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. Forwarding TCP connections is system dependent but the firewalled-clients FAQ entry offers some examples on how to do this.

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 this is overloaded. This means that one or many of the following load metrics have been triggered:

Note that if a relay reaches an overloaded state we show it for 72 hours after the relay has recovered.

If you notice that your relay is overloaded please:

  1. Check https://status.torproject.org/ for any known issues in the "Tor network" category.

  2. Consider tuning sysctl for your system for network, memory and CPU load.

  3. Consider enabling MetricsPort to understand what is happening.

Tuning sysctl for network, memory and CPU load

TCP port exhaustion

If you are experiencing TCP port exhaustion consider expanding your local port range. You can do that with

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

o

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

DNS timeout

If you are experiencing DNS timeout, you should investigate if this is a network or a resolver issue.

In Linux in resolve.conf there is an option to set a timeout:

timeout:n
  Sets  the  amount of time the resolver will wait for a response from a remote
  name server before retrying the query via a different name server.
  This may not be the total time taken by any resolver API call and there is no guarantee
  that a single resolver API call maps to a single timeout.
  Measured in seconds, the default is RES_TIMEOUT (currently 5, see <resolv.h>).
  The value for this option is silently capped to 30.

Check $ man resolve.conf for more information.

MetricsPort

Consider enabling MetricsPort to understand what is happening.

MetricsPort data for relays has been introduced since version >= 0.4.7.1-alpha, while the overload data has been added to the relay descriptors since 0.4.6+.

It's important to understand that exposing the tor MetricsPort publicly is dangerous for the Tor network users.

Please take extra precaution and care when opening this port, and close it when you are done debugging. Set a very strict access policy with MetricsPortPolicy and consider using your operating systems firewall features for defense in depth.

Here is an example of what output enabling MetricsPort will produce:

‪# 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="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="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="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

Let's find out what some of these lines actually mean:

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

When a relay starts seeing "dropped", it is a CPU/RAM problem usually.

Tor is sadly single threaded except for when the "onion skins" are processed. The "onion skins" are the cryptographic work that needs to be done on the famous "onion layers" in every circuits.

When tor processes the layers we use a thread pool and outsource all of that work to that pool. It can happen that this pool starts dropping work due to memory or CPU pressure and this will trigger an overload state.

If your server is running at capacity this will likely be triggered.

‪tor_relay_exit_dns_error_total{...}

Any counter in the "*_dns_error_total" realm indicates a DNS problem.

DNS timeouts issues only apply to Exit nodes. If tor starts noticing DNS timeouts, you'll get the overload flag. This might not be because your relay is overloaded in terms of resources but it signals a problem on the network.

DNS timeouts at the Exits are a huge UX problem for tor users. Therefore Exit operators really need to address these issues to help the network.

‪tor_relay_load_oom_bytes_total{...}

An Out-Of-Memory invocation indicates a RAM problem. The relay might need more RAM or it is leaking memory. If you noticed that the tor process is leaking memory, please report the issue either via Tor gitLab or sending an email to the tor-relays mailing list.

Tor has its own OOM handler and it is invoked when 75%, of the total memory tor thinks is available, is reached. Thus, let say tor thinks it can use 2GB in total then at 1.5GB of memory usage, it will start freeing memory. That is considered an overload state.

To estimate the amount of memory it has available, when tor starts, it will use MaxMemInQueues or, if not set, will look at the total RAM available on the system and apply this algorithm:

    if RAM >= 8GB {
      memory = RAM * 40%
    } else {
      memory = RAM * 75%
    }
    /* Capped. */
    memory = min(memory, 8GB) -> [8GB on 64bit and 2GB on 32bit)
    /* Minimum value. */
    memory = max(250MB, memory)

To avoid an overloaded state we recommend to run a relay above 2GB of RAM on 64bit. 4GB is advised, although of course it doesn't hurt to add more RAM if you can.

One might notice that tor could be called by the OS OOM handler itself. Because tor takes the total memory on the system when it starts, if the overall system has many other applications running using RAM, it ends up eating too much memory. In this case the OS could OOM tor, without tor even noticing memory pressure.

tor_relay_load_socket_total

These lines indicate the relay is running out of sockets. The solution is to increase ulimit -n for the tor process.

tor_relay_load_tcp_exhaustion_total

These lines indicate the relay is running out of TCP ports.

Try to tune sysctl as described above.

tor_relay_load_global_rate_limit_reached_total

If this counter is incremented by some noticeable value over a short period of time, the relay is congested. It is likely being used as a Guard by a big onion service or for an ongoing DDoS on the network.

If your relay is still overloaded and you don't know why, please get in touch with network-report@torproject.org. You can encrypt your email using network-report OpenPGP key.

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.

The default open ports are listed below but keep in mind that, any port or ports can be opened by the relay operator by configuring it in torrc or modifying the source code. The default according to src/or/policies.c (line 85 and line 1901) from the source code release 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). Busca a tu repetidor en Métricas. 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.

Además hay opciones de hibernación donde le puedes decir a Tor que deje pasar una determinada cantidad de tráfico por unidad de tiempo (como por ejemplo 100 GB al mes). Están explicadas más abajo en la sección de hibernación.

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

You can run a relay in Windows following this tutorials:

You should only run a Windows relay if you can run it 24/7. If you are unable to guarantee that, Snowflake is a better way to contribute your resources to the Tor network.