Cloud VPN

簡介

Cloud VPN 透過 IPsec VPN 連線，安全地把你的對等網路（地端資料中心、分公司、或另一家雲端供應商）連到 Google Cloud 的 VPC 網路。流量由一個 VPN 閘道器加密，再由另一端的 VPN 閘道器解密，保護資料在公共網際網路傳輸過程中不被竊聽。Cloud VPN 是 Cloud Interconnect 之外較便宜、能快速佈建的替代方案，適合需要站點對站點加密、但能容忍單一隧道約 3 Gbps 頻寬上限與公共網際網路變動延遲的工作負載。在 Professional Cloud Network Engineer（PCNE）考試中，你必須了解 HA VPN 與 Classic VPN 的架構差異、Google 支援的加密參數（AES-256-GCM、SHA-256、IKEv2），以及如何透過 Cloud Router 的 BGP 達成動態故障切換。

Google 提供兩種 Cloud VPN：HA VPN（現代化、推薦使用、提供 99.99% 閘道器 SLA）與 Classic VPN（舊版、單一介面、99.9% SLA、許多情境已逐步淘汰）。PCNE 題目高度偏向 HA VPN，因為它是唯一能達成企業級 SLA 的選項，也是唯一能與 Network Connectivity Center spoke 拓撲相容的 VPN。

HA VPN：99.99% SLA 的架構

HA VPN 在 Google Cloud 是一個區域型資源，對外提供 兩個外部 IPv4 介面（interface 0 與 interface 1），每個介面分別位於同一 region 內、不同可用區的 Google 代管叢集上。要達成 99.99% SLA，你必須從 HA VPN 閘道器建立 兩條隧道，並終結於：(a) 兩台對等 VPN 裝置，或 (b) 一台具兩個介面（active/active 或 active/standby）的對等裝置，並在兩條隧道上都建立 BGP session。

閘道器資源模型

gcloud compute vpn-gateways create 指令會佈建 HA VPN 閘道器並立即配發兩個外部 IP。你無法自選 IP — Google 從自家位址池配發。每個介面的 IP 在閘道器生命週期內固定不變，這點很重要，因為你的地端防火牆必須允許 IKE 與 ESP 來自這兩個確切的位址。

雙隧道拓撲

支援的 HA VPN 拓撲是 interface 0 → 對等裝置 A，tunnel 1 與 interface 1 → 對等裝置 B，tunnel 2。如果你只從一個介面建一條隧道，就退回 99.9% SLA（單隧道）。如果建四條隧道（每個介面兩條）在跨雲拓撲中是合法的，但不會提升 SLA — 只是透過 ECMP 增加頻寬。

BGP 強制要求

HA VPN 僅支援透過 BGP 的動態路由；靜態路由在建立隧道時就會被拒絕。每條隧道執行自己的 BGP session，使用一個 /30 的 link-local 子網（例如 169.254.0.0/30）。GCP 端的 Cloud Router 通告 VPC 子網，對等路由器通告地端前綴。BGP 的 MED 與 AS-path prepending 可讓你在兩條隧道間操控流量，達成 active/active 或 active/passive 行為。

Classic VPN：舊版行為與限制

Classic VPN（資源類型 targetVpnGateway）是原始的 Cloud VPN 產品。它在單一閘道器上對外提供 單一外部 IP，支援靜態路由（policy-based 或 route-based）或基於 BGP 的動態路由。最高 SLA 為 99.9%，Google 已宣布在多數 region 限制建立新的 IPv4 BGP-based Classic VPN 閘道器，鼓勵改用 HA VPN。既有的 Classic VPN 閘道器仍可繼續運作。

Policy-based 與 Route-based 比較

Policy-based VPN 以 IKE 的 traffic selector（左/右子網）比對流量。對等端的 selector 必須完全鏡像 GCP 端的 selector；任何不一致都會導致 Phase 2 失敗並回報 TS_UNACCEPTABLE。當地端子網變動時，policy-based 非常脆弱。

Route-based VPN（Classic 搭配靜態路由）以 0.0.0.0/0 作為協商的 selector，並使用 VPC 路由把流量導入隧道。比 policy-based 彈性，但仍是靜態 — 對等裝置掛掉時不會自動故障切換。

何時 Classic VPN 仍可接受

• Lab 或概念驗證環境，99.9% 已足夠
• 真的不支援 BGP 的對等裝置（2026 年已罕見）
• 既有隧道的就地遷移 — 除非情境明確要求 99.99% SLA，否則無需為考試重建

IPsec IKEv2 與支援的加密套件

Cloud VPN 支援 IKEv2（RFC 7296）與 IKEv1（legacy）。Google 強烈建議新部署採用 IKEv2，因為它支援現代化 AEAD 加密、MOBIKE（端點移動性），重新換鑰也更有效率。

Phase 1（IKE SA）加密套件

Cloud VPN 在 IKE 協商時會提出一組精選的 Phase 1 演算法。常見組合包含：

• 加密： AES-CBC-256、AES-GCM-256、AES-GCM-128
• 完整性（PRF）： HMAC-SHA2-256、HMAC-SHA2-384、HMAC-SHA2-512
• DH Group： Group 14（2048-bit MODP）、Group 19/20（ECP）、Group 24

Phase 2（Child SA / ESP）加密套件

Phase 2 保護實際在隧道內流動的資料：

• AES-256-GCM（AEAD — 推薦；同時處理加密與驗證）
• AES-256-CBC 搭配 HMAC-SHA2-256
• AES-128-GCM 用於 CPU 較弱的對等裝置

Pre-Shared Key（PSK）

Cloud VPN 使用 PSK 驗證 — 不支援憑證式 IKE。共用秘密存於隧道資源中，至少應為 32 個隨機字元。輪替 PSK 的方式是建立一條新隧道（使用新秘密）並拆掉舊隧道（無法就地修改 PSK）。

透過 Cloud Router 的 BGP 動態路由

Cloud Router 是每個 HA VPN 部署在 GCP 端的 BGP speaker。它是代管的區域型服務，不需要你佈建任何 VM 即可執行 BGP。

ASN 配置

你需替 Cloud Router 設定一個 私有 ASN，範圍為 64512–65534（16 位元私有）或 4200000000–4294967294（32 位元私有）。若你擁有公開 ASN，也可使用。對等端的 ASN 是你的地端路由器所用的編號；兩個 ASN 在 HA VPN 中必須不同（eBGP）。Google 保留給 VPN peering 的 ASN 是 16550（用於 Partner Interconnect，非 VPN）。

BGP Session 建立

每條隧道分配一個 /30 的 link-local IPv4 範圍。Cloud Router 拿 .1，對等端拿 .2。隧道起來後，Cloud Router 對對等端開啟 TCP 179 並交換 OPEN 訊息。session 成功時，gcloud compute routers get-status 會顯示 BGP state = Established。

路由通告模式

• 預設模式： Cloud Router 通告該 region 內所有 VPC 子網（若動態路由模式為 GLOBAL 則通告全域）。
• 自訂模式： 你以 --advertisement-ranges 明確列出要洩漏給對等端的前綴。

Active/Passive 與 Active/Active

預設 BGP 行為在兩條隧道上呈現 equal-cost 路由，產生 active/active ECMP — 流量會 hash 到兩條隧道，達到約 2 倍頻寬。要強制 active/passive，在備援隧道上做 AS-path prepend（例如主路徑用 --advertised-route-priority=100、備援用 200，再搭配 MED 調整）。

Traffic Selectors 與子網協商

Traffic selector 定義哪些來源/目的前綴可以進入隧道，在 IKE Phase 2 中協商。

HA VPN 的 Traffic Selector

HA VPN 隧道 永遠以 0.0.0.0/0 ↔ 0.0.0.0/0 作為協商的 selector（等於「route-based」）。實際的路由決策發生在 VPC 路由表與 BGP 層 — 不在 IKE。這大幅簡化協商，也代表你在 HA VPN 上永遠不會看到 Phase 2 selector 不一致的問題。

