Comment accéder au localhost d'un sous-système linux à partir de Windows ?

J'avais besoin d'accéder à mon port hébergé par le WSL à partir d'un autre appareil de mon réseau local
(par exemple, pour le développement mobile), et j'ai trouvé que la réponse de @Owen Tourlamain ne m'a pas aidé pour cela.

J'avais besoin de mettre en place portproxy et j'ai constaté que l'utilisation de connectaddress=localhost o connectaddress=127.0.0.1 a fait pas fonctionne pour moi (WSL2, Windows 10 20H2).

Il me restait donc à trouver la réponse à la question de l'OP, et il s'avère qu'elle est étonnamment simple :

1. Startup WSL

2. wsl hostname -I

   Sortie comme : 172.10.200.10

Nota:
Vous devez couper les espaces blancs si vous les utilisez en ligne dans une commande powershell, par exemple :

netsh interface portproxy add v4tov4 listenport=19000 listenaddress=0.0.0.0 `
    connectport=19000 connectaddress=$($(wsl hostname -I).Trim());

Accéder au WSL depuis votre réseau

L'OP a posé la question de l'accès au WSL "à partir de Windows". Si vous souhaitez également y accéder "depuis votre réseau privé", vous devrez également, une fois, créer une règle de pare-feu autorisant un port spécifique (ou une série de ports).

Avertissement : Ne pas activer le pare-feu de Windows "éteint" . Établissez une règle pour n'ouvrir que les ports spécifiques dont vous avez besoin.

_{(powershell en tant qu'administrateur)}

New-NetFireWallRule -Profile Private -DisplayName 'MyRule ports for LAN development' `
    -Direction Inbound -LocalPort 19000-19006 -Action Allow -Protocol TCP

Nota:

• -LocalPort 19000-19006 Remplacer le 19000-19006 avec le(s) port(s) dont vous avez besoin.
• -Profile Private afin que les ports ne soient ouverts que sur un réseau que vous avez marqué comme étant "privé"
• -Direction Inbound signifie uniquement en entrée (ingress)
• -DisplayName 'MyRuleName blah blah...' est pour vous un nom lisible par l'homme. Mais choisissez quelque chose dont vous vous souviendrez, car vous pourrez utiliser ce nom pour retrouver la règle à l'avenir, pour consulter son état ou pour la supprimer. par ex. Get-NetFirewallRule | Where-Object {$_.DisplayName -Match "MyRuleName.*"}

Comme solution temporaire, s'il cesse de fonctionner sur WSL2, vous pouvez simplement arrêter WSL et le relancer à partir de PowerShell ou de CMD. Je ne sais pas pourquoi, mais cela résout temporairement le problème :

wsl --shutdown
wsl

Vieille question qui a été soulevée aujourd'hui par une autre réponse, je me permets donc d'intervenir. Cette question a été posée à l'origine pour la WSL1. Bien que la "réponse" soit la même pour le WSL2, il y a quelques légères différences qui doivent être prises en compte.

Tout d'abord, sur WSL1, comme le mentionne la réponse originale acceptée de 2016, le réseau fonctionne réellement sur l'interface hôte Windows. C'est pourquoi localhost / 127.0.0.1 (ou l'adresse du NIC Windows) fonctionne ici.

Le WSL2, quant à lui, fonctionne de manière virtualisée, de sorte que l'interface réseau est un vNIC doté d'un différents que celle de l'hôte Windows. Ce réseau est en fait NATé derrière l'hôte Windows. C'est également la raison pour laquelle vous pouvez accéder à une instance WSL1 en utilisant l'adresse IP de Windows à partir de otro sur le réseau, ce qui n'est pas le cas avec WSL2.

Mais le WSL2 dispose d'une fonction appelée "localhost forwarding", qui lui permet de fonctionner comme le WSL1 en ce qui concerne localhost / 127.0.0.1 . Cette fonction est activée par défaut, mais peut être désactivé (bien que je ne connaisse aucune raison de le faire, honnêtement).

Cette fonctionnalité vous permet d'accéder à un service (comme une application Rails, dans cette question). Si le port n'est pas utilisé sur la carte réseau Windows, le WSL2 transfère automatiquement la requête de localhost vers le même port sur la carte réseau virtuelle du WSL2.

Tout va donc bien et vous pouvez accéder aux services WSL1 et WSL2 via localhost n'est-ce pas ?

Pas si vite, malheureusement. Parfois, comme deux autres réponses l'ont mentionné, localhostForwarding "pauses". Nous avons identifié deux cas d'utilisation très courants (et liés) où cela se produit :

• Lorsque l'hôte Windows est en hibernation.
• Lorsque l'hôte Windows est mis sous tension à l'aide de la fonction "Démarrage rapide" de Windows, qui s'avère être activée par défaut. Cette fonction utilise une forme d'hibernation.

La solution est la suivante :

• N'hibernez pas si possible
• Désactiver le démarrage rapide. Vous le trouverez dans le Panneau de configuration. Naviguez jusqu'à Matériel et son -> Options d'alimentation -> Modifier l'action des boutons d'alimentation
• Si vous vous retrouvez dans une situation où la fonctionnalité ne fonctionne pas, comme le mentionne la réponse de @AhmetK, vous pouvez généralement récupérer la redirection de l'hôte local :
  • Quitter toutes les instances WSL en cours d'exécution
  • Délivrance wsl --shutdown (à partir de PowerShell, CMD ou même du menu Démarrer). Bien qu'un redémarrage complet de Windows ait le même effet, un redémarrage de wsl --shutdown est beaucoup plus rapide.
  • Redémarrez votre instance WSL et les services/applications en cours d'exécution.

Voir les commentaires sur cette réponse de l'OS qui ont confirmé le problème et la solution.

Après avoir fonctionné correctement pendant un certain temps, j'ai eu ce problème sur Win10 19042 avec WSL2 après avoir installé Docker (la nouvelle version de WSL), et j'ai dû redémarrer mon ordinateur pour que localhost fonctionne à nouveau.