Почта встала, а на сервере не было ни одной причины: порты режет панель хостера

Однажды у платформы перестали уходить все письма разом. Диагноз занял полдня — не потому что случай сложный, а потому что сервер был чист.

Что показывал сервер

Всё, что обычно объясняет такой отказ, было в порядке:

• iptables и nftables — пустые;
• политика цепочки OUTPUT — accept;
• ufw неактивен;
• DNS отвечает верно, SPF на месте;
• в журнале почтовой службы — таймаут на соединении, и больше ничего.

Ни одна строка на машине не говорила, что исходящее соединение кто-то рвёт.

Где оно рвалось на самом деле

У сервера в панели хостера был список закрытых портов: 25, 465, 587, 2525 и ещё три. Он применяется на гипервизоре, снимается там же и действует сразу.

Ключевое свойство, ради которого этот разбор и написан: изнутри машины этот список не виден никаким способом. Ни в одной таблице правил, ни в одном журнале, ни в выводе любой диагностической утилиты. С точки зрения сервера пакет ушёл и не вернулся.

Порядок диагностики, который к этому приводит

Мы дошли до панели последним пунктом. Вот порядок, который стоило применить сразу, — он отличает «дропаем мы» от «дропает не наша машина» за пять минут:

1. Проба из контейнера — на каком шаге диалога встало: разрешение имени, установка соединения, TLS, аутентификация.

2. Та же проба с хоста — контейнерная сеть отпадает как причина:

timeout 7 bash -c "</dev/tcp/smtp.example.com/465" && echo открыт || echo молчит

3. tcpdump во время попытки — ключевой шаг:

sudo tcpdump -ni any 'tcp port 465'

Смотреть надо на одну вещь: уходят ли SYN с интерфейса. Если уходят, а ответа нет — дропает не ваша машина. Локально дропнутый пакет до интерфейса не доходит вовсе, и в дампе его не будет. Это тот самый признак, который разворачивает поиск на сто восемьдесят градусов.

4. И только теперь — панель хостера.

Почему это стоит знать заранее

У клиента такой отказ выглядит просто: «ваша платформа не отправляет письма». И ни один лог на сервере не скажет обратного — вы будете смотреть в чистые таблицы правил и искать ошибку у себя.

Тот же список портов бывает у любого провайдера и обычно закрыт по умолчанию: почтовые порты режут против рассылок с угнанных машин. Логика хостера понятна — неприятно то, что она невидима с той стороны, где вы ищете.

Что мы сделали, кроме снятия запрета

Добавили в порядок разбора инцидента шаг «дропает не наша машина» и вынесли tcpdump-признак наверх: он стоит секунд, а отсекает половину гипотез.

И записали правило шире одного случая: когда сервер чист, а соединение не устанавливается, следующий вопрос — не «что ещё на сервере», а «кто между сервером и адресатом». Гипервизор, панель провайдера, сетевой фильтр площадки, маршрут провайдера — всё это невидимо изнутри и всё это ломает соединение так же, как локальное правило.

---

Мы смотрим на клиентские серверы агентом, который сам ходит наружу: открытые порты, обновления, состояние служб — с самой машины, а не снаружи. Разбор такого случая занимает столько же, но начинается с данных, а не с догадки. Как это устроено — Скан сервера.