commit 82c05c5ebf85e170e485a62a9744f3c55ad821a4
Author: gus <[email protected]>
Date: Thu Jul 4 18:31:48 2019 -0400
Tor relay post-install and good practices
---
.../contents.lr | 175 +++++++++++++++++++++
1 file changed, 175 insertions(+)
diff --git
a/content/relay-operations/technical-setup/relays-post-install-and-good-practices/contents.lr
b/content/relay-operations/technical-setup/relays-post-install-and-good-practices/contents.lr
new file mode 100644
index 0000000..8373219
--- /dev/null
+++
b/content/relay-operations/technical-setup/relays-post-install-and-good-practices/contents.lr
@@ -0,0 +1,175 @@
+_model: page
+---
+title: Relay Post-install and good practices
+---
+body:
+
+#1. Make sure relay ports can be reached
+
+If you are using a firewall, open a hole in your firewall so incoming
connections can reach the ports you will use for your relay (ORPort, plus
DirPort if you enabled it).
+
+Also, make sure you allow all outgoing connections too, so your relay can
reach the other Tor relays, clients and destinations.
+
+You can find the specific ORPort TCP port number in the torrc configuration
samples bellow (in the OS specific sections).
+
+# 2. Verify that your relay works
+
+If your logfile (syslog) contains the following entry after starting your tor
daemon your relay should be up and running as expected:
+
+```
+Self-testing indicates your ORPort is reachable from the outside. Excellent.
+Publishing server descriptor.
+```
+
+About 3 hours after you started your relay it should appear on [Relay
Search](https://metrics.torproject.org/rs.html).
+You can search for your relay using your nickname or IP address.
+
+# 3. Read about Tor relay lifecycle
+
+It takes some time for relay traffic to ramp up, this is especially true for
guard relays but to a lesser extend also for exit relays. To understand this
process, read about the [lifecycle of a new
relay](https://blog.torproject.org/lifecycle-new-relay).
+
+
+#4. Optional: Limiting bandwidth usage (and traffic)
+
+Tor will not limit its bandwidth usage by default, but supports multiple ways
to restrict the used bandwidth and the amount of traffic.
+This can be handy if you want to ensure that your Tor relay does not exceed a
certain amount of bandwidth or total traffic per day/week/month.
+The following torrc configuration options can be used to restrict bandwidth
and traffic:
+
+* AccountingMax
+* AccountingRule
+* AccountingStart
+* BandwidthRate
+* BandwidthBurst
+* RelayBandwidthRate
+
+Having a fast relay for some time of the month is preferred over a slow relay
for the entire month.
+
+Also see the bandwidth entry in the FAQ:
https://www.torproject.org/docs/faq.html.en#BandwidthShaping
+
+# 5. Check IPv6 availability
+
+We encourage everyone to enable IPv6 on their relays. This is especially
valuable on exit and guard relays.
+
+Before enabling your tor daemon to use IPv6 in addition to IPv4 you should do
some basic IPv6 connectivity tests.
+
+The following command line will ping the IPv6 addresses of Tor directory
authorities from your server:
+
+```
+ping6 -c2 2001:858:2:2:aabb:0:563b:1526 && ping6 -c2
2620:13:4000:6000::1000:118 && ping6 -c2 2001:67c:289c::9 && ping6 -c2
2001:678:558:1000::244 && ping6 -c2 2607:8500:154::3 && ping6 -c2
2001:638:a000:4140::ffff:189 && echo OK.
+```
+
+At the end of the output you should see "OK." if that is not the case do not
enable IPv6 in your torrc configuration file before IPv6 is indeed working.
+If you enable IPv6 without working IPv6 connectivity your entire relay will
not be used, regardless if IPv4 is working.
+
+If it worked fine, make your Tor relay reachable via IPv6 by adding an
additional ORPort line to your configuration (example for ORPort 9001):
+
+```
+ORPort [IPv6-address]:9001
+```
+
+The location of that line in the configuration file does not matter you can
simply add it next to the first ORPort lins in your torrc file.
+
+Note: You have to explicitly specify your IPv6 address in square brackets, you
can not tell tor to bind to any IPv6 (like you do for IPv4).
+If you have a global IPv6 address you should be able to find it in the output
of the following command:
+
+```
+ip addr|grep inet6|grep global
+```
+
+If you are an exit relay with IPv6 connectivity, tell your tor daemon to allow
exiting via IPv6 so clients can reach IPv6 destinations:
+
+```
+IPv6Exit 1
+```
+
+Note: Tor requires IPv4 connectivity, you can not run a Tor relay on IPv6-only.
+
+# 6. Important: if you run more than one Tor instance
+
+To avoid putting Tor clients at risk when operating multiple relays you must
set a proper
[MyFamily](https://2019.www.torproject.org/docs/tor-manual.html.en#MyFamily)
value and have a valid
[ContactInfo](https://2019.www.torproject.org/docs/tor-manual.html.en#ContactInfo)
in your torrc configuration.
+The MyFamily setting is simply telling Tor clients what Tor relays are
controlled by a single entity/operator/organization, so they are not used in
multiple positions in a single circuit.
+
+If you run two relays and they have fingerprints AAAAAAAAAA and BBBBBBBB, you
would add the following configuration to set MyFamily:
+
+```
+MyFamily AAAAAAAAAA,BBBBBBBB
+```
+
+to both relays. To find your relays fingerprint you can look into the log
files when tor starts up or find the file named "fingerprint" in your tor
DataDirectory.
+
+Instead of doing so manually for big operators we recommend to automate the
MyFamily setting via a configuration management solution.
+Manually managing MyFamily for big relaygroups is error prone and can put Tor
clients at risk.
+
+
+# 7. Maintaining a relay
+
+## Backup Tor Identity Keys
+
+After your initial installation and start of the tor daemon it is a good idea
to make a backup of your relay's long term identity keys.
+They are located in the "keys" subfolder of your DataDirectory (simply make a
copy of the entire folder and store it in a secure location).
+Since relays have a ramp-up time it makes sense to backup the identity key to
be able to restore your relay's reputation after a disk failure - otherwise you
would have to go through the ramp-up phase again.
+
+Default locations of the keys folder:
+
+* Debian/Ubuntu: `/var/lib/tor/keys`
+* FreeBSD: `/var/db/tor/keys`
+
+## Subscribe to the tor-announce mailing list
+
+This is a very low traffic mailing list and you will get information about new
stable tor releases and important security update information.
+
+* https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-announce
+
+## Setting up outage notifications
+
+Once you setup your relay it will likely run without much work from your side.
+If something goes wrong it is good to get notified automatically.
+We recommend you use one of the free services that allow you to check your
relay's ORPorts for reachability and send you an email should they become
unreachable for what ever reason.
+
+[UptimeRobot](https://uptimerobot.com/) is one of these services that allow
you to monitor TCP listeners on arbitrary ports.
+This service can check your configured ports once every 5 minutes and send you
an email should your tor process die or become unreachable.
+This checks only for the listener but does not speak the Tor protocol.
+
+A good way to monitor a relay for its health state is to have a look at its
bandwidth graphs.
+
+## System Health Monitoring
+
+To ensure your relay is healthy and not overwhelmed it makes sense to have
some basic system monitoring in place to keep an eye on the following metrics:
+
+* Bandwidth
+* Established TCP Connections
+* Memory
+* Swap
+* CPU
+
+There are many tools for monitoring this kind of data,
[munin](http://munin-monitoring.org/) is one of them and is relatively easy to
setup.
+
+Note: **Do not make your private monitoring data graphs public since this
could help attackers with deanonymizing Tor users.**
+
+Some practical advice:
+
+* If you want to publish traffic statistics, you should aggregate all your
relays' traffic over at least a week, then round that to the nearest 10 TiB
(terabytes).
+* Reporting individual relays is worse than reporting totals for groups of
relays. In future, tor will securely aggregate bandwidth statistics, so any
individual relay bandwidth reporting will be less secure than tor's statistics.
+* Smaller periods are worse.
+* Numbers are worse than graphs.
+* Real-time data is worse than historical data.
+* Data in categories (IP version, in/out, etc.) is worse than total data.
+
+## Tools
+
+ This section lists a few tools that you might find handy as a Tor relay
operator.
+
+* [Nyx](https://nyx.torproject.org/): is a Tor Project tool (formerly arm)
that allows you to see real time data of your relay.
+
+* vnstat: vnstat is a command-line tool that shows the amount of data going
through your network connection.
+You can also use it to generate PNG pictures showing traffic graphs. [vnstat
documentation](https://humdi.net/vnstat/) and [demo
output](https://humdi.net/vnstat/cgidemo/).
+---
+html: two-columns-page.html
+---
+key: 4
+---
+section: Relay operations
+---
+section_id: relay-operations
+---
+subtitle:
_______________________________________________
tor-commits mailing list
[email protected]
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-commits
