異機種間のIPSecVPN構築の注意点：VPNの実力を知る（前編）

　国内でインターネットVPNが一般的に使用されるようになった今日、VPN対応製品としてIPSecを実装した製品が数多く市場に出回っており、大企業向けの高性能・高機能な製品から個人でも手が届くブロードバンドルータまで多種多様である。

　そのような中、安価なブロードバンドルータをROBO（Remote Office／Branch Office）に設置し、企業（本社）側に高性能・高機能なVPN装置を設置するというような、異なるVPN装置を使用したサイト接続型のVPNを使用するニーズは少なくない。

　本特集ではこのように利便性が向上し、リモートアクセス時のセキュアな通信において必要不可欠となったVPNのその接続性について紹介する。まず前編では、異機種間のIPSec相互接続環境構築時および運用時の注意点に焦点を絞り解説する。

サイト接続型VPNを実現するVPN製品の分類

　国内で本格的にインターネットVPNが使用されるようになった2000年ごろはVPN装置というと高価なVPN専用装置か、ファイアウォールのオプション機能しかなく、それらのスループットはせいぜい10Mbps程度しか出なかった。しかも価格は100万円前後のものが中心で高額なものであった。

　しかし、現在では各種ベンダから用途に応じた製品が提供されており、サイト接続型VPNを実現する製品は大きく4種類に分類することができる。

●VPN専用機

　現在はどちらかというと少数派であるこのタイプの製品の特徴は、高スループットを実現するためにVPNの暗号処理をASICで行っているほか、高可用性を実現するために冗長機能を有していることである。また、多数のリモートアクセスユーザーのセンター機器としての利用も考慮され、認証機能が充実している。価格は数十万〜数百万円と幅広く、スループットと同時接続数により製品のレベルが分けられていることが多い。

●ファイアウォール一体型ハードウェア

　インターネット接続に必要なファイアウォールの機能とVPN装置を1台の筐体で実現できるため機器導入コストや管理負荷が軽減できるなどメリットが多い。このタイプは、現在最も多くインターネットVPNで使用されていて、製品は高スループットを実現するために暗号処理をASICで行っていることが特徴である。

　また、最近ではブロードバンドルータ機能を有したROBO向けの安価な製品も提供されている。価格は10万〜数百万円台と幅広く、主にファイアウォールとVPNのスループットにより製品レベルが分けられていることが多い。

●ファイアウォールソフトウェア

　ソフトウェアタイプの製品であるためコストパフォーマンスの良いIAサーバ機にプリインストールされたアプライアンス化されて製品が多いのが特徴である。最近ではIAサーバ機の処理速度が高いため、専用ASICを搭載したハードウェアタイプに匹敵するスループットを実現している。

　また、リモートアクセスユーザーのセンター機器として使用した場合、ファイアウォール一体型ハードウェアと比較して、認証機能が充実しているのも特徴である。価格は数十万〜数百万円と幅広いが、多くの場合VPN機能はファイアウォール機能のオプションとして扱われている。

●ブロードバンドルータ

　これまで説明したタイプの製品に比べ最も安価なタイプである。最近では3万円前後で購入可能なVPN機能搭載のブロードバンドルータが市場に出回っており、そのスループットも10Mbpsを超える。

　このタイプの製品の特徴としては、同時接続数が限られているほか、IKE^＊1認証は既知共有鍵（Pre Shared Secret方式）しかサポートしていないなど機能的な制限が多いことがある。しかし、最低限のファイアウォール機能も有しているため安価にVPN網を構築する際には最適の製品である。

事前検証のすすめ

　現在のVPN機器は異なる機器であっても接続は可能である。しかし、異なる機器間の相互接続を安定稼働させるには、事前に各機器の特徴を確認する必要がある。なぜならば、RFCで標準化されているIPSecプロトコルにはあいまいな記述が多く、その部分の実装が機器により異なるためである。実際に確認すべき項目を紹介しながら、その理由と手順について解説する。

（1）リキー（Re-Key）に関する調査

　同じ暗号鍵を使い続けると暗号鍵が漏えいする危険性が高くなる。そのため、SA^＊2には寿命（Life Duration）が設定されており定期的にSAを更新する。この動作をRe-Keyと呼び、一般的にSAが確立してからRe-Keyされるまでのタイミングをソフト有効期間（ソフトライフタイム）と呼び、機器に設定されたSAの寿命のことをハード有効期間（ハードライフタイム）と呼ぶ。

　ソフト有効期間があるのはIPSec SAだけである。いい換えるとIPSec SAはRe-Keyされるが、IKE SAはRe-Keyされずにハード有効期間を迎えると消去されるのである。

　相互接続を行う際には事前にソフト有効期間とハード有効期間を迎えた際の動作を確認しておくとよいだろう（図1）。

図1 ソフト有効期間（ソフトライフタイム）とハード有効期間（ハードライフタイム）

●IPSec SAに関する調査

