隧道运行状况检查

Cloudflare 持续监测连接您网络与 Cloudflare 的每条隧道是否可达且性能良好。当某条隧道变得不健康时，Cloudflare 会自动将流量引导至备用路径——无需手动干预。此监测依赖于隧道健康检查探测。

隧道健康检查探测由封装在被测试隧道协议中的 ICMP（互联网控制报文协议） ↗ 载荷组成。例如，如果隧道是 IPsec 隧道，则 ICMP 数据包 ↗ 将在隧道的安全封装载荷（ESP）数据包内被加密。

隧道健康检查探测从 Cloudflare 发送到隧道源，然后向 Cloudflare 返回响应。Cloudflare 使用此响应来确定探测结果并计算隧道状态（以下各节将对此进行更详细的解释）。

Magic Transit 使用两种类型的健康检查：

隧道健康检查监测从 Cloudflare 路由流量到您源网络的隧道的健康状态。Magic Transit 依赖这些检查来将流量引导至最佳可用路由。在接入过程中，您会 指定隧道端点，或指定来自 Cloudflare 全球网络的隧道探测所指向的隧道健康检查目标。

您可以通过 API 访问隧道健康检查结果。Cloudflare 会聚合来自不同 Cloudflare 服务器的单个健康检查结果以生成这些结果。

端点健康检查评估从 Cloudflare 分布式数据中心到您源网络的连接性。与隧道健康检查不同，端点探测旨在提供 Cloudflare 与您的网络之间互联网健康状况的宏观图景。它们在可用隧道上流动，但不会影响隧道选择或引导逻辑。

Cloudflare 全球网络服务器在客户网络命名空间之外发出端点健康检查，且目标通常是隧道终止边界路由器之外的端点。在接入过程中，您指定 IP 地址来配置端点健康检查。

隧道健康检查探测具有以下属性。

隧道健康检查探测测试 Cloudflare 是否可以通过该隧道成功连接到特定地址或端点。目标是您想要验证是否可达的地址。它是可选的，默认值根据健康检查的方向而有所不同（请参阅 方向 了解更多信息）。

隧道健康检查探测可以有两个可能的方向——单向和双向。

单向健康检查探测仅在一个方向上被封装，并通过隧道进入源（从 Cloudflare 到源）。响应以未封装的形式返回到 Cloudflare，并遵循标准互联网 路由 ↗ 在隧道外进行路由。

如果存在，目标默认为在隧道上指定为 customer_endpoint 的公共可路由源。否则，您可以使用自定义目标。

双向探测在两个方向上都保持封装。探测通过隧道进入，响应也通过隧道封装离开。来自您路由器的 ICMP 回复，如果是发往 Cloudflare 网络上的任播（anycast） IP 地址，则会到达最近的 Cloudflare 数据中心，并使用等价多路径 (ECMP) 分发在其中一台服务器上，以确保响应采取最有效的路径。

默认数据包寻址

默认情况下，Cloudflare 会将这些数据包的目标地址设为在隧道上设置的接口地址字段的 Cloudflare 端，并将其源地址设为隧道的客户端。例如，如果接口地址为 10.100.0.8/31，则 Cloudflare 将数据包的目标地址设为 10.100.0.9，源地址设为 10.100.0.8。

接口地址范围

接口地址字段使用 /30 或 /31 CIDR 范围：

• /31 范围：您提供的 IP 是 Cloudflare 侧，另一个 IP 是客户端。例如，如果接口地址是 10.100.0.8/31，那么 10.100.0.8 是 Cloudflare 侧，10.100.0.9 是客户端。
• /30 范围：您提供的 IP 是 Cloudflare 侧，另一个 IP（不包括广播和网络标识符）是客户端。例如，如果接口地址是 10.100.0.9/30，那么 10.100.0.9 是 Cloudflare 侧，10.100.0.10 是客户端。

您还可以为双向健康检查配置自定义公共目标，这是 Azure Active Standby 隧道设置的推荐方法。

这些数据包通过您配置的隧道在 Cloudflare 之间双向流动，以提供对 Cloudflare 网络与您的站点之间的流量路径的完整可见性。您需要配置流量选择器以接受 IPsec 隧道的健康检查数据包。

