On Mo, 22.02.21 16:29, Petr Menšík (pemensik(a)redhat.com) wrote: It might be OK for systemd's resolvectl to pass the call on to some other executable if it notices resolved is not there. We do the same in the "telinit" tool, so that Debian can have multiple init systems, and when ours owns the "telinit" name, but the system is not actually booted with systemd we can propagate the call to some other tool. Happy to review a patch for that (submit upstream) Lennart -- Lennart Poettering, Berlin

On Mon, Feb 22, 2021 at 5:15 pm, Petr Menšík <pemensik(a)redhat.com&gt; wrote: Is there some reason systemd-resolved cannot be a subpackage? Seems like that would be the easiest solution? If that's problematic for some reason, then surely /usr/sbin/resolvconf can move to a subpackage.

On Mo, 22.02.21 17:15, Petr Menšík (pemensik(a)redhat.com) wrote: Quite frankly, I am not sure it would be a good idea to do things that way. note that resolved should be fine as a resolvconf replacement, even if you don't want to use it as a resolver: just set the /etc/resolv.conf symlink to /run/systemd/resolve/resolv.conf (instead of the usual /run/systemd/resolve/stub-resolv.conf) and you get the upstream servers listed there, as any other resolvconf implementation would do it. The thing is, there's a bunch of software these days that can talk to to resolved's D-Bus interface to set DNS servers and such. You lose all that if you insist that systemd-resolved is so terrible that you cannot even use it as a resolvconf reimplementation, that is more than a bunch of shell scripts. Another option might be https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/ btw. Lennart -- Lennart Poettering, Berlin

On Mon, 22 Feb 2021, Petr Menšík wrote: In the past I also mentioned this. The overwhelming majority of installs do not gain any benefit from te systemd-resolved service. Most servers, containers and even workstations are installed and given DNS configurations via DHCP, manager by a network administrator. systemd-resolved addresses a problem with finding printers and resolving a .box domain for router reconfiguration. And it provides partial solutions for split-DNS views when VPN's are deployed on laptops. There is no technical reason why this is not in its own package. There has been some focussing on reducing minimal installs, and this is a prime candidate for that. I'm fine with the workstation or desktop installs bringing this package in by default. But I see only potential harm from installing it on servers, containers and most virtual machines. Paul

On 2/25/21 9:06 AM, Peter Boy wrote: systemd-resolved has some cool features, but I haven't found a way to configure domain forwarding to selected IP address without a device. Which would match your use-case. Every classic dns cache, dnsmasq used by libvirt included, can forward subdomain queries to selected IPs. I think systemd-resolved is able to configure it only per connection. But it should be possible to use virbr0 device for it inside resolved. resolvectl dns virbr0 192.168.122.1 resolvectl dns virbr0 example.lan I don't know any permanent way to store this information to NM or systemd-resolved, so it would configure it itself next boot. Maybe systemd guys would know a way. -- Petr Menšík Software Engineer Red Hat, http://www.redhat.com/ email: pemensik(a)redhat.com PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

On 22/02/2021 16:29, Petr Menšík wrote: Just providing some input from the OpenVPN perspective. * OpenVPN 3 Linux OpenVPN 3 Linux [0] since the v10 release provides native systemd-resolved support. It is not optimal yet, but we plan to provide full support for split-DNS (only pushed domains will be resolved via the DNS server requested by the VPN server) and exclusive DNS (use only the DNS server pushed by VPN server). The current implementation will query all DNS servers on all interfaces. This hybrid mode will also be supported. At the moment I'm not yet decided what should be the default mode, but I'm leaning towards split-DNS - as that provides the least risk for DNS leakage either way. But for some any DNS lookups to the main link is considered a DNS leak as well, so this is highly usage dependent. We are also considering how far the server can go to push for a certain profile - as the use cases for VPN provider side are also very diverse with different requirements. For the v10+ releases you need to do a little configuration step [1] to enable this support, but we are planning to enable this by default on Fedora 33+. Ubuntu 20.04 will probably also be updated to use it by default. This will most likely happen from the v14 release. * OpenVPN 2.x We are also considering to fully embrace the update-systemd-resolved [2] script for the OpenVPN 2.x versions. And will work together with this project to ensure OpenVPN 3 Linux and OpenVPN 2.x will behave a similar as possible. * NetworkManger and OpenVPN Outside of that, OpenVPN via NetworkManager will be a different beast to tackle which we have not yet dug into from the OpenVPN project side. From the OpenVPN side, we are not too happy about the current NetworkManager plug-in from a general point of view. It is good with the graphical interface, but NetworkManager does not fully consider what OpenVPN is capable and restricts its capabilities too much in several areas (like killing the OpenVPN process if the main link disappears; OpenVPN is capable of recovering quite nicely when network recovers). And we have more OpenVPN specific features planned as well, where the NetworkManager can cause more damage - as it does not (and should not) understand how OpenVPN operates. * DNS updates If NetworkManager is capable of fully integrating with a unified DNS resolver management which OpenVPN and other updateresolve alternatives could work with would definitely be the best for all of this. OpenVPN 3 Linux and OpenVPN 2.x can be extended and taught to integrate with various DNS management approaches. systemd-resolved is already on the way, but does not need to be restricted here. But we are very much interested in being involved in such discussions. [0] <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux> [1] <https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg20607... [2] <https://github.com/jonathanio/update-systemd-resolved> -- kind regards, David Sommerseth OpenVPN Inc

