-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OpenVPN not working inside container #18708
Comments
nix-containers could expose --capabilities of systemd-nspawn, so NET_ADMIN could be added to the list |
@Mic92 Thanks for the pointer. I'm investigating... |
Ok, I stumbled upon this in the manual:
Which sounded somewhat confusing to me at first, but was made clearer after @Mic92's comment about
Though
So, containers with private network have CAP_NET_ADMIN, containers without don't, meaning OpenVPN should work at least in the former. After that I've tried to run OpenVPN inside a container with private networking by setting
Not really sure what's going on here... |
Actually, it seems that, when started manually, OpenVPN also works inside a container without private network:
|
Actually you need 2 things: access to the device node /dev/net/tun and create a tun device and CAP_NET_ADMIN to add ip addresses/routes to this interface. Note that the container has its own devtmpfs mounted on
|
|
Ok. Opening a device node should not require any special capabilities, just the correct permissions.
Is running openvpn as user in the openvpn service? |
@Mic92
@Mic92 Openvpn is run as root AFAICT. Both the generated service and the config file don't include any user directives. Though I'm not sure how to find that out for real. I was thinking about just adding Here is the generated service:
If I just copy the |
I just checked the permission of the tun device from within the service in such a container. It is the same as the as expected (with ls). The service has also all capabilities the container has (with getpcaps $$).
UPDATE Maybe it has something to do with systemd's https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html This list is already restricted at container startup, but maybe it is further restricted for a service? |
I found out why OpenVPN works with @edolstra Why does |
ok, didn't now that it uses nsenter. This is probably a leftover, when machinectl had no |
I finally found the problem. @Mic92 was right with the By default, Editing the containers module to set I'll submit PRs for |
Reopening. Needs backport to 16.09 |
It would also be great to allow /dev/net/tun to be used inside imperative containers/globally. |
Yes, I need that, so that it works with nixops. |
Is this still relevant? Backporting to 16.09 is probably no longer interesting, but is there anything else to do here? |
/dev/tun access was backported in #19523, but I'm unclear whether it works in imperative containers as @cillianderoiste and @nh2 mention above. |
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly:
|
this is still relevant, as /dev/net/tun is inaccessible inside imperative containers. Would be nice if there would be --enable-tun flag for nixos-container create or something like that EDIT: so a solution would be to allow /dev/net/tun globally in all declarative containers in https://github.com/NixOS/nixpkgs/blob/master/nixos/modules/virtualisation/nixos-containers.nix Or maybe to add some flags to globally enable/disable the flags for all imperative containers. |
I marked this as stale due to inactivity. → More info |
Issue description
OpenVPN inside a container fails to start with:
Steps to reproduce
Technical details
It looks like NET_ADMIN capability is missing in order for OpenVPN to manipulate the TUN device.
The text was updated successfully, but these errors were encountered: