应用程序和应用类型

Gateway 允许您基于应用程序和应用类型创建 DNS、Network 和 HTTP 策略。由于单个应用程序通常跨越多个主机名，按名称选择应用程序比为每个主机名编写单独的规则更容易。您可以选择单个应用程序或应用类型来过滤网络上的特定流量。

当您在 Gateway 策略生成器中选择 Application（应用程序） 选择器时，Value（值） 字段将包括所有受支持的应用程序及其各自的应用类型。或者，您可以使用 Gateway API 来获取应用程序、应用类型和 ID 编号的列表。

要在 Cloudflare One 中管理整合的应用程序列表，您可以使用应用程序库。

你可以在应用程序库中创建自定义应用程序，并在 DNS、HTTP 和网络策略现有的 Application（应用程序） 选择器中按名称选择它。自定义应用程序和 Cloudflare 托管应用程序可以出现在同一条件中。自定义应用程序仅在拥有它的账户中可用。

对于 API 和 Terraform 规则，请将应用程序已分配的数字 ID 与现有应用程序字段一起使用，例如 app.ids、app.hosts_ids 和 app.supports_ids。创建时输入的人类可读 Application ID（应用程序 ID） 不是规则表达式中使用的数字 ID。

要检索自定义应用程序 ID，请使用 GET /accounts/{account_id}/resource-library/applications 列出账户中的应用程序。旧版 Gateway app_types 端点返回 Cloudflare 托管目录，不包含自定义应用程序。

例如，将 <CUSTOM_APPLICATION_NUMERIC_ID> 替换为数字 ID 以匹配该应用程序：

any(app.ids[*] in {<CUSTOM_APPLICATION_NUMERIC_ID>})

编辑应用程序的网络标识符后，引用该应用程序的规则会在定义传播到 Gateway 后匹配更新后的流量。你无需更换其 ID 或重新创建规则。只要仍有 Gateway 规则或可复用配置文件引用自定义应用程序（包括已关闭的规则），就无法删除该应用程序。请参阅删除自定义应用程序。

当主机名或目标 IP 与定义匹配时，Gateway 会将该流量匹配为自定义应用程序。如果定义同时包含主机名和 IP 子网，两者可以独立匹配。每个字段内的多条条目也是替代关系。

主机名会匹配指定域名及其子域名。例如，example.com 会同时匹配 example.com 和 api.example.com。如果需要限制自定义应用程序的范围，请选择更具体的主机名。

在 HTTP 和网络策略中，已配置的端口协议会在主机名或 IP 匹配之上增加限制。目标还必须匹配其中一个已配置的端口/协议对或包含两端的范围。如果 Port protocols（端口协议） 为空，该定义适用于任何端口和协议。仅端口/协议匹配不会标识应用程序。

例如，定义一个自定义应用程序，主机名为 crm.example.com，IP 子网为 192.0.2.0/24，端口协议为 tcp/443：

DNS 策略会在解析前匹配查询主机名，也可以在解析后匹配已解析的 IP 地址。DNS 应用程序匹配不使用应用程序的端口/协议约束，因为 DNS 查询无法识别后续连接的目标端口。对于上述示例应用程序，即使后续连接使用端口 8443，对 crm.example.com 的查询也可以匹配。

支持主机名标识应用程序依赖项。Gateway 会将它们包含在 Allow（允许）策略中，并从 Block（阻止）策略中排除，行为与 Cloudflare 托管应用程序的支持主机名相同。添加支持主机名并不能替代主主机名或 IP 子网的要求。主机名合计限制、IP 子网限制和端口格式请参阅自定义应用程序限制。

Gateway 将应用程序归入以下应用类型组中：

像 Google Drive 这样的应用程序会使用其自身的主机名（例如 drive.google.com）以及其他应用程序共享的资源（例如用于登录的 accounts.google.com）。Gateway 将这些分离为主机名和支持主机名，以便您可以独立控制每个应用程序的行为。

主机名是应用程序核心且不被其他应用程序使用的域。这些是您拦截应用程序时 Gateway 拦截的域。应用库在应用程序的 Hostnames（主机名）表格中公开了这些主机名。

支持主机名是应用程序依赖的用于内容分发、身份验证或第三方集成的共享资源。由于多个应用程序共享这些主机名，拦截它们可能会导致意外的副作用。

例如，假设 file-sharing-service.com 依赖 content-delivery.com。如果您允许访问 file-sharing-service.com 及其关联的子域但不允许访问 content-delivery.com，当 Gateway 匹配流量时，file-sharing-service.com 的某些功能可能会损坏。

