Come gestire un relay Tor su un VPS Linux

Cosa fa un relay Tor su un VPS

Un relay Tor è un demone Tor eseguito su una macchina con un indirizzo IP pubblico, che inoltra traffico crittografato per conto di altri utenti. Le directory authority lo pubblicano e i client Tor costruiscono circuiti attraverso di esso. Un relay guard o middle inoltra il traffico esclusivamente a un altro relay. Non apre quindi connessioni verso i siti web per conto di estranei. È proprio questo il motivo per cui non riceve segnalazioni di abuso e per cui rappresenta il contributo più adatto a un VPS comune.

L'attività richiesta è limitata: un pacchetto, quindici righe di configurazione, una regola del firewall e un riavvio. Il resto di questa guida riguarda gli aspetti che possono causare problemi: il calcolo della larghezza di banda in un piano a consumo e il motivo per cui un relay nuovo e perfettamente funzionante può sembrare inattivo per una settimana.

Guard, middle, bridge o exit: scegli prima di installare

Un solo demone gestisce tutti e quattro i ruoli. Il tuo file di configurazione, insieme alle directory authority, determina quale ruolo assumi.

• Middle relay. Riceve il traffico da un guard e lo inoltra a un altro relay. Non contatta mai il sito di destinazione. Ogni nuovo relay inizia da qui.
• Guard relay. Usa la stessa configurazione, con un flag aggiuntivo. Le directory authority assegnano il flag Guard ai relay che sono rimasti sufficientemente veloci e stabili per un periodo adeguato. Non puoi sceglierlo. Devi ottenerlo, e la configurazione riportata di seguito è ciò che ti permette di farlo.
• Bridge. È un relay escluso intenzionalmente dalla directory pubblica e distribuito privatamente agli utenti che si trovano in luoghi in cui Tor è bloccato. È il ruolo che richiede l'impegno minore tra i quattro: usa poca banda, non viene pubblicato nella directory ed è il primo passo corretto se il tuo piano è di dimensioni ridotte.
• Exit relay. È l'ultimo hop e apre la connessione al sito di destinazione. Ogni richiesta effettuata da un utente esce dal tuo indirizzo IP, quindi le segnalazioni di abuso e le richieste della polizia arrivano al titolare di quell'indirizzo.

L'exit è l'unico ruolo che non dovrebbe essere eseguito su un VPS general-purpose. Esegui un exit soltanto presso un provider che abbia accettato in anticipo di ricevere queste comunicazioni, con un proprio indirizzo IP e un contatto abuse pubblicato. La maggior parte delle condizioni standard di hosting lo vieta, e di norma ignorarle causa la sospensione del server e la perdita dell'indirizzo IP. Un guard o un middle relay trasporta lo stesso traffico degli utenti senza questa esposizione.

Tutto ciò che segue configura un guard/middle relay. ExitRelay 0 è la riga che lo mantiene in questo ruolo.

Cosa serve al VPS prima di iniziare

Il Tor Project pubblica requisiti minimi precisi per i relay. Ad agosto 2026 sono: un indirizzo IPv4 pubblico per il relay, almeno 10 Mbit/s di banda in entrambe le direzioni, con 16 Mbit/s consigliati, almeno 100 GB di traffico in uscita al mese e 512 MB di RAM sotto i 40 Mbit/s oppure 1 GB oltre tale velocità. Non esiste una regola fissa sull'uptime, ma un relay attivo per meno di due ore al giorno è di scarsa utilità per la rete.

Il valore di 10 Mbit/s descrive la linea, non l'impostazione. Serve una porta che supporti questa velocità. La quantità di banda che si autorizza al relay è una decisione separata, da valutare in base al limite mensile di trasferimento. Leggi il piano prima di modificare la configurazione. Se stai ancora scegliendo un server, quanto costa davvero un VPS al mese spiega come vengono venduti i limiti di trasferimento, mentre misurare il throughput di rete reale di un VPS mostra come verificare le prestazioni della linea con iperf3 invece di fidarsi della pagina commerciale.

Metti in sicurezza la macchina prima di tutto. Un relay è un servizio pubblico su un indirizzo pubblico e l'indirizzo viene sottoposto a scansioni entro pochi minuti dalla pubblicazione. limitare SSH alle chiavi e configurare sshd in modo sicuro richiede dieci minuti e deve essere fatto prima di rendere operativo il relay, non dopo.

Installare Tor dal repository di Tor Project

