Quand les routes du tunneling divisé se chevauchent : quel préfixe l’emporte

Deux profils de tunneling divisé, deux préfixes privés et un hôte que les deux revendiquent. Le symptôme est rarement une panne nette : un service fonctionne le lundi, expire après la reconnexion du second client, et refonctionne après un redémarrage. L’ordre dans lequel vous avez connecté les clients ne décide pas du résultat, pas plus que l’ordre des lignes dans l’interface du client. Exécutez ces vérifications dans l’ordre et arrêtez-vous à la première qui ne tient pas, car les suivantes n’ont de sens que si les précédentes sont vraies.

1. Notez la destination et la source

Partez de l’adresse exacte vers laquelle va la requête qui échoue, pas du nom d’hôte et pas du nom de l’application. Résolvez le nom une fois, notez chaque réponse et choisissez celle que le flux en échec utilise réellement. Notez ensuite l’adresse locale du même flux, car l’adresse source peut changer quelle règle de politique correspond et donc quelle table est consultée.

Une requête vers l’un de plusieurs enregistrements A peut échouer alors qu’une adresse sœur réussit, ce qui ressemble à un tunnel instable et correspond en réalité à deux chemins différents. Si la destination est un nom avec plusieurs réponses, testez chaque réponse séparément avant de changer quoi que ce soit.

2. Demandez au noyau quelle route il a choisie

Ne lisez pas la table de routage et n’en déduisez pas la réponse. Posez la même question que la pile, avec la même adresse source : ip route get 10.20.4.10 from 10.8.0.2 sous Linux, ou Find-NetRoute -RemoteIPAddress 10.20.4.10 dans PowerShell. La sortie nomme la route qui serait réellement utilisée, et ce n’est souvent pas celle que vous attendiez en lisant la table.

Parmi les routes qui correspondent, le préfixe le plus spécifique gagne normalement : un /24 bat un /16 pour une adresse située dans les deux. Entre des correspondances de même longueur, la métrique la plus basse gagne, et une route installée sur un lien hors service est ignorée. Deux tunnels qui annoncent le même /24 avec la même métrique forment un autre cas : le noyau conserve les deux routes et choisit entre elles, si bien que le résultat peut alterner au lieu de suivre l’ordre dans lequel les clients se sont connectés. C’est exactement la situation qui produit le schéma lundi ça marche, mardi ça échoue, et se reconnecter dans un autre ordre ne le change pas.

3. Vérifiez si une règle de politique a redirigé la recherche

Avant que la table de routage ne soit consultée, le noyau parcourt ses règles de politique. Une règle peut envoyer le trafic d’une source, d’un utilisateur ou d’une marque de pare-feu donnés vers une table entièrement différente, si bien que le préfixe gagnant de la table principale peut n’être jamais consulté pour ce flux. ip rule show les liste dans l’ordre d’évaluation, et ip route show table 100 montre ce que contient réellement la table sélectionnée.

Deux pièges se cachent ici. Une règle qui pointe vers une table vide produit une recherche qui retombe sur la règle suivante, si bien que la règle semble ne rien faire. L’autre est le numéro de priorité lui-même : les règles se lisent par ordre croissant, et les valeurs intégrées sont 0 local, 32766 main et 32767 default. Une règle dont le numéro est inférieur à 32767 est consultée avant la règle par défaut qui capte tout. Une règle dont le numéro est supérieur à 32767 se trouve derrière elle et n’est atteinte que si aucune table antérieure ne répond, ce qu’une route par défaut normale dans main empêche, si bien qu’en pratique elle n’est jamais atteinte et ne fait rien en silence tout en paraissant installée. Si le client a écrit une règle et une route, vérifiez les deux, et vérifiez-les de nouveau après une reconnexion, car un profil réécrit peut ajouter une seconde règle avec une priorité différente.

4. Distinguez une égalité de routage d’un plan d’adressage dupliqué

Parfois le préfixe n’est pas du tout le problème. Deux sites qui utilisent tous deux 192.168.1.0/24 signifient que la même adresse identifie deux hôtes différents, et aucune route ne peut les distinguer. Une route d’hôte vers l’une des deux réponses ne fonctionne que jusqu’à ce que l’autre site réponde pour le même nom, et l’exception devient alors silencieusement le défaut.

L’indice est que l’adresse de destination est identique sur les deux chemins et que seul le propriétaire prévu diffère. C’est une décision de plan d’adressage, pas un réglage de routage : renumérotez un côté, placez un côté derrière une passerelle qui traduit, ou atteignez le second site via un proxy qui résout ses propres noms. Abaisser une route par défaut ou empiler des exceptions d’hôte ne fait que déplacer la collision ailleurs.

5. Confirmez que le résolveur est d’accord avec la route

Un nom qui se résout vers la mauvaise adresse privée produit tous les symptômes d’un conflit de routage et aucune de ses causes. Comparez la réponse que l’hôte reçoit avec l’adresse que la destination utilise réellement, et vérifiez quel résolveur a répondu. Si le tunnel pousse un résolveur, le client devrait l’installer pour les flux qui utilisent le tunnel ; sinon, l’hôte continue d’interroger le résolveur local, qui peut répondre depuis un domaine de recherche ou un enregistrement en cache.

Interrogez le résolveur directement et notez le serveur qui a répondu. Une réponse en cache avec un TTL court peut aussi expliquer pourquoi la première requête après une reconnexion se comporte différemment de la cinquième.

6. Reconnectez, inspectez l’état appliqué, puis testez les deux flux

Après une correction, reconnectez et inspectez ce que le client a réellement installé au lieu de faire confiance à l’éditeur de profils. Relisez les règles, les tables et la réponse de ip route get qui en résulte. Un second client peut réinstaller sa propre route à la connexion et recréer le conflit, ce qui explique pourquoi la vérification de l’état doit avoir lieu après la connexion du dernier client, et non avant.

Testez deux flux, pas un : la requête qui échouait et une ressource censée utiliser l’autre tunnel. Déplacer tout le trafic privé sur une seule connexion fera passer le premier test tout en cassant le second, et seul un test par paire le détecte. Notez chaque exception que vous conservez, avec la destination et la raison, afin que la personne suivante puisse distinguer une route d’hôte délibérée d’une route résiduelle.