Tại sao NAT không dự trữ cổng từ nhóm cổng TCP và UDP của máy?


8

Tôi đã thực hiện hai thí nghiệm. Đây là mạng cho cả hai:

        [private network]     [public network]
    A -------------------- R ----------------- B
192.168.0.5     192.168.0.1|192.0.2.1       192.0.2.8

Một 's gateway mặc định là R . R có chuyển tiếp IPv4 hoạt động và quy tắc iptables sau:

iptables -t nat -A POSTROUTING -p TCP -j MASQUERADE --to-ports 50000

Mục đích là, mọi thứ TCP từ A sẽ được che dấu là 192.0.2.1 bằng cổng 50000 của R.

Tôi đã xuất bản một dịch vụ TCP trên cổng 60000 trên B bằng cách sử dụng nc -4l 192.0.2.8 60000.

Sau đó, tôi đã mở một kết nối từ A :nc -4 192.0.2.8 60000

A bắt đầu gửi các gói trông như thế này:

192.168.0.5:53269 -> 192.0.2.8:60000

R đã dịch nó thành

192.0.2.1:50000 -> 192.0.2.8:60000

Càng xa càng tốt.

Sau đó tôi đã cố gắng mở ứng dụng khách sau trên R : nc -4 192.0.2.8 60000 -p 50000. Tôi đã gửi tin nhắn, không có gì xảy ra. Không có gói nào có thể được nhìn thấy trên tcpdump của R.

Bởi vì quy tắc giả trang tồn tại hoặc ít nhất là vì nó hoạt động, tôi đã dự đoán nc của R sẽ thất bại với thông báo lỗi "nc: Địa chỉ đã được sử dụng", đó là điều xảy ra nếu tôi liên kết hai ncs với cùng một cổng.

Sau đó tôi đợi một lúc để ánh xạ của conntrack sẽ chết.

Thử nghiệm thứ hai bao gồm tôi cố gắng mở ứng dụng khách của R trước. R bắt đầu nói chuyện với B tốt. Nếu sau đó tôi mở kết nối từ A , các gói của nó sẽ bị bỏ qua. Các SYN của A đến R , nhưng họ không trả lời, thậm chí không phải do lỗi ICMP. Tôi không biết liệu đây có phải là do R biết rằng nó đã hết các cổng giả mạo hay vì Linux chỉ bị nhầm lẫn (về mặt kỹ thuật nó che giấu cổng nhưng kết nối đã được thiết lập bằng cách nào đó đã can thiệp).

Tôi cảm thấy hành vi của NAT là sai. Tôi có thể vô tình cấu hình một cổng cho cả việc giả mạo (đặc biệt, bằng cách không chỉ định --to-portstrong quy tắc iptables) và một dịch vụ, và kernel sẽ bỏ kết nối một cách im lặng. Tôi cũng không thấy bất kỳ tài liệu này ở bất cứ đâu.

Ví dụ:

  • Một tạo ra một yêu cầu bình thường để B . Mặt nạ R sử dụng cổng 50k.
  • Một làm cho một truy vấn DNS để R . Do T là đệ quy, R (sử dụng, ngoài sự trùng hợp ngẫu nhiên, cổng phù du 50k) truy vấn máy chủ tên Z có thẩm quyền trên cổng 53.

Một vụ va chạm vừa xảy ra; R hiện đang sử dụng cổng 50k cho hai kết nối TCP riêng biệt.

Tôi đoán đó là vì bạn thường không xuất bản dịch vụ trên các bộ định tuyến. Nhưng sau đó, một lần nữa, nó có làm tổn thương hạt nhân để "mượn" cổng từ nhóm cổng TCP khi nó bị giả mạo tích cực không?

Tôi biết rằng tôi có thể tách các cổng phù du của tôi khỏi --to-ports. Tuy nhiên, đây dường như không phải là hành vi mặc định. Cả NAT và các cổng phù du mặc định là 32768-61000, rất đáng sợ.

(Tôi đã tìm thấy phạm vi phù du bằng cách truy vấn / Proc / sys / net / ipv4 / ip_local_port_range và phạm vi NAT bằng cách đơn giản NATting nhiều yêu cầu UDP trong một thử nghiệm riêng biệt - và in cổng nguồn ở phía máy chủ. Tôi không thể tìm thấy một cách để in phạm vi bằng iptables.)


