Pošiljanje pošte spodleti ob povezavi VPN: poiščite stopnjo

Pošta, ki je delovala vse jutro, se ustavi v trenutku, ko se tunel dvigne, in prvi vzgib je znova vnesti geslo. Ta vzgib preskoči bolj koristno vprašanje: ali je odjemalec sploh dosegel strežnik in ali je šel dovolj daleč, da bi ponudil poverilnice? Časovna omejitev, napaka potrdila in odgovor z zavrnitvijo so tri različne napake in le tretja se nanaša na račun. Pojdite skozi stopnje po vrsti in VPN postane spremenljivka, ki jo lahko preizkusite, ne osumljenec, ki ga krivite.

Korak 1: razvrstite napako, preden se dotaknete poverilnic

Preberite napako, ki jo je aplikacija dejansko ustvarila, in jo nato postavite v eno od treh košar. Časovna omejitev ali ponastavitev povezave pomeni, da je pot TCP spodletela; napaka TLS ali potrdila pomeni, da je pot delovala, rokovanje pa ne; odgovor SMTP s kodo pomeni, da je poštni strežnik odgovoril in se odločil. Vsaka košara kaže na drugega odgovornega.

Košare je vredno ločiti, ker si popravki nasprotujejo. Podaljšanje časovne omejitve ne pomaga, ko strežnik zavrača pošiljatelja, in menjava gesla ne naredi ničesar, ko je pot blokirana. Koda odgovora je najdragocenejši dokaz na seznamu, ker dokazuje, da je celotna transportna veriga delovala in da je težava v politiki ali identiteti. Shranite natančno besedilo, vključno z morebitno razširjeno kodo stanja, preden poskusite znova.

Ustavite se tukaj, če napake ne morete ponoviti zunaj VPN. Težava, ki se pojavi v eni aplikaciji na enem računalniku, še ni omrežna težava.

Korak 2: potrdite končno točko in način TLS

Pošiljanje sporočil je samostojna storitev, ne isto kot posredovanje od strežnika do strežnika. Potrdite ime gostitelja, vrata in način TLS v dokumentaciji ponudnika za pošiljanje, ker znana vrata, izposojena iz druge poštne nastavitve, niso dokaz. Vrata 587 pričakujejo pozdrav v čistem besedilu in nato STARTTLS, medtem ko vrata 465 pričakujejo TLS od prvega 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

Izvajanje napačne od dveh preizkusov je natanko napaka, ki jo odjemalec naredi, ko je konfiguriran za drugi način. Če se preizkus implicitnega TLS ustavi na 587 ali preizkus STARTTLS spodleti na 465, se vrata in način ne ujemata. Popravite način v odjemalcu, namesto da izklopite preverjanje potrdila, kar spremeni konfiguracijsko napako v nepreverjeno povezavo. Ta delitev je dovolj stara, da je standardizirana: implicitni TLS na vratih 465 je ureditev, opisana v RFC 8314.

Napaka potrdila je tukaj informacija in ne ovira. Poimenuje identiteto, ki jo je predstavil strežnik, in identiteto, ki jo je pričakoval odjemalec, in obe je mogoče popraviti, ne da bi oslabili povezavo.

Korak 3: primerjajte poti brez spreminjanja računa

Držite končno točko, račun in nastavitve odjemalca nespremenjene in spremenite le pot. Pošljite enkrat s spuščenim tunelom in enkrat z dvignjenim ter zabeležite pot in izvorni naslov, ki bi ga strežnik videl. Če napaka sledi poti, ste jo izolirali; če sledi računalniku, 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

Polni tunel spremeni izvorni naslov, ki ga vidi ponudnik, in nekateri ponudniki do neznanega vira ravnajo strožje kot do neznanega gesla. To je politična odločitev na njihovi strani in je lahko sivi seznam, omejitev hitrosti ali blokada. Ne posplošujte od enega ponudnika na vse in ne domnevajte, da manjkajoče pravilo NAT pojasni vsako napako. Zapis curl pokaže, katera stopnja je spodletela, tudi ko tega ne pokaže dnevnik aplikacije.

Če naj tunel prenaša internetni promet, morata tako njegovo usmerjanje kot njegova izhodna politika dovoliti ta cilj. Tunel, ki prenaša le zasebne poti, pusti poštno povezavo na lokalni poti, kar je druga primerjava.

Korak 4: pošljite eno neškodljivo sporočilo in zabeležite odgovor

Popravite stopnjo, ki je spodletela, in nato pošljite eno neškodljivo sporočilo skozi isto aplikacijo, ne prek strani spletne pošte. Preizkušate lastno pot pošiljanja aplikacije, vključno z njenimi shranjenimi nastavitvami in načinom TLS. Seja spletne pošte o tem ničesar ne dokazuje.

Zabeležite odgovor, vrata, način TLS in pot, ki ste jo uporabili, da lahko naslednja oseba ponovi rezultat. Delujoč brskalnik in zelena ikona VPN so opažanja o drugih stvareh. Če sporočilo prispe, je preostalo delo narediti to konfiguracijo privzeto za vsak računalnik, ki pošilja prek tega računa.

Kontrolni seznam je popoln, ko lahko poimenujete stopnjo, ki je spodletela, vrata in način TLS, ki ju uporablja odjemalec, pot, ki jo je sporočilo opravilo, in odgovor, ki ga je vrnil strežnik. Ta štiri dejstva spremenijo nejasno težavo z odhodno pošto v spremembo, ki jo lahko nekdo pregleda.