VPNSmith
VPS Contabo
self-host-vpnINFO

WireGuard : supprimer un peer sans redémarrer, et que ça tienne (2026)

wg set peer remove agit immédiatement et s'efface au prochain wg-quick down/up. La différence entre l'état en cours et le fichier de configuration, pourquoi le peer revient, et l'ordre des opérations qui révoque vraiment l'accès.

Par Eric Gerard · Fondateur · VPNSmith - Spécialiste self-host VPN & VPS GDPR5 min de lecturePhoto via Pexels

Tu as supprimé le peer. wg show confirme qu'il a disparu. Une semaine plus tard, le portable que tu as révoqué se reconnecte, et rien dans tes logs ne l'explique.

Rien n'a dysfonctionné. WireGuard a simplement deux états, et la commande que tu as utilisée n'en a modifié qu'un seul.

Les deux états

ce que c'estce qui le modifie
état en coursce que le noyau accepte en ce momentwg set, wg syncconf
fichier de configurationce qui est chargé au prochain démarrageton éditeur, wg-quick save

wg set wg0 peer PUBLIC_KEY remove agit sur le premier. C'est immédiat, tous les autres peers restent connectés, et la commande ne touche jamais à /etc/wireguard/wg0.conf. La clé publique que tu passes est la clé Curve25519 de 32 octets affichée sous forme de 44 caractères base64 : c'est pour cela qu'un peer est identifié par cette chaîne et non par un nom. WireGuard ne stocke aucun nom pour lui.

