JP2007221740A - Ｖｐｎシステム利用時のｉｐアドレス競合回避策 - Google Patents

Abstract

【課題】ＶＰＮシステムを用いて多数のＬＡＮ同士、またはＬＡＮ上に存在するコンピュータ同士を接続すると、ＩＰアドレスの競合が発生し、通信に支障を来たす。
【解決手段】ＶＰＮ回線の収容方法をネットワーク機器、擬似ネットワークアダプタにて収容する方法ではなく、コンピュータ上で動作するアプリケーション毎に収容するという方法にすることにより、ＩＰアドレスの競合が通信に悪影響を及ぼさない様にする。
【選択図】図１

Description

本発明はＶＰＮシステム利用時のＩＰアドレス空間の利用法に関するものである。

インターネットのブロードバンド化、低価格化により、認証、暗号化技術を使ってインターネット上に仮想的な専用線を構築するシステムが普及してきた。
特許公開２００５−３１１５０７ 特許公開２００５−１４１６１２

しかし、ＶＰＮシステムでは現在のインターネットもしくはインターネットおよびＬＡＮにおいて主流であるＩＰｖ４という通信プロトコルを用いる事が一般的である。このＩＰｖ４では、コンピュータネットワーク上の各ノードの識別のためにＩＰアドレスという４オクテットのアドレスを使用している。
ＲＦＣ７９１

ＩＰｖ４にて使用されるＩＰアドレスは４オクテットであるため、およそ４３億個のアドレスしか表現する事が出来ず、全世界的にインターネットおよびＬＡＮが普及しつつある昨今ではその枯渇問題が不安材料になっている。

また、ＩＰｖ４ではＬＡＮ内で使用可能なＩＰアドレスとしてプライベートＩＰアドレスという物が定義されているが、これもおよそ１７００万個しか表現できない。しかも市販のルータのデフオルト値を用いて設定されたプライベートＩＰアドレスは設置場所同士で同じ範囲の物を使用しているケースが多い。

本来、プライベートＩＰアドレスはその事務所もしくは家庭という閉ざされたコンピュータネットワーク上でのみ使用するためのものであるため、他の事務所もしくは家庭でのＩＰアドレスと同じ物があっても互いに物理的に隔離されているので問題はない。しかし、ＶＰＮシステムにより事務所と事務所など２箇所以上の拠点を接続すると、双方のローカルエリアネットワークが接続されてしまうため、ＩＰアドレスが競合するノードが存在すると通信に支障をきたす。

従来のＶＰＮシステムの応用手段は、ルータ等のネットワーク機器にてＶＰＮ回線を収容し、ＬＡＮと相互通信をさせる方法か、コンピュータのＯＳに対して本物のインターネットもしくはＬＡＮのアダプタの振りをする擬似的なネットワークアダプタを用いてコンピュータのＯＳに対してＶＰＮ経由での通信機能を提供するという方法が主であった。しかし、この方法の問題点として、ＶＰＮ上にて使用されるＩＰアドレスと実際のインターネットもしくはＬＡＮにて使用されるＩＰアドレスが競合するという可能性があった。限られた数のＬＡＮ同士、もしくはＬＡＮ上のコンピュータ同士をＶＰＮにて相互に接続するという場合、かつ全てのＬＡＮのＩＰアドレス運用方針を変更できる場合には、綿密なアドレス運用計画を行いさえすればＩＰアドレスが競合するという問題は発生しないが、大規模にＶＰＮシステムを展開する場合や現在のＬＡＮのＩＰアドレス運用方針に対する変更が困難である場合、ＶＰＮシステムにてＬＡＮ同士、もしくはＬＡＮ上のコンピュータ同士を接続する事が不可能になるケースが存在する。図２ではＶＰＮにてＬＡＮ上のコンピュータ同士を相互に接続した際に、実際のＬＡＮ上のＩＰアドレスとＶＰＮ経由でのＩＰアドレスが競合し、通信に支障を来たすケースのネットワーク構成を表している。このケースでは図中のコンピュータＡ１から１０．０．０．１０というＩＰアドレスを持つコンピュータにデータを送信する際に、ＶＰＮ上のＩＰアドレス１０．０．０．１０を持つコンピュータＢに送っていいのか、ＬＡＮ上のＩＰアドレス１０．０．０．１０を持つコンピュータＡ２に送っていいのか分からなくなり、通信に支障を来たす。

本発明では、ＶＰＮ回線の収容方法をネットワーク機器、擬似ネットワークアダプタではなく、コンピュータ上で動作するアプリケーション毎にＶＰＮ専用の独立したプロトコルスタックおよびソケットライブラリを用いて収容する。

