WSL2 : Guide avancé de configuration réseau, NAT et modes miroir

Informatec Digital » Ressources » WSL2 : Guide avancé de configuration réseau, NAT et modes miroir

WSL2 a complètement transformé l'intégration de Linux avec Windows , notamment en matière de réseau : nous disposons désormais d'une machine virtuelle légère dotée de sa propre pile réseau, d'une adresse IP et de règles d'accès distinctes. Ceci ouvre de nombreuses perspectives pour le développement, les tests, les conteneurs et les environnements auto-hébergés, mais soulève également des inquiétudes quant à l'inaccessibilité de certains services, comme c'était le cas avec WSL1.

Comprendre la configuration réseau de WSL2, ses modes NAT et miroir, l'utilisation des fichiers `.wslconfig` et `wsl.conf`, ainsi que leur interaction avec les pare-feu, les VPN, Docker et des outils comme Tailscale est essentiel pour éviter les problèmes. Nous verrons étape par étape le fonctionnement de cette configuration, comment exposer des services à Windows et au réseau local, quelles commandes utiliser pour obtenir les adresses IP appropriées et quelles options de configuration avancées vous permettent d'optimiser votre environnement, le rendant ainsi stable et, surtout, sécurisé.

Comment le réseau fonctionne réellement dans WSL2

WSL2 ne partage plus la pile réseau de l'hôte comme WSL1.Au lieu de cela, il exécute chaque distribution Linux au sein d'une petite machine virtuelle gérée par Hyper-V. Cette machine virtuelle possède sa propre carte réseau virtuelle (généralement eth0) et une adresse IP privée attribuée par un commutateur virtuel interne.

