Надсилання пошти зривається під час підключення 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, які використовує клієнт, шлях, який пройшло повідомлення, і відповідь, яку повернув сервер. Ці чотири факти перетворюють розпливчасту проблему вихідних на зміну, яку хтось може переглянути.