Мониторинг UDP для DNS, NTP и других служб, которые отвечают на датаграммы

UDP по умолчанию молчит

У TCP есть рукопожатие, поэтому «соединено» — чёткий сигнал. У UDP ничего подобного нет: датаграмма уходит, и если служба не решит ответить, обратно не приходит ничего. Поэтому у монитора только один положительный сигнал, ответ, и два неоднозначных результата. UDP-монитор Tenium отправляет с проверяющего сервера одну пробную датаграмму, ждёт таймаута и классифицирует, что произошло. Он честен в том, что это может доказать, и эта страница так же честна в отношении служб, которые он покрыть не в состоянии.

Три возможных результата

Каждая UDP-проверка заканчивается одним из таких состояний:

• Датаграмма вернулась до таймаута: всё в порядке. Время ответа — это сколько она шла, а размер ответа сохраняется в деталях. Содержимое не анализируется.
• Целевой хост ответил ICMP «port unreachable»: проверка сразу завершается ошибкой «UDP port closed». Это единственный отрицательный сигнал, который даёт UDP, и приходит он быстро.
• До таймаута ничего не пришло: сбой после ожидания. Тишину не отличить от потерянного пакета, файрвола или службы, которая игнорирует неизвестные данные, поэтому её считают недоступностью. Настроенный вами таймаут ограничен 15 секундами.

Пробы: настоящие DNS и NTP и вежливый стук для остальных

Tenium выбирает содержимое по порту. На 53 он отправляет стандартный DNS-запрос на A-запись example.com, поэтому рабочий резолвер или авторитетный сервер отвечает; даже ответ REFUSED считается доказательством жизни. На 123 отправляется 48-байтовый клиентский запрос NTP, на который отвечает любой сервер NTP. На 161 уходит короткая текстовая строка, которая не является корректным запросом SNMP, а на любой другой порт — CRLF-датаграмма. Задать собственное содержимое запроса или проверить ответ по ожидаемой строке нельзя.

Это настоящее ограничение, и оно определяет, где монитор уместен. Он отлично подходит для двух протоколов выше и для любой службы, которая отвечает на произвольные данные или отклоняет их. И плохо подходит для протоколов, которые требуют точного рукопожатия, прежде чем скажут хоть слово.

Службы, которые будут выглядеть недоступными, даже когда здоровы

Несколько хорошо известных UDP-служб устроены так, чтобы не отвечать чужим. WireGuard игнорирует любой пакет, который не является корректным аутентифицированным рукопожатием, и это функция безопасности. Конфигурации OpenVPN с TLS-аутентификацией так же отбрасывают неаутентифицированные пакеты. Приёмники syslog на порту 514 только слушают. Игровые серверы обычно ждут запрос в собственном формате: игры на движке Source хотят конкретный информационный запрос, Minecraft Bedrock — RakNet-ping, голосовые серверы — свой протокол. Агенты SNMP отбрасывают пакеты, которые не являются корректным SNMP, а общая проба таким не является. QUIC на 443 ожидает настоящего начального пакета.

Не добавляйте такие службы как UDP-мониторы, а потом не удивляйтесь постоянному красному. Воспользуйтесь альтернативами ниже.

Лучшие варианты для молчаливых служб

Надёжный подход — следить изнутри наружу. Для эндпоинта WireGuard запустите на клиенте небольшой скрипт, который проверяет время последнего рукопожатия и вызывает URL cron-heartbeat только тогда, когда туннель здоров; если пинги прекратятся, вас оповестят. Для сборщика syslog ежеминутное задание, которое проверяет, вырос ли лог-файл за последние пять минут, и вызывает heartbeat, выявит мёртвый приёмник. Многие игровые серверы открывают TCP-запрос, порт RCON, веб-страницу статуса или плагин, сообщающий число игроков; пользуйтесь для этого монитором порта или монитором ключевых слов. Во всех случаях ping-монитор на хосте покрывает саму машину.

Файрволы, тарифы и проверка

Разрешите входящий UDP с адресов из списка IP-адресов проверяющих серверов на порт, который вы отслеживаете. Файрволы с учётом состояния обрабатывают ответ автоматически. Частные адреса отклоняются ещё до отправки пакета. Мониторинг UDP начинается с тарифа Starter и считается одним монитором в вашем лимите: 100, 300 или 1000.

Одна особенность: кнопка «тестовая проверка» в редакторе для UDP-мониторов отключена, так что сначала сохраните монитор и посмотрите первый результат на его странице. Если первый запуск говорит «No UDP reply», попробуйте ту же пробу из оболочки, чтобы убедиться, что служба вообще отвечает: dig @your-resolver example.com A для порта 53 или ntpdate -q host для порта 123. Если они работают снаружи вашей сети, монитор тоже будет работать.