公開日: 2026-03-05 執筆: Steve Welham, Lauren Joplin, Jackson Kruger, Thea Heinen 所要時間: 約7分

概要

パブリックインターネットは、「単一のIPアドレスが論理的に一意の宛先を指す」という予測可能なルーティングの原則に依存しています。CloudflareのようなAnycastアーキテクチャでも、1つのIPが世界中の複数ロケーションからアナウンスされますが、そのIPの各インスタンスは同じサービスを表します。ルーティングテーブルはパケットの意図された行き先を常に正確に把握できます。

しかし企業ネットワークの世界では、IPアドレスは単なる名前に過ぎず（例: 「John Smith」）、同じ名前が複数存在すると問題になります。Cloudflare Oneを企業バックボーン向けの接続クラウドとして拡張する過程で、プライベートIPアドレス空間の重複という現実に直面しました。重複が発生する合理的な理由は複数あり、企業はこれらの衝突に対処する手段を必要とします。

この課題に対して、本日 Closed Beta の Automatic Return Routing（ARR）を発表します。ARRはCloudflare Oneのお客様向けのオプション機能で、ルーティングテーブルにIPルートを追加することなく、トラフィックを発信元に戻す柔軟性を提供します。これにより、1行のNATや複雑なVRF設定なしに、重複ネットワークの共存が可能になります。

曖昧性の問題

企業ネットワークにおけるIP重複は日常的に発生します。管理者にとって手間を生む代表的な3つのシナリオは次の通りです:

• 合併・買収: 二社が合併し、どちらもコアサービスに10.0.1.0/24を使っている。
• エクストラネット: パートナーやベンダー、顧客が自社の内部IPスキームでネットワーク接続するため、競合が避けられない。
• テンプレート化されたアーキテクチャ: SaaS提供者や小売ブランドが簡素化のために各拠点で同一IP空間を使う。

問題は、こうしたサイトがCloudflare経由でインターネットやデータセンターと通信しようとする時に発生します。同じ送信元IPを持つトラフィックが複数のサイトから来ると、帰りのパケットはアーキテクチャ上の壁にぶつかります。管理者は曖昧な宛先に対してどのようにルーティングするかを決めなければなりません。両方のルートをルーティングテーブルに入れると、どのパスが選択されるかは非決定的になります。標準的なルーティングテーブルの視点では、同一のパスを区別する方法がないためです。

（図の説明）Site AとSite Bの2つの支店が両方とも10.0.1.0/24を使用し、Cloudflareにパケットを送信します。インターネットからの応答パケットがCloudflareエッジに到達すると、ルーティングテーブルに同一の出口が2つあるため、誤ったサイトに送られることがあります。

従来の対処法が失敗する理由

この曖昧性を解決する方法はいくつかありますが、いずれも運用上の負担と複雑さを伴います。主要な従来手法は以下の通りです:

• Virtual Routing and Forwarding (VRF): トラフィックを隔離するために「仮想」ルーティングテーブルを作成します。分離には有効ですが、運用のオーバーヘッドを増やします。cross-VRF通信（ルートリーク）の管理は大規模では壊れやすく、複雑です。
• Network Address Translation (NAT): 重複するサブネットを管理外のIP空間から管理下のユニークなIPレンジにNATします。効果的ですが、新しいサイトやパートナーごとにマッピングの手作業が発生し、管理業務が増えます。

多くの顧客から聞く典型的なユースケースは、重複ネットワークがインターネットやプライベートデータセンターにアクセスする必要がある場合です。これを管理上の手間を増やさずにどう解くかが課題でした。

Automatic Return Routing (ARR) の紹介

ARRはこの問題に対する「ゼロタッチ」ソリューションとして設計しました。ARRはルーティングロジックをルーティングテーブルからステートフルなトラッキングへ移します。

ステートフルトラッキングとは何か？ 従来のネットワーキングでは、ルータは「忘れっぽい」（ステートレス）です。各パケットをまったくの初対面として扱い、直前に同じ送信元・宛先のパケットを見ていたとしても再度ルーティングテーブルを参照します。ステートフルでは、システムが記憶を持ち、複数のパケットが同じ「フロー」（2つのエンドポイント間の通信）に属することを認識し、そのフローが終了するまで重要な情報を保持します。

ARRでは、フローを初期化する際にもう1つだけ情報を記録します: そのフローを開始した“特定のトンネル”です。これにより、戻りトラフィックをルーティングテーブルを参照せずに同じトンネルに返送できます。従来の「このIPはどこにあるか？」という問いではなく、「この特定の会話はどこから来たか？」を問うようになります。

ARRのロジック

