UDP-порт «открыт», но сервис молчит: проверяем ответ протокола

В отчёте сетевой проверки написано, что UDP-порт доступен, однако приложение не получает ответ. Привычная логика TCP здесь мешает: у UDP нет установки соединения с подтверждённым рукопожатием. Успешная локальная отправка пакета означает прежде всего то, что операционная система приняла данные для отправки. Сервис на другой стороне может их даже не увидеть.

Проверьте слушатель и транспорт

ss -lunp
ss -ltnp

Сравнение важно, например, для DNS на порту 53. Служба может слушать UDP, TCP или оба транспорта. Запись о TCP-слушателе ничего не сообщает о UDP. Проверьте адрес привязки: внутренний интерфейс, loopback и все интерфейсы создают разные границы доступности.

Показ владельца требует подходящих прав. Отсутствие имени процесса в выводе обычного пользователя не равно отсутствию сокета. Сначала читайте адрес и порт, а владельца уточняйте в рамках разрешённого доступа к серверу. Для UDP состояние UNCONN нормально: оно не описывает неудачную попытку TCP-соединения.

Отправьте понятный службе запрос

dig @192.0.2.53 example.org A +time=2 +tries=1 +notcp
dig @192.0.2.53 example.org A +time=2 +tries=1 +tcp

Подставьте адрес согласованного DNS-сервера. Первый вызов начинает запрос по UDP, второй проверяет TCP. DNS-запрос содержит структуру, на которую служба способна ответить. Случайная строка на порту 53 может быть отброшена исправным сервером, поэтому молчание на такую строку мало полезно.

Увиденный DNS-ответ подтверждает прохождение запроса и ответа для конкретного имени, типа записи и клиента. Статус REFUSED или SERVFAIL отличается от транспортного таймаута: сервер ответил, но отказал в операции либо не смог её выполнить. Сохраните статус и адрес отвечающего сервера. При усечении UDP-ответа dig может повторить запрос по TCP; подробный вывод позволяет это заметить.

Исследуйте обе стороны молчания

Предположим, запрос по TCP вернул адрес, а UDP несколько раз завершился таймаутом. Это направляет проверку к UDP-слушателю и фильтрации именно этого транспорта. Если оба варианта ответили REFUSED, начните с политики DNS: открытие дополнительных сетевых портов не отменит отказ сервера обслуживать клиента.

Проверяйте, попадает ли запрос в разрешённую сеть и возвращается ли ответ по ожидаемому маршруту. UDP не гарантирует доставку и порядок. Один пропавший пакет на загруженной сети не равен постоянной недоступности; несколько одинаковых попыток с зафиксированными параметрами дают более полезную картину.

Для собственного протокола проверка должна знать допустимый запрос, ожидаемый ответ и ограничение времени. Иногда сервис отвечает с другого порта или лишь авторизованным источникам. Эти правила нужно взять из протокола, а не вывести из того, что UDP «не соединяется».

Готовый результат диагностики формулируется конкретно: DNS по TCP отвечает, по UDP от выбранного клиента ответа нет; либо UDP-ответ приходит с отказом политики. По этим вариантам разные владельцы смогут продолжить работу без повторного сбора исходных данных.

Сделайте проверки сервисов осмысленными. В курсе Linux и Bash для DevOps-инженеров предусмотрена диагностика DNS, портов и HTTP. Откройте программу, чтобы научиться проверять полезный результат приложения вместе с доступностью сетевого транспорта.

Ещё по теме

• DNS отвечает на короткие запросы, но ломается на больших: проверьте TCP 53
• CLOSE_WAIT растёт: почему перезапуск сети не закрывает сокеты приложения