☰

Strongswan VPN 无法工作，除非手动 ping 出

tag-icon • tag-icon vpn google-cloud strongswan
Strongswan VPN 无法工作，除非手动 ping 出

我们已经在我们的网络上成功设置了一个 Strongswan VPN 来与 Google Cloud VPN 进行通信。

有时我们让它闲置一段时间，比如说一个晚上，这时问题就会出现。如果我尝试从 Google ping 我们的网络，它不起作用，不会传输任何数据包。如果我尝试从我们这边 ping 到 Google，它会起作用，然后 Google 那边被阻止的 ping 就会开始正常工作。

看起来 StrongSwan 在我们这边进入睡眠模式，只有当我手动 ping 出去时才会醒来，而不是在接收数据包时醒来。但我在文档中找不到任何选项来解决此问题，有人遇到此问题并以某种方式解决它吗？

编辑：我们这边没有防火墙可以解释这种行为，而在谷歌这边我们只能设置允许通过防火墙的IP范围，没有其他。但由于它使用他们自己的 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 建立，ping 就会通过。虽然ESP SPI前后没有变化。我还在 ipsec statusall 上看到 7 小时内重新生成密钥。难道是夜间超过7个小时没有活动的问题吗？

这是卡戎日志：

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 设备日志中可能有一行与此相关的内容）。稍后，当您从内部 ping Google 时，您的连接将重新建立，并且您的防火墙/NAT 设备现在再次将传入数据视为有效。

解决方案是通过确保定期数据流（每分钟一条 UDP 消息可能就足够了）来防止防火墙/NAT 设备断开“连接”。搜索 Strongswan 中内置的任何保持活动机制并激活它。

答案2

可能发生此行为的另一种情况是在网络层使用 IPv6 数据包时。显然这里的情况并非如此。

然而，即使不使用 NAT，但使用 IPv6，我也经历过完全相同的行为。

Internet 路由器具有数据包过滤功能，可防止对具有公共 IPv6 地址的本地主机进行不受限制的访问。当在 IPv6 上使用 IPSec 隧道时，路由器可能会在几分钟不活动后阻止来自外部的数据包，即使两个隧道端点都指示正确的安全关联。这是因为连接是通过 UDP 控制的，但有效负载是通过 ESP 传输的。虽然控制信道因密钥更新或 DPD（失效对等点检测）而经常使用，但它在传输信道上可能保持静默。这会导致 Internet 路由器假定传输通道上不再有流量。因此，路由器会阻止进一步传入的数据包。

为了解决这个问题，需要暴露内部主机。根据路由器上配置数据包过滤的功能，允许主机传入 ESP 流量就足够了。

相关内容