Redirection de ports dans WSL2 : rendez vos services accessibles depuis le LAN

Le modèle mental : ce qu’est réellement le « réseau WSL2 »

WSL2 n’est pas « des processus Linux sur Windows » comme l’était WSL1. WSL2 est une VM légère exécutant un vrai noyau Linux.
Cette VM se trouve derrière un commutateur virtuel et généralement derrière un NAT. Traduction : votre instance WSL2 a sa propre adresse IP, généralement sur un réseau privé Hyper‑V,
et cette adresse peut changer à chaque redémarrage de WSL.

Quand vous appelez localhost sur Windows, WSL2 essaie d’être utile. Il existe une fonctionnalité souvent appelée
« redirection localhost » qui rend les ports accessibles depuis l’hôte Windows sans que vous fassiez de routage explicite.
Mais « accessible depuis l’hôte Windows » n’est pas la même chose que « accessible depuis le reste de votre réseau ».

Pour que le LAN atteigne un service dans WSL2, vous avez besoin d’un point d’entrée sur l’hôte Windows (qui possède une IP atteignable depuis le LAN),
puis d’un forward ou proxy de cet hôte vers l’IP/port privé de la VM. Voilà tout le jeu.

Pensez à Windows comme à votre nœud d’edge et à WSL2 comme à un service backend dans un sous‑réseau privé. Soudain, ça ressemble à n’importe quel autre environnement
que vous avez déjà maintenu en production. Félicitations : vous faites tourner un petit datacenter NATé sur votre portable.

Faits intéressants et bref historique

• WSL1 et WSL2 ont des réseaux fondamentalement différents. WSL1 partageait la pile réseau de l’hôte ; WSL2 ne le fait pas. C’est pourquoi l’exposition des ports est devenue « plus difficile ».
• WSL2 utilise un vrai noyau Linux. C’est pour cela que iptables, sysctl et les outils de débogage « Linux classiques » redeviennent pertinents.
• Le commutateur virtuel Hyper‑V est la plomberie. Même sur les éditions Windows où vous n’avez jamais ouvert Hyper‑V Manager, WSL2 repose toujours sur des composants Hyper‑V.
• L’IP de la VM WSL2 est généralement éphémère. Elle est allouée au démarrage ; un arrêt/redémarrage la change souvent, ce qui casse les forwards statiques si vous les avez codés en dur.
• netsh interface portproxy est antérieur à WSL2 de plusieurs années. C’est un outil de redirection TCP ancien mais efficace qui a regagné en popularité parce qu’il fonctionne.
• Portproxy ne gère que TCP. Si vous avez besoin d’UDP, il faudra employer une autre approche (ou repenser l’architecture).
• Le pare‑feu Windows traite les ports redirigés comme de vrais services entrants. Si le pare‑feu bloque le port sur Windows, votre plan de redirection est mort‑né.
• « Ça marche sur localhost » est un piège. Le succès sur localhost prouve souvent seulement que la redirection Windows→WSL est active — pas que votre service écoute sur la bonne interface.

Mode opératoire de diagnostic rapide

Quand quelqu’un dit « je ne peux pas atteindre mon service WSL2 depuis le LAN », la route la plus rapide est d’identifier le premier saut où les paquets s’arrêtent.
Ne devinez pas. Ne redémarrez pas. Mesurez.

1) Premier contrôle : est‑ce que le service écoute dans Linux sur la bonne interface ?

S’il n’écoute que sur 127.0.0.1 dans WSL, la redirection depuis Windows n’aidera pas. Vous allez forwarder dans un mur.

2) Deuxième contrôle : Windows peut‑il atteindre le service via l’IP WSL ?

Si Windows ne peut pas se connecter à WSL_IP:PORT, votre problème n’est pas le LAN. C’est le binding du service, le pare‑feu Linux, ou le routage entre l’hôte et la VM.

3) Troisième contrôle : Windows écoute‑t‑il sur l’IP/port du LAN et le pare‑feu est‑il ouvert ?

Si Windows n’écoute pas (ou si le pare‑feu bloque), le LAN obtiendra un timeout. Si Windows écoute mais que le forward est incorrect, vous verrez des échecs rapides ou des resets.

4) Quatrième contrôle : est‑ce que cela échoue seulement depuis certains clients LAN ?

C’est un indice pour un pare‑feu côté client/VPN avec split tunneling, un mauvais profil de sous‑réseau (Public vs Private), ou une politique d’entreprise sur l’endpoint.

Tâches de base : prouver où les paquets meurent

Ce sont les tâches que j’exécute dans l’ordre. Chacune a : commande, sortie d’exemple, ce que cela signifie, et la décision suivante.
L’objectif est d’arrêter de vous disputer avec votre vous‑du‑futur.

Tâche 1 : Trouver votre IP LAN Windows (le vrai point d’entrée)

cr0x@server:~$ ipconfig

Windows IP Configuration

