- tor-relays - lists.torproject.org

inet_csk_bind_conflict
by Christopher Sheats 21 Mar '23

21 Mar '23

Hello tor-relays, We are using Ubuntu server currently for our exit relays. Occasionally, exit throughput will drop from ~4Gbps down to ~200Mbps and the only observable data point that we have is a significant increase in inet_csk_bind_conflict, as seen via 'perf top', where it will hit 85% [kernel] utilization. A while back we thought we solved with with two /etc/sysctl.conf settings: net.ipv4.ip_local_port_range = 1024 65535 net.ipv4.tcp_tw_reuse = 1 However we are still experiencing this problem. Both of our (currently, two) relay servers suffer from the same problem, at the same time. They are AMD Epyc 7402P bare-metal servers each with 96GB RAM, each has 20 exit relays on them. This issue persists after upgrading to 0.4.7.11. Screenshots of perf top are shared here: https://digitalcourage.social/@EmeraldOnion/109440197076214023 Does anyone have experience troubleshooting and/or fixing this problem? Cheers, -- Christopher Sheats (yawnbox) Executive Director Emerald Onion Signal: +1 206.739.3390 Website: https://emeraldonion.org/ Mastodon: https://digitalcourage.social/@EmeraldOnion/

6 20

Next Tor Relay Operator Meetup - March 4, 2023 (19 UTC)
by gus 19 Mar '23

19 Mar '23

Hi, The next Tor Relay Operator Meetup will happen on March 4, 2023, at 19 UTC! We're still working on the agenda, feel free to add your topics and/or questions on the pad: https://pad.riseup.net/p/tor-relay-op-meetup-m4-keep onionsite: http://kfahv6wfkbezjyg4r6mlhpmieydbebr5vkok5r34ya464gqz6c44bnyd.onion/p/tor… WHERE Room link: https://tor.meet.coop/gus-og0-x74-dzn Registration No need for a registration or anything else, just use the room-link above. We will open the room 10 minutes before so you can test your mic setup. Please share with your friends, social media and other mailing lists! Gus -- The Tor Project Community Team Lead

6 7

Confusing bridge signs...
by Keifer Bly 18 Mar '23

18 Mar '23

Hi, So my bridge at https://metrics.torproject.org/rs.html#details/4D6E3CA2110FC36D3106C86940A1… says it has “none “, though the torrc file has it set to be distributed publicly. I'm wondering why the bridge would say that, when it obviously is being used as it's apparently blocked in Russia? I have not personally given the bridge to anyone. Thanks. --Keifer

5 25

export iptables metrics
by Toralf Förster 17 Mar '23

17 Mar '23

I found the time and wrote a Bash script [1] to export iptables and ipset metrics to Prometheus/Grafana. It works at least with [2]. [1] https://github.com/toralf/torutils/blob/main/metrics.sh [2] https://github.com/toralf/torutils#readme -- Toralf

1 0

Too Many Connections
by Jeff Teitel 15 Mar '23

15 Mar '23

My node is overloaded with connections. Conntrack.sh shows count: 65535. By far the majority (50k+) are to/from my own IP. This sometimes makes my node unreachable. And now it is reporting the StaleDesc flag. There is nothing else running on this node (except bind9). I've already set up tor-ddos. What else can I do? -- Jeff Teitel e-Mail: Jeff(a)Teitel.net Mobile: +1-202-271-1238 (he/his)

2 1

Relay requirements
by Sydney 10 Mar '23

10 Mar '23

Newbie here. No network experience but already running 2 TOR instances: 1 TOR service + 1 bridge. I would like to "upgrade" to TOR relays but have a few questions relating to hardware needs. The [TOR-friendly] ISP I'm looking at have these 4 offers available: [1] 1 core @ 3.1GHz 1 GB RAM 10 TB/mo @ 5 Gbps BW [2] 1 core @ 3.1GHz 2 GB RAM10 TB/mo @ 5 Gbps BW [3] 2 core @ 3.1GHz4 GB RAM20 TB/mo @ 5 Gbps BW [4] 3 core @ 3.1GHz 12 GB RAM30 TB/mo @ 5 Gbps BW From [relay requirements](https://community.torproject.org/relay/relays-requirements/), my understanding is that [1] is what is expected for a guard or middle relay and [2] for an exit relay. My preferred choice at the moment is [3] where I would like to have 3 relays (one of each type; 3.5 GB RAM needed). Each relay would be limited to, say, 6.6 TB/mo BW. This would allow me to experiment and get used to the network and its requirements. My questions is about future increase. If I want to increase my offer to the TOR network I could: - Negotiate with my ISP to increase my BW to 30 TB/mo while still running on [3] and increase each BW limit to 10 TB/mo; - Move my 3 relays on [4] and increase each BW limit to 10 TB/mo; - Move my 3 relays on [4], add 2 IP addresses and 6 relays (2 of each type; 10.5 GB RAM needed total), and limit each relay to 3.3 TB/mo. I guess my fundamental question is what is the advantage of running multiple relays of the same type, on the same server? I see some operators running dozens of them, all in the same country, same ISP. Why not just a single relay running with a large capacity? Also, is there a requirement for the number of relays per core? (Maybe this is the answer to my question.) I know my bridge is currently keeping one core of my 2-core server constantly under load. Thank in advance.

