JP2011239343A - クライアント装置、及びプログラム - Google Patents

Abstract

【課題】アプリケーションの改造をほとんどすることなく、クライアント装置にトンネリング機能を備える。
【解決手段】トンネルサーバ装置との間のトンネルを介して、通信相手装置とデータ通信を行うクライアント装置において、前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うトンネル機能手段と、通信ネットワークを介してデータ送受信を行うためのデータ通信手段と、前記データ通信手段を経由するパケットを監視し、当該パケットの通信情報に基づき、当該パケットが、前記クライアント装置が備えるアプリケーション部から出力されたパケットであると判定した場合に、当該パケットを前記トンネル機能手段に渡すパケット制御手段とを備え、前記トンネル機能手段は、前記パケット制御手段から受け取った前記パケットを、前記トンネルを経由して前記通信相手装置に向けて送信する。
【選択図】図４

Description

本発明は、通信ネットワークにおけるトンネリング技術に関するものである。

企業内ネットワークや家庭内ネットワーク等のプライベートネットワークと、インターネット等の外部ネットワークとの間には、通信のセキュリティを確保するためのファイアウォール装置（NAT装置等も含む）が設置されるのが一般的である。

このようなファイアウォール装置では、ネットワーク管理のポリシーに応じて、通信を許可するプロトコルが設定されるが、例えば、多くの場合、プライベートネットワーク内のクライアント装置からの要求に係るHTTP／HTTPS通信は許容されている。

そこで、プライベートネットワーク内のクライアント装置と、外部の装置との間で、IP電話や映像会議等の通信を行うために、HTTPのように通信が許容されているプロトコルのヘッダで、目的とする通信のパケットをカプセリングすることにより、仮想的な通信路であるトンネルを形成し、当該トンネルを通して、IP電話や映像会議等の目的とする通信を行うトンネリング技術が用いられている。

一般に、トンネリング技術では、トンネリング機能を備えたクライアント装置と、外部ネットワークに設置されたトンネルサーバ装置との間でトンネルを形成し、通信を行う。

ここで、クライアント装置（PC等）をトンネリング対応とするための従来技術の１つとして図１に示すようなライブラリ方式がある。この方式では、トンネリング処理を行うソフトウェアをライブラリとして備えるとともに、当該トンネリング用のライブラリに対応したアプリケーションを備える。

また、クライアント装置をトンネリング対応とするための他の従来技術として、図２に示すように、OS上に仮想的なネットワークインタフェースを設けて、そこにIPアドレスを付与することにより、当該仮想ネットワークインタフェースを経由して通信する部分をトンネリング経由にする方式もある。この方式では、あたかも仮想ネットワークインタフェースが、トンネリングサーバの存在する遠隔のネットワーク上に存在するかのように動作する。なお、本願に関連する先行技術文献の１つとして、特許文献１がある。

特開2008-187686号公報

しかしながら、上記の従来技術におけるライブラリ方式では、使用するアプリケーションの改造が必要となる。また、仮想的なネットワークインタフェースを設ける方式では、アドレスの消費やセキュリティの面で問題が生じる可能性があった。より詳細には下記のとおりである。

ライブラリ方式によりトンネリングを実現する場合、アプリケーションのソケットＡＰＩ部分についてアプリケーションの改造を要する。また、ＴＣＰ等のソケットＡＰＩを模擬しようとすると、プロトコル処理をライブラリ側で行う必要があり、アプリケーションが元々有しているプロトコル処理との互換性上の問題で、アプリケーションの動作に影響が出る可能性があった。また、アプリケーションをトンネリング対応に改造しようとする場合において、第三者が作成したライブラリ等のオブジェクトを利用する場合などソースコードがない場合には、そもそも改造が困難であった。

また、仮想ネットワークインタフェースを作成し、パケットをルーティングすることでトンネリングする方式では、基本的に全てのパケットが相互に外部と疎通してしまうため、セキュリティ上問題が生じる可能性があった。更に、仮想ネットワークインタフェースが出来てしまうことによる、複数インタフェース間のルーティング設定の煩雑化、あるいはそれに起因する通信障害等のトラブルの発生率が上昇する問題があった。また、一般に、対外的な通信を担うことから、仮想インタフェースに対してグローバルアドレスを割り当てることになるため、ＩＰｖ４のようにアドレス空間が限られている環境で、貴重なグローバルアドレスを１台のクライアントで１つ占有してしまう問題もある。

ところで、トンネルを通じたデータ送信に当たって、制御パケットと、データパケットを区別する等のためのヘッダを付けたパケットをトンネル経由で送信し、受信側において、ヘッダからパケット種別を判別して受信処理を行う従来技術がある。そのような従来技術では、受信パケットが破損していた場合に、次のヘッダまで、パケットを読み飛ばし、次のパケットで受信処理行っている。

しかし、このような従来技術では、任意のデータの中において、上記次のヘッダを識別できるようにするために、ヘッダをある程度の大きさを持ったサイズとしなければならず、通信のオーバーヘッドが大きくなるという問題があった。

また、トンネリングを用いた通信を行う場合に、ファイアウォール装置の機能により、長時間無通信の場合に、強制的に切断させられてしまう場合や、切断状態にならないのに、信号が疎通しなくなっている、いわゆるトンネルが詰まった状態が生じる場合がある。このようなことを回避するために、クライアント装置と、トンネルサーバ装置との間で、生存確認要求／生存確認要求応答の送受信を一定時間間隔で行うことが一般に行われている。

しかし、このような疎通確認技術では、生存確認要求の送信間隔が短いと、本来の通信パケット以外の無駄なパケットが増加し、無通信クライアントを含む多数のクライアントのトラフィックが集中するトンネルサーバ装置やそのネットワークにおいて、処理負荷が増加し、性能低下を招く恐れがある。逆に、送信間隔を長くしてしまうと、詰まり状態を長時間検出できず、通信が長時間途切れたりする問題が生じる。つまり、処理負担軽減と異常状態検出時間の短縮という相反する条件を、生存確認要求の送信周期の調整でもって同時に満たすことは困難であった。

本発明は上記の問題点に鑑みてなされたものであり、アプリケーションの改造をほとんどすることなく、クライアント装置にトンネリング機能を備えることを可能とした技術を提供することを目的とする。

また、本発明は、パケットに付するヘッダを短くし、効率的な通信を実現する技術を提供することも目的としている。更に、本発明は、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たすことを可能とした、生存確認の技術を提供することも目的としている。

上記の課題を解決するために、本発明は、トンネルサーバ装置との間に構築されたトンネルを介して、通信相手装置とデータ通信を行うクライアント装置であって、前記トンネルサーバ装置との間で前記トンネルを構築し、当該トンネルを介してパケットの送受信を行うトンネル機能手段と、通信ネットワークを介してデータ送受信を行うためのデータ通信手段と、前記データ通信手段を経由するパケットを監視し、当該パケットの通信情報に基づき、当該パケットが、前記クライアント装置が備えるアプリケーション部から出力されたパケットであると判定した場合に、当該パケットを前記トンネル機能手段に渡すパケット制御手段とを備え、前記トンネル機能手段は、前記パケット制御手段から受け取った前記パケットを、前記トンネルを経由して前記通信相手装置に向けて送信することを特徴とするクライアント装置として構成される。

また、前記クライアント装置において、前記パケット制御手段は、前記トンネル機能手段から、前記トンネルを経由して受信したパケットを受け取り、当該パケットを前記データ通信手段を介して前記アプリケーション部に送出する。

前記トンネル機能手段が前記トンネルを経由して受信するパケットには、ヘッダが付されており、前記トンネル機能手段は、前記ヘッダの情報に基づき、前記パケットが破損しているか否かを判定し、当該パケットが破損していると判定した場合に、前記トンネルを切断し、その後に、前記トンネルサーバ装置との間にトンネルを再構築する破損処理手段を備えることとしてもよい。

また、前記トンネル機能手段は、前記トンネルサーバ装置から、当該トンネルサーバ装置のアドレスとポート番号であるサーバアドレスとサーバポート番号を受け取り、当該サーバアドレスとサーバポート番号とを、前記アプリケーション部に対応するクライアントポート番号に対応付けて記憶手段に格納し、前記パケット制御手段から、前記クライアントポート番号を発ポート番号として含むパケットを受け取った場合に、前記記憶手段を参照することにより、前記パケットにおける発アドレスを前記サーバアドレスに変換し、前記パケットにおける発ポート番号を前記サーバポート番号に変換し、当該変換を施したパケットを前記トンネルを経由して送出するように構成してもよい。

