WSL2 + VPN : pourquoi ça casse (et comment réparer)

Le modèle mental : pourquoi WSL2 et les VPN entrent en collision

WSL2 n’est pas une couche de compatibilité au sens ancien. C’est une VM légère avec un vrai noyau Linux.
Du point de vue réseau, elle se comporte comme une machine située derrière une petite passerelle NAT implémentée par Windows.
Votre distribution Linux reçoit une adresse dans une plage privée (typiquement 172.16.0.0/12 ou 192.168.0.0/16-style),
et Windows fait la traduction et le transfert.

Les clients VPN, quant à eux, sont professionnellement intrusifs. Ils installent des adaptateurs virtuels, injectent des routes,
remplacent le DNS, appliquent des politiques et parfois bloquent volontairement les chemins de transit « non corporatifs ».
Le VPN part du principe qu’il gère une pile réseau unique. WSL2 est une seconde pile derrière lui.
Vous avez maintenant deux domaines de routage et au moins trois endroits où le DNS peut être « utilement » réécrit :
Windows, le client VPN et le /etc/resolv.conf auto-généré de WSL.

Où vont réellement les paquets

Lorsqu’un processus dans WSL2 se connecte à git.internal.corp, il fait :

• L’application Linux interroge le résolveur Linux pour le DNS.
• Le résolveur Linux consulte /etc/resolv.conf (souvent pointant vers une IP résolveur côté Windows).
• Le trafic quitte la VM WSL vers l’hôte Windows via le switch virtuel WSL.
• Windows décide quelle interface/route l’emporte : adaptateur VPN, Wi‑Fi/Ethernet, ou « non ».
• Le client VPN peut NATer, chiffrer ou bloquer le transfert selon la politique.

La panne tombe généralement dans l’une des quatre catégories : routage, DNS, MTU/fragmentation, ou politique/pare‑feu.
Vous pouvez corriger les quatre, mais il faut arrêter de deviner dans quel panier vous êtes.

Blague n°1 : les clients VPN sont comme des chats — indépendants, territoriaux et convaincus qu’ils sont la seule chose importante dans la maison.

La vérité inconfortable

Certaines politiques VPN rendent intentionnellement WSL2 difficile. Pas parce que WSL2 est malveillant, mais parce que c’est effectivement une seconde machine.
Les équipes sécurité craignent des environnements Linux non gérés qui se propagent dans les réseaux internes.
Donc le « correctif » peut ne pas être un réglage ; il peut être « demandez à votre équipe VPN d’autoriser » ou « utilisez une VM de dev sanctionnée ».
Pourtant, dans beaucoup d’entreprises, c’est juste des mauvaises configurations et des valeurs par défaut qui s’affrontent.

Playbook de diagnostic rapide (vérifier 1/2/3)

Quand WSL2 + VPN casse, ne commencez pas par réinstaller WSL ou changer dix réglages d’un coup.
Faites ce qui suit dans l’ordre. Chaque étape réduit le domaine du bug.

1) Est-ce le DNS ou le routage ?

• Si ping 10.x.x.x fonctionne mais ping git.internal.corp ne fonctionne pas, c’est le DNS.
• Si le DNS résout vers la bonne IP mais que le TCP ne peut pas se connecter, c’est le routage/pare‑feu/MTU.
• Si seuls certains sous‑réseaux internes fonctionnent, c’est l’injection de routes en split tunnel.

2) Comparez le comportement Windows vs WSL

• Si Windows peut atteindre les ressources internes mais pas WSL, le problème vient de la frontière NAT/forwarding ou du transfert DNS.
• Si Windows ne peut pas non plus les atteindre, arrêtez de blâmer WSL. Corrigez d’abord la connexion VPN, les routes ou le DNS d’entreprise.

3) Identifiez l’interface qui doit l’emporter

• Tunnel complet : la route par défaut doit passer par le VPN. Le DNS doit être corporatif.
• Split tunnel : seuls des préfixes internes spécifiques passent par le VPN ; la route par défaut reste sur l’internet local.
• Dans les deux cas : le trafic WSL doit être autorisé à traverser Windows vers cette interface.

4) Vérifiez le MTU en dernier (mais n’oubliez pas)

Les problèmes MTU ressemblent à « le DNS fonctionne, ping fonctionne, HTTPS se bloque » ou « petites requêtes OK, grosses bloquées ».
Si vous voyez ce schéma, testez le MTU avant de perdre une heure à discuter des tables de routage.

Faits et historique : pourquoi c’est un problème récurrent

