Pse OpenVPN ndaloi së lidhuri pas një përditësimi të Ubuntu?

Profilet VPN që funksiononin javën e kaluar prishen pas një përditësimi të versionit të Ubuntu, dhe regjistri rrallë e përmend përditësimin. Ajo që emërton është shtresa që dështoi: shtrëngimi i duarve TLS, shifrimi i negociuar për kanalin e të dhënave, paketa e instaluar ose kopja e OpenSSL që binari ngarkon në nisje. Çdo shtresë ka formën e vet të gabimit dhe riparimin e vet, prandaj klasifikimi është puna e parë dhe redaktimi e dyta. Trajtojeni profilin si të pafajshëm derisa regjistri ta emërtojë.

Cila shtresë dështoi: shtrëngimi i duarve, shifrimi, paketa apo biblioteka

Lexoni regjistrin e klientit përpara se të prekni profilin. gabimi më i hershëm në dalje është ai që identifikon shtresën; çdo gjë e shtypur pas tij është zakonisht pasojë e atij dështimi të parë. Kur klienti nuk niset fare, regjistri i VPN-së është skedari i gabuar për t'u hapur.

Ankesat për certifikatat dhe nënshkrimet, ose një mesazh për gjatësinë e çelësit, vijnë nga kanali i kontrollit dhe politika e bibliotekës që e rregullon atë. Ndërsa një paralajmërim që fillon me DEPRECATED OPTION i përket negociimit të kanalit të të dhënave.

Një rresht si Unrecognized option është kategoria e tretë: binari i ri nuk pranon më një direktivë që i vjetri e toleronte, prandaj profili duhet rishkruar e jo biblioteka lehtësuar. Dështimet e paketave duken sërish ndryshe sepse ndodhin përpara se të ekzekutohet ndonjë kod tuneli. Një binar që mungon, një shtojcë që nuk ngarkohet ose një depo që tregon emrin e gabuar të kodit prodhojnë të gjitha atë formë. Katër simptoma, katër vende për të parë dhe pothuajse asnjë mbivendosje mes riparimeve.

Kur dështon shtrëngimi i duarve, politika TLS e refuzon certifikatën

Ubuntu 22.04 e kaloi sistemin në OpenSSL 3, dhe niveli i parazgjedhur i sigurisë në atë degë është më i rreptë për nënshkrimet e certifikatave dhe madhësitë e çelësave sesa ishte 20.04. Një certifikatë CA e nënshkruar me një tretësirë më të vjetër, ose një çelës nën pragun aktual, tani dështojnë gjatë shtrëngimit të duarve. Meqenëse asgjë nuk është vërtetuar ende, gabimi lexohet si fjalëkalim i gabuar ose server i vdekur.

