Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

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

IPsecトンネルの動的エンドポイントの設定

IPsecトンネルは、 動的ピア セキュリティゲートウェイを使用して確立することもできますが、トンネルのリモートエンドには静的に割り当てられたIPアドレスがありません。リモートアドレスは不明であり、リモートホストが再起動するたびにアドレスプールから取得される可能性があるため、トンネルの確立は、事前共有グローバルキーまたはリモート識別値を受け入れるデジタル証明書のいずれかで main モードを使用することに依存しIKE。ポリシーベーストンネルとリンクタイプトンネルの両方がサポートされています。

  • ポリシーベースのトンネルは、共有モードを使用しました。

  • リンクタイプトンネルまたはルーテッドトンネルは、専用モードを使用します。各トンネルは、動的ピアに設定されたインターフェイスのプールからサービスインターフェイスを割り当てます。ルーティングプロトコルは、これらのサービスインターフェイス上で実行するように設定し、このシナリオでリンクとして使用される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 です。

注:

このルールは設定しません。これは、鍵管理プロセス(KMD)によって作成されます。

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

静的ルールのルール一致に失敗した後に、動的ルールが一致します。

デッドピア検出(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に追加されます。

注:

逆ルート挿入は、動的ピアへのトンネルに対してのみ行われます。これらのルートは、ネクストホップスタイルのサービスセットに対してのみ追加されます。

IKEアクセスプロファイルの設定

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

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

注:

動的ピアの場合、Junos OSは、認証の事前共有鍵方式またはローカルデジタル証明書を使用するIKEアクセスプロファイルのいずれかで、IKEメインモードをサポートします。

  • 事前共有鍵モードでは、IPアドレスを使用してトンネルピアを識別し、事前共有鍵情報を取得します。 client* (ワイルドカード)は、このプロファイル内の設定が、このプロファイルにアクセスするサービスセット内で終端するすべての動的ピアに対して有効であることを意味します。

  • デジタル証明書モードでは、IKEポリシーによって許可されるリモート識別値が定義されます。

以下のステートメントが 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] 階層レベルで定義します。ポリシーが設定されていない場合、動的ピアによって提案されたポリシーはすべて受け入れられます。

サービスセットでのIKEアクセスプロファイルの参照

設定を完了するには、[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ステートメントによって識別されるプールの一部になります。

注:

一度に指定できるインターフェイス識別子は1つだけです。 ipsec-interface-id ステートメントまたは l2tp-interface-id ステートメントを含めることができますが、両方を含めることはできません。

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

デフォルトのIKEおよびIPsecプロポーザル

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

注:

RSA証明書は、動的エンドポイント設定ではサポートされていません。

表1:動的ネゴシエーションのためのデフォルトのIKEおよびIPsecプロポーザル

ステートメント名

価値

暗黙的な IKE プロポーザル

authentication-method

pre-shared keys

dh-group

group1group2group5group14

authentication-algorithm

sha1md5sha-256

encryption-algorithm

3des-cbcdes-cbcaes-128aes-192aes-256

lifetime-seconds

3600

暗黙的なIPsecプロポーザル

protocol

espahbundle

authentication-algorithm

hmac-sha1-96, hmac-md5-96

encryption-algorithm

3des-cbcdes-cbcaes-128aes-192aes-256

lifetime-seconds

28,800秒(8時間)

サービスインターフェイス間でのエンドポイントIPsecトンネルの分散

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

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

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

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

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

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

    • 同じ local-gateway IPアドレスを持っていること。

    • 同じ ike-access-profile 名を持つこと。

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

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

    • すべてのインターフェイスに dedicated を使用、またはすべてのインターフェイスに shared を使用。

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

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

    • 同じVRF内にあるインターフェイス下でのみ。

例:動的に割り当てられたポリシーベースのトンネルの設定

この例では、動的に割り当てられたポリシーベースのトンネルを設定する方法を示し、以下のセクションで構成されています。

要件

この例では、以下のハードウェアおよびソフトウェアコンポーネントを使用しています。

  • M Series、MXシリーズ、またはT Seriesルーター3台。

  • Junos OSリリース9.4以降。

概要とトポロジー

動的エンドポイントのIPsecポリシーは、動的ピアセキュリティゲートウェイ間のIPsecネゴシエーション中に使用されるセキュリティパラメーター(IPsecプロポーザル)の組み合わせを定義します。このとき、トンネルのリモートエンドには静的に割り当てられたIPアドレスがありません。

ポリシーベースのVPNは、トンネルとして機能するポリシーで参照される特定のVPNトンネルを持つ設定です。ポリシーベースのVPNは、リモートVPNデバイスがジュニパー以外のデバイスであり、VPNを介してリモートサイトの1つのサブネットまたは1つのネットワークにのみアクセスする必要がある場合に使用します。

この例では、 図 1 に示すように、IPsec 動的エンドポイント トンネリング トポロジーについて説明します。

動的に割り当てられたトンネルを設定する前に、以下を確認してください。

  • セキュリティゲートウェイSG-1に接続されたローカルネットワークN-1。出口ポイントには、静的および動的ピアエンドポイントを終端するためのジュニパーネットワークスルーターが必要です。SG-1のトンネル終端アドレスは10.1.1.1で、ローカルネットワークアドレスは172.16.1.0/24です。

  • ISPプールからアドレスを取得し、RFC準拠のIKEを実行する2つのリモートピアルーター。リモートネットワークN-2は、アドレス172.16.2.0/24を持ち、トンネル終端アドレス10.2.2.2を使用してセキュリティゲートウェイSG-2に接続されています。リモートネットワークN-3は、アドレス172.16.3.0/24を持ち、トンネル終端アドレス10.3.3.3でセキュリティゲートウェイSG-3に接続されています。

トポロジー

図1:IPsec動的エンドポイントトンネリングトポロジー IPsec Dynamic Endpoint Tunneling Topology

設定

動的に割り当てられたポリシーベースのトンネルを設定するには、以下のタスクを実行します。

注:

この例に示されているインターフェイスタイプは、あくまでも目安です。例えば、ge-の代わりにso-インターフェイスを使用し、ms-の代わりにsp-を使用できます。

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

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

インターフェイスの設定

アクセスプロファイルの設定

サービスセットの設定

IPsecプロパティの設定

ルーティングインスタンスの設定

ネクストホップSG1サービスセットの設定

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

次の例では、設定階層のさまざまなレベルに移動する必要があります。

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

  2. アクセスプロファイルを設定します。

  3. サービスセットを設定します。

  4. IPsecプロパティを設定します。

  5. ルーティングインスタンスを設定します。

結果

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

検証

ポリシーベースのトンネルを持つネクストホップSG1サービスセットが作成されていることの確認

目的

ポリシーベースのトンネルを持つネクストホップSG1サービスセットが作成されていることを確認します。

アクション

動作モードから、 show route コマンドを入力します。

動作モードから、show services ipsec-vpn ipsec security-associations detailを入力します

意味

show services ipsec-vpn ipsec security-associations detailコマンドの出力には、設定したプロパティが表示されます。

変更履歴テーブル

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

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