Ihr VPN funktioniert erst nach der Anmeldung – wegen des Schlüsselbunds

Der Befehl funktioniert, solange Sie angemeldet sind, also legen Sie ihn in ein Startskript und gehen nach Hause. Am nächsten Morgen ist die Maschine online und der Tunnel nicht. Der Mythos besagt, ein funktionierender Aufruf sei ein funktionierender Dienst. In der Praxis ist der Unterschied meist eines von zwei Dingen: Das Profil gehört zu Ihrer Benutzersitzung statt zum System, oder das Geheimnis wird von etwas entsperrt, das erst nach Ihrer Anmeldung existiert. Beides funktioniert im manuellen Test einwandfrei und scheitert genau in dem Moment, in dem niemand hinsieht.

Warum die Anmeldung es funktionieren lässt

Eine grafische Anmeldung startet einen Sitzungsbus und einen Agenten des Geheimnisdienstes, und dort speichern viele desktoporientierte Clients das Passwort des Profils oder die Passphrase des privaten Schlüssels. Eine Aktivierung, die nach der Anmeldung als Ihr Benutzer läuft, kann diesen Agenten nach dem Geheimnis fragen und Erfolg haben. Dieselbe Aktivierung, ausgeführt von einer Starteinheit, hat keine Sitzung, keinen Bus und keinen Agenten, sodass die Suche scheitert oder an einer Eingabeaufforderung blockiert, die niemand sieht.

Führen Sie dasselbe Profil vor und nach der Anmeldung aus, und Sie erhalten zwei verschiedene Ergebnisse aus einer Konfiguration. Das ist die Signatur einer Abhängigkeit von Anmeldedaten, nicht eines defekten Tunnels, und es erklärt, warum ein manueller Test im Terminal weniger beweist, als es scheint. Der Tunnel ist in Ordnung; es fehlt das, was sein Geheimnis entsperrt.

Entscheiden Sie, welcher Eigentümer den Tunnel startet

Es gibt zwei unterstützte Muster, und sie zu mischen ist der andere Weg, auf dem dies scheitert. NetworkManager kann eine systemweite Verbindung aktivieren, was passend ist, wenn die Maschine ihre Netzwerkverwaltung bereits dort zentralisiert. Alternativ betreibt eine dedizierte systemd-Einheit das VPN direkt und besitzt die Schnittstelle selbst.

systemctl list-unit-files 'openvpn*'
systemctl list-unit-files 'wg-quick*'
nmcli connection show --active
systemctl enable --now wg-quick@wg0

Betreiben Sie nicht beide Eigentümer gegen eine Konfiguration. Wenn NetworkManager die Schnittstelle verwaltet und eine Einheit sie ebenfalls hochbringt, kämpfen sie um Routen und DNS, und der resultierende Zustand hängt davon ab, wer zuletzt fertig wurde.

Legen Sie das Geheimnis dorthin, wo ein Dienst es lesen kann

Ein Hintergrunddienst kann keine Eingabeaufforderung beantworten. Zertifikats-Passphrasen, Kontopasswörter und referenzierte Auth-Dateien brauchen alle eine Speicherregelung, die die Einheit ohne Menschen erreicht, die dem Konto gehört, das den Dienst ausführt, und für alle anderen unlesbar ist.

Die verlockende Abkürzung besteht darin, die Datei für alle lesbar zu machen, bis der Berechtigungsfehler verschwindet. Das tauscht einen Startfehler gegen eine langlebige Offenlegung von Anmeldedaten, und es ist die Art von Änderung, zu der niemand zurückkehrt. Nutzen Sie den Mechanismus, dem das Deployment bereits vertraut: eine eingeschränkte Anmeldedatendatei, ein unverschlüsselter Schlüssel, der durch Dateiberechtigungen geschützt ist, oder eine systemweite Verbindung mit eigenem Geheimnisspeicher.

Testen Sie das Ereignis, das tatsächlich eintritt

Den Dienst nach der Anmeldung manuell zu starten, testet fast nichts. Starten Sie neu oder deaktivieren Sie die grafische Anmeldung für einen Zyklus und beobachten Sie, wie die Einheit von selbst hochkommt. Das ist der einzige Test, der Verfügbarkeit der Anmeldedaten, Netzwerkbereitschaft und Einheitenreihenfolge zusammen prüft. Es ist auch der Test, der den vom Benutzer gemeldeten Fehler reproduziert, was ein manueller Start nie tut.

systemctl is-enabled wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager
systemctl status systemd-networkd-wait-online --no-pager

Die Reihenfolge zählt ebenso viel wie die Anmeldedaten. Eine Einheit, die startet, bevor der zugrunde liegende Uplink konfiguriert ist, gibt auf, und manche Distributionen unterscheiden sich darin, ob sie auf Konnektivität warten. Wenn die Einheit beim Start einen Fehler meldet, aber dreißig Sekunden später von Hand gestartet gelingt, haben Sie ein Reihenfolgeproblem gefunden und kein Geheimnisproblem.

Prüfen Sie Routen und DNS, nicht nur die Schnittstelle

Eine vorhandene Schnittstelle ist kein funktionierender Tunnel. Prüfen Sie nach einem unbeaufsichtigten Start die Routen, den Resolver-Zustand und ein Ziel per Adresse, bevor Sie einen Namen prüfen. Prüfen Sie dann die Anwendung, für die der Tunnel existiert.

ip -4 route show
resolvectl status
ping -c 3 10.61.0.1
curl -sS --max-time 5 https://internal.example/ -o /dev/null -w '%{http_code}\n'

Funktioniert die Adresse und der Name nicht, ist das verbleibende Problem die DNS-Richtlinie und nicht der Tunnel. Notieren Sie, welcher Eigentümer den Dienst startet und wo das Geheimnis liegt, denn die nächste Person, die diese Maschine neu startet, braucht beides.