トンネルのヘルス

このガイドでは、Cloudflare WAN の一般的なトンネルヘルスの問題を切り分け、解決します。トンネルヘルスチェックは、GRE および IPsec のトンネルエンドポイント（Cloudflare ダッシュボードではコネクターとも呼びます）を監視し、利用可能な最適なルートへトラフィックを誘導します。

次の表で、症状を最も多い原因と最初の対処に対応づけます。

• ダッシュボード: データセンターごとのトンネルヘルスステータスと、トンネルごとのトラフィック量（Insights > Network health > Network health を開きます）
• API: Cloudflare WAN のトンネルヘルス API でトンネルヘルスステータスを確認できます
• Network Analytics: Network Analytics でトラフィック量、パケット数、プロトコル分布を確認できます
• 自社ネットワークから: トンネルエンドポイントから Cloudflare 向けに traceroute と MTR を実行します。Cloudflare のエンドポイントはエニーキャストのため、これは最も近いデータセンターまでの経路だけをテストします。特定リージョンをテストするには、Cloudflare Traceroute API を使い、特定の Cloudflare 拠点から自社ネットワークへ traceroute を実行します。

• トンネルヘルスイベントと Cloudflare ネットワーク障害の相関
• パケット単位の転送判断（どのデータセンターが、どのパケットを、どのトンネル経由で転送したか）
• ダッシュボードの保持期間を超えたヘルスチェックプローブの履歴データ

トンネルヘルスの問題がある場合は、まず次を確認してください。

1. ヘルスチェックタイプ: ステートフルファイアウォール（Palo Alto Networks、Check Point、Cisco、Fortinet など）を使っている場合は、ヘルスチェックタイプを Reply から Request に変更します。
2. アンチリプレイ保護: ルーターでアンチリプレイ保護を無効にするか、リプレイウィンドウを 0 に設定します。
3. MTU 設定: MTU が正しく設定されていることを確認します（通常、GRE は 1476、IPsec は 1400〜1450）。
4. IPsec パラメーター: 暗号パラメーターが Cloudflare のサポート対象構成 と一致していることを確認します。
5. ヘルスチェックの方向: Cloudflare WAN のデフォルトは Bidirectional です。
6. Cloudflare Network Firewall ルール（あまり多くありません）: Cloudflare の IP アドレス ↗ からの ICMP トラフィックが許可されていることを確認します。

Cloudflare ダッシュボードの Network health ↗ ページには、次の 3 つのトンネルヘルス状態が表示されます。

ダッシュボードは、トラフィックが着地する各 Cloudflare データセンターから測定したトンネルヘルスを表示します。インターネット経路の問題により、一部の拠点が degraded を報告するのは通常のことです。Traffic volume (1h) 列にトラフィックがある拠点に注目してください。

トンネルヘルスダッシュボードは、データセンターごと・トンネルごとにヘルス状態を報告します。各 Cloudflare データセンターは、各トンネルのヘルスを独立して追跡します。

よくある誤解は、ダッシュボードの「100% degraded」を 100% のパケットロスだと読み間違えることです。この 2 つは異なります。

degraded 状態が発動する条件:

ヘルスチェックプローブが失敗すると、Cloudflare は追加で 2 回プローブを送ります。成功するプローブと失敗するプローブが混在すると、そのデータセンターのトンネルは degraded 状態になります。数秒の間欠的なパケットロスでも、この遷移は起きます。

確認すべきこと:

Traffic volume (1h) 列にトラフィックがあるデータセンターに注目してください。トラフィックがゼロ、またはごく少ないデータセンターの degraded は参考情報です。その Cloudflare データセンターと自社ネットワーク間の経路に問題があることを示しますが、そのデータセンター経由でトラフィックが流れなければ影響はありません。

回復までの時間:

トンネルは、ヘルスチェックがすぐに成功し始めても、最低 5 分間は degraded 状態のままです。degraded から healthy への回復には、一定期間にわたってヘルスチェックが安定して成功する必要があり、最大 30 分かかることがあります。状態間の遷移の詳細は、後述の 回復動作 を参照してください。

トンネルが unhealthy になると、Cloudflare はそのトンネル経由のルートに優先度ペナルティを加えます。

• Degraded: ルート優先度に 500,000 を加算
• Down: ルート優先度に 1,000,000 を加算