また、前記トンネル機能手段は、前記トンネルを経由して、前記サーバアドレスを宛先アドレスとして含み、前記サーバポート番号を宛先ポート番号として含むパケットを受信した場合に、前記記憶手段を参照することにより、前記パケットにおける宛先アドレスを前記クライアント装置のアドレスに変換し、前記パケットにおける宛先ポート番号を前記クライアントポート番号に変換し、当該変換を施したパケットを、前記パケット制御手段を介して前記アプリケーション部に送出するように構成してもよい。

また、前記トンネルサーバ装置は、前記クライアント装置からパケットを受信する度に、当該パケットの受信時刻を最終受信時刻として記憶手段に保持し、データパケットを送信する場合には、当該データパケットの送信時刻の前記最終受信時刻からの経過時間を算出し、当該経過時間をサーバ側経過時間として前記データパケットに含めて送信してもよく、この場合、前記トンネル機能手段は、パケットを前記トンネルサーバ装置に送信する度に、当該パケットの送信時刻を最終送信時刻として記憶手段に保持し、前記トンネルサーバ装置から、前記データパケットを受信した場合に、当該データパケットの受信時刻の前記最終送信時刻からの経過時間をクライアント側経過時間として算出し、前記データパケットから取得したサーバ側経過時間と、前記クライアント側経過時間とに基づき、前記トンネルサーバ装置に対して生存確認要求を送信するか否かを決定するように構成してもよい。

また、上記構成において、前記トンネル機能手段は、前記クライアント側経過時間が、所定の時間以上である場合には、前記サーバ側経過時間が前記クライアント側経過時間より大きい場合に、生存確認要求を送信し、前記クライアント側経過時間が、前記所定の時間未満である場合には、前記サーバ側経過時間が、パケットの送信時刻から算出される平均送信間隔の所定数倍以上である場合に、生存確認要求を送信することとしてよい。

前記所定の時間は、例えば、前記クライアント装置と前記トンネルサーバ装置間におけるラウンドトリップ時間の２倍の時間であり、前記所定数は、例えば、４である。

また、前記トンネル機能手段は、前記トンネルサーバ装置からデータパケットを受信した後、その後にパケットを受信することなく、所定のタイマー時間が経過した場合に、生存確認要求を送信するように構成してもよい。

本発明によれば、アプリケーションの改造をほとんどすることなく、クライアント装置にトンネリング機能を備えることが可能になる。また、本発明によれば、パケットの読み飛ばし処理が不要になるため、パケットに付するヘッダを短くすることができ、効率的な通信を実現することが可能となる。更に、本発明によれば、処理負担軽減と異常状態検出時間の短縮という相反する条件を満たすことを可能とした、生存確認の技術を提供することが可能となる。

従来のトンネリング方式を示す図である。 従来のトンネリング方式を示す図である。 本発明の実施の形態におけるシステム構成図である。 第１の実施の形態におけるクライアント装置１の機能構成図である。 第１の実施の形態におけるクライアント装置１の機能をプロトコルスタックで表現した図である。 第１の実施の形態におけるトンネルサーバ装置１の機能構成図である。 第１の実施の形態におけるシーケンスチャートである。 第１の実施の形態におけるクライアント装置１のパケット送信時のフローチャートである。 第１の実施の形態におけるクライアント装置１のパケット受信時のフローチャートである。 第１の実施の形態におけるトンネルサーバ装置２のパケット受信時のフローチャートである。 破損データ受信時の処理の概念を示す図である。 第２の実施の形態におけるクライアント装置１のトンネル機能部１２の機能構成図である。 第２の実施の形態におけるトンネルサーバ装置２の機能構成図である。 第２の実施の形態におけるクライアント装置１のテーブル情報格納部１２４に格納されるテーブル例を示す図である。 第２の実施の形態におけるトンネルサーバ装置２のテーブル情報格納部２３に格納されるテーブル例を示す図である。 第２の実施の形態におけるトンネリング通信例を説明するための図である。 第２の実施の形態におけるシーケンスチャートである。 第２の実施の形態におけるクライアント装置１のトンネル接続処理のフローチャートである。 第２の実施の形態におけるトンネルサーバ装置２のトンネル接続時処理のフローチャートである。 第２の実施の形態におけるクライアント装置１のポートマップ要求処理のフローチャートである。 第２の実施の形態におけるトンネルサーバ装置２のポートマップ要求時処理のフローチャートである。 第２の実施の形態におけるクライアント装置１のポートマップ解除要求処理のフローチャートである。 第２の実施の形態におけるトンネルサーバ装置２のポートマップ解除要求時処理のフローチャートである。 第２の実施の形態におけるクライアント装置１のパケット送信処理のフローチャートである。 第２の実施の形態におけるクライアント装置１のパケット受信処理のフローチャートである。 第２の実施の形態におけるトンネルサーバ装置２のパケット送信処理のフローチャートである。 第２の実施の形態におけるトンネルサーバ装置２のパケット受信処理のフローチャートである。 第２の実施の形態におけるクライアント装置１のトンネル切断処理のフローチャートである。 第２の実施の形態におけるクライアント装置１のトンネル再接続処理のフローチャートである。 第３の実施の形態におけるクライアント装置１のトンネル機能部１２の機能構成図である。 第３の実施の形態におけるトンネルサーバ装置２の機能構成図である。 第３の実施の形態における処理の概要を説明するための図である。 第３の実施の形態におけるクライアント装置１の制御パケット受信時の処理を示すフローチャートである。 第３の実施の形態におけるクライアント装置１のパケット送信時処理のフローチャートである。 IPパケットの例を示す図である。 第３の実施の形態におけるクライアント装置１のデータパケット受信時処理のフローチャートである。 第３の実施の形態における生存確認動作シーケンス例である。 第３の実施の形態における生存確認動作シーケンス例である。

以下、図面を参照して本発明の実施の形態を説明する。

＜第１の実施の形態＞
（システム構成）
図３に、第１の実施の形態におけるシステムの全体構成を示す。図３に示すように、本実施の形態のシステムは、インターネット５と、企業内ネットワーク等のプライベートネットワーク６との境界に設置されるファイアフォール装置４、ファイアウォール装置４配下にあるクライアント装置１、トンネルサーバ装置２、及び、クライアント装置１と通信を行う通信相手装置３とを含む。本実施の形態では、トンネルサーバ装置２と、通信相手装置３は、インターネット５に接続されている。

クライアント装置１は、一般的なOS（オペレーティングシステム）と、IP電話や映像会議等の目的の通信を行うアプリケーションと、本発明に係るトンネル処理機能を備えるコンピュータ（PC、携帯端末等）である。

トンネルサーバ装置２は、クライアント装置１からの要求を受けてクライアント装置１との間にトンネルを形成し、クライアント装置１とトンネルを介した通信を行う機能を備えた装置である。ファイアウォール装置４は、当該トンネルの通信を許容するファイアウォール装置４である。なお、本実施の形態では、ファイアウォール装置４での通信が許容されているトンネルであれば、トンネルのプロトコルの種類はどのようなものでもよい。

本実施の形態における通信相手装置３は、例えばSIPサーバや、その他のアプリケーションサーバであり、クライアント装置１と通信を行う。もちろん、通信相手装置３は、同一または他のプライベートネットワーク内に備えられた他のクライアント装置であってもよい。

図４に、クライアント装置１の機能構成図を示す。図４に示すように、クライアント装置１は、データ通信部１１、トンネル機能部１２、アプリケーション部１３を備える。データ通信部１１は、パケット捕捉・放流部１４（パケット制御手段と称してもよい）を備える。

データ通信部１１は、通信ネットワークを介してデータ通信を行うための機能部であり、アプリケーション部１３から出力されるデータをIPパケットにしたり、その逆の処理を行う機能、IPパケットを入出力するネットワークインターフェースの機能等を含むものである。データ通信部１１が備えるパケット捕捉・放流部１４の機能については後述する。

アプリケーション部１３は、目的の通信サービス（例えば映像会議通信）を提供するためのアプリケーションに対応する機能部であり、例えば、SIP等の制御通信を行う機能、音声／映像等のメディア通信を行う機能等を含む。

トンネル機能部１２は、トンネルサーバに対応するトンネリングクライアントアプリケーションに相当し、トンネル処理部１２１と、破損データ処理部１２２を有している。トンネル処理部１２１は、パケット捕捉・放流部１４から受け取ったパケット（IPパケット）を、トンネル経由で送出する機能、及び、トンネル経由でパケットを受信したりする機能部である。より具体的には、トンネル処理部１２１は、受け取ったパケットを、例えばHTTPヘッダ等を用いてカプセリングし、カプセリングした後のパケットをデータ通信部１１を介して送出する機能や、トンネルヘッダでカプセリングされているパケットを受け取った場合に、トンネルヘッダのカプセリングをはずして中身のパケットを取り出し、当該パケットを、出力する機能等を有する。なお、本明細書において、「トンネル経由で送信する」等の表現や、「トンネル経由で受信する」等との表現は、実際には、上記のようにカプセリング／デカプセリングを行うことを意味している。

更に、本実施の形態においては、トンネル処理部１２１は、トンネルに送出するパケットの種別（制御パケット、データパケットの種別等）を示す識別子と、パケットの長さとからなるヘッダを付加したパケットを生成し、当該ヘッダ付きパケットをトンネルに送出する機能を有している。

破損データ処理部１２２は、トンネルから受信したパケットが破損しているか否かを調べ、破損していた場合に、トンネル接続を一旦切断するとともに、トンネルを再接続する等の破損データ処理機能を有している。

パケット捕捉・放流部１４は、データ通信部１１を流れるパケットを監視し、例えばトンネル機能部１２から指定される特定のIPアドレス及びポート番号、もしくは特定のポート番号（これらを通信情報と呼ぶことにする）を有するパケットを検知した場合には、当該パケットを取得（捕捉）し、トンネル機能部１２に渡す等の機能を有する。

本実施の形態では、アプリケーション部１３から送出されるパケットは、パケット捕捉・放流部１４で捕捉され、トンネル機能部１２に渡される。また、パケット捕捉・放流部１４は、トンネル機能部１２によりデカプセリングされたパケットを受け取り、それをアプリケーション部１３に向けて送出（放流）する。

なお、指定された特定の通信情報を有するパケット以外のパケットについては、データ通信部１１の機能により、パケットの種類・宛先等に応じて、アプリケーション部１３に渡されたり、外部に送出される。

図５は、図４に示す構成をソフトウェア（プログラムモジュール）のスタックイメージで表記した図である。図５において、図４との対応を分かりやすくするために、図４において対応する機能部に付された参照符号を付している。図５の記載位置からわかるように、パケット捕捉・放流部１４は、デバイスドライバにより実現することができる。なお、トンネルクライアントプログラムと、当該デバイスドライバは、コンピュータをトンネル機能部１２及びパケット捕捉・放流部１４として機能させるプログラムである。

図６に、トンネルサーバ装置２の機能構成図を示す。図６に示すように、本実施の形態におけるトンネルサーバ装置２は、トンネル処理部２１と破損データ処理部２２を有する。トンネル処理部２１は、クライアント装置１におけるトンネル処理部１２１に対応するトンネルサーバ処理を行う機能部である。また、破損データ処理部２２は、クライアント装置１における破損データ処理部１２２と同様にして、受信パケットの破損データ検知を行って、トンネル切断処理等を行う機能部である。

本実施の形態に係るクライアント装置１及びトンネルサーバ装置２のそれぞれは、CPU、記憶装置等を有するコンピュータに上記の各機能を実現するためのプログラムを実行させることにより実現できる。当該プログラムは可搬メモリ等の記録媒体からコンピュータにインストールすることとしてもよいし、ネットワーク上のサーバからダウンロードすることとしてもよい。

クライアント装置１を、上記のような構成としたことにより、トンネリングに係る処理は、アプリケーション部１３に対して隠蔽される。つまり、アプリケーション部１３は、トンネリングを意識することなく、トンネリング機能部がない場合と同様の通常の通信処理を行いながら、トンネリングを実現できる。

（システムの動作について）
次に、本実施の形態に係るシステムの動作概要について、図７のシーケンスチャートを参照して説明する。

まず、クライアント装置１におけるトンネル機能部１２が、トンネルサーバ装置２にトンネル接続要求を送信することにより、トンネルの設定（トンネル接続）を行う（ステップ１）。すなわち、トンネルサーバ装置２と、クライアント装置１のトンネル機能部１２とにおいて、トンネル通信を行うために必要な設定がなされる。なお、トンネル機能部１２は、例えば、アプリケーション部１３からの要求に基づき、トンネル接続を行ってよい。

その後、アプリケーション部１３からパケットが送出される。より詳細には、アプリケーション部１３から出力されるデータが、データ通信部１１によりIPパケット化されるが、ここでは便宜上、アプリケーション部１３からパケットが送出されると表現することにする（ステップ２）。

パケットは、パケット捕捉・放流部１４を経由して、トンネル機能部１２に届けられ、トンネル機能部１２において、パケットの種別を示す識別子と、パケットの長さ情報とをヘッダとして付加し、ヘッダ付きパケットをトンネル経由で送出する（ステップ３）。

送出されたヘッダ付きパケットは、トンネルを経由してトンネルサーバ装置２が受信する。トンネルサーバ装置２では、パケットの破損チェックが行われる。破損がなければ、ヘッダを取り外したパケットが、通信相手装置３に送信される。

また、通信相手装置３から送出されたパケットを受信したトンネルサーバ装置２は（ステップ５）、パケットにヘッダ（識別子と長さ）を付加し、ヘッダ付きパケットをトンネル経由で送出する（ステップ６）。

クライアント装置１におけるトンネル機能部１２は、トンネル経由でヘッダ付きパケットを受信し、破損チェックを行う。破損がなければ、ヘッダを取り外したパケットが、パケット捕捉・放流部１４を介してアプリケーション部１３に渡される（ステップ７）。

トンネルサーバ装置２もしくはクライアント装置１において、パケットの破損を検出した場合には、トンネルが切断され（ステップ８）、すぐにトンネルの再接続が行われ（ステップ９）、以降、ステップ２〜ステップ７と同様にしてパケット通信が行われる。

次に、各フローチャートを参照して、主要な処理について詳細に説明する。

まず、アプリケーション部１３からデータが送出される場合におけるクライアント装置１の動作を図８のフローチャートを参照して説明する。

アプリケーション部１３から送出されたデータは、データ通信部１１において通信情報が付加されたパケットにされる。そして、パケット捕捉部・放流部１４は、パケットにおける通信情報が、指定された通信情報と一致するか否かを調べる（ステップ１１）。一例として、より具体的には、、指定された通信情報は、OSが管理するソケット管理テーブルのようにメモリ等に格納されているものであり、パケット捕捉部・放流部１４は、発アドレスがクライアント装置１のアドレスであり、プロトコル種別および発ポート番号がアプリケーション部１３が所有するソケットに対応するものであるか否かの一致確認を行う。

監視しているパケットの通信情報が、指定された通信情報と一致する場合、パケット捕捉部・放流部１４は、当該パケットを捕捉し、捕捉したパケットをトンネル機能部１２に渡す。トンネル機能部１２は、パケット捕捉・放流部１４から受け取ったパケットに、識別子（IDとする)と長さ情報からなるヘッダを付加したヘッダ付きパケットを生成し、当該ヘッダ付きパケットをトンネル経由で送出する（ステップ１２）。

ステップ１１において、パケットにおける通信情報が、指定された通信情報と一致しない場合、パケットは、適切な宛先に転送されることになる。

次に、クライアント装置１におけるトンネル機能部１２が、トンネル経由でヘッダ付きパケットを受信した場合の動作を、図９のフローチャートを参照して説明する。

トンネル機能部１２は、例えば、ヘッダの識別子が予め定めた値と一致するかどうか、長さ情報が、実際のパケットの長さと一致するかどうか、等のチェックを行うことにより、パケットが破損しているか否かの判定を行う（ステップ２１）。パケットが破損していないと判定した場合、パケット機能部１２は、ヘッダを取り外したパケットを、パケット捕捉・放流部１４を介してアプリケーション部１３側に送出（放流）する（ステップ２２）。

ステップ２１において、パケットが破損していると判定された場合には、パケット機能部１２は、トンネル接続を一旦切断し（ステップ２３）、再び、トンネルサーバへ接続要求を送信することにより、トンネル接続を再開する（ステップ２４）。

次に、トンネルサーバ装置２が、トンネル経由でヘッダ付きパケットを受信した場合の動作を、図１０のフローチャートを参照して説明する。

トンネルサーバ装置２は、クライアント装置１のトンネル機能部１２と同様に、パケットが破損しているか否か判定する（ステップ３１）。パケットが破損していなければ、ヘッダを取り外したパケットをネットワークに送出する（ステップ３２）。ステップ３１において、パケットの破損が検出された場合には、トンネル接続を切断する。なお、このとき、クライアント装置１のトンネル機能部１２は、トンネルが切断されたことを検知し、再接続処理を行うことになる。

図１１に、トンネルサーバ装置２もしくはクライアント装置１における破損パケット受信時の処理の概念図を示す。図１１に示すように、トンネル経由で送信されるパケットに破損が検出されなければ、ヘッダを取り外したパケットが送出されるが、破損が検出された場合には、切断後、再接続されたトンネルにてヘッダ付きパケットが送信される。

このような処理を行うのは、パケットが破損している可能性が非常に低いことに基づく。そして、上記のように、パケット破損時に、切断／再接続を行うこととしたため、従来のように、パケットを読み飛ばして次のヘッダを検知する処理が不要になるので、ヘッダ（識別子等）の長さを従来に比べて非常に短くすることができる。その結果、通信のオーバーヘッドを、従来に比べて低減できる。

＜第２の実施の形態＞
次に、本発明の第２の実施の形態について説明する。第２の実施の形態では、ポートマッピングが行われる。

（システム構成）
本実施の形態における全体のシステム構成については、図３に示した第１の実施の形態でのシステム構成と同じである。以下では、主に、第１の実施の形態と異なる点を中心に説明する。

図１２に、本実施の形態におけるクライアント装置１のトンネル機能部１２の機能構成図を示す。図１２に示すように、本実施の形態に係るトンネル機能部１２は、破損データ処理部１２２、トンネル処理部１２１に加えて、アドレス・ポートの取得処理、管理、変換処理を行うアドレス・ポート処理部１２３、及び、テーブル情報格納部１２４を備える。

図１３に、本実施の形態におけるトンネルサーバ装置２の機能構成図を示す。図１３に示すように、本実施の形態におけるトンネルサーバ装置２は、破損データ処理部２２、トンネル処理部２１に加えて、アドレス／ポート情報の管理や払い出し等に係る処理を行うアドレス・ポート処理部２４、及びテーブル情報格納部２３を有する。

図１４に、クライアント装置１のテーブル情報格納部１２４に格納されるテーブルの例を示す。図１４に示すとおり、クライアント装置１のテーブル情報格納部１２４には、クライアント装置１のトンネル接続、セッションID、及びサーバアドレスを対応付けて記録するクライアント接続管理テーブルと、セッションID、マップしたポートのプロトコル種別、サーバポート番号、及びクライアントポート番号を対応付けて記録するクライアントポートマップテーブルと、クライアントアドレスを記録するクライアントアドレステーブルとを格納する。もちろん、クライアント装置１のテーブル情報格納部１２４等の記憶手段には、クライアント装置１のアドレスが格納されている。

図１５に、トンネルサーバ装置２のテーブル情報格納部２３に格納されるテーブルの例を示す。図１５に示すとおり、トンネルサーバ装置２のテーブル情報格納部２３には、サーバ接続管理テーブルと、サーバポートマップテーブルと、サーバ空きポートリストが格納される。

サーバ接続管理テーブルは、トンネル接続の識別子と、セッションIDとを対応付けて記録する。サーバポートマップテーブルは、セッションID、マップしたポートのプロトコル種別、及びポート番号を記録する。サーバ空きポートリストは、プロトコル種別毎に、トンネルサーバ装置２における空きポート番号を記録する。

（システムの動作）
まず、図１６を参照して、本実施の形態におけるトンネリング通信例について説明する。本例では、各装置に、図１６に示すとおりのアドレスが割り当てられているものとする。また、図１６には、トンネルを介して送受信されるパケットのヘッダ（通信情報）の中の情報も示されている。図１６の例において、クライアント装置１のトンネル機能部１２におけるテーブル情報格納部１２４には、トンネルサーバ装置１のアドレス（１２．２３．４５．７８）及びポート番号（１２３５）が、アプリケーション部１３が使用するポート番号であるクライアントポート番号（５５３４）及びクライアント装置１のアドレス（１０．１０．９．８）と対応付けて格納されている。

まず、アプリケーション部１３から、上りパケットが送信されると、パケット捕捉・放流部１４により、発アドレス（SRC_ADDR:10.10.9.8）がクライアント装置１のアドレス（10.10.9.8）と一致し、プロトコル種別（PROTOCOL:UDP）および発ポート番号（SRC_PORT:5534）がクライアントポートマップテーブルに存在することが確認され、当該上りパケットは、トンネル機能部１２に渡される。トンネル機能部１２では、上りパケットの発ポート番号（SRC_PORT:5534)に基づき、テーブル情報格納部１２４を検索し、当該発ポート番号に対応する発アドレス（SRC_ADDR:12.23.45.78)と、発ポート番号（SRC_PORT:1235）とを取得し、上りパケットにおける発アドレスと発ポート番号とを、上記取得した発アドレス（SRC_ADDR:12.23.45.78)と発ポート番号（SRC_PORT:1235）に変換する。そして、トンネル機能部１２は、変換を行った上りパケットをトンネル経由で送出する。

上りパケットをトンネル経由で受信したトンネルサーバ装置２は、上りパケットを通信相手装置３に送出する。

上りパケットには、発アドレス及び発ポート番号として、トンネルサーバ装置２のアドレス及びポート番号が設定してあるので、上りパケットを受信した通信相手装置３は、当該パケットは、トンネルサーバ装置２から送出されたものであると認識する。

その後、通信相手装置３は、宛先アドレス及び宛先ポート番号を、トンネルサーバ装置２のものに設定した下りパケットを送信する。下りパケットを受信したトンネルサーバ装置２は、当該下りパケットをトンネルを経由してクライアント装置１に送出する。

トンネルから下りパケットを受け取ったクライアント装置１のトンネル機能部１２は、テーブル情報格納部１２４を参照することにより、下りパケットにおける宛先アドレスと宛先ポート番号とを、クライアント装置１のアドレス（10.10.9.8）とポート番号（5534）に変換し、変換を行ったパケットを、パケット捕捉・放流部１４を介してアプリケーション部１３に送出する。

次に、図１７を参照して本実施の形態における処理のシーケンスを示す。このシーケンスに沿ってまずは処理の概要を説明する。

まず、アプリケーション部１３が、トンネル機能部１２に対して初期化要求を行うと（ステップ４１）、トンネル機能部１２は、初期化処理を行うとともに、トンネル接続要求をトンネルサーバ装置２に対して送信することにより、トンネルを設定する（ステップ４２）。ここでの初期化処理では、例えば、クライアントポートマップテーブル、及びクライアント接続管理テーブルのエントリを全てクリアする処理が行われる。

トンネル接続要求を受信したトンネルサーバ装置２は、トンネルを接続する。また、ここでトンネルサーバ装置２は、図１５に示すサーバ接続管理テーブルに、接続識別子とセッションＩＤを記録する。。

そして、トンネルサーバ装置２は、トンネルサーバ装置２のアドレスと、セッションIDとを含むトンネル接続応答を、クライアント装置１のトンネル機能部１２に返し、トンネル機能部１２は、アプリケーション部１３に対して初期化結果応答を返す。

上記の処理より、トンネルが設定され、以降のトンネルサーバ装置２とクライアント装置１間の通信は、トンネルを介して行われる。

