Hi Micah! Is the georgetown bridge is flaky as it seems? We have alerts
set up for the default bridges and it seems like yours alerts a lot
and the others alert rarely. It always comes back after a little while,
so this isn't a "hey your bridge is down" mail so much as a "what's up
with your bridge" mail.
I wonder if it is an issue with the network it's running on; or if it's an
issue with the bridge itself, e.g. maybe there is something in Tor's logs
that could help diagnose; or if it's something wonky about our alerts.
(I am cc'ing anti-censorship-team so others can coordinate and stay
in sync; note that this is a public list with archives.)
Thanks!
--Roger
----- Forwarded message from Monit <anti-censorship-monitor(a)nymity.ch> -----
Date: Thu, 19 Jan 2023 12:26:36 GMT
From: Monit <anti-censorship-monitor(a)nymity.ch>
To: anti-censorship-alerts(a)lists.torproject.org
Subject: [anti-censorship-alerts] monit alert -- Connection failed
default-bridge-georgetown
X-Mailer: Monit 5.26.0
Connection failed Service default-bridge-georgetown
Date: Thu, 19 Jan 2023 13:26:35
Action: alert
Host: server01
Description: failed protocol test [DEFAULT] at [209.148.46.65]:443 [TCP/IP] -- Connection timed out
_______________________________________________
anti-censorship-alerts mailing list
anti-censorship-alerts(a)lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/anti-censorship-alerts
----- End forwarded message -----
Greetings,
I hope this is an appropriate mailing list to discuss a technical issue
with Tor's Snowflake project. Please redirect me to the right place if not.
I am the original author and maintainer of the open source project,
Stuntman. Stuntman is an implementation of the STUN protocol, which
includes the STUN server. More details at www.stunprotocol.org. In short,
a STUN server helps bootstream direct "p2p" connections such as WebRTC
sessions or similar VOIP scenarios by allowing internet devices to
self-discover their own public IP address and obtain a (UDP) port for
communicating with another node.
I also run a public instance of a STUN server with the code at
stun.stunprotocol.org. It's been up and running for about 10 years
now. It's hosted on AWS. In recent years, the hosting bills for this
server have started to get on the high side, even with reserved instances.
The number of STUN queries it processes per day is now on the order of
hundreds of millions. The stunprotocol.org domain receives nearly a million
DNS queries on Route 53 daily. What used to cost a trivial number of
dollars to run is now starting to reach $1000 in annual service costs.
This isn't paid for by a corporation or well funded internet organization.
I pay this out of my personal pocket.
It's been a mystery what has been driving the increasing traffic to the
server - especially redundant requests from the same IPs. I was inspecting
the DNS logs the other day and started to investigate the nodes sending out
redundant DNS requests repetitively. Trying to understand why these nodes
wouldn't leverage DNS caching. And to my surprise, one of the IPs was
running a web server that presented a TOR landing page. That led me to
discover this discussion online:
https://gitlab.torproject.org/tpo/anti-censorship/pluggable-transports/snow…
And a quick inspection of the Snowflake code leads me to find that
stun.stunprotocol.org is the default STUN server for Snowflake proxy and
listed throughout the documentation as well.
While the Snowflake project has good intentions, it doesn't appear to take
my hosting costs into consideration. I'm hoping we can have a good
discussion on the following:
1) How many snowflake clients and proxies are active and how many STUN
requests are each generating towards stunprotocol.org? Do we think the
entire worldwide usage of Snowflake could be responsible for millions of
STUN queries to stunprotocol.org per day?
2) Expected number of DNS queries (it's a 3-day TTL on these DNS entries,
so it blows my mind that there are so many redundant requests). Does Pion
or any other part of the Snowflake code tend to go direct to the namespace
server itself?
3) Removing stun.stunprotocol.org as the default STUN server.
OR...
4) Alternatively, I'm always open to accepting donations to help run the
service costs of stunprotocol.org. I'm definitely not getting rich running
this thing.
Thanks,
John Selbie