¿Ejecutar la VPN en el host o dentro de la VM? Guía de decisión

Construir el túnel dentro del invitado y construirlo en el host cambian ambos la dirección que informa un navegador, y ahí termina el parecido. Un túnel propiedad del invitado guarda sus claves, su ruta predeterminada y su resolutor dentro del núcleo del invitado, mientras que el host reenvía paquetes cifrados a una única dirección remota. Un túnel propiedad del host es la imagen especular: el cliente del host mantiene la sesión y aplica rutas y política, y el invitado toma prestado lo que sale. Elija al propietario equivocado y cada síntoma posterior lo enviará a la máquina equivocada. Dos comandos resuelven la cuestión en aproximadamente un minuto, y el resto de esta guía es qué hacer con la respuesta.

Decida el propietario antes de tocar el cliente

La regla trata de dónde se produce el texto cifrado, no de qué máquina muestra un icono de VPN. Si lo produce el invitado, el invitado necesita una ruta funcional al servidor VPN y nada más del host. Si lo produce el host, el invitado necesita que el camino por el host sobreviva a cualquier política que el cliente del host imponga al tráfico local.

Tres preguntas suelen elegir la ubicación por usted. ¿Debe el tráfico del invitado sobrevivir a un cliente corporativo en el host? Entonces el túnel va dentro del invitado. ¿Necesitan varios invitados una sola credencial y una sola dirección de salida? Entonces va en el host, con el reenvío configurado a propósito. ¿Debe el tráfico del invitado quedarse totalmente fuera de la VPN del host? Entonces un túnel en el invitado es la única disposición que se lo da por construcción.

Anote la respuesta en una línea junto al nombre de la VM: guest-owned o host-owned. En un laboratorio de seis máquinas esa nota ahorra más tiempo que cualquier paso de abajo, porque le impide diagnosticar un túnel que nunca estuvo en la máquina en la que ha iniciado sesión.

WSL1 y WSL2 son casos opuestos

WSL1 no es una máquina virtual, así que la cuestión de la ubicación se evapora en su mayor parte. Sus binarios de Linux se ejecutan contra la pila de red de Windows a través de una capa de traducción, y un cliente VPN de Linux no tiene interfaces independientes que configurar. La disposición que funciona es un túnel del lado de Windows, con la distribución usando el resultado sin poseer nada.

WSL2 es lo contrario. Ejecuta un núcleo real en una VM auxiliar ligera detrás de un conmutador virtual de Hyper-V, y su espacio de direcciones se traduce por NAT mediante un adaptador del lado del host. Por eso un cliente de Linux dentro de la distribución se comporta como en una máquina Linux física: crea tun0 o wg0, instala sus propias rutas y funciona. El fallo vive en el lado del host. Cuando un cliente VPN de Windows se conecta con una política que bloquea el tráfico en las redes locales, trata la subred WSL2 como una red local no fiable y corta el camino NAT. Entonces la distribución pierde DNS y acceso de salida mientras su propio túnel sigue sano: wg show informa de un handshake, ip route parece correcto y curl se cuelga.

Qué corrección puede usar depende de la compilación de Windows. La más antigua es una excepción en el cliente del host para la subred WSL, añadida en los ajustes de red local o de túnel dividido del cliente. La más nueva, en compilaciones de Windows 11 que la admiten, es la red reflejada: ponga networkingMode=mirrored en la sección [wsl2] de %UserProfile%\.wslconfig, ejecute wsl --shutdown, y la distribución compartirá las interfaces del host en lugar de una subred NAT privada. El modo reflejado también cambia el comportamiento de localhost y de los puertos entrantes, así que trátelo como una migración y no como un interruptor.

NAT, puente y qué puede ver el host

Bajo NAT, los paquetes del túnel del invitado se dirigen a la dirección pública del servidor VPN y salen por el adaptador del host como UDP o TCP cifrado. El host ve un solo flujo y su recuento de bytes, nada sobre los destinos que hay dentro. Bajo un adaptador en puente, el invitado tiene su propia identidad de capa 2 en la LAN física, toma su propio arrendamiento DHCP y parece ante cualquier política basada en MAC un segundo dispositivo. Ninguno de los dos modos deja que el host lea la carga del túnel; el invitado en puente es simplemente mucho más visible para la red que lo rodea.

