Warum wg-quick wg0.conf beim Stoppen der Schnittstelle neu schreibt

Sie fügen einen Peer zu /etc/wireguard/wg0.conf hinzu, führen systemctl restart wg-quick@wg0 aus, und beim nächsten Blick fehlt der Peer in der Datei. Nichts hat irgendetwas beschädigt. Ein Neustart ist ein Stoppen mit anschließendem Starten, und der Stopp-Schritt kann den aktuellen Laufzeitzustand über die gerade bearbeitete Datei schreiben. Die verantwortliche Einstellung liegt in derselben Datei, die Sie bearbeitet haben, und genau das macht die Schleife beim ersten Mal so verwirrend.

Zwei Zustände, eine Datei und ein Speichern beim Herunterfahren

WireGuards Laufzeitzustand und eine wg-quick-Konfigurationsdatei hängen zusammen, sind aber verschieden. Die Datei ist die Eingabe: wg-quick liest sie, erstellt die Schnittstelle, setzt Adressen und Routen und konfiguriert Peers. Das Kernel-Gerät ist das lebende Objekt, und Änderungen auf niedriger Ebene mit wg schreiben sich nie selbst zurück.

Außer in eine Richtung. Wenn SaveConfig = true im Schnittstellenabschnitt steht, speichert wg-quick die laufende Konfiguration in die Datei, während die Schnittstelle heruntergefahren wird. Das wg-quick-Handbuch warnt genau davor: Änderungen an der Datei, während die Schnittstelle aktiv ist, können beim Entfernen überschrieben werden. Es ist ein Speichern beim Herunterfahren, kein Hintergrundtimer, also greift es nur, wenn etwas die Schnittstelle stoppt.

Lesen Sie die Tabelle als Warnung zur Reihenfolge. Jeder versehentliche Verlust in diesem Bereich entsteht durch eine Bearbeitung vor einem Speichern statt danach.

Erst stoppen, dann bearbeiten, zuletzt starten

Wenn die Datei Ihre Quelle der Wahrheit ist, machen Sie die Datei durch Konstruktion verbindlich statt durch Hoffnung. Fahren Sie die Schnittstelle herunter, bestätigen Sie, dass sie weg ist, bearbeiten Sie dann und bringen Sie sie danach wieder hoch. Die Regel ist einfach: Es existiert keine Bearbeitung, solange noch ein Speichern laufen kann.

sudo cp -a /etc/wireguard/wg0.conf /root/wg0.conf.$(date +%F-%H%M)
sudo wg-quick down wg0
ls /sys/class/net/wg0 2>/dev/null || echo "interface is gone"
sudoedit /etc/wireguard/wg0.conf
sudo wg-quick up wg0

Die Backup-Zeile ist keine Zeremonie. Wenn der Tunnel der Weg zu dieser Maschine ist, kann der Herunterfahr-Schritt Ihre Sitzung beenden, und eine Kopie auf der Platte plus eine Konsole oder ein Out-of-Band-Weg ist der einzige Rollback, der funktioniert. Prüfen Sie diese zweite Zeile, bevor Sie ihr trauen: ein veralteter Schnittstellenname in einem Skript, das still scheitert, ist der Weg, wie Menschen eine Datei bearbeiten, die noch lebt.

SaveConfig = false vor einem normalen Herunterfahren zu setzen ist der andere akzeptierte Weg, und es muss in der Datei geschehen, die wg-quick tatsächlich liest. Es verhindert dieses eine automatische Speichern. Es bewirkt nicht, dass ein separates NetworkManager-Profil, ein Router-Export oder ein Container-Einstiegspunkt Ihre Änderungen neu laden, denn diese Verwalter lesen diese Datei überhaupt nicht.

Peer-Änderungen anwenden, ohne die Schnittstelle abzureißen

