- tor-relays - lists.torproject.org

Metrics
by BridgeOverStyx 08 Sep '23

08 Sep '23

My bridge styxVortex is up and running. I know this because the Nyx monitor shows activity. However, a search of metrics.torproject.org shows it down. It has been in this state for at least a month. Do you have any suggestions of what could be the possible cause of this? I am using pfblockerng on my network, but the machine that is running Tor bridge is not filtered by it. I do have a couple of TOR feed enabled in pfblockerng but only incoming traffic is filtered. I have no idea how the bridge stats are passed to metrics.torproject.org so it is very challenging for me to tamp down on the cause. Any suggestion, at this point, will be helpful. Sent with [Proton Mail](https://proton.me/) secure email.

6 9

Quick bugfix sharing regarding obfs4 malfunctioning
by telekobold 07 Sep '23

07 Sep '23

Hi, I just want to share some quick bugfix with you (sorry if this is obvious to you or has been written somewhere else). Suddenly, I got the following error messages on my two bridges running on Debian 11 appearing in the logs (in /var/log/tor/notices.log and in the nyx output) every second until a restart: <timestamp> [warn] Managed proxy "/usr/bin/obfs4proxy" process terminated with status code 65280 <timestamp> [warn] Server managed proxy encountered a method error. (obfs4 listen tcp 0.0.0.0:443: bind: permission denied) <timestamp> [warn] Managed proxy '/usr/bin/obfs4proxy' was spawned successfully, but it didn't launch any pluggable transport listeners! When restarting the corresponding bridge, in the startup process the second and the third of the above warning messages again appeared in the logs. So obfs4 was suddenly not usable any more. Port 443 is not blocked in the bridge's firewalls. A bit research reveled that apparently, an automatic update set the systemd setting "NoNewPrivileges=no" in /lib/systemd/system/tor(a)default.service and tor@.service [1] back to yes, which caused the above issue. After setting it back and restarting, everything works fine now and instead of the warning messages mentioned above, the following message appears in the log again: <timestamp> [notice] Registered server transport 'obfs4' at '[::]:443' (Several places recommend to set the obfs4 port to 443 to get around restrictive firewalls, so I didn't want to set it to something else). Kind regards telekobold [1] http://xmrhfasfg5suueegrnc4gsgyi2tyclcy5oz7f5drnrodmdtob6t2ioyd.onion/relay…

3 2

(Last call) Bridges running obsolete Tor version (0.4.5.x) to be removed soon
by gus 05 Sep '23

05 Sep '23

Hi bridge operators, Serge, the Bridge Authority is about to update their Tor version to 0.4.8.5 and it will reject bridges running the Tor version 0.4.5.x. Please upgrade your bridge if you're running an outdated version (0.4.5.x) ASAP. List of outdated bridges: https://metrics.torproject.org/rs.html#search/type:bridge%20version:0.4.5%20 Thanks for helping censored users to bypass censorship! cheers, Gus -- The Tor Project Community Team Lead

2 1

relayor v23.2.0 is released
by nusenu 28 Aug '23

28 Aug '23

Hi, relayor v23.2.0 is released. relayor is an ansible role that helps you with running tor relays with minimal effort (automate everything). https://github.com/nusenu/ansible-relayor#main-benefits-for-a-tor-relay-ope… This release includes new prometheus alert rules so you do not forget to renew your relay certificates before they expire. This feature requires tor version 0.4.8 though which is unfortunately not yet available on deb.torproject.org stable repos. It also includes rules that alert you if your exit relay has an unhealthy DNS timeout fraction or if your relay is dropping onionskins for at least 15 minutes. Changelog: https://github.com/nusenu/ansible-relayor/releases/tag/v23.2.0 kind regards, nusenu -- https://nusenu.github.io

1 0

Exit Relays: What is your DNS timeout rate?
by nusenu 26 Aug '23

26 Aug '23

Hi, the upcoming relayor release will contain new prometheus alert rules that should help operators detect/mitigate/prevent some common operational issues. One of these rules will alert on high DNS timeout rates [1] on exit relays that should be investigated and resolved to improve the Tor Browser experience for users. To define the default alert threshold it would be relevant to know current timeout rates by multiple exit operators. So if you feel up to it you can send me (off-list) your current timeout rates (30 day graph): If you run tor exits with relayor and MetricsPort enabled you can use these Prometheus queries: timeout percentage by server: (sum by (instance)(rate(tor_relay_exit_dns_error_total{reason="tor_timeout"}[15m])))/(sum by (instance)(rate(tor_relay_exit_dns_query_total[15m])))*100 DNS query rate: sum by (instance)(rate(tor_relay_exit_dns_query_total[15m])) If you run exits without relayor you can use these queries: (sum by (job)(rate(tor_relay_exit_dns_error_total{reason="tor_timeout"}[15m])))/(sum by (job)(rate(tor_relay_exit_dns_query_total[15m])))*100 sum(rate(tor_relay_exit_dns_query_total[15m])) kind regards, nusenu [1] https://github.com/nusenu/ansible-relayor/commit/9b6937563ec0b41e6abb0217ed… -- https://nusenu.github.io

1 0

Wrong "first seen" flag for bridges at metrics.torproject.org
by telekobold 23 Aug '23

23 Aug '23

Hi together, I have an issue regarding the "first seen" flag at metrics.torproject.org: It is definitely wrong for my two bridges - both dates are much too close in the past. For one of the bridges, it seems to correspond to the last signing key renewal, for the other bridge, it seems to correspond to the penultimate signing key renewal. Has anyone observed similar behavior for its relay? (I found it meaningful to first ask here before creating an issue at [*]). [*] https://gitlab.torproject.org/hiro/onionoo/-/issues Kind regards, telekobold

3 2

Tor-Bridge
by tor＠pqpera.xyz 19 Aug '23

19 Aug '23

Possible compression bomb; abandoning stream. <- Happened to my server for 2h straight. Should I take any measures against that? Bridge is obsf4 with fingerprint: 2EA91C1415C421424BB478A55790E655627DE366.

2 1

Tor Relay in Kubernetes cluster
by Daniel Nikoloski 18 Aug '23

18 Aug '23

Hi all, Is anyone running Tor relay in k8s cluster? I am trying for a few days but It does not come alive. My servers are not behind a firewall, should be and are accessible, I run two bare-metal servers in Contabo. 1 master 1 node. Docker image and helm chart that use; https://gitlab.com/nikoloskid/tor-server The logs I get; > Aug 05 21:04:55.000 [notice] Now checking whether IPv4 ORPort 38.242.233.101:32150 is reachable... (this may take up to 20 minutes -- look for log messages indicating success) > Aug 05 21:24:45.000 [warn] Your server has not managed to confirm reachability for its ORPort(s) at 38.242.233.101:32150. Relays do not publish descriptors until their ORPort and DirPort are reachable. Please check your firewalls, ports > > , address, /etc/hosts file, etc. When i try telnet it is open to the internet > telnet 38.242.233.101 32150 > Trying 38.242.233.101... > Connected to 38.242.233.101. > Escape character is '^]'. You can see the service here; https://gitlab.com/nikoloskid/tor-server/-/raw/helm-chart-tor-relay/tor-ser… /etc/tor/torrc; > Nickname icebergk8s > Address 38.242.233.101 > ContactInfo nikoloskid(a)pm.me > RelayBandwidthRate 3.5MB > RelayBandwidthBurst 5MB > MaxAdvertisedBandwidth 5MB > ORPort 9001 NoAdvertise IPv4Only > ORPort 32150 NoListen IPv4Only > SocksPort 0 > ExitPolicy reject *:* > User debian-tor > DataDirectory /var/lib/tor Lep pozdrav / Best Regards, Daniel Nikoloski

2 1

Tor Relay Operator meetup @ CCCamp 2023 - Saturday 19th @ 7pm
by gus 17 Aug '23

17 Aug '23

Hello, The Tor Relay Operator Meetup - Chaos Communication Camp-2023[1] will happen at Bornhack (Cold North Village)[2] on Saturday, August 19th at 7pm (local time). After the meetup, we invite everyone to stay and have beer and drinks at Bornhack. Please spread the message. We have Tor stickers for you! :) Gus [1] https://events.ccc.de/camp/2023/infos/ [2] Coordinates: 53.0314175, 13.3065457 https://map.events.ccc.de/camp/2023/map/#20/53.03143/13.3066 -- The Tor Project Community Team Lead

2 4

WebTunnel: What ASNs/networks work best?
by tor-home at encryptfirst.com 17 Aug '23

17 Aug '23

When running a WebTunnel bridge, what types of IPs are better for serving requests? My background is with self-hosted home-lab type of setups. There are a number of different ways for homelabs to accept inbound https connections. A few examples: - Forward a port on a home router. - Rent a cloud VM/VPS and tunnel a port from the VPS's IP. - Have a CDN tunnel/forward requests. - VPN hybrid solutions like Tailscale Funnel. Are any of these better than others for hosting a WebTunnel bridge? Should cloud provider IPs be preferred over residential IPs, for example, considering that is where most web servers are hosted? Are large CDNs preferred over individual cloud VMs? Is it better to use a different IP for WebTunnel than the IP that runs the OR port (i.e. host OR port on home IP and WebTunnel from a cloud-based IP)? I'm mainly asking to determine which way helps the broadest number of Tor users. And which is less likely to be blocked in the future. What are the best practices? PS: Thanks for the webtunnel-bridge Docker image and the documentation on how to run it. It was very helpful and made setup easy.

4 4