… | |
… | |
66 | only a single type of buffer and it's always of fixed length. |
66 | only a single type of buffer and it's always of fixed length. |
67 | |
67 | |
68 | =item EASY TO SETUP |
68 | =item EASY TO SETUP |
69 | |
69 | |
70 | A few lines of config (the config file is shared unmodified between all |
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 |
71 | hosts) and generating an RSA key-pair on each node suffices to make it |
72 | make it work. |
72 | work. |
73 | |
73 | |
74 | =item MAC-BASED SECURITY |
74 | =item MAC-BASED SECURITY |
75 | |
75 | |
76 | Since every host has it's own private key, other hosts cannot spoof |
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 |
77 | traffic from this host. That makes it possible to filter packet by MAC |
… | |
… | |
117 | |
117 | |
118 | ./configure --enable-hmac-length=4 --enable-rand-length=0 |
118 | ./configure --enable-hmac-length=4 --enable-rand-length=0 |
119 | |
119 | |
120 | Minimize the header overhead of VPN packets (the above will result in |
120 | Minimize the header overhead of VPN packets (the above will result in |
121 | only 4 bytes of overhead over the raw ethernet frame). This is a insecure |
121 | only 4 bytes of overhead over the raw ethernet frame). This is a insecure |
122 | configuration because a HMAC length of 4 makes collision attacks based on |
122 | configuration because a HMAC length of 4 makes collision attacks almost |
123 | the birthday paradox pretty easy. |
123 | trivial. |
124 | |
124 | |
125 | =head2 MINIMIZE CPU TIME REQUIRED |
125 | =head2 MINIMIZE CPU TIME REQUIRED |
126 | |
126 | |
127 | ./configure --enable-cipher=bf --enable-digest=md4 |
127 | ./configure --enable-cipher=bf --enable-digest=md4 |
128 | |
128 | |
… | |
… | |
130 | gvpe. MD4 has been broken and is quite insecure, though, so using another |
130 | gvpe. MD4 has been broken and is quite insecure, though, so using another |
131 | digest algorithm is recommended. |
131 | digest algorithm is recommended. |
132 | |
132 | |
133 | =head2 MAXIMIZE SECURITY |
133 | =head2 MAXIMIZE SECURITY |
134 | |
134 | |
135 | ./configure --enable-hmac-length=16 --enable-rand-length=16 --enable-digest=sha384 |
135 | ./configure --enable-hmac-length=16 --enable-rand-length=12 --enable-digest=ripemd610 |
136 | |
136 | |
137 | This uses a 16 byte HMAC checksum to authenticate packets (I guess 8-12 |
137 | This uses a 16 byte HMAC checksum to authenticate packets (I guess 8-12 |
138 | would also be pretty secure ;) and will additionally prefix each packet |
138 | would also be pretty secure ;) and will additionally prefix each packet |
139 | with 16 bytes of random data. |
139 | with 12 bytes of random data. |
140 | |
140 | |
141 | In general, remember that AES-128 seems to be as secure but faster than |
141 | In general, remember that AES-128 seems to be as secure but faster than |
142 | AES-192 or AES-256, more randomness helps against sniffing and a longer |
142 | AES-192 or AES-256, more randomness helps against sniffing and a longer |
143 | HMAC helps against spoofing. MD4 is a fast digest, SHA1, RIPEMD160, SHA256 |
143 | HMAC helps against spoofing. MD4 is a fast digest, SHA1, RIPEMD160, SHA256 |
144 | are consecutively better, and Blowfish is a fast cipher (and also quite |
144 | are consecutively better, and Blowfish is a fast cipher (and also quite |
… | |
… | |
189 | By enabling routing on the gateway host that runs C<gvpe> all nodes will |
189 | By enabling routing on the gateway host that runs C<gvpe> all nodes will |
190 | be able to reach the other nodes. You can, of course, also use proxy ARP |
190 | be able to reach the other nodes. You can, of course, also use proxy ARP |
191 | or other means of pseudo-bridging, or (best) full routing - the choice is |
191 | or other means of pseudo-bridging, or (best) full routing - the choice is |
192 | yours. |
192 | yours. |
193 | |
193 | |
194 | =head2 STEP 2: create the RSA key pairs for all hosts |
194 | =head2 STEP 2: create the RSA key pair for each node |
195 | |
195 | |
196 | Run the following command to generate all key pairs for all nodes (that |
196 | Next you have to generate the RSA keys for the nodes. While you can set |
197 | might take a while): |
197 | up GVPE so you can generate all keys on a single host and centrally |
|
|
198 | distribute all keys, it is safer to generate the key for each node on the |
|
|
199 | node, so that the secret/private key does not have to be copied over the |
|
|
200 | network. |
198 | |
201 | |
|
|
202 | To do so, run the following command to generate a key pair: |
|
|
203 | |
199 | gvpectrl -c /etc/gvpe -g |
204 | gvpectrl -c /etc/gvpe -g nodekey |
200 | |
205 | |
201 | This command will put the public keys into C<< |
206 | This will create two files, F<nodekey> and F<nodekey.privkey>. The former |
202 | /etc/gvpe/pubkeys/I<nodename> >> and the private keys into C<< |
207 | should be copied to F<< /etc/gvpe/pubkey/I<nodename> >> on the host where |
203 | /etc/gvpe/hostkeys/I<nodename> >>. |
208 | your config file is (you will have to create the F<pubkey> directory |
|
|
209 | first): |
|
|
210 | |
|
|
211 | scp nodekey confighost:/etc/gvpe/pubkey/nodename |
|
|
212 | |
|
|
213 | The private key F<nodekey.privkey> should be moved to F</etc/gvpe/hostkey>: |
|
|
214 | |
|
|
215 | mkdir -p /etc/gvpe |
|
|
216 | mv nodekey.privkey /etc/gvpe/hostkey |
204 | |
217 | |
205 | =head2 STEP 3: distribute the config files to all nodes |
218 | =head2 STEP 3: distribute the config files to all nodes |
206 | |
219 | |
207 | Now distribute the config files and private keys to the other nodes. This |
220 | Now distribute the config files and public keys to the other nodes. |
208 | should be done in two steps, since only the private keys meant for a node |
|
|
209 | should be distributed (so each node has only it's own private key). |
|
|
210 | |
221 | |
211 | The example uses rsync-over-ssh |
222 | The example uses rsync-over-ssh to copy the config file and all the public |
|
|
223 | keys: |
212 | |
224 | |
213 | First all the config files without the hostkeys should be distributed: |
|
|
214 | |
|
|
215 | rsync -avzessh /etc/gvpe first.example.net:/etc/. --exclude hostkeys |
225 | rsync -avzessh /etc/gvpe first.example.net:/etc/. --exclude hostkey |
216 | rsync -avzessh /etc/gvpe 133.55.82.9:/etc/. --exclude hostkeys |
226 | rsync -avzessh /etc/gvpe 133.55.82.9:/etc/. --exclude hostkey |
217 | rsync -avzessh /etc/gvpe third.example.net:/etc/. --exclude hostkeys |
227 | rsync -avzessh /etc/gvpe third.example.net:/etc/. --exclude hostkey |
218 | |
228 | |
219 | Then the hostkeys should be copied: |
|
|
220 | |
|
|
221 | rsync -avzessh /etc/gvpe/hostkeys/first first.example.net:/etc/hostkey |
|
|
222 | rsync -avzessh /etc/gvpe/hostkeys/second 133.55.82.9:/etc/hostkey |
|
|
223 | rsync -avzessh /etc/gvpe/hostkeys/third third.example.net:/etc/hostkey |
|
|
224 | |
|
|
225 | You should now check the configuration by issuing the command C<gvpectrl -c |
229 | You should now check the configuration by issuing the command C<gvpectrl |
226 | /etc/gvpe -s> on each node and verify it's output. |
230 | -c /etc/gvpe -s> on each node and verify it's output. |
227 | |
231 | |
228 | =head2 STEP 4: starting gvpe |
232 | =head2 STEP 4: starting gvpe |
229 | |
233 | |
230 | You should then start gvpe on each node by issuing a command like: |
234 | You should then start gvpe on each node by issuing a command like: |
231 | |
235 | |
… | |
… | |
246 | |
250 | |
247 | =head2 STEP 5: enjoy |
251 | =head2 STEP 5: enjoy |
248 | |
252 | |
249 | ... and play around. Sending a -HUP (C<gvpectrl -kHUP>) to the daemon |
253 | ... and play around. Sending a -HUP (C<gvpectrl -kHUP>) to the daemon |
250 | will make it try to connect to all other nodes again. If you run it from |
254 | will make it try to connect to all other nodes again. If you run it from |
251 | inittab, as is recommended, C<gvpectrl -k> (or simply C<killall gvpe>) will |
255 | inittab C<gvpectrl -k> (or simply C<killall gvpe>) will kill the daemon, |
252 | kill the daemon, start it again, making it read it's configuration files |
256 | start it again, making it read it's configuration files again. |
253 | again. |
257 | |
|
|
258 | To run the GVPE daemon permanently from your SysV init, you can add it to |
|
|
259 | your F<inittab>, e.g.: |
|
|
260 | |
|
|
261 | t1:2345:respawn:/bin/sh -c "exec nice -n-20 /path/to/gvpe -D node >/var/log/gvpe.log 2>&1" |
|
|
262 | |
|
|
263 | For systems using systemd, you can use a unit file similar to this one: |
|
|
264 | |
|
|
265 | [Unit] |
|
|
266 | Description=gvpe |
|
|
267 | After=network.target |
|
|
268 | Before=remote-fs.target |
|
|
269 | |
|
|
270 | [Service] |
|
|
271 | ExecStart=/path/to/gvpe -D node |
|
|
272 | KillMode=process |
|
|
273 | Restart=always |
|
|
274 | |
|
|
275 | [Install] |
|
|
276 | WantedBy=multi-user.target |
254 | |
277 | |
255 | =head1 SEE ALSO |
278 | =head1 SEE ALSO |
256 | |
279 | |
257 | gvpe.osdep(5) for OS-dependent information, gvpe.conf(5), gvpectrl(8), |
280 | gvpe.osdep(5) for OS-dependent information, gvpe.conf(5), gvpectrl(8), |
258 | and for a description of the transports, protocol, and routing algorithm, |
281 | and for a description of the transports, protocol, and routing algorithm, |