【特集】管理者のための
インターネットVPNの接続環境(前編)
組織間を接続する「サイト間接続型VPN」の構成を知る
丸山 龍一郎
2003/3/5
「特集 インターネットVPNの導入メリット(前・後編)」では、IPsec技術に基づくVPN(インターネットVPN)が何を実現し、導入した場合のメリットは何かについて、管理運用面に重きを置いて解説した。
今回の特集は、前編ではインターネットVPNを使用して組織間を接続するサイト間接続型のVPN構成において管理者が認識しておかなければならない特徴について記述し、後編ではリモートアクセスVPNに関して、IPsec機能の現状と問題点について説明する。
 |
サイト間接続型VPNを導入する場合の留意点 |
サイト間接続型VPNの典型的なネットワーク構成を図1に示す。各組織が設置したVPNゲートウェイ間でIPsecVPNトンネルを構成し、各組織のネットワーク間を相互接続する。組織間で相互接続されるネットワークをVPNドメインと呼ぶ。
VPNドメイン内では、接続相手先のVPNドメインあてのパケットがVPNトンネルを経由するように経路制御がなされなければならない。パケットを受信したVPNゲートウェイでは、受信したパケットを復号してセキュリティポリシーに従ってアクセス制御する。
 |
図1 サイト間接続型VPNのネットワーク構成(拡大) |
サイト間接続型VPNを導入する場合の留意点を以下に示す。
●VPNドメインに割り当てるアドレス体系 |
●VPNゲートウェイ上で管理されるSA(Security
Association)のグラニュラリティ(IPsec SAを生成する単位) |
●VPNゲートウェイの通過パケットに対する経路制御 |
●VPNゲートウェイの性能 |
●VPNゲートウェイの管理 |
(1)VPNドメインのネットワークアドレス
VPNドメインとして使用するネットワークアドレスが、接続するサイト間で重複しないように割り当てることが必要である。VPNドメインのネットワークアドレスが重複してしまった場合の動作を説明する。
図1において、サイトAのVPNドメイン内のホストAからサイトBのVPNドメイン内のサーバB2にVPN経由でアクセスすることを考える。送信されたIPパケットの送信先アドレス、送信元アドレスの両方が同じネットワークアドレスとなり、ホストAではダイレクトルーティングによりパケットを処理する。つまり、サイトBのサーバB2までパケットを到達させることができない。このような状態が両方のサイトで発生し、VPN通信ができないことになる。
VPNドメインのネットワークアドレスが重複する場合の対応策としては、 以下のような方法が考えられる。
- VPNドメインのネットワークアドレスをサイト間で重複しないように調整することが最適な方法である。一般的に同一企業の組織間を接続する場合は、情報システム部により調整することが可能であるが、異なる企業間を接続するような場合の調整は困難を極める。双方ともアドレス体系を変更したくないからである。
- VPNゲートウェイの機能を使用してVPNトンネルを通過したパケットの送信元アドレスを重複しないアドレス体系に変換する。
(2)IPsec SAのグラニュラリティ(Granularity)
IPsecVPNでは、VPNコネクションを確立したときにSA(Security Association)を生成し、コネクションが管理される。SAにはフェイズ1のネゴシエーションの結果生成されるIKE
SAと、そのIKE SAを使用して実際のアプリケーションデータを暗号化するためのIPsec SAが生成される。
IKE SAは双方向通信が可能であるが、1つのIPsec SAは単方向通信である。そのため、アプリケーションデータの暗号化通信を双方向で実現するためには、1つのVPNコネクションに対して2つのIPsec
SAが必要となる。
IPsec SAを生成する単位(グラニュラリティという)はVPNゲートウェイの設定に依存する。実際の設定では、サブネット/ホスト/プロトコル/ポート単位で指定することができる。図2のような構成の場合、サイトAのホストH1とH2からサイトBのサーバS(HTTPとFTPのサーバ)へVPN経由でアクセスした場合に、ゲートウェイ上でホスト単位にIPsec
SAを管理する例である。
 |
