在一台linux机器上同时运行多个openvpn客户端

服务端配置，如下

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


为客户端制作了证书1.crt 1.key和2.crt 2.key

客户端配置如下(有两份,证书文件分别为1.*和2.*)

client
dev tun
proto tcp
remote 10.0.0.200 1194
resolv-retry infinite
nobind
user nobody
group nobody
persist-key
persist-tun
ca ca.crt
cert 1.crt
key 1.key
comp-lzo
verb 3

在同一台linux上运行这两个个openvpn客户端 ，都连接同一个openvpn服务端

启动之后，两个openvpn客户端都能正常启动

运行ifconfig，可以看到tun0和tun1

从客户端ping服务端( ping 172.16.0.1 ) 成功

这两个客户端分别获得ip　172.16.0.9 和 172.16.0.13

       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

从vpn服务端ping 172.16.0.9 成功，ping 172.16.0.13 不通

(后来发现，实际是172.16.0.9和172.16.0.13只能有一个通，至于是哪一个通，取决于路有表里谁的规则靠前)

检查不通的原因

两个通道的tunnel服务器的ip都是172.16.0.1

ping 172.16.0.1，是通过tun0，tun1不会通过

从服务端ping 172.16.0.9，从服务器到客户端的包是从tun0过来，回去也是走tun0，正常

从服务端ping 172.16.0.13，从服务器到客户端的包是从tun1过来，回去是走tun0，不正常

为了解决这个问题：

方案１：改造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;
  }
注释掉这一段，重新编译，替换服务端的openvpn后，发现两个通道都正常

但是这个解决方案不太好

1.改造了第三方的工具，以后升级的时候还得再次改动

2.可能导致其他不可预知的问题，因为并没有通过仔细的调查研究

3.同样配置的通道服务端在不同的机器(就是tun0连接server0, tun1连接server1，但是两个vpnserver配置一样)上就会有问题

方案２：更改路由规则

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

更改后，两个通道均能正常