GCP 網路基礎：VPC、防火牆與安全連線完全指南

在 GCP 開出第一台 Compute Engine VM，你大概馬上會卡在這幾個問題上：為什麼這台 VM 開機就連得上網路？防火牆規則要怎麼設，才不會一不小心把自己鎖在外面、又不會開得太大？還有 SSH、gcloud、Cloud IAP 這三種連線方式，到底差在哪、什麼時候用哪個？

這篇就把 GCP 網路最該先搞懂的三件事講清楚：VPC 虛擬私有雲怎麼運作、防火牆規則怎麼設計、安全連線怎麼選。中間會穿插我自己踩過的坑，還有 ACE 考試常拿這些點出題的地方，讓你看完不只會考，實際開環境時也知道在做什麼。

---

Section 1: VPC 核心概念 — GCP 的全球化網路架構

什麼是 VPC (Virtual Private Cloud)?

VPC (Virtual Private Cloud，虛擬私有雲) 是 GCP 提供的軟體定義網路 (SDN, Software-Defined Network)——白話講，就是整套網路（路由、防火牆、子網路）都用軟體跟設定檔來定義，而不是靠機房裡那些實體線路。你在雲端拉出一個自己專屬、跟別人隔開的私有網路環境，而背後的硬體完全交給 Google 管。

跟傳統資料中心那種實體網路不一樣，VPC 是完全虛擬化的：

• 不用買實體路由器、交換機
• 網路規則與路由都用軟體來定義
• 可以隨時調整，擴展起來也不卡

GCP VPC 的三大特色:

1. 全球性資源 - VPC 本身是全球資源，不受限於單一區域
2. 區域性子網路 - Subnets 是區域資源，可跨 Zone 但不跨 Region
3. 自動路由 - VPC 自動建立全球路由表，子網路間無需手動設定路由

GCP VPC vs AWS VPC：關鍵差異

這裡是 GCP 跟 AWS/Azure 在架構上差最多的地方：

特性	GCP VPC	AWS VPC	說明
VPC 範圍	🌍 全球	🌏 區域	GCP VPC 一次可跨多個 Region
Subnet 範圍	🌏 區域	🏢 可用區	GCP Subnet 可跨同 Region 內的多個 Zone
路由	✅ 自動	⚠️ 手動	GCP 自動建立子網路間的路由
擴展性	高	中	GCP 設計更適合全球化應用

實務意義:

假設你要在台灣 (asia-east1) 與新加坡 (asia-southeast1) 兩個區域部署應用，在 GCP 只需：

1 個 VPC
├── asia-east1 Subnet (10.1.0.0/24)
└── asia-southeast1 Subnet (10.2.0.0/24)

而在 AWS 需要：

VPC-Taiwan (需手動建立 VPC Peering)
VPC-Singapore

GCP 這種全球化設計，跨區域通訊就少了一道手續。我第一次從 AWS 換過來時，最有感的就是這個——以前在 AWS 為了讓兩個 region 的服務互通，光是接 VPC Peering、調路由表就要搞半天，GCP 這邊一個 VPC 把兩個 region 的 subnet 一放就通了。

VPC 的三種網路模式

在 GCP 建專案時，VPC 網路模式有三種可以選：

模式	子網路建立方式	適用場景	生產建議
Default	專案開通時自動建立	快速測試、POC	❌ 不建議
Auto Mode	在 10.128.0.0/9 整段裡，每個 Region 自動拿一個 /20	中小型專案、快速部署	⚠️ 謹慎使用
Custom Mode	完全手動控制 IP 範圍	企業生產環境	✅ 強烈推薦

為什麼生產環境要用 Custom Mode?

1. 完全掌控 IP 範圍 - 避免與 On-Premise(地端，就是你自己機房裡的網路)網段衝突
2. 安全性更高 - Default/Auto Mode 預設開放過多防火牆規則
3. 靈活性更好 - 可依環境 (Dev/Staging/Prod) 規劃獨立 CIDR
4. 符合企業規範 - 大多數企業都有一套 IP 地址管理政策 (IPAM, IP Address Management)，統一規定哪個網段歸誰用

我自己的經驗是：Auto Mode 一開始確實省事，但它在每個 region 自動塞一個 10.128.0.0/9 裡的網段，你完全沒得挑。等哪天要接地端機房、或跟另一個專案的 VPC 互通，撞到網段就只能整個重來——重切網段這種事一旦上了生產環境，等於要停機搬家。所以與其之後痛，不如一開始就用 Custom Mode 把 IP 範圍捏在自己手裡。

