GRE 和 IPsec 隧道

隧道和封装

为了在 Cloudflare 的全球网络与您的源网络之间路由流量，Magic Transit 会将您的原始数据包包装在外部数据包内 —— 这一过程称为封装（encapsulation）。外部数据包将您的流量通过互联网传输到目的地，并在那里将其拆封（解封装）并进行递送。

Magic Transit 使用两种封装协议：通用路由封装 (GRE) 和 IPsec。GRE 是无状态的，配置更简单，但不加密流量。IPsec 加密流量并对源进行身份验证，从而提供更强的安全性。两者都创建了隧道 —— Cloudflare 与您的网络之间的逻辑点对点连接。Cloudflare 在您网络命名空间内的全球网络服务器上设置隧道端点，而您在数据中心的路由器上设置隧道端点。

为了适应封装引入的额外标头数据，您必须调整最大分段大小 (MSS)，以符合标准互联网可路由的最大传输单元 (MTU)（即 1500 字节）。

有关说明，请参阅设置最大分段大小。

此图说明了 Magic Transit 的流量流向。

sequenceDiagram
accTitle: Tunnels and encapsulation
accDescr: This diagram shows the flow of traffic with Magic Transit.
participant A as 客户端
participant B as Cloudflare Magic Transit
participant C as 源路由器
A->>B: 负载 <br> 协议 <br> IP 标头
Note left of A: 入口流量
B->>C: 负载 <br> 协议 <br> IP 标头 <br> GRE <br> IP 标头
C->>A: IP 标头 <br> 协议 <br> 负载
Note right of C: 出口流量

任播

传统隧道连接两个固定的端点 —— 每一侧各有一台设备。Magic Transit 使用了不同的模型：将任播（anycast） IP 地址用于 Cloudflare 的隧道端点。在任播模型中，任何 Cloudflare 数据中心内的任何服务器都可以接收流量，并且必须能够为任何隧道封装和解封装数据包。这意味着您的隧道不会绑定到单个 Cloudflare 服务器 —— 流量由距离源最近的任何数据中心处理。

这适用于 GRE 隧道，因为 GRE 协议是无状态的。Cloudflare 独立处理每个数据包，不需要隧道端点之间进行任何协商或协调。隧道端点绑定到 IP 地址，但不绑定到特定设备。任何可以剥离外部标头然后路由内部数据包的设备，都可以处理通过隧道发送的任何 GRE 数据包。

对于 IPsec 隧道，客户的路由器使用因特网密钥交换 (IKE) 协议与 Cloudflare 协商创建 IPsec 隧道。因为 IPsec 是有状态的（它需要共享密钥和会话参数），所以由一台 Cloudflare 服务器处理初始协商，然后将隧道详情（流量选择器、密钥等）传播到所有 Cloudflare 数据中心。结果是，任何 Cloudflare 服务器都可以处理该 IPsec 隧道的流量，即使只有一台服务器协商了设置。

Cloudflare 的任播架构为 Cloudflare 全球网络上每个数据中心内的每台服务器提供了通往您隧道的管道。下图显示了这种架构。

flowchart LR
accTitle: Anycast tunnel
accDescr: Multiple servers in data center preparing packets to send through anycast tunnel.

a(用户)

subgraph 1
direction LR
b(Cloudflare 全球 <br> 网络服务器)
c(Cloudflare 全球 <br> 网络服务器)
d(Cloudflare 全球 <br> 网络服务器)
e(Cloudflare 全球 <br> 网络服务器)
f(Cloudflare 全球 <br> 网络服务器)
g(Cloudflare 全球 <br> 网络服务器)
h(Cloudflare 全球 <br> 网络服务器)
end

subgraph 2
i("Acme 路由器 <br> 198.51.100.1")
j("FTP 服务器 <br> (203.0.113.100)")
end

subgraph 3
x("Acme 路由器 <br> 198.51.100.1")
z("FTP 服务器 <br> (203.0.113.100)")
end

a --> 1== Cloudflare 任播 GRE <br> 单个端点 ==>i --> j

1== Cloudflare 任播 IPsec <br> 单个端点 ==>x --> z

IPsec 隧道

IPsec ↗ 是一组协同工作的协议，用于在设备之间建立加密连接。它有助于保护您在公共网络上发送的数据的安全。组织经常使用 IPsec 来建立虚拟专用网络 (VPN)，其工作原理是加密 IP 数据包并对数据包来源的源头进行身份验证。

有关如何设置 IPsec 隧道的详细信息，请参阅配置隧道端点。若要了解有关 Magic Transit 用于创建 IPsec 隧道的配置参数的更多信息，请继续阅读。

IKEv2 如何建立 IPsec 隧道

Magic Transit 使用以下阶段来建立 IPsec 隧道：

初始交换 (IKE_SA_INIT)：IKE 对等体协商 IKE 安全关联 (SA) 的参数，并建立用于密钥派生的共享密钥，并在适用时，通过 RFC 9370 ↗ 发送对后量子密钥交换的支持信号。当启用降级保护时，Cloudflare 还会在此交换期间发送 IKE_SA_INIT_FULL_TRANSCRIPT_AUTH 通知，以发送对完整记录身份验证（full transcript authentication）的支持信号。在此交换之后，对等体拥有一个安全通信通道，但尚未对彼此进行身份验证。
中间交换 (IKE_INTERMEDIATE)：如果两个对等体都支持 RFC 9370，它们将使用 ML-KEM（基于模格的密钥封装机制）执行额外的密钥交换，ML-KEM 是一种在 draft-ietf-ipsecme-ikev2-mlkem ↗ 中指定的后量子密钥交换。这通过将来自经典 Diffie-Hellman（在 IKE_SA_INIT 期间建立）的共享密钥与后量子 ML-KEM 相结合，创建了一个 hybrid 共享密钥，以防御先收集、后解密（harvest-now, decrypt-later） ↗攻击。
认证交换 (IKE_AUTH)：使用从 IKE_SA_INIT 和 IKE_INTERMEDIATE 交换建立的密钥，IKE 对等体进行相互认证。在认证之后，它们建立 IKE 安全关联 (SA)。接下来，对等体协商并建立 IPsec 隧道，即所谓的子 SA（Child SA）。
重置密钥 (Rekeying)：定期地或通过人工干预，可以对 IKE SA 进行重新生成密钥（rekey），以为会话生成带有新鲜密钥的新 SA。此 rekey 操作针对 IKE SA（以刷新控制平面）和子 SA（以刷新数据平面）执行。当使用混合交换 (RFC 9370) 时，IKE SA 的 rekey 过程将再次执行并行的经典 (DH) 和后量子 (ML-KEM) 交换，以确保持续的量子抗性。

总而言之，IKEv2 创建一个使用特定加密转换的 IKE SA。然后，它使用该 IKE SA 创建一个子 SA，该子 SA 本身使用特定的加密转换。以下配置部分详细说明了 Magic Transit 当前对 IKE SA 和子 SA 支持的加密转换。

支持的配置参数

根据您的设备所支持的内容，从 Magic Transit 支持的以下配置参数中进行选择。

IKE SA（也称为阶段 1）

按照 IKEv1 语言，文档有时将 IKE SA 称为阶段 1 (Phase 1)。

加密（Encryption）
- 密钥长度为 128 位或 256 位的 AES-GCM-16
- 密钥长度为 256 位的 AES-CBC
完整性（Integrity）（有时称为身份验证）
- SHA2-256
密钥交换方法（Key Exchange Method）（前称 Diffie-Hellman 组）： Cloudflare 支持以下用于 IKE SA 的密钥交换方法。请注意，RFC 9370 ↗ 将 “DH 组” 重命名为 “密钥交换方法” 选项以容纳非 DH 算法。
- 后量子混合（推荐）：ML-KEM-768 作为 DH 组 20 的附加密钥交换（根据 RFC 9370 和 draft-ietf-ipsecme-ikev2-mlkem ↗）
- 后量子混合：ML-KEM-1024 作为 DH 组 20 的附加密钥交换（根据 RFC 9370 和 draft-ietf-ipsecme-ikev2-mlkem ↗）
- 经典 DH 组 20（384 位随机 ECP 组）
- 经典 DH 组 14（2048 位 MODP 组）
- 经典 DH 组 5（1536 位 MODP 组）
  
  注意
  Cloudflare 推荐使用 ML-KEM-768 + DH Group 20 混合交换进行后量子密钥协商。如果您的设备尚不支持 RFC 9370 和 draft-ietf-ipsecme-ikev2-mlkem，请使用 DH 组 20。
