OpenVPN 3 Linux: Lies einen D-Bus-Fehler, bevor du zurückrollst

Fehler von OpenVPN 3 Linux kommen als D-Bus-Methodenfehler mit einem ungewohnten Namen an, und die Versuchung ist, ein Paket herunterzustufen und zu hoffen. Der Client ist kein einzelnes Programm: Ein Kommandozeilen-Frontend spricht über den Bus mit Diensten, die Profile, Sitzungen, die VPN-Engine und die privilegierten Netzwerkänderungen besitzen. Zu entscheiden, welcher dieser fünf den fehlschlagenden Aufruf besitzt, ist der größte Teil der Diagnose, und es kostet einen Befehl statt eines Rollbacks. Was folgt, ist diese Entscheidung, in der Reihenfolge, in der die Fehler üblicherweise auftreten.

Fünf Besitzer hinter einem Befehl

Fünf Prozesse sind relevant, und jeder hat einen eigenen Busnamen: das Frontend, das deinen Befehl annimmt, der Konfigurationsmanager, der Profile und ihre Zugriffsrichtlinie speichert, der Sitzungsmanager, der die Lebensdauer von Sitzungen besitzt, das Backend, das die Verbindung über die OpenVPN 3 Core Engine führt, und der Netzwerkkonfigurationsdienst, der Schnittstelle, Routen und DNS-Einstellungen einrichtet. Ein Fehler, der ein Konfigurationsobjekt nennt, ist deshalb kein Backend-Fehler, und ein Backend, das nicht startet, ist kein Authentifizierungsfehler. Die Meldung einer dieser Zeilen zuzuordnen, muss geschehen, bevor irgendetwas geändert wird, denn jeder spätere Schritt hängt davon ab, welche Zeile zutrifft. Das Raten an der Zeile ist der Weg, auf dem aus einer kurzen Korrektur ein Nachmittag Paketarbeit wird.

Frage den Systembus, welche Dienste vorhanden sind, bevor du irgendetwas anderes fragst, und bestätige dann, dass die installierten Teile sich auf eine Version einig sind. OpenVPN 3 Linux registriert diese Dienste als System-Units, also ist der zu fragende Bus der Systembus, die Versionsabfrage braucht administrative Rechte, und eine Auflistung mit --user liest deine Login-Sitzung, in der die Units nie erscheinen. Dienste aktivieren sich bei Bedarf, und manche beenden sich im Leerlauf, ein vor deiner ersten Anfrage fehlender Dienst wurde also einfach noch nicht angefragt. Die drei Befehle unten beantworten Vorhandensein, Version und Unit-Zustand, ohne eine VPN-Sitzung zu öffnen.

sudo busctl list | grep -i openvpn
sudo openvpn3-admin version --services
systemctl list-units 'openvpn3*'

Was die einzelnen Listen tatsächlich belegen

Die eigenen Ansichten des Clients sind der billigste verfügbare Beleg, und jede von ihnen belegt weniger, als es scheint. Ein Profil in der Konfigurationsliste zeigt, dass ein Profil importiert ist, und nichts darüber, ob jemand damit verbinden darf. Eine Sitzung in der Sitzungsliste zeigt, dass ein Sitzungsobjekt existiert, und nichts darüber, ob die entfernte Authentifizierung abgeschlossen wurde.

openvpn3 configs-list
openvpn3 sessions-list

Objektpfade in diesen Ausgaben bezeichnen verwaltete Objekte auf dem Bus und keine Dateien, sie lassen sich also nicht bearbeiten, und ein früher notierter Pfad wird veraltet, sobald diese Sitzung getrennt wird. Einen davon aus deinen Notizen wiederzuverwenden, erzeugt "no such object"-Fehler, die nichts mit dem VPN zu tun haben. Die Stufentabelle unten trennt, was jeder Schritt einer Verbindung herstellt, von dem, was er offen lässt, und genau diese Unterscheidung entscheidet über einen Rollback. Lies die Zeile, die zu deinem Beleg passt, und lies dann den Fehlertext noch einmal.

Der Verbindungsaufruf kehrt zurück, bevor der Tunnel existiert

