Warum hat OpenVPN nach einem Ubuntu-Upgrade aufgehört zu verbinden?

VPN-Profile, die letzte Woche noch funktionierten, brechen nach einem Ubuntu-Release-Upgrade, und das Log erwähnt das Upgrade kaum. Was es nennt, ist die Schicht, die versagt hat: der TLS-Handshake, die für den Datenkanal ausgehandelte Cipher, das installierte Paket oder die OpenSSL-Kopie, die das Binary beim Start lädt. Jede Schicht hat ihre eigene Fehlerform und ihre eigene Reparatur, weshalb die Klassifikation die erste und das Bearbeiten die zweite Aufgabe ist. Behandeln Sie das Profil als unschuldig, bis das Log es nennt.

Welche Schicht versagt hat: Handshake, Cipher, Paket oder Bibliothek

Lesen Sie das Client-Log, bevor Sie das Profil anfassen. Der früheste Fehler in der Ausgabe ist derjenige, der die Schicht benennt; alles danach Gedruckte ist meist Folge dieses ersten Fehlschlags. Wenn der Client gar nicht startet, ist das VPN-Log die falsche Datei.

Beschwerden über Zertifikate und Signaturen oder eine Meldung zur Schlüssellänge stammen vom Control-Channel und der Bibliotheks-Policy, die ihn regelt. Eine Warnung, die mit DEPRECATED OPTION beginnt, gehört dagegen zur Aushandlung des Datenkanals.

Eine Zeile Unrecognized option ist eine dritte Kategorie: Das neue Binary akzeptiert keine Direktive mehr, die das alte duldete, also muss das Profil umgeschrieben werden, statt die Bibliothek zu lockern. Paketfehler sehen wieder anders aus, weil sie passieren, bevor irgendein Tunnelcode läuft. Ein fehlendes Binary, ein Plugin, das nicht lädt, oder ein Repository, das auf den falschen Codename zeigt, erzeugen alle diese Form. Vier Symptome, vier Stellen zum Nachsehen und fast keine Überschneidung zwischen den Reparaturen.

Wenn der Handshake scheitert, weist die TLS-Policy das Zertifikat zurück

Ubuntu 22.04 stellte das System auf OpenSSL 3 um, und die Standard-Sicherheitsstufe dieses Zweigs ist strenger bei Zertifikatssignaturen und Schlüsselgrößen als 20.04. Ein CA-Zertifikat mit älterem Digest oder ein Schlüssel unter dem aktuellen Schwellenwert scheitert jetzt während des Handshakes. Da noch nichts authentifiziert ist, liest sich der Fehler wie ein falsches Passwort oder ein toter Server.

Die enge Reparatur hängt eine Cipher-Zeichenkette nur an diese Verbindung. Öffnen Sie im Desktop-Editor das Profil, wechseln Sie zu den erweiterten Einstellungen und setzen Sie DEFAULT:@SECLEVEL=0 in das TLS-Cipher-Feld. Die NetworkManager-Keyfile übernimmt denselben Wert unter [vpn]:

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

Starten Sie NetworkManager neu und verbinden Sie sich erneut, denn der Daemon cacht geparste Profile und würde sonst weiter die bereits gehaltene Kopie verwenden. Wissen Sie, was die Zeile tut, bevor Sie sie behalten: Diese Einstellung ist ein Schwellenwert über mehrere Zertifikats- und Schlüsselparameter, kein Cipher-Name, ihr Absenken erweitert also, was das einzelne Profil akzeptiert. Notieren Sie, welcher Server sie verlangte, und streichen Sie die Einstellung, sobald der Betreiber aktuelles Material neu ausstellt. Das Ändern von /etc/ssl/openssl.cnf erreicht denselben Schwellenwert für jedes Programm, das diese Datei liest, was weit über das VPN hinausgeht.

OpenVPN 2.6 verlangt die Cipher in der Aushandlung

Ubuntu 22.10 lieferte OpenVPN 2.6, und in dieser Version hört --cipher auf, den Datenkanal allein zu wählen. Die Cipher muss auch in der ausgehandelten Liste data-ciphers stehen, sonst gibt der Client eine Deprecation-Warnung aus und schafft es dann nicht, den Tunnel hochzubringen.

Das NetworkManager-Plugin derselben Zeit schrieb weiterhin nur die alte Direktive. Dieses Detail teilt die Diagnose, denn ein von Hand korrigiertes Profil kann aus einer Shell verbinden und aus dem Desktop-Applet weiter scheitern. Fügen Sie die Liste in der Verbindungsdatei unter [vpn]:

data-ciphers=AES-256-CBC

