VPN ポリシー設定のための Dell SonicWALL 機能は、「VPN > 設定」ページで提供されています。この「VPN > 設定」ページから、サイト間 VPN ポリシーおよび GroupVPN ポリシーを設定することができます。
仮想プライベート ネットワーク (VPN) では、パブリック インターネットを介して 2 台以上のコンピュータ、または保護されたネットワーク間をセキュリティ保護された手段で接続できます。VPN では、正しい通信相手との情報の送受信を保証するために、認証が実施されます。認証によって、情報を送受信途中の閲覧や改ざんから保護するためのセキュリティが確保されます。
インターネット プロトコル セキュリティ (IPsec) およびセキュア ソケット レイヤ (SSL) が発明される以前は、セキュリティ保護された手段でリモート コンピュータやネットワーク間を接続するためには専用回線または衛星中継が必要でしたが、 両方とも柔軟性が乏しいうえコストが割高でした。
VPN では、接続作成時に同様の信頼性およびセキュリティを確保するために、セキュリティ保護されたトンネルをインターネット経由で確立します。このトンネルは物理接続ではないことから柔軟性に優れているため、このトンネルに随時に変更を加え、さらに多くのノードを追加することも、ノードを変更することも、また全ノードを削除することもできます。また、VPN のインターネット インフラストラクチャには既存のものを使えるため、コストをかなり低く抑えることもできます。
今日広範に使用されている VPN には大きく分けて、次の 2 種類があります。
• IPsec VPN: IPsec は、ネットワーク通信のパケット処理層でのセキュリティに関する一連のプロトコルです。IPsec のメリットは、個別ユーザのコンピュータを変更する必要なしにセキュリティ上の処置に対処できることです。SonicOS は、IPsec VPN の作成および管理をサポートしています。
• IPsec では、2 とおりあるセキュリティ サービス (データ送信者の認証を基本的に許可する認証ヘッダー (AH) と、データ送信者の認証およびデータの暗号化の両方をサポートするカプセル化セキュリティ ペイロード (ESP)) のどちらかを選択できます。これらの各サービスに関連する固有情報は、IP パケット ヘッダーの後続ヘッダー内のパケットに挿入されます。
• SSL VPN: セキュア ソケット レイヤ (SSL) は、インターネット上での (通常は HTTPS 経由の) メッセージ転送のセキュリティを管理するためのプロトコルです。SSL が使用するプログラム層は、インターネットのハイパーテキスト転送プロトコル (HTTP) 層と転送制御プロトコル (TCP) 層との間に位置しています。SSL には RSA の公開鍵/秘密鍵暗号化方式が使用され、この暗号化方式を使用する際にはデジタル証明書も使用されます。SSL VPN は、SSL を使用して VPN トンネルのセキュリティを保護します。
• SSL VPN のメリットの 1 つは、ほとんどのウェブ ブラウザに SSL を組み込めることです。その際に特別な VPN クライアント ソフトウェアやハードウェアは必要ありません。
Note Dell SonicWALL で製造している SSL VPN 機器は、SonicOS が動作する Dell SonicWALL ネットワークセキュリティ装置と連携させて使うことも、別個に使うことも可能です。Dell SonicWALL の SSL VPN 機器については、Dell SonicWALL のウェブサイトhttp://www.SonicWALL.com/us/products/Secure_Remote_Access.html を参照してください。
IPsec VPN トラフィックは、次の 2 つのフェーズでセキュリティ保護されます。
• 認証: 第 1 フェーズでは、公開鍵と秘密鍵のペアのうちの公開鍵部分の交換によって、トラフィックの送信者および受信者の認証を確立します。このフェーズが正常終了しないうちは、VPN トンネルを確立できません。
• 暗号化: VPN トンネル内のトラフィックは、AES や 3DES などの暗号化アルゴリズムを使用して暗号化されます。
手動鍵を使用する場合 (VPN 内の各ノードに同じ値を入力する必要があるため)、VPN メンバー認証情報およびデータ暗号化/復号化情報を交換する際には、認証情報 (鍵) の交換および VPN トンネル確立のための IKE (インターネット鍵交換) プロトコルが使用されます。SonicOS Enhanced では、以下の 2 つのバージョンの IKE がサポートされます。
• IKEv2
IKE バージョン 1 は 2 つのフェーズから成る処理によって、VPN トンネルのセキュリティを保護します。
• IKE フェーズ 1 は認証フェーズです。トンネルの片側にあるノードまたはゲートウェイは、相互に認証し、暗号化鍵と復号化鍵を交換して、セキュリティ保護されたトンネルを確立します。
• IKE フェーズ 2 はネゴシエーション フェーズです。2 つのノードまたはゲートウェイはいったん認証を終えると、VPN 経由で渡されたデータに対して用いる暗号化方式および (ハッシュ関数を使用した) データ検証をネゴシエートするとともに、トンネルおよび存続期間内でのセキュア アソシエーション (SA) の数をネゴシエートし、その後、暗号化/復号化鍵の再ネゴシエートを要求します。
IKE フェーズ 1
IKEv1 の場合、認証情報を交換するモードには、 メイン モードおよびアグレッシブ モードの 2 とおりがあります。
メイン モード: VPN を起動するノードまたはゲートウェイは、受信側のノードまたはゲートウェイに問い合わせて、認証方式、公開鍵、および識別情報を交換します。この処理では通常 6 つのメッセージを送受信する必要があります。メイン モードでは、認証メッセージが次のような順序で処理されます。
1. 開始側が自らサポートしている暗号化アルゴリズムのリストを送信する
2. サポートされている暗号化アルゴリズムのリストを、応答側が使用して応答する
3. 相互にサポートされている最初の暗号化アルゴリズム用の公開鍵 (Diffie-Helman 公開/秘密鍵のペアの一部) を開始側が送信する
4. 応答側が同じ暗号化アルゴリズムの公開鍵を使用して応答する
5. 開始側が識別情報 (通常は証明書) を送信する
6. 応答側が識別情報を使用して応答する
アグレッシブ モード: 認証時に交換されるメッセージの数を半減するために、どの暗号化アルゴリズムを使用したらよいかについてのネゴシエーションが省略されます。ある特定のアルゴリズムを開始側が提案すると、応答側はそのアルゴリズムをサポートしているかどうかについての応答を返します。 たとえば、次のようになります。
1. 開始側が自らの公開鍵を使用/送信するための暗号化アルゴリズムを提案する
2. 応答側が公開鍵および識別証明を使用して応答する
3. 開始側が識別証明を送信する 認証後は、VPN トンネルが 2 つの SA を使用して確立されます。1 つは各ノードから他のノードへの SA です。
IKE フェーズ 2
IKE フェーズ 2 では、両方の通信相手が利用するセキュリティの種類をネゴシエートします。
個々のパケット用のセキュリティには、次の 2 種類があります。
• カプセル化セキュリティ ペイロード (ESP) － 各パケットのデータ部を、通信相手間でネゴシエートされたプロトコルを使用して暗号化します。
• 認証ヘッダー (AH) － 各パケットの認証ヘッダーには認証情報が含まれています。これにより、情報の信憑性が保証されるとともに、改ざんが防止されます。AH のデータには暗号化は一切使用されません。
SonicOS は、VPN 経由のトラフィックに対して、次の暗号化方式をサポートしています。
• DES
• 3DES
• AES-128
• AES-192
• AES-256
IKEv1 の詳細は、当初の IKE を規定する 3 つの仕様書 (RFC 2407、RFC 2408 および RFC 2409) に記載されています。 次のウェブで閲覧できます。
• http://www.faqs.org/rfcs/rfc2407.html
• http://www.faqs.org/rfcs/rfc2408.html
• http://www.faqs.org/rfcs/rfc2409.html
IKE バージョン 2 は、SA のネゴシエーションおよび確立のための新しいプロトコルです。IKEv2 には、改良されたセキュリティ、簡素化されたアーキテクチャ、強化されたリモート ユーザ向けサポートが導入されています。また、IKEv2 では、上記以外に IP アドレスの割り当ておよび拡張認証プロトコル (EAP) もサポートすることにより、いくつかの認証方式やリモート アクセスのシナリオを可能にします。IKEv2 を使用することにより、SA の確立に要するメッセージ交換の回数が IKEv1 のメイン モードに比べて大幅に減少すると同時に、IKEv1 のアグレッシブ モードに比べてセキュリティが強化され柔軟性が高まります。これにより、鍵を再設定する際の遅延が低減します。VPN の拡大に伴って複数のノードまたはゲートウェイ間に含まれるトンネルが増えると、IKEv2 は各トンネルに要する SA の数を減らすことによって、帯域幅の必要量を低く抑え、ハウスキーピングのオーバーヘッドを軽減します。
IKEv2 には IKEv1 との互換性はありません。IKEv2 を使用する場合、トンネルを確立するには、VPN 内のすべてのノードに IKEv2 を使用する必要があります。
IKEv2 内の SA は子 SA と呼ばれており、VPN トンネルの有効期間中はいつでも個別に作成、変更、削除することができます。
IKEv2 での初期化と認証
IKEv2 は、メッセージ交換のペア (2 組のメッセージ/応答) を使用して VPN トンネルを初期化します。
• 通信の初期化: 1 組目のメッセージ (IKE_SA_INIT) は、暗号化アルゴリズムをネゴシエートし、ナンス (反復したメッセージを防ぐために生成し送信されるランダム値) を交換して、公開鍵交換を実行します。
– サポートされている暗号化アルゴリズム、公開鍵、およびナンスのリストを、開始側が送信する
– 応答側が選択した暗号化アルゴリズム、公開鍵、ナンスおよび認証要求を送信する
• 認証: 2 組目のメッセージ (IKE_AUTH) は、以前のメッセージを認証し、識別情報および証明書を交換して、最初の CHILD_SA を確立します。これらのメッセージの一部は、IKE_SA_INIT 交換で確立された鍵によって暗号化され整合性が保全されます。 その結果、識別情報が盗聴から隠蔽され、あらゆるメッセージの全フィールドが認証されます。
– 開始側が識別証明 (たとえば、共有鍵や証明書)、および子 SA 確立の要求を送信する
– 応答側が一致する識別証明を送信して、子 SA のネゴシエーションを完了する
IKEv2 での SA のネゴシエーション
この交換は 1 つの要求/応答ペアから成るため、IKEv1 では“フェーズ 2 交換"と呼ばれていました。フェーズ 2 交換は、最初の交換の完了後に、SA の片側で開始できます。
最初の交換以降の後続メッセージはすべて、IKE 交換の最初の 2 つのメッセージでネゴシエートされた暗号化アルゴリズムおよび鍵を使用して、暗号化によって保護されます。
このセクションでは、CREATE_CHILD_SA 交換を開始する側のエンドポイントを“開始側"という用語で指しています。
1. この交換は、両方のエンドポイントで開始可能であるためです。 開始側は子 SA オファーを送信する(データを暗号化する必要のある場合は、暗号化方式および公開鍵も送信する)
2. 応答側は受け取った子 SA オファーを送信する (暗号情報が含まれていた場合は、公開鍵も送信する)
設定ペイロード
IKEv2 設定ペイロード (CP) によって、VPN サーバはリモート クライアントに IP アドレスを動的に割り当てることができます。DHCP ネゴシエーションと同様に、クライアントが LAN に直接接続しているかのようにクライアントとサーバが情報を交換します。
IKE フェーズ 1 プロポーザルの交換方式としてIKEv2 を選択すると、管理者はクライアントに IKEv2 IP アドレス プールから IP アドレスを割り当てることができます。
IKEv2 設定ペイロードは、比較的小規模の配備を想定しています。
Windows 7 IKEv2 クライアント
Dell SonicWALL 装置と使用する場合、Windows 7 IKEv2 クライアントは認証方式としてサードパーティ証明書を使用する必要があります。リモート アクセス サーバにインストールするこの証明書には、以下の値が含まれます。
• コモンネーム (CN):このフィールドには、リモート アクセス サーバの完全修飾 DNS 名または IP アドレスが含まれている必要があります。サーバがネットワーク アドレス指定変換 (NAT) ルータの背後にある場合は、証明書には、NAT ルータの外部接続の完全修飾 DNS 名または IP アドレス (クライアント コンピュータからサーバのアドレスとして認識されるアドレス) が含まれている必要があります。
• EKU:このフィールドには、サーバ認証が含まれている必要があります。サーバ認証証明書が複数ある場合は、IP セキュリティ IKE 中間 EKU も含めてください。証明書を 1 つに限定して両方の EKU オプションを含める必要であり、そうでないと、IPsec にはどの証明書を使用すればよいかわからず、目的の証明書が選択されない可能性があります。詳細については、以下を参照してください。
http://technet.microsoft.com/en-us/library/dd941612(WS.10).aspx
Note IKEv2 の詳細は、仕様書 RFC4306 に記載されています。次のウェブで閲覧できます。http://www.ietf.org/rfc/rfc4306.txt