Làm thế nào để NAT quyết định kết nối nào là trong nước và bên ngoài nào?


7

Tôi đang xây dựng một ứng dụng P2P cần có khả năng truy cập các nút phía sau NAT. NAT này không cho phép các kết nối gửi đến, do đó các nút bên ngoài mạng không thể tiếp cận với các nút phía sau NAT.

Giải pháp của tôi cho vấn đề này là nút phía sau NAT sẽ tiếp cận với nút bên ngoài và nút bên ngoài, khi thời gian sẵn sàng, kết nối với nút bên trong NAT bằng cách sử dụng kết nối TCP được thiết lập sẵn đó. Vì kết nối này sẽ được thiết lập bởi nút bên trong NAT, nên điều này sẽ không bị chặn bởi NAT.

Đây là câu hỏi của tôi. Tôi không biết cách giải thích nào được gạch chân là đúng, hoặc nếu cả hai đều sai.

Giải thích # 1

một khái niệm về một kết nối TCP, hiệu quả một ống, và khi một nút bên trong NAT tạo ra một yêu cầu bất cứ điều gì về thế giới bên ngoài, ống mở ra, câu trả lời được đưa vào nó, và ống đóng mãi mãi.

Kết quả: NAT sẽ không cho phép bất kỳ kết nối TCP nào tới máy khách từ nút bên ngoài sau khi ống đó đóng lại.

Giải thích # 2

Không có thứ gọi là kết nối TCP, nhưng, truyền TCP. Do kết nối TCP được định nghĩa là a local ip:portvà a remote ip:port, sau khi một nút phía sau NAT gọi một nút bên ngoài, nút bên ngoài có thể gọi lại bằng cùng một cổng mà khách hàng đã thực hiện yêu cầu và điều đó sẽ "tính" như cùng một TCP kết nối, không phải là một cuộc gọi không mong muốn của NAT.

Kết quả: NAT đoán một cách hiệu quả liệu kết nối này có phải là phản hồi cho những gì nút bên trong NAT yêu cầu hay không bằng cách xem hồ sơ lịch sử. Do nút phía sau NAT thực hiện cuộc gọi đầu tiên, nên nút bên ngoài có thể gọi lại bằng cách sử dụng cùng một cổng máy khách và nó sẽ hoạt động.

Mô hình tinh thần của tôi gần với # 1, nhưng khi tôi kiểm tra các kết nối với Wireshark, chúng xuất hiện dưới dạng các kết nối TCP riêng biệt hoặc ít nhất là các thực thể riêng biệt.

Nó gần với # 1, hay # 2 hơn, hay tôi vô vọng bối rối?


Bạn có thể muốn tra cứu STUN và công việc liên quan: en.wikipedia.org/wiki/STUN
pjc50

5
Tôi thực sự khuyên bạn trước tiên nên triển khai phiên bản IPv6 cho ứng dụng của mình để bạn không phải đối phó với tất cả sự phức tạp của NAT trong phiên bản đầu tiên. Khi bạn có phiên bản hoạt động trên IPv6, hãy bắt đầu xem xét cách làm cho nó hoạt động trên IPv4.
kasperd

Câu trả lời:


9

TCP là một giao thức hướng kết nối và nó chỉ có thể giao tiếp thông qua các kết nối.

Trước khi bạn bắt đầu lập trình bằng TCP, trước tiên bạn nên hiểu cách thức hoạt động của TCP và bạn nên bắt đầu với RFC 793, Giao thức điều khiển truyền dẫn , là định nghĩa của TCP.

RFC giải thích các ổ cắm và kết nối:

Ghép kênh:

Để cho phép nhiều quy trình trong một Máy chủ sử dụng đồng thời các phương tiện truyền thông TCP, TCP cung cấp một bộ địa chỉ hoặc cổng trong mỗi máy chủ. Kết hợp với mạng và địa chỉ máy chủ từ lớp giao tiếp internet, điều này tạo thành một ổ cắm. Một cặp ổ cắm xác định duy nhất mỗi kết nối. Đó là, một ổ cắm có thể được sử dụng đồng thời trong nhiều kết nối.

