Dous clientes VPN nun só escritorio: que choca e que funciona

O seu segundo cliente conecta, os recursos do primeiro deixan de resolverse e o tícket di que a VPN do traballo rompeu a persoal. Nada está roto no sentido dunha avaría: ambos os clientes fixeron aquilo para o que foron deseñados, e a máquina só ten unha táboa de enrutamento. O choque é por catro recursos que cada cliente supón que posúe. Revíseos en orde e a solución adoita converterse nunha decisión de deseño máis que nunha reparación.

Paso 1: averigüe que cliente controla a saída

Lea a decisión de saída actual antes de cambiar nada. A consulta de ruta para un enderezo público dille que interface e que salto seguinte usaría un paquete agora mesmo, e esa é a resposta a quen gañou. Compárea cos nomes de interface que crearon os clientes, que adoitan levar o nome do produto ou do protocolo. Se a consulta apunta ao túnel que non esperaba, xa atopou o choque.

ip route get 1.1.1.1
ip route show default
route print

Algúns clientes non substitúen a ruta predeterminada en absoluto; engaden dúas metades, unha para a metade inferior do espazo de enderezos e outra para a superior, que xuntas o cobren todo. Iso deixa visible a ruta predeterminada orixinal e fai que unha reparación manual pareza correcta mentres o tráfico segue saíndo polo túnel. Lea a métrica e a lonxitude do prefixo, non só a presenza dunha entrada predeterminada.

Detéñase se ambos os clientes reclaman o mesmo prefixo coa mesma métrica. O núcleo elixirá un, e o outro aparecerá conectado sen transportar nada.

Paso 2: comprobe o resolutor e os prefixos superpostos

O DNS é o segundo choque e produce un síntoma distintivo: os nomes fallan mentres os enderezos funcionan. Cada cliente impón o seu propio resolutor, e o último que escribe gaña para as consultas seguintes. Pregunte ao servizo de resolución que usa por ligazón en lugar de ler a páxina de axustes do cliente.

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

Despois compare os prefixos privados que usan as dúas redes. Se ambos os lados asignan do mesmo rango, ningún arranxo do lado do cliente o solucionará, porque a máquina non pode dicir que destino 10.0.0.0/8 pertence a que túnel. Un lado ten que renumerarse ou traducirse, e iso é unha conversación cos donos da rede, non un cambio de configuración. A superposición é o único choque onde a resposta honesta é que o deseño ten que cambiar.

Detéñase aquí se os prefixos se superpón. Todo o posterior nesta lista asume que non o fan.

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

Os patróns fiables evitan executar dous clientes contra a mesma táboa de enrutamento. Un só cliente con unha política de túnel dividido que chega ás dúas redes privadas é o máis simple, sempre que os destinos non se superpón e o dono da política estea de acordo. Unha máquina virtual ou un espazo de nomes de rede é o paso seguinte, porque cada un obtén a súa propia táboa e o seu propio resolutor.

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 espazo de nomes dá a mesma separación que unha máquina virtual sen o segundo sistema operativo, pero ten arestas: o dispositivo do túnel ten que moverse dentro e a aplicación debe iniciarse alí. Un dispositivo físico á parte adoita ser a opción menos sorprendente para unha VPN persoal xunto a un cliente de traballo xestionado. Apilar un túnel dentro doutro non é un patrón de separación; o extremo interior debe seguir sendo alcanzable a través do túnel exterior, e a disposición engade encima problemas de MTU e latencia.

Elixa un patrón e anote por que. Mesturar un espazo de nomes para unha aplicación cun túnel dividido para o resto recrea o choque orixinal nunha forma máis difícil de depurar.

Paso 4: verifique ambas as redes desde a mesma sesión

Probe un recurso en cada rede privada desde a contorna onde a aplicación se executa de verdade, non desde a súa shell se a aplicación corre dentro dun espazo de nomes. Comprobe a interface de saída, o enderezo resolto e o código de resposta ao mesmo tempo, porque un éxito nun dos tres pode ocultar un fallo nos outros. Repítao tras un reinicio, xa que a orde na que arrancan os clientes decide quen gaña. Esa orde é a parte que a xente esquece rexistrar.

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

Rexiste as versións dos clientes, as interfaces, o estado do resolutor e os prefixos de cada rede. Cando un cliente se actualiza e cambia o seu comportamento de enrutamento, ese rexistro é a diferenza entre unha reparación de cinco minutos e unha reconstrución. A seguinte persoa non compartirá a súa memoria sobre que túnel subiu primeiro.

A lista está completa cando pode nomear a interface que posúe a ruta predeterminada, o resolutor que usa cada nome, o patrón que separa o segundo túnel e o resultado dunha petición por rede tras un reinicio. Calquera cousa menos é unha configuración que funciona por casualidade hoxe.