Choisir une source d’enregistrement stable pour les membres GET VPN

Quelqu’un pointe l’enregistrement du membre du groupe vers une adresse loopback et déclare l’instabilité de GET VPN résolue. Parfois c’est vrai. Souvent, la loopback n’est joignable que depuis la table de routage du membre lui-même et de nulle part ailleurs, si bien que l’enregistrement casse encore la fois suivante où l’uplink qui le portait vacille. L’adresse d’enregistrement est une identité du plan de contrôle, et elle n’aide que lorsqu’un chemin réel existe dans les deux sens. La choisir délibérément vaut la peine, et c’est un changement plus petit que ne le laisse croire la rumeur.

Ce que l’adresse d’enregistrement identifie

Dans un déploiement GDOI, le membre du groupe s’enregistre auprès du serveur de clés et reçoit de lui la politique de groupe. L’adresse que le serveur de clés enregistre est l’identité du membre pour cette conversation.

Cette identité couvre la conversation de contrôle : enregistrement, renouvellement des clés et téléchargement de la politique. Elle ne devient pas la source du trafic des clients, et elle ne change pas quelles interfaces protègent quels flux.

Garder les deux séparés est la première étape, car l’essentiel de la confusion autour de ce réglage vient de l’attente qu’un changement dans le plan de contrôle corrige un symptôme du plan de données.

Une loopback ne vaut que ce que vaut sa route

Une loopback donne au membre une adresse logique qui ne disparaît pas lorsqu’un uplink physique tombe. C’est un avantage réel sur un routeur qui dispose de plusieurs chemins vers le serveur de clés.

Mais ce n’est aussi qu’une adresse. Si le serveur de clés n’a pas de route de retour vers elle, l’enregistrement échoue exactement comme avant. Si la table de routage du membre n’atteint le serveur de clés que par un seul uplink, la loopback est stable et le chemin ne l’est pas.

Vérifiez la joignabilité dans les deux sens à travers chaque uplink que vous voulez voir survivre. Une loopback qui reste administrativement active ne prouve rien sur le transfert, et la panne apparaît comme un serveur de clés injoignable plutôt que comme un problème d’interface. Écrivez la vérification sous forme de commande par uplink, pas d’hypothèse. La prochaine fenêtre de changement partira alors de preuves et non d’un schéma.

Garder le contrôle et le trafic protégé séparés

Le guide de contournement GDOI de Cisco documente l’interface d’enregistrement et la relation entre l’enregistrement et le traitement du contournement. Lisez le comportement de la version que vous exécutez réellement au lieu de traiter une phrase comme une commande universelle.

Revoyez le filtrage et la traduction sur le chemin de contrôle, et confirmez que le trafic de gestion des clés n’est pas entraîné par accident dans une politique de protection qui dépend précisément de la politique de groupe qu’il cherche à récupérer. Cette dépendance circulaire est une façon classique de faire échouer un déploiement qui fonctionnait après un changement de politique.

La politique du plan de données est une conception distincte. Changer l’origine de l’enregistrement laisse les flux protégés, les sélecteurs et les règles de contournement exactement là où ils étaient.

Vérifier l’identité pendant la transition

Avant le changement, notez le groupe, l’adresse d’enregistrement retenue, la destination du serveur de clés, le contexte de routage et le chemin de contrôle autorisé. Après un changement d’uplink approuvé, inspectez de nouveau la vue des membres enregistrés du serveur de clés et l’état de contrôle du membre.

Ce que vous voulez voir, c’est le point de terminaison logique prévu toujours joignable et toujours représenté comme vous l’avez conçu. Ce que vous ne voulez pas, c’est un second enregistrement depuis une adresse non prévue, car c’est ainsi que les entrées de membre en double apparaissent.

Testez ensuite le trafic applicatif protégé à part. Un transfert peut réussir alors que le prochain renouvellement de clés n’a nulle part où aller, et un enregistrement réussi ne dit rien sur le fait qu’un flux donné soit correctement sélectionné et routé.

Ce qu’une source stable ne corrige pas

Elle ne supprime pas les entrées de membre en double créées par une mauvaise configuration antérieure. Elle ne répare pas un échec de renouvellement de clés dû à un écart de politique entre le membre et le serveur de clés. Elle ne survit pas à la panne d’un chemin physique qui a supprimé l’unique route vers le serveur de clés.

Ce qu’elle fait, c’est supprimer une variable : l’identité ne change plus quand une adresse d’uplink change. Cela vaut la peine, et c’est une ligne dans une conception et non la conception entière.

Ordre du travail : nommer le chemin de contrôle, choisir une adresse avec une route dans les deux sens, confirmer la vue du serveur de clés, puis tester le trafic protégé séparément. Si l’enregistrement échoue encore, la loopback n’a jamais été le problème.