Roteamento por política versus SOCKS: qual camada faz realmente o proxy

Você adicionou uma rota por política que envia o tráfego de um cliente VPN para um host que executa um ouvinte SOCKS na porta 1080. Os pacotes chegam, o ouvinte não registra nada e a conexão fica pendurada. A rota não tem nada de errado: o próximo salto escolhe para onde vai um pacote, e SOCKS é uma conversa que o cliente precisa iniciar. Compare as três arquiteturas que as pessoas normalmente querem dizer ao enviar tráfego por um proxy, e fica claro qual peça falta na sua configuração.

O roteamento, o DNAT e o SOCKS mudam coisas diferentes

Uma rota por política reescreve uma decisão da camada 3. Duas linhas bastam para enviar o tráfego de um cliente a um próximo salto escolhido:

ip route add default via 10.50.0.2 table 101
ip rule add from 10.77.0.2 lookup 101

Depois disso, o núcleo entrega o pacote a 10.50.0.2 com o destino original ainda no cabeçalho IP. Se 10.50.0.2 for um roteador, ele encaminha o pacote. Se for um host com um daemon SOCKS na 1080, o pacote não está endereçado a nada que possa aceitá-lo, e o DNAT para a porta 1080 também não ajuda, porque um pacote traduzido ainda carrega a carga útil original da aplicação em vez de uma saudação SOCKS.

SOCKS5 começa com um byte de versão, uma lista de métodos, uma troca de autenticação e uma requisição que nomeia o destino. Isso são dados de aplicação. Nem uma entrada de roteamento nem um alvo do netfilter os gera, e essa é a comparação em uma linha: o roteamento escolhe um caminho, o SOCKS pede a um servidor que faça uma segunda conexão.

Caso um: a aplicação consegue falar SOCKS sozinha

Quando o programa tem uma definição de proxy, esse é o caminho mais curto e não exige mudança no núcleo. Aponte-o para o ouvinte, forneça credenciais se o servidor pedir, e decida se os nomes são resolvidos localmente ou passados ao proxy. Com curl são sinalizadores diferentes, e a diferença importa quando o destino só é resolvido pelo lado do proxy:

curl --socks5 10.50.0.2:1080 https://docs.example.com
curl --socks5-hostname 10.50.0.2:1080 https://internal.example.com

Aplicações que ignoram variáveis de ambiente de proxy, ou que abrem sockets brutos, não podem ser ajudadas assim. Navegadores e a maioria das ferramentas HTTP estão bem; um cliente de jogo, um daemon de correio ou um binário qualquer de fornecedor normalmente não. A fronteira é por aplicação e por protocolo, por isso esta opção é excelente para testes e fraca como resposta para o VPN inteiro.

Caso dois: um adaptador que converte fluxos IP em sessões de proxy

Para programas que não conseguem falar SOCKS, a conversão precisa acontecer em algo que encerra o tráfego IP e abre sessões de proxy em nome deles. Esse componente possui uma interface de túnel, aceita os fluxos selecionados pelo roteamento por política, realiza o aperto de mão SOCKS para cada um e reconstrói as respostas. A rota direciona o tráfego para ele; o adaptador é o que cria a sessão.

Leia a documentação antes de confiar a ele uma sub-rede inteira. Muitos adaptadores transportam bem TCP e só tratam UDP por meio de uma associação UDP de SOCKS5, e nenhum deles transforma ICMP em tráfego de proxy, então um ping bem-sucedido não diz nada sobre o caminho do proxy. O DNS é a outra armadilha: se o adaptador resolve nomes localmente, registros apenas internos são resolvidos para a resposta errada, ou para nada.

A prevenção de laços é o detalhe operacional que morde. As próprias conexões do adaptador ao servidor SOCKS não podem ser roteadas de volta para o adaptador, então o tráfego dele precisa de uma exceção na regra ou de um endereço de origem dedicado. Erre nisso e a sessão de proxy tentará fazer proxy de si mesma.

Caso três: o host é na verdade um gateway roteado

Às vezes a configuração que funciona não contém SOCKS nenhum. O host remoto encaminha pacotes ou aplica NAT a eles, e a regra baseada na origem simplesmente o escolhe como saída. Esse desenho é legítimo, e explica por que uma configuração copiada funciona em uma rede e falha em outra: a regra é idêntica, a peça que falta é um serviço de encaminhamento do outro lado.

Os três casos se separam rápido. Verifique o que está realmente escutando e depois olhe os primeiros bytes que chegam ao host:

ss -ltnp 'sport = :1080'
tcpdump -ni eth0 -X 'tcp port 1080'

O primeiro byte de carga útil de um cliente SOCKS real é 0x05, a versão da saudação. Se a captura mostrar dados originais da aplicação em vez disso, nenhum daemon SOCKS responderá, porque a negociação nunca começou. Se nada escuta na 1080, o host é um gateway, e a pergunta passa a ser se ele encaminha e se existe um caminho de volta.

Escolha a camada com quatro perguntas

O programa tem uma definição de proxy? Use-a e pare aí. O tráfego inclui UDP ou ICMP que precisam sobreviver? Só um gateway roteado ou com NAT transporta ICMP, e UDP exige uma associação SOCKS5 que ambos os lados suportem. Todo processo da máquina precisa ser coberto, inclusive os que você não consegue configurar? Então você precisa de um adaptador que possua a interface e encerre fluxos. Você também consegue assumir o roteamento, o DNS e as exceções de prevenção de laços dele? Se não, o gateway simples custará menos para operar.

Uma distinção vale a pena manter clara. A própria opção socks-proxy de um cliente VPN descreve como a conexão do túnel externo chega ao seu servidor, e não diz nada sobre converter os fluxos internos do cliente. As duas são confundidas constantemente no mesmo ticket. Decida qual relação você precisa antes de tocar em uma rota.