Enrutar el tráfico del host por una VPN en una VM: seis comprobaciones

Seis comprobaciones, ejecutadas en orden, deciden si una VM puede actuar como puerta de enlace VPN para su propio host. El hipervisor no hace nada de esto por ti: el invitado posee el túnel, el host posee una ruta, y la red entre ambos es enrutamiento corriente. Mantengo la lista porque saltarse un paso siempre produce el mismo síntoma, silencio, cuando el host hace ping al invitado sin problemas y no llega a nada interno.

Empieza por el motivo. O el cliente corporativo solo se instala dentro del invitado, o la política lo mantiene allí, y sigues necesitando el servidor de compilación interno desde el host. Si el host puede tener su propio cliente, haz eso en su lugar: un túnel en el host gana siempre a dos redes más un NAT.

Comprobación 1: el host necesita un enlace al que pueda asignar dirección

El host debe tener una interfaz en el mismo prefijo que el segundo adaptador del invitado. Host-only en VirtualBox, host-only o un VMnet personalizado en VMware Workstation, un puente interno o dispositivo tap en QEMU/KVM y un conmutador Internal en Hyper-V cumplen todos. Invitado 192.168.56.2, host 192.168.56.1, prefijo 192.168.56.0/24 es la disposición que uso en laboratorios.

La red QEMU en modo usuario (-netdev user, el backend SLIRP por defecto) y el NAT de VirtualBox fallan esta comprobación de plano. Los paquetes del invitado llegan a un proceso proxy en el host, así que el host nunca ve un dispositivo que lleve las direcciones del invitado y no tiene a qué apuntar una ruta. El Default Switch de Hyper-V es la misma historia. Si ping 192.168.56.2 desde el host falla, detente: ninguna ruta añadida después lo arreglará.

Comprobación 2: el invitado reenvía y traduce

Los paquetes del host llegan con una dirección de origen de la red host-only y un destino interno, así que el invitado debe reenviarlos y luego esconderlos tras la dirección de su túnel. En un invitado Linux eso significa reenvío, un par FORWARD accept y source NAT hacia el túnel:

sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -A FORWARD -i eth1 -o tun0 -j ACCEPT
sudo iptables -A FORWARD -i tun0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
sudo iptables -t nat -A POSTROUTING -s 192.168.56.0/24 -o tun0 -j MASQUERADE

La regla MASQUERADE es la parte que la gente omite. Los routers corporativos rara vez saben que 192.168.56.0/24 existe; con la regla, los servidores internos ven la dirección del túnel del invitado y responden a ella, y la respuesta encuentra el camino de vuelta al invitado.

Un invitado Windows es más torpe. IPEnableRouter=1 bajo SYSTEM\CurrentControlSet\Services\Tcpip\Parameters activa el reenvío sin traducción, así que solo funciona donde el enrutamiento corporativo ya apunta de vuelta a tu prefijo host-only. El uso compartido de conexión a Internet sí traduce, pero renumera el adaptador compartido a 192.168.137.1, así que lee la dirección que realmente tomó antes de escribir rutas del host.

Comprobación 3: las rutas del host nombran al invitado, no al túnel

Envía por el invitado solo los prefijos que el host necesita. En Linux basta una ruta por prefijo y se revierte limpiamente:

sudo ip route add 10.20.0.0/16 via 192.168.56.2
ip route get 10.20.30.40

En Windows el equivalente es route add 10.20.0.0 mask 255.255.0.0 192.168.56.2. Deja fuera -p mientras sigues probando, para que una ruta mala muera al reiniciar, y añádelo cuando el camino funcione. No elimines la ruta por defecto del host salvo que todas las aplicaciones del host deban usar el túnel; si el túnel completo es de verdad el requisito, añade las dos rutas /1 y conserva la ruta directa a la red del hipervisor:

sudo ip route add 0.0.0.0/1 via 192.168.56.2
sudo ip route add 128.0.0.0/1 via 192.168.56.2

