Relay Operators

Tor indovina il suo indirizzo IP chiedendo al computer il nome host e risolvendo tale nome host. Spesso le persone hanno voci vecchie che puntano a vecchi indirizzi IP nel loro file /etch/hosts.

Se ciò non risolve, dovresti utilizzare l'opzione di configurazione "Indirizzo" per specificare l'IP che desideri selezionare. Se il tuo computer è dietro un NAT e ha solo un indirizzo IP interno, vedi la seguente voce Supporto su indirizzi IP dinamici.

Inoltre, se hai molti indirizzi, potresti anche voler impostare "OutboundBindAddress" in modo che le connessioni esterne provengano dall'IP che intendi presentare al mondo.

Se il tuo relè è relativamente nuovo, dagli tempo. Tor decide quali relè utilizzare euristicamente in base ai rapporti delle Autorità di Banda. Queste autorità effettuano misurazioni della capacità del relè e, nel tempo, vi indirizzano più traffico fino a raggiungere un carico ottimale. Il ciclo di vita di un nuovo relè è spiegato in modo più approfondito in questo blog post. Se stai utilizzato un relè da un po' e hai ancora problemi, prova a chiedere nell'elenco relè.

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 consenti connessioni di uscita, alcuni servizi a cui le persone si connettono dal tuo relay si riconnetteranno per raccogliere ulteriori informazioni su di te. Ad esempio, alcuni server IRC si ricollegano alla tua porta identd per registrare quale utente ha effettuato la connessione. (Questo non funziona davvero per loro, perché Tor non conosce queste informazioni, ma ci provano comunque.) Inoltre, gli utenti che escono da te potrebbero attirare l'attenzione di altri utenti sul server IRC, sul sito Web, ecc. che vogliono sapere di più sull'host attraverso cui stanno trasmettendo.

Un altro motivo è che i gruppi che cercano proxy aperti su Internet hanno appreso che a volte i relè Tor espongono la loro porta socks al mondo. Ti consigliamo di associare la tua porta socks solo alle reti locali.

In ogni caso, è necessario tenersi aggiornati con la sicurezza. Vedi questo articolo sulla sicurezza per i relè Tor per ulteriori suggerimenti.

  • Il relè di uscita è il tipo di relè più necessario ma presenta anche il rischio e l'esposizione legale più elevati (e NON dovresti eseguirli da casa).
  • Se si desidera offrire un relè con il minimo sforzo, anche i guard relè veloci sono molto utili
  • seguito dal ponte

Quando un'uscita è configurata in modo errato o dannoso, viene assegnato il flag BadExit. Questo dice a Tor di evitare di uscire attraverso quel relè. In effetti, i relè con questo flag diventano non-uscite. Se hai ricevuto questo flag, abbiamo scoperto un problema o un'attività sospetta durante il routing del traffico attraverso la tua uscita e non siamo riusciti a contattarti. Ti preghiamo di contattare il team di relé difettosi così che possiamo risolvere il problema.

Quando aggiorni il tuo relè Tor o lo sposti su un altro computer, la parte importante è mantenere le stesse chiavi di identità (memorizzate in "keys/ed25519_master_id_secret_key" e "keys/secret_id_key" nella tua DataDirectory). Conservare delle copie delle chiavi di identità in modo da poter ripristinare un relè in futuro è il modo raccomandato per garantire che la reputazione del relè non venga sprecata.

Ciò significa che se stai aggiornando il tuo relè Tor e mantieni lo stesso torrc e la stessa DataDirectory, l'aggiornamento dovrebbe funzionare e il tuo relè continuerà a usare la stessa chiave. Se devi scegliere una nuova DataDirectory, assicurati di copiare le tue vecchie keys/ed25519_master_id_secret_key e le keys/secret_id_key.

