GRE と IPsec トンネル

Cloudflare のグローバルネットワークとオリジンネットワークの間でトラフィックをルーティングするため、Magic Transit は元のパケットを外側のパケットで包みます。この処理をカプセル化と呼びます。外側のパケットがインターネット経由で宛先まで運び、そこで包みが解かれ（デカプセル化）、配信されます。

Magic Transit が使うカプセル化プロトコルは 2 つです。Generic Routing Encapsulation（GRE） と IPsec です。GRE はステートレスで設定が簡単ですが、トラフィックは暗号化しません。IPsec はトラフィックを暗号化し、送信元を認証するため、セキュリティがより強くなります。どちらもトンネル（Cloudflare とネットワークの間の論理的なポイントツーポイント接続）を作ります。Cloudflare はネットワーク名前空間内のグローバルネットワークサーバー上にトンネルエンドポイントを用意し、データセンターのルーター上にトンネルエンドポイントを用意します。

カプセル化で増えるヘッダーデータに対応するため、maximum segment size（MSS） を調整し、標準のインターネット経路で使える maximum transmission unit（MTU）である 1500 バイトに合わせる必要があります。

手順は maximum segment size を設定する を参照してください。

次の図は、Magic Transit でのトラフィックの流れを示します。

sequenceDiagram
accTitle: トンネルとカプセル化
accDescr: Magic Transit でのトラフィックの流れを示します。
participant A as クライアント端末
participant B as Cloudflare Magic Transit
participant C as オリジンルーター
A->>B: ペイロード <br> プロトコル <br> IP ヘッダー
Note left of A: イングレス <br> トラフィック
B->>C: ペイロード <br> プロトコル <br> IP ヘッダー <br> GRE <br> IP ヘッダー
C->>A: IP ヘッダー <br> プロトコル <br> ペイロード
Note right of C: エグレス <br> トラフィック

従来のトンネルは、両端が固定された 2 つのエンドポイントを結びます。Magic Transit は別のモデルを使います。Cloudflare 側のトンネルエンドポイントに anycast IP アドレスを使います。anycast モデルでは、どの Cloudflare データセンターのどのサーバーでもトラフィックを受け取れ、どのトンネルでもパケットのカプセル化とデカプセル化ができなければなりません。トンネルは特定の Cloudflare サーバーに固定されません。送信元に最も近いデータセンターがトラフィックを処理します。

これは GRE トンネルで機能します。GRE プロトコルがステートレスだからです。Cloudflare は各パケットを独立して処理し、トンネルエンドポイント間の交渉や調整は不要です。トンネルエンドポイントは IP アドレスにバインドしますが、特定のデバイスにはバインドしません。外側のヘッダーを取り除き、内側のパケットをルーティングできるデバイスなら、トンネル経由で送られたどの GRE パケットでも処理できます。

IPsec トンネルでは、顧客のルーターが Internet Key Exchange（IKE） プロトコルを使って Cloudflare と IPsec トンネルの作成を交渉します。IPsec はステートフル（共有キーとセッションパラメーターが必要）なため、1 台の Cloudflare サーバーが最初の交渉を担当し、トンネルの詳細（トラフィックセレクター、キーなど）をすべての Cloudflare データセンターへ伝播します。その結果、セットアップを交渉したのが 1 台でも、どの Cloudflare サーバーでもその IPsec トンネルのトラフィックを処理できます。

Cloudflare の anycast アーキテクチャは、グローバルネットワーク上のすべてのデータセンターのすべてのサーバーからトンネルへの導線を提供します。次の図はこのアーキテクチャを示します。

flowchart LR
accTitle: Anycast トンネル
accDescr: データセンター内の複数サーバーが anycast トンネル経由でパケットを送ります。

a(ユーザー)

subgraph 1
direction LR
b(Cloudflare グローバル <br> ネットワークサーバー)
c(Cloudflare グローバル <br> ネットワークサーバー)
d(Cloudflare グローバル <br> ネットワークサーバー)
e(Cloudflare グローバル <br> ネットワークサーバー)
f(Cloudflare グローバル <br> ネットワークサーバー)
g(Cloudflare グローバル <br> ネットワークサーバー)
h(Cloudflare グローバル <br> ネットワークサーバー)
end

subgraph 2
i("Acme ルーター <br> 198.51.100.1")
j("FTP サーバー <br> (203.0.113.100)")
end

subgraph 3
x("Acme ルーター <br> 198.51.100.1")
z("FTP サーバー <br> (203.0.113.100)")
end

a --> 1== Cloudflare anycast GRE <br> 単一エンドポイント ==>i --> j

1== Cloudflare anycast IPsec <br> 単一エンドポイント ==>x --> z

IPsec ↗ は、機器間の暗号化接続を確立するために連携するプロトコル群です。公開ネットワーク経由で送るデータを安全に保つのに役立ちます。組織は Virtual Private Network（VPN）の構築に IPsec を使うことが多く、IP パケットを暗号化し、パケットの送信元を認証することで動作します。

IPsec トンネルの設定方法は トンネルエンドポイントを設定する を参照してください。Magic Transit が IPsec トンネルを作るときに使う設定パラメーターの詳細は、この先を読み進めてください。

Magic Transit は、次の段階で IPsec トンネルを確立します。