💡 重點提點

生產環境一律用 Custom Mode VPC,自己決定每個網段；Auto Mode 只留給個人學習跟 POC。記一個關鍵：Auto Mode 可以轉成 Custom，但 Custom 不能轉回 Auto,是單向不可逆的——所以猶豫時直接選 Custom，反正退路只有一個方向。

---

Section 2: Subnet 子網路規劃 — CIDR 計算與最佳實踐

什麼是 Subnet (子網路)?

Subnet (子網路) 就是 VPC 裡的一段 IP 地址範圍,拿來分配給 VM、容器這些資源用。

GCP Subnet 的特性:

• 區域性資源 - 每個 Subnet 屬於特定 Region
• 可跨 Zone - 同一 Region 內的多個 Zone 可共用 Subnet（這點跟 AWS 不同，AWS 的 Subnet 綁死在單一可用區）
• 唯一 CIDR - 每個 Subnet 的 IP 範圍在 VPC 內必須唯一
• 可擴展 - 建立後可透過指令把主要 IP 範圍擴大，但不能縮小、也不能整個換掉(官方就是 expand only)

CIDR 表示法快速入門

CIDR (Classless Inter-Domain Routing) 是表示 IP 範圍的標準格式：

10.0.1.0/24
│       │
IP 起點 │
        子網路遮罩（表示多少位元固定）

常見 CIDR 範圍對照表:

CIDR	可用 IP 數量	適用場景	範例
/32	1	單一 IP	10.0.1.5/32
/28	16	極小型子網路	10.0.1.0/28
/24	256	小型應用（標準）	10.0.1.0/24
/20	4,096	中型應用	10.0.0.0/20
/16	65,536	大型應用	10.0.0.0/16
/8	16,777,216	企業級超大網段	10.0.0.0/8

💡 重點提點

新手規劃網段最容易算錯「實際能用幾個 IP」。表格上 /24 寫 256，但 GCP 會在每個 Subnet 的主要 IP 範圍保留 4 個(第一個網路位址、第二個給預設閘道、倒數第二個保留、最後一個廣播位址)，所以 /24 真正能配給 VM 的是 252 個,公式是 2^(32-遮罩) - 4。要開的 VM 數量很貼近上限時，記得把這 4 個先扣掉再算，不然之後 IP 不夠用要擴網段又是一場工程。

私有 IP 範圍選擇

根據 RFC 1918，可用於私有網路的 IP 範圍為：

類別	CIDR 範圍	可用 IP 總數	建議用途
Class A	10.0.0.0/8	16,777,216	大型企業、多環境
Class B	172.16.0.0/12	1,048,576	中型組織
Class C	192.168.0.0/16	65,536	小型專案、家用網路

（這裡借用 Class A/B/C 的舊名字只是幫你記憶。現在 IP 規劃早就改用 CIDR、不再分 class 了，嚴格說 172.16.0.0/12 跟傳統的 Class B 也不完全是同一回事——看到 class 別以為 CIDR 還要分等級。）

實務建議:

• 企業環境 - 使用 10.0.0.0/8，為不同 Region 與環境預留充足空間
• 混合雲架構 - 先確認地端機房現在用哪些網段，避免上雲後 IP 撞在一起
• 容器環境 - 為 GKE 預留額外的 Secondary IP Range(次要 IP 範圍，專門給 Pod 跟 Service 用)

實戰案例：規劃多環境 Subnet

假設你要在 asia-east1 開 Dev / Staging / Prod 三個環境：

VPC: my-company-vpc (10.0.0.0/8)

├── asia-east1-dev (10.1.0.0/20)       → 4,096 IPs
├── asia-east1-staging (10.2.0.0/20)   → 4,096 IPs
└── asia-east1-prod (10.3.0.0/20)      → 4,096 IPs
    ├── Primary Range: 10.3.0.0/20       → 4,096 IPs (VMs)
    ├── Secondary Range 1: 10.3.16.0/24  → 256 IPs (GKE Pods)
    └── Secondary Range 2: 10.3.17.0/24  → 256 IPs (GKE Services)

設計邏輯:

1. 預留足夠空間 - 每環境 /20 (4,096 IPs)，足夠未來擴展
2. 環境隔離 - 不同環境使用不同 IP 段落，便於防火牆規則管理
3. 容器支援 - Production 環境預留 Secondary Range 給 GKE

GCP Subnet 建立範例

使用 gcloud CLI 建立 Custom Subnet：

# 建立 Production Subnet
gcloud compute networks subnets create asia-east1-prod \
    --network=my-company-vpc \
    --region=asia-east1 \
    --range=10.3.0.0/20 \
    --secondary-range=gke-pods=10.3.1.0/24,gke-services=10.3.2.0/24 \
    --enable-private-ip-google-access

參數說明:

• --range - Primary IP 範圍，供 VM 使用
• --secondary-range - 額外 IP 範圍，供 GKE 等服務使用
• --enable-private-ip-google-access - 允許無公開 IP 的 VM 存取 Google APIs

---

Section 3: 防火牆規則設計 — 8 大最佳實踐詳解

GCP 防火牆基礎

GCP 防火牆是 VPC 層級的規則，負責管進出 VM 的流量。它是有狀態的(Stateful)——意思是防火牆會記住每一條已建立的連線。只要你放行了一個進來的請求(Ingress)，它的回程流量會被自動放行，你不用另外再開一條 Egress 規則去放回程。這跟某些「無狀態(Stateless)」的防火牆不一樣，後者進、出兩個方向都得各自開規則，很容易漏一邊。

關鍵特性:

• VPC 層級 - 防火牆規則套用於整個 VPC，不是綁在單一 VM 上
• Stateful 機制 - Ingress 放行的連線，回程自動放行，不必另開 Egress
• 優先權機制 - 數字越小優先權越高（0-65535）
• 預設拒絕 - GCP 預設擋掉所有 Ingress、放行所有 Egress
• 目標選擇 - 可用 Network Tags、Service Accounts、IP 範圍指定套用對象

防火牆規則的組成元素

一條防火牆規則包含以下關鍵元素：

元素	說明	範例
Direction	流量方向	INGRESS (進入) / EGRESS (出去)
Action	動作	ALLOW / DENY
Priority	優先權 (0-65535)	1000 (數字越小優先權越高)
Source/Destination	來源/目的地	IP 範圍、Service Account、Tag
Protocol & Port	協定與連接埠	tcp:22 (SSH), tcp:80 (HTTP)
Target	套用對象	特定 VM Tag、Service Account

防火牆規則評估順序（ACE 必考）

GCP 防火牆規則的評估遵循嚴格順序，考試常考「兩條規則衝突時誰贏？」：

封包到達 VM
    │
    ▼
1. 依 Priority 數字排序（小的先評估）
    │
    ▼
2. 同 Priority：DENY 優先於 ALLOW
    │
    ▼
3. 第一個匹配的規則決定結果
    │
    ▼
4. 沒有任何規則匹配 → 使用隱含規則
   （Ingress: 隱含 DENY ALL）
   （Egress:  隱含 ALLOW ALL）

常考範例：

規則	Priority	Action	Source	Port
Rule A	1000	ALLOW	0.0.0.0/0	tcp:80
Rule B	900	DENY	10.0.0.0/8	tcp:80

結果：來自 10.0.0.5 的 HTTP 請求會被 DENY（Rule B Priority 900 < 1000，先評估先匹配）。來自 203.0.113.1 的 HTTP 請求會被 ALLOW（Rule B 不匹配，Rule A 匹配）。

記憶口訣：Priority 數字越小越優先；同 Priority 時 DENY 贏；沒匹配到就看隱含規則（Ingress 全擋、Egress 全放）。

8 大防火牆最佳實踐

根據 Tufin GCP Best Practices 與 Google 官方建議：

1. 最小權限原則 (Least Privilege)

預設阻擋所有流量，僅允許必要的連線。

❌ 錯誤做法:

# 允許所有來源存取所有連接埠（極度危險！）
gcloud compute firewall-rules create allow-all \
    --allow=tcp,udp,icmp \
    --source-ranges=0.0.0.0/0

✅ 正確做法:

# 僅允許特定 IP 存取特定連接埠
gcloud compute firewall-rules create allow-ssh-from-office \
    --allow=tcp:22 \
    --source-ranges=203.0.113.0/24 \
    --target-tags=ssh-enabled

2. 明確 IP 範圍與連接埠