Hi! On 25/02/2021 14:39, Petr Menšík wrote: [..snip...] systemd-resolved is already enabled in Ubuntu 18.04 (but not fully) and now in Fedora 33 (which goes a long way of integration into the system). It also provides a D-Bus interface which is reasonable to integrate with. This solved use cases we have for customers connecting Ubuntu machines to OpenVPN Cloud, where DNS is a big part of the Cloud solution. dnsmasq and unbound are great packages as well, but they are not really designed for system integration in the same level as systemd-resolved when considering today's ever changing network topology. Just take an average laptop user today - how many various networks might that user connect during a day, especially when travelling? Since we have the impression systemd-resolved is becoming more and more used by default, we figured that would be a reasonable service to integrate with. It also seems to handle the various use cases of roadwarriors pretty well as well as virtualised servers. Plus it provides a reasonable D-Bus API to work with (more on that below). OpenVPN 3 Linux aims to run with as least privileges as possible. And tt tries to integrate with the basic existing network components on the system. But running with least privileges is a challenge with lots of the network stack, as it requires some elevated privileges. So OpenVPN 3 Linux is split up into several components doing a dedicated task. == Some OpenVPN 3 Linux architecture details == The most privileged service running is the openvpn3-service-netcfg (net.openvpn.v3.netcfg). This is responsible for creating and configure TUN interfaces (with or without kernel acceleration), setting up routes and DNS. But it runs as the openvpn:openvpn user with CAP_NETADMIN. If using the resolv.conf approach (currently the default, which edits /etc/resolv.conf directly - which IS nasty), it also adds CAP_DAC_OVERRIDE. But we generally try to avoid exec() any external code and depend on available APIs on the host, whether it is Kernel Netlink, libc related interfaces or D-Bus. In fact, the script-hooks found in OpenVPN 2.x is non-existing in OpenVPN 3 Linux. You can however achieve similar features (but with some more work currently) by subscribing to various D-Bus signals OpenVPN 3 services sends. The openvpn3-addon-aws is such a service, which propagates pushed VPN routes to a AWS VPC setup and removes them again when the VPN connection is taken down. In regards to network configuration and DNS resolvers. The openvpn3-service-netcfg module is written in a way so it should be possible to extend it with more "resolver setting backends". A new backend needs to implement this interface: <https://github.com/OpenVPN/openvpn3-linux/blob/master/src/netcfg/dns/reso... Each running VPN session provides the DNS resolver settings via ResolverSettings objects, which are gathered via the Apply() method. And once all settings are provided, the Commit() method is called which makes sure the settings are happening on the host. The ResolverSettings class is defined here: <https://github.com/OpenVPN/openvpn3-linux/blob/master/src/netcfg/dns/reso... Agreed! Yes, the missing resolvconf is part of the challenge. In addition to the split-DNS challenges which are beginning to surface. Users start discovering these advantages and wants them. That's good. But it will require an exec() which we really try to avoid. No, resolvconf (and some variants of it) was not really considered, due to requiring exec() and not being a system wide "owning" the resolver configuration. And that's essentially the crux of it. Linux is lacking a centralized interface for handling DNS and resolver settings. NetworkManager does not really do it, but it can pass info along. And systemd-resolved is moving towards that direction. I do like that there are alternatives to systemd-resolved. But I am not really convinced that wrapping _scripts_ around them is the most ideal way of integration. Sure, for many use cases this might be good enough. But when you start wanting to do this via lesser privileged processes, running scripts or programs quickly becomes a big hurdle from a security perspective. A well defined API with proper access control and authorization solves that to a large degree. And D-Bus solves a lot of privilege separation issues on Linux today. Whether OpenVPN integrates directly with systemd-resolved or something else is less important for us as long as it gives the users the DNS management they prefer (essentially, explicitly defined DNS servers, split-DNS or hybrid mode) and that all components can run with as least privileges as possible. Another issue, which will become relevant here later on, is that we begin to have users wanting to start VPN sessions *inside* containers. Some users wants that for the wrong reason ("because nginx and httpd can be in a container, VPNs should too"), but some do have valid use cases for it (think Amazon Fargate, like containerized micro services connected together via a VPN). DNS resolving will in these cases become an interesting scenario, as the VPN provided DNS resolving should be for the contained VPN sessions only. But at the same time, the VPN implementation inside the container needs to be allowed to create the needed TUN interfaces and configure the networking for it. This is an area we have just begun investigating. This will also need to be handled in a clever way in regards to the overall DNS/resolver configurations - both inside and outside containers. That's essentially the crux of the issue with NetworkManager. VPNs and devices are kind of same-same-but-very-different. I have spoken with NetworkManager developers about these challenges a while back, and we kinda agreed that NetworkManager was not the perfect fit given the current design and architecture. There are pointers to our Fedora Copr repository in [0] ;-) <https://copr.fedorainfracloud.org/coprs/dsommers/openvpn3/> Once we're getting ready with a stable release, I want to submit the Copr packaging to mainline Fedora. But do read the quick-start part in [0], as OpenVPN 3 Linux is designed very differently from OpenVPN 2.x ... and it tries to have a user interface which is more end-user friendly than OpenVPN 2.x. -- kind regards, David Sommerseth OpenVPN Inc

