WSL2 no hereda la VPN corporativa, y ese es el error

La wiki interna carga en Edge, mientras que git clone dentro de la distribución agota el tiempo. Esa única observación suele leerse como «la VPN bloquea WSL2», y la hora siguiente se va en editar /etc/resolv.conf. La lectura más útil es que WSL2 nunca tuvo la ruta de red del host: se ejecuta en una VM auxiliar con su propio adaptador, sus propias rutas y un archivo de resolver que Windows genera para ella. Todo lo que sigue depende de cuál de esos tres le falta en realidad.

La VM tiene su propia pila, métrica y resolver

En el modo NAT predeterminado, la distribución está detrás de un conmutador virtual y llega a internet a través del host, pero no ve los adaptadores del host. ip addr muestra una interfaz con una dirección privada, ip route muestra una ruta predeterminada a través de ese conmutador, y /etc/resolv.conf es un archivo generado que apunta a un stub resolver que eligió Windows. Nada de eso cambia porque un cliente VPN se haya iniciado en el lado de Windows.

Por eso «el navegador funciona» demuestra tan poco. El navegador usa la pila del host, el túnel y la política de resolver del host. Su shell usa otra pila que casualmente comparte una tarjeta de red física. Coinciden en el caso feliz y divergen exactamente cuando la VPN instala un filtro, reescribe la lista de DNS o agrega una ruta para la subred del conmutador virtual.

Dos pruebas deciden en qué mundo está, y deben ejecutarse dentro de la distribución:

getent hosts example.com
curl -sS -m 8 -o /dev/null -w "%{http_code}\n" 1.1.1.1
ip route
cat /etc/resolv.conf

Que los nombres fallen mientras una dirección literal responde es un problema de resolver. Que nombres y direcciones fallen juntos es un problema de ruta, y ninguna cantidad de edición del resolver lo tocará. La evidencia del lado de Windows viene después: Get-NetAdapter | Get-DnsClientServerAddress y route print -4 muestran si el túnel se quedó con la subred donde vive su VM.

Mito uno: los servidores DNS corporativos lo arreglan

Editar el archivo de resolver es el consejo clásico, y acierta aproximadamente la mitad de las veces. Cuando acierta, es por un motivo concreto: el archivo generado apunta a un resolver que solo conoce nombres públicos, así que una consulta para intranet.example.internal vuelve como inexistente aunque la ruta esté bien.

Fijar los servidores de la VPN significa impedir que Windows regenere el archivo, porque cualquier archivo que escriba a mano se reemplaza en el siguiente arranque:

[network]
generateResolvConf = false

Guarde eso como /etc/wsl.conf, ejecute wsl --shutdown desde Windows, luego arranque la distribución y escriba /etc/resolv.conf con los servidores del túnel primero y un resolver público solo como respaldo. Es un cambio duradero con un costo de mantenimiento: el archivo ya no sigue al host, así que cuando cambian las direcciones DNS corporativas la distribución sigue preguntando por las antiguas. Alguien tiene que ser dueño de ese archivo.

Tampoco hace nada cuando el fallo es más amplio. Si curl hacia 1.1.1.1 agota el tiempo, el cliente del túnel está filtrando el conmutador virtual o encaminando la subred de la VM al túnel, y un resolver correcto solo le da nombres que aún no se pueden alcanzar.

Mito dos: el cambio de métrica se mantiene

Cuando los nombres se resuelven pero el tráfico sale por el adaptador físico, la palanca son las métricas de interfaz. Dé al adaptador de la VPN un costo alto y al conmutador WSL uno bajo:

Get-NetAdapter | Where-Object InterfaceDescription -Match "AnyConnect" | Set-NetIPInterface -InterfaceMetric 4000
Get-NetIPInterface -InterfaceAlias "vEthernet (WSL)" | Set-NetIPInterface -InterfaceMetric 1

Luego recuerde que en muchas compilaciones del cliente el adaptador del túnel se recrea en cada conexión y la métrica vuelve a su valor predeterminado. Un comando puntual es una corrección que caduca en silencio, normalmente durante un fin de semana, y el ticket vuelve con «la semana pasada funcionaba». Una tarea programada activada por el evento de la VPN, o un script que el usuario ejecuta tras conectarse, es la versión honesta de esta reparación.

La misma caducidad se aplica a las rutas de host añadidas para un prefijo terco. Valen la pena como diagnóstico, porque le dicen si el problema es un destino o toda la ruta, pero no son una arquitectura.

Mito tres: una corrección cubre cada compilación de Windows

wsl-vpnkit es el patrón sidecar: una distribución pequeña posee la ruta del lado del host y reenvía para otras distribuciones a través de un socket virtual, de modo que el tráfico de las aplicaciones deja de depender del conmutador filtrado. Necesita que la ruta estándar funcione, lo que significa quitar las anulaciones networkingMode y dnsTunneling de %UserProfile%\.wslconfig, restaurar generateResolvConf = true en cada distribución que funcione e iniciar el servicio al iniciar sesión.

El modo reflejado es la alternativa integrada en Windows 11 22H2 y posteriores, y es un ajuste más un apagado:

[wsl2]
networkingMode=mirrored

Dentro de la distribución ip addr entonces enumera los adaptadores del host, el túnel puede aparecer entre ellos, y el túnel de DNS reenvía las consultas a través del resolver de Windows incluso cuando el cliente reescribe la lista de DNS. No es universal: algunos controladores de filtro siguen descartando la ruta reflejada, y las reglas de firewall de Hyper-V pueden necesitar un permiso explícito. La guía de redes de WSL de Microsoft es la página que debe contrastar con su compilación antes de aplicar una receta escrita para una más nueva.

Pruebe tres cosas tras cada cambio

Elija un mecanismo por máquina y anótelo, porque los dos se combinan mal. Un sidecar sobre el modo reflejado duplica el reenvío, y un host reflejado con una entrada de sidecar obsoleta en .wslconfig tiende a fallar después de una actualización, no antes.

Elija lo que elija, la prueba de aceptación son las mismas tres peticiones dentro de la distribución: un nombre interno, un nombre público y una dirección cruda. Luego repítalas tras desconectar y reconectar el túnel, y tras wsl --shutdown. Que solo falle el nombre interno significa política de resolver; que fallen juntos el nombre interno y el público con una dirección que funciona sigue significando política de resolver; que falle todo significa la ruta.

Si falla un host interno mientras el resto funciona, deje de mirar el resolver y busque una ruta que falte para ese prefijo. Si todo funciona hasta la siguiente reconexión, ha encontrado una corrección que depende del estado en tiempo de ejecución, y debe reaplicarse automáticamente o sustituirse por uno de los dos mecanismos anteriores.