Classic VPN 的 Policy-based Selector

Classic policy-based VPN 允許你指定左右兩側的 CIDR（--local-traffic-selector、--remote-traffic-selector）。對等端必須提出完全鏡像的提案 — 差一個 octet 就會出現 INVALID_SELECTORS，隧道無法建立。

Selector 最佳實踐

任何新建環境，請優先選擇 HA VPN + BGP。若必須使用 Classic policy-based VPN（例如舊防火牆廠商不支援 BGP），請把 selector 設得越寬越好（10.0.0.0/8 ↔ 10.0.0.0/8），避免每次新增子網都要重新協商。

MTU、分片、與效能調校

IPsec 會加上 ESP 標頭、trailer、IV 與 ICV 等額外負擔，會縮減有效負載 MTU。MTU 設錯會造成靜默封包丟棄、分片黑洞、TCP 吞吐崩盤。

Cloud VPN MTU 預設值

• Cloud VPN 隧道 MTU： 1460 bytes（IPv4）
• Cloud VPN 隧道 MTU（IPv6 underlay）： 最少 1280 bytes
• VPC 預設 MTU： 1460 bytes（或 1500 / 8896 若你啟用 jumbo）

TCP MSS Clamping

VPC 端，GCP 會自動把 TCP MSS 夾到 MTU − 40（預設 MTU 下為 1420）。對等端則需在隧道介面設定 ip tcp adjust-mss 1380（或類似指令），讓 TCP 三向交握協商出能塞進 ESP 開銷後 IPsec 負載的 MSS。

Don't Fragment（DF）位元處理

Cloud VPN 會遵守 DF 位元。若一個 1500-byte 且設了 DF 的封包打到隧道，Cloud VPN 會回 ICMP「fragmentation needed」（type 3 code 4）給來源端並丟棄封包。某些地端防火牆會封鎖 ICMP，造成 PMTUD 黑洞 — 在特定 payload 大小下 TCP 連線會卡死。對策：積極夾 MSS，並確保 ICMP type 3 全程通行。

VPN 隧道監控與運維

Cloud VPN 為閘道器與隧道分別匯出第一級的 Cloud Monitoring 指標。

關鍵指標

• vpn.googleapis.com/tunnel_established — gauge，1 = up、0 = down
• vpn.googleapis.com/network/sent_bytes_count 與 received_bytes_count — 每條隧道吞吐量
• vpn.googleapis.com/network/dropped_sent_packets_count — 因 MTU 或加密錯誤而丟棄的封包
• router.googleapis.com/bgp/session_up — 每個對等端的 BGP session 狀態

日誌

Cloud VPN 不會發送每包日誌（那是 VPC Flow Logs 的職責），但閘道器資源會把 IKE 協商事件寫入 Cloud Logging，篩選 resource.type="vpn_gateway"。以 jsonPayload.event_type 過濾失敗事件，例如 IKE_AUTH_FAILED、DH_GROUP_MISMATCH、LIFETIME_MISMATCH。

告警樣式

production 的告警政策應在 任一隧道中斷超過 60 秒、或 任一 BGP session 掉線時觸發。不要只在「兩條隧道都掉」才告警 — 那時你的 SLA 早已破。

gcloud 運維指令

gcloud compute vpn-tunnels list --region=us-central1
gcloud compute vpn-tunnels describe my-tunnel --region=us-central1
gcloud compute routers get-status my-router --region=us-central1

get-status 輸出包含每個對等端的 BGP 狀態、已通告/已收到的路由數、運作時間。

跨雲與多區域拓撲

HA VPN 的雙介面設計，是跨雲與多區域混合拓撲的自然選擇。

GCP 對 AWS

HA VPN 搭配 AWS Virtual Private Gateway（VGW） 或 Transit Gateway（TGW）。AWS VGW 每條 VPN connection 對外暴露兩個 public IP — 完美對應 HA VPN 的兩個介面。將 interface 0 接 AWS tunnel-A、interface 1 接 AWS tunnel-B，兩條都跑 BGP。ASN：GCP 一般用 65001、AWS VGW 預設 64512。

