Configure routes for Cloudflare Mesh · Cloudflare One 文档

默认情况下，Mesh 节点仅能通过自身的 Mesh IP 访问。要让节点后方子网中的其他设备可访问，包括无法运行 Cloudflare One Client 的服务器、数据库、打印机和 IoT 设备，请向节点添加路由。Mesh 节点支持两种路由：

CIDR 路由 — 通过节点转发 IP 范围（私有 IP，例如 10.0.0.0/24；或公共 IP）的流量。
Hostname route — 将 hostname 的流量引导到 node 而不是 IP。这适用于专用 hostname（例如 wiki.internal.local），可用于应用程序 IP 未知或临时变化的情况；也适用于公共 hostname（例如 www.example.com），会通过 node 路由该 hostname 的流量，并通过 node 的公共 IP 出站。

当您添加路由时，Mesh 节点将充当网关：发往宣告的 CIDR 或主机名的流量将被转发到该节点，然后该节点将其传送到本地网络上的相应主机（或将其流出到公共互联网）。

支持 IPv4 和 IPv6 CIDR 路由。IPv6 路由要求将 Mesh 节点的设备配置文件配置为使用 MASQUE；如果设备配置文件使用 WireGuard，IPv6 路由将无法工作。

何时使用路由

不使用路由 — Mesh 上的设备只能通过其 Mesh IP 访问节点本身。直接运行在节点上的服务可以通过这种方式访问。
使用路由 — Mesh 上的设备可以访问节点背后子网中的任何主机。当您拥有无法运行 Cloudflare One Client 的基础设施时，请使用此选项。

flowchart LR
  subgraph subnet["Subnet 10.0.0.0/24"]
    node["Mesh node <br> 10.0.0.1"]
    db["Database <br> 10.0.0.50"]
    printer["Printer <br> 10.0.0.100"]
  end
  client["Client device <br> 100.96.0.10"] --> CF((Cloudflare)) --> node
  node --> db
  node --> printer

管理 CIDR 路由

使用 CIDR 路由将流量从您的 Mesh 节点转发到本地网络上的设备。

添加路由

在 Cloudflare 仪表板中，前往 Networking（网络） > Mesh。
前往 Mesh ↗
选择您的 Mesh 节点。
转到 Routes（路由） 选项卡。
选择 Add route（添加路由）。
输入要通过此节点路由的私有 CIDR（例如 10.0.0.0/24）。
（可选）为路由添加描述。
选择 Add route（添加路由）。

Required API token permissions

At least one of the following token permissions is required:

Cloudflare One Networks Write
Cloudflare Tunnel Write

Create a tunnel routebash

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"network": "10.0.0.0/24",
		"tunnel_id": "{mesh_node_id}",
		"comment": "Staging subnet"
	}'

编辑路由

前往 Networking（网络） > Mesh > 选择您的节点 > Routes（路由） 选项卡。
选择要修改的路由旁边的编辑图标。
更新 CIDR 或描述。
选择 Save（保存）。

Required API token permissions

At least one of the following token permissions is required:

Cloudflare One Networks Write
Cloudflare Tunnel Write

Update a tunnel routebash

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"network": "10.0.0.0/24",
		"comment": "Updated description"
	}'

删除路由

前往 Networking（网络） > Mesh > 选择您的节点 > Routes（路由） 选项卡。
选择路由旁边的删除图标。
确认删除。

Required API token permissions

At least one of the following token permissions is required:

Cloudflare One Networks Write
Cloudflare Tunnel Write

Delete a tunnel routebash

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID" \
	--request DELETE \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

配置分流隧道

为了让流量到达您宣告的 CIDR，该范围必须在 Mesh 节点和客户端设备上均通过 Cloudflare 进行路由。

在 Mesh 节点上

在 Mesh 节点的设备配置文件中，确保宣告的 CIDR 通过 Cloudflare 进行路由：

包含模式（推荐用于 Mesh 节点）：将 CIDR 添加到您的包含列表中。
排除模式：从排除列表中移除 CIDR（或其父范围）。

例如，如果您宣告的是 10.0.0.0/24，而您的分流隧道排除列表包含 10.0.0.0/8，则需要移除 10.0.0.0/8，并重新添加您不希望通过 Cloudflare 路由的 10.0.0.0/8 范围的部分。

在客户端设备上

在客户端设备使用的设备配置文件上重复相同的分流隧道配置，确保宣告 the CIDR 通过 Cloudflare 进行路由。

返回流量路由

