Handshake actif, adresse disparue : trois états de WireGuard

WireGuard peut avoir un handshake récent et aucune adresse en même temps, et cet état est cohérent plutôt que contradictoire. Le handshake est un événement du pair, l'adresse appartient à l'interface, et la route décide par quel lien montant un paquet sort. Trois couches, trois propriétaires, et chacune peut échouer pendant que les deux autres semblent saines.

Les lire comme un seul état, c'est ce qui transforme un diagnostic de deux minutes en un après-midi entier de redémarrages de services.

Un handshake est un événement du pair, pas un événement d'adressage

Le handshake de WireGuard prouve que le pair configuré a répondu avec une clé valide et que les clés de session sont à jour. Il ne dit rien de l'adresse locale sur l'interface, ni si une route pointe vers elle. Un assistant ou un gestionnaire de réseau attribue l'adresse, tandis que la configuration du protocole ne fait que nommer des pairs et des clés. Confondre les deux, c'est ainsi qu'un handshake sain se lit comme un tunnel qui fonctionne.

C'est pourquoi wg show peut signaler un handshake vieux de quelques secondes sur une interface qui ne peut accepter un seul paquet d'une application.

Un gestionnaire qui recrée l'interface peut perdre l'adresse sans toucher à la configuration du pair, et le handshake suivant réussit immédiatement parce que les clés n'ont jamais changé. La ligne de journal sur un handshake réussi est exacte et sans rapport avec la panne.

L'adresse de l'interface a son propre propriétaire

Une adresse sur l'appareil tunnel peut venir de la ligne Address d'un assistant, d'un client DHCP exécuté sur l'interface, ou d'un démon de gestion qui la crée à la connexion. Quel qu'il soit, ce composant possède l'adresse et la rétablira ou non selon sa propre logique. Lire l'adresse sans nommer son propriétaire vous laisse incapable d'expliquer pourquoi elle a disparu.

Deux propriétaires sur une interface, c'est la panne classique. Lancer un assistant et un gestionnaire de réseau de bureau sur le même appareil produit une course où l'un supprime ce que l'autre vient de configurer, et le point de terminaison continue de répondre pendant tout ce temps.

Choisissez un seul propriétaire et laissez l'autre outil observer plutôt que gérer. Cette décision mérite d'être écrite, car le symptôme apparaît des semaines plus tard et ressemble à une perte d'adresse aléatoire.

Une route choisit un lien montant, pas l'interface

Une route interne qui pointe vers wg0 décide que le trafic entre dans le tunnel. Une décision distincte envoie les paquets externes chiffrés vers le pair, et sur un hôte doté de plusieurs liens montants cette décision vient de la table de transfert et des règles de politique. Une itinérance Wi-Fi peut changer le chemin externe sans toucher à l'adresse interne.

Ainsi, un tunnel qui fonctionne et un pair injoignable sont des états compatibles, tout comme un pair correct et une route interne cassée. Les trois observations doivent être prises ensemble, au même moment, sinon la comparaison n'a aucun sens.

Comparez les trois états en une seule passe

Trois commandes en lecture seule répondent aux trois questions dans l'ordre qui isole le plus vite la panne. Exécutez-les sans rien changer entre elles.

ip address show dev wg0
ip route get 10.80.0.1
wg show wg0 latest-handshakes transfer

La première montre si l'interface possède une adresse, et la deuxième montre quel appareil une destination donnée utiliserait maintenant. La troisième rapporte l'heure du dernier handshake et les compteurs d'octets, et c'est la seule des trois qui décrit le pair plutôt que l'hôte local.

Lisez les compteurs autant que l'horodatage. Un handshake qui se rafraîchit sans cesse pendant que le transfert reste plat signifie que le pair répond mais que rien d'utile ne passe, ce qui pointe vers le routage ou une ACL plutôt que vers les clés. Un horodatage qui cesse d'avancer alors qu'une adresse est présente pointe vers l'amont. Les deux lectures viennent de la même ligne de sortie, et aucune n'est visible si vous vérifiez seulement qu'un handshake existe.

Corrigez l'état précis qui est faux, puis retestez l'application plutôt que le tunnel. Un handshake récent est une preuve sur le pair, et une preuve sur le pair n'est pas la preuve que la prochaine requête de votre navigateur trouvera une adresse, une route et un lien montant qui fonctionne. Le manuel de wg-quick indique explicitement lesquels de ces éléments l'assistant met en place et lesquels relèvent du protocole.