为了防止这种情况，Gateway 仅在 Allow（允许）策略中使用支持主机名 —— 它将允许支持主机名连接但不会拦截它们。例如，许多 Google 应用程序使用 accounts.google.com 进行身份验证。如果您为将 accounts.google.com 列为支持主机名的应用程序创建 Allow 策略，Gateway 将同时允许 accounts.google.com 和该应用程序自身的域。

当您在 HTTP 策略中使用带有 is 运算符的 Application（应用程序）选择器时，您可以选择特定操作和动作以匹配应用程序流量。支持的应用程序和操作包括：

有关更多信息，请参阅应用程序细粒度控制。

重叠的主机名最常见于拥有众多应用程序的供应商，例如 Google 或 Meta。当您在 Gateway 策略中使用 Application 选择器时，Gateway 采取的动作将被限制在定义的特定应用程序中。Gateway 还会记录使用相同主机名的其他应用程序，但除非策略匹配了该应用程序，否则它不会采取动作。例如，Facebook 和 Facebook Messenger 应用程序均使用 chat-e2ee.facebook.com 主机名。在评估发往 Facebook Messenger 应用程序的流量时，Gateway 将仅对 Facebook Messenger 流量采取动作，但可能会同时记录 Facebook 和 Facebook Messenger 应用程序。

为了确保 Gateway 按照您期望的优先级评估流量，请根据执行顺序将您最具体的策略排序为最高优先级。

Gateway 会自动将与 TLS 解密不兼容的应用程序归类为 Do Not Inspect（不检测） 应用类型。随着 Cloudflare 识别不兼容的应用程序，Gateway 将定期更新此应用类型以添加新应用程序。为确保 Gateway 不拦截任何当前或未来不兼容的流量，您可以创建一个 Do Not Inspect（不检测） HTTP 策略，并选择整个 Do Not Inspect（不检测） 应用类型。

当使用应用程序库管理应用程序时，Do Not Inspect（不检测） 应用程序将显示在相应的应用程序下方。例如，应用库会将 Google Drive (Do Not Inspect)（不检测） 归组在 Google Drive 下。

由于各种原因，应用程序可能与 TLS 解密不兼容：

• Certificate pinning（证书固定）：证书固定是 一种安全机制，通过硬编码应用程序期望收到的证书信息，防止 Internet 上的路径攻击。如果收到错误的证书，即使该证书受系统信任，应用程序也会拒绝连接。

• 非 Web 流量：有些应用程序通过 TLS 发送非 Web 流量，例如用于语音和视频通话的会话发起协议（SIP）以及用于聊天的可扩展消息与存在协议（XMPP）。Gateway 无法检查这些协议。

为了优化 Microsoft 365 应用程序和服务的性能，您可以通过开启 Microsoft 365 流量集成来绕过 TLS 解密。这将为 Microsoft 指定的所有 Microsoft 365 域和 IP 地址 ↗创建一个 Do Not Inspect（不检测）策略。此策略还使用 Cloudflare 智能分析来识别其他未明确定义的 Microsoft 365 流量。

开启 Microsoft 365 集成：

1. 在 Cloudflare 仪表板 ↗中，前往 Zero Trust > Traffic policies（流量策略） > Traffic settings（流量设置） > Policy settings（策略设置）。
2. 在 Bypass decryption of Microsoft 365 traffic（绕过 Microsoft 365 流量的解密） 中，选择 Create policy（创建策略）。
3. 要验证策略是否已创建，请选择 View policy（查看策略）。或者，前往 Traffic policies（流量策略） > HTTP policies（HTTP 策略）。列表中将启用一个名为 Microsoft 365 Auto Generated 的策略。

所有未来的 Microsoft 365 流量都将绕过 Gateway 的记录和过滤。要禁用此行为，请关闭或删除该策略。

Terraform 用户可以使用 cloudflare_zero_trust_gateway_app_types_list 数据源获取应用类型列表。这允许您使用应用程序的名称而不是数字 ID 来创建 Gateway 策略。例如：

data "cloudflare_zero_trust_gateway_app_types_list" "gateway_apptypes" {
  account_id = var.cloudflare_account_id
}

locals {
  apptypes_map = merge([
    for c in data.cloudflare_zero_trust_gateway_app_types_list.gateway_apptypes.result :
    { (c.name) = c.id }
  ]...)
}

resource "cloudflare_zero_trust_gateway_policy" "zt_block_dns_apps" {
  account_id = var.cloudflare_account_id
  name       = "DNS Blocked apps"
  action     = "block"
  traffic    = "any(app.ids[*] in {${join(" ", [
    local.apptypes_map["Discord"],
    local.apptypes_map["GoToMeeting"],
    local.apptypes_map["Greenhouse"],
    local.apptypes_map["Zelle"],
    local.apptypes_map["Microsoft Visual Studio"]
  ])}})"
}