Nabibigo ang pagsumite ng mail kapag kumonekta ang VPN: hanapin ang yugto

Ang mail na gumana buong umaga ay tumitigil sa sandaling umangat ang tunnel, at ang unang instinto ay i-type muli ang password. Nilalaktawan ng instintong iyon ang mas kapaki-pakinabang na tanong: naabot ba ng client ang server, at umabot ba ito nang sapat upang mag-alok ng mga kredensyal? Ang timeout, error sa sertipiko at tugon ng pagtanggi ay tatlong magkaibang pagkabigo, at ang pangatlo lang ang may kinalaman sa account. Dumaan sa mga yugto nang sunud-sunod at ang VPN ay magiging variable na masusubok mo sa halip na suspek na sinisisihan mo.

Yugto 1: uriin ang pagkabigo bago hawakan ang mga kredensyal

Basahin ang error na aktwal na ginawa ng aplikasyon, pagkatapos ay ilagay ito sa isa sa tatlong basket. Ang timeout o pag-reset ng koneksyon ay nangangahulugang nabigo ang landas ng TCP; ang error sa TLS o sertipiko ay nangangahulugang gumana ang landas at hindi ang handshake; ang tugon ng SMTP na may code ay nangangahulugang sumagot ang mail server at nagpasya. Ang bawat basket ay tumutukoy sa magkaibang responsable.

Sulit na paghiwalayin ang mga basket dahil nagkakasalungatan ang mga pagwawasto. Walang tulong ang pagpapahaba ng timeout kapag tinatanggihan ng server ang nagpadala, at walang ginagawa ang pagpalit ng password kapag naka-block ang landas. Ang response code ang pinakamahalagang ebidensya sa listahan, dahil pinatutunayan nito na gumana ang buong chain ng transportasyon at ang problema ay patakaran o pagkakakilanlan. I-save ang eksaktong teksto, kasama ang anumang extended status code, bago subukan muli.

Huminto dito kung hindi mo maaaring kopyahin ang pagkabigo sa labas ng VPN. Ang problemang lumalabas sa isang aplikasyon sa isang makina ay hindi pa problema ng network.

Yugto 2: kumpirmahin ang endpoint at ang TLS mode

Ang pagsumite ng mensahe ay sariling serbisyo, hindi kapareho ng relay mula server hanggang server. Kumpirmahin ang hostname, port at TLS mode mula sa dokumentasyon ng provider para sa pagsumite, dahil ang pamilyar na port na hiniram mula sa ibang setup ng mail ay hindi ebidensya. Inaasahan ng port 587 ang pagbati sa plain text na sinusundan ng STARTTLS, habang inaasahan ng port 465 ang TLS mula sa unang 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

Ang pagpapatakbo ng maling isa sa dalawang pagsubok ay eksaktong pagkakamaling ginagawa ng client kapag naka-configure ito para sa kabilang mode. Kung ang pagsubok ng implicit TLS ay natigil sa 587, o nabigo ang pagsubok ng STARTTLS sa 465, hindi tugma ang port at mode. Ayusin ang mode sa client sa halip na patayin ang verification ng sertipiko, na ginagawang hindi na-verify na koneksyon ang error sa configuration. Ang paghahati ay sapat na luma upang maging standard: ang implicit TLS sa port 465 ay ang kaayusang inilarawan sa RFC 8314.

Ang error sa sertipiko dito ay impormasyon at hindi hadlang. Pinangalanan nito ang pagkakakilanlang iniharap ng server at ang pagkakakilanlang inaasahan ng client, at pareho ay maaaring ayusin nang hindi pinapahina ang koneksyon.

Yugto 3: ihambing ang mga landas nang hindi binabago ang account

Panatilihing pare-pareho ang endpoint, account at mga setting ng client at baguhin lamang ang landas. Magpadala nang isang beses na nakababa ang tunnel at isang beses na nakaangat, at itala ang ruta at source address na makikita ng server. Kung sinusundan ng pagkabigo ang landas, nahiwalay mo ito; kung sinusundan nito ang makina, hindi.

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

Binabago ng full tunnel ang source address na nakikita ng provider, at ang ilang provider ay mas mahigpit sa hindi kilalang pinagmulan kaysa sa hindi kilalang password. Ito ay desisyon sa patakaran sa kanilang panig, at maaaring ito ay gray list, limitasyon sa bilis o pag-block. Huwag mag-generalize mula sa isang provider patungo sa lahat, at huwag ipagpalagay na ang nawawalang NAT rule ang nagpapaliwanag sa bawat pagkabigo. Ipinapakita ng transcript ng curl kung aling yugto ang nabigo kahit hindi ito ipinapakita ng sariling log ng aplikasyon.

Kung ang tunnel ay dapat magdala ng trapiko ng internet, parehong ang routing at ang egress policy nito ay dapat pumayag sa destinasyong ito. Ang tunnel na nagdadala lamang ng mga pribadong ruta ay iniiwan ang koneksyon ng mail sa lokal na landas, na ibang paghahambing.

Yugto 4: magpadala ng isang hindi mapaminsalang mensahe at itala ang tugon

Ayusin ang yugtong nabigo, pagkatapos ay isumite ang isang hindi mapaminsalang mensahe sa pamamagitan ng parehong aplikasyon at hindi sa isang pahina ng webmail. Ang sinusubukan mo ay ang sariling landas ng pagpapadala ng aplikasyon, kasama ang mga naka-save na setting at TLS mode nito. Walang pinatutunayan ang sesyon ng webmail tungkol dito.

Itala ang tugon, port, TLS mode at landas na ginamit mo, upang ang susunod na tao ay makopya ang resulta. Ang gumaganang browser at berdeng icon ng VPN ay mga obserbasyon tungkol sa ibang bagay. Kung dumating ang mensahe, ang natitirang gawain ay gawing default ang configuration na iyon para sa bawat makinang nagpapadala sa account na ito.

Kumpleto ang checklist kapag kaya mong pangalanan ang yugtong nabigo, ang port at TLS mode na ginagamit ng client, ang landas na tinahak ng mensahe at ang tugon na ibinalik ng server. Ang apat na katotohanang iyon ay ginagawang pagbabagong masusuri ng kahit sino ang malabong problema sa outbox.