Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

適用順序

最終更新 Markdown で表示Agent セットアップ

Gateway は、トラフィックが Cloudflare のグローバルネットワークを経由してインターネットへ向かうとき、決まった適用順序に従います。

flowchart TB
    %% Accessibility
    accTitle: Gateway の適用順序
    accDescr: Gateway ポリシーの適用順序を示すフローチャートです。

 subgraph Resolution["解決"]
        dns2["1.1.1.1"]
        dns4["カスタムリゾルバー"]
        dns3["Resolver ポリシー <br>（Enterprise のみ）"]
        internal["Internal DNS"]
  end
 subgraph DNS["DNS"]
        dns1["DNS ポリシー"]
        Resolution
  end
 subgraph HTTP["HTTP ポリシー"]
        http1{{"Do Not Inspect ポリシー"}}
        http2["Isolate ポリシー  <br>（Browser Isolation アドオン）"]
        http3["Allow、Block、Do Not Scan、Quarantine、Redirect ポリシー、DLP、アンチウイルススキャン"]
        https["HTTP または HTTPS？"]
  end
 subgraph Proxy["プロキシ"]
        HTTP
        network1["ネットワークポリシー"]
        nonhttp["HTTP(S) 以外のトラフィック"]
  end
 subgraph Egress["Egress"]
        egress1["Egress ポリシー <br>（Enterprise のみ）"]
  end
    start(["トラフィック"]) --> dns0[/"DNS クエリ"/] & http0["ネットワーク接続"]
    dns0 ----> dns1
    dns1 -- 解決先 --> dns2
    dns1 --> dns3
    dns3 -- 解決先 --> dns4
    dns2 -----> internet(["Internet"])
    dns4 -----> internet
    dns4 ---> cloudflare["プライベートネットワークサービス <br>（Cloudflare Tunnel、Cloudflare WAN、Cloudflare Mesh）"]
    http1 -- Do Not Inspect --> internet
    http1 -- Inspect --> 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 -->|Allow ポリシー| G[Gateway が双方向にトラフィックをプロキシ]
    F -->|Block ポリシー| 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 の Network または HTTP の Block ポリシーでは、最初の 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. Resolver ポリシー（該当する場合）
  3. 解決後に評価されるセレクターを持つ DNS ポリシー
  4. Egress ポリシー（該当する場合）
  5. ネットワークポリシー
  6. HTTP ポリシー

DNS ポリシーと Resolver ポリシーは独立しています。たとえば、DNS ポリシーでサイトをブロックしても、対応する HTTP ポリシーを作っていない場合、ユーザーは IP アドレスを知っていればそのサイトにアクセスできます。

HTTP/3 トラフィック

プロキシされた HTTP/3 トラフィック では、Gateway は次の順でポリシーを適用します。

  1. DNS ポリシー
  2. ネットワークポリシー
  3. HTTP ポリシー

ポリシービルダー内の優先順位

DNS ポリシー

Gateway は DNS ポリシーを、まず DNS 解決の順で評価し、次に 優先順位 で評価します。

DNS クエリを受信すると、Gateway は解決前セレクターを持つポリシーを評価し、DNS クエリを解決し、そのあと解決後セレクターを持つポリシーを評価します。つまり、DNS 解決前に評価されるセレクターを持つポリシーが優先されます。たとえば、次のポリシーセットは example.com をブロックします。

優先順位 セレクター 演算子 値 アクション
1 Resolved Country IP Geolocation is United States Allow
2 Domain is example.com Block

明示的な Allow ポリシーが先頭にあっても、Domain セレクターは DNS 解決前に評価されるため、ポリシー 2 が優先されます。

ポリシーに解決前セレクターと解決後セレクターの両方がある場合、Gateway はポリシー全体を DNS 解決後に評価します。各セレクターの評価タイミングは、DNS セレクターの一覧 を参照してください。

ネットワークポリシー

Gateway はネットワークポリシーを 優先順位 で評価します。

HTTP ポリシー

