Relay-Betreiber

Tor errät seine IP-Adresse, indem es den Computer nach seinem Hostnamen fragt und dann diesen Hostnamen auflöst. Oft haben Leute alte Einträge in ihrer /etc/hosts-Datei, die auf alte IP-Adressen zeigen.

Wenn das nicht hilft, solltest du die Konfigurationsoption "Adresse" verwenden, um die IP anzugeben, die ausgewählt werden soll. Wenn sich dein Computer hinter einem NAT befindet und nur eine interne IP-Adresse hat, siehe den folgenden Support-Eintrag zu dynamischen IP-Adressen.

Ausserdem, wenn du viele Adressen hast, möchtest du vielleicht auch "OutboundBindAddress" so einstellen, dass externe Verbindungen von der IP kommen, die du der Welt präsentieren willst.

Wenn dein Relay neu ist gib ihm ein bisschen Zeit. Tor entscheidet anhand von Berichten von Bandbreiten-Autoritäten heuristisch, welche Relays es benutzt. Diese Autoritäten messen die Kapazität deines Relays und leiten mit der Zeit mehr Verkehr dorthin, bis es eine optimale Auslastung erreicht hat. Der Lebenszyklus eines neuen Relays wird in diesem Blogeintrag ausführlicher erläutert. Wenn du schon eine Weile ein Relay betreibst und immer noch Probleme hast, dann versuche auf der Tor-Relays-Liste nachzufragen.

Warum die Relay-Last variiert

Tor verwaltet die Bandbreite im gesamten Netzwerk. Für die meisten Relays macht es einen vernünftigen Job. Aber die Ziele von Tor sind anders als bei Protokollen wie BitTorrent. Tor will Webseiten mit niedriger Latenz, was schnelle Verbindungen mit Reserven erfordert. BitTorrent will Massendownloads, was die Nutzung der gesamten Bandbreite erfordert.

Wir arbeiten an einem neuen Bandbreitenscanner, der einfacher zu verstehen und zu warten ist. Es verfügt über Diagnosen für Relays, die nicht gemessen werden, und Relays, die niedrige Messwerte aufweisen.

Warum braucht Tor Bandbreitenscanner?

Die meisten Anbieter geben dir die maximale Geschwindigkeit deines lokalen Anschlusses an. Aber Tor hat Benutzer auf der ganzen Welt, und unsere Benutzer verbinden sich zufällig mit einem oder zwei Schutz-Relays. Wir müssen also wissen, wie gut jedes Relay mit der ganzen Welt verbunden werden kann.

Selbst wenn also alle Relay-Betreiber ihre beworbene Bandbreite auf ihre lokale Verbindungsgeschwindigkeit einstellen würden, bräuchten wir immer noch Bandbreiten-Autoritäten, um die Last zwischen verschiedenen Teilen des Internets auszugleichen.

Was ist eine normale Relay-Last?

Es ist normal, dass die meisten Relays mit 30%-80% ihrer Kapazität belastet werden. Dies ist gut für die Clients: ein überlastetes Relay hat eine hohe Latenz. (Wir wollen genug Relays, so dass jedes Relay zu 10% ausgelastet ist. Dann wäre Tor fast so schnell wie das breitere Internet).

Manchmal ist ein Relay langsam, weil sein Prozessor langsam ist oder seine Verbindungen begrenzt sind. In anderen Fällen ist es das Netzwerk, das langsam ist: das Relay hat ein schlechtes Peering zu den meisten anderen Tor-Relays oder ist sehr weit entfernt.

Herausfinden, was ein Relay einschränkt

Viele Dinge können ein Relay ausbremsen. Hier erfährst du, wie du sie aufspüren kannst.

System-Grenzwerte

  • Überprüfe die RAM-, CPU- und Socket-/Dateideskriptor-Auslastung auf deinem Relay

Tor protokolliert einiges davon, wenn es startet. Andere können mit top oder ähnlichen Tools eingesehen werden.

Provider-Grenzwerte

  • Prüfe das Internet-Peering (Bandbreite, Latenz) vom Provider deines Relays zu anderen Relays. Die Relays, die über Comcast übertragen werden, waren zeitweise langsam. Relays außerhalb Nordamerikas und Westeuropas sind in der Regel langsamer.

Tor-Netzwerk-Grenzwerte

Die Relay-Bandbreite kann durch die vom Relay selbst beobachtete Bandbreite oder durch die gemessene Bandbreite der Verzeichnisbehörden begrenzt werden. So findest du heraus, welche Messung dein Relay einschränkt:

  • Prüfe jede der Stimmen für dein Relay auf consensus-health (große Seite), und prüfe den Mittelwert. Wenn dein Relay von einigen Verzeichnisbehörden nicht als "Running" gekennzeichnet ist:
    • Hat es die falsche IPv4- oder IPv6-Adresse?
    • Ist seine IPv4- oder IPv6-Adresse von einigen Netzwerken aus unerreichbar?
    • Sind da mehr als 2 Relays auf seiner IPv4-Adresse?

Andernfalls überprüfe die von deinem Relay beobachtete Bandbreite und Bandbreitenrate (Limit). Schau dein Relay auf Metrics nach. Fahre dann mit der Maus über die Überschrift "Bandbreite", um die beobachtete Bandbreite und die Relay-Bandbreitenrate zu sehen.

Hier findest du weitere Details und einige Beispiele: Drop in consensus weight und Rampup speed of Exit relay.

Wie man es behebt

