WSL2: Guida avanzata alla configurazione di rete e alle modalità NAT e mirroring

Informatec Digital » Risorse » WSL2: Guida avanzata alla configurazione di rete e alle modalità NAT e mirroring

WSL2 ha completamente cambiato il modo in cui Linux si integra con Windows , soprattutto per quanto riguarda la rete: ora abbiamo una macchina virtuale leggera con un proprio stack di rete, indirizzo IP e regole di accesso separate. Questo apre molte possibilità per lo sviluppo, il testing, i container e gli ambienti self-hosting, ma solleva anche preoccupazioni quando i servizi diventano inaccessibili, come accadeva con WSL1.

Comprendere la configurazione di rete di WSL2, le sue modalità NAT e mirroring, l'utilizzo di .wslconfig e wsl.conf e la loro interazione con firewall, VPN, Docker e strumenti come Tailscale è fondamentale per evitare problemi. Vedremo passo dopo passo come funziona l'intera configurazione, come esporre i servizi a Windows e alla LAN, quali comandi utilizzare per ottenere gli indirizzi IP corretti e quali opzioni di configurazione avanzate sono disponibili per ottimizzare l'ambiente, rendendolo stabile e, soprattutto, sicuro.

Come funziona realmente la rete in WSL2

WSL2 non condivide più lo stack di rete host come WSL1Invece, esegue ogni distribuzione Linux all'interno di una piccola macchina virtuale gestita da Hyper-V. Quella VM ha il suo adattatore virtuale (di solito eth0) e un indirizzo IP privato assegnato da uno switch virtuale interno.

Nella sua modalità predefinita, WSL2 utilizza un'architettura basata su NAT (Network Address Translation). Windows funge da router/host e la distribuzione Linux risiede su una subnet privata, in genere all'interno dell'intervallo. 172.16.0.0/12Questa subnet può cambiare dopo i riavvii o i riavvii di WSL, un fenomeno che ha fatto impazzire più di una persona durante la configurazione delle regole del firewall statico.

Da un punto di vista pratico, ciò significa che l'indirizzo IP della distribuzione WSL2 non è stabile né direttamente accessibile dalla LAN come accadeva con WSL1: per impostazione predefinita, la connettività tra Windows e WSL2 avviene solo tramite regole di reindirizzamento e NAT, e l'accesso alla rete locale richiede passaggi aggiuntivi o l'utilizzo della modalità mirror.

Oltre a questa architettura di base, Windows 11 22H2 e le versioni successive aggiungono nuove funzionalità di rete (modalità mirroring, dnsTunneling, autoProxy, firewall Hyper-V, ecc.) che sono controllati dal file globale .wslconfigmentre alcune opzioni all'interno di Linux sono gestite con /etc/wsl.conf.

Identificare gli indirizzi IP in WSL2

Lavorare con WSL2 implica distinguere chiaramente tra due scenari IP : quando è necessario l'indirizzo IP della distribuzione Linux e quando è necessario l'indirizzo IP dell'host Windows visto da Linux. Ciascuno viene gestito con un comando diverso.

Scenario 1: Da Windows, si desidera conoscere l'indirizzo IP della distribuzione WSL2 in modo che un'applicazione sull'host (ad esempio, un client, un browser o uno strumento di test) possa connettersi a un servizio in esecuzione su Linux. Per fare ciò, è possibile eseguire i seguenti comandi in Windows (CMD o PowerShell):

wsl.exe --distribution <DistroName> hostname -i

Se si desidera utilizzare la distribuzione predefinita, è possibile omettere il parametro distribution. e chiama semplicemente wsl.exe hostname -iIn background, questo comando viene avviato in Linux hostname --ip-addresses e restituisce l'indirizzo IP dell'istanza. Un risultato tipico potrebbe essere simile a questo:

172.30.98.229

Scenario 2: Dalla distribuzione Linux, è necessario conoscere l'indirizzo IP dell'host Windows , ad esempio, affinché un'applicazione WSL2 possa connettersi a un server in esecuzione nativamente su Windows (Node.js, SQL Server, Caddy, ecc.). All'interno della shell Linux, è possibile utilizzare:

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

