JP2020048127A - 制御装置、制御方法、及びプログラム - Google Patents

Abstract

【課題】閉域網を介した通信を行うユーザ端末が、インターネット上の所定のサーバに高速にアクセスする。【解決手段】複数の網に接続され、ユーザ端末から受信したパケットを当該複数の網のうちのいずれかの網に振り分ける制御装置において、前記ユーザ端末から送信されたＤＮＳ問い合わせパケットを受信し、当該ＤＮＳ問い合わせパケットの問い合わせ対象に基づいて、当該ＤＮＳ問い合わせパケットを前記複数の網のうちのいずれかの網に振り分けるＤＮＳ制御部と、パケットを受信し、当該パケットの宛先アドレスに基づいて当該パケットの送信先を決定し、決定された送信先に当該パケットを送信するルーティング部とを備える。【選択図】図２

Description

本発明は、ユーザ端末からネットワーク上のサーバなどへのアクセスを高速化する技術に関連するものである。

近年、Ｓｏｆｔｗａｒｅ−ａｓ−ａ−Ｓｅｒｖｉｃｅ（ＳａａＳ）の利用が爆発的に普及してきた。一方、ＳａａＳでは、元々ＬＡＮ環境での利用を想定して設計されていたアプリケーションがＣｌｏｕｄ上で提供されるため、そのパフォーマンスはネットワークの遅延や品質に左右され、特に企業がグローバル展開するほどネットワークの遅延や品質の影響が大きくなる。

現状では、閉域網である企業ネットワークはＳａａＳ利用に向けて設計されていない。例えば、多くの企業ネットワークではインターネットへの接続点は限られているので、インターネットを経由するＳａａＳ接続が遠回りになってしまう。

また、企業ネットワーク内の通信である拠点間の通信とＳａａＳ向けの通信とを同一回線に重畳する場合、拠点間などで回線の帯域が圧迫される。２０２０年ごろには半分以上の企業がネットワークに関連するＳａａＳ利用上の問題を抱えるという予測もある。

北米の大手金融／流通／小売りなどの企業のＩＴ責任者を中心に立ち上げたＯＮＵＧ（Ｏｐｅｎ Ｎｅｔｗｏｒｋｉｎｇ Ｕｓｅｒ Ｇｒｏｕｐ）という団体でＳＤ−ＷＡＮ（Ｓｏｆｔｗａｒｅ−ｄｅｆｉｎｅｄ ＷＡＮ）の技術が提唱されてきた。現在のＷＡＮコストの削減、運用の簡略化、品質の向上などを狙い、多くの企業が市販のＳＤ−ＷＡＮソリューションを導入し始めた。ＳＤ−ＷＡＮの利用において、一番有望視されているユースケースがＳａａＳアクセスを中心としたＬｏｃａｌ Ｂｒｅａｋｏｕｔと言われている。

Ｌｏｃａｌ Ｂｒｅａｋｏｕｔとは、ブランチ拠点において、ＳａａＳにアクセスする際に、特定のデータフローをＤｅｅｐ Ｐａｃｋｅｔ Ｉｎｓｐｅｃｔｉｏｎ（ＤＰＩ）エンジンを用いて識別し、識別された該当データフローをブランチ拠点からインターネットに直接流すようにルーティングを制御する仕組みである。

ＳＤ−ＷＡＮ Ｃｕｓｔｏｍｅｒ Ｐｒｅｍｉｓｅｓ Ｅｑｕｉｐｍｅｎｔ（ＣＰＥ）の利用により、Ｌｏｃａｌ Ｂｒｅａｋｏｕｔを実現し、ＳａａＳ向けのトラフィックをブランチ拠点からインターネットに直接流すことによって、上記の様々な問題の解決が期待されている。

特許第５８３２９７０号

しかし、従来のＳＤ−ＷＡＮ技術を用いたＳａａＳアクセス方法は実際の利用シーンに最適化されていない場合が多いため、ユーザ端末からＳａａＳサーバへのアクセスに遅延が生じるなどの課題がある。

本発明は上記の点に鑑みてなされたものであり、閉域網を介した通信を行うユーザ端末が、インターネット上の所定のサーバに高速にアクセスすることを可能とする技術を提供することを目的とする。

開示の技術によれば、複数の網に接続され、ユーザ端末から受信したパケットを当該複数の網のうちのいずれかの網に振り分ける制御装置であって、
前記ユーザ端末から送信されたＤＮＳ問い合わせパケットを受信し、当該ＤＮＳ問い合わせパケットの問い合わせ対象に基づいて、当該ＤＮＳ問い合わせパケットを前記複数の網のうちのいずれかの網に振り分けるＤＮＳ制御部と、
パケットを受信し、当該パケットの宛先アドレスに基づいて当該パケットの送信先を決定し、決定された送信先に当該パケットを送信するルーティング部と
を備える制御装置が提供される。

開示の技術によれば、閉域網を介した通信を行うユーザ端末が、インターネット上の所定のサーバに高速にアクセスすることを可能とする技術が提供される。

本発明の実施の形態におけるシステムの全体構成図である。 第１の実施の形態におけるアクセス装置１００の機能構成図である。 アクセス装置１００のハードウェア構成図である。 アプリケーション管理ＤＢに格納される情報の例を示す図である。 アプリケーションキャッシュに格納される情報の例を示す図である。 ＤＮＳ振り分けポリシー管理ＤＢに格納される情報の例を示す図である。 ＩＰルーティングポリシー管理ＤＢ及びアプリルーティングポリシー管理ＤＢに格納される情報の例を示す図である。 第１の実施の形態におけるマネジメントフロー制御のフローチャートである。 第１の実施の形態におけるデータフロー制御のフローチャートである。 ＤＮＳの問い合わせの宛先を書き換える場合のＤＮＳ制御部の構成図である。 ＤＮＳの問い合わせの宛先を書き換える場合のアプリルーティングポリシー管理ＤＢに格納される情報の例を示す図である。 ＤＮＳの問い合わせの宛先を書き換える場合におけるデータフロー制御のフローチャートである。 ＤＮＳの問い合わせ結果を用いてアプリケーションキャッシュを随時更新する場合のフローチャートである。 ＤＮＳの問い合わせ結果を用いてアプリケーションキャッシュを随時更新する場合のアプリケーションキャッシュを示す図である。 第２の実施の形態におけるアクセス装置１００の機能構成図である。 ＩＰルーティングポリシー管理ＤＢ及びアプリルーティングポリシー管理ＤＢに格納される情報の例を示す図である。 プロキシ振り分けポリシー管理ＤＢに格納される情報の例を示す図である。 第２の実施の形態におけるマネジメントフロー制御のフローチャートである。 第２の実施の形態におけるデータフロー制御のフローチャートである。 アプリケーションキャッシュを利用する場合におけるプロキシ振り分けポリシー管理ＤＢに格納される情報の例を示す図である。 アプリケーション管理ＤＢの定期的更新を説明するための図である。 アプリケーション管理ＤＢの定期的更新のフローチャートである。 アプリケーションキャッシュに格納される情報の例を示す図である。