Gateway は HTTP ポリシーを、アクションの種類 と 優先順位 の組み合わせで適用します。

  1. すべての Do Not Inspect ポリシーを、優先順位の順に最初に評価します。
  2. 一致するポリシーがなければ、すべての Isolate ポリシーを優先順位の順に評価します。
  3. すべての Allow、Block、Do Not Scan ポリシーを優先順位の順に評価します。
  4. HTTP リクエストの本文を評価します。Data Loss Prevention（DLP）、アンチウイルススキャン、ファイルサンドボックスが含まれます。

この適用順序により、Gateway はまず復号するかどうかを判断できます。サイトが Do Not Inspect ポリシーに一致すると、Gateway を通過して自動的に許可され、ほかの HTTP ポリシーはすべてバイパスされます。

次に、Gateway は復号したトラフィックを Isolate ポリシーと照合します。ユーザーのリクエストが Isolate ポリシーに一致すると、リクエストは リモートブラウザー へ再ルーティングされます。

そのあと、Gateway はすべての Allow、Block、Do Not Scan ポリシーを評価します。これらのポリシーは、隔離されたトラフィックと隔離されていないトラフィックの両方に適用されます。たとえば、example.com が隔離され、example.com/subpage がブロックされている場合、Gateway はリモートブラウザー内でサブページ（example.com/subpage）をブロックします。

最後に、Gateway は HTTP リクエストの本文を DLP ポリシーと照合し、アンチウイルススキャンとファイルサンドボックスを実行します。DLP の Block ポリシーがある場合、Gateway が最終的に取るアクションは、最初に記録するアクションと一致しないことがあります。詳細は DLP ポリシーの優先順位 を参照してください。

Resolver ポリシー

Resolver ポリシー がある場合、Gateway はまず解決前セレクターを持つ DNS ポリシーを評価し、次に Resolver ポリシーの 優先順位 に従って DNS クエリをルーティングし、最後に解決後セレクターを持つ DNS ポリシーを評価します。

ポリシーに一致しない場合のデフォルト動作

トラフィックが明示的な Allow または Block ポリシーに一致しない場合、Gateway は次のデフォルトを適用します。

ポリシーの種類 デフォルトアクション 説明
DNS Allow DNS クエリは、設定したリゾルバーで通常どおり解決されます。
ネットワーク Allow TCP および UDP 接続は Gateway プロキシを通過できます。
HTTP Allow HTTP および HTTPS リクエストは許可されます。ただし、HTTP ポリシー設定 でデフォルトの Block アクションを設定している場合、一致しないトラフィックはブロックされます。

デフォルトは一致しないトラフィックの許可なので、Gateway は許可がデフォルトのモデルです。拒否がデフォルトのモデル（デフォルトでブロックし、例外だけ許可）にするには、該当するポリシービルダーの最も低い優先順位にキャッチオールの Block ポリシーを作り、その上に具体的な Allow ポリシーを追加します。

優先順位

優先順位とは、DNS、ネットワーク、HTTP の各ポリシービルダー内での、個々のポリシーの優先度です。Gateway は最も小さい値から昇順でポリシーを評価します。

優先順位は、最初に一致したものを採用する原則に従います。トラフィックが Allow または Block ポリシーに一致すると評価は止まり、以降のポリシーはその判定を上書きできません。そのため、Cloudflare は、最も具体的なポリシーと例外を優先順位の上位に、最も一般的なポリシーを下位に配置することを推奨します。

Cloudflare ダッシュボード

Cloudflare ダッシュボードでは、一覧の上から下が優先順位です。ポリシーは優先順位 1 から始まり、数が増えていきます。ダッシュボードで個々のポリシーをドラッグアンドドロップして、優先順位を変えられます。

Cloudflare API

Cloudflare API でポリシーの優先順位を更新するには、Update a Zero Trust Gateway rule エンドポイントで precedence フィールドを更新します。

DLP ポリシーの優先順位

