跳转到内容
搜索文档
↵选择
↑↓导航
ESC关闭

执行顺序

最后更新 查看 MarkdownAgent 设置

借助 Cloudflare Gateway，您可以启用并配置 DNS、网络和 HTTP 策略的任意组合。

flowchart TB
    %% Accessibility
    accTitle: Gateway 执行顺序
    accDescr: 描述 Gateway 策略执行顺序的流程图。

 subgraph Resolution["解析"]
        dns2["1.1.1.1"]
        dns4["自定义解析器"]
        dns3["解析器策略 <br>（仅限 Enterprise 用户）"]
        internal["内部 DNS"]
  end
 subgraph DNS["DNS"]
        dns1["DNS 策略"]
        Resolution
  end
 subgraph HTTP["HTTP 策略"]
        http1{{"“不检查”策略 (Do Not Inspect)"}}
        http2["“隔离”策略  <br>（带浏览器隔离附加组件）"]
        http3["“允许”、“拦截”、“不扫描”、“隔离区”和“重定向”策略，DLP 以及防病毒扫描"]
        https["HTTP 还是 HTTPS？"]
  end
 subgraph Proxy["代理"]
        HTTP
        network1["网络策略"]
        nonhttp["非 HTTP(S) 流量"]
  end
 subgraph Egress["出站 (Egress)"]
        egress1["出站策略 <br>（仅限 Enterprise 用户）"]
  end
    start(["流量"]) --> dns0[/"DNS 查询"/] & http0["网络连接"]
    dns0 ----> dns1
    dns1 -- 解析自 --> dns2
    dns1 --> dns3
    dns3 -- 解析自 --> dns4
    dns2 -----> internet(["互联网"])
    dns4 -----> internet
    dns4 ---> cloudflare["私有网络服务 <br>（Cloudflare Tunnel、Cloudflare WAN、Cloudflare Mesh）"]
    http1 -- 不检查 --> internet
    http1 -- 检查 --> http2
    http2 --> http3
    http0 --> magic["Cloudflare Network Firewall（仅限 Enterprise 用户）"]
    magic --> egress1
    egress1 --> tcp["检查源站可用性 (TCP SYN)"]
    tcp --> network1
    http3 --> internet
    https -- HTTPS --> http1
    https -- HTTP --> http2
    network1 --> https & nonhttp
    dns3 -- 解析自 --> internal & dns2
    nonhttp -----> internet

    https@{ shape: hex}
    http0@{ shape: lean-r}

连接建立

当用户通过 Gateway 连接到服务器时，Gateway 首先与目标服务器在用户请求的端口上建立 TCP 连接。由于 TCP 流量由 Cloudflare 代理，因此 Gateway 与源站建立的连接独立于用户与 Gateway 建立的连接。这意味着 Gateway 会为用户的连接分配一个新的源 IP 和端口，且用户的 TCP 握手详情不会包含在与源站服务器的 TCP 握手中。

如果与目标服务器的 TCP 连接成功，Gateway 将应用策略。如果 Gateway 策略允许该连接，Gateway 将把用户连接到目标服务器。如果 Gateway 策略拦截了该连接，Gateway 将终止连接，并且不会在用户与目标服务器之间发送任何数据。如果与目标服务器的 TCP 连接不成功，Gateway 将不运行任何策略，并重试从用户到服务器的 TCP 连接。

flowchart TD
    %% Accessibility
    accTitle: Gateway 代理工作原理
    accDescr: 描述 Gateway 代理如何使用 Happy Eyeballs 算法建立 TCP 连接并代理用户流量的流程图。

    %% Flowchart
    A[用户的设备向 Gateway 发送 TCP SYN] --> B[Gateway 向源站服务器发送 TCP SYN]
    B --> C{{源站服务器响应 TCP SYN-ACK？}}
    C -->|是| E[TCP 握手完成]
    C -->|否| D[连接失败]
    E --> F{{是否允许连接？}}
    F -->|允许策略| G[Gateway 双向代理流量]
    F -->|拦截策略| H[连接被防火墙策略拦截]

    %% Styling
    style D stroke:#D50000
    style G stroke:#00C853
    style H stroke:#D50000

无论连接是否成功，与 Zero Trust 的连接都将始终显示在您的 Zero Trust 网络会话日志中。由于 Gateway 不会检查失败的连接，因此它们不会显示在您的 Gateway 活动日志中。

使用 Cloudflare Network Firewall 过滤 TCP SYN 数据包

由于 Gateway 在评估策略之前会向目标服务器发送 TCP SYN，因此 Gateway 网络或 HTTP 拦截策略不会阻止初始 TCP SYN 到达目标服务器。如果您需要阻止向特定目标 IP 地址发送 TCP SYN 数据包，您可以创建 Cloudflare Network Firewall 规则以在数据包级别拦截流量。如执行流程图所示，Cloudflare Network Firewall 会在 Gateway 检查源站可用性之前评估流量。

