Automatiser les réinitialisations de tunnel ASA : trois portes avant d'autoriser

Considérez une réinitialisation automatique de tunnel comme une action de rétablissement avec un rayon d'impact, et non comme une saute d'humeur planifiée. La décision devant vous est plus étroite que ne le suggère l'outillage : quelle panne la justifie, quel pair elle peut toucher et ce qui l'arrête. Trompez-vous sur ces trois points et vous avez construit une machine à effacer des preuves. J'ai vu l'une d'elles se déclencher toutes les quinze minutes contre un pair sain pendant la majeure partie d'une semaine, et personne ne l'a remarqué parce que le tunnel revenait à chaque fois.

Première porte : prouvez que la panne est dans le tunnel

Corrélez un état frais avant d'autoriser quoi que ce soit. show crypto ikev2 sa detailed vous dit si l'association IKEv2 existe et jusqu'où la négociation est allée, et show vpn-sessiondb detail l2l donne la vue de session qui correspond au même pair. Ensuite show crypto ipsec sa peer 203.0.113.10 montre les SA enfants, les compteurs encaps et decaps et les sélecteurs utilisés. Un compteur encaps qui monte avec un compteur decaps plat est un problème très différent de l'absence totale d'association.

Vérifiez ensuite ce qu'une reconstruction ne peut pas réparer : une route de retour manquante, une MTU qui engloutit les gros paquets, une politique qui refuse le port après le déchiffrement, ou un routage asymétrique qui renvoie les réponses autour de l'équipement. Effacer des SA contre l'un de ces cas produit un bref clignotement vert et le même ticket demain. Chacun ressemble à un tunnel mort côté application, c'est pourquoi les compteurs comptent plus que l'alerte.

Prenez un instantané avant l'action. Notez le pair, les identifiants d'association, les compteurs au moment du déclencheur et les preuves qui l'ont déclenché. Une réinitialisation qui devance l'instantané détruit les données les plus utiles de l'incident.

Deuxième porte : limitez la portée au pair, jamais au monde

Sur la CLI de l'ASA, clear crypto ikev2 sa peer 203.0.113.10 et clear crypto ipsec sa peer 203.0.113.10 sont des opérations ciblées. Les mêmes commandes sans argument de pair effacent toutes les associations du contexte, ce qui en fait une variante d'orthographe et une panne d'effet. La référence des commandes d'effacement de Cisco sépare ces formes de la variante purement statistique, qui remet les compteurs à zéro sans rien réparer. En mode multi-contexte, la commande n'agit que sur le contexte courant, l'automatisation doit donc aussi savoir dans quel contexte elle se trouve.

Validez le pair avant que la commande ne soit construite. Une variable vide ou non résolue doit faire échouer la tâche bruyamment plutôt que de s'effondrer en un effacement total, et ce contrôle appartient à du code qu'un relecteur peut lire.

Dessinez le rayon d'impact honnêtement. Un pair peut porter plusieurs réseaux protégés, des milliers de sessions et un second tunnel pour la gestion, donc un effacement limité au pair reste un événement multi-clients sur un concentrateur. Exécutez l'action depuis un chemin de gestion qui ne dépend pas du tunnel réinitialisé. Sinon l'automatisation ne peut pas vérifier son propre résultat, et l'étape suivante est un humain qui se rend sur site.

Troisième porte : tentatives, refroidissement, succès défini

Donnez à la tâche un verrou par pair, une période de refroidissement et une limite d'essais stricte comptée à partir d'observations fraîches. Sans le verrou, deux moniteurs qui se déclenchent au même instant effacent le même pair pendant que la renégociation est en cours, et chacun conclut que l'autre a échoué.

Le succès signifie que l'association est revenue et que la charge autorisée passe, non que la commande est revenue sans erreur. Sondez avec le même contrôle qui a détecté la panne, puis confirmez que les compteurs des SA enfants bougent dans les deux sens. Une commande qui sort à zéro alors que le tunnel reste tombé est une défaillance de supervision déguisée en rétablissement.

Gardez l'inconnu séparé de l'échec. Si la télémétrie est périmée ou si le chemin de gestion est injoignable, l'état honnête est inconnu, et un budget de tentatives ne doit pas y lire une autorisation de retirer.

Quand le premier rétablissement approuvé ne restaure pas le service, escaladez avec l'instantané au lieu de boucler. Les réinitialisations planifiées sont la pire version du schéma, car elles masquent un défaut de renégociation de clés, de route ou de politique tout en coupant des sessions saines sur un minuteur.

Propriété, un interrupteur et une répétition

Nommez un propriétaire, documentez comment désactiver l'applet ou la planification en une étape, et fixez une date de revue. Une automatisation sans chemin de désactivation devient une infrastructure permanente le jour où son auteur change d'équipe.

Répétez-la en laboratoire ou dans une fenêtre de maintenance avec la sélection de pair volontairement cassée, pour découvrir si la tâche échoue en sécurité. Répétez ensuite le chemin de succès, car une tâche qui ne tourne que lorsque quelque chose va mal ne vous apprend rien sur son comportement normal.