Waarom stopte OpenVPN met verbinden na een Ubuntu-upgrade?

VPN-profielen die vorige week nog werkten, breken na een Ubuntu-release-upgrade, en de log noemt de upgrade zelden. Wat hij wel noemt, is de laag die faalde: de TLS-handshake, de cipher die voor het datakanaal is onderhandeld, het geïnstalleerde pakket of de OpenSSL-kopie die de binary bij het starten laadt. Elke laag heeft zijn eigen foutvorm en zijn eigen reparatie, waardoor classificatie de eerste taak is en bewerken de tweede. Behandel het profiel als onschuldig tot de log het noemt.

Welke laag faalde: handshake, cipher, pakket of bibliotheek

Lees de clientlog voordat u het profiel aanraakt. De vroegste fout in de uitvoer is degene die de laag aanwijst; alles wat daarna wordt afgedrukt is meestal gevolg van die eerste fout. Als de client helemaal niet start, is de VPN-log het verkeerde bestand om te openen.

Klachten over certificaten en handtekeningen, of een bericht over sleutellengte, komen van het controlekanaal en het bibliotheekbeleid dat dat regelt. Een waarschuwing die begint met DEPRECATED OPTION hoort daarentegen bij de onderhandeling van het datakanaal.

Een regel als Unrecognized option is een derde categorie: de nieuwe binary accepteert geen richtlijn meer die de oude tolereerde, dus het profiel moet worden herschreven in plaats van de bibliotheek versoepeld. Pakketfouten zien er weer anders uit omdat ze gebeuren voordat er tunnelcode draait. Een ontbrekende binary, een plugin die niet laadt of een repository die naar de verkeerde codenaam wijst, geven allemaal die vorm. Vier symptomen, vier plekken om te kijken en bijna geen overlap tussen de reparaties.

Als de handshake faalt, wijst het TLS-beleid het certificaat af

Ubuntu 22.04 zette het systeem op OpenSSL 3, en het standaard beveiligingsniveau in die tak is strenger over certificaathandtekeningen en sleutelgroottes dan 20.04 was. Een CA-certificaat dat met een oudere digest is ondertekend, of een sleutel onder de huidige drempel, faalt nu tijdens de handshake. Omdat er nog niets is geauthenticeerd, leest de fout als een verkeerd wachtwoord of een dode server.

De smalle reparatie hangt een cipher-string alleen aan deze verbinding. Open in de desktop-editor het profiel, ga naar de geavanceerde instellingen en zet DEFAULT:@SECLEVEL=0 in het TLS-cipherveld. Het NetworkManager-sleutelbestand neemt dezelfde waarde onder [vpn]:

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

Herstart NetworkManager en verbind opnieuw, want de daemon cachet geparseerde profielen en zou anders de kopie blijven gebruiken die hij al heeft. Weet wat de regel doet voordat u hem houdt: die instelling is een drempel over meerdere certificaat- en sleutelparameters, geen cipher-naam, dus verlagen verruimt wat het enkele profiel accepteert. Noteer welke server hem eiste en laat de instelling vallen zodra de operator actueel materiaal opnieuw uitgeeft. Het wijzigen van /etc/ssl/openssl.cnf bereikt dezelfde drempel voor elk programma dat dat bestand leest, wat veel verder gaat dan de VPN.

OpenVPN 2.6 vereist de cipher in de onderhandeling

Ubuntu 22.10 leverde OpenVPN 2.6, en in die release stopt --cipher met zelf het datakanaal kiezen. De cipher moet ook in de onderhandelde lijst data-ciphers staan, anders print de client een verouderingswaarschuwing en krijgt hij de tunnel daarna niet omhoog.

De NetworkManager-plugin uit dezelfde periode schreef nog steeds alleen de oude richtlijn. Dat detail splitst de diagnose, want een met de hand gecorrigeerd profiel kan vanuit een shell verbinden en vanuit de desktop-applet alsnog falen. Voeg de lijst toe aan het verbindingsbestand onder [vpn]:

data-ciphers=AES-256-CBC

