Migrer un sous-réseau vers un nouveau tunnel VPN sans coupure

Montez le nouveau tunnel, déplacez un sous-réseau, et ce sous-réseau échoue désormais par intermittence alors que tout le reste fonctionne parfaitement. Les VPN à moitié migrés échouent exactement ainsi, parce que le tunnel n'a jamais été la partie difficile. Le chemin comprend aussi quelle route gagne, quels sélecteurs correspondent, ce que les règles d'accès autorisent, comment les réponses reviennent et toute traduction que l'ancienne conception appliquait. Déplacez le tunnel seul et vous n'avez rien déplacé de tout cela.

Le tunnel est la moitié facile du chemin

Les pannes intermittentes après une migration partielle signifient généralement que deux chemins sont tous deux plausibles. Certains flux prennent le nouveau tunnel, d'autres gardent l'ancien, et un équipement à état voit alors une réponse arriver par un chemin que la requête n'a jamais emprunté. Deux chemins ne sont pas automatiquement plus sûrs qu'un seul ; ce sont deux choses qui peuvent être en désaccord. Regardez les rapports d'oscillation plutôt que les compteurs du tunnel, car les compteurs sembleront sains tout du long.

La première question utile n'est pas quel tunnel est le meilleur. C'est quels flux choisissent quel chemin aujourd'hui, et si la requête et la réponse obtiennent la même réponse.

Construisez la destination avant de la préférer

Confirmez que les pairs sont compatibles et que le nouveau tunnel porte la plage d'adresses voulue. Ajoutez le transfert et les autorisations de service nécessaires tant qu'il est encore le chemin non préféré, afin que la bascule elle-même ne change que la sélection et rien d'autre.

Demandez au site distant comment il renverra le trafic. Si les réponses sortent encore par l'ancien tunnel, une nouvelle route locale produit de l'asymétrie ou échoue sur un filtre qui garde l'état. La traduction relève de la conception pour la même raison : une adresse source modifiée change aussi le chemin de retour.

Basculez de façon étroite, et sachez revenir

Nommez le sous-réseau exact et le mécanisme pris en charge par la plateforme qui préfère sa nouvelle route ou son sélecteur. Les définitions fondées sur des politiques ne se comportent pas toujours comme des métriques de route, alors lisez les règles de politiques qui se chevauchent de votre implémentation avant de supposer que la correspondance la plus précise l'emporte.

Déplacez un sous-réseau, pas un site. Gardez l'accès d'administration sur un chemin que vous ne touchez pas, et écrivez le retour arrière avant d'appliquer quoi que ce soit : quelle route ou politique revient, qui le fait, et comment ils restent connectés pendant ce temps.

Asymétrie et état périmé

Les pare-feu et les équipements NAT se souviennent de l'interface qu'un flux a utilisée. Quand la requête et la réponse prennent des tunnels différents, l'équipement peut rejeter la réponse alors même que chaque chemin fonctionne seul. Testez avec un flux que vous ouvrez après le changement, car une session établie peut continuer d'emprunter l'ancien chemin pendant des heures.

Si l'adresse source observée a bougé, trouvez chaque politique qui nomme l'ancienne. Une migration qui change la source en silence casse des règles que personne n'avait classées comme faisant partie de la conception VPN.

Prouvez les deux réponses, puis retirez l'ancienne politique

Depuis un hôte ordinaire du sous-réseau migré, atteignez le service prévu et vérifiez la source observée et l'interface de réponse. Testez ensuite un réseau censé rester sur l'ancien tunnel, car une migration n'est terminée que lorsque les deux réponses sont justes. Le second test est celui que les gens sautent, et c'est celui qui attrape un sélecteur plus large que voulu.

Retirez la politique obsolète seulement quand aucun sous-réseau restant n'en dépend, et consignez la route finale avec son propriétaire dans l'inventaire des sélecteurs. Terminer, ce n'est pas que le nouveau tunnel annonce être monté ; c'est que chaque réseau suive le chemin prévu.