Ald .ovpn-profil mislearret op Ubuntu 24.04: hokker rigels moatsto wiskje
Ubuntu 24.04 leveret OpenVPN 2.6, en in profyl dat foar 2.4 eksportearre is, stjert op fuorthelle opsjes. Wiskje keysize en ncp-disable, en reparearje dan ns-cert-type.
It profyl wurdt del laden, ymportearre en stoppet dan by rigel 12 fan it bestân mei in berjocht Unrecognized option dat keysize neamt. Oan it akkount is neat feroare en de tsjinner akseptearret noch altyd oare kliïnten. Wat feroare is, is de klient sels: Ubuntu 24.04 ynstallearret OpenVPN 2.6, wylst de eksport foar 2.4 skreaun is. De reparaasje is in koarte searje wiskingen, en de folchoarder is fan belang om't elke ferâldere opsje it parsen ôfbrekt foardat de folgjende ea lêzen wurdt.
Lês de fluchrigel foardat jo it bestân oanreitsje
OpenVPN neamt it bestân en de rigel dêr't it parsen stoppe, dus jo kinne mar ien probleem per run reparearje. Start it profyl fanôf in terminal ynstee fan in buroblêd-applet, om't de applet stderr meastentiids trochslokt en it rigelnûmer de iennichste betroubere oanwizing is dy't jo krije: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Reparearje dy rigel, start opnij en ferwachtsje dat de folgjende flater in oare opsje neamt.
In parseflater ferskynt altyd foarôfgeand oan elke TLS-hânskodding, dus in berjocht dat in sertifikaat neamt, hat de syntaksfaze al trochstien. Dat ûnderskied hâldt jo tsjin om in bestân te bewurkjen dat allinnich by autentikaasje mislearret. Lês it earste wurd fan it berjocht, net it midden.
Trije flaterklassen, trije ferskillende reparaasjes
Alde eksporten mislearje op trije ûnderskiedbere manieren, en krekt it gearfoegjen ta ien probleem is wêrom't minsken pakketten opnij ynstallearje dy't nea stikken wiene. De wurden fan it berjocht fertelle jo yn hokker klasse jo sitte foardat jo it bestân iepenje.
- Parseflaters neame in bestân en in rigel, en stopje foardat der ek mar wat ferkear bestiet.
- Underhannelingsflaters meitsje ferbining en melde dan dat de beide einen it net iens wurde koene oer in mienskiplike sjifre of in akseptabel datakanaal.
- Autentikaasjeflaters komme it fierst en neame in sertifikaat, in brûker of in wegere legitimaasje.
It bewurkjen fan it profyl reparearret allinnich de earste klasse. Underhanneling freget in beslút oan beide einen fan 'e tunnel, en in wegere legitimaasje is hielendal gjin syntaksprobleem. As jo berjocht in mienskiplike sjifre of in datakanaal neamt, sille de wiskingen hjirûnder neat feroarje.
Wiskje de opsjes dy't 2.6 fuorthelle hat, yn dizze folchoarder
Elk fan dizze rigels stopet it parsen op himsels, dus de klient meldet se ien foar ien. Wurkje de list del en start opnij nei elke wisking.
Wiskje earst keysize, want it hat gjin moderne ekwivalint en syn oanwêzigens markearret meastentiids in sjifre dy't de hjoeddeiske klient dochs wegeret. Wiskje dan ncp-disable, dat de sjifre-ûnderhanneling regele, yn 2.5 ferâldere rekke en yn 2.6 fuort is. Ferfange ns-cert-type server troch remote-cert-tls server, dat deselde bedoeling útdrukt fia in stipe kontrôle. De 2.6-feroaringsskiednis listet de oerbliuwende fuorthellingen neist har ferfangings, dus alles wat de parser noch wegeret, hat in dokumintearre antwurd.
Hâld in kopy fan it orizjinele profyl foar de earste bewurking. Providers meitsje eksporten opnij, en in diff tsjin it ûnoanreite bestân is de fluchste manier om jo feroarings fan dy fan harren te skieden. As in wisking de klient starte lit mar de tunnel mislearret noch, binne jo nei de underhannelingsklasse ferhuze en binne de oerbliuwende rigels net de oarsaak. Set de klientferzje yn 'e bestânsnamme sadat de folgjende persoan wit op hokker útjefte de bewurkings rjochte binne.
Hâld BF-CBC allinnich as beheinde fallback oan 'e gong
Guon providers einigje noch op BF-CBC, dêr't OpenVPN 2.6 sûnder help net oer ûnderhannelje sil, om't de sjifre in 64-bits blok hat. De smelle reparaasje is in fallbacklist plus de âlde OpenSSL-provider, gjin delgradearring fan 'e hiele klient.
providers legacy default
data-ciphers AES-256-GCM:AES-128-GCM
data-ciphers-fallback BF-CBC
De earste rigel laded de âlde provider sadat OpenSSL dy sjifre noch meitsje kin, de twadde behâldt moderne ûnderhanneling foar peers dy't it stypje, en de tredde jildt allinnich as de tsjinner neat betters biedt. Dat is in bewuste ferswakking fan 'e tunnel, dus skriuw njonken it bestân wêrom't it bestiet. Freegje de provider tagelyk om in opnij makke eksport, want de fallback is in brêge en gjin bestimming.
Gryp net nei --compat-mode as algemien antwurd. It feroaret ferskate gedragingen tagelyk, wêrûnder de standertwearden foar ûnderhanneling en werûnderhanneling, dus jo leare nea hokker feroaring it ferskil makke. Ferkiezje de trije eksplisite rigels hjirboppe, want elk fan harren seit syn eigen effekt.
Kontrolearje mei it profyl dat de klient echt laded
Ymportearre ferbiningen wurde faak nei in systeemmap kopiaasje, dus it bewurkjen fan it bestân yn jo downloadmap kin hielendal neat feroarje. Fyn de kopy dy't rint: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Start dan de tunnel en lês de logrigel dy't meldet hokker sjifre fan it datakanaal echt keazen is. In ferbining dy't de hânskodding op 'e fallback foltôget, fertelt jo dat de tsjinner nea eat moderns oanbean hat.
Test fan in netwurk dat net it netwurk is dat de provider ferwachtet, sadat in captive portal of in filtere gastnetwurk him net as profylflater foardocht. Skriuw de klientferzje op by elke stipe-oanfraach.
As de tunnel omheech is, stjoer dan ien fersyk dat der trochhinne moat en ien dat net moat, en befêstigje dan dat it antwurd fan 'e resolver feroare is sa't jo ferwachten. As it profyl no parset mar de ferbining mislearret noch, hawwe jo it syntaksprobleem efterlitten en sil de flatertekst de nije klasse neame. Hâld it bewurke bestân yn ferzjekontrôle njonken in notysje dy't de riochte OpenVPN-útjefte neamt.