Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
このページの内容
 

IPsec VPN向けIKE

IPsec VPN用のIKEv2とJunos OSでのその設定について説明します。

Internet Key Exchange version 2(IKEv2)は、IPsecベースのトンネリングプロトコルです。IKEv2は、ピアVPNデバイス間のセキュアなVPN通信チャネルを提供し、IPsecセキュリティアソシエーション(SA)のネゴシエーションと認証を保護された方法で定義します。

機能エクスプローラーを使用して、特定の機能のプラットフォームとリリースのサポートを確認します。

プラットフォームに関連する注意事項については、「 プラットフォーム固有のIKEv2レスポンダーのみの動作 」のセクションを参照してください。

IKEおよびIPsecパケット処理

IKEはIPsecのトンネル管理を提供し、エンドエンティティを認証します。IKEは、Diffie-Hellman(DH)鍵交換を実行して、ネットワークデバイス間にIPsecトンネルを生成します。IKEによって生成されるIPsecトンネルは、IPレイヤーのネットワークデバイス間のユーザートラフィックの暗号化、復号化、認証に使用されます。

IKEパケット処理

トンネリングを必要とするジュニパーネットワークスデバイスにクリアテキスト パケットが到着し、そのトンネルにアクティブなフェーズ 2 SA が存在しない場合、Junos OS は IKE ネゴシエーションを開始し、パケットを破棄します。IP パケットヘッダー内の送信元アドレスと宛先アドレスは、それぞれローカルおよびリモートの IKE ゲートウェイです。IP パケット ペイロードには、ISAKMP(IKE)パケットをカプセル化した UDP セグメントがあります。IKEパケットの形式は、フェーズ1とフェーズ2で同じです。 図1をご覧ください。

その間に、送信元ホストは破棄されたパケットを再送しました。通常、2番目のパケットが到着する頃にはIKEネゴシエーションは完了し、Junos OSはパケットとセッション内の後続のすべてのパケットをIPsecで保護してから転送します。

図1:フェーズ1およびフェーズ2のIKEパケットDiagram of a network packet structure with IP, UDP, and ISAKMP headers for IKE protocol in IPsec communications.

[次のペイロード] フィールドには、次のいずれかのペイロード タイプを示す数字が含まれています。

  • 0002—SA ネゴシエーション ペイロードには、フェーズ 1 またはフェーズ 2 SA の定義が含まれています。

  • 0004—プロポーザルペイロードは、フェーズ1またはフェーズ2のプロポーザルにすることができます。

  • 0008—変換ペイロードは、SAペイロードにカプセル化されるプロポーザルペイロードにカプセル化されます。

  • 0010—KE(鍵交換)ペイロードには、DHパブリック値など、鍵交換の実行に必要な情報が含まれています。

  • 0020—識別(IDx)ペイロード。

    • フェーズ1では、IDiiはイニシエーターIDを示し、IDirはレスポンダIDを示します。

    • フェーズ 2 では、IDui はユーザー イニシエーターを示し、IDur はユーザー レスポンダーを示します。

    ID は、FQDN、U-FQDN、IP アドレス、ASN.1_DN などのIKE ID タイプです。

  • 0040—証明書(CERT)ペイロード。

  • 0080—証明書要求(CERT_REQ)ペイロード。

  • 0100—ハッシュ(HASH)ペイロードには、特定のハッシュ関数のダイジェスト出力が含まれます。

  • 0200—署名(SIG)ペイロードにはデジタル署名が含まれています。

  • 0400—ノンス(Nx)ペイロードには、交換に必要な擬似乱数情報が含まれています)。

  • 0800—ペイロードに通知します。

  • 1000—ISAKMP 削除ペイロード。

  • 2000—ベンダーID(VID)ペイロードは、フェーズ1の交渉のどこにでも含めることができます。Junos OSはこれを使用して、NAT-Tのサポートをマークします。

各 ISAKMP ペイロードは、 図 2 に示すように、同じ汎用ヘッダーから開始します。

図2:汎用ISAKMPペイロードヘッダーDiagram of a network packet header with fields: Next Header, Reserved, Transform Payload Length in bytes, and Payload.

複数の ISAKMP ペイロードをチェーン化し、後続の各ペイロード タイプを [次のヘッダー] フィールドの値で示すことができます。値 0000 は、最後の ISAKMP ペイロードを示します。例については 、図3 を参照してください。

図3:汎用ISAKMPペイロードStructure of an IKE packet in the IKE protocol showing fields like Initiator's SPI, Responder's SPI, Next Payload, Version, Exchange Type, and Flags.を使用したISAKMPヘッダー

IPsecパケット処理

IKEネゴシエーションが完了し、2つのIKEゲートウェイがフェーズ1とフェーズ2のSAを確立した後、後続のすべてのパケットがトンネルを使用して転送されます。フェーズ 2 SA がトンネル モードで ESP(カプセル化セキュリティ プロトコル)を指定すると、 パケットは図 4 のようになります。デバイスによって、開始側ホストが送信する元のパケットに 2 つのヘッダーが追加されます。

図4に示すように、開始側ホストが構築するパケットには、ペイロード、TCPヘッダー、および内部IPヘッダー(IP1)が含まれています。

図4:IPsecパケット—トンネルモードのESP Encapsulated network packet structure with IP2 Header, ESP Header, IP1 Header, TCP Header, and Payload for secure transmission.

Junos OS が追加するルーター IP ヘッダー(IP2)には、宛先 IP アドレスとしてリモート ゲートウェイの IP アドレスが、送信元 IP アドレスとしてローカル ルーターの IP アドレスが含まれています。また、Junos OSは、外部と内部のIPヘッダー間にESPヘッダーを追加します。ESP ヘッダーには、リモート ピアがパケットを受信したときに適切に処理できるようにする情報が含まれています。 図5をご覧ください。

図5:外部IPヘッダー(IP2)とESPヘッダーStructure of an IPsec Encapsulating Security Payload ESP packet showing IPv4 header, ESP header, and ESP payload with trailer.

[次のヘッダー] フィールドは、[ペイロード] フィールド内のデータのタイプを示します。トンネル モードでは、この値は 4 で、ペイロード内に IP パケットが含まれていることを示します。 図6をご覧ください。

図6:内部IPヘッダー(IP1)とTCPヘッダーIP and TCP headers showing fields for routing, delivery, and reliable communication in the TCP/IP model.

Junos OS の IKE の概要

IKEは、インターネットなどの安全でないメディアを介して、暗号化と認証のために安全に鍵を交換する方法を提供します。IKE、1組のセキュリティゲートウェイで以下が可能になります。 セキュリティゲートウェイがトンネルや重要な情報を交換できるセキュアなトンネルを動的に確立します。トンネル属性ネゴシエーションや鍵管理など、ユーザーレベルのトンネルまたはSAを設定します。これらのトンネルは、同じセキュアチャネル上で更新して終了することもできます。IKEはDiffie-Hellman方式を採用しており、IPsecではオプションです(共有鍵はエンドポイントで手動で入力できます)。

IKEv2は以下をサポートします。

  • ルートベースVPN

  • サイトツーサイトVPN。

  • デッドピアの検出

  • シャーシクラスター。

  • 事前共有キー認証。

  • 証明書ベースの認証。

  • 子SA。IKEv2の子SAは、IKEv1のフェーズ2SAとして知られています。IKEv2では、基盤となるIKESAなしでは子SAは存在できませんIKE。

  • AutoVPN

  • 動的エンドポイント VPN

  • EAPは、IKEv2を使用したリモートアクセスでサポートされています。

  • トラフィックセレクター。

IKEv2は、以下の機能をサポートしていません。

  • ポリシーベースのVPN。

  • VPN監視。

  • IPComp(IP ペイロード圧縮プロトコル)。

Junos OS での IKEv2 の設定

VPNピアは、IKEv1またはIKEv2のいずれかとして設定されます。ピアがIKEv2として構成されている場合、リモートピアがIKEv1ネゴシエーションを開始しても、IKEv1にフォールバックすることはできません。デフォルトでは、ジュニパーネットワークスのセキュリティデバイスはIKEv1ピアです。

version v2-only 構成ステートメントを [edit security ike gateway gw-name ] 階層レベルで使用して、IKEv2 を構成します。

IKEバージョンは、 show security ike security-associations および show security ipsec security-associations CLI操作コマンドの出力に表示されます。

ジュニパーネットワークスデバイスは、フェーズ2ネゴシエーションで最大4つのプロポーザルをサポートします。これにより、受け入れるトンネルパラメーターの範囲をどのくらい制限するかを定義できます。Junos OS は、定義済みの標準、互換、基本フェーズ 2 のプロポーザル セットを提供します。カスタムフェーズ2プロポーザルを定義することもできます。

IKEv2構成ペイロードについて

構成ペイロードは、応答側から開始側にプロビジョニング情報を伝送するために提供される Internet Key Exchange バージョン 2(IKEv2)オプションです。IKEv2構成ペイロードは、ルートベースVPNでのみサポートされます。

