隆重推出 WARP Connector：為實現任意連線鋪平道路

在不斷發展的企業安全領域，CISO 和 CIO 必須孜孜不倦地構建新的企業網路並維護舊的網路，以實現高效能的任意連線性。對於他們的網路架構師團隊來說，調查自己的環境以跟上不斷變化的需求是工作的一半，另一半通常是發掘可以無縫整合到現有環境中的創新解決方案。為追求安全、靈活的基礎架構而進行這樣的持續建設和強化，正是 Cloudflare 的 SASE 產品 Cloudflare One 的目的所在。

Cloudflare One 根據客戶和分析師的意見反應不斷改進。今天，我們很高興向公眾推出 Cloudflare WARP Connector，這是一種新工具，可以更輕鬆地確保雙向、網站到網站和網狀連線的安全性，而無需對現有網路基礎架構進行任何破壞性變更。

Cloudflare 始終致力於提供廣泛的產品，並承認網路連線沒有一體適用的解決方案。我們的願景很簡單：以您想要的任何方式實現任意連線。

在 WARP Connector 出現之前，將您的基礎架構連接到 Cloudflare 的最簡單方法之一（無論是本機 HTTP 伺服器、由 Kubernetes 叢集提供的 Web 服務還是私有網路段）是透過 Cloudflare Tunnel 應用程式連接器 cloudflared。在許多情況下，這種方法效果很好，但隨著時間的推移，客戶開始發現一系列基於 cloudflared 底層架構無法支援的使用案例。這包括客戶使用 VOIP 電話的情況，需要 SIP 伺服器與使用者的軟體電話建立傳出連線，或者需要 CI/CD 伺服器向 CI/CD 管道每個階段的相關利益相關者傳送通知。稍後，我們將在這篇部落格文章中詳細探討這些使用案例。

作為 OSI 模型第 4 層的 cloudflared 代理，其設計專門針對代理對原始服務的請求進行了最佳化——它並非設計作為處理源自原始服務之請求的主動接聽程式。這種設計權衡意味著 cloudflared 需要將其代理到應用程式伺服器的所有請求都進行來源 NAT。對於客戶無需更新路由表即可在其原始服務前面部署 cloudflared 的情況，這種設定非常方便。但是，這也意味著客戶無法看到傳送請求的用戶端的真實來源 IP。這在網路防火牆記錄所有網路流量的情況下很重要，因為所有請求的來源 IP 都將是 cloudflared 的 IP 位址，導致客戶無法看到真正的用戶端來源。

為了解決這個問題，我們確定了兩個潛在的解決方案：從頭開始構建新的連接器，或者借用現有的連接器，可能是 cloudflared 或 WARP。

下表概述了兩種方法的權衡取捨：

功能

Features	Build in cloudflared	Borrow from WARP
Bidirectional traffic flows	As described in the earlier section, limitations of Layer 4 proxying.	This does proxying at  Layer 3, because of which it can act as default gateway for that subnet, enabling it to support traffic flows from both directions.
User experience	For Cloudflare One customers, they have to work with two distinct products (cloudflared and WARP) to connect their services and users.	For Cloudflare One customers, they just have to get familiar with a single product to connect their users as well as their networks.
Site-to-site connectivity between branches, data centers (on-premise and cloud) and headquarters.	Not recommended	For sites where running  agents on each device is not feasible, this could easily connect the sites to users running WARP clients in other sites/branches/data centers. This would work seamlessly where the underlying tunnels are all the same.
Visibility into true source IP	It does source NATting.	Since it acts as the default gateway, it preserves the true source IP address for any traffic flow.
High availability	Inherently reliable by design and supports replicas for failover scenarios.	Reliability specifications are very different for a default gateway use case vs endpoint device agent. Hence, there is opportunity to innovate here.

在 cloudflared 中建置

向 WARP 借用 

雙向流量流程

如前面部分所述，第 4 層代理的局限性。

這在第 3 層進行代理， 

因此它可以充當該子網路的預設閘道，使其能夠支援來自兩個方向的流量。

使用者體驗

對於 Cloudflare One 客戶，他們必須使用兩種不同的產品（cloudflared 和 WARP）來連接他們的服務和使用者。

對於 Cloudflare One 客戶來說，他們只需熟悉單一產品即可連接他們的使用者和網路。

分支機搆、資料中心（內部部署和雲端）和總部之間的網站到網站連線。

不推薦

對於無法在每個裝置上執行代理程式的網站，這可以輕鬆地將網站連接到在其他網站/分支機搆/資料中心執行 WARP 用戶端的使用者。當底層通道都相同時，這將無縫執行。

對真實來源 IP 的可見度

會進行來源 NAT。

由於它充當預設閘道，它會為任何流量保留真正的來源 IP 位址。

高可用性

設計本質上可靠，並支援容錯移轉場景的復本。

預設閘道使用案例與端點裝置代理程式的可靠性規範有很大不同。因此，這裡存在創新的機會。 

隆重推出 WARP Connector

從今天開始，WARP Connector 的推出開啟了新的可能性：伺服器發起的 (SIP/VoIP) 流程；網站到網站連線，連接分支機搆、總部和雲端平台；甚至使用 WARP-to-WARP 實現網狀網路。從本質上講，這個新的連接器是 warp-client 的延伸，可以充當網路內任何子網路的虛擬路由器，透過 Cloudflare 開啟/關閉流量。

