Magic Transit：Cloudflare規模的網路功能

　　Cloudflare Magic Transit，使Cloudflare的網路可被網際網路上的任意IP流量使用。到目前為止，Cloudflare主要運營代理服務：我們的伺服器終止與Internet使用者的HTTP、TCP和UDP會話，並透過與原始伺服器建立的新會話傳遞這些資料。透過Magic Transit，我們現在還在IP層進行運營：除了終止會話之外，我們的伺服器還在逐個資料包的基礎上應用一套網路功能（DoS緩解、防火牆、路由等等）。

　　

　　Magic Transit是在與上述相同的網路上使用相同的技術構建的，這意味著我們的客戶現在可以在Cloudflare規模的網路上執行他們的網路功能。我們快速、安全、可靠的全球優勢同時也成為了客戶的優勢。要弄清楚這是如何工作的，就讓我們來跟蹤一下資料包從網際網路上的使用者到Magic Transit客戶網路的旅程吧。

　　

　　讓我們的DoS緩解功能……為您服務！

　　

　　在產品釋出博文中，我們講述了Acme Corp（頂點集團）的一個部署示例。讓我們繼續講下這個例子吧。當Acme將其IP字首203.0.113.0/24提供給Cloudflare時，我們開始向全球每個資料中心的傳輸提供者、對等網路和網際網路交換機公告該字首。此外，Acme停止向自己的網路服務提供商宣告字首。這意味著網際網路上任何目標地址位於Acme字首內的IP包都將被交付給附近的Cloudflare資料中心，而不是Acme的路由器。

　　

　　假設我想從位於伊利諾伊州香檳市的Cloudflare辦公室的計算機上訪問Acme的FTP伺服器203.0.113.100。得益於任播，這個資料包最終到達了Cloudflare位於芝加哥的資料中心，這是離香檳市最近的資料中心（就網際網路路由距離而言）。資料包到達資料中心的路由器，該路由器使用ECMP（等價多路徑）路由選擇應該處理資料包的伺服器，並將資料包傳送到所選的伺服器。

　　

　　一旦到達了伺服器，資料包就會流經我們基於XDP和iptables的DoS檢測和緩解功能。如果這個TCP SYN包被確定為攻擊的一部分，它將被丟棄，傳輸就此結束。而我比較幸運，我發出的資料包透過了檢測。

　　

　　到目前為止，這看起來和Cloudflare網路上的其他流量完全一樣。由於我們有執行全球任播網路方面的專業知識，我們能夠將Magic Transit客戶的流量吸引到每個資料中心，並部署多年來用於保護Cloudflare的相同DoS緩解解決方案。我們的DoS解決方案已經處理了一些有史以來最大的網路攻擊，包括2018年942Gbps的SYN洪水。下面是最近的每秒300Mbps資料包的SYN洪水的截圖。我們的體系架構允許我們進行擴充套件從而阻止最大的攻擊。

　　用於隔離和控制的網路名稱空間

　　

　　上面的操作看起來與其他Cloudflare流量的處理方式相同，但也只有這些是相同的。對於我們的其他服務，TCP SYN包現在將被髮送到本地代理程式（例如，我們基於nginx的HTTP/S堆疊）。對於Magic Transit，我們希望動態地提供和應用客戶定義的網路功能，比如防火牆和路由。我們需要一種方法來快速啟動和配置這些網路功能，同時提供網路隔離。為此，我們轉向了網路名稱空間。

　　

　　名稱空間是一組Linux核心特性的集合，用於建立可在一組程式之間共享的系統資源的輕量級虛擬例項。名稱空間是Linux中容器化的基本構建塊。值得注意的是，Docker是基於Linux名稱空間構建的。網路名稱空間是Linux網路堆疊的一個獨立例項，包含它自己的網路介面（帶有它們自己的eBPF鉤子）、路由表、netfilter配置等等。網路名稱空間為我們提供了一種低成本的機制，可以獨立地快速應用客戶定義的網路配置，所有這些配置都具有內建的Linux核心特性，因此不會因為使用者空間包轉發或代理而影響效能。

　　

