WireGuard envoie des données mais ne reçoit rien en retour : de quel côté ?

Des compteurs d’émission qui montent alors que le compteur de réception reste à zéro décrivent une direction, pas un diagnostic. La même lecture apparaît lorsque le pair n’a jamais terminé un handshake, lorsque la destination a choisi le mauvais pair, lorsque le côté distant n’a pas de route de retour et lorsqu’un filtre jette la réponse sur le chemin du retour. Chacun de ces cas se répare à un endroit différent.

La comparaison qui raccourcit le travail oppose une requête qui n’a jamais quitté le tunnel à une réponse qui n’est jamais revenue. Une capture sur la bonne interface tranche entre les deux.

Les compteurs décrivent un volume, pas la direction de la panne

Les compteurs de WireGuard enregistrent ce que l’interface a remis au pair et ce qu’elle a reçu de lui. Ils ne disent pas quelle destination, quel pair ou quelle moitié d’un échange a échoué. Le trafic de fond rend les totaux encore moins parlants, car certains octets peuvent être des messages de maintien ou des flux sans rapport. Lisez-les comme l’indication que l’interface est active, puis cessez de les traiter comme une preuve.

Le premier fait utile est de savoir si un handshake est à jour. Sans lui, rien n’a été chiffré pour ce pair et le compteur de réception n’a aucune raison de bouger.

Choix du pair ou chemin de la réponse : deux explications

La première explication est que le paquet n’a jamais atteint le pair prévu, parce que la route pointait ailleurs ou parce que les préfixes autorisés du pair ne couvraient pas la destination. La seconde est que le paquet est arrivé et que la réponse n’a pas pu revenir, ce qui est un problème de routage à l’extrémité distante. Le tableau les sépare selon ce que vous observeriez à chaque point.

Lisez le tableau depuis le haut. Un handshake absent vous envoie vers les clés, les points de terminaison et le chemin extérieur, car il n’y a encore rien d’autre à examiner. Un handshake à jour avec la requête visible sur le serveur déplace le problème vers la direction du retour, où la table de routage de la destination décide. Une requête qui n’apparaît jamais sur le serveur est un problème de sélection, et les préfixes autorisés sur les deux pairs sont la première chose à comparer.

Deux de ces quatre lignes se réparent sur le client et deux sur le serveur. Savoir dans quelle paire vous vous trouvez représente l’essentiel du travail.

Où disparaissent les réponses

Une réponse quitte la destination, atteint l’interface de tunnel du serveur et est chiffrée pour le pair dont les adresses autorisées correspondent à l’adresse interne du client. Si cette correspondance échoue, la réponse est écartée en silence, ce qui ressemble exactement à une panne réseau vue du client. Si la réponse est chiffrée et que le filtre propre au client la rejette, le symptôme est de nouveau identique. Les deux cas exigent la capture plutôt que le compteur.

La forme la plus forte de cette erreur est un serveur qui transfère des paquets pour le client mais n’a aucune route de retour vers la plage interne du client. Il accepte la requête, envoie la réponse vers sa passerelle par défaut, et le tunnel ne la voit jamais. Une règle de traduction large ajoutée sur le serveur masque cette panne au lieu de réparer la route.

Testez une seule destination de bout en bout

Choisissez une seule destination dans la plage du pair et testez-la pendant qu’un handshake est manifestement à jour. Les commandes ci-dessous lisent l’état du pair, la route choisie et les deux côtés de l’échange. Lancez la capture sur l’interface que les paquets chiffrés utilisent réellement.

wg show wg0 latest-handshakes
wg show wg0 transfer
ip route get 10.60.9.5
sudo tcpdump -ni wg0 host 10.60.9.5

Une capture montrant la requête sur l’interface de tunnel sans rien qui revienne est une réponse côté serveur, et la table de routage de la destination est le prochain endroit à regarder. Si rien n’apparaît du tout, le paquet a pris un autre chemin, donc la route locale est suspecte. Un échange visible dans les deux captures sans progression dans l’application déplace la question vers la taille des paquets ou vers un filtre que les statistiques de l’interface ne montrent jamais. Gardez une destination et un client dans le test, car une seconde variable transforme la preuve en impression.

Si les noms échouent alors qu’une adresse autorisée fonctionne, la réponse se trouve dans le DNS et non dans le tunnel. Si seuls les gros transferts bloquent, examinez la taille des paquets séparément.