Proxies SOCKS5 y SOCKS4

Un proxy SOCKS permite que una aplicación pida a un servidor intermediario que se conecte a un destino por ella. El proxy abre la conexión solicitada y pasa los datos en ambas direcciones. La aplicación sigue utilizando su propio protocolo, por lo que esto sirve para solicitudes web, clientes de API, transferencias de archivos y otros programas compatibles con SOCKS.

Para una configuración nueva, SOCKS5 suele ofrecer las opciones más útiles: más formatos de dirección, elección de métodos de autenticación y compatibilidad con UDP. SOCKS4 sigue siendo útil para programas que exigen la versión antigua. La elección general entre estos protocolos y los proxies HTTP se trata en Proxies SOCKS y HTTP.

Cómo se conecta una aplicación mediante SOCKS

Considera una aplicación que abre https://example.com/ a través de un proxy SOCKS5. Primero llega al proxy, le pide que abra una conexión con el sitio web y solo después intercambia los datos del sitio. El proceso tiene cuatro etapas:

1. La aplicación se conecta por TCP al nombre de host o IP del proxy y a su puerto de escucha.
2. La aplicación y el proxy seleccionan un método de acceso. Si ese método requiere credenciales, la aplicación las proporciona y el proxy las comprueba.
3. La aplicación envía una solicitud SOCKS CONNECT con la dirección y el puerto de destino. El proxy comprueba sus reglas de acceso, intenta la conexión posterior e informa del resultado.
4. Después de una respuesta satisfactoria, la aplicación se comunica con el destino a través del proxy. Para un sitio HTTPS, establece TLS con el sitio y verifica su certificado antes de enviar la solicitud web.

Los dos números de puerto pertenecen a servidores distintos. Un proxy de ejemplo podría escuchar en proxy.example:1080, mientras se llega al sitio web en example.com:443. El puerto 1080 es habitual en SOCKS, pero un servicio puede utilizar otro. Utiliza el puerto de escucha asignado a tu proxy; no sustituye al puerto del destino.

Durante el reenvío TCP ordinario, SOCKS pasa el flujo de bytes de la aplicación sin tener que interpretar cada solicitud HTTP u orden de archivo. La aplicación sigue utilizando su propio protocolo con el destino. Por eso el mismo mecanismo de conexión SOCKS puede servir a clientes web y otros tipos de programas.

CONNECT es una orden dentro de SOCKS con su propio formato de mensaje; es distinta del método HTTP CONNECT. SOCKS también define BIND para aplicaciones que necesitan que un servidor inicie una conexión de vuelta a través del proxy, como puede ocurrir con FTP activo. BIND necesita compatibilidad específica y no se utiliza en una solicitud ordinaria a un sitio web o una API.

Qué cambia entre SOCKS4, SOCKS4a y SOCKS5

SOCKS4 abre conexiones TCP a direcciones IPv4. SOCKS4a añade la opción de enviar un nombre de host para que el proxy encuentre su IP mediante DNS. SOCKS5 añade una elección de métodos de autenticación, acepta direcciones IPv4, direcciones IPv6 y nombres de host, y define el reenvío UDP.

Son funciones de los protocolos. El cliente y el servicio de proxies deben implementar la función concreta que pretendes utilizar. Por ejemplo, un servicio SOCKS5 puede gestionar conexiones TCP sin ofrecer una retransmisión UDP utilizable.

SOCKS5 puede incluir un destino IPv6 en su solicitud, pero el proxy también debe poder llegar a ese servidor IPv6. Las dos conexiones pueden utilizar versiones de IP distintas: la aplicación puede llegar al proxy por IPv4, mientras el proxy se conecta al destino por IPv6.

SOCKS4a es una extensión de SOCKS4, no otro nombre para todas las conexiones SOCKS4. Si un cliente antiguo solo envía direcciones IPv4, seleccionar SOCKS4 no le proporciona DNS remoto. SOCKS4a requiere compatibilidad en ambos extremos. SOCKS5 suele ser la opción más sencilla cuando ambos extremos lo admiten; seleccionar SOCKS4 no mejora por sí solo la reputación o la velocidad de la IP de salida.

Quién resuelve el nombre del destino

Antes de que una conexión pueda llegar a un servidor identificado por un nombre, ese nombre debe traducirse a una dirección IP. SOCKS5 puede aceptar el resultado de esa consulta o el propio nombre. La configuración DNS del cliente determina cuál envía.

Con DNS local, la aplicación pregunta a su resolvedor configurado por reports.example. Supongamos que la respuesta es 203.0.113.27: la aplicación solicita después una conexión SOCKS a 203.0.113.27:443. La consulta ya se ha realizado en el lado del cliente, aunque la conexión posterior con el sitio pasa por el proxy.

