Comment vérifier ce qu'un VPN sous Windows achemine réellement dans PowerShell

J'ai connecté le client VPN sur un portable Windows 11, la vignette est passée à Connecté, un partage de fichiers interne s'est ouvert, et un site public se chargeait toujours directement depuis le Wi-Fi du bureau. Ce mélange ressemble à un tunnel cassé. C'est pourtant la sortie normale d'un profil qui envoie une partie du trafic par le VPN et laisse le reste sur l'adaptateur physique. Le tunnel forcé change la route par défaut que Windows préfère ; il ne supprime pas les routes plus spécifiques et ne promet pas que le trafic s'arrête quand la connexion tombe. Voici l'ordre que je suis quand un client affirme avoir une couverture : état du client, profil enregistré, routes appliquées, résolveur, puis flux réels.

Commencez par le client, puis cessez de lui faire confiance

Le client est le bon point de départ uniquement parce qu'il vous dit quel profil est actif. Ouvrez les propriétés de la connexion et notez le nom exact du profil, s'il a été créé pour l'utilisateur actuel ou pour tout le monde sur la machine, et quel adaptateur apparaît dans ncpa.cpl après la connexion. Sur mon portable de test, l'adaptateur portait le nom du profil, ce qui rendait la sortie des routes facile à lire. Sur d'autres machines, il apparaît comme une entrée WAN Miniport et le nom ne vous dit rien.

Ce que le client ne peut pas vous dire, c'est la couverture. Une vignette connectée décrit l'état du tunnel, pas un inventaire des destinations. Les clients tiers gardent aussi leur propre configuration, donc le profil natif de Windows, et chaque propriété que vous allez y lire, peuvent n'avoir aucun rapport avec ce que ce client a installé. Si le VPN est arrivé via AnyConnect, OpenVPN GUI, WireGuard ou un agent fournisseur, les vérifications PowerShell ci-dessous ne s'appliquent généralement pas et vous devriez plutôt lire les réglages de tunnel divisé et de routage propres à ce client.

Lisez le profil enregistré, pas la vignette

Pour un profil natif Windows (IKEv2, L2TP, SSTP ou un profil poussé par MDM), la décision de tunnel divisé enregistrée est une seule propriété :

Get-VpnConnection -Name 'Office' | Select-Object Name, ServerAddress, SplitTunneling, DnsSuffix

Ajoutez -AllUserConnection quand le profil a été créé pour tout le monde sur l'appareil. Sans cela, vous lisez la liste de l'utilisateur actuel, qui peut être vide ou contenir une autre entrée au nom similaire. Une valeur False dans SplitTunneling signifie que le profil a été enregistré comme tunnel complet : Windows installe une route par défaut via l'adaptateur VPN. True signifie tunnel divisé, et la couverture dépend alors entièrement des routes et des règles de résolution de noms que ce profil pousse.

Traitez cette valeur comme une configuration, pas comme une observation. Elle enregistre ce que le profil a demandé au moment de la connexion. Windows peut finir avec des routes appliquées différentes, à cause d'une route plus spécifique d'une autre interface, d'un paramètre de stratégie ou d'une entrée résiduelle d'une connexion précédente, donc le booléen ne tranche jamais la question à lui seul.

Comparez la valeur enregistrée avec la table de routage appliquée

Après la connexion, listez les routes de l'adaptateur du tunnel au lieu de parcourir toute la table :

$vpn = Get-NetAdapter | Where-Object InterfaceDescription -match 'VPN|WAN Miniport'
Get-NetRoute -InterfaceIndex $vpn.ifIndex | Sort-Object DestinationPrefix
Find-NetRoute -RemoteIPAddress 10.20.4.15 | Select-Object -First 1

Find-NetRoute est la moitié utile. Il répond à la question que le client ne répond jamais : pour cette destination, quelle interface et quelle adresse source Windows utilisera-t-il réellement ? Exécutez-le pour un hôte interne, un hôte public et tout ce que vous considérez comme une exception délibérée. Un profil de tunnel complet devrait afficher l'interface du tunnel pour l'adresse publique. Un profil de tunnel divisé y affiche généralement l'adaptateur physique tandis que les préfixes internes se résolvent toujours vers le VPN.

Deux pièges expliquent la plupart des rapports « il route dans le mauvais sens ». Le préfixe le plus spécifique gagne toujours, donc un /24 sur l'adaptateur physique bat une route par défaut sur le VPN, quelle que soit la métrique du tunnel. La métrique ne départage que les routes de même préfixe. Et IPv4 et IPv6 sont décidés séparément : un profil qui couvre 0.0.0.0/0 peut laisser IPv6 sur le lien local, ce qui fait qu'un site double pile semble à moitié tunnelisé. Vérifiez Get-NetRoute -AddressFamily IPv6 avant de conclure que le tunnel est correct.

Vérifiez la résolution de noms séparément avec NRPT

Les noms internes qui échouent alors que les adresses IP internes fonctionnent pointent vers la stratégie du résolveur, pas vers le routage. Windows décide du DNS par espace de noms via la table de stratégie de résolution de noms, indépendante de la table de routage :

Get-DnsClientNrptPolicy -Effective | Select-Object Namespace, NameServers
Get-DnsClientServerAddress -InterfaceIndex $vpn.ifIndex

Quand une règle correspond à *.corp.example, les requêtes pour cet espace de noms vont aux serveurs DNS du tunnel même si le chemin de données vers ces serveurs reste sur l'adaptateur physique en mode tunnel divisé. C'est la conception, et c'est pourquoi un test de navigateur qui ouvre un site public ne vous dit rien sur les noms internes. Si l'adaptateur liste les serveurs attendus mais que les recherches vont ailleurs, comparez l'ordre des règles NRPT et vérifiez si un espace de noms plus spécifique correspond en premier.

Vérifiez les flux, puis décidez ce que vous avez réellement demandé

Parcourez les destinations dans un ordre fixe pour que les résultats soient comparables d'une machine à l'autre : une adresse publique, une adresse interne, un nom interne et une exception délibérée comme une imprimante locale ou un appel vidéo. Notez l'interface et l'adresse source que Find-NetRoute renvoie pour chacune. Après tout changement de stratégie, reconnectez-vous et répétez les mêmes quatre vérifications ; la table de routage après reconnexion est la seule preuve que le nouveau profil a pris effet.

Séparez ensuite le routage de l'application forcée. Le tunnel forcé préfère le tunnel pour le trafic couvert tant qu'il est actif. Ce n'est pas un interrupteur d'urgence. Si l'exigence est que rien ne quitte la machine quand le tunnel tombe, cela doit venir d'une conception bloquante : un profil de pare-feu lié à l'état du tunnel, un profil toujours actif avec des filtres de trafic ou l'option propre de fermeture en cas d'échec du client fournisseur. Le tunnel forcé doit aussi laisser l'adresse du serveur VPN lui-même accessible hors du tunnel, et la bloquer au nom de « tout forcer » est un moyen fiable de vous verrouiller hors de la connexion que vous cherchez à appliquer.

Avant de changer quoi que ce soit, parcourez cette liste. Chaque élément qui échoue précise où se situe le vrai problème.

• Nom et portée du profil confirmés, avec -AllUserConnection pour les profils à l'échelle de la machine.
• SplitTunneling lu et traité comme une configuration plutôt qu'une preuve de couverture.
• Routes de l'adaptateur du tunnel listées séparément pour IPv4 et IPv6.
• Find-NetRoute exécuté pour une destination publique, une interne et une exception.
• Règles NRPT vérifiées avant d'accuser les routes d'un échec de nom.
• Exigence de blocage relue : le routage préféré n'est pas la même chose que le blocage appliqué.

La décision de tunnel complet ou divisé appartient à celui qui possède le profil, et les notes de routage de Microsoft décrivent le comportement que Windows met en œuvre quand un profil le définit. Microsoft : tunnel forcé et divisé est la référence que je garde ouverte en lisant la sortie.