O reset de par no ASA apaga as SA de IPsec, não o estado IKE nem as sessões
Um clear limitado ao par derruba apenas o caminho de dados IPsec. Veja o que sobrevive, por que o túnel se reconstrói em segundos e que camada limpar em vez disso.
O túnel cai para uma única aplicação, alguém executa um clear de IPsec limitado ao par e o ticket é encerrado porque o comando foi aceito. Nada nessa sequência mostra que a falha foi corrigida. Num ASA a palavra reset abrange três âmbitos separados, e o clear limitado ao par toca exatamente um deles, por isso o mesmo túnel costuma estar de pé outra vez antes de o operador terminar de ler a saída.
Três âmbitos escondidos atrás de uma palavra
Um par de SA de IPsec é o próprio caminho de dados, uma associação por sentido, com números de sequência e contadores. Uma SA de IKE é o canal de negociação que produziu essas associações e que ainda mantém a relação com o par. Uma sessão VPN é o registo da base de dados de sessões para um utilizador, um par site a site ou uma ligação sem 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 |
Os âmbitos são suficientemente independentes para que limpar um deixe os outros a funcionar, e essa independência gera a maior parte da confusão. Limpe as SA de IPsec enquanto a SA de IKE está saudável, e o tráfego provoca associações novas em segundos, pelo que o túnel parece ter-se curado sozinho. O desajuste da proposta, a falha de rota ou a falha de autenticação continuam lá.
Se a falha estiver na negociação, um clear de IPsec não muda nada observável.
Leia o estado enquanto ainda existe
Anote o endereço do par, a versão de IKE em uso, as redes protegidas e os contadores direcionais antes de tocar em alguma coisa. As vistas suportadas variam conforme a versão, mas as formas são estáveis: show crypto ipsec sa peer, show crypto ikev2 sa detailed ou o equivalente para IKEv1, e show vpn-sessiondb para a camada de sessões.
Escreva o registo temporal e a falha exata visível ao utilizador ao lado dessa saída. Um par costuma transportar várias redes protegidas, pelo que o raio de um clear limitado ao par é cada seletor desse par, não a única aplicação do ticket. Um reset sem imagem prévia não pode ser diagnosticado depois, porque o clear apaga precisamente os contadores com que teria comparado.
Recolha primeiro as provas. O clear elimina-as, e uma captura feita depois diz o que foi reconstruído, não o que estava avariado.
O que o clear limitado ao par faz realmente
A referência dos comandos clear da Cisco documenta a forma de IPsec limitada ao par. Com um endereço de documentação substituído, fica assim:
clear crypto ipsec sa peer 198.51.100.42Esse comando derruba as associações de IPsec que correspondem ao par. Não remove a SA de IKE, não apaga configuração e não reinicia a base de dados de sessões. Execute-o a partir de um caminho de gestão que não dependa do túnel que está a alterar, porque uma sessão SSH transportada dentro desse túnel morrerá com ele e pode não voltar sozinha. Todo o resto do equipamento continua a funcionar, e é precisamente por isso que o comando parece inofensivo.
Quando a procura do alvo é incerta, não recorra a um clear sem qualificação. A forma mais ampla chega a cada par do equipamento, e a interrupção que criar será maior do que aquela por que foi chamado.
Verifique a camada que queria reparar
Depois do clear, confirme que as associações voltaram com contadores novos em vez de assumir que o reset funcionou porque a lista de pares se repovoou. Depois teste a aplicação indicada no ticket, porque um ping bem-sucedido não diz nada sobre uma permissão de serviço ou uma sessão expirada.
Se as associações se reconstruírem e a aplicação continuar a falhar, os candidatos restantes são a camada de IKE e a camada de sessões. Escolha aquela cujo estado ainda consegue inspecionar. Use a operação dirigida para a versão que está realmente em execução, seja um clear de IKEv2, um clear de IKEv1 ou um clear da base de dados de sessões limitado ao tipo de sessão correto. Apagar e recriar configuração persistente de crypto-map para forçar uma reconstrução é adivinhação com uma reversão mais longa.
Escale com ambas as imagens, antes e depois, em vez de limpar outra vez.
Quando o reset prolonga a interrupção
Os clear repetidos escondem as falhas que um reset não consegue corrigir: uma rota em falta, um seletor que já não corresponde à nova sub-rede, uma chave pré-partilhada alterada de um lado ou uma renovação de chave que falha repetidamente numa proposta que o par não aceitará. Cada clear interrompe tráfego saudável em cada seletor desse par enquanto a causa real fica intacta. É assim que uma investigação de cinco minutos se transforma numa janela de mudança.
Um reset delimitado continua a ser útil. A versão útil é dirigida, registada e seguida de uma inspeção da camada que devia reparar.
Ordem de trabalho: registe par, versão, seletores e contadores; confirme a que âmbito pertence a falha; execute o clear mais estreito que corresponda; verifique as associações e a aplicação; escale com provas se a camada recuperar mas o sintoma não.