Dos clientes VPN en un mismo escritorio: qué choca y qué funciona

Su segundo cliente se conecta, los recursos del primero dejan de resolverse y el ticket dice que la VPN del trabajo rompió la personal. Nada está roto en el sentido de una avería: ambos clientes hicieron aquello para lo que fueron diseñados, y la máquina solo tiene una tabla de enrutamiento. El choque es por cuatro recursos que cada cliente asume que posee. Revíselos en orden y la solución suele convertirse en una decisión de diseño más que en una reparación.

Paso 1: averigüe qué cliente controla la salida

Lea la decisión de salida actual antes de cambiar nada. La consulta de ruta para una dirección pública le dice qué interfaz y qué salto siguiente usaría un paquete ahora mismo, y esa es la respuesta a quién ganó. Compárela con los nombres de interfaz que crearon los clientes, que suelen llevar el nombre del producto o del protocolo. Si la consulta apunta al túnel que no esperaba, ya ha encontrado el choque.

ip route get 1.1.1.1
ip route show default
route print

Algunos clientes no sustituyen la ruta predeterminada en absoluto; añaden dos mitades, una para la mitad inferior del espacio de direcciones y otra para la superior, que juntas lo cubren todo. Eso deja visible la ruta predeterminada original y hace que una reparación manual parezca correcta mientras el tráfico sigue saliendo por el túnel. Lea la métrica y la longitud del prefijo, no solo la presencia de una entrada predeterminada.

Deténgase si ambos clientes reclaman el mismo prefijo con la misma métrica. El núcleo elegirá uno, y el otro aparecerá conectado sin transportar nada.

Paso 2: compruebe el resolvedor y los prefijos superpuestos

El DNS es el segundo choque y produce un síntoma distintivo: los nombres fallan mientras las direcciones funcionan. Cada cliente impone su propio resolvedor, y el último que escribe gana para las consultas siguientes. Pregunte al servicio de resolución qué usa por enlace en lugar de leer la página de ajustes del cliente.

resolvectl status
Get-DnsClientServerAddress
dig +short intranet.corp.example

Luego compare los prefijos privados que usan las dos redes. Si ambos lados asignan del mismo rango, ningún arreglo del lado del cliente lo solucionará, porque la máquina no puede decir qué destino 10.0.0.0/8 pertenece a qué túnel. Un lado tiene que renumerarse o traducirse, y eso es una conversación con los dueños de la red, no un cambio de configuración. La superposición es el único choque donde la respuesta honesta es que el diseño tiene que cambiar.

Deténgase aquí si los prefijos se superponen. Todo lo posterior en esta lista asume que no lo hacen.

Paso 3: elija un patrón de separación que aguante

Los patrones fiables evitan ejecutar dos clientes contra la misma tabla de enrutamiento. Un solo cliente con una política de túnel dividido que llega a ambas redes privadas es lo más simple, siempre que los destinos no se superpongan y el dueño de la política esté de acuerdo. Una máquina virtual o un espacio de nombres de red es el siguiente paso, porque cada uno obtiene su propia tabla y su propio resolvedor.

sudo ip netns add vpn2
sudo ip netns exec vpn2 ip link show
sudo ip netns exec vpn2 curl -sI https://intranet.corp.example/

Un espacio de nombres da la misma separación que una máquina virtual sin el segundo sistema operativo, pero tiene aristas: el dispositivo del túnel tiene que moverse dentro y la aplicación debe iniciarse allí. Un dispositivo físico aparte suele ser la opción menos sorprendente para una VPN personal junto a un cliente de trabajo gestionado. Apilar un túnel dentro de otro no es un patrón de separación; el extremo interior debe seguir siendo alcanzable a través del túnel exterior, y la disposición añade encima problemas de MTU y latencia.

Elija un patrón y anote por qué. Mezclar un espacio de nombres para una aplicación con un túnel dividido para el resto recrea el choque original en una forma más difícil de depurar.

Paso 4: verifique ambas redes desde la misma sesión

Pruebe un recurso en cada red privada desde el entorno donde la aplicación se ejecuta de verdad, no desde su shell si la aplicación corre dentro de un espacio de nombres. Compruebe la interfaz de salida, la dirección resuelta y el código de respuesta a la vez, porque un éxito en uno de los tres puede ocultar un fallo en los otros. Repita tras un reinicio, ya que el orden en que arrancan los clientes decide quién gana. Ese orden es la parte que la gente olvida registrar.

curl -sI https://intranet.corp.example/
curl -sI https://files.personal.example/
ip route get 10.20.30.40

Registre las versiones de los clientes, las interfaces, el estado del resolvedor y los prefijos de cada red. Cuando un cliente se actualiza y cambia su comportamiento de enrutamiento, ese registro es la diferencia entre una reparación de cinco minutos y una reconstrucción. La siguiente persona no compartirá su memoria sobre qué túnel subió primero.

La lista está completa cuando puede nombrar la interfaz que posee la ruta predeterminada, el resolvedor que usa cada nombre, el patrón que separa el segundo túnel y el resultado de una petición por red tras un reinicio. Cualquier cosa menos es una configuración que funciona por casualidad hoy.