Ethernet adapter Ethernet:

   IPv4 Address. . . . . . . . . . . : 192.168.1.40
   Subnet Mask . . . . . . . . . . . : 255.255.255.0
   Default Gateway . . . . . . . . . : 192.168.1.1

Signification : Les clients LAN doivent cibler 192.168.1.40 (ou votre IP Wi‑Fi) pour atteindre quoi que ce soit sur cette machine.
Décision : Utilisez cette IP pour vos tests depuis un autre ordinateur. N’utilisez pas l’IP WSL ; le LAN ne peut pas y router par défaut.

Tâche 2 : Trouver l’IP de la VM WSL2 (la cible backend)

cr0x@server:~$ wsl.exe -e bash -lc "ip -4 addr show eth0 | sed -n 's/.*inet \\([0-9.]*\\).*/\\1/p'"
172.24.181.166

Signification : C’est l’adresse vers laquelle Windows doit forwarder.
Décision : Si vous implémentez portproxy, vous la pointerez ici. Aussi : attendez‑vous à ce qu’elle change plus tard.

Tâche 3 : Confirmer que le service écoute dans WSL2, et où

cr0x@server:~$ wsl.exe -e bash -lc "ss -lntp | head -n 20"
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
LISTEN 0      4096   127.0.0.1:8000      0.0.0.0:*     users:(("python3",pid=2217,fd=3))
LISTEN 0      4096   0.0.0.0:9090        0.0.0.0:*     users:(("prometheus",pid=1022,fd=7))

Signification : Le port 8000 est lié à 127.0.0.1 seulement (loopback). Le port 9090 est lié à 0.0.0.0 (toutes les interfaces).
Décision : Tout ce qui est lié à 127.0.0.1 ne sera pas joignable via un forward vers eth0. Corrigez d’abord la configuration du service.

Tâche 4 : Tester depuis Windows vers l’IP WSL directement (contourne portproxy)

cr0x@server:~$ powershell.exe -NoProfile -Command "Test-NetConnection -ComputerName 172.24.181.166 -Port 9090"

ComputerName     : 172.24.181.166
RemoteAddress    : 172.24.181.166
RemotePort       : 9090
InterfaceAlias   : vEthernet (WSL)
SourceAddress    : 172.24.176.1
TcpTestSucceeded : True

Signification : Windows peut atteindre le service dans WSL. C’est bon signe.
Décision : Il ne vous reste plus qu’à résoudre l’ingress LAN→Windows + le forward.

Tâche 5 : Si le test Windows→WSL échoue, vérifiez le pare‑feu Linux dans WSL

cr0x@server:~$ wsl.exe -e bash -lc "sudo iptables -S | head -n 30"
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

Signification : Pas de blocage iptables ici (politique ACCEPT).
Décision : Si votre politique est DROP ou si vous avez des rejects explicites, corrigez cela avant de toucher à Windows.

Tâche 6 : Vérifiez si Windows écoute déjà sur le port cible

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetTCPConnection -LocalPort 9090 -State Listen | Format-Table -AutoSize"

LocalAddress LocalPort RemoteAddress RemotePort State  OwningProcess
----------- --------- ------------- ---------- -----  -------------
0.0.0.0     9090      0.0.0.0       0          Listen 1234

Signification : Quelque chose écoute déjà sur Windows sur le port 9090. Portproxy ne peut pas se binder sur un port déjà pris.
Décision : Choisissez un autre port externe, ou arrêtez l’écoute conflictuelle.

Tâche 7 : Vérifiez les règles portproxy existantes (parce que les fantômes existent)

cr0x@server:~$ powershell.exe -NoProfile -Command "netsh interface portproxy show v4tov4"

Listen on ipv4:             Connect to ipv4:

Address         Port        Address         Port
--------------- ----------  --------------- ----------
0.0.0.0         8080        172.24.181.166  8000

Signification : Windows écoute sur 0.0.0.0:8080 et redirige vers WSL 172.24.181.166:8000.
Décision : Validez que WSL écoute réellement sur 8000 sur une interface non‑loopback, sinon ce forward vous ment.

Tâche 8 : Confirmez que Windows écoute après avoir ajouté portproxy

cr0x@server:~$ powershell.exe -NoProfile -Command "netstat -ano | findstr :8080"
  TCP    0.0.0.0:8080           0.0.0.0:0              LISTENING       4

Signification : PID 4 est le processus System hébergeant l’écoute portproxy. C’est normal.
Décision : Si vous ne voyez pas LISTENING, portproxy n’est pas actif ou le port est bloqué/occupé.

Tâche 9 : Testez depuis une autre machine du LAN (le seul test qui compte)

cr0x@server:~$ curl -I http://192.168.1.40:8080
HTTP/1.1 200 OK
Server: uvicorn
Date: Tue, 06 Feb 2026 11:20:14 GMT
Content-Type: text/html; charset=utf-8

