Ejecutando un Bridge Tor en Linux: Guía Completa obfs4 y WebTunnel

En 2026, más de 2,5 millones de personas al día llegan a una Internet libre y abierta a través de la red Tor conectando directamente a un relé — Tor Metrics sitúa esa estimación diaria por encima de los tres millones durante la mayor parte del año, y solo cuenta conexiones directas: quien entra por un bridge, que es de lo que trata esta guía, se contabiliza aparte y no está en esa cifra. Periodistas en regímenes autoritarios, activistas que organizan protestas, denunciantes que destapan casos de corrupción y ciudadanos corrientes que protegen su privacidad: todos ellos dependen de una red operada íntegramente por voluntarios.

¿El problema? Solo hay unos 2.600 bridges dando servicio a esos millones de usuarios. Los bridges son el recurso más crítico y escaso en el ecosistema Tor — son el primer punto de contacto para usuarios en países censurados, y cada nuevo bridge ayuda directamente a alguien a acceder a la información libremente.

Esta guía te enseñará todo lo que necesitas saber sobre la red Tor, el enrutamiento onion, y cómo configurar un bridge obfs4 + WebTunnel listo para producción en Linux — completo con camuflaje Nginx, endurecimiento del firewall, monitorización con Prometheus e integración con CrowdSec.

La red Tor: una introducción

¿Qué es Tor?

Tor (The Onion Router) es una red descentralizada operada por voluntarios, diseñada para proteger la privacidad de los usuarios y resistir la censura. Cuando usas Tor, tu tráfico de Internet se enruta a través de una serie de relés cifrados, lo que hace que sea extremadamente difícil para cualquiera — tu ISP, gobierno o un actor malicioso — rastrear tu actividad y asociarla contigo.

Pero Tor no es solo una herramienta de privacidad. Es una parte esencial de la infraestructura de derechos humanos. En países como China, Irán, Rusia y Myanmar, donde los gobiernos bloquean activamente el acceso a la información, Tor es a menudo la única forma para que los ciudadanos accedan a Internet sin censura.

Una breve historia

Los orígenes de Tor se remontan a los años 90 en el Laboratorio de Investigación Naval de EE.UU. (NRL), donde investigadores Paul Syverson, David Goldschlag y Michael Reed desarrollaron el concepto de enrutamiento onion — una técnica de comunicación anónima sobre una red de ordenadores. Puedes leer más sobre la historia completa de Tor en el sitio oficial.

1. 1995
   Se inventa el enrutamiento onion Hito

   Syverson, Goldschlag y Reed, en el Laboratorio de Investigación Naval de EE.UU., desarrollan el concepto de cifrado en capas para la comunicación anónima.

2. 2002
   Nace el Proyecto Tor Estándar

   Roger Dingledine y Nick Mathewson, ambos del MIT, se unen a Syverson para construir 'The Onion Router' — Tor. El código se publica como software libre con alrededor de una docena de nodos voluntarios.

3. 2004
   La EFF empieza a financiarlo Estándar

   La Electronic Frontier Foundation reconoce la importancia de Tor para los derechos digitales y aporta una financiación crítica en los primeros años. El NRL libera el código al dominio público.

4. 2006
   Se funda Tor Project, Inc. Hito

   El Proyecto Tor se convierte en una organización sin ánimo de lucro 501(c)(3) con sede en Massachusetts, lo que asegura desarrollo y gobernanza a largo plazo.

5. 2007
   Llegan los bridges Estándar

   Se desarrollan direcciones de relé secretas (bridges) para ayudar a los usuarios a esquivar firewalls en países censurados donde el directorio de Tor está bloqueado.

6. 2008
   Empieza el Navegador Tor Estándar

   Un navegador propio que empaqueta Tor en una aplicación fácil de usar y reduce drásticamente la barrera de entrada para usuarios no técnicos.

7. 2011
   Primavera Árabe Hito

   Tor desempeña un papel crítico cuando activistas de Túnez, Egipto, Libia y Siria lo usan para organizar protestas y comunicarse de forma segura pese a la censura gubernamental.

8. 2013
   Revelaciones de Snowden Obsoleto

   Las revelaciones de Edward Snowden sobre los programas de vigilancia masiva global disparan la adopción de Tor en todo el mundo.

9. 2023
   Se publica WebTunnel Estándar

   Un pluggable transport nuevo que disfraza el tráfico de Tor como HTTPS corriente, lo que lo hace casi imposible de bloquear sin daño colateral.

