Come configurare un bridge Tor obfs4 su un VPS

Che cos’è un bridge Tor e perché esiste

Un bridge Tor è un punto di accesso alla rete Tor il cui indirizzo non è pubblicato nell’elenco pubblico dei relay. Questo elenco, chiamato consenso, è un documento firmato che chiunque può scaricare, compreso un organismo di censura. Bloccare Tor usando questo elenco richiede poco tempo: si scarica il consenso e poi si bloccano tutti gli indirizzi che contiene al confine della rete. I bridge esistono perché l’elenco pubblico è il punto debole. Gli indirizzi dei bridge vengono distribuiti pochi alla volta, quindi nessuna singola richiesta restituisce l’intero insieme.

Un indirizzo non pubblicato risolve soltanto metà del problema. La deep packet inspection (DPI), che classifica il traffico in base al contenuto e non all’indirizzo, riconosce una connessione Tor dalla struttura dell’handshake TLS (transport layer security). Un organismo di censura che non dispone dell’elenco può comunque capire che «questo traffico sembra Tor» e bloccare la connessione. Un pluggable transport elimina questo segnale. Sul lato client incapsula il flusso Tor in un altro tipo di traffico, che il bridge rimuove all’arrivo.

obfs4 è il transport utilizzato dalla maggior parte dei bridge. Trasforma il flusso in byte privi di header e di handshake fisso, quindi la DPI non ha alcun modello da individuare. Inoltre autentica il client. Il valore cert= contenuto in una bridge line è una chiave di cui il client deve dimostrare di essere in possesso prima che il bridge risponda. Questo impedisce le active probing: un organismo di censura che si connette al tuo indirizzo per verificare se parla Tor non riceve alcuna risposta e non apprende nulla.

Quale trasporto collegabile dovresti usare?

• obfs4 richiede un VPS, 2 porte TCP e nessun nome di dominio. È la soluzione utile più semplice da eseguire e costituisce l'oggetto di questa guida.
• WebTunnel nasconde la connessione all'interno del normale traffico HTTPS diretto a un sito web reale. Il Tor Project indica come requisiti un indirizzo IPv4 statico, un dominio sotto il tuo controllo, un web server funzionante come NGINX o Apache, un certificato TLS valido e almeno 1 GB di RAM; 4 GB sono la quantità consigliata. È adatto alle reti in cui il traffico dall'aspetto casuale è di per sé sospetto, perché un Paese che consente poco oltre la navigazione web consente comunque HTTPS.
• Snowflake è un tipo di contributo diverso. I volontari eseguono proxy WebRTC di breve durata, quindi i punti di accesso cambiano continuamente e non esiste un indirizzo stabile che un censore possa bloccare. Non devi gestire un bridge per questo trasporto. Devi eseguire un proxy, che non richiede un indirizzo fisso.

Inizia con obfs4. In seguito puoi aggiungere un bridge WebTunnel su un secondo indirizzo: eseguire entrambi sullo stesso IP significa che il blocco di un singolo indirizzo rende inutilizzabili entrambi.

Quanto costa gestire un bridge?

[
  {
    "label": "Bridge, minimum",
    "min_upstream_mbit": 1
  },
  {
    "label": "Guard or middle relay, minimum",
    "min_upstream_mbit": 10
  },
  {
    "label": "Guard or middle relay, recommended",
    "min_upstream_mbit": 16
  }
]

Ad agosto 2026 il Tor Project richiede a un bridge almeno 1 Mbit/s di banda in upstream e downstream. Per un relay guard o middle sono richiesti 10 Mbit/s, con 16 Mbit/s consigliati. Si tratta di requisiti pubblicati, non di misurazioni. Un bridge nuovo resta di solito molto al di sotto del proprio minimo per alcune settimane. La stessa pagina dei requisiti richiede a un relay almeno 100 GByte di traffico in uscita al mese. I piani più piccoli coprono già questa quantità. Prima di dimensionare un piano più grande, leggi quanto costa davvero un piccolo VPS al mese.

