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アドレスをリクエストに割り当てます。

  • 追加オプション noneauthentication-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サーバーを認証する必要があります。これがないと、トンネル確立は成功しません。

図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プロファイルを示しています。

複数の証明書タイプを設定して IKE および IPsec SA を確立する

複数の認定書タイプを構成および管理する方法について説明します。

この例では、複数の証明書タイプを設定してIKEおよびIPsec SAを確立する方法を示しています。

Junos OSリリース22.4R1以降、set security ike proposal ike_proposal_name authentication-method certificatesコマンドを使用してプロポーザルで認証-methodがcertificatesとして設定されている場合IKE、開始側と応答側で使用される証明書の種類に関係なくトンネルを確立できます。

show security pki local-certificate certificate-id certificate-name detail コマンドを使用して登録された証明書を表示できます。

request security pki local-certificate verify certificate-id certificate-nameコマンドを使用して、登録された証明書を確認できます。

要件

始める前に:

  • デバイスに証明書が登録されていることを確認します。 証明書の登録を参照してください。

    request security pki local-certificate certificate-id certificate-name detailコマンドを使用して、デバイスに登録されている証明書を確認できます。

  • パッケージIKEインストールされていることを確認し、インストールされているIKEパッケージを確認するには、 show version | match ike 操作コマンドを使用します。

    デバイスにIKEパッケージがインストールされていない場合は、運用コマンドを使用してIKEパッケージをインストールできます。 request system software add optional://junos-ike.tgz詳細については、「 IPsec VPN機能セットの有効化」を参照してください。

概要

この例では、複数の証明書タイプを設定して、オンSRX_AとオンSRX_Bの間でIKEとIPsec SAを確立します。

この例では、SRX_AにRSA証明書を、SRX_BデバイスにECDSA証明書を登録しました。証明書のインストール方法の詳細については、「 証明書の登録」を参照してください。

表2:SRX_AおよびSRX_Bデバイスのトポロジー設定
デバイス名 使用されるインターフェイス IKEゲートウェイアドレス IKEゲートウェイのローカルIPアドレス
SRX_A ge-0/0/0 192.168.1.2 192.168.1.1
SRX_B ge-0/0/0 192.168.1.1 192.168.1.2

トポロジー

図9は、複数の証明書タイプサポート設定のトポロジーを示しています。

図9:複数の証明書タイプがサポートされる設定例 Network topology diagram with Juniper SRX_A and SRX_B. SRX_A's ge-0/0/1 connects left, and ge-0/0/0 links to SRX_B via green link. SRX_B's ge-0/0/0 connects to green link, and ge-0/0/1 connects right. Diagram ID is jn-000543.

設定

SRX_Aの設定

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

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

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

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

複数の証明書タイプを設定してIKEおよびIPsec SAを確立するには:

  1. show security pki local-certificate certificate-id certificate-name detailコマンドを使用して、デバイスに登録されている証明書を表示します。

    デバイスに証明書が登録されていない場合は、デバイスに証明書をインストールします。詳細については、「 証明書の登録」を参照してください。

  2. インターフェイスを設定します。

  3. セキュリティゾーンとセキュリティポリシーを設定します。

  4. IKEプロポーザルを設定します。

  5. IKEポリシーを設定します。

  6. IKEゲートウェイを設定します。

  7. IPsecプロポーザルを設定します。

  8. IPsecポリシーを設定します。

  9. IPsec VPNを設定します。

結果

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

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

SRX_Bの設定

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

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

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

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

複数の証明書タイプを設定してIKEおよびIPsec SAを確立するには:

  1. request security pki local-certificate certificate-id certificate-name detailコマンドを使用して、デバイスに登録されている証明書を表示します。

    デバイスに証明書が登録されていない場合は、デバイスに証明書をインストールします。詳細については、「 証明書の登録」を参照してください。

  2. インターフェイスを設定します。

  3. セキュリティゾーンとセキュリティポリシーを設定します。

  4. IKEプロポーザルを設定します。

  5. IKEポリシーを設定します。

  6. IKEゲートウェイを設定します。

  7. IPsecプロポーザルを設定します。

  8. IPsecポリシーを設定します。

  9. IPsec VPNを設定します。

結果

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

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

検証

設定が正常に機能していることを確認します。

SRX_Aを確認する

ここに示されている出力例はSRX-Aです。

目的

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

アクション

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

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

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

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

動作モードから、 show security pki local-certificate certificate-id r0_rsa_cr detail コマンドを入力します。

動作モードから、 show security pki ca-certificate ca-profile Root-CA detail コマンドを入力します。

SRX_Bを確認する

ここに示されている出力例はSRX-Bです。

目的

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

アクション

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

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

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

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

動作モードから、 show security pki local-certificate certificate-id r1_crt_ecdsa384 detail コマンドを入力します。

s

動作モードから、 show security pki ca-certificate ca-profile Root-CA detail コマンドを入力します。

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セッション中に、毎秒大量のキー更新要求を送信します。

  • 個別のメッセージ識別子(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セキュリティ)thresholdssend-cookiereduce-timeoutオプションを参照してください。

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

    • 認証失敗と開始失敗フェーズのバックオフタイムアウトを設定できます。詳細については、セッション(セキュリティ IKE) で オプション backoff-timeoutsinit-phase-failureauth-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_BLOCKEDIKE_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-typeid-patternに基づいて、他のルールに別の一致基準を設定することもできます。これらのパターンは、標準の正規表現を使用します。

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

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

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

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

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

要件

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

概要

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

トポロジー

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

図10:証明書チェーンの例 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。

信頼できる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ポリシーに関連付けられた証明書を表示します。

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サーバーのグループで実行できます。