Cómo configurar un repetidor Tor en un VPS Linux

Qué hace un repetidor Tor en un VPS

Un repetidor Tor es un daemon de Tor en una máquina con una dirección IP pública que reenvía tráfico cifrado para otros usuarios. Las autoridades de directorio lo publican y los clientes de Tor construyen circuitos a través de él. Un repetidor de guardia o intermedio solo entrega tráfico a otro repetidor, por lo que nunca abre una conexión a un sitio web en nombre de un tercero. Ese hecho es la razón por la que no recibe correos de abuso y por la que es la contribución que mejor se adapta a un VPS convencional.

El trabajo es mínimo: un paquete, quince líneas de configuración, una regla de firewall y un reinicio. El resto de esta guía trata sobre los puntos que suelen fallar. El cálculo del ancho de banda en un plan con límites y la razón por la que un repetidor nuevo y en perfecto estado parece inactivo durante una semana.

Guard, middle, bridge o exit: elija antes de instalar

Un mismo daemon ejecuta los cuatro roles. Su configuración, junto con las directory authorities, determina cuál de ellos desempeña.

• Middle relay. Recibe tráfico de un guard y lo transfiere a otro relay. Nunca contacta con el sitio de destino. Todo relay nuevo comienza aquí.
• Guard relay. La misma configuración, con un flag adicional. Las directory authorities otorgan el flag Guard a los relays que han sido rápidos y estables durante el tiempo suficiente. Usted no lo elige. Se gana, y la configuración que aparece a continuación es lo que permite obtenerlo.
• Bridge. Un relay que se mantiene deliberadamente fuera del directorio público y se distribuye de forma privada a usuarios en lugares donde Tor está bloqueado. Es el compromiso más pequeño de los cuatro: poco ancho de banda, sin listado público y el primer paso adecuado si su plan es modesto.
• Exit relay. El último salto, que abre la conexión con el sitio de destino. Cada petición que realiza un usuario sale desde su dirección IP, por lo que los informes de abuso y las consultas policiales llegan a quien sea el propietario de esa dirección.

El exit es el único rol que no debe alojarse en un VPS de propósito general. Ejecute un exit solo en un proveedor que haya aceptado de antemano recibir ese tipo de comunicaciones, con su propia dirección IP y un contacto de abuso publicado. La mayoría de los términos de alojamiento estándar lo prohíben, y el resultado habitual de ignorar esto es la suspensión del servidor y la pérdida de la dirección IP. Un guard o middle relay transporta el mismo tráfico de usuario sin esa exposición.

Todo lo que aparece a continuación configura un guard/middle relay. ExitRelay 0 es la línea que permite mantenerlo como tal.

Lo que el VPS necesita antes de empezar

The Tor Project publica requisitos estrictos para los repetidores. A fecha de agosto de 2026 son: una dirección IPv4 pública para el repetidor, al menos 10 Mbit/s de ancho de banda en cada dirección con 16 Mbit/s recomendados, al menos 100 GB de tráfico saliente al mes y 512 MB de RAM por debajo de 40 Mbit/s o 1 GB por encima. No existe una regla de tiempo de actividad fija, pero un repetidor que funciona menos de dos horas al día es de poca utilidad para la red.

La cifra de 10 Mbit/s describe la línea, no la configuración. Necesita un puerto capaz de alcanzar esa velocidad. Qué parte de esa línea permite usar al repetidor es una decisión independiente, tomada en función de la cuota de transferencia mensual. Lea su plan antes de tocar la configuración. Si aún está eligiendo un servidor, lo que cuesta realmente un VPS al mes cubre cómo se venden las cuotas de transferencia, y medir el rendimiento de red real de un VPS muestra cómo averiguar qué hace la línea con iperf3 en lugar de confiar en la página de ventas.

Refuerce la máquina primero. Un repetidor es un servicio público en una dirección pública, y la dirección es escaneada a los pocos minutos de ser publicada. Restringir SSH a claves y una configuración de sshd reforzada lleva diez minutos y debe hacerse antes de que el repetidor esté activo, no después.

