Kvifor slutta OpenVPN å kopla til etter ei Ubuntu-oppgradering?

VPN-profilar som fungerte førre veke, knekk etter ei Ubuntu-utgåveoppgradering, og loggen nemner sjeldan oppgraderinga i det heile. Det han nemner, er laget som feila: TLS-handtrykket, cipheren som vart forhandla for datakanalen, pakken som vart installert, eller OpenSSL-kopien som binæra lastar ved oppstart. Kvart lag har si eiga feilform og si eiga reparasjon, så klassifisering er den første jobben og redigering den andre. Handsame profilen som uskuldig til loggen namngir han.

Kva lag feila: handtrykk, cipher, pakke eller bibliotek

Les klientloggen før du rører profilen. Den tidlegaste feilen i utdataa er den som identifiserer laget; alt som blir skrive ut etter han, er vanlegvis følgje av den første feilen. Når klienten ikkje startar i det heile, er VPN-loggen feil fil å opne.

Klager på sertifikat og signaturar, eller ei melding om nøkkellengd, kjem frå kontrollkanalen og bibliotekpolitikken som styrer han. Ei åtvaring som byrjar med DEPRECATED OPTION høyrer derimot til forhandlinga av datakanalen.

Ei line som Unrecognized option er ein tredje kategori: den nye binæra godtek ikkje lenger eit direktiv den gamle tolererte, så profilen må skrivast om i staden for at biblioteket blir mjuka opp. Pakkefeil ser att annleis ut fordi dei skjer før nokon tunnelkode køyrer. Manglande binær, ein plugin som ikkje lastar, eller eit depot som peikar på feil kodenamn gjev alle den forma. Fire symptom, fire stader å sjå, og nesten inga overlapping mellom reparasjonane.

Når handtrykket feilar, avviser TLS-politikken sertifikatet

Ubuntu 22.04 flytta systemet til OpenSSL 3, og standard tryggleiksnivå i den greina er strengare på sertifikatsignaturar og nøkkelstorleikar enn 20.04 var. Eit CA-sertifikat signert med ein eldre digest, eller ein nøkkel under dagens terskel, feilar no under handtrykket. Sidan ingenting er autentisert enno, blir feilen lesen som eit feil passord eller ein død server.

Den smale reparasjonen festar ein cipher-streng berre til denne tilkoplinga. I skrivebordseditoren opnar du profilen, går til avanserte innstillingar og set DEFAULT:@SECLEVEL=0 i TLS-cipher-feltet. NetworkManager-nøkkelfila tek same verdi under [vpn]:

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

Start NetworkManager på nytt og kople til igjen, fordi daemonen cachar parsar av profilar og elles held fram med å bruke kopien han alt har. Vit kva lina gjer før du held henne: innstillinga er ein terskel over fleire sertifikat- og nøkkelparametrar, ikkje eit cipher-namn, så senking utvidar det den enkelte profilen godtek. Noter kva server som kravde det, og slepp innstillinga når operatøren gjev ut gjeldande materiale på nytt. Å endre /etc/ssl/openssl.cnf når same terskelen for kvart program som les den fila, noko som er langt utanfor VPN-en.

OpenVPN 2.6 krev cipheren oppført for forhandling

Ubuntu 22.10 leverte OpenVPN 2.6, og i den utgåva sluttar --cipher å velje datakanalen sjølv. Cipheren må også vere med i den forhandla data-ciphers-lista, elles skriv klienten ut ei utdateringsåtvaring og klarar deretter ikkje å reise tunnelen.

NetworkManager-pluginen frå same periode skreiv framleis berre det gamle direktivet. Den detaljen deler diagnosen, fordi ein profil retta for hand kan kople til frå eit skal og likevel feile frå skrivebordsappletten. Legg lista til tilkoplingsfila under [vpn]:

data-ciphers=AES-256-CBC

