Thời gian chờ kết nối UDP thực sự có ý nghĩa gì?

18

Vì UDP là giao thức không kết nối, tôi bối rối với cài đặt trên Tường lửa Sonicwall của mình cho "Hết thời gian kết nối UDP". Nó được đặt ở mặc định là 30 giây - nhưng chính xác thì hết sau 30 giây?

Đây là tình huống thực tế của tôi: Tôi có một máy chủ NTP trong nhóm ntp.org phục vụ khoảng 3000 truy vấn mỗi phút. Điều này gây ra một chút căng thẳng cho lớp TZ-200 SOHO của tôi - không phải về băng thông; nhưng về mặt # của các kết nối, nó đã đi qua nó. Tôi tự hỏi liệu các kết nối UDP bằng cách nào đó có 'được giữ sống' trên SonicWall hay không; mặc dù chúng (theo định nghĩa) không kết nối.

Tôi đang thiếu gì ở đây? SonicWall có nghĩa là gì khi nói về "Hết thời gian kết nối UDP"?

sonicwall udp

— Jon Wadsworth
nguồn

Tường lửa thường cho phép các gói cho một kết nối được thiết lập bởi một máy bên trong tường lửa. Nhưng UDP không có kết nối. Vì vậy, các lựa chọn là cho phép tất cả các gói UDP, chặn tất cả các gói UDP hoặc thử đoán "các kết nối UDP" là gì để chỉ cho phép các gói là một phần của các "kết nối" đó. Tất cả (?) Nhà cung cấp tường lửa thực hiện phương pháp cuối cùng.

— dùng253751

Như Immibis đã mô tả. Do Dịch địa chỉ mạng hoặc NAT, bộ định tuyến cổng mạng / mạng con sẽ chỉ cho phép TCP (hầu như tất cả lưu lượng truy cập là TCP) trong đó máy khách trên mạng con khởi tạo kết nối. Vì không có cách nào để gán một cổng cho NAT nếu kết nối đến. Làm thế nào để bộ định tuyến biết ai sẽ gửi nó đến? UDP thậm chí không có kết nối, vậy làm thế nào để bộ định tuyến xử lý các yêu cầu UDP bắt đầu? Một cách là theo dõi các gói UDP đi.

— soái ca thủ công

Nếu bạn đang lưu trữ một máy chủ, bạn nên chuyển tiếp các cổng mà bạn mong đợi để nhận kết nối, mặc dù hãy chuẩn bị cho mọi thứ.

— soái ca thủ công

16

Mặc dù không có "kết nối" chính thức với UDP, nhưng vẫn có một quy ước rằng khách hàng gửi yêu cầu và mong đợi nhận được phản hồi với IP nguồn và cổng được hoán đổi với IP và cổng Destinatoin.

Do đó, tường lửa và NAT có trạng thái giả định rằng các gói có sự kết hợp nhất định của IP nguồn / cổng nguồn / Cổng đích / Cổng đích và sự kết hợp tương ứng với một phần của "kết nối" nguồn và đích. Điều này cho phép các quy tắc như "chỉ kết nối đi" được áp dụng cho UDP và cho phép áp dụng các bản dịch ngược cho các gói phản hồi.

Thật không may, tường lửa hoặc NAT không có cách nào để biết khi nào máy khách nói xong với máy chủ. Vì vậy, nó phải chờ một khoảng thời gian chờ trước khi xóa mục khỏi bảng theo dõi trạng thái của nó. Đó là thời gian chờ bạn đang thiết lập.

Về nguyên tắc, có thể xây dựng một hộp NAT sử dụng cách tiếp cận không trạng thái cho cổng chuyển tiếp trong khi vẫn duy trì cách tiếp cận trạng thái cho các kết nối đi nhưng đơn giản hơn là chỉ sử dụng NAT trạng thái cho mọi thứ và có vẻ như đây là việc nhà cung cấp của bạn đang làm.

Thật không may khi bạn đã phát hiện ra điều này đối với các máy chủ UDP không trạng thái phục vụ số lượng lớn các yêu cầu nhỏ. Bạn kết thúc trong một tình huống mà tường lửa tiêu thụ nhiều tài nguyên hơn nhiều so với chính sever.

— Peter Green
nguồn

2

Cảm ơn câu trả lời tuyệt vời Peter! Trong trường hợp của tôi, SonicWall cho phép tôi giảm "thời gian chờ kết nối" UDP trên một quy tắc tường lửa cụ thể, vì vậy tôi sẽ giảm quy tắc của chính sách NTP xuống còn 5 giây (từ mặc định là 30).

— Jon Wadsworth

1

