Dante SOCKS sobre VPN: túnel completo versus roteamento por origem

Você quer que o tráfego do proxy SOCKS saia pela VPN enquanto o resto do host mantém seu caminho normal. Dois projetos fazem isso, e diferem no que quebra quando algo dá errado. Um empurra uma rota padrão para dentro do túnel e depois a contorna; o outro deixa a tabela principal em paz e envia um único endereço de origem para uma segunda tabela. O segundo é mais limpo, e tem as suas próprias armadilhas.

Dois projetos, dois raios de dano diferentes

O projeto de túnel completo é o que a maioria dos clientes VPN faz por padrão: substituir a rota padrão para que tudo siga o túnel e depois excluir o que não deveria. É fácil de raciocinar e difícil de manter estreito, porque cada serviço local que você adiciona herda o túnel até você excluí-lo. O modo de falha é amplo, pois uma única rota errada leva consigo a conectividade do próprio host.

O projeto de seleção por origem vai na direção oposta. A tabela principal fica como estava, e uma regra de política envia os pacotes de um endereço local específico para uma tabela com uma rota padrão pelo túnel. Nada mais muda, o que significa que o raio de dano é um endereço.

Essa estreiteza também é a restrição: o projeto só funciona se os pacotes de saída do proxy realmente carregarem esse endereço.

O que a configuração external do Dante faz

A configuração external escolhe os endereços que o proxy usa para as conexões de saída; ela não mexe na política de roteamento do kernel. É essa separação que torna o segundo projeto possível, e também é onde as pessoas leem a documentação errado. Apontar external para um endereço do túnel faz o proxy originar suas conexões a partir desse endereço, e a tabela de roteamento decide então para onde vão esses pacotes.

O listener é uma questão separada. Mantenha internal restrito aos clientes que deveriam usar o proxy, exija autenticação e feche a porta com um firewall, porque um listener aberto não é uma característica da saída por VPN.

Confirme que o endereço configurado pertence mesmo ao túnel dentro do espaço de nomes de rede do proxy.

Construir a tabela de seleção por origem

Para um endereço TUN de 10.90.0.2/24 com um par alcançável em 10.90.0.1, e um número de tabela que nada mais usa, a disposição é esta:

ip -4 route add table 100 10.90.0.0/24 dev tun0 src 10.90.0.2
ip -4 route add table 100 default via 10.90.0.1 dev tun0 metric 10
ip -4 route add table 100 unreachable default metric 32760
ip -4 rule add priority 1000 from 10.90.0.2/32 lookup 100

A rota inalcançável é a parte que as pessoas pulam. Sem ela, uma tabela cuja rota de túnel desaparece cai na rota padrão comum e o proxy sai silenciosamente pela WAN. Com ela, a consulta falha, o que é uma falha visível em vez de um vazamento silencioso. A prioridade da regra também precisa ficar à frente de qualquer outra coisa que corresponda a essa origem.

Estes valores descrevem uma topologia. Os pares ponto a ponto, o endereçamento net30 e os clientes que distribuem um prefixo diferente precisam das suas próprias rotas, então copie a forma, não os endereços.

Onde a regra de origem vaza

Uma regra que corresponde a um endereço de origem afeta todo processo que o usa, não apenas o proxy. Se outro daemon vincula o mesmo endereço, o tráfego dele também pega o túnel, e a falha vai parecer um problema de um serviço não relacionado. Dê ao proxy um endereço que nada mais usa, ou aceite que o escopo é o endereço e não o processo.

DNS é o outro vazamento. Um socket de resolução não usa necessariamente a origem de dados de saída do proxy, então as consultas de nomes ainda podem sair pela WAN. Teste a resolução separadamente do estabelecimento da conexão e decida se esse resultado é aceitável.

IPv6 precisa das suas próprias regras e rotas, porque uma disposição IPv4 não prova nada sobre ele.

Escolha pela falha que você consegue tolerar

Escolha o túnel completo quando o host deve ser protegido como um todo e você consegue manter a lista de exclusões. Escolha o roteamento por origem quando o host precisa manter o seu próprio caminho e apenas um serviço deve ser redirecionado. Ambos são legítimos; o erro é escolher um e depois testá-lo como se fosse o outro.

Qualquer que seja a escolha, verifique dos dois lados: um pedido através do proxy e um pedido direto a partir do host, com o endereço de saída observado registrado para cada um.

Se o túnel cair, decida de antemão se o proxy deve falhar ou recuar, e deixe a tabela de roteamento expressar essa decisão.