Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IPsec VPN の概要

VPN とは、パブリックネットワークを使用して2つ以上のリモートサイトを接続するプライベートネットワークです。Vpn は、ネットワーク間の専用接続を使用するのではなく、パブリックネットワークからルーティングされた仮想接続 (トンネリング) を使用します。IPsec VPN はプロトコルであり、VPN 接続の確立に使用される標準のセットから成ります。

IPsec VPN の概要

VPN は、リモートコンピューターがインターネットなどのパブリック WAN を介して安全に通信するための手段を提供します。

VPN 接続では、2つの Lan (サイト間 VPN) またはリモートのダイヤルアップユーザーと LAN をリンクすることができます。これら2つのポイント間でフローされるトラフィックは、パブリック WAN を構成するルーター、スイッチ、その他のネットワーク機器などの共有リソースを介して渡されます。WAN を通過しながら VPN 通信を保護するために、2つの参加者は IP セキュリティー (IPsec) トンネルを作成します。

トンネルという用語 は、 トンネル モードを示すではありません(「 トンネル モードでのパケット 処理 」を参照してください)。その代わりに IPsec 接続を参照しています。

IPsec は、IP パケットレイヤーでの通信を暗号で保護するための、関連するプロトコルのセットです。また、IPsec には、セキュリティアソシエーション (Sa) とキー配信の手動および自動ネゴシエーションのためのメソッドが用意されています。そのすべての属性は、解釈のドメイン (DOI) に集められています。IPsec DOI は、VPN トンネルのネゴシエーションを成功するために必要なすべてのセキュリティ パラメーターの定義を含むドキュメントです。基本的に、SA および IKE ネゴシエーションに必要なすべての属性が含まれます。詳細については、RFC 2407 および RFC 2408 を参照してください。

このトピックは、以下のセクションで構成されています。

セキュリティーアソシエーション

SA (セキュリティ関連) は、通信チャネルのセキュリティー強化に使用する方法とパラメーターに関して、VPN の参加者間の片方向契約です。完全な双方向通信には、各方向に1つずつ、少なくとも2つの Sa が必要です。SA を通じて、IPsec トンネルは以下のセキュリティ機能を提供できます。

  • プライバシ (暗号化を使用)

  • コンテンツの整合性 (データ認証を通じて)

  • 送信者の認証と(証明書を使用している場合)否認拒否(データ送信元認証を使用)

どのようなセキュリティ機能を採用するかは、ニーズによって異なります。IP パケットの送信元とコンテンツの整合性のみを認証する必要がある場合は、暗号化を適用せずにパケットを認証できます。一方、プライバシの維持のみに不安がある場合は、認証メカニズムを適用せずにパケットを暗号化することができます。必要に応じて、パケットを暗号化して認証することもできます。ほとんどのネットワークセキュリティー設計者は、VPN トラフィックを暗号化、認証、再生することを選択しています。

