O reset de par no ASA borra as SA de IPsec, non o estado de IKE nin as sesións
Un clear limitado ao par só derruba a ruta de datos de IPsec. Vexa que sobrevive, por que o túnel se reconstrúe en segundos e que capa cómpre limpar no seu lugar.
O túnel cae para unha soa aplicación, alguén executa un clear de IPsec limitado ao par e o ticket péchase porque a orde foi aceptada. Nada desa secuencia demostra que a avaría fose reparada. Nun ASA a palabra reset cobre tres ámbitos separados, e o clear limitado ao par toca exactamente un deles, por iso o mesmo túnel adoita estar de novo arriba antes de que o operador remate de ler a saída.
Tres ámbitos agóchanse tras unha palabra
Un par de SA de IPsec é a propia ruta de datos, unha asociación por sentido, con números de secuencia e contadores. Unha SA de IKE é a canle de negociación que produciu esas asociacións e que aínda mantén xunta a relación co par. Unha sesión VPN é o rexistro da base de datos de sesións para un usuario, un par sitio a sitio ou unha conexión sen 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 son abondo independentes como para que limpar un deixe funcionando os demais, e esa independencia xera a maior parte da confusión. Limpe as SA de IPsec mentres a SA de IKE está san e o tráfico provoca asociacións novas en segundos, así que o túnel parece terse curado só. O desaxuste de proposta, o oco de ruta ou o fallo de autenticación seguen aí.
Se a avaría está na negociación, un clear de IPsec non cambia nada observable.
Lea o estado mentres aínda existe
Anote o enderezo do par, a versión de IKE en uso, as redes protexidas e os contadores direccionais antes de tocar nada. As vistas admitidas varían segundo a versión, pero as formas son estables: show crypto ipsec sa peer, show crypto ikev2 sa detailed ou o equivalente para IKEv1, e show vpn-sessiondb para a capa de sesións.
Escriba a marca de tempo e a avaría exacta que ve o usuario xunto a esa saída. Un par adoita levar varias redes protexidas, así que o radio dun clear limitado ao par é cada selector dese par, non a única aplicación do ticket. Un reset sen imaxe previa non se pode diagnosticar despois, porque o clear borra xusto os contadores cos que tería comparado.
Capture primeiro as probas. O clear elimínaas, e unha captura tomada despois dille que se reconstruíu, non que estaba roto.
Que fai realmente o clear limitado ao par
A referencia de ordes clear de Cisco documenta a forma de IPsec limitada ao par. Cun enderezo de documentación substituído, queda así:
clear crypto ipsec sa peer 198.51.100.42Esa orde derruba as asociacións de IPsec que coinciden co par. Non elimina a SA de IKE, non borra configuración e non reinicia a base de datos de sesións. Execútea desde unha ruta de xestión que non dependa do túnel que está a cambiar, porque unha sesión SSH transportada dentro dese túnel morrerá con el e pode que non volva por si soa. Todo o demais no dispositivo segue funcionando, e xustamente por iso a orde parece inofensiva.
Cando a busca do obxectivo é incerta, non recorra a un clear sen cualificar. A forma máis ampla chega a cada par do dispositivo e a caída que provoque será maior que aquela pola que o chamaron.
Verifique a capa que quería reparar
Despois do clear, confirme que as asociacións volveron con contadores novos en lugar de supor que o reset funcionou porque a lista de pares se repoboou. Logo probe a aplicación que nomeaba o ticket, porque un ping correcto non di nada sobre un permiso de servizo nin sobre unha sesión caducada.
Se as asociacións se reconstrúen e a aplicación segue fallando, os candidatos restantes son a capa de IKE e a capa de sesións. Escolla a que aínda poida inspeccionar. Use a operación dirixida para a versión que realmente se executa, sexa un clear de IKEv2, un clear de IKEv1 ou un clear da base de datos de sesións limitado ao tipo de sesión correcto. Borrar e recrear configuración persistente de crypto-map para forzar unha reconstrución é unha conxectura cunha reversión máis longa.
Escale coas dúas imaxes, antes e despois, en lugar de limpar outra vez.
Cando o reset alarga a caída
Os clear repetidos agochan as avarías que un reset non pode arranxar: unha ruta que falta, un selector que xa non coincide coa subrede nova, unha clave precompartida cambiada nun lado ou unha renovación de clave que falla unha e outra vez cunha proposta que o par non aceptará. Cada clear interrompe tráfico san en cada selector dese par mentres a causa real queda intacta. Así é como unha investigación de cinco minutos se converte nunha xanela de cambio.
Un reset acoutado segue sendo útil. A versión útil é dirixida, rexistrada e seguida dunha inspección da capa que debía reparar.
Orde de traballo: capture par, versión, selectores e contadores; confirme a que ámbito pertence a avaría; execute o clear máis estreito que encaixe; verifique as asociacións e a aplicación; escale con probas se a capa se recupera pero o síntoma non.