私有网络连接性

当运行 Cloudflare One Client 的最终用户在连接 Cloudflare Tunnel 后面的私有网络时遇到问题，请遵循此故障排除流程。

Cloudflare One Client GUI 应显示 Connected（已连接）和 Your Internet is protected（您的互联网已受保护）。

If the Cloudflare One Client is stuck in the Disconnected state or frequently changes between Connected and Disconnected, refer to 无法连接 WARP。

仅当用户通过私有主机名（例如 wiki.internal.local）访问您的应用程序时，才需要执行此步骤。

• 如果您正在使用自定义解析器策略来处理私有 DNS，请转到您的 Gateway DNS 日志（Insights（洞察） > Logs（日志） > DNS query logs（DNS 查询日志））并搜索该主机名的 DNS 查询。

• 如果您正在使用本地域回退（Local Domain Fallback）来处理私有 DNS，请转到您的 Gateway 网络日志（Insights（洞察） > Logs（日志） > Network logs（网络日志））并搜索发往您 DNS 服务器 IP 的端口 53 流量。

如果没有任何相关的 Gateway 日志，这意味着 WARP 无法将查询转发到您的私有 DNS 服务器。请检查您的解析器策略或本地域回退配置，并参阅 WARP 如何处理 DNS 请求。

接下来，检查您的 Gateway 网络日志（Insights（洞察） > Logs（日志） > Network logs（网络日志））是否显示了发往目标 IP 的流量。

如果 Cloudflare One Client 已连接但没有网络日志，这意味着您的私有网络 IP 没有通过 Cloudflare One Client 进行路由。您可以通过在设备上搜索路由表以查找您应用程序的 IP 地址来确认这一点。发往您应用程序的流量应该通过 Cloudflare One Client 接口进行路由。如果使用了其他接口，请检查您的分流隧道（Split Tunnel）配置。

要检查是否发生了 Gateway 阻止事件：

1. 转到 Insights（洞察） > Logs（日志），然后选择 DNS query logs（DNS 查询日志）、Network logs（网络日志） 或 HTTP request logs（HTTP 请求日志）。
2. 应用以下筛选器：
   • Email（电子邮件）：用户的电子邮件地址
   • Event（事件）：Blocked（已阻止）
   • Date Time Range（日期时间范围）：用户访问应用程序的时间段

确定用户是否匹配了任何策略，或者他们匹配的策略优先级是否高于预期策略。

1. 要确定实际应用的策略：
   1. 转到 Insights（洞察） > Logs（日志），并选择 DNS query logs（DNS 查询日志）、Network logs（网络日志） 或 HTTP request logs（HTTP 请求日志）。
   2. 应用以下筛选器：
      • Email（电子邮件）：用户的电子邮件地址
      • Date Time Range（日期时间范围）：用户访问应用程序的时间段
   3. 在搜索框中，按目标 IP 或 FQDN 进行筛选。
   4. 在结果中，选择一条日志并记下其 **Policy Name（策略名称）**的值。
2. 转到 Traffic policies（流量策略） > Firewall policies（防火墙策略），比较已匹配策略与预期策略的执行顺序。
3. 比较 Gateway 日志值与预期策略标准。
   • 如果不匹配的值与身份相关，请检查用户注册表并验证从您的身份提供程序（IdP）传递给 Gateway 的值。当用户在 Cloudflare One Client 中注册时，Cloudflare 会更新注册表。如果用户的身份已过期，请让用户重新对客户端进行身份验证（Profile（个人资料） > Account information（账户信息） > Re-authenticate（重新验证））¹。

• 如果不匹配的值与设备状态相关，请查看用户设备的状态检查结果。验证设备是否通过了策略中配置的状态检查。

在 Traffic policies（流量策略） > Traffic settings（流量设置） 下，确保为 TCP、UDP 和 ICMP 流量启用了 Allow Secure Web Gateway to proxy traffic（允许 Secure Web Gateway 代理流量）。代理 DNS 流量和其他 UDP 数据包需要 UDP，而 ping 和其他管理功能需要 ICMP。

查看您的隧道日志流。如果您没有看到任何发往应用程序的请求，请确保您已将相应的静态路由添加到您的 Cloudflare Tunnel。

验证您是否可以直接从 cloudflared 主机连接到应用程序：

telnet test.example.com 443

PS C:\Users\JohnDoe> Test-NetConnection test.example.com -port 443

您还可以使用 tcpdump 或 Wireshark 等数据包捕获工具，来追踪来自用户设备的流量是否成功到达 cloudflared 并路由到您的应用程序。发往您应用程序的流量将携带 cloudflared 主机的源 IP。

1. 检查应用服务器是否配置了本地防火墙，从而阻止了来自 cloudflared 主机的请求。

2. 检查应用服务器是否需要主动向用户的设备发起任何连接。如果是，这是 cloudflared 的一个限制，您应该改为部署 Cloudflare Mesh以启用双向流量。

如果 TLS 检测（TLS inspection）存在问题，用户在浏览器中访问应用程序时将收到 Insecure Upstream（上游不安全）错误。如果他们在浏览器之外访问应用程序，可能不会收到错误。

启用了 Logpush 的客户可以检查 Gateway HTTP 数据集，以查找具有较高的 526 HTTP 状态码错误率的任何主机名。

要对 TLS 检测进行故障排除：

1. 创建一条临时的 Gateway HTTP 策略，为发往该应用程序的所有流量禁用 TLS 检测。例如：

   选择器（Selector）	运算符（Operator）	值（Value）	操作（Action）
   Destination IP（目标 IP）	in	10.2.3.4/32	Do Not Inspect

2. 如果 Do Not Inspect 策略允许用户进行连接，请验证您的应用程序所使用的 TLS 证书是由公共 证书颁发机构（CA）信任的，而不是自签名的。Cloudflare Gateway 无法与使用自签名证书的应用程序协商 TLS。有关更多信息，请参阅 TLS 检测限制。

   要解决此问题：

   • 选项 1： 为此应用程序创建一条永久的 Do Not Inspect HTTP 策略。
   • 选项 2： 使用其自己的证书基础设施进行检测的客户可以选择创建一条 Allow Pass Through 策略，这允许我们的代理接受来自您应用程序的 TLS 协商。这将允许请求正常流动，而无需 Do Not Inspect 策略。
   • 选项 3： 如果您的应用程序使用 HTTPS 或其他常用协议，您可以将一个已发布的应用程序添加到您的 Cloudflare Tunnel 中，并将 noTLSVerify 设置为 true。这将允许 cloudflared 信任您的自签名证书。