Tor-Relay auf einem VPS einrichten: Guard oder Middle

Was ein Tor-Relay auf einem VPS tut

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 über das Relay auf. Ein Guard- oder Middle-Relay leitet den Datenverkehr ausschließlich an ein weiteres Relay weiter. 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 ist es dadurch für einen gewöhnlichen VPS geeignet.

Der Aufwand ist gering: ein Paket, 15 Zeilen Konfiguration, eine Firewall-Regel und ein Neustart. Der problematische Teil dieses Leitfadens folgt danach. Dazu gehören die Berechnung des Datenverkehrs bei einem volumenbasierten Tarif und der Grund, warum ein vollständig funktionsfähiges neues Relay eine Woche lang inaktiv wirkt.

Guard, Middle, Bridge oder Exit: Treffen Sie die Auswahl vor der Installation

Ein Daemon übernimmt alle vier Rollen. Ihre Konfiguration und die Directory Authorities bestimmen, welche Rolle der Server einnimmt.

• Middle Relay. Es empfängt Datenverkehr von einem Guard und leitet ihn an ein weiteres Relay weiter. Es kontaktiert niemals eine Zielseite. Jedes neue Relay beginnt in 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 müssen sie sich verdienen. Die folgende Konfiguration ist die Grundlage dafür.
• Bridge. Ein Relay, das bewusst aus dem öffentlichen Directory herausgehalten und privat an Benutzer in Regionen verteilt wird, in denen Tor blockiert ist. Dies ist die Rolle mit der geringsten Bindung: geringe Bandbreite, kein öffentlicher Eintrag und der richtige erste Schritt, wenn Ihr Vorhaben klein ist.
• Exit Relay. Der letzte Hop, der die Verbindung zur Zielseite öffnet. Jede Anfrage eines Benutzers verlässt das Netzwerk über Ihre IP-Adresse. Daher gehen Missbrauchsmeldungen und Anfragen der Polizei an den Betreiber dieser Adresse.

Ein Exit gehört als einzige Rolle nicht auf einen allgemeinen VPS. Betreiben Sie einen Exit nur bei einem Anbieter, der vorab zugestimmt hat, diese E-Mails zu empfangen, und der eine eigene IP-Adresse sowie einen veröffentlichten Abuse-Kontakt bereitstellt. Die meisten Standardbedingungen von Hosting-Anbietern untersagen dies. Bei einer Missachtung wird der Server normalerweise gesperrt und die IP-Adresse entzogen. Ein Guard oder Middle Relay transportiert denselben Benutzerdatenverkehr ohne diese Risiken.

Alles Folgende richtet ein Guard/Middle Relay ein. ExitRelay 0 ist die Zeile, die verhindert, dass es zum Exit wird.

Was der VPS vor dem Start benötigt

Das Tor Project veröffentlicht verbindliche Anforderungen für Relays. Stand August 2026 sind dies: eine öffentliche IPv4-Adresse für das Relay, mindestens 10 Mbit/s Bandbreite in beide Richtungen, empfohlen werden 16 Mbit/s, mindestens 100 GB ausgehender Traffic pro Monat sowie 512 MB RAM bei weniger als 40 Mbit/s oder 1 GB darüber. Es gibt keine feste Uptime-Vorgabe. 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 Bandbreite bereitstellen kann. Wie viel dieser Bandbreite Sie dem Relay erlauben, ist eine separate Entscheidung, die sich an der monatlichen Transfermenge orientiert. Lesen Sie Ihren Tarif, bevor Sie die Konfiguration ändern. Wenn Sie noch einen Server auswählen, erklärt was ein VPS tatsächlich pro Monat kostet, wie Transferkontingente angeboten werden. Die tatsächliche Netzwerkbandbreite eines VPS messen zeigt, wie Sie mit iperf3 ermitteln, was die Leitung tatsächlich leistet, statt der Verkaufsseite zu vertrauen.

Härten Sie den Rechner zuerst ab. Ein Relay ist ein öffentlicher Dienst auf einer öffentlichen Adresse. Die 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 muss vor dem produktiven Start des Relays erfolgen, nicht danach.

Tor aus dem Repository des Tor Project installieren

Verwenden Sie das eigene apt-Repository des Tor Project statt des Distributionspakets. Der Relay-Code wird schneller weiterentwickelt als ein Stable-Release. Daher erreichen Fehlerbehebungen dieses Repository zuerst, während das Distributionspaket zwischen den Releases zurückbleibt.

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