10. 2026
    Hoy

    ~10.000 relés, ~2.600 bridges y más de 2,5 millones de usuarios diarios en más de 200 países. La red está operada íntegramente por voluntarios.

¿Cómo funciona el enrutamiento onion?

El enrutamiento onion debe su nombre a las capas de una cebolla — tus datos se envuelven en múltiples capas de cifrado, y cada relé en el circuito “pela” una capa para revelar el siguiente destino. Ningún relé único conoce jamás tanto el origen como el destino del tráfico.

Esto es lo que lo hace seguro:

Detalles técnicos clave de la construcción de circuitos de Tor (ver también la descripción general del sistema en la especificación de Tor):

• Selección de la ruta del circuito: el cliente elige los relés al azar y evita dos relés en la misma subred /16 o en el mismo país, para ganar diversidad.
• Intercambio de claves: cada salto usa un handshake ntor (basado en Curve25519) para establecer un secreto compartido, con lo que se obtiene forward secrecy.
• Celdas de tamaño fijo: dentro de Tor todo se transmite en celdas de 512 bytes, lo que impide el análisis de tráfico por tamaño de paquete.
• Rotación de circuitos: los circuitos se rotan cada 10 minutos aproximadamente, para acotar la ventana de los ataques de correlación de tráfico.
• Autoridades de directorio: nueve servidores de confianza mantienen el consenso sobre el estado de la red, las claves de relé y los flags.

El ecosistema Tor: tipos de voluntarios

La red Tor está compuesta por diferentes tipos de nodos operados por voluntarios, cada uno sirviendo un propósito distinto:

¿Qué son los pluggable transports?

Los censores no solo bloquean Tor por IP: usan inspección profunda de paquetes (DPI) para identificar y bloquear el propio protocolo Tor. Los pluggable transports resuelven esto disfrazando el tráfico de Tor como algo completamente diferente.

En esta guía configuraremos obfs4 y WebTunnel en el mismo servidor, para maximizar el impacto con una sola máquina.

Requisitos previos

Paso 1: instalar Tor del repositorio oficial

Paso 2: instalar WebTunnel (opcional pero recomendado)

WebTunnel es un pluggable transport más reciente que disfraza las conexiones de Tor como tráfico HTTPS normal. A diferencia de obfs4 (que parece datos aleatorios), WebTunnel usa de verdad upgrades de WebSocket sobre HTTPS, lo que lo hace casi indistinguible de la navegación web legítima. El Proyecto Tor publica instrucciones de configuración oficiales y una guía para compilarlo desde el código fuente.

Paso 3: configurar tu bridge de Tor

Vamos con la configuración principal. El fichero torrc controla todo el comportamiento de Tor.

Sustituye el contenido de /etc/tor/torrc por:

# =============================================================
# Tor Bridge Configuration — obfs4 + WebTunnel
# =============================================================

# --- General Settings ---
SocksPort 0                        # Not a client — disable SOCKS
RunAsDaemon 0                      # Managed by systemd
DataDirectory /var/lib/tor
Log notice file /var/log/tor/notices.log
Log notice syslog

# --- Security Hardening ---
DisableDebuggerAttachment 1        # Prevent ptrace/debugger attachment

# --- Bridge Mode ---
BridgeRelay 1                      # This is a bridge, not a relay
PublishServerDescriptor bridge     # Publish to BridgeDB (not public directory)

# --- ORPort — IPv4 (NAT from router) + IPv6 (direct, global) ---
# IMPORTANT: Use 0.0.0.0 for NAT environments, not 127.0.0.1
ORPort 0.0.0.0:9001
ORPort [YOUR_IPV6_ADDRESS]:9001
ExtORPort auto

# --- Contact & Identity ---
ContactInfo your-email<at>example<dot>com
Nickname YourBridgeName

# --- obfs4 Transport ---
# Port 4443 must be forwarded from your router
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:4443

# --- WebTunnel Transport ---
# Listens locally; Nginx reverse-proxies HTTPS to it
ServerTransportPlugin webtunnel exec /usr/local/bin/webtunnel-server
ServerTransportListenAddr webtunnel 127.0.0.1:15000
ServerTransportOptions webtunnel url=https://YOUR-DOMAIN/YOUR-SECRET-PATH

