JP4789980B2 - トンネル通信システムおよび制御装置 - Google Patents

Description

本発明は、トンネル通信システムおよび制御装置に関する。

近年、遠隔地のネットワークに接続するサーバなどを利用することを目的として、端末が遠隔地のネットワークにアクセスする「リモートアクセス」のニーズが高まっている。中でも、外出先や出張先などの移動先のネットワークに接続する端末が、自宅や企業などの遠隔地のネットワークにアクセスする「移動対応のリモートアクセス」が注目されている。ここで、リモートアクセスとは、アクセス要求を送信する端末と、アクセス要求を受け付けるゲートウェイ装置との間にＶＰＮ（Virtual Private Network）が生成され、端末とゲートウェイ装置とがＶＰＮを用いてトンネル通信を行うことで実現される技術である。

例えば、非特許文献１には、端末およびゲートウェイ装置各々がＳＩＰ ＵＡ（Session Initiation Protocol User Agent）機能を備え、トンネル通信に先立って行われるＳＩＰ通信によって、ＶＰＮの生成やトンネル通信に必要なパラメータを交換することで、ＶＰＮを生成する手法が開示されている。

加藤淳也、水野伸太郎、川島正久、「ＳＩＰを用いた移動対応ＶＰＮ通信方式」、電子情報通信学会、２００７年９月 ＮＳ／ＩＮ／ＣＳ研究会、２００７年９月２０日発表

ところで、上記した従来の技術では、端末が、トンネル通信に先立って行われる通信（以下、適宜、ＶＰＮ生成手順と呼ぶ）のための専用アプリケーションを備えていることが必須であるという課題があった。例えば、非特許文献１に開示されている技術では、端末が、ＳＩＰ ＵＡ機能の専用アプリケーションを備えていることが必須であった。

そこで、本発明は、上記した従来の技術の課題を解決するためになされたものであり、端末がＶＰＮ生成手順のための専用アプリケーションを備えていなくても、リモートアクセスを実現することが可能なトンネル通信システムおよび制御装置を提供することを目的とする。

上述した課題を解決し、目的を達成するため、請求項１に係る発明は、アクセス要求を送信する端末が接続するアクセス網と当該端末のアクセス先となるアクセス先網とがＩＰレイヤでパケットを転送するＩＰ網に各々接続される状況の下、当該ＩＰ網かつ当該アクセス先網に接続して当該アクセス要求を受け付ける受付装置と当該端末との間で行われるトンネル通信を制御するトンネル通信システムであって、前記アクセス網かつ前記ＩＰ網に接続する制御装置は、前記端末との間で通信を行い、当該通信にて当該端末を認証することで、当該端末との間に認証済みのセッションを生成する第一のセッション生成手段と、前記第一のセッション生成手段によって生成されたセッションを用いて前記アクセス要求を前記端末から受信すると、当該アクセス要求を受け付ける受付装置を決定する受付装置決定手段と、前記受付装置決定手段によって決定された受付装置と前記端末との間のトンネル通信に必要なパラメータを決定し、当該パラメータを設定するパラメータ設定手段と、前記パラメータ設定手段によって決定されたパラメータを前記受付装置に送信する第一のパラメータ送信手段と、前記パラメータ設定手段によって決定されたパラメータを前記第一のセッション生成手段によって生成されたセッションを用いて前記端末に送信する第二のパラメータ送信手段と、前記端末または前記受付装置から送信されたトンネル通信のパケットを受信すると、当該パケットを転送する転送手段とを備え、前記端末は、前記制御装置との間で通信を行い、当該通信にて当該制御装置に認証されることで、当該制御装置との間に認証済みのセッションを生成する第二のセッション生成手段と、前記第二のセッション生成手段によって生成されたセッションを用いて、前記アクセス要求を前記制御装置に送信するアクセス要求送信手段とを備え、前記端末および前記受付装置各々は、前記パラメータ送信手段によって送信されたパラメータを用いてトンネル通信を行うトンネル通信手段と、を備えたことを特徴とする。

また、請求項２に係る発明は、アクセス要求を送信する端末が接続するアクセス網と当該端末のアクセス先となるアクセス先網とがＩＰレイヤでパケットを転送するＩＰ網に各々接続される状況の下、当該ＩＰ網かつ当該アクセス先網に接続して当該アクセス要求を受け付ける受付装置と当該端末との間で行われるトンネル通信を制御するトンネル通信システムにおける制御装置であって、前記制御装置は、前記アクセス網かつ前記ＩＰ網に接続するものであり、前記端末との間で通信を行い、当該通信にて当該端末を認証することで、当該端末との間に認証済みのセッションを生成する第一のセッション生成手段と、前記第一のセッション生成手段によって生成されたセッションを用いて前記アクセス要求を前記端末から受信すると、当該アクセス要求を受け付ける受付装置を決定する受付装置決定手段と、前記受付装置決定手段によって決定された受付装置と前記端末との間のトンネル通信に必要なパラメータを決定し、当該パラメータを設定するパラメータ設定手段と、前記パラメータ設定手段によって決定されたパラメータを前記受付装置に送信する第一のパラメータ送信手段と、前記パラメータ設定手段によって決定されたパラメータを前記第一のセッション生成手段によって生成されたセッションを用いて前記端末に送信する第二のパラメータ送信手段と、前記端末または前記受付装置から送信されたトンネル通信のパケットを受信すると、当該パケットを転送する転送手段と、を備えたことを特徴とする。

また、請求項３に係る発明は、上記の発明において、前記受付装置決定手段は、前記アクセス要求を受け付ける受付装置を識別する受付装置識別情報を受信すると、当該受付装置識別情報によって識別される受付装置を、当該アクセス要求を受け付ける受付装置として決定することを特徴とする。

また、請求項４に係る発明は、上記の発明において、前記端末を識別する端末識別情報と、前記受付装置を識別する受付装置識別情報とを対応づけて記憶する識別情報記憶手段をさらに備え、前記受付装置決定手段は、前記アクセス要求を送信した端末を識別する端末識別情報を特定し、当該端末識別情報を用いて前記識別情報記憶手段を検索することで、当該端末識別情報に対応づけて記憶されている受付装置識別情報を取得し、当該受付装置識別情報によって識別される受付装置を、アクセス要求を受け付ける受付装置として決定することを特徴とする。

また、請求項５に係る発明は、上記の発明において、パケットの正当性を検証可能な鍵情報を前記端末に送信する鍵情報送信手段と、前記鍵情報送信手段によって送信された鍵情報を用いて前記端末においてカプセル化されたトンネル通信のパケットを受信すると、当該鍵情報を用いて当該パケットを検証する検証手段とをさらに備え、前記転送手段は、前記検証手段によって検証されたパケットのみを前記受付装置に転送することを特徴とする。

また、請求項６に係る発明は、アクセス要求を送信する端末が接続するアクセス網と当該端末のアクセス先となるアクセス先網とがＩＰレイヤでパケットを転送するＩＰ網に各々接続される状況の下、当該ＩＰ網かつ当該アクセス先網に接続して当該アクセス要求を受け付ける受付装置と当該端末との間で行われるトンネル通信を制御するトンネル通信システムにおける制御装置が実行する制御プログラムであって、前記制御装置は、前記アクセス網かつ前記ＩＰ網に接続するものであり、前記端末との間で通信を行い、当該通信にて当該端末を認証することで、当該端末との間に認証済みのセッションを生成する第一のセッション生成手順と、前記第一のセッション生成手順によって生成されたセッションを用いて前記アクセス要求を前記端末から受信すると、当該アクセス要求を受け付ける受付装置を決定する受付装置決定手順と、前記受付装置決定手順によって決定された受付装置と前記端末との間のトンネル通信に必要なパラメータを決定し、当該パラメータを設定するパラメータ設定手順と、前記パラメータ設定手順によって決定されたパラメータを前記受付装置に送信する第一のパラメータ送信手順と、前記パラメータ設定手順によって決定されたパラメータを前記第一のセッション生成手順によって生成されたセッションを用いて前記端末に送信する第二のパラメータ送信手順と、前記端末または前記受付装置から送信されたトンネル通信のパケットを受信すると、当該パケットを転送する転送手順と、を制御装置に実行させることを特徴とする。

請求項１、２、または６の発明によれば、端末と受付装置との間に制御装置が介在し、端末と受付装置との間のパラメータ交換を仲介するので、端末がＶＰＮ生成手順のための専用アプリケーションを備えていなくても、リモートアクセスを実現することが可能になる。

また、請求項３の発明によれば、受信した受付装置識別情報によって受付装置を決定するので、制御装置は、端末識別情報と受付装置識別情報との対応関係といった利用者管理情報を保持する必要がなくなる。この結果、利用者が受付装置を変更するたびに制御装置側で利用者管理情報を更新することも不要となる。

また、請求項４の発明によれば、制御装置が、端末識別情報と受付装置識別情報との対応づけを記憶し、アクセス要求を送信した端末を識別する端末識別情報から受付装置識別情報を取得し、受付装置を決定するので、端末は、制御装置に受付装置識別情報を送信する必要がない。

