Konfigurimi publik i VPN ndaloi së punuari? Lexo fazën e dështimit

Profili punoi të martën, dhe të premten klienti rrotullohet tridhjetë sekonda dhe dorëzohet. Asgjë në makinën tënde nuk ndryshoi. Pikërisht kjo është çështja: një konfigurim i shkarkuar përshkruan një host në një moment, dhe operatori në anën tjetër nuk ka asnjë detyrim ta mbajë atë përshkrim të vërtetë. Tundimi është të fillosh të editosh cilësimet e sigurisë derisa tuneli të kthehet. Pikërisht ai instinkt është arsyeja pse njerëzit përfundojnë duke ekzekutuar një profil me verifikimin e certifikatës të çaktivizuar, gjë që është më e keqe sesa të mos kesh fare tunel.

Skedari përshkruan një moment, jo një kontratë

Një skedar konfigurimi është një grup pohimesh: ky emër hosti dëgjon në këtë port me këtë protokoll, paraqet një certifikatë që përputhet me këtë emër dhe pranon këto kredenciale. Kur ndonjëra prej tyre prestan së qeni e vërtetë, skedari është i vjetëruar dhe rregullimi i takon anës së operatorit të kufirit, jo cilësimeve të tua.

Listat publike të nyjeve e bëjnë këtë të qartë nga natyra e tyre. Nyjet drejtohen nga vullnetarë, shfaqen dhe zhduken, adresat riciklohen dhe portat bllokohen nga rrjeti pas të cilit ndodhen. Lista është një pamje e çastit që rigjenerohet, dhe kopja në diskun tënd është një fotografi e një pamjeje më të vjetër.

Shërbimet tregtare ndryshojnë më ngadalë, por jo kurrë. Autoritetet e certifikimit rrotullohen, një dëgjues kalon nga një adresë e përbashkët në një të dedikuar, një protokoll i vjetër tërhiqet dhe arrin një listë e re shifrash. Secila prej tyre është e padukshme derisa klienti yt të provojë të lidhet dhe të marrë një përgjigje të ndryshme nga ajo që pret skedari.

Lexo fazën e dështimit para se të prekësh një cilësim

Mesazhi i gabimit thotë cila pohim ra, dhe secili pohim ka një rregullim krejt të ndryshëm. Editimi i shifrave kur emri i hostit nuk zgjidhet më humb një pasdite dhe nuk i mëson askujt asgjë.

dig +short vpn.example.net
curl -sS -o /dev/null -w 'connect=%{time_connect} tls=%{time_appconnect}\n' --max-time 8 https://vpn.example.net:443/
openssl s_client -connect vpn.example.net:443 -servername vpn.example.net -brief </dev/null

Rreshti i mesëm ndan një rrugë të bllokuar nga një shtrëngim duarsh i prishur, dhe i treti tregon lëshuesin dhe datat e vlefshmërisë të certifikatës që paraqitet në të vërtetë. Nëse ai lëshues nuk është ai që profili ka fiksuar, certifikata ka ndryshuar, dhe asnjë opsion nga ana e klientit nuk do ta bëjë fiksimin e vjetër përsëri të saktë.

Ndryshimet e certifikatës dhe identitetit janë ato të heshtura

Shumica e dështimeve njoftojnë vetë. Ndryshimet e identitetit nuk e bëjnë, sepse një klient që fikson një emër certifikate do të refuzojë një certifikatë të re plotësisht të mirë me një mesazh që shumë njerëz e lexojnë si një bug. Tuneli është në rregull. Fiksimi është i vjetëruar.

Kërko opsionet e identitetit përpara se të nxjerrësh ndonjë përfundim:

grep -nE '^(remote|proto|auth|verify-x509-name|tls-crypt|key-direction|ca) ' profile.ovpn
openssl x509 -in profile-ca.crt -noout -subject -dates

Nëse profili mban një CA të integruar dhe operatori ka kaluar në një autoritet të re, skedari i vjetër nuk mund të vërtetojë serverin e re. Zëvendësimi i bllokut CA me atë të publikuar nga operatori është një rregullim legjitim. Fshirja e direktivës së verifikimit nuk është, dhe janë të njëjtat shtypje tastesh me një rezultat krejt të ndryshëm.

Një përditësim i klientit mund të prodhojë të njëjtin simptom pa asnjë ndryshim nga operatori. Opsionet që toleroheshin në heshtje tani refuzohen, ose një protokoll i vjetëruar hiqet. Ky është një kufi përputhshmërie në softuerin tënd, dhe ia vlen të provosh një profil të dytë me të njëjtin klient përpara se të fajësosh serverin.

Vetëm operatori mund të publikojë një zëvendësim të vlefshëm

Kur një nyje zhduket, zëvendësimi duhet të vijë nga i njëjti burim që publikoi origjinalin. Një profil që arrin në një mesazh të drejtpërdrejtë sepse «përdor të njëjtin emër serveri» është një konfigurim i paverifikuar nga një palë e panjohur, dhe importimi i tij i jep asaj pale kontrollin e rrugëzimit tënd.

Kontrolli është i lirë. Merre skedarin aktual nga vendndodhja e publikuar, krahaso pikën fundore dhe protokollin me listën, dhe konfirmo gjurmën e gishtit të materialit CA në vend që të besosh emrin e skedarit:

curl -sS -o current.ovpn https://example.org/nodes/current.ovpn
sha256sum current.ovpn profile.ovpn
grep -nE '^(remote|proto) ' current.ovpn

Nëse dy hash-et ndryshojnë vetëm në hapësira, ke një ndryshim formatimi. Nëse ndryshojnë në pikat fundore, operatori ka lëvizur diçka dhe skedari i publikuar është autoriteti. Nëse skedari i publikuar është më i vjetër se ai që ke, ndoshta po shikon një cache, dhe përgjigja e vjetëruar do të të dërgojë në drejtimin e gabuar.

Tërhiqe hyrjen e vjetër dhe shkruaj çfarë ndodhi

Pasi një zëvendësim funksional verifikohet, fshije profilin e vjetër në vend që ta mbash si rezervë. Një hyrje e vjetëruar që lidhet gjysmë është një kurth: do të zgjidhet gjatë një ndërprerjeje, do të dështojë ngadalë, dhe personi që korrigjon gabimet do të kalojë dhjetë minutat e para në skedarin e gabuar.

Mbaj një regjistër të shkurtër jashtë konfigurimit: datën, pikën fundore të vjetër, fazën e dështimit dhe çfarë e zëvendësoi. Nyjet publike ndryshojnë, dhe gjashtë javë më vonë e njëjta pyetje vjen me një person tjetër. Një rresht në një skedar shënimesh i përgjigjet në sekonda.

Nëse nga një rrjet çdo nyje dështon në të njëjtën mënyrë dhe nga një tjetër asnjë, ndalo editimin e profileve dhe shiko rrugën lokale. Një portal robërues, një interval portash i filtruar ose një proxy përgjues do të prodhojnë gabime identike te ofrues të palidhur, dhe pikërisht ai model është sinjali i vetëm se problemi nuk ishte kurrë skedari.