La poignée de main WireGuard aboutit, mais aucune réponse ne revient
Une poignée de main récente prouve que les clés fonctionnent. Suivez une adresse interne et lisez les compteurs de transfert avant d’accuser le tunnel, le firmware ou les clés.
Les poignées de main récentes sont une bonne nouvelle et une affirmation bien plus modeste que la phrase qu’on voudrait écrire. Les pairs ont échangé des messages de poignée de main authentifiés. Un paquet applicatif doit encore atteindre sa destination interne et revenir.
Cet écart entre un plan de contrôle sain et un plan de données silencieux est tout le sujet ici. Deux relevés des mêmes compteurs vous disent de quel côté vous vous trouvez.
Une poignée de main prouve les clés, pas la livraison
La poignée de main WireGuard est un accord de clés avec authentification. Elle aboutit dès que les pairs peuvent s’atteindre et disposent de clés valides. Le routage, la politique du pare-feu et la destination elle-même sont des questions que la poignée de main ne pose jamais.
Un tunnel peut donc être parfaitement établi alors que chaque paquet à l’intérieur est abandonné. Un paquet interne mal routé et une réponse qui prend un autre chemin se ressemblent vus du client.
Une seule adresse interne suffit à tout tester
Choisissez une destination et tenez-vous-y. L’adresse de tunnel du pair lui-même est le cas le plus simple, et un hôte derrière le pair ajoute exactement un saut. Alterner entre les deux sans noter le changement produit des résultats que personne ne peut comparer.
Regardez ensuite la route que choisit le client. Une route locale plus spécifique peut envoyer le paquet ailleurs avant même que WireGuard soit consulté, ce qui arrive chaque fois que le réseau local domestique recoupe la plage distante.
ip route get 10.30.8.10
ip -4 addr show wg0
ip route show table all | grep -w wg0
Une adresse qui se résout vers l’interface physique a déjà répondu à la question. Le tunnel n’abandonne rien. Le paquet n’y est jamais entré.
Les compteurs sont des preuves, pas un verdict
wg show indique les octets envoyés et reçus par pair, et les deux nombres évoluent indépendamment. Faites un relevé, effectuez une requête autorisée, puis faites un autre relevé dans la même minute.
wg show wg0 transfer
wg show wg0 latest-handshakes
ping -c 4 10.30.8.10
wg show wg0 transfer
Un envoi qui monte avec une réception plate est la signature d’une requête sans réponse. Cela ne dit pas si la requête a été filtrée, si la destination était hors service ou si la réponse est partie par une autre route. Ce sont trois enquêtes qui partagent un symptôme. Séparez-les avant de changer la moindre configuration.
Un nombre fixe d’octets n’est pas non plus un seuil de réussite. Les valeurs des compteurs suivent le trafic, et traiter un seul nombre comme une preuve de bonne santé produit des absurdités pleines d’assurance.
Le pair vérifie lui-même le paquet de retour
Le pair distant n’accepte un paquet interne que si la source tombe dans son allowedips. Une route présente sur l’émetteur ne suffit pas. Une entrée de source absente chez le récepteur abandonne le trafic de retour en silence.
Les pare-feu de l’hôte se trouvent derrière cette vérification. Une règle de transfert qui autorise l’interface du tunnel mais pas le sous-réseau interne accepte la poignée de main et rejette le paquet. Vu du client, cela ressemble exactement à un pair mort. Un hôte à deux interfaces peut aussi répondre depuis la mauvaise source, et le pair écarte alors la réponse qu’il n’attendait pas.
Gardez l’expérience honnête
Tester un profil d’accès distant depuis le même réseau domestique qu’il est censé atteindre exerce un chemin différent de celui prévu. Passez au réseau externe et notez son préfixe local, afin que les deux exécutions puissent être comparées.
Un petit échange réussi n’exclut pas non plus tous les problèmes de chemin. Les paquets plus gros peuvent échouer là où les petits passent, et un filtre qui correspond à la taille ou au protocole peut se comporter autrement sous charge.
Gardez la poignée de main comme l’étape dont on sait qu’elle fonctionne et avancez à partir de là. La prochaine preuve utile est l’endroit où une requête interne s’arrête, pas un nouveau jeu de clés et un autre tour de suppositions.