Pourquoi les routes à coût égal rendent les pannes VPN difficiles à voir
Quand plusieurs tunnels partagent un même coût, chaque flux peut en emprunter un différent. Un ping réussi ne dit rien du chemin que votre application utilise réellement.
Un utilisateur signale que l’application interne fonctionne depuis une machine et échoue depuis une autre, alors que le ping lancé depuis la passerelle réussit dans les deux cas. Avec plusieurs tunnels à coût égal, ce n’est pas une contradiction. Chaque flux est placé sur son propre saut suivant, donc votre sonde et la session de l’utilisateur peuvent simplement emprunter des chemins différents. La démarche ci-dessous reproduit ce choix avant toute modification.
Un ping, plusieurs chemins possibles
Quand une route possède plus d’un saut suivant au même coût, le routeur doit en choisir un par paquet. La plupart des implémentations hachent des champs du paquet, généralement les adresses source et destination avec le protocole et les ports, pour que les réponses restent sur le même chemin. Des applications différentes, ou même des connexions différentes d’une même application, produisent des hachages différents.
C’est pourquoi un diagnostic depuis la passerelle prouve si peu. La sonde de la passerelle a ses propres adresses et ports, donc son propre hachage. Elle peut atterrir sur le tunnel sain pendant que l’utilisateur continue d’atterrir sur celui qui est cassé.
Comment la plateforme choisit un saut suivant
Reproduisez le choix au lieu de le deviner. Demandez au noyau quelle route il utiliserait pour la même source et la même destination que la session qui échoue. Cette recherche inclut des champs qu’une simple recherche de destination ignore. Lancez-la aussi depuis un client qui fonctionne et comparez les deux réponses :
ip route get 10.20.5.7 from 10.20.0.14Les versions récentes d’iproute2 acceptent aussi le protocole et le port de destination, ce qui compte quand le hachage les inclut. Comparez cette sortie à la même recherche depuis un client qui fonctionne, et la différence est la preuve qui vous manquait.
| Observation | Likely cause | First check |
|---|---|---|
| Ping works, application fails | A different flow hash selects another tunnel | Per-flow lookup from the client's address |
| Some users fail, others do not | One tunnel lacks a prefix or selector | Compare both tunnels' installed routes |
| Fails only at larger sizes | Tunnels have different effective MTU | Probe the same size over each path |
| Fails after a reconnect | Stateful asymmetry between paths | Session state on both gateways |
Suivez le flux qui échoue, pas la table de routage
La table de routage liste les deux tunnels et semble correcte par définition. La question est ce que chaque tunnel fait du paquet une fois choisi. Vérifiez que les deux portent les mêmes préfixes protégés, la même autorisation de transfert et un chemin de retour qui atteint le même client.
Faites attention aux équipements à état au milieu. Si une requête sort par un tunnel et que la réponse revient par l’autre, un pare-feu ou un NAT qui n’a jamais vu le flux d’origine la rejettera. Les deux tunnels transfèrent correctement le trafic, et la connexion échoue quand même.
Vérifiez aussi la MTU par chemin. Un chemin avec une encapsulation supplémentaire réduit la taille utile, et un transfert qui réussit sur un tunnel se bloque sur l’autre exactement à la taille où le plus petit casse.
Comparez un chemin à la fois
Là où la conception permet une maintenance, retirez un tunnel du service et répétez la tâche de l’utilisateur. Si la panne disparaît, le problème appartient au chemin retiré, et l’étape suivante consiste à comparer sa configuration à celle de son voisin plutôt qu’à réexaminer la table de routage.
Comparez l’application réelle, pas des pings répétés. Notez si la panne suit un saut suivant particulier, une taille de paquet ou une transition après reconnexion, car ces trois motifs pointent vers des réparations différentes.
Enfin, notez pourquoi les chemins sont considérés comme équivalents et comment une panne est censée en retirer un du service. Le multipath n’est sûr que lorsque les chemins sont réellement interchangeables, et c’est une affirmation de conception qu’il vaut mieux vérifier que supposer.