ホスト |
サーバ
|
図2 IPsec SAのグラニュラリティ(拡大) |
● IPsec SAのグラニュラリティがホストの場合のIPsec SA数
IPsec SA数:2 ホストH1からサーバSへの通信用/サーバSからホストH1への通信用 |
IPsec SA数:2 ホストH2からサーバSへの通信用/サーバSからホストH2への通信用 |
● IPsec SAのグラニュラリティの設定がポートの場合のIPsec SA数
IPsec SA数:2 ホストH1からサーバS(HTTP)への通信用/サーバS(HTTP)からホストH1への通信用 |
IPsec SA数:2 ホストH1からサーバS(FTP)への通信用/サーバS(FTP)からホストH1への通信用
|
IPsec SA数:2 ホストH2からサーバS(HTTP)への通信用/サーバS(HTTP)からホストH2への通信用 |
IPsec SA数:2 ホストH2からサーバS(FTP)への通信用/サーバS(FTP)からホストH2への通信用 |
VPNゲートウェイ製品の仕様では、管理可能なSA数に制限があるため、VPNゲートウェイが同時に処理できるVPNコネクション数を考える上でIPsec
SAのグラニュラリティの設定は重要となる。
(3)VPNパケットの経路制御
VPN通信が正しく実行されるためには接続先相手のVPNドメインから送信されたパケットが目的のサーバに到達し、その応答パケットが再度VPNトンネルを通過して発信元に戻されなければならない。VPNパケットに対する経路制御は、VPN環境の構築方法によっても変わる。ファイアウォールとVPNゲートウェイが一体化した製品と別個のシステムを用いて実現した場合の経路制御を考える(図3)。
 |
ファイアウォールとVPNゲートウェイが一体化した製品の場合は、 インターネットあてのパケットとVPNドメインあてのパケットのデフォルト
ゲートウェイを共通にすることができる。
|
|
ファイアウォールとVPNゲートウェイを別個の製品で実現した場合は、
各システム上にインターネットあてのパケットのデフォルトゲートウェイとして
ファイアウォールを定義し、VPNドメインあてのパケットのゲートウェイとして VPNゲートウェイを定義しなければならない。
|
図3 VPNパケットの経路制御 |
一体化した製品を使用して構築されたネットワーク環境では、イントラネット上の各ホストのデフォルトルートはファイアウォールのイントラネット側のインターフェイスに設定されている。この場合、接続先相手のVPNドメインあてのパケットも結果としてVPNゲートウェイに戻されるため、正しくVPN通信が可能となる。
一方、ファイアウォールとVPNゲートウェイが別個のシステムとして実現されている環境では、HTTPなどのインターネットあてのパケットはファイアウォールを経由、VPNドメインあてのパケットはVPNゲートウェイにルーティングされなければならない。このような経路定義はVPN通信を行うすべてのシステムで必要となる。VPN通信を行うシステムが多数存在する場合は、個々のシステムに経路定義を設定する負荷を回避するために、ルータを設置してVPN通信が必要なシステムを集約し、そのルータのみに経路情報を定義する。
(4)VPNゲートウェイの性能
VPNゲートウェイでは、VPNドメイン間で送受信されるすべてのパケットに対して暗号化/復号化処理が実行される。例えば、FTPをVPNトンネル経由で利用する場合、大量のデータ通信が開始されると一時的にVPNゲートウェイのCPU処理はFTPデータの暗号化/復号化処理により高負荷となり、ほかの処理がCPUを使用することは困難となる。
ファイアウォールと一体化した製品の場合、VPN通信によりCPU処理が占有されてしまうと、ファイアウォールの処理性能が低下する。そのため、一体化した製品では、暗号化処理を専用に処理するASICを搭載、あるいは、複数のCPUを有するプラットフォームを採用し、CPU負荷を分散させるような仕組みを有している。
(5)VPNゲートウェイの管理
サイト間VPNを構築する場合、VPNゲートウェイに定義されるフェイズ1/フェイズ2のパラメータや事前共有鍵などは双方で正しい値を定義する必要がある。理想的なVPN管理環境は、1つの組織が双方のVPNゲートウェイを統合的に管理することである。しかし、統合管理環境を実現するためには、組織間(企業間)の壁や技術(スキル)問題、技術者の教育コストなどさまざまな問題が存在する。
統合管理環境においては、リモートに存在するVPNゲートウェイを管理するための通信プロトコルを介在するファイアウォール上を通過させる作業も必要となる。さらに、リモート管理で運用する場合には、管理用通信が不可能となった状況を想定した代替の運用方法も検討しておく必要がある。
 |
