仍然是 vpn 描述“分配資源。VPN 隧道即將啟動。”

從本地 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。

因為您的問題自行解決了，所以我們只能猜測是什麼導致了這個問題。

正如我在評論中所寫，最好遵循故障排除指南並從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送出問題報告。

引用自：https://serverfault.com/questions/1027127