Hvorfor stoppede OpenVPN med at forbinde efter en Ubuntu-opgradering?

VPN-profiler, der virkede i sidste uge, brækker efter en Ubuntu-udgivelsesopgradering, og loggen nævner sjældent opgraderingen. Det, den nævner, er det lag, der fejlede: TLS-håndtrykket, den cipher, der blev forhandlet til datakanalen, pakken der blev installeret, eller den OpenSSL-kopi som binæren indlæser ved start. Hvert lag har sin egen fejlform og sin egen reparation, så klassifikation er det første arbejde og redigering det andet. Behandl profilen som uskyldig, indtil loggen nævner den.

Hvilket lag fejlede: håndtryk, cipher, pakke eller bibliotek

Læs klientloggen, før du rører profilen. Den tidligste fejl i outputtet er den, der udpeger laget; alt trykt efter den er som regel følger af den første fejl. Når klienten slet ikke starter, er VPN-loggen den forkerte fil at åbne.

Klager over certifikater og signaturer eller en besked om nøglelængde kommer fra kontrolkanalen og den bibliotekspolitik, der styrer den. En advarsel, der begynder med DEPRECATED OPTION hører derimod til forhandlingen af datakanalen.

En linje som Unrecognized option er en tredje kategori: den nye binær accepterer ikke længere et direktiv, som den gamle tolererede, så profilen skal skrives om, i stedet for at biblioteket skal lempes. Pakkefejl ser igen anderledes ud, fordi de sker, før nogen tunnelkode kører. En manglende binær, et plugin der ikke indlæses, eller et repository, der peger på det forkerte kodenavn, giver alle den form. Fire symptomer, fire steder at kigge, og næsten ingen overlapning mellem reparationerne.

Når håndtrykket fejler, afviser TLS-politikken certifikatet

Ubuntu 22.04 flyttede systemet til OpenSSL 3, og standard-sikkerhedsniveauet i den gren er strengere om certifikatsignaturer og nøglestørrelser, end 20.04 var. Et CA-certifikat signeret med et ældre digest eller en nøgle under den nuværende tærskel fejler nu under håndtrykket. Da intet er autentificeret endnu, lyder fejlen som en forkert adgangskode eller en død server.

Den snævre reparation knytter en cipher-streng til netop denne forbindelse. Åbn profilen i skrivebordseditoren, skift til de avancerede indstillinger, og sæt DEFAULT:@SECLEVEL=0 i TLS-cipher-feltet. NetworkManager-nøglefilen tager samme værdi under [vpn]:

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

Genstart NetworkManager og tilslut igen, for daemonen cacher parsede profiler og vil ellers blive ved med at bruge den kopi, den allerede har. Vid, hvad linjen gør, før du beholder den: indstillingen er en tærskel på tværs af flere certifikat- og nøgleparametre, ikke et cipher-navn, så en sænkning udvider, hvad den enkelte profil accepterer. Notér, hvilken server der krævede det, og slip indstillingen, når operatøren udsteder aktuelt materiale igen. At ændre /etc/ssl/openssl.cnf rammer samme tærskel for ethvert program, der læser den fil, hvilket ligger langt ud over VPN'et.

OpenVPN 2.6 kræver cipheren angivet til forhandling

Ubuntu 22.10 leverede OpenVPN 2.6, og i den udgivelse holder --cipher op med selv at vælge datakanalen. Cipheren skal også være med i den forhandlede data-ciphers-liste, ellers udskriver klienten en forældelsesadvarsel og formår derefter ikke at rejse tunnelen.

NetworkManager-pluginet fra samme periode skrev stadig kun det gamle direktiv. Den detalje deler diagnosen, for en profil rettet i hånden kan forbinde fra en shell og alligevel fejle fra skrivebordsappletten. Føj listen til forbindelsesfilen under [vpn]:

data-ciphers=AES-256-CBC

Brug den værdi, serveren annoncerer, ikke den du husker; en server, der udbyder AES-256-GCM, forhandler ikke med en klientliste, der kun nævner CBC. Genstart manageren og tilslut igen, og gentag så forsøget fra en shell med cipheren angivet eksplicit til både forhandling og fallback:

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

Rejser den kommando tunnelen, er serveren, certifikaterne og adgangsoplysningerne alle sunde, og den eneste resterende fejl er managerens gemte indstilling. En advarsel om direktivet keysize hører til samme oprydning: kommentér den ud, og gem originalfilen ved siden af profilen.

Pakke- og pluginfjæld ligner VPN-fejl

Ikke hvert fejlslagne forsøg efter opgraderingen er kryptografisk. Et OpenVPN-repository tilføjet under et kodenavn, som udgivelsen ikke bruger, giver en pakke, der aldrig installeres, så sammenlign, hvad lsb_release -a rapporterer, med den listefil, du tilføjede. En manglende universe-komponent eller sikkerhedslomme giver en pakke, der slet ikke kan findes. Begge tilfælde lader profilen urørt og tunnelen umulig.

Læs pakkehåndteringens fejl før VPN-loggen. Blev klienten aldrig installeret, giver ingen mængde profilredigering et håndtryk.

To-faktor-profiler, der holder op med at spørge, er plugin-versionen af den samme historie. Udfordringen kommer fra et autentificeringsplugin, og en opgradering, der droppede eller erstattede det, lader profilen intakt, mens forespørgslen forsvinder. Geninstaller det understøttede plugin i stedet for at slette den anden faktor for at få forbindelsen til at virke.

Et leverandørbibliotek kan gemme sig bag en politikfejl

Et mønster fortjener genkendelse, fordi det slår enhver politikreparation. Et konfigurationsværktøj fra en hardwareleverandør kan installere sine egne OpenSSL-biblioteker og placere dem foran systemkopierne i loaderens søgesti. Klienten starter så mod et bibliotek, som ingen har opgraderet, og startfejlen ligner præcis et afvist certifikat.

Geninstallation af VPN-pakken ændrer ikke, hvilket bibliotek der findes først, og en sænkning af TLS-niveauet kan ikke nå et bibliotek, der aldrig kom fra systemet. Spørg loaderen, hvilke kryptoobjekter binæren faktisk opløser:

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

Fjern eller ompeg leverandørkopien, og kør derefter den samme kontrol igen. Den forventede version skal være den, der er i brug, før du vender tilbage til profilen.

At fastholde en ældre klient køber tid, ikke en løsning

At holde den forrige klientversion tilbage genskaber tunnelen, så længe holdet varer. Det fryser også sikkerhedsopdateringer for den pakke og planlægger samme brud til næste opgradering, så behandl det som en dateret midlertidig løsning, ikke en løsning.

Hvis du alligevel fastholder den, hold pakken eksplicit, så en uovervåget opgradering ikke kan ophæve fastHoldet, skriv årsagen og datoen ned til genovervejelse, og sæt en påmindelse til udbyderens næste profiludgivelse. Betingelsen, der er værd at holde øje med, er en serverprofil, der forhandler en aktuel cipher; når den findes, har fastHoldet ingen begrundelse tilbage. Et uregistreret fastHold bliver derimod et udfald, som ingen kan forklare et halvt år senere, fordi personen, der satte det, er flyttet videre, og filen registrerer intet.

Næste gang en VPN dør efter en udgivelsesopgradering, stil fem spørgsmål i rækkefølge: hvilket lag gav den første fejl, afviste TLS-politikken certifikatet, kan cipheren forhandles i begge retninger, blev pakken og dens plugin faktisk installeret, og hvilket bibliotek indlæser processen. Først når alle fem kommer rent tilbage, giver en nedgradering mening.