# --- Bandwidth Limits ---
# Adjust to what your connection can sustain (example: 250 Mbps)
RelayBandwidthRate 31 MBytes       # Sustained rate
RelayBandwidthBurst 35 MBytes     # Burst allowance

# --- Memory — cap internal queue memory (OOM protection) ---
MaxMemInQueues 4096 MB

# --- Statistics ---
ConnDirectionStatistics 1          # Enable connection direction stats

# --- DoS Protection ---
DoSRefuseSingleHopClientRendezvous 1

# --- Monitoring: Prometheus Metrics ---
MetricsPort 0.0.0.0:9052
MetricsPortPolicy accept 192.168.0.0/16
MetricsPortPolicy accept 127.0.0.0/8

# --- Control Port (for Nyx monitoring tool) ---
ControlPort 9051
CookieAuthentication 1

Repasemos las secciones críticas:

Generar la ruta secreta de WebTunnel

El transporte WebTunnel usa una ruta de URL secreta que hace las veces de token de autenticación. Genera una cadena aleatoria de 24 caracteres:

7Zkw18j2NWGK9X7PiiPUQRJB

Usa ese valor en dos sitios:

1. El torrc: ServerTransportOptions webtunnel url=https://your-domain.com/YOUR_SECRET
2. La configuración de Nginx: location = /YOUR_SECRET

Paso 4: configurar Nginx para camuflaje WebTunnel

Lo bonito de WebTunnel es que tu servidor parece un sitio web completamente normal. Los visitantes ven una página HTML corriente; solo quien conoce la ruta secreta puede conectarse al bridge de Tor. Esto es camuflaje por ruta secreta. No es domain fronting: aquello usa un dominio en el SNI de TLS y otro distinto en la cabecera Host, mientras que aquí hay un solo dominio y lo que oculta el bridge es la ruta.

HTTP/1.1 200 OK
Content-Type: text/html
<html>Welcome...</html>

HTTP/1.1 101 Switching Protocols
Upgrade: websocket
Connection: Upgrade
[El tráfico de Tor circula por el túnel]

Paso 5: configurar el reenvío de puertos

Si tu servidor está detrás de un router (lo habitual en instalaciones domésticas), tienes que reenviar estos puertos desde la IP pública del router hasta la IP local de tu servidor:

Los pasos exactos dependen de tu router. El proceso general es este:

Firewall del servidor (UFW)

Si usas UFW (Uncomplicated Firewall) en tu servidor:

Si usas iptables directamente:

IPv6: sin NAT

Comprueba que el puerto IPv6 está abierto:

Paso 6: configuración de AppArmor

En sistemas Debian/Ubuntu, AppArmor puede restringir lo que Tor y obfs4proxy tienen permitido hacer. Hay que asegurarse de que el perfil de obfs4proxy permite la ejecución:

Paso 7: iniciar y verificar

Comprobar la accesibilidad externa

Desde otra máquina (o con un comprobador de puertos online), comprueba que tus puertos son accesibles:

Paso 8: monitorización con Prometheus y Grafana

Tor expone un conjunto muy completo de métricas por su MetricsPort en formato Prometheus. Con ellas puedes vigilar en tiempo real el uso de ancho de banda, las conexiones, la construcción de circuitos y la salud del relé.

Configurar el scraping de Prometheus

Añade un target de scrape para tu puente Tor en la configuración de Prometheus:

scrape_configs:
  - job_name: 'tor-bridge'
    scrape_interval: 30s
    scrape_timeout: 10s
    metrics_path: '/metrics'
    static_configs:
      - targets: ['YOUR_SERVER_IP:9052']
        labels:
          instance: 'tor-bridge'
          nickname: 'YourBridgeName'

Métricas clave que vigilar

Tor expone decenas de métricas de Prometheus. Estas son las más importantes para quien opera un puente:

Panel de Grafana

Puedes montar un panel de Grafana bastante completo con gráficas para:

1. Ancho de banda — rate(tor_relay_traffic_bytes[5m]) — throughput de entrada y salida en tiempo real
2. Conexiones — tor_relay_connections_total por tipo — quién se está conectando
3. Flags del relé — tor_relay_flag — ¿ha reconocido la red tu puente?
4. Circuitos — tor_relay_circuits_total — cuántos circuitos hay activos
5. Recursos del sistema — process_resident_memory_bytes, process_cpu_seconds_total
6. Salud — tor_relay_load_oom_bytes_total, tor_relay_load_tcp_exhaustion_total