Nota: a partire da Tor 0.2.7 stiamo usando identità di nuova generazione per relè basati sulla crittografia a curva ellittica ed25519. Alla fine sostituiranno le vecchie identità RSA, ma ciò avverrà nel tempo, per garantire la compatibilità con le versioni precedenti. Fino ad allora, ogni relè avrà sia un'identità ed25519 (file chiave di identità: keys/ed25519_master_id_secret_key) sia un'identità RSA (file chiave di identità: keys/secret_id_key). È necessario copiare entrambi per poter ripristinare il tuo relè, modificare la DataDirectory o migrare il relè su un nuovo computer.

Siamo alla ricerca di persone con connessioni Internet ragionevolmente affidabili, con banda disponibile di almeno 10 Mbit/s (Mbps) in ogni direzione. Se questa descrizione ti rappresenta, ti preghiamo di prendere in considerazione l'esecuzione di un relè Tor.

Anche se non disponi di almeno 10 Mbit/s di banda, puoi comunque aiutare la rete Tor eseguendo un bridge Tor con supporto obfs4. In quel caso dovresti disporre di almeno 1 MBit/s di banda.

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.

Hai ragione, per la maggior parte un byte nel tuo relè Tor significa un byte in uscita e viceversa. Ma ci sono alcune eccezioni:

Se apri la tua DirPort, i client Tor ti chiederanno una copia della directory. La richiesta che fanno (un HTTP GET) è piuttosto piccola e la risposta a volte è piuttosto grande. Questo probabilmente spiega la maggior parte della differenza tra il conteggio dei byte "write" e il conteggio dei byte "read".

Un'altra eccezione minore si presenta quando si opera come nodo di uscita e si leggono alcuni byte da una connessione di uscita (ad esempio una connessione di messaggistica istantanea o ssh) e la si avvolge in un'intera cella da 512 byte per il trasporto attraverso la rete Tor.

Se il tuo relè Tor sta utilizzando più memoria di quella che desideri, ecco alcuni suggerimenti per ridurne l'impatto:

  • Se sei su Linux, potresti riscontrare bug di frammentazione della memoria nell'implementazione malloc di glibc. Cioè, quando Tor rilascia memoria nel sistema, i pezzi di memoria sono frammentati e quindi più difficili da riutilizzare. Il tarball Tor viene fornito con l'implementazione malloc di OpenBSD, che non ha altrettanti bug di frammentazione (ma il compromesso è un carico maggiore della CPU). Puoi dire a Tor di utilizzare questa implementazione di malloc al suo posto: ./configure --enable-openbsd-malloc.
  • Se stai eseguendo un relè veloce, il che significa che hai molte connessioni TLS aperte, probabilmente stai perdendo molta memoria nei buffer interni di OpenSSL (38 KB+ per socket). Abbiamo corretto OpenSSL per rilasciare la memoria buffer inutilizzata in modo più aggressivo. Se esegui l'aggiornamento a OpenSSL 1.0.0 o successivo, il processo di creazione di Tor riconoscerà e utilizzerà automaticamente questa funzione.
  • Se non riesci comunque a gestire il carico di memoria, considera di ridurre la quantità di larghezza di banda pubblicizzata dal tuo relè. Pubblicizzare meno larghezza di banda significa che attirerai meno utenti, quindi il tuo relè non dovrebbe crescere così tanto. Vedi l'opzione MaxAdvertisedBandwidth nella pagina principale.

Detto questo, i relè Tor veloci usano molta RAM. Non è insolito che un relè di uscita veloce utilizzi 500-1000 MB di memoria.

Il nostro obiettivo è rendere la configurazione di un relè Tor semplice e conveniente:

  • Non è un problema se a volte il relè si disconnette. Le directory lo notano rapidamente e smettono di pubblicizzare il relè. Cerca solo di fare in modo che non accada troppo spesso, poiché le connessioni che utilizzano il relè si interromperanno quando si disconnette.
  • Ogni relè Tor ha una politica di uscita che specifica quale tipo di connessioni in uscita sono consentite o rifiutate da quel relè. Se non ti senti a tuo agio nel consentire alle persone di uscire dal tuo relè, puoi impostarlo in modo da consentire solo le connessioni ad altri relè Tor.
  • Il tuo relè stimerà e pubblicizzerà passivamente la sua recente capacità di banda, quindi i relè ad alta larghezza di banda attireranno più utenti di quelli a bassa larghezza di banda. Pertanto, anche avere relè a larghezza di banda ridotta è utile.

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"