　Re-Keyが行われ、新たなIPSec SAが確立するとVPN機器は古いSAと併せて複数のSAを持つことになる。一般的には新しいSAを使用する製品が多いが、例外的に古いSAを使用して通信を行う機器もあるためIPSec通信ができなくなる組み合わせもある。

　この調査では各機器のソフト有効期間と、Re-Key後に新しいSAを使用して通信を行うか、それとも古いSAを使用して通信を行うかを確認する。

●IKE SAに関する調査

　IKE SAのハード有効期間を迎えたときの動作は2つある。1つ目はIKE SAのハード有効期間を迎えてもIPSec SAは維持される。2つ目はIKE SAのハード有効期間を迎えると、そのIKE SAの保護下で確立したIPSec SAすべてが無効になる。どちらがよいかの議論はここでは行わないが、前者を採用している製品が多いようだ。

　ここでは、IKE SAのハード有効期間を迎えたときの動作を確認するとともに、後者（IKE SAのハード有効期間を迎えるとIPSec SAも無効になる）の実装をしている製品が、IPSec SAを無効にした際にDeleteペイロードを送信するか否かを確認し、送信している場合はそれを受信したVPN機器が対応するSAを削除するか否かを確認する。

　Deleteペイロードを送信し、それを受信した機器でSAが削除される場合は、その組み合わせでIKE SAに関する問題は発生しない。Deleteペイロードを送信しない場合や、Deleteペイロードを受信した機器がSAを削除しない場合は、不要なSAが残ってしまう。そのため、SA数に制限を持ったVPN機器の場合は新たなSAが確立できるだけの余裕を持った機器を選択すべきである（図2）。

図2 IKE SAハード有効期間を迎えたときの動作

（2）SA消去に関するテスト

　機器の故障や停電などの理由により通信相手のSAが消えてしまうことは十分に考えられる問題である。このとき、通信相手の機器の状態（電源）が回復してもSAは残っていないため、IPSec通信ができない状態に陥る。

　このように一方の機器がSAを持ち、もう一方の機器がSAを持たない状態（以下：SA情報の不一致）になった際に、どのようにすればIPSec通信が可能な状態に回復させることができるかを確認するのがこのテストである（図3）。

図3 SA情報の不一致

●テスト手順

• 手順1：
  製品Aと製品Bとの間で初期SAを確立したことを確認した後、製品AをリブートするなどしてSA1／SA2ともに削除する。製品BではSA1／SA2が残っていることを確認し製品A側のクライアントから製品B側のクライアントに対して通信を行う。
  
  
• 手順2：
  製品Aと製品Bとの間で初期SAを確立したことを確認した後、製品AをリブートするなどしてSA1／SA2ともに削除する。製品BではSA1／SA2が残っていることを確認し製品B側のクライアントから製品A側のクライアントに対して通信を行う。
  
  
• 手順3：
  製品Aと製品Bとの間で初期SAを確立したことを確認した後、製品BをリブートするなどしてSA1／SA2ともに削除する。製品AではSA1／SA2が残っていることを確認し製品A側のクライアントから製品B側のクライアントに対して通信を行う。
  
  
• 手順4：
  製品Aと製品Bとの間で初期SAを確立したことを確認した後、製品BをリブートするなどしてSA1／SA2ともに削除する。製品AではSA1／SA2が残っていることを確認し製品B側のクライアントから製品A側のクライアントに対して通信を行う。

　手順1と手順4で新たなSAが確立されIPSec通信が行えることが確認できた場合は、SAを削除した側から通信を行う運用をすれば障害を回避することができる。おそらくほとんどの組合せでSAが再確立できるはずである。しかし、例外的に新たなSAの確立に失敗しIPSec通信が行えない製品の組み合わせがある。このような組み合わせの場合、両方の機器をリブートしないとトラブルを回避できないため実際の運用には耐えられない。そのためこの組み合わせは使用すべきではない。

　手順2と手順3については、SAを持っているVPN装置側から通信を行うため、そのSAを使用してIPSecパケットを相手側に送信してしまう。しかし、IPSecパケットを受信したVPN装置はそのSAを理解できないため、「Invalid SPI エラー」が発生して通信が行えないことが多い。この状態に陥ると、SAを持っているVPN機器のIKE SAが削除されるまでこの状態が続く。

（3）設定変更時のSAに関する調査

　特に本社などのVPN通信が集中するセンターサイトでは、新たなVPNサイトが追加／削除されると必ずVPN機器の設定変更が発生する。設定変更により既存のSAが削除されるとSA情報の不一致が発生し、センターサイトからすべてのサイトに通信を行い新たなSAを確立する必要がある。

　この調査ではSAを確立した後で、架空のリモートサイト用のVPN設定を変更し、既存SAが削除されるかどうかを確認する。もしも、SAが削除される製品の場合、設定変更を行うたびにSA情報の不一致状態になるため、その製品はセンターサイトで使用すべき製品ではない。

製品選定について

