Gammel .ovpn-profil feiler på Ubuntu 24.04: hvilke linjer du skal slette

Profilen lastes ned, importeres og stopper så på linje 12 i filen med en Unrecognized option-melding som navngir keysize. Ingenting med kontoen er endret, og serveren godtar fortsatt andre klienter. Det som er endret, er klienten selv: Ubuntu 24.04 installerer OpenVPN 2.6, mens eksporten ble skrevet for 2.4. Reparasjonen er en kort serie slettinger, og rekkefølgen betyr noe fordi hvert utdaterte alternativ avbryter parsingen før det neste i det hele tatt leses.

Les feillinjen før du rører filen

OpenVPN navngir filen og linjen der parsingen stoppet, så du kan bare rette ett problem per kjøring. Start profilen fra en terminal og ikke fra et skrivebordsapplet, fordi appletten vanligvis svelger stderr og linjenummeret er den eneste pålitelige pekeren du får: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Rett den linjen, kjør igjen, og forvent at neste feil navngir et annet alternativ.

En parsefeil vises alltid før noen TLS-handshake, så en melding som nevner et sertifikat har allerede passert syntaksstadiet. Den forskjellen hindrer deg i å redigere en fil som bare feiler på autentisering. Les det første ordet i meldingen og ikke midten av den.

Tre feilklasser, tre forskjellige reparasjoner

Gamle eksporter feiler på tre kjennbare måter, og det å slå dem sammen til ett problem er grunnen til at folk reinstallerer pakker som aldri var ødelagt. Ordlyden i meldingen forteller deg hvilken klasse du er i før du åpner filen.

• Parsefeil navngir en fil og en linje, og stopper før noen trafikk finnes.
• Forhandlingsfeil kobler til, og rapporterer deretter at de to endene ikke kunne bli enige om et delt chiffer eller en akseptabel datakanal.
• Autentiseringsfeil kommer lengst og navngir et sertifikat, en bruker eller en avvist legitimasjon.

En profilredigering retter bare den første klassen. Forhandling krever en beslutning i begge ender av tunnelen, og avvist legitimasjon er ikke et syntaksproblem i det hele tatt. Hvis meldingen din nevner et delt chiffer eller en datakanal, vil slettingene nedenfor ikke endre noe.

Slett alternativene som 2.6 fjernet, i denne rekkefølgen

Hver av disse linjene stopper parsingen alene, så klienten rapporterer dem én om gangen. Arbeid deg nedover listen og kjør på nytt etter hver sletting.

Fjern keysize først, fordi det ikke har noen moderne ekvivalent og tilstedeværelsen markerer vanligvis et chiffer som dagens klient avviser uansett. Fjern deretter ncp-disable, som styrte chifferforhandling, ble avviklet i 2.5 og er borte i 2.6. Erstatt ns-cert-type server med remote-cert-tls server, som uttrykker samme intensjon gjennom en støttet sjekk.Endringshistorikken for 2.6 viser de gjenværende fjerningene ved siden av erstatningene, så alt parseren fortsatt avviser har et dokumentert svar.

Ta en kopi av den opprinnelige profilen før den første redigeringen. Leverandører genererer eksporter på nytt, og en diff mot den urørte filen er den raskeste måten å skille dine endringer fra deres. Hvis en sletting lar klienten starte, men tunnelen fortsatt feiler,har du flyttet deg inn i forhandlingsklassen og de gjenværende linjene er ikke årsaken. Sett klientversjonen i filnavnet slik at neste person vet hvilken utgivelse redigeringene retter seg mot.

Hold BF-CBC i gang bare som en avgrenset fallback

Noen leverandører avslutter fortsatt på BF-CBC, som OpenVPN 2.6 ikke vil forhandle uten hjelp fordi chiffreren har en 64-bits blokk. Den snevre reparasjonen er en fallback-liste pluss OpenSSLs legacy-provider, ikke en nedgradering av hele klienten.

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

Den første linjen laster legacy-provideren slik at OpenSSL fortsatt kan instansiere det chiffreren, den andre beholder moderne forhandling for par som støtter det, og den tredje gjelder bare når serveren ikke tilbyr noe bedre. Det er en bevisst svekkelse av tunnelen, så noter hvorfor den finnes ved siden av filen. Be leverandøren om en regenerert eksport samtidig, siden fallbacken er en bro og ikke en destinasjon.

Ikke grip til --compat-mode som et generelt svar. Det endrer flere atferder samtidig, inkludert standardverdier for forhandling og reforhandling, så du lærer aldri hvilken endring som betydde noe. Foretrekk de tre eksplisitte linjene ovenfor, fordi hver av dem oppgir sin egen effekt.

Verifiser med profilen klienten faktisk laster

Importerte tilkoblinger kopieres ofte til en systemkatalog, så redigering av filen i nedlastingsmappen kan ikke endre noe i det hele tatt. Finn kopien som kjører: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Start deretter tunnelen og les logglinjen som rapporterer hvilket datakanal-chiffer som faktisk ble valgt. En tilkobling som fullfører handshaken på fallbacken forteller deg at serveren aldri tilbød noe moderne.

Test fra et nettverk som ikke er det leverandøren forventer, slik at en captive portal eller et filtrert gjestenettverk ikke utgir seg for å være en profilfeil. Noter klientversjonen sammen med enhver støtteforespørsel.

Når tunnelen er oppe, send én forespørsel som må krysse den og én som ikke må, og bekreft deretter at resolver-svaret endret seg slik du forventet. Hvis profilen nå parses men tilkoblingen fortsatt feiler, har du forlatt syntaksproblemet og feilteksten vil navngi den nye klassen. Hold den redigerte filen i versjonskontroll ved siden av et notat som navngir OpenVPN-utgivelsen den retter seg mot.