避免使用 0.0.0.0/0，除非絕對必要（如公開網站的 HTTP/HTTPS）。

最常見的災難就是有人為了「先連得上再說」，把 SSH 的 tcp:22 開給 0.0.0.0/0,結果沒幾天 log 裡就是滿滿的全世界掃 port 嘗試登入。對外只該開真正要對全世界服務的連接埠(80、443)，管理用的 SSH/RDP 永遠鎖在固定 IP 或走後面會講的 IAP——這條守住，你的攻擊面就少一大半。

✅ 實務技巧:

• 使用公司辦公室的固定 IP 作為管理入口
• 透過 Cloud VPN 或 Cloud Interconnect 連接 On-Premise
• 對外服務僅開放必要連接埠（80, 443）

3. 優先使用 Service Accounts 取代 Network Tags

為什麼 Service Accounts 優於 Network Tags?

方法	優點	缺點
Network Tags	設定簡單	❌ 任何 Compute Engine Admin 可修改 Tag
Service Accounts	✅ 綁定 IAM 權限，更安全	設定稍複雜

❌ 使用 Network Tags:

# Tag 可被管理員輕易新增到其他 VM,擴大攻擊面
gcloud compute firewall-rules create allow-db \
    --allow=tcp:3306 \
    --target-tags=database-server

✅ 使用 Service Accounts:

# 只有特定 Service Account 的 VM 可存取,更安全
gcloud compute firewall-rules create allow-db \
    --allow=tcp:3306 \
    --target-service-accounts=db-sa@my-project.iam.gserviceaccount.com

4. 階層化策略 (Hierarchical Firewall Policies)

在組織/資料夾層級設定 DENY 規則，VM 層級設定 ALLOW 規則。

Organization Level
├── DENY all RDP (tcp:3389) globally  ← 全公司禁止 RDP
│
Folder Level (Production)
├── DENY outbound to public internet   ← 生產環境禁止對外連線
│
Project Level
└── ALLOW specific application traffic  ← 應用層允許必要流量

優勢:

• 全域安全基線 - 組織層級強制執行安全政策
• 防止誤設定 - 即使 Project Admin 誤設，Org 層級仍阻擋
• 集中管理 - 安全團隊統一控管

5. 優先權數值規劃

數字越小優先權越高，關鍵規則配置低數值。

# Priority 100 - 最高優先權,阻擋已知惡意 IP
gcloud compute firewall-rules create block-malicious-ips \
    --priority=100 \
    --deny=tcp,udp,icmp \
    --source-ranges=198.51.100.0/24

# Priority 1000 - 標準允許規則
gcloud compute firewall-rules create allow-https \
    --priority=1000 \
    --allow=tcp:443 \
    --source-ranges=0.0.0.0/0

# Priority 65534 - 預設拒絕（最低優先權）
gcloud compute firewall-rules create default-deny-all \
    --priority=65534 \
    --deny=all \
    --source-ranges=0.0.0.0/0

建議優先權範圍:

優先權範圍	用途
0-999	緊急阻擋規則（惡意 IP、漏洞連接埠）
1000-9999	正常業務規則
10000-64999	低優先權允許規則
65000-65535	預設拒絕規則

6. 啟用日誌與監控

Firewall Rules Logging + Firewall Insights 雙重驗證。

# 建立規則時啟用日誌記錄
gcloud compute firewall-rules create allow-ssh \
    --allow=tcp:22 \
    --source-ranges=203.0.113.0/24 \
    --enable-logging

啟用日誌的好處:

• 稽核追蹤 - 記錄所有允許/拒絕的連線
• 異常偵測 - 發現非預期的流量模式
• 合規要求 - 有助於滿足 PCI-DSS、HIPAA 等的稽核紀錄要求（合規是一整套控制措施，單靠開 log 不等於就「符合」，但 log 通常是其中跑不掉的一項）

Firewall Insights 自動分析：

• 未使用的規則 - 一段時間內(預設約數週)沒有任何流量打中的規則
• 過於寬鬆的規則 - 允許 0.0.0.0/0 的規則
• 重複規則 - 邏輯上重複的規則

7. 定期稽核與自動化清理

移除過時或未使用的規則，利用自動化工具。

建議流程：

