Encadenamiento de proxies: cómo funciona y cuándo resulta útil

Nuestra declaración de intereses: somos Geonode y vendemos proxies, por lo que en este artículo nos oponemos al uso de nuestro propio producto. Encadenar nuestros proxies detrás de los de otra persona, o a través de varios de los nuestros de forma secuencial, ralentizará tus solicitudes y las hará menos fiables, y no mejorará de forma significativa tu posición. La razón es de carácter estructural, más que una limitación de un proveedor concreto, y se explica a continuación. Hay dos o tres razones realmente válidas para encadenar proxies, y tienen que ver con el enrutamiento y el acceso, más que con el anonimato. Si tu objetivo es el anonimato, la respuesta sincera es que un sistema diseñado específicamente para ello lo hace correctamente, mientras que una pila de proxies comerciales no.

¿Qué es realmente el encadenamiento?

Normalmente: te conectas a un proxy y el proxy se conecta al destino. Dos conexiones, un intermediario.

En cadena: te conectas al proxy A, que se conecta al proxy B, que a su vez se conecta al destino. Cada salto termina la conexión anterior e inicia una nueva, de modo que el destino solo ve la dirección del proxy B, y el proxy B solo ve la del proxy A.

Las ventajas que se atribuyen a este sistema son que ningún intermediario conoce ambos extremos y que rastrear la ruta requiere la cooperación de todos los operadores de la cadena.

Ambas afirmaciones son ciertas en un sentido estricto, pero en la práctica son mucho menos sólidas de lo que sugiere el resumen. El resto de este artículo explica por qué.

Las dos formas de crear una cadena

El encadenamiento del lado del cliente es el caso más habitual: tu equipo está configurado para enrutar a través de A, y A está configurado —o tiene instrucciones— para reenviar la conexión a B. Herramientas como proxychains lo hacen interceptando las conexiones y haciéndolas pasar por una lista que tú controlas.

La característica que importa: tú eliges la cadena. Conoces cada salto, puedes modificarlos y no es necesaria la colaboración de ningún operador. Por eso, casi todo el encadenamiento práctico se realiza del lado del cliente.

El encadenamiento del lado del servidor se da cuando un proveedor redirige tu tráfico a través de una infraestructura que no controlas. Algunos servicios lo hacen internamente: una pasarela que termina tu conexión y sale a través de uno de muchos puntos finales es, técnicamente, una cadena, aunque no se suele describir como tal.

La característica que importa aquí es la contraria: no controlas la cadena y no puedes verificarla. La afirmación de un proveedor de que el tráfico pasa por varios países es imposible de verificar desde tu lado. Eso es una declaración de confianza, no una arquitectura.

proxychains: qué hace y cuáles son sus limitaciones

Es la herramienta más conocida, y su propia descripción explica con precisión su mecanismo de funcionamiento. proxychains es «un programa de UNIX que intercepta las funciones de libc relacionadas con la red en programas enlazados dinámicamente a través de una DLL precargada y redirige las conexiones a través de proxies SOCKS4a/5 o HTTP».

Esa frase resume tanto su ingenio como su limitación.

El ingenio: funciona con programas que no admiten proxies por sí mismos. Al interceptar a nivel de libc, una aplicación que realiza llamadas de socket normales se redirige de forma transparente sin que se dé cuenta.

La limitación, expresada sin rodeos: «solo funciona en programas enlazados dinámicamente» y requiere que proxychains y la aplicación de destino «utilicen el mismo enlazador dinámico». Los binarios enlazados estáticamente —entre los que se incluye gran parte del software moderno escrito en Go— simplemente no se ven afectados. El programa se ejecuta, se conecta directamente y no aparece ningún aviso.

Se admiten tres modos de cadena:

Orden exacto: los proxies se utilizan exactamente tal y como se han configurado. Es predecible, y un solo proxy inactivo rompe la cadena. Orden dinámico: los proxies inactivos se excluyen de forma inteligente, por lo que la cadena sobrevive a los fallos a costa de no ser la cadena que se especificó. Orden aleatorio: un subconjunto aleatorio de una longitud configurada, útil cuando se desea variación entre ejecuciones.

La compatibilidad con protocolos abarca SOCKS4, SOCKS4a, SOCKS5 y HTTP(S), con autenticación mediante nombre de usuario y contraseña para SOCKS y autenticación básica para HTTP.

