Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IPsec VPN インターネット鍵交換IKE(IKE)

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

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 パケットフェーズ1および2の IKE パケット

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

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

  • 0004 — プロペイロードプロポーザルにはフェーズ 1 またはフェーズ 2 のプロポーザルを使用できます。

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

  • 0010—KE(鍵交換)ペイロード DH 公開値などの鍵交換を実行するために必要な情報が含まれている。

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

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

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

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

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

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

  • 0100—HASH(ハッシュ)ハッシュペイロード、特定のハッシュ関数のダイジェスト出力を含む。

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

  • 0400—Nonce(Nx)にはペイロード情報が含まれている場合があります。

  • 0800 — 通知ペイロード。

  • 1000— ISAKMP Delete ペイロード。

  • 2000—VID(ベンダー ID)のペイロード、フェーズ 1 のネゴシエーションの任意の場所に含まれます。Junos OS は NAT-T のサポートをマークするためにそれを使用します。

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

図 2: 汎用 ISAKMP ペイロードヘッダー汎用 ISAKMP ペイロードヘッダー

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

図 3: 汎用 ISAKMP ペイロードを使用した ISAKMP ヘッダー汎用 ISAKMP ペイロードを使用した ISAKMP ヘッダー

IPsec パケット処理

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

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

図 4: IPsec パケット—トンネル モードの ESPIPsec パケット—トンネル モードの ESP

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

図 5: 外部 IP ヘッダー (IP2) と ESP ヘッダー外部 IP ヘッダー (IP2) と ESP ヘッダー

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

図 6: 内部 IP ヘッダー (IP1) と TCP ヘッダー内部 IP ヘッダー (IP1) と TCP ヘッダー

新しいIKEの概要Junos OS

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

IKEv2 には、以下のサポートが含まれています。

  • ルートベース Vpn。

  • サイトツーサイト Vpn

  • デッドピア検知

  • シャーシクラスターです。

  • 事前共有鍵認証

  • 証明書ベースの認証。

  • 子の Sa。IKEv1 内の IKEv2 の子 SA は、フェーズ 2 SA として知られています。IKEv2 では、基盤となる IKE SA がなければ子 SA を存在させることはできません。

  • AutoVPN.

  • 動的エンドポイント VPN。

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

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

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

  • ポリシーベースの VPN。

  • VPN 監視

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

