IPsec トンネルのトラブルシューティング

このガイドは、初期確立から継続運用まで、IPsec トンネル（ダッシュボードではコネクターとも呼ばれます）の問題を切り分けるときに使います。次の各セクションで症状を特定し、適切な対処を見つけてください。

トンネルが確立しない（IKE ネゴシエーション失敗）

症状

トンネルステータスが Down のままで、健全になりません
トンネルをトラフィックが通りません
トンネルエンドポイントのログに、IKE ネゴシエーションエラーや再送が表示されます

考えられる原因と対処

ファイアウォールが IKE トラフィックを遮断している

エッジファイアウォールが、IPsec トンネル確立に必要なトラフィックを遮断している場合があります。ファイアウォールで次を許可しているか確認してください。

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

暗号パラメーターの不一致

トンネルエンドポイントと Cloudflare の間で、フェーズ 1（IKE）またはフェーズ 2（IPsec）のパラメーターが一致しないと、IKE ネゴシエーションは失敗します。よくある症状は、デバイスログの "no proposal chosen" エラーです。

パラメーターが Cloudflare の対応値と一致しているか確認してください。一覧は対応している設定パラメーターを参照してください。

事前共有鍵（PSK）の不一致

フェーズ 1 の認証失敗は、PSK の不一致を示します。次の手順で解消します。

Connectors を開き、対象のトンネルを選びます。
Connectors を開く ↗
Generate new PSK を選びます。
新しい PSK を正確にコピーします。余分なスペースや文字を付けないでください。
トンネルエンドポイントを新しい PSK で更新します。

IKE ID 形式の不一致

Cloudflare は IKE ID に FQDN 形式を使います。トンネルエンドポイントが別のピア識別形式（IP アドレスなど）を期待していると、PSK が正しくても認証は失敗します。

トンネルエンドポイントが FQDN のピア識別を受け入れるよう設定してください。トンネルの FQDN は、Connectors で対象トンネルを選び、トンネル詳細で確認できます。

トンネルは確立するがヘルスチェックが失敗する

症状

IKE ネゴシエーションは成功します
ダッシュボードではトンネルが Down または Degraded と表示されます
ユーザートラフィックはトンネルを通る場合があります

考えられる原因と対処

トンネルエンドポイントでアンチリプレイ保護が有効

これは IPsec で最もよくある問題です。アンチリプレイ保護は、単一の送信元からパケットが順番に届くことを想定します。Cloudflare の anycast アーキテクチャでは、トンネルトラフィックは数千台のサーバーから発信され、それぞれが独自のシーケンスカウンターを持ちます。そのため、トンネルエンドポイントはパケットを順序外として破棄します。

トンネルエンドポイントでアンチリプレイ保護を無効にするか、リプレイウィンドウを 0 に設定してください。詳しい説明はアンチリプレイ保護を参照してください。

ヘルスチェック種類がステートフルファイアウォールと互換でない

ステートフルファイアウォール（Palo Alto Networks、Check Point、Cisco、Fortinet など）は、デフォルトの Reply ヘルスチェックパケットを破棄します。セッションテーブルに一致する ICMP リクエストがないためです。

ヘルスチェック種類を Reply から Request に変更してください。手順の詳細はトンネルヘルスのトラブルシューティングを参照してください。

ISP がヘルスチェックの戻り経路を遮断している

一方向のヘルスチェックでは、Cloudflare はトンネル経由でプローブを送りますが、応答はパブリックインターネット経由で戻ります（ダイレクトサーバーリターン）。ISP が Cloudflare 宛て ICMP reply パケットを遮断していると、トンネルトラフィックは通常どおり動いていてもヘルスチェックは失敗します。

出力トラフィックが有効なら、双方向ヘルスチェックへの切り替えを検討してください。プローブと応答の両方がトンネルを通ります。設定の詳細はトンネルヘルスのトラブルシューティングを参照してください。

ポリシーベース VPN でのヘルスチェック失敗

ポリシーベース VPN（トラフィックセレクターが 0.0.0.0/0 ではなく特定プレフィックスを定義する方式）では、Reply 方式のヘルスチェックは動きません。Reply ヘルスチェックは Cloudflare の IP アドレス宛てに自己アドレスされるため、トンネルのトラフィックセレクターの外になります。

代わりに Request 方式のヘルスチェックを使ってください。トンネルエンドポイントにループバックアドレスを設定し、ヘルスチェックのターゲットにします。ターゲットはルーティング可能で、トンネルのトラフィックセレクター（暗号化ドメイン）に含まれている必要があります。詳細はトンネルヘルスのトラブルシューティングを参照してください。

トンネルが断続的に動作する（フラッピング）

症状

トンネルが健全と不健全の間で切り替わります
トンネルで断続的なパケットロスが発生します
設定変更なしに、一定時間動いたあとトラフィックが止まります

考えられる原因と対処

アンチリプレイ保護が順序外パケットを破棄している

Cloudflare の anycast アーキテクチャでは、パケットはシーケンスカウンターの異なる多数のサーバーから届きます。アンチリプレイ保護はこれをリプレイ攻撃と解釈し、パケットを断続的に破棄します。

リキーイベントによる短時間の中断

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

Cloudflare はリキーを開始せず、応答するだけです。リキーの試行はすべてトンネルエンドポイント側から行います。リキー中にデバイスが TEMPORARY_FAILURE 応答を受け取った場合は、Dead Peer Detection（DPD）に "restart" アクションを設定し、IKE セッションを自動で再確立するようにします。DPD の restart がないと、失敗したリキーのループに陥ることがあります。

リキーの影響を抑えるには、トンネルエンドポイントの SA 寿命を長くしてリキー頻度を下げます。よく使う値は、IKE SA が 8〜24 時間、IPsec SA が 1〜8 時間です。詳細はトンネルヘルスのトラブルシューティングを参照してください。

MTU の問題

トンネル MTU を超えるパケットは断片化または破棄され、断続的な接続障害の原因になります。MTU が正しく設定されているか確認してください。通常、GRE トンネルは 1476、IPsec トンネルは 1400〜1450 です。詳しい指針は MTU と MSS を参照してください。

IPsec ログで監視する

IPsec ネゴシエーションの鍵交換フェーズにおけるトンネル活動を監視するには、IPsec ログを使います。Logpush ジョブを設定し、分析用の任意のストレージサービスへこれらのログを転送します。

IPsec の Logpush ジョブを設定する

Logpush ページを開きます。
Logpush を開く ↗
Create a Logpush job を選びます。
データセットとして IPsec logs を選びます。

機能の詳細と、データセットで利用できるフィールドについては、Logpush のドキュメントを参照してください。