o

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.

  • Il tuo ulimit -n viene impostato a 32768, abbastanza alto da consentire a Tor di tenere aperte tutte le connessioni di cui ha bisogno.
  • Un profilo utente viene creato solo per Tor, quindi Tor non deve essere eseguito come root.
  • Uno script init è incluso in modo che Tor sia lanciato all'avvio del computer. Tor funziona con --verify-config, in modo che la maggior parte dei problemi con il tuo file di configurazione venga scoperta.
  • Tor può legarsi a porte di basso livello, e poi perdere i privilegi.

Tutte le connessioni in uscita devono essere consentite, così che ciascun relè possa comunicare con ogni altro relè.

In molte giurisdizioni, gli operatori di relè Tor sono legalmente protetti dalle stesse normative comuni che impediscono ai fornitori di servizi Internet di essere ritenuti responsabili per i contenuti di terzi che passano attraverso la loro rete. I relè di uscita che filtrano parte del traffico perderebbero probabilmente quelle protezioni.

Tor promuove libero accesso alla rete senza interferenze. I relè di uscita non devono filtrare il traffico Internet che passa attraverso di loro. I relè di uscita che filtrano il traffico riceveranno il flag BadExit una volta scoperti.

No. Se le forze dell'ordine si interessano al traffico passato dal tuo exit relay, è possibile che gli agenti sequestrino il tuo computer. Per questo motivo, è meglio non implementare un exit relay a casa tua né utilizzare la tua connessione internet domestica.

Considera invece di implementare il tuo exit relay in una struttura che sia favorevole a Tor. Utilizza un indirizzo IP dedicato per il tuo exit relay, e non fare passare da lì il tuo traffico. Naturalmente, dovresti evitare di tenere dati sensibili o personali sul computer che utilizzi come host per il tuo exit relay.

  • Non utilizzare i pacchetti presenti nei repository di Ubuntu. Non sono sufficientemente aggiornati. Se li utilizzerai, potresti perdere importanti correzioni per la stabilità e la sicurezza.
  • Verifica la tua versione di Ubuntu utilizzando il seguente comando:
     ‪$ lsb_release -c
    
  • Come root, aggiungi le seguenti righe a /etc/apt/sources.list. Sostituisci 'version' con la versione trovata nel passo precedente:
     deb https://deb.torproject.org/torproject.org version main
     deb-src https://deb.torproject.org/torproject.org version main
    
  • Aggiungi la chiave gpg utilizzata per firmare il pacchetto eseguendo i seguenti comandi:
     ‪$ curl https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | sudo apt-key add -
    
  • Esegui i comandi seguenti per installare Tor e verificare le sue firme:
     ‪$ sudo apt-get update
     ‪$ sudo apt-get install tor deb.torproject.org-keyring
    

In parole semplici, funziona così:

  • There is a primary ed25519 identity secret key file named "ed25519_master_id_secret_key". Questo è il file più importante, quindi assicurati di conservarne una copia in un luogo sicuro: il file è sensibile e deve essere protetto. Tor può cifrarlo per te se lo generi manualmente e inserisci una password quando richiesto.
  • Una chiave per firmare a medio termine denominata "ed25519_signing_secret_key" viene generata per essere utilizzata da Tor. Also, a certificate is generated named "ed25519_signing_cert" which is signed by the primary identity secret key and confirms that the medium term signing key is valid for a certain period of time. La validità predefinita è di 30 giorni, ma può essere personalizzata impostando "SigningKeyLifetime N giorni|settimane|mesi" nel 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. Questa non è sensibile e può essere facilmente calcolata da "ed5519_master_id_secret_key".