また、請求項５の発明によれば、制御装置は、端末から送信されたトンネル通信のパケットについて、当該パケットが確かに端末から送信されたものであること、また、当該パケットが改竄されていないことなどを検証し、検証に成功したパケットのみを受付装置に転送するので、アクセス網区間についてのセキュリティを向上させることが可能になる。

以下に添付図面を参照して、本発明に係るトンネル通信システムおよび制御装置の実施例を詳細に説明する。なお、実施例を説明する前に、本発明の基本原理を説明する。

［基本原理］
図１を用いて、本発明の基本原理を説明する。図１は、基本原理を説明するための図である。なお、基本原理の説明においては説明の便宜上から例示を伴うが、本発明は、以下に例示する内容に限定されるものではない。

本発明に係るトンネル通信システムにおいては、図１に示すように、アクセスＬＡＮ（Local Area Network）と、アクセス先ＬＡＮとが、ＩＰ（Internet Protocol）レイヤでパケットを転送するＩＰ網に各々接続されている。また、トンネル通信システムは、アクセスＬＡＮに接続してアクセス要求を送信する端末と、ＩＰ網かつアクセス先ＬＡＮに接続して当該アクセス要求を受け付ける受付装置との間で行われるトンネル通信を制御するものである。なお、受付装置は、ＩＰ網かつアクセス先ＬＡＮに接続することで、ＩＰ網とアクセス先ＬＡＮとの間でパケットを送受信するものであるが、物理的に設置される場所としては、ＩＰ網側に設置される形態であっても、アクセス先ＬＡＮ側に設置される形態であっても、いずれでもよい。

また、本発明に係るトンネル通信システムには、アクセスＬＡＮかつＩＰ網に接続する制御装置が備えられる。なお、制御装置は、アクセスＬＡＮかつＩＰ網に接続することで、アクセスＬＡＮとＩＰ網との間でパケットを送受信するものであるが、物理的に設置される場所としては、アクセスＬＡＮ側に設置される形態であっても、ＩＰ網側に設置される形態であっても、いずれでもよい。

かかる制御装置は、Ｗｅｂポータル機能（Ｗｅｂサーバ機能）とＳＩＰ ＵＡ機能とを兼ね備え、端末に対してはＷｅｂポータル機能を用い、受付装置に対してはＳＩＰ ＵＡ機能を用いることで、端末と受付装置との間のパラメータ交換を仲介する。すなわち、図１に示すように、制御装置は、端末との間でＨＴＴＰ（HyperText Transfer Protocol）による通信もしくはＨＴＴＰＳ（ＨＴＴＰ Security）による通信を行い、受付装置との間でＳＩＰによる通信を行う結果、ＨＴＴＰによる通信もしくはＨＴＴＰＳによる通信とＳＩＰによる通信との間を制御装置が中継することにより、端末と受付装置との間にＶＰＮを生成する。一方、端末は、Ｗｅｂクライアント機能（Ｗｅｂブラウザ）を備え、受付装置とＳＩＰ通信をすることなく、制御装置とＨＴＴＰ通信もしくはＨＴＴＰＳ通信を行うだけで、受付装置との間のパラメータ交換を実現する。

上記した内容について具体的に説明する。まず、端末および制御装置は、相互にＨＴＴＰ通信もしくはＨＴＴＰＳ通信（以下、ＨＴＴＰ／ＨＴＴＰＳ通信と呼ぶ）を行い、ＨＴＴＰ／ＨＴＴＰＳ通信にて制御装置が端末を認証することで、端末と制御装置との間に認証済みのセッションを生成する（図１の（１）を参照）。

例えば、端末は、端末にインストールされたＷｅｂブラウザを起動し、制御装置のＵＲＬ（Uniform Resource Locator）にアクセスする。すると、制御装置は、端末に対してログイン画面を送信する。端末の利用者が、ログイン画面にＩＤおよびパスワードを入力することで、ＩＤおよびパスワードが制御装置に送信され、制御装置は、端末を認証する。続いて、制御装置は、端末に対してダイアルアップ用のフォーム画面を送信する。こうして、端末と制御装置との間で認証済みのセッションが生成される。

次に、端末が、制御装置との間で生成されたＨＴＴＰ／ＨＴＴＰＳ通信のセッションを用いて、アクセス要求を制御装置に送信する（図１の（２）を参照）。例えば、端末は、図１に示すようなダイアルアップフォーム画面に、『アクセス先番号』、『通信種別』、『帯域』を入力することで、アクセス要求を制御装置に送信する。

すると、制御装置は、アクセス要求を受信すると、受付装置を決定する（図１の（３）を参照）。例えば、制御装置は、アクセス要求とともに送信されたアクセス先番号によって識別される受付装置を、アクセス要求を受け付ける受付装置として決定する。

続いて、制御装置は、決定した受付装置と端末との間のトンネル通信に必要なパラメータを決定し、設定する（図１の（４）を参照）。また、制御装置は、決定したパラメータを受付装置に送信し、他方、端末との間で生成したセッションを用いてパラメータを端末に送信する（図１の（５）を参照）。

例えば、制御装置は、受付装置向けのトンネル通信用のＩＰアドレスやポート番号などを選択し、ＳＩＰ通信にて受付装置に送信する。すると、受付装置は、トンネル通信用のＩＰアドレスやポート番号などを、ＳＩＰ通信にて制御装置に送信する。続いて、制御装置は、端末向けのポート番号を選択し、ＩＰアドレスおよびポート番号を変換するＮＡＰＴ（Network Address Port Translation）を行うためのルールを生成する。また、制御装置は、選択したポート番号などを端末に送信する。

こうして、端末と受付装置との間にＶＰＮが生成され、端末および受付装置各々は、制御装置から送信されたパラメータを用いて、トンネル通信を行う（図１の（６）を参照）。

このように、本発明に係るトンネル通信システムは、まず、端末と受付装置との間でＳＩＰ通信がなされることなくＶＰＮが生成される点に特徴がある。言い換えると、端末と受付装置との間に、Ｗｅｂポータル機能とＳＩＰ ＵＡ機能とを兼ね備えた制御装置が介在し、端末と受付装置との間のパラメータ交換を仲介する点に特徴がある。かかる特徴により、端末は、ＳＩＰ ＵＡ機能を備える必要がなくなるのである。

また、本発明に係るトンネル通信システムは、制御装置と端末との間で行われる認証として、Ｗｅｂベースの認証を選択し得る点に特徴がある。すなわち、制御装置は、端末の接続回線によって端末を認証する回線ベースの認証などに限られず、柔軟なＷｅｂベースの認証によって端末を認証することも選択し得る。かかる特徴により、本発明に係るトンネル通信システムは、端末が固定回線に接続する場合のみならず、端末が移動し、移動先の回線に接続する場合にも対応することができるのである。

さらに、本発明に係るトンネル通信システムは、ＶＰＮの終端を端末にしている点に特徴がある。すなわち、制御装置は、自装置と受付装置との間にＶＰＮを生成するのではなく、端末と受付装置との間にＶＰＮを生成するように制御する。かかる特徴により、本発明に係るトンネル通信システムは、アクセスＬＡＮに接続する他端末までもが受付装置にリモートアクセスしてしまう事態を防ぐことができるのである。

このような基本原理を有するトンネル通信システムについて、以下、実施例１〜実施例４を説明する。実施例１は、トンネル通信がＩＰｓｅｃ（Security Architecture for Internet Protocol）によって実現される場合を説明する。実施例２は、トンネル通信がＳＳＬ（Secure Socket Layer）によって実現される場合を説明する。実施例３は、実施例１のトンネル通信システムにＳＲＴＰ（Secure Real-time Transport Protocol）による保護を行った場合を説明する。なお、実施例４は、その他の実施例である。

［実施例１に係るトンネル通信システムの構成］
まず、図２を用いて、実施例１に係るトンネル通信システムの構成を説明する。図２は、実施例１に係るトンネル通信システムの構成を示すブロック図およびプロトコルスタック図である。なお、以下では、各部を簡単に説明し、詳細については、後述する処理の手順において説明する。

図２に示すように、実施例１に係るトンネル通信システムは、プロキシ装置１０と、端末２０と、ＳＩＰダイアルアップゲートウェイ装置３０とを備える。なお、以下では、ＳＩＰダイアルアップゲートウェイ装置３０を、ＳＩＰダイアルアップＧＷ（GateWay）３０と呼ぶ。また、実施例１に係るトンネル通信システムは、アクセスＬＡＮとしてアクセス網（ＩＰ）を想定し、ＩＰ網として通信事業者の閉域ＩＰ網を想定し、アクセス先網として企業ＩＰ網を想定する。このようなトンネル通信システムにおいて、端末２０は、企業ＩＰ網に接続するサーバ４０にリモートアクセスしようとしている。以下、プロキシ装置１０、端末２０、ＳＩＰダイアルアップＧＷ３０の構成を順に説明する。

［プロキシ装置１０］
プロキシ装置１０は、汎用的なサーバなどであり、特に本発明に密接に関連するものとしては、図２に示すように、Ｗｅｂポータル部１１と、ＳＩＰ ＵＡ部１２と、パラメータ設定部１３と、ＵＤＰ（User Datagram Protocol）リレー部１４とを備える。