その後、アプリケーション部１３は、ポートマップ要求をトンネル機能部１２に対して送信し（ステップ４５）、トンネル機能部１２は、ポートマップ要求をトンネルサーバ装置２に送信する（ステップ４６）。このポートマップ要求には、アプリケーション部１３が用いるプロトコル種別が含まれる。なお、ポートマップ解除要求も行うことが可能であるため、図１７においては、両方を含む意味で、ポート要求と記述している。

トンネルサーバ装置２は、空きのポート番号から１つのポート番号を払い出して、ポート要求結果に含めて、クライアント装置１のトンネル機能部１２に送信する（ステップ４７）。ポート番号を受信したトンネル機能部１２は、ポート番号をテーブル情報格納部１２４に格納するとともに、アプリケーション部１３に、ポート要求の結果応答を返す（ステップ４８）。

その後、図１６で説明したようなパケット通信が行われる（ステップ４９〜ステップ５４）。また、第２の実施の形態でも、第１の実施の形態と同様に、トンネルを経由して送受信されるパケットには、ヘッダ（識別子＋長さ）が付され、第１の実施の形態と同様にして、破損チェックが行われる。

破損が検出された場合等には、トンネルが切断され（ステップ５５）、トンネル再接続が行われる（ステップ５６）。このときのトンネル接続要求には、セッションIDが付加され、トンネルサーバ装置２からの応答には、セッションIDが含められる（ステップ５７）。これにより、トンネル切断後も、トンネル切断前と同じセッションIDのセッションを継続できる。

次に、各フローチャートを参照して、シーケンスに示した処理における主要な処理をより詳細に説明する。

図１８に、クライアント装置１におけるトンネル接続処理を示す。図１８に示すように、クライアント装置１のトンネル機能部１２は、トンネルサーバ装置１に接続を行った後（ステップ７１）、サーバアドレスとセッションIDをトンネルサーバ装置１から受信する（ステップ７２）。そして、トンネル機能部１２は、クライアント接続管理テーブル及びクライアントポートマップテーブルにエントリを追加する（ステップ７３）。

図１９に、トンネルサーバ装置２におけるトンネル接続時の処理を示す。図１９に示すように、トンネル接続要求を受信したトンネルサーバ装置２は、まず、トンネル接続要求にセッションIDが付加されているか否かをチェックする（ステップ８１）。

セッションIDがなければ、トンネルサーバ装置２は、擬似乱数からセッションIDを生成し（ステップ８２）、正常完了応答、サーバアドレス、及びセッションIDをトンネル経由でクライアント装置１に返す（ステップ８６）。
ステップ８１において、セッションIDがトンネル接続要求に含まれていた場合、トンネルサーバ装置２は、サーバ接続管理テーブルにおいて当該セッションIDが存在するかどうかをチェックし、存在しなければエラーを返す（ステップ８４）。存在する場合、サーバ接続管理テーブルのセッションIDに該当するエントリの接続識別子を更新し、ステップ８６に進む。

図２０に、クライアント装置１側でのポートマップ要求処理を示し、図２１に、トンネルサーバ装置２でのポートマップ要求時の処理を示す。

図２０に示すように、クライアント装置１側でのポートマップ要求処理においては、まず、トンネル機能部１２が、アプリケーション部１３からの要求に基づき、ポートマップ要求と、要求するプロトコル種別をトンネル経由でトンネルサーバ装置２に送信する（ステップ９１）。

正常終了応答が返ってきた場合に、トンネル機能部１２は、クライアント接続管理テーブルからセッションIDを取得し（ステップ９４）、クライアントポートマップテーブルに、セッションID、プロトコル種別、サーバポート番号、クライアントポート番号を追加する（ステップ９５）。

続いて、図２１を参照して、トンネルサーバ装置２側でのポートマップ要求に係る処理を説明する。

ポートマップ要求を受信したトンネルサーバ装置２は、サーバ空きポートリストから、要求に対応するプロトコル種別のエントリ（プロトコル種別、ポート番号）を取得するとともに、当該エントリをリストから削除する（ステップ１０１、１０３）。そして、サーバポートマップテーブルにエントリ（プロトコル種別、ポート番号、セッションID)を追加するとともに（ステップ１０４）、正常完了応答と、払い出したポート番号をトンネル経由でクライアント装置１に送信する（ステップ１０５）。なお、要求に対応するプロトコル種別のエントリがない場合にはエラーが返される（ステップ１０２）。

本実施の形態では、ポートマップによる通信が終了した場合等において、ポートマップ解除処理を行う。図２２に、クライアント装置１側のポートマップ解除処理を示し、図２３に、トンネルサーバ装置２側のポートマップ解除処理を示す。

まず、図２２を参照して、クライアント装置１側のポートマップ解除処理を説明する。アプリケーション部１３から、ポートマップ解除要求を受信したトンネル機能部１２は、アプリケーション部１３に対応する解除対象ポート番号が、クライアントポートマップテーブルに存在するかどうかをチェックし、存在しなければエラーを返す（ステップ１１１、１１２）。

解除対象ポート番号が存在する場合、トンネル機能部１２は、ポートマップ解除要求、解除するプロトコル種別、及び解除するポート番号（サーバポート番号）をトンネルサーバ装置２にトンネルを経由して送信する（ステップ１１３）。

その後、正常終了応答が返却されれば、トンネル機能部１２は、クライアント接続管理テーブルからセッションIDを取得し（ステップ１１５）、クライアントポートマップテーブルから、セッションIDに対応するエントリを削除する（ステップ１１６）。

次に、図２３を参照して、トンネルサーバ装置２側でのポートマップ解除要求に係る処理を説明する。

ポートマップ解除要求を受信したトンネルサーバ装置２は、要求に係るプロトコル種別とポート番号との組み合わせがサーバポートマップテーブルに存在するか否かをチェックし、存在しなければエラーを返し（ステップ１２１、１２２）、存在すればステップ１２３に進む。ステップ１２３において、トンネルサーバ装置２は、サーバポートマップテーブルから解除対象エントリを削除し（ステップ１２３）、空きポートリストにエントリを追加し（ステップ１２４）、正常完了をトンネルを経由してクライアント装置１に送信する（ステップ１２５）。

図２４に、クライアント装置１におけるパケット送信の際の処理を示し、図２５にクライアント装置におけるパケット受信の際の処理を示す。

まず、図２４を参照して、パケット送信の際の処理を説明する。パケット捕捉・放流部１４は、データ通信部１１を流れる個々のパケットを監視し、パケットにおける通信情報が、指定された通信情報と一致するか否かを調べる（ステップ１３１）。本実施形態では、発アドレスがクライアント装置１のアドレスであり、プロトコル種別および発ポート番号がクライアントポートマップテーブルに存在するプロトコル種別およびクライアントポート番号である場合に、パケットをトンネル機能部１３に渡す（トンネル送信する）ことが指定されており、パケット捕捉・放流部１４は、パケットの通信情報が上記条件に合致すること判定した場合に、パケットをトンネル機能部１２に渡す。

トンネル機能部１２は、図１６を参照して説明したとおりに、パケットの発アドレスをサーバアドレスに書き換え、発ポート番号をサーバポート番号に書き換える（ステップ１３２）。そして、トンネル機能部１２は、識別子と長さ情報からなるヘッダを付加したヘッダ付きパケットを生成し、当該ヘッダ付きパケットをトンネル経由で送出する（ステップ１３３）。

次に、クライアント装置１におけるトンネル機能部１２が、トンネル経由でヘッダ付きパケットを受信した場合の動作を図２５のフローチャートを参照して説明する。

まず、パケットを受信したトンネル機能部１２は、それが切断通知か否か判定する（ステップ１４１）。切断通知である場合には、トンネル切断処理を行う（ステップ１４２）。

切断通知でない場合、第１の実施の形態と同様にして、トンネル機能部１２は、パケットが破損しているか否かの判定を行う（ステップ１４３）。パケットが破損していないと判定した場合、パケット機能部１２は、パケットからヘッダを取り外し（ステップ１４４）、宛先アドレスをローカルアドレスに、宛先ポート番号をローカルポート番号に書き換え、書き換えたパケットをパケット捕捉・放流部１４を介してアプリケーション部１３側に送出する（ステップ１４５）。

ステップ１４３において、パケットが破損していると判定された場合には、パケット機能部１２は、トンネル再接続処理を行う（ステップ１４６）。