Fügen Sie zuerst den Signaturschlüssel und anschließend das Repository hinzu. Der Codename wird direkt auf dem System ermittelt. Daher funktioniert derselbe Block 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 entschlüsselte Schlüssel nicht an dem in der Zeile Signed-By: angegebenen Pfad. apt hat dann keinen Schlüssel, mit dem es die Release-Datei prüfen kann. Das Paket deb.torproject.org-keyring ist später wichtig: Es liefert den Signaturschlüssel als reguläres Paket. Dadurch funktioniert apt weiter, wenn dieser Schlüssel ausgetauscht wird.

Aktivieren Sie automatische Upgrades. Konfigurieren Sie anschließend die neue Origin dafür.

sudo apt install -y unattended-upgrades apt-listchanges

Fügen Sie unter Ubuntu die Tor-Origin 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 Origins aus, auf die er angewendet wird, und schreibt keine Änderungen.

Die relevante torrc

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 besteht aus 1 bis 19 Zeichen und darf nur Buchstaben und Ziffern enthalten. Der Wert ist im Netzwerk nicht eindeutig und stellt nicht Ihre Identität dar. Dafür ist der Fingerabdruck maßgeblich. Über diesen Namen 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 von Crawlern erfasst. Verwenden Sie eine Adresse, die Sie auch in zwei Jahren noch lesen. Sie können sie bei Bedarf verschleiern. Dies ist der einzige Kommunikationskanal, über den das Tor Project Sie über ein Problem mit Ihrem Relay informieren kann.

ORPort 9001 ist der Port, zu dem andere Relays und Clients eine Verbindung herstellen. 9001 ist üblich. Port 443 ist ebenfalls eine gängige Wahl, weil einige restriktive Netzwerke nur ausgehende Verbindungen zu 443 erlauben. Ein Relay, das dort lauscht, ist daher für mehr Clients erreichbar. Verwenden Sie 443 nur, wenn kein anderer Dienst auf dem System diesen Port benötigt.

SocksPort 0 deaktiviert den lokalen SOCKS-Proxy, den ein Relay nicht verwendet, und entfernt einen Listening-Socket vom System. ExitRelay 0 schreibt diese Absicht ausdrücklich in die Datei: Dieses Relay wird niemals im Auftrag eines Benutzers eine Verbindung zu einem Ziel herstellen. Außerdem muss niemand, der die Konfiguration später liest, diese Einstellung aus dem Standardwert ableiten.

Wenn die VPS über eine IPv6-Adresse verfügt, fügen Sie eine zweite ORPort-Zeile hinzu. Tor kann nicht wie bei IPv4 an eine beliebige IPv6-Adresse binden. Schreiben Sie die Adresse daher in eckige Klammern.

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

Fügen Sie auf einer VPS mit 1 GB außerdem MaxMemInQueues 512 MB hinzu. Tor legt das Warteschlangenlimit anhand des auf dem System erkannten Arbeitsspeichers fest. Auf einem kleinen gemeinsam genutzten System ist dieses Limit höher, als es sein sollte. Wenn Sie das Limit selbst festlegen, verwirft Tor bei hoher Auslastung zwischengespeicherte Cells. Das Relay bleibt dadurch funktionsfähig, statt die Warteschlange so lange zu vergrößern, bis der Kernel den Prozess beendet.

Öffnen Sie den ORPort in der Firewall

Eingehend muss der ORPort aus dem gesamten Internet erreichbar sein. Lassen Sie das Relay ausgehend uneingeschränkt: Es baut Verbindungen zu Tausenden anderen Relays über viele verschiedene Ports auf. Eine Allowlist für ausgehenden Datenverkehr würde es unbemerkt stark 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 betreiben vor der virtuellen Maschine einen Paketfilter. Eine mit ufw hinzugefügte Regel hat dort keine Wirkung. Der Port kann deshalb auf dem System als offen erscheinen, von außen jedoch geschlossen sein. Wenn ufw für Sie neu ist, erläutert die ufw-Regeln, die auf jedes VPS gehören die Standardrichtlinie und die Reihenfolge, in der die Regeln abgearbeitet werden.

Die 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 diesen Satz 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 deren 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 Rechenhilfe, keine Messung. Sie zeigen, welche Datenmenge bei einer Rate anfällt, wenn das Relay sie 30 Tage lang in beide Richtungen durchgehend 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 Ihr Budget passen. Verwenden Sie sie nicht, um eine Rechnung bis auf das Gigabyte vorherzusagen.

Bei 1 Mbit/s in jede Richtung überträgt ein Relay etwa 21.6 GB pro Tag. In einem Monat mit 30 Tagen entstehen daher ungefähr 648 GB berechneter Datenverkehr. Das passt mit Reserve für Updates und Backups in ein Kontingent von 1 TB. Bei 2 Mbit/s fallen im Monat 1,296 GB an. Damit ist ein Tarif mit 1 TB bereits überschritten. Die letzte Zeile, 20 Mbit/s, benötigt 12,960 GB pro Monat und gehört an einen Anschluss ohne Datenmengenbegrenzung. 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 anschließend 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 kurzzeitige Spitzen über der Rate möglich, solange der Durchschnitt eingehalten wird. Etwa das Doppelte der Rate ist ein sinnvoller Wert.

