GCP國際帳號代理 GCP子網路由表自定義配置教程：實現多網卡實例策略路由與流量轉發

谷歌雲GCP / 2026-09-04 15:17:30

前言：為什麼需要自定義子網路由

很多人第一次用 GCP，會依賴「系統預設路由」：子網會自動把目的地交給合適的下一跳，網路看起來就能跑起來。但一旦你進入更複雜的場景，例如多網卡（multi-NIC）主機、同時連接多個出口、需要依「來源地址/應用/目的類別」做差異化轉發，預設路由往往不夠準確。你會遇到下列典型問題：

第一，流量從 A 子網進來，應該走 B 出口的策略，卻被系統預設路由導到另一條路。第二，回程路由不一致，導致會話被對端丟棄或出現不對稱路徑。第三，你需要把某些服務流量導向特定防火牆/代理/網關，但卻無法只靠目的網段靜態匹配。解法通常是「網路層自定義路由表 + 主機層策略路由（PBR）」的組合。

本文聚焦在 GCP 子網路由表（Route）自定義配置，並以多網卡實例策略路由與流量轉發為主線，給出可落地的設計思路與步驟。你會看到：怎麼建路由、怎麼讓 GCP 把流量交給正確下一跳，接著如何在 Linux 內對不同流量做標記與選路，最後如何驗證與排錯。

目標與架構：多網卡實例 + 兩段網路策略

我們假設一個常見需求：同一台 VM 需要同時連到兩個子網（兩張 NIC），分別代表「內網側」與「外網側」。此外，對不同目的網段或不同來源（例如特定服務），要走不同出口，甚至要經過不同的轉發節點。

可用的架構抽象如下：

VPC 內有兩個子網：subnet-a（例如 10.10.0.0/24）與 subnet-b（例如 10.20.0.0/24）。
一台路由/轉發主機或業務主機（VM）掛兩張網卡：eth0 在 subnet-a，eth1 在 subnet-b。
你希望：來自 subnet-a 的特定目的（或特定流量）走 eth1；其他流量走預設路徑。
GCP國際帳號代理 更進階時，你可能把「下一跳」指到某台防火牆/轉送器（可在 GCP 內，也可在互連網段/HA VPN/Interconnect 背後）。

在 GCP 端，我們會用路由表定義「目的地網段 → 下一跳」。在 VM 端，我們再用策略路由把不同流量導向不同的網卡或下一跳，確保封包的來源/回程符合預期。

第一部分：GCP 子網路由表的基礎與關鍵概念

路由表是什麼：從目標網段匹配到下一跳

在 GCP VPC 中，路由會依「目的 IP」匹配，然後選擇下一跳：

GCP國際帳號代理 目的地（Destination range）：例如 0.0.0.0/0 或特定網段。
下一跳（Next hop）：下一跳是 GCP 內的資源（下一跳 VM 的 IP）或互連設定。
優先序（Priority）：相同目的網段更細或優先序更高的路由會被選用。
適用範圍（Tags / Service accounts / Directions 等概念）：通常用 Network tags 或 service account 讓路由僅套用到某些 VM。

你要做到策略路由，並不是一定要在 GCP 端做到所有精細控制；GCP 端負責把流量「交給正確的下一段路徑」，VM 端再把「同一方向但不同流」分流。

重要：路由不等於連通性，防火牆先看清

很多人把「路由沒命中」當成根因，但實際上是防火牆擋掉了。

GCP國際帳號代理 在 GCP 中，連通性大致要同時滿足：

路由能把封包送到下一跳。
該下一跳/目標 VM 的防火牆規則允許入站。
來源方向也要符合（若你有複雜轉發，還需要注意回程和 NAT/轉發的規則）。

若你做的是轉發主機，還要確保 Linux IP forwarding 打開，並且防火牆策略不阻擋轉發。

理解 Priority：同網段多條路由時誰說了算

自定義路由很容易被預設路由或其他自定義路由蓋過。原則是：

目的網段更精確（更長的前綴）通常會優先匹配。
若前綴相同或競爭條件，priority 值影響選擇。

因此建議你在設計時就把路由命名、priority、目的網段層級想清楚，否則排查會很痛苦。