• WSL1 et WSL2 ont des réseaux fondamentalement différents. WSL1 partageait la pile Windows ; WSL2 est NATé derrière une VM.
• WSL2 utilise un switch virtuel Hyper‑V sous le capot. Même sur Windows Home, la plomberie se comporte comme un mini‑Hyper‑V.
• Beaucoup de clients VPN fournissent encore des pilotes noyau. Ils s’accrochent profondément au réseau Windows pour appliquer politiques et routes.
• La « split horizon » DNS est courante dans les entreprises. Un même nom peut résoudre différemment selon que vous êtes dans le VPN ou non, rendant les résolveurs obsolètes catastrophiques.
• NRPT et DNS par interface sont spécifiques à Windows. Windows peut envoyer des requêtes DNS différentes selon les règles de domaine ; Linux le fait rarement sans configuration.
• La douleur MTU est antérieure à WSL. L’encapsulation VPN réduit le MTU effectif, et PMTUD reste fragile dans les réseaux réels.
• La priorité des routes par défaut n’est pas universelle. Les métriques de route Windows et les réglages « force tunnel » du VPN surprennent souvent les gens venant de Linux.
• Les baselines de sécurité d’entreprise bloquent souvent le forwarding IP. Même si Windows peut atteindre le VPN, il peut refuser d’acheminer le trafic depuis une NIC « virtuelle ».
• L’accès localhost WSL2 a évolué dans le temps. Les builds Windows récentes ont amélioré le forwarding localhost entre Windows et WSL, mais les VPN peuvent toujours interférer.

Modes de panne cartographiés aux causes profondes

Mode de panne A : « Le DNS est cassé dans WSL, mais Windows va bien »

Le plus courant. WSL auto‑génère /etc/resolv.conf pointant vers une IP résolveur côté Windows.
Quand vous connectez le VPN, les serveurs DNS Windows changent. WSL ne met pas toujours à jour proprement, ou il se met à un résolveur qui ne peut pas atteindre
le DNS d’entreprise à cause du binding d’interface.

Mode de panne B : « Les IP internes expirent depuis WSL, mais se résolvent correctement »

C’est typiquement du routage ou de la politique. Windows peut router vers le sous‑réseau interne via l’adaptateur VPN,
mais le trafic WSL peut ne pas être autorisé à emprunter ce chemin (pare‑feu, politique du client VPN, ou route de retour manquante).

Mode de panne C : « Split tunnel : un sous‑réseau marche, un autre non »

Le split tunneling repose sur l’injection de nombreux préfixes internes. Certains clients VPN poussent ces routes seulement vers Windows et partent du principe que seuls les processus locaux sont la source.
Le trafic WSL peut utiliser une plage d’adresse source différente (la plage NAT WSL), et le côté corporate peut ne pas avoir de route de retour.

Mode de panne D : « HTTPS se bloque, git clone se fige, mais ping fonctionne »

MTU / fragmentation. L’encapsulation réduit le MTU ; certains chemins laissent tomber les messages ICMP « fragmentation nécessaire » ; TCP devient muet.
C’est ennuyeux, ancien, et ça brûle encore des équipes chaque semaine.

Mode de panne E : « Tout fonctionne jusqu’à la mise en veille/reprise »

La reprise change souvent l’ordre des interfaces, les métriques de route, ou l’état interne du client VPN.
WSL continue de tourner, gardant d’anciennes configurations DNS ou routes, tandis que Windows a évolué.

Tâches pratiques : commandes, sorties et décisions (12+)

Ces tâches sont conçues pour être exécutées exactement lorsque les choses sont cassées. Chacune vous dit quelque chose de spécifique,
et vous indique la suite. Exécutez les vérifications côté Windows et côté WSL ; le delta est l’indice.

Task 1 (WSL) : Quelle IP et quelle passerelle par défaut ai‑je ?

cr0x@server:~$ ip -br addr
lo               UNKNOWN        127.0.0.1/8 ::1/128
eth0             UP             172.26.112.45/20

cr0x@server:~$ ip route show
default via 172.26.112.1 dev eth0
172.26.112.0/20 dev eth0 proto kernel scope link src 172.26.112.45

Ce que ça signifie : WSL est sur 172.26.112.0/20 et utilise 172.26.112.1 comme passerelle (NAT Windows).
Décision : Si la passerelle manque ou que l’interface est DOWN, votre réseau WSL est cassé avant même l’entrée du VPN.
Redémarrez WSL (wsl --shutdown depuis Windows) et réessayez.

Task 2 (WSL) : Le DNS pointe-t-il quelque part de raisonnable ?

cr0x@server:~$ cat /etc/resolv.conf
# This file was automatically generated by WSL. To stop automatic generation of this file, add the following entry to /etc/wsl.conf:
# [network]
# generateResolvConf = false
nameserver 172.26.112.1

Ce que ça signifie : WSL utilise la passerelle Windows comme proxy/résolveur DNS.
Décision : Si le DNS d’entreprise échoue, c’est votre premier suspect. Soit le résolveur Windows est incorrect pour l’état VPN,
soit WSL est bloqué avec un DNS obsolète. Passez aux Tasks 3 et 4.

Task 3 (WSL) : Puis‑je résoudre un nom interne, et quel serveur a répondu ?

cr0x@server:~$ resolvectl status 2>/dev/null | sed -n '1,120p'
Global
       Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: foreign
Current DNS Server: 172.26.112.1
       DNS Servers: 172.26.112.1

Ce que ça signifie : Votre résolveur est la passerelle WSL. Ça peut marcher, mais seulement si Windows relaie correctement les requêtes.
Décision : Si les domaines internes ne se résolvent pas, testez le DNS direct vers les serveurs d’entreprise ensuite (Task 4) pour séparer « résolveur WSL » de « portée DNS ».