Die kleinste dieser Zahlen ist die Begrenzung der dem Relay zugewiesenen Bandbreite.

  • Wenn es an der Bandbreitenrate liegt, erhöhe die BandwidthRate/Burst oder RelayBandwidthRate/Burst in deiner torrc.
  • Wenn es sich um die beobachtete Bandbreite handelt, wird dein Relay nicht nach mehr Bandbreite fragen, bis es sieht, dass es selbst schneller wird. Du musst herausfinden, warum es langsam ist.
  • Wenn es sich um den Mittelwert der gemessenen Bandbreite handelt, sieht dein Relay aus Sicht der Mehrheit der Bandbreitenbehörden langsam aus. Du musst herausfinden, warum sie es langsam messen.

Eigene Relaymessungen durchführen

Wenn dein Relay meint, es sei langsam, oder die Bandbreitenbehörden meinen, es sei langsam, kannst du die Bandbreite selbst testen:

  • Führe einen Test mit Tor durch, um zu sehen, wie schnell Tor mit deinem/r Netzwerk/CPU werden kann.
  • Führe einen Test mit Tor und Chutney durch, um herauszufinden, wie schnell Tor mit deiner CPU werden kann. Erhöhe die Datenmenge so lange, bis die Bandbreite nicht mehr steigt.

Wenn du Exit-Verbindungen zulässt, werden einige Dienste, zu denen sich Personen von deinem Relay aus verbinden, eine Rückverbindung herstellen, um weitere Informationen über dich zu sammeln. Beispielsweise stellen einige IRC-Server eine Rückverbindung zu deinem identd-Anschluss her, um aufzuzeichnen, welcher Benutzer die Verbindung hergestellt hat. (Das funktioniert bei ihnen nicht wirklich, da Tor diese Informationen nicht kennt, aber sie versuchen es trotzdem). Außerdem könnten Benutzer, die von dir ausgehen, die Aufmerksamkeit anderer Benutzer auf dem IRC-Server, der Website usw. erregen, die mehr über den Host wissen wollen, über den sie die Verbindung weiterleiten.

Ein weiterer Grund ist, dass Gruppen, die im Internet nach offenen Proxies suchen, gelernt haben, dass manchmal Tor-Relays ihren Socks-Anschluss der Welt preisgeben. Wir empfehlen dir, deinen Socks-Anschluss nur an lokale Netzwerke zu binden.

In jedem Fall musst du über deine Sicherheit auf dem Laufenden bleiben. Siehe diesen Artikel über Sicherheit für Tor-Relays für weitere Vorschläge.

  • Das Exit-Relay ist der am meisten benötigte Relay-Typ, aber es ist auch mit der höchsten rechtlichen Gefahr und dem höchsten Risiko verbunden (und du solltest es NICHT von zu Hause aus betreiben).
  • Wenn du ein Relay mit minimalem Aufwand betreiben möchtest, sind auch schnelle Schutz-Relays sehr nützlich
  • Gefolgt von Brücken.

Wenn ein Exit fehlkonfiguriert oder böswillig ist, erhält es die BadExit-Markierung. Dies weist Tor an, den Ausgang über dieses Relay zu vermeiden. Tatsächlich werden Relays mit dieser Markierung zu Nicht-Exits. Wenn du diese Markierung erhalten hast, haben wir entweder ein Problem oder eine verdächtige Aktivität entdeckt, als wir den Verkehr durch dein Exit geleitet haben, und waren nicht in der Lage, dich zu kontaktieren. Bitte wende dich an das Bad Relays-Team, damit wir das Problem klären können.

Wenn du dein Tor-Relay aktualisierst oder auf einen anderen Computer umziehst, ist es wichtig, die gleichen Identitätsschlüssel zu behalten (gespeichert in "keys/ed25519_master_id_secret_key" und "keys/secret_id_key" in deinem DataDirectory). Sicherungen der Identitätsschlüssel aufzubewahren, damit du in Zukunft ein Relay wiederherstellen kannst, ist der empfohlene Weg, um sicherzustellen, dass der Ruf des Relays nicht leidet.

Das bedeutet, dass wenn du dein Tor-Relay aktualisierst und du das gleiche torrc und das gleiche DataDirectory behältst, dann sollte die Aktualisierung einfach funktionieren und dein Relay wird weiterhin den gleichen Schlüssel verwenden. Wenn du ein neues DataDirectory auswählen musst, kopiere unbedingt deine alten keys/ed25519_master_id_secret_key und keys/secret_id_key rüber.

Hinweis: Ab Tor 0.2.7 verwenden wir Identitäten der neuen Generation für Relays, die auf der ed25519-Verschlüsselung mit elliptischen Kurven basieren. Letztendlich werden sie die alten RSA-Identitäten ersetzen, aber das wird mit der Zeit geschehen, um die Kompatibilität mit älteren Versionen zu gewährleisten. Bis dahin wird jedes Relay sowohl eine ed25519-Identität (Identitätsschlüsseldatei: keys/ed25519_master_id_secret_key) als auch eine RSA-Identität (Identitätsschlüsseldatei: keys/secret_id_key) haben. Du musst beide kopieren / sichern, um dein Relay wiederherzustellen, dein DataDirectory zu ändern oder das Relay auf einen neuen Computer zu migrieren.

Wir suchen Personen mit einigermaßen zuverlässigen Internetverbindungen, die über eine verfügbare Bandbreite von mindestens 10 Mbit/s (Mbps) in jeder Richtung verfügen. Wenn du das bist, ziehe bitte in Betracht ein Tor-Relay zu betreiben.

Selbst wenn du nicht mindestens 10 Mbit/s an verfügbarer Bandbreite hast, kannst du dem Tor-Netzwerk helfen, indem du eine Tor-Brücke mit obfs4-Unterstützung betreibst. In diesem Fall solltest du mindestens 1 MBit/s an verfügbarer Bandbreite haben.

Du kannst ein Relay in Windows mit Hilfe dieser Tutorials starten:

Du solltest nur dann ein Windows-Relay betreiben, wenn du es rund um die Uhr betreiben kannst. Wenn du das nicht garantieren kannst, ist Snowflake ein besserer Weg, um deine Ressourcen zum Tor-Netzwerk beizutragen.

Du hast Recht, in den meisten Fällen bedeutet ein Byte in dein Tor-Relay ein Byte heraus und umgekehrt. Aber es gibt ein paar Ausnahmen:

Wenn du dein DirPort öffnest, werden dich die Tor-Programme nach einer Kopie des Verzeichnisses fragen. Die Anforderung, die sie stellen (ein HTTP GET), ist ziemlich klein, und die Antwort ist manchmal ziemlich groß. Dies macht wahrscheinlich den größten Teil des Unterschieds zwischen deiner "schreibenden" und deiner "lesenden" Byte-Zahl aus.

Eine weitere kleine Ausnahme tritt auf, wenn du einen Exit-Knoten betreibst und du ein paar Bytes aus einer Exit-Verbindung (z.B. einer Instant-Sofortnachrichten- oder ssh-Verbindung) liest und sie in eine ganze 512-Byte-Zelle für den Transport durch das Tor-Netzwerk einpackst.

Hier sind ein paar Tipps falls dein Tor Relay zu viel Arbeitsspeicher verbraucht:

  • Wenn du unter Linux arbeitest, wirst du möglicherweise auf Speicherfragmentierungsfehler in der malloc-Implementierung der glibc stoßen. Das heißt, wenn Tor Speicher an das System zurückgibt, werden die Speicherstücke fragmentiert, so dass sie schwer wiederzuverwenden sind. Tarball von Tor wird mit der malloc-Implementierung von OpenBSD ausgeliefert, die nicht so viele Fragmentierungsfehler hat (aber der Kompromiss ist eine höhere CPU-Last). Du kannst Tor anweisen, stattdessen diese malloc-Implementierung zu verwenden: ./configure --enable-openbsd-malloc.
  • Wenn du ein schnelles Relay betreibst, was bedeutet, dass du viele TLS-Verbindungen offen hast, verlierst du wahrscheinlich eine Menge Speicher in den internen Puffern von OpenSSL (38KB+ pro socket). Wir haben OpenSSL gepatcht, um unbenutzten Pufferspeicher verstärkt freizugeben. Wenn du auf OpenSSL 1.0.0 oder neuer aktualisierst, wird Tors Erstellungsprozess diese Funktion automatisch erkennen und nutzen.
  • Wenn du die Speicherlast immer noch nicht bewältigen kannst, ziehe in Betracht, die von deinem Relay angebotene Bandbreite zu reduzieren. Weniger Bandbreite anzubieten bedeutet, dass du weniger Benutzer anziehen wirst, so dass dein Relay nicht so groß werden sollte. Siehe die Option MaxAdvertisedBandwidth in der Handbuchseite.

Abgesehen davon verbrauchen schnelle Tor-Relays sehr viel Ram. Es ist nicht ungewöhnlich, dass ein schnelles Exit-Relay 500-1000 MB Speicher verbraucht.

Unser Ziel ist es die EInrichtung eines Tor Relays möglichst einfach zu machen:

  • Es ist in Ordnung wenn der Relay manchmal offline ist. Die Verzeichnisse merken das schnell und stellen keine Verbindungen mehr zu dem Relay her. Beachte nur, dass es nicht zu oft passiert, weil jedesmal die Verbindung die über den Relay läuft abbricht.
  • Jedes Tor-Relay hat eine Exit-Richtlinie die genau festlegt, welche Ausgansverbindungen auf dem Relay erlaubt oder verboten sind. Wenn du dir nicht sicher bist ob du einen Exit Relay betreiben möchtest, solltest du Verbindunge nur zu anderen Tor Relays erlauben.
  • Dein Relay schätzt die Bandbreitenkapazität und tauscht diese mit dem Tor Netzwerk aus. Relays mit hoher Bandbreite ziehen mehr Benutzer an. Trotzdem sind auch Relays mit geringer Bandbreite nützlich.

Bei der Relay-Suche zeigen wir einen gelben Punkt neben dem Relay-Spitznamen an, wenn dieser überlastet ist. Dies bedeutet, dass eine oder mehrere der folgenden Lastkennzahlen ausgelöst wurden:

  • Jeder Tor-OOM-Aufruf aufgrund von Speicherdruck
  • Jede ntor Onionskin wird verworfen
  • TCP Port-Ausschöpfung
  • DNS Zeitüberschreitung erreicht

Wenn ein Relay einen überlasteten Zustand erreicht, zeigen wir dies 72 Stunden lang an, nachdem sich das Relay erholt hat.

Wenn du feststellst, dass dein Relay überlastet ist, bitte:

1. Überprüfe https://status.torproject.org/ auf alle bekannten Probleme in der Kategorie "Tor-Netzwerk".

2. Denk dran, sysctl für dein System auf Netzwerk-, Speicher- und CPU-Last einzustellen.

Wenn die TCP-Ports ausgeschöpft sind, solltest du deinen lokalen Portbereich erweitern

‪sysctl -w net.ipv4.ip_local_port_range="15000 64000"

oder

echo 15000 64000 > /proc/sys/net/ipv4/ip_local_port_range

Wenn DNS-Zeitüberschreitungen auftreten, solltest du untersuchen, ob es sich um ein Netzwerk- oder ein Resolver-Problem handelt.

Unter Linux gibt es in der Datei resolve.conf eine Option, um eine Zeitüberschreitung festzulegen:

timeout:n
  Legt die Zeitspanne fest, die der Resolver auf eine Antwort von einem entfernten
  Nameserver wartet, bevor er die Abfrage über einen anderen Nameserver erneut versucht.
  Dies ist nicht unbedingt die Gesamtzeit, die für einen Resolver-API-Aufruf benötigt wird, und es gibt keine Garantie
  dass ein einzelner Resolver-API-Aufruf einem einzelnen Timeout entspricht.
  Gemessen in Sekunden, ist die Voreinstellung RES_TIMEOUT (derzeit 5, siehe <resolv.h>).
  Der Wert für diese Option wird stillschweigend auf 30 begrenzt.

Siehe $ man resolve.conf für weitere Informationen.

3. Consider enabling MetricsPort to understand what is happening.

MetricsPort data for relays has been introduced since version >= 0.4.7.1-alpha, while the overload data has been added to the relay descriptors since 0.4.6+.

Es ist wichtig zu verstehen, dass die Veröffentlichung von Tor-Lastkennzahlen für die Nutzer des Tor-Netzwerks gefährlich ist. Bitte sei beim Öffnen dieses Anschlusses besonders vorsichtig und umsichtig. Lege eine sehr strenge Zugriffsrichtlinie mit MetricsPortPolicy fest und erwäge die Verwendung der Firewall-Funktionen deines Betriebssystems für eine umfassende Verteidigung.

Hier ist ein Beispiel für die Ausgabe, die das Aktivieren von MetricsPort erzeugen wird:

‪# HELP tor_relay_load_onionskins_total Total number of onionskins handled
‪# TYPE tor_relay_load_onionskins_total counter
tor_relay_load_onionskins_total{type="tap",action="processed"} 0
tor_relay_load_onionskins_total{type="tap",action="dropped"} 0
tor_relay_load_onionskins_total{type="fast",action="processed"} 0
tor_relay_load_onionskins_total{type="fast",action="dropped"} 0
tor_relay_load_onionskins_total{type="ntor",action="processed"} 0
tor_relay_load_onionskins_total{type="ntor",action="dropped"} 0
‪# HELP tor_relay_exit_dns_query_total Total number of DNS queries done by this relay
‪# TYPE tor_relay_exit_dns_query_total counter
tor_relay_exit_dns_query_total{record="A"} 0
tor_relay_exit_dns_query_total{record="PTR"} 0
tor_relay_exit_dns_query_total{record="AAAA"} 0
‪# HELP tor_relay_exit_dns_error_total Total number of DNS errors encountered by this relay
‪# TYPE tor_relay_exit_dns_error_total counter
tor_relay_exit_dns_error_total{record="A",reason="success"} 0
tor_relay_exit_dns_error_total{record="A",reason="format"} 0
tor_relay_exit_dns_error_total{record="A",reason="serverfailed"} 0
tor_relay_exit_dns_error_total{record="A",reason="notexist"} 0
tor_relay_exit_dns_error_total{record="A",reason="notimpl"} 0
tor_relay_exit_dns_error_total{record="A",reason="refused"} 0
tor_relay_exit_dns_error_total{record="A",reason="truncated"} 0
tor_relay_exit_dns_error_total{record="A",reason="unknown"} 0
tor_relay_exit_dns_error_total{record="A",reason="timeout"} 0
tor_relay_exit_dns_error_total{record="A",reason="shutdown"} 0
tor_relay_exit_dns_error_total{record="A",reason="cancel"} 0
tor_relay_exit_dns_error_total{record="A",reason="nodata"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="success"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="format"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="serverfailed"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="notexist"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="notimpl"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="refused"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="truncated"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="unknown"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="timeout"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="shutdown"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="cancel"} 0
tor_relay_exit_dns_error_total{record="PTR",reason="nodata"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="success"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="format"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="serverfailed"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="notexist"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="notimpl"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="refused"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="truncated"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="unknown"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="timeout"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="shutdown"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="cancel"} 0
tor_relay_exit_dns_error_total{record="AAAA",reason="nodata"} 0
‪# HELP tor_relay_load_tcp_exhaustion_total Total number of times we ran out of TCP ports
‪# TYPE tor_relay_load_tcp_exhaustion_total counter
tor_relay_load_tcp_exhaustion_total 0
‪# HELP tor_relay_load_socket_total Total number of sockets
‪# TYPE tor_relay_load_socket_total gauge
tor_relay_load_socket_total{state="opened"} 135
tor_relay_load_socket_total 1048544
‪# HELP tor_relay_load_oom_bytes_total Total number of bytes the OOM has freed by subsystem
‪# TYPE tor_relay_load_oom_bytes_total counter
tor_relay_load_oom_bytes_total{subsys="cell"} 0
tor_relay_load_oom_bytes_total{subsys="dns"} 0
tor_relay_load_oom_bytes_total{subsys="geoip"} 0
tor_relay_load_oom_bytes_total{subsys="hsdir"} 0
‪# HELP tor_relay_load_global_rate_limit_reached_total Total number of global connection bucket limit reached
‪# TYPE tor_relay_load_global_rate_limit_reached_total counter
tor_relay_load_global_rate_limit_reached_total{side="read"} 0
tor_relay_load_global_rate_limit_reached_total{side="write"} 0

Lass uns herausfinden, was einige dieser Zeilen tatsächlich bedeuten:

tor_relay_load_onionskins_total{type="ntor",action="dropped"} 0

Wenn ein Relay anfängt "dropped" zu sehen, handelt es sich in der Regel um ein CPU/RAM-Problem.

Tor is sadly single threaded except for when the "onion skins" are processed. The "onion skins" are the cryptographic work that needs to be done on the famous "onion layers" in every circuits.

When tor processes the layers we use a thread pool and outsource all of that work to that pool. It can happen that this pool starts dropping work due to memory or CPU pressure and this will trigger an overload state.

If your server is running at capacity this will likely be triggered.

tor_relay_exit_dns_error_total{...}

Jeder Zahlenwert im Bereich "*_dns_error_total" weist auf ein DNS-Problem hin.

DNS timeouts issues only apply to Exit nodes. If tor starts noticing DNS timeouts, you'll get the overload flag. This might not be because your relay is overloaded in terms of resources but it signals a problem on the network.

DNS timeouts at the Exits are a huge UX problem for tor users. Therefore Exit operators really need to address these issues to help the network.

tor_relay_load_oom_bytes_total{...}

An Out-Of-Memory invocation indicates a RAM problem. Möglicherweise benötigt das Relay mehr RAM oder es treten Speicherverluste auf. Wenn du feststellst, dass der Tor-Prozess Speicherverluste hat, melde das Problem bitte entweder über GitLab oder schicke eine E-Mail an die Tor-Relays Mailingliste.

Tor has its own OOM handler and it is invoked when 75%, of the total memory tor thinks is available, is reached. Thus, let say tor thinks it can use 2GB in total then at 1.5GB of memory usage, it will start freeing memory. That is considered an overload state.

To estimate the amount of memory it has available, when tor starts, it will use MaxMemInQueues or, if not set, will look at the total RAM available on the system and apply this algorithm:

    if RAM >= 8GB {
      memory = RAM * 40%
    } else {
      memory = RAM * 75%
    }
    /* Capped. */
    memory = min(memory, 8GB) -> [8GB on 64bit and 2GB on 32bit)
    /* Minimum value. */
    memory = max(250MB, memory)

To avoid an overloaded state we recommend to run a relay above 2GB of RAM on 64bit. 4GB is advised, although of course it doesn't hurt to add more RAM if you can.

One might notice that tor could be called by the OS OOM handler itself. Because tor takes the total memory on the system when it starts, if the overall system has many other applications running using RAM, it ends up eating too much memory. In this case the OS could OOM tor, without tor even noticing memory pressure.

tor_relay_load_socket_total


tor_relay_load_tcp_exhaustion_total

Diese Zeilen zeigen an, dass das Relay keine Sockets oder TCP-Ports mehr hat. Wenn das Problem mit dem Socket zusammenhängt, ist die Lösung, ulimit -n für den Tor-Prozess zu erhöhen

Wenn die Lösung mit der Ausschöpfung der TCP-Ports zusammenhängt, versuche sysctl wie oben beschrieben einzustellen.

tor_relay_load_global_rate_limit_reached_total

Wenn dieser Zähler über einen kurzen Zeitraum um einen merklichen Wert ansteigt, bedeutet dies, dass das Relay überlastet ist. Es wird wahrscheinlich von einem großen Onion-Dienst als Schutz verwendet oder für ein laufendes DDoS im Netzwerk.

Wenn dein Relay immer noch überlastet ist und du nicht weißt, warum, wende dich bitte an network-report@torproject.org. Du kannst deine E-Mail mit Network-Report verschlüsseln OpenPGP key.

If you're using Debian or Ubuntu especially, there are a number of benefits to installing Tor from the Tor Project's repository.

  • Dein ulimit -n wird auf 32768 gesetzt. Genug um alle Verbindungen offen zu halten, die Tor verwendet.
  • Weil extra ein Nutzerprofil nur für Tor erstellt wird muss Tor nicht als root ausgeführt werden.
  • Ein init Skript ist eingebaut, damit Tor sofort läuft.
  • Tor funktioniert mit --verify-config, sodass die meisten Probleme mit deiner Konfigurationsdatei erkannt werden.
  • Tor kann sich an Low-Level-Anschlüsse binden und dann Privilegien ablegen.

Alle ausgehenden Verbindungen müssen erlaubt sein, sodass jeder Relay mit den anderen Relays kommunizieren kann.

In vielen Rechtssystemen sind Tor Relay Betreiber rechtlich durch die gleichen Bestimmungen geschützt, die verhindern, dass Provider für Inhalte Dritter, die durch ihr Netzwerk laufen, haftbar gemacht werden können. Exit Relays die einen Teil des Datenverkehrs filtern verlieren möglicherweise diesen Schutz.

Tor fördert den freien Netzwerkzugang. Exit Relays müssen den Datenverkehr der über sie ins Internet läuft nicht filtern. Wenn wir entdecken, dass ein Exit Relay den Datenverkehr filtert, bekommt er von uns das BadExit flag.

Nein. Wenn sich Strafverfolgungsbehörden für Verbindungen von einem Austrittsknoten interessieren, kann es vorkommen, dass der Computer beschlagnahmt wird. Aus diesem Grund ist es nicht zu empfehlen, einen Austritts-Knoten von zu Hause zu betreiben.

Verwende für einen Ausgangs-Knoten stattdessen eine kommerzielle Einrichtung, die Tor unterstützt. Benutze eine eigene IP-Adresse für jeden Austrittsknoten und benutze ihn nicht für eigene Verbindungen. Selbstverständlich solltest du es vermeiden, sensitive persönliche Informationen auf dem Computer des Exit-Relays zu speichern.

Schau dir unser obfs4 setup guide um mehr über das Betreiben einer obfs4 bridge zu lernen.

  • Benutze keine Pakete in Ubuntu-Quellen. Diese werden nicht verlässlich aktualisiert. Wenn du sie benutzt, wirst du wichtige Stabilitäts- und Sicherheits-Fehlerkorrekturen verpassen.
  • Ermittle deine Ubuntu-Version mit folgendem Befehl:
     ‪$ lsb_release -c
    
  • Füge als root die folgenden Zeilen zu /etc/apt/sources.list hinzu. Ersetze "Version" durch die Version, die du im vorherigen Schritt gefunden hast:
     deb https://deb.torproject.org/torproject.org version main
     deb-src https://deb.torproject.org/torproject.org version main
    
  • Füge den GPG-Schlüssel, der zum Signieren des Pakets verwendet wurde, mit folgendem Befehl hinzu:
     ‪$ curl https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | sudo apt-key add -
    
  • Führe folgenden Befehl aus, um Tor zu installieren und die Signaturen zu überprüfen:
     ‪$ sudo apt-get update
     ‪$ sudo apt-get install tor deb.torproject.org-keyring
    

