Hi!
On 25/02/2021 14:39, Petr Menšík wrote:
[..snip...]
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).
>
This case is exactly what I am trying to prevent. There is multiple
implementations of dns cache, most of them can support split-DNS by some
configuration. If openvpn supports systemd-resolved natively, does that
mean it would not be able to support split-DNS on dnsmasq or unbound?
What is motivation to support specific implementation instead of generic
interface? I don't want to ask openvpn to support also dnsmasq or
unbound natively, because I think there should be middle layer support.
I am trying to use resolvconf as such layer.
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.
I am dnsmasq, unbound and bind (co)maintainer. I want them to stay first
class citizens in Fedora, even when they are not installed by default.
Of course, also knot-resolver and pdns-recursor should be supported, if
they are (willing and) able to.
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/resolver-backend-interface.hpp>
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/resolver-settings.hpp>
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.
>
I think it should be configurable from server side with ability to
override it on client side. The VPN owner should be able to do specify,
whether all queries or only domain-selected queries should go over the
VPN. Is it already possible to choose the variant from server side? The
default should matter only in case VPN administrator does not care.
Agreed!
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.
>
Is there a reason, why systemd-resolved's resolvconf does not work for
you? Does update-systemd-resolved need more functionality than
resolvconf is able to provide? Was the reason missing resolvconf on
Ubuntu/Debian?
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.
For example, resolvconf -p -a <resolv.conf would request only selected
domains over provided interface. resolvconf -x -a <resolv.conf would
send all queries over the interface, according to man 8 resolvconf.
The same seems to be supported also by systemd's resolvconf.
That's good. But it will require an exec() which we really try to avoid.
Was resolvconf usage tried for this purpose? AFAIK systemd does not
provide resolvconf on Ubuntu nor Debian, where only openresolv and
resolvconf packages exist to provide resolvconf binary. In Fedora, only
systemd provided it until now. I think resolvectl might expose
resolvconf interface via parameters, not only by resolvconf symlink to
resolvectl.
It misuses search resolv.conf clause to list provided domains a bit. I
doubt ~domain notation is supported by openresolv already, but I think
it would not be hard to implement it.
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.
* 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.
>
NM can set ipv4.dns-search and ipv4.dns, with ipv6 having this too. My
ethernet nmcli shows values from DHCP as IP4.DNS[*] and IP4.DOMAIN[*]. I
think that is almost all we need. Set of DNS IPs and list of domains
handled by them. Then just a signal of preference, whether to forward
all unspecific queries to this connection by default. NM has also
ipv4.dns-priority number, I guess it is for similar thing.
Problem is as you already noted, NM limits some feature uses. I think NM
can store only values per connection only when it manages such
connection. I doubt it can store dns properties on connections or
devices not managed by it. resolvconf should make possible even pure
openvpn connections having list of dns servers and list of domains. Can
or should we ignore connections not managed by NM? How rare are they?
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.
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.
Of course! Providers of VPN are a primary target to split-DNS support.
There should be unified interface for them, without having to implement
any specific cache details. Implementation-specific mapping to cache
implementation should be provided by dns cache maintainers IMHO. If
resolvconf is problematic in any way, what features are missing? What
requirements are important for OpenVPN?
Is OpenVPN 3 even packaged on Fedora?
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.
[0] <https://community.openvpn.net/openvpn/wiki/OpenVPN3Linux>
--
kind regards,
David Sommerseth
OpenVPN Inc
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
