Come gestire un nodo di uscita Tor

Che cosa fa un nodo di uscita Tor e chi rende identificabile

Un nodo di uscita Tor è l’ultimo relay di un circuito: il sistema che apre la connessione verso la destinazione. Per questo la destinazione registra l’indirizzo del tuo server e non quello dell’utente. Ogni altra decisione descritta in questa guida deriva da questo fatto. L’indirizzo viene considerato l’origine di tutto il traffico che lo attraversa. Deve quindi essere un indirizzo dedicato esclusivamente a questo scopo, presso un provider che abbia accettato di trasportare questo traffico.

Gestire un nodo di uscita è l’opposto di nascondersi. Il relay è elencato in una directory pubblica che chiunque può scaricare. Il tuo indirizzo di contatto compare nella directory alla voce ContactInfo. Il reverse DNS (domain name system) comunica che cosa è il server. La porta 80 pubblica una pagina che comunica la stessa informazione. Inoltre rispondi personalmente alle comunicazioni relative agli abusi, usando il tuo nome. In questo sistema, nessuno è più facilmente identificabile di un operatore di un nodo di uscita. Questo è il compito del nodo di uscita ed è il motivo per cui funziona.

Gestiamo questi nodi. SSD Nodes gestisce relay di uscita in diversi Paesi come contributo alla libertà di espressione. Noleggiamo queste macchine da provider che hanno scelto deliberatamente di accettare traffico di uscita e non siamo il provider di tali macchine. È una scelta intenzionale. La sezione successiva spiega il motivo.

Dove è appropriato un exit relay e dove no

Un exit relay non è adatto a un VPS (virtual private server) generico, incluso il nostro. Una rete generica trasporta siti web, posta, backup e pannelli di controllo per migliaia di clienti non correlati, su indirizzi adiacenti. Il traffico in uscita dell’exit relay inserisce uno di questi indirizzi nei report di scansione e nelle blocklist antispam, con conseguenze anche per gli indirizzi vicini. I provider che ospitano correttamente gli exit relay hanno predisposto l’infrastruttura necessaria: spazio di indirizzamento dedicato e un abuse desk che conosce già Tor.

Quindi, quando un host che pubblica questa guida ti consiglia di acquistare la macchina altrove, questo è l’aspetto utile. Sappiamo quali effetti ha il traffico di un exit relay su un indirizzo perché paghiamo altri soggetti per trasportare il nostro, e li paghiamo perché gestirlo correttamente è un’attività diversa dalla vendita di server generici.

Il Tor Project afferma la stessa cosa in termini ancora più diretti. La pagina tipi di relay afferma che gli exit relay «hanno la maggiore esposizione legale e responsabilità tra tutti i relay» e che «non dovresti eseguire un Tor exit relay dalla tua abitazione». Un VPS generico che ospita i tuoi progetti è più vicino a casa di quanto sembri. È una macchina che ti interessa, su un indirizzo che vuoi mantenere senza segnalazioni negative.

Se hai un VPS ordinario e questa settimana vuoi contribuire alla rete, esegui un relay non-exit oppure un bridge. Non è un ripiego. È un’attività diversa, con un profilo di rischio diverso, ed entrambi sono necessari alla rete. Un relay non-exit non apre mai una connessione verso una destinazione, quindi genera quasi nessuna segnalazione, e le indicazioni di Tor richiedono almeno 2 MByte/s (megabyte al secondo) in entrambe le direzioni prima che valga la pena pubblicarlo nell’elenco. Un bridge è un punto di ingresso non pubblicato per gli utenti nelle reti sottoposte a censura. Richiede connettività 24/7 e una porta TCP (transmission control protocol) aperta, caratteristiche che lo rendono l’impiego più utile che una macchina di piccole dimensioni possa offrire. Entrambi sono adatti all’hardware che già possiedi. Un exit relay no.

Come trovare un provider disponibile a ospitare un exit?

