Automatic Return RoutingがIPアドレス重複問題を解決する方法

2026-03-05 | Steve Welham, Lauren Joplin, Jackson Kruger, Thea Heinen | 7分で読める

パブリックインターネットは、予測可能なルーティングという基本原則に依存しています。つまり、単一のIPアドレスは論理的に一意の宛先を指すということです。Cloudflareのような数百の拠点から1つのIPがアナウンスされるAnycastアーキテクチャにおいても、そのIPのすべてのインスタンスは同じサービスを表します。ルーティングテーブルは常にパケットがどこに向かうべきかを正確に把握しています。

この原則が成り立つのは、グローバルなアドレス管理機関が重複や競合を防ぐためにIPアドレス空間を組織に割り当てているからです。すべての人が単一の権威あるレジストリに従うとき、ルーティングテーブルは絶対的な真実の源として機能します。

パブリックインターネットでは、IPアドレスは一意でグローバルに登録された国民IDカードのようなものです。プライベートネットワークでは、IPは「John Smith」のような名前に過ぎず、同じ部屋に3人の「John Smith」がいて同じ人と話そうとするまでは問題ありません。

私たちがCloudflare Oneをエンタープライズバックボーンのための接続クラウドに拡張するにつれ、プライベートIPアドレス空間の複雑な現実に直面しています。重複が発生する正当な理由があり、企業はこれらの競合を処理するソリューションを必要としています。

本日、**Automatic Return Routing（ARR）**をクローズドベータで導入します。ARRは、Cloudflare Oneのお客様向けのオプションツールで、ルーティングテーブルにIPルートを必要とせずに、トラフィックを発信元に戻すルーティングの柔軟性を提供します。この機能により、重複するネットワークが、Network Address Translation（NAT）や複雑なVirtual Routing and Forwarding（VRF）設定を一切必要とせずに共存できます。

曖昧性の問題

エンタープライズネットワーキングにおいて、IPの重複は避けられない現実です。従来、管理者にとって負担となる3つの一般的なシナリオがあります：

• M&A（合併・買収）: 2つの会社が合併し、両方ともコアサービスに10.0.1.0/24を使用している
• エクストラネット: パートナー、ベンダー、または顧客が独自の内部IPスキームを使用してネットワークに安全に接続し、避けられない競合が発生する
• クッキーカッター型アーキテクチャ: SaaSプロバイダーや小売ブランドが、デプロイメントと運用を簡素化するために、すべてのブランチで同一のIPアドレス空間を使用する

問題は、これらのサイトがCloudflare経由でインターネットやデータセンターと通信しようとするときに発生します。2つの異なるサイトが同じソースIPからトラフィックを送信すると、リターンパケットがアーキテクチャ上の壁にぶつかります。管理者は、曖昧な宛先に基づいてトラフィックをルーティングする方法を決定する必要があります。

管理者が両方のルートをルーティングテーブルに入れると、正しいパスまたは間違ったパスのどちらが選択されるかは非決定的になります。標準的なルーティングテーブルの観点からは、2つの同一パスを区別する方法がありません。

この図は、両方とも10.0.1.0/24を使用している2つのブランチ（サイトAとサイトB）を示しています。これらはCloudflareにパケットを送信します。インターネットからのリターンパケットがCloudflareエッジに到達すると、ルーティングテーブルに2つの同一の出力オプションがあるため、このリターントラフィックが間違ったサイトに送信されることがあります。

従来の修正方法が失敗する理由

この曖昧性を解決する方法は数多くありますが、私たちはお客様にとって最も管理しやすい方法で解決することをお約束します。従来の「業界標準」の修正方法は機能的ですが、私たちが排除することを約束している重要な管理オーバーヘッドと複雑さをもたらします：

• Virtual Routing and Forwarding（VRF）: これは、トラフィックを分離するために「仮想」ルーティングテーブルを作成することを含みます。分離には効果的ですが、管理オーバーヘッドが追加されます。VRF間通信（ルートリーキング）の管理は、大規模では脆弱で複雑です。