Task 4 (WSL) : Interroger le DNS d’entreprise directement (contourner le proxy)

cr0x@server:~$ dig @10.20.30.40 git.internal.corp +time=2 +tries=1

; <<>> DiG 9.18.24-1ubuntu1.3-Ubuntu <<>> @10.20.30.40 git.internal.corp +time=2 +tries=1
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached

Ce que ça signifie : WSL ne peut pas atteindre directement le serveur DNS d’entreprise.
Décision : C’est du routage/politique, pas un simple fichier de résolveur. Allez aux Tasks 6 (routage) et 10 (indices pare‑feu/politique).

Task 5 (Windows dans le shell WSL) : Puis‑je comparer rapidement avec Windows DNS ?

cr0x@server:~$ powershell.exe -NoProfile -Command "Resolve-DnsName git.internal.corp | Select-Object -First 1"
Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
git.internal.corp                              A      60    Answer     10.50.12.34

Ce que ça signifie : Windows peut résoudre le nom.
Décision : Vous savez maintenant : le DNS marche sur Windows, mais WSL ne peut pas l’utiliser. Le correctif est généralement l’intégration DNS WSL (voir section correctifs : « pin resolv.conf » ou « utiliser systemd-resolved correctement »).

Task 6 (WSL) : Quelle route utiliserais‑je pour atteindre une IP interne ?

cr0x@server:~$ ip route get 10.50.12.34
10.50.12.34 via 172.26.112.1 dev eth0 src 172.26.112.45 uid 1000

Ce que ça signifie : WSL enverra le trafic interne vers la passerelle Windows. C’est attendu.
Décision : Si Windows ne la relaye pas ensuite, vous avez un problème de routage/politique/pare‑feu Windows ou un client VPN qui bloque le transit depuis la vNIC de WSL.

Task 7 (WSL) : Puis‑je atteindre l’IP interne du tout ?

cr0x@server:~$ ping -c 2 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 56(84) bytes of data.

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1027ms

Ce que ça signifie : Pas de reachabilité ICMP. Pas définitif (ICMP peut être bloqué), mais c’est un signal fort.
Décision : Essayez la connectivité TCP ensuite. Si le TCP échoue aussi, c’est routage/politique. Si le TCP fonctionne et que ping échoue, c’est seulement une politique ICMP.

Task 8 (WSL) : Tester le TCP sur un port interne connu

cr0x@server:~$ nc -vz -w 2 10.50.12.34 443
nc: connect to 10.50.12.34 port 443 (tcp) timed out: Operation now in progress

Ce que ça signifie : Le TCP ne passe pas.
Décision : Remontez la pile : vérifiez les routes Windows et le comportement de l’adaptateur VPN. Si Windows peut se connecter mais pas WSL, suspectez des restrictions du client VPN sur le forwarding/NAT.

Task 9 (Windows via WSL) : Que pense Windows des routes ?

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetRoute -AddressFamily IPv4 | Sort-Object -Property RouteMetric | Select-Object -First 8"
ifIndex DestinationPrefix NextHop     RouteMetric ifMetric PolicyStore
------- ----------------- -------     ----------- -------- -----------
19      0.0.0.0/0         10.8.0.1    5           25       ActiveStore
3       0.0.0.0/0         192.168.1.1 35          25       ActiveStore
19      10.0.0.0/8        0.0.0.0     5           25       ActiveStore
19      172.16.0.0/12     0.0.0.0     5           25       ActiveStore
19      192.168.0.0/16    0.0.0.0     5           25       ActiveStore
1       127.0.0.0/8       0.0.0.0     256         75       ActiveStore

Ce que ça signifie : Le VPN (ifIndex 19) gagne la route par défaut et les plages RFC1918 internes.
Décision : En tunnel complet, c’est attendu. En split tunnel, cela peut être incorrect et casser l’accès réseau local.
Quoi qu’il en soit, si WSL ne peut pas traverser cela, le client VPN peut bloquer le forwarding ou le pare‑feu Windows filtre la vEthernet de WSL.

Task 10 (Windows via WSL) : Le profil/pare‑feu de vEthernet (WSL) est‑il hostile ?

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetAdapter -Name 'vEthernet (WSL)' | Format-List -Property Name,Status,MacAddress,LinkSpeed"
Name       : vEthernet (WSL)
Status     : Up
MacAddress : 00-15-5D-4A-2B-1C
LinkSpeed  : 10 Gbps

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetConnectionProfile -InterfaceAlias 'vEthernet (WSL)' | Format-List"
Name             : Network
InterfaceAlias   : vEthernet (WSL)
NetworkCategory  : Public
IPv4Connectivity : Internet

Ce que ça signifie : La NIC virtuelle WSL est catégorisée comme Public. Beaucoup de pare‑feux d’entreprise serrent la vis sur les profils Public.
Décision : Si la politique le permet, passez la NIC WSL en Privé. Si la politique ne le permet pas, ajoutez des règles de pare‑feu étroites plutôt que de basculer des profils globalement.

Task 11 (WSL) : Vérifier le MTU et tester la perte de paquets

