Freigeben über

Zugriff auf Netzwerkanwendungen mit WSL

  • Artikel

Beim Arbeiten mit Netzwerk-Apps und WSL sind einige Überlegungen zu berücksichtigen. WSL verwendet standardmäßig eine NAT-basierte Architektur, und wir empfehlen, den neuen gespiegelten Netzwerkmodus auszuprobieren, um die neuesten Features und Verbesserungen zu erhalten.

Ermitteln der IP-Adresse

Es gibt zwei Szenarien, die beim Identifizieren der IP-Adresse berücksichtigt werden müssen, die für eine über WSL ausgeführte Linux-Distribution verwendet wird:

Szenario 1: Aus Sicht des Windows-Hosts möchten Sie die IP-Adresse einer Linux-Verteilung abfragen, die über WSL2 ausgeführt wird, damit ein Programm auf dem Windows-Host eine Verbindung mit einem Serverprogramm herstellen kann, das innerhalb der Distribution (Instanz) ausgeführt wird.

Der Windows-Host kann folgenden Befehl verwenden:

wsl -d <DistributionName> hostname -I

Wenn Sie die Standarddistribution abfragen, kann dieser Teil des Befehls, der die Distribution angibt, weggelassen werden: -d <DistributionName>. Achten Sie darauf, ein -I-Flag mit Großbuchstaben und nicht -i mit Kleinbuchstaben zu verwenden.

Im Hintergrund startet der Hostbefehl wsl.exe die Zielinstanz und führt den Linux-Befehl hostname -I aus. Mit diesem Befehl wird dann die IP-Adresse der WSL-Instanz in STDOUT ausgegeben. Der STDOUT-Textinhalt wird dann zurück an „wsl.exe“ weitergeleitet. Schließlich zeigt „wsl.exe“ diese Ausgabe in der Befehlszeile an.

Beispiel für eine typische Ausgabe:

172.30.98.229

Szenario 2: Ein Programm, das in einer Linux-Distribution über WSL2 (Instanz) ausgeführt wird, möchte die IP-Adresse des Windows-Hosts kennen, damit ein Linux-Programm eine Verbindung mit einem Windows-Hostserverprogramm herstellen kann.

Der WSL2 Linux-Benutzer kann folgenden Befehl verwenden:

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

Beispiel für eine typische Ausgabe:

172.30.96.1

172.30.96.1 ist also die Host-IP-Adresse für Windows in diesem Beispiel.

Hinweis

Diese oben genannte IP-Adressabfrageaktion ist in der Regel erforderlich, wenn WSL2 mit dem standardmäßigen NAT-Netzwerkmodus ausgeführt wird. Wenn WSL2 mit dem neuen gespiegelten Modusausgeführt wird, können der Windows-Host und die WSL2-VM mithilfe von localhost (127.0.0.1) als Zieladresse eine Verbindung herstellen, es muss also nicht die IP-Adresse eines Abfragespeers verwendet werden.

Standardnetzwerkmodus: NAT

Standardmäßig verwendet WSL eine NAT-basierte Architektur (Network Address Translation) für Netzwerke. Beachten Sie die folgenden Überlegungen, wenn Sie mit einer NAT-basierten Netzwerkarchitektur arbeiten:

Zugreifen auf Linux-Netzwerk-Apps aus Windows (localhost)

Wenn Sie in Ihrer Linux-Verteilung eine Netzwerk-App (z. B. eine App, die auf einer NodeJS- oder SQL Server-Instanz ausgeführt wird) entwickeln, können Sie auf diese über eine Windows-App (z. B. Ihren Microsoft Edge- oder Chrome-Internetbrowser) unter Verwendung von localhost zugreifen (genau wie Sie dies normalerweise tun würden).

Zugreifen auf Windows-Netzwerk-Apps aus Linux (Host-IP)

