Failback na ASA: que se move realmente cando volve a ruta
Que unha ruta volva á primaria non significa que os fluxos antigos se movesen. Observe xuntos o uplink, o túnel, a táboa de conexións e o resultado da aplicación.
Nunha ASA con dous uplinks, o failback non é o inverso do failover. A ruta cara ao peer cambia e despois a plataforma ten que conciliar tres máquinas de estado separadas: a táboa de rutas, as asociacións de seguridade IKE e IPsec e a táboa de conexións. Cada unha pode quedar atrás das outras, e ese atraso é o que a maioría da xente describe como un túnel que non volve.
Que cambia realmente o failback
A consulta da ruta é a parte visible. Cando o obxecto monitorizado se recupera, a ruta monitorizada cara ao enderezo exterior do peer regresa, e o seguinte paquete que envía a ASA volve seguir a ligazón primaria. Todo o que vén despois depende de se o estado existente concorda co camiño novo.
ARP e NAT son as dependencias silenciosas. Un next hop novo necesita unha pasarela resoluble e unha tradución que aínda encaixe co extremo remoto; se non, os primeiros paquetes tras o failback non van a ningures e a ruta parece correcta mentres nada funciona.
Catro perspectivas nunha soa liña temporal
Rexistre as mesmas catro cousas antes, durante e despois da transición, porque unha soa instantánea non pode dicirlle que capa se moveu.
| View | What to record |
|---|---|
| Uplink and route | Interface state, the tracked object result, the route selected for the outer peer address |
| IKE and IPsec | The live peer, IKE version, security associations, protected-traffic counters |
| Connection table | Interface and endpoint pair for old flows and for flows created after the change |
| Application | One pre-existing operation and one fresh request, each marked success, reset, stall or recovered |
Unha ruta que nunca cambiou e unha ruta que cambiou mentres unha conexión máis antiga conservaba o seu estado de reenvío producen a mesma queixa e probas completamente distintas.
Por que as conexións antigas quedan na ruta de reserva
A ASA non derruba un fluxo porque cambiase unha ruta. As conexións establecidas conservan a decisión de reenvío coa que se crearon, e a plataforma ofrece controis separados para canto tempo se permite iso: floating-connection timeout e connection holddown. A Guía de configuración de conexións da ASA 9.24 de Cisco trátaos como preguntas distintas, e é exactamente como se comportan. Un goberna a supervivencia dun fluxo existente; o outro, cando poden os fluxos novos usar a ruta preferida.
Lea os valores efectivos da súa versión antes de cambiar calquera dos dous. Baixalos pecha sesións que a xente aínda usa. Subilos fai que o failback pareza non ter ocorrido, porque as conexións novas seguen collendo a ruta antiga durante todo ese tempo.
Un túnel non renegocia claves porque vise unha ruta
As asociacións de seguridade IPsec levan a súa propia vida útil negociada e sobreviven ao cambio de ruta que as transportaba. Por iso un túnel pode seguir en pé durante un failback mentres o seu direccionamento exterior xa non coincide co camiño en uso, que é o argumento a favor de DPD e dos deseños que fixan o enderezo do peer en lugar de deixalo flotante.
Os deseños con crypto-map e VTI compórtanse aquí de forma distinta, e a documentación de Cisco para 9.24 VTI describe a opción baseada en rutas. A vella afirmación xeral de que unha ASA non pode executar VPN baseadas en rutas non se sostén nas versións admitidas.
Lea as probas nesta orde
Comece polo plano de control: show route para a ruta seleccionada, show interface para o estado da ligazón e os contadores do monitor SLA para o obxecto monitorizado. Despois lea show crypto ikev2 sa, ou o equivalente IKEv1, para ver que peer está vivo, seguido de show crypto ipsec sa para os fluxos protexidos. A continuación restrinxa a táboa de conexións con show conn address <host> e compare a columna de interface entre as entradas antigas e novas. Anote as saídas con marcas de tempo, porque a súa orde é o diagnóstico.
Remate cunha proba de aplicación: un fluxo que xa existía e outro creado despois de que volvese a ruta. Se o fluxo antigo falla e o novo funciona, ten unha historia de estado de conexión. Se fallan os dous, o túnel ou a política están mal e a táboa de conexións é unha distracción.
Manteña ese rexistro coa mesma forma nas tres fases e anote a versión exacta. Cando a liña temporal siga apuntando a unha soa transición, envíe o rexistro a soporte en lugar de adiviñar un ID de erro.