Gammel .ovpn-profil fejler på Ubuntu 24.04: hvilke linjer skal slettes

Profilen hentes, importeres og stopper derefter på linje 12 i filen med en Unrecognized option-meddelelse, der nævner keysize. Intet ved kontoen er ændret, og serveren accepterer stadig andre klienter. Det er klienten selv, der er ændret: Ubuntu 24.04 installerer OpenVPN 2.6, mens eksporten blev skrevet til 2.4. Rettelsen er en kort serie sletninger, og rækkefølgen betyder noget, fordi hver forældet valgmulighed afbryder parsingen, før den næste overhovedet læses.

Læs fejlens linje, før du rører ved filen

OpenVPN angiver filen og den linje, hvor parsingen stoppede, så du kan kun rette ét problem ad gangen. Start profilen fra en terminal i stedet for fra et skrivebordsprogram, fordi programmet normalt sluger stderr, og linjenummeret er det eneste pålidelige pejlemærke, du får: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Ret den linje, kør igen, og forvent, at den næste fejl nævner en anden valgmulighed.

En parsefejl vises altid før et TLS-håndtryk, så en meddelelse, der nævner et certifikat, har allerede passeret syntaksfasen. Den forskel forhindrer dig i at redigere en fil, der kun fejler på godkendelse. Læs det første ord i meddelelsen i stedet for midten af den.

Tre fejlklasser, tre forskellige rettelser

Gamle eksporter fejler på tre forskellige måder, og netop det at slå dem sammen til ét problem får folk til at geninstallere pakker, der aldrig var i stykker. Meddelelsens ordlyd fortæller dig, hvilken klasse du er i, før du åbner filen.

• Parsefejl angiver en fil og en linje og stopper, før der findes nogen trafik.
• Forhandlingsfejl opretter forbindelse og rapporterer derefter, at de to ender ikke kunne blive enige om et fælles cipher eller en acceptabel datakanal.
• Godkendelsesfejl når længst og angiver et certifikat, en bruger eller en afvist adgangsdetalje.

En profilændring retter kun den første klasse. Forhandling kræver en beslutning i begge ender af tunnelen, og en afvist adgangsdetalje er slet ikke et syntaksproblem. Hvis din meddelelse nævner et fælles cipher eller en datakanal, ændrer sletningerne nedenfor ingenting.

Slet de valgmuligheder, som 2.6 har fjernet, i denne rækkefølge

Hver af disse linjer standser parsingen alene, så klienten rapporterer dem én ad gangen. Arbejd dig ned ad listen, og kør igen efter hver sletning.

Slet keysize først, fordi det ikke har nogen moderne ækvivalent, og dets tilstedeværelse markerer normalt et cipher, som den nuværende klient alligevel afviser. Slet derefter ncp-disable, som styrede cipher-forhandlingen, blev forældet i 2.5 og er væk i 2.6. Erstat ns-cert-type server med remote-cert-tls server, som udtrykker den samme hensigt gennem et understøttet tjek. 2.6-ændringshistorikken lister de resterende fjernelser op ved siden af deres erstatninger, så alt, hvad parseren stadig afviser, har et dokumenteret svar.

Gem en kopi af den originale profil før den første redigering. Udbyderne genskaber eksporter, og en diff mod den urørte fil er den hurtigste måde at skelne dine ændringer fra deres. Hvis en sletning får klienten til at starte, men tunnelen stadig fejler, er du flyttet til forhandlingsklassen, og de resterende linjer er ikke årsagen. Sæt klientversionen i filnavnet, så den næste person ved, hvilken udgivelse redigeringerne sigter mod.

Hold kun BF-CBC kørende som en afgrænset reserveløsning

Nogle udbydere afslutter stadig på BF-CBC, som OpenVPN 2.6 ikke vil forhandle uden hjælp, fordi cipher har en 64-bit blok. Den snævre rettelse er en reserve-liste plus den gamle OpenSSL-udbyder, ikke en nedgradering af hele klienten.

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

Den første linje indlæser den gamle udbyder, så OpenSSL stadig kan skabe det cipher, den anden bevarer moderne forhandling for peers, der understøtter det, og den tredje gælder kun, når serveren ikke tilbyder noget bedre. Det er en bevidst svækkelse af tunnelen, så noter hvorfor den findes ved siden af filen. Bed samtidig udbyderen om en genskabt eksport, fordi reserven er en bro og ikke en destination.

Grib ikke efter --compat-mode som et universelt svar. Det ændrer flere adfærdsformer på én gang, herunder standarderne for forhandling og genforhandling, så du lærer aldrig, hvilken ændring der gjaldt. Foretræk de tre eksplicitte linjer ovenfor, fordi hver af dem angiver sin egen virkning.

Kontrollér med den profil, som klienten faktisk indlæser

Importerede forbindelser kopieres ofte til en systemmappe, så redigering af filen i din downloadmappe kan ændre absolut intet. Find den kopi, der kører: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Start derefter tunnelen, og læs den loglinje, der rapporterer, hvilket cipher til datakanalen der faktisk blev valgt. En forbindelse, der fuldfører håndtrykket på reserven, fortæller dig, at serveren aldrig tilbød noget moderne.

Test fra et netværk, der ikke er det, udbyderen forventer, så en captive portal eller et filtreret gæstenetværk ikke optræder som en profilfejl. Noter klientversionen sammen med enhver supportanmodning.

Når tunnelen er oppe, send én anmodning, der skal krydse den, og én der ikke skal, og bekræft derefter, at resolverens svar ændrede sig, som du forventede. Hvis profilen nu parses, men forbindelsen stadig fejler, har du efterladt syntaksproblemet og fejlteksten vil angive den nye klasse. Hold den redigerede fil i versionskontrol ved siden af en note, der angiver den OpenVPN-udgivelse, den sigter mod.