図２６に、トンネルサーバ装置２において、通信相手装置３から受信したパケットをトンネルに送信する際の処理を示し、図２７にトンネルサーバ装置２においてトンネルからパケットを受信する際の処理を示す。

トンネルサーバ装置２は、通信相手装置３から受信したパケットの宛先ポート番号を参照し、まず、サーバポートマップテーブルから、当該ポート番号（サーバポート番号）に対応するセッションIDを探し（ステップ１５１）、無ければパケットを廃棄し（ステップ１５２）、あればセッションIDを取得する（ステップ１５３）。そして、セッションIDに対応する接続識別子を取得し、パケットにヘッダ（識別子＋長さ）を付し、ヘッダ付きパケットを、接続識別子に対応付けて設定してあるトンネル経由で送信する（ステップ１５４）。

次に、図２７を参照して、トンネルサーバ装置２においてトンネルからパケットを受信する際の処理を説明する。

トンネルサーバ装置２は、受信したパケットが切断通知であるかどうかをチェックし（ステップ１６１）、切断通知である場合、サーバ接続管理テーブル、及びポートマップテーブルの該当エントリをクリアし、トンネル接続を切断する（ステップ１６５、１６３）。

受信したパケットが切断通知でない場合、クライアント装置のトンネル機能部と同様に、パケットが破損しているか否か判定する。パケットが破損していなければ、ヘッダを取り外したパケットをネットワークに送出する（ステップ１６２、１６４）。ステップ１６２において、パケットの破損が検出された場合には、トンネル接続を切断する（ステップ１６３）。

なお、このとき、クライアント装置１のトンネル機能部１２は、トンネルが切断されたことを検知し、再接続処理を行うことになる。

次に、図２８を参照して、クライアント装置１側での、アプリケーション部１３からの指示に基づくトンネル切断処理を説明する。

アプリケーション部１３から、トンネル切断要求を受けたトンネル機能部１２は、トンネルサーバ装置２に対して切断通知を送信し（ステップ１７１）、トンネルサーバ装置１との接続を切断する（ステップ１７２）。そして、トンネル機能部１２は、セッションIDをクライアント接続管理テーブルから取得し（ステップ１７３）、セッションIDをキーとして、クライアントポートマップテーブル、及びクライアント接続管理テーブルのエントリをクリアする（ステップ１７４）。

次に、図２９を参照して、クライアント装置１側におけるトンネル再接続処理（パケット破損時等）を説明する。

まず、トンネル機能部１２は、トンネルサーバ装置２との接続を一旦切断する（ステップ１８１）。そして、トンネル機能部１２は、トンネルサーバ装置１８２に接続し（ステップ１８２）、切断前に接続していたトンネル接続のセッションIDをトンネルサーバ装置２に送信し（ステップ１８３）、トンネルサーバ装置２からサーバアドレスとセッションIDを受信する（ステップ１８４）。なお、サーバ側でパケット破損があった場合等、意図しないトンネル切断があった場合は、ステップ１８２から開始する。

トンネル機能部１２は、送信したセッションIDと受信したセッションIDとが同一であるか否かを確認し（ステップ１８５）、同一であればここでの処理を終了する。つまり、この場合、切断前のセッションIDにてトンネル通信が行われることになる。

ステップ１８５にて、送信したセッションIDと受信したセッションIDとが同一でなかった場合、旧セッションIDのテーブルエントリがクリアされ、新セッションIDでのエントリが追加される（ステップ１８６、１８７）。その後は、新セッションIDにてトンネル通信が行われる。

つまり、本実施の形態では、切断と再接続の場合に、セッションIDを使用して、既に行われているポートマッピングの状態を保持することとしている。

＜第３の実施の形態＞
次に第３の実施の形態について説明する。本実施の形態における全体のシステム構成については、図３に示した第１の実施の形態でのシステム構成と同じである。また、クライアント装置１とトンネルサーバ装置２は、第１及び第２の実施の形態で説明した機能を含むものとする。以下、第１及び第２の実施の形態と異なる点を中心に説明する。

図３０に、本実施の形態におけるクライアント装置１のトンネル機能部１２の機能構成図を示す。図３０に示すように、本実施の形態におけるクライアント装置１のトンネル機能部１２は、第２の実施の形態での構成に加えて、生存確認処理部１２５及び時間情報格納部１２６を有する。

生存確認処理部１２５は、後述する生存確認に係る処理を行う機能とともに、当該処理ためのタイマーとして、（従来と同様の）生存確認要求を送信するタイミング決定用のタイマー１（一例として30秒程度）、受信途切れ検出用のタイマー２（一例として一秒程度）、及び、切断検出時間計測用のタイマー３（一例として３秒程度）を備えている。時間情報格納部１２６には、後述するRTT、最終送信時刻、平均送信間隔、要求送信時刻等の時間情報が格納されるとともに、受信予測フラグの情報も格納される。

図３１に、本実施の形態におけるトンネルサーバ装置２の機能構成図を示す。図３１に示すように、本実施の形態におけるトンネルサーバ装置２は、第２の実施の形態での構成に加えて、生存確認のための処理を行う生存確認処理部２５及び時間情報格納部２６を有する。時間情報格納部２６には、後述する最終受信時刻等が格納される。

次に、図３２、及び各フローチャートを適宜参照して、本実施の形態における処理を説明する。図３２におけるトンネルサーバ装置２と、クライアント装置１（トンネル機能部１２）間の通信はトンネルを介した通信である。

まず、クライアント装置１のトンネル機能部１２は、初期化処理を行う。初期化処理では、RTT値を０に設定し、現在時刻を最終送信時刻にセットする。そして、タイマー１をスタートさせ、受信予測フラグをクリアする（例えば０にする）。なお、受信予測フラグは、データパケットの受信途切れを検知するためのフラグであり、データパケットを受信した場合にセットされ、当該フラグがセットされた状態で、タイマー２が満了した場合に、生存確認要求が送信される。

トンネル機能部１２は、ポートマップ要求等の制御パケット（アプリケーション部１３から送信されるデータを含むデータパケット以外のパケット）を送信する場合に、送信する時刻を「要求送信時刻」として記録しておく。

特に、制御パケットとして生存確認要求を送信する場合には、送信する時刻を「要求送信時刻」として記録しておくとともに、生存確認要求応答待ち時間満了（つまり、切断）を検知するためのタイマー３を始動させる。タイマー３がタイムアウトした場合は、現在のトンネル接続を切断し、トンネル再接続を実行することになる。

トンネル機能部１２が、制御パケットに対する応答を受信した場合には、当該受信時刻に基づき、パケットがトンネルサーバ装置２とクライアント装置１との間を往復する時間であるRTT(Round Trip Time)を決定し、それを時間情報格納部１２６に格納する。

図３３は、制御パケット受信時におけるトンネル機能部１２の処理をより詳細に示した図である。図３３を参照して、制御パケット受信時の処理をより具体的に説明する。

図３３に示すように、制御パケットのうち、生存確認要求応答を受信した場合には、タイマー１を始動させ（既に始動していた場合には一旦停止し再始動させ）、タイマー３を停止する（ステップ１９１）。その後、ステップ１９２に進む。生存確認要求応答以外の制御パケットの場合は、ステップ１９２から開始する。

ステップ１９２において、トンネル機能部１２は、受信予測フラグをクリアし、タイマー２を停止する。そして、現在時刻−要求送信時刻を算出し、それを応答時間とし、応答時間が現在のRTT値より大きいかどうかをチェックし、大きくなければ処理を終了し、大きければ、当該応答時間をRTT値として時間情報格納部１２６に格納する。すなわち、ここでの処理により、セッションの中での最大のRTTが、記録されることになる。

図３２に戻り、クライアント装置１は、パケット（制御パケットパケットを含む全ての種類のパケット）を送信する度に、当該パケットの送信時刻を「最終送信時刻」として、時間情報格納部１２６に格納し、当該「最終送信時刻」に基づき、「平均送信間隔」を計算し、それを時間情報格納部１２６に格納しておく。

