Ou .ovpn-profiel werk nie meer op Ubuntu 24.04 nie: watter reëls moet weg

Die profiel laai af, voer in en stop dan by reël 12 van die lêer met die boodskap Unrecognized option wat keysize noem. Niks omtrent die rekening het verander nie, en die bediener aanvaar steeds ander kliënte. Wat verander het, is die kliënt self: Ubuntu 24.04 installeer OpenVPN 2.6, terwyl die uitvoer teen 2.4 geskryf is. Die regstelling is 'n kort reeks verwyderings, en die volgorde maak saak, want elke verouderde opsie breek die ontleding af voordat die volgende een ooit gelees word.

Lees eers die foutreël voordat jy die lêer aanraak

OpenVPN noem die lêer en die reël waar die ontleding gestop het, so jy kan net een probleem per lopie regmaak. Begin die profiel vanaf 'n terminaal eerder as 'n werkskermtoepassing, want die toepassing sluk gewoonlik stderr en die reël nommer is die enigste betroubare aanduiding wat jy kry: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Maak daardie reël reg, hardloop weer, en verwag dat die volgende fout 'n ander opsie sal noem.

'n Ontledingsfout verskyn altyd voor enige TLS-handskud, so 'n boodskap wat 'n sertifikaat noem, het reeds die sintaksfase verby. Daardie onderskeid keer dat jy 'n lêer wysig wat net op verifikasie misluk. Lees die eerste woord van die boodskap, nie die middel daarvan nie.

Drie foutklasse, drie verskillende herstellings

Ou uitvoere misluk op drie onderskeibare maniere, en om hulle in een probleem saam te vat, is hoekom mense pakette herinstalleer wat nooit stukkend was nie. Die bewoording van die boodskap sê vir jou in watter klas jy is voordat jy die lêer oopmaak.

• Ontledingsfoute noem 'n lêer en 'n reël en stop voordat enige verkeer bestaan.
• Onderhandelingsfoute maak verbinding en rapporteer dan dat die twee kante nie oor 'n gedeelde syfer of 'n aanvaarbare datakanaal kon saamstem nie.
• Verifikasiefoute kom die verste en noem 'n sertifikaat, 'n gebruiker of 'n verwerpte geloofsbrief.

'n Profielwysiging maak net die eerste klas reg. Onderhandeling verg 'n besluit aan beide kante van die tonnel, en 'n verwerpte geloofsbrief is glad nie 'n sintaksprobleem nie. As jou boodskap 'n gedeelde syfer of 'n datakanaal noem, sal die verwyderings hieronder niks verander nie.

Verwyder die opsies wat 2.6 verwyder het, in hierdie volgorde

Elkeen van hierdie reëls stop die ontleding op sy eie, so die kliënt rapporteer hulle een op 'n slag. Werk die lys af en hardloop weer na elke verwydering.

Verwyder keysize eerste, want dit het geen moderne ekwivalent nie en die teenwoordigheid daarvan dui gewoonlik op 'n syfer wat die huidige kliënt in elk geval weier. Verwyder dan ncp-disable, wat syferonderhandeling beheer het, in 2.5 afgeskaf is en in 2.6 weg is. Vervang ns-cert-type server met remote-cert-tls server, wat dieselfde bedoeling deur 'n ondersteunde kontrole uitdruk. Die 2.6-veranderingsgeskiedenis lys die oorblywende verwyderings langs hul plaasvervangers, so enigiets wat die ontleder steeds verwerp, het 'n gedokumenteerde antwoord.

Hou 'n kopie van die oorspronklike profiel voor die eerste wysiging. Verskaffers regenereer uitvoere, en 'n diff teen die onaangeraakte lêer is die vinnigste manier om jou veranderinge van hulle s'n te skei. As 'n verwydering die kliënt laat begin maar die tonnel steeds misluk, het jy na die onderhandelingsklas beweeg en is die oorblywende reëls nie die oorsaak nie. Sit die kliëntweergawe in die lêernaam sodat die volgende persoon weet watter vrystelling die wysigings teiken.

Hou BF-CBC net as 'n beperkte terugval aan die gang

Sommige verskaffers termineer steeds op BF-CBC, wat OpenVPN 2.6 nie sonder hulp sal onderhandel nie, want die syfer het 'n 64-bis-blok. Die nou regstelling is 'n terugvallys plus die OpenSSL-legacy-provider, nie 'n afgradering van die hele kliënt nie.

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

Die eerste reël laai die legacy-provider sodat OpenSSL daardie syfer steeds kan instansieer, die tweede hou moderne onderhandeling vir eweknieë wat dit ondersteun, en die derde geld net wanneer die bediener niks beters bied nie. Dit is 'n doelbewuste verswakking van die tonnel, so teken aan waarom dit bestaan langs die lêer. Vra terselfdertyd vir die verskaffer 'n hergenererte uitvoer, want die terugval is 'n brug, nie 'n bestemming nie.

Moenie na --compat-mode gryp as 'n algemene antwoord nie. Dit verander verskeie gedragte tegelyk, insluitend die verstekke vir onderhandeling en heronderhandeling, so jy leer nooit watter verandering saak gemaak het nie. Verkies eerder die drie eksplisiete reëls hierbo, want elkeen sê sy eie effek.

Verifieer met die profiel wat die kliënt werklik laai

Ingevoerde verbindings word dikwels na 'n stelselgids gekopieer, so om die lêer in jou aflaai-gids te wysig, kan heeltemal niks verander nie. Vind die kopie wat loop: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Begin dan die tonnel en lees die logreël wat die datakanaal-syfer rapporteer wat werklik gekies is. 'n Verbinding wat die handskud op die terugval voltooi, sê vir jou die bediener het nooit iets moderns aangebied nie.

Toets vanaf 'n netwerk wat nie die een is wat die verskaffer verwag nie, sodat 'n captive portal of 'n gefiltreerde gasnetwerk nie as 'n profielfout voordoen nie. Teken die kliëntweergawe aan saam met enige ondersteuningsversoek.

Sodra die tonnel op is, stuur een versoek wat dit moet kruis en een wat dit nie moet nie, en bevestig dan dat die antwoord van die resolver verander het soos jy verwag het. As die profiel nou ontleed maar die verbinding steeds misluk, het jy die sintaksprobleem agter gelaat en die foutteks sal die nuwe klas noem. Hou die gewysigde lêer in weergawebeheer langs 'n nota wat die OpenVPN-vrystelling noem wat dit teiken.