在不断发展的企业安全领域，首席信息安全官和首席信息官必须孜孜不倦地构建新的企业网络并维护旧的网络，以实现高性能的任意对任意连接。对于他们的网络架构师团队来说，调查自己的环境以跟上不断变化的需求是工作的一半，另一半通常是发掘可以无缝集成到现有环境中的创新解决方案。为追求安全、灵活的基础设施而进行这样的持续建设和强化，正是 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 来改变他们的连接和安全格局。