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. Schau dir den Lebenszyklus eines Tor Relays an. 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] (https://blog.torproject.org/blog/lifecycle-of-a-new-relay) ausführlicher erläutert. Wenn du schon eine Weile ein Relay betreibst und immer noch Probleme hast, dann versuche auf der [Tor-Relays-Liste] (https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays/) nachzufragen.

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-Port 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] (https://trac.torproject.org/projects/tor/wiki/TorRelayGuide/Security) 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] (https://community.torproject.org/relay/community-resources/bad-relays/), 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] (https://community.torproject.org/relay/).

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] (https://community.torproject.org/relay/setup/bridge) betreibst. In diesem Fall solltest du mindestens 1 MBit/s an verfügbarer Bandbreite haben.

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] (https://lists.torproject.org/pipermail/tor-dev/2008-June/001519.html). 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.
  • Jeder Tor Relay hat eine exit policy 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.

Wenn du Debian oder Ubuntu verwendest hat es viele Vorteile Tor aus dem Tor Project's Repository zu installieren.

  • 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 die 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.

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

In einfachen Worten funktioniert es so:

  • There is a primary ed25519 identity secret key file named "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. Also, a certificate is generated named "ed25519_signing_cert" which is signed by the primary identity secret key and confirms that the medium term signing key is valid for a certain period of time. Die standardmäßige Gültigkeit beträgt 30 Tage. Das kann in der torrc Datei angepasst werden mit "SigningKeyLifetime N days|weeks|months".
  • There is also a primary public key named "ed25519_master_id_public_key, which is the actual identity of the relay advertised in the network. Dieser ist nicht empfindlich und kann aus dem "ed5519_master_id_secret_key" errechnet werden.

Tor will only need access to the medium term signing key and certificate as long as they are valid, so the primary identity secret key can be kept outside DataDirectory/keys, on a storage media or a different computer. 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. If you want your relay to run unattended for longer time without having to manually do the medium term signing key renewal on regular basis, best to leave the primary identity secret key in DataDirectory/keys, just make a backup in case you'll need to reinstall it. 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 bietet teilweise Unterstützung für IPv6 und wir ermutigen jeden Relay Betreiber IPv6 in seiner torrc Datei zu aktivieren wenn IPv6 verfügbar ist. 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. Lies den [Support-Eintrag zu Problemen, auf die du stoßen könntest] (https://support.torproject.org/abuse/exit-relay-expectations/), wenn du die standardmäßige Exit-Richtlinie verwendest, und lies dann Mike Perry's Tipps zum Betrieb eines Exit-Knotens mit minimaler Belästigung.

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 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. Lass die "Adress" Zeile in deiner torrc  Datei einfach frei und Tor wird sie erraten.

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 Ports weiterleiten kannst, lese dir portforward.com](https://portforward.com/) durch.

Wenn dein Relay in einem internen Netzwerk läuft, musst du die Portweiterleitung einstellen. Die Weiterleitung von TCP Verbindungen ist systemabhängig. Die Firewall Client FAQs zeigen wie es funktioniert.

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, dass 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.