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 のエニーキャスト構成では、トンネルトラフィックは数千台のサーバーから送られ、それぞれが独自のシーケンスカウンターを持ちます。その結果、トンネルエンドポイントはパケットを順序外れとして破棄します。

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

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

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

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

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

単方向ヘルスチェックでは、Cloudflare はトンネル経由でプローブを送りますが、応答はパブリックインターネット(ダイレクトサーバーリターン)で戻ります。ISP が Cloudflare 宛ての ICMP 応答パケットをブロックすると、トンネルトラフィックは正常でもヘルスチェックは失敗します。

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

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

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

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


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

症状

  • トンネルが健全な状態と不健全な状態を行き来する
  • トンネル上で断続的なパケットロスが起きる
  • 構成を変えていないのに、一定時間動いたあとトラフィックが止まる

想定される原因と対処

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

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

トンネルエンドポイントでアンチリプレイ保護を無効にするか、リプレイウィンドウを 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 トンネルで 14001450 です。詳細は、MTU と MSS を参照してください。


IPsec ログで監視する

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

IPsec の Logpush ジョブを設定する

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

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

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

機能の詳細は Logpush のドキュメント を参照してください。データセットの 利用可能なフィールド も確認できます。


その他の WAN リソース

詳細は、Cloudflare WAN のドキュメント全体を参照してください。

IPsec トラブルシューティングガイド全体 ❯

役に立ちましたか?