AccountingRule ist die Zeile, die viele Betreiber übersehen. Der Standardwert ist max. Dabei wird die größere der beiden Richtungen auf das Kontingent angerechnet. 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 auf dasselbe Kontingent an. Das entspricht der Messung eines tatsächlichen Übertragungskontingents.

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

Der Ruhezustand ist ein grobes Mittel. Wenn das Kontingent ausgeschöpft ist, protokolliert tor dies und nimmt keine weiteren Aufgaben 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 aktiviert. Tor ermittelt, wie schnell das letzte Kontingent verbraucht wurde, und wählt einen zufälligen Zeitpunkt innerhalb des neuen Intervalls. Dadurch kehren nicht Tausende Relays in derselben Sekunde zum Netzwerk zurück. Ein Relay, das in der letzten Woche jedes Monats ausfällt, verliert fortlaufend die Stabilität, anhand derer es von den Directory Authorities bewertet wird. Dimensionieren Sie RelayBandwidthRate so, dass das Limit nie erreicht wird. Verwenden Sie AccountingMax als zusätzliche Absicherung gegen eine unerwartet hohe Rechnung.

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.

Diese Meldung bedeutet, dass andere Relays eine Verbindung zu Ihrem ORPort hergestellt und einen Circuit darüber aufgebaut haben. Bis sie erscheint, ist Ihr Relay nicht im Verzeichnis eingetragen und überträgt überhaupt keinen Datenverkehr. 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 der Reihe nach 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 Ihr System 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 korrigierte Firewall-Konfiguration wird daher ohne weiteres 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

Etwa drei Stunden nach der Veröffentlichung des Deskriptors erscheint das Relay in der Relay-Suche. 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 ihm die Authorities geben und welche Version es veröffentlicht.

Warum trägt ein neuer Tor-Relay fast keinen Datenverkehr?

Weil das Netzwerk ihn noch nicht bewertet hat und diese Bewertung mehrere Wochen dauert. Das Tor Project beschreibt den Hochlauf in vier Phasen. Ein Betreiber, der diese Beschreibung nicht gelesen hat, hält das Relay für defekt und beginnt, Einstellungen zu ändern.

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

Um den achten Tag wird das Relay für das Guard-Flag zugelassen. Das Setzen dieses Flags lässt den Datenverkehr zurückgehen, was zunächst überrascht: Beim Auswählen mittlerer Hops überspringen Clients Guards, weil sie davon ausgehen, dass ein Guard bereits ausgelastet ist. Dadurch verliert das Relay mittleren Datenverkehr, bevor es Guard-Datenverkehr gewinnt. Erst wenn Clients ihre Guard-Sets wechseln, füllt sich der Datenverkehr wieder auf. Das dauert mehrere Wochen. Nach etwa 68 Tagen erreicht das Relay einen stabilen Zustand. Dann gleicht die Zahl der Clients, die es entfernen, ungefähr der Zahl der Clients aus, die es hinzufügen.

Die realistische Erwartung lautet daher: drei Tage lang nichts, nach einer Woche etwas und nach zwei Monaten eine echte Auslastung. Ändern Sie jeweils nur eine Einstellung. Warten Sie anschließend eine Woche, um die Auswirkung zu sehen. Eine selbst gehostete Statusseite mit Uptime Kuma und einer TCP-Prüfung gegen Port 9001 nutzt die vorhandene Unruhe besser. Sie beantwortet die Frage, die Sie tatsächlich kontrollieren können: ob der Port weiterhin antwortet.

Relay mit nyx überwachen

nyx ist der Terminalmonitor für einen laufenden 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 zunächst eine geheime Datei lesen, bevor es Befehle ausführen kann. Tor schreibt dieses Cookie als Benutzer debian-tor nach /run/tor/control.authcookie und setzt den Modus auf 600. Dadurch kann kein anderer Benutzer die Datei lesen. CookieAuthFileGroupReadable 1 gibt die Datei für die Gruppe frei. Damit kann Ihr eigenes Konto nyx ohne sudo ausfü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 wird erst bei der Anmeldung übernommen. Wenn Sie nyx in derselben Shell-Sitzung starten, wird für die Cookie-Datei ein Berechtigungsfehler ausgegeben, obwohl die Konfiguration korrekt ist. nyx zeigt die aktuelle Bandbreite, die Laufzeit, den Logdatenstrom und die Verbindungsliste an. In den ersten Wochen sollten Sie darauf achten, dass das Bandbreitendiagramm unter Ihrem RelayBandwidthRate bleibt.