Gebruik de waarde die de server aankondigt, niet degene die u onthoudt; een server die AES-256-GCM aanbiedt, onderhandelt niet met een clientlijst die alleen CBC noemt. Herstart de beheerder en verbind opnieuw, en herhaal dan de poging vanuit een shell met de cipher expliciet doorgegeven voor zowel onderhandeling als fallback:

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

Als dat commando de tunnel omhoogbrengt, zijn de server, de certificaten en de inloggegevens allemaal gezond, en is de enige resterende fout de opgeslagen optie van de beheerder. Een waarschuwing over de richtlijn keysize hoort bij dezelfde opruiming: commentarieer hem uit en bewaar het originele bestand naast het profiel.

Pakket- en pluginfouten lijken op VPN-fouten

Niet elke fout na de upgrade is cryptografisch. Een OpenVPN-repository die is toegevoegd onder een codenaam die de release niet gebruikt, levert een pakket dat nooit installeert; vergelijk dus wat lsb_release -a meldt met het lijstbestand dat u hebt toegevoegd. Een ontbrekende universe-component of beveiligingspocket levert een pakket dat helemaal niet te vinden is. Beide gevallen laten het profiel onaangeroerd en de tunnel onmogelijk.

Lees de fout van de pakketbeheerder vóór de VPN-log. Is de client nooit geïnstalleerd, dan levert geen enkele profielbewerking een handshake op.

Tweefactorprofielen die ophouden met vragen zijn de plugin-versie van hetzelfde verhaal. De uitdaging komt van een authenticatieplugin, en een upgrade die hem heeft weggehaald of vervangen laat het profiel intact terwijl de vraag verdwijnt. Herinstalleer de ondersteunde plugin in plaats van de tweede factor te wissen om de verbinding te laten werken.

Een leveranciersbibliotheek kan zich achter een beleidsfout verschuilen

Eén patroon verdient erkenning omdat het elke beleidsreparatie verslaat. Een configuratiehulpmiddel van een hardwareleverancier kan zijn eigen OpenSSL-bibliotheken installeren en ze in het zoekpad van de loader vóór de systeemkopieën plaatsen. De client start dan tegen een bibliotheek die niemand heeft geüpgraded, en de startfout lijkt precies op een geweigerd certificaat.

Het VPN-pakket opnieuw installeren verandert niet welke bibliotheek eerst wordt gevonden, en het verlagen van het TLS-niveau bereikt geen bibliotheek die nooit van het systeem kwam. Vraag de loader welke crypto-objecten de binary werkelijk oplost:

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

Verwijder of verwijs de leverancierskopie opnieuw en voer daarna dezelfde controle opnieuw uit. De verwachte versie moet de gebruikte zijn voordat u terugkeert naar het profiel.

Een oudere client vastpinnen koopt tijd, geen oplossing

De vorige clientversie vasthouden herstelt de tunnel zolang de vasthouding duurt. Het bevriest ook de beveiligingsupdates voor dat pakket en plant dezelfde breuk voor de volgende upgrade, dus behandel het als een gedateerde noodoplossing, niet als een oplossing.

Als u hem toch pint, houd het pakket expliciet vast zodat een onbeheerde upgrade de pin niet kan ongedaan maken, schrijf de reden en de datum voor herziening op en zet een herinnering voor de volgende profielrelease van de provider. De voorwaarde die aandacht verdient is een serverprofiel dat een actuele cipher onderhandelt; zodra dat bestaat, heeft de pin geen rechtvaardiging meer. Een niet vastgelegde pin wordt daarentegen een storing die niemand een half jaar later kan verklaren, omdat degene die hem toepaste weg is en het bestand niets vastlegt.

De volgende keer dat een VPN sterft na een release-upgrade, stel vijf vragen op rij: welke laag gaf de eerste fout, wees het TLS-beleid het certificaat af, is de cipher in beide richtingen onderhandelbaar, zijn het pakket en zijn plugin echt geïnstalleerd, en welke bibliotheek laadt het proces. Pas als alle vijf schoon terugkomen, heeft een downgrade zin.