Wenn Sie von Ihrer Linux-Verteilung (d. h. Ubuntu) aus, auf eine Netzwerk-App zugreifen möchten, die unter Windows ausgeführt wird (z. B. eine App, die auf einer NodeJS- oder SQL Server-Instanz ausgeführt wird), müssen Sie die IP-Adresse des Hostcomputers verwenden. Obwohl dies kein gängiges Szenario ist, können Sie die folgenden Schritte ausführen, damit es funktioniert.

  1. Rufen Sie die IP-Adresse Ihres Hostcomputers ab, indem Sie den folgenden Befehl aus Ihrer Linux-Verteilung heraus ausführen: ip route show | grep -i default | awk '{ print $3}'
  2. Stellen Sie mithilfe der kopierten IP-Adresse eine Verbindung zu jedem beliebigen Windows-Server her.

Die Abbildung zeigt ein Beispiel dafür – hier wird über curl eine Verbindung mit einem Node.js-Server hergestellt, der unter Windows ausgeführt wird.

Herstellen einer Verbindung mit dem NodeJS-Server in Windows über Curl

Verbinden über Remote-IP-Adressen

Wenn Sie Remote-IP-Adressen verwenden, um Verbindungen mit Ihren Anwendungen herzustellen, werden diese als Verbindungen aus dem LAN (Local Area Network) behandelt. Dies bedeutet, Sie müssen sicherstellen, dass Ihre Anwendung LAN-Verbindungen akzeptieren kann.

Sie müssen z. B. möglicherweise Ihre Anwendung an 0.0.0.0 statt an 127.0.0.1 binden. In dem Beispiel einer Python-App, die Flask verwendet, kann das mithilfe dieses Befehls erfolgen: app.run(host='0.0.0.0'). Achten Sie auf die Sicherheit, wenn Sie diese Änderungen vornehmen, da dadurch Verbindungen aus Ihrem LAN aus zugelassen werden.

Zugreifen auf eine WSL 2-Verteilung aus Ihrem LAN (Local Area Network)

Wenn Sie eine WSL 1-Verteilung verwenden und Ihr Computer so eingerichtet wurde, dass auf ihn über Ihr LAN zugegriffen wird, kann auf Anwendungen, die in WSL ausgeführt werden, in Ihrem LAN ebenfalls zugegriffen werden.

Dies ist nicht der Standardfall in WSL 2. WSL 2 verfügt über einen virtualisierten Ethernet-Adapter mit einer eigenen eindeutigen IP-Adresse. Um diesen Workflow zu aktivieren, müssen Sie aktuell die gleichen Schritte wie bei einem gewöhnlichen virtuellen Computer durchlaufen. (Wir untersuchen Möglichkeiten, dieses Verhalten zu verbessern.)

Hier ein Beispiel für die Verwendung des Windows-Befehls Netsh interface portproxy, um einen Portproxy hinzuzufügen, der am Hostport lauscht und diesen Portproxy mit der IP-Adresse des virtuellen WSL 2-Computers verbindet.

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

In diesem Beispiel müssen Sie <yourPortToForward> mit einer Portnummer aktualisieren, z. B. listenport=4000. listenaddress=0.0.0.0 bedeutet, dass eingehende Anforderungen von JEDER IP-Adresse akzeptiert werden. Die Listenadresse gibt die IPv4-Adresse an, die vom Listener überwacht werden soll, und kann in folgende Werte geändert werden: IP-Adresse, NetBIOS-Computername oder DNS-Name des Computers. Wenn keine Adresse angegeben ist, ist der Standardwert der lokale Computer. Sie müssen den <yourPortToConnectToInWSL>-Wert mit einer Portnummer aktualisieren, mit der WSL eine Verbindung herstellen soll, z. B. connectport=4000. Schließlich muss der connectaddress-Wert der IP-Adresse Ihrer Linux-Distribution entsprechen, die über WSL 2 (die WSL 2-VM-Adresse) installiert wurde und die durch Eingabe des folgenden Befehls ermittelt werden kann: wsl.exe hostname -I.

Dieser Befehl sieht in etwa wie folgt aus:

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

Verwenden Sie zum Abrufen der IP-Adresse Folgendes:

  • wsl hostname -I für die IP-Adresse Ihrer Linux-Distribution, die über WSL 2 installiert wurde (die WSL 2-VM-Adresse)
  • cat /etc/resolv.conf für die IP-Adresse des Windows-Computers aus Sicht von WSL 2 (die WSL 2-VM)

Bei Verwendung von listenaddress=0.0.0.0 wird an allen IPv4-Ports gelauscht.