　　GRE（通用路由封裝） + 任播 = 魔法

　　

　　透過邊緣網路函式之後，TCP SYN包最終準備好被傳送回客戶的網路基礎設施。因為Acme Corp.在Cloudflare的託管設施中沒有網路佔用，所以我們需要透過公共網際網路交付它們的網路流量。

　　

　　這就產生了一個問題。TCP SYN包的目標地址是203.0.113.100，但是Internet上唯一公告IP字首為203.0.113.0/24的網路是Cloudflare。這意味著我們不能簡單地把這個包轉發到網際網路上——它會直接給我們帶來不良後果！為了將這個包交付給Acme，我們需要使用一種稱為隧道的技術。

　　

　　隧道是將流量從一個網路傳輸到另一個網路的一種方法。在我們的例子中，它涉及到將Acme的IP包封裝在可以透過網際網路交付給Acme路由器的IP包中。有許多常見的隧道協議，但我們通常使用的是通用路由封裝（GRE），因其簡單性和受到廣泛的供應商支援。

　　

　　GRE隧道端點配置在Cloudflare的伺服器（在Acme的網路名稱空間內）以及Acme的路由器上。然後，Cloudflare伺服器將傳送到203.0.113.0/24的IP包封裝在傳送到Acme路由器的可公開路由IP地址的IP包中，該路由器將這些包解密並將其傳送到Acme的內部網路。

　　現在，我在上面的圖表中省略了一個重要的細節：Cloudflare在GRE隧道一側的IP地址。配置GRE隧道需要為每邊指定一個IP地址，而透過隧道傳送的資料包的外部IP請求頭必須使用這些特定的地址。但是Cloudflare有數千臺伺服器，每臺伺服器都可能需要透過隧道向客戶交付資料包。那麼客戶需要與多少Cloudflare IP地址（和GRE隧道）進行通訊呢？答案：只有一個，多虧了任播的魔力。

　　

　　Cloudflare為我們的GRE隧道端點使用任播IP地址，這意味著任意資料中心中的任意伺服器都能夠為同一個GRE隧道封裝和解封資料包。這怎麼可能呢？隧道不是點對點的連結的嗎？GRE協議本身是無狀態的——每個資料包都是獨立處理的，不需要在隧道端點之間進行任何協商或協調。雖然隧道在技術上是繫結到一個IP地址的，但它不需要繫結到特定的裝置。任何可以剝離外部請求頭然後路由內部資料包的裝置都可以處理透過隧道傳送的任意GRE資料包。實際上，在任播背景中，術語“隧道”具有誤導性，因為它字面上意味著兩個定點之間的連結。藉助Cloudflare的Anycast GRE（任播通用路由封裝），一個“隧道”可以為Cloudflare全球邊緣網路上的每個資料中心的每臺伺服器提供一個通道。

　　Anycast GRE的一個非常強大的作用是它消除了單點故障。傳統上，GRE-over-Internet可能存在問題，因為兩個GRE端點之間的一次網際網路中斷會完全破壞“隧道”。這意味著可靠的資料傳輸需要經歷令人頭疼的問題，即建立和維護端點位於不同物理站點的冗長的GRE隧道，並在其中一個隧道中斷時重新路由流量。但是，由於Cloudflare從每個資料中心的每個伺服器封裝和交付來自的客戶流量，因此不會遇到僅有的單條“隧道”被破壞的問題。這意味著Magic Transit的客戶可以享受在多個物理站點的終端隧道的冗餘和可靠性，同時只需要設定和維護一個GRE端點，從而使他們的工作更簡單。

　　

　　我們的規模現在也是您的規模

　　

　　Magic Transit是一種強大的大規模部署網路功能的新方法。我們不只是給你一個虛擬例項，我們會給你一個全球虛擬邊緣網路。Magic Transit採用您通常在本地網路中安裝的硬體裝置，並將它們分佈在Cloudflare網路中的每個資料中心的每個伺服器上。這使您可以訪問我們的全球任播網路，使用我們的伺服器群執行您的任務，以及藉助我們的工程專業知識，構建快速、可靠、安全的網路。我們的規模就是你們的規模。