1. 每季稽核 - 使用 Firewall Insights 檢視未使用規則
2. 標記移除 - 將未使用規則標記為 “To-Be-Removed”
3. 測試期 - 保留 30 天觀察是否有影響
4. 自動清理 - 使用 Cloud Scheduler + Cloud Functions 自動移除

8. 上線前測試

在 Staging 環境驗證規則行為，避免生產環境中斷。

✅ 測試檢查清單:

• 允許規則是否生效？（測試正常流量）
• 拒絕規則是否生效？（測試異常流量）
• 優先權順序是否正確？（測試衝突規則）
• 日誌記錄是否正常？（檢查 Cloud Logging）

---

Section 4: 安全連線方式對比 — SSH vs gcloud vs Cloud IAP

為什麼需要安全連線？

在 GCP 開好 VM 之後，最常碰到的需求就是遠端登入管理。但傳統 SSH 連線其實有不少風險：

• 暴露公開 IP - VM 必須掛一個外部 IP，等於把自己放上檯面當攻擊目標
• 金鑰管理困難 - 金鑰要手動分發、輪替，人一多就亂
• 無法追蹤稽核 - 很難說清楚誰在什麼時候登入過
• 無地理位置限制 - 只要 IP 通，世界任何角落都能試著連

GCP 提供三種安全連線方式，各自適合不同場景。

方法 1: 傳統 SSH Key 連線

運作流程:

你的電腦 → SSH (port 22) → VM 外部 IP → 驗證 SSH Key → 登入

設定步驟:

# 1. 產生 SSH 金鑰
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

# 2. 將公鑰加入 VM Metadata
gcloud compute instances add-metadata my-vm \
    --metadata-from-file ssh-keys=~/.ssh/id_rsa.pub

# 3. 透過外部 IP 連線
ssh -i ~/.ssh/id_rsa username@35.201.XXX.XXX

優點:

• ✅ 設定簡單，適合個人專案
• ✅ 不需額外工具或服務
• ✅ 支援所有 SSH 工具（PuTTY、MobaXterm）

缺點:

• ❌ 需要暴露外部 IP（安全風險）
• ❌ 金鑰管理困難（多人協作時）
• ❌ 無法追蹤登入紀錄（稽核困難）
• ❌ 需手動設定防火牆規則

適用場景: 個人學習、POC 專案

方法 2: gcloud CLI 連線（OS Login）

運作流程:

你的電腦 → gcloud compute ssh → IAM 驗證 → 自動產生臨時 SSH Key → 登入

設定步驟:

# 1. 啟用 OS Login（專案層級）
gcloud compute project-info add-metadata \
    --metadata enable-oslogin=TRUE

# 2. 授予使用者 OS Login 權限
gcloud projects add-iam-policy-binding my-project \
    --member="user:user@example.com" \
    --role="roles/compute.osLogin"

# 3. 直接連線（無需手動管理金鑰）
gcloud compute ssh my-vm --zone=asia-east1-a

優點:

• ✅ 無需手動管理金鑰 - gcloud 自動產生臨時金鑰
• ✅ 與 IAM 整合 - 使用 Google 帳號認證
• ✅ 自動追蹤稽核 - Cloud Logging 記錄所有登入
• ✅ 支援 2FA - 可強制雙因素認證

缺點:

• ❌ 仍需外部 IP - VM 必須可從網際網路存取
• ❌ 依賴 gcloud CLI - 無法使用傳統 SSH 工具

適用場景: 團隊協作、需要 IAM 整合的專案

方法 3: Cloud IAP 零信任連線（推薦）

運作流程:

你的電腦 → gcloud CLI → HTTPS 隧道 → IAP Proxy → IAM 驗證 → VM (無外部 IP)

Cloud IAP 帶來的改變:

1. 無需外部 IP - VM 完全隱藏在內網
2. 無需跳板機 - 省去維護 Bastion Host(跳板機，一台專門掛公開 IP 讓人先 SSH 進去、再轉進內網其他機器的中繼主機)的成本
3. 無需 VPN - 使用者直接透過瀏覽器或 CLI 存取
4. 端到端加密 - SSH 加密從本地延伸到目標 VM
5. 情境感知存取 - 可根據裝置安全狀態、地理位置控管

過去要讓內網 VM 不掛公開 IP 又能登入，標準做法就是架一台 Bastion Host 當唯一入口。但那台跳板機本身就要修補、要顧、被打掛全部人都進不去，等於把雞蛋全放一個籃子。IAP 的好處就是把這台跳板機整個拿掉，改由 Google 的代理層幫你驗證身分再轉發——我現在新開的環境基本上都直接走 IAP，不再自己養 Bastion 了。

