Operadores de Repetidores

  • No utilices los paquetes de los repositorios de Ubuntu. Seguramente no están actualizados. Si los usas, perderás importantes parches de estabilidad y seguridad.
  • Concreta tu versión de Ubuntu para ejecutar el siguiente comando:
     ‪$ lsb_release -c
    
  • Como root, añade las líneas siguientes a /etc/apt/sources.list. Reemplaza 'version' con la versión que encontraste en el paso previo:
     deb https://deb.torproject.org/torproject.org version main
     deb-src https://deb.torproject.org/torproject.org version main
    
  • Añade la clave gpg utilizada para firmar los paquetes ejecutando los siguientes comandos:
     ‪$ curl https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | sudo apt-key add -
    
  • Ejecuta los siguientes comandos para instalar tor y comprobar sus firmas:
     ‪$ sudo apt-get update
     ‪$ sudo apt-get install tor deb.torproject.org-keyring
    

Simplificando, funcionan tal que así:

  • Hay un archivo para la clave secreta primaria de identidad ed25519, llamado "ed25519_master_id_secret_key". Esta es la más importante, así que asegúrate de que mantienes una copia de seguridad en lugar seguro - el archivo es delicado y debe estar protegido. Tor puede cifrarlo por ti si lo generas de forma manual y le asignas una contraseña cuando se te pida.
  • Una clave intermedia de firma digital llamada "ed25519_signing_secret_key" es generada para ser usada por Tor. También se genera un certificado, llamado "ed25519_signing_cert", firmado por la clave secreta de la identidad primaria, y confirma que la clave de firma de medio plazo es válida por un cierto periodo de tiempo. La validez por defecto es de 30 días, pero puedes cambiar este valor ajustando "SigningKeyLifetime N days|weeks|months" en el archivo torrc.
  • También hay una clave pública primaria llamada "ed25519_master_id_public_key", la cual es la identidad real del repetidor, publicada en la red. Esta no es secreta, ya que se puede calcular a partir de la "ed5519_master_id_secret_key".

Tor solamente necesitará acceso a la clave de firma y al certificado de medio plazo en la medida en que sean válidos, por lo que la clave secreta de la identidad primaria puede ser mantenida fuera de DataDirectory/keys, en un medio de almacenamiento o una computadora diferente. Deberás renovar de forma manual la clave intermedia de firma digital y el certificado antes de que caduquen, de lo contrario el proceso tor del repetidor se detendrá cuando pase el tiempo estipulado.

Esta característica es opcional, no necesitas usarla a menos que quieras hacerlo. Si quieres que tu repetidor corra sin atención por un tiempo más largo sin tener que hacer manualmente la renovación de la clave de firma de medio término en forma regular, lo mejor es dejar la clave secreta de la identidad primaria en DataDirectory/keys, solo haz una copia de seguridad en caso que vayas a necesitar reinstalarla. Si estás interesado en utilizar esta característica, puedes consultar nuestra guía en profundidad al respecto.

Tor permite parcialmente el uso de IPv6 y animamos a cada operador de repetidor a que active la funcionalidad IPv6 en su torrc si dispone de conectividad IPv6. Por el momento Tor requiere una dirección IPv4 en los repetidores, no puedes ejecutar un repetidor en un ordenador que solo disponga de direcciones IPv6.

Cierto, normalmente un byte en dirección al repetidor implica un byte haca la red y viceversa. Pero hay unas cuantas excepciones:

Si abres el DirPort, otros clientes Tor te pedirán una copia del directorio. La petición (HTTP GET) es bastante pequeña, pero la respuesta puede ser bastante grande. Esto seguramente explique la mayor parte del desequilibrio entre entrada y salida en el conteo de bytes.

Otra pequeña excepción aparece cuando administras un repetidor de salida y lees unos pocos bytes de una conexión de salida (por ejemplo, de mensajería instantánea o SSH) y lo empaquetas en una celda entera de 512 bytes para que sea transportada a través de la red Tor.

Aspiramos a que poner en marcha un repetidor Tor sea una tarea fácil:

  • No pasa nada si el repetidor se cae de vez en cuando. Los directorios se dan cuenta rápidamente y dejan de anunciarlo a la red. Simplemente asegúrate de que no sea demasiado a menudo, ya que las conexiones que estén usándolo fallarán. Cada repetidor Tor tiene una política de salida que establece qué tipo de conexiones salientes son permitidas o denegadas desde ese repetidor. Si no te sientes cómodo/a dejando que terceros salgan a internet desde tu repetidor, puedes configurarlo para que solo acepte conexiones hacia otros repetidores.
  • Tu repetidor calculará y anunciará su capacidad de ancho de banda reciente, para que los repetidores con mejor ancho de banda reciban más usuarios. Así que tener un repetidor con poco ancho de banda también es útil.

Los parámetros asignados a AccountingMax y BandwidthRate se aplican tanto a las funciones de repetidor como a las de cliente del proceso tor. Así que puedes encontrarte con que no puedes navegar tan pronto como tu programa Tor entra en modo hibernación, indicado por esta entrada en el registro:

