OpenVPN beim Start unter Ubuntu: NetworkManager oder systemd?

Die meisten Anleitungen stellen die Wahl als kosmetisch dar: Entweder lassen Sie NetworkManager den Tunnel aufbauen, oder Sie aktivieren eine systemd-Instanz und sind fertig. Die beiden Wege unterscheiden sich in einer Sache, die das Ergebnis auf einer Maschine ohne Bildschirm entscheidet, und sie hat nichts damit zu tun, welches Werkzeug neuer ist. NetworkManager schließt Geheimnisse über eine Sitzung auf; eine systemd-Instanz hat keine Sitzung zum Aufschließen. Wählen Sie den Weg, dessen Umgang mit Geheimnissen zur Maschine vor Ihnen passt.

Alles andere, von der Routeninstallation bis zum Verhalten bei der Wiederverbindung, folgt aus dieser ersten Entscheidung.

Der Schlüsselbund ist der Unterschied, den niemand erwähnt

Wenn NetworkManager ein VPN-Profil besitzt, kann das Passwort im Anmelde-Schlüsselbund liegen, der entsperrt wird, wenn sich ein Benutzer anmeldet. Auf einem Laptop funktioniert das gut: Die Person ist anwesend, der Schlüsselbund öffnet sich, der Tunnel kommt hoch. Auf einem Server, der unbeaufsichtigt startet, ist niemand da, der etwas entsperren könnte, also wartet das Profil auf ein Geheimnis, das nie ankommt. Die Verbindung sieht konfiguriert aus und wird nie aktiv.

Die systemd-Instanz vermeidet dieses Problem, indem sie eine Anmeldedatendatei von der Festplatte liest, wodurch die Datei das ist, was Sie schützen. chmod 400 plus Eigentum von root ist das Minimum, und die Datei sollte aus Sicherungen und Image-Vorlagen herausbleiben, die Sie nicht kontrollieren.

Das VPN an eine Verbindung zu hängen ist keine Startgarantie

Wählen Sie in nm-connection-editor die kabelgebundene oder drahtlose Verbindung statt des VPN, öffnen Sie den Reiter General, setzen Sie den Haken bei der Option, automatisch mit einem VPN zu verbinden, und benennen Sie das Profil. NetworkManager aktiviert das VPN dann als sekundäre Verbindung, wenn die primäre einen verbundenen Zustand erreicht. Das ist eine Abhängigkeit, keine Firewall-Regel. Pakete können in den Sekunden vor dem Tunnelaufbau immer noch hinausgehen, und ein gespeichertes Geheimnis, das sich nicht entsperren lässt, lässt die Maschine ohne ihn online.

Wenn die Anforderung ist, dass nichts ohne den Tunnel hinausgeht, sagen Sie das und bauen Sie einen Kill Switch, denn diese Einstellung liefert keinen. Testen Sie auch Suspend und Resume, da die sekundäre Verbindung beim Zurückkommen neu bewertet wird.

Die systemd-Instanz braucht einen passenden Dateinamen

Legen Sie das Profil in das Client-Verzeichnis, das das Paket erwartet, etwa /etc/openvpn/client/office.conf, und verweisen Sie darin mit auth-user-pass office.cred auf die Anmeldedatendatei. Der Instanzname ist der Dateiname ohne Endung, also liest openvpn-client@office die Datei office.conf. Aktivieren Sie sie mit sudo systemctl enable --now openvpn-client@office und bestätigen Sie die Zuordnung mit systemctl cat openvpn-client@office, statt einem Beispiel aus einem Blog zu vertrauen.

Pfade im Profil werden relativ zum Arbeitsverzeichnis der Unit aufgelöst, nicht zum Profil selbst, daher kann eine relative ca- oder auth-user-pass-Zeile beim Start fehlschlagen, während sie beim manuellen Test funktioniert. Verwenden Sie absolute Pfade für alles, was die Unit finden muss. Lesen Sie dann nach einem echten Start journalctl -u openvpn-client@office -b; eine Unit, die aktiv meldet, aber keinen Tunnel hat, nennt in diesem Protokoll meist eine fehlende Datei.

Ältere Pakete liefern einen anderen Vorlagennamen, daher klärt systemctl list-unit-files 'openvpn*', welche auf diesem Host existiert.

Wiederverbindungsverhalten ist eine eigene Entscheidung

Ein Profil mit ping-restart baut den Tunnel nach einem Abbruch neu auf, und eine Unit mit einer Neustart-Direktive tut auf Dienstebene etwas Ähnliches. Das sind Richtlinien, die Sie wählen, keine Vorgaben, die Sie erben. Wenn die Verbindung nur auf Anforderung hochkommen soll, entfernen Sie das Neustartverhalten bewusst und schreiben Sie auf, warum. Wenn die Unit startet, bevor das Netz nutzbar ist, braucht sie eine Wiederholungsrichtlinie, denn ein fehlgeschlagener Versuch beim Start wiederholt sich nicht von selbst.

Das Stoppen ist ebenso wörtlich: sudo systemctl disable --now openvpn-client@office stoppt die laufende Instanz und entfernt die Startverknüpfung. Nur zu deaktivieren lässt den Tunnel bis zum nächsten Neustart laufen, was jeden überrascht, der durch Deaktivieren testet und zusieht, wie die Schnittstelle oben bleibt.

Neu starten, dann vier Dinge der Reihe nach prüfen

Den Dienst neu zu starten testet den Dienst; die Maschine neu zu starten testet den Startweg. Bestätigen Sie nach dem Neustart, dass die Unit hochgekommen ist, dann dass eine Route für das entfernte Subnetz existiert, dann welche Adresse die Maschine dem Internet zeigt, und schließlich dass Namen durch den Tunnel aufgelöst werden. Diese vier Prüfungen schlagen in dieser Reihenfolge fehl, wenn etwas nicht stimmt, was den ersten Fehler zum nützlichen macht.

Eine aktive Unit ohne Route bedeutet meist, dass das Profil verbunden wurde, der Server aber keine Route geschoben hat, oder dass die Route auf einer Schnittstelle installiert wurde, die später verschwand. Eine Route ohne funktionierende Namensauflösung deutet auf die DNS-Konfiguration hin, nicht auf den Tunnel selbst.

Entscheiden Sie vorab, was passieren soll, wenn der Tunnel nicht hochkommt. Der Rückfall auf gewöhnliche Konnektivität ist eine Richtlinie und sollte aufgeschrieben werden, statt sie dem Manager zu überlassen, der zuerst gestartet ist.