请参阅 添加隧道 以了解如何配置双向或单向健康检查。

对于使用带公共 IP 范围的旧版健康检查系统的客户，Cloudflare 建议：

• 将隧道健康检查目标 IP 地址配置在 172.64.240.252/30 前缀范围内。
• 应用基于策略的路由，以匹配源 IP 地址等于配置的隧道健康检查目标（例如 172.64.240.253/32）的数据包，并通过隧道将它们路由回 Cloudflare。

隧道健康检查探测可以有两个可能的类型：request（请求）和 reply（回复）。对于每种类型，源和目标地址取决于方向。请参阅 添加隧道 以了解如何更改此设置。

在 Request 样式的健康检查中，载荷探测是 ICMP 请求。

对于单向探测，源地址是隧道的 Cloudflare 侧（公共可路由地址），目标是源路由器（同样是公共可路由的）。源路由器接收探测并生成具有相反源和目标的 ICMP 响应，并将其发送到隧道之外。

对于双向探测，源地址是隧道的 Cloudflare 侧的接口地址（私有可路由地址），目标是隧道的接口地址（同样是私有可路由的）。源路由器接收探测并生成具有相反源和目标的 ICMP 响应，并将其发送到隧道中。

在 Reply 样式的健康检查中，载荷探测是 ICMP 回复。

对于单向探测，目标地址是隧道的 Cloudflare 侧（公共可路由地址），源是源路由器（同样是公共可路由的）。源路由器接收探测并将其作为响应在未更改的情况下发送到隧道外。

对于双向探测，目标地址是隧道的 Cloudflare 侧接口地址（私有可路由地址），源是隧道的接口地址（同样是私有可路由的）。源路由器接收探测数据包，并将探测数据包作为响应（未更改）发送回隧道，因为目标地址是通过隧道路由的。

flowchart TB
accTitle: 双向 Request 样式
accDescr: 显示 Cloudflare 与源之间双向 Request 样式隧道健康检查探测和响应的流动。
   subgraph Tunnel Healthcheck Probe
   cloudflare(Cloudflare) --- bare_echo_request([ICMP Echo 请求])
   bare_echo_request --> tunnel[隧道]
   tunnel --- encapsulated_echo_request([隧道协议 < ICMP Echo 请求 >])
   encapsulated_echo_request --> Internet([互联网])
   Internet --- encapsulated_echo_request_2([隧道协议 < ICMP Echo 请求 >])
   encapsulated_echo_request_2 --> origin_tunnel(隧道)
   origin_tunnel --- received_bare_echo_request([ICMP Echo 请求])
   received_bare_echo_request --> origin(源)
   end
   subgraph Tunnel Healthcheck Response
   origin --> bare_echo_reply([ICMP Echo 回复])
   bare_echo_reply --- origin_tunnel_2(隧道)
   origin_tunnel_2 --- encapsulated_echo_reply([隧道协议 < ICMP Echo 回复 >])
   encapsulated_echo_reply --- Internet_2([互联网])
   Internet_2 --> encapsulated_echo_reply_2([隧道协议 < ICMP Echo 回复 >])
   encapsulated_echo_reply_2 --> tunnel_2[隧道]
   tunnel_2 --> bare_echo_reply_2([ICMP Echo 回复])
   bare_echo_reply_2 --> cloudflare
   end

flowchart TB
accTitle: 双向 Reply 样式
accDescr: 显示 Cloudflare 与源之间双向 Reply 样式隧道健康检查探测和响应的流动。
   subgraph Tunnel Healthcheck Probe
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo 回复])
   bare_echo_probe --> tunnel[隧道]
   tunnel --- encapsulated_echo_probe([隧道协议 < ICMP Echo 回复 >])
   encapsulated_echo_probe --> Internet([互联网])
   Internet --- encapsulated_echo_probe_2([隧道协议 < ICMP Echo 回复 >])
   encapsulated_echo_probe_2 --> origin_tunnel(隧道)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo 回复])
   received_bare_echo_reply --> origin(源)
   end
   subgraph Tunnel Healthcheck Response
   origin --> bare_echo_reply([ICMP Echo 回复])
   bare_echo_reply --- origin_tunnel_2(隧道)
   origin_tunnel_2 --- encapsulated_echo_reply([隧道协议 < ICMP Echo 回复 >])
   encapsulated_echo_reply --- Internet_2([互联网])
   Internet_2 --> encapsulated_echo_reply_2([隧道协议 < ICMP Echo 回复 >])
   encapsulated_echo_reply_2 --> tunnel_2[隧道]
   tunnel_2 --> bare_echo_reply_2([ICMP Echo 回复])
   bare_echo_reply_2 --> cloudflare
   end