RFC 5996、 Internet Key Exchange Protocol Version 2(IKEv2)では、応答側が開始側に返すことのできる15種類の構成属性が定義されています。 表1は 、ファイアウォールでサポートされているIKEv2構成属性を示しています。

表1:IKEv2の設定属性

属性タイプ

値

説明

長さ

INTERNAL_IP4_ADDRESS

1

内部ネットワーク上のアドレスを指定します。複数の内部アドレスを要求できます。レスポンダは、要求されたアドレス数まで送信できます。

0または4オクテット

INTERNAL_IP4_NETMASK

2

内部ネットワークのネットマスク値を指定します。リクエストメッセージとレスポンスメッセージで使用できるネットマスク値は1つだけ(例:255.255.255.0)で、INTERNAL_IP4_ADDRESS属性でのみ使用する必要があります。

0または4オクテット

INTERNAL_IP4_DNS

3

ネットワーク内のDNSサーバーのアドレスを指定します。複数のDNSサーバーを要求できます。レスポンダは、0個以上のDNSサーバー属性で応答できます。

0または4オクテット

INTERNAL_IP4_NBNS

4

ネットワーク内のNetBIOSネームサーバー(NBNS)(WINSサーバーなど)のアドレスを指定します。複数のNBNSサーバーをリクエストできます。レスポンダは、0個以上のNBNSサーバー属性で応答できます。

0または4オクテット

INTERNAL_IP6_ADDRESS

8

内部ネットワーク上のアドレスを指定します。複数の内部アドレスを要求できます。レスポンダは、要求されたアドレス数まで送信できます。

0または17オクテット

INTERNAL_IP6_DNS

10

ネットワーク内のDNSサーバーのアドレスを指定します。複数のDNSサーバーを要求できます。レスポンダは、0個以上のDNSサーバー属性で応答できます。

0または16オクテット

IKEレスポンダーがイニシエーターにプロビジョニング情報を提供するには、RADIUSサーバーなどの指定されたソースから情報を取得する必要があります。プロビジョニング情報は、DHCP サーバーから RADIUS サーバーを介して返すこともできます。RADIUSサーバーでは、ユーザー情報に認証パスワードを含めることはできません。RADIUSサーバープロファイルは、[edit security ike gateway gateway-name ]階層レベルのaaa access-profile profile-name 設定を使用してIKEゲートウェイにバインドされます。

Junos OSでは、IKEv2設定ペイロードが改善され、以下の機能がサポートされるようになりました。

  • IPv4およびIPv6ローカルアドレスプールのサポート。また、固定IPアドレスをピアに割り当てることもできます。

    IKE確立中に、イニシエーターはレスポンダーにIPv4アドレス、IPv6アドレス、DNSアドレス、またはWINSアドレスを要求します。レスポンダはイニシエーターの認証に成功した後、ローカルアドレスプールまたはRADIUSサーバー経由でIPアドレスを割り当てます。設定に応じて、このIPアドレスはピアが接続するたびに動的に割り当てられるか、固定IPアドレスとして割り当てられます。RADIUSサーバーがフレームプールで応答した場合、Junos OSは対応するローカルプールから設定に基づいてIPアドレスまたは情報を割り当てます。ローカルアドレスプールとRADIUSサーバーの両方を設定した場合、RADIUSサーバーから割り当てられたIPアドレスがローカルプールよりも優先されます。ローカルIPアドレスプールを設定し、RADIUSサーバーがIPアドレスを返さなかった場合、ローカルプールはそのIPアドレスをリクエストに割り当てます。

  • 追加オプション none 、 authentication-order向けに導入されました。 認証順序(アクセスプロファイル)を参照してください。

  • RADIUSアカウンティングの開始および停止メッセージは、トンネルまたはピアの状態をRADIUSサーバーに通知します。これらのメッセージは、追跡目的やDHCPサーバーなどのサブシステムへの通知に使用できます。

    RADIUSサーバーがアカウンティング開始メッセージまたはストップメッセージをサポートしていることを確認します。また、ファイアウォールと RADIUS サーバーの両方に、これらのメッセージを追跡するための適切な設定があることを確認します。

  • IPv6サポートの導入により、設定ペイロードを使用したデュアルスタックトンネルが可能になります。ログインプロセス中に、IKEはIPv4アドレスとIPv6アドレスの両方を要求します。AAAは、要求されたすべてのアドレスが正常に割り当てられた場合にのみログインを許可します。要求されたIPが割り当てられていない場合、IKEはネゴシエーションを終了します。

ルートベースVPNでは、セキュアトンネル(st0)インターフェイスは、ポイントツーマルチポイントモードまたはポイントツーポイントモードで動作します。IKEv2構成ペイロードを介したアドレス割り当てが、ポイントツーマルチポイントモードまたはポイントツーポイントモードでサポートされるようになりました。ポイントツーマルチポイントインターフェイスの場合、インターフェイスに番号を付け、設定ペイロードINTERNAL_IP4_ADDRESS属性タイプのアドレスが、関連するポイントツーマルチポイントインターフェイスのサブネットワーク範囲内である必要があります。

IKEゲートウェイ構成のIKEv2構成ペイロード要求に共通のパスワードを構成できます。1文字から128文字の範囲の共通パスワードで、管理者は共通パスワードを定義できます。このパスワードは、ファイアウォールがIKEv2設定ペイロードを使用してリモートIPsecピアに代わってIPアドレスを要求する場合に、ファイアウォールとRADIUSサーバーの間で使用されます。RADIUSサーバーは、設定ペイロード要求に対してファイアウォールにIP情報を提供する前に、資格情報を照合します。[edit security ike gateway gateway-name aaa access-profile access-profile-name]階層レベルでconfig-payload-password configured-password 設定ステートメントを使用して共通パスワードを設定できます。

ファイアウォールとRADIUSサーバーの両方に同じパスワードを設定し、認証プロトコルとしてパスワード認証プロトコル(PAP)を使用するようにRADIUSサーバーを認証する必要があります。これがないと、トンネル確立は成功しません。

注:ikedプロセスは、DHCPプールやアドレス割り当て方法に依存しません。VPN トンネルがダウンすると、Junos OS は割り当てられたアドレスを解放します。

図7 は、IKEv2構成ペイロードの典型的なワークフローを示しています。

図7: IKEv2の代表的な構成ペイロードワークフローSequence diagram of IKEv2 VPN connection setup, showing interactions between IKE peer, DHCP server, SRX device, Radius server, and optional DHCP server.

IKEv2設定ペイロード機能は、ポイントツーマルチポイントのセキュアトンネル(st0)インターフェイスとポイントツーポイントインターフェイスの両方でサポートされます。ポイントツーマルチポイントインターフェイスには番号が付けられる必要があり、設定ペイロードで指定されたアドレスは、関連するポイントツーマルチポイントインターフェイスのサブネットワーク範囲内にある必要があります。

Picoセルプロビジョニングについて

IKEv2構成ペイロードを使用して、ファイアウォールなどのIKEレスポンダーから、セルラーネットワーク内のLTEピコセル基地局などの複数のイニシエーターにプロビジョニング情報を伝送できます。ピコセルは、ファイアウォールに接続できる標準設定で出荷されますが、ピコセルのプロビジョニング情報は、保護されたネットワーク内の1台以上のプロビジョニングサーバーに保存されます。ピコセルは、プロビジョニングサーバーとの安全な接続を確立した後、完全なプロビジョニング情報を受け取ります。

ピコセルをブートストラップしてプロビジョニングし、サービスに導入するために必要なワークフローには、4つの異なる段階があります。

  1. 初期アドレスの取得—ピコセルは工場から以下の情報とともに出荷されます。

    • ファイアウォールへのセキュア ゲートウェイ トンネルの設定

    • メーカー発行のデジタル証明書

    • 保護されたネットワーク内にあるプロビジョニングサーバーの完全修飾ドメイン名(FQDN)

    ピコセルが起動し、DHCPサーバーからIKEネゴシエーションに使用するアドレスを取得します。次に、このアドレスを使用して、ファイアウォール上のセキュアゲートウェイへのトンネルが構築されます。OAM(運用、管理、および管理)トラフィックのアドレスも、保護されたネットワークで使用するためにDHCPサーバーによって割り当てられます。

  2. ピコセルのプロビジョニング—割り当てられたOAMトラフィックアドレスを使用して、ピコセルはプロビジョニング情報(通常は運用担当者証明書、ライセンス、ソフトウェア、設定情報)を、保護されたネットワーク内のサーバーに要求します。

  3. 再起動—ピコセルが再起動し、取得したプロビジョニング情報を使用して、サービスプロバイダのネットワークおよび運用モデルに固有の情報を作成します。

  4. サービスプロビジョニング—ピコセルがサービスを開始すると、識別名(DN)とサブジェクトの代替名値を含む単一の証明書とFQDNを使用して、ファイアウォール上のセキュアゲートウェイへの2つのトンネルを構築します。1つはOAMトラフィック用、もう1つは3GPP(Third-Generation Partnership Project)データトラフィック用です。

関連項目

IKEの提案

IKE構成は、ピアセキュリティゲートウェイとのセキュアなIKE接続を確立するために使用されるアルゴリズムとキーを定義します。1つ以上のIKEプロポーザルを設定できます。各プロポーザルは、IKEホストとそのピア間のIKE接続を保護するためのIKE属性のリストです。

IKEプロポーザルを設定するには、 proposal ステートメントを含め、[edit security ike ]階層レベルで名前を指定します。

IKEポリシー

IKEポリシーは、IKEネゴシエーション中に使用するセキュリティパラメーター(IKEプロポーザル)の組み合わせを定義します。ピアアドレスとその接続に必要なプロポーザルを定義します。使用される認証方法に応じて、特定のピアまたはローカル証明書の事前共有キー(PSK)が定義されます。IKEネゴシエーション中に、IKEは両方のピアで同じIKEポリシーを探します。ネゴシエーションを開始するピアは、すべてのポリシーをリモートピアに送信し、リモートピアは一致するものを見つけようとします。2つのピアの両方のポリシーに、同じ設定された属性を含むプロポーザルがある場合に一致が行われます。ライフタイムが同一でない場合は、(ホストとピアから)2つのポリシー間の短い方のライフタイムが使用されます。設定されたPSKもピアと一致する必要があります。

まず、1つ以上のIKEプロポーザルを設定します。次に、これらのプロポーザルを IKE ポリシーに関連付けます。

IKEポリシーを設定するには、 policy ステートメントを含め、[edit security ike]階層レベルでポリシー名を指定します。

鍵更新と再認証

概要

IKEv2では、鍵更新と再認証は別個のプロセスです。鍵更新により、IKEセキュリティアソシエーション(SA)用の新しい鍵が確立され、メッセージIDカウンターがリセットされますが、ピアの再認証は行われません。再認証は、VPNピアが認証資格情報へのアクセスを保持していることを確認します。再認証により、IKE SA と子 SA 用の新しい鍵が確立されます。保留中の IKE SA または子 SA の鍵更新は不要になりました。新しい IKE と子 SA が作成された後、古い IKE と子 SA が削除されます。

IKEv2の再認証は、デフォルトでは無効になっています。再認証を有効にするには、再認証の頻度値を1から100の間で設定します。再認証の頻度とは、再認証が行われるまでに発生する IKE 鍵更新の回数のことです。例えば、再認証の頻度を1として構成した場合、IKE鍵更新のたびに再認証が行われます。再認証の頻度を2として構成した場合、IKE鍵更新2回につき再認証が行われます。再認証の頻度を3として構成すると、IKE鍵更新3回ごとに再認証が行われる、という具合です。

再認証の頻度は、[edit security ike policy policy-name]階層レベルのreauth-frequencyステートメントで設定します。再認証は、再認証の頻度を0(デフォルト)に設定することで無効になります。再認証の頻度はピアによってネゴシエートされず、各ピアは独自の再認証頻度値を持つことができます。

サポートされている機能

IKEv2の再認証は、以下の機能でサポートされています。

  • IKEv2開始側または応答側

  • デッドピア検出(DPD)

  • 仮想ルーターの仮想ルーターとセキュア トンネル(st0)インターフェイス

  • ネットワークアドレス変換トラバーサル(NAT-T)

  • アクティブ/アクティブおよびアクティブ/パッシブモードのシャーシクラスター

  • ISSU(インサービスソフトウェアアップグレード)

  • ISHU(インサービスハードウェアアップグレード)手順を使用した新しいSPU(サービス処理ユニット)のアップグレードまたは挿入

制限事項

IKEv2 再認証を使用する場合は、以下の点に注意してください。

  • NAT-T を使用すると、以前の IKE SA とは異なるポートを使用して新しい IKE SA を作成できます。このシナリオでは、古い IKE SA は削除されない可能性があります。

  • NAT-Tシナリオでは、NATデバイスの背後にあるイニシエーターが、再認証後にレスポンダーになることができます。NATセッションが期限切れになると、NATデバイスは、別のポートに到着する可能性のある新しいIKEパケットを破棄することがあります。NATセッションを有効に維持するには、NAT-TキープアライブまたはNATDPDを有効にする必要があります。AutoVPNの場合、スポークに設定された再認証の頻度は、ハブに設定された再認証の頻度よりも小さくすることが推奨されます。

  • 再認証の頻度に基づいて、元のIKE SAの開始側または応答側のいずれかが新しいIKE SAを開始できます。EAP(Extensible Authentication Protocol)の認証と設定ペイロードでは、元のIKE SAと同じパーティがIKE SAを開始する必要があるため、EAP認証または設定ペイロードでは再認証はサポートされていません。

IKE認証(証明書ベースの認証)

証明書認証のためのマルチレベル階層

証明書ベースの認証は、IKEネゴシエーション中にファイアウォールでサポートされている認証方法です。大規模なネットワークでは、複数の認証局(CA)がそれぞれのエンドデバイスにエンドエンティティ(EE)証明書を発行できます。個々の場所、部門、または組織ごとに個別のCAを持つのが一般的です。

証明書ベースの認証に単一レベルの階層が採用されている場合、ネットワーク内のすべてのEE証明書は、同じCAによって署名される必要があります。すべてのファイアウォールデバイスには、ピア証明書の検証用に同じCA証明書が登録されている必要があります。IKEネゴシエーション中に送信される証明書ペイロードには、EE証明書のみが含まれています。

または、IKEネゴシエーション中に送信される証明書ペイロードには、EEおよびCA証明書のチェーンを含めることができます。 証明書チェーン は、ピアのEE証明書を検証するために必要な証明書のリストです。証明書チェーンには、EE証明書と、ローカルピアに存在しないCA証明書が含まれます。

ネットワーク管理者は、IKE ネゴシエーションに参加しているすべてのピアが、それぞれの証明書チェーンに少なくとも 1 つの共通の信頼できる CA を持っていることを確認する必要があります。共通の信頼できる CA がルート CA である必要はありません。EEの証明書とチェーンの最上位CAの証明書を含めたチェーン内の証明書の数は、10を超えることはできません。

設定された IKE ピアの検証は、指定された CA サーバーまたは CA サーバーのグループを使用して実行できます。証明書チェーンでは、ルート CA が IKE ポリシーで設定された信頼できる CA グループまたは CA サーバーと一致する必要があります。

図 8 に示されている CA 階層の例では、ルート CA はネットワーク内のすべてのデバイスに対して共通の信頼できる CA です。Root-CA発行CA、エンジニアリングCAとSales CAに証明書を発行します。これらは、それぞれEng-CAとSales-CAとして識別されます。Eng-CAは、それぞれDev-CAとQa-CAとして識別される開発および品質保証CAに証明書CA発行します。ホスト-AはDev-CAからEE証明書を受け取り、ホスト-BはSales-CAからEE証明書を受け取ります。

図8:証明書ベースの認証のためのマルチレベル階層Multilevel Hierarchy for Certificate-Based Authentication

各エンド デバイスには、その階層内の CA 証明書を読み込む必要があります。Host-Aには、Root-CA、Eng-CA、Dev-CA証明書が必要です。Sales-CA および Qa-CA 証明書は必要ありません。Host-Bには、Root-CAおよびSales-CA証明書が必要です。証明書は、デバイスに手動で読み込むことも、SCEP(簡易証明書登録プロセス)を使用して登録することもできます。

各エンドデバイスは、証明書チェーン内の各 CA の CA プロファイルを設定する必要があります。以下の出力は、ホストAに設定されたCAプロファイルを示しています。

以下の出力は、ホスト-Bに設定されたCAプロファイルを示しています。

関連項目

IKEv2での署名認証

IKEv2のシグネチャ認証方法とそのJunos OSでの仕組みについては、このトピックをお読みください。

IKEv2(Internet Key Exchange バージョン 2)プロトコルは、公開キー暗号化を使用する署名ベースの認証をサポートします。IKEv2では、署名ベースの認証は、署名アルゴリズムごとに1つの認証方法をサポートします。例えば、IKEピアは、これらのデジタル署名ごとに、RSA、デジタル署名アルゴリズム(DSA)、楕円曲線DSA(ECDSA)という個別の認証方法を使用します。各ハッシュアルゴリズムは、認証用の1つのシグネチャに関連付けられています。IKEv2プロポーザル設定で、認証方法を指定すると、デバイスはその方法を使用してIKEv2メッセージのソースを認証します。IKEピアが、どのハッシュアルゴリズムがシグネチャに関連付けられているかを知ることは困難です。このプロセスは、新しいアルゴリズムが導入されるたびにさらに面倒になります。IKEv2の詳細については 、「Internet Key Exchange 」を参照してください。

RFC 7427に基づくデジタル署名認証方法を使用して、これらの課題に対処できます。この方法は、IKEピアがサポートされている署名アルゴリズムのいずれかを使用し、署名ハッシュアルゴリズムをネゴシエートできるため、シグネチャベースの認証方法と比較してより汎用的です。IKEv2の署名認証について理解するには、以下をお読みください。

IKEv2における署名認証の実装

Junos OS は、アルゴリズムごとに署名ベースの認証をサポートすることに加えて、RFC 7427 で説明されているデジタル署名認証方法もサポートします。この方法では、IKEv2認証ペイロードは、公開キーのタイプだけでなく、デバイスが署名を生成するために使用するハッシュアルゴリズムも示します。デバイスは、SIGNATURE_HASH_ALGORITHM通知を使用して、RFC 7427のサポートについてピアに通知し、サポートされているハッシュアルゴリズムのリストを提供します。

この機能を使用するには、デバイスでデジタル署名認証方法を設定する必要があります。デジタル署名認証方法の詳細については、提案(セキュリティIKE)を参照してください。設定オプションsignature-hash-algorithmを使用して、受信した各シグネチャハッシュアルゴリズムと階層順に一致させる必要がある特定のシグネチャハッシュアルゴリズムを定義できます。シグネチャハッシュアルゴリズムを指定しない場合、デバイスは、サポートされているすべてのハッシュアルゴリズムのデフォルトリストから受信したシグネチャハッシュアルゴリズムと一致します。シグネチャハッシュアルゴリズム(セキュリティIKE)を参照してください。

Junos OSでは、認証方法には、IKEv2メッセージフローで定義された以下の手順が含まれます。詳細については、RFC 7296、 Internet Key Exchange Protocol Version 2(IKEv2) を参照してください。

  • 両方の IKE ピアは、最初にサポートされているハッシュ アルゴリズムのリストを互いに通知します。デバイスは、IKE_SA_INITメッセージ内のSIGNATURE_HASH_ALGORITHMペイロードをピアデバイスに送信し、応答を受信します。その後、ピアはシグネチャハッシュアルゴリズムをネゴシエートします。

  • IKE_AUTHメッセージでは、ピアはデジタル署名認証方法を交換します。

デバイスは、次のいずれかのシナリオでデフォルトの証明書認証方法を使用します。

  • レスポンダは RFC 7427 をサポートしていません。

  • イニシエーターは、受信したハッシュ アルゴリズムをサポートしていません。

利点

  • 柔軟性 - 従来のデジタル署名と新しいデジタル署名が含まれます。

  • 使いやすさ—既存のPKI(公開鍵基盤)に統合します。

  • 堅牢なソリューション—署名ベースの認証方法と比較して優れた本人確認を実行し、IKEピアの全体的なセキュリティと信頼性を向上させます。

関連項目

DDoS攻撃からのIKE保護

このトピックを読み、ジュニパーがIPsec VPN IKE実装を分散型サービス拒否(DDoS)攻撃から保護し、実装を監視する方法を理解してください。

サービス拒否(DoS)は、安全でないIPsec VPNネットワークで最も一般的ですが深刻な攻撃の1つです。DoS攻撃は、ネットワークインフラストラクチャに多くの足場を必要としないため、迅速かつ容易にネットワークをつかむ方法となります。サイバー攻撃者は、ネットワークを制御するためにこの方法を選択します。

DoS攻撃では何が起こるか?

攻撃者は、あまりにも多くのトラフィックでネットワークをフラッディングして徐々にクラッシュさせようとし、ネットワークリソースを使い果たし、メモリやCPUなどのデバイスリソースをさらに制御します。攻撃者が複数のオーケストレーションされたシステムを使用して制御し、単一のターゲットを同期的に攻撃しようとする場合、それは分散型 DoS(DDoS)攻撃と呼ばれます。

IKE実装のDDoS脆弱性

リモートピア(イニシエーター)がSA_INITメッセージを送信すると、ローカルピア(レスポンダー)が返信し、メッセージ構造にメモリを割り当てます。このセッションは、IKE_AUTHメッセージによって認証が発生するまで、 ハーフオープンIKEセッション と呼ばれます。ピアが IKE セキュリティ アソシエーション(SA)を確立すると、セッションは フルオープンの IKE セッションになります。

IKEv2 DDoS の脆弱性を理解するために、攻撃者が IKE SA に対して簡単な攻撃ベクトルを作成する方法をいくつか見てみましょう。

  • 攻撃者がハーフオープンのIKEセキュリティアソシエーション構造を作成できる大量のSA_INITメッセージ(IKE_AUTHメッセージなし)を送信します。この攻撃により、デバイスがリソースを使用し、メモリが不足します。

  • イニシエーターとレスポンダーにそれぞれ正しいSPI_iとSPI_rを使用して、大量のジャンクIKE_AUTHパケットを送信します。パケットを復号化しようとしているときにデバイスのメモリが不足します。

  • SA_INITパケットを継続的に送信します。暗号化されたパケットの鍵を生成しようとしている間、デバイスのメモリが不足します。

  • フルオープンのIKEセッション中に、1秒あたり大量のキー更新要求を送信します。

  • 個別のメッセージ識別子(ID)を持つ大量のメッセージを送信する。デバイスはすべての受信 IKE メッセージをキューに入れ、メモリが不足します。

IKE実装を保護する方法

IKEv1プロトコルとIKEv2プロトコルの両方について、DDoS攻撃を緩和および監視するための堅牢なインフラストラクチャを提供します。ファイアウォールがIPsec IKEサービスのikedプロセス( junos-ike パッケージ内)を実行すると、IKE実装に対する攻撃から保護できます。

注:

IKEv2 の DDoS 保護の詳細については、RFC 8019、 分散型サービス拒否攻撃からの Internet Key Exchange プロトコル バージョン 2 (IKEv2) 実装の保護」を参照してください。ファイアウォールがikedプロセスを使用してIPsec VPNサービスを実行する場合、IKEv1にも同様の保護が提供されます。RFCが提示するクライアントパズルメカニズムはサポートしていません。

DDoS攻撃からの保護

IKEセキュリティアソシエーションの作成プロセス中に、DDoS攻撃に対する複数の防御メカニズムを有効にできます。これらのメカニズムには、ハーフオープン IKE SA のレート制限と保持期間の設定、さらに鍵更新要求の受信為替レートの管理が含まれます。当社は、IKE SAに対するDDoS攻撃から確実に保護するために、以下の対策を提供しています。

  • ハーフオープン IKE SA の保護対策:

    • レスポンダは、一定時間、ハーフオープン IKE SA の設定を許可しません。この制限を設定すると、タイムアウト時間に達するまでレスポンダ側がSAを設定しないようにすることができます。詳細については、オプションtimeoutのセッション(セキュリティIKE)を参照してください。

    • レスポンダーで許容されるハーフオープン IKE SA の最大数に制限を設定できます。ハーフオープン IKE SA の総数が最大数に達すると、レスポンダーは IKEv1 と IKEv2 SA の両方の新規接続を拒否します。詳細については、セッション(セキュリティ IKE)のmax-countオプションを参照してください。

    • レスポンダは、ハーフオープン IKE SA のセッション数にしきい値を適用します。ハーフオープン IKE SA の総数がしきい値に達すると、次のようになります。

      • IKEv2 SAの場合、レスポンダーは新しい接続に対してCookieメカニズムを呼び出します。

      • IKEv1 SAの場合、レスポンダは新しい接続を拒否します。

      詳細については、セッション(IKEセキュリティ)のthresholds、send-cookie、reduce-timeoutオプションを参照してください。

    • レスポンダは重複するセッションを破棄できます。詳細については、セッション(セキュリティIKE)のdiscard-duplicateオプションを参照してください。

    • 認証失敗と開始失敗フェーズのバックオフタイムアウトを設定できます。詳細については、セッション(セキュリティ IKE) でオプション backoff-timeouts、 init-phase-failure 、 auth-phase-failureを参照してください。

  • フルオープンの IKE SA の場合:

    • 受信キー更新リクエストの最大レートを設定して、拡張されたシナリオでリクエストをスロットルすることができます。詳細については、セッション(セキュリティIKE)のincoming-exchange-max-ratesオプションを参照してください。

  • レスポンダは、ピアIKE IDに基づいて、ピアからの受信IKEセッションをブロックできます。詳細については、「ブロックリスト(セキュリティ IKE)」を参照してください。

  • 動的ゲートウェイの場合、オプション connections-limitを使用して、IKEゲートウェイ設定レベルで接続数の制限を設定できます。詳細については、「ゲートウェイ(セキュリティ IKE)」を参照してください。

これらのオプションの構成方法の詳細については、「 IKE DDoS攻撃に対する保護の構成」を参照してください。

以下はサポートされません。

  • kmdプロセスに基づくIPsec VPNサービスによるDDoS保護。

  • ハッシュ攻撃やURL証明書エンコーディング攻撃に対する保護 これらのエンコーディングタイプをサポートしていないため