Dans son mode par défaut, WSL2 utilise une architecture basée sur NAT (Traduction d'adresses réseau). Windows fait office de routeur/hôte, et la distribution Linux réside sur un sous-réseau privé, généralement dans la plage d'adresses IP spécifiée. 172.16.0.0/12Ce sous-réseau peut changer après un redémarrage ou un redémarrage de WSL, ce qui a rendu plus d'une personne folle lors de la configuration de règles de pare-feu statiques.

D'un point de vue pratique, cela signifie que l'adresse IP de votre distribution WSL2 n'est ni stable ni directement accessible depuis le réseau local comme c'était le cas avec WSL1 : par défaut, la connectivité entre Windows et WSL2 se fait uniquement via des règles de redirection et la NAT, et l'exposition au réseau local nécessite des étapes supplémentaires ou l'utilisation du mode miroir.

En plus de cette architecture de base, Windows 11 22H2 et les versions ultérieures ajoutent de nouvelles fonctionnalités réseau. (mode miroir, tunnel DNS, proxy automatique, pare-feu Hyper-V, etc.) qui sont contrôlés à partir du fichier global .wslconfigcertaines options de Linux sont gérées avec /etc/wsl.conf.

Identifier les adresses IP dans WSL2

L'utilisation de WSL2 implique de bien distinguer deux cas de figure en matière d' adressage IP : l'adresse IP de la distribution Linux et l'adresse IP de l'hôte Windows telle qu'elle est perçue depuis Linux. Chaque cas est géré par une commande différente.

Scénario 1 : Sous Windows, vous souhaitez connaître l’adresse IP de la distribution WSL2 afin qu’une application installée sur l’hôte (par exemple, un client, un navigateur ou un outil de test) puisse se connecter à un service exécuté sous Linux. Pour ce faire, vous pouvez exécuter les commandes suivantes sous Windows (invite de commandes ou PowerShell) :

wsl.exe --distribution <DistroName> hostname -i

Si vous souhaitez utiliser la distribution par défaut, vous pouvez omettre le paramètre de distribution. et appelez simplement wsl.exe hostname -iEn arrière-plan, cette commande s'exécute sous Linux. hostname --ip-addresses et renvoie l'adresse IP de l'instance. Un résultat typique pourrait ressembler à ceci :

172.30.98.229

Scénario 2 : Depuis votre distribution Linux, vous devez connaître l’adresse IP de l’hôte Windows , par exemple pour qu’une application WSL2 puisse se connecter à un serveur exécuté nativement sous Windows (Node.js, SQL Server, Caddy, etc.). Dans le terminal Linux, vous pouvez utiliser :

ip route show | grep -i default | awk '{ print $3 }'

Le résultat sera la passerelle par défaut de la machine virtuelle WSL2 , qui correspond à l'adresse IP de l'hôte Windows vue depuis Linux, quelque chose comme :

172.30.96.1

Cette valeur (par exemple, 172.30.96.1) est l'adresse vers laquelle vos clients Linux doivent pointer lorsque vous souhaitez accéder aux services exécutés sur l'hôte Windows en mode NAT classique.

Mode NAT : comportement par défaut du réseau WSL2

Par défaut, WSL2 fonctionne en mode NAT, ce qui est largement suffisant pour de nombreux environnements de développement simples . L'important est de comprendre ce qui fonctionne « automatiquement » et ce qui ne fonctionne pas, afin d'éviter de perdre du temps à chercher des solutions inefficaces.

Accéder aux services Linux depuis Windows en utilisant localhostSi vous exécutez une application réseau (par exemple, un serveur Node.js, un serveur Flask, un serveur SQL Server sous Linux) sur votre distribution WSL2, vous pouvez y accéder depuis Windows en utilisant localhost:puertoWindows redirige automatiquement les connexions entrantes vers l'adresse IP interne de la machine virtuelle WSL2.

Accéder aux services exécutés sous Windows depuis Linux : la donne change. Pour accéder à une application réseau sur l’hôte (comme un serveur Node.js, SQL Server ou Caddy sous Windows) depuis WSL2, vous devez utiliser l’adresse IP de l’hôte telle qu’elle apparaît sous Linux, obtenue avec la commande `path` par défaut :

ip route show | grep -i default | awk '{ print $3 }'

Grâce à cette adresse IP, vous pouvez vous connecter depuis Linux à n'importe quel service hébergé., par exemple http://172.30.96.1:3000 si votre serveur Windows écoute sur le port 3000 sur toutes les interfaces.

Lorsque vous vous connectez via des adresses IP distantes (et non localhost), les applications les perçoivent comme des connexions LAN.Cela signifie que de nombreux serveurs doivent être configurés pour écouter sur 0.0.0.0 au lieu de 127.0.0.1Par exemple, avec Flask, vous pouvez lancer :

app.run(host='0.0.0.0')

Ce changement améliore l'accessibilité mais exige une attention particulière à la sécurité , car il autorise les connexions depuis votre réseau local, et non plus seulement depuis l'appareil lui-même.

Accéder à WSL2 depuis le réseau local (LAN) via NAT

L'un des changements les plus gênants lors du passage de WSL1 à WSL2 est que les distributions ne sont plus directement accessibles depuis le réseau local . Sous WSL1, si votre système Windows était visible sur le réseau, les services de la distribution bénéficiaient de cette visibilité presque automatiquement.

Dans WSL2, la machine virtuelle possède sa propre adresse IP privée et n'est pas automatiquement annoncée sur le réseau local . Pour obtenir un comportement similaire à celui de l'ancien système, en mode NAT, vous devez créer un proxy de port sous Windows, comme pour toute machine virtuelle Hyper-V.

Windows propose un outil classique pour cela : netsh interface portproxyUne commande typique pour rediriger un port hôte vers l'adresse IP/le port WSL2 serait :

netsh interface portproxy add v4tov4 listenport=<puertoHost> listenaddress=0.0.0.0 connectport=<puertoWSL> connectaddress=(wsl hostname -I)

En pratique, vous remplaceriez les marqueurs par des valeurs spécifiques , par exemple :

netsh interface portproxy add v4tov4 listenport=4000 listenaddress=0.0.0.0 connectport=4000 connectaddress=192.168.101.100

Ici listenaddress=0.0.0.0 Cela indique que Windows écoutera sur toutes les adresses IPv4 de l'hôte.et transmettra ce qui arrive par le port 4000 à 192.168.101.100:4000qui correspondrait à l'adresse IP WSL2 obtenue avec :

• wsl hostname -I Elle vous donne l'adresse IP de la distribution Linux à l'intérieur de la machine virtuelle WSL2.
• cat /etc/resolv.conf Elle révèle l'adresse IP de l'hôte Windows Vista depuis WSL2.

Grâce à cette technique, vous pouvez rendre un service exécuté sur WSL2 accessible depuis n'importe quel ordinateur du réseau local , à condition que le pare-feu Windows l'autorise et que vous soyez bien conscient que vous exposez un service d'une machine virtuelle et non directement celui de l'hôte.

IPv6 et fonctionnalités de réseau modernes

WSL2 est également compatible avec IPv6, ce qui est particulièrement pertinent dans les environnements modernes, les VPN et les réseaux d'entreprise . Pour gérer les adresses, les commandes de base sous Linux sont équivalentes à celles d'IPv4 :

• wsl hostname -i Depuis Windows, afficher l'adresse IP de la distribution WSL2
• ip route show | grep -i default | awk '{ print $3 }' depuis Linux pour obtenir l'adresse IP de l'hôte Windows

Le véritable bond en avant en matière de qualité dans la prise en charge d'IPv6 et des VPN réside dans le mode réseau miroir , disponible dans Windows 11 22H2 et versions ultérieures, que nous verrons en détail plus tard.

Mode réseau miroir : duplication des interfaces Windows sous Linux

Sur les ordinateurs équipés de Windows 11 22H2 ou supérieur, vous pouvez activer le mode réseau « miroir » dans WSL2, ce qui change complètement le modèle : au lieu du NAT classique, Linux « voit » les interfaces réseau Windows reflétées.

Pour l'activer, vous devez modifier le fichier .wslconfig votre utilisateur, qui est en %UserProfile%\.wslconfigDepuis PowerShell avec des privilèges d'administrateur, vous pouvez l'ouvrir avec :

notepad $env:USERPROFILE\.wslconfig

À l'intérieur, ajoutez (ou modifiez) la section [wsl2] pour activer le mode miroir :

[wsl2]
networkingMode=mirrored

Une fois le fichier enregistré, vous devez redémarrer WSL2 pour que les modifications soient prises en compte , par exemple avec :

wsl --shutdown

Lors de son redémarrage, WSL utilisera la nouvelle architecture réseau en miroir , qui offre plusieurs avantages importants :

• Prise en charge native d'IPv6 et intégration améliorée avec les réseaux d'entreprise et les VPN
• Possibilité de se connecter aux services Windows depuis Linux via 127.0.0.1 directamente (bien que cela ne soit pas autorisé) ::1 (comme la boucle de retour IPv6 pour cela)
• Amélioration de la prise en charge du multicast dans l'intégration Windows-Linux
• Accès direct à WSL depuis le réseau local sans avoir besoin de netsh portproxyen utilisant l'adresse IP de la machine Windows elle-même

L'activation de ce mode résout de nombreux problèmes NAT classiques de WSL2 et constitue l'option recommandée dans la plupart des environnements de développement et d'auto-hébergement modernes où vous pouvez utiliser une version mise à jour de Windows 11.

Tunneling DNS et utilisation de proxys dans WSL2

Dans Windows 11 22H2 et les versions ultérieures, la résolution de noms de WSL2 a également fait l'objet d'une refonte importante.La clé réside dans deux fonctionnalités définies dans .wslconfig: dnsTunneling y autoProxy.

Le choix dnsTunneling Elle est activée par défaut dans la section [wsl2]. Cela permet de traiter les requêtes DNS Linux via une fonctionnalité de virtualisation, au lieu de les envoyer sous forme de paquets réseau classiques. Ceci améliore considérablement la compatibilité avec les VPN et les configurations réseau complexes sur l'hôte.

Pour sa part, autoProxy=true force WSL à utiliser les paramètres de proxy HTTP de WindowsSi l'hôte se trouve derrière un proxy d'entreprise ou de sécurité, WSL2 l'hérite automatiquement sans que vous ayez à vous soucier manuellement des variables d'environnement.

Vous pourriez avoir, par exemple, quelque chose comme ceci dans votre .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

Cela garantit que le réseau WSL2 se comporte de manière cohérente avec la configuration de l'hôte , ce qui est particulièrement utile dans les entreprises ayant des politiques strictes en matière de réseau et de filtrage.

Pare-feu Hyper-V et exposition des services sécurisés

Dans les environnements modernes, le réseau WSL2 transite également par un pare-feu dédié . À partir de WSL 2.0.9 sur Windows 11 22H2, la fonctionnalité de pare-feu Hyper-V est activée par défaut, ajoutant une couche de filtrage supplémentaire pour le trafic des machines virtuelles (y compris le trafic WSL2).

Si vous travaillez en mode miroir et souhaitez exposer en permanence les services WSL2 au réseau local (par exemple, les API, les tableaux de bord ou les services auto-hébergés), vous devez vous assurer que les règles du pare-feu l'autorisent.

Une approche raisonnable depuis PowerShell avec des privilèges d'administrateur consiste à créer une règle Hyper-V pour les réseaux privés :

New-NetFirewallHyperVRule -DisplayName "WSLPrivateInboundRule" -Profiles Private -Direction Inbound -Action Allow -VMCreatorId ((Get-NetFirewallHyperVVMCreator).VMCreatorId)

Si, pour une raison quelconque, vous souhaitez désactiver cette protection Hyper-V spécifique (ce qui est moins recommandé), vous pouvez utiliser :

Set-NetFirewallHyperVVMSetting -Name ((Get-NetFirewallHyperVVMCreator).VMCreatorId) -Enabled False

L'idée est de maintenir le pare-feu actif autant que possible , en limitant les règles aux réseaux privés et uniquement aux ports nécessaires, et en réservant toute désactivation massive en dernier recours et toujours dans l'optique de renforcer à nouveau la configuration dès que tout fonctionne correctement.

Architecture réseau WSL2, plages X11 et 172.16.0.0/12

Un cas classique qui révèle des détails du réseau WSL2 est l'utilisation d'applications graphiques via X11 , par exemple le lancement de Xming sous Windows et l'envoi d'applications Linux via DISPLAY.

Lors de la mise à niveau de WSL1 vers WSL2, de nombreux utilisateurs constatent que X cesse de fonctionner. car le réseau cesse d'être « partagé » et devient un réseau NAT virtuel avec des plages d'adresses telles que : 172.16.0.0/12qui peut également changer après chaque redémarrage de Windows ou de WSL.

Pour que X fonctionne à nouveau avec Xming depuis WSL2, l'astuce habituelle consiste à obtenir l'adresse IP Windows que Linux voit en utilisant :

ens

DISPLAY=$(grep nameserver /etc/resolv.conf | cut -d' ' -f2):0

En parallèle, il est nécessaire de configurer le pare-feu Windows pour autoriser le trafic X11 provenant de ce sous-réseau NAT.Une approche courante consiste à modifier la règle Xming en ajoutant la plage 172.16.0.0/12 en TCP+UDP 6000.

Beaucoup finissent par désactiver l'authentification Xming avec cette option. -acCela ouvre en réalité la porte à tout client X se connectant depuis ce réseau. Bien que fonctionnel, ce système présente des risques de sécurité importants ; il est donc préférable d'envisager des solutions plus limitées ou l'utilisation de WSLg (applications GUI intégrées) sous Windows 11.

wsl.conf et .wslconfig : configuration avancée de WSL2

WSL propose deux fichiers de configuration clés qui contrôlent à la fois le comportement de la machine virtuelle et celui de chaque distribution.: /etc/wsl.conf (par distribution) et %UserProfile%\.wslconfig (global pour toutes les distributions WSL2).

wsl.conf vit au sein de la distribution Linux, dans /etc/wsl.confIl sert à configurer les options locales de cette distribution : montages automatiques, génération de hosts y resolv.confinteropérabilité avec Windows, l'utilisateur par défaut, systemd, etc.

.wslconfig Il est enregistré en dehors de Linux, dans le profil utilisateur Windows. (C:\Users\<Usuario>\.wslconfig) et contrôle les paramètres globaux de la VM qui alimente WSL2 : mémoire, processeurs, noyau, mode réseau, pare-feu, DNS, taille du disque virtuel, prise en charge de l’interface graphique, etc.

Un détail important à noter est la « règle des 8 secondes » lors de la modification des paramètres : lorsque vous modifiez l’un de ces fichiers, vous devez vous assurer que la machine virtuelle WSL s’arrête complètement. Même si vous fermez la fenêtre de la distribution, celle-ci peut rester en mémoire pendant quelques secondes.

Pour forcer le redémarrage d'un sous-système, vous pouvez utiliser :

• wsl --list --running vérifier s'il existe des distributions actives
• wsl --shutdown pour fermer toutes les distributions en une seule fois
• wsl --terminate <distroName> pour arrêter une distribution spécifique

Ce n'est qu'après avoir désactivé et redémarré WSL que les modifications de configuration sont réellement appliquées , un point que beaucoup négligent et qui leur fait croire que leurs paramètres « ne fonctionnent pas ».

Principales options de wsl.conf par section

L'archive wsl.conf Il s'inspire du format .ini classique, avec des sections et des clésLes principales sections sont [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] Vous contrôlez la manière dont les lecteurs Windows sont montés sous Linux. (généralement faible) /mnt):

