Configurar un puente Tor con obfs4 en un VPS

Qué es un puente Tor y por qué existe

Un puente Tor es un punto de entrada a la red Tor cuya dirección no se publica en la lista pública de repetidores. Esa lista, denominada consenso, es un documento firmado que cualquiera puede descargar, y un censor también lo hace. Bloquear Tor a partir de ella lleva una tarde: obtener el consenso y luego descartar todas las direcciones que contiene en el perímetro. Los puentes existen porque la lista publicada es el punto débil. Las direcciones de los puentes se entregan de pocas en pocas, por lo que ninguna solicitud individual revela el conjunto completo.

Una dirección no listada es solo la mitad de la solución. La inspección profunda de paquetes (DPI), que clasifica el tráfico por su contenido en lugar de por su dirección, reconoce una conexión Tor por la forma de su handshake de TLS (transport layer security). Un censor sin lista aún puede detectar que "esto parece Tor" y descartar la conexión. Un pluggable transport elimina esa señal. Envuelve el flujo de Tor en otra cosa en el lado del cliente, y su puente lo desenvuelve.

obfs4 es el transporte que ejecutan la mayoría de los puentes. Convierte el flujo en bytes sin cabecera y sin un handshake fijo, por lo que el DPI no tiene ningún patrón con el que coincidir. También autentica al cliente. El valor cert= dentro de una línea de puente es una clave que el cliente debe demostrar que posee antes de que el puente responda, lo que frustra el sondeo activo: un censor que se conecte a su dirección para probar si habla Tor no recibirá respuesta y no aprenderá nada.

¿Qué transporte conectable debería ejecutar?

• obfs4 requiere un VPS, dos puertos TCP y no necesita un nombre de dominio. Es la opción útil más sencilla de implementar y el tema central de esta guía.
• WebTunnel oculta la conexión dentro del tráfico HTTPS ordinario hacia un sitio web real. El Tor Project especifica como requisitos una dirección IPv4 estática, un dominio bajo su control, un servidor web funcional como NGINX o Apache, un certificado TLS válido y al menos 1 GB de RAM (se recomiendan 4 GB). Es adecuado para redes donde el tráfico de aspecto aleatorio resulta sospechoso por sí mismo, ya que un país que apenas permite el acceso a la navegación web sigue permitiendo HTTPS.
• Snowflake es una contribución diferente. Los voluntarios ejecutan proxies WebRTC de corta duración, por lo que los puntos de entrada cambian constantemente y no existe una dirección estable que un censor pueda bloquear. Usted no opera un puente para este sistema. Usted ejecuta un proxy y este no necesita una dirección fija.

Comience con obfs4. Puede añadir un puente WebTunnel más adelante, en una segunda dirección: ejecutar ambos en una misma IP implica que una sola dirección bloqueada inhabilitará ambos servicios.

¿Qué coste tiene ejecutar un bridge?

