Що насправді означає час очікування з'єднання UDP?

18

Оскільки UDP є протоколом без підключення, мене бентежить налаштування на мій брандмауері Sonicwall для "Час очікування з'єднання UDP". Він встановлений за замовчуванням 30 секунд - але що саме закінчується через 30 секунд?

Ось моя реальна ситуація: у мене є NTP-сервер у пулі ntp.org, який обслуговує близько 3000 запитів в хвилину. Це спричиняє певну напругу на моєму SOHO TZ-200 - не з точки зору пропускної здатності; але з точки зору # з'єднань воно проходить через нього. Мені цікаво, чи з'єднання UDP якось «зберігаються в живих» на SonicWall; навіть якщо вони (за визначенням) без зв’язку.

Що я тут пропускаю? Що означає SonicWall, коли йдеться про "таймаут з'єднання UDP"?

sonicwall udp

— Джон Уодсворт
джерело

Брандмауери зазвичай дозволяють пакети для з'єднання, встановленого машиною всередині брандмауера. Але UDP не має зв’язків. Таким чином, вибір полягає в тому, щоб дозволити всі пакети UDP, заблокувати всі пакети UDP або спробувати відгадати, що таке "UDP-з'єднання", тому дозволяють лише пакети, які є частиною цих "з'єднань". Усі постачальники брандмауера (?) Використовують останній підхід.

— користувач253751

Як описав іммібіс. Завдяки трансляції мережевих адрес або NAT, маршрутизатор шлюзу для Інтернету / підмережі дозволить лише TCP (практично весь трафік - це TCP), в якому клієнт по підмережі ініціює з'єднання. Тому що немає способу призначити порт для NAT, якщо з'єднання вхідне. Як маршрутизатор знає, кому його надіслати? UDP навіть не має з'єднання, тож як маршрутизатор обробляє запити UDP, що надходять? Один із способів - відстежувати вихідні пакети UDP.

— маршальське ремесло

Якщо ви розміщуєте сервер, вам слід переадресувати порти, на які ви очікуєте отримання з'єднань, але будьте готові до чого завгодно.

— маршальське ремесло

16

Незважаючи на те, що формальної "зв'язку" з UDP не існує, все ще існує умова, що клієнти надсилають запити та очікують отримання відповідей з вихідним IP-адресом та портом, обміненим IP-адресом і портом Destinatoin.

Таким чином, стаціонарні брандмауери та NAT припускають, що пакети із заданою комбінацією вихідного IP / вихідного порту / Порту призначення IP / Порт призначення та відповідної комбінації з заміненим джерелом та пунктом призначення є частиною "з'єднання". Це дозволяє застосовувати до UDP такі правила, як "тільки вихідні з'єднання", і дозволяє застосовувати зворотні переклади до пакетів відповідей.

На жаль, брандмауер або NAT не мають можливості знати, коли клієнт закінчив спілкуватися з сервером. Тож доводиться чекати тайм-ауту, перш ніж видалити запис із своїх таблиць відстеження стану. Це час, який ви встановлюєте.

В принципі, можна було б створити NAT-поле, яке використовувало підхід без громадянства для переадресації портів, зберігаючи при цьому підхідний стан для вихідних з'єднань, але простіше просто використовувати державний NAT для всього, і це звучить так, як це робить ваш постачальник.

На жаль, як ви виявили, це відходи для серверів UDP без стану, які обслуговують велику кількість невеликих запитів. Ви опинитесь в ситуації, коли брандмауер споживає набагато більше ресурсів, ніж сам сервер.

— Пітер Грін
джерело

2

Дякую за чудову відповідь Петро! У моєму випадку SonicWall дозволяє мені зменшити "час очікування з'єднання" UDP за певним правилом брандмауера, тому я зменшу правило NTP-політики до 5 секунд (з 30 за замовчуванням).

— Джон Уодсворт

1

Примітка: Після цього я побачив "загальне з'єднання", як повідомляється зниженням Sonicwall з ~ 1500 до ~ 400. Ідеально! Ще раз дякую за чудову відповідь.

