Tor-Relay auf einem VPS einrichten

Was ein Tor-Relay auf einem VPS macht

Ein Tor-Relay ist ein Tor-Daemon auf einem Rechner mit öffentlicher IP-Adresse, der verschlüsselten Datenverkehr für andere Personen weiterleitet. Die Directory Authorities veröffentlichen es, und Tor-Clients bauen Verbindungen darüber auf. Ein Guard- oder Middle-Relay übergibt den Datenverkehr ausschließlich an ein anderes Relay. Es baut daher niemals im Namen einer fremden Person eine Verbindung zu einer Website auf. Genau deshalb erhält es keine Abuse-Meldungen. Außerdem eignet es sich für einen gewöhnlichen VPS. Ein Relay transportiert den Datenverkehr anderer Personen und veröffentlicht keine eigenen Inhalte. Wenn Sie stattdessen Ihre eigene Website in das Netzwerk bringen möchten, anstatt Datenpakete dafür weiterzuleiten, ist der Betrieb eines v3-Onion-Service hinter nginx eine andere Aufgabe für denselben tor-Daemon. Der Betrieb eines Relays schützt außerdem nicht die Privatsphäre Ihres eigenen Browsings. Das ist ein separates Problem, dessen Möglichkeiten geringer sind, als viele erwarten: was das Self-Hosting von SearXNG tatsächlich verbirgt zeigt recht zuverlässig, wie viel das Verschieben eines Dienstes auf den eigenen VPS bewirkt.

Der Aufwand ist gering: ein Paket, fünfzehn Konfigurationszeilen, eine Firewall-Regel und ein Neustart. Der restliche Teil dieses Leitfadens behandelt die Punkte, an denen es problematisch wird. Dazu gehören die Bandbreitenberechnung bei einem volumenbasierten Tarif und der Grund, warum ein vollkommen gesundes neues Relay eine Woche lang nicht erreichbar zu sein scheint.

Guard, Middle, Bridge oder Exit: Entscheiden Sie sich vor der Installation

Ein Daemon übernimmt alle vier Rollen. Ihre Konfiguration und die Directory Authorities bestimmen, welche Rolle Sie erhalten.

• Middle Relay. Es empfängt Datenverkehr von einem Guard und leitet ihn an ein weiteres Relay weiter. Es kontaktiert niemals eine Zielsite. Jedes neue Relay beginnt mit dieser Rolle.
• Guard Relay. Es verwendet dieselbe Konfiguration mit einem zusätzlichen Flag. Die Directory Authorities vergeben das Guard-Flag an Relays, die lange genug schnell und stabil waren. Sie wählen diese Rolle nicht selbst. Sie verdienen sie sich, und die folgende Konfiguration schafft dafür die Voraussetzungen.
• Bridge. Ein Relay, das absichtlich aus dem öffentlichen Directory herausgehalten und privat an Benutzer in Regionen verteilt wird, in denen Tor blockiert ist. Von den vier Rollen erfordert diese die geringste Bindung: geringe Bandbreite, kein öffentlicher Eintrag und der richtige erste Schritt, wenn Ihr Vorhaben klein ist. Zusätzlich muss ein obfs4-Proxy neben dem Daemon ausgeführt werden, und es sind andere torrc-Zeilen erforderlich. Einrichten einer obfs4-Bridge auf einem günstigen VPS beschreibt die Vorgehensweise einschließlich der Weitergabe der Bridge-Zeile an die Benutzer am Ende.
• Exit Relay. Der letzte Hop. Es öffnet die Verbindung zur Zielsite. Jede von einem Benutzer gestellte Anfrage verlässt das Netzwerk über Ihre IP-Adresse. Daher gehen Abuse-Meldungen und polizeiliche Anfragen an den Inhaber dieser Adresse.

Ein Exit ist die einzige Rolle, die nicht auf einen allgemeinen VPS gehört. Betreiben Sie einen Exit nur bei einem Anbieter, der dem Empfang dieser Nachrichten im Voraus zugestimmt hat, eine eigene IP-Adresse bereitstellt und einen veröffentlichten Abuse-Kontakt besitzt. Die üblichen Hosting-Bedingungen verbieten dies. Bei einer Missachtung wird der Server normalerweise gesperrt und die IP-Adresse entzogen. Wenn Sie diese Aufgabe trotzdem übernehmen möchten, beschreibt Was der Betrieb eines Exit Relays tatsächlich bedeutet, wie Sie einen exit-freundlichen Host finden, die Exit-Policy und den Reverse DNS einrichten und eingehende Nachrichten beantworten. Ein Guard oder Middle Relay transportiert denselben Benutzerverkehr, ohne Sie diesen Risiken auszusetzen.

