[tor-relays] obfs4 bridge current setup is not entirely clear
s7r
s7r at sky-ip.org
Wed Nov 8 16:42:46 UTC 2023
Hi,
I ran into some new IP space and I decided to change a cluster of obfs4
bridges that are more than 4 year old. When I set them up I don't
remember spending so much time.
So, Debian latest and Tor latest from deb.torproject.org nightly.
GoLang from the official website (as it's the latest version) and
obfs4proxy cloned from its default git repository.
1. The page at
https://community.torproject.org/relay/setup/bridge/debian-ubuntu/ needs
a small revision.
This page must be changed, for Debian it doesn't work simply $ edit
tor at .service tor at default.service , change to NoNewPrivileges=no, save
and quit.
For me it only worked by editing
/lib/systemd/system/tor at .service and
/lib/systemd/system/tor at default.service with NoNewPrivileges=no and then:
$ sudo systemctl daemon-reload.
Setcap command is ok but it also need to mention to install the package
in Debian libcap2-bin as well as an additional step:
Under Debian, if obfs4proxy is installed in a different place, for
example like in its git documentation /usr/local/bin/obfs4proxy then you
also need to edit this file:
/etc/apparmor.d/abstractions/tor
and add one line (or change the default obfs4proxy line to):
/usr/local/bin/obfs4proxy Pix,
Substitute path if different and then:
$ sudo systemctl restart apparmor.
------------------------------------------------
2. It was recommended on the mail list that obfs4 bridges should not
open their ORPorts publicly to prevent scanning the entire 1-65536 port
range and determine it's a Tor bridge. OK.
But if you try:
ORPort 127.0.0.1:auto
ORPort [::1]:auto
AssumeReachable 1 # needed to skip ORPort reachability test
Tor will start but it will constantly complain in the log with:
[warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor
address REAL_IPv4_ADDRESS. If you have a static public IPv4 address, use
'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a
NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort
<InternalPort> NoAdvertise'.
[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'.
I guess it's OK to continue to run it even with this as I do understand
the log messages and it's the desired effect, but isn't it confusing for
less experienced users? They might think something is wrong when it is not.
The recommended way is to add a simple logic to skip that check, because
we can't remove it, it's vital necessary for relays (not bridges) behind
NAT or dynDNS or whatever. So if BridgeRelay 1 is set and
$some_transport enabled, ignore the ORPort and descriptor check / log.
and instead check the pluggable transport if port open and listening.
Or even better, code a pluggable transport port reachability test before
building and uploading the descriptor, by cloning the code that does
this for ORPorts to the pluggable transport ports. This would need a
proposal that covers all use cases.
3. ServerTransportListenAddr can be used just once and it's difficult
for dual-stack which is now the vast majority.
It's known for many years that each pluggable transport supports just
one ServerTransportListenAddr line, the second one is simply ignored.
Tickets for this exist.
So what is the best way to for an user to open both IPv4 and IPv6
pluggable transport ports?
In Debian I have achieved it by using as wildcard
ServerTransportListenAddr [::]:80 since the wildcard [::] under Debian
binds to all IPv4 and IPv6 addresses on all interfaces, but this might
not be the same for all operating systems.
Also, how does BridgeDB determine in case wildcard [::] is used if the
pluggable transport is IPv4, IPv6 or both? Which one is used when
BridgeDB sends this bridge to clients?
-------------- 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/416cc8d8/attachment.sig>
More information about the tor-relays
mailing list