IPsec トンネルは、SPI(セキュリティ パラメーター インデックス)、宛先 IP アドレス、セキュリティ プロトコル(採用した認証ヘッダー [AH] または ESP(セキュリティのカプセル化ペイロード)を指定する、一方向 SA のペア(トンネルの各方向に 1 つの SA)で構成されています。SA は、通信のセキュリティを強化するために、以下のコンポーネントをまとめてグループ化します。

  • セキュリティーアルゴリズムとキー

  • プロトコルモード、トランスポートまたはトンネルのいずれかです。Junos OS デバイスでは、常にトンネルモードを使用します。(トンネルモードでのパケット処理を参照してください)。

  • キー管理方法 (手動キーまたは自動キー IKE) (をIPsec キー管理参照してください)

  • SA ライフタイム

インバウンドトラフィックの場合、Junos OS は次の3つの方法を使用して SA を検索します。

  • 宛先 IP アドレス。

  • セキュリティープロトコル (AH または ESP) (をIPsec セキュリティープロトコル参照してください)

  • セキュリティーパラメータインデックス (SPI) 値。

アウトバウンド VPN トラフィックでは、VPN トンネルに関連付けられた SA がポリシーによって呼び出されます。

IPsec キー管理

Vpn を正常に使用するには、鍵の配信と管理が不可欠です。Junos OS は、次の3種類のキー作成メカニズムにより、VPN トンネルを作成するための IPsec 技術をサポートしています。

  • 手動キー

  • 事前共有鍵または証明書を使用した自動キー IKE

フェーズ 1 およびフェーズ 2 プロポーザルの設定時に、鍵作成メカニズム(認証方法とも呼ばれる)を選択できます。参照IPsec トンネルネゴシエーションしてください。

このトピックは、以下のセクションで構成されています。

手動キー

手動キーを使用すると、トンネルの両方のエンドの管理者がすべてのセキュリティパラメーターを構成します。これは、キーの配信、保守、および追跡が難しくない、小規模で静的なネットワークに適した手法です。ただし、長距離間で手動キー設定を安全に配布すると、セキュリティーの問題が発生します。キーを対面するだけでなく、キーが転送中に侵害されていないことを完全に確認することはできません。また、キーの変更が必要になった場合でも、初めてそれを配布したときと同じようなセキュリティの問題が発生しています。

AutoKey IKE

多数のトンネルを作成して管理する必要がある場合は、すべての要素を手動で構成する必要がない方法を使用する必要があります。IPsec は、インターネット鍵交換 (IKE) プロトコルを使用して、キーとセキュリティアソシエーションの自動化された生成とネゴシエーションをサポートします。Junos OS は、AutoKey IKE として自動化されたトンネルネゴシエーションを意味し、事前共有鍵と証明書を使用した自動キー IKE を使用して、AutoKey IKE をサポートします。

  • 事前共有鍵IKEを使用する AutoKey IKE を事前共有鍵と一緒に使用して、IKE セッションの参加者を認証するには、事前に共有鍵を構成し、セキュアに交換する必要があります。この点を考慮すると、セキュアなキー配信の問題は、キーを手動で使用した場合と同じです。ただし、手動キーとは異なり、一度配布されると、自動キーは、IKE プロトコルを使用して、あらかじめ決められた間隔で自動的に変更されることがあります。頻繁に変更されるキーによってセキュリティが大幅に向上し、自動的な処理が行われるため、キー管理の責任が大幅に減少します。ただし、キーを変更すると、トラフィックのオーバーヘッドが増加します。そのため、多くの場合、キーを変更することで、データ転送の効率を低下させることができます。

    事前共有鍵は、暗号化と復号化の両方にとって重要です。どちらも、通信を開始する前に、どちらの参加者にすべきかを示しています。

  • AutoKey IKE 証明書の追加 — AutoKey IKE ネゴシエーション中に証明書を使用して参加者を認証する場合、サイドで公開鍵とプライベートの鍵ペアを生成し、証明書を取得します。 発行元認証機関(CA)が両者から信頼されている限り、参加者はピアの公開鍵を取得して、ピアの署名を検証できます。鍵と Sa を管理する必要はありません。IKE によって自動的に実行されます。

Diffie-hellman 交換

Diffie-hellman (DH) エクスチェンジを使用すると、参加者は共有シークレット値を生成できます。この手法の強度は、参加者は、通信を通して機密値を渡さずに、セキュリティ保護されていないメディアを介してシークレット値を作成できるということです。各グループの計算で使用される主な係数のサイズは、以下の表に示すように異なります。DH(Diffie Hellman)交換操作は、ソフトウェアまたはハードウェアで実行できます。これらの交換操作がハードウェアで実行される場合、QuickAssist Technology(QAT)暗号化を利用します。以下に、DH(異なる Diffie Hellman)グループをリストし、そのグループに対して実行される操作がハードウェア内かソフトウェア中かを 表 1 指定します。

表 1: DH(Diffie Hellman)グループとその交換操作の実行

Diffie-Hellman(DH)グループ

プライム モジュール サイズ

取引所での運用

DH グループ 1

768-bit

ハードウェア

DH グループ 2

102-bit

ハードウェア

DH グループ 5

1536-bit

ハードウェア

DH グループ 14

2048-bit

ハードウェア

DH グループ 15

3072-bit

ソフトウェア

DH グループ 16

4096-bit

ソフトウェア

DH グループ 19

256 ビット楕円曲線

ソフトウェア

DH グループ 20

384 ビット楕円曲線

ソフトウェア

DH グループ 21

521 ビット楕円曲線

ソフトウェア

DH グループ 24

256 ビット素数次サブグループを使用した 2048 ビット

ソフトウェア

最初のリリース Junos OS デバイス19.1R1、SRX シリーズ DH グループ 15、16、21 をサポートしています。

DH グループ1、2、5を使用することは推奨されません。

各 DH グループのモジュラスは異なるサイズであるため、参加者は同じグループを使用することに同意する必要があります。

IPsec セキュリティープロトコル

IPsec は2つのプロトコルを使用して、IP レイヤーでの通信をセキュリティで保護します。

  • AH(認証ヘッダー) — IP パケットの送信元を認証して内容の整合性を検証するセキュリティ プロトコル

  • ESP(セキュリティ ペイロードのカプセル化) — IP パケット全体を暗号化する(およびコンテンツを認証する)セキュリティ プロトコル

フェーズ 2 プロポーザルの設定中に、セキュリティ プロトコル(認証 および暗号化アルゴリズムとも呼ばれる)を選択できます。参照IPsec トンネルネゴシエーションしてください。

各 VPN トンネルには、サービスプロセッシングユニット (SPUs) と制御プレーンに、AH および ESP トンネルセッションがインストールされています。ネゴシエーションが完了すると、ネゴシエートしたプロトコルでトンネルセッションが更新されます。SRX5400、SRX5600、SRX5800 デバイスでは、アンカーをネゴシエートしたプロトコルでトンネルセッションが更新されます。しかし、非アンカーの SPUs ESP および AH トンネルセッションを維持しています。ESP および AH トンネルセッションは、 show security flow sessionおよびshow security flow cp-session運用モードコマンドの出力に表示されます。

このトピックは、以下のセクションで構成されています。

AH プロトコル

認証ヘッダー (AH) プロトコルは、パケットの内容と送信元の信頼性と整合性を検証する手段を提供します。パケットを認証するには、ハッシュメッセージ認証コード (HMAC) を介して計算された、秘密鍵と MD5 または SHA ハッシュ機能を使用します。

  • Message Digest 5(MD5)—任意の長さのメッセージと 16 バイトの鍵から128 ビット ハッシュ(デジタル シグネチャーまたはメッセージ ダイジェストとも呼ばれる)を生成するアルゴリズムです。 結果として得られるハッシュは、入力のフィンガープリントと同様に、コンテンツとソースの信頼性と整合性を検証するために使用されます。

  • Secure Hash Algorithm(SHA) — 任意の長さのメッセージと 20 バイトの鍵から 160 ビットのハッシュを生成するアルゴリズムです。一般に、大量のハッシュが生成されるため、MD5 よりも安全であると見なされています。この計算処理は ASIC で実行されるため、パフォーマンスコストは無視できません。

MD5 ハッシュアルゴリズムの詳細については、RFC 1321 および RFC 2403 を参照してください。SHA ハッシュアルゴリズムの詳細については、RFC 2404 を参照してください。HMAC の詳細については、RFC 2104 を参照してください。

ESP プロトコル

カプセル化セキュリティペイロード (ESP) プロトコルは、プライバシ (暗号化) と送信元の認証およびコンテンツの整合性 (認証) を保証する手段を提供します。トンネルモードの ESP は、IP パケット (ヘッダーとペイロード) 全体をカプセル化し、新しい IP ヘッダーをすぐに暗号化されたパケットに追加します。この新しい IP ヘッダーには、保護されたデータをネットワーク経由でルーティングするために必要な宛先アドレスが含まれています。(トンネルモードでのパケット処理を参照してください)。

ESP を使用すると、暗号化と認証、暗号化のみ、または認証のみが可能になります。暗号化には、以下の暗号化アルゴリズムのいずれかを選択できます。

  • DES(データ暗号化規格) — 56 ビット鍵を使用した暗号化ブロック アルゴリズムです。

  • トリプル DES(3DES)—168 ビット 鍵を使用して、元の DES アルゴリズムが 3 つのラウンドで適用される、DES のより強力なバージョンです。DES はパフォーマンスを大幅に向上させますが、多くの分類または機密性の高い材料振替では容認できないと見なされます。

  • AES(Advanced Encryption Standard)—他のデバイスとの高い相互運用性を提供する暗号化規格です。Junos OS では、128ビット、192ビット、256ビットの各キーを使用して AES をサポートしています。

認証には、MD5 または SHA アルゴリズムのいずれかを使用できます。

暗号化に NULL を選択することもできますが、IPsec がこのような状況下での攻撃に対して脆弱であることが実証されています。そのため、最大限のセキュリティを確保するために暗号化アルゴリズムを選択することをお勧めします。

IPsec トンネルネゴシエーション

キー IKE の自動 IPsec トンネルを確立するには、ネゴシエーションの2つのフェーズが必要です。

  • フェーズ 1 では、参加者が IPsec セキュリティー アソシエーション(SAS)をネゴシエートするためのセキュアなチャネルを確立します。

  • フェーズ 2 では、参加者は、ユーザー データの交換を暗号化して認証するために IPsec SA をネゴシエートします。

手動によるキー IPsec トンネルの場合、SA パラメーターはすべて事前に定義されているため、使用する Sa をネゴシエートする必要はありません。つまり、トンネルはすでに確立されています。この手動キートンネルを使用してトラフィックがポリシーに一致する場合、またはルートがトンネルに関連している場合、ジュニパーネットワークスデバイスは、判断したとおりにデータを暗号化して認証し、宛先ゲートウェイに転送します。

リモート IKE ゲートウェイアドレスには、任意の仮想ルーティング (VR) インスタンスを使用できます。VR は IKE フェーズ1およびフェーズ2ネゴシエーション中に決定されます。VR は、IKE の提案で設定する必要はありません。IKE ゲートウェイインターフェイスを1つの VR から別のものに移動すると、IKE ゲートウェイに対する既存の IKE フェーズ1およびフェーズ2ネゴシエーションが消去され、新しいフェーズ1およびフェーズ2ネゴシエーションが実行されるようになります。

  • SRX シリーズデバイスで VPN を有効にすると、仮想ルーター間で IP アドレスの重複がサポートされます。以下の制限があります。

    • IKE 外部インターフェイスアドレスは、他の仮想ルーターと重複することはできません。

    • 内部インターフェイスアドレスまたは信頼されています。

    • St0 のインターフェイスアドレスは、NHTB などのポイントツーマルチポイントトンネルでルートベースの VPN と重複することはできません。

    • St0 のインターフェースアドレスは、ルートベースの VPN でポイントツーポイントトンネルにオーバーラップできます。

  • VRs で構成される IPsec VPN トンネルのローカル IP アドレスとリモートゲートウェイ IP アドレスの組み合わせは、一意である必要があります。

  • ループバックインターフェイスが IKE ゲートウェイ外部インターフェイスとして使用されている場合、IKE ネゴシエーション用の物理インターフェイスは同じ VR にある必要があります。

SRX シリーズデバイス上の IPsec VPN トポロジ

Junos のオペレーティングシステム (OS) でサポートされている IPsec VPN トポロジの一部を以下に示します。

  • サイトツーサイトVPN :組織内の2つのサイトを接続して、そのサイト間のセキュアな通信を可能にします。

  • ハブアンドスポーク型VPN:企業ネットワーク内の支社と本社を接続します。このトポロジを使用して、ハブを経由してトラフィックを送信することで、スポーク同士を接続することもできます。

  • リモートアクセスVPN :自宅や出張中のユーザーが本社とそのリソースに接続できます。このトポロジーは、サイト間トンネル とも呼ばれます

ポリシーベースおよびルートベースの Vpn の比較

ポリシーベースとルートベースの Vpn の違いと、なぜそれが他よりも望ましい理由を理解することが重要です。

表 2は、ルートベースの Vpn とポリシーベースの Vpn の違いを示しています。

表 2: ルートベースの Vpn とポリシーベースの Vpn の違い

ルートベース Vpn

ポリシーベースの Vpn

ルートベースの Vpn では、ポリシーによって VPN トンネルが明確に参照されるわけではありません。

ポリシーベースの VPN トンネルを使用すると、トンネルはオブジェクトとして扱われ、送信元、宛先、アプリケーション、およびアクションとともに、VPN トラフィックを許可するトンネルポリシーを構成します。

ポリシーは宛先アドレスを参照します。

ポリシーベースの VPN 構成では、トンネルポリシーは名前によって VPN トンネルを具体的に参照しています。

作成するルートベースの VPN トンネル数は、ルートエントリ数またはデバイスがサポートする st0 インターフェイス数によって制限されます。いずれか小さい方の番号が使用されます。

作成できるポリシーベースの VPN トンネルの数は、そのデバイスがサポートするポリシーの数によって制限されます。

VPN トラフィックに対するきめ細かな制限を設定しながら、トンネルリソースを節約したい場合は、ルートベースの VPN トンネル構成を選択することをお勧めします。

ポリシーベースの VPN では、同じ VPN トンネルを参照する多数のトンネルポリシーを作成できますが、各トンネルポリシーペアがリモートピアとの間で個別の IPsec セキュリティーアソシエーション (SA) を作成します。各 SA は、個々の VPN トンネルとしてカウントされます。

Vpn にルートベースのアプローチを採用したことで、トラフィックの規制がその配信手段に結び付けられることはありません。数十のポリシーを設定して、2つのサイト間で1つの VPN トンネルを通過するトラフィックを規制し、1つの IPsec SA のみを稼働させることができます。また、ルートベースの VPN 構成では、アクションが拒否されている VPN トンネルを介して到達する宛先を参照するポリシーを作成できます。

ポリシーベースの VPN 構成では、アクションが許可される必要があり、トンネルが含まれている必要があります。

ルートベースの Vpn は、VPN トンネルを介した動的なルーティング情報の交換をサポートしています。VPN トンネルにバインドされた st0 インターフェイス上で、OSPF などの動的ルーティングプロトコルのインスタンスを有効にすることができます。

動的なルーティング情報の交換は、ポリシーベースの Vpn ではサポートされていません。

ハブアンドスポークトポロジーでは、ルートベースの構成が使用されます。

ポリシーベースの Vpn は、ハブアンドスポーク型トポロジーには使用できません。

ルートベースの Vpn では、ポリシーによって VPN トンネルが明確に参照されるわけではありません。

トンネルによって、動的なルーティングプロトコルを実行している大規模なネットワークを接続しない場合、トンネルを節約する必要がないか、またはさまざまなポリシーを定義しなくても、トンネリングを介してトラフィックをフィルター処理できます。ポリシーベースのトンネルを採用することをお勧めします。

ルートベースの Vpn は、リモートアクセス (ダイヤルアップ) VPN 構成をサポートしていません。

リモートアクセス (ダイヤルアップ) VPN 構成には、ポリシーベースの VPN トンネルが必要です。

ルートベースの Vpn は、一部のサードパーティーベンダーでは正常に動作しない場合があります。

サードパーティーが各リモートサブネットに個別の Sa を必要とする場合は、ポリシーベースの Vpn が必要になることがあります。

セキュリティデバイスがルートルックアップを行って、アドレスに到達するためにトラフィックを送信する必要があるインターフェイスを見つけると、特定の VPN トンネルにバインドst0されているセキュアトンネルインターフェイス () を介してルートを検出します。

ルートベースの VPN トンネルでは、トラフィックを配信する手段としてトンネルを検討し、そのトラフィックの配信を許可または拒否するための方法としてそのポリシーを検討できます。

ポリシーベースの VPN トンネルでは、トンネルをポリシーの構築の要素として考えることができます。

ルートベースの Vpn は、st0 インターフェイス用の NAT をサポートしています。

トンネルされたトラフィックに NAT が必要な場合は、ポリシーベースの Vpn を使用できません。

プロキシ ID は、ルートベースおよびポリシーベースの Vpn の両方でサポートされています。ルートベース トンネルでは、マルチプロキシ ID とも呼ばれる複数のトラフィック セレクターを使用できます。トラフィック セレクターは、トラフィックがローカルおよびリモート IP アドレス プレフィックス、送信元ポート範囲、宛先ポート範囲、プロトコルの指定ペアと一致する場合に、トンネルを介したトラフィックを許可する IKE ピア間の同意書です。特定のルートベースの VPN 内でトラフィックセレクターを定義すると、複数フェーズ2の IPsec Sa が生成される可能性があります。SA によって許可されるトラフィックのみが、トラフィックセレクターに準拠しています。リモートゲートウェイデバイスが非ジュニパーネットワークスデバイスである場合、一般的にトラフィックセレクターが必要になります。

ポリシーベースの Vpn は、SRX5400、SRX5600、SRX5800 デバイスでのみサポートされています。プラットフォームのサポートは、インストールの Junos OS リリースによって異なります。

ポリシーベースの Vpn とルートベースの Vpn の比較

表 3ポリシーベースの Vpn とルートベースの Vpn の違いについてまとめています。

表 3: ポリシーベースの Vpn とルートベースの Vpn の比較

ポリシーベースの Vpn

ルートベース Vpn

ポリシーベースの Vpn では、トンネルは、送信元、宛先、アプリケーション、およびアクションとともに、VPN トラフィックを許可するトンネルポリシーを構成するオブジェクトとして扱われます。

ルートベースの Vpn では、ポリシーによって VPN トンネルが明確に参照されるわけではありません。

トンネルポリシーは、特に名前を指定して VPN トンネルを参照します。

ルートは、宛先 IP アドレスに基づいてトンネルを介して送信されるトラフィックを決定します。

作成できるポリシーベースの VPN トンネルの数は、デバイスがサポートするトンネル数によって制限されます。

作成するルートベースの VPN トンネル数は、st0 インターフェイスの数 (ポイントツーポイント Vpn の場合) またはデバイスがサポートするトンネル数 (低い方) によって制限されます。

ポリシーベースの VPN では、同じ VPN トンネルを参照する多数のトンネルポリシーを作成できますが、各トンネルポリシーペアは、リモートピアとともに個々の IPsec SA を作成します。各 SA は、個々の VPN トンネルとしてカウントされます。

このルートはポリシーではなく、トンネルを通過するトラフィックを決定するため、1つの SA または VPN で複数のポリシーをサポートできます。

ポリシーベースの VPN では、アクションが許可される必要があり、トンネルが含まれている必要があります。

ルートベースの VPN では、トラフィックの規制は、その配信方法には結合されません。

動的なルーティング情報の交換は、ポリシーベースの Vpn ではサポートされていません。

ルートベースの Vpn は、VPN トンネルを介した動的なルーティング情報の交換をサポートしています。VPN トンネルにバインドされた st0 インターフェイス上で、OSPF などの動的ルーティングプロトコルのインスタンスを有効にすることができます。

トンネルに送信されるトラフィックを指定することによりきめ細かな制御を行う必要がある場合は、セキュリティポリシーを使用してポリシーベースの VPN を使用することをお勧めします。

ルートベースの Vpn は、トンネルに送信されるトラフィックを指定するためにルートを使用します。ポリシーは、特に VPN トンネルを参照しているわけではありません。

ポリシーベースの VPN トンネルでは、トンネルをポリシーの構築の要素として考えることができます。

セキュリティデバイスがルートルックアップを実行して、アドレスに到達するためにトラフィックを送信する必要があるインターフェイスを見つけると、セキュアトンネル (st0) インターフェイスを介してルートが検出されます。

ルートベースの VPN トンネルでは、トラフィックを配信する手段としてトンネルを検討し、そのトラフィックの配信を許可または拒否するための方法としてそのポリシーを検討できます。

IKE と IPsec パケット処理について

IPsec VPN トンネルは、トンネルの設定と適用されたセキュリティから成ります。トンネルの設定時に、ピアはセキュリティーアソシエーション (Sa) を確立します。これにより、トラフィックをセキュリティで保護するためのパラメーターが定義されます。( IPSEC VPN の概要を参照してください)。トンネルが確立された後、IPsec は、トンネルの設定中に Sa によって定義されたセキュリティパラメーターを適用することによって、2つのトンネルエンドポイント間で送信されるトラフィックを保護します。Junos OS 実装では、IPsec は、カプセル化セキュリティペイロード (ESP) および認証ヘッダー (AH) プロトコルをサポートするトンネルモードで適用されます。

このトピックは、以下のセクションで構成されています。

トンネルモードでのパケット処理

IPsec は、トランスポートまたはトンネルという 2 つのモードのいずれかを使用して動作します。トンネルの両端がホストである場合、どちらのモードを使用してもかまいません。トンネルの少なくとも1つのエンドポイントが、Junos OS ルーターやファイアウォールなどのセキュリティゲートウェイである場合、トンネルモードを使用する必要があります。ジュニパーネットワークスデバイスは、常に IPsec トンネルのトンネルモードで動作します。

トンネル モードでは、 に示すように、元の IP パケット(ペイロードとヘッダー)全体が別の IP ペイロード内でカプセル化され、新しいヘッダーが追加されます 図 1 。元のパケット全体は暗号化、認証、またはその両方にすることができます。認証ヘッダー (AH) プロトコルを使用すると、AH と新しいヘッダーも認証されます。Esp (カプセル化セキュリティーペイロード) プロトコルを使用した場合には、これらを認証することもできます。

図 1: トンネルモードトンネルモード

サイトツーサイト VPN では、新しいヘッダーで使用される送信元と宛先のアドレスはアウトゴーイングインターフェイスの IP アドレスです。参照図 2してください。

図 2: トンネルモードのサイトツーサイト VPNトンネルモードのサイトツーサイト VPN

ダイヤルアップ VPN では、VPN のダイヤルアップクライアント側にトンネルゲートウェイはありません。トンネルはクライアント自体に直接拡張されます図 3(を参照)。この場合、ダイヤルアップクライアントから送信されたパケットでは、新しいヘッダーとカプセル化した元のヘッダーの両方が同じ IP アドレスを持つことになります。クライアントのコンピューターのデバイスです。

動的 VPN クライアントや Netscreen-Remote などの一部の VPN クライアントは、仮想内部 IP アドレス(「スティッキー アドレス」とも呼ばれる)を使用します。Netscreen-Remote を使用すると、仮想 IP アドレスを定義できます。ダイナミック VPN クライアントは、XAuth の設定交換時に割り当てられた仮想 IP アドレスを使用します。このような場合、仮想内部 IP アドレスは、クライアントから送信されたトラフィックの元のパケットヘッダー内の送信元 IP アドレスであり、ISP がダイヤルアップクライアントを動的に割り当てる IP アドレスは、外部ヘッダー内の送信元 IP アドレスです。

図 3: トンネルモードのダイヤルアップ VPNトンネルモードのダイヤルアップ VPN

IKE と IPsec セッションの分散

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

VPN は、IKE と IPsec のワークロードをプラットフォームの複数のサービス処理ユニット (SPUs) に分散することで作成されます。サイトツーサイトトンネルの場合、最小ロード SPU がアンカー SPU として選択されます。複数の SPUs が同じ最小負荷を持つ場合、それらのいずれかをアンカー SPU として選択することができます。ここでは、ロードは、サイトツーサイトのゲートウェイの数または SPU に固定された手動 VPN トンネルに対応しています。動的トンネルでは、新たに確立された動的トンネルがラウンドロビンアルゴリズムを使用して SPU を選択します。

IPsec では、ワークロードは IKE を分散するアルゴリズムによって配布されます。指定された VPN トンネルの終了ポイントペアのフェーズ 2 SA は、特定の SPU によって排他的に所有され、このフェーズ 2 SA に属するすべての IPsec パケットが、その SA による IPsec 処理用のアンカーポイントに転送されます。

複数の IPsec セッション (フェーズ 2 SA) は、1つまたは複数の IKE セッションで運用できます。IPsec セッションを固定するために選択された SPU は、基になっている IKE セッションを固定した SPU に基づいています。そのため、単一の IKE ゲートウェイで実行されるすべての IPsec セッションは同じ SPU でサービスを提供し、いくつかの SPUs で負荷分散されていません。

表 4は、SRX5000 シリーズデバイスの例を示しています。3つの spus は、3つの IKE ゲートウェイを介して7個の IPsec トンネルを実行しています。

表 4: IKE と IPsec セッションの分散

SPU

IKE ゲートウェイ

IPSecトンネル

SPU0

IKE-1

IPsec-1

IPsec-2

IPsec-3

SPU1

IKE-2

IPsec-4

IPsec-5

IPsec-6

SPU2

IKE-3

IPsec-7

3つの SPUs は、それぞれが1つの IKE ゲートウェイを均等にロードしています。新しい IKE ゲートウェイが作成された場合は、SPU0、SPU1、または SPU2 を選択して、IKE ゲートウェイとその IPsec セッションを固定できます。

既存の IPsec トンネルを設定して切断しても、基礎となる IKE セッションや既存の IPsec トンネルには影響を与えません。

showのコマンドを使用して、SPU ごとの現在のトンネル数を表示します。show security ike tunnel-map

各ゲートウェイsummaryのアンカーポイントを表示するには、コマンドのオプションを使用します。show security ike tunnel-map summary

サービス処理カードの挿入に関する VPN サポート

SRX5400、SRX5600、SRX5800 の各デバイスには、シャーシベースの分散型プロセッサアーキテクチャが搭載されています。フロー処理能力は共有され、サービスプロセッシングカード (SPCs) の数に基づいています。新しい SPCs をインストールすることで、デバイスの処理能力を拡張できます。

SRX5400、SRX5600、または SRX5800 シャーシクラスターでは、既存の IKE または IPsec VPN トンネルのトラフィックに影響を与えたり中断したりすることなく、新しい SPCs をデバイスに挿入できます。クラスターの各シャーシに新しい SPC を挿入しても、既存のトンネルは影響を受けず、中断することなくトラフィックのフローが継続されます。

Junos OS リリース 19.4 R1 では、すべての SRX5000 シリーズデバイスのシャーシクラスターで、SPC3 カードを含む既存のシャーシに新しい SRX5K-MPC-SPC3 (SRX5K-MPC) または 4-15-320 SPC2 (SPC3) カードを挿入できます。カードは、シャーシ上の既存の SPC3 カードよりも上位のスロットにのみ挿入できます。SPC3 を挿入した後、ノードを再起動してカードをアクティブにする必要があります。ノードの再起動が完了すると、IPsec トンネルがカードに配信されます。

しかし、既存のトンネルでは、新しい Spus のサービス処理ユニット (SPUs) の処理能力を使用することはできません。新しい SPU では、新たに確立されたサイト間および動的トンネルをアンカーすることができます。しかし、新たに設定されたトンネルは、新しい SPU で対応することが保証されているわけではありません。

サイトツーサイトトンネルは、負荷分散アルゴリズムに基づいて別の SPUs に固定されています。ロードバランスアルゴリズムは、各 SPU が使用している数値フロースレッドに依存しています。同じローカルおよびリモートゲートウェイ IP アドレスに属するトンネルは、SPU で使用されるさまざまなフロー RT スレッドで同じ SPU に固定されています。最小負荷の SPU がアンカー SPU として選択されます。各 SPU は、その特定の SPU でホストされているフロー RT スレッドの数を管理しています。各 SPU でホストされるフロー RT スレッド数は、SPU のタイプによって異なります。

トンネル・ロード・ファクター = SPU で使用されるフロー RT スレッドの SPU または合計数に対応する、トンネル数を指定します。

動的トンネルは、ラウンドロビンアルゴリズムに基づいて異なる SPUs に固定されています。新たに構成された動的トンネルは、新しい SPC で固定されるとは限りません。

Junos OS では、18.2 R2 と 18.4 R1 のリリースで、SRX5K-MPC-SPC3 (SPC3) で現在サポートされている既存のすべての IPsec VPN 機能が、SRX5K-MPC SPC-4-15-320 (SPC2) および SPC3 カードがインストールされている場合にのみ、SRX5400、SRX5600、および SRX5800 の各デバイスでサポートされます。デバイスをシャーシクラスターモードまたはスタンドアロンモードで動作させる。

SPC2 と SPC3 カードの両方がインストールされている場合は、 show security ipsec tunnel-distributionコマンドを使用して別の spus でトンネルマッピングを検証できます。

SPC2 カードのみshow security ike tunnel-mapを挿入した別の spus でトンネルマッピングを表示するには、このコマンドを使用します。SPC2 およびshow security ike tunnel-map SPC3 カードがインストールされている環境では、このコマンドは有効ではありません。

SPC3 カードを挿入しています: ガイドラインと制限:

  • シャーシクラスターでは、ノードの1つの SPC3 カードがあり、もう一方のノードが2個の SPC3 カードを備えている場合、1個の SPC3 カードを持つノードへのフェイルオーバーはサポートされません。

  • 下のスロットにある現在の SPC3 より大きいスロットに、既存のシャーシの SPC3 または SPC2 を挿入する必要があります。

  • SPC3 ISHU が機能するためには、新しい SPC3 カードをより大きなスロット番号に挿入する必要があります。

  • SRX5800 シャーシクラスターでは、電力と熱分散に制限があるため、最上位スロット (スロット no. 11) に SPC3 カードを挿入することはできません。

  • SPC3 のホット削除をサポートしていません。

SRX5K-MPC の SPC3 サービス処理カードでの IPsec VPN 機能セットの有効化

SRX5000 シリーズデバイスの数が SRX5K-SPC3 カードを使用している場合、パッケージをインストールし、IPsec VPN 機能を有効にする junos-ike 必要があります。デフォルトでは、パッケージは RE3 Junos OS デバイスの junos-ike 20.1R2、20.2R2、20.3R2、20.4R1 にインストールされ、SRX5000 シリーズ 以降はインストールされます。その結果 ikedikemd 、IPsec鍵モデル(kmd)の代わりに、デフォルトでルーティング エンジン管理デーモンされます。

KMDプロセスを使用して、デフォルトのデフォルト設定ではなくIPsec VPN機能を有効IKE、 コマンドを実行 request system software delete junos-ike します。

インストールされてjunos-ikeいるパッケージを確認するには、次のコマンドを使用します。

SRX5K-SPC3 を使用した SRX5000 ラインのデバイスおよび新しいパッケージを使用した vSRX インスタンスでの IPsec VPN 機能のサポート

このトピックでは、SPC3 を使用するデバイスの SRX5000 シリーズ および複数のインスタンスでサポートされていない IPsec VPN の機能と設定vSRX概要を示します。

IPsec VPN 機能は、2 つのプロセスと ikedikemd 、SRX5K-SPC3 および vSRXでサポートされています。一度に1 iked つの ikemd インスタンス、およびルーティング エンジン実行されます。

デフォルトでは、パッケージは re3 搭載デバイスの Junos OS リリース Junos-ike 20.1R2、20.2R2、20.3R2、SRX5000 シリーズ 20.4R1 にインストールされ、プロセスとプロセスの両方がルーティング エンジンで実行されます。 ikedikemd

ルーチン エンジン ikemd でプロセスを再起動するには、 コマンドを使用 restart ike-config-management します。

デバイスで iked プロセスを再起動するには、 ルーティング エンジンを使用 restart ike-key-management します。

KMDプロセスを使用して、デフォルトのデフォルト設定ではなくIPsec VPN機能を有効IKE、コマンドを実行 request system software delete junos-ike します。

IPsec VPN 機能はサポートされていません

機能が特定のプラットフォームまたは Junos OS リリースによってサポートされているかどうかを確認するには、機能エクスプローラーを参照してください。

表 5: デバイスおよびインスタンス間SRX シリーズ IPsec VPN 機能vSRXサポート

特長

SRX5K-SPC3 および SRX インスタンスを使用した SRX 5000 vSRXサポート

ADVPN(自動検出 VPN)

なし

AutoVPN プロトコルに依存しないマルチキャスト (PIM) ポイントツー multipoint モード。

なし

ユニキャストトラフィックの自動 Vpn RIP をサポートします。

なし

St0 インターフェイス上の OSPFv3 ルート経由の双方向フォワーディング検知 (BFD)

このデバイスではvSRX

IPsec Vpn で転送クラスを構成します。

なし

設定モード (ドラフト dukes-ike モード-cfg-03)

なし

Dead ピア検知 (DPD) と DPD ゲートウェイフェイルオーバー

DPD ゲートウェイ フェイルオーバーは、デバイスでvSRX。

AH トランスポート モード

なし

グループ VPN。

なし

IKE のアイドルタイマー。

なし

IPsec SA のアイドルタイマー。

なし

無効な SPI 応答です。

なし

IKE SA の有効期間 (キロバイト)。

なし

論理システムです。

なし

手動 VPN.

なし

マルチキャストトラフィック

なし

St0 インターフェイスを介した近傍検索プロトコル (NDP)。

なし

IPsec datapath 検証のためのパケットサイズの設定

なし

トンネル経由の IPv6 フラグメントでのパケットの並べ替え。

なし

ポイントツーマルチポイントトンネルインターフェイス

なし

ポリシーベースの IPsec VPN。

なし

リモートアクセス。

なし

RIP over IPsec。

なし

動的 VPN 構成用のサポートグループ IKE Id。

SRX でサポート

IPsec (外部/内部) に対応した TOS/DSCP。

SRX でサポート

静的および動的 (RIP、OSPF、BGP) ルーティングのユニキャスト

SRX でサポート

VPN 監視

なし

Xauth

なし

ハブアンドスポーク型 Vpn について

デバイスで終了する2つの VPN トンネルを作成する場合は、ルートのペアを設定して、1つのトンネルを終了しているトラフィックを他のトンネルに転送することができます。また、トラフィックが1つのトンネルから他方に通過するためのポリシーを作成する必要があります。このような構成は、ハブアンドスポーク型 VPNとして知られています。(を図 4参照してください)

また、複数の Vpn を構成し、任意の2つのトンネル間でトラフィックをルーティングすることもできます。

SRX シリーズデバイスでは、ルートベースのハブアンドスポーク機能のみがサポートされています。

図 4: ハブアンドスポーク型 VPN 構成での複数トンネルハブアンドスポーク型 VPN 構成での複数トンネル
リリース履歴テーブル
リリース
説明
20.1R2
デフォルトでは、パッケージは RE3 Junos OS デバイスの junos-ike 20.1R2、20.2R2、20.3R2、20.4R1 にインストールされ、SRX5000 シリーズ 以降はインストールされます。その結果 ikedikemd 、IPsec鍵モデル(kmd)の代わりに、デフォルトでルーティング エンジン管理デーモンされます。
19.1R1
最初のリリース Junos OS デバイス19.1R1、SRX シリーズ DH グループ 15、16、21 をサポートしています。