DDoS攻撃を監視する方法

DDoS攻撃を監視するために、以下のメカニズムを提供しています。

  • show security ike security-associationsコマンドを使用して、成熟したセキュリティアソシエーションと成熟していないIKEセキュリティアソシエーションをすべてリストアップします。詳細については、show security ike security-associationsを参照してください。

  • show security ike statsコマンドを使用して、進行中、確立済み、期限切れの統計情報など、IPsec VPNトンネルのグローバルIKE統計情報を表示します。詳細については、show security ike statsを参照してください。

  • show security ike active-peerコマンドを使用して、リモートピアとの成功したIKEネゴシエーションの詳細を表示します。詳細については、show security ike active-peerを参照してください。

  • show security ike peers in-progressコマンドを使用すると、半開IKE SAを含む進行中のIKE SAの詳細が表示されます。詳細については、show security ike peersを参照してください。このコマンドを使用すると、ブロックされたピア、失敗したピア、バックオフされたピアの詳細も確認できます。

  • clear security ike peersコマンドを使用して、バックオフ、ブロック、障害、または進行中のIKEピアをクリアします。詳細については、「clear security ike peers」を参照してください。

  • それ以降の通信をブロックする必要があるピアとの既存のIKEセキュリティアソシエーションを削除するには、 clear security ike security-associations コマンドを使用します。詳細については、 clear security ike security-associationsを参照してください。

  • iked システムログ(syslog)メッセージ IKE_GATEWAY_PEER_BLOCKED、 IKE_GATEWAY_PEER_BACKOFF 、および IKE_GATEWAY_PEER_FAILED は、それぞれリモートピアとのブロック、バックオフ、および失敗した IKE ネゴシエーションの詳細を提供します。

  • セキュリティをさらに強化するために、Junos OS は、フィルタリング、セッション カウント、レート制限などのパケットベースのシステム攻撃から保護するサービスをユーザーに提供します。詳細については、[edit security screen ids-option screen-name]階層レベルのshow firewallコマンドとids-optionステートメントを参照してください。

IKE DDoS攻撃に対する保護を設定する

IKEプロトコルに対するDDoS攻撃に対する保護を設定する方法については、このセクションを参照してください。

前提条件

IKE DDoS攻撃に対する保護を設定する前に、以下の前提条件を満たしていることを確認してください。

  • ikedプロセスを使用してIPsec VPNサービスを実行する junos-ike パッケージをサポートするファイアウォール。

  • ローカルエンドポイント(レスポンダー)として機能するファイアウォールは、リモートIKEピア(イニシエーター)に到達可能です。

  • IKEブロックリストを関連付けることができるIKEポリシー。

IKE DDoS攻撃に対する保護の設定には、以下のアクションが含まれます。

  • 受信するハーフオープンIKE SAを管理します。

  • 受信するフルオープン IKE SA を管理します。

  • 複数のブロッキング方法を設定して、さまざまなピアから受信するIKEセッションをブロックし、ブロックリストの1つをIKEピアに関連付けます。

これらのアクションを設定するには、以下のタスクを参照してください。

ハーフオープンIKE SAのIKEセッションを設定する

概要

上記の前提条件をすべて満たしていることを確認します。

このセクションでは、ハーフオープンIKE SAのタイムアウト、最大カウント、およびしきい値を設定する方法について説明します。設定変更は新しいセッションに適用されますが、既存のセッションは、以前に明示的に設定されていない場合、引き続きデフォルト値を使用します。[edit security ike session half-open] 階層レベルでのこれらの設定の範囲は、ピア レベルではなくグローバル レベルで適用されます。

設定

  • オプション timeout seconds を使用してレスポンダのライフタイムパラメーターを設定するには、次の手順に従います。

    この期間中、レスポンダはタイムアウト時間に達するまで、ハーフオープンのIKE SAの設定を許可しません。イニシエーターは、レスポンダーの設定に関係なく、60秒のタイムアウト時間を維持し続けることができます。

  • オプション max-count value を使用してレスポンダの最大カウントパラメーターを設定するには:

    このオプションは、レスポンダーのハーフオープンIKEセッションの最大数を設定します。指定しない場合、デフォルト値は300です。 max-count 設定では、すべてのしきい値を無効にします。このような場合は、それらを適用するためのしきい値を明示的に設定する必要があります。

  • レスポンダーのセッション数が制限に達したときに threshold オプションを使用して、さまざまなタイプのアクションを指定します。

    • 次のオプションを使用して、Cookieアクションを適用するハーフオープンIKEセッションの最小数を設定するには send-cookie count:

      これは、応答側がリモート ピアに対し、初期応答でピアに返送された Cookie を使用してセッション開始を再試行するよう要求するしきい値制限を指定します。ここでは、ハーフオープンIKEセッションカウントの制限が500に達すると、ikedプロセスは新しいIKEセッションにCookieメカニズムを採用します。

    • 次のオプションを使用して、タイムアウトの短縮アクションを強制するハーフオープンIKEセッションの最小数を設定するには reduced-timeout count timeout seconds:

      これは、ikedプロセスが新しいハーフオープンIKE SAのライフタイムを短縮する制限を指定します。ハーフオープンレスポンダーIKEセッションカウントがしきい値を下回ると、ハーフオープンレスポンダーIKEセッションはデフォルトのタイムアウト値を再度使用します。

  • イニシエーターに応答を送り返さずに、重複するハーフオープンIKEセッションを破棄するためにオプション discard-duplicate を設定するには:

    ネゴシエーションの進行中にIKE SAがない、同じピアから別のイニシエーターCookieを使用して来た重複するセッション開始リクエスト(SA_INIT)の場合、レスポンダはパケットを破棄します。

  • backoff-timeoutsオプションを使用して、バックオフタイムアウトを設定できます。

    これにより、セッション開始に失敗した場合にリモートピアがバックオフする時間が与えられ、その間に同じピアが新しいセッションを開始できなくなります。バックオフタイムアウト後、ピアは新しいセッションを開始できます。セッションの開始は、初期化フェーズと認証フェーズの2つのフェーズで失敗することがあります。

    • オプション backoff-timeouts auth-phase-failure value を使用して、IKE_AUTH フェーズ中に障害が発生した場合のバックオフ タイムアウトを設定するには、次の手順に従います。

      auth-phase-failureを設定すると、ターゲットブロックリストルールのアクションとしてバックオフを設定していなくても、ブロックリストに登録されたリモートピアはバックオフします。バックオフのタイムアウトは、auth-phase-failureに設定されたタイムアウトです。この例では、デバイスは 150 秒後に新しいセッションを開始します。特定のルールのこのバックオフタイムアウトを上書きするにはrulebackoff、[edit security ike blocklists blocklist1 rule rule-name then backoff timeout-value] hierarchy level.

    • オプション backoff-timeouts init-phase-failure value を使用して、SA_INIT フェーズ中に障害が発生した場合のバックオフ タイムアウトを設定するには、次の手順に従います。

      この例では、デバイスは 160 秒後に新しいセッションを開始します。

フルオープンの IKE SA 用の IKE セッションの設定

概要

上記の前提条件をすべて満たしていることを確認します。

このセクションでは、[edit security ike session full-open] 階層レベルでオプション incoming-exchange-max-rates を使用して、フル オープン IKE SA に対してさまざまな受信リクエスト レートを設定する方法について説明します。

設定

incoming-exchange-max-ratesオプションを設定して、IKE SAの確立後にリモートピアによって開始されたさまざまな交換の最大レートを設定します。IKE鍵更新、IPsec鍵更新、キープアライブ(デッドピア検出とも呼ばれる)の3種類の為替レートを設定できます。

  • 次のオプションを使用して、受信ピアが開始IKEキー更新の最大レートを設定するには、次の incoming-exchange-max-rates ike-rekey value手順に従います。

    このオプションは、IKE SAがすでに存在する既存のピアとのピア単位でのIKEvIKE鍵更新に適用できます。

  • 次のオプションを使用して、受信ピアが開始したIPsec SAのキー更新の最大レートを設定するにはincoming-exchange-max-rates ipsec-rekey value:

    この制限は、トンネルごとに適用されます。

  • 次のオプションを使用して、受信ピア開始キープアライブの最大レートを設定するにはincoming-exchange-max-rates keepalive value:

    この制限は、ピアごとに適用されます。

IKEセッションブロックリストを設定する

概要

上記の前提条件をすべて満たしていることを確認します。

ピアIKE IDに基づいてピアから受信IKEセッションをブロックするには、1つ以上のブロックリストを設定する必要があります。各ブロックリストには、1つ以上のルールが含まれています。各ルールには一致条件とアクションがあります。