Ｗｅｂポータル部１１は、アクセス網（ＩＰ）に接続する端末２０に対してＷｅｂポータル機能（Ｗｅｂサーバ機能）を提供する部である。具体的には、Ｗｅｂポータル部１１は、端末２０との間でＨＴＴＰ／ＨＴＴＰＳ通信を行い、ＨＴＴＰ／ＨＴＴＰＳ通信にて端末２０を認証することで、端末２０との間に認証済みのセッションを生成する。また、Ｗｅｂポータル部１１は、端末２０から送信されたアクセス要求を受信する。また、Ｗｅｂポータル部１１は、アクセス要求とともに送信されたアクセス先番号によって識別される装置を、アクセス要求を受け付けるＳＩＰダイアルアップＧＷ３０として決定する。また、Ｗｅｂポータル部１１は、パラメータ設定部１３から伝達されたパラメータを、端末２０に送信する。なお、Ｗｅｂポータル部１１は、端末２０から受信した情報を、ＳＩＰ ＵＡ部１２やパラメータ設定部１３に伝達するなどする。

ＳＩＰ ＵＡ部１２は、ＳＩＰダイアルアップＧＷ３０との間でＳＩＰ通信を行う部である。具体的には、ＳＩＰ ＵＡ部１２は、Ｗｅｂポータル部１１から伝達されたアクセス先番号や、パラメータ設定部１３から伝達されたパラメータを用いて、ＳＩＰ通信にてＳＩＰダイアルアップＧＷ３０にパラメータを送信したり、ＳＩＰダイアルアップＧＷ３０から情報を受信する。なお、ＳＩＰ ＵＡ部１２は、ＳＩＰダイアルアップＧＷ３０から受信した情報を、パラメータ設定部１３に伝達するなどする。

パラメータ設定部１３は、トンネル通信用のパラメータを設定する部である。具体的には、パラメータ設定部１３は、Ｗｅｂポータル部１１から伝達された情報や、ＳＩＰ ＵＡ部１２から伝達された情報を用いて、パラメータを決定する。また、パラメータ設定部１３は、決定したパラメータを設定することで、端末２０とプロキシ装置１０との間、および、プロキシ装置１０とＳＩＰダイアルアップＧＷ３０との間に通信路を設定する。なお、パラメータ設定部１３は、決定したパラメータを、ＳＩＰ ＵＡ部１２やＷｅｂポータル部１１に伝達するなどする。

ＵＤＰリレー部１４は、ＵＤＰパケットを転送する部である。具体的には、ＵＤＰリレー部１４は、端末２０から送信されたＵＤＰパケットを受信すると、パラメータ設定部１３による設定に基づいて、当該ＵＤＰパケットを転送する。また、ＵＤＰリレー部１４は、ＳＩＰダイアルアップＧＷ３０から送信されたＵＤＰパケットを受信すると、パラメータ設定部１３による設定に基づいて、当該ＵＤＰパケットを転送する。

［端末２０］
端末２０は、汎用的なＰＣ（Personal Computer）などであり、特に本発明に密接に関連するものとしては、図２に示すように、Ｗｅｂブラウザ部２１と、トンネル通信部２２とを備える。

Ｗｅｂブラウザ部２１は、Ｗｅｂクライアント機能を有する部である。具体的には、Ｗｅｂブラウザ部２１は、プロキシ装置１０との間でＨＴＴＰ／ＨＴＴＰＳ通信を行い、ＨＴＴＰ／ＨＴＴＰＳ通信にてプロキシ装置１０に認証されることで、プロキシ装置１０との間に認証済みのセッションを生成する。また、Ｗｅｂブラウザ部２１は、アクセス要求をプロキシ装置１０に送信する。また、Ｗｅｂブラウザ部２１は、プロキシ装置１０から送信されたパラメータを受信する。なお、Ｗｅｂブラウザ部２１は、プロキシ装置１０から受信したパラメータを、トンネル通信部２２に伝達するなどする。

トンネル通信部２２は、ＳＩＰダイアルアップＧＷ３０との間でトンネル通信を行う部である。具体的には、トンネル通信部２２は、Ｗｅｂブラウザ部２１から伝達されたパラメータを用いてトンネル通信を行う。なお、実施例１におけるトンネル通信部２２は、トンネル通信をＩＰｓｅｃによって実現する。

［ＳＩＰダイアルアップＧＷ３０］
ＳＩＰダイアルアップＧＷ３０は、汎用的なサーバなどであり、特に本発明に密接に関連するものとしては、図２に示すように、ＳＩＰ ＵＡ部３１と、トンネル通信部３２とを備える。

ＳＩＰ ＵＡ部３１は、プロキシ装置１０との間でＳＩＰ通信を行う部である。具体的には、ＳＩＰ ＵＡ部３１は、ＳＩＰ通信にてプロキシ装置１０からパラメータを受信したり、プロキシ装置１０に情報を送信する。なお、ＳＩＰ ＵＡ部３１は、プロキシ装置１０から受信したパラメータを、トンネル通信部３２に伝達するなどする。

トンネル通信部３２は、端末２０との間でトンネル通信を行う部である。具体的には、トンネル通信部３２は、ＳＩＰ ＵＡ部３１から伝達されたパラメータを用いてトンネル通信を行う。なお、実施例１におけるトンネル通信部３２は、トンネル通信をＩＰｓｅｃによって実現する。

［実施例１に係るトンネル通信システムのプロトコルスタック］
次に、図２を用いて、実施例１に係るトンネル通信システムのプロトコルスタックを説明する。

まず、図２の（ａ）制御系（ＶＰＮ生成手順）の連携について説明する。図２に示すように、端末２０のプロトコルスタックは、『ＩＰ（アクセス網）』、『ＴＣＰ（Transmission Control Protocol）』、『ＨＴＴＰ／ＨＴＴＰＳ』、『ブラウザ表現レイヤ』で構成される。なお、『ブラウザ表現レイヤ』は、ＨＴＴＰ／ＨＴＴＰＳ上で動作するＷｅｂブラウザを表現するレイヤを意味する。また、『ＩＰ（アクセス網）』とあるのは、端末２０に付与されたＩＰアドレスが、アクセス網（ＩＰ）に接続するために付与されたＩＰアドレスであることを意味する。

一方、図２に示すように、ＳＩＰダイアルアップＧＷ３０のプロトコルスタックは、『ＩＰ（閉域網）』、『ＵＤＰ』、『ＳＩＰ』で構成される。なお、『ＩＰ（閉域網）』とあるのは、ＳＩＰダイアルアップＧＷ３０に付与されたＩＰアドレスが、閉域ＩＰ網に接続するために付与されたＩＰアドレスであることを意味する。

このように、端末２０およびＳＩＰダイアルアップＧＷ３０のプロトコルスタックは各々異なる構成であり、端末２０とＳＩＰダイアルアップＧＷ３０との間で制御系の情報を送受信することはできない。この点、図２に示すように、プロキシ装置１０のプロトコルスタックが、これらを仲介するように構成されていることで、制御系の連携を実現している。すなわち、プロキシ装置１０のプロトコルスタックは、端末２０と同じ構成のプロトコルスタックと、ＳＩＰダイアルアップＧＷ３０と同じ構成のプロトコルスタックとで構成されており、『ブラウザ表現レイヤ』との情報のやりとり、『ＳＩＰ』との情報のやりとりを制御プログラムが担うことで、連携を実現しているのである。

次に、図２の（ｂ）トンネルパケットの転送を説明する。図２に示すように、端末２０のプロトコルスタックは、『ＩＰ（アクセス網）』、『ＵＤＰ』、『ＩＫＥ（Internet Key Exchange）／ＮＡＴ−Ｔ（Traversal） ＩＰｓｅｃ』、『ｕｓｅｒＩＰ』で構成される。なお、『ｕｓｅｒＩＰ』とあるのは、端末２０に付与されたＩＰアドレスが、企業ＩＰ網に接続するためにＳＩＰダイアルアップＧＷ３０によって付与されたＩＰアドレスであることを意味する。

一方、図２に示すように、ＳＩＰダイアルアップＧＷ３０のプロトコルスタックは、閉域ＩＰ網側が、『ＩＰ（閉域網）』、『ＵＤＰ』、『ＩＫＥ／ＮＡＴ−Ｔ ＩＰｓｅｃ』、『ＩＰルーチング』で構成され、端末２０のプロトコルスタックとほぼ同様の構成である。すなわち、端末２０とＳＩＰダイアルアップＧＷ３０とは、トンネル通信のパケットを送受信し、カプセル化された情報を取り出すことができる。

この点、図２に示すように、プロキシ装置１０のプロトコルスタックは、『ＵＤＰ』の上位レイヤについては単に『ＵＤＰリレー』するのみである。すなわち、端末２０とＳＩＰダイアルアップＧＷ３０との間にＶＰＮが生成されていることがわかる。

［実施例１に係るトンネル通信システムによる処理の手順］
続いて、図３および図４を用いて、実施例１に係るトンネル通信システムによる処理の手順を説明する。図３は、実施例１に係るトンネル通信システムによる処理の手順を示すシーケンス図であり、図４は、Ｗｅｂダイアルアップ画面を説明するための図である。