Die ausführlichsten Informationen zum Betreiben eines Relays findest im Relay Setup Guide.

In einfachen Worten funktioniert es so:

  • Es gibt eine master ed25519 identity secret key Datei "ed25519_master_id_secret_key". Das ist das wichtigste, daher solltest du ein Backup machen und die Datei an einem sicheren Ort aufbewahren. Tor kann es für dich entschlüsseln wenn du es manuell erzeugst (wenn gefragt gib ein Passwort ein).
  • Ein medium term signing key ist "ed25519_signing_secret_key", der für Tor gerneriert wird. Ebenso wird ein Zertifikat erstellt "ed25519_signing_cert", dass von dem master identity secret key signiert wird und sicherstellt, dass der medium term signing key für einen bestimmten Zeitraum validiert ist. Die standardmäßige Gültigkeit beträgt 30 Tage. Das kann in der torrc Datei angepasst werden mit "SigningKeyLifetime N days|weeks|months".
  • Es gibt auch einen primären öffentlichen Schlüssel mit dem Namen "ed25519_master_id_public_key", der die tatsächliche Identität des im Netzwerk beworbenen Relays darstellt. Dieser ist nicht empfindlich und kann aus dem "ed5519_master_id_secret_key" errechnet werden.

Tor benötigt nur Zugriff auf den mittelfristigen Signierschlüssel und das Zertifikat, solange sie gültig sind, so dass der private Hauptidentitätsschlüssel außerhalb von DataDirectory/keys, auf einem Speichermedium oder einem anderen Computer aufbewahrt werden kann. Du musst den medium term signing key und das Zertifikat manuell erneuern bevor es ausläuft, sonst wird der Tor Prozess nach Ablauf auf dem Relay beendet.

Diese Funktion ist optional, du brauchst sie nicht zu benutzen, es sei denn, du möchtest es. Wenn du möchtest, dass dein Relay für längere Zeit unbeaufsichtigt läuft, ohne dass du die Erneuerung des mittelfristigen Signaturschlüssels regelmäßig manuell durchführen musst, lässt du am besten den privaten Hauptidentitätsschlüssel in DataDirectory/keys, mach einfach eine Datensicherung für den Fall, dass du ihn neu installieren musst. Wenn du diese Funktion nutzen möchtest, kannst du den detaillierteren Guide lesen.

Da es jetzt ein Schutz ist, wird es von Programmen weniger in anderen Positionen benutzt, aber bisher haben noch nicht viele Programme ihre bestehenden Schutze ausgewechselt, um es als Schutz zu benutzen. Lese mehr Details in diesem Blogpost oder in Changing of the Guards: A Framework for Understanding and Improving Entry Guard Selection in Tor.

Großartig. Wenn du mehrere Relays betreiben willst um das Netzwerk noch besser zu unterstützen freut uns das. Bitte betreibe nicht mehr als ein paar Dutzend im gleichen Netzwerk, denn Teil des Ziels des Tor Netzwerks ist es dezentral und vielfältig zu sein.

Wenn du dich dazu entscheidest mehr als einen Relay zu betreiben, dann verändere bitte die "MyFamily" Konfiguration Option in der torrc Datei bei jedem Relay. Liste alle Relays (durch Komma getrennt) die unter deiner Kontrolle stehen auf:

MyFamily $fingerprint1,$fingerprint2,$fingerprint3

wo jeder Fingerabdruck der 40 Zeichen Fingerabdruck ist (ohne Leerzeichen)

Dadurch wissen Tor Clients welche Relays zusammen gehören und können so vermeiden, dass sie nicht mehr als einen deiner Relays zusammen verwenden. Du solltest MyFamily für deine Relays einstellen wenn du Kontrolle über den Computer und/oder das Netzwerk hast. Auch wenn die Relays über verschiedene Provider und Standorte verteilt sind.

Die accounting Option in der torrc Datei ermöglichen es ihnen die maximale Menge an Bytes die in einer bestimmten Zeitspanne verwendet werden anzugeben.

    AccountingStart day week month [day] HH:MM

Hier wird angegeben, wann die Abrechnung zurückgesetzt werden soll. Um beispielsweise eine Gesamtzahl von Bytes einzustellen, die in einer Woche übertragen werden darf (und die jeden Mittwoch um 10:00 Uhr zurückgesetzt wird), würdest du Folgendes verwenden:

    AccountingStart week 3 10:00
    AccountingMax 500 GBytes

Dies gibt die maximale Datenmenge an die ihr Relay während einer Abrechnungsperiode senden/verwenden darf. Wenn der Abrechnungszeitraum vorbei ist (von AccountingStart), wird der Zähler für AccountingMax auf 0 gesetzt.

Beispiel: Du möchtest jeden Tag 50 GB Traffic erlauben und die Abrechnung setzt sich jeden nachmittag zurück:

    AccountingStart day 12:00
    AccountingMax 50 GBytes

Beachte, dass dein Relay nicht genau zu Beginn des Abrechnungszeitraumes starten wird. Es wird gespeichert, wie schnell dein Relay seine maximale Bandbreite ausgeschöpft hat und dann wird ein neuer zufälliger Zeitpunkt in dem neuen Zeitraum gewählt, wann der Relay startet. Dadurch verhindern wir, dass nicht hunderte Relays Ende des Monats ihren Betrieb einstellen.

Wenn du im Vergleich zu deiner Verbindungsgeschwindigkeit nur eine kleine Menge an Bandbreite zu spenden hast, empfehlen wir dir eine tägliche Abrechnung, damit du nicht am ersten Tag dein gesamtes monatliches Kontingent verbrauchst. Teilen sie einfach ihr monatliches Volumen durch 30. Sie können auch die Bandbreite begrenzen um ihren Beitrag am Tor Netzwerk über den ganzen Tag zu verteilen: Wenn sie X GB in jede Richtung anbieten wollen, dann begrenzen sie die RelayBandwidthRate für ihren Relay auf 20*X KBytes. Wenn sie zum Beispiel 50 GB Volumen in jede Richtung haben, dann setzten sie die RelayBandwidthRate ihres Relays auf 1000 KBytes: Dadurch ist ihr Relay immer für mindestens die Hälfte des Tages nützlich.

    AccountingStart day 0:00
    AccountingMax 50 GBytes
    RelayBandwidthRate 1000 KBytes
    RelayBandwidthBurst 5000 KBytes # erlaube höhere Bursts behalte aber den Durchschnit bei

Tor has partial support for IPv6 and we encourage every relay operator to enable IPv6 functionality in their torrc configuration files when IPv6 connectivity is available. Momentan setzt Tor IPv4 Adressen auf den Relays voraus. Es ist nicht möglich einen Tor Relay auf einem Server nur mit IPv6 Adressen zu betreiben.

Die Werte die in AccountingMax und BandwidthRate festgelegt werden gelten sowohl für Client als auch die Übermittlungsfunktion von Tor. Deshalb kann es sein, dass du nicht mehr surfen kannst sobald dein Tor im Ruhezustnad ist. Dann steht folgendes im Protokoll:

Variable Bandbreitengrenze erreicht; Beginn des Ruhezustands.
Es werden keine neuen Verbindungen angenommen

Die Lösung ist es zwei Tor Prozesse laufen zu lassen - einen Relay und einen Client, jeder mit passender Konfiguration. Eine Möglichkeit es zu machen (wenn du mit einem laufenden Relay Setup beginnst) ist wie folgt:

  • In der Relay Tor torrc Datei, setze einfach den SocksPort auf 0.
  • Erstelle eine neue torrc Datei aus dem torrc,beispiel und stelle sicher, dass sie eine andere Datei als das Relay verwenden. Ein Name könnte torrc.client oder torrc.relay sein.
  • Fügen sie -f /path/to/correct/torrc in die Startskripte des Clients und des Relays ein.
  • Die Veränderung der Startskripte zu Tor.client und Tor.relay in Linux/BSD/Mac OS X kann die Trennung der config erleichtern.

Großartig. Genau deshalb haben wir exit Policies eingebaut.

Jeder Tor Relay hat eine exit policy, die festlegt welche Art von ausgehender Verbindungen zugelassen oder abgelehnt werden. Über das Verzeichnis sieht Tor die exit policies der Relays und sorgt so dafür, dass die Clients keine exit Relays wählen, die die Verbindung zu ihrem Ziel verhindern würden. Dadurch kann jeder Relay entscheiden, zu welchen Services und Netzwerken er sich verbinden will, basierend auf dem Missbrauchspotential und seiner eigenen Situation. Read the Support entry on issues you might encounter if you use the default exit policy, and then read Mike Perry's tips for running an exit node with minimal harassment.

Die standardmäßigen Exit Richtlinien (z.B. Internetsurfen) erlauben den Zugriff auf viele bekannte Dienste aber unterbinden manche wegen Missbrauchspotential (z.B. E-Mail) und manche weil das Tor Netzwerk die Bandbreite nicht verarbeiten kann (z.B. Dateisharing). Du kannst deine Exit Richtlinien in deiner torrc Datei festlegen. Wenn du du das meiste wenn nicht sogar das ganze Missbrauchspotential vermeiden möchtest dann setze "reject :". ein. Diese Einstellung bedeutet, dass ihr Relay für die Übermittlung von Datenverkehr innerhalb des Tor Netzwerkes verwendet wird, aber nicht für Verbindungen zu externen Websiten oder anderen Diensten.

Wenn du alle Exit Verbindungen erlaubst, stelle sicher, dass die Namensauflösung funktioniert. Wenn dein Computer irgendwelche Ressourcen nicht erreichen kann (bspw. weil er sich hinter einer Firewall oder einem Inhaltsfilter befindet), solltest du diese explizit in deinen Exit Richtlinien verbieten, da sonst auch andere Tor Nutzer betroffen sind.

Tor kann Relays mit dynamischer IP-Adresse gut einbinden. Just leave the "Address" line in your torrc blank, and Tor will guess.

Die standardmäßig geöffneten Ports sind unten aufgelistet, aber bedenke, dass jeder Port oder Ports vom Relaybetreiber geöffnet werden können, indem er sie in torrc konfiguriert oder den Quellcode modifiziert. Die Voreinstellung gemäß src/or/policies.c (Zeile 85 und Zeile 1901) aus der Quellcodeversion Release-0.4.6:

reject 0.0.0.0/8
reject 169.254.0.0/16
reject 127.0.0.0/8
reject 192.168.0.0/16
reject 10.0.0.0/8
reject 172.16.0.0/12

reject *:25
reject *:119
reject *:135-139
reject *:445
reject *:563
reject *:1214
reject *:4661-4666
reject *:6346-6429
reject *:6699
reject *:6881-6999
accept *:*