Riparimi i ngushtë lidh një varg shifrimi vetëm me këtë lidhje. Në redaktorin e desktopit, hapni profilin, kaloni te cilësimet e avancuara dhe vendosni DEFAULT:@SECLEVEL=0 në fushën e shifrimit TLS. Skedari i çelësave i NetworkManager merr të njëjtën vlerë nën [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

Rinisni NetworkManager dhe rilidhuni, sepse daemoni i ruajtur në memorie profilet e analizuara dhe përndryshe do të vazhdonte të përdorte kopjen që tashmë mban. Dijeni çfarë bën rreshti përpara se ta mbani: ai cilësim është një prag mbi disa parametra certifikatash dhe çelësash, jo një emër shifrimi, prandaj ulja e tij zgjeron atë që pranon profili i vetëm. Shënoni cili server e kërkoi dhe hiqni cilësimin kur operatori të riemëtojë materialin aktual. Ndryshimi i /etc/ssl/openssl.cnf arrin të njëjtin prag për çdo program që lexon atë skedar, që shkon shumë përtej VPN-së.

OpenVPN 2.6 kërkon shifrimin e listuar për negociim

Ubuntu 22.10 solli OpenVPN 2.6, dhe në atë version --cipher ndalon së zgjedhuri vetë kanalin e të dhënave. Shifrimi duhet të jetë edhe në listën data-ciphers të negociuar, përndryshe klienti shtyp një paralajmërim vjetërsie dhe më pas nuk arrin ta ngrejë tunelin.

Shtojca e NetworkManager nga e njëjta periudhë vazhdonte të shkruante vetëm direktivën e vjetër. Ky detaj e ndan diagnozën, sepse një profil i korrigjuar me dorë mund të lidhet nga një shell dhe gjithsesi të dështojë nga applet-i i desktopit. Shtoni listën në skedarin e lidhjes nën [vpn]:

data-ciphers=AES-256-CBC

Përdorni vlerën që shpall serveri, jo atë që mbani mend; një server që ofron AES-256-GCM nuk do të negociojë me një listë klienti që përmend vetëm CBC. Rinisni menaxherin dhe rilidhuni, pastaj përsëritni provën nga një shell duke e dhënë shifrimin në mënyrë eksplicite si për negociim ashtu edhe për rezervë:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

Nëse ai komandë e ngre tunelin, serveri, certifikatat dhe kredencialet janë të gjitha të shëndosha, dhe defekti i vetëm i mbetur është opsioni i ruajtur i menaxherit. Një paralajmërim për direktivën keysize i përket të njëjtit pastrim: komentojeni dhe mbajeni skedarin origjinal pranë profilit.

Defektet e paketës dhe shtojcës duken si defekte VPN

Jo çdo dështim pas përditësimit është kriptografik. Një depo OpenVPN e shtuar nën një emër kodi që versioni nuk e përdor prodhon një paketë që nuk instalohet kurrë, prandaj krahasoni atë që raporton lsb_release -a me skedarin e listës që shtuat. Një komponent universe që mungon ose një xhep sigurie prodhojnë një paketë që nuk gjendet fare. Të dyja rastet e lënë profilin të paprekur dhe tunelin të pamundur.

Lexoni gabimin e menaxherit të paketave përpara regjistrit të VPN-së. Nëse klienti nuk është instaluar kurrë, asnjë sasi e redaktimit të profilit nuk do të prodhojë një shtrëngim duarsh.

Profilet me dy faktorë që ndalojnë së kërkuari janë versioni me shtojcë i të njëjtës histori. Sfida vjen nga një shtojcë vërtetimi, dhe një përditësim që e hoqi ose e zëvendësoi e lë profilin të paprekur ndërsa kërkesa zhduket. Riinstaloni shtojcën e mbështetur në vend që të fshini faktorin e dytë që lidhja të funksionojë.

Një bibliotekë furnizuesi mund të fshihet pas një gabimi politike

Një model meriton njohje, sepse mposht çdo riparim politike. Një mjet konfigurimi i një furnizuesi hardueri mund të instalojë bibliotekat e veta OpenSSL dhe t'i vendosë përpara kopjeve të sistemit në rrugën e kërkimit të ngarkuesit. Klienti atëherë niset kundër një biblioteke që askush nuk e ka përditësuar, dhe dështimi i nisjes duket saktësisht si një certifikatë e refuzuar.

Riinstalimi i paketës VPN nuk ndryshon cila bibliotekë gjendet e para, dhe ulja e nivelit TLS nuk arrin një bibliotekë që nuk ka ardhur kurrë nga sistemi. Pyesni ngarkuesin cilat objekte kriptografike zgjidh vërtet binari:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

Hiqni ose riorientoni kopjen e furnizuesit, pastaj ekzekutoni përsëri të njëjtin kontroll. Versioni i pritur duhet të jetë ai në përdorim përpara se të ktheheni te profili.

Fiksimi i një klienti më të vjetër blen kohë, jo zgjidhje

Mbajtja e versionit të mëparshëm të klientit e rikthen tunelin sa zgjat mbajtja. Gjithashtu ngrin përditësimet e sigurisë për atë paketë dhe planifikon të njëjtin thyerje për përditësimin e radhës, prandaj trajtojeni si një zgjidhje të përkohshme me datë, jo si zgjidhje.

Nëse gjithsesi e fiksoni, mbajeni paketën në mënyrë eksplicite që një përditësim i pambikëqyrur të mos mund ta anulojë fiksimin, shkruani arsyen dhe datën e rishikimit dhe vendosni një kujtesë për versionin e radhës të profilit nga furnizuesi. Kushti që ia vlen të ndiqet është një profil serveri që negocion një shifrim aktual; sapo të ekzistojë, fiksimi nuk ka më asnjë justifikim. Një fiksim i paregjistruar, nga ana tjetër, bëhet një ndërprerje që askush nuk mund ta shpjegojë gjashtë muaj më vonë, sepse personi që e zbatoi është larguar dhe skedari nuk regjistron asgjë.

Herën tjetër që një VPN vdes pas një përditësimi versioni, bëni pesë pyetje me radhë: cila shtresë prodhoi gabimin e parë, a e refuzoi politika TLS certifikatën, a është i negociueshëm shifrimi në të dy drejtimet, a u instaluan vërtet paketa dhe shtojca e saj, dhe cilën bibliotekë ngarkon procesi. Vetëm pasi të pesë kthehen të pastra ka kuptim një zbritje versioni.