DLP ポリシーがある Gateway 構成では、Gateway は最初に一致したものを採用してトラフィックをフィルタおよび記録し、そのあと HTTP リクエストの本文をスキャンして一致するコンテンツを探します。最初に一致したものを採用する原則のため、Gateway はトラフィックに対して判定を実行して記録したあと、矛盾する判定を行うことがあります。たとえば、トラフィックがまず Allow の HTTP ポリシーで許可され、その後 DLP の Block ポリシーでブロックされた場合、Gateway は最終的にリクエストをブロックしても、最初の Allow アクションを記録します。

Access アプリケーション

Gateway のトラフィックが Access アプリケーションとして保護されているプライベート IP アドレスへ向かう場合、Gateway の Allow ポリシーが先に一致していても、宛先アプリケーションの Access ポリシーで評価されます。一致した Gateway の Block ポリシーは、以降のポリシー評価を終了します。これは想定どおりの動作です。Gateway の Allow ポリシーは、Access ポリシーを上書きしたりバイパスしたりしません。

例

次の優先順位でポリシーが並んでいるとします。

  • DNS ポリシー:

    優先順位 セレクター 演算子 値 アクション
    1 Host is example.com Block
    2 Host is test.example.com Allow
    3 Domain matches regex .\ Block

  • HTTP ポリシー:

    優先順位 セレクター 演算子 値 アクション
    1 Host is example.com Block
    2 Host is test2.example.com Do Not Inspect

  • ネットワークポリシー:

    優先順位 セレクター 演算子 値 アクション
    1 Destination Port is 80 Block
    2 Destination port is 443 Allow
    3 SNI Domain is test.example.com Block

ユーザーが https://test.example.com へアクセスすると、Gateway は次の処理を行います。

  1. DNS リクエストを DNS ポリシーと照合します。

    1. ポリシー #1 は test.example.com に一致しません。ポリシー #2 の確認に進みます。
    2. ポリシー #2 が一致するため、DNS 解決は許可されます。
    3. すでに明示的な一致があるため、ポリシー #3 は評価されません。

  2. HTTPS リクエストをネットワークポリシーと照合します。

    1. ポート 80 は標準 HTTP 用であり HTTPS ではないため、ポリシー #1 は一致しません。
    2. ポリシー #2 が一致するため、リクエストは許可され、上流サーバーへプロキシされます。
    3. すでに明示的な一致があるため、ポリシー #3 は評価されません。

  3. HTTPS リクエストを HTTP ポリシーと照合します。

    1. Do Not Inspect は Allow および Block より 常に優先 されるため、ポリシー #2 を先に評価します。一致しないため、ポリシー #1 の確認に進みます。
    2. ポリシー #1 は test.example.com に一致しません。一致する Block ポリシーがないため、リクエストは HTTP フィルタを通過します。

したがって、ユーザーは https://test.example.com に接続できます。

優先順位の計算

Cloudflare ダッシュボード ↗ でポリシーを並べ替えると、Gateway は並べ替えたポリシーの優先順位を自動計算します。

API でポリシーを作成するとき、ポリシーに優先順位を明示していない場合、Gateway は 1000 から優先順位を割り当てます。新しいポリシーを順序の末尾に追加するたびに、Gateway はアカウント内の現在の最大優先順位を計算し、1000 に 1 から 100 の乱数を加えて、そのポリシーがアカウント内で最大の優先順位になるようにします。ポリシーの優先順位を手動で更新するには、Update a Zero Trust Gateway rule エンドポイントを使います。ポリシーの優先順位には、まだ使われていない任意の値を設定できます。

Cloudflare ダッシュボードまたは API で順序を変えると、Terraform 利用時に設定の不整合が起きることがあります。

Terraform で優先順位を管理する

Terraform で Gateway ポリシーの実行順を管理できます。Terraform Cloudflare プロバイダーのバージョン 5 では、希望する整数の優先順位を付けて、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 でポリシーを並べ替えるときは、優先順位の計算エラーを避けるため、1 件ずつ動かしてから terraform plan と terraform apply を実行してください。Terraform と Cloudflare ダッシュボードまたは API を併用する場合は、Terraform で並べ替える前に terraform refresh でポリシーを同期します。または、Cloudflare ダッシュボードでアカウントを読み取り専用 にし、API または Terraform だけで変更できるようにします。

役に立ちましたか？