以下、図面を参照して本発明の実施形態を説明する。以下で説明する実施形態は一例に過ぎず、本発明が適用される実施の形態は、以下の実施形態に限られるわけではない。

（課題について）
まず、実施の形態で説明するアクセス装置１００により解決される課題について説明する。なお、以下の３つの課題は例であり、アクセス装置１００により解決される課題は下記の課題に限られない。

（１）ＤＮＳについての課題
多くのＳａａＳはどの地域のユーザにも最大限のパフォーマンスでサービスを提供するため、ＧｅｏＤＮＳ技術を採用している。ＧｅｏＤＮＳの利用により、ＤＮＳサーバに問い合わせたクライアントの物理的な位置に応じて、最寄りのＳａａＳのサーバのＩＰアドレスを応答することができる。なお、ＤＮＳはＤｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍの略である。

ただし、企業ユーザがデータセンタなどの主要拠点に内部ＤＮＳサーバを設置し、外部ＤＮＳサーバへの問い合わせを当該主要拠点からブレークアウトさせている設計が多い。そのため、ＳａａＳアクセスに関するＤＮＳトラフィックは、データセンタなどの主要拠点からインターネットに出るの対し、データフローはブランチ拠点（例：データセンタと異なる国に設置された拠点）からインターネットに出ることになり、両者の出口が合致していない。その結果、せっかくＳａａＳに関する特定のデータフローをブランチ拠点にてブレークアウトしているのに、主要拠点からＤＮＳ問い合わせをした結果、主要拠点の最寄りのＳａａＳサーバにアクセスしてしまい、期待されている遅延の改善効果が見られない場合がある。

（２）プロキシについての課題
ユーザ端末とＳａａＳサーバとの間にプロキシ（プロキシ装置、プロキシサーバなどと称してもよい）を設置して、プロキシを経由して通信を行うことが多い。しかし、ＳａａＳの種類によって、利用時にＴＣＰセッションを大量に消費する場合もあるため、セッション増によるプロキシの処理限界により、ＳａａＳが快適に利用できないことがある。

そこで、既存のプロキシをバイパスし、処理負荷を軽減することが求められている。従来方式では、ＳａａＳトラフィックに対して、プロキシをバイパスさせるために、ＳＤ−ＷＡＮ装置とは別に、既存のプロキシにおいて、ＳａａＳ向けの通信の宛先を定期的にチェックしなければならず、その結果をプロキシ自動設定（ＰＡＣ）ファイルに反映し、当該ＰＡＣファイルをまたすべてのエンドユーザに配布しなければならない。従って、運用負荷が増加する場合がある。

（３）パケット識別遅延の課題
また、従来のＳＤ−ＷＡＮ装置のＤＰＩエンジンにおいて、ＨＴＴＰ／ＨＴＴＰｓのハンドシェイクのやり取りを解析し、その中で抽出したＳａａＳのドメインネームを用いてアクセス先のＳａａＳを判別する方法が採用されている。しかし、この方法では最初に到着したパケット（Ｆｉｒｓｔ Ｐａｃｋｅｔ）にてＳａａＳを識別することが困難であるため、該当ＳａａＳの最初のフローが主要拠点から出てしまう場合がある。

以下、本発明の実施の形態として、上記課題を解決する技術について詳細に説明する。なお、本実施の形態では、アクセス装置１００が閉域網２０、及びインターネット３０に接続されるが、この形態は一例に過ぎない。閉域網２０及びインターネット３０以外の２網間で同様の制御がされてもよい。また、アクセス装置１００は３つ以上の複数の網に接続されて、パケットを当該複数の網のうちのいずれかの網に振り分けることとしてもよい。

（システム構成）
図１に本発明の実施の形態におけるシステムの全体構成を示す。図１に示すとおり、ユーザ端末１０、閉域網２０、及びインターネット３０と接続されるアクセス装置１００が備えられる。アクセス装置１００は、ユーザ端末１０からのアクセスを受けて、ユーザ端末１０を、閉域網２０上の装置、あるいは、インターネット３０上の装置に接続させ、通信を行う装置である。なお、アクセス装置１００を、ＳａａＳアクセス高速化装置と称してもよい。また、アクセス装置１００は、データフローに対する種々の制御を実施する装置なので、これを制御装置と称してもよい。

閉域網２０は、例えば企業の複数拠点を接続する企業内の網である。アクセス装置１００は、例えば、グローバル企業の企業ネットワークにおけるブランチ拠点毎に設置される装置である。

以下、アクセス装置１００の構成と動作を詳細に説明する。以下では、アクセス装置１００の基本的な構成を第１の実施の形態として説明し、第１の実施の形態のアクセス装置１００にプロキシ制御部が追加された構成を第２の実施の形態として説明する。

（第１の実施の形態）
＜装置構成＞
図２に、第１の実施の形態におけるアクセス装置１００の機能構成図を示す。図２に示すように、アクセス装置１００は、指令受信部１１０、ＤＮＳ制御部１２０、共通アプリケーション管理部１３０、ＳＤ−ＷＡＮルーティング部１４０、複数のＩＦ（インタフェース）を有する。

複数のＩＦの例として、図２には、閉域網に接続するための閉域網接続ＩＦ１５０、インターネットに接続するためのＩｎｔｅｒｎｅｔ接続ＩＦ１６０、ＬＡＮに接続するためのＬＡＮ−ＩＦ１７０が示されている。閉域網接続ＩＦ１５０及びＩｎｔｅｒｎｅｔ接続ＩＦ１６０には図示のとおりにＩＰアドレスが割り当てられている。

図示のとおり、閉域網接続ＩＦ１５０には内部ＤＮＳサーバ２１０が接続され、Ｉｎｔｅｒｎｅｔ接続ＩＦ１６０には、外部ＤＮＳサーバ３１０及びＳａａＳサーバ３２０が接続され、ＬＡＮ−ＩＦ１７０にはユーザ端末１０が接続されている。また、各サーバには図示のとおりのＩＰアドレスが割り当てられている。本実施の形態におけるＳａａＳサーバ３２０に関して、ＩＰアドレスは固定ではなく、随時ＩＰアドレスが変わる。

なお、ＩＦは、物理ポートに限らず、ＩＰｓｅｃなどのトンネルを終端する論理ポートであってもよい。また、本実施の形態では、例として、共通アプリケーション管理部１３０を各アクセス装置に備えることとしているが、これに代えて、共通アプリケーション管理部１３０を、アクセス装置１００の外部に備え、複数のアクセス装置が共通に利用可能なものとして設置してもよい。アクセス装置１００の各部の詳細については後述する。

