当我连接到多个 VPN 连接时，我丢失了（第一个连接的 VPN 的）路由。
设置
2 strongSwan servers
- local_ts: 10.0.64.0/20
- local_ts: 10.0.80.0/20
1 osx client
连接前的路由表
# netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 82 0 en0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 17 8937650 lo0
169.254 link#8 UCS 0 0 en0
192.168.0 link#8 UCS 4 0 en0
192.168.0.1/32 link#8 UCS 1 0 en0
192.168.0.1 40:d:10:73:1f:90 UHLWIir 24 120 en0 1177
192.168.0.10 f4:5f:d4:fb:24:4a UHLWI 0 185 en0 925
192.168.0.23 dc:a9:4:2a:21:db UHLWI 0 1 en0 714
192.168.0.31/32 link#8 UCS 0 0 en0
192.168.0.32 0:6d:52:13:65:63 UHLWIi 1 37 en0 73
192.168.0.33 link#8 UHLWI 0 1 en0
224.0.0/4 link#8 UmCS 2 0 en0
224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 104 en0
255.255.255.255/32 link#8 UCS 0 0 en0
连接到 10.0.64/20 VPN 服务器
# netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 88 0 en0
default link#13 UCSI 0 0 ipsec0
10.0.64/20 172.31.0.1 UGSc 0 0 ipsec0
18.130.230.56 192.168.0.1 UGHS 0 0 en0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 31 8937992 lo0
169.254 link#8 UCS 0 0 en0
172.31.0.1 172.31.0.1 UH 1 0 ipsec0
192.168.0 link#8 UCS 4 0 en0
192.168.0.1/32 link#8 UCS 1 0 en0
192.168.0.1 40:d:10:73:1f:90 UHLWIir 34 128 en0 1162
192.168.0.10 f4:5f:d4:fb:24:4a UHLWI 0 197 en0 872
192.168.0.23 dc:a9:4:2a:21:db UHLWI 0 1 en0 661
192.168.0.31/32 link#8 UCS 0 0 en0
192.168.0.32 0:6d:52:13:65:63 UHLWIi 1 38 en0 20
192.168.0.33 link#8 UHLWI 0 1 en0
224.0.0/4 link#8 UmCS 2 0 en0
224.0.0/4 link#13 UmCSI 1 0 ipsec0
224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 113 en0
239.255.255.250 link#13 UHmW3I 0 4 ipsec0 8
255.255.255.255/32 link#8 UCS 0 0 en0
255.255.255.255/32 link#13 UCSI 0 0 ipsec0
连接到 10.0.80/20 VPN 服务器（第一个仍然连接） - 路由 10.0.64/20 消失了！
# netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 81 0 en0
default link#15 UCSI 0 0 ipsec1
10.0.80/20 172.31.1.1 UGSc 0 0 ipsec1
18.130.140.63 192.168.0.1 UGHS 0 0 en0
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 25 8938255 lo0
169.254 link#8 UCS 0 0 en0
172.31.0.1 172.31.0.1 UH 0 0 ipsec0
172.31.1.1 172.31.1.1 UH 1 0 ipsec1
192.168.0 link#8 UCS 3 0 en0
192.168.0.1/32 link#8 UCS 1 0 en0
192.168.0.1 40:d:10:73:1f:90 UHLWIir 28 148 en0 1190
192.168.0.10 f4:5f:d4:fb:24:4a UHLWI 0 203 en0 1190
192.168.0.23 dc:a9:4:2a:21:db UHLWI 0 1 en0 573
192.168.0.31/32 link#8 UCS 0 0 en0
192.168.0.32 0:6d:52:13:65:63 UHLWIi 1 40 en0 1186
224.0.0/4 link#8 UmCS 2 0 en0
224.0.0/4 link#15 UmCSI 1 0 ipsec1
224.0.0.251 1:0:5e:0:0:fb UHmLWI 0 0 en0
239.255.255.250 1:0:5e:7f:ff:fa UHmLWI 0 118 en0
239.255.255.250 link#15 UHmW3I 0 1 ipsec1 10
255.255.255.255/32 link#8 UCS 0 0 en0
255.255.255.255/32 link#15 UCSI 0 0 ipsec1
既然 VPN 服务器位于不同的 CIDR 中，为什么会发生这种情况？
如果我之后手动添加到 10.0.64/20 的路由，我就可以访问任一网络。
答案1
VPN 客户端显然正在相互竞争，争夺路由表。
他们还对路由和默认网关进行了修改，显然最后加载的网关具有修改第一个创建的路由的优势。
最后，在最后一个 VPN 客户端加载后，缺少路由/不同的通信路径可能会混淆第一个 VPN 客户端的协商时间/保活计时器。 （这本身也可以解释路线的消失）。
正如您所发现的，在同一个客户端中同时运行多个 VPN 客户端并不完全是正确的，如果他们正在实施完整的隧道 VPN，则更多。
您可能必须尝试同时运行它们的机会之一是，在它们完成后您会弄乱路由表。然而，如果可以的话，它可能必须编写脚本，因为你的时间很短。
恐怕您在问题中描述的症状是简单的标准行为。
附言。我正在搞乱 Linux 中 Ckeckpoint 客户端的路由，从经验和理论知识来看，我知道在客户端/防火墙决定连接已损坏之前我的时间确实有限。