Magic Transit 参考架构

简介

本文档旨在描述 Cloudflare Magic Transit 的关键架构、功能和网络部署选项。它是一种基于 BGP 的 DDoS 保护和流量加速服务，适用于面向互联网的网络基础设施。

此文档适合谁，您将学到什么？

本参考架构专为对其组织的现有网络基础设施负有一定责任或有所了解的 IT 或网络专业人员设计。拥有内容交付重要技术和概念（包括路由器、DNS 和防火墙）方面的一些经验将会很有用。

为了更好地了解 Cloudflare 的基准知识，我们推荐以下资源：

什么是 Cloudflare？ | 网站 ↗（需 5 分钟阅读）或视频 ↗（2 分钟）

博客：Magic Transit 让您的网络更智能、更好、更强、且运营成本更低 ↗（14 分钟阅读）

阅读本参考架构的人将了解：

Cloudflare Magic Transit 如何保护您的网络基础架构免受拒绝服务攻击 (DDoS)
如何将 Magic Transit 设计到您现有的网络基础架构中

什么是 Magic Transit？

保护网络基础设施免受 DDoS 攻击，需要兼顾力度和速度。大规模流量型攻击很容易压垮硬件设备及其带宽受限的互联网链路。此外，大多数基于云的解决方案会将流量重定向到集中式清洗中心，这会显著影响网络性能。

Cloudflare Magic Transit 为本地、云和混合网络提供 DDoS 保护和流量加速。凭借跨越数百个城市 ↗并提供数百 Tbps 缓解容量的数据中心，Magic Transit 可以平均在全球不到三秒的时间内在其源头附近检测和缓解攻击，同时以比公共互联网更快的速度路由流量。

图 1：Magic Transit 概览 — Figure 1: Magic transit overview

在较高的层面上，Magic Transit 的工作原理如下：

连接： 通过向互联网发布边界网关协议 (BGP) 路由公告以及 Cloudflare 任播网络，客户流量会在最靠近源头的 Cloudflare 数据中心被摄取。
保护与处理： 会检查所有客户流量是否存在攻击。在检测到攻击时，立即应用高级和自动缓解技术。还可以将负载平衡、下一代防火墙、内容缓存和无服务器计算等其他功能作为服务提供。
加速： 干净的流量通过 Cloudflare 的低延迟网络链接进行路由，以获得最佳吞吐量，并通过 IP 隧道（GRE 或 IPsec）或专用网络互连 (PNI) 移交给源网络。Magic Transit 使用任播 IP 地址作为 Cloudflare 的隧道端点，这意味着任何数据中心中的任何服务器都可以为同一隧道封装和解封装数据包。有关隧道和封装的具体详情，请参阅 GRE 和 IPsec 隧道。

使用任播技术将弹性融入我们的网络

Magic Transit 对其网络隧道端点使用任播 IP 地址——因此从客户网络到 Cloudflare 配置的单个隧道会连接到所有 Cloudflare 全球数据中心（不包括中国网络）。这不会给路由器增加额外负担；从路由器的角度来看，这是到单个 IP 端点的单条隧道。

这是因为虽然隧道端点在技术上绑定到一个 IP 地址，但它不需要绑定到特定的设备。任何能够剥离外部标头然后路由内部数据包的设备都可以处理通过隧道发送的任何数据包。

在网络中断或其他问题发生时，隧道会自动进行故障转移，且不会对客户的网络性能造成任何影响。

Magic Transit 的部署架构

默认配置（仅限入口，直接服务器返回）

默认情况下，Magic Transit 仅处理入口方向的流量（从互联网到客户网络）。从服务器返回给客户端的流量由客户的 DC 边缘路由器根据其默认路由表通过其上行链路路由到互联网/ISP。此服务器返回流量不会通过隧道穿过 Cloudflare。这称为直接服务器返回（Direct Server Return，简称 DSR）。

图 2 中的网络图说明了这种 Magic Transit 设置，以及受 Magic Transit 保护流量的端到端数据包流。此设置中的隧道使用 GRE 进行封装。

图 2：使用默认 DSR 选项的 Magic Transit anycast 隧道 (GRE) 参考配置 — Figure 2: Reference Configuration of Magic Transit anycast Tunnel (GRE) With Default DSR Option

