Redirigimos todo el tráfico del contenedor a través de un proxy SOCKS con tun2socks

A veces surge la necesidad de redirigir todo el tráfico saliente de un contenedor determinado a través de un servidor proxy. Esto puede ser útil para garantizar el anonimato, sortear geobloqueos o para probar configuraciones de red. En este artículo veremos cómo configurar tal sistema usando la utilidad tun2socks y reglas de iptables, así como cómo gestionar este proceso con systemd.

¿Qué es tun2socks?

tun2socks es una herramienta potente que permite redirigir el tráfico de red destinado a un dispositivo TUN a través de un proxy SOCKS. Crea una interfaz de red virtual (dispositivo TUN), cuyo tráfico se encapsula en una conexión SOCKS. Esto es especialmente útil cuando el proxy a nivel de aplicación no es posible o no es deseable.

Instalación de tun2socks

Para empezar necesitamos instalar tun2socks. Usaremos binarios precompilados desde GitHub.

1. Vaya a la página de lanzamientos de tun2socks: https://github.com/xjasonlyu/tun2socks/releases

2. Seleccione la última versión estable (a septiembre de 2026 — v2.7.0 del 12.07.2026) y descargue el archivo para su arquitectura. Los archivos se publican en formato .zip, por ejemplo tun2socks-linux-amd64.zip para sistemas Linux de 64 bits; dentro hay un único ejecutable.

3. Descomprima el archivo y mueva el ejecutable a una ruta del sistema, por ejemplo /usr/local/bin/:

   bash Copy

   # Ejemplo para linux-amd64; en caso de una nueva versión reemplace v2.7.0
   wget https://github.com/xjasonlyu/tun2socks/releases/download/v2.7.0/tun2socks-linux-amd64.zip
   unzip tun2socks-linux-amd64.zip
   sudo install -m 0755 tun2socks-linux-amd64 /usr/local/bin/tun2socks

   Asegúrese de que la ruta al binario en su script coincida con la real. En nuestro ejemplo es /usr/local/bin/tun2socks.

Script de redirección de tráfico

Ahora veamos el script que automatiza el proceso de configuración del dispositivo TUN, iptables y el arranque de tun2socks.

Nota importante: Para el correcto funcionamiento con systemd, modificaremos un poco el script para que tun2socks se ejecute en segundo plano y el script pueda finalizar, dejando a systemd el control del proceso tun2socks.

#!/bin/bash
set -euo pipefail

# Configuración
TUN_DEV="tun0" # Nombre del dispositivo TUN
TUN_ADDR="10.0.0.2/24" # Dirección IP para el dispositivo TUN
FWMARK="100" # Marca para el tráfico
ROUTE_TABLE="100" # Número de la tabla de enrutamiento
CONTAINER_IP="172.29.172.2" # Dirección IP de su contenedor cuyo tráfico debe redirigirse
SOCKS_PROXY="socks5://username:password@xxx.xxx.xxx.xx:yyyyy" # Dirección del proxy SOCKS5 (con autenticación)
TUN2SOCKS_BIN="/usr/local/bin/tun2socks" # Ruta al ejecutable tun2socks

# Ruta al archivo PID que será usado por systemd
PID_FILE="/var/run/tun2socks.pid"

# Función para limpiar reglas
cleanup() {
    echo "[INFO] Limpiando rutas antiguas e iptables..."
    # Eliminamos las reglas en orden inverso al de creación
    iptables -t nat -D POSTROUTING -o "$TUN_DEV" -j MASQUERADE 2>/dev/null || true
    iptables -t mangle -D PREROUTING -s "$CONTAINER_IP" -p tcp -j MARK --set-mark "$FWMARK" 2>/dev/null || true

    ip route flush table "$ROUTE_TABLE" 2>/dev/null || true
    ip rule del fwmark "$FWMARK" table "$ROUTE_TABLE" priority "$FWMARK" 2>/dev/null || true

    ip link set "$TUN_DEV" down 2>/dev/null || true
    ip tuntap del dev "$TUN_DEV" mode tun 2>/dev/null || true

    # Eliminamos el archivo PID
    rm -f "$PID_FILE" 2>/dev/null || true
}