Instalar Tor desde el repositorio del Tor Project

Utilice el repositorio apt propio del Tor Project en lugar del paquete de la distribución. El código de los nodos de retransmisión evoluciona más rápido que una versión estable, por lo que las correcciones llegan primero a este repositorio y el paquete de la distribución queda desactualizado entre lanzamientos.

sudo apt update
sudo apt install -y apt-transport-https gnupg wget

Añada la clave de firma y, a continuación, el repositorio. El nombre en clave se lee directamente de la máquina, por lo que el mismo bloque funciona en Ubuntu 24.04 (noble) y Debian 13 (trixie).

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc \
  | gpg --dearmor \
  | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

CODENAME=$(. /etc/os-release && echo "$VERSION_CODENAME")
echo "$CODENAME"

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $CODENAME
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
tor --version

tor --version muestra la versión que acaba de instalar. Si apt update devolvió un error NO_PUBKEY, la clave sin armadura no se encuentra en la ruta indicada en la línea Signed-By:, por lo que apt no dispone de una clave para verificar el archivo de lanzamiento. El paquete deb.torproject.org-keyring es importante para el futuro: incluye la clave de firma como un paquete ordinario, de modo que apt siga funcionando cuando dicha clave sea rotada.

Active las actualizaciones automáticas y configure el nuevo origen.

sudo apt install -y unattended-upgrades apt-listchanges

En Ubuntu, añada el origen de Tor al bloque Allowed-Origins en /etc/apt/apt.conf.d/50unattended-upgrades:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}-security";
        "TorProject:${distro_codename}";
};

En Debian, el mismo archivo utiliza Origins-Pattern, donde la línea a añadir es "origin=TorProject";. Verifique el resultado con sudo unattended-upgrade --debug --dry-run, que muestra los orígenes sobre los que actuará y no escribe nada.

El archivo torrc relevante

El paquete instala un /etc/tor/torrc extenso y con muchos comentarios. Solo unas pocas líneas son importantes para un repetidor. Añádalas al final del archivo.

Nickname mynicerelay
ContactInfo relay-ops[at]example.com
ORPort 9001
ExitRelay 0
SocksPort 0

Nickname debe tener entre 1 y 19 caracteres, solo letras y números. No es único en la red y no es su identidad; la huella digital (fingerprint) es lo que le identifica. Es el nombre con el que encontrará su propio repetidor en un buscador, así que elija algo que pueda deletrear por teléfono.

ContactInfo se publica dentro del descriptor del repetidor, que es un documento público que cualquiera puede descargar, por lo que la dirección será rastreada. Use una dirección que siga leyendo dentro de dos años y ofúsquela si lo desea. Este es el único canal que tiene el Tor Project para avisarle sobre un problema con su repetidor.

ORPort 9001 es el puerto al que se conectan otros repetidores y clientes. 9001 es el convencional. El puerto 443 es la otra opción común, ya que algunas redes restrictivas solo permiten tráfico saliente por el 443, por lo que un repetidor que escuche ahí es accesible para más clientes. Elija 443 solo si ningún otro servicio en la máquina lo necesita.

SocksPort 0 desactiva el proxy SOCKS local, que un repetidor no utiliza, y elimina un socket de escucha de la máquina. ExitRelay 0 escribe la intención en el archivo: este repetidor nunca se conectará a un destino en nombre de un usuario, y nadie que lea la configuración más adelante tendrá que deducirlo de los valores predeterminados.

Si el VPS tiene una dirección IPv6, añada una segunda línea ORPort. Tor no puede vincularse a "cualquier" dirección IPv6 de la misma forma que lo hace con IPv4, por lo que debe escribir la dirección entre corchetes.

ORPort 9001
ORPort [2001:db8::1]:9001

En un VPS de 1 GB, añada MaxMemInQueues 512 MB. Tor decide su límite de cola basándose en la memoria que detecta en la máquina, la cual, en un servidor compartido pequeño, es más de lo que usted desea que utilice. Establecer el límite manualmente hace que tor descarte las celdas en cola bajo presión, algo que el repetidor puede gestionar, en lugar de crecer hasta que el kernel elimine el proceso.

Abrir el ORPort en el firewall

El ORPort debe ser accesible desde cualquier punto de internet para el tráfico entrante. Para el tráfico saliente, no aplique restricciones al relay: este abre conexiones hacia miles de otros relays en múltiples puertos, y una lista blanca de salida lo inutilizará silenciosamente.

sudo ufw allow 9001/tcp comment 'tor ORPort'
sudo ufw status verbose

A continuación, verifique el firewall de red del proveedor. Muchos paneles de control ejecutan un filtro de paquetes frente a la máquina virtual; una regla añadida con ufw no tendrá efecto allí, por lo que el puerto aparecerá como abierto en el servidor pero cerrado desde el exterior. Si no está familiarizado con ufw, las reglas de ufw que todo VPS debe tener explica la política predeterminada y el orden en que se aplican las reglas.

Dimensione el ancho de banda según su plan

El manual describe RelayBandwidthRate como un bucket de tokens independiente que limita "el uso promedio de ancho de banda entrante para el tráfico retransmitido en este nodo al número de bytes por segundo especificado, y el uso promedio de ancho de banda saliente a ese mismo valor". Lea esto dos veces. El límite se aplica a cada dirección por separado. Un relay configurado a 1 Mbit/s puede mover 1 Mbit/s de entrada y 1 Mbit/s de salida al mismo tiempo, y un proveedor que contabiliza ambas direcciones factura la suma.

[
  {
    "label": "1 Mbit/s",
    "torrc_rate": "125 KBytes",
    "gb_per_day": 21.6,
    "gb_per_month": "648"
  },
  {
    "label": "2 Mbit/s",
    "torrc_rate": "250 KBytes",
    "gb_per_day": 43.2,
    "gb_per_month": "1,296"
  },
  {
    "label": "5 Mbit/s",
    "torrc_rate": "625 KBytes",
    "gb_per_day": 108,
    "gb_per_month": "3,240"
  },
  {
    "label": "10 Mbit/s",
    "torrc_rate": "1250 KBytes",
    "gb_per_day": 216,
    "gb_per_month": "6,480"
  },
  {
    "label": "20 Mbit/s",
    "torrc_rate": "2500 KBytes",
    "gb_per_day": 432,
    "gb_per_month": "12,960"
  }
]

Esas 5 filas son aritméticas, no una medición: muestran lo que cuesta una tasa si el relay la mantiene durante 30 días completos en ambas direcciones. Un relay real permanece por debajo de su límite la mayor parte del tiempo, especialmente en las primeras semanas. Utilice la tabla para descartar configuraciones que no encajan, no para predecir una factura al gigabyte.

A 1 Mbit/s en cada sentido, un relay mueve aproximadamente 21.6 GB al día, por lo que un mes de 30 días consume aproximadamente 648 GB de tráfico medido. Esto cabe dentro de una asignación de 1 TB con espacio restante para actualizaciones y copias de seguridad. Si aumenta a 2 Mbit/s, el mes cuesta 1,296 GB, lo cual ya supera un plan de 1 TB. La última fila, 20 Mbit/s, necesita 12,960 GB al mes y requiere un puerto sin límite de medición. Si su proveedor factura solo el tráfico saliente, divida cada cifra por dos. Averigüe qué tipo de facturación tiene antes de establecer la tasa, ya que las dos respuestas difieren por un factor de dos.

Ahora la configuración. Primero el límite de tasa, segundo la cuota.

RelayBandwidthRate 125 KBytes
RelayBandwidthBurst 250 KBytes
AccountingMax 400 GBytes
AccountingRule sum
AccountingStart month 1 00:00