GCP 對 Azure

Azure VPN Gateway 在 active-active 模式下也會暴露兩個 public IP。模式相同：交叉連線。注意 Azure 的 BGP timer 預設 60 秒 hold / 20 秒 keepalive — Cloud Router 要設成相同值，否則會 flapping。

GCP 對 GCP（跨區域）

位於不同 region 的兩個 HA VPN 閘道器可以互相 peer，建立 region 對 region 的加密骨幹，適用於 VPC Network Peering 不具傳遞性造成問題的情境。每個閘道器看到對方的兩個 IP，建立四條隧道（full mesh）。

頻寬、配額與擴展

每條 VPN 隧道都受 Google 限速。

每隧道吞吐

• 單隧道上限： 約 3 Gbps 合計（ingress + egress 加總），依封包大小與加密選擇而變動
• AES-GCM 比 AES-CBC + HMAC-SHA 快，因為 AEAD 演算法能更有效率使用 CPU AES-NI
• 小封包（64-byte）因每包開銷高，吞吐被壓到數百 Mbps

超過 3 Gbps 的擴展

使用 多隧道 ECMP — 在單一 HA VPN 閘道器建立 4 條隧道（每介面 2 條），用 BGP 分流，可達約 12 Gbps 合計。再上去就要改用 Cloud Interconnect（Dedicated 10/100 Gbps 或 Partner Interconnect 50 Mbps–50 Gbps），雖然 L2 不加密，但走的是私有光纖。

配額

• 每 region VPN 閘道器： 15（soft，可申請提高）
• 每閘道器隧道： 8
• 每 Cloud Router BGP 對等端： 8
• 每 BGP session 通告路由： 100（自訂通告）

安全強化

除了加密套件選擇，還有幾個旋鈕可進一步強化 Cloud VPN。

IKE Lifetime

Cloud VPN 預設 IKE SA 為 36000 秒（10 小時）、Child SA 為 10800 秒（3 小時）。更短的 lifetime 代表更頻繁的 re-key — 成本更高但 PFS 更強。與對等端設定要完全一致，否則會週期性出現 1 秒的閃斷。

Perfect Forward Secrecy（PFS）

PFS 在 Cloud VPN 預設啟用（透過 Phase 2 的 DH group 協商）。請務必確認對等端也啟用 PFS — 若無 PFS，PSK 一旦外洩，所有歷史流量都會被解密。

Dead Peer Detection（DPD）

Cloud VPN 每 10 秒送一次 DPD 探測，連續 3 次未收到回應（約 30 秒）後拆掉隧道。這正是觸發 BGP 故障切換的機制。對等裝置應設成相同數值。

防火牆規則

GCP 端，你不需要在 VPN 閘道器自身設定 ingress 防火牆規則（它是 Google 代管資源）。但接收 VPN 隧道流量的 VM 看到的來源 IP 是地端範圍 — 你需要 VPC 防火牆規則允許那段流量。用 網路標籤 或 服務帳號 精準縮限規則範圍。

白話文解釋（Plain English Explanation）

譬喻一：外交郵袋

想像兩個大使館位於敵意城市的兩端。他們需要交換文件，但城市的郵政系統會偷看每一封信。所以每個大使館配發一個 外交郵袋（IPsec 隧道），上面有可見封籤（HMAC-SHA256）和一把只有收件大使館能開的鎖（AES-256-GCM）。HA VPN 等於有 兩個郵袋，分別由兩位信差走兩條不同路線運送 — 即使一位信差塞車（一條隧道掉了），另一位仍能送達，達成 99.99% 的準時送達率。

譬喻二：雙線熱線電話

IKE Phase 1 像是兩位外交官各自拿起加密電話、用共用密語（PSK）互相驗證身分。彼此信任後，他們再協商出 第二條更快的線路專門講正事 — 那就是 Phase 2（Child SA），承載以 AES-256-GCM 加密的業務對談。透過 Cloud Router 的 BGP 則像是第三條線，兩邊大使館的總機持續八卦哪條街道現在通（「今天到 10.0.0.0/16 要這樣走」） — 路徑變動時，兩端自動適應，不需要人工改寫通訊錄。

