服務端配置，如下
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
更改後，兩個通道均能正常