La superficie di abuso è ridotta. È questo il punto che spesso viene frainteso. Un bridge è il primo hop. Il traffico che lascia il tuo server raggiunge un altro relay Tor, non il sito web scelto dall'utente. Il tuo indirizzo IP non compare mai nei log web di terzi come origine di una richiesta. Le segnalazioni che gli operatori dei relay exit devono gestire, quindi, non arrivano a questo server. Controlla comunque la policy di utilizzo accettabile del provider, perché alcuni host considerano qualsiasi servizio Tor un caso particolare. Un bridge e un onion service sono opposti sotto questo aspetto: un bridge è utile solo perché il suo indirizzo è raggiungibile e viene infine distribuito, mentre un onion service v3 sullo stesso tipo di VPS è utile solo finché il tuo IP pubblico resta nascosto.

Non convertire un relay pubblico esistente in un bridge mantenendo lo stesso indirizzo. Per questo caso il Tor Project consiglia di cambiare "IP address, name and fingerprint", perché il vecchio indirizzo è già incluso nel consensus scaricato dai censori. Un bridge che la settimana scorsa era un relay pubblico è già presente in una blocklist.

La disponibilità conta più della velocità. I requisiti per i relay indicano che "if your relay is not running for more than 2 hours a day its usefulness is limited". In questo aspetto un bridge è in una situazione peggiore rispetto a un relay, perché ogni client dispone di un solo indirizzo e non ha un fallback. Un riavvio disconnette tutti gli utenti che lo utilizzano. Configura un controllo della porta TCP in Uptime Kuma sulla porta obfs4, così saprai il giorno in cui smette di rispondere.

Installare Tor dal repository del Tor Project

I pacchetti della distribuzione sono spesso meno aggiornati, mentre un bridge è un componente di sicurezza che deve rimanere aggiornato. Aggiungere prima il repository ufficiale del progetto.

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

Ora creare il file delle sorgenti. La riga Suites: deve contenere il codename della release in uso. Leggerlo dal sistema invece di inserirlo manualmente.

sudo tee /etc/apt/sources.list.d/tor.sources >/dev/null <<EOF
Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: $(lsb_release -cs)
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 obfs4proxy

Se apt update segnala che il repository non dispone di un file Release per il codename in uso, il Tor Project non supporta quella release. Eliminare /etc/apt/sources.list.d/tor.sources, eseguire nuovamente sudo apt update e installare il pacchetto tor fornito dalla distribuzione. Tutto il resto della procedura rimane invariato.

Il pacchetto obfs4proxy è fornito direttamente da Debian e Ubuntu (versione 0.0.14 in Debian 13, ad agosto 2026). Verificare dove è stato installato il binario, perché il relativo percorso deve essere inserito nella configurazione:

command -v obfs4proxy || command -v lyrebird

Il progetto upstream è stato rinominato in lyrebird, quindi un pacchetto più recente potrebbe installare invece /usr/bin/lyrebird. Usare il percorso restituito da quel comando.

Configura il bridge in /etc/tor/torrc

BridgeRelay 1
ORPort 8443
ServerTransportPlugin obfs4 exec /usr/bin/obfs4proxy
ServerTransportListenAddr obfs4 0.0.0.0:9443
ExtORPort auto
ContactInfo you@example.com
Nickname PickANickname
BridgeDistribution any

Ogni riga ha un possibile punto di errore associato. Verificale quindi una alla volta.

BridgeRelay 1 indica a tor di inviare il proprio descrittore all'autorità dei bridge invece che al consenso pubblico. Questa è la riga che rende il relay non elencato.

ORPort è la porta Tor effettiva. Deve essere raggiungibile da Internet, perché tor la verifica e rifiuta di pubblicare un descrittore finché il test non viene superato.

ServerTransportPlugin specifica il comando da eseguire. tor avvia obfs4proxy come processo figlio e comunica con esso tramite una pipe. Per questo obfs4proxy non ha una propria unità di servizio e non compare mai in systemctl status.

