Redsocks escuta no loopback, mas o tráfego VPN nunca chega

Um túnel sobe, o cliente consegue fazer ping ao gateway, e cada pedido web pelo caminho do proxy morre. O processo redsocks está a correr e a sua porta está à escuta, por isso o serviço parece saudável a partir do próprio gateway. O que falha é o passo de entrega: um pacote redirecionado do túnel não aterra no socket que iniciou. O endereço de ligação e o destino do redirecionamento têm de concordar, e normalmente só se verifica um deles.

Onde um pacote redirecionado aterra realmente

O proxy transparente num gateway usa REDIRECT na tabela nat em PREROUTING para reescrever o destino de uma ligação de entrada para uma porta local. O destino reescrito é um endereço local tal como é visto pela interface por onde o pacote chegou, e não o endereço de loopback de um processo iniciado noutro lugar. Um ouvinte ligado apenas a 127.0.0.1 aceita ligações que já eram locais no anfitrião, e é exatamente este o caso que continua a funcionar enquanto o tráfego do túnel falha. O loopback do próprio cliente é um terceiro endereço e nunca é o destino da regra do gateway.

Por isso, antes de mexer nas credenciais da camada superior, estabeleça dois factos: para que endereço local a regra reescreve e a que endereço está ligado o socket do proxy.

Leia o ouvinte e a regra de redirecionamento em conjunto

Imprima a tabela de sockets e as regras nat na mesma passagem, porque uma regra que aponta para uma porta que ninguém possui parece idêntica a uma regra que aponta para o endereço errado. sudo ss -ltnp | grep redsocks mostra o endereço de ligação e o processo proprietário. sudo iptables -t nat -S PREROUTING mostra o destino REDIRECT, e sudo iptables -t nat -L PREROUTING -v -n mostra se algo correspondeu a ele.

Um salto para uma cadeia de utilizador chamada REDSOCKS não alcança nada a menos que essa cadeia exista e transporte as exclusões previstas e a ação REDIRECT. Leia a cadeia para a qual salta com sudo iptables -t nat -S REDSOCKS em vez de assumir que o nome faz o trabalho.

Depois compare os dois valores. Se a regra redireciona para um endereço de gateway na porta 12345 e o ouvinte reporta 127.0.0.1:12345, a discrepância explica a falha sem qualquer diagnóstico adicional.

Ligue de forma estreita e depois limite o que o pode alcançar

A configuração de exemplo da camada superior coloca o ouvinte no loopback por uma boa razão: um proxy transparente aceita ligações em nome de quem o consiga alcançar. Mudar a ligação para 0.0.0.0 corrige a entrega e abre ao mesmo tempo a porta em todas as interfaces, o que é uma alteração de segurança, não uma reparação neutra. Prefira ligar ao endereço local específico que o redirecionamento visa, e mantenha a porta fechada nas interfaces não fidedignas. Se uma ligação mais ampla for inevitável, acrescente uma regra de firewall do anfitrião que permita apenas o intervalo de origem do túnel e o tráfego local do próprio gateway.

Abrir a porta na interface pública nunca é necessário para o tráfego VPN redirecionado, porque a ligação termina localmente após a reescrita. Não exponha o proxy à internet para fazer funcionar um redirecionamento local.

Prove-o com uma nova ligação de um cliente

Teste a partir de um cliente VPN real com uma ligação TCP nova, não a partir de uma shell no gateway. curl -sS -o /dev/null -w '%{http_code}\n' http://example.com no cliente exercita o caminho redirecionado de ponta a ponta.

Depois confirme que uma ligação direta ao ouvinte a partir de uma rede não fidedigna continua a ser recusada, e que a ligação ascendente do próprio proxy não é novamente capturada pela mesma regra. A captura recursiva manifesta-se como um proxy que se liga a si mesmo e nunca conclui um pedido. Acrescente o destino do proxy ao conjunto de exclusões, ou marque os seus pacotes de saída para que a cadeia os ignore.

Por fim, lembre-se do que este caminho não cobre. O redirecionamento TCP normal do redsocks não transforma UDP, QUIC ou DNS em tráfego SOCKS, e os destinos privados costumam exigir exclusões explícitas. Um teste local bem-sucedido prova apenas o caminho de loopback que nunca foi o problema.