— Джон Уодсворт

1

Майте на увазі, що більшість потокових протоколів використовують UDP, що включає медіа-частину VOIP (після узгодження з використанням SIP). Маючи такий короткий час очікування, це може спричинити проблеми, якщо немає трафіку (наприклад, призупинення дзвінка, вимкнення обох сторін тощо), оскільки не всі телефони VOIP (жорсткі або м'які) чудово підходять для повторного обговорення підключення до медіа, якщо порти відмовляються. . Інші користуються функцією "підтримуйте життя", періодично надсилаючи крихітні сигнали, які можуть бути відстані від 5 секунд.

— Чак ван дер Лінден

11

Ваш брандмауер підтримує таблицю з'єднань для з'єднань UDP. Наприклад, коли ви надсилаєте запит DNS, брандмауер створює запис для цього потоку, щоб відповідь DNS була дозволена назад у вашу мережу. Записи в таблиці очікуються через 30 секунд без активності.

— Рон Трунк
джерело

Спасибі Рон. Чи можете ви прокоментувати цю таблицю підключень щодо вхідних з'єднань? Оскільки мій сервер NTP знаходиться з внутрішньої сторони, насправді не повинно виникати необхідності "тримати двері відкритими" для тих вхідних з'єднань, оскільки мій сервер з внутрішньої сторони завжди може повернутися до джерела (у мене широко відкритий вихідний правила). Дякую за швидку відповідь!

— Джон Уодсворт

3

Таблиця з'єднань будується незалежно від напрямку з'єднання і фактично негайно використовується для пакету відповідей, що повертається з вашого сервера через брандмауер, що повертається до запиту. Брандмауер підтримує кортеж (src ip, src port, dst ip, dst port), щоб асоціювати початковий запит з відповіддю. Оскільки насправді не існує семафору, який би вказував на брандмауер про те, що конкретний сеанс UDP закінчений, а сокет закрив значення часу очікування, закінчується використання.

— rnxrx

2

Ваш NTP-сервер знаходиться позаду вашого NAT (брандмауера). UDP не пов'язаний з точки зору програми та ОС та для більшості мережевих пристроїв.

Однак для вашого брандмауера NAT він записує кожен раз, коли UDP-пакет вимикається, щоб відповідь з іншого кінця в кінцевому підсумку перенаправлялася на той самий комп'ютер у вашій мережі. Вони називаються брандмауером "з'єднання".

Тепер, теоретично, NAT знає, що зовнішній порт буде NTP добре відомим портом, але схоже, що ваш брандмауер не підтримує цього. Якщо це єдине використання для UDP через цей брандмауер, ви можете встановити час очікування підключення до меншої кількості. Крім того, якщо це дозволить вам встановити порт порту програми, ви можете встановити його на менший час (скажімо, 1 секунду) для цього конкретного порту.

— Алан
джерело

1

Час очікування не є специфічним для NAT; будь-який державний брандмауер матиме його.

— user1686

Брандмауер не робить NAT, натомість він намагається фільтрувати пакети, які переходять через NAT, таким чином взаємозв'язок з маршрутизатором і NAT.

— маршальське ремесло

Маршрутизатор для Інтернету повинен використовувати NAT, оскільки будь-який комп'ютер знаходиться в підмережі, тільки маршрутизатор шлюзу має фактичну Інтернет-адресу IP. Було б надзвичайно марно, якби кожен комп'ютер був предметом в Інтернеті. Маршрутизатор шлюзу іноді має велику групу комп'ютерів, які пов'язані з однією Інтернет-IP-адресою. Він використовує веб-розетку Berkly, щоб мати можливість перекладати один на один між вхідними пакетами з Інтернету та комп'ютерами в своїй мережі. Люди, схоже, цього не отримують.

— маршальське ремесло

0

IPv6 не потребує NAT, але все ще здається, що брандмауери є надзвичайними щодо UDP.

— Девід Говард
джерело