Petr Menšík wrote: IMHO, the proper fix would be to have a proper facl on resolv.conf for the openvpn user. Kevin Kofler

Petr Menšík wrote: Well, what I propose is really to have a systemwide file ACL set by the RPM owning resolv.conf, listing all system users that need write access to the file, and openvpn would be one of them. If something then overwrites the file losing the ACLs, that something needs to be fixed then. Kevin Kofler

On 25/02/2021 16:02, Dan Williams wrote: [...snip...] We do have on our todo-list to provide a nm-openvpn3 plugin; I hope we will be able to allocate resources to work on that in the next 4-6 months. We cannot re-use the existing nm-openvpn implementation as it is a completely different client. OpenVPN 3 Linux is fully managed via D-Bus. Hopefully the new architecture will make it easier to add NM integration, as OpenVPN 3 Linux already takes care of the privilege separations and OpenVPN configuration management. There are APIs to import and retrieve available configurations, start/stop/pause/resume VPN sessions and as well as retrieving VPN session statistics and log/status updates. So an nm-openvpn3 plug-in just needs to behave like a user interface towards the user. That said, if there are other aspects where NM would like to integrate more tightly with OpenVPN 3 on the networking integration, we are equally open to look into improvements here. We have briefly started to investigate NM online status tracking - to hold back starting of VPN connections until the host is fully online, and equally pause sessions when the connection disappears. Mostly to put the network silent when a connection is impossible but being able to recover quickly when the network is back. This is great news and a considerable improvement. Last time I was in contact with the NM developers, this was being discussed but got the impression it had not materialized yet. But this is something which would be great to explore further. Another challenge, which is more a bureaucratic/management one, is the collaboration platform between the nm-openvpn project/development and the upstream OpenVPN project. Currently OpenVPN Inc people working in the community focuses on OpenVPN 3 and, server side aspects of OpenVPN 2 and the OpenVPN kernel module under development. While the community itself mostly focuses on the whole breath OpenVPN 2. But it is hard to motivate people to work on the NM integrations from our side. And to be honest, it's not too easy to get people involved in the Windows GUI either - but we do have at least some progress there with a very dedicated upstream maintainer. Somehow it seems the GUI aspects are not that intriguing to work on. That said, if there are people wanting to dive into the NM-OpenVPN integration, OpenVPN will be supportive to such efforts and will help as much as possible. Just keep me in the loop and I will ensure that the right people gets in touch. -- kind regards, David Sommerseth OpenVPN Inc