여러 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 클라이언트에 대한 라우팅을 엉망으로 만들고 있으며 경험과 이론적 지식을 통해 클라이언트/방화벽이 연결이 끊어졌다고 결정하기까지 시간이 실제로 제한되어 있다는 것을 알고 있습니다.