Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

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

最終更新 Markdown で表示Agent セットアップ

このガイドでは、初回確立から継続運用まで、IPsec トンネル（ダッシュボードではコネクターとも呼びます）の問題を診断します。次の各セクションで症状を特定し、対応する対処を確認してください。

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

症状

  • トンネルステータスが Down のまま、正常になりません
  • トンネルを通るトラフィックがありません
  • トンネルエンドポイントのログに IKE ネゴシエーションエラーまたは再送が出ます

考えられる原因と対処

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

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

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

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

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

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

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

Phase 1 の認証失敗は、PSK の不一致を示します。対処手順は次のとおりです。

  1. Connectors を開き、対象のトンネルを選びます。

    Connectors を開く ↗

  2. Generate new PSK を選びます。

  3. 新しい PSK をそのままコピーします。余分な空白や文字を足さないでください。

  4. トンネルエンドポイントに新しい 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 はトンネル経由でプローブを送りますが、応答はパブリックインターネット経由（direct server return）で戻ります。ISP が Cloudflare 宛ての ICMP 応答パケットをブロックしていると、トンネルトラフィックは問題なくてもヘルスチェックは失敗します。

egress トラフィックを有効にしている場合は、プローブと応答の両方をトンネル経由にする双方向ヘルスチェックへの切り替えを検討してください。設定の詳細は トンネルヘルスのトラブルシューティング を参照してください。

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

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

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

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

症状

  • トンネルが正常と異常のあいだを行き来します
  • トンネル上で断続的なパケットロスが起きます
  • 設定変更なしで、一定時間動いたあとトラフィックが止まります

考えられる原因と対処

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

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

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

再鍵（rekey）による短時間の切断

トンネルエンドポイントが 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 ジョブを設定する

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

    Logpush を開く ↗

  2. Create a Logpush job を選びます。

  3. データセットとして IPsec logs を選びます。

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

役に立ちましたか？