Alles Folgende richtet ein Guard/Middle Relay ein. ExitRelay 0 ist die Zeile, die es bei dieser Rolle belässt.

Was der VPS vor dem Start benötigt

Das Tor Project veröffentlicht verbindliche Anforderungen für Relays. Im Oktober 2026 sind dies: eine öffentliche IPv4-Adresse für das Relay, mindestens 10 Mbit/s Bandbreite in beide Richtungen, wobei 16 Mbit/s empfohlen werden, mindestens 100 GB ausgehender Datenverkehr pro Monat sowie 512 MB RAM bei weniger als 40 Mbit/s oder 1 GB darüber. Es gibt keine feste Vorgabe zur Betriebszeit. Ein Relay, das weniger als zwei Stunden pro Tag läuft, ist für das Netzwerk jedoch nur von geringem Nutzen.

Der Wert von 10 Mbit/s beschreibt die Leitung, nicht die Konfiguration. Sie benötigen einen Port, der diese Geschwindigkeit unterstützt. Wie viel dieser Bandbreite Sie dem Relay erlauben, ist eine separate Entscheidung und hängt vom monatlichen Transferlimit ab. Lesen Sie Ihren Tarif, bevor Sie die Konfiguration ändern. Wenn Sie noch einen Server auswählen, erklärt was ein VPS pro Monat tatsächlich kostet, wie Transferlimits angeboten werden. Die tatsächliche Netzwerkbandbreite eines VPS messen zeigt, wie Sie mit iperf3 die Leistung der Leitung ermitteln, statt sich auf die Angaben der Verkaufsseite zu verlassen.

Härten Sie das System zuerst ab. Ein Relay ist ein öffentlicher Dienst auf einer öffentlichen Adresse. Diese Adresse wird innerhalb weniger Minuten nach ihrer Veröffentlichung gescannt. SSH auf Schlüssel und eine gehärtete sshd-Konfiguration beschränken dauert zehn Minuten und sollte erfolgen, bevor das Relay in Betrieb geht, nicht danach.

Tor aus dem Repository des Tor Project installieren

Verwenden Sie das eigene apt-Repository des Tor Project und nicht das Paket der Distribution. Der Relay-Code entwickelt sich schneller als ein Stable-Release. Deshalb erreichen Fehlerbehebungen zuerst dieses Repository, während das Paket der Distribution zwischen den Releases zurückbleibt.

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

Fügen Sie den Signaturschlüssel und anschließend das Repository hinzu. Der Codename wird direkt auf dem Rechner ermittelt. Derselbe Block funktioniert daher unter Ubuntu 24.04 (noble) und 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 gibt die gerade installierte Version aus. Wenn apt update stattdessen einen NO_PUBKEY-Fehler ausgegeben hat, liegt der dearmorisierte Schlüssel nicht am in der Zeile Signed-By: angegebenen Pfad. apt verfügt dann über keinen Schlüssel, mit dem die Release-Datei geprüft werden kann. Das Paket deb.torproject.org-keyring ist später wichtig: Es liefert den Signaturschlüssel als gewöhnliches Paket aus. Dadurch funktioniert apt weiter, wenn dieser Schlüssel ausgetauscht wird.

Aktivieren Sie automatische Upgrades und informieren Sie sie anschließend über die neue Quelle.

sudo apt install -y unattended-upgrades apt-listchanges

Fügen Sie unter Ubuntu die Tor-Quelle zum Block Allowed-Origins in /etc/apt/apt.conf.d/50unattended-upgrades hinzu:

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

Unter Debian verwendet dieselbe Datei Origins-Pattern. Die hinzuzufügende Zeile lautet "origin=TorProject";. Prüfen Sie das Ergebnis mit sudo unattended-upgrade --debug --dry-run. Der Befehl gibt die Quellen aus, auf die er angewendet wird, und schreibt keine Änderungen.

Die relevante torrc-Konfiguration

Das Paket installiert eine lange, ausführlich kommentierte /etc/tor/torrc. Für ein Relay sind nur wenige Zeilen relevant. Fügen Sie diese am Ende der Datei hinzu.

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