Cloudflare 为客户提供隧道端点的 Cloudflare 端 IPv4 任播地址。这是 Cloudflare 拥有的地址空间中可公开路由的 IP 地址。Cloudflare 通过从分布在全球的许多数据中心中的多个节点宣告端点 IP，自动处理其网络上的故障。要处理客户网络上的故障，请从单独的路由器配置两条隧道。客户可以联系其客户团队，要求其他任播 IP 地址。上面的配置显示了单个隧道，Cloudflare 端的隧道端点地址是 192.0.2.1。
客户侧 anycast GRE 隧道端点需要是可公开路由的地址，通常是客户边缘路由器 WAN 接口的 IP 地址。本例中为 192.0.2.153。
隧道接口 IP 地址为 RFC 1918 私有地址。这些地址仅在其所属的 Magic Transit 服务实例内具有“本地意义 (locally significant)”。因此，只要不与同一 Magic Transit 服务实例内其他隧道地址重叠，客户可以选择任意 RFC 1918 地址。
最佳实践是，由于隧道是点对点连接，/31 子网足以分配给定隧道所需的 2 个 IP 地址。上例选择 10.10.10.0/31 子网，Cloudflare 端隧道接口为 10.10.10.0/31，客户数据中心边缘路由器侧为 10.10.10.1/31。
配置隧道后，在 Magic Transit 服务实例中配置一条路由，将发往给定客户前缀的流量转发到正确的隧道。
目的地为客户前缀 203.0.113.0/24 的流量将被路由到远程端（从 Cloudflare 网络视角即客户侧）隧道接口为 10.10.10.1 的隧道。
由于这是 Direct Server Return (DSR) 设置，服务器返回流量遵循客户边缘路由器上配置的默认路由（ip route 0/0），经上行对等体（客户 ISP 路由器）返回客户端，不会经过 Cloudflare 网络。

注意： 大多数 ISP 在彼此的 BGP 通告中接受的最小 IP 前缀大小（最长子网掩码）为 /24；例如 x.x.x.0/24 或 y.y.y.0/23 可以，但 z.z.z.0/25 不行。因此 Cloudflare Magic Transit 能够代表客户通告的最小 IP 前缀大小为 /24。

启用了 Egress 选项的 Magic Transit

当 Magic Transit 部署时启用了“出口（Egress）”选项，来自客户网络的出站流量也会流经 Cloudflare 网络。此部署选项使流量保持对称性，即客户端到服务器和服务器返回流量均流经 Cloudflare 网络。此实施不仅增加额外的安全性以及 Cloudflare 网络带来的高可靠性，还可保护服务器返回流量。

以下网络图说明了在启用 Magic Transit 选项时最终客户端和客户网络之间的端到端数据包流：

图 3：启用出口选项的 Magic Transit — Figure 3: Magic Transit With Egress Option Enabled

传入流量流与上述默认配置用例相同。
要使 Magic Transit 接收和处理出站流量，源 IP 地址必须在 Magic Transit 保护的 IP 前缀范围内，目的地 IP 地址必须是可在互联网上路由的公用地址（非 RFC 1918 地址）。

值得注意的是，对于为云托管服务引入自带公共 IP 地址（BYOIP）的客户，Magic Transit Egress 选项可以带来附加价值。通过使用该选项，客户无需向其云提供商购买和实施 BYOIP 服务，从而可减少其云账单并降低运营成本。

为实现此目标，用于连接 Magic Transit 的 IP 隧道配置在云提供商 VPC 与 Cloudflare 网络之间。借助 Magic Transit Egress 选项，双向客户端-服务器流量都将流经这些隧道。隧道数据包中的 BYOIP 地址隐藏在隧道端点 IP 地址和隧道头之后，对 VPC 与 Cloudflare 网络之间的底层云提供商网络元素不可见。

通过 Cloudflare Network Interconnect (CNI) 的 Magic Transit

Cloudflare Network Interconnect (CNI) 允许客户将他们的网络基础架构直接连接到 Cloudflare（绕过公共互联网），以获得更可靠、更高效和更安全的体验。