Mesh 节点将来自 Cloudflare 的入站流量转发到子网上的设备。然而，对于返回流量（来自子网设备返回到 Mesh 客户端的响应），子网设备需要有一条回到 Mesh 节点的路由。

flowchart LR
  client["Client device <br> 100.96.0.10"] -- request --> CF((Cloudflare)) -- request --> node["Mesh node <br> 10.0.0.1"]
  node --> db["Database <br> 10.0.0.50"]
  db -. "response: <br> needs route to node" .-> node -. response .-> CF -. response .-> client

如何配置这取决于 Mesh 节点的安装位置：

选项 1：Mesh 节点是默认网关

如果 Mesh 节点是子网的默认网关（或安装在路由器上），则不需要额外配置。来自子网设备的所有流量会自然地通过节点路由。

选项 2：Mesh 节点不是默认网关

如果 Mesh 节点是子网中的普通主机，请配置子网的路由器以通过该节点发送 Mesh 流量。添加静态路由：

目标：100.96.0.0/12（Mesh IP 范围）
下一跳：Mesh 节点的本地子网 IP（例如 10.0.0.1）

这可确保将发往 Mesh 客户端的响应转发到 Mesh 节点，以便通过 Cloudflare 进行传送。

站点到站点路由

Mesh node 可以在不同站点的专用 subnet 之间路由流量。每个 node 都会通告其本地 CIDR，并通过 Cloudflare 路由远程 CIDR。

有关配置两个站点、其 router、返回 route 和验证测试的信息，请参阅使用 Cloudflare Mesh 连接两个专用网络。

DNS 过滤

要使用 Cloudflare Gateway 筛选来自子网的 DNS 查询：

在路由器上配置 DNS：将路由器的 DNS 指向 Gateway 解析器 IP：
- 172.64.36.1
- 172.64.36.2
向路由器添加 IP 路由：在您的路由器上，添加指向 Gateway 解析器 IP 到您的 Mesh 节点本地 IP 的静态路由。这允许 DNS 流量通过节点到达 Cloudflare。
- 目标：172.64.36.1 → 下一跳：10.0.0.1（本地 Mesh 节点）
- 目标：172.64.36.2 → 下一跳：10.0.0.1
配置分流隧道：确保在您的分流隧道配置中，以下 IP 通过 Mesh 节点进行路由：
- 子网的内部 DNS 解析器 IP
- Gateway 初始解析 IP 范围：172.64.128.0/20（IPv4）和 2606:4700:0cf1:4000::/64（IPv6）

Gateway 会使用发起设备的私有源 IP 记录 DNS 查询。你可以据此为内部 DNS 记录创建解析器策略。

主机名路由

您可以将特定主机名的流量引导至 Mesh 节点，而不是宣告 IP 范围。当用户请求该主机名时，Cloudflare Gateway 会分配一个初始解析 IP 并通过该节点路由流量。

私有主机名（例如 wiki.internal.local）— 节点将流量传送给本地网络上应用程序的私有 IP。这在应用程序的 IP 未知或为临时 IP 时非常有用。
公共主机名（例如 www.example.com）— 节点使用其自身的公共 IP 将流量流出到公共互联网。这使您可以将 Mesh 节点用作该主机名的专用出口。

主机名路由取代了虚拟网络作为访问资源的方式：因为主机名是全球唯一的，所以不支持重叠的主机名，并且一个主机名一次只能路由到一个节点或隧道。

客户端设备
请求 wiki.internal.local
DNS 查询
Cloudflare Gateway
返回一个令牌 IP，然后将目标重写为真实的私有 IP。
100.80.0.0/16
主机名路由
Mesh 节点
将流量转发到本地网络上的主机
↓
私有主机
wiki.internal.local · 10.0.0.50

要深入了解主机名路由背后的数据包流向，请参阅公告博客文章 ↗。

前提条件

运行受支持的 Mesh 节点版本。 主机名路由需要 Mesh 节点运行 Linux Cloudflare One Client 版本 2026.6.822.0 或更高版本。
将 Mesh 节点的设备配置文件配置为使用 MASQUE。 如果设备配置文件改用 WireGuard，主机名路由将无法工作。
启用 Gateway 代理（支持 TCP、UDP 和 ICMP）：
1. 转到 Traffic policies（流量策略）> Traffic settings（流量设置）。
2. 在 代理和检查 中，开启 允许 Secure Web Gateway 代理流量。
3. 选择 TCP。
4. 选择 UDP（将流量代理到内部 DNS 解析器所必需）。
5. （推荐）要代理 ping 和 traceroute 等诊断工具的流量，请选择 ICMP。你可能还需要更新系统，以允许 ICMP 流量通过 cloudflared。
1. 向您的 cloudflare_api_token ↗ 添加以下权限：
  
  Zero Trust Write
2. 使用 cloudflare_zero_trust_device_settings ↗ 资源启用 TCP 和/或 UDP 代理：
  
  resource "cloudflare_zero_trust_device_settings "global_warp_settings" { account_id = var.cloudflare_account_id gateway_proxy_enabled = true gateway_udp_proxy_enabled = true }
现在，Cloudflare 将代理来自已注册设备的流量，但拆分隧道设置中排除的流量除外。有关 Gateway 如何转发流量的详细信息，请参阅 Gateway 代理。
在 通过 Cloudflare 路由以下 IPv4 地址范围 的 Split Tunnel 配置中，同时为 Mesh node 的设备 profile 和 client 设备 profile 进行设置。在 Include 模式下，添加每个地址范围。在 Exclude 模式下，确保这些地址范围（或其父级范围）均未被排除。

用途 IPv4

Mesh 设备 IP 范围 100.96.0.0/12

Cloudflare 源 IP 范围 100.64.0.0/12

主机名路由（token IP）范围（172.64.128.0/20）和所有 Cloudflare One IPv6 范围会自动通过 Cloudflare 路由，无需手动添加。
客户端设备上从本地域回退中移除主机名的顶级域，以便将 DNS 查询发送到 Cloudflare Gateway 进行解析。

用途	IPv4
Mesh 设备 IP 范围	`100.96.0.0/12`
Cloudflare 源 IP 范围	`100.64.0.0/12`

添加主机名路由

在 Cloudflare 仪表板中，前往 Networking（网络） > Mesh。
前往 Mesh ↗
选择您的 Mesh 节点。
转到 Routes（路由） 选项卡。
选择 Add route（添加路由），然后选择 Private hostname（专用主机名）。
输入您要通过此节点路由的完全限定域名（FQDN）（例如 wiki.internal.local）。
主机名格式限制
- 字符限制：必须少于 255 个字符。
- 支持的通配符：允许使用单个通配符（*），且它必须代表一个完整的 DNS 标签。示例：*.internal.local
- 不支持的通配符：不支持以下通配符格式：
  - 部分通配符，例如 *-dev.internal.local 或 dev-*.internal.local。
  - 中间的通配符，例如 foo*bar.internal.local 或 foo.*.internal.local。
  - 主机名中的多个通配符，例如 *.*.internal.local。
- 通配符修剪：前导通配符（*）会被修剪掉，并假定有一个隐式的点（.）。例如，*.internal.local 会保存为 internal.local，但会匹配通配符级别的所有子域名（涵盖 foo.internal.local，但不涵盖 foo.bar.internal.local）。
- 点修剪：允许前导点和尾随点（.），但会被修剪掉。
（可选）为路由添加描述。
选择 Add hostname（添加主机名）。

Required API token permissions

At least one of the following token permissions is required:

Cloudflare One Networks Write
Cloudflare Tunnel Write

Create hostname routebash

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/zerotrust/routes/hostname" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"hostname": "wiki.internal.local",
		"tunnel_id": "{mesh_node_id}",
		"comment": "Internal wiki"
	}'

配置 DNS 解析

对于私有主机名，Gateway 必须能够将主机名解析为其私有 IP。如何配置取决于 DNS 解析和应用程序流量是使用相同的连接器还是不同的连接器。

节点解析主机名（默认）

默认情况下，Mesh 节点使用其主机上配置的 DNS 解析器（例如 Linux 上的 /etc/resolv.conf）来解析主机名，这与 cloudflared 的工作方式相同。如果节点已经能够通过该解析器将主机名解析为其私有 IP，则不需要进一步配置。

如果节点自身无法解析主机名，最简单的选择是在节点的 hosts 文件（例如 Linux 上的 /etc/hosts）中添加一个条目，将主机名映射到其私有 IP。与 Cloudflare Tunnel 不同，Mesh 节点不要求您运行专用的 DNS 服务器：

/etc/hoststxt

10.0.0.50 wiki.internal.local

分割 DNS：DNS 和应用程序流量使用不同的连接器