設定步驟:

# 1. 啟用 Cloud IAP API
gcloud services enable iap.googleapis.com

# 2. 建立防火牆規則（允許 IAP 轉發流量）
gcloud compute firewall-rules create allow-iap-ssh \
    --allow=tcp:22 \
    --source-ranges=35.235.240.0/20 \
    --target-tags=iap-ssh

# 3. 授予使用者 IAP 權限
gcloud projects add-iam-policy-binding my-project \
    --member="user:user@example.com" \
    --role="roles/iap.tunnelResourceAccessor"

# 4. 透過 IAP 連線（VM 無需外部 IP）
gcloud compute ssh my-vm \
    --zone=asia-east1-a \
    --tunnel-through-iap

IAP 的運作原理:

當你執行 gcloud compute ssh --tunnel-through-iap 時：

1. gcloud 建立 HTTPS 隧道 - 連線到 IAP Proxy (tunnel.cloudproxy.app)
2. IAP 驗證 IAM 權限 - 檢查你是否有 iap.tunnelResourceAccessor 角色
3. 轉發 SSH 流量 - IAP 將加密的 SSH 流量轉發到目標 VM
4. VM 驗證身份 - VM 端再次驗證 SSH 連線（雙重認證）

這裡有個容易誤會的點：IAP 並不會把 SSH 連線解開來看，它只是負責驗證你有沒有權限、然後把加密好的流量原封轉發到 VM，所以加密是真正從你本機一路到目標 VM 的端到端，中間沒有被拆開過。

三種方法完整對比

方法	需要外部 IP?	需要 VPN?	金鑰管理	情境感知	稽核追蹤	適用場景
SSH Key	✅ 是	❌ 否	手動管理	❌ 無	⚠️ 有限	個人學習
gcloud CLI	✅ 是	❌ 否	自動產生	⚠️ 有限	✅ 完整	團隊協作
Cloud IAP	❌ 否	❌ 否	無需金鑰	✅ 完整	✅ 完整	生產環境（推薦）

💡 重點提點

三種方法最容易被搞混的就是「到底還要不要外部 IP」。記一個關鍵差別：SSH Key 跟 gcloud CLI(OS Login)都還是要 VM 有外部 IP——gcloud 只是幫你省掉手動管金鑰跟接上 IAM，連線路徑本身還是走公開 IP。只有 Cloud IAP 能讓 VM 完全不掛外部 IP,把機器藏在內網，改由 IAP 驗證後轉發。考試常拿這點出題：「VM 不能有外部 IP、又要能 SSH 進去」，答案永遠是 IAP，不是 OS Login。

Cloud IAP 進階功能

1. 情境感知存取 (Context-Aware Access)

可根據以下條件限制存取：

• 裝置安全狀態 - 僅允許受管理的裝置
• 地理位置 - 僅允許特定國家/地區
• 時間限制 - 僅允許工作時間存取
• 裝置類型 - 限制桌機或行動裝置

2. IAP Desktop 工具

Google 提供開源工具 IAP Desktop，支援：

• Windows RDP 連線
• Linux SSH 連線
• 檔案傳輸
• 多 VM 集中管理

3. 與 Security Command Center 整合

IAP 連線記錄可整合到 Security Command Center，實現：

• 異常登入偵測 - 偵測非工作時間或異地登入
• 合規報告 - 自動產生存取稽核報告
• 威脅偵測 - 與 Cloud IDS 整合，偵測橫向移動攻擊

---

Section 5: 實戰演練 — 建立 Custom VPC + IAP 連線

實戰目標

建立一個符合最佳實踐的 GCP 網路環境：

• ✅ Custom Mode VPC
• ✅ 適當規劃的 Subnet CIDR
• ✅ 基於 Service Account 的防火牆規則
• ✅ Cloud IAP 零信任連線（無外部 IP）

Step 1: 建立 Custom VPC

# 建立 VPC（不自動建立子網路）
gcloud compute networks create my-secure-vpc \
    --subnet-mode=custom \
    --bgp-routing-mode=regional

Step 2: 建立 Subnet

