Siunčiant paštą nepavyksta, kai prisijungia VPN: raskite etapą

Paštas, kuris veikė visą rytą, sustoja tą akimirką, kai tunelis pakyla, ir pirmas instinktas yra iš naujo įvesti slaptažodį. Šis instinktas praleidžia naudingesnį klausimą: ar klientas apskritai pasiekė serverį ir ar nuėjo pakankamai toli, kad pasiūlytų prisijungimo duomenis? Skirtasis laikas, sertifikato klaida ir atmetimo atsakymas yra trys skirtingi gedimai, ir tik trečiasis susijęs su paskyra. Pereikite etapus iš eilės ir VPN taps kintamuoju, kurį galite išbandyti, o ne įtariamuoju, kuriuo kaltinate.

1 žingsnis: klasifikuokite gedimą prieš liesdami prisijungimo duomenis

Perskaitykite klaidą, kurią programa iš tikrųjų sukūrė, tada įdėkite ją į vieną iš trijų krepšių. Skirtasis laikas arba ryšio atstatymas reiškia, kad TCP kelias nepavyko; TLS arba sertifikato klaida reiškia, kad kelias veikė, o rankos paspaudimas ne; SMTP atsakymas su kodu reiškia, kad pašto serveris atsakė ir priėmė sprendimą. Kiekvienas krepšys nurodo kitą atsakingą asmenį.

Krepšius verta atskirti, nes pataisymai prieštarauja vienas kitam. Pratęsti skirtąjį laiką nepadės, kai serveris atmeta siuntėją, o slaptažodžio keitimas nieko nepadarys, kai kelias užblokuotas. Atsakymo kodas yra vertingiausias įrodymas sąraše, nes jis įrodo, kad visa transportavimo grandinė veikė ir problema yra politikoje arba tapatybėje. Išsaugokite tikslų tekstą, įskaitant bet kurį išplėstinį būsenos kodą, prieš bandydami dar kartą.

Sustokite čia, jei negalite atkurti gedimo už VPN ribų. Problema, pasireiškianti vienoje programoje viename kompiuteryje, dar nėra tinklo problema.

2 žingsnis: patvirtinkite galinį tašką ir TLS režimą

Pranešimų siuntimas yra atskira paslauga, o ne tas pats, kas perdavimas iš serverio į serverį. Patvirtinkite pagrindinio kompiuterio vardą, prievadą ir TLS režimą iš teikėjo siuntimo dokumentacijos, nes pažįstamas prievadas, pasiskolintas iš kitos pašto konfigūracijos, nėra įrodymas. 587 prievadas tikisi paprasto teksto pasveikinimo ir po jo STARTTLS, o 465 prievadas tikisi TLS nuo pirmo baito.

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

Paleisti neteisingą iš dviejų patikrų yra būtent ta klaida, kurią klientas daro, kai yra sukonfigūruotas kitam režimui. Jei implicitinio TLS patikra užstringa ties 587, arba STARTTLS patikra nepavyksta ties 465, prievadas ir režimas nesutampa. Ištaisykite režimą kliente, o ne išjunkite sertifikato tikrinimą, kuris konfigūracijos klaidą paverčia nepatikrintu ryšiu. Šis atskyrimas yra pakankamai senas, kad būtų standartizuotas: implicitinis TLS 465 prievade yra tvarka, aprašyta RFC 8314.

Sertifikato klaida čia yra informacija, o ne kliūtis. Ji įvardija tapatybę, kurią pateikė serveris, ir tapatybę, kurios tikėjosi klientas, ir abi galima ištaisyti nesusilpninant ryšio.

3 žingsnis: palyginkite kelius nekeisdami paskyros

Laikykite galinį tašką, paskyrą ir kliento nustatymus pastovius ir keiskite tik kelią. Siųskite vieną kartą su nuleistu tuneliu ir vieną kartą su pakeltu, ir užrašykite maršrutą bei šaltinio adresą, kurį serveris matytų. Jei gedimas seka kelią, jūs jį izoliavote; jei seka kompiuterį, ne.

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

Visas tunelis pakeičia šaltinio adresą, kurį mato teikėjas, ir kai kurie teikėjai nepažįstamą šaltinį vertina griežčiau nei nepažįstamą slaptažodį. Tai jų pusės politikos sprendimas, ir tai gali būti pilkas sąrašas, greičio ribojimas arba blokavimas. Negeneralizuokite nuo vieno teikėjo visiems ir nemanykite, kad trūkstama NAT taisyklė paaiškina kiekvieną gedimą. curl įrašas rodo, kuris etapas nepavyko, net kai pačios programos žurnalas to nerodo.

Jei tunelis turi perduoti interneto srautą, jo maršrutizavimas ir išėjimo politika abu turi leisti šią paskirties vietą. Tunelis, perduodantis tik privačius maršrutus, palieka pašto ryšį vietiniame kelyje, o tai yra kitas palyginimas.

4 žingsnis: išsiųskite vieną nekenksmingą pranešimą ir užrašykite atsakymą

Ištaisykite etapą, kuris nepavyko, tada išsiųskite vieną nekenksmingą pranešimą per tą pačią programą, o ne per žiniatinklio pašto puslapį. Jūs tikrinate pačios programos siuntimo kelią, įskaitant išsaugotus nustatymus ir TLS režimą. Žiniatinklio pašto sesija apie tai nieko neįrodo.

Užrašykite atsakymą, prievadą, TLS režimą ir naudotą kelią, kad kitas žmogus galėtų atkurti rezultatą. Veikianti naršyklė ir žalia VPN piktograma yra stebėjimai apie kitus dalykus. Jei pranešimas atvyksta, likęs darbas yra padaryti šią konfigūraciją numatytąja kiekvienam kompiuteriui, kuris siunčia per šią paskyrą.

Kontrolinis sąrašas baigtas, kai galite įvardyti nepavykusį etapą, kliento naudojamą prievadą ir TLS režimą, kelią, kurį nuėjo pranešimas, ir atsakymą, kurį grąžino serveris. Šie keturi faktai neaiškią siunčiamųjų dėžutės problemą paverčia pakeitimu, kurį kas nors gali peržiūrėti.