サイト間接続型のネットワークトポロジー |
サイト間VPN接続を構築する場合のネットワークトポロジーについて考える。構成するネットワークトポロジーには以下の2つのタイプが存在する(図4)。
- フルメッシュ型(Full-Meshed)
- ハブ・アンド・スポーク型(Hub-and-Spoke)
フルメッシュ型(Full-Meshed)
|
ハブ・アンド・スポーク型
(Hub-and-Spoke)
|
 |
すべてのVPNゲートウェイは、ほかのVPNゲートウェイ
と直接VPNコネクションで接続される。GW-Aは、 他の3つのサイトとコネクションを確立する。 |
|
VPNゲートウェイは、VPNハブを経由してほかのVPN ゲートウェイに接続する。GW-AとGW-Cの間で通信する場合は、VPNトンネルA-BとB-Cの2本のコネク
ションを利用する。 GW-AはVPNハブとの1つのコネクションのみ生成。 |
図4 2つのネットワークトポロジーのタイプ |
(1)フルメッシュ型トポロジー
最も典型的なVPNネットワークのトポロジーである。VPN接続する各サイト間を個々に相互接続するネットワーク構成(図4左側)で、1つのVPNゲートウェイはほかのサイトのVPNゲートウェイと直接接続される。以下に、フルメッシュ型トポロジーの特徴を示す。
- 各サイト間でそれぞれにVPNコネクションを確立しているため、1台のVPNゲートウェイが停止してもほかのサイト間のVPNコネクションに影響しない。
- 各サイトのVPNドメインのネットワークアドレスを重複しないように調整する必要がある。接続するサイト数が増加するに従いVPNドメインのネットワークアドレスの調整が困難となる。
- 各サイト間で送受信されるパケットに対するアクセス制御は、VPNコネクションを確立する2つのVPNゲートウェイ間で定義する必要がある。
- VPN接続に関連するルールベースが複雑になる。
- 各VPNゲートウェイが生成するVPNコネクション数が多くなる。接続するサイトの増加に比例して、生成されるVPNコネクション数が増加する。
- 新たにVPNゲートウェイを追加する場合、すべてのサイトにおいて設定変更が必要となる。
3つのサイトをフルメッシュ型のトポロジーで構成するVPN環境を考える(図5)。
 |
図5 3つのサイトをフルメッシュ型のトポロジーで構成するVPN環境 |
この例では、VPNで相互接続のために3つのVPNトンネルが生成される。ここでは、VPNゲートウェイA上に定義されるVPN接続用のルールを以下に示す。
10.0.1.0 --- 10.0.2.0 --- ANY --- Encrypt(サイトAからサイトBへのVPN通信用) |
10.0.2.0 --- 10.0.1.0 --- ANY --- Encrypt(サイトBからサイトAへのVPN通信用) |
10.0.1.0 --- 10.0.3.0 --- ANY --- Encrypt(サイトAからサイトCへのVPN通信用) |
10.0.3.0 --- 10.0.1.0 --- ANY --- Encrypt(サイトCからサイトAへのVPN通信用) |
上記と同様なルールをVPNゲートウェイB、Cにも定義する必要がある。この例から容易に想像できるように、フルメッシュ型トポロジーでは接続するサイト数の増加に比例して定義するVPN関連ルールも増加し、VPNゲート
ウェイ上のルール全体が複雑になる。
(2)ハブ・アンド・スポーク型トポロジー(スター型トポロジー)
VPN接続するサイトが中央のVPNゲートウェイ(VPNハブという)を経由して相互に接続されるネットワーク構成である(図4右側)。一般的に、本社のVPNゲートウェイをVPNハブとして各支店のVPNゲートウェイを接続する。以下に、ハブ・アンド・スポーク型トポロジーの特徴を示す。
- VPNハブが停止するとすべてのVPNコネクションが利用不可能となる。
- VPNハブを経由して送受信されるすべてのトラフィックに対してアクセス制御が可能である。各サイト間で送受信されるパケットは、VPNハブで一度復号化され、VPNポリシーに従って再度暗号化されて送信される。そのためVPNハブ上で各サイトあてのパケットに対するアクセス制御を実現することが可能である。
- 各サイトが生成するVPNコネクションは、VPNハブとの間の1本のコネクションのみである。管理可能なVPNコネクション数に制限があるVPNゲートウェイ製品(SOHO向けの小型のVPN製品など)を利用して多数のサイトとVPNを確立するような場合に利用できる。
- 各組織のVPNドメインのネットワークをサイト全体で再構築する必要がある。
- VPNハブとなるVPNゲートウェイの高性能化および高可用性機能が必要となる。
3つのサイトをハブ・アンド・スポーク型トポロジーで構成するVPN環境を考える。以下の例では、サイトBがVPNハブとして動作し、サイトAとサイトCがそれぞれサイトBに接続する。このトポロジーにおいてサイトAからサイトCに通信する場合の動作を説明する。
- VPNドメインA上のホストAからVPNドメインC上のホストCへのパケットは、VPNゲートウェイAで暗号化パケットとしてVPNハブBに送信される。
- VPNゲートウェイBでは、ホストAからの暗号化パケットを復号する。
- 復号されたパケットはVPNゲートウェイBに定義されたルールベースと経路情報に従って処理され、再び暗号化されてサイトCに送信される。
- VPNゲートウェイCでは、復号してホストCに送信する。
ハブ・アンド・スポーク型トポロジーのVPNハブとして利用できるVPNゲートウェイには以下のような要件が存在する。
●特別なVPN機能
前述したように、VPNハブでは一方のVPNトンネルからのパケットを復号し、VPNポリシーに従って別のVPNトンネルに送信するために暗号化するような特別な処理が実行できる必要がある。また、オーバーラップするVPNドメインを管理するSAに対してアクセス制御ルールを正しく解釈できる機能が必要となる。
以下の例では、支店サイトのVPNドメインのネットワークアドレスが、VPNハブの背後のVPNドメインのネットワークアドレスのサブネットとなるように割り当てられている。ハブ・アンド・スポーク型トポロジーでは、IPsecのSAに関する仕様上、SAにおいて複数のVPNドメインを扱えないこととVPN
ルールを複雑にしないためにも、前述のようにVPNドメインのネットワークア ドレスを割り当てることが推奨される(図6)。
 |
