I honestly can’t get my head around this. I have a machine with Linux (endeavouros), and docker with a few containers. Since I want all the traffic from this system to go through the VPN, do I need to set up gluetun? I think not, but I am not 100% sure…
I’ll ask this question because it might be something you didn’t think of.
What happens to your network connection if the VPN fails? will it continue to connect without a VPN?
I had a similar case of that happening, and ended up causing me to get some shame mail from my ISP.
now I run my VPN inside docker, and any containers that need access to it are configured as network slaves to it. VPN goes down? container reboots, all the others reboot after connection is restored, but will have no connection while it’s down.
it’s all in a well designed system of healthchecks and container configuration.
You can force all outgoing traffic to use the VPN interface via iptables/routes (meaning if it doesn’t exist or doesn’t work nothing will be able to access the internet) OR use systemd globally hide the non-VPN network interface from all services except for the VPN client.
IMO this is the best OS way, but without nix it’s a pita to maintain through restores/rebuilds. personally I never fully comprehended how to properly configure iptables/routes (I did try though, so nobody can blame me lol).
however, a major benefit to using a contained VPN or gluetun is that you can be selective on what apps use the VPN.
I host 12 other containers (with nas mounts) on the same host outside of the three that need to use a VPN, so this is why the solution I described works for me. and should I ever need to use routes for more advanced network filtering I still have it available without adding the complexity of splitting normal traffic vs VPN traffic.
but without nix it’s a pita to maintain through restores/rebuilds.
No it isn’t. You can even define those routing polices in your systemd network unit alongside the network interface config and it will manage it all for you.
If you aren’t comfortable with systemd, you can also use simple “ip” and “route” commands to accomplish that, add everything to a startup script and done.
major benefit to using a contained VPN or gluetun is that you can be selective on what apps use the VPN.
Systemd can do that for you as well, you can tell that a certain service only has access to the wg network interface while others can use eth0 or wtv.
More classic ip/route can also be used for that, you can create a routing table for programs that you want to force to be on the VPN and other for the ones you want to use your LAN directly. Set those to bind to the respective interface and the routing tables will take place and send the traffic to the right place.
You’re using docker or similar, to make things simpler you can also create a network bridge for containers that you want to restrict to the VPN and another for everything else. Then you set the container to use one or the other bridge.
There are multiple ways to get this done, throwing more containers, like gluetun and dragging xyz dependencies and opinionated configurations from somewhere isn’t the only one, nor the most performant for sure. Linux is designed to handle this cases.
Yes, there’s many ways to make programs unable to use other network interfaces. E.g. I’m creating a network namespace with a single wg0 interface, which I make services use through systemd NetworkNamespacePath.
That said, I’d argue gluetun is pretty much foolproof, especially with most people using docker which messes with iptables (edit: although I don’t know if this’d be an issue for this use case).
I simply enable the killswitch in mullvad settings and get all the Linux isos I need. But I’m thinking to keep gluetun enabled since I’ve already configured it
I would recommend it. Speaking from personal experience, I trusted my VPN connection to remain on and self-heal. Thinking that cost me a strike against my ISP.
Now I know for a fact that if anything goes wrong with the VPN connection, all the containers that need it will need to restart before they have connectivity again and that can only happen after the VPN container restarts and passes healthcheck.
It’s convenient if you want to see gluetun up as the only way a container (say, your torrenting container) can get to the open net, in the interest of avoiding getting directly pinged by DMCA rats. That way, if the VPN goes down, your torrent client isn’t just downloading stuff nakedly. Also, if you want to set up different VPN connections for different containers, it’s pretty easy to set a handful of replica containers for that too.
All of that can be achieved with simple systemd or iptables/routes tweaks. You can force all outgoing traffic to use the VPN interface via routes (meaning if it doesn’t exist or doesn’t work nothing will be able to access the internet) OR use systemd globally hide the non-VPN network interface from all software except for the VPN client.
Well sure, but the question was about gluetun, so I was trying to focus on that and the applications thereof. In terms of homelab stuff, I know a lot of people appreciate the containerized approach.
Yeah, when you have the VPN running all of your external traffic should go through it. It starts to get complicated when you only want a specific container/user to use/bypass the VPN.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
I’ll ask this question because it might be something you didn’t think of.
What happens to your network connection if the VPN fails? will it continue to connect without a VPN?
I had a similar case of that happening, and ended up causing me to get some shame mail from my ISP.
now I run my VPN inside docker, and any containers that need access to it are configured as network slaves to it. VPN goes down? container reboots, all the others reboot after connection is restored, but will have no connection while it’s down.
it’s all in a well designed system of healthchecks and container configuration.
You can force all outgoing traffic to use the VPN interface via iptables/routes (meaning if it doesn’t exist or doesn’t work nothing will be able to access the internet) OR use systemd globally hide the non-VPN network interface from all services except for the VPN client.
IMO this is the best OS way, but without nix it’s a pita to maintain through restores/rebuilds. personally I never fully comprehended how to properly configure iptables/routes (I did try though, so nobody can blame me lol).
however, a major benefit to using a contained VPN or gluetun is that you can be selective on what apps use the VPN.
I host 12 other containers (with nas mounts) on the same host outside of the three that need to use a VPN, so this is why the solution I described works for me. and should I ever need to use routes for more advanced network filtering I still have it available without adding the complexity of splitting normal traffic vs VPN traffic.
No it isn’t. You can even define those routing polices in your systemd network unit alongside the network interface config and it will manage it all for you.
If you aren’t comfortable with systemd, you can also use simple “ip” and “route” commands to accomplish that, add everything to a startup script and done.
Systemd can do that for you as well, you can tell that a certain service only has access to the wg network interface while others can use eth0 or wtv.
More classic ip/route can also be used for that, you can create a routing table for programs that you want to force to be on the VPN and other for the ones you want to use your LAN directly. Set those to bind to the respective interface and the routing tables will take place and send the traffic to the right place.
You’re using docker or similar, to make things simpler you can also create a network bridge for containers that you want to restrict to the VPN and another for everything else. Then you set the container to use one or the other bridge.
There are multiple ways to get this done, throwing more containers, like gluetun and dragging xyz dependencies and opinionated configurations from somewhere isn’t the only one, nor the most performant for sure. Linux is designed to handle this cases.
Yes, there’s many ways to make programs unable to use other network interfaces. E.g. I’m creating a network namespace with a single wg0 interface, which I make services use through systemd NetworkNamespacePath.
That said, I’d argue gluetun is pretty much foolproof, especially with most people using docker which messes with iptables (edit: although I don’t know if this’d be an issue for this use case).
I simply enable the killswitch in mullvad settings and get all the Linux isos I need. But I’m thinking to keep gluetun enabled since I’ve already configured it
I would recommend it. Speaking from personal experience, I trusted my VPN connection to remain on and self-heal. Thinking that cost me a strike against my ISP.
Now I know for a fact that if anything goes wrong with the VPN connection, all the containers that need it will need to restart before they have connectivity again and that can only happen after the VPN container restarts and passes healthcheck.
It’s convenient if you want to see gluetun up as the only way a container (say, your torrenting container) can get to the open net, in the interest of avoiding getting directly pinged by DMCA rats. That way, if the VPN goes down, your torrent client isn’t just downloading stuff nakedly. Also, if you want to set up different VPN connections for different containers, it’s pretty easy to set a handful of replica containers for that too.
You always just bind the torrent client to the VPN adapter so this doesn’t happen. Most modern clients have this (qBittorrent certainly does)
Oh yeah you can do it that way too, but if you want it all containerized, that’s roughly how to do it. That’s all I meant.
All of that can be achieved with simple systemd or iptables/routes tweaks. You can force all outgoing traffic to use the VPN interface via routes (meaning if it doesn’t exist or doesn’t work nothing will be able to access the internet) OR use systemd globally hide the non-VPN network interface from all software except for the VPN client.
Well sure, but the question was about gluetun, so I was trying to focus on that and the applications thereof. In terms of homelab stuff, I know a lot of people appreciate the containerized approach.
What I said applies to containerized setups as well. Same logic, just managed in a slightly different way.
Fair; I blame target fixation
Nope
Ok, thanks. So if I’m getting this right every container should return the VPN IP with curl ifconfig.me
That’s correct and a good way to test it out.
Yes
Yeah, when you have the VPN running all of your external traffic should go through it. It starts to get complicated when you only want a specific container/user to use/bypass the VPN.
Perfect, thanks!
I ran a Linux VM and just had Mullvad app installed and always on, and that was all I needed
And that works too. Containers are just a way to do it more efficiently. Better for weaker hardware and energy usage.
Yeah I know, I use Gluetun now, I was just answering OPs question.