Por que uma sub-rede ainda contorna a rota padrão da VPN

Você muda a VPN para túnel completo, a maior parte do tráfego obedece, e então um endereço responde diretamente — uma impressora, um NAS, um host de salto em 10.x. A leitura óbvia é que o túnel está vazando, então você baixa a métrica da rota padrão e nada muda. Essa tentativa fracassada é a pista: uma rota padrão é um recurso de reserva, não um veredito. A consulta de rota pega o prefixo correspondente mais longo antes mesmo de comparar métricas, então uma /24 continua vencendo uma /0, não importa qual número você prenda a qualquer uma delas. Uma vez clara essa ordem, o vazamento costuma ser uma rota que alguém instalou de propósito, ou um prefixo que o cliente nunca pretendeu cobrir.

O que uma rota padrão realmente promete

0.0.0.0/0 corresponde a qualquer destino IPv4 com zero bits de especificidade. Ela existe para que um host alcance qualquer coisa que sua tabela não descreva melhor. Uma rota para 192.168.1.0/24 carrega 24 bits correspondentes, então para 192.168.1.40 ela vence antes que alguém compare métricas, distância administrativa ou como o cliente chame seu campo de prioridade. A mesma regra vale na FIB do Linux, na tabela de rotas do Windows e na pilha BSD atrás do macOS.

Numa LAN normal esse comportamento é um recurso. A sub-rede local está conectada diretamente, a impressora continua funcionando enquanto o túnel carrega sua navegação, e nada está mal configurado. A pergunta que vale a pena não é por que esse endereço vai direto, mas qual prefixo em qual tabela corresponde a ele, e quem o colocou ali.

Meias-rotas padrão, ou por que a entrada padrão pode parecer intacta

O exemplo mais limpo é redirect-gateway def1 do OpenVPN. Em vez de apagar sua rota padrão e substituí-la, ele adiciona 0.0.0.0/1 e 128.0.0.0/1. Juntas, a dupla cobre todo o IPv4, cada prefixo é mais longo que /0, e ambas derrotam a rota padrão do roteador deixando-a no lugar. Execute uma listagem de rotas depois e a rota padrão original ainda está lá, ainda aponta para o seu gateway; ela simplesmente nunca é escolhida para destinos de internet.

O wg-quick do WireGuard chega ao mesmo resultado por roteamento baseado em política. Quando AllowedIPs cobre 0.0.0.0/0, ele cria sua própria tabela, envia os pacotes marcados para lá e adiciona uma regra que ignora o prefixo de comprimento zero da tabela principal. A tabela principal mantém sua entrada padrão, e as regras decidem que a tabela do túnel é consultada primeiro para o tráfego que a interface possui.

Os dois desenhos precisam de exatamente uma rota fora do túnel: uma rota de host para o endereço do próprio servidor VPN através do gateway original. Sem ela, o cliente tentaria carregar dentro do túnel os pacotes que constroem o túnel, e a conexão nunca se completaria. Uma rota que não é de túnel na sua tabela é, portanto, normal mesmo num perfil estrito de túnel completo. As rotas que merecem questionamento são as que cobrem destinos que realmente importam para você.

Métricas decidem empates, prefixos decidem vencedores

As métricas só são comparadas entre candidatos que correspondem igualmente bem ao destino. No Linux, ip route get 10.20.5.9 imprime o vencedor junto com sua tabela, e ip route show table all lista os candidatos, incluindo quaisquer meias-rotas padrão e qualquer tabela para a qual uma regra aponte. No Windows, Find-NetRoute -RemoteIPAddress 10.20.5.9 devolve a rota selecionada e o endereço de origem, enquanto Get-NetRoute mostra a tabela crua — mas o custo efetivo é a métrica da rota mais a métrica da interface, então um adaptador lento pode perder um empate que parece ganhar.

Três casos cobrem a maior parte do que você verá:

• Mesmo destino, /24 contra /0: a /24 vence pelo comprimento do prefixo, digam o que digam as métricas.
• Mesmo destino, duas /24 com métricas diferentes: vence a métrica efetiva mais baixa.
• Mesmo destino, duas tabelas, uma escolhida por uma regra de política: a regra escolhe a tabela primeiro, e a comparação de prefixos acontece dentro dela.

O terceiro caso é onde a maioria desses relatos termina. Uma ip rule do Linux ou um filtro de tráfego VPN do Windows pode enviar tráfego para uma tabela que nunca teve a rota padrão do túnel, e a tabela principal parece perfeita o tempo todo.

Quem costuma ser dono do desvio

Comece pelo perfil, não pela tabela. Configurações de túnel dividido e ajustes de VPN por aplicativo deixam deliberadamente prefixos nomeados fora do túnel; um perfil de trabalho que protege uma sub-rede privada e deixa a navegação geral ir direto comporta-se como projetado, e substituí-lo quebra a política que ele deveria aplicar. O guia de roteamento VPN da Microsoft traça a mesma linha entre tráfego forçado no túnel e exceções explícitas, o que o torna uma verificação cruzada útil antes de editar qualquer coisa.

Depois procure sobras. Uma rota que aponta para uma interface que não existe mais, ou para um endereço da rede anterior, aparece depois que estações de acoplamento, adaptadores USB e pontes de contêiner vão e vêm. Apagá-la uma vez não é o fim: perfis de conexão do NetworkManager, arquivos netplan e rotas persistentes do Windows a reinstalam na próxima conexão ou inicialização, então encontre o arquivo ou perfil que a possui antes de editar qualquer coisa.

Depois verifique IPv6 separadamente. ip -6 route e Get-NetRoute -AddressFamily IPv6 mantêm estado separado, rotas padrão separadas e comportamento de cliente separado. Uma auditoria só de IPv4 não diz nada sobre um host de pilha dupla que prefere silenciosamente um caminho IPv6 nativo, e isso sozinho pode fazer um cliente parecer túnel dividido.

Confirme com o fluxo da própria aplicação

Anote o destino que a aplicação realmente usa e depois pergunte ao sistema o caminho que ela tomaria a partir do endereço de origem ao qual aquela aplicação se vincula. ip route get 10.20.5.9 from 192.168.1.40 responde a isso no Linux; Find-NetRoute -RemoteIPAddress 10.20.5.9 mais o endereço local faz isso no Windows. Compare o resultado com o que o perfil afirma. A página de IP público de um navegador testa um destino num protocolo e não diz nada sobre o endereço privado que iniciou a queixa.

Corrija o objeto mais estreito que explica a diferença. Se a exceção está aprovada, anote o prefixo e deixe-o; se não, remova a rota ou adicione uma rota explícita mais estreita pelo túnel em vez de baixar a métrica da padrão. Baixar uma métrica não supera um prefixo mais longo, e editar a padrão enquanto duas rotas /1 possuem o caminho de internet também não muda nada.

Depois reconecte o túnel e repita a mesma consulta. Os clientes reinstalam rotas a cada conexão, então uma mudança que só dura até o próximo handshake não foi testada. Se o caminho ainda divergir, os suspeitos restantes são uma regra de política, uma segunda tabela ou um filtro do lado do cliente — não a rota padrão.

• Nomeie o destino e o endereço de origem que o aplicativo realmente usa.
• Mostre a rota vencedora com ip route get ou Find-NetRoute.
• Verifique se um par /1 ou uma tabela de política é dono do caminho de internet.
• Liste todo prefixo mais longo que /0 que corresponda ao destino.
• Repita a verificação de IPv6 separadamente.
• Rastreie a rota sobrevivente até o arquivo, perfil ou filtro que a instala.
• Reconecte e execute a consulta novamente antes de declará-la corrigida.

Se todos os sete concordarem com o perfil, o túnel faz exatamente o que foi configurado para fazer, e a correção pertence ao perfil, não a uma métrica.