トンネルの健全性をトラブルシュートする

このガイドでは、Magic Transit のよくあるトンネル健全性の問題を切り分けて解消します。トンネルヘルスチェックは、GRE および IPsec のトンネルエンドポイント（Cloudflare ダッシュボードではコネクターとも呼びます）を監視し、利用可能な最良の経路へトラフィックを誘導します。

次の表で、症状を最も可能性の高い原因と最初の対応に対応付けます。

• ダッシュボード: データセンターごとのトンネル健全性と、トンネルごとのトラフィック量（Insights > Network health > Network health を開きます）
• API: Magic Transit トンネルヘルス API によるトンネル健全性
• Network Analytics: Network Analytics によるトラフィック量、パケット数、プロトコル分布
• 自社ネットワークから: トンネルエンドポイントから Cloudflare 向けの traceroute と MTR。Cloudflare のエンドポイントは anycast を使うため、これは最寄りのデータセンターまでの経路だけを検証します。特定リージョンを調べるには、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. ヘルスチェックの方向: Magic Transit の既定は Unidirectional（ダイレクトサーバーリターン）です。
6. Cloudflare Network Firewall ルール（あまり多くない）: Cloudflare IP アドレス ↗ からの ICMP トラフィックが許可されていることを確認します。

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

ダッシュボードは、トラフィックが着地する各 Cloudflare データセンターから測ったトンネル健全性を表示します。インターネット経路の問題で、一部の拠点が低下状態を報告するのは普通です。Traffic volume (1h) 列にトラフィックがある拠点に注目します。

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

よくある混乱は、ダッシュボードの「100% degraded」を 100% のパケット損失と読み違えることです。これは別物です。

低下状態が起きる仕組み:

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

確認すること:

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

回復までの時間:

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

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

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

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

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

• 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 を「状態外」として破棄します。

ヘルスチェックタイプを 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 トンネルが健全とダウンのあいだで頻繁にフラップする
• トンネル上で間欠的なパケット損失がある
• 構成を変えていないのに、一定時間動いたあとトラフィックが止まる
• ルーターログに、次の理由でパケットが破棄されたと出る:
  • "replay check failed"
  • "invalid sequence number"
  • "invalid SPI"（Security Parameter Index）

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

Cloudflare の anycast アーキテクチャでは、トンネルトラフィックは数百のデータセンターにある数千台のサーバーから発信されます。各サーバーは独自のシーケンスカウンターを持つため、ルーターから見るとパケットは順不同で到着します。

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

ほとんどのルーター:

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

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

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

アンチリプレイの無効化に対応していない機器:

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

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. Pre-Shared Key（PSK）を確認します。

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

3. IKE ID 形式を確認します。 Cloudflare は IKE ID に FQDN 形式を使います。ルーターが FQDN のピア識別子を受け入れるよう設定されていることを確認します。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: トラフィック分析ツール