Accès aux applications réseau avec WSL

  • Article

Il existe quelques considérations à prendre en compte lors de l’utilisation d’applications réseau et WSL. Par défaut, WSL utilise une architecture basée sur NAT et nous vous recommandons d’essayer le nouveau mode réseau mis en miroir pour obtenir les dernières fonctionnalités et améliorations.

Mode réseau par défaut : NAT

Par défaut, WSL utilise une architecture NAT (traduction d'adresses réseau) pour la mise en réseau. Gardez à l’esprit les considérations suivantes lors de l’utilisation d’une architecture réseau basée sur NAT :

Accès aux applications réseau Linux à partir de Windows (localhost)

Si vous créez une application réseau (par exemple, une application qui s’exécute sur un serveur SQL ou NodeJS) dans votre distribution Linux, vous pouvez y accéder à partir d’une application Windows (comme votre navigateur Internet Edge ou Chrome) à l’aide de localhost (comme vous le feriez normalement).

Accès aux applications réseau Windows à partir de Linux (adresse IP de l’hôte)

Si vous souhaitez accéder à une application réseau qui s’exécute sur Windows (par exemple, une application s’exécutant sur un serveur SQL ou NodeJS) à partir de votre distribution Linux (p. ex. Ubuntu), vous devez utiliser l’adresse IP de votre ordinateur hôte. Il ne s’agit pas d’un scénario courant, mais vous pouvez suivre ces étapes pour le faire fonctionner.

  1. Obtenez l’adresse IP de votre ordinateur hôte en exécutant cette commande à partir de votre distribution Linux : ip route show | grep -i default | awk '{ print $3}'
  2. Connectez-vous à n’importe quel serveur Windows à l’aide de l’adresse IP copiée.

L’image ci-dessous présente un exemple de cela avec la connexion à un serveur Node.js en cours d’exécution dans Windows via curl.

Se connecter au serveur NodeJS dans Windows via Curl

Connexion via des adresses IP distantes

Lorsque vous utilisez des adresses IP distantes pour vous connecter à vos applications, celles-ci sont traitées comme des connexions à partir du réseau local (LAN). Cela signifie que vous devez vous assurer que votre application peut accepter les connexions LAN.

Par exemple, vous devrez peut-être lier votre application à 0.0.0.0 au lieu de 127.0.0.1. Dans l’exemple d’une application Python utilisant Flask, vous pouvez procéder à l’aide de la commande : app.run(host='0.0.0.0'). Gardez à l’esprit la sécurité lorsque vous apportez ces changements, car cela permettra d’établir des connexions à partir de votre réseau local.

Accès à une distribution WSL 2 à partir de votre réseau local (LAN)

Lorsque vous utilisez une distribution WSL 1, si votre ordinateur était configuré pour être accessible via votre réseau local, les applications qui s’exécutent dans WSL sont également accessibles sur votre réseau local.

Ce n’est pas le cas par défaut dans WSL 2. WSL 2 a une carte Ethernet virtualisée avec sa propre adresse IP unique. Actuellement, pour activer ce flux de travail, vous devez suivre les mêmes étapes que pour une machine virtuelle standard. (Nous recherchons des moyens d’améliorer cette expérience.)

Voici un exemple d’utilisation de la commande Windows Netsh interface portproxy pour ajouter un proxy de port qui écoute votre port hôte et connecte ce proxy de port à l’adresse IP de la machine virtuelle WSL 2.

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

Dans cet exemple, vous devez mettre à jour <yourPortToForward> sur un numéro de port, par exemple listenport=4000. listenaddress=0.0.0.0 signifie que les demandes entrantes sont acceptées à partir de n’importe quelle adresse IP. L’adresse d’écoute spécifie l’adresse IPv4 à écouter et peut être modifiée sur des valeurs qui incluent : adresse IP, nom NetBIOS de l’ordinateur ou nom DNS de l’ordinateur. Si aucune adresse n’est spécifiée, la valeur par défaut est l’ordinateur local. Vous devez mettre à jour la valeur <yourPortToConnectToInWSL> sur un numéro de port où vous souhaitez que WSL se connecte, par exemple connectport=4000. Enfin, la valeur connectaddress doit être l’adresse IP de votre distribution Linux installée par le biais de WSL 2 (adresse de la machine virtuelle WSL 2), que vous pouvez trouver en entrant la commande suivante : wsl.exe hostname -I.

Cette commande peut donc ressembler à ceci :

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

Pour obtenir l’adresse IP, utilisez :

  • wsl hostname -I pour l’adresse IP de votre distribution Linux installée via WSL 2 (l’adresse de machine virtuelle WSL 2)
  • cat /etc/resolv.conf pour l’adresse IP de la machine Windows telle que vue à partir de WSL 2 (la machine virtuelle WSL 2)

L’utilisation de listenaddress=0.0.0.0 écoutera sur tous les ports IPv4.

Remarque

L’utilisation d’une minuscule « i » avec la commande de nom d’hôte génère un résultat différent de celui avec une majuscule « I ». wsl hostname -i est votre ordinateur local (127.0.1.1 est une adresse de diagnostic d’espace réservé), tandis que wsl hostname -I retourne l’adresse IP de votre ordinateur local comme vu par d’autres ordinateurs et doit être utilisé pour identifier le connectaddress de votre distribution linux exécutée via WSL 2.

Accès IPv6

  • wsl hostname -i pour l’adresse IP de votre distribution Linux installée via WSL 2 (l’adresse de machine virtuelle WSL 2)
  • ip route show | grep -i default | awk '{ print $3}' pour l’adresse IP de la machine Windows telle que vue à partir de WSL 2 (la machine virtuelle WSL 2)

L’utilisation de listenaddress=0.0.0.0 écoutera sur tous les ports IPv4.

Mise en réseau en mode miroir

Vous pouvez définir networkingMode=mirrored sous [wsl2] dans le fichier .wslconfig pour activer la mise en réseau en mode miroir. Cette activation modifie WSL vers une architecture réseau entièrement nouvelle qui a pour objectif la « mise en miroir » des interfaces réseau que vous avez sur Windows dans linux, pour ajouter de nouvelles fonctionnalités de mise en réseau et améliorer la compatibilité.

Activer ce mode présente les avantages actuels suivants :

  • Compatible avec IPv6
  • Se connecter aux serveurs Windows à partir de Linux en utilisant l’adresse localhost 127.0.0.1. L’adresse localhost IPv6 ::1 n’est pas prise en charge
  • Compatibilité réseau améliorée pour les VPN
  • Prise en charge de la multidiffusion
  • Connexion à WSL directement à partir de votre réseau local (LAN)

Remarque

Exécutez la commande suivante dans la fenêtre PowerShell avec des privilèges d’administrateur pour configurer les paramètres de pare-feu Hyper-V pour autoriser les connexions entrantes : Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow ou New-NetFirewallHyperVRule -Name "MyWebServer" -DisplayName "My Web Server" -Direction Inbound -VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -Protocol TCP -LocalPorts 80.

Ce nouveau mode résout les problèmes réseau rencontrés avec l’utilisation d’une architecture NAT (traduction d'adresses réseau). Recherchez des problèmes connus ou des commentaires sur les bogues identifiés dans le référentiel de produit WSL sur GitHub.

Tunneling DNS

Si vous définissez dnsTunneling=true sous [wsl2] dans le fichier .wslconfig, WSL utilise une fonctionnalité de virtualisation pour répondre aux requêtes DNS à partir de WSL au lieu de les demander sur un paquet réseau. Cette fonctionnalité vise à améliorer la compatibilité avec les VPN et d’autres configurations réseau complexes.

Proxy automatique

Définir autoProxy=true sous [wsl2] dans le fichier .wslconfig oblige WSL à utiliser les informations de proxy HTTP de Windows. Si vous avez déjà configuré un proxy dans Windows, l’activation de cette fonctionnalité définit automatiquement ce proxy dans WSL.

WSL et pare-feu

Sur les ordinateurs exécutant Windows 11 22H2 et versions ultérieures, avec WSL 2.0.9 et versions ultérieures, la fonctionnalité de pare-feu Hyper-V est activée par défaut. Cela garantit que :