1,343 25/03/2026 07/04/2026 8 min

In produzione, WSL2 su Windows Server 2022 non è un giocattolo. Serve per tool interni, build legacy, script Linux e piccoli servizi di supporto. Il problema arriva quando il riavvio del servizio LxssManager cambia il comportamento del firewall, lascia la porta 8080 esposta male o rompe un backup fatto in fretta.

Questo articolo prende un caso reale: un server con una distro Ubuntu in WSL2 che espone un servizio interno su 127.0.0.1:8080, accessibile solo da amministrazione e rete di management. L’obiettivo è fare una configurazione da produzione, con regole minime, verifiche post-reboot e backup ripristinabile del VHDX.

Warning: se WSL2 ospita dati importanti, non affidarti solo allo snapshot del disco virtuale. Devi testare anche il restore. Un backup non verificato è solo un file grande.

Prerequisiti

  • Windows Server 2022 o Windows 11 Pro/Enterprise aggiornato.
  • WSL2 abilitato con una distribuzione Linux già installata.
  • Permessi amministrativi locali.
  • PowerShell 5.1 o 7.
  • Un servizio Linux in ascolto nella distro, ad esempio su porta 8080.
  • Accesso a un percorso di backup su volume diverso dal disco di sistema.

Note: i comandi mostrati sono pensati per un host con WSL2 già funzionante. Non coprono l’installazione base della feature. Qui contano hardening, persistenza e recovery.

Step 1: fotografare lo stato prima di toccare firewall e servizi

Serve un punto di partenza. In produzione, ogni modifica senza baseline crea dubbi quando qualcosa smette di rispondere. Qui controlliamo la versione di WSL, le distro registrate e il servizio LxssManager.

wsl --status
wsl -l -v
Get-Service LxssManager | Select-Object Status, Name, StartType
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

# Output: WSL 2 come versione predefinita, distro in stato Running o Stopped, LxssManager presente e profili firewall con policy note.

Se il servizio è disabilitato o il firewall è stato irrigidito da GPO, lo scopri subito. In quel caso il problema non è nella distro. È nell’host.

Step 2: fissare il servizio Linux dentro WSL2 con restart automatico controllato

Molti lasciano il processo partire a mano nella shell WSL. In produzione è fragile. Conviene farlo partire con un servizio Linux gestito dalla distro, con restart policy e log leggibili. Un esempio semplice è un demone esposto con systemd, se la distro lo supporta.

# dentro la distro WSL2
sudo systemctl enable myapp.service
sudo systemctl edit myapp.service
[Service]
Restart=always
RestartSec=3
User=appsvc
Group=appsvc

# Output: il servizio si riavvia dopo crash, senza intervento manuale.

Se usi una distro senza systemd pieno, il principio non cambia. Devi avere un avvio controllato, non una shell interattiva lasciata aperta. Un processo che muore al logout non è un servizio.

Perché questo conta

WSL2 non è un hypervisor classico. Se la sessione si chiude male o il backend si resetta, il processo può sparire. Una policy di restart riduce il fermo dopo aggiornamenti, login interrotti o riavvii di LxssManager.

Step 3: bloccare la porta con regole firewall mirate, non con eccezioni larghe

Il punto delicato è il traffico verso il servizio pubblicato da WSL2. In molti ambienti il traffico entra dall’host verso localhost o verso un indirizzo NAT generato da WSL. La regola giusta dipende dal caso, ma la logica è sempre la stessa: consentire solo ciò che serve.

New-NetFirewallRule -DisplayName "WSL2 app 8080 from mgmt" `
  -Direction Inbound -Action Allow -Protocol TCP -LocalPort 8080 `
  -Profile Domain -RemoteAddress 10.20.0.0/24,10.20.1.15

# Output: solo la subnet di management e un host specifico possono raggiungere la porta 8080.

Se il servizio deve restare interno all’host, la regola deve essere ancora più stretta. In quel caso limita l’origine al loopback o evita la pubblicazione esterna. Il firewall non deve diventare un elenco di eccezioni permanenti.

Note: se l’app è raggiunta da browser o agenti locali, verifica anche Windows Defender Firewall con profili Domain, Private e Public. Un cambio di profilo dopo una VPN può bloccare tutto.

Step 4: verificare che il binding sia quello giusto dopo il riavvio di LxssManager

Il sintomo tipico è questo: il servizio Linux è vivo, ma la porta non risponde più dove ti aspetti. Succede dopo restart di LxssManager, aggiornamenti di WSL o wake da sospensione.

Restart-Service LxssManager
Start-Sleep -Seconds 5
netstat -ano | findstr :8080
Test-NetConnection 127.0.0.1 -Port 8080

# Output: la porta 8080 resta in ascolto e il test TCP su localhost torna True.

Se il test fallisce, entra nella distro e controlla il listener reale. In produzione io verifico sempre anche lato Linux.

ss -ltnp | grep 8080
curl -I http://127.0.0.1:8080/health

# Output: il processo ascolta su 0.0.0.0:8080 o 127.0.0.1:8080 e l’endpoint health risponde 200.

Un binding su 0.0.0.0 non è sempre sbagliato, ma va giustificato. Se basta localhost, usa localhost. Meno superficie, meno errori.

Step 5: mettere in sicurezza l’accesso alla distro con account separato e permessi minimi

Molti amministratori usano il proprio account Windows anche per operare dentro WSL2. È comodo, ma rischioso. Per un servizio esposto conviene un utente Linux dedicato, senza privilegi inutili.