図３に示すように、まず、端末２０は、端末２０にインストールされたＷｅｂブラウザ部２１を起動する。そして、Ｗｅｂブラウザ部２１は、プロキシ装置１０のＷｅｂポータル部１１との間でＨＴＴＰ／ＨＴＴＰＳ通信を行い、プロキシ装置１０のＵＲＬにアクセスする（ステップＳ１０１）。

例えば、Ｗｅｂブラウザ部２１は、『GET default.html』をＷｅｂポータル部１１に送信する。ここで、『GET』とは、ＷｅｂブラウザがＷｅｂサーバに対してＨＴＴＰリクエストを送信するための一般的なメソッドである。すなわち、Ｗｅｂブラウザ部２１は、Ｗｅｂポータル部１１に対して、『default.html』のファイルを送信するよう要求する。

すると、Ｗｅｂポータル部１１は、Ｗｅｂブラウザ部２１に、ログイン画面をＨＴＴＰ／ＨＴＴＰＳ通信にて送信することで、端末２０の利用者を認証するための情報を要求する（ステップＳ１０２）。例えば、Ｗｅｂポータル部１１は、端末２０の利用者にＩＤおよびパスワードの入力を促すログイン画面を送信する。

次に、Ｗｅｂブラウザ部２１は、送信されたログイン画面に利用者によってＩＤおよびパスワードが入力されるなどすることで、ＩＤおよびパスワードを、Ｗｅｂポータル部１１に送信する（ステップＳ１０３）。こうして、Ｗｅｂブラウザ部２１は、端末２０の利用者を認証するための情報を、Ｗｅｂポータル部１１にＨＴＴＰ／ＨＴＴＰＳ通信にて送信する。

続いて、Ｗｅｂポータル部１１は、Ｗｅｂブラウザ部２１から送信された情報を用いて端末２０の利用者を認証し、認証に成功すると、Ｗｅｂブラウザ部２１に、ダイアルアップフォーム画面をＨＴＴＰ／ＨＴＴＰＳ通信にて送信する（ステップＳ１０４）。こうして、Ｗｅｂブラウザ部２１とＷｅｂポータル部１１との間には、認証済みのセッションが生成される。

ところで、ダイアルアップフォーム画面とは、例えば、図４の（Ａ）に示すような画面である。図４の（Ａ）について説明すると、『お客様の利用ＩＤ』には、ステップＳ１０３においてＷｅｂブラウザ部２１から送信されたＩＤ『NO1234567』が表示されている。また、端末２０は未だダイアルアップしていないという意味で、『接続状態』は、『アイドル 0Mbps』と表示されている。また、実施例１におけるダイアルアップフォーム画面では、『接続先番号』、『通信種別』、『帯域』を、端末２０の利用者が入力可能な表示となっている。『接続先番号』とは、端末２０がリモートアクセスすることを要求しているＳＩＰダイアルアップＧＷ３０を識別する識別情報である。また、『通信種別』とは、トンネル通信をどの種別の通信で行うかを指定する情報である。また、『帯域』とは、トンネル通信に必要な帯域としてどのくらいの帯域を要求するかを指定する情報である。

図３に戻り、次に、Ｗｅｂブラウザ部２１は、送信されたダイアルアップフォーム画面に利用者によって各種情報が入力されるなどすることで、ダイアルアップ要求（アクセス要求）を、Ｗｅｂポータル部１１に、ＨＴＴＰ／ＨＴＴＰＳ通信にて送信する（ステップＳ１０５）。例えば、図４の（Ａ）の例で説明すると、Ｗｅｂブラウザ部２１は、ダイアルアップ要求を、接続先番号『0422-59-1111』と、通信種別『ＩＰｓｅｃ』と、帯域『１０Ｍｂｐｓ』とともに送信する。

すると、Ｗｅｂポータル部１１は、Ｗｅｂブラウザ部２１からダイアルアップ要求を受信すると、ＳＩＰダイアルアップＧＷ３０を決定する。続いて、パラメータ設定部１３が、ＳＩＰダイアルアップＧＷ３０に通知するパラメータを決定する。

例えば、Ｗｅｂポータル部１１は、Ｗｅｂブラウザ部２１からダイアルアップ要求とともに受信した接続先番号『0422-59-1111』で識別される装置を、ＳＩＰダイアルアップＧＷ３０であると決定する。そして、Ｗｅｂポータル部１１は、接続先番号『0422-59-1111』を、パラメータ設定部１３およびＳＩＰ ＵＡ部１２に伝達する。すると、パラメータ設定部１３は、ＩＰダイアルアップＧＷ３０に通知するパラメータとして、ＩＰアドレス『ＩＰ３』およびポート番号『Ｐｏｒｔ３』や、プロトコル『ＵＤＰ』を決定し、ＳＩＰ ＵＡ部１２に伝達する。

次に、プロキシ装置１０のＳＩＰ ＵＡ部１２は、パラメータ設定部１３によって決定されたパラメータを、ＳＩＰダイアルアップＧＷ３０のＳＩＰ ＵＡ部３１に、ＳＩＰ通信にて送信する（ステップＳ１０６）。例えば、ＳＩＰ ＵＡ部１２は、ＩＮＶＩＴＥメッセージを送信し、ＳＤＰ（Session Description Protocol）によってｍ行、ｃ行およびｂ行などを記述することで、パラメータを送信する。

ここで、ｍ行とは、一般に、『ｍ＝＜media＞＜port＞＜proto＞・・・』で定義されるものであり、左から順に、メディアタイプ、ポート番号、トランスポートプロトコルを意味する。図３の例では、『ｍ＝ａｐｐｌｉｃａｔｉｏｎ Ｐｏｒｔ３ ＵＤＰ』とあるが、これは、メディアタイプが『ａｐｐｌｉｃａｔｉｏｎ』（実施例１においては、ＶＰＮを示すものとして用いている）で、ポート番号が『Ｐｏｒｔ３』で、プロトコルが『ＵＤＰ』であることを記述している。

また、ｃ行とは、一般に、『ｃ＝＜nettype＞＜addrtype＞＜connection-address＞』で定義されるものであり、左から順に、ネットワークのタイプ、アドレスのタイプ、接続アドレスを意味する。図３の例では、『ｃ＝ＩＮ ＩＰ４ ＩＰａｄｄｒ３』とあるが、これは、ネットワークのタイプが『ＩＮ』（アクセス網（ＩＰ））で、アドレスのタイプが『ＩＰversion４』で、ＳＩＰダイアルアップＧＷ３０からみた接続アドレスが『ＩＰ３』であることを記述している。なお、実施例１におけるｃ行の記述においては、アドレスのタイプを『ＩＰ４』または『ＩＰ６』と記述し、接続アドレスを『ＩＰａｄｄｒＸ』（Ｘは数字）と記述して両者を区別する。すなわち、例えば、ｃ行に『ＩＰ４』と記述されている場合は、アドレスのタイプが『ＩＰversion４』であることを意味し、ｃ行に『ＩＰａｄｄｒ４』と記述されている場合は、接続アドレスが『ＩＰ４』であることを意味する。

また、ｂ行とは、一般に、『ｂ＝＜bwtype＞：＜bandwidth＞』で定義されるものであり、左から順に、英数字の修飾子、帯域を意味する。図３の例では、『ｂ＝１０Ｍ』とあるが、帯域が『１０Ｍｂｐｓ』であることのみを記述している。

すると、ＳＩＰダイアルアップＧＷ３０のＳＩＰ ＵＡ部３１は、自装置に関する情報を、プロキシ装置１０のＳＩＰ ＵＡ部１２にＳＩＰ通信にて送信する（ステップＳ１０７）。例えば、ＳＩＰ ＵＡ部３１は、２００ ＯＫメッセージを送信し、ＳＤＰによってｍ行およびｃ行を記述することで、情報を送信する。図３の例では、ｍ行に、メディアタイプが『application』で、ポート番号が『Ｐｏｒｔ４』で、プロトコルが『ＵＤＰ』であることを記述し、ｃ行に、ネットワークのタイプが『ＩＮ』で、アドレスのタイプが『ＩＰversion４』で、プロキシ装置１０からみた接続アドレスが『ＩＰ４』であることを記述している。

次に、プロキシ装置１０のＳＩＰ ＵＡ部１２は、ＳＩＰ ＵＡ部３１から受信した情報をパラメータ設定部１３に伝達し、パラメータ設定部１３は、端末２０に通知するパラメータを決定する（ステップＳ１０８）。例えば、パラメータ設定部１３は、ポート番号『Ｐｏｒｔ２』を選択し、端末２０に通知するパラメータとして、ＩＰアドレス『ＩＰ２』およびポート番号『Ｐｏｒｔ２』を決定する。

なお、実施例１においては、まず、ステップＳ１０６においてＳＩＰダイアルアップＧＷ３０に通知するパラメータを決定した後に、ステップＳ１０８において端末２０に通知するパラメータを決定しているが、本発明はこれに限られるものではない。そもそも、ポート番号『Ｐｏｒｔ２』と、ＳＩＰダイアルアップＧＷ３０に通知したポート番号『Ｐｏｒｔ３』とに異なる値を選ぶものとすれば、パラメータ設定部１３は、端末２０に通知するパラメータを、例えば、ステップＳ１０５の時点（ダイアルアップ要求を受信した時点）で決定してもよい。

