Separate Docker stacks using gluetun networking
from Dust0741@lemmy.world to selfhosted@lemmy.world on 07 Oct 14:15
https://lemmy.world/post/37034737

I would like to run Gluetun in its own compose.yaml file, and run qbittorrent in its own compose.yaml file. I want to use the vpn connection Gluetun makes for qbittorrent.

Does anyone have examples of this working? I’ve been messing with the containers, and different docker networks can I cannot get it working.

(my test has been running docker exec -it qbittorrent curl -s https://ifconfig.me/)

#selfhosted

threaded - newest

doeknius_gloek@discuss.tchncs.de on 07 Oct 14:32 next collapse

Maybe try this: docs.docker.com/compose/how-tos/…/merge/

Dust0741@lemmy.world on 07 Oct 15:59 collapse

I don’t want to merge them, I specifically would like them separate.

CumBroth@discuss.tchncs.de on 07 Oct 14:47 next collapse

You could use network_mode: “container:{name}” instead of service:{name}. See here docs.docker.com/reference/compose-file/services/#…

Service definitions have to be defined in the same compose file or merged into one file at some point in order to be able to reference each other. Containers don’t have that restriction.

Dust0741@lemmy.world on 07 Oct 15:59 next collapse

network_mode is only for multiple containers in the same stack.

CumBroth@discuss.tchncs.de on 07 Oct 19:23 collapse

Uhh, I think you might be confused. Let me explain a bit more:

  1. Services and Containers aren’t the same thing. The distinction usually doesn’t matter in typical self-hosting scenarios, but in this case it does.

In short: Services are what you define in a compose file; Containers are what you spin up based on those service definitions.

  1. network_mode is a service attribute and it can be defined for each service separately.
  2. network_mode: “service:{name}” requires the service being referenced to be part of the same stack. This is probably what you were thinking of when you wrote this reply.
  3. network_mode: “container:{name}” can freely reference any preexisting container. This helps you achieve what you want. You can define your gluetun container independently, along with any services you might want to be part of the same stack, and give it a unique identifier using container_name: myIndependentGluetun. After spinning it up, run your Qbittorrent container or whatever service you want to route through the gluetun container after adding network_mode: “container:myIndependentGluetun”.

You could also route it manually. That’s a more advanced solution, but it’s more convenient than the network_mode approach. More on this here: discuss.tchncs.de/post/19039498

Dust0741@lemmy.world on 07 Oct 20:14 next collapse

Oooooooooooo I totally was confused. Thank you for this!!!

Dust0741@lemmy.world on 08 Oct 12:10 collapse

Amazing this worked great!!!

One question though; How do I get qbittorrent to auto reconnect if gluetun gets restarted? (currently checking public ip per above fails if gluetun gets restarted, and the only way to fix is by restarting qbittorrent.)

CumBroth@discuss.tchncs.de on 09 Oct 03:28 collapse

This is an annoying quirk in the way docker handles networking between containers and I couldn’t find a good solution for this issue when I was trying out network_mode. I just couldn’t find a way to set docker up to automatically restart the dependent container. You can achieve this with services defined in the same stack (using depends_on), but I don’t know if it’s possible with your current setup.

That’s why I mentioned manual routing in my other reply. It’s annoying to set up, but more convenient because you avoid having to manage restarts (or figuring out how to get docker to do it, which may not be possible in this case).

lem@lemmy.world on 07 Oct 16:07 collapse

I have gluetun and qbittorrent running separately and this works for me.

RyanDownyJr@lemmy.world on 07 Oct 16:12 next collapse

youtu.be/hgcFdUIOf5M

I’m pretty sure this is the video I used to setup mine awhile back. I have my deluge docker networked into Gluetun. Everything else flows normal.

GuillaumeRossolini@infosec.exchange on 07 Oct 23:39 next collapse

@Dust0741 you could also get each container to access the other by specifying the stack prefix

Say you have stack1 and stack2

Stack1 can have

networks:
  stack2_default:
    external: true
services:
  foo:
    networks:
      - default
      - stack2_default
ki9@lemmy.gf4.pw on 08 Oct 00:22 next collapse

In the qbt compose file, you can set

network_mode: container:gluetun

To use Gluetun’s network namespace for your qbt container. This is how I use qbt over vpn.

Selfhoster1728@infosec.pub on 09 Oct 10:00 collapse

I had a problem similar to this and did not like the containers being binded to gluetun (problematic on docker daemon restarts, gluetun container being recreated, etc)

My solution was changing the gateway of each container to be routed through the tun. So first by having them both on the same internal network, then changing the entrypoint of the container I want tunneled to include the gateway change.

For example my entrypoint would be:

… && route del default && route add default gateway $GATEWAY_IP eth0

The container may be missing packages related to route so it may be necessary to modify the Dockerfile to install extra packages.

The reason the gateway must be set at the entrypoint is because docker overrides the gateway to correspond with the networking defined during container creation. And the entrypoint is the last thing executed before the container starts for realsies.

However gluetun also needs to work as a gateway which is done by modifying it’s iptables post-up rules file (at /iptables/post-rules.txt). I appended at the beginning of the file the following rules:

iptables -A FORWARD -i eth0 -o tun0 -s 172.84.0.0/24 -d 0.0.0.0/0 -j ACCEPT iptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i tun0 -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

What this does is accept any traffic from the net I have my gluetun and other container in, then forwards outgoing traffic to eth0 from tun0, and vice versa for incoming.

Sorry for wall of text this is not very straight forward :(