Chiedetelo prima dell'ordine, per iscritto, e conservate la risposta. Le linee guida per gli exit di Tor suggeriscono di porre la domanda in due passaggi: prima chiedete se il provider accetta in generale un exit Tor, poi chiedete se assegnerà un indirizzo o un intervallo dedicato. Porre entrambe le domande insieme tende a produrre un rifiuto automatico.

Quattro domande permettono di capire se un provider è realmente preparato a gestire questo tipo di servizio.

• Assegnerete un indirizzo IP dedicato, sul quale non sarà ospitato nient'altro, e imposterete il record DNS inverso che vi indicherò?
• Chi riceve i messaggi di abuso e potrete inoltrarmeli senza modificarli, mantenendo intatto l'indirizzo del segnalante così che io possa rispondergli direttamente?
• Cosa succede alla prima segnalazione: me la inoltrate oppure applicate prima un null route all'indirizzo e chiedete spiegazioni dopo?
• Quanti exit sono già presenti su questa rete? Le linee guida di Tor sono chiare: "non è utile concentrare troppi exit presso lo stesso ISP disponibile".

L'ultima domanda è più importante di quanto sembri. Parte del valore di un exit dipende dalla sua posizione nella rete. Un altro exit su una rete che ne ospita già cinquanta aggiunge meno valore rispetto alla stessa macchina collocata in una rete nuova. Relay Search mostra quali reti ospitano già degli exit, così potete verificare la situazione prima di impegnarvi.

Ottenete le risposte prima di pagare e acquistate la macchina con un account separato, invece di aggiungerla all'account che contiene gli altri server. La sicurezza dell'hosting VPS dipende soprattutto da quali sistemi mettete vicini tra loro, e questo è l'esempio più chiaro di questa regola.

Un solo indirizzo, un solo servizio

L'indirizzo pubblico non deve ospitare nient'altro. Nessun sito web, server di posta, VPN, dashboard di monitoraggio o jump host SSH (secure shell) personale. L'indirizzo finirà nelle blocklist e qualsiasi altro servizio che vi risiede inizierà a presentare problemi difficili da diagnosticare. Un indirizzo dedicato a un solo scopo consente inoltre di rispondere brevemente alle segnalazioni: questo indirizzo è un exit relay e non svolge altre funzioni.

Prima di installare tor, esegui le attività ordinarie. Usa SSH con autenticazione tramite sole chiavi e disabilita l'accesso con password. Configura inoltre un firewall che consenta soltanto le porte pubblicate. Mettere in sicurezza SSH su un VPS illustra il primo passaggio, mentre Nozioni di base sul firewall ufw illustra il secondo. Un exit pubblica esattamente due porte verso Internet: la ORPort, che trasporta il traffico Tor, e la porta 80 per la pagina con l'avviso dell'exit. Tutto il resto deve rimanere chiuso.

Attiva gli aggiornamenti automatici non presidiati, perché un exit che esegue una versione obsoleta di tor costituisce un problema per ogni utente il cui traffico viene instradato attraverso quel relay.

sudo apt update && sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Non aggiungere il logging. Acquisire il traffico in chiaro che esce da un exit è tecnicamente semplice, ma è l'unica attività che un operatore non deve mai svolgere. La FAQ legale di Tor dell'EFF raccomanda agli operatori di non farlo, perché la normativa statunitense sulle intercettazioni e normative analoghe di altri Paesi possono comportare responsabilità per l'analisi di quel traffico. Mantieni il logging predefinito di tor al livello notice e non aggiungere altro.

Installare Tor dal repository del Tor Project

I pacchetti della distribuzione sono spesso arretrati. Usare il repository del Tor Project per ricevere le correzioni di sicurezza il giorno stesso del rilascio. Ad agosto 2026 la serie stabile corrente è la 0.4.9.

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

Scrivere /etc/apt/sources.list.d/tor.sources, sostituendo noble con il codename restituito da lsb_release -cs:

Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: noble
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg

Aggiungere la chiave di firma, quindi installare:

wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null
sudo apt update
sudo apt install -y tor deb.torproject.org-keyring
tor --version

Il pacchetto deb.torproject.org-keyring mantiene aggiornata automaticamente questa chiave, evitando che il repository smetta di funzionare quando la chiave viene sostituita. Se apt update segnala che lo stesso repository è configurato due volte, sono presenti sia un file .list sia un file .sources che lo definiscono; l'errore relativo alla sorgente deb822 duplicata spiega come risolvere il problema.

DNS: il tuo exit risolve i nomi per tutti gli utenti che lo utilizzano

Un exit esegue le ricerche DNS per ogni circuito che lo attraversa, quindi il suo resolver vede un flusso di nomi appartenenti ad altre persone. Se lo indirizzi verso un resolver pubblico di grandi dimensioni, consegni l'intero flusso a una sola azienda: è proprio la centralizzazione che Tor chiede agli operatori degli exit di evitare. Esegui invece sul server un resolver con validazione e cache.

sudo apt install -y unbound bind9-dnsutils
sudo cp /etc/resolv.conf /etc/resolv.conf.backup
echo "nameserver 127.0.0.1" | sudo tee /etc/resolv.conf
sudo chattr +i /etc/resolv.conf
sudo systemctl enable --now unbound

chattr +i rende il file immutabile, perché i client DHCP (dynamic host configuration protocol) e resolvconf riscrivono /etc/resolv.conf secondo una propria pianificazione. Senza questa impostazione, un riavvio può riportare le richieste DNS al resolver del provider e non ricevi alcun avviso quando accade. Le istruzioni di Tor per Debian e Ubuntu abilitano anche la minimizzazione dei nomi nelle query, che invia a ciascun server dei nomi soltanto la parte del nome effettivamente necessaria:

server:
    qname-minimisation: yes

Inserisci il contenuto in un file sotto /etc/unbound/unbound.conf.d/, quindi verifica che il resolver risponda:

sudo systemctl restart unbound
dig +short example.com @127.0.0.1

La presenza di un indirizzo nella risposta indica che unbound funziona. Se unbound non si avvia con address already in use, un altro processo occupa la porta 53: esegui sudo ss -lntup | grep :53 e verifica quale processo la utilizza. In Ubuntu, systemd-resolved è in ascolto su 127.0.0.53, quindi non entra in conflitto con unbound su 127.0.0.1.

Il file torrc per un relay di uscita

Il pacchetto Debian legge /etc/tor/torrc. Questa è l’intera configurazione relativa all’uscita.

Nickname     exampleExit01
ORPort       443
ExitRelay    1
SocksPort    0
ContactInfo  email:tor[]example.org abuse:abuse[]example.org url:https://example.org ciissversion:3
ReducedExitPolicy 1
Log          notice syslog

Ogni riga è essenziale. Esaminale quindi una alla volta.

ORPort 443 è la porta su cui gli altri relay si connettono al tuo. La porta 443 attraversa le reti restrittive che bloccano le porte insolite, quindi il relay è raggiungibile da più utenti rispetto a quanto sarebbe sulla porta tradizionale 9001. Puoi usare la 443 solo perché nessun altro servizio su questo sistema la richiede. Questo è un ulteriore motivo per usare un indirizzo dedicato.

SocksPort 0 disabilita il proxy SOCKS locale. Un relay non ne ha mai bisogno. Una porta SOCKS in ascolto su un indirizzo pubblico è un proxy aperto, che verrà individuato e utilizzato impropriamente nel giro di poche ore.

ExitRelay 1 abilita la funzione di uscita. Impostala esplicitamente invece di affidarti a un valore predefinito, così il file di configurazione indica chiaramente il ruolo della macchina.

ContactInfo viene pubblicato nella directory pubblica, dove chiunque può leggerlo. Scrivilo nel formato ContactInfo Information Sharing Specification, che è quello interpretato dagli strumenti della rete, e includi ciissversion:3. Usare [] al posto di @ è la convenzione adottata da questa specifica per rallentare i sistemi che raccolgono indirizzi. Usa una casella di posta che controlli ogni giorno, perché qui arriveranno le segnalazioni di abuso.

