![Google Cloud Classic VPN 间歇性断开连接](https://linux22.com/image/766155/Google%20Cloud%20Classic%20VPN%20%E9%97%B4%E6%AD%87%E6%80%A7%E6%96%AD%E5%BC%80%E8%BF%9E%E6%8E%A5.png)
几周前,我们创建了 Google Cloud Classic VPN,并与其他本地网络创建了隧道,连接成功建立,我们能够访问他们的应用程序,但几个小时后,VPN 开始间歇性断开连接。我establishing IKE_SA failed, peer not responding
在日志中发现了错误。
当 VPN 断开时,VPN 隧道状态有时会是NO INCOMING PACKETS
。FIRST HANDSHAKE
我不知道发生了什么。
VPN 配置详细信息:
- 地区:
us-east1
- 路由类型:
Policy-based
- 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 将无法重新连接。