要拦截指向特定目标的 TCP SYN 数据包：

  1. 在 Cloudflare 仪表板 ↗中，转到 Zero Trust > Firewall policies（防火墙策略） > Custom policies（自定义策略）。
  2. 选择 Add a policy（添加策略）。
  3. 使用您要拦截的目标 IP 地址或 CIDR 范围创建一条规则。例如，要拦截指向 10.0.0.0/8 的所有流量，请使用表达式 ip.dst in {10.0.0.0/8}，并配合 **Block（拦截）**操作。
  4. 选择 Add new policy（添加新策略）。

有关创建数据包过滤规则的更多信息，请参阅添加策略。

策略生成器之间的优先级

Gateway 按以下顺序应用您的策略：

  1. 在解析前评估选择器的 DNS 策略
  2. 解析器策略（如果适用）
  3. 在解析后评估选择器的 DNS 策略
  4. 出站策略（如果适用）
  5. 网络策略
  6. HTTP 策略

DNS 和解析器策略是独立的。例如，如果您通过 DNS 策略拦截了某个网站，但未创建相应的 HTTP 策略，则用户在知道其 IP 地址的情况下仍可访问该网站。

HTTP/3 流量

对于代理的 HTTP/3 流量，Gateway 按以下顺序应用您的策略：

  1. DNS 策略
  2. 网络策略
  3. HTTP 策略

策略生成器内的优先级

DNS 策略

Gateway 首先按照 DNS 解析的顺序评估 DNS 策略，然后按照优先顺序进行评估。

收到 DNS 查询时，Gateway 会评估具有解析前选择器的策略，解析 DNS 查询，然后评估具有解析后选择器的策略。这意味着在 DNS 解析之前评估选择器的策略具有优先权。例如，以下策略集将拦截 example.com：

优先级 选择器 运算符 值 操作
1 解析的国家/地区 IP 地理定位 is United States 允许
2 域 is example.com 拦截

尽管明确的“允许”策略排在第一位，但策略 2 具有优先权，因为 Domain（域）选择器在 DNS 解析之前进行评估。

如果策略同时包含解析前和解析后选择器，Gateway 将在 DNS 解析后评估整个策略。有关何时评估每个选择器的信息，请参阅 DNS 选择器列表。

网络策略

Gateway 按照优先顺序评估网络策略。

HTTP 策略

Gateway 根据操作类型和优先顺序的组合来应用 HTTP 策略：

  1. 首先评估所有“不检查 (Do Not Inspect)”策略，按优先顺序排列。
  2. 如果没有策略匹配，则按优先顺序评估所有“隔离 (Isolate)”策略。
  3. 按优先顺序评估所有“允许 (Allow)”、“拦截 (Block)”和“不扫描 (Do Not Scan)”策略。
  4. 评估 HTTP 请求的主体，包括数据防泄露（DLP）、防病毒扫描和文件沙箱。

这种执行顺序允许 Gateway 首先确定是否应该进行解密。如果网站与“不检查”策略匹配，它将自动允许通过 Gateway 并绕过所有其他 HTTP 策略。

接下来，Gateway 根据您的“隔离”策略检查解密后的流量。当用户发出的请求触发了“隔离”策略时，该请求将被重定向到远程浏览器。

接下来，Gateway 评估所有“允许”、“拦截”和“不扫描”策略。这些策略适用于隔离和非隔离流量。例如，如果 example.com 被隔离且 example.com/subpage 被拦截，Gateway 将在远程浏览器内部拦截该子页面（example.com/subpage）。

最后，Gateway 通过根据 DLP 策略评估 HTTP 请求的主体，并运行防病毒扫描和文件沙箱来进行检查。如果存在 DLP 拦截策略，Gateway 最终采取的操作可能与它最初记录的操作不匹配。有关更多信息，请参阅 DLP 策略优先级。

解析器策略

当存在解析器策略时，Gateway 首先评估具有解析前选择器的任何 DNS 策略，然后根据您的解析器策略的优先顺序路由任何 DNS 查询，最后评估具有解析后选择器的任何 DNS 策略。

无策略匹配时的默认行为

如果流量与任何明确的“允许”或“拦截”策略都不匹配，Gateway 将应用以下默认值：

策略类型 默认操作 描述
DNS 允许 DNS 查询通过配置的解析器正常解析。
网络 允许 TCP 和 UDP 连接允许通过 Gateway 代理。
HTTP 允许 HTTP 和 HTTPS 请求是允许的。但是，如果您在 HTTP 策略设置中配置了默认的 Block（拦截）操作，未匹配的流量则会被拦截。

由于默认行为是允许未匹配的流量，因此 Gateway 遵循宽松模式。要切换到严格模式（默认拦截，例外允许），请在相关策略生成器中以最低优先级创建一条包含一切（catch-all）的拦截策略，并在其上方添加特定的允许策略。

优先顺序

优先顺序是指 DNS、网络或 HTTP 策略生成器中各个策略的优先级。Gateway 按照升序评估策略，从最低值开始。

优先顺序遵循首次匹配原则。一旦流量与“允许”或“拦截”策略匹配，评估就会停止，后续政策无法覆盖该决定。因此，Cloudflare 建议将最具针对性的策略和例外分配最高的优先级，而将最通用的策略分配最低的优先级。

Cloudflare 仪表板

在 Cloudflare 仪表板中，策略按照在列表中的从上到下的顺序优先执行。策略以优先级 1 开始并向上累加。您可以通过在仪表板中拖放单个策略来修改优先顺序。

Cloudflare API

要使用 Cloudflare API 更新策略的优先级，请使用 Update a Zero Trust Gateway rule 端点来更新 precedence field。

DLP 策略优先级

对于具有 DLP 策略的 Gateway 配置，Gateway 将基于首次匹配对流量进行过滤和记录，然后扫描 HTTP 请求的主体以查找匹配内容。由于首次匹配原则，Gateway 可能会对流量执行并记录一个决定，然后又执行一个与之矛盾的决定。例如，如果流量首先被 HTTP 允许策略允许，随后又被 DLP 拦截策略拦截，Gateway 将记录初始的 Allow（允许）操作，尽管最终拦截了该请求。

Access 应用程序

如果 Gateway 流量正走向被保护为 Access 应用程序的私有 IP 地址，该流量仍将由目标应用程序的 Access 策略进行评估，即使 Gateway 允许策略首先匹配也是如此。与流量匹配的 Gateway 拦截策略将终止任何其他策略评估。这是预期行为。Gateway 允许策略不会覆盖或绕过 Access 策略。

示例

假设您有一组按照以下优先顺序排列的策略：

  • DNS 策略：

    优先级 选择器 运算符 值 操作
    1 主机 is example.com 拦截
    2 主机 is test.example.com 允许
    3 域 matches regex .\ 拦截

  • HTTP 策略：

    优先级 选择器 运算符 值 操作
    1 主机 is example.com 拦截
    2 主机 is test2.example.com 不检查

  • 网络策略：

    优先级 选择器 运算符 值 操作
    1 目的端口 is 80 拦截
    2 目的端口 is 443 允许
    3 SNI 域 is test.example.com 拦截

当用户访问 https://test.example.com 时，Gateway 会执行以下操作：

  1. 根据 DNS 策略评估 DNS 请求：

    1. 策略 #1 不匹配 test.example.com — 继续检查策略 #2。
    2. 策略 #2 匹配，因此允许 DNS 解析。
    3. 策略 #3 不进行评估，因为已经有了明确的匹配。

  2. 根据网络策略评估 HTTPS 请求：

    1. 策略 #1 不匹配，因为端口 80 用于标准 HTTP，而不是 HTTPS。
    2. 策略 #2 匹配，因此该请求被允许并代理到上游服务器。
    3. 策略 #3 不进行评估，因为已经有了明确的匹配。

  3. 根据 HTTP 策略评估 HTTPS 请求：

    1. 首先评估策略 #2，因为“不检查”始终比“允许”和“拦截”具有优先权。由于没有匹配项，继续检查策略 #1。
    2. 策略 #1 与 test.example.com 不匹配。由于没有匹配的“拦截”策略，该请求通过了 HTTP 过滤器。

因此，用户能够连接到 https://test.example.com。

优先级计算

在 Cloudflare 仪表板 ↗中排列策略时，Gateway 会自动计算重新排列策略的优先级。

使用 API 创建策略时，除非在策略中明确定义了优先级，否则 Gateway 将为策略分配从 1000 开始的优先级。每当在排序底部添加新策略时，Gateway 都会计算账户中当前的最高优先级，并将 1 到 100 之间的随机整数相加到最高优先级上，以使其声称拥有账户中的最大优先级。要手动更新策略的优先级，请使用 Update a Zero Trust Gateway rule 端点。您可以将策略的优先级设置为尚未使用的任何值。

在使用 Terraform 时，在 Cloudflare 仪表板或通过 API 更改顺序可能会导致配置问题。

使用 Terraform 管理优先级

您可以使用 Terraform 管理 Gateway 策略的执行顺序。使用第 5 版的 Terraform Cloudflare 提供商，Gateway 用户可以在 Terraform 文件中列出其策略，并赋予任何所需的整数优先级值。Cloudflare 建议从 1000 的优先级开始，并在每个策略的优先级之间留出额外的空间，以便应对未来可能添加的策略。例如：

resource "cloudflare_zero_trust_gateway_policy" "policy_1" {
  account_id = var.cloudflare_account_id
  # other attributes...
  precedence = 1000
}

resource "cloudflare_zero_trust_gateway_policy" "policy_2" {
  account_id = var.cloudflare_account_id
  # other attributes...
  precedence = 2000
}

resource "cloudflare_zero_trust_gateway_policy" "policy_3" {
  account_id = var.cloudflare_account_id
  # other attributes...
  precedence = 3000
}

为避免使用 Terraform 重新排序策略时出现优先级计算错误，您应该在运行 terraform plan 和 terraform apply 之前每次只移动一个策略。如果您同时使用 Terraform 和 Cloudflare 仪表板或 API，请在 Terraform 中重新排序策略之前，先通过 terraform refresh 同步您的策略。或者，您也可以将账户设置为 Cloudflare 仪表板中的只读状态，仅允许使用 API 或 Terraform 进行更改。

这篇文档对您有帮助吗？