Operadores de Retransmissores

O Tor adivinha seu endereço IP, solicitando ao computador o nome do host e resolvendo esse nome. Frequentemente, as pessoas têm entradas antigas no arquivo /etc/hosts que apontam para endereços IP antigos.

Se isso não corrigir, você deve usar a opção de configuração "Endereço" para especificar o IP que deseja escolher. Se o seu computador estiver protegido por um NAT e tiver apenas um endereço IP interno, consulte a seguinte entrada de Suporte em endereços IP dinâmicos.

Além disso, se você tiver muitos endereços, convém definir "OutboundBindAddress" para que as conexões externas venham do IP que você pretende apresentar ao mundo.

Se seu relé for relativamente novo, aguarde um momento. O Tor decide heuristicamente qual retransmissor ele usa baseado em relatórios de autoridades de Bandwidth. Essas autoridades realizam medições da capacidade do seu retransmissor e ao longo do tempo, direcionam mais tráfego para ele até que atinja a carga ótima. O ciclo de vida de um retransmissor novo é explicado em mais detalhes neste artigo de blog. Se você tem executado um retransmissor por algum tempo e ontinua tendo problemas, então tente perguntar na lista de retransmissor Tor.

Why Relay Load Varies

Tor manages bandwidth across the entire network. It does a reasonable job for most relays. But Tor's goals are different to protocols like BitTorrent. Tor wants low-latency web pages, which requires fast connections with headroom. BitTorrent wants bulk downloads, which requires using all the bandwidth.

We're working on a new bandwidth scanner, which is easier to understand and maintain. It will have diagnostics for relays that don't get measured, and relays that have low measurements.

Why does Tor need bandwidth scanners?

Most providers tell you the maximum speed of your local connection. But Tor has users all over the world, and our users connect to one or two Guard relays at random. So we need to know how well each relay can connect to the entire world.

So even if all relay operators set their advertised bandwidth to their local connection speed, we would still need bandwidth authorities to balance the load between different parts of the Internet.

What is a normal relay load?

It's normal for most relays to be loaded at 30%-80% of their capacity. This is good for clients: an overloaded relay has high latency. (We want enough relays to so that each relay is loaded at 10%. Then Tor would be almost as fast as the wider Internet).

Sometimes, a relay is slow because its processor is slow or its connections are limited. Other times, it is the network that is slow: the relay has bad peering to most other tor relays, or is a long distance away.

Finding Out what is Limiting a Relay

Lots of things can slow down a relay. Here's how to track them down.

System Limits

  • Check RAM, CPU, and socket/file descriptor usage on your relay

Tor logs some of these when it starts. Others can be viewed using top or similar tools.

Provider Limits

  • Check the Internet peering (bandwidth, latency) from your relay's provider to other relays. Relays transiting via Comcast have been slow at times. Relays outside North America and Western Europe are usually slower.

Tor Network Limits

Relay bandwidth can be limited by a relay's own observed bandwidth, or by the directory authorities' measured bandwidth. Here's how to find out which measurement is limiting your relay:

  • Check each of the votes for your relay on consensus-health (large page), and check the median. If your relay is not marked Running by some directory authorities:
    • Does it have the wrong IPv4 or IPv6 address?
    • Is its IPv4 or IPv6 address unreachable from some networks?
    • Are there more than 2 relays on its IPv4 address?

Otherwise, check your relay's observed bandwidth and bandwidth rate (limit). Look up your relay on Metrics. Then mouse over the bandwidth heading to see the observed bandwidth and relay bandwidth rate.

Here is some more detail and some examples: Drop in consensus weight and Rampup speed of Exit relay.

How to fix it

The smallest of these figures is limiting the bandwidth allocated to the relay.

  • If it's the bandwidth rate, increase the BandwidthRate/Burst or RelayBandwidthRate/Burst in your torrc.
  • If it's the observed bandwidth, your relay won't ask for more bandwidth until it sees itself getting faster. You need to work out why it is slow.
  • If it's the median measured bandwidth, your relay looks slow from a majority of bandwidth authorities. You need to work out why they measure it slow.