En un host Windows, revisa también la métrica de la interfaz. Una ruta añadida mientras el adaptador host-only estaba deshabilitado se queda en la tabla pero nunca transporta tráfico, y un segundo adaptador con métrica más baja puede ganar la búsqueda para el mismo prefijo.

Comprobación 4: el DNS sigue la ruta, no el defecto del túnel

Las rutas mueven paquetes; el resolutor decide qué nombres producen paquetes. Limita el resolutor corporativo a la zona corporativa en lugar de sustituir el resolutor del host, y apúntalo a un servidor DNS que la nueva ruta ya alcanza. Con systemd-resolved en el host:

resolvectl dns eth1 10.20.0.53
resolvectl domain eth1 '~corp.example.com'

En Windows, una entrada en la tabla de directivas de resolución de nombres hace el mismo trabajo: Add-DnsClientNrptRule -Namespace ".corp.example.com" -NameServers 10.20.0.53. Si el invitado ejecuta su propio resolutor en la dirección host-only, usa esa dirección en su lugar, pero solo después de confirmar que responde en 192.168.56.2 y no en loopback.

Luego revisa la MTU antes de culpar al DNS de páginas lentas. La interfaz del túnel es menor que la interfaz de 1500 bytes del host, así que un host que envía segmentos de tamaño completo con el bit DF activado los ve caer en algún punto dentro del invitado. El síntoma clásico es un ping que funciona y una aplicación web interna que se atasca tras el saludo TLS. Aprieta la MSS en la ruta de reenvío del invitado:

sudo iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

Comprobación 5: verifica desde ambos extremos

Desde el host, traceroute o tracert hacia una dirección interna debería mostrar 192.168.56.2 como primer salto, no la puerta de enlace física. En el invitado, observa cómo sale el mismo intento: tcpdump -ni any host 10.20.30.40 muestra la petición reenviada en el lado host-only y la traducida en el túnel. Una petición que sale, vuelve y aun así deja mudo al host apunta al camino de vuelta.

Dos fallos explican la mayor parte de eso. O el túnel del invitado no lleva ruta de vuelta para el prefijo host-only porque falta la regla NAT, o la ruta del host apunta a una dirección que el invitado ya no tiene tras un reinicio. Vuelve a leer las direcciones con ip -br addr y ip route get en lugar de fiarte de notas de la sesión anterior.

Comprobación 6: haz que sobreviva a un reinicio y a una actualización del hipervisor

Persiste las dos mitades: configuración de rutas con netplan o NetworkManager en el host, route add ... -p en Windows, y net.ipv4.ip_forward=1 dentro de /etc/sysctl.d/ más un conjunto de reglas de cortafuegos que se recargue en el invitado. Haz una instantánea del invitado en cuanto se verifique la configuración, antes de que llegue la siguiente actualización del cliente corporativo.

Las redes host-only se renumeran cuando el hipervisor recrea sus adaptadores, lo que invalida en silencio cada ruta y regla NAT construida sobre 192.168.56.0/24. Tras una actualización, vuelve a ejecutar las tres primeras comprobaciones en orden; cuesta un minuto y atrapa el caso en que el host aún tiene su ruta mientras el invitado se ha movido a una subred nueva.

IPv6 necesita su propia pasada. Las reglas de ip6tables, los registros AAAA y una segunda familia de rutas del host no siguen la configuración IPv4, y un servicio corporativo accesible por IPv6 parecerá permanentemente roto mientras IPv4 funciona.

Pase o falle, en orden: el host puede hacer ping a la dirección host-only del invitado; el invitado reenvía y hace MASQUERADE hacia el túnel; ip route get devuelve el invitado como puerta de enlace para el prefijo interno; los nombres corporativos se resuelven por el resolutor limitado; traceroute muestra el invitado primero; y las mismas seis respuestas sobreviven a un reinicio.