On Mittwoch, 8. November 2023 20:35:56 CET s7r wrote:
boldsuck wrote:
Not recommended, but rather a request to try it out.
So I tried, and besides the log messages that I have a descriptor mismatch I also get the status of my bridge as not running when ORPort is not exposed. The minute I switched ORPort to `localhost` the BridgeDB reported the bridge as not running, regardless it was actually running with the pluggable transport port open.
That is unfortunately the case. I checked whether they are online at: https://bridges.torproject.org/status?id=%5Bhashed_identity_key] On Tor metrics you can also see that the history continues.
Some info in the old thread https://lists.torproject.org/pipermail/tor-relays/2023-August/021259.html
Relevant tiket from meskio: https://gitlab.torproject.org/tpo/anti-censorship/team/-/issues/129
Thank you, yes. But unfortunately I think we are going to need a proposal for this, to document various use cases and maybe clone the code that does the ORPort reachability check to do pluggable transport port reachability test, then build descriptor and then publish, but this needs ORPort like behavior like NoListen, etc.
That'd be good
I've gradually reconfigured _all_ bridges over the last 2 months: The number of connections/users has stayed pretty much the same. Bridges with setting "BridgeDistribution any" the distribution method has not changed.
OrPort must forwarded or should not firewalled otherwise the status will be dysfunctional on https://bridges.torproject.org/status
I don't care to use BridgeDistribution param, I let BridgeDB decide this randomly
Me too. "BridgeDistribution any" is tor default setting.
but configured without public open ORPort I don't get the running flag, I get that bridge is down, while it's not actually.
So what is the best way to for an user to open both IPv4 and IPv6 pluggable transport ports?
The ServerTransportListenAddr line is dual stack friendly. ServerTransportListenAddr obfs4 [::]:8443
So I saw yes, I was able to use [::]:80 to bind to all interfaces in dual stack mode but I am not sure the clients are served both the IPv6 line and the IPv4 line, I think it's just one of them and I was curious which one and what logic is applied to determine it. This means that currently one cannot setup a dual stack pluggable transport bridge, it must be either IPv4 either IPv6, right?
If I use my dual stack bridges with TorBrowser or HS clients, I can use IP and IPv6.
2023-11-08 21:15:20.815 [NOTICE] Bridge 'ForPrivacyNET' has both an IPv4 and an IPv6 address. Will prefer using its IPv6 address ([2001:db8:1::228]:11228) based on the configured Bridge address. 2023-11-08 21:15:21.712 [NOTICE] Bridge 'ForPrivacyNET' has both an IPv4 and an IPv6 address. Will prefer using its IPv4 address (203.0.113.228:11228) based on the configured Bridge address.