在不斷發展的企業安全領域,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 來改變他們的連線和安全格局。