L'output sarà il gateway predefinito della VM WSL2 , che corrisponde all'indirizzo IP dell'host Windows visto da Linux, qualcosa del tipo:

172.30.96.1

Quel valore (ad esempio, 172.30.96.1) è l'indirizzo a cui dovrebbero puntare i tuoi client Linux quando si desidera accedere ai servizi in esecuzione sull'host Windows mentre si è in modalità NAT classica.

Modalità NAT: comportamento predefinito della rete WSL2

Di default, WSL2 funziona in modalità NAT e, per molti ambienti di sviluppo semplici, questo è più che sufficiente . L'importante è capire cosa funziona "di default" e cosa no, per non perdere tempo a cercare soluzioni inesistenti.

Accesso ai servizi Linux da Windows tramite localhostSe esegui un'applicazione di rete (ad esempio, un server Node.js, un server Flask, un SQL Server su Linux) sulla tua distribuzione WSL2, puoi accedervi da Windows utilizzando localhost:puertoWindows inoltra automaticamente le connessioni in entrata all'indirizzo IP interno della VM WSL2.

Accesso ai servizi in esecuzione su Windows da Linux : qui le cose cambiano. Per raggiungere un'applicazione di rete sull'host (come un server Node.js, SQL Server o Caddy su Windows) da WSL2, è necessario utilizzare l'indirizzo IP dell'host visto da Linux, ottenuto con il comando default path:

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

Con quell'indirizzo IP puoi connetterti da Linux a qualsiasi servizio sull'host, per esempio http://172.30.96.1:3000 se il server Windows è in ascolto sulla porta 3000 su tutte le interfacce.

Quando ci si connette tramite IP remoti (non localhost), le applicazioni li vedono come connessioni LAN.Ciò significa che molti server devono essere configurati per l'ascolto su 0.0.0.0 al posto di 127.0.0.1Ad esempio, con Flask potresti lanciare:

app.run(host='0.0.0.0')

Questa modifica migliora l'accessibilità ma richiede un'attenta considerazione della sicurezza , poiché consente connessioni dalla rete locale, e non solo dal dispositivo stesso.

Accesso a WSL2 dalla rete locale (LAN) tramite NAT

Uno dei cambiamenti più fastidiosi nel passaggio da WSL1 a WSL2 è che le distribuzioni non sono più direttamente accessibili dalla LAN . In WSL1, se il sistema Windows era visibile sulla rete, i servizi della distribuzione ereditavano tale visibilità quasi senza problemi.

In WSL2, la macchina virtuale ha un proprio indirizzo IP privato e non viene automaticamente pubblicizzata sulla LAN . Per ottenere un comportamento simile a quello precedente, in modalità NAT è necessario creare un proxy di porta in Windows, proprio come si farebbe con qualsiasi macchina virtuale Hyper-V.

Windows include uno strumento classico per questo: netsh interface portproxyUn comando tipico per reindirizzare una porta host all'IP/porta WSL2 sarebbe:

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

In pratica, si sostituirebbero i marcatori con valori specifici , ad esempio:

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

qui listenaddress=0.0.0.0 Ciò indica che Windows ascolterà tutti gli indirizzi IPv4 dell'host.e inoltrerà ciò che arriva attraverso la porta 4000 a 192.168.101.100:4000che sarebbe l'indirizzo IP WSL2 ottenuto con:

• wsl hostname -I Fornisce l'indirizzo IP della distribuzione Linux all'interno della VM WSL2
• cat /etc/resolv.conf Rivela l'indirizzo IP dell'host Windows Vista da WSL2.

Con questa tecnica è possibile rendere un servizio in esecuzione su WSL2 accessibile da qualsiasi computer della LAN , a condizione che il firewall di Windows lo consenta e che sia chiaro che si sta esponendo un servizio di una macchina virtuale e non direttamente dell'host.

IPv6 e funzionalità di rete moderne

WSL2 è compatibile anche con IPv6, una caratteristica particolarmente rilevante negli ambienti moderni, nelle VPN e nelle reti aziendali . Per gestire gli indirizzi, i comandi di base in Linux sono equivalenti a quelli per IPv4:

• wsl hostname -i Da Windows per visualizzare l'indirizzo IP della distribuzione WSL2
• ip route show | grep -i default | awk '{ print $3 }' da Linux per ottenere l'indirizzo IP dell'host Windows

Il vero salto di qualità nel supporto per IPv6 e VPN si riscontra nella modalità di rete mirror , disponibile in Windows 11 22H2 e versioni successive, che analizzeremo in dettaglio più avanti.

Modalità di rete speculare: mirroring delle interfacce Windows in Linux

Sui computer con Windows 11 22H2 o versioni successive, è possibile attivare la modalità di rete "mirrorata" in WSL2, che cambia completamente il modello: invece del NAT classico, Linux "vede" le interfacce di rete di Windows riflesse.

Per abilitarlo, è necessario modificare il file .wslconfig del tuo utente, trovato in %UserProfile%\.wslconfigDa PowerShell con privilegi di amministratore, puoi aprirlo con:

notepad $env:USERPROFILE\.wslconfig

All'interno, aggiungi (o modifica) la sezione [wsl2] per attivare la modalità speculare :

[wsl2]
networkingMode=mirrored

Una volta salvato il file, è necessario riavviare WSL2 affinché la modifica abbia effetto , ad esempio con:

wsl --shutdown

Al riavvio, WSL utilizzerà la nuova architettura di rete con mirroring , che offre diversi vantaggi significativi:

• Supporto IPv6 nativo e integrazione migliorata con reti aziendali e VPN
• Possibilità di connettersi ai servizi Windows da Linux utilizzando 127.0.0.1 directamente (anche se non è consentito) ::1 (ad esempio, loopback IPv6 per questo)
• Supporto multicast migliorato nell'integrazione Windows-Linux
• Accesso diretto a WSL dalla LAN senza bisogno di netsh portproxyutilizzando l'indirizzo IP della macchina Windows stessa

L'attivazione di questa modalità risolve molti dei classici problemi NAT di WSL2 ed è l'opzione consigliata nella maggior parte degli ambienti di sviluppo e di self-hosting moderni in cui è possibile utilizzare una versione aggiornata di Windows 11.

Tunneling DNS e utilizzo di proxy in WSL2

In Windows 11 22H2 e versioni successive, anche la risoluzione dei nomi da WSL2 ha subito una revisione significativa.La chiave risiede in due funzionalità definite in .wslconfig: dnsTunneling y autoProxy.

l'opzione dnsTunneling È abilitato per impostazione predefinita nella sezione [wsl2]. Ciò consente di gestire le richieste DNS Linux tramite una funzionalità di virtualizzazione, anziché essere inviate come normali pacchetti di rete. Ciò migliora notevolmente la compatibilità con VPN e configurazioni di rete complesse sull'host.

D'altro canto, autoProxy=true forza WSL a utilizzare le impostazioni del proxy HTTP di WindowsSe l'host si trova dietro un proxy aziendale o di sicurezza, WSL2 lo eredita automaticamente, senza che sia necessario modificare manualmente le variabili di ambiente.

Potresti avere, ad esempio, qualcosa di simile nel tuo .wslconfig:

[wsl2]
dnsTunneling=true
autoProxy=true

Ciò garantisce che la rete WSL2 si comporti in modo coerente con la configurazione dell'host , il che è particolarmente utile nelle aziende con rigide politiche di rete e di filtraggio.

Firewall Hyper-V ed esposizione sicura del servizio

Negli ambienti moderni, la rete WSL2 passa anche attraverso un firewall dedicato . A partire da WSL 2.0.9 su Windows 11 22H2, la funzionalità firewall di Hyper-V è abilitata per impostazione predefinita, aggiungendo un ulteriore livello di filtraggio per il traffico delle macchine virtuali (incluso il traffico WSL2).

Se si lavora in modalità mirror e si desidera esporre in modo permanente i servizi WSL2 alla LAN (ad esempio, API, dashboard o servizi self-hosted), è necessario assicurarsi che le regole del firewall lo consentano.

Un approccio ragionevole da utilizzare con PowerShell con privilegi di amministratore è quello di creare una regola Hyper-V per le reti private :

