Hvorfor sluttet OpenVPN å koble til etter en Ubuntu-oppgradering?

VPN-profiler som virket forrige uke, knekker etter en Ubuntu-utgivelsesoppgradering, og loggen nevner sjelden oppgraderingen i det hele tatt. Det den nevner, er laget som feilet: TLS-håndtrykket, cipheren som ble forhandlet for datakanalen, pakken som ble installert, eller OpenSSL-kopien som binæren laster ved oppstart. Hvert lag har sin egen feilform og sin egen reparasjon, så klassifisering er den første jobben og redigering den andre. Behandle profilen som uskyldig til loggen navngir den.

Hvilket lag feilet: håndtrykk, cipher, pakke eller bibliotek

Les klientloggen før du rører profilen. Den tidligste feilen i utdataene er den som identifiserer laget; alt som skrives ut etter den, er vanligvis følger av den første feilen. Når klienten ikke starter i det hele tatt, er VPN-loggen feil fil å åpne.

Klager på sertifikater og signaturer, eller en melding om nøkkellengde, kommer fra kontrollkanalen og bibliotekpolicyen som styrer den. En advarsel som begynner med DEPRECATED OPTION hører derimot til forhandlingen av datakanalen.

En linje som Unrecognized option er en tredje kategori: den nye binæren godtar ikke lenger et direktiv den gamle tolererte, så profilen må skrives om i stedet for at biblioteket må lempes. Pakkefeil ser igjen annerledes ut fordi de skjer før noen tunnelkode kjører. Manglende binær, en plugin som ikke lastes, eller et depot som peker på feil kodenavn gir alle den formen. Fire symptomer, fire steder å se, og nesten ingen overlapping mellom reparasjonene.

Når håndtrykket feiler, avviser TLS-policyen sertifikatet

Ubuntu 22.04 flyttet systemet til OpenSSL 3, og standard sikkerhetsnivå i den grenen er strengere på sertifikatsignaturer og nøkkelstørrelser enn 20.04 var. Et CA-sertifikat signert med en eldre digest, eller en nøkkel under dagens terskel, feiler nå under håndtrykket. Siden ingenting er autentisert ennå, leses feilen som et feil passord eller en død server.

Den smale reparasjonen fester en cipher-streng bare til denne tilkoblingen. I skrivebordseditoren åpner du profilen, går til avanserte innstillinger og setter DEFAULT:@SECLEVEL=0 i TLS-cipher-feltet. NetworkManager-nøkkelfilen tar samme verdi under [vpn]:

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

Start NetworkManager på nytt og koble til igjen, fordi daemonen cacher parsede profiler og ellers fortsetter å bruke kopien den allerede har. Vit hva linjen gjør før du beholder den: innstillingen er en terskel over flere sertifikat- og nøkkelparametere, ikke et cipher-navn, så senking utvider det den enkelte profilen godtar. Noter hvilken server som krevde det, og slipp innstillingen når operatøren gir ut gjeldende materiale på nytt. Å endre /etc/ssl/openssl.cnf når samme terskel for hvert program som leser den filen, noe som er langt utenfor VPN-en.

OpenVPN 2.6 krever cipheren oppført for forhandling

Ubuntu 22.10 leverte OpenVPN 2.6, og i den utgivelsen slutter --cipher å velge datakanalen selv. Cipheren må også være med i den forhandlede data-ciphers-listen, ellers skriver klienten ut en utdateringsadvarsel og klarer deretter ikke å reise tunnelen.

NetworkManager-pluginen fra samme periode skrev fortsatt bare det gamle direktivet. Den detaljen deler diagnosen, fordi en profil rettet for hånd kan koble til fra et skall og likevel feile fra skrivebordsappletten. Legg listen til tilkoblingsfilen under [vpn]:

data-ciphers=AES-256-CBC

Bruk verdien serveren annonserer, ikke den du husker; en server som tilbyr AES-256-GCM forhandler ikke med en klientliste som bare nevner CBC. Start behandleren på nytt og koble til igjen, og gjenta så forsøket fra et skall med cipheren gitt eksplisitt for både forhandling og reserve:

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

Hvis den kommandoen reiser tunnelen, er serveren, sertifikatene og påloggingsdetaljene alle i orden, og den eneste gjenstående feilen er behandlerens lagrede valg. En advarsel om direktivet keysize hører til samme opprydding: kommenter det ut og oppbevar originalfilen ved siden av profilen.

Pakke- og pluginfeil ser ut som VPN-feil

Ikke hver feil etter oppgraderingen er kryptografisk. Et OpenVPN-depot lagt til under et kodenavn utgivelsen ikke bruker, gir en pakke som aldri installeres, så sammenlign hva lsb_release -a rapporterer med listefilen du la til. En manglende universe-komponent eller sikkerhetslomme gir en pakke som ikke kan finnes i det hele tatt. Begge tilfellene lar profilen være urørt og tunnelen umulig.

Les pakkebehandlerens feil før VPN-loggen. Ble klienten aldri installert, gir ingen mengde profilredigering et håndtrykk.

Tofaktorprofiler som slutter å spørre, er plugin-versjonen av samme historie. Utfordringen kommer fra en autentiseringsplugin, og en oppgradering som droppet eller erstattet den, lar profilen være intakt mens forespørselen forsvinner. Reinstaller den støttede pluginen i stedet for å slette den andre faktoren for å få tilkoblingen til å virke.

Et leverandørbibliotek kan gjemme seg bak en policyfeil

Ett mønster fortjener gjenkjennelse fordi det slår hver policyreparasjon. Et konfigurasjonsverktøy fra en maskinvareleverandør kan installere egne OpenSSL-biblioteker og plassere dem foran systemkopiene i lasteprogrammets søkesti. Klienten starter da mot et bibliotek ingen har oppgradert, og oppstartsfeilen ser nøyaktig ut som et avvist sertifikat.

Reinstallasjon av VPN-pakken endrer ikke hvilket bibliotek som finnes først, og senking av TLS-nivået når ikke et bibliotek som aldri kom fra systemet. Spør lasteprogrammet hvilke kryptoobjekter binæren faktisk løser opp:

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

Fjern eller ompek leverandørkopien, og kjør så samme kontroll igjen. Den forventede versjonen må være den som brukes, før du går tilbake til profilen.

Å feste en eldre klient kjøper tid, ikke en løsning

Å holde den forrige klientversjonen tilbake gjenoppretter tunnelen så lenge tilbakeholdelsen varer. Det fryser også sikkerhetsoppdateringene for pakken og planlegger samme brudd til neste oppgradering, så behandl det som en datert midlertidig løsning, ikke en løsning.

Hvis du likevel fester den, hold pakken eksplisitt så en uovervåket oppgradering ikke kan oppheve festen, skriv ned årsaken og datoen for ny vurdering, og sett en påminnelse for leverandørens neste profilutgivelse. Betingelsen som er verdt å følge med på, er en serverprofil som forhandler en gjeldende cipher; når den finnes, har festen ingen begrunnelse igjen. En uregistrert fest blir derimot et avbrudd ingen kan forklare et halvt år senere, fordi personen som brukte den er borte, og filen registrerer ingenting.

Neste gang en VPN dør etter en utgivelsesoppgradering, still fem spørsmål i rekkefølge: hvilket lag ga den første feilen, avviste TLS-policyen sertifikatet, kan cipheren forhandles i begge retninger, ble pakken og pluginen faktisk installert, og hvilket bibliotek laster prosessen. Først når alle fem kommer tilbake rene, gir en nedgradering mening.