Se il sistema dispone di IPv6 funzionante, aggiungi una ORPort IPv6 e abilita l’uscita tramite IPv6. Lascia entrambe le impostazioni assenti se IPv6 non è disponibile, perché un relay che pubblicizza un indirizzo che non può usare realmente non supera il proprio test di raggiungibilità.

ORPort   [2001:db8::1]:443
IPv6Exit 1

Policy di uscita: cosa consente ogni porta

La policy di uscita è l'elenco delle destinazioni a cui il relay è disposto a connettersi. Tor la legge dall'alto verso il basso e applica la prima regola corrispondente. ReducedExitPolicy 1 seleziona un elenco curato di circa settanta porte per web, invio della posta, chat e git, ed esclude le porte che generano la maggior parte delle segnalazioni. È il punto di partenza corretto per un primo exit relay.

È utile conoscere due regole per nome. ExitPolicyRejectPrivate è attiva per impostazione predefinita e impedisce all'exit relay di connettersi agli intervalli di indirizzi privati e agli indirizzi del relay stesso. In questo modo si impedisce che l'exit relay venga indirizzato verso la rete interna del provider. La porta 25 (SMTP, simple mail transfer protocol) viene rifiutata e deve restare rifiutata, perché consentirla trasforma il relay in una fonte di spam e l'indirizzo viene inserito in una blocklist nel giro di pochi giorni.

Un exit relay deve consentire le porte 80 e 443 per essere utile. La documentazione di Tor sugli exit relay lo dichiara esplicitamente. Se il provider richiede una policy più restrittiva di quella ridotta, un exit relay limitato al web resta comunque un contributo concreto:

ExitPolicy accept *:80
ExitPolicy accept *:443
ExitPolicy reject *:*

Concludi l'elenco con reject *:*, in modo che la policy sia completa e non erediti altre regole. La policy ridotta consente anche la porta 22 (SSH), che è la fonte abituale delle segnalazioni relative ai tentativi di forza bruta. Se preferisci non gestire questo tipo di messaggi, aggiungi ExitPolicy reject *:22 sopra le altre regole. Le porte per la condivisione di file nell'intervallo 6881-6999 sono la fonte abituale delle notifiche di violazione del copyright e la policy ridotta le esclude già.

Una modifica alla policy raggiunge i client soltanto dopo che il relay pubblica un nuovo descrittore e la directory lo propaga. Attendi quindi alcune ore prima di valutarne l'effetto.

Informazioni di contatto, chiavi della famiglia e registrazione del relay

Registrare un relay di uscita significa associarlo a un nome che chiunque possa verificare. Esistono due meccanismi, che operano insieme.

Il primo è un file noto. Pubblica l'identità della famiglia su un dominio che controlli, quindi indica questa prova in ContactInfo:

ContactInfo email:tor[]example.org url:https://example.org proof:uri-familyid-ed25519 ciissversion:3

Il file si trova in https://example.org/.well-known/tor-relay/ed25519-family-id.txt e contiene il tuo ID della famiglia. Chiunque può quindi confermare che chi dichiara di gestire questi relay controlla anche quel dominio. Questa è la differenza tra un indirizzo di contatto e un indirizzo verificato.

Il secondo meccanismo è la famiglia stessa. Se gestisci più di un relay, la rete deve sapere che hanno lo stesso operatore, in modo che un client non costruisca un circuito attraverso due delle tue macchine. Le versioni attuali di tor gestiscono questo aspetto con una chiave della famiglia, chiamata Happy Families, sui relay che eseguono la versione 0.4.9.2-alpha o successiva:

tor --keygen-family exampleFamily