• Network Address Translation（NAT）: 重複する各サブネットを、ネットワーク内で一意の管理されたIP範囲から未管理のIPアドレス空間にNATできます。このアプローチは効果的ですが、マッピングは新しいサイトやパートナーごとに管理上の負担となります。

通常、お客様から聞くユースケースは、重複するネットワークがインターネットやプライベートデータセンターにアクセスする必要があるというものです。管理オーバーヘッドなしにこれをどのように解決するのでしょうか？

Automatic Return Routing（ARR）の導入

私たちは、この問題に対する「ゼロタッチ」ソリューションとしてARRを開発しました。ARRは、インテリジェンスをルーティングテーブルからステートフル追跡に移します。

では、ステートフル追跡とは何でしょうか？従来のネットワーキングでは、ルーターは「忘れっぽい」（別名「ステートレス」）です。すべての単一パケットを完全な見知らぬ人として扱います。1ミリ秒前に全く同じソースから全く同じ宛先に向かうパケットを見たばかりでも、次のパケットをどこに送るかを決定するために、再びルーティングテーブルを調べる必要があります。

ステートフル追跡では、システムにメモリがあります。一連のパケットがすべて同じ「フロー」（つまり、2つのエンドポイント間のネットワーク会話）の一部であることを認識し、そのフローが終了するまでフローに関する重要な情報を記憶します。

ARRでは、フローを初期化するときに1つの追加情報を記憶します：それを開始した特定のトンネルです。これにより、ルーティングテーブルを参照することなく、リターントラフィックを同じトンネルに送り返すことができます！

ネットワークに「このIPはどこにありますか？」と尋ねる代わりに、ARRは「この特定の会話はどこから発信されましたか？」と尋ねます。

ロジック：

1. 入力: パケットが特定の接続（IPsecトンネル、GREトンネル、またはNetwork Interconnect）を介してサイトからCloudflareエッジに到着します。

2. フローマッチング: Cloudflare Virtual Networkは最初に（ヘッダー検査により）そのパケットが既存のフローと一致するかどうかをチェックします。

3. プロキシング: パケットが一致する場合、それは素晴らしいことです！このトラフィックに関するすべての決定は既に行われ、メモリに保存されています。そのパケットを既に確立されたパスに沿って渡すだけです。

4. フロー設定: 既存のフローと一致しない場合、Cloudflare Oneスタックのどの部分を通すか（例：Gateway、DLP、Firewall）と最終的な宛先を決定します。このすべての状態をメモリに保存します。ARRでは、これがフローを開始したトンネルを記録するタイミングです。

5. 対称リターン: 宛先からリターントラフィックが到着すると、Cloudflare Virtual Networkは既存のメモリ内状態を使用してトラフィックをプロキシします。重要なことに、これはトラフィックの宛先IPを調べる必要がなく、異なるサイト間で再利用される可能性があります。これにより、ルーティングテーブルを参照する必要が完全に回避されます。フロー状態で発信元トンネルを確認し、パケットを直接そこに配信します。

メモリ内フロー状態によって追跡される重複ソースIPの例。ソースオンランプでタグ付けされ、リターンルーティング決定に情報を提供します。

すべてのフローの発信元トンネルを記憶することで、ARRはゼロタッチルーティングを促進します。サイトトラフィックがクライアントからインターネットへのみの場合、リターンルートを設定する必要がまったくなく、新しいブランチサイトや「Coffee Shop Networking」をデプロイする際の負担が軽減されます。

Unified Routingに基づく構築

CloudflareスケールでARRを実現するために、私たちが取り組んできた別のイニシアチブであるUnified Routingに接続しました。

