假設你有一個 VM,你想要讓外面的人可以直接連到這個 VM 的某個 port (通訊埠), 但你又希望有一些網路層的設定或保護。

這時候你就可以用「通訊協定轉送」這個功能。它的作用就是把外部進來的網路流量,按照你設定的規則,轉送到指定的 VM 上面。

目標執行個體 (Target Instance)

當你設定通訊協定轉送的時候, 你需要告訴 GCP「我要把流量轉送到哪裡去」。這個「哪裡」就是你指定的一個 VM 執行個體, 而這個被指定的 VM 在這個情境下就被稱為「目標執行個體」。簡單說, 目標執行個體就是「流量最終要送達的那台 VM」。

假設你有一台 VM 上面跑著一個遊戲伺服器, 這個遊戲使用特殊的網路協定, 不是常見的 HTTP 或 HTTPS。你想要讓玩家可以從網路上連進來,但又想要有一些流量控制。

這時候你就可以設定「通訊協定轉送」,把外部進來的遊戲協定流量轉送到你的 VM 上。在這個設定中,你的這台遊戲伺服器 VM 就是「目標執行個體」。

到底通訊協定轉送長什麼樣子？

「通訊協定轉送」不是一台 VM,它是一個「網路規則」或「轉送設定」。這個轉送設定會指向一台 VM (也就是目標執行個體), 流量是從外部先到這個轉送規則,然後再被轉送到你指定的 VM 上。

用更簡單的比喻:通訊協定轉送就像是一個「郵局轉信服務」。你告訴 GCP「寄到地址 A 的信,都轉寄到地址 B」,這裡地址 B 就是你的 VM(目標執行個體),而這個轉信規則本身就是「通訊協定轉送」。整個過程只有一台 VM,不是兩台。

另一個常見的情況是企業的 VPN 服務。

VPN 通常會用 ESP(一種加密協定)或特定的 TCP/UDP port,這些都不是標準的網頁流量。如果你想在 GCP 上建立 VPN Server,就必須透過 Protocol Forwarding 來接收這些特殊協定的連線。

此外,像是資料庫的直接連線、串流媒體伺服器、或者物聯網裝置的通訊,只要不是走 HTTP/HTTPS,基本上都可能需要用到這個功能。

與其他方案的差異

難道 TCP Proxy LB 或 Network LB 做不到嗎?它們不是針對 「不是 HTTP/HTTPS 的流量」嗎?

Load Balancer 的本質功能

首先要理解,TCP Proxy Load Balancer 和 Network Load Balancer 的核心目的是「負載平衡」。什麼意思呢?就是當你有多台伺服器在背後提供相同的服務時,Load Balancer 會把進來的流量「分散」到這些伺服器上,避免某台伺服器累死、其他伺服器卻閒著。這就像是一個餐廳有多個櫃台,門口的帶位人員會引導客人到比較空的櫃台去排隊。

這些 Load Balancer 雖然可以處理 TCP、UDP 等協定,但它們會「介入」流量的處理。TCP Proxy Load Balancer 會終止(terminate)連線,也就是說,客戶端先連到 Load Balancer,然後 Load Balancer 再重新建立一條新的連線到後端伺服器。Network Load Balancer 雖然是 passthrough 模式,但它仍然會進行流量的檢查和分配,並且需要配置 backend service 和 health check 等複雜的設定。

Protocol Forwarding 的簡單直接

相比之下,Protocol Forwarding 就單純多了。它不做負載平衡,不需要 backend service,也不會終止或檢查你的連線內容。它就像是一個「純粹的轉接頭」,把特定 IP 和 port 收到的流量,直接原封不動地送到指定的目標。這個目標可以是單一台 VM instance,也可以是一組 target pool(但 target pool 的分配邏輯比 Load Balancer 簡單很多)。

這種設計在某些情況下反而是優勢。比如說,你只有一台伺服器,根本不需要負載平衡的功能,只是想要一個固定的外部 IP 位址來接收特定協定的流量。這時候用 Load Balancer 就太複雜了,還要設定一堆用不到的功能。或者,你的應用程式本身對連線非常敏感,不希望中間有任何「代理」介入,Protocol Forwarding 的直接轉送特性就很重要。

實際場景的選擇

再舉個具體例子:假設你要架設一個 IPsec VPN Server。VPN 連線通常使用 ESP(IP Protocol 50)或特定的 UDP port,而且連線的狀態非常重要。如果用 TCP Proxy Load Balancer,它會終止連線並重建,這可能會破壞 VPN 協定的運作。如果用 Network Load Balancer,雖然可以運作,但你需要設定 health check、backend service 等,而且如果你只有一台 VPN Server,這些設定都是多餘的。

這時候 Protocol Forwarding 就很適合,你只需要建立一個 Forwarding Rule,指定「所有到這個 IP 的 ESP 協定流量都轉送到我的 VPN Server」,就完成了。設定簡單,流量處理也最直接。當然,如果你後來需要多台 VPN Server 並做負載平衡,那時候再改用 Network Load Balancer 也不遲。

