WSL2 no arriba a la subxarxa VPN: llegiu la ruta de l'amfitrió

Des de dins de la distribució, un ping a un servidor intern expira mentre la mateixa adreça respon des de Windows. La VPN està connectada i la ruta de Windows és correcta, així que el buit és la frontera de WSL. Recorreu el camí des de l'ordre que falla fins a la interfície de l'amfitrió. La solució no és un CIDR fix en un fitxer de configuració; és llegir l'adreça actual i afegir-la allà on la distribució la pugui fer servir.

Confirmeu on s'atura el camí

Executeu la mateixa prova als dos costats: resoleu i connecteu un amfitrió intern des de Windows i repetiu-ho a la distribució. Un èxit a Windows més un temps d'espera a la distribució situen la fallada entremig, no al client VPN ni al servidor intern. Feu-ho abans de canviar qualsevol ruta, perquè els dos resultats descriguin la mateixa destinació.

Dins de la distribució, ip -4 addr mostra un adaptador virtual amb una adreça del rang NAT de WSL, i ip route mostra una ruta per defecte cap a la porta d'enllaç de WSL. No hi ha cap ruta per al prefix corporatiu, perquè l'adaptador de túnel de l'amfitrió no té cap equivalent dins de la distribució. La porta d'enllaç per defecte porta al NAT de WSL, no a la xarxa corporativa.

Afegir la ruta corporativa sense afegir primer una adreça local en un enllaç abastable produeix un temps d'espera o un error de xarxa inabastable. L'adreça és la part que fa útil la ruta, així que llegiu-la primer i tracteu la ruta com el segon pas.

Trieu xarxa replicada o una ruta amb script

La xarxa replicada dona a la distribució les interfícies pròpies de l'amfitrió, així que el túnel i les seves rutes apareixen sense copiar. La funció depèn d'una compilació recent de Windows i de networkingMode=mirrored a .wslconfig, i activar-la canvia comportaments no relacionats com el reenviament de localhost. Tracteu-ho com un canvi de plataforma, no com un ajust de ruta. Si la compilació ho admet i els efectes secundaris són acceptables, és el camí més curt.

L'enfocament més estret manté el NAT per defecte i copia l'adreça i la ruta del túnel a la distribució sempre que el túnel s'aixeca. Funciona en més compilacions, no canvia el comportament de localhost i falla de manera visible quan la VPN està caiguda. El cost és un script petit que s'ha d'executar a cada connexió.

Trieu-ne un i escriviu-lo. Barrejar una configuració replicada amb rutes manuals produeix una distribució amb dos camins cap al mateix prefix i sense un propietari clar per a cap dels dos. Un mètode documentat és més fàcil de depurar que dos de mig configurats.

Extraieu els detalls actuals del túnel de l'amfitrió

Feu coincidir l'adaptador per adreça MAC i no per nom, perquè els noms canvien amb el client VPN i l'ordre de connexió. Llisteu els adaptadors una vegada, anoteu la MAC de l'adaptador de túnel i consulteu-ne l'adreça i el prefix. La MAC es manté amb l'adaptador virtual entre reconnexions, mentre que el nom i l'índex d'interfície no:

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

La porta d'enllaç prové de la configuració de la interfície. Obteniu primer l'índex d'interfície i llegiu després el següent salt. L'índex pot canviar després d'un reinici o d'un reinici de l'adaptador, i per això l'script l'ha de llegir en lloc de desar-lo:

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

Passeu la sortida per tr -d '\r' abans d'assignar-la a una variable. PowerShell acaba les línies amb un retorn de carro, i sense eliminar-lo l'últim camp porta un caràcter ocult que fa fallar una ordre de ruta amb un error d'anàlisi confús.

Apliqueu l'adreça i la ruta dins de la distribució

Instal·leu l'adreça del túnel com a adreça amb prefix a la interfície de la distribució i encamineu el bloc corporatiu per la porta d'enllaç de l'amfitrió:

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 descarta una adreça configurada manualment quan la connexió es reinicia, i cap client DHCP en demana una de substitució. Posa el mètode en automàtic perquè cada reconnexió refresqui l'adreça i torna a aixecar la connexió. El mètode manual sembla estable fins a la primera reconnexió:

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

Executeu els dos passos des del ganxo que inicia la VPN, no des d'una shell interactiva. Un script que llegeix l'adreça, l'afegeix, afegeix la ruta i registra els valors converteix una reparació manual recurrent en una de repetible, i el registre és el primer que cal llegir quan el prefix canvia.

Fixeu el nom i demostreu el camí

El nucli pot canviar el nom de la interfície de la distribució entre eth1 i eth2 després d'un canvi de xarxa, i un script escrit per a un nom edita llavors el dispositiu equivocat. Una regla udev lligada a la MAC dona a la interfície una etiqueta estable:

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

Després verifiqueu amb l'adreça, la ruta i una connexió TCP real: ip -4 addr show dev vpn, ip route get 172.20.4.10 i una connexió a un port intern conegut. La consulta de ruta hauria de nomenar el dispositiu vpn i l'adreça d'origen que heu afegit.

Si les tres proves passen dins de la distribució i la connexió encara falla, el paquet surt de WSL i es descarta al costat de Windows. Comproveu el tallafoc de l'amfitrió i el filtratge propi del client VPN abans de canviar l'script, perquè una altra edició de ruta no arreglarà un paquet que ja arriba a l'amfitrió.