続いて、パラメータ設定部１３は、パラメータを設定する（ステップＳ１０９）。例えば、パラメータ設定部１３は、「ソースアドレスが『ＩＰ１』でソースポート番号が『４５００』であるパケットであって、宛先アドレスが『ＩＰ２』で宛先ポート番号が『Ｐｏｒｔ２』であるパケット」と、「ソースアドレスが『ＩＰ３』でソースポート番号が『Ｐｏｒｔ３』であるパケットであって、宛先アドレスが『ＩＰ４』で宛先ポート番号が『Ｐｏｒｔ４』であるパケット」とを相互に変換するＮＡＰＴを設定する。すなわち、実施例１におけるＮＡＰＴとしては、symmetricＮＡＴを想定しており、パラメータ設定部１３は、「ソースアドレスが『ＩＰ１』でソースポート番号が『４５００』であるパケットであって、宛先アドレスが『ＩＰ２』で宛先ポート番号が『Ｐｏｒｔ２』であるパケット」を「ソースアドレスが『ＩＰ３』でソースポート番号が『Ｐｏｒｔ３』であるパケットであって、宛先アドレスが『ＩＰ４』で宛先ポート番号が『Ｐｏｒｔ４』であるパケット」に変換するというルールと、「ソースアドレスが『ＩＰ３』でソースポート番号が『Ｐｏｒｔ３』であるパケットであって、宛先アドレスが『ＩＰ４』で宛先ポート番号が『Ｐｏｒｔ４』であるパケット」を「ソースアドレスが『ＩＰ１』でソースポート番号が『４５００』であるパケットであって、宛先アドレスが『ＩＰ２』で宛先ポート番号が『Ｐｏｒｔ２』であるパケット」に変換するというルールの両方を設定する。

これは、ステップＳ１０８において選択したポート番号に対して端末２０から送信されたパケットは、ＳＩＰダイアルアップＧＷ３０に対するトンネル通信のパケットであるので、ＩＰアドレスとポート番号とを変換した上で、ＳＩＰダイアルアップＧＷ３０に送信することを意味している。また、反対に、ステップＳ１０６において通知したポート番号に対してＳＩＰダイアルアップＧＷ３０から送信されたパケットは、端末２０に対するトンネル通信のパケットであるので、ＩＰアドレスとポート番号とを変換した上で、端末２０に送信することを意味している。

そして、パラメータ設定部１３は、ステップＳ１０８において決定したパラメータをＷｅｂポータル部１１に伝達し、Ｗｅｂポータル部１１は、パラメータを、端末２０のＷｅｂブラウザ部２１に、ＨＴＴＰ／ＨＴＴＰＳ通信にて送信する（ステップＳ１１０）。例えば、Ｗｅｂポータル部１１は、ステップＳ１０５において受信したダイアルアップ要求に対する応答として、ＩＰアドレス『ＩＰ２』およびポート番号『Ｐｏｒｔ２』を送信する。

すると、Ｗｅｂブラウザ部２１は、Ｗｅｂポータル部１１から送信されたパラメータを、ＨＴＴＰ／ＨＴＴＰＳ通信にて受信し、企業ＩＰ網（ＩＰ５）宛ての通信のセキュリティポリシーとして、ＩＰアドレス『ＩＰ２』およびポート番号『Ｐｏｒｔ２』を設定する（ステップＳ１１１）。

こうして、端末２０とＳＩＰダイアルアップＧＷ３０との間にＶＰＮが生成され、その後、端末２０とＳＩＰダイアルアップＧＷ３０との間では、ＩＫＥ（Internet Key Exchange）による鍵交換や、ＥＳＰ（Encapsulating Security Payload）によってカプセル化されたトンネル通信が行われる（ステップＳ１１２）。なお、この時、プロキシ装置１０のＵＤＰリレー部１４は、ステップＳ１０９においてパラメータ設定部１３によって設定されたＮＡＰＴに基づいて、ＩＰアドレスおよびポート番号の変換を行う。

［実施例１の効果］
上記してきたように、実施例１によれば、端末とＳＩＰダイアルアップＧＷとの間にプロキシ装置が介在し、端末とＳＩＰダイアルアップＧＷとの間のパラメータ交換を仲介するので、端末がＶＰＮ生成手順のための専用アプリケーション（ＳＩＰ ＵＡ機能）を備えていなくても、リモートアクセスを実現することが可能になる。

すなわち、実施例１に係るトンネル通信システムは、まず、端末とＳＩＰダイアルアップＧＷとの間でＳＩＰ通信がなされることなくＶＰＮが生成される点に特徴がある。言い換えると、端末とＳＩＰダイアルアップＧＷとの間に、Ｗｅｂポータル機能とＳＩＰ ＵＡ機能とを兼ね備えたプロキシ装置が介在し、端末とＳＩＰダイアルアップＧＷとの間のパラメータ交換を仲介する点に特徴がある。かかる特徴により、端末は、ＳＩＰ ＵＡ機能を備える必要がなくなるのである。

また、実施例１に係るトンネル通信システムは、プロキシ装置と端末との間で行われる認証として、Ｗｅｂベースの認証を選択し得る点に特徴がある。すなわち、プロキシ装置は、柔軟なＷｅｂベースの認証によって端末を認証することも選択し得る。かかる特徴により、実施例１に係るトンネル通信システムは、端末が固定回線に接続する場合のみならず、端末が移動し、移動先の回線に接続する場合にも対応することができるのである。

さらに、実施例１に係るトンネル通信システムは、ＶＰＮの終端を端末にしている点に特徴がある。すなわち、プロキシ装置は、自装置とＳＩＰダイアルアップＧＷとの間にＶＰＮを生成するのではなく、端末とＳＩＰダイアルアップＧＷとの間にＶＰＮを生成するように制御する。かかる特徴により、実施例１に係るトンネル通信システムは、アクセスＬＡＮに接続する他端末までもがＳＩＰダイアルアップＧＷにリモートアクセスしてしまう事態を防ぐことができるのである。

また、実施例１によれば、ダイアルアップ要求とともに受信したアクセス先情報によってＳＩＰダイアルアップＧＷを決定するので、プロキシ装置は、端末識別情報とアクセス先情報との対応関係といった利用者管理情報を保持する必要がなくなる。この結果、利用者がＳＩＰダイアルアップＧＷを変更するたびにプロキシ装置側で利用者管理情報を更新することも不要となる。

さて、これまで実施例１として、トンネル通信がＩＰｓｅｃによって実現される場合を説明してきたが、本発明はこれに限られるものではない。以下、実施例２として、トンネル通信がＳＳＬによって実現される場合を説明する。

［実施例２に係るトンネル通信システムの構成］
まず、図５を用いて、実施例２に係るトンネル通信システムの構成を説明する。図５は、実施例２に係るトンネル通信システムの構成を示すブロック図およびプロトコルスタック図である。なお、以下では、実施例１に係るトンネル通信システムと異なる点を中心に説明する。

図５に示すように、実施例２に係るトンネル通信システムは、プロキシ装置１０にＴＣＰリレー部１５が備えられる点が、実施例１に係るトンネル通信システムと異なる。

ＴＣＰリレー部１５は、ＴＣＰパケットを転送する部である。具体的には、ＴＣＰリレー部１５は、パラメータ設定部１３から伝達されたパラメータに基づいて、ＳＩＰダイアルアップＧＷ３０との間でＴＣＰコネクションを生成する。また、ＴＣＰリレー部１５は、パラメータ設定部１３から伝達されたパラメータに基づいて、端末２０との間でもＴＣＰコネクションを生成する。また、ＴＣＰリレー部１５は、生成したＴＣＰコネクション同士をリレーすることで、端末２０とＳＩＰダイアルアップＧＷ３０との間でＴＣＰパケットを転送する。

［実施例２に係るトンネル通信システムのプロトコルスタック］
次に、図５を用いて、実施例２に係るトンネル通信システムのプロトコルスタックを説明する。なお、以下では、実施例１に係るトンネル通信システムと異なる点を中心に説明する。

図５の（ｂ）トンネルパケットの転送を説明する。図５に示すように、実施例２に係るトンネル通信システムは、端末２０のプロトコルスタックの『ＩＰ（アクセス網）』の上のプロトコルが『ＴＣＰ』、『ＳＳＬ（ｏｒＴＬＳ（Transport Layer Security））』である点、また、プロキシ装置１０のプロトコルスタックの『ＩＰ』および『ＩＰ（閉域網）』各々の上のプロトコルが『ＴＣＰ』、『ＴＣＰリレー』である点、さらに、ＳＩＰダイアルアップＧＷ３０の『ＩＰ（閉域網）』の上のプロトコルが『ＴＣＰ』、『ＳＳＬ（ｏｒＴＬＳ）』である点が、実施例１と異なる。なお、ＴＬＳは、ＳＳＬに若干の改良が加えられたものであり、ＲＦＣ２２４６として標準化されている。以下では、ＳＳＬとＴＬＳとを特に区別せずに説明する。

