Dois clientes VPN ao mesmo tempo: quem ganha a rota padrão?

Executar dois clientes VPN ao mesmo tempo é uma discussão de roteamento, não um ajuste de privacidade. O túnel que possui a rota mais específica recebe o tráfego, e o outro permanece conectado mas ocioso. O gateway corporativo então vê uma conexão chegando da saída pessoal, enquanto o cliente corporativo na sua máquina continua vendo cada adaptador. Decidir qual desses dois fatos importa é o exercício inteiro.

A tabela de rotas escolhe um único vencedor

Capture a tabela antes e depois de o cliente corporativo iniciar, e leia a coluna de interface em vez de apenas o destino. Uma rota padrão simples do túnel externo é fácil de deslocar, porque um par /1 é mais específico que /0. O par literal 0.0.0.0/1 e 128.0.0.0/1 cobre todo o espaço IPv4 em duas metades e vence qualquer rota padrão única. Uma vez instalado, o túnel externo continua aparecendo conectado e não transporta nada.

ip route show default
ip route show | grep -E '^(0.0.0.0/1|128.0.0.0/1)'

O roteamento por política pode substituir completamente a tabela principal, então leia tanto as regras quanto as rotas. Uma regra que envia o tráfego marcado para outra tabela vence antes de a tabela principal ser consultada. É assim que uma aplicação pode ficar no link físico enquanto todo o resto usa o túnel.

ip rule show

O Windows decide isso com métricas

No Windows, o vencedor é a rota com a menor métrica para o destino, e dois clientes podem ambos instalar uma rota padrão com métricas diferentes. Leia a tabela e a configuração da interface juntas, porque o adaptador com a métrica mais baixa nem sempre é o que você espera. Um cliente que também define uma métrica de interface pode mover a rota padrão sem adicionar uma única rota. O adaptador que perde continua ativo e simplesmente não recebe nada.

route print -4
Get-NetIPConfiguration | Select-Object InterfaceAlias, IPv4DefaultGateway

Compare as duas saídas e nomeie a interface que possui 0.0.0.0/0. Se ambos os clientes a reivindicam, a métrica decide, e é por isso que um teste de ordem de conexão pode parecer inconsistente entre máquinas. Se nenhuma das saídas mostrar um gateway padrão, o cliente não está rodando em túnel completo e o argumento da cadeia é irrelevante.

Dois observadores, duas visões diferentes

O gateway remoto vê uma conexão chegando da saída externa mais tudo o que o cliente encaminha para o seu túnel. O cliente local vê adaptadores, rotas e a existência de outro túnel, porque é executado com privilégios para criá-los. Separar essas visões é o ponto; afirmar que o cliente não pode perceber não é.

Suponha que o cliente possa enumerar o que quiser, e planeje para a visão do gateway. Um projeto que depende de o cliente permanecer cego está a uma atualização de quebrar.

DNS e IPv6 são onde a cadeia vaza

O DNS segue a configuração de resolvedor que vencer, e essa não é necessariamente o caminho que os pacotes percorrem. Um resolvedor corporativo alcançado pelo túnel corporativo é coerente com o projeto; um resolvedor local alcançado fora dele não é, e expõe nomes que o túnel deveria esconder. IPv6 é o segundo vazamento: um host de pilha dupla continua usando IPv6 para destinos que o túnel só transporta por IPv4. Verifique as famílias separadamente, porque um túnel só de IPv4 não diz nada sobre rotas ou resolvedores IPv6.

ip -6 route show default
resolvectl status | grep -A2 'DNS Servers'

Corrija o resolvedor e a rota IPv6 deliberadamente em vez de empilhar um segundo túnel em cima. A encapsulação dupla também custa MTU, então uma MTU interna menor é a primeira coisa a tentar quando as páginas travam depois que a cadeia sobe. Um resolvedor que responde rápido não é prova de que seja o correto.