Activador de VPN per aplicació a Windows contra túnel dividit: què aïlla
Un perfil de VPN de Windows activat per una aplicació només obre un túnel. Un túnel dividit amb rutes decideix què hi entra, i cada opció falla de manera diferent per a una aplicació.
Dues configuracions de Windows s’assemblen a Configuració i no es comporten gens igual. Una és un perfil de VPN copiat amb un activador d’aplicació, de manera que engegar un executable aixeca el túnel. L’altra és un perfil de túnel dividit la llista de rutes del qual cobreix justament allò amb què parla aquella aplicació. La primera respon quan el túnel existeix. La segona respon quins paquets hi entren, i només la segona deixa la resta de la màquina a l’enllaç físic mentre l’aplicació continua connectada.
L’activador és una regla de cicle de vida, no una regla d’encaminament
Add-VpnConnectionTriggerApplication vincula un camí executable a un nom de perfil. Quan aquell procés s’inicia, el Gestor de connexions d’accés remot marca el perfil, i quan la condició de l’activador s’acaba, la connexió es pot tallar. Res d’aquest intercanvi no inspecciona sòcols. El cmdlet necessita un shell elevat, el camí complet del binari i -Force quan substituïu una entrada existent. Confirmeu que l’associació ha sobreviscut amb Get-VpnConnectionTrigger en lloc de confiar en el missatge; la referència d’Add-VpnConnectionTriggerApplication llista els paràmetres i els exemples.
Dos límits expliquen la majoria d’informes que “l’activador no fa res”. Els activadors es basen en perfils per a tots els usuaris, així que l’abast del perfil és la primera cosa a resoldre, i el camí de l’aplicació ha de coincidir amb el binari que realment s’executa, no amb una drecera ni amb un llançador que genera un segon procés. L’altre límit és intencionat: en una xarxa que Windows classifica com a fiable, l’activador queda inactiu, perquè el perfil està pensat per funcionar fora de l’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 dividit decideix què travessa el túnel
Amb el túnel dividit desactivat, Windows instal·la una ruta per defecte basada en classe amb una mètrica baixa a la interfície VPN. Tots els sòcols la segueixen, inclòs el navegador i el servei d’actualitzacions, així que un activador en aquesta configuració mou tota la màquina mentre el perfil estigui connectat. L’activador continua sent només una regla de cicle de vida; el radi d’impacte venia de la ruta.
Amb el túnel dividit activat, el perfil només porta els prefixos que la passarel·la empeny o que afegiu a la interfície VPN. Tota la resta continua utilitzant la ruta per defecte física. Aquesta és la disposició que la gent sol voler dir amb “una aplicació per una sortida separada”, i és una decisió d’encaminament de cap a peus.
Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefixOn un túnel dividit amb rutes deixa d’aïllar la vostra aplicació
La fallada habitual és una destinació que no apareix mai a la llista de rutes del túnel. Una aplicació que inicia sessió contra una adreça i després fa streaming des d’una CDN, o que resol una dotzena de punts finals rotatius, posarà algunes connexions a la interfície VPN i la resta al Wi-Fi. IPv6 és una taula a part, així que un perfil que només empeny prefixos IPv4 pot semblar correcte mentre el trànsit IPv6 de l’aplicació es queda local.
Dos efectes més petits importen igual. Guanya la coincidència de prefix més llarg, així que una ruta enllaçada més específica, un /32 enviat per a un amfitrió de gestió o la subxarxa d’una segona targeta poden superar el túnel justament per a l’adreça que us interessa. La resolució també passa abans de l’encaminament: tret que els servidors DNS del perfil o una regla NRPT cobreixin el nom, l’aplicació pot resoldre per la targeta física i després marcar una adreça que mai no era dins dels prefixos tunelats.
Tres formes, i què compra cadascuna
La taula és la part que enganxaria a la paret, perquè la decisió va del radi d’impacte i no de les funcions. Si les destinacions de l’aplicació són prefixos estables que podeu llistar, el túnel dividit amb rutes dóna aïllament amb la petjada més petita. Si no ho són, un perfil de ruta per defecte darrere d’una VM o d’un segon dispositiu manté la separació honesta a costa de moure més d’un procés.
| 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 |
El que cap d’aquestes opcions ofereix és vinculació a nivell de sòcol a l’amfitrió. El client VPN clàssic de Windows no té cap regla que digui que aquest procés ha d’usar aquella targeta; els activadors i els filtres de rutes viuen en capes diferents, i la capa que tria una interfície és la taula de rutes. Si una guia promet aplicació per aplicació només amb un perfil copiat, pregunteu quina ruta o quin filtre fa la feina.
Verifiqueu la parella en una sola passada
Proveu el cicle de vida i l’encaminament per separat, en aquest ordre. Tanqueu l’aplicació, confirmeu que el perfil indica Disconnected, i després engegueu l’aplicació i comproveu que l’estat ha canviat. Només quan el túnel estigui aixecat heu de preguntar on va una destinació concreta, i heu d’usar l’adreça que l’aplicació marca realment en lloc d’una suposició.
$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 nomena la interfície i el següent salt que portarien aquella destinació. Un àlies físic allà vol dir que el túnel està aixecat i és irrellevant per a aquell flux: comproveu els prefixos enviats, després les rutes més específiques i després IPv6. Si l’estat no canvia mai, l’activador no s’ha disparat, i el camí de l’executable, l’abast del perfil i el registre operatiu del client VPN són els tres llocs on mirar.
Desfeu-ho net perquè la propera prova sigui honesta
Elimineu en l’ordre invers al que vau construir: primer l’activador de l’aplicació, després el perfil. Esborrar el perfil mentre l’activador continua deixa una associació penjada que fa confús el proper intent, i Remove-VpnConnection -Force no sempre esborra una entrada de l’agenda telefònica creada fora dels cmdlets.
Les entrades per usuari viuen al rasphone.pbk de l’usuari, sota el perfil Roaming; les entrades per a tots els usuaris viuen a ProgramData. Comproveu el magatzem que coincideix amb l’abast del perfil, torneu a connectar el perfil que heu conservat i confirmeu que les seves rutes i el DNS encara funcionen, perquè una prova posterior mesuri el canvi que heu fet i no l’estat romanent.
- El túnel s’inicia en engegar el procés, no en iniciar sessió.
- Només els prefixos previstos apareixen a la interfície VPN.
- L’adreça remota real de l’aplicació es resol a l’àlies de la VPN.
- No queda cap activador penjat després de treure el perfil.