第二部分：在 GCP 建立自訂路由（Route）

規劃：你要把哪些流量導到哪個下一跳

以我們的目標為例，假設 VM 的 eth0 在 subnet-a，eth1 在 subnet-b。你希望：

對某些目的網段（例如 172.16.50.0/24，代表一個特定後端），流量從 subnet-a 進來時要導向下一跳（下一跳可以就是這台雙網卡 VM 的其中一個介面 IP，或指向一台轉發器 VM）。
對其他網段採用預設系統路由。

在 GCP 路由中，這通常意味著你會在某個路由表（實際上 Route 是在 VPC 層級存在、但可用 network tags/service accounts 讓其對應子網內 VM）增加一條目的網段特定的路由。

更常見做法是：讓「來源 VM」使用 tags，然後讓路由只對這些 tags 生效，避免影響整個網段。

實作：建立自訂路由的步驟（概念流程）

在 GCP Console 或透過指令建立 Route，核心參數通常包括：

Route name：例如 route-to-backend-via-forwarder
Network：你的 VPC 名稱
Destinations：例如 172.16.50.0/24
Next hop：例如 forwarder VM 在該網路的 IP
Priority：例如 1000 或更小值（依你的設計）
Applied to：使用 Network tags 讓路由僅套用到指定 VM

實務上我建議你先用較寬的目的網段驗證，確定封包會走你預期的下一跳，再逐步收窄目的範圍與條件。否則你會遇到「路由看似建立了但沒有命中」的情況，排查門檻會很高。

下一跳選擇：直接指到 VM 還是指到下一台轉發器

當你用雙網卡 VM 做轉發，有兩種模式：

模式 A：把下一跳指到轉發器 VM。源端 VM 封包先到轉發器，再由轉發器內部決定送到 eth0 或 eth1。
模式 B：直接在源端用多條 GCP 路由把封包送到不同網段。這需要你的目的網段與下一跳映射足夠清楚，否則就要爆炸性增加路由。

GCP國際帳號代理 策略路由通常選模式 A，因為它把複雜度下放到主機層，容易做更精細的條件分流。

第三部分：在雙網卡 VM 上做策略路由（PBR）與流量轉發

路由表讓「封包先到哪」更可控，但要做到多網卡實例的精準選路，你仍需要在 VM 的 OS 層完成策略路由。下面以 Linux 為例，因為它對 netfilter、ip rule、ip route 這套能力支援完善。

準備：開啟 IP forwarding 並理解 rp_filter

如果你的 VM 充當路由器/轉發器，必須開啟：

net.ipv4.ip_forward=1

接著你要注意反向路徑過濾（rp_filter）。在多來源、多介面場景，rp_filter 有時會因為看到「封包回程不在預期介面」而丟棄。建議你在測試期把 rp_filter 設為宽松模式，或對特定介面調整。

實際值你可以依環境調整，但核心思路是：當你做不對稱或策略路由時，rp_filter 不能成為你成功的隱形敵人。

建立基礎路由表：主表（main）與自定義表（例如 100、101）

Linux 的策略路由核心在「多路由表 + ip rule 決定走哪張表」。流程通常如下：

主路由表（main）：保持系統預設或你基本需求的路由。
自訂路由表（如 table 100、101）：存放你希望從特定來源/標記走向不同下一跳或不同介面。

比如：

table 100：優先把流量送到 eth1（對應 subnet-b 的出口）。
table 101：優先把流量送到 eth0（對應 subnet-a 的出口）。

用 fwmark/ip rule 做分流：把「你要選的流」標記起來

策略路由最常用做法是：

先在 netfilter（iptables/nftables）對封包打標記（mark）。
再用 ip rule 依 mark 選擇路由表。

為什麼要這樣？因為你在 OS 層可以依據：

來源/目的 IP
來源/目的埠
應用層協定（透過端口/協定推斷）
網卡入站介面（iif）

來做比「只有目的網段」更細的判斷。這能把策略路由的可控性大幅提升。

一個可落地的策略：依目的網段導向不同介面

假設你要把目的網段 172.16.50.0/24 的流量導向 eth1。可用的思路：

