動的なエンドポイントを持つIPsecトンネル

リモート(動的ピア)が、ローカル(ジュニパーネットワークス)ルーターとのネゴシエーションを開始します。ローカルルーターは、デフォルトのIKEおよびIPsecポリシーを使用して、リモートピアから送信されたプロポーザルと照合し、セキュリティアソシエーション(SA)値をネゴシエートします。暗黙的なプロポーザルには、ローカル ルーターがすべての動的ピアに期待する、サポートされているすべてのトランスフォームのリストが含まれています。

事前共有鍵認証を使用する場合、事前共有鍵はサービス セットに対してグローバルです。ピアの事前共有キーを探す場合、ローカルルーターはピアの送信元アドレスを、そのサービスセット内で明示的に設定された事前共有キーと照合します。一致するものが見つからない場合、ローカルルーターは認証にグローバル事前共有鍵を使用します。

認証のフェーズ 2 では、ピアから送信された保護されたホストおよびネットワークの プロキシ ID を、構成済みのプロキシ ID のリストと照合します。受け入れられたプロキシ ID は、トラフィックを暗号化するための動的ルールを作成するために使用されます。IKE アクセス プロファイルに allowed-proxy-pair ステートメントを含めることで、プロキシ ID を設定できます。一致するエントリーがない場合、ネゴシエーションは拒否されます。

allowed-proxy-pairステートメントを設定しない場合、デフォルト値ANY(0.0.0.0/0)-ANYが適用され、ローカルルーターはピアから送信されたプロキシIDを受け入れます。IPv4 アドレスと IPv6 アドレスの両方が受け入れられますが、すべての IPv6 アドレスを手動で設定する必要があります。

フェーズ2のネゴシエーションが正常に完了すると、ルーターは動的ルールを構築し、受け入れたプロキシIDを使用してルーティングテーブルにリバースルートを挿入します。

動的ピアとのネゴシエーションが成功すると、キー管理プロセス(kmd)は、受け入れられたフェーズ2プロキシの動的ルールを作成し、ローカルASまたはマルチサービスPICに適用します。送信元アドレスと宛先アドレスは、承認されたプロキシによって指定されます。このルールは、フェーズ 2 プロキシ ID のエンド ホストの 1 つに送信されるトラフィックを暗号化するために使用されます。

動的ルールには、動的トンネルに割り当てられたインターフェイス名である ipsec-inside-interface 値が含まれます。 source-address と destination-address の値は、プロキシ ID から受け入れられます。 match-direction 値は、ネクストホップスタイルのサービス セットでは input です。

スタティック トンネルのルール ルックアップは、ダイナミック ルールの存在による影響を受けません。設定された順序で実行されます。サービス セットのパケットを受信すると、スタティック ルールが常に最初に一致します。

動的ルールは、静的ルールのルール一致に失敗した後に照合されます。

デッドピア検出(DPD)helloメッセージへの応答は、静的ピアと同様に動的ピアで行われます。動的ピアからの DPD hello メッセージの開始はサポートされていません。

静的ルートは、リモートトンネルのエンドポイントによって保護されているネットワークとホストのルートテーブルに自動的に挿入されます。これらの保護されたホストとネットワークは、リモート プロキシ ID と呼ばれます。

各ルートは、ピアから送信されたリモートプロキシネットワークとマスクに基づいて作成され、フェーズ1とフェーズ2のネゴシエーションが成功した後、関連するルートテーブルに挿入されます。

各スタティックリバースルートのルート優先度は1です。この値は、ルーティングプロトコルプロセス(rpd)によって追加される可能性のある類似ルートとの競合を避けるために必要です。

受け入れたリモート プロキシ アドレスがデフォルト(0.0.0.0/0)の場合、ルートは追加されません。この場合、IPsec トンネル上でルーティングプロトコルを実行してルートを学習し、このトンネル上で保護したいトラフィックの静的ルートを追加することができます。

ネクストホップスタイルのサービス セットの場合、リバース ルートには、 inside-service-interface ステートメントで指定されたロケーションを指すネクスト ホップが含まれます。

これらのルートを挿入するルート テーブルは、 inside-service-interface の場所がリストされている場所によって異なります。これらのインターフェイスがVPNルーティングおよび転送(VRF)インスタンスに存在する場合、ルートは対応するVRFテーブルに追加されます。それ以外の場合、ルートは inet.0に追加されます。

すべての動的ピアに対して、サービスセットごとに1つのトンネルプロファイルのみを設定できます。プロファイルで設定された事前共有キーは、そのサービス セットで終端するすべての動的ピアの IKE 認証に使用されます。または、 ike-policy ステートメントを含めて、特定の識別値またはワイルドカード( any-remote-id オプション)で定義したIKEポリシーを参照することもできます。IKEポリシーは、 [edit services ipsec-vpn ike] 階層レベルで設定します。

IKEトンネルプロファイルは、IKEネゴシエーションを完了するために必要なすべての情報を指定します。各プロトコルは、プロトコル固有の属性値ペアを設定するために、clientステートメント内に独自のステートメント階層を持ちますが、各プロファイルに対して許可されるクライアント設定は1つだけです。以下に、 [edit access] 階層レベルの設定を示します。アクセスプロファイルの詳細については、 ルーティングデバイス用Junos OS管理ライブラリを参照してください。

IKE プロファイルは、以下のステートメントで構成されます。