このペナルティは、冗長性を保ちながら、より健全なトンネルへトラフィックを移します。Cloudflare はルートを完全には削除しないため、すべてのトンネルが unhealthy でもフェイルオーバーの選択肢は残ります。

フラップを防ぐため、トンネルの状態遷移は非対称です。

• Healthy から Degraded / Down: 失敗を検出するとすぐに遷移します。プローブの再試行がすべて失敗した場合、トンネルは Healthy から Down へ直接遷移できます。
• Down から Degraded: ヘルスチェックプローブが 3 回連続で成功する必要があります。
• Degraded から Healthy: 30 回連続のプローブで失敗率が 0.1% 未満である必要があります。

トンネルステータスの監視手順は、ダッシュボードでトンネルヘルスを確認する を参照してください。

ヘルスチェックタイプ:

ヘルスチェックの方向:

• ダッシュボードではトンネルが Down または Degraded
• 実際のユーザートラフィックはトンネルを正常に通過する
• 接続は機能しているのに、ヘルスチェックの失敗率が 100%

ステートフルファイアウォール（Palo Alto Networks、Check Point、Cisco、Fortinet など）がヘルスチェックパケットを破棄します。デフォルトでは、Cloudflare はヘルスチェックプローブとして ICMP の Reply パケットを送ります。

ステートフルファイアウォールはこれらのパケットを検査し、セッションテーブルに一致する ICMP Request を探します。一致するリクエストがないと、ファイアウォールは reply を状態外（out-of-state）として破棄します。

ヘルスチェックタイプを Reply から Request に変更します。

1. Connectors ページを開きます。

   Connectors を開く ↗

2. IPsec/GRE tunnels で、対象トンネルの Edit を選びます。

3. Health check type を Reply から Request に変更します。

4. Update tunnel を選びます。

Request 形式のヘルスチェックでは、Cloudflare が ICMP echo request を送ります。ファイアウォールのステートフル検査エンジンは、これを正当なリクエストとして認識し、ICMP reply 応答を自動で許可します。

• Cloudflare Network Firewall を有効にする前はトンネルが正常だった
• Cloudflare Network Firewall ルールを追加したあと、ヘルスチェックが失敗する
• ICMP トラフィックをブロックすると、ヘルスチェックがすぐに失敗する

Cloudflare Network Firewall は、Cloudflare のヘルスチェックプローブを含むすべてのトラフィックを処理します。ICMP トラフィックをブロックするルールを作ると、トンネル状態の監視のために Cloudflare が送るヘルスチェックパケットもブロックします。

Cloudflare の IP アドレスからの ICMP トラフィックを許可するルールを、ブロックルールの 前 に追加します。

1. Firewall policies ページを開きます。

   Firewall policies を開く ↗

2. 次のパラメーターで新しいポリシーを作成します。

3. このルールを、ICMP トラフィックをブロックするルールの 前 に配置します。

詳細は Cloudflare Network Firewall ルールとエンドポイントヘルスチェック を参照してください。

• IPsec トンネルが正常と down のあいだで頻繁にフラップする
• トンネル上で間欠的なパケットロスがある
• 設定変更なしで、一定時間はトラフィックが流れ、その後止まる
• ルーターログに次の理由でパケットが破棄されたと出る:
  • "replay check failed"
  • "invalid sequence number"
  • "invalid SPI"（Security Parameter Index）

ルーターでアンチリプレイ保護が有効です。IPsec のアンチリプレイ保護は、単一の送信元からパケットが順番に届くことを想定します。

Cloudflare のエニーキャストアーキテクチャでは、トンネルトラフィックは数百のデータセンターにある数千台のサーバーから発生します。各サーバーは独自のシーケンスカウンターを持つため、ルーターから見るとパケットが順序どおりに届きません。

ルーターでアンチリプレイ保護を無効にします。

ほとんどのルーターの場合:

IPsec 設定でアンチリプレイまたはリプレイ保護の設定を探し、無効にします。

リプレイウィンドウサイズしか設定できない場合:

リプレイウィンドウを 0 にすると、実質的にチェックを無効にできます。

アンチリプレイを無効にできない機器の場合:

Cloudflare ダッシュボードでリプレイ保護を有効にします。トンネルトラフィックはすべて単一のサーバー経由になり、シーケンス番号は正しく保たれますが、エニーキャストの利点は失われます。

1. Connectors ページを開きます。

   Connectors を開く ↗

2. IPsec/GRE tunnels で、対象の IPsec トンネルの Edit を選びます。

3. Replay protection を有効にします。

4. Update tunnel を選びます。

Cisco IOS / IOS-XE ルーターで "invalid SPI" エラーが出る場合:

ISAKMP の invalid SPI recovery を有効にし、ルーターが Security Association を再同期しやすくします。

configure terminal
crypto isakmp invalid-spi-recovery
exit

この設定が必要な理由の詳細は、アンチリプレイ保護 を参照してください。

• トンネルヘルスが定期的に Degraded または Down に落ちる
• 問題の発生が IPsec のリキー間隔（通常は数時間ごと）と一致する
• 1〜3 分後にトンネルが自動で回復する
• ルーターログではリキーが成功している

トンネルエンドポイントが IPsec リキーを開始すると、新しい Security Association（SA）を Cloudflare のネットワーク全体に伝播する必要があります。リキー伝播の遅延は大幅に減っており、ほとんどの導入では珍しくなっています。ただし、一部の構成では、リキー中に短いトンネル劣化がまだ起きることがあります。

Cloudflare はリキーを開始せず、応答するだけです。リキーの試行は、すべてトンネルエンドポイント側から行う必要があります。リキー中に機器が TEMPORARY_FAILURE 応答を受け取った場合は、回復のために IKE セッションを再確立する必要があります。

この動作は想定どおりであり、トンネルは自動で回復します。影響を抑えるには、次を行います。

1. Dead Peer Detection（DPD）を restart で設定する: トンネルエンドポイントの DPD アクションを "restart" にし、リキーが TEMPORARY_FAILURE で失敗した場合に IKE セッションを自動で再確立します。DPD の restart がないと、失敗したリキーを繰り返すループに陥ることがあります。

2. リキー間隔を長くする: トンネルエンドポイントの SA ライフタイムを長くし、リキー頻度を下げます。一般的な値は、IKE SA が 8〜24 時間、IPsec SA が 1〜8 時間です。

3. ヘルスチェックの感度を調整する: リキー中の短い劣化でアラートが出る場合は、ヘルスチェックレートを下げることを検討します。

   1. Connectors ページを開きます。
   Connectors を開く ↗
   2. IPsec/GRE tunnels で、対象トンネルの Edit を選びます。
   3. Health check rate を Low に変更します。

4. リキー時刻をずらす: トンネルが複数ある場合は、同時にリキーしないよう SA ライフタイムを変えます。

• 双方向に設定したヘルスチェックが継続的に失敗する
• 一方向のヘルスチェックは正常に動作する
• トラフィックはトンネルを通常どおり流れる

双方向ヘルスチェックでは、プローブと応答の両方がトンネルを通過する必要があります。ルーターは次を行う必要があります。

1. トンネルインターフェイス IP アドレス宛の ICMP パケットを受け入れる
2. ICMP 応答をトンネル経由で Cloudflare へ戻す

トラフィックセレクターやファイアウォールルールがこのトラフィックを許可していないと、双方向ヘルスチェックは失敗します。

IPsec トンネルの場合:

トンネルインターフェイスアドレス宛のパケットを受け入れるよう、トラフィックセレクターを設定します。たとえば、トンネルインターフェイスアドレスが 10.252.2.27/31 の場合:

• 10.252.2.26（Cloudflare 側）との送受信を許可する
• 10.252.2.27（自社側）との送受信を許可する

すべてのトンネルタイプの場合:

ファイアウォールがトンネルインターフェイス上の ICMP トラフィックを許可していることを確認します。多くのファイアウォールでは、トンネルインターフェイス上の管理トラフィック（ping を含む）を許可する明示的なルールが必要です。

双方向ヘルスチェックの動作の詳細は、トンネルヘルスチェック を参照してください。

• トンネルステータスが Down のまま、正常にならない
• トンネル経由でトラフィックが流れない
• ルーターログに IKE ネゴシエーション失敗が出る

IPsec トンネルの確立は、次のような設定の不一致で失敗することがあります。