ServerTransportListenAddr imposta la porta sulla quale obfs4proxy resta in ascolto. Se ometti questa riga, obfs4proxy sceglie una porta libera all'avvio e, dopo la maggior parte dei riavvii, ne sceglie una diversa. Di conseguenza, ogni riga del bridge che hai già distribuito punta a una porta senza alcun processo in ascolto. I client ricevono una connessione rifiutata e interrompono i tentativi.

ExtORPort auto apre la ORPort estesa, un canale di loopback che obfs4proxy usa per restituire a tor le connessioni completate insieme all'indirizzo del client. La guida alla configurazione del Tor Project la include in ogni bridge, perché senza di essa il trasporto non può comunicare quell'indirizzo a tor.

ContactInfo e Nickname sono entrambi pubblici. Usa un indirizzo che controlli, perché il Tor Project lo utilizza per contattarti in caso di problemi con il bridge. Scegli un nickname che non permetta di identificarti se preferisci non attirare attenzione.

BridgeDistribution seleziona il distributore che fornisce il tuo indirizzo agli utenti. I valori accettati sono https, email, telegram, settings, none e any. Usa any per il primo bridge e lascia che sia il sistema a decidere. Usa none per un bridge privato che distribuisci personalmente, mantenendo così l'indirizzo completamente fuori dalla distribuzione pubblica.

Perché la scelta delle porte è importante

Evita di usare 9001 per entrambe le porte. Il Tor Project lo indica esplicitamente, perché 9001 è l'ORPort tradizionale e i censori eseguono scansioni su Internet per individuarla. Le due porte devono inoltre essere diverse, perché tor e obfs4proxy aprono ciascuno il proprio listener.

La porta obfs4 più efficace è 443. Le connessioni in uscita verso 443 sono consentite su quasi tutte le reti soggette a restrizioni e una connessione persistente verso questa porta appare come una normale sessione web. L'associazione a una porta inferiore a 1024 richiede un passaggio aggiuntivo, perché obfs4proxy non viene eseguito come root:

sudo setcap cap_net_bind_service=+ep /usr/bin/obfs4proxy
sudo systemctl edit tor@.service tor@default.service

Aggiungi queste due righe in ogni editor che viene aperto:

[Service]
NoNewPrivileges=no

La capability, da sola, non è sufficiente. NoNewPrivileges di systemd impedisce a un processo di ottenere privilegi che il processo padre non aveva e una capability del file produce esattamente questo effetto. Di conseguenza, obfs4proxy non riesce ad associarsi alla porta 443 finché questa impostazione resta attiva.

Se preferisci saltare questo passaggio, scegli una porta alta non appariscente e annotala. Qualunque porta tu scelga, non modificare in seguito la porta obfs4. Una riga del bridge associa indirizzo, porta, fingerprint e certificato. Ogni copia già presente nel browser di un utente smette quindi di funzionare non appena la porta cambia.

Apri le porte su entrambi i firewall

sudo ufw allow 8443/tcp
sudo ufw allow 9443/tcp
sudo ufw status

Entrambe le porte devono essere aperte. La maggior parte dei provider gestisce anche un secondo firewall nel pannello di controllo, che ufw non conosce. Una regola presente sul server ma non nel pannello crea un bridge non raggiungibile e che non pubblica mai alcun descriptor. Se uno dei due aspetti è nuovo per te, consulta le regole ufw necessarie su un VPS appena installato e che cosa significa realmente una porta in ascolto su Linux. Già che ci sei, proteggi SSH con chiavi e una configurazione sshd più sicura. Un bridge non elencato su un server con accesso SSH tramite password resta comunque un server con accesso SSH tramite password.

Avviarlo, quindi leggere il log

sudo systemctl enable --now tor.service
sudo systemctl restart tor.service
sudo journalctl -e -u tor@default

