UDP a través del puerto SOCKS de Tor: qué no se transporta

Apuntar una aplicación a un puerto SOCKS funciona con un navegador y falla con un juego, y la razón no es la configuración. SOCKS5 define varios comandos, y una implementación es libre de admitir solo algunos; la interfaz de Tor acepta conexiones de flujo y resolución de nombres, no el reenvío arbitrario de datagramas. Un cliente que envía UDP y espera que el proxy lo retransmita pide un comando que el servidor no implementa. La guía siguiente lo comprueba en unos minutos y luego elige un transporte que realmente pueda funcionar.

Compruebe qué envía realmente la aplicación

Empiece por identificar el transporte y no el nombre del protocolo. Un cliente de voz puede iniciar sesión por HTTPS y luego llevar los medios por UDP; un juego puede autenticarse por TCP y jugar por UDP; una transferencia de archivos puede usar TCP para el control y UDP para el descubrimiento. Los dos primeros comportamientos parecen idénticos hasta que el inicio de sesión tiene éxito y la llamada sigue fallando, por eso «se conectó» no es prueba de que toda la aplicación funcione. Algunos clientes también vuelven de UDP a TCP por su cuenta, lo que hace que una sesión que funciona en parte parezca una red inestable en lugar de un transporte bloqueado.

Anote el puerto de destino y el transporte de la parte que falla. Esa única línea decide si un proxy puede ayudar en absoluto.

Qué aceptará la interfaz SOCKS de Tor

Tor implementa el comando SOCKS5 CONNECT para conexiones de flujo y comandos de extensión para resolver nombres, por eso un navegador funciona a través de ella sin cambios. UDP ASSOCIATE, el comando que permitiría a un cliente entregar datagramas al proxy para reenviarlos, no forma parte de lo que ofrece Tor. La documentación de las extensiones está en la especificación de extensiones SOCKS del proyecto, y es breve. La ausencia de un comando para datagramas es deliberada: reenviar UDP arbitrario daría a la red un papel de reenvío para el que nunca se diseñó.

Esta es también la respuesta para WireGuard, que es UDP por diseño y no tiene alternativa TCP. No existe una ruta admitida que apunte WireGuard a un puerto SOCKS, y todo lo que afirme lo contrario es un envoltorio con su propia historia de confianza y mantenimiento, no una función de ninguna de las dos herramientas.

OpenVPN es la excepción parcial, porque se puede configurar para tunelizar por TCP y entiende una opción de proxy SOCKS. Eso sigue exigiendo un servidor configurado para TCP y una decisión consciente sobre las consecuencias de rendimiento y de huella, así que es una elección de diseño y no una solución de compatibilidad.

Ejecute la comprobación en orden

Confirme primero que el proxy funciona para flujos, para que un fallo posterior no se atribuya a un puerto inalcanzable. Luego confirme el tráfico propio de la aplicación y observe qué 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 primer comando correcto y un flujo establecido en la segunda línea muestran que la ruta del proxy funciona según lo diseñado. El tercer comando busca sockets de datagramas locales que pertenezcan a la aplicación; si el cliente abre uno y envía directamente a una dirección remota, nunca consultó al proxy y ningún ajuste de proxy lo cambiará. Si falla en el primer paso, deténgase y repare la ruta del proxy antes de investigar la aplicación, porque dos fallos a la vez producen un informe con el que nadie puede actuar.

Revierta y elija la herramienta correcta

Elimine cualquier variable de entorno de proxy o ajuste de proxy por aplicación que apuntara el cliente UDP al puerto SOCKS; dejarlos en su sitio vuelve ambiguas las pruebas posteriores. Restaure la configuración anterior desde una copia, reinicie la aplicación y confirme que vuelve el comportamiento original para que la comparación sea limpia. Una reversión que no se verifica es solo la esperanza de que el estado haya cambiado.

Para un transporte que deba seguir siendo UDP, una VPN suele encajar mejor: lleva los paquetes de la aplicación sin pedirle que hable un protocolo de proxy, a costa de propiedades de anonimato completamente distintas. Use cada herramienta para lo que documenta, y trate cualquier puente entre ellas como un sistema aparte que necesita su propia revisión. Anote en el informe final qué capa lleva qué transporte, para que la siguiente persona no redescubra el mismo límite con otra aplicación.