アクセス装置１００は、複数のコンピュータ（通信装置なども含む）により構成されるシステムであってもよいし、１つのコンピュータで実現される装置であってもよい。また、当該コンピュータは物理マシンであってもよいし仮想マシンであってもよい。また、アクセス装置１００が、本実施の形態で説明する処理を実行する専用ハードウェア回路で実現されてもよい。

アクセス装置１００がコンピュータで実現される場合において、アクセス装置１００は、コンピュータに内蔵されるＣＰＵやメモリ等のハードウェア資源を用いて、アクセス装置１００で実施される処理に対応するプログラムを実行することによって実現することが可能である。上記プログラムは、コンピュータが読み取り可能な記録媒体（可搬メモリ等）に記録して、保存したり、配布したりすることが可能である。また、上記プログラムをインターネットや電子メール等、ネットワークを通して提供することも可能である。

図３は、上記コンピュータのハードウェア構成例を示す図である。図３のコンピュータは、それぞれバスＢで相互に接続されているドライブ装置１０００、補助記憶装置１００２、メモリ装置１００３、ＣＰＵ１００４、インタフェース装置１００５、表示装置１００６、及び入力装置１００７等を有する。

当該コンピュータでの処理を実現するプログラムは、例えば、ＣＤ−ＲＯＭ又はメモリカード等の記録媒体１００１によって提供される。プログラムを記憶した記録媒体１００１がドライブ装置１０００にセットされると、プログラムが記録媒体１００１からドライブ装置１０００を介して補助記憶装置１００２にインストールされる。但し、プログラムのインストールは必ずしも記録媒体１００１より行う必要はなく、ネットワークを介して他のコンピュータよりダウンロードするようにしてもよい。補助記憶装置１００２は、インストールされたプログラムを格納すると共に、必要なファイルやデータ等を格納する。

メモリ装置１００３は、プログラムの起動指示があった場合に、補助記憶装置１００２からプログラムを読み出して格納する。ＣＰＵ１００４は、メモリ装置１００３に格納されたプログラムに従って、アクセス装置１００に係る機能を実現する。インタフェース装置１００５は、ネットワークに接続するためのインタフェースとして用いられ、ネットワークを介した入力手段及び出力手段として機能する。表示装置１００６はプログラムによるＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を表示する。入力装置１５７はキーボード及びマウス、ボタン、又はタッチパネル等で構成され、様々な操作指示を入力させるために用いられる。

以下、アクセス装置１００の各部の構成、動作を詳細に説明する。

＜共通アプリケーション管理部１３０＞
共通アプリケーション管理部１３０は、アプリケーション管理ＤＢとアプリケーションキャッシュ（アプリケーションテーブルと称してもよい）を有する。図４に、アプリケーション管理ＤＢに格納される情報の例を示し、図５に、アプリケーションキャッシュに格納される情報の例を示す。

アプリケーション管理ＤＢは様々なＳａａＳの通信パターンを管理するＤＢであり、図４に示す例では、アプリケーション管理ＤＢのカラムとして、アプリケーション名、ＦＱＤＮ、宛先ＩＰアドレスなどを有する。図４は例であり、アプリケーション管理ＤＢの構成は図４に示すものに限られない。例えば、図４のアプリケーション名、ＦＱＤＮ、宛先ＩＰアドレスに加えて、宛先ポート番号を含めてもよい。また、ＳａａＳアプリを特定するその他のパラメータを含めてもよい。

図４に示す情報は、アプリケーション名が「Ｅｘａｍｐｌｅ」のＳａａＳに関しては、宛先のＦＱＤＮがＥｘａｍｐｌｅ．ｃｏｍもしくは、Ｅｘａｍｐｌｅ３６５．ｃｏｍもしくは、宛先ＩＰアドレスがＢ．Ｂ．Ｂ．Ｂ／Ｂの３種類の通信パターンがあることを示す。

アプリケーションキャッシュは、現時点においてアクセス装置１００が把握しているＳａａＳの宛先サーバのＩＰアドレスを記録する。図５に示すように、アプリケーションキャッシュのカラムとしては、例えば、アプリケーション名と宛先ＩＰアドレスを有するが、これに限られるわけではない。また、図５（ａ）は、アプリケーション名が「Ｅｘａｍｐｌｅ」の宛先ＩＰアドレスがＢ．Ｂ．Ｂ．Ｂとして把握された場合を示している。図５（ｂ）は、例えば、アプリケーション名が「Ｅｘａｍｐｌｅ」の宛先ＩＰアドレスがＢ．Ｂ．Ｂ．Ｂとして把握された後、「Ｅｘａｍｐｌｅ」の宛先ＩＰアドレスとしてＡ．Ａ．Ａ．Ａが検知された場合を示している。

＜ＤＮＳ制御部１２０＞
図２に示したように、ＤＮＳ制御部１２０は、ＤＮＳ振り分け部１２１とＤＮＳ振り分けポリシー管理部１２２を有する。

ＤＮＳ振り分け部１２１は、ＤＮＳ振り分けポリシー管理部１２２が管理するＤＮＳ振り分けポリシーに従って、ＤＮＳ問い合わせ（ＤＮＳ問い合わせパケットと称してもよい）を振り分ける。つまり、当該ＤＮＳ振り分けポリシーに従って、ＤＮＳ問い合わせの送信先を決定し、その送信先に向けてＤＮＳ問い合わせを送信する。

ＤＮＳ振り分けポリシー管理部１２２は、図６に示すＤＮＳ振り分けポリシー管理ＤＢを有する。ＤＮＳ振り分けポリシー管理ＤＢは、ＤＮＳ問い合わせに対して、実行する動作を定義する情報を格納するＤＢである。図６に示す例では、Ｅｘａｍｐｌｅ．ｃｏｍあるいはＥｘａｍｐｌｅ３６５．ｃｏｍのＦＱＤＮが含まれるＤＮＳ問い合わせに対して、ＩＰアドレスがＹ．Ｙ．Ｙ．Ｙの外部ＤＮＳサーバ３１０にＦｏｒｗａｒｄし、その他の問い合わせは、Ｄｅｆａｕｌｔとして内部ＤＮＳサーバ２１０にＦｏｒｗａｒｄする動作を定義している。

＜ＳＤ−ＷＡＮルーティング部１４０＞
図２に示したように、ＳＤ−ＷＡＮルーティング部１４０は、アプリ検知部１４１、ルーティング制御部１４２、ルーティングポリシー管理部１４３を有する。

アプリ検知１４１は、ＳＤ−ＷＡＮルーティング部１４０によりルーティングされるデータフロー（より詳細にはデータフローを構成するパケット）を調べることにより、そのデータフローの宛先あるいは送信元のアプリケーションを検知する。ルーティング制御部１４２は、ルーティングポリシー管理部１４３に管理されているルーティングポリシーに従ってパケットのルーティングを実行する。

