Pasta sūtīšana neizdodas, kad VPN pievienojas: atrodiet posmu

Pasts, kas darbojās visu rītu, apstājas tajā brīdī, kad tunelis paceļas, un pirmā instinkta reakcija ir no jauna ievadīt paroli. Šī reakcija izlaiž noderīgāko jautājumu: vai klients vispār sasniedza serveri un vai aizgāja pietiekami tālu, lai piedāvātu akreditācijas datus? Taimauts, sertifikāta kļūda un noraidījuma atbilde ir trīs dažādas kļūmes, un tikai trešā attiecas uz kontu. Izstaigājiet posmus secībā, un VPN kļūs par mainīgo, ko varat pārbaudīt, nevis aizdomās turamo, ko vainojat.

1. solis: klasificējiet kļūmi pirms akreditācijas datu aizskaršanas

Izlasiet kļūdu, ko lietojumprogramma faktiski radīja, un pēc tam ievietojiet to vienā no trim groziem. Taimauts vai savienojuma atiestatīšana nozīmē, ka TCP ceļš neizdevās; TLS vai sertifikāta kļūda nozīmē, ka ceļš darbojās un rokasspiediens ne; SMTP atbilde ar kodu nozīmē, ka pasta serveris atbildēja un pieņēma lēmumu. Katrs grozs norāda uz citu atbildīgo.

Grozu atdalīšana ir tā vērta, jo labojumi ir pretrunīgi. Taimauta pagarināšana nepalīdz, kad serveris noraida sūtītāju, un paroles maiņa neko nedara, kad ceļš ir bloķēts. Atbildes kods ir vērtīgākais pierādījums sarakstā, jo tas pierāda, ka visa transportēšanas ķēde darbojās un problēma ir politikā vai identitātē. Saglabājiet precīzu tekstu, tostarp jebkuru paplašināto statusa kodu, pirms mēģināt vēlreiz.

Apstājieties šeit, ja nevarat atkārtot kļūmi ārpus VPN. Problēma, kas parādās vienā lietojumprogrammā vienā datorā, vēl nav tīkla problēma.

2. solis: apstipriniet galapunktu un TLS režīmu

Ziņojumu iesniegšana ir atsevišķs pakalpojums, nevis tas pats, kas pārsūtīšana no servera uz serveri. Apstipriniet resursdatora nosaukumu, portu un TLS režīmu pakalpojumu sniedzēja iesniegšanas dokumentācijā, jo pazīstams ports, kas aizgūts no citas pasta konfigurācijas, nav pierādījums. Ports 587 gaida vienkārša teksta sveicienu un pēc tam STARTTLS, savukārt ports 465 gaida TLS no pirmā baita.

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

Nepareizā no divām pārbaudēm palaišana ir tieši tā kļūda, ko klients pieļauj, kad tas ir konfigurēts otrajam režīmam. Ja implicītā TLS pārbaude iestrēgst uz porta 587, vai STARTTLS pārbaude neizdodas uz porta 465, ports un režīms nesakrīt. Izlabojiet režīmu klientā, nevis izslēdziet sertifikāta pārbaudi, kas konfigurācijas kļūdu pārvērš nepārbaudītā savienojumā. Šis dalījums ir pietiekami sens, lai būtu standartizēts: implicītais TLS portā 465 ir izkārtojums, kas aprakstīts RFC 8314.

Sertifikāta kļūda šeit ir informācija, nevis šķērslis. Tā nosauc identitāti, ko serveris uzrādīja, un identitāti, ko klients gaidīja, un abas var izlabot, nevājinot savienojumu.

3. solis: salīdziniet ceļus, nemainot kontu

Turiet galapunktu, kontu un klienta iestatījumus nemainīgus un mainiet tikai ceļu. Nosūtiet vienu reizi ar nolaistu tuneli un vienu reizi ar paceltu, un pierakstiet maršrutu un avota adresi, ko serveris redzētu. Ja kļūme seko ceļam, jūs to esat izolējuši; ja tā seko datoram, 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

Pilns tunelis maina avota adresi, ko redz pakalpojumu sniedzējs, un daži sniedzēji pret nezināmu avotu izturas stingrāk nekā pret nezināmu paroli. Tas ir viņu puses politikas lēmums, un tas var būt pelēks saraksts, ātruma ierobežojums vai bloķēšana. Nevispāriniet no viena sniedzēja uz visiem un nepieņemiet, ka trūkstošs NAT noteikums izskaidro katru kļūmi. curl ieraksts parāda, kurš posms neizdevās, pat ja pašas lietojumprogrammas žurnāls to nerāda.

Ja tunelim jāpārvadā interneta trafiks, gan tā maršrutēšanai, gan izejas politikai jāatļauj šis galamērķis. Tunelis, kas pārvadā tikai privātus maršrutus, atstāj pasta savienojumu vietējā ceļā, un tas ir cits salīdzinājums.

4. solis: nosūtiet vienu nekaitīgu ziņojumu un pierakstiet atbildi

Izlabojiet posmu, kas neizdevās, un pēc tam iesniedziet vienu nekaitīgu ziņojumu caur to pašu lietojumprogrammu, nevis caur tīmekļa pasta lapu. Jūs pārbaudāt pašas lietojumprogrammas sūtīšanas ceļu, tostarp tās saglabātos iestatījumus un TLS režīmu. Tīmekļa pasta sesija par to neko nepierāda.

Pierakstiet atbildi, portu, TLS režīmu un izmantoto ceļu, lai nākamais cilvēks varētu atkārtot rezultātu. Strādājošs pārlūks un zaļa VPN ikona ir novērojumi par citām lietām. Ja ziņojums pienāk, atlikušais darbs ir padarīt šo konfigurāciju par noklusējumu katram datoram, kas sūta caur šo kontu.

Kontrolsaraksts ir pabeigts, kad varat nosaukt neizdevušos posmu, klienta izmantoto portu un TLS režīmu, ceļu, ko ziņojums gāja, un atbildi, ko serveris atgrieza. Šie četri fakti pārvērš neskaidru izejošo pastu problēmu par izmaiņām, ko kāds var pārskatīt.