E-posindiening misluk wanneer die VPN koppel: vind die stadium

E-pos wat die hele oggend gewerk het, stop sodra die tonnel opkom, en die eerste instink is om die wagwoord weer in te tik. Daardie instink slaan die nuttiger vraag oor: het die kliënt die bediener hoegenaamd bereik, en het dit ver genoeg gekom om geloofsbriewe aan te bied? ’n Tydverstreke, ’n sertifikaatfout en ’n verwerpingsantwoord is drie verskillende mislukkings, en net die derde betrek die rekening. Werk die stadiums in volgorde deur, dan word die VPN ’n veranderlike wat jy kan toets eerder as ’n verdagte wat jy blameer.

Stap 1: klassifiseer die fout voordat jy geloofsbriewe aanraak

Lees die fout wat die toepassing werklik geproduseer het, en plaas dit dan in een van drie mandjies. ’n Tydverstreke of verbindingsherstel beteken die TCP-roete het gefaal; ’n TLS- of sertifikaatfout beteken die roete het gewerk en die handdruk het nie; ’n SMTP-antwoord met ’n kode beteken ’n e-posbediener het geantwoord en ’n besluit geneem. Elke mandjie wys na ’n ander eienaar.

Die mandjies is die moeite werd om te skei omdat die regstellings mekaar weerspreek. Om ’n tydverstreke te verleng help niks wanneer die bediener die afsender verwerp nie, en om ’n wagwoord te verander doen niks wanneer die roete doodgemaak is nie. ’n Antwoordkode is die waardevolste bewyse in die lys, want dit bewys die hele vervoerketting het gewerk en die probleem is beleid of identiteit. Stoor die presiese teks, insluitend enige uitgebreide statuskode, voordat jy weer probeer.

Stop hier as jy die fout nie buite die VPN kan herproduseer nie. ’n Probleem wat in een toepassing op een masjien verskyn, is nog nie ’n netwerkprobleem nie.

Stap 2: bevestig die eindpunt en die TLS-modus

Boodskapindiening is sy eie diens, nie dieselfde ding as herleiding tussen bedieners nie. Bevestig die gasheernaam, die poort en die TLS-modus uit die verskaffer se dokumentasie vir indiening, want ’n bekende poort wat uit ’n ander e-posopstelling geleen is, is nie bewyse nie. Poort 587 verwag ’n gewone teksgroet gevolg deur STARTTLS, terwyl poort 465 TLS vanaf die eerste greep verwag.

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

Om die verkeerde een van daardie twee ondersoeke te hardloop, is presies die fout wat die kliënt maak wanneer dit vir die ander modus opgestel is. As die implisiete-TLS-ondersoek op 587 hang, of die STARTTLS-ondersoek op 465 misluk, stem die poort en die modus nie ooreen nie. Herstel die modus in die kliënt eerder as om sertifikaatverifikasie te deaktiveer, wat ’n opstellingsfout in ’n ongeverifieerde verbinding omskep. Die skeiding is oud genoeg om gestandaardiseer te wees: implisiete TLS op poort 465 is die reëling wat in RFC 8314 beskryf word.

’n Sertifikaatfout hier is inligting eerder as ’n hindernis. Dit noem die identiteit wat die bediener aangebied het en die identiteit wat die kliënt verwag het, en albei is regstelbaar sonder om die verbinding te verswak.

Stap 3: vergelyk roetes sonder om die rekening te verander

Hou die eindpunt, rekening en kliëntinstellings konstant en verander net die roete. Stuur een keer met die tonnel af en een keer met dit op, en teken die roete en die bronadres aan wat die bediener sou sien. As die mislukking die roete volg, het jy dit geïsoleer; as dit die masjien volg, het jy 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

’n Volle tonnel verander die bronadres wat die verskaffer sien, en sommige verskaffers behandel ’n onbekende bron strenger as ’n onbekende wagwoord. Dit is ’n beleidsbesluit aan hul kant, en dit kan ’n gryslys, ’n tempobeperking of ’n blok wees. Moenie van een verskaffer na almal veralgemeen nie, en moenie aanvaar dat ’n ontbrekende NAT-reël elke mislukking verduidelik nie. Die curl-transkripsie wys watter stadium gefaal het selfs wanneer die toepassing se eie log dit nie doen nie.

As die tonnel veronderstel is om internetverkeer te dra, moet sy roetering en sy uitgangsbeleid albei hierdie bestemming toelaat. ’n Tonnel wat net private roetes dra, laat die e-posverbinding op die plaaslike roete, wat ’n ander vergelyking is.

Stap 4: stuur een skadelose boodskap en teken die antwoord aan

Herstel die stadium wat gefaal het, en dien dan een skadelose boodskap deur dieselfde toepassing in eerder as deur ’n webpos-bladsy. Dit is die toepassing se eie stuurroete wat jy toets, insluitend sy gestoorde instellings en sy TLS-modus. ’n Webpos-sessie bewys niks daaromtrent nie.

Teken die antwoord, die poort, die TLS-modus en die roete wat jy gebruik het aan, sodat die volgende persoon die resultaat kan herproduseer. ’n Werkende blaaier en ’n groen VPN-ikoon is waarnemings oor ander dinge. As die boodskap aankom, is die oorblywende werk om daardie opstelling die verstek te maak vir elke masjien wat deur hierdie rekening stuur.

Die kontrolelys is voltooi wanneer jy die stadium wat gefaal het, die poort en TLS-modus wat die kliënt gebruik, die roete wat die boodskap gevolg het en die antwoord wat die bediener teruggegee het, kan noem. Daardie vier feite verander ’n vae uitboksprobleem in ’n verandering wat iemand kan hersien.