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.
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…
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
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
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
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
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.
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
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