ブロックリストを設定するときは、以下の基準を考慮してください。

  • ブロックリストルールは、ネゴシエート中の新しいIKE SAに適用され、既存のIKE SAには影響しません。ピア認証段階で、デバイスはブロックリストルールを適用します。

  • ルールの適用順序は、これらのルールがリストされる順序によって異なります。

  • ロール(イニシエーターまたはレスポンダー)、IDタイプ(IPv4またはIPv6アドレス、ホスト名、識別名、メールID、またはキーID)、およびIKE IDと一致する正規表現であるIDパターンに基づいて一致基準を設定します。

  • 各ルールをIDタイプで設定できます。これにより、同じブロックリスト内の異なるルールに対して異なるIKE IDを設定できます。

  • ピア接続を破棄または拒否するアクションを設定します。一致に基づいて、デバイスはアクションを適用します。オプションで、これらのアクションでバックオフタイマーを設定することもできます。

  • IKEゲートウェイに関連付けられたIKEポリシー内のブロックリストを参照してください。

  • 各 IKE ゲートウェイは、1 種類のリモート IKE ID タイプのみをサポートします。ブロックリストをゲートウェイにアタッチし、異なるIKE IDを含むルールで設定した場合、ゲートウェイは、IKE IDタイプがIKEゲートウェイ用に設定されたものと同じIKE IDタイプを持つIKEルールのみを適用して照合します。

  • IKEゲートウェイに接続されたブロックリストを使用したトンネル設定レートメトリックは、ブロックリストで設定されたルールの数に基づいています。

このセクションでは、ブロックリストを設定し、ブロックリストをIKEポリシーに関連付ける方法について説明します。

設定

  • 複数のルールを含むブロックリストを作成するには:

    • ブロックリストを作成します。

    • 1つ以上のルールを作成します。

    このようなブロックリストとそのルールを複数作成できます。

  • 一致基準を設定し、アクションを指定するには:

    • ブロックリストblocklist1内のrule1の一致基準を設定します。

      IKE ID または部分的な IKE ID のグループを使用してブロックリストを設定するには、サフィックスまたはプレフィックスを付けた id-pattern value を使用します。例えば、hr.example.com、finance.example.com、admin.example.com に一致させる必要がある場合に、値*.example.com を使用できます。ルール rule1で、デバイスはパターン peer.*\.example\.netに一致するホスト名を探します。ここでは、peer.example.net、peer.1.example.net、peer.uplink.example.net が一致する可能性のあるものをいくつか紹介します。ルール rule2で、デバイスはパターン hr.example.comに一致するメールアドレスを探します。同様に、異なる id-type や id-patternに基づいて、他のルールに別の一致基準を設定することもできます。これらのパターンは、標準の正規表現を使用します。

    • 一致するアクションを指定します。

  • ブロックリストをIKEピアに関連付けるには:

    • IKEポリシーike_policy1でブロックリストblocklist1を設定します。

関連項目

例:ピア証明書チェーン検証用のデバイスの設定

この例では、IKEネゴシエーション中にピアデバイスを検証するために使用される証明書チェーンにデバイスを設定する方法を示しています。

要件

開始する前に、ローカル証明書のリクエストを送信する際に認証機関(CA)のアドレスと必要な情報(チャレンジパスワードなど)を取得します。

概要

この例では、証明書チェーン用にローカルデバイスを設定し、CA証明書とローカル証明書を登録し、登録された証明書の有効性を確認し、ピアデバイスの失効ステータスを確認する方法を示しています。

トポロジー

この例では、 図 9 に示すように、Host-A の設定と操作コマンドを示しています。ホストAには動的CAプロファイルが自動的に作成され、ホストAはSales-CAからCRLをダウンロードして、ホストBの証明書の失効ステータスを確認できます。

図9:証明書チェーンの例Certificate Chain Example

この例では、ホスト A のフェーズ 1 およびフェーズ 2 ネゴシエーションの IPsec VPN 設定を示しています。フェーズ1とフェーズ2のオプションが正常にネゴシエートされ、セキュリティアソシエーション(SA)が確立されるように、ピアデバイス(Host-B)を適切に設定する必要があります。VPN 用のピアデバイスの構成例については、 サイト間 VPN 用のリモート IKE ID の設定 を参照してください。

設定

証明書チェーン用にデバイスを設定するには:

CAプロファイルの設定

CLIクイックコンフィグレーション

この例をすばやく設定するには、以下のコマンドをコピーしてテキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、コマンドを [edit] 階層レベルでCLIにコピー アンド ペーストして、設定モードから commit を入力します。

ステップバイステップの手順

次の例では、設定階層のさまざまなレベルに移動する必要があります。その方法の詳細については、『CLIユーザーガイド』の「構成モードでのCLIエディターの使用」を参照してください。

CAプロファイルを設定するには:

  1. Root-CA の CA プロファイルを作成します。

  2. Eng-CAのCAプロファイルを作成します。

  3. Dev-CAのCAプロファイルを作成します。

結果

設定モードから、 show security pki コマンドを入力して設定を確認します。出力に意図した設定が表示されない場合は、この例の設定手順を繰り返して修正します。

デバイスの設定が完了したら、設定モードから commit を入力します。

証明書の登録

ステップバイステップの手順

証明書を登録するには:

  1. CA証明書を登録します。

    プロンプトで yes と入力して、CA証明書を読み込みます。

  2. CA証明書がデバイスに登録されていることを確認します。

  3. 登録されたCA証明書の有効性を確認します。

  4. キーペアを生成します。

  5. ローカル証明書を登録します。

  6. ローカル証明書がデバイスに登録されていることを確認します。

  7. 登録されたローカル証明書の有効性を確認します。

  8. 設定済みのCAプロファイルのCRLダウンロードを確認します。

IPsec VPNオプションの設定

CLIクイックコンフィグレーション

この例をすばやく設定するには、以下のコマンドをコピーしてテキスト ファイルに貼り付け、改行を削除し、ネットワーク設定に一致させる必要がある詳細情報を変更し、コマンドを [edit] 階層レベルでCLIにコピー アンド ペーストして、設定モードから commit を入力します。

ステップバイステップの手順

次の例では、設定階層のさまざまなレベルに移動する必要があります。その方法の詳細については、『CLIユーザーガイド』の「構成モードでのCLIエディターの使用」を参照してください。

IPsec VPNオプションを設定するには:

  1. フェーズ1のオプションを設定します。

  2. フェーズ2のオプションを設定します。

結果

設定モードから、 show security ike および show security ipsec コマンドを入力して設定を確認します。出力に意図した設定が表示されない場合は、この例の設定手順を繰り返して修正します。

デバイスの設定が完了したら、設定モードから commit を入力します。

検証

ピアデバイス間のIKEネゴシエーション中に証明書の検証に成功すると、IKEとIPsecセキュリティアソシエーション(SA)の両方が確立されます。

証明書が有効であれば、IKE SAは稼働しています。証明書が失効した場合、ピアデバイスで失効チェックが設定されている場合にのみ、IKE SAがDOWNでIPSEC SAが形成されます

IKEフェーズ1ステータスの確認

目的

IKEフェーズ1ステータスを確認します。

アクション

動作モードから show security ike security-associations コマンドを入力します。

IPsecフェーズ2ステータスの確認

目的

IPsecフェーズ2のステータスを確認します。

アクション

動作モードから show security ipsec security-associations コマンドを入力します。

失効した証明書の IKE および IPsec SA の障害

失効した証明書の確認

問題点

ピアデバイス間のIKEネゴシエーション中に証明書の検証に失敗した場合は、ピアの証明書が失効していないことを確認してください。動的CAプロファイルにより、ローカルデバイスはピアのCAからCRLをダウンロードし、ピアの証明書の失効ステータスを確認できます。動的CAプロファイルを有効にするには、親CAプロファイルで revocation-check crl オプションを設定する必要があります。

ソリューション

ピアの証明書の失効ステータスを確認するには:

  1. 動作モードから show security pki crl コマンドを入力して、ピアデバイスのCRLを表示する動的CAプロファイルを特定します。

    CAプロファイル dynamic-001 がホストA上で自動的に作成されるため、ホストAはホストBのCA(Sales-CA)からCRLをダウンロードし、ピアの証明書の失効ステータスを確認できます。

  2. 動作モードから show security pki crl ca-profile dynamic-001 detail コマンドを入力して、動的CAプロファイルのCRL情報を表示します。

    開始

    ホストBの証明書(シリアル番号10647084)が失効しました。

関連項目

IKEv2フラグメント化

メッセージのフラグメント化

RFC 7383「 プロトコルバージョン2(IKEv2)メッセージフラグメント化Internet Key Exchange」で説明されているように、IKEv2メッセージフラグメント化により、IPフラグメントがブロックされ、ピアがIPsecセキュリティアソシエーション(SA)を確立できないような環境でもIKEv2を動作させることができます。IKEv2フラグメント化は、大きなIKEv2メッセージを小さなメッセージのセットに分割し、IPレベルでフラグメント化が発生しないようにします。フラグメント化は、元のメッセージが暗号化および認証される前に行われるため、各フラグメントは個別に暗号化および認証されます。受信側でフラグメントが収集、検証、復号化され、元のメッセージにマージされます。