Sự ràng buộc của các cổng với các quy trình được xử lý độc lập bởi mỗi Máy chủ. Tuy nhiên, nó hữu ích khi đính kèm các quy trình được sử dụng thường xuyên (ví dụ: "logger" hoặc dịch vụ chia sẻ thời gian) vào các ổ cắm cố định được công chúng biết đến. Những dịch vụ này sau đó có thể được truy cập thông qua các địa chỉ được biết đến. Thiết lập và tìm hiểu địa chỉ cổng của các quy trình khác có thể liên quan đến các cơ chế năng động hơn.

Kết nối:

Các cơ chế kiểm soát luồng và độ tin cậy được mô tả ở trên yêu cầu các TCP khởi tạo và duy trì thông tin trạng thái nhất định cho từng luồng dữ liệu. Sự kết hợp của thông tin này, bao gồm các ổ cắm, số thứ tự và kích thước cửa sổ, được gọi là kết nối. Mỗi kết nối được chỉ định duy nhất bởi một cặp ổ cắm xác định hai mặt của nó.

Khi hai quá trình muốn giao tiếp, trước tiên TCP của chúng phải thiết lập kết nối (khởi tạo thông tin trạng thái ở mỗi bên). Khi giao tiếp của họ hoàn tất, kết nối bị chấm dứt hoặc đóng để giải phóng tài nguyên cho các mục đích sử dụng khác.

Do các kết nối phải được thiết lập giữa các máy chủ không đáng tin cậy và qua hệ thống truyền thông internet không đáng tin cậy, nên một cơ chế bắt tay với các số thứ tự dựa trên đồng hồ được sử dụng để tránh khởi tạo sai các kết nối.

Theo như liên kết ngang hàng TCP bên ngoài, nó đang kết nối với địa chỉ bên ngoài của thiết bị NAT, mặc dù thiết bị đó đang chuyển tiếp đến ngang hàng TCP khác ở bên trong, dựa trên kết nối được khởi tạo bởi thiết bị bên trong.

Bạn cũng có thể nghiên cứu RFC 5382, Yêu cầu hành vi của NAT đối với TCP .


7

Kết nối TCP được coi là "có hiệu lực" miễn là phần mềm xử lý ở hai đầu giữ cho ổ cắm mở.

Khi quá trình trên một hoặc cả hai kết thúc đóng ổ cắm (vì duyên dáng hoặc kết nối bị hủy bỏ vì một lý do nào đó), điều này sẽ chuyển, trên dây, sang gói TCP với cờ FIN hoặc RST được đặt.

Việc triển khai NAT trên bộ định tuyến NAT tìm kiếm các cờ FIN và RST và khi thấy một gói có các cờ này, nó sẽ "đóng lỗ". Sau thời điểm này, khách hàng phải bắt đầu một kết nối mới để "mở một lỗ mới".

Tóm lại, miễn là máy khách và máy chủ của bạn giữ cho ổ cắm của họ mở, hiệp hội NAT vẫn tồn tại.


4

Khi tôi viết "thông thường" ở đây, tôi nghĩ đến bộ định tuyến WLAN-NAT tiêu dùng trung bình của bạn với cấu hình lành mạnh hoặc một số mạng Linux đơn giản với cài đặt mặc định. Như thường lệ, điều này có thể được thực hiện phức tạp hoặc phức tạp khi cần thiết. Vì câu hỏi rất cơ bản, điều này dường như có ý nghĩa nhất đối với tôi thay vì đi thẳng vào bất kỳ giải pháp NAT cấp doanh nghiệp phức tạp hơn.

Bạn đã chấp nhận câu trả lời, nhưng hãy để tôi cố gắng giải quyết trực tiếp câu hỏi bạn đã hỏi:

Làm thế nào để NAT quyết định kết nối nào là trong nước và bên ngoài nào?

Cơ sở cho quyết định (cho bất kỳ quyết định nào trong bộ định tuyến) là một bộ quy tắc dưới một hình thức hoặc thời trang nào đó. Trong trường hợp này, đối với mỗi giao diện liên quan (nghĩa là giao diện LAN bên trong so với giao diện WAN / đường lên bên ngoài), quản trị viên sẽ thực hiện các quy tắc. Các quy tắc này khá khác nhau, tức là các quy tắc cho giao diện LAN trông khác rất nhiều so với các quy tắc của giao diện WAN.

Biết một gói đến từ đâu và đến đâu là bánh mì và bơ của những gì một bộ định tuyến làm.

Hãy để tôi bắt đầu với một

Thí dụ

Trang NAT của Wikipedia có rất nhiều văn bản về vấn đề này, nhưng một trường hợp đơn giản (mạng LAN công ty đơn giản so với đường lên DSL đơn) đây là điều xảy ra:

  1. PC khách cố gắng khởi tạo kết nối HTTP đến máy chủ dựa trên internet, ví dụ 198.51.100.20. Bản thân PC có một địa chỉ không định tuyến như 192.0.2.2. Bộ định tuyến DSL giá rẻ có hai giao diện, một bên trong (192.0.2.1) và bên ngoài (203.0.113.10, rất có thể thay đổi thường xuyên và được cung cấp thông qua một số giao thức liên kết cục bộ của nhà cung cấp DLS). Vì vậy, PC gửi một gói SYN đến 198.51.100.20:80 thông qua cổng mặc định của nó, đó là 192.0.2.1.
  2. Bộ định tuyến nhận gói tin tại giao diện 192.0.2.1, giống như nó cũng sẽ làm nếu không có NAT tham gia. Nó đã được cấu hình để thực hiện NAT trên giao diện này, vì vậy nó tiến hành thực hiện những việc sau:
    • Phát minh ra một số cổng mới, chưa được sử dụng cho đến nay. Ví dụ 12345.
    • Thay đổi địa chỉ "người gửi" trong tiêu đề IP thành 203.0.113.10.
    • Hãy nhớ số cổng người gửi ban đầu trong tiêu đề TCP (do PC cung cấp), hãy gọi nó là 4321.
    • Thay đổi tiêu đề TCP để chứa số cổng người gửi 12345.
    • Thêm một mục (12345; 192.0.2.2; 4321) trong bảng dịch NAT của nó.
    • Gửi gói theo cách vui vẻ của nó đến đường lên / cổng riêng của nó.
  3. 198.51.100.20 cuối cùng nhận được gói, thông báo rằng đó là một SYN ("thiết lập kết nối mới") và gửi tin nhắn SYN-ACK trở lại cho người gửi. Theo quan điểm của mình, đây là địa chỉ IP 203.0.113.10, với cổng đích TCP là 12345.
  4. Bộ định tuyến nhận gói tin này trên giao diện WAN của nó. Giao diện WAN đã được cấu hình để giải quyết các địa chỉ NATted như thế này. Các bộ định tuyến sau đó ...
    • ... kiểm tra bảng dịch NAT của nó, tìm mục ...
    • ... Sửa đổi gói thành đích 192.0.2.2 ...
    • ... sửa cổng đích TCP trở về 4321 ...
    • ... và gửi nó theo cách vui vẻ của nó (trên giao diện LAN).
  5. PC nhận được gói và không thấy gì về thủ tục NAT. Các chàng gói chỉ như thế nào nếu 198.51.100.20 đã gửi nó, vì nếu router NAT là không có gì cả.

Không có lúc nào chủ đề của một "kết nối" xuất hiện. Bộ định tuyến NAT (ở dạng đơn giản nhất) không cần quan tâm đến nội dung của các tin nhắn. Nó quan tâm đến các địa chỉ IP và các cổng của người gửi và người nhận, nhưng không có gì khác. (Được cấp: điều này có khả năng bỏ qua tất cả các loại vấn đề liên quan đến bảo mật và hiệu suất; nhưng đây là về nguyên tắc rất cơ bản giống như nguyên tắc trong câu hỏi này.)

Vậy làm thế nào để bộ định tuyến biết?

Các bộ định tuyến hoàn toàn không cần biết về "kết nối". Trong thực tế, các quy trình tương tự như được mô tả cho TCP tồn tại đối với giao thức UDP không kết nối (đục lỗ UDP), hoặc thực sự có thể được thực hiện cho bất kỳ giao thức nào có thứ gì đó giống như số cổng trong lớp vận chuyển.

Lý do tại sao bộ định tuyến cần biết giao thức cấp vận chuyển (TCP, UDP, ...) liên quan đến NAT chủ yếu là do các cổng không phải là một phần của IP; và các cổng là những gì làm cho "hack" mà NAT (loại này) có thể dễ dàng thực hiện được.

