A métrica da rota VPN mudou após conectar: o que isso significa
Uma métrica menor só desempata entre rotas igualmente específicas. Leia a regra de política, o prefixo e a rota de host do endpoint antes de editar qualquer número de rota VPN.
Você conecta a VPN, executa route print e a rota padrão agora carrega uma métrica muito menor do que antes. A conclusão natural é que a VPN assumiu a rota padrão porque o número dela é menor. Às vezes foi exatamente isso que aconteceu. Muitas vezes a métrica não é o fator decisivo, e editá-la não muda nada porque a escolha foi feita antes, pelo comprimento do prefixo ou por uma regra de política.
O sintoma é real: o tráfego que antes saía pelo adaptador Wi-Fi agora sai pelo túnel, ou o contrário. A métrica é uma entrada de uma busca que roda em ordem fixa, e é essa ordem que você precisa ler antes de mexer em um número.
Com o que o número realmente compete
A primeira comparação é especificidade, não preferência. Uma rota para 10.20.0.0/16 vence 10.0.0.0/8, e ambas vencem 0.0.0.0/0, digam o que disserem suas métricas. Uma VPN que instala uma rota padrão com a menor métrica da máquina ainda perde para qualquer rota mais específica que corresponda ao destino, incluindo a rota de host que o cliente instala para o próprio servidor.
Por isso baixar a métrica de uma rota padrão não consegue forçar uma sub-rede conectada diretamente para dentro do túnel. Se você quer essa sub-rede dentro da VPN, adicione uma rota para o prefixo ou selecione a tabela do túnel com uma regra de política. A métrica é a alavanca errada para esse trabalho.
| Check in this order | Question | Where you read it |
|---|---|---|
| 1. Policy and table | Which routing table does this traffic use? | ip rule, client profile |
| 2. Prefix length | Which matching route is most specific? | route print, ip route |
| 3. Metric | Which of the equally specific routes is preferred? | route print, ip route |
| 4. Interface state | Is the chosen next hop reachable? | adapter status, link state |
O Linux decide a tabela antes da métrica
No Linux o kernel consulta primeiro o banco de políticas. ip rule lista as regras e as tabelas que elas selecionam, e ip route get 203.0.113.10 informa a tabela, a rota e o endereço de origem que o kernel realmente usaria para aquele destino. Uma métrica dentro da tabela 100 nunca compete com uma rota da tabela principal, porque a regra escolheu a tabela antes de qualquer métrica ser comparada.
Por isso uma rota pode parecer correta em ip route show table all e ainda assim não carregar tráfego. Leia a regra que coincidiu, depois a tabela que ela selecionou, depois compare as rotas dentro dela. Se a tabela errada foi selecionada, nenhuma edição de métrica na outra tabela vai ajudar.
O Windows combina duas métricas
O Windows não tem banco de políticas por padrão, mas combina uma métrica de rota com uma métrica de interface, e a métrica automática de interface pode mudar com a velocidade do link e o estado do adaptador. Por isso a mesma rota pode se comportar diferente depois que uma docking station ou um adaptador virtual aparece. Find-NetRoute -RemoteIPAddress 203.0.113.10 informa o endereço de origem, o próximo salto e a interface escolhidos, o que está mais perto da decisão real do que a tabela bruta.
Leia os valores de rota e de interface juntos. Aumentar a métrica de uma interface pode mover tráfego sem que nenhuma entrada de rota mude, e um cliente VPN que possui suas rotas vai reinstalá-las ao reconectar e descartar sua edição.
Mantenha o endpoint do túnel fora do túnel
Todo túnel precisa de um caminho até o próprio servidor que não passe pelo túnel. Os clientes instalam uma rota de host para o endpoint pelo gateway físico, e essa rota deve continuar mais específica que a rota padrão que o cliente adiciona. Apague-a, ou deixe o túnel ganhar a busca por esse endereço, e os pacotes encapsulados tentarão entrar no túnel que deveriam construir. A conexão falha ou entra em laço.
Verifique essa rota de host antes e depois de qualquer mudança de métrica: ela deve apontar para o próximo salto físico e sobreviver a uma reconexão. Se o cliente é dono dela, mude o perfil ou a configuração gerenciada em vez de um valor de runtime que será sobrescrito.
Verifique as duas famílias de endereços e o contexto do aplicativo
IPv4 e IPv6 são decisões separadas com tabelas separadas. Uma VPN pode carregar IPv4 enquanto o IPv6 continua usando o roteador local, e uma mudança de métrica em uma família não diz nada sobre a outra. Verifique as duas e depois verifique o contexto da aplicação. Um processo preso a uma interface, um namespace de contêiner ou uma VPN por aplicativo podem ver uma tabela diferente da sua shell.
Verifique com a ferramenta que informa a decisão para o destino real, não com a listagem completa da tabela. Se a rota escolhida é a que o projeto pretende, pare. Uma métrica que não é o menor número na tela não é defeito, e forçá-la a ser a menor pode quebrar o caminho do endpoint do qual o túnel depende.