Doing Your Own Relay Measurements

If your relay thinks it is slow, or the bandwidth authorities think it is slow, you can test the bandwidth yourself:

  • Run a test using tor to see how fast tor can get on your network/CPU.
  • Run a test using tor and chutney to find out how fast tor can get on your CPU. Keep increasing the data volume until the bandwidth stops increasing.

Se você permitir conexões de saída, alguns serviços aos quais as pessoas se conectam a partir de sua retransmissão se conectarão novamente para coletar mais informações sobre você. Por exemplo, alguns servidores de IRC se conectam novamente à sua porta identd para registrar qual usuário fez a conexão. (Isso realmente não funciona para eles, porque o Tor não conhece essas informações, mas tenta de qualquer maneira.) Além disso, os usuários que saem de você podem atrair a atenção de outros usuários no servidor de IRC, site etc. que desejam saber mais sobre o host pelo qual eles estão retransmitindo.

Outra razão é que grupos que escaneiam por proxies abertos na Internet aprenderam que às vezes retransmissores Tor expoem suas "port socks" para o mundo. Nós recomendamos que você vincule sua socksport apenas com redes locais.

De qualquer maneira, você precisa manter sua segurança em dia. Veja este artigo sobre segurança para retransmissores Tor para mais sugestões.

  • O retransmissor de saída é o tipo de retransmissor mais necessário, porém ele também tem a maior exposição e risco legal (e você não deve executá-los da sua casa).
  • Se você está querendo executar um retransmissor com mínimo esforço, retransmissores rápidos de guarda são também muito úteis.
  • Seguido pelas pontes.

Quando uma saída está mal configurada ou é maliciosa ela é nomeada com a bandeira SaídaRuim (BadExit). Isto diz ao Tor para evitar a saída através daquele retransmissor. De fato, retransmissores com essa bandeira se tornam não disponíveis para saída. Se você recebeu essa sinalização, então descobrimos um problema ou atividade suspeita ao direcionar o tráfego pela sua saída e não conseguimos entrar em contato com você. Entre em contato com a equipe de relés ruins para que possamos resolver o problema.

Ao implementar melhorias no seu retransmissor Tor, ou movê-lo para um computador diferente, a parte importante é manter as mesmas chaves de identidade.(stored in "keys/ed25519_master_id_secret_key" and "keys/secret_id_key" in your DataDirectory). Mantenha backups das chaves de identidade para que você possa restaurar um retransmissor no futuro é a maneira recomendada para garantir que a reputação do retransmissor não seja desperdiçada.

Isso significa que se você estiver implementando melhorias no seu retransmissor Tor e você mantiver o mesmo torrc e o mesmo DataDirectory, então as melhorias devem funcionar e o seu retransmissor irá manter-se usando a mesma chave. Se você precisar escolher um novo DataDirectory, certifique-se de copiar suas chaves antigas: keys/ed25519_master_id_secret_key e keys/secret_id_key

Nota: A partir do Tor 0.2.7 nós estamos usando novas gerações de identidade para retransmissores baseados na curva criptografia elíptica ed25519. Eventualmente elas irão substituir as antigas identidades RSA, mas isso irá acontecer com o tempo, para garantir compatibilidade com versões antigas. Até lá, cada retransmissor irá ter ambas identidades, uma ed25519 (identity key file: keys/ed25519_master_id_secret_key) e uma RSA (identity key file: keys/secret_id_key). Você precisa copiar / fazer o backup de ambas para conseguir restaurar seu retransmissor, mudar seu DataDirectory ou migrar seu retransmissor para um computador novo.

Nós estamos procurando por pessoas com uma conexão de internet razoavelmente confiável, que tenha ao mínimo 10 Mbit/s (Mbps) disponíveis de bandwitdh em cada sentido. Se possuir, por favor considere executar um retransmissor Tor.

Mesmo que você não tenha ao mínimo 10Mbit/s disponíveis de bandwidth, você continua podendo ajudar a rede Tor ao executar uma ponte Tor com suporte obfs4. Nesse caso, você deve ter ao menos 1 Mbit/s disponível de bandwidth.

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.

