On 25/02/2021 16:02, Dan Williams wrote:
On Thu, 2021-02-25 at 11:57 +0100, David Sommerseth wrote:
[...snip...]
* 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.
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.
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...
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
_______________________________________________
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
