Dodici build

Far funzionare un relay Tor che resta all'interno della politica di utilizzo accettabile

Un relay non di uscita con IPv6, contabilizzazione della banda, un'unità systemd indurita e una verifica che conferma che la tua impronta sia arrivata al consenso.

Cosa si ottiene

Un relay intermedio: accetta connessioni da client e altri relay, inoltra il traffico all'interno della rete e non apre mai una connessione verso una destinazione su Internet ordinario. Nessuno riceve una segnalazione di abuso per un relay intermedio, perché dall'esterno scambia traffico cifrato con una lista pubblicata di altri relay e nient'altro.

Questa distinzione è l'intero motivo per cui esiste questa guida. I relay di uscita sono un'altra conversazione: le segnalazioni su di essi arrivano al nostro desk abusi, non al tuo, quindi leggi la politica di utilizzo accettabile e apri un ticket prima di configurarne uno. Tutto ciò che segue disattiva deliberatamente l'uscita, due volte.

Prima di iniziare

  • Un R-4. Tor è single-threaded per connessione e limitato dalla rete; quattro core dedicati satureranno un collegamento molto prima che la CPU se ne accorga.
  • Un sito con banda che sei disposto a donare. BUH-01 e HEL-01 sono i terabyte più economici che vendiamo, ed entrambi hanno il transito per sostenerlo.
  • Un orologio funzionante. I relay con tempo skewato vengono esclusi dal consenso, e questa è la causa più comune di un relay che si avvia perfettamente e non appare mai da nessuna parte.

1. Sistema di base

apt update && apt full-upgrade -y
apt install -y tor nyx chrony nftables
timedatectl set-timezone UTC
chronyc tracking

chronyc tracking dovrebbe riportare un offset di tempo di sistema nell'ordine dei microsecondi. Se riporta secondi, fermati e correggi prima quello; nulla a valle funzionerà.

2. La configurazione del relay

Sostituisci /etc/tor/torrc con quanto segue. Leggi ogni riga, perché due di esse sono quelle che ti tengono dentro la politica:

Nickname exampleRelay
ContactInfo [email protected]

ORPort 9001
ORPort [2001:db8:1a2b::2]:9001
SocksPort 0
ControlPort 0

ExitRelay 0
ExitPolicy reject *:*
IPv6Exit 0

RelayBandwidthRate 40 MBytes
RelayBandwidthBurst 60 MBytes
AccountingMax 40 TBytes
AccountingStart month 1 00:00

MetricsPort 127.0.0.1:9035
MetricsPortPolicy accept 127.0.0.1

User debian-tor
DataDirectory /var/lib/tor
Log notice syslog

ExitRelay 0 e ExitPolicy reject *:* sono cintura e bretelle. Ognuna basterebbe da sola; insieme significano che nessun default futuro di pacchetto, e nessuna modifica ricordata a metà notte, ti trasforma silenziosamente in un'uscita.

Sostituisci l'indirizzo IPv6 reale della tua istanza nella seconda riga ORPort. Ogni istanza viene fornita con un /64 instradato, quindi non c'è motivo di eseguire un relay solo v4, e i relay con capacità v6 sono ancora in offerta più scarsa di quelli v4.

La contabilità della banda merita un pensiero, non un copia-incolla. Il traffico sulla nostra rete è senza contatore sotto uso equo, ma un relay senza limite userà esattamente quanto la rete può trovargli, per sempre. Quaranta megabyte al secondo con un tetto mensile di quaranta terabyte è un relay generoso e ben educato. Quando la contabilità viene raggiunta, il relay va in letargo fino al rollover del periodo, invece di essere interrotto a metà circuito.

Se esegui più di un relay ovunque, aggiungi una riga MyFamily che elenca ogni impronta inclusa questa, separata da virgole. I client la usano per evitare di costruire un circuito che passa attraverso due macchine sotto lo stesso controllo, e ometterla è la lamentela di configurazione più comune rivolta agli operatori.

3. Indurimento dell'unità

L'unità impacchettata è decente; queste righe la rendono considerevolmente meno interessante per chi trova un bug in essa.

systemctl edit tor@default
[Service]
NoNewPrivileges=yes
PrivateTmp=yes
PrivateDevices=yes
ProtectSystem=strict
ProtectHome=yes
ProtectKernelTunables=yes
ProtectKernelModules=yes
ProtectControlGroups=yes
RestrictAddressFamilies=AF_INET AF_INET6 AF_UNIX
RestrictNamespaces=yes
MemoryDenyWriteExecute=yes
ReadWritePaths=/var/lib/tor /var/log/tor /run/tor
LimitNOFILE=65535

