O túnel continua ativo, a rota desapareceu: separar duas falhas de VPN

Um host torna-se inacessível enquanto a interface do túnel continua a declarar-se estabelecida, e as duas observações não se contradizem. Algo removeu o caminho que o tráfego usava: um vizinho retirou seu prefixo, uma rota estática monitorada foi removida, ou outra rota passou a ser preferida. A associação de segurança pode permanecer perfeitamente saudável nos três casos. Separar os eventos significa perguntar qual camada mudou primeiro, não se a VPN falhou.

Três estágios que parecem um único evento

Uma decisão de roteamento tem três estágios. O prefixo é recebido, selecionado como o melhor e instalado na tabela de encaminhamento. Cada estágio pode falhar sozinho, e a falha parece idêntica do lado da aplicação. Um prefixo aprendido mas que perdeu a seleção é indistinguível de um que nunca chegou quando a única evidência que se observa é a tabela de encaminhamento.

Por isso a primeira pergunta é qual estágio quebrou, e não qual protocolo tem culpa. A resposta decide quem é dono do incidente e que ferramenta a próxima verificação usa.

Leia primeiro a rota instalada

Pergunte ao kernel para onde vai realmente o tráfego para o destino que falha. ip route get imprime o próximo salto, a interface e o endereço de origem que o kernel usaria, e responde para um destino em vez de para a tabela inteira. Se a resposta nomear o túnel, a tabela de encaminhamento ainda acredita que o caminho existe e o problema está acima.

ip route get 10.20.5.10
ip route show 10.20.0.0/16

Uma resposta «unreachable» significa que não há rota instalada alguma, o que aponta para uma retirada ou uma instalação ausente. Uma resposta que nomeia uma interface física significa que o tráfego saiu do túnel sem que ninguém decidisse isso, e a próxima verificação é a preferência que venceu. Uma resposta que nomeia o túnel enquanto os pacotes continuam a desaparecer aponta mais abaixo no caminho, para a filtragem ou para o lado remoto.

Depois olhe para a visão do próprio protocolo

Um daemon de roteamento mantém mais do que uma tabela, e a comparação interessante é entre elas. Para BGP, o estado da sessão vizinha, o anúncio recebido e a rota instalada são três provas separadas. Um prefixo pode ficar na tabela recebida e nunca chegar ao kernel porque uma rota com distância administrativa menor vence. Verifique as três antes de concluir que o outro lado parou de anunciar.

vtysh -c "show bgp summary"
vtysh -c "show bgp ipv4 unicast 10.20.0.0/16"

O resumo diz se a sessão está estabelecida, a visão por prefixo diz se o prefixo foi aceito, e a consulta ao kernel diz se foi instalado. Lê-las nessa ordem evita que um tremor de sessão seja confundido com uma retirada, e uma retirada com uma rejeição por política.

Quando os relógios não concordam

Coloque o log do túnel, o log de roteamento e a primeira falha da aplicação numa única linha do tempo usando os seus fusos horários reais. Se a perda do vizinho vier primeiro, o túnel derrubou a rota consigo. Se a retirada vier primeiro, o roteamento mudou e o túnel reagiu depois. São incidentes diferentes com donos diferentes, e a ordem é todo o achado.

Um minuto de desvio do relógio basta para inverter essa conclusão, por isso confirme o fuso horário e o deslocamento antes de confiar na sequência. Os dispositivos que registram em hora local sem deslocamento são a fonte habitual de uma linha do tempo confiante mas errada.

Recuperação sem laço

Após uma retirada, dois caminhos podem ser elegíveis: o que o protocolo seleciona e o que se fixa à mão. Apenas o primeiro é uma decisão que a rede continua a tomar por você, por isso uma rota manual é um remendo e não um plano de recuperação. Um anúncio alternativo também não preserva o estado da firewall ou do NAT para uma sessão já estabelecida, portanto novos fluxos podem funcionar enquanto o original continua quebrado. Confirme qual backup deve tornar-se ativo e se o site remoto aceitará um caminho de retorno por ele.

Não instale uma substituição estática permanente antes de entender por que a retirada aconteceu. Esse atalho pode fixar o tráfego num caminho com falha ou contornar silenciosamente uma política de roteamento deliberada, e enterra a causa original sob uma nova configuração. Teste novamente a aplicação quando a rota estiver restaurada, e confirme que o prefixo escolhido tem um caminho de dados funcional e não apenas uma entrada numa tabela.