[tor-relays] obfs4 bridge current setup is not entirely clear

[s7r]

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20231108/a516c5db/attachment-0001.sig>