在不斷發展的企業安全領域，CISO 和 CIO 必須孜孜不倦地構建新的企業網路並維護舊的網路，以實現高效能的任意連線性。對於他們的網路架構師團隊來說，調查自己的環境以跟上不斷變化的需求是工作的一半，另一半通常是發掘可以無縫整合到現有環境中的創新解決方案。為追求安全、靈活的基礎架構而進行這樣的持續建設和強化，正是 Cloudflare 的 SASE 產品 Cloudflare One 的目的所在。
Cloudflare One 根據客戶和分析師的意見反應不斷改進。今天，我們很高興向公眾推出 Cloudflare WARP Connector，這是一種新工具，可以更輕鬆地確保雙向、網站到網站和網狀連線的安全性，而無需對現有網路基礎架構進行任何破壞性變更。
彌合 Cloudflare Zero Trust 故事中的缺口
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。
下表概述了兩種方法的權衡取捨：
功能
在 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 伺服器
對於透過 VoIP 軟體服務建立音訊或視訊通話的使用者，私人網路中的 SIP 伺服器通常會使用終端使用者的最後一個已知 IP 位址來代理連線。但是，如果流量在路徑上的任何地方被代理，這通常會導致參與者僅收到部分音訊或資料訊號。使用 WARP Connector，客戶現在可以對這些服務套用精細原則以實現安全安全，從而在其 Zero Trust 架構內強化 VOIP 基礎架構。
保護對 CI/CD 管道的存取
組織的 DevOps 生態系統通常由許多部分組成，但 Jenkins 或 Teamcity 之類的 CI/CD 伺服器是所有開發活動的中心。因此，確保 CI/CD 伺服器的安全至關重要。藉助 WARP Connector 和 WARP 用戶端，組織可以保護整個 CI/CD 管道並輕鬆簡化它。
讓我們看一下 Kubernetes 應用程式的典型 CI/CD 管道。環境設定如上圖所示，開發人員和 QA 筆記型電腦上有 WARP 用戶端，WARP Connector 安全地連接不同網路上的 CI/CD 伺服器和暫存伺服器：
通常，當開發人員提交其程式碼變更並叫用 CI/CD 伺服器上的 webhook 時，就會觸發 CI/CD 管道。
構建影像後，就可以部署程式碼，這通常分階段進行：測試、暫存和生產。
當影像在測試/暫存環境中準備就緒時，開發人員和 QA 工程師會收到通知。
QA 工程師透過 webhook 從 CI/CD 伺服器接收通知，以啟動監控和疑難排解工作流程。
藉助 WARP Connector，客戶可以輕鬆地將其開發人員連接到 DevOps 生態系統中的工具，同時保持生態系統的私密性，不向公眾公開。在 DevOps 生態系統安全地連接到 Cloudflare 後，可以輕鬆套用精細的安全性原則來保護對 CI/CD 管道的存取。
保留真實來源 IP 位址
執行 Microsoft AD 伺服器或非 Web 應用程式伺服器的組織通常需要識別真實的來源 IP 位址以進行稽核或應用原則。如果存在這些要求，WARP Connector 可以簡化此過程，提供無需新增 NAT 邊界的解決方案。這對於限制不健康的來源 IP 位址的速率、在邊界內實施基於 ACL 的原則或從終端使用者處收集其他診斷資訊非常有用。
開始使用 WARP Connector
作為此次發佈的一部分，我們對 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 來改變他們的連線和安全格局。