WireGuard-Peer verschwindet nach Neustart: die echte Konfiguration finden

Der Peer, den Sie mit wg set hinzugefügt haben, antwortet den ganzen Nachmittag auf Ping und ist nach dem Neustart weg. Nichts wurde beschädigt: Der Kernel hat diesen Peer nirgends außer in der laufenden Schnittstelle gespeichert, und alles, was die Schnittstelle beim Start neu erzeugt, hat sie aus einer Datei aufgebaut, die Sie nicht angefasst haben. Die Reparatur ist kein weiteres wg set. Sie besteht darin, herauszufinden, welche Komponente die Schnittstelle besitzt, den Zustand dieser Komponente zu bearbeiten und dann zu beweisen, dass der Peer genau das Lebenszyklusereignis übersteht, das ihn entfernt hat.

Einmal absichtlich reproduzieren

Beheben Sie kein Neustartproblem, bevor Sie es beobachten können. Mit Konsolen- oder Out-of-Band-Zugang notieren Sie die Peerliste, starten über den Dienst neu, der die Schnittstelle besitzt, und vergleichen. Ist der Peer noch da, hat Ihre Änderung den dauerhaften Zustand bereits erreicht, und Sie debuggen das falsche Ereignis.

Notieren Sie dabei drei Fakten: den Namen der Schnittstelle, die Unit oder das Profil, die sie gestartet hat, und ob der Handshake-Zähler des verbliebenen Peers zurückgesetzt wurde. Ein zurückgesetzter Zähler bedeutet, dass die Schnittstelle zerstört und neu erzeugt wurde; ein unveränderter Zähler bei fehlendem Peer bedeutet, dass etwas die Konfiguration unter Ihnen bearbeitet hat.

Wem gehört die Schnittstelle?

WireGuard selbst hat keinen Daemon und keine Konfigurationsdatei. Etwas darüber ruft beim Start wg auf, und dieses Etwas ist die Quelle der Wahrheit. Die üblichen Kandidaten sind [email protected], ein NetworkManager-Verbindungsprofil, eine distributionsspezifische Netzwerk-Unit oder ein Verwaltungsfeld, das seine eigene Datenbank schreibt.

Fragen Sie das System statt die Dokumentation Ihrer Distribution. systemctl status wg-quick@wg0 und nmcli connection show klären das meist mit je einem Befehl. Wenn beide die Schnittstelle beanspruchen, haben Sie den Fehler gefunden, bevor Sie etwas bearbeitet haben: zwei Eigentümer überschreiben bei jedem Start dasselbe Gerät, und der zuletzt ausgeführte gewinnt.

systemctl status wg-quick@wg0 --no-pager
grep -R "Address\|SaveConfig\|PostUp" /etc/wireguard/wg0.conf
nmcli -g NAME,TYPE connection show
wg show wg0 peers

Laufzeitzustand und Startzustand sind nicht dieselbe Datei

wg set bearbeitet das laufende Gerät über netlink. Es schreibt nicht /etc/wireguard/wg0.conf, ein NetworkManager-Profil oder die Datenbank eines Panels. Ein erfolgreiches wg show danach beweist, dass der Kernel den Peer angenommen hat, nicht dass etwas ihn wiederherstellen wird.

Es gibt eine zweite Falle in die Gegenrichtung. Die Option SaveConfig von wg-quick schreibt den aktuellen Zustand der Schnittstelle zurück in die Konfigurationsdatei, wenn die Schnittstelle heruntergefahren wird. Ist sie aktiv, kann eine Änderung an der Datei, während die Schnittstelle läuft, durch das folgende Herunterfahren überschrieben werden, und Sie würden schwören, die Zeile sei dort gewesen. Wenn der Peer immer wieder zurückkehrt, lesen Sie die Datei nach einem Stopp, nicht davor.

NetworkManager verhält sich wieder anders: Er besitzt das Profil und wendet es bei der Aktivierung an, sodass eine von Hand bearbeitete .conf neben einer aktiven NetworkManager-Verbindung reine Dekoration ist. Wählen Sie einen Eigentümer für die Schnittstelle und lassen Sie den anderen Manager sie in Ruhe.

Dafür sorgen, dass die Änderung an beiden Stellen landet

Bearbeiten Sie zuerst den dauerhaften Zustand, lassen Sie ihn dann vom Eigentümer anwenden und prüfen Sie anschließend den laufenden Zustand. Diese Reihenfolge bedeutet, dass ein Fehler an jedem Schritt auf eine Sache statt auf drei zeigt.

# 1. persistent state (wg-quick owner)
sudo vi /etc/wireguard/wg0.conf

# 2. apply through the owner, not by hand
sudo systemctl restart wg-quick@wg0

# 3. verify runtime matches the file
sudo wg show wg0
sudo wg showconf wg0

wg showconf gibt die laufende Konfiguration in der Syntax aus, die auch die Datei verwendet, wodurch beide direkt vergleichbar sind. Behandeln Sie diese Ausgabe als Geheimnis: Sie enthält private Schlüssel, also nicht in ein Ticket oder einen Chatkanal kopieren. Vergleichen Sie die öffentlichen Schlüssel der Peers und die erlaubten IP-Adressen und prüfen Sie, ob der absichtlich entfernte Peer nicht zurück ist.

Beweisen, dass er das Lebenszyklusereignis übersteht

Starten Sie ein zweites Mal über den Eigentümer neu und bestätigen Sie dann drei getrennte Dinge: Der Peer erscheint in wg show, der Handshake-Zähler steigt nach Verkehr, und die Anwendung, die vom Tunnel abhängt, antwortet tatsächlich. Ein Peer mit veraltetem Handshake ist ein Routing- oder Schlüsselproblem, kein Persistenzproblem, und diese Unterscheidung erspart eine sinnlose Konfigurationsänderung.

Prüfen Sie zum Schluss, was der Neustart wiederhergestellt hat. Ein Neustart, der einen absichtlich entfernten Peer wiederbelebt, ist derselbe Fehler mit umgekehrtem Vorzeichen, und meist bedeutet es, dass irgendwo noch eine alte Kopie der Konfiguration geladen wird. Notieren Sie Eigentümer, Dateipfad, öffentlichen Schlüssel des Peers und die Prüfbefehle neben der Konfiguration, damit die nächste Person das nicht erneut entdeckt, indem sie einen Produktionshost neu startet.