譬喻三：貨櫃船與報關貼紙

一個普通封包像 1500 磅的貨櫃。IPsec 加上一張很重的 報關貼紙（ESP 標頭 + IV + ICV），重約 40 磅。如果你硬塞一個滿 1500 磅的貨櫃進一個只允許 1460 磅總載重（MTU）的隧道，碼頭工人要嘛拒收（drop），要嘛把貨櫃鋸成兩半（fragment）。修正辦法是 MSS clamping — 告訴寄件人「貨櫃別超過 1420 磅，這樣貼紙還塞得下」。當對等端防火牆把「貨櫃太大」的 ICMP 訊息退回給寄件人也封鎖時，你就遇到 PMTUD 黑洞 — 寄件人一直送 1500 磅貨櫃，但什麼也送不出去。

常見問題（FAQs）

HA VPN 能搭配不會說 BGP 的對等裝置嗎？

不行。HA VPN 強制使用 BGP。如果你的對等裝置只支援靜態路由，有兩條路：(1) 在它前面部署一台支援 BGP 的小裝置（例如跑 FRR 或 BIRD 的 Linux VM），或 (2) 退回 Classic VPN 加靜態路由 — 但會失去 99.99% SLA，也無法當作 Network Connectivity Center 的 spoke。

要怎麼不中斷地輪替 pre-shared key？

PSK 在隧道資源上不可修改。輪替方式是：在不同的 /30 BGP 子網上建立 第二條隧道（用新 PSK），確認 BGP 起來、路由有交換後，用 AS-path prepend 把流量從舊隧道引流走，最後刪除舊隧道。兩條同時保留至少 5 分鐘，避免 flow 中斷。

為什麼我的 HA VPN 隧道一直停在 "First Handshake"？

通常是 Phase 1 加密套件不一致。執行 gcloud compute vpn-tunnels describe 看 detailedStatus。最常見原因：對等端提出 IKEv1 但 GCP 期望 IKEv2、DH group 不一致（對等端用 Group 5，GCP 要求 Group 14 以上）、或 PSK 打錯。把對等裝置 IKE 日誌與 Cloud Logging 紀錄並排比對。

Cloud VPN 的流量可以不走公共網際網路嗎？

Cloud VPN 閘道器 IP 是公開的，但加密後的 ESP 封包可透過 HA VPN over Interconnect 拓撲走 Cloud Interconnect。這提供加密、私有光纖的傳輸 — 適合那些即使在私有電路上也強制要求 encryption-in-transit 的合規要求。

Cloud VPN 支援 IPv6 嗎？

支援。HA VPN 支援 雙堆疊 隧道 — IPv4 外層搭配 IPv6 內層，或純 IPv4 內層。純 IPv6 外層目前尚未支援。設定方式是在 BGP session 上加上 --ip-version=IPV6，並確認對等端支援 IPv6 BGP address-family 協商（RFC 4760 multiprotocol extensions）。

HA VPN over Interconnect 與一般 HA VPN 的差別？

一般 HA VPN 把加密流量送上公共網際網路。HA VPN over Interconnect 則以你的 Dedicated 或 Partner Interconnect 線路作為 underlay — 所以封包是以加密方式在私有光纖上行進。仍享有 IPsec 加密（Interconnect 本身不提供加密），再加上私有路徑的可預期延遲。這是 GCP 混合連線最高階的方案。

99.99% SLA 也涵蓋對等端嗎？

不。Google 的 SLA 只涵蓋 Google 代管的 HA VPN 閘道器 — 它的兩個介面、IPsec 終結、以及 Cloud Router 上的 BGP speaker。你的對等裝置可用性、地端機房電力、以及對等端到 Google 之間的網際網路路徑都 不在涵蓋範圍。要達成端到端 99.99%，你必須在自己這側也設計冗餘（兩台對等路由器、雙 ISP 等等）。