Você está certo, para a maioria um byte dentro do seu retransmissor Tor significa um byte para fora e vice-versa. Mas existem algumas exceções:

Se você abrir seu DirPort, então os clientes Tor irão pedir para você uma cópia do diretório. A solicitação que eles fazem (uma GET HTTP) é bem pequena e a resposta às vezes bem grande. Isto provavelmente é responsável pela maior parte da diferença de contagem de bytes entre o que o seu relé escreve e lê.

Outra exceção secundária aparece quando você opera como um no de saída e você lê alguns bytes de uma conexão de saída (por exemplo, uma mensagem instantânea ou uma conexão ssh) e a embrulha em uma cápsula inteira de 512 bytes para transporte através da rede Tor.

Se o seu retransmissor Tor está usando mais memória do que você gostaria, aqui estão algumas dicas para reduzir sua demanda:

  • Se você estiver no Linux, vocês pode estar encontrando erros de fragmentação de memória na implementação glibc's malloc. Isto é, quando o Tor libera memória de volta para o sistema, as peças de memória são fragmentadas e devido a isso são difíceis de serem reusadas. O arquivo.tar do Tor vem com implementação malloc OpenBSD, a qual não possui muitos erros de fragmentação (mas a desvantagem é uma carga maior da CPU). Você pode dizer ao Tor para alternativamente usar esta implementação malloc: ./configure --enable-openbsd-malloc.
  • Se você estiver executando um retransmissor rápido, significando que você tem várias conexões TLS abertas, você provavelmente está perdendo muita memória para os buffers internos OpenSSL's (38KB+ para cada socket). Nós atualizamos o OpenSSL para liberar memória não usada pelo buffer de maneira mais consistente. Se você atualizar para o OpenSSL 1.0.0 ou versão mais recente, o processo embutido no Tor irá reconhecer automaticamente e usar este recurso.
  • Se você continuar a não conseguir lidar com a carga de memória, considere reduzir a quantidade de bandwidth que o seu retransmissor anuncia. Anunciar menos bandwidth siginifica que você irá atrair menos usuários, então o seu retransmissor não deve crescer como um grande. Veja a opção MaxAdvertisedBandwidth na página principal.

Dito tudo isso, retransmissores Tor rápidos usam muito de ram. Não é incomum para um retransmissor de saída rápido usar de 500-1000 MB de memória.

Nós esperamos tornar a configuração de um retransmissor Tor fácil e conveniente:

  • Tudo bem se o retransmissor ficar offline algumas vezes. Os diretórios notam isso rapidamente e param de anunciar o retransmissor. Apenas tente ter certeza de que não seja tão frequente, uma vez que as conexões usando o retransmissor serão quebradas quando ele desconectar.
  • Cada retransmissor Tor tem uma política de saída que especifica que tipo de conexões de saída são permitidas ou negadas por aquele retransmissor. Se você está desconfortável em permitir pessoas para sair a partir do seu retransmissor, você pode configurá-lo para apenas permitir conexões para outros retransmissores Tor.
  • Seu retransmissor irá estimar passivamente e anunciar sua capacidade recente de bandwidth, então retransmissores de alta bandwidth irão atrair mais usuários que os de baixa. Portanto, ter retransmissores de baixa bandwidth também é útil.

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:

  • Any Tor OOM invocation due to memory pressure
  • Any ntor onionskins are dropped
  • TCP port exhaustion
  • DNS timeout reached

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.

If you are experiencing TCP port exhaustion consider expanding your local port range

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

ou

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

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.

3. 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 tor metrics publicly is dangerous to the Tor network users. Please take extra precaution and care when opening this port. 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 via either GitLab or send 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


tor_relay_load_tcp_exhaustion_total

These lines indicate the relay is running out of sockets or TCP ports. If the issue is socket related the solution is to increase ulimit -n for the tor process

If the solution is related to TCP ports exhaustion 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 then it indicates 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.

