Como o túnel dividido decide qual tráfego usa a VPN

O túnel dividido é uma política de roteamento expressa como um conjunto de regras, e o cliente é apenas o que as instala. A separação ocorre em dois lugares: regras de correspondência que escolhem um caminho para cada pacote, e vinculações que mantêm uma aplicação numa interface diga o que disser a tabela. Em qual mecanismo o seu cliente se baseia explica a maioria das surpresas que as pessoas relatam.

Uma política que você pode enunciar numa linha é testável. Uma política descrita como navegação mais rápida não é, e não lhe dirá qual regra mudar quando um pedido segue pelo caminho errado.

O cliente instala regras, o núcleo faz a escolha

Quando o túnel sobe, o cliente adiciona rotas e frequentemente regras de política à mesma tabela que as suas outras interfaces usam. Cada pacote então chega a uma busca que compara o seu destino com cada prefixo candidato e mantém a correspondência mais específica, enquanto a prioridade resolve empates entre regras que apontam para tabelas diferentes. Nada nessa busca sabe que o pacote veio de uma aba do navegador e não de uma tarefa de backup. A regra que vence é a que define o caminho, e você pode lê-la antes e depois da mudança.

Por isso um túnel dividido pode parecer arbitrário. Dois destinos numa mesma aplicação podem seguir caminhos diferentes só porque um prefixo é mais estreito que o outro.

A mesma escolha existe em cada plataforma, embora os nomes mudem. O Windows empurra a decisão para a sua plataforma de filtros, o Android expõe uma lista de permitidos por aplicação através do seu serviço VPN, e o macOS liga o túnel a um dispositivo que ainda obedece à tabela de roteamento. As notas de roteamento da Microsoft valem a leitura para o caso do Windows, e um guia escrito para uma plataforma raramente se transfere sem alterações para outra.

A vinculação por aplicação e os prefixos de destino são ferramentas diferentes

Uma política de destino pergunta para onde o pacote vai e consulta a tabela de rotas ou uma regra de política. Uma política por aplicação pergunta qual programa abriu o socket, e a plataforma mantém esse programa na interface do túnel mesmo quando uma rota mais específica aponta para outro lugar. A segunda é mais forte porque sobrevive a mudanças de tabela, mas cobre apenas os processos que a plataforma consegue atribuir. Um processo auxiliar, um navegador incorporado ou um serviço que abre a sua própria conexão pode não herdar a vinculação que você supôs.

Nenhuma das duas abordagens sobrevive a uma política baseada em nomes sem ajuda. Os endereços de sites grandes rodam entre redes de conteúdo, então fixar um nome de host a alguns prefixos produz uma regra que deixa de coincidir em silêncio. Uma política que precisa seguir nomes requer um componente ciente do resolvedor em vez de uma rota estática.

O DNS e o interruptor de segurança seguem as suas próprias regras

A resolução de nomes é uma decisão separada do roteamento de pacotes, e um túnel dividido normalmente quer dois resolvedores: o da empresa para nomes internos, o local para todo o resto. O cliente pode instalar configurações de DNS por interface, entregar as consultas a um resolvedor intermediário ou deixar o padrão do sistema intacto. Um navegador com o seu próprio resolvedor cifrado contorna as três disposições. Teste uma consulta em vez de presumir que o resolvedor seguiu a rota.

Um interruptor de segurança acrescenta um filtro por cima, e esse filtro nem sempre distingue uma exclusão deliberada de uma fuga acidental. Alguns clientes bloqueiam tudo fora do túnel enquanto outros permitem as exclusões que a política declara, então leia qual comportamento o seu implementa antes de confiar em qualquer um dos dois.

Verifique a divisão dos dois lados

Teste o caminho incluído e o caminho excluído separadamente, e julgue o resultado pelo nome da interface e não por um endereço público. Estes comandos pressupõem um host Linux com o dispositivo de túnel já levantado. Substitua 203.0.113.10 por um destino que a sua política encaminha para dentro, e 198.51.100.25 por um que ela envia para fora.

ip route get 203.0.113.10
ip route get 198.51.100.25
resolvectl query intranet.example.com
curl -s --interface tun0 https://example.com -o /dev/null -w '%{http_code}\n'

Leia as duas primeiras respostas juntas, porque a interface nomeada em cada uma mostra se a divisão colocou esse destino no túnel. A consulta ao resolvedor mostra qual servidor respondeu ao nome interno, e o último comando prova que o dispositivo de túnel consegue transportar um pedido. Uma falha na segunda linha enquanto a primeira tem sucesso significa que a política faz exatamente o que lhe foi dito.

Repita o conjunto após uma reconexão e após uma mudança de rede. A renovação do lease e a agitação das interfaces são onde uma divisão deixa de coincidir com a intenção para a qual foi construída, e uma saída guardada de cada execução torna o desvio evidente.