WireGuard: Peer entfernen ohne Neustart, und zwar dauerhaft (2026)

Sie haben den Peer entfernt. wg show bestätigt, dass er weg ist. Eine Woche später verbindet sich der Laptop, dem Sie den Zugang entzogen haben, wieder, und nichts in Ihren Logs erklärt das.

Es ist nichts schiefgelaufen. WireGuard hat schlicht zwei Zustände, und der Befehl, den Sie benutzt haben, hat nur einen davon geändert.

Die zwei Zustände

wg set wg0 peer PUBLIC_KEY remove wirkt auf den ersten. Der Befehl greift sofort, lässt alle anderen Peers verbunden und rührt /etc/wireguard/wg0.conf nie an. Der übergebene öffentliche Schlüssel ist der 32-Byte-Curve25519-Schlüssel, dargestellt als 44 Base64-Zeichen. Deshalb wird ein Peer über diese Zeichenkette identifiziert und nicht über einen Namen: WireGuard speichert keinen.

Das nächste wg-quick down wg0 && wg-quick up wg0 (ein Reboot, ein Paket-Upgrade, ein systemd-Neustart, an den Sie nicht gedacht haben) liest also eine Datei, die den Peer noch enthält, und setzt ihn wieder ein. Niemand wird benachrichtigt. Der Zugang funktioniert einfach wieder.

Endgültig entfernen

Zwei mögliche Reihenfolgen, und die zweite ist die bessere.

Die schnelle, wenn in der Datei nichts steht, an dem Ihnen etwas liegt:

sudo wg set wg0 peer PUBLIC_KEY remove
sudo wg-quick save wg0

wg-quick save schreibt den Laufzeitzustand zurück in die Datei. Das funktioniert, schreibt die Datei aber aus Sicht des Kernels neu. Ihre Kommentare verschwinden. Auf einem Server mit einem Dutzend Peers sind diese Kommentare meist die einzige Aufzeichnung darüber, welcher Peer welcher Laptop ist. Ohne sie wird aus einer lesbaren Konfiguration eine Liste anonymer öffentlicher Schlüssel.

Die bessere, bei der die Datei maßgeblich bleibt:

sudo nano /etc/wireguard/wg0.conf        # delete the whole [Peer] block
sudo wg syncconf wg0 <(wg-quick strip wg0)

wg syncconf wendet die Datei auf das laufende Interface an, ohne es herunterzufahren: Nur was sich geändert hat, ist betroffen, und die anderen Tunnel behalten ihre Sessions. wg-quick strip entfernt die Direktiven, die der Kernel nicht versteht (Address, DNS, PostUp), und gibt den Rest aus.

Der Unterschied zählt auf einem Server mit mehreren Clients: wg-quick down && up trennt alle für ein paar Sekunden, nur um einen einzigen Peer zu widerrufen. Die Kernel-Implementierung akzeptiert bis zu 1.048.576 Peers pro Gerät. Die Grenze, an die Sie zuerst stoßen, ist also Ihre eigene Fähigkeit, sie auseinanderzuhalten, nicht die des Protokolls.

Zwei flache Schlüssel an einem einzigen Ring, an einer hellen Metallplatte, die an eine helle Holztür geschraubt ist. Der obere Schlüssel trägt die eingravierten Initialen „R.M.I.“. Warme Töne, sichtbare Holzmaserung.

An beiden Stellen prüfen, nicht nur an einer

sudo wg show wg0 peers                        # what the kernel accepts now
grep PublicKey /etc/wireguard/wg0.conf        # what loads next time

Ein Schlüssel, der im ersten fehlt und im zweiten steht, ist ein Widerruf mit Ablaufdatum. Genau für diese Situation gibt es diesen Artikel, und sie bleibt unsichtbar bis zu dem Tag, an dem das Interface neu startet.

Die hier verwendeten Live-Befehle (wg set wg0 peer <pubkey> remove, wg show wg0 latest-handshakes, wg show wg0 endpoints) stehen auf einer druckbaren A4-Seite in unserem kostenlosen WireGuard Cheat Sheet, neben den [Peer]-Schlüsseln und dem Befehl, mit dem man einen Peer live wieder hinzufügt. Direkter Download, ohne Anmeldung. Cheat Sheet herunterladen.

Was der Widerruf nicht leistet

Den Peer zu entfernen bedeutet, dass der Server den Handshake verweigert. Das Schlüsselmaterial auf dem verlorenen Gerät wird gegen diesen Server wertlos. Das ist real, und genau dort endet die Wirkung.

Der Widerruf greift nicht ganz augenblicklich, und die Verzögerung ist durch die Timer des Protokolls begrenzt. Ein Session-Schlüssel wird nach 180 Sekunden abgelehnt (REJECT_AFTER_TIME), und ein neuer Handshake wird normalerweise nach 120 Sekunden eingeleitet (REKEY_AFTER_TIME). Eine Session, die beim Entfernen des Peers bereits bestand, kann also bis zu drei Minuten lang weiter Traffic transportieren, bevor der Kernel sie verwirft. Wenn dieses Zeitfenster eine Rolle spielt, fahren Sie das Interface herunter, statt es abzuwarten.

Die Konfigurationsdatei liegt weiterhin auf diesem Gerät. Ebenso ihr privater Schlüssel und alles, was das Gerät sonst noch enthielt: eine noch offene Session, ein entsperrt gelassener Passwortmanager, das Postfach, über das sich Ihre anderen Konten zurücksetzen lassen. Den Tunnel zu widerrufen ist der richtige erste Schritt. Es ist nicht die ganze Antwort, und wer es dafür hält, ist am Ende vollkommen überzeugt und trotzdem angreifbar.

Ihre eigene Angriffsfläche einordnen: 10 Fragen, etwa drei Minuten, kein Konto, keine E-Mail, nichts wird gespeichert. Das Ergebnis nennt die eine Änderung, die Ihre Angriffsfläche am stärksten verkleinert, und für jemanden, der selbst hostet, ist das selten eine weitere Firewall-Regel.

Kurz gesagt

Ein Satz zum Merken: Ein Peer, der aus dem Speicher entfernt wurde und in der Datei steht, ist nicht entfernt, sondern nur aufgeschoben.

Braucht das widerrufene Gerät einen Ersatz, erzeugen Sie ein neues Schlüsselpaar, statt das alte wiederzuverwenden: Unser WireGuard-Konfigurationsgenerator schreibt die neue Client-Datei samt QR-Code sowie eine Server-Datei, deren [Peer]-Block Sie vor wg syncconf in Ihre eigene kopieren. Der Generator ist bis 10 Geräte kostenlos; darüber hinaus hebt WireGuard Pro (unser eigenes Produkt, einmalig 9 EUR, kein Abo) das Limit auf 250 an und liefert ein ZIP mit jeder Client-.conf und ihrem QR-Code als PNG, praktisch, um ein ganzes Büro oder eine ganze Familie in einem Rutsch einzurichten.