Routage récursif : quand le tunnel capture ses propres paquets

Le tunnel monte, le journal montre une poignée de main terminée, et une seconde plus tard la même session meurt et se reconnecte en boucle. Ce schéma a une cause précise : la route vers le serveur pointe désormais à l’intérieur du tunnel, donc les paquets qui portent le tunnel sont envoyés par le tunnel. Rien n’a changé du côté de l’authentification, ce qui explique pourquoi ressaisir les identifiants ne change rien. Comparez le chemin extérieur avant et après le changement de route et la récursion devient visible.

Vérifiez d’abord le chemin extérieur

Il y a deux paquets en jeu, pas un. Le paquet intérieur appartient à l’application et devrait être chiffré, tandis que le paquet extérieur est adressé au serveur et doit l’atteindre par un chemin qui ne dépend pas du tunnel.

ip route get 198.51.100.7
ip rule show
ip route show table all | grep -F 198.51.100.7
wg show wg0 endpoints

Demandez au noyau la route vers l’adresse du serveur une fois le tunnel monté, puis de nouveau après le changement de la route par défaut. Un saut suivant qui atterrit sur l’appareil du tunnel est la récursion, et elle est visible sans aucune capture de paquets. Un rattachement à une interface, des marques ou un espace de noms réseau peuvent rendre une simple interrogation incomplète, alors utilisez le contexte que le client emploie lui-même. Quand la réponse semble correcte mais que la session boucle encore, lisez les règles de la politique de routage plutôt que la seule table principale.

Pourquoi la session survit un instant

La poignée de main se termine avant l’installation de la nouvelle route, donc les premières secondes semblent saines. Dès que le client ajoute la route par défaut, le paquet extérieur suivant la suit dans l’interface par laquelle ce paquet extérieur doit passer. Le serveur ne voit rien, le client retransmet, et la tentative soit expire, soit tue la session et repart de zéro.

Cet ordre explique pourquoi un tunnel peut fonctionner sur un portable et échouer sur un routeur, et pourquoi la panne commence souvent au démarrage du trafic et non à la connexion. Il explique aussi la boucle : chaque redémarrage rétablit la session avant que la route ne le rende impossible.

Trouvez à qui appartient l’exception du point de terminaison

Les clients pris en charge aménagent leur propre exception : une route d’hôte vers le serveur via la passerelle d’origine, ou une marque qui maintient la prise extérieure hors du tunnel. La question est de savoir si autre chose l’a supprimée ou contournée.

Pour IPsec basé sur les routes, examinez les sélecteurs de politique qui décident quels paquets entrent dans le tunnel et confirmez que l’adresse du pair en est exclue. Pour WireGuard, la marque de pare-feu de l’interface et ses règles de politique maintiennent les paquets de transport hors du tunnel, si bien qu’une route par défaut ajoutée à la main peut briser cet agencement. Un second profil VPN ou un script d’administration qui réécrit la route par défaut est un coupable courant. Les règles de contournement larges ajoutées une par une sont le résultat habituel, et elles transforment un bogue de routage en une table que personne ne peut maintenir.

Revérifiez après un changement de réseau

Une route d’hôte via une passerelle Wi-Fi est correcte jusqu’à ce que la machine passe sur un autre réseau. Le même symptôme revient alors sans aucun changement de configuration.

Notez l’adresse du point de terminaison, la route avant et après la connexion, et l’interface utilisée par chacune. Ces trois faits séparent généralement un bogue du client d’un contournement, et ils survivent à la personne qui les a recueillis.

Reconnectez-vous sur le nouveau réseau et répétez la lecture. Si l’exception manque de nouveau, le correctif appartient au profil qui la possède, pas à une commande ponctuelle tapée pendant une panne.