# 在 asia-east1 建立 Production Subnet
gcloud compute networks subnets create asia-east1-prod \
    --network=my-secure-vpc \
    --region=asia-east1 \
    --range=10.1.0.0/24 \
    --enable-private-ip-google-access

Step 3: 建立防火牆規則

# 1. 允許 IAP 轉發 SSH 流量
gcloud compute firewall-rules create allow-iap-ssh \
    --network=my-secure-vpc \
    --allow=tcp:22 \
    --source-ranges=35.235.240.0/20 \
    --priority=1000 \
    --enable-logging

# 2. 允許內部通訊
gcloud compute firewall-rules create allow-internal \
    --network=my-secure-vpc \
    --allow=tcp,udp,icmp \
    --source-ranges=10.1.0.0/24 \
    --priority=2000

# 3. 預設拒絕規則（顯式記錄）
# GCP 本來就有一條隱含的 Deny Ingress，這條顯式規則是為了把被擋的流量寫進 Log
gcloud compute firewall-rules create default-deny-all \
    --network=my-secure-vpc \
    --deny=all \
    --priority=65534 \
    --source-ranges=0.0.0.0/0 \
    --enable-logging

Step 4: 建立無外部 IP 的 VM

# 建立 VM（注意 --no-address 與 --tags 參數）
gcloud compute instances create secure-vm \
    --zone=asia-east1-a \
    --machine-type=e2-micro \
    --subnet=asia-east1-prod \
    --no-address \
    --service-account=my-sa@my-project.iam.gserviceaccount.com \
    --scopes=https://www.googleapis.com/auth/cloud-platform \
    --tags=iap-ssh   # ← 必須加上此行，對應防火牆規則！

Step 5: 透過 IAP 連線

# 授予自己 IAP 權限（首次設定）
gcloud projects add-iam-policy-binding my-project \
    --member="user:$(gcloud config get-value account)" \
    --role="roles/iap.tunnelResourceAccessor"

# 授予 Compute 檢視權限（必要）
gcloud projects add-iam-policy-binding my-project \
    --member="user:$(gcloud config get-value account)" \
    --role="roles/compute.viewer"

# 授予 OS Login 權限（若使用 OS Login）
gcloud projects add-iam-policy-binding my-project \
    --member="user:$(gcloud config get-value account)" \
    --role="roles/compute.osLogin"

# 連線到 VM（完全無外部 IP！）
gcloud compute ssh secure-vm \
    --zone=asia-east1-a \
    --tunnel-through-iap

驗證結果

# 在 VM 內執行，確認無外部 IP
curl ifconfig.me
# 應回傳錯誤或超時，因為 VM 無對外連線能力

# 但可以存取 Google APIs（Private Google Access）
curl https://storage.googleapis.com
# 應正常回應

# 注意：由於未設定 Cloud NAT，此 VM 僅能存取 Google 服務
# 無法連接一般網際網路（如 apt-get update），這是正常的安全隔離狀態

---

Section 6: 總結與下一步

核心重點回顧

一篇看下來內容不少，這裡把最該帶走的幾個觀念收攏一下，考前掃一眼就夠：

1. VPC 核心概念

• GCP VPC 是全球性資源,這是跟 AWS/Azure 差最多的地方
• Subnet 是區域性資源,可跨同 Region 內的 Zone，但不跨 Region
• 生產環境務必使用 Custom Mode VPC,而且記得它轉過去就回不來了

2. Subnet 規劃

• 看懂 CIDR 表示法,並記得 GCP 每段保留 4 個 IP（/24 標 256、實際可用 252）
• 用 RFC 1918 私有 IP 範圍（10.x.x.x、172.16.x.x、192.168.x.x）
• 為容器環境預留 Secondary IP Range

3. 防火牆規則

• 遵循 8 大最佳實踐（最小權限、用 Service Accounts、階層化策略）
• 是 Stateful,放行 Ingress 就自動放回程；Priority 越小越優先，同 Priority 時 DENY 贏
• 啟用 Firewall Logging & Insights,定期清掉沒在用的規則

4. 安全連線

• 要 VM 不掛外部 IP 又能登入，答案是 Cloud IAP,不是 OS Login
• 不需外部 IP、不需 VPN、不需自己養跳板機
• 支援情境感知存取與完整稽核

下一步學習資源

官方文件

• 📘 VPC Networks Overview
• 📘 VPC Firewall Rules
• 📘 Cloud IAP Documentation

