Por que um segundo túnel VPN quebra o primeiro?

Instalar um segundo cliente VPN para alcançar uma rede de cliente é o modo usual como isto começa, e o primeiro túnel apaga enquanto os dois clientes relatam sucesso. Cada cliente instalou uma rota padrão, a segunda era mais específica, e o núcleo agora segue essa rota para tudo, exceto a própria conexão externa do primeiro túnel. Nada travou e nenhum perfil está errado. Uma rota substituiu a outra, e a solução é decidir qual túnel deve possuir a rota padrão.

O sintoma: o segundo cliente vence em silêncio

OpenVPN: a opção redirect-gateway def1 não sobrescreve 0.0.0.0/0. Ela acrescenta 0.0.0.0/1 e 128.0.0.0/1: juntas cobrem todos os endereços IPv4, e cada prefixo vence uma rota padrão simples pelo comprimento. A rota padrão original fica na tabela e deixa de ser usada para o tráfego comum, e uma rota de host para o servidor VPN impede o túnel de capturar os próprios pacotes externos. Os dois clientes fazem isso, e o segundo apenas instala o seu par mais tarde.

Por isso o primeiro túnel parece morto em vez de desconectado. A interface está ativa, o canal de controle está vivo, e nenhum tráfego de aplicação chega mais a ele. A queixa inversa tem o mesmo push ausente: um telefone que se conecta mas não envia nada costuma falar com um servidor que nunca anunciou redirect-gateway, então o dispositivo mantém a própria rota padrão e só alcança o pool.

Tire um instantâneo das rotas antes e depois de o segundo cliente conectar. As duas meias rotas que aparecem na tabela são toda a mudança, e explicam as duas queixas. Nada mais na tabela precisa se mover para o sintoma aparecer. Por isso remover o segundo cliente restaura o primeiro na hora.

Leia qual túnel realmente vence

Não deduza o vencedor da ordem em que os clientes iniciaram nem do ícone na bandeja. Pergunte ao núcleo qual rota ele usaria para um destino fora das duas redes privadas, e leia a interface que retorna.

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

Os dois primeiros são a resposta do Linux e os dois últimos o equivalente do Windows. Execute-os com os dois túneis ativos, depois desconecte um e execute de novo. A diferença entre as duas saídas é o fato de que você precisa antes de escolher uma solução, e leva menos tempo do que ler o log de qualquer um dos clientes.

Anote o resultado, incluindo o nome da interface e o prefixo que coincidiu. Um ticket que diz que o segundo VPN quebrou o primeiro é uma descrição do sintoma, não uma afirmação de roteamento sobre a qual alguém possa agir. A consulta transforma isso num fato que o próximo engenheiro pode reproduzir com um comando.

Windows: impeça um perfil de possuir a rota padrão

O Windows guarda perfis salvos, e o cliente embutido permite que um dependa de outro para que o primeiro suba automaticamente quando o segundo disca. O perfil conectado mais recentemente tende a manter a rota padrão, então o dono prático é a última discagem e não a primeira. Dê a cada perfil as suas próprias rotas push e ative o split tunneling para o que não deve possuir a rota padrão.

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

O split tunneling muda isso: só os prefixos empurrados pelo servidor entram na tabela, o que deixa a rota padrão com o primeiro túnel. O desenho ainda falha se os dois servidores empurrarem uma rota padrão, porque aí a última conexão vence e nenhuma configuração do lado do cliente muda isso. Corrija o push do lado do servidor ou aceite um único dono.

Perfis acionados por aplicação são outra funcionalidade e vale conhecê-los: um perfil do Windows pode iniciar quando um executável nomeado arranca, com filtros de tráfego decidindo o que ele transporta. É uma configuração de perfil e não uma regra de firewall, e resolve um problema diferente do conflito de rota padrão.

Linux: mantenha o segundo túnel fora da tabela principal

Executar duas instâncias de openvpn --config numa mesma máquina coloca os dois clientes na mesma tabela, e três opções os separam com isolamento crescente. A mais leve é impedir o segundo cliente de editar a tabela por completo, com route-nopull e rotas explícitas, ou um script route-up que instale só o que você pretende. Então o segundo túnel carrega exatamente os prefixos que você nomeia e nada mais. Então você decide que prefixos vão aonde em vez de descobrir isso depois.

O roteamento por políticas é a opção intermediária. Uma regra seleciona uma tabela separada para um endereço de origem ou uma marca de firewall, e essa tabela carrega as rotas do segundo túnel. A filtragem de caminho reverso é a armadilha aqui, porque uma resposta que chega numa interface diferente da que a tabela escolheria é descartada, então verifique a configuração rp_filter antes de concluir que o túnel está quebrado.

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

Espaços de nomes de rede são a opção mais pesada e a mais limpa. Inicie o segundo cliente dentro de ip netns, dê a ele um par veth e entre nesse espaço de nomes para usá-lo. A interferência desaparece porque cada espaço de nomes tem as próprias tabelas em vez de compartilhar uma, o que vale a configuração extra quando os dois túneis precisam ficar ativos por semanas.

Por aplicação, e o encadeamento como problema separado

Às vezes só um programa deveria usar o segundo túnel. No Linux, o roteamento por políticas por usuário, cgroup ou porta alcança esse resultado, e um único destino pode ser fixado a uma interface sem tocar na rota padrão. Uma aplicação que fixa o próprio socket a uma interface nunca consulta a tabela de roteamento, então um lançador pode continuar usando o adaptador físico até que um endereço seja escolhido nas suas próprias configurações.

O encadeamento é uma operação diferente de executar dois túneis lado a lado. Encadear A sobre B significa que o endereço do servidor interno tem de ser alcançável de dentro do túnel externo. O cliente externo também não deve confundir os pacotes cifrados do cliente interno com um vazamento. Um cliente dentro de uma máquina virtual é a versão tosca mas confiável; os dois num único host exigem o trabalho de roteamento acima mais um caminho externo até o servidor interno que nunca entra no túnel interno.

Anote o dono da rota padrão, a lista de prefixos que cada túnel carrega e o caminho DNS. Esses três fatos transformam o próximo incidente numa consulta em vez de uma investigação.