cr0x@server:~$ ip link show dev eth0 | sed -n '1,3p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:4a:2b:1c brd ff:ff:ff:ff:ff:ff

cr0x@server:~$ ping -c 2 -M do -s 1472 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 1472(1500) bytes of data.
ping: local error: message too long, mtu=1500

cr0x@server:~$ ping -c 2 -M do -s 1360 10.50.12.34
PING 10.50.12.34 (10.50.12.34) 1360(1388) bytes of data.

--- 10.50.12.34 ping statistics ---
2 packets transmitted, 0 received, 100% packet loss, time 1018ms

Ce que ça signifie : Le premier ping montre la logique MTU de votre interface. Le second montre que le chemin échoue encore — donc ce n’est pas seulement « paquets trop gros ».
Décision : Si des tailles plus petites réussissent mais que les plus grandes bloquent, réduisez le MTU (ou MSS) côté WSL ou corrigez PMTUD. Si les deux échouent, revenez au routage/politique.

Task 12 (WSL) : Tracer où les paquets s’arrêtent (basique)

cr0x@server:~$ traceroute -n -w 1 -q 1 10.50.12.34
traceroute to 10.50.12.34 (10.50.12.34), 30 hops max, 60 byte packets
 1  172.26.112.1  0.240 ms
 2  * 
 3  * 
 4  *

Ce que ça signifie : Le trafic atteint la passerelle Windows, puis disparaît. C’est la frontière.
Décision : Arrêtez de bidouiller les routes Linux. Vous devez faire en sorte que Windows+VPN relaient correctement le trafic, ou ajuster la posture VPN pour supporter WSL.

Task 13 (WSL) : Voir si un proxy est attendu (fréquent dans les VPN d’entreprise)

cr0x@server:~$ env | grep -iE 'http_proxy|https_proxy|no_proxy'
https_proxy=http://proxy.internal.corp:8080
http_proxy=http://proxy.internal.corp:8080
no_proxy=localhost,127.0.0.1,.internal.corp

Ce que ça signifie : Votre environnement attend un proxy HTTP.
Décision : Si le TCP direct vers les endpoints internes échoue mais que l’accès via proxy fonctionne sur Windows, vous devrez homogénéiser les variables de proxy dans WSL (ou utiliser une solution PAC via Windows). Assurez‑vous aussi que no_proxy inclut les domaines internes qui ne doivent pas passer par le proxy.

Task 14 (WSL) : Confirmer ce que git essaie réellement de faire

cr0x@server:~$ GIT_CURL_VERBOSE=1 GIT_TRACE=1 git ls-remote https://git.internal.corp/team/repo 2>&1 | sed -n '1,40p'
20:17:14.123456 git.c:460               trace: built-in: git ls-remote https://git.internal.corp/team/repo
20:17:14.130000 http.c:725              == Info:   Trying 10.50.12.34:443...
20:17:14.132000 http.c:725              == Info: connect to 10.50.12.34 port 443 failed: Connection timed out
fatal: unable to access 'https://git.internal.corp/team/repo/': Failed to connect to git.internal.corp port 443 after 2002 ms: Timeout was reached

Ce que ça signifie : La résolution a réussi ; la connexion a expiré.
Décision : Ne touchez pas au DNS. Corrigez le routage/forwarding/politique ou utilisez le proxy d’entreprise si requis.

Schémas de correction qui tiennent la route

Il existe des dizaines de « correctifs » sur les forums pour WSL2+VPN. La moitié sont du cargo cult. Un quart violent les politiques de sécurité.
Le reste peut être rendu fiable si vous choisissez le bon schéma pour votre environnement : tunnel complet, split tunnel, proxy‑only, ou « le client VPN l’interdit ».

Schéma 1 : Stabiliser le DNS dans WSL (arrêter de courir après des cibles mouvantes)

Si Windows résout les noms internes mais pas WSL, vous voulez généralement que WSL utilise directement les serveurs DNS d’entreprise,
ou qu’il utilise un forwardeur local stable qui suit réellement l’état du VPN.

Option A : Épingler resolv.conf (simple, brutal, efficace)

Désactivez la génération automatique et placez des serveurs DNS explicites.
Cela marche mieux lorsque les IP DNS d’entreprise sont stables pendant la connexion VPN.

cr0x@server:~$ sudo tee /etc/wsl.conf >/dev/null <<'EOF'
[network]
generateResolvConf = false
EOF

cr0x@server:~$ sudo rm -f /etc/resolv.conf
cr0x@server:~$ sudo tee /etc/resolv.conf >/dev/null <<'EOF'
nameserver 10.20.30.40
nameserver 10.20.30.41
search internal.corp
options timeout:2 attempts:2
EOF

Ce que la sortie signifie : Pas de sortie attendue ; vous écrivez des fichiers.
Décision : Redémarrez WSL (wsl --shutdown) pour que la configuration soit prise en compte. Si cela règle la résolution interne mais casse le DNS public hors VPN,
il vous faudra un DNS conditionnel ou un résolveur qui bascule avec le VPN.

Option B : Utiliser systemd-resolved correctement (moins brutal, plus propre)

