Изпращането на поща се проваля при свързване на 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 режима, които клиентът използва, пътя, който съобщението е поело, и отговора, който сървърът е върнал. Тези четири факта превръщат смътния проблем с изходящата поща в промяна, която някой може да прегледа.