Gammal .ovpn-profil feilar på Ubuntu 24.04: kva linjer du skal sletta

Profilen blir lasta ned, importert og stoppar så på linje 12 i fila med ei Unrecognized option-melding som namngir keysize. Ingenting med kontoen er endra, og tenaren godtek framleis andre klientar. Det som er endra, er klienten sjølv: Ubuntu 24.04 installerer OpenVPN 2.6, medan eksporten vart skriven for 2.4. Reparasjonen er ei kort rekkje slettingar, og rekkjefølgja betyr noko fordi kvart utdaterte alternativ avbryt parsinga før det neste i det heile blir lese.

Les feillinja før du rører fila

OpenVPN namngir fila og linja der parsinga stoppa, så du kan berre retta eitt problem per køyring. Start profilen frå ein terminal og ikkje frå ein skrivebordsapplet, fordi appletten vanlegvis svelgjer stderr og linjenummeret er den einaste pålitelege peikaren du får: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Rett den linja, køyr igjen, og vent at neste feil namngir eit anna alternativ.

Ein parsefeil viser seg alltid før nokon TLS-handshake, så ei melding som nemner eit sertifikat har allereie passert syntaksstadiet. Den skilnaden hindrar deg i å redigera ei fil som berre feilar på autentisering. Les det første ordet i meldinga og ikkje midten av ho.

Tre feilklassar, tre ulike reparasjonar

Gamle eksportar feilar på tre kjennbare måtar, og det å slå dei saman til eitt problem er grunnen til at folk reinstallerer pakkar som aldri var øydelagde. Ordlyden i meldinga fortel deg kva klasse du er i før du opnar fila.

• Parsefeil namngir ei fil og ei linje, og stoppar før nokon trafikk finst.
• Forhandlingsfeil koplar til, og rapporterer deretter at dei to endane ikkje kunne bli samde om eit delt chiffer eller ein akseptabel datakanal.
• Autentiseringsfeil kjem lengst og namngir eit sertifikat, ein brukar eller ein avvist legitimasjon.

Ei profilredigering rettar berre den første klassen. Forhandling krev ei avgjerd i begge endar av tunnelen, og avvist legitimasjon er ikkje eit syntaksproblem i det heile. Viss meldinga di nemner eit delt chiffer eller ein datakanal, vil slettingane nedanfor ikkje endra noko.

Slett alternativa som 2.6 fjerna, i denne rekkjefølgja

Kvar av desse linjene stoppar parsinga åleine, så klienten rapporterer dei éin om gongen. Arbeid deg nedover lista og køyr på nytt etter kvar sletting.

Fjern keysize først, fordi det ikkje har nokon moderne ekvivalent og førekomsten markerer vanlegvis eit chiffer som dagens klient avviser uansett. Fjern deretter ncp-disable, som styrte chifferforhandling, vart avvikla i 2.5 og er borte i 2.6. Erstatt ns-cert-type server med remote-cert-tls server, som uttrykkjer same intensjon gjennom ein støtta sjekk.Endringshistorikken for 2.6 viser dei gjenverande fjerningane ved sida av erstatningane, så alt parseren framleis avviser har eit dokumentert svar.

Ta ein kopi av den opphavlege profilen før den første redigeringa. Leverandørar genererer eksportar på nytt, og ein diff mot den urørte fila er den raskaste måten å skilja endringane dine frå deira. Viss ei sletting lèt klienten starta, men tunnelen framleis feilar,har du flytta deg inn i forhandlingsklassen og dei gjenverande linjene er ikkje årsaka. Set klientversjonen i filnamnet slik at neste person veit kva utgiving redigeringane rettar seg mot.

Hald BF-CBC i gang berre som ein avgrensa fallback

Nokon leverandørar avsluttar framleis på BF-CBC, som OpenVPN 2.6 ikkje vil forhandla utan hjelp fordi chiffreren har ein 64-bits blokk. Den snaue reparasjonen er ei fallback-liste pluss legacy-provideren til OpenSSL, ikkje ein nedgradering av heile klienten.

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

Den første linja lastar legacy-provideren slik at OpenSSL framleis kan instansiera den chiffreren, den andre held på moderne forhandling for partar som støttar det, og den tredje gjeld berre når tenaren ikkje tilbyr noko betre. Det er ei medviten svekking av tunnelen, så noter kvifor ho finst ved sida av fila. Be leverandøren om ein regenerert eksport samstundes, sidan fallbacken er ei bru og ikkje ein destinasjon.

Ikkje grip til --compat-mode som eit generelt svar. Det endrar fleire åtferder samstundes, inkludert standardverdiar for forhandling og reforhandling, så du lærer aldri kva endring som betydde noko. Føretrekk dei tre eksplisitte linjene ovanfor, fordi kvar av dei oppgir sin eigen effekt.

Verifiser med profilen klienten faktisk lastar

Importerte tilkoplingar blir ofte kopierte til ein systemkatalog, så redigering av fila i nedlastingsmappa kan ikkje endra noko i det heile. Finn kopien som køyrer: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Start deretter tunnelen og les logglinja som rapporterer kva datakanal-chiffer som faktisk vart valt. Ei tilkopling som fullfører handshaken på fallbacken fortel deg at tenaren aldri tilbaud noko moderne.

Test frå eit nettverk som ikkje er det leverandøren ventar, slik at ein captive portal eller eit filtrert gjestenettverk ikkje gir seg ut for å vere ein profilfeil. Noter klientversjonen saman med kvar støtteførespurnad.

Når tunnelen er oppe, send éin førespurnad som må krysse han og éin som ikkje må, og stadfest deretter at resolver-svaret endra seg slik du venta. Viss profilen no blir parsa men tilkoplinga framleis feilar, har du forlate syntaksproblemet og feilteksten vil namngi den nye klassen. Hald den redigerte fila i versjonskontroll ved sida av eit notat som namngir OpenVPN-utgivinga ho rettar seg mot.