Hi,
On Fri, Jun 10, 2016 at 4:47 PM, Chris Laif <chris.l...@googlemail.com>
wrote:
> On Wed, May 25, 2016 at 4:04 AM, Selva Nair <selva.n...@gmail.com> wrote:
> > This looks like a very useful feature that I went ahead and took a stab
> at
> > it. See PR #50 at
> > https://github.com/OpenVPN/openvpn/pull/50
> >
>
> Thank you very much for implementing this feature! That's exactly what
> I had in mind when I sent my request to the list.
>
Thanks for caring to provide feedback on this.
>
> > It has undergone very limited testing, so may still have some wrinkles
> ---
> > options processing in OpenVPN is not something I fully understand. Hence
> the
> > PR and not a patch. Feedback most welcome.
> >
>
> I suggest to split the "option string" in two separate parts:
>
> Usage: --pull-filter accept|reject "option string"
>
> to
>
> Usage: --pull-filter accept|reject "option" "option-filter"
>
>
> where "option" is an exact match (identical string) for the
> corresponding openvpn option and "option-filter" is a partial match.
This would boil down to the current single prefix-matching filter unless we
interpret absence of "option-filter" as an end of string indicator. I Guess
that's what you have in mind. More on that below.
>
> where "option" is an exact match (identical string) for the
> corresponding openvpn option and "option-filter" is a partial match.
>
> As you wrote having things like 'Note the space at the end of "route "
> to not reject "route-gateway"' is error prone. Users might complain
> about hard-to-explain config errors.
Its hard to avoid such errors no matter what we do. Suppose we allow only
exact match and the user puts a space at the end or beginning. Are we
supposed to strip it before matching? Or with two filters (option and
option-filter suggested above) two words with forgotten quotes will convert
an expected exact match to a partial match with no warning. The current
implementation will flag an error when required quotes are missing.
Being an advanced feature I wouldn't worry much about user errors --- lay
user is not supposed to edit any config files, just download them from
somewhere or create them using a fancy GUI :-) I was initially thinking of
supporting full posix regex matching, stopped short of it only because of
the pain of portable support without using an external library. That would
have been much more powerful for some and possibly more error-prone for
some others.
> Or even worse, one filter may
> work for openvpn version X and not for version Y because it matches a
> different scope of openvpn options.
You can force future-proof exact matching for option names using a space at
the end, but I agree there are potential problems when the filter goes
beyond just the option name. For example, a filter "redirect-gateway def1"
may unintentionally match an ill-named future option "redirect-gateway
def100". The way to avoid such issues would be to cripple it by allowing
exact match only or support an end of string marker like $.
I'm open to adding support for $, but would avoid using an _optional_
second option-filter because of how missing quotes will change the meaning.
Selva
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are
consuming the most bandwidth. Provides multi-vendor support for NetFlow,
J-Flow, sFlow and other flows. Make informed decisions using capacity
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
