Failback na ASA: o que se move realmente quando a rota regressa
O regresso de uma rota ao caminho principal não significa que os fluxos antigos se tenham deslocado. Observe em conjunto o uplink, o túnel, a tabela de ligações e o resultado da aplicação.
Numa ASA com dois uplinks, o failback não é o inverso do failover. A rota para o peer muda e, depois, a plataforma tem de reconciliar três máquinas de estado distintas: a tabela de rotas, as associações de segurança IKE e IPsec e a tabela de ligações. Cada uma pode ficar atrás das outras, e é esse atraso que a maioria das pessoas descreve como um túnel que não regressa.
O que o failback realmente altera
A consulta da rota é a parte visível. Quando o objeto monitorizado recupera, a rota monitorizada para o endereço exterior do peer regressa, e o pacote seguinte que a ASA envia volta a seguir a ligação principal. Tudo o que vem depois depende de o estado existente estar de acordo com o novo caminho.
ARP e NAT são as dependências silenciosas. Um novo next hop precisa de um gateway resolúvel e de uma tradução que ainda corresponda ao extremo remoto, senão os primeiros pacotes após o failback não vão a lado nenhum e a rota parece bem enquanto nada funciona.
Quatro vistas numa única linha temporal
Registe as mesmas quatro coisas antes, durante e depois da transição, porque uma única instantâneo não consegue dizer que camada 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 |
Uma rota que nunca mudou e uma rota que mudou enquanto uma ligação mais antiga mantinha o seu estado de encaminhamento produzem a mesma queixa e provas completamente diferentes.
Porque as ligações antigas ficam no caminho de reserva
A ASA não derruba um fluxo porque uma rota mudou. As ligações estabelecidas mantêm a decisão de encaminhamento com que foram criadas, e a plataforma expõe controlos separados para quanto tempo isso é permitido: floating-connection timeout e connection holddown. o guia de configurações de ligação da ASA 9.24 da Cisco trata-os como questões distintas, e é exatamente assim que se comportam. Um governa a sobrevivência de um fluxo existente; o outro, quando os novos fluxos podem usar o caminho preferido.
Leia os valores efetivos da sua versão antes de alterar qualquer um deles. Baixá-los fecha sessões que as pessoas ainda usam. Subi-los faz o failback parecer que nunca aconteceu, porque as novas ligações continuam a usar o caminho antigo durante todo o período.
Um túnel não renegocia chaves porque uma rota regressou
As associações de segurança IPsec transportam o seu próprio tempo de vida negociado e sobrevivem à mudança de rota que as transportou. Um túnel pode, por isso, ficar de pé durante um failback enquanto o seu endereçamento exterior já não corresponde ao caminho em uso, e é este o argumento a favor de DPD e de projetos que fixam o endereço do peer em vez de o deixarem flutuar.
Os projetos crypto-map e VTI comportam-se aqui de forma diferente, e a documentação da Cisco para 9.24 VTI descreve a opção baseada em rotas. A velha afirmação genérica de que uma ASA não consegue executar VPN baseadas em rotas não se aplica às versões suportadas.
Leia as provas nesta ordem
Comece pelo plano de controlo: show route para o caminho selecionado, show interface para o estado da ligação e os contadores do monitor SLA para o objeto monitorizado. Depois leia show crypto ikev2 sa, ou o equivalente IKEv1, para ver qual peer está vivo, seguido de show crypto ipsec sa para os fluxos protegidos. Em seguida restrinja a tabela de ligações com show conn address <host> e compare a coluna da interface nas entradas antigas e novas. Anote as saídas com marcas temporais, porque a ordem delas é o diagnóstico.
Termine com um teste de aplicação: um fluxo que já existia e outro criado depois de a rota regressar. Se o fluxo antigo falhar e o novo funcionar, tem uma história de estado de ligação. Se ambos falharem, o túnel ou a política estão errados e a tabela de ligações é uma distração.
Mantenha esse registo na mesma forma nas três fases e anote a versão exata. Quando a linha temporal continuar a apontar para uma única transição, envie o registo ao suporte em vez de adivinhar um ID de erro.