this won't work for everyone. Depending on how you configure your container to network, this may or may not need tweaks. I just know it works for the few containers I usually use.
This will never work because neither docker nor most vpns will stop taking over IP-subspaces by default, disrespecting other software who might also need them. Docker is especially bad with this, since it doesnt even give you a proper error but simply crashes with the "can't connect to docker daemon" error with is very misleading.
- make sure docker starts first, i.e. before you connect your vpn. The easiest way to do this is by telling
systemdto start it by default
systemctl enable docker (requires restart)
- start your VPN
Now you should be able to deploy docker images.
Since docker started before the VPN, it still thinks it is in charge of the network and will probably work but not through the VPN. This is especially noticable if you use a kill-switch, resulting in the containers' connections timing out.
docker network list
-
find the bridge setup by dockerfile/docker-compose/etc. It will have a set name, and
bridgeas driver. -
Delete it. We will help docker setup a better subspace, but DON'T delete the bridge with NAME bridge!
docker network rm <name-that-is-not-bridge>
-
stop the container. Docker can't hotswap networks without the containers noticing.
-
Setup a less aggressive subspace. Use the same name as in the removal above.
docker network create --driver=bridge --subnet=192.168.0.0/16 <name-that-is-not-bridge>
- Now try to start up your container-based application again. It should route traffic over the VPN now.
If your container network name is consistent, you will only have to do this once. Docker does not overwrite existing networks so it will use your self-made network without noticing.