2
Tại sao nó đáng sợ khi NAT sử dụng phạm vi cổng ethemeral? Nếu một khách hàng trên A sử dụng một cổng kết nối cũng được sử dụng trên R, thì nó sẽ được chuyển sang một cổng mới. Và tại sao có một dịch vụ như DNS hoặc DHCP trên R phải làm bất cứ điều gì với điều này? DNS và DHCP không sử dụng cổng phù du (ở phía máy chủ). Và tại sao chỉ sử dụng một cổng duy nhất để giả mạo?
Thomas Erker

@Thomas: Các câu hỏi của bạn thực sự đã đưa tôi đi đúng hướng và tôi rất biết ơn, nhưng có vẻ như bạn cũng có một quan niệm sai lầm nhỏ: Nếu một khách hàng trên A sử dụng cổng phù du cũng được sử dụng trên R, điều đó không nhất thiết được NATed đến một cái mới; NAT không truy vấn nhóm cổng TCP / UDP. Tôi thực sự nhận thấy các kết nối NAT va chạm là bình thường và vô hại; xem câu trả lời của tôi
Yd Ahhrk

@Thomas: Tôi không nghĩ DHCP thông qua; Tôi đã thực sự nghĩ về DNS. Tôi tưởng tượng DNS sử dụng các cổng phù du nếu đó là một máy chủ tên đệ quy (để truy vấn các cổng có thẩm quyền); xem chỉnh sửa của tôi.
Yd Ahhrk

@Thomas: Toàn bộ thí nghiệm nhằm xem điều gì sẽ xảy ra khi có va chạm; Tôi giảm phạm vi phù du xuống một cổng duy nhất để buộc va chạm.
Yd Ahhrk

Câu trả lời:


2

nó có làm tổn thương hạt nhân để "mượn" cổng từ nhóm cổng TCP khi nó bị giả mạo tích cực không?

Tôi đoán câu trả lời là "không, nhưng nó không quan trọng lắm."

Tôi giả sử không chính xác R chỉ sử dụng địa chỉ vận chuyển đích của gói phản hồi để cho biết liệu nó đang hướng về A hay chính nó. Nó thực sự dường như sử dụng toàn bộ địa chỉ vận chuyển đích nguồn để xác định một kết nối. Do đó, NAT thực sự tạo ra nhiều kết nối bằng cách sử dụng cùng một cổng ( sở hữu R ); nó không tạo ra bất kỳ sự nhầm lẫn. Do đó, nhóm cổng TCP / UDP không thành vấn đề.

Bây giờ nó khá rõ ràng khi tôi nghĩ về nó.

Sau đó tôi đã cố gắng mở ứng dụng khách sau trên R : nc -4 192.0.2.8 60000 -p 50000. Tôi đã gửi tin nhắn, không có gì xảy ra. Không có gói nào có thể được nhìn thấy trên tcpdump của R.

Đây là một phần của các thí nghiệm mà tôi đã làm hỏng.

Lỗi xảy ra vì cả địa chỉ vận chuyển nguồn đích đều giống nhau, không chỉ vì địa chỉ nguồn giống nhau.

Nếu tôi làm, nói nc -4 192.0.2.8 60001 -p 50000, nó thực sự hoạt động. Ngay cả khi nó sử dụng cùng một cổng với mặt nạ NAT.

Tôi cảm thấy hành vi của NAT là sai. Tôi có thể vô tình cấu hình một cổng cho cả việc giả mạo (đặc biệt, bằng cách không chỉ định --to-portstrong quy tắc iptables) và một dịch vụ, và kernel sẽ bỏ kết nối một cách im lặng.

Nó sẽ không, bởi vì các kết nối đeo mặt nạ và các kết nối được khởi động R rất có thể sẽ có các điểm đến khác nhau.

Bởi vì quy tắc giả trang tồn tại hoặc ít nhất là vì nó hoạt động, tôi đã dự đoán nc của R sẽ thất bại với thông báo lỗi "nc: Địa chỉ đã được sử dụng", đó là điều xảy ra nếu tôi liên kết hai ncs với cùng một cổng.

Tôi vẫn đang tìm kiếm một câu trả lời chống đạn cho vấn đề này, nhưng mọi thứ dường như chỉ ra rằng "đó là hậu quả bất lợi của cách nó được thực hiện và thật nhỏ bé chúng tôi sẵn sàng sống với nó."

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.