Le tunnel signale qu'il est connecté et le wiki se charge encore. Puis un téléchargement se bloque et le partage sur l'étagère cesse de répondre. Le tunnel a fait son travail, et le profil revendiquait simplement chaque destination.

Windows traite une connexion VPN comme une décision de routage. Tant que cette décision n'est pas resserrée, la machine se comporte comme si elle avait déménagé au bureau.

Pourquoi un tunnel qui fonctionne ressemble à une panne

Un profil autorisé à utiliser la passerelle distante installe une route par défaut à travers le tunnel. Chaque destination qui n'est pas sur le lien local sort alors par le pare-feu du bureau. Les partages locaux cessent de répondre parce que leur trafic voyage désormais vers un autre continent et revient. Rien dans l'état du client ne le reflète.

Les symptômes sont déroutants à dessein. La résolution de noms peut encore fonctionner pendant que le partage expire, ou l'inverse. L'utilisateur signale que le VPN est cassé, le client signale qu'il va bien, et les deux affirmations sont exactes.

La case qui se cache dans la boîte de dialogue IPv4

Le réglage se trouve plusieurs boîtes de dialogue plus loin. Ouvrez ncpa.cpl, faites un clic droit sur la connexion, puis Propriétés IPv4, puis Avancé, et décochez l'option qui permet à la connexion de devenir la passerelle par défaut distante. Cette seule case décide si le profil est un tunnel complet. Tout le reste du profil s'applique toujours.

Comparez route print -4 avant et après la reconnexion. L'entrée 0.0.0.0 qui pointait vers le tunnel devrait avoir disparu, et les préfixes d'entreprise devraient toujours être là.

route print -4 | findstr /c:"0.0.0.0"
Get-VpnConnection -Name 'Work VPN' | Select-Object Name, SplitTunneling, Routes

Changer la métrique de l'interface n'est pas un substitut. Une métrique ne décide qu'entre deux routes par défaut concurrentes, et un client qui réinstalle sa propre route par défaut à chaque connexion gagne cette compétition quel que soit le nombre configuré.

Le préfixe que personne n'a listé

Le tunnel fractionné expose exactement les préfixes enregistrés dans le profil. Un sous-réseau de bureau ajouté après l'écriture du profil reste injoignable alors que le tunnel est parfaitement sain. Le rapport arrive alors comme un serveur cassé plutôt qu'un VPN cassé.

Une route ajoutée à la main couvre le manque jusqu'à ce que l'adresse de la passerelle change. Enregistrer le préfixe dans la connexion est plus solide, car le préfixe suit alors la connexion au lieu d'une adresse devinée.

route -p add 172.20.8.0 mask 255.255.255.0 10.8.0.1
Add-VpnConnectionRoute -ConnectionName 'Work VPN' -DestinationPrefix 172.20.8.0/24
Get-VpnConnection -Name 'Work VPN' | Select-Object -ExpandProperty Routes

Lisez la liste stockée et la table active ensemble. Un préfixe stocké peut exister alors que la table ne le reçoit jamais, ce qui arrive quand un agent de gestion filtre les routes après l'établissement de la connexion. L'inverse se produit aussi, avec une route de registre qui pointe vers un adaptateur hors service. Aucune des deux vues seule ne raconte toute l'histoire.

Prouver le résultat après un redémarrage

Tracez dans les deux sens et résolvez par nom. Une trace publique devrait sortir par le fournisseur, une trace interne devrait entrer dans le tunnel, et un hôte interne devrait répondre par son nom et pas seulement par son adresse.

tracert -4 www.example.com
tracert -4 wiki.corp.example
ping -4 fileserver.corp.example
ping -4 172.20.8.20

Répétez après une déconnexion, une reconnexion et un redémarrage. Un préfixe qui survit à une reconnexion manuelle et disparaît après un redémarrage n'a jamais été stocké dans le profil.

Gardez aussi l'imprimante et le NAS dans le test, car un tunnel fractionné qui coupe les appareils à côté du portable a résolu un problème en en créant un plus petit et plus irritant. La référence Microsoft pour Add-VpnConnectionRoute est l'endroit où vérifier l'orthographe des paramètres par rapport à la version de votre module.

Articles similaires