flowchart TB
accTitle: 单向 Echo 请求
accDescr: 显示来自 Cloudflare 到源并返回的单向 Echo 请求健康检查流。
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo 请求])
   bare_echo_probe --> tunnel[隧道]
   tunnel --- encapsulated_echo_probe([隧道协议 < ICMP Echo 请求 >])
   encapsulated_echo_probe --> Internet([互联网])
   Internet --- encapsulated_echo_probe_2([隧道协议 < ICMP Echo 请求 >])
   encapsulated_echo_probe_2 --> origin_tunnel(隧道)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo 请求])
   received_bare_echo_reply --> origin(源)
   origin --- received_bare_echo_reply_2([ICMP Echo 回复])
   received_bare_echo_reply_2 --> Internet_2([互联网])
   Internet_2 --> cloudflare

flowchart TB
accTitle: 单向 Echo 回复
accDescr: 显示来自 Cloudflare 到源并返回的单向 Echo 回复健康检查流。
   cloudflare(Cloudflare) --- bare_echo_probe([ICMP Echo 回复])
   bare_echo_probe --> tunnel[隧道]
   tunnel --- encapsulated_echo_probe([隧道协议 < ICMP Echo 回复 >])
   encapsulated_echo_probe --> Internet([互联网])
   Internet --- encapsulated_echo_probe_2([隧道协议 < ICMP Echo 回复 >])
   encapsulated_echo_probe_2 --> origin_tunnel(隧道)
   origin_tunnel --- received_bare_echo_reply([ICMP Echo 回复])
   received_bare_echo_reply --> origin(源)
   origin --- received_bare_echo_reply_2([ICMP Echo 回复])
   received_bare_echo_reply_2 --> Internet_2([互联网])
   Internet_2 --> cloudflare

配置用于处理您流量的每个 Cloudflare 数据中心都会发送隧道健康检查探测。Cloudflare 发送这些探测的频率因隧道和位置而异。您可以通过使用 API 或仪表板（dashboard） 修改 health_check 频率，基于每条隧道微调该频率。您可以将频率设置为 low（低）、mid（中） 或 high（高），默认值为 mid（中）。

实际的频率公式考虑了 Cloudflare 数据中心中的服务器数量，或者对于动态预置的命名空间，考虑了其上预置有客户命名空间的服务器数量。该频率是动态的，取决于 Cloudflare 网络的规模。

当针对某个 健康隧道 的探测尝试失败时，检测到故障的每台服务器会迅速再探测最多两次以获得准确的结果。如果隧道一直处于中断状态且探测开始返回成功，Cloudflare 也会这样做。因为 Cloudflare 全球网络服务器最多每秒发送一次探测，所以您的网络每秒将收到数百个健康检查数据包。作为探测的一部分，每个 Cloudflare 数据中心仅发送一个健康检查数据包，代表相对微不足道的流量。

存在三种隧道健康状态：healthy（健康）、degraded（降级）和 down（中断）。

健康隧道优于降级隧道，而降级隧道优于已中断的隧道。

Magic Transit 根据您在 接入期间分配隧道路由优先级 时设置的优先级将流量引导至隧道。数值较低的隧道路由优先于数值较高的路由。

• 当在前五分钟内至少有 0.1% 的隧道健康检查失败（且至少发生两次失败）时，Magic Transit 认为链路存在丢包，并将隧道状态设置为 degraded（降级）（假设隧道未中断）。
• Magic Transit 需要两次失败，以便单个丢失的数据包不会触发惩罚。
• 然后，Magic Transit 立即将隧道状态设置为 degraded，并应用优先级惩罚。

