Comment distinguer une boucle de routage d'une route qui clignote sur des sites VPN
Une boucle de routage et une route instable provoquent la même perte intermittente. Trois vérifications sur les passerelles les distinguent avant que vous ne changiez quoi que ce soit.
Deux sites, un tunnel et un préfixe distant qui répond un moment puis devient silencieux. Le réflexe est d'appeler cela une boucle de routage, et c'est parfois exactement ce que c'est. Mais une boucle et une route instable produisent la même plainte et exigent des réparations opposées : l'une est une décision de transfert qui ne se termine jamais, l'autre un préfixe qui ne cesse de quitter la table. Trois observations les séparent, et vous pouvez réunir les trois depuis la ligne de commande de la passerelle avant de toucher un filtre ou de redémarrer un tunnel.
Une boucle se décide saut par saut. Le site A choisit B comme saut suivant pour la destination, B choisit A pour la même destination, et le paquet expire sur le TTL après deux allers-retours. Un clignotement est décidé à la place par le protocole de routage : le préfixe est retiré, réinstallé ou remplacé par un saut suivant alternatif, si bien que certains paquets n'ont aucune route tandis que d'autres suivent une route parfaitement bonne.
Les trois vérifications qui tranchent la question
Vous n'avez pas besoin d'une capture de paquets pour prendre la première décision. Il vous faut l'état du préfixe aux deux extrémités, le saut suivant que chaque côté choisit et un nombre de sauts qui se répète ou non. Si le préfixe reste installé avec le même saut suivant alors que le trafic échoue, la boucle vit dans le chemin de transfert. Si le préfixe disparaît et revient, la panne est au-dessus du transfert et la réparation relève du protocole de routage, pas d'une route statique.
| Observation | Routing loop | Route flapping |
|---|---|---|
| Prefix in the table | Installed, same next hop throughout | Withdrawn and reinstalled, or next hop alternates |
| Hop count | Reaches zero at the same two gateways | Expires only while the prefix is missing |
| Failure shape | Consistent loss for that prefix from every source | Bursts, often after a link or peer event |
| Where the fix belongs | The site that owns the prefix, plus filters on the transit path | Advertisement, hold timers, or the flapping link |
Un avertissement avant de commencer. Si vous lisez ceci à travers le tunnel qui boucle, votre session meurt à l'instant où vous changez la route. Ouvrez une console ou un chemin d'administration qui ne dépend pas du préfixe que vous êtes sur le point de réparer.
Vérification un : le préfixe est-il stable ou agité
Demandez au noyau ce qu'il a installé, pas ce que promet le fichier de configuration. Sur une passerelle Linux, ip route get 10.20.30.40 exécute la même recherche que le chemin de transfert, y compris les tables de politiques, tandis que ip route show 10.20.30.0/24 montre l'entrée elle-même. ip monitor route diffuse chaque changement au moment où il survient, ce qui est le moyen le plus rapide de voir un préfixe arriver et partir.
Sur un routeur qui fait tourner FRR ou BIRD, la table de transfert n'est pas l'intéressante. show ip bgp 10.20.30.0/24 renvoie le chemin sélectionné et son temps de fonctionnement ; un temps de fonctionnement qui se réinitialise toutes les quelques minutes est un clignotement que vous pouvez nommer, pas une boucle. show ip bgp summary montre l'état des voisins et les comptes de préfixes, donc un pair qui tombe sans cesse retire la faute du chemin de transfert.
Notez la réponse avant de changer quoi que ce soit. Stable pendant dix minutes alors que les pings échouaient, et disparu quatre fois en dix minutes, mènent à des étapes suivantes différentes. Le second cas rend toute théorie de route statique sans objet.
Vérification deux : le saut suivant repointe-t-il vers le tunnel d'arrivée
Une boucle exige que deux passerelles se mettent d'accord. Sur le site qui reçoit le paquet, regardez la route que le paquet utilisera pour sortir : ip route get 10.20.30.40 from 10.10.5.20 avec la vraie adresse source, car une règle de politique peut répondre différemment de la table principale. Répétez ensuite la recherche sur le site qui l'a envoyé. Si chaque côté choisit l'autre comme saut suivant pour le même préfixe, la boucle est prouvée et aucune capture n'y ajoutera rien.
La cause est presque toujours une annonce qui n'aurait pas dû traverser le tunnel. Une route par défaut redistribuée dans le tunnel, un agrégat qui couvre le propre sous-réseau du site distant ou une route statique pointant vers le pair par précaution créent tous le même saut suivant mutuel. Le tunnel peut être pleinement établi et transporter malgré tout le trafic en cercle ; les notes de transfert de strongSwan décrivent le volet routage de cette exigence.
WireGuard mérite sa propre note, car il n'y a aucune annonce à blâmer. wg show liste les AllowedIPs de chaque pair, et le noyau n'accepte une destination pour un pair que si elle tombe dans cette plage. Une boucle ici est une plage d'AllowedIPs qui se chevauche ou une route statique qui repointe à travers l'interface, donc la réparation vit à ces deux endroits et nulle part ailleurs.
Vérification trois : lisez le nombre de sauts, pas les étoiles
traceroute -n -I 10.20.30.40 et mtr -n -r -c 20 10.20.30.40 montrent tous deux le chemin, et le mode ICMP survit souvent à un filtrage qui mange les sondes UDP. Une boucle ressemble à une courte séquence répétée des mêmes deux adresses de passerelle avec le TTL qui monte à chaque fois. Une chute ressemble à des étoiles après la dernière passerelle qui a répondu, et un seul saut silencieux ne prouve rien.
Quand le chemin est ambigu, lisez le TTL sur le fil. tcpdump -ni any -vv icmp sur les deux passerelles montre le TTL de chaque paquet et l'adresse source de chaque réponse de temps dépassé. Si un paquet atteint le site distant avec un TTL inférieur au nombre de sauts que le chemin peut contenir, quelque chose ajoute des sauts que traceroute ne vous montre pas, ce qui arrive quand le pare-feu d'un site répond aux sondes au nom d'un autre.
Réparez le propriétaire du préfixe, puis vérifiez les deux directions
Décidez quel site est à l'origine de la destination et quels chemins de transit sont autorisés, puis changez l'annonce ou la route statique chez ce propriétaire. Corriger le site récepteur est tentant et généralement faux : cela cache la boucle pour un préfixe et laisse la mauvaise annonce en place pour le suivant. Les étiquettes de route, les listes de distribution et les règles de split-horizon existent pour arrêter cela à la source, et elles coûtent moins cher qu'un filtre qui correspond à un seul préfixe.
Après le changement, vérifiez l'aller et le retour séparément, car une boucle peut être remplacée par un trou noir sans aucune amélioration visible du symptôme. Lancez ip route get depuis les deux extrémités, envoyez du trafic depuis un hôte qui n'est pas la passerelle, et laissez ip monitor route tourner au moins un temporisateur de maintien pour qu'un clignotement ne soit pas pris pour une réparation.
Avant de changer quoi que ce soit, confirmez ces cinq points : le préfixe est stable ou agité, le saut suivant aux deux extrémités pointe vers un tunnel, le nombre de sauts se répète ou non, un seul site possède le préfixe, et vous disposez d'un chemin d'administration qui survit au changement. Si l'un des cinq est inconnu, les quatre autres sont des suppositions.