実施例１と同様、実施例２においても、ＳＩＰダイアルアップＧＷ３０のプロトコルスタックは、閉域ＩＰ網側は、端末２０のプロトコルスタックとほぼ同様の構成である。すなわち、端末２０とＳＩＰダイアルアップＧＷ３０とは、トンネル通信のパケットを送受信し、カプセル化した情報を取り出すことができる。この点、プロキシ装置１０のプロトコルスタックは、『ＴＣＰ』の上位レイヤについては単に『ＴＣＰリレー』するのみであり、端末２０とＳＩＰダイアルアップＧＷ３０との間にＶＰＮが生成されていることがわかる。

［実施例２に係るトンネル通信システムによる処理の手順］
続いて、図６を用いて、実施例２に係るトンネル通信システムによる処理の手順を説明する。図６は、実施例２に係るトンネル通信システムによる処理の手順を示すシーケンス図である。なお、以下では、実施例１に係るトンネル通信システムと異なる点を中心に説明する。

図６に示すように、ステップＳ２０１〜ステップＳ２０５は、実施例１に係るトンネル通信システムと同様の処理の手順が実行される。

そして、Ｗｅｂポータル部１１は、Ｗｅｂブラウザ部２１からダイアルアップ要求を受信すると、ＳＩＰダイアルアップＧＷ３０を決定する。続いて、パラメータ設定部１３が、ＳＩＰダイアルアップＧＷ３０に通知するパラメータを決定する。

例えば、Ｗｅｂポータル部１１は、実施例１と同様、Ｗｅｂブラウザ部２１からダイアルアップ要求とともに受信した接続先番号『0422-59-1111』で識別される装置を、ＳＩＰダイアルアップＧＷ３０であると決定する。そして、実施例２におけるパラメータ設定部１３は、ＩＰダイアルアップＧＷ３０に通知するパラメータとして、ＩＰアドレス『ＩＰ３』およびポート番号『Ｐｏｒｔ３』や、プロトコル『ＴＣＰ』、『ＴＬＳ』を決定し、ＳＩＰ ＵＡ部１２に伝達する。

次に、プロキシ装置１０のＳＩＰ ＵＡ部１２は、実施例１と同様、パラメータ設定部１３によって決定されたパラメータを、ＳＩＰダイアルアップＧＷ３０のＳＩＰ ＵＡ部３１に、ＳＩＰ通信にて送信する（ステップＳ２０６）。

すると、ＳＩＰダイアルアップＧＷ３０のＳＩＰ ＵＡ部３１は、実施例１と同様、自装置に関する情報を、プロキシ装置１０のＳＩＰ ＵＡ部１２にＳＩＰ通信にて送信する（ステップＳ２０７）。

ところで、実施例２におけるプロキシ装置１０およびＳＩＰダイアルアップＧＷ３０は、ステップＳ２０７に続いて、ＴＣＰコネクション（ＴＣＰ１）を生成する（ステップＳ２０８）。具体的には、パラメータ設定部１３からパラメータを伝達されたＴＣＰリレー部１５が、アドレス『ＩＰ４』およびポート番号『Ｐｏｒｔ４』を指定してＴＣＰ接続することで、ＴＣＰリレー部１５と、ＳＩＰ ＵＡ部３１からパラメータを伝達されたトンネル通信部３２とが、ＴＣＰコネクションを生成する。また、この時、ＴＣＰリレー部１５は、ポート番号『Ｐｏｒｔ３』を使用して接続する。

続いて、実施例１と同様、プロキシ装置１０のパラメータ設定部１３は、端末２０に通知するパラメータを決定する（ステップＳ２０９）。例えば、パラメータ設定部１３は、ポート番号『Ｐｏｒｔ２』を選択し、端末２０に通知するパラメータとして、ＩＰアドレス『ＩＰ２』およびポート番号『Ｐｏｒｔ２』を決定する。

続いて、実施例２におけるパラメータ設定部１３は、ソースアドレスが『ＩＰ１』であるパケットであって、宛先アドレスが『ＩＰ２』で宛先ポート番号が『Ｐｏｒｔ２』であるパケットについては、ＴＣＰによる接続を許可する設定を行う（ステップＳ２１０）。

これは、ステップＳ２０９において選択したポート番号に対して端末２０から送信されたパケットは、ＳＩＰダイアルアップＧＷ３０に対するトンネル通信のパケットであるので、ＴＣＰリレーの対象として、ＳＩＰダイアルアップＧＷ３０に送信することを意味している。なお、実施例２においては、ＳＩＰダイアルアップＧＷ３０から送信されたパケットを端末２０に対してＴＣＰリレーする点については、予め許可するものとして設定されているものとする。

そして、パラメータ設定部１３は、実施例１と同様、ステップＳ２０９において決定したパラメータをＷｅｂポータル部１１に伝達し、Ｗｅｂポータル部１１は、パラメータを、端末２０のＷｅｂブラウザ部２１に、ＨＴＴＰ／ＨＴＴＰＳ通信にて送信する（ステップＳ２１１）。

すると、実施例２におけるＷｅｂブラウザ部２１は、Ｗｅｂポータル部１１から送信されたパラメータを、トンネル通信部２２に伝達する。すると、実施例２における端末２０およびプロキシ装置１０は、ステップＳ２１１に続いて、ＴＣＰコネクション（ＴＣＰ２）を生成する（ステップＳ２１２〜２１３）。具体的には、Ｗｅｂポータル部１１からパラメータを伝達されたトンネル通信部２２が、アドレス『ＩＰ２』およびポート番号『Ｐｏｒｔ２』を指定してＴＣＰ接続することで、トンネル通信部２２と、プロキシ装置１０のＴＣＰリレー部１５とが、ＴＣＰコネクションを生成する。

その後、実施例２におけるＴＣＰリレー部１５は、ステップＳ２０８において生成されたＴＣＰコネクション『ＴＣＰ１』と、ステップＳ２１３において生成されたＴＣＰコネクション『ＴＣＰ２』との間で、ＴＣＰリレーを開始する（ステップＳ２１４）。

こうして、端末２０とＳＩＰダイアルアップＧＷ３０との間にＶＰＮが生成され、その後、端末２０とＳＩＰダイアルアップＧＷ３０との間では、Ｅｎｄ−ＥｎｄでＴＬＳ−Ｈａｎｄｓｈａｋｅが行われ、ＴＬＳ通信が実行される（ステップＳ２１５）。

［実施例２の効果］
上記してきたように、本発明に係るトンネル通信システムは、トンネル通信がＳＳＬによって実現される場合にも適用することが可能である。この場合には、端末にインストールされるべきアプリケーションがＷｅｂブラウザのみでよいという点で、トンネル通信がＩＰｓｅｃによって実現される場合に比較して有効である。すなわち、トンネル通信にＩＰｓｅｃを適用する場合、端末２０には、ＩＰｓｅｃ通信機能を有する必要がある。また、ＩＰｓｅｃ通信機能には、ＳＩＰダイアルアップＧＷ３０に設定されているパラメータと同じ値が設定されなければならない。例えば、暗号化アルゴリズム、ハッシュアルゴリズム、ライフタイムといった値である。これに対して、トンネル通信にＳＳＬを適用する場合、端末２０には、Ｗｅｂブラウザのみがインストールされていればよい。

さて、これまで実施例１および実施例２のトンネル通信システムを説明してきたが、いずれも、アクセス網（ＩＰ）区間のパケット転送の保護をＩＰｓｅｃによって実現するものであった。この点、実施例３に係るトンネル通信システムは、パケット転送の保護を代替する手法の一つとして、ＳＲＴＰを提案するものである。ＳＲＴＰは、ＲＴＰに暗号化の仕組みおよび認証の仕組みを追加した拡張版プロトコル（ＲＦＣ３７１１）である。以下では、実施例１に係るトンネル通信システムにＳＲＴＰを導入した実施例を、実施例３に係るトンネル通信システムとして説明する。

［実施例３に係るトンネル通信システムの構成］
まず、図７を用いて、実施例３に係るトンネル通信システムの構成を説明する。図７は、実施例３に係るトンネル通信システムの構成を示すブロック図およびプロトコルスタック図である。なお、以下では、実施例１に係るトンネル通信システムと異なる点を中心に説明する。

図７に示すように、実施例３に係るトンネル通信システムは、端末２０のトンネル通信部２２にＳＲＴＰカプセル化部２３が備えられる点、また、プロキシ装置１０のＵＤＰリレー部１６がＳＲＴＰ対応となる点が、実施例１に係るトンネル通信システムと異なる。

ＳＲＴＰカプセル化部２３は、トンネル通信部２２によってＵＤＰカプセル化されたパケットを、ＳＲＴＰによってさらにカプセル化する。具体的には、ＳＲＴＰカプセル化部２３は、ＵＤＰカプセル化されたパケットをトンネル通信部２２から伝達されると、当該パケットをさらにＳＲＴＰカプセル化し、ＳＲＴＰカプセル化したパケットを、再びトンネル通信部２２に伝達する。なお、ＳＲＴＰカプセル化部２３は、プロキシ装置１０のＷｅｂポータル部１１から伝達されたＳＲＴＰカプセル化用のパラメータを用いて、ＳＲＴＰカプセル化を行う。なお、実施例３におけるＳＲＴＰカプセル化部２３は、Null-Cipher、Authenticationのみのモードを使用している。つまり、実施例３においては、ＳＲＴＰの仕組みの内、認証の仕組みのみを利用しているが、もちろん、暗号の仕組みを併用してもよい。