• allowed-proxy-pair- フェーズ2 IKEネゴシエーション中に、リモートピアは自身のネットワークアドレス(remote)とピアのネットワークアドレス(local)を提供します。複数の動的トンネルが同じメカニズムで認証されるため、このステートメントには可能な組み合わせのリストを含める必要があります。動的ピアが有効な組み合わせを提示しない場合、フェーズ2 IKEネゴシエーションは失敗します。

  デフォルトでは、値が設定されていない場合、 remote 0.0.0.0/0 local 0.0.0.0/0 が使用されます。この設定では、IPv4 と IPv6 の両方のアドレス形式がサポートされていますが、デフォルトの IPv6 アドレスはありません。偶数 0::0/0を指定する必要があります。

• pre-shared-key—IKE フェーズ 1 ネゴシエーション中に動的ピアを認証するために使用されるキー。この鍵は、帯域外のセキュア メカニズムを通じて両端で認識されます。値は、 hexadecimal 形式または ascii-text 形式で設定できます。これは必須の値です。

• ike-policy—許可された動的ピアに対応するリモート識別値を定義するポリシー。ワイルドカード値を含めることができます any-remote-id 動的エンドポイント構成でのみ使用できます。

• interface-id—インターフェイス識別子。セッションの論理サービス インターフェイス情報を取得するために使用される必須属性。

• ipsec-policy—セッションの IPsec ポリシー情報を定義する IPsec ポリシーの名前。IPsecポリシーは、 [edit services ipsec-vpn ipsec policy policy-name] 階層レベルで定義します。ポリシーが設定されていない場合、動的ピアから提案されたすべてのポリシーが受け入れられます。

設定を完了するには、[edit access]階層レベルで設定されたIKEアクセスプロファイルを参照する必要があります。これを行うには、[edit services service-set name ipsec-vpn-options]階層レベルでike-access-profileステートメントを含めます。

ike-access-profileステートメントは、[edit access]階層レベルでIKEアクセス用に設定したprofileステートメントと同じ名前を参照する必要があります。各サービス セットで参照できるアクセス プロファイルは 1 つだけです。このプロファイルは、動的ピアとのIKEおよびIPsecセキュリティアソシエーションのネゴシエートにのみ使用されます。

サービス セット内の inside-service-interface ステートメントで参照されるすべてのインターフェイスは、同じ VRF インスタンスに属している必要があります。

動的ピアのグループに対して、どの適応型サービス論理インターフェイスが動的IPsecネゴシエーションに参加するかを指定するインターフェイス識別子を設定できます。複数の論理インターフェイスに同じインターフェイス識別子を割り当てることで、この目的のためのインターフェイスのプールを作成できます。インターフェイス識別子を設定するには、[edit interfaces interface-name unit logical-unit-number dial-options]階層レベルでipsec-interface-idステートメントとdedicatedまたはsharedステートメントを含めます。

dial-options ステートメントでインターフェイス識別子を指定すると、この論理インターフェイスは ipsec-interface-id ステートメントで識別されるプールの一部になります。

sharedモードを設定すると、1つの論理インターフェイスを複数のトンネルで共有することができます。dedicatedステートメントは、論理インターフェイスが専用モードで使用されることを指定します。これは、IPsecリンクタイプトンネルを設定する場合に必要となります。ipsec-interface-id値を指定する場合は、dedicated ステートメントを含める必要があります。

ソフトウェアには、動的ピアから送信されたプロポーザルと一致するように、暗黙的なデフォルトのIKEおよびIPsecプロポーザルが含まれています。値は 表1に示されています。複数の値が表示されている場合は、最初の値がデフォルトです。

Junos OS リリース 16.2R1 以降、複数の MS-MIC 間または MS-MPC の複数のサービス PIC 間で、動的エンドポイントを持つ IPsec トンネルを配布できます。トンネル配信を設定するには、各サービスPICのマルチサービス(ms-)インターフェイスにネクストホップIPsecサービス セットを設定します。Junos OS リリース 17.1R1 以降では、各 AMS インターフェイスにネクストホップ IPsec サービス セットを設定することで、MS-MIC または MS-MPC の集約されたマルチサービス(AMS)インターフェイス間で、動的なエンドポイントを持つ IPsec トンネルを配信することもできます。

IPsecピアの設定を変更することなく、別のサービスセットを追加するだけで、後でサービスPICハードウェアをMXシリーズルーターに追加し、そのサービスPICをトンネルディストリビューションに含めることができます。

トンネル配信を設定するには、動的エンドポイントIPsecトンネルを設定する際に以下のステップを実行します。

• 動的エンドポイント IPsec トンネルで使用される各サービス インターフェイスまたは AMS インターフェイスに対して、ネクストホップ IPsec サービス セットを設定します( サービス セット内の IKE アクセス プロファイルの参照を参照を参照)。すべてのサービスセットは、次の条件を満たす必要があります。

  • マルチサービス(ms-)インターフェイスまたは AMS(ams-)インターフェイスのいずれかの、同じタイプのサービスインターフェイスを使用します。

  • outside-serviceステートメントに、他のサービスセット内のインターフェイスと同じVPNルーティングおよび転送(VRF)インスタンスにあるインターフェイスがあります。

  • 同じ local-gateway IP アドレスを使用します。

  • 同じ ike-access-profile 名を持ちます。

• インターフェイス識別子を設定する場合( インターフェイス識別子の設定を参照)、 ipsec-interface-id identifier を設定する必要があります。

  • サービス セットの inside-service-set ステートメントに表示されるインターフェイスのみ。

  • すべてのインターフェイスに dedicated 、すべてのインターフェイスに shared があります。

  • インターフェイスの共有ユニットが1つ以下。

  • service-domain inside で設定されたインターフェイスのみ。

  • 同じ VRF 内のインターフェイスのみ。