Mehr als ein Relay betreiben: MyFamily und Family Keys

Bei einem einzelnen Relay überspringen Sie diesen Abschnitt. Zwei oder mehr Relays desselben Betreibers müssen einander deklarieren. So bauen Clients nie einen Circuit auf, der über Ihre Maschinen ein- und wieder ausgeleitet wird. Andernfalls könnte ein Betreiber beide Enden des Circuits sehen.

Die bisher übliche Methode besteht aus MyFamily in der torrc jedes Relays. Dort werden die Fingerprints aller anderen Relays aufgeführt:

MyFamily AAAAAAAAAA,BBBBBBBB

Jedes Relay führt alle anderen Relays auf. Das bedeutet: Für ein viertes Relay müssen Sie vier Dateien bearbeiten. Tor 0.4.9 ersetzt diese Methode durch einen Family Key. Generieren Sie einen Schlüssel und verteilen Sie ihn anschließend:

tor --keygen-family myfamily

Der Befehl schreibt myfamily.secret_family_key und gibt eine Zeile mit FamilyId aus. Kopieren Sie die Schlüsseldatei auf jedes Relay in das Unterverzeichnis keys des 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 zu jeder torrc hinzu und laden Sie die Konfiguration mit sudo systemctl reload tor@default neu. Lassen Sie die Liste MyFamily vorerst ebenfalls bestehen. Clients, die Family Certificates noch nicht verstehen, verwenden weiterhin die alte Liste. Das Tor Project wird bekannt geben, sobald sie entfernt werden kann.

Was nach dem Start ausfallen kann

Die Version ist veraltet. Unattended upgrades ersetzt das Paket, aber der laufende Prozess verwendet weiterhin die Binärdatei, mit der er gestartet wurde, bis ein Neustart erfolgt. Vergleichen Sie tor --version auf dem Server mit der auf der Relay Search-Seite des Relays angezeigten Version. Wenn die Versionen 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 einer stark abweichenden Uhr lehnt den Konsens ab und veröffentlicht nicht mehr. timedatectl sollte melden, dass die Systemuhr synchronisiert ist. Falls nicht, aktivieren Sie systemd-timesyncd oder installieren Sie chrony.

Die IP-Adresse ändert sich. Der Descriptor enthält die Adresse. Clients können eine Adresse, die sich geändert hat, nicht erreichen. Starten Sie tor nach jedem Providerwechsel oder jeder Adressänderung neu und überwachen Sie die Self-Test-Meldung erneut.

Das Relay ist langsamer, als der Tarif zulässt. 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 jede Richtung. Lange vor diesem Grenzwert begrenzen Sie die Portgeschwindigkeit und das Transferlimit. 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 in 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 30-Tage-Monat, wobei beide Richtungen gezählt werden. Ergänzen Sie darunter AccountingMax mit AccountingRule sum als festem monatlichem Limit.

Erhalte ich durch den Betrieb eines Tor-Relays Abuse-Beschwerden?

Ein Guard- oder Middle-Relay leitet Datenverkehr ausschließlich an andere Tor-Relays weiter. Es 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. Möglich sind jedoch Scans und gelegentliche Einträge in IP-Reputationslisten, weil die Adresse öffentlich als Relay aufgeführt wird. Exit-Relays erhalten Abuse-E-Mails und rechtliche Mitteilungen. Dafür benötigen sie einen Provider, der deren Bearbeitung im Voraus zugesagt hat. Lesen Sie vor dem Start die Vertragsbedingungen Ihres Providers, unabhängig davon, welche Relay-Art Sie betreiben.

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

Weil neue Relays absichtlich gedrosselt werden, 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 das Relay ab ungefähr dem dritten Tag. Um den achten Tag wird es für das Guard-Flag zugelassen. Zu diesem Zeitpunkt geht der Datenverkehr erneut zurück, weil Clients Guards bei der Auswahl von Middle-Hops vermeiden. Die volle Auslastung wird ungefähr um Tag 68 erreicht. Prüfen Sie, ob das Log "Self-testing indicates your ORPort is reachable from the outside" enthält, und lassen Sie das Relay anschließend einfach laufen.

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

Ja, bei ungefähr 1 Mbit/s in jede 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. Ergänzen Sie AccountingMax 400 GBytes mit AccountingRule sum und AccountingStart month 1 00:00, damit das Relay in den Ruhezustand wechselt, statt das Kontingent 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: Listen Sie den Fingerabdruck jedes Relays in der MyFamily-Zeile jedes Relays auf. Alternativ können Sie den mit Tor 0.4.9 eingeführten Family-Key verwenden. Dieser verteilt einen einzigen FamilyId anstelle einer immer länger werdenden Liste.