Skip to content

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

Cloudflare Gateway

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

包括的な Secure Web Gateway である Cloudflare Gateway では、DNS、ネットワーク、HTTP、エグレスのトラフィックを検査するポリシーを設定できます。

インターネット向けトラフィック、または Cloudflare WAN（旧 Magic WAN）経由で Cloudflare ネットワークに入るプライベートトラフィックに対して、ネットワークおよび HTTP の Gateway ポリシーを、Cloudflare Network Firewall ポリシー（L3/4 トラフィックのフィルタリング用）と併用できます。さらに、Cloudflare WAN からの DNS クエリを解決 するよう Gateway を設定できます。

HTTPS フィルタリング

HTTPS トラフィックを検査するには、各クライアントデバイスに Cloudflare のルート証明書をインストールする必要があります。Cloudflare が TLS を復号 するには証明書が必要です。

証明書のインストール

対応デバイスでは、Cloudflare One Client を使って Cloudflare 証明書を自動インストール できます。Cloudflare One Client による証明書インストールに対応していないデバイスやアプリケーションでは、証明書を手動インストール できます。

検査から除外する

証明書をインストールできない、またはしたくない場合は、Do Not Inspect ポリシーを作成し、互換性のない Cloudflare WAN トラフィックを検査から除外するか、TLS 復号を完全に無効にできます。

Gateway は Cloudflare WAN トラフィックを区別できないため、Gateway ポリシーでトラフィックを照合するには、Cloudflare One Client チェック か、Cloudflare WAN に紐づく IP アドレスを使います。

たとえば、組織が Cloudflare One Client でデバイスを Cloudflare WAN にオンボードしている場合、OS バージョンチェック を使い、Cloudflare One Client を実行していないデバイスを除外できます。

セレクター 演算子 値 論理 アクション
Passed Device Posture Checks not in Windows (OS version) Or Do Not Inspect
Passed Device Posture Checks not in macOS (OS version) Or Do Not Inspect
Passed Device Posture Checks not in Linux (OS version) Or Do Not Inspect
Passed Device Posture Checks not in iOS (OS version) Or Do Not Inspect
Passed Device Posture Checks not in Android (OS version) Do Not Inspect

組織が Cloudflare One Client 以外のオンランプ でユーザーを Cloudflare WAN にオンボードしている場合は、IPsec トンネルの IP アドレスを使ってデバイスを検査から除外できます。

セレクター 演算子 値 アクション
Source IP in 203.0.113.0/24 Do Not Inspect

DNS フィルタリング

Cloudflare WAN ネットワークの DNS リゾルバーを、Gateway DNS リゾルバーの共有 IP アドレスに設定できます。Gateway DNS リゾルバーの IP は 172.64.36.1 と 172.64.36.2 です。

Cloudflare WAN からの DNS クエリを Gateway で解決すると、Gateway はプライベートな送信元 IP 付きでクエリを記録します。このプライベート送信元 IP を使い、内部 DNS レコード 向けのクエリに対して リゾルバーポリシー を作成できます。

次の図は、Cloudflare WAN と Cloudflare Mesh からの DNS クエリが、Gateway を経て内部 DNS に届く流れを示します。

flowchart LR
accTitle: DNS クエリの流れ
accDescr: Cloudflare WAN と Cloudflare Mesh からの DNS クエリが Gateway を経て内部 DNS に届く流れを示します。
subgraph subGraph0["データセンター"]
  direction TB
      InternalDNS(["内部 DNS"])
      ResolverPolicies["リゾルバーポリシー"]
      CloudflareGatewayDNSResolver["Gateway DNS リゾルバー"]
end
  ResolverPolicies -- 送信元内部 IP を</br>保持して使用 --> InternalDNS
  CloudflareGatewayDNSResolver -- <br> --> ResolverPolicies
  WarpConnector["Cloudflare Mesh"] -- DHCP/DNS リゾルバー --> IPSecTunnel["IPsec トンネル"]
  CloudflareWAN[Cloudflare WAN] -- DHCP/DNS リゾルバー --> IPSecTunnel
  IPSecTunnel -- 共有 IP エンドポイント --> CloudflareGatewayDNSResolver
  ResolverPolicies@{ shape: proc}
  WarpConnector@{ shape: in-out}
  CloudflareWAN@{ shape: in-out}

