Automatizar los reinicios de túnel ASA: tres puertas antes de permitirlo

Piense en un reinicio automático de túnel como una acción de recuperación con radio de impacto, no como un cambio de humor programado. La decisión que tiene delante es más estrecha de lo que sugiere la herramienta: qué fallo lo justifica, qué par puede tocar y qué lo detiene. Si se equivoca en esas tres, ha construido una máquina para borrar pruebas. He visto uno de estos dispararse cada quince minutos contra un par sano durante buena parte de una semana, y nadie lo notó porque el túnel volvía cada vez.

Puerta uno: demuestre que el fallo está dentro del túnel

Correlacione estado fresco antes de autorizar nada. show crypto ikev2 sa detailed le dice si existe la asociación IKEv2 y hasta dónde llegó la negociación, y show vpn-sessiondb detail l2l le da la vista de sesión que corresponde al mismo par. Después show crypto ipsec sa peer 203.0.113.10 muestra las SA hijas, los contadores de encaps y decaps y los selectores en uso. Un contador de encaps que sube con un contador de decaps plano es un problema muy distinto de la ausencia total de asociación.

A continuación, revise lo que una reconstrucción no puede reparar: una ruta de retorno ausente, una MTU que se traga los paquetes grandes, una política que deniega el puerto tras el descifrado, o un enrutamiento asimétrico que envía las respuestas rodeando el dispositivo. Borrar SA contra cualquiera de esos produce un breve destello verde y el mismo ticket mañana. Cada uno parece un túnel muerto desde el lado de la aplicación, por eso los contadores importan más que la alerta.

Tome una instantánea antes de la acción. Registre el par, los identificadores de la asociación, los contadores en el momento del disparo y la evidencia que lo activó. Un reinicio que se adelanta a la instantánea destruye los datos más útiles que tenía el incidente.

Puerta dos: limite el alcance al par, nunca al mundo

En la CLI del ASA, clear crypto ikev2 sa peer 203.0.113.10 y clear crypto ipsec sa peer 203.0.113.10 son operaciones dirigidas. Los mismos comandos sin argumento de par borran todas las asociaciones del contexto, lo que los convierte en una variación de escritura y en una caída de efecto. La referencia de comandos de borrado de Cisco separa esas formas de la variante solo de estadísticas, que reinicia contadores y no repara nada. En modo multicontexto el comando actúa solo sobre el contexto actual, así que la automatización también debe saber en qué contexto está.

Valide el par antes de construir el comando. Una variable vacía o sin resolver debe hacer fallar el trabajo ruidosamente en lugar de colapsar en un borrado total, y esa comprobación pertenece a código que un revisor pueda leer.

Dibuje el radio de impacto con honestidad. Un par puede llevar varias redes protegidas, miles de sesiones y un segundo túnel para gestión, así que un borrado limitado al par sigue siendo un evento multicliente en un concentrador. Ejecute la acción desde una ruta de gestión que no dependa del túnel que se reinicia. De lo contrario, la automatización no puede verificar su propio resultado, y el siguiente paso es una persona conduciendo hasta el sitio.

Puerta tres: reintentos, enfriamiento, éxito definido

Dé al trabajo un bloqueo por par, un periodo de enfriamiento y un límite duro de intentos contado a partir de observaciones frescas. Sin el bloqueo, dos monitores que saltan al mismo tiempo borran el mismo par mientras la renegociación está en curso, y cada uno concluye que el otro falló.

Éxito significa que la asociación volvió y que la carga permitida pasa, no que el comando regresó sin error. Sondee con la misma comprobación que detectó el fallo y luego confirme que los contadores de las SA hijas se mueven en ambos sentidos. Un comando que sale con cero mientras el túnel sigue caído es un fallo de monitorización disfrazado de recuperación.

Mantenga lo desconocido separado de lo fallido. Si la telemetría está obsoleta o la ruta de gestión no es alcanzable, el estado honesto es desconocido, y un presupuesto de reintentos no debe leerlo como permiso para volver a disparar.

Cuando la primera recuperación aprobada no restaura el servicio, escale con la instantánea en lugar de repetir en bucle. Los reinicios programados son la peor versión del patrón, porque ocultan un defecto de renegociación de claves, ruta o política mientras cortan sesiones sanas con un temporizador.

Propiedad, un interruptor y un ensayo

Nombre un propietario, documente cómo desactivar el applet o la programación en un solo paso y fije una fecha de revisión. Una automatización sin ruta de desactivación se convierte en infraestructura permanente el día que su autor cambia de equipo.

Ensáyela en un laboratorio o en una ventana de mantenimiento con la selección de par rota a propósito, para descubrir si el trabajo falla cerrado. Después ensaye la ruta de éxito, porque un trabajo que solo se ejecuta cuando algo va mal no le enseña nada sobre su comportamiento normal.