If you're using Debian or Ubuntu especially, there are a number of benefits to installing Tor from the Tor Project's repository.

  • Seu ulimit -n é configurado para 32768 alto o suficiente para o Tor manter aberta todas as conexões necessárias.
  • Um perfil de usuário é criado apenas para o Tor, portanto Tor não precisa ser rodado como root.
  • Um script de inicialização é incluso, assim Tor roda no boot. Tor roda com '--verify-config', assim a maioria dos problemas com seu arquivo de configuração serão descobertos. Tor pode ligar-se a portas de baixo nível, então diminuir privilégios.

Todas as conexões de saída devem ser permitidas, assim cada retransmissor pode se comunicar com todos os outros retransmissores.

Em muitas jurisdições, operados de retransmissores Tor são legalmente protegidos pelos mesmos regulamentos comuns de Provedores de Rede, oque previne provedores de serviço de Internet de serem responsabilizados pelo conteúdo de terceiro que passa pela rede deles. Retransmissores de saída que filtram algum tráfego provavelmente perdem essas proteções.

Tor promove acesso livre a rede sem interferências. Retransmissores de saída não devem filtrar o tráfego que passam através deles para a Internet. Retransmissores de saída que forem descobertos filtrando tráfego irão receber a bandeira {SaídaRuim](https://community.torproject.org/relay/community-resources/bad-relays/) assim que forem detectados.

Não. Se a polícia se interessar pelo tráfego do seu relay de saída, é possível que policiais apreendam seu computador. Por essa razão, é melhor não rodar seu relay de saída em sua casa ou usando a conexão de internet da sua residência.

Em vez disso, considere executar seu relay de saída em uma instalação comercial que é solidária com Tor. Tenha um endereço de IP separado de seu relay de saída, e não roteie seu próprio tráfego por dele. Naturalmente, você deveria evitar manter qualquer informação sensível ou pessoal em computadores que hospedam seu relay de saída.

  • Não use os pacotes dos repositórios do Ubuntu. Eles não são atualizados de maneira confiável. Se você usar eles, você perderá importante estabilidade e atualizações na segurança.
  • Determine a sua versão Ubuntu utilizada executando o seguinte comando:
     ‪$ lsb_release -c
    
  • Como root, adicione as seguintes linhas ao /etc/apt/sources.list. Substitua 'versão' pela versão que você encontrou na etapa anterior:
     deb https://deb.torproject.org/torproject.org version main
     deb-src https://deb.torproject.org/torproject.org version main
    
  • Adicione a chave gpg usada para assinar os pacotes executando os seguintes comandos
     ‪$ curl https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | sudo apt-key add -
    
    Rode os seguintes comandos pra instalar o Tor e verificar suas assinaturas:
     ‪$ sudo apt-get update
     ‪$ sudo apt-get install tor deb.torproject.org-keyring
    

Para obter os recursos mais detalhados sobre a execução de um relé, consulte o Guia de configuração de relé.

Em palavras simples, funciona assim:

  • Há um arquivo principal de chave secreta da identidade ed25519 chamado "ed25519_master_Id_secret_key". Este é o mais importante, então tenha certeza de manter um backup em um lugar seguro - o arquivo é sensível e deve ser protegido. Tor pode criptografá-lo para você se você gerá-lo manualmente e digitar uma senha quando perguntado. Uma chave de assinatura de médio termo nomeada "ed25519_signing_secret_key" é gerada para o Tor usar. Além disso, é gerado um certificado chamado "ed25519_signing_cert" o qual é assinado pela chave-principal de identidade e confirma que a chave de assinatura de médio prazo é válida por um certo período de tempo. A validade padrão é 30 dias, mas isso pode ser personalzado configurando ""SigningKeyLifetime N days|weeks|months" no torrc.
  • There is also a primary public key named "ed25519_master_id_public_key", which is the actual identity of the relay advertised in the network. Essa não é sensível e pode ser facilmente obtida pela "ed5519_master_id_secret_key".

O Tor só precisará de acesso à chave de assinatura de médio prazo e o certificado desde que eles sejam válidos, então a chave primária de identidade pode ser mantida fora do DataDirectory/keys, em uma mídia de armazenamento ou em um computador diferente. Você terá que manualmente renovar a chave de assinatura de médio prazo e o certificado antes que eles expirem, de outra forma o processo do Tor no retransmissor irá sair após a expiração.

Este recurso é opicional, você não precisa usá-lo a não ser que queira. Se você quiser que seu retransmissor funcione sem nenhum acompanhamento por um período maior sem ter que fazer manualmente a renovação da chave de assinatura de médio prazo com regularidade, o melhor é deixar a chave de identidade primária secreta no DataDirectory/keys, e basta fazer um backup no caso de precisar reinstalar. Se você quiser usar esse recurso, você pode consultar nosso guia mais detalhado sobre o tópico.

Ótimo. Se você pode executar vários retransmissores para doar mais para a rede, nós ficamos feliz com isso. Porém, por favor, não rode mais do que algumas dúzias na mesma rede, visto que parte do objetivo da rede Tor é dispersão e diversidade.

Se você decidir em manter mais de um retransmissor, por favor configure a opção "MyFamily" no arquivo torrc de cada retransmissor, listando todos os retransmissores (separados por vírgula) que estão sob seu controle:

MyFamily $fingerprint1,$fingerprint2,$fingerprint3

onde cada fingerprint é a identidade de 40 caracteres (sem espaços).

Dessa maneira, clientes Tor irão saber evitar usar mais de um de seus retransmissores em um único circuito. Você deve configurar MyFamily se você tiver controle administrativo dos computadores ou da rede, mesmo se eles não estiverem todos na mesma localização geográfica.

As opções contábeis no arquivo torrc permitem que você especifique a quantidade máximas que seu retransmissor usa por um período de tempo.

    AccountingStart dia semana mês [dia] HH:MM

Isso especifíca quando a contabilidade deve ser zerada. Por exemplo, para definir a quantidade total de bytes disponíveis para uma semana (que é zerada toda Quarta-feira às 10 am), você deve usar:

    AccountingStart semana 3 10:00
    AccountingMax 500 GBytes

Isso especifica a quantidade máxima de dados que seu retransmissor irá enviar durante um período contabilizada, e o máximo de informação que seu retransmissores irá receber durante um tempo contado. Quando o período contabilizado zerar (através do AccountingStart), então a contagem de AccountingMax será também zerada.

Exemplo: Vamos dizer que você quer permitir 50 GB de tráfego todo dia em cada direção e a contabilidade deve ser zerada todo dia, ao meio-dia.

    AccountingStart dia 12:00
    AccountingMax 50 GBytes

Observe que seu retransmissores não irá ser ativado exatamente no começo de cada período contabilizado. Será mantido o registro de quão rápido ele usou a cota no último período e escolher um ponto aleatório no novo intervalo para se ativar. Dessa maneira nós evitamos ter centenas de retransmissores funcionando no começo de cada mês, porém nenhum ativo ainda no final do mês.

Se você tem apenas uma quantidade pequena de bandwidth para doar comparado com a sua velocidade de conexão, nós recomendamos que você use a contagem diária, assim você não acabará usando sua cota mensal inteira no primeiro dia. Apenas divida sua quantidade mensal por 30. Você pode também considerar limitar a taxa para aumentar sua utilidade ainda mais no dia; se você quer oferecer X GB em cada direção, você pode configurar sua RelayBandwidthRate para 20*X KBytes. Por exemplo, se você tem 50 GB para oferecer em cada direção, você pode configurar sua RelayBandwidthRate para 1000 KBytes: dessa maneira seu retransmissor será sempre útil pelo menos para metade de cada dia.

    AccountingStart dia 0:00
    AccountingMax 50 GBytes
    RelayBandwidthRate 1000 KBytes
    RelayBandwidthBurst 5000 KBytes # permite picos maiores, mas mantém a média.

Tor has partial support for IPv6 and we encourage every relay operator to enable IPv6 functionality in their torrc configuration files when IPv6 connectivity is available. Por enquanto, o Tor exigirá endereços IPv4 em relés, não é possível executar um relé Tor em um host apenas com endereços IPv6.

Os parâmetros atribuídos no AccountingMax e BandwidthRate aplicam-se para as funções dos processos Tor para ambos, cliente e retransmissor. Portanto você pode achar que não está apto a navegar assim que seu Tor entra em hibernação, sinalizado por esta entrada no log:

Limite de bandwidth alcançado; Iniciando hibernação.
Conexões novas não serão aceitas

A solução é rodar dois processos Tor - um retransmissor e outro cliente, cada um com sua própria configuração. Uma maneira de fazer isso (se você estiver começando a partir de uma configuração com um retransmissor em funcionamento) e a seguinte:

  • No arquivo torrc do retransmissor Tor, simplesmente edite o SocksPort para 0>
  • Crie um novo arquivo torrc de cliente usando o torrc.sample e garanta que use um arquivo diferente de registro do que o do retransmissor. Uma convenção para nomear pode ser torrc.client e torrc.relay. *Modifique o cliente Tor e scripts de iniciação do retransmissor para incluir -f /path/to/correct/torrc.
  • No Linux/BSD/Mac OS X, mudar os scripts de inicialização para Tor.client e Tor.relay pode tornar a separação de configuração mais fácil.

Ótimo. É exatamente por isto que nós implementamos as políticas de saída.

Cada retransmissor do Tor tem uma política de saída que especifica qual tipo de conexões de saída são permitidas ou negadas por aquele retransmissor. As políticas de saída são propagadas para os clientes Tor através do diretório, assim clientes irão automaticamente evitar escolher retransmissores de saída que recusariam-se "sair" para a destinação pretendida por eles. Desta maneira, cada retransmissor pode decidir os serviços, hospedagens e redes que querem permitir conexões para, baseado no potencial de abuso e sua própria situação. Read the Support entry on issues you might encounter if you use the default exit policy, and then read Mike Perry's tips for running an exit node with minimal harassment.

A política padrão de saída permite acesso para vários serviços populares (ex.: navegar na web), mas restringe alguns devido o potencial de abuso (ex.: email) e alguns desde que a rede Tor não consiga lidar com o carregamento. Você pode mudar a sua política de saída editando seu arquivo torrc. Se você quiser evitar a maior parte, senão todo o potencial de abuso, defina como "rejeitar : ". Esta configuração significa que seu retransmissor será usado para retransmissão de tráfego dentro da rede Tor, mas não para conexões para websites externos ou outros serviços.

Se você autoriza qualquer conexão de saída, tenha certeza que a resolução de nomes funciona (isto é, que seu computador pode resolver os endereços de Internet corretamente). Se existirem qualquer recursos que o seu computador não pode alcançar (por exemplo, você está atrás de um firewall restritivo ou filtro de conteúdo), por favor, explicitamente rejeite eles na suas política de saída caso contrário usuários do Tor também serão impactados.

Tor pode lidar facilmente com retransmissores de endereço de IP dinâmico. Just leave the "Address" line in your torrc blank, and Tor will guess.

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 *:*

BridgeDB implements four mechanisms to distribute bridges: HTTPS, Moat, Email, and Reserved. Bridge operators can check which mechanism their bridge is using, on the Relay Search. Enter the bridge's <HASHED FINGERPRINT> in the form and click "Search".

Operators can also choose which distribution method their bridge uses. To change the method, modify the BridgeDistribution setting in the torrc file to one of these: https, moat, email, none, any.

Read more on the Bridges post-install guide.

Sim, você obtém um anonimato melhor contra alguns tipos de ataques.

O exemplo mais simples é um atacante que possui uma quantidade pequena de retransmissores de Tor. Eles irão ver uma conexão vindo de você, mas eles não serão capazes de saber se a conexão foi originada em seu computador ou se foi retransmitida vinda de outra pessoa.

Existem alguns casos onde isto não parece ajudar: Se um atacante pode observar todo o seu tráfego vindo e indo, então é fácil para ele aprender quais conexões são retransmissões e quais você iniciou. (Neste caso, eles continuam não sabendo suas destinações a não ser que também estejam obeservando elas também, mas você não estará melhor do que se você você um usuário padrão.)

Existem também algumas desvantagens em executar um retransmissor Tor. Primeiro, enquanto nós temos apenas algumas centenas de retransmissores, o fato de você estar executando um pode talvez sinalizar para um atacante que você deposita um grande valor em seu anonimato. Segundo, existem alguns ataques mais raros que não são bem entendidos ou testados o suficiente que envolvem fazer uso do conhecimento que você está executando um retransmissor - por exemplo, um atacante pode ser capaz de "observar" se você está enviando tráfego mesmo se ele não pode efetivamente observar sua rede, ao retransmitir tráfego através do seu relé Tor e observar mudanças no tempo de tráfego.

É uma questão aberta à pesquisa se os benefícios superam os riscos. A maior parte disto depende dos ataques com o quais você é mais preocupado. Para a maioria dos usuários, nós achamos que isso é um movimento inteligente.

Veja portforward.com para instruções em como encaminhar para portas com seu aparelho NAT/router.

Se o seu retransmissor está rodando em uma rede interna, você precisa configurar o encaminhamento de porta. Forwarding TCP connections is system dependent but the firewalled-clients FAQ entry offers some examples on how to do this.

Também existe um exemplo de como você deveria fazer isto no GNU/Linux se você estiver usando Iptables:

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

Pode ser que você tenha que alterar "eth0" se você tem uma interface externa diferente (aquela conectada à Internet). Provavelmente você tem apenas uma (exceto o loopback) então isso não deve ser muito difícil de descobrir.

Existem duas opções que você pode adicionar no seu arquivo torrc:

BandwidthRate é a bandwidth máxima de longo prazo permitida (bytes por segundo). Por exemplo, você pode querer escolher "taxa de Bandwidth 10MBytes" para 10 megabytes por segundo (uma conexão rápida), ou "taxa de Bandwidth 500 KBytes" para 500 kilobytes por segundo (uma conexão à cabo decente). A configuração mínima de taxa de Bandwidth é 75 kilobytes por segundo.

BandwidthBurst é um conjunto de bytes usado para atender solicitações durante períodos curtos de tráfego acima da taxa de Bandwidth mas continua a manter a média ao longo do período com a taxa de Bandwidth. Uma baixa taxa mas uma alta explosão impõe uma média de longo prazo enquanto continua permitindo mais tráfego durante momentos de pico se a média não tem sido alcançada ultimamente. Por exemplo, se você escolher "BandwidthBurst 500 KBytes"  e também usar para sua taxa de Bandwidth, então você nunca ira usar mais do que 500 kilobytes por segundos; mas se você escolher uma BandwidthBurst mais alta (como 5 MBytes), isto irá permitir mai bytes através até o conjunto estar vazio.

Se você tem uma conexão assimétrica (upload menos do que download) como um modem a cabo, você deveria definir a BandwidthRate para menos do que a sua menor bandwidth (Geralmente é a bandwidth de upload). Caso contrário, você poderia perder vários pacotes durante os períodos de máximo uso da bandwidth - talvez você precise experimentar qual valor torna sua conexão mais confortável. Então defina a BandwidthBurst para o mesmo que a BandwidthRate.

Nós Tor baseados em Linux possuem outra opção a sua disposição: eles podem priorizar o tráfego do Tor abaixo de outro tráfego em sua máquina, então seu próprio tráfego pessoal não é impactado pela carga do Tor. Um script para fazer isso pode ser encontrado no diretório contrib da distribuição dos fontes do Tor.

Adicionalmente, existem opções hibernantes, onde você pode dizer ao Tor para apenas fornecer uma certa quantidade de bandwidth por período de tempo (como 100 GB por mês). Estas são cobertas no registro abaixo sobre hibernação:

Observe que BandwidthRate e BandwidthBurst estão em Bytes, não Bits.