このガイドでは、Cloudflare WAN のトンネル健全性に関する一般的な問題を診断し、解決します。トンネルヘルスチェックは、GRE および IPsec のトンネルエンドポイント（Cloudflare ダッシュボードではコネクターとも呼ばれます）を監視し、利用可能な最善のルートへトラフィックを誘導します。
次の表で、症状から最も多い原因と最初に行うことを照合します。
| 症状 | 最も多い原因 | 最初に行うこと |
|---|---|---|
| トンネルが Down のままで、健全にならない | 設定の不一致、またはファイアウォールが IKE を遮断している | IPsec パラメーターとファイアウォールルールを確認します。IPsec トンネルの確立失敗 を参照してください。 |
| 一部の colo でダッシュボードが「100% degraded」を表示する | 正常です。これは状態の表示であり、パケットロスではありません | 該当する colo がトラフィックを担っているか確認します。ダッシュボードの degraded 状態を理解する を参照してください。 |
| トンネルが健全と不健全のあいだでフラップする | アンチリプレイ保護、またはリキーによる中断 | ルーターでアンチリプレイ保護を無効にします。IPsec トンネルの不安定さ を参照してください。 |
| ヘルスチェックは失敗するが、トラフィックは通常どおり流れる | ステートフルファイアウォールがヘルスチェックプローブを破棄している | ヘルスチェックタイプを Reply から Request に変更します。トンネルは Down だがトラフィックは流れている を参照してください。 |
| ポリシーベース VPN トンネルでヘルスチェックが失敗する | Reply ヘルスチェックがトンネルのトラフィックセレクターの外になる | ループバック先を使う Request 形式のヘルスチェックを使います。ポリシーベース VPN のヘルスチェック失敗 を参照してください。 |
| 特定リージョンですべてのトンネルが degraded または down | そのリージョンと自ネットワークのあいだの経路の問題 | ISP の接続を確認します。トンネルエンドポイントから Cloudflare 向けに traceroute または MTR を実行します。 |
| グローバルですべてのトンネルが degraded または down | 自ネットワークエッジの問題 | トンネルエンドポイントのルーターと上流の接続を確認します。 |
- ダッシュボード: データセンターごとのトンネル健全性ステータスと、トンネルごとのトラフィック量（Insights > Network health > Network health を開きます）
- API: Cloudflare WAN トンネルヘルス API によるトンネル健全性ステータス
- Network Analytics: Network Analytics によるトラフィック量、パケット数、プロトコル分布
- 自ネットワークから: トンネルエンドポイントから Cloudflare 向けの traceroute と MTR。Cloudflare のエンドポイントは anycast を使うため、これは最寄りのデータセンターまでの経路だけを確認します。特定リージョンを確認するには、Cloudflare Traceroute API を使い、特定の Cloudflare 拠点から自ネットワークへ traceroute を実行します。
- トンネル健全性イベントと Cloudflare ネットワーク障害の相関
- パケット単位の転送判断（どのデータセンターが、どのトンネル経由で、どのパケットを転送したか）
- ダッシュボードの保持期間を超えた、過去のヘルスチェックプローブデータ
トンネルの健全性に問題がある場合は、まず次の項目を確認します。
- ヘルスチェックタイプ: ステートフルファイアウォール（Palo Alto Networks、Check Point、Cisco、Fortinet など）を使っている場合は、ヘルスチェックタイプを Reply から Request に変更します。
- アンチリプレイ保護: ルーターでアンチリプレイ保護を無効にするか、リプレイウィンドウを
0に設定します。 - MTU 設定: MTU が正しく設定されていることを確認します（通常、GRE は
1476、IPsec は1400〜1450）。 - IPsec パラメーター: 暗号パラメーターが Cloudflare の対応設定 と一致することを確認します。
- ヘルスチェックの方向: Cloudflare WAN のデフォルトは Bidirectional です。
- Cloudflare Network Firewall ルール（頻度は低め）: Cloudflare の IP アドレス ↗ からの ICMP トラフィックが許可されていることを確認します。
Cloudflare ダッシュボードの Network health ↗ ページには、3 つのトンネル健全性状態が表示されます。
| 状態 | ダッシュボードの表示 | 技術的なしきい値 |
|---|---|---|
| Healthy | ヘルスチェックの 80% 超が成功 | 失敗率が 0.1% 未満 |
| Degraded | ヘルスチェックの成功が 40%〜80% | 直近 5 分間で少なくとも 0.1% の失敗（最低 2 回の失敗） |
| Down | ヘルスチェックの成功が 40% 未満 | すべてのヘルスチェックが失敗（直近 1 秒で少なくとも 3 サンプル） |
ダッシュボードは、トラフィックが到着する各 Cloudflare データセンターから計測したトンネル健全性を表示します。インターネット経路の問題により、一部の拠点が degraded を報告するのは普通です。Traffic volume (1h) 列にトラフィックがある拠点に注目してください。
トンネル健全性ダッシュボードは、データセンターごと・トンネルごとに健全性の状態を報告します。各 Cloudflare データセンターは、各トンネルの健全性を独立して追跡します。
よくある混乱は、ダッシュボードで「100% degraded」を見て、100% のパケットロスだと誤解することです。これらは別物です。
degraded 状態が起きる仕組み:
ヘルスチェックプローブが失敗すると、Cloudflare は追加で 2 回プローブを送ります。成功するプローブと失敗するプローブが混在すると、そのデータセンターではトンネルが degraded 状態になります。数秒の間欠的なパケットロスで、この遷移が起きます。
確認すべきこと:
Traffic volume (1h) 列にトラフィックがあるデータセンターに注目してください。トラフィックがゼロ、またはごく少ないデータセンターの degraded は参考情報です。その Cloudflare データセンターと自ネットワークのあいだの経路の問題を示しますが、そのデータセンター経由でトラフィックが流れなければ影響はありません。
回復までの時間:
トンネルは、ヘルスチェックがすぐに成功し始めても、少なくとも 5 分間は degraded 状態のままです。degraded から Healthy への回復には、一定期間にわたってヘルスチェックが安定して成功する必要があり、最大 30 分かかることがあります。状態間の遷移の詳細は、後述の 回復の動作 を参照してください。
トンネルが不健全になると、Cloudflare はそのトンネル経由のルートに優先度ペナルティを適用します。
- Degraded: ルート優先度に
500,000を加算 - Down: ルート優先度に
1,000,000を加算
これらのペナルティは、冗長性を保ちつつ、より健全なトンネルへトラフィックを移します。Cloudflare はルートを完全には削除しないため、すべてのトンネルが不健全でもフェイルオーバーの選択肢は残ります。
フラップを防ぐため、トンネルの状態遷移は非対称です。
- Healthy から Degraded / Down: 失敗を検出するとすぐに遷移します。プローブの再試行がすべて失敗した場合、トンネルは Healthy から直接 Down になることがあります。
- Down から Degraded: ヘルスチェックプローブが 3 回連続で成功する必要があります。
- Degraded から Healthy: 連続 30 回のプローブで失敗率が 0.1% 未満である必要があります。
トンネルステータスの監視手順は、ダッシュボードでトンネルの健全性を確認する を参照してください。
ヘルスチェックタイプ:
| 種類 | 動作 | 使う場面 |
|---|---|---|
| Reply（デフォルト） | Cloudflare が ICMP reply パケットを送信します | ステートフルファイアウォールのない単純なネットワーク |
| Request | Cloudflare が ICMP echo request を送信します | ステートフルファイアウォールのあるネットワーク（ほとんどの導入で推奨） |
ヘルスチェックの方向:
| 方向 | 動作 | デフォルト対象 |
|---|---|---|
| Bidirectional | プローブと応答の両方がトンネルを通ります | Cloudflare WAN（旧称 Magic WAN） |
| Unidirectional | プローブはトンネルを通り、応答はインターネット経由で戻ります | Magic Transit（direct server return） |
- ダッシュボードがトンネルを
DownまたはDegradedと表示する - 実際のユーザートラフィックはトンネルを正常に通過する
- 接続は機能しているのに、ヘルスチェックの失敗率が 100%
ステートフルファイアウォール（Palo Alto Networks、Check Point、Cisco、Fortinet など）がヘルスチェックパケットを破棄します。デフォルトでは、Cloudflare はヘルスチェックプローブとして ICMP の Reply パケットを送ります。
ステートフルファイアウォールはこれらのパケットを検査し、セッションテーブル内の一致する ICMP Request を探します。一致するリクエストがないと、ファイアウォールは応答を「out-of-state」として破棄します。
ヘルスチェックタイプを Reply から Request に変更します。
-
Connectors ページを開きます。
Connectors を開く ↗ -
IPsec/GRE tunnels で、対象トンネルの Edit を選びます。
-
Health check type を Reply から Request に変更します。
-
Update tunnel を選びます。
Request 形式のヘルスチェックを使うと、Cloudflare は ICMP echo request を送ります。ファイアウォールのステートフル検査はこれを正当なリクエストとして認識し、ICMP reply 応答を自動的に許可します。
- Cloudflare Network Firewall を有効にする前はトンネルが健全だった
- Cloudflare Network Firewall ルールを追加したあと、ヘルスチェックが失敗する
- ICMP トラフィックをブロックすると、ヘルスチェックがすぐに失敗する
Cloudflare Network Firewall は、Cloudflare のヘルスチェックプローブを含むすべてのトラフィックを処理します。ICMP トラフィックをブロックするルールを作ると、トンネル状態の監視に使うヘルスチェックパケットもブロックします。
Cloudflare の IP アドレスからの ICMP トラフィックを許可するルールを、ブロックルールの 前 に追加します。
-
Firewall policies ページを開きます。
Firewall policies を開く ↗ -
次のパラメーターで新しいポリシーを作成します。
| フィールド | 値 |
|---|---|
| Action | Allow |
| Protocol | ICMP |
| Source | Cloudflare IP ranges ↗ |
- ICMP トラフィックをブロックするルールの 前 に、このルールを配置します。
詳細は、Cloudflare Network Firewall ルールとエンドポイントヘルスチェック を参照してください。
- IPsec トンネルが健全と down のあいだで頻繁にフラップする
- トンネル上で間欠的なパケットロスが起きる
- 設定変更なしで、一定時間はトラフィックが流れ、その後止まる
- ルーターログに、次の理由でパケットが破棄されたと表示される
- "replay check failed"
- "invalid sequence number"
- "invalid SPI"（Security Parameter Index）
ルーターでアンチリプレイ保護が有効です。IPsec のアンチリプレイ保護は、単一の送信者からパケットが順序どおり到着することを想定します。
Cloudflare の anycast アーキテクチャでは、トンネルトラフィックは数百のデータセンターにある数千台のサーバーから発生します。各サーバーは独自のシーケンスカウンターを持つため、ルーターから見るとパケットが順序どおり到着しません。
ルーターでアンチリプレイ保護を無効にします。
多くのルーターの場合:
IPsec 設定でアンチリプレイまたはリプレイ保護の設定を探し、無効にします。
リプレイウィンドウサイズしか設定できない場合:
リプレイウィンドウを 0 に設定すると、実質的にチェックを無効にできます。
アンチリプレイの無効化に対応していない機器の場合:
Cloudflare ダッシュボードでリプレイ保護を有効にします。これにより、すべてのトンネルトラフィックが単一のサーバーを経由し、シーケンス番号は正しく保たれます。その代わり、anycast の利点は失われます。
-
Connectors ページを開きます。
Connectors を開く ↗ -
IPsec/GRE tunnels で、対象の IPsec トンネルの Edit を選びます。
-
Replay protection を有効にします。
-
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 セッションを再確立する必要があります。
この動作は想定どおりで、トンネルは自動的に回復します。影響を抑えるには、次を行います。
-
Dead Peer Detection（DPD）を restart で設定する: トンネルエンドポイントの DPD アクションを「restart」に設定し、リキーが TEMPORARY_FAILURE で失敗した場合に IKE セッションを自動再確立します。DPD の restart がないと、失敗したリキーのループに陥ることがあります。
-
リキー間隔を長くする: トンネルエンドポイントの SA 有効期間を長くし、リキーの頻度を下げます。一般的な値は、IKE SA が 8〜24 時間、IPsec SA が 1〜8 時間です。
-
ヘルスチェックの感度を調整する: リキー中の短い劣化でアラートが出る場合は、ヘルスチェックレートを下げることを検討します。
- Connectors ページを開きます。
- IPsec/GRE tunnels で、対象トンネルの Edit を選びます。
- Health check rate を Low に変更します。
-
リキー時刻をずらす: トンネルが複数ある場合は、SA 有効期間を変えて同時にリキーしないようにします。
- 双方向に設定したヘルスチェックが一貫して失敗する
- 一方向のヘルスチェックは正しく動作する
- トラフィックはトンネルを通常どおり流れる
双方向ヘルスチェックでは、プローブと応答の両方がトンネルを通る必要があります。ルーターは次を行う必要があります。
- トンネルインターフェースの IP アドレス宛ての ICMP パケットを受け入れる
- ICMP 応答をトンネル経由で Cloudflare へ戻す
トラフィックセレクターやファイアウォールルールがこのトラフィックを許可していないと、双方向ヘルスチェックは失敗します。
IPsec トンネルの場合:
トンネルインターフェースアドレス宛てのパケットを受け入れるよう、トラフィックセレクターを設定します。たとえば、トンネルインターフェースアドレスが 10.252.2.27/31 の場合は次のとおりです。
10.252.2.26（Cloudflare 側）とのあいだのトラフィックを許可する10.252.2.27（自側）とのあいだのトラフィックを許可する
すべてのトンネル種別:
トンネルインターフェース上で ICMP トラフィックをファイアウォールが許可していることを確認します。多くのファイアウォールでは、トンネルインターフェース上の管理トラフィック（ping を含む）を明示的に許可するルールが必要です。
双方向ヘルスチェックの動作の詳細は、トンネルヘルスチェック を参照してください。
- トンネルステータスが
Downのままで、健全にならない - トンネルを通るトラフィックがない
- ルーターログに IKE ネゴシエーションの失敗が記録される
IPsec トンネルの確立は、次のような設定の不一致で失敗することがあります。
| 問題 | 症状 |
|---|---|
| 暗号パラメーターの不一致 | IKE ネゴシエーションが "no proposal chosen" で失敗する |
| PSK が正しくない | Phase 1 で認証失敗になる |
| IKE ID の形式が違う | PSK は正しいのに認証失敗になる |
| ファイアウォールが IKE を遮断している | IKE トラフィックが Cloudflare に届かない |
-
暗号パラメーターが Cloudflare の対応設定と一致することを確認します。
Phase 1（IKE）
| パラメーター | 対応値 |
|---|---|
| IKE version | IKEv2 のみ |
| Encryption | AES-GCM-16、AES-CBC-256 |
| Authentication | SHA-256、SHA-384、SHA-512 |
| DH Group | DH group 14、15、16、19、20 |
Phase 2（IPsec）
| パラメーター | 対応値 |
|---|---|
| Encryption | AES-GCM-16、AES-CBC-256 |
| Authentication | SHA-256、SHA-512 |
| PFS Group | DH group 14、15、16、19、20 |
-
事前共有鍵（PSK）を確認します。
- Cloudflare ダッシュボードで PSK を再生成します
- 新しい PSK を正確にコピーします（余分な空白や文字を含めない）
- ルーターに新しい PSK を反映します
-
IKE ID の形式を確認します。 Cloudflare は IKE ID に FQDN 形式を使います。ルーターが FQDN のピア ID を受け入れるよう設定されていることを確認してください。FQDN は Cloudflare ダッシュボードのトンネル詳細に表示されます。
-
ファイアウォールルールを確認します。 エッジファイアウォールで次を許可します。
- UDP ポート
500（IKE） - UDP ポート
4500（IKE NAT-T） - IP プロトコル
50（ESP）
- UDP ポート
対応パラメーターの一覧は、対応している設定パラメーター を参照してください。
- ポリシーベース IPsec トンネルでヘルスチェックが一貫して失敗する
- トンネルのトラフィックセレクター（暗号化ドメイン）に一致するトラフィックは通常どおり流れる
- 同じ機器上のルートベーストンネルは正しく動作する
ポリシーベース IPsec トンネルは、トンネル内で許可するプレフィックスをトラフィックセレクターで定義します。Reply 形式のヘルスチェックは Cloudflare の IP アドレス宛てです。これらのアドレスはトンネルのトラフィックセレクター（顧客ネットワーク宛先だけを許可）の外になるため、トンネルエンドポイントはヘルスチェックパケットを破棄します。
さらに、一部のファイアウォール（Check Point など）は、Reply 形式のヘルスチェックパケットを自己宛ての性質からスプーフとみなし、ルートベーストンネルでも破棄することがあります。
- ヘルスチェックタイプを Reply から Request に変更します。
- トンネルエンドポイント上にループバックアドレスを設定し、ヘルスチェックのターゲットにします。ターゲットは次の条件を満たす必要があります。
- トンネルエンドポイントから到達できる
- トンネルのトラフィックセレクター（暗号化ドメイン）に含まれる
- 双方向ヘルスチェックの場合は、ヘルスチェックの送信元（Cloudflare ダッシュボードで設定するトンネルの Interface Address）もトラフィックセレクターに含まれていることを確認します。
| ベンダー | よくある問題 | 解決方法 |
|---|---|---|
| Palo Alto Networks | デフォルト設定でヘルスチェックが失敗する | ヘルスチェックタイプを Request に変更し、アンチリプレイを無効にします |
| Cisco Meraki | アンチリプレイを無効にできない | Cloudflare ダッシュボードでリプレイ保護を有効にします |
| AWS VPN Gateway | アンチリプレイを無効にできない | Cloudflare ダッシュボードでリプレイ保護を有効にします |
| VeloCloud | アンチリプレイを無効にできない | Cloudflare ダッシュボードでリプレイ保護を有効にします |
| Check Point | out-of-state パケットの破棄 | ヘルスチェックタイプを Request に変更します |
このガイドを一通り確認してもトンネルの健全性に問題がある場合は、Cloudflare サポートに連絡する前に、次の情報を集めてください。
- 影響を受けている Account ID と トンネル名
- 問題が起きた タイムスタンプ（UTC）
- トンネル設定の詳細:
- トンネル種別（GRE または IPsec）
- ヘルスチェックタイプ（Request または Reply）
- ヘルスチェックの方向（Bidirectional または Unidirectional）
- ヘルスチェックレート（Low、Medium、または High）
- ルーター情報:
- ベンダーとモデル
- ファームウェア / ソフトウェアのバージョン
- IPsec 設定（PSK は除いてサニタイズする）
- 観測した症状:
- ダッシュボードのトンネル健全性ステータス
- ユーザートラフィックへの影響の有無
- ルーターログのエラーメッセージ
- ルーターからの、トンネルトラフィックの パケットキャプチャ
- 問題発生時間帯をカバーする ルーターログ
- 自ネットワークから 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: トラフィック分析ツール