Lưu ý: Sau khi thực hiện điều đó, tôi đã thấy 'tổng số kết nối' được báo cáo bởi Sonicwall giảm từ ~ 1500 xuống ~ 400. Hoàn hảo! Cảm ơn một lần nữa cho câu trả lời tuyệt vời.

— Jon Wadsworth

1

Xin lưu ý rằng hầu hết các giao thức phát trực tuyến đều sử dụng UDP, bao gồm phần phương tiện của VOIP (sau khi được đàm phán bằng SIP). Việc thiếu thời gian chờ đó có thể gây ra sự cố nếu không có lưu lượng truy cập (ví dụ như cuộc gọi bị tạm dừng, cả hai bên bị tắt tiếng, v.v.) vì không phải tất cả các điện thoại VOIP (cứng hoặc mềm) đều tuyệt vời trong việc đàm phán lại kết nối phương tiện nếu các cổng bị rớt . Những người khác sử dụng 'giữ mạng' bằng cách gửi các tín hiệu nhỏ trên cơ sở định kỳ, có thể cách xa nhau hơn 5 giây.

— Chuck van der Linden

11

Tường lửa của bạn đang duy trì một bảng kết nối cho các kết nối UDP. Ví dụ: khi bạn gửi truy vấn DNS, tường lửa sẽ tạo một mục nhập cho luồng đó để phản hồi DNS sẽ được phép quay lại mạng của bạn. Các mục trong bảng hết thời gian sau 30 giây không có hoạt động.

— Ron Trunk
nguồn

Cảm ơn Ron. Bạn có thể nhận xét về Bảng kết nối đó, liên quan đến các kết nối trong nước không? Vì máy chủ NTP của tôi ở bên trong, nên thực sự không cần phải 'mở cửa' cho các kết nối gửi đến, vì Máy chủ của tôi ở bên trong luôn có thể quay trở lại nguồn (Tôi có mở rộng ra bên ngoài quy tắc). Cảm ơn vì sớm phản hồi!

— Jon Wadsworth

3

Bảng kết nối được xây dựng bất kể hướng của kết nối và thực sự được sử dụng ngay lập tức cho gói phản hồi quay trở lại từ máy chủ của bạn thông qua tường lửa trở về querier. Tường lửa đang duy trì một bộ (src ip, src port, dst ip, dst port) để liên kết truy vấn ban đầu với phản hồi. Vì thực sự không có một semaphore để chỉ ra cho tường lửa rằng một phiên UDP cụ thể đã kết thúc và ổ cắm đã đóng giá trị thời gian chờ kết thúc được sử dụng.

— rnxrx

2

Máy chủ NTP của bạn đứng sau NAT (tường lửa) của bạn. UDP không có kết nối theo quan điểm của ứng dụng và HĐH và cho hầu hết các thiết bị mạng trên đường đi.

Tuy nhiên, đối với tường lửa NAT của bạn, nó ghi lại bất cứ khi nào gói UDP bị tắt để phản hồi từ đầu bên kia sẽ được chuyển hướng đến cùng một máy tính trong mạng của bạn. Chúng được gọi là "kết nối" bởi tường lửa.

Bây giờ, về mặt lý thuyết, NAT biết rằng cổng bên ngoài sẽ là cổng nổi tiếng NTP, nhưng có vẻ như tường lửa của bạn không hỗ trợ điều đó. Nếu đây là lần duy nhất bạn sử dụng cho UDP thông qua tường lửa này, bạn có thể đặt thời gian chờ kết nối thành một số nhỏ hơn. Cách khác, nếu nó cho phép bạn đặt theo cổng ứng dụng, bạn có thể đặt nó ở thời gian nhỏ hơn (1 giây, giả sử) cho cổng cụ thể đó.

— Alan
nguồn

1

Thời gian chờ không dành riêng cho NAT; bất kỳ tường lửa nhà nước sẽ có một.

— grawity

Tường lửa không làm NAT thay vào đó, nó đang cố lọc các gói đang chuyển qua NAT, do đó có liên quan đến bộ định tuyến và NAT.

— soái ca thủ công

Bộ định tuyến cổng vào internet Phải sử dụng NAT vì bất kỳ máy tính nào nằm trên mạng con, chỉ có bộ định tuyến cổng có địa chỉ IP internet thực tế. Sẽ vô cùng lãng phí nếu mỗi máy tính là một thứ trên internet. Bộ định tuyến cổng đôi khi có một nhóm lớn các máy tính được liên kết với một địa chỉ IP internet. Nó sử dụng một ổ cắm web bí mật để có thể dịch một đến một giữa các gói đến từ web và máy tính trên mạng của nó. Mọi người dường như không có được điều này.

— soái ca thủ công

0

IPv6 không cần NAT, nhưng nó vẫn xuất hiện như thể tường lửa có trạng thái liên quan đến UDP.

— David Howard
nguồn