Utskick av e-post misslyckas när VPN:et ansluter: hitta steget

E-post som fungerade hela morgonen stannar i samma ögonblick som tunneln kommer upp, och den första impulsen är att skriva lösenordet igen. Den impulsen hoppar över den mer användbara frågan: nådde klienten servern överhuvudtaget, och kom den tillräckligt långt för att erbjuda inloggningsuppgifter? En timeout, ett certifikatfel och ett avvisningssvar är tre olika fel, och bara det tredje gäller kontot. Gå igenom stegen i ordning och VPN:et blir en variabel du kan testa i stället för en misstänkt du skyller på.

Steg 1: klassificera felet innan du rör inloggningsuppgifterna

Läs felet som programmet faktiskt producerade och placera det i en av tre hinkar. En timeout eller en återställning av anslutningen betyder att TCP-vägen misslyckades; ett TLS- eller certifikatfel betyder att vägen fungerade och handskakningen inte; ett SMTP-svar med en kod betyder att en e-postserver svarade och fattade ett beslut. Varje hink pekar på en annan ansvarig.

Hinkarna är värda att skilja åt eftersom åtgärderna motsäger varandra. Att förlänga en timeout hjälper ingenting när servern avvisar avsändaren, och att byta lösenord gör ingenting när vägen är blockerad. En svarskod är det mest värdefulla beviset i listan, eftersom den bevisar att hela transportkedjan fungerade och att problemet är policy eller identitet. Spara den exakta texten, inklusive eventuell utökad statuskod, innan du försöker igen.

Stanna här om du inte kan återskapa felet utanför VPN:et. Ett problem som visar sig i ett program på en maskin är ännu inte ett nätverksproblem.

Steg 2: bekräfta slutpunkten och TLS-läget

Utskick av meddelanden är en egen tjänst, inte samma sak som vidarebefordran från server till server. Bekräfta värdnamn, port och TLS-läge i leverantörens dokumentation för utskick, eftersom en välkänd port lånad från en annan e-postinställning inte är bevis. Port 587 förväntar sig en hälsning i klartext följd av STARTTLS, medan port 465 förväntar sig TLS från första byten.

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

Att köra den felaktiga av de två kontrollerna är exakt det misstag klienten gör när den är konfigurerad för det andra läget. Om kontrollen av implicit TLS hänger på 587, eller STARTTLS-kontrollen misslyckas på 465, stämmer inte porten och läget. Rätta läget i klienten i stället för att stänga av certifikatverifieringen, vilket gör ett konfigurationsfel till en overifierad anslutning. Uppdelningen är tillräckligt gammal för att vara standardiserad: implicit TLS på port 465 är det arrangemang som beskrivs i RFC 8314.

Ett certifikatfel här är information och inte ett hinder. Det namnger den identitet som servern presenterade och den identitet som klienten förväntade sig, och båda kan åtgärdas utan att försvaga anslutningen.

Steg 3: jämför vägar utan att ändra kontot

Håll slutpunkt, konto och klientinställningar konstanta och ändra bara vägen. Skicka en gång med tunneln nere och en gång med den uppe, och notera rutten och källadressen som servern skulle se. Om felet följer vägen har du isolerat det; om det följer maskinen, inte.

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

En full tunnel ändrar källadressen som leverantören ser, och vissa leverantörer behandlar en okänd källa strängare än ett okänt lösenord. Det är ett policybeslut på deras sida, och det kan vara en grålista, en hastighetsbegränsning eller en blockering. Generalisera inte från en leverantör till alla, och anta inte att en saknad NAT-regel förklarar varje fel. curl-utskriften visar vilket steg som misslyckades även när programmets egen logg inte gör det.

Om tunneln ska bära internettrafik måste både dess routning och dess utgångspolicy tillåta denna destination. En tunnel som bara bär privata rutter lämnar e-postanslutningen på den lokala vägen, vilket är en annan jämförelse.

Steg 4: skicka ett ofarligt meddelande och notera svaret

Rätta steget som misslyckades och skicka sedan ett ofarligt meddelande genom samma program i stället för genom en webmail-sida. Det är programmets egen sändningsväg du testar, inklusive dess sparade inställningar och TLS-läge. En webmail-session bevisar ingenting om det.

Notera svaret, porten, TLS-läget och vägen du använde, så att nästa person kan återskapa resultatet. En webbläsare som fungerar och en grön VPN-ikon är observationer om andra saker. Om meddelandet kommer fram är det återstående arbetet att göra den konfigurationen till standard för varje maskin som skickar genom detta konto.

Checklistan är komplett när du kan namnge steget som misslyckades, porten och TLS-läget som klienten använder, vägen som meddelandet tog och svaret som servern returnerade. Dessa fyra fakta förvandlar ett vagt problem med utkorgen till en ändring som någon kan granska.