Vous partagez une connexion Windows ? Le chemin du VPN change en dessous

Un ordinateur portable partage son Wi-Fi, l’hôte navigue par le tunnel sans se plaindre, et la tablette de ce partage n’atteint rien. L’hôte a cessé d’être seulement un client au moment où le partage a été activé : il est désormais un routeur, et les paquets transférés rencontrent un autre jeu de règles. Ce qui fonctionne sur l’hôte ne dit rien de l’appareil derrière lui. Lancez les vérifications depuis le client en aval et la distinction cesse d’être théorique.

Le succès de l’hôte ne prouve rien

Le partage de connexion confie quatre tâches à une seule machine : attribution d’adresses, transfert, traduction et filtrage. Un client VPN qui protège le trafic généré localement peut considérer le trafic transféré hors de son périmètre, ou le bloquer exprès comme une fuite. Aucun des deux comportements n’est un défaut, et aucun n’est écrit sur l’écran où le partage a été activé. Seul le test en aval vous dit lequel vous avez.

Beaucoup de clients ne transfèrent que le trafic de l’hôte et rien d’autre, alors consultez la section partage de la documentation du client au lieu de croire que le tunnel va router pour la tablette. Le symptôme visible est un appareil qui s’associe, reçoit une adresse, puis échoue à la première requête. Un client qui refuse de transférer paraît toujours parfaitement sain sur l’hôte.

Quel adaptateur est partagé, lequel sert les clients

Notez les deux adaptateurs, car ils portent des adresses et des filtres différents, et un changement sur le mauvais explique beaucoup de résultats déroutants. L’hôte du partage prend normalement une adresse fixe du côté aval et y exécute un petit service DHCP et DNS. Windows conserve le transfert par adaptateur plutôt que globalement, donc l’état doit se lire interface par interface.

Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name,InterfaceIndex,LinkSpeed
Get-NetIPAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,IPAddress,PrefixLength
Get-NetIPInterface | Select-Object InterfaceAlias,Forwarding,ConnectionState
Get-NetConnectionProfile

Si le transfert apparaît comme Désactivé sur l’adaptateur partagé, rien en aval ne fonctionnera quoi que fasse le tunnel. Activez-le uniquement sur une machine dont la politique l’autorise à router pour d’autres appareils.

Transfert, traduction et filtrage

Un paquet transféré doit atteindre le tunnel, être traduit en quelque chose que le côté distant accepte et revenir par la même traduction. Chacune de ces trois étapes peut casser, et chaque casse produit le même délai d’attente du navigateur. Une capture de paquets, une recherche de route et un journal du côté distant valent plus qu’une nouvelle relecture de la boîte de dialogue de partage. C’est l’étape qui échoue qui vous dit de qui vient le changement nécessaire.

Le côté distant peut aussi avoir besoin d’une route de retour pour le sous-réseau partagé, une plage que le serveur VPN n’a jamais vue. Là où le client traduit, le serveur ne voit que l’adresse du tunnel et aucune route de retour n’est nécessaire. Là où il ne traduit pas, celui qui possède la passerelle doit ajouter cette route délibérément, et c’est une demande de changement, pas un réglage du client.

Faites les vérifications sur le client, pas sur l’hôte

Faites chaque vérification sur le client qui échoue, pas sur l’hôte qui fonctionne. Gardez l’adresse de sortie, la réponse du résolveur et le test applicatif dans la même session, car des résultats collectés à une heure d’intervalle ne disent rien de la façon dont les trois se combinent.

Resolve-DnsName intranet.example.net -Type A
Resolve-DnsName intranet.example.net -Type AAAA
Invoke-RestMethod https://api.ipify.org
Test-NetConnection intranet.example.net -Port 443 -InformationLevel Detailed

Comparez l’adresse de sortie avec celle de l’hôte et notez si les deux concordent. Une réponse différente signifie que le chemin transféré contourne le tunnel, ce qui est une question de politique avec un responsable et non un correctif rapide. Une réponse identique à côté d’une application en échec déplace le travail vers la résolution de noms ou vers la politique du côté distant. N’arrêtez pas non plus au résultat IPv4 : un partage peut passer toutes les vérifications IPv4 tandis qu’IPv6 sort par une autre sortie, alors répétez les vérifications de noms et de sortie avec l’enregistrement AAAA et le test de connexion détaillé.

Sur une machine gérée, confirmez que le partage est autorisé, car exposer l’accès à un autre appareil est une décision administrative et non un interrupteur de confort. Après tout changement pris en charge, répétez les vérifications à la reconnexion et de nouveau pendant une panne. Une reconnexion propre de l’hôte ne restaure pas une route transférée que le client n’a jamais prise en charge.