Tor will only need access to the medium term signing key and certificate as long as they are valid, so the primary identity secret key can be kept outside DataDirectory/keys, on a storage media or a different computer. Dovrai rinnovare manualmente la chiave per firmare e il certificato a medio termine prima che scadano, altrimenti il processo Tor sul relè terminerà alla scadenza.

Questa funzione è facoltativa, non hai bisogno di utilizzarla se non vuoi. Se vuoi che il tuo relè funzioni senza attenzioni per un lungo periodo senza dover eseguire manualmente su base regolare il rinnovo della chiave per firmare a medio termine, il meglio è lasciare la chiave di identità segreta principale in DataDirectory/keys, fai solo un backup nel caso in cui sia necessario reinstallarlo. Se vuoi utilizzare questa funzione, puoi consultare la nostra guida più dettagliata sull'argomento.

Dal momento che ora è un guard, i client lo usano meno in altre posizioni, ma non molti client hanno ruotato i loro guard attuali per usarlo come nuovo guard. Leggi maggiori dettagli in questo blog post o in Changing of the Guards: A Framework for Understanding and Improving Entry Guard Selection in Tor.

Ottimo, se vuoi eseguire relè diversi per donare di più alla rete, ne siamo felici. Per favore però non eseguirne più di qualche dozzina sulla stessa rete, poiché parte dell'obiettivo della rete Tor è la dispersione e la diversità.

Se decidi di eseguire più di un relè, per favore imposta l'opzione di configurazione "MyFamily" nel torrc di ciascun relè, elencando tutti i relè (separati da virgola) che sono sotto il tuo controllo:

MyFamily $fingerprint1,$fingerprint2,$fingerprint3

dove ogni fingerprint è l'impronta di identificazione di 40 caratteri (senza spazi).

In questo modo, i client Tor sapranno evitare l'uso di multipli tuoi relè in un singolo circuito. Dovresti impostare MyFamily se hai il controllo amministrativo dei computer o della loro rete, anche se non sono tutti nella stessa posizione geografica.

Le opzioni di contabilità nel file torrc consentono di specificare la quantità massima di byte utilizzata dal tuo relè per un periodo di tempo.

    AccountingStart day week month [day] HH:MM

Questo specifica quando resettare il conteggio. Ad esempio, per impostare un numero totale di byte serviti in una settimana (che si resetta ogni mercoledì alle 10:00), utilizza:

    AccountingStart week 3 10:00
    AccountingMax 500 GBytes

Questo specifica la quantità massima di dati che il relè invierà durante un periodo di conteggio e la quantità massima di dati che il relè riceverà durante tale periodo. Quando il periodo contabile si resetta (da AccountingStart), i contatori di AccountingMax vengono reimpostati a 0.

Esempio: Supponiamo tu voglia consentire 50 GB di traffico ogni giorno in ogni direzione e il conteggio deve resettarsi a mezzogiorno ogni giorno:

    AccountingStart day 12:00
    AccountingMax 50 GBytes

Si noti che il tuo relè non si attiva esattamente all'inizio di ogni periodo di conteggio. Terrà traccia di quanto velocemente ha usato la sua quota nell'ultimo periodo e sceglierà un punto casuale nel nuovo intervallo per attivarsi. In questo modo evitiamo che centinaia di relè funzionino all'inizio di ogni mese, ma che nessuno sia ancora attivo alla fine.