Sur les builds WSL récentes, systemd peut être activé. Quand il fonctionne, il vous fournit un vrai démon résolveur,
et vous pouvez le configurer vers des serveurs DNS avec mise en cache et comportement de secours approprié.
L’astuce : il faut garder la story DNS Windows/VPN cohérente, sinon vous échouez plus vite.

Si vous n’utilisez pas déjà systemd dans WSL, ne l’activez pas uniquement pour corriger le DNS VPN à moins de pouvoir supporter ce changement.
C’est bien. C’est aussi une pièce additionnelle à gérer. Règle de production : ajoutez de la complexité seulement si elle apporte de la stabilité.

Schéma 2 : Réalité du split tunnel (les routes doivent exister dans les deux sens)

Le split tunnel est l’endroit où l’optimisme meurt. Votre machine Windows reçoit des routes vers 10.0.0.0/8 et consorts via le VPN.
WSL envoie des paquets à la passerelle Windows. Windows les forwarde dans le VPN. Super.
Puis le côté corporate reçoit des paquets dont la source est 172.26.112.45 (la plage NAT de WSL) et ne sait pas comment répondre.

En tunnel complet, cela fonctionne souvent « par accident » parce que le client VPN NATe le trafic sortant et le fait apparaître comme provenant de l’IP VPN de l’hôte Windows.
En split tunnel, le comportement NAT varie énormément. Certains clients NATent, d’autres non, certains le font seulement pour les processus Windows, et certains refusent pour les « adaptateurs virtuels ».

Vos options de correction :

• Meilleur : le client VPN supporte le NAT/forwarding pour le trafic WSL (ou est configuré pour le faire).
• Également valide : le réseau corporate a des routes de retour vers le sous‑réseau NAT WSL (rare ; nécessite l’adhésion de l’équipe réseau).
• Contournement : utilisez un proxy/serveur saut/bastion que Windows peut atteindre, et tunnelisez depuis WSL via ce chemin unique autorisé.

Schéma 3 : Faire en sorte que le pare‑feu Windows cesse de saboter la vEthernet (WSL)

Si l’adaptateur WSL est « Public » et que votre pare‑feu d’entreprise est strict, le trafic WSL peut être bloqué pour atteindre l’adaptateur VPN.
C’est courant sur les laptops durcis.

Si vous êtes autorisé, définissez le NIC virtuel WSL en profil Privé. Si ce n’est pas autorisé, ajoutez des règles de pare‑feu étroites.
Votre équipe sécurité appréciera des règles « étroites et auditables » plutôt que « j’ai togglé des trucs au hasard jusqu’à ce que ça marche ».

Schéma 4 : Corriger le MTU (ou MSS) quand TCP cale

L’encapsulation VPN grignote le MTU. Si vous avez un MTU sous‑jacent de 1500 et que le VPN ajoute des overheads,
votre MTU de chemin effectif peut être autour de 1400 ou moins. Si PMTUD échoue (parce que l’ICMP est filtré quelque part),
les gros segments TCP tombent dans un trou noir et les connexions se bloquent de façon mystérieuse.

Le correctif pragmatique est de réduire le MTU sur l’interface WSL ou de limiter le MSS TCP.
Vous échangez un peu de débit contre de la stabilité. En entreprise, la stabilité est la seule monnaie acceptée.

cr0x@server:~$ sudo ip link set dev eth0 mtu 1400
cr0x@server:~$ ip link show dev eth0 | sed -n '1,2p'
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:5d:4a:2b:1c brd ff:ff:ff:ff:ff:ff

Ce que ça signifie : Le MTU est maintenant 1400.
Décision : Retestez le workflow qui bloquait (git clone, curl, etc.). Si ça corrige les blocages, rendez‑le persistant (via la config du réseau de la distro),
et documentez pourquoi. Si ça ne change rien, revenez au diagnostic.

Schéma 5 : Traiter les proxies comme des citoyens de première classe

Beaucoup d’environnements VPN d’entreprise ne sont pas « routez où vous voulez ». Ils sont « routez vers le proxy, puis le proxy ».
Si Windows a un auto‑config de proxy, mais pas WSL, WSL échouera même si l’ordinateur « marche ».

Dans ce cas, la bonne correction est de configurer les variables de proxy dans WSL de façon cohérente et de maintenir no_proxy.
Ne le codez pas en dur dans des fichiers de démarrage obscurs ; utilisez une approche gérée (scripts de profil),
et gardez‑le visible. Les secrets vont dans des coffres, pas dans un .bashrc.

Blague n°2 : Déboguer le réseau VPN, c’est regarder un spectacle de magie où le lapin est votre paquet et il ne revient jamais.

Schéma 6 : Quand le client VPN interdit WSL, arrêtez de vous battre

Certains clients VPN appliquent « pas de trafic depuis les adaptateurs virtuels » ou similaires. Parfois c’est une politique explicite ; parfois un artefact d’implémentation.
Si votre diagnostic montre systématiquement que les paquets meurent à la passerelle Windows et que votre client VPN verrouille le forwarding,
vous avez trois options raisonnables :

