Mailverzending mislukt wanneer de VPN verbindt: vind de fase

Mail die de hele ochtend werkte, stopt op het moment dat de tunnel omhoogkomt, en de eerste reflex is het wachtwoord opnieuw typen. Die reflex slaat de nuttiger vraag over: bereikte de client de server überhaupt, en kwam hij ver genoeg om inloggegevens aan te bieden? Een time-out, een certificaatfout en een afwijzingsantwoord zijn drie verschillende fouten, en alleen de derde betreft het account. Doorloop de fasen in volgorde en de VPN wordt een variabele die u kunt testen in plaats van een verdachte die u de schuld geeft.

Stap 1: classificeer de fout voordat u inloggegevens aanraakt

Lees de fout die de toepassing werkelijk heeft geproduceerd en plaats die in een van drie emmers. Een time-out of een verbindingsreset betekent dat het TCP-pad is mislukt; een TLS- of certificaatfout betekent dat het pad werkte en de handshake niet; een SMTP-antwoord met een code betekent dat een mailserver antwoordde en een beslissing nam. Elke emmer wijst naar een andere verantwoordelijke.

De emmers zijn het scheiden waard, omdat de oplossingen elkaar tegenspreken. Een time-out verlengen helpt niets wanneer de server de afzender weigert, en een wachtwoord wijzigen doet niets wanneer de route geblokkeerd is. Een antwoordcode is het waardevolste bewijs in de lijst, omdat hij aantoont dat de hele transportketen werkte en dat het probleem in beleid of identiteit zit. Bewaar de exacte tekst, inclusief een eventuele uitgebreide statuscode, voordat u het opnieuw probeert.

Stop hier als u de fout buiten de VPN niet kunt reproduceren. Een probleem dat in één toepassing op één machine verschijnt, is nog geen netwerkprobleem.

Stap 2: bevestig het eindpunt en de TLS-modus

Berichtinzending is een eigen dienst, niet hetzelfde als doorsturen van server naar server. Bevestig de hostnaam, de poort en de TLS-modus in de documentatie van de provider voor inzending, want een bekende poort die uit een andere mailconfiguratie is geleend, is geen bewijs. Poort 587 verwacht een begroeting in platte tekst gevolgd door STARTTLS, terwijl poort 465 TLS vanaf de eerste byte verwacht.

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

De verkeerde van de twee tests uitvoeren is precies de fout die de client maakt wanneer hij voor de andere modus is geconfigureerd. Als de test voor impliciete TLS op 587 blijft hangen, of de STARTTLS-test op 465 mislukt, kloppen de poort en de modus niet. Corrigeer de modus in de client in plaats van de certificaatverificatie uit te schakelen, wat een configuratiefout in een niet-geverifieerde verbinding verandert. De splitsing is oud genoeg om gestandaardiseerd te zijn: impliciete TLS op poort 465 is de regeling die in RFC 8314 wordt beschreven.

Een certificaatfout is hier informatie en geen obstakel. Hij noemt de identiteit die de server presenteerde en de identiteit die de client verwachtte, en beide zijn te verhelpen zonder de verbinding te verzwakken.

Stap 3: vergelijk paden zonder het account te wijzigen

Houd het eindpunt, het account en de clientinstellingen constant en wijzig alleen het pad. Verstuur één keer met de tunnel omlaag en één keer met de tunnel omhoog, en noteer de route en het bronadres dat de server zou zien. Als de fout het pad volgt, hebt u hem geïsoleerd; als hij de machine volgt, niet.

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

Een volledige tunnel verandert het bronadres dat de provider ziet, en sommige providers behandelen een onbekende bron strenger dan een onbekend wachtwoord. Dat is een beleidsbeslissing aan hun kant, en het kan een grijze lijst, een snelheidslimiet of een blokkade zijn. Generaliseer niet van één provider naar alle, en ga er niet van uit dat een ontbrekende NAT-regel elke fout verklaart. De curl-transcriptie laat zien welke fase is mislukt, zelfs wanneer het eigen log van de toepassing dat niet doet.

Als de tunnel internetverkeer moet vervoeren, moeten zowel de routering als het uitgaande beleid deze bestemming toestaan. Een tunnel die alleen privéroutes vervoert, laat de mailverbinding op het lokale pad, wat een andere vergelijking is.

Stap 4: verstuur één onschadelijk bericht en noteer het antwoord

Corrigeer de fase die is mislukt en verstuur daarna één onschadelijk bericht via dezelfde toepassing en niet via een webmailpagina. U test het eigen verzendpad van de toepassing, inclusief de opgeslagen instellingen en de TLS-modus. Een webmailsessie bewijst daar niets over.

Noteer het antwoord, de poort, de TLS-modus en het pad dat u gebruikte, zodat de volgende persoon het resultaat kan reproduceren. Een werkende browser en een groen VPN-pictogram zijn waarnemingen over andere dingen. Als het bericht aankomt, is het resterende werk om die configuratie de standaard te maken voor elke machine die via dit account verzendt.

De checklist is compleet wanneer u de mislukte fase, de poort en TLS-modus die de client gebruikt, het pad dat het bericht aflegde en het antwoord dat de server teruggaf kunt benoemen. Die vier feiten veranderen een vaag probleem met de postbus in een wijziging die iemand kan beoordelen.