Odesílání pošty selhává při připojení VPN: najděte fázi

Pošta, která celé dopoledne fungovala, se zastaví ve chvíli, kdy se zvedne tunel, a prvním instinktem je znovu napsat heslo. Ten instinkt přeskakuje užitečnější otázku: dostal se klient vůbec na server a došel dost daleko, aby nabídl přihlašovací údaje? Časový limit, chyba certifikátu a odpověď s odmítnutím jsou tři různá selhání a jen to třetí se týká účtu. Projděte fáze popořadě a VPN se stane proměnnou, kterou můžete testovat, místo podezřelého, kterého obviňujete.

Krok 1: klasifikujte selhání, než se dotknete přihlašovacích údajů

Přečtěte si chybu, kterou aplikace skutečně vyprodukovala, a zařaďte ji do jednoho ze tří košů. Časový limit nebo reset spojení znamená, že cesta TCP selhala; chyba TLS nebo certifikátu znamená, že cesta fungovala a handshake ne; odpověď SMTP s kódem znamená, že poštovní server odpověděl a rozhodl. Každý koš ukazuje na jiného vlastníka.

Koše stojí za to oddělit, protože opravy si navzájem odporují. Prodlužování časového limitu nepomůže, když server odmítá odesílatele, a změna hesla nic neudělá, když je trasa zablokovaná. Kód odpovědi je nejcennější důkaz v seznamu, protože dokazuje, že celý přenosový řetězec fungoval a problém je v politice nebo identitě. Před dalším pokusem uložte přesný text včetně jakéhokoli rozšířeného stavového kódu.

Zastavte se tady, pokud selhání nedokážete reprodukovat mimo VPN. Problém, který se objeví v jedné aplikaci na jednom počítači, ještě není problém sítě.

Krok 2: ověřte koncový bod a režim TLS

Odesílání zpráv je samostatná služba, ne totéž co přenos mezi servery. Ověřte název hostitele, port a režim TLS podle dokumentace poskytovatele pro odesílání, protože známý port vypůjčený z jiného poštovního nastavení není důkaz. Port 587 očekává pozdrav v čistém textu následovaný STARTTLS, zatímco port 465 očekává TLS od prvního bajtu.

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

Spuštění špatné ze dvou těchto kontrol je přesně chyba, kterou klient dělá, když je nakonfigurován pro druhý režim. Pokud kontrola implicitního TLS na 587 visí nebo kontrola STARTTLS na 465 selže, port a režim si neodpovídají. Opravte režim v klientovi místo vypnutí ověřování certifikátu, které mění konfigurační chybu v neověřené připojení. Rozdělení je dost staré na to, aby bylo standardizované: implicitní TLS na portu 465 je uspořádání popsané v RFC 8314.

Chyba certifikátu je zde informace, ne překážka. Pojmenovává identitu, kterou server předložil, a identitu, kterou klient očekával, a obojí lze opravit bez oslabení spojení.

Krok 3: porovnejte cesty bez změny účtu

Držte koncový bod, účet a nastavení klienta konstantní a změňte pouze cestu. Odešlete jednou se spuštěným tunelem a jednou bez něj a zaznamenejte trasu a zdrojovou adresu, kterou by server viděl. Pokud selhání sleduje cestu, izolovali jste ho; pokud sleduje počítač, ne.

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

Plný tunel mění zdrojovou adresu, kterou poskytovatel vidí, a někteří poskytovatelé se k neznámému zdroji chovají přísněji než k neznámému heslu. Je to jejich politické rozhodnutí a může to být šedý seznam, limit rychlosti nebo blokace. Nezobecňujte od jednoho poskytovatele na všechny a nepředpokládejte, že chybějící pravidlo NAT vysvětluje každé selhání. Záznam curl ukazuje, která fáze selhala, i když vlastní log aplikace ne.

Má-li tunel přenášet internetový provoz, musí jeho směrování i jeho výstupní politika toto cíl povolit. Tunel, který přenáší jen soukromé trasy, nechává poštovní spojení na místní cestě, což je jiné srovnání.

Krok 4: odešlete jednu neškodnou zprávu a zaznamenejte odpověď

Opravte fázi, která selhala, a potom odešlete jednu neškodnou zprávu stejnou aplikací, ne přes stránku webmailu. Testujete vlastní odesílací cestu aplikace, včetně jejích uložených nastavení a režimu TLS. Relace webmailu o tom nic nedokazuje.

Zaznamenejte odpověď, port, režim TLS a cestu, kterou jste použili, aby další člověk mohl výsledek reprodukovat. Fungující prohlížeč a zelená ikona VPN jsou pozorování o jiných věcech. Pokud zpráva dorazí, zbývá udělat z této konfigurace výchozí pro každý počítač, který přes tento účet odesílá.

Kontrolní seznam je hotový, když dokážete pojmenovat fázi, která selhala, port a režim TLS, který klient používá, cestu, kterou zpráva prošla, a odpověď, kterou server vrátil. Tyto čtyři skutečnosti mění mlhavý problém odchozí pošty ve změnu, kterou někdo může zkontrolovat.