GCP國際帳號代理 在 PREROUTING（mangle 表）將這個目的網段的封包 mark 為 0x64。
用 ip rule：fwmark 0x64 → 使用 table 100。
在 table 100 的路由中，把 172.16.50.0/24 指向你希望的下一跳或出口。

接著你再處理回程：回到 table 100 選路後，源地址與介面要合理，否則對端可能覺得你「不是從它以為的那個地方回來」。

第四部分：把 GCP 路由與 OS 策略路由對齊，避免不對稱與黑洞

很多「看起來路由都有配但就是通不了」的問題，根因通常不是單一設定錯，而是兩層路由不一致。你需要確保三件事：

封包到達轉發器的方向正確（GCP 路由表）。
轉發器在入站後對目標的選路正確（OS 策略路由）。
回程路由在對端視角成立（源地址、SNAT/回程表、以及可能的 rp_filter）。

回程路由一致性：來源地址與 NAT 是策略的一部分

在多網卡 VM 轉發時，最常見的「成功發出但對方回不來」原因是來源地址選擇不一致。

假設：

你從 eth1 對外送包，但封包的 source IP 仍是 eth0 的地址，對端可能會根據路由或安全策略把回程送錯地方。
或你在出站需要 SNAT，但 OS 沒有做。

因此你需要明確你的「對外顯示的來源」應該是誰：

如果你希望對端看到的是 subnet-b 的地址，那就要讓出站封包的 source IP 對應到 eth1。
如果你要用虛擬 IP 或節點地址，那就需要 NAT（多半在轉發器上做）讓源/目的符合設計。

策略路由能控制走哪張路，但來源地址的選擇有時仍依 kernel 的選擇規則。你要用 ip rule 或更進階的 SNAT/route cache 調整，確保「走 eth1 → 出口源地址也屬於 eth1 的網段」。

在 GCP 端避免「路由交給錯的下一跳」

你可能已經在 VM 端做好策略，但若 GCP 把封包導到另一台不該承接的轉發器，你在 VM 裡做任何 PBR 都不會生效。驗證路由命中很重要。

你可以用 VPC flow logs 觀察封包進出，並以 tcpdump 或 traceroute（有時 UDP/TCP 封包選擇會影響）確認實際路徑。若流量完全不到 VM，那就回頭看 GCP route 的：

目的網段是否正確
GCP國際帳號代理 路由是否被 tags/service account 正確套用
priority 與系統路由是否競爭

第五部分：策略路由與轉發的完整流程（從零到通）

步驟 1：確定網路介面與靜態資訊

先在 VM 上確認：

eth0/eth1 對應的 IP
預設路由與現有路由表
你要用的目標網段

你需要一致的介面命名和 IP，以免 ip rule 綁定條件時失效。

步驟 2：在 VM 建立自訂路由表

你至少需要一張「走 eth1」的路由表，以及一張「走 eth0」的路由表（若雙向需求）。在每張表中加入必要目的網段路由。

如果你的下一跳在 GCP 內是某台 VM 或虛擬網關，下一跳 IP 也要能在對應子網內被 ARP/路由解析到。

步驟 3：用 ip rule 決定走哪張表

用條件（fwmark 或者 from/to）建立 rule。例如：

如果目標是特定網段 → 用 table 100（走 eth1）。
如果來源在某個網段/服務 → 用 table 101。

這裡的條件你可以從簡到繁。先用最粗粒度（目的網段）通了，再把規則精細化到端口或應用。

步驟 4：必要時用 nftables/iptables 做封包標記與 SNAT

若你用 fwmark 模式，就需要在 mangle 表打 mark。

若你的策略要求來源地址固定為某個介面網段，就要做 SNAT。注意 SNAT 的規則要綁定到你預期走哪個出口，避免把不該被翻譯的流也一起翻了。

步驟 5：在 GCP 建立或調整自訂路由，讓封包先到轉發器

此時你要回到 GCP，確認封包確實被送到轉發器 VM，而不是被路由表導到預設出口。

特別是當你的轉發器本身也在特定子網內時，路由表要注意來源範圍與適用條件（tags/service account）。你也要確保沒有其它更優先的 route 抢走流量。

