在过去几年中，为实现对私有公司网络的远程访问而安装和维护硬件的传统方法已不再安全或具有成本效益。由于本地 VPN 产品中发现的 漏洞 ↗ 不断增加，安全和 IT 团队正在寻找不需要团队监控和响应 CVE 警报 ↗ 的解决方案。这些相同的系统还限制了用户的带宽，因为它们通过单一的基础设施路由所有用户互联网流量，从而导致糟糕的用户体验。IT 团队认识到，安装和维护自己的硬件所需的成本和精力，可以通过更现代、更安全的云托管服务来抵消。用户对应用程序性能的期望正暴露出受带宽限制的自托管 VPN 解决方案的局限性。总之，运行您自己的 VPN 成本高昂、风险大，并且无法提供出色的用户体验。
因此，许多组织正寻求使用 零信任网络访问 (Zero Trust Network Access, ZTNA) ↗ 服务，作为 安全访问服务边缘 (Secure Access Service Edge, SASE) ↗ 架构的一部分，从而转向 零信任 (zero trust) ↗ 安全态势，以提供对私有资源的远程访问。随着所有关键软件作为云服务运行，组织解除了保持服务器和软件最新的责任。云平台还针对大规模进行了架构设计，这显著增加了最终用户的可用带宽，从而改善了他们的体验。
在旧模型中，VPN 硬件可以直接访问应用程序所在的网络，通常用户可以访问整个网络。新的 SASE 远程访问方法创建了从云平台到应用程序所在网络的连接，但仅公开对特定应用程序或网络地址的访问权限。Cloudflare 推荐的方法是安装软件代理（类似于最终用户设备上的代理），这些代理创建从云到私有网络的安全隧道。但是，这并不总是一条容易采取的路径。对于试图快速更换旧版远程访问硬件的网络管理员来说，必须部署新服务器或经过漫长的变更控制以将软件部署到现有应用程序服务器上，在可接受的时间范围内可能是不可能的。相反，网络管理员可能更熟悉并且更有把握，使用熟悉的协议（例如 GRE 或 IPsec）创建从云 SASE 平台到现有网络硬件的安全隧道。这甚至可能意味着使用以前用于 VPN 访问的相同硬件设备，但只需将它们简化为安全隧道连接器，并关闭（或删除许可证）任何昂贵且易受攻击的远程访问功能。
本设计指南面向处于这种情况下的组织：他们需要一种快速的方法来快速替换或减少他们对自托管远程访问硬件的使用，然后在适当的情况下逐步迁移到推荐的软件代理方法。
本指南专为考虑更换当前 VPN 供应商，同时为其组织准备向零信任或 SASE 架构迁移的网络和安全专家而编写。它假定读者熟悉网络概念，例如 IPsec 隧道、路由表和拆分隧道。
您将学到：
- Cloudflare 如何替换传统的类似 VPN 的实施
- 如何获得对 VPN 网络流量的可见性
- 大规模实施 Cloudflare 解决方案时需要考虑的因素
- 迁移到推荐的零信任网络访问实现所采取的步骤
本指南描述的解决方案要求您与 Cloudflare 签订包含以下内容的合同：
- 针对您希望入职的用户数量的 Cloudflare One 许可证
- Cloudflare WAN（以前称为 Magic WAN）
为了建立对 Cloudflare 更强大的基础了解，我们推荐以下资源：
- 什么是 Cloudflare？| 网站 ↗（五分钟阅读）或 视频 ↗（两分钟）
- 博客：什么是 SASE？| 安全访问服务边缘 | Cloudflare ↗（14 分钟阅读）
- 参考架构：使用 Cloudflare 演进至 SASE 架构（三小时阅读）
传统的 VPN 方法通常提供以下类型的访问：
- 允许远程用户访问运行在企业网络上的自托管私有应用程序。
- 将所有用户互联网流量通过应用了安全策略的单个集中 VPN 接入点进行路由。
SASE 平台通过提供两项关键服务取代了传统的 VPN 硬件。首先，它将用户访问直接映射到托管在公司网络或云中的内部应用程序，这与通常提供对整个公司网络广泛访问权限的托管自建 VPN 服务不同。其次，它可以在靠近用户的位置过滤互联网流量，允许用户安全地访问互联网，而无需通过公司网络路由所有流量，从而提高效率并保持安全性。
远程用户对云托管的零信任网络访问 (ZTNA) 服务进行身份验证和连接，而该服务又可连接到私有应用程序所在的网络。Cloudflare 的 SASE 参考架构 描述了将 Cloudflare 连接到您现有应用程序和网络的三种方法：
- 软件连接器（
cloudflared或 Cloudflare Mesh） - 使用 Cloudflare WAN 的 IPsec 或 GRE 隧道
- 使用 Cloudflare Network Interconnect 的直接网络连接
这三种方法都有其特定的优势，但在考虑现代零信任实施时，通常首选软件连接器，原因有三：
- 它们提供了一种灵活且易于在跨环境中复制的网络连接模型。您可以在很少甚至不更改配置的情况下移动应用程序和服务器。
- 软件守护进程架构简化了对增加的流量需求的扩展，只需在更多服务器上安装更多代理即可。
- 由于守护进程在靠近您的应用程序（而不是在您的网络边缘）运行，因此您可以构建隔离的网络或应用程序网段以在其中实施策略，防止横向移动并充分发挥零信任模型的优势。
发往一般互联网的流量通过云端安全 Web 网关 (SWG) 进行路由。编写了过滤对恶意网站的请求的策略，并根据用户身份和设备安全态势允许访问 SaaS 应用程序。
Cloudflare 的 SASE 参考架构 描述了将用户设备连接到 Cloudflare 的不同方法，有些需要安装设备代理，有些要求用户只需将 Web 浏览器指向一个 URL 即可。在本文档中，由于大多数传统 VPN 在设备上都需要某些客户端软件，因此我们将描述一个使用 Cloudflare 设备代理 的解决方案。
在现有远程访问硬件存在漏洞且迫切需要更换的情况下，速度是关键。此外，负责弃用现有 VPN 硬件的团队可能更熟悉网络，而不是在服务器上安装软件。尝试实施一个完整的项目以用一种完全不同的模式（即部署软件代理）替换现有硬件，可能需要数周而不是几天的时间。本指南概述了如何快速移除或减少现有 VPN 解决方案，并提出后续步骤，以充分利用 SASE 平台的各个方面。
这种方法允许网络和安全团队快速启动和运行，同时获得现代零信任部署中的经验，以允许远程访问内部应用程序。对网络流量增加的可见性还将使团队能够深入了解应用程序使用情况，并计划进行成功且安全的零信任迁移。
本指南将在较高级别描述以下阶段，如果您需要有关特定于您环境的具体详细信息的帮助，请 联系 Cloudflare ↗。
- 第 1 阶段：用基于云的远程访问快速替换现有传统/易受攻击的 VPN 硬件，同时深入了解应用程序流量。
- 第 2 阶段：向上扩展和卸载传统 IPsec 隧道。
- 第 3 阶段：通过细分应用程序访问权限和启用无客户端访问来改善安全态势。
考虑一个拥有全球 IT 基础架构的组织。具体而言，分别在欧洲、美国和亚洲部署了三个数据中心，每个数据中心都有其自己的 VPN 服务。为了获得最佳性能，此 VPN 实施方案要求员工有意识地根据自己的位置选择连接到其中一个 VPN 集群。在这个示例中，所有的用户互联网流量都会被路由穿过 VPN 服务，在通过其中的防火墙施加一定的安全级别来保护用户免受一般互联网上的各种危险。
在此第一阶段期间，将在用户设备及其目前经由现有网络基础架构访问的专用网络之间建立网络连接。这通过两种方式来实现。
- 在员工设备上安装 Cloudflare 设备代理。这取代了当前正在使用的 VPN 客户端软件。
- 利用位于数据中心的现有网络硬件，建立使用 Cloudflare WAN 服务进行管理的前往 Cloudflare 的 IPsec 隧道。
无论是员工的设备还是数据中心网络，都将会连接到距离它们最近的 Cloudflare 服务器。这要归功于 Cloudflare 的任何播架构 (anycast architecture) ↗，并确保为用户流量提供最理想的路径，无需员工或 IT 支持人员付出任何努力。用户不再需要选择要连接到哪个 VPN 服务区域，因为 Cloudflare 始终会确保他们连接到最近且响应最快的服务节点，以获得访问私有应用程序的最佳性能。
图 4 显示了从终端用户设备到 Cloudflare 的流量，以及将流量路由到私有数据中心的隧道。当用户流量到达最近的 Cloudflare 接入点时，Cloudflare 会将目的地为私有应用程序的流量直接路由至数据中心，同时通过 Cloudflare 的 安全 Web 网关 (SWG) 处理绑定互联网的流量。您可以利用现有 DNS 服务，并使用 Cloudflare Gateway DNS 策略 解析对私有地址的请求。Cloudflare WAN 用于在 Cloudflare 与数据中心之间创建 IPsec 隧道，并通过静态路由配置确定流量如何到达各个现有网络和应用程序。
通过在现有网络或安全设备上终止 IPsec 隧道，可以创建安全的出站连接，且对当前基础架构的影响有限。这些 IPsec 隧道还允许出站的服务器发起流量继续流动。不过，根据部署规模，现有设备可能会遇到带宽限制。最好将第一阶段视为“试点”或低规模部署，以便快速启动运行并验证用户与应用程序的连通性。下一阶段将根据本阶段收集的见解改进设计。
采用这种设计后，Cloudflare 可以根据请求用户的身份过滤流量。例如，已对公司身份提供商进行身份验证且属于“工程 (Engineering)”组成员的用户，将仅被允许访问内部托管的源代码存储库。此外，用户设备在连接前可能需要通过 特定的态势检查。零信任文档中提供了可作参考的 示例网络策略。本质上，这使您能够使用用户身份（而非关联的 IP 地址范围）来定义网络访问策略。摆脱传统的 5 元组 ACL 是迈向零信任模型的第一步。
既然我们已将您的网络连接到 Cloudflare，接下来需要让员工设备上的流量到达 Cloudflare 网络，这需要 设备代理。首次安装代理时，系统会提示用户通过与 Cloudflare 配置的身份提供商 (IdP) 进行身份验证。IdP 将确保用户使用现有身份进行身份验证，还可以导入访问策略中使用的组成员身份信息。设备注册策略 用于确保只有合适的用户、使用正确的身份验证方法且使用安全设备，才能将新设备连接到您的组织的 Cloudflare Zero Trust 实例，然后他们才能获得任何应用程序的访问权限。
使用 设备配置文件 为不同用户应用不同的设备代理配置——或使用 受管网络 为不同位置的同一用户应用不同配置。对于不通过 VPN 服务器路由互联网流量的公司，设备配置文件允许您 配置设备代理以排除互联网流量，使其不经过 Cloudflare 隧道而直接连接到互联网。请注意，本指南强烈建议将绑定互联网的流量通过 Cloudflare 发送，因为在那里您可以对该流量的安全性拥有更大的控制权。但您可以有选择性地让带宽占用大的流量（例如视频会议）绕过 Cloudflare。
使用设备代理访问内部资源的员工流量，其源 IP 将位于 100.96.0.0/12 IP 范围内。该范围来自 RFC 6598 运营商级 NAT 空间 ↗，应作为路由添加到数据中心区域，以便流量能够流回这些用户。有关更多信息，请参阅 利用 WARP 集成的 Cloudflare WAN 文档。
尽管本阶段侧重于将 Cloudflare WAN 服务和 IPsec 隧道用于大量员工流量，但 Cloudflare 软件连接器在内部主机名的 DNS 解析中发挥着关键作用。由于在获取使用这些软件连接器方面的经验也将有助于下一阶段的工作，因此定义部署和管理这些连接器的过程的努力应在第一阶段开始。
Cloudflare 提供两类软件连接器：
cloudflared- Cloudflare Mesh（以前称为 WARP Connector）
如引言中所讨论，cloudflared 是零信任网络访问的首选方法，但仅支持到您的网络和应用服务器的入站连接，任何由服务器发起的连接都不会通过隧道，而是遵循服务器的默认网络路径。Cloudflare Mesh 旨在创建促进出站和入站连接的隧道，但目前尚未具备同等水平的故障转移支持和易配置性。就本指南而言，由于 cloudflared 支持这里描述的内部 DNS 用例，因此我们将讨论使用 cloudflared。
针对大型远程访问用例，Cloudflare 建议将连接器部署至专有主机。有关更多部署建议及服务器规模调整的信息，请参阅 系统要求文档。这些服务器的部署位置取决于它们需要获得的访问权限，以及内部防火墙规则和网络分段。某些客户从在其次外部防御网（DMZ）进行首次部署开始，也有人将其部署于网络更深处，并以此为基础进行扩展。
以自动化方式安装 cloudflared 效果最佳，因此，我们推荐使用如 Docker 等虚拟化技术来部署，或者将其部署为 VMware 客户机并利用 Ansible 来配置。理想情况下，当使用 cloudflared 隧道的流量增加时，此类系统便能够基于从各个主机收集来的实时指标对部署自动进行缩放。可以通过 Prometheus 指标端点 (metrics endpoint) 监控各个 cloudflared 实例。Prometheus 是一个基于 HTTP 的监控及告警系统，功能类似于 SNMP，能暴露指标供被监控资源轮询。现如今市面上的多数监控系统均支持 Prometheus 格式，以采集告警和自动扩缩所需的指标。
有关大规模部署 cloudflared 连接器的更多信息，请参考：
- 关于在 Ansible、Terraform 及 Kubernetes 等各种环境中进行 连接器的各种部署和更新指南
- 借由使用 副本 (replicas) 建立高可用性
- 借助 Grafana 监控隧道
如您在图 4 中所见，DNS 和一般网络流量都会从员工设备流向 Cloudflare。默认情况下，设备代理会将所有 DNS 查询转发至 Cloudflare，并根据 DNS 策略 进行检查和过滤。这非常实用，因为管理员可以配置 DNS 策略以阻止潜在安全威胁，并在员工上线时立即开始保护他们。这也适用于互联网流量经隧道到达 Cloudflare、但客户端仍通过 Cloudflare DNS 服务解析主机名请求的情况。
对于内部域，Cloudflare 需要知道如何解析它们。这就是 解析器策略 (resolver policies) 发挥作用的地方。在将 DNS 策略应用于传入的 DNS 请求之后，客户可以选择将针对内部 DNS 主机名的请求转发给他们的内部 DNS 服务器。例如，域名 example.local 可能托管在运行在 10.10.10.123 的 DNS 服务器上。解析器策略将确保属于该域的主机名请求被发送到该 IP。
需要一条通过隧道暴露到内部 DNS 服务器的路由。应在能够将 DNS 流量路由到 10.10.10.123 IP 地址的主机上部署 cloudflared。随后，通过 DNS 网关对内部域的请求将通过隧道重定向到此 DNS 服务器。
随着第一阶段工作的展开，最初的用户将开始访问应用程序，对适当的监控和日志记录的需求将变得显而易见。了解通过 Cloudflare 的流量可见性将有助于：
- 支持人员的故障排除等运营活动。
- 由 SOC（安全运营中心）监控潜在威胁，可能使用安全信息和事件管理 (SIEM ↗) 服务。
- 了解应用程序流量，以查看可在哪些方面进行潜在的安全性和性能改进（另见第 2 阶段）。
Cloudflare 在不同级别上提供可见性，可通过仪表板获取，或使用 Logpush 导出。对于流经 Cloudflare WAN IPsec 隧道的流量，可在仪表板以及通过 GraphQL API 找到 网络分析 (Network Analytics)。这将显示流量的采样统计数据，可用于趋势和流量流分析。
接下来是更详细的 网络会话日志，收集通过 Cloudflare 安全 Web 网关的所有网络连接/会话信息，包括失败的请求。随后是 Gateway 活动日志，其中包含流量被网关引擎检查时触发的策略信息。将这些日志组合起来，可以全面显示所有网络流（包括用户身份）。利用这些信息，网络和安全团队可以分析哪些类型的流量流向何处，并据此规划后续步骤。
最后，对于实时告警，可以配置 Cloudflare 通知，用于 IPsec 和 cloudflared 隧道健康状况以及 Cloudflare 基础设施总体状态等事件。
在大多数环境中，IPsec 终止点的吞吐量有限，当扩展到整个业务的流量时，迟早可能引发问题。第 1 阶段的最后一步将帮助您深入了解应用程序流量流向。尽管您可能无法完全绘制应用程序格局，但很可能已经发现一些在当前 IPsec 隧道上造成显著负载的应用程序。
幸运的是，这些应用程序中的大多数可以逐一迁移到可扩展性更强的基于软件连接器的隧道。任何不依赖服务器发起流量的应用程序都符合此类迁移条件。凭借在第 1 阶段最初部署 cloudflared 期间积累的经验：
- 在相关环境（如下文示例中的美国数据中心）中部署两个或更多
cloudflared实例。 - 将 私有网络添加到隧道，以定义更具体地限定于其处理流量所在网络和应用程序的路由和访问。例如，通过软件连接器隧道暴露
10.20.56.0/24子网，而不是由 Cloudflare WAN 管理的 IPsec 隧道暴露的更大的10.20.0.0/16。 - 来自员工的流量现在将通过 /24 子网的软件连接器隧道进行路由，而不是通过跨越 IPsec 隧道的 /16 路由，从而减轻对 IPsec 终止设备的依赖。
在某些情况下（例如上文的亚洲数据中心），这可能意味着不再需要 IPsec 隧道，软件连接器成为连接基础架构的唯一途径。在这种情况下，整个 10.30.0.0/16 子网可以由 cloudflared 管理，并停用 IPsec 隧道及其相关硬件。这个阶段很可能是一个持续过程：随着更多应用程序被映射且流量流被认为符合基于软件连接器隧道的条件，它们将根据需要进行迁移。
本指南前两个阶段产生的设计，与利用 VPN 集中器的传统 VPN 极为相似——策略执行发生在边界处。尽管我们出于引言中列出的原因采用了这种方式，但零信任架构的承诺是通过定义更小的应用程序/网络段来改善安全态势，并尽可能在靠近资源的地方应用安全策略。
这个阶段旨在使隧道后暴露的资源更小、更隔离，以防止内部网络中的横向移动。您可以利用前面阶段获得的可见性，选择一个应用程序（或一组应用程序）、关联的 IP 地址，并部署专用的软件连接器实例。请参阅如何部署连接器并暴露私有网络，并在第 3 步配置该应用程序的 IP 地址。
由于每个软件连接器实例都专用于该应用程序，因此可以将其配置为唯一入口点。进出应用程序所在网络段的流量可以被完全阻断，从而防止任何内部横向移动。所需的条件只是软件连接器具有有效的出站路由以创建隧道，以及网络/应用程序能够访问部署软件连接器的服务器。访问控制不仅管理 IP 路由，还在协议级别进行控制。因此，通过这种方法，您可以仅定义对该服务器上 HTTPS 的访问——该服务器可能还运行 SSH 和其他服务，但您只想明确针对该应用程序端口定义访问。
在上面的示例中，子网 X 和 Y 与数据中心的其余部分完全隔离。在这些子网中运行的应用程序（分别为 10.10.45.1 和 10.20.56.1）的流量只能流经 Cloudflare，并应用相关的身份验证和授权策略。一对一部署软件连接器并不总是正确的方法。您可能在私有网络上运行多个应用程序，并部署多台运行 cloudflared 的服务器来处理这些应用程序的流量。
除了路由私有 IP 地址的流量外，cloudflared 还可以通过公开可解析的主机名暴露内部应用程序。这使得在不使用设备上任何软件的情况下连接此类应用程序成为可能。这对于无法在设备上安装软件的情况非常有用，例如向承包商或合作伙伴提供应用程序访问。
在下面的示例中，erp.example.com 作为 公共主机名 添加到隧道，将流量路由到内部子网 Y 上的特定 IP 地址的端口 80 和/或 443。然后使用 Cloudflare Access 安全策略 保护从互联网对该资源的访问，这也依赖于您为员工入职设置的 IdP 连接。
并非所有应用程序都适合这种访问方式。仅支持 HTTP(S) 应用程序或 可以在浏览器中渲染的应用程序（例如 SSH 和 VNC）。要了解有关此类部署以及其他高级选项（如 Cookie 设置、浏览器隔离以及在应用程序中使用 Access 令牌进行身份验证）的更多信息，请参阅 自托管应用程序文档。
本设计指南从一个具有常见功能、局限性和风险的相当传统的 VPN 环境开始。通过在用户设备上使用 Cloudflare，并在面向数据中心的网络方面使用 Cloudflare WAN，第一和第二阶段描述了一种使用现有技术和知识进行迁移的低风险设计。这在停用 VPN 集中器、改善网络可见性以及提高用户访问内部资源的性能方面已经带来了好处。
第三阶段通过引入基于身份的网络策略和带有软件连接器的更小网络段改进了设计。这进一步开启了提供其他零信任访问模式的机会，例如 Web 应用程序的无客户端访问以及浏览器渲染的 VNC 或 SSH 会话。
Cloudflare 连接云连接任何设备、应用程序和网络的灵活性，使这种零信任迁移可以逐步进行，从而降低风险，并允许网络和安全团队以其组织所需的速度调整其知识和架构。
- Cloudflare WAN 集成：前往 Cloudflare WAN 的 WARP 匝道
- 策略配置：Gateway 网络策略