La route de secours VPN flottante ne prend pas le relais : liste de vérification du basculement

Votre route VPN flottante est configurée, la distance du secours est supérieure à celle de la route principale, et pourtant rien ne bouge jamais. Ou bien elle bascule, puis revient quelques minutes plus tard alors que le lien sans fil est toujours coupé. Dans les deux cas, autre chose que la panne qui vous intéresse décide de l'éligibilité de la route.

Effectuez ces contrôles dans l'ordre. Chacun a une condition d'arrêt, et un contrôle échoué ne peut pas être sauvé par les suivants. Les exemples utilisent la syntaxe RouterOS parce que la distance, l'accessibilité de la passerelle et le saut suivant récursif y sont tous visibles dans la configuration, mais l'ordre s'applique à tout routeur doté de routes statiques suivies.

Nommez la panne que le secours doit couvrir

« La route principale est en panne » recouvre quatre observations différentes. Une radio qui perd son pair, une interface qui perd sa porteuse, une passerelle distante qui cesse de répondre et une application qui cesse de fonctionner se voient toutes différemment depuis la place du routeur. Notez laquelle le dimensionnement vise avant que quiconque change une valeur de distance.

Vérifiez ensuite l'indépendance. Si le transport externe du VPN passe par le même chemin sans fil, ou par un lien d'accès qui partage le même amont, le secours n'est pas un second domaine de panne et sera hors service exactement quand vous en aurez besoin. Tirez le câble principal sur le papier : si le transport du tunnel lui-même meurt avec, la route flottante ne couvre que les erreurs de configuration, pas les coupures.

Cessez de demander à la distance de détecter quoi que ce soit

Une distance plus élevée rend une route moins préférée. C'est tout le travail. Tant que la route statique principale reste éligible, la route flottante reste inactive, et c'est un comportement correct, pas un bogue. La panne ne devient visible que lorsque la route principale est retirée ou marquée injoignable.

Pour les routes statiques, cela exige un traqueur explicite :

/ip route
add dst-address=10.20.0.0/24 gateway=192.0.2.1 distance=1 check-gateway=ping
add dst-address=10.20.0.0/24 gateway=wg-backup distance=10

Lisez ce que cela teste : le saut suivant, pas la destination. Une radio qui répond encore de son côté local alors que le transfert au-delà est cassé maintient la route principale active. C'est le cas silencieux, et la distance plus un contrôle de passerelle ne l'attraperont pas. Si ce cas compte, la détection doit venir de quelque chose qui observe le côté distant : une adjacence de protocole de routage, ou une sonde dont vous avez défini vous-même le chemin et la règle de résultat.

Tracez où vont les paquets de la sonde elle-même

Une sonde de santé a elle aussi une route. Une fois que le trafic de données passe sur le VPN, une sonde non contrainte vers la même adresse distante peut la suivre, réussir et être lue comme la preuve que la route principale est revenue. Le trafic retourne sur un chemin cassé et le cycle se répète.

Épinglez la sonde sur le chemin qu'elle est censée juger. Dans RouterOS, la méthode habituelle est une route d'hôte vers la cible de supervision via la passerelle principale, avec une portée assez petite pour qu'aucune autre route ne puisse la résoudre, ce que construit l'exemple de basculement récursif du manuel RouterOS. Confirmez-le sur la table vivante avec le secours actif, pas à partir du commentaire de configuration :

/ip route print detail where dst-address=203.0.113.10
# gateway should still be the primary next hop

Définissez ce que signifie le résultat d'une sonde avant d'ajouter des cibles

Une cible qui rejette ICMP ou passe en maintenance ressemble exactement à une panne de chemin, et trois cibles sans règle ne vous donnent que trois avis. Décidez d'abord la règle, puis mettez-la en œuvre : par exemple, la route principale compte comme hors service quand deux cibles sur trois échouent pendant deux intervalles consécutifs, consigné dans le manuel d'exploitation où la personne suivante le trouvera.

Réglez les seuils de panne et de rétablissement pour qu'un paquet perdu ne déplace pas le site. L'hystérésis coûte un peu de temps de détection et rachète de la stabilité. Choisissez l'intervalle d'après la durée tolerable d'une coupure, pas d'après la vitesse à laquelle la sonde peut tourner, et gardez le retour plus lent que le basculement pour que la route principale doive faire ses preuves avant de récupérer le trafic.

Vérifiez le chemin de retour et l'histoire des sessions

Un basculement qui ne fonctionne qu'en sortie est un demi-dimensionnement. Le site distant a besoin d'une route de retour vers votre plage source via le VPN, sinon le trafic de retour arrive d'une adresse inattendue et heurte un état de pare-feu qui ne correspond plus. Les sessions existantes casseront même lorsque les nouvelles connexions fonctionnent, alors mettez-le dans les critères d'acceptation au lieu de promettre la survie du transfert.

Gardez l'accès de gestion hors du chemin testé. Si votre seule entrée passe par la route principale, un test de basculement vous enferme dehors de l'équipement qui se comporte mal.

Exécutez la séquence d'acceptation

Trois tests couvrent l'essentiel : perte physique de la route principale, panne de transfert silencieuse avec l'interface toujours active, et rétablissement de la route principale. Pour chacun, enregistrez la source et le saut suivant de la sonde, la route de destination active et un échange applicatif autorisé frais dans les deux sens.

Le cas silencieux est celui qui sépare les dimensionnements. Si le secours ne prend pas le relais là, vous avez construit un moniteur de lien plutôt qu'un moniteur de chemin. Décidez si c'est acceptable et écrivez la limitation là où l'ingénieur d'astreinte la lira. Un second tunnel connecté n'est pas, en soi, une politique de secours aboutie.