Dërgimi i postës dështon kur VPN lidhet: gjeni fazën

Posta që funksionoi gjithë mëngjesin ndalet në momentin që tuneli ngrihet, dhe instinkti i parë është të rishkruash fjalëkalimin. Ky instinkt anashkalon pyetjen më të dobishme: a arriti klienti te serveri dhe a shkoi mjaft larg për të ofruar kredencialet? Një timeout, një gabim certifikate dhe një përgjigje refuzimi janë tre dështime të ndryshme, dhe vetëm i treti ka të bëjë me llogarinë. Kaloni nëpër fazat me radhë dhe VPN bëhet një variabël që mund ta provoni, jo një i dyshuar që fajësoni.

Faza 1: klasifikoni dështimin përpara se të prekni kredencialet

Lexoni gabimin që aplikacioni prodhoi në të vërtetë, pastaj vendoseni në një nga tre shportat. Një timeout ose rivendosje e lidhjes do të thotë që rruga TCP dështoi; një gabim TLS ose certifikate do të thotë që rruga funksionoi dhe shtrëngimi i duarve jo; një përgjigje SMTP me kod do të thotë që një server poste u përgjigj dhe mori një vendim. Çdo shportë tregon një përgjegjës tjetër.

Ia vlen t’i ndash shportat, sepse ndreqjet kundërshtojnë njëra-tjetrën. Zgjatja e një timeout nuk ndihmon kur serveri refuzon dërguesin, dhe ndryshimi i fjalëkalimit nuk bën asgjë kur rruga është e bllokuar. Kodi i përgjigjes është prova më e vlefshme në listë, sepse vërteton që i gjithë zinxhiri i transportit funksionoi dhe problemi është në politikë ose identitet. Ruani tekstin e saktë, duke përfshirë çdo kod statusi të zgjeruar, përpara se të provoni përsëri.

Ndaloni këtu nëse nuk mund ta riprodhoni dështimin jashtë VPN. Një problem që shfaqet në një aplikacion në një makinë nuk është ende problem rrjeti.

Faza 2: konfirmoni pikën fundore dhe modalitetin TLS

Dërgimi i mesazheve është shërbim më vete, jo e njëjta gjë me përcjelljen nga serveri në server. Konfirmoni emrin e hostit, portën dhe modalitetin TLS nga dokumentacioni i ofruesit për dërgimin, sepse një port i njohur i huazuar nga një konfigurim tjetër poste nuk është provë. Porta 587 pret një përshëndetje me tekst të thjeshtë e ndjekur nga STARTTLS, ndërsa porta 465 pret TLS që nga bajti i parë.

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

Ekzekutimi i provës së gabuar nga të dyja është pikërisht gabimi që bën klienti kur është konfiguruar për modalitetin tjetër. Nëse prova e TLS-së së nënkuptuar ngec në 587, ose prova STARTTLS dështon në 465, porta dhe modaliteti nuk përputhen. Rregulloni modalitetin në klient në vend të çaktivizimit të verifikimit të certifikatës, që e kthen një gabim konfigurimi në një lidhje të paverifikuar. Kjo ndarje është mjaft e vjetër për të qenë e standardizuar: TLS i nënkuptuar në portën 465 është rregullimi i përshkruar në RFC 8314.

Një gabim certifikate këtu është informacion dhe jo pengesë. Ai emërton identitetin që paraqiti serveri dhe identitetin që priste klienti, dhe të dy mund të rregullohen pa dobësuar lidhjen.

Faza 3: krahasoni rrugët pa ndryshuar llogarinë

Mbani pikën fundore, llogarinë dhe cilësimet e klientit konstante dhe ndryshoni vetëm rrugën. Dërgoni një herë me tunelin poshtë dhe një herë me atë lart, dhe shënoni rrugën dhe adresën e burimit që serveri do të shihte. Nëse dështimi ndjek rrugën, e keni izoluar; nëse ndjek makinën, jo.

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

Një tunel i plotë ndryshon adresën e burimit që shikon ofruesi, dhe disa ofrues trajtojnë një burim të panjohur më rreptësisht sesa një fjalëkalim të panjohur. Ky është një vendim politikash nga ana e tyre dhe mund të jetë listë gri, kufi shpejtësie ose bllokim. Mos përgjithësoni nga një ofrues te të gjithë dhe mos supozoni se një rregull NAT që mungon shpjegon çdo dështim. Transkripti i curl tregon cila fazë dështoi edhe kur regjistri i vetë aplikacionit nuk e tregon.

Nëse tuneli duhet të mbajë trafik interneti, si rrugëtimi ashtu edhe politika e daljes duhet të lejojnë këtë destinacion. Një tunel që mban vetëm rrugë private e lë lidhjen e postës në rrugën lokale, që është një krahasim tjetër.

Faza 4: dërgoni një mesazh të padëmshëm dhe shënoni përgjigjen

Rregulloni fazën që dështoi, pastaj dërgoni një mesazh të padëmshëm përmes të njëjtit aplikacion dhe jo përmes një faqe webmail. Ajo që provoni është rruga e dërgimit të vetë aplikacionit, duke përfshirë cilësimet e ruajtura dhe modalitetin TLS. Një sesion webmail nuk provon asgjë për këtë.

Shënoni përgjigjen, portën, modalitetin TLS dhe rrugën që përdorët, që personi tjetër të mund ta riprodhojë rezultatin. Një shfletues që funksionon dhe një ikonë e gjelbër VPN janë vëzhgime për gjëra të tjera. Nëse mesazhi arrin, puna e mbetur është ta bëni atë konfigurim të parazgjedhur për çdo makinë që dërgon përmes kësaj llogarie.

Lista e kontrollit është e plotë kur mund të emërtoni fazën që dështoi, portën dhe modalitetin TLS që përdor klienti, rrugën që ndoqi mesazhi dhe përgjigjen që ktheu serveri. Këto katër fakte e kthejnë një problem të paqartë të kutisë së daljes në një ndryshim që dikush mund ta shqyrtojë.