Hello,
Thanks everyone for joining us last saturday!
The next Tor Relay Operator meetup is on May 21st at 1900 UTC.
Here is our meetup notes.
cheers,
Gus
## Tor Relay Operator - April 02, 2022
* EOL relays and bridges removal update (GeKo)
* Overload reporting adjustment (GeKo):
* https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/27
* https://gitlab.torproject.org/tpo/core/tor/-/issues/40560
* Added to 0.4.7.5-alpha, with backport to 0.4.6 coming
* Bridges contact info are now public listed (gus)
In Colector we stopped sanitizing contact info for bridges:
https://lists.torproject.org/pipermail/tor-project/2022-April/003329.html
https://gitlab.torproject.org/tpo/network-health/metrics/collector/-/issues/20983
* Announcement: 0.4.7 release is coming up soon (just released last alpha) around May 15th
* "Expectations for relay operators", as a periodic fyi that we do at each of these meetings:
https://gitlab.torproject.org/tpo/community/relays/-/issues/18 -- feedback is great if you have any! :)
### Q&A part of the meeting
* Best practices to secure relays and bridges
We discussed in a previous relay operator meetup about having a
*workshop* for giving this guidance to people. We have two people,
Kushal and BSD George, who are excited to help lead the workshop. We
need to pick a day and time to try a 1-hour workshop. One point is to
help people understand how to configure MyFamily and why configuring it
is important for helping the network health team distinguish imposter
relays -- which are not just theoretical these days, bad people are
actually setting up imposter relays trying to make it look like you
misconfigured your Family.
There's a ticket: https://gitlab.torproject.org/tpo/community/relays/-/issues/36
* But bridges still shouldn't set MyFamily, right?
Right. But, we have a plan for the future that will let us fix that situation. Stay tuned:
https://gitweb.torproject.org/torspec.git/tree/proposals/321-happy-families.md
* Is a open metrics port really that bad? Why?
The metrics port gives out traffic details that are too-finegrained to
publish. Having your metrics port open to the world will expose that
info to people who should't have it. Please keep metrics port output
private.
* Is anybody here hitting the ORPort self-test bug that seems like it
might be new in 0.4.5 / 0.4.6? https://gitlab.torproject.org/tpo/core/tor/-/issues/40424
It's hard to tell if it's widespread or just a few people.
Nobody on the chat at the time says that they experienced the bug. This
is a good sign at least. :)
* My 0.4.6.10 FreeBSD bridge disappeared from the metrics site. What happened?
Best answer is to ask on irc when this happens. It sounds unrelated to
your OS, and more likely to be something else. Maybe your ORPort is
closed so your bridge stopped publishing. Be sure to check out your Tor
logs as a first step too.
* Performance tweaks for high bandwidth / multi instance servers,
[server confi templates - Torservers](https://github.com/torservers/server-config-templates/).
What about HardwareAccel, NumCPUs?
In the distant past, AES instructions in the chipset were rare,
and you needed to tell your Tor to tell your openssl to use
hardwareaccel. In the glorious present, maybe openssl just auto does it
for you? Somebody should do some experiments. One key hint: Tor tells
you at info-level in its logs about whether it's using accel.
* How about NumCPUs? On my computer I have 64 cores, 64 instances and
NumCPUs defaults to using 16 of them (on each instance).
Current C-Tor does AES and TLS in the main core, and it farms out
circuit handshakes to other cores. So it is not as multi-threaded as we
might want. So to turn it around: on your huge machine, how are those 16
threads doing? Are they mostly full? In that case yes set NumCPUs
explicitly. If no, maybe it is fine as is.
* I am new to Linux and Tor. I have Debian up and running on a laptop.
Is there any good "getting started with Tor" resources for beginners like me?
Yes, we have some docs on the Community portal:
- Run a Bridge: https://community.torproject.org/relay/setup/bridge/
- Run a Snowflake Standalone Proxy:
- https://community.torproject.org/relay/setup/snowflake/standalone/
- https://packages.debian.org/search?keywords=snowflake
(snowflake-proxy available in debian unstable)
- https://hub.docker.com/r/thetorproject/snowflake-proxy (Docker)
* Suggestion for reducing the amount of EOL relays: Promote/link the
unattended-upgrade guide and tor-repo information more visible.
I wonder where we should put this to make it more visible. One option
could be on relay-search when we show the "Not Recommended" banner.
[GeKo]
* Is it dangerous to run Snowflake from a home-network?
Mostly it is ok? If you are in Russia, I would not recommend doing
it. But if you're in a country that's not at war, it should be fine.
We are seeing some people confused about Snowflake-proxy vs
Snowflake-client. If you check the [Metrics
portal](https://collector.torproject.org/recent/snowflakes/), you can
see that the #3 country running Snowflake *proxies* is Russia. And
apparently they aren't getting punished. Maybe people there are getting
confused and thinking that they are helping get around their own
censorship by installing the Snowflake extension? Is it good idea to
leave it as-is, because getting more proxies is good, or it is better to
understand and fix it, because one day it might lead to something unwanted?
* What does your ISP see if you have snowflake proxy?
Your internet provider will see:
(a) a TLS connection to the (centralized) snowflake broker,
(b) WebSocket connection to the (centralized) Snowflake bridge,
(c) - less specific - some WebRTC connections to censored countries when
you are assigned to someone.
So if your ISP knows the IP addresses of those centralized services (or
sees DNS lookups for them, or their SNI - endless possibilities, proxies
are not designed to be unblockable by their own ISP), they could
conclude that you're being a Snowflake volunteer. I guess they could try
to block your connections at that point? We haven't seen any problems
here.
* It's hard to explain the difference between snowflake client, proxy and
server on AUR (archlinux user repository), some "official" resource would be nice.
Yes, we are looking into this.
* Are there any plans to add an obfs4proxy package to the torproject debian repository?
The new obfs4proxy package is in Debian sid, and now in Debian
backports. There's a ticket to get it into Ubuntu backports but it's
unclear how long that will take.
We have a policy at deb.torproject.org that we only include things
that are already packaged in Debian. So, that policy is compatible
with this idea! We could do it. And maybe we really should, because
otherwise the Ubuntu people will have a tough time getting their proper
obfs4proxy package. The main barrier is having people who will shepherd
the process to its end. Any volunteers? :)
* Please add prometheus support (process uptime, memory usage, bandwidth
usage, number of users served, ...) to snowflake proxy (standalone) so
we can detect crashed snowflake proxies
Right -- please open tickets on gitlab.torproject.org with the
desired behavior. And as an extra bonus, please include a patch
for it to work. :)
* Do other relay operators also see occasionally sudden connection
spikes on their relays? Does anybody know what causes this?
Please file a ticket to help us investigate!
https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/
If it's a one-day spike, a good explanation is that your relay
became the HSDir for a super popular onion service. In the past,
those were typically dead botnet C&C controllers, where some jerk had
tried to sign his botnet up to use Tor for command-and-control, but
realized it wasn't a good idea and stopped, but the bots still tried to
reach the dead C&C, causing onion service descriptor fetching hotspots.
But if it's a 20 minute spike, it sounds like it's not that. A
mystery! Open a ticket please. :)
* "Flood of resolve attempts overwhelms unbound on relays"
The unbound bug, and/or the Tor exit relay overload issue -
https://gitlab.torproject.org/tpo/network-health/analysis/-/issues/30
Please add all the hints you have to the ticket!
One thing that seems like it might help: put your dns resolver on a
different (outbound) IP address than your Tor exit relay. That way
when .ru censors your exit relay, it doesn't block the dns queries you
make to .ru.
### Next Tor Relay Operator Meetup
* May 21st 1900 UTC
### Other resources for relay operators
- The [tor-relays@ mailing list](https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays)
- The #tor-relays irc channel (IRC.OFTC.NET) or [Matrix](#tor-relays:matrix.org)
- The [forum.torproject.net forum](https://forum.torproject.net/c/support/relay-operator/17)
On Mon, Mar 28, 2022 at 03:58:00PM -0300, gus wrote:
> Hello relay operators and Tor friends,
>
> The next Tor Relay Operator meetup will happen this Saturday, April 2 @
> 1900 UTC / 1500 EDT / 2100 CET.
>
> Where: BigBlueButton - https://tor.meet.coop/gus-og0-x74-dzn
>
> No need for a registration or anything else, just use the room-link
> above.
>
> The agenda is available here:
> https://pad.riseup.net/p/tor-relay-meetup-april-2022-keep
>
> Everyone is free to bring up additional questions or topics at the
> meeting itself.
>
> Please share with your friends, social media and other mailing lists!
>
> cheers,
> Gus
> --
> The Tor Project
> Community Team Lead
--
The Tor Project
Community Team Lead
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ tor-relays mailing list tor-relays@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays