Greetings everyone!
We've very recently merged upstream (tor.git) full IPv6 supports which implies
many many things. We are still finalizing the work but most of it is in at the
moment.
This is a call for help if anyone would like to test either git master[1] or
nightly builds[2] (only Debian) to test for us a specific feature.
The feature we would love for some of you to test is the IPv6 address
discovery. In short, with this new feature, specifying an ORPort without an
address will …
[View More]automatically bind tor to [::]:<port> and attempt to find the
IPv6 address by looking at (in this order):
1. "Address" from torrc
2. "ORPort address:port" from torrc
3. Interface address. First public IPv6 is used.
4. Local hostname, DNS AAAA query.
If all fails, the relay will simply never publish an IPv6 in the descriptor
but it will work properly with the IPv4 (still mandatory).
The other new thing is that now tor supports *two* "Address" statement which
can be a hostname or IPv4 or IPv6 now.
Thus this is now valid:
Address 1.2.3.4
Address [4242::4242]
ORPort 9001
Your Tor will bind to 0.0.0.0:9001 and [::]:9001 but will publish the 1.2.3.4
for the IPv4 address and [4242::4242] for IPv6 in the descriptor that is the
address to use to reach your relay's ORPort.
Now, if you happen to have this configuration which I believe might be common
at the moment:
ORPort 9001
ORPort [4242::4242]:9001
The second ORPort which specifies an IPv6 address will supersede the "ORPort
9001" which uses [::] and thus you will bind on 0.0.0.0:9001 and
[4242::4242]:9001. You should get a notice log about this.
Thus the recommended configuration to avoid that log notice would be to bind
to specific addresses per family:
ORPort <IPv4>:9001
ORPort <IPv6>:9001
And of course, if you want your relay to _not_ listen on IPv6:
ORPort 9001 IPv4Only
In your notice log, you will see which address is used to bind on the ORPort
and then you will see the reachability test succeed or not on the address that
tor either used from the configuration or auto discovered that is the address
you are supposedly reachable from.
Man page has NOT been updated yet, it will arrive once we stabilize the IPv6
feature and everything around it.
Please, do report (on this thread) _anything_ even slightly annoying about
this like logging or lack of logging and so on. This is a complex feature and
errors can be made thus any testing you can offer is extremely appreciated.
Thanks!!
David
[1] https://gitweb.torproject.org/tor.git/
[2] https://2019.www.torproject.org/docs/debian.html.en
--
EeJVrrC/dHQXEXYB1ShOOZ4QuQ8PMnRY2XGq4BYsFq4=
[View Less]
Hello,
I'm taking care of a server of a friend who's on holiday. The server is up and running but not part of the consensus.
As beeing instructed I updated to the lastest OpenBSD snapshot when I saw that a new tor release is available (Tor 0.4.3.5 on OpenBSD).
Excerpts from the log:
Jul 13 20:04:02.000 [notice] Self-testing indicates your DirPort is reachable from the outside. Excellent.
Jul 13 20:05:02.000 [notice] Self-testing indicates your ORPort is reachable from the outside. …
[View More]Excellent. Publishing server descriptor.
Jul 13 20:05:35.000 [notice] Performing bandwidth self-test...done.
Jul 14 02:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus.
Jul 14 02:04:01.000 [notice] Heartbeat: Tor's uptime is 6:00 hours, with 0 circuits open. I've sent 2.04 MB and received 6.25 MB.
Jul 14 02:04:01.000 [notice] Average packaged cell fullness: 12.450%. TLS write overhead: 33%
Jul 14 02:04:01.000 [notice] Circuit handshake stats since last time: 0/0 TAP, 5/5 NTor.
Jul 14 02:04:01.000 [notice] Since startup we initiated 0 and received 157 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and
received 5 v4 connections; initiated 48 and received 124 v5 connections.
Jul 14 02:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0
INTRODUCE2 rejected.
Jul 14 06:04:02.000 [notice] Your relay has a very large number of connections to other relays. Is your outbound address the same as your relay address? Found 9 connections to 6 relays. Found 4
current canonical connections, in 0 of which we were a non-canonical peer. 3 relays had more than 1 connection, 0 had more than 2, and 0 had more than 4 connections.
Jul 14 08:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus.
Jul 14 08:04:01.000 [notice] Heartbeat: Tor's uptime is 12:00 hours, with 1 circuits open. I've sent 3.46 MB and received 11.22 MB.
Jul 14 08:04:01.000 [notice] Average packaged cell fullness: 12.450%. TLS write overhead: 47%
Jul 14 08:04:01.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 1/1 NTor.
Jul 14 08:04:01.000 [notice] Since startup we initiated 0 and received 340 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and
received 10 v4 connections; initiated 57 and received 246 v5 connections.
Jul 14 08:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0
INTRODUCE2 rejected.
Jul 14 14:04:01.000 [notice] Heartbeat: It seems like we are not in the cached consensus.
Jul 14 14:04:01.000 [notice] Heartbeat: Tor's uptime is 18:00 hours, with 1 circuits open. I've sent 4.89 MB and received 15.33 MB.
Jul 14 14:04:01.000 [notice] Average packaged cell fullness: 26.760%. TLS write overhead: 51%
Jul 14 14:04:01.000 [notice] Circuit handshake stats since last time: 2/2 TAP, 6/6 NTor.
Jul 14 14:04:01.000 [notice] Since startup we initiated 0 and received 493 v1 connections; initiated 0 and received 0 v2 connections; initiated 0 and received 0 v3 connections; initiated 0 and
received 18 v4 connections; initiated 64 and received 370 v5 connections.
Jul 14 14:04:01.000 [notice] DoS mitigation since startup: 0 circuits killed with too many cells. 0 circuits rejected, 0 marked addresses. 0 connections closed. 0 single hop clients refused. 0
INTRODUCE2 rejected.
Atlas show the server as down: https://metrics.torproject.org/rs.html#details/AC601DBDB7FBD53454045EDC08DA…
Accessing the status page on port 80 works.
No FW on the machine.
Any ideas?
Thanks and regards
Fran
[View Less]
Dear Relay Operators,
Do you want your relay to be a Tor fallback directory mirror?
Will it have the same address and port for the next 2 years?
Just reply to this email with your relay's fingerprint.
Important: you have until July 23 2020 to reply to this message to get
in the fallback directory mirror list.
If your relay is on the current fallback list, you don't need to do
anything.
If you're asking:
Q: What's a fallback directory mirror?
Fallback directory mirrors help Tor clients …
[View More]connect to the network. For
more details, see [1].
Q: Is my relay on the current list?
Search [2] and [3] for your relay fingerprint or IP address and port.
[2] is the current list of fallbacks in Tor.
[3] is used to create the next list of fallbacks.
Q: What do I need to do if my relay is on the list?
Keep the same IP address, keys, and ports. Email tor-relays if the
relay's details change.
Q: Can my relay be on the list next time?
We need fast relays that will be on the same IP address and port for 2
years. Reply to this email to get on the list, or to update the details
of your relay.
Once or twice a year, we run a script to choose about 150-200 relays
from the potential list [3] for the list in Tor [2].
Q: Why didn't my relay get on the list last time?
We check a relay's uptime, flags, and speed [4]. Sometimes, a relay
might be down when we check. That's ok, we will check it again next
time.
It's good to have some new relays on the list every release. That helps
tor clients, because blocking a changing list is harder.
cheers,
Gus
[1]
https://gitlab.torproject.org/tpo/core/tor/-/wikis/NetworkTeam/FallbackDire…
[2]
https://gitweb.torproject.org/tor.git/tree/src/app/config/fallback_dirs.inc
[3]
https://gitweb.torproject.org/fallback-scripts.git/tree/fallback_offer_list
[4]
https://trac.torproject.org/projects/tor/attachment/ticket/21564/fallbacks_…
--
The Tor Project
Community Team Lead
http://expyuzz4wqqyqhjn.onion/
[View Less]
Daily DDOS love the last 14 days …
https://imgur.com/a/rfu0OUA <https://imgur.com/fCsIv6V>
even for my standards, thats a shit-ton of sockets … Tor DDOS protection is configured but I get more connections than I can drop …
nifty
Question: What's with the failure when installing Tor of the "no valid keys" for focal? I've had to back up to ubuntu 18 several times. --potlatch--
Sent with [ProtonMail](https://protonmail.com) Secure Email.
Hello CypherpunkLabs,
I noticed your set of new relays and wanted to say hi,
welcome you to the Tor relay community
and give you a few recommendations and pointers especially since you are aiming to run 100 tor relays.
The Tor relay guide has a lot of useful information, so you probably want to start there:
https://torproject.org/relay-guide
Since all your current relays appear to be OVH based I'd like to point out the following
quote from the guide:
> Try to avoid the following hosters:…
[View More]
>
> OVH SAS (AS16276)
> Online S.a.s. (AS12876)
> Hetzner Online GmbH (AS24940)
> DigitalOcean, LLC (AS14061)
https://community.torproject.org/relay/technical-considerations/
The reasoning behind this, is that those hosters are already hosting many tor relays,
and the network dislikes centralization. OVH is the biggest commercially available tor hoster in terms of exit capacity
today already.
Depending on your per-relay size you might end up running a big fraction of the network and
especially big exit operators are encourage to take care of their DNS resolution.
Specific guidelines can be found here:
https://community.torproject.org/relay/setup/exit/
IPv6 connectivity is also encouraged (which currently none of your relays appear to have).
Especially for big operators it is recommended to managed their relays using configuration
management (puppet, salt, ansible, ...) and update them regularly.
An ansible role for Tor relay operator (I maintain) can be found at:
https://github.com/nusenu/ansible-relayor
The ContactInfo Information Sharing Specification is a spec about a machine readable ContactInfo string:
https://github.com/nusenu/ContactInfo-Information-Sharing-Specification
Your site suggests that you (will) run bridges and exits.
Combining these two types of nodes under a single operator is generally a
bad idea since tor's MyFamily configuration is not supported for bridges, so users might end up
using your bridges _and_ your tor exits - which puts them at risk should someone compromise you, please
consider running non-bridges only.
For strong protections for your long term relay keys
you can use tor's OfflineMasterKey feature,
especially relevant if your run a big fraction of the network:
https://2019.www.torproject.org/docs/tor-manual.html.en#OfflineMasterKey
kind regards,
nusenu
PS: don't forget about your MyFamily setting if you do not choose a solution
that manages that for you automatically.
--
https://mastodon.social/@nusenu
[View Less]
I have IPv6 with my ISP, but there seems to be a bug in the firmware of my networking equipment that causes IPv6 to stop working periodically and I have to take my network down and bring it back up. If I do not do this, my relay stops functioning as I have torrc configured to use IPv6 and IPv4. So, my question is whether or not having a higher uptime is more important or having IPv6 support? My relay never goes down when on IPv4 only. I apparently cannot have both until the firmware bug is …
[View More]fixed. I appreciate it!
[View Less]
Hi,
I believe the Tor bandwidth scanner nicknamed "longclaw" is measuring
relays in the US West Coast worse than other bandwidth scanners in North
America. This happens on multiple ISPs, both ones I have and ones I
don't.
This includes two Tor exit instances on a dedicated server hosted in Los
Angeles on Psychz Networks (AS40676):
https://metrics.torproject.org/rs.html#details/156AAC3FAD1ACC8906316519DCB4…https://metrics.torproject.org/rs.html#details/A69CEB30328B1E85C6B167FECAF2……
[View More]And two Tor non-exit instances on a home server in Seattle on Wave
Broadband (AS11404), using a symmetrical Gigabit link:
https://metrics.torproject.org/rs.html#details/B0F9BA27944FA59E3B1A182208FF…https://metrics.torproject.org/rs.html#details/DB710B14D7329B7289CFCC547F48…
The consensus weight values from longclaw are much lower than other
North American bandwidth scanners, according to
https://consensus-health.torproject.org/.
This also affects other relays/ISPs on the West Coast US/Canada, such as
Emerald Onion, AT&T U-verse, Sonic.net, and QuadraNet. The same
ISPs/hosts in the East Coast aren't affected.
This discrepancy in the measurement disproportionately favors European
and East Coast US/Canada relays at the expense of West Coast relays,
centralizing the Tor network even further than it already was. This
wasn't an issue in the past, even as early as a few months ago. It only
started appearing around June.
Is anyone else hosting West Coast relays having this issue? Is
"longclaw" actually measuring bandwidth from Europe? If so, WHY?
I got in contact with "longclaw"'s admin and he wasn't too helpful.
Best,
Neel Chauhan
===
https://www.neelc.org/
[View Less]