mirror of
https://github.com/torproject/community.git
synced 2024-11-24 02:09:48 +00:00
better strings for l10n
This commit is contained in:
emma peel
parent
eb608718c2
commit
85f4edda01
@ -180,52 +180,41 @@ The following torrc configuration options can be used to restrict bandwidth and
|
||||
* BandwidthBurst
|
||||
* RelayBandwidthRate
|
||||
|
||||
Having a fast relay for some time of the month is preferred over a slow relay
|
||||
for the entire month.
|
||||
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
|
||||
|
||||
# IPv6
|
||||
|
||||
We encourage everyone to enable IPv6 on their relays. This is especially
|
||||
valuable on exit and guard relays.
|
||||
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.
|
||||
Before enabling your tor daemon to use IPv6 in addition to IPv4 you should do some basic IPv6 connectivity tests.
|
||||
|
||||
he following command line will ping the IPv6 addresses of Tor directory
|
||||
authorities from your server:
|
||||
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.
|
||||
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):
|
||||
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.
|
||||
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:
|
||||
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:
|
||||
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
|
||||
@ -235,59 +224,44 @@ Note: Tor requires IPv4 connectivity, you can not run a Tor relay on IPv6-only.
|
||||
|
||||
# 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 don't
|
||||
use them in multiple position in a single circuit.
|
||||
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:
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
||||
# Exit Relay Configuration
|
||||
|
||||
It is recommended that you setup exit relays on servers dedicated to this
|
||||
purpose. It is not recommended to install Tor exit relays on servers that you
|
||||
need for other services as well. Do not mix your own traffic with your exit
|
||||
relay traffic.
|
||||
It is recommended that you setup exit relays on servers dedicated to this purpose. It is not recommended to install Tor exit relays on servers that you need for other services as well.
|
||||
Do not mix your own traffic with your exit relay traffic.
|
||||
|
||||
## Reverse DNS and WHOIS record
|
||||
|
||||
Before switching your relay to become an exit relay, ensure that you have set a
|
||||
clear DNS reverse (PTR) record to make it clear for everyone that this is a tor
|
||||
exit relay. Something like "tor-exit" it its name is a good start.
|
||||
Before switching your relay to become an exit relay, ensure that you have set a clear DNS reverse (PTR) record to make it clear for everyone that this is a tor exit relay.
|
||||
Something like "tor-exit" it its name is a good start.
|
||||
|
||||
If your provider offers it, make sure your WHOIS record contains clear
|
||||
indications that this is a Tor exit relay.
|
||||
If your provider offers it, make sure your WHOIS record contains clear indications that this is a Tor exit relay.
|
||||
|
||||
## Exit Notice HTML page
|
||||
|
||||
To make it even more obvious that this is a Tor exit relay you should serve a
|
||||
Tor exit notice HTML page. Tor can do that for you if your DirPort is on TCP
|
||||
port 80, you can make use of tor's DirPortFrontPage feature to display a
|
||||
HTML file on that port. This file will be shown to anyone directing his browser
|
||||
to your Tor exit relay IP address.
|
||||
To make it even more obvious that this is a Tor exit relay you should serve a Tor exit notice HTML page.
|
||||
Tor can do that for you if your DirPort is on TCP port 80, you can make use of tor's DirPortFrontPage feature to display a HTML file on that port.
|
||||
This file will be shown to anyone directing his browser to your Tor exit relay IP address.
|
||||
|
||||
```
|
||||
DirPort 80
|
||||
DirPortFrontPage /path/to/html/file
|
||||
```
|
||||
|
||||
We offer a sample Tor exit notice HTML file, but you might want to adjust it to
|
||||
your needs:
|
||||
We offer a sample Tor exit notice HTML file, but you might want to adjust it to your needs:
|
||||
https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-exit-notice.html
|
||||
|
||||
Here are some more tips for running a reliable exit relay:
|
||||
@ -295,24 +269,15 @@ https://blog.torproject.org/tips-running-exit-node
|
||||
|
||||
## Exit Policy
|
||||
|
||||
Defining the [exit
|
||||
policy](https://www.torproject.org/docs/tor-manual.html.en#ExitPolicy)
|
||||
is one of the most important parts of an exit relay configuration. The exit
|
||||
policy defines which destination ports you are willing to forward. This has an
|
||||
impact on the amount of abuse emails you will get (less ports means less abuse
|
||||
emails, but an exit relay allowing only few ports is also less useful). If you
|
||||
want to be a useful exit relay you must **at least allow destination ports 80
|
||||
and 443**.
|
||||
Defining the [exit policy](https://www.torproject.org/docs/tor-manual.html.en#ExitPolicy) is one of the most important parts of an exit relay configuration.
|
||||
The exit policy defines which destination ports you are willing to forward.
|
||||
This has an impact on the amount of abuse emails you will get (less ports means less abuse emails, but an exit relay allowing only few ports is also less useful).
|
||||
If you want to be a useful exit relay you must **at least allow destination ports 80 and 443**.
|
||||
|
||||
As a new exit relay - especially if you are new to your hoster - it is good to
|
||||
start with a reduced exit policy (to reduce the amount of abuse emails) and
|
||||
further open it up as you become more experienced. The reduced exit policy can
|
||||
be found on the
|
||||
[ReducedExitPolicy](https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy)
|
||||
wiki page.
|
||||
As a new exit relay - especially if you are new to your hoster - it is good to start with a reduced exit policy (to reduce the amount of abuse emails) and further open it up as you become more experienced.
|
||||
The reduced exit policy can be found on the [ReducedExitPolicy](https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy) wiki page.
|
||||
|
||||
To become an exit relay change ExitRelay from 0 to 1 in your torrc configuration
|
||||
file and restart the tor daemon.
|
||||
To become an exit relay change ExitRelay from 0 to 1 in your torrc configuration file and restart the tor daemon.
|
||||
|
||||
```
|
||||
ExitRelay 1
|
||||
@ -320,9 +285,8 @@ ExitRelay 1
|
||||
|
||||
## DNS on Exit Relays
|
||||
|
||||
Unlike other types of relays, exit relays also do DNS resolution for Tor
|
||||
clients. DNS resolution on exit relays is crucial for Tor clients, it should be
|
||||
reliable and fast by using caching.
|
||||
Unlike other types of relays, exit relays also do DNS resolution for Tor clients.
|
||||
DNS resolution on exit relays is crucial for Tor clients, it should be reliable and fast by using caching.
|
||||
|
||||
* DNS resolution can have a significant impact on the performance and reliability your exit relay provides. Poor DNS performance will result in less traffic going through your exit relay.
|
||||
* Don't use any of the big DNS resolvers as your primary or fallback DNS resolver to avoid centralization (Google, OpenDNS, Quad9, Cloudflare, 4.2.2.1-6)
|
||||
@ -331,28 +295,19 @@ reliable and fast by using caching.
|
||||
* if a local resolver like unbound is not an option for you try to use a resolver that your provider runs in the same autonomous system (to find out if an IP address is in the same AS as your relay, you can look it up, using for example https://bgp.he.net).
|
||||
* try to avoid adding too many resolvers to your /etc/resolv.conf file to limit exposure on an AS-level (try to not use more than two entries)
|
||||
|
||||
There are multiple options for DNS server software, unbound has become a popular
|
||||
one but **feel free to use any other you are comfortable with**. When choosing your
|
||||
DNS resolver software try to ensure it supports DNSSEC validation and QNAME
|
||||
minimisation (RFC7816). In every case the software should be installed
|
||||
using the OS package manager to ensure it is updated with the rest of the
|
||||
system.
|
||||
There are multiple options for DNS server software, unbound has become a popular one but **feel free to use any other you are comfortable with**.
|
||||
When choosing your DNS resolver software try to ensure it supports DNSSEC validation and QNAME minimisation (RFC7816).
|
||||
In every case the software should be installed using the OS package manager to ensure it is updated with the rest of the system.
|
||||
|
||||
By using your own DNS resolver you are less vulnerable to DNS-based censorship
|
||||
that your upstream resolver might impose.
|
||||
By using your own DNS resolver you are less vulnerable to DNS-based censorship that your upstream resolver might impose.
|
||||
|
||||
Here follow specific instructions on how to install and configure unbound on
|
||||
your exit - a DNSSEC-validating and caching resolver. unbound has many
|
||||
configuration and tuning nobs but we try to keep these instructions as simple
|
||||
and short as possible and the basic setup will do just fine for most operators.
|
||||
Here follow specific instructions on how to install and configure unbound on your exit - a DNSSEC-validating and caching resolver. unbound has many configuration and tuning nobs but we try to keep these instructions as simple and short as possible and the basic setup will do just fine for most operators.
|
||||
|
||||
After switching to unbound verify it works as expected by resolving a valid
|
||||
hostname, if it does not work, you can restore the old resolv.conf file.
|
||||
After switching to unbound verify it works as expected by resolving a valid hostname, if it does not work, you can restore the old resolv.conf file.
|
||||
|
||||
### Debian/Ubuntu
|
||||
|
||||
The following 3 commands install unbound, backup your DNS configuration and tell
|
||||
the system to use the local unbound:
|
||||
The following 3 commands install unbound, backup your DNS configuration and tell the system to use the local unbound:
|
||||
|
||||
```
|
||||
apt install unbound
|
||||
@ -366,9 +321,8 @@ To avoid that the configuration gets changed (for example by the DHCP client):
|
||||
chattr +i /etc/resolv.conf
|
||||
```
|
||||
|
||||
The Debian configuration ships with QNAME minimisation (RFC7816) enabled
|
||||
by default so you don't need to enable it explicitly. The unbound resolver you
|
||||
just installed does also DNSSEC validation.
|
||||
The Debian configuration ships with QNAME minimisation (RFC7816) enabled by default so you don't need to enable it explicitly.
|
||||
The unbound resolver you just installed does also DNSSEC validation.
|
||||
|
||||
### CentOS/RHEL
|
||||
|
||||
@ -412,8 +366,7 @@ chattr +i /etc/resolv.conf
|
||||
|
||||
### FreeBSD
|
||||
|
||||
FreeBSD ships unbound in the base system but the one in ports is usually
|
||||
following upstream more closely so we install the unbound package:
|
||||
FreeBSD ships unbound in the base system but the one in ports is usually following upstream more closely so we install the unbound package:
|
||||
|
||||
```
|
||||
pkg install unbound
|
||||
@ -449,22 +402,17 @@ chflags schg /etc/resolv.conf
|
||||
|
||||
# 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:
|
||||
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
|
||||
|
||||
# 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.
|
||||
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:
|
||||
|
||||
@ -473,33 +421,27 @@ Default locations of the keys folder:
|
||||
|
||||
## 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.
|
||||
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.
|
||||
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 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.
|
||||
UptimeRobot 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.
|
||||
|
||||
* https://uptimerobot.com/
|
||||
|
||||
A good way to monitor a relay for its health state is to have a look at its
|
||||
bandwidth graphs.
|
||||
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:
|
||||
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
|
||||
@ -507,11 +449,9 @@ basic system monitoring in place to keep an eye on the following metrics:
|
||||
* Swap
|
||||
* CPU
|
||||
|
||||
There are many tools for monitoring this kind of data, munin is one of them and
|
||||
is relatively easy to setup.
|
||||
There are many tools for monitoring this kind of data, munin 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.**
|
||||
Note: **Do not make your private monitoring data graphs public since this could help attackers with deanonymizing Tor users.**
|
||||
|
||||
Some practical advice:
|
||||
|
||||
@ -526,12 +466,10 @@ Some practical advice:
|
||||
|
||||
This section listsm a few tools that you might find handy as a Tor relay operator.
|
||||
|
||||
Nyx: [Nyx](https://nyx.torproject.org/) is a Tor Project tool (formerly arm)
|
||||
that allows you to see real time data of your relay.
|
||||
Nyx: [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: 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 and demo output:
|
||||
|
||||
|
||||
@ -14,8 +14,7 @@ body:
|
||||
|
||||
# 1. Configure Tor Package Repository
|
||||
|
||||
Enable the Torproject package repository by following the instructions
|
||||
**[here](https://2019.www.torproject.org/docs/debian.html.en#ubuntu)**.
|
||||
Enable the Torproject package repository by following the instructions **[here](https://2019.www.torproject.org/docs/debian.html.en#ubuntu)**.
|
||||
|
||||
# 2. Package Installation
|
||||
|
||||
@ -25,7 +24,7 @@ Install the `tor` package:
|
||||
|
||||
# 3. Configuration File
|
||||
|
||||
Put the configuration file `/etc/tor/torrc` in place:
|
||||
Put the configuration file `/etc/tor/torrc` in place:
|
||||
|
||||
```
|
||||
#change the nickname "myNiceRelay" to a name that you like
|
||||
|
||||
@ -12,38 +12,30 @@ key: 5
|
||||
---
|
||||
body:
|
||||
|
||||
We assume you read through the [relay guide](..) already. This subpage is
|
||||
for operators that want to turn on exiting on their relay.
|
||||
We assume you read through the [relay guide](..) already. This subpage is for operators that want to turn on exiting on their relay.
|
||||
|
||||
It is recommended that you setup exit relays on servers dedicated to this
|
||||
purpose. It is not recommended to install Tor exit relays on servers that you
|
||||
need for other services as well. Do not mix your own traffic with your exit
|
||||
relay traffic.
|
||||
It is recommended that you setup exit relays on servers dedicated to this purpose.
|
||||
It is not recommended to install Tor exit relays on servers that you need for other services as well.
|
||||
Do not mix your own traffic with your exit relay traffic.
|
||||
|
||||
## Reverse DNS and WHOIS record
|
||||
|
||||
Before turning your non-exit relay into an exit relay, ensure that you have set a
|
||||
reverse DNS record (PTR) to make it more obvious that this is a tor
|
||||
exit relay. Something like "tor-exit" it its name is a good start.
|
||||
Before turning your non-exit relay into an exit relay, ensure that you have set a reverse DNS record (PTR) to make it more obvious that this is a tor exit relay. Something like "tor-exit" it its name is a good start.
|
||||
|
||||
If your provider offers it, make sure your WHOIS record contains clear
|
||||
indications that this is a Tor exit relay.
|
||||
If your provider offers it, make sure your WHOIS record contains clear indications that this is a Tor exit relay.
|
||||
|
||||
## Exit Notice HTML page
|
||||
|
||||
To make it even more obvious that this is a Tor exit relay you should serve a
|
||||
Tor exit notice HTML page. Tor can do that for you if your DirPort is on TCP
|
||||
port 80, you can make use of tor's DirPortFrontPage feature to display a
|
||||
HTML file on that port. This file will be shown to anyone directing his browser
|
||||
to your Tor exit relay IP address.
|
||||
To make it even more obvious that this is a Tor exit relay you should serve a Tor exit notice HTML page.
|
||||
Tor can do that for you if your DirPort is on TCP port 80, you can make use of tor's DirPortFrontPage feature to display a HTML file on that port.
|
||||
This file will be shown to anyone directing his browser to your Tor exit relay IP address.
|
||||
|
||||
```
|
||||
DirPort 80
|
||||
DirPortFrontPage /path/to/html/file
|
||||
```
|
||||
|
||||
We offer a sample Tor exit notice HTML file, but you might want to adjust it to
|
||||
your needs:
|
||||
We offer a sample Tor exit notice HTML file, but you might want to adjust it to your needs:
|
||||
https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-exit-notice.html
|
||||
|
||||
Here are some more tips for running a reliable exit relay:
|
||||
@ -51,24 +43,15 @@ https://blog.torproject.org/tips-running-exit-node
|
||||
|
||||
## Exit Policy
|
||||
|
||||
Defining the [exit
|
||||
policy](https://www.torproject.org/docs/tor-manual.html.en#ExitPolicy)
|
||||
is one of the most important parts of an exit relay configuration. The exit
|
||||
policy defines which destination ports you are willing to forward. This has an
|
||||
impact on the amount of abuse emails you will get (less ports means less abuse
|
||||
emails, but an exit relay allowing only few ports is also less useful). If you
|
||||
want to be a useful exit relay you must **at least allow destination ports 80
|
||||
and 443**.
|
||||
Defining the [exit policy](https://www.torproject.org/docs/tor-manual.html.en#ExitPolicy) is one of the most important parts of an exit relay configuration.
|
||||
The exit policy defines which destination ports you are willing to forward.
|
||||
This has an impact on the amount of abuse emails you will get (less ports means less abuse emails, but an exit relay allowing only few ports is also less useful).
|
||||
If you want to be a useful exit relay you must **at least allow destination ports 80 and 443**.
|
||||
|
||||
As a new exit relay - especially if you are new to your hoster - it is good to
|
||||
start with a reduced exit policy (to reduce the amount of abuse emails) and
|
||||
further open it up as you become more experienced. The reduced exit policy can
|
||||
be found on the
|
||||
[ReducedExitPolicy](https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy)
|
||||
wiki page.
|
||||
As a new exit relay - especially if you are new to your hoster - it is good to start with a reduced exit policy (to reduce the amount of abuse emails) and further open it up as you become more experienced.
|
||||
The reduced exit policy can be found on the [ReducedExitPolicy](https://trac.torproject.org/projects/tor/wiki/doc/ReducedExitPolicy) wiki page.
|
||||
|
||||
To become an exit relay change ExitRelay from 0 to 1 in your torrc configuration
|
||||
file and restart the tor daemon.
|
||||
To become an exit relay change ExitRelay from 0 to 1 in your torrc configuration file and restart the tor daemon.
|
||||
|
||||
```
|
||||
ExitRelay 1
|
||||
@ -76,39 +59,30 @@ ExitRelay 1
|
||||
|
||||
## DNS on Exit Relays
|
||||
|
||||
Unlike other types of relays, exit relays also do DNS resolution for Tor
|
||||
clients. DNS resolution on exit relays is crucial for Tor clients, it should be
|
||||
reliable and fast by using caching.
|
||||
Unlike other types of relays, exit relays also do DNS resolution for Tor clients.
|
||||
DNS resolution on exit relays is crucial for Tor clients, it should be reliable and fast by using caching.
|
||||
|
||||
* DNS resolution can have a significant impact on the performance and reliability your exit relay provides. Poor DNS performance will result in less traffic going through your exit relay.
|
||||
* DNS resolution can have a significant impact on the performance and reliability your exit relay provides.
|
||||
Poor DNS performance will result in less traffic going through your exit relay.
|
||||
* Don't use any of the big DNS resolvers as your primary or fallback DNS resolver to avoid centralization (Google, OpenDNS, Quad9, Cloudflare, 4.2.2.1-6)
|
||||
* We recommend running a local caching and DNSSEC-validating resolver without using any forwarders (specific instructions follow bellow for each operating systems)
|
||||
* if you want to add a second DNS resolver as a fallback to your /etc/resolv.conf configuration, try to choose a resolver within your autonomous system and make sure it is not your first entry in that file (the first entry should be your local resolver)
|
||||
* if a local resolver like unbound is not an option for you try to use a resolver that your provider runs in the same autonomous system (to find out if an IP address is in the same AS as your relay, you can look it up, using for example https://bgp.he.net).
|
||||
* try to avoid adding too many resolvers to your /etc/resolv.conf file to limit exposure on an AS-level (try to not use more than two entries)
|
||||
|
||||
There are multiple options for DNS server software, unbound has become a popular
|
||||
one but **feel free to use any other you are comfortable with**. When choosing your
|
||||
DNS resolver software try to ensure it supports DNSSEC validation and QNAME
|
||||
minimisation (RFC7816). In every case the software should be installed
|
||||
using the OS package manager to ensure it is updated with the rest of the
|
||||
system.
|
||||
There are multiple options for DNS server software, unbound has become a popular one but **feel free to use any other you are comfortable with**.
|
||||
When choosing your DNS resolver software try to ensure it supports DNSSEC validation and QNAME minimisation (RFC7816).
|
||||
In every case the software should be installed using the OS package manager to ensure it is updated with the rest of the system.
|
||||
|
||||
By using your own DNS resolver you are less vulnerable to DNS-based censorship
|
||||
that your upstream resolver might impose.
|
||||
By using your own DNS resolver you are less vulnerable to DNS-based censorship that your upstream resolver might impose.
|
||||
|
||||
Here follow specific instructions on how to install and configure unbound on
|
||||
your exit - a DNSSEC-validating and caching resolver. unbound has many
|
||||
configuration and tuning nobs but we try to keep these instructions as simple
|
||||
and short as possible and the basic setup will do just fine for most operators.
|
||||
Here follow specific instructions on how to install and configure unbound on your exit - a DNSSEC-validating and caching resolver. unbound has many configuration and tuning nobs but we try to keep these instructions as simple and short as possible and the basic setup will do just fine for most operators.
|
||||
|
||||
After switching to unbound verify it works as expected by resolving a valid
|
||||
hostname, if it does not work, you can restore the old resolv.conf file.
|
||||
After switching to unbound verify it works as expected by resolving a valid hostname, if it does not work, you can restore the old resolv.conf file.
|
||||
|
||||
### Debian/Ubuntu
|
||||
|
||||
The following 3 commands install unbound, backup your DNS configuration and tell
|
||||
the system to use the local unbound:
|
||||
The following 3 commands install unbound, backup your DNS configuration and tell the system to use the local unbound:
|
||||
|
||||
```
|
||||
apt install unbound
|
||||
@ -122,9 +96,8 @@ To avoid that the configuration gets changed (for example by the DHCP client):
|
||||
chattr +i /etc/resolv.conf
|
||||
```
|
||||
|
||||
The Debian configuration ships with QNAME minimisation (RFC7816) enabled
|
||||
by default so you don't need to enable it explicitly. The unbound resolver you
|
||||
just installed does also DNSSEC validation.
|
||||
The Debian configuration ships with QNAME minimisation (RFC7816) enabled by default so you don't need to enable it explicitly.
|
||||
The unbound resolver you just installed does also DNSSEC validation.
|
||||
|
||||
### CentOS/RHEL
|
||||
|
||||
@ -168,8 +141,7 @@ chattr +i /etc/resolv.conf
|
||||
|
||||
### FreeBSD
|
||||
|
||||
FreeBSD ships unbound in the base system but the one in ports is usually
|
||||
following upstream more closely so we install the unbound package:
|
||||
FreeBSD ships unbound in the base system but the one in ports is usually following upstream more closely so we install the unbound package:
|
||||
|
||||
```
|
||||
pkg install unbound
|
||||
|
||||
@ -18,6 +18,6 @@ html: user-testing.html
|
||||
---
|
||||
body:
|
||||
|
||||
Protecting privacy is what we do at Tor. So how do we collect meaningful user
|
||||
feedback without violating user consent? We conduct all of our user research
|
||||
through in-person studies that users explicitly opt into.
|
||||
Protecting privacy is what we do at Tor.
|
||||
So how do we collect meaningful user feedback without violating user consent?
|
||||
We conduct all of our user research through in-person studies that users explicitly opt into.
|
||||
|
||||
@ -18,6 +18,6 @@ html: user-testing.html
|
||||
---
|
||||
body:
|
||||
|
||||
Protecting privacy is what we do at Tor. So how do we collect meaningful user
|
||||
feedback without violating user consent? We conduct all of our user research
|
||||
through in-person studies that users explicitly opt into.
|
||||
Protecting privacy is what we do at Tor.
|
||||
So how do we collect meaningful user feedback without violating user consent?
|
||||
We conduct all of our user research through in-person studies that users explicitly opt into.
|
||||
|
||||
@ -18,6 +18,6 @@ html: user-testing.html
|
||||
---
|
||||
body:
|
||||
|
||||
Protecting privacy is what we do at Tor. So how do we collect meaningful user
|
||||
feedback without violating user consent? We conduct all of our user research
|
||||
through in-person studies that users explicitly opt into.
|
||||
Protecting privacy is what we do at Tor.
|
||||
So how do we collect meaningful user feedback without violating user consent?
|
||||
We conduct all of our user research through in-person studies that users explicitly opt into.
|
||||
|
||||
@ -18,6 +18,6 @@ html: user-testing.html
|
||||
---
|
||||
body:
|
||||
|
||||
Protecting privacy is what we do at Tor. So how do we collect meaningful user
|
||||
feedback without violating user consent? We conduct all of our user research
|
||||
through in-person studies that users explicitly opt into.
|
||||
Protecting privacy is what we do at Tor.
|
||||
So how do we collect meaningful user feedback without violating user consent?
|
||||
We conduct all of our user research through in-person studies that users explicitly opt into.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user