BridgeDB implementiert vier Mechanismen, um Brücken zu verteilen: HTTPS, Moat, E-Mail und Reserviert. Brückenbetreiber können auf der Seite Relaysuche überprüfen, welchen Mechanismus ihre Brücke verwendet. Den <HASHED FINGERPRINT> der Brücke in der Eingabemaske eingeben und auf "Suchen" klicken.

Betreiber können auch wählen, welche Verteilungsmethode ihre Brücke verwendet. Um die Methode zu ändern, ändere die Einstellung BridgeDistribution in der torrc-Datei auf eine der folgenden: https, moat, email, none, any.

Weitere Informationen findest du in der Brücken-Nachinstallations-Anleitung.

Ja, deine Anonymität erhöht sich für manche Angriffe.

Das beste Beispiel ist ein Angreifer der eine kleine Anzahl Tor Relays betreibt. Sie sehen eine Verbindung von dir aber sie sehen nicht ob die Anfrage ursprünglich von dir oder von jemand anderem übermittelt wurde.

Es gibt einige Fälle in denen es nicht hilft: Wenn ein Angreifer ihren gesamten ein- und ausgehenden Verkehr beobachten kann, dann ist es sehr leicht für ihn zu sehen welche Verbindungen von Ihnen kommen und welche sie nur weiterleiten. (In diesem Fall wissen sie aber immer noch nicht dein Ziel, solange sie die nicht auch beobachten. Trotzdem wären bist du immer noch genauso unterwegs wie ein normaler Websitenbesucher.

Es gibt auch einige Nachteile beim betreiben eines Tor Relays. Anfangs, als wir nur ein paar hundert Relays hatten, konnte die Tatsache, dass sie einen betreiben einem Angreifer zeigen, dass sie großen Wert auf Anonymität legen. Zweitens gibt es einige esoterischere Angriffe, die nicht so gut verstanden oder erprobt sind, und bei denen man sich das Wissen zunutze macht, dass du ein Relay betreibst - zum Beispiel könnte ein Angreifer in der Lage sein, zu "beobachten", ob du Verkehr sendest, auch wenn er dein Netzwerk nicht wirklich überwachen kann, indem er Verkehr durch dein Tor-Relay weiterleitet und Änderungen im Verkehrs-Timing bemerkt.

Es ist noch unerforscht, ober der Nutzen die Risiken überwiegt. Das meiste hängt von den Angriffen ab, über die du dir am meisten Sorgen machst. Wir denken, dass das für die meisten Nutzer ein wichtiger Schritt ist.

Für eine Anleitung wie du mit deinem NAT/Router Anschlüsse weiterleiten kannst, lies dir portforward.com durch.

Wenn dein Relay in einem internen Netzwerk läuft, musst du die Anschlussweiterleitung einstellen. Forwarding TCP connections is system dependent but the firewalled-clients FAQ entry offers some examples on how to do this.

Hier ist ebenfalls ein Beispiel wie du es unter GNU/Linux machen solltest, wenn du iptables verwendest:

/sbin/iptables -A INPUT -i eth0 -p tcp --destination-port 9001 -j ACCEPT

Möglicherweise musst du "eth0" ändern, wenn du eine andere externe Schnitstelle hast (die, die mit dem Internet verbunde ist). Die Chancen stehen gut, dass du nur eins hast (mit Ausnahme des Loopbacks), also sollte es nicht allzu schwer sein, das herauszufinden.

Es gibt zwei Optionen die du in deine torrc Datei schreiben kannst:

BandwidthRate is die maximal erlaubte Bandbreite (bytes pro Sekunde). Du willst beispielsweise "BandwidthRate 10 MBytes" für 10 Megabyte pro Sekunde einstellen (eine schnelle Verbindung) oder "BandwidthRate 500 KBytes" für 500 Kilobytes pro Sekunde (eine gute Kabelverbindung). Die minmale Bandbreitenrate liegt bei 75 Kilobytes pro Sekunde.

BandwidthBurst ist ein Pool von Bytes, der verwendet wird, um Anfragen während kurzer Verkehrsperioden oberhalb von BandwidthRate zu erfüllen, aber dennoch den Durchschnitt über einen langen Zeitraum auf BandwidthRate hält. Eine langsame Bandbreite aber ein hoher Burst erzwingen einen langfristigen Durchschnitt, damit ungenutzte Bandbreite zu Spitzenzeiten genutzt werden kann. Wenn du beispielsweise "BandwidthBurst 500 KBytes" wählst und das auch für deine Bandbreitenrate benutzt, wirst du nie mehr als 500 Kilobytes pro Sekunde erreichen. Aber wenn du einen höheren Bandbreitenburst (z.B. 5 MBytes) nimmst, dann kann eine höhere Geschwindigkeit erreicht werden bis der Burst aufgebraucht ist.

Wenn du eine asymmetrische Verbindung hast (Upload geringer als Download), solltest du die Bandbreitenrate auf maximal die maximale Uploadrate setzen. Andernfalls könntest du in Zeiten maximaler Bandbreitennutzung viele Pakete verlieren - möglicherweise musst du experimentieren, welche Werte deine Verbindung komfortabel machen. Dann setze den Bandbreitenburst auf den selben Wert wie die Bandbreitenrate.

Tor Relays die auf Linux basieren haben eine weitere Option: Sie können den ihren persönlichen Verkehr priorisieren, sodass dieser nicht durch die Tor Last beeinträchtigt wird. Dafür gibt es ein Skript, das sich im Contrib-Verzeichnis der Tor-Quelldistribution befindet.

Es gibt zusätzliche Optionen, bei denen sie festlegen können, dass nur eine bestimmte Trafficmenge pro Zeitperiode (z.B. 100 GB pro Monat) verwendet werden.

Beachte, dass die Bandbreitenrate und der Bandbreitenburst in Bytes und nicht in Bits angegeben wird.