Nyx: monitorización desde el terminal

Nyx es una interfaz de terminal para vigilar Tor en tiempo real. Se conecta al ControlPort y muestra gráficas de ancho de banda, conexiones, circuitos y configuración.

Paso 9: integración con CrowdSec (si aplica)

Si ejecutas CrowdSec en el mismo servidor (algo habitual si ya tienes Nginx), te vas a encontrar con un problema: CrowdSec está diseñado para bloquear IPs maliciosas, pero los clientes del puente Tor disparan falsos positivos. Tu propio IDS puede acabar bloqueando a usuarios legítimos de Tor que se conectan a tu puente.

La solución es un bypass de tres capas que garantiza que el tráfico de Tor no se bloquee nunca:

Capa 1: iptables — esquivar el bouncer de firewall

Inserta reglas ACCEPT para los puertos concretos de Tor antes de la CROWDSEC_CHAIN:

Capa 2: Nginx — esquivar el bouncer Lua

Si el bouncer de Nginx de CrowdSec usa un rewrite_by_lua_block a nivel de http {}, añade una excepción para tu dominio de Tor:

rewrite_by_lua_block {
    local cs = require "plugins.crowdsec.lib.crowdsec"

    -- Bypass CrowdSec for Tor bridge domain
    if ngx.var.host == "your-tor-domain.com" then
        -- Skip CrowdSec check entirely for Tor bridge traffic
    else
        local ok, err = cs.Allow(ngx.var.remote_addr)
        if not ok then
            ngx.exit(ngx.HTTP_CLOSE)
        end
    end
}

Capa 3: lista blanca en el parser de CrowdSec

Aun con lo anterior, CrowdSec seguirá analizando tus logs de Tor y puede generar decisiones locales. Crea una lista blanca en el parser para que ignore todo el tráfico hacia tu dominio de Tor:

name: custom/tor-bridge-whitelist
description: "Ignore all traffic to the Tor bridge domain"
whitelist:
  reason: "Tor bridge traffic — legitimate by definition"
  expression:
    - evt.Parsed.target_fqdn == 'your-tor-domain.com'

Para que CrowdSec detecte el target_fqdn, tus logs de Nginx tienen que incluir la variable $host. Crea un formato de log propio:

# Log format with vhost prefix for CrowdSec target_fqdn detection
log_format combined_vhost
    '$host $remote_addr - $remote_user [$time_local] '
    '"$request" $status $body_bytes_sent '
    '"$http_referer" "$http_user_agent"';

Después úsalo en el bloque de servidor de Tor:

access_log /var/log/nginx/tor.access.log combined_vhost;

Tras cualquier cambio, recarga los dos servicios:

Persistir las reglas de iptables tras un reinicio

Las reglas de bypass de iptables se pierden al reiniciar. Crea un servicio systemd que las vuelva a aplicar:

[Unit]
Description=Tor Bridge — iptables bypass for CrowdSec
After=crowdsec-firewall-bouncer.service
Wants=crowdsec-firewall-bouncer.service

[Service]
Type=oneshot
RemainAfterExit=yes

# IPv4: Accept Tor traffic before CROWDSEC_CHAIN
ExecStart=/bin/sh -c '\
  iptables  -C INPUT -p tcp --dport 4443 -j ACCEPT 2>/dev/null || \
  iptables  -I INPUT 1 -p tcp --dport 4443 -j ACCEPT; \
  iptables  -C INPUT -p tcp --dport 9001 -j ACCEPT 2>/dev/null || \
  iptables  -I INPUT 1 -p tcp --dport 9001 -j ACCEPT'

# IPv6: Same rules
ExecStart=/bin/sh -c '\
  ip6tables -C INPUT -p tcp --dport 4443 -j ACCEPT 2>/dev/null || \
  ip6tables -I INPUT 1 -p tcp --dport 4443 -j ACCEPT; \
  ip6tables -C INPUT -p tcp --dport 9001 -j ACCEPT 2>/dev/null || \
  ip6tables -I INPUT 1 -p tcp --dport 9001 -j ACCEPT'

[Install]
WantedBy=multi-user.target

Descripción general de la arquitectura

Esta es la arquitectura completa de lo que has montado:

Lista de verificación

Con todo configurado, repasa esta lista para confirmar que tu bridge funciona por completo:

Notas operativas

