Varför slutade OpenVPN ansluta efter en Ubuntu-uppgradering?

VPN-profiler som fungerade förra veckan går sönder efter en Ubuntu-utgåveuppgradering, och loggen nämner sällan uppgraderingen. Det den namnger är lagret som misslyckades: TLS-handskakningen, cifret som förhandlades för datakanalen, paketet som installerades eller OpenSSL-kopian som binären laddar vid start. Varje lager har sin egen felform och sin egen reparation, så klassificering är första arbetet och redigering det andra. Behandla profilen som oskyldig tills loggen namnger den.

Vilket lager misslyckades: handskakning, cipher, paket eller bibliotek

Läs klientloggen innan du rör profilen. Det tidigaste felet i utdata är det som identifierar lagret; allt som skrivs ut efteråt är vanligen följden av det första felet. När klienten inte startar alls är VPN-loggen fel fil att öppna.

Klagomål på certifikat och signaturer, eller ett meddelande om nyckellängd, kommer från kontrollkanalen och den bibliotekspolicy som styr den. En varning som börjar med DEPRECATED OPTION hör i stället till förhandlingen av datakanalen.

En rad som Unrecognized option är en tredje kategori: den nya binären accepterar inte längre ett direktiv som den gamla tolererade, så profilen måste skrivas om i stället för att biblioteket mjukas upp. Paketfel ser åter annorlunda ut eftersom de inträffar innan någon tunnelkod körs. En saknad binär, en plugin som inte laddas eller ett arkiv som pekar på fel kodnamn ger alla den formen. Fyra symtom, fyra ställen att titta på och nästan ingen överlappning mellan reparationerna.

När handskakningen misslyckas avvisar TLS-policyn certifikatet

Ubuntu 22.04 flyttade systemet till OpenSSL 3, och standard säkerhetsnivå i den grenen är strängare mot certifikatsignaturer och nyckelstorlekar än 20.04 var. Ett CA-certifikat signerat med en äldre digest, eller en nyckel under nuvarande tröskel, misslyckas nu under handskakningen. Eftersom inget har autentiserats än läses felet som ett felaktigt lösenord eller en död server.

Den snäva reparationen fäster en cipher-sträng bara vid den här anslutningen. Öppna profilen i skrivbordsredigeraren, gå till avancerade inställningar och sätt DEFAULT:@SECLEVEL=0 i TLS-cipherfältet. NetworkManager-nyckelfilen tar samma värde under [vpn]:

[vpn]
tls-cipher=DEFAULT:@SECLEVEL=0

Starta om NetworkManager och anslut igen, eftersom daemonen cachar tolkade profiler och annars fortsätter använda kopian den redan har. Vet vad raden gör innan du behåller den: inställningen är en tröskel över flera certifikat- och nyckelparametrar, inte ett cipher-namn, så att sänka den vidgar vad den enskilda profilen accepterar. Notera vilken server som krävde den och släpp inställningen när operatören ger ut aktuellt material igen. Att ändra /etc/ssl/openssl.cnf når samma tröskel för varje program som läser filen, vilket ligger långt utanför VPN:en.

OpenVPN 2.6 kräver cifret listat för förhandling

Ubuntu 22.10 levererade OpenVPN 2.6, och i den utgåvan slutar --cipher att själv välja datakanalen. Cifret måste också finnas i den förhandlade data-ciphers-listan, annars skriver klienten ut en utfasad varning och lyckas sedan inte resa tunneln.

NetworkManager-pluginen från samma period skrev fortfarande bara det gamla direktivet. Den detaljen delar diagnosen, eftersom en profil som rättats för hand kan ansluta från ett skal och ändå misslyckas från skrivbordsappletten. Lägg till listan i anslutningsfilen under [vpn]:

data-ciphers=AES-256-CBC

Använd värdet servern annonserar, inte det du minns; en server som erbjuder AES-256-GCM förhandlar inte med en klientlista som bara nämner CBC. Starta om hanteraren och anslut igen, upprepa sedan försöket från ett skal med cifret uttryckligen angivet för både förhandling och reserv:

sudo openvpn --config client.ovpn --data-ciphers AES-256-CBC --data-ciphers-fallback AES-256-CBC

Om det kommandot reser tunneln är servern, certifikaten och inloggningsuppgifterna alla sunda, och det enda kvarvarande felet är hanterarens sparade inställning. En varning om direktivet keysize hör till samma städning: kommentera bort det och behåll originalfilen bredvid profilen.

Paket- och pluginfel ser ut som VPN-fel

Inte varje fel efter uppgraderingen är kryptografiskt. Ett OpenVPN-arkiv tillagt under ett kodnamn som utgåvan inte använder ger ett paket som aldrig installeras, så jämför vad lsb_release -a rapporterar med listfilen du lade till. En saknad universe komponent eller säkerhetsficka ger ett paket som inte går att hitta alls. Båda fallen lämnar profilen orörd och tunneln omöjlig.

Läs pakethanterarens fel före VPN-loggen. Installerades klienten aldrig ger ingen mängd profilredigering en handskakning.

Tvåfaktorprofiler som slutar fråga är plugin-versionen av samma historia. Utmaningen kommer från en autentiseringsplugin, och en uppgradering som tog bort eller ersatte den lämnar profilen intakt medan frågan försvinner. Installera om den stödda pluginen i stället för att radera den andra faktorn för att anslutningen ska fungera.

Ett leverantörsbibliotek kan gömma sig bakom ett policyfel

Ett mönster förtjänar igenkänning eftersom det besegrar varje policyreparation. Ett konfigurationsverktyg från en hårdvaruleverantör kan installera egna OpenSSL-bibliotek och placera dem före systemkopiorna i lastarens sökväg. Klienten startar då mot ett bibliotek som ingen har uppgraderat, och startfelet ser exakt ut som ett avvisat certifikat.

Att installera om VPN-paketet ändrar inte vilket bibliotek som hittas först, och att sänka TLS-nivån når inte ett bibliotek som aldrig kom från systemet. Fråga lastaren vilka kryptoobjekt binären faktiskt löser upp:

ldd /usr/sbin/openvpn | grep -i -E 'ssl|crypto'

Ta bort eller peka om leverantörens kopia och kör sedan samma kontroll igen. Den förväntade versionen måste vara den som används innan du återvänder till profilen.

Att fästa en äldre klient köper tid, inte en lösning

Att hålla kvar föregående klientversion återställer tunneln så länge hållningen varar. Det fryser också säkerhetsuppdateringarna för paketet och schemalägger samma brott för nästa uppgradering, så behandla det som en daterad tillfällig lösning, inte en lösning.

Om du ändå fäster det, håll paketet uttryckligen så att en övervakad uppgradering inte kan upphäva fästningen, skriv ned orsaken och datumet för omprövning och ställ in en påminnelse för leverantörens nästa profilutgåva. Villkoret som är värt att följa är en serverprofil som förhandlar ett aktuellt cipher; när det finns har fästningen ingen motivering kvar. En oregistrerad fästning blir däremot ett avbrott som ingen kan förklara ett halvår senare, eftersom personen som tillämpade den har gått vidare och filen registrerar ingenting.

Nästa gång en VPN dör efter en utgåveuppgradering, ställ fem frågor i följd: vilket lager gav det första felet, avvisade TLS-policyn certifikatet, går cifret att förhandla i båda riktningarna, installerades paketet och dess plugin verkligen, och vilket bibliotek laddar processen. Först när alla fem kommer tillbaka rena har en nedgradering någon mening.