Tcpdump hiển thị cổng chuyển hướng khác sau khi thêm quy tắc REDIRECT trong iptables

Nói rõ hơn: Thử nghiệm của OP được thực hiện từ hệ thống 192.168.1.100 cho chính nó, không phải từ hệ thống từ xa và đó là nguyên nhân của sự cố. Cổng không bị thay đổi trong trường hợp này vì không có quy tắc NAT nào khớp, trong khi nó sẽ khớp nếu được thực hiện từ một hệ thống từ xa.

Sơ đồ dưới đây cho thấy thứ tự các hoạt động được thực hiện trên một gói:

Lý do là cách NAT hoạt động trên Linux: iptables nhìn thấy một gói trong tự nhiên table chỉ dành cho gói đầu tiên của luồng theo dõi mới (do đó ở trạng thái MỚI).

Quy tắc này hoạt động tốt khi từ một hệ thống từ xa. Trong trường hợp này, gói đầu tiên được nhìn thấy sẽ là gói đến:

đến cổng 8000 -> AF_PACKET (tcpdump) -> conntrack -> nat/PREROUTING (iptables REDIRECT): đến cổng 30000
--> quyết định định tuyến --> ... --> nhận quy trình cục bộ trên cổng 30000

Tất cả các gói sau trong cùng một luồng sẽ có conntrack xử lý trực tiếp thay đổi cổng (hoặc đảo ngược cổng để trả lời) và sẽ bỏ qua mọi quy tắc iptables trong tự nhiên bảng (như được viết trong sơ đồ: tự nhiên bảng chỉ được tư vấn cho MỚI kết nối). Vì vậy, (bỏ qua phần gói trả lời), thay vào đó, gói đến tiếp theo sẽ trải qua quá trình này:

đến cổng 8000 -> AF_PACKET (tcpdump) -> conntrack: đến cổng 30000
--> quyết định định tuyến --> ... --> nhận quy trình cục bộ trên cổng 30000

Để tự kiểm tra hệ thống, gói đầu tiên không phải là gói đến mà là gói đi. Thay vào đó, điều này xảy ra bằng cách sử dụng lệnh gửi đi lo giao diện:

máy khách quy trình cục bộ cuộn tròn -> quyết định định tuyến -> conntrack -> nat/OUTPUT (không có quy tắc ở đây)
-> kiểm tra định tuyến lại -> AF_PACKET (tcpdump) -> đến cổng 8000

Và bây giờ gói này được lặp lại trên lo giao diện, nó xuất hiện lại dưới dạng một gói không còn là gói đầu tiên trong kết nối, vì vậy hãy làm theo trường hợp thứ hai như trên: conntrack một mình xử lý NAT và không gọi nat/CHUẨN BỊ. Ngoại trừ nó không được hướng dẫn ở bước trước để thực hiện bất kỳ NAT nào:

đến cổng 8000 -> AF_PACKET (tcpdump) -> conntrack
--> quyết định định tuyến --> ... -->khôngquá trình cục bộ nhận trên cổng8000

vì không có gì lắng nghe trên cổng 8000, hệ điều hành sẽ gửi lại TCP RST.

Để điều này hoạt động trên hệ thống cục bộ, một CHUYỂN ĐỔI quy tắc cũng phải được đưa vào tự nhiên/ĐẦU RA chuỗi:

iptables -t nat -I OUTPUT -d 192.168.1.100 -p tcp --dport 8000 -j REDIRECT --to-port 30000

Ghi chú bổ sung

• nếu trường hợp được thiết kế để sử dụng từ xa, đừng kiểm tra từ hệ thống cục bộ: các quy tắc được kiểm tra thông qua không giống nhau. Điều này làm cho bài thi không phản ánh đúng thực tế.

  Chỉ cần sử dụng một không gian tên mạng để tạo một hệ thống điều khiển từ xa bỏ túi trong trường hợp không có hệ thống nào khác. Ví dụ sẽ hoạt động với một hệ thống chỉ có OP nat/CHUẨN BỊ quy tắc và làm cuộn tròn http://192.168.1.100/ (không yêu cầu DNS):

  ip netns thêm hệ thống từ xa
  liên kết ip thêm tên vethremote lên loại veth ngang hàng netns tên hệ thống từ xa eth0
  địa chỉ ip add 192.0.2.1/24 dev vethremote
  ip -n địa chỉ hệ thống từ xa thêm 192.0.2.2/24 dev eth0
  thiết lập liên kết hệ thống từ xa ip -n eth0
  ip -n tuyến hệ thống từ xa thêm 192.168.1.100 qua 192.0.2.1
  ip netns exec remotesystem curl http://192.168.1.100:8000/
  

• tcpdump và NAT

  tcpdump xảy ra tại AF_PACKET các bước trong sơ đồ trên: rất sớm để xâm nhập và rất muộn để đi ra. Điều đó có nghĩa là đối với trường hợp hệ thống từ xa, nó sẽ không bao giờ chiếm được cổng 30000 ngay cả khi nó đang hoạt động. Đối với trường hợp hệ thống cục bộ, một khi tự nhiên/ĐẦU RA quy tắc được thêm vào, nó sẽ chiếm cổng 30000.

  Chỉ cần không tin tưởng một cách mù quáng vào địa chỉ/cổng được hiển thị bởi tcpdump khi thực hiện NAT: nó phụ thuộc vào trường hợp và nơi xảy ra quá trình chụp.