Dois clientes VPN, uma tabela de rotas: quem ganha a rota padrão

Parece que dois clientes VPN brigam pelo mesmo socket, e a correção óbvia deve ser desinstalar um. Na prática, eles raramente tocam o mesmo socket. Cada conexão reescreve a tabela de rotas do sistema operacional, e um perfil de túnel completo reivindica a rota padrão. Quem se conectou por último costuma vencer, e é por isso que o sintoma parece mudar de cliente.

O conflito vive na tabela de rotas

Um adaptador virtual mais uma rota padrão é como um túnel completo captura o tráfego. Quando o segundo cliente instala a própria rota padrão, a entrada mais antiga é substituída ou rebaixada pela métrica, e cada destino agora passa pelo túnel mais novo. O primeiro cliente continua conectado e ainda mostra um ícone verde, então a interface está ativa enquanto o caminho desapareceu. É essa separação entre o estado da conexão e o estado do roteamento que torna o comportamento confuso.

Os clientes são editores de uma tabela compartilhada. Saber qual edição aconteceu por último explica quase todos os sintomas.

Leia qual túnel é dono do caminho atual

Verifique a decisão real em vez de confiar no cliente que informa estar conectado. Pergunte ao sistema qual interface levaria um destino específico.

ip route get 10.20.0.5
route print -4

O primeiro comando nomeia a interface e o endereço de origem para um destino, e essa é exatamente a pergunta que lhe importa. O despejo de rotas mostra no Windows as entradas padrão concorrentes e suas métricas, então você vê qual vence agora. Execute a consulta para um host de cada rede remota, porque um destino pode estar correto enquanto a outra rede é inalcançável. Se a resposta apontar o túnel errado, reconectar não ajudará; a política de rotas precisa mudar.

Impeça o segundo cliente de reivindicar tudo

Um cliente deve ser dono da rota padrão, e o outro deve levar apenas os próprios prefixos. OpenVPN os clientes podem recusar o que o servidor empurra.

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

route-nopull ignora cada rota empurrada, enquanto pull-filter ignore "redirect-gateway" descarta apenas a diretiva da rota padrão e mantém o DNS e as outras opções empurradas. Escolha entre os dois conforme quanto da configuração do servidor você ainda quer, e depois acrescente os prefixos específicos de que a segunda rede precisa. Lembre-se do DNS, porque um resolvedor empurrado por um túnel que não leva as consultas não devolve nada. Teste um host conhecido em cada rede e confirme o endereço de origem que o lado remoto vê.

Sub-redes sobrepostas não podem ser contornadas

Quando as duas redes publicam o mesmo prefixo, o kernel mantém uma entrada para dois lugares diferentes e precisa escolher. Uma rota de host não pode inventar a distinção que falta, e um ajuste de métrica também não. Renumere um lado, ou faça o administrador traduzir a faixa remota para que os prefixos difiram. Verifique as sub-redes reais antes de culpar os clientes, porque o padrão 192.168.1.0/24 de um roteador doméstico colide com uma faixa de escritório mais vezes do que se espera. Anote as duas faixas no ticket para que a próxima mudança não recrie a sobreposição.

Separe também dois objetivos: alcançar as duas redes é um problema de roteamento, enquanto encadear túneis por privacidade é outro projeto, com um operador extra no caminho. Não use um para resolver o outro.