Nickname darf 1 bis 19 Zeichen lang sein und ausschließlich Buchstaben und Ziffern enthalten. Der Wert ist im Netzwerk nicht eindeutig und stellt nicht Ihre Identität dar. Maßgeblich ist der Fingerprint. Über Nickname finden Sie Ihr eigenes Relay in einem Suchfeld. Wählen Sie daher einen Namen, den Sie am Telefon buchstabieren können.

ContactInfo wird im Relay-Descriptor veröffentlicht. Dabei handelt es sich um ein öffentliches Dokument, das jeder herunterladen kann. Die Adresse wird daher automatisch erfasst. Verwenden Sie eine Adresse, die Sie auch in zwei Jahren noch lesen. Bei Bedarf können Sie sie verschleiern. Dies ist der einzige Kanal, über den das Tor Project Sie vor einem Problem mit Ihrem Relay warnen kann.

ORPort 9001 ist der Port, zu dem andere Relays und Clients eine Verbindung herstellen. 9001 ist die übliche Wahl. Port 443 wird ebenfalls häufig verwendet, weil einige restriktive Netzwerke nur ausgehende Verbindungen zu 443 erlauben. Ein Relay, das dort lauscht, ist dadurch für mehr Clients erreichbar. Verwenden Sie 443 nur, wenn kein anderer Dienst auf dem System den Port benötigt.

SocksPort 0 deaktiviert den lokalen SOCKS-Proxy, den ein Relay nicht verwendet, und entfernt einen lauschenden Socket vom System. ExitRelay 0 schreibt diese Absicht ausdrücklich in die Datei: Dieses Relay stellt niemals im Namen eines Benutzers eine Verbindung zu einem Ziel her. Wer die Konfiguration später liest, muss dies nicht aus dem Standardwert ableiten.

Wenn das VPS über eine IPv6-Adresse verfügt, versucht tor bereits, diese zu verwenden. Seit tor 0.4.5 lauscht eine ORPort-Zeile ohne Adresse über IPv4 und IPv6 und ermittelt die IPv6-Adresse des Relays auf dieselbe Weise wie die IPv4-Adresse. Fügen Sie nur dann eine zweite ORPort-Zeile mit der Adresse in eckigen Klammern hinzu, wenn die automatische Ermittlung die falsche Adresse verwendet. Die Adresse muss erreichbar sein: Ein expliziter IPv6-ORPort, der den Erreichbarkeitstest nicht besteht, verhindert, dass das Relay seinen Descriptor veröffentlicht.

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

Fügen Sie auf einem VPS mit 1 GB MaxMemInQueues 512 MB hinzu. Tor legt die Größe der Warteschlange anhand des auf dem System verfügbaren Speichers fest. Auf einem kleinen gemeinsam genutzten System ist das meist mehr Speicher, als Tor verwenden soll. Wenn Sie das Limit selbst festlegen, verwirft tor bei Speicherdruck wartende Zellen. Das Relay bleibt dadurch funktionsfähig, statt die Warteschlange so lange zu vergrößern, bis der Kernel den Prozess beendet.

ORPort in der Firewall freigeben

Eingehend muss der ORPort aus dem gesamten Internet erreichbar sein. Für ausgehenden Verkehr sollte das Relay uneingeschränkt bleiben: Es baut Verbindungen zu Tausenden anderen Relays über viele verschiedene Ports auf. Eine Allowlist für ausgehenden Verkehr würde das Relay unbemerkt erheblich beeinträchtigen.

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

Prüfen Sie anschließend die Netzwerk-Firewall des Providers. Viele Control Panels führen vor der virtuellen Maschine einen Paketfilter aus. Eine Regel, die Sie mit ufw hinzugefügt haben, hat dort keine Wirkung. Dadurch erscheint der Port auf dem System als offen, ist von außen jedoch geschlossen. Wenn ufw für Sie neu ist, beschreibt die ufw-Regeln, die auf jeden VPS gehören die Standardrichtlinie und die Reihenfolge, in der Regeln abgeglichen werden.

Bandbreite passend zu Ihrem Tarif dimensionieren

Das Handbuch beschreibt RelayBandwidthRate als separaten Token-Bucket, der „die durchschnittliche eingehende Bandbreitennutzung für weitergeleiteten Datenverkehr auf diesem Knoten auf die angegebene Anzahl Bytes pro Sekunde und die durchschnittliche ausgehende Bandbreitennutzung auf denselben Wert begrenzt“. Lesen Sie das zweimal. Die Begrenzung gilt für jede Richtung separat. Ein Relay mit 1 Mbit/s kann gleichzeitig 1 Mbit/s eingehend und 1 Mbit/s ausgehend übertragen. Ein Anbieter, der beide Richtungen misst, berechnet die Summe.