IKEv2 の設定(Junos OS

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

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

IKE のバージョンが、 show security ike security-associationsshow security ipsec security-associations CLI の運用コマンドの出力に表示されます。

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

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

設定ペイロードは、レスポンインターネット鍵交換サーからイニシエーターへのプロビジョニング情報を伝達するために提供される IKEv2(サービス バージョン 2)オプションです。IKEv2 構成ペイロードは、ルートベースの Vpn でのみサポートされています。

RFC 5996、インターネット鍵交換 プロトコル バージョン 2(IKEv2)では、レスポンダーからイニシエーターに戻ることができる 15 の異なる設定属性を定義しています。 表 1 では、これらのデバイスでサポートされる IKEv2 設定属性SRX シリーズ説明します。

表 1: IKEv2 構成属性

属性タイプ

金額

説明

期間

INTERNAL_IP4_ADDRESS

1

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

0または4オクテット

INTERNAL_IP4_NETMASK

2

内部ネットワークの net分値を指定します。リクエストおよび応答メッセージには、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 サーバーなどの指定された送信元から情報を取得する必要があります。また、プロビジョニング情報は、RADIUS サーバーを通じて DHCP サーバーから返されることもあります。RADIUS サーバーでは、ユーザー情報に認証パスワードを含めないようにする必要があります。RADIUS サーバープロファイルは、[ aaa access-profile profile-nameedit security ike gateway gateway-name] 階層レベルの設定を使用して、IKE ゲートウェイにバインドされます。

SPC3 および vSRX 20.3R1 がJunos OSされたデバイスの SRX5000 シリーズ で、リリース SRX5000 シリーズ から、IKEv2 設定ペイロードを以下に改善しました。

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

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

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

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

    サーバー サポート アカウンティングRADIUSメッセージの開始または停止を確認します。また、これらのメッセージを追跡SRX シリーズデバイスとRADIUS両方に適切な設定が含されている必要があります。

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

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

最初の Junos OS リリース 20.1R1、IKEv2 の設定ペイロード要求に対して共通パスワードを設定して、サービス ゲートウェイIKEできます。管理者は、1~128 文字の範囲で共通パスワードを定義できます。このパスワードは、IKEv2 設定ペイロードを使用してリモート IPsec ピアに代わって IP アドレスを要求している SRX シリーズ デバイスが、SRX シリーズ デバイスと RADIUS サーバーの間で使用されます。RADIUSサーバーは、設定ペイロード要求用に任意の IP 情報をSRX シリーズする前に、認証情報を一致します。[ ] 階層レベルの設定ステートメント config-payload-password configured-password を使用して、共通 edit security ike gateway gateway-name aaa access-profile access-profile-name パスワードを設定できます。

SRX シリーズ と RADIUS サーバーの両方で同じパスワードが設定されている必要があります。RADIUS サーバーは、認証プロトコルとして PAP(パスワード認証プロトコル)を使用するように設定する必要があります。この設定がない場合、トンネルの確立は成功しない。

図 7 は、IKEv2 設定設定の一般的なワークフローをペイロード。

図 7: 一般的な IKEv2 ペイロードワークフロー一般的な IKEv2 ペイロードワークフロー

IKEv2 構成ペイロード機能は、ポイントツーマルチポイントのセキュアトンネル (st0) インターフェイスでのみサポートされています。ポイントからマルチポイントへのインターフェイスには番号が付いている必要があります。また、構成ペイロードに含まれるアドレスは、関連付けられているポイントツーマルチポイントインターフェイスのサブネットワークの範囲内になければなりません。

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

IKEv2 構成ペイロードを使用すると、SRX シリーズデバイスなどの IKE レスポンダーから、携帯ネットワーク内の LTE pico cell ベースステーションなどの複数のイニシエーターにプロビジョニング情報を伝搬することができます。Pico のセルは、標準設定で出荷されているため、SRX シリーズデバイスに接続できますが、pico のセルプロビジョニング情報は、保護対象のネットワーク内の1台以上のプロビジョニングサーバーに格納されます。Pico のセルは、プロビジョニングサーバーとの安全な接続を確立した後、完全なプロビジョニング情報を受け取ります。

Pico のセルをブートストラップしてプロビジョニングするために必要なワークフローは、以下の4つのステップで構成されています。

  1. 初期アドレス取得 — picoセルは工場から出荷される次の情報を使用して出荷されます。

    • SRX シリーズデバイスへのセキュアゲートウェイトンネルの設定

    • 製造者から発行されたデジタル証明書

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

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

  2. Picoセルプロビジョニング:割り当てられたOAMトラフィックアドレスを使用して、picoセルは、保護されたネットワーク内のサーバーから、通常はオペレータ証明書、ライセンス、ソフトウェア、設定情報など、そのプロビジョニング情報を要求します。

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

  4. サービス プロビジョニング:pico セルがサービスに入った場合、FQDN を持つ識別名(DN)とサブジェクト代替名の値を含む 1 つの証明書を使用して、SRX シリーズ デバイスのセキュア ゲートウェイに 2 つのトンネルを構築します。1つは OAM トラフィック用で、もう一方は第3世代のパートナーシッププロジェクト (3GPP) データトラフィック用です。

IKE提案

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

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

IKEポリシー

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

まず、1 つ以上のプロポーザルIKE設定します。プロポーザルを他のプロポーザルとIKEします

IKEポリシーを設定するには、 ステートメントを含め、 [ ] 階層レベルでポリシー名 policyedit 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 キー更新のたびに行われます。再認証の頻度が3に設定されている場合は、3回の IKE キー更新のたびに再認証が行われます。

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

サポートされる機能

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

  • IKEv2 イニシエーターまたはレスポンダー

  • デッドピア検知 (DPD)

  • 仮想ルーターと secure tunnel (st0) インターフェイス (バーチャルルーター)

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

  • SRX5400、SRX5600、SRX5800 デバイスに対応したアクティブ/アクティブおよびアクティブ/パッシブモードのシャーシクラスター

  • SRX5400、SRX5600、SRX5800 の各デバイスでのインサービスソフトウェアアップグレード (ISSU)

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

おける

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

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

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

  • 再認証の頻度に基づいて、新しい IKE SA を開始するには、開始元の IKE SA のいずれかのイニシエーターまたはレスポンダーを使用します。拡張認証プロトコル (EAP) 認証と構成ペイロードでは、元の IKE SA と同じパーティによって IKE SA が開始される必要があるため、EAP 認証や構成ペイロードでは再認証がサポートされません。

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

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

証明書ベースの認証は、IKE ネゴシエーション中に SRX シリーズデバイスでサポートされる認証方法です。大規模なネットワークでは、複数の証明機関 (Ca) がエンドエンティティ (EE) 証明書をそれぞれのエンドデバイスに発行できます。個々の拠点、部門、組織に別々の Ca を配置するのが一般的です。

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

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

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

Junos OS リリース18.1 から開始して、指定された CA サーバーまたは CA サーバーグループで、構成済みの IKE ピアの検証を実行できます。証明書チェーンを使用している場合、ルート CA は、IKE ポリシーに設定された信頼される CA グループまたは CA サーバーと一致する必要があります。

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

図 8: 証明書ベースの認証用のマルチレベル階層証明書ベースの認証用のマルチレベル階層

各エンドデバイスは、その階層に CA の証明書とともにロードされる必要があります。Host A は、ルート CA、Eng CA、および Dev CA の証明書を持っている必要があります。販売 CA と Qa CA の証明書は必要ありません。ホスト B には、ルート CA と販売 CA の証明書が必要です。証明書はデバイスに手動でロードするか、SCEP (Simple Certificate Enrollment Process) を使用して登録することができます。

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

次の出力は、ホスト B に構成されている CA プロファイルを示しています。

例:ピア証明書チェーンの検証用にデバイスを構成しています

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

要件

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

概要

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

Topology

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

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

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

構成

証明書チェーン用のデバイスを構成するには、次のようにします。

CA プロファイルの設定

CLI クイック構成

この例を簡単に構成するには、以下のコマンドをコピーしてテキストファイルに貼り付け、改行を削除し、ネットワーク設定に一致する必要がある詳細を変更し、コマンドを[edit]階層レベルで CLI にコピー & ペーストしてから設定commitモードから開始します。

順を追った手順

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

CA プロファイルを設定するには、次のようにします。

  1. ルート CA 用の CA プロファイルを作成します。

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

  3. 開発 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 ikeshow security ipsecコマンドを入力して設定を確認します。出力に意図した構成が表示されない場合は、この例の設定手順を繰り返して修正してください。

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

検証

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

証明書が有効な場合、IKE SA が起動します。IKE SA がダウンし、証明書が失効した場合に 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 から THE をダウンロードし、ピアの証明書の失効ステータスを確認できます。動的 CA プロファイルを有効にするrevocation-check crlには、このオプションを親 CA プロファイルで設定する必要があります。

ソリューション

ピアの証明書の失効ステータスを確認するには、次の方法に示します。

  1. 動作モードから コマンドを入力CAピア デバイスのSLを表示する動的クライアント show security pki crl プロファイルを識別します。

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

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

    入力

    ホスト B の証明書(シリアル番号 10647084)が取り消されました。

IKEv2 フラグメント化

メッセージの断片化

RFC 7383、インターネット鍵交換 プロトコル バージョン 2(IKEv2)メッセージ フラグメント化で説明されている IKEv2 メッセージフラグメント化により、IP フラグメントがブロックされ、ピアが IPsec セキュリティ アソシエーション(SA)を確立できない環境で IKEv2 を動作できます。IKEv2 の断片化によって、大規模な IKEv2 メッセージが、IP レベルで断片化が発生しないように、小規模なメールセットに分割されます。断片化は、元のメッセージが暗号化されて認証される前に行われるため、各フラグメントが個別に暗号化されて認証されます。受信者側では、フラグメントが収集、検証、暗号化解除された後、元のメッセージに反映します。

IKEv2 の断片化を発生させるには、両方の VPN ピアで、IKE_SA_INIT exchange に IKEV2_FRAGMENTATION_SUPPORTED 通知ペイロードを含めることで、フラグメンテーションのサポートを指定する必要があります。両方のピアがフラグメンテーションのサポートを示している場合は、メッセージ交換のイニシエーターによって、IKEv2 の断片化が使用されているかどうかを確認します。

SRX シリーズデバイスでは、1つの IKEv2 メッセージで最大32フラグメントが許可されます。送信または受信する IKEv2 メッセージフラグメント数が32を超えると、フラグメントが削除されてトンネルが確立しません。個々のメッセージフラグメントの再送信はサポートされていません

構成

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

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

以下の機能は IKEv2 の断片化でサポートされていません。

  • パス MTU 検出。

  • SNMP.

IKEなポリシーと信頼性の高いポリシー CA

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

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

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

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

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

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

デバイスに構成されている CA プロファイルと信頼される CA グループをshow security pki表示するには、command を実行します。

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

IKE での確立トンネルのレスポンダーの構成

このトピックでは、確立されたトンネルレスポンダーを構成する方法についてインターネット鍵交換 (IKE) で説明します。リモートピアからトンネルを開始し、すべてのトンネルを通してトラフィックを送信します。IKE をいつアクティブにするかを指定します。

デバイスの Junos OS リリース 19.1R1から、SRX5000 シリーズ の確立オプションは、 階層レベルの下の および の responder-onlyresponder-only-no-rekey[edit security ipsec vpn vpn-name] 値をサポートしています。

と オプションは、SPC3 カードがSRX5000 シリーズデバイスのデバイス の responder-onlyresponder-only-no-rekey 設定で、インストールされている junos-ike-package 場合にのみサポートされます。これらのオプションは、サイト間 VPN でのみサポートされています。これらのオプションは、Auto VPN ではサポートされていません。

と オプションはデバイスから VPN トンネルを確立しないので、VPN トンネルはリモート responder-onlyresponder-only-no-rekey ピアから開始されます。設定すると、確立されたトンネルは、設定されたインターフェイスIKE IPsecライフタイム値に基づいて、IKEと responder-only IPsecの両方を再キーします。設定時に、確立されたトンネルはデバイスから再入力されません。リモート ピアに依存して再キー responder-only-no-rekey を開始します。リモートピアがキー更新を開始しなかった場合は、ハードライフが満了した後でトンネルが破棄されます。

開始する前に:

  • IKE IPsec トンネルの自動キーを確立する方法について説明します。詳細 IPsec の概要 を読む

IKE で確立トンネルのレスポンダーのみを構成するには、次のようにします。

  1. 確立-トンネルのレスポンダーのみを構成
  2. show security ipsec vpn IPSEC_VPNコマンドを入力して設定を確認してください。
  3. 確立-トンネルの応答側のみ-キー更新の構成
  4. show security ipsec vpn IPSEC_VPNコマンドを入力して設定を確認してください。

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

リリース履歴テーブル
リリース
説明
18.1R1
Junos OS リリース18.1 から開始して、指定された CA サーバーまたは CA サーバーグループで、構成済みの IKE ピアの検証を実行できます。