Il comando crea exampleFamily.secret_family_key e stampa una riga FamilyId. Copia il file della chiave segreta nella directory delle chiavi di ogni relay (/var/lib/tor/keys su Debian e Ubuntu), mantieni l'estensione .secret_family_key nel nome del file, aggiungi la riga FamilyId stampata a ogni torrc e ricarica tor. La documentazione di tor specifica chiaramente che devi comunque impostare l'opzione legacy MyFamily, elencando l'impronta di ogni relay, finché il progetto non comunicherà che non è più necessaria. Configura quindi entrambe le opzioni. L'impronta di ciascun relay si trova in /var/lib/tor/fingerprint.

Con la seconda e la terza macchina iniziano a diventare importanti gli aspetti operativi; gestire più server Linux contemporaneamente pone qui lo stesso problema che si presenta in qualsiasi altro contesto. Esegui il backup di /var/lib/tor/keys in una posizione esterna al server. Se lo perdi, il relay torna a essere sconosciuto e deve ottenere nuovamente ogni flag e tutta la propria reputazione, partendo da zero.

Iscriviti anche alla mailing list tor-relays. Le modifiche che interessano gli operatori vengono annunciate prima su quella lista.

DNS inverso e avviso sull’uscita sulla porta 80

Imposta il record DNS inverso prima che il relay trasporti traffico. Le linee guida di Tor per gli exit relay indicano di configurare un nome che descriva il ruolo del server, ad esempio tor-exit-01.example.org. Il motivo è pratico. Quando nei log compare un indirizzo sconosciuto, il primo comando che l’amministratore esegue è una ricerca inversa. Un nome che contiene "tor-exit" risponde alla domanda prima che qualcuno ti contatti, trasformando una parte delle possibili segnalazioni in nessuna segnalazione. Chiedi al provider di impostare il record PTR (pointer) e aggiungi un record forward corrispondente sul tuo lato.

Quindi pubblica sulla porta 80 una pagina di avviso che comunichi lo stesso messaggio in forma testuale. Le guide meno recenti usano a questo scopo l’impostazione DirPortFrontPage di tor, che dipende da un DirPort. DirPort è deprecato per i relay a partire da tor 0.4.6.5, quindi usa invece un piccolo web server.

sudo apt install -y nginx
sudo install -d -m 755 /srv/tor-exit-notice

Scrivi /srv/tor-exit-notice/index.html:

<!DOCTYPE html>
<html>
<head><title>This is a Tor exit relay</title></head>
<body>
<h1>This is a Tor exit relay</h1>
<p>Traffic from this address was sent by a user of the Tor network. It did not
come from the operator of this machine, and this machine keeps no record of
who sent it.</p>
<p>Operator: Example Org. Abuse reports: abuse@example.org. Every report gets a
reply from a person.</p>
<p>To check whether this address was a Tor exit at a given date and time:
https://metrics.torproject.org/exonerator.html</p>
</body>
</html>

Scrivi questo blocco server in /etc/nginx/sites-available/tor-exit-notice:

server {
    listen 80 default_server;
    listen [::]:80 default_server;
    server_name _;
    root /srv/tor-exit-notice;
    index index.html;
    access_log off;
}

Abilitalo, rimuovi il sito predefinito di nginx e verifica il risultato:

sudo ln -sf /etc/nginx/sites-available/tor-exit-notice /etc/nginx/sites-enabled/tor-exit-notice
sudo rm -f /etc/nginx/sites-enabled/default
sudo nginx -t && sudo systemctl reload nginx
curl -s http://127.0.0.1/ | head -n 5

nginx -t che segnala syntax is ok e test is successful indica che il file è valido. curl dovrebbe visualizzare le prime righe dell’avviso. Se visualizza invece la pagina di benvenuto di nginx, il sito predefinito è ancora abilitato e il tuo blocco non viene utilizzato.

Avvialo e leggi il contenuto del log

sudo systemctl restart tor@default
sudo journalctl -u tor@default -n 50 --no-pager

Entro pochi minuti, nel log dovrebbe comparire la riga che indica che gli altri relay possono raggiungerti:

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

