Ce qu'une migration VPN doit préserver d'un circuit privé

Les circuits privés sont faciles à décrire et difficiles à remplacer, car le contrat couvrait plus qu'un câble. Il portait une remise, un plan d'adressage, une attente de latence et un accord de support, et le tunnel qui le remplace hérite des quatre, que quelqu'un les ait écrits ou non. Les migrations échouent quand l'équipe copie la configuration de routage et qualifie le reste de problème d'exploitation. Partez des exigences, puis prouvez chacune sur le nouveau chemin avant que l'ancien soit résilié.

Transformez le circuit en liste de propriétés

La première question est ce que l'ancien service a réellement remis: un lien routé avec un petit sous-réseau, ou un segment de couche 2 partagé entre sites. Cette distinction décide si un tunnel IP peut le reproduire, car un tunnel transporte des paquets entre deux adresses et ne transporte ni découverte par diffusion ni EtherTypes arbitraires. Un circuit qui se présentait comme un port de commutateur est une migration différente d'un circuit qui présentait un /30.

Notez les préfixes de site, les adresses de passerelle, les applications qui intègrent des adresses dans leur propre configuration et les préfixes qui se chevauchent ailleurs dans le parc. Un plan d'adressage qui survit à la migration est un résultat de conception, pas une hypothèse. Ces quatre listes deviennent aussi les critères d'acceptation plus tard, alors gardez-les là où les testeurs peuvent les lire.

Acheminez le nouveau chemin dans les deux sens

Un tunnel qui monte n'est que la moitié d'un chemin. Le côté distant a besoin d'une route de retour vers chaque préfixe local, et le côté local doit préférer le tunnel pour ces préfixes sans voler le trafic qui doit toujours sortir par internet. Le transfert asymétrique est le symptôme habituel d'une de ces moitiés réussie. Inspectez la table du côté distant aussi soigneusement que la vôtre, car la route de retour est celle que personne n'a configurée.

ip route get 10.20.0.10

Le routage par politique rend la séparation explicite: marquez le trafic qui appartient à la paire de sites et donnez-lui une table dont la valeur par défaut est le tunnel. IPsec fournit l'association protégée et la politique qui décide de ce qui y entre, mais pas les routes autour, ainsi que le décrit l'architecture IPsec dans son ensemble. Quand la marque correspond trop largement, le trafic web ordinaire du site entre aussi dans le tunnel et sort par la mauvaise sortie.

Basculez avec un retour arrière que vous avez déjà testé

Deux chemins actifs avec des propriétaires différents invitent au transfert asymétrique, alors montez le nouveau dans une fenêtre définie et déplacez les préfixes dans un ordre annoncé. Gardez l'ancien circuit configuré et maintenez un chemin de gestion hors bande qui ne dépend d'aucun des deux tunnels. Déplacez un préfixe à la fois là où les applications le permettent, et surveillez la table des sessions entre les déplacements.

Décidez à l'avance quelles preuves autorisent la bascule et quelle condition déclenche le retour arrière. Un retour arrière qui exige de réparer le nouveau VPN à travers la connexion défaillante n'est pas un retour arrière. Énoncez le déclencheur comme une condition mesurable et non comme une sensation dans la salle.

Acceptez avec le trafic que le circuit portait réellement

Ping prouve l'accessibilité et peu de chose de plus. Testez la résolution de noms, les sessions de longue durée, les flux refusés et les tailles de paquet que l'ancien chemin traitait sans fragmentation. La MTU est l'endroit où les tunnels diffèrent le plus souvent d'un circuit, car l'encapsulation consomme des octets que l'application supposait disponibles. Mesurez la charge utile la plus grande qui passe sans fragmentation dans les deux sens, pas seulement vers le serveur.

ping -M do -s 1400 -c 3 10.20.0.10

Si une charge de 1400 octets passe et que 1472 ne passe pas, le maximum du chemin est plus petit que ne l'attendent les applications et vous avez trouvé une régression réelle, pas cosmétique. Comparez ce résultat aux exigences écrites à la première étape et retirez le circuit seulement quand les propriétaires de ces applications acceptent la mesure. Cette signature est ce qui transforme un test réussi en migration acceptée.