ルーティングポリシー管理部１４３は、ＩＰルーティングポリシー管理ＤＢとアプリルーティングポリシー管理ＤＢとを有する。図７（ａ）に、ＩＰルーティングポリシー管理ＤＢに格納される情報の例を示し、図７（ｂ）に、アプリルーティングポリシー管理ＤＢに格納される情報の例を示す。

ＩＰルーティングポリシー管理ＤＢは、通常のルータのルーティングテーブルに相当し、図７（ａ）に示すとおり、宛先ＩＰアドレスとＮｅｘｔ Ｈｏｐを格納している。

アプリルーティングポリシー管理ＤＢは対象アプリに対するルーティング制御方法を定義する情報を格納するＤＢである。図７（ｂ）には、一例として対象アプリ「Ｅｘａｍｐｌｅ」のＳａａＳフローをローカルにあるＮｅｘｔ ｈｏｐ（Ｉｎｔｅｒｎｅｔ接続ＩＦ（Ｊ．Ｊ．Ｊ．Ｊ））に転送するルーティング動作を定義する情報が示されている。

図７（ａ）はＩＰルーティングポリシー管理ＤＢが宛先ＩＰアドレスとＮｅｘｔ ｈｏｐのカラムを有することを示し、図７（ｂ）はアプリルーティングポリシー管理ＤＢが対象アプリと、Ｎｅｘｔ ｈｏｐのカラムを有することを示しているが、これらは一例である。ＩＰルーティングポリシー管理ＤＢとアプリルーティングポリシー管理ＤＢのそれぞれにおいて、通信元のＩＰアドレスや、ポート番号などを含めてもよい。

以下、アクセス装置１００の基本的な動作として、ＤＢの設定／更新などのための動作（マネジメントフローの制御と呼ぶ）と、ユーザ端末１０が通信を行う際の動作（データフローの制御と呼ぶ）について説明する。

＜マネジメントフローの制御＞
図８に示すフローチャートの手順に沿ってマネジメントフローの制御におけるアクセス装置１００の動作について説明する。

Ｓ１０１）対象指定
指示受信部１１０は、ユーザからＬｏｃａｌ ｂｒｅａｋｏｕｔさせる対象ＳａａＳの指定を受信し、受信内容に基づいてＤＮＳ制御部１２０と、ＳＤ−ＷＡＮルーティング部１４０にそれぞれ指示をする。

Ｓ１０２）ＤＮＳ振り分けポリシー管理ＤＢ更新
ＤＮＳ制御部１２０は、共通アプリケーション管理部１３０から、対象ＳａａＳに対するＬｏｃａｌ ｂｒｅａｋｏｕｔのために必要な情報を収集し、ＤＮＳ振り分けポリシー管理ＤＢ（例：図６）を更新する。

対象ＳａａＳに対するＬｏｃａｌ ｂｒｅａｋｏｕｔのために必要な情報は、例えば、対象ＳａａＳに対応する１つ又は複数のＦＱＤＮ（ＦＱＤＮ一覧）である。ＤＮＳ制御部１２０は、取得したＦＱＤＮ一覧におけるＦＱＤＮを想定される動作と紐付け、ＤＮＳ振り分けポリシー管理ＤＢに格納する。

本実施の形態では、Ｌｏｃａｌ ｂｒｅａｋｏｕｔの際のＮｅｘｔ−ｈｏｐは事前に設定された外部ＤＮＳサーバ３１０のＩＰアドレス（Ｙ．Ｙ．Ｙ．Ｙ）を想定する。それ以外のＦＱＤＮに関する問い合わせは内部ＤＮＳサーバ２１０のＩＰアドレス（Ｘ．Ｘ．Ｘ．Ｘ）を想定する。

例えば、図６の最初のレコードには、ＤＮＳ問い合わせにおける対象ＳａａＳのＦＱＤＮがＥｘａｍｐｌｅ．ｃｏｍである場合において、当該ＤＮＳ問い合わせをＩＰアドレス（Ｙ．Ｙ．Ｙ．Ｙ）にＦｏｗａｒｄする動作に対応する情報が記録される。

Ｓ１０３）アプリルーティングポリシー管理ＤＢ更新
ＳＤ−ＷＡＮルーティング部１４０は、アプリルーティングポリシー管理ＤＢ（例：図７（ｂ））を更新する。具体的には、図７（ｂ）に示すように、対象ＳａａＳと事前に定義されているＮｅｘｔ ｈｏｐアドレスとを紐付けた情報を記録する。

＜データフローの制御例１＞
次に、データフローの制御例１におけるアクセス装置１００の動作について、図９のフローチャートの手順に沿って説明する。データフローの制御例１では、ユーザ端末１０でのＤＮＳサーバのアドレスがアクセス装置１００のＤＮＳ制御部１２０（Ｚ．Ｚ．Ｚ．Ｚ）に設定されている。

Ｓ２０１）ＤＮＳ問い合わせ受信／転送
ルーティング制御部１４２は、ユーザ端末１０から送信されたＤＮＳ問い合わせを受信し、ＩＰルーティングポリシー管理ＤＢ（例：図７（ａ））に従って、通常のルータと同様にして、該当問い合わせをＤＮＳ制御部１２０に転送する。ＤＮＳ制御部１２０のＤＮＳ振り分け部１２１がＤＮＳ問い合わせを受信する。

Ｓ２０２）ＤＮＳ問い合わせ再転送
ＤＮＳ制御部１２０におけるＤＮＳ振り分け部１２１は、受信したＤＮＳ問い合わせをＤＮＳ振り分けポリシー管理ＤＢ（例：図６）に従って再転送する。

例えば、該当ＤＮＳ問い合わせに含まれるＦＱＤＮが、対象ＳａａＳのＥｘａｍｐｌｅ．ｃｏｍである場合において、ＤＮＳ振り分け部１２１は、ＤＮＳ振り分けポリシー管理ＤＢ（図６）に従って、当該ＤＮＳ問い合わせを外部ＤＮＳサーバ３１０（Ｙ．Ｙ．Ｙ．Ｙ）に転送される。その他のＤＮＳ問い合わせはＤｅｆａｕｌｔに従って、内部ＤＮＳサーバ２１０に転送される。なお、データフローの制御例１においても、後述する問い合わせ先変更部１２３を備えることで、ＤＮＳ問い合わせの宛先を転送先のＩＰアドレスに変更してもよい。

その後、ユーザ端末１０は、該当ＤＮＳサーバから送出されたＩＰアドレスを受信し、当該ＩＰアドレスを宛先とするデータ通信を開始する。

