Como verificar o que uma VPN no Windows realmente encaminha no PowerShell
Um bloco de VPN conectado não prova cobertura. Leia o sinalizador salvo do perfil, a tabela de rotas ativa e as regras NRPT nesta ordem.
Conectei o cliente VPN num portátil com Windows 11, o bloco passou a Conectado, um compartilhamento de arquivos interno abriu e um site público ainda carregava diretamente do Wi-Fi do escritório. Essa mistura parece um túnel quebrado. É a saída normal de um perfil que envia parte do tráfego pela VPN e deixa o resto no adaptador físico. O túnel forçado muda qual rota padrão o Windows prefere; não apaga rotas mais específicas e não promete que o tráfego pare quando a conexão cair. O que segue é a ordem que percorro quando um cliente afirma ter cobertura: estado do cliente, perfil salvo, rotas aplicadas, resolvedor e depois fluxos reais.
Comece pelo cliente e depois pare de confiar nele
O cliente é o lugar certo para começar só porque diz qual perfil está ativo. Abra as propriedades da conexão e anote o nome exato do perfil, se foi criado para o usuário atual ou para todos na máquina, e qual adaptador aparece em ncpa.cpl depois de conectar. No meu portátil de teste o adaptador trazia o nome do perfil, o que facilitava ler a saída de rotas. Noutras máquinas ele aparece como uma entrada WAN Miniport e o nome não diz nada.
O que o cliente não pode dizer é a cobertura. Um bloco conectado descreve o estado do túnel, não um inventário de destinos. Clientes de terceiros também mantêm a própria configuração, então o perfil nativo do Windows, e cada propriedade que você vai ler dele, pode não ter nada a ver com o que aquele cliente instalou. Se a VPN chegou via AnyConnect, OpenVPN GUI, WireGuard ou um agente do fornecedor, as verificações de PowerShell abaixo em geral não se aplicam e você deve ler antes as configurações próprias de túnel dividido e roteamento desse cliente.
Leia o perfil salvo, não o bloco
Para um perfil nativo do Windows (IKEv2, L2TP, SSTP ou um enviado por MDM), a decisão salva de túnel dividido é uma única propriedade:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixAdicione -AllUserConnection quando o perfil foi criado para todos no dispositivo. Sem isso você lê a lista do usuário atual, que pode estar vazia ou conter outra entrada com nome parecido. Um valor False em SplitTunneling significa que o perfil foi salvo como túnel completo: o Windows instala uma rota padrão através do adaptador da VPN. True significa túnel dividido, e a cobertura depende então inteiramente das rotas e regras de resolução de nomes que aquele perfil envia.
Trate esse valor como configuração, não como observação. Ele registra o que o perfil pediu no momento da conexão. O Windows pode acabar com rotas aplicadas diferentes, por causa de uma rota mais específica de outra interface, uma definição de política ou uma entrada restante de uma conexão anterior, então o booleano nunca resolve a questão sozinho.
Compare o valor salvo com a tabela de rotas aplicada
Depois de conectar, liste as rotas no adaptador do túnel em vez de percorrer a tabela toda:
$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1Find-NetRoute é a metade útil. Ele responde à pergunta que o cliente nunca responde: para este destino, qual interface e qual endereço de origem o Windows usará de fato? Execute-o para um host interno, um host público e qualquer coisa que você considere uma exceção deliberada. Um perfil de túnel completo deve mostrar a interface do túnel para o endereço público. Um perfil de túnel dividido costuma mostrar ali o adaptador físico enquanto os prefixos internos ainda resolvem pela VPN.
Duas armadilhas explicam a maioria dos relatos de «está roteando errado». O prefixo mais específico sempre vence, então um /24 no adaptador físico ganha de uma rota padrão na VPN por mais baixa que seja a métrica do túnel. A métrica só desempata entre rotas do mesmo prefixo. E IPv4 e IPv6 são decididos separadamente: um perfil que cobre 0.0.0.0/0 pode deixar o IPv6 no link local, o que faz um site de pilha dupla parecer meio tunelado. Verifique Get-NetRoute -AddressFamily IPv6 antes de concluir que o túnel está bem.
| What you see | Most likely cause | Check next |
|---|---|---|
| Public traffic leaves the physical adapter while SplitTunneling reads False | A more specific route on that adapter wins over the tunnel default | Find-NetRoute for the exact destination, then look for a /24 or host route on the physical interface |
| Internal name fails, internal IP works | No NRPT rule for that namespace, or a broader rule matches first | Get-DnsClientNrptPolicy and the namespace order |
| A dual-stack site opens directly while IPv4 uses the tunnel | The profile covers only the IPv4 default route | The IPv6 route table on both interfaces |
| Routes look right but one app still goes direct | The app uses its own proxy, or the client keeps a per-app list | The app's proxy settings and the client's application list |
Verifique a resolução de nomes separadamente com a NRPT
Nomes internos que falham enquanto os endereços IP internos funcionam apontam para a política do resolvedor, não para o roteamento. O Windows decide o DNS por espaço de nomes através da tabela de políticas de resolução de nomes, que é independente da tabela de rotas:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexQuando uma regra corresponde a *.corp.example, as consultas desse espaço de nomes vão para os servidores DNS do túnel mesmo que o caminho de dados até esses servidores fique no adaptador físico no modo de túnel dividido. Esse é o desenho, e é por isso que um teste de navegador que abre um site público não diz nada sobre nomes internos. Se o adaptador lista os servidores esperados mas as consultas continuam indo para outro lugar, compare a ordem das regras NRPT e verifique se um espaço de nomes mais específico corresponde primeiro.
Verifique os fluxos e depois decida o que você realmente pediu
Percorra os destinos numa ordem fixa para que os resultados sejam comparáveis entre máquinas: um endereço público, um endereço interno, um nome interno e uma exceção deliberada, como uma impressora local ou uma videochamada. Anote a interface e o endereço de origem que Find-NetRoute devolve para cada um. Depois de qualquer mudança de política, reconecte e repita as mesmas quatro verificações; a tabela de rotas após a reconexão é a única prova de que o novo perfil entrou em vigor.
Depois separe o roteamento da aplicação forçada. O túnel forçado prefere o túnel para o tráfego coberto enquanto ele está ativo. Não é um kill switch. Se o requisito é que nada saia da máquina quando o túnel cai, isso tem de vir de um desenho de bloqueio: um perfil de firewall ligado ao estado do túnel, um perfil sempre ativo com filtros de tráfego ou a opção própria de fechamento em falha do cliente do fornecedor. O túnel forçado também precisa deixar o endereço do próprio servidor VPN acessível fora do túnel, e bloqueá-lo em nome de «forçar tudo» é uma forma confiável de se trancar fora da conexão que você tenta aplicar.
Antes de mudar qualquer coisa, percorra esta lista. Cada item que falha estreita onde está o problema real.
- Nome e escopo do perfil confirmados, com
-AllUserConnectionpara perfis de toda a máquina. SplitTunnelinglido e tratado como configuração, não como prova de cobertura.- Rotas do adaptador do túnel listadas separadamente para IPv4 e IPv6.
Find-NetRouteexecutado para um destino público, um interno e um de exceção.- Regras NRPT verificadas antes de culpar as rotas por uma falha de nome.
- Requisito de bloqueio relido: o roteamento preferido não é o mesmo que o bloqueio aplicado.
A decisão de túnel completo ou dividido pertence a quem possui o perfil, e as notas de roteamento da Microsoft descrevem o comportamento que o Windows implementa quando um perfil o define. Microsoft: túnel forçado e dividido é a referência que mantenho aberta enquanto leio a saída.