Formazione
Percorso di apprendimento
Configurare la rete nei client Windows - Training
MD-100 Configurare la rete nei client Windows
Questo browser non è più supportato.
Esegui l'aggiornamento a Microsoft Edge per sfruttare i vantaggi di funzionalità più recenti, aggiornamenti della sicurezza e supporto tecnico.
Sono stati illustrati alcuni scenari di risoluzione dei problemi comuni associati a WSL di seguito, ma è consigliabile cercare i problemi inseriti nel repository del prodotto WSL anche in GitHub.
I problemi del repository del prodotto WSL consentono di:
cmd.exe /c ver
per visualizzare la versione corrente #), indipendentemente dal fatto che si esegua WSL 1 o 2, la versione corrente del kernel Linux # (esecuzione wsl.exe --status
o cat /proc/version
), la versione # della distribuzione (esecuzione lsb_release -r
), le altre versioni software coinvolte, i passaggi di riproduzione, il comportamento previsto, il comportamento effettivo e i log di diagnostica, se disponibili e appropriati. Per altre info, vedere Contribuire a WSL.È anche possibile:
Installazione non riuscita. Codice di errore: 0x80070003
C:
). Assicurati che le distribuzioni siano archiviate nell'unità di sistema:Operazione di WslRegisterDistribution non riuscita con errore 0x8007019e
Installazione non riuscita con errore 0x80070003 o errore 0x80370102
Errore durante il tentativo di aggiornamento: Invalid command line option: wsl --set-version Ubuntu 2
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
.Non è possibile completare l'operazione richiesta a causa di una limitazione del sistema del disco virtuale. I file dei dischi rigidi virtuali devono essere non compressi e non crittografati. Inoltre, non devono essere sparse.
%USERPROFILE%\AppData\Local\Packages\CanonicalGroupLimited...
wsl --set-version
dovrebbe funzionare.Nota
In questo caso, la cartella LocalState per la distribuzione di Ubuntu 18.04 si trovava in C:\Users<my-user-name>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu18.04onWindows_79rhkp1fndgsc
Per informazioni aggiornate, vedere il thread 4103 sulla documentazione di WSL in GitHub, dove viene tenuta traccia di questo problema.
Termine 'wsl' non riconosciuto come nome di cmdlet, funzione, programma eseguibile o file script.
wsl.exe
da PowerShell Core o dal prompt dei comandi.Errore: Il sottosistema Windows per Linux non ha distribuzioni installate.
\Windows\sysnative
. Non sarà presente sul disco, ma il sistema di risoluzione del percorso del file system lo troverà.Errore: Questo aggiornamento si applica solo ai computer con il sottosistema Windows per Linux.
This update only applies to machines with the Windows Subsystem for Linux
.È in uso una versione precedente di Windows che non supporta WSL 2. Fai riferimento al Passaggio 2 per i requisiti di versione e i collegamenti ai file di aggiornamento.
WSL non è abilitato. Torna al Passaggio 1 e assicurati che nel computer in uso sia abilitata la funzionalità WSL facoltativa.
Dopo aver abilitato WSL, è necessario riavviare il computer affinché la modifica venga applicata. Riavvia il computer e riprova.
Errore: WSL 2 richiede un aggiornamento al relativo al componente kernel. Per ulteriori informazioni, visita https://aka.ms/wsl2kernel .
Probabilmente questo problema dipende dalla mancata esecuzione del backporting per WSL 2 sul computer. Il modo più semplice per risolverlo è passare a Impostazioni di Windows e fare clic su "Verifica disponibilità aggiornamenti" per installare gli aggiornamenti più recenti nel sistema. Vedere le istruzioni complete per l'esecuzione del backporting.
Se si fa clic su "Verifica disponibilità aggiornamenti" e l'aggiornamento KB KB4566116 non viene visualizzato, è possibile installarlo manualmente.
Questo problema può verificarsi quando l'opzione "Lingua di visualizzazione" o "Impostazioni locali del sistema" non è impostata sulla lingua inglese.
wsl --set-default-version 2
Error: 0x1bc
For information on key differences with WSL 2 please visit https://aka.ms/wsl2
L'errore effettivo per 0x1bc
è il seguente:
WSL 2 requires an update to its kernel component. For information please visit https://aka.ms/wsl2kernel
Per altre informazioni, vedere il problema 5749.
Un file server con protocollo 9p fornisce il servizio sul lato Linux per consentire a Windows di accedere al file system Linux. Se non è possibile accedere a WSL usando \\wsl$
in Windows, è possibile che il protocollo 9p non sia stato avviato correttamente.
Per verificarlo, è possibile controllare i log di avvio usando dmesg |grep 9p
, in modo da visualizzare eventuali errori. Un output corretto è simile al seguente:
[ 0.363323] 9p: Installing v9fs 9p2000 file system support
[ 0.363336] FS-Cache: Netfs '9p' registered for caching
[ 0.398989] 9pnet: Installing 9P2000 support
Per ulteriori informazioni su questo problema, vedere questo thread in GitHub.
Se la lingua di visualizzazione non è l'inglese, è possibile che venga visualizzata una versione troncata di un testo di errore.
C:\Users\me>wsl
WSL 2
Per risolvere il problema, visitare https://aka.ms/wsl2kernel
e installare manualmente il kernel seguendo le istruzioni visualizzate nella pagina della documentazione.
Gli utenti possono eseguire il file eseguibili Windows come notepad.exe direttamente da Linux. In alcuni casi, è possibile fare clic su "comando non trovato" come riportato di seguito:
$ notepad.exe
-bash: notepad.exe: command not found
Se non sono presenti percorsi Win32 in $PATH, l'interoperabilità non troverà il file .exe.
Per verificarlo, è possibile eseguire echo $PATH
in Linux. Verrà visualizzato un percorso Win32 (ad esempio, /mnt/c/Windows) nell'output.
Se non è possibile visualizzare i percorsi di Windows, è molto probabile che il percorso venga sovrascritto dalla shell Linux.
Di seguito è riportato un esempio che /etc/profile in Debian ha contribuito al problema:
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
Il modo corretto su Debian consiste nel rimuovere le righe riportate sopra. È anche possibile aggiungere $PATH durante l'assegnazione, come indicato di seguito, ma ciò comporta altri problemi con WSL e 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
Per altre informazioni, vedere i problemi 5296 e 5779.
Abilitare la funzionalità Virtual Machine Platform di Windows e verificare che la virtualizzazione sia abilitata nel BIOS.
Controllare i requisiti di sistema di Hyper-V.
Se il computer è una macchina virtuale, abilitare manualmente la virtualizzazione annidata. Avviare PowerShell con admin ed eseguire il comando seguente, sostituendo <VMName>
con il nome della macchina virtuale nel sistema host (è possibile trovare il nome nella console di gestione di Hyper-V):
Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
Per abilitare la virtualizzazione, seguire le linee guida del produttore del computer. In generale, ciò può comportare l'uso del BIOS di sistema per garantire che queste funzionalità siano abilitate nella CPU. Le istruzioni per questo processo possono variare da computer a computer. Per un esempio, vedere questo articolo di Bleeping Computer.
Riavviare il computer dopo aver abilitato il componente facoltativo Virtual Machine Platform
.
Accertarsi che l'avvio dell'hypervisor sia abilitato nella configurazione di avvio. È possibile convalidare questa operazione eseguendo (powershell con privilegi elevati):
bcdedit /enum | findstr -i hypervisorlaunchtype
Se viene visualizzato hypervisorlaunchtype Off
, l'hypervisor è disabilitato. Per abilitare l'esecuzione in powershell con privilegi elevati:
bcdedit /set hypervisorlaunchtype Auto
Inoltre, se sono installati hypervisor di terze parti (come ad esempio VMware o VirtualBox), accertarsi di avere questi elementi nelle versioni più recenti che possono supportare HyperV (VMware 15.5.5+ e VirtualBox 6+) o saranno disattivati.
Se si riceve questo errore in una macchina virtuale di Azure, verificare che Trusted Launch sia disabilitato. La virtualizzazione annidata non è supportata nelle macchine virtuali di Azure.
Ulteriori informazioni su come Configurare la virtualizzazione annidata quando si esegue Hyper-V in una macchina virtuale.
Gli ambienti Business o Enterprise possono avere impostazioni di Windows Defender Firewall configurate per bloccare il traffico di rete non autorizzato. Se l'unione delle regole locali è impostata su "No", la rete WSL non funzionerà per impostazione predefinita e l'amministratore dovrà aggiungere una regola di firewall per consentirla.
È possibile confermare l'impostazione dell'unione delle regole locali seguendo questa procedura:
Per istruzioni su come modificare questa impostazione del firewall, vedere Configurare il firewall Hyper-V.
Se dopo la connessione a una rete VPN in Windows, bash perde la connettività di rete, prova questa soluzione in bash. Questa soluzione ti consente di eseguire manualmente l'override della risoluzione DNS tramite /etc/resolv.conf
.
ipconfig.exe /all
sudo cp /etc/resolv.conf /etc/resolv.conf.new
di resolv.conf esistentesudo unlink /etc/resolv.conf
sudo mv /etc/resolv.conf.new /etc/resolv.conf
/etc/wsl.conf
e aggiungere il contenuto al file. (Ulteriori informazioni su questa configurazione sono disponibili in Configurazione delle impostazioni avanzate)[network]
generateResolvConf=false
/etc/resolv.conf
e Una volta disconnessa la rete VPN, dovrai annullare le modifiche apportate a /etc/resolv.conf
. A tale scopo, esegui queste operazioni:
cd /etc
sudo mv resolv.conf resolv.conf.new
sudo ln -s ../run/resolvconf/resolv.conf resolv.conf
La VPN Cisco AnyConnect modifica le route in modo da impedire il funzionamento di NAT. Esiste una soluzione alternativa specifica per WSL 2: vedere Guida amministratore a Cisco AnyConnect Secure Mobility Client, versione 4.10 - Risolvere i problemi relativi a AnyConnect.
La modalità di rete con mirroring è attualmente un'impostazione sperimentale nella configurazione WSL. L'architettura di rete NAT tradizionale di WSL può essere aggiornata a una modalità di rete completamente nuova denominata "modalità di rete con mirroring". Quando la versione sperimentale networkingMode
è impostata su mirrored
, viene eseguito il mirroring delle interfacce di rete disponibili in Windows in Linux per migliorare la compatibilità. Per altre informazioni, vedere il blog della riga di comando: aggiornamento di WSL di settembre 2023.
Alcune VPN sono state testate e confermate essere non compatibili con WSL, tra cui:
Il mirroring proxy HTTP/S può essere configurato usando l'impostazione autoProxy
nella sezione sperimentale del file di configurazione WSL. Quando si applica questa impostazione, tenere presenti queste considerazioni:
Quando è abilitata, quanto segue viene applicato alle impostazioni proxy nelle distribuzioni Linux:
HTTP_PROXY
, è impostata su uno o più proxy HTTP installati nella configurazione del proxy HTTP di Windows.HTTPS_PROXY
, è impostata su uno o più proxy HTTPS installati nella configurazione del proxy HTTP di Windows.NO_PROXY
, è impostata per bypassare tutti i proxy HTTP/S presenti nelle destinazioni di configurazione di Windows.WSL_PAC_URL
, è impostata su lettere minuscole e maiuscole. Ad esempio: HTTP_PROXY
e http_proxy
.Si è verificato un problema noto causato dalle configurazioni di ZScaler, in cui ZScaler abilita e disabilita ripetutamente le configurazioni proxy di Windows, con conseguente ripetizione di WSL che mostra la notifica "È stata rilevata una modifica del proxy HTTP nell'host".
Per altre informazioni, vedere il blog della riga di comando: aggiornamento di WSL di settembre 2023.
Quando WSL non riesce a connettersi a Internet, è possibile che la chiamata DNS all'host Windows sia bloccata. Questo avviene perché il pacchetto di rete per DNS inviato dalla macchina virtuale WSL all'host Windows è bloccato dalla configurazione di rete esistente. Il tunneling DNS risolve questo problema usando una funzionalità di virtualizzazione per comunicare direttamente con Windows, consentendo la risoluzione del nome DNS senza inviare un pacchetto di rete. Questa funzionalità dovrebbe migliorare la compatibilità di rete e consentire di ottenere una migliore connettività Internet anche se si dispone di una VPN, di una configurazione del firewall specifica o di altre configurazioni di rete.
Il tunneling DNS può essere configurato usando l'impostazione dnsTunneling
nella sezione sperimentale del file di configurazione WSL. Quando si applica questa impostazione, tenere presenti queste considerazioni:
/etc/resolv.conf
nella distribuzione Linux presenta un limite massimo di 3 server DNS, mentre Windows può usare più di 3 server DNS. L'uso del tunneling DNS rimuove questa limitazione: tutti i server DNS Windows possono ora essere usati da Linux.Per altre informazioni, vedere il blog della riga di comando: aggiornamento di WSL di settembre 2023.
Quando si usa la modalità di rete con mirroring (il networkingMode
sperimentale è impostato su mirrored
), il traffico in ingresso ricevuto dall'host Windows non verrà mai indirizzato verso la macchina virtuale Linux. Questo traffico è il seguente:
WSL configurerà automaticamente determinate impostazioni di rete Linux quando è in uso la modalità di rete con mirroring. Le configurazioni utente di queste impostazioni durante l'uso della modalità di rete con mirroring non sono supportate. Di seguito è riportato l'elenco delle impostazioni configurate da WSL:
Nome dell'impostazione | Valore |
---|---|
https://sysctl-explorer.net/net/ipv4/accept_local/ | Abilitata (1) |
https://sysctl-explorer.net/net/ipv4/route_localnet/ | Abilitata (1) |
https://sysctl-explorer.net/net/ipv4/rp_filter/ | Disabilitata (0) |
https://sysctl-explorer.net/net/ipv6/accept_ra/ | Disabilitata (0) |
https://sysctl-explorer.net/net/ipv6/autoconf/ | Disabilitata (0) |
https://sysctl-explorer.net/net/ipv6/use_tempaddr/ | Disabilitata (0) |
addr_gen_mode | Disabilitata (0) |
disable_ipv6 | Disabilitata (0) |
https://sysctl-explorer.net/net/ipv4/arp_filter/ | Abilitata (1) |
Si è verificato un problema noto in cui non sarà possibile creare contenitori Docker Desktop con porte pubblicate (docker run –publish/-p). Il team WSL collabora con il team di Docker Desktop per risolvere questo problema. Per risolvere il problema, usare lo spazio dei nomi di rete dell'host nel contenitore Docker. Impostare il tipo di rete tramite l'opzione "--network host" usata nel comando "docker run". Una soluzione alternativa consiste nell'elencare il numero di porta pubblicato nell'impostazione ignoredPorts
della sezione sperimentale nel file di configurazione WSL.
Si è verificato un problema noto con i contenitori Docker che hanno il servizio Gestione rete in esecuzione. I sintomi includono errori durante il tentativo di effettuare connessioni di loopback all'host. È consigliabile arrestare il servizio Gestione rete per configurare correttamente la rete WSL.
sudo systemctl disable network-manager.service
Per risolvere i nomi host in indirizzi IP all'interno di una rete locale senza la necessità di un server DNS convenzionale, vengono spesso usati nomi locali. Questo risultato viene ottenuto tramite il protocollo DNS mDNS (Multicast), che si basa sul traffico multicast per funzionare.
networkingMode impostato su NAT:
Attualmente, questa funzionalità non è supportata quando è abilitato il tunneling DNS. Per abilitare la risoluzione dei nomi locali, è consigliabile usare le soluzioni seguenti:
networkingMode impostato su Mirrored:
Nota: per avere la funzionalità riportata di seguito, è necessario trovarsi nella build WSL 2.3.17 o successiva.
Poiché la modalità mirroring supporta il traffico multicast, è possibile usare il protocollo mDNS (Multicast DNS) per risolvere i nomi locali. Linux deve essere configurato per supportare mDNS, perché non lo fa per impostazione predefinita. Un modo per configurarlo consiste nell'usare i due passaggi seguenti:
sudo apt-get install libnss-mdns
*Il pacchetto "libnss-mdns" è un plug-in per la funzionalità GNU Name Service Switch (NSS) della libreria GNU C (glibc) che fornisce la risoluzione del nome host tramite DNS multicast (mDNS). Questo pacchetto consente in modo efficace ai programmi Unix/Linux comuni di risolvere i nomi nel dominio mDNS ad hoc .local.
/etc/nsswitch.conf
file per abilitare l'impostazione "mdns_minimal" nella sezione "hosts". Contenuto di esempio del file: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
A seconda delle configurazioni nel file con estensione wslconfig, WSL avrà i suffissi DNS wrt seguenti:
Quando networkingMode è impostato su NAT:
Caso 1) Per impostazione predefinita, nessun suffisso DNS è configurato in Linux
Caso 2) Se il tunneling DNS è abilitato (dnsTunneling è impostato su true in .wslconfig) Tutti i suffissi DNS windows sono configurati in Linux, nell'impostazione "search" di /etc/resolv.conf
I suffissi vengono configurati in /etc/resolv.conf nell'ordine seguente, in modo simile all'ordine in cui il client DNS Windows prova i suffissi durante la risoluzione di un nome: suffissi DNS globali, quindi suffissi DNS supplementari, quindi suffissi DNS per interfaccia.
Quando si verifica una modifica nei suffissi DNS di Windows, tale modifica verrà riflessa automaticamente in Linux
Caso 3) Se il tunneling DNS è disabilitato e il proxy DNS SharedAccess è disabilitato (dnsTunneling è impostato su false e dnsProxy è impostato su false in .wslconfig) Un singolo suffisso DNS è configurato in Linux, nell'impostazione "dominio" di /etc/resolv.conf
Quando si verifica una modifica nei suffissi DNS di Windows, tale modifica non viene riflessa in Linux
Il suffisso DNS singolo configurato in Linux viene scelto dai suffissi DNS per interfaccia (i suffissi globali e supplementari vengono ignorati)
se Windows dispone di più interfacce, viene usata un'euristica per scegliere il singolo suffisso DNS che verrà configurato in Linux. Ad esempio, se è presente un'interfaccia VPN in Windows, il suffisso viene scelto da tale interfaccia. Se non è presente alcuna interfaccia VPN, il suffisso viene scelto dall'interfaccia più probabile per fornire la connettività Internet.
Quando networkingMode è impostato su Mirrored:
Tutti i suffissi DNS di Windows sono configurati in Linux, nell'impostazione "search" di /etc/resolv.conf
I suffissi vengono configurati in /etc/resolv.conf nello stesso ordine del caso 2) dalla modalità NAT
Quando si verifica una modifica nei suffissi DNS di Windows, tale modifica verrà riflessa automaticamente in Linux
Nota: i suffissi DNS supplementari possono essere configurati in Windows usando SetInterfaceDnsSettings - App Win32 | Microsoft Learn, con il flag DNS_SETTING_SUPPLEMENTAL_SEARCH_LIST impostato nel parametro Settings
La configurazione DNS predefinita quando WSL avvia un contenitore in modalità NAT consiste nel fare in modo che il dispositivo NAT nell'host Windows funzioni come "server" DNS per il contenitore WSL. Quando le query DNS vengono inviate dal contenitore WSL al dispositivo NAT nell'host Windows, il pacchetto DNS viene inoltrato dal dispositivo NAT al servizio di accesso condiviso nell'host; la risposta viene inviata nella direzione inversa al contenitore WSL. Questo processo di inoltro di pacchetti per l'accesso condiviso richiede una regola del firewall per consentire tale pacchetto DNS in ingresso, creato dal servizio HNS quando WSL chiede inizialmente a HNS di creare la rete virtuale NAT per il contenitore WSL.
A causa di questa progettazione NAT - Accesso condiviso, esistono alcune configurazioni note che possono interrompere la risoluzione dei nomi da WSL.
1. Un'organizzazione può eseguire il push di criteri che non consentono regole del firewall definite in locale, consentendo solo regole definite dai criteri aziendali.
Quando questa impostazione viene impostata da un'organizzazione, la regola del firewall creata da HNS viene ignorata, perché si tratta di una regola definita localmente. Affinché questa configurazione funzioni, l'organizzazione deve creare una regola del firewall per consentire la porta UDP 53 al servizio di accesso condiviso oppure WSL può essere impostato per l'uso del tunneling DNS. È possibile verificare se questa opzione è configurata per non consentire regole del firewall definite in locale eseguendo le operazioni seguenti. Si noti che verranno visualizzate le impostazioni per tutti e 3 i profili: Dominio, Privato e Pubblico. Se è impostato su un profilo, i pacchetti verranno bloccati se a tale profilo è assegnata la scheda di interfaccia di rete virtuale WSL (il valore predefinito è Pubblico). Si tratta solo di un frammento del primo profilo firewall restituito in PowerShell:
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. E Enterprise può eseguire il push delle impostazioni di Criteri di gruppo e dei criteri MDM che bloccano tutte le regole in ingresso.
Queste impostazioni sostituiscono qualsiasi regola del firewall in ingresso consentita. Questa impostazione bloccherà quindi la regola del firewall UDP creata da HNS e impedirà a WSL di risolvere i nomi. Per il funzionamento di questa configurazione, WSL deve essere impostato per l'uso del tunneling DNS. Questa impostazione bloccherà sempre il proxy DNS NAT.
Da Criteri di gruppo:
Configurazione computer \ Modelli amministrativi \ Rete \ Connessioni di rete \ Windows Defender Firewall \ Profilo di dominio | Profilo standard
"Windows Defender Firewall: Non consentire eccezioni" - Abilitato
Dai criteri MDM:
./Vendor/MSFT/Firewall/MdmStore/PrivateProfile/Shielded
./Vendor/MSFT/Firewall/MdmStore/DomainProfile/Shielded
./Vendor/MSFT/Firewall/MdmStore/PublicProfile/Shielded
È possibile verificare se questa impostazione è configurata per non consentire alcuna regola del firewall in ingresso eseguendo quanto segue (vedere le avvertenze precedenti nei profili firewall). Si tratta solo di un frammento del primo profilo firewall restituito in PowerShell:
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. Un utente passa attraverso l'impostazione Sicurezza di Windows app e controlla il controllo per "Blocca tutte le connessioni in ingresso, incluse quelle nell'elenco delle app consentite".
Windows supporta un consenso esplicito dell'utente per la stessa impostazione che può essere applicata da un'organizzazione a cui si fa riferimento nel numero 2 precedente. Gli utenti possono aprire la pagina delle impostazioni "Sicurezza di Windows", seleziona l'opzione "Firewall e protezione di rete", seleziona il profilo firewall che desidera configurare (Dominio, Privato o Pubblico) e in "Connessioni in ingresso" controlla il controllo "Blocca tutte le connessioni in ingresso, incluse quelle nell'elenco delle app consentite".
Se questa opzione è impostata per il profilo pubblico (si tratta del profilo predefinito per la scheda di interfaccia di rete virtuale WSL), la regola del firewall creata da HNS per consentire ai pacchetti UDP di accedere condiviso verrà bloccata.
Questa opzione deve essere deselezionata per il funzionamento della configurazione del proxy DNS NAT da WSL oppure WSL può essere impostata per l'uso del tunneling DNS.
4. La regola del firewall HNS per consentire ai pacchetti DNS di accedere condiviso può diventare non valida, facendo riferimento a un identificatore di interfaccia WSL precedente. Si tratta di un difetto all'interno di HNS che è stato risolto con la versione più recente di Windows 11. Nelle versioni precedenti, se ciò si verifica, non è facilmente individuabile, ma offre una semplice soluzione alternativa:
Arrestare WSL
wsl.exe –shutdown
Eliminare la regola precedente del firewall HNS. Questo comando di PowerShell dovrebbe funzionare nella maggior parte dei casi:
Get-NetFirewallRule -Name "HNS*" | Get-NetFirewallPortFilter | where Protocol -eq UDP | where LocalPort -eq 53 | Remove-NetFirewallRule
Rimuovere tutti gli endpoint HNS. Nota: se HNS viene usato per gestire altri contenitori, ad esempio MDAG o Sandbox di Windows, è necessario arrestare anche tali contenitori.
hnsdiag.exe delete all
Riavviare o riavviare il servizio HNS
Restart-Service hns
Quando WSL viene riavviato, HNS creerà nuove regole del firewall, destinate correttamente all'interfaccia WSL.
Se non si ha accesso alla rete, potrebbe essere dovuto a una configurazione errata. Verificare se il driver FSE è in esecuzione: 'sc queryex FSE'. Se non viene visualizzato FSE in esecuzione, controllare se il valore del Registro di sistema PortTrackerEnabledMode viene chiuso in questa chiave del Registro di sistema: reg query HKLM\System\CurrentControlSet\Services\Tcpip\Parameters. Se FSE non è in esecuzione o installato e PortTrackerEnabledMode esiste, eliminare il valore e il riavvio del Registro di sistema
Gli adattatori fantasma o i dispositivi Plug and Play fantasma (PnP), fanno riferimento a componenti hardware visualizzati nel sistema, ma non connessi fisicamente. Questi dispositivi "fantasma" possono causare confusione e confusione nelle impostazioni del sistema. Se vengono visualizzati adattatori fantasma durante l'esecuzione di WSL in una macchina virtuale, seguire questa procedura manuale per trovare ed eliminare questi dispositivi Phantom PnP. Microsoft sta lavorando a una soluzione automatizzata che non richiederà l'intervento manuale. Altre informazioni saranno presto disponibili.
Segui queste istruzioni per raccogliere i log WSL nel repository WSL in GitHub per raccogliere log dettagliati e segnalare un problema in GitHub.
Esistono due componenti del sottosistema Windows per Linux che possono richiedere l'aggiornamento.
Per aggiornare il sottosistema Windows per Linux stesso, usare il comando wsl --update
in PowerShell o CMD.
Per aggiornare i file binari utente di distribuzione Linux specifici, usare il comando: apt-get update | apt-get upgrade
nella distribuzione Linux che si sta cercando di aggiornare.
Alcuni pacchetti usano funzionalità che non sono ancora state implementate. Non è ancora previsto ad esempio il supporto per udev
, che causa diversi errori apt-get upgrade
.
Per risolvere i problemi correlati a udev
, segui questa procedura:
Scrivi quanto segue in /usr/sbin/policy-rc.d
e salva le modifiche.
#!/bin/sh
exit 101
Aggiungi autorizzazioni di esecuzione a /usr/sbin/policy-rc.d
:
chmod +x /usr/sbin/policy-rc.d
Eseguire i comandi seguenti:
dpkg-divert --local --rename --add /sbin/initctl
ln -s /bin/true /sbin/initctl
Questo errore dipende dal fatto che non è supportata la console legacy. Per disattivare la console legacy:
È possibile che la funzionalità Sottosistema Windows per Linux sia stata disabilitata durante un aggiornamento di Windows. In tal caso, è necessario riabilitarla. Le istruzioni per abilitare la funzionalità sottosistema Windows per Linux sono disponibili nella Guida all'installazione.
Il programma di installazione di Sottosistema Windows per Linux tenterà di modificare automaticamente le impostazioni locali di Ubuntu in modo che corrispondano alle impostazioni locali dell'installazione di Windows. Se non vuoi ottenere questo risultato, puoi eseguire questo comando per modificare le impostazioni locali di Ubuntu al completamento dell'installazione. Per rendere effettiva questa modifica, dovrai riavviare bash.exe.
L'esempio seguente passa alle impostazioni locali in en-US
:
sudo update-locale LANG=en_US.UTF8
%windir%\System32\Tasks\Microsoft\Windows\Windows Subsystem for Linux
Alcuni utenti hanno segnalato problemi con applicazioni firewall specifiche che bloccano l'accesso a Internet in Sottosistema Windows per Linux. I firewall segnalati sono:
In alcuni casi, la disabilitazione del firewall consente l'accesso. In altri casi sembra che il semplice fatto che il firewall sia installato blocchi l'accesso.
Se si usa Microsoft Defender Firewall, deselezionare "Blocca tutte le connessioni in ingresso, incluse quelle nell'elenco delle app consentite".
Per Windows Anniversary Update, versione 1607 sono necessari privilegi di amministratore in Windows per eseguire il ping in WSL. Per eseguire il comando ping, esegui Bash in Ubuntu su Windows come amministratore oppure esegui bash.exe da un prompt dei comandi o di PowerShell con privilegi di amministratore.
Per le versioni successive di Windows, build 14926 e successive, i privilegi di amministratore non sono più necessari.
Se durante l'uso noti che bash è bloccato o in deadlock e non risponde agli input, puoi aiutare a diagnosticare il problema raccogliendo e segnalando un dump della memoria. Tieni presente che questi passaggi comporteranno un arresto anomalo del sistema. Non eseguire questa operazione se non hai familiarità con questa procedura oppure salva il lavoro prima di procedere.
Per raccogliere un dump della memoria
Modifica il tipo di dump della memoria impostandolo su "Dump della memoria completo". Quando modifichi il tipo di dump, prendi nota del tipo corrente.
Segui i passaggi per configurare l'arresto anomalo usando il controllo tastiera.
Riproduci il blocco o il deadlock.
Riproduci l'arresto anomalo del sistema usando la sequenza di tasti del passaggio (2).
Il sistema si arresterà in modo anomalo e raccoglierà il dump della memoria.
Una volta riavviato il sistema, invia memory.dmp a secure@microsoft.com. Il percorso predefinito del file di dump è %SystemRoot%\memory.dmp o C:\Windows\memory.dmp se C: è l'unità di sistema. Nel messaggio di posta elettronica indica se il dump è per il team di Sottosistema Windows per Linux o di Bash in Windows.
Ripristina l'impostazione originale del tipo di dump della memoria.
Per trovare l'architettura del PC e il numero di build di Windows, apri
Impostazioni>Sistema>Informazioni sul sistema.
Cerca i campi Build sistema operativo e Tipo sistema.
Per trovare il numero di build di Windows Server, esegui questo comando in PowerShell:
systeminfo | Select-String "^OS Name","^OS Version"
Puoi verificare che il sottosistema Windows per Linux sia abilitato eseguendo questo comando in una finestra di PowerShell con privilegi elevati:
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux
Il tentativo di connessione del server SSH non è riuscito e ha generato l'errore seguente: "Connessione chiusa dalla porta 127.0.0.1 22".
Verifica che il server OpenSSH sia in esecuzione:
sudo service ssh status
e di aver seguito questa esercitazione: https://ubuntu.com/server/docs/service-openssh
Arresta il servizio sshd e avvia sshd in modalità di debug:
sudo service ssh stop
sudo /usr/sbin/sshd -d
Controlla i log di avvio e verifica che siano disponibili chiavi host e che non vengano visualizzati messaggi di log come ad esempio:
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
Se visualizzi messaggi di questo tipo e le chiavi non sono presenti in /etc/ssh/
, dovrai rigenerare le chiavi o semplicemente eseguire i comandi purge e install per openssh-server:
sudo apt-get purge openssh-server
sudo apt-get install openssh-server
Questo errore è correlato a uno stato di installazione non valido. Completa i passaggi seguenti per provare a risolvere il problema:
Se esegui il comando di abilitazione della funzionalità Sottosistema Windows per Linux da PowerShell, prova a usare piuttosto l'interfaccia utente grafica. Apri il menu Start, cerca 'Attivazione o disattivazione delle funzionalità Windows' e quindi seleziona dall'elenco 'Sottosistema Windows per Linux' per installare il componente facoltativo.
Aggiorna la versione di Windows. A tale scopo, passa a Impostazioni, Aggiornamenti e quindi fai clic su 'Verifica disponibilità aggiornamenti'.
Se entrambe le operazioni hanno esito negativo ed è necessario accedere a WSL, prova a eseguire l'aggiornamento in loco reinstallando Windows 10 con i supporti di installazione e selezionando 'Mantieni tutto' in modo da mantenere le app e i file. Per istruzioni su come eseguire questa operazione, vedi la pagina Reinstallare Windows 10.
Se vedi questo errore:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0777 for '/home/user/.ssh/private-key.pem' are too open.
Per risolvere questo problema, aggiungere quanto segue al /etc/wsl.conf
file :
[automount]
enabled = true
options = metadata,uid=1000,gid=1000,umask=0022
Si noti che l'aggiunta di questo comando determinerà l'inclusione di metadati e la modifica delle autorizzazioni per i file di Windows visualizzati da WSL. Per altre informazioni, vedi Autorizzazioni per il file system.
Se si usa openssh-server in Windows e si tenta di accedere a WSL in modalità remota, viene visualizzato questo errore:
The file cannot be accessed by the system.
Si tratta di un problema comune quando si usa la versione dello Store di WSL. È possibile risolvere questo problema usando WSL 1 o la versione in Windows di WSL. Per ulteriori informazioni, https://aka.ms/wslstoreinfo vedere:
Alcune distribuzioni disponibili in Microsoft Store non sono ancora completamente compatibili per l'esecuzione dei comandi di Windows nel terminale predefinito. Se si verifica un errore -bash: powershell.exe: command not found
durante l'esecuzione di powershell.exe /c start .
o di qualsiasi altro comando di Windows, è possibile risolvere il problema attenendosi alla procedura seguente:
echo $PATH
./mnt/c/Windows/system32
, è presente un elemento che sta ridefinendo la variabile PATH standard.cat /etc/profile
.cat /etc/wsl.conf
e assicurarsi che non includa appendWindowsPath=false
, altrimenti impostarlo come commento.wsl -t
seguito dal nome della distribuzione oppure eseguire wsl --shutdown
in cmd o PowerShell.È un problema noto quello che riguarda gli utenti che non sono in grado di eseguire l'avvio dopo l'installazione di WSL 2. Durante le attività intraprese per una diagnosi completa del problema, gli utenti hanno segnalato che la modifica delle dimensioni del buffer o l'installazione dei driver corretti può essere utile a risolvere il problema. Per gli aggiornamenti più recenti su questo argomento, visualizzare il problema in GitHub.
Internet Connection Sharing (ICS) è un componente obbligatorio di WSL 2. Il servizio ICS viene usato dal servizio di rete host (HNS) per creare la rete virtuale su cui si basa WSL 2 per la condivisione di connessioni NAT, DNS, DHCP e host.
La disabilitazione del servizio ICS (SharedAccess) o la disabilitazione di ICS tramite criteri di gruppo impedirà la creazione della rete HNS WSL. Ciò genererà errori durante la creazione di una nuova immagine WSL versione 2 e l'errore seguente quando si tenta di convertire un'immagine versione 1 in un'immagine versione 2.
There are no more endpoints available from the endpoint mapper.
I sistemi che richiedono WSL 2 devono lasciare il servizio ICS (SharedAccess) nello stato di avvio predefinito, Manuale (Avvio trigger) e tutti i criteri che disabilitano ICS devono essere sovrascritti o rimossi. Durante la disabilitazione del servizio ICS si interrompe WSL 2 e non è consigliabile disabilitare ICS, le parti di ICS possono essere disabilitate seguendo queste istruzioni
Esistono diverse differenze da notare se si esegue una versione precedente di Windows e WSL, come ad esempio Windows 10 Creators Update (ottobre 2017, Versione 16299) o Aggiornamento dell'anniversario (agosto 2016, Versione 14393). Ti consigliamo di eseguire l'aggiornamento alla versione più recente di Windows, ma se non è possibile, di seguito abbiamo descritto alcune delle differenze.
Differenze dei comandi di interoperabilità:
bash.exe
è stato sostituito con wsl.exe
. I comandi di Linux possono essere eseguiti dal prompt dei comandi di Windows o da PowerShell, ma per le versioni precedenti di Windows può essere necessario usare il comando bash
. Ad esempio: C:\temp> bash -c "ls -la"
. I comandi di Sottosistema Windows per Linux passati in bash -c
vengono inoltrati al processo di Sottosistema Windows per Linux senza alcuna modifica. I percorsi di file devono essere specificati nel formato di Sottosistema Windows per Linux ed è necessario prestare attenzione per l'escape dei caratteri pertinenti. Ad esempio, C:\temp> bash -c "ls -la /proc/cpuinfo"
o C:\temp> bash -c "ls -la \"/mnt/c/Program Files\""
.[distro.exe] /?
. Ad esempio, con Ubuntu: C:\> ubuntu.exe /?
.$PATH
di WSL./mnt/c/Windows/System32/notepad.exe
root
usare questo comando in PowerShell: C:\> lxrun /setdefaultuser root
e poi eseguire Bash.exe per accedere a: C:\> bash.exe
. Reimpostare la password usando il comando password delle distribuzioni: $ passwd username
e poi chiudere la riga di comando di Linux: $ exit
. Dal prompt dei comandi di Windows o Da PowerShell, reimpostare l'utente predefinito sul normale account utente di Linux: C:\> lxrun.exe /setdefaultuser username
.Se WSL è stato originariamente installato in una versione di Windows 10 prima di Creators Update (ottobre 2017, Versione 16299), è consigliabile eseguire la migrazione di eventuali file, dati e così via necessari dalla distribuzione Linux precedente installata a una distribuzione più recente installata tramite Microsoft Store. Per rimuovere la distribuzione legacy dal computer, eseguire quanto segue da una riga di comando o da un'istanza di PowerShell: wsl --unregister Legacy
. È anche possibile rimuovere manualmente la distribuzione legacy precedente eliminando la %localappdata%\lxss\
cartella (e tutto il contenuto secondario) usando Esplora file di Windows o tramite PowerShell: rm -Recurse $env:localappdata/lxss/
.
Feedback su Windows Subsystem for Linux
Windows Subsystem for Linux è un progetto di open source. Selezionare un collegamento per fornire feedback:
Formazione
Percorso di apprendimento
Configurare la rete nei client Windows - Training
MD-100 Configurare la rete nei client Windows