Hello there,
i’m currently trying to setup another obfs4 bridge. I have already set up one a while ago directly on a host which is working fine so far. For my new bridge i decided to go the container way however. For simplicity i decided to keep the configuration on the bare minimum at first (copied default docker compose and adjusted .env-file), as i am not a docker/podman expert.
My infrastructure looks like this:
Bridge container (podman) —> host with firewall —> provider firewall
So far i was able to configure the container based on the instructions on torproject.org and got it up and running. I also verified it working by using it within the tor browser.
I do however face some weird issues with the bridge that i do not seem to be able to figure out (didn’t have them when running the bridge directly on host in the past):
- Inspecting the logs from the container i always observe that the bridge seems to fail it’s reachability test. This seems odd to me as i have made rules in both firewalls for the configured OT- and PT-Port. I have also verified this with the ‘TCP reachability check’-tool and with using the bridge in the tor browser. Is this expected behavior of running the bridge inside a container? If not, has anybody here any tips to resolve this?
- Searching with the ‘Relay Search’-tool on tor metrics i can already find my newly configured bridge. It does however report it as offline. This also seems odd to me as i have no problems with using the bridge, thus it should be reported as online. Has this something to do with the reachability check of the bridge always failing? If yes, why am i able to find an entry on tor metrics for it if it is/was never able to successfully complete the check?
- The .env file for the container includes some options to configure the OT- and PT-Ports (and some additional stuff). It does however not include any options to report the ipv4 & ipv6 addresses for the bridge. For ipv4 this seems fine as the bridge can get that info from outside. For ipv6 this does however not work. Is there any (other) way to still configure ipv6 for a bridge running inside or container?
I would be really glad about any input.
1 Like
Little update as i kept tinkering with my setup while this post waited for approval:
Inspecting the logs from the container i always observe that the bridge seems to fail it’s reachability test. This seems odd to me as i have made rules in both firewalls for the configured OT- and PT-Port. I have also verified this with the ‘TCP reachability check’-tool and with using the bridge in the tor browser. Is this expected behavior of running the bridge inside a container? If not, has anybody here any tips to resolve this?
I was actually able to solve this. The issue seems to be related to how podman does networking with rootless containers. During further research i stumbled upon the different network modes one can use for containers. With the network mode ‘pasta’ the container actually realizes that it is reachable from the outside. Communication with tor metrics also seems to work now.
Heads-up for people reading this: As i understand ‘pasta’ should be the default network mode for rootless containers in the current version of podman (for me it was not). Also be cautions about how you configure your containers (e. g. cli, gui, podman-compose, … etc.). Some of those still don’t fully support every feature of podman (-> may require some tinkering to get it to work).
The .env file for the container includes some options to configure the OT- and PT-Ports (and some additional stuff). It does however not include any options to report the ipv4 & ipv6 addresses for the bridge. For ipv4 this seems fine as the bridge can get that info from outside. For ipv6 this does however not work. Is there any (other) way to still configure ipv6 for a bridge running inside or container?
I kind of solved this too. Additionally to setting the network mode of the container to ‘pasta’ i also bound the OT- and PT-Port explicitly to an interface (ip-address for linux). Suddenly the container seems to recognize those ip-addresses on startup (ipv4 and ipv6).
Nevertheless i still do have some problems with the current container image and configuration:
- The installed tor version inside the official image seems to lag behind the official release version. Currently still unsure if this is really a problem but i still find it kinda odd that the image doesn’t seem to be up-to-date. There are some other unofficial images on docker hub, which are already on the current version, but i guess those are to be used with caution.
- I kinda do not like the the default docker-compose.yml and .env file that gets recommended on torproject.org. While it does seem to be tailored more for ‘fire-and-forget’ (easy setup) it seems to lack the capability to be tweaked for more advanced usage. While there is the option to set some more torrc settings via environment variables some things are not (easily) possible (e. g. ipv6, socks proxy, nyx, … etc.). I guess tailoring your own custom container is a necessity for this in the long run.
1 Like