On 04/01/2019 18:32, Bernhard Schmidt wrote: > Am 04.01.19 um 17:25 schrieb David Sommerseth: > > Hi everyone, > >> Okay, I was a bit unclear. The approach used with openvpn.service and >> openvpn@.service are broken by (Debian) design. Quite many users have >> reported that these service files does not work at all. But I'll admit, I'm >> not really up-to-date if these service files have been updated by >> distro-packagers later on. > > (One of the) Debian OpenVPN maintainer here. I'd like to get some input > about the perceived brokenness of the openvpn@.service in Debian. Freeze > is coming up, but we still have time to fix issues if they arise. I'm > not aware of any major bugs reported for this. > > First of all, we ship both openvpn@.service (which is maintained in > Debian) and openvpn-client@.service and openvpn-server@.service from the > upstream sources. As a user of our package you are very much free (and > encouraged) to work with OpenVPN in the officially documented way.
That's really good! Thank you, Bernhard! > openvpn@.service mostly comes from a compatibility layer. Since years in > Debian you could drop a .conf into /etc/openvpn and had it executed at > startup (controlled by a variable in /etc/default/openvpn). This is > pretty much remodeled by the use of a custom generator, see > https://sources.debian.org/src/openvpn/2.4.6-1/debian/openvpn-generator/ > . openvpn.service just binds these instances together to allow for a > service openvpn restart to work. And I currently don't see a compelling > reason to drop this, since it allows upgrading users to keep working). I have no strong opinions about what the best approach for the official Debian packages is, from pure a Debian perspective (my responses to Samuli has been the .deb packaging we place into our own repositories). I do know that this generator has been quite unreliable and a lot of users got confused in the past and several users did 'systemctl start openvpn.service' ... and no OpenVPN services did start while the configuration files was to be found in /etc/openvpn and users did claim this worked earlier. Switching to the new unit files, and everything worked instantly. Another challenge has been that it has been hard to find the proper location where log entries ends up. Too many users don't realise that openvpn.service is something very different from openvpn@CONFIG.service. > Since the .conf files are not split between client and server we have to > use one openvpn@.service that can accomodate both. But I really fail to > see the problem here. openvpn@.service and openvpn-server@.service are > not that much different. We move slowly forward in regards to hardening both services. And the server operational mode has more privileges than the client mode. Currently probably not the biggest issue, but this is something we will need to work further on. > We do use systemd readyness notification, the > capability bounding set is the same (for server), That's good! That has been one of the major pain points. > the ExecStart line is similar, we do restart on error. Restart on error is reasonable and good in server mode. For client mode, for some that is the proper thing to do; while for others it can be annoying. Hence we have only added restart-on-error for the server mode. We generally recommend users to do 'systemctl edit openvpn-client@CONFIGNAME' to add restart-on-error for those configurations where it is wanted. > openvpn@.service > ExecStart=/usr/sbin/openvpn --daemon ovpn-%i --status > /run/openvpn/%i.status 10 --cd /etc/openvpn --config > /etc/openvpn/%i.conf --writepid /run/openvpn/%i.pid --daemon is definitaly a NOOP if Type=notify, so that can go out. --writepid is really questionable to me. With Type=notify, systemd should not care about any PID files at all. There is an outstanding issue with our LimitNPROC= setting. That might need to be increased on the server side, but I don't think we've really found a reasonable default. For client side, it will typically allow 5-10 simultaneously running tunnels, so it might not be hit too hard. The challenge is that LimitNPROC is set on a user account level, it's not a per-process setting. But I see you don't have --supress-timestamps ... how does the log entries in the log files look like? Don't you get duplicated timestamps per line? > openvpn-server@.service > ExecStart=/usr/sbin/openvpn --status %t/openvpn-server/status-%i.log > --status-version 2 --suppress-timestamps --config %i.conf > > -client.service is a bit more restricted and uses --nobind and no status > file, but that's about it. Yes, currently. And I would like to restrict it even further, but the script hooks are really tricky to tackle correctly as it is now. We've tightened the OpenVPN 3 Linux client quite well, and I'd like to see some of those approaches reimplemented in OpenVPN 2 as well. We are now also in a state with OpenVPN 3 Linux that we can start playing with re-using the openvpn3-service-netcfg D-Bus interface in OpenVPN 2, which will allow the openvpn process to run completely unprivileged. The netcfg service has potential to become a kind of a more generic VPN API for Linux. But for OpenVPN 2.x, the tricky detail is, once again, script hooks - too many scripts expects to have root privileges. That said, the netcfg service will also handle DNS configuration in addition to IP address and routing configuration, so part of the root access requirement on the client side is probably less crucial. -- kind regards, David Sommerseth OpenVPN Inc
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
