Pourquoi un peer WireGuard supprimé revient après un redémarrage

L'identité disparaît de l'interface en cours d'exécution et la modification semble terminée. Après le redémarrage du service, elle est de retour, ce qui se lit comme si WireGuard ignorait la commande. Ce qui s'est réellement passé est plus simple : la configuration de démarrage contient encore le peer.

Deux états tiennent cette liste. La révocation n'est réelle que lorsque les deux la perdent.

Ce que wg set change réellement

La commande wg set wg0 peer <public-key> remove modifie l'interface en cours d'exécution dans le noyau. Elle n'écrit rien sur le disque. Le fichier de configuration, le profil NetworkManager ou l'état enregistré du routeur restent intacts. C'est la conception, pas un défaut.

Cette séparation est délibérée, car l'outil n'a aucune idée de qui possède l'interface. Une commande d'exécution doit pouvoir s'appliquer sans risque à une interface gérée par autre chose. Elle ne peut pas deviner où vit la copie durable. La conséquence est facile à énoncer : une suppression à l'exécution est temporaire par construction.

Ainsi le peer revient au redémarrage suivant, et il revient avec ses préfixes autorisés d'origine. Tout ce qui est routé par son intermédiaire est recréé aussi. Une identité censément révoquée peut donc atteindre ses anciennes destinations après un rechargement. Rien dans la sortie d'exécution n'avait prévenu qui que ce soit.

Trouvez l'écrivain avant de modifier un fichier

L'interface a un propriétaire. Ce peut être wg-quick lisant un fichier, NetworkManager appliquant un profil, la configuration d'interface du routeur lui-même, ou le point d'entrée d'un conteneur qui recrée l'interface au démarrage. Modifier un fichier que le propriétaire ne lit jamais ne produit aucun changement persistant.

Partez de l'interface en cours d'exécution et identifiez les clés publiques, car les noms et les adresses sont des identifiants plus faibles que la clé elle-même. Comparez ensuite cette liste avec la configuration enregistrée que le propriétaire lit réellement.

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

Une interface vivante dont la liste des peers et le contenu du fichier ne concordent pas, c'est tout le diagnostic. La configuration enregistrée gagne au démarrage, et l'état d'exécution perd. Comparez-les avant de modifier l'un ou l'autre.

Le piège de SaveConfig

wg-quick ajoute un pli qui attrape ceux qui modifient les fichiers à la main. Lorsque SaveConfig est activé, son comportement documenté à l'arrêt réécrit l'état d'exécution courant par-dessus le fichier de configuration.

Cela inverse le sens habituel de la persistance. Vous retirez un peer du fichier, puis le service s'arrête. L'état en cours est réécrit par-dessus votre modification et rétablit le peer que vous venez de supprimer.

L'ordre compte donc : modifiez le fichier pendant que l'interface est arrêtée, ou désactivez SaveConfig avant la modification, puis remontez l'interface et confirmez ce qui a été chargé. Une modification à la main avec l'interface active est une course contre l'écriture d'arrêt.

Changez les deux états, puis rechargez

À l'exécution, retirez le peer par sa clé. Dans la configuration enregistrée, retirez le même bloc via l'opération prise en charge du propriétaire, plutôt qu'en modifiant autour.

Examinez ensuite ce que le peer transportait. Un réseau routé qui appartenait à l'identité révoquée doit être réattribué délibérément ou supprimé, pas hérité silencieusement par le peer qui sera modifié ensuite.

Gardez un chemin de récupération ouvert si la passerelle porte aussi votre accès administratif. Un redémarrage qui retire le mauvais peer est une panne que vous vous infligez. Il en va de même pour un redémarrage qui retire la mauvaise route.

À quoi ressemble un test réussi

Rechargez ou redémarrez le service, puis relisez la liste des peers. L'ancienne clé doit être absente, et les peers que vous vouliez garder doivent toujours être présents et fonctionnels.

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

Là où la situation le permet, confirmez que l'ancienne identité n'atteint plus ses anciennes ressources. Une liste d'interface propre avant un redémarrage, c'est la moitié d'un test. L'autre moitié, c'est ce que l'identité peut encore faire ensuite.

Si un gestionnaire continue de restaurer le peer, cessez de répéter la suppression de bas niveau. Corrigez l'inventaire que cet écrivain lit, car jusque-là chaque redémarrage est une nouvelle invitation pour l'identité à réapparaître.