Nehmen Sie den Wert, den der Server ankündigt, nicht den erinnerten; ein Server, der AES-256-GCM anbietet, handelt nicht mit einer Client-Liste, die nur CBC nennt. Starten Sie den Manager neu und verbinden Sie sich, dann wiederholen Sie den Versuch aus einer Shell mit explizit übergebener Cipher für Aushandlung und Fallback:

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

Bringt dieser Befehl den Tunnel hoch, sind Server, Zertifikate und Zugangsdaten in Ordnung, und der einzige verbleibende Fehler ist die gespeicherte Option des Managers. Eine Warnung zur Direktive keysize gehört zur selben Aufräumaktion: auskommentieren und die Originaldatei neben dem Profil behalten.

Paket- und Plugin-Fehler sehen wie VPN-Fehler aus

Nicht jeder Fehlschlag nach dem Upgrade ist kryptografisch. Ein OpenVPN-Repository, das unter einem Codename eingetragen wurde, den das Release nicht nutzt, ergibt ein Paket, das nie installiert wird; vergleichen Sie also, was lsb_release -a meldet, mit der hinzugefügten Listendatei. Eine fehlende Komponente universe oder ein Security-Pocket ergibt ein Paket, das sich gar nicht finden lässt. Beide Fälle lassen das Profil unberührt und den Tunnel unmöglich.

Lesen Sie den Fehler des Paketmanagers vor dem VPN-Log. Wurde der Client nie installiert, erzeugt keine noch so große Profilbearbeitung einen Handshake.

Zwei-Faktor-Profile, die aufhören zu fragen, sind die Plugin-Version derselben Geschichte. Die Challenge kommt von einem Authentifizierungs-Plugin, und ein Upgrade, das es entfernt oder ersetzt hat, lässt das Profil intakt, während die Abfrage verschwindet. Installieren Sie das unterstützte Plugin neu, statt den zweiten Faktor zu löschen, damit die Verbindung funktioniert.

Eine Herstellerbibliothek kann sich hinter einem Policy-Fehler verstecken

Ein Muster verdient Aufmerksamkeit, weil es jede Policy-Reparatur aushebelt. Ein Konfigurationswerkzeug eines Hardwareherstellers kann eigene OpenSSL-Bibliotheken installieren und sie im Suchpfad des Loaders vor die Systemkopien legen. Der Client startet dann gegen eine Bibliothek, die niemand aktualisiert hat, und der Startfehler sieht genau wie ein zurückgewiesenes Zertifikat aus.

Eine Neuinstallation des VPN-Pakets ändert nicht, welche Bibliothek zuerst gefunden wird, und das Absenken der TLS-Stufe erreicht keine Bibliothek, die nie vom System kam. Fragen Sie den Loader, welche Kryptoobjekte das Binary tatsächlich auflöst:

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

Entfernen oder verlagern Sie die Herstellerkopie und führen Sie dann dieselbe Prüfung erneut aus. Die erwartete Version muss die verwendete sein, bevor Sie zum Profil zurückkehren.

Ein älteres Paket zu pinnen kauft Zeit, keine Lösung

Die vorige Client-Version festzuhalten stellt den Tunnel wieder her, solange der Hold dauert. Es friert auch die Sicherheitsupdates für dieses Paket ein und plant denselben Bruch für das nächste Upgrade ein, behandeln Sie es also als datierte Übergangslösung, nicht als Behebung.

Wenn Sie es doch pinnen, halten Sie das Paket ausdrücklich, damit ein unbeaufsichtigtes Upgrade den Pin nicht aufheben kann, notieren Sie Grund und Datum für die Überprüfung und setzen Sie eine Erinnerung für das nächste Profilrelease des Anbieters. Die Bedingung, auf die zu achten ist, ist ein Serverprofil, das eine aktuelle Cipher aushandelt; sobald es das gibt, hat der Pin keine Rechtfertigung mehr. Ein nicht dokumentierter Pin dagegen wird zu einem Ausfall, den sechs Monate später niemand erklären kann, weil die Person, die ihn setzte, weitergezogen ist und die Datei nichts festhält.

Wenn eine VPN das nächste Mal nach einem Release-Upgrade stirbt, stellen Sie fünf Fragen der Reihe nach: Welche Schicht erzeugte den ersten Fehler, hat die TLS-Policy das Zertifikat zurückgewiesen, ist die Cipher in beide Richtungen aushandelbar, wurden Paket und Plugin wirklich installiert, und welche Bibliothek lädt der Prozess. Erst wenn alle fünf sauber zurückkommen, ergibt ein Downgrade Sinn.