# Comprobamos los argumentos de la línea de comandos
if [ "$#" -eq 1 ] && [ "$1" == "cleanup_only" ]; then
    cleanup
    echo "[INFO] Limpieza completada."
    exit 0
fi

# Llamamos a cleanup al inicio para garantizar un estado limpio, si no es modo cleanup_only
cleanup

echo "[INFO] Creando $TUN_DEV..."
ip tuntap add dev "$TUN_DEV" mode tun
ip addr add "$TUN_ADDR" dev "$TUN_DEV"
ip link set "$TUN_DEV" up

echo "[INFO] Configurando ip rule e iptables..."
ip rule add fwmark "$FWMARK" table "$ROUTE_TABLE" priority "$FWMARK"
ip route replace default dev "$TUN_DEV" table "$ROUTE_TABLE"

iptables -t mangle -A PREROUTING -s "$CONTAINER_IP" -p tcp -j MARK --set-mark "$FWMARK"
iptables -t nat -A POSTROUTING -o "$TUN_DEV" -j MASQUERADE

echo "[INFO] Iniciando tun2socks..."
"$TUN2SOCKS_BIN" \
  --device "$TUN_DEV" \
  --proxy "$SOCKS_PROXY" \
  --loglevel info &

# Guardamos el PID de tun2socks para systemd
echo $! > "$PID_FILE"

echo "[INFO] Configuración completada. tun2socks en ejecución."

Desglose del script

Vamos a desglosar con más detalle lo que hace cada parte del script:

Configuración

Al inicio del script se definen las variables clave:

• TUN_DEV: Nombre de la interfaz de red virtual (por ejemplo, tun0).
• TUN_ADDR: Dirección IP y máscara de subred que se asignarán a TUN_DEV. Esta dirección se usará como puerta de enlace para el contenedor.
• FWMARK: Marca numérica arbitraria que se usará para marcar los paquetes que deben redirigirse.
• ROUTE_TABLE: Número de la tabla de enrutamiento de usuario a la que se enviará el tráfico marcado.
• CONTAINER_IP: ¡Parámetro críticamente importante! Es la dirección IP de su contenedor cuyo tráfico desea redirigir. Deberá averiguarla.
• SOCKS_PROXY: Dirección completa de su proxy SOCKS5, incluyendo protocolo, usuario, contraseña y puerto.
• PID_FILE: Ruta al archivo donde se guardará el PID del proceso tun2socks para el seguimiento por parte de systemd.

Función cleanup

La función cleanup() se encarga de eliminar todas las reglas iptables, rutas y el propio dispositivo TUN creados anteriormente. Esto es importante para asegurar un estado “limpio” antes de cada nueva configuración y al detener el servicio. También elimina el archivo PID.

Lógica de arranque y limpieza

El script comprueba los argumentos de la línea de comandos. Si se ejecuta con el argumento cleanup_only, solo ejecuta la función cleanup y finaliza. En caso contrario, primero limpia configuraciones previas y luego procede a crear las nuevas.

Creación del dispositivo TUN

• ip tuntap add dev "$TUN_DEV" mode tun: Crea una nueva interfaz TUN con el nombre indicado.
• ip addr add "$TUN_ADDR" dev "$TUN_DEV": Asigna la dirección IP al dispositivo TUN creado.
• ip link set "$TUN_DEV" up: Activa la interfaz TUN.

Configuración de ip rule e iptables

Este es el corazón del mecanismo de redirección de tráfico:

• ip rule add fwmark "$FWMARK" table "$ROUTE_TABLE" priority "$FWMARK": Crea una regla de enrutamiento que dice: “cualquier paquete con la marca FWMARK debe ser procesado usando la tabla de enrutamiento ROUTE_TABLE”. La prioridad FWMARK garantiza que esta regla se considere antes que otras.

• ip route replace default dev "$TUN_DEV" table "$ROUTE_TABLE": Dentro de nuestra tabla especial ROUTE_TABLE establecemos la ruta por defecto que apunta a nuestro dispositivo TUN. Esto significa que todo el tráfico que entre en esta tabla se dirigirá a través de TUN_DEV.

