WSL2 non raggiunge la sottorete VPN: leggete la rotta dell’host

Dall’interno della distribuzione, un ping verso un server interno scade mentre lo stesso indirizzo risponde da Windows. La VPN è connessa e la rotta di Windows è corretta, quindi il divario è il confine di WSL. Percorrete il cammino dal comando che fallisce fino all’interfaccia dell’host. La correzione non è un CIDR fisso in un file di configurazione; è leggere l’indirizzo attuale e aggiungerlo dove la distribuzione può usarlo.

Confermate dove si ferma il cammino

Eseguite la stessa prova su entrambi i lati: risolvete e collegatevi a un host interno da Windows, poi ripetetelo nella distribuzione. Un successo in Windows più un timeout nella distribuzione collocano il guasto tra i due, non nel client VPN né nel server interno. Fatelo prima di cambiare qualsiasi rotta, così i due risultati descrivono la stessa destinazione.

Dentro la distribuzione, ip -4 addr mostra un adattatore virtuale con un indirizzo dell’intervallo NAT di WSL, e ip route mostra una rotta predefinita verso il gateway WSL. Non esiste una rotta per il prefisso aziendale, perché l’adattatore del tunnel dell’host non ha un equivalente dentro la distribuzione. Il gateway predefinito porta al NAT di WSL, non alla rete aziendale.

Aggiungere la rotta aziendale senza prima aggiungere un indirizzo locale su un collegamento raggiungibile produce un timeout o un errore di rete irraggiungibile. L’indirizzo è la parte che rende utilizzabile la rotta, quindi leggetelo per primo e trattate la rotta come secondo passo.

Scegliete la rete rispecchiata o una rotta con script

La rete rispecchiata offre alla distribuzione le interfacce dell’host stesso, così il tunnel e le sue rotte compaiono senza copiare. La funzione dipende da una build recente di Windows e da networkingMode=mirrored in .wslconfig, e attivarla cambia comportamenti non correlati come l’inoltro di localhost. Trattatela come un cambio di piattaforma, non come una messa a punto della rotta. Se la build la supporta e gli effetti collaterali sono accettabili, è la via più breve.

L’approccio più stretto mantiene il NAT predefinito e copia l’indirizzo e la rotta del tunnel nella distribuzione ogni volta che il tunnel sale. Funziona su più build, non cambia il comportamento di localhost e fallisce in modo visibile quando la VPN è spenta. Il costo è un piccolo script da eseguire a ogni connessione.

Sceglietene uno e scrivetelo. Mescolare una configurazione rispecchiata con rotte manuali produce una distribuzione con due cammini verso lo stesso prefisso e senza un proprietario chiaro per nessuno dei due. Un metodo documentato è più facile da diagnosticare di due mezzi configurati.

Ricavate i dettagli attuali del tunnel dall’host

Abbinate l’adattatore per indirizzo MAC e non per nome, perché i nomi cambiano con il client VPN e con l’ordine di connessione. Elencate gli adattatori una volta, annotate il MAC dell’adattatore del tunnel, poi chiedete il suo indirizzo e il prefisso. Il MAC resta con l’adattatore virtuale tra le riconnessioni, mentre il nome e l’indice dell’interfaccia no:

powershell.exe 'Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" } | Get-NetIPAddress -AddressFamily IPv4 | Select-Object IPAddress, PrefixLength'

Il gateway proviene dalla configurazione dell’interfaccia. Prendete prima l’indice dell’interfaccia, poi leggete il salto successivo. L’indice può cambiare dopo un riavvio o un reset dell’adattatore, perciò lo script deve leggerlo invece di memorizzarlo:

powershell.exe '(Get-NetAdapter | Where-Object { $_.MacAddress -eq "3C-52-82-0A-1B-7C" }).InterfaceIndex'
powershell.exe '(Get-NetIPConfiguration -InterfaceIndex 27).IPv4DefaultGateway.NextHop'

Fate passare l’output attraverso tr -d '\r' prima di assegnarlo a una variabile. PowerShell termina le righe con un ritorno carrello, e senza la rimozione l’ultimo campo porta un carattere nascosto che fa fallire un comando di rotta con un errore di analisi confuso.

Applicate l’indirizzo e la rotta dentro la distribuzione

Installate l’indirizzo del tunnel come indirizzo con prefisso sull’interfaccia della distribuzione, poi instradate il blocco aziendale attraverso il gateway dell’host:

sudo ip addr add 172.20.14.37/22 dev vpn
sudo ip route add 172.20.0.0/16 via 172.20.12.1 dev vpn

NetworkManager scarta un indirizzo configurato a mano quando la connessione si riavvia, e nessun client DHCP ne chiede uno sostitutivo. Impostate il metodo su automatico perché ogni riconnessione aggiorni l’indirizzo, poi riattivate la connessione. Il metodo manuale sembra stabile fino alla prima riconnessione:

nmcli con show vpn
sudo nmcli con mod vpn ipv4.method auto
sudo nmcli con up vpn

Eseguite entrambi i passi dall’hook che avvia la VPN, non da una shell interattiva. Uno script che legge l’indirizzo, lo aggiunge, aggiunge la rotta e registra i valori trasforma una riparazione manuale ricorrente in una ripetibile, e il registro è la prima cosa da leggere quando il prefisso cambia.

Fissate il nome e dimostrate il cammino

Il kernel può rinominare l’interfaccia della distribuzione tra eth1 ed eth2 dopo un cambio di rete, e uno script scritto per un nome modifica allora il dispositivo sbagliato. Una regola udev legata al MAC dà all’interfaccia un’etichetta stabile:

SUBSYSTEM=="net", ACTION=="add", ATTRS{address}=="3c:52:82:0a:1b:7c", NAME="vpn"

Poi verificate con l’indirizzo, la rotta e una connessione TCP reale: ip -4 addr show dev vpn, ip route get 172.20.4.10 e una connessione a una porta interna nota. La ricerca della rotta dovrebbe nominare il dispositivo vpn e l’indirizzo sorgente che avete aggiunto.

Se tutte e tre passano dentro la distribuzione e la connessione fallisce ancora, il pacchetto lascia WSL e viene scartato sul lato Windows. Controllate il firewall dell’host e il filtraggio del client VPN prima di cambiare lo script, perché un’altra modifica di rotta non sistemerà un pacchetto che raggiunge già l’host.