Vous ajoutez un peer à /etc/wireguard/wg0.conf, exécutez systemctl restart wg-quick@wg0, et le peer a disparu du fichier au prochain coup d’œil. Rien n’a rien corrompu. Un redémarrage est un arrêt suivi d’un démarrage, et l’étape d’arrêt peut réécrire l’état d’exécution courant par-dessus le fichier que vous venez de modifier. Le réglage responsable se trouve dans le même fichier que vous modifiiez, et c’est ce qui rend la boucle si déroutante la première fois qu’on la rencontre.

Deux états, un fichier et une sauvegarde à l’arrêt

L’état d’exécution de WireGuard et un fichier de configuration wg-quick sont liés mais distincts. Le fichier est une entrée : wg-quick le lit, crée l’interface, définit les adresses et les routes et configure les peers. Le périphérique du noyau est l’objet vivant, et les modifications de bas niveau effectuées avec wg ne se réécrivent jamais d’elles-mêmes.

Sauf dans un sens. Quand SaveConfig = true apparaît dans la section de l’interface, wg-quick sauvegarde la configuration vivante dans le fichier lors de la descente de l’interface. Le manuel de wg-quick met exactement en garde contre cela : les modifications faites au fichier pendant que l’interface est active peuvent être écrasées lorsqu’elle est supprimée. C’est une sauvegarde à l’arrêt, pas un minuteur d’arrière-plan, donc elle ne se déclenche que lorsque quelque chose arrête l’interface.

ActionWhat it writesWhen it surprises you
wg set on a live interfaceKernel state onlyAfter reboot, when the file was never updated
wg-quick down with SaveConfigLive state into the fileRight after you edited the file
wg syncconfKernel state onlyNever; it does not touch the file
wg-quick upKernel state from the fileIf the file is stale, you get the old tunnel

Lisez le tableau comme un avertissement sur l’ordre. Chaque perte accidentelle dans ce domaine vient d’une modification faite avant une sauvegarde plutôt qu’après.

Arrêtez d’abord, modifiez ensuite, démarrez en dernier

Si le fichier est votre source de vérité, rendez le fichier faisant autorité par construction plutôt que par espoir. Descendez l’interface, confirmez qu’elle a disparu, puis modifiez, puis remontez-la. La règle est simple : aucune modification n’existe tant qu’une sauvegarde peut encore s’exécuter.

sudo cp -a /etc/wireguard/wg0.conf /root/wg0.conf.$(date +%F-%H%M)
sudo wg-quick down wg0
ls /sys/class/net/wg0 2>/dev/null || echo "interface is gone"
sudoedit /etc/wireguard/wg0.conf
sudo wg-quick up wg0

La ligne de sauvegarde n’est pas une cérémonie. Si le tunnel est votre moyen d’atteindre cette machine, l’étape de descente peut mettre fin à votre session, et une copie sur disque plus une console ou un chemin hors bande est le seul retour arrière qui fonctionne. Vérifiez cette deuxième ligne avant de lui faire confiance : un nom d’interface obsolète dans un script qui échoue silencieusement est la façon dont les gens modifient un fichier qui est encore vivant.

Mettre SaveConfig = false avant une descente normale est l’autre voie acceptée, et cela doit être fait dans le fichier que wg-quick lit réellement. Cela empêche cette unique sauvegarde automatique. Cela n’oblige pas un profil NetworkManager séparé, un export de routeur ou un point d’entrée de conteneur à recharger vos modifications, car ces gestionnaires ne lisent jamais ce fichier.

Appliquez les changements de peers sans déchirer l’interface

Toute modification n’exige pas une coupure. Les changements au niveau des peers peuvent être appliqués à une interface en cours d’exécution en convertissant le fichier en configuration et en le synchronisant, ce qui évite entièrement l’étape de descente et donc la sauvegarde :

sudo wg syncconf wg0 <(sudo wg-quick strip wg0)
sudo wg show wg0 peers
sudo wg show wg0 latest-handshakes

L’étape strip compte. Elle imprime le fichier avec les clés propres à wg-quick retirées, afin que les adresses, le DNS et les directives de routage n’arrivent pas dans un outil qui ne les comprend pas. La synchronisation applique ensuite les peers et les clés à l’appareil vivant sans recréer l’interface, donc les sessions et routes existantes survivent.

Soyez précis sur les limites. Synchroniser des peers ne change pas l’adresse de l’interface, les routes ajoutées par wg-quick ni la configuration du résolveur, car rien de tout cela n’appartient au périphérique WireGuard. Ajouter un sous-réseau à AllowedIPs et s’attendre à ce que le noyau le route est la mauvaise lecture classique ; la route doit être ajoutée par wg-quick au démarrage ou par vous.

Vérifiez qui possède l’interface avant de modifier quoi que ce soit

Sur un poste de travail ou un serveur géré par un système de configuration, le fichier peut être une sortie plutôt qu’une entrée. Une connexion NetworkManager, un profil généré par un routeur ou un script de démarrage de conteneur peuvent tous posséder le même nom d’interface, et dans ce cas une séquence wg-quick impeccable modifie quand même le mauvais artefact.

systemctl status wg-quick@wg0 --no-pager
nmcli connection show | grep -i wireguard
sudo wg showconf wg0 | head -n 5

La troisième commande imprime la configuration vivante dans le même format que le fichier, clé privée incluse, ce qui est utile pour comparer et dangereux dans un ticket. Masquez-la avant de la coller ; une clé privée dans un fil d’assistance est un compromis permanent, pas une faute de frappe.

Si l’unité de service est inactive mais que l’interface existe, autre chose l’a créée et le fichier ne fait pas autorité. Cette seule observation économise une heure de modification d’un fichier que rien ne lit.

Vérifiez le prochain redémarrage, puis gardez un retour arrière

Le test qui prouve réellement le correctif est un deuxième redémarrage, car c’est la séquence qui a échoué la première fois. Confirmez que le peer y survit et que la configuration vivante correspond toujours à ce qui est sur le disque :

sudo systemctl restart wg-quick@wg0
sudo wg show wg0 latest-handshakes
sudo grep -c '^\[Peer\]' /etc/wireguard/wg0.conf

Exécutez le redémarrage deux fois. Une seule passe propre peut être de la chance : le premier redémarrage peut consommer un changement d’exécution qui n’avait pas encore été sauvegardé, donc le second est celui qui vous dit que le fichier et l’exécution étaient d’accord à la fin du premier.

Gardez la sauvegarde depuis le début du processus jusqu’à ce que vous ayez fait le double redémarrage, puis supprimez-la ou déplacez-la hors du répertoire de configuration. Un wg0.conf.bak égaré à côté du vrai fichier est inoffensif pour wg-quick et déroutant pour la personne suivante, qui finira par modifier le mauvais.

Articles similaires