RelayBandwidthBurst es el tamaño del bucket de tokens, por lo que permite picos cortos por encima de la tasa mientras el promedio se mantiene. Aproximadamente el doble de la tasa es un valor razonable.

AccountingRule es la línea que la mayoría de los operadores pasan por alto. El valor predeterminado es max, que mide la mayor de las dos direcciones frente a la cuota. Con el valor predeterminado, AccountingMax 400 GBytes permite 400 GB de entrada y 400 GB de salida, lo que suma 800 GB en un medidor que contabiliza ambos. AccountingRule sum contabiliza la suma de lectura y escritura frente a la cuota única, que es lo que realmente mide una asignación de transferencia.

Escriba también AccountingStart, nunca AccountingMax por sí solo. La cuota es el número y la línea de inicio es el período en el que se reinicia. Una cuota sin período deja al relay en hibernación sin nada que lo reactive.

La hibernación es un instrumento contundente. Cuando se agota la cuota, tor registra esto y deja de aceptar trabajo:

Bandwidth soft limit reached; commencing hibernation. No new connections will be accepted

El relay tampoco se reactiva exactamente al inicio del siguiente período. Tor rastrea qué tan rápido consumió la última cuota y elige un punto aleatorio dentro del nuevo intervalo, para que miles de relays no regresen a la red en el mismo segundo. Un relay que desaparece durante la última semana de cada mes pierde la estabilidad con la que las autoridades de directorio lo miden. Dimensione RelayBandwidthRate para que nunca se alcance el límite y mantenga AccountingMax como la red de seguridad que protege la factura.

Inicie el relay y confirme que es accesible

sudo systemctl restart tor@default
sudo systemctl status tor@default
sudo journalctl -u tor@default -n 50

En unos minutos, el registro debería contener esta línea:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.

Esa frase significa que otros relays se conectaron a su ORPort y establecieron un circuito a través de él. Hasta que aparezca, su relay no está en el directorio y no transporta tráfico alguno. El fallo se muestra así:

Your server has not managed to confirm reachability for its ORPort(s) at 203.0.113.10:9001. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports, address, /etc/hosts file, etc.

Revise los puntos en orden. Compruebe si el ORPort está abierto en ufw. Verifique si también está abierto en el firewall de red externo del proveedor. Asegúrese de que la dirección en ese mensaje sea la dirección a la que Internet realmente enruta hacia usted, y no una dirección privada de una configuración NAT. Pruebe el puerto desde una máquina distinta con nc -vz 203.0.113.10 9001. Tor repite la autocomprobación por sí mismo, por lo que un firewall corregido se detecta sin su intervención, y un reinicio hace que el cambio sea inmediato.

La identidad permanente de su relay es su fingerprint:

sudo cat /var/lib/tor/fingerprint

Aproximadamente tres horas después de que se publique el descriptor, el relay aparecerá en Relay Search. Busque el apodo o pegue el fingerprint. Esa página muestra lo que la red considera de su relay: qué flags posee, qué peso le asignan las autoridades y qué versión está publicando.

¿Por qué un nuevo repetidor Tor casi no recibe tráfico?

Debido a que la red aún no lo ha medido, y el proceso de medición lleva semanas. El Tor Project describe este incremento en cuatro fases, y un operador que no lo ha leído suele concluir que el repetidor está averiado y comienza a modificar configuraciones.

Durante los primeros tres días, el repetidor no está medido. Informa de su propio resultado de autodiagnóstico, y las autoridades de directorio limitan el peso publicado a 20 KB de todos modos, por lo que los clientes casi nunca lo seleccionan. Aproximadamente desde el día tres hasta el ocho, las autoridades de ancho de banda lo miden de forma real y el peso aumenta, pero solo se utiliza como salto intermedio, ya que ningún cliente está dispuesto a convertir un repetidor nuevo en su primer salto.

