UDP através da porta SOCKS do Tor: o que não passa

Apontar um aplicativo para uma porta SOCKS funciona para um navegador e falha para um jogo, e o motivo não é a configuração. O SOCKS5 define vários comandos, e uma implementação é livre de suportar apenas alguns deles; a interface do Tor aceita conexões de fluxo e resolução de nomes, não o encaminhamento arbitrário de datagramas. Um cliente que envia UDP e espera que o proxy o encaminhe pede um comando que o servidor não implementa. O guia abaixo verifica isso em poucos minutos e depois escolhe um transporte que realmente possa funcionar.

Verifique o que o aplicativo realmente envia

Comece identificando o transporte, e não o nome do protocolo. Um cliente de voz pode entrar por HTTPS e depois levar a mídia por UDP; um jogo pode autenticar por TCP e jogar por UDP; uma transferência de arquivos pode usar TCP para controle e UDP para descoberta. Os dois primeiros comportamentos parecem idênticos até o login dar certo e a chamada continuar falhando, por isso «conectou» não é prova de que todo o aplicativo funciona. Alguns clientes também voltam de UDP para TCP por conta própria, o que faz uma sessão que funciona em parte parecer uma rede instável em vez de um transporte bloqueado.

Anote a porta de destino e o transporte da parte que falha. Essa única linha decide se um proxy pode ajudar.

O que a interface SOCKS do Tor aceitará

O Tor implementa o comando SOCKS5 CONNECT para conexões de fluxo e comandos de extensão para resolver nomes, por isso um navegador funciona através dela sem alterações. O UDP ASSOCIATE, o comando que permitiria a um cliente entregar datagramas ao proxy para encaminhamento, não faz parte do que o Tor oferece. A documentação das extensões está na especificação de extensões SOCKS do projeto, e é curta. A ausência de um comando para datagramas é deliberada: encaminhar UDP arbitrário daria à rede um papel de encaminhamento para o qual ela nunca foi projetada.

Esta é também a resposta para o WireGuard, que é UDP por concepção e não tem alternativa TCP. Não existe caminho suportado que aponte o WireGuard para uma porta SOCKS, e tudo que afirma o contrário é um invólucro com sua própria história de confiança e manutenção, não um recurso de qualquer uma das duas ferramentas.

OpenVPN é a exceção parcial, porque pode ser configurado para tunelar por TCP e entende uma opção de proxy SOCKS. Isso ainda exige um servidor configurado para TCP e uma decisão consciente sobre as consequências de desempenho e de impressão digital, então é uma escolha de projeto e não uma correção de compatibilidade.

Execute a verificação em ordem

Confirme primeiro que o proxy funciona para fluxos, para que uma falha posterior não seja atribuída a uma porta inalcançável. Depois confirme o tráfego do próprio aplicativo, e observe quais sockets ele realmente abre.

curl --socks5-hostname 127.0.0.1:9050 -sS https://check.torproject.org/api/ip
ss -tupn | grep 9050
ss -aun | grep -E ':(3478|5060|27015)\b'

Um primeiro comando bem-sucedido e um fluxo estabelecido na segunda linha mostram que o caminho do proxy funciona como projetado. O terceiro comando procura sockets de datagramas locais pertencentes ao aplicativo; se o cliente abrir um e enviar diretamente a um endereço remoto, nunca consultou o proxy e nenhum ajuste de proxy mudará isso. Se falhar já no primeiro passo, pare e conserte o caminho do proxy antes de investigar o aplicativo, porque duas falhas ao mesmo tempo produzem um relatório com o qual ninguém pode agir.

Reverta e escolha a ferramenta certa

Remova qualquer variável de ambiente de proxy ou configuração de proxy por aplicativo que apontasse o cliente UDP para a porta SOCKS; deixá-las no lugar torna os testes posteriores ambíguos. Restaure a configuração anterior de uma cópia, reinicie o aplicativo e confirme que o comportamento original volta para que a comparação seja limpa. Uma reversão que não é verificada é apenas a esperança de que o estado tenha mudado.

Para um transporte que deve continuar UDP, uma VPN costuma ser mais adequada: ela leva os pacotes do aplicativo sem exigir que ele fale um protocolo de proxy, ao custo de propriedades de anonimato completamente diferentes. Use cada ferramenta para o que ela documenta, e trate qualquer ponte entre elas como um sistema separado que precisa da própria revisão. Anote no relatório final qual camada leva qual transporte, para que a próxima pessoa não redescubra o mesmo limite com outro aplicativo.