Hi,
On 16/11/17 11:29, Илья Шипицин wrote:
2017-11-16 15:21 GMT+05:00 Jan Just Keijser <janj...@nikhef.nl
<mailto:janj...@nikhef.nl>>:
Hi,
On 16/11/17 09:42, Илья Шипицин wrote:
2017-11-16 13:35 GMT+05:00 David Sommerseth <open...@sf.lists.topphemmelig.net
<mailto:open...@sf.lists.topphemmelig.net>>:
On 16/11/17 06:59, Илья Шипицин wrote:
> hi,
>
> I'm running vpn server since 2012, with comp-lzo enabled (on both
client
> and server side)
>
> in openvpn-2.4 comp-lzo is deprecated in favor of compress option.
>
> also, I'm considering switching to lz4 from lzo.
>
> any best practice how to switch lzo --> lz4 without operation
interruption ?
First of all, I'd recommend you to do some performance testing on the
typical payload you're pushing through your tunnel. You might find that
LZO can perform better than LZ4 in some scenarios with a lower CPU load.
But it is hard to come with a generic recommendation; it depends a lot
on what you push through your tunnel and how compressible that data
stream is. A bit more info can be found here:
<https://github.com/lz4/lz4/>
Another detail is the security aspects related to compressing data
streams. The CRIME attack [0] is now an ageing side-channel attack
vector which is made possible due to compression. And there are other
compression oracle attacks [1] too, like BREACH [2].
[0] <https://en.wikipedia.org/wiki/CRIME
<https://en.wikipedia.org/wiki/CRIME>>
[1] <https://en.wikipedia.org/wiki/Oracle_attack
<https://en.wikipedia.org/wiki/Oracle_attack>>
[2]
<https://threatpost.com/breach-compression-attack-steals-https-secrets-in-under-30-seconds/101579/
<https://threatpost.com/breach-compression-attack-steals-https-secrets-in-under-30-seconds/101579/>>
--compress is pushable. Not sure if you can mix lzo and lz4
it is a separate question, why pushing must be enabled (and it is not
enabled by default).
this is mostly due to historical reasons: if you enable any form of
compression, one byte is reserved in each packet for a
possible compression flag. Thus, for incompressible data, it actually
*hurts* performance to enable compression.
however, I address here another question, are lzo and lz4 mutually
exclusive ?
yes, they are: you can only specify one type of compression per server.
according to man page, you must explicitely specify either "compression lzo" or
"compression lz4".
compression, but I'd just add 'compression' in all the config files and
just "compression" is somewhat not clearly covered by documentation. is it "stub" ?
or is it "enable both lzo and lz4" ?
then only push 'compress {lzo,lz4}' to those clients that is reasonable
to use. I would not, however, enable compression itself on by default -
just have the compression framing available.
by adding
compression
or
comp-lzo
to the client config, you turn on the compression bit in each packet, and
thus allow the server to push the compression
algorithm of choice to all clients.
so, if clients support pushes (2.3 or higher), I can leave "comp-lzo" in client configs .... enable "compress lz4" in server
configs and push it ?
those clients who do not support pushes will get broken ?
yes, pretty much: all clients that have 'comp-lzo' in the client config and that support LZ4 can be told to use LZ4 compression
by adding
push "compress lz4"
in the server config.
"push-peer-info" will tell you whether a client supports LZ4 or not.
JJK
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Openvpn-users mailing list
Openvpn-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/openvpn-users