Der Verbindungsaufruf übergibt dir eine Sitzung zum Beobachten und kehrt zurück, weshalb ein scheinbar erfolgreicher Aufruf, gefolgt von Stille, ein normaler Zwischenzustand und kein Widerspruch ist. Das Frontend muss weiterhin Statusänderungen verfolgen und jede Anfrage nach Interaktion beantworten. Ein Profil, das eine Anmeldeinformation braucht und keine Antwort erhält, wartet in einem Zustand, der genau wie ein hängendes Backend aussieht. Dieser Wartezustand verdient Beachtung, denn er schickt Leute zur falschen Komponente.

Während ein Versuch läuft, beobachte die Sitzungsliste und das eigene Protokoll des Frontends für dieses Profil. Eine Sitzung, die ihren Anfangszustand nie verlässt, benennt die Komponente, die gestoppt hat, und das Protokoll nennt sie meist schon in den ersten Zeilen. Halte den Profilnamen bereit, denn der Protokollbefehl nimmt ein Profil und keinen Sitzungspfad, was ein weiterer Grund ist, die Liste erneut zu lesen statt einen Pfad wiederzuverwenden.

openvpn3 sessions-list
openvpn3 log --config <profile> --level 6

Das Protokoll einer Komponente lesen, ohne eine Sitzung zu öffnen

Wenn das Frontend nichts Nützliches meldet, geh zu der Komponente, die den Fehler protokolliert hat, statt eine weitere Verbindung zu starten. Mit einem konfigurierten systemd-journald-Logger liest die eingeschränkte Journal-Ansicht des Administrators die Ereignisse einer Komponente, ohne die Bus-Richtlinie anzutasten oder eine Sitzung zu öffnen, was zählt, weil eine Diagnose, die das gemessene System verändert, sehr wenig belegt. Filtere nach Unit und nicht nach Syslog-Tag: Die einzelnen Dienst-Units garantieren keine gemeinsame Kennung, eine Tag-Abfrage kann also eine leere Seite liefern, während die Unit selbst den Fehler aufgezeichnet hat.

Notiere vier Angaben, bevor du jemanden um Hilfe bittest: den vollständigen Fehlernamen, den beteiligten Dienst und das beteiligte Objekt, den Zeitstempel und die installierten Paketversionen. Das ist es, was ein Maintainer braucht, und nichts davon verlangt, ein Profil oder eine Anmeldeinformation in ein Ticket zu kopieren. Die Bus-Zugriffsrichtlinie zu erweitern, um den Fehler stummzustellen, ist keine Diagnose, sie löscht die Grenze, die dir die Komponente benannt hat. Private Profilinhalte bleiben aus geteilten Berichten heraus, aus demselben Grund wie Anmeldeinformationen.

journalctl -u 'openvpn3-service-*' -n 50 --no-pager
openvpn3-admin journal --service <name>

Die Grenze korrigieren, die abgelehnt hat

Jede Zeile der Zuordnung hat ihre eigene Korrektur, und die Zeilen ersetzen einander nicht. Eine abgelehnte Operation an einem Profil ist eine Frage von Richtlinie und Eigentümerschaft, während ein Backend, das nicht aktiviert, eine Frage von Diensten und Paketierung ist. Ein Server, der die Authentifizierung ablehnt, ist keines von beiden, wiederholte Passwortänderungen können also kein lokales Aktivierungsproblem reparieren. Die falsche Korrektur zu wählen, ist der Weg, auf dem aus einem Richtlinienproblem eine Neuinstallation wird.

Prüfe nach einer Paketänderung, dass eine stimmige, unterstützte Installation vorliegt, statt eine alte Binärdatei an ihren Platz zu kopieren. Ein kontrollierter Rollback ist eine legitime Antwort auf eine bestätigte Regression, sofern die Pakete kompatibel bleiben und ein Weg zurück zur unterstützten Wartung existiert. Richte diesen Weg ein, bevor der Dienst aufhört zu starten, nicht danach.

Eine andere Plattform kann dieselbe VPN-Kernbibliothek nutzen, ohne die Bus-Dienste von Linux zu teilen, ein ähnlich aussehender Fehler unter Windows sagt also nichts über diesen hier. Die D-Bus-Übersicht dokumentiert die für Konfigurationen und Sitzungen bereitgestellten Objektpfade, und genau dieser Teil der Architektur trägt diese Diagnose. Lies sie einmal, und der nächste Fehler kommt mit einer bereits zugeordneten Komponente.