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