| 1 |
=head1 NAME |
| 2 |
|
| 3 |
GNU-VPE - Overview of the GNU Virtual Private Ethernet suite. |
| 4 |
|
| 5 |
=head1 DESCRIPTION |
| 6 |
|
| 7 |
GVPE is a suite designed to provide a virtual private network for multiple |
| 8 |
nodes over an untrusted network. This document first gives an introduction |
| 9 |
to VPNs in general and then describes the specific implementation of GVPE. |
| 10 |
|
| 11 |
=head2 WHAT IS A VPN? |
| 12 |
|
| 13 |
VPN is an acronym, it stands for: |
| 14 |
|
| 15 |
=over 4 |
| 16 |
|
| 17 |
=item X<Virtual> |
| 18 |
|
| 19 |
Virtual means that no physical network is created (of course), but a |
| 20 |
network is I<emulated> by creating multiple tunnels between the member |
| 21 |
nodes by encapsulating and sending data over another transport network. |
| 22 |
|
| 23 |
Usually the emulated network is a normal IP or Ethernet, and the transport |
| 24 |
network is the Internet. However, using a VPN system like GVPE to connect |
| 25 |
nodes over other untrusted networks such as Wireless LAN is not uncommon. |
| 26 |
|
| 27 |
=item X<Private> |
| 28 |
|
| 29 |
Private means that non-participating nodes cannot decode ("sniff)" nor |
| 30 |
inject ("spoof") packets. This means that nodes can be connected over |
| 31 |
untrusted networks such as the public Internet without fear of being |
| 32 |
eavesdropped while at the same time being able to trust data sent by other |
| 33 |
nodes. |
| 34 |
|
| 35 |
In the case of GVPE, even participating nodes cannot sniff packets |
| 36 |
send to other nodes or spoof packets as if sent from other nodes, so |
| 37 |
communications between any two nodes is private to those two nodes. |
| 38 |
|
| 39 |
=item X<Network> |
| 40 |
|
| 41 |
Network means that more than two parties can participate in the network, |
| 42 |
so for instance it's possible to connect multiple branches of a company |
| 43 |
into a single network. Many so-called "vpn" solutions only create |
| 44 |
point-to-point tunnels, which in turn can be used to build larger |
| 45 |
networks. |
| 46 |
|
| 47 |
GVPE provides a true multi-point network in wich any number of nodes (at |
| 48 |
least a few dozen in practise, the theoretical limit is 4095 nodes) can |
| 49 |
participate. |
| 50 |
|
| 51 |
=back |
| 52 |
|
| 53 |
=head2 GVPE DESIGN GOALS |
| 54 |
|
| 55 |
=over 4 |
| 56 |
|
| 57 |
=item SIMPLE DESIGN |
| 58 |
|
| 59 |
Cipher, HMAC algorithms and other key parameters must be selected |
| 60 |
at compile time - this makes it possible to only link in algorithms |
| 61 |
you actually need. It also makes the crypto part of the source very |
| 62 |
transparent and easy to inspect, and last not least this makes it possible |
| 63 |
to hardcode the layout of all packets into the binary. GVPE goes a step |
| 64 |
further and internally reserves blocks of the same length for all packets, |
| 65 |
which virtually removes all possibilities of buffer overflows, as there is |
| 66 |
only a single type of buffer and it's always of fixed length. |
| 67 |
|
| 68 |
=item EASY TO SETUP |
| 69 |
|
| 70 |
A few lines of config (the config file is shared unmodified between all |
| 71 |
hosts) and a single run of C<gvpectrl> to generate the keys suffices to |
| 72 |
make it work. |
| 73 |
|
| 74 |
=item MAC-BASED SECURITY |
| 75 |
|
| 76 |
Since every host has it's own private key, other hosts cannot spoof |
| 77 |
traffic from this host. That makes it possible to filter packet by MAC |
| 78 |
address, e.g. to ensure that packets from a specific IP address come, in |
| 79 |
fact, from a specific host that is associated with that IP and not from |
| 80 |
another host. |
| 81 |
|
| 82 |
=back |
| 83 |
|
| 84 |
=head1 PROGRAMS |
| 85 |
|
| 86 |
Vpe comes with two programs: one daemon (C<gvpe>) and one control program |
| 87 |
(C<gvpectrl>). |
| 88 |
|
| 89 |
=over 4 |
| 90 |
|
| 91 |
=item gvpectrl |
| 92 |
|
| 93 |
Is used to generate the keys, check and give an overview of of the |
| 94 |
configuration and contorl the daemon (restarting etc.). |
| 95 |
|
| 96 |
=item gvpe |
| 97 |
|
| 98 |
Is the daemon used to establish and maintain connections to the other |
| 99 |
network members. It should be run on the gateway machine. |
| 100 |
|
| 101 |
=back |
| 102 |
|
| 103 |
=head1 COMPILETIME CONFIGURATION |
| 104 |
|
| 105 |
Please have a look at the C<gvpe.osdep(5)> manpage for platform-specific |
| 106 |
information. |
| 107 |
|
| 108 |
Here are a few recipes for compiling your gvpe, showing the extremes |
| 109 |
(fast, small, insecure OR slow, large, more secure), between you should |
| 110 |
choose: |
| 111 |
|
| 112 |
=head2 AS LOW PACKET OVERHEAD AS POSSIBLE |
| 113 |
|
| 114 |
./configure --enable-hmac-length=4 --enable-rand-length=0 |
| 115 |
|
| 116 |
Minimize the header overhead of VPN packets (the above will result in |
| 117 |
only 4 bytes of overhead over the raw ethernet frame). This is a insecure |
| 118 |
configuration because a HMAC length of 4 makes collision attacks based on |
| 119 |
the birthday paradox easy, though. |
| 120 |
|
| 121 |
=head2 MINIMIZE CPU TIME REQUIRED |
| 122 |
|
| 123 |
./configure --enable-cipher=bf --enable-digest=md4 |
| 124 |
|
| 125 |
Use the fastest cipher and digest algorithms currently available in |
| 126 |
gvpe. MD4 has been broken and is quite insecure, though. |
| 127 |
|
| 128 |
=head2 MAXIMIZE SECURITY |
| 129 |
|
| 130 |
./configure --enable-hmac-length=16 --enable-rand-length=8 --enable-digest=sha1 |
| 131 |
|
| 132 |
This uses a 16 byte HMAC checksum to authenticate packets (I guess 8-12 |
| 133 |
would also be pretty secure ;) and will additionally prefix each packet |
| 134 |
with 8 bytes of random data. In the long run, people should move to |
| 135 |
SHA-224 and beyond, but support in openssl is missing as of writing this |
| 136 |
document. |
| 137 |
|
| 138 |
In general, remember that AES-128 seems to be more secure and faster than |
| 139 |
AES-192 or AES-256, more randomness helps against sniffing and a longer |
| 140 |
HMAC helps against spoofing. MD4 is a fast digest, SHA1 or RIPEMD160 are |
| 141 |
better, and Blowfish is a fast cipher (and also quite secure). |
| 142 |
|
| 143 |
=head1 HOW TO SET UP A SIMPLE VPN |
| 144 |
|
| 145 |
In this section I will describe how to get a simple VPN consisting of |
| 146 |
three hosts up and running. |
| 147 |
|
| 148 |
=head2 STEP 1: configuration |
| 149 |
|
| 150 |
First you have to create a daemon configuation file and put it into the |
| 151 |
configuration directory. This is usually C</etc/gvpe>, depending on how you |
| 152 |
configured gvpe, and can be overwritten using the C<-c> commandline switch. |
| 153 |
|
| 154 |
Put the following lines into C</etc/gvpe/gvpe.conf>: |
| 155 |
|
| 156 |
udp-port = 50000 # the external port to listen on (configure your firewall) |
| 157 |
mtu = 1400 # minimum MTU of all outgoing interfaces on all hosts |
| 158 |
ifname = vpn0 # the local network device name |
| 159 |
|
| 160 |
node = first # just a nickname |
| 161 |
hostname = first.example.net # the DNS name or IP address of the host |
| 162 |
|
| 163 |
node = second |
| 164 |
hostname = 133.55.82.9 |
| 165 |
|
| 166 |
node = third |
| 167 |
hostname = third.example.net |
| 168 |
|
| 169 |
The only other file neccessary if the C<if-up> script that initializes the |
| 170 |
local ethernet interface. Put the following lines into C</etc/gvpe/if-up> |
| 171 |
and make it execute (C<chmod 755 /etc/gvpe/if-up>): |
| 172 |
|
| 173 |
#!/bin/sh |
| 174 |
ip link set $IFNAME address $MAC mtu $MTU up |
| 175 |
[ $NODENAME = first ] && ip addr add 10.0.1.1 dev $IFNAME |
| 176 |
[ $NODENAME = second ] && ip addr add 10.0.2.1 dev $IFNAME |
| 177 |
[ $NODENAME = third ] && ip addr add 10.0.3.1 dev $IFNAME |
| 178 |
ip route add 10.0.0.0/16 dev $IFNAME |
| 179 |
|
| 180 |
This script will give each node a different IP address in the C<10.0/16> |
| 181 |
network. The internal network (e.g. the C<eth0> interface) should then be |
| 182 |
set to a subset of that network, e.g. C<10.0.1.0/24> on node C<first>, |
| 183 |
C<10.0.2.0/24> on node C<second>, and so on. |
| 184 |
|
| 185 |
By enabling routing on the gateway host that runs C<gvpe> all nodes will |
| 186 |
be able to reach the other nodes. You can, of course, also use proxy arp |
| 187 |
or other means of pseudo-bridging (or even real briding), or (best) full |
| 188 |
routing - the choice is yours. |
| 189 |
|
| 190 |
=head2 STEP 2: create the RSA key pairs for all hosts |
| 191 |
|
| 192 |
Run the following command to generate all key pairs (that might take a |
| 193 |
while): |
| 194 |
|
| 195 |
gvpectrl -c /etc/gvpe -g |
| 196 |
|
| 197 |
This command will put the public keys into C<< |
| 198 |
/etc/gvpe/pubkeys/I<nodename> >> and the private keys into C<< |
| 199 |
/etc/gvpe/hostkeys/I<nodename> >>. |
| 200 |
|
| 201 |
=head2 STEP 3: distribute the config files to all nodes |
| 202 |
|
| 203 |
Now distribute the config files to the other nodes. This should be done in two steps, since the |
| 204 |
private keys should not be distributed. The example uses rsync-over-ssh |
| 205 |
|
| 206 |
First all the config files without the hostkeys should be distributed: |
| 207 |
|
| 208 |
rsync -avzessh /etc/gvpe first.example.net:/etc/. --exclude hostkeys |
| 209 |
rsync -avzessh /etc/gvpe 133.55.82.9:/etc/. --exclude hostkeys |
| 210 |
rsync -avzessh /etc/gvpe third.example.net:/etc/. --exclude hostkeys |
| 211 |
|
| 212 |
Then the hostkeys should be copied: |
| 213 |
|
| 214 |
rsync -avzessh /etc/gvpe/hostkeys/first first.example.net:/etc/hostkey |
| 215 |
rsync -avzessh /etc/gvpe/hostkeys/second 133.55.82.9:/etc/hostkey |
| 216 |
rsync -avzessh /etc/gvpe/hostkeys/third third.example.net:/etc/hostkey |
| 217 |
|
| 218 |
You should now check the configration by issuing the command C<gvpectrl -c |
| 219 |
/etc/gvpe -s> on each node and verify it's output. |
| 220 |
|
| 221 |
=head2 STEP 4: starting gvpe |
| 222 |
|
| 223 |
You should then start gvpe on each node by issuing a command like: |
| 224 |
|
| 225 |
gvpe -D -linfo first # first is the nodename |
| 226 |
|
| 227 |
This will make the gvpe stay in foreground. You should then see |
| 228 |
"connection established" messages. If you don't see them check your |
| 229 |
firewall and routing (use tcpdump ;). |
| 230 |
|
| 231 |
If this works you should check your networking setup by pinging various |
| 232 |
endpoints. |
| 233 |
|
| 234 |
To make gvpe run more permanently you can either run it as a daemon |
| 235 |
(by starting it without the C<-D> switch), or, much better, from your |
| 236 |
inittab. I use a line like this on my systems: |
| 237 |
|
| 238 |
t1:2345:respawn:/opt/gvpe/sbin/gvpe -D -L first >/dev/null 2>&1 |
| 239 |
|
| 240 |
=head2 STEP 5: enjoy |
| 241 |
|
| 242 |
... and play around. Sending a -HUP (C<gvpectrl -kHUP>) to the daemon |
| 243 |
will make it try to connect to all other nodes again. If you run it from |
| 244 |
inittab, as is recommended, C<gvpectrl -k> (or simply C<killall gvpe>) will |
| 245 |
kill the daemon, start it again, making it read it's configuration files |
| 246 |
again. |
| 247 |
|
| 248 |
=head1 SEE ALSO |
| 249 |
|
| 250 |
gvpe.osdep(5) for OS-depedendent information, gvpe.conf(5), gvpectrl(8), |
| 251 |
and for a description of the transports, protocol, and routing algorithm, |
| 252 |
gvpe.protocol(7). |
| 253 |
|
| 254 |
The GVPE mailinglist, at L<http://lists.schmorp.de/>, or |
| 255 |
C<gvpe@lists.schmorp.de>. |
| 256 |
|
| 257 |
=head1 AUTHOR |
| 258 |
|
| 259 |
Marc Lehmann <gvpe@schmorp.de> |
| 260 |
|
| 261 |
=head1 COPYRIGHTS AND LICENSES |
| 262 |
|
| 263 |
GVPE itself is distributed under the GENERAL PUBLIC LICENSE (see the file |
| 264 |
COPYING that should be part of your distribution). |
| 265 |
|
| 266 |
In some configurations it uses modified versions of the tinc vpn suite, |
| 267 |
which is also available under the GENERAL PUBLIC LICENSE. |
| 268 |
|
