Cloudflare Tunnel 経由のエグレス

一部のサードパーティサービスは、アクセス制御リスト（ACL）に載っている特定の送信元 IP からの接続だけを受け付けます。非 Cloudflare の IP（たとえば ISP や AWS などのクラウドプロバイダーの IP）がすでに許可リストにある場合は、Cloudflare Tunnel 経由でトラフィックを流し、同じ IP から出るようにできます。これを送信元 IP の固定（source IP anchoring）と呼びます。既存のエグレス IP を、Cloudflare の専用エグレス IP を購入せずに使い続けられます。

たとえば、app.bank.com の銀行サービスが AWS の IP からのトラフィックを想定しているとします。AWS 環境に cloudflared をインストールし、app.bank.com の公開ホスト名ルートを追加します。ユーザーが Cloudflare One Client 経由で app.bank.com に接続すると、Gateway がネットワークポリシーを適用し、フィルタ済みトラフィックを Cloudflare Tunnel 経由で AWS へ送ります。そのあとトラフィックは、AWS のエグレス IP を使ってパブリックインターネットへ出ます。

    flowchart LR
      subgraph aws["AWS VPC"]
				cloudflared["cloudflared"]
      end
			subgraph cloudflare[Cloudflare]
			  gateway["Gateway"]
			end
			subgraph internet[インターネット]
				resolver[1.1.1.1]
				app[アプリケーション]
			end
      warp["Cloudflare One
				Client"]--"app.bank.com"-->gateway--"ネットワークトラフィック"-->cloudflared
			gateway<-.DNS ルックアップ.->resolver
			aws--AWS のエグレス IP -->app

ホスト名ベースのエグレスポリシーの詳細は、Cloudflare ブログ ↗ を参照してください。

ユーザートラフィックは、次のいずれかの方法で Gateway にオンランプする必要があります。

cloudflared を使って、プライベートネットワークを Cloudflare に接続 します。たとえば AWS からトラフィックを出したい場合は、AWS VPC のプライベート CIDR ブロックを接続します。

公開ホスト名を Cloudflare Tunnel 経由でルーティングするには、次の手順を実行します。

1. Cloudflare ダッシュボードで Networking > Routes を開きます。

   Routes を開く ↗

2. Create hostname route を選択します。

3. Hostname に、アプリケーションを表す公開ホスト名を入力します（例: app.bank.com）。ホスト名はパブリックインターネットから到達できる必要があります。

4. Tunnel で、プライベートネットワークを Cloudflare に接続している Cloudflare Tunnel を選択します。

5. Create route を選択します。

WARP の Split Tunnels 設定で、次の IP アドレスを WARP トンネル経由で Gateway へルーティングします。

ユーザーが公開ホスト名ルートに接続すると、Gateway は DNS クエリに対して、次の範囲から 初期解決 IP（initial resolved IP） を割り当てます。

• IPv4: 172.64.128.0/20
• IPv6: 2606:4700:0cf1:4000::/64

これがデフォルトの範囲です。既存ネットワークと衝突する場合は、IPv4 向けに カスタムの初期解決 IP 範囲を設定 できます。

Gateway のネットワークエンジンは OSI モデル ↗ のレイヤー 3 / レイヤー 4 で動作します。ここで使えるのはホスト名ではなく IP アドレスだけです。初期解決 IP は合図として働きます。パケットの宛先 IP がこの範囲に入ると、Gateway はその IP が公開ホスト名ルートに対応すると判断し、該当する Cloudflare Tunnel 経由でトラフィックを送ります。

初期解決 IP を Cloudflare One Client 経由でルーティングするには、次の手順を実行します。

WARP の デバイスプロファイル で、初期解決 IP が WARP トンネル経由でルーティングされるよう Split Tunnels を設定します。設定内容は Split Tunnels のモード によって異なります。

• Exclude mode: Split Tunnels のリストから 100.64.0.0/10 を削除します。Cloudflare One サービスで明示的に使っていない IP 範囲を戻す ことを推奨します。これにより、CGNAT アドレス空間を使う既存のプライベートネットワーク設定との衝突リスクを下げられます。
• Include mode: 次の IP アドレスを Split Tunnel のエントリとして追加します。
  • IPv4: 172.64.128.0/20
  • IPv6: 2606:4700:0cf1:4000::/64

  これがデフォルトの範囲です。既存ネットワークと衝突する場合は、IPv4 向けに カスタムの初期解決 IP 範囲を設定 できます。

プライベートネットワークの CIDR ブロックも、WARP トンネル経由でルーティングする必要があります。設定例の詳細は、プライベートネットワークを接続する を参照してください。

Gateway のネットワークポリシー を作り、ポート 443 の公開ホスト名向け HTTPS トラフィックをフィルタできます。たとえば app.bank.com を、特定のユーザーまたはグループだけが AWS のエグレス IP 経由で使えるようにするには、許可ポリシーとそれ以外をブロックするポリシーの 2 つを作成します。

1. 社員を許可します。

   セレクター	演算子	値	論理演算	アクション
   SNI	in	app.bank.com	And	Allow
   User Email	matches regex	.*@example.com

2. ポート 443 でそれ以外をブロックします。

   セレクター	演算子	値	アクション
   SNI	in	app.bank.com	Block

Gateway は、443 以外のポートではホスト名ベースのフィルタリングに対応していません。すべてのポートで app.bank.com 宛てトラフィックをブロックするには、Destination IP セレクターを使い、app.bank.com の公開 IP 範囲を指定します。

デバイスからブラウザーを開き、app.bank.com にアクセスします。

Gateway の DNS ログ で app.bank.com を検索できます。DNS response details に、公開の解決済み IP と 初期解決 IP が表示されるはずです。Cloudflare Tunnel のログ で、リクエストがトンネル経由で公開の解決済み IP へルーティングされていることも確認できます。

Chrome 142 ↗ 以降、ローカルネットワークアクセス（Local Network Access、LNA）は、Web サイトからローカル IP アドレスへのリクエストを制限します。LNA は Chromium エンジン層で実装されているため、Google Chrome だけでなく、Chromium ベースのすべてのブラウザー（例: Microsoft Edge、Brave、Opera）に影響します。Gateway の 初期解決 IP 範囲が、まだキャリアグレード NAT（CGNAT）アドレス空間（100.64.0.0/10）から割り当てられているアカウントで、この問題が起きることがあります。例として、レガシーのデフォルト範囲 100.80.0.0/16 や、CGNAT 空間内に設定したカスタム範囲です。これらのブラウザーは、該当アドレスをローカルネットワークに属すると分類します。公開 IP から読み込んだ Web サイトが、この空間の初期解決 IP 経由で解決したドメインへサブリクエストを送ると、ブラウザーは公開ネットワークからローカルネットワークへのリクエストとして扱い、ローカルネットワーク上のデバイスへのアクセスを許可するようユーザーに確認します。ユーザーがこのプロンプトを許可するまで、ブラウザーはこれらのドメインへのリクエストをブロックします。

この問題は、広く使われるドメイン（cloudfront.net や github.com など）に Egress ポリシーが一致し、公開ページからのサブリクエストが CGNAT 空間へ解決されるときに、よく起きます。

現在のデフォルトの初期解決 IP 範囲（172.64.128.0/20）を使っているアカウントは影響を受けません。この範囲は CGNAT ではなく、Cloudflare の公開アドレス空間だからです。このデフォルトが変わる前に作成したアカウント、またはカスタムの CGNAT 空間範囲を設定したアカウントでは、次のブラウザー回避策に頼るのではなく、初期解決 IP を設定する を参照して、CGNAT 以外の範囲へ移してください。

以下の回避策は Google Chrome Enterprise ポリシーを使います。組織が別の Chromium ベースブラウザーを管理している場合は、同等の制御について、そのブラウザーのエンタープライズポリシーのドキュメントを確認してください。

影響を受けるリクエストが iframe 内から発生する場合（例: サードパーティポータルに埋め込まれたアプリケーション）、親フレームにブラウザーのプロンプトを表示するには、iframe が local-network-access 権限を宣言する必要があります。

• Chrome 142〜144: iframe 要素に allow="local-network-access" 属性を使います。
• Chrome 145 以降: 権限は allow="local-network" と allow="loopback-network" に分かれました。

iframe が入れ子になっている場合は、チェーン内のすべての iframe に適切な属性が必要です。サードパーティアプリケーションは自身の iframe 属性を制御するため、エンドユーザー側では設定できないことがあります。

この問題を避けるには、次のいずれかを選びます。

• IP アドレス空間の分類を上書きする（Chrome 146 以降）: LocalNetworkAccessIpAddressSpaceOverrides ↗ Chrome Enterprise ポリシーを使い、CGNAT 空間の初期解決 IP 範囲（例: 100.80.0.0/16）を公開として再分類します。セキュリティチェック全体を無効にするのではなく、初期解決 IP 範囲の分類だけを変えるため、いちばん対象を絞った対処です。
• 特定の URL を許可する（Chrome 140 以降）: LocalNetworkAccessAllowedForUrls ↗ Chrome Enterprise ポリシーを使い、特定の Web サイトをローカルネットワークアクセスのチェックから除外します。すべての URL でチェックを無効にする場合、https://* も有効なエントリです。
• 特定の URL を許可する（Chrome 146 以降）: LocalNetworkAllowedForUrls ↗ Chrome Enterprise ポリシーを使います。Chrome 146 以降、LocalNetworkAccessAllowedForUrls の代わりになります。
• ローカルネットワークアクセス制限をオプトアウトする（Chrome 142〜152）: LocalNetworkAccessRestrictionsTemporaryOptOut ↗ Chrome Enterprise ポリシーを使い、ローカルネットワークアクセス制限を完全にオプトアウトします。一時的なポリシーで、Chrome 152 以降は削除されます。
• Chrome の機能フラグを無効にする: chrome://flags を開き、Local Network Access Checks フラグを Disabled にします。個人ユーザー向けの方法で、エンタープライズ全体への展開には向きません。