|
|
|
|
|
= The Tor Relay Guide moved to https://community.torproject.org/relay/ =
|
|
|
|
|
|
= The content on this page is no longer maintained. =
|
|
|
# The content on this page is no longer maintained.
|
|
|
|
|
|
|
|
|
== Using this guide ==
|
... | ... | @@ -18,7 +18,7 @@ If you wish to skip directly to setting up a relay, read part two only. |
|
|
We use "tor" (lower case) whenever we talk specifically about the program tor (the daemon), in all other cases we use "Tor".
|
|
|
|
|
|
== Part one: deciding to run a relay ==
|
|
|
=== Why run a Tor relay? ===
|
|
|
### Why run a Tor relay?
|
|
|
|
|
|
By running a Tor relay you can help make the Tor network:
|
|
|
* faster (and therefore more usable)
|
... | ... | @@ -38,24 +38,24 @@ Guard and middle relays usually do not receive abuse complaints. All relays will |
|
|
|
|
|
A non-exit Tor relay requires minimal maintenance efforts and bandwidth usage can be highly customized in the tor configuration (will be covered in more detail later in this guide). The so called "exit policy" of the relay decides if it is a relay allowing clients to exit or not. A non-exit relay does not allow exiting in its exit policy.
|
|
|
|
|
|
==== Exit relay ====
|
|
|
#### Exit relay
|
|
|
|
|
|
The exit relay is the final relay in a Tor circuit, the one that sends traffic out its destination. The services Tor clients are connecting to (website, chat service, email provider, etc) will see the IP address of the exit relay instead of their real IP address of the Tor user.
|
|
|
|
|
|
Exit relays have the greatest legal exposure and liability of all the relays. For example, if a user downloads copyrighted material while using your exit relay, you the operator may receive a [https://www.dmca.com/Solutions/view.aspx?ID=712f28a5-93f2-467b-ba92-3d58c8345a32&?ref=sol08a2 DMCA notice]. Any abuse complaints about the exit will go directly to you (via your hoster, depending on the WHOIS records). Generally, most complaints can be handled pretty easily through template letters, which we'll discuss more in legal considerations section.
|
|
|
Exit relays have the greatest legal exposure and liability of all the relays. For example, if a user downloads copyrighted material while using your exit relay, you the operator may receive a [DMCA notice](https://www.dmca.com/Solutions/view.aspx?ID=712f28a5-93f2-467b-ba92-3d58c8345a32&?ref=sol08a2). Any abuse complaints about the exit will go directly to you (via your hoster, depending on the WHOIS records). Generally, most complaints can be handled pretty easily through template letters, which we'll discuss more in legal considerations section.
|
|
|
|
|
|
Because of the legal exposure that comes with running an exit relay, **you should not run a Tor exit relay from your home**. Ideal exit relay operators are affiliated with some institution, like a university, a library, a hackerspace or a privacy related organization. An institution can not only provide greater bandwidth for the exit, but is better positioned to handle abuse complaints or the rare law enforcement inquiry.
|
|
|
|
|
|
If you are considering running an exit relay, please read [[TorRelayGuide#Legalconsiderationsforexitrelayoperators|the section on legal considerations]] for exit relay operators.
|
|
|
|
|
|
==== Bridge ====
|
|
|
#### Bridge
|
|
|
The design of the Tor network means that the IP address of Tor relays is public. However, one of the ways Tor can be blocked by governments or ISPs is by blacklisting the IP addresses of these public Tor nodes. Tor bridges are nodes in the network that are not listed in the public Tor directory, which make it harder for ISPs and governments to block them.
|
|
|
|
|
|
Bridges are useful for Tor users under oppressive regimes or for people who want an extra layer of security because they're worried somebody will recognize that they are contacting a public Tor relay IP address. Several countries, including China and Iran, have found ways to detect and block connections to Tor bridges. Pluggable transports (https://www.torproject.org/docs/pluggable-transports.html.en), a special kind of bridge, address this by adding an additional layer of obfuscation.
|
|
|
|
|
|
Bridges are relatively easy, low-risk and low bandwidth Tor nodes to operate, but they have a big impact on users. A bridge isn't likely to receive any abuse complaints, and since bridges are not listed in the public consensus, they are unlikely to be blocked by popular services. Bridges are a great option if you can only run a Tor node from your home network, have only one static IP, and don't have a huge amount of bandwidth to donate -- we recommend giving your bridge at least 1 Mbit/sec.
|
|
|
|
|
|
=== Relay Requirements ===
|
|
|
### Relay Requirements
|
|
|
Requirements for Tor relays depend on the type of relay and the bandwidth they provide.
|
|
|
|
|
|
==== Bandwidth and Connections
|
... | ... | @@ -166,7 +166,7 @@ We collected the steps to enable automatic software updates for different operat |
|
|
* [[TorRelayGuide/BSDUpdates|FreeBSD/HardenedBSD]]
|
|
|
|
|
|
|
|
|
=== Tor Relay Setup: Installation and Configuration ===
|
|
|
### Tor Relay Setup: Installation and Configuration
|
|
|
|
|
|
This section covers the installation and configuration of the program required to run a Tor relay for various operating systems. These steps are intended for the latest stable version of the given OS, on Ubuntu for the latest LTS release.
|
|
|
|
... | ... | @@ -216,9 +216,9 @@ Please choose your platform: |
|
|
|
|
|
=== 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.
|
|
|
|
|
|
=== Getting Help
|
... | ... | @@ -231,12 +231,12 @@ This is a great resource for asking (and answering) questions, and generally get |
|
|
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:
|
|
|
|
|
|
* [https://www.torproject.org/docs/tor-manual.html.en#AccountingMax AccountingMax]
|
|
|
* [https://www.torproject.org/docs/tor-manual.html.en#AccountingRule AccountingRule]
|
|
|
* [https://www.torproject.org/docs/tor-manual.html.en#AccountingStart AccountingStart]
|
|
|
* [https://www.torproject.org/docs/tor-manual.html.en#BandwidthRate BandwidthRate]
|
|
|
* [https://www.torproject.org/docs/tor-manual.html.en#BandwidthBurst BandwidthBurst]
|
|
|
* [https://www.torproject.org/docs/tor-manual.html.en#RelayBandwidthRate RelayBandwidthRate]
|
|
|
* [AccountingMax](https://www.torproject.org/docs/tor-manual.html.en#AccountingMax)
|
|
|
* [AccountingRule](https://www.torproject.org/docs/tor-manual.html.en#AccountingRule)
|
|
|
* [AccountingStart](https://www.torproject.org/docs/tor-manual.html.en#AccountingStart)
|
|
|
* [BandwidthRate](https://www.torproject.org/docs/tor-manual.html.en#BandwidthRate)
|
|
|
* [BandwidthBurst](https://www.torproject.org/docs/tor-manual.html.en#BandwidthBurst)
|
|
|
* [RelayBandwidthRate](https://www.torproject.org/docs/tor-manual.html.en#RelayBandwidthRate)
|
|
|
|
|
|
Having a fast relay for some time of the month is preferred over a slow relay for the entire month.
|
|
|
|
... | ... | @@ -250,30 +250,30 @@ We encourage everyone to enable IPv6 on their relays. This is especially valuabl |
|
|
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.
|
|
|
|
... | ... | @@ -281,12 +281,12 @@ Additional information related to IPv6 can be found in the [/wiki/doc/IPv6RelayH |
|
|
|
|
|
=== 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 [https://www.torproject.org/docs/tor-manual.html.en#MyFamily MyFamily] value and have a valid **[https://www.torproject.org/docs/tor-manual.html.en#ContactInfo 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://www.torproject.org/docs/tor-manual.html.en#MyFamily) value and have a valid **[ContactInfo](https://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.
|
|
|
|
|
|
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
|
... | ... | @@ -305,12 +305,12 @@ If your provider offers it, make sure your WHOIS record contains clear indicatio |
|
|
|
|
|
==== 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 [https://www.torproject.org/docs/tor-manual.html.en#DirPortFrontPage 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](https://www.torproject.org/docs/tor-manual.html.en#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:
|
|
|
https://gitweb.torproject.org/tor.git/plain/contrib/operator-tools/tor-exit-notice.html
|
... | ... | @@ -328,7 +328,7 @@ Unlike other types of relays, exit relays also do DNS resolution for Tor clients |
|
|
* 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 ([https://tools.ietf.org/html/rfc7816 RFC7816]).
|
|
|
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](https://tools.ietf.org/html/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.
|
... | ... | @@ -342,86 +342,86 @@ After switching to unbound verify it works as expected by resolving a valid host |
|
|
|
|
|
The following 3 commands install unbound, backup your DNS configuration and tell the system to use the local unbound:
|
|
|
|
|
|
{{{
|
|
|
```
|
|
|
apt install unbound
|
|
|
cp /etc/resolv.conf /etc/resolv.conf.backup
|
|
|
echo nameserver 127.0.0.1 > /etc/resolv.conf
|
|
|
}}}
|
|
|
```
|
|
|
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 ([https://tools.ietf.org/html/rfc7816 RFC7816])
|
|
|
QNAME minimisation ([RFC7816](https://tools.ietf.org/html/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
|
|
|
Install the unbound package:
|
|
|
{{{
|
|
|
```
|
|
|
yum install unbound
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
in /etc/unbound/unbound.conf
|
|
|
replace the line
|
|
|
{{{
|
|
|
```
|
|
|
# qname-minimisation: no
|
|
|
}}}
|
|
|
```
|
|
|
with:
|
|
|
{{{
|
|
|
```
|
|
|
qname-minimisation: yes
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
enable and start unbound:
|
|
|
{{{
|
|
|
```
|
|
|
systemctl enable unbound
|
|
|
systemctl start unbound
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
Tell the system to use the local unbound server:
|
|
|
{{{
|
|
|
```
|
|
|
cp /etc/resolv.conf /etc/resolv.conf.backup
|
|
|
echo nameserver 127.0.0.1 > /etc/resolv.conf
|
|
|
}}}
|
|
|
```
|
|
|
To avoid that the configuration gets changed (for example by the DHCP client):
|
|
|
{{{
|
|
|
```
|
|
|
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:
|
|
|
{{{
|
|
|
```
|
|
|
pkg install unbound
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
Replace the content in /usr/local/etc/unbound/unbound.conf with the following lines:
|
|
|
{{{
|
|
|
```
|
|
|
server:
|
|
|
verbosity: 1
|
|
|
qname-minimisation: yes
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
enable and start the unbound service:
|
|
|
{{{
|
|
|
```
|
|
|
sysrc unbound_enable=YES
|
|
|
service unbound start
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
Tell the system to use the local unbound server:
|
|
|
{{{
|
|
|
```
|
|
|
cp /etc/resolv.conf /etc/resolv.conf.backup
|
|
|
echo nameserver 127.0.0.1 > /etc/resolv.conf
|
|
|
}}}
|
|
|
```
|
|
|
To avoid that the configuration gets changed (for example by the DHCP client):
|
|
|
{{{
|
|
|
```
|
|
|
chflags schg /etc/resolv.conf
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
==== Exit Policy
|
|
|
|
|
|
Define your [https://www.torproject.org/docs/tor-manual.html.en#ExitPolicy exit policy]. 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.**
|
|
|
Define your [exit policy](https://www.torproject.org/docs/tor-manual.html.en#ExitPolicy). 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 following page:
|
|
|
[/wiki/doc/ReducedExitPolicy ReducedExitPolicy]
|
... | ... | @@ -429,9 +429,9 @@ As a new exit relay - especially if you are new to your hoster - it is good to s |
|
|
==== Final Step: Enable Exiting in your torrc configuration
|
|
|
|
|
|
To become an exit relay change `ExitRelay` from 0 to 1 in your torrc configuration file and restart the tor daemon.
|
|
|
{{{
|
|
|
```
|
|
|
ExitRelay 1
|
|
|
}}}
|
|
|
```
|
|
|
|
|
|
|
|
|
=== Tor relay lifecycle
|
... | ... | @@ -471,7 +471,7 @@ To ensure your relay is healthy and not overwhelmed it makes sense to have some |
|
|
* Swap
|
|
|
* CPU
|
|
|
|
|
|
There are many tools for monitoring this kind of data, [http://munin-monitoring.org/ munin] is one of them and is relatively easy to setup.
|
|
|
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.**
|
|
|
|
... | ... | @@ -486,9 +486,9 @@ Some practical advice: |
|
|
==== Tools
|
|
|
This section listsm a few tools that you might find handy as a Tor relay operator.
|
|
|
|
|
|
'''Nyx:''' [https://nyx.torproject.org/ Nyx] 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:
|
|
|
* http://humdi.net/vnstat/
|
... | ... | @@ -506,7 +506,7 @@ The EFF Tor Legal FAQ (https://www.torproject.org/eff/tor-legal-faq.html.en) ans |
|
|
|
|
|
Also see the [/wiki/doc/TorExitGuidelines Tor Exit Guidelines].
|
|
|
|
|
|
==== Responding to abuse complaints ====
|
|
|
#### Responding to abuse complaints
|
|
|
|
|
|
Operators can put together their own abuse complaint template responses from one of many templates that Tor has created: [/wiki/doc/TorAbuseTemplates TorAbuseTemplates].
|
|
|
|
... | ... | @@ -518,11 +518,11 @@ Other docs we like: |
|
|
* a letter Boing Boing used to respond to a US federal subpoena about their exit relay: https://boingboing.net/2015/08/04/what-happened-when-the-fbi-sub.html
|
|
|
* abuse response templates from Coldhak, an organization in Canada that runs multiple relays: https://github.com/coldhakca/abuse-templates/blob/master/dmca.template, https://github.com/coldhakca/abuse-templates/blob/master/generic.template
|
|
|
|
|
|
=== Running a relay with other people ===
|
|
|
### Running a relay with other people
|
|
|
|
|
|
Running relays is more fun with other people! You can work with your university department, your employer or institution, or an organization like Torservers.net to run a relay.
|
|
|
|
|
|
==== Torservers.net ====
|
|
|
#### Torservers.net
|
|
|
|
|
|
Torservers is an independent, global network of organizations that help the Tor network by running high bandwidth Tor relays. Becoming a Torservers partner is a good way to become more involved in the Tor relay community, and can help you connect with dedicated relay operators around the world for solidarity and support. To start a Torservers partner, the most important thing is to have a group of people (3-5 suggested to start) interested in helping with the various activities required for running relays. There should be mutual trust between the people in the group, and members should commit to running relays for the long term. If you do not know anyone in your social network interested in running relays, one place to meet people is your local hackerspace: https://wiki.hackerspaces.org/Hackerspaces.
|
|
|
|
... | ... | @@ -530,14 +530,14 @@ Once you have a trusted group of people, depending on your region, it is often a |
|
|
|
|
|
The next steps are figuring out hardware, transit, and server hosting. Depending on your location and connections within the technical community of the area, the last one may be the hardest step. Small local ISPs often have extra bandwidth, and may be interested in supporting your group with some bandwidth or rackspace. It is extremely important to maintain good relationships with these ISPs.
|
|
|
|
|
|
==== At your university ====
|
|
|
#### At your university
|
|
|
|
|
|
Many computer science departments, university libraries, and individual students and faculty run relays from university networks. These universities include the Massachusetts Institute of Technology (MIT CSAIL), Boston University, the University of Waterloo, the University of Washington, Northeastern University, Karlstad University, Universitaet Stuttgart, and Friedrich-Alexander University Erlangen-Nuremberg. To learn more about how to get support for a relay on your university's network, check out EFF's resources: https://www.eff.org/torchallenge/tor-on-campus.html.
|
|
|
|
|
|
==== At your company or organization ====
|
|
|
#### At your company or organization
|
|
|
If you work at a Tor-friendly company or organization, that's another ideal place to run a relay. Some companies running relays inlcude Brass Horn Communications, Quintex Alliance Consulting, and OmuraVPN. Some organizations running Tor relays include Digital Courage, Access Now, Derechos Digitales, and Lebanon Libraries in New Hampshire.
|
|
|
|
|
|
=== More resources ===
|
|
|
### More resources
|
|
|
Congratulations, you're officially a Tor relay operator! What now?
|
|
|
|
|
|
* You can check out traffic and other statistics for your relay at our Relay Search: https://metrics.torproject.org/rs.html (your relay will appear on "Relay Search" about 3 hours after you started it).
|
... | ... | |