Y hay un modo de fallo documentado que conviene conocer porque es realmente poco conocido: «cuando un proceso se bifurca, realiza una consulta DNS en el proceso hijo y, a continuación, utiliza la IP del proceso padre, no se encontrará la asignación de IP correspondiente». Las aplicaciones estructuradas de esta forma presentan un comportamiento anómalo que parece un problema de red, pero no lo es.

La latencia se acumula y la fiabilidad se reduce

Las cifras son el argumento más sólido en contra del encadenamiento aleatorio.

La latencia se acumula. Cada salto aporta su propio tiempo de ida y vuelta, además del tiempo de procesamiento. Una solicitud directa de 50 ms puede llegar a ser de unos 200 ms al pasar por un proxy y de 400 ms al pasar por dos. Para un uso interactivo, esta es la diferencia entre que sea utilizable o resulte irritante. Para una tarea de scraping que realice cien mil solicitudes, es la diferencia entre cuatro horas y ocho.

La fiabilidad se multiplica, y la multiplicación de números inferiores a uno solo va en una dirección. Si cada salto está disponible de forma independiente el 95 % del tiempo:

Una cadena de tres saltos de proxies fiables individualmente es un sistema que falla una de cada siete solicitudes. Y los fallos en una cadena son peores que los fallos en un único salto, porque el diagnóstico es más difícil: un tiempo de espera agotado te indica que la cadena se ha roto, pero no en qué enlace.

El ancho de banda se factura por salto. Si pagas por dos proxies con tarifa por uso, cada byte se factura dos veces. Encadenar dos servicios residenciales a 0,79 $/GB supone 1,58 $/GB por los mismos datos.

El rendimiento está limitado por el salto más lento, y añadir saltos aumenta las posibilidades de que se produzca una ralentización.

Frente a esos costes, la ventaja tiene que ser sustancial. Normalmente no lo es.

¿El encadenamiento te hace más anónimo?

La respuesta sincera es: menos de lo que se anuncia, y depende totalmente de quiénes sean los operadores.

Lo que sí consigue el encadenamiento. Ningún salto ve a la vez tu dirección y la del destino. El salto A sabe quién eres y que te has comunicado con B. El salto B sabe que se ha comunicado con el destino, pero no quién fue el origen. Esa es una propiedad genuina.

Por qué consigue menos de lo que parece.

La correlación entre los saltos resulta fácil para cualquiera que observe ambos. Un observador con visibilidad de ambos extremos —tiempo, volumen, patrones— puede vincularlos sin necesidad de descifrar nada. Esto es análisis de tráfico y constituye el problema central de los sistemas de anonimato. Dos proxies comerciales no lo resuelven.

La propiedad común rompe la cadena. Si ambos saltos pertenecen al mismo proveedor, o revenden la misma red subyacente, la separación es imaginaria. Las relaciones de reventa en el mercado de los proxies son habituales y no siempre se revelan, y una cadena que pasa por dos marcas que comparten un proveedor tiene un único operador, no dos.

La capa de aplicación lo anula por completo. Las cookies, los datos de inicio de sesión, las huellas digitales del navegador y cualquier cosa que escribas te identifican independientemente del enrutamiento. Una cadena de cinco proxies que transportan una sesión en la que has iniciado sesión es una forma muy lenta de ser identificado.

Los registros de pago y de cuenta permiten rastrearte. Tú compraste estos servicios. Hay un registro.

El cifrado no es por capas. En una cadena de proxies sin cifrado, cada salto puede leer todo aquello que no esté protegido por TLS. El encadenamiento no añade cifrado; añade intermediarios que podrían leer tu tráfico. Eso es lo contrario de lo que se pretende, y es precisamente lo que aborda la siguiente sección.

¿Funciona correctamente el encadenamiento en Tor?

Merece la pena entenderlo como diseño de referencia, ya que muestra lo que le falta a una pila de proxies comerciales.

El Proyecto Tor explica claramente la diferencia: «A diferencia de los servidores proxy habituales, que crean un único punto de confianza y de fallo, Tor enruta tu tráfico a través de múltiples repetidores con cifrado por capas».

El tráfico pasa por al menos tres repetidores, y la información se divide deliberadamente. El primer relé puede observar que una dirección está utilizando Tor, pero no puede determinar el destino. El relé intermedio ve el tráfico cifrado y no puede identificar ni al remitente ni al destino final. El relé de salida ve el tráfico saliente, pero no su origen; y, con HTTPS, solo ve el sitio de destino, no el contenido.

