L3/L4 Anti-DDoS 是什麼？企業 BGP 流量清洗、Anycast 與乾淨流量交付完整解析

L3/L4 Anti-DDoS 保護的是網路層與傳輸層，主要觀察 IP、協定、來源分布、封包速率、連線狀態及 TCP/UDP 行為。常見攻擊包含 UDP Flood、ICMP Flood、SYN Flood、SYN-ACK Reflection、DNS Flood，以及利用公開服務進行的反射放大攻擊。這類攻擊的目的通常是耗盡線路頻寬、路由器、防火牆、負載平衡器或伺服器的連線資源。

L7 攻擊則針對 HTTP、HTTPS、登入、搜尋、API 或特定應用邏輯。它可能只使用不大的頻寬，卻讓後端 CPU、資料庫或應用執行緒耗盡。因此，L3/L4 Anti-DDoS 不能取代 CDN、WAF、Rate Limiting、Bot Management 或應用程式安全；同樣地，只有 WAF 也無法解決上游 Internet 線路被打滿的問題。

部署 FortiGate、Palo Alto、Cisco、Juniper 或其他高階防火牆，不代表企業已經具備上游 DDoS 清洗能力。防火牆位於 Internet 線路之後；如果企業申請的是 1 Gbps 線路，攻擊流量只要在上游形成數十或數百 Gbps，線路會先壅塞，防火牆根本收不到可處理的正常流量。

即使攻擊沒有完全塞滿線路，大量半開 TCP 連線、亂序封包或高 PPS 小封包仍可能耗盡防火牆 Session Table、CPU 或介面封包處理能力。企業端設備仍然重要，但它更適合執行邊界政策、存取控制、VPN 與應用辨識；大規模 L3/L4 攻擊則需要在具有足夠網路容量的上游平台先處理。

一個可運作的 L3/L4 Anti-DDoS 架構，不只是「把攻擊擋掉」，而是要讓合法封包仍能穩定到達原始服務。從 Internet 到企業端，大致會經過以下流程：

BGP 決定 Internet 如何找到企業的公開網段。當受保護 Prefix 經由防護平台公告，全球入站封包會先走向清洗網路；Anycast 則讓同一服務入口分布在多個網路節點，由路由條件決定流量從哪裡進入。攻擊因此可以在更接近來源的位置被分散承接，而不是全部集中到企業所在機房。

IPv4 在全球 Internet 上通常以 /24 作為可被廣泛接受的最小公告單位，因此使用自有網段導入時，需先確認 Prefix 長度、ASN、路由授權與現有上游政策。若只有單一 IP 或小於 /24 的網段，不能假設能直接使用相同的 BGP 導入方式，必須改以供應商 IP、反向代理、NAT 或其他交付模式評估。

防護平台完成封包判斷後，仍需要一條可控且可監測的交付路徑。常見方式包括 GRE、IPsec、機房 Cross Connect、私有網路互連或電信 last mile。GRE 架構較單純但本身不提供加密；IPsec 提供加密與來源驗證，但需要處理 IKE、金鑰、MTU、反重放及設備相容性。機房互連通常能提供更穩定的容量與延遲，但會增加端口及 Cross Connect 成本。

企業級設計不應只有一條 Tunnel 或一個 BGP Session。雙路由器、雙 Session、不同交付節點、Tunnel Health Check 與路由優先級，會直接影響單一路徑故障時能否維持服務。這也是為什麼採購時不能只問「能擋多少 Gbps」，還要確認乾淨流量如何交付。

自動緩解系統通常以 Managed Rules、流量特徵、速率與正常基線判斷攻擊。企業上線初期應先觀察平日流量、尖峰時段、協定分布、封包大小與合法高流量事件，再決定敏感度及特殊例外。門檻過鬆可能讓攻擊流量通過，門檻過緊則可能影響促銷、版本更新、備份同步或大量合法連線。

真正可維運的服務還應提供事件時間、攻擊向量、峰值 bps、峰值 pps、來源分布、被攻擊 Prefix 與目的端口。這些資訊不只用來證明有擋到攻擊，也用來檢查容量是否足夠、規則是否需要調整，以及企業端是否仍有其他瓶頸。

只要企業直接營運公開 IP 服務，而且中斷會造成營收、客訴、交易失敗或營運停擺，就應評估網路層防護。特別是遊戲平台、IDC、VPS、主機代管、金融 API、VPN、DNS、SaaS、跨境電商、直播、票務及對外提供 TCP/UDP 服務的企業。

評估時應先盤點 ASN、Prefix、平時與尖峰正常流量、封包速率、主要協定、服務所在機房、可接受中斷時間及既有上游。Server Plus Anti-DDoS 採用 Cloudflare Magic Transit 防護架構，提供 BGP Prefix 防護、全球 Anycast 緩解與台灣在地乾淨流量交付規劃。

在簽約與排定切換前，至少要完成下列確認，才能避免防護平台上線後才發現路由、MTU 或交付容量不符合需求。