Skip to content

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

Cloudflare Gateway

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

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

インターネット向けトラフィック、または Cloudflare WAN(旧 Magic WAN)経由で Cloudflare ネットワークに入るプライベートトラフィックに対して、Cloudflare Network Firewall ポリシー(L3/4 トラフィックのフィルタリング用)とあわせて、ネットワークおよび HTTP の Gateway ポリシーを適用できます。さらに、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 version チェック を使い、Cloudflare One Client を実行していないデバイスを除外できます。

Selector Operator Value Logic Action
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 以外の on-ramp でユーザーを Cloudflare WAN にオンボードしている場合は、IPsec トンネルの IP アドレスを使ってデバイスを検査から除外できます。

Selector Operator Value Action
Source IP in 203.0.113.0/24 Do Not Inspect

DNS フィルタリング

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

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

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

flowchart LR
accTitle: DNS query flow
accDescr: Shows how DNS queries from Cloudflare WAN and Cloudflare Mesh flow through Gateway to internal 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}
  

アウトバウンドのインターネットトラフィック

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

  • RFC 1918 の IP またはデバイスを送信元とする TCP、UDP、ICMP トラフィック。
  • BYOIP または Leased IPs を送信元とし、ウェルノウンポート(0-1023)宛てになる TCP および UDP トラフィック。

デフォルトでは、パブリック IP 宛てのトラフィックはパブリックインターネット経由でルーティングされます。フィルタリング後に、特定のパブリック IP 範囲をパブリックインターネットではなく 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 空間、WARPBYOIP、または 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 Clamping) が正しく設定されていることを確認します。

HTTPS クエリがハングまたは失敗し、HTTP は動作する場合、MSS の値が高すぎるか未設定の可能性があります。カスタマー構内設備側でこの値を下げ、IKEESP の設定がもたらすオーバーヘッドに合わせてください。

役に立ちましたか?