• Initial Exchange（IKE_SA_INIT）: IKE ピアが IKE Security Association（SA）のパラメーターを交渉し、鍵導出用の共有秘密を確立します。該当する場合は RFC 9370 ↗ でポスト量子鍵交換の対応を通知します。ダウングレード保護 が有効なときは、Cloudflare はこの交換中に IKE_SA_INIT_FULL_TRANSCRIPT_AUTH 通知も送り、完全なトランスクリプト認証への対応を示します。この交換のあと、ピア間には安全な通信チャネルがありますが、まだ相互認証はしていません。
• Intermediate Exchange（IKE_INTERMEDIATE）: 両方のピアが RFC 9370 に対応している場合、draft-ietf-ipsecme-ikev2-mlkem ↗ で規定されたポスト量子鍵交換である ML-KEM（Module-Lattice-based Key-Encapsulation Mechanism）で追加の鍵交換を行います。IKE_SA_INIT で確立した古典的な Diffie-Hellman 由来の秘密とポスト量子の ML-KEM を組み合わせてハイブリッド共有秘密を作り、harvest-now, decrypt-later ↗ 攻撃から守ります。
• Auth Exchange（IKE_AUTH）: IKE_SA_INIT と IKE_INTERMEDIATE の両方で確立した鍵を使い、IKE ピアが相互に認証します。認証後、IKE security association（SA）を確立します。次に、ピアは IPsec トンネル（Child SA）を交渉して確立します。
• Rekeying: 定期的に、または手動操作で、IKE SA を再鍵化し、セッション用の新しい SA と新しい鍵を生成できます。この再鍵操作は、IKE SA（コントロールプレーンの更新）と Child SA（データプレーンの更新）の両方に対して行います。ハイブリッド交換（RFC 9370）を使っている場合、IKE SA の再鍵でも古典的な（DH）交換とポスト量子（ML-KEM）交換を並行して行い、耐量子性を維持します。

まとめると、IKEv2 は特定の暗号変換を使う IKE SA を作り、その IKE SA を使って特定の暗号変換を使う Child SA を作ります。次の設定セクションでは、Magic Transit が現在 IKE SA と Child SA でサポートする変換を説明します。

機器がサポートする内容に合わせて、Magic Transit がサポートする次の設定パラメーターから選びます。

次のサードパーティベンダーは、ポスト量子鍵合意向けに Cloudflare IPsec との相互運用がテストおよび検証済みです。

Cloudflare はほかのサードパーティ機器のテストと検証を続けています。ここにないベンダーでポスト量子 IPsec を設定できた場合は、アカウントチームに連絡してください。

Magic Transit は IPsec 向けに次の IKE ID タイプをサポートします。

さらに、次の 2 つの条件を満たす場合、Cloudflare は IKE ID タイプ ID_IPV4_ADDR もサポートします。

1. IPsec トンネルの customer_endpoint 値を設定している。
2. cloudflare_endpoint と customer_endpoint の組み合わせが、その顧客の IPsec トンネル間で一意である。

Cloudflare はルートベース VPN とポリシーベース VPN の両方をサポートしますが、ルートベース VPN を推奨します。

ルートベース VPN が使えず、ポリシーベース VPN を使う必要がある場合は、次の制限に注意してください。

• Cloudflare がサポートする traffic selector のセットは、Child SA あたり 1 組のみです。
• ポリシーは応答型のヘルスチェックをカバーする必要があります。つまり traffic selector に一致する必要があります。一致しないと、ポリシーに一致しない IPsec トンネルからのほかのトラフィックと同様に、Cloudflare はドロップします。
• 1 つの IPsec トンネルに含められる Child SA は約 100 個までです。そのため、トンネルあたりの異なるポリシー数には実質的な上限があります。

IKEv2 の当初の認証設計では、各エンドポイントは自分の送信メッセージだけに署名し、ハンドシェイク全体のトランスクリプトには署名しません。量子耐性のある on-path 攻撃者 ↗ はこれを悪用し、ハンドシェイクの「分割ビュー」を作って、両方の側がポスト量子鍵交換に対応していても、ポスト量子接続を古典暗号へダウングレードさせることができます。

これに対処するため、Cloudflare は IKE_SA_INIT_FULL_TRANSCRIPT_AUTH ↗ IKEv2 拡張をサポートします。有効にすると、両方の IKEv2 ピアは認証交換中に自分のメッセージだけでなく、ハンドシェイク全体のトランスクリプトに署名します。攻撃者が検知されずに接続をダウングレードするのを防ぎます。

動作:

• 機能フラグが有効なとき、Cloudflare（IKE responder として動作）は IKE_SA_INIT 応答に無条件で IKE_SA_INIT_FULL_TRANSCRIPT_AUTH 通知を含めます。
• initiator もこの拡張に対応している場合、双方が完全なトランスクリプト認証を使い、ダウングレード攻撃に対する保護が強化されます。
• initiator がこの拡張に対応していない場合、ハンドシェイクは標準の IKEv2 認証で進みます。ダウングレード保護が有効になるには、双方がこの拡張に対応している必要があります。

要件:

• IKEv2 initiator が draft-ietf-ipsecme-ikev2-downgrade-prevention ↗ で定義された IKE_SA_INIT_FULL_TRANSCRIPT_AUTH 通知に対応している必要があります。

トンネルの問題を解決するには、次を参照してください。

• トンネルのヘルスをトラブルシュートする - ヘルスチェックの失敗を診断して修正します
• IPsec ログでトラブルシュートする - Logpush を使って IPsec ハンドシェイクの問題を分析します

Cloudflare の Network Analytics は、ネットワーク層とトランスポート層のトラフィックパターンと Distributed Denial of Service（DDoS）攻撃をほぼリアルタイムで可視化し、IP トラフィックの問題の切り分けに役立ちます。特定の期間のイングレスおよびエグレスのトンネルトラフィックを確認して、Cloudflare のグローバルネットワークから出ていくトラフィックの情報も見られます。

詳細は Analytics を参照してください。

トンネルの問題を解決するには、次を参照してください。

• トンネルのヘルスをトラブルシュートする - ヘルスチェックの失敗を診断して修正します
• IPsec ログでトラブルシュートする - Logpush を使って IPsec ハンドシェイクの問題を分析します