• Ingress（受信）: パケットがサイトからCloudflareエッジに到着します。接続はIPsecトンネル、GREトンネル、またはNetwork Interconnectなどの特定の接続経路です。
• Flow Matching（フローマッチ）: Cloudflare Virtual Networkはヘッダ検査により、そのパケットが既存のフローに一致するかを最初に確認します。
• Proxying（プロキシ処理）: 一致すれば、トラフィックに関する判断はすでにメモリに保存されているため、既存の経路に従ってパケットを転送します。
• Flow Setup（フロー設定）: 既存フローに一致しない場合、Cloudflare Oneのどのスタック（例: Gateway、DLP、Firewall）を通し、最終的な宛先を決定します。このときすべてのステートをメモリに保存し、どのトンネルがフローを開始したかも記録します。
• Symmetric Return（対称的な戻り）: 宛先からの戻りトラフィックが到着した際、Cloudflare Virtual Networkは既存のメモリ上のフローステートを使ってトラフィックをプロキシします。重要なのは、戻りパケットの宛先IPが異なるサイトで再使用されている可能性があるため、宛先IPを調べる必要がない点です。代わりにフローステート内にある発信元トンネル情報を参照して直接そのトンネルに配信します。

（図の説明）発信元オンランプでタグ付けされたメモリ内フローステートにより、重複する送信元IPが追跡され、戻りルーティングの決定に寄与します。

発信元トンネルをすべてのフローに記憶することで、ARRはゼロタッチルーティングを実現します。サイトのトラフィックがクライアント→インターネットのみの場合、戻りルートを事前に設定する必要はなく、新しい拠点や“Coffee Shop Networking”の展開時の手間を削減します。

Unified Routing 上での構築

ARRをCloudflareのスケールで実現するために、別の取り組みであるUnified Routingに接続しました。

歴史的に、Cloudflare Zero Trust（ユーザ／プロキシ）とCloudflare WAN（ネットワーク層／サイト）はシステム内で別レイヤーに存在していました。Cloudflare WANはカーネルプリミティブ（Linux ネットワークネームスペース、ルート、eBPFなど）に依存し、Zero Trustはユーザースペースで動作してアプリケーションレベルの詳細な検査とセキュリティを提供していました。この“スプリットブレイン”アプローチは、コンポーネント間でトラフィックを移動するための複雑なロジックを必要とし、顧客が認識するプロダクト上の制限につながることがありました。

Unified Routingモードにより、初期のルーティング判断をネットワーク層のデータプレーン（カーネル）から、Cloudflare One ClientsやCloudflare Tunnelで使われる既存のZero Trustユーザースペースのルーティングロジックへ移しました。この変更により、Cloudflare WANとZero Trust間の相互運用性に関する長年の問題を解決し、Cloudflare Mesh、Cloudflare Tunnel、IPsec/GREオンランプを同一アカウント内で競合なく併用できるようになりました。

2025年9月に、社内の全社員およびサイトでUnified Routingモードをデプロイし、Cloudflare One Clientsについて3〜5倍のパフォーマンス改善を即時に確認しました。

ARR設計時には、カーネルベースのルーティングから離れ、Unified Routingフレームワーク上に構築する必要があると判断しました。Unified Routingが有効な場合、すべてのCloudflare WANトラフィックはApollo（当社のZero Trustハブ）を経由します。Linuxカーネルの標準ルーティングテーブルとは異なり、ユーザースペースのデータプレーンは完全にプログラム可能で、発信元Tunnel IDのようなメタデータをフローエントリに直接付与できます。各パケットはエッジに到達した瞬間からフローとして追跡され、独立したパケットごとのルーティング判断を行う必要がなくなります。代わりに、フローの寿命にわたり一貫したセッション認識型の判断を行えます。

ARRはトンネルまたはインターコネクト単位で簡単に有効化できます。有効化されたトンネル／インターコネクトでは、既存フローに一致するトラフィックはルーティングテーブルを参照せずに発信元の接続に戻されます。

実務での利用

エンタープライズアーキテクトにとって、ARRはIPアドレス競合による継続的な摩擦を回避するためのツールです。買収の統合やパートナーのオンボーディング時に、目指すべきはネットワークを目立たなくすることであり、配管（plumbing）ではなくアプリケーションに集中できるようにすることです。

現状、ARRはClosed Betaであり、Secure Web Gatewayを経由してインターネットにアクセスする重複IPアドレスをサポートしています。既に以下の拡張作業に取り組んでいます:

• プライベートデータセンターアクセスのサポート
• ミッドフローフェイルオーバー（フローをプライマリオンランプにピン留めし、バックアップオンランプにフェイルオーバーしたことをシームレスに検出）
• 最も複雑なグローバル展開に対してもIP重複を問題にしないためのアーキテクチャ能力への追加投資

まだCloudflare Oneを利用していない場合

無料および従量課金（Pay-as-you-go）プランから始めて、ユーザーとネットワークの保護・接続を開始できます。IPsecや専用インターコネクトによる包括的なプライベートWAN接続についてはお問い合わせください。

Cloudflareの接続クラウドは企業ネットワーク全体を保護し、インターネット規模のアプリケーションを効率的に構築することを支援し、あらゆるWebサイトやインターネットアプリケーションを高速化し、DDoS攻撃から守り、ハッカーの脅威を抑止し、Zero Trustへの移行を支援します。任意のデバイスから1.1.1.1を訪れて、インターネットをより速く安全にする無料アプリを入手してください。

当社のミッション「より良いインターネットを作る」について詳しくはstart hereをご覧ください。新しいキャリアをお探しの場合は、オープンポジションをご確認ください。

タグ: SASE, Cloudflare One