　インターネットVPNを使用して大規模なVPN網を構築する場合、ハブ＆スポーク型かフルメッシュ型のいずれかのトポロジを採用することになるが、運用を含めたコスト面を考えるとハブ＆スポーク型の方が有利である。ここではハブ＆スポーク型のハブに当たるセンターサイトで使用する機器は、どのような視点で選択すべきかを解説する。

　ハブ＆スポーク型ではハブが落ちてしまうと、VPN網がダウンしてしまうため可用性を上げる必要がある。従って冗長化機能がある製品が望ましい。また、トラフィックが集中するため、高スループットであることが望ましい。ここまではよく知られた内容である。しかし、実際に運用をしてみるとそれ以外にも必要な機能がいくつかある。

（1）PeerごとのSA削除機能

　大規模なVPN網を運用した際に一番頭を悩ませるのが、前述の「事前検証のすすめの（2）SA消去に関するテスト」で説明したSA情報の不一致の状態である。このとき、SAがない方から通信を行えば新たなSAが確立しIPSec通信が可能となる組み合わせを使用していても、業務時間外などでユーザーがいない場合はこれを実施することができない。

　このような場合、センターサイトのVPN装置でSA情報の不一致状態が発生したサイトのSAだけを削除できれば、センターサイトからIPSec通信を復旧することが可能である。もしも、PeerごとにSAを削除する機能がなく、保持しているSAを一括でしか削除できなければ、SA削除により障害が発生していたサイトとの通信は回復することができる。

　しかし、それまで正常に通信できていたサイトすべてがSA情報の不一致状態となり被害が大きくなってしまう。従って、PeerごとにSAを削除できる機能はセンターサイトでは必須の機能の1つであると考える。

（2）SA一覧機能

　多くのリモートサイトが接続している環境で障害が発生した場合、障害発生サイトのSA状態をログから確認するのは非常に面倒である。従って、センターサイトのVPN装置の管理コンソールでSAの一覧を表示する機能があると便利である。この機能は必須ではないが実際に運用をすると非常に有用であるため実装している製品を選択するのが望ましい。

運用管理について

　最近のVPN装置は暗号処理などをハードウェアで行っているため、IPSecに関するすべての処理はハードウェアで行っていると思われがちだが、実際には複雑なソフトウェア処理を多く残している。そのため、VPN装置の運用管理も複雑なものとなっている。ここでは、VPN装置を運用管理する際のポイントについて解説する。

（1）バージョンアップについて

　VPN装置はセキュリティにかかわる技術を実装しているので、ソフトウェアやファームウェアは常に最新に保つ必要がある。従って、バージョンアップやパッチの適用は小まめに行うべきである。しかし、相互接続環境の場合は、最新のソフトウェアでIPSecに関する実装に手が加えられていると相互接続性に影響が出ることがあるため、最低限の動作検証をした後に実環境のVPN装置の確認作業を実施することを忘れてはならない。

（2）アクセスログについて

　「どこのサイト」と「いつ」「どのような方法」でVPN接続したかを把握するためにアクセスログの収集と分析が重要である。また、VPN装置へはインターネットから直接アクセスできるため、いつどこから不正なアクセスがあるか分からないので、VPN以外からのアクセスログの収集、分析も忘れてはならない。

　また、センターサイトのVPN装置では定期的にログ解析が行われているが、リモートサイトのログ管理は意外に実施されていないことが多い。ほとんどのVPN装置ではsyslogサーバにアクセスログを転送できるので、この機能を使用してセンターサイトにログを集中させるなどして、リモートサイトのVPN装置のログ解析も必ず実施してほしい。

（3）SAについて

　VPNを運用管理する際に忘れてはならないのがSAの管理である。特にSAの数は正確に把握しておかなければならない。SAの数によって接続しているリモートサイト数が把握できるほか、VPN装置に掛かる負荷を確認することができる。

　SAの数が多くなるとパフォーマンスが劣化するほか、SA数に制限があるVPN装置ではその制限を超えると新たなSAが確立できなくなる。特に相互接続環境では、前述の「事前検証のすすめ（1）リキーに関する調査」で解説したようにRe-Keyの際に古いSAが残る可能性があるので十分に注意して管理してほしい。

今後の相互接続性について

　異なる機種間の相互接続性はRe-Keyに関する部分の実装やSA情報の不一致状態についてまだ問題が残っているが、事前に検証を行い各製品の実装を把握しておけば多くの問題は運用でカバーできるレベルである。運用時に一番問題となるSA情報の不一致状態に陥ることがないよう、現在IETFでは「A Traffic-Based Method of Detecting Dead IKE Peers」が標準化の最終段階に入っている。このドラフトでは、VPN通信を行う装置間でKeepAliveパケットをやりとりし、それが途絶えたらIKEネゴシエーションを最初から行うよう記述されている。

　一部の機器ではすでに実装されているが、各社独自の実装をしているため互換性がないのが現状である。従って、相互接続環境では使用できないが、標準化された内容を各社実装することで運用に関する大きな問題がクリアされ相互接続はより容易に実施できるようになると思われる。