Usare il repository apt ufficiale di Tor Project invece del pacchetto della distribuzione. Il codice del relay viene aggiornato più rapidamente rispetto a una release stabile, quindi le correzioni arrivano prima in questo repository e il pacchetto della distribuzione rimane indietro tra una release e l’altra.

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

Aggiungere la chiave di firma, quindi il repository. Il codename viene letto dalla macchina, quindi lo stesso blocco funziona su Ubuntu 24.04 (noble) e Debian 13 (trixie).

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

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

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $CODENAME
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg
EOF

sudo apt update
sudo apt install -y tor deb.torproject.org-keyring
tor --version

tor --version stampa la versione appena installata. Se invece apt update ha stampato un errore NO_PUBKEY, la chiave dearmored non si trova nel percorso indicato nella riga Signed-By:, quindi apt non dispone di una chiave con cui verificare il file di release. Il pacchetto deb.torproject.org-keyring sarà importante in seguito: distribuisce la chiave di firma come pacchetto ordinario, quindi apt continua a funzionare quando la chiave viene ruotata.

Abilitare gli aggiornamenti automatici, quindi configurare la nuova origine.

sudo apt install -y unattended-upgrades apt-listchanges

Su Ubuntu, aggiungere l’origine Tor al blocco Allowed-Origins in /etc/apt/apt.conf.d/50unattended-upgrades:

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

Su Debian, lo stesso file usa Origins-Pattern; la riga da aggiungere è "origin=TorProject";. Verificare il risultato con sudo unattended-upgrade --debug --dry-run, che stampa le origini su cui interverrà senza scrivere nulla.

Il file torrc da configurare

Il pacchetto installa un /etc/tor/torrc lungo e ampiamente commentato. Per un relay sono necessarie solo poche righe. Aggiungile alla fine del file.

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

Nickname contiene da 1 a 19 caratteri, esclusivamente lettere e cifre. Non è univoco nella rete e non identifica il relay: a identificarlo è il fingerprint. È il nome con cui troverai il tuo relay in una casella di ricerca, quindi scegline uno che si possa dettare al telefono senza ambiguità.

ContactInfo viene pubblicato nel relay descriptor, un documento pubblico che chiunque può scaricare; l'indirizzo verrà quindi raccolto. Usa un indirizzo che continuerai a leggere tra due anni e, se vuoi, offuscalo. Questo è l'unico canale che il Tor Project può usare per avvisarti di un problema del relay.

ORPort 9001 è la porta a cui si connettono gli altri relay e i client. 9001 è la scelta convenzionale. L'altra scelta comune è la porta 443, perché alcune reti restrittive consentono soltanto connessioni in uscita sulla porta 443; un relay in ascolto su questa porta è quindi raggiungibile da più client. Scegli 443 solo se nessun altro servizio sul server ne ha bisogno.

SocksPort 0 disabilita il proxy SOCKS locale, che un relay non utilizza, e rimuove un socket in ascolto dal server. ExitRelay 0 rende esplicita questa scelta nel file: il relay non si connetterà mai a una destinazione per conto di un utente e chiunque consulterà in seguito la configurazione non dovrà dedurlo dal valore predefinito.

Se il VPS ha un indirizzo IPv6, aggiungi una seconda riga ORPort. Tor non può associarsi a un indirizzo IPv6 "any" come fa con IPv4, quindi indica l'indirizzo tra parentesi quadre.

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

Su un VPS con 1 GB, aggiungi MaxMemInQueues 512 MB. Tor determina il limite della coda in base alla memoria rilevata sul server; su un piccolo server condiviso, questo valore è superiore a quello che vuoi consentirgli di utilizzare. Impostando direttamente il limite, fai in modo che tor scarti le celle accodate quando la memoria è sotto pressione; il relay continua così a funzionare invece di aumentare la coda fino a quando il kernel termina il processo.

Aprire la ORPort nel firewall

In ingresso, la ORPort deve essere raggiungibile da qualsiasi punto di Internet. In uscita, lasciare il relay senza restrizioni: apre connessioni verso migliaia di altri relay su molte porte diverse e una allowlist per il traffico in uscita lo renderebbe inutilizzabile senza produrre errori evidenti.

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

Controllare quindi anche il firewall di rete del provider. Molti pannelli di controllo eseguono un filtro dei pacchetti davanti alla macchina virtuale. In questo caso, una regola aggiunta con ufw non ha effetto: la porta risulta aperta sulla macchina, ma chiusa dall'esterno. Se ufw è una novità, le regole ufw da applicare su ogni VPS spiega la policy predefinita e l'ordine di valutazione delle regole.

Dimensionare la larghezza di banda in base al piano