Du coup, le prochain wg-quick down wg0 && wg-quick up wg0 (un reboot, une mise à jour de paquet, un redémarrage systemd auquel tu n'avais pas pensé) lit un fichier qui contient toujours le peer, et le remet en place. Personne n'est prévenu. L'accès reprend, tout simplement.

Le supprimer pour de bon

Deux façons de procéder, et c'est la seconde qu'il faut préférer.

La rapide, quand le fichier ne contient rien qui t'importe :

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

wg-quick save réécrit l'état en cours dans le fichier. Ça marche, et ça réécrit le fichier du point de vue du noyau. Tes commentaires disparaissent. Sur un serveur avec une douzaine de peers, ces commentaires sont généralement la seule trace de quel peer correspond à quel portable. Les perdre transforme une config lisible en liste de clés publiques anonymes.

Celle à préférer, qui garde le fichier comme référence :

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

wg syncconf applique le fichier à l'interface active sans la faire tomber : seul ce qui a changé est affecté, et les autres tunnels conservent leurs sessions. wg-quick strip retire les directives que le noyau ne comprend pas (Address, DNS, PostUp) et affiche le reste.

La différence compte sur un serveur avec plusieurs clients : wg-quick down && up coupe tout le monde pendant quelques secondes pour révoquer un seul peer. L'implémentation noyau accepte jusqu'à 1 048 576 peers par interface, donc la limite que tu atteindras en premier est ta propre capacité à les distinguer, pas celle du protocole.

Deux clés plates sur un anneau suspendues à une plaque de métal clair fixée sur une porte en bois clair, la clé du haut gravée des initiales R.M.I.
Deux clés plates sur un anneau suspendues à une plaque de métal clair fixée sur une porte en bois clair, la clé du haut gravée des initiales R.M.I.

Deux clés plates sur un même anneau, suspendues à une plaque de métal clair vissée sur une porte en bois clair. La clé du haut porte les initiales gravées « R.M.I. ». Tons chauds, veinage du bois visible.

Vérifier aux deux endroits, pas à un seul

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

Une clé absente du premier et présente dans le second, c'est une révocation avec une date d'expiration. C'est exactement la situation pour laquelle cet article existe, et elle reste invisible jusqu'au jour où l'interface redémarre.

Les commandes à chaud utilisées ici (wg set wg0 peer <pubkey> remove, wg show wg0 latest-handshakes, wg show wg0 endpoints) tiennent sur une page A4 imprimable dans notre WireGuard Cheat Sheet gratuite, à côté des clés du bloc [Peer] et de la commande qui rajoute un peer à chaud. Téléchargement direct, sans inscription. Télécharger l'aide-mémoire.

Ce que la révocation ne fait pas

Supprimer le peer signifie que le serveur refuse le handshake. Les clés présentes sur l'appareil perdu deviennent inutilisables contre ce serveur. C'est réel, et c'est là que l'effet s'arrête.

La révocation n'est pas tout à fait instantanée, et le délai est borné par les propres temporisations du protocole. Une clé de session est rejetée au bout de 180 secondes (REJECT_AFTER_TIME), et un nouveau handshake est normalement initié au bout de 120 secondes (REKEY_AFTER_TIME). Une session déjà établie au moment où tu as supprimé le peer peut donc continuer à transporter du trafic jusqu'à trois minutes avant que le noyau ne la coupe. Si cette fenêtre compte, fais tomber l'interface plutôt que d'attendre.

Le fichier de configuration est toujours sur cet appareil. Sa clé privée aussi, et tout ce que l'appareil contenait : une session encore ouverte, un gestionnaire de mots de passe resté déverrouillé, la boîte mail qui peut réinitialiser tes autres comptes. Révoquer le tunnel est le bon premier geste. Ce n'est pas toute la réponse, et le considérer comme tel, c'est ainsi qu'on finit parfaitement confiant et toujours exposé.

Situer ta propre surface d'attaque, 10 questions, environ trois minutes, sans compte, sans e-mail, rien n'est conservé. Le résultat nomme le changement qui réduit le plus ton exposition, et pour quelqu'un qui auto-héberge, c'est rarement une règle de pare-feu de plus.

En bref

Ce que tu as faitCe que ça a réellement changé
wg set … peer … removel'état en cours seulement, annulé au redémarrage
wg-quick savele fichier aussi, au prix de tes commentaires
modifier le fichier, puis wg syncconfles deux, sans couper les autres peers
révoqué après la perte d'un appareille tunnel, pas ce que l'appareil détient encore

Une phrase à retenir : un peer supprimé de la mémoire et laissé dans le fichier n'est pas supprimé, il est reporté.

Quand l'appareil révoqué doit être remplacé, génère une nouvelle paire de clés plutôt que de réutiliser l'ancienne : notre générateur de config WireGuard écrit le nouveau fichier client et son code QR, ainsi qu'un fichier serveur dont tu copies le bloc [Peer] dans le tien avant wg syncconf. Le générateur est gratuit jusqu'à 10 appareils ; au-delà, WireGuard Pro (notre propre produit, 9 EUR une fois, sans abonnement) relève la limite à 250 et ajoute un ZIP unique avec chaque .conf client et son code QR en PNG, pratique pour équiper tout un bureau ou toute une famille d'un coup.

★ Datacenter Nuremberg GDPR · ✓ IPv4 dédiée incluse · port 200 Mbit/s

Héberge ton VPN sur ton propre VPS → ContaboAccès root complet · IPv4 publique · choisis ta région→

Questions fréquentes

Comment supprimer un peer WireGuard sans redémarrer le tunnel ?
Utilise wg set wg0 peer PUBLIC_KEY remove. La suppression est immédiate, les autres peers ne sont pas touchés et aucune interface ne tombe. Ce que la commande ne fait pas, c'est modifier ton fichier de configuration : le peer disparaît uniquement de l'état en cours, et il reviendra la prochaine fois que l'interface sera montée à partir de ce fichier.
Pourquoi le peer que j'ai supprimé revient-il ?
Parce que tu l'as supprimé de la mémoire, pas du disque. WireGuard a deux états distincts : ce que le noyau détient en ce moment, que wg set modifie, et ce que contient /etc/wireguard/wg0.conf, que wg-quick lit au démarrage. Supprime le peer de l'un sans l'autre et le prochain wg-quick down puis up le restaure, sans rien dire. C'est la façon la plus courante de croire un accès révoqué alors qu'il fonctionne toujours.
Que fait réellement wg-quick save ?
Il réécrit l'état en cours dans le fichier de configuration, ce qui rend bien la suppression permanente. Le prix à payer : il réécrit le fichier du point de vue du noyau. Les commentaires disparaissent, l'ordre change, et tout ce que wg-quick ne modélise pas (tes propres annotations indiquant à quel appareil appartient chaque peer) est perdu. Sur un serveur avec une douzaine de peers, ces commentaires sont généralement la seule chose qui te dit qui est qui.
Comment vérifier qu'un peer a vraiment disparu ?
Deux commandes, parce qu'il y a deux états. wg show wg0 peers liste ce que le noyau accepte actuellement. grep PublicKey /etc/wireguard/wg0.conf montre ce qui sera chargé la prochaine fois. Un peer absent du premier et présent dans le second, c'est une révocation qui expire au prochain redémarrage.
Supprimer un peer suffit-il après la perte d'un appareil ?
Pour le tunnel, oui : sans entrée de peer correspondante, le serveur refuse le handshake, et les clés présentes sur l'appareil perdu deviennent inutilisables contre lui. Cela ne change rien à l'appareil lui-même. Le fichier de configuration, sa clé privée et tout ce que l'appareil contenait sont toujours là, entre les mains de quelqu'un d'autre. Révoquer est le bon premier geste, ce n'est pas toute la réponse.