Meili saatmine ebaõnnestub VPN-i ühendamisel: leidke etapp

Meil, mis oli kogu hommiku töötanud, peatub hetkel, kui tunnel üles tuleb, ja esimene tung on parool uuesti sisestada. See tung jätab vahele kasulikuma küsimuse: kas klient jõudis üldse serverini ja läks piisavalt kaugele, et volitusi pakkuda? Aegumine, sertifikaadiviga ja keeldumisvastus on kolm eri riket ning ainult kolmas puudutab kontot. Käige etapid järjekorras läbi ja VPN muutub muutujaks, mida saate testida, mitte süüdlaseks, keda süüdistada.

Samm 1: liigitage rike enne volituste puudutamist

Lugege viga, mille rakendus tegelikult tekitas, ja asetage see ühte kolmest korvist. Aegumine või ühenduse lähtestamine tähendab, et TCP-tee ebaõnnestus; TLS-i või sertifikaadi viga tähendab, et tee töötas ja käepigistus mitte; SMTP vastus koodiga tähendab, et meiliserver vastas ja tegi otsuse. Iga korv osutab eri vastutajale.

Korve tasub eraldada, sest parandused on vastuolus. Aegumise pikendamine ei aita, kui server saatjat tagasi lükkab, ja parooli muutmine ei tee midagi, kui marsruut on blokeeritud. Vastusekood on nimekirja kõige väärtuslikum tõend, sest see tõestab, et kogu transpordiahel töötas ja probleem on poliitikas või identiteedis. Salvestage täpne tekst, sealhulgas mis tahes laiendatud olekukood, enne uuesti proovimist.

Peatuge siin, kui te ei saa riket väljaspool VPN-i korrata. Probleem, mis ilmneb ühes rakenduses ühes masinas, ei ole veel võrguprobleem.

Samm 2: kinnitage lõpp-punkt ja TLS-i režiim

Sõnumite saatmine on omaette teenus, mitte sama asi kui serverist serverisse edastamine. Kinnitage hostinimi, port ja TLS-i režiim teenusepakkuja saatmise dokumentatsioonist, sest teisest meililahendusest laenatud tuttav port ei ole tõend. Port 587 ootab lihtteksti tervitust, millele järgneb STARTTLS, samas kui port 465 ootab TLS-i alates esimesest baidist.

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

Kahest kontrollist vale käivitamine on täpselt see viga, mille klient teeb, kui see on seadistatud teise režiimi jaoks. Kui implitsiitse TLS-i kontroll takerdub pordil 587 või STARTTLS-i kontroll ebaõnnestub pordil 465, ei ole port ja režiim kooskõlas. Parandage režiim kliendis, selle asemel et sertifikaadi kontrollimine välja lülitada, mis muudab seadistusvea kontrollimata ühenduseks. See jaotus on piisavalt vana, et olla standardiseeritud: implitsiitne TLS pordil 465 on korraldus, mida kirjeldatakse dokumendis RFC 8314.

Sertifikaadiviga on siin informatsioon, mitte takistus. See nimetab identiteedi, mille server esitas, ja identiteedi, mida klient ootas, ning mõlemat saab parandada ühendust nõrgendamata.

Samm 3: võrrelge teid kontot muutmata

Hoidke lõpp-punkt, konto ja kliendi seaded muutumatuna ning muutke ainult teed. Saatke üks kord allalastud tunneliga ja üks kord üleslastud tunneliga ning kirjutage üles marsruut ja lähteaadress, mida server näeks. Kui rike järgib teed, olete selle isoleerinud; kui see järgib masinat, siis mitte.

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

Täistunnel muudab lähteaadressi, mida teenusepakkuja näeb, ja mõned pakkujad kohtlevad tundmatut allikat rangemalt kui tundmatut parooli. See on nende poolel poliitikaotsus ja see võib olla hall nimekiri, kiiruspiirang või blokeering. Ärge üldistage ühelt pakkujalt kõigile ega eeldage, et puuduv NAT-reegel selgitab iga riket. curl-i logi näitab, milline etapp ebaõnnestus, isegi kui rakenduse enda logi seda ei näita.

Kui tunnel peaks kandma internetiliiklust, peavad nii selle marsruutimine kui ka väljundpoliitika seda sihtkohta lubama. Tunnel, mis kannab ainult privaatseid marsruute, jätab meiliühenduse kohalikule teele, mis on teine võrdlus.

Samm 4: saatke üks kahjutu sõnum ja kirjutage vastus üles

Parandage etapp, mis ebaõnnestus, ja saatke seejärel üks kahjutu sõnum sama rakenduse kaudu, mitte veebimeili lehe kaudu. Testite rakenduse enda saatmisteid, sealhulgas selle salvestatud seadeid ja TLS-i režiimi. Veebimeili sessioon ei tõesta selle kohta midagi.

Kirjutage üles vastus, port, TLS-i režiim ja teie kasutatud tee, et järgmine inimene saaks tulemust korrata. Töötav brauser ja roheline VPN-i ikoon on tähelepanekud muude asjade kohta. Kui sõnum kohale jõuab, on ülejäänud töö teha see seadistus vaikeväärtuseks iga masina jaoks, mis selle konto kaudu saadab.

Kontroll-loend on täielik, kui suudate nimetada etapi, mis ebaõnnestus, kliendi kasutatava pordi ja TLS-i režiimi, tee, mille sõnum läbis, ja vastuse, mille server tagastas. Need neli fakti muudavad ebamäärase väljundpostkasti probleemi muudatuseks, mida keegi saab üle vaadata.