sudo useradd --system --create-home --shell /usr/sbin/nologin appsvc
sudo chown -R appsvc:appsvc /opt/myapp
sudo chmod 750 /opt/myapp

# Output: utente di servizio dedicato e directory non scrivibile da altri.

Per i file di configurazione sensibili, limita ancora di più. Chiavi, token e connection string non devono stare in una cartella world-readable. Se l’app deve leggere segreti, meglio file separati con 600.

sudo install -m 600 /dev/null /etc/myapp/secrets.env
sudo chown root:root /etc/myapp/secrets.env

Warning: non usare l’account Administrator come proprietario dei dati della distro. Se il servizio cambia utente, ti ritrovi con permessi incoerenti e restore più difficili.

Step 6: fare backup del VHDX senza fermare tutto, ma con una finestra coerente

Il file della distro WSL2 è un VHDX. È il cuore del backup. Copiarlo mentre il file è in uso può funzionare male o produrre una copia incoerente. La pratica migliore è fermare la distro, copiare il VHDX, poi riaprirla. Se non puoi fermarla, devi usare una strategia più robusta.

wsl --shutdown
Copy-Item "C:\Users\Public\Documents\WSL\Ubuntu\ext4.vhdx" `
  "D:\Backup\WSL\Ubuntu\ext4.vhdx" -Force
wsl -d Ubuntu

# Output: copia del VHDX completata e distro riavviata manualmente.

Per un contesto più serio, integra un backup host-level con wbadmin o con il tuo tool aziendale, ma includi il percorso del VHDX nel set protetto. Il backup dell’host non è automatico se il disco virtuale è altrove.

wbadmin start backup -backupTarget:D: -include:C:,D:\Backup\WSL -quiet

# Output: backup avviato verso il target D: con il percorso WSL incluso.

Se la macchina usa un sistema di backup centralizzato, etichetta il file VHDX con data e versione. Un nome chiaro accelera il restore quando serve davvero.

Step 7: validare un restore di prova, non solo la presenza del file

Il backup va testato su una macchina o su una cartella di prova. Qui il punto non è il volume del file, ma l’avvio della distro ripristinata e la lettura dei dati.

wsl --import Ubuntu-Test D:\WSL\Test D:\Backup\WSL\Ubuntu\ext4.vhdx --version 2
wsl -d Ubuntu-Test -- uname -a

# Output: la distro di test si registra e uname restituisce il kernel Linux WSL.

Se il servizio interno riparte e l’endpoint health risponde, il backup è utile. Se il VHDX si importa ma l’app non parte, hai un problema di coerenza o di dipendenze mancanti nel filesystem.

Verifica finale

La verifica finale deve essere corta e ripetibile. Io uso sempre la stessa sequenza, dopo ogni riavvio e dopo ogni patch cumulativa.

  1. Controllo che LxssManager sia running.
  2. Controllo che la distro sia presente e avviabile.
  3. Controllo che la porta 8080 risponda solo dal range consentito.
  4. Controllo che il servizio Linux sia in restart policy.
  5. Controllo che il VHDX sia nel backup giornaliero.
Get-Service LxssManager
wsl -l -v
Test-NetConnection 127.0.0.1 -Port 8080
Get-NetFirewallRule -DisplayName "WSL2 app 8080 from mgmt" | Select-Object Enabled, Direction, Action
Get-ChildItem D:\Backup\WSL\Ubuntu\ext4.vhdx | Select-Object Name, Length, LastWriteTime

# Output: servizio attivo, distro disponibile, porta raggiungibile, regola presente e VHDX aggiornato.

Note: se usi monitoraggio, aggiungi un controllo sintetico su Test-NetConnection e uno script che segnali la data dell’ultimo backup valido.

Troubleshooting

1) "The virtual machine could not be started because a required feature is not installed"

La causa più comune è Hyper-V o Virtual Machine Platform assente o disabilitata dopo update o hardening.

Fix:

Enable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform -NoRestart
Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux -NoRestart
Restart-Computer

# Output: le feature risultano abilitate e WSL2 riparte dopo il reboot.

2) "An attempt was made to access a socket in a way forbidden by its access permissions"

La causa è quasi sempre un conflitto di binding o una regola firewall che lascia passare la porta sbagliata.

Fix:

Stop-Process -Id (Get-NetTCPConnection -LocalPort 8080).OwningProcess -Force
Get-NetFirewallRule -DisplayName "WSL2 app 8080 from mgmt" | Set-NetFirewallRule -Enabled True

# Output: il processo conflittuale viene chiuso e la regola torna attiva.

3) "The file is being used by another process"

La causa è una copia del VHDX eseguita senza fermare WSL o senza svuotare correttamente la sessione.

Fix:

wsl --shutdown
Start-Sleep -Seconds 3
Copy-Item "C:\Users\Public\Documents\WSL\Ubuntu\ext4.vhdx" "D:\Backup\WSL\Ubuntu\ext4.vhdx" -Force

# Output: il file viene copiato senza lock attivi.

Conclusione

WSL2 in produzione funziona bene solo se tratti host, firewall e backup come un unico sistema. Il servizio può essere leggero, ma la disciplina operativa deve essere pesante.

Il prossimo passo concreto è trasformare queste verifiche in uno script PowerShell pianificato. Aggiungi un alert se LxssManager si riavvia, la porta 8080 cambia stato o il VHDX non si aggiorna entro la finestra attesa.