伪随机函数（PRF）

请勿将其与完美前向安全性 (PFS) 混淆。您通常无法配置 PRF。
- SHA2-256
- SHA2-384
- SHA2-512

子 SA（也称为阶段 2 或 IPsec SA）

子 SA（Child SA）。按照 IKEv1 语言，文档有时将此称为阶段 2 (Phase 2)。

加密（Encryption）：
- 密钥长度为 128 位或 256 位的 AES-GCM-16
- 密钥长度为 128 位或 256 位的 AES-CBC
完整性（Integrity）（有时称为身份验证）
- SHA2-256
- SHA-1
说明
在使用 AES-GCM-16 时，您不需要完整性算法，因为 AES GCM 包含完整性检查（由于它是一种关联数据认证加密 (AEAD) 算法）。然而，即使使用 AEAD 算法，某些路由器仍要求您选择完整性算法。
完美前向安全性 (PFS) 组

文档有时将此称为阶段 2 Diffie-Hellman 组。请勿将其与 PRF 混淆。Cloudflare 支持以下 Diffie-Hellman (DH) 组。
- DH 组 20（384 位随机 ECP 组）
- DH 组 14（2048 位 MODP 组）
- DH 组 5（1536 位 MODP 组）
  
  后量子安全
  如果子 SA 使用 DH 组进行完美前向安全性，那么如果父 IKE SA 是使用混合 ML-KEM 交换建立的，它仍然能免受量子威胁的影响。
  注意
  Cloudflare 建议您在配置设备时仅使用一个 DH 组，具体来说是 DH 组 20。
  说明
  Cloudflare 建议将子 SA 密钥重新生成间隔（SA 生存期）配置在 30 分钟到 8 小时之间。

必需配置参数

IKE 版本必须是 IKEv2。
IKE 身份验证方法必须是预共享密钥 (PSK)。
Cloudflare 支持 NAT 穿透 (NAT-T)。Cloudflare 也支持从端口 4500 开始的 NAT-T。
（罕见）您必须禁用扩展序列号 (ESN)。
如果您的隧道需要重放保护，请在您的路由器中启用对端死亡检测 (DPD)，并选择当发生 DPD 超时时重新启动 IKE 会话的选项。这种“重新启动”选项可确保在 Cloudflare 服务器下线的情况下连接能够恢复。如果您的路由器没有提供此设置，请查看路由器文档以了解其死亡对端检测行为。
多密钥交换 (RFC 9370 ↗)：若要使用后量子安全性，您的路由器必须支持 RFC 9370 和 draft-ietf-ipsecme-ikev2-mlkem ↗ 中定义的 IKE_INTERMEDIATE 和 IKE_FOLLOWUP_KE 交换。由于后量子公钥和密文（例如 ML-KEM-768）比经典密钥更大，您必须在路由器上启用 IKEv2 分片，以防止数据包超过 1,500 字节的 MTU。配置第一个附加密钥交换时，对 ML-KEM-768 使用 IANA 分配的转换 ID 36，对 ML-KEM-1024 使用转换 ID 37。

可选配置参数

禁用防重放保护。
IPsec NULL 加密（不推荐）： 除非必要，否则请勿使用此选项，因为这会让 IPsec 流量保持不加密状态，从而降低安全性。您必须明确选择加入以使用该选项。使用此选项还会消除后量子保护。

经过测试的第三方供应商互操作性

以下第三方供应商已通过测试，验证了可与 Cloudflare IPsec 协同进行后量子密钥协商：

供应商	产品 / 版本	ML-KEM 变体	DH 组	备注
Cisco	Cisco 8000 Series Secure Routers with IOS XR Release 26.1.1	ML-KEM-1024	组 20	需要支持 RFC 9370 和 draft-ietf-ipsecme-ikev2-mlkem。
Fortinet	FortiOS 7.6.6+	ML-KEM-768	组 20	需要支持 RFC 9370 和 draft-ietf-ipsecme-ikev2-mlkem。
Fortinet	FortiOS 7.6.6+	ML-KEM-1024	组 20	需要支持 RFC 9370 和 draft-ietf-ipsecme-ikev2-mlkem。

