UDP a través do porto SOCKS de Tor: o que non se transporta

Apuntar unha aplicación a un porto SOCKS funciona cun navegador e falla cun xogo, e a razón non é a configuración. SOCKS5 define varios comandos, e unha implementación é libre de admitir só algúns; a interface de Tor acepta conexións de fluxo e resolución de nomes, non o reenvío arbitrario de datagramas. Un cliente que envía UDP e espera que o proxy o reenvíe pide un comando que o servidor non implementa. A guía seguinte compróbao en poucos minutos e despois escolle un transporte que realmente poida funcionar.

Comprobe que envía realmente a aplicación

Comece identificando o transporte e non o nome do protocolo. Un cliente de voz pode iniciar sesión por HTTPS e despois levar os medios por UDP; un xogo pode autenticarse por TCP e xogar por UDP; unha transferencia de ficheiros pode usar TCP para o control e UDP para o descubrimento. Os dous primeiros comportamentos parecen idénticos ata que o inicio de sesión ten éxito e a chamada segue fallando, por iso «conectou» non é proba de que toda a aplicación funcione. Algúns clientes tamén volven de UDP a TCP por si mesmos, o que fai que unha sesión que funciona en parte pareza unha rede inestable en lugar dun transporte bloqueado.

Anote o porto de destino e o transporte da parte que falla. Esa única liña decide se un proxy pode axudar en absoluto.

Que aceptará a interface SOCKS de Tor

Tor implementa o comando SOCKS5 CONNECT para conexións de fluxo e comandos de extensión para resolver nomes, por iso un navegador funciona a través dela sen cambios. UDP ASSOCIATE, o comando que permitiría a un cliente entregar datagramas ao proxy para reenvialos, non forma parte do que ofrece Tor. A documentación das extensións está na especificación de extensións SOCKS do proxecto, e é breve. A ausencia dun comando para datagramas é deliberada: reenviar UDP arbitrario daría á rede un papel de reenvío para o que nunca se deseñou.

Esta é tamén a resposta para WireGuard, que é UDP por deseño e non ten alternativa TCP. Non existe unha ruta admitida que apunte WireGuard a un porto SOCKS, e todo o que afirme o contrario é un envoltorio coa súa propia historia de confianza e mantemento, non unha función de ningunha das dúas ferramentas.

OpenVPN é a excepción parcial, porque se pode configurar para tunelizar por TCP e entende unha opción de proxy SOCKS. Iso segue esixindo un servidor configurado para TCP e unha decisión consciente sobre as consecuencias de rendemento e de pegada, así que é unha elección de deseño e non unha solución de compatibilidade.

Execute a comprobación en orde

Confirme primeiro que o proxy funciona para fluxos, para que un fallo posterior non se atribúa a un porto inalcanzable. Despois confirme o tráfico propio da aplicación e observe que sockets abre realmente.

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'

Un primeiro comando correcto e un fluxo establecido na segunda liña mostran que a ruta do proxy funciona segundo o deseño. O terceiro comando busca sockets de datagramas locais que pertenzan á aplicación; se o cliente abre un e envía directamente a un enderezo remoto, nunca consultou o proxy e ningún axuste de proxy o cambiará. Se falla no primeiro paso, detéñase e repare a ruta do proxy antes de investigar a aplicación, porque dous fallos á vez producen un informe co que ninguén pode actuar.

Reverta e escolla a ferramenta correcta

Elimine calquera variable de contorno de proxy ou axuste de proxy por aplicación que apuntase o cliente UDP ao porto SOCKS; deixalos no seu sitio volve ambiguas as probas posteriores. Restaure a configuración anterior desde unha copia, reinicie a aplicación e confirme que volve o comportamento orixinal para que a comparación sexa limpa. Unha reversión que non se verifica só é a esperanza de que o estado cambiase.

Para un transporte que deba seguir sendo UDP, unha VPN adoita encaixar mellor: leva os paquetes da aplicación sen pedirlle que fale un protocolo de proxy, a costa de propiedades de anonimato completamente distintas. Use cada ferramenta para o que documenta, e trate calquera ponte entre elas como un sistema aparte que necesita a súa propia revisión. Anote no informe final que capa leva que transporte, para que a seguinte persoa non redescubra o mesmo límite con outra aplicación.