Changer de fournisseur sans renuméroter les adresses VPN du site

Une succursale change de fournisseur d'accès et le serveur de fichiers garde son adresse. Ce résultat est normal dans un VPN de site routé et surprenant pour qui suppose que l'adresse du point de terminaison du tunnel est celle de l'application. Les deux vivent dans des couches différentes de la conception, et une seule a bougé. Les traiter comme une seule, c'est ainsi qu'une migration de fournisseur devient un projet de renumérotation.

Deux plans d'adressage qui bougent indépendamment

Le plan intérieur décrit les adresses privées qu'utilisent les applications : le serveur de la succursale en 10.55.8.20, le préfixe du siège qui route vers lui et la route de retour. Le plan extérieur décrit comment deux passerelles se joignent : adresses de pair, ports d'écoute et le chemin à travers internet.

Un changement de fournisseur touche le plan extérieur. Il n'exige pas, à lui seul, de modifier le plan intérieur.

Garder les deux inventaires séparés est la raison pratique de faire tourner une superposition même quand l'application chiffre déjà son propre trafic. La superposition vous donne une topologie intérieure stable qui survit aux changements extérieurs. L'application garde son adresse, ses règles de pare-feu et ses enregistrements DNS. Seules les entrées de transport changent, et c'est une revue bien plus petite.

Le tunnel extérieur porte la conversation intérieure

Dans un tunnel de passerelle à passerelle, l'en-tête IP extérieur adresse les deux passerelles. L'en-tête intérieur nomme toujours les points de terminaison réels de l'application. La description passerelle à passerelle du RFC 7296 traite cela comme un routage ordinaire qui livre le trafic via les points de terminaison du tunnel.

C'est pourquoi le serveur de la succursale peut conserver 10.55.8.20 pendant que l'adresse publique de la passerelle change. Le paquet intérieur ne contient pas du tout l'adresse du fournisseur.

La séparation est une propriété de conception, pas une garantie automatique. Si le lien de remplacement ne peut pas établir le tunnel pris en charge, ou si les routes intérieures ne sont pas réinstallées, l'application perd son chemin même si son adresse n'a pas changé.

Le déménagement de fournisseur a encore une liste de contrôle

La liste extérieure comporte cinq entrées : l'adresse du pair ou le nom maintenu, l'écouteur et tout filtrage en amont, la traduction sur le chemin, l'identité attendue du pair et les réglages autorisés de l'autre passerelle. Chacune peut échouer seule. Gardez un chemin de reprise distinct pendant que vous changez le lien qui porte l'administration. Couper l'accès distant pendant une bascule de lien est une panne que vous avez provoquée vous-même.

Ensuite, vérifiez le préfixe de la succursale, la route dans les deux sens, la politique de protection et un flux applicatif réel. Un tunnel fraîchement authentifié ne corrige pas une route qui pointe vers l'ancien sous-réseau privé.

Le chevauchement d'adresses avec un autre site connecté est un problème de planification distinct. Le changement de fournisseur ne le crée pas, mais une migration est généralement le moment où il apparaît.

Ce qui ne survit pas : source publique et sessions

Une adresse de serveur privée stable n'est pas une source publique stable. Si la navigation sort directement par le nouveau fournisseur, les sites voient la nouvelle adresse tournée vers le fournisseur.

Garder cette adresse stable exige une conception de sortie délibérée, avec sa propre disponibilité et sa propre politique. Elle ne vient pas gratuitement avec le tunnel.

Les sessions établies ne survivent pas non plus à un changement de chemin. Le tunnel peut se rétablir en quelques secondes et tout de même casser des connexions de longue durée ancrées à l'ancien chemin. Planifiez la bascule sur une fenêtre où les reconnexions sont acceptables. N'affirmez pas qu'une migration sera invisible tant que les clients concernés et leurs délais d'attente n'ont pas été testés.

Vérifiez le déménagement avec quatre contrôles

Après le changement, vérifiez quatre choses dans l'ordre : le tunnel est établi avec le pair prévu, la route intérieure vers le préfixe de la succursale existe, la politique autorise le flux applicatif et l'application répond. Chacune a sa propre commande.

Sur une passerelle Linux, ces trois couvrent le milieu de cette liste :

ip route get 10.55.8.20
ip xfrm policy list
curl -sS -o /dev/null -w "%{http_code}" --max-time 8 http://10.55.8.20/health

Gardez les adresses de transport dans un inventaire et les adresses applicatives dans un autre. Ne mettez à jour que les entrées qui ont réellement bougé. Renuméroter des dépendances internes parce que l'adresse extérieure du tunnel a changé est un travail évitable.