Что на самом деле означает тайм-аут соединения UDP?

18

Поскольку UDP является протоколом без установления соединения, меня смущает настройка на моем брандмауэре Sonicwall «Тайм-аут соединения UDP». По умолчанию установлено значение 30 секунд, но какой именно тайм-аут после 30 секунд?

Вот моя реальная ситуация: у меня есть NTP-сервер в пуле ntp.org, который обслуживает около 3000 запросов в минуту. Это немного напрягает мой класс SOHO TZ-200 - не с точки зрения пропускной способности; но с точки зрения количества соединений он проходит через него. Мне интересно, поддерживаются ли UDP-соединения на SonicWall; хотя они (по определению) без установления соединения.

Что мне здесь не хватает? Что означает SonicWall, когда говорит о «тайм-ауте UDP-соединения»?

sonicwall udp

— Джон Уодсворт
источник

Межсетевые экраны обычно разрешают пакеты для соединения, которое было установлено машиной внутри межсетевого экрана. Но UDP не имеет соединений. Поэтому выбор состоит в том, чтобы разрешить все пакеты UDP, заблокировать все пакеты UDP или попытаться угадать, что такое «соединения UDP», поэтому разрешать только пакеты, которые являются частью этих «соединений». Все (?) Поставщики брандмауэров используют последний подход.

— user253751 30.12.16

Как описал иммибис. Из-за трансляции сетевых адресов или 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 30.12.16

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

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

Маршрутизатор шлюза в Интернет Должен использовать NAT, потому что любой компьютер находится в подсети, и только маршрутизатор шлюза имеет фактический IP-адрес в Интернете. Было бы очень расточительно, если бы каждый компьютер был в Интернете. Шлюз-маршрутизатор иногда имеет большую группу компьютеров, все из которых связаны с одним интернет-IP-адресом. Он использует Berkly веб-сокет, чтобы иметь возможность преобразовывать один к одному между входящими пакетами из Интернета и компьютерами в своей сети. Люди, кажется, не понимают этого.

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

0

IPv6 не нуждается в NAT, но все равно создается впечатление, что брандмауэры находятся в состоянии по отношению к UDP.

— Дэвид Ховард
источник