步驟 6：驗證方法（不要只看「能不能 ping」）

驗證建議分三層：

GCP國際帳號代理 路由是否命中：用 tcpdump/ss/conntrack 觀察封包出入介面，並確認目的網段的封包走的是你定義的出口。
策略是否生效：檢查 ip rule 命中、mark 統計（可用工具或規則計數器）。
回程是否正常：抓對端回包或觀察 flow logs，確認對端回流到正確來源。

在排錯上，ping 有時會誤導你：它只是一種 ICMP，對應用流量（TCP/UDP）可能走不同策略或被防火牆允許/拒絕。

第六部分：常見錯誤與對策

錯誤 1：路由有命中，但防火牆擋住轉發

如果你在轉發器上做了 IP forwarding，但 GCP 防火牆沒有允許入站/出站，就會出現「進來了但轉不出去」的情況。

對策：明確允許轉發器 VM 兩個介面所需的入站，並允許到下一跳目標的出站（或讓下一跳處於同一安全域）。同時檢查是否有基於標籤的規則未套用。

錯誤 2：不對稱路徑導致會話被對端拒絕

你可能看到一段時間「出站看似成功」，但對端回包被丟棄。常見原因：

source IP 不符合對端預期
回程走錯出口
GCP國際帳號代理 rp_filter 或 conntrack 狀態導致丟包

對策：確保你在策略路由中同時處理來源地址（必要時 SNAT），並在 OS 層調整 rp_filter 與適當的狀態追蹤。

錯誤 3：GCP Route 沒命中（tags/service account 不一致）

最常見的「明明建了 route 但沒效果」。通常是你把 route 的套用條件限制得太嚴，而目標 VM 的 tags/service account 沒對上。

對策：先做最小化驗證，暫時用較寬的條件（或在測試 VM 上加對應 tag），確認封包能走，再回到正式條件收斂。

錯誤 4：Priority/目的網段前綴競爭，導致走了別的路

如果你在 VPC 裡有多條目的網段路由，某條可能因為前綴更長或 priority 更高而搶走流量。

對策：在設計時把路由階層整理清楚，並在排錯時查看「最終匹配到哪條路由」。

第七部分：實務維運建議（讓你不會三天後又回來重做）

把規則命名成「可理解」而不是「可堆疊」

GCP route 的 name、Linux table id、rule id，都要對應到你的業務意圖。不要只用 generic 名稱，否則你會在未來面對多次變更時失去可追蹤性。

規則拆分：先做最低可用路徑，再加細節

我常建議你把配置拆成三層：

第一層：確保封包能到轉發器（GCP 路由命中）。
第二層：確保轉發器能依目的網段走到正確介面（OS 路由表與 ip rule）。
第三層：再加上端口/服務級標記、SNAT 精細化與例外規則。

這樣排錯時你知道問題卡在哪一層。

記錄你關鍵決策的依據：來源一致性、下一跳選擇理由

策略路由最怕「只會改，卻不知道為什麼」。你要把以下決策寫在內部文件：

為什麼目的網段 172.16.50.0/24 走 eth1
為什麼轉發器不直接由系統路由完成
SNAT 的來源是什麼、對應哪個介面

當未來你新增出口或調整子網 CIDR，這些理由能直接告訴你哪些規則要改、哪些不必動。

結語：把「網路控制權」從預設交給你

自定義子網路由表不是為了炫技，而是把流量的控制權收回來。當你需要多網卡實例策略路由與精準流量轉發時，最佳路徑通常不是只在 GCP 端堆路由，也不是只在 VM 端憑感覺調 PBR，而是把職責分清：

GCP國際帳號代理 GCP 路由表確保封包先被交給正確的承接點（轉發器/下一跳）。
Linux 策略路由確保在承接點內，封包依你的條件走正確出口與下一跳。
GCP國際帳號代理 防火牆與回程一致性確保會話能穩定建立、維持並被對端接受。

當你把這三件事對齊，你的多網卡架構就不再是「偶爾能跑」的黑盒，而是可預期、可驗證、可擴展的系統。只要按本文的方法逐層落地與驗證，你就能把路由與轉發做得像工程，而不是像賭運氣。