[
  {
    "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"
  }
]

Diese 5 Zeilen sind eine arithmetische Berechnung und keine Messung. Sie zeigen, welche Datenmenge eine Rate verursacht, wenn das Relay sie 30 Tage lang in beide Richtungen dauerhaft auslastet. Ein echtes Relay bleibt häufig unter seinem Limit, besonders in den ersten Wochen. Verwenden Sie die Tabelle, um Einstellungen auszuschließen, die nicht in Ihren Tarif passen. Verwenden Sie sie nicht, um eine Abrechnung auf das Gigabyte genau vorherzusagen.

Bei 1 Mbit/s in jede Richtung überträgt ein Relay ungefähr 21.6 GB pro Tag. Ein Monat mit 30 Tagen verursacht damit ungefähr 648 GB gemessenen Datenverkehr. Das passt mit Reserve für Updates und Backups in ein Kontingent von 1 TB. Bei 2 Mbit/s verursacht der Monat 1,296 GB. Das liegt bereits über einem Tarif mit 1 TB. Die letzte Zeile, 20 Mbit/s, benötigt 12,960 GB pro Monat und gehört an einen Anschluss ohne Volumenbegrenzung. Wenn Ihr Anbieter nur ausgehenden Datenverkehr berechnet, halbieren Sie alle Werte. Klären Sie vor dem Festlegen der Rate, welches Abrechnungsmodell gilt. Die beiden Ergebnisse unterscheiden sich um den Faktor zwei.

Nun zur Konfiguration. Begrenzen Sie zuerst die Rate und setzen Sie danach das Kontingent.

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

RelayBandwidthBurst ist die Größe des Token-Buckets. Dadurch sind kurze Spitzen über der Rate möglich, während der Durchschnitt die Begrenzung einhält. Ein Wert von ungefähr dem Doppelten der Rate ist sinnvoll.

AccountingRule ist die Zeile, die viele Betreiber übersehen. Der Standardwert ist max. Dabei wird die größere der beiden Richtungen gegen das Kontingent gerechnet. Mit dem Standardwert erlaubt AccountingMax 400 GBytes 400 GB eingehend und 400 GB ausgehend. Auf einem Zähler, der beide Richtungen erfasst, sind das 800 GB. AccountingRule sum rechnet Lese- und Schreibvorgänge gegen dasselbe Kontingent. Das entspricht der Messung eines tatsächlichen Datenübertragungskontingents.

Setzen Sie außerdem AccountingStart, niemals allein AccountingMax. Das Kontingent ist der Zahlenwert. Die Startzeile legt fest, wann es zurückgesetzt wird. Ein Kontingent ohne Zeitraum versetzt das Relay in den Ruhezustand, ohne dass es wieder aktiviert wird.

Der Ruhezustand ist ein grobes Mittel. Wenn das Kontingent aufgebraucht ist, schreibt tor dies ins Log und nimmt keine Arbeit mehr an:

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

Das Relay wird auch nicht exakt zum Beginn des nächsten Zeitraums wieder aktiv. Tor verfolgt, wie schnell das letzte Kontingent verbraucht wurde, und wählt innerhalb des neuen Zeitraums einen zufälligen Zeitpunkt. Dadurch kehren nicht Tausende Relays in derselben Sekunde ins Netzwerk zurück. Ein Relay, das in der letzten Woche jedes Monats verschwindet, verliert fortlaufend die Stabilität, anhand derer es von den Directory Authorities bewertet wird. Dimensionieren Sie RelayBandwidthRate so, dass das Limit nie erreicht wird. Lassen Sie AccountingMax als letzte Schutzmaßnahme für die Rechnung bestehen.

Relay starten und Erreichbarkeit bestätigen

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

Innerhalb weniger Minuten sollte das Log diese Zeile enthalten:

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

Das bedeutet, dass andere Relays eine Verbindung zu Ihrem ORPort hergestellt und darüber einen Circuit aufgebaut haben. Bis diese Zeile erscheint, ist Ihr Relay nicht im Directory eingetragen und überträgt überhaupt keinen Traffic. Der Fehler sieht so aus:

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.