實驗室實作

Qwiklabs 已經併進 Google Cloud Skills Boost，舊的 qwiklabs.com 連結大多失效或重導了。直接到 Skills Boost 上搜尋對應的 hands-on lab 即可：

• 在 Skills Boost 搜尋 「VPC Networks」 — 練 VPC 與 Subnet 建立
• 在 Skills Boost 搜尋 「Firewall Rules」 — 練防火牆規則設定
• 在 Skills Boost 搜尋 「Cloud IAP」/「IAP for TCP forwarding」 — 練零信任連線

進階主題

• 🚀 VPC Peering - 連接多個 VPC
• 🚀 Shared VPC - 跨專案共用網路資源
• 🚀 Cloud VPN & Interconnect - 混合雲架構
• 🚀 Private Service Connect - 私有存取 Google APIs

系列文章連結

• 📖 上一篇：GCP-103：第一台雲端主機：Compute Engine 完全指南
• 📖 下一篇：ACE-201：GCP 資料儲存策略
• 📖 系列總覽：GCP 精通之路：完整學習地圖

---

常見問題 FAQ

Q1: VPC 與 Subnet 有什麼差異？

A: VPC 是全球性的虛擬網路容器，Subnet 是 VPC 內特定區域的 IP 地址範圍。一個 VPC 可包含多個跨區域的 Subnet。

Q2: 為什麼 Cloud IAP 不需要外部 IP？

A: IAP 透過 Google 內部骨幹網路建立 HTTPS 隧道，流量不經過公開網際網路，因此 VM 無需暴露公開 IP。

Q3: 防火牆規則的優先權如何運作？

A: 數字越小優先權越高。當多條規則匹配時，GCP 使用優先權最高（數字最小）的規則。建議保留 0-999 給緊急阻擋規則。

Q4: Auto Mode VPC 可以轉換成 Custom Mode 嗎？

A: 可以，但轉換是單向且不可逆的。使用 gcloud compute networks update VPC_NAME --switch-to-custom-subnet-mode 指令即可轉換（VPC_NAME 替換為實際網路名稱）。

Q5: 如何監控防火牆規則是否被使用？

A: 使用 Firewall Insights 功能，可自動識別一段時間內(預設約數週)沒有任何流量打中的規則，建議定期清理。

Q6: GCP VPC vs AWS VPC 的主要差異是什麼？

A: GCP VPC 是全球資源可跨多個 Region,Subnet 是區域資源可跨同 Region 內的多個 Zone。AWS VPC 是區域資源，Subnet 僅限單一可用區。GCP 設計更適合全球化應用。

Q7: IAP TCP forwarding 防火牆如何設定？

A: 必須允許來源 IP 範圍 35.235.240.0/20 的 TCP 連線到目標 VM 的相關連接埠（如 SSH 的 22），並使用 --target-tags 或 --target-service-accounts 指定套用對象。

Q8: OS Login 是什麼？

A: OS Login 是 GCP 的 IAM 整合 SSH 功能，使用 Google 帳號認證取代傳統 SSH 金鑰，支援雙因素認證與完整稽核追蹤。

---

ACE 考試重點整理

必背知識點

1. GCP VPC 是全球資源，Subnet 是區域資源——跟 AWS 不同
2. 防火牆規則 Priority 越小越優先（0-65535），同 Priority 時 DENY 優先
3. 預設 Ingress 全擋、Egress 全放
4. Cloud IAP 是零信任 SSH/RDP 連線，需允許 35.235.240.0/20
5. Private Google Access 讓無外部 IP 的 VM 存取 Google API
6. VPC 是免費的，流量才收費（Egress）

常見陷阱題

Q：Custom VPC 可以改成 Auto Mode 嗎？ A：不行。Auto Mode 可以轉 Custom（單向不可逆），但 Custom 不能轉回 Auto。

Q：兩條防火牆規則，一條 ALLOW tcp:80 priority 1000，一條 DENY tcp:80 priority 1000，結果是？ A：DENY。同 Priority 時 DENY 優先於 ALLOW。

Q：VM 沒有外部 IP，但需要存取 Cloud Storage API，怎麼做？ A：在 Subnet 上啟用 Private Google Access。

---

下一課 GCP-105：GCP IAM 完全指南——身分管理與存取控制，學習 ACE 考試出題率最高的核心主題。