[Openvpn-devel] (no subject)

[James Y. <ji...@yo...>]

A new release of the 2.0 beta is available.

* One of the goals of OpenVPN 2.0 is extreme scalability, i.e. robustly
handling connections from potentially thousands of clients.  To do this, some
kind of load balancing and failover capability is needed, because a single
OpenVPN daemon running on a single processor may not be able to handle this
kind of load.  One solution is to set up a cluster of near-identically
configured OpenVPN daemons on separate machines, or multiple daemons on a
multiprocessor machine, or both.  Each daemon is running with --mode server
and can handle multiple clients.

The feature that makes this now possible is that --remote has been extended to
allow a list of remote servers and port numbers to be specified on the client
such as:

  remote server1 5000
  remote server1 5001
  remote server2 5000
  remote server2 5001
  
By default the OpenVPN client will try each host/port in the order specified.
 If the connection fails (such as triggered by --ping/--ping-restart) the
client will move to the next host in the list.  The client can also initially
randomize the list using the new --remote-random flag, to provide a basic
load-balancing capability.

The servers are configured almost identically, though each has its own port
number and --ifconfig-pool IP address range.

* Harald Roelle has observed some limitations in the current Linux 2.4 and 2.6
tun/tap driver.  Specifically, the TX queue size is set to 10 by default,
which is too small.  There is also a problem with "kicking" where a packet in
the driver may get stuck there and need another packet to come through to
"kick" it out.  This may account for the "no buffer space available" message
that some Linux users report.  To work around this problem, OpenVPN has added
a --txqueuelen option to raise the queue length to a more sane size, and now
defaults to 100.  Right now, this is a Linux-only option.  I've also added
--rcvbuf and --sndbuf to control the TCP/UDP socket buffer sizes.  Harald
Roelle and Max Krasnyansky have put together some patches which fix the Linux
tun/tap driver issues, and should (hopefully) be in the pipeline shortly for
inclusion in the mainline 2.4 and 2.6 branches.  For now, --txqueuelen will
provide a workaround.

At this point I would say that nearly all of the key features which have been
envisaged for 2.0 are in place with a few exceptions:

* TCP Support in the multi-client server -- The only way that I can see of
scalably adding TCP support (without using multiple threads or processes) is
to use an efficient multi-socket API such as epoll() which is available on
Linux 2.6 and also apparently on 2.4 via a kernel patch.

* Forking server support -- The 2.0 multi-client server model is designed for
people who want a potentially large number of clients to tunnel through a
single tun or tap interface using a single daemon process.  Some people
however might prefer the forking server model, where the server automatically
forks off a new process for each incoming client, dynamically allocating a
private tun/tap interface for that client.

* Multithreading support -- multithreading offers two key advantages: (1) it
reduces the worst-case latency of packets flowing through the tunnel and (2)
it offers the opportunity for a single daemon to utilize all the processors on
an multiprocessor machine.  Unfortunately, multithreading causes a lot of
problems including complexifying the source code and introducing
race-condition bugs which can be extremely difficult to reproduce or track
down.  My thinking at this point is that implementing multithreading may not
be worth the trouble, especially given the fact that the new load balancing
feature can allow multiple OpenVPN daemons running on multiple machines to
serve the same client pool.

* Compatibility with 1.x -- OpenVPN 2.0 tries as much as possible to be
upwardly compatible with 1.x.  The main difference is that 2.0 changes some
parameter defaults.  The tun/tap MTU has been raised to 1500, --mssfix 1450 is
now the default, and --key-method now defaults to 2.  The only feature which
has been removed is the special-purpose SSL/TLS thread feature which is
enabled on 1.x if you build OpenVPN with the --enable-pthread flag.  I might
put it back if people complain, but overall I'm not sure that it's worth the
trouble.

Change Log:

2004.04.28 -- Version 2.0-test26

* Optimized broadcast path in multi-client mode.
* Added socket buffer size options --rcvbuf & --sndbuf.
* Configure Linux tun/tap driver to use a more sensible
  txqueuelen default.  Also allow explicit setting
  via --txqueuelen option (Harald Roelle).
* The --remote option now allows the port number
  to be specified as the second parameter.  If
  unspecified, the port number defaults to the
  --rport value.
* Multiple --remote options on the client can now be
  specified for load balancing and failover.  The
  --remote-random flag can be used to initially randomize
  the --remote list for basic load balancing.
* If a remote DNS name resolves to multiple DNS addresses,
  one will be chosen by random as a kind of basic
  load-balancing feature if --remote-random is used.
* Added --connect-freq option to control maximum
  new connection frequency in multi-client mode.
* In multi-client mode, all syslog messages associated
  with a specific client now include a client-ID prefix.
* For Windows, use a gettimeofday() function based
  on QueryPerformanceCounter (Derek Burdick).
* Fixed bug in interaction between --key-method 2
  and DES ciphers, where dynamic keys would be generated
  with bad parity and then be rejected.


Download:

http://openvpn.sourceforge.net/beta/