• enabled (booléen, valeur par défaut : vrai)Si cela est vrai, les disques C:/, D:/, etc. sont automatiquement montés sur /mnt/c, /mnt/d...
• mountFsTab (booléen)Si c'est vrai, c'est traité. /etc/fstab lors du démarrage de la distribution.
• root (chaîne): répertoire racine où les lecteurs seront montés, par exemple /windir/ pour avoir /windir/c.
• options (liste séparée par des virgules): Paramètres spécifiques à DrvFs tels que metadata, uid, gid, umask, fmask, dmask o case.

DrvFs est le système de fichiers pont entre Windows et Linux , conçu pour accéder à NTFS depuis WSL avec contrôle des permissions, métadonnées et sensibilité à la casse.

Dans la section [network] Vous pouvez ajuster la génération automatique des fichiers réseau:

• generateHostsSi cela est vrai, WSL génère automatiquement /etc/hosts.
• generateResolvConfSi cela est vrai, WSL crée /etc/resolv.conf avec le DNS hérité.
• hostname: nom d'hôte que la distribution utilisera.

La section [interop] contrôle l'interopérabilité avec Windows:

• enabled: Active ou désactive la possibilité de lancer des processus Windows depuis WSL.
• appendWindowsPath: décide s'il faut ajouter les chemins d'accès Windows à $PATH Linux.

