Exclure un hôte de la route par défaut d'un VPN Windows

Le portable se connecte au VPN du bureau et tout le suit, y compris la page web d'une imprimante et un intranet qui ne répond que sur le réseau local. Une route fabriquée à la main corrige cela pendant une heure, puis la connexion tombe, revient, et l'exception a disparu. Rien ne cloche dans le tunnel : Windows tient une seule table de routage, et l'adaptateur VPN réécrit sa part de cette table à chaque connexion. Ce qui survit, c'est tout ce qui vit en dehors des entrées propres à l'adaptateur.

Quelle entrée le tunnel reprend

Relevez la table deux fois, une fois tunnel coupé et une fois tunnel monté, et comparez les lignes par défaut. Quand le profil revendique le préfixe par défaut, l'entrée de l'adaptateur est la ligne la plus large de la table, donc toute exception doit être plus étroite qu'elle. C'est de l'arithmétique sur la longueur du préfixe, pas une affirmation sur la confiance ou la politique. Elle fixe aussi quelle interface l'exception doit nommer.

Notez l'index d'interface et la passerelle locale avant de continuer, car les deux changent quand la machine rejoint un autre réseau. Les commandes ci-dessous les lisent depuis la machine et non depuis la mémoire.

route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.30

La seconde commande indique l'interface et le prochain saut que cette adresse utiliserait à l'instant, ce qui vaut mieux que lire quarante lignes et deviner. Lancez-la avant et après la connexion et vous avez la paire qui mérite d'être jointe à un enregistrement de changement. Les deux sorties fournissent les nombres utilisés dans le reste de cette page.

Une route d'hôte l'emporte par sa spécificité

La correspondance du préfixe le plus long décide du gagnant, donc un /32 par la passerelle physique bat la route par défaut par le tunnel sans que le tunnel soit touché. Le trafic vers cette adresse sort par l'interface locale tandis que tout le reste garde son chemin actuel. Le tunnel porte toujours la route par défaut et cesse simplement d'être le seul candidat pour cette destination. La longueur du préfixe est le seul levier que la table expose, et pour cette tâche il suffit.

La spécificité écarte aussi le raccourci évident d'exclure un nom de domaine, car la table compare des adresses et un nom peut se résoudre en plusieurs. Résolvez d'abord l'hôte, puis décidez laquelle de ses adresses mérite l'exception.

Pour tout ce qui suit, supposez une connexion nommée Office, une passerelle locale 10.0.0.1 sur l'interface 7, et une destination à 198.51.100.30. Ce sont des valeurs de substitution et non des valeurs par défaut, et les commandes ci-dessus produisent les valeurs que votre machine utilise réellement. Gardez cette note de substitution avec le changement pour que le prochain lecteur ne recopie pas les nombres.

Faites survivre la route à la prochaine reconnexion

Windows n'offre aucune instruction d'exclusion sur une connexion VPN, donc l'exception doit vivre sur l'interface physique, là où l'adaptateur ne la réécrira pas. La cmdlet qui ressemble à la réponse fait l'inverse : Add-VpnConnectionRoute déplace un préfixe dans le tunnel, ce qui est le cas miroir où un profil scindé devrait porter une destination et laisser le reste en local. Y recourir ici garantit que le trafic que vous vouliez garder dehors entre.

La forme manuelle est une seule commande. Sa faiblesse est le changement de réseau et non la reconnexion.

route -p add 198.51.100.30 mask 255.255.255.255 10.0.0.1 metric 1 if 7

Cela survit à un redémarrage grâce à -p et envoie une adresse par l'interface 7 pendant que le tunnel porte tout le reste. Déplacez le portable vers un autre réseau et la passerelle comme l'index deviennent obsolètes, donc l'entrée échoue en silence. Notez à qui elle appartient et quand elle doit être supprimée.

Un script de connexion est la version la plus solide, car il réajoute l'exception après chaque connexion au lieu d'espérer que l'entrée a survécu. Les deux lignes ci-dessous appartiennent à ce qui démarre le tunnel, pas à un script d'ouverture de session.

rasdial Office
route add 198.51.100.30 mask 255.255.255.255 10.0.0.1 metric 1 if 7

Ce qui remonte le tunnel est le bon endroit pour la seconde ligne, et rasdial ne revient qu'une fois la connexion établie, donc la route atterrit derrière les entrées propres à l'adaptateur. Relancez-la après une reprise, car une mise en veille peut faire tomber la route et laisser le tunnel monté. Si la tâche est l'inverse, pousser un seul préfixe dans le tunnel pendant que le reste reste local, alors Add-VpnConnectionRoute est le bon outil.

Le routage ne peut pas choisir un processus

Parfois l'exigence est plus étroite qu'une destination : un programme devrait prendre le chemin local pendant que tout le reste reste dans le tunnel. Le routage ne peut pas l'exprimer, car il compare des adresses et non des processus. Le schéma viable pousse le problème dans le lanceur.

Gardez le profil hors de la route par défaut et démarrez ce seul programme lié à l'adresse de l'interface locale, ainsi l'exception devient la commande de lancement et le tunnel conserve ce qu'il traitait déjà. Rien ne change dans la table de routage, et c'est pourquoi cela survit aux reconnexions. Cela signifie aussi que le tunnel ne doit pas posséder la route par défaut au départ, donc c'est une conception différente et non un correctif sur la précédente.

Sa faiblesse est opérationnelle et non technique. Le programme doit toujours démarrer via l'enveloppe, et si la liaison manque après une reprise, il prend en silence le chemin que la table propose. C'est tolérable pour un navigateur que vous ouvrez exprès et inacceptable pour tout ce qui ne doit jamais quitter le tunnel.

Les connexions par utilisateur ne règlent pas cela non plus. Windows peut restreindre une connexion à un compte alors que la table de routage reste à l'échelle de la machine, donc une connexion liée à un compte et portant une route par défaut redirige encore chaque processus de la machine, y compris les autres sessions. La portée ne devient réelle que lorsque la portée de la route correspond au compte. Deux personnes qui partagent un portable partagent donc une table, et la seconde hérite du tunnel que la première a démarré.

Vérifiez que l'exception a survécu à une reconnexion

Testez le changement tel qu'il échouera : déconnectez, reconnectez, ouvrez une application neuve, puis demandez une adresse qui doit rester locale et une qui doit passer par le tunnel. Comparez les deux avec Find-NetRoute à l'état connecté.

Si le préfixe manque dans la table après une reconnexion, il vit dans le mauvais objet et non dans le mauvais format. Déplacez-le sur l'interface physique et refaites le test. Gardez les deux sorties de commandes avec l'enregistrement de changement, car un instantané de l'état qui fonctionne répond plus tard à plus de questions qu'un paragraphe d'explication. La personne suivante voudra savoir ce que la connexion a produit, pas ce que vous comptiez qu'elle produise.