Hay tres características de diseño que hacen que esto funcione, y una cadena de proxies manual no cuenta con ninguna de ellas:

Cifrado por capas. Cada salto elimina una capa. Un relé no puede leer lo que recibirá el siguiente salto. En una cadena de proxies simple, cada salto ve tu tráfico tal y como lo envió tu cliente.

Los circuitos los selecciona el cliente a partir de un directorio publicado, con restricciones de ruta diseñadas para evitar relés correlacionados. En una cadena manual, eliges entre lo que hayas comprado y no puedes saber si dos proveedores comparten infraestructura.

Los relés son gestionados de forma independiente por voluntarios. Los proveedores de proxy comerciales son empresas con registros, facturación y obligaciones legales.

Nada de esto convierte a Tor en una solución universal: es lento, muchos sitios lo bloquean y no es adecuado para la recopilación de grandes volúmenes de datos. La cuestión es comparativa: si tu objetivo es el anonimato, un sistema diseñado para ello cumple su función, y apilar proxies comerciales se aproxima a la forma sin la sustancia.

Las fugas que echan por tierra toda la cadena

Una cadena es tan buena como su eslabón más débil, y hay varias rutas que la eluden por completo.

DNS. La más habitual. Si se consulta directamente a tu resolutor, tu proveedor de acceso a Internet ve todos los nombres de host mientras tu tráfico pasa por tres saltos. Con SOCKS5, utiliza el esquema socks5h para que los nombres de host sean resueltos por el proxy en lugar de localmente; la diferencia entre socks5:// y socks5h:// en curl es precisamente esta, y es el detalle que más se suele pasar por alto en la configuración del proxy.

WebRTC. En los navegadores, puede exponer direcciones locales y públicas fuera de la ruta del proxy.

IPv6. Una cadena exclusiva para IPv4 con conectividad IPv6 disponible implica que parte del tráfico se transmite directamente. De forma silenciosa e invisible, a menos que se compruebe.

Binarios enlazados estáticamente bajo proxychains. Ya se ha comentado anteriormente: la interceptación simplemente no se aplica, y el programa se conecta directamente sin previo aviso.

Cualquier cosa fuera del proceso interceptado. Actualizadores del sistema, telemetría, servicios en segundo plano. Nunca han estado en la cadena.

La regla general: verificar en lugar de dar por sentado. Comprobar que una página web muestra una dirección IP externa solo confirma lo que, obviamente, iba a cambiar. Nuestra guía sobre cómo probar proxies explica cómo comprobar correctamente el DNS, WebRTC e IPv6, y en el caso de una cadena, esa verificación es aún más importante, ya que hay más puntos en los que puede fallar.

Razones legítimas para encadenar

Casos reales, ninguno de los cuales tiene que ver con el anonimato.

Acceder a una red a la que no puedes conectarte directamente. Un proxy corporativo es tu única vía de salida, y necesitas un segundo proxy más allá de este para llegar a un destino específico. Esto es encadenamiento como «tuberías», y es, con diferencia, el uso legítimo más común.

Puente de protocolos. Tu aplicación solo admite SOCKS, pero el proxy disponible es HTTP, o viceversa. Un proxy local convierte y reenvía. De nuevo, «tuberías».

Añadir funcionalidad en un salto local. Ejecutar un proxy local para el almacenamiento en caché, el registro, la reescritura de solicitudes o la inspección de TLS, que luego reenvía la información a un proxy de nivel superior. Se trata de una cadena cuyo primer salto existe para realizar una tarea, más que para ocultar nada, y es una práctica habitual en el desarrollo y las pruebas.

Enrutamiento geográfico que no se puede adquirir directamente. En ocasiones, solo se puede acceder a la ubicación de salida que necesitas a través de un intermediario. Es poco frecuente, y merece la pena comprobar si un proveedor ofrece directamente esa ubicación antes de crear una cadena.

Probar el comportamiento en múltiples saltos. Si estás creando algo que se ejecutará detrás de varios proxies, es legítimo probar esa ruta.

Fíjate en lo que tienen en común: la cadena existe debido a una restricción de enrutamiento, no porque se supusiera que cuantos más saltos, mejor. Esa es la distinción que vale la pena aplicar a tu propio caso.

Preguntas frecuentes

¿Encadenar proxies aumenta el anonimato?

