You don't want to be messing around with trying to test OpenVPN over the Internet; you want a safe, controlled environment for testing before you deploy it.
Not a problem. Just build a little test lab with three computers. One acts as the remote PC, the second one is the OpenVPN server and router, and the third one represents your LAN. The PC acting as the OpenVPN server and router needs two Ethernet interfaces. With this setup, you can test OpenVPN configurations and firewall rules safely, and in a realistic manner. These should be in physical proximity to each other because when you start messing with networking, you're going to lose connectivity. You should use Ethernet cables and a switch; don't try this with wireless unless you enjoy introducing more problems.
Before you do anything else, install OpenVPN on the remote PC
and the machine that is going to be your OpenVPN server. In this
recipe, all three computers are running Linux. (We'll get to other
clients later in the chapter.) OpenVPN is included in most Linux
distributions, so it's just a yum install
openvpn or aptitude install
openvpn away.
Setting up routes can get a bit confusing, especially if you still rely on cheat sheets for calculating subnets (like I do), and have to draw network diagrams even for simple setups (which I must also do), so take it slowly and follow these steps exactly. You can always change addresses and routes later. Your test network should look like Figure 9-1.
Connect the remote PC to the server directly with a crossover cable. In this recipe, I'll use Xena as the name of the OpenVPN server, Stinkpad as the remote client, and Uberpc represents the rest of the LAN.
Xena and Stinkpad need to be on different subnets, so our network addressing looks like this:
- Stinkpad
eth0 address 192.168.2.100 netmask 255.255.255.0 broadcast 192.168.2.255 - Xena
eth0- LAN interface address 192.168.1.10 netmask 255.255.255.0 broadcast 192.168.1.255 eth1- "Internet" interface address 192.168.3.10 netmask 255.255.255.0 broadcast 192.168.3.255 - Uberpc
eth0 address 192.168.1.76 netmask 255.255.255.0 broadcast 192.168.1.255 default gateway 192.168.1.10
It doesn't matter what network configurations your PCs already have because we'll set them temporarily for testing, so you don't need to touch any configuration files. Set their IP addresses with these commands:
root@stinkpad:~# ifconfig eth0 192.168.2.100 netmask 255.255.255.0 up
root@xena:~# ifconfig eth0 192.168.1.10 netmask 255.255.255.0 up
root@xena:~# ifconfig eth1 192.168.3.11 netmask 255.255.255.0 up
root@uberpc:~# ifconfig eth1 192.168.1.76 netmask 255.255.255.0 upNow, create some static routes, and turn on forwarding on Xena, so that the bits may flow freely:
root@stinkpad:~# route del default
root@stinkpad:~# route add -net 192.168.3.0/24 gw 192.168.2.100 eth0
root@xena:~# route del default
root@xena:~# route add -net 192.168.2.0/24 gw 192.168.3.10 eth1
root@xena:~# echo 1 > /proc/sys/net/ipv4/ip_forward
root@uberpc:~# route del default
root@uberpc:~# route add default gw 192.168.1.10 eth0View your routes with the route command. If you make a mistake, routes are deleted this way, using your own network address, of course:
# route del -net 192.168.3.0/24Stinkpad and Uberpc should now be able to ping each other. Once ping is working, you can go to the next recipe to start testing OpenVPN.
If you get hopelessly messed up, simply reboot and start over.
This is designed to mimic the Internet. A real Internet connection would have routers between Stinkpad and Xena, so to emulate this, Stinkpad must be its own router and gateway. Stinkpad only needs to be routed to Xena; routing into the LAN behind Xena will be handled by the OpenVPN server, which we'll get to later in this chapter.
You may add more computers if you wish—just remember to put them on the same LAN as Stinkpad (192.168.1.0/24), and make Stinkpad's LAN IP address their default gateway.
If you set two default gateways on a computer, you can select which one to delete, like this:
# route del default gw 192.168.1.25There can be only one default gateway. It's not necessary to have default gateways during testing, but you should on production machines.
It is possible to have a large number of routes, and to have your usual Internet connectivity if you configure everything correctly. Feel free to be as much of a routing guru as you like; I prefer to keep it as simple as possible for easier debugging. That is why the default routes are deleted, so they aren't hanging around to confuse you. If you have other routes that do not pertain to testing OpenVPN, get rid of them, too.
Stinkpad (the remote PC), must connect directly to the router, Xena, because different broadcast domains need routing between them. (Or bridging, which we'll get to later.)