Utsending av e-post feilar når VPN-et koplar til: finn trinnet

E-post som fungerte heile morgonen, stoggar i det augneblinken tunnelen kjem opp, og den første impulsen er å skrive passordet på nytt. Den impulsen hoppar over det meir nyttige spørsmålet: nådde klienten serveren i det heile, og kom han langt nok til å tilby påloggingsinformasjon? Eit tidsavbrot, ein sertifikatfeil og eit avvissvar er tre ulike feil, og berre den tredje gjeld kontoen. Gå gjennom trinna i rekkjefølgje, og VPN-et blir ein variabel du kan teste i staden for ein mistenkt du gjev skulda.

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

Les feilen programmet faktisk produserte, og plasser han i ei av tre bøtter. Eit tidsavbrot eller tilbakestilling av sambandet tyder at TCP-vegen feila; ein TLS- eller sertifikatfeil tyder at vegen verka og handtrykket ikkje; eit SMTP-svar med ein kode tyder at ein e-postserver svara og tok ei avgjerd. Kvar bøtte peikar på ein ulik ansvarleg.

Bøttene er verdt å skilje fordi rettingane motseier kvarandre. Å forlenge eit tidsavbrot hjelper ingenting når serveren avviser avsendararen, og å byte passord gjer ingenting når ruta er blokkert. Ein svarkode er det mest verdifulle provet på lista, fordi han provar at heile transportkjeda verka og at problemet er policy eller identitet. Lagre den nøyaktige teksten, inkludert eventuell utvida statuskode, før du prøver igjen.

Stopp her viss du ikkje kan gjenskape feilen utanfor VPN-et. Eit problem som viser seg i eitt program på éin maskin, er enno ikkje eit nettverksproblem.

Trinn 2: stadfest endepunktet og TLS-modusen

Utsending av meldingar er ei eiga teneste, ikkje det same som videresending frå server til server. Stadfest vertsnamn, port og TLS-modus i dokumentasjonen til leverandøren for utsending, fordi ein kjend port lånt frå eit anna e-oppsett ikkje er prov. Port 587 ventar ei helsing i klartekst etterfølgd av STARTTLS, medan port 465 ventar TLS frå 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

Å køyre den gale av dei to testane er nøyaktig feilen klienten gjer når han er konfigurert for den andre modusen. Viss testen for implisitt TLS heng på 587, eller STARTTLS-testen feilar på 465, stemmer ikkje porten og modusen. Rett modusen i klienten i staden for å slå av sertifikatvalidering, som gjer ein konfigurasjonsfeil om til eit uverifisert samband. Splittinga er gammal nok til å vere standardisert: implisitt TLS på port 465 er ordninga som er skildra i RFC 8314.

Ein sertifikatfeil her er informasjon og ikkje ein hindring. Han namngjev identiteten serveren presenterte og identiteten klienten venta, og begge kan rettast utan å svekkje sambandet.

Trinn 3: samanlikn vegar utan å endre kontoen

Hald endepunkt, konto og klientinnstillingar konstante og endre berre vegen. Send éin gong med tunnelen nede og éin gong med han oppe, og noter ruta og kildeadressa serveren ville sjå. Viss feilen følgjer vegen, har du isolert han; viss han følgjer maskinen, har du ikkje.

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

Ein full tunnel endrar kildeadressa leverandøren ser, og nokre leverandørar behandlar ei ukjend kjelde strengare enn eit ukjent passord. Det er ei policyavgjerd på deira side, og det kan vere ei gråliste, ei fartsgrense eller ei blokkering. Ikkje generaliser frå éin leverandør til alle, og ikkje gå ut frå at ei manglande NAT-regel forklarer kvar feil. curl-utskrifta viser kva trinn som feila, sjølv når eigen logg i programmet ikkje gjer det.

Viss tunnelen skal bere internettrafikk, må både rutinga og utgangspolicyen tillate denne destinasjonen. Ein tunnel som berre ber private ruter, lèt e-postsambandet bli på den lokale vegen, som er ei anna samanlikning.

Trinn 4: send éi uskuldig melding og noter svaret

Rett trinnet som feila, og send deretter éi uskuldig melding gjennom det same programmet i staden for gjennom ei webmail-side. Det er den eigen sendevegen til programmet du testar, inkludert dei lagra innstillingane og TLS-modusen. Ei webmail-økt provar ingenting om det.

Noter svaret, porten, TLS-modusen og vegen du brukte, slik at neste person kan gjenskape resultatet. Ein nettlesar som verkar og eit grønt VPN-ikon er observasjonar om andre ting. Viss meldinga kjem fram, er det attverande arbeidet å gjere den konfigurasjonen til standard for kvar maskin som sender gjennom denne kontoen.

Sjekklista er komplett når du kan namngje trinnet som feila, porten og TLS-modusen klienten brukar, vegen meldinga tok og svaret serveren returnerte. Desse fire fakta gjer eit vagt problem med utboksen om til ei endring nokon kan gå gjennom.