Il manuale descrive RelayBandwidthRate come un token bucket separato che limita «l'utilizzo medio della larghezza di banda in ingresso per il traffico inoltrato su questo nodo al numero di byte al secondo specificato e l'utilizzo medio della larghezza di banda in uscita allo stesso valore». Rileggi questa frase. Il limite si applica separatamente a ciascuna direzione. Un relay configurato a 1 Mbit/s può trasferire contemporaneamente 1 Mbit/s in ingresso e 1 Mbit/s in uscita; un provider che contabilizza entrambe le direzioni addebita la somma.

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

Le 5 righe sono calcoli aritmetici, non misurazioni: mostrano quanto costa una velocità se il relay la mantiene per tutti i 30 giorni, in entrambe le direzioni. Un relay resta al di sotto del limite per gran parte del tempo, soprattutto nelle prime settimane. Usa la tabella per escludere impostazioni incompatibili con il piano, non per prevedere una fattura al gigabyte.

A 1 Mbit/s in ciascuna direzione, un relay trasferisce circa 21.6 GB al giorno; in un mese di 30 giorni, il traffico contabilizzato ammonta quindi a circa 648 GB. Questo rientra in un tetto di 1 TB, lasciando margine per aggiornamenti e backup. Passando a 2 Mbit/s, il mese richiede 1,296 GB, oltre il limite di un piano da 1 TB. L'ultima riga, 20 Mbit/s, richiede 12,960 GB al mese e deve essere usata su una porta senza limiti di traffico. Se il provider contabilizza solo il traffico in uscita, dimezza ogni valore. Verifica quale criterio applica il tuo provider prima di impostare la velocità, perché i due risultati differiscono di un fattore due.

Passiamo ora alla configurazione. Prima limita la velocità, poi imposta la quota.

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

RelayBandwidthBurst è la dimensione del token bucket, quindi consente picchi brevi superiori alla velocità configurata mentre mantiene il valore medio entro il limite. Un valore pari a circa il doppio della velocità è una scelta ragionevole.

AccountingRule è la riga che molti operatori trascurano. Il valore predefinito è max e confronta con la quota la direzione con il consumo maggiore. Con il valore predefinito, AccountingMax 400 GBytes consente 400 GB in ingresso e 400 GB in uscita, per un totale di 800 GB su un contatore che considera entrambe le direzioni. AccountingRule sum conta letture e scritture insieme rispetto a un'unica quota, che corrisponde alla misura effettiva di un limite sul trasferimento.

Scrivi anche AccountingStart, mai AccountingMax da solo. La quota è il valore numerico; la riga di avvio indica il momento in cui il periodo viene reimpostato. Una quota senza periodo lascia il relay in ibernazione, senza alcun evento che possa riattivarlo.

L'ibernazione è una misura drastica. Quando la quota si esaurisce, tor registra questo evento e smette di accettare lavoro:

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

Il relay non si riattiva esattamente all'inizio del periodo successivo. Tor calcola la velocità con cui ha consumato l'ultima quota e sceglie un momento casuale all'interno del nuovo intervallo, così migliaia di relay non rientrano nella rete nello stesso secondo. Un relay che scompare durante l'ultima settimana di ogni mese perde continuamente la stabilità sulla quale le autorità della directory lo valutano. Dimensiona RelayBandwidthRate in modo che il limite non venga mai raggiunto e mantieni AccountingMax come protezione finale per evitare sorprese in fattura.

Avviare il relay e verificare che sia raggiungibile

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

Entro pochi minuti, il log dovrebbe contenere questa riga:

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

Questa frase indica che altri relay si sono connessi alla tua ORPort e hanno creato un circuito attraverso di essa. Finché non compare, il tuo relay non è presente nella directory e non trasporta alcun traffico. L'errore è il seguente:

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

Procedi con le verifiche nell'ordine indicato. La ORPort è aperta in ufw? È aperta anche nel firewall di rete separato del provider? L'indirizzo mostrato nel messaggio è quello a cui Internet instrada effettivamente le connessioni, anziché un indirizzo privato di una configurazione NAT? Verifica la porta da un'altra macchina con nc -vz 203.0.113.10 9001. Tor ripete autonomamente il test di raggiungibilità, quindi rileva senza interventi aggiuntivi la correzione del firewall; un riavvio rende il controllo immediato.

L'identità permanente del relay è il suo fingerprint:

sudo cat /var/lib/tor/fingerprint

