Le pair WireGuard sort par le mauvais WAN : cinq vérifications dans l’ordre

Deux liens montants, une passerelle et un pair WireGuard dont le trafic ne cesse de réapparaître sur la ligne de secours. La poignée de main reste saine tout du long. C’est pourquoi le symptôme se lit facilement à tort comme une défaillance de WireGuard plutôt qu’un défaut de routage.

Effectuez les vérifications ci-dessous dans l’ordre. Chacune a une condition d’arrêt, et brûler les étapes produit généralement une réponse fausse et assurée.

Séparez la poignée de main du flux transféré

L’échange chiffré avec le pair dispose d’une route de point de terminaison vers l’adresse publique du serveur. Le trafic client transféré a une autre destination et peut être sélectionné par des marques ou des règles de politique. Ce sont deux décisions de routage qui partagent une interface. Traiter l’une comme une preuve sur l’autre est la première erreur.

Arrêtez-vous dès que vous vous surprenez à raisonner à partir de la poignée de main. Elle ne prouve que le chemin vers le point de terminaison.

Lisez la règle de politique, pas la table par défaut

Une table par défaut montre ce qui se passe quand aucune règle de politique ne correspond. Sur une passerelle qui route par source, marque ou destination, la règle décisive vit ailleurs. La table simple peut sembler parfaitement raisonnable alors que le vrai choix se fait au-dessus d’elle.

ip rule show
ip route show table main
ip -4 route get 203.0.113.9 from 10.30.8.2

Lisez les règles de politique et les tables vers lesquelles elles pointent. Confirmez ensuite quelle règle correspond à votre flux de test. Une règle qui référence une interface qui ne porte plus le lien montant prévu est une constatation, pas un détail. La recherche de route à la fin montre la réponse bien plus vite que lire une table et deviner.

Vérifiez la marque et la traduction ensemble

Le routage par politique repose sur une marque de paquet posée plus tôt dans la chaîne. Si la règle de marquage rate votre trafic, le flux retombe dans la table principale et sort par ce qui y est par défaut. Les paquets transférés sautent souvent des chaînes écrites pour le trafic généré localement.

nft list chain inet filter prerouting
conntrack -L -s 10.30.8.2 2>/dev/null | head
ip -s link show dev eth1

La traduction doit s’accorder avec le lien montant qui porte le flux. Une règle qui traduit vers l’adresse principale alors que le paquet sort par la ligne de secours produit des réponses adressées à une interface que le flux n’a jamais utilisée. Vérifiez la condition d’interface de la règle de traduction elle-même. Une règle inconditionnelle fonctionne jusqu’à ce que le second lien montant soit utilisé, puis échoue d’une manière qui paraît intermittente.

Regardez quelle interface porte la réponse

Capturez sur les deux liens montants pendant qu’une requête s’exécute. Notez quelle interface porte la requête et laquelle porte la réponse. Les chemins asymétriques sont bien plus faciles à voir qu’à prévoir.

Si la réponse arrive par le mauvais lien montant, le problème a quitté WireGuard pour le suivi des connexions ou la traduction. Aucun changement à la configuration du pair n’y remédiera.

Changez une seule chose avec un retour possible

Gardez un accès console ou hors bande avant de modifier des règles de politique sur une passerelle. Faites un seul changement, testez la même destination autorisée, puis reconnectez-vous et confirmez que la poignée de main utilise toujours le chemin de point de terminaison prévu. Ajoutez un test numérique sur la seconde famille d’adresses, car une politique limitée à v4 laisse la même erreur disponible.

Notez quel lien montant chaque flux a utilisé. Ce relevé transforme le prochain rapport en vérification de deux minutes au lieu d’un après-midi entier. les notes de WireGuard sur les espaces de noms et le routage décrivent comment séparer délibérément le chemin de point de terminaison du trafic tunnelisé, ce qui est généralement plus propre que de copier un contournement par route par défaut.