Hinweis

Die Verwendung des Kleinbuchstabens „i“ mit dem hostname-Befehl führt zu einem anderen Ergebnis als die Verwendung des Großbuchstabens „I“. wsl hostname -i ist Ihr lokaler Computer (127.0.1.1 ist eine Platzhalterdiagnoseadresse), wohingegen wsl hostname -I die IP-Adresse Ihres lokalen Rechners zurückgibt, wie sie von anderen Rechnern gesehen wird und zur Identifizierung der connectaddress Ihrer Linux-Distribution verwendet werden sollte, die über WSL 2 läuft.

IPv6-Zugriff

  • wsl hostname -i für die IP-Adresse Ihrer Linux-Distribution, die über WSL 2 installiert wurde (die WSL 2-VM-Adresse)
  • ip route show | grep -i default | awk '{ print $3}' für die IP-Adresse des Windows-Computers aus Sicht von WSL 2 (die WSL 2-VM)

Bei Verwendung von listenaddress=0.0.0.0 wird an allen IPv4-Ports gelauscht.

Netzwerk im gespiegelten Modus

Auf Rechnern mit Windows 11 22H2 und höher können Sie networkingMode=mirrored unter [wsl2] in der Datei .wslconfig festlegen, um den gespiegelten Netzwerkmodus zu aktivieren. Durch die Aktivierung dieses Features wird WSL in eine völlig neue Netzwerkarchitektur geändert, die darauf abzielt, die unter Windows vorhandenen Netzwerkschnittstellen in Linux zu „spiegeln“, um neue Netzwerkfunktionen hinzuzufügen und die Kompatibilität zu verbessern.

Die Aktivierung dieses Modus bietet aktuell folgende Vorteile:

  • IPv6-Unterstützung
  • Verbinden mit Windows-Servern aus Linux mithilfe der Localhost-Adresse 127.0.0.1. Die IPv6-Localhost-Adresse ::1 wird nicht unterstützt.
  • Verbesserte Netzwerkkompatibilität für VPNs
  • Multicastunterstützung
  • Verbinden mit WSL direkt von Ihrem lokalen Netzwerk (LAN)

Hinweis

Führen Sie den folgenden Befehl mit Administratorrechten im PowerShell-Fenster aus, um Hyper-V-Firewalleinstellungen so zu konfigurieren, dass eingehende Verbindungen zugelassen werden: Set-NetFirewallHyperVVMSetting -Name '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -DefaultInboundAction Allow oder New-NetFirewallHyperVRule -Name "MyWebServer" -DisplayName "My Web Server" -Direction Inbound -VMCreatorId '{40E0AC32-46A5-438A-A0B2-2B479E8F2E90}' -Protocol TCP -LocalPorts 80.

Dieser neue Modus behebt Netzwerkprobleme, die bei Verwendung einer NAT-basierten Architektur (Network Address Translation) auftreten. Finden Sie bekannte Probleme oder protokollieren Sie Feedback zu identifizierten Fehlern im WSL-Produkt-Repository auf GitHub.

DNS-Tunneling

Auf Rechnern mit Windows 11 22H2 und höher bewirkt die Festlegung von dnsTunneling=true unter [wsl2] in der Datei .wslconfig, dass WSL eine Virtualisierungsfunktion verwendet, um DNS-Anforderungen von WSL aus zu beantworten, anstatt sie über ein Netzwerkpaket anzufordern. Dieses Feature zielt darauf ab, die Kompatibilität mit VPNs und anderen komplexen Netzwerkkonfigurationen zu verbessern.

Autoproxy

Auf Rechnern mit Windows 11 22H2 und höher erzwingt die Festlegung von autoProxy=true unter [wsl2] in der Datei .wslconfig, dass WSL die HTTP-Proxy-Informationen von Windows verwendet. Wenn Sie bereits in Windows einen Proxy eingerichtet haben, wird durch Aktivieren dieses Feature dieser Proxy auch automatisch in WSL festgelegt.

WSL und Firewall

Auf Computern mit Windows 11 22H2 und höher mit WSL 2.0.9 und höher wird das Hyper-V-Firewallfeature standardmäßig aktiviert. Dadurch wird Folgendes sichergestellt: