应用程序和应用类型

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

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

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

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（证书固定）：证书固定是 a security mechanism used to prevent on-path attacks on the Internet by hardcoding information about the certificate that the application expects to receive. If the wrong certificate is received, even if it is trusted by the system, the application will refuse to connect.

• 非 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"]
  ])}})"
}