Skip to content

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

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

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

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

トンネルが確立しない（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 に設定してください。詳しい説明は アンチリプレイ保護 を参照してください。

リキーイベントによる一時的な途絶

トンネルエンドポイントが IPsec リキーを開始すると、新しいセキュリティアソシエーション（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 のドキュメント を参照してください。

アンチリプレイ保護

一部のお客様ルーターは IPsec のアンチリプレイ保護を完全には無効にできません。Magic Transit を最適に動かすには、この無効化が必要です（Cloudflare エッジでのパケット並べ替えが、誤った破棄を引き起こすためです）。

ルーターがアンチリプレイの無効化に対応していない場合:

  1. ルーターが replay window size の設定に対応しているか確認します。0 にすると、アンチリプレイ保護の無効化と同等です。
  2. アンチリプレイの無効化も、ウィンドウサイズの 0 設定もできない場合、そのルーターは Magic Transit の IPsec オンランプとして使えません。代わりに GRE トンネルまたは Cloudflare Network Interconnect（CNI）を検討してください。

IPsec 利用時のヘルスチェック失敗

デフォルトの一方向（DSR）構成では、Magic Transit のヘルスチェック応答は IPsec トンネルではなく、パブリックインターネット経由で Cloudflare に戻ります。そのため、ISP または上流ネットワークは、お客様プレフィックスからのヘルスチェック応答パケットが Cloudflare の IP レンジ ↗ に届くことを許可する必要があります。

ISP がこれらの応答パケットを遮断していると、IPsec トンネルとデータプレーンは正常でもヘルスチェックは失敗します。

症状: ヘルスチェックは失敗するが、アプリケーショントラフィックはトンネルを通常どおり流れる。

対処: 双方向ヘルスチェックに切り替えます。プローブと応答の両方がトンネルを通ります。双方向ヘルスチェックには、Magic Transit 構成で egress トラフィックを有効にする必要があります。詳細は トンネルヘルスチェック を参照してください。

役に立ちましたか？