Como comprobar que encamiña realmente unha VPN en Windows con PowerShell
Un mosaico de VPN conectado non demostra cobertura. Le o indicador gardado do perfil, a táboa de rutas activa e as regras NRPT nesta orde.
Conectei o cliente VPN nun portátil con Windows 11, o mosaico pasou a Conectado, abriuse un recurso compartido interno e un sitio público seguía cargando directamente desde o Wi-Fi da oficina. Esa mestura parece un túnel roto. É a saída normal dun perfil que envía parte do tráfico pola VPN e deixa o resto no adaptador físico. O túnel forzado cambia que ruta predeterminada prefire Windows; non borra as rutas máis específicas e non promete que o tráfico se deteña cando cae a conexión. O que segue é a orde que percorro cando un cliente afirma ter cobertura: estado do cliente, perfil gardado, rutas aplicadas, resolución de nomes e despois fluxos reais.
Comeza polo cliente e despois deixa de confiar nel
O cliente é o lugar correcto para comezar só porque che di que perfil está activo. Abre as propiedades da conexión e anota o nome exacto do perfil, se se creou para o usuario actual ou para todos na máquina, e que adaptador aparece en ncpa.cpl tras conectar. No meu portátil de probas o adaptador levaba o nome do perfil, o que facía fácil ler a saída de rutas. Noutras máquinas aparece como unha entrada WAN Miniport e o nome non che di nada.
O que o cliente non pode dicirche é a cobertura. Un mosaico conectado describe o estado do túnel, non un inventario de destinos. Os clientes de terceiros tamén gardan a súa propia configuración, así que o perfil nativo de Windows, e cada propiedade que vas ler del, pode non ter nada que ver co que instalou ese cliente. Se a VPN chegou mediante AnyConnect, OpenVPN GUI, WireGuard ou un axente do provedor, as comprobacións de PowerShell de abaixo na súa maioría non se aplican e deberías ler a configuración propia de túnel dividido e encamiñamento dese cliente.
Le o perfil gardado, non o mosaico
Para un perfil nativo de Windows (IKEv2, L2TP, SSTP ou un empurrado por MDM), a decisión gardada de túnel dividido é unha soa propiedade:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixEngade -AllUserConnection cando o perfil se creou para todos no dispositivo. Sen iso les a lista do usuario actual, que pode estar baleira ou conter outra entrada cun nome similar. Un valor False en SplitTunneling significa que o perfil se gardou como túnel completo: Windows instala unha ruta predeterminada a través do adaptador da VPN. True significa túnel dividido, e entón a cobertura depende por completo das rutas e das regras de resolución de nomes que empurra ese perfil.
Trata ese valor como configuración, non como observación. Rexistra o que o perfil pediu ao conectar. Windows pode acabar con rutas aplicadas distintas, por unha ruta máis específica doutra interface, unha opción de política ou unha entrada sobrante dunha conexión anterior, así que o booleano nunca resolve a cuestión por si só.
Compara o valor gardado coa táboa de rutas aplicada
Despois de conectar, lista as rutas do adaptador do túnel en lugar de percorrer toda a táboa:
$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. Responde a pregunta que o cliente nunca responde: para este destino, que interface e que enderezo de orixe usará Windows realmente? Execútao para un host interno, un host público e calquera cousa que consideres unha excepción deliberada. Un perfil de túnel completo debería mostrar a interface do túnel para o enderezo público. Un perfil de túnel dividido adoita mostrar aí o adaptador físico mentres os prefixos internos seguen resolvéndose pola VPN.
Dúas trampas explican a maioría dos informes de «encamiña mal». O prefixo máis específico sempre gaña, así que un /24 no adaptador físico supera unha ruta predeterminada na VPN por baixa que sexa a métrica do túnel. A métrica só desempata entre rutas do mesmo prefixo. E IPv4 e IPv6 decídense por separado: un perfil que cobre 0.0.0.0/0 pode deixar IPv6 na ligazón local, o que fai que un sitio de dobre pila pareza medio tunelizado. Comproba Get-NetRoute -AddressFamily IPv6 antes de concluír que o túnel está ben.
| 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 |
Comproba a resolución de nomes por separado con NRPT
Os nomes internos que fallan mentres os enderezos IP internos funcionan apuntan á política do resolvedor, non ao encamiñamento. Windows decide o DNS por espazo de nomes mediante a táboa de políticas de resolución de nomes, que é independente da táboa de rutas:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexCando unha regra coincide con *.corp.example, as consultas dese espazo de nomes van aos servidores DNS do túnel aínda que a ruta de datos cara a eses servidores siga no adaptador físico en modo de túnel dividido. Ese é o deseño, e por iso unha proba de navegador que abre un sitio público non che di nada sobre nomes internos. Se o adaptador lista os servidores esperados pero as consultas seguen indo a outro sitio, compara a orde das regras NRPT e comproba se coincide primeiro un espazo de nomes máis específico.
Verifica os fluxos e despois decide que pediches en realidade
Percorre os destinos nunha orde fixa para que os resultados sexan comparables entre máquinas: un enderezo público, un enderezo interno, un nome interno e unha excepción deliberada como unha impresora local ou unha videollamada. Anota a interface e o enderezo de orixe que Find-NetRoute devolve para cada unha. Tras calquera cambio de política, reconecta e repite as mesmas catro comprobacións; a táboa de rutas posterior á reconexión é a única proba de que o novo perfil entrou en vigor.
Despois separa o encamiñamento da aplicación forzosa. O túnel forzado prefire o túnel para o tráfico cuberto mentres está activo. Non é un interruptor de emerxencia. Se o requisito é que nada saia da máquina cando cae o túnel, iso debe vir dun deseño de bloqueo: un perfil de devasas ligado ao estado do túnel, un perfil sempre activo con filtros de tráfico ou a opción propia de peche ante fallo do cliente do provedor. O túnel forzado tamén debe deixar accesible o enderezo do propio servidor VPN fóra do túnel, e bloquearlo en nome de «forzalo todo» é unha forma fiable de quedares fóra da conexión que intentas aplicar.
Antes de cambiar nada, repasa esta lista. Cada elemento que falla axusta onde está o problema real.
- Nome e alcance do perfil confirmados, con
-AllUserConnectionpara perfís de toda a máquina. SplitTunnelinglido e tratado como configuración, non como proba de cobertura.- Rutas do adaptador do túnel listadas por separado para IPv4 e IPv6.
Find-NetRouteexecutado para un destino público, un interno e un de excepción.- Regras NRPT comprobadas antes de culpar as rutas dun fallo de nome.
- Requisito de bloqueo relido: o encamiñamento preferido non é o mesmo que o bloqueo aplicado.
A decisión de túnel completo ou dividido pertence a quen posúe o perfil, e as notas de encamiñamento de Microsoft describen o comportamento que Windows implementa cando un perfil o establece. Microsoft: túnel forzado e dividido é a referencia que manteño aberta mentres leo a saída.