• iptables -t mangle -A PREROUTING -s "$CONTAINER_IP" -p tcp -j MARK --set-mark "$FWMARK": Esta regla de iptables en la cadena PREROUTING (que procesa paquetes antes de que pasen por el enrutamiento) en la tabla mangle (usada para modificar paquetes). Dice: “si un paquete TCP proviene de CONTAINER_IP, márcalo con la marca FWMARK”. Así identificamos el tráfico que queremos redirigir.

Importante: en este esquema solo se envía a través del proxy el tráfico TCP. La regla marca paquetes con -p tcp, por lo que el tráfico UDP del contenedor, incluidos las consultas DNS, sale directamente por la puerta de enlace principal. tun2socks soporta UDP, pero para ello el servidor SOCKS5 debe soportar UDP ASSOCIATE y habría que añadir UDP a la regla. Si es importante que el DNS no salga fuera del proxy, o marque también UDP, o configure en el contenedor un servidor DNS accesible a través del proxy por TCP.

• iptables -t nat -A POSTROUTING -o "$TUN_DEV" -j MASQUERADE: Esta regla en la tabla nat en la cadena POSTROUTING (que procesa los paquetes justo antes de enviarlos). Realiza mascarading (SNAT), es decir, cambia la IP origen de los paquetes salientes que pasan por TUN_DEV a la IP asociada a TUN_DEV. Esto es necesario para el correcto funcionamiento del proxy.

Arranque de tun2socks

• "$TUN2SOCKS_BIN" --device "$TUN_DEV" --proxy "$SOCKS_PROXY" --loglevel info &: Inicia tun2socks. Se vincula al TUN_DEV creado y usa el SOCKS_PROXY indicado para redirigir todo el tráfico que llega a TUN_DEV. & lo ejecuta en segundo plano, --loglevel info establece el nivel de registro (debug es útil para depuración). tun2socks no tiene los flags --nohup ni --log-level — con ellos el programa no se iniciará.

• echo $! > "$PID_FILE": Guarda el PID del proceso tun2socks que acaba de iniciarse en segundo plano, para que systemd pueda rastrearlo.

Cómo usar (con systemd)

Ahora que el script está listo, podemos integrarlo con systemd para una gestión cómoda.

1. Guarde el script: Cree un archivo, por ejemplo, /usr/local/bin/tun2socks_redirect.sh, y pegue en él el contenido del script modificado.

   bash Copy

   sudo nano /usr/local/bin/tun2socks_redirect.sh

2. Hágalo ejecutable:

   bash Copy

   sudo chmod +x /usr/local/bin/tun2socks_redirect.sh

3. Determine la dirección IP del contenedor: Si usa Docker, puede obtener la IP del contenedor ejecutando docker inspect <nombre_contenedor> | grep "IPAddress".

4. Actualice CONTAINER_IP y SOCKS_PROXY: Asegúrese de cambiar los valores CONTAINER_IP y SOCKS_PROXY en el script /usr/local/bin/tun2socks_redirect.sh por los suyos.

Creación del fichero Unit de systemd

Creemos el archivo unit de systemd para nuestro servicio.

1. Cree el archivo /etc/systemd/system/tun2socks-redirect.service:

   bash Copy

   sudo nano /etc/systemd/system/tun2socks-redirect.service

2. Pegue el siguiente contenido:

   ini Copy

   [Unit]
   Description=Tun2socks Traffic Redirection Service
   After=network-online.target
   Wants=network-online.target
   
   [Service]
   Type=forking
   # Usamos Type=forking porque nuestro script inicia tun2socks en segundo plano
   # y finaliza por sí mismo; el proceso tun2socks permanece en ejecución dentro del grupo del servicio.
   # PIDFile se usa para rastrear el PID de tun2socks.
   PIDFile=/var/run/tun2socks.pid
   ExecStartPre=/usr/local/bin/tun2socks_redirect.sh
   # ExecStart es el comando que systemd va a supervisar.
   # Como nuestro script ya inicia tun2socks en segundo plano, systemd lo rastreará mediante PIDFile.
   ExecStart=/bin/true
   # ExecStopPost se ejecuta después de detener el servicio, para limpieza
   ExecStopPost=/usr/local/bin/tun2socks_redirect.sh cleanup_only
   # User=root - ya que el script requiere privilegios root
   User=root
   Restart=on-failure
   RestartSec=5s
   
   [Install]
   WantedBy=multi-user.target

