Warum ein gelöschter WireGuard-Peer nach einem Neustart zurückkehrt

Die Identität verschwindet aus dem laufenden Interface, und die Änderung wirkt erledigt. Nach dem Neustart des Dienstes ist sie wieder da, was so aussieht, als ignoriere WireGuard den Befehl. Was tatsächlich geschah, ist einfacher: die Startkonfiguration enthält den Peer noch.

Zwei Zustände halten diese Liste. Eine Rücknahme ist erst real, wenn beide ihn verlieren.

Was wg set tatsächlich ändert

Der Befehl wg set wg0 peer <public-key> remove bearbeitet das laufende Interface im Kernel. Er schreibt nichts auf die Platte. Die Konfigurationsdatei, das NetworkManager-Profil oder der gespeicherte Zustand des Routers bleiben unberührt. Das ist das Design, kein Fehler.

Diese Trennung ist Absicht, denn das Werkzeug weiß nicht, wem das Interface gehört. Ein Laufzeitbefehl muss gegenüber einem Interface sicher sein, das von etwas anderem verwaltet wird. Es kann nicht erraten, wo die dauerhafte Kopie liegt. Die Konsequenz ist leicht zu benennen: eine Entfernung zur Laufzeit ist konstruktionsbedingt vorläufig.

Der Peer kehrt also beim nächsten Neustart zurück, und zwar mit seinen ursprünglichen erlaubten Präfixen. Alles, was durch ihn geroutet wird, entsteht ebenfalls neu. Eine angeblich zurückgenommene Identität kann ihre früheren Ziele daher nach einem Neuladen wieder erreichen. Nichts in der Laufzeitausgabe hatte jemanden gewarnt.

Finden Sie den Schreiber, bevor Sie eine Datei bearbeiten

Das Interface hat einen Besitzer. Es könnte wg-quick sein, das eine Datei liest, NetworkManager, der ein Profil anwendet, die eigene Interface-Konfiguration eines Routers oder ein Container-Einstiegspunkt, der das Interface beim Start neu erzeugt. Eine Datei zu bearbeiten, die der Besitzer nie liest, bewirkt überhaupt keine dauerhafte Änderung.

Beginnen Sie beim laufenden Interface und identifizieren Sie die öffentlichen Schlüssel, denn Namen und Adressen sind schwächere Kennungen als der Schlüssel selbst. Vergleichen Sie dann diese Liste mit der gespeicherten Konfiguration, die der Besitzer tatsächlich liest.

wg show wg0 peers
wg show wg0 allowed-ips
systemctl status wg-quick@wg0 --no-pager
ls -l /etc/wireguard

Ein laufendes Interface, dessen Peer-Liste und Dateiinhalt nicht übereinstimmen, ist die ganze Diagnose. Die gespeicherte Konfiguration gewinnt beim Start, der Laufzeitzustand verliert. Vergleichen Sie beide, bevor Sie eines von beiden ändern.

Die SaveConfig-Falle

wg-quick fügt eine Falte hinzu, die Leute fängt, die Dateien von Hand bearbeiten. Bei aktiviertem SaveConfig schreibt sein dokumentiertes Verhalten beim Herunterfahren den aktuellen Laufzeitzustand über die Konfigurationsdatei.

Das kehrt die übliche Richtung der Persistenz um. Sie entfernen einen Peer aus der Datei, dann stoppt der Dienst. Der laufende Zustand wird über Ihre Bearbeitung geschrieben und stellt den gerade gelöschten Peer wieder her.

Die Reihenfolge ist deshalb wichtig: bearbeiten Sie die Datei, während das Interface unten ist, oder deaktivieren Sie SaveConfig vor der Bearbeitung, bringen Sie das Interface danach wieder hoch und prüfen Sie, was geladen wurde. Eine Handbearbeitung bei laufendem Interface ist ein Wettlauf mit dem Schreibvorgang beim Herunterfahren.

Ändern Sie beide Zustände, dann neu laden

Entfernen Sie den Peer zur Laufzeit über den Schlüssel. Entfernen Sie in der gespeicherten Konfiguration denselben Block über die unterstützte Operation des Besitzers, statt drumherum zu editieren.

Prüfen Sie dann, was der Peer mitbrachte. Ein geroutetes Netz, das zur zurückgenommenen Identität gehörte, sollte bewusst neu zugewiesen oder entfernt werden, nicht stillschweigend von dem Peer geerbt werden, der als Nächstes bearbeitet wird.

Halten Sie einen Wiederherstellungspfad offen, wenn das Gateway auch Ihren administrativen Zugang trägt. Ein Neustart, der den falschen Peer entfernt, ist ein selbst verursachter Ausfall. Dasselbe gilt für einen Neustart, der die falsche Route entfernt.

Wie ein bestandener Test aussieht

Laden Sie den Dienst neu oder starten Sie ihn neu und lesen Sie dann die Peer-Liste erneut. Der alte Schlüssel muss fehlen, und die Peers, die Sie behalten wollten, müssen weiterhin vorhanden sein und funktionieren.

wg show wg0 peers
wg show wg0 allowed-ips
sudo wg-quick down wg0 && sudo wg-quick up wg0
wg show wg0 peers

Wo die Lage es zulässt, bestätigen Sie, dass die alte Identität ihre früheren Ressourcen nicht mehr erreicht. Eine aufgeräumte Interface-Auflistung vor einem Neustart ist die halbe Prüfung. Die andere Hälfte ist, was die Identität danach noch tun kann.

Wenn ein Manager den Peer immer wiederherstellt, hören Sie auf, die Entfernung auf niedriger Ebene zu wiederholen. Reparieren Sie das Inventar, das dieser Schreiber liest, denn bis dahin ist jeder Neustart eine weitere Einladung für die Identität, wieder aufzutauchen.