Dos clientes VPN a la vez: ¿quién gana la ruta predeterminada?

Ejecutar dos clientes VPN a la vez es una discusión de enrutamiento, no un ajuste de privacidad. El túnel que posee la ruta más específica recibe el tráfico, y el otro permanece conectado pero inactivo. La puerta de enlace corporativa ve entonces una conexión que llega desde la salida personal, mientras que el cliente corporativo de tu máquina sigue viendo cada adaptador. Decidir cuál de esos dos hechos importa es todo el ejercicio.

La tabla de rutas elige un solo ganador

Captura la tabla antes y después de que arranque el cliente corporativo, y lee la columna de interfaz en lugar de solo el destino. Una ruta predeterminada simple del túnel exterior es fácil de desplazar, porque un par /1 es más específico que /0. El par literal 0.0.0.0/1 y 128.0.0.0/1 cubre todo el espacio IPv4 en dos mitades y supera cualquier ruta predeterminada única. Una vez instalado, el túnel exterior sigue mostrándose conectado y no transporta nada.

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

El enrutamiento por políticas puede anular por completo la tabla principal, así que lee tanto las reglas como las rutas. Una regla que envía el tráfico marcado a otra tabla gana antes de que se consulte la tabla principal. Así es como una aplicación puede quedarse en el enlace físico mientras todo lo demás usa el túnel.

ip rule show

Windows lo decide con métricas

En Windows, el ganador es la ruta con la métrica más baja para el destino, y dos clientes pueden instalar ambos una ruta predeterminada con métricas distintas. Lee la tabla y la configuración de la interfaz juntas, porque el adaptador con la métrica más baja no siempre es el que esperas. Un cliente que también fija una métrica de interfaz puede mover la predeterminada sin añadir ni una sola ruta. El adaptador que pierde se queda activo y simplemente no recibe nada.

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

Compara las dos salidas y nombra la interfaz que posee 0.0.0.0/0. Si ambos clientes la reclaman, decide la métrica, y por eso una prueba de orden de conexión puede parecer inconsistente entre máquinas. Si ninguna de las dos salidas muestra una puerta de enlace predeterminada, el cliente no funciona en túnel completo y el argumento de la cadena queda sin sentido.

Dos observadores, dos visiones distintas

La puerta de enlace remota ve una conexión que llega desde la salida exterior más todo lo que el cliente reenvía a su túnel. El cliente local ve adaptadores, rutas y la existencia de otro túnel, porque se ejecuta con privilegios para crearlos. Separar esas visiones es el punto; afirmar que el cliente no puede darse cuenta no lo es.

Supón que el cliente puede enumerar lo que quiera y planifica para la visión de la puerta de enlace. Un diseño que depende de que el cliente siga ciego está a una actualización de romperse.

DNS e IPv6 son donde la cadena pierde

El DNS sigue el ajuste de resolutor que gane, y ese no es necesariamente el camino que toman los paquetes. Un resolutor corporativo alcanzado a través del túnel corporativo es coherente con el diseño; uno local alcanzado fuera de él no lo es, y expone nombres que el túnel debía ocultar. IPv6 es la segunda fuga: un host de pila doble sigue usando IPv6 hacia destinos que el túnel solo transporta por IPv4. Comprueba las familias por separado, porque un túnel solo de IPv4 no dice nada sobre rutas o resolutores IPv6.

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

Corrige el resolutor y la ruta IPv6 a propósito en lugar de apilar un segundo túnel encima. La encapsulación doble también cuesta MTU, así que una MTU interna más pequeña es lo primero que hay que probar cuando las páginas se atascan tras levantar la cadena. Un resolutor que responde rápido no es prueba de que sea el correcto.