[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

A fecha de agosto de 2026, el Tor Project solicita para un bridge al menos 1 Mbit/s de ancho de banda de subida y bajada. Para un guard o middle relay se solicitan 10 Mbit/s, con 16 Mbit/s recomendados. Estos son requisitos publicados, no mediciones. Un bridge nuevo suele situarse muy por debajo de su propio mínimo durante semanas. La misma página de requisitos solicita para un relay al menos 100 GByte de tráfico saliente al mes, lo cual ya cubren los planes más pequeños, así que consulte cuánto cuesta realmente un VPS pequeño al mes antes de dimensionar algo mayor.

La superficie de abuso es pequeña, y esta es la parte que la gente malinterpreta. Un bridge es el primer salto. El tráfico que sale de su servidor va hacia otro relay de Tor, nunca hacia un sitio web elegido por el usuario. Su dirección IP nunca aparece en el registro web de un extraño como origen de una petición, por lo que los correos de queja que gestionan los operadores de exit relays no llegan aquí. Revise de todos modos la política de uso aceptable de su proveedor, ya que algunos hosts tratan cualquier servicio Tor como un caso especial.

Una cosa que no debe hacer: convertir un relay público existente en un bridge en la misma dirección. El consejo del Tor Project para ese caso es cambiar la "dirección IP, nombre y huella digital", porque la dirección antigua ya está en el consenso que descargan los censores. Un bridge que fue un relay público la semana pasada es un bridge que ya está en una lista de bloqueo.

El tiempo de actividad (uptime) importa más que la velocidad. Los requisitos de los relays dicen que "si su relay no está funcionando durante más de 2 horas al día, su utilidad es limitada", y un bridge está en peor situación que un relay en este aspecto, porque cada cliente tiene una única dirección y no dispone de alternativa. Un reinicio desconecta a todos los usuarios. Configure una comprobación de puerto TCP en Uptime Kuma contra el puerto obfs4 para que sepa el día que deja de responder.

Instalar Tor desde el repositorio del Tor Project

Los paquetes de la distribución suelen estar desactualizados. Un bridge es software de seguridad y debe mantenerse al día. Primero, añada el repositorio oficial del proyecto.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget lsb-release
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

Ahora cree el archivo de fuentes. La línea Suites: debe contener el nombre en clave de su versión, así que léalo del sistema en lugar de escribirlo de memoria.

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring obfs4proxy

Si apt update informa que el repositorio no tiene un archivo Release para su nombre en clave, el Tor Project no ofrece soporte para esa versión. Elimine /etc/apt/sources.list.d/tor.sources, ejecute sudo apt update de nuevo e instale el paquete tor que ofrece su distribución. Todo lo que sigue a continuación es idéntico.

El paquete obfs4proxy proviene directamente de Debian y Ubuntu (versión 0.0.14 en Debian 13, a fecha de agosto de 2026). Confirme dónde se instaló el binario, ya que su ruta debe incluirse en la configuración:

command -v obfs4proxy || command -v lyrebird

El proyecto cambió su nombre a lyrebird, por lo que es posible que un paquete más reciente instale /usr/bin/lyrebird en su lugar. Utilice la ruta que devuelva ese comando.

Configurar el bridge en /etc/tor/torrc

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

Cada una de estas líneas conlleva un posible fallo, así que analícelas una por una.

BridgeRelay 1 indica a tor que envíe su descriptor a la autoridad de bridges en lugar de al consenso público. Esta única línea es la que hace que el relay no aparezca en los listados.

ORPort es el puerto OR real de Tor. Debe ser accesible desde Internet, ya que tor lo comprueba y se niega a publicar un descriptor hasta que dicha prueba sea exitosa.

ServerTransportPlugin proporciona a tor el comando que debe ejecutar. tor inicia obfs4proxy como un proceso hijo y se comunica con él a través de una tubería (pipe), por lo que obfs4proxy no tiene su propia unidad de servicio y nunca aparece en systemctl status.

ServerTransportListenAddr fija el puerto en el que escucha obfs4proxy. Si omite esta línea, obfs4proxy elegirá un puerto libre al iniciarse y uno diferente tras la mayoría de los reinicios; por tanto, cada línea de bridge que haya distribuido apuntará a un puerto donde no hay nada escuchando. Esos clientes recibirán una conexión rechazada y dejarán de intentarlo.

ExtORPort auto abre el ORPort extendido, un canal de loopback que obfs4proxy utiliza para devolver las conexiones finalizadas a tor junto con la dirección del cliente. La guía de configuración de The Tor Project lo incluye en todos los bridges, ya que sin él el transporte no puede informar de dicha dirección a tor.

ContactInfo y Nickname son ambos públicos. Utilice una dirección que consulte habitualmente, ya que es el medio por el cual The Tor Project le contactará si su bridge falla, y elija un apodo que no le identifique si prefiere mantener el anonimato.

BridgeDistribution elige qué distribuidor entrega su dirección a los usuarios. Los valores aceptados son https, email, telegram, settings, none y any. Utilice any para un primer bridge y deje que el sistema decida. Utilice none para un bridge privado que usted mismo distribuya, lo cual mantiene la dirección fuera de la distribución pública por completo.

Por qué es importante la elección del puerto

Evite usar 9001 para ambos puertos. El Tor Project lo desaconseja explícitamente, ya que 9001 es el ORPort tradicional y los sistemas de censura escanean internet en su búsqueda. Ambos puertos deben ser distintos entre sí, dado que tor y obfs4proxy abren sus propios listeners por separado.

El puerto más robusto para obfs4 es el 443. El tráfico saliente por el puerto 443 está permitido en casi cualquier red restringida, y una conexión persistente a este puerto aparenta ser una sesión web convencional. Vincular un puerto inferior a 1024 requiere un paso adicional, ya que obfs4proxy no se ejecuta como root:

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

Añada estas dos líneas en cada editor que se abra:

[Service]
NoNewPrivileges=no

La capacidad por sí sola no es suficiente. La directiva NoNewPrivileges de systemd impide que un proceso obtenga privilegios que su proceso padre no poseía, y una capacidad de archivo es precisamente eso; por tanto, obfs4proxy no podrá vincular el puerto 443 mientras esta configuración permanezca activa.

Si prefiere omitir este paso, elija un puerto alto poco llamativo y anótelo. Independientemente de lo que elija, no cambie el puerto de obfs4 posteriormente. Una línea de puente (bridge line) vincula la dirección, el puerto, la huella digital (fingerprint) y el certificado; por lo tanto, cualquier copia guardada en el navegador de un usuario dejará de funcionar en el momento en que se modifique el puerto.

Abra los puertos en ambos firewalls

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

Ambos puertos deben estar abiertos. La mayoría de los proveedores ejecutan un segundo firewall en su panel de control que ufw desconoce. Una regla que existe en el servidor pero no en el panel crea un puente que nunca es alcanzable y nunca publica un descriptor. Si alguna de estas partes es nueva, las reglas de ufw que necesita un VPS nuevo y qué es realmente un puerto en escucha en Linux cubren el tema. Mientras realiza esto, restrinja SSH con claves y una configuración de sshd endurecida. Un puente no listado en un servidor con SSH por contraseña sigue siendo un servidor con SSH por contraseña.

Inícielo y luego lea el registro

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian y Ubuntu incluyen dos unidades. tor.service es un pequeño envoltorio y tor@default.service es el proceso que realiza el trabajo; por eso journalctl -u tor parece casi vacío, mientras que el registro que necesita se encuentra en tor@default.

Dos líneas indican que funcionó:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

La primera significa que la prueba de alcanzabilidad fue exitosa y el descriptor se envió a la autoridad de puente. Si nunca aparece, algo entre internet y su servidor está descartando el tráfico hacia el ORPort. La segunda línea debe mostrar el puerto que configuró. Un puerto distinto ahí significa que tor nunca aplicó ServerTransportListenAddr, y la causa habitual es un nombre de transporte que no coincide: debe decir obfs4 en ambas directivas.

Confirme que los dos oyentes existen:

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

¿Dónde está mi línea de bridge?

obfs4proxy escribe una plantilla en el directorio de datos de tor:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

Ese directorio pertenece al usuario tor y tiene permisos 700, por lo que sin sudo obtendrá Permission denied. El archivo contiene una línea con este formato:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Reemplace <IP ADDRESS> con la dirección pública de su servidor, <PORT> con el puerto de obfs4 y no con el ORPort, y <FINGERPRINT> con la huella digital de identidad que tor escribió en su directorio de datos:

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

El primer archivo contiene su apodo y la huella digital de identidad que debe ir en una línea de bridge. El segundo contiene la huella digital cifrada, que es la que debe pegar en Relay Search para comprobar si su bridge está en ejecución y aproximadamente cuántos clientes lo utilizan. Ambos no son intercambiables. Una línea de bridge que contenga el valor cifrado no coincide con la clave de identidad que presenta su bridge, por lo que el cliente rechaza la conexión que acaba de abrir.

¿Cómo llega realmente un bridge a los usuarios?

Usted no entrega su línea de bridge a nadie. Una vez que el descriptor llega a la autoridad de bridges, el sistema de distribución (rdsys, el sucesor de BridgeDB) asigna su bridge a un distribuidor, y los usuarios solicitan bridges a dicho distribuidor. A fecha de agosto de 2026, las rutas son las siguientes:

• El formulario web en bridges.torproject.org/options, que entrega líneas de bridge tras completar un captcha.
• Correo electrónico a bridges@torproject.org desde una dirección de Gmail o Riseup, que responde con líneas de bridge. La restricción de proveedores existe porque las cuentas gratuitas ilimitadas permitirían a un censor enumerar todos los bridges.
• El bot de Telegram @GetBridgesBot. Envíe /start, luego /obfs4 o /webtunnel.
• El propio Tor Browser, en Ajustes y luego Conexión, donde "Solicitar bridges" los obtiene a través del canal moat.

Un bridge nuevo aparece en Relay Search unas tres horas después de su configuración. Los usuarios tardan mucho más: la propia documentación del Tor Project indica que "puede llevar varios días o semanas hasta que vea un conjunto constante de usuarios". Una primera quincena sin actividad es normal, no es un fallo.

Configurar BridgeDistribution none excluye al bridge de todo este proceso. En ese caso, la línea de bridge queda bajo su control para que usted la envíe a las personas que la necesiten, a través de un canal que el censor no esté vigilando.

Cuando algo no funciona

No hay línea de autodiagnóstico en el registro. El ORPort no es alcanzable. Pruébelo desde otra máquina con nc -vz your.ip 8443. Un bloqueo significa que los paquetes están siendo descartados, así que revise ufw y el panel de control de su proveedor. Un rechazo significa que tor no está escuchando, así que revise ss -lntp y lea el registro en busca de un error de configuración.

El transporte registrado muestra un puerto que usted no eligió. tor ignoró ServerTransportListenAddr. El nombre del transporte debe coincidir exactamente con el que aparece en ServerTransportPlugin, y ambos deben estar en obfs4.

obfs4proxy no puede enlazar el puerto 443. Confirme la capacidad con getcap /usr/bin/obfs4proxy, luego confirme que la anulación llegó a la unidad con systemctl show tor@default -p NoNewPrivileges. Si eso imprime NoNewPrivileges=yes, su archivo de configuración adicional se aplicó a una unidad que no está en ejecución.

No hay nada dentro de /var/lib/tor/pt_state/. tor nunca inició el transporte, lo que significa que la ruta en ServerTransportPlugin es incorrecta. Compárela con la salida de command -v obfs4proxy.

Los clientes dejaron de conectarse tras un cambio. Cualquier cambio en la dirección o en el puerto obfs4 invalida todas las líneas de puente ya distribuidas. Compruebe si la IP pública del servidor también cambió, lo cual ocurre al reconstruir el servidor con algunos proveedores.

tor no inicia en absoluto. Ejecute sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. Esta herramienta analiza el archivo, imprime la línea que causa el conflicto y no afecta al servicio en ejecución.

FAQ

¿Se quejará mi proveedor de VPS por un puente Tor?

Un puente es un punto de entrada, por lo que el tráfico que sale de su servidor va hacia otros repetidores Tor y nunca hacia un sitio elegido por el usuario. Su dirección IP no aparece en los registros web de nadie como origen de una petición, que es lo que genera las quejas que gestionan los operadores de repetidores de salida. Las normas de alojamiento varían y algunos proveedores tratan cualquier servicio Tor como un caso especial, así que lea la política de uso aceptable antes de empezar y coloque una dirección que usted lea en ContactInfo.

¿Cuánto ancho de banda consume un puente Tor?

El mínimo publicado es de 1 Mbit/s de subida y bajada, frente a los 10 Mbit/s de un repetidor de guardia o intermedio. El uso real comienza cerca de cero, porque su puente solo transporta tráfico para los usuarios que un distribuidor le envía. Si desea un límite estricto, configure RelayBandwidthRate y RelayBandwidthBurst en torrc.

¿Por qué nadie se ha conectado a mi nuevo puente?

Un puente tarda unas tres horas en aparecer en Relay Search, y la guía del Tor Project indica que un conjunto constante de usuarios tarda varios días o semanas. Compruebe que el descriptor se haya publicado, que es la línea de autocomprobación en journalctl -u tor@default, busque su huella digital (fingerprint) con hash en Relay Search y confirme que BridgeDistribution no esté configurado como none.

¿Debo ejecutar obfs4 o WebTunnel?

Ejecute obfs4 si este es su primer puente: un VPS, dos puertos, sin dominio, sin certificado. Ejecute WebTunnel donde el tráfico de aspecto aleatorio esté bloqueado, ya que requiere un dominio que usted controle, un servidor web real, un certificado TLS válido y al menos 1 GB de RAM. Colóquelos en direcciones separadas si ejecuta ambos, porque de lo contrario una IP bloqueada eliminaría dos puentes a la vez.

¿Qué ocurre si cambio el puerto de obfs4 más tarde?

Cada línea de puente ya distribuida deja de funcionar. Una línea de puente vincula la dirección, el puerto, la huella digital y el certificado; por lo tanto, un cliente que tenga la línea antigua abre una conexión a un puerto donde no hay nada escuchando y se rinde. Lo mismo se aplica cuando cambia la IP pública del servidor. Elija el puerto durante la configuración y no lo modifique.