WSL2 no llega a la subred VPN: lea la ruta del host

Desde dentro de la distribución, un ping a un servidor interno caduca mientras la misma dirección responde desde Windows. La VPN está conectada y la ruta de Windows es correcta, así que el hueco es el límite de WSL. Recorra el camino desde el comando que falla hasta la interfaz del host. La solución no es un CIDR fijo en un archivo de configuración; es leer la dirección actual y añadirla donde la distribución pueda usarla.

Confirme dónde se detiene el camino

Ejecute la misma prueba en ambos lados: resuelva y conéctese a un host interno desde Windows y repítalo en la distribución. Un éxito en Windows más un tiempo de espera en la distribución sitúan el fallo entre ambos, no en el cliente VPN ni en el servidor interno. Hágalo antes de cambiar cualquier ruta, para que los dos resultados describan el mismo destino.

Dentro de la distribución, ip -4 addr muestra un adaptador virtual con una dirección del rango NAT de WSL, y ip route muestra una ruta predeterminada hacia la puerta de enlace de WSL. No hay ruta para el prefijo corporativo, porque el adaptador de túnel del host no tiene equivalente dentro de la distribución. La puerta de enlace predeterminada lleva al NAT de WSL, no a la red corporativa.

Añadir la ruta corporativa sin añadir antes una dirección local en un enlace alcanzable produce un tiempo de espera o un error de red inalcanzable. La dirección es la parte que hace utilizable la ruta, así que léala primero y trate la ruta como el segundo paso.

Elija red reflejada o una ruta con script

La red reflejada entrega a la distribución las interfaces propias del host, así que el túnel y sus rutas aparecen sin copiar. La función depende de una compilación reciente de Windows y de networkingMode=mirrored en .wslconfig, y activarla cambia comportamientos no relacionados como el reenvío de localhost. Trátelo como un cambio de plataforma, no como un ajuste de ruta. Si la compilación lo admite y los efectos secundarios son aceptables, es el camino más corto.

El enfoque más estrecho mantiene el NAT predeterminado y copia la dirección y la ruta del túnel en la distribución cada vez que el túnel se levanta. Funciona en más compilaciones, no cambia el comportamiento de localhost y falla de forma visible cuando la VPN está caída. El coste es un script pequeño que debe ejecutarse en cada conexión.

Elija uno y escríbalo. Mezclar una configuración reflejada con rutas manuales produce una distribución con dos caminos al mismo prefijo y sin un dueño claro para ninguno. Un método documentado es más fácil de depurar que dos a medio configurar.

Extraiga los detalles actuales del túnel del host

Empareje el adaptador por dirección MAC y no por nombre, porque los nombres cambian con el cliente VPN y el orden de conexión. Enumere los adaptadores una vez, anote la MAC del adaptador de túnel y consulte su dirección y prefijo. La MAC permanece con el adaptador virtual entre reconexiones, mientras que el nombre y el índice de interfaz no:

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

La puerta de enlace proviene de la configuración de la interfaz. Obtenga primero el índice de interfaz y lea después el siguiente salto. El índice puede cambiar tras un reinicio o un reinicio del adaptador, por eso el script debe leerlo en lugar de guardarlo:

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

Pase la salida por tr -d '\r' antes de asignarla a una variable. PowerShell termina las líneas con un retorno de carro, y sin eliminarlo el último campo lleva un carácter oculto que hace fallar un comando de ruta con un error de análisis confuso.

Aplique la dirección y la ruta dentro de la distribución

Instale la dirección del túnel como dirección con prefijo en la interfaz de la distribución y luego enrute el bloque corporativo por la puerta de enlace del 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 una dirección configurada manualmente cuando la conexión se reinicia, y ningún cliente DHCP pide un reemplazo. Ponga el método en automático para que cada reconexión refresque la dirección y luego vuelva a levantar la conexión. El método manual parece estable hasta la primera reconexión:

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

Ejecute ambos pasos desde el gancho que inicia la VPN, no desde un shell interactivo. Un script que lee la dirección, la añade, añade la ruta y registra los valores convierte una reparación manual recurrente en repetible, y el registro es lo primero que hay que leer cuando cambia el prefijo.

Fije el nombre y demuestre el camino

El núcleo puede renombrar la interfaz de la distribución entre eth1 y eth2 tras un cambio de red, y un script escrito para un nombre edita entonces el dispositivo equivocado. Una regla udev ligada a la MAC da a la interfaz una etiqueta estable:

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

Luego verifique con la dirección, la ruta y una conexión TCP real: ip -4 addr show dev vpn, ip route get 172.20.4.10 y una conexión a un puerto interno conocido. La consulta de ruta debería nombrar el dispositivo vpn y la dirección de origen que añadió.

Si las tres pruebas pasan dentro de la distribución y la conexión sigue fallando, el paquete sale de WSL y se descarta en el lado de Windows. Revise el firewall del host y el filtrado propio del cliente VPN antes de cambiar el script, porque otra edición de ruta no arreglará un paquete que ya llega al host.