保护私有 IP 或主机名

您可以配置自托管 Access 应用程序来管理对您专有网络上特定 IP 或主机名的访问。

• 私有 IP 和主机名可通过 Cloudflare One Client、Cloudflare WAN（前称 Magic WAN）或 Browser Isolation 访问。有关更多详细信息，请参阅连接专有网络。
• 私有主机名通过本地域回退或 Gateway 解析器策略路由到您的自定义 DNS 解析器。
• 公网 IP 和主机名可用于定义私有应用程序，但该 IP 或主机名必须通过 Cloudflare Tunnel、Cloudflare Mesh 或 Cloudflare WAN 路由到 Cloudflare。
• （可选）如果您想使用 Access JWT 管理 HTTPS 应用程序会话，请开启 Gateway TLS 解密。

1. 在 Cloudflare 仪表板 ↗中，转到 Zero Trust > Access controls（访问控制）> Applications（应用程序）。

2. 选择 Create new application（创建新应用程序）。

3. 选择 Self-hosted and private（自托管和私有）。

4. 要使用其私有 IP 添加应用程序：

   1. 选择 Add private IP（添加私有 IP）。

   2. 在 **IP address（IP 地址）**中，输入代表应用程序的私有 IP 或 CIDR 范围（例如 10.0.0.1 或 172.16.0.0/12）。

   3. 在 **Port（端口）**中，输入您的应用程序使用的单个端口或端口范围（例如 22 或 8000-8099）。

      不支持逗号分隔的端口列表（例如 80, 443）。要为特定 IP 添加多个端口，您可以选择 Add private IP（添加专用 IP） 并对另一个端口重复该 IP 地址。或者，为另一个端口创建一个新的 Access 应用程序。

5. 要使用其私有主机名添加应用程序：

   1. 选择 Add private hostname（添加私有主机名）。
   2. 在 **Hostname（主机名）**中，输入应用程序的私有主机名（例如 wiki.internal.local）。您可以对私有主机名使用通配符，以保护共享根路径的应用程序的多个部分。
   3. 在 **Port（端口）**中，输入您的应用程序使用的单个端口或端口范围（例如 22 或 8000-8099）。

6. 在 Access policies 下，添加现有策略或创建新策略，以控制哪些用户可以连接到您的应用程序。所有 Access 应用程序默认均为拒绝状态——用户必须匹配 Allow 策略才能被授予访问权限。

7. 配置用户的身份验证方式：

   1. 选择您希望为应用程序启用的身份提供商。

   2. （推荐）如果您计划仅允许通过单一 IdP 进行访问，请开启 Apply instant authentication。最终用户将不会看到 Cloudflare Access 登录页面，Cloudflare 将直接将用户重定向到您的 SSO 登录事件。

   3. （推荐）开启 Authenticate with Cloudflare One Client，允许用户使用其 Cloudflare One Client 会话身份对应用程序进行身份验证。如果您的应用程序不在浏览器中且无法处理 302 重定向，请开启此选项。

8. （可选）为该应用程序配置独立 MFA。

9. 在 Session Duration 中，选择用户的应用程序令牌的过期频率。

   Cloudflare 会检查对您应用程序的每个 HTTP 请求是否包含有效的应用程序令牌。如果用户的应用程序令牌（和全局令牌）已过期，系统将提示他们重新向 IdP 进行身份验证。有关更多信息，请参阅会话管理。

   如果应用程序是非 HTTPS 的，或者您未开启 TLS 解密，则会话将由每个应用程序的 Cloudflare One Client 跟踪。

10. （可选）转到 **Additional settings（其他设置）**选项卡以自定义应用程序体验：

    • App Launcher 自定义：配置此应用程序在 App Launcher 中向用户显示的方式。

    • 允许免客户端访问：允许用户在没有 Cloudflare One Client 的情况下访问此私有主机名或 IP。通过您的 Access 策略的用户将在其 App Launcher 中看到一个磁贴，该磁贴指向前缀 URL，例如 https://<your-teamname>.cloudflareaccess.com/browser/https://wiki.internal.local/。该链接将通过免客户端网页隔离将流量路由到应用程序。此设置对于处于非托管设备上的用户或无法安装设备客户端的承包商非常有用。

    • 自定义拦截页面：选择用户被拒绝访问应用程序时将看到的内容。

      • Cloudflare default（Cloudflare 默认）：重新加载登录页面，并在 Cloudflare Access 徽标下方显示拦截消息。默认消息为 That account does not have access，您也可以输入自定义消息。
      • Redirect URL（重定向 URL）：重定向到指定网站。
      • Custom page template（自定义页面模板）：显示托管在 Cloudflare One 中的自定义拦截页面。

    • 以下设置仅适用于私有主机名，并且需要 Gateway TLS 解密：

      • 跨域资源共享（CORS）设置
      • Cookie 设置
      • 401 响应用于服务身份验证策略：当用户（或机器）在请求应用程序时未携带正确的服务令牌，则返回 401 响应代码。