Circa tre ore dopo la pubblicazione del descriptor, il relay compare in Relay Search. Cerca il nickname oppure incolla il fingerprint. Questa pagina mostra come la rete considera il tuo relay: quali flag possiede, quale peso gli assegnano le authority e quale versione sta pubblicando.

Perché un nuovo relay Tor gestisce quasi nessun traffico?

Perché la rete non lo ha ancora misurato e la misurazione richiede settimane. Il Tor Project descrive questa fase in quattro passaggi, ma un operatore che non li conosce conclude che il relay non funziona e inizia a modificare la configurazione.

Per i primi tre giorni il relay non è misurato. Pubblica il risultato del proprio self-test, ma le directory authority limitano comunque il peso pubblicato a 20 KB, quindi i client lo scelgono quasi mai. Da circa il terzo all'ottavo giorno le bandwidth authority lo misurano effettivamente e il peso aumenta, ma il relay viene usato soltanto come middle hop, perché nessun client è disposto a usare un relay completamente nuovo come primo hop.

Verso l'ottavo giorno il relay può ottenere il flag Guard. L'assegnazione del flag fa diminuire il traffico, cosa che sorprende molti operatori: quando scelgono i middle hop, i client escludono i guard perché presumono che un guard sia già impegnato. Di conseguenza il relay perde traffico come middle hop prima di guadagnare traffico come guard. Il traffico torna a crescere soltanto quando i client ruotano i propri set di guard, un processo che richiede settimane. Dopo circa 68 giorni raggiunge uno stato stabile, nel quale i client che lo rimuovono compensano quelli che lo aggiungono.

L'aspettativa realistica è quindi nessun traffico per tre giorni, qualche risultato dopo una settimana e un carico significativo dopo due mesi. Modifica una sola impostazione, poi attendi una settimana per valutarne l'effetto. Una pagina di stato self-hosted di Uptime Kuma con un controllo TCP sulla porta 9001 usa meglio l'energia spesa a preoccuparsi: risponde alla domanda che puoi davvero controllare, cioè se la porta continua a rispondere.

Monitorare il relay con nyx

nyx è il monitor da terminale per un relay in esecuzione. Comunica con la porta di controllo di tor, quindi abilitala prima in torrc:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort è in ascolto solo su 127.0.0.1 e l'autenticazione tramite cookie richiede che un programma legga un file segreto prima di poter eseguire comandi. Tor scrive questo cookie in /run/tor/control.authcookie con l'utente debian-tor e la modalità 600, così nessun altro può leggerlo. CookieAuthFileGroupReadable 1 lo rende accessibile al gruppo, consentendo al tuo account di eseguire nyx senza sudo.

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

Esci dalla sessione e accedi nuovamente, quindi esegui nyx. Il nuovo gruppo deve essere acquisito al login; se esegui nyx nella stessa sessione della shell, riceverai un errore di autorizzazione sul file cookie anche se la configurazione è corretta. nyx mostra la larghezza di banda in tempo reale, il tempo di attività, il flusso dei log e l'elenco delle connessioni. Nelle prime settimane, il valore da monitorare è il grafico della larghezza di banda, che deve restare al di sotto di RelayBandwidthRate.

Eseguire più relay: MyFamily e le chiavi di famiglia

Con un solo relay, saltare questa sezione. Due o più relay gestiti dallo stesso operatore devono dichiararsi reciprocamente, in modo che i client non costruiscano mai un circuito che entra ed esce attraverso le vostre macchine. In caso contrario, un singolo operatore potrebbe vedere entrambe le estremità del circuito.

Il metodo storico consiste nell'usare MyFamily nel file torrc di ogni relay, elencando le fingerprint di tutti gli altri:

MyFamily AAAAAAAAAA,BBBBBBBB

Ogni relay elenca tutti gli altri. Per aggiungere un quarto relay, è quindi necessario modificare quattro file. Tor 0.4.9 ha sostituito questo metodo con una family key. Generare una chiave e quindi condividerla:

tor --keygen-family myfamily

Questo comando scrive myfamily.secret_family_key e visualizza una riga FamilyId. Copiare il file della chiave su ogni relay, nella sottodirectory keys di DataDirectory (/var/lib/tor/keys su Debian e Ubuntu), mantenendo il suffisso .secret_family_key. Aggiungere la riga FamilyId visualizzata a ogni torrc e ricaricare la configurazione con sudo systemctl reload tor@default. Per il momento, mantenere anche l'elenco MyFamily. I client che non supportano ancora i certificati di famiglia continuano a leggere l'elenco precedente. Il Tor Project comunicherà quando sarà possibile rimuoverlo.

Cosa può rompersi dopo l'avvio