CNI 由交叉连接提供商作为一组第二层连接进行配置，Cloudflare 从自己的互联网可路由 IP 地址块中为每个连接分配一对 IP 地址。
Cloudflare 在 CNI 接入期间与客户协调配置这些链路，并在链路上建立 BGP 对等会话。
BGP 会话在通过 CNI 连接的 Cloudflare 网络与客户边缘路由器之间建立后，Cloudflare 拥有的前缀将通过此 CNI 链路通告给客户边缘路由器。

图 4 展示了通过 CNI 的 Magic Transit 的参考配置以及其相关数据包流。

注意： 此示例为未启用 Egress 选项的默认 Magic Transit 服务。如前几节所述，在 Magic Transit Direct Server Return 模式（即仅入站）下，服务器返回流量由客户边缘路由器经 ISP 通过公共互联网路由回客户端。

图 4：通过 CNI 的 Magic Transit 参考配置（默认 DSR 选项） — Figure 4: Reference Configuration of Magic Transit Over CNI (Default DSR Option)

启用并使用 Magic Transit Egress 选项时，服务器返回流量可通过配置在 CNI 连接上的 IP 隧道，经 Cloudflare 网络返回客户端。图 5 展示了此类示例。

图 5：启用出口选项的通过 CNI 的 Magic Transit 参考配置 — Figure 5: Reference Configuration of Magic Transit Over CNI with Egress Option Enabled

Magic Transit 保护公共云托管服务

Magic Transit 保护本地和云端托管的服务。此用例说明了云托管部署的配置。

图 6：使用 Magic Transit 保护多云服务（已启用出口选项） — Figure 6: Protect Multi-Cloud-Based Services With Magic Transit (Egress Option Enabled)

在此示例中，给定的客户有两个云 VPC 部署，分别跨越两个不同的云提供商和两个不同的地理区域。
在此示例中，客户的 /24 或更大前缀被拆分为多个更小的前缀（例如 /26），并分配给不同位置的各个 VPC。在从 Cloudflare 网络到各 VPC 建立隧道后，客户可以在 Magic Transit 配置中集中配置路由，将流量路由到相应 VPC。此类配置可通过 API 或 UI 仪表板完成。

借助 Magic Transit Egress 选项，客户可以绕过各云提供商的 BYOIP 服务及其相关费用和配置/运维复杂性，通过 Magic Transit 隧道经 Cloudflare 全球网络发送出站流量（即服务器返回或受保护前缀的服务器到互联网流量）。

Magic Transit 和 Cloudflare WAN

除了使用 Cloudflare Magic Transit 保护和路由企业面向外部的服务（即南北向可路由的互联网流量）外，客户还可以使用 Cloudflare WAN（以前称为 Magic WAN）保护东西向“企业内部”内部流量（例如 RFC 1918 私有地址），互联企业的所有站点。

Cloudflare WAN 使用 Cloudflare 网络取代了传统的 WAN 架构，通过一个简单的用户界面提供全球连接、基于云的安全性、性能和控制。

将 Cloudflare Magic Transit 和 Cloudflare WAN 服务结合起来，可为整个企业提供全面、安全、可靠且高性能的全球网络即服务解决方案，保护并加速南北向以及东西向流量。

这两种服务可以部署在同一服务实例中，也可以为偏好将面向互联网的外部网络与内部企业网络的管理和流量完全分离的客户，分别部署不同的 Magic Transit 和 Cloudflare WAN 服务实例。

图 7 演示了在独立的各运行空间系统里布设与分批构建起把 Magic Transit 连同 Cloudflare WAN 给个自配置完成的一个例子展现。

图 7：Magic Transit + Cloudflare WAN 为企业提供 Network-as-a-Service — Figure 7: Magic Transit + Cloudflare WAN Provide Network-as-a-Service for the Entire Enterprise

注意：此图像中的标签可能反映了以前的产品名称。

在此示例中，GRE 隧道用于通过 Cloudflare 全球任播网络连接客户的各个站点。Magic Transit 服务实例的 Cloudflare 任播 IP 地址为 192.0.2.1，Cloudflare WAN 服务实例为 192.0.2.2。Magic Transit 服务已启用 Egress 选项。
Magic Transit 服务负责保护和路由面向外部的前端客户端-服务器流量。Cloudflare WAN 服务负责保护和路由企业内部流量，例如内部应用程序、后端数据库同步以及分支机构到数据中心和分支机构到分支机构之间的流量。