Nicht jede Bearbeitung braucht eine Ausfallzeit. Änderungen auf Peer-Ebene lassen sich auf eine laufende Schnittstelle anwenden, indem man die Datei in eine Konfiguration umwandelt und sie synchronisiert, was den Herunterfahr-Schritt ganz vermeidet und damit das Speichern umgeht:

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)
sudo wg show wg0 peers
sudo wg show wg0 latest-handshakes

Der strip-Schritt ist wichtig. Er gibt die Datei mit entfernten Schlüsseln aus, die nur wg-quick gehören, sodass Adressen, DNS und Routing-Anweisungen nicht an ein Werkzeug gehen, das sie nicht versteht. Die Synchronisierung wendet dann Peers und Schlüssel auf das lebende Gerät an, ohne die Schnittstelle neu zu erstellen, sodass bestehende Sitzungen und Routen überleben.

Seien Sie präzise bei den Grenzen. Das Synchronisieren von Peers ändert nicht die Schnittstellenadresse, die von wg-quick hinzugefügten Routen oder die Resolver-Konfiguration, denn nichts davon gehört zum WireGuard-Gerät. Ein Subnetz zu AllowedIPs hinzuzufügen und zu erwarten, dass der Kernel es routet, ist die klassische Fehllesung; die Route muss von wg-quick beim Hochfahren oder von Ihnen hinzugefügt werden.

Prüfen Sie, wem die Schnittstelle gehört, bevor Sie etwas bearbeiten

Auf einem Desktop oder einem Server, der von einem Konfigurationssystem verwaltet wird, kann die Datei eine Ausgabe statt einer Eingabe sein. Eine NetworkManager-Verbindung, ein vom Router erzeugtes Profil oder ein Container-Startskript können alle denselben Schnittstellennamen besitzen, und in diesem Fall bearbeitet eine fehlerfreie wg-quick-Sequenz trotzdem das falsche Artefakt.

systemctl status wg-quick@wg0 --no-pager
nmcli connection show | grep -i wireguard
sudo wg showconf wg0 | head -n 5

Der dritte Befehl gibt die laufende Konfiguration im selben Format wie die Datei aus, einschließlich des privaten Schlüssels, was für den Vergleich nützlich und in einem Ticket gefährlich ist. Schwärzen Sie ihn vor dem Einfügen; ein privater Schlüssel in einem Support-Thread ist eine dauerhafte Kompromittierung, kein Tippfehler.

Wenn die Service-Unit inaktiv ist, die Schnittstelle aber existiert, hat etwas anderes sie erstellt, und die Datei ist nicht verbindlich. Diese eine Beobachtung spart eine Stunde Bearbeitung einer Datei, die nichts liest.

Den nächsten Neustart prüfen und dann einen Rollback behalten

Der Test, der die Korrektur wirklich beweist, ist ein zweiter Neustart, denn genau diese Sequenz ist beim ersten Mal fehlgeschlagen. Bestätigen Sie, dass der Peer ihn übersteht und dass die laufende Konfiguration noch dem entspricht, was auf der Platte liegt:

sudo systemctl restart wg-quick@wg0
sudo wg show wg0 latest-handshakes
sudo grep -c '^\[Peer\]' /etc/wireguard/wg0.conf

Führen Sie den Neustart zweimal aus. Ein einzelner sauberer Durchlauf kann Glück sein: Der erste Neustart kann eine Laufzeitänderung verbrauchen, die noch nicht gespeichert war, also ist der zweite derjenige, der Ihnen sagt, dass Datei und Laufzeit am Ende des ersten übereinstimmten.

Behalten Sie das Backup vom Beginn des Vorgangs, bis Sie den doppelten Neustart erledigt haben, und löschen Sie es dann oder verschieben Sie es aus dem Konfigurationsverzeichnis. Ein verirrtes wg0.conf.bak neben der echten Datei ist für wg-quick harmlos und für die nächste Person verwirrend, die irgendwann die falsche bearbeitet.