図6 ハブ・アンド・スポーク型トポロジーで構成するVPN環境 |
サイトAにおけるVPN接続用のルール定義を以下に示す。
10.0.1.0/24 --- 10.0.0.0/8 --- ANY --- Encrypt(サイトAからサイトA以外へのVPN通信用) |
10.0.0.0/8 --- 10.0.1.0/24 --- ANY --- Encrypt(サイトA以外からサイトAへのVPN通信用) |
サイトCにおけるVPN接続用のルール定義を以下に示す。
10.0.2.0/24 --- 10.0.0.0/8 --- ANY --- Encrypt(サイトCからサイトC以外へのVPN通信用) |
10.0.0.0/8 --- 10.0.2.0/24 --- ANY --- Encrypt(サイトC以外からサイトCへのVPN通信用) |
サイトB(VPNハブ)におけるVPN接続用のルール定義を以下に示す。
10.0.1.0 --- 10.0.2.0 --- ANY --- Encrypt(サイトAからサイトBへのVPN通信用) |
10.0.1.0/24 --- 10.0.0.0/8 --- ANY --- Encrypt(サイトAからサイトBへのVPN通信用) |
10.0.1.0 --- 10.0.3.0 --- ANY --- Encrypt(サイトAからサイトCへのVPN通信用) |
10.0.2.0/24 --- 10.0.0.0/8 --- ANY --- Encrypt(サイトCからサイトBへのVPN通信用) |
●高性能、高可用性
ハブ・アンド・スポーク型のVPNハブとなるシステムには、すべてのサイト間のVPNトラフィックに対して暗号化/復号化処理を実現するための高い処理能力が要求される。また、VPNハブが停止した場合にすべてのサイト間のVPN通信の停止を回避するために、VPNゲートウェイのクラスタ化などの高可用性を実現する必要がある。
今回2つのタイプのVPNネットワークトポロジーについて説明してきたが、どちらの構成を選択すべきかの指標としては構築するVPNネットワークの規模に基づいて検討する必要がある。少数のサイト間を接続する場合であれば、定義されるVPNポリシー数もそれほど多くならないため、フルメッシュ型でも十分である。大規模なVPNネットワークを構成する場合には、VPNポリシーの単純さや新規サイト追加時のメンテナンス性を考慮して、ハブ・アンド・スポーク型の構成を検討すべきである。
◇
後編では、ブロードバンド環境の普及でますます利用シーンが増加するリモートアクセスVPNで実現するIPsec機能の現状と問題点について説明する。
|