主页 / server / 问题 / 1027127
Accepted
Tsukasa Naritomi
Asked: 2020-07-29 14:43:35 +0800 CST

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

  • 772

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

为什么详细状态不进行？为什么状态仍然是“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-tunnel，

 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。

vpn google-cloud-platform google-cloud-vpn

1 个回答

  1. Best Answer

    因为您的问题自行解决了，所以我们只能猜测是什么导致了这个问题。

    正如我在评论中所写，最好遵循故障排除指南并从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-Traversal (NAT-T) 的一对一 NAT。不支持一对多 NAT 和基于端口的地址转换。换言之，Cloud VPN 无法连接到共享单个外部 IP 地址的多个对等 VPN 网关。

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

    此问题可能与您的本地路由器有关，但没有任何日志很难说。

    此外，下次您可以在Google Cloud Status Dashboard中检查 Google 方面是否存在此问题，并在Google Issue Tracker提交问题报告。

    • 0

相关问题