Dois clientes VPN num só desktop: o que colide e o que funciona

O seu segundo cliente liga-se, os recursos do primeiro deixam de resolver e o ticket diz que a VPN do trabalho estragou a pessoal. Nada está avariado no sentido de uma falha: ambos os clientes fizeram aquilo para que foram concebidos, e a máquina só tem uma tabela de encaminhamento. A colisão é por quatro recursos que cada cliente assume possuir. Percorra-os por ordem e a correção passa normalmente a ser uma decisão de projeto em vez de uma reparação.

Passo 1: descubra que cliente controla a saída

Leia a decisão de saída atual antes de mudar seja o que for. A consulta de rota para um endereço público diz-lhe que interface e que salto seguinte um pacote usaria agora mesmo, e essa é a resposta a quem ganhou. Compare-a com os nomes de interface criados pelos clientes, que normalmente transportam o nome do produto ou do protocolo. Se a consulta apontar para o túnel que não esperava, já encontrou a colisão.

ip route get 1.1.1.1
ip route show default
route print

Alguns clientes não substituem de todo a rota predefinida; acrescentam duas metades, uma para a metade inferior do espaço de endereços e outra para a superior, que juntas cobrem tudo. Isso deixa visível a rota predefinida original e faz uma reparação manual parecer correta, enquanto o tráfego continua a sair pelo túnel. Leia a métrica e o comprimento do prefixo, não apenas a presença de uma entrada predefinida.

Pare se ambos os clientes reclamarem o mesmo prefixo com a mesma métrica. O núcleo escolherá um, e o outro aparecerá ligado sem transportar nada.

Passo 2: verifique o resolvedor e os prefixos sobrepostos

O DNS é a segunda colisão e produz um sintoma distintivo: os nomes falham enquanto os endereços funcionam. Cada cliente impõe o seu próprio resolvedor, e o último a escrever ganha para as consultas seguintes. Pergunte ao serviço de resolução o que usa por ligação em vez de ler a página de definições do cliente.

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

Depois compare os prefixos privados usados pelas duas redes. Se ambos os lados atribuírem do mesmo intervalo, nenhum arranjo do lado do cliente o resolve, porque a máquina não consegue dizer que destino 10.0.0.0/8 pertence a que túnel. Um dos lados tem de ser renumerado ou traduzido, e isso é uma conversa com os donos da rede, não uma alteração de configuração. A sobreposição é a única colisão em que a resposta honesta é que o projeto tem de mudar.

Pare aqui se os prefixos se sobrepuserem. Tudo o resto nesta lista assume que não se sobrepõem.

Passo 3: escolha um padrão de separação que resista

Os padrões fiáveis evitam executar dois clientes contra a mesma tabela de encaminhamento. Um único cliente com uma política de túnel dividido que chega às duas redes privadas é o mais simples, desde que os destinos não se sobreponham e o dono da política concorde. Uma máquina virtual ou um espaço de nomes de rede é o passo seguinte, porque cada um recebe a sua própria tabela e o seu próprio 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/

Um espaço de nomes dá a mesma separação que uma máquina virtual sem o segundo sistema operativo, mas tem arestas: o dispositivo do túnel tem de ser movido para lá e a aplicação tem de ser iniciada dentro dele. Um dispositivo físico separado é muitas vezes a opção menos surpreendente para uma VPN pessoal ao lado de um cliente de trabalho gerido. Empilhar um túnel dentro de outro não é um padrão de separação; o ponto final interior tem de continuar alcançável através do túnel exterior, e a disposição acrescenta por cima problemas de MTU e latência.

Escolha um padrão e anote porquê. Misturar um espaço de nomes para uma aplicação com um túnel dividido para o resto recria a colisão original numa forma mais difícil de depurar.

Passo 4: verifique as duas redes a partir da mesma sessão

Teste um recurso em cada rede privada a partir do ambiente onde a aplicação corre de facto, não a partir da sua shell se a aplicação corre dentro de um espaço de nomes. Verifique a interface de saída, o endereço resolvido e o código de resposta em conjunto, porque um sucesso num dos três pode esconder uma falha nos outros. Repita após um reinício, pois a ordem em que os clientes arrancam decide quem ganha. É essa ordem que as pessoas se esquecem de registar.

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

Registe as versões dos clientes, as interfaces, o estado do resolvedor e os prefixos de cada rede. Quando um cliente é atualizado e muda o seu comportamento de encaminhamento, esse registo é a diferença entre uma correção de cinco minutos e uma reconstrução. A pessoa seguinte não vai partilhar a sua memória sobre qual túnel subiu primeiro.

A lista está completa quando consegue nomear a interface que possui a rota predefinida, o resolvedor que cada nome usa, o padrão que separa o segundo túnel e o resultado de um pedido por rede após um reinício. Qualquer coisa menos é uma configuração que funciona por acaso hoje.