Le reset de pair sur l’ASA efface les SA IPsec, pas l’état IKE ni les sessions
Un clear limité au pair ne démonte que le chemin de données IPsec. Voyez ce qui survit, pourquoi le tunnel se reconstruit en quelques secondes et quelle couche nettoyer à la place.
Le tunnel tombe pour une seule application, quelqu’un lance un clear IPsec limité au pair, et le ticket est fermé parce que la commande a été acceptée. Rien dans cette séquence ne montre que la panne a été réparée. Sur un ASA le mot reset couvre trois portées distinctes, et le clear limité au pair touche exactement l’une d’elles, ce qui explique pourquoi le même tunnel est souvent remonté avant que l’opérateur ait fini de lire la sortie.
Trois portées se cachent derrière un mot
Une paire de SA IPsec est le chemin de données lui-même, une association par sens, avec des numéros de séquence et des compteurs. Une SA IKE est le canal de négociation qui a produit ces associations et qui tient encore la relation avec le pair. Une session VPN est l’enregistrement de la base de sessions pour un utilisateur, un pair site à site ou une connexion sans client.
| Scope | What a clear removes | What usually survives |
|---|---|---|
| IPsec SA | Data-path associations for the matching peer or selector | IKE SA, session records, crypto-map or tunnel-group config |
| IKE SA | Negotiation channel and the IPsec children derived from it | Session records until they age out or are cleared |
| VPN session | Session-database entry for that user or peer type | Configuration, and any SA that is not tied to the session |
Les portées sont assez indépendantes pour que le nettoyage de l’une laisse les autres fonctionner, et cette indépendance produit l’essentiel de la confusion. Effacez les SA IPsec alors que la SA IKE est saine, et le trafic déclenche de nouvelles associations en quelques secondes, si bien que le tunnel semble s’être guéri tout seul. Le désaccord de proposition, le trou de route ou l’échec d’authentification sont toujours là.
Si la panne se situe au niveau de la négociation, un clear IPsec ne change rien d’observable.
Lisez l’état pendant qu’il existe encore
Notez l’adresse du pair, la version d’IKE utilisée, les réseaux protégés et les compteurs directionnels avant de toucher quoi que ce soit. Les vues prises en charge varient selon la version, mais les formes sont stables : show crypto ipsec sa peer, show crypto ikev2 sa detailed ou l’équivalent pour IKEv1, et show vpn-sessiondb pour la couche session.
Écrivez l’horodatage et la panne exacte visible par l’utilisateur à côté de cette sortie. Un pair porte souvent plusieurs réseaux protégés, donc le rayon d’action d’un clear limité au pair est chaque sélecteur de ce pair, pas l’unique application du ticket. Un reset sans image préalable ne peut pas être diagnostiqué après coup, car le clear supprime précisément les compteurs auxquels vous auriez comparé.
Capturez d’abord les preuves. Le clear les supprime, et une capture prise ensuite vous dit ce qui s’est reconstruit, pas ce qui était cassé.
Ce que fait réellement le clear limité au pair
La référence des commandes clear de Cisco documente la forme IPsec limitée au pair. Avec une adresse de documentation substituée, cela donne ceci :
clear crypto ipsec sa peer 198.51.100.42Cette commande démonte les associations IPsec correspondant au pair. Elle ne retire pas la SA IKE, n’efface pas la configuration et ne réinitialise pas la base des sessions. Lancez-la depuis un chemin de gestion qui ne dépend pas du tunnel que vous modifiez, car une session SSH transportée dans ce tunnel mourra avec lui et risque de ne pas revenir d’elle-même. Tout le reste de l’équipement continue de fonctionner, et c’est précisément pour cela que la commande semble inoffensive.
Lorsque la recherche de la cible est incertaine, ne cédez pas à un clear non qualifié. La forme plus large atteint chaque pair de l’équipement, et la panne que vous créez sera plus grande que celle pour laquelle on vous a appelé.
Vérifiez la couche que vous vouliez réparer
Après le clear, confirmez que les associations sont revenues avec des compteurs neufs au lieu de supposer que le reset a fonctionné parce que la liste des pairs s’est repeuplée. Testez ensuite l’application nommée dans le ticket, car un ping réussi ne dit rien d’une autorisation de service ou d’une session expirée.
Si les associations se reconstruisent et que l’application échoue encore, les candidats restants sont la couche IKE et la couche session. Choisissez celle dont vous pouvez encore inspecter l’état. Utilisez l’opération ciblée pour la version réellement en service, qu’il s’agisse d’un clear IKEv2, d’un clear IKEv1 ou d’un clear de la base des sessions limité au bon type de session. Supprimer puis recréer une configuration crypto-map persistante pour forcer une reconstruction relève du tâtonnement avec un retour arrière plus long.
Escaladez avec les deux images, avant et après, au lieu de nettoyer à nouveau.
Quand le reset allonge la panne
Les clear répétés masquent les pannes qu’un reset ne peut pas corriger : une route manquante, un sélecteur qui ne correspond plus au nouveau sous-réseau, une clé pré-partagée changée d’un côté, ou un renouvellement de clé qui échoue sans cesse sur une proposition que le pair n’acceptera pas. Chaque clear interrompt du trafic sain sur chaque sélecteur de ce pair pendant que la cause réelle reste intacte. Voilà comment une enquête de cinq minutes se transforme en fenêtre de changement.
Un reset borné reste utile. La version utile est ciblée, consignée et suivie d’une inspection de la couche qu’il était censé réparer.
Ordre du travail : relevez pair, version, sélecteurs et compteurs ; confirmez à quelle portée appartient la panne ; exécutez le clear le plus étroit qui corresponde ; vérifiez les associations et l’application ; escaladez avec des preuves si la couche se rétablit mais que le symptôme persiste.