Se la riga non compare mai, la ORPort non è raggiungibile. Verifica che tor sia in ascolto con sudo ss -lntp | grep 443, quindi testa la porta da un altro computer con nc -vz your.address.here 443. La causa più comune è un firewall davanti al VPS, configurato da te oppure nel pannello di controllo del provider.

Verifica che il servizio torni disponibile dopo un riavvio con systemctl is-enabled tor, che dovrebbe stampare enabled.

Il relay compare in Ricerca relay circa tre ore dopo l'avvio, con il nickname scelto. Il traffico aumenta poi nell'arco di diversi giorni, perché il sistema di misurazione della larghezza di banda della rete deve osservare il relay prima di attribuirgli un peso significativo per i client. È normale che un nuovo relay di uscita gestisca pochissimo traffico il primo giorno.

Il playbook per gli abusi e il contenuto delle segnalazioni

Prepara il playbook prima della prima segnalazione, perché di solito arriva entro la prima settimana. La maggior parte di queste comunicazioni è generata automaticamente. Le linee guida di Tor indicano che le segnalazioni automatiche rappresentano circa l'80% del totale; una risposta standard risolve la maggior parte dei casi restanti.

Ecco cosa arriva concretamente. Una segnalazione di scansione o di attacco brute-force generata dal sistema di rilevamento delle intrusioni di qualcuno, con il tuo indirizzo e un timestamp. Una comunicazione relativa al copyright, se la tua policy consente l'uso di porte per il file sharing. Un reclamo per spam in un forum o nei commenti, inviato dal gestore del sito. In alcuni casi arriva una richiesta di conservazione dei dati o un mandato delle forze dell'ordine. Questa è una categoria diversa: in quel momento devi rivolgerti a un avvocato, non usare un modello di risposta.

La risposta è breve ed è quasi sempre la stessa:

Hello,

Thank you for the report. The address 203.0.113.10 is a Tor exit relay,
operated by <your name> at <your organisation>. The connection you saw was
made by a user of the Tor network. It did not originate on this machine.

This relay keeps no record of which user made which connection, so I cannot
identify the sender and there are no logs for me to hand over.

You can confirm that this address was a Tor exit at the date and time in
question here: https://metrics.torproject.org/exonerator.html

If you would prefer to stop Tor traffic reaching your service, the current
list of exit addresses is published here:
https://check.torproject.org/torbulkexitlist

I read this mailbox personally and will answer any follow-up.

<your name>

Quattro abitudini rendono efficace questa procedura. Rispondi entro un giorno lavorativo, dall'indirizzo indicato in ContactInfo, e firma con il tuo nome. Non offrire mai di identificare un utente, perché non puoi farlo; un operatore che lascia intendere il contrario dovrà smentire quella promessa in seguito. Conserva tutte le risposte in un'unica cartella, così una seconda comunicazione sullo stesso incidente riceve la stessa risposta. Se il provider inoltra un reclamo con un avviso di sospensione, rispondi prima al provider e poi al segnalante.

Due link sono sufficienti per la maggior parte di queste risposte. ExoneraTor risponde alla domanda che interessa realmente a chi svolge l'indagine: questo indirizzo era un'uscita Tor in quel preciso momento? La lista completa delle uscite è un semplice elenco degli indirizzi di uscita attuali, uno per riga, per chi ha deciso di bloccare Tor e preferisce farlo in modo accurato invece di procedere per supposizioni.

Banda, costi e il secondo relay

Gli exit relay generano traffico reale. Stabilite il limite mensile prima di ordinare il server e chiedete come fattura il provider il traffico oltre la soglia, perché quanto costa davvero un VPS dipende soprattutto dalla quantità di trasferimento inclusa, non dal prezzo esposto. Tor può applicare questo limite dal vostro lato:

AccountingMax 4 TBytes
AccountingStart month 1 00:00
RelayBandwidthRate 20 MBytes
RelayBandwidthBurst 25 MBytes