Cloudflare Network Firewall：在不需要的流量到达企业网络之前进行控制和过滤

虽然 Magic Transit 保护客户服务免受 DDoS 攻击，但许多网络管理员还希望控制和阻止其他不受欢迎或潜在恶意流量。Cloudflare Network Firewall 在整个客户 WAN（包括总部、分支机构和虚拟私有云）上强制执行一致的网络安全策略，使客户能够在数秒内从统一仪表板在全球部署细粒度过滤规则。

Cloudflare Network Firewall 作为 Magic Transit 的一部分部署和配置。所有流经 Cloudflare 边缘数据中心、目的地前缀受 Magic Transit 保护的入站流量，均可由 Cloudflare Network Firewall 过滤。

图 8：Cloudflare Network Firewall 在互联网边缘阻止不需要和恶意的流量 — Figure 8: Cloudflare Network Firewall Blocks Unwanted and Malicious Traffic at the Internet Edge

注意：此图像中的标签可能反映了以前的产品名称。

在 Cloudflare Network Firewall 规则中，管理员不仅可以基于 IP 数据包头中的典型 5 元组（源/目的 IP、源/目的端口、协议）匹配和过滤网络流量，还可以使用 IP 包长度、IP 头长度、TTL 等其他信息。此外，还可以使用 Cloudflare 数据中心/colo 名称、区域、所在国家等地理信息配置 Network Firewall 规则（地理封锁 geo-blocking）。

有关 Cloudflare Network Firewall 及其配置的更多详情，请参阅 Introducing Magic Firewall ↗ 和 Cloudflare Network Firewall 文档。

关于始终在线和按需部署的说明

云 DDoS 缓解服务提供商可以始终监控流量威胁（始终在线部署模型 always-on），或仅在检测到攻击时重路由流量（按需 on-demand）。这一决策会影响响应时间和缓解时间，在某些情况下还会影响延迟。

在按需部署模式中，会在网络边缘监控和测量入站流量，以检测大规模攻击。在正常操作（即“和平时期”）期间，所有流量都会直接到达应用程序和基础架构，而没有任何延迟或重定向。只有在发生活跃的 DDoS 攻击时，流量才会被转移到云清洗提供商。在许多情况下，客户需要致电服务提供商来重定向流量，这会增加响应时间。

始终在线模式是在遭受攻击时无需客户采取任何行动的 DDoS 缓解方式。组织的流量始终路由通过云提供商数据中心进行威胁检查，即使在和平时期也是如此。这最大限度地缩短从检测到缓解的时间，且不会中断服务。

在所有方法和部署选项中，“始终在线”方法提供最全面的保护。

然而，将所有流量路由通过云清洗提供商可能会增加延迟，对某些延迟敏感的业务产生不利影响。Cloudflare 在设计时已考虑这一点——即使在始终在线部署下，客户也不应在性能上做出妥协。通过在边缘进行过滤和清洗，Cloudflare 可以大规模缓解攻击，同时不影响用户体验。

这得益于任播架构：流量始终被路由到距离发送方最近的 Cloudflare 位置进行过滤，而 Cloudflare 在数百个城市 ↗拥有存在，距离通常很短，从而消除“ trombone effect（长号效应）”。

在许多情况下，通过 Cloudflare 网络路由的路径比公共互联网更快 ↗；我们不认为客户必须牺牲性能才能获得全面保护。

总结

Cloudflare 提供全面的网络服务，以连接和保护本地、云托管和混合企业网络。Cloudflare 提供各种连接和部署选项，以适应客户的独特架构。

Cloudflare Magic Transit 是一款云原生网络安全解决方案，利用 Cloudflare 全球网络的强大功能来保护组织免受 DDoS 攻击。
Magic Transit 带有内置网络防火墙，帮助客户淘汰本地防火墙并部署可扩展的网络安全即服务。
除了为企业的外部服务（即南北向可路由的互联网流量）保护和路由流量之外，客户还可以使用 Cloudflare WAN 连接和保护东西向的“企业内部”流量。

如果您想了解有关 Magic Transit、Cloudflare WAN 或 Cloudflare Network Firewall 的更多信息，请联系我们获取演示 ↗。