WSL2 non chega á subrede VPN: lea a ruta do host

Desde dentro da distribución, un ping a un servidor interno caduca mentres o mesmo enderezo responde desde Windows. A VPN está conectada e a ruta de Windows é correcta, así que o oco é o límite de WSL. Percorra o camiño desde o comando que falla ata a interface do host. A solución non é un CIDR fixo nun ficheiro de configuración; é ler o enderezo actual e engadilo onde a distribución poida usalo.

Confirme onde se detén o camiño

Execute a mesma proba nos dous lados: resolva e conéctese a un host interno desde Windows e repítao na distribución. Un éxito en Windows máis un tempo de espera na distribución sitúan o fallo entre ambos, non no cliente VPN nin no servidor interno. Fágao antes de cambiar calquera ruta, para que os dous resultados describan o mesmo destino.

Dentro da distribución, ip -4 addr mostra un adaptador virtual cun enderezo do rango NAT de WSL, e ip route mostra unha ruta predeterminada cara á pasarela de WSL. Non hai ruta para o prefixo corporativo, porque o adaptador de túnel do host non ten equivalente dentro da distribución. A pasarela predeterminada leva ao NAT de WSL, non á rede corporativa.

Engadir a ruta corporativa sen engadir antes un enderezo local nunha ligazón alcanzable produce un tempo de espera ou un erro de rede inalcanzable. O enderezo é a parte que fai útil a ruta, así que lea primeiro e trate a ruta como o segundo paso.

Escolla rede reflectida ou unha ruta con script

A rede reflectida entrega á distribución as interfaces propias do host, así que o túnel e as súas rutas aparecen sen copiar. A función depende dunha compilación recente de Windows e de networkingMode=mirrored en .wslconfig, e activala cambia comportamentos non relacionados como o reenvío de localhost. Tráteo como un cambio de plataforma, non como un axuste de ruta. Se a compilación o admite e os efectos secundarios son aceptables, é o camiño máis curto.

O enfoque máis estreito mantén o NAT predeterminado e copia o enderezo e a ruta do túnel na distribución cada vez que o túnel se levanta. Funciona en máis compilacións, non cambia o comportamento de localhost e falla de forma visible cando a VPN está caída. O custo é un script pequeno que debe executarse en cada conexión.

Escolla un e escríbao. Mesturar unha configuración reflectida con rutas manuais produce unha distribución con dous camiños ao mesmo prefixo e sen un dono claro para ningún. Un método documentado é máis fácil de depurar que dous a medio configurar.

Extraia os detalles actuais do túnel do host

Emparede o adaptador por enderezo MAC e non por nome, porque os nomes cambian co cliente VPN e coa orde de conexión. Enumere os adaptadores unha vez, anote a MAC do adaptador de túnel e consulte o seu enderezo e prefixo. A MAC permanece co adaptador virtual entre reconexións, mentres que o nome e o índice de interface non:

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

A pasarela vén da configuración da interface. Obteña primeiro o índice de interface e lea despois o seguinte salto. O índice pode cambiar tras un reinicio ou un reinicio do adaptador, por iso o script debe lelo en lugar de gardalo:

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

Pase a saída por tr -d '\r' antes de asignala a unha variable. PowerShell termina as liñas cun retorno de carro, e sen eliminalo o último campo leva un carácter oculto que fai fallar un comando de ruta cun erro de análise confuso.

Aplique o enderezo e a ruta dentro da distribución

Instale o enderezo do túnel como enderezo con prefixo na interface da distribución e logo encamiñe o bloque corporativo pola pasarela do 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 descarta un enderezo configurado manualmente cando a conexión se reinicia, e ningún cliente DHCP pide un substituto. Pon o método en automático para que cada reconexión refresque o enderezo e logo volve levantar a conexión. O método manual parece estable ata a primeira reconexión:

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

Execute os dous pasos desde o gancho que inicia a VPN, non desde un shell interactivo. Un script que le o enderezo, engádeo, engade a ruta e rexistra os valores converte unha reparación manual recorrente nunha repetible, e o rexistro é o primeiro que hai que ler cando cambia o prefixo.

Fixe o nome e demostre o camiño

O núcleo pode renomear a interface da distribución entre eth1 e eth2 tras un cambio de rede, e un script escrito para un nome edita entón o dispositivo equivocado. Unha regra udev ligada á MAC dálle á interface unha etiqueta estable:

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

Logo verifique co enderezo, a ruta e unha conexión TCP real: ip -4 addr show dev vpn, ip route get 172.20.4.10 e unha conexión a un porto interno coñecido. A consulta de ruta debería nomear o dispositivo vpn e o enderezo de orixe que engadiu.

Se as tres probas pasan dentro da distribución e a conexión segue fallando, o paquete sae de WSL e descártase no lado de Windows. Comprobe a devasa do host e o filtrado propio do cliente VPN antes de cambiar o script, porque outra edición de ruta non arranxará un paquete que xa chega ao host.