Mailafsendelse fejler, når VPN’et forbinder: find trinnet

Mail, der virkede hele morgenen, stopper i det øjeblik, tunnelen kommer op, og den første indskydelse er at skrive adgangskoden igen. Den indskydelse springer det mere nyttige spørgsmål over: nåede klienten overhovedet serveren, og kom den langt nok til at tilbyde loginoplysninger? En timeout, en certifikatfejl og et afvisningssvar er tre forskellige fejl, og kun den tredje handler om kontoen. Gå trinnene igennem i rækkefølge, og VPN bliver en variabel, du kan teste, i stedet for en mistænkt, du giver skylden.

Trin 1: klassificér fejlen, før du rører loginoplysningerne

Læs den fejl, programmet faktisk producerede, og placer den i en af tre spande. En timeout eller nulstilling af forbindelsen betyder, at TCP-vejen fejlede; en TLS- eller certifikatfejl betyder, at vejen virkede, og håndtrykket ikke; et SMTP-svar med en kode betyder, at en mailserver svarede og traf en beslutning. Hver spand peger på en forskellig ejer.

Spandene er værd at skille ad, fordi rettelserne modsiger hinanden. At forlænge en timeout hjælper intet, når serveren afviser afsenderen, og at skifte adgangskode gør intet, når ruten er blokeret. En svarkode er det mest værdifulde bevis på listen, fordi den beviser, at hele transportkæden virkede, og at problemet er politik eller identitet. Gem den præcise tekst, inklusive enhver udvidet statuskode, før du prøver igen.

Stop her, hvis du ikke kan genskabe fejlen uden for VPN’et. Et problem, der viser sig i ét program på én maskine, er endnu ikke et netværksproblem.

Trin 2: bekræft endepunktet og TLS-tilstanden

Aflevering af meddelelser er sin egen tjeneste, ikke det samme som videresendelse fra server til server. Bekræft værtsnavn, port og TLS-tilstand i udbyderens dokumentation for aflevering, fordi en velkendt port lånt fra et andet mailopsætning ikke er bevis. Port 587 forventer en hilsen i klartekst efterfulgt af STARTTLS, mens port 465 forventer TLS fra den første byte.

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

At køre den forkerte af de to undersøgelser er præcis den fejl, klienten laver, når den er konfigureret til den anden tilstand. Hvis undersøgelsen af implicit TLS hænger på 587, eller STARTTLS-undersøgelsen fejler på 465, er porten og tilstanden uenige. Ret tilstanden i klienten i stedet for at deaktivere certifikatvalidering, hvilket gør en konfigurationsfejl til en uverificeret forbindelse. Opdelingen er gammel nok til at være standardiseret: implicit TLS på port 465 er den ordning, der er beskrevet i RFC 8314.

En certifikatfejl her er information snarere end en forhindring. Den navngiver den identitet, serveren præsenterede, og den identitet, klienten forventede, og begge kan rettes uden at svække forbindelsen.

Trin 3: sammenlign veje uden at ændre kontoen

Hold endepunkt, konto og klientindstillinger konstante, og skift kun vejen. Send én gang med tunnelen nede og én gang med den oppe, og notér ruten og kildeadressen, som serveren ville se. Hvis fejlen følger vejen, har du isoleret den; hvis den følger maskinen, har du ikke.

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 fuld tunnel ændrer den kildeadresse, udbyderen ser, og nogle udbydere behandler en ukendt kilde strengere end en ukendt adgangskode. Det er en politisk beslutning på deres side, og det kan være en gråliste, en hastighedsgrænse eller en blokering. Generalisér ikke fra én udbyder til alle, og antag ikke, at en manglende NAT-regel forklarer enhver fejl. Curl-udskriften viser, hvilket trin der fejlede, selv når programmets egen log ikke gør det.

Hvis tunnelen skal bære internettrafik, skal både dens routing og dens udgangspolitik tillade denne destination. En tunnel, der kun bærer private ruter, efterlader mailforbindelsen på den lokale vej, hvilket er en anden sammenligning.

Trin 4: send én uskadelig meddelelse og notér svaret

Ret det trin, der fejlede, og send derefter én uskadelig meddelelse gennem det samme program i stedet for gennem en webmail-side. Det er programmets egen sendvej, du tester, inklusive dets gemte indstillinger og dets TLS-tilstand. En webmail-session beviser intet om det.

Notér svaret, porten, TLS-tilstanden og den vej, du brugte, så den næste person kan genskabe resultatet. En browser, der virker, og et grønt VPN-ikon er observationer om andre ting. Hvis meddelelsen ankommer, er det resterende arbejde at gøre den konfiguration til standard for hver maskine, der sender gennem denne konto.

Tjeklisten er komplet, når du kan navngive det trin, der fejlede, den port og TLS-tilstand, klienten bruger, den vej, meddelelsen tog, og det svar, serveren returnerede. De fire fakta forvandler et vagt problem med udbakken til en ændring, som nogen kan gennemgå.