Bruk verdien serveren annonserer, ikkje den du hugsar; ein server som tilbyr AES-256-GCM forhandlar ikkje med ei klientliste som berre nemner CBC. Start handsamar på nytt og kople til igjen, og gjer så forsøket om att frå eit skal med cipheren gjeven eksplisitt for både forhandling og reserve:

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

Viss den kommandoen reiser tunnelen, er serveren, sertifikata og påloggingsdetaljane alle i orden, og den einaste gjenverande feilen er den lagra innstillinga til handsamaren. Ei åtvaring om direktivet keysize høyrer til same oppryddinga: kommenter det ut og oppbevar originalfila ved sida av profilen.

Pakke- og pluginfeil ser ut som VPN-feil

Ikkje kvar feil etter oppgraderinga er kryptografisk. Eit OpenVPN-depot lagt til under eit kodenamn utgåva ikkje brukar, gjev ein pakke som aldri blir installert, så samanlikn kva lsb_release -a rapporterer med listefila du la til. Ein manglande universe-komponent eller tryggleikslomme gjev ein pakke som ikkje kan finnast i det heile. Begge tilfella lèt profilen vere urørd og tunnelen umogleg.

Les feilen til pakkehandsamaren før VPN-loggen. Vart klienten aldri installert, gjev inga mengd profilredigering eit handtrykk.

Tofaktorprofilar som sluttar å spørje, er plugin-versjonen av same historia. Utfordringa kjem frå ein autentiseringsplugin, og ei oppgradering som sløyfa eller erstatta han, lèt profilen vere intakt medan førespurnaden forsvinn. Installer den støtta pluginen på nytt i staden for å slette den andre faktoren for å få tilkoplinga til å virke.

Eit leverandørbibliotek kan gøyme seg bak ein politikkfeil

Eitt mønster fortener attkjenning fordi det slår kvar politikkreparasjon. Eit konfigurasjonsverktøy frå ein maskinvareleverandør kan installere eigne OpenSSL-bibliotek og plassere dei framom systemkopiane i søkjestien til lastaren. Klienten startar då mot eit bibliotek ingen har oppgradert, og oppstartsfeilen ser nøyaktig ut som eit avvist sertifikat.

Reinstallasjon av VPN-pakken endrar ikkje kva bibliotek som blir funne først, og senking av TLS-nivået når ikkje eit bibliotek som aldri kom frå systemet. Spør lastaren kva kryptoobjekt binæra faktisk løyser opp:

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

Fjern eller ompeik leverandørkopien, og køyr så same kontrollen om att. Den forventa versjonen må vere den som er i bruk, før du går tilbake til profilen.

Å feste ein eldre klient kjøper tid, ikkje ei løysing

Å halde att den førre klientversjonen gjenopprettar tunnelen så lenge tilbakehaldet varer. Det frys òg tryggleiksoppdateringane for pakken og planlegg same brotet til neste oppgradering, så handsame det som ei datert mellombels løysing, ikkje ei løysing.

Viss du likevel festar han, hald pakken eksplisitt så ei overvaking utan tilsyn ikkje kan oppheve festet, skriv ned årsaka og datoen for ny vurdering, og set eit minne for neste profilutgjeving frå leverandøren. Vilkåret som er verdt å følgje med på, er ein serverprofil som forhandlar ein gjeldande cipher; når han finst, har festet inga grunngjeving att. Eit uregistrert fest blir derimot eit avbrot ingen kan forklare eit halvt år seinare, fordi personen som brukte det, er borte, og fila registrerer ingenting.

Neste gong ein VPN døyr etter ei utgåveoppgradering, still fem spørsmål i rekkjefølgje: kva lag gav den første feilen, avviste TLS-politikken sertifikatet, kan cipheren forhandlast i begge retningar, vart pakken og pluginen hans faktisk installerte, og kva bibliotek lastar prosessen. Først når alle fem kjem att reine, gjev ein nedgradering meining.