Split tunneling por aplicação ou por destino: qual escolher

O split tunneling por aplicação e por destino não são dois ajustes para a mesma tarefa. Um pergunta qual processo está a enviar um pacote; o outro pergunta para onde esse pacote vai. Uma regra criada para a primeira pergunta falha em silêncio quando o tráfego vem de um processo auxiliar, e uma regra criada para a segunda falha quando um nome de anfitrião resolve para um endereço que nunca listou. Escolha o objeto que corresponde ao requisito e comprove-o com dois pacotes de teste: um que deve usar o túnel e outro que não deve.

As duas regras atuam em camadas diferentes

Uma regra de aplicação é aplicada acima da camada de rede, contra a identidade que o sistema operativo atribui ao emissor. No Android é o UID por trás de um pacote, e o serviço VPN decide por UID se o tráfego entra no túnel. Nada é perguntado sobre o destino, pelo que a aplicação escolhida pode alcançar tudo e nenhuma outra aplicação pode alcançar a rede interna.

Uma regra de destino é aplicada ao próprio pacote. A interface do túnel possui um conjunto de prefixos, a tabela de rotas envia para lá o tráfego correspondente e o processo emissor é irrelevante. Por isso uma regra de destino cobre um serviço, uma impressora ou uma tarefa em lote que ninguém se lembrou de listar, e por isso não pode ser expressa como exatamente este programa numa plataforma cujo cliente nunca olha para o processo.

As regras de aplicação servem clientes móveis e agentes geridos

O Android expõe a escolha diretamente: VpnService.Builder.addAllowedApplication() e addDisallowedApplication() recebem nomes de pacotes e aplicam a decisão por UID, como descrito no guia do programador de VPN do Android. O iOS tem um equivalente através de regras VPN por aplicação baseadas em identificadores de pacote, normalmente distribuídas por um perfil MDM em vez de escritas à mão.

Os clientes de ambiente de trabalho são o ponto fraco. A maioria dos clientes VPN de Windows e macOS encaminha por destino e não oferece qualquer seletor por processo, porque o controlador do túnel vê pacotes, não processos. Se o seu plano depende de encaminhar uma só aplicação num portátil, verifique as capacidades reais do cliente antes de desenhar em torno disso; pode estar a escolher entre uma lista de destinos e uma segunda máquina.

Um corolário que as pessoas perdem: nessas plataformas não pode imitar uma regra de aplicação com rotas. Acrescentar uma rota de anfitrião para o servidor da aplicação encaminha o tráfego de todos para esse servidor, incluindo o navegador e o atualizador.

As regras de destino servem listas de subredes e alcance de sites

O WireGuard torna o modelo explícito. AllowedIPs é encaminhamento por chave criptográfica: um pacote interno cujo destino cai na lista de um par é cifrado para esse par, e tudo o resto sai sem cifra pelo caminho normal. Não há processo a nomear nem ambiguidade sobre o que está incluído.

O OpenVPN chega ao mesmo ponto através da tabela de rotas empurrada. route-nopull impede o servidor de ditar rotas, após o que uma route 10.20.0.0 255.255.0.0 vpn_gateway do lado do cliente cobre exatamente o prefixo do escritório. O IPv6 é uma instrução separada em cada um destes clientes, e esquecê-lo é a forma mais comum de escapar em torno de um split IPv4 com bom aspeto.

Um nome de anfitrião não é uma rota. Se o perfil oferece um campo de domínio, trate-o como um nome que o cliente resolve uma vez, não como um intervalo de endereços permanente; as redes de distribuição de conteúdo e os balanceadores de carga darão endereços diferentes amanhã.

Onde ambos os modelos quebram: auxiliares, serviços partilhados, resolvedores

Os processos auxiliares quebram as regras de aplicação de uma forma que parece uma falha do servidor. O atualizador de um navegador, um relator de falhas, um serviço de sincronização a correr como SYSTEM e uma WebView embebida noutro pacote são identidades separadas, pelo que encaminhar o navegador pode deixar o pedido real fora do túnel. O inverso é igualmente confuso: uma aplicação excluída que chama uma biblioteca partilhada dentro de um processo encaminhado continua a ter o seu tráfego no túnel.

As regras de destino quebram nos serviços partilhados e nos nomes. As partilhas de ficheiros, as impressoras, o DNS interno e o servidor de licenças vivem em endereços, pelo que um túnel de uma só aplicação dá acesso ao navegador enquanto a unidade mapeada fica morta. Essa diferença de cobertura não é um erro de nenhum dos modelos, mas é a razão pela qual um túnel de uma só aplicação produz tantas vezes que a VPN está ligada e a partilha desapareceu.

Os resolvedores atravessam ambos. Se o cliente define servidores DNS internos mas o sistema operativo usa DNS sobre HTTPS para um resolvedor público, a resposta vem de fora do túnel e a regra de destino pode nunca corresponder. Verifique que resolvedor respondeu realmente antes de concluir que a regra está errada, e confirme do lado do cliente se instalou o resolvedor do túnel. Um split que deixa o DNS fora do túnel parece perfeito na tabela de rotas e ainda assim falha em todos os nomes internos.

Procedimento: escolher, aplicar, verificar

Comece pelo requisito, não pelo menu. Se o objetivo é que só esta aplicação possa usar o túnel, precisa de regras de aplicação e de uma plataforma que as suporte. Se o objetivo é que estas redes sejam alcançáveis através do túnel, precisa de prefixos. Se a resposta for ambas, implemente-as como dois controlos separados e anote qual é responsável por que falha.

Aplique a forma mais estreita que conseguir expressar e depois verifique perguntando à tabela de rotas em vez de ao ícone de estado do cliente:

ip route get 10.20.30.40
ip -6 route get 2001:db8:10::40
wg show wg0 allowed-ips
Get-NetRoute -DestinationPrefix 10.20.0.0/16
Find-NetRoute -RemoteIPAddress 10.20.30.40

As duas primeiras linhas nomeiam a interface que um destino real usaria; wg show imprime a lista de prefixos configurada; no Windows, Find-NetRoute responde à mesma pergunta que a pilha responderá quando o pacote for enviado. Se a interface for o túnel, a regra correspondeu.

Depois teste um segundo pacote que deveria ser excluído, de outra aplicação, para o mesmo destino. Registe no ticket a versão do cliente, o tipo de regra, a lista de prefixos ou de pacotes e os dois resultados observados. É esse par de resultados que diz ao engenheiro seguinte se a política está mal configurada ou se o tráfego nunca lhe pertenceu.