Ｓ２０３）データフロー検知
ＤＮＳの問い合わせ実施後、ユーザ端末１０によるデータ通信が開始されると、対象ＳａａＳのデータフローがＬＡＮ−ＩＦ１７０により受信され、ＳＤ−ＷＡＮルーティング部１４０に送信される。

ＳＤ−ＷＡＮルーティング部１４０のアプリ検知部１４１は特定のＳａａＳのデータフローを検知し、該当フローの宛先ＩＰアドレスを用いて、アプリケーションキャッシュ（例：図５）を更新する。アプリ検知部１４１によるＳａａＳデータフローの検知方法として、例えばＨＴＴＰ／ＨＴＴＰｓのＨｅａｄｅｒから抽出する方法があるが、それに限らない。

Ｓ２０４）ルーティング制御
ルーティング制御部１４２は、アプリルーティングポリシー管理ＤＢ（例：図７（ｂ））と、アプリケーションキャッシュ（例：図５）を用いて、ＳａａＳデータフローのルーティングを制御する。例えば、対象ＳａａＳがＥｘａｍｐｌｅ．ｃｏｍの場合、アプリケーションキャッシュにＥｘａｍｐｌｅ．ｃｏｍに対する宛先アドレスとしてＡ．Ａ．Ａ．Ａが記録された後、ルーティング制御部１４２は、宛先がＡ．Ａ．Ａ．Ａであるパケットを受信すると、アプリケーションキャッシュを参照することで、対象ＳａａＳがＥｘａｍｐｌｅであることを把握し、アプリルーティングポリシー管理ＤＢを参照することで、当該パケットをＩｎｔｅｒｎｅｔ接続ＩＦ１６０（Ｊ．Ｊ．Ｊ．Ｊ）に転送する。

Ｓ２０５）ルーティング制御
その後、同じデータフローが発生した場合、アプリ検知部１４１を経由することなく、アプリケーションキャッシュを用いることでルーティングの制御を実行することが可能となる。

＜データフローの制御例２＞
次に、データフローの制御例２として、ユーザ端末１０でのＤＮＳサーバのアドレスが内部ＤＮＳサーバ２１０（Ｘ．Ｘ．Ｘ．Ｘ）と設定されるケースについて、データフローの制御例１と異なる点を説明する。

データフローの制御例２では、図１０に示すように、ＤＮＳ制御部１２０は、ＤＮＳ振り分け部１２１とＤＮＳ振り分けポリシー管理部１２２に加えて、問い合わせ先変更部１２３を有する。

また、図１１に示すように、アプリルーティングポリシー管理ＤＢにＤＮＳ問い合わせに対するルーティングポリシーを新たに追加する。このルーティングポリシーは、ポート番号（例：５３）でＤＮＳ問い合わせトラフィックを特定し、Ｎｅｘｔ ｈｏｐをＤＮＳ制御部１２０（Ｚ．Ｚ．Ｚ．Ｚ）とするポリシーである。

この場合のデータフローの制御を図１２のフローチャートの手順に沿って説明する。

Ｓ３０１）ＤＮＳ問い合わせ受信／転送
ルーティング制御部１４２は、ＤＮＳ問い合わせを受信すると、アプリルーティングポリシー管理ＤＢ（図１１）におけるＤＮＳに関するポリシーに従って、当該ＤＮＳ問い合わせをＤＮＳ制御部１２０（Ｚ．Ｚ．Ｚ．Ｚ）に転送する。

Ｓ３０２）ＤＮＳ問い合わせ再転送
ＤＮＳ制御部１２０におけるＤＮＳ振り分け部１２１は、受信したＤＮＳ問い合わせをＤＮＳ振り分けポリシー管理部１２２に従って再転送する。対象ＳａａＳ以外の問い合わせはＤｅｆａｕｌｔに従って、内部ＤＮＳサーバ２１０（Ｘ．Ｘ．Ｘ．Ｘ）に再転送される。

Ｓ３０３）宛先アドレス変更
一方、対象ＳａａＳのＤＮＳ問い合わせは、宛先を問い合わせ先変更部１２３によって変更した上で再転送する。変更先となるＤＮＳ問い合わせの宛先アドレスは事前に設定されるものとし、例として外部ＤＮＳサーバ３１０のＩＰアドレス（Ｙ．Ｙ．Ｙ．Ｙ）が変更先として設定される。以降の処理はデータフローの制御例１と同様である。

＜ＤＮＳの問い合わせの結果を用いたアプリケーションキャッシュの更新＞
上述した例では、アプリ検知部１４１がパケットを解析することにより当該パケットに係るデータフローに対応するＳａａＳアプリケーションを識別し、アプリケーションキャッシュ（例：図５）を更新していた。この方法に代えて（あるいはこの方法に加えて）、ＤＮＳの問い合わせ結果を用いてアプリケーションキャッシュを更新してもよい。

ＤＮＳの問い合わせの結果を用いて、アプリケーションキャッシュを随時更新する機能を持たせることで、Ｆｉｒｓｔ ｐａｃｋｅｔでＳａａＳアプリケーションの識別が可能となる。

この場合のアクセス装置１００の動作を図１３のフローチャートの手順に沿って説明する。

Ｓ４０１）アプリケーションキャッシュ更新
例えば、ＤＮＳ問い合わせが外部ＤＮＳサーバ３１０に転送され、外部ＤＮＳサーバ３１０から送出される問い合わせ結果（ＦＱＤＮに対応するＩＰアドレス）をルーティング制御部１４２が受信する。ルーティング制御部１４２は、当該問い合わせ結果を用いてアプリケーションキャッシュを更新する。

例えば、Ｅｘａｍｐｌｅ．ｃｏｍの問い合わせ結果がＡ．Ａ．Ａ．Ａであり、Ｅｘａｍｐｌｅ３６５．ｃｏｍの問い合わせ結果がＣ．Ｃ．Ｃ．Ｃであるとし、ルーティング制御部１４２がそれぞれの問い合わせ結果を受信した場合、図１４に示すように、アプリケーションキャッシュが更新される。つまり、Ａ．Ａ．Ａ．Ａのレコードと、Ｃ．Ｃ．Ｃ．Ｃのレコードが追加される。なお、本実施の形態におけるＥｘａｍｐｌｅ．ｃｏｍとＥｘａｍｐｌｅ３６５．ｃｏｍのアプリケーション名はいずれも「Ｅｘａｍｐｌｅ」として識別される。

Ｓ４０２）ルーティング制御
その後、ルーティング制御部１４２が、該当ＳａａＳのデータフローを受信した場合、アプリルーティングポリシー管理ＤＢ（例：図７（ｂ））と、アプリケーションキャッシュ（例：図１４）を用いて、該当フローのルーティングを制御する。