より具体的には、図３４のフローチャートに示すように、トンネル機能部１２は、まず、現在時刻−最終送信時刻を、送信間隔とする。そして、時間情報格納部１２６に格納されている平均送信間隔を取得し、当該平均送信間隔を用いて、α×送信間隔＋（１−α）×平均送信間隔を計算し、これを新たな平均送信間隔として時間情報格納部１２６に格納する。αは、０から１の間の定数であり、事前に定めておくものである。

そして、トンネル機能部１２は、現在時刻を、「最終送信時刻」として時間情報格納部１２６に格納する。

図３２に戻り、トンネルサーバ装置２は、クライアント装置１からパケット（制御パケットパケットを含む全ての種類のパケット）を受信する度に、受信時刻を「最終受信時刻」として時間情報格納部２６に格納しておき、データパケット（制御パケットでないデータのIPパケット）の送信時に、当該データパケットの送信時刻の「最終受信時刻」からの経過時間を、IPパケットヘッダの所定の領域（本実施形態ではチェックサム欄）に上書きして送信する。図３５に、チェックサム欄を含むIPパケットの構成を示す。

クライアント装置１のトンネル機能部１２が、トンネルサーバ装置１からデータパケットを受信した際の処理は、図３６に示すとおりである。

図３６に示すように、トンネル機能部１２が、データパケットを受信すると、まず、受信予測フラグをセットして（ステップ２１１）、タイマー２を始動する（ステップ２１２）。

また、トンネル機能部１２は、パケットを受信した時刻（「現在時刻」）の「最終送信時刻」からの経過時間（現在時刻−最終送信時刻）を算出し、当該経過時間が２×RTT以上である場合には、「チェックサム欄」が（「現在時刻」−「最終送信時刻」）より大きい場合にのみ生存確認要求をトンネルサーバ装置１に送信する（ステップ２１３、２１４、２１５）。

上記経過時間が、２×RTT未満の場合には、「チェックサム欄」が「平均送信間隔」×４よりも大きい場合にのみ、生存確認要求を送信する（ステップ２１３、２１６、２１５）。

すなわち、クライアント装置１から前回のパケットを送信した時刻（最終送信時刻）から、今回のデータパケットを受信した時刻までの経過時間がRTTと比較してある程度長い場合（本実施形態では、RTTの２倍以上）、生存確認の役割を果たすべき、クライアント装置から送信するパケットの時間間隔が長くなっている可能性を予想できる。

そこで、この場合、サーバ側での経過時間（チェックサム欄）と、クライアント側での経過時間を比較し、サーバ側での経過時間のほうが短い場合には、クライアント装置１から送ったパケットがサーバに届いており、生存確認の役割を果たしていると判断できるため、生存確認要求を送出しない。一方、サーバ側での経過時間のほうが長い場合には、クライアント装置１から前回送信したパケットが正常にトンネルサーバに届いていないことを想定できるため、前回送信したパケットが生存確認の役割を果たしていないと推定でき、生存確認要求を送信することとしている。

一方、クライアント装置１から前回のパケットを送信した時刻（最終送信時刻）から、データパケットを受信した時刻までの経過時間がRTTと比較してある程度短い場合（本実施形態では、RTTの２倍未満）、前回送信したパケットに対応するデータパケットではなく、それ以前の送信パケットに対応するデータパケットを受信したこと等を想定できる。

そこで、この場合は、サーバ側での経過時間が、平均送信間隔よりもある程度長いか否か（本実施形態では、平均送信間隔×４より長いか否か）をチェックしている。サーバ側での経過時間が、平均送信間隔よりもある程度長くないのであれば、クライアント装置１が受信したデータパケットを送信したサーバにおいて、前回受信されたパケットにて、生存確認が成立していると判断できるので、生存確認要求送信は行われない。

一方、サーバ側での経過時間が、平均送信間隔よりもある程度長い場合には、サーバにおいて、前回受信されたパケットによる生存確認以降、クライアント装置１からの生存確認の役割を果たすパケット送信が行われていないことを推定できるため、生存確認要求を送信することとしている。

一方、上記のチェックと並行して、クライアント装置１は、データパケット受信時にタイマー２を起動した後、パケットを受信せずに、タイマー２の時間が経過した場合に生存確認要求を送信する。つまり、受信途切れを検出した場合に、生存確認要求を送信している。

また、クライアント装置１は、タイマー１を用いて、タイマー１が満了する度に、一定時間間隔で生存確認要求送出を行っている。

図３７は、生存確認動作概念の一例を示す図である。図３７に示す例は、データパケットの送受信が全く行われていなかった場合の例であり、この場合、タイマー１のタイムアウト毎に、定期的に生存確認要求送信が行われることになる。

図３８は、生存確認動作概念の他の例を示す図である。図３８に示す例において、前述したとおり、クライアント装置１には、トンネルサーバ装置２での最終受信時刻からの経過時間をチェックサム欄に含むデータパケットが届けられる。そして、前述したロジックで、パケット毎にRTTや平均送信間隔の値から異常判定を行うことにより、生存確認要求送出要否が判定される。更に、データパケット受信時に起動するタイマー２により、データパケットの受信途切れをチェックし、受信途切れを検知した場合には、その都度生存確認要求を送信することとしている。

本方式により、データが途切れることなく送受信されている場合には、送受信データ自身が生存確認の役割を果たすため、生存確認要求を行わず、一方、図３６に示したロジックで異常を検知した場合や、タイマー２でデータの途切れを検知した場合には、生存確認要求を送信することとしているので、従来技術に比べて、生存確認要求自身の送信に係る負担を減らしながら、データ通信中は、比較的短時間で異常を検出でき、効率的なデータ通信が可能になる。

＜実施の形態のまとめ、効果について＞
本発明の実施の形態では、アプリケーション部１３が、通常の通信ライブラリを使用して送受信するパケットを、ネットワークインタフェースの直前に設けたパケット捕捉・放流部１４により捕捉し、トンネルを使って送信する。逆に、トンネルから送られてきたパケットを、パケット捕捉・放流部１４から放流し、OSのプロトコルスタックを経由してアプリケーション部１３に引き渡している。

また、破損データ対応では、ヘッダを短くし、パケットをトンネルから受信する段階で、破損データを発見した場合には、そもそもトンネル処理が破綻しているとみなし、トンネルを切断し、再接続を行うことで、破損データの読み飛ばし処理を省略している。

また、本発明の実施の形態では、トンネル機能部１２は、トンネルの利用開始に先立ち、トンネルサーバ装置２が持つアドレスを取得する。そして、アプリケーション部１３は、自らが通信に利用するポート番号をトンネル機能部１２に対して予め宣言し予約すると同時に、トンネル機能部１２は、トンネルサーバ装置２側に、対応するポート番号を割り当ててもらい、トンネル機能部１２は、そのポート番号を受信する。

その結果、宣言したポートのパケットのみがトンネルを通じて送受信され、また、送受信に際してはIPアドレス及びポート番号変換が行われる。また、トンネル接続の際は、再接続に備えて、セッションIDをトンネルサーバが払い出し、再接続が発生した場合に、セッションIDを提示することで、ポートマッピング状態を引き継ぐこととしている。

また、本発明の実施の形態では、トンネル接続が正常動作するか否かを確認するための生存確認要求以外に、データパケットや、データパケット以外の制御パケットの応答時間等を利用して効率的に生存確認要求を行っている。具体的には、トンネル機能部１２が、トンネルサーバ装置２からデータパケットを受信した際には、最終送信時刻からの経過時間を調べ、それが２×RTT以上の場合であって、チェックサム欄＞現在時刻−最終送信時刻の場合には、生存確認要求を送信し、２×RTT未満の場合には、「チェックサム欄」＞平均送信間隔×４の場合に、生存確認要求を送信する。更に、データパケット受信時に、前述したタイマー２を起動し、データパケットが途切れてタイマー２の時間が経過した場合にも、生存確認要求を送信する。

本実施の形態で説明した技術を用いることにより、アプリケーションの改造等が少なく、効率の良く安定（かつセキュアな）した通信経路を提供することが可能となる。より具体的には以下のとおりである。

