Utsending av e-post feiler når VPN-et kobler til: finn trinnet

E-post som fungerte hele morgenen, stopper i det øyeblikket tunnelen kommer opp, og den første impulsen er å skrive passordet på nytt. Den impulsen hopper over det mer nyttige spørsmålet: nådde klienten serveren i det hele tatt, og kom den langt nok til å tilby påloggingsinformasjon? En tidsavbrudd, en sertifikatfeil og et avvisningssvar er tre ulike feil, og bare den tredje gjelder kontoen. Gå gjennom trinnene i rekkefølge, og VPN-et blir en variabel du kan teste i stedet for en mistenkt du gir skylden.

Trinn 1: klassifiser feilen før du rører påloggingsinformasjon

Les feilen programmet faktisk produserte, og plasser den i en av tre bøtter. En tidsavbrudd eller tilbakestilling av forbindelsen betyr at TCP-veien feilet; en TLS- eller sertifikatfeil betyr at veien virket og håndtrykket ikke; et SMTP-svar med en kode betyr at en e-postserver svarte og tok en beslutning. Hver bøtte peker på en ulik ansvarlig.

Bøttene er verdt å skille fordi rettelsene motsier hverandre. Å forlenge en tidsavbrudd hjelper ingenting når serveren avviser avsenderen, og å bytte passord gjør ingenting når ruten er blokkert. En svarkode er det mest verdifulle beviset på listen, fordi den beviser at hele transportkjeden virket og at problemet er policy eller identitet. Lagre den nøyaktige teksten, inkludert eventuell utvidet statuskode, før du prøver igjen.

Stopp her hvis du ikke kan gjenskape feilen utenfor VPN-et. Et problem som vises i ett program på én maskin, er ennå ikke et nettverksproblem.

Trinn 2: bekreft endepunktet og TLS-modusen

Utsending av meldinger er en egen tjeneste, ikke det samme som videresending fra server til server. Bekreft vertsnavn, port og TLS-modus i leverandørens dokumentasjon for utsending, fordi en kjent port lånt fra et annet e-oppsett ikke er bevis. Port 587 forventer en hilsen i klartekst etterfulgt av STARTTLS, mens port 465 forventer TLS fra 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

Å kjøre den gale av de to testene er nøyaktig feilen klienten gjør når den er konfigurert for den andre modusen. Hvis testen for implisitt TLS henger på 587, eller STARTTLS-testen feiler på 465, stemmer ikke porten og modusen. Rett modusen i klienten i stedet for å deaktivere sertifikatvalidering, som gjør en konfigurasjonsfeil om til en uverifisert forbindelse. Splittelsen er gammel nok til å være standardisert: implisitt TLS på port 465 er ordningen som er beskrevet i RFC 8314.

En sertifikatfeil her er informasjon og ikke en hindring. Den navngir identiteten serveren presenterte og identiteten klienten forventet, og begge kan rettes uten å svekke forbindelsen.

Trinn 3: sammenlign veier uten å endre kontoen

Hold endepunkt, konto og klientinnstillinger konstante og endre bare veien. Send én gang med tunnelen nede og én gang med den oppe, og noter ruten og kildeadressen serveren ville se. Hvis feilen følger veien, har du isolert 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 full tunnel endrer kildeadressen leverandøren ser, og noen leverandører behandler en ukjent kilde strengere enn et ukjent passord. Det er en policybeslutning på deres side, og det kan være en gråliste, en hastighetsbegrensning eller en blokkering. Ikke generaliser fra én leverandør til alle, og ikke anta at en manglende NAT-regel forklarer hver feil. curl-utskriften viser hvilket trinn som feilet, selv når programmets egen logg ikke gjør det.

Hvis tunnelen skal bære internettrafikk, må både rutingen og utgangspolicyen tillate denne destinasjonen. En tunnel som bare bærer private ruter, lar e-postforbindelsen bli på den lokale veien, som er en annen sammenligning.

Trinn 4: send én uskyldig melding og noter svaret

Rett trinnet som feilet, og send deretter én uskyldig melding gjennom det samme programmet i stedet for gjennom en webmail-side. Det er programmets egen sendevei du tester, inkludert de lagrede innstillingene og TLS-modusen. En webmail-økt beviser ingenting om det.

Noter svaret, porten, TLS-modusen og veien du brukte, slik at neste person kan gjenskape resultatet. En nettleser som virker og et grønt VPN-ikon er observasjoner om andre ting. Hvis meldingen kommer frem, er det resterende arbeidet å gjøre den konfigurasjonen til standard for hver maskin som sender gjennom denne kontoen.

Sjekklisten er komplett når du kan navngi trinnet som feilet, porten og TLS-modusen klienten bruker, veien meldingen tok og svaret serveren returnerte. Disse fire fakta gjør et vagt problem med utboksen om til en endring noen kan gjennomgå.