On Thu, 2021-02-25 at 11:57 +0100, David Sommerseth wrote: > On 22/02/2021 16:29, Petr Menšík wrote: > > Why? I thought about common interface to various DNS cache > > implementations for workstations and different VPN providers > > available. > > While I think the best place to direct, which interface resolvers > > should > > handle given domains. resolvconf handles conflicting requests from > > different interfaces, when multiple DNS resolver providers are > > configured by connection. > > 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 > 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 > 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 > 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 > 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. I'm pretty sure the NM team would be receptive to improvements especially given new OpenVPN capabilities. But NM has supported a feature that allows VPN connections to persist across link changes (the VPN service returns the "can-persist" key in its IP config response if it knows the underlying service can handle it). I don't see that exposed/utilized by nm-openvpn, but perhaps it should be if the connection properties will allow it (eg, if -- keepalive/ping*/whatever is enabled?). I'm sure they'd accept patches to that effect... Dan > * 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@xxxxxxxxxxxxxxxxxxxxx/msg20607.html > > > [2] <https://github.com/jonathanio/update-systemd-resolved> > > > -- > 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 _______________________________________________ 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
