WSL2 n’atteint pas le sous-réseau VPN : lisez la route de l’hôte

Depuis la distribution, un ping vers un serveur interne expire alors que la même adresse répond depuis Windows. Le VPN est connecté et la route Windows est correcte, donc l’écart est la frontière de WSL. Parcourez le chemin depuis la commande en échec jusqu’à l’interface de l’hôte. Le correctif n’est pas un CIDR fixe dans un fichier de configuration ; c’est lire l’adresse actuelle et l’ajouter là où la distribution peut l’utiliser.

Confirmez où le chemin s’arrête

Lancez le même test des deux côtés : résolvez et connectez-vous à un hôte interne depuis Windows, puis répétez-le dans la distribution. Un succès sous Windows plus un délai d’attente dans la distribution situent la panne entre les deux, pas dans le client VPN ni dans le serveur interne. Faites-le avant de modifier une route, pour que les deux résultats décrivent la même destination.

Dans la distribution, ip -4 addr affiche un adaptateur virtuel avec une adresse de la plage NAT de WSL, et ip route affiche une route par défaut vers la passerelle WSL. Aucune route n’existe pour le préfixe d’entreprise, car l’adaptateur de tunnel de l’hôte n’a pas d’équivalent dans la distribution. La passerelle par défaut mène au NAT de WSL, pas au réseau d’entreprise.

Ajouter la route d’entreprise sans d’abord ajouter une adresse locale sur une liaison joignable produit un délai d’attente ou une erreur de réseau inaccessible. L’adresse est la partie qui rend la route utilisable, alors lisez-la d’abord et traitez la route comme la deuxième étape.

Choisissez le réseau en miroir ou une route scriptée

Le réseau en miroir donne à la distribution les interfaces de l’hôte lui-même, si bien que le tunnel et ses routes apparaissent sans copie. La fonction dépend d’une version récente de Windows et de networkingMode=mirrored dans .wslconfig, et l’activer modifie des comportements sans rapport, comme le transfert de localhost. Traitez-la comme un changement de plateforme, pas comme un réglage de route. Si la version la prend en charge et que les effets secondaires sont acceptables, c’est le chemin le plus court.

L’approche plus étroite conserve le NAT par défaut et copie l’adresse et la route du tunnel dans la distribution à chaque montée du tunnel. Elle fonctionne sur davantage de versions, ne change pas le comportement de localhost et échoue visiblement quand le VPN est coupé. Le coût est un petit script à exécuter à chaque connexion.

Choisissez-en une et écrivez-la. Mélanger une configuration en miroir avec des routes manuelles produit une distribution avec deux chemins vers le même préfixe et sans propriétaire clair pour aucun. Une méthode documentée est plus facile à déboguer que deux à moitié configurées.

Récupérez les détails actuels du tunnel depuis l’hôte

Associez l’adaptateur par adresse MAC plutôt que par nom, car les noms changent avec le client VPN et l’ordre de connexion. Listez les adaptateurs une fois, notez la MAC de l’adaptateur de tunnel, puis interrogez son adresse et son préfixe. La MAC reste avec l’adaptateur virtuel entre les reconnexions, alors que le nom et l’index d’interface non :

powershell.exe 'Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" } | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, PrefixLength'

La passerelle vient de la configuration de l’interface. Récupérez d’abord l’index d’interface, puis lisez le saut suivant. L’index peut changer après un redémarrage ou une réinitialisation d’adaptateur, c’est pourquoi le script doit le lire plutôt que le stocker :

powershell.exe '(Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" }).InterfaceIndex'
powershell.exe '(Get-NetIPConfiguration -InterfaceIndex 27).IPv4DefaultGateway.NextHop'

Faites passer la sortie par tr -d '\r' avant de l’affecter à une variable. PowerShell termine les lignes par un retour chariot, et sans le retrait le dernier champ porte un caractère invisible qui fait échouer une commande de route avec une erreur d’analyse déroutante.

Appliquez l’adresse et la route dans la distribution

Installez l’adresse du tunnel comme adresse qualifiée par préfixe sur l’interface de la distribution, puis routez le bloc d’entreprise via la passerelle de l’hôte :

sudo ip addr add 172.20.14.37/22 dev vpn
sudo ip route add 172.20.0.0/16 via 172.20.12.1 dev vpn

NetworkManager abandonne une adresse configurée manuellement lorsque la connexion redémarre, et aucun client DHCP n’en demande un remplacement. Passez la méthode en automatique pour que chaque reconnexion rafraîchisse l’adresse, puis remontez la connexion. Une méthode manuelle semble stable jusqu’à la première reconnexion :

nmcli con show vpn
sudo nmcli con mod vpn ipv4.method auto
sudo nmcli con up vpn

Exécutez les deux étapes depuis le hook qui démarre le VPN, pas depuis un shell interactif. Un script qui lit l’adresse, l’ajoute, ajoute la route et journalise les valeurs transforme une réparation manuelle récurrente en réparation répétable, et le journal est la première chose à lire quand le préfixe change.

Fixez le nom et prouvez le chemin

Le noyau peut renommer l’interface de la distribution entre eth1 et eth2 après un changement de réseau, et un script écrit pour un nom modifie alors le mauvais périphérique. Une règle udev liée à la MAC donne à l’interface une étiquette stable :

SUBSYSTEM=="net", ACTION=="add", ATTRS{address}=="3c:52:82:0a:1b:7c", NAME="vpn"

Vérifiez ensuite avec l’adresse, la route et une vraie connexion TCP : ip -4 addr show dev vpn, ip route get 172.20.4.10 et une connexion vers un port interne connu. La recherche de route devrait nommer le périphérique vpn et l’adresse source que vous avez ajoutée.

Si les trois passent dans la distribution et que la connexion échoue encore, le paquet quitte WSL et est abandonné côté Windows. Vérifiez le pare-feu de l’hôte et le filtrage propre au client VPN avant de modifier le script, car une autre modification de route ne corrigera pas un paquet qui atteint déjà l’hôte.