NAT frente a red de VM en modo puente: ¿cuál transporta el tráfico VPN?
Los invitados NAT toman prestado el túnel del host solo si el cliente tuneliza por ruta; los invitados en puente enrutan por sí mismos. Prueba el invitado y luego elige el modo que corresponda.
El modo puente y NAT no son dos formas de conectar el mismo invitado a tu VPN; deciden quién es dueño de los paquetes del invitado antes de que haya un túnel de por medio. En modo NAT el hipervisor reescribe el tráfico del invitado y lo emite desde código del lado del host, así que el invitado va por la ruta que el host le dé a ese código. En modo puente el invitado obtiene su propia identidad de capa de enlace en el segmento físico y elige su propia puerta de enlace predeterminada, lo que hace que el túnel del host le resulte irrelevante, salvo que el router de la LAN sea el que tuneliza. Dejé de tratar la VM como si estuviera en la VPN y empecé a tratarla como una pregunta sobre hacia dónde apunta la ruta predeterminada de ese invitado. La prueba de abajo tarda unos minutos por modo y lo resuelve sin conjeturas.
NAT mantiene al invitado detrás del código del hipervisor, donde rigen las rutas del host
En VirtualBox un invitado NAT está en 10.0.2.0/24 con una puerta de enlace virtual en 10.0.2.2, un proxy DNS en 10.0.2.3 y ninguna ruta propia hacia la red física. Los paquetes salientes los toma el motor NAT, se reescriben para que el origen sea el host y se pasan a la pila IP del host. A partir de ahí el tráfico del invitado es un flujo del host, y la búsqueda de ruta es por destino: un cliente de túnel completo que instala 0.0.0.0/1 y 128.0.0.0/1 en el host lo captura sin saber siquiera que existe una VM. El capítulo de Oracle sobre redes de VirtualBox enumera estos valores por defecto si quieres confirmar las direcciones en tu compilación.
La red predeterminada de libvirt llega al mismo sitio desde 192.168.122.0/24, donde dnsmasq reparte concesiones y el host hace masquerade de la subred, así que los paquetes del invitado vuelven a llegar a la decisión de enrutamiento del host. La excepción es un cliente que elige el tráfico por proceso en lugar de por ruta. Si la lista de túnel dividido contiene tu navegador y nada más, el motor NAT no está en esa lista, y el invitado sale de la máquina sin túnel mientras el navegador del host sigue pareciendo cubierto. Misma subred, resultado opuesto.
El puente le da al invitado su propio sitio en la LAN física
A un invitado en puente se le da una NIC virtual conectada a un adaptador real, recibe su propia dirección MAC y toma una concesión DHCP de la red física. Su puerta de enlace predeterminada es el router de la LAN, no el hipervisor, y sus tramas salen al cable por ese adaptador. Las rutas del túnel del host viven en la tabla del host y nunca se consultan, porque las tramas del invitado nunca entran en la pila IP del host.
Eso corta en ambos sentidos. mDNS y la exploración SMB empiezan a funcionar porque el invitado ve el tráfico de difusión de la LAN, y el invitado se vuelve accesible desde otras máquinas del mismo segmento sin un cortafuegos del host en medio. El puente tampoco es una forma de empujar un invitado por un túnel existente: conectar una VM a la interfaz WireGuard u OpenVPN del host no es algo que VirtualBox o libvirt hagan por ti. Si un invitado en puente tiene que ir por un túnel, el túnel debe terminar en algún punto de esa LAN.
La prueba que zanja la discusión
Ejecuta las mismas comprobaciones en ambos modos y anota las respuestas:
- En el host,
curl -s https://ifconfig.meda la dirección v4 pública. - En el invitado, el mismo comando, más
ip routeen Linux oGet-NetRoute -DestinationPrefix 0.0.0.0/0en Windows para la puerta de enlace predeterminada. - Identidad del resolutor:
resolvectl statusocat /etc/resolv.confen el invitado, para ver si apunta a 10.0.2.3 o a un servidor de la LAN. - Familia de direcciones:
ip -6 addr show scope globaly una petición v6, porque un túnel v4 no dice nada sobre una dirección v6 global que el invitado pueda tener.
Direcciones públicas coincidentes significan que el invitado está en la ruta del host. Una dirección de invitado que coincide con la salida habitual de la LAN significa que no lo está. El paso que la gente se salta es el control: baja el túnel del host y repite la petición del invitado. Si el invitado sigue navegando, nunca dependió del túnel del host, diga lo que diga el nombre del modo. En modo NAT el invitado debería perder internet con el túnel del host caído, salvo que el cliente esté configurado para permitir tráfico sin túnel, lo cual merece saberse por sí solo.
Dos señales mienten. Un ping correcto demuestra alcanzabilidad, no ruta de salida. Y el DNS puede responderse desde el proxy 10.0.2.3 a través del resolutor del host mientras TCP toma otra ruta, que es como se consigue una página que carga y un inicio de sesión que nunca termina.
Qué modo encaja con el trabajo
El modo es una decisión de enrutamiento, así que elígelo por requisito y no por costumbre:
| Requirement | Mode that fits |
|---|---|
| Every guest flow must exit through the host tunnel | NAT, with a host client that tunnels by route, verified from inside the guest |
| The guest needs its own VPN account or profile | Bridged, or NAT with a client running inside the guest, not both |
| The guest must serve SSH, SMB, or a dev server to the LAN | Bridged; NAT needs a port forward, which does not change the outbound path |
| The guest must stay invisible to the LAN | NAT; a bridged guest is another host on the segment |
| The guest needs a real public IPv6 address | Bridged; VirtualBox NAT mode has no IPv6 forwarding |
| Isolation from the LAN with access to the host | Host-only adapter, not NAT |
La primera fila es donde pilla la gente: NAT más un cliente de túnel completo en el host sí cubre a un invitado, pero solo mientras el cliente tuneliza por ruta y el enlace ascendente del host es ese túnel. Mueve el cliente a una lista de permitidos solo para el navegador y la cobertura desaparece sin ningún error en ninguna parte. La cuarta fila es el error inverso: un invitado en puente por comodidad que empieza a responder SMB o SSH en la LAN de la oficina sin que nadie lo note.
Fallos que se achacan a la VPN
En Windows la traducción NAT se ejecuta dentro del proceso de la VM de VirtualBox, así que un cliente por aplicación necesita esa imagen exacta en su lista en lugar de una regla general para máquinas virtuales. Cuando una actualización del cliente reconstruye su lista de procesos, los invitados NAT pierden la cobertura primero, y el informe suena a una VM que alcanza la LAN pero no internet mientras el host está bien.
El puente sobre Wi-Fi es el otro clásico. Los puntos de acceso rara vez reenvían tramas con una MAC de origen ajena, así que un puente sobre wlan0 o falla del todo o funciona hasta que el aislamiento de clientes del AP empieza a descartarlo. VirtualBox seguirá ofreciendo el adaptador inalámbrico en su lista. Si el host está en Wi-Fi y el invitado tiene que ir en puente, planifica probarlo en lugar de suponerlo.
El MTU es el tercero. Un invitado en puente conserva el MTU de 1500 bytes de la LAN, y si ejecuta su propio cliente WireGuard a 1420, los handshakes TLS grandes se atascan mientras las peticiones pequeñas funcionan. Bajo NAT el MTU del túnel del host es problema del host, pero el invitado sigue creyendo en 1500, y el UDP con el bit no fragmentar activado se pierde igual.
Anota el modo y vuelve a comprobar tras cualquier cambio de adaptador
Anota el modo, la interfaz del host que usa el puente, la puerta de enlace predeterminada del invitado, su resolutor y sus direcciones de salida v4 y v6. Ese registro es lo que abarata el siguiente fallo: cuando un portátil pasa del dock al Wi-Fi, un invitado en puente sigue al puente hacia otro adaptador físico y puede renovar la concesión en otra subred, mientras un invitado NAT conserva su dirección 10.0.2.x y hereda en silencio otro enlace ascendente.
Antes de cerrar el ticket, confirma cada uno de estos puntos:
- La dirección de salida del invitado difiere de la del host, así que no está en el túnel del host.
- El resolutor es el proxy 10.0.2.3 o un servidor de la LAN, y sabes cuál respondió.
- No existe ninguna dirección v6 global en el invitado si el diseño del túnel es solo v4.
- Con el túnel del host caído, el invitado deja de navegar, o ahora sabes que nunca dependió de él.
- El invitado no ve tráfico de difusión de la LAN que no le incumbe.