Cloudflare 将继续测试和验证其他第三方设备。如果您已成功配置未在此处列出的供应商的后量子 IPsec，请联系您的账户团队。

支持的 IKE ID 格式

Magic Transit 支持以下 IKE ID 类型以用于 IPsec：

征求意见稿（RFC）名称 ID_RFC822_ADDR

格式：ipsec@<TUNNEL_ID>.<ACCOUNT_ID>.ipsec.cloudflare.com
示例：ipsec@f5407d8db1a542b196c59f6d04ba8bd1.123456789.ipsec.cloudflare.com

RFC 名称 ID_FQDN

格式：<TUNNEL_ID>.<ACCOUNT_ID>.ipsec.cloudflare.com
示例：f5407d8db1a542b196c59f6d04ba8bd1.123456789.ipsec.cloudflare.com

RFC 名称 ID_KEY_ID

格式：<ACCOUNT_ID>_<TUNNEL_ID>
示例：123456789_f5407d8db1a542b196c59f6d04ba8bd1

此外，如果满足以下两个条件，Cloudflare 还支持 ID_IPV4_ADDR 的 IKE ID 类型：

您设置了 IPsec 隧道的 customer_endpoint 值。
cloudflare_endpoint 和 customer_endpoint 的组合在客户的 IPsec 隧道中是唯一的。

基于路由与基于策略的 VPN

虽然 Cloudflare 同时支持基于路由和基于策略的 VPN，但我们推荐使用基于路由的 VPN。

如果无法选择基于路由的 VPN 且您必须使用基于策略的 VPN，请注意以下限制：

Cloudflare 仅支持每个子 SA 单个流量选择器集。
策略必须涵盖回复式的健康检查 —— 也就是说，它们必须匹配流量选择器 —— 否则，Cloudflare 会将它们丢弃，就像任何其他不匹配策略的来自 IPsec 隧道的流量一样。
单个 IPsec 隧道最多只能包含大约 100 个子 SA。因此，每个隧道的不同策略数量实际上是有限制的。

改进的降级保护（Beta）

IKEv2 的原始身份验证设计让每个端点仅签署自己的出站消息，而不是完整的握手记录。具备量子能力的路径上攻击者（on-path attacker） ↗可以利用这一点来创建握手的“分裂视图”，从而诱使端点将后量子连接降级回经典密码学，即使双方都支持后量子密钥交换。

为了解决这个问题，Cloudflare 支持 IKE_SA_INIT_FULL_TRANSCRIPT_AUTH ↗ IKEv2 扩展。启用后，两个 IKEv2 对等体都会在认证交换期间签署整个握手记录，而不仅仅是签署它们自己的消息。这可以防止攻击者在不被发现的情况下将连接降级。

工作原理：

当该功能标志启用时，Cloudflare（作为 IKE 响应方）会在其 IKE_SA_INIT 响应中无条件包含一个 IKE_SA_INIT_FULL_TRANSCRIPT_AUTH 通知。
如果发起方也支持该扩展，双方都将使用完整记录身份验证，从而提高对降级攻击的保护。
如果发起方不支持该扩展，握手将以标准 IKEv2 身份验证继续进行。双方必须都支持该扩展才能使降级保护生效。

要求：

您的 IKEv2 发起方必须支持 draft-ietf-ipsecme-ikev2-downgrade-prevention ↗ 中定义的 IKE_SA_INIT_FULL_TRANSCRIPT_AUTH 通知。

故障排除

有关解决隧道问题的帮助：

排查隧道健康问题 - 诊断并修复健康检查故障
使用 IPsec 日志进行排查 - 使用 Logpush 分析 IPsec 握手问题

网络分析（Network Analytics）

Cloudflare 的 Network Analytics 提供网络层和传输层流量模式以及分布式拒绝服务 (DDoS) 攻击的近乎实时可见性，以帮助排查 IP 流量问题。您还可以通过查看特定时间段内的入口和出口隧道流量，使用 Network Analytics 来查看离开 Cloudflare 全球网络的流量信息。

有关更多信息，请参阅 Analytics。

故障排除

有关解决隧道问题的帮助：

排除隧道健康故障 - 诊断并修复运行状况检查失败问题
使用 IPsec 日志排除故障 - 使用 Logpush 分析 IPsec 握手问题