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 cambiato completamente il modo in cui Linux si integra con WindowsSoprattutto per quanto riguarda la rete: ora disponiamo di una macchina virtuale leggera con il proprio stack di rete, il proprio indirizzo IP e regole di accesso separate. Questo apre numerose possibilità per lo sviluppo, il test, i container e gli ambienti self-hosting, ma solleva anche preoccupazioni quando i servizi diventano inaccessibili, come è successo con WSL1.

Comprendere la configurazione di rete WSL2, le sue modalità NAT e mirroring, l'uso di .wslconfig e wsl.conf e come interagiscono con firewall, VPN, Docker o strumenti come Tailscale Questo è fondamentale per evitare mal di testa. Vediamo passo dopo passo come funziona l'intera configurazione, come esporre i servizi a Windows e alla LAN, quali comandi utilizzare per ottenere gli 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 tua distribuzione WSL2 non è né stabile né direttamente accessibile dalla LAN Come con WSL1: per impostazione predefinita, la connettività tra Windows e WSL2 avviene solo tramite regole di reindirizzamento e NAT, mentre l'esposizione alla rete locale richiede passaggi aggiuntivi o l'uso della modalità mirroring.

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 visualizzato da Linux. Ciascuno viene risolto con un comando diverso.

Scenario 1: da Windows si desidera conoscere l'indirizzo IP della distribuzione WSL2 Per consentire a un'applicazione sull'host (ad esempio, un client, un browser o uno strumento di test) di connettersi a un servizio in esecuzione su Linux, è possibile eseguire i seguenti comandi in Windows (utilizzando 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 WindowsAd esempio, per connettere un'applicazione WSL2 a un server in esecuzione nativa 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 come 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, questa è più che sufficiente.L'importante è capire cosa funziona "da solo" e cosa no, per non perdere tempo a dare la caccia ai fantasmi.

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 LinuxEcco dove 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 come visto da Linux, ottenuto con il comando default route:

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 di concentrarsi sulla sicurezza.perché stai consentendo connessioni dalla tua rete locale, non solo dal computer 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 LANIn WSL1, se Windows era visibile sulla rete, i servizi della distribuzione ereditavano tale esposizione quasi senza sforzo.

In WSL2, la VM ha un proprio indirizzo IP privato e non viene pubblicizzata automaticamente sulla LAN.Per ottenere un comportamento simile a quello precedente, in modalità NAT è necessario creare un proxy di porta in Windows, 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, dovresti sostituire 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 LANa condizione che il firewall di Windows lo consenta e che sia chiaro che si sta esponendo un servizio di una macchina virtuale, non direttamente l'host.

IPv6 e funzionalità di rete moderne

WSL2 può funzionare anche con IPv6, il che è 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 di 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

Dove il salto di qualità nel supporto IPv6 e VPN è veramente evidente è nella modalità di rete mirroring, disponibile in Windows 11 22H2 e versioni successive, che vedremo più avanti in dettaglio.

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

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

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à mirroring:

[wsl2]
networkingMode=mirrored

Una volta salvato il file, è necessario riavviare WSL2 affinché le modifiche abbiano effetto.Ad esempio, con:

wsl --shutdown

Al riavvio, WSL utilizzerà la nuova architettura di rete speculare.che porta con sé diversi vantaggi molto potenti:

• 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'abilitazione di questa modalità risolve molti dei classici problemi NAT WSL2 ed è l'opzione consigliata nella maggior parte degli ambienti di sviluppo e 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., particolarmente utile nelle aziende con rigide politiche di rete e 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 Hyper-V è abilitata per impostazione predefinita, aggiungendo un ulteriore livello di filtraggio per il traffico delle VM (incluso il traffico WSL2).

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

Un approccio ragionevole da 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 qualsiasi motivo desideri disabilitare quella specifica protezione Hyper-V (qualcosa di meno consigliato), potresti usare:

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

L'idea è di mantenere il firewall attivo ogniqualvolta possibile.limitando le regole alle reti private e solo alle porte realmente necessarie, riservando qualsiasi disattivazione di massa come ultima risorsa e sempre con l'obiettivo di rafforzare nuovamente la configurazione non appena tutto funziona.

Architettura di rete WSL2, intervalli X11 e 172.16.0.0/12

Un caso classico che rivela i dettagli della rete WSL2 è l'uso di applicazioni grafiche tramite X11Ad esempio, avviare Xming su Windows e inviare 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 più comune è ottenere l'indirizzo IP di Windows che vede Linux. utilizzando:

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 curioso è la "regola degli 8 secondi" quando si cambiano le impostazioni.Quando si modifica uno di questi file, è necessario assicurarsi che la VM WSL sia completamente spenta. Anche se si chiude la finestra della distribuzione, i file potrebbero rimanere in memoria per alcuni secondi.

Per forzare il riavvio del 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 effettivamente applicate solo quando WSL viene arrestato e riavviato.Qualcosa che molti trascurano e pensano che i loro adattamenti "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 che fa da ponte 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 ottimizza il comportamento di ogni distribuzione, .wslconfig consente di ottimizzare la VM condivisa da tutte le distribuzioni WSL2.Questo file viene preso in considerazione solo dalle distribuzioni che funzionano come WSL2, non come 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 di .wslconfig fa la differenza tra una macchina virtuale che consuma molte risorse e un ambiente ottimizzato che funziona bene con il sistema 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 esempio molto pratico è l'utilizzo di WSL2 sui server Windows (anche Windows Server 2025) come piattaforma di auto-hosting, combinando Ubuntu su WSL2, Docker Engine (senza Docker Desktop), Tailscale e un proxy inverso come Caddy per esporre servizi come n8n o Supabase.

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

Con Tailscale installato su WSL2, puoi pubblicare i tuoi servizi su una VPN mesh. senza aprire porte sul router e utilizzando Caddy come proxy inverso per centralizzare i certificati TLS, i percorsi e il bilanciamento del carico leggero tra i container.

Per mantenere una rete pulita, prevedibile e sicura, è consigliabile:

• 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 un semplice strumento di sviluppo e può trasformarsi in una piattaforma di self-hosting piuttosto seria.a condizione che se ne accettino le limitazioni (virtualizzazione su Hyper-V, livello di rete aggiuntivo, ecc.) e che lo si configuri con attenzione.

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

Oltre alla messa a punto, ci sono una serie di linee guida che ti aiutano a lavorare comodamente con la rete WSL2 senza dover combattere costantemente con IP, porte e firewall.

Per i servizi di sviluppo, utilizzare porte alte (superiori a 1024) ed evitare porte 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 di semi-produzione, è meglio non affidarsi ciecamente all'inoltro automatico di WSL.Configurare in modo esplicito porte, proxy e regole del firewall per sapere esattamente cosa è esposto e dove.

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