仅当 DNS 查询必须发送到与应用程序流量不同的连接器时，才需要 Gateway 解析器策略。例如，内部 DNS 服务器位于一个 Mesh 节点或 Cloudflare Tunnel 后方，而应用程序通过另一个节点或隧道访问。在这种情况下：

为 DNS 服务器的 IP 添加 CIDR 路由，以便 Gateway 可以通过 DNS 服务器所在的连接器（Mesh 节点或 Cloudflare Tunnel）访问它。
创建解析器策略，将主机名（或其域名）的 DNS 查询发送到该内部 DNS 服务器。

对于公共主机名，Mesh 节点会处理解析：Gateway 将 DNS 查询发送给节点，节点通过其上游 DNS 提供商进行解析，然后将数据包路由到目的地，并使用其自身的公共 IP 流出。不需要内部 DNS 服务器或解析器策略。

安全保护主机名流量

添加主机名路由后，请使用 Access 自托管应用程序或 Gateway 网络策略保护该路由。有关详细信息和示例，请参阅连接私有主机名。

局限性

从 Chrome 142 ↗ 起，本地网络访问（LNA）会限制网站向本地 IP 地址发出的请求。LNA 在 Chromium 引擎层面实现，因此会影响所有基于 Chromium 的浏览器（例如 Microsoft Edge、Brave 和 Opera），不只是 Google Chrome。如果账户的 Gateway 初始解析 IP 范围仍来自运营商级 NAT（CGNAT）地址空间（100.64.0.0/10），就可能受到影响，例如旧版默认范围 100.80.0.0/16，或在 CGNAT 空间中配置的自定义范围。这些浏览器会将此类地址归类为本地网络地址。当从公共 IP 加载的网站向解析为此空间内初始解析 IP 的域名发起子请求时，浏览器会将其视为从公共网络到本地网络的请求，并提示用户允许访问本地网络上的设备。用户接受提示前，浏览器会阻止向这些域名发出的请求。

当出口策略匹配广泛使用的域名（例如 cloudfront.net 或 github.com），导致公共页面的子请求解析到 CGNAT 空间时，通常会发生这种情况。

使用当前默认初始解析 IP 范围（172.64.128.0/20）的账户不受影响，因为此范围属于 Cloudflare 公共地址空间，而非 CGNAT。如果账户在默认范围变更前创建，或配置了自定义 CGNAT 空间范围，请参阅配置初始解析 IP，迁移到非 CGNAT 范围，无需依赖以下浏览器变通方法。

以下变通方法使用 Google Chrome 企业策略。如果组织管理其他基于 Chromium 的浏览器，请查阅该浏览器的企业策略文档，寻找等效控制项。

Iframe

如果受影响的请求源自 iframe 内部（例如嵌入在第三方门户中的应用程序），则 iframe 必须声明 local-network-access 权限，以便在父框架中显示浏览器提示：

Chrome 142-144：在 iframe 元素上使用 allow="local-network-access" 属性。
Chrome 145+：该权限被拆分为 allow="local-network" 和 allow="loopback-network"。

如果 iframe 是嵌套的，则链中的每个 iframe 都必须包含相应的属性。由于第三方应用程序控制着它们自己的 iframe 属性，这可能无法由最终用户进行配置。

规避方法

为避免此问题，请选择以下选项之一：

覆盖 IP 地址空间分类（Chrome 146+）：使用 LocalNetworkAccessIpAddressSpaceOverrides ↗ Chrome 企业策略，将 CGNAT 空间中的初始解析 IP 范围（例如 100.80.0.0/16）重新归类为公共地址。这是最有针对性的修复方式，因为它只更改初始解析 IP 范围的分类，而不会完全禁用安全检查。
Chrome 140+（允许特定 URL）：使用 LocalNetworkAccessAllowedForUrls ↗ Chrome 企业版策略使特定网站免受本地网络访问检查。请注意，https://* 是停用所有 URL 检查的有效条目。
Chrome 146+（允许特定 URL）：使用 LocalNetworkAllowedForUrls ↗ Chrome 企业版策略，从 Chrome 146 开始，该策略会替换 LocalNetworkAccessAllowedForUrls。
Chrome 142-152（选择退出本地网络访问限制）：使用 LocalNetworkAccessRestrictionsTemporaryOptOut ↗ Chrome 企业版策略完全退出本地网络访问限制。这是一项临时策略，将在 Chrome 152 之后移除。
停用 Chrome 功能标志：转到 chrome://flags，然后将 Local Network Access Checks 标志设置为 Disabled。此方法适用于个人用户，但不适用于企业级部署。