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.

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

Sie können networkingMode=mirrored unter [wsl2] in der .wslconfig-Datei 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

Die Festlegung von dnsTunneling=true unter [wsl2] in der .wslconfig-Datei bewirkt, dass WSL ein Virtualisierungsfeature verwendet, um DNS-Anforderungen innerhalb von WSL zu beantworten, anstatt diese über ein Netzwerkpaket anzufordern. Dieses Feature zielt darauf ab, die Kompatibilität mit VPNs und anderen komplexen Netzwerkkonfigurationen zu verbessern.

Autoproxy

Durch Festlegen von autoProxy=true unter [wsl2] in der .wslconfig-Datei wird WSL gezwungen, die HTTP-Proxyinformationen von Windows zu verwenden. 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: