WireGuard-Tunnel als systemd-Dienst starten
Die Vorlage wg-quick@ bringt ein benanntes Profil hoch und trägt Routen, DNS und Hooks ein. Prüfe die Unit, lass einen Verwalter zuständig bleiben und teste den Abbau.
Du hast ein WireGuard-Profil unter /etc/wireguard/wg0.conf und willst es hochfahren, ohne nach jedem Neustart wg-quick up von Hand einzutippen. Die mitgelieferte systemd-Vorlage macht genau das: [email protected] führt wg-quick für das Profil namens wg0 aus. Sie richtet außerdem Adressen, Routen, DNS und alle Hooks ein, die das Profil deklariert, also mehr als nur einen Schlüssel in den Kernel zu laden. Prüfe, ob die Vorlage auf deinem System vorhanden ist, bevor du davon ausgehst.
Der Rest dieser Anleitung folgt der Reihenfolge, in der du tatsächlich vorgehst.
Unit und Profil finden, das sie liest
Liste die Unit-Dateien mit systemctl list-unit-files 'wg-quick*' auf. Bei Distributionen, die sie mitliefern, siehst du [email protected], wobei der Instanzname aus dem Profil stammt. Die Instanz löst zu /etc/wireguard/<name>.conf auf, sodass wg-quick@wg0 ausschließlich wg0.conf liest. Wenn die Liste leer ist, ist das Tools-Paket nicht installiert und kein Aktivieren hilft mehr.
Halte das Profil auf Modus 600 und im Besitz von root. Es enthält einen privaten Schlüssel, und die Unit läuft ohne Weiteres mit schlechteren Rechten, wenn du es zulässt.
Hochfahren und Journal lesen
Starte die Instanz mit systemctl start wg-quick@wg0, prüfe dann systemctl status wg-quick@wg0 und journalctl -u wg-quick@wg0 -b. Eine Unit, die startet und sofort endet, hat meist einen Profilfehler, und das Journal nennt die Zeile. Bestätige mit wg show, dass die Schnittstelle existiert und der letzte Handshake aktuell ist. Das wg-quick-Handbuch listet, was das Skript über die Schnittstelle hinaus tut.
Eine konfigurierte Schnittstelle ohne Handshake ist ein Pfad- oder Schlüsselproblem, kein Dienstproblem.
Nur ein Verwalter
Wenn NetworkManager oder ein anderer Client den Tunnel bereits besitzt, erzeugt das Starten der systemd-Unit einen zweiten Eigentümer für dieselbe Schnittstelle, dieselben Routen und dasselbe DNS. Die Symptome sind verwirrend: Der Tunnel kommt hoch, dann verschwinden die Routen, oder DNS springt nach einigen Sekunden zurück. Wähle einen Verwalter und deaktiviere den anderen für dieses Profil. Das Journal zeigt die Übernahme meist als Routen- oder Resolver-Änderungen direkt nachdem die Unit Erfolg meldet.
Zwei Verwalter teilen sich den Besitz nicht. Sie überschreiben einander.
Stoppen, Neustart und Boot testen
Führe systemctl stop wg-quick@wg0 aus und bestätige, dass die Schnittstelle weg und die Routen entfernt sind. Starte sie dann erneut und prüfe, dass die Routen zurückkommen, denn Abbaufehler zeigen sich als liegengebliebene Routen und nicht als fehlgeschlagene Starts. Aktiviere sie schließlich beim Boot mit systemctl enable --now wg-quick@wg0 und starte einmal neu.
Beim Boot muss der Endpunktname auflösen, bevor die Unit läuft. Wenn DNS noch nicht oben ist, scheitert die Unit und bleibt gescheitert, bis du sie von Hand startest.
Den Eigentümer festhalten
Notiere, welches Profil die Unit liest, welcher Verwalter die Schnittstelle besitzt und woher die Datei stammt. Wenn jemand denselben Tunnel später in einen Desktop-Client importiert, entscheidet diese Notiz zwischen einer Migration und zwei Bereitstellungen, die um eine Adresse streiten. Halte auch den Schnittstellennamen fest, denn zwei Profile mit ähnlichen Namen sind die übliche Quelle der Verwirrung.
Ein Tunnel mit zwei Eigentümern funktioniert bis zum ersten Neustart, danach ist er ein Rätsel. Deshalb gehört die Notiz ins Repository und nicht in einen Chat-Thread.