¿Qué sucede después de arrancar el bridge?

1. 0–1 hora
   Bootstrap y autotest Estándar

   Tor se conecta a la red, descarga el consenso y comprueba si tu ORPort es accesible. Si el autotest pasa, tu puente ya está operativo.

2. 1–24 horas
   Publicación del descriptor

   Tor publica el descriptor de tu puente en la Autoridad de Puentes. BridgeDB ya lo conoce, pero todavía no lo reparte entre los usuarios.

3. 24–48 horas
   Distribución por BridgeDB Estándar

   BridgeDB empieza a repartir tu línea de puente entre quienes piden puentes. Aquí pueden aparecer tus primeras conexiones de clientes.

4. 1–7 días
   Llegada de los flags

   Las autoridades de directorio asignan los flags según el comportamiento de tu puente. Running y Valid llegan primero; Stable exige unos 7 días de funcionamiento ininterrumpido.

5. Continuo
   Régimen estable Hito

   Tu puente está plenamente integrado en la red Tor. Vigila las métricas, mantén el software actualizado y cuida el uptime para maximizar el impacto.

Buenas prácticas de mantenimiento

Copia de seguridad de los ficheros críticos

Estos ficheros contienen la identidad de tu bridge. Perderlos significa empezar de cero con otra huella digital:

Solución de problemas

sudo aa-status | grep obfs4

ls -la /var/lib/tor/pt_state/

Cómo lo tengo montado

Cuatro nodos Tor, que es justo el motivo de que esta guía exista en lugar de ser un resumen del manual.

Dos puentes: uno en Valencia, en el mismo servidor que sirve esta página, y otro en Alicante en un mini PC en casa — ese segundo cuelga de una línea de fibra doméstica por detrás del router MikroTik, de ahí que la sección de NAT y reenvío de puertos de más arriba esté escrita como está. Los dos relays intermedios son instancias VPS de IONOS, una en Londres y otra en Madrid, porque un relay quiere ancho de banda estable y una línea residencial no lo da de forma fiable.

Sinceramente, no hay ningún incidente que contar. No ha pasado nada dramático: ni una notificación de retirada, ni una queja por abuso, ni la visita de nadie. El puente y los relays simplemente han funcionado. Merece la pena decirlo así de claro, porque la pregunta que la gente se hace antes de montar uno es “qué me va a pasar si hago esto”, y la respuesta aquí, desde una línea doméstica en España, ha sido: nada.

Dos cosas sí me sorprendieron, y ambas están en esta guía por eso.

La primera es lo que tardan los flags del consenso. Yo esperaba que el puente estuviera “funcionando” en una hora, y en sentido estricto lo estaba: Running y Valid llegan enseguida. Stable tardó aquí alrededor de una semana, y Guard algo más. Son observaciones de este despliegue, no un calendario: las autoridades de directorio asignan Stable a partir de un tiempo medio entre fallos ponderado, no de un contador de uptime a secas, y Guard exige además Stable, Fast, familiaridad y ancho de banda suficiente, así que tus fechas serán otras. La lección práctica se sostiene igual: un reinicio para cambiar una línea de configuración retrasa la medición, así que trastea en la primera hora y luego déjalo en paz.

La segunda es que CrowdSec baneó a mis propios clientes de Tor antes de que se me ocurriera excluir los puertos del puente. Desde el punto de vista del IDS, un puente es exactamente lo que parece un ataque: muchas conexiones, muchas direcciones, ningún patrón. Estaba haciendo su trabajo correctamente y el resultado seguía siendo el equivocado, que es el modo de fallo que conviene recordar: la regla que se dispara aquí es la misma que describo en los artículos del honeypot de MikroTik y del tarpit de nginx, apuntando a tráfico que sí quería.

La red te necesita

Ejecutar un bridge de Tor es una de las cosas con más impacto que puedes hacer por la libertad en Internet. Cada bridge que operas es un salvavidas directo para gente bajo censura: periodistas en Irán, activistas en China, estudiantes en Rusia, ciudadanos en Myanmar. La barrera técnica es modesta; el impacto humano, incalculable.

Si esta guía te ha resultado útil, compártela con quien pueda querer contribuir. Cuantos más bridges haya, más difícil se lo pondremos a los censores.

Y si quieres ir más allá: monta un servidor dedicado a relés de salida, el recurso más escaso y con más impacto de toda la red Tor. Esa es una guía para otro día.