💾 Archived View for perso.pw › blog › articles › tor-relay.gmi captured on 2021-12-04 at 18:04:22. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2021-12-03)

➡️ Next capture (2021-12-17)

-=-=-=-=-=-=-

Tor part 4: run a relay

on Mastodon

In this fourth Tor article, I will _quickly_ cover how to run a Tor relay, the

Tor project already have a very nice and up-to-date Guide for setting a relay.

Those relays are what make Tor usable, with more relay, Tor gets more bandwidth

and it makes you harder to trace, because that would mean more traffic to

analyze.

A relay server can be an **exit node**, which will relay Tor traffic to the

outside. This implies a lot of legal issues, the Tor project foundation offers

to help you if your exit node gets you in trouble.

Remember that being an exit node is **optional**. Most relays are not exit

nodes. They will either relay traffic between relays, or become a **guard**

which is an entry point to the Tor network. The guard gets the request over

non-tor network and send it to the next relay of the user circuit.

Running a relay requires a lot of CPU (capable of some crypto) and a huge

amount of bandwidth. Running a relay requires at least a bandwidth of 10Mb/s,

this is a minimal requirement. If you have less, you can still run a bridge

with obfs4 but I won't cover it here.

When running a relay, you will be able to set a daily/weekly/monthly traffic

limit, so your relay will stop relaying when it reach the quota. It's quiet

useful if you don't have unmeasured bandwidth, you can also limit the bandwidth

allowed to Tor.

To get real-time information about your relay, the software Nyx (net/nyx) is a

Tor top-like front end which show Tor CPU usage, bandwidth, connections, log in

real time.

[The awesome Official Tor guide](https://blog.torproject.org/new-guide-running-tor-relay)