Gammal .ovpn-profil misslyckas på Ubuntu 24.04: vilka rader du ska ta bort

Profilen laddas ner, importeras och stannar sedan på rad 12 i filen med ett Unrecognized option-meddelande som namnger keysize. Ingenting på kontot har ändrats, och servern accepterar fortfarande andra klienter. Det som ändrades är klienten själv: Ubuntu 24.04 installerar OpenVPN 2.6, medan exporten skrevs för 2.4. Reparationen är en kort serie borttagningar, och ordningen spelar roll eftersom varje föråldrat alternativ avbryter tolkningen innan nästa ens läses.

Läs felraden innan du rör filen

OpenVPN namnger filen och raden där tolkningen stoppade, så du kan bara åtgärda ett problem per körning. Starta profilen från en terminal i stället för en skrivbordsapplet, eftersom appletten oftast sväljer stderr och radnumret är den enda tillförlitliga pekare du får: sudo openvpn --config /etc/openvpn/client/provider.ovpn. Åtgärda den raden, kör igen och förvänta dig att nästa fel namnger ett annat alternativ.

Ett tolkningsfel visas alltid före någon TLS-handskakning, så ett meddelande som nämner ett certifikat har redan passerat syntaxsteget. Den skillnaden hindrar dig från att redigera en fil som bara misslyckas vid autentisering. Läs det första ordet i meddelandet och inte mitten av det.

Tre felklasser, tre olika reparationer

Gamla exporter misslyckas på tre urskiljbara sätt, och att slå ihop dem till ett problem är anledningen till att folk installerar om paket som aldrig var trasiga. Meddelandets formulering berättar vilken klass du är i innan du öppnar filen.

• Tolkningsfel namnger en fil och en rad och stoppar innan någon trafik finns.
• Förhandlingsfel ansluter och rapporterar sedan att de två ändarna inte kunde enas om ett delat chiffer eller en godtagbar datakanal.
• Autentiseringsfel kommer längst och namnger ett certifikat, en användare eller en avvisad inloggningsuppgift.

En profilredigering åtgärdar bara den första klassen. Förhandling kräver ett beslut i båda ändar av tunneln, och en avvisad inloggningsuppgift är inte alls ett syntaxproblem. Om ditt meddelande nämner ett delat chiffer eller en datakanal kommer borttagningarna nedan inte att ändra något.

Ta bort alternativen som 2.6 tog bort, i den här ordningen

Var och en av dessa rader stoppar tolkningen på egen hand, så klienten rapporterar dem en i taget. Arbeta dig nedåt i listan och kör igen efter varje borttagning.

Ta bort keysize först, eftersom det inte har någon modern motsvarighet och dess närvaro brukar markera ett chiffer som den nuvarande klienten ändå vägrar. Ta sedan bort ncp-disable, som styrde chifferförhandlingen, avvecklades i 2.5 och är borta i 2.6. Ersätt ns-cert-type server med remote-cert-tls server, som uttrycker samma avsikt genom en kontroll som stöds.Ändringshistorik för 2.6 listar de återstående borttagningarna bredvid sina ersättningar, så allt som tolken fortfarande avvisar har ett dokumenterat svar.

Spara en kopia av originalprofilen före den första redigeringen. Leverantörer återskapar exporter, och en diff mot den orörda filen är det snabbaste sättet att skilja dina ändringar från deras. Om en borttagning låter klienten starta men tunneln fortfarande misslyckas,har du flyttat in i förhandlingsklassen och de återstående raderna är inte orsaken. Sätt klientversionen i filnamnet så att nästa person vet vilken utgåva redigeringarna riktar sig till.

Håll BF-CBC igång endast som en avgränsad reservlösning

Vissa leverantörer avslutar fortfarande på BF-CBC, som OpenVPN 2.6 inte förhandlar utan hjälp eftersom chiffret har ett 64-bitars block. Den snäva reparationen är en reservlista plus OpenSSL:s legacy-leverantör, inte en nedgradering av hela klienten.

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

Den första raden laddar legacy-leverantören så att OpenSSL fortfarande kan instansiera det chiffret, den andra behåller modern förhandling för par som stöder det, och den tredje gäller bara när servern inte erbjuder något bättre. Det är en medveten försvagning av tunneln, så anteckna varför den finns bredvid filen. Be leverantören om en återskapad export samtidigt, eftersom reserven är en bro och inte en destination.

Ta inte till --compat-mode som ett generellt svar. Det ändrar flera beteenden på en gång, inklusive standardvärden för förhandling och omförhandling, så du får aldrig veta vilken ändring som spelade roll. Föredra de tre uttryckliga raderna ovan, eftersom var och en anger sin egen effekt.

Verifiera med den profil som klienten faktiskt läser in

Importerade anslutningar kopieras ofta till en systemkatalog, så att redigera filen i din nedladdningsmapp kan inte ändra någonting alls. Hitta kopian som körs: sudo grep -rl "remote " /etc/NetworkManager/system-connections /etc/openvpn. Starta sedan tunneln och läs loggraden som rapporterar vilket datakanalchiffer som faktiskt valdes. En anslutning som slutför handskakningen på reserven säger att servern aldrig erbjöd något modernt.

Testa från ett nätverk som inte är det leverantören förväntar sig, så att en captive portal eller ett filtrerat gästnätverk inte utger sig för att vara ett profilfel. Anteckna klientversionen tillsammans med varje supportförfrågan.

När tunneln är uppe, skicka en förfrågan som måste korsa den och en som inte får, och bekräfta sedan att resolver-svaret ändrades som du förväntade dig. Om profilen nu tolkas men anslutningen fortfarande misslyckas har du lämnat syntaxproblemet bakom dig och feltexten kommer att namnge den nya klassen. Håll den redigerade filen i versionskontroll bredvid en anteckning som namnger den OpenVPN-utgåva den riktar sig till.