具体的には、ルーティング制御部１４２は、データフローの宛先ＩＰアドレスでアプリケーションキャッシュを検索し、ヒットするレコードがある場合、当該レコードのアプリケーション名（対象ＳａａＳ名）を用いてアプリルーティングポリシー管理ＤＢで当該対象ＳａａＳのＮｅｘｔ ｈｏｐを検索する。その結果、ルーティング制御部１４２はＮｅｘｔ ｈｏｐに記載されているＩＰアドレスに該当フローを転送する。

（第２の実施の形態）
次に、第２の実施の形態を説明する。ここでは、第１の実施の形態と異なる点を主に説明する。

＜装置構成＞
図１５に、第２の実施の形態におけるアクセス装置１００の機能構成図を示す。図１５に示すように、第２の実施の形態におけるアクセス装置１００は、第１の実施の形態におけるアクセス装置１００に対してプロキシ制御部１８０が追加された構成である。また、図１５には、内部プロキシサーバ２２０が示されている。図示するように、ここではプロキシ制御部１８０のＩＰアドレスはＺ'．Ｚ'．Ｚ'．Ｚ'であり、内部プロキシサーバ２２０のＩＰアドレスはＺ１．Ｚ１．Ｚ１．Ｚ１である。

図１５に示すとおり、プロキシ制御部１８０は、プロキシ振り分け部１８１とプロキシ振り分けポリシー管理部１８２を有する。

第２の実施の形態では、プロキシ制御部１８０までトラフィックをルーティングさせるため、図１６（ａ）に示すように、ルーティングポリシー管理部１４３におけるＩＰルーティングポリシー管理ＤＢに新たにＺ'．Ｚ'．Ｚ'．Ｚ'に関するポリシーを追加する。

また、プロキシ振り分けポリシー管理部１８２はプロキシ振り分けポリシー管理ＤＢを有する。図１７に、プロキシ振り分けポリシー管理ＤＢに格納される情報の例を示す。図１７に示すように、プロキシ振り分けポリシー管理ＤＢは、各ＦＱＤＮと、ＩＰアドレスに対するプロキシの制御動作を定義する情報を格納したＤＢである。

プロキシ振り分け部１８１は、プロキシ振り分けポリシー管理ＤＢの情報に従って、トラフィックの振り分け制御を実行する。例えば、プロキシ振り分け部１８１は、宛先のＦＱＤＮがＥｘａｍｐｌｅ．ｃｏｍであるパケットを受信した場合、当該パケットをプロキシパススルーとさせる。Ｄｅｆａｕｌｔの場合、内部プロキシ（Ｚ１．Ｚ１．Ｚ１．Ｚ１）とプロキシチェーニングを実施する。

＜マネジメントフローの制御＞
図１８に示すフローチャートの手順に沿って、プロキシ制御部１８０の追加に伴って追加される制御フローについて説明する。

Ｓ５０１）対象指定
まず、指示受信部１１０は、ユーザからＬｏｃａｌ ｂｒｅａｋｏｕｔさせる対象ＳａａＳの指定を受信し、受信内容に基づいてプロキシ制御部１８０に指示をする。

Ｓ５０２）プロキシ振り分けポリシー管理ＤＢ更新
プロキシ制御部１８０は、共通アプリケーション管理部１３０のアプリケーション管理ＤＢから、対象ＳａａＳに対するＬｏｃａｌ ｂｒｅａｋｏｕｔのために必要な情報を収集し、プロキシ振り分けポリシー管理ＤＢを更新する。

対象ＳａａＳに対するＬｏｃａｌ ｂｒｅａｋｏｕｔのために必要な情報は、例えば、対象ＳａａＳに対応する１つ又は複数のＦＱＤＮ（ＦＱＤＮ一覧）と１つ又は複数のＩＰアドレス（ＩＰアドレス一覧）である。プロキシ制御部１８０は、取得したＦＱＤＮ一覧とＩＰアドレス一覧を、想定される動作と紐付け、プロキシ振り分けポリシー管理ＤＢに格納する。

図１７に示すように、パススルーしない場合（Ｄｅｆａｕｌｔの場合）におけるＮｅｘｔ−ｈｏｐは、事前に設定されたプロキシチェーニングの先となる内部ＤＮＳサーバ２２０のＩＰアドレス（Ｚ１．Ｚ１．Ｚ１．Ｚ１）としている。

＜データフローの制御＞
次に、データフローの制御におけるアクセス装置１００の動作について、図１９のフローチャートの手順に沿って説明する。

Ｓ６０１）トラフィック受信／転送
ルーティング制御部１４２は、プロキシ制御部１８０向けのトラフィック（ここでは、ＳａａＳアクセス要求とする）を受信し、ルーティングポリシー管理部１４３のＩＰルーティングポリシー管理ＤＢ（例：図１６（ａ））に従って、トラフィックをプロキシ制御部１８０（Ｚ'．Ｚ'．Ｚ'．Ｚ'）に転送する。プロキシ制御部１８０におけるプロキシ振り分け部１８１がトラフィック（ＳａａＳアクセス要求）を受信する。

Ｓ６０２）トラフィック受信／転送
プロキシ振り分け部１８１は、受信したＳａａＳアクセス要求を一旦終端し、プロキシ振り分けポリシー管理ＤＢ（図１７）に従って、該当ＳａａＳにアクセスするためのプロキシ制御を行う。

一例として、Ｅｘａｍｐｌｅ．ｃｏｍにアクセスする要求に関して、図１７の動作定義に従って、パススルーとさせる。パススルーの場合、プロキシ制御部１８０が起点となって、ＤＮＳの問い合わせを実施する。ＤＮＳの問い合わせ動作や、その後の一連の動作はこれまでの説明と同様である。なお、この場合のＤＮＳ問い合わせは、プロキシ制御部１８０からルーティング制御部１４２に送られ、ルーティング制御部１４０からＤＮＳ制御部１２０に送られる。

一方、対象ＳａａＳアクセス以外のデータフローに関しては、Ｄｅｆａｕｌｔに該当し、内部プロキシサーバ２２０とチェーニングさせるために、プロキシ制御部１８０は、内部プロキシサーバ２２０に該当データフローのアクセスを要求する。要求の中身の一例として以下の様式が考えられる。

［ＩＰ ｈｅａｄｅｒ（抜粋）］
Ｓｒｃ ＩＰ：Ｚ'．Ｚ'．Ｚ'．Ｚ'
Ｄｓｔ ＩＰ：Ｚ１．Ｚ１．Ｚ１．Ｚ１
［ＴＣＰ ｈｅａｄｅｒ（抜粋）］
Ｓｒｃ ｐｏｒｔ：２６００１
Ｄｓｔ ｐｏｒｔ：４４３
［Ｈｔｔｐ ｒｅｑｕｅｓｔ（抜粋）］
ＧＥＴ ｈｔｔｐｓ：／／ｗｗｗ．ｅｘａｍｐｌｅ．ｃｏｍ
上記の要求によって、該当のデータフローについては、内部プロキシサーバ２２０がユーザ端末１０に対するプロキシとなって動作を行う。

