VPNゲートウェイを導入する際の検討ポイント：インターネットVPNの導入メリット（後編）
前編「リモートアクセスのセキュリティ対策」では、RAS接続とインターネットVPN、IP-VPNサービスをレビューすることで、IPsec技術が何を実現できるのか、その適用の可能性を記述した。後編としては、企業がVPNゲートウェイを導入する場合に検討すべきポイントについて考えてみる。今回検討するのは以下のポイントである。
- 導入目的に応じたソリューション要件
- VPNゲートウェイ（暗号化／復号）のスループット
- VPN環境の可用性
- VPNゲートウェイの設置場所
導入目的に応じたソリューション要件
当然のことであるが、最初に何を目的にVPN環境を構築するのかを明確にしておく必要がある。VPNの利用形態には、企業間あるいは組織間を接続するサイト間接続タイプと外出中の社員に企業内のイントラネットへのアクセス環境を提供するリモートアクセスタイプがある（図1）。構築するVPN環境のタイプによって導入するVPNゲートウェイに求められる要件も異なる。
図1 イントラネットへのアクセス環境を提供するリモートアクセスタイプ●サイト間接続タイプのVPN環境に求められる要件
・接続する組織間のデータ通信処理のスループット
サイト間接続タイプではネットワーク間を接続するため、ネットワーク上に存在するサーバ間の通信すべてに対して暗号化／復号処理が適用される。
・ 24時間365日、安定した接続性を維持する可用性
・対抗するVPNゲートウェイとの接続性
IPsecの仕様自体がVPNゲートウェイ間の接続を前提に標準化されているという経緯があるため、サイト間接続タイプで利用する異なるベンダ製のVPNゲートウェイの相互接続性が確認されている場合が多い（日本ネットワークセキュリティ協会が相互接続性実証実験を実施した結果を「PKI環境下のIPsec相互接続に関する調査」としてIPAのWebサイトに掲載しているので参考にするとよいだろう）。
●リモートアクセスタイプのVPN環境に求められる要件
最近では、通常の利用方法として社外から組織内のイントラネット上にあるサーバにアクセスしている企業が多く見受けられる。そのため、スループットや可用性についてはサイト間接続タイプと同様の要件が求められる。それに加えてリモートアクセスタイプでは下記の要件が求められる。
・VPNクライアントのマルチプラットフォーム対応
企業内で使用されているOSプラットフォームに幅広く対応している必要がある。
・NAT環境への対応
現在のIPsecの仕様において、NAT環境への対応はまだ標準化されていない。米国などの広いアドレス空間を利用できる環境ではあまり問題とならないが、少なくとも日本ではリモートアクセスクライアントがプライベートアドレスを割り当てられるケースが多いため、必須の要件と考えられる。
・利用者の認証
サイト間接続タイプでは接続相手の認証にはIPアドレスが使用される。リモートアクセスタイプではエンドユーザーのVPNクライアントのIPアドレスではなくユーザー固有の情報（ユーザー名やメールアドレスなど）を使用することになるが、ユーザー認証については現在のところIPsecの仕様として標準化されておらず、インターネットドラフトである。しかし、リモートアクセスタイプでは利用者認証は必須となるため、導入予定のソリューションがどのような実現方式であるかを事前に確認しておく必要がある。
・イントラネット情報の割り当て
通常VPN経由 でアクセスする接続先は組織内のサーバであり、それらは当然ISPが提供するDNSには登録されていない。そのため、VPN接続時にVPNゲートウェイからイントラネットのDNSサーバの情報を通知する必要がある。 また、リモートアクセスクライアントは通常任意のIPアドレスを利用するアクセスインフラ（ダイアルアップやWiFiなど）により割り当てられるため、VPNゲートウェイからでたパケットの送信元アドレスは任意のアドレスとなる。そのため、ネットワーク管理者としては、VPN経由の応答パケットを確実時にVPNゲートウェイに戻すような経路制御と利用者単位のアクセス制御が困難となる。これを解決するために、DHCPのような機能が必要となる。
・VPNゲートウェイとの接続性
NAT対応や利用者認証は現在インターネットドラフトであるため、各ベンダでの実現方式が異なっている。そのために、相互接続性の動作検証を実施する必要がある。
・ほかの通信系ソフトウェアとの相性
VPNクライアントソフトウェアによっては、ほかの通信ソフトウェアと競合する場合がある。例えば、最近ではPPPoEクライアントなどである。
VPNゲートウェイのスループット
インターネットVPNの場合、VPNの実現にトンネリングと暗号化技術を使用している。VPNゲートウェイでは、該当するVPNドメインあてのパケットに対して暗号化および復号処理が実行される。暗号化／復号処理はCPU負荷が高い処理であり、VPNゲートウェイ上でCPU能力を必要とするほかのプロセスが存在する場合、CPU能力を取り合う形となりVPNスループットに直接影響する。1台のシステム中にVPN以外にファイアウォールやコンテンツフィルタリングなどの機能を同居させた製品では、導入する以前に実際の動作環境下でのスループットを測定する必要がある。カタログ上の性能値をうのみにしてはいけない。カタログスペックはVPN機能のみ有効にして測定している場合が多く、さらに最も性能が高くなるような暗号化アルゴリズムやパケットサイズを使用して測定されているからである。
安定したVPNスループットを実現するために、暗号化／復号処理に専用のCPU（ASIC）を採用する製品が多く見られるようになった。このような傾向はハードウェアアプライアンス製品に多い。ソフトウェア型のVPNゲートウェイには、ベンダから暗号化／復号専用のアクセラレータカードが提供されている。アクセラレータカードを利用する場合には、そのボードがどの暗号化アルゴリズムに対応しているのかを確認する必要がある。大抵のカードはDES／3DESに対応している。その理由としてDESが暗号化アルゴリズムの標準として採用されてきたことが背景にある。新しい暗号化アルゴリズムの標準としてAESが採用されたが、AESに対応したアクセラレータカードはマーケットでの選択肢は多くない。
最近のVPNゲートウェイでは、DES／3DESに加えてAES／Blowfish／CASTなど複数の暗号化アルゴリズムを採用している。AESはDESと比較すると処理が軽いアルゴリズムであるので、IPsecの暗号化をDESからAESに変更することでスループットを向上させることも可能である。アクセラレータカードが対応していないアルゴリズムを利用したい場合、SMPに対応したハードウェアをプラットフォームに利用する方法もある。
VPN環境の可用性
企業でVPN環境を構築する場合、24時間365日の接続性を要求される場合が多い。VPN環境の可用性については、VPNゲートウェイ自身の冗長性と利用するアクセス回線の冗長性の両面から検討する必要がある。VPNゲートウェイの冗長性は複数台のVPNゲートウェイをクラスタリングすることで実現される。クラスタリングのタイプにはホットスタンバイ型とロードバランシング型がある（図2）。
図2 VPNゲートウェイのクラスタリングのタイプホットスタンバイ型では複数のVPNゲートウェイの中の1台（プライマリノード）が実際にVPN接続処理を実行し、他ノード（セカンダリノード）は待機状態にある。プライマリノードが何らかの理由でサービスを停止した場合は、セカンダリノードがVPN接続処理を引き継ぐ。ロードバランシング型は複数ノードが同時に稼働状態となり、VPN接続処理を負荷分散しながら動作する。仮にVPN接続処理を実行しているノードが停止した場合は、ほかのノードのいずれかがその処理を引き継ぐ。どちらのタイプでも利用者からはノードの切り替え処理は透過的に実行されるべきである。つまり、利用者が接続中のVPN接続は切断されることなくノード間でフェイルオーバーされる（ステートフルフェイルオーバーという）。ステートフルフェイルオーバーを実現するためには、複数ノード間でVPN接続のSA情報（SecurityAssociation）が共有されている必要がある。そのため、複数のノード間で処理情報を共有するためにハートビートネットワークという独立したネットワークを用意する必要である。
VPNゲートウェイの冗長性に加えて、アクセス回線の冗長性を検討する必要がある。通常のインターネットVPN環境では、1つのISP接続を利用して構築している。この環境では何らかの原因でISP回線に不具合が発生した場合はVPN環境を利用できない。現在ではアクセス回線に対する可用性を実現するために、複数のアクセス回線を利用してインターネットVPN環境を構築するためのソリューションが利用できる（図3）。
図3 アクセス回線に対する可用性の実現方法図3のタイプAのようにVPNゲートウェイ自身が複数のアクセス回線を認識できるものと、タイプBのようにVPNゲートウェイの手前に回線専用の負荷分散装置を配置するものがある。両者の相違点は、タイプＡが回線状態とIPsecSAを監視できるのに対して、タイプBは回線状態のみを監視している点である。さらにタイプAではVPNゲートウェイをクラスタリングすることで、VPNゲートウェイとアクセス回線の両方を１つのソリューションで実現することが可能である。
VPNゲートウェイの設置場所 〜 どこからどこまで守るのか
VPNトンネル内で送受信されるデータの重要性がVPN環境の構築に影響する。VPNゲートウェイの背後では、情報は暗号化が解かれた状態（平文）でネットワーク上を送受信されるため、パケット解析ソフトウェアなどを使用した盗聴などの攻撃には全くの無防備である。そのため、暗号化される区間をどこからどこまでとするのかを明確にしておく必要がある。
実際にVPN環境を構築するためにVPNゲートウェイをネットワーク上に設置する方法は2つ存在する（図4）。企業で導入しているファイアウォールが有するVPN機能を使用する方法とVPN専用機器を使用する方法である。ファイアウォール同居型ではVPN接続のエンドポイントはすべてファイアウォールとなり、VPNトンネル内を通過してきたパケットはすべて復号される。つまり、接続先相手からVPNゲートウェイまでが暗号化区間となり、VPNゲートウェイから目的のサーバまでは保護されない区間となる。そのため、VPNゲートウェイの背後では、通信内容を解析することが可能となる。
図4 VPNゲートウェイをネットワーク上に設置する2つの方法アクセス先のサーバまでの区間を保護する必要がある場合は、サーバが存在しているネットワークにVPN専用機器を導入する方法がある。これにより、接続先相手から目的のサーバまでの間を保護することが可能となる。この場合、VPNゲートウェイと接続先との間にファイアウォールが存在するため、ファイアウォールにIPsecのパケットが通過できるためのルールを追加する必要がある。具体的には、以下のルールである。
| プロトコル | プロトコルID | ポート番号 |
|---|---|---|
| IKE | UDP（17） | ポート500 |
| ESP | 50 | --- |
| AH | 51 | --- |
上記のルールは、IPsecの標準化がVPNゲートウェイ間の接続を前提としているためVPNゲートウェイ間の接続の場合に一般的に利用されるものである。これに対して、リモートアクセスタイプのVPN環境の場合、NAT環境への対応や利用者認証などの仕様がインターネットドラフトのレベルであるため、各ベンダにより実現方法が異なっている。実際にNAT環境への対応について、現在多くのベンダが参照しているインターネットドラフトは以下の2つのドキュメントである（これ以外のベンダ独自の仕様を採用している製品もある）。
- NAT-Traversal（draft-ietf-ipsec-nat-t-ike）
- UDP Encapsulation（draft-ietf-ipsec-udp-encaps）
上記のインターネットドラフトには複数のバージョンが存在し、ベンダによって実現時に参照しているドラフトのバージョンが異なっている。これが、異なるベンダ製のVPNクライアントソフトウェアとVPNゲートウェイが接続できない大きな理由である。
最新のインターネットドラフトに基づいた実現をしているVPNクライアントとVPNゲートウェイを使用しているのであれば、UDP（PORT 500）をファイアウォールのルールとして許可していればよい。
今回は企業がVPNゲートウェイを導入する際の製品の選択ポイントについて考察してきた。
実際は、企業としてVPN環境を構築する目的のために必要な機能と、それを実現するために必要となるコストをはかりにかけて検討することとなる。また、リモートアクセスタイプのVPN環境では、エンドユーザー端末が直接VPNのエンドポイントとなる。特にIPsecでは、エンドユーザー端末に導入するVPNクライアントソフトウェアの設定条件や設定内容が複雑となるため、ユーザー教育やサポートが必要不可欠となり、企業としては機能面のみでなく運用面に対してもエンドユーザーに可能な限り負荷がかからないようなソリューションを導入する必要がある。エンドユーザーの負荷を軽減することは、企業におけるVPN環境の運用サポートの負荷軽減（サポートコスト削減）につながることを踏まえてほしい。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。