Slanje pošte ne uspijeva kad se VPN poveže: pronađite fazu

Pošta koja je radila cijelo jutro staje u trenutku kad se tunel podigne, a prva pomisao je ponovno upisivanje lozinke. Ta pomisao preskače korisnije pitanje: je li klijent uopće stigao do poslužitelja i je li otišao dovoljno daleko da ponudi vjerodajnice? Istek vremena, pogreška certifikata i odgovor s odbijenicom tri su različita kvara, a samo treći uključuje račun. Prođite faze po redu i VPN postaje varijabla koju možete testirati, a ne osumnjičenik kojeg krivite.

Korak 1: klasificirajte kvar prije nego dirnete vjerodajnice

Pročitajte pogrešku koju je aplikacija stvarno proizvela, zatim je smjestite u jednu od tri košare. Istek vremena ili reset veze znači da je TCP putanja zakazala; TLS ili pogreška certifikata znači da je putanja radila, a rukovanje nije; SMTP odgovor s kodom znači da je poštanski poslužitelj odgovorio i donio odluku. Svaka košara pokazuje na drugog vlasnika.

Košare vrijedi razdvojiti jer se popravci međusobno proturječe. Produljenje isteka vremena ne pomaže kad poslužitelj odbija pošiljatelja, a promjena lozinke ne čini ništa kad je putanja blokirana. Kod odgovora najvrjedniji je dokaz na popisu, jer dokazuje da je cijeli transportni lanac radio i da je problem u politici ili identitetu. Sačuvajte točan tekst, uključujući svaki prošireni statusni kod, prije nego pokušate ponovno.

Zaustavite se ovdje ako kvar ne možete reproducirati izvan VPN-a. Problem koji se pojavljuje u jednoj aplikaciji na jednom računalu još nije mrežni problem.

Korak 2: potvrdite krajnju točku i TLS način rada

Slanje poruka zasebna je usluga, a ne isto što i prijenos od poslužitelja do poslužitelja. Potvrdite naziv hosta, port i TLS način rada iz dokumentacije pružatelja za slanje, jer poznat port posuđen iz drugog poštanskog postava nije dokaz. Port 587 očekuje pozdrav u čistom tekstu nakon kojeg slijedi STARTTLS, dok port 465 očekuje TLS od prvog bajta.

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

Pokretanje pogrešne od dvije provjere upravo je pogreška koju klijent čini kad je konfiguriran za drugi način rada. Ako provjera implicitnog TLS-a zapne na 587, ili provjera STARTTLS-a ne uspije na 465, port i način rada se ne slažu. Popravite način rada u klijentu umjesto da isključite provjeru certifikata, što konfiguracijsku pogrešku pretvara u neprovjerenu vezu. Ta je podjela dovoljno stara da bude standardizirana: implicitni TLS na portu 465 poredak je opisan u RFC 8314.

Pogreška certifikata ovdje je informacija, a ne prepreka. Ona imenuje identitet koji je poslužitelj predstavio i identitet koji je klijent očekivao, a oba se mogu popraviti bez slabljenja veze.

Korak 3: usporedite putanje bez promjene računa

Držite krajnju točku, račun i postavke klijenta stalnima i promijenite samo putanju. Pošaljite jednom s isključenim tunelom i jednom s uključenim te zabilježite rutu i izvornu adresu koju bi poslužitelj vidio. Ako kvar slijedi putanju, izolirali ste ga; ako slijedi računalo, niste.

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

Puni tunel mijenja izvornu adresu koju pružatelj vidi, a neki pružatelji prema nepoznatom izvoru postupaju strože nego prema nepoznatoj lozinci. To je njihova politička odluka i može biti sivi popis, ograničenje brzine ili blokada. Ne generalizirajte s jednog pružatelja na sve i ne pretpostavljajte da nedostajuće NAT pravilo objašnjava svaki kvar. curl zapis pokazuje koja je faza zakazala čak i kad vlastiti dnevnik aplikacije to ne pokazuje.

Ako tunel treba prenositi internetski promet, njegovo usmjeravanje i njegova izlazna politika moraju dopuštati ovo odredište. Tunel koji prenosi samo privatne rute ostavlja poštansku vezu na lokalnoj putanji, što je druga usporedba.

Korak 4: pošaljite jednu bezopasnu poruku i zabilježite odgovor

Popravite fazu koja je zakazala, zatim pošaljite jednu bezopasnu poruku kroz istu aplikaciju, a ne kroz stranicu web-pošte. Ono što testirate jest vlastita putanja slanja aplikacije, uključujući njezine spremljene postavke i TLS način rada. Sesija web-pošte o tome ne dokazuje ništa.

Zabilježite odgovor, port, TLS način rada i putanju koju ste koristili, kako bi sljedeća osoba mogla reproducirati rezultat. Radni preglednik i zelena VPN ikona zapažanja su o drugim stvarima. Ako poruka stigne, preostaje učiniti tu konfiguraciju zadanim za svako računalo koje šalje kroz ovaj račun.

Popis je dovršen kad možete navesti fazu koja je zakazala, port i TLS način rada koje klijent koristi, putanju koju je poruka prošla i odgovor koji je poslužitelj vratio. Te četiri činjenice pretvaraju nejasan problem odlazne pošte u promjenu koju netko može pregledati.