Redirigir todo el tráfico del sistema a través de un proxy SOCKS5 con tun2socks

Las herramientas estándar como proxychains a menudo fallan cuando se trata de aplicaciones multihilo, binarios Go/Rust, aplicaciones Electron y servicios del sistema. Aquí entra en juego tun2socks — una herramienta que crea una interfaz de red virtual TUN, intercepta todo el tráfico IP del sistema y lo encapsula de forma transparente en SOCKS5.

A continuación se presenta una guía exhaustiva para elegir la implementación, configurarla en Ubuntu/Debian y resolver problemas típicos.

Comparación de implementaciones actuales (en 2026)

A lo largo de los años desde la aparición del concepto han surgido varias versiones de la utilidad. Elegir la correcta te ahorrará muchos quebraderos de cabeza.

En esta guía se pone el foco en xjasonlyu/tun2socks v2 como la solución más estable y cómoda.

Cómo funciona (Arquitectura)

1. Se crea una interfaz de red virtual tun0.
2. Todo el sistema (o aplicaciones concretas) envían el tráfico a tun0 mediante la tabla de enrutamiento.
3. tun2socks lee paquetes del TUN, los procesa mediante el stack en espacio de usuario (gVisor) y los encapsula en peticiones al proxy SOCKS5.
4. Las respuestas del proxy se devuelven al TUN y se entregan a las aplicaciones originales.

Peligro principal — bucle de red (Routing Loop). Si el tráfico desde tun2socks hacia el propio servidor SOCKS5 también entra en el túnel, se producirá una recursión infinita que colapsará Internet y sobrecargará la CPU al 100%.

Método básico: Enrutamiento global

Este método encapsula en el proxy todo el tráfico del sistema operativo.

Paso 1: Instalación de tun2socks

Descargamos el binario actual desde la página de releases de GitHub:

# Descargar la última versión (arquitectura amd64)
wget https://github.com/xjasonlyu/tun2socks/releases/latest/download/tun2socks-linux-amd64.zip

unzip tun2socks-linux-amd64.zip
sudo mv tun2socks-linux-amd64 /usr/local/bin/tun2socks
sudo chmod +x /usr/local/bin/tun2socks

# Verificación
tun2socks --version

Paso 2: Creación de la interfaz TUN

Creamos la interfaz en espacio kernel y le asignamos la subred 198.18.0.0/15 (RFC 2544, no interfiere con redes locales habituales).

sudo ip tuntap add dev tun0 mode tun user $USER
sudo ip addr add 198.18.0.1/15 dev tun0
sudo ip link set dev tun0 up mtu 9000

Nota: MTU 9000 (Jumbo Frames) se recomienda para mejorar el rendimiento si tu proxy lo soporta. De lo contrario mantén los 1500 por defecto.

Paso 3: Protección contra bucles de red

Supongamos que tu proxy está en un servidor remoto.

• IP del servidor SOCKS5: 93.184.216.34
• Puerta de enlace del proveedor: 192.168.1.1
• Tu interfaz: eth0

# 1. Enrutamos de forma fija el tráfico hacia el proxy a través de la puerta de enlace real (excluir del túnel)
sudo ip route add 93.184.216.34 via 192.168.1.1 dev eth0

# 2. Redirigimos el resto del tráfico al TUN.
# Usamos dos máscaras /1 en lugar de eliminar la puerta de enlace por defecto (0.0.0.0/0) — esto es más seguro.
sudo ip route add 0.0.0.0/1 dev tun0
sudo ip route add 128.0.0.0/1 dev tun0

(Si el proxy es local — por ejemplo, Xray en 127.0.0.1 — debes excluir la IP del servidor remoto al que Xray se conecta).

Paso 4: Solución para DNS

tun2socks de xjasonlyu no intercepta las consultas DNS automáticamente. La forma más fiable de evitar fugas es definir DNS públicos (por ejemplo, Google o Cloudflare) para que su tráfico también vaya por el túnel.

sudo tee /etc/resolv.conf <<EOF
nameserver 8.8.8.8
nameserver 1.1.1.1
EOF
# Proteger el archivo contra la sobreescritura por servicios del sistema (NetworkManager/systemd-resolved)
sudo chattr +i /etc/resolv.conf

Paso 5: Ejecución

tun2socks -device tun0 \
          -proxy socks5://user:pass@93.184.216.34:1080 \
          -loglevel info \
          -mtu 9000

Automatización con Systemd

Para no tener que reconfigurar las rutas a mano tras cada reinicio, crearemos un servicio del sistema.

Crea el archivo /etc/systemd/system/tun2socks.service:

[Unit]
Description=Tun2Socks Tunnel Service
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=root
# Ajusta las variables a tu gusto
Environment=PROXY=socks5://93.184.216.34:1080
Environment=PROXY_IP=93.184.216.34
Environment=GATEWAY=192.168.1.1
Environment=INTERFACE=eth0
Environment=MTU=9000

# Preparación de la interfaz
ExecStartPre=/bin/sh -c 'ip link set dev tun0 down 2>/dev/null || true'
ExecStartPre=/bin/sh -c 'ip tuntap del dev tun0 mode tun 2>/dev/null || true'
ExecStartPre=/bin/sh -c 'ip tuntap add dev tun0 mode tun && ip addr add 198.18.0.1/15 dev tun0 && ip link set dev tun0 up mtu $MTU'

# Enrutamiento
ExecStartPre=/bin/sh -c 'ip route add $PROXY_IP via $GATEWAY dev $INTERFACE 2>/dev/null || true'
ExecStartPre=/bin/sh -c 'ip route add 0.0.0.0/1 dev tun0 && ip route add 128.0.0.0/1 dev tun0'

# Inicio
ExecStart=/usr/local/bin/tun2socks -device tun0 -proxy ${PROXY} -loglevel info -mtu ${MTU}

# Limpieza al detener
ExecStopPost=/bin/sh -c 'ip route del 0.0.0.0/1 dev tun0 2>/dev/null || true'
ExecStopPost=/bin/sh -c 'ip route del 128.0.0.0/1 dev tun0 2>/dev/null || true'
ExecStopPost=/bin/sh -c 'ip route del $PROXY_IP via $GATEWAY dev $INTERFACE 2>/dev/null || true'
ExecStopPost=/bin/sh -c 'ip link set dev tun0 down && ip tuntap del dev tun0 mode tun'

Restart=on-failure
RestartSec=3
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW

[Install]
WantedBy=multi-user.target

Activación:

sudo systemctl daemon-reload
sudo systemctl enable --now tun2socks
sudo systemctl status tun2socks

Nivel avanzado: Policy Routing (fwmark) para enrutamiento selectivo

Cambiar la puerta de enlace por defecto no es adecuado para todos. En sistemas complejos (con Docker o un servidor VPN propio) interceptar todo el tráfico lo romperá todo. El Policy Routing permite enviar al proxy solo las aplicaciones necesarias basándose en el grupo de usuario (GID).

1. Configurar tablas de enrutamiento

Creamos tun0, pero en lugar de rutas globales creamos una tabla separada (por ejemplo, 100).

sudo ip tuntap add dev tun0 mode tun user $USER
sudo ip addr add 198.18.0.1/15 dev tun0
sudo ip link set dev tun0 up mtu 9000

# Todos los paquetes marcados con 0x1 van a la tabla 100
sudo ip rule add fwmark 0x1 table 100

# En la tabla 100 todo el tráfico se envía a tun0
sudo ip route add default dev tun0 table 100

2. Marcado vía iptables

Creamos el grupo tunapp. El tráfico de cualquier proceso que pertenezca a ese grupo irá por el proxy.

# Añadimos el grupo y tu usuario a él
sudo addgroup tunapp
sudo usermod -aG tunapp $USER

# Marcamos (fwmark 0x1) los paquetes salientes de ese grupo
sudo iptables -t mangle -A OUTPUT -m owner --gid-owner tunapp -j MARK --set-mark 0x1

3. Uso

Ejecuta tun2socks como de costumbre. Ahora todo el sistema funciona directo, sin proxy. Para ejecutar una aplicación por el túnel, usa la utilidad sg (switch group):

# Petición normal (tu IP real)
curl ifconfig.me

# Petición a través del proxy
sg tunapp -c "curl ifconfig.me"

# Ejecutar el navegador o el cliente de torrent por el túnel
sg tunapp -c "google-chrome"

Ventaja del método: garantía total de ausencia de bucles de red, ya que el cliente del proxy (por ejemplo, Xray local) se ejecuta con tu usuario normal y su tráfico no se marca.

hev-socks5-tunnel: ejecución y configuración

hev-socks5-tunnel — otra implementación de tun2socks, escrita en C y distribuida bajo MIT. Redirige conexiones TCP y paquetes UDP a SOCKS5, soporta IPv4 e IPv6 simultáneamente y funciona en Linux, Android, FreeBSD, macOS, iOS y Windows. Versión actual — 2.17.1 (12.08.2026); xjasonlyu/tun2socks, mencionado arriba, está en v2.7.0 (12.07.2026).

Cómo difiere en operación respecto a xjasonlyu/tun2socks:

• La configuración se guarda en un archivo YAML, no se pasan tantos flags por línea de comandos.
• El programa crea la interfaz TUN por sí mismo — no hace falta ip tuntap, el nombre, direcciones y MTU se definen en la configuración.
• La marca de sockets se define en la configuración (mark). Las conexiones del programa al proxy reciben esta marca y así es fácil excluirlas del túnel.
• El modo de transporte de UDP se elige por el parámetro udp: udp — UDP normal vía SOCKS5, tcp — UDP dentro de una conexión TCP.

Instalación

Los binarios para Linux (x86_64, arm64, armv7, mips y otras arquitecturas) se publican en la página de releases del proyecto:

wget https://github.com/heiher/hev-socks5-tunnel/releases/download/2.17.1/hev-socks5-tunnel-linux-x86_64
sudo install -m 755 hev-socks5-tunnel-linux-x86_64 /usr/local/bin/hev-socks5-tunnel

Construcción desde fuentes:

git clone --recursive https://github.com/heiher/hev-socks5-tunnel
cd hev-socks5-tunnel
make

Configuración mínima

Archivo /etc/hev-socks5-tunnel.yml basado en el ejemplo del README del proyecto:

tunnel:
  name: tun0
  mtu: 8500
  multi-queue: false
  ipv4: 198.18.0.1
  ipv6: 'fc00::1'
  icmp: 'off'

socks5:
  port: 1080
  address: 127.0.0.1
  udp: 'udp'
  # username: 'username'
  # password: 'password'
  mark: 438

• address y port — dirección del proxy SOCKS5; para proxies con autenticación descomenta username y password.
• mark marca las conexiones del propio programa hacia el proxy. Con esa marca se excluyen del túnel (ver enrutamiento abajo).
• Los demás parámetros — DNS integrado (mapdns), logging, timeouts, tamaños de buffer — están documentados con comentarios en conf/main.yml del repositorio.

Ejecución:

sudo hev-socks5-tunnel /etc/hev-socks5-tunnel.yml

Enrutamiento

Ejemplo del README del proyecto: todo el tráfico va a tun0 mediante una tabla de enrutamiento separada, y los paquetes con la marca 438 — las conexiones del programa al proxy — usan la tabla principal, saltándose el túnel.

sudo sysctl -w net.ipv4.conf.all.rp_filter=0
sudo sysctl -w net.ipv4.conf.tun0.rp_filter=0
sudo ip rule add fwmark 438 lookup main pref 10
sudo ip -6 rule add fwmark 438 lookup main pref 10
sudo ip route add default dev tun0 table 20
sudo ip rule add lookup 20 pref 20
sudo ip -6 route add default dev tun0 table 20
sudo ip -6 rule add lookup 20 pref 20

La marca en la regla (fwmark 438) debe coincidir con el valor mark en la configuración. Si no coinciden, las conexiones al proxy caerán en el túnel y se producirá el mismo bucle de red descrito arriba. Por qué para rp_filter es importante el valor all, y no solo el valor de la interfaz, se explica en el artículo ¿Qué es rp_filter y para qué sirve?.

Cuándo elegir hev-socks5-tunnel

Es adecuada en routers y hardware limitado donde el bajo consumo de memoria y CPU es importante, y cuando necesitas UDP e IPv6 sin configuración adicional. xjasonlyu/tun2socks es más cómodo si prefieres lanzar con flags o si necesitas otros tipos de proxy: además de SOCKS trabaja con HTTP, Shadowsocks y SSH.

Si en el proxy necesitas encaminar el tráfico de un solo contenedor y no de todo el sistema, véase tun2socks para contenedor. Si la tarea es una red privada entre dispositivos en lugar de salida a Internet a través de proxy, consulta la serie Mesh VPN.

Depuración y problemas típicos

• Bucle de red (CPU al 100%, logs llenos, sin Internet): Asegúrate de que la ruta hacia la IP del proxy esté forzada a través de la interfaz física (ip route show).
• Túnel levantado, pero sitios no cargan: Verifica el DNS (/etc/resolv.conf). Revisa los contadores de paquetes: ip -s link show tun0. Si RX aumenta y TX está en cero — tun2socks no está extrayendo paquetes del kernel (revisa los logs del servicio).
• Baja velocidad: Comprueba que el MTU coincida en la interfaz y en los argumentos del programa (-mtu 9000). Si llegas al límite del CPU (router poco potente), cambia la implementación a hev-socks5-tunnel.
• Necesitas IPv6: Añade rutas para tráfico IPv6 análogas a las de IPv4:

sudo ip -6 route add ::/1 dev tun0
sudo ip -6 route add 8000::/1 dev tun0