Se alcanzó el límite suave de ancho de banda; iniciando hibernación.
No serán aceptadas nuevas conexiones

La solución está en ejecutar dos procesos Tor: uno como repetidor y otro como cliente, cada uno con su configuración. Un modo de hacer esto (si comienzas desde una configuración como repetidor) es como sigue:

  • En el archivo torrc del repetidor Tor, simplemente ajusta a 0 el parámetro SocksPort.
  • Crea un nuevo archivo torrc para el cliente, usando como plantilla el archivo torrc.sample y asegúrate de que utiliza un archivo de registro de eventos distinto al del repetidor. Una posible forma de llamarlos es torrc.client y torrc.relay.
  • Modifica los scripts de arranque del cliente y del repetidor para que incluyan -f /ruta/al/correspondiente/torrc.
  • En Linux/BSD/Mac OS X, cambiar el nombre de los script de arranque a Tor.client y Tor.relay puede hacer mas sencilla la separación de configuraciones.

Estamos buscando personas con conexiones a Internet razonablemente fiables, que dispongan de al menos 10Mbit/s (Mbps) de ancho de banda en cada dirección. Si es tu caso, por favor, plantéate administrar un repetidor Tor.

Incluso si no dispones de al menos 10 Mbit/s, puedes contribuir a la red Tor poniendo en marcha un repetidor puente con soporte obfs4. En ese caso, deberías tener disponible al menos 1 Mbit/s de ancho de banda.

Visita portforward.com para ver instrucciones sobre cómo redireccionar puertos en tu router.

Si tu repetidor está funcionando en una red interna, necesitas activar la redirección de puertos. La redirección de conexiones TCP depende del sistema, pero la entrada PMF de clientes tras cortafuegos ofrece algunos ejemplos sobre cómo hacer esto.

Además aquí hay un ejemplo de cómo hacerlo en GNU/Linux si usas iptables:

/sbin/iptables -A INPUT -i eth0 -p tcp --destination-port 9001 -j ACCEPT

Puede que tengas que sustituir "eth0" si tu interfaz externa (la que tiene acceso a internet) es otra. Lo más probable es que solo tengas una (además de loopback) así que no debería de ser muy complicado.

BridgeDB implementa cuatro mecanismos para distribuir puentes: HTTPS, Moat, Correo Electrónico y Reservado. Los operadores de puentes pueden verificar qué mecanismo usa un puente on la Búsqueda de Relays. Ingresa el <HASHED FINGERPRINT> del puente en el formulario y haz clic en "Buscar".

Los operadores pueden elegir el método de distribución para sus puentes. Para cambiar el método, modifica la directiva BridgeDistribution en el archivo torrc a una de estas: https, moat, email, none, any.

Lee más en la guía postinstalación de Puentes.

Si, consigues mejor protección frente a ciertos ataques.

El ejemplo más sencillo es un atacante que maneja un pequeño número de repetidores Tor. Verá una conexión desde tu ordenador, pero no podrá saber si la originaste tu o venía desde otro usuario de la red Tor.

Hay otros casos donde esto no es una ventaja: si un atacante puede ver todo tu tráfico de entrada y de salida, le será fácil distinguir qué conexiones has iniciado tú y cuales vienen desde otro usuario. (en este caso seguirá sin poder saber hacia donde va esa conexión a menos que también esté espiando el destino, pero en ese caso estás igual que alguien que no use Tor)

También hay desventajas en ejecutar un repetidor Tor. En primer lugar, mientras solo haya unos cientos de repetidores, el hecho de que tú estás ejecutando uno, puede hacer pensar a un atacante que valoras enormemente tu anonimato. En segundo lugar, existen ataques más exóticos que han sido menos estudiados que se aprovechan del hecho de saber que estás ejecutando un repetidor. Por ejemplo, un atacante puede ser capaz de "observar" si estás mandanto tráfico incluso aunque no pueda espiar tu red, mandando tráfico a través de tu repetidor y observando cambios en la cadencia del tráfico de red.

Es una materia de investigación no resuelta si los beneficios superan a los riesgos. Mucho de esto depende de los ataques que más te preocupen. Para la mayoría de los usuarios, creemos que esto es un beneficio.

Ya que desde ahora es guardián, los clientes lo están usando menos en otras posiciones, pero todavía no muchos clientes han rotado sus guardianes existentes para usarlo con este fin. Puedes consultar más detalles en este blog o en Cambio de guardián: Un esbozo para entender y mejorar la selección de guardianes de entrada en Tor.

Si permites conexiones de salida, algunos servicios a los que la gente se conecta desde tu repetidor abrirán conexiones para obtener más información sobre tí. Por ejemplo, algunos servidores IRC abren conexiones a tu puerto identd para registrar qué usuario realizó la conexión (en realidad esto no funciona, porque Tor no conoce esta información, pero igualmente lo intentan). Además, los usuarios que salgan a través de tu repetidor, pueden atraer la atención de otros usuarios del servidor IRC, sitio web, etc. que quieren saber más acerca del equipo que hace la conexión.

