Done in a Million

Evitar fugas de DNS (DNS Leak)

Escrito por

admin

en

omo evitar las fugas de dns, explica primero, resume de que s etrata, y la solucion

Una 

fuga de DNS (DNS Leak) ocurre cuando tu bot usa la IP del usuario para navegar, pero le pregunta «qué dirección tiene google.com» a un servidor que no es el del usuario (como el de tu centro de datos).

¿De qué se trata?

Imagina que el bot está en un servidor en Alemania y el usuario en España.

  1. El bot quiere entrar a una web.
  2. El bot usa su propia red para resolver el nombre del dominio (DNS).
  3. La web (Google/Cloudflare) ve que la petición de conexión viene de España, pero la consulta previa del nombre vino de un servidor en Alemania.
  4. Resultado: El sistema detecta la inconsistencia y te marca como proxy/bot inmediatamente.

La Solución: Forzar el DNS a través del Túnel

Para que sea 100% indetectable, el bot no debe saber nada de la red exterior; todo, incluida la resolución de nombres, debe pasar por el programa del usuario.

1. Configuración SOCKS5 con resolución remota

Si usas un proxy SOCKS5 (que es lo más recomendable para tu caso), este protocolo permite dos modos. Debes asegurarte de que tu bot use SOCKS5h (la «h» significa host o resolución remota).

  • Mal: El bot resuelve la IP y luego pide la conexión al proxy.
  • Bien: El bot le pasa el nombre del dominio (google.com) al proxy, y el programa del usuario en España es quien resuelve la IP usando el DNS de su proveedor local (Movistar, Vodafone, etc.).

2. Configuración en el Bot (Ejemplo en Python/Requests o Playwright)

Si usas herramientas como curl, requests o playwright, debes pasar el esquema de proxy correctamente:

  • Usa socks5h://usuario:password@tu-servidor:puerto en lugar de solo socks5://. La «h» fuerza a que el DNS se resuelva en el destino (el PC del usuario).

3. En el Servidor de Control (Relay)

Si estás construyendo tu propio sistema con Golang (Chisel, Frp) o SSH:

  • Asegúrate de que el servidor proxy que corre en el PC del usuario esté configurado para aceptar peticiones de resolución. En SSH, esto se logra con la opción -D (Dynamic Forwarding), que crea un servidor SOCKS local que maneja DNS automáticamente.

4. Deshabilitar DNS local en el servidor del Bot

Como medida de seguridad extra, puedes configurar el servidor donde viven tus bots para que no tenga servidores DNS configurados en /etc/resolv.conf. Si el bot intenta resolver algo por su cuenta, fallará, obligándolo a usar siempre el túnel.

¿Quieres que te muestre un ejemplo de código en Python o Node.js para configurar un bot de modo que fuerce el DNS a través de un proxy SOCKS5?

«El bot usa su propia red para resolver el nombre del dominio (DNS)» PORQUE ? no se supone que mi bot se conecta (digamos desde mi servidor en Lloret de mar) a internet a traves del proxy inverso, o sea instalado en un usuario digamos en Madrid, se supone que la pregunta de resuelveme que ip lleva google, ¿la debe tramitar desde la ip del usuario no ?

Exacto, 

tienes toda la razón en la teoría, pero en la práctica muchos programas de bots están «mal configurados» por defecto y cometen ese error sin que te des cuenta.

Aquí te explico por qué ocurre ese fallo técnico y cómo evitarlo:

¿Por qué el bot a veces usa su propia red?

Por defecto, la mayoría de librerías de programación (como requests en Python o el comando curl básico) funcionan en dos pasos separados:

  1. Paso 1 (Local): El sistema operativo del bot pregunta: «Oye, ¿cuál es la IP de google.com?». Usa el DNS de tu servidor en Lloret de Mar.
  2. Paso 2 (Proxy): Una vez que tiene la IP (ej. 142.250.184.14), el bot le dice al proxy en Madrid: «Conéctame a la IP 142.250.184.14».

El rastro que dejas: Google recibe una conexión desde Madrid, pero Cloudflare (que ve las consultas DNS globales) nota que alguien desde Lloret de Mar acaba de preguntar por esa misma web justo un milisegundo antes. Esa es la fuga.

La Solución: Resolución Remota (SOCKS5h)

Para que el bot no haga el «Paso 1» en Lloret de Mar, debes usar el protocolo SOCKS5h (la «h» es la clave).

  • SOCKS5 (normal): El bot resuelve el DNS en Lloret y le da al proxy de Madrid una IP. (Hay fuga).
  • SOCKS5h (remoto): El bot no resuelve nada. Le envía al proxy de Madrid el nombre del dominio (google.com). El programa en el PC del usuario en Madrid es quien hace la pregunta DNS a su router de Movistar/Vodafone. (No hay fuga).

Cómo implementarlo en tus bots

Si tus bots están en Python, la configuración debe ser así:

python

import requests

# USA "socks5h" para forzar que el DNS se resuelva en el PC del usuario (Madrid)
proxies = {
    'http': 'socks5h://tu-servidor-relay:puerto',
    'https': 'socks5h://tu-servidor-relay:puerto'
}

