Systemd gegen NetworkManager: Wer startet das VPN beim Booten?

Zwei Ubuntu-Maschinen aus demselben Image, ein VPN-Profil, entgegengesetzte Ergebnisse bei der Anmeldung: Bei der einen steht der Tunnel, bevor der Desktop erscheint, bei der anderen kommt er nie hoch. Das Profil ist hier nicht die Variable. Unterschiedlich ist, welche von drei Komponenten ihn starten sollte, und diese drei teilen keinen Schalter.

Der Vergleich nebeneinander geht schneller als Raten. Jede von ihnen scheitert auf erkennbare Weise, und genau das macht den Vergleich sinnvoll.

Drei Starter mit drei verschiedenen Auslösern

Der paketierte openvpn-Dienst ist der älteste Weg. Sein Init-Skript liest eine Autostart-Liste aus /etc/default/openvpn. Ist diese Liste auskommentiert oder leer, startet das Skript jede Konfiguration, die es in diesem Verzeichnis findet, statt der einen, die Sie hinzugefügt haben. Eine einzige Datei für einen Tunnel kann still mehrere hochfahren.

Die zweite Zeile ist die, die Leute falsch konfigurieren. NetworkManager hält das importierte Profil und wird es starten, aber nur als Sekundärverbindung einer anderen Verbindung, was bedeutet, dass der Auslöser zur Netzwerkstrecke gehört und nicht zum VPN.

Vergleichen Sie Einrichtungsaufwand und Reichweite

Der Weg über das Init-Skript kostet eine Zeile und deckt jede Konfiguration auf dem Rechner ab. Für einen Router ist das richtig und für ein Notebook, das verschiedene Netze nutzt, falsch. Der NetworkManager-Weg kostet eine UUID-Suche und bindet den Tunnel an eine Basisverbindung. Er kommt im Arbeitsnetz hoch und bleibt in einem Hotelnetz unten.

Eine handgeschriebene Unit kostet am meisten und kauft die meiste Kontrolle, einschließlich der Reihenfolge gegenüber anderen Diensten. Die Reichweite ist der entscheidende Faktor. Hat die Maschine ein Netz und einen Tunnel, ist der paketierte Dienst ehrlich und vorhersehbar. Soll der Tunnel einem bestimmten Wi-Fi-Netz folgen, ist die Sekundärverbindung die einzige der drei, die diese Bedingung ohne zusätzliches Skripting ausdrückt.

Wählen Sie einen Eigentümer und entfernen Sie die anderen

Ein Profil, das zwei Eigentümer starten, erzeugt ein Timing, das sich zwischen Boots ändert, was schlechter ist als jeder der Mechanismen allein. Wählen Sie den Eigentümer und deaktivieren Sie dann den konkurrierenden Weg absichtlich statt versehentlich.

# who is configured to start something?
grep -v '^#' /etc/default/openvpn
systemctl list-units 'openvpn*'
nmcli -g connection.secondaries connection show 'Work Wi-Fi'

# NetworkManager: attach the tunnel to the base link by UUID
TUNNEL=$(nmcli -g UUID connection show 'Corp Tunnel')
nmcli connection modify 'Work Wi-Fi' +connection.secondaries "$TUNNEL"

Wenn der paketierte Weg stillgelegt wird, tun Sie es in der richtigen Reihenfolge: Setzen Sie AUTOSTART auf none, führen Sie systemctl daemon-reload aus, damit die generierten Units die neue Liste übernehmen, und deaktivieren Sie dann die Template-Instanz, die Sie nicht mehr wollen. Wird das Neuladen übersprungen, bleiben die alten Units aktiv, was so aussieht, als hätte die Änderung nichts bewirkt.

Ein hängendes Stoppen ist ein separates Problem mit einer begrenzten Antwort. TimeoutStopSec begrenzt, wie lange systemd wartet, bevor SIGKILL gesendet wird. Ein Drop-in ist der richtige Ort dafür, weil das Bearbeiten der paketierten Unit die Änderung beim nächsten Upgrade verliert.

Prüfen Sie, was tatsächlich gestartet wurde

Starten Sie neu und lesen Sie die Belege, statt der Konfigurationsdatei zu vertrauen. Die Unit, der der Tunnel gehört, zeigt einen aktiven Zustand und einen Startzeitstempel, der zum Booten passt, und die VPN-Schnittstelle existiert, bevor Sie sich anmelden.

systemctl is-enabled openvpn-client@office
systemctl status openvpn-client@office --no-pager
nmcli -f GENERAL.STATE,connection.secondaries connection show 'Work Wi-Fi'
ip -brief link show tun0

Eine weitere Prüfung gehört hierher: Vergewissern Sie sich, dass das ExecStart der Unit auf die Binärdatei zeigt, die Sie vermuten. Ein lokal kompilierter Client oder ein Snap-Paket braucht oft einen expliziten Pfad oder einen snap run-Wrapper, weil systemd die Suchreihenfolge Ihrer Shell nicht erbt. Der Vergleich von command -v openvpn mit der Unit-Datei klärt das in Sekunden.

Schreiben Sie den gewählten Eigentümer in die Notizen der Maschine, neben den Profilnamen. Die nächste Person, die einen fehlenden Tunnel debuggt, beginnt bei dieser Zeile, statt den Vergleich zu wiederholen.