WSL permite combinar las herramientas de desarrollo de Windows con un entorno Linux completo en el mismo equipo. Sin embargo, esta integración suele verse afectada cuando se utiliza una VPN corporativa, de manera que al conectarnos a ella, perdamos la conectividad con Internet en nuestra terminal WSL2.
El origen del problema está en la arquitectura de red de WSL2. La distribución de Linux se ejecuta dentro de una máquina virtual ligera que dispone de su propia interfaz de red virtualizada, y muchos clientes VPN modifican la tabla de rutas de Windows o aplican políticas de firewall que descartan el tráfico procedente de este tipo de redes virtuales.
wsl-vpnkit resuelve esta situación sin permisos de administrador ni cambios en la configuración de Windows, haciendo que el tráfico de la distribución de Linux salga a través de un proceso de Windows, de modo que la VPN lo trate como tráfico propio del equipo.
A lo largo de este artículo se describe cómo instalar wsl-vpnkit y configurarlo como un servicio de systemd, de forma que la conectividad se restablezca automáticamente cada vez que se inicia la distribución.
Este artículo está basado en la versión
v0.4.1de wsl-vpnkit, correspondiente a la release v0.4.1 publicada en el repositorio oficial del proyecto.
Cómo accede WSL2 a Internet
Por defecto, WSL2 utiliza el modo de red NAT, de forma que la máquina virtual dispone de su propia subred privada, separada de la de Windows. Las aplicaciones de la distribución de Linux utilizan la pila TCP/IP del kernel de Linux, que envía los paquetes por la interfaz eth0. Estos cruzan el bus de Hyper-V a través del switch virtual y llegan a Windows por el adaptador vEthernet (WSL). Allí, WinNAT traduce las direcciones privadas de la distribución de Linux a las del equipo y la pila TCP/IP de Windows encamina los paquetes hacia el adaptador de la VPN.
Acceso a Internet de WSL2 en modo NAT (por defecto)
Todo este recorrido transcurre en el espacio de kernel de Windows, de modo que el tráfico de WSL2 no llega desde una aplicación, sino como paquetes de red a través de una interfaz virtual. Cuando el cliente VPN modifica las rutas o aplica políticas que solo admiten el tráfico de sus propias interfaces o de determinadas aplicaciones, estos paquetes pueden quedar fuera del túnel o ser descartados.
Antes de instalar wsl-vpnkit
Las versiones recientes de WSL incluyen dos opciones nativas pensadas precisamente para mejorar la compatibilidad con VPN: mirrored networking y DNS tunneling. Conviene identificar qué parte de la conexión está fallando, ya que si estas opciones son suficientes, puede no ser necesario recurrir a wsl-vpnkit.
Diagnóstico de la conectividad
Con la VPN conectada, se ejecutan las siguientes comprobaciones desde la terminal de WSL:
1
2
3
4
5
6
7
8
# 1. Conectividad a una IP pública (sin resolución DNS)
ping -c 3 1.1.1.1
# 2. Resolución de nombres
nslookup github.com
# 3. Acceso HTTPS completo
curl -sSI https://github.com
Algunas redes corporativas bloquean el tráfico ICMP. Si
pingfalla pero se sospecha que la red funciona, puede usarsecurl -sSI https://1.1.1.1como alternativa para comprobar la conectividad por IP.
El resultado de estas pruebas permite identificar el tipo de problema:
| Conectividad IP | Resolución DNS | Acceso HTTPS | Diagnóstico |
|---|---|---|---|
| OK | OK | ERROR | Proxy corporativo |
| OK | ERROR | ERROR | Problema de DNS |
| ERROR | ERROR | ERROR | Problema de enrutamiento |
Solución nativa de WSL2
La guía de Microsoft para configurar WSL en entornos empresariales recomienda ajustar las opciones de red avanzadas de la sección [wsl2] del fichero %UserProfile%\.wslconfig, que puede crearse manualmente si no existe. Estas opciones requieren Windows 11 22H2 o superior y WSL 2.0.9 o posterior, lo que puede comprobarse con wsl --version. En entornos corporativos con VPN, lo habitual es activar conjuntamente las tres opciones siguientes, independientemente del resultado del diagnóstico:
1
2
3
4
[wsl2]
networkingMode=mirrored
dnsTunneling=true
autoProxy=true
networkingMode=mirrored: replica las interfaces de red de Windows en Linux, lo que mejora la compatibilidad en entornos de red complejos.dnsTunneling=true: obtiene la información DNS mediante funciones de virtualización en lugar de paquetes de red.autoProxy=true: aplica automáticamente en WSL el proxy HTTP configurado en Windows.
Con el modo mirrored, el esquema de red cambia respecto al modo NAT, de manera que desaparece el adaptador vEthernet (WSL) y la traducción de direcciones de WinNAT, y Linux pasa a ver réplicas de las interfaces de Windows con sus mismas direcciones IP. Los paquetes siguen cruzando el bus de Hyper-V, pero se entregan directamente a la pila TCP/IP de Windows.
Acceso a Internet de WSL2 en modo mirrored
Para aplicar los cambios es necesario reiniciar WSL y, a continuación, repetir las comprobaciones del diagnóstico:
1
wsl --shutdown
Los errores de certificado con conectividad y DNS correctos suelen deberse a la inspección TLS corporativa. No se resuelven con
.wslconfig, sino importando el certificado raíz corporativo en la distribución.
Cuando la solución nativa no es suficiente
Las opciones de .wslconfig mejoran la compatibilidad de WSL2 con las VPN, pero, como muestran los diagramas anteriores, no cambian un aspecto fundamental de su arquitectura: tanto en modo NAT como en modo mirrored, el tráfico de la máquina virtual sale por una tarjeta de red virtual de Hyper-V y llega a la pila de red de Windows a nivel de kernel, sin pasar por ningún proceso en espacio de usuario. Muchos clientes VPN y soluciones de seguridad aplican sus reglas en capas de la pila de red por las que ese tráfico no pasa, o lo identifican como procedente de una interfaz ajena al equipo en lugar de un proceso local.
Cómo lo resuelve wsl-vpnkit
wsl-vpnkit evita por completo el adaptador de red virtual de WSL2. En su lugar, se apoya en dos componentes de gvisor-tap-vsock:
wsl-vm: se trata del componentegvforwarder, renombrado para wsl-vpnkit. Se ejecuta dentro de la distribución de Linux y reenvía los paquetes de la interfaz TAP hacia el proceso de Windows. El scriptwsl-vpnkitconfigura esa interfaz, la ruta por defecto y la redirección de DNS.wsl-gvproxy.exe: se trata del componentegvproxy, renombrado para wsl-vpnkit. Implementa una pila TCP/IP en el espacio de usuario de Windows, recibe los paquetes de la distribución de Linux y abre las conexiones correspondientes como sockets normales de Windows.
La clave está en cómo se comunican ambos componentes, esto es, no lo hacen a través de la red virtual, sino mediante la entrada y salida estándar del proceso wsl-gvproxy.exe, que la distribución de Linux lanza gracias a la interoperabilidad de WSL con los ejecutables de Windows y que viaja por un canal vSock del bus de Hyper-V. Así, para la VPN y el firewall, las conexiones de WSL2 son indistinguibles de las de cualquier otra aplicación de Windows, y se encaminan por el túnel sometidas a las mismas políticas que el resto del tráfico del equipo.
Acceso a Internet de WSL2 mediante wsl-vpnkit
A diferencia de los dos esquemas anteriores, en éste el tráfico no entra en Windows como paquetes de red a través de una interfaz, sino desde espacio de usuario a través de wsl-gvproxy.exe. Este enfoque tiene además otras ventajas: no requiere permisos de administrador, no modifica la configuración de Windows y funciona con independencia del cliente VPN utilizado.
wsl-vpnkit sólo restablece la conectividad de red, es decir, el proxy y los certificados corporativos, en caso de ser necesarios, deben configurarse por separado en la distribución de Linux.
Si se ha probado anteriormente el modo mirrored sin éxito, conviene eliminar
networkingMode=mirroredde.wslconfigy ejecutarwsl --shutdownantes de instalar wsl-vpnkit, ya que está diseñado para el modo de red NAT por defecto de WSL2.
Instalación de wsl-vpnkit como servicio de systemd
wsl-vpnkit puede instalarse de dos formas: como una distribución de WSL independiente o como un script dentro de una distribución de Linux ya existente. En este artículo se utiliza la segunda opción, delegando su ejecución en systemd para que se inicie automáticamente con la distribución. Los comandos están pensados para Ubuntu y Debian.
La instalación requiere acceso a Internet desde WSL para instalar paquetes y descargar wsl-vpnkit. Si la VPN bloquea la conexión, puede desconectarse temporalmente durante estos pasos o descargar el fichero
wsl-vpnkit.tar.gzdesde Windows y copiarlo hacia\\wsl.localhost\<distribution>\home\<user>.
Habilitar systemd en la distribución de Linux
WSL admite systemd de forma oficial desde la versión 0.67.6, pero que la versión de WSL lo soporte no implica que esté habilitado en cada distribución. Para comprobarlo, basta con consultar el nombre del proceso con PID 1:
1
ps -p 1 -o comm=
Si el resultado es systemd, está habilitado y puede pasarse al siguiente paso. En caso contrario, se habilita añadiendo lo siguiente al fichero /etc/wsl.conf de la distribución:
1
2
[boot]
systemd=true
A continuación, se reinicia WSL desde PowerShell y se vuelve a abrir la distribución:
1
wsl --shutdown
Tras el reinicio, systemctl status debería responder correctamente.
Instalar las dependencias
El script de wsl-vpnkit necesita varias utilidades de red: iproute2 e iptables para configurar la interfaz TAP, las rutas y la redirección de DNS, y iputils-ping, dnsutils y wget para las comprobaciones de conectividad que ejecuta al arrancar.
1
2
sudo apt update
sudo apt install -y iproute2 iptables iputils-ping dnsutils wget
Descargar wsl-vpnkit
Se crea el directorio de instalación y se descarga la release correspondiente:
1
2
3
4
5
sudo mkdir -p /opt/wsl-vpnkit
cd /opt/wsl-vpnkit
VERSION=v0.4.1
sudo wget https://github.com/sakai135/wsl-vpnkit/releases/download/$VERSION/wsl-vpnkit.tar.gz
El paquete contiene una distribución completa, pero para la instalación como script solo son necesarios cuatro ficheros: el script wsl-vpnkit, los binarios wsl-vm y wsl-gvproxy.exe, y la plantilla del servicio wsl-vpnkit.service. Se extraen únicamente estos y se elimina el paquete:
1
2
3
4
5
6
7
sudo tar --strip-components=1 -xf wsl-vpnkit.tar.gz \
app/wsl-vpnkit \
app/wsl-gvproxy.exe \
app/wsl-vm \
app/wsl-vpnkit.service
sudo rm wsl-vpnkit.tar.gz
Configurar el servicio
La plantilla wsl-vpnkit.service incluida en la release está preparada para la instalación como distribución, con las líneas correspondientes a la instalación como script comentadas. El siguiente comando comenta la primera variante, activa la segunda y ajusta las rutas a /opt/wsl-vpnkit:
1
2
3
4
5
6
7
sudo sed -i \
-e 's|^ExecStart=/mnt/c/Windows/system32/wsl.exe.*|#&|' \
-e 's|^#ExecStart=/full/path/to/wsl-vpnkit|ExecStart=/opt/wsl-vpnkit/wsl-vpnkit|' \
-e 's|^#Environment=.*|Environment=VMEXEC_PATH=/opt/wsl-vpnkit/wsl-vm GVPROXY_PATH=/opt/wsl-vpnkit/wsl-gvproxy.exe|' \
wsl-vpnkit.service
sudo cp /opt/wsl-vpnkit/wsl-vpnkit.service /etc/systemd/system/wsl-vpnkit.service
El fichero resultante, que puede consultarse con cat /etc/systemd/system/wsl-vpnkit.service, debería quedar así:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[Unit]
Description=wsl-vpnkit
After=network.target
[Service]
# for wsl-vpnkit setup as a distro
#ExecStart=/mnt/c/Windows/system32/wsl.exe -d wsl-vpnkit --cd /app wsl-vpnkit
# for wsl-vpnkit setup as a standalone script
ExecStart=/opt/wsl-vpnkit/wsl-vpnkit
Environment=VMEXEC_PATH=/opt/wsl-vpnkit/wsl-vm GVPROXY_PATH=/opt/wsl-vpnkit/wsl-gvproxy.exe
Restart=always
KillMode=mixed
[Install]
WantedBy=multi-user.target
Las variables VMEXEC_PATH y GVPROXY_PATH indican al script dónde encontrar los binarios, ya que por defecto los busca en /app, la ruta que utiliza la instalación como distribución. Restart=always hace que systemd relance el servicio si se detiene, y KillMode=mixed permite que el script restaure la configuración de red original de WSL2 al pararse.
Activar el servicio
Por último, se recarga la configuración de systemd y se habilita el servicio para que arranque con la distribución de Linux, iniciándolo en ese mismo momento:
1
2
sudo systemctl daemon-reload
sudo systemctl enable --now wsl-vpnkit
Verificación
El estado del servicio debe aparecer como active (running):
1
systemctl status wsl-vpnkit
Al arrancar, el script ejecuta una serie de comprobaciones de conectividad cuyo resultado queda registrado en el journal del servicio:
1
journalctl -u wsl-vpnkit -b | grep check
Además, la ruta por defecto de la distribución de Linux debe apuntar ahora a la puerta de enlace de wsl-vpnkit (192.168.127.1) a través de la interfaz TAP:
1
ip route show default
Con la VPN conectada, basta con repetir las pruebas del diagnóstico inicial para confirmar que la conectividad se ha restablecido:
1
2
3
ping -c 3 1.1.1.1
nslookup github.com
curl -sSI https://github.com
Conclusión
La pérdida de conectividad de WSL2 al conectarse a una VPN corporativa se debe a la propia arquitectura de red de WSL2, esto es, su tráfico llega a Windows como paquetes de red a través de una interfaz virtual, de modo que muchos clientes VPN no lo tratan como tráfico propio del equipo. Por ello, el primer paso es diagnosticar qué parte de la conexión falla y probar las opciones nativas de WSL, mirrored networking, DNS tunneling y autoProxy, que en muchos entornos son suficientes y no requieren software adicional.
Cuando estas opciones no bastan, wsl-vpnkit ofrece una alternativa al trasladar el tráfico a un proceso de Windows en espacio de usuario, consiguendo así que la VPN y el firewall lo traten igual que el de cualquier otra aplicación del equipo, sin permisos de administrador ni cambios en la configuración de Windows. Instalado como servicio de systemd, la conectividad se restablece automáticamente cada vez que se inicia la distribución, de forma transparente y práctica para el día a día.
