Oud .ovpn-profiel faalt op Ubuntu 24.04: welke regels u moet verwijderen

Het profiel wordt gedownload, geïmporteerd en stopt dan bij regel 12 van het bestand met een Unrecognized option-melding die keysize noemt. Aan het account is niets veranderd en de server accepteert nog steeds andere clients. Wat is veranderd, is de client zelf: Ubuntu 24.04 installeert OpenVPN 2.6, terwijl de export voor 2.4 is geschreven. De reparatie is een korte reeks verwijderingen, en de volgorde is belangrijk omdat elke verouderde optie het parsen afbreekt voordat de volgende ooit wordt gelezen.

Lees de foutregel voordat u het bestand aanraakt

OpenVPN noemt het bestand en de regel waar het parsen stopte, dus u kunt per run maar één probleem oplossen. Start het profiel vanuit een terminal in plaats van een desktopapplet, omdat de applet meestal stderr inslikt en het regelnummer de enige betrouwbare aanwijzing is die u krijgt: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Repareer die regel, voer opnieuw uit en verwacht dat de volgende fout een andere optie noemt.

Een parsefout verschijnt altijd vóór enige TLS-handshake, dus een melding die een certificaat noemt, is al voorbij de syntaxis-fase. Dat onderscheid weerhoudt u ervan een bestand te bewerken dat alleen op authenticatie faalt. Lees het eerste woord van de melding en niet het midden.

Drie faalklassen, drie verschillende reparaties

Oude exports falen op drie herkenbare manieren, en het samenvoegen daarvan tot één probleem is waarom mensen pakketten herinstalleren die nooit kapot waren. De bewoording van de melding vertelt u in welke klasse u zit voordat u het bestand opent.

• Parsefouten noemen een bestand en een regel, en stoppen voordat er enig verkeer bestaat.
• Onderhandelingsfouten verbinden, en melden dan dat de twee uiteinden het niet eens konden worden over een gedeelde cipher of een acceptabel datakanaal.
• Authenticatiefouten komen het verst en noemen een certificaat, een gebruiker of een afgewezen referentie.

Een profielbewerking verhelpt alleen de eerste klasse. Onderhandeling vereist een beslissing aan beide uiteinden van de tunnel, en een afgewezen referentie is helemaal geen syntaxprobleem. Als uw melding een gedeelde cipher of een datakanaal noemt, veranderen de verwijderingen hieronder niets.

Verwijder de opties die 2.6 heeft geschrapt, in deze volgorde

Elk van deze regels stopt het parsen op zichzelf, dus de client meldt ze één voor één. Werk de lijst af en voer na elke verwijdering opnieuw uit.

Verwijder eerst keysize, omdat het geen moderne equivalent heeft en de aanwezigheid ervan meestal een cipher markeert die de huidige client sowieso weigert. Verwijder daarna ncp-disable, dat de cipheronderhandeling regelde, in 2.5 is verouderd en in 2.6 is verdwenen. Vervang ns-cert-type server door remote-cert-tls server, dat dezelfde bedoeling uitdrukt via een ondersteunde controle.Wijzigingsgeschiedenis van 2.6 vermeldt de resterende verwijderingen naast hun vervangingen, dus alles wat de parser nog weigert, heeft een gedocumenteerd antwoord.

Bewaar een kopie van het oorspronkelijke profiel vóór de eerste bewerking. Providers genereren exports opnieuw, en een diff met het onaangeroerde bestand is de snelste manier om uw wijzigingen van die van hen te scheiden. Als een verwijdering de client laat starten maar de tunnel nog steeds faalt,bent u in de onderhandelingsklasse beland en zijn de resterende regels niet de oorzaak. Zet de clientversie in de bestandsnaam zodat de volgende persoon weet op welke release de bewerkingen zijn gericht.

Houd BF-CBC alleen als begrensde fallback aan de gang

Sommige providers beëindigen nog steeds op BF-CBC, dat OpenVPN 2.6 niet zonder hulp wil onderhandelen omdat de cipher een blok van 64 bits heeft. De nauwe oplossing is een fallbacklijst plus de legacy-provider van OpenSSL, niet een downgrade van de hele client.

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

De eerste regel laadt de legacy-provider zodat OpenSSL die cipher nog kan instantiëren, de tweede houdt moderne onderhandeling voor peers die dat ondersteunen, en de derde geldt alleen wanneer de server niets beters biedt. Dat is een bewuste verzwakking van de tunnel, dus noteer waarom die bestaat naast het bestand. Vraag de provider tegelijk om een opnieuw gegenereerde export, want de fallback is een brug en geen bestemming.

Grijp niet naar --compat-mode als algemeen antwoord. Het verandert meerdere gedragingen tegelijk, inclusief de standaardwaarden voor onderhandeling en heronderhandeling, dus u leert nooit welke wijziging ertoe deed. Geef de drie expliciete regels hierboven de voorkeur, omdat elk zijn eigen effect vermeldt.

Verifieer met het profiel dat de client daadwerkelijk laadt

Geïmporteerde verbindingen worden vaak naar een systeemmap gekopieerd, dus het bewerken van het bestand in uw downloadmap kan helemaal niets veranderen. Zoek de kopie die draait: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Start dan de tunnel en lees de logregel die meldt welke datakanaal-cipher daadwerkelijk is gekozen. Een verbinding die de handshake op de fallback voltooit, vertelt u dat de server nooit iets moderns heeft aangeboden.

Test vanaf een netwerk dat niet het netwerk is dat de provider verwacht, zodat een captive portal of een gefilterd gastnetwerk zich niet voordoet als een profielstoring. Noteer de clientversie bij elk supportverzoek.

Zodra de tunnel staat, stuurt u één verzoek dat erdoorheen moet en één dat dat niet mag, en bevestigt u daarna dat het resolver-antwoord veranderde zoals u verwachtte. Als het profiel nu wordt geparseerd maar de verbinding nog steeds faalt, hebt u het syntaxprobleem achter u gelaten en noemt de fouttekst de nieuwe klasse. Houd het bewerkte bestand in versiebeheer naast een notitie die de OpenVPN-release noemt waarop het is gericht.