Alrededor del día ocho, el repetidor se vuelve elegible para la bandera Guard. Obtener esta bandera hace que el tráfico disminuya, lo cual sorprende a todos: los clientes omiten los nodos Guard al elegir saltos intermedios, asumiendo que un Guard ya está ocupado, por lo que el repetidor pierde tráfico intermedio antes de ganar tráfico de Guard. Solo se recupera a medida que los clientes rotan sus conjuntos de nodos Guard, lo que lleva semanas. Aproximadamente en el día 68 alcanza un estado estable, donde los clientes que lo eliminan se equilibran con los clientes que lo añaden.

Por lo tanto, la expectativa realista es no recibir nada durante tres días, algo después de una semana y una carga real después de dos meses. Cambie una configuración y espere una semana para ver qué efecto tuvo. Una página de estado de Uptime Kuma autohospedada con una comprobación TCP en el puerto 9001 es un mejor uso de la energía nerviosa: responde a la pregunta que realmente puede controlar, que es si el puerto sigue respondiendo.

Monitorizar el relay con nyx

nyx es el monitor de terminal para un relay en ejecución. Se comunica con el puerto de control de tor, por lo que debe habilitarlo primero en torrc:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort escucha únicamente en 127.0.0.1, y la autenticación por cookie implica que un programa debe leer un archivo secreto antes de poder enviar comandos. Tor escribe esa cookie en /run/tor/control.authcookie como el usuario debian-tor, con modo 600, para que nadie más pueda leerla. CookieAuthFileGroupReadable 1 permite el acceso al grupo, lo que permite que su propia cuenta ejecute nyx sin necesidad de sudo.

sudo apt install -y nyx
sudo adduser "$USER" debian-tor
sudo systemctl restart tor@default

Cierre la sesión y vuelva a entrar, luego ejecute nyx. El nuevo grupo debe ser reconocido al iniciar sesión, por lo que ejecutar nyx en la misma sesión de shell provoca un error de permisos en el archivo de la cookie, incluso si la configuración es correcta. nyx muestra el ancho de banda en tiempo real, el tiempo de actividad, el flujo de registros y la lista de conexiones. Durante las primeras semanas, el valor que debe vigilar es que el gráfico de ancho de banda se mantenga por debajo de su RelayBandwidthRate.

Ejecución de varios repetidores: MyFamily y claves de familia

Si solo tiene un repetidor, omita esta sección. Dos o más repetidores gestionados por el mismo operador deben declararse entre sí para que los clientes nunca construyan un circuito que entre y salga a través de sus máquinas, lo cual permitiría a un mismo operador ver ambos extremos.

El método tradicional consiste en usar MyFamily en el archivo torrc de cada repetidor, listando las huellas (fingerprints) de todos los demás:

MyFamily AAAAAAAAAA,BBBBBBBB

Cada repetidor debe listar a todos los demás, por lo que añadir un cuarto repetidor implica editar cuatro archivos. Tor 0.4.9 sustituyó esto por una clave de familia. Genere una clave y compártala:

tor --keygen-family myfamily

Esto escribe myfamily.secret_family_key e imprime una línea FamilyId. Copie el archivo de clave en cada repetidor, dentro del subdirectorio keys del DataDirectory (/var/lib/tor/keys en Debian y Ubuntu), manteniendo el sufijo .secret_family_key. Añada la línea FamilyId impresa a cada torrc y recargue con sudo systemctl reload tor@default. Mantenga también la lista MyFamily en su lugar por ahora. Los clientes que aún no reconocen los certificados de familia seguirán leyendo la lista antigua, y el Tor Project anunciará cuándo podrá eliminarse.

Qué falla después de estar en ejecución

La versión queda obsoleta. Las actualizaciones automáticas reemplazan el paquete, pero el proceso en ejecución mantiene el binario con el que inició hasta que algo lo reinicia. Compare tor --version en el equipo con la versión que se muestra en la página Relay Search del repetidor. Si son diferentes, la red sigue viendo la versión antigua, por lo que debe reiniciar el servicio.