AccountingMax mette Tor in ibernazione dopo aver trasferito quel volume nel periodo di fatturazione e lo riattiva all'inizio del periodo successivo. Confrontate il primo mese con il contatore del provider prima di considerare attendibile il valore, perché i due sistemi non contano sempre gli stessi byte. RelayBandwidthRate limita la velocità sostenuta, mantenendo utilizzabile l'uplink e riducendo il rischio di contestazioni da parte del provider.

Quando aggiungete un secondo exit relay, collocatelo su una rete diversa, non nello stesso rack del primo. La diversità è una parte importante del contributo di un exit relay, e due macchine nello stesso luogo possono guastarsi contemporaneamente. Inseriteli nella stessa famiglia, pubblicate per entrambi lo stesso contatto verificato e rispondete alle email da entrambi. Un exit relay che nessuno riesce a contattare viene considerato un problema anonimo. Un exit relay il cui operatore risponde nello stesso giorno viene considerato un server gestito da una persona, come in effetti è.

FAQ

Posso eseguire un nodo di uscita Tor su un VPS che possiedo già?

No. In questo caso è necessario essere rigorosi. Un nodo di uscita richiede un indirizzo dedicato, che non ospiti nient'altro, presso un provider che abbia accettato in anticipo di trasportare traffico di uscita e di inoltrarti senza modifiche le segnalazioni di abuso. Su un VPS per uso generale, incluso il nostro, quell'indirizzo svolge già un'altra funzione e condivide la stessa rete con clienti che eseguono servizi ordinari. Sul server che possiedi puoi eseguire un relay non di uscita oppure un bridge obfs4. Sono servizi realmente utili, ricevono quasi nessuna segnalazione di abuso e richiedono soltanto il server per cui stai già pagando.

Quante segnalazioni di abuso riceve un relay di uscita Tor e chi le riceve?

Dipende dalla tua exit policy. Con ReducedExitPolicy 1, la porta 25 rifiutata e le porte per la condivisione di file escluse, la maggior parte dei messaggi ricevuti riguarda scansioni automatizzate e attacchi brute-force. Le linee guida per i nodi di uscita Tor indicano che le segnalazioni automatizzate rappresentano circa l'80% del totale. I messaggi vengono inviati all'indirizzo a cui l'ufficio abusi del provider li inoltra. Per questo, prima di ordinare il servizio, devi chiedere se il provider li inoltra a te mantenendo integro l'indirizzo del segnalante. Pubblica lo stesso indirizzo in ContactInfo e nella pagina informativa sulla porta 80, quindi rispondi entro un giorno lavorativo.

Devo pubblicare il mio vero nome e il mio indirizzo email?

Sì. ContactInfo viene pubblicato nella directory pubblica dei relay e chiunque può scaricarlo. Il nome DNS inverso indica la funzione della macchina e la pagina informativa sulla porta 80 lo ripete. Questa trasparenza è prevista dal progetto, non è un effetto collaterale. Un nodo di uscita senza un contatto funzionante viene trattato come una fonte anonima di problemi, e alcuni client escludono del tutto i nodi che non pubblicano alcun contatto. Aggiungi proof:uri-familyid-ed25519 e il file /.well-known/tor-relay/ed25519-family-id.txt a un dominio sotto il tuo controllo, così il contatto sarà verificabile e non soltanto dichiarato.

Perché il mio nuovo relay di uscita trasporta quasi niente traffico?

Controlla innanzitutto che journalctl -u tor@default contenga Self-testing indicates your ORPort is reachable from the outside. Excellent., perché un relay che non supera il test di raggiungibilità non viene mai pubblicato e non trasporta alcun traffico. Se la riga è presente, di solito è necessario attendere. Un relay compare in Relay Search circa tre ore dopo l'avvio, ma i client iniziano a inviargli traffico significativo solo dopo che la misurazione della larghezza di banda della rete lo ha rilevato; questo richiede diversi giorni. Prima che il relay venga considerato effettivamente un nodo di uscita, è inoltre necessaria una policy che consenta le porte 80 e 443.