Re: [Sarlug] Участие в конфе

["Paul Komkoff" <i@stingr.net>]

2009/1/19 Denis S Mikhlevich <mikhlevich@gmail.com>:
>> udp/tcp?
> udp

good.

dev tun or dev tap?

>> comp lzo?
>
> раскоменчено comp-lzo

--comp-lzo [mode]
Use fast LZO compression -- may add up to 1 byte per packet for
incompressible data. mode may be "yes", "no", or "adaptive" (default).
In a server mode setup, it is possible to selectively turn compression
on or off for individual clients.
First, make sure the client-side config file enables selective
compression by having at least one --comp-lzo directive, such as
--comp-lzo no. This will turn off compression by default, but allow a
future directive push from the server to dynamically change the
on/off/adaptive setting.
Next in a --client-config-dir file, specify the compression setting
for the client, for example:

comp-lzo yes
push "comp-lzo yes"

The first line sets the comp-lzo setting for the server side of the
link, the second sets the client side.

>> mssfix? fragment?
>
> Таких опций нет.

То, что у тебя эти опции не выставлены, ещё не значит того, что их нет.
http://openvpn.net/index.php/documentation/manuals/openvpn-21.html

--fragment max
Enable internal datagram fragmentation so that no UDP datagrams are
sent which are larger than max bytes.
The max parameter is interpreted in the same way as the --link-mtu
parameter, i.e. the UDP packet size after encapsulation overhead has
been added in, but not including the UDP header itself.
The --fragment option only makes sense when you are using the UDP
protocol ( --proto udp ).
--fragment adds 4 bytes of overhead per datagram.
See the --mssfix option below for an important related option to --fragment.
It should also be noted that this option is not meant to replace UDP
fragmentation at the IP stack level. It is only meant as a last resort
when path MTU discovery is broken. Using this option is less efficient
than fixing path MTU discovery for your IP link and using native IP
fragmentation instead.
Having said that, there are circumstances where using OpenVPN's
internal fragmentation capability may be your only option, such as
tunneling a UDP multicast stream which requires fragmentation.
--mssfix max
Announce to TCP sessions running over the tunnel that they should
limit their send packet sizes such that after OpenVPN has encapsulated
them, the resulting UDP packet size that OpenVPN sends to its peer
will not exceed max bytes.
The max parameter is interpreted in the same way as the --link-mtu
parameter, i.e. the UDP packet size after encapsulation overhead has
been added in, but not including the UDP header itself.
The --mssfix option only makes sense when you are using the UDP
protocol for OpenVPN peer-to-peer communication, i.e. --proto udp.
--mssfix and --fragment can be ideally used together, where --mssfix
will try to keep TCP from needing packet fragmentation in the first
place, and if big packets come through anyhow (from protocols other
than TCP), --fragment will internally fragment them.
Both --fragment and --mssfix are designed to work around cases where
Path MTU discovery is broken on the network path between OpenVPN
peers.
The usual symptom of such a breakdown is an OpenVPN connection which
successfully starts, but then stalls during active usage.
If --fragment and --mssfix are used together, --mssfix will take its
default max parameter from the --fragment max option.
Therefore, one could lower the maximum UDP packet size to 1300 (a good
first try for solving MTU-related connection problems) with the
following options:
--tun-mtu 1500 --fragment 1300 --mssfix

>> Версия openvpn?
>  OpenVPN 2.1_rc15 i386-redhat-linux-gnu [SSL] [LZO2] [EPOLL] built on Nov 30 2008

ещё иногда бывает полезно запустить копирование чего ты там копируешь,
и посмотреть на загрузку на обеих машинах.

-- 
This message represents the official view of the voices in my head