Отправка почты срывается при подключении VPN: найдите этап

Почта, которая работала всё утро, останавливается в тот момент, когда поднимается туннель, и первый инстинкт — заново ввести пароль. Этот инстинкт пропускает более полезный вопрос: клиент вообще дошёл до сервера и продвинулся ли достаточно далеко, чтобы предложить учётные данные? Тайм-аут, ошибка сертификата и ответ с отказом — три разных сбоя, и только третий касается учётной записи. Пройдите этапы по порядку, и VPN станет переменной, которую можно проверить, а не подозреваемым, которого обвиняют.

Этап 1: классифицируйте сбой, прежде чем трогать учётные данные

Прочитайте ошибку, которую приложение действительно выдало, и поместите её в одну из трёх корзин. Тайм-аут или сброс соединения означает, что путь TCP не сработал; ошибка TLS или сертификата означает, что путь работал, а рукопожатие нет; ответ SMTP с кодом означает, что почтовый сервер ответил и принял решение. Каждая корзина указывает на другого ответственного.

Корзины стоит разделять, потому что исправления противоречат друг другу. Продление тайм-аута не помогает, когда сервер отклоняет отправителя, а смена пароля ничего не даёт, когда маршрут заблокирован. Код ответа — самое ценное доказательство в списке, потому что он подтверждает, что вся транспортная цепочка работала, а проблема в политике или идентичности. Сохраните точный текст, включая любой расширенный код состояния, прежде чем повторять попытку.

Остановитесь здесь, если не можете воспроизвести сбой вне VPN. Проблема, которая проявляется в одном приложении на одной машине, ещё не является проблемой сети.

Этап 2: подтвердите конечную точку и режим TLS

Отправка сообщений — отдельная служба, а не то же самое, что пересылка от сервера к серверу. Подтвердите имя хоста, порт и режим TLS по документации провайдера для отправки, потому что знакомый порт, заимствованный из другой почтовой настройки, не является доказательством. Порт 587 ожидает приветствие открытым текстом и затем STARTTLS, а порт 465 ожидает TLS с первого байта.

openssl s_client -connect smtp.example.com:465 -servername smtp.example.com -quiet
openssl s_client -starttls smtp -connect smtp.example.com:587 -servername smtp.example.com -quiet
nc -vz smtp.example.com 587

Запуск неверной из двух проверок — это именно та ошибка, которую совершает клиент, настроенный на другой режим. Если проверка неявного TLS зависает на 587 или проверка STARTTLS не проходит на 465, порт и режим не совпадают. Исправьте режим в клиенте вместо отключения проверки сертификата, которое превращает ошибку настройки в непроверенное соединение. Это разделение достаточно старо, чтобы быть стандартизированным: неявный TLS на порту 465 — это порядок, описанный в RFC 8314.

Ошибка сертификата здесь — информация, а не препятствие. Она называет удостоверение, которое представил сервер, и удостоверение, которого ожидал клиент, и оба можно исправить, не ослабляя соединение.

Этап 3: сравните пути, не меняя учётную запись

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

ip route get smtp.example.com
curl -v --ssl-reqd --url smtp://smtp.example.com:587 --user "$SMTP_USER" \
  --mail-from [email protected] --mail-rcpt [email protected] --upload-file msg.txt

Полный туннель меняет адрес источника, который видит провайдер, и некоторые провайдеры относятся к незнакомому источнику строже, чем к незнакомому паролю. Это решение на их стороне, и это может быть серый список, ограничение скорости или блокировка. Не обобщайте от одного провайдера на всех и не предполагайте, что отсутствующее правило NAT объясняет каждый сбой. Запись curl показывает, какой этап не сработал, даже когда собственный журнал приложения этого не показывает.

Если туннель должен нести интернет-трафик, и его маршрутизация, и его политика выхода должны разрешать этот пункт назначения. Туннель, который несёт только частные маршруты, оставляет почтовое соединение на локальном пути, а это другое сравнение.

Этап 4: отправьте одно безобидное сообщение и запишите ответ

Исправьте этап, который не сработал, затем отправьте одно безобидное сообщение через то же приложение, а не через страницу веб-почты. Вы проверяете собственный путь отправки приложения, включая его сохранённые настройки и режим TLS. Сеанс веб-почты ничего об этом не доказывает.

Запишите ответ, порт, режим TLS и использованный путь, чтобы следующий человек мог воспроизвести результат. Работающий браузер и зелёный значок VPN — это наблюдения о других вещах. Если сообщение доходит, оставшаяся работа — сделать эту конфигурацию стандартной для каждой машины, которая отправляет через эту учётную запись.

Контрольный список завершён, когда вы можете назвать этап, который не сработал, порт и режим TLS, которые использует клиент, путь, который прошло сообщение, и ответ, который вернул сервер. Эти четыре факта превращают расплывчатую проблему исходящих в изменение, которое кто-то может проверить.