Por qué el orden de los adaptadores no decide la ruta VPN del laboratorio

Que el adaptador 1 sea el primero de la lista del hipervisor es solo un orden de visualización, y la tabla de enrutamiento del invitado no lo lee. Lo que decide la ruta es el prefijo, la métrica y cualquier regla de política que se aplique antes que ambas. Por eso, añadir un adaptador puente a una VM de laboratorio puede crear una segunda ruta predeterminada mientras la antigua interfaz NAT sigue apareciendo como presente y numerada en segundo lugar. El resultado es una VM que a veces usa el túnel y a veces no, sin ningún cambio de configuración que lo explique.

Tres condiciones deciden la ruta

Las tres condiciones son qué prefijo es más específico, qué hacen las métricas cuando los prefijos empatan y qué reglas aplicó el invitado tras el cambio de hardware. Cada una se responde con un solo comando, y ninguna depende de la numeración del hipervisor.

Ese último punto es la decisión: si no puede decir qué prefijo gana para la propia dirección del punto final VPN, no tiene una política de enrutamiento, tiene una topología que hoy funciona por casualidad.

Primera condición: qué prefijo gana

Una ruta hacia 10.8.0.0/24 supera a una ruta predeterminada para una dirección dentro de ella, sin importar las métricas ni el orden de los adaptadores. Por eso un cliente VPN que instala una ruta específica sigue funcionando aunque aparezca un segundo adaptador con una métrica menor: la especificidad gana antes de considerar el coste. Compruebe con ip route show la tabla que cree que está en uso, y con ip route get 203.0.113.9 la respuesta que el núcleo daría realmente para un destino concreto.

La propia dirección del punto final es la prueba que más importa. Si la dirección del servidor VPN se resuelve a través de un adaptador puente recién añadido, el túnel puede no establecerse nunca, o establecerse y luego perder su propia ruta de transporte. Consulte esa dirección en concreto en lugar de suponer que la interfaz del túnel es la respuesta.

Segunda condición: qué hace la métrica y qué no

Su papel es más estrecho de lo que la mayoría espera. Las métricas desempatan entre rutas hacia el mismo prefijo; no permiten que una ruta más amplia venza a una más específica. Dentro de un empate se prefiere el número menor, y distintos sistemas operativos cuentan en direcciones opuestas, por eso los consejos copiados entre Linux y Windows a menudo se contradicen.

En el invitado, ip route show imprime la métrica junto a cada ruta, y Get-NetRoute en Windows imprime una InterfaceMetric más una métrica de ruta. Lea ambas, porque la preferencia efectiva puede ser una suma y no un único campo. Si existen dos rutas predeterminadas, ese es el hallazgo: el invitado tiene dos salidas, y cuál gana es función de números que un cambio de hardware puede alterar.

Tercera condición: qué aplicó realmente el invitado

La configuración no es lo mismo que el estado aplicado. Los nombres de interfaz no son estables entre cambios de hardware en todas las plataformas, y una configuración que coincidía por nombre puede que ahora no se aplique a nada.

Compruebe el estado aplicado y no el previsto. ip -br link muestra las interfaces que existen ahora, y en un host con NetworkManager nmcli connection show muestra qué perfil está vinculado a qué dispositivo. Un perfil que no logró vincularse deja la interfaz levantada sin direccionamiento, lo que parece un problema de enrutamiento y es un problema de nombres. Las instantáneas restauradas lo empeoran, porque el estado guardado del invitado puede referenciar identidades de adaptador que el nuevo hardware ya no proporciona.

Mantenga reproducible la topología del laboratorio

Guarde las conexiones de red virtual previstas junto con la configuración del invitado, para que la correspondencia de rol a adaptador quede escrita en lugar de inferida de una posición en la lista.

Normalmente basta con nombrar cuatro roles: enlace privado, gestión, transporte exterior y túnel. Cada uno debería corresponder a un adaptador concreto y a una interfaz de invitado concreta, en un archivo.

Después pruebe la aplicación real tras un cambio de hardware, un reinicio o una instantánea restaurada, e incluya la ruta al punto final VPN en esa prueba. Si una VM de puerta de enlace debe ser la única salida, verifique que la VM de prueba no tenga una segunda ruta predeterminada no deseada, porque una segunda ruta predeterminada es exactamente lo que añade un adaptador puente. Pruebe desde el invitado, no desde la consola del hipervisor, ya que ambos pueden no coincidir sobre qué interfaz es cuál.

La documentación de redes de VirtualBox describe los modos de adaptador y a qué se conecta cada uno, que es la parte que vale la pena leer antes de añadir un segundo. Un laboratorio que identifica qué adaptador sirve a cada rol hace explicable un cambio de ruta. Un laboratorio que depende de la numeración del hipervisor convierte cada cambio en un experimento.