Sem interruptor «excluir esta aplicação»: dê ao processo a sua própria origem

Um programa deveria usar a ligação normal enquanto tudo o resto fica no túnel, e o cliente não tem nenhum interruptor para isso. Também não há nenhum menu escondido para encontrar. Uma rota é escolhida a partir de campos dentro do pacote, e o pacote transporta endereços e portas em vez da identidade do processo que o criou, por isso uma exclusão tem de ser expressa num desses campos. Siga um pacote uma vez e as opções disponíveis deixam de ser misteriosas.

Porque é que o cliente não o pode oferecer

O encaminhamento por destino compara o endereço de destino com prefixos e conserva a correspondência mais longa. Nesse momento todos os pacotes parecem iguais, seja o que for que os produziu. O encaminhamento por política de origem alarga a comparação ao endereço de origem, e é esse o gancho que qualquer solução prática usa: mude a origem e outra tabela torna-se elegível.

As portas não ajudam. Uma exclusão por porta teria de ser avaliada antes da consulta de destino, e a porta não desempenha qualquer papel nessa decisão. Tudo o que é anunciado como exclusão baseada na porta exclui na realidade por outro campo e descreve-o de forma frouxa.

O encaminhamento real por aplicação existe onde a plataforma acrescentou maquinaria para isso, como as chamadas de filtro no Windows ou a ligação do serviço VPN no Android. Uma instância de ambiente de trabalho do OpenVPN não traz nada disso, e nenhuma opção de configuração o inventa.

Linux: marque o processo e depois encaminhe a marca

A abordagem mais limpa liga a decisão ao processo que possui o socket. A correspondência owner funciona para o tráfego gerado localmente na cadeia OUTPUT, por isso uma marca aplicada aí pode selecionar uma tabela separada:

iptables -t mangle -A OUTPUT -m owner --uid-owner 1001 -j MARK --set-mark 0x1
ip rule add fwmark 0x1 table 200
ip route add 192.168.1.0/24 dev eth0 src 192.168.1.0 table 200
ip route add default via 192.168.1.1 dev eth0 table 200

Os pacotes do utilizador 1001 consultam então a tabela 200 e saem pelo gateway habitual, enquanto a tabela principal continua a enviar tudo o resto para o túnel. A correspondência owner aplica-se apenas a pacotes gerados localmente, que é exatamente o tráfego que aqui importa, e não consegue classificar pacotes reencaminhados para outro anfitrião. Verifique com as ferramentas e não com a intenção: ss -tnp mostra o endereço local e o processo proprietário das ligações estabelecidas, e ip route get 1.1.1.1 mark 0x1 mostra qual tabela a marca seleciona.

Um espaço de nomes de rede é a resposta mais sólida para um programa autónomo, porque cada socket criado lá dentro fica ligado a ele por construção, pelo que os processos auxiliares e as ligações filhas herdam o comportamento sem serem classificados de todo. O custo é de canalização: um par veth, um endereço em cada extremidade e uma rota predefinida dentro do espaço de nomes que aponta de volta para o anfitrião.

ip netns add novpn
ip link add veth-host type veth peer name veth-ns
ip link set veth-ns netns novpn
ip addr add 10.200.0.1/24 dev veth-host
ip netns exec novpn ip addr add 10.200.0.2/24 dev veth-ns
ip netns exec novpn ip route add default via 10.200.0.1

Windows: o destino continua a decidir

O Windows escolhe a interface de saída a partir do destino, por isso um programa que quer outro caminho tem de mudar algo que a pilha consulta antes dessa escolha. O ForceBindIP cobre a primeira metade: inicia um programa com os sockets já ligados a um endereço local que indique. Só isso não muda a interface por onde o pacote sai, porque o destino continua a selecionar a rota. Ligue uma origem num portátil cuja rota predefinida aponta para o túnel e o pacote entra no túnel mesmo assim.

O sintoma tem uma forma legível assim que se conhece. Vale para um endereço de LAN que a interface escolhida alcança diretamente e falha para tudo o que, na internet, tenha uma rota a apontar para o túnel. Também parece funcionar até o programa entregar trabalho a um auxiliar, porque a um auxiliar que abre o seu próprio socket nunca lhe foi dito nada sobre a ligação.

Mova a decisão quando um só processo é a unidade errada

Se o requisito real é um dispositivo e não um programa, coloque-o no seu próprio SSID ou VLAN e deixe o router decidir: essa origem segue o caminho normal enquanto as outras usam o túnel. Uma máquina de gateway dedicada é o outro desenho honesto: mantém a VPN e só recebe os destinos que o router lhe envia. Numa VLAN a política cobre cada fluxo que o dispositivo abre, incluindo os processos auxiliares que quebraram a abordagem do Windows. A troca é de âmbito: dois programas nesse dispositivo já não podem ser tratados de forma diferente.

Ambas são políticas de origem ou de destino com um âmbito que se pode dizer numa frase. Nenhuma é por aplicação, e um desenho que se vende como por aplicação falha a primeira vez que o programa delega o seu trabalho a um segundo processo.