Arbeiten Sie die möglichen Ursachen in dieser Reihenfolge durch. Ist der ORPort in ufw geöffnet? Ist er auch in der separaten Netzwerk-Firewall des Providers geöffnet? Ist die in dieser Meldung angegebene Adresse tatsächlich die Adresse, über die das Internet Ihren Server erreicht, und nicht eine private Adresse aus einer NAT-Konfiguration? Testen Sie den Port von einem anderen Rechner aus mit nc -vz 203.0.113.10 9001. Tor wiederholt den Selbsttest automatisch. Eine dauerhaft korrigierte Firewall-Konfiguration wird daher auch ohne Ihr Zutun erkannt. Ein Neustart führt den Test sofort aus.

Die dauerhafte Identität Ihres Relays ist sein Fingerprint:

sudo cat /var/lib/tor/fingerprint

Ungefähr drei Stunden nach der Veröffentlichung des Descriptors erscheint das Relay in der Relay Search. Suchen Sie nach dem Nickname oder fügen Sie den Fingerprint ein. Diese Seite zeigt, wie das Netzwerk Ihr Relay sieht: welche Flags es besitzt, welches Gewicht die Authorities ihm geben und welche Version es veröffentlicht.

Warum transportiert ein neues Tor-Relay fast keinen Datenverkehr?

Weil das Netzwerk es noch nicht vermessen hat und die Messung Wochen dauert. Das Tor Project beschreibt den Hochlauf in vier Phasen. Ein Betreiber, der diese Beschreibung nicht gelesen hat, kommt zu dem Schluss, dass das Relay defekt ist, und beginnt, Änderungen vorzunehmen.

In den ersten drei Tagen ist das Relay nicht vermessen. Es meldet das Ergebnis seines eigenen Selbsttests. Die Directory Authorities begrenzen das veröffentlichte Gewicht trotzdem auf 20 KB, sodass Clients es fast nie auswählen. Etwa vom dritten bis zum achten Tag vermessen die Bandwidth Authorities das Relay tatsächlich. Sein Gewicht steigt, aber es wird nur als mittlerer Hop verwendet, weil kein Client ein ganz neues Relay als ersten Hop verwenden möchte.

Um den achten Tag wird das Relay für das Guard-Flag zugelassen. Wenn es das Flag erhält, sinkt der Datenverkehr. Das überrascht viele Betreiber: Bei der Auswahl mittlerer Hops überspringen Clients Guards, weil sie davon ausgehen, dass ein Guard bereits ausgelastet ist. Dadurch verliert das Relay Datenverkehr als mittlerer Hop, bevor es Datenverkehr als Guard gewinnt. Es füllt sich erst wieder auf, wenn Clients ihre Guard-Sets wechseln. Das dauert Wochen. Nach ungefähr 68 Tagen erreicht es einen stabilen Zustand. Die Zahl der Clients, die es entfernen, entspricht dann ungefähr der Zahl der Clients, die es hinzufügen.

Die realistische Erwartung lautet daher: drei Tage lang nichts, nach einer Woche etwas und nach zwei Monaten eine tatsächliche Auslastung. Ändern Sie jeweils nur eine Einstellung. Warten Sie anschließend eine Woche, um die Auswirkung zu prüfen. Eine selbst gehostete Uptime-Kuma-Statusseite mit einer TCP-Prüfung gegen Port 9001 ist eine sinnvollere Beschäftigung für die eigene Nervosität. Sie beantwortet die Frage, die Sie tatsächlich kontrollieren können: ob der Port weiterhin antwortet.

Nyx zur Überwachung des Relays

nyx ist die Terminalüberwachung für ein laufendes Relay. Das Programm kommuniziert mit dem Control-Port von tor. Aktivieren Sie ihn daher zuerst in torrc:

ControlPort 9051
CookieAuthentication 1
CookieAuthFileGroupReadable 1

ControlPort lauscht ausschließlich auf 127.0.0.1. Bei der Cookie-Authentifizierung muss ein Programm zuerst eine geheime Datei lesen, bevor es Befehle ausführen kann. Unter Debian und Ubuntu entsprechen die letzten beiden Zeilen bereits dem Paketstandard: Das eigene /usr/share/tor/tor-service-defaults-torrc-Paket von tor setzt CookieAuthentication 1, CookieAuthFileGroupReadable 1 und CookieAuthFile /run/tor/control.authcookie. Dadurch schreibt tor das Cookie als Benutzer debian-tor nach /run/tor/control.authcookie. Die Gruppe debian-tor kann die Datei von Anfang an lesen. Wenn Sie die beiden Zeilen in torrc schreiben, wird diese Einstellung nur für Personen sichtbar, die die Konfiguration später lesen. Die Mitgliedschaft in dieser Gruppe ermöglicht es Ihrem eigenen Konto, nyx ohne sudo auszuführen.

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

