Dous clientes VPN, unha táboa de rutas: quen gaña a ruta predeterminada

Parece que dous clientes VPN pelexan polo mesmo socket, e a solución obvia debe ser desinstalar un. Na práctica raramente tocan o mesmo socket. Cada conexión reescribe a táboa de rutas do sistema operativo, e un perfil de túnel completo reclama a ruta predeterminada. Adoita gañar o que se conectou ao final, e por iso o síntoma parece moverse entre clientes.

O conflito vive na táboa de rutas

Un adaptador virtual máis unha ruta predeterminada é como un túnel completo captura o tráfico. Cando o segundo cliente instala a súa propia ruta predeterminada, a entrada anterior substitúese ou degrádase por métrica, e cada destino viaxa agora polo túnel máis novo. O primeiro cliente segue conectado e aínda mostra unha icona verde, así que a interface está activa mentres a ruta desapareceu. Esa separación entre o estado de conexión e o estado de enrutamento é o que fai confuso o comportamento.

Os clientes son editores dunha táboa compartida. Saber que edición ocorreu ao final explica case todos os síntomas.

Le que túnel posúe a ruta actual

Comproba a decisión real en lugar de confiar no cliente que informa de que está conectado. Pregunta ao sistema que interface levaría un destino concreto.

ip route get 10.20.0.5
route print -4

O primeiro comando nomea a interface e o enderezo de orixe para un destino, e esa é a pregunta exacta que che importa. O volcado de rutas mostra en Windows as entradas predeterminadas en competencia e as súas métricas, así que ves cal gaña agora. Executa a consulta para un host de cada rede remota, porque un destino pode ser correcto mentres a outra rede é inalcanzable. Se a resposta nomea o túnel equivocado, reconectar non axudará; a política de enrutamento ten que cambiar.

Detén o segundo cliente para que non reclame todo

Un cliente debería posuír a ruta predeterminada, e o outro só debería levar os seus propios prefixos. OpenVPN os clientes poden rexeitar o que o servidor empuxa.

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

route-nopull ignora cada ruta empuxada, mentres que pull-filter ignore "redirect-gateway" só descarta a directiva de ruta predeterminada e conserva o DNS e outras opcións empuxadas. Elixe entre eles segundo canta configuración do servidor queiras aínda, e despois engade os prefixos concretos que precisa a segunda rede. Ten en conta o DNS, porque un resolutor empuxado por un túnel que non leva as consultas non devolve nada. Proba un host coñecido en cada rede e confirma o enderezo de orixe que ve o lado remoto.

As subredes solapadas non se poden evitar

Cando ambas as redes publican o mesmo prefixo, o núcleo mantén unha entrada para dous lugares distintos e debe elixir. Unha ruta de host non pode inventar a distinción que falta, nin un axuste de métrica tampouco. Renumera un lado, ou fai que o seu administrador traduza o rango remoto para que os prefixos difiran. Comproba as subredes reais antes de culpar os clientes, porque o valor predeterminado 192.168.1.0/24 dun router doméstico choca cun rango de oficina máis a miúdo do que ninguén espera. Anota ambos os rangos no ticket para que o próximo cambio non volva crear o solapamento.

Separa tamén dous obxectivos: alcanzar ambas as redes é un problema de enrutamento, mentres que encadear túneles por privacidade é outro deseño cun operador extra na ruta. Non uses un para resolver o outro.