ここで、ＳＲＴＰカプセル化を実行するにあたっては、マスター鍵と、ＳＳＲＣ（Synchronization SouRCe）と、シーケンス番号初期値とが利用される。マスター鍵とは、認証に利用する鍵情報であり、パケットの正当性をプロキシ装置１０において検証するための鍵情報である。また、ＳＳＲＣとは、ＲＴＰセッションごとに端末２０を識別するための情報であり、ランダムに生成されるものである。また、シーケンス番号初期値とは、パケットの送信順を示す通し番号である。

実施例３においては、プロキシ装置１０のパラメータ設定部１３が、端末２０に通知するＳＲＴＰカプセル化用のパラメータとして、マスター鍵、ＳＳＲＣ（ｓ）、シーケンス番号初期値を決定し、Ｗｅｂポータル部１１に伝達する。すると、Ｗｅｂポータル部１１が、これらのＳＲＴＰカプセル化用のパラメータを端末２０のＷｅｂブラウザ部２１に送信する。こうして、端末２０のＳＲＴＰカプセル化部２３は、ＳＲＴＰカプセル化用のパラメータを受信するので、これらのパラメータを用いてＳＲＴＰカプセル化を実行する。具体的には、ＳＲＴＰカプセル化部２３は、ＵＤＰカプセル化したパケットをさらにＳＲＴＰカプセル化するとともに、マスター鍵を用いた署名を添付する。

一方、プロキシ装置１０のＵＤＰリレー部１６は、端末２０から送信されたパケットを受信すると、当該パケットからＳＲＴＰカプセル化された情報を取り出す。そして、ＵＤＰリレー部１６は、マスター鍵を用いて署名を検証することで、当該パケットが確かに端末２０から送信されたものであること、また、当該パケットが改竄されていないことなどを検証する。その後、ＵＤＰリレー部１６は、検証に成功したＳＲＴＰカプセル化パケットからＵＤＰカプセル化パケットを取り出し、当該ＵＤＰカプセル化パケットのみをリレーする。

［実施例３に係るトンネル通信システムのプロトコルスタック］
次に、図７を用いて、実施例３に係るトンネル通信システムのプロトコルスタックを説明する。なお、以下では、実施例１に係るトンネル通信システムと異なる点を中心に説明する。

図７の（ｂ）トンネルパケットの転送を説明する。図７に示すように、実施例３に係るトンネル通信システムは、端末２０のプロトコルスタックの『ＵＤＰ』と『ＩＫＥ／ＮＡＴ−Ｔ ＩＰｓｅｃ』との間に、『ＳＲＴＰ』のプロトコルが介在する点、また、プロキシ装置１０のプロトコルスタックの『ＵＤＰ』と『ＵＤＰリレー』との間に、『ＳＲＴＰ』のプロトコルが介在する点が、実施例１と異なる。

また、実施例１と異なり、実施例３においては、ＳＩＰダイアルアップＧＷ３０のプロトコルスタックは、『ＳＲＴＰ』のプロトコルが介在しない点で、端末２０のプロトコルスタックとは異なる構成である。すなわち、ＳＲＴＰカプセル化は、端末２０とプロキシ装置１０との間でのみ行われていることがわかる。

［実施例３に係るトンネル通信システムによる処理の手順］
続いて、図８を用いて、実施例３に係るトンネル通信システムによる処理の手順を説明する。図８は、実施例３に係るトンネル通信システムによる処理の手順を示すシーケンス図である。なお、以下では、実施例１に係るトンネル通信システムと異なる点を中心に説明する。

図８に示すように、ステップＳ３０１〜Ｓ３０７は、実施例１に係るトンネル通信システムと同様の処理の手順が実行される。

すると、実施例３におけるパラメータ設定部１３は、ＳＲＴＰのマスター鍵、ＳＳＲＣ（ｓ）、シーケンス番号初期値を決定する（ステップＳ３０８）。そして、パラメータ設定部１３は、ＳＳＲＣ（ｓ）をソースとするパケットについては、ソースアドレスを『ＩＰ３』、ソースポート番号を『Ｐｏｒｔ３』に変更し、かつ、宛先アドレスを『ＩＰ４』、宛先ポート番号を『Ｐｏｒｔ４』に変更して中継するように、設定を行う（ステップＳ３０９）。

そして、パラメータ設定部１３は、ステップＳ３０８において決定したパラメータをＷｅｂポータル部１１に伝達し、Ｗｅｂポータル部１１は、パラメータを、端末２０のＷｅｂブラウザ部２１に、ＨＴＴＰ／ＨＴＴＰＳ通信にて送信する（ステップＳ３１０）。すなわち、パラメータ設定部１３は、ＩＰアドレス『ＩＰ２』および宛先ポート番号『Ｐｏｒｔ２』の他に、マスター鍵、ＳＳＲＣ（ｓ）、シーケンス番号初期値を送信する。

すると、Ｗｅｂブラウザ部２１が、Ｗｅｂポータル部１１から送信されたパラメータを、ＨＴＴＰ／ＨＴＴＰＳ通信にて受信すると、トンネル通信部２２は、企業ＩＰ網（ＩＰ５）宛ての通信のパケットは、ＵＤＰカプセル化した後に、ＳＲＴＰでさらにカプセル化して転送するように、ポリシーを設定する（ステップＳ３１１）。

こうして、端末２０とＳＩＰダイアルアップＧＷ３０との間にＶＰＮが生成され、その後、端末２０とＳＩＰダイアルアップＧＷ３０との間では、ＩＫＥによる鍵交換や、ＥＳＰによってカプセル化されたトンネル通信が行われる（ステップＳ３１２）。

なお、この時、プロキシ装置１０のＵＤＰリレー部１６は、端末２０から送信されたパケットを受信すると、当該パケットからＳＲＴＰカプセル化された情報を取り出す。そして、ＵＤＰリレー部１６は、マスター鍵を用いて署名を検証することで、当該パケットが確かに端末２０から送信されたものであること、また、当該パケットが改竄されていないことなどを検証する（ソース認証）。また、ＵＤＰリレー部１６は、検証に成功したＳＲＴＰカプセル化パケットからＵＤＰカプセル化パケットを取り出し、ＳＳＲＣの値（ｓ）に対応づけて記憶されている設定（ステップＳ３０９における設定）に基づいて、当該パケットのソースアドレスを『ＩＰ３』、ソースポート番号を『Ｐｏｒｔ３』に変更し、宛先アドレスを『ＩＰ４』、宛先ポート番号を『Ｐｏｒｔ４』に変更する。こうして、ＵＤＰリレー部１６は、当該ＵＤＰカプセル化パケットのみをリレーする。

［実施例３の効果］
上記してきたように、実施例３によれば、プロキシ装置は、端末から送信されたトンネル通信のパケットについて、当該パケットが確かに端末から送信されたものであること、また、当該パケットが改竄されていないことなどを検証し、検証に成功したパケットのみをＳＩＰダイアルアップＧＷに転送するので、アクセス網区間についてのセキュリティを向上させることが可能になる。

［他の実施例］
さて、これまで本発明の実施例について説明したが、本発明は上記した実施例以外にも、種々の異なる形態にて実施されてよいものである。

［ＳＩＰ通信以外の網］
実施例１〜実施例３においては、制御装置（プロキシ装置）と受付装置（ＳＩＰダイアルアップＧＷ）との間の通信がＳＩＰ通信であることを想定してきたが、本発明はこれに限られるものではない。すなわち、本発明は、端末自身にＶＰＮを生成する機能が備えられていなくても、端末と受付装置との間に制御装置が介在することで、端末と受付装置との間のＶＰＮが生成されるものである。したがって、制御装置と受付装置との間の通信にＳＩＰ通信以外のプロトコルを用いる網であっても、本発明を同様に適用することができる。

［ＨＴＴＰ／ＨＴＴＰＳ通信以外のプロトコル］
実施例１〜実施例３においては、端末と制御装置（プロキシ装置）との間の通信がＨＴＴＰ／ＨＴＴＰＳ通信であることを想定してきたが、本発明はこれに限られるものではなく、例えば、ＳＭＴＰ（Simple Mail Transfer Protocol）通信などであってもよい。すなわち、端末が制御装置との間で通信を行うにあたり、専用アプリケーションを備える必要がないプロトコルであれば、いずれでもよい。この点、例えば、端末が一般的に備えるメールソフトのプロトコルであるＳＭＴＰ通信などであってもよいのである。

［受付装置の決定］
また、実施例１〜実施例３においては、制御装置（プロキシ装置）が、端末からダイアルアップ要求を受信するとともに受付装置（ＳＩＰダイアルアップＧＷ）を識別するアクセス先番号を受信し、当該アクセス先番号によって識別される受付装置を、ダイアルアップ要求を受け付ける受付装置として決定する手法を説明してきた。しかしながら、本発明はこれに限られるものではない。まず、制御装置がダイアルアップ要求を受信するタイミングとアクセス先番号を受信するタイミングとが同時である手法に限られるものではなく、ダイアルアップ要求を受信し、その後、アクセス先番号を受信する、といったタイミングなどでもよい。

