L’interface est active mais wg-quick a échoué : que faire ensuite

L’unité est rouge, l’interface existe et le tunnel fonctionne en grande partie, ce qui est la combinaison la plus déroutante qui soit. La configuration est une séquence : l’interface est créée d’abord, puis viennent les adresses, les routes, les réglages du résolveur et d’éventuelles commandes de hook. Un échec à la quatrième étape laisse les trois premières en place, donc le nom de l’interface prouve que le démarrage a commencé, pas qu’il a abouti. Un seul fait supplémentaire aurait évité la confusion : l’étape qui a échoué.

L’état partiel est l’échec normal

Ce comportement mérite d’être attendu plutôt que traité comme une corruption. L’interface est la partie la moins chère de la configuration et la plus facile à laisser derrière, et c’est aussi la partie qui donne à la machine cet air de fonctionner à moitié.

Ce qui n’existe pas encore, c’est tout ce qui venait après l’étape en échec. Si l’échec s’est produit à l’étape du résolveur, les adresses et les routes sont là et le DNS ne l’est pas. S’il s’agissait d’une route, le tunnel a une adresse et aucun chemin pour le traverser.

La conséquence est une machine qui répond à certains tests et échoue à d’autres, d’où la conclusion que le service clignote alors qu’il n’a jamais démarré correctement. Un service qui n’a jamais abouti ne peut pas clignoter. Il ne peut qu’échouer encore et encore pour la même raison.

Trouvez la première étape en échec

Lisez le journal de l’unité plutôt que le seul état courant, et lisez-le depuis le début de l’exécution en échec. La dernière ligne vous donne le code de sortie ; la première erreur vous dit quoi réparer.

Ces commandes affichent l’état de l’unité, le journal de démarrage de cette unité et l’état vivant du tunnel :

systemctl status wg-quick@wg0
journalctl -u wg-quick@wg0 -b --no-pager | tail -40
wg show
ip -4 addr show dev wg0

Une erreur de résolveur, une route qui existe déjà, un hook sorti avec un code différent de zéro et un échec d’analyse de la configuration apparaissent tous dans cette fenêtre, et chacun nomme son propre composant. Deviner à partir du seul état de l’interface ignore toutes ces informations.

Trois conditions qui décident de la réparation

Décidez si vous nettoyez, si vous réparez sur place ou si vous retirez l’unité du chemin de démarrage, et décidez-le avant de taper quoi que ce soit.

Si l’interface est cassée mais que la configuration est correcte, nettoyez et repartez de zéro. Si la configuration est fausse, corrigez-la et nettoyez quand même d’abord, car lancer un second gestionnaire sur un état partiel produit deux propriétaires pour une seule interface. Si l’échec est un composant système manquant, comme un assistant de résolveur que la machine n’a pas, installez ou retirez la dépendance délibérément au lieu de modifier l’unité jusqu’à ce qu’elle cesse de se plaindre.

Ces trois cas couvrent l’essentiel de ce qui ressemble à une unité rouge mystérieuse. La question qui tranche est de savoir si le même échec se produirait sur une machine à l’état propre, et la réponse vient généralement de la première ligne d’erreur.

Nettoyez avant de réessayer

Une nouvelle tentative sur un état existant peut échouer pour une raison nouvelle et masquer la raison d’origine. Abaissez l’interface avec le même outil qui l’a créée, puis confirmez qu’il ne reste rien.

Ne supprimez pas d’interfaces sans rapport et ne réinitialisez pas la pile réseau de l’hôte. Les deux sont des actions lourdes pour réparer un petit objet, et elles transforment un seul tunnel en échec en une machine dont les autres connexions doivent être rétablies. La bonne portée est une interface et l’unité qui la possède. Tout ce qui est plus large exige une raison écrite avant que cela n’arrive.

Prouvez le tunnel, pas l’unité

Une unité verte signifie que la séquence de démarrage s’est terminée par zéro. Cela ne signifie pas qu’un paquet a atteint l’autre côté, ni que le résolveur a été configuré comme vous le vouliez.

Envoyez une requête dans le tunnel et lisez l’état qui l’a produite :

systemctl is-active wg-quick@wg0
wg show wg0 latest-handshakes
ping -c 3 10.63.0.1
resolvectl query internal.example.net

Une poignée de main sans réponse vous dit encore que le tunnel s’est formé et que le côté distant est silencieux, ce qui est un problème différent d’une unité qui n’a jamais démarré. Gardez l’état de l’unité, la poignée de main et le résultat de la requête dans un seul enregistrement, car ils échouent indépendamment et seule la combinaison décrit le système.