總結差異

所以簡單來說,TCP Proxy Load Balancer 和 Network Load Balancer 確實可以處理非 HTTP/HTTPS 流量,但它們是為了「多台伺服器的負載分配」而設計的,功能複雜、設定繁瑣。Protocol Forwarding 則是為了「單純的流量轉送」,當你不需要負載平衡,只想要一個乾淨、直接的流量入口時,它就是最佳選擇。這就是為什麼 GCP 會同時提供這些不同的方案,讓使用者根據實際需求來選擇最適合的工具。

你可能會想,為什麼不直接讓伺服器對外開放就好?

確實可以這樣做,但 Protocol Forwarding 提供了一層額外的管理和保護。

透過 Forwarding Rule(轉送規則),你可以統一管理哪些 IP 位址和 port 可以接收流量,而不需要在每台伺服器上個別設定防火牆規則。這樣的架構讓你的網路設計更有彈性,也更容易維護。

為什麼保護 Protocol Forwarding 有保護的功能？

Forwarding Rule 本身並不是用來「阻擋」流量的,它比較像是「開通一條路」。當你建立一個 Forwarding Rule,你是在說「我要讓這個 External IP 的這個 port(或協定)可以接收流量,並且把這些流量轉送到指定的目標」。但這不代表「沒有設定 Forwarding Rule 的 port 就會被擋下來」,因為 Forwarding Rule 根本不管其他 port 的事。

舉個例子來說明:假設你有一台 VM,它的內部 IP 是 10.0.0.5。你申請了一個 External IP 是 34.80.0.100,然後建立一個 Forwarding Rule,把 34.80.0.100:8080 的流量轉送到 10.0.0.5:8080。這時候,外面的人可以透過 34.80.0.100:8080 連到你的 VM。但如果有人試圖連 34.80.0.100:3306(假設你沒設定這個 port 的 Forwarding Rule),會發生什麼事呢?

防火牆規則才是真正的守門員

答案是:這個連線會失敗,但不是因為 Forwarding Rule 擋住它,而是因為根本就「沒有路可以通」。

Forwarding Rule 只負責「有設定的 port」,沒設定的 port 就不會被轉送,流量會直接被丟棄或回應連線失敗。從這個角度來看,Forwarding Rule 確實有「只開放特定 port」的效果,但它的本質是「開通」而不是「防禦」。

真正的防火牆功能還是要靠 Firewall Rules 來做。Firewall Rules 才是那個會主動「檢查」並「決定要不要放行」的機制。

即使你設定了 Forwarding Rule 把流量轉到 VM,如果 VM 的 Firewall Rules 沒有允許那個 port,流量還是會被擋下來。

所以完整的流程是:

External IP 的流量 → Forwarding Rule 決定要不要轉送 → Firewall Rules 決定要不要放行 → 最後才到達 VM。

兩者的互補關係

所以正確的理解應該是:Forwarding Rule 是「入口管理」,它決定哪些流量可以進入你的 GCP 架構;Firewall Rules 是「存取控制」,它決定流量能不能到達特定的資源。

兩者是互補的,不是替代的關係。Forwarding Rule 確實讓你不用在每台伺服器上都開放對外 port,但你還是需要 Firewall Rules 來做更細緻的安全控制。這樣的設計讓你的網路架構既有彈性,又有足夠的安全保護。

以下整理一張完整的功能比較表,讓你能清楚看出這四種方案的差異。

GCP 流量轉送方案功能比較表

表格重點說明

這張表格從上到下,逐漸從「功能豐富但複雜」走向「功能簡單但直接」。Application Load Balancer 功能最完整,可以看懂 HTTP 內容並根據網址或 Header 來分配流量,但也最複雜。TCP Proxy Load Balancer 則退一步,不看內容,只處理 TCP 連線,但仍保有全球負載平衡的能力。

Network Load Balancer 更進一步簡化,它是 passthrough 模式,不會終止連線,所以效能最好,但只能在單一區域內運作。最後的 Protocol Forwarding 則是最純粹的,它幾乎不做任何處理,就是把流量轉過去而已,所以設定最簡單,適合那些「我只想要一個入口」的需求。

選擇哪一種方案,關鍵在於你的需求:如果需要根據內容智慧分配流量,選 ALB;如果需要全球分布的 TCP 服務,選 TCP Proxy LB;如果需要高效能且保留原始 IP,選 Network LB;如果只是簡單轉送不需要複雜功能,選 Protocol Forwarding。這樣的設計讓你可以根據實際情況,選擇最符合成本效益的方案。

詳細介紹可以參考通訊協定轉送總覽，設定方法可以參考設定通訊協定轉送。

關於更多 GCP 負載平衡的概念和實作教學，都在東東的 GCP 線上課程《雲端架構師養成班》，有需要可以進來看喔！

The post 通訊協定轉送 (Protocol Forwarding) 是什麼？何時會用到？ first appeared on 東東 GCP 教學 - GCP 實戰講師.