On 01/09/16 20:04, David Sommerseth wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 31/08/16 20:55, David Sommerseth wrote:
>> Hi,
>>
>> I have for a long time pondered on how we can make the management
>> API more suitable for more modern tools and tasks. So I am just
>> giving an extremely early heads-up on on what I'm poking at ... and
>> hopefully receive some feedbacks on what you think.
> [...snip...] (I'll try to respond to all feedback in this single mail)
>
> Thank you to all of you who raised your voice, this is very helpful!
>
> First of all, I understand the scepticism. And I also do not want to
> bloat OpenVPN needlessly.
>
> JJK have also made a very good point, that there is a contradiction
> between the need on the server and client. In regards to splitting
> client and server code, the OpenVPN 3 code base is actually far better
> separated in this regards - so we are moving towards that direction.
>
> I also understand the argument "If it ain't broken, don't fix it".
> The problem is what and who defines what is broken or not. I see a
> great potential to make OpenVPN integrate better, both towards the OS
> level but also towards the user interfaces. From my point of view,
> OpenVPN is still stuck in how things were done in 90s, and to enable
> possibilities which is found in modern OS we need to adopt OpenVPN
> likewise. I still wouldn't call it broken, but seeing it more mature
> for a real update.
>
> Samuli's comment regarding easing the client management on the server
> side, is quite spot-on. But it won't be that much extra work at all
> to add client side support in addition. Hence, I am daring to also
> consider client-side needs.
>
> I understand that the client-side is quite happy with the situation as
> it is now. So I will therefore then focus these next steps on the
> server side primarily. If the client-side see some advantages later
> on, it shouldn't be too hard adding those features later on. And
> having both the old TCP based management interface and a newer D-Bus
> interface will therefore be the primary goal - with D-Bus enabling
> will happen both at compile time (to allow building without extra
> dependencies) and runtime (to not enforce D-Bus to be used). And I
> will not spend time adding new features to the TCP based management
> interface for the time being.
>
> So just to provide a few more examples why I'm so persistent on
> providing D-Bus support ... I'll bring up both a few already mentioned
> use cases, for completeness, as well as some new ones.
>
> * Better and easier integration with modern management tools (like
> Cockpit)
>
> * Enables a simpler way to manage OpenVPN also from shell scripts,
> by using standard D-Bus clients such as gdbus or qdbus.
>
> * Allow multiple management tools to interact with OpenVPN at the same
> time, even allowing differentiated access controls per management
> client (more on that in a bit)
>
> * Enable management of OpenVPN plug-ins without needing to extend
> OpenVPN core code additionally per plug-in and allow plug-ins
> full control of the API it will provide (not restricted to the
> OpenVPN capabilities the core OpenVPN code is designed for - each
> plug-in can provide its own D-Bus interface independently of others)
>
> * Allow for PUSH notifications (in D-Bus jargon: signals) instead of
> management tools need to constantly pull for information
>
> * Enable possibility to add (set) triggers (which uses D-Bus signals)
>
> * Provide possibility to do user/password authentication via D-Bus
> as an alternative to plug-ins or script hooks. Can also extend this
> to provide the TLS verification methods too. This allows for more
> powerful authentication modules where using script hooks easily
> gets complex and writing a C plug-in is a too big challenge.
>
> * New tools can more easily manipulate firewalls on the fly using
> more fine grained information for connected sessions at once. Also
> considering that FirewallD is also D-Bus based can ease this
> integration too.
>
> * Enable policy management of methods ("function calls") provided over
> D-Bus. This can allow non-admin users to have limited power while
> admin users can be allowed to do more. These policies can also
> be completely controlled by using user groups defined by the system.
> All user authentication is done by the OS via D-Bus (using polkit).
> This means, a non-root user can actually control much of an OpenVPN
> process if the policy allows it - including restarting OpenVPN.
> The OpenVPN process itself can run as a different user or even root.
>
> * Enable possibility to have better understanding of the current network
> situation, as OpenVPN can through D-Bus query NetworkManager (or
> similar D-Bus interfaces for networks) for the general network
> situation. This is probably more useful on the client side than
> server side, though. (No need to try to reconnect every 5th second
> if the network state is "offline")
>
> * Prepare the ground for seamless restart of the OpenVPN process without
> needing to do complete reconnect with all TLS key exchanges for all
> connected clients. This can be done such that the new OpenVPN
> process connects to the D-Bus, signals the already running process to
> pass over all client states. These client states can also include
> byte/packet counters as well, if that is used for accounting.
>
> By adding an extra "link program", it can, in theory at least, also
> be made possible to sync client states across hosts.
>
> This can probably be done today too, but would we enable such things
> over an unencrypted TCP link? As it is unencrypted, I'd say that the
> management password you can set is quite moot and useless. So to get
> the security right, the management today needs to be even further
> extended - as D-Bus provides the authentication and access control
> in the basic API.
>
> These are just some of the possibilities I see D-Bus can more easily
> enable. As I said, OpenVPN ain't broke as it is, but it can be
> improved to be better integrated with more advanced use cases which is
> harder to achieve today.
>
> As an example in the end, I'll consider up a question I've heard every
> now and then on the #openvpn IRC channel. "How can I add quotas to
> VPN clients?" Today, I would say, that can only be achieved by either
> writing a plug-in and/or some tools using the management interface to
> retrieve information and do the quota controls.
>
> With D-Bus this can be done with a few simple scripts ... here as a
> very simple pseudo code. These scripts can be written in your
> favourite language as long as it has D-Bus libraries available.
>
>
> * ConnectionSetup ... a script which prepares the triggers
> =====================================================================
> system_bus = dbus.connect(DBUS_SYSTEM)
> while (1) {
> # wait for a client to connect
> res = system_bus.wait_for_signal(dest="net.openvpn.managment",
> path="/net/openvpn/management/Triggers",
> signal="sys_vpn_connect");
>
> # Fetch client info and log
> client = system_bus.call(dest="net.openvpn.management",
> path="/net/openvpn/management/ClientInfo/" + res,
> method="QueryClients");
>
> # Retrieve quota and do some logging
> quota = corp_function_get_quota(client.cn);
> printf("Client %s connected, used %i bytes of quota, " \
> "setting quota to %i bytes\n",
> client.cn, quota.used, quota.max);
>
> # Set the quota for this session, account for already used quota
> system_bus.call(dest="net.openvpn.management",
> path="/net/openvpn/management/Triggers/" + res,
> method="SetQuota"
> quota=(quota.max - quota.used));
> }
> =====================================================================
>
>
> * ConnectionDisconnected ... a script which logs used quota
> =====================================================================
> system_bus = dbus.connect(DBUS_SYSTEM)
> while (1) {
> # wait for a client to connect
> res = system_bus.wait_for_signal(dest="net.openvpn.managment",
> path="/net/openvpn/management/Triggers",
> signal="sys_vpn_disconnect");
>
> # Fetch session info
> session = system_bus.call(dest="net.openvpn.management",
> path="/net/openvpn/management/Sessions/" + res,
> method="QuerySession");
>
> # Log some statistics
> printf("Client %s disconnects, used %i bytes in this session\n",
> session.cn,
> (session.bytes_received + session.bytes_sent));
>
> # Update corp database with used quota
> corp_function_add_used_quota(session.cn,
> (session.bytes_received + session.bytes_sent));
> }
> =====================================================================
>
>
> * QuotaControl .... a script which kicks out clients exceeding quota
> =====================================================================
> system_bus = dbus.connect(DBUS_SYSTEM)
> while (1) {
> # wait for a client who exceeds the quota
> res = system_bus.wait_for_signal(dest="net.openvpn.managment",
> path="/net/openvpn/management/Triggers",
> signal="quota_exceed");
>
> # Fetch client info and log
> client = system_bus.call(dest="net.openvpn.management",
> path="/net/openvpn/management/ClientInfo/" + res,
> method="QueryClients");
>
> printf("Client %s exceeded quota, killing session\n",
> client.cn);
>
> # Kill the session
> system_bus.call(dest="net.openvpn.management",
> path="/net/openvpn/management/Sessions/" + res,
> method="KillClientSession");
> }
> =====================================================================
>
> (I admit this over-simplifies the D-Bus calls, but this is in
> essence of how these calls would work)
>
>
> So three individual scripts, which can be added/modified/restarted at
> will outside of OpenVPN without influencing any established OpenVPN
> connections.
>
> Doing a similar thing using the TCP based management interface is
> going to be considerably harder, as you need to manage everything
> through a single TCP connection and it is needed to do regular polls
> to the OpenVPN server as there are no push features. Plus you need to
> manage the TCP connection setup and all communication over the socket.
>
> I'll let you all know when I have something more concrete to show; but
> I am still very much open for more feedback!
>
>
> - --
> kind regards,
>
> David Sommerseth
> OpenVPN Technologies, Inc
>
David, that all sounds fantastic but .. One note of caution:
* If it sounds too good to be true .. then it probably is.
If it is possible; a run time option eg. --dbus enabled|disabled
or at least a compile time option --enable-dbus might be preferable.
For me personally, it sounds like a lot of openvpn 'control' is being
handed over to another entity and I am not convinced that is ideal.
Regards
------------------------------------------------------------------------------
_______________________________________________
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
