Bascule VPN : quand le chemin de retour reste dans l’ancien tunnel

Le tunnel de secours monte, le tunnel principal tombe, et l’application expire encore. Sur les deux sites, l’état du tunnel semble sain, et c’est précisément ce qui trouble. Une bascule qui déplace les requêtes vers le secours mais laisse les réponses sur l’ancien chemin n’est pas une bascule. Le guide ci-dessous teste le chemin de retour, pas seulement la poignée de main.

Relevez d’abord les routes aux deux extrémités ; une vue d’un seul site ne peut pas montrer un chemin asymétrique. C’est aussi l’étape la plus souvent omise sous pression temporelle.

Relevez les routes des deux sites avant le test

Pour chaque préfixe protégé, écrivez la route principale, la route de secours et la préférence qui choisit entre elles. Incluez la passerelle LAN derrière chaque extrémité VPN, car l’extrémité est rarement le dernier saut.

Les métriques statiques, les routes suivies et le routage dynamique expriment l’éligibilité différemment. Sachez lequel votre conception utilise, et ce qu’il faut pour que l’alternative devienne active. Écrivez la condition à côté de la route, par exemple une métrique plus basse jusqu’à l’échec de la sonde.

Faites-le sur les deux sites. Un secours préféré d’un côté et ignoré de l’autre produit exactement l’asymétrie que vous cherchez à éviter.

Observez les requêtes et les réponses à chaque phase

Utilisez une application autorisée et inoffensive et observez trois phases : normale, panne du principal et rétablissement. À chaque phase, relevez quel tunnel porte la requête et lequel porte la réponse. Une adresse de pair joignable ne prouve pas que le chemin protégé de l’application fonctionne. Capturez sur les deux sites pour qu’un flux unidirectionnel soit visible.

Si les requêtes bougent et pas les réponses, vérifiez la route du site distant vers le préfixe client et sa préférence pour le secours. C’est une décision de routage, pas une panne de tunnel.

Rétablissez la condition d’origine après le test et confirmez que le principal est de nouveau préféré. Un principal rétabli qui n’est pas préféré est une conception de bascule inachevée.

Gérez l’état de session lorsque la passerelle change

Les pare-feu et le NAT peuvent conserver l’état de connexion sur une passerelle, et un changement de chemin vers une autre passerelle ne le transporte pas. Certaines applications se reconnectent seules ; d’autres échouent jusqu’au rétablissement de la session. Si le secours change la source publique ou l’adresse privée traduite, les règles d’accès distant peuvent aussi réagir. Documentez tout redémarrage de session attendu au lieu de promettre une bascule sans interruption.

Maintenez un adressage stable là où l’application l’exige. Une conception de bascule qui change l’adresse source à chaque session est un choix de conception, et il devrait être écrit. Ce choix détermine la part de l’interruption que les utilisateurs remarquent réellement.

Testez une application qui maintient une longue session, pas seulement une nouvelle requête.

Rétablissez le principal et vérifiez l’oscillation

Confirmez que les annonces de route ou les préférences se stabilisent sans osciller. Un principal qui oscille peut être plus perturbant qu’une panne nette, car chaque transition réinitialise l’état.

Gardez l’administration de la passerelle joignable par un chemin de récupération, afin que le test ne vous enferme pas dehors. Relevez les phases, les chemins observés et le temps de récupération ; ce relevé est ce qui rend la bascule suivante prévisible. Les notes de strongSwan sur le transfert sont utiles lorsque les extrémités sont des hôtes Linux.