Le tunnel tient, la route a disparu : séparer deux pannes VPN

Un hôte devient injoignable alors que l’interface du tunnel se déclare toujours établie, et les deux observations ne se contredisent pas. Quelque chose a retiré le chemin qu’utilisait le trafic : un voisin a retiré son préfixe, une route statique suivie a été supprimée, ou une autre route est devenue préférable. L’association de sécurité peut rester parfaitement saine dans les trois cas. Séparer les événements consiste à demander quelle couche a changé en premier, et non si le VPN a échoué.

Trois étapes qui ressemblent à un seul événement

Une décision de routage comporte trois étapes. Le préfixe est reçu, sélectionné comme le meilleur et installé dans la table de transfert. Chaque étape peut échouer seule, et la panne est identique vue de l’application. Un préfixe appris mais qui a perdu la sélection est indissociable de celui qui n’est jamais arrivé lorsque la seule preuve examinée est la table de transfert.

C’est pourquoi la première question est quelle étape a cédé, et non quel protocole est en cause. La réponse détermine à qui appartient l’incident et quel outil la vérification suivante utilisera.

Lisez d’abord la route installée

Demandez au noyau où va réellement le trafic vers la destination défaillante. ip route get affiche le prochain saut, l’interface et l’adresse source que le noyau utiliserait, et il répond pour une destination et non pour la table entière. Si la réponse nomme le tunnel, la table de transfert croit encore que le chemin existe et le problème se situe au-dessus.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Une réponse « unreachable » signifie qu’aucune route n’est installée, ce qui oriente vers un retrait ou une installation manquante. Une réponse qui nomme une interface physique signifie que le trafic a quitté le tunnel sans que personne ne l’ait décidé, et la vérification suivante est la préférence qui a gagné. Une réponse qui nomme le tunnel alors que les paquets disparaissent encore oriente plus loin sur le chemin, vers le filtrage ou vers le côté distant.

Regardez ensuite la vision du protocole lui-même

Un démon de routage tient plus d’une table, et la comparaison intéressante est entre elles. Pour BGP, l’état de la session voisine, l’annonce reçue et la route installée sont trois preuves distinctes. Un préfixe peut rester dans la table reçue et n’atteindre jamais le noyau parce qu’une route de plus courte distance administrative l’emporte. Vérifiez les trois avant de conclure que l’autre côté a cessé d’annoncer.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

Le résumé indique si la session est établie, la vue par préfixe indique si le préfixe a été accepté, et la recherche dans le noyau indique s’il a été installé. Les lire dans cet ordre évite de confondre un clignotement de session avec un retrait, et un retrait avec un rejet par politique.

Quand les horloges ne concordent pas

Placez le journal du tunnel, le journal de routage et la première défaillance applicative sur une même chronologie en utilisant leurs vrais fuseaux horaires. Si la perte du voisin arrive en premier, le tunnel a entraîné la route avec lui. Si le retrait arrive en premier, le routage a changé et le tunnel a réagi ensuite. Ce sont des incidents différents avec des propriétaires différents, et l’ordre est toute la trouvaille.

Une minute de dérive d’horloge suffit à inverser cette conclusion, alors confirmez le fuseau horaire et le décalage avant de faire confiance à la séquence. Les appareils qui journalisent en heure locale sans décalage sont la source habituelle d’une chronologie assurée mais fausse.

Récupération sans boucle

Après un retrait, deux chemins peuvent être éligibles : celui que le protocole sélectionne et celui que vous fixez à la main. Seul le premier est une décision que le réseau continue de prendre pour vous, c’est pourquoi une route manuelle est un expédient et non un plan de récupération. Une annonce alternative ne préserve pas non plus l’état du pare-feu ni du NAT pour une session déjà établie, si bien que de nouveaux flux peuvent fonctionner tandis que l’original reste cassé. Confirmez quelle sauvegarde doit devenir active et si le site distant acceptera un chemin de retour par elle.

N’installez pas de dérogation statique permanente avant de comprendre pourquoi le retrait a eu lieu. Ce raccourci peut épingler le trafic sur un chemin défaillant ou contourner silencieusement une politique de routage délibérée, et il enterre la cause d’origine sous une nouvelle configuration. Retestez l’application une fois la route restaurée, et confirmez que le préfixe choisi dispose d’un chemin de données fonctionnel et pas seulement d’une entrée dans une table.