Strongswan VPN은 수동으로 핑하지 않으면 작동하지 않습니다.

Strongswan VPN은 수동으로 핑하지 않으면 작동하지 않습니다.

Google Cloud VPN과 통신하기 위해 네트워크에 Strongswan VPN을 성공적으로 설정했습니다.

때때로 우리는 밤새도록 잠시 동안 유휴 상태로 두었는데, 이때 문제가 발생합니다. Google에서 네트워크에 ping을 시도하면 작동하지 않고 패킷이 전송되지 않습니다. 우리 측에서 Google로 ping을 시도하면 작동하고, Google 측에서 차단된 ping이 정상적으로 작동하기 시작합니다.

StrongSwan은 우리 쪽에서 절전 모드로 들어가고 패킷이 수신될 때가 아니라 수동으로 핑할 때만 깨어나는 것 같습니다. 하지만 문서에서 이 문제를 해결하기 위한 옵션을 찾을 수 없습니다. 누군가 이 문제를 겪고 어떻게든 해결한 적이 있습니까?

편집: 우리 측에는 이 동작을 설명할 수 있는 방화벽이 없으며 Google 측에서는 방화벽을 통해 허용되는 IP 범위만 설정할 수 있으며 다른 것은 아무것도 설정할 수 없습니다. 그러나 Strongswan 서버와 통신하기 위해 자체 VPN 서비스를 사용하기 때문에 Strongswan 서버에서 오는 것일 가능성이 높습니다.

다음은 당사 측에서 문제가 발생하기 전에 반환된 ipsec 상태입니다.

net-net[72]: ESTABLISHED 113 minutes ago, 79.xxx.xxx.xxx[79.xxx.xxx.xxx]...146.xxx.xxx.xxx[146.xxx.xxx.xxx]     
net-net{255}:  INSTALLED, TUNNEL, reqid 24, ESP SPIs: c5xxxxxx 4exxxxxx     
net-net{255}:   192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20

ipsec statusall 이후에 반환되는 내용은 다음과 같습니다.

Status of IKE charon daemon (strongSwan 5.3.5, Linux 4.4.0-64-generic, x86_64):  
uptime: 22 days, since Feb 27 15:21:33 2017  
malloc: sbrk 2568192, mmap 0, used 370288, free 2197904  
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 11  
loaded plugins: charon aes agent attr connmark constraints dnskey fips-prf gcm md4 openssl pem pgp pkcs1 pkcs12 pkcs7 pkcs8 pubkey rc2 resolve revocation sshkey test-vectors x509 xcbc sha1 sha2 md5 gmp random nonce hmac stroke kernel-netlink socket-default updown

Listening IP addresses:  192.168.17.205  79.xxx.xxx.xxx
Connections:     
    net-net:  79.xxx.xxx.xxx...146.xxx.xxx.xxx  IKEv2, dpddelay=30s     
    net-net:   local:  [79.xxx.xxx.xxx] uses pre-shared key authentication     
    net-net:   remote: [146.xxx.xxx.xxx] uses pre-shared key authentication     
    net-net:   child:  192.168.17.0/24 192.168.0.0/24 === 10.132.0.0/20 TUNNEL, dpdaction=restart
Security Associations (1 up, 0 connecting):     
    net-net[72]: ESTABLISHED 2 hours ago, 79.xxx.xxx.xxx[79.xxx.xxx.xxx]...146.xxx.xxx.xxx[146.xxx.xxx.xxx]     
    net-net[72]: IKEv2 SPIs: 0fd4efxxxxxx 17ed000axxxxxx*, pre-shared key reauthentication in 108 minutes     
    net-net[72]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048     
    net-net{255}:  INSTALLED, TUNNEL, reqid 24, ESP SPIs: c5b822fe_i 4ed83bd8_o     
    net-net{255}:  AES_GCM_16_128, 3916 bytes_i (47 pkts, 1020s ago), 3956 bytes_o (47 pkts, 1020s ago), rekeying in 7 hours     
    net-net{255}:   192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20

및 ipsec.conf:

config setup

conn %default
        ikelifetime=24h
        keylife=8h
        rekeymargin=9m
        keyingtries=1
        authby=psk
        keyexchange=ikev2
        mobike=no
        esp=aes128gcm16-modp2048!
        dpdaction=restart
conn net-net
        left=79.xxx.xxx.xxx
        leftsubnet=192.168.17.0/24,192.168.0.0/24
        leftid=79.xxx.xxx.xxx
        leftfirewall=yes
        leftdns=xxx....
        right=146.xxx.xxx.xxx
        rightsubnet=10.132.0.0/20
        rightid=146.xxx.xxx.xxx
        auto=start

Google 측 로그에서 ping 테스트를 보낼 때 CHILD_SA를 다시 생성하라는 일부 요청을 보낸 것을 확인했습니다.

"creating rekey job for CHILD_SA ESP/0xxxxxxxxx/79.xxx.xxx.xxx"  
...

CHILD_SA가 SPI를 통해 설정되면 핑이 통과됩니다. ESP SPI 전후에는 변화가 없습니다. 또한 ipsec statusall에서 7시간 안에 키를 다시 입력하는 것을 볼 수 있습니다. 밤에 7시간 이상 활동이 없으면 문제인가요?

이것은 Charon 로그입니다:

Mar 22 07:56:43 vpn07 charon: 11[ENC] parsed CREATE_CHILD_SA request 223 [ N(REKEY_SA) SA No KE TSi TSr ]
Mar 22 07:56:43 vpn07 charon: 11[IKE] CHILD_SA net-net{255} established with SPIs c5b8xxxxxxx_o and TS 192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20
Mar 22 07:56:43 vpn07 charon: 11[ENC] generating CREATE_CHILD_SA response 223 [ SA No KE TSi TSr ]
Mar 22 07:56:43 vpn07 charon: 05[IKE] received DELETE for ESP CHILD_SA with SPI 7dd6xxxx
Mar 22 07:56:43 vpn07 charon: 05[IKE] closing CHILD_SA net-net{254} with SPIs ce7xxxx (95264 bytes) 7ddxxxxx (4885433 bytes) and TS 192.168.0.0/24 192.168.17.0/24 === 10.132.0.0/20
Mar 22 07:56:43 vpn07 charon: 05[IKE] sending DELETE for ESP CHILD_SA with SPI ce75xxxxx
Mar 22 07:56:43 vpn07 charon: 05[IKE] CHILD_SA closed

그리고 구글 로그:

D  sending DPD request 
D  CHILD_SA closed 
D  received DELETE for ESP CHILD_SA with SPI cexxxxx 
D  parsed INFORMATIONAL response 224 [ D ] 
D  received packet: from 79.xxx.xxx.xxx[500] to 146.xxx.xxx.xxx[500] (76 bytes) 
D  sending packet: from 146.xxx.xxx.xxx[500] to 79.xxx.xxx.xxx[500] (76 bytes) 
D  generating INFORMATIONAL request 224 [ D ] 
D  sending DELETE for ESP CHILD_SA with SPI 7dxxxxxx
I  closing CHILD_SA vpn_79.xxx.xxx.xxx{33} with SPIs 7dxxxxx (5073648 bytes) cexxxxxx (95264 bytes) and TS 10.132.0.0/20 === 192.168.0.0/24 192.168.17.0/24  
I  CHILD_SA vpn_79.xxx.xxx.xxx{34} established with SPIs 4exxxxxx c5xxxxxx and TS 10.132.0.0/20 === 192.168.0.0/24 192.168.17.0/24  
D  handling HA CHILD_SA vpn_79.xxx.xxx.xxx{34} 10.132.0.0/20  === 192.168.0.0/24 192.168.17.0/24  (segment in: 1*, out: 1*) 
D  parsed CREATE_CHILD_SA response 223 [ SA No KE TSi TSr ] 
D  received packet: from 79.xxx.xxx.xxx[500] to 146.xxx.xxx.xxx[500] (476 bytes) 
D  sending packet: from 146.xxx.xxx.xxx[500] to 79.xxx.xxx.xxx[500] (620 bytes) 
D  generating CREATE_CHILD_SA request 223 [ N(REKEY_SA) SA No KE TSi TSr ] 
I  establishing CHILD_SA vpn_79.xxx.xxx.xxx{1} 
D  creating rekey job for CHILD_SA ESP/0xxxxxxx/79.xxx.xxx.xxx 
D  parsed INFORMATIONAL response 222 [ ] 
D  received packet: from 79.xxx.xxx.xxx[500] to 146.xxx.xxx.xxx[500] (76 bytes) 
D  sending packet: from 146.xxx.xxx.xxx[500] to 79.xxx.xxx.xxx[500] (76 bytes) 
D  generating INFORMATIONAL request 222 [ ] 
D  sending DPD request 

답변1

Strongswan VPN 클라이언트가 방화벽 뒤에 있는 것 같습니다.네트워크 주소 변환장치는 일정 기간 동안 활동이 없으면 "연결됨"(여기서는 UDP일 수 있으며 "연결됨"이라는 용어는 좋은 선택이 아님) 연결을 끊습니다. 이 연결에 속하는 모든 수신 데이터는 유효하지 않은 것으로 간주되어 삭제됩니다(FW/NAT 장치 로그에 이에 대한 내용이 있을 수 있음). 나중에 내부에서 Google을 핑하면 연결이 다시 설정되고 방화벽/NAT 장치는 이제 수신 데이터를 다시 유효한 것으로 처리합니다.

해결책은 정기적인 데이터 흐름을 보장하여 방화벽/NAT 장치가 "연결"을 끊는 것을 방지하는 것입니다(분당 하나의 UDP 메시지이면 충분할 수 있음). Strongswan에 내장된 연결 유지 메커니즘을 검색하고 활성화하세요.

답변2

이 동작이 발생할 수 있는 또 다른 상황은 IPv6 패킷이 네트워크 계층에서 사용되는 경우입니다. 분명히 여기서는 그렇지 않습니다.

그러나 NAT 없이도 IPv6를 사용하더라도 똑같은 동작을 경험했습니다.

인터넷 라우터에는 공용 IPv6 주소를 사용하여 로컬 호스트에 대한 무제한 액세스를 방지하는 패킷 필터링 기능이 있습니다. IPv6를 통해 IPSec 터널을 사용할 때 두 터널 끝점이 올바른 보안 연결을 나타내더라도 라우터는 몇 분 동안 활동이 없으면 외부로부터의 패킷을 차단할 수 있습니다. 연결은 UDP를 통해 제어되지만 페이로드는 ESP를 통해 전송되기 때문입니다. 제어 채널은 키 재설정 또는 DPD(Dead Peer 감지)에 자주 사용되지만 전송 채널에서는 자동으로 유지될 수 있습니다. 이로 인해 인터넷 라우터는 전송 채널에 더 이상 트래픽이 없다고 가정합니다. 따라서 라우터는 추가로 들어오는 패킷을 차단합니다.

이 문제를 해결하려면 내부 호스트를 노출시켜야 합니다. 라우터에 패킷 필터링이 구성된 방식에 따라 호스트로 들어오는 ESP 트래픽을 허용하는 것만으로도 충분할 수 있습니다.

관련 정보