Re: [Openvpn-devel] wanted: mechanism to send text messages to client
Hi Thanks for the comments. On Fri, Dec 25, 2020 at 3:03 PM Gert Doering wrote: > Hi, > > On Sun, Dec 20, 2020 at 07:31:42PM -0500, Selva Nair wrote: > > Here is the link again. > > https://github.com/selvanair/openvpn-gui/releases/tag/v11-echo-msg > > I got no feedback then nor now. > > I have stared at the code a bit, and it seems to make sense. The part > "store a digest + timestamp, and avoid repeating the same message for > hours" is a good idea. > > I can see that "echo_msg_clear()" has a bool parameter to clear the > message history but I can not see a call with "true" - what did you > have in mind? A button to clear the messages history? Or "if changing > to a different profile"? > It has been a while... The history needs to be cleared to free up memory when the thread is terminated on disconnect. Looks like a bug if it's not done during cleanup. That said, I see that I have newer versions of this echo-msg branch (upto v4) in my local repo and the latest includes persisting the history in registry and clearing before disconnect. > I have not tested the binary. > Don't. While we are in this blessed "One True Echo" state, let me rebase the latest version, do some quick tests and post it as a PR for review & comments. Have to do that before I again get stuck in procrastination and the desire to add more glitter like urls in message text etc.. Selva ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] wanted: mechanism to send text messages to client
Hi, On Sun, Dec 20, 2020 at 07:31:42PM -0500, Selva Nair wrote: > Here is the link again. > https://github.com/selvanair/openvpn-gui/releases/tag/v11-echo-msg > I got no feedback then nor now. I have stared at the code a bit, and it seems to make sense. The part "store a digest + timestamp, and avoid repeating the same message for hours" is a good idea. I can see that "echo_msg_clear()" has a bool parameter to clear the message history but I can not see a call with "true" - what did you have in mind? A button to clear the messages history? Or "if changing to a different profile"? I have not tested the binary. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] wanted: mechanism to send text messages to client
Hi,
On Sun, Dec 20, 2020 at 07:06:57PM +, Greg Cox wrote:
> So IMO, 1-2 are fundamental, 3-5 are
> wishlist/consideration/extensions/ideas, use or ignore as you see fit:
> * Make the ability for receiving messages on a client as described.
> Enabled by default, maybe selectively disable-able because someone will
> think it's spammy, but I'd almost suggest not allowing it.
> * Make the ability to send a user a message via management. Enabled by
> default, maybe selectively disable-able as a safety mechanism / make
> someone "key the mic to speak."
These two can be done with the proposed "echo msg..." mechanism (and
suppressed with "pull-filter ignore echo" already today, and possibly
with buttons to-be-added in the GUIs).
> * Make the ability to 'wall' a message out to all connected users in one
> command, e.g. 'wall "server going down in 5 mins"' or something like that.
This is an interesting challenge. Parts of openvpn client might assume
that a PUSH_REPLY is only seen at initial or renegotion time, so sending
a message with the proposed mechanism ("PUSH_REPLY echo msg server shutdown")
might trigger surprising effects.
It might just work.
But it can not be triggered from the server via client-connect scripts/
files/plugins as those are gone. Maybe it can be triggered from the
servers-side management interface. Not sure.
> * Make the ability to 'post' a message for some amount of time, e.g.
> 'wallpost 60m "server going down at 1700"' Sending a message gets someone
> who is connected now, but misses the user who connects 2m after I go
> through the list of users and I stop looking. So, this would hang around
> and pop a message to everyone connected now, plus each new connection, for
> the next 60m.
This is something outside "openvpn core", more tied to your client-connect
scripts/plugins on the server. Put messages with an expire date "somewhere"
(database, filesystem, ...) and on connect, find everything that is still
valid and generate 'push "echo msg..."' messages accordingly.
> * Add an option ala --[no-]use-expired-certs. When true, proceed like you
> do today; when false, if certs are expired, have the client feed itself a
> message via this mechanism to popup that your certs are expired, so a user
> knows right away what's wrong. It'd be a spammy option if it tried to tell
> you what to do, so I'm keeping the idea simple and generic.
Interesting idea :-) - not sure what to do about this one. Since all
"major" GUIs already look at the log file, and present warnings in some
form to the user, maybe this is more a GUI task - if we warn about
"cert might be expired" AND then there is a AUTH_FAILED response,
change that warning (or even "all warnings logged") into a popup window?
Related but slightly different problem.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
signature.asc
Description: PGP signature
___
Openvpn-devel mailing list
Openvpn-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] wanted: mechanism to send text messages to client
Hi, On Fri, Dec 25, 2020 at 12:08:16PM -0500, Selva Nair wrote: > I find it hard to imagine why everyone seems to be avoiding "echo" and > trying to find alternatives. Well, in the beginning of this thread, having all forgotten about the previous thread (still puzzling me) I only had the nagging memory that "nobody understands 'echo' but it does not do what I want". Since then I have been converted to the One True Echo and agree with you that *for this purpose* it's the approach that needs the least changes to existing infrastructure, and will get the job done. gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] wanted: mechanism to send text messages to client
Hi, On Mon, Dec 21, 2020 at 12:22:20PM -0500, Selva Nair wrote: > > I'm sure the thread is still sitting in my mailbox... will go looking for > > it today. > > For those who have lost the original threads: > > https://sourceforge.net/p/openvpn/mailman/openvpn-users/thread/CAEsd45T%2Bd6FUJ9Po0KHwtHjfuL9Q2D-poG8yFtY45Qyh%2BtHjkg%40mail.gmail.com/#msg36136236 > > https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/CAKuzo_jPThhvXTJAtzhqVUVOLPW1VGu6h2jQhVsHicY8P2WRqA%40mail.gmail.com/#msg36141193 > > That was in Nov-Dec 2017. Actually, I was also thinking of reviving this > only the other day when intimating users about some updates came up.. Thanks for digging these up for me. Very interesting read, this :-) I have tried to shape this into a "v 0.1" patch which should hit the list "right now", also in reply-to to your e-mail. Comments and corrections welcome, I'll whack this as long as needed. It's in patch form, but basically a draft, inviting comments. > Somehow such itches re-surface at the end of the year :) Let's see if we can progress this a bit more :-) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de signature.asc Description: PGP signature ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH] Document common uses of 'echo' directive, re-enable logging for 'echo'.
The 'echo' command can be used to signal information to an OpenVPN GUI driving the openvpn core via management interface. Which commands exists and their syntax has so far been mostly undocumented. Condense the long and good discussion between Selva Nair and Jonathan K. Bullard into doc/gui-notes.txt (initial draft from Jonathan, comments from Selva and Arne), with a pointer added to doc/management-notes.txt. See: https://sourceforge.net/p/openvpn/mailman/openvpn-users/thread/CAEsd45T%2Bd6FUJ9Po0KHwtHjfuL9Q2D-poG8yFtY45Qyh%2BtHjkg%40mail.gmail.com/#msg36136236 and https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/CAKuzo_jPThhvXTJAtzhqVUVOLPW1VGu6h2jQhVsHicY8P2WRqA%40mail.gmail.com/#msg36141193 for the details. Re-enable logging of 'echo' statements, but only for the particular class of messages starting with 'echo msg...'. Signed-off-by: Gert Doering --- doc/Makefile.am | 2 +- doc/gui-notes.txt| 363 +++ doc/management-notes.txt | 10 ++ src/openvpn/options.c| 15 +- 4 files changed, 382 insertions(+), 8 deletions(-) create mode 100644 doc/gui-notes.txt diff --git a/doc/Makefile.am b/doc/Makefile.am index df2f54a3..e411f5f9 100644 --- a/doc/Makefile.am +++ b/doc/Makefile.am @@ -15,7 +15,7 @@ MAINTAINERCLEANFILES = \ SUBDIRS = doxygen dist_doc_DATA = \ - management-notes.txt + management-notes.txt gui-notes.txt dist_noinst_DATA = \ README.plugins interactive-service-notes.rst \ diff --git a/doc/gui-notes.txt b/doc/gui-notes.txt new file mode 100644 index ..9715e8f6 --- /dev/null +++ b/doc/gui-notes.txt @@ -0,0 +1,363 @@ +Management Interface "echo" protocol + + +THIS IS A PRELIMINARY VERSION OF THIS DOCUMENT. ALL INFORMATION IN IT +IS SUBJECT TO CHANGE. + + + +CONTENTS +THE OPENVPN --ECHO OPTION +ENVIRONMENT COMMAND +MESSSAGE COMMANDS +PASSWORD COMMANDS +QUOTING +COMMMAND DETAILS + + += +THE OPENVPN --ECHO OPTION += + +The OpenVPN --echo option causes commands to be sent out through the +management interface, typically to a Graphic User Interface (GUI) such +as "OpenVPN for Android", "Tunnelblick" (for macOS), or "Windows +OpenVPN GUI". It can be included in a configuration file or on a +command line, or can be pushed from the server. + +This document describes the commands that can be sent and how they are +interpreted by various GUIs. + + * OpenVPN does not process the commands in an --echo option; it only +sends them out through the management interface. + + * "echo" commands are processed by the GUI if, as, when, and in the +order they are received. If no GUI is present the processing of +commands may be delayed, the commands may never be processed, or only +some commands may be processed. (That can happen if OpenVPN discards +commands because its buffer for the commands fills up.) + + * There is no mechanism for the GUI to acknowledge the receipt, +success, or failure of a command. + + * "echo" commands are stored by OpenVPN (within limits, see the next +point) and sent only when the GUI requests them through the management +interface. "echo" commands in the configuration file or the command +line are typically requested and processed at the start of a +connection attempt. "echo" commands that are pushed by the server are +also typically asked for at the start of a connection attempt but can +be sent at any time. They are processed in the middle of a connection +attempt or after a connection is established, as the "push" options +are received by the client from the server. + + * OpenVPN's storage for echo commands is limited in size, so a large +number of commands or commands with long messages may require that +some commands be removed from the storage. If that happens, some of +the commands may not be sent through the management interface when a +GUI does connect to it or asks for the "echo" commands. + + * On SIGUSR1 and SIGHUP connection restarts, "echo" commands that +were sent through the management interface and have been saved by +OpenVPN are sent again and will be re-processed by the GUI. (The +message commands include a mechanism for muting (skipping) duplicate +messages, see MESSAGE COMMANDS, below.) + + * OpenVPN limits the number of separate arguments in each line of a +configuration file. Arguments may be quoted to work around this +limitation, see QUOTING, below. + + * OpenVPN limits the size of each "echo" command sent over the +management interface to 255 bytes, including overhead characters. To +allow messages of arbitrary length, several message commands can be +concatenated together before being displayed to the user, see MESSAGE +COMMANDS, below. + + * There no indication to the GUI of the source of the
Re: [Openvpn-devel] wanted: mechanism to send text messages to client
Hi, Merry Christmas! On Wed, Dec 23, 2020 at 6:15 AM Jan Just Keijser wrote: > On 21/12/20 18:22, Selva Nair wrote: > > > > On Mon, Dec 21, 2020 at 2:04 AM Gert Doering wrote: > >> Hi, >> >> On Sun, Dec 20, 2020 at 07:31:42PM -0500, Selva Nair wrote: >> > I thought we already went through this when we discussed the proposed >> "echo >> > msg" in considerable detail 3 years ago. >> >> Yeah, sorry. Seems I got distracted and forgot all about the discussed >> "solution space", and just remembered the itch. >> >> I'm sure the thread is still sitting in my mailbox... will go looking for >> it today. >> > > For those who have lost the original threads: > > > https://sourceforge.net/p/openvpn/mailman/openvpn-users/thread/CAEsd45T%2Bd6FUJ9Po0KHwtHjfuL9Q2D-poG8yFtY45Qyh%2BtHjkg%40mail.gmail.com/#msg36136236 > > > https://sourceforge.net/p/openvpn/mailman/openvpn-devel/thread/CAKuzo_jPThhvXTJAtzhqVUVOLPW1VGu6h2jQhVsHicY8P2WRqA%40mail.gmail.com/#msg36141193 > > That was in Nov-Dec 2017. Actually, I was also thinking of reviving this > only the other day when intimating users about some updates came up.. > Somehow such itches re-surface at the end of the year :) > > sorry to chip on so late, but at some point we did have a way to push env > vars to the client (back in v2.2 at least): > > inside a client-connect script you can/could do > > echo "push \"setenv-safe MSG1 'hello'\"" > $1 > echo "push \"setenv-safe MSG2 'download version 2.5 please'\"" >> $1 > setenv-safe is not passed on to the UI/GUI, so not very useful for sending messages to the user. In fact we already use echo to send env variables to the UI -- OpenVPN-GUI interprets push "echo setenv foo bar" and passes it in the env to scripts run by the GUI. See https://github.com/OpenVPN/openvpn-gui/pull/200 In one of our setups we use it to pass file server names, SMB shares to map etc. Among options that already exist, "echo" is the best candidate for this purpose, and it's designed for sending "commands" (which could be messages) from server to client side UI. It's use only requires an agreement on the syntax so that all UI authors can code to interpret them consistently. I find it hard to imagine why everyone seems to be avoiding "echo" and trying to find alternatives. Selva ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
Re: [Openvpn-devel] [PATCH] Clarify --block-ipv6 intent and direction.
On 25/12/2020 16:42, Gert Doering wrote: --block-ipv6 is a fairly special-purpose option, and only blocks packet in the client->server option. This is implied by not ever mentioning the other direction in the existing documentation, but not written down. Make this explicit, avoid confusion. Also, point why this option exist (avoid IPv6 leakage from dual-stacked clients around IPv4-only VPN offerings). Trac: #1351 Signed-off-by: Gert Doering --- doc/man-sections/vpn-network-options.rst | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/doc/man-sections/vpn-network-options.rst b/doc/man-sections/vpn-network-options.rst index 26682789..711dfcc8 100644 --- a/doc/man-sections/vpn-network-options.rst +++ b/doc/man-sections/vpn-network-options.rst @@ -21,7 +21,8 @@ routing. For this option to make sense you actually have to route traffic to the tun interface. The following example config block would send all IPv6 traffic to OpenVPN and answer all requests with no route to host, - effectively blocking IPv6. + effectively blocking IPv6 (to avoid IPv6 connections from dual-stacked + clients to leak around IPv4-only VPN services). **Client config** :: @@ -38,6 +39,12 @@ routing. --push "redirect-gateway ipv6" --block-ipv6 + Note: this option does not influence traffic sent from the server + towards the client (neither on the server nor on the client side). + This is not seen as necessary, as such traffic can be most easily + avoided by not configuring IPv6 on the server tun, or setting up a + server-side firewall rule. + --dev device TUN/TAP virtual network device which can be :code:`tunX`, :code:`tapX`, :code:`null` or an arbitrary name string (:code:`X` can be omitted for LGTM Acked-by: Richard Bonhomme ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
[Openvpn-devel] [PATCH] Clarify --block-ipv6 intent and direction.
--block-ipv6 is a fairly special-purpose option, and only blocks packet in the client->server option. This is implied by not ever mentioning the other direction in the existing documentation, but not written down. Make this explicit, avoid confusion. Also, point why this option exist (avoid IPv6 leakage from dual-stacked clients around IPv4-only VPN offerings). Trac: #1351 Signed-off-by: Gert Doering --- doc/man-sections/vpn-network-options.rst | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/doc/man-sections/vpn-network-options.rst b/doc/man-sections/vpn-network-options.rst index 26682789..711dfcc8 100644 --- a/doc/man-sections/vpn-network-options.rst +++ b/doc/man-sections/vpn-network-options.rst @@ -21,7 +21,8 @@ routing. For this option to make sense you actually have to route traffic to the tun interface. The following example config block would send all IPv6 traffic to OpenVPN and answer all requests with no route to host, - effectively blocking IPv6. + effectively blocking IPv6 (to avoid IPv6 connections from dual-stacked + clients to leak around IPv4-only VPN services). **Client config** :: @@ -38,6 +39,12 @@ routing. --push "redirect-gateway ipv6" --block-ipv6 + Note: this option does not influence traffic sent from the server + towards the client (neither on the server nor on the client side). + This is not seen as necessary, as such traffic can be most easily + avoided by not configuring IPv6 on the server tun, or setting up a + server-side firewall rule. + --dev device TUN/TAP virtual network device which can be :code:`tunX`, :code:`tapX`, :code:`null` or an arbitrary name string (:code:`X` can be omitted for -- 2.26.2 ___ Openvpn-devel mailing list Openvpn-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openvpn-devel
