Se usi WSL2 su Windows 11 per strumenti di build, script o servizi interni, il problema non è avviarlo. Il problema è tenerlo affidabile dopo un reboot, senza aprire porte inutili e senza perdere i dati del VHDX.
Qui imposto un profilo da produzione. Il caso è concreto: una distro WSL2 espone un servizio locale, il firewall di Windows deve consentire solo la porta necessaria, e il backup deve essere automatizzato con wbadmin più una verifica del file VHDX.
Il punto chiave è ridurre le sorprese. WSL2 non è una VM tradizionale, ma in produzione va trattato come un componente di servizio. Serve disciplina su rete, permessi e ripristino.
Prerequisiti
- Windows 11 Pro o Enterprise aggiornato.
- WSL2 già abilitato con una distro Linux installata.
- PowerShell avviato come amministratore.
- Spazio libero sufficiente per il backup del volume che contiene il VHDX.
- Accesso al firewall di Windows Defender.
Note: i comandi di backup con wbadmin sono disponibili solo da riga di comando. La parte firewall si può fare anche da GUI.
Step 1: definire il servizio e la porta esposta
In produzione devi partire dal servizio, non dal tool. Se WSL2 ospita, per esempio, un agent HTTP interno, fissa una porta precisa e non lasciare ascolti casuali. Qui uso la porta 8080 come esempio, perché è comune per dashboard o health endpoint.
Dentro la distro, verifica l’ascolto con un test semplice. Se il servizio parte da systemd nella distro, controlla anche lo stato.
ss -lntp | grep ':8080'
systemctl status myservice --no-pager# Output:
LISTEN 0 4096 0.0.0.0:8080 0.0.0.0:* users:("myservice",pid=1234,fd=7)
● myservice.service - Internal app Active: active (running)Se il servizio non è un demone vero, meglio lanciarlo tramite un task schedulato o un servizio Windows che richiama wsl.exe. Evita avvii manuali da terminale utente.
Step 2: aprire il firewall solo per l’host giusto
Se il servizio deve essere raggiunto solo dal PC locale, non aprire la porta su tutte le interfacce. La regola più pulita è limitare il traffico all’host o a una subnet interna.
Da interfaccia grafica vai in Windows Defender Firewall con sicurezza avanzata → Regole in ingresso → Nuova regola. Scegli Porta, poi TCP, quindi 8080. Nella schermata Ambito restringi gli IP remoti consentiti. Se puoi, usa solo 127.0.0.1 per servizi locali o la rete di management.
Da PowerShell, la regola equivalente è più ripetibile e più facile da auditare.
New-NetFirewallRule ` -DisplayName "WSL2 Internal App 8080" ` -Direction Inbound ` -Action Allow ` -Protocol TCP ` -LocalPort 8080 ` -Profile Domain,Private ` -RemoteAddress 127.0.0.1# Output:
Name : {a1b2c3d4-1111-2222-3333-444455556666}
DisplayName : WSL2 Internal App 8080
Enabled : TrueWarning: non usare -RemoteAddress Any se il servizio non è pensato per essere esposto. Su laptop e workstation è il classico errore che trasforma una porta interna in una superficie d’attacco.
Step 3: fissare il comportamento di rete di WSL2
WSL2 usa una rete NAT virtuale e, dopo riavvii o aggiornamenti, può cambiare l’IP della distro. Se il servizio è consumato da tool locali, conviene puntare a localhost con il port-forwarding naturale di WSL2, oppure usare un alias stabile in Windows.
Controlla la versione WSL e lo stato delle distro.
wsl --status
wsl -l -v# Output:
Default Version: 2 NAME STATE VERSION
* Ubuntu-24.04 Running 2Se hai problemi con la risoluzione tra host e distro, aggiorna WSL e riavvia il sottosistema.
wsl --update
wsl --shutdown# Output:
Checking for updates.
The latest version of Windows Subsystem for Linux is already installed.Per un ambiente di produzione, aggiungi anche un controllo post-boot. Un task pianificato può verificare che il servizio sia vivo e che la porta risponda.
Test-NetConnection -ComputerName 127.0.0.1 -Port 8080# Output:
ComputerName : 127.0.0.1
RemotePort : 8080
TcpTestSucceeded : TrueStep 4: rendere persistente l’avvio del servizio
In una distro moderna, la soluzione migliore è usare systemd dentro WSL2. Così il servizio si comporta in modo prevedibile dopo il login o dopo un reboot dell’host.
Dentro la distro, abilita il servizio e verifica che parta automaticamente.
sudo systemctl enable myservice
sudo systemctl start myservice
sudo systemctl is-enabled myservice# Output:
enabledSe il servizio deve avviarsi solo quando arriva traffico locale, valuta un socket activation. In molti casi è più pulita di un demone sempre acceso.
Note: la configurazione di systemd dentro WSL2 dipende dalla distro e dalla versione. Se hai già abilitato systemd, non reinventare l’avvio con script fragili in .bashrc.
Step 5: preparare il backup del VHDX con wbadmin
Il backup vero non è il file copiato a mano mentre la distro è aperta. Serve una copia coerente del volume che ospita il VHDX, più un controllo sulla presenza del file. In scenari piccoli, wbadmin è la scelta più pratica.
Prima individua dove si trova il VHDX. Di solito è sotto il profilo utente, dentro LocalState.
Get-ChildItem "$env:LOCALAPPDATA\Packages" -Recurse -Filter *.vhdx | Select-Object FullName, Length# Output:
FullName Length
-------- ------
C:\Users\alice\AppData\Local\Packages\...\ext4.vhdx 26843545600Poi lancia un backup del volume che contiene quel file. Se il VHDX sta su C:, fai l’immagine del volume con destinazione su disco esterno o share dedicata.
wbadmin start backup -backupTarget:E: -include:C: -quiet# Output:
wbadmin 1.0 - Backup command-line tool
The backup operation completed successfully.Warning: se il VHDX cresce molto, controlla la retention. Un backup pieno di un volume quasi pieno ti porta presto a finire spazio senza avviso.
Step 6: aggiungere un controllo di integrità dopo il backup
Il backup senza verifica è una scommessa. Dopo il job, controlla che il file VHDX esista, che non sia a dimensione zero e che il volume di backup risponda.
$vhdx = Get-ChildItem "$env:LOCALAPPDATA\Packages" -Recurse -Filter *.vhdx | Select-Object -First 1
Test-Path $vhdx.FullName
Get-Item $vhdx.FullName | Select-Object FullName, Length# Output:
True
FullName ...
Length 26843545600Se vuoi un livello in più, pianifica un restore test su una macchina di laboratorio. È il solo modo per sapere se il backup è davvero utile.
Step 7: schedulare tutto con Attività pianificate
La produzione non vive di click ripetuti. Usa l’Utilità di pianificazione per avvio servizio, controllo porta e backup. La GUI resta comoda per la prima impostazione.
Vai in Utilità di pianificazione → Crea attività. Nella scheda Generale usa un account amministrativo o un service account dedicato. Nella scheda Trigger scegli all’avvio del sistema o ogni notte. Nella scheda Azioni inserisci PowerShell con questi parametri:
-NoProfile -ExecutionPolicy Bypass -File C:\Scripts\check-wsl2.ps1# Output:
Task Scheduler: The operation completed successfully.Nel file check-wsl2.ps1 puoi unire controllo servizio, test porta e avvio backup. Mantieni il file breve e leggibile. Un job opaco diventa impossibile da gestire al primo incidente.
Verifica finale
La verifica finale deve essere breve e concreta. Devi vedere tre cose: il servizio è vivo, la porta risponde, il backup è partito e il VHDX è presente.
wsl -d Ubuntu-24.04 -- systemctl is-active myservice
Test-NetConnection 127.0.0.1 -Port 8080
Get-ChildItem "$env:LOCALAPPDATA\Packages" -Recurse -Filter *.vhdx | Select-Object -First 1 | Format-Table FullName, Length# Output:
active
TcpTestSucceeded : True
FullName LengthSe questi tre controlli passano, l’assetto è già buono per un ambiente interno o una workstation critica.
Troubleshooting
Errore: “The system cannot find the file specified.”
Causa: il task punta a un path del VHDX o dello script che è cambiato dopo un update o una reinstallazione della distro.
Fix:
Get-ChildItem "$env:LOCALAPPDATA\Packages" -Recurse -Filter *.vhdx
Get-Item C:\Scripts\check-wsl2.ps1# Output:
FullName ... ext4.vhdx
Mode LastWriteTime Length NameErrore: “TCP connect to (127.0.0.1 : 8080) failed”
Causa: il servizio non ascolta, oppure WSL2 non ha ancora rialzato la rete dopo il reboot.
Fix:
wsl --shutdown
wsl -d Ubuntu-24.04 -- sudo systemctl restart myservice
Test-NetConnection 127.0.0.1 -Port 8080# Output:
TcpTestSucceeded : TrueErrore: “wbadmin failed to create the backup”
Causa: il disco di destinazione è pieno, scollegato o non ha permessi sufficienti.
Fix:
Get-PSDrive E
wbadmin get versions -backupTarget:E:# Output:
Name Used (GB) Free (GB)
E ... ...Conclusione
Un WSL2 usato in produzione non va trattato come sandbox. Serve una porta controllata, un servizio stabile e un backup che sia davvero ripristinabile.
Il passo successivo è fare un restore test del VHDX su una seconda macchina o su una VM di laboratorio. Solo lì scopri se il tuo piano regge un incidente reale.
Commenti (0)
Nessun commento ancora.
Segnala contenuto
Elimina commento
Eliminare definitivamente questo commento?
L'azione non si può annullare.