Por que un segundo túnel VPN rompe o primeiro?

Instalar un segundo cliente VPN para chegar a unha rede de cliente é a forma habitual en que isto comeza, e o primeiro túnel apágase mentres ambos os clientes informan de éxito. Cada cliente instalou unha ruta predeterminada, a segunda era máis específica, e o núcleo agora séguena para todo agás a propia conexión exterior do primeiro túnel. Nada caeu e ningún perfil está mal. Unha ruta substituíu a outra, e a solución é decidir que túnel debe posuír a predeterminada.

O síntoma: o segundo cliente gaña en silencio

OpenVPN: a súa opción redirect-gateway def1 non sobrescribe 0.0.0.0/0. Engade 0.0.0.0/1 e 128.0.0.0/1: entre ambas cobren todos os enderezos IPv4, e cada prefixo supera por lonxitude a unha predeterminada simple. A predeterminada orixinal queda na táboa e deixa de usarse para o tráfico normal, e unha ruta de host ao servidor VPN evita que o túnel capture os seus propios paquetes exteriores. Ambos os clientes fan isto, e o segundo simplemente instala a súa parella máis tarde.

Por iso o primeiro túnel parece morto en vez de desconectado. A súa interface está activa, a súa canle de control segue viva e xa non lle chega tráfico de aplicacións. A queixa inversa ten o mesmo push ausente: un teléfono que se conecta pero non envía nada adoita falar cun servidor que nunca anunciou redirect-gateway, así que o dispositivo conserva a súa propia predeterminada e só alcanza a piscina.

Tome unha instantánea das rutas antes e despois de que se conecte o segundo cliente. As dúas semirrutas que aparecen na táboa son todo o cambio, e explican ambas as queixas. Nada máis na táboa ten que moverse para que apareza o síntoma. Por iso quitar o segundo cliente restaura o primeiro ao instante.

Lea que túnel gaña realmente

Non deduza o gañador da orde en que arrincaron os clientes nin da icona da bandexa. Pregunte ao núcleo que ruta usaría para un destino fóra de ambas as redes privadas, e lea a interface que devolve.

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

Os dous primeiros son a resposta de Linux e os dous últimos o equivalente de Windows. Execúteos con ambos os túneles activos, logo desconecte un e execúteos outra vez. A diferenza entre as dúas saídas é o feito que necesita antes de escoller unha solución, e leva menos tempo que ler o rexistro de calquera dos clientes.

Anote o resultado, incluídos o nome da interface e o prefixo que coincidiu. Un tícket que di que o segundo VPN rompeu o primeiro é unha descrición do síntoma, non unha afirmación de encamiñamento sobre a que ninguén poida actuar. A consulta convérteo nun feito que o seguinte enxeñeiro pode reproducir cun só comando.

Windows: evitar que un perfil posúa a predeterminada

Windows conserva perfís gardados, e o cliente integrado permite que un dependa doutro para que o primeiro suba automaticamente cando o segundo marca. O perfil conectado máis recentemente adoita conservar a predeterminada, así que o propietario práctico é a última marcación e non a primeira. Dea a cada perfil as súas propias rutas empuxadas e active o túnel dividido para o que non debe posuír a predeterminada.

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

O túnel dividido cambia iso: só os prefixos empuxados polo servidor chegan á táboa, o que deixa a predeterminada no primeiro túnel. O deseño segue fallando se ambos os servidores empuxan unha ruta predeterminada, porque entón gaña a última conexión e ningún axuste do lado do cliente o cambia. Corrixa o push do servidor ou acepte un só propietario.

Os perfís activados por aplicacións son outra función e paga a pena coñecelos: un perfil de Windows pode iniciarse cando arrinca un executábel concreto, con filtros de tráfico que deciden o que transporta. É un axuste de perfil e non unha regra de firewall, e resolve un problema distinto do conflito de ruta predeterminada.

Linux: manter o segundo túnel fóra da táboa principal

Executar dúas instancias de openvpn --config nunha máquina pon ambos os clientes na mesma táboa, e tres opcións séparanos cun illamento crecente. A máis lixeira é impedir de todo que o segundo cliente edite a táboa, con route-nopull e rutas explícitas, ou un script route-up que só instale o que vostede quere. Entón o segundo túnel leva exactamente os prefixos que nomea e nada máis. Entón vostede decide que prefixos van a onde en lugar de descubrilo despois.

O encamiñamento por políticas é a opción intermedia. Unha regra selecciona unha táboa aparte para un enderezo de orixe ou unha marca de firewall, e esa táboa leva as rutas do segundo túnel. O filtrado de ruta inversa é a trampa aquí, porque unha resposta que chega por unha interface distinta da que elixiría a táboa descártase, así que comprobe o axuste rp_filter antes de concluír que o 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

Os espazos de nomes de rede son a opción máis pesada e a máis limpa. Inicie o segundo cliente dentro de ip netns, déalle un par veth e entre nese espazo de nomes para usalo. A interferencia desaparece porque cada espazo de nomes ten as súas propias táboas en lugar de compartir unha, o que paga a pena a configuración extra cando ambos os túneles deben permanecer activos durante semanas.

Por aplicación, e o encadeamento como problema aparte

Ás veces só un programa debería usar o segundo túnel. En Linux, o encamiñamento por políticas por usuario, cgroup ou porto logra ese resultado, e un só destino pódese fixar a unha interface sen tocar a predeterminada. Unha aplicación que fixa o seu socket a unha interface nunca consulta a táboa de encamiñamento, así que un lanzador pode seguir usando o adaptador físico ata que se escolla un enderezo dentro dos seus propios axustes.

O encadeamento é unha operación distinta de executar dous túneles un ao lado do outro. Encadear A sobre B significa que o enderezo do servidor interior debe ser alcanzable desde dentro do túnel exterior. O cliente exterior tampouco debe confundir os paquetes cifrados do cliente interior cunha fuga. Un cliente dentro dunha máquina virtual é a versión tosca pero fiable; ambos nun só host requiren o traballo de encamiñamento anterior máis un camiño exterior cara ao servidor interior que nunca entre no túnel interior.

Anote o propietario da predeterminada, a lista de prefixos que leva cada túnel e o camiño DNS. Esas tres verdades converten o próximo incidente nunha consulta en lugar dunha investigación.