Se hai solo una piccola quantità di banda da donare rispetto alla velocità della tua connessione, ti consigliamo di utilizzare il conteggio giornalierio, in modo da non finire l'intera quota mensile nel primo giorno. Dividi semplicemente per 30. Potresti anche considerare la limitazione della velocità per diffondere la tua utilità in più momenti della giornata: se vuoi offrire X GB in ogni direzione, puoi impostare RelayBandwidthRate su 20*X KBytes. Ad esempio, se hai 50 GB da offrire in ogni direzione, puoi impostare RelayBandwidthRate a 1000 KBytes: in questo modo il tuo relè sarà sempre utile per almeno la metà di ogni giorno.

    AccountingStart day 0:00
    AccountingMax 50 GBytes
    RelayBandwidthRate 1000 KBytes
    RelayBandwidthBurst 5000 KBytes # consente burst più elevati ma mantiene la media

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. Per il momento Tor richiederà indirizzi IPv4 sui relè, non è possibile eseguire un relè Tor su un host con solo indirizzi IPv6.

I parametri assegnati in AccountingMax e BandwidthRate si applicano sia alle funzioni del client che del relè del processo Tor. Perciò potresti scoprire di non essere in grado di navigare non appena Tor entra in ibernazione, segnalato da questa voce nel registro:

Limite della banda di rete raggiunto; avvio dell'ibernazione.
Non verranno accettate nuove connessioni

La soluzione è eseguire due processi Tor: un relè e un client, ognuno con la propria configurazione. Un modo per fare ciò (se si parte da una configurazione di relè funzionante) è il seguente:

  • Nel file torrc del relè Tor, imposta semplicemente la SocksPort a 0.
  • Crea un nuovo file torrc del client da torrc.sample e assicurati che utilizzi un file di registro diverso dal relè. Una convenzione potrebbe essere torrc.client and torrc.relay.
  • Modifica il client Tor e lo script di avvio del relè per includere -f/path/to/correct/torrc.
  • In Linux/BSD/Mac OS X, modificare gli script di avvio a Tor.client eTor.relay può facilitare la separazione delle configurazioni.

Ottimo. Questo è esattamente il motivo per cui abbiamo implementato le politiche di uscita.

Ogni relè Tor ha una politica di uscita che specifica quale tipo di connessioni in uscita sono consentite o rifiutate da quel relè. Le politiche di uscita vengono propagate ai client Tor tramite la directory, quindi i client eviteranno automaticamente di selezionare i relè di uscita che si rifiuterebbero di uscire alla destinazione prevista. In questo modo ogni relè può decidere i servizi, gli host e le reti a cui vuole consentire le connessioni, in base al potenziale di abuso e alla propria situazione. 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.

La politica di uscita predefinita consente l'accesso a molti servizi popolari (ad es. Navigazione web), ma ne limita alcuni a causa del potenziale abuso (ad es. Posta) e altri poiché la rete Tor non è in grado di gestirne il carico (ad es. Porte predefinite per la condivisione di file). Puoi cambiare la tua politica di uscita modificando il file torrc. If you want to avoid most if not all abuse potential, set it to "reject *:*". Questa impostazione indica che il tuo relè verrà utilizzato per inoltrare il traffico all'interno della rete Tor, ma non per le connessioni a siti Web esterni o altri servizi.

Se si autorizzano le connessioni in uscita, assicurarsi che la risoluzione dei nomi funzioni (ovvero, che il computer sia in grado di risolvere correttamente gli indirizzi Internet). Se ci sono risorse che il tuo computer non è in grado di raggiungere (ad esempio, sei dietro un firewall restrittivo o un filtro di contenuti), ti preghiamo di respingerle esplicitamente nella tua politica di uscita, altrimenti gli utenti di Tor saranno influenzati.

Tor può gestire relè con indirizzi IP dinamici senza problemi. 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.

Sì, ottieni migliore anonimato contro certi attacchi.

L'esempio più semplice è un attaccante che possiede un piccolo numero di relè Tor. Questi vedranno una connessione proveniente da te, ma non saranno in grado di stabilire se la connessione origina dal tuo computer o è stata inoltrata da qualcun'altro.

