複数の 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にパスを手動で追加すると、2つのネットワークのいずれかにアクセスできます。
答え1
VPNクライアントはルーティングテーブルを置いて互いに競合しているようです。
彼らはまたルーティングとデフォルトゲートウェイを変更し、明らかに最後にロードされたゲートウェイは最初に生成されたルートを変更するという利点がありました。
最後に、最後のVPNクライアントがロードされた後に失われたルーティング/他の通信経路が原因で、最初のVPNクライアントのネゴシエーション時間/接続維持タイマーが混乱する可能性があります。 （これ自体でもパスが消えたことを説明できます）。
見たように、同じクライアントで複数のVPNクライアントを同時に実行することは完全に正しくありません。
同時に実行しようとする機会の1つは、タスクが完了した後にルーティングテーブルを混乱させることです。しかし、時間が足りないので、可能であればスクリプトを書く必要があるかもしれません。
あなたの質問に説明されている症状は単に標準的な動作です。
PS。私はLinuxでCkeckpointクライアントへのルーティングをめちゃくちゃにしていますが、経験と理論的知識によって、クライアント/ファイアウォールが切断されたと判断するまでに時間が実際に制限されていることを知っています。