El reset de par en el ASA borra las SA de IPsec, no el estado de IKE ni las sesiones
Un clear limitado al par solo derriba la ruta de datos de IPsec. Vea qué sobrevive, por qué el túnel se reconstruye en segundos y qué capa conviene limpiar en su lugar.
El túnel cae para una sola aplicación, alguien ejecuta un clear de IPsec limitado al par y el ticket se cierra porque el comando fue aceptado. Nada en esa secuencia demuestra que la avería se haya reparado. En un ASA la palabra reset cubre tres ámbitos separados, y el clear limitado al par toca exactamente uno de ellos, por eso el mismo túnel suele estar de nuevo arriba antes de que el operador termine de leer la salida.
Tres ámbitos se esconden tras una palabra
Un par de SA de IPsec es la propia ruta de datos, una asociación por sentido, con números de secuencia y contadores. Una SA de IKE es el canal de negociación que produjo esas asociaciones y que aún mantiene unida la relación con el par. Una sesión VPN es el registro de la base de datos de sesiones para un usuario, un par sitio a sitio o una conexión sin cliente.
| 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 |
Los ámbitos son lo bastante independientes como para que limpiar uno deje funcionando los demás, y esa independencia genera la mayor parte de la confusión. Limpie las SA de IPsec mientras la SA de IKE está sana y el tráfico provoca asociaciones nuevas en segundos, así que el túnel parece haberse curado solo. El desajuste de propuesta, el hueco de ruta o el fallo de autenticación siguen ahí.
Si la avería está en la negociación, un clear de IPsec no cambia nada observable.
Lea el estado mientras aún existe
Anote la dirección del par, la versión de IKE en uso, las redes protegidas y los contadores direccionales antes de tocar nada. Las vistas admitidas varían según la versión, pero las formas son estables: show crypto ipsec sa peer, show crypto ikev2 sa detailed o el equivalente para IKEv1, y show vpn-sessiondb para la capa de sesiones.
Escriba la marca de tiempo y el fallo exacto que ve el usuario junto a esa salida. Un par suele llevar varias redes protegidas, así que el radio de un clear limitado al par es cada selector de ese par, no la única aplicación del ticket. Un reset sin imagen previa no se puede diagnosticar después, porque el clear borra justo los contadores con los que habría comparado.
Capture primero las pruebas. El clear las elimina, y una captura tomada después le dice qué se reconstruyó, no qué estaba roto.
Qué hace realmente el clear limitado al par
La referencia de comandos clear de Cisco documenta la forma de IPsec limitada al par. Con una dirección de documentación sustituida, queda así:
clear crypto ipsec sa peer 198.51.100.42Ese comando derriba las asociaciones de IPsec que coinciden con el par. No elimina la SA de IKE, no borra configuración y no reinicia la base de datos de sesiones. Ejecútelo desde una ruta de gestión que no dependa del túnel que está cambiando, porque una sesión SSH transportada dentro de ese túnel morirá con él y puede que no vuelva por sí sola. Todo lo demás del dispositivo sigue funcionando, y justamente por eso el comando parece inofensivo.
Cuando la búsqueda del objetivo es incierta, no recurra a un clear sin calificar. La forma más amplia alcanza a cada par del dispositivo y la caída que provoque será mayor que aquella por la que le llamaron.
Verifique la capa que quería reparar
Después del clear, confirme que las asociaciones han vuelto con contadores nuevos en lugar de suponer que el reset funcionó porque la lista de pares se repobló. Luego pruebe la aplicación que nombraba el ticket, porque un ping correcto no dice nada sobre un permiso de servicio ni sobre una sesión caducada.
Si las asociaciones se reconstruyen y la aplicación sigue fallando, los candidatos restantes son la capa de IKE y la capa de sesiones. Elija la que aún pueda inspeccionar. Use la operación dirigida para la versión que realmente se ejecuta, ya sea un clear de IKEv2, un clear de IKEv1 o un clear de la base de datos de sesiones limitado al tipo de sesión correcto. Borrar y recrear configuración persistente de crypto-map para forzar una reconstrucción es una conjetura con una reversión más larga.
Escale con ambas imágenes, antes y después, en lugar de limpiar otra vez.
Cuando el reset alarga la caída
Los clear repetidos esconden las averías que un reset no puede arreglar: una ruta que falta, un selector que ya no coincide con la subred nueva, una clave precompartida cambiada en un lado o una renovación de clave que falla una y otra vez con una propuesta que el par no aceptará. Cada clear interrumpe tráfico sano en cada selector de ese par mientras la causa real queda intacta. Así es como una investigación de cinco minutos se convierte en una ventana de cambio.
Un reset acotado sigue siendo útil. La versión útil es dirigida, registrada y seguida de una inspección de la capa que debía reparar.
Orden de trabajo: capture par, versión, selectores y contadores; confirme a qué ámbito pertenece la avería; ejecute el clear más estrecho que encaje; verifique las asociaciones y la aplicación; escale con pruebas si la capa se recupera pero el síntoma no.