Debian e Ubuntu forniscono due unità. tor.service è un wrapper minimale, mentre tor@default.service è il processo che esegue il lavoro. Per questo journalctl -u tor appare quasi vuoto, mentre il log da consultare si trova in tor@default.

Due righe confermano che il servizio ha funzionato:

Self-testing indicates your ORPort is reachable from the outside. Excellent. Publishing server descriptor.
Registered server transport 'obfs4' at '0.0.0.0:9443'

La prima indica che il test di raggiungibilità è riuscito e che il descriptor è stato inviato all'autorità bridge. Se non compare, qualcosa tra Internet e il server sta bloccando il traffico verso la ORPort. La seconda riga deve mostrare la porta configurata. Se indica una porta diversa, tor non ha applicato ServerTransportListenAddr. La causa più comune è un nome di trasporto non corrispondente: deve essere obfs4 in entrambe le direttive.

Verificare che i due listener siano presenti:

sudo ss -lntp | grep -E 'tor|obfs4|lyrebird'

Dov'è la mia riga bridge?

obfs4proxy scrive un modello nella directory dati di tor:

sudo cat /var/lib/tor/pt_state/obfs4_bridgeline.txt

La directory appartiene all'utente tor e ha modalità 700, quindi senza sudo si ottiene Permission denied. Il file contiene una riga con questa struttura:

Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=<CERTIFICATE> iat-mode=0

Sostituisci <IP ADDRESS> con l'indirizzo pubblico del server, <PORT> con la porta obfs4 e non con la ORPort, e <FINGERPRINT> con l'impronta digitale dell'identità che tor ha scritto nella propria directory dati:

sudo cat /var/lib/tor/fingerprint
sudo cat /var/lib/tor/hashed-fingerprint

Il primo file contiene il nickname e l'impronta digitale dell'identità da inserire in una riga bridge. Il secondo contiene l'impronta digitale sottoposta a hashing, che puoi incollare in Ricerca relay per verificare se il bridge è in esecuzione e stimare quanti client lo raggiungono. I due valori non sono intercambiabili. Una riga bridge che contiene il valore sottoposto a hashing non corrisponde alla chiave dell'identità presentata dal bridge, quindi il client rifiuta la connessione appena aperta.

Come raggiunge effettivamente gli utenti un bridge?

Non si consegna la riga del bridge a chiunque. Quando il descriptor raggiunge la bridge authority, il sistema di distribuzione (rdsys, il successore di BridgeDB) assegna il bridge a un distributore e gli utenti chiedono i bridge a quel distributore. Ad agosto 2026 i canali sono questi:

• Il modulo web all'indirizzo bridges.torproject.org/options, che restituisce le righe dei bridge dopo un captcha.
• Un'email a bridges@torproject.org inviata da un indirizzo Gmail o Riseup, alla quale viene risposto con le righe dei bridge. La restrizione sui provider esiste perché account gratuiti illimitati permetterebbero a un censore di enumerare ogni bridge.
• Il bot Telegram @GetBridgesBot. Inviare /start, quindi /obfs4 o /webtunnel.
• Tor Browser stesso, in Settings e poi Connection, dove "Request bridges" li recupera tramite il canale moat.

Un nuovo bridge compare in Relay Search circa tre ore dopo la configurazione. Gli utenti richiedono molto più tempo: secondo la formulazione del Tor Project, "Possono essere necessari diversi giorni o settimane prima di visualizzare un insieme stabile di utenti." Un primo periodo di due settimane con poca attività è normale e non indica un problema.

L'impostazione di BridgeDistribution none disattiva tutti questi canali. La riga del bridge resta quindi a disposizione per essere inviata alle persone che ne hanno bisogno, tramite un canale che il censore non sta monitorando.

Quando qualcosa non funziona

Nel log non compare la riga di autotest. ORPort non è raggiungibile. Eseguire il test da un'altra macchina con nc -vz your.ip 8443. Se il comando resta in attesa, i pacchetti vengono probabilmente filtrati: controllare ufw e il pannello del provider. Un rifiuto indica che tor non è in ascolto: controllare ss -lntp e cercare nel log un errore di configurazione.

Il transport registrato mostra una porta diversa da quella scelta. tor ha ignorato ServerTransportListenAddr. Il nome del transport deve corrispondere esattamente a quello in ServerTransportPlugin, ed entrambi devono essere obfs4.

obfs4proxy non riesce ad associarsi alla porta 443. Verificare la capability con getcap /usr/bin/obfs4proxy, quindi verificare che l'override sia stato applicato all'unità con systemctl show tor@default -p NoNewPrivileges. Se il comando stampa NoNewPrivileges=yes, il drop-in è stato applicato a un'unità che non è in esecuzione.

/var/lib/tor/pt_state/ è vuota. tor non ha avviato il transport, quindi il percorso in ServerTransportPlugin è errato. Confrontarlo con l'output di command -v obfs4proxy.

I client hanno smesso di connettersi dopo una modifica. Qualsiasi modifica all'indirizzo o alla porta obfs4 invalida tutte le bridge line già distribuite. Verificare anche se l'IP pubblico del server è cambiato, come può accadere durante una ricostruzione con alcuni provider.

tor non si avvia. Eseguire sudo -u debian-tor tor --verify-config -f /etc/tor/torrc. Il comando analizza il file, stampa la riga che causa il problema e lascia invariato il servizio in esecuzione.

FAQ

Il mio provider VPS si lamenterà per la presenza di un bridge Tor?

Un bridge è un punto di ingresso, quindi il traffico in uscita dal server passa verso altri relay Tor e non raggiunge mai il sito scelto dall'utente. Il tuo indirizzo IP non compare nei log web di nessuno come origine di una richiesta. Sono queste richieste a generare le segnalazioni che devono gestire gli operatori dei relay di uscita. Le regole di hosting variano comunque. Alcuni provider considerano qualsiasi servizio Tor un caso particolare. Leggi quindi la policy di utilizzo accettabile prima di iniziare e inserisci in ContactInfo un indirizzo che controlli.

Quanta larghezza di banda usa un bridge Tor?

Il minimo pubblicato è di 1 Mbit/s in upload e download, rispetto ai 10 Mbit/s richiesti per un relay guard o middle. L'utilizzo effettivo parte da un valore prossimo a zero, perché il bridge trasporta traffico soltanto per gli utenti che un distributore gli assegna. Se vuoi impostare un limite massimo rigido, configura RelayBandwidthRate e RelayBandwidthBurst in torrc.

Perché nessuno si è connesso al mio nuovo bridge?

Un bridge impiega circa tre ore per comparire in Relay Search. Secondo le indicazioni del Tor Project, per raggiungere un numero stabile di utenti possono servire diversi giorni o settimane. Verifica che il descriptor sia stato pubblicato. È la riga di self-test in journalctl -u tor@default. Cerca l'impronta hashata in Relay Search e conferma che BridgeDistribution non sia impostato su none.

Devo usare obfs4 o WebTunnel?

Usa obfs4 se questo è il tuo primo bridge: un VPS, due porte, nessun dominio e nessun certificato. Usa WebTunnel quando il traffico dall'aspetto casuale viene bloccato, perché richiede un dominio sotto il tuo controllo, un server web reale, un certificato TLS valido e almeno 1 GB di RAM. Se usi entrambi, assegnali a indirizzi separati. In caso contrario, il blocco di un solo IP rimuoverebbe contemporaneamente due bridge.

Cosa succede se in seguito cambio la porta obfs4?

Ogni riga del bridge già distribuita smette di funzionare. Una riga del bridge associa indirizzo, porta, impronta e certificato. Un client che conserva la riga precedente tenta quindi di connettersi a una porta sulla quale non è in ascolto nulla e interrompe il tentativo. Lo stesso vale quando cambia l'IP pubblico del server. Scegli la porta durante la configurazione e non modificarla in seguito.