Il limite dei descrittori di file conta più di quanto sembri. Un relay occupato tiene migliaia di socket simultanei, e il limite predefinito produce un relay che funziona per una settimana e poi inizia a rifiutare connessioni senza nulla di ovvio nel log.

4. Firewall

flush ruleset

table inet filter {
  chain input {
    type filter hook input priority filter; policy drop;
    ct state established,related accept
    ct state invalid drop
    iif lo accept
    ip protocol icmp accept
    ip6 nexthdr icmpv6 accept
    tcp dport 22 accept
    tcp dport 9001 accept
  }
  chain forward {
    type filter hook forward priority filter; policy drop;
  }
}
systemctl enable --now nftables
systemctl restart tor@default

Nota che la porta delle metriche è vincolata all'indirizzo di loopback e quindi non necessita di alcuna regola. Raggiungila tramite un tunnel SSH quando la vuoi, e non esporla mai; le metriche del relay interessano più persone di quante pensi.

Verifica

Questa è la parte che richiede ore invece che minuti, quindi avvialo e vai via.

Innanzitutto, entro circa venti minuti dall'avvio, il log dovrebbe dire che il relay ha testato la propria porta dall'esterno e ha superato:

journalctl -u tor@default --since "20 min ago" | grep -i "self-testing"

Vuoi la riga che dice che la tua ORPort è raggiungibile dall'esterno. Se non appare mai, il firewall sta bloccando la 9001 in ingresso o il tuo indirizzo v6 nel torrc non corrisponde all'istanza.

In secondo luogo, prendi la tua impronta e conservala:

cat /var/lib/tor/fingerprint

In terzo luogo, conferma che il relay sta facendo lavoro piuttosto che semplicemente funzionando:

nyx
curl -s http://127.0.0.1:9035/metrics | grep -E "tor_relay_traffic|tor_relay_connections"

I contatori di traffico dovrebbero salire entro un'ora dal superamento dell'autotest. Le autorità di directory impiegano circa tre ore per votare la tua impronta nel consenso, e i client iniziano a inviare volume significativo solo dopo. Il flag Guard arriva intorno all'ottavo giorno se il tuo uptime regge, ed è allora che il grafico del traffico passa da un rivolo al limite che hai impostato.

In quarto luogo, e soprattutto per questa particolare costruzione, prova che non stai uscendo. Da una seconda macchina, verifica che nulla esca tranne il traffico del relay:

ss -tn state established | wc -l
ss -tn state established sport = :9001 | wc -l

Quasi ogni connessione stabilita dovrebbe coinvolgere la ORPort. Un gran numero di connessioni in uscita verso porte arbitrarie significherebbe una politica di uscita che non intendevi, a quel punto ferma il demone e rileggi il passo due.

Operarlo

CosaRisposta
RiavvioCosta alcune ore di reputazione. Raggruppa le tue modifiche.
Aggiornamentiapt upgrade poi riavvia. I relay con versioni vecchie vengono segnalati e infine eliminati.
Trasferimento di sitoCopia /var/lib/tor/keys e l'impronta segue il relay. Il peso del consenso non si resetta.
SegnalazioniUn relay intermedio non ne genera alcuna. Se ne ricevi una, qualcosa sta uscendo e dovresti controllare.
SpegnimentoImposta AccountingMax a un valore piccolo prima, così i circuiti si svuotano, o semplicemente fermalo e accetta la perdita di reputazione.

Esegui il backup di /var/lib/tor/keys da qualche parte fuori dall'istanza il giorno in cui lo costruisci. La chiave di identità è ciò che rende questo relay quello specifico relay; perderla e ricominci da zero con peso di consenso, che significa otto giorni in cui nessuno ti usa. La nostra posizione su cosa registriamo mentre il tuo relay è in esecuzione è sulla pagina di logging, ed è breve.

Pronto quando lo sei

Scegli una città. Scegli una dimensione. Paga in criptovaluta.

Nessun modulo su chi sei, nessuna attesa per l'approvazione di una persona, nessuna chiamata per verificare nulla. La fattura viene saldata e le credenziali arrivano nella tua casella di posta.