GRE と IPsec トンネル

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

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

カプセル化で増えるヘッダーデータに対応するため、最大セグメントサイズ（MSS） を調整し、インターネットでルーティング可能な標準の最大伝送ユニット（MTU）である 1500 バイトに合わせます。

手順は 最大セグメントサイズを設定する を参照してください。

次の図は、Cloudflare WAN でのトラフィックの流れです。

sequenceDiagram
accTitle: トンネルとカプセル化
accDescr: Cloudflare WAN でのトラフィックの流れを示します。
participant A as クライアント
participant B as Cloudflare WAN
participant C as オリジンルーター
A->>B: Payload <br> Protocol <br> IP header
Note left of A: イングレス <br> トラフィック
B->>C: Payload <br> Protocol <br> IP header <br> GRE <br> IP header
C->>A: IP header <br> Protocol <br> Payload
Note right of C: エグレス <br> トラフィック

従来のトンネルは、両端が固定された 2 つのエンドポイントを接続します。Cloudflare WAN は別のモデルです。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 router <br> 198.51.100.1")
j("FTP server <br> (203.0.113.100)")
end

subgraph 3
x("Acme router <br> 198.51.100.1")
z("FTP server <br> (203.0.113.100)")
end

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

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

IPsec ↗ は、機器間の暗号化接続を確立するために連携する一連のプロトコルです。公開ネットワーク上で送るデータを保護します。組織は IPsec を Virtual Private Network（VPN）の構築によく使い、IP パケットを暗号化してパケットの送信元を認証します。

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

Cloudflare WAN は、次の段階で 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 セキュリティアソシエーション（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 を作ります。次の設定節では、Cloudflare WAN が現在 IKE SA と Child SA でサポートする変換を示します。

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

次のサードパーティベンダーは、耐量子鍵合意の Cloudflare IPsec との相互運用が検証済みです。

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

Cloudflare WAN は、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 は Child SA あたり 1 組のトラフィックセレクターのみをサポートします。
• ポリシーは応答形式のヘルスチェックをカバーする必要があります。つまりトラフィックセレクターに一致する必要があります。一致しないと、ポリシーに一致しない IPsec トンネルからの他のトラフィックと同様に、Cloudflare がドロップします。
• 1 つの IPsec トンネルに含められる Child SA はおよそ 100 個です。そのため、トンネルあたりの異なるポリシー数にも実質的な上限があります。

IKEv2 の当初の認証設計では、各エンドポイントは自分の送信メッセージだけに署名し、ハンドシェイク全体のトランスクリプトには署名しません。量子能力を持つ 経路上の攻撃者 ↗ は、これを突いてハンドシェイクの「分割ビュー」を作り、双方が耐量子鍵交換をサポートしていても、耐量子接続を古典暗号へダウングレードさせることができます。

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

仕組み:

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

要件:

• IKEv2 イニシエーターが、draft-ietf-ipsecme-ikev2-downgrade-prevention ↗ で定義された IKE_SA_INIT_FULL_TRANSCRIPT_AUTH 通知をサポートしている必要があります。

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

• トンネル健全性のトラブルシューティング - ヘルスチェック失敗の診断と修正
• IPsec ログでトラブルシュートする - Logpush で IPsec ハンドシェイクの問題を分析

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

• トンネル健全性のトラブルシューティング - ヘルスチェック失敗の診断と修正
• IPsec ログでトラブルシュートする - Logpush で IPsec ハンドシェイクの問題を分析