Disparador de VPN por aplicación en Windows frente al túnel dividido: qué aísla
Un perfil de VPN de Windows activado por una aplicación solo inicia un túnel. Un túnel dividido enrutado decide qué entra en él, y cada uno falla de forma distinta para una aplicación.
Dos configuraciones de Windows se parecen en Configuración y no se comportan en absoluto igual. Una es un perfil de VPN copiado con un disparador de aplicación, así que iniciar un ejecutable levanta el túnel. La otra es un perfil de túnel dividido cuya lista de rutas cubre por casualidad aquello con lo que habla esa aplicación. La primera responde cuándo existe el túnel. La segunda responde qué paquetes entran en él, y solo la segunda deja el resto de la máquina en el enlace físico mientras la aplicación sigue conectada.
El disparador es una regla de ciclo de vida, no una regla de enrutamiento
Add-VpnConnectionTriggerApplication vincula la ruta de un ejecutable a un nombre de perfil. Cuando ese proceso arranca, el Administrador de conexiones de acceso remoto marca el perfil, y cuando termina la condición del disparador, la conexión puede caerse. Nada en ese intercambio inspecciona sockets. El cmdlet necesita un shell elevado, la ruta completa al binario y -Force cuando reemplazas una entrada existente. Confirma que la asociación sobrevivió con Get-VpnConnectionTrigger en lugar de fiarte del mensaje; la referencia de Add-VpnConnectionTriggerApplication enumera los parámetros y los ejemplos.
Dos límites explican la mayoría de los informes de que «el disparador no hace nada». Los disparadores giran en torno a perfiles para todos los usuarios, así que el ámbito del perfil es lo primero que hay que resolver, y la ruta de la aplicación debe coincidir con el binario que realmente se ejecuta, no con un acceso directo ni con un lanzador que genera un segundo proceso. El otro límite es intencionado: en una red que Windows clasifica como de confianza, el disparador permanece inactivo, porque el perfil está pensado para funcionar fuera de la oficina.
Add-VpnConnectionTriggerApplication -Name "APP_VPN" -ApplicationID "C:\Program Files\Vendor\app.exe" -Force
Get-VpnConnectionTrigger -Name "APP_VPN" | Format-List *
Get-VpnConnection -Name "APP_VPN" | Format-List Name,ConnectionStatus,SplitTunneling,AllUserConnectionEl túnel dividido decide qué cruza el túnel
Con el túnel dividido desactivado, Windows instala una ruta predeterminada basada en clase con una métrica baja en la interfaz VPN. Todos los sockets la siguen, incluidos el navegador y el servicio de actualizaciones, así que un disparador en esa configuración mueve toda la máquina mientras el perfil esté conectado. El disparador sigue siendo solo una regla de ciclo de vida; el radio de impacto vino de la ruta.
Con el túnel dividido activado, el perfil solo lleva los prefijos que empuja la puerta de enlace o que añades a la interfaz VPN. Todo lo demás sigue usando la ruta predeterminada física. Esa es la disposición que la gente suele querer decir con «una aplicación por una salida separada», y es una decisión de enrutamiento de principio a fin.
Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefixDónde un túnel dividido enrutado deja de aislar tu aplicación
El fallo habitual es un destino que nunca aparece en la lista de rutas del túnel. Una aplicación que inicia sesión contra una dirección y luego hace streaming desde una CDN, o que resuelve una docena de puntos finales rotativos, pondrá algunas conexiones en la interfaz VPN y el resto en el Wi-Fi. IPv6 es una tabla aparte, así que un perfil que solo empuja prefijos IPv4 puede parecer correcto mientras el tráfico IPv6 de la aplicación se queda local.
Dos efectos menores importan igual. Gana la coincidencia de prefijo más larga, así que una ruta enlazada más específica, un /32 enviado para un host de gestión o la subred de un segundo adaptador pueden superar al túnel justo para la dirección que te importa. La resolución también ocurre antes del enrutamiento: salvo que los servidores DNS del perfil o una regla NRPT cubran el nombre, la aplicación puede resolver por el adaptador físico y luego marcar una dirección que nunca estuvo dentro de los prefijos tunelizados.
Tres formas y qué aporta cada una
La tabla es la parte que pegaría en la pared, porque la decisión va del radio de impacto y no de las funciones. Si los destinos de la aplicación son prefijos estables que puedes listar, el túnel dividido enrutado da aislamiento con la huella más pequeña. Si no lo son, un perfil de ruta predeterminada detrás de una VM o de un segundo dispositivo mantiene la separación honesta a costa de mover más de un proceso.
| Shape | What starts the tunnel | What enters it | Pick it when |
|---|---|---|---|
| Trigger plus routed split | Process start | Only pushed or added prefixes | The app's endpoints are stable prefixes and the host should stay direct |
| Trigger plus default route | Process start | Everything, machine-wide | You need one exit for all traffic and accept the wider scope |
| Separate VM or device | Guest boot or login | Everything inside that guest | The app's destinations rotate, or the host must keep its own public address |
Lo que ninguna de estas opciones ofrece es vinculación a nivel de socket en el host. El cliente VPN clásico de Windows no tiene ninguna regla que diga que este proceso debe usar ese adaptador; los disparadores y los filtros de rutas viven en capas distintas, y la capa que elige una interfaz es la tabla de rutas. Si una guía promete aplicación por aplicación solo con un perfil copiado, pregunta qué ruta o qué filtro hace el trabajo.
Verifica el par en una sola pasada
Prueba el ciclo de vida y el enrutamiento por separado, en ese orden. Cierra la aplicación, confirma que el perfil indica Disconnected, luego inicia la aplicación y comprueba que el estado cambió. Solo cuando el túnel esté levantado debes preguntar adónde va un destino concreto, y debes usar la dirección que la aplicación marca de verdad en lugar de una suposición.
$app = Get-Process app | Select-Object -First 1
Get-VpnConnection -Name "APP_VPN" | Select-Object ConnectionStatus
Get-NetTCPConnection -OwningProcess $app.Id -State Established | Select-Object RemoteAddress,RemotePort
Find-NetRoute -RemoteIPAddress 203.0.113.10Find-NetRoute nombra la interfaz y el siguiente salto que llevaría ese destino. Un alias físico ahí significa que el túnel está levantado y es irrelevante para ese flujo: revisa los prefijos empujados, luego las rutas más específicas, luego IPv6. Si el estado no cambia en absoluto, el disparador no se activó, y la ruta del ejecutable, el ámbito del perfil y el registro operativo del cliente VPN son los tres sitios donde mirar.
Deshaz limpiamente para que la siguiente prueba sea honesta
Elimina en el orden inverso al que construiste: primero el disparador de la aplicación, luego el perfil. Borrar el perfil mientras el disparador sigue deja una asociación colgada que hace confuso el siguiente intento, y Remove-VpnConnection -Force no siempre borra una entrada de la guía telefónica creada fuera de los cmdlets.
Las entradas por usuario viven en el rasphone.pbk del usuario, bajo el perfil Roaming; las entradas para todos los usuarios viven en ProgramData. Revisa el almacén que coincide con el ámbito del perfil, vuelve a conectar el perfil que conservaste y confirma que sus rutas y su DNS siguen funcionando, para que una prueba posterior mida el cambio que hiciste y no el estado sobrante.
- El túnel arranca al iniciar el proceso, no al iniciar sesión.
- Solo los prefijos previstos aparecen en la interfaz VPN.
- La dirección remota real de la aplicación se resuelve al alias de la VPN.
- No queda ningún disparador colgado tras eliminar el perfil.