VirtualBox NAT o bridge: dónde termina la VPN de la máquina virtual

Dos preguntas distintas llegan juntas cada vez que una máquina virtual ejecuta un cliente VPN, y tienen respuestas diferentes. La primera es si un túnel dentro del invitado protege al anfitrión, y la segunda es si un túnel en el anfitrión cubre al invitado. El modo de adaptador decide ambas, más que el propio software VPN. Un adaptador NAT convierte al anfitrión en el extremo visible, mientras que un adaptador puente pone al invitado en la red con su propia dirección.

Quién termina realmente la sesión cifrada

Una sesión cifrada pertenece a la máquina que la termina, y esa es el invitado cuando el cliente se ejecuta dentro de la VM. Solo el tráfico que entra en el adaptador virtual del invitado pasa por ese túnel, y el hipervisor nunca encamina otra máquina a través del invitado por su cuenta. Por eso el invitado puede mantener un túnel funcionando mientras el anfitrión navega en claro. Lo contrario no es simétrico, y esa asimetría es la parte que la mayoría de las guías equivoca.

Qué dirección ve la red exterior es la pregunta que responde el modo de adaptador. Una vez resuelto eso, la cobertura deja de ser una cuestión de política y se vuelve mecánica. Todo lo que sigue se deriva de esos dos hechos.

NAT reescribe al invitado hasta que parece el anfitrión

Con NAT, el hipervisor reescribe cada paquete del invitado a la dirección del anfitrión antes de que llegue al primer conmutador. Ese tráfico se entrega después a la pila de red del propio anfitrión, donde sigue su tabla de rutas, incluida una ruta por defecto propiedad de un túnel en el anfitrión. Un invitado NAT queda por tanto cubierto por un túnel del anfitrión sin ninguna configuración, que es lo contrario de lo que sugiere el caso de invitado a anfitrión.

# on the host: adapter mode and NAT DNS behaviour
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
VBoxManage modifyvm "lab-vm" --natdnshostresolver1 on

Un invitado que ejecuta su propio cliente termina ese túnel dentro del invitado, y el tráfico cifrado sale luego por la misma reescritura, de modo que las aplicaciones del anfitrión conservan su propio camino y su propia dirección de salida. VirtualBox también controla la resolución de nombres en este modo y retransmite las consultas del invitado por su propio motor salvo que --natdnshostresolver1 esté activado. Activarlo entrega las búsquedas del invitado al resolutor del anfitrión, lo que corrige la resolución cuando la visión propia del anfitrión es correcta e igualmente entrega un resolutor que puede existir solo dentro de un túnel. La VM debe estar apagada antes de cambiar el ajuste, y el ajuste pertenece al adaptador y no al software del invitado.

El puente da al invitado su propio arrendamiento y su propia exposición

El puente pasa las tramas del invitado al segmento físico, así que DHCP le da un arrendamiento y la red lo trata como un anfitrión separado. Cada invitado puenteado puede mantener un túnel independiente con su propia ruta por defecto, y la tabla del anfitrión nunca cambia. El precio es la exposición: el invitado responde a difusiones, aparece en tablas de vecinos y queda sujeto a la seguridad de puertos del conmutador y al aislamiento de clientes inalámbricos. Un túnel en el anfitrión tampoco cubre esta disposición, porque las tramas del invitado nunca pasan por la pila del anfitrión.

Esa diferencia respecto al caso NAT merece decirse claramente en lugar de dejarla como implicación. Un invitado puenteado necesita su propio cliente y sus propias credenciales siempre que su tráfico tenga que usar un túnel. Donde el invitado debe permanecer invisible para la red local, NAT o una red solo interna con enrutamiento controlado es el mejor diseño.

Por qué el invitado no puede ser la puerta de enlace del anfitrión

Prestar el túnel de un invitado al anfitrión no tiene ningún interruptor soportado en ninguno de los dos hipervisores principales. El anfitrión no tiene ruta hacia el túnel del invitado ni regla de traducción que apunte a él, así que el tráfico del invitado y del anfitrión siguen siendo flujos separados con dueños separados. Esa dirección falla con independencia del modo de adaptador.

Los sustitutos viables son las redirecciones y los proxys. Una redirección local SSH permite al anfitrión conectarse a su propio loopback mientras el invitado lleva el flujo al túnel, lo que cubre servicios TCP sin instalar un segundo cliente. Hacer que el propio tráfico IP del anfitrión use el túnel del invitado en su lugar requiere un encaminador dentro del invitado más una ruta explícita en el anfitrión y traducción en el anfitrión. Eso es un diseño de red pequeño y no una casilla, y necesita un plan para el camino de vuelta. Cuando el invitado existe solo para ejecutar el cliente, pon el cliente en el anfitrión y elimina el salto extra.

ssh -N -f -L 8080:internal-host.example:80 user@lab-vm

Los resolutores y las rutas no cruzan la frontera

El DNS sigue al adaptador que recibió la opción, así que un invitado no hereda el resolutor del túnel del anfitrión y un anfitrión nunca conoce el servidor empujado al invitado. Los valores dhcp-option DNS empujados se aplican a la interfaz que los aceptó, y por eso un invitado puenteado sin cliente no puede resolver nombres internos. Un invitado NAT usa normalmente el manejo de DNS del hipervisor, y la diferencia se ve en un comando por entorno.

# on the host
VBoxManage showvminfo "lab-vm" | grep -i -E "nic|nat"
# inside a Linux guest
ip -4 route
resolvectl status
# inside a Windows guest
Get-DnsClientServerAddress

Lee el resolutor y la ruta dentro del invitado antes de suponer que alguno de los dos sigue al anfitrión. Añade el resolutor del túnel al adaptador propio del invitado cuando los nombres internos deban resolverse allí, y luego verifica con un nombre que solo exista detrás del túnel. Anota el modo de adaptador, el dueño del túnel y la fuente del resolutor para cada VM, porque esos tres hechos responden casi cualquier pregunta posterior. Otros hipervisores renombran los modos y dejan el principio intacto.