☰

Google Cloud Classic VPN 间歇性断开连接

tag-icon • tag-icon google-cloud-vpn
Google Cloud Classic VPN 间歇性断开连接

几周前，我们创建了 Google Cloud Classic VPN，并与其他本地网络创建了隧道，连接成功建立，我们能够访问他们的应用程序，但几个小时后，VPN 开始间歇性断开连接。我establishing IKE_SA failed, peer not responding在日志中发现了错误。

当 VPN 断开时，VPN 隧道状态有时会是NO INCOMING PACKETS。FIRST HANDSHAKE我不知道发生了什么。

VPN 配置详细信息：

  1. 地区：us-east1
  2. 路由类型：Policy-based
  3. IKE版本：IKEv2

日志：

1.  creating acquire job for policy with reqid {1}
2.  initiating IKE_SA vpn_BB.BBB.BBB.BBB[21328] to BB.BBB.BBB.BBB
3.  generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ]
4.  sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
5.  retransmit 1 of request with message ID 0 
6.  sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
7.  retransmit 2 of request with message ID 0
8.  sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
9.  creating acquire job for policy with reqid {1}
10. ignoring acquire, connection attempt pending
11. retransmit 3 of request with message ID 0
12. sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
13. retransmit 4 of request with message ID 0 
14. sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
15. retransmit 5 of request with message ID 0 
16. sending packet: from AA.AAA.AAA.AAA[500] to BB.BBB.BBB.BBB[500] (892 bytes)
17. creating acquire job for policy with reqid {1}
18. ignoring acquire, connection attempt pending
19. giving up after 5 retransmits
20. establishing IKE_SA failed, peer not responding

有人能解释一下发生了什么事吗？

请查看我的 GCP VPN 的最新日志

1.  peer didn't accept DH group MODP_2048, it requested MODP_1024
2.  remote host is behind NAT
3.  authentication of 'AA.AAA.AAA.AAA' (myself) with pre-shared key
4.  establishing CHILD_SA vpn_ BB.BBB.BBB.BBB
5.  generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr N(EAP_ONLY) ]
6.  parsed IKE_AUTH response 1 [ IDr AUTH N(CRASH_DET) SA TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) N(ADD_TS_POSS) ]
7.  authentication of ' BB.BBB.BBB.BBB' with pre-shared key successful
8.  IKE_SA vpn_ BB.BBB.BBB.BBB [21588] established between AA.AAA.AAA.AAA [AA.AAA.AAA.AAA]... BB.BBB.BBB.BBB [BB.BBB.BBB.BBB]
9.  scheduling rekeying in 35937s
10. maximum IKE_SA lifetime 36537s
11. received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
12. Remote traffic selectors narrowed for Child SA: vpn_ BB.BBB.BBB.BBB. Configured TS: [XX.XXX.X.X/24 YYY.YY.YYY.Y/24 ], negotiated TS:[XX.XXX.X.X/24 ]. Please verify configuration on the remote side
13. handling HA CHILD_SA vpn_ BB.BBB.BBB.BBB{66} ZZ.ZZZ.Z.Z/24 === XX.XXX.X.X/24 (segment in: 1, out: 1)
14. CHILD_SA vpn_68.112.246.185{66} established with SPIs 07ab7fec_i de049161_o and TS ZZ.ZZZ.Z.Z/24 === XX.XXX.X.X/24
15. sending DPD request

答案1

这个问题有解决方案吗？我遇到了类似的问题，GCP VPN 和客户在初次连接几天后断线。我发现让 VPN 重新上线的唯一方法是让客户重置他们的连接。

VPN 断开时的大致日志显示：

解析了 CREATE_CHILD_SA 请求 51 [ SA 编号 KE TSi TSr N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) ]

收到 ESP_TFC_PADDING_NOT_SUPPORTED，未使用 ESPv3 TFC 填充

警告：本地流量选择器已针对子 SA 缩小：vpn_###.###.###。已配置的 TS：[###.###.###/32]，已协商的 TS：[###.###.###/32[tcp/65001] ###.###.###/32 ]。请验证远程端的配置。

警告：远程流量选择器已针对子 SA 缩小：vpn_###.###.###.###。已配置的 TS：[###.###.###.###/32 ]，已协商的 TS：[###.###.###.###/32[tcp/60394] ###.###.###.###/32 ]。请验证远程端的配置。

处理 HA CHILD_SA vpn_###.###.###.###{4302} ###.###.###.###/32 === ###.###.###.###/32（段输入：1*，输出：1*）

生成 CREATE_CHILD_SA 响应 51 [ SA No KE TSi TSr ]

注意：记录上述消息后，接下来的 5 条消息会不断重复，直到客户端重置 vpn 连接。

发送数据包：从 ###.###.###.###[500] 到 ###.###.###.###[500] (476 字节)

正在发送 DPD 请求

生成 INFORMATIONAL_V1 请求 3569313833 [ HASH N(DPD) ]

已解析 INFORMATIONAL_V1 请求 1654888155 [ HASH N(DPD_ACK) ]

发送数据包：从###.###.###.###[500] 到###.###.###.###[500] (92字节)

接收数据包：从 ###.###.###.###[500] 到 ###.###.###.###[500] (92 字节)

编辑以添加：该问题已存在大约 3 年，直到客户对其防火墙进行了更新（我相信是固件），现在该问题每周都会发生一次，并且如果客户不弹出其 VPN 端，VPN 将无法重新连接。

相关内容