• Utiliser WSL1 (si votre charge de travail le permet) parce qu’il partage la pile réseau Windows et évite souvent la frontière NAT.
• Utiliser une VM de dev sanctionnée sur le VPN (gérée par l’IT) ou un hôte de développement distant dans le réseau.
• Utiliser un bastion SSH accessible depuis Windows et se connecter via lui (port‑forwarding) depuis WSL ; considérez‑le comme une sortie contrôlée.

L’option insensée est « installer un pilote douteux » ou « désactiver le pare‑feu endpoint » pour que ça marche.
C’est comme ça qu’on se fait mettre en quarantaine, et ensuite la semaine s’empire.

Un principe de fiabilité à garder

« L’espoir n’est pas une stratégie. » — James Cameron

Appliquez‑le ici : arrêtez d’espérer que la table de routage « a l’air correcte » et prouvez chaque couche avec des tests ciblés.

Erreurs fréquentes : symptôme → cause → correctif

1) Symptom : « WSL ne peut pas résoudre les domaines internes ; Windows le peut »

Cause : /etc/resolv.conf de WSL pointe vers un résolveur qui ne suit pas les changements DNS du VPN, ou le DNS Windows est par interface et le chemin proxy DNS de WSL ignore les règles NRPT.

Correctif : Épinglez le DNS dans WSL (désactivez generateResolvConf) vers les serveurs DNS d’entreprise quand vous êtes sur le VPN, ou implémentez un résolveur qui suit l’état du VPN de façon fiable.

2) Symptom : « Le DNS résout, mais le TCP vers une IP interne time out depuis WSL »

Cause : Le client VPN bloque le forwarding depuis l’adaptateur vEthernet de WSL, ou le profil du pare‑feu Windows le bloque.

Correctif : Vérifiez la catégorie réseau de l’adaptateur WSL ; ajoutez des exceptions de pare‑feu étroites ; si la politique VPN l’interdit, utilisez WSL1 ou un hôte dev sanctionné.

3) Symptom : « Split tunnel : certains sous‑réseaux internes fonctionnent, d’autres non »

Cause : Routes manquantes du client VPN, chevauchements de réseaux locaux, ou chemin de retour inconnu pour la plage NAT WSL.

Correctif : Vérifiez les routes Windows pour chaque préfixe ; évitez les réseaux LAN locaux qui chevauchent les RFC1918 de l’entreprise ; poussez les routes correctes via le profil VPN ; assurez‑vous que le NAT est cohérent.

4) Symptom : « Après veille/reprise, WSL perd la connectivité jusqu’au redémarrage »

Cause : Changement de métrique d’interface ou état résolveur obsolète dans WSL ; la reconnexion VPN change l’ordre DNS/routes.

Correctif : Automatisez wsl --shutdown après la reconnexion VPN (ou au moins documentez‑le). Préférez une configuration DNS stable plutôt que de compter sur resolv.conf auto‑généré.

5) Symptom : « HTTPS se bloque ; petites requêtes OK ; ping OK »

Cause : Trou noir MTU dû à l’encapsulation VPN et PMTUD cassé.

Correctif : Baissez le MTU sur l’interface WSL (ou clamp MSS) et retestez. Si ça marche, rendez‑le persistant et notez l’overhead VPN.

6) Symptom : « Les services locaux sur Windows ne sont pas accessibles depuis WSL quand le VPN est actif »

Cause : Le VPN impose des routes ou des règles pare‑feu qui interfèrent avec le sous‑réseau local/localhost forwarding ; parfois le VPN bascule agressivement des règles pare‑feu.

Correctif : Utilisez des IPs hôtes explicites, validez les règles pare‑feu Windows, et envisagez de lier les services à la bonne interface. Pour le développement, préférez la connexion via localhost quand supportée, mais vérifiez après la connexion VPN.

Listes de contrôle / plan pas à pas

Checklist A : Vous avez besoin du DNS interne + TCP interne depuis WSL (VPN tunnel complet)

1. Confirmez que Windows peut résoudre et se connecter au service interne.
2. Dans WSL, vérifiez /etc/resolv.conf ; testez dig vers le DNS corporate directement.
3. Si Windows marche et WSL non, épinglez le DNS WSL vers les résolveurs corporate ou corrigez le chemin proxy DNS.
4. Vérifiez les routes Windows : la route par défaut VPN et les préfixes internes devraient passer par l’adaptateur VPN.
5. Vérifiez le profil pare‑feu de l’adaptateur WSL ; passez en Privé si autorisé ou ajoutez des règles étroites.
6. Si le TCP se bloque de façon étrange, testez le MTU et réduisez‑le si nécessaire.
7. Documentez l’état final : serveurs DNS, MTU, et ce qui casse hors VPN.

Checklist B : Vous avez besoin de split tunnel (internet local, sous‑réseaux corp via VPN)

