Routing: subnets on both sides_OpenVPN 2 Cookbook-QQ阅读中文历史网

上QQ阅读APP看书，第一时间看更新

Routing: subnets on both sides

This recipe will demonstrate how to set up server-side and client-side routing in client/server mode. With this setup, the OpenVPN client will be able to reach all machines behind the OpenVPN server and the server will be able to reach all machines behind the client.

Getting ready

We use the following network layout:

This recipe uses the PKI files created in the first recipe of this chapter. For this recipe, the server computer was running CentOS 5 Linux and OpenVPN 2.1.1 and the client was running Fedora 13 Linux and OpenVPN 2.1.1. Keep the server configuration file, basic-udp-server.conf, as well as the client configuration file, basic-udp-client.conf, from the recipe Server-side routing at hand.

How to do it...

Modify the server configuration file, basic-udp-server.conf, by adding the lines:
```
 client-config-dir /etc/openvpn/cookbook/clients
 route 192.168.4.0 255.255.255.0 192.168.200.1
```
Then save it as example2-5-server.conf.
Next, create the directory for the client configuration files:
```
 [root@server]# mkdir -m 755 /etc/openvpn/cookbook/clients
```
Place a file in this directory with the name of the client certificate as openvpnclient1 containing:
```
iroute 192.168.4.0 255.255.255.0
```
This name can be retrieved from the client certificate file using:
```
 $ openssl x509 -subject -noout -in client1.crt
    subject= /C=NL/O=Cookbook/CN=openvpnclient1/emailAddress=…
```

Start the server:

 [root@server]# openvpn --config example2-5-server.conf

Start the client:

 [root@client]# openvpn --config basic-udp-client.conf

After the VPN is established, we need to set up routing on both sides. Enable the IP traffic forwarding on the server:
```
 [root@server]# sysctl -w net.ipv4.ip_forward=1
```
Add a route to the LAN B's Gateway to point to the OpenVPN server itself:
```
 [siteB-gw]> ip route add 192.168.4.0/24 via 10.198.1.1
 [siteB-gw]> ip route add 192.168.200.0/24 via 10.198.1.1
```
Here, 10.198.1.1 is the LAN IP address of the OpenVPN server used in this recipe.

On the client side:

 [client]$ sysctl -w net.ipv4.ip_forward=1

And similarly, for the LAN A Gateway:

 [siteA-gw]> ip route add 10.198.0.0/16 via 192.168.4.5
 [siteA-gw]> ip route add 192.168.200.0/24 via 192.168.4.5

Here, 192.168.4.5 is the LAN IP address of the OpenVPN client used in this recipe.

Now, we verify that we can ping a machine on the remote server LAN:

[client]$ ping -c 2 10.198.0.10
     PING 10.198.0.10 (10.198.0.10) 56(84) bytes of data.
     64 bytes from 10.198.0.10: icmp_seq=1 ttl=63 time=31.1 ms
     64 bytes from 10.198.0.10: icmp_seq=2 ttl=63 time=30.0 ms

And vice versa:

 [server]$ ping -c 2 192.168.4.164
    PING 192.168.4.164 (192.168.4.164) 56(84) bytes of data.
    64 bytes from 192.168.4.164: icmp_seq=1 ttl=64 time=30.2 ms
    64 bytes from 192.168.4.164: icmp_seq=2 ttl=64 time=29.7 ms

How it works...

When a client connects to the server with its certificate and with the certificate's common name, openvpnclient1, the OpenVPN server reads the client configuration file (also known as a CCD file) in the client-config-dir directory. The following directive in this file tells the OpenVPN server that the subnet 192.168.4.0/24 is reachable through the client openvpnclient1:

iroute 192.168.4.0 255.255.255.0

This directive has nothing to do with a kernel routing table, and is only used internally by the OpenVPN server process.

The following server directive is used by OpenVPN to configure the routing table of the operating system so that all the traffic intended for the subnet 192.168.4.0/24 is forwarded to the interface with IP address 192.168.200.1, which is the VPN IP of the server:

route 192.168.4.0 255.255.255.0 192.168.200.1

With the appropriate routing set up on both ends, site-to-site routing is now possible.

There's more...

Masquerading

We could have used masquerading on both ends as well, but with multiple clients, it becomes very hard to keep track of the network traffic.

Client-to-client subnet routing

If another VPN client needs to reach the subnet 192.168.4.0/24 behind client openvpnclient1, the server configuration file needs to extended with the following:

push "route 192.168.4.0 255.255.255.0"

This instructs all clients that subnet 192.168.4.0/24 is reachable through the VPN tunnel, except for client openvpnclient1. The client openvpnclient1 itself is excluded due to the matching iroute entry.