Profili i vjetër .ovpn dështon në Ubuntu 24.04: cilat rreshta duhen fshirë

Profili shkarkohet, importohet dhe pastaj ndalon në rreshtin 12 të skedarit me një mesazh Unrecognized option që emërton keysize. Asgjë në llogari nuk ka ndryshuar dhe serveri vazhdon të pranojë klientë të tjerë. Ajo që ndryshoi është vetë klienti: Ubuntu 24.04 instalon OpenVPN 2.6, ndërsa eksporti është shkruar për 2.4. Riparimi është një seri e shkurtër fshirjesh dhe rendi ka rëndësi sepse çdo opsion i vjetëruar ndërpret analizimin përpara se tjetri të lexohet fare.

Lexoni rreshtin e gabimit përpara se të prekni skedarin

OpenVPN emërton skedarin dhe rreshtin ku ndaloi analizimi, kështu që mund të rregulloni vetëm një problem për çdo ekzekutim. Nisni profilin nga një terminal dhe jo nga një applet desktopi, sepse applet-i zakonisht e gëlltit stderr dhe numri i rreshtit është treguesi i vetëm i besueshëm që merrni: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Rregulloni atë rresht, ekzekutoni përsëri dhe prisni që dështimi tjetër të emërtojë një opsion tjetër.

Një gabim analizimi shfaqet gjithmonë përpara çdo handshake TLS, kështu që një mesazh që përmend një certifikatë e ka kaluar tashmë fazën e sintaksës. Ky dallim ju pengon të modifikoni një skedar që dështon vetëm në autentikim. Lexoni fjalën e parë të mesazhit dhe jo mesin e tij.

Tri klasa dështimi, tri riparime të ndryshme

Eksportet e vjetra dështojnë në tri mënyra të dallueshme dhe bashkimi i tyre në një problem të vetëm është arsyeja pse njerëzit riinstalojnë paketa që nuk ishin prishur kurrë. Formulimi i mesazhit ju tregon në cilën klasë jeni përpara se të hapni skedarin.

• Gabimet e analizimit emërtojnë një skedar dhe një rresht dhe ndalen përpara se të ekzistojë çfarëdo trafiku.
• Gabimet e negocimit lidhen dhe pastaj raportojnë se dy skajet nuk mund të binin dakord për një shifër të përbashkët ose një kanal të dhënash të pranueshëm.
• Gabimet e autentikimit shkojnë më larg dhe emërtojnë një certifikatë, një përdorues ose kredenciale të refuzuara.

Një modifikim i profilit rregullon vetëm klasën e parë. Negocimi kërkon një vendim në të dy skajet e tunelit dhe kredencialet e refuzuara nuk janë fare problem sintakse. Nëse mesazhi juaj përmend një shifër të përbashkët ose një kanal të dhënash, fshirjet më poshtë nuk do të ndryshojnë asgjë.

Fshini opsionet që 2.6 hoqi, në këtë rend

Secili prej këtyre rreshtave e ndal analizimin vetë, kështu që klienti i raporton një nga një. Zbritni listën dhe ekzekutoni përsëri pas çdo fshirjeje.

Hiqni së pari keysize, sepse nuk ka ekuivalent modern dhe prania e tij zakonisht shënon një shifër që klienti aktual e refuzon gjithsesi. Pastaj hiqni ncp-disable, i cili kontrollonte negocimin e shifrave, u vjetërua në 2.5 dhe u zhduk në 2.6. Zëvendësoni ns-cert-type server me remote-cert-tls server, i cili shpreh të njëjtin qëllim përmes një kontrolli të mbështetur.Historiku i ndryshimeve të 2.6 liston fshirjet e mbetura krahas zëvendësimeve të tyre, kështu që çdo gjë që analizuesi ende refuzon ka një përgjigje të dokumentuar.

Ruani një kopje të profilit origjinal përpara modifikimit të parë. Ofruesit i rigjenerojnë vërtet eksportet dhe një diff me skedarin e paprekur është mënyra më e shpejtë për t'i ndarë ndryshimet tuaja nga ato të tyre. Nëse një fshirje lejon klientin të niset, por tuneli ende dështon,keni kaluar në klasën e negocimit dhe rreshtat e mbetur nuk janë shkaku. Vendosni versionin e klientit në emrin e skedarit që personi tjetër të dijë se për cilën version janë modifikimet.

Mbani BF-CBC duke punuar vetëm si fallback i kufizuar

Disa ofrues ende përfundojnë në BF-CBC, të cilin OpenVPN 2.6 nuk do ta negociojë pa ndihmë sepse shifra ka një bllok 64-bit. Riparimi i ngushtë është një listë fallback plus ofruesi legacy i OpenSSL, jo një downgrade i të gjithë klientit.

providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC

Rreshti i parë ngarkon ofruesin legacy që OpenSSL të mund ta krijojë ende atë shifër, i dyti mban negocimin modern për partnerët që e mbështesin dhe i treti zbatohet vetëm kur serveri nuk ofron asgjë më të mirë. Ky është një dobësim i qëllimshëm i tunelit, prandaj shkruani pranë skedarit pse ekziston. Kërkojini ofruesit një eksport të rigjeneruar në të njëjtën kohë, pasi fallback-u është urë dhe jo destinacion.

Mos u mbështetni te --compat-mode si përgjigje universale. Ndryshon disa sjellje njëherësh, duke përfshirë parazgjedhjet e negocimit dhe të rinegocimit, kështu që nuk mësoni kurrë se cili ndryshim kishte rëndësi. Preferoni tri rreshtat e qartë më sipër, sepse secili deklaron efektin e vet.

Verifikoni me profilin që klienti ngarkon në të vërtetë

Lidhjet e importuara shpesh kopjohen në një drejtori sistemi, kështu që modifikimi i skedarit në dosjen e shkarkimeve mund të mos ndryshojë asgjë. Gjeni kopjen që ekzekutohet: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Pastaj nisni tunelin dhe lexoni rreshtin e logut që raporton shifrën e kanalit të dhënave që u zgjodh në të vërtetë. Një lidhje që përfundon handshake-un në fallback ju tregon se serveri nuk ofroi kurrë asgjë moderne.

Testoni nga një rrjet që nuk është ai që pret ofruesi, që një portal captive ose një rrjet mysafirësh i filtruar të mos duket si defekt i profilit. Shkruani versionin e klientit bashkë me çdo kërkesë për mbështetje.

Pasi tuneli të jetë lart, dërgoni një kërkesë që duhet ta kalojë dhe një që nuk duhet, pastaj konfirmoni se përgjigja e resolver-it ndryshoi siç prisnit. Nëse profili tani analizohet, por lidhja ende dështon, e keni lënë problemin e sintaksës pas dhe teksti i gabimit do të emërtojë klasën e re. Mbani skedarin e modifikuar në kontrollin e versioneve pranë një shënimi që emërton versionin e OpenVPN që synon.