Déclencheur VPN par application sous Windows ou tunneling divisé : ce qui isole
Un profil VPN Windows déclenché par une application ne fait que démarrer un tunnel. Un tunneling divisé routé décide de ce qui y entre, et chacun échoue différemment pour une application.
Deux configurations Windows se ressemblent dans Paramètres et ne se comportent pas du tout de la même façon. L’une est un profil VPN copié avec un déclencheur d’application, si bien que le lancement d’un exécutable monte le tunnel. L’autre est un profil en tunneling divisé dont la liste de routes couvre justement ce avec quoi cette application communique. La première répond quand le tunnel existe. La seconde répond quels paquets y entrent, et seule la seconde laisse le reste de la machine sur le lien physique pendant que l’application reste connectée.
Le déclencheur est une règle de cycle de vie, pas une règle de routage
Add-VpnConnectionTriggerApplication lie un chemin d’exécutable à un nom de profil. Quand ce processus démarre, le Gestionnaire de connexions d’accès distant compose le profil, et lorsque la condition de déclenchement se termine, la connexion peut tomber. Rien dans cet échange n’inspecte les sockets. L’applet de commande exige un shell élevé, le chemin complet du binaire et -Force quand vous remplacez une entrée existante. Confirmez que l’association a survécu avec Get-VpnConnectionTrigger au lieu de vous fier à l’invite ; la référence d’Add-VpnConnectionTriggerApplication liste les paramètres et les exemples.
Deux limites expliquent la plupart des signalements « le déclencheur ne fait rien ». Les déclencheurs reposent sur des profils pour tous les utilisateurs, donc la portée du profil est la première chose à régler, et le chemin de l’application doit correspondre au binaire qui s’exécute réellement, pas à un raccourci ni à un lanceur qui démarre un second processus. L’autre limite est voulue : sur un réseau que Windows classe comme approuvé, le déclencheur reste inactif, car le profil est censé se déclencher hors du bureau.
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,AllUserConnectionLe tunneling divisé décide de ce qui traverse le tunnel
Tunneling divisé désactivé, Windows installe une route par défaut basée sur la classe avec une métrique basse sur l’interface VPN. Chaque socket la suit, y compris le navigateur et le service de mise à jour, si bien qu’un déclencheur dans cette configuration déplace toute la machine tant que le profil est connecté. Le déclencheur reste une simple règle de cycle de vie ; le rayon d’impact venait de la route.
Tunneling divisé activé, le profil ne porte que les préfixes que la passerelle pousse ou que vous ajoutez à l’interface VPN. Tout le reste continue d’utiliser la route par défaut physique. C’est la disposition que les gens entendent généralement par « une application par une sortie séparée », et c’est une décision de routage de bout en bout.
Set-VpnConnection -Name "APP_VPN" -SplitTunneling $true
Get-VpnConnection -Name "APP_VPN" | Select-Object SplitTunneling
Get-NetRoute -InterfaceAlias "APP_VPN" | Sort-Object DestinationPrefixLà où un split routé cesse d’isoler votre application
La défaillance courante est une destination qui n’apparaît jamais dans la liste de routes du tunnel. Une application qui s’authentifie sur une adresse puis diffuse depuis un CDN, ou qui résout une douzaine de points de terminaison rotatifs, placera certaines connexions sur l’interface VPN et le reste sur le Wi-Fi. IPv6 est une table distincte, si bien qu’un profil qui ne pousse que des préfixes IPv4 peut sembler correct alors que le trafic IPv6 de l’application reste local.
Deux effets plus petits comptent autant. La correspondance du préfixe le plus long gagne, si bien qu’une route sur lien plus spécifique, un /32 poussé pour un hôte d’administration ou le sous-réseau d’une seconde carte peuvent battre le tunnel précisément pour l’adresse qui vous intéresse. La résolution se fait aussi avant le routage : à moins que les serveurs DNS du profil ou une règle NRPT ne couvrent le nom, l’application peut résoudre via la carte physique puis composer une adresse qui n’a jamais été dans les préfixes tunnelisés.
Trois formes, et ce que chacune apporte
Le tableau est la partie que je scotcherais au mur, car la décision porte sur le rayon d’impact plutôt que sur les fonctionnalités. Si les destinations de l’application sont des préfixes stables que vous pouvez lister, le split routé donne l’isolation avec la plus petite empreinte. Sinon, un profil en route par défaut derrière une VM ou un second appareil garde la séparation honnête au prix de déplacer plus d’un processus.
| 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 |
Ce qu’aucune de ces options n’offre, c’est une liaison au niveau du socket sur l’hôte. Le client VPN classique de Windows n’a aucune règle disant que ce processus doit utiliser cette carte ; les déclencheurs et les filtres de routes vivent dans des couches différentes, et la couche qui choisit une interface est la table de routage. Si un guide promet une application par application à partir d’un simple profil copié, demandez quelle route ou quel filtre fait le travail.
Vérifiez la paire en une seule passe
Testez le cycle de vie et le routage séparément, dans cet ordre. Fermez l’application, confirmez que le profil indique Disconnected, puis lancez l’application et vérifiez que l’état a changé. Ce n’est qu’une fois le tunnel monté que vous devez demander où va une destination précise, et vous devez utiliser l’adresse que l’application compose réellement plutôt qu’une supposition.
$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 nomme l’interface et le prochain saut qui porteraient cette destination. Un alias physique ici signifie que le tunnel est monté et sans importance pour ce flux : vérifiez les préfixes poussés, puis les routes plus spécifiques, puis IPv6. Si l’état ne change jamais du tout, le déclencheur ne s’est pas déclenché, et le chemin de l’exécutable, la portée du profil et le journal opérationnel du client VPN sont les trois endroits à regarder.
Démontez proprement pour que le prochain test soit honnête
Supprimez dans l’ordre inverse de la construction : d’abord le déclencheur d’application, puis le profil. Supprimer le profil alors que le déclencheur reste laisse une association pendante qui rend la tentative suivante confuse, et Remove-VpnConnection -Force ne nettoie pas toujours une entrée de carnet d’adresses créée en dehors des applets.
Les entrées par utilisateur vivent dans le rasphone.pbk de l’utilisateur, sous le profil Roaming ; les entrées pour tous les utilisateurs vivent sous ProgramData. Vérifiez le magasin qui correspond à la portée du profil, reconnectez le profil conservé et confirmez que ses routes et son DNS se comportent encore, afin qu’un test ultérieur mesure le changement effectué plutôt qu’un état résiduel.
- Le tunnel démarre au lancement du processus, pas à la connexion.
- Seuls les préfixes prévus apparaissent sur l’interface VPN.
- L’adresse distante réelle de l’application se résout en l’alias VPN.
- Aucun déclencheur pendant ne subsiste après la suppression du profil.