Мониторинг TCP-портов для баз данных, почтовых серверов и SSH

Что доказывает завершённое рукопожатие

Монитор порта подключается к host:port по TCP и считает проверку успешной, как только завершается трёхэтапное рукопожатие. Затраченное на это время сохраняется как время ответа, а сокет сразу закрывается без отправки данных. Это доказательство того, что что-то приняло соединение, и не более. Оно не доказывает, что служба за портом здорова, что аутентификация работает или что запрос вернёт строки. База данных, которая принимает соединения, но зависает на каждом запросе, эту проверку всё равно проходит.

Учтите, что балансировщики нагрузки, обратные прокси и некоторые CDN принимают соединения вместо бэкенда, который может быть мёртв. Если порт, который вы проверяете, заканчивается на прокси, монитор расскажет вам о прокси. Проверяйте порт на настоящей машине, когда хотите знать о настоящей машине.

Отклонено, таймаут или не найдено

Сообщение о сбое само по себе инструмент диагностики:

• «Connection refused»: хост жив и доступен, но на этом порту никто не слушает. Служба упала или остановлена.
• «Timeout after 10 s connecting to host:port»: пакеты исчезают. Их отбрасывает файрвол, хост выключен или маршрут нарушен. Это же вы увидите, когда изменилась группа безопасности и забыли разрешить проверяющие серверы.
• «DNS lookup failed»: имя не резолвится со стороны проверяющего сервера, так что смотрите на свои записи, прежде чем на сервер.
• «Connection reset» или сообщения о недоступности: устройство на пути активно отклоняет соединение или не имеет маршрута.

Какие порты действительно отслеживают

Почта: 25, 465 и 587 для SMTP, 993 для IMAP, 995 для POP. Почтовый сервер, который перестал слушать, для пользователей даёт тишину, а не ошибки, так что часто это единственное предупреждение. Удалённый доступ: 22 для SSH, 3389 для RDP. Базы данных и кеши: 3306 для MySQL, 5432 для PostgreSQL, 6379 для Redis, 27017 для MongoDB, но прежде чем открывать их, прочитайте следующий раздел. Игры с TCP-слушателем, например Minecraft Java на 25565, тоже хорошо подходят. Для всего, что работает по UDP, пользуйтесь монитором UDP.

Никогда не открывайте базу данных всему миру ради монитора

Монитор должен достучаться до порта из публичного интернета, и это соблазняет выставить базу данных или кеш для всех. Не делайте этого. Ограничьте правило адресами из списка IP-адресов проверяющих серверов, которые опубликованы именно для этого; правило файрвола, пропускающее только эти адреса, оставляет порт закрытым для остальных. Если и это слишком много, отслеживайте служебный URL самого приложения, который проверяет базу данных изнутри, а проверку порта применяйте только к службам, публичным по замыслу, например почта и SSH.

Список IP может меняться при добавлении регионов, поэтому подпишитесь на его обновления или пересмотрите правило, когда увидите необъяснимые таймауты. Полезная привычка — называть правило файрвола по имени монитора, чтобы тот, кто будет наводить порядок в правилах в следующем году, знал: удаление отключит проверку, а не просто почистит список. Для SSH отдельно: ограниченный источник в правиле плюс вход только по ключу держат уязвимость небольшой.

Таймауты, интервалы и TLS-порты

Таймаут по умолчанию — 30 секунд, но TCP-рукопожатие, которое занимает больше 5–10, уже является симптомом, так что большинству мониторов портов подойдёт значение короче. Интервалы зависят от тарифа: 5 мин на Free, 1 мин на Starter, 30 с на Pro и Agency. Мониторинг портов доступен на всех тарифах.

На порту, который оборачивает трафик в TLS, например 465 или 993, обычная проверка показывает лишь то, что слушатель существует. Добавьте монитор SSL с тем же портом, чтобы проверить сертификат. В TCP-мониторе нет функции «отправить и ожидать», так что проверить баннер или диалог протокола не получится; используйте монитор HTTP или ключевых слов там, где у службы есть веб-интерфейс.