また、制御装置が、端末を識別する識別情報に基づいて受付装置を決定する手法にも本発明を適用することができる。この場合には、制御装置は、予め、端末を識別する端末識別情報と、受付装置を識別する受付装置識別情報とを対応づけて記憶している。そして、制御装置は、ダイアルアップ要求を受信すると、当該ダイアルアップ要求を送信した端末の端末識別情報を特定し、記憶している対応づけを検索することで、当該端末識別情報に対応づけて記憶されている受付装置識別情報を取得する。こうして、制御装置は、当該受付装置識別情報によって識別される受付装置を、ダイアルアップ要求を受け付ける受付装置として決定することができる。この手法によれば、端末は、制御装置に受付装置識別情報を送信する必要がない。

［システム構成等］
また、本実施例において説明した各処理のうち、自動的におこなわれるものとして説明した処理の全部または一部を手動的におこなうこともでき、あるいは、手動的におこなわれるものとして説明した処理の全部または一部を公知の方法で自動的におこなうこともできる。この他、上記文書中や図面中で示した処理手順（図３、図６、図８など）、制御手順、具体的名称、各種のデータやパラメータを含む情報については、特記する場合を除いて任意に変更することができる。

また、図示した各装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示（図２、図５、図７など）の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、各装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。

なお、本実施例で説明したトンネル通信方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータで実行することによって実現することができる。このプログラムは、インターネットなどのネットワークを介して配布することができる。また、このプログラムは、ハードディスク、フレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤなどのコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行することもできる。

以上のように、本発明に係るトンネル通信システムおよび制御装置は、リモートアクセスを実現することに有用であり、特に、端末がＶＰＮ生成手順のための専用アプリケーションを備えていなくても、リモートアクセスを実現することに適する。

基本原理を説明するための図である。 実施例１に係るトンネル通信システムの構成を示すブロック図およびプロトコルスタック図である。 実施例１に係るトンネル通信システムによる処理の手順を示すシーケンス図である。 Ｗｅｂダイアルアップ画面を説明するための図である。 実施例２に係るトンネル通信システムの構成を示すブロック図およびプロトコルスタック図である。 実施例２に係るトンネル通信システムによる処理の手順を示すシーケンス図である。 実施例３に係るトンネル通信システムの構成を示すブロック図およびプロトコルスタック図である。 実施例３に係るトンネル通信システムによる処理の手順を示すシーケンス図である。

符号の説明

１０ プロキシ装置
１１ Ｗｅｂポータル部
１２ ＳＩＰ ＵＡ部
１３ パラメータ設定部
１４ ＵＤＰリレー部
２０ 端末
２１ Ｗｅｂブラウザ部
２２ トンネル通信部
３０ ＳＩＰダイアルアップＧＷ
３１ ＳＩＰ ＵＡ部
３２ トンネル通信部

Claims (6)

1. アクセス要求を送信する端末が接続するアクセス網と当該端末のアクセス先となるアクセス先網とがＩＰレイヤでパケットを転送するＩＰ網に各々接続される状況の下、当該ＩＰ網かつ当該アクセス先網に接続して当該アクセス要求を受け付ける受付装置と当該端末との間で行われるトンネル通信を制御するトンネル通信システムであって、
   前記アクセス網かつ前記ＩＰ網に接続する制御装置は、
   前記端末との間で通信を行い、当該通信にて当該端末を認証することで、当該端末との間に認証済みのセッションを生成する第一のセッション生成手段と、
   前記第一のセッション生成手段によって生成されたセッションを用いて前記アクセス要求を前記端末から受信すると、当該アクセス要求を受け付ける受付装置を決定する受付装置決定手段と、
   前記受付装置決定手段によって決定された受付装置と前記端末との間のトンネル通信に必要なパラメータを決定し、当該パラメータを設定するパラメータ設定手段と、
   前記パラメータ設定手段によって決定されたパラメータを前記受付装置に送信する第一のパラメータ送信手段と、
   前記パラメータ設定手段によって決定されたパラメータを前記第一のセッション生成手段によって生成されたセッションを用いて前記端末に送信する第二のパラメータ送信手段と、
   前記端末または前記受付装置から送信されたトンネル通信のパケットを受信すると、当該パケットを転送する転送手段とを備え、
   前記端末は、
   前記制御装置との間で通信を行い、当該通信にて当該制御装置に認証されることで、当該制御装置との間に認証済みのセッションを生成する第二のセッション生成手段と、
   前記第二のセッション生成手段によって生成されたセッションを用いて、前記アクセス要求を前記制御装置に送信するアクセス要求送信手段とを備え、
   前記端末および前記受付装置各々は、
   前記パラメータ送信手段によって送信されたパラメータを用いてトンネル通信を行うトンネル通信手段と、
   を備えたことを特徴とするトンネル通信システム。
2. アクセス要求を送信する端末が接続するアクセス網と当該端末のアクセス先となるアクセス先網とがＩＰレイヤでパケットを転送するＩＰ網に各々接続される状況の下、当該ＩＰ網かつ当該アクセス先網に接続して当該アクセス要求を受け付ける受付装置と当該端末との間で行われるトンネル通信を制御するトンネル通信システムにおける制御装置であって、
   前記制御装置は、前記アクセス網かつ前記ＩＰ網に接続するものであり、
   前記端末との間で通信を行い、当該通信にて当該端末を認証することで、当該端末との間に認証済みのセッションを生成する第一のセッション生成手段と、
   前記第一のセッション生成手段によって生成されたセッションを用いて前記アクセス要求を前記端末から受信すると、当該アクセス要求を受け付ける受付装置を決定する受付装置決定手段と、
   前記受付装置決定手段によって決定された受付装置と前記端末との間のトンネル通信に必要なパラメータを決定し、当該パラメータを設定するパラメータ設定手段と、
   前記パラメータ設定手段によって決定されたパラメータを前記受付装置に送信する第一のパラメータ送信手段と、
   前記パラメータ設定手段によって決定されたパラメータを前記第一のセッション生成手段によって生成されたセッションを用いて前記端末に送信する第二のパラメータ送信手段と、
   前記端末または前記受付装置から送信されたトンネル通信のパケットを受信すると、当該パケットを転送する転送手段と、
   を備えたことを特徴とする制御装置。
3. 前記受付装置決定手段は、前記アクセス要求を受け付ける受付装置を識別する受付装置識別情報を受信すると、当該受付装置識別情報によって識別される受付装置を、当該アクセス要求を受け付ける受付装置として決定することを特徴とする請求項２に記載の制御装置。
4. 前記端末を識別する端末識別情報と、前記受付装置を識別する受付装置識別情報とを対応づけて記憶する識別情報記憶手段をさらに備え、
   前記受付装置決定手段は、前記アクセス要求を送信した端末を識別する端末識別情報を特定し、当該端末識別情報を用いて前記識別情報記憶手段を検索することで、当該端末識別情報に対応づけて記憶されている受付装置識別情報を取得し、当該受付装置識別情報によって識別される受付装置を、アクセス要求を受け付ける受付装置として決定することを特徴とする請求項２に記載の制御装置。
5. パケットの正当性を検証可能な鍵情報を前記端末に送信する鍵情報送信手段と、
   前記鍵情報送信手段によって送信された鍵情報を用いて前記端末においてカプセル化されたトンネル通信のパケットを受信すると、当該鍵情報を用いて当該パケットを検証する検証手段とをさらに備え、
   前記転送手段は、前記検証手段によって検証されたパケットのみを前記受付装置に転送することを特徴とする請求項２〜４のいずれか一つに記載の制御装置。
6. アクセス要求を送信する端末が接続するアクセス網と当該端末のアクセス先となるアクセス先網とがＩＰレイヤでパケットを転送するＩＰ網に各々接続される状況の下、当該ＩＰ網かつ当該アクセス先網に接続して当該アクセス要求を受け付ける受付装置と当該端末との間で行われるトンネル通信を制御するトンネル通信システムにおける制御装置が実行する制御プログラムであって、
   前記制御装置は、前記アクセス網かつ前記ＩＰ網に接続するものであり、
   前記端末との間で通信を行い、当該通信にて当該端末を認証することで、当該端末との間に認証済みのセッションを生成する第一のセッション生成手順と、
   前記第一のセッション生成手順によって生成されたセッションを用いて前記アクセス要求を前記端末から受信すると、当該アクセス要求を受け付ける受付装置を決定する受付装置決定手順と、
   前記受付装置決定手順によって決定された受付装置と前記端末との間のトンネル通信に必要なパラメータを決定し、当該パラメータを設定するパラメータ設定手順と、
   前記パラメータ設定手順によって決定されたパラメータを前記受付装置に送信する第一のパラメータ送信手順と、
   前記パラメータ設定手順によって決定されたパラメータを前記第一のセッション生成手順によって生成されたセッションを用いて前記端末に送信する第二のパラメータ送信手順と、
   前記端末または前記受付装置から送信されたトンネル通信のパケットを受信すると、当該パケットを転送する転送手順と、
   を制御装置に実行させることを特徴とする制御プログラム。

Images