Melden Sie sich ab und wieder an. Führen Sie anschließend nyx aus. Die neue Gruppe muss bei der Anmeldung übernommen werden. Wenn Sie nyx in derselben Shell-Sitzung starten, erhalten Sie für die Cookie-Datei einen Berechtigungsfehler, obwohl die Konfiguration korrekt ist. nyx zeigt die aktuelle Bandbreite, die Laufzeit, den Logstream und die Verbindungsliste an. In den ersten Wochen sollten Sie darauf achten, dass die Bandbreitenkurve unter Ihrem RelayBandwidthRate bleibt.

Mehr als ein Relay betreiben: MyFamily und Family Keys

Wenn Sie nur ein Relay betreiben, überspringen Sie diesen Abschnitt. Zwei oder mehr Relays desselben Betreibers müssen einander deklarieren. Dadurch bauen Clients niemals einen Circuit auf, der über Ihre Geräte ein- und wieder ausgeleitet wird. Andernfalls könnte ein Betreiber beide Enden des Circuits sehen.

Der bisher übliche Weg ist MyFamily in der torrc-Datei jedes Relays. Dort werden die Fingerprints aller anderen Relays aufgeführt:

MyFamily AAAAAAAAAA,BBBBBBBB

Jedes Relay führt alle anderen Relays auf. Ein viertes Relay erfordert daher Änderungen an vier Dateien. Tor 0.4.9 ergänzt einen Family Key, der diese Liste nicht ersetzt, sondern zusammen mit ihr verwendet wird. Im Tor-Handbuch wird der Key als künftig bevorzugte Methode zur Bekanntgabe einer Relay-Familie bezeichnet. Für den Moment sollen Relay-Familien jedoch sowohl diesen Key als auch MyFamily konfigurieren. Sobald alle Ihre Relays 0.4.9.2-alpha oder neuer ausführen, generieren Sie einen Key und verteilen ihn anschließend:

tor --keygen-family myfamily

Der Befehl schreibt myfamily.secret_family_key und gibt eine Zeile mit FamilyId aus. Kopieren Sie die Key-Datei auf jedes Relay in das Verzeichnis keys unterhalb von DataDirectory (/var/lib/tor/keys unter Debian und Ubuntu). Behalten Sie dabei das Suffix .secret_family_key bei. Fügen Sie die ausgegebene Zeile FamilyId in jede torrc-Datei ein und laden Sie die Konfiguration mit sudo systemctl reload tor@default neu. Belassen Sie auch die Liste MyFamily in der Konfiguration. Clients, die Family Keys noch nicht unterstützen, lesen weiterhin nur die Legacy-Liste. Deshalb verlangt das Handbuch beide Einstellungen.

Was nach dem Start ausfällt

Die Version ist veraltet. Unattended upgrades ersetzen das Paket. Der laufende Prozess verwendet jedoch weiterhin die Binärdatei, mit der er gestartet wurde, bis er neu gestartet wird. Vergleichen Sie tor --version auf dem Server mit der auf der Relay Search-Seite des Relays angezeigten Version. Wenn sie abweichen, sieht das Netzwerk weiterhin die alte Version. Starten Sie den Dienst neu.

Die Uhr geht falsch. Konsensdokumente und Zertifikate sind zeitgebunden. Ein Rechner mit stark abweichender Uhr weist den Konsens zurück und veröffentlicht nichts mehr. timedatectl sollte melden, dass die Systemuhr synchronisiert ist. Falls das nicht der Fall ist, aktivieren Sie systemd-timesyncd oder installieren Sie chrony.

Die IP-Adresse ändert sich. Der Descriptor enthält die Adresse. Clients können eine Adresse nicht erreichen, wenn sie geändert wurde. Starten Sie tor nach jedem Providerwechsel oder jeder Adressänderung neu und achten Sie erneut auf die Zeile des Selbsttests.

