Training
Lernpfad
Konfigurieren von Netzwerken auf Windows Clients - Training
MD-100 Konfigurieren von Netzwerken auf Windows Clients
Dieser Browser wird nicht mehr unterstützt.
Führen Sie ein Upgrade auf Microsoft Edge durch, um die neuesten Features, Sicherheitsupdates und den technischen Support zu nutzen.
Im Folgenden werden einige häufige Problembehandlungsszenarien im Zusammenhang mit WSL behandelt. Sie sollten jedoch auch die im WSL-Produkt-Repository auf GitHub aufgeführten Probleme durchsuchen.
Die Probleme im WSL-Produkt-Repository ermöglichen Ihnen Folgendes:
cmd.exe /c ver
aus, um die aktuelle Buildnummer anzuzeigen), ob Sie WSL 1 oder 2 ausführen, Ihre aktuelle Linux-Kernelversionsnummer (führen Sie wsl.exe --status
oder cat /proc/version
aus), die Versionsnummer Ihrer Verteilung (führen Sie lsb_release -r
aus), alle anderen beteiligten Softwareversionen, die Reproduktionsschritte, das erwartete Verhalten, das tatsächliche Verhalten und die Diagnoseprotokolle, falls verfügbar und angemessen. Weitere Informationen finden Sie unter Mitwirken an WSL.Sie können außerdem:
Installation failed with error 0x80070003 (Installationsfehler mit Fehlercode 0x80070003)
C:
). Stellen Sie sicher, dass die Verteilungen auf dem Systemlaufwerk gespeichert sind:WslRegisterDistribution failed with error 0x8007019e (WslRegisterDistribution-Fehler mit Fehlercode 0x8007019e)
Fehler 0x80070003 oder Fehler 0x80370102 während der Installation
Fehler beim Upgradeversuch: Invalid command line option: wsl --set-version Ubuntu 2
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
.Der angeforderte Vorgang konnte aufgrund einer Einschränkung des virtuellen Dateisystems nicht abgeschlossen werden. Dateien für virtuelle Festplatten müssen unkomprimiert und unverschlüsselt sein und dürfen keine geringe Dichte aufweisen.
%USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited...
.wsl --set-version
funktionieren.Hinweis
In meinem Fall befand sich der Ordner „LocalState“ für meine Ubuntu 18.04-Verteilung unter „C:\Users<my-user-name>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc“.
Prüfen Sie den GitHub-Thread #4103 in der WSL-Dokumentation, der diesem Thema gewidmet ist, auf aktualisierte Informationen.
Der Ausdruck 'wsl' wurde nicht als Name eines Cmdlets, einer Funktion, einer Skriptdatei oder eines ausführbaren Programms erkannt.
wsl.exe
in PowerShell Core oder einer Eingabeaufforderung aus.Fehler: Für das Windows-Subsystem für Linux wurden keine Distributionen installiert.
\Windows\sysnative
. Beachten Sie, dass dieser auf dem Datenträger nicht tatsächlich vorhanden ist, die Pfadauflösung des Dateisystems findet ihn aber.Error: Dieses Update gilt nur für Computer mit dem Windows-Subsystem für Linux.
This update only applies to machines with the Windows Subsystem for Linux
.Sie befinden sich immer noch in der alten Version von Windows, die WSL 2 nicht unterstützt. In Schritt 2 finden Sie Versionsanforderungen und Links zum Update.
WSL ist nicht aktiviert. Sie müssen zu Schritt 1 zurückkehren und sicherstellen, dass das optionale WSL-Feature auf Ihrem Computer aktiviert ist.
Nachdem Sie WSL aktiviert haben, muss ein Neustart durchgeführt werden, damit es wirksam wird. Starten Sie den Computer neu, und wiederholen Sie den Vorgang.
Fehler: WSL 2 erfordert ein Update der zugehörigen Kernel-Komponente. Weitere Informationen finden Sie unter https://aka.ms/wsl2kernel.
Dies liegt wahrscheinlich daran, dass auf Ihrem Computer der Backport für WSL 2 noch nicht eingerichtet ist. Die einfachste Möglichkeit zur Lösung des Problems besteht darin, zu den Windows-Einstellungen zu wechseln und auf „Nach Updates suchen“ zu klicken, um die neuesten Updates auf Ihrem System zu installieren. Schauen Sie sich die vollständigen Anweisungen zur Einrichtung des Backports finden an.
Wenn Sie auf „Nach Updates suchen“ klicken und das Update immer noch nicht erhalten, können Sie KB4566116 manuell installieren.
Dies kann vorkommen, wenn die Einstellung „Anzeigesprache“ oder „Systemgebietsschema“ nicht auf Englisch festgelegt ist.
wsl --set-default-version 2
Error: 0x1bc
For information on key differences with WSL 2 please visit https://aka.ms/wsl2
Der tatsächliche Fehler für 0x1bc
lautet:
WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel
Weitere Informationen finden Sie im Problem 5749.
Ein 9p-Protokolldateiserver stellt den Dienst auf der Linux-Seite bereit, um Windows den Zugriff auf das Linux-Dateisystem zu ermöglichen. Wenn Sie nicht über \\wsl$
unter Windows auf WSL zugreifen können, kann dies daran liegen, dass 9P nicht ordnungsgemäß gestartet wurde.
Um dies zu überprüfen, können Sie die Startprotokolle mit dmesg |grep 9p
überprüfen. Dadurch werden Fehler angezeigt. Eine erfolgreiche Ausgabe sieht wie folgt aus:
[ 0.363323] 9p: Installing v9fs 9p2000 file system support
[ 0.363336] FS-Cache: Netfs '9p' registered for caching
[ 0.398989] 9pnet: Installing 9P2000 support
Weitere Informationen zu diesem Problem finden Sie in diesem GitHub-Thread.
Wenn Ihre Anzeigesprache nicht Englisch ist, sehen Sie möglicherweise eine abgeschnittene Version eines Fehlertexts.
C:\Users\me>wsl
WSL 2
Um dieses Problem zu beheben, navigieren Sie zu https://aka.ms/wsl2kernel
, und installieren Sie den Kernel manuell, indem Sie die Anweisungen auf der doc-Seite befolgen.
Benutzer können ausführbare Windows-Programmdateien wie „notepad.exe“ direkt aus Linux ausführen. Manchmal kann es vorkommen, dass "Befehl nicht gefunden" angezeigt wird, wie unten dargestellt:
$ notepad.exe
-bash: notepad.exe: command not found
Wenn es keine Win32-Pfade in Ihrem $PATH gibt, findet interop die EXE-Datei nicht.
Sie können dies überprüfen, indem Sie echo $PATH
in Linux ausführen. In der Ausgabe sollte ein Win32-Pfad (z. B. „/mnt/c/Windows“) angezeigt werden.
Werden keine Windows-Pfade angezeigt, wird Ihr PATH höchstwahrscheinlich von Ihrer Linux-Shell außer Kraft gesetzt.
Im folgenden Beispiel hat „/etc/profile“ auf Debian zu diesem Problem beigetragen:
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games"
fi
Die richtige Vorgehensweise unter Debian besteht darin, die obigen Zeilen zu entfernen. Sie können auch $PATH während der Zuweisung anhängen, wie unten beschrieben, aber das führt zu einigen anderen Problemen mit WSL und VSCode.
if [ "`id -u`" -eq 0 ]; then
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:$PATH"
else
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:$PATH"
fi
Weitere Informationen finden Sie unter den Problemen 5296 und 5779.
Aktivieren Sie das Windows-Feature "Virtual Machine Platform", und stellen Sie sicher, dass Virtualisierung im BIOS aktiviert ist.
Klicken Sie auf Systemanforderungen von Hyper-V.
Wenn es sich bei dem Computer um einen virtuellen Computer handelt, aktivieren Sie die geschachtelte Virtualisierung manuell. Starten Sie PowerShell mit Administrator, und führen Sie den folgenden Befehl aus, und ersetzen Sie <VMName>
mit den Namem des virtuellen Computers auf Ihrem Hostsystem (Sie finden den Namen in Ihrem Hyper-V-Manager):
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
Befolgen Sie die Richtlinien des Herstellers Ihres PCs, um zu erfahren, wie Sie die Virtualisierung aktivieren. Dadurch müssen Sie möglicherweise den System-BIOS verwenden, um sicherzustellen, dass diese Features auf Ihrer CPU aktiviert sind. Die Anweisungen für diesen Prozess können von Computer zu Computer variieren. In diesem Artikel von Bleeping Computer finden Sie ein Beispiel.
Starten Sie den Computer neu, nachdem Sie die optionale Virtual Machine Platform
-Komponente aktiviert haben.
Vergewissern Sie sich, dass der Hypervisorstart in Ihrer Startkonfiguration aktiviert ist. Sie können dies überprüfen, indem Sie (PowerShell mit erhöhten Rechten) ausführen:
bcdedit /enum | findstr -i hypervisorlaunchtype
Wenn Sie hypervisorlaunchtype Off
sehen, ist der Hypervisor deaktiviert. Zum Aktivieren führen Sie dies in einer PowerShell mit erhöhten Rechten aus:
bcdedit /set hypervisorlaunchtype Auto
Wenn Sie Hypervisoren von Drittanbietern installiert haben (z. B. VMware oder VirtualBox), müssen Sie außerdem sicherstellen, dass Sie die neuesten Versionen verwenden, die HyperV unterstützen (VMware 15.5.5+ und VirtualBox 6+), oder dass diese deaktiviert sind.
Wenn Sie diesen Fehler auf einem virtuellen Azure-Computer erhalten, überprüfen Sie, ob Vertrauenswürdiger Start deaktiviert ist. Geschachtelte Virtualisierung wird auf virtuellen Azure-Computern nicht unterstützt.
Erfahren Sie mehr über das Konfigurieren der geschachtelten Virtualisierung beim Ausführen von Hyper-V auf einem virtuellen Computer.
In Geschäfts- oder Unternehmensumgebungen sind möglicherweise Einstellungen für die Windows Defender Firewall konfiguriert, um nicht autorisierten Netzwerkdatenverkehr zu blockieren. Wenn das Zusammenführen lokaler Regeln auf „Nein“ festgelegt ist, kann das WSL-Netzwerk standardmäßig nicht verwendet werden, und Ihr Administrator muss eine Firewallregel hinzufügen, um die Verbindung zuzulassen.
Sie können die Einstellung für das Zusammenführen lokaler Regeln bestätigen, indem Sie die folgenden Schritte ausführen:
Anweisungen zum Ändern dieser Firewalleinstellung finden Sie unter Konfigurieren der Hyper-V-Firewall.
Wenn Bash nach dem Herstellen einer Verbindung mit einem VPN unter Windows die Netzwerkkonnektivität verliert, können Sie diese Problemumgehung innerhalb von Bash versuchen. Mit dieser Problemumgehung können Sie die DNS-Auflösung manuell durch /etc/resolv.conf
außer Kraft setzen.
ipconfig.exe /all
).sudo cp /etc/resolv.conf /etc/resolv.conf.new
).sudo unlink /etc/resolv.conf
).sudo mv /etc/resolv.conf.new /etc/resolv.conf
/etc/wsl.conf
, und fügen Sie diesen Inhalt zur Datei hinzu. (Weitere Informationen zu diesem Setup finden Sie in der Konfiguration der erweiterte Einstellungen.)[network]
generateResolvConf=false
/etc/resolv.conf
und Nachdem Sie die Verbindung mit dem VPN getrennt haben, müssen Sie die Änderungen auf /etc/resolv.conf
zurücksetzen. Gehen Sie dazu folgendermaßen vor:
cd /etc
sudo mv resolv.conf resolv.conf.new
sudo ln -s ../run/resolvconf/resolv.conf resolv.conf
Cisco AnyConnect VPN ändert Routen auf eine Weise, die verhindert, dass NAT funktioniert. Es gibt eine Problemumgehung spezifisch für WSL 2: Siehe Cisco AnyConnect Secure Mobility Client-Administratorhandbuch, Release 4.10 – Problembehandlung von AnyConnect.
Der Netzwerkmodus „Gespiegelt“ ist derzeit eine experimentelle Einstellung in der WSL-Konfiguration. Die herkömmliche NAT-Netzwerkarchitektur von WSL kann auf einen völlig neuen Netzwerkmodus aktualisiert werden, der als „Gespiegelter Netzwerkmodus“ bezeichnet wird. Wenn der experimentelle networkingMode
auf mirrored
festgelegt ist, werden die Netzwerkschnittstellen, die Sie unter Windows haben, in Linux gespiegelt, um die Kompatibilität zu verbessern. Weitere Informationen finden Sie im Befehlszeilenblog: WSL-Update vom September 2023.
Einige VPNs wurden getestet und als nicht kompatibel mit WSL bezeichnet, darunter:
Die HTTP/S-Proxyspiegelung kann mithilfe der autoProxy
-Einstellung im experimentellen Abschnitt der WSL-Konfigurationsdatei konfiguriert werden. Bei der Anwendung dieser Einstellung sind folgende Punkte zu beachten:
Wenn diese Option aktiviert ist, gilt Folgendes für Proxyeinstellungen für Ihre Linux-Distributionen:
HTTP_PROXY
ist auf einen oder mehrere HTTP-Proxys festgelegt, die in der Windows-HTTP-Proxykonfiguration gefunden werden.HTTPS_PROXY
S-Proxys festgelegt, die in der Windows-HTTP-Proxykonfiguration gefunden werden.NO_PROXY
ist so festgelegt, dass alle HTTP/S-Proxys umgangen werden, die in den Windows-Konfigurationszielen gefunden werden.WSL_PAC_URL
ist sowohl auf Groß- als auch auf Kleinschreibung festgelegt. Beispiel: HTTP_PROXY
und http_proxy
.Es gibt ein bekanntes Problem, das durch ZScaler-Konfigurationen verursacht wird, bei dem ZScaler wiederholt Windows-Proxy-Konfigurationen aktiviert und deaktiviert, was dazu führt, dass WSL wiederholt die Meldung „Eine Http-Proxy-Änderung wurde auf dem Host erkannt“ anzeigt.
Weitere Informationen finden Sie im Befehlszeilenblog: WSL-Update vom September 2023.
Wenn WSL keine Verbindung mit dem Internet herstellen kann, liegt dies möglicherweise daran, dass der DNS-Aufruf an den Windows-Host blockiert ist. Dies liegt daran, dass das Netzwerkpaket für DNS, das von der WSL-VM an den Windows-Host gesendet wird, durch die vorhandene Netzwerkkonfiguration blockiert wird. Durch DNS-Tunneling wird dies mithilfe eines Virtualisierungsfeatures für die direkte Kommunikation mit Windows behoben, sodass der DNS-Name aufgelöst werden kann, ohne ein Netzwerkpaket zu senden. Dieses Feature sollte die Netzwerkkompatibilität verbessern und es Ihnen ermöglichen, eine bessere Internetverbindung zu erzielen, auch wenn Sie über ein VPN, ein bestimmtes Firewallsetup oder andere Netzwerkkonfigurationen verfügen.
DNS-Tunneling kann mithilfe der dnsTunneling
-Einstellung im experimentellen Abschnitt der WSL-Konfigurationsdatei konfiguriert werden. Bei der Anwendung dieser Einstellung sind folgende Punkte zu beachten:
/etc/resolv.conf
-Datei in Ihrer Linux-Verteilung hat eine maximale Beschränkung auf 3 DNS-Server, während Windows möglicherweise mehr als 3 DNS-Server verwendet. Die Verwendung von DNS-Tunneling entfernt diese Einschränkung – alle Windows-DNS-Server können jetzt von Linux verwendet werden.Weitere Informationen finden Sie im Befehlszeilenblog: WSL-Update vom September 2023.
Bei Verwendung des Netzwerkmodus „Gespiegelt“ (der experimentelle networkingMode
ist auf mirrored
festgelegt) wird ein Teil des eingehenden Datenverkehrs, der vom Windows-Host empfangen wird, niemals auf die Linux-VM geleitet. Dieser Datenverkehr ist wie folgt:
WSL wird bei Verwendung des gespiegelten Netzwerkmodus automatisch bestimmte Linux-Netzwerkeinstellungen konfigurieren. Alle Benutzerkonfigurationen dieser Einstellungen werden beim Verwenden des gespiegelten Netzwerkmodus nicht unterstützt. Hier ist die Liste der Einstellungen, die WSL konfigurieren wird:
Einstellungsname | Wert |
---|---|
https://sysctl-explorer.net/net/ipv4/accept_local/ | Aktiviert (1) |
https://sysctl-explorer.net/net/ipv4/route_localnet/ | Aktiviert (1) |
https://sysctl-explorer.net/net/ipv4/rp_filter/ | Deaktiviert (0) |
https://sysctl-explorer.net/net/ipv6/accept_ra/ | Deaktiviert (0) |
https://sysctl-explorer.net/net/ipv6/autoconf/ | Deaktiviert (0) |
https://sysctl-explorer.net/net/ipv6/use_tempaddr/ | Deaktiviert (0) |
addr_gen_mode | Deaktiviert (0) |
disable_ipv6 | Deaktiviert (0) |
https://sysctl-explorer.net/net/ipv4/arp_filter/ | Aktiviert (1) |
Es gibt ein bekanntes Problem, bei dem Docker Desktop-Container mit veröffentlichten Ports (docker run –publish/-p) nicht erstellt werden können. Das WSL-Team arbeitet mit dem Docker Desktop-Team zusammen, um dieses Problem zu beheben. Um das Problem zu umgehen, verwenden Sie den Netzwerknamespace des Hosts im Docker-Container. Legen Sie den Netzwerktyp über die Option „--network host“ fest, die im Befehl „docker run“ verwendet wird. Eine alternative Problemumgehung besteht darin, die veröffentlichte Portnummer in der ignoredPorts
-Einstellung des experimentellen Abschnitts in der WSL-Konfigurationsdatei aufzulisten.
Es gibt ein bekanntes Problem mit Docker-Containern, die den Netzwerk-Manager-Dienst ausführen. Zu den Symptomen gehören Fehler beim Versuch, Loopbackverbindungen mit dem Host herzustellen. Es wird empfohlen, den Netzwerk-Manager-Dienst für WSL-Netzwerke zu beenden, damit er ordnungsgemäß konfiguriert werden kann.
sudo systemctl disable network-manager.service
Um Hostnamen in IP-Adressen innerhalb eines lokalen Netzwerks aufzulösen, ohne dass ein herkömmlicher DNS-Server erforderlich ist, werden häufig .local names verwendet. Dies wird über das mDNS-Protokoll (Multicast DNS) erreicht, das auf Multicastdatenverkehr basiert, um zu funktionieren.
networkingMode auf NAT festgelegt:
Derzeit wird dieses Feature nicht unterstützt, wenn DNS-Tunneling aktiviert ist. Um die Auflösung von .local names zu aktivieren, empfehlen wir die folgenden Lösungen:
networkingMode auf "Gespiegelt" festgelegt:
Hinweis: Sie müssen sich auf WSL Build 2.3.17 oder höher befinden, um die unten aufgeführten Funktionen zu erhalten.
Da der gespiegelte Modus Multicastdatenverkehr unterstützt, kann das mDNS -Protokoll (Multicast DNS) verwendet werden, um .local names aufzulösen. Linux muss so konfiguriert sein, dass mDNS unterstützt wird, da dies nicht standardmäßig der Fall ist. Eine Möglichkeit, es zu konfigurieren, kann durch das Befolgen dieser beiden Schritte erfolgen:
sudo apt-get install libnss-mdns
*Das Paket "libnss-mdns" ist ein Plugin für die GNU Name Service Switch (NSS)-Funktionalität der GNU C Library (glibc), die Hostnamenauflösung über Multicast DNS (mDNS) bereitstellt. Dieses Paket ermöglicht es effektiv gängige Unix/Linux-Programme, Namen in der Ad-hoc-mDNS-Domäne .local aufzulösen.
/etc/nsswitch.conf
-Datei, um die Einstellung "mdns_minimal" im Abschnitt "Hosts" zu aktivieren. Beispielinhalt der Datei:cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.
passwd: compat systemd
group: compat systemd
shadow: compat
gshadow: files
hosts: files mdns_minimal [NOTFOUND=return] dns
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis
Abhängig von den Konfigurationen in der Wslconfig-Datei verfügt WSL über das folgende Verhalten von DNS-Suffixen:
Wenn networkingMode auf NAT festgelegt ist:
Fall 1) Standardmäßig ist kein DNS-Suffix in Linux konfiguriert
Fall 2) Wenn DNS-Tunneling aktiviert ist (dnsTunneling ist in .wslconfig auf true gesetzt), werden alle Windows-DNS-Suffixe unter Linux in der Einstellung „search“ in /etc/resolv.conf konfiguriert
Die Suffixe sind in /etc/resolv.conf in der folgenden Reihenfolge konfiguriert, ähnlich der Reihenfolge, in der Windows DNS-Client Suffixe beim Auflösen eines Namens versucht: globale DNS-Suffixe zuerst, dann ergänzende DNS-Suffixe und dann pro Schnittstelle DNS-Suffixe.
Wenn es eine Änderung in den Windows-DNS-Suffixen gibt, wird diese Änderung automatisch in Linux widergespiegelt
Fall 3) Wenn DNS-Tunneling deaktiviert ist und der SharedAccess-DNS-Proxy deaktiviert ist (dnsTunneling ist in .wslconfig auf false und dnsProxy auf false gesetzt), wird unter Linux in der Einstellung „domain“ von /etc/resolv.conf ein einziger DNS-Suffix konfiguriert
Wenn es eine Änderung in den Windows-DNS-Suffixen gibt, wird diese Änderung nicht in Linux widergespiegelt
Das in Linux konfigurierte einzelne DNS-Suffix wird aus den DNS-Suffixen pro Schnittstelle ausgewählt (globale und ergänzende Suffixe werden ignoriert)
Wenn Windows über mehrere Schnittstellen verfügt, wird eine Heuristik verwendet, um das einzelne DNS-Suffix auszuwählen, das in Linux konfiguriert wird. Wenn beispielsweise eine VPN-Schnittstelle unter Windows vorhanden ist, wird das Suffix von dieser Schnittstelle ausgewählt. Wenn keine VPN-Schnittstelle vorhanden ist, wird das Suffix von der Schnittstelle ausgewählt, die höchstwahrscheinlich eine Internetverbindung gibt.
Wenn networkingMode auf Mirrored festgelegt ist:
Alle Windows-DNS-Suffixe sind in Linux konfiguriert, in der Einstellung „search“ von /etc/resolv.conf
Die Suffixe sind in /etc/resolv.conf in der gleichen Reihenfolge wie bei 2) aus dem NAT-Modus konfiguriert
Wenn es eine Änderung in den Windows-DNS-Suffixen gibt, wird diese Änderung automatisch in Linux widergespiegelt
Hinweis: Ergänzende DNS-Suffixe können in Windows mit SetInterfaceDnsSettings - Win32-Apps konfiguriert werden | Microsoft Learn mit dem Flag DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST, das im Parameter Einstellungen festgelegt ist
Die standardmäßige DNS-Konfiguration, wenn WSL einen Container im NAT-Modus startet, besteht darin, dass das NAT-Gerät auf dem Windows-Host als DNS-'Server' für den WSL-Container dient. Wenn DNS-Abfragen vom WSL-Container an dieses NAT-Gerät auf dem Windows-Host gesendet werden, wird das DNS-Paket vom NAT-Gerät an den freigegebenen Zugriffsdienst auf dem Host weitergeleitet; die Antwort wird in umgekehrter Richtung zurück an den WSL-Container gesendet. Für diesen Paketweiterleitungsprozess für den freigegebenen Zugriff ist eine Firewallregel erforderlich, um dieses eingehende DNS-Paket zuzulassen, das vom HNS-Dienst erstellt wird, wenn WSL zunächst HNS fragt, das virtuelle NAT-Netzwerk für seinen WSL-Container zu erstellen.
Aufgrund dieses NAT-freigegebenen Zugriffsdesigns gibt es einige bekannte Konfigurationen, die die Namensauflösung von WSL unterbrechen können.
1. Ein Unternehmen kann Eine Richtlinie pushen, die keine lokal definierten Firewallregeln zulässt, und nur unternehmensrichtliniendefinierte Regeln zulassen.
Wenn dies von einem Unternehmen festgelegt wird, wird die von HNS erstellte Firewallregel ignoriert, da es sich um eine lokal definierte Regel handelt. Damit diese Konfiguration funktioniert, muss das Unternehmen eine Firewallregel erstellen, um UDP-Port 53 für den freigegebenen Zugriffsdienst zuzulassen, oder WSL kann für die Verwendung von DNS-Tunneling festgelegt werden. Sie können sehen, ob dies so konfiguriert ist, dass lokal definierte Firewallregeln nicht zulässig sind, indem Sie Folgendes ausführen. Beachten Sie, dass dadurch Einstellungen für alle drei Profile angezeigt werden: Domain, Privat und Öffentlich. Wenn es für ein Profil festgelegt ist, werden Pakete blockiert, wenn dem Profil die WSL-vNIC zugewiesen ist (Standardeinstellung ist Öffentlich). Dies ist nur ein Codeausschnitt des ersten Firewallprofils, das in Powershell zurückgegeben wird:
PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name : Domain
Enabled : True
DefaultInboundAction : Block
DefaultOutboundAction : Allow
AllowInboundRules : True
AllowLocalFirewallRules : False
AllowLocalFirewallRules:False means the locally defined firewall rules, like that by HNS, will not be applied or used.
2. Und Enterprise kann Gruppenrichtlinien- und MDM-Richtlinieneinstellungen drücken, die alle eingehenden Regeln blockieren.
Diese Einstellungen haben Vorrang vor allen Firewallregeln, die den Eingang zulassen. Diese Einstellung blockiert somit die von HNS erstellte UDP-Firewallregel und verhindert daher, dass WSL Namen auflösen kann. Damit diese Konfiguration funktioniert, muss WSL für die Verwendung von DNS-Tunneling festgelegt werden. Diese Einstellung blockiert immer den NAT-DNS-Proxy.
Aus Gruppenrichtlinie:
Computerkonfiguration \ Administrative Vorlagen \ Netzwerk \ Netzwerkverbindungen \ Windows Defender Firewall \ Domainprofil | Standardprofil
„Windows Defender Firewall: Keine Ausnahmen zulassen“ – Aktiviert
Aus MDM-Richtlinie:
./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/Shielded
./Vendor/MSFT/Firewall/MdmStore/DomainProfile/Shielded
./Vendor/MSFT/Firewall/MdmStore/PublicProfile/Shielded
Sie können sehen, ob dies so konfiguriert ist, dass eingehende Firewallregeln nicht zulässig sind, indem Sie folgendes ausführen (siehe oben beschriebene Einschränkungen in Firewallprofilen). Dies ist nur ein Codeausschnitt des ersten Firewallprofils, das in Powershell zurückgegeben wird:
PS C:\> Get-NetFirewallProfile -PolicyStore ActiveStore
Name : Domain
Enabled : True
DefaultInboundAction : Block
DefaultOutboundAction : Allow
AllowInboundRules : False
AllowInboundRules: False means that no inbound Firewall rules will be applied.
3. Ein Benutzer durchläuft die Windows-Sicherheit Einstellungs-Apps und überprüft das Steuerelement auf „Blockiert alle eingehenden Verbindungen, einschließlich derjenigen in der Liste der zulässigen Apps“.
Windows unterstützt eine Benutzer-Opt-In für dieselbe Einstellung, die von einem Enterprise-Element angewendet werden kann, auf das oben in #2 verwiesen wird. Benutzer können die Einstellungsseite „Windows-Sicherheit“ öffnen, die Option „Firewall & Netzwerkschutz“ auswählen, das Firewallprofil auswählen, das sie konfigurieren möchten (Domain, Privat oder Öffentlich), und unter „Eingehende Verbindungen“ das Steuerelement mit der Bezeichnung „Blockiert alle eingehenden Verbindungen, einschließlich derjenigen in der Liste der zulässigen Apps“ aktivieren.
Wenn dies für das öffentliche Profil festgelegt ist (dies ist das Standardprofil für die WSL vNIC), wird die Firewallregel, die von HNS erstellt wurde, blockiert, damit die UDP-Pakete gemeinsam genutzt werden können.
Dies muss deaktiviert sein, damit die NAT-DNS-Proxykonfiguration von WSL funktioniert, oder WSL kann für die Verwendung von DNS-Tunneling festgelegt werden.
4. Die HNS-Firewallregel, damit die DNS-Pakete für den freigegebenen Zugriff ungültig werden können und auf einen vorherigen WSL-Schnittstellenbezeichner verweisen. Dies ist ein Fehler in HNS, der mit der neuesten Windows 11-Version behoben wurde. In früheren Versionen ist dies nicht leicht zu erkennen, aber es gibt eine einfache Lösung dafür:
WSL beenden
wsl.exe –shutdown
Löschen Sie die alte HNS-Firewallregel. Dieser PowerShell-Befehl sollte in den meisten Fällen funktionieren:
Get-NetFirewallRule -Name "HNS*" | Get-NetFirewallPortFilter | where Protocol -eq UDP | where LocalPort -eq 53 | Remove-NetFirewallRule
Entfernen Sie alle HNS-Endpunkte. Hinweis: Wenn HNS zum Verwalten anderer Container wie MDAG oder Windows-Sandbox verwendet wird, sollten diese ebenfalls beendet werden.
hnsdiag.exe delete all
Starten oder rebooten Sie den HNS-Dienst neu
Restart-Service hns
Wenn WSL neu gestartet wird, erstellt HNS neue Firewallregeln, die korrekt auf die WSL-Schnittstelle ausgerichtet sind.
Wenn Sie keinen Netzwerkzugriff haben, kann dies auf eine Fehlkonfiguration zurückzuführen sein. Überprüfen Sie, ob der FSE-Treiber ausgeführt wird: „sc queryex FSE“. Wenn FSE nicht ausgeführt wird, überprüfen Sie, ob der PortTrackerEnabledMode-Registrierungswert unter diesem Registrierungsschlüssel vorhanden ist: reg query HKLM\System\CurrentControlSet\Services\Tcpip\Parameters. Wenn FSE nicht ausgeführt oder installiert ist und PortTrackerEnabledMode vorhanden ist, löschen Sie diesen Registrierungswert und starten Sie es neu.
Ghost-Adapter, die auch als Phantom-Plug-and-Play-Geräte (PnP) bezeichnet werden, beziehen sich auf Hardwarekomponenten, die in Ihrem System angezeigt werden, aber nicht physisch verbunden sind. Diese „Ghost“-Geräte können Verwirrung und Unübersichtlichkeit in Ihren Systemeinstellungen verursachen. Wenn beim Ausführen von WSL auf einem virtuellen Computer (VM) Ghost-Adapter angezeigt werden, führen Sie diese manuellen Schritte aus, um diese Phantom-PnP-Geräte zu suchen und zu löschen. Microsoft arbeitet an einer automatisierten Lösung, die keinen manuellen Eingriff erfordert. Weitere Informationen werden in Kürze verfügbar sein.
Befolgen Sie die Anweisungen zum Sammeln von WSL-Protokollen im WSL-Repository auf GitHub, um detaillierte Protokolle zu sammeln und ein Problem auf unserem GitHub einzureichen.
Es gibt zwei Komponenten des Windows-Subsystems für Linux, die eine Aktualisierung erfordern können.
Um das Windows-Subsystem für Linux selbst zu aktualisieren, verwenden Sie den Befehl wsl --update
in PowerShell oder CMD.
Um die spezifischen Benutzerbinärdateien der Linux-Verteilung zu aktualisieren, verwenden Sie den Befehl apt-get update | apt-get upgrade
in der Linux-Verteilung, die Sie aktualisieren möchten.
In einigen Paketen werden Features verwendet, die noch nicht implementiert wurden. udev
wird z.B. noch nicht unterstützt und verursacht mehrere apt-get upgrade
-Fehler.
Führen Sie die folgenden Schritte aus, um Probleme im Zusammenhang mit udev
zu beheben:
Schreiben Sie Folgendes in /usr/sbin/policy-rc.d
, und speichern Sie die Änderungen.
#!/bin/sh
exit 101
Fügen Sie /usr/sbin/policy-rc.d
Ausführungsberechtigungen hinzu:
chmod +x /usr/sbin/policy-rc.d
Führen Sie die folgenden Befehle aus:
dpkg-divert --local --rename --add /sbin/initctl
ln -s /bin/true /sbin/initctl
Dies hat mit der Tatsache zu tun, dass die Legacykonsole nicht unterstützt wird. So deaktivieren Sie die Legacykonsole:
Das Feature „Windows-Subsystem für Linux“ ist möglicherweise während eines Windows-Updates deaktiviert. Wenn dies der Fall ist, muss das Windows-Feature erneut aktiviert werden. Anweisungen zum Aktivieren des Windows-Subsystems für Linux finden Sie im Leitfaden zur manuellen Installation.
Die WSL-Installation versucht, das Ubuntu-Gebietsschema automatisch so zu ändern, dass es dem Gebietsschema Ihrer Windows-Installation entspricht. Wenn Sie dieses Verhalten nicht wünschen, können Sie diesen Befehl ausführen, um das Ubuntu-Gebietsschema zu ändern, nachdem die Installation abgeschlossen wurde. Sie müssen „bash.exe“ neu starten, damit diese Änderung wirksam wird.
Im folgenden Beispiel wird das Gebietsschema in en-US
geändert:
sudo update-locale LANG=en_US.UTF8
%windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux
. Einige Benutzer haben Probleme mit bestimmten Firewallanwendungen gemeldet, die den Internetzugriff in WSL blockieren. Die gemeldeten Firewalls sind:
In einigen Fällen ermöglicht das Deaktivieren der Firewall den Zugriff. In einigen Fällen sieht es so aus, als ob bereits die Installation der Firewall den Zugriff blockiert.
Wenn Sie Microsoft Defender Firewall verwenden, wird der Zugriff durch Deaktivieren des Kontrollkästchens „Blockiert alle eingehenden Verbindungen, einschließlich der in der Liste zugelassener Apps“ ermöglicht.
Für Windows Anniversary Update, Version 1607, sind Administratorberechtigungen in Windows erforderlich, um Ping in WSL auszuführen. Um Ping auszuführen, führen Sie Bash unter Ubuntu unter Windows als Administrator aus, oder starten Sie „bash.exe“ über eine CMD-/PowerShell-Eingabeaufforderung mit Administratorrechten.
Für spätere Versionen von Windows, ab Build 14926, sind Administratorberechtigungen nicht mehr erforderlich.
Wenn Sie beim Arbeiten mit Bash feststellen, dass Bash hängt (oder blockiert ist) und nicht mehr auf Eingaben reagiert, helfen Sie uns, das Problem zu diagnostizieren, indem Sie ein Speicherabbild erfassen und melden. Beachten Sie, dass diese Schritte zu einem Absturz Ihres Systems führen. Unterlassen Sie dies, wenn Sie damit nicht einverstanden sind, oder speichern Sie Ihre Arbeit zuvor.
So erfassen Sie ein Speicherabbild
Ändern Sie den Typ des Speicherabbilds in „Vollständiges Speicherabbild“. Notieren Sie sich den aktuellen Typ, bevor Sie den Speicherabbildtyp ändern.
Verwenden Sie diese Schritte zum Konfigurieren von Abstürzen mithilfe der Tastatursteuerung.
Reproduzieren Sie das Hängen oder die Blockade.
Lassen Sie das System mithilfe der Tastensequenz aus (2) abstürzen.
Das System stürzt ab und erfasst das Speicherabbild.
Nachdem das System neu gestartet wurde, übermitteln Sie die Datei „memory.dmp“ an secure@microsoft.com. Der Standardspeicherort der Speicherabbilddatei ist „%SystemRoot%\memory.dmp“ oder „C:\Windows\memory.dmp“, wenn „C:“ das Systemlaufwerk ist. Geben Sie in der E-Mail an, dass das Speicherabbild für das WSL- oder Bash unter Windows-Team vorgesehen ist.
Stellen Sie die ursprünglichen Einstellung für den Speicherabbildtyp wieder her.
Um die Architektur des PCs und die Windows-Buildnummer zu ermitteln, öffnen Sie
Einstellungen>System>Info
Suchen Sie nach den Feldern Betriebssystembuild und Systemtyp.
Führen Sie Folgendes in PowerShell aus, um die Windows Server-Buildnummer zu ermitteln:
systeminfo | Select-String "^OS Name","^OS Version"
Sie können bestätigen, dass das Windows-Subsystem für Linux aktiviert ist, indem Sie Folgendes in einem PowerShell-Fenster mit erhöhten Rechten ausführen:
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
Beim Versuch, den SSH-Server zu verbinden, tritt ein Fehler auf: „Connection closed by 127.0.0.1 port 22“ (Verbindung wurde durch 127.0.0.1 Port 22 geschlossen).
Stellen Sie sicher, dass der OpenSSH-Server ausgeführt wird:
sudo service ssh status
und Sie dieses Tutorial befolgt haben: https://ubuntu.com/server/docs/service-openssh
Beenden Sie den sshd-Dienst, und starten Sie sshd im Debugmodus:
sudo service ssh stop
sudo /usr/sbin/sshd -d
Überprüfen Sie die Startprotokolle, und stellen Sie sicher, dass HostKeys verfügbar sind und keine Protokollmeldungen wie die folgenden angezeigt werden:
debug1: sshd version OpenSSH_7.2, OpenSSL 1.0.2g 1 Mar 2016
debug1: key_load_private: incorrect passphrase supplied to decrypt private key
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_rsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_dsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_ecdsa_key
debug1: key_load_private: No such file or directory
debug1: key_load_public: No such file or directory
Could not load host key: /etc/ssh/ssh_host_ed25519_key
Wenn solche Meldungen angezeigt werden und die Schlüssel unter /etc/ssh/
fehlen, müssen Sie die Schlüssel neu generieren oder openssh-server einfach bereinigen und installieren:
sudo apt-get purge openssh-server
sudo apt-get install openssh-server
Dieser Fehler bezieht sich auf einen fehlerhaften Installationsstatus. Führen Sie die folgenden Schritte aus, um eine Behebung dieses Problems zu versuchen:
Wenn Sie den Befehl zum Aktivieren des WSL-Features aus PowerShell ausführen, versuchen Sie stattdessen, die grafische Benutzeroberfläche zu verwenden, indem Sie das Startmenü öffnen, nach „Windows-Features aktivieren oder deaktivieren“ suchen und dann in der Liste „Windows Subsystem für Linux“ auswählen, wodurch die optionale Komponente installiert wird.
Aktualisieren Sie Ihre Windows-Version, indem Sie zu „Einstellungen“, „Updates“ wechseln und dann auf „Nach Updates suchen“ klicken
Wenn beide Versuche erfolglos bleiben und Sie auf WSL zugreifen müssen, erwägen Sie, ein lokales Upgrade auszuführen, indem Sie Windows mithilfe der Installationsmedien erneut installieren und „Alles beibehalten“ auswählen, um sicherzustellen, dass Ihre Apps und Dateien erhalten bleiben. Anweisungen dazu finden Sie auf der Seite Erneutes Installieren von Windows 10.
Wenn dieser Fehler angezeigt wird:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/user/.ssh/private-key.pem' are too open.
Um dieses Problem zu beheben, fügen Sie Folgendes an die Datei /etc/wsl.conf
an:
[automount]
enabled = true
options = metadata,uid=1000,gid=1000,umask=0022
Beachten Sie, dass durch Hinzufügen dieses Befehls Metadaten hinzugefügt und die in WSL angezeigten Dateiberechtigungen für die Windows-Dateien geändert werden. Weitere Informationen finden Sie in den Dateisystemberechtigungen.
Wenn Sie „openssh-server“ unter Windows verwenden und versuchen, remote auf WSL zuzugreifen, sehen Sie möglicherweise folgenden Fehler:
The file cannot be accessed by the system.
Es handelt sich um ein bekanntes Problem, wenn Sie die Store-Version von WSL verwenden. Sie können dies derzeit umgehen, indem Sie WSL 1 oder die in Windows enthaltene Version von WSL verwenden. Weitere Informationen finden Sie unter https://aka.ms/wslstoreinfo.
Einige im Microsoft Store verfügbare Verteilungen sind noch nicht vollständig kompatibel, um Windows-Befehle sofort auszuführen. Wenn Sie beim Ausführen von powershell.exe /c start .
oder eines anderen Windows-Befehls der Fehler -bash: powershell.exe: command not found
angezeigt wird, können Sie ihn mit den folgenden Schritten beheben:
echo $PATH
in Ihrer WSL-Verteilung aus./mnt/c/Windows/system32
nicht enthalten ist, wird die PATH-Standardvariable von irgendeiner Komponente neu definiert.cat /etc/profile
.cat /etc/wsl.conf
), und stellen Sie sicher, dass appendWindowsPath=false
nicht enthalten ist. Andernfalls kommentieren Sie es aus.wsl -t
eingeben, gefolgt vom Namen der Verteilung, oder indem Sie wsl --shutdown
entweder in cmd oder PowerShell ausführen.Es ist ein Problem bekannt, das Benutzer betrifft, wenn Sie nach der Installation von WSL 2 nicht starten können. Während unserer umfassenden Diagnose dieser Probleme haben Benutzer berichtet, dass das Ändern der Puffergröße oder das Installieren der richtigen Treiber helfen kann, dieses Problem zu beheben. Im folgenden GitHub-Artikel finden Sie die neuesten Updates zu diesem Problem.
Internet Connection Sharing (ICS) ist eine erforderliche Komponente von WSL 2. Der ICS-Dienst wird vom Hostnetzwerkdienst (HNS) verwendet, um das zugrunde liegende virtuelle Netzwerk zu erstellen, auf dem WSL 2 für NAT, DNS, DHCP und die Freigabe von Hostverbindungen basiert.
Das Deaktivieren des ICS-Dienstes (SharedAccess) oder das Deaktivieren von ICS über eine Gruppenrichtlinie verhindert, dass das WSL HNS-Netzwerk erstellt wird. Dies führt zu Fehlern beim Erstellen eines neuen WSL Version 2-Images und dem folgenden Fehler beim Versuch, ein Image der Version 1 in Version 2 zu konvertieren.
There are no more endpoints available from the endpoint mapper.
Systeme, für die WSL 2 erforderlich ist, sollten den ICS-Dienst (SharedAccess) im Standardstartstatus „Manuell“ (Start durch Auslöser) belassen, und alle Richtlinien, die ICS deaktivieren, sollten außer Kraft gesetzt oder entfernt werden. Beim Deaktivieren des ICS-Diensts wird die Ausführung von WSL 2 abgebrochen, daher wird von der Deaktivierung von ICS abgeraten. Eine teilweise Deaktivierung von ICS ist anhand dieser Anweisungen möglich.
Es gibt mehrere Unterschiede, die SIe beachten sollten, wenn Sie eine ältere Version von Windows und WSL ausführen, z. B. Windows 10 Creators Update (Oktober 2017, Build 16299) oder Anniversary Update (August 2016, Build 14393). Es wird empfohlen, auf die neueste Windows Version zu aktualisieren. Wenn dies jedoch nicht möglich ist, werden nachfolgend einige der Unterschiede beschrieben.
Unterschiede bei Interoperabilitätsbefehlen:
bash.exe
wurde durch wsl.exe
ersetzt. Linux-Befehle können an der Windows-Eingabeaufforderung oder in PowerShell ausgeführt werden. Für frühe Windows-Versionen müssen Sie jedoch möglicherweise den Befehl bash
verwenden. Beispiel: C:\temp> bash -c "ls -la"
. Die an bash -c
übergebenen WSL-Befehle werden ohne Änderung an den WSL-Prozess weitergeleitet. Dateipfade müssen im WSL-Format angegeben werden, und es muss darauf geachtet werden, dass relevante Zeichen mit Escapezeichen versehen werden. Beispiel: C:\temp> bash -c "ls -la /proc/cpuinfo"
oder C:\temp> bash -c "ls -la \"/mnt/c/Program Files\""
.[distro.exe] /?
aus. Beispielsweise mit Ubuntu: C:\> ubuntu.exe /?
.$PATH
von WSL enthalten./mnt/c/Windows/System32/notepad.exe
.root
zu ändern, verwenden Sie in PowerShell den Befehl C:\> lxrun /setdefaultuser root
, und führen Sie dann „Bash.exe“ aus, um sich anzumelden: C:\> bash.exe
. Setzen Sie Ihr Kennwort mit dem Kennwortbefehl der Verteilung $ passwd username
zurück, und schließen Sie die Linux-Befehlszeile: $ exit
. Setzen Sie ihren Standardbenutzer über die Windows-Eingabeaufforderung oder PowerShell wieder auf Ihr normales Linux-Benutzerkonto zurück: C:\> lxrun.exe /setdefaultuser username
.Wenn Sie WSL ursprünglich auf einer Version von Windows 10 vor dem Creators-Update installiert haben (Oktober 2017, Build 16299), empfehlen wir Ihnen, alle erforderlichen Dateien, Daten usw. von der älteren installierten Linux-Verteilung zu einer neueren, über den Microsoft Store installierten Verteilung zu migrieren. Um die alte Verteilung von Ihrem Computer zu entfernen, führen Sie Folgendes über eine Befehlszeilen oder PowerShell-Instanz aus: wsl --unregister Legacy
. Sie haben auch die Möglichkeit, die ältere Legacyverteilung manuell zu entfernen, indem Sie den Ordner %localappdata%\lxss\
(und alle untergeordneten Inhalte) mit dem Windows-Datei-Explorer oder mit PowerShell löschen: rm -Recurse $env:localappdata/lxss/
.
Feedback zu Windows Subsystem for Linux
Windows Subsystem for Linux ist ein Open Source-Projekt. Wählen Sie einen Link aus, um Feedback zu geben:
Training
Lernpfad
Konfigurieren von Netzwerken auf Windows Clients - Training
MD-100 Konfigurieren von Netzwerken auf Windows Clients