Le pair WireGuard disparaît après un redémarrage : trouvez la vraie configuration

Le pair que vous avez ajouté avec wg set répond aux ping tout l’après-midi et disparaît après le redémarrage. Rien n’a été corrompu : le noyau n’a jamais stocké ce pair ailleurs que dans l’interface vivante, et tout ce qui recrée l’interface au démarrage l’a reconstruite à partir d’un fichier que vous n’avez pas touché. La réparation n’est pas un autre wg set. Il s’agit de découvrir quel composant possède l’interface, de modifier l’état de ce composant, puis de prouver que le pair survit exactement à l’événement de cycle de vie qui l’a supprimé.

Reproduisez-le une fois, exprès

Ne corrigez pas un problème de redémarrage avant de pouvoir le voir se produire. Avec un accès console ou hors bande disponible, notez la liste des pairs, redémarrez via le service qui possède l’interface, puis comparez. Si le pair est toujours là, votre modification a déjà atteint l’état persistant et vous déboguez le mauvais événement.

Notez trois faits pendant cette opération : le nom de l’interface, l’unité ou le profil qui l’a démarrée, et si le compteur de handshake du pair survivant a été réinitialisé. Un compteur réinitialisé signifie que l’interface a été détruite et recréée ; un compteur inchangé avec un pair absent signifie que quelque chose a modifié la configuration sous vos pieds.

Qui possède l’interface ?

WireGuard lui-même n’a ni démon ni fichier de configuration. Quelque chose au-dessus appelle wg au démarrage, et cette chose est la source de vérité. Les candidats habituels sont [email protected], un profil de connexion NetworkManager, une unité réseau propre à la distribution ou un panneau d’administration qui écrit sa propre base de données.

Interrogez le système, pas la documentation de votre distribution. systemctl status wg-quick@wg0 et nmcli connection show tranchent généralement la question en une commande chacun. Si les deux revendiquent l’interface, vous avez trouvé le bogue avant de modifier quoi que ce soit : deux propriétaires réécrivent le même périphérique à chaque démarrage, et le dernier exécuté gagne.

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

L’état d’exécution et l’état de démarrage ne sont pas le même fichier

wg set manipule le périphérique vivant via netlink. Il n’écrit pas /etc/wireguard/wg0.conf, un profil NetworkManager ni la base de données d’un panneau. Un wg show réussi ensuite prouve que le noyau a accepté le pair, pas que quelque chose va le restaurer.

Il existe un second piège dans la direction opposée. L’option SaveConfig de wg-quick réécrit l’état actuel de l’interface dans le fichier de configuration lorsque l’interface est arrêtée. Si elle est active, une modification du fichier effectuée pendant que l’interface est montée peut être écrasée par l’arrêt qui suit, et vous jurerez que la ligne y était. Si le pair revient sans cesse, lisez le fichier après un arrêt, pas avant.

NetworkManager se comporte encore autrement : il possède le profil et l’applique à l’activation, donc un .conf modifié à la main à côté d’une connexion NetworkManager active n’est que décoratif. Choisissez un seul propriétaire pour l’interface et laissez l’autre gestionnaire la laisser tranquille.

Faites atterrir la modification aux deux endroits

Modifiez d’abord l’état persistant, laissez ensuite le propriétaire l’appliquer, puis vérifiez l’état vivant. Cet ordre fait qu’un échec à n’importe quelle étape pointe vers une chose au lieu de trois.

# 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 affiche la configuration vivante dans la même syntaxe que celle utilisée par le fichier, ce qui rend les deux directement comparables. Traitez cette sortie comme un secret : elle contient des clés privées, donc ne la collez pas dans un ticket ni dans un canal de discussion. Comparez les clés publiques des pairs et les IP autorisées, et vérifiez que le pair que vous avez supprimé exprès n’est pas revenu.

Prouvez qu’il survit à l’événement de cycle de vie

Redémarrez via le propriétaire une seconde fois, puis confirmez trois choses distinctes : le pair apparaît dans wg show, le compteur de handshake augmente après du trafic, et l’application qui dépend du tunnel répond réellement. Un pair listé avec un handshake périmé est un problème de routage ou de clé, pas un problème de persistance, et cette distinction épargne une modification de configuration inutile.

Enfin, vérifiez ce que le redémarrage a restauré. Un redémarrage qui ressuscite un pair que vous avez supprimé délibérément est le même bogue avec le signe opposé, et il signifie généralement qu’une ancienne copie de la configuration est encore chargée depuis quelque part. Notez le propriétaire, le chemin du fichier, la clé publique du pair et les commandes de vérification à côté de la configuration, pour que la personne suivante ne redécouvre pas cela en redémarrant un hôte de production.