Ci sono alcuni casi in cui non sembra aiutare: se un attaccante può guardare tutto il tuo traffico in entrata e in uscita, allora è facile per lui scoprire quali connessioni sono inoltrate e quali originano da te. (In questo caso non conoscono comunque le tue destinazioni a meno che non le stiano osservando, ma non sei messo meglio rispetto a un normale client.)

Ci sono anche alcuni aspetti negativi nell'eseguire un relè Tor. In primo luogo, essendoci solo poche centinaia di relè, il fatto che tu ne stia eseguendo uno potrebbe segnalare a un utente malintenzionato che attribuisci un valore elevato al tuo anonimato. In secondo luogo, ci sono alcuni attacchi più esoterici che non sono così ben compresi o ben testati che si basano sulla nozione che stai eseguendo un relè -- ad esempio, un utente malintenzionato potrebbe essere in grado di "osservare" se stai inviando traffico anche se non è in grado di osservare la tua rete, inoltrando il traffico attraverso il tuo relè Tor e notando cambiamenti nei tempi del traffico.

E' una questione irrisolta se i benefici superano i rischi. Molto dipende dagli attacchi di cui sei più preoccupato. Per la maggior parte degli utenti, pensiamo che sia una mossa intelligente.

Vedi portforward.com per direzionare le porte del tuo Nat/router dispositivo.

Se il tuo relè è in esecuzione su una rete interna, è necessario impostare il port forwarding. Forwarding TCP connections is system dependent but the firewalled-clients FAQ entry offers some examples on how to do this.

Inoltre, qui c'è un esempio di come fare ciò su GNU/Linux utilizzando iptables:

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

Potresti dover cambiare "eth0" se hai un'interfaccia esterna (quella connessa a Internet) diversa. È probabile che tu ne abbia solo uno (tranne il loopback), quindi non dovrebbe essere troppo difficile da capire.

Ci sono due opzioni che puoi aggiungere al tuo file torrc:

BandwidthRate è la massima larghezza di banda a lungo termine consentita (byte al secondo). Ad esempio, potresti voler scegliere "BandwidthRate 10 MBytes" per 10 megabyte al secondo (una connessione veloce) o "BandwidthRate 500 KBytes" per 500 kilobyte al secondo (una connessione via cavo decente). L'impostazione minima di BandwidthRate è 75 kilobyte al secondo.

BandwidthBurst è una pool di byte utilizzato per soddisfare le richieste durante brevi periodi di traffico al di sopra del BandwidthRate ma mantiene comunque la media sul lungo periodo al BandwidthRate. Un tasso basso ma un rinforzo elevato impone una media a lungo termine pur consentendo più traffico durante le ore di punta se la media non è stata raggiunta di recente. Ad esempio, se scegli "BandwidthBurst 500 KBytes" e lo usi anche per BandwidthRate, non utilizzerai mai più di 500 kilobyte al secondo; ma se scegli un BandwidthBurst più alto (come 5 MBytes), consentirà più byte fino a quando la pool non si svuota.

Se hai una connessione asimmetrica (upload inferiore al download) come un modem via cavo, dovresti impostare il BandwidthRate al valore inferiore fra i due (di solito è la larghezza di banda dell'upload). Altrimenti, potresti fermare molti pacchetti durante i periodi di massimo utilizzo della larghezza di banda - potresti dover sperimentare quali valori rendono stabile la tua connessione. Quindi imposta BandwidthBurst allo stesso valore di BandwidthRate.

I nodi Tor basati su Linux hanno un'altra opzione a loro disposizione: possono prioritizzare il traffico Tor rispetto ad altri traffici sul loro computer, in modo tale che il loro traffico personale non sia impattato dal carico di Tor. A script to do this can be found in the Tor source distribution's contrib directory.

Inoltre, ci sono opzioni di ibernazione in cui puoi dire a Tor di servire solo una certa quantità di larghezza di banda per periodo di tempo (come 100 GB al mese). Questi sono trattati nella voce di ibernazione di seguito.

Nota che BandwidthRate e BandwidthBurst sono in Byte, non in Bit.