• 当在过去的一秒内，至少三个样本的所有健康检查均失败时，Magic Transit 会立即将隧道从 healthy（健康）或 degraded（降级）状态转换为 down（中断）状态，并对通过该隧道的路由应用优先级惩罚。
• down（中断）状态判定优先于 degraded（降级）状态判定。这意味着隧道只能是以下状态之一：down、degraded 或 healthy。

当 Magic Transit 识别到不健康的路由时，它会应用以下惩罚：

• Degraded（降级）：在优先级上增加 500,000。
• Down（中断）：在优先级上增加 1,000,000。

故障惩罚的值有意设定为极大值，以便它们始终超过在 路由配置 期间分配的优先级值。

应用惩罚而不是完全删除路由，这保留了冗余并为只有一条隧道的客户维持了选择。惩罚还支持多条隧道均不健康的情况。

在 Cloudflare 数据中心发生故障的情况下，Cloudflare 的全球网络不会宣告您的前缀，并且 Cloudflare 会将您的数据包路由到下一个最近的数据中心。要检查 Cloudflare 全球网络和仪表板（dashboard）的系统状态，请参阅 Cloudflare 系统状态 ↗。

一旦隧道处于 down（中断）状态，全球网络服务器将继续按照前面所述的节奏发出探测。当探测返回 healthy（健康）时，接收到健康数据包的全球网络服务器会立即再发送两个探测。如果这两个探测都返回健康，Magic Transit 将隧道状态设置为 degraded（降级）（因为连续三个成功的探测不再满足 down 状态的条件）。

当过去 30 次探测的失败率低于 0.1% 时，处于 degraded（降级）状态的隧道将转换为 healthy（健康）。此转换最多可能需要 30 分钟。

Magic Transit 的隧道健康检查系统允许隧道迅速从 healthy 转换为 degraded 或 down，但从 degraded 或 down 转换为 healthy 的过程很慢。这种行为称为迟滞（hysteresis），可防止由抖动和其他间歇性网络故障引起的路由变动。

考虑两条隧道及其关联的路由优先级。记住，较低的路由值具有优先级。

• 隧道 1，路由优先级 100
• 隧道 2，路由优先级 200

当两条隧道都处于 healthy（健康）状态时，路由优先级将流量专门引导到隧道 1，因为其路由优先级 100 优于隧道 2 的优先级。隧道 2 不接收任何流量，但隧道健康检查探测除外。端点健康检查也仅通过隧道 1 流向源网络内部的目的地。

如果隧道 1 与 Cloudflare 之间的链路变得不可用，Cloudflare 全球网络服务器会在其下一次健康检查探测中发现此故障，并立即再发出两次探测（假设隧道最初是健康的）。

当全球网络服务器没有从这两个额外探测中收到正确的 ICMP 回复数据包时，该全球网络服务器会将隧道 1 标记为 down（中断），并将隧道 1 的优先级降级为 1,000,100。然后，优先级转移到隧道 2，并且 Magic Transit 立即将到达该全球网络服务器的数据包引导到隧道 2。

假设导致隧道 1 健康状态被判定为 down 的连接问题得到解决。在下一个健康检查间隔，发出检查的全球网络服务器会收到成功的探测，并立即再发送两个探测以验证隧道健康。

当所有三个探测都成功返回时，Magic Transit 会将隧道状态从 down（中断）转换为 degraded（降级）。在此转换过程中，Cloudflare 减少了该路由的优先级惩罚，使其优先级变为 500,100。因为隧道 2 的优先级为 200，所以流量继续通过隧道 2 发送。

全球网络服务器继续探测隧道 1。当在五分钟内健康检查失败率降至 0.1% 以下时，Magic Transit 将隧道状态设置为 healthy（健康）。Cloudflare 完全将隧道 1 的路由优先级恢复为 100，并且流量引导将数据流返回到隧道 1。

有关解决隧道运行状况问题的帮助，请参阅排除隧道健康故障。