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