¿VPN activada y VM inaccesible? La ruta probablemente nunca fue el problema

Conecta la VPN y la VM de desarrollo que respondía hace un minuto se queda muda. La historia obvia se escribe sola: el túnel se llevó la ruta, el anfitrión ahora envía el tráfico del invitado a la red corporativa, y el arreglo es añadir una ruta estática o cambiar el adaptador a modo puente. Esa historia a veces es cierta. Pero no es la causa habitual, y actuar según ella primero suele romper otra cosa.

La red host-only es una red de software propiedad del anfitrión y compartida con sus invitados, separada de cualquier conexión física. Nada en la propia interfaz del cliente VPN cambia esa red, así que antes de tocarla, averigua cuál de las cuatro capas falló realmente.

La ruta normalmente sigue siendo local

Pregunta al núcleo en lugar de a la portada de la tabla de rutas. En Linux, ip route get 192.168.56.10 informa de la ruta, la interfaz y la dirección de origen exactas que se usarían, lo que es una respuesta distinta a leer una ruta por defecto y adivinar. Si la salida nombra la interfaz host-only, el túnel no participa en absoluto en esa ruta.

Dos cosas sí pueden romperla, y ambas son problemas de direcciones y no de VPN. Una subred remota que se solape con el prefijo host-only hace ganar a la ruta más específica, y un cliente VPN que instala una ruta amplia con una métrica más baja puede llevarse el prefijo. Ambas se ven en el mismo comando: la interfaz nombrada en la salida será el túnel, y la corrección corresponde a quien posea ese plan de direcciones.

Selección de ruta y admisión de paquetes son decisiones distintas

Esta es la parte que el modelo mental suele omitir. Incluso con una ruta local perfecta, un cliente VPN puede rechazar el paquete. Muchos clientes aplican una política de acceso local a la red que decide qué destinos se permiten fuera del túnel, y una subred conectada no actualiza esa lista automáticamente.

Así, el fallo parece idéntico a un problema de enrutamiento desde el lado de la aplicación y completamente distinto desde el lado del cliente. Si ip route get nombra la interfaz correcta y la conexión sigue agotando el tiempo, deja de editar rutas y lee en su lugar el comportamiento de acceso local documentado del cliente. Algunos clientes ofrecen una lista de permitidos para subredes locales, otros bloquean todo lo que no sea el túnel, y otros solo bloquean cuando hay un kill switch activado.

Esa distinción importa porque los arreglos no son intercambiables. Añadir una ruta no satisface un filtro, y desactivar un filtro para llegar a un solo invitado es una decisión mucho mayor de lo que sugiere el síntoma.

El invitado tiene tres formas de decir que no

Un invitado que puede navegar por internet no ha demostrado nada sobre el servicio que quieres. El receptor puede estar vinculado a 127.0.0.1 dentro del invitado, y en ese caso ninguna petición del anfitrión puede llegar, por buena que sea la ruta. Compruébalo con ss -ltn dentro del invitado y mira la columna de la dirección local, no solo el puerto.

Después está el cortafuegos del propio invitado. Una imagen de desarrollo con un valor por defecto restrictivo puede aceptar los paquetes del anfitrión y descartarlos en el límite del servicio, lo que produce un tiempo de espera que parece exactamente un agujero negro de enrutamiento. Por último está la configuración del propio servicio: una aplicación web vinculada a un nombre de anfitrión concreto, o una lista de direcciones de cliente permitidas, rechazará una petición de la subred host-only aunque lleguen todos los paquetes.

Repasa esos tres puntos antes de plantearte cambiar el modo de red de la VM. Cada uno es un cambio menor que rediseñar la conexión del invitado, y cada uno tiene una prueba clara.

Qué es realmente un puente, y cuánto cuesta

Cambiar el adaptador a modo puente no es una reparación del camino host-only. Es la decisión de poner al invitado en otra red, normalmente la LAN física, donde se vuelve visible para todo lo demás que vive allí. Puede ser exactamente lo que quieres. Pero no es lo que hacía la configuración original.

Úsalo cuando el invitado realmente necesite ser un par en esa LAN y la exposición esté aprobada. No lo uses porque un solo servicio haya dejado de responder, ya que el cambio puede sacar al invitado del aislamiento que lo hacía seguro para desarrollar.

Después de cualquier corrección aprobada, prueba en un orden fijo: una petición nueva del anfitrión al invitado, un recurso corporativo necesario a través del túnel, y el comportamiento denegado previsto con el túnel caído. Si el último ya no se cumple, la corrección fue más allá del problema.

La sección de VirtualBox sobre redes host-only describe la interfaz de software del lado del anfitrión y en qué se diferencia de una conexión en puente, que es la referencia que vale la pena leer antes de suponer que los dos modos son intercambiables.