CloudVPN HOW-TO
By popular demand, this document describes the configuration of CloudVPN in the easy way with a target of "just getting it to work". We will establish several CloudVPN server and client nodes, and will connect some clients to them (now, specifically, ethernet gate). To achieve this, we will need:
- generate some keys for TLS
- decide on network topology
- establish cloud nodes and connections among them
- connect gates to them (so it actually does something)
To get a bigger picture of it, be sure to check the CloudVPN Design Poster!
Other How-To's
If you want to achieve something else than just ethernet tunelling, we have more howto's:
- CloudVPN Ethernet Bridging with redundant connections on Ubuntu, by Fadjar Tandabawana
Step 1: generating keys
If you already generated some keys, say, for OpenVPN, this is nothing new to you. You need a CA (with key, and selfsigned certificate), and several keys (one for each node) with certificates signed by that CA. Progress is, given the GnuTLS's certtool, simple:
First, generate a CA key (DSA, 3072 bits):
$ certtool -p --outfile ca.key --dsa --bits 3072(remember to keep this key for yourself)
Then, make a self-signed certificate of that authority:
$ certtool -s --load-privkey ca.key --outfile ca.crt(now you must fill in several options - be sure to check that this key can be used for signing certificates, and as a certificate authority)
Now we need a private key for encryption. Let's use RSA one:
$ certtool -p --outfile ssl.key --bits 4096(you should check whether using RSA key of given size is legal in your country)
Now, sign the certificate using the generated CA:
$ certtool -c --outfile ssl.crt --load-privkey ssl.key \ --load-ca-privkey ca.key --load-ca-certificate ca.crt(you will be asked the same questions as those from CA self-signing - you should now disable signing of certificates, but instead enable TLS server and client purposes.)
Also, you might need some generated DH parameters - this can be done easily:
$ certtool --generate-dh-params --bits 1024 --outfile dh1024.pem(you will need to remove extra lines from the .pem, so GnuTLS can read it properly. Just make sure that the very first line of the .pem file looks exactly like "-----BEGIN DH PARAMETERS-----")
After this, each node obtains the CA certificate, his own DH parameters, and the keypair. CA key is meant to be kept safe, away from public, because it's the only thing that gives access to the network.
Step 2: Decide the network topology
This is pretty simple. You have a bunch of nodes running on several machines, and you have to decide which machines are gonna act as servers (so, therefore, listen to connections), and which nodes will be assigned to connecting to other, and which of them will do both. You have pretty free hands here: Because of CloudVPN meshing features, you can connect everything with everything, and make an extreme graph of anything you can imagine.
Step 3: Establish the network of nodes
Now, let's connect the computers with some transport lines. This means only running of 'cloud' daemons, and assigning correct options to them. I usually create a script called after the network it connects to, and use #! shell feature to feed it to cloud daemon as a configuration file. Note that there's no need to run this program as root (except if you want it to use privileged ports/files/chroot). So, just create an executable file called, for example, 'mydarknet' and fill it with this:
#!/bin/cloud -@include # load the keys you generated in step 1 ca ./ca.crt key ./ssl.key cert ./ssl.crt dh ./dh1024.pem # now, if this is a server, assign it to listen on CloudVPN port 15135 listen 0.0.0.0 15135 # you can also listen on IPv6, and also repeat 'listen' # options as many times you need it. listen :: 15136 listen 10.0.0.1 36324 # if this is not a server, you have to connect to something. connect mydarknet.myserver.com 15135 # you can connect to multiple servers - it's benefical for splitting load. connect serv1.dark.net 15135 connect serv2.dark.net 15135 connect ipv6.dark.net 15136 # to see what is being connected and routed, let's periodically export # status to a text file. You can watch it when Cloud is running. status-file ./status.txt # regenerate stats every minute. Please note that all time values in CloudVPN # are measured in microseconds. Hence 7 zeroes. status-interval 60000000 # now, make a gate that the gate-clients can use to connect. # we will later connect to this socket with a Ethernet client, # that will use cloud to transport packets. # (don't mistake this with "clients" from client/server model. This here is # much more like mesh/client.) # # If address contains with a slash, it means that we use unix(7) local sockets gate ./gate.sock # You can also allow computers on local LAN to use your computer as a gate. # 15137 is a standard gate port. gate 192.168.0.1 15137 # Also, if given configuration is meant only as a transport node, and will not # have any "own" ethernet entry point, it's suggested not to have any gates.
Given this file, it's pretty easy to run CloudVPN node now. Just 'chmod +x' the file, and run it like './mydarknet'. The node should print out some debug information, and also advertise when it gets an established connection. Be sure to watch status.txt file for connection entries too.
Step 4: Let's route something!
Let's suppose you want to route ethernet traffic through our VPN - so you need an ethernet daemon! Complete and easily usuable tap-tunneling daemon is supplied with CloudVPN package, and is called 'ether'.
If you have correctly established a cloud mesh, on machines thathave a gate, you can easily run it like this:
# ether -gate ./gate.sock ---this uses local socket gate # ether -gate '192.168.1.3 15137' ---this connect to a gate on the network
ether will create a TAP interface (therefore you need a tun/tap driver, which should be present in any modern linux distro), and will route packets from it to the network, allowing other gate-clients to receive and process them.
At present time, CloudVPN doesn't do ANY ethernet autoconfiguration, so you will have to either assign your internal IP addresses manually with ifconfig, or, for larger networks, run a DHCP daemon on some of the nodes. When the IP's are assigned, you should be able to ping other IPs without any trouble. boing! finished!
Problems?
Go to IRC and visit #cloudvpn on irc.freenode.net, I'm usually there.
What about BSD's TAP interfaces?
On FreeBSD (and probably most other BSD's) it's pretty easy - you just have to create the TAP interface:
# ifconfig tap0 create --to create the interface # ifconfig tap0 destroy --to delete the interface
On OpenBSD this gets a little more complicated.
# ifconfig tun0 create --create tunnel # ifconfig tun0 link0 --assign it to link layer (ethernet) # ifconfig tun0 destroy # ether -gate '...' -iface_dev tun0
It eats all my CPU and doesn't do anything!
There's a common problem: you didn't notice that all time values in config are in microseconds. If this doesn't help, please try to check if some kind of loop occured, see whether it sends or receives traffic, and generally report it to IRC channel, because it's most probably a bug.
I got warning 'could not unlink socket gate.sock' or similar, and gate file doesn't disappear, preventing next start of cloud!
You can always remove it manually - simply add a rm to startup script. But that is ugly.
Better way is to check why cloud daemon can't unlink it after. Common problem is when you use 'user' or 'group' option to drop privileges, and sockets are created in directory that only root can unlink in. Fix is simple, best thing to use is probably this:
# cd /var/lib # mkdir cloudvpn # chown cloud:nobody cloudvpn -R # cloud -gate /var/lib/cloudvpn/gate.sock -user cloud -group nobody .....
last modification: 2009-09-19 12:54:47 +0200