Signification : Le LAN atteint Windows, Windows forwarde vers WSL, et l’application répond.
Décision : Validez et mettez en production (ou partagez). Ensuite rendez cela persistant, car les IP WSL sont capricieuses.

Tâche 10 : Si le test LAN timeoute, vérifiez l’état de la règle du pare‑feu Windows

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetFirewallRule -DisplayName 'WSL2 8080 Inbound' -ErrorAction SilentlyContinue | Select-Object DisplayName, Enabled, Profile, Direction, Action"
DisplayName            Enabled Profile Direction Action
-----------            ------- ------- --------- ------
WSL2 8080 Inbound      True    Private Inbound   Allow

Signification : La règle existe, est activée, s’applique au profil Private, et autorise l’entrée.
Décision : Si votre réseau est en Public, cette règle ne s’appliquera pas. Corrigez le profil ou ajoutez Public (avec précaution).

Tâche 11 : Vérifiez le profil réseau Windows (Public vs Private)

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetConnectionProfile | Format-Table -AutoSize"
Name             InterfaceAlias      NetworkCategory IPv4Connectivity
----             --------------      --------------- ----------------
OfficeLAN        Ethernet            Public          Internet

Signification : Vous êtes en profil Public, donc les règles Private ne fonctionneront pas.
Décision : Soit changez le profil en Private (si approprié), soit autorisez le port sur Public pour cette interface uniquement.

Tâche 12 : Confirmez que le trafic arrive sur Windows (capture de paquets, rapide et honnête)

cr0x@server:~$ powershell.exe -NoProfile -Command "pktmon filter remove; pktmon filter add -p 8080; pktmon start --etw -m real-time"
PktMon started with Real Time display.

Signification : Vous surveillez maintenant les paquets entrants sur le port 8080.
Décision : Si vous ne voyez rien lors d’un test client, le problème est en amont (mauvaise IP, VLAN, route client ou politique réseau). Si vous voyez du trafic, concentrez‑vous sur le pare‑feu/portproxy/service.

Blague #1 : La redirection de ports, c’est comme la politique de bureau — tout fonctionne jusqu’à ce que vous supposiez que l’autre côté peut « juste y accéder ».

Trois manières d’exposer les services WSL2 au LAN (et quand les utiliser)

Approche A : portproxy Windows (simple, fonctionne, TCP‑only)

C’est la solution courante pour « j’ai besoin que mon service TCP WSL2 soit accessible depuis mon LAN aujourd’hui ». Vous liez un écouteur sur Windows, et vous forwardez vers l’IP WSL.
C’est ennuyeux. L’ennui, c’est bien.

À utiliser quand :

• Vous avez besoin de TCP (HTTP, gRPC, SSH, Prometheus, bases de données via TCP).
• Vous pouvez tolérer une petite configuration côté Windows.
• Vous voulez l’accès LAN sans changer le mode réseau WSL2.

Approche B : reverse proxy sur Windows (IIS/NGINX/Caddy sur l’hôte)

Si vous voulez terminaison TLS, authentification côté hôte, de meilleurs logs, ou plusieurs backends avec un routage clair, exécutez un vrai reverse proxy sur Windows
et pointez‑le vers WSL. C’est plus propre que d’empiler plusieurs règles portproxy, et plus facile à raisonner quand vous avez plusieurs services.

À utiliser quand :

• Vous avez besoin de HTTPS et vous ne voulez pas que vos certificats de dev restent uniquement dans WSL.
• Vous voulez un routage basé sur le chemin (/api, /grafana) ou plusieurs apps sur le port 443.
• Vous avez besoin de vrais logs et d’un contrôle de débit.

Approche C : mode bridgé / mirroring réseau (tentant, mais dépend de l’environnement)

Selon votre version de Windows et WSL, il existe des modes réseau plus récents qui peuvent changer la façon dont WSL est connecté (y compris un comportement « mirror »).
Cela peut réduire le besoin de forwards explicites, mais ce n’est pas une solution universelle — surtout dans des environnements d’entreprise avec contrôles d’endpoint,
clients VPN et politiques de pare‑feu gérées.

À utiliser quand :

• Vous standardisez une flotte de développement et pouvez valider le comportement sur des builds identiques.
• Vous voulez moins d’éléments mouvants que portproxy + tâches planifiées.
• Vous comprenez que « ça marche sur mon portable » n’est pas une stratégie de déploiement.

Méthode 1 (la plus courante) : netsh portproxy sur Windows + pare‑feu

Étape 1 : Assurez‑vous que votre service écoute sur quelque chose accessible depuis eth0 de WSL

Si votre appli se lie à 127.0.0.1 dans WSL, elle n’acceptera que des connexions provenant de cette même instance WSL.
C’est acceptable pour du dev local. C’est inutile pour une exposition LAN.

Exemple : Uvicorn/FastAPI. Ne faites pas ça :