Explicaciones del fichero Unit:

• [Unit]:
  • Description: Breve descripción del servicio.
  • After=network-online.target: El servicio se iniciará después de que la red esté completamente configurada.
  • Wants=network-online.target: Indica una dependencia deseada de la red.
• [Service]:
  • Type=forking: Indica a systemd que el proceso principal del servicio “forkea” un proceso hijo (nuestro tun2socks) y el proceso padre (el script) finalizará. systemd usará PIDFile para rastrear el proceso real del servicio.
  • PIDFile=/var/run/tun2socks.pid: Ruta al archivo donde nuestro script guarda el PID de tun2socks. Esto es crítico para Type=forking.
  • ExecStartPre=/usr/local/bin/tun2socks_redirect.sh: Comando que se ejecuta antes del inicio principal del servicio. Aquí nuestro script configura el dispositivo TUN y las reglas de iptables, y además inicia tun2socks en segundo plano.
  • ExecStart=/bin/true: Dado que tun2socks ya fue iniciado por nuestro script ExecStartPre y systemd lo supervisa mediante PIDFile, no necesitamos ejecutar nada más en ExecStart. /bin/true simplemente devuelve un código de salida exitoso.
  • ExecStopPost=/usr/local/bin/tun2socks_redirect.sh cleanup_only: Comando que se ejecuta después de detener el servicio. Con el argumento cleanup_only el script solo realiza la limpieza de las reglas.
  • User=root: El servicio debe ejecutarse como root, ya que modifica la configuración de red y las reglas iptables.
  • Restart=on-failure: Si el servicio termina con error, systemd intentará reiniciarlo.
  • RestartSec=5s: Retraso antes de intentar reiniciar.
• [Install]:
  • WantedBy=multi-user.target: El servicio se iniciará al arrancar el sistema en modo multiusuario.

Habilitar y arrancar el servicio Systemd

Tras crear el fichero Unit y ajustar el script:

1. Recargue el daemon de systemd:

   bash Copy

   sudo systemctl daemon-reload

2. Habilite el servicio para que se inicie automáticamente al arrancar:

   bash Copy

   sudo systemctl enable tun2socks-redirect.service

3. Inicie el servicio:

   bash Copy

   sudo systemctl start tun2socks-redirect.service

4. Compruebe el estado del servicio:

   bash Copy

   sudo systemctl status tun2socks-redirect.service

   Debería ver que el servicio está activo (active (running)).

5. Revise los registros:

   bash Copy

   journalctl -u tun2socks-redirect.service -f

   Esto le ayudará a seguir la salida del script y de tun2socks.

Ahora su servicio se iniciará automáticamente al arrancar el sistema y tratará de mantener en funcionamiento tun2socks y las reglas de enrutamiento. Para detener el servicio use sudo systemctl stop tun2socks-redirect.service, y se limpiarán las reglas automáticamente. Para reiniciarlo: sudo systemctl restart tun2socks-redirect.service.

Conclusión

De este modo hemos configurado un sistema que redirige todo el tráfico TCP de un contenedor especificado a través de un servidor proxy SOCKS. Si necesita redirigir todo el tráfico del sistema, y no solo de un contenedor, vea el artículo Redirigir todo el tráfico del sistema a través de un proxy SOCKS5 con tun2socks. Este método ofrece flexibilidad y control sobre el tráfico de red, permitiéndole gestionar fácilmente su enrutamiento a través de servicios proxy externos, y la integración con systemd mejora significativamente la fiabilidad y la comodidad de la gestión.

Espero que este artículo le haya sido útil. Si tiene preguntas o sugerencias, no dude en dejar comentarios.