En [user] Vous pouvez spécifier l'utilisateur qui sera utilisé par défaut au démarrage de la distribution.:

• default: nom d'utilisateur qui sera démarré par défaut dans WSL.

La section [boot] Il est particulièrement utile sous Windows 11 et Server 2022. pour lancer automatiquement des services, tels que Docker, au sein de WSL :

• command: chaîne de commande à exécuter au démarrage de WSL, par exemple service docker start.
• protectBinfmt: protège la génération des unités systemd lorsque systemd est activé.

Vous avez également des sections comme [gpu] (activer l'accès au GPU Windows depuis Linux), et [time] synchroniser le fuseau horaire avec WindowsCela évite les problèmes lors du passage à l'heure d'été ou lors de voyages.

.wslconfig : contrôle de la machine virtuelle WSL2

Alors que le fichier wsl.conf permet d'affiner le comportement de chaque distribution, le fichier .wslconfig permet d'affiner la configuration de la machine virtuelle partagée par toutes les distributions WSL2 . Ce fichier concerne uniquement les distributions exécutées sous WSL2, et non sous WSL1.

Dans .wslconfig la section principale est [wsl2]où vous définissez les paramètres clés:

• kernel y kernelModules: chemins absolus depuis Windows vers un noyau Linux personnalisé et ses modules.
• memory: Limite de mémoire de la machine virtuelle (par défaut 50 % de la RAM de l'hôte), par exemple 4GB.
• processors: nombre de processeurs logiques affectés à la VM.
• localhostForwarding: permet d'accéder aux ports ouverts dans WSL2 depuis Windows via localhost.
• swap y swapFile: taille et chemin du fichier d'échange de la machine virtuelle.
• guiApplications: active ou désactive la prise en charge des applications GUI (WSLg).
• dnsProxyEn mode NAT, le système détermine si le serveur DNS Linux sera l'instance NAT de l'hôte ou une copie du serveur DNS Windows.
• networkingModeIci, vous avez le choix entre none, nat, bridged (obsolète), mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxy: options que nous avons évoquées pour mieux intégrer le réseau WSL aux stratégies Windows.
• defaultVhdSize: taille maximale du VHD où est stocké le système de fichiers de la distribution (par défaut 1 To).

Il y a aussi une section [experimental] où les fonctionnalités sont activées en phase de test en tant que:

• autoMemoryReclaim: paramètres de récupération automatique de la mémoire (désactivé, progressif, dropCache).
• sparseVhd: création de disques virtuels clairsemés pour économiser de l'espace.
• bestEffortDnsParsing y dnsTunnelingIpAddress: réglage fin du tunnelage DNS.
• ignoredPorts: ports que les applications Linux peuvent utiliser même s'ils sont utilisés sous Windows en mode miroir.
• hostAddressLoopback: permet à l'hôte et au conteneur de se connecter en utilisant les adresses IP locales de l'hôte en mode miroir.

Une configuration correcte du fichier .wslconfig fait toute la différence entre une machine virtuelle gourmande en ressources et un environnement optimisé qui fonctionne parfaitement avec votre système Windows et votre réseau , en particulier si vous travaillez avec des charges de travail importantes, des conteneurs ou plusieurs distributions simultanées.

WSL2, Docker et réseau pour l'auto-hébergement avec Tailscale

Un cas très pratique consiste à utiliser WSL2 sur des serveurs Windows (même Windows Server 2025) comme plateforme d'auto-hébergement , en combinant Ubuntu sur WSL2, Docker Engine (sans Docker Desktop), Tailscale et un proxy inverse comme Caddy pour exposer des services comme n8n ou Supabase.

L'objectif est de disposer d'un environnement Docker stable au sein de WSL2, en évitant les problèmes rencontrés avec Docker Desktop sur les serveurs . En installant Docker Engine directement sur Ubuntu (WSL2), le réseau de conteneurs s'appuie sur le réseau WSL2, qui dépend lui-même du mode NAT ou miroir défini dans le fichier .wslconfig.

Avec Tailscale installé sur WSL2, vous pouvez publier vos services sur un VPN maillé sans ouvrir de ports sur le routeur et utiliser Caddy comme proxy inverse pour centraliser les certificats TLS, les routes et l'équilibrage de charge léger entre les conteneurs.

Pour maintenir un réseau propre, prévisible et sécurisé, il est conseillé de :

• Choisissez un seul mode réseau cohérent (NAT ou miroir) et documentez-le.
• Évitez les conflits de ports entre Windows et WSL2, en s'appuyant sur ignoredPorts si vous utilisez des miroirs
• Contrôlez l'exposition du service uniquement via Tailscale ou Caddy.au lieu d'ouvrir les ports « par défaut » dans le pare-feu
• Automatisez le démarrage de Docker, Tailscale et Caddy depuis [boot] dans wsl.conf avoir un environnement plus proche de la production

Avec cette architecture, WSL2 cesse d'être un simple outil de développement et peut devenir une plateforme d'auto-hébergement assez sérieuse , à condition d'accepter ses limitations (virtualisation sur Hyper-V, couche réseau supplémentaire, etc.) et de la configurer avec soin.

Meilleures pratiques pour la mise en réseau WSL2 en vue du développement et des tests

Hormis les réglages de précision, il existe un certain nombre de directives qui vous aident à travailler confortablement avec le réseau WSL2 sans avoir à lutter constamment avec les adresses IP, les ports et les pare-feu.

Pour les services de développement, utilisez des ports élevés (supérieurs à 1024) et évitez les ports système privilégiés ou fortement utilisés ; cela minimise les conflits et élimine le besoin de privilèges supplémentaires.

Assurez-vous que le code et les données résident dans le système de fichiers Linux. (vous ~/ ou des itinéraires internes) au lieu de travailler directement sur /mnt/ccar l'accès à NTFS depuis WSL est plus lent et peut pénaliser les services gourmands en E/S.

Automatisez les paramètres réseau et les règles de redirection à l'aide de scripts. En PowerShell et Bash : par exemple, un script qui configure WSL2 à son démarrage. netsh portproxy (si vous continuez avec NAT) ou vérifiez les règles du pare-feu lors de l'utilisation de la mise en miroir.

Évitez de vous fier aux changements d'adresse IP. généré par le commutateur virtuel interne. Dans la mesure du possible, travaillez avec localhost, noms d'hôtes ou entrées dans /etc/hosts pour vos services, afin qu'un changement d'adresse IP ne mette pas paralysé la moitié de votre infrastructure de test.

Dans les environnements professionnels ou semi-production, il est préférable de ne pas se fier aveuglément au transfert automatique de WSL . Configurez explicitement les ports, les proxys et les règles de pare-feu pour savoir précisément ce qui est exposé et où.

Correctement configuré, WSL2 offre un réseau isolé et flexible, idéal pour le développement avancé, les tests d'API, la gestion de conteneurs et la simulation d'environnements distribués . La clé du succès réside dans la maîtrise des modes réseau (NAT ou miroir), des fichiers wsl.conf et .wslconfig, ainsi que de l'interaction avec votre pare-feu et les outils de votre infrastructure (Docker, Tailscale, proxys inverses), afin que Windows et Linux puissent fonctionner sur la même machine sans conflit de ports ni compromission de la sécurité.