New-NetFirewallHyperVRule -DisplayName "WSLPrivateInboundRule" -Profiles Private -Direction Inbound -Action Allow -VMCreatorId ((Get-NetFirewallHyperVVMCreator).VMCreatorId)

Se per qualche motivo desideri disabilitare quella specifica protezione Hyper-V (operazione meno consigliata), puoi utilizzare:

Set-NetFirewallHyperVVMSetting -Name ((Get-NetFirewallHyperVVMCreator).VMCreatorId) -Enabled False

L'idea è di mantenere il firewall attivo il più possibile , limitando le regole alle reti private e solo alle porte effettivamente necessarie, riservando la disattivazione di massa come ultima risorsa e sempre con l'obiettivo di ripristinare la sicurezza non appena tutto funziona correttamente.

Architettura di rete WSL2, intervalli X11 e 172.16.0.0/12

Un caso classico che rivela i dettagli della rete WSL2 è l'utilizzo di applicazioni grafiche tramite X11 , ad esempio l'avvio di Xming su Windows e l'invio di applicazioni Linux tramite DISPLAY.

Molti utenti, durante l'aggiornamento da WSL1 a WSL2, scoprono che X smette di funzionare. perché la rete cessa di essere "condivisa" e diventa una rete NAT virtuale con intervalli come 172.16.0.0/12che può cambiare anche dopo ogni riavvio di Windows o WSL.

Per far funzionare di nuovo X con Xming da WSL2, il trucco usuale è ottenere l'indirizzo IP di Windows che Linux vede usando:

ens

DISPLAY=$(grep nameserver /etc/resolv.conf | cut -d' ' -f2):0

Parallelamente, è necessario regolare il firewall di Windows per consentire il traffico X11 da quella subnet NATUn approccio tipico è quello di modificare la regola Xming aggiungendo l'intervallo 172.16.0.0/12 in TCP+UDP 6000.

Molti finiscono per disabilitare l'autenticazione Xming con l'opzione -acQuesto di fatto "apre la porta" a qualsiasi client X proveniente da quella rete. Funziona, ma dal punto di vista della sicurezza è piuttosto discutibile, quindi vale la pena considerare soluzioni più limitate o utilizzare WSLg (applicazioni GUI integrate) in Windows 11.

wsl.conf e .wslconfig: configurazione avanzata di WSL2

WSL offre due file di configurazione chiave che controllano sia il comportamento della VM sia quello di ciascuna distribuzione.: /etc/wsl.conf (per distribuzione) e %UserProfile%\.wslconfig (globale per tutte le distribuzioni WSL2).

wsl.conf vive all'interno della distribuzione Linux, in /etc/wsl.confViene utilizzato per configurare le opzioni locali per quella distribuzione: montaggi automatici, generazione di hosts y resolv.confinteroperabilità con Windows, utente predefinito, systemd, ecc.

.wslconfig Viene salvato al di fuori di Linux, nel profilo utente di Windows. (C:\Users\<Usuario>\.wslconfig) e controlla i parametri globali della VM che alimenta WSL2: memoria, CPU, kernel, modalità di rete, firewall, DNS, dimensioni del disco virtuale, supporto GUI, ecc.

Un dettaglio interessante è la "regola degli 8 secondi" quando si modificano le impostazioni : quando si modifica uno qualsiasi di questi file, è necessario assicurarsi che la macchina virtuale WSL si arresti effettivamente. Anche se si chiude la finestra della distribuzione, il file potrebbe rimanere in memoria per alcuni secondi.

Per forzare il riavvio di un sottosistema è possibile utilizzare :

• wsl --list --running per verificare se ci sono distribuzioni attive
• wsl --shutdown per chiudere tutte le distribuzioni contemporaneamente
• wsl --terminate <distroName> per fermare una distribuzione specifica

Le modifiche alla configurazione vengono applicate effettivamente solo quando WSL viene spento e riavviato , un aspetto che molti trascurano, pensando che le loro impostazioni "non funzionino".

Opzioni principali di wsl.conf per sezione

il file wsl.conf Si ispira al classico formato .ini, con sezioni e chiaviLe sezioni principali sono [automount], [network], [interop], [user], [boot], [gpu] y [time].