1. Listez les préfixes internes exacts dont vous avez besoin (ne devinez pas ; obtenez‑les du profil VPN ou de l’équipe réseau).
2. Sur Windows, confirmez que ces préfixes ont des routes via l’adaptateur VPN (approche Task 9).
3. Dans WSL, vérifiez que le trafic vers chaque préfixe va vers la passerelle Windows (Task 6) et ne dévie pas.
4. Testez la reachabilité vers une IP interne par préfixe (Task 8).
5. Si ça échoue, suspectez le chemin de retour/NAT : vérifiez si le côté corporate attend le trafic seulement depuis l’IP VPN Windows.
6. Décidez : (a) le client VPN supporte le forwarding/NAT WSL ; (b) le réseau corporate route la plage NAT WSL ; ou (c) utilisez proxy/bastion.
7. Stabilisez le DNS : les domaines internes doivent résoudre vers des IP internes uniquement sur VPN ; évitez de mélanger résolveurs publics et privés.

Checklist C : Vous êtes sur un endpoint verrouillé par l’entreprise

1. Supposez que vous ne pouvez pas changer le profil pare‑feu, installer des pilotes, ou ajouter des routes de façon persistante.
2. Prouvez où les paquets meurent (Task 12 traceroute vers l’IP interne).
3. Si la chute est à la passerelle Windows et que Windows lui‑même peut atteindre la cible, c’est probablement une politique contre le forwarding depuis des adaptateurs virtuels.
4. Arrêtez de lutter contre la machine. Changez de stratégie : WSL1, hôte dev distant, ou bastion avec port‑forwards.
5. Faites documenter l’exception si WSL2 est un besoin métier ; « c’est embêtant » n’est pas une justification suffisante.

Trois mini‑histoires d’entreprise (anonymisées, plausibles et douloureusement familières)

Mini‑histoire 1 : L’incident causé par une mauvaise hypothèse

Une équipe a déployé un nouveau miroir de paquets interne lors d’une migration. Les développeurs utilisaient WSL2 pour les builds.
Le miroir vivait sur un sous‑réseau interne accessible seulement via VPN.
Les laptops Windows y arrivaient. L’équipe a supposé que cela voulait dire « les développeurs peuvent y accéder », point final.

Le premier lundi après le déploiement, les temps de build sont passés de normaux à catastrophiques. Pas parce que le miroir était down.
Parce que WSL2 ne pouvait pas l’atteindre, les outils retombaient sur des miroirs publics et multipliaient les retries. Certains builds réussissaient lentement ; d’autres échouaient ; tout le monde accusait le miroir.
La personne de garde a reçu des pages pour une « panne de registry » qui n’en était pas une.

Le mode de panne était clair a posteriori : Windows avait les routes VPN ; le trafic WSL mourait à la frontière hôte.
Le client VPN appliquait une politique qui n’autorisait pas le forwarding depuis les adaptateurs virtuels. Les processus Windows allaient bien ; WSL non.
Personne n’avait vérifié l’hypothèse tôt parce que « ça marche sur ma machine » était vrai — pas dans la même pile réseau.

Le correctif n’a pas été un hack de route astucieux. C’était une décision : pour la posture sécurité de l’entreprise, WSL2 n’aurait pas d’accès direct au VPN.
Ils ont fourni une image VM Linux sanctionnée pour les builds et gardé WSL2 pour les workflows locaux. C’était moins pratique.
Mais ça a arrêté les « pourquoi apt est cassé » hebdomadaires dans Slack.

Mini‑histoire 2 : L’optimisation qui s’est retournée contre eux

Une autre organisation a tenté de « accélérer le VPN » en imposant un split tunneling agressif. Le trafic Internet restait local ; seuls les préfixes internes passaient par le VPN.
Ça a réduit la charge sur leurs concentrateurs et amélioré les appels vidéo. Tout le monde s’est réjoui.

Puis les outils dev ont commencé à échouer de façons étranges. Les containers WSL2 atteignaient certains services internes mais pas d’autres.
Le DNS retournait parfois des IP internes, parfois des IP publiques. Git via HTTPS se bloquait par intermittence.
Ce n’était pas aléatoire. C’était du chaos déterministe.

L’optimisation a introduit deux points de couplage : l’exhaustivité des routes et la cohérence DNS.
Leurs routes split tunnel n’incluaient pas toutes les dépendances internes, surtout les plus récentes. Et leur stratégie DNS reposait sur des règles NRPT Windows,
que WSL2 n’honorait pas quand il utilisait un chemin résolveur générique.
Résultat : la résolution réussissait, mais la route manquait, alors les connexions expiraient. Les développeurs « corrigeaient » avec des fichiers hosts et IPs codées en dur.
Ce qui a marché jusqu’au prochain renumérotage.

Le rollback n’a pas été total. L’équipe a gardé le split tunnel pour la plupart du personnel, mais a créé un profil VPN « développeur » :
soit tunnel complet, soit un ensemble de préfixes beaucoup plus large plus un DNS stable. Moins élégant, plus de bande passante, moins de pannes mystérieuses.
Ils ont aussi banni les fixes hosts-file pour les services internes, pas par pureté, mais parce que c’était une dette opérationnelle avec des conséquences.

Mini‑histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe plateforme avait l’habitude qui ressemblait à de la bureaucratie : chaque fois qu’un développeur signalait « le VPN a cassé WSL » ,
la première réponse n’était pas un conseil — c’était une petite checklist d’extraits de commandes à coller.
WSL : ip route, cat /etc/resolv.conf, dig domaine interne.
Windows : un extrait de la table de routage et la liste des serveurs DNS. Même demande, à chaque fois.

