💡 先搞懂問題
虛構公司「青松物流」的工程師第一次在 Google Cloud 開了一台 VM 放訂單查詢網站。新專案預設帶了一個名叫 default 的網路，他直接用它，VM 也順手給了外部 IP。上線一週後，資安顧問指出幾件事：default 網路預先建好的規則把 SSH（TCP 22）與 RDP（TCP 3389）開給了 0.0.0.0/0，也就是整個網際網路；網站和資料庫的 VM 混在同一段位址裡；公司明年要在美國開客服中心，IP 規劃要先想好，免得以後接 VPN 撞號。
他有 AWS 的經驗，第一個念頭是「台灣一個 VPC、美國一個 VPC，再做對等互連」。第二個念頭是「SSH 太危險，加一條拒絕 22 的規則就好」。他之前為了測試方便，自己建過一條優先順序 1000、允許 SSH 來自 0.0.0.0/0 的規則；這次新增的拒絕規則填了優先順序 2000，結果 SSH 照樣連得進來。這兩個念頭都卡在同一件事：Google Cloud 的網路模型和另外兩家不太一樣。
先把名詞對齊。VPC 網路（Virtual Private Cloud network）是你在專案（project）裡擁有的私人網路，它是全域資源（global），本身沒有位址範圍，也不綁任何區域。位址範圍放在子網路（subnet）上，子網路是區域資源（regional）：建在某個區域（Region），例如 asia-east1（台灣），並涵蓋這個區域裡所有的可用區（Zone）。所以台灣和美國的子網路可以放在同一個 VPC，彼此用內部 IP 直接互通，流量走 Google 的骨幹網路。
流量過濾靠VPC 防火牆規則（VPC firewall rules）。每條規則屬於整個 VPC，而不是某個子網路或某張網卡；它有方向（輸入 ingress／輸出 egress）、優先順序（priority，0～65535，數字越小越先比）、動作（允許 allow／拒絕 deny）、目標（target）與來源或目的地範圍。目標決定這條規則套用到哪些 VM：整個網路的所有執行個體、帶某個網路標記（network tag）的執行個體，或使用某個服務帳戶（service account）的執行個體。新手最常卡的地方有四個：以為拒絕規則一定贏（其實要看優先順序，數字小的先決定）；以為同一個子網路裡的 VM 預設可以互連（其實沒有規則允許的輸入都會被擋）；以為要自己寫回應封包的規則（其實規則有狀態，回應自動放行）；以為 VPC 規則是唯一一層（其實機構或資料夾的階層式防火牆政策（hierarchical firewall policy）會先比對）。
生活比喻：跨縣市的連鎖社區
想像一家建設公司在全國經營一個「青松連鎖社區」。社區只有一個名字、一套管委會，但實際的房子分散在各縣市：台北一棟大樓、台中一棟大樓、高雄一棟大樓。每棟大樓各自分到一段門牌號碼，大樓有好幾層，住戶分布在不同樓層；不同縣市的住戶要互相拜訪，走的是社區自己的專用接駁道路，不用上公共道路。
社區管委會訂了一本統一的門禁守則，每一條都有編號：「第 100 條：192.0.2 開頭的車牌一律不准進」「第 1000 條：送貨到穿綠色背心的住戶家，走 443 號門可以進」……警衛從最小的編號往下核對，第一條對得上的守則就決定結果。守則還會寫明適用的人：全體住戶、穿某個顏色背心的住戶，或持某家公司識別證的住戶。守則最後印著兩條沒有編號的總則：「外人沒有守則允許就不准進」「住戶出門不攔」。訪客進門時登記過，離開時警衛不會再翻一次守則。比這本守則更優先的，是建設公司總部發下來的全國規定，每個社區都得先照它檢查。
這個比喻有幾個地方和實際不同。第一，社區的警衛站在大門口，VPC 防火牆規則卻是在每台 VM 的網卡旁分散執行，沒有一台集中的防火牆設備，所以同一個子網路裡的兩台 VM 互連，一樣要過規則；default 網路之所以內部互通，是因為它預先建了一條允許 10.128.0.0/9 的 default-allow-internal 規則，自己建的 VPC 沒有這條。第二，背心誰都能穿：能編輯 VM 的人就能改網路標記，等於自己換背心；服務帳戶則要有 IAM 權限才能指定給 VM，所以要求嚴謹的環境用服務帳戶當目標比較穩。第三，青松物流那條「優先順序 2000 拒絕 SSH」沒有用，是因為他自己建的允許規則是 1000，數字小的先決定；拒絕只有在優先順序相同時才勝過允許。第四，回應自動放行只對「已允許的連線」有效，而且有狀態追蹤：連線閒置太久（官方文件寫至少每 10 分鐘要有一個封包）追蹤就會失效。
🎮 互動實驗室一：防火牆規則比對模擬器
情境：青松物流的 VPC qingsong-vpc 裡有兩台 VM（見下方卡片）。選好來源、目的地、通訊協定與連接埠後按「送出封包」，畫面會依官方的預設評估順序逐層比對：先看機構的階層式防火牆政策，再看 VPC 防火牆規則，接著是網路防火牆政策（本情境沒有建立，會直接略過），最後是隱含動作。來源是 VM 時會先檢查它的輸出，目的地是 VM 時再檢查它的輸入。VPC 規則那一層會先篩掉方向或目標不符的規則，在符合的規則裡取優先順序數字最小的；同一個優先順序同時有允許與拒絕時，拒絕勝出。你可以直接改優先順序、刪除或新增規則，或切換成其他規則組合，目標是讓下方五個任務全部達成。
10.10.0.10、有外部 IP網路標記
web・服務帳戶 web-sa10.10.1.20、沒有外部 IP網路標記
db・服務帳戶 db-sa① 階層式防火牆政策：qingsong-org（機構層級）
屬於 Cloud NGFW，由資安團隊在機構或資料夾設定，比任何 VPC 規則都先評估。規則依優先順序比對，允許或拒絕就直接結束；goto_next 表示「交給下一層決定」，沒有規則符合時也等同 goto_next。
② VPC 防火牆規則：qingsong-vpc
只看方向與目標都符合的規則，再挑優先順序數字最小的那一條；同一優先順序拒絕勝過允許。優先順序欄位可以直接改（0～65535）。
③ 網路防火牆政策（全域、區域）
本情境沒有建立，評估時直接略過。實務上可以把規則集中在網路防火牆政策，一份政策關聯到多個 VPC。
④ 隱含動作
前面都沒有允許或拒絕時才會走到這裡，它不是可以刪除的規則。
🎮 互動實驗室二：子網路規劃計算器
左邊先選 VPC 的子網路建立模式。自訂模式下，每一列是一個子網路：填名稱、選區域、填主要 IPv4 範圍（CIDR）。計算器會算出每個子網路的位址總數、Google Cloud 保留的 4 個位址與可用數量，並檢查格式、大小（最小 /29）、禁用範圍，以及同一個 VPC 裡所有子網路不能重疊，不管它們是不是在同一個區域。也可以填入地端或要對等互連的網段，看會不會撞號。下方的「擴充試算」示範子網路只能擴大、不能縮小。切到自動模式，可以看到 Google Cloud 自動在每個區域建立的 /20 子網路。
一、VPC 與子網路
二、檢查結果
🛠️ 操作教學：建立 VPC、子網路、防火牆規則與 Cloud NAT
跟著 8 個步驟，在左邊的示意控制台替青松物流建立一個自訂模式 VPC、一個開啟私人 Google 存取的子網路、兩條防火牆規則（網站對外開放 HTTP／HTTPS、只讓 IAP 轉送 SSH），以及讓沒有外部 IP 的 VM 能連外的 Cloud Router 與 Cloud NAT。你填的名稱、區域、IP 範圍與規則會即時反映到右邊的 gcloud CLI 與 Terraform；目前步驟對應的那幾行以黃色底標示。填錯時畫面會說明原因，修正後才能進到下一步。
自己動手時要注意
權限：練習用的個人專案裡，專案擁有者（Owner）就夠了；在公司專案裡請找管理員依職責授權。建立 VPC、子網路、Cloud Router 與 Cloud NAT 需要 Compute Network Admin（roles/compute.networkAdmin），但這個角色只能檢視、不能修改防火牆規則；建立或修改防火牆規則需要 Compute Security Admin（roles/compute.securityAdmin）。網路團隊與資安團隊分開授權，正是 Google Cloud 官方建議的分工方式。第一次在專案裡用 Compute Engine 時，要先啟用 Compute Engine API（compute.googleapis.com），啟用 API 需要 Service Usage Admin 之類的權限。工程師要透過 IAP 轉送 SSH，還要有 IAP-secured Tunnel User（roles/iap.tunnelResourceAccessor）角色。
費用：VPC 網路、子網路與內部 IP 本身不收費，一般的 VPC 防火牆規則屬於 Cloud NGFW Essentials 層級，也不另外收費。會產生費用的是：Cloud NAT（依 Cloud NAT 的計價方式收費，它使用的外部 IP 位址也依小時計費）、外部 IP 位址、跨區域或流出網際網路的資料傳輸，以及打開 VPC 流量記錄或防火牆規則記錄後產生的記錄量。新帳戶的 Free Trial 有 300 美元抵用金、期限 90 天（查證日期 2026-10-08），練習產生的費用會先從抵用金扣。練習完請把 Cloud NAT 與 Cloud Router 刪掉。
收尾：用 Terraform 建立的，在同一個資料夾執行 terraform destroy 就會刪除它建立的所有資源。用 gcloud 建立的，要從依賴最少的往回刪：先刪 NAT 閘道與 Cloud Router，再刪防火牆規則、子網路，最後刪 VPC 網路；子網路裡還有 VM 時刪不掉。最乾淨的做法是整個練習都開一個專用專案，結束後刪除專案，專案會先進入 30 天的待刪除狀態，期間可以復原。
# 方法一：Terraform 建立的，在範本所在資料夾執行（會列出要刪的資源，確認後輸入 yes）
terraform destroy
# 方法二：gcloud 建立的，依序刪除（名稱、區域換成自己的值）
gcloud compute routers nats delete qingsong-nat --router=qingsong-router --region=asia-east1
gcloud compute routers delete qingsong-router --region=asia-east1
gcloud compute firewall-rules delete allow-web-http-https
gcloud compute firewall-rules delete allow-ssh-from-iap
gcloud compute networks subnets delete web-tw --region=asia-east1
gcloud compute networks delete qingsong-vpc
# 方法三：整個練習專案一起刪除（專案裡所有資源都會停止並排入刪除）
gcloud projects delete my-project-id範例裡沒有任何服務帳戶金鑰、密碼或真實的專案 ID，my-project-id 請換成自己的專案 ID。在自己的電腦上用 gcloud，先執行 gcloud auth login 以使用者帳戶登入；Terraform 則用 gcloud auth application-default login 取得應用程式預設憑證（ADC）。在 CI／CD 管線裡執行 Terraform 時，改用 Workload Identity Federation 讓管線以短期憑證扮演服務帳戶，不要下載服務帳戶金鑰檔。也可以直接在控制台開 Cloud Shell，它已經登入並裝好 gcloud 與 Terraform。
📘 原理補完
VPC 與子網路：網路是全域的，位址是區域的
VPC 網路屬於某個專案，連同它的路由與防火牆規則都是全域資源；VPC 本身沒有 CIDR，位址範圍全部放在子網路上。子網路是區域資源，涵蓋該區域的所有可用區，所以同一個子網路裡可以放不同可用區的 VM，做跨可用區的高可用時不必像 AWS 那樣每個 AZ 各切一個子網路。不同區域的子網路只要在同一個 VPC，就能直接用內部 IP 互通。
建立 VPC 時要選子網路建立模式。自動模式（auto mode）會在每個區域自動建一個子網路，範圍取自 10.128.0.0/9，每個區域一段 /20，例如 us-central1 是 10.128.0.0/20、asia-east1 是 10.140.0.0/20，日後新開的區域也會自動加上子網路。自訂模式（custom mode）一開始沒有任何子網路，區域與範圍都由你決定。新專案預設帶的 default 網路就是自動模式，還附了四條優先順序 65534 的輸入允許規則：default-allow-internal（10.128.0.0/9 的所有 TCP、UDP 與 ICMP）、default-allow-ssh（0.0.0.0/0 的 TCP 22）、default-allow-rdp（0.0.0.0/0 的 TCP 3389）與 default-allow-icmp。練習可以用它，正式環境官方建議用自訂模式：IP 可以配合地端與其他網路規劃，也才能用 IPv6 子網路。自動模式可以用 gcloud compute networks update NETWORK --switch-to-custom-subnet-mode 單向轉成自訂模式，轉了就不能回去；兩個自動模式 VPC 的範圍一定重疊，所以不能互相對等互連。
子網路的主要 IPv4 範圍最小是 /29（8 個位址），官方建議不要比 /8 更大；同一個 VPC 裡所有子網路的主要與次要範圍都不能重疊，也不能和已對等互連網路的子網路重疊。0.0.0.0/8、127.0.0.0/8、169.254.0.0/16、224.0.0.0/4、255.255.255.255/32 以及私人 Google 存取用的 199.36.153.4/30、199.36.153.8/30 都不能拿來當子網路。主要範圍可以擴大（gcloud compute networks subnets expand-ip-range），但不能縮小或替換，擴大之後也不能復原，所以一開始寧可留空間。
一條防火牆規則有哪些欄位
VPC 防火牆規則屬於單一 VPC，不能跨網路共用。每條規則只有一個方向：輸入（ingress）管進入目標 VM 的封包，比對的是來源（IPv4／IPv6 範圍、來源網路標記或來源服務帳戶）；輸出（egress）管目標 VM 送出的封包，比對的是目的地範圍。沒有指定方向時預設是輸入，沒有指定來源範圍時預設是 0.0.0.0/0。優先順序是 0～65535 的整數，預設 1000。動作只有允許或拒絕其中一個。通訊協定和通訊埠可以寫 tcp、udp、icmp、esp、ah、sctp、ipip 或 IANA 協定編號，連接埠只對 TCP 與 UDP 有意義，不寫就代表全部。目標可以是網路中的所有執行個體、指定的網路標記或指定的服務帳戶；網路標記和服務帳戶不能混用在同一條規則（目標與來源都一樣）。規則還可以停用（保留但不執行），也可以開啟防火牆規則記錄，事後查是哪條規則放行或擋下。
評估順序：階層式政策先看，隱含動作最後
VPC 防火牆規則現在屬於 Cloud NGFW（Cloud Next Generation Firewall）的 Essentials 層級。同一個 Cloud NGFW 底下還有三種「防火牆政策」：設在機構或資料夾的階層式防火牆政策、可以關聯到多個 VPC 的全域網路防火牆政策，以及區域網路防火牆政策。官方文件寫明的預設評估順序是：階層式政策（先機構，再從最上層資料夾往下）→ 區域系統防火牆政策（regional system firewall policies，部分 Google 受管服務使用，實驗室省略）→ VPC 防火牆規則 → 全域網路防火牆政策 → 區域網路防火牆政策 → 隱含動作。每一層都先跳過方向或目標不符的規則，再依優先順序找第一條符合的。允許與拒絕會直接結束評估；goto_next 會把決定交給下一層；一層裡沒有規則符合時，也等同 goto_next。VPC 網路可以把 networkFirewallPolicyEnforcementOrder 改成 BEFORE_CLASSIC_FIREWALL，讓網路防火牆政策排在 VPC 防火牆規則前面，但階層式政策永遠最先。
這個順序的實際意義是：機構的資安團隊可以在階層式政策寫「一律拒絕某段惡意 IP」或「一律允許監控系統的來源」，各專案的 VPC 規則改不動它；要把決定權交給專案，就寫 goto_next。同一層裡，VPC 規則的衝突只看優先順序：數字較小的勝出；只有優先順序相同時，拒絕才勝過允許，同優先順序又同動作時結果相同，但官方說用哪一條比對是不確定的，所以別依賴它來看記錄。
有狀態、隱含規則，以及永遠擋或永遠放的流量
防火牆規則是有狀態（stateful）的：一條連線被允許之後，回應封包（來源與目的地對調的同一組五元組）自動放行，你也沒辦法另外寫規則擋掉它。所以輸出走隱含允許的連線，回程就算碰上「輸入一律拒絕」也能回來；反過來，輸入被允許的連線，回應也不必寫輸出規則。連線追蹤支援 TCP、UDP、SCTP 與 ICMP，連線要至少每 10 分鐘有一個封包，追蹤才會持續。
隱含動作在官方文件裡寫成「評估的最後一步」：輸入到 VM 網卡是拒絕，輸出是允許。很多教材把它畫成兩條優先順序 65535 的規則，概念相同，重點是它們不能刪除，只能用更小的數字蓋過去。另外有幾種流量不受防火牆規則控制：到中繼資料伺服器 169.254.169.254 的流量一律允許；送往外部 IP 的 TCP 25 輸出預設一律封鎖（465、587 不受影響），寫允許規則也開不了。
管理連線：用 IAP TCP 轉送取代對網際網路開放 SSH／RDP
把 TCP 22 或 3389 開給 0.0.0.0/0，等於讓全世界的掃描程式都能嘗試登入。Google Cloud 的建議做法是 Identity-Aware Proxy（IAP）的 TCP 轉送：工程師在自己的電腦執行 gcloud compute ssh VM_NAME --tunnel-through-iap，連線先到 IAP，IAP 檢查這個使用者有沒有 IAP-secured Tunnel User 角色（也可以加上情境感知存取條件），通過後再從 Google 的 35.235.240.0/20 這段位址連到 VM 的內部 IP。VM 不需要外部 IP，防火牆只要允許來源 35.235.240.0/20 連 22（Windows 是 3389）。權限由 IAM 集中管理，誰在什麼時候連進哪台 VM 也會留在稽核記錄。
私有 VM 怎麼連出去：Cloud NAT 與私人 Google 存取
拿掉外部 IP 之後，VM 還要下載修補程式、呼叫外部 API。這時用 Cloud NAT：它是建在某個區域 Cloud Router 上的受管服務，由 Google 的網路堆疊分散執行，沒有一台閘道 VM 會成為單點；它只處理 VM 主動發起的連線與回應，外面無法主動連進來。Cloud NAT 是區域資源，一個區域的子網路要用同區域的 Cloud Router 與 NAT 閘道。如果 VM 只是要存取 Cloud Storage、BigQuery 這類 Google API，在子網路開私人 Google 存取（Private Google Access）就夠了，流量不會經過 NAT，也不離開 Google 網路。注意防火牆的輸出規則仍然有效：如果你用高優先順序寫了「拒絕所有輸出」，NAT 和私人 Google 存取都救不了。
相似功能怎麼分
| 功能 | 設定在哪裡 | 挑目標的方式 | 動作 | 適合的用途 |
|---|---|---|---|---|
| VPC 防火牆規則 | 單一 VPC（全域） | 所有執行個體、網路標記、服務帳戶 | 允許、拒絕 | 單一網路裡的日常規則，例如網站開 443、IAP 開 22 |
| 階層式防火牆政策 | 機構或資料夾 | 關聯到的資源底下所有 VPC；可再指定服務帳戶等 | 允許、拒絕、goto_next 等 | 資安團隊的全公司底線，專案改不動 |
| 網路防火牆政策（全域／區域） | 政策資源，可關聯多個 VPC | 支援安全標記（secure tags）等，受 IAM 控管 | 允許、拒絕、goto_next 等 | 集中管理多個 VPC 的規則；Standard、Enterprise 層級的 FQDN、威脅情資、第 7 層檢查 |
| Google Cloud Armor | 外部負載平衡器的後端服務 | 依 IP、地理位置、第 7 層條件 | 允許、拒絕、限速等 | 網站的 WAF 與 DDoS 防護，在流量到達 VM 之前處理 |
| VPC Service Controls | 機構裡的服務邊界 | 專案與 Google API 服務 | 邊界內外的 API 存取 | 防止資料從 BigQuery、Cloud Storage 等 API 外洩，不是封包防火牆 |
| 項目 | Google Cloud | AWS | Azure |
|---|---|---|---|
| 虛擬網路的範圍 | VPC 全域，子網路屬於區域 | VPC 屬於區域，子網路屬於一個 AZ | VNet 屬於區域，子網路涵蓋區域內的可用性區域 |
| 子網路保留位址 | 主要範圍 4 個 | 每個子網路 5 個 | 每個子網路 5 個 |
| 主要的流量過濾 | VPC 防火牆規則（VPC 層級、有狀態、允許＋拒絕、優先順序 0～65535） | 安全群組（有狀態、只有允許）＋網路 ACL（無狀態、依編號） | NSG（有狀態、允許＋拒絕、優先順序 100～4096） |
| 挑目標的方式 | 網路標記、服務帳戶、全部 | 掛在網路介面上的安全群組 | 關聯子網路或網路介面；應用程式安全性群組 |
| 不開公開 IP 的管理連線 | IAP TCP 轉送 | Systems Manager Session Manager 等 | Azure Bastion |
判斷步驟
- 先確定網路範圍：同一個團隊、同一個機構要跨區域部署，一個自訂模式 VPC 加多個區域子網路就夠，不需要每區一個 VPC。多個專案要共用網路，再考慮共用 VPC；兩個獨立管理的網路要互通，才考慮 VPC 網路對等互連。
- 規劃 IP：每個子網路的主要範圍不能和同一 VPC 的其他子網路、對等網路、地端網段重疊，大小最小 /29，而且只能擴大，所以先估好未來數量，再扣掉 4 個保留位址。
- 寫防火牆規則前先決定目標要用什麼挑：要求嚴謹就用服務帳戶，簡單情境用網路標記，真的要全部 VM 一致才用「所有執行個體」。
- 對外服務只開必要的連接埠，管理連線一律走 IAP（來源 35.235.240.0/20），不要對 0.0.0.0/0 開 22 或 3389。
- 要擋特定流量時，確認拒絕規則的優先順序數字比對應的允許規則小；整個公司都要擋的，交給階層式防火牆政策。
- 沒有外部 IP 的 VM 要連外：連網際網路用同區域的 Cloud NAT，只連 Google API 開私人 Google 存取。
- 上線後打開防火牆規則記錄或 VPC 流量記錄，搭配 Network Intelligence Center 的 Firewall Insights 找出沒用到或被遮蔽的規則（記錄會產生費用，看需要開）。
容易考錯的地方
「VPC 是區域資源」是錯的。常見的干擾選項會寫「在每個區域各建一個 VPC 再做對等互連」來達成跨區通訊，在 Google Cloud 這是多此一舉；正確答案通常是同一個 VPC 加多個區域子網路。反過來，子網路是區域資源，所以「把子網路建在某個可用區」的選項也不對。
拒絕不一定贏。題目給兩條規則時先比優先順序，數字小的決定；只有優先順序相同時拒絕才勝過允許。要擋掉某個來源，拒絕規則的數字要比允許規則小。
網路標記 vs 服務帳戶。題目強調「防止有 VM 編輯權限的人自己開放流量」或「依身分控管」時，答案是用服務帳戶當目標或來源；網路標記只要能改 VM 就能改。兩者不能混用在同一條規則。
不要開 0.0.0.0/0 的 22。需要讓管理員 SSH 進沒有外部 IP 的 VM，答案是 IAP TCP 轉送，防火牆允許 35.235.240.0/20；Cloud NAT 是讓 VM 連出去，方向相反，不能解決這個問題。
回應不用另外寫規則。規則有狀態，干擾選項常寫「新增輸出規則允許回應流量」或「放行 1024～65535」，那是 AWS 網路 ACL 的思維。
自訂 VPC 沒有內部互通規則。從 default 網路搬到自訂 VPC 後，VM 之間突然連不上，是因為少了 default-allow-internal 那類規則，要自己加允許內部範圍或指定標記的輸入規則。
子網路只能擴大。題目問「子網路 IP 不夠用、又不想中斷服務」，答案是擴大主要範圍（expand-ip-range），而且要確認新範圍不和其他子網路重疊；「縮小範圍」或「直接改成另一段 CIDR」都做不到。相關考試：ACE 的網路設定與管理、PCSE 的邊界安全與分段、PCNE 的 VPC 設計與 Cloud NGFW 都會考到這些判斷。
✅ 自我檢測
以下 6 題都是原創題，選完會立即顯示對錯與解析，全部作答後會出現總分。目前得分：0 / 6