También hay un suelo para el aislamiento. Un invitado no puede esconderse de la máquina que posee su memoria, y quien controla el host puede leer claves de la RAM del invitado. Lo que le da un túnel en el invitado es una frontera de enrutamiento y una frontera de malware, no protección frente a la persona que sostiene el portátil. Merece la pena tener abiertos los modos de adaptador documentados mientras elige, ya que el modo cambia tanto lo que ve el host como lo que ve la LAN.

Guía: ubíquelo, configúrelo, demuéstrelo

Ejecute estas cuatro comprobaciones en orden en un shell de invitado nuevo, y deténgase en la primera que no concuerde con el propietario que anotó.

1. ip route get 1.1.1.1 que devuelve tun0 o wg0 significa propiedad del invitado, y eth0 con un siguiente salto privado significa propiedad del host.
2. resolvectl query example.com, o lea /etc/resolv.conf donde el invitado no ejecuta ningún servicio resolutor. Un túnel que transporta tráfico pero no DNS es el estado a medio configurar más habitual.
3. Compare las salidas: curl -4 -s https://ifconfig.me en el invitado frente a curl.exe -4 -s https://ifconfig.me en el host. Direcciones distintas significan que el invitado posee el túnel, y un host en la VPN con un invitado que muestra el proveedor de casa es el caso en que no se heredó nada.
4. Repita ambos con -6. Un túnel solo de v4 filtra v6 a menos que el cliente lo bloquee o lo enrute, y muchos clientes dejan v6 en la interfaz física por defecto.

Para un diseño de puerta de enlace en el host, donde varios invitados comparten un túnel, el host tiene que reenviar y traducir. En un host Linux son tres piezas, y el invitado vuelve en silencio a su ruta simple cuando falta cualquiera de ellas:

sysctl -w net.ipv4.ip_forward=1
iptables -t nat -A POSTROUTING -o wg0 -j MASQUERADE
iptables -A FORWARD -i virbr0 -o wg0 -j ACCEPT
iptables -A FORWARD -i wg0 -o virbr0 -m state --state RELATED,ESTABLISHED -j ACCEPT

En el lado de WireGuard, la AllowedIPs del par del host debe incluir la subred de los invitados, por ejemplo 192.168.122.0/24, o los paquetes de vuelta nunca llegan y la configuración parece un problema de cortafuegos. Un host Windows logra el mismo resultado con Conexión compartida a Internet o una regla NAT en el conmutador Hyper-V, y necesita la misma comprobación del camino de vuelta.

Cuando el diseño sigue abierto, esta tabla cubre las disposiciones más frecuentes:

Dos túneles, dos invitados y los conflictos entre ellos

Cuando necesita dos salidas a la vez, el patrón que aguanta es un túnel por invitado. Cada VM mantiene su propia ruta predeterminada y su resolutor, el host se queda en la red ordinaria, y los dos túneles nunca discuten por la misma tabla de enrutamiento. Puentear dos invitados tampoco une sus rutas: la red virtual proporciona un camino, y a cada cliente todavía hay que decirle que este tráfico local puede saltarse el túnel.

Ejecutar un túnel del host y uno del invitado a la vez es legítimo, y el anidamiento deliberado a veces es exactamente lo que quiere, con el invitado saliendo por su propio túnel y ese túnel saliendo por el del host. Lo que lo convierte en una caída es que nadie anotó qué extremo debe alcanzarse por qué capa. Mantenga una lista de dos columnas con destino y propietario, y un conflicto de rutas se convierte en una consulta en lugar de una tarde de descubrimiento.

Verifique, y luego deje la recuperación al propietario

Pruebe desde dentro del invitado con un proceso de aplicación nuevo: tráfico, resolución de nombres, ambas familias de direcciones y qué ocurre cuando el túnel cae. El icono de VPN del host no dice nada sobre la cobertura del invitado, y esa es la confirmación falsa más habitual en toda esta área.

La recuperación también pertenece al propietario. Un túnel propiedad del invitado se restaura con el cliente propio del invitado y las rutas que escribió. Un diseño propiedad del host se restaura con la secuencia de arranque del host, y las reglas de reenvío no sobreviven a un reinicio a menos que una unidad o una tarea de inicio las vuelva a aplicar. Una instantánea restaurada es un despliegue, no un deshacer, porque devuelve credenciales viejas y rutas viejas junto con el disco. Antes de dar el trabajo por terminado, confirme que el propietario sigue coincidiendo con la línea que anotó, que DNS y ambas familias de direcciones se resuelven dentro del invitado, que un túnel muerto deja una red utilizable en lugar de un agujero negro, y que un reinicio o una restauración de instantánea reproduce el mismo estado.