☰

仍然 vpn 描述“分配资源。VPN 隧道将很快启动。”

tag-icon • tag-icon vpn google-cloud-platform google-cloud-vpn
仍然 vpn 描述“分配资源。VPN 隧道将很快启动。”

从本地 Linux，我尝试检查 vpn 状态。

为什么detailedStatus没有继续？为什么状态仍然是“FIRST_HANDSHAKE”？

共享密钥和TargetIP没有错误。

$ gcloud compute vpn-tunnels describe gvis-vpn-tunnel

回声就在这里。

 creationTimestamp: '2020-07-28T15:05:44.541-07:00'

 description: ''

 detailedStatus: Allocating resources. VPN tunnel will start soon.

 id:'2892217179569987543'

 ikeVersion: 2

 kind: compute#vpnTunnel
 
 :

 region: https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-east1

 : 

 sharedSecret: '*************'

 : 

 status: FIRST_HANDSHAKE

 targetVpnGateway: https://www.googleapis.com/compute/v1/projects/[project-id]/regions/us-east1/targetVpnGateways/gvis-vpn

更新

上周，我可以连接 VPN 隧道。从本周一开始，无法连接，并且我看到以下日志：

2020-07-28T22:45:04.831987016Z  initiating IKE_SA vpn_58.xxx.xxx.xxx[779] to 58.xxx.xxx.xxx
2020-07-28T22:45:04.758749637Z  creating acquire job for policy with reqid {1}
2020-07-28T22:45:02.148478373Z  sending packet: from 35.xxx.xxx.xxx[4500] to 58.xxx.xxx.xxx[4500] (80 bytes)
2020-07-28T22:45:02.148478373Z  generating INFORMATIONAL request 2 [ N(AUTH_FAILED) ]
2020-07-28T22:45:02.148478373Z  tried 1 shared key for '35.xxx.xxx.xxx' - '58.xxx.xxx.xxx', but MAC mismatched
2020-07-28T22:45:02.148478373Z  parsed IKE_AUTH response 1 [ IDr AUTH N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]
2020-07-28T22:45:02.105535147Z  received packet: from 58.xxx.xxx.xxx[4500] to 35.xxx.xxx.xxx[4500] (256 bytes)
2020-07-28T22:45:02.029020541Z  sending packet: from 35.xxx.xxx.xxx[4500] to 58.xxx.xxx.xxx[4500] (336 bytes)
2020-07-28T22:45:02.029020541Z  generating IKE_AUTH request 1 [ IDi AUTH SA TSi TSr N(EAP_ONLY) ]
2020-07-28T22:45:02.029020541Z  establishing CHILD_SA vpn_58.xxx.xxx.xxx{1}
2020-07-28T22:45:02.029020541Z  authentication of '35.xxx.xxx.xxx' (myself) with pre-shared key
2020-07-28T22:45:02.029020541Z  remote host is behind NAT
2020-07-28T22:45:02.029020541Z  parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) ]
2020-07-28T22:45:01.933846400Z  received packet: from 58.xxx.xxx.xxx[500] to 35.xxx.xxx.xxx[500] (464 bytes)
2020-07-28T22:45:01.819625244Z  sending packet: from 35.xxx.xxx.xxx[500] to 58.xxx.xxx.xxx[500] (892 bytes)
2020-07-28T22:45:01.819625244Z  generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) ]

自 2019 年 12 月以来，预共享密钥一直相同。每天，当我想连接时，都会像这样建立 vpn 隧道，

 gcloud compute vpn-tunnels create [my-vpn-tunnel] \
     --peer-address 58.xxx.xxx.xxx \
     --ike-version 2 \
     --shared-secret [Pre-shared key] \
     --local-traffic-selector=192.xxx.100.0/24 \
     --remote-traffic-selector=172.xx.xx.0/24,192.xxx.10.0/24 \
     --target-vpn-gateway [my-vpn] \
     --region us-east1 \
     --project [project-id]

当我断开连接时，像这样删除 vpn-tunnel，

gcloud compute vpn-tunnels delete [my-vpn-tunnel] --region=us-east1

我一直在我的 Linux Shell 脚本上使用 gcloud。

答案1

由于您的问题已自行解决，因此我们只能猜测之前是什么原因导致了此问题。

正如我在评论中写道，最好遵循故障排除指南并从开始Cloud VPN 日志。

2020-07-28T22:45:02.148478373Z  tried 1 shared key for '35.xxx.xxx.xxx' - '58.xxx.xxx.xxx', but MAC mismatched

消息认证码 (MAC) 是根据预共享密钥和消息计算的，如果预共享密钥不匹配，则相应的 MAC 也不会匹配。同时，这看起来不像您的情况，因为您声称“预共享密钥自 2019 年 12 月以来一直相同”。

2020-07-28T22:45:02.029020541Z  remote host is behind NAT

因为你使用 NAT，我建议你看一下故障排除指南部分NAT 后面的本地网关：

Cloud VPN 可与 NAT 后面的本地或对等 VPN 网关配合使用。这是通过 UDP 封装和 NAT-T 实现的，并且仅支持一对一 NAT。

更多详细信息，请参阅本节：

Cloud VPN 仅支持通过 UDP 封装进行一对一 NAT，以实现 NAT 遍历 (NAT-T)。不支持一对多 NAT 和基于端口的地址转换。换句话说，Cloud VPN 无法连接到共享单个外部 IP 地址的多个对等 VPN 网关。

使用一对一 NAT 时，必须将对等 VPN 网关配置为使用外部 IP 地址（而不是其内部（专用）地址）来标识自己。配置 Cloud VPN 隧道以连接到对等 VPN 网关时，请指定外部 IP 地址。Cloud VPN 要求本地 VPN 网关使用其外部 IP 地址作为其身份。

该问题可能与您的内部路由器有关，但没有任何日志就很难说。

此外，下次您可以检查 Google 方面是否存在此问题Google Cloud 状态仪表板并提交问题报告在Google 问题追踪器。

相关内容