＜情報収集方法の他の例＞
上記のマネジメントフローの例では、プロキシ制御部１８０が共通アプリケーション管理部１３０のアプリケーション管理ＤＢから必要な情報を収集するとしたが、それに加えて（又はそれに代えて）、アプリケーションキャッシュから情報を収集することとしてもよい。図２０に、アプリケーションキャッシュから収集した情報も利用して更新したプロキシ振り分けポリシー管理ＤＢ１８２の例を示す。

この場合、プロキシ制御部１８０は、アプリケーション管理ＤＢから対象ＳａａＳに対応するＦＱＤＮ一覧とＩＰアドレスに加えて、アプリケーションキャッシュから既にキャッシングされているＩＰアドレスも収集し、それらのＩＰアドレスをプロキシ振り分けポリシー管理ＤＢにおいて想定される動作と紐付ける。また、プロキシ振り分けポリシー管理部１８２は定期的に共通アプリケーション管理部１３０と同期し、常にアプリケーション管理ＤＢと、アプリケーションキャッシュの最新情報を保持する。

ＳａａＳサーバのＩＰアドレスが随時変更されることから、上記のようにアプリケーションキャッシュの最新情報を保持することで、正確なＩＰアドレスに基づいた動作を実行できる。

＜アプリケーション管理ＤＢ、アプリケーションキャッシュの定期更新について＞
第１の実施の形態と第２の実施の形態に共通の動作として、図２１に示すように、外部アプリケーション管理サーバ４００から情報を取得することにより、共通アプリケーション管理部１３０が、アプリケーション管理ＤＢを定期的に更新することとしてもよい。この場合の動作を図２２のフローチャートを参照して説明する。なお、外部アプリケーション管理サーバ４００には最新の情報が格納されているものとする。

Ｓ７０１）ポーリング
共通アプリケーション管理部１３０は、定期的に外部アプリケーション管理サーバ４００にＤＢのアップデートがあるかどうかの問い合わせ（ポーリング）を行う。

Ｓ７０２）更新
共通アプリケーション管理部１３０は、アップデートがあったことを検知すると、最新のデータを受信し、アプリケーション管理ＤＢを更新する。

また、共通アプリケーション管理部１３０は、アプリケーションキャッシュを定期的に更新してもよい。この場合、図２３に示すように、アプリケーションキャッシュはレコード毎にタイマー値を保持する。共通アプリケーション管理部１３０は、アプリケーションキャッシュを監視し、レコードのデータが設定された時点から更新されずにタイマー値の期間が経過した時点で当該レコードを自動的に削除する。

ＳａａＳサーバのＩＰアドレスは固定されておらず、随時変更されることから、上記のように更新機構を設けることで、正確なＩＰアドレスに基づいた動作を実行できる。

（実施の形態の効果等）
以上説明したように、本発明の実施の形態に係るアクセス装置１００においては、ＳＤ−ＷＡＮルーティング部１４０に加えて、共通アプリケーション管理部１３０と、ＤＮＳ制御部１２０と、プロキシ制御部１８０を設けることとした。

ＤＮＳ制御部１２０は共通アプリケーション管理部１３０を参照しながら、特定ＳａａＳのデータフローの制御に追随し、それに関するＤＮＳトラフィックの最適出口を判断・制御する。同様に、プロキシ制御部１８０は、共通アプリケーション管理部１３０を参照しながら、特定ＳａａＳのデータフロー対し、既存プロキシを迂回させるようにルーティング制御を行う。さらに、ＤＮＳ制御部１２０を経由して行われたＤＮＳの問い合わせ結果であるＳａａＳサーバのＩＰアドレスをアプリケーションキャッシュに随時反映し、アクセス先のＳａａＳサーバＩＰを用いて、特定ＳａａＳを識別することができる。

上記のような構成を備えるアクセス装置１００により、特定ＳａａＳのデータフローをブランチ拠点から直接にブレークアウトさせる際に、該当ＳａａＳアクセスに関するＤＮＳトラフィックや、プロキシへのルーティングをそれに合わせて連動的に制御することが可能となり、該当ＳａａＳへの最適アクセスが実現される。

すなわち、ＤＮＳフローとデータフローの出口を一致させることによって、ブランチ拠点の最寄りのＳａａＳサーバへアクセスすることが可能となる。また、既存プロキシをバイパスすることによって、該当ＳａａＳアクセスに起因するプロキシ処理負荷を軽減することが期待できる。さらに、最新のＤＮＳの問い合わせ結果を用いて、Ｆｉｒｓｔ Ｐａｃｋｅｔで特定ＳａａＳを識別できる。

（実施の形態のまとめ）
以上、説明したとおり、本実施の形態により、少なくとも下記の制御装置、制御方法、及びプログラムが提供される。
（第１項）
複数の網に接続され、ユーザ端末から受信したパケットを当該複数の網のうちのいずれかの網に振り分ける制御装置であって、
前記ユーザ端末から送信されたＤＮＳ問い合わせパケットを受信し、当該ＤＮＳ問い合わせパケットの問い合わせ対象に基づいて、当該ＤＮＳ問い合わせパケットを前記複数の網のうちのいずれかの網に振り分けるＤＮＳ制御部と、
パケットを受信し、当該パケットの宛先アドレスに基づいて当該パケットの送信先を決定し、決定された送信先に当該パケットを送信するルーティング部と
を備える制御装置。
（第２項）
前記制御装置は、パケットの宛先アドレスと当該パケットの宛先のアプリケーションとを対応付けた情報を格納するアプリケーションテーブルを備え、
前記ルーティング部は、前記アプリケーションテーブルを参照することにより、受信したパケットの宛先アドレスに対応するアプリケーションを把握し、当該アプリケーションに対して予め定められたポリシーに従って当該パケットを前記複数の網のうちのいずれかの網に振り分ける
第１項に記載の制御装置。
（第３項）
前記ルーティング部は、前記ＤＮＳ問い合わせパケットの問い合わせ対象と、問い合わせの応答として受信したアドレスとを用いて前記アプリケーションテーブルを更新する
第２項に記載の制御装置。
（第４項）
前記アプリケーションテーブルは、レコード毎にタイマー値を有し、当該タイマー値の期間が経過したレコードを削除する
第２項又は第３項の制御装置。
（第５項）
前記ＤＮＳ制御部は、前記ＤＮＳ問い合わせパケットの宛先アドレスを、当該ＤＮＳ問い合わせパケットの振り分け先に応じて書き換える
第１項ないし第４項のうちいずれか１項に記載の制御装置。
（第６項）
前記制御装置は所定のプロキシ装置に接続されており、前記制御装置は、
受信したパケットのアクセス先のアプリケーションに基づいて、当該パケットを前記プロキシ装置に送信するか否かを決定するプロキシ制御部
を更に備える請求項１ないし５のうちいずれか１項に記載の制御装置。
（第７項）
前記プロキシ制御部は、
アプリケーション毎の宛先アドレスと動作とを記録したプロキシ振り分けテーブルを備え、当該プロキシ振り分けテーブルを参照することにより、パケットを前記プロキシ装置に送信するか否かの決定を行い、
前記アプリケーションテーブルを利用して前記プロキシ振り分けテーブルを更新する
第２項ないし第４項のうちいずれか１項に従属する第６項に記載の制御装置。
（第８項）
前記制御装置は、
アプリケーションの情報を管理するアプリケーション管理データベースと、
外部のアプリケーション管理サーバに定期的にアクセスすることにより、前記アプリケーション管理データベースを更新する管理部と
を備える第１項ないし第７項のうちいずれか１項に記載の制御装置。
（第９項）
複数の網に接続され、ユーザ端末から受信したパケットを当該複数の網のうちのいずれかの網に振り分ける制御装置が実行する制御方法であって、
前記ユーザ端末から送信されたＤＮＳ問い合わせパケットを受信し、当該ＤＮＳ問い合わせパケットの問い合わせ対象に基づいて、当該ＤＮＳ問い合わせパケットを前記複数の網のうちのいずれかの網に振り分けるステップと、
パケットを受信し、当該パケットの宛先アドレスに基づいて当該パケットの送信先を決定し、決定された送信先に当該パケットを送信するステップと
を備える制御方法。
（第１０項）
コンピュータを、第１項ないし第８項のうちいずれか１項に記載の制御装置における各部として機能させるためのプログラム。