IKEv2フラグメント化が発生するためには、両方のVPNピアが、IKE_SA_INIT交換にIKEV2_FRAGMENTATION_SUPPORTED通知ペイロードを含めることで、フラグメント化サポートを示す 必要があります 。両方のピアがフラグメント化のサポートを示している場合、IKEv2 フラグメント化が使用されるかどうかは、メッセージ交換の開始側が判断します。

ファイアウォールでは、IKEv2メッセージごとに最大32個のフラグメントを使用できます。送受信されるIKEv2メッセージフラグメントの数が32を超えると、フラグメントがドロップされ、トンネルは確立されません。個々のメッセージフラグメントの再送信はサポートされていません

設定

ファイアウォールでは、IPv4 および IPv6 メッセージに対して IKEv2 フラグメント化がデフォルトで有効になっています。IKEv2フラグメント化を無効にするには、[edit security ike gateway gateway-name fragmentation]階層レベルでdisableステートメントを使用します。また、sizeステートメントを使用して、メッセージがフラグメント化されるパケットのサイズを設定することもできます。パケットサイズは500〜1300バイトの範囲です。sizeが設定されていない場合、デフォルトのパケットサイズは、IPv4トラフィックで576バイト、IPv6トラフィックで1280バイトです。設定されたパケットサイズよりも大きいIKEv2パケットはフラグメント化されます。

IKEv2のフラグメント化を無効または有効にするか、パケットのフラグメントサイズを変更すると、IKEゲートウェイでホストされているVPNトンネルがダウンし、IKEおよびIPsec SAが再ネゴシエートされます。

注意事項

IKEv2フラグメント化では、以下の機能はサポートされていません。

  • パス MTU 検出。

  • SNMP。

関連項目

ローカル証明書を使用した IKE ポリシー

このトピックではIKEネゴシエーション中に認証にローカル証明書を使用するIKEポリシーについて説明します。

IKEのローカル証明書

Internet Key Exchange(IKE)は、証明書ベースの認証をサポートし、VPNピア間の信頼を安全に確立します。この認証方法では、両方のピアがデジタル証明書を使用して、IKEネゴシエーション中に互いのIDを検証します。

IKE認証フェーズでは、リモートピア(イニシエーター)が証明書要求ペイロードをローカルデバイス(レスポンダー)に送信します。これに応じて、ローカルデバイスはローカル証明書を含む証明書ペイロードを送信します。イニシエーターは、受信した証明書を使用して、証明書チェーンを検証し、発行する認証機関(CA)との信頼関係を確認することで、レスポンダーのIDを検証します。この検証により、レスポンダが IKE ネゴシエーションに参加する権限を持っていることを確認できます。

ローカル証明書の選択基準

ローカル証明書は、応答側が IKE ネゴシエーション中にイニシエーターに提示して ID を証明する証明書です。VPN ピアは、信頼する CA を示すために、証明書要求に CA 識別子を含めます。iked プロセスでは、最初の 8 つの識別子のみが考慮され、追加の識別子は無視されます。ローカルデバイスは、ピアの証明書要求ペイロードに含まれるCA識別子を調べ、以下の表に示す基準に基づいてローカル証明書を選択します。

表2:IKEのローカル証明書選択基準
IKEバージョン 証明書の選択基準
IKEv2 証明書要求ペイロードで指定されたCAハッシュに基づいてローカル証明書を選択します。
IKEv1 証明書要求ペイロードで指定されたCAサブジェクト識別名(DN)に基づいてローカル証明書を選択します。
IKEフォールバック動作 一致するものが見つからない場合、ローカル証明書リストに読み込まれた最初の証明書を選択します。

複数のローカル証明書

デバイスは、単一または複数のローカル証明書をサポートするかどうかに基づいてローカル証明書を選択して管理します。

デバイスが単一のローカル証明書のみをサポートする場合:

  • 新しいローカル証明書設定はそれぞれ、既存の証明書に置き換わります。

  • ゲートウェイは、複数のリモートピアにサービスを提供する場合でも、単一の証明書を使用します。一部のピアは、ゲートウェイ証明書の検証に必要な CA 証明書を持っていない場合があります。これは、ゲートウェイがピアの要求に応答して一致するローカル証明書を提示しない可能性があるためです。

デバイスがikedプロセスで複数のローカル証明書をサポートしている場合:

  • IKEポリシーで複数のローカル証明書を設定できます。

  • 設定された各ローカル証明書は、既存のリストに置き換えるのではなく、追加されます。証明書は、有効期限が切れるか、明示的に削除されるまで、引き続き使用できます。

  • デバイスは、リストされた順序でローカル証明書を評価します。デバイスは、信頼できるルート CA に構築されたチェーンがピア CA 識別子の 1 つと一致する最初の証明書を選択します。設定された証明書が証明書要求の CA 識別子に一致しない場合、iked プロセスは、信頼できるルート CA にチェーンを構築できるローカル証明書を選択します。このプロセスでは、証明書を順次評価し、有効なチェーンを持つ最初の証明書を選択してピアに送信します。

証明書の選択におけるIKE IDの役割

  • ローカル IKE ID は、IKE ID タイプが [edit security ike gateway name remote-identity distinguished-name] 階層レベルの DN である場合を除き、証明書の選択IKE影響しません。

    • IKE ID が DN の場合、IKE は PKI ルックアップを実行して、リストされた順序を評価せずに DN に一致する証明書を取得します。
    • 取得後、IKEは将来使用するために証明書をキャッシュします。

ローカル IKE ID が選択したローカル証明書と一致しない場合、ピアデバイスで IKE ハンドシェイクが失敗する可能性があります。

IKEでのローカル証明書のキャッシュ

ローカル証明書を選択すると、IKEは証明書をキャッシュして、将来のPKIルックアップを最小限に抑えます。IKEにキャッシュされたら:

  • iked プロセスは、受信する CA 識別子と一致する場合にのみ、後続の接続にキャッシュされた証明書を使用します。

  • キャッシュされた証明書が受信した CA 識別子と一致しない場合、iked プロセスは新しい証明書を選択し、構成されたローカル証明書リストから証明書チェーンを再構築します。

  • 証明書の順序は、証明書の選択には影響しません。

  • 証明書の順序を変更しても(たとえば、最初の証明書を別の位置に移動する)、新しいPKIルックアップがトリガーされたり、既存のIPsec接続が削除されたりすることはありません。

  • IKEは、必要な選択基準を満たす限り、キャッシュされた証明書を使用し続けます。

  • ローカル証明書がデバイスから削除されると、対応するキャッシュ証明書もクリアされます。

  • ikedプロセスを再起動すると、証明書キャッシュがクリアされます。

ローカル証明書の追加または削除

  • 証明書を追加しても、既存のSA(セキュリティアソシエーション)は削除されません。

  • 証明書リストから証明書が削除されると、対応するIKEポリシーを使用するすべてのIKE SAが削除されます。

  • PKIからローカル証明書またはCA証明書を削除しても、IKEでコミットエラーが発生したり、既存のIPsec接続が削除されたりすることはありません。

複数のローカル証明書で IKE ポリシーを設定する

複数のローカル証明書を設定するには、以下の手順を実行します。

  1. CAプロファイルを設定し、CA証明書を読み込みます。 認証機関を参照してください。

  2. デバイスに既存のローカル証明書を読み込むか、以前にCA証明書が読み込まれたCAからローカルCA証明書を登録します。 「デジタル証明書」を参照してください。

    IKEポリシー内の各ローカル証明書について、この手順を繰り返します。

  3. ローカル証明書を IKE ポリシーに関連付けます。以下のコマンドのいずれかを使用します。

    または

IKEポリシー、IKEプロポーザル、およびIKEゲートウェイを設定し、その後にIPsecポリシーとエンドツーエンドIPsec VPNトンネル確立用のプロポーザルを設定します。

IKEポリシーで構成された証明書リストからどのローカル証明書が選択されているかを確認するには、IKEトレースログを確認します。ログには、証明書サブジェクトDNが表示されます。

関連項目

信頼できるCAを使用したIKEポリシー

この例では、信頼できる CA サーバーをピアの IKE ポリシーにバインドする方法を示します。

開始する前に、ピアの IKE ポリシーに関連付けるすべての信頼できる CA のリストを用意しておく必要があります。

IKEポリシーは、単一の信頼できるCAプロファイルまたは信頼できるCAグループに関連付けることができます。セキュアな接続を確立するために、IKEゲートウェイは、証明書を検証する間、IKEポリシーを使用して、設定されたCAグループ(caプロファイル)に自身を制限します。信頼できる CA または信頼できる CA グループ以外のソースから発行された証明書は検証されません。IKEポリシーから証明書検証リクエストがある場合、IKEポリシーに関連付けられたCAプロファイルが証明書を検証します。IKEポリシーがどのCAにも関連付けられていない場合、デフォルトでは、設定されたCAプロファイルのいずれかによって証明書が検証されます。

