Le VPN Windows prend tout le trafic ? Supprimez sa route par défaut

Vous vous connectez au VPN du bureau et chaque page du navigateur se met à passer par ce réseau : le serveur de fichiers est rapide, tout le reste est lent, filtré ou absent. Le client ne se comporte pas mal ; le profil a demandé un tunnel complet. L'interrupteur qui l'arrête est une case à cocher dans une boîte de dialogue que l'application Paramètres moderne n'affiche pas, et la passerelle reprend la parole à chaque connexion. Cette procédure suit l'ordre que l'interface Windows présente réellement, puis couvre les vérifications qui échouent encore quand la table de routage semble correcte.

Commencez dans les propriétés de la carte, pas dans Paramètres

L'application Paramètres liste le profil sous Réseau et Internet, puis VPN, mais n'expose que des options générales. La décision de la passerelle par défaut vit sur la carte. Ouvrez la liste classique des cartes avec Win+R et ncpa.cpl, faites un clic droit sur la connexion VPN, choisissez Propriétés, sélectionnez Protocole Internet version 4, choisissez de nouveau Propriétés, puis Avancé. Décochez Utiliser la passerelle par défaut sur le réseau distant et confirmez la sortie des trois boîtes de dialogue.

Reconnectez-vous avant de tester, car la case s'applique à l'établissement du tunnel et une session existante conserve la table qu'elle a construite. Si la carte manque alors que le client est déconnecté, connectez-vous une fois et rouvrez la fenêtre. Un client éditeur qui installe une carte TAP ou Wintun sans page de propriétés IPv4 n'a pas du tout cette boîte de dialogue ; pour ceux-là, la même décision est une option de tunneling divisé dans les réglages du client, et la case de la carte est le mauvais endroit où chercher.

Le même changement depuis PowerShell

Pour un profil créé dans le magasin VPN de Windows, le réglage est scriptable, ce qui est ce que vous voulez si la machine est souvent réinstallée :

Set-VpnConnection -Name "Office" -SplitTunneling $true
Get-VpnConnection -Name "Office" | Select-Object Name,SplitTunneling

Cette cmdlet n'atteint que les profils de ce magasin. Une connexion ajoutée par un client tiers n'apparaîtra pas, et la commande échoue avec une erreur de nom qui ressemble à une faute de frappe. Notez aussi ce que l'interrupteur ne fait pas : il empêche le client d'installer une route par défaut, mais il ne supprime pas les routes que la passerelle pousse à la connexion, donc la section suivante reste nécessaire sur de nombreux réseaux.

Quand la passerelle repousse la route par défaut

Lisez d'abord la table. Deux entrées par défaut avec des métriques différentes signifient que le changement de profil a fonctionné et que la route poussée l'a quand même remplacé :

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-NetAdapter | Select-Object Name,ifIndex

Supprimez la route par défaut qui appartient au tunnel et gardez la physique. Utilisez l'index d'interface de la troisième commande, pas l'alias de la carte, car les scripts qui passent un alias cassent dès que le nom d'affichage change :

Remove-NetRoute -DestinationPrefix 0.0.0.0/0 -InterfaceIndex 21 -Confirm:$false
route delete 0.0.0.0 10.8.0.1

La suppression emporte le bureau avec elle, alors rajoutez les préfixes d'entreprise via la passerelle du tunnel. C'est la ligne que les gens sautent, et c'est pourquoi « le VPN a cessé de fonctionner » suit un changement de tunneling divisé réussi :

route add 10.0.0.0 mask 255.0.0.0 10.8.0.1 metric 5 if 21

Rien de tout cela ne survit à une reconnexion, ce qui est un comportement honnête et non un bug : la carte est reconstruite et le client réapplique ce sur quoi le profil et la passerelle se sont accordés. Si la route par défaut réapparaît à chaque fois, la passerelle est configurée pour refuser le tunneling divisé et continuera de la pousser, ou coupera la session. C'est la politique de l'opérateur du réseau, et la demande appartient là-bas, pas à un script local qui se bat contre elle une fois par connexion.

Revérifiez DNS, IPv6 et les métriques après une reconnexion

Supprimer une route par défaut IPv4 ne prouve rien sur l'autre famille ni sur la résolution de noms. Un tunnel peut transporter IPv6 pendant que la route par défaut IPv4 reste locale, et une liste de résolveurs poussée peut maintenir les noms internes en marche pendant que les requêtes qui l'utilisent passent par un autre chemin. Vérifiez les trois avant de considérer que c'est fait :

Get-NetRoute -DestinationPrefix ::/0
Get-DnsClientServerAddress -InterfaceAlias "Office"
Get-DnsClientNrptPolicy

Si l'état revient à chaque connexion, déplacez les commandes dans une action par connexion au lieu d'éditer la table à la main : une tâche planifiée déclenchée par l'événement de connexion, ou le réglage de tunneling divisé du client quand il en a un. Gardez l'index d'interface dans une variable et recherchez-le à l'exécution, car il peut changer lorsque des cartes sont ajoutées ou retirées.

Décidez de ce que vous avez abandonné

Le trafic Internet local n'est plus inspecté ni filtré par le bureau, et tout ce qui n'est publié que par le tunnel a désormais besoin de sa propre route. Certaines organisations considèrent le tunneling divisé comme une violation de politique, alors confirmez-le avant de modifier un appareil géré ; une route par défaut poussée est parfois le mécanisme d'application et non un accident. La documentation de Set-VpnConnection liste le paramètre de tunneling divisé et les types de profil auxquels il s'applique.

Vérifiez ensuite dans un ordre fixe : qui possède la route par défaut, la navigation ordinaire, un hôte d'entreprise par adresse, un nom interne, et les mêmes quatre après une seule reconnexion. Si la navigation fonctionne et que l'hôte d'entreprise échoue, c'est la route de préfixe qui manque, pas la route par défaut que vous avez retirée, et c'est bien moins coûteux à corriger que de reconstruire le profil.