11. 选择 Create（创建）。

在通过 Cloudflare Access 进行身份验证后，用户现在可以连接到您的私有应用程序。

身份验证体验取决于应用程序的协议。

如果开启了 Gateway TLS 解密，并且用户正在访问端口 443 上的 HTTPS 应用程序，Cloudflare Access 将在浏览器中显示登录页面，并向您的源站颁发应用程序令牌。这与自托管公共应用程序使用的基于 Cookie 的身份验证流程相同。

如果关闭了 Gateway TLS 解密，会话管理将在 Cloudflare One Client 中处理，而不是在浏览器中。

对于在端口 80 上通过明文 HTTP 提供服务的应用程序，Cloudflare Access 会显示一个浏览器内登录页面并颁发应用程序令牌，这与具有 Gateway TLS 解密的 HTTPS 应用程序相同。不需要 Gateway TLS 解密，因为流量已经未加密。

对于非 HTTP 或 HTTPS 的应用程序（例如 SSH、RDP 或任意 TCP/UDP），由 Cloudflare One Client 管理会话。用户将收到来自 Cloudflare One Client 的 Authentication required 弹出通知。当用户选择该通知时，Cloudflare One Client 将打开一个包含您的 Access 登录页面的浏览器窗口。

确保您的操作系统允许 Cloudflare One 客户端发送通知。如果启用了专注模式、勿扰模式或屏幕共享设置，您的设备可能不会显示通知。要在运行 DisplayLink 软件的 macOS 设备上启用客户端通知，您可能需要在镜像显示器时允许系统通知。有关更多信息，请参阅 macOS 文档 ↗。

默认情况下，Cloudflare 会在评估所有 Gateway 网络策略之后再评估 Access 应用程序策略。要在特定 Gateway 策略之前或之后评估 Access 应用程序，请执行以下步骤：

1. 在 Cloudflare 仪表板 ↗中，转到 Zero Trust > Traffic policies（流量策略） > Firewall policies（防火墙策略）。在 Network（网络） 中，使用以下配置创建网络策略：

   选择器	运算符	值	操作
   Access Private App	is	Present	Allow（允许）

2. 使用仪表板或 API 更新策略的优先顺序。

由私有主机名定义的 Access 应用程序优先于由私有 IP 定义的 Access 应用程序。例如，假设 App-1 指向 wiki.internal.local，App-2 指向 10.0.0.1，但 wiki.internal.local 解析为 10.0.0.1。转到 wiki.internal.local 的用户将永远不会匹配 App-2；他们将完全基于 App-1 Access 策略（以及 Gateway 策略）被允许或阻止。

Browser Isolation 与使用私有 IP 或主机名且端口非 443 的自托管私有应用程序不兼容。尝试通过非 443 端口访问自托管应用程序将导致出现 Gateway 拦截页面。

要对位于私有 IP 地址且使用非 443 端口的应用程序使用 Browser Isolation，请改为配置私有网络应用程序。

从 Chrome 142 ↗ 开始，浏览器会限制来自网站对本地 IP 地址的请求，包括 Gateway 初始解析的 IP（initial resolved IP） CGNAT 范围（100.80.0.0/16）。由于该范围属于 100.64.0.0/10，Chrome 将这些地址归类为属于本地网络。当从公共 IP 加载的网站向通过初始解析 IP 解析的域发出子请求时，Chrome 会将此视为“公共到本地网络”请求，并显示提示要求用户允许访问本地网络上的设备。在用户接受此提示之前，Chrome 将拦截对这些域的请求。

这通常发生在出站（Egress）策略与广泛使用的域（例如 cloudfront.net 或 github.com）匹配时，导致来自公共页面的子请求解析为 100.80.0.0/16 范围。

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

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

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

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

• Chrome 146+（覆盖 IP 地址空间分类）：使用 LocalNetworkAccessIpAddressSpaceOverrides ↗ Chrome 企业版策略将 100.80.0.0/16 范围重新归类为公共（public）。这是最具针对性的修复，因为它仅更改初始解析 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。此方法适用于个人用户，但不适用于企业级部署。