この例では、 root-ca という名前のCAプロファイルが作成され、そのプロファイルに root-ca-identity が関連付けられています。

信頼できるCAグループに追加したいCAプロファイルは最大20個まで設定できます。信頼できるCAグループで20を超えるCAプロファイルを設定した場合、設定をコミットできません。

  1. CAプロファイルを作成し、CA識別子をプロファイルに関連付けます。
  2. IKEプロポーザルとIKEプロポーザルの認証方法を定義します。
  3. Diffie-Hellman グループ、認証アルゴリズム、IKE プロポーザルの暗号化アルゴリズムを定義します。
  4. IKEポリシーを設定し、ポリシーをIKEプロポーザルに関連付けます。
  5. IKEポリシーのローカル証明書識別子を設定します。
  6. IKEポリシーに使用するCAを定義します。

デバイスに設定されているCAプロファイルと信頼できるCAグループを表示するには、 show security pki コマンドを実行します。

show security ikeコマンドは、ike_policyという名前のIKEポリシーの下にCAプロファイルグループと、IKEポリシーに関連付けられた証明書を表示します。

関連項目

信頼できるCAグループを使用したIKEポリシー

証明書ベースの認証に信頼できるCAグループを使用するようにIKEポリシーを設定する方法については、このトピックをお読みください。

IKEの信頼できるCAグループの概要

信頼できる認証機関(CA)グループは、1つ以上のCAプロファイルをバンドルし、IKEネゴシエーション中にピア証明書を検証するための単一のトラストアンカーとして機能します。デバイスには、複数のCA証明書を含めることができます。設定されたCA証明書のサブセットである信頼できるCAグループを使用するようにIKEを設定できます。IKEv2またはIKEv1の証明書ベースの認証中に、デバイスはピアの証明書チェーンがルートまでであることを確認します。IKEポリシーが信頼できるCAグループを使用する場合、デバイスはグループに含まれるすべてのCAプロファイルに対してピアの証明書を検証します。

信頼された CA グループは、複数の CA を使用する環境や、ある CA から別の CA に移行する場合の証明書管理を簡素化します。CAグループはいつでも更新して、CAプロファイルを追加または削除できます。

VPNピアが接続を開始すると、デバイスはIKEポリシーで設定された信頼できるCAグループを使用してピアの証明書を検証します。

  • 証明書が信頼できるグループの CA によって署名されている場合、認証は成功し、接続が許可されます。

  • 証明書が信頼できるグループ内の CA によって署名されていない場合、認証は失敗し、IPsec トンネルは確立されません。

したがって、信頼できるCAグループにより、デバイスは承認されたCAから発行された証明書のみを受け入れるようになり、セキュアなVPN認証を維持しながら証明書管理を簡素化できます。

信頼できるCAグループでIKEポリシーを設定する

信頼できるCAグループでIKEポリシーを設定する前に、以下を確認してください。

  • 信頼したいすべてのCAのリストがあります。

  • IKEポリシーは、証明書ベースの認証を使用します。

  • デバイス上でPKIとIKE設定を構成するためのアクセス権があります。

信頼できるCAグループでIKEポリシーを構成および検証するには:

  1. CAプロファイルを作成し、証明書をロードします。各 CA プロファイルは 1 つの CA を表します。 CAプロファイルの設定を参照してください。

    各CAプロファイルは、ピア証明書を検証できる信頼できるCAを表しています。

    CA証明書を対応するCAプロファイルにロードします。ロードされた各CA証明書により、デバイスはそのCAから発行されたピア証明書を検証できます。

  2. 信頼できる CA グループを作成します。CAプロファイルを信頼できるCAグループにグループ化します。信頼できる CA グループ内の CA プロファイルの順序は、証明書の検証には影響しません。 信頼できる CA グループの設定を参照してください。

    デバイスは、このグループを使用して、IKE 認証中にピア証明書を検証します。

  3. 証明書ベースの認証を使用するようにIKEポリシーを設定し、信頼できるCAグループをポリシーに関連付けます。

  4. 信頼できる CA グループが正しく設定されていることを確認します。

    信頼できる CA グループが IKE ポリシーに関連付けられていることを確認します。

設定が完了したら、次の手順に従います。

  • デバイスは、証明書を使用してVPNピアを認証します。

  • デバイスは、信頼された CA グループ内の任意の CA によって発行された証明書を信頼します。

  • ピア証明書が CA グループによって検証されている場合、受信 VPN 接続は成功します。

エンドツーエンドのIPsec VPNトンネルを確立するには、残りの設定を完了します。IKEポリシー、IKEプロポーザル、IKEゲートウェイを設定し、その後にIPsecポリシーとIPsecプロポーザルを設定します。

IKEでの確立トンネルレスポンダーのみの設定

このトピックでは、Internet Key Exchange(IKE)で establish-tunnels responder-onlyを設定する方法を説明します。リモートピアからトンネルを開始し、すべてのトンネルを介してトラフィックを送信します。IKEがアクティブになるタイミングを指定します。

ファイアウォールでは、establish-tunnelsオプションは、[edit security ipsec vpn vpn-name]階層レベルのresponder-only値とresponder-only-no-rekey値をサポートします。

これらのオプションは、サイト間VPNでのみサポートされます。これらのオプションは、自動VPNではサポートされていません。

responder-onlyオプションとresponder-only-no-rekeyオプションでは、デバイスからのVPNトンネルは確立されないため、VPNトンネルはリモートピアから開始されます。responder-onlyを設定すると、確立されたトンネルは、設定されたIKEとIPsecのライフタイム値に基づいて、IKEとIPsecの両方のキーを再生成します。responder-only-no-rekeyを設定すると、確立されたトンネルデバイスからのキー更新は行われず、リモートピアに依存してキー更新が開始されます。リモートピアがキー更新を開始しない場合、ハードライフタイムの有効期限が切れた後にトンネルの破棄が行われます。

始める前に:

  • AutoKey IKE IPsec トンネルの確立方法を理解します。 「IPsecの概要」を参照してください。

IKEでestablish-トンネルレスポンダーのみを設定するには:

  1. 確立トンネルレスポンダーのみの設定
  2. show security ipsec vpn IPSEC_VPNコマンドを入力して、設定を確認します。
  3. establish-トンネル responder-only-no-rekey の設定
  4. show security ipsec vpn IPSEC_VPNコマンドを入力して、設定を確認します。

    複数のVPNオブジェクトがある場合は、レスポンダー専用モードが優先されます。ゲートウェイ内のいずれかのVPNがレスポンダー専用モードで設定されている場合、ゲートウェイ内のすべてのVPNもレスポンダー専用モードで設定する必要があります。

プラットフォーム固有の IKEv2レスポンダーのみ の動作

機能エクスプローラーを使用して、特定の機能のプラットフォームとリリースのサポートを確認します。

お使いのプラットフォームに固有の動作を確認するには、以下の表を使用して下さい。

表3:プラットフォーム固有の動作
プラットフォーム 違い
SRXシリーズ

  • IKEv2 responder-only およびオプションで値 responder-only-no-rekey をサポートする establish-tunnels SRX5000シリーズの場合:

    • ファイアウォールは、SPC3カードのみのオプションをサポートします。

    • ファイアウォールは、ikedプロセスでIPsec VPNサービス用に junos-ike パッケージがインストールされている場合のオプションをサポートします。

関連ドキュメント

変更履歴テーブル

サポートされる機能は、使用しているプラットフォームとリリースによって決まります。 機能エクスプローラー を使用して、機能がお使いのプラットフォームでサポートされているかどうかを確認します。

リリース
説明
24.4R1
IKEv2プロトコルでの署名認証のサポートは、Junos OSリリース24.4R1で導入されています。
23.4R1
DDoS攻撃からのIKE保護のサポートが、Junos OSリリース23.4R1で導入されました。
20.3R1
ikedプロセスを実行するSRX5000シリーズおよびvSRX仮想ファイアウォールでのIKEv2設定ペイロードに対するサポートが、Junos OSリリース20.3R1に追加されました。
20.1R1
SRX5000シリーズおよびikedプロセスを実行するvSRX仮想ファイアウォールのポイントツーポイントインターフェイスによるIKEv2設定ペイロード機能のサポートが、Junos OSリリース20.1R1で導入されました。
20.1R1
IKEゲートウェイのIKEv2構成ペイロード要求における共通パスワード構成のサポートが、Junos OSリリース20.1R1で導入されました。
19.1R1
[edit security ipsec vpn vpn-name]階層レベルのestablish-tunnelsオプションのresponder-only値とresponder-only-no-rekey値のサポートは、Junos OSリリース19.1R1のSRX5000シリーズで導入されました。
18.1R1
Junos OSリリース18.1R1以降、設定されたIKEピアの検証は、指定されたCAサーバーまたはCAサーバーのグループで実行できます。