Otra razón es que los grupos que escanean en busca de proxies abiertos en internet se han dado cuenta que a veces los repetidores Tor exponen su puerto socks a todo internet. Recomendamos que expongas tu puerto socks solo a las redes locales.

En todo caso, debes estar al día con la seguridad. Consulta este artículo sobre la seguridad de los repetidores Tor para más recomendaciones.

On relay search we show an amber dot next to the relay nickname when it is overloaded. Esto significa que una o muchas de las siguientes métricas de carga han sido desencadenadas:

Ten en cuenta que si un repetidor alcanza un estado de sobrecarga lo mostramos por 72 horas luego de que el repetidor se haya resuperado.

Si notas que tu repetidor está sobrecargado, por favor:

  1. Comprueba https://status.torproject.org/ por cualquier dificultad conocida en la categoría "red Tor".

  2. Considera sintonizar sysctl para tu sistema para las cargas de red, memoria y CPU.

  3. Considera habilitar MetricsPort para entender qué está pasando.

Sintonizando sysctl para cargas de red, memoria y CPU

Agotamiento de puertos TCP

Si estás experimentando agotamiento de puertos TCP considera expandir tu rango de puertos locales. Puedes hacer eso con

# sysctl -w net.ipv4.ip_local_port_range="15000 64000"

o

# echo 15000 64000 > /proc/sys/net/ipv4/ip_local_port_range

Keep in mind that tuning sysctl as described is not permanent and will be lost upon restart. You need to add the configuration to /etc/sysctl.conf or to a file in /etc/sysctl.d/ to make it permanent.

MetricsPort

To understand the well-being of Tor relays and the Tor network it is vital to provide and have access to relay metrics. Relay overload information has been added to relay descriptors since 0.4.6+ but it was not until Tor >= 0.4.7.1-alpha that an interface to the underlying relay metrics was available: the metrics port.

Enabling MetricsPort

Tor provides access to the metrics port via a torrc configuration option called MetricsPort.

It's important to understand that exposing the tor MetricsPort publicly is dangerous for the Tor network users, which is why that port is not enabled by default and its access has to be governed by an access policy. Por favor, toma precaución y cuidado extras al abrir este puerto, y ciérralo cuando hayas finalizado la depuración de errores.

Let's assume you are the only user on a server that runs a Tor relay. You can enable the metrics port adding this to your torrc file:

MetricsPort 127.0.0.1:9035
MetricsPortPolicy accept 127.0.0.1

And then you will be able to easily retrieve the metrics with:

# curl http://127.0.0.1:9035/metrics

which are by default in a Prometheus format.

Note: every user on that server will be able to access those relay metrics in the example above. In general, set a very strict access policy with MetricsPortPolicy and consider using your operating systems firewall features for defense in depth.

For a more detailed explanation about MetricsPort and MetricsPortPolicy see tor's man page.

MetricsPort output

He aquí un ejemplo de qué salida producirá la habilitación de MetricsPort:

# HELP tor_relay_load_onionskins_total Total number of onionskins handled
# TYPE tor_relay_load_onionskins_total counter
tor_relay_load_onionskins_total{type="tap",action="processed"} 0
tor_relay_load_onionskins_total{type="tap",action="dropped"} 0
tor_relay_load_onionskins_total{type="fast",action="processed"} 0
tor_relay_load_onionskins_total{type="fast",action="dropped"} 0
tor_relay_load_onionskins_total{type="ntor",action="processed"} 0
tor_relay_load_onionskins_total{type="ntor",action="dropped"} 0
# HELP tor_relay_exit_dns_query_total Total number of DNS queries done by this relay
# TYPE tor_relay_exit_dns_query_total counter
tor_relay_exit_dns_query_total{record="A"} 0
tor_relay_exit_dns_query_total{record="PTR"} 0
tor_relay_exit_dns_query_total{record="AAAA"} 0
# HELP tor_relay_exit_dns_error_total Total number of DNS errors encountered by this relay
# TYPE tor_relay_exit_dns_error_total counter
tor_relay_exit_dns_error_total{record="A",reason="success"} 0
tor_relay_exit_dns_error_total{record="A",reason="format"} 0
tor_relay_exit_dns_error_total{record="A",reason="serverfailed"} 0
tor_relay_exit_dns_error_total{record="A",reason="notexist"} 0
tor_relay_exit_dns_error_total{record="A",reason="notimpl"} 0
tor_relay_exit_dns_error_total{record="A",reason="refused"} 0
tor_relay_exit_dns_error_total{record="A",reason="truncated"} 0
tor_relay_exit_dns_error_total{record="A",reason="unknown"} 0
tor_relay_exit_dns_error_total{record="A",reason="tor_timeout"} 0
tor_relay_exit_dns_error_total{record="A",reason="shutdown"} 0
tor_relay_exit_dns_error_total{record="A",reason="cancel"} 0
tor_relay_exit_dns_error_total{record="A",reason="nodata"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="success"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="format"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="serverfailed"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="notexist"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="notimpl"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="refused"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="truncated"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="unknown"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="tor_timeout"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="shutdown"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="cancel"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="nodata"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="success"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="format"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="serverfailed"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="notexist"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="notimpl"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="refused"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="truncated"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="unknown"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="tor_timeout"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="shutdown"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="cancel"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="nodata"} 0
# HELP tor_relay_load_tcp_exhaustion_total Total number of times we ran out of TCP ports
# TYPE tor_relay_load_tcp_exhaustion_total counter
tor_relay_load_tcp_exhaustion_total 0
# HELP tor_relay_load_socket_total Total number of sockets
# TYPE tor_relay_load_socket_total gauge
tor_relay_load_socket_total{state="opened"} 135
tor_relay_load_socket_total 1048544
# HELP tor_relay_load_oom_bytes_total Total number of bytes the OOM has freed by subsystem
# TYPE tor_relay_load_oom_bytes_total counter
tor_relay_load_oom_bytes_total{subsys="cell"} 0
tor_relay_load_oom_bytes_total{subsys="dns"} 0
tor_relay_load_oom_bytes_total{subsys="geoip"} 0
tor_relay_load_oom_bytes_total{subsys="hsdir"} 0
# HELP tor_relay_load_global_rate_limit_reached_total Total number of global connection bucket limit reached
# TYPE tor_relay_load_global_rate_limit_reached_total counter
tor_relay_load_global_rate_limit_reached_total{side="read"} 0
tor_relay_load_global_rate_limit_reached_total{side="write"} 0

