Un pair WireGuard injoignable alors qu’un autre fonctionne : liste de vérification

Un pair WireGuard transporte du trafic et un second effectue la poignée de main mais n’atteint jamais rien derrière le tunnel. Le pair qui fonctionne vous dit que l’interface, le port UDP et la clé du serveur sont probablement corrects. Il ne vous dit rien des AllowedIPs du second pair, de son adresse source interne ni des règles de transfert entre les deux. Parcourez la liste dans l’ordre et arrêtez-vous à la première étape dont la condition échoue.

Étape 1 : Notez le chemin que le paquet devrait suivre

Deux clients sur le même concentrateur ne se joignent pas automatiquement. Dans une conception en concentrateur et rayons, le serveur reçoit le paquet sur wg0 et doit le retransférer hors de wg0 vers l’autre pair, ce qui exige le transfert IP et une règle de transfert. Dans une conception directe de pair à pair, chaque côté a besoin de l’extrémité de l’autre et de l’adresse de son tunnel dans les AllowedIPs. Décidez quelle conception vous dépannez avant de lire la moindre configuration.

Le chemin attendu vous indique aussi où regarder. Si le paquet doit traverser le concentrateur, le saut qui échoue est soit les AllowedIPs de l’émetteur, soit le transfert du concentrateur, soit les AllowedIPs du récepteur. S’il doit passer en direct, le concentrateur n’a pas d’importance et ce sont les champs d’extrémité des deux pairs qui comptent.

Étape 2 : Comparez les AllowedIPs des deux côtés, pas d’un seul

WireGuard utilise les AllowedIPs à la fois comme table de routage et comme liste de contrôle d’accès. À l’émission, l’adresse de destination est recherchée dans les AllowedIPs du pair pour choisir le tunnel ; à la réception, l’adresse source interne doit tomber dans les AllowedIPs du pair émetteur, sinon le paquet est rejeté. Une plage manquante d’un côté ou de l’autre produit le même symptôme : le transport fonctionne, la charge utile disparaît.

Lisez l’état actif plutôt que le fichier, car un rechargement a pu échouer en silence : sudo wg show wg0 allowed-ips. Sur le serveur, l’entrée du pair défaillant doit inclure son adresse de tunnel, par exemple 10.90.0.3/32. Sur le client, l’entrée du pair serveur doit inclure la destination que vous testez, qu’il s’agisse de l’adresse de tunnel du concentrateur ou du sous-réseau distant. Les plages qui se chevauchent rendent la recherche ambiguë et peuvent sélectionner un pair que vous ne vouliez pas, gardez-les donc distinctes.

Étape 3 : Vérifiez l’adresse source interne

Un client qui route 10.90.0.3 via wg0 mais émet ses paquets depuis son adresse Wi-Fi sera rejeté par le récepteur, car la source ne correspond pas aux AllowedIPs du pair. Vérifiez ce que le noyau sélectionne réellement avec ip route get 10.90.0.3 from 10.90.0.2, et vérifiez l’adresse attribuée à l’interface du tunnel avec ip -brief addr show wg0.

Sur l’hôte Linux récepteur, le filtrage du chemin inverse est une seconde porte. Un rp_filter strict sur l’interface qui possède la route de retour peut rejeter le trafic du tunnel dont le chemin de retour ne correspond pas à l’interface par laquelle il est arrivé. Vérifiez la valeur effective avant de le désactiver ; dans beaucoup de topologies, la correction consiste en une route, pas en un filtre assoupli.

Étape 4 : Examinez le transfert du concentrateur et le chemin de retour

Si le concentrateur doit transférer entre pairs, le noyau a besoin de net.ipv4.ip_forward=1, et le pare-feu doit accepter le flux transféré : entrée sur wg0, sortie sur wg0, de l’adresse de tunnel de l’émetteur vers celle du récepteur. Une défaillance courante est une règle d’entrée qui accepte UDP 51820 mais aucune règle de transfert], si bien que la poignée de main réussit et que la charge utile meurt. Listez les règles effectives avec sudo nft list ruleset ou l’équivalent de votre gestionnaire de pare-feu.

Vérifiez ensuite la réponse. L’hôte de destination doit avoir une route de retour vers l’émetteur, soit par le concentrateur, soit par sa propre passerelle. Si le concentrateur fait aussi du NAT sur le sous-réseau du tunnel, vérifiez que la traduction s’applique au flux transféré et que la réponse atteint le concentrateur avant l’expiration de l’état. Une défaillance unidirectionnelle qui ressemble à un problème de clé n’est souvent que cette route de retour.

Enfin, séparez la poignée de main des données. Un pair qui termine la poignée de main mais cale sur les transferts volumineux a généralement un problème de MTU ou de MSS sur ce chemin précis, pas un problème d’AllowedIPs. Testez d’abord avec un petit ping, puis avec un ping de taille maximale, et comparez les deux pairs.

Étape 5 : Changez une seule chose et gardez le pair qui fonctionne intact

Faites une seule modification sur le chemin défaillant et retestez les deux pairs. Remplacer les AllowedIPs de chaque pair par 0.0.0.0/0 est le moyen le plus rapide de casser le pair qui fonctionnait déjà, car cela change la décision de routage de tout le trafic sur cette interface. Modifiez cette seule entrée, rechargez et relisez l’état actif.

Notez quel chemin a réussi, lequel a échoué et la sortie exacte de la commande pour chacun. Cette comparaison vaut plus qu’un rapport général disant que le VPN est cassé, et c’est la première chose que la personne suivante demandera.