La versione diventa obsoleta. Gli aggiornamenti automatici sostituiscono il pacchetto, ma il processo in esecuzione continua a usare il binario con cui è stato avviato finché non viene riavviato. Confrontare tor --version sul server con la versione mostrata nella pagina Relay Search del relay. Se differiscono, la rete vede ancora quella precedente: riavviare il servizio.

L'orologio del sistema si desincronizza. I documenti di consenso e i certificati sono vincolati al tempo. Una macchina il cui orologio è molto fuori sincronia rifiuta il consenso e interrompe la pubblicazione. timedatectl dovrebbe indicare che l'orologio di sistema è sincronizzato. In caso contrario, abilitare systemd-timesyncd oppure installare chrony.

L'indirizzo IP cambia. Il descriptor contiene l'indirizzo e i client non possono raggiungere un indirizzo che è cambiato. Dopo una migrazione del provider o qualsiasi modifica dell'indirizzo, riavviare tor e verificare nuovamente la riga del self-test.

Il relay è più lento di quanto consenta il piano. La crittografia dei relay Tor è efficiente sui processori moderni. Tor Project indica per una CPU con supporto AES-NI una velocità di circa 400-450 Mbit/s in ciascuna direzione. Molto prima di raggiungere questo limite, i vincoli diventano la velocità della porta e il limite di trasferimento. Per questo la sezione sulla contabilizzazione riportata sopra è più importante dell'hardware.

FAQ

Quanta banda utilizza un relay Tor?

Tutta quella consentita, e non di più. RelayBandwidthRate limita il traffico inoltrato separatamente in ciascuna direzione, quindi un relay impostato a 1 Mbit/s può gestire contemporaneamente 1 Mbit/s in ingresso e 1 Mbit/s in uscita. Questo corrisponde a circa 21.6 GB al giorno, oppure 648 GB in un mese di 30 giorni, considerando entrambe le direzioni. Aggiungi AccountingMax con AccountingRule sum come quota mensile massima da applicare a quella velocità.

L'esecuzione di un relay Tor genera segnalazioni di abuso?

Un relay guard o middle inoltra il traffico soltanto ad altri relay Tor e non si connette mai a un sito web per conto di un utente. Le segnalazioni relative alle attività svolte tramite Tor vengono quindi inviate all'operatore del relay exit, non a te. Potresti invece rilevare scansioni e occasionali inserimenti dell'indirizzo IP in liste di reputazione, perché l'indirizzo è pubblicamente associato a un relay. Sono i relay exit a ricevere messaggi di abuso e comunicazioni legali; devono quindi usare un provider che abbia accettato in anticipo di gestire queste richieste. Leggi i termini del provider prima di avviare uno dei due tipi di relay.

Perché il mio nuovo relay Tor non riceve traffico?

Perché i nuovi relay vengono limitati intenzionalmente finché non sono stati misurati. Nei primi tre giorni le directory authority limitano a 20 KB il peso pubblicato, quindi i client scelgono il relay solo in casi eccezionali. Le bandwidth authority ne misurano la capacità a partire circa dal terzo giorno; il relay può ottenere il flag Guard intorno all'ottavo giorno. A quel punto il traffico diminuisce nuovamente, perché i client evitano i guard quando selezionano gli hop middle. Il carico completo arriva intorno al giorno 68. Verifica che il log mostri "Self-testing indicates your ORPort is reachable from the outside", quindi non modificarlo.

Posso eseguire un relay Tor su un VPS con un limite di trasferimento di 1 TB?

Sì, a circa 1 Mbit/s in ciascuna direzione, cioè RelayBandwidthRate 125 KBytes. Se il provider conteggia entrambe le direzioni, il consumo è di circa 648 GB al mese e rimane margine per aggiornamenti e backup. Aggiungi AccountingMax 400 GBytes con AccountingRule sum e AccountingStart month 1 00:00, in modo che il relay entri in modalità hibernation invece di superare il limite del piano. Se il provider fattura soltanto il traffico in uscita, puoi raddoppiare la velocità.

Devo impostare MyFamily se eseguo un solo relay?

No. Le dichiarazioni di famiglia servono ai client per evitare di costruire un circuito attraverso due relay gestiti dallo stesso operatore. Con un solo relay non hanno alcun effetto. Impostale appena aggiungi un secondo relay: inserisci il fingerprint di ogni relay nella riga MyFamily di tutti i relay, oppure usa la family key introdotta da Tor 0.4.9, che distribuisce un solo FamilyId invece di un elenco sempre più lungo.