En [automount] Puoi controllare come le unità Windows vengono montate all'interno di Linux (tipicamente basso) /mnt):

• enabled (bool, valore predefinito true)Se è vero, C:/, D:/, ecc. vengono montati automaticamente in /mnt/c, /mnt/d...
• mountFsTab (bollo): se è vero, viene elaborato /etc/fstab all'avvio della distribuzione.
• root (catena): directory radice in cui verranno montate le unità, ad esempio /windir/ avere /windir/c.
• options (elenco separato da virgole): Parametri specifici di DrvFs come metadata, uid, gid, umask, fmask, dmask o case.

DrvFs è il file system di collegamento tra Windows e Linux , progettato per accedere a NTFS da WSL con controllo dei permessi, metadati e distinzione tra maiuscole e minuscole.

Nella sezione [network] Si regola la generazione automatica dei file di rete:

• generateHosts: se vero, WSL genera automaticamente /etc/hosts.
• generateResolvConfSe è vero, WSL crea /etc/resolv.conf con DNS legacy.
• hostname: nome host che verrà utilizzato dalla distribuzione.

sezione [interop] controlla l'interoperabilità con Windows:

• enabled: Abilita o disabilita la possibilità di avviare processi Windows da WSL.
• appendWindowsPath: decide se aggiungere percorsi Windows a $PATH Linux.

En [user] È possibile specificare l'utente che verrà utilizzato di default all'avvio della distribuzione:

• default: nome utente che verrà avviato per impostazione predefinita in WSL.

sezione [boot] È particolarmente utile in Windows 11 e Server 2022 per avviare automaticamente servizi, come Docker all'interno di WSL:

• command: stringa di comando da eseguire all'avvio di WSL, ad esempio service docker start.
• protectBinfmt: protegge la generazione di unità systemd quando systemd è abilitato.

Hai anche sezioni come [gpu] (abilita l'accesso alla GPU di Windows da Linux) e [time] per sincronizzare il fuso orario con WindowsIn questo modo si evitano problemi quando si passa all'ora legale o si viaggia.

.wslconfig: controllo della macchina virtuale WSL2

Mentre wsl.conf permette di configurare il comportamento di ciascuna distribuzione, .wslconfig consente di configurare la macchina virtuale condivisa da tutte le distribuzioni WSL2 . Questo file è rilevante solo per le distribuzioni in esecuzione come WSL2, non per WSL1.

Entro .wslconfig la sezione principale è [wsl2]dove si definiscono i parametri chiave:

• kernel y kernelModules: percorsi assoluti da Windows a un kernel Linux personalizzato e ai suoi moduli.
• memory: Limite di memoria della VM (predefinito 50% della RAM dell'host), ad esempio 4GB.
• processors: numero di processori logici assegnati alla VM.
• localhostForwarding: consente alle porte aperte in WSL2 di essere accessibili da Windows utilizzando localhost.
• swap y swapFile: dimensione e percorso del file di swap per la VM.
• guiApplications: abilita o disabilita il supporto delle applicazioni GUI (WSLg).
• dnsProxyQuando si è in modalità NAT, il sistema decide se il server DNS Linux sarà l'istanza NAT dell'host o una copia del DNS di Windows.
• networkingModeQui puoi scegliere tra none, nat, bridged (obsoleto), mirrored o virtioproxy.
• firewall, dnsTunneling y autoProxy: opzioni che abbiamo discusso per integrare meglio la rete WSL con i criteri di Windows.
• defaultVhdSize: dimensione massima del VHD in cui è archiviato il file system della distribuzione (predefinito 1 TB).

C'è anche una sezione [experimental] dove le funzionalità vengono attivate durante i test come:

• autoMemoryReclaim: impostazioni di ripristino automatico della memoria (disabilitato, graduale, dropCache).
• sparseVhd: creazione di dischi virtuali sparsi per risparmiare spazio.
• bestEffortDnsParsing y dnsTunnelingIpAddress: messa a punto per il tunneling DNS.
• ignoredPorts: porte che le app Linux possono utilizzare anche se sono in uso su Windows quando si è in modalità mirroring.
• hostAddressLoopback: consente all'host e al contenitore di connettersi utilizzando gli indirizzi IP locali dell'host in modalità mirroring.

Una corretta configurazione del file .wslconfig fa la differenza tra una macchina virtuale che consuma troppe risorse e un ambiente ottimizzato che funziona bene con Windows e la rete , soprattutto se si lavora con carichi di lavoro pesanti, container o più distribuzioni simultanee.

WSL2, Docker e networking per l'auto-hosting con Tailscale

Un caso molto pratico è l'utilizzo di WSL2 su server Windows (anche Windows Server 2025) come piattaforma di self-hosting , combinando Ubuntu su WSL2, Docker Engine (senza Docker Desktop), Tailscale e un reverse proxy come Caddy per esporre servizi come n8n o Supabase.

L'obiettivo è avere un ambiente Docker stabile all'interno di WSL2, evitando i problemi di Docker Desktop sui server . Installando Docker Engine direttamente su Ubuntu (WSL2), la rete dei container si basa sulla rete di WSL2, che a sua volta dipende dalla modalità NAT o mirror definita in .wslconfig.

Con Tailscale installato su WSL2, è possibile pubblicare i propri servizi su una VPN mesh senza aprire porte sul router e utilizzare Caddy come proxy inverso per centralizzare certificati TLS, routing e bilanciamento del carico leggero tra i container.

Per mantenere una rete pulita, prevedibile e sicura, si consiglia di :

• Scegli una singola modalità di rete coerente (NAT o mirroring) e documentala
• Evita conflitti di porta tra Windows e WSL2, basandosi su ignoredPorts se usi mirroring
• Controllare l'esposizione del servizio solo tramite Tailscale o Caddyinvece di aprire le porte "di default" nel firewall
• Automatizza l'avvio di Docker, Tailscale e Caddy da [boot] in wsl.conf per avere un ambiente più vicino alla produzione

Con questa architettura, WSL2 cessa di essere solo uno strumento di sviluppo e può diventare una piattaforma di self-hosting piuttosto seria , a patto di accettarne i limiti (virtualizzazione su Hyper-V, livello di rete aggiuntivo, ecc.) e di configurarla con attenzione.

Best practice per la rete WSL2 per lo sviluppo e il test

Oltre alla messa a punto, esistono diverse linee guida che ti aiutano a lavorare comodamente con la rete WSL2 senza dover lottare continuamente con indirizzi IP, porte e firewall.

Per i servizi di sviluppo, utilizzare porte elevate (superiori a 1024) ed evitare porte di sistema privilegiate o molto utilizzate; ciò riduce al minimo i conflitti ed elimina la necessità di privilegi aggiuntivi.

Assicurarsi che il codice e i dati risiedano nel file system Linux. (Voi ~/ o percorsi interni) invece di lavorare direttamente su /mnt/cperché l'accesso a NTFS da WSL è più lento e può penalizzare i servizi che richiedono un uso intensivo di I/O.

Automatizza le impostazioni di rete e le regole di reindirizzamento con gli script In PowerShell e Bash: ad esempio, uno script che configura WSL2 all'avvio. netsh portproxy (se si continua con NAT) o controllare le regole del firewall quando si utilizza il mirroring.

Evitare di fare affidamento su IP variabili generato dall'interruttore virtuale interno. Quando possibile, lavorare con localhost, nomi host o voci in /etc/hosts per i tuoi servizi, in modo che un cambio di IP non rompa metà della tua infrastruttura di test.

Negli ambienti professionali o semi-produttivi, è meglio non affidarsi ciecamente all'inoltro automatico di WSL . Configurate esplicitamente porte, proxy e regole del firewall per sapere esattamente cosa è esposto e dove.

Se configurato correttamente, WSL2 offre una rete isolata ma flessibile, ideale per lo sviluppo avanzato, il test delle API, l'utilizzo di container e la simulazione di ambienti distribuiti . La chiave sta nel padroneggiare le modalità di rete (NAT vs. mirroring), i file wsl.conf e .wslconfig e l'interazione con il firewall e gli strumenti del proprio stack (Docker, Tailscale, proxy inversi), in modo che Windows e Linux possano essere eseguiti sulla stessa macchina senza conflitti di porte o compromissioni della sicurezza.