# La petición viajará ciega hasta Madrid, y allí se resolverá el DNS
response = requests.get('https://www.google.com', proxies=proxies)

Usa el código con precaución.

Resumen de la solución:

  1. En el Bot: Usa siempre el esquema socks5h:// en lugar de socks5://.
  2. En el Navegador (si usas Selenium/Playwright): Configura el flag --proxy-server=socks5://tu-proxy y asegúrate de activar la opción «Proxy DNS when using SOCKS v5».
  3. En el programa del Usuario: Asegúrate de que el servidor proxy que creaste (el nodo) acepte peticiones de nombres de dominio y no solo de IPs.

¿Quieres que te pase el comando específico para verificar si tienes fugas desde la consola de tu bot? Es la mejor forma de estar 100% seguro antes de lanzar los bots masivamente.

Las respuestas de la IA pueden contener errores. Más información

que no «Paso 1 (Local): El sistema operativo del bot pregunta: «Oye, ¿cuál es la IP de google.com?». Usa el DNS de tu servidor en Lloret de Mar. Paso 2 (Proxy): Una vez que tiene la IP (ej. 142.250.184.14), el bot le dice al proxy en Madrid: «Conéctame a la IP 142.250.184.14″.» como va a ser asi, a ver pasos. Paso 1) mi bot en IP1 lloret,, se conecta al proxy del usuario remoto en Madrid IP2, y bot en IP1 en lloret, pregunta al DNS, ¿donde esta google ?, pero hace la pregunta pasando por el proxy IP2 ¿el que resuelve el DNS, ve que la pregunta la hace mi bot desde IP1 en lloret o desde IP2 en madrid, ue es desde donde esta el proxy ?

Ahí está el punto clave de la confusión y es donde la mayoría de la gente falla al configurar proxies. Te lo explico paso a paso para que veas dónde está el «truco» técnico:

El Problema: Quién hace la pregunta al DNS

Por defecto, el sistema operativo de tu servidor en Lloret de Mar intenta ser eficiente. Antes de mandar cualquier dato por el proxy, necesita saber a qué dirección IP debe conectarse.

Si usas un Proxy SOCKS5 convencional (sin configuración de DNS remoto):

  1. Paso 1 (Lloret): Tu programa (el bot) le dice al Sistema Operativo (Windows/Linux) de Lloret: «Quiero ir a google.com».
  2. Paso 2 (Lloret): El Sistema Operativo de Lloret, usando su propia conexión de red local, le pregunta a su servidor DNS (ej. el de tu router en Lloret o el 8.8.8.8 de Google): «¿Qué IP tiene google.com?».
  3. Paso 3 (Lloret recibe la respuesta): El DNS le responde a tu servidor de Lloret: «La IP es 142.250.184.14».
  4. Paso 4 (Lloret -> Madrid): Ahora que tu bot ya sabe la IP, se conecta al proxy de Madrid y le dice: «Oye, proxy, conéctame a la IP 142.250.184.14».

¿Qué ve Google/Cloudflare?

  • Ve una consulta DNS viniendo desde la IP de Lloret de Mar.
  • Milisegundos después, ve una conexión web viniendo desde la IP de Madrid.
  • Resultado: Detectan que hay un proxy de por medio porque la consulta DNS y la conexión web no vienen del mismo sitio. Eso es la Fuga de DNS.

La Solución: El Protocolo SOCKS5h (DNS Remoto)

Para que sea indetectable, tienes que decirle a tu bot: «No intentes resolver la IP tú mismo. Pásale el nombre ‘google.com’ directamente al proxy de Madrid y que él se encargue de todo».

Si usas SOCKS5h (con DNS remoto):

  1. Paso 1 (Lloret -> Madrid): Tu bot en Lloret abre el túnel hacia el proxy en Madrid y le dice: «Toma este nombre de dominio: ‘google.com’. Resuélvelo tú y conéctame».
  2. Paso 2 (Madrid): El programa que instalaste en el usuario de Madrid recibe el nombre «google.com». El PC de Madrid, usando la conexión de Madrid, le pregunta a su DNS local (Movistar/Vodafone Madrid): «¿Qué IP tiene google.com?».
  3. Paso 3 (Madrid): El PC de Madrid recibe la IP y establece la conexión allí mismo.
  4. Paso 4 (Madrid -> Lloret): El proxy de Madrid le devuelve los datos de la web a tu bot en Lloret a través del túnel.

¿Qué ve Google/Cloudflare ahora?

  • Ve que la consulta DNS viene de Madrid.
  • Ve que la conexión web viene de Madrid.
  • Resultado: Para ellos, es un usuario real en Madrid navegando normalmente. No hay rastro de Lloret de Mar.

Conclusión

La pregunta DNS la hace quien tenga el nombre del dominio. Si tu bot resuelve el nombre antes de hablar con el proxy, la pregunta sale desde Lloret. Si tu bot le pasa el nombre al proxy sin resolverlo, la pregunta sale desde Madrid.

¿Entiendes ahora por qué es vital configurar el bot para que use SOCKS5h (resolución remota) y no el SOCKS5 estándar?

El Protocolo SOCKS5h

Comentarios

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Más entradas