以上、本実施の形態について説明したが、本発明はかかる特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

１０ ユーザ端末
２０ 閉域網
３０ インターネット
１００ アクセス装置
１１０ 指令受信部
１２０ ＤＮＳ制御部
１２１ ＤＮＳ振り分け部
１２２ ＤＮＳ振り分けポリシー管理部
１２３ 問い合わせ先変更部
１３０ 共通アプリケーション管理部
１４０ ＳＤ−ＷＡＮルーティング部
１４１ アプリ検知部
１４２ ルーティング制御部
１４３ ルーティングポリシー管理部
１５０ 閉域網接続ＩＦ
１６０ Ｉｎｔｅｒｎｅｔ接続ＩＦ
１７０ ＬＡＮ−ＩＦ
１８０ プロキシ制御部
１８１ プロキシ振り分け部
１８２ プロキシ振り分けポリシー管理部
２１０ 内部ＤＮＳサーバ
２２０ 内部プロキシサーバ
３１０ 外部ＤＮＳサーバ
３２０ ＳａａＳサーバ
４００ 外部アプリケーション管理サーバ
１０００ ドライブ装置
１００１ 記録媒体
１００２ 補助記憶装置
１００３ メモリ装置
１００４ ＣＰＵ
１００５ インターフェース装置
１００６ 表示装置
１００７ 入力装置

Claims (10)

1. 複数の網に接続され、ユーザ端末から受信したパケットを当該複数の網のうちのいずれかの網に振り分ける制御装置であって、
   前記ユーザ端末から送信されたＤＮＳ問い合わせパケットを受信し、当該ＤＮＳ問い合わせパケットの問い合わせ対象に基づいて、当該ＤＮＳ問い合わせパケットを前記複数の網のうちのいずれかの網に振り分けるＤＮＳ制御部と、
   パケットを受信し、当該パケットの宛先アドレスに基づいて当該パケットの送信先を決定し、決定された送信先に当該パケットを送信するルーティング部と
   を備える制御装置。
2. 前記制御装置は、パケットの宛先アドレスと当該パケットの宛先のアプリケーションとを対応付けた情報を格納するアプリケーションテーブルを備え、
   前記ルーティング部は、前記アプリケーションテーブルを参照することにより、受信したパケットの宛先アドレスに対応するアプリケーションを把握し、当該アプリケーションに対して予め定められたポリシーに従って当該パケットを前記複数の網のうちのいずれかの網に振り分ける
   請求項１に記載の制御装置。
3. 前記ルーティング部は、前記ＤＮＳ問い合わせパケットの問い合わせ対象と、問い合わせの応答として受信したアドレスとを用いて前記アプリケーションテーブルを更新する
   請求項２に記載の制御装置。
4. 前記アプリケーションテーブルは、レコード毎にタイマー値を有し、当該タイマー値の期間が経過したレコードを削除する
   請求項２又は３の制御装置。
5. 前記ＤＮＳ制御部は、前記ＤＮＳ問い合わせパケットの宛先アドレスを、当該ＤＮＳ問い合わせパケットの振り分け先に応じて書き換える
   請求項１ないし４のうちいずれか１項に記載の制御装置。
6. 前記制御装置は所定のプロキシ装置に接続されており、前記制御装置は、
   受信したパケットのアクセス先のアプリケーションに基づいて、当該パケットを前記プロキシ装置に送信するか否かを決定するプロキシ制御部
   を更に備える請求項１ないし５のうちいずれか１項に記載の制御装置。
7. 前記プロキシ制御部は、
   アプリケーション毎の宛先アドレスと動作とを記録したプロキシ振り分けテーブルを備え、当該プロキシ振り分けテーブルを参照することにより、パケットを前記プロキシ装置に送信するか否かの決定を行い、
   前記アプリケーションテーブルを利用して前記プロキシ振り分けテーブルを更新する
   請求項２ないし４のうちいずれか１項に従属する請求項６に記載の制御装置。
8. 前記制御装置は、
   アプリケーションの情報を管理するアプリケーション管理データベースと、
   外部のアプリケーション管理サーバに定期的にアクセスすることにより、前記アプリケーション管理データベースを更新する管理部と
   を備える請求項１ないし７のうちいずれか１項に記載の制御装置。
9. 複数の網に接続され、ユーザ端末から受信したパケットを当該複数の網のうちのいずれかの網に振り分ける制御装置が実行する制御方法であって、
   前記ユーザ端末から送信されたＤＮＳ問い合わせパケットを受信し、当該ＤＮＳ問い合わせパケットの問い合わせ対象に基づいて、当該ＤＮＳ問い合わせパケットを前記複数の網のうちのいずれかの網に振り分けるステップと、
   パケットを受信し、当該パケットの宛先アドレスに基づいて当該パケットの送信先を決定し、決定された送信先に当該パケットを送信するステップと
   を備える制御方法。
10. コンピュータを、請求項１ないし８のうちいずれか１項に記載の制御装置における各部として機能させるためのプログラム。

Images