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.
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.
[warn] The IPv6 ORPort address ::1 does not match the descriptor address REAL_IPv6_ADDRESS. If you have a static public IPv4 address, use 'Address <IPv6>' and 'OutboundBindAddress <IPv6>'. If you are behind a NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort <InternalPort> NoAdvertise'.
Yes you can ignore the logs. Not exposing OrPort for bridges is still experimental feature.
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 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?