Odosielanie pošty zlyháva pri pripojení VPN: nájdite fázu

Pošta, ktorá fungovala celé ráno, sa zastaví v okamihu, keď sa tunel zdvihne, a prvým inštinktom je znova zadať heslo. Ten inštinkt preskakuje užitočnejšiu otázku: dostal sa klient vôbec na server a zašiel dosť ďaleko, aby ponúkol prihlasovacie údaje? Časový limit, chyba certifikátu a odpoveď s odmietnutím sú tri rôzne zlyhania a len tretie sa týka účtu. Prejdite fázy po poradí a VPN sa stane premennou, ktorú môžete testovať, a nie podozrivým, ktorého obviňujete.

Krok 1: klasifikujte zlyhanie, skôr než sa dotknete prihlasovacích údajov

Prečítajte si chybu, ktorú aplikácia skutočne vyprodukovala, a potom ju umiestnite do jedného z troch košov. Časový limit alebo reset spojenia znamená, že cesta TCP zlyhala; chyba TLS alebo certifikátu znamená, že cesta fungovala a podanie rúk nie; odpoveď SMTP s kódom znamená, že poštový server odpovedal a rozhodol. Každý kôš ukazuje na iného zodpovedného.

Kôše sa oplatí oddeliť, pretože opravy si navzájom odporujú. Predĺženie časového limitu nepomôže, keď server odmieta odosielateľa, a zmena hesla nič neurobí, keď je trasa zablokovaná. Kód odpovede je najcennejší dôkaz v zozname, pretože dokazuje, že celý transportný reťazec fungoval a problém je v politike alebo identite. Pred ďalším pokusom uložte presný text vrátane akéhokoľvek rozšíreného stavového kódu.

Zastavte sa tu, ak nedokážete zlyhanie reprodukovať mimo VPN. Problém, ktorý sa objaví v jednej aplikácii na jednom počítači, ešte nie je problém siete.

Krok 2: potvrďte koncový bod a režim TLS

Odosielanie správ je samostatná služba, nie to isté ako prenos zo servera na server. Potvrďte názov hostiteľa, port a režim TLS podľa dokumentácie poskytovateľa pre odosielanie, pretože známy port požičaný z iného poštového nastavenia nie je dôkaz. Port 587 očakáva pozdrav v čistom texte nasledovaný STARTTLS, zatiaľ čo port 465 očakáva TLS od prvé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

Spustenie nesprávnej z dvoch kontrol je presne tá chyba, ktorú klient robí, keď je nakonfigurovaný pre druhý režim. Ak kontrola implicitného TLS visí na 587 alebo kontrola STARTTLS zlyhá na 465, port a režim si nezodpovedajú. Opravte režim v klientovi namiesto vypnutia overovania certifikátu, ktoré mení konfiguračnú chybu na neoverené pripojenie. Toto rozdelenie je dosť staré na to, aby bolo štandardizované: implicitný TLS na porte 465 je usporiadanie opísané v RFC 8314.

Chyba certifikátu je tu informácia, nie prekážka. Pomenúva identitu, ktorú server predložil, a identitu, ktorú klient očakával, a obe sa dajú opraviť bez oslabenia spojenia.

Krok 3: porovnajte cesty bez zmeny účtu

Držte koncový bod, účet a nastavenia klienta konštantné a zmeňte iba cestu. Odošlite raz so spusteným tunelom a raz bez neho a zaznamenajte trasu a zdrojovú adresu, ktorú by server videl. Ak zlyhanie sleduje cestu, izolovali ste ho; ak sleduje počítač, nie.

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 mení zdrojovú adresu, ktorú poskytovateľ vidí, a niektorí poskytovatelia sa k neznámemu zdroju správajú prísnejšie ako k neznámemu heslu. Je to ich politické rozhodnutie a môže to byť šedý zoznam, limit rýchlosti alebo blokovanie. Nezovšeobecňujte od jedného poskytovateľa na všetkých a nepredpokladajte, že chýbajúce pravidlo NAT vysvetľuje každé zlyhanie. Záznam curl ukazuje, ktorá fáza zlyhala, aj keď vlastný log aplikácie nie.

Ak má tunel prenášať internetovú prevádzku, jeho smerovanie aj jeho výstupná politika musia povoliť tento cieľ. Tunel, ktorý prenáša iba súkromné trasy, necháva poštové spojenie na miestnej ceste, čo je iné porovnanie.

Krok 4: odošlite jednu neškodnú správu a zaznamenajte odpoveď

Opravte fázu, ktorá zlyhala, a potom odošlite jednu neškodnú správu tou istou aplikáciou, nie cez stránku webmailu. Testujete vlastnú odosielaciu cestu aplikácie vrátane jej uložených nastavení a režimu TLS. Relácia webmailu o tom nič nedokazuje.

Zaznamenajte odpoveď, port, režim TLS a cestu, ktorú ste použili, aby ďalší človek mohol výsledok reprodukovať. Fungujúci prehliadač a zelená ikona VPN sú pozorovania o iných veciach. Ak správa dorazí, zostáva urobiť z tejto konfigurácie predvolenú pre každý počítač, ktorý cez tento účet odosiela.

Kontrolný zoznam je hotový, keď dokážete pomenovať fázu, ktorá zlyhala, port a režim TLS, ktorý klient používa, cestu, ktorou správa prešla, a odpoveď, ktorú server vrátil. Tieto štyri skutočnosti menia hmlistý problém odchádzajúcej pošty na zmenu, ktorú môže niekto skontrolovať.