A detecção de peer morto do IKEv2 não testa a sua aplicação

A verificação de vivacidade do IKEv2 faz uma pergunta: o outro peer ainda responde na relação de controle protegida. Ela não mede se uma aplicação interna está saudável, se existe uma rota atrás do gateway, ou se navegar parece rápido. A verificação pode passar enquanto tudo o que é útil atrás do túnel falha.

Leia os dois tipos de evidência separadamente antes de mudar um temporizador.

O que a verificação de vivacidade realmente pergunta

Uma troca de vivacidade é enviada dentro da associação de segurança IKE estabelecida e espera uma resposta dentro de uma janela configurada. Sucesso significa que a implementação IKE do peer ainda está lá e ainda disposta a conversar. Ela não diz nada sobre as associações de segurança filhas que transportam tráfego, nada sobre roteamento além do gateway, e nada sobre o serviço para o qual você abriu o túnel. São três perguntas separadas com três modos de falha separados.

Essa distinção decide onde olhar quando uma sessão fica silenciosa. Um peer que continua respondendo enquanto um caminho de dados está quebrado aponta para política, roteamento ou um serviço a jusante. Um peer que para de responder aponta para alcançabilidade ou para o estado da própria ponta remota.

Leia as associações de segurança antes do navegador

O estado de controle e o estado de dados são listados separadamente quando você pergunta ao daemon, e os contadores dizem se algo foi tentado. Uma associação filha que nunca foi instalada não se parece em nada com uma que foi instalada e depois parou de passar pacotes, embora ambas produzam a mesma reclamação do usuário.

ipsec statusall | head -n 40
swanctl --list-sas
ip xfrm state | grep -E 'proto|mode'

Anote os nomes dos estados literalmente no ticket, junto com os contadores no momento da reclamação. Uma descrição como túnel em baixo esconde qual das duas associações terminou, e esse é geralmente o único fato que vale a pena ter.

Uma falha de rota parece exatamente um peer morto

O gateway pode responder a trocas de controle enquanto um servidor privado está offline, uma rota encaminhada está faltando, ou a resolução de nomes interna falha por completo. Do ponto de vista do cliente, cada um desses casos aparece como uma sessão ativa e um destino inativo. Verifique o caminho de volta com o mesmo cuidado que o caminho de ida, porque o roteamento assimétrico do lado remoto produz silêncio em apenas uma direção.

Teste a aplicação pretendida diretamente e nomeie o endereço que ela tentou, em vez de testar se o túnel está ativo. Um ping ao gateway prova que o gateway responde; nunca provou que a aplicação respondeu. Registre o endereço exato que a aplicação tentou. Essa string estreita a busca depois, e é o único fato que o ticket costuma omitir.

Mantenha os temporizadores fora do diagnóstico

Encurtar um intervalo de detecção não é uma mudança de desempenho e não adiciona capacidade. Sob perda de pacotes, muda a rapidez com que uma falha é reconhecida, o que pode fazer um sintoma parecer diferente sem melhorar nada. Registre primeiro o momento real da falha, depois decida se a tolerância está errada para o link que você realmente tem.

As renovações de mapeamento NAT pertencem à mesma categoria. Elas mantêm um caminho traduzido utilizável, e não são prova de que a aplicação remota funciona.

Uma política de recuperação completa diz o que o cliente deve fazer quando um peer é declarado morto: reiniciar, fechar ou manter, e o que outro tráfego pode fazer enquanto isso acontece. Sem isso, o mesmo incidente é diagnosticado do zero a cada trimestre.