Das Relay ist langsamer, als es der Tarif erlaubt. Die Relay-Kryptografie von Tor arbeitet auf modernen Prozessoren effizient. Das Tor Project veranschlagt für eine CPU mit AES-NI-Unterstützung ungefähr 400 bis 450 Mbit/s in jeder Richtung. Lange vor dieser Obergrenze werden Sie durch die Portgeschwindigkeit und das Transferlimit begrenzt. Deshalb ist der Abschnitt zur Abrechnung weiter oben wichtiger als die Hardware.

FAQ

Wie viel Bandbreite verwendet ein Tor-Relay?

So viel, wie Sie erlauben, und nicht mehr. RelayBandwidthRate begrenzt den weitergeleiteten Datenverkehr für jede Richtung separat. Ein Relay mit 1 Mbit/s kann daher gleichzeitig 1 Mbit/s eingehend und 1 Mbit/s ausgehend übertragen. Das entspricht ungefähr 21.6 GB pro Tag oder 648 GB in einem Monat mit 30 Tagen, wobei beide Richtungen gezählt werden. Fügen Sie darunter AccountingMax mit AccountingRule sum als festes monatliches Limit für diese Rate hinzu.

Erhalte ich durch den Betrieb eines Tor-Relays Beschwerden wegen Missbrauchs?

Ein Guard- oder Middle-Relay leitet Datenverkehr nur an andere Tor-Relays weiter und verbindet sich niemals für einen Benutzer mit einer Website. Beschwerden über Aktivitäten, die jemand über Tor ausgeführt hat, gehen daher an den Betreiber des Exit-Relays und nicht an Sie. Sie können jedoch Scans und gelegentliche Einträge in IP-Reputationslisten feststellen, weil die Adresse öffentlich als Relay aufgeführt ist. Exit-Relays erhalten Missbrauchsmeldungen und rechtliche Benachrichtigungen. Dafür benötigen sie einen Provider, der deren Bearbeitung im Voraus zugesagt hat. Lesen Sie vor dem Start die Bedingungen Ihres Providers, unabhängig davon, welche Relay-Art Sie betreiben.

Warum erhält mein neues Tor-Relay keinen Datenverkehr?

Neue Relays werden absichtlich gedrosselt, bis sie vermessen wurden. In den ersten drei Tagen begrenzen die Directory Authorities das veröffentlichte Gewicht auf 20 KB. Clients wählen das Relay daher fast nie aus. Die Bandwidth Authorities messen es ab ungefähr dem dritten Tag. Um den achten Tag wird es für das Guard-Flag zugelassen. Zu diesem Zeitpunkt geht der Datenverkehr wieder zurück, weil Clients Guards bei der Auswahl von Middle-Hops vermeiden. Die vollständige Auslastung wird ungefähr nach 68 Tagen erreicht. Prüfen Sie, ob das Log die Meldung "Self-testing indicates your ORPort is reachable from the outside" enthält. Lassen Sie das Relay anschließend unverändert weiterlaufen.

Kann ich ein Tor-Relay auf einem VPS mit einem Übertragungslimit von 1 TB betreiben?

Ja, bei ungefähr 1 Mbit/s in jeder Richtung. Das entspricht RelayBandwidthRate 125 KBytes. Wenn Ihr Provider beide Richtungen abrechnet, sind das ungefähr 648 GB pro Monat. Damit bleibt noch Reserve für Updates und Backups. Fügen Sie AccountingMax 400 GBytes mit AccountingRule sum und AccountingStart month 1 00:00 hinzu, damit das Relay in den Ruhezustand wechselt, statt das Limit zu überschreiten. Wenn der Provider nur ausgehenden Datenverkehr abrechnet, können Sie die Rate verdoppeln.

Muss ich MyFamily setzen, wenn ich nur ein Relay betreibe?

Nein. Family-Deklarationen sorgen dafür, dass Clients keine Verbindung über zwei Relays desselben Betreibers aufbauen. Bei einem einzigen Relay ist das bedeutungslos. Setzen Sie die Deklaration, sobald Sie ein zweites Relay hinzufügen: Tragen Sie den Fingerprint jedes Relays in die MyFamily-Zeile jedes Relays ein. Sobald auf jedem Relay Tor 0.4.9.2-alpha oder höher läuft, fügen Sie zusätzlich die FamilyId-Zeile des gemeinsamen Family-Schlüssels hinzu. Das tor-Handbuch verlangt derzeit, dass Sie beide Angaben konfigurieren, damit ältere Clients die Familie weiterhin erkennen.