| 1 |
pcg |
1.1 |
|
| 2 |
pcg |
1.2 |
==== NAME ==== |
| 3 |
|
|
|
| 4 |
|
|
vpe - Overview of the virtual private ethernet suite. |
| 5 |
|
|
|
| 6 |
|
|
|
| 7 |
|
|
==== DESCRIPTION ==== |
| 8 |
|
|
|
| 9 |
|
|
Vpe is a suite designed to provide a virtual private network for |
| 10 |
|
|
multiple nodes over an untrusted network. |
| 11 |
|
|
|
| 12 |
|
|
"Virtual" means that no physical network is created (of course), but an |
| 13 |
|
|
ethernet is emulated by creating multiple tunnels between the member |
| 14 |
|
|
nodes. "Private" means that non-participating nodes cannot decode |
| 15 |
|
|
("sniff)" nor inject ("spoof") packets. In the case of vpe, even |
| 16 |
|
|
participating nodes cannot spoof packets from other nodes. And "network" |
| 17 |
|
|
means that more than two parties - many so-called vpn solutions only |
| 18 |
|
|
create point-to-point tunnels - can participate in the network, so it's |
| 19 |
|
|
possible to connect multiple branches of a company into a single |
| 20 |
|
|
network. |
| 21 |
|
|
|
| 22 |
|
|
|
| 23 |
|
|
== DESIGN GOALS == |
| 24 |
|
|
|
| 25 |
|
|
: SIMPLE DESIGN |
| 26 |
|
|
Cipher, HMAC algorithms and other key parameters must be selected at |
| 27 |
|
|
compile time - this makes it possible to only link in algorithms you |
| 28 |
|
|
actually need. It also makes the crypto part of the source very |
| 29 |
|
|
transparent and easy to inspect. |
| 30 |
|
|
|
| 31 |
|
|
: EASY TO SETUP |
| 32 |
|
|
A few lines of config (the config file is shared unmodified between |
| 33 |
|
|
all hosts) and a single run of ``vpectrl'' to generate the keys |
| 34 |
|
|
suffices to make it work. |
| 35 |
|
|
|
| 36 |
|
|
: MAC-BASED SECURITY |
| 37 |
|
|
Since every host has it's own private key, other hosts cannot spoof |
| 38 |
|
|
traffic from this host. That makes it possible to filter packest by |
| 39 |
|
|
MAC address, e.g. to ensure that packets from a specific IP address |
| 40 |
|
|
come, in fact, from a specific host. |
| 41 |
|
|
|
| 42 |
|
|
|
| 43 |
|
|
==== PROGRAMS ==== |
| 44 |
|
|
|
| 45 |
|
|
Vpe comes with two programs: one daemon (``vped'') and one control |
| 46 |
|
|
program ``vpectrl''). |
| 47 |
|
|
|
| 48 |
|
|
: vpectrl |
| 49 |
|
|
Is used to generate the keys and give an overview of the |
| 50 |
|
|
configuration. |
| 51 |
|
|
|
| 52 |
|
|
: vped |
| 53 |
|
|
Is the daemon used to establish and maintain conenctions to the |
| 54 |
|
|
other network members. It should be run on the gateway machine. |
| 55 |
|
|
|
| 56 |
|
|
|
| 57 |
|
|
==== CONFIGURING VPE ==== |
| 58 |
|
|
|
| 59 |
|
|
Here are a few recipes for configuring your vpe: |
| 60 |
|
|
|
| 61 |
|
|
|
| 62 |
|
|
== AS LOW PACKET OVERHEAD AS POSSIBLE == |
| 63 |
|
|
|
| 64 |
|
|
./configure --enable-hmac-length=4 --enable-rand-length=0 |
| 65 |
|
|
|
| 66 |
|
|
Minimize the header overhead of VPN packets. |
| 67 |
|
|
|
| 68 |
|
|
|
| 69 |
|
|
== MINIMIZE CPU TIME REQUIRED == |
| 70 |
|
|
|
| 71 |
|
|
./configure --enable-cipher=bf --enable-digest=md4 |
| 72 |
|
|
|
| 73 |
|
|
Use the fastest cipher and digest algorithms. |
| 74 |
|
|
|
| 75 |
|
|
|
| 76 |
|
|
== MAXIMIZE SECURITY == |
| 77 |
|
|
|
| 78 |
|
|
./configure --enable-hmac-length=16 --enable-rand-length=8 --enable-digest=sha1 |
| 79 |
|
|
|
| 80 |
|
|
In general, remember that AES-128 seems to be more secure and faster |
| 81 |
|
|
than AES-192 or AES-256, more randomness and longer hmac is more secure, |
| 82 |
|
|
MD4 is a fast digest, SHA1 or RIPEMD160 are better, and Blowfish is a |
| 83 |
|
|
fast and so-far quite secure cipher. |
| 84 |
|
|
|
| 85 |
|
|
|
| 86 |
|
|
==== HOW TO SET UP A SIMPLE VPN ==== |
| 87 |
|
|
|
| 88 |
|
|
In this section I will describe how to get a simple VPN consisting of |
| 89 |
|
|
three hosts up and running. |
| 90 |
|
|
|
| 91 |
|
|
|
| 92 |
|
|
== STEP 1: configuration == |
| 93 |
|
|
|
| 94 |
|
|
First you have to create a daemon configuation file and put it into the |
| 95 |
|
|
configuration directory. This is usually ``/etc/vpe'', depending on how |
| 96 |
|
|
you configured vpe, and can be overwritten using the ``-c'' commandline |
| 97 |
|
|
switch. |
| 98 |
|
|
|
| 99 |
|
|
Put the following lines into ``/etc/vpe/vped.conf'': |
| 100 |
|
|
|
| 101 |
|
|
udp-port = 50000 # the external port to listen on (configure your firewall) |
| 102 |
|
|
mtu = 1400 # minimum MTU of all outgoing interfaces on all hosts |
| 103 |
|
|
ifname = vpn0 # the local network device name |
| 104 |
|
|
|
| 105 |
|
|
node = first # just a nickname |
| 106 |
|
|
hostname = first.example.net # the DNS name or IP address of the host |
| 107 |
|
|
|
| 108 |
|
|
node = second |
| 109 |
|
|
hostname = 133.55.82.9 |
| 110 |
|
|
|
| 111 |
|
|
node = third |
| 112 |
|
|
hostname = third.example.net |
| 113 |
|
|
|
| 114 |
|
|
The only other file neccessary if the ``if-up'' script that initializes |
| 115 |
|
|
the local ethernet interface. Put the following lines into |
| 116 |
|
|
``/etc/vpe/if-up'' and make it execute (``chmod 755 /etc/vpe/if-up''): |
| 117 |
|
|
|
| 118 |
|
|
#!/bin/sh |
| 119 |
|
|
ip link set $IFNAME address $MAC mtu $MTU up |
| 120 |
|
|
[ $NODENAME = first ] && ip addr add 10.0.1.1 dev $IFNAME |
| 121 |
|
|
[ $NODENAME = second ] && ip addr add 10.0.2.1 dev $IFNAME |
| 122 |
|
|
[ $NODENAME = third ] && ip addr add 10.0.3.1 dev $IFNAME |
| 123 |
|
|
ip route add 10.0.0.0/16 dev $IFNAME |
| 124 |
|
|
|
| 125 |
|
|
This script will give each node a different IP address in the |
| 126 |
|
|
``10.0/16'' network. The internal network (e.g. the ``eth0'' interface) |
| 127 |
|
|
should then be set to a subset of that network, e.g. ``10.0.1.0/24'' on |
| 128 |
|
|
node ``first'', ``10.0.2.0/24'' on node ``second'', and so on. |
| 129 |
|
|
|
| 130 |
|
|
By enabling routing on the gateway host that runs ``vped'' all nodes |
| 131 |
|
|
will be able to reach the other nodes. You can, of course, also use |
| 132 |
|
|
proxy arp or other means of pseudo-bridging (or even real briding), or |
| 133 |
|
|
(best) full routing - the choice is yours. |
| 134 |
|
|
|
| 135 |
|
|
|
| 136 |
|
|
== STEP 2: create the RSA key pairs for all hosts == |
| 137 |
|
|
|
| 138 |
|
|
Run the following command to generate all key pairs (that might take a |
| 139 |
|
|
while): |
| 140 |
|
|
|
| 141 |
|
|
vpectrl -c /etc/vpe -g |
| 142 |
|
|
|
| 143 |
|
|
This command will put the public keys into |
| 144 |
|
|
``/etc/vpe/pubkeys/*nodename*'' and the private keys into |
| 145 |
|
|
``/etc/vpe/hostkeys/*nodename*''. |
| 146 |
|
|
|
| 147 |
|
|
|
| 148 |
|
|
== STEP 3: distribute the config files to all nodes == |
| 149 |
|
|
|
| 150 |
|
|
Now distribute the config files to the other nodes. This should be done |
| 151 |
|
|
in two steps, since the private keys should not be distributed. The |
| 152 |
|
|
example uses rsync-over-ssh |
| 153 |
|
|
|
| 154 |
|
|
First all the config files without the hostkeys should be distributed: |
| 155 |
|
|
|
| 156 |
|
|
rsync -avzessh /etc/vpe first.example.net:/etc/. --exclude hostkeys |
| 157 |
|
|
rsync -avzessh /etc/vpe 133.55.82.9:/etc/. --exclude hostkeys |
| 158 |
|
|
rsync -avzessh /etc/vpe third.example.net:/etc/. --exclude hostkeys |
| 159 |
|
|
|
| 160 |
|
|
Then the hostkeys should be copied: |
| 161 |
|
|
|
| 162 |
|
|
rsync -avzessh /etc/vpe/hostkeys/first first.example.net:/etc/hostkey |
| 163 |
|
|
rsync -avzessh /etc/vpe/hostkeys/second 133.55.82.9:/etc/hostkey |
| 164 |
|
|
rsync -avzessh /etc/vpe/hostkeys/third third.example.net:/etc/hostkey |
| 165 |
|
|
|
| 166 |
|
|
You should now check the configration by issuing the command ``vpectrl |
| 167 |
|
|
-c /etc/vpe -s'' on each node and verify it's output. |
| 168 |
|
|
|
| 169 |
|
|
|
| 170 |
|
|
== STEP 4: starting vped == |
| 171 |
|
|
|
| 172 |
|
|
You should then start vped on each node by issuing a command like: |
| 173 |
|
|
|
| 174 |
|
|
vped -D -linfo first # first is the nodename |
| 175 |
|
|
|
| 176 |
|
|
This will make the vped stay in foreground. You should then see |
| 177 |
|
|
"connection established" messages. If you don't see them check your |
| 178 |
|
|
firewall and routing (use tcpdump ;). |
| 179 |
|
|
|
| 180 |
|
|
If this works you should check your networking setup by pinging various |
| 181 |
|
|
endpoints. |
| 182 |
|
|
|
| 183 |
|
|
To make vped run more permanently you can either run it as a daemon (by |
| 184 |
|
|
starting it without the ``-D'' switch), or, much better, from your |
| 185 |
|
|
inittab. I use a line like this on my systems: |
| 186 |
|
|
|
| 187 |
|
|
t1:2345:respawn:/opt/vpe/sbin/vped -D -L first >/dev/null 2>&1 |
| 188 |
|
|
|
| 189 |
|
|
|
| 190 |
|
|
== STEP 5: enjoy == |
| 191 |
|
|
|
| 192 |
|
|
... and play around. Sending a -HUP (``vpectrl -kHUP'') to the daemon |
| 193 |
|
|
will make it try to connect to all other nodes again. If you run it from |
| 194 |
|
|
inittab, as is recommended, ``vpectrl -k'' (or simply ``killall vped'') |
| 195 |
|
|
will kill the daemon, start it again, making it read it's configuration |
| 196 |
|
|
files again. |
| 197 |
|
|
|
| 198 |
|
|
|
| 199 |
|
|
==== SEE ALSO ==== |
| 200 |
|
|
|
| 201 |
|
|
vpe(8), vpectrl(8), vped.conf(5). |
| 202 |
|
|
|
| 203 |
|
|
|
| 204 |
|
|
==== AUTHOR ==== |
| 205 |
|
|
|
| 206 |
|
|
Marc Lehmann <vpe@plan9.de> |
| 207 |
|
|
|
