VPN implementation
------------------

This directory contains a virtual private network implementation.

A virtual private network is one ore more local nets that are bridged using
the Internet, so the separate networks appear as one whole. This is the
"virtual" part.

The Internet is full of baddies. If the communications are to be safe, they
must be encrypted. This constitutes the "private" part.

The example consists of one server and one client. They use pppd to establish
the network interfaces and transmit packets. All IP packets can be relayed,
which means you get TCP/IP, UDP/IP, etc. And yes, you can play Quake over the
link.

Setting up PPPD
---------------

You need pppd 2.3.11 or later installed on your system. If it crashes when
transferring large amounts of data, get the pppd-2.3.11 sources and apply the
patch (also in this directory) to it before compiling and installing. Like
this:

tar -xzvf ppp-2.3.11.tar.gz
patch -p0 < ppp-2.3.11-charshunt-again.patch

Then compile and install it as normal. This is a bug in the pppd charshunt -
its maintainers have been notified.

Preparing the server/client
---------------------------

The client has to connect to the server to establish the link, and the
IP/port it connects to is hardcoded into the source as of now. It defaults to
"localhost", port 2140.

Also, the IPs of the virtual network interfaces it uses is specified as an
argument to pppd in the client.

When you're done editing the sources, recompile by issuing a "make" in this
directory. Put the server on one host and the client on another (they can
both be on the same host too, which will result in an encrypted loopback
interface).

Become root on both sides. Start the server. Wait for it to generate a host
key. Then start the client.

You can test the connection by pinging through the PPP interfaces you get.
Setting up routes is done as with any other network interface, typically with
the "route" command.

Important
---------

This is just a toy implementation. It does encryption, but _not_
authentication, so if you use it unmodified, it's not regarded as secure.

Adding authentication is a relatively small matter, though. After the
encrypted link is established, you can use challenge/response or password
exchange to ensure that the hosts are who you expect.

As mentioned, this is a client/server solution. I did it this way because
it's the easiest to demonstrate and understand. However, a nice
implementation would use a peer-peer connection/authentication scheme, where
any one of the hosts can contact the other. This is also relatively simple to
add.