cr0x@server:~$ wsl.exe -e bash -lc "python3 -m uvicorn app:app --host 127.0.0.1 --port 8000"
INFO:     Uvicorn running on http://127.0.0.1:8000 (Press CTRL+C to quit)

Faites plutôt ceci :

cr0x@server:~$ wsl.exe -e bash -lc "python3 -m uvicorn app:app --host 0.0.0.0 --port 8000"
INFO:     Uvicorn running on http://0.0.0.0:8000 (Press CTRL+C to quit)

Décision : Avant de toucher au réseau Windows, obtenez que ss -lntp affiche 0.0.0.0:8000 (ou l’IP eth0 WSL).
C’est le contrat que vous allez forwarder.

Étape 2 : Ajoutez une règle portproxy (Windows écoute, forwarde vers WSL)

Choisissez un port d’écoute externe sur Windows. Souvent vous le gardez identique au port interne.
Ici, on forward le port 8080 de Windows vers le port 8000 de WSL.

cr0x@server:~$ powershell.exe -NoProfile -Command "netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=8080 connectaddress=172.24.181.166 connectport=8000"
Ok.

Signification : Windows accepte maintenant des connexions TCP sur toutes les interfaces (y compris le LAN) sur le port 8080 et les forwarde vers WSL.
Décision : Si vous ne voulez exposer le LAN que sur une interface/IP spécifique, définissez listenaddress sur votre IP LAN au lieu de 0.0.0.0.

Étape 3 : Vérifiez la règle et l’écoute

cr0x@server:~$ powershell.exe -NoProfile -Command "netsh interface portproxy show v4tov4"
Listen on ipv4:             Connect to ipv4:

Address         Port        Address         Port
--------------- ----------  --------------- ----------
0.0.0.0         8080        172.24.181.166  8000

cr0x@server:~$ powershell.exe -NoProfile -Command "netstat -ano | findstr :8080"
  TCP    0.0.0.0:8080           0.0.0.0:0              LISTENING       4

Signification : Le mapping portproxy existe et Windows écoute.
Décision : Si netstat n’affiche rien, vous avez un conflit (port occupé), des privilèges insuffisants, ou une politique qui le bloque.

Étape 4 : Testez depuis Windows, puis depuis le LAN

cr0x@server:~$ powershell.exe -NoProfile -Command "curl.exe -I http://127.0.0.1:8080"
HTTP/1.1 200 OK
Server: uvicorn
Date: Tue, 06 Feb 2026 11:22:40 GMT
Content-Type: text/html; charset=utf-8

Signification : Windows peut toucher son propre écouteur et être forwardé vers WSL.
Décision : Si localhost fonctionne mais pas le LAN, votre problème est presque toujours le profil/règles du pare‑feu Windows ou le réseau en amont.

Règles du pare‑feu Windows sans vous faire détester la vie

Le pare‑feu Windows n’est pas votre ennemi. C’est un videur. Il faut juste inscrire votre nom sur la liste.
La subtilité est le profil : Domain, Private, Public. Votre « OfficeLAN » peut être catégorisé en Public, et alors votre règle soigneusement créée pour Private ne servira à rien.

Créer une règle entrante autorisée pour le port d’écoute

cr0x@server:~$ powershell.exe -NoProfile -Command "New-NetFirewallRule -DisplayName 'WSL2 8080 Inbound' -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8080 -Profile Private"
Name                  : {2d4e3f2b-41c0-4b84-9c85-1c09f3324c7f}
DisplayName           : WSL2 8080 Inbound
Enabled               : True
Direction             : Inbound
Profiles              : Private

Signification : TCP/8080 entrant est autorisé quand votre interface est en profil Private.
Décision : Si vous êtes en Public (Tâche 11), soit changez la catégorie réseau, soit ajoutez Public. N’ouvrez pas aveuglément des ports sur Public sur un portable que vous déplacez.

Limiter la portée : autoriser seulement votre sous‑réseau LAN (recommandé)

cr0x@server:~$ powershell.exe -NoProfile -Command "Set-NetFirewallRule -DisplayName 'WSL2 8080 Inbound' -RemoteAddress 192.168.1.0/24"

Signification : Seuls les clients de 192.168.1.0/24 peuvent se connecter.
Décision : C’est la bonne pratique pour des labos maison et des sous‑réseaux de bureau. Vous vous en remercierez plus tard.

Confirmer que la règle s’applique et est activée

cr0x@server:~$ powershell.exe -NoProfile -Command "Get-NetFirewallRule -DisplayName 'WSL2 8080 Inbound' | Get-NetFirewallPortFilter | Format-Table -AutoSize"
Protocol LocalPort RemotePort IcmpType LocalAddress RemoteAddress
-------- --------- ---------- -------- ------------ -------------
TCP      8080      Any        Any      Any          192.168.1.0/24

Signification : Le filtre de port est correct et limité.
Décision : Si RemoteAddress affiche « Any » et que ce n’était pas votre intention, restreignez‑le. Les incidents de sécurité commencent souvent par « c’est juste ma machine de dev ».

Rendre cela persistant lors des redémarrages de WSL

L’IP de WSL2 change. Les règles portproxy ne suivent pas magiquement. Si vous codez en dur l’IP WSL d’hier, vous serez
« mystérieusement hors ligne » après un reboot, un arrêt de WSL, ou parfois après une reprise de veille capricieuse.

Il y a deux options sensées :

• Automatiser la mise à jour du portproxy chaque fois que WSL démarre (ou à la connexion de l’utilisateur).
• Arrêter d’utiliser portproxy pour des backends dynamiques et mettre un reverse proxy sur Windows qui cible localhost via la redirection localhost WSL (quand c’est approprié).

Option 1 : Script de mise à jour du portproxy au logon (simple, efficace)

Ce one‑liner PowerShell obtient l’IP WSL actuelle et met à jour un mapping portproxy.

cr0x@server:~$ powershell.exe -NoProfile -Command "$wslip = (wsl.exe -e bash -lc `"ip -4 addr show eth0 | sed -n 's/.*inet \\([0-9.]*\\).*/\\1/p'`").Trim(); netsh interface portproxy delete v4tov4 listenport=8080 listenaddress=0.0.0.0 2>$null; netsh interface portproxy add v4tov4 listenaddress=0.0.0.0 listenport=8080 connectaddress=$wslip connectport=8000; netsh interface portproxy show v4tov4"
Listen on ipv4:             Connect to ipv4:

Address         Port        Address         Port
--------------- ----------  --------------- ----------
0.0.0.0         8080        172.24.181.166  8000

Signification : La règle est maintenant alignée sur l’IP WSL du jour.
Décision : Placez‑le dans une tâche planifiée « At log on » ou « At startup » avec les plus hauts privilèges.
Si vous ne l’exécutez pas élevé, les changements portproxy peuvent échouer silencieusement ou ne fonctionner qu’à moitié.

Option 2 : Confirmer que WSL n’est pas arrêté de façon inattendue

cr0x@server:~$ wsl.exe --status
Default Distribution: Ubuntu
Default Version: 2
WSL version: 2.1.5.0
Kernel version: 5.15.146.1

Signification : WSL est installé et actif ; les détails de version aident quand le comportement diffère entre machines.
Décision : Si votre organisation a des versions mixtes, standardisez ou attendez‑vous à des comportements incohérents sur le port/localhost.

Faire en sorte que le service écoute correctement (la partie que tout le monde oublie)

La plupart des échecs de « redirection WSL2 » ne sont pas des échecs de redirection. Ce sont des échecs d’association d’adresse.
Votre service n’écoute que sur le loopback, donc il fonctionne depuis WSL et peut‑être depuis Windows via la redirection localhost spéciale,
mais il n’acceptera pas les connexions arrivant sur eth0.

Diagnostiquer le binding : loopback vs toutes les interfaces

cr0x@server:~$ wsl.exe -e bash -lc "ss -lnt | awk 'NR==1 || /:8000|:9090/'"
State  Recv-Q Send-Q Local Address:Port Peer Address:Port Process
LISTEN 0      4096   127.0.0.1:8000    0.0.0.0:*
LISTEN 0      4096   0.0.0.0:9090      0.0.0.0:*

Signification : 8000 est loopback‑only ; 9090 est joignable depuis le réseau de la VM WSL.
Décision : Pour une exposition LAN, liez sur 0.0.0.0 ou l’IP WSL, puis restreignez avec un pare‑feu/proxy si nécessaire.

Vérifier l’adresse à laquelle votre appli pense devoir se binder

cr0x@server:~$ wsl.exe -e bash -lc "grep -R --line-number 'listen\\|bind\\|host' /etc/nginx 2>/dev/null | head"

Signification : Pas de config nginx dans cet exemple. Sur des systèmes réels, vous trouverez des surprises listen 127.0.0.1:....
Décision : Si vous voyez des binds loopback, décidez si vous voulez que portproxy forwarde vers le loopback (peu typique) ou changez le service pour écouter sur eth0.

Blague #2 : Si vous vous liez à 127.0.0.1 et que vous attendez que le LAN y accède, vous envoyez un colis à vous‑même et vous accusez le service postal.

Docker/Desktop/conteneurs dans WSL2 : la couche supplémentaire

Les conteneurs n’éliminent pas la complexité réseau ; ils la concentrent. Si vous exécutez Docker dans WSL2 (ou Docker Desktop utilisant WSL2),
vous pouvez avoir trois couches réseau : LAN → Windows → VM WSL2 → conteneur.

La bonne démarche dépend d’où le port du conteneur est publié.

Tâche : Vérifier la publication de port du conteneur dans WSL2

cr0x@server:~$ wsl.exe -e bash -lc "docker ps --format 'table {{.Names}}\t{{.Ports}}' | head"
NAMES        PORTS
api-dev      0.0.0.0:8000->8000/tcp
grafana      127.0.0.1:3000->3000/tcp

Signification : api-dev est publié sur toutes les interfaces dans WSL2 ; grafana est loopback‑only dans WSL2.
Décision : Pour l’exposition LAN, publiez le port du conteneur sur 0.0.0.0 dans WSL2 (ou utilisez un reverse proxy côté WSL), puis forwardez depuis Windows.

Tâche : Vérifier depuis Windows vers l’IP WSL pour un service containerisé

cr0x@server:~$ powershell.exe -NoProfile -Command "Test-NetConnection -ComputerName 172.24.181.166 -Port 8000"
ComputerName     : 172.24.181.166
RemoteAddress    : 172.24.181.166
RemotePort       : 8000
InterfaceAlias   : vEthernet (WSL)
SourceAddress    : 172.24.176.1
TcpTestSucceeded : True

Signification : Le port publié par le conteneur est joignable depuis Windows via l’interface vEthernet.
Décision : Configurez alors portproxy de Windows vers WSL:8000, et gérez le pare‑feu.

Trois mini‑histoires du monde professionnel (pour que vous ne les répétiez pas)

1) L’incident causé par une mauvaise hypothèse

Une équipe a construit une chaîne d’outils interne : une petite API dans WSL2, une UI sur la machine d’un autre développeur, et de l’automatisation appelant l’API depuis un runner CI sur le LAN.
Le développeur a fait la démo : ça marche sur son portable Windows en utilisant http://localhost:5000. Tout le monde a hoché la tête. Ils ont mergé.

Quand le runner CI a essayé d’appeler, timeouts. L’hypothèse était « localhost veut dire joignable », ce genre de mensonge qui survit juste assez longtemps pour être déployé.
Ils avaient confondu la redirection localhost Windows avec l’accessibilité réelle depuis le LAN.

Le débogage a commencé au mauvais endroit. Les gens ont regardé les logs applicatifs et rejettent la faute sur les clients HTTP. Pendant ce temps, les paquets n’avaient jamais atteint Windows.
Le profil du pare‑feu était Public sur le portable parce que le réseau était traité comme non fiable par la politique. L’entrée était bloquée.

La correction fut simple : une règle entrée pare‑feu Windows scindée au subnet du CI, plus un mapping portproxy mis à jour au logon.
L’important n’était pas les commandes. C’était le changement de modèle mental : WSL2 est un segment réseau backend, et Windows est l’edge.

Ensuite, ils ont écrit un runbook d’une page : « Si ça ne marche que sur localhost, ce n’est pas un service. C’est une démo locale. » Ça les a sauvés d’une répétition.

2) L’optimisation qui a mal tourné

Une autre équipe avait plusieurs services WSL2 et en avait assez de gérer des règles portproxy. Quelqu’un a proposé une approche « plus propre » :
binder tout dans WSL2 sur 0.0.0.0, puis ouvrir une large règle entrante sur Windows pour une plage de ports.
Moins d’administration, onboarding plus rapide. Ça semblait efficace.

Puis un scan de sécurité a signalé la machine comme exposant des services inattendus sur le réseau d’entreprise.
Certains de ces ports étaient des bases de données de dev sans authentification (parce que « c’est juste sur mon portable »), et l’un était un endpoint de debug qui divulguait volontiers des variables d’environnement.

L’équipe a argué d’un faux positif. Ce n’en était pas un. Ils avaient créé une workstation « cible molle » qui se comportait comme un serveur faiblement protégé.
Même si personne ne l’exploitait, l’exposition seule a déclenché une réponse incident et un examen politique.

Le rollback a été douloureux mais instructif : ils sont passés à un reverse proxy Windows sur 443 avec authentification, et n’ont forwardé que des ports précis.
Ils ont aussi restreint les règles pare‑feu aux subnets connus. L’onboarding est devenu un peu plus complexe, mais la posture de sécurité n’était plus embarrassante.

L’optimisation n’est pas seulement vitesse. En réseau, « moins de règles » signifie souvent « plus grand rayon d’impact ».

3) La pratique ennuyeuse mais correcte qui a sauvé la situation

Une équipe plateforme avait un problème prévisible : l’IP WSL2 changeait et cassait les intégrations locales pour plusieurs ingénieurs chaque semaine.
Plutôt que des sessions de débogage héroïques, ils ont écrit un script ennuyeux et l’ont standardisé via la gestion des endpoints.

Le script faisait trois choses : interroger l’IP WSL actuelle, réécrire les mappings portproxy pour une courte liste de ports requis, et valider les écouteurs avec netstat.
Si la validation échouait, il loggait une erreur et s’arrêtait. Pas de devinettes, pas d’état partiel.

Ils ont aussi créé des règles pare‑feu avec des portées explicites (subnets du bureau uniquement) et les ont liées aux profils Private/Domain.
Sur les réseaux Public (cafés), les services n’étaient simplement pas atteignables. C’était une fonctionnalité, pas un bug.

Des mois plus tard, quand une mise à jour Windows a changé le comportement sur un sous‑ensemble de machines, leur étape de validation l’a détectée tôt.
Ils n’ont pas découvert la rupture pendant une démo. Ils l’ont découverte lors d’une exécution de script au logon, avec un point de défaillance clair.

Le travail SRE le plus précieux ressemble souvent à de la paperasse : standardisation, scripts idempotents et vérifications qui échouent bruyamment.

Erreurs courantes : symptôme → cause racine → correction

1) Symptôme : ça marche dans WSL avec curl, échec depuis le LAN avec timeout

Cause racine : Le pare‑feu Windows bloque l’entrée sur le port écouté (souvent mauvais profil réseau : Public vs Private).

Correction : Créez/activez une règle entrante autorisant le port et le profil correct, scopez‑la au sous‑réseau LAN.

2) Symptôme : ça marche depuis localhost de Windows, échoue de Windows vers WSL_IP

Cause racine : Le service dans WSL est lié à 127.0.0.1 seulement, ou le pare‑feu Linux bloque le non‑loopback.

Correction : Lieez le service sur 0.0.0.0 (ou l’IP eth0 WSL). Re‑vérifiez avec ss -lntp.

3) Symptôme : le LAN voit « connection refused » immédiatement

Cause racine : Windows est joignable, mais rien n’écoute (portproxy manquant, mauvais listenport, ou conflit de port empêchant le binding).

Correction : Vérifiez netstat -ano pour LISTENING. Corrigez les conflits de port ou recréez le mapping portproxy.

4) Symptôme : ça marchait hier ; aujourd’hui timeout

Cause racine : L’IP WSL2 a changé ; portproxy pointe encore vers l’ancienne IP.

Correction : Re‑interrogez l’IP WSL et mettez à jour portproxy. Automatisez via une tâche planifiée.

5) Symptôme : seuls certains clients LAN peuvent se connecter

Cause racine : Règle pare‑feu trop restrictive, client sur un autre subnet/VLAN, ou client sur VPN avec routage différent.

Correction : Validez l’IP/source du client. Élargissez intentionnellement RemoteAddress, ou routez correctement.

6) Symptôme : erreurs HTTPS/TLS ou mauvais comportement Host header

Cause racine : Utiliser raw portproxy pour plusieurs apps HTTP sans reverse proxy ; le backend attend un Host/SNI spécifique.

Correction : Mettez un reverse proxy sur Windows, terminez le TLS là, routez par host/chemin, et forwardez vers WSL.

7) Symptôme : le service UDP ne fonctionne jamais via portproxy

Cause racine : Portproxy est TCP‑only.

Correction : Redessinez (utilisez TCP), exécutez un autre proxy supportant UDP, ou utilisez un mode réseau offrant une adressation directe.

8) Symptôme : portproxy existe, pare‑feu ouvert, toujours rien

Cause racine : Vous écoutez sur 0.0.0.0 mais la NIC Windows est en profil Public avec restrictions entrantes ou des règles d’endpoint d’entreprise qui prévalent.

Correction : Vérifiez le profil réseau, les politiques de sécurité de l’endpoint, et validez avec une capture de paquets (pktmon). Si la politique bloque l’entrée, arrêtez de lutter et utilisez une solution d’ingress/reverse proxy approuvée.

Listes de contrôle / plan étape par étape

Checklist A : Un service, un port, accès LAN requis (TCP)

1. Confirmez que le service se bind correctement dans WSL2.

   Exécutez ss -lntp. Vous voulez 0.0.0.0:PORT ou WSL_IP:PORT, pas 127.0.0.1:PORT.

2. Récupérez l’IP WSL.

   Utilisez wsl.exe -e bash -lc "ip -4 addr show eth0 ...". Notez‑la ; c’est votre connectaddress.

3. Testez Windows → WSL directement.

   Test-NetConnection -ComputerName WSL_IP -Port PORT. Si cela échoue, ne touchez pas encore au LAN.

4. Créez un mapping portproxy.

   Lieez sur Windows listenaddress=0.0.0.0 et forwardez vers WSL.

5. Ouvrez le pare‑feu Windows pour le port d’écoute.

   Créez une règle entrante Allow sur Private/Domain ; scopez RemoteAddress au sous‑réseau LAN.

6. Testez depuis une autre machine du LAN.

   Utilisez curl ou un navigateur. Ne considérez pas terminé tant qu’une seconde machine ne réussit pas.

7. Rendez cela persistant.

   Planifiez un script pour mettre à jour le mapping portproxy avec l’IP WSL actuelle au démarrage/connexion.

Checklist B : Plusieurs services (HTTP) et vous voulez de la propreté

1. Exécutez un reverse proxy sur Windows sur 443 (un seul trou entrant).
2. Forwardez vers des backends WSL sur leurs ports internes.
3. Gardez les ports WSL fermés au LAN ; seul le proxy Windows est exposé.
4. Utilisez des scopes pare‑feu pour limiter qui peut atteindre le proxy.
5. Consignez les requêtes côté Windows ; le débogage devient vivable.

Checklist C : Ça casse après reboot

1. Supposez que l’IP WSL a changé jusqu’à preuve du contraire.
2. Mettez à jour programmatique le mapping portproxy.
3. Validez : netsh ... show et netstat -ano.
4. Si ça échoue encore, relancez le mode opératoire de diagnostic rapide. Ne « redémarrez juste ».

Une citation à garder sur votre écran

« Everything fails, all the time. » — Werner Vogels

Ce n’est pas du pessimisme. C’est une contrainte de conception. Votre redirection de ports doit être conçue comme si elle allait être redémarrée, renumérotée et mal profilée — parce que ce sera le cas.

FAQ

1) Pourquoi puis‑je atteindre le service depuis localhost de Windows mais pas depuis d’autres machines LAN ?

Parce que la redirection Windows→WSL pour localhost n’est pas du routage LAN. Les machines LAN frappent l’IP LAN de votre Windows, et Windows doit accepter le trafic entrant
(pare‑feu) et le forwarder (portproxy ou proxy) vers WSL.

2) Ai‑je toujours besoin de netsh portproxy ?

Non. C’est le plus simple pour TCP. Si vous voulez TLS, routage et logs, exécutez un reverse proxy sur Windows à la place.
Si vous avez besoin d’UDP, portproxy ne vous aidera pas.

3) Pourquoi portproxy casse‑t‑il après un reboot ou wsl --shutdown ?

La VM WSL2 obtient une nouvelle IP. Portproxy pointe toujours vers l’ancienne. Automatisez la mise à jour du mapping avec l’IP WSL actuelle au démarrage/connexion.

4) Puis‑je forwarder vers 127.0.0.1 dans WSL ?

Portproxy forwarde vers une IP que Windows peut router. Typiquement vous forwardez vers l’IP eth0 de WSL.
Si votre service est loopback‑only, changez‑le pour écouter sur 0.0.0.0 (puis contrôlez l’exposition avec un pare‑feu/proxy).

5) Est‑ce sûr de mettre listenaddress=0.0.0.0 ?

C’est sûr seulement si vos scopes de pare‑feu sont sensés. Si vous exposez un port sur toutes les interfaces et l’autorisez depuis « Any », vous publiez un service.
Restreignez par profil et RemoteAddress, surtout sur un portable.

6) Portproxy supporte‑t‑il l’UDP ?

Non. Il ne gère que TCP. Si vous avez besoin de services UDP (certains jeux, DNS, certaines télémétries), utilisez un autre mécanisme de proxy ou redessinez vers TCP.

7) Pourquoi je vois LISTENING PID 4 pour mon port forwardé ?

C’est attendu. Le processus System héberge l’écoute pour les règles portproxy.
Validez le mapping avec netsh interface portproxy show v4tov4 et des tests bout‑en‑bout.

8) Puis‑je lier le forward seulement à mon IP LAN au lieu de toutes les interfaces ?

Oui. Définissez listenaddress sur votre IP LAN (comme 192.168.1.40) et gardez la règle pare‑feu limitée aussi.
Cela réduit l’exposition accidentelle sur les adaptateurs VPN ou autres interfaces.

9) Quelle est la manière la plus rapide de savoir si la requête LAN atteint ma machine Windows ?

Utilisez pktmon filtré sur le port d’écoute pendant que vous lancez une requête client LAN. Si aucun paquet n’arrive, arrêtez de blâmer WSL.
Corrigez l’IP ciblée, le routage VLAN ou le comportement VPN du client.

Conclusion : prochaines étapes qui fonctionnent vraiment

Faites en sorte que ce soit ennuyeux. L’ennui s’échelonne.

1. Corrigez d’abord le binding dans WSL : assurez‑vous que votre service écoute sur 0.0.0.0 (ou l’IP eth0 WSL), pas seulement sur le loopback.
2. Prouvez que Windows peut atteindre WSL par IP avec Test-NetConnection. Si cela échoue, n’impliquez pas le LAN.
3. Utilisez portproxy pour une exposition TCP simple, puis ouvrez le pare‑feu Windows de manière étroite (profil + scope subnet).
4. Automatisez les mises à jour portproxy pour que la rotation d’IP WSL ne vous réveille pas (ou n’échoue pas votre démo) après chaque reboot.
5. Quand la complexité augmente (TLS, plusieurs apps, auth), arrêtez d’empiler des rustines et exécutez un vrai reverse proxy Windows.

Si vous traitez votre portable comme un petit serveur d’edge — avec ingress explicite, politique explicite et configuration reproductible — vous cesserez de « déboguer le réseau »
et vous commencerez à livrer des services.