トンネル機能を実現するために、ネットワークインタフェースの直前に、パケット捕捉・放流部１４を設けた。これにより、アプリケーション部１３は、OSが提供するプロトコルスタックをそのまま使用することができるため、改造が不要あるいは小規模で済む。これは、オブジェクト形式で提供される既存ソフトウェアやライブラリを使用しなければならない場合に特に有用である。また、OSが提供するプロトコルスタックをそのまま使用するため、自前でのプロトコル処理が不要となり、OSのプロトコルスタックとの仕様の差分による不安定要因を持たずに済む上、トンネル機能部１３の実装が小規模で済む。

破損データ対応では、ヘッダを短くすることにより、パケット送信毎に必要だったオーバーヘッドを省略することができ、結果として伝送効率を向上させることができる。特に、トンネル接続として、HTTPSのように接続が暗号化され途中ノードで復号されない場合、通常はトンネルデータが破損することはなく、ヘッダ短縮の効果がより大きくなる。更に、伝送路のMTU（Message Transfer Unit)サイズに上限がある場合に、トンネリングのためのオーバーヘッドでそれを越えやすくなってしまうが、本実施の形態による技術では、ヘッダ長が短いために、同じMTUの中でより大きなパケットを伝送できる。

第２の実施の形態で説明したポートマッピング方式では、予めアプリケーション部１３等から指定された特定ポートのパケットのみを伝送する方式とした。これにより、アプリケーション部１３が使用する必要最低限のポートのみが外部に対して開かれることになり、外部からの侵入や攻撃、あるいはトロイの木馬等による内部からの情報流出のリスクを最小化することができる。

また、アドレス・ポート変換を行うことにより、トンネルサーバ側に割り当てられたIPアドレスを複数のトンネルクライアントでポート単位に分割して利用できるため、枯渇が心配されているＩＰv４のグローバルIPアドレス等を節約して利用することができる。また、従来技術の複数の仮想ネットワークアダプタが存在する方式に比べて、ルーティングが単純なままで通信することができるため、ルーティングに起因するトラブルを未然に防止することができる。

また、第３の実施の形態として説明した技術によれば、無通信の場合は、単純な生存確認要求を送付する場合と同程度の間隔で生存確認要求を実現できる。また、データパケットによる通信が行われている場合には、データパケット毎に応答悪化を検出可能な点に加えて、定常的なデータパケットの受信が途切れた段階で、生存確認要求を送付することとしているので、通信中の異常検出を短時間で実施することができる。

また、データパケットがIPパケットである場合、受信時のポート書き換えで再計算しなければならず、伝送が無意味なIPパケットのチェックサム欄を利用することで、適宜発せられる生存確認要求パケットを除き、本実施の形態に係る通信オーバーヘッドは無いことになる。

本発明は、上記の実施の形態に限定されることなく、特許請求の範囲内において、種々変更・応用が可能である。

１ クライアント装置
２ トンネルサーバ装置
３ 通信相手装置
４ ファイアフォール装置
５ インターネット
６ プライベートネットワーク
１１ データ通信部
１２ トンネル機能部
１３ アプリケーション部
１４ パケット捕捉・放流部
２１ トンネル処理部
２２ 破損データ処理部
２３ テーブル情報格納部
２４ アドレス・ポート処理部
２５ 生存確認処理部
２６ 時間情報格納部
１２１ トンネル処理部
１２２ 破損データ処理部
１２３ アドレス・ポート処理部
１２４ テーブル情報格納部
１２５ 生存確認処理部
１２６ 時間情報格納部

Claims (10)

1. トンネルサーバ装置との間に構築されたトンネルを介して、通信相手装置とデータ通信を行うクライアント装置であって、
   前記トンネルサーバ装置との間で前記トンネルを構築し、当該トンネルを経由してパケットの送受信を行うトンネル機能手段と、
   通信ネットワークを介してデータ送受信を行うためのデータ通信手段と、
   前記データ通信手段を経由するパケットを監視し、当該パケットの通信情報に基づき、当該パケットが、前記クライアント装置が備えるアプリケーション部から出力されたパケットであると判定した場合に、当該パケットを前記トンネル機能手段に渡すパケット制御手段とを備え、
   前記トンネル機能手段は、前記パケット制御手段から受け取った前記パケットを、前記トンネルを経由して前記通信相手装置に向けて送信する
   ことを特徴とするクライアント装置。
2. 前記パケット制御手段は、前記トンネル機能手段から、前記トンネルを経由して受信したパケットを受け取り、当該パケットを前記データ通信手段を介して前記アプリケーション部に送出することを特徴とする請求項１に記載のクライアント装置。
3. 前記トンネル機能手段が前記トンネルを経由して受信するパケットには、ヘッダが付されており、
   前記トンネル機能手段は、
   前記ヘッダの情報に基づき、前記パケットが破損しているか否かを判定し、当該パケットが破損していると判定した場合に、前記トンネルを切断し、その後に、前記トンネルサーバ装置との間にトンネルを再構築する破損処理手段を備える
   ことを特徴とする請求項１又は２に記載のクライアント装置。
4. 前記トンネル機能手段は、
   前記トンネルサーバ装置から、当該トンネルサーバ装置のアドレスとポート番号であるサーバアドレスとサーバポート番号を受け取り、当該サーバアドレスとサーバポート番号とを、前記アプリケーション部に対応するクライアントポート番号に対応付けて記憶手段に格納し、
   前記パケット制御手段から、前記クライアントポート番号を発ポート番号として含むパケットを受け取った場合に、前記記憶手段を参照することにより、前記パケットにおける発アドレスを前記サーバアドレスに変換し、前記パケットにおける発ポート番号を前記サーバポート番号に変換し、当該変換を施したパケットを前記トンネルを経由して送出する
   ことを特徴とする請求項１ないし３のうちいずれか1項に記載のクライアント装置。
5. 前記トンネル機能手段は、
   前記トンネルを経由して、前記サーバアドレスを宛先アドレスとして含み、前記サーバポート番号を宛先ポート番号として含むパケットを受信した場合に、前記記憶手段を参照することにより、前記パケットにおける宛先アドレスを前記クライアント装置のアドレスに変換し、前記パケットにおける宛先ポート番号を前記クライアントポート番号に変換し、当該変換を施したパケットを、前記パケット制御手段を介して前記アプリケーション部に送出する
   ことを特徴とする請求項４に記載のクライアント装置。
6. 前記トンネルサーバ装置は、前記クライアント装置からパケットを受信する度に、当該パケットの受信時刻を最終受信時刻として記憶手段に保持し、データパケットを送信する場合には、当該データパケットの送信時刻の前記最終受信時刻からの経過時間を算出し、当該経過時間をサーバ側経過時間として前記データパケットに含めて送信し、
   前記トンネル機能手段は、
   パケットを前記トンネルサーバ装置に送信する度に、当該パケットの送信時刻を最終送信時刻として記憶手段に保持し、
   前記トンネルサーバ装置から、前記データパケットを受信した場合に、当該データパケットの受信時刻の前記最終送信時刻からの経過時間をクライアント側経過時間として算出し、
   前記データパケットから取得したサーバ側経過時間と、前記クライアント側経過時間とに基づき、前記トンネルサーバ装置に対して生存確認要求を送信するか否かを決定する
   ことを特徴とする請求項１ないし５のうちいずれか1項に記載のクライアント装置。
7. 前記トンネル機能手段は、
   前記クライアント側経過時間が、所定の時間以上である場合には、前記サーバ側経過時間が前記クライアント側経過時間より大きい場合に、生存確認要求を送信し、
   前記クライアント側経過時間が、前記所定の時間未満である場合には、前記サーバ側経過時間が、パケットの送信時刻から算出される平均送信間隔の所定数倍以上である場合に、生存確認要求を送信する
   ことを特徴とする請求項６に記載のクライアント装置。
8. 前記所定の時間は、前記クライアント装置と前記トンネルサーバ装置間におけるラウンドトリップ時間の２倍の時間であり、前記所定数は４であることを特徴とする請求項７に記載のクライアント装置。
9. 前記トンネル機能手段は、前記トンネルサーバ装置からデータパケットを受信した後、その後にパケットを受信することなく、所定のタイマー時間が経過した場合に、生存確認要求を送信することを特徴とする請求項６ないし８のうちいずれか１項に記載のクライアント装置。
10. コンピュータを、請求項１ないし９のうちのいずれか１項に記載のクライアント装置におけるトンネル機能手段、及びパケット制御手段として機能させるためのプログラム。

Images