Ligeramente, y menos de lo esperado. Esto significa que ningún salto concreto ve tanto tu dirección como la del destino. Sin embargo, no protege contra la correlación del tráfico, la propiedad común entre proveedores ni la identificación en la capa de aplicación a través de cookies, datos de inicio de sesión y huellas digitales. Además, el encadenamiento simple no añade cifrado: cada salto ve todo lo que el TLS no protege.

¿Cuántos proxies debo encadenar?

Por razones legítimas de enrutamiento, tantos como requiera la restricción; normalmente, dos. En cuanto al anonimato, encadenar proxies comerciales es un enfoque erróneo, independientemente del número, y un sistema diseñado específicamente para ese fin lo hace mejor. Cada salto adicional añade latencia, multiplica la probabilidad de fallo y duplica tu factura de ancho de banda.

¿Qué es proxychains y cómo funciona?

Una herramienta de Unix que se acopla a las funciones de libc relacionadas con la red en programas enlazados dinámicamente y redirige las conexiones a través de proxies SOCKS4a/5 o HTTP. Ofrece un orden de encadenamiento exacto, dinámico y aleatorio. Su principal limitación es que solo funciona con programas enlazados dinámicamente; los binarios enlazados estáticamente se conectan directamente sin previo aviso.

¿Es lento el encadenamiento de proxies?

Sí, necesariamente. Cada salto añade un tiempo de ida y vuelta y de procesamiento, por lo que una cadena de dos saltos duplica aproximadamente el coste de un solo proxy. El rendimiento está limitado por el salto más lento, y si cada salto tiene una fiabilidad del 95 %, una cadena de tres saltos tiene éxito aproximadamente el 86 % de las veces.

¿Puedo encadenar una VPN y un proxy?

Técnicamente sí, y es algo habitual. El efecto práctico suele ser una mayor latencia a cambio de un cambio modesto en lo que observa cada parte. Tu proveedor de VPN sigue viendo que te conectas, el operador del proxy sigue viendo tus solicitudes, y ninguna de estas configuraciones aborda la identificación en la capa de aplicación.

¿El encadenamiento impide que los sitios web me rastreen?

No. El rastreo funciona a través de cookies, huellas del navegador, inicios de sesión en cuentas y patrones de comportamiento; ninguno de estos factores se ve afectado por el número de saltos de red que realiza tu tráfico. El enrutamiento cambia la dirección que registra un sitio web, y hace mucho tiempo que los sitios dejaron de basarse únicamente en la dirección.

¿Es Tor una cadena de proxies?

Se trata de un encadenamiento que cuenta con tres propiedades de las que carece una cadena manual: cifrado por capas, de modo que ningún relé puede leer lo que recibe el siguiente; rutas seleccionadas por el cliente a partir de un directorio publicado con restricciones para evitar relés correlacionados; y relés voluntarios gestionados de forma independiente. El Proyecto Tor contrasta esto con los proxies habituales, que «crean un único punto de confianza y de fallo».

¿Pago dos veces por el ancho de banda en una cadena?

Si ambos saltos están medidos, sí: cada byte atraviesa ambos y es facturado por ambos. Dos servicios residenciales a 0,79 $/GB cuestan 1,58 $/GB por los mismos datos. Esta es una razón clara para comprobar si una cadena resuelve realmente un problema antes de crearla.

Conclusión

El encadenamiento de proxies es una técnica de enrutamiento que se promociona como una técnica de privacidad, pero ambas cosas no son lo mismo.

Como técnica de enrutamiento, a veces resulta totalmente adecuada: para salir a través de un proxy corporativo hacia un destino que requiere otro, para tender un puente entre SOCKS y HTTP, o para colocar un proxy local delante con fines de almacenamiento en caché y registro. En esos casos, la cadena existe debido a una restricción, y la latencia adicional es el precio que hay que pagar por la ruta.

En cuanto a la privacidad, es una versión débil de algo que existe en una versión fuerte. Una cadena manual no añade ningún cifrado, por lo que cada salto puede leer todo aquello que TLS no proteja. No permite saber si dos proveedores comparten infraestructura. No hace nada respecto a la correlación del tráfico, y nada en absoluto respecto a las cookies, los inicios de sesión y las huellas digitales —que es donde realmente se produce la identificación—.

Los costes, por su parte, son evidentes. La latencia aumenta, la fiabilidad se reduce drásticamente y el ancho de banda medido se factura por duplicado. Si estás considerando utilizar una cadena, la pregunta útil es qué restricción de enrutamiento específica resuelve. Si la respuesta es «más saltos parecen más seguros», las cifras te dan la razón.