這是需要：
將靜態 1:1 NAT 後面的 Fortigate 裝置連接到 Internet 的 Google Cloud Platform (GCP) VPN 閘道。
簡化的 ASCII 圖：
LOCAL_LAN ---- Fortigate ----- Fiber modem ---- Internet ---- GCP VPN Gateway ----- GCP_VPC
光纖數據機正在對 Fortigate 執行 NAT 1:1，在此數據機上呼叫 DMZ 模式。
我遵循了幾條指示：
如何在 GCP 上建立到外部網關的 VPN - 我是用例#3，因為我在 Fortigate 上只有一個公用 IP https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn#gcloud_4
與 Fortinet 的互通性 - 我沒有 2 個靜態 IP，Fortigate 上的每個介面一個 https://cloud.google.com/community/tutorials/using-ha-vpn-with-fortigate
IKE v1 的結果：
第一階段已經協商好了，問題是第二階段從來沒有被提出來。 Google 的故障排除指南：
https://cloud.google.com/network-connectivity/docs/vpn/support/troubleshooting
說：您必須將對等 ID 定義為公用 IP 才能啟動隧道。
奇怪的是，我已經在 FortiGate Phase 1 localid 參數上定義了公用 IP，並且它被正確地傳送到 GCP VPN 閘道。
這是在 GCP 日誌上確認的事件，如下所示！
{
insertId: "5abgbbg2313tdw"
labels: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:14:46.610751733Z"
resource: {2}
severity: "DEBUG"
**textPayload: "IDir '201.110.XXX.240' does not match to '201.110.XXX.240'"**
timestamp: "2021-09-01T21:14:46.592461252Z"
}
但問題是階段 2 從未在 GCP 側進行協商，並且隧道被刪除。出於文件目的，以下是 Fortigate 的 ike 調試日誌的輸出：
ike 0:gcp00-0:10752: processed INITIAL-CONTACT
ike 0:gcp00-0: schedule auto-negotiate
ike 0:gcp00-0:10752: no pending Quick-Mode negotiations
[...]
ike 0:gcp00-0:10751: recv ISAKMP SA delete 14cb5d60541aaaaa/d405bbbbf6d06acb
然後，ISAKMP 斷開連線會在 GCP 日誌上進行比對：
{
insertId: "5abgbbg2313tdx"
labels: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:14:46.610751733Z"
resource: {2}
severity: "NOTICE"
textPayload: "deleting IKE_SA vpn_201.110.XXX.240[2662] between 35.242.XXX.165[35.242.XXX.165]...201.110.XXX.240[%any]"
timestamp: "2021-09-01T21:14:46.592502955Z"
}
協商會無限循環地維持在這個狀態。
使用 IKE v2 進行測試。
我也嘗試過IKE v2，結果非常相似。隧道永遠不會啟動，唯一的區別是在 FGT 端我無法將公共 IP 發送到 GCP VPN 網關。我嘗試修改 IKEv2 上的 localid、local-gw 和 eap 參數，但沒有成功。從 GPC 角度來看的日誌是 AUTHENTICATION_FAILED。 PSK 身份驗證已完成，但由於從未正確識別對等點，因此從未提出。如果我將 FGT 上的 local-gw 參數定義為 Fortigate 前面調變解調器的公共 IP，則協商本身根本無法完成。原因是：當在 FGT Phase1-interface gw 上設定此參數時，Fortigate 將使用 local-gw 定義的 IP 的 SOURCE IP 傳送封包。由於該 IP 對於調製解調器無效，因此封包永遠不會發送出去。
需要注意的是，我製作了 2 個隧道，一個在 ike v1 上，另一個在 ike v2 上進行測試。因此，以下隧道上的 IP 不同：以下是來自 GCP 控制台的證據日誌：
{
insertId: "134hqnjg23gnfib"
labels: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:52:39.566968571Z"
resource: {2}
severity: "DEBUG"
textPayload: "looking for peer configs matching 35.220.XXX.31[%any]...201.110.XXX.240[201.110.XXX.240]"
timestamp: "2021-09-01T21:52:39.552310603Z"
}
{
insertId: "134hqnjg23gnfia"
labels: {1}
logName: "projects/my-project-xxxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:52:39.566968571Z"
resource: {2}
severity: "DEBUG"
textPayload: "parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]"
timestamp: "2021-09-01T21:52:39.552287263Z"
}
問題
有人知道為什麼在 ike v1 上即使 IP 正確，GCP VPN 閘道也拒絕設定隧道（階段 2）？
有人知道在 Fortigate 上的第 1 階段定義上設定 IKE v2 IDi 或 IDr 的方法嗎？
以前有人看過這個問題嗎？有什麼建議麼？
答案1
好吧，回答我自己的問題。事情是這樣的：
在 FortiOS 7.0.1 上，當 ForiGate 作為 NAT 設備執行 1:1 NAT 時，沒有記錄或明確的方法以 GCP 接受設定的方式定義 FortiGate 上第一階段定義的 IDi 或 IDr隧道。
在 FGT 和 GCP VPN 閘道之間設定 VPN 隧道的唯一方法是 FortiGate 將公用 IP 直接指派給連接到 GCP VPN 的介面。
這樣，您可以將「本機網關」IP 定義到接口，即 FGT 第 1 階段定義上的公用 IP。至此，隧道協商完成，VPN 正常運作。
總之，當 FGT 位於 NAT 設備後方時，請勿嘗試設定 FGT 到 GCP VPN 隧道。根本行不通！
這是在 FortiOS 7.0.1 使用 IKE v2 連接到 GCP VPN 冗餘網關時進行的測試，其中 FortiGate 上有一個公共 IP，GCP VPN 端有兩個 IP。 IKE v1 未經測試。