Como distinguir as rotas empurradas pela VPN das estáticas no Linux

Um prefixo aparece no portátil quando o túnel sobe, por isso parece que a VPN o instalou. Pode ter instalado, mas o mesmo resultado pode vir de um script de cliente que corre ao ligar, de um perfil de ligação que lista a sub-rede, ou de uma rota estática que ali estava desde o início e só começou a funcionar quando a interface existiu. Escolher o proprietário errado significa que a rota volta após cada limpeza, e a pessoa seguinte repete a mesma correção. A sequência abaixo separa os três antes de mudar seja o que for.

Passo 1: nomeie o mecanismo que instala prefixos

Protocolos diferentes fornecem alcançabilidade de formas diferentes, e chamar a tudo isso um anúncio esconde a distinção. Um servidor OpenVPN empurra uma diretiva de rota pelo canal de controlo e o cliente instala-a, a menos que um filtro pull a bloqueie. Uma configuração WireGuard lista localmente os prefixos permitidos, que o cliente usa tanto para o encaminhamento de chaves criptográficas como para as rotas que acrescenta. Um túnel IPsec negoceia seletores de tráfego com o par, e o núcleo instala rotas a partir desses seletores.

Identifique qual destes o seu túnel usa antes de ler qualquer tabela. Uma rota empurrada ao ligar não é um anúncio de um protocolo de encaminhamento e não promete que o prefixo seja alcançável atrás da extremidade remota. Anote o mecanismo junto ao prefixo, porque é ele que decide onde pertence a correção.

Passo 2: compare a tabela ao longo de uma ligação

Guarde a tabela principal com o túnel em baixo, levante-o, guarde outra vez e compare as duas capturas. Tudo o que apareceu pertence ao ciclo de vida da ligação, e tudo o que ficou pertence à configuração local.

Capture-a com ip route show table main > /tmp/route-down.txt, ligue-se e capture de novo. Faça o mesmo para ip -6 route se o site usar IPv6, porque um prefixo em falta aí produz falhas que parecem não ter relação com o encaminhamento.

Passo 3: leia a métrica, não apenas a presença

Duas entradas para o mesmo prefixo podem coexistir, e o núcleo escolhe a métrica mais baixa. Uma rota estática com métrica 50 continuará a ganhar a uma rota empurrada com 100 mesmo que ambas sejam visíveis, por isso «a rota está lá» e «o tráfego usa-a» são afirmações diferentes.

Pergunte ao núcleo diretamente com ip route get 10.20.5.7 e leia a interface que ele indica. Se o tráfego sair pelo adaptador físico enquanto uma rota do túnel está na tabela, é a métrica ou o comprimento do prefixo que o explica, não o cliente VPN. Repita a consulta para um anfitrião que sabe estar atrás do túnel e para um que sabe não estar, e a diferença mostra se a divisão se comporta como pretendido.

Passo 4: encontre as entradas que sobrevivem ao túnel

As rotas estáticas sobrevivem a uma desconexão por desenho, e é daí que vêm as entradas obsoletas. Uma rota persistente que aponta para uma interface que já não existe pode engolir uma sub-rede em silêncio, e uma que aponta para um nome de interface reutilizado pode enviar tráfego privado pela porta errada após um reinício.

Verifique o lado persistente no local que a sua distribuição usa, seja uma unidade systemd-networkd, um perfil NetworkManager ou um script no diretório up do cliente. Corrigir a tabela viva com ip route del só aguenta até à ligação seguinte. Trate essa eliminação como um teste da hipótese e não como a reparação.

Onde a extremidade remota fornece a cobertura errada, leve o assunto ao operador em vez de filtrar tudo. Descartar todas as definições empurradas também descarta o DNS e a política de túnel dividido de que o perfil depende.

Passo 5: confirme o caminho de regresso antes de culpar o cliente

Para uma ligação sítio a sítio ou uma sub-rede atrás do túnel, o lado remoto precisa de uma rota de regresso ao endereço do seu cliente e do encaminhamento ativo na gateway. Um caminho de ida parece exatamente um erro de encaminhamento do cliente, exceto que o aperto de mão e o pacote de saída têm ambos sucesso.

A filtragem do caminho inverso acrescenta uma segunda armadilha nas gateways Linux. Uma resposta que chega por uma interface diferente da que a rota prevê é descartada em modo estrito, e os caminhos assimétricos por dois fornecedores desencadeiam-no de forma fiável. Os contadores de descarte na gateway, não no cliente, dizem se a filtragem é a causa.

Passo 6: teste o recurso, não o ping

Depois de a rota escolhida estar correta, abra o recurso real e confirme o tráfego de regresso. Uma resposta a ping prova o caminho num sentido e nada sobre o serviço, e um serviço que responde numa ligação em cache prova ainda menos.

Depois repita toda a verificação após uma reconexão. O valor da sequência é que prevê o que fará a ligação seguinte, por isso tanto a comparação como a métrica pertencem ao ticket.