(57)【要約】【課題】従来のVPNシステムの、VPN接続要求によってサービス不能となるようなシステムの安全性に関わる問題や、ユーザの利便性に関わる問題を解決する。【解決手段】インターネット上のGK １００が発信元端末、着信先端末を認証し、その認証結果に基づいて発信元端末と着信先端末間のVPN接続を行い、VPN接続中は発信元端末と着信先端末間にて直接通信を行う。また、発信元端末から着信先端末に対するVPN接続要求が生じた場合に、GK １００、及び、着信先端末の両方においてVPN接続可否判定（Ｓ００６、Ｓ００８）を行う。【選択図】図６
2005311507.tif 000002
【特許請求の範囲】
【請求項１】
インターネット上の仲介サーバが発信元端末、着信先端末を認証し、その認証結果に基づいて発信元端末と着信先端末間のVPN接続を行い、VPN接続中は発信元端末と着信先端末間にて直接通信を行うVPN通信方法において、
前記発信元端末から前記着信先端末に対するVPN接続要求が生じた場合に、前記仲介サーバ、及び、前記着信先端末の両方においてVPN接続可否判定を行う
ことを特徴とするVPN通信方法。
【請求項２】
前記発信元端末が前記着信先端末に対してリモートアクセスVPN接続かLAN間VPN接続かを選択できることを特徴とする請求項１に記載のVPN通信方法。
【請求項３】
前記発信元端末から前記着信先端末へのVPN接続要求に対し、その都度、前記着信先端末においてVPN接続のための共有鍵を生成し、前記仲介サーバを経由して前記発信元端末へ受け渡すことを特徴とする請求項１に記載のVPN通信方法。
【請求項４】
前記発信元端末と前記着信先端末のユーザネットワーク同士によるVPN接続時のアドレス衝突を回避するためのネットワーク情報の交換を、前記仲介サーバを経由したシグナリングに重畳して行うことを特徴とする請求項１に記載のVPN通信方法。
【請求項５】
前記発信元端末と前記着信先端末のVPN接続時に、お互いのユーザネットワーク内の端末情報のうち、相手と情報交換する端末を制限もしくは選択できることを特徴とする請求項１に記載のVPN通信方法。
【請求項６】
前記仲介サーバが前記発信元端末に対して、前記発信元端末からのVPN接続を許可している着信先端末のリストを生成し、オンラインで表示することを特徴とする請求項１に記載のVPN通信方法。
【請求項７】
前記発信元端末又は前記着信先端末以外の端末から前記仲介サーバへの操作を契機として、前記発信元端末と前記着信先端末間のVPN接続を開始する、もしくは、前記発信元端末と前記着信先端末間のVPN接続を終了することを特徴とする請求項１に記載のVPN通信方法。
【請求項８】
インターネットに接続される発信元端末と仲介サーバと着信先端末から構成されるVPNシステムにおいて、
前記発信元端末が、
前記仲介サーバに対して認証情報を通知する認証情報通知手段を有し、
前記仲介サーバが、
前記発信元端末から通知された認証情報に基づいて、本人性の認証を行う本人性認証手段と、
前記本人性認証手段により本人性が認証された場合に、前記発信元端末と前記着信先端末の間でのVPN接続可否の判定を行う第１の接続可否判定手段と、
前記第１の接続可否判定手段によって接続が認められた場合に、前記着信先端末に対して、VPN接続要求を通知するVPN接続要求通知手段とを有し、
前記着信先端末が、
前記VPN接続要求通知手段から通知されたVPN接続要求に基づいて、前記発信元端末と前記着信先端末の間でのVPN接続可否の判定を行う第２の接続可否判定手段とを有し、
前記第１の接続可否判定手段及び前記第２の接続可否判定手段の双方において接続が許可された場合に、前記発信元端末と前記着信先端末の間でVPN接続を行うことを特徴とするVPNシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は発信元と着信先間のインターネットVPN（Virtual Private Network）接続（以下、VPN接続）において、仲介サーバがPC端末、ルータを認識し、その認識結果に基づいてユーザ間のVPN接続を行い、VPN接続中はユーザ間にて直接通信を行うVPN通信方法及びVPNシステムに係わり、特に発信元からのVPN接続要求を可否判断するVPN通信方法及びVPNシステムに関する。
【背景技術】
【０００２】
任意の二者間（発信元、着信先）のVPN接続には、リモートアクセスVPNとLAN間VPNの二つの形態がある。
リモートアクセスVPNのネットワーク構成例を図１７に示す。リモートアクセスVPNは、発信元がＰＣ端末１０４、着信先がルータ１０２でVPN接続する場合の特殊な形態のことをいう。リモートアクセスVPN接続時には、接続前に着信先ユーザネットワーク１０７のアドレス空間中のＩＰアドレスを発信元に割当て、発信元でアドレス設定を行った後に接続を開始することになる。
発信元は、あたかも着信先ユーザネットワーク１０７内に発信元ＰＣ端末１０４があるような使用が可能である。リモートアクセスVPNの一般的な利用例として、社内LANのメールサーバやWebサーバに、外出先の端末からリモートアクセスする場合が挙げられる。
【０００３】
一方、LAN間VPN接続のネットワーク構成例を図１８に示す。LAN間VPNは、発信元、着信先がＰＣ端末（１０８〜１１０、１１１〜１１３）、ルータ（１０１、１０２）の全ての組み合わせで接続する形態のことを呼ぶ。LAN間VPN接続時には、発信元ユーザネットワーク１０６と着信先ユーザネットワーク１０７間のアドレス空間の衝突を回避するため、事前にお互いに異なるアドレス空間を設定している必要がある。例えば、発信元アドレス空間として１０．０．０．１〜１０．０．０．２５４の範囲を設定し、着信先アドレス空間として１９２．１６８．１．１〜１９２．１６８．１．２５４の範囲を設定することにより、お互いに衝突しないアドレス空間同士で接続するようにしていた。
LAN間VPN接続の一般的な利用例として、会社間のファイル交換や、VoIPに代表されるP2P接続が挙げられる。
従来のVPN接続では、リモートアクセスVPN、LAN間VPNのいずれか一方の形態をサポートする方式がとられている。
【０００４】
一般的なVPN接続のひとつである、共有鍵認証方式のIPsec接続を例にして、VPN接続の手順について説明する。
まず、発信元がVPN接続要求を着信先に対して送信する。着信先では、二者間であらかじめ設定した共有鍵をもとに発信元の本人性認証を行い、発信元を認証し、発信元からのVPN接続を許可する場合は、発信元に対して応答する。
ここでは、発信元でも共有鍵をもとにした着信先の本人性認証を行い、お互いに認証した時点で、VPN接続に必要なVPN接続情報を交換する。VPN接続情報の交換は、制御通信用のVPNトンネル（ISAKMP SA）を一時的に生成し、暗号化して行う。
【０００５】
VPN接続情報を交換した後は、新たにデータ通信用のVPNトンネル（IPsec SA）を生成し、交換したVPN接続情報を設定することによって、ユーザネットワーク内からのVPN接続を開始できる。ここで、お互いのユーザネットワークのアドレス空間情報は、あらかじめ設定しておく必要があり、ISAKMP SAを通じての交換は規定されていない。なお、IPsecについては、非特許文献１に記載されている。
【０００６】
以上説明してきたように、発信元と着信先のVPN接続においては、VPN接続を開始する前に、VPN接続要求の受け渡し、お互いの本人性認証、着信先でのVPN接続可否判定、VPN接続に必要なVPN接続情報の交換等の処理が必要となる。
また、本人性認証のための共有鍵やアドレス空間の情報は、接続先ごとにあらかじめ設定しておく必要がある。この前処理のうち、VPN接続要求の受け渡し、お互いの本人性認証を効率的に行う方法として、発信元と着信先の間に仲介サーバであるゲートキーパー（以下、GK）を設置する方法がある。
【０００７】
GKは、シグナリングによって発信元から着信先に対するVPN接続要求を仲介し、発信元の本人性を認証した上で、着信先へVPN接続要求を受け渡す。これによって、GKが認証できない発信元は、着信先に対してVPN接続要求を出せないので、なりすましを回避することができる点で効果がある。
そして、着信先へVPN接続要求を受け渡し、着信先側で実際にVPN接続を許可するか否かの判定を行うVPN接続可否判定を行った後、発信元と着信先間で直接VPN接続に必要なVPN接続情報を交換し、VPN接続を開始する。このように、仲介サーバを設置したVPNシステムによって、ユーザの認証に基づいたVPN接続を実現することができる。
【０００８】
しかしながら、仲介サーバを経由したVPNシステムは、前記のような過程を踏むために、以下の点で問題があった。
つまり、従来の仲介サーバを経由したVPNシステムでは、GKにおいてVPN接続可否判定を行うものがなかった。すなわち、発信元からのVPN接続要求に対し、GKにおいてVPN接続を許可するか否かを判定する機能を有するものはなかった。
また、これまでのVPN接続システムでは、GKにおいて、発信元の認証を行った後は、全てのVPN接続要求を着信先に対して受け渡していた。これによって、着信先に対して、同時に不特定多数の発信元からのVPN接続要求が発生した場合、従来方式では全てのVPN接続要求がGKを経由して着信先に受け渡されるため、GKと比較して処理能力が低い着信先では、大量のVPN接続要求を同時に処理しきれずに、サービス不能状態に陥ることがあり、システムの安全性に問題があった。
【０００９】
また、発信元から着信先に対してVPN接続要求を出す際に、リモートアクセスVPN接続するのか、LAN間のVPN接続をするのかを選択することができなかった点においてユーザの利便性に問題があった。
また、発信元と着信先とのVPN接続の際は、あらかじめ双方で設定した共有鍵を利用していたために、全てのVPN接続先との間に異なる共有鍵を設定しておく必要があり、VPN接続の設定が煩雑であるという点においてユーザの利便性に問題があった。
また、発信元と着信先のユーザネットワーク間のVPN接続において、アドレス空間の衝突を回避するために、お互いに割当てるアドレス空間情報は、接続先ごとにあらかじめ設定しておく必要がある点でユーザの利便性に問題があった。
【００１０】
また、従来のVPNシステムでは、発信元と着信先のユーザネットワーク間のVPN接続において、お互いのユーザネットワーク内の、全てのPC端末の情報を交換していた点でシステムの安全性に問題があった。
また、発信元からどの着信先にVPN接続できるのかといった接続可否情報を、発信元がオンラインであらかじめ知る方法がなかった点でユーザの利便性に問題があった。
【００１１】
また、VPN接続の開始は発信元から行い、VPN接続の終了は発信元と着信先のいずれか一方から行うというように、従来のVPNシステムでは発信元と着信先以外の第三者の操作を契機として、VPN接続の開始もしくは終了の制御ができなかった点でユーザの利便性に問題があった。
【非特許文献１】小早川知昭著、「IPsec徹底入門」、翔泳社
【発明の開示】
【発明が解決しようとする課題】
【００１２】
本発明は上記事情を考慮してなされたもので、その目的は、従来のVPNシステムのVPN接続要求によってサービス不能となるようなシステムの安全性に関わる問題や、ユーザの利便性に関わる問題を解決することにある。
【課題を解決するための手段】
【００１３】
請求項１に記載の発明は、インターネット上の仲介サーバが発信元端末、着信先端末を認証し、その認証結果に基づいて発信元端末と着信先端末間のVPN接続を行い、VPN接続中は発信元端末と着信先端末間にて直接通信を行うVPN通信方法において、前記発信元端末から前記着信先端末に対するVPN接続要求が生じた場合に、前記仲介サーバ、及び、前記着信先端末の両方においてVPN接続可否判定を行うことを特徴とする。
仲介サーバにおいてVPN接続を拒否した場合は、着信先端末までVPN接続要求を受け渡さずに、そのまま発信元端末へ拒否の旨を応答する。仲介サーバにおけるVPN接続可否判定で許可されたVPN接続要求だけが、着信先端末へ受け渡される。
【００１４】
請求項２に記載の発明は、請求項１に記載の発明において、前記発信元端末が前記着信先端末に対してリモートアクセスVPN接続かLAN間VPN接続かを選択できることを特徴とする。
VPN接続を開始する際に、発信元端末が着信先端末に対して、リモートアクセスVPN接続するか、LAN間VPN接続するか、を選択することができるようにする。
【００１５】
請求項３に記載の発明は、請求項１に記載の発明において、前記発信元端末から前記着信先端末へのVPN接続要求に対し、その都度、前記着信先端末においてVPN接続のための共有鍵を生成し、前記仲介サーバを経由して前記発信元端末へ受け渡すことを特徴とする。
発信元端末からの接続要求が着信先端末の接続可否判定で許可された時点で、その都度、着信先端末もしくは発信元端末もしくは仲介サーバにおいて、発信元端末と着信先端末間のVPN接続用の共有鍵を生成し、仲介サーバを経由して交換することによって、VPN接続を開始する前にあらかじめ着信先端末との間で共有鍵を設定しなくても済むようになる。
【００１６】
請求項４に記載の発明は、請求項１に記載の発明において、前記発信元端末と前記着信先端末のユーザネットワーク同士によるVPN接続時のアドレス衝突を回避するためのネットワーク情報の交換を、前記仲介サーバを経由したシグナリングに重畳して行うことを特徴とする。
発信元端末と着信先端末のVPN接続情報や、お互いのユーザネットワークに割当てるアドレス空間情報を、仲介サーバを経由したシグナリングに重畳して交換しあうことによって、VPN接続を開始する前にあらかじめ設定する必要がなくなる。
【００１７】
請求項５に記載の発明は、請求項１に記載の発明において、前記発信元端末と前記着信先端末のVPN接続時に、お互いのユーザネットワーク内の端末情報のうち、相手と情報交換する端末を制限もしくは選択できることを特徴とする。
発信元端末と着信先端末間の、ユーザネットワークの端末情報の交換において、発信元端末に対して公開する着信先端末の情報を制限、選択できるようにすることによって、隠蔽したい着信先端末の情報を発信元端末に通知する必要がなくなる。
【００１８】
請求項６に記載の発明は、請求項１に記載の発明において、前記仲介サーバが前記発信元端末に対して、前記発信元端末からのVPN接続を許可している着信先端末のリストを生成し、オンラインで表示することを特徴とする。
仲介サーバ内に登録されているVPN接続可否の情報から、発信元端末からのVPN接続を許可している着信先端末のリストを生成し、発信元端末に対してオンラインで表示する。
【００１９】
請求項７に記載の発明は、請求項１に記載の発明において、前記発信元端末又は前記着信先端末以外の端末から前記仲介サーバへの操作を契機として、前記発信元端末と前記着信先端末間のVPN接続を開始する、もしくは、前記発信元端末と前記着信先端末間のVPN接続を終了することを特徴とする。
仲介サーバに対して、発信元端末、着信先端末以外の第三者からの操作を許可することによって、発信元端末と着信先端末の間のVPN接続を第三者が制御できるようになる。
【００２０】
請求項８に記載の発明は、インターネットに接続される発信元端末と仲介サーバと着信先端末から構成されるVPNシステムにおいて、前記発信元端末が、前記仲介サーバに対して認証情報を通知する認証情報通知手段を有し、前記仲介サーバが、前記発信元端末から通知された認証情報に基づいて、本人性の認証を行う本人性認証手段と、前記本人性認証手段により本人性が認証された場合に、前記発信元端末と前記着信先端末の間でのVPN接続可否の判定を行う第１の接続可否判定手段と、前記第１の接続可否判定手段によって接続が認められた場合に、前記着信先端末に対して、VPN接続要求を通知するVPN接続要求通知手段とを有し、前記着信先端末が、前記VPN接続要求通知手段から通知されたVPN接続要求に基づいて、前記発信元端末と前記着信先端末の間でのVPN接続可否の判定を行う第２の接続可否判定手段とを有し、前記第１の接続可否判定手段及び前記第２の接続可否判定手段の双方において接続が許可された場合に、前記発信元端末と前記着信先端末の間でVPN接続を行うことを特徴とする。
【００２１】
本発明では、従来方法では着信先端末でのみ行われていたVPN接続可否判定を、仲介サーバでも行うようにした点、リモートアクセスVPNとLAN間VPNを選択できるようにした点において従来の方法と大きく異なる。
また、VPN接続の都度、発信元端末と着信先端末の間で共有鍵を生成する点、VPN接続情報やアドレス空間情報を、仲介サーバを経由したシグナリングに重畳して交換する点、VPN接続時に交換するユーザネットワーク内の端末情報を制限することができる点において従来の方法と大きく異なる。
更に、VPN接続が可能な着信先端末をオンラインで発信元端末に表示する点、発信元端末及び着信先端末以外の第三者によって発信元端末と着信先端末の間のVPN接続を制御できる点において従来の方法と大きく異なる。
【発明の効果】
【００２２】
請求項１に記載の発明によれば、発信元端末から着信先端末に対するVPN接続要求が生じた場合、仲介サーバ、及び、着信先端末の両方においてVPN接続可否判定を行うようにした。よって、仲介サーバと着信先の二段階のVPN接続可否判定を行うことにより、同時に不特定多数のVPN接続要求が来た場合に、仲介サーバである程度遮断でき、システムの安全性が向上する。
また、仲介サーバでは静的なVPN接続可否判定を行い、着信先端末では動的なVPN接続可否判定を行うというように、VPN接続可否判定に拡張性を持たせることができるため、着信先のVPNユーザの利便性が向上する。
【００２３】
また、請求項２に記載の発明によれば、発信元端末が着信先端末に対してリモートアクセスVPN接続を行うか、LAN間VPN接続を行うかを選択できるようにしたので、発信元端末のVPNユーザの利便性が向上する。
【００２４】
また、請求項３に記載の発明によれば、発信元端末から着信先端末へのVPN接続要求に対し、その都度、着信先端末においてVPN接続のための共有鍵を生成し、仲介サーバを経由して発信元端末へ受け渡すようにしたので、共有鍵を個別に管理する必要がなくなり、ユーザの利便性が向上する。
【００２５】
また、請求項４に記載の発明によれば、仲介サーバを経由したシグナリングに重畳して、VPN接続に必要なVPN接続情報やアドレス空間情報、端末情報等を交換するようにしたので、発信元端末と着信先端末の間でVPN接続のための事前設定処理が必要なくなり、VPN接続にかかる処理が軽減され、VPNユーザの利便性が向上する。
【００２６】
また、請求項５に記載の発明によれば、発信元端末と着信先端末の間で交換する端末情報に関して、接続先に合わせて公開する着信先端末の情報を制限、選択することができる。よって、必要以上にユーザネットワーク内の情報を公開せずにVPN接続が可能となるため、システムの安全性が向上する。
【００２７】
また、請求項６に記載の発明によれば、仲介サーバが発信元端末に対して、VPN接続可能な着信先端末の情報をオンラインで表示できるようにしたので、発信元端末のユーザに対する利便性を向上させることができる。
【００２８】
また、請求項７に記載の発明によれば、第三者による仲介サーバの操作を契機として、発信元端末と着信先端末の間のVPN接続等を制御できるようにした。よって、VPN接続の開始、切断等の制御に拡張性をもたせることができ、VPNユーザの利便性を向上させることができる。
【００２９】
また、請求項８に記載の発明によれば、仲介サーバと着信先端末で二段階のVPN接続可否判定を行うことにしたので、同時に不特定多数のVPN接続要求が来た場合に、仲介サーバである程度遮断でき、システムの安全性が向上させることができる。
【発明を実施するための最良の形態】
【００３０】
図１は、本発明の第１の実施形態によるVPNシステムの構成を示す概略図である。
本実施形態によるVPNシステムは、インターネット１０３上に設置された発信元ルータ１０１、着信先ルータ１０２、発信元PC端末１０４、着信先PC端末１０５、そしてGK １００から構成される。
【００３１】
図２は、本実施形態によるVPNシステムの発信元ルータ１０１及び着信先ルータ１０２の構成を示すブロック図である。
発信元ルータ１０１と着信先ルータ１０２は、それぞれ設定部（３０１、３１１）、接続可否判定部（３０２、３１２）、本人性を示す認証情報（３０３、３１３）、シグナリング部（３０４、３１４）、共有鍵生成部（３０５、３１５）、VPN接続部（３０６、３１６）、配下NW制御部（３０７、３１７）から構成される。
発信元ルータ１０１と着信先ルータ１０２の配下となる発信元ユーザネットワーク１０６と着信先ユーザネットワーク１０７には、ＰＣ端末（１０８〜１１０、１１１〜１１３）がそれぞれ1台以上接続される。
【００３２】
図３は、発信元PC端末１０４と着信先PC端末１０５の構成を示すブロック図である。
発信元PC端末１０４と着信先PC端末１０５は、それぞれ設定部（４０１、４１１）、接続可否判定部（４０２、４１２）、本人性を示す認証情報（４０３、４１３）、シグナリング部（４０４、４１４）、共有鍵生成部（４０５、４１５）、VPN接続部（４０６、４１６）から構成される。
【００３３】
図４は、GK １００の構成を示すブロック図である。
GK １００は認証部２０１、接続可否判定部２０２、シグナリング仲介部２０３、カスタマコントロール部２０４、ＤＢ ２０５から構成される。ＤＢ ２０５には、各ルータの認証情報、VPN接続情報、VPN接続可否情報などが記録される。ＤＢ ２０５には、図５に示すように、発信元に対して接続を許可する着信先のリストを記録しているアクセスリスト５００等が格納される。
【００３４】
図６は、本実施形態によるVPN接続処理を示すフローチャートである。
ステップＳ００１において、発信元ユーザネットワーク１０６（図２）のPC端末（１０８〜１１０）より、着信先ルータ１０２へのVPN接続要求が発生すると、発信元ルータ１０１の配下NW制御部３０７がVPN接続要求を受け取り、シグナリング部３０４へと受け渡す。
ここで、VPN接続要求の発生は、PC端末からの接続先指定によって発信元ルータ１０１が自動でVPN接続要求を発生させる方法と、PC端末上の専用アプリケーションでユーザが手動でVPN接続要求を発生させる方法がある。
【００３５】
また、ここではVPN接続要求の中には、リモートアクセスVPNかLAN間VPNかを示す情報を重畳するものとし、この設定は、発信元ルータ１０１の管理者があらかじめ設定部３０１に設定したVPN接続形態をもとに決定するか、もしくは、ユーザがPC端末上の専用アプリケーションでVPN接続要求を発生する際に、逐次指定できるものとする。
処理を受け渡された発信元ルータ１０１内のシグナリング部３０４はGK １００と通信を開始する。
【００３６】
ステップＳ００２において、GK １００内では発信元ルータ１０１内のシグナリング部３０４からの通信に対し、まず認証部２０１が発信元ルータ１０１の本人性認証を行う。認証は、発信元ルータ１０１内の認証情報をもとに行うものとし、発信元ルータ１０１の本人性が認証された場合は、ステップＳ００３でＹＥＳと判断され、GK １００内の接続可否判定部２０２に処理を受け渡す。認証されなかった場合は、ステップＳ００３でＮＯと判断され、ステップＳ００４に進む。ステップＳ００４では、発信元ルータ１０１内のシグナリング部３０４に認証失敗の応答を返し、ステップ００５に進む。ステップＳ００５では、全体の処理を終了する。
【００３７】
ステップＳ００６では、処理を受け渡されたGK １００内の接続可否判定部２０２が、発信元ルータ１０１のVPN接続要求が着信先ルータ１０２にVPN接続を許可されているか否かを判定する。このVPN接続の可否を判定は、あらかじめ着信先ルータ１０２の管理者がGK １００内のDB ２０５に設定した図５に示すようなアクセスリスト５００をもとに行う。
アクセスリスト５００を参照した結果、発信元から着信先へのVPN接続を許可している場合は、ステップＳ００６でＹＥＳと判断され、GK １００内のシグナリング仲介部２０３へ処理を受け渡す。
VPN接続を拒否する場合は、ステップＳ００６でＮＯと判断され、ステップＳ００４に進む。ステップＳ００４では、発信元ルータ１０１内のシグナリング部３０４に接続拒否の応答を返し、ステップＳ００５に進む。ステップＳ００５では、全体の処理を終了する。
【００３８】
ステップＳ００７では、処理を受け渡されたGK １００内のシグナリング仲介部２０３が、着信先ルータ１０２内のシグナリング部３１４に対し、発信元ルータ１０１のVPN接続要求を受け渡す。着信先ルータ１０２内のシグナリング部３１４では、発信元ルータ１０１からのVPN接続要求を着信先ルータ１０２内の接続可否判定部３１２に受け渡す。
ステップＳ００８では、着信先ルータ１０２内の接続可否判定部３１２が、発信元ルータ１０１のVPN接続要求を受け入れるか否かを判定する。この判定は、着信先ルータ１０２の管理者が、あらかじめ着信先ルータ１０２の設定部３１１に設定した、図５に示すようなアクセスリストをもとに行う。
【００３９】
アクセスリスト５００を参照した結果、接続を許可する場合は、ステップＳ００８でＹＥＳと判断され、着信先ルータ１０２内のシグナリング部３１４に処理を受け渡し、ステップＳ００９に進む。一方、着信先ルータ１０２の接続可否判定部３１２が接続を拒否した場合は、ステップＳ００８でＮＯと判断され、GK １００のシグナリング仲介部２０３を経由して、ステップＳ００４に進む。ステップＳ００４では、シグナリングにより接続拒否の応答が発信元ルータ１０１へ返される。その後、ステップＳ００５に進み、全体の処理を終了する。
【００４０】
ステップＳ００９では、GK １００のシグナリング仲介部２０３を経由して、シグナリングによって接続許可の応答を発信元ルータ１０１内のシグナリング部３０４に返す。ステップＳ０１４では、発信元が着信先からの応答を受け取る。
ステップＳ０１０では、VPN接続部間でVPN接続処理を開始する前に、着信先ルータ１０２の共有鍵生成部３１５で共有鍵を生成し、VPN接続情報やアドレス空間情報と同様に、シグナリングに重畳して交換する。
ステップＳ０１１及びＳ０１５では、各ルータのシグナリング部（３０４、３１４）間でVPN接続に必要なVPN接続情報やアドレス空間情報を、VPN接続要求のシグナリングに重畳して交換する。
【００４１】
また、ここで交換するアドレス空間情報は、発信元ルータ１０１の管理者が発信元ルータ１０１の設定部３０１に、着信先ルータ１０２の管理者が着信先ルータ１０２の設定部３１１に、それぞれあらかじめ設定した、図７に示すようなVPN接続先ごとの公開端末情報リスト７００をもとに、図８に示すVPN接続する相手へ公開する端末情報リスト８００が生成される。
なお、VPN接続先ごとの公開端末情報リスト７００に、VPN接続する相手の情報がなかった場合は、全ての端末情報を公開する等、デフォルトの設定に従うものとする。そして、発信元ルータ１０１と着信先ルータ１０２間でVPNに必要な情報が交換できた後は、ステップＳ０１２及びＳ０１６において、発信元ルータ１０１と着信先ルータ１０２のVPN接続部（３０６、３１６）間で直接VPN接続処理を行う。その後、ステップＳ０１３及びＳ０１７において、発信元と着信先との間でVPN接続を開始する。
【００４２】
なお、着信先ルータ１０２内の接続可否判定部３１２では、あらかじめ設定したアクセスリスト５００をもとに判定するのではなく、発信元ルータ１０１からのVPN接続要求が着信先ルータ１０２内のシグナリング部３１４に受け渡され、接続可否判定部３１２に受け渡された時点で、着信先ルータ１０２の管理者の意思で動的に接続可否判定をすることもできるものとする。
また、GK １００と着信先において、二段階の接続可否判定を行うにあたり、それぞれの判定は、異なる接続許可リストをもとに行うことも可能である。また、接続許可リストとしては、図９に示すように接続先名の他に接続可能な時間で指定したアクセスリスト５０１を用いることも可能である。この場合は、接続先名、接続要求を送出した時間、の両方の判定で許可した場合に、接続を許可するものとする。
【００４３】
また、着信先が着信先ルータ１０２ではなく、着信先PC端末１０５（図３）であった場合は、着信先PC端末１０５の接続可否判定部４１２においてVPN接続可否判定するものとする。着信先ルータ１０２と着信先PC端末１０５の構成は、配下NW制御部３１７が存在しない点が大きく異なる。着信先となる着信先PC端末１０５は着信先ルータ１０２の配下に接続されているか、インターネット１０３に直接接続されている状態で動作する。発信元も、着信先と同様に、発信元ルータ１０１ではなく発信元PC端末１０４である場合も本実施形態に含まれるものとする。
【００４４】
以上のような構造になっているため、発信元からのVPN接続要求を、GK １００と着信先の二段階でVPN接続可否判定できるようになり、VPN接続の形態がリモートアクセスVPNかLAN間VPNのいずれかを選択できるようになる。
また、VPN接続の度に、発信元、着信先間の共有鍵を生成し、交換することができ、VPN接続するユーザネットワークのアドレス空間情報をシグナリングに重畳して交換することができ、接続先と交換するユーザネットワーク内の端末情報を制限することができる。更に、発信元ユーザが簡単にオンラインで、VPN接続が可能な接続先の情報を得ることができる。
【００４５】
なお、二つのユーザネットワークの間でLAN間VPN接続する場合において、発信元ユーザネットワーク１０６と着信先のユーザネットワーク１０７のアドレス空間が衝突する問題の解決方法について図１０を用いて説明する。
図において、発信元のアドレス空間（１）と着信先のアドレス空間（３）はともに、１９２．１６８．１．１〜１９２．１６８．１．２５４であり衝突している。
そこで、VPN接続を開始する際には、発信元から（２）のアドレス空間（１９２．１６８．３．１〜１９２．１６８．３．２５４）を着信先に割り当てることを提案し、着信先は（４）のアドレス空間（１９２．１６８．４．１〜１９２．１６８．４．２５４）を発信元に割り当てることを提案する。もし、お互いのユーザネットワークのアドレス空間（（１）、（３））が等しくても、（１）と（２）、（３）と（４）が異なっていれば、アドレス空間を衝突させずに通信を行うことが可能である。
実際のVPN接続では、発信元が発信元ユーザネットワーク１０６内のアドレスを指定する場合は（１）を使用し、着信先ユーザネットワーク１０７のアドレスを指定する場合は（２）を使用する。（２）のアドレスは、着信先ルータ１０２で（３）に変換され、着信先ユーザネットワーク１０７内の端末（１１１〜１１３）と通信が可能となる。
同様に、着信先が着信先ネットワーク１０７内のアドレスを指定する場合は（３）を使用し、発信元ユーザネットワーク１０６のアドレスを指定する場合は（４）を使用する。（４）のアドレスは、発信元ルータ１０１で（１）に変換され、発信元ユーザネットワーク１０６内の端末
との通信が可能となる。
【００４６】
次に、図１１を参照して、本実施形態によるVPN接続処理のシーケンスを説明する。
ステップＳ１０１では、発信元が、GK １００に対して、VPN接続要求を受け渡す。ステップＳ１０２では、発信元からのVPN接続要求に応答して、GK １００が発信元に対して認証情報を要求する。ステップＳ１０３では、発信元がGK １００に対して認証情報を通知する。
ステップＳ１０４では、GK １００が発信元の本人性を認証する。その後、ステップＳ１０５で、発信元の着信先に対する接続可否の判定が行われる。発信元の着信先に対する接続が認められた場合には、ステップＳ１０６において、GK １００が着信先に対してVPN接続要求を受け渡す。
【００４７】
ステップＳ１０７では、着信先における接続可否判定が行われる。発信元の着信先に対する接続が認められた場合には、ステップＳ１０８において、着信先から発信元に対して応答要求を受け渡す。この着信先から発信元への応答要求に対して、ステップＳ１０９では、発信元から着信先に応答を返す。その後、ステップＳ１１０及びＳ１１１では、発信元と着信先の双方において公開端末リストが生成される。そして、ステップＳ１１２では、
発信元と着信先との間でVPN接続情報、アドレス空間の情報が交換される。
ステップＳ１１３では、着信先において共有鍵が生成される。その後、ステップＳ１１４において、着信先において生成された共有鍵が発信元に対して受け渡される。
ステップ１１５では、発信元と着信先との間で、VPN接続が開始される。
【００４８】
図１２は、本実施形態によるVPN接続先表示処理を示すシーケンス図である。
ステップＳ２０１では、着信先は、GK １００のカスタマコントロール部２０４に対して、VPN接続を許可する接続先の登録を要求する。
ステップＳ２０２では、GK １００のカスタマコントロール部２０４が、認証部２０１に処理を受け渡し、認証部２０１が着信先の本人性認証を行う。
ステップＳ２０３では、着信先の本人性認証が行われた場合は、カスタマコントロール部２０４に処理を受け渡す。カスタマコントロール部２０４は、DB ２０５に格納されている、図５に示すようなアクセスリスト５００に着信先へのVPN接続を許可する接続先を登録する。
【００４９】
ステップＳ２０４では、発信元は、GK １００に対して、VPN接続が可能な接続先リストを要求する。Webブラウザ等を通してGK １００のカスタマコントロール部２０４にアクセスすることを契機とする。
ステップＳ２０５では、要求を受けたカスタマコントロール部２０４が、認証部２０１に処理を受け渡す。GK １００の認証部２０１は、発信元の要求に対し、本人性認証のための認証情報を要求する。
ステップＳ２０６では、発信元がGK １００に対して認証情報を通知する。
【００５０】
ステップＳ２０７では、GK １００の認証部２０１が、発信元の本人性を認証する。認証部２０１において本人性が認証できた場合には、カスタマコントロール部２０４に処理を受け渡す。
ステップＳ２０８では、カスタマコントロール部２０４がDB ２０５で発信元からのVPN接続を許可している着信先をDB ２０５に格納されている各接続先のアクセスリスト５００（図５）から検索し、図１３に示すようなVPN接続が可能な接続先リスト６００を生成する。
ステップＳ２０９では、VPN接続が可能な接続先リスト６００（図１３）を、発信元のWebブラウザ等に表示する。
【００５１】
次に本発明の第２の実施形態によるVPNシステムを説明する。
図１４は、本発明の第２の実施形態によるVPNシステムでのVPN接続開始処理を示したシーケンス図である。
ステップＳ３０１、Ｓ３０２では、発信元と着信先がともに、GK １００のカスタマコントロール部２０４に対して、VPN接続の制御を許可する第三者の登録を要求する。
GK １００のカスタマコントロール部２０４は、認証部２０１に処理を受け渡し、認証部２０１が発信元、着信先の本人性認証を行う。
ステップＳ３０３では、発信元と着信先の本人性認証が行われた場合は、カスタマコントロール部２０４に処理を受け渡す。カスタマコントロール部２０４はDB ２０５に格納されている、図１５に示すようなVPN接続制御許可リスト９００に発信元、着信先のVPN接続の制御を許可する第三者を登録する。
【００５２】
ステップＳ３０４では、第三者が、Webブラウザ等を通じて、GK １００のカスタマコントロール部２０４に対して、任意の二者間（発信元、着信先）のVPN接続を要求する。GK １００のカスタマコントロール部２０４は認証部２０１に処理を受け渡す。
ステップＳ３０５では、認証部２０１が第三者の要求に対し、本人性認証のための認証情報を第三者に対して要求する。
ステップＳ３０６では、第三者がGK １００に対して認証情報を通知する。
ステップＳ３０７では、GK １００の認証部２０１が、第三者の本人性を認証する。認証部２０１において本人性が認証できた場合、接続可否判定部２０２に処理を受け渡す。
【００５３】
ステップＳ３０８では、接続可否判定部２０２がDB ２０５から、発信元と着信先が、第三者によるVPN接続の制御を許可しているか否かを判定する。VPN接続の制御を許可している場合は、シグナリング部２０３に処理を受け渡し、ステップＳ３０９及びＳ３１０において発信元ルータ１０１のシグナリング部３０４、GK １００から着信先ルータ１０２のシグナリング部３１４に対して、それぞれVPN接続要求を受け渡す。
それ以外の場合は、カスタマコントロール部２０４に処理を受け渡し、ステップＳ３１１において、Webブラウザ等を通じて処理失敗の旨を第三者に通知し、全体の処理を終了する。
【００５４】
ステップＳ３１２及びＳ３１３では、GK １００から処理を受け渡された発信元ルータ１０１、着信先ルータ１０２のシグナリング部（３０４、３１４）は、接続可否判定部（３０２、３１２）でそれぞれVPN接続可否判定を行う。その後、ステップＳ３１４及びＳ３１５において、その結果をGK １００に応答する。
発信元と着信先のお互いがVPN接続を許可している場合は、ステップＳ３１６において、発信元ルータ１０１と着信先ルータ１０２のシグナリング部（３０４、３１４）で、シグナリングに重畳してVPN接続情報、アドレス空間情報、端末情報リストを交換する。その後、ステップＳ３１７において、発信元と着信先との間でVPN接続部間で直接VPN接続を開始する。
VPN接続開始の情報は、カスタマコントロール部２０４が、Webブラウザ等を通じて第三者に通知する。
【００５５】
図１６は本発明の第２の実施形態によるVPNシステムでのVPN接続切断処理を示したシーケンス図である。
ステップＳ４０１、Ｓ４０２では、発信元と着信先はともに、GK １００に対して、VPN接続の制御を許可する第三者の登録を要求する。
ステップＳ４０３では、GK １００のDB ２０５に発信元、着信先のVPN接続の制御を許可する第三者を登録する。
ステップＳ４０４では、第三者が、Webブラウザ等を通じて、GK １００のカスタマコントロール部２０４に対して、任意の二者間（発信元、着信先）のVPN接続の切断を要求する。GK １００のカスタマコントロール部２０４は、認証部２０１に処理を受け渡す。
【００５６】
ステップＳ４０５では、認証部２０１が第三者の要求に対し、本人性認証のための認証情報を第三者に要求する。これに応答して、ステップＳ４０６では、第三者はGK １００に対して認証情報を通知する。
ステップＳ４０７では、第三者の本人性認証が行われる。GK １００の認証部２０１は、第三者の本人性が認証できた場合、接続可否判定部２０２に処理を受け渡す。
ステップＳ４０８では、接続可否判定部２０２がDB２０５から、発信元と着信先が、第三者によるVPN接続の制御を許可しているか否かを判定する。発信元と着信先が、第三者によるVPN接続の制御を許可している場合は、シグナリング部２０３に処理を受け渡す。その後、ステップＳ４０９では、GK １００が着信先ルータ１０２のシグナリング部３１４に対して、VPN接続の切断要求を受け渡すとともに、ステップＳ４１１において、着信先からGK １００に対して応答が返される。
それ以外の場合は、ステップＳ４１０において、カスタマコントロール部２０４に処理を受け渡し、Webブラウザ等を通じて処理失敗の旨を第三者に通知し、全体の処理を終了する。
【００５７】
GK １００から処理を受け渡された発信元ルータ１０１、着信先ルータ１０２のシグナリング部（３０４、３１４）は、ステップＳ４１２において、発信元ルータ１０１のシグナリング部３０４に対して、切断要求を受け渡す。これに応答して、ステップＳ４１３において、発信元ルータ１０１のシグナリング部３０４から、着信先ルータ１０２のシグナリング部３１４に切断要求を受け渡す。その後、ステップＳ４１４及びＳ４１５において、発信元と着信先間のVPN接続を切断する。
VPN接続切断の情報は、カスタマコントロール部２０４が、Webブラウザ等を通じて第三者に通知する。
【００５８】
なお、GK １００から発信元ルータ１０１のシグナリング部３０４に対して、VPN接続の切断要求を受け渡すことも本実施形態に含まれるものとする。
また、発信元自身、着信先自身が第三者として、上述のように、GK １００を通じてVPN接続を制御することも本実施形態に含まれるものとする。
以上のような構造になっているため、第三者によるGK １００への操作を契機として、発信元から着信先へのVPN接続を制御することができる。
【００５９】
以上説明してきた本発明の実施形態によるVPNシステムによれば、インターネットに接続した二者間（発信元、着信先）のVPN接続において、特に仲介サーバを設置し、仲介サーバが発信元、着信先を認証し、その結果に基づいてVPN接続を提供するVPNシステムに関して、従来方式では課題があったシステムの安全性確保やユーザの利便性向上を達成することができる。
また、発信元から着信先に対するVPN接続を許可するか否かという判定を、仲介サーバと着信先の二箇所で行うため、VPN接続可否判定方式によってシステムの安全性を確保することができる。
また、接続形態をあらかじめ選択する方式、二者間の共有鍵を逐次生成する方式、接続情報やネットワーク情報をシグナリングに重畳して交換する方式、VPN接続時にユーザネットワーク内の公開する端末を制限する方式、接続先情報のオンライン表示方式や第三者による接続制御方式を用いることにより、ユーザの利便性を向上することができる。
【図面の簡単な説明】
【００６０】
【図１】本発明の実施形態によるVPNシステムの構成図である。
【図２】本発明の実施形態による発信元ルータ１０１、着信先ルータ１０２の構成図である。
【図３】本発明の実施形態による発信元PC端末１０４、着信先PC端末１０５の構成図である。
【図４】本発明の実施形態によるGK １００の構成図である。
【図５】VPN接続可否情報であるアクセスリスト５００の例である。
【図６】本発明の第１の実施形態によるVPN接続処理のフロー図である。
【図７】VPN接続先ごとの公開端末情報リスト７００の例である。
【図８】VPN接続する相手へ公開する公開端末リスト８００の例である。
【図９】VPN接続可否情報であるアクセスリスト５０１の例である。
【図１０】アドレス空間の衝突を回避する方法を示す概略図である。
【図１１】本発明の第１の実施形態によるVPN接続処理のシーケンス図である。
【図１２】本発明の第１の実施形態によるVPN接続先表示処理のシーケンス図である。
【図１３】VPN接続が可能な接続先リスト６００の例である。
【図１４】本発明の第２の実施形態によるVPN接続開始処理のシーケンス図である。
【図１５】VPN接続制御を許可する第三者のリスト９００の例である。
【図１６】本発明の第２の実施形態によるVPN接続終了処理のシーケンス図である。
【図１７】従来のリモートアクセスVPNのネットワーク構成図である。
【図１８】従来のLAN間VPN接続のネットワーク構成図である。
【符号の説明】
【００６１】
１００・・・GK
１０１・・・発信元ルータ
１０２・・・着信先ルータ
１０３・・・インターネット
１０４・・・発信元PC端末
１０５・・・着信先PC端末
１０６・・・発信元ユーザネットワーク
１０７・・・着信先ユーザネットワーク
１０８〜１１３・・・ルータ配下のPC端末
２０１・・・認証部
２０２・・・接続可否判定部
２０３・・・シグナリング仲介部
２０４・・・カスタマコントロール部
２０５・・・DB
３０１、３１１・・・設定部
３０２、３１２・・・接続可否判定部
３０３、３１３・・・認証情報
３０４、３１４・・・シグナリング部
３０５、３１５・・・共有鍵生成部
３０６、３１６・・・接続部
３０７、３１７・・・配下NW制御部
４０１、４１１・・・設定部
４０２、４１２・・・接続可否判定部
４０３、４１３・・・認証情報
４０４、４１４・・・シグナリング部
４０５、４１５・・・共有鍵生成部
４０６、４１６・・・接続部
５００、５０１・・・アクセスリスト
６００・・・VPN接続が可能な接続先のリスト
７００・・・VPN接続先ごとの公開端末情報リスト
８００・・・公開端末リスト
９００・・・VPN接続制御を許可する第三者のリスト
【図１】
2005311507.tif 000003
【図２】
2005311507.tif 000004
【図３】
2005311507.tif 000005
【図４】
2005311507.tif 000006
【図５】
2005311507.tif 000007
【図６】
2005311507.tif 000008
【図７】
2005311507.tif 000009
【図８】
2005311507.tif 000010
【図９】
2005311507.tif 000011
【図１０】
2005311507.tif 000012
【図１１】
2005311507.tif 000013
【図１２】
2005311507.tif 000014
【図１３】
2005311507.tif 000015
【図１４】
2005311507.tif 000016
【図１５】
2005311507.tif 000017
【図１６】
2005311507.tif 000018
【図１７】
2005311507.tif 000019
【図１８】
2005311507.tif 000020