Automatizar reposições de túnel ASA: três portões antes de permitir

Encare uma reposição automática de túnel como uma ação de recuperação com raio de impacto, não como uma mudança de humor agendada. A decisão à sua frente é mais estreita do que as ferramentas sugerem: que falha a justifica, que par pode tocar e o que a faz parar. Erre nesses três e terá construído uma máquina para apagar provas. Vi uma delas disparar a cada quinze minutos contra um par saudável durante boa parte de uma semana, e ninguém notou porque o túnel voltava sempre.

Portão um: prove que a falha está dentro do túnel

Correlacione estado fresco antes de autorizar qualquer coisa. show crypto ikev2 sa detailed diz se a associação IKEv2 existe e até onde chegou a negociação, e show vpn-sessiondb detail l2l dá a vista de sessão que corresponde ao mesmo par. Depois show crypto ipsec sa peer 203.0.113.10 mostra as SA filhas, os contadores de encaps e decaps e os seletores em uso. Um contador de encaps a subir com um contador de decaps plano é um problema muito diferente da ausência total de associação.

A seguir, verifique o que uma reconstrução não consegue reparar: uma rota de retorno em falta, uma MTU que engole pacotes grandes, uma política que nega a porta após a desencriptação, ou um encaminhamento assimétrico que envia as respostas à volta do equipamento. Apagar SA contra qualquer um destes produz um breve lampejo verde e o mesmo bilhete amanhã. Cada um parece um túnel morto do lado da aplicação, por isso os contadores contam mais do que o alerta.

Tire uma captura de estado antes da ação. Registe o par, os identificadores da associação, os contadores no momento do disparo e as provas que o desencadearam. Uma reposição que se adiante à captura destrói os dados mais úteis que o incidente tinha.

Portão dois: limite o âmbito ao par, nunca ao mundo

Na CLI da ASA, clear crypto ikev2 sa peer 203.0.113.10 e clear crypto ipsec sa peer 203.0.113.10 são operações dirigidas. Os mesmos comandos sem argumento de par apagam todas as associações no contexto, o que os torna uma variação de escrita e uma queda de efeito. A referência dos comandos de limpeza da Cisco separa essas formas da variante apenas de estatísticas, que repõe contadores e não repara nada. Em modo multicontexto o comando atua apenas no contexto atual, pelo que a automatização também tem de saber em que contexto está.

Valide o par antes de o comando ser construído. Uma variável vazia ou não resolvida tem de falhar o trabalho ruidosamente em vez de colapsar num apagamento total, e essa verificação pertence a código que um revisor possa ler.

Desenhe o raio de impacto com honestidade. Um par pode transportar várias redes protegidas, milhares de sessões e um segundo túnel para gestão, pelo que um apagamento limitado ao par continua a ser um evento multicliente num concentrador. Execute a ação a partir de um caminho de gestão que não dependa do túnel que está a ser reposto. Caso contrário, a automatização não consegue verificar o seu próprio resultado, e o passo seguinte é uma pessoa a conduzir até ao local.

Portão três: tentativas, arrefecimento, sucesso definido

Dê ao trabalho um bloqueio por par, um período de arrefecimento e um limite rígido de tentativas contado a partir de observações frescas. Sem o bloqueio, dois monitores que disparam no mesmo instante apagam o mesmo par enquanto a renegociação está em curso, e cada um conclui que o outro falhou.

Sucesso significa que a associação voltou e a carga permitida passa, não que o comando regressou sem erro. Sondar com a mesma verificação que detetou a falha e depois confirmar que os contadores das SA filhas se movem nos dois sentidos. Um comando que sai com zero enquanto o túnel fica em baixo é uma falha de monitorização disfarçada de recuperação.

Mantenha o desconhecido separado do falhado. Se a telemetria estiver desatualizada ou o caminho de gestão for inalcançável, o estado honesto é desconhecido, e um orçamento de tentativas não deve ler isso como permissão para disparar outra vez.

Quando a primeira recuperação aprovada não restaura o serviço, escale com a captura de estado em vez de fazer ciclos. As reposições agendadas são a pior versão do padrão, porque escondem um defeito de renegociação de chaves, de rota ou de política enquanto cortam sessões saudáveis com um temporizador.

Propriedade, um interruptor e um ensaio

Nomeie um proprietário, documente como desativar o applet ou o agendamento num único passo e defina uma data de revisão. Uma automatização sem caminho de desativação torna-se infraestrutura permanente no dia em que o seu autor muda de equipa.

Ensaie-a em laboratório ou numa janela de manutenção com a seleção de par deliberadamente quebrada, para descobrir se o trabalho falha de forma segura. Depois ensaie o caminho de sucesso, porque um trabalho que só corre quando algo está mal não lhe ensina nada sobre o seu comportamento normal.