Dos clientes VPN, una tabla de rutas: quién gana la ruta predeterminada

Parece que dos clientes VPN se pelean por el mismo socket, y la solución obvia debe ser desinstalar uno. En la práctica rara vez tocan el mismo socket. Cada conexión reescribe la tabla de rutas del sistema operativo, y un perfil de túnel completo reclama la ruta predeterminada. Suele ganar el que se conectó al final, y por eso el síntoma parece moverse entre clientes.

El conflicto vive en la tabla de rutas

Un adaptador virtual más una ruta predeterminada es cómo un túnel completo captura el tráfico. Cuando el segundo cliente instala su propia ruta predeterminada, la entrada anterior se reemplaza o se degrada por métrica, y cada destino viaja ahora por el túnel más nuevo. El primer cliente sigue conectado y aún muestra un icono verde, así que la interfaz está activa mientras la ruta desapareció. Esa separación entre el estado de conexión y el estado de enrutamiento es lo que hace confuso el comportamiento.

Los clientes son editores de una tabla compartida. Saber qué edición ocurrió al final explica casi todos los síntomas.

Lee qué túnel posee la ruta actual

Comprueba la decisión real en lugar de confiar en el cliente que informa que está conectado. Pregunta al sistema qué interfaz llevaría un destino concreto.

ip route get 10.20.0.5
route print -4

El primer comando nombra la interfaz y la dirección de origen para un destino, y esa es la pregunta exacta que te importa. El volcado de rutas muestra en Windows las entradas predeterminadas en competencia y sus métricas, así que ves cuál gana ahora. Ejecuta la consulta para un host de cada red remota, porque un destino puede ser correcto mientras la otra red es inalcanzable. Si la respuesta nombra el túnel equivocado, reconectar no ayudará; la política de enrutamiento tiene que cambiar.

Detén al segundo cliente para que no reclame todo

Un cliente debería poseer la ruta predeterminada, y el otro solo debería llevar sus propios prefijos. OpenVPN los clientes pueden rechazar lo que el servidor empuja.

pull-filter ignore "redirect-gateway"
ip route get 10.30.4.10

route-nopull ignora cada ruta empujada, mientras que pull-filter ignore "redirect-gateway" solo descarta la directiva de ruta predeterminada y conserva el DNS y otras opciones empujadas. Elige entre ellos según cuánta configuración del servidor quieras todavía, y luego añade los prefijos concretos que necesita la segunda red. Ten en cuenta el DNS, porque un resolutor empujado por un túnel que no lleva las consultas no devuelve nada. Prueba un host conocido en cada red y confirma la dirección de origen que ve el lado remoto.

Las subredes solapadas no se pueden esquivar

Cuando ambas redes publican el mismo prefijo, el núcleo mantiene una entrada para dos lugares distintos y debe elegir. Una ruta de host no puede inventar la distinción que falta, ni un ajuste de métrica tampoco. Renumera un lado, o haz que su administrador traduzca el rango remoto para que los prefijos difieran. Comprueba las subredes reales antes de culpar a los clientes, porque el valor predeterminado 192.168.1.0/24 de un router doméstico choca con un rango de oficina más a menudo de lo que nadie espera. Anota ambos rangos en el ticket para que el próximo cambio no vuelva a crear el solapamiento.

Separa también dos objetivos: alcanzar ambas redes es un problema de enrutamiento, mientras que encadenar túneles por privacidad es otro diseño con un operador extra en la ruta. No uses uno para resolver el otro.