Run multiple openvpn clients simultaneously on a linux machine

Run multiple openvpn clients-linux Enterprise Application-Linux server application information on a Linux machine at the same time. The following is a detailed description. The server configuration is as follows:

Port 1194
Proto tcp
Dev tun
Ca/etc/openvpn/keys/ca. crt
Cert/etc/openvpn/keys/vpnserver. crt
Key/etc/openvpn/keys/vpnserver. key
Dh/etc/openvpn/keys/dh1024.pem
Server 172.16.0.0 255.255.255.0
Ifconfig-pool-persist ipp.txt
Push "route 172.16.0.0 255.255.255.0"
Client-config-dir/etc/openvpn/ccd
Client-to-client
Keepalive 10 120
Comp-lzo
User root
Group root
Persist-key
Persist-tun
Status openvpn-status.log
Verb 3


Certificate 1.crt 1. key and 2.crt 2.key are created for the client.

The client configuration is as follows (there are two certificates: 1. * and 2 .*)

Client
Dev tun
Proto tcp
Remote 10.0.0.2001194
Resolv-retry infinite
Nobind
User nobody
Group nobody
Persist-key
Persist-tun
Ca. crt
Cert 1.crt
Key 1.key
Comp-lzo
Verb 3

Run the two openvpn clients on the same linux server and connect them to the same openvpn server.

After it is started, both openvpn clients can start normally.

Run ifconfig. tun0 and tun1 are displayed.

The server is successfully pinged from the client (ping 172.16.0.1 ).

The two clients obtain the ip addresses 172.16.0.9 and 172.16.0.13 respectively.

Tun0: client: 172.16.0.9 <=> 172.16.0.10 server: 172.16.0.1

Tun1: client 172.16.0.13 <=> 172.16.0.14 server: 172.16.0.1

Ping 172.16.0.9 from the vpn Server is successful. ping 172.16.0.13 fails.

(Later, we found that only 172.16.0.9 and 172.16.0.13 can have one connection. Which connection is the result depends on which rule is in front of the road table)

Cause of failure

The tunnel server ip addresses of both channels are 172.16.0.1.

Ping 172.16.0.1 through tun0, tun1 does not pass

Ping 172.16.0.9 from the server, the packet from the server to the client is from tun0, and going back is also going through tun0, normal

Ping 172.16.0.13 from the server, the packet from the server to the client is from tun1, and going back to tun0 is abnormal

To solve this problem:

Solution 1: Modify openvpn (2.0.9)

Multi. c (1634)

/* Make sure that source address is associated with this client */
Else if (multi_get_instance_by_virtual_addr (m, & src, true )! = M-> pending)
{
Msg (D_MULTI_DROPPED, "MULTI: bad source address from client [% s], packet dropped ",
Mroute_addr_print (& src, & gc ));
C-> c2.to _ tun. len = 0;
}
Comment out this section and recompile it. After the openvpn on the server is replaced, both channels are normal.

But this solution is not good.

1. The third-party tool has been modified and will be changed again in the future.

2. Other unpredictable problems may occur because no careful investigation has been conducted.

3. The same channel server is configured on different machines (tun0 connects to server0, tun1 connects to server1, but the two vpnservers have the same configuration ).

Solution 2: Change routing rules

Ip route add 172.16.0.0/8 via 172.16.0.10 table 2

Ip rule add from 172.16.0.9/32 to 172.16.0.0/8 table 2 pref 1500

Ip route add 172.16.0.0/8 via 172.16.0.14 table 3

Ip rule add from 172.16.0.13/32 to 172.16.0.0/8 table 3 pref 1500

Ip route flush cache

After the change, both channels can work normally.