El reloj se desincroniza. Los documentos de consenso y los certificados tienen límites de tiempo, por lo que una máquina cuyo reloj está muy desviado rechaza el consenso y deja de publicar. timedatectl debería informar que el reloj del sistema está sincronizado. Si no es así, habilite systemd-timesyncd o instale chrony.

La dirección IP cambia. El descriptor contiene la dirección y los clientes no pueden alcanzar una dirección que se ha movido. Después de cualquier migración de proveedor o cambio de dirección, reinicie tor y espere a ver de nuevo la línea de autodiagnóstico.

El repetidor es más lento de lo que permite el plan. La criptografía de los repetidores de Tor es eficiente en procesadores modernos, y el Tor Project estima que una CPU con soporte AES-NI alcanza aproximadamente entre 400 y 450 Mbit/s en cada dirección. Mucho antes de llegar a ese límite, usted estará restringido por la velocidad del puerto y la cuota de transferencia, razón por la cual la sección de contabilidad anterior es más importante que el hardware.

FAQ

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

Tanto como usted permita, y nada más. RelayBandwidthRate limita el tráfico retransmitido en cada dirección por separado, por lo que un repetidor configurado a 1 Mbit/s puede gestionar 1 Mbit/s de entrada y 1 Mbit/s de salida simultáneamente. Esto equivale a unos 21.6 GB al día, o 648 GB en un mes de 30 días, contando ambas direcciones. Añada AccountingMax con AccountingRule sum como una cuota mensual estricta por debajo de esa tasa.

¿Recibiré quejas por abuso si ejecuto un repetidor Tor?

Un repetidor de guardia o intermedio solo transmite tráfico a otros repetidores Tor y nunca se conecta a un sitio web en nombre del usuario, por lo que las quejas sobre lo que alguien hizo a través de Tor se dirigen al operador del nodo de salida, no a usted. Lo que puede observar es escaneo y listados ocasionales de reputación de IP, debido a que la dirección aparece públicamente como un repetidor. Los repetidores de salida son los que reciben correos de abuso y notificaciones legales, y requieren un proveedor que haya aceptado de antemano gestionarlos. Lea los términos de su proveedor antes de iniciar cualquiera de los dos tipos.

¿Por qué mi nuevo repetidor Tor no recibe tráfico?

Porque los repetidores nuevos están limitados por diseño hasta que son medidos. Durante los primeros tres días, las autoridades de directorio limitan el peso publicado a 20 KB, por lo que los clientes casi nunca eligen el repetidor. Las autoridades de ancho de banda lo miden a partir del tercer día aproximadamente, se vuelve elegible para el flag Guard alrededor del octavo día, y el tráfico disminuye de nuevo en ese punto porque los clientes evitan los nodos de guardia al elegir saltos intermedios. La carga completa llega alrededor del día 68. Confirme que el registro muestra "Self-testing indicates your ORPort is reachable from the outside" y luego no realice cambios.

¿Puedo ejecutar un repetidor Tor en un VPS con un límite de transferencia de 1 TB?

Sí, a aproximadamente 1 Mbit/s en cada dirección, lo cual es RelayBandwidthRate 125 KBytes. Esto suma aproximadamente 648 GB al mes si su proveedor mide ambas direcciones, dejando margen para actualizaciones y copias de seguridad. Añada AccountingMax 400 GBytes con AccountingRule sum y AccountingStart month 1 00:00 para que el repetidor hiberne en lugar de exceder el plan. Si el proveedor factura solo el tráfico de salida, puede duplicar la tasa.

¿Necesito configurar MyFamily si solo ejecuto un repetidor?

No. Las declaraciones de familia existen para que los clientes eviten construir un circuito a través de dos repetidores propiedad del mismo operador, lo cual carece de sentido con un solo repetidor. Configúrelo tan pronto como añada un segundo: liste la huella digital (fingerprint) de cada repetidor en la línea MyFamily de cada uno, o utilice la clave de familia que introdujo Tor 0.4.9, la cual distribuye un FamilyId en lugar de una lista que crece constantemente.