¿Tu VM usa la VPN del host? Compruébalo desde dentro del invitado

Compruebas la IP pública del host, muestra la VPN y concluyes que la VM está cubierta. Esa conclusión no la respalda la prueba. Un invitado tiene su propia tabla de enrutamiento, su propio resolutor y sus propias interfaces, y la dirección de salida del host no dice nada sobre ellas.

La prueba debe ejecutarse dentro del invitado y debe nombrar qué midió.

Empieza dentro del invitado, no en el navegador del host

Anota primero el modo de red del hipervisor: NAT, bridged, host-only o macvtap. En modo NAT el host enruta el tráfico del invitado, así que el túnel del host puede aplicarse o no según cómo el cliente instale las rutas. En modo bridged el invitado es un par en la LAN física y el túnel del host es irrelevante. Esos dos modos dan respuestas opuestas con la misma configuración del host.

Anota el modo antes de cambiar nada, porque determina qué puede significar el resultado.

Haz una petición cuyo destino conozcas

Usa una petición inocua a un servicio que informe de la dirección de origen que vio. Después comprueba la decisión de enrutamiento del propio invitado para ese destino: ip route get 203.0.113.5 imprime la interfaz y la puerta de enlace que usará el invitado.

Si la interfaz es la NIC normal del invitado, el tráfico no pasa por ningún túnel dentro del invitado.

Un segundo adaptador, un ajuste de proxy o un cliente VPN del lado del invitado pueden cambiar la respuesta para una aplicación y no para otra. Prueba la aplicación que de verdad te importa, no una petición genérica desde un shell.

Comprueba el resolutor por separado

Una dirección de salida distinta no te dice qué resolutor gestionó el nombre del host. Consulta el nombre de forma explícita con la herramienta que corresponda a la plataforma y anota qué servidor respondió. Un DNS dividido significa que la pregunta del resolutor y la del enrutamiento tienen respuestas distintas.

Esas dos pueden divergir en cualquier dirección, y la divergencia suele ser el fallo real.

En un host con systemd, resolvectl query nombra la interfaz y el servidor DNS que hay detrás de la respuesta. Las instalaciones más antiguas muestran el servidor en la salida de dig — en cualquier caso, la cuestión es ver qué servidor respondió, no solo si llegó una respuesta.

Prueba la política de fallo, no solo el éxito

Si el requisito es que ningún tráfico salga fuera del túnel, una petición correcta no demuestra nada. Usa la prueba de fallo controlada compatible con el cliente: detén el túnel de la forma admitida y comprueba si se bloquea una nueva petición del invitado. No des por hecho que el kill switch del cliente del host cubre cualquier disposición de reenvío virtual. Su alcance documentado es lo único con lo que puedes contar.

Un invitado que vuelve a la NIC física cuando cae el túnel hace exactamente lo que permite el modo NAT.

Anota el modo y el alcance

Anota el modo del hipervisor, la interfaz y la ruta del invitado, el resolutor y la aplicación que probaste. Añade la fecha, porque restaurar una instantánea o actualizar el hipervisor puede cambiar las cuatro cosas.

Si IPv4 siguió el túnel, dilo. No extiendas la afirmación a IPv6, a otro espacio de nombres ni a otra VM en otra red.