図１で示す様にＶＰＮ回線の収容方法をコンピュータ上で動作するアプリケーション毎とする事により、ＬＡＮ上のＩＰアドレスとＶＰＮ上のＩＰアドレスが競合してもＯＳレベルではＬＡＮ上での通信のみ、アプリケーションレベルではＶＰＮ上の通信のみを行うようになるため、ＬＡＮ上のＩＰアドレスとＶＰＮ上のＩＰアドレスが競合した場合でも通信が滞る事がなくなる。図１ではＶＰＮ上の通信を用いる通信アプリケーションＡのみがＶＰＮ上のＩＰアドレスを用いて通信を行い、ＬＡＮ上の通信を用いる通信アプリケーションＢはＬＡＮ上のＩＰアドレスを用いて通信を行う事を表している。

また、ＶＰＮ回線の収容方法として、ＶＰＮ専用の独立したプロトコルスタックおよびソケットライブラリをアプリケーションと同じ動作レベルにて実装するため、万が一ＶＰＮ回線収容部分のプログラムの瑕疵によって問題が生じてもＯＳ自体に危害を加える事がなくなる。

独立したソケットライブラリとこれを使用するアプリケーションとの間のインタフェースは図３に示す様に、ＯＳが提供する本物のソケットライブラリとこれを使用するアプリケーションとの間のインタフェースを模した形とする。これにより、既存アプリケーションにＶＰＮ通信機能を付加する際のプログラム修正を容易に行うことを可能とする。

独立したソケットライブラリはその下位層となるプロトコルスタックとして、独立したプロトコルスタックを利用する。このプロトコルスタックはＯＳが提供する本物のプロトコルスタックと違い、図３で示す様に下位部分にＶＰＮ通信機能を有する。

ここでは図４を提示しながら説明を行う。まずＳＩＰプロトコルに準拠したＩＰ電話クライアントアプリケーションをクライアントサイトに設置し、ＩＰ電話サーバシステムをセンターサイトに設置して運用を行うケースがある。またこのケースではクライアントサイトとセンターサイトの間はインターネットにて接続されている。この場合、ＩＰ電話クライアントアプリケーションとＩＰ電話サーバシステムが通信を行う場合、インターネットを中継する過程でＩＰアドレスをＬＡＮ上のものからインターネット上のものに変換して通信を行う必要があるのだが、ＳＩＰプロトコルではそのデータ中に自局のＩＰアドレス情報を持つという性質上、このネットワークアドレスの変換を通じた通信を行う場合には何らかの対策が必要である。この方法としては、ＳＴＵＮと呼ばれる方法、ＵＰｎＰと呼ばれる方法などいくつかの方法が存在するが、ＶＰＮを用いた方法も存在する。その際にクライアントサイトＡ、クライアントサイトＢ、クライアントサイトＣという３つのサイトの実際のＬＡＮにてそれぞれ、１０．０．０．１〜１０．２５５．２５５．２５４、１７２．１６．０．１〜１７２．１６．２５５．２５４、１９２．１６８．１．１〜１９２．１６８．１．２５４という範囲のＩＰアドレスを使用している場合、ＶＰＮ回線をネットワークアダプタにて収容する形だとほぼ全てのＩＰアドレス範囲が実際のＬＡＮ上で使用されている為、ＩＰアドレスの競合回避が難しい。しかし本発明の方法を用いる事で、実際のＬＡＮ上で使用されているＩＰアドレスと同じ範囲のＩＰアドレスをＶＰＮ上で使用しても問題なく通信を行うことが出来るようになる。
ＲＦＣ３２６１ ＲＦＣ３４８９

ＶＰＮは拠点間の接続目的だけでなく、ＬＡＮとインターネットの間に存在するネットワークアドレス変換に関する様々な不具合を解消するＮＡＴトラバーサル目的、また旧来の非暗号化プロトコルをラッピングして転送するという目的を果たすため、今後益々普及して行くと思われる。特にＶＰＮの末端に位置するアプリケーションが不特定多数に提供される様なサービスを展開する事業者にとって、ＩＰアドレス競合の問題は避けては通れない問題となりつつある。その様な中で本発明の仕組みは産業上多くの利をもたらすと思われる。

アプリケーション毎のＶＰＮ回線収容を表す概略図 ローカルエリアネットワークとＶＰＮでのＩＰアドレス競合例 ＶＰＮ回線収容ライブラリの内部構造図 ＩＰ電話システムへの適用例

Claims (2)

1. ＯＳ自体の持つプロトコルスタックおよびソケットライブラリとは独立した形でＶＰＮ通信専用のプロトコルスタックおよびソケットライブラリを持ち。アプリケーションに対して、ＶＰＮ通信機能を提供する機能
2. ＶＰＮ通信専用のプロトコルスタックおよびソケットライブラリがＯＳの管理下で稼動するアプリケーションと同じレベルで動作する事により、万が一プログラムの瑕疵による障害が発生した場合でもＯＳの機能に影響を及ぼす事を防止する機能

Images