WireGuard n’affiche aucune poignée de main récente : que vérifier en premier

Un champ de dernière poignée de main vide signifie généralement que l’interface n’a terminé aucune poignée de main depuis son démarrage, ce qui en dit moins sur la configuration qu’il n’y paraît. WireGuard reste silencieux jusqu’à ce qu’un paquet doive sortir par l’interface, donc un peer inactif sans rien à envoyer rapporte exactement cela. Établissez si quelque chose a réellement été proposé avant d’inspecter les clés.

Le test est un paquet autorisé vers une destination que le peer devrait porter. Tout le reste sur cet écran d’état décrit une intention plutôt qu’une activité.

Une interface inactive n’a rien à signaler

WireGuard effectue les poignées de main paresseusement : le premier paquet qui a besoin du tunnel déclenche l’échange, et l’interface reste silencieuse jusque-là. Un peer configuré et jamais utilisé affiche une poignée de main vide, zéro octet reçu et un écart croissant depuis la dernière. Cet état est sain pour un client inactif et alarmant seulement si vous attendiez déjà du trafic. Vérifiez aussi les compteurs de transfert, car ils distinguent rien-envoyé de essayé-et-échoué.

Si les compteurs restent à zéro des deux côtés, le problème se situe en amont du tunnel. Rien n’a atteint l’interface pour déclencher quoi que ce soit.

Déclenchez le trafic que le peer est autorisé à porter

Choisissez une adresse dans les préfixes autorisés du peer, sur la machine locale, et confirmez que la table de routage l’enverrait par l’interface. Une destination hors de ces préfixes produit une requête routée ordinaire sans aucune implication de WireGuard. Utilisez un service qui répond vite, comme un ping ou une courte connexion TCP, pour que la tentative ait un début et une fin visibles. Relisez ensuite la ligne de poignée de main au lieu de fixer l’écran en attendant.

ip route get 10.60.9.5
ping -c 3 -W 2 10.60.9.5
wg show wg0 latest-handshakes
wg show wg0 transfer

La requête de route compte plus que le ping. Si elle nomme l’interface physique, le paquet n’est jamais entré dans le tunnel et la poignée de main vide est une réponse de routage, non cryptographique. Réparez la route avant de déboguer le peer.

Comparez la paire de clés et le point de terminaison

Une fois le trafic réellement proposé, l’identité est le contrôle suivant. La clé privée locale doit correspondre à la clé publique autorisée par l’autre côté, la clé publique distante configurée doit identifier le peer prévu, et toute clé pré-partagée doit correspondre aux deux extrémités. Une seule différence de caractère dans une clé base64 produit un peer qui semble configuré et ne termine jamais d’échange. Comparez avec le registre de provisionnement plutôt que de régénérer les clés, car une nouvelle clé invalide tous les peers qui faisaient confiance à l’ancienne.

Le point de terminaison exige le même examen : nom d’hôte, adresse, port UDP et la famille utilisée pour l’atteindre. Une adresse obsolète ou le mauvais port produisent un silence plutôt qu’un message.

Surveillez le chemin UDP externe

La poignée de main voyage en UDP vers le point de terminaison, le chemin externe doit donc la porter. Les commandes ci-dessous vérifient l’existence d’un écouteur, si la pile locale a émis le datagramme et quel point de terminaison est configuré. Lancez la capture pendant que vous déclenchez le trafic, pas avant.

ss -lunp | grep 51820
sudo tcpdump -ni eth0 udp port 51820
wg show wg0 endpoints
conntrack -L -p udp | grep 51820

Une capture montrant l’initiation sans réponse indique l’extérieur de la machine, car l’extrémité distante n’écoute pas, est filtrée ou est mal adressée. Une capture qui ne montre rien signifie que le paquet n’est jamais parti, ce qui vous ramène à la route et à toute marque de socket en jeu. Lorsque vous administrez les deux extrémités, corrélez la tentative par horodatage avec une capture étroite sur le serveur plutôt qu’une capture générale. Un test de port TCP ne prouve rien ici, car le protocole est uniquement UDP.

Dès qu’une poignée de main apparaît, testez une application à travers le tunnel, car un échange terminé prouve l’identité et l’accessibilité, pas un débit utilisable ni un DNS correct. Conservez la sortie d’état avant et après le changement, et la différence devient votre preuve.