Vì vậy, với câu hỏi của bạn:

Làm thế nào để NAT quyết định kết nối nào là trong nước và bên ngoài nào?

Các kết nối ngoài là mỗi định nghĩa bắt đầu bằng gói SYN (hoặc cú đấm UDP ban đầu trong trường hợp UDP) xuất hiện tại giao diện LAN. Gọi họ là "kết nối" trong trường hợp NAT là một chút; chúng kết thúc đơn giản chỉ là một mục tạm thời trong bảng dịch NAT (cộng với bất kỳ bảo mật / hiệu suất bổ sung nào mà bộ định tuyến NAT riêng lẻ cũng có thể sử dụng).

Kết nối trong nước không tồn tại trong kịch bản tôi đã sử dụng trong câu trả lời cho đến nay. Tất nhiên có các biến thể của NAT làm điều này; ví dụ: bạn có thể xác định tĩnh một cổng trên giao diện WAN của bộ định tuyến bằng một IP cụ thể: PORT trên giao diện LAN, điều này cho phép chạy một máy chủ bên trong mạng LAN NATted của bạn. Điều này cũng thường được hỗ trợ bởi các bộ định tuyến DSL / WLAN tiêu dùng giá rẻ. Và với các bộ định tuyến "thực", rõ ràng bạn có thể định cấu hình chúng theo bất kỳ hình thức hoặc thời trang nào bạn thích.

Các gói IP trong / ngoài nước khác không khác với các gói được đưa ra trong ví dụ. Khi bắt tay SYN ban đầu đã được thực hiện và bộ định tuyến có mục trong bảng dịch của nó, nó sẽ đi qua (với cùng một bản dịch như được giải thích trong ví dụ) tất cả các gói tiếp theo theo cả hai hướng.

Nếu, trong bối cảnh kết nối TCP được thiết lập như vậy, máy chủ muốn gửi dữ liệu đến máy khách (điều này hoàn toàn có thể - TCP là hai chiều), đây chỉ là các gói IP, theo như bộ định tuyến NAT có liên quan. Nó sẽ không thực sự quan tâm nhiều đến nội dung của các gói đó (nghĩa là chúng có chứa các tải trọng nhất định hay chỉ là các gói "quản lý" của TCP hoặc bất cứ thứ gì).

Không có lúc nào bộ định tuyến "đóng ống" khi bạn đặt nó. Rõ ràng, bộ định tuyến sẽ có một số khái niệm về việc khi nào nó có thể xóa mục nhập khỏi bảng dịch (có thể là khi thông báo bắt tay FIN kết thúc kết nối, hoặc do hết thời gian hoặc một số trạng thái lỗi), nhưng từ đầu đến cuối một cuộc tình liên tục.


1
Vui lòng sử dụng địa chỉ IP từ RFC5737, được xác định cụ thể cho mục đích tài liệu, thay vì "chiếm quyền điều khiển" hợp lệ, đặc biệt là từ Google.
Patrick Mevzek

1
Các kết nối là hai chiều, vì vậy chúng là cả trong và ngoài nước. Đó là sự khởi đầu của kết nối sẽ là trong hoặc ngoài nước.
Ron Maupin

@RonMaupin, vâng, tôi giải thích rằng trong các đoạn cuối, đặc biệt là đoạn thứ hai đến cuối. Điều đó có phù hợp với những gì bạn muốn nói không, hay tôi đã viết nó một cách khó hiểu?
AnoE

@PatrickMevzek, học một cái gì đó mới mỗi ngày. Xong + cảm ơn!
AnoE

Cảm ơn. Tôi đồng ý, câu hỏi của tôi có lẽ được đặt ra cụ thể hơn là bắt đầu kết nối, không phải là một câu hỏi liên quan đến tính hai chiều. Tôi đã thực hiện ánh xạ cổng và các bộ định tuyến hoạt động bình thường sẽ hoạt động. Tôi đã hỏi câu hỏi này để tìm ra những gì có thể được thực hiện cho các bộ định tuyến không cộng tác, chẳng hạn như các bộ định tuyến trong quán cà phê, nơi công cộng, v.v. Đây là một phản ứng tuyệt vời đi qua tình hình chung, mặc dù, rất nhiều đánh giá cao.
Trưởng khoa M.
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.