Trimiterea poștei eșuează când VPN-ul se conectează: găsiți etapa

Poșta care a funcționat toată dimineața se oprește în momentul în care tunelul urcă, iar primul instinct este să retastezi parola. Acel instinct sare peste întrebarea mai utilă: a ajuns clientul la server și a mers destul de departe pentru a oferi credențiale? Un timeout, o eroare de certificat și un răspuns de respingere sunt trei defecțiuni diferite, iar doar a treia privește contul. Parcurgeți etapele în ordine și VPN-ul devine o variabilă pe care o puteți testa, nu un suspect pe care îl învinuiți.

Etapa 1: clasificați defecțiunea înainte de a atinge credențialele

Citiți eroarea pe care aplicația a produs-o efectiv, apoi plasați-o într-una din trei găleți. Un timeout sau o resetare a conexiunii înseamnă că calea TCP a eșuat; o eroare TLS sau de certificat înseamnă că calea a funcționat, iar strângerea de mână nu; un răspuns SMTP cu cod înseamnă că un server de poștă a răspuns și a luat o decizie. Fiecare găleată indică un responsabil diferit.

Merită să separați gălețile, pentru că remediile se contrazic. Prelungirea unui timeout nu ajută când serverul respinge expeditorul, iar schimbarea parolei nu face nimic când ruta este blocată. Un cod de răspuns este cea mai valoroasă dovadă din listă, pentru că dovedește că întregul lanț de transport a funcționat și că problema ține de politică sau identitate. Salvați textul exact, inclusiv orice cod de stare extins, înainte de a reîncerca.

Opriți-vă aici dacă nu puteți reproduce defecțiunea în afara VPN-ului. O problemă care apare într-o aplicație pe o singură mașină nu este încă o problemă de rețea.

Etapa 2: confirmați punctul final și modul TLS

Trimiterea mesajelor este un serviciu separat, nu același lucru cu retransmisia de la server la server. Confirmați numele de gazdă, portul și modul TLS din documentația furnizorului pentru trimitere, pentru că un port cunoscut împrumutat dintr-o altă configurație de poștă nu este dovadă. Portul 587 așteaptă un salut în text simplu urmat de STARTTLS, în timp ce portul 465 așteaptă TLS din primul octet.

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

Rularea sondei greșite dintre cele două este exact greșeala pe care o face clientul când este configurat pentru celălalt mod. Dacă sonda TLS implicită se blochează pe 587, sau sonda STARTTLS eșuează pe 465, portul și modul nu concordă. Corectați modul în client în loc să dezactivați verificarea certificatului, ceea ce transformă o eroare de configurare într-o conexiune neverificată. Separarea este destul de veche pentru a fi standardizată: TLS implicit pe portul 465 este aranjamentul descris în RFC 8314.

O eroare de certificat aici este informație, nu un obstacol. Ea numește identitatea pe care serverul a prezentat-o și identitatea pe care clientul o aștepta, iar ambele pot fi corectate fără a slăbi conexiunea.

Etapa 3: comparați căile fără a schimba contul

Păstrați punctul final, contul și setările clientului constante și schimbați doar calea. Trimiteți o dată cu tunelul coborât și o dată cu el ridicat, și notați ruta și adresa sursă pe care serverul ar vedea-o. Dacă defecțiunea urmează calea, ați izolat-o; dacă urmează mașina, nu.

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

Un tunel complet schimbă adresa sursă pe care o vede furnizorul, iar unii furnizori tratează o sursă necunoscută mai strict decât o parolă necunoscută. Este o decizie de politică de partea lor și poate fi o listă gri, o limită de rată sau un blocaj. Nu generalizați de la un furnizor la toți și nu presupuneți că o regulă NAT lipsă explică fiecare defecțiune. Transcrierea curl arată care etapă a eșuat chiar și atunci când jurnalul aplicației nu o arată.

Dacă tunelul ar trebui să transporte trafic de internet, atât rutarea, cât și politica de ieșire trebuie să permită această destinație. Un tunel care transportă doar rute private lasă conexiunea de poștă pe calea locală, ceea ce este o altă comparație.

Etapa 4: trimiteți un mesaj inofensiv și notați răspunsul

Corectați etapa care a eșuat, apoi trimiteți un mesaj inofensiv prin aceeași aplicație, nu printr-o pagină de webmail. Ceea ce testați este calea de trimitere a aplicației, inclusiv setările salvate și modul TLS. O sesiune de webmail nu dovedește nimic despre asta.

Notați răspunsul, portul, modul TLS și calea pe care ați folosit-o, ca următoarea persoană să poată reproduce rezultatul. Un browser care funcționează și o pictogramă VPN verde sunt observații despre alte lucruri. Dacă mesajul ajunge, munca rămasă este să faceți acea configurație implicită pentru fiecare mașină care trimite prin acest cont.

Lista de verificare este completă când puteți numi etapa care a eșuat, portul și modul TLS pe care le folosește clientul, calea pe care a mers mesajul și răspunsul pe care l-a returnat serverul. Aceste patru fapte transformă o problemă vagă a cutiei de ieșire într-o schimbare pe care cineva o poate examina.