Con DNS en el lado del proxy, la aplicación envía reports.example:443 sin consultar primero ese destino localmente. El proxy obtiene su IP mediante DNS y abre la conexión solicitada. El nombre de host llega al proxy como parte de la solicitud SOCKS.

Esto puede ayudar cuando el cliente no puede resolver un nombre que el proxy sí puede resolver. Algunos servicios devuelven direcciones distintas según el resolvedor DNS, por lo que trasladar la consulta puede cambiar qué servidor recibe la conexión. No establece el país de salida del proxy ni garantiza que el sitio acepte la solicitud.

En curl, las dos órdenes siguientes eligen los dos modos DNS:

curl --proxy socks5://proxy.example:1080 https://example.com/
curl --proxy socks5h://proxy.example:1080 https://example.com/

socks5:// hace que curl resuelva localmente el nombre del sitio; socks5h:// lo pasa al proxy. Ambos utilizan SOCKS5. La h significa resolución del nombre de host por el proxy en la sintaxis de URL de este cliente. No convierte SOCKS5 en HTTPS ni añade cifrado. Otras aplicaciones pueden utilizar una casilla o elegir DNS remoto automáticamente. Sustituye el nombre de host y el puerto del proxy de ejemplo por los datos de tu servicio y proporciona la autenticación requerida.

Pasar un nombre de dominio en una solicitud TCP SOCKS5 no requiere compatibilidad con retransmisión UDP. El proxy realiza la consulta con su propia configuración DNS. Esto es distinto de pedir a SOCKS5 que transporte los paquetes UDP de un cliente.

Si un cliente está configurado para dejar el DNS del destino al proxy, pero realiza esa consulta localmente, expone el nombre solicitado fuera de la ruta prevista. Esto es una fuga de DNS. El DNS cifrado protege el intercambio con el resolvedor, pero ese resolvedor sigue recibiendo el nombre. Consultar el nombre de host del propio proxy es una tarea aparte, y otras aplicaciones mantienen su propio comportamiento DNS. El DNS remoto de un programa no traslada todas las consultas del dispositivo.

Autenticación y cifrado

SOCKS5 permite que el cliente ofrezca métodos de autenticación compatibles y que el proxy elija uno. El nombre de usuario y la contraseña son una opción. Otra es una conexión sin intercambio de inicio de sesión SOCKS, que un servicio puede permitir después de comprobar la IP de origen del cliente contra una lista de permitidas. Por tanto, un punto de conexión sin campo de contraseña puede seguir restringiendo el acceso.

No lograr acordar un método es distinto de rechazar una contraseña: en el primer caso, el intercambio de contraseña aún no se ha producido. Un cliente que no admite usuario y contraseña no puede utilizar un punto de conexión SOCKS5 exclusivo de contraseña por el mero hecho de tener un ajuste SOCKS5. SOCKS4 tiene un campo de ID de usuario, pero no un intercambio estándar de contraseña equivalente; su servidor puede seguir aplicando reglas de acceso.

El intercambio habitual de usuario y contraseña de SOCKS5 no cifra las credenciales. Ocurre antes de que la aplicación establezca HTTPS con el destino, por lo que esa conexión HTTPS posterior no protege el inicio de sesión previo del proxy. Cifrar la ruta entre cliente y proxy requiere una conexión protegida separada o un mecanismo de seguridad admitido expresamente.

Durante el reenvío SOCKS ordinario, HTTPS protege el intercambio de la aplicación con el sitio web, con la verificación de certificados activada y sin interceptación TLS. Un protocolo de aplicación sin cifrar sigue sin cifrar a través de la retransmisión. La compatibilidad con SOCKS5 o la autenticación por contraseña, por sí solas, no prometen tráfico cifrado.

El proxy sigue conociendo la IP desde la que se conecta el cliente, el destino solicitado y los tiempos de conexión. El destino ve la IP de salida del proxy y recibe los datos de aplicación dirigidos a él. Las cookies, los inicios de sesión de cuentas y otros identificadores de aplicación pueden seguir identificando al usuario; cambiar la versión de SOCKS no los elimina.

Cómo transporta SOCKS5 TCP y UDP

TCP proporciona un flujo ordenado de bytes. Una solicitud del navegador, una llamada a una API o una sesión SSH pueden utilizar una conexión SOCKS TCP cuando el cliente admite esa ruta y el proxy permite el destino. Que funcione el puerto 443 de un sitio web no demuestra que esté disponible el puerto de otra aplicación.

UDP envía datagramas separados. Un cliente SOCKS5 abre primero una conexión de control TCP y solicita una retransmisión mediante UDP ASSOCIATE. El proxy devuelve la dirección de retransmisión y el puerto UDP. El cliente envía allí sus datagramas con cabeceras SOCKS que describen sus destinos. Cerrar la conexión de control TCP termina esta asociación UDP; los datagramas viajan por separado de la conexión de control, no dentro de un flujo SOCKS CONNECT ordinario.

La aplicación y el servicio deben admitir este mecanismo, y la red debe permitir la ruta UDP. Un programa puede completar un inicio de sesión TCP mientras su función de voz, juego u otra función UDP sigue fallando. Una solicitud HTTPS satisfactoria mediante SOCKS CONNECT demuestra reenvío TCP, no UDP operativo. QUIC utiliza UDP, pero que QUIC sea utilizable también depende del cliente y de toda la ruta; la etiqueta SOCKS5 por sí sola no lo demuestra.

Dónde resulta útil SOCKS

SOCKS resulta útil cuando un programa necesita una conexión intermediaria y conserva su propio protocolo de aplicación. Un script puede solicitar datos de una API a través de una IP de salida asignada, un cliente de transferencia de archivos puede llegar a un servidor remoto por una ruta aprobada y una aplicación de escritorio compatible puede utilizar un proxy sin ser un navegador web. Cada caso depende de la compatibilidad SOCKS del cliente y de los puertos de destino que permita el servicio.

Para trabajos repetidos con la misma cuenta o servidor, puede ser adecuada una salida fija. Para tareas independientes, puede resultar útil un servicio rotativo. SOCKS4 y SOCKS5 no deciden este comportamiento: el servicio determina la IP de salida, su tipo de red, si otros clientes la utilizan y cuándo cambia. La versión del protocolo tampoco establece una clasificación de velocidad; la longitud de la ruta, la carga del servidor y el ancho de banda disponible afectan al resultado.

La compatibilidad del cliente puede ser más limitada que la del protocolo. La implementación SOCKS5 incorporada en Chrome resuelve los nombres de destino mediante el proxy, pero no realiza autenticación SOCKS5 con usuario y contraseña ni retransmite UDP. Por tanto, un punto de conexión exclusivo de contraseña puede funcionar en curl y fallar con ese ajuste incorporado del navegador. Un adaptador externo es una parte separada de la conexión, con sus propias funciones.

Un proxy configurado dentro de un programa se aplica a las conexiones compatibles de ese programa. No configura otro gestor de descargas o script. Del mismo modo, la configuración de proxy del sistema afecta a los programas que la utilizan. Cuando un adaptador redirige conexiones de una aplicación sin compatibilidad SOCKS nativa, importa su cobertura de TCP, UDP y DNS. SOCKS no proporciona reenvío ICMP ordinario, por lo que ping no prueba esta ruta de proxy.

Configuración de conexión y una prueba útil

Empieza por la dirección del proxy, el puerto de escucha, la versión de SOCKS y el método de acceso proporcionados para ese punto de conexión. Un número como 1080 no identifica el protocolo por sí solo. Selecciona SOCKS en el cliente en lugar de introducir la misma dirección en un campo exclusivo de proxy HTTP.

Las credenciales del proxy autorizan el uso del intermediario; el inicio de sesión de un sitio autoriza el uso del sitio. Pertenecen a configuraciones distintas. En curl, --proxy-user proporciona las credenciales del proxy, mientras que --user proporciona las del destino. Para el acceso basado en IP, la lista de permitidas debe coincidir con la IP de origen del cliente que ve el proxy, que puede cambiar cuando el cliente cambia de red.

Elige el modo DNS previsto y después comprueba las reglas de exclusión. Se puede omitir un proxy configurado para destinos incluidos en una lista de excepciones. En curl, NO_PROXY puede provocar esto; --noproxy "" borra esas exclusiones durante una ejecución cuando quieres probar deliberadamente la ruta del proxy.

Prueba desde el programa real que realizará el trabajo. Un punto de comprobación de IP, o un registro de servidor de destino que controles, puede mostrar la IP de origen de la solicitud. Compara ese resultado con una solicitud directa. La dirección utilizada para llegar al proxy y la dirección de salida que ve el destino no tienen por qué ser idénticas.

Después prueba la tarea real. Una IP distinta demuestra la ruta de la solicitud probada, pero no mide todos los transportes ni establece cómo responderá otro sitio. Prueba UDP o IPv6 por separado cuando la tarea los necesite y evalúa el tiempo de respuesta y la estabilidad de la conexión con una carga representativa.

Localiza un error por su etapa de conexión

Distingue entre llegar al proxy, obtener acceso, abrir la conexión con el destino y recibir la respuesta de la aplicación. Estas etapas tienen causas de fallo diferentes.

Si una conexión HTTPS verificada funciona y el sitio devuelve una página de inicio de sesión, un CAPTCHA o un rechazo de acceso, la conexión SOCKS ya ha transportado ese intercambio. Investiga la respuesta del sitio y el comportamiento de la aplicación. Si la solicitud muestra en cambio tu IP pública habitual, comprueba el proxy seleccionado y las reglas de exclusión de ese programa.