3 3

Draft workshop submission "Running a high-performance pluggable transports Tor bridge"
by David Fifield 07 Mar '23

07 Mar '23

Linus Nordberg and I have been working together to run the main Snowflake bridge since April 2022. We are preparing a short paper (4 pages) for the FOCI workshop (https://foci.community/) on the special procedures required to operate a bridge that gets the large volume of traffic that a Snowflake bridge does. This is a draft of the submission: https://www.bamsoftware.com/papers/pt-bridge-hiperf/pt-bridge-hiperf.202303… https://www.bamsoftware.com/papers/pt-bridge-hiperf/pt-bridge-hiperf.202303… I am posting the draft here to see if anyone has feedback or comments. If you do, our submission deadline is 2023-03-15. The main ideas were worked out in a thread on this very list: https://forum.torproject.net/t/tor-relays-how-to-reduce-tor-cpu-load-on-a-s… The core problem is that a single tor process is limited to a single CPU core. The main fix is to run multiple tor processes, and synchronize their identity and onion keys externally. It has been essential to enable scaling in the Snowflake bridge; but the same trick may be useful (minus the pluggable transport part) for other relays that process a much larger amount of traffic than average, such as large exit relays. (Though it's not clear that one exit with 2× the capacity is really any different than 2 exits in the same family.) This is also somewhat related to the current discussion about increasing the limit on the number of relays per IP address, which is a concession to the limited scalability of one tor process: https://bugs.torproject.org/tpo/core/tor/40744 > While this is great in general, it also adds significant complexity > for Tor operators since Tor does not scale well on multi-core CPU's. > In order to effectively use a modern server with a large amount of > threads, you would need to run many Tor relays.

1 0

D5A3882CBDBE4CAD2F9DDA2AB80FE761BEDC3F11 is spoofing my contact info
by lists＠for-privacy.net 06 Mar '23

06 Mar '23

This is _not_ my relay: https://metrics.torproject.org/rs.html#details/D5A3882CBDBE4CAD2F9DDA2AB80F… https://nusenu.github.io/OrNetStats/w/relay/D5A3882CBDBE4CAD2F9DDA2AB80FE76… -- ╰_╯ Ciao Marco! Debian GNU/Linux It's free software and it gives you freedom!

3 2

Storing ed25519_master_id_secret_key[_encrypted] on a smartcard?
by telekobold 04 Mar '23

04 Mar '23

Dear fellow relay operators, currently, I'm operating a Tor relay (Middle/Guard) and a Tor Bridge. Offline keys [1],[2] are a good way to secure a Tor relay, but I'm wondering if there is a standard way or something like a hacking guide how to store your ed25519_master_id_secret_key[_encrypted] on a smartcard or hardware token like a Nitrokey or Yubikey? This would even be more secure than storing it on a "normal" USB device. Unfortunately I have not found much about this on the internet. Kind regards telekobold [1] https://support.torproject.org/relay-operators/offline-ed25519/ [2] https://gitlab.torproject.org/legacy/trac/-/wikis/doc/TorRelaySecurity/Offl…

1 1

RFC: does a private exit would work?
by Toralf Förster 04 Mar '23

04 Mar '23

tl;dr; restricted access + usage of an exit longer: An exit is sooner or later abused. A reduced exit policy does not prevent that. What about setup a tor exit relay with 'PublishServerDescriptor = 0' ? Having an access line like for bridges would restrict the access. An alternative could be a port knockig + iptables solution. Objections and comments are welcome. -- Toralf

5 5