Pianifica e mantieni un relay Tor su un VPS
Scegli un relay non-exit o un bridge, pianifica la larghezza di banda, installa i pacchetti Tor mantenuti e gestisci il nodo in modo responsabile.
In breve
Eseguire un relay Tor richiede un provider adeguato, capacità di trasferimento sufficiente, porte corrette e manutenzione regolare. Un relay intermedio o un bridge differisce da un nodo di uscita nel ruolo di rete e nelle responsabilità. Usa i controlli di configurazione del Tor Project e monitora l'uso delle risorse dopo il deployment.
Scegli il ruolo prima di noleggiare le risorse
Un relay pubblico non-exit trasmette traffico cifrato tra nodi Tor invece di effettuare la connessione finale dell'utente a un servizio internet. Può in seguito ricevere lo stato di guard mentre la rete lo valuta. Un bridge fornisce un punto di ingresso che non è elencato come un normale relay pubblico, aiutando gli utenti le cui reti bloccano indirizzi Tor noti.
Un relay exit effettua la connessione in uscita finale e quindi espone il proprio IP alle destinazioni. Ciò comporta requisiti operativi e di gestione degli abusi diversi. Per un primo nodo, un relay non-exit o un bridge è di solito la scelta più gestibile. Conferma che il provider consenta il ruolo preciso prima di distribuirlo.
Prevedi un budget per continuità e traffico
Un relay trae vantaggio da un indirizzo stabile, un uptime affidabile e una capacità sostenuta in entrambe le direzioni. Risorse VPS contenute possono supportare un relay iniziale, ma il throughput dipende dalle prestazioni di cifratura, dal comportamento condiviso del CPU e dai limiti di rete. I requisiti di RAM aumentano con il numero di connessioni; monitora l'uso reale invece di considerare l'istanza più piccola adatta a tutto.
Il trasferimento mensile conta quanto la velocità della porta. Una velocità elevata mantenuta costantemente può esaurire rapidamente un piano a consumo, soprattutto dove contano sia il traffico in entrata che in uscita. Allinea la regolazione e la contabilizzazione della larghezza di banda all'effettivo limite consentito e lascia un margine per la manutenzione del sistema.
Installa software mantenuto su un sistema irrobustito
Parti da un sistema operativo aggiornato, accesso amministrativo basato su chiavi e un firewall che consenta la porta relay selezionata. Usa le istruzioni di installazione correnti del progetto Tor per la tua distribuzione e la fonte di pacchetti supportata. Le chiavi dei repository, i nomi dei pacchetti e le unità di servizio devono provenire da quelle istruzioni anziché da un vecchio installer copiato.
Su molti sistemi Linux la configurazione è /etc/tor/torrc. Imposta un nickname distintivo e un indirizzo di contatto del progetto monitorato, poi configura esplicitamente il ruolo relay. Mantieni il percorso di gestione separato dal listener pubblico del relay.
Usa una configurazione non-exit esplicita
Quanto segue è uno schema illustrativo non-exit, non uno script di configurazione completo. Sostituisci il contatto con un indirizzo che monitori e seleziona valori di rate adatti all'abbonamento. L'indirizzo .invalid mostrato è un placeholder e non può ricevere messaggi dell'operatore.
Convalida la configurazione e rivedi la diagnostica di avvio. Conferma che la porta relay sia raggiungibile e che il nodo compaia infine nella directory pubblica. Un nuovo relay può inizialmente trasportare poco traffico mentre la sua capacità e affidabilità vengono valutate; evita di cambiare ripetutamente la sua identità solo per forzare l'attività.
Nickname SilentNode
ORPort 9001
ContactInfo [email protected]
RelayBandwidthRate 1 MBytes
RelayBandwidthBurst 2 MBytes
ExitRelay 0
SocksPort 0Un bridge necessita di un trasporto e di una distribuzione accurata
Un bridge obfs4 maschera il suo schema di traffico per aiutare gli utenti a bypassare il filtraggio. Segui la guida attuale per il bridge specifica della distribuzione per il suo pacchetto di trasporto collegabile; il progetto di implementazione obfs4 ora si chiama lyrebird. Configura il listener del trasporto, verifica la raggiungibilità e ottieni le informazioni di connessione del bridge.
Non pubblicare indiscriminatamente una linea bridge privata. Usa il meccanismo di distribuzione documentato o condividila con gli utenti previsti. Convertire un relay noto pubblicamente in un bridge senza cambiare i dettagli identificativi può rendere il bridge più facile da scoprire e bloccare.
Dichiara la proprietà comune e mantieni il contatto
Se gestisci diversi relay, divulga il loro controllo condiviso tramite l'attuale meccanismo di famiglia Tor così che i client possano evitare di selezionare i tuoi nodi in più posizioni del circuito. Le linee guida attuali usano FamilyID; i vecchi esempi MyFamily non dovrebbero essere considerati istruzioni di configurazione attuali.
Un indirizzo ContactInfo monitorato consente ad altri operatori di segnalare problemi senza necessitare della tua identità civile. Mantieni aggiornati gli aggiornamenti di sicurezza, ma comprendi come i riavvii dei servizi e i cambiamenti dei pacchetti influenzino il nodo. Usa le impostazioni di banda e accounting in modo deliberato anziché permettere a un relay di consumare inaspettatamente l'intero piano.
- Controlla la configurazione di famiglia attuale per l'operazione multi-relay.
- Monitora la casella di posta di contatto dedicata.
- Rivedi gli aggiornamenti e la raggiungibilità dopo un riavvio.
- Mantieni i dettagli di monitoraggio privati adeguatamente limitati.
- Scegli un accounting di trasferimento che corrisponda alla fatturazione del provider.
Tratta le exit come una decisione di deployment separata
Il traffico exit può generare reclami e inserimento in blocklist lato destinazione. Prima di abilitare una exit, stabilisci un permesso esplicito del provider, un processo di abuso monitorato, un'infrastruttura dedicata adeguata e una comprensione informata degli obblighi applicabili. Non trasformare un nodo esistente in modalità exit solo per aumentarne l'utilità.
Un relay non di uscita o un bridge contribuisce già con capacità utile. La sua minore esposizione a reclami sulla destinazione non elimina la necessità di manutenzione o autorizzazione. Il sito web pubblico SilentVPS non può sostituire una politica operativa confermata quando l'infrastruttura di produzione diventerà disponibile.
Preserva un relay sano nel tempo
Controlla lo stato della directory, il throughput, la sincronizzazione dell'orologio, la memoria e il listener scelto dopo le modifiche. Un sistema di monitoraggio privato aiuta a rilevare interruzioni senza pubblicare schemi di traffico sensibili e granulari. Conserva i backup della configurazione e delle chiavi di identità in un luogo sicuro.
Se esegui la migrazione, preserva il materiale di identità appropriato così che il nodo non debba ricostruire tutta la sua storia; verifica la guida di migrazione attuale prima di copiare i file. Non eseguire mai istanze duplicate non intenzionali della stessa identità. Una capacità stabile e ben mantenuta avvantaggia la rete più di frequenti sperimentazioni su un nodo live.