1. 暗号パラメーターが Cloudflare のサポート対象構成と一致していることを確認します。

   Phase 1（IKE）

Phase 2（IPsec）

2. 事前共有鍵（PSK）を確認します。

   • Cloudflare ダッシュボードで PSK を再生成します
   • 新しい PSK をそのままコピーします（余分な空白や文字を入れない）
   • ルーターを新しい PSK で更新します

3. IKE ID の形式を確認します。 Cloudflare は IKE ID に FQDN 形式を使います。ルーターが FQDN のピア ID を受け入れる設定になっていることを確認してください。FQDN は Cloudflare ダッシュボードのトンネル詳細に表示されます。

4. ファイアウォールルールを確認します。 エッジファイアウォールで次を許可してください。

   • UDP ポート 500（IKE）
   • UDP ポート 4500（IKE NAT-T）
   • IP プロトコル 50（ESP）

サポート対象パラメーターの一覧は、サポートされる設定パラメーター を参照してください。

• ポリシーベース IPsec トンネルでヘルスチェックが継続的に失敗する
• トンネルのトラフィックセレクター（暗号化ドメイン）に一致するトラフィックは通常どおり流れる
• 同じ機器上のルートベーストンネルは正常に動作する

ポリシーベース IPsec トンネルは、トンネル内で許可するプレフィックスをトラフィックセレクターで定義します。Reply 形式のヘルスチェックは Cloudflare の IP アドレス宛てです。これらのアドレスはトンネルのトラフィックセレクター（お客様ネットワークの宛先だけを許可）の外にあるため、トンネルエンドポイントはヘルスチェックパケットを破棄します。

加えて、一部のファイアウォール（Check Point など）は、Reply 形式のヘルスチェックパケットを自己宛のためスプーフと見なし、ルートベーストンネルでも破棄することがあります。

1. ヘルスチェックタイプを Reply から Request に変更します。
2. トンネルエンドポイント上にループバックアドレスを設定し、ヘルスチェック先にします。対象は次の条件を満たす必要があります。
   • トンネルエンドポイントから到達できる
   • トンネルのトラフィックセレクター（暗号化ドメイン）に含まれる
3. 双方向ヘルスチェックの場合は、ヘルスチェックの送信元（Cloudflare ダッシュボードで設定するトンネル Interface Address）もトラフィックセレクターに含まれるようにします。

このガイドを一通り確認してもトンネルヘルスの問題が続く場合は、Cloudflare サポートに問い合わせる前に、次の情報を集めてください。

1. 影響を受けている Account ID と トンネル名
2. 問題が起きた タイムスタンプ（UTC）
3. トンネル設定の詳細:
   • トンネルタイプ（GRE または IPsec）
   • ヘルスチェックタイプ（Request または Reply）
   • ヘルスチェックの方向（Bidirectional または Unidirectional）
   • ヘルスチェックレート（Low、Medium、または High）
4. ルーター情報:
   • ベンダーとモデル
   • ファームウェア / ソフトウェアのバージョン
   • IPsec 設定（PSK は除いてサニタイズする）
5. 確認した症状:
   • ダッシュボードのトンネルヘルスステータス
   • ユーザートラフィックへの影響の有無
   • ルーターログのエラーメッセージ

• ルーターから取得した、トンネルトラフィックの パケットキャプチャ
• 問題発生時間帯の ルーターログ
• 自社ネットワークから Cloudflare エンドポイントへの traceroute 結果
• トンネルヘルスダッシュボードの スクリーンショット
• ping.pe ↗ のようなツールを使った 分散 traceroute（複数のグローバル拠点からの到達性確認）

次のコマンドの出力を収集します（構文はベンダーによって異なります）。

• IPsec SA のステータス: show crypto ipsec sa
• IKE SA のステータス: show crypto isakmp sa
• トンネルインターフェイスのステータス: show interface tunnel <number>
• ルーティングテーブル: show ip route

• トンネルヘルスチェック: ヘルスチェック動作の技術詳細
• アンチリプレイ保護: アンチリプレイを無効にする理由
• トンネルエンドポイントの設定: トンネルのセットアップ手順
• ダッシュボードでトンネルヘルスを確認する: ダッシュボードの操作案内
• Network Analytics: トラフィック分析ツール

詳細は、Cloudflare WAN のドキュメント全体を参照してください。