Automatizar os reinicios de túnel ASA: tres portas antes de permitilo

Pense nun reinicio automático de túnel como unha acción de recuperación cun raio de impacto, non como un cambio de humor programado. A decisión que ten diante é máis estreita do que suxire a ferramenta: que falla o xustifica, que par pode tocar e que o detén. Se se equivoca nesas tres, construíu unha máquina para borrar probas. Vino un destes dispararse cada quince minutos contra un par san durante boa parte dunha semana, e ninguén o notou porque o túnel volvía cada vez.

Porta unha: demostre que a falla está dentro do túnel

Correlacione estado fresco antes de autorizar nada. show crypto ikev2 sa detailed dille se existe a asociación IKEv2 e ata onde chegou a negociación, e show vpn-sessiondb detail l2l dá a vista de sesión que corresponde ao mesmo par. Despois show crypto ipsec sa peer 203.0.113.10 mostra as SA fillas, os contadores de encaps e decaps e os selectores en uso. Un contador de encaps que sobe cun contador de decaps plano é un problema moi distinto da ausencia total de asociación.

A continuación, revise o que unha reconstrución non pode reparar: unha ruta de retorno ausente, unha MTU que traga os paquetes grandes, unha política que denega o porto tras o descifrado, ou un encamiñamento asimétrico que envía as respostas arredor do aparello. Borrar SA contra calquera deses produce un breve destello verde e o mesmo ticket mañá. Cada un parece un túnel morto desde o lado da aplicación, por iso os contadores importan máis que a alerta.

Tome unha instantánea antes da acción. Registre o par, os identificadores da asociación, os contadores no momento do disparo e a evidencia que o activou. Un reinicio que se adianta á instantánea destrúe os datos máis útiles que tiña o incidente.

Porta dúas: limite o alcance ao par, nunca ao mundo

Na CLI do ASA, clear crypto ikev2 sa peer 203.0.113.10 e clear crypto ipsec sa peer 203.0.113.10 son operacións dirixidas. Os mesmos comandos sen argumento de par borran todas as asociacións do contexto, o que os converte nunha variación de escritura e nunha caída de efecto. A referencia de ordes de borrado de Cisco separa esas formas da variante só de estatísticas, que reinicia contadores e non repara nada. En modo multicontexto o comando actúa só sobre o contexto actual, así que a automatización tamén debe saber en que contexto está.

Valide o par antes de construír o comando. Unha variable baleira ou sen resolver debe facer fallar o traballo ruidosamente en lugar de colapsar nun borrado total, e esa comprobación pertence a código que un revisor poida ler.

Debuxe o raio de impacto con honestidade. Un par pode levar varias redes protexidas, miles de sesións e un segundo túnel para xestión, así que un borrado limitado ao par segue sendo un evento multicliente nun concentrador. Execute a acción desde unha ruta de xestión que non dependa do túnel que se reinicia. Se non, a automatización non pode verificar o seu propio resultado, e o seguinte paso é unha persoa conducindo ata o sitio.

Porta tres: reintentos, arrefriamento, éxito definido

Dea ao traballo un bloqueo por par, un período de arrefriamento e un límite duro de intentos contado a partir de observacións frescas. Sen o bloqueo, dous monitores que saltan ao mesmo tempo borran o mesmo par mentres a renegociación está en curso, e cada un conclúe que o outro fallou.

Éxito significa que a asociación volveu e que a carga permitida pasa, non que o comando regresou sen erro. Sondee coa mesma comprobación que detectou a falla e logo confirme que os contadores das SA fillas se moven en ambos os sentidos. Un comando que sae con cero mentres o túnel segue caído é unha falla de monitorización disfrazada de recuperación.

Manteña o descoñecido separado do fallido. Se a telemetría está obsoleta ou a ruta de xestión non é alcanzable, o estado honesto é descoñecido, e un orzamento de reintentos non debe ler iso como permiso para volver disparar.

Cando a primeira recuperación aprobada non restaura o servizo, escale coa instantánea en lugar de facer bucles. Os reinicios programados son a peor versión do patrón, porque ocultan un defecto de renegociación de chaves, ruta ou política mentres cortan sesións san cun temporizador.

Propiedade, un interruptor e un ensaio

Nomee un propietario, documente como desactivar o applet ou a programación nun só paso e fixe unha data de revisión. Unha automatización sen ruta de desactivación convértese en infraestrutura permanente o día que o seu autor cambia de equipo.

Ensáea nun laboratorio ou nunha ventá de mantemento coa selección de par rota a propósito, para descubrir se o traballo falla pechado. Despois ensaie a ruta de éxito, porque un traballo que só se executa cando algo vai mal non lle ensina nada sobre o seu comportamento normal.