Les gens se sont d’abord plaints. « Pourquoi vous avez besoin de tout ça ? C’est évidemment le DNS. » Ce n’était pas toujours le DNS.
La checklist les a forcés à arrêter de se battre contre leurs propres intuitions.
Après un mois, des motifs sont apparus : une version de client VPN cassait le forwarding ; une mise à jour de driver Wi‑Fi changeait les métriques ; une mise à jour de politique endpoint reclassait la NIC WSL.

Quand un incident réel est survenu — un dépôt interne inaccessible depuis WSL à travers un département — ces sorties de base ont rendu le triage rapide.
Ils pouvaient dire : Windows résout et se connecte, WSL résout mais ne peut pas se connecter, traceroute meurt à la passerelle, et la NIC WSL est Public.
Ça a réduit le périmètre d’investigation de « le réseau est down » à « régression de politique endpoint ».

Le correctif final était ennuyeux : un ajustement de politique pour autoriser des flux sortants spécifiques depuis l’adaptateur WSL vers l’adaptateur VPN,
plus un contournement documenté pour le clamp MTU sur un certain FAI. Personne n’a écrit un article là‑dessus.
Mais la prochaine fois, la personne de garde a dormi.

FAQ

1) Pourquoi WSL2 casse‑t‑il avec le VPN alors que WSL1 ne le faisait pas ?

WSL1 partageait la pile réseau Windows. WSL2 est une VM derrière une frontière NAT. Les clients VPN et pare‑feu qui gèrent la pile Windows
n’acheminent pas automatiquement le trafic d’une seconde pile.

2) Dois‑je passer à WSL1 juste pour la compatibilité VPN ?

Si votre charge de travail tolère WSL1 (les performances disque et les fonctionnalités noyau peuvent être limitées), c’est une solution légitime.
Elle évite la frontière NAT et se comporte souvent comme un « réseau Windows normal ».

3) Le problème est‑il toujours le DNS ?

Non. Le DNS est fréquent, mais beaucoup de pannes sont du routage/politique : le trafic atteint la passerelle Windows et meurt parce que le client VPN bloque le forwarding
ou que le profil pare‑feu est hostile.

4) Pourquoi ça fonctionne jusqu’à ce que je ré‑authentifie le VPN ou reprenne après la veille ?

La reconnexion VPN et la reprise peuvent réordonner les interfaces, changer les serveurs DNS et modifier les métriques de route.
WSL peut garder d’anciennes configurations résolveur, pendant que l’état Windows/VPN évolue en dessous.

5) Comment savoir si c’est le MTU ?

Si la résolution de noms marche et que les petites requêtes réussissent, mais que les téléchargements HTTPS, les git clone ou les appels API se figent, suspectez MTU/PMTUD.
Baissez temporairement le MTU dans WSL et retestez le workflow défaillant.

6) Puis‑je juste ajouter des routes dans WSL pour corriger le split tunnel ?

Généralement non. Les routes WSL passent toujours par la passerelle Windows. Si Windows/VPN n’acheminent pas, des tweaks côté Linux ne changeront pas la politique.
Concentrez‑vous d’abord sur les routes Windows et le comportement du VPN.

7) Pourquoi Windows peut atteindre des IP internes alors que WSL ne le peut pas ?

Les processus Windows prennent origine depuis les interfaces Windows et sont traités par le client VPN comme prévu.
Le trafic WSL prend pour source la plage NAT vEthernet/WLS ; certains clients VPN considèrent cela comme du « trafic forwarded » et le bloquent.

8) Quelle est la solution la plus propre et adaptée à l’entreprise ?

Un environnement de développement sanctionné à l’intérieur du réseau corporate : VM gérée, VDI ou hôte dev distant.
Si WSL2 local doit être utilisé, négociez une exception de politique documentée et implémentez des règles de pare‑feu étroites plutôt que des changements de profil larges.

9) Activer systemd dans WSL résout‑il les problèmes VPN ?

Parfois cela aide pour le DNS car vous obtenez un vrai service résolveur, mais cela ne contourne pas magiquement la politique VPN ou les règles pare‑feu.
Utilisez‑le si vous pouvez le supporter opérationnellement, pas comme une superstition.

Étapes pratiques suivantes

Faites trois choses, dans cet ordre :

1. Classifiez la panne : DNS vs routage/politique vs MTU. Utilisez les étapes de diagnostic rapide et les tâches ci‑dessus.
2. Choisissez un correctif stable : épinglez le DNS, ajustez le profil/pare‑feu, clamp MTU, adoptez le proxy, ou changez de stratégie (WSL1/hôte distant).
3. Rendez‑le reproductible : documentez l’état attendu (serveurs DNS, mode VPN, MTU) et conservez une checklist copiable pour le prochain incident.

L’objectif n’est pas « le faire marcher sur votre laptop aujourd’hui ». L’objectif est « le rendre ennuyeux le mois prochain ».
WSL2 est excellent. Les VPN sont nécessaires. Les faire coopérer relève moins de commandes astucieuses que de reconnaître où se situe réellement la frontière.