A VPN do Windows está a levar todo o tráfego? Remova a rota predefinida

Liga-se à VPN do escritório e cada página do navegador começa a passar por essa rede: o servidor de ficheiros é rápido, todo o resto está lento, filtrado ou desapareceu. O cliente não se está a comportar mal; o perfil pediu um túnel completo. O interruptor que o trava é uma caixa de verificação num diálogo que a aplicação Definições moderna não mostra, e o gateway volta a ter voz em cada ligação. Este guia segue a ordem que a interface do Windows apresenta realmente e depois cobre as verificações que continuam a falhar quando a tabela de rotas parece correta.

Comece nas propriedades do adaptador, não em Definições

A aplicação Definições lista o perfil em Rede e Internet e depois VPN, mas só expõe opções gerais. A decisão do gateway predefinido vive no adaptador. Abra a lista clássica de adaptadores com Win+R e ncpa.cpl, clique com o botão direito na ligação VPN, escolha Propriedades, selecione Protocolo Internet versão 4, escolha novamente Propriedades e depois Avançadas. Desmarque Utilizar gateway predefinido na rede remota e confirme a saída dos três diálogos.

Volte a ligar antes de testar, porque a caixa é aplicada quando o túnel é estabelecido e uma sessão existente mantém a tabela que construiu. Se o adaptador faltar enquanto o cliente está desligado, ligue-se uma vez e reabra a janela. Um cliente de fornecedor que instala um adaptador TAP ou Wintun sem página de propriedades IPv4 não tem este diálogo de todo; para esses, a mesma decisão é uma opção de tunelamento dividido nas definições do próprio cliente, e a caixa do adaptador é o local errado para procurar.

A mesma alteração a partir do PowerShell

Para um perfil criado no arquivo VPN do Windows, a definição é scriptable, que é o que quer se a máquina for reconstruída com frequência:

Set-VpnConnection -Name "Office" -SplitTunneling $true
Get-VpnConnection -Name "Office" | Select-Object Name,SplitTunneling

Esse cmdlet só alcança perfis desse arquivo. Uma ligação adicionada por um cliente de terceiros não aparecerá, e o comando falha com um erro de nome que se lê como uma gralha. Note também o que o interruptor não faz: impede o cliente de instalar uma rota predefinida, mas não remove as rotas que o gateway empurra ao ligar, pelo que a secção seguinte continua a ser necessária em muitas redes.

Quando o gateway volta a empurrar a rota predefinida

Leia primeiro a tabela. Duas entradas predefinidas com métricas diferentes significam que a alteração do perfil funcionou e que a rota empurrada a substituiu de qualquer forma:

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-NetAdapter | Select-Object Name,ifIndex

Elimine a rota predefinida que pertence ao túnel e mantenha a física. Use o índice de interface do terceiro comando, não o alias do adaptador, porque os scripts que passam um alias quebram assim que o nome de apresentação muda:

Remove-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceIndex 21 -Confirm:$false
route delete 0.0.0.0 10.8.0.1

A eliminação leva o escritório consigo, por isso volte a adicionar os prefixos corporativos através do gateway do túnel. Esta é a linha que as pessoas saltam, e é a razão pela qual «a VPN deixou de funcionar» segue uma alteração de tunelamento dividido bem-sucedida:

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Nada disto sobrevive a uma nova ligação, o que é um comportamento honesto e não um erro: o adaptador é reconstruído e o cliente volta a aplicar o que o perfil e o gateway acordaram. Se a predefinida reaparecer sempre, o gateway está configurado para recusar o tunelamento dividido e continuará a empurrá-la, ou cortará a sessão. Essa é a política do operador da rede, e o pedido pertence lá e não a um script local que luta contra isso uma vez por ligação.

Verifique novamente DNS, IPv6 e as métricas após uma nova ligação

Remover uma rota predefinida IPv4 não prova nada sobre a outra família nem sobre a resolução de nomes. Um túnel pode transportar IPv6 enquanto a predefinida IPv4 fica local, e uma lista de resolvedores empurrada pode manter os nomes internos a funcionar enquanto as consultas que a usam seguem outro caminho. Verifique as três antes de dar a tarefa por concluída:

Get-NetRoute -DestinationPrefix ::/0
Get-DnsClientServerAddress -InterfaceAlias "Office"
Get-DnsClientNrptPolicy

Se o estado voltar em cada ligação, mova os comandos para uma ação por ligação em vez de editar a tabela à mão: uma tarefa agendada acionada pelo evento de ligação, ou a definição de tunelamento dividido do próprio cliente quando existe. Mantenha o índice de interface numa variável e consulte-o em tempo de execução, porque pode mudar quando adaptadores são adicionados ou removidos.

Decida o que cedeu

O tráfego de Internet local já não é inspecionado nem filtrado pelo escritório, e tudo o que é publicado apenas através do túnel passa a precisar da sua própria rota. Algumas organizações consideram o tunelamento dividido uma violação de política, por isso confirme isso antes de alterar um dispositivo gerido; uma predefinida empurrada é por vezes o mecanismo de aplicação e não um acidente. A documentação do Set-VpnConnection lista o parâmetro de tunelamento dividido e os tipos de perfil a que se aplica.

Depois verifique numa ordem fixa: quem detém a rota predefinida, a navegação normal, um anfitrião corporativo por endereço, um nome interno, e os mesmos quatro após uma única nova ligação. Se a navegação funcionar e o anfitrião corporativo falhar, falta a rota de prefixo e não a predefinida que removeu, e isso é muito mais barato de corrigir do que reconstruir o perfil.