透過基於 WARP 進行構建，我們能夠利用其設計，即在主機上建立虛擬網路介面，以邏輯上細分實體介面 (NIC) 來路由 IP 流量。這使我們能夠透過主機和 Cloudflare 邊緣之間維護的 WireGuard/MASQUE 通道傳送雙向流量。利用這種架構，客戶還可以獲得查看用戶端真實來源 IP 的額外好處。

WARP Connector 可以輕鬆部署在預設閘道上，無需進行任何額外的路由變更。或者，可以為需要透過 WARP Connector 路由的特定 CIDR 設定靜態路由，並且可以在預設閘道或該子網路中的每個主機上設定靜態路由。

在這裡，我們將介紹部署我們的新連接器的幾個主要理由，但請記住，此解決方案可以支援多種服務，例如 Microsoft 的 System Center Configuration Manager (SCCM)、Active Directory 伺服器更新、VOIP 和 SIP 流量，以及具有複雜 CI/CD 管道互動的開發人員工作流程。還需要注意的是，該連接器既可以與 cloudflared 和 Magic WAN 一起執行，也可以作為 Cloudflare 全球網路的獨立遠端存取和網站到網站連接器。

對於透過 VoIP 軟體服務建立音訊或視訊通話的使用者，私人網路中的 SIP 伺服器通常會使用終端使用者的最後一個已知 IP 位址來代理連線。但是，如果流量在路徑上的任何地方被代理，這通常會導致參與者僅收到部分音訊或資料訊號。使用 WARP Connector，客戶現在可以對這些服務套用精細原則以實現安全安全，從而在其 Zero Trust 架構內強化 VOIP 基礎架構。

組織的 DevOps 生態系統通常由許多部分組成，但 Jenkins 或 Teamcity 之類的 CI/CD 伺服器是所有開發活動的中心。因此，確保 CI/CD 伺服器的安全至關重要。藉助 WARP Connector 和 WARP 用戶端，組織可以保護整個 CI/CD 管道並輕鬆簡化它。

讓我們看一下 Kubernetes 應用程式的典型 CI/CD 管道。環境設定如上圖所示，開發人員和 QA 筆記型電腦上有 WARP 用戶端，WARP Connector 安全地連接不同網路上的 CI/CD 伺服器和暫存伺服器：

1. 通常，當開發人員提交其程式碼變更並叫用 CI/CD 伺服器上的 webhook 時，就會觸發 CI/CD 管道。

2. 構建影像後，就可以部署程式碼，這通常分階段進行：測試、暫存和生產。

3. 當影像在測試/暫存環境中準備就緒時，開發人員和 QA 工程師會收到通知。

4. QA 工程師透過 webhook 從 CI/CD 伺服器接收通知，以啟動監控和疑難排解工作流程。

藉助 WARP Connector，客戶可以輕鬆地將其開發人員連接到 DevOps 生態系統中的工具，同時保持生態系統的私密性，不向公眾公開。在 DevOps 生態系統安全地連接到 Cloudflare 後，可以輕鬆套用精細的安全性原則來保護對 CI/CD 管道的存取。

執行 Microsoft AD 伺服器或非 Web 應用程式伺服器的組織通常需要識別真實的來源 IP 位址以進行稽核或應用原則。如果存在這些要求，WARP Connector 可以簡化此過程，提供無需新增 NAT 邊界的解決方案。這對於限制不健康的來源 IP 位址的速率、在邊界內實施基於 ACL 的原則或從終端使用者處收集其他診斷資訊非常有用。

作為此次發佈的一部分，我們對 Cloudflare One 儀表板進行了一些變更，以更好地突出我們不同的網路開啟/關閉選項。從今天起，您的儀表板上將出現一個新的「網路」索引標簽。這將成為 Cloudflare Tunnel UI 的新主頁。

我們還在「通道」旁邊引入了新的「路由」索引標簽。此頁面將顯示客戶虛擬網路、Cloudflare Tunnel 及其相關路由的結構化檢視。這個新頁面可協助回答客戶有關其網路設定的問題，例如：「哪個 Cloudflare Tunnel 具有到我的主機 192.168.1.2 的路由」、「如果存在 CIDR 192.168.2.1/28 的路由，如何存取它」，或「我的環境中有哪些重疊的 CIDR，它們屬於哪些 VNET？」。這對於擁有非常複雜的企業網路並使用 Cloudflare 儀表板來解決連線問題的客戶非常有用。

開始您的 WARP Connector 之旅非常簡單。目前可在 Linux 主機上部署，使用者可以選擇「建立 Tunnel」，並從 cloudflared 或 WARP 中選擇，直接從儀表板進行部署。遵循我們的開發人員文件，只需幾個簡單的步驟即可開始。在不久的將來，我們將支援在更多平台上部署 WARP Connector。

感謝所有私人測試版客戶提供的寶貴意見反應。展望未來，我們未來幾季的首要任務是簡化部署、效仿 cloudflared 的部署以及透過備援和容錯移轉機制增強高可用性。

隨著我們繼續創新和增強 Cloudflare One 平台，請繼續關注更多更新。我們很期待看到我們的客戶如何利用 WARP Connector 來改變他們的連線和安全格局。