¿Por qué un segundo túnel VPN rompe el primero?

Instalar un segundo cliente VPN para llegar a una red de cliente es la forma habitual en que esto empieza, y el primer túnel se apaga mientras ambos clientes informan de éxito. Cada cliente instaló una ruta predeterminada, la segunda era más específica, y el núcleo ahora la sigue para todo excepto la propia conexión exterior del primer túnel. Nada se cayó y ningún perfil está mal. Una ruta sustituyó a otra, y la solución es decidir qué túnel debe poseer la predeterminada.

El síntoma: el segundo cliente gana en silencio

OpenVPN: su opción redirect-gateway def1 no sobrescribe 0.0.0.0/0. Añade 0.0.0.0/1 y 128.0.0.0/1: entre ambas cubren todas las direcciones IPv4, y cada prefijo supera por longitud a una predeterminada simple. La predeterminada original se queda en la tabla y deja de usarse para el tráfico normal, y una ruta de host al servidor VPN evita que el túnel capture sus propios paquetes exteriores. Ambos clientes hacen esto, y el segundo simplemente instala su pareja más tarde.

Por eso el primer túnel parece muerto en lugar de desconectado. Su interfaz está activa, su canal de control sigue vivo y ya no llega tráfico de aplicaciones. La queja inversa tiene el mismo push ausente: un teléfono que se conecta pero no envía nada suele hablar con un servidor que nunca anunció redirect-gateway, así que el dispositivo conserva su propia predeterminada y solo alcanza la piscina.

Tome una instantánea de las rutas antes y después de que se conecte el segundo cliente. Las dos semirrutas que aparecen en la tabla son todo el cambio, y explican ambas quejas. Nada más en la tabla tiene que moverse para que aparezca el síntoma. Por eso quitar el segundo cliente restaura el primero al instante.

Lea qué túnel gana realmente

No deduzca el ganador del orden en que arrancaron los clientes ni del icono de la bandeja. Pregunte al núcleo qué ruta usaría para un destino fuera de ambas redes privadas, y lea la interfaz que devuelve.

ip route show
ip route get 198.51.100.24
route print -4
Find-NetRoute -RemoteIPAddress 198.51.100.24

Los dos primeros son la respuesta de Linux y los dos últimos el equivalente de Windows. Ejecútelos con ambos túneles activos, luego desconecte uno y ejecútelos otra vez. La diferencia entre las dos salidas es el hecho que necesita antes de elegir una solución, y lleva menos tiempo que leer el registro de cualquiera de los clientes.

Anote el resultado, incluidos el nombre de la interfaz y el prefijo que coincidió. Un ticket que dice que el segundo VPN rompió el primero es una descripción del síntoma, no una afirmación de enrutamiento sobre la que nadie pueda actuar. La consulta lo convierte en un hecho que el siguiente ingeniero puede reproducir con un solo comando.

Windows: evitar que un perfil posea la predeterminada

Windows conserva perfiles guardados, y el cliente integrado permite que uno dependa de otro para que el primero suba automáticamente cuando el segundo marca. El perfil conectado más recientemente suele conservar la predeterminada, así que el propietario práctico es la última marcación y no la primera. Dé a cada perfil sus propias rutas empujadas y active el túnel dividido para el que no debe poseer la predeterminada.

Set-VpnConnection -Name "Contoso" -SplitTunneling $true
rasdial Contoso

El túnel dividido cambia eso: solo los prefijos empujados por el servidor llegan a la tabla, lo que deja la predeterminada en el primer túnel. El diseño sigue fallando si ambos servidores empujan una ruta predeterminada, porque entonces gana la última conexión y ningún ajuste del lado del cliente lo cambia. Corrija el push del servidor o acepte un solo propietario.

Los perfiles activados por aplicaciones son otra función y merece la pena conocerlos: un perfil de Windows puede iniciarse cuando arranca un ejecutable concreto, con filtros de tráfico que deciden qué transporta. Es un ajuste de perfil y no una regla de firewall, y resuelve un problema distinto del conflicto de ruta predeterminada.

Linux: mantener el segundo túnel fuera de la tabla principal

Ejecutar dos instancias de openvpn --config en una máquina pone ambos clientes en la misma tabla, y tres opciones los separan con un aislamiento creciente. La más ligera es impedir del todo que el segundo cliente edite la tabla, con route-nopull y rutas explícitas, o un script route-up que solo instale lo que usted quiere. Entonces el segundo túnel lleva exactamente los prefijos que nombre y nada más. Entonces usted decide qué prefijos van a dónde en lugar de descubrirlo después.

El enrutamiento por políticas es la opción intermedia. Una regla selecciona una tabla aparte para una dirección de origen o una marca de firewall, y esa tabla lleva las rutas del segundo túnel. El filtrado de ruta inversa es la trampa aquí, porque una respuesta que llega por una interfaz distinta de la que elegiría la tabla se descarta, así que compruebe el ajuste rp_filter antes de concluir que el túnel está roto.

ip rule add from 10.44.7.0/24 table 100
ip route add default dev tun1 table 100
sysctl net.ipv4.conf.all.rp_filter

Los espacios de nombres de red son la opción más pesada y la más limpia. Inicie el segundo cliente dentro de ip netns, dele un par veth y entre en ese espacio de nombres para usarlo. La interferencia desaparece porque cada espacio de nombres tiene sus propias tablas en lugar de compartir una, lo que vale la configuración extra cuando ambos túneles deben permanecer activos durante semanas.

Por aplicación, y el encadenamiento como problema aparte

A veces solo un programa debería usar el segundo túnel. En Linux, el enrutamiento por políticas por usuario, cgroup o puerto logra ese resultado, y un solo destino se puede fijar a una interfaz sin tocar la predeterminada. Una aplicación que fija su socket a una interfaz nunca consulta la tabla de enrutamiento, así que un lanzador puede seguir usando el adaptador físico hasta que se elija una dirección dentro de sus propios ajustes.

El encadenamiento es una operación distinta de ejecutar dos túneles uno al lado del otro. Encadenar A sobre B significa que la dirección del servidor interior debe ser alcanzable desde dentro del túnel exterior. El cliente exterior tampoco debe confundir los paquetes cifrados del cliente interior con una fuga. Un cliente dentro de una máquina virtual es la versión tosca pero fiable; ambos en un solo host requieren el trabajo de enrutamiento anterior más un camino exterior hacia el servidor interior que nunca entre en el túnel interior.

Anote el propietario de la predeterminada, la lista de prefijos que lleva cada túnel y la ruta DNS. Esos tres hechos convierten el próximo incidente en una consulta en lugar de una investigación.