Моніторинг 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. Якщо вони працюють ззовні вашої мережі, монітор теж працюватиме.