歴史的に、Cloudflare Zero Trust（ユーザー/プロキシ）とCloudflare WAN（ネットワーク層/サイト）はシステムの異なるレベルに存在していました。Cloudflare WANはカーネルプリミティブ（Linuxネットワーク名前空間、ルート、eBPFなど）に依存していました。Zero Trustはユーザースペースに存在し、プロキシが深い検査とアプリケーションレベルのセキュリティを実行できました。

この「分割脳」アプローチは、コンポーネントサービス間でトラフィックを移動するために複雑なロジックを必要とすることが多く、この複雑さの一部がお客様が気づく可能性のある製品制限となりました。

新しいUnified Routingモードでは、初期ルーティング決定をネットワーク層データプレーンから既存のZero Trustユーザースペースルーティングロジック（Zero Trustソリューションでcloudflare One ClientsとCloudflare Tunnelで使用されている同じ堅牢なソフトウェア）に移しました。

この変更により、お客様がCloudflareプラットフォーム全体の製品でプライベートネットワークを使用する方法に多くの利点がもたらされ、Cloudflare WANとZero Trust間の長年の相互運用性問題が修正されます。Unified Routingは、Cloudflare Mesh、Cloudflare Tunnel、IPsec/GREオンランプを同じアカウントで競合なしに一緒に使用できることを意味します。

2025年9月、私たちはすべてのCloudflare従業員とサイトに対してUnified Routingモードを内部的にデプロイしました。上のグラフで見ることができるように、Cloudflare One Clientsで即座に3-5倍のパフォーマンス向上を確認しました。

ARRを設計する際、カーネルベースのルーティングから離れ、新しいUnified Routingフレームワーク上に構築する必要があることを知っていました。Unified Routingが有効になると、すべてのCloudflare WANトラフィックは私たちのZero TrustハブであるApolloを通過します。Linuxカーネルの標準ルーティングテーブルとは異なり、私たちのユーザースペースデータプレーンは完全にプログラム可能です。発信元トンネルIDなどのメタデータをApolloのフローエントリに直接添付できます。

各パケットは、エッジに到達した瞬間からフローによって追跡され、独立したパケットごとのルーティング決定を行う必要がなくなりました。代わりに、フローの生存期間中、一貫したセッション認識決定を行うことができます。

ARRは、トンネルまたはインターコネクトベースで有効にするのが簡単です：

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

ARRの実用化

エンタープライズアーキテクトにとって、ARRはIPアドレス競合の持続的な摩擦を回避するツールです。買収の統合やパートナーのオンボーディングにおいて、目標はネットワークを見えなくすることで、配管ではなくアプリケーションに集中できるようにすることです。

本日、ARRはクローズドベータ段階にあり、Secure Web Gateway経由でインターネットにアクセスする重複IPアドレスをサポートしています。私たちは既にこれをプライベートデータセンターアクセスをサポートするように拡張し、フロー中のフェイルオーバー（フローをプライマリオンランプに固定し、そのフローがバックアップオンランプにフェイルオーバーしたときをシームレスに検出）を追加し、最も複雑なグローバルデプロイメントでもIP重複を問題にしないために必要なアーキテクチャ機能にさらに投資しています。

まだCloudflare Oneを使用していませんか？無料およびPay-as-you-goプランで今すぐ始めて、ユーザーとネットワークを保護・接続し、IPsecとプライベートインターコネクト経由の包括的なプライベートWAN接続についてはお問い合わせください。

Cloudflareの接続クラウドは企業ネットワーク全体を保護し、お客様がインターネット規模のアプリケーションを効率的に構築し、あらゆるWebサイトやインターネットアプリケーションを高速化し、DDoS攻撃を防御し、ハッカーを寄せ付けず、Zero Trustへの道のりをサポートします。

あらゆるデバイスから1.1.1.1にアクセスして、インターネットをより高速で安全にする無料アプリを始めましょう。より良いインターネットの構築を支援するという私たちの使命について詳しく知るには、こちらから始めてください。新しいキャリアの方向性をお探しの場合は、求人情報をご確認ください。