Descubramos qué significan realmente algunas de estas líneas:

tor_relay_load_onionskins_total{type="ntor",action="dropped"} 0

Cuando un repetidor empieza a ser visto "caído", usualmente es un problema de CPU/RAM.

Tristemente, Tor se ejecuta en instancia única excepto cuando son procesadas las "pieles de cebolla". Las "pieles de cebolla" son el trabajo criptográfico que necesita ser hecho en las famosas "capas de cebolla" en cada circuito.

Cuando tor procesa las capas usamos una reserva de instancias, y le damos todo ese trabajo a esa reserva. Puede pasar que esta reserva empiece a descartar trabajos debido a presión en la memoria o la CPU, y esto desencadenará un estado de sobrecarga.

Si tu servidor se está ejecutando a capacidad, probablemente esto será desencadenado.

tor_relay_exit_dns_error_total{...}

Any counter in the "*_dns_error_total" realm indicates a potential DNS related problem. However, we realized during the 0.4.7 release cycle that DNS errors are way too noisy and contain too many false positives to be useful for overload reporting purposes. We therefore don't use them anymore for that purpose starting with 0.4.6.9 and 0.4.7.4-alpha. However, we still keep DNS metrics around to give the relay operator insight into what is going on with their relay.

DNS timeout issues and errors only apply to Exit nodes.

tor_relay_load_oom_bytes_total{...}

Una invocación de memoria agotada indica un problema con la RAM. El repetidor podría necesitar más RAM o está filtrando memoria. Si notaste que el proceso tor está filtrando memoria, por favor informa esta dificultad vía el gitLab de Tor o bien enviando un correo electrónico a la lista de correo tor-relays.

Tor tiene su propio manejador OOM, y es invocado cuando el 75% de la memoria total que tor piensa que está disponible es alcanzado. Por lo tanto, digamos que tor piensa que puede usar 2GB en total, luego, a 1.5GB de uso de memoria, empezará a liberarla. Ese es considerado un estado de sobrecarga.

Para estimar la cantidad de memoria que tiene disponible, cuando tor se inicia usará MaxMemInQueues, o, si no está establecido, mirará al total de RAM disponible en el sistema y aplicará este algoritmo:

    if RAM >= 8GB {
      memoria = RAM * 40%
    } else {
      memoria = RAM * 75%
    }
    /* Límite alcanzado. */
    memoria = min(memoria, 8GB) -> [8GB en 64bit y 2GB en 32bit)
    /* Valor mínimo. */
    memoria = max(250MB, memoria)

Para evitar un estado sobrecargado, recomendamos ejecutar un repatidor por sobre 2GB de RAM en 64bit. 4GB es aconsejado, sin embargo, por supuesto, no causa daño agregar más RAM si puedes.

Uno podría notar que tor podría ser llamado por el manejador OOM del SO propiamente dicho. Como tor toma la memoria total en el sistema cuando se inicia, si el sistema en general tiene muchas otras aplicaciones ejecutándose usando RAM, termina consumiendo demasiada memoria. En este caso el SO podría hacerle un OOM a tor, sin que este ni siquiera note la presión en la memoria.

tor_relay_load_socket_total

Estas líneas indican que el repetidor está quedándose sin sockets. La solución es incrementar ulimit -n para el proceso tor.

tor_relay_load_tcp_exhaustion_total

Estas líneas indican que el repetidor está quedándose sin puertos TCP.

Intenta sintonizar sysctl como se describió arriba.