アウトバウンド Internet トラフィック

デフォルトでは、IPsec/GRE トンネル経由でルーティングされ、パブリック IP アドレス宛ての次のトラフィックが、Cloudflare Gateway でプロキシ / フィルタリングされます。

  • RFC 1918 ↗ の IP またはデバイスから発信された TCP、UDP、ICMP トラフィック。
  • BYOIP または Leased IPs から発信され、よく知られたポート（0-1023）宛ての TCP および UDP トラフィック。

デフォルトでは、パブリック IP 宛てのトラフィックはパブリック Internet 経由でルーティングされます。フィルタリング後に、特定のパブリック IP 範囲をパブリック Internet ではなく IPsec/GRE トンネル経由でルーティングしたい場合は、アカウントチームにお問い合わせください。

このトラフィックは、Cloudflare Gateway で定義した エグレスポリシー に従って Cloudflare から出ていきます。デフォルトでは、共有の Cloudflare パブリック IP 範囲から出ていきます。

プライベートトラフィック

デフォルトでは、IPsec/GRE トンネル経由でルーティングされ、Cloudflare Tunnel 背後のルート宛ての TCP、UDP、ICMP トラフィックが、Cloudflare Gateway でプロキシ / フィルタリングされます。

IPsec/GRE トンネル背後のルート宛てのトラフィックに Gateway フィルタリングを有効にするには、アカウントチームにお問い合わせください。

デフォルトのフィルタリング条件

有効にすると、次の条件を すべて 満たす TCP/UDP トラフィックが、Cloudflare Gateway でプロキシおよびフィルタリングされます。

  • 送信元および宛先 IP: 両方が RFC1918 ↗ 空間、WARP、BYOIP、または Leased IPs に含まれること。
  • 送信元ポート: 1023 より大きいクライアントポートであること。
  • 宛先ポート: よく知られたポート（1024 未満）であること。

カスタムのフィルタリング条件

デフォルト条件を上書きする、より具体的な一致を指定できます。

  • 送信元 IP プレフィックス: RFC1918 空間、BYOIP、または Leased IPs のサブセット。
  • 宛先 IP プレフィックス: RFC1918 空間、BYOIP、または Leased IPs のサブセット。
  • 宛先ポート: 0 から 65535 までの任意のポート。

Gateway 連携をテストする

Gateway が Cloudflare WAN 接続で正しく動作しているか確認するには、顧客構内機器の背後にあるホストからブラウザーを開き、https://ifconfig.me にアクセスします。

まだ Gateway をテスト中で、Cloudflare がデフォルトルートでない場合は、ルーターにポリシーベースルートを設定し、先に Cloudflare Gateway へトラフィックを送ってください。

HTTP Gateway Activity Logs にテストのエントリがあることを確認します。

次の内容を確認してください。

  • Destination IP: ifconfig.me のパブリック IP アドレスであること。
  • Source IP: ブラウザーを使っているホストのプライベート（WAN）アドレスであること。
  • Outbound connection: Cloudflare が代理でアドバタイズしているパブリック IP ではなく、Cloudflare WAN の IP アドレスから発信されていること。

これは Magic Transit With Egress Option を使う場合にも当てはまります。

さらに、http://ifconfig.me（非 TLS）と https://ifconfig.me（TLS）の両方をテストし、TCP 最大セグメントサイズ（MSS クランプ） が正しく設定されていることを確認します。

HTTPS のクエリがハングまたは失敗し、HTTP は成功する場合、MSS の値が高すぎるか未設定の可能性があります。顧客構内機器でこの値を下げ、IKE と ESP ↗ の設定によるオーバーヘッドに合わせてください。

役に立ちましたか？