VPN en el invitado y VPN en el anfitrión: qué ruta gana de verdad

Dos clientes se ejecutan a la vez, cada uno convencido de que posee la ruta predeterminada, y el síntoma llega como algo extraño: una aplicación del invitado funciona y otra se resuelve en el lugar equivocado. Una VPN dentro de un invitado y una VPN en el anfitrión pueden convivir, pero solo cuando la ruta exterior y la política interior coinciden en quién transporta qué. Arrancar ambas no crea una cadena por sí solo. Anota primero la conexión y luego cambia una cosa cada vez.

Anota primero la conexión del invitado

El invitado llega a su servidor VPN por el camino que le dio el hipervisor: NAT detrás del anfitrión, un puente hacia el segmento físico o una red solo para el anfitrión con enrutamiento añadido encima. Cada conexión cambia lo que el invitado puede ver y lo que el anfitrión puede hacer con su tráfico. Bajo NAT los paquetes del invitado parecen venir del anfitrión, así que el propio túnel del anfitrión puede transportarlos sin que el invitado sepa nada. Bajo un puente el invitado tiene presencia propia en el segmento y su propia puerta de enlace predeterminada.

Anota la conexión antes de tocar cualquier configuración, junto con qué cliente debe transportar qué aplicación. Esa frase resuelve la mayoría de estos casos, porque los dos clientes suelen estar construidos sobre supuestos distintos. Un invitado que debe usar el túnel del anfitrión no debe tener además una ruta predeterminada competidora propia.

Sigue el extremo del invitado hacia fuera

Una VPN del invitado necesita un camino utilizable hacia su propio servidor antes de que nada más funcione. Cuando el túnel del anfitrión está activo y el invitado está detrás de NAT, el saludo del invitado sale por el túnel del anfitrión, lo que es o el diseño o un accidente que nadie documentó. Cuando el túnel del anfitrión cae y el invitado dependía de él, el invitado pierde conectividad sin un solo cambio por su parte. Seguir el extremo hacia fuera te dice cuál de esos dos casos tienes en realidad.

Una ruta amplia en cualquiera de los dos contextos captura tráfico que el otro cliente esperaba. Una ruta 0.0.0.0/0 dentro del invitado y un cliente de anfitrión con túnel completo reclaman ambos todo, y gana el que se aplique en último lugar. Las superposiciones entre las redes virtuales del invitado, la LAN local y las redes remotas producen el mismo efecto para prefijos privados, con fallos que se parecen a problemas de autenticación; el comportamiento de traducción de direcciones es el mismo que se describe para la red de contenedores.

Compara un registro de antes y después

Toma una línea base con el túnel del anfitrión apagado, o en cualquier estado controlado que permita tu política, y anota la ruta y el resolutor del invitado. Después aplica la configuración combinada y compara los dos registros, manteniendo intactos los requisitos de privacidad. Si una línea base directa no es adecuada, escribe esa limitación en el registro en lugar de omitir la comparación.

ip route get 10.20.30.41
ip rule show
resolvectl status --no-pager | head -12

La consulta de ruta nombra la interfaz y la dirección de origen que transportarían un destino concreto, y es la línea más útil de esta investigación. El listado de reglas muestra si el enrutamiento por políticas envía algunos destinos por una segunda tabla. La salida del resolutor muestra si el DNS siguió el túnel del invitado o se quedó en la ruta del anfitrión. Ejecuta los mismos tres comandos antes y después del cambio, y el delta nombra al culpable.

Mantén la propiedad clara entre reinicios

La restricción de acceso local de un cliente de anfitrión puede bloquear el tráfico hacia un NAT virtual o un puente, y esa restricción se confunde habitualmente con un problema de credenciales del invitado. Lee el comportamiento documentado del cliente en lugar de desactivar la restricción para que pase una prueba. Tras una corrección soportada, vuelve a probar la aplicación del invitado y la política de fallo que exiges. Un anfitrión que se reconecta con éxito no demuestra nada sobre la ruta o el resolutor del invitado.

Decide qué lado posee la ruta predeterminada y escríbelo en el manual de operaciones. Un reinicio del invitado o un cambio de red en el anfitrión que invierta la propiedad en silencio produce un informe de error sobre una VPN que nunca tuvo la culpa. El arreglo debería sobrevivir a un reinicio sin que nadie recuerde por qué funcionaba.