tor_relay_load_global_rate_limit_reached_total

Si este contador es incrementado en algún valor notable sobre un periodo de tiempo corto, el repetidor está congestionado. Probablemente esté siendo usado como Guardián por un servicio cebolla grande o por un ataque DDoS ocurriendo sobre la red.

Si tu repetidor aún está sobrecargado y no sabes por qué, por favor contáctate con network-report@torproject.org. Puedes cifrar tu correo electrónico usando la clave OpenPGP de network-report.

Hay unas opciones en el archivo torrc que te permiten especificar el máximo número de bytes que serán transmitidos por tu repetidor en una unidad de tiempo determinada.

    AccountingStart day week month [day] HH:MM

Esto establece cuando el conteo será restablecido. Por ejemplo, para fijar el total de bytes por semana (que se ponga a cero cada miércoles a las 10:00AM), usarías:

    AccountingStart week 3 10:00
    AccountingMax 500 GBytes

Esto establece la máxima cantidad de datos que tu repetidor enviará durante un periodo de conteo y la máxima cantidad de datos que tu repetidor recibirá durante un periodo de conteo. Cuando el periodo de conteo comienza (mediante AccountingStart) los contadores para AccountingMax vuelven a 0.

Por ejemplo: Digamos que quieres permitir 50 GB de tráfico al día en cada dirección y el periodo de conteo debe restablecerse a diario a mediodía:

    AccountingStart day 12:00
    AccountingMax 50 GBytes

Ten en cuenta que tu repetidor no se despertará exactamente al principio del periodo de conteo. Llevará la cuenta de lo rápido que ha usado su cuota en el último periodo y escogerá un momento aleatorio en el próximo intervalo para despertar. De este modo evitamos que haya cientos de repetidores trabajando al principio de cada mes y no quede ninguno al final del mismo.

Si solo dispones de una cantidad pequeña de ancho de banda para donar en relación a tu velocidad de conexión, te recomendamos que uses un conteo diario, para no acabarte la cuota mensual el primer día. Simplemente divide la cantidad mensual por 30. Puedes tener en cuenta tambien limitar el cuadal para espaciar la utilidad a lo largo del día: si quieres ofrecer X GB en cada dirección, puedes ajustar RelayBandwidthRate a 20*X KBytes. Por ejemplo, si tienes 50 GB para ofrecer en cada dirección, puedes establecer RelayBandwidthRate a 1000KBytes. De este modo tu repetidor siempre será útil al menos la mitad de cada día.

    AccountingStart day 0:00
    AccountingMax 50 GBytes
    RelayBandwidthRate 1000 KBytes
    RelayBandwidthBurst 5000 KBytes # permitir picos mayores pero manteniendo un valor medio

Genial. Para eso tenemos las políticas de salida.

Cada repetidor Tor tiene una política de salida que especifica qué tipo de conexiones salientes serán permitidas o denegadas. Las políticas de salida son propagadas a los clientes Tor mediante los directorios, así los clientes evitan elegir repetidores que no permitirían llegar a su destino. De esta forma cada repetidor puede elegir qué servicios, destinos y redes quiere permitir, basándose en el potencial para el abuso o en otros criterios. Consulta la entrada sobre los problemas que puedes encontrar si utilizas la política de salida por defecto y después lee los consejos para ejecutar un repetidor de salida con las mínimas molestias de Mike Perry.

La política de salida por defecto permite el acceso a muchos servicios populares (navegación web), pero impide algunos otros debido al potencial para el abuso (correo) y otros para los que la red Tor no está diseñada para aguantar (P2P, bittorrent, etc). Puedes cambiar la política de salida editando el archivo torrc. Si quieres evitar la mayor parte, si no todo, el potencial para el abuso, ajústalo a "reject *:*". Este ajuste significa que tu repetidor será usado para retransmitir tráfico dentro de la red Tor, pero no para conexiones a sitios web externos u otros servicios.

Si permites conexiones de salida, asegúrate de que la resolución DNS funciona (es decir, que tu ordenador puede resolver correctamente las direcciones de Internet). Si hay recursos a los que que tu ordenador es incapaz de conectar (por ejemplo, estás detras de un cortafuegos restrictivo o de un filtro de contenidos) por favor, recházalos de forma explícita en tu política de salida, de lo contrario los usuarios de Tor se verán afectados también.

Si tu repetidor es relativamente nuevo, ten paciencia. Tor decide qué repetidores usar de forma inteligente, usando información de las autoridades de ancho de banda. Dichas autoridades realizan mediciones de la capacidad de tu repetidor y con el tiempo dirigen más tráfico allí para que la carga sea óptima. El ciclo de vida de un repetidor nuevo se explica con más detalle en esta entrada del blog. Si llevas un tiempo ejecutando un repetidor y aún tienes problemas, prueba preguntando en la lista de correo tor-relays.

Genial. Si quieres ejecutar varios repetidores para donar más a la red, nos parece bien. Pero por favor, no ejecutes más de unas docena en la misma red, ya que parte de los objetivos de la red Tor es tener diversidad geográfica.

Si decides ejecutar más de un repetidor, por favor, establece la opción de configuración "MyFamily" en el archivo torrc de cada repetidor, listando todos los repetidores (separándolos con coma) que estén bajo tu control:

MyFamily $fingerprint1,$fingerprint2,$fingerprint3

donde cada huella es el identificador de 40 caracteres (sin espacios).

De esta forma, los clientes Tor sabrán evitar el uso de más de uno de tus repetidores en un mismo circuito. Debes establecer MyFamily si tienes control administrativo de los ordenadores o de la red en la que se encuentran, incluso si no están situados geográficamente en el mismo sitio.

Los puertos abiertos por defecto están listados abajo, pero ten en mente que cualquier puerto o puertos pueden ser abiertos por el operador del repetidor configurándolos en torrc o modificando el código fuente. Los predeterminados de acuerdo a src/or/policies.c (línea 85 y línea 1901) del lanzamiento del código fuente release-0.4.6:

reject 0.0.0.0/8
reject 169.254.0.0/16
reject 127.0.0.0/8
reject 192.168.0.0/16
reject 10.0.0.0/8
reject 172.16.0.0/12

reject *:25
reject *:119
reject *:135-139
reject *:445
reject *:563
reject *:1214
reject *:4661-4666
reject *:6346-6429
reject *:6699
reject *:6881-6999
accept *:*

Tor determina su dirección IP preguntando al equipo por su nombre de host y resolviendo ese nombre. Muchas veces, la gente tiene entradas antiguas en su archivo /etc/hosts que apuntan a direcciones antiguas.

Si esto no lo arregla, deberías usar la opción de configuración "Address" para especificar la dirección IP que quieres que use. Si tu equipo está detrás de un router con traducción de direcciones (NAT) y solo dispone de una dirección IP privada, consulta la siguiente entrada sobre direcciones IP dinámicas.

También, si tienes muchas direcciones, puede que encuentres útil la opción "OutboundBindAddress" para que las conexiones salientes se realicen desde la dirección que desees.

Por qué varía la carga en repetidores

Tor gestiona el ancho de banda a lo largo de la red completa. Hace un trabajo razonable para la mayoría de los repetidores. Pero los objetivos de Tor son diferentes de los de protocolos como BitTorrent. Tor quiere páginas web de baja latencia, lo cual requiere conexiones rápidas con capacidad de sobra. BitTorrent quiere descargas masivas, lo cual requiere usar todo el ancho de banda.

Estamos trabajando en un nuevo escáner de ancho de banda, el cual es más fácil de entender y mantener. Tendrá diagnósticos para repetidores que no son medidos, y repetidores que tienen bajas mediciones.

¿Por qué necesita Tor escáners de ancho de banda?

La mayoría de los proveedores te dicen la máxima velocidad de tu conexión local. Pero Tor tiene usuarios a lo largo del mundo, quienes se conectan a uno o dos repetidores guardianes al azar. Por lo que necesitamos saber qué tan bien puede conectarse cada repetidor al mundo entero.

Por lo que aún si todos los operadores de repetidores establecieran su ancho de banda publicitado a su velocidad de conexión local, aún necesitaríamos autoridades de ancho de banda para balancear la carga entre diferentes partes de Internet.

¿Cuál es la carga normal de un repetidor?

Es normal para la mayoría de los repetidores estar cargados al 30%-80% de su capacidad. Esto es bueno para los clientes: un repetidor sobrecargado tiene alta latencia. (Queremos suficientes repetidores de manera que cada cual esté cargado al 10%. Entonces Tor sería casi tan rápido como Internet en su amplitud).

A veces, un repetidor es lento porque su procesador es lento, o sus conexiones son limitadas. Otras veces, es la red quien es lenta: el repetidor está mal apareado con la mayoría de los otros repetidores tor, o está ubicado a una gran distancia.

Encontrando qué cosa está limitando a un repetidor

Montones de cosas pueden hacer lento a un repetidor. He aquí como rastrearlas.

Límites del sistema

  • Comprueba la RAM, la CPU y el uso de sockets/descriptores de archivo en tu repetidor

Tor registra algunos de estos cuando arranca. Otros pueden ser visualizados usando top o herramientas similares.

Límites del proveedor

  • Comprueba la calidad de comunicación de Internet (ancho de banda, latencia) desde el proveedor de tu repetidor a otros repetidores. Los repetidores transitando vía Comcast han sido lentos a veces. Los repetidores fuera de América del Norte y Europa Occidental usualmente son más lentos.

Límites de la red Tor

El ancho de banda de un repetidor puede estar limitado por el propio ancho de banda observado por él, o por el ancho de banda medido por las autoridades de directorio. He aquí cómo descubrir qué medida está limitando a tu repetidor:

  • Comprueba cada uno de los votos para tu repetidor en consensus-health (una página grande), y mira la mediana. Si tu repetidor no está marcado Running por algunas autoridades de directorio:
    • ¿Tiene las direcciones IPv4 o IPv6 equivocadas?
    • ¿Su dirección IPv4 o IPv6 es inalcanzable desde algunas redes?
    • ¿Hay más de 2 repetidores en su dirección IPv4?

De otra manera, comprueba el ancho de banda observado de tu repetidor, y la tasa de ancho de banda (límite). Look up your relay on Metrics. Luego pasa con el mouse por arriba del encabezado de ancho de banda para ver el ancho de banda observado y la tasa de ancho de banda del repetidor.

He aquí algún detalle más y algunos ejemplos: Caída en el peso del consenso y Velocidad de escalamiento de repetidores de salida.

Cómo arreglarlo

La más pequeña de estas cantidades está limitando el ancho de banda asignado al repetidor.

  • Si es la tasa de ancho de banda, incrementa las directivas BandwidthRate/Burst o RelayBandwidthRate/Burst en tu torrc.
  • Si es el ancho de banda observado, tu repetidor no solicitará más ancho de banda hasta que se vea operando más rápido. Necesitas darte cuenta de por qué es lento.
  • Si es la mediana del ancho de banda medido, tu repetidor aparece lento para una mayoría de autoridades de ancho de banda. Necesitas darte cuenta de por qué lo midieron como lento.

Efectuando mediciones en tu propio repetidor

Si tu repetidor piensa que es lento, o así lo creen las autoridades de ancho de banda, puedes probar por tí mismo el ancho de banda:

  • Efectúa una prueba usando tor para ver que tan rápido puede llegar a ser en tu red/CPU.
  • Efectúa una prueba usando tor y chutney para descubrir que tan rápido tor puede llegar a ser en tu CPU. Sigue aumentando el volumen de datos hasta que el ancho de banda no se incremente.

  • El de salida es el más necesario pero tiene un elevado riesgo de conllevar problemas legales (y NO deberías hacerlo funcionar desde tu casa).
  • Si estás buscando correr un repetidor con mínimo esfuerzo, los repetidores guardianes rápidos también son muy útiles
  • Seguidos de los repetidores puente.

Hay dos opciones que puedes añadir a tu archivo torrc:

BandwidthRate es el máximo ancho de banda a largo plazo permitido (en bytes por segundo). Por ejemplo, puedes añadir "BandwidthRate 10 MBytes" para 10 megabytes por segundo (conexión rápida), o "BandwidthRate 500 KBytes" para 500 kilobytes por segundo (una conexión cablemodem decente). El ajuste mínimo para BandwidthRate es de 75 kilobytes por segundo.

BandwidthBurst es una reserva de bytes usada para satisfacer una demanda por encima de BandwidthRate durante un corto periodo de tiempo pero respetando el valor medio fijado en BandwidthRate. Un valor bajo en Rate pero alto en Burst, asegura a largo plazo un valor medio a la vez que permite picos superiores de tráfico si dicho valor medio no se ha superado recientemente. Por ejemplo, si estableces "BandwidthBurst 500 KBytes" y usas el mismo valor para BandwidthRate, nunca se superará el caudal de 500 kilobytes por segundo, pero si eliges un valor más alto para BandwidthBurst (por ejemplo 5 MBytes), dejará pasar más trafico hasta que la reserva se vacíe.

Si tu conexión es asimétrica (la capacidad de subida es inferior que la de bajada) como pasa con los cablemodem, debes ajustar BandwidthRate a un valor inferior a tu ancho de banda más bajo (normalmente el de subida). De otro modo, podrías sufrir pérdida de paquetes durante los periodos de máximo uso de ancho de banda. Puede que tengas que jugar con estos valores hasta que consigas un uso adecuado de tu conexión. Ajusta BandwidthBurst y BandwidthRate al mismo valor.

Los repetidores Tor basados en Linux, tienen otra opción a su disposición: pueden priorizar el tráfico Tor para que otros tipos de tráfico no se vean afectados por la carga de Tor. Un script para hacer esto puede ser encontrado en el directorio de contribuciones de la distribución del código fuente de Tor.

Additionally, there are hibernation options where you can tell Tor to only serve a certain amount of bandwidth per time period (such as 100 GB per month). These are covered in the hibernation entry.

Ten en cuenta que BandwidthRate y BandwidthBurst aceptan valores en Bytes, no en Bits.

No. Si las fuerzas de seguridad se interesan en el tráfico de tu repetidor de salida, es posible que los agentes confisquen tu ordenador. Por esa razón, es mejor no hacer funcionar el repetidor de salida en tu casa o usando la conexión a Internet de tu casa.

En su lugar, considera ejecutar tu repetidor de salida en una instalación comercial que apoye a Tor. Ten una dirección IP separada para tu repetidor de salida y no enrutes tu propio tráfico a través de esta. Por supuesto, debes evitar mantener cualquier información sensible o personal en el ordenador que hospeda tu repetidor de salida.

Todas las conexiones salientes se deben permitir para que cada repetidor pueda comunicarse con los demás.

En muchas jurisdicciones, los operadores de repetidores Tor están cubiertos legalmente por la misma regulación que previene que los proveedores de servicios de internet puedan ser responsables del contenido que terceros hacen circular por su red. Los repetidores de salida que aplican algún filtro al tráfico, es posible que pierdan esas protecciones.

Tor fomenta el acceso libre a la red sin intromisiones. Los repetidores de salida no deben filtrar el tráfico que pasa a través de ellos hacia internet. Los repetidores de salida que apliquen filtros al tráfico serán catalogados con el distintivo BadExit cuando sean detectados.

Cuando un repetidor de salida está mal configurado o actúa de mala fé, se le asigna la indicación BadExit. Esto le sirve a Tor para evitar salir a través de ese repetidor. De hecho, los repetidores con esta indicación se convierten en repetidores de no salida. Si se te asigna este indicador quiere decir que hemos descubierto un problema o actividad sospechosa con el tráfico que pasa a traves de tu repetidor y no hemos podido contactar contigo. Por favor, ponte en contacto con el equipo bad-relays para que podamos solucionarlo.

Tor puede adaptarse bien a esta situación. Simplemente deja en blanco la opción "Address" en el archivo torrc y Tor se encargará de averiguarla.

Cuando actualizas tu repetidor Tor o lo mueves a otro equipo, lo importante es que tenga las mismas claves privadas (almacenadas en los archivos "keys/ed25519_master_id_secret_key" y "keys/secret_id_key" en tu directorio DataDirectory). Guardar copias de seguridad de las claves privadas para que puedan ser restauradas posteriormente en un repetidor es la manera recomendada de asegurarte que la reputación del repetidor no se desperdicie.

Esto significa que si actualizas el repetidor Tor y mantienes el mismo archivo torrc y el mismo directorio DataDirectory, todo debería de funcionar y tu repetidor usará las mismas claves. Si necesitas cambiar la ubicación de tu DataDirectory, asegúrate de copiar las antiguas keys/ed25519_master_id_secret_key y keys/secret_id_key.

Nota: Desde la versión 0.2.7, Tor utiliza una nueva generación de identidades basadas en criptografía de curva elíptica ed25519. Con el tiempo estas reemplazarán a las antiguas identidades RSA, pero llevará su tiempo, para asegurar la compatibilidad con versiones más antiguas. Mientras tanto, cada repetidor tendrá ambas: una ed25519 (en el archivo keys/ed25519_master_id_secret_key) y una RSA (en el archivo keys/secret_id_key) Necesitas tener una copia de seguridad de ambas para poder restaurar tu repetidor, cambiar tu DataDirectory o mover el repetidor a un nuevo equipo.

Si tu repetidor Tor usa más memoria de la que quisieras, estos son unos trucos para reducir su uso:

  • Si estás usando Linux, puede haber errores de fragmentación de la memoria en la implementación de la funcion malloc de la biblioteca glibc. Esto es, cuando Tor libera memoria al sistema operativo, lo hace en tramos no contiguos dificultando su uso. El archivo con el código fuente de Tor, viene con la implementación de la función malloc del sistema operativo OpenBSD, que sufre este problema de manera más leve (la contrapartida es un mayor uso de CPU). Puedes compilar Tor con esta implementación si lo prefieres: ./configure --enable-openbsd-malloc.
  • Si tienes un repetidor rápido, esto es, tienes muchas conexiones TLS abiertas, posiblemente estés perdiendo mucha memoria a causa de los buffers internos de OpenSSL (más de 38KB por conexión). Hemos parcheado OpenSSL para que libere de forma más agresiva la memoria que no necesita. Si actualizas OpenSSL a la versión 1.0.0 o superior, el proceso de compilación de Tor lo reconocerá automáticamente y usará esta característica.
  • Si el uso de memoria sigue siendo demasiado alto, puedes probar a reducir el ancho de banda que tu repetidor anuncia. Anunciar un ancho de banda más bajo supone que menos usuarios lo usarán, esto debería ayudar. Consulta la opción MaxAdvertisedBandwidth en el manual.

Con todo, los repetidores rápidos usan un montón de RAM. No es raro para un repetidor de salida el usar 500-1000 MB de memoria.

Si estás usando Debian o Ubuntu, hay una serie de ventajas al instalar Tor desde el repositorio de Tor Project.

  • Tu ulimit -n queda establecido a 32768, valor lo suficientemente alto para que Tor pueda abrir todas las conexiones que necesita.
  • Se crea una cuenta de usuario específica para Tor, para que no haya que ejecutarlo como root.
  • Se incluye un script para que Tor se ejecute al arracar.
  • Se ejecuta tor con la opción --verify-config para comprobar que no haya problemas con el archivo de configuración.
  • Tor puede ponerse a la escucha en puertos privilegiados y después desprenderse de los privilegios

Puedes correr un repetidor en Windows siguiendo estos tutoriales:

Deberías correr un repetidor Windows solamente si puedes hacerlo 24/7. Si no eres capaz de garantizar eso, Snowflake es una mejor manera de contribuir tus recursos a la red Tor.