Destinos originais no encaminhamento transparente de TCP para SOCKS

Um firewall pode mudar onde uma conexão TCP termina. Mas não pode, apenas com essa mudança, ensinar a aplicação de origem a falar SOCKS.

Um servidor SOCKS comum espera uma negociação que descreva o destino solicitado. Uma aplicação que não conhece o proxy envia, em vez disso, seus próprios bytes de protocolo imediatamente. Redirecione esses bytes direto para um ouvinte SOCKS e os dois lados vão discordar sobre a primeira mensagem.

O componente que falta é um tradutor

Um componente transparente de TCP para proxy fica entre essas interfaces. Ele descobre o destino que a aplicação pediu originalmente, estabelece a sessão SOCKS ou HTTP CONNECT adequada e então repassa os dados da aplicação pelo fluxo resultante.

No seu caminho Linux iptables, o código do redsocks recupera o destino preservado usando SO_ORIGINAL_DST. Outros sistemas operacionais e métodos de redirecionamento usam mecanismos diferentes. Isso é uma propriedade do redirecionador e da configuração de rede, não um recurso de um cliente SOCKS comum.

A informação do destino original também explica por que mover uma regra de redirecionamento do host do proxy para um gateway não relacionado nem sempre é equivalente. O processo receptor precisa dos metadados exigidos pelo seu modo de interceptação. Um endereço reescrito em outro lugar talvez não forneça mais essa informação na forma esperada.

Mantenha explícito o escopo do tradutor. Uma conexão TCP redirecionada que funciona não comprova suporte a UDP arbitrário, ICMP ou a cada caminho de resolução. O protocolo do proxy a montante e a implementação do tradutor ainda definem as operações suportadas.

Quando uma configuração falha logo após a conexão, verifique a fronteira do protocolo antes de ampliar as regras de acesso. Um ouvinte SOCKS perfeitamente acessível pode rejeitar bytes que nunca foram uma solicitação SOCKS.