Cómo comprobar qué enruta realmente una VPN en Windows con PowerShell
Un mosaico de VPN conectado no demuestra cobertura. Lee el indicador guardado del perfil, la tabla de rutas activa y las reglas NRPT en este orden.
Conecté el cliente VPN en un portátil con Windows 11, el mosaico pasó a Conectado, se abrió un recurso compartido interno y un sitio público seguía cargando directamente desde el Wi-Fi de la oficina. Esa mezcla parece un túnel roto. Es la salida normal de un perfil que envía parte del tráfico por la VPN y deja el resto en el adaptador físico. El túnel forzado cambia qué ruta predeterminada prefiere Windows; no borra las rutas más específicas y no promete que el tráfico se detenga cuando cae la conexión. Lo que sigue es el orden que recorro cuando un cliente afirma tener cobertura: estado del cliente, perfil guardado, rutas aplicadas, resolución de nombres y luego flujos reales.
Empieza por el cliente y luego deja de confiar en él
El cliente es el lugar correcto para empezar solo porque te dice qué perfil está activo. Abre las propiedades de la conexión y anota el nombre exacto del perfil, si se creó para el usuario actual o para todos en la máquina, y qué adaptador aparece en ncpa.cpl tras conectar. En mi portátil de pruebas el adaptador llevaba el nombre del perfil, lo que hacía fácil leer la salida de rutas. En otras máquinas aparece como una entrada WAN Miniport y el nombre no te dice nada.
Lo que el cliente no puede decirte es la cobertura. Un mosaico conectado describe el estado del túnel, no un inventario de destinos. Los clientes de terceros también guardan su propia configuración, así que el perfil nativo de Windows, y cada propiedad que vas a leer de él, puede no tener nada que ver con lo que instaló ese cliente. Si la VPN llegó mediante AnyConnect, OpenVPN GUI, WireGuard o un agente del proveedor, las comprobaciones de PowerShell de abajo en su mayoría no se aplican y deberías leer la configuración propia de túnel dividido y enrutamiento de ese cliente.
Lee el perfil guardado, no el mosaico
Para un perfil nativo de Windows (IKEv2, L2TP, SSTP o uno empujado por MDM), la decisión guardada de túnel dividido es una sola propiedad:
Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffixAñade -AllUserConnection cuando el perfil se creó para todos en el dispositivo. Sin eso lees la lista del usuario actual, que puede estar vacía o contener otra entrada con un nombre similar. Un valor False en SplitTunneling significa que el perfil se guardó como túnel completo: Windows instala una ruta predeterminada a través del adaptador de la VPN. True significa túnel dividido, y entonces la cobertura depende por completo de las rutas y las reglas de resolución de nombres que empuja ese perfil.
Trata ese valor como configuración, no como observación. Registra qué pidió el perfil al conectar. Windows puede acabar con rutas aplicadas distintas, por una ruta más específica de otra interfaz, una opción de directiva o una entrada sobrante de una conexión anterior, así que el booleano nunca resuelve la pregunta por sí solo.
Compara el valor guardado con la tabla de rutas aplicada
Después de conectar, lista las rutas del adaptador del túnel en lugar de recorrer toda la tabla:
$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 es la mitad útil. Responde la pregunta que el cliente nunca responde: para este destino, ¿qué interfaz y qué dirección de origen usará Windows realmente? Ejecútalo para un host interno, un host público y cualquier cosa que consideres una excepción deliberada. Un perfil de túnel completo debería mostrar la interfaz del túnel para la dirección pública. Un perfil de túnel dividido suele mostrar ahí el adaptador físico mientras los prefijos internos siguen resolviéndose por la VPN.
Dos trampas explican la mayoría de los informes de «enruta mal». El prefijo más específico siempre gana, así que un /24 en el adaptador físico supera a una ruta predeterminada en la VPN por baja que sea la métrica del túnel. La métrica solo desempata entre rutas del mismo prefijo. Y IPv4 e IPv6 se deciden por separado: un perfil que cubre 0.0.0.0/0 puede dejar IPv6 en el enlace local, lo que hace que un sitio de doble pila parezca medio tunelizado. Comprueba Get-NetRoute -AddressFamily IPv6 antes de concluir que el túnel está bien.
| 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 |
Comprueba la resolución de nombres por separado con NRPT
Los nombres internos que fallan mientras las direcciones IP internas funcionan apuntan a la directiva del resolutor, no al enrutamiento. Windows decide el DNS por espacio de nombres mediante la tabla de directivas de resolución de nombres, que es independiente de la tabla de rutas:
Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndexCuando una regla coincide con *.corp.example, las consultas de ese espacio de nombres van a los servidores DNS del túnel aunque la ruta de datos hacia esos servidores siga en el adaptador físico en modo de túnel dividido. Ese es el diseño, y por eso una prueba de navegador que abre un sitio público no te dice nada sobre nombres internos. Si el adaptador lista los servidores esperados pero las consultas siguen yendo a otro sitio, compara el orden de las reglas NRPT y comprueba si coincide primero un espacio de nombres más específico.
Verifica los flujos y luego decide qué pediste en realidad
Recorre los destinos en un orden fijo para que los resultados sean comparables entre máquinas: una dirección pública, una dirección interna, un nombre interno y una excepción deliberada como una impresora local o una videollamada. Anota la interfaz y la dirección de origen que Find-NetRoute devuelve para cada una. Tras cualquier cambio de directiva, reconecta y repite las mismas cuatro comprobaciones; la tabla de rutas posterior a la reconexión es la única prueba de que el nuevo perfil surtió efecto.
Luego separa el enrutamiento de la aplicación forzosa. El túnel forzado prefiere el túnel para el tráfico cubierto mientras está activo. No es un interruptor de emergencia. Si el requisito es que nada salga de la máquina cuando cae el túnel, eso debe venir de un diseño de bloqueo: un perfil de firewall ligado al estado del túnel, un perfil siempre activo con filtros de tráfico o la opción propia de cierre ante fallo del cliente del proveedor. El túnel forzado también debe dejar accesible la dirección del propio servidor VPN fuera del túnel, y bloquearla en nombre de «forzarlo todo» es una forma fiable de quedarte fuera de la conexión que intentas aplicar.
Antes de cambiar nada, repasa esta lista. Cada elemento que falla acota dónde está el problema real.
- Nombre y alcance del perfil confirmados, con
-AllUserConnectionpara perfiles de toda la máquina. SplitTunnelingleído y tratado como configuración, no como prueba de cobertura.- Rutas del adaptador del túnel listadas por separado para IPv4 e IPv6.
Find-NetRouteejecutado para un destino público, uno interno y uno de excepción.- Reglas NRPT comprobadas antes de culpar a las rutas de un fallo de nombre.
- Requisito de bloqueo releído: el enrutamiento preferido no es lo mismo que el bloqueo aplicado.
La decisión de túnel completo o dividido pertenece a quien posee el perfil, y las notas de enrutamiento de Microsoft describen el comportamiento que Windows implementa cuando un perfil lo establece. Microsoft: túnel forzado y dividido es la referencia que mantengo abierta mientras leo la salida.