This article describes a method for remotely accessing virtual servers. The aim is to be able to have multiple clients access one or more virtual servers across one or more physical hosts as if everyone was on the same LAN. It is also necessary to do this without compromising on security and without ANY extra configuration for the virtual servers.
We will achieve this using Qemu and Openvpn.
I’m assuming you have basic knowledge of whatever host operating system you’re using and basic networking knowledge.
I’m not going to bother telling you how to install the two programs you need, etc.
Other than that, I hope I’ve covered everything (or at least pointed you towards external documentation).
If there’s something you’re stuck on then leave a comment or email me (address below) and I’ll do my best to assist and update this guide if necessary.
I will assume that you already have your virtual machines set up. If not then the Qemu manual will get you started.
The guest can be basically any operating system that’s capable of networking. No special configuration is required. I’m just using a few existing virtual machines from previous projects.
You will need to add the following options to the qemu command line:
"-net nic -net tap,script=no,downscript=no"
The “-net nic” option creates a virtual network card. The “-net tap” option creates a tap network device on the host, we will connect this to Openvpn later. For an explanation of what this means, see the Wikipedia article.
Start your virtual machine with the additional options given and assign it a static IP address (I’m using 10.0.0.1).
The Openvpn website contains all the information you could want on configuring Openvpn.
Here’s a link to the documentation: http://openvpn.net/index.php/open-source/documentation/howto.html
Pick a set of instructions that suit your needs and use them as a basis for this setup.
If you only need to connect to the server from one client, select the “quick start guide”. If you need more than one then follow the sections titled “Setting up your own Certificate Authority (CA) and generating certificates and keys for an OpenVPN server and multiple clients.” and “Creating configuration files for server and clients”.
Either of these sets of instructions will give you a decent basis for the rest of this guide. We will choose an IP range for the VPN later on.
Routing or Bridging?
You’ll also need to choose between creating a bridged network or a routed network. Again, the Openvpn site has plenty of information on making this choice, consider reading this page.
In summary, use bridging if you need network broadcasts for any reason or want to be able to browse for windows shares (eg: under “network neighbourhood”, etc). Otherwise use routing.
The two (rather crude, I’m afraid) diagrams below illustrate the differences between the two setups.
In the bridged setup, ethernet frames (black arrows) are transferred across the VPN. This enables non-IP traffic to be transferred, but increases the overheads. The two TAP devices are bridged in this setup.
In the routed setup, IP packets (green arrows) are transferred across the VPN. This results in less data needing to be transferred across the VPN.
IP range setup
If you’re using a bridged setup then you should use the “server-bridge” option to set the client and server IPs.
You should put everything in the same subnet.
You should leave some room free in the subnet for the virtual server.
For example, I assigned my virtual server 10.0.0.1.
I’m assigning the Openvpn server 10.0.0.2 and clients IPs from 10.0.0.50 to 10.0.0.100.
The config file line looks like this:
server-bridge 10.0.0.2 255.255.255.0 10.0.0.50 10.0.0.100
If you’re using a routed setup then you should use the “server” option to set the client and server IPs.
You should use seperate subnets for the VPN and virtual server.
For example, my virtual server is 10.0.0.1.
I’m assigning the Openvpn server 10.1.0.1 and clients IPs from 10.1.0.2 to 10.1.0.254.
The config file line looks like this:
server 10.1.0.0 255.255.255.0
You’ll also need to tell the Openvpn server to instruct clients to add a routing entry for the virtual server’s subnet:
push "route 10.0.0.0 255.255.255.0"
Connecting the two
The method for connecting the two is different depending on whether you chose bridging (tap adapter) or routing (tun adapter). Either way, I assume you’ve started Qemu and Openvpn successfully and can connect to the Openvpn server ok.
For the bridging scenario you have two tap devices, one created by Qemu and one by Openvpn. All you need to do is bridge the two.
Configure the tap devices:
# ifconfig tap0 0.0.0.0 promisc up
# ifconfig tap1 0.0.0.0 promisc up
Create the bridge device:
# brctl addbr br0
# ifconfig br0 0.0.0.0 promisc up
Add the tap devices to the bridge:
# brctl addif br0 tap0
# brctl addif br0 tap1
If you chose to configure Openvpn for routing then you have one tap device created by Qemu and one tun device created by Openvpn.
It’s just a simple matter of configuring the host to forward packets between the two.
Assign an IP address to the tap device:
# ifconfig tap0 10.0.0.2
Enable IP forwarding
# echo 1 > /proc/sys/net/ipv4/ip_forward
Testing it out
You should now be able to communicate between the client and the virtual server.
If you chose a routed setup, you can also ping between the client and physical server (over the vpn) and between the physical server and the virtual one. This may be useful for locating problems.
Adding more virtual servers
In a bridged setup, adding more virtual servers is extremely easy. Simply start the new VM exactly as you did the first one and add the new TAP device to the bridge.
# brctl addif br0 tap2
With a routed setup, if you want more than one virtual server you’ll have to add a host route for each virtual server.
# route add 10.1.0.1 dev tap1
# route add 10.1.0.2 dev tap2
Adding more physical servers
If you add more physical servers then they will (confusingly) be openvpn clients.
Configure it exactly like any other client. Connecting the virtual servers on a new physical server is done exactly as we did it earlier in the article.
You will need to add the “client-to-client” option to your configuration file.
If you see any errors with this article, have any comments/suggestions or need any help then feel free to leave a comment or email me (address below) and I will get back to you.
Thanks for reading, I hope this has been useful.