Disparador de VPN por aplicación en Windows fronte ao túnel dividido: que illa
Un perfil de VPN de Windows activado por unha aplicación só inicia un túnel. Un túnel dividido encamiñado decide que entra nel, e cada un falla de xeito distinto para unha aplicación.
Dúas configuracións de Windows parécense en Configuración e non se comportan en absoluto igual. Unha é un perfil de VPN copiado cun disparador de aplicación, así que iniciar un executable levanta o túnel. A outra é un perfil de túnel dividido cuxa lista de rutas cobre por casualidade aquilo co que fala esa aplicación. A primeira responde cando existe o túnel. A segunda responde que paquetes entran nel, e só a segunda deixa o resto da máquina na ligazón física mentres a aplicación segue conectada.
O disparador é unha regra de ciclo de vida, non unha regra de encamiñamento
Add-VpnConnectionTriggerApplication vincula a ruta dun executable a un nome de perfil. Cando ese proceso arrinca, o Xestor de conexións de acceso remoto marca o perfil, e cando remata a condición do disparador, a conexión pode caer. Nada nese intercambio inspecciona sockets. O cmdlet precisa un shell elevado, a ruta completa ao binario e -Force cando substituímos unha entrada existente. Confirma que a asociación sobreviviu con Get-VpnConnectionTrigger en vez de confiar na mensaxe; a referencia de Add-VpnConnectionTriggerApplication enumera os parámetros e os exemplos.
Dous límites explican a maioría dos informes de que «o disparador non fai nada». Os disparadores xiran arredor de perfís para todos os usuarios, así que o ámbito do perfil é o primeiro que hai que resolver, e a ruta da aplicación debe coincidir co binario que realmente se executa, non cun atallo nin cun lanzador que xera un segundo proceso. O outro límite é intencionado: nunha rede que Windows clasifica como de confianza, o disparador queda inactivo, porque o perfil está pensado para funcionar fóra da 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,AllUserConnectionO túnel dividido decide que cruza o túnel
Co túnel dividido desactivado, Windows instala unha ruta predeterminada baseada en clase cunha métrica baixa na interface VPN. Todos os sockets séguena, incluídos o navegador e o servizo de actualizacións, así que un disparador nesa configuración move toda a máquina mentres o perfil estea conectado. O disparador segue sendo só unha regra de ciclo de vida; o raio de impacto veu da ruta.
Co túnel dividido activado, o perfil só leva os prefixos que empuxa a pasarela ou que engades á interface VPN. Todo o demais segue usando a ruta predeterminada física. Esa é a disposición que a xente adoita querer dicir con «unha aplicación por unha saída separada», e é unha decisión de encamiñamento 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 DestinationPrefixOnde un túnel dividido encamiñado deixa de illar a túa aplicación
O fallo habitual é un destino que nunca aparece na lista de rutas do túnel. Unha aplicación que inicia sesión contra un enderezo e logo fai streaming desde unha CDN, ou que resolve unha ducia de puntos finais rotativos, poñerá algunhas conexións na interface VPN e o resto no Wi-Fi. IPv6 é unha táboa aparte, así que un perfil que só empuxa prefixos IPv4 pode parecer correcto mentres o tráfico IPv6 da aplicación queda local.
Dous efectos menores importan igual. Gaña a coincidencia de prefixo máis longa, así que unha ruta ligada máis específica, un /32 enviado para un host de xestión ou a subrede dun segundo adaptador poden superar o túnel xusto para o enderezo que che importa. A resolución tamén ocorre antes do encamiñamento: salvo que os servidores DNS do perfil ou unha regra NRPT cubran o nome, a aplicación pode resolver pola tarxeta física e logo marcar un enderezo que nunca estivo dentro dos prefixos tunelizados.
Tres formas e que achega cada unha
A táboa é a parte que pegaría na parede, porque a decisión vai do raio de impacto e non das funcións. Se os destinos da aplicación son prefixos estables que podes listar, o túnel dividido encamiñado dá illamento coa pegada máis pequena. Se non o son, un perfil de ruta predeterminada detrás dunha VM ou dun segundo dispositivo mantén a separación honesta a costa de mover máis dun 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 |
O que ningunha destas opcións ofrece é a vinculación a nivel de socket no host. O cliente VPN clásico de Windows non ten ningunha regra que diga que este proceso debe usar ese adaptador; os disparadores e os filtros de rutas viven en capas distintas, e a capa que escolle unha interface é a táboa de rutas. Se unha guía promete aplicación por aplicación só cun perfil copiado, pregunta que ruta ou que filtro fai o traballo.
Verifica o par nunha soa pasada
Proba o ciclo de vida e o encamiñamento por separado, nesa orde. Pecha a aplicación, confirma que o perfil indica Disconnected, despois inicia a aplicación e comproba que o estado cambiou. Só cando o túnel estea levantado debes preguntar a onde vai un destino concreto, e debes usar o enderezo que a aplicación marca de verdade en lugar dunha 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 nomea a interface e o seguinte salto que levarían ese destino. Un alias físico alí significa que o túnel está levantado e é irrelevante para ese fluxo: revisa os prefixos enviados, despois as rutas máis específicas e despois IPv6. Se o estado non cambia en absoluto, o disparador non se activou, e a ruta do executable, o ámbito do perfil e o rexistro operativo do cliente VPN son os tres sitios onde mirar.
Desfai limpiamente para que a seguinte proba sexa honesta
Elimina na orde inversa á que construíches: primeiro o disparador da aplicación, despois o perfil. Borrar o perfil mentres o disparador segue deixa unha asociación colgada que fai confuso o seguinte intento, e Remove-VpnConnection -Force non sempre limpa unha entrada da axenda telefónica creada fóra dos cmdlets.
As entradas por usuario viven no rasphone.pbk do usuario, baixo o perfil Roaming; as entradas para todos os usuarios viven en ProgramData. Revisa o almacén que coincide co ámbito do perfil, volve conectar o perfil que conservaches e confirma que as súas rutas e o DNS seguen funcionando, para que unha proba posterior mida o cambio que fixeches e non o estado restante.
- O túnel arrinca ao iniciar o proceso, non ao iniciar sesión.
- Só os prefixos previstos aparecen na interface VPN.
- O enderezo remoto real da aplicación resólvese ao alias da VPN.
- Non queda ningún disparador colgado tras eliminar o perfil.