JP3805771B2 - ネットワーク上における透過ゲートウェイまたは透過プロキシ具現方法 - Google Patents
ネットワーク上における透過ゲートウェイまたは透過プロキシ具現方法 Download PDFInfo
- Publication number
- JP3805771B2 JP3805771B2 JP2003508029A JP2003508029A JP3805771B2 JP 3805771 B2 JP3805771 B2 JP 3805771B2 JP 2003508029 A JP2003508029 A JP 2003508029A JP 2003508029 A JP2003508029 A JP 2003508029A JP 3805771 B2 JP3805771 B2 JP 3805771B2
- Authority
- JP
- Japan
- Prior art keywords
- gateway
- packet
- session
- transparent
- destination
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
- 238000000034 method Methods 0.000 title claims description 41
- 238000013519 translation Methods 0.000 claims description 7
- 238000006243 chemical reaction Methods 0.000 description 18
- 230000005540 biological transmission Effects 0.000 description 14
- 238000010586 diagram Methods 0.000 description 11
- 238000004891 communication Methods 0.000 description 3
- 230000000903 blocking effect Effects 0.000 description 2
- 238000005516 engineering process Methods 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 239000013065 commercial product Substances 0.000 description 1
- 230000000295 complement effect Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 238000013507 mapping Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 239000013589 supplement Substances 0.000 description 1
- 238000012795 verification Methods 0.000 description 1
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/66—Arrangements for connecting between networks having differing types of switching systems, e.g. gateways
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
- H04L61/09—Mapping addresses
- H04L61/25—Mapping addresses of the same type
- H04L61/2503—Translation of Internet protocol [IP] addresses
- H04L61/255—Maintenance or indexing of mapping tables
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L61/00—Network arrangements, protocols or services for addressing or naming
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/161—Implementation details of TCP/IP or UDP/IP stack architecture; Specification of modified or new header fields
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
- H04L69/163—In-band adaptation of TCP data exchange; In-band control procedures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/40—Network security protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/16—Implementation or adaptation of Internet protocol [IP], of transmission control protocol [TCP] or of user datagram protocol [UDP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/30—Definitions, standards or architectural aspects of layered protocol stacks
- H04L69/32—Architecture of open systems interconnection [OSI] 7-layer type protocol stacks, e.g. the interfaces between the data link level and the physical level
- H04L69/322—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions
- H04L69/329—Intralayer communication protocols among peer entities or protocol data unit [PDU] definitions in the application layer [OSI layer 7]
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer Security & Cryptography (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Small-Scale Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ネットワーク上における透過ゲートウェイ(transparent gateway)または透過プロキシ(transparent proxy)具現方法に関し、特に、ネットワーク住所変換(Network Address Translation：以下、ＮＡＴと略す)手法が具現されたルータ(Router)、ゲートウェイまたはスイッチング装備などでＮＡＴを変形した手法を使用することによって透過ゲートウェイまたは透過プロキシを具現できる方法に関する。
【０００２】
【従来の技術および発明が解決しようとする課題】
透過ゲートウェイとは、使用者側からみるとき、まるでゲートウェイ無しにサーバーと直接通信しているかのように見えるゲートウェイを意味する。つまり、透過ゲートウェイは、使用者がゲートウェイまたはプロキシを直接設定しなくてもＴＣＰ(Transmission Control Protocol)のサービスポートに該当する全てのパケットがゲートウェイ或いはプロキシに伝送されて付加的な他の作業を可能にする。
【０００３】
一般に、ゲートウェイとして最も広く活用されるのが、侵入遮断システムのプロキシまたはゲートウェイである。一般のプロキシでは全ての使用者がプロキシを設定するか、或いはプロキシに接続した後に実際に接続したいサーバーに再び接続する方式を採択している。しかし、透過ゲートウェイでは、使用者がゲートウェイ或いはプロキシを意識せずに直接接続したいシステムに接続を試みると、透過ゲートウェイで再び検証作業を経て自体的に実際のサーバーと連携して連結を行う。したがって、使用者とサーバーにとってそれらの間にゲートウェイ無しに直接通信しているかのように考えさせるシステムである。
【０００４】
現在使用されている技術によれば、ウェブプロキシ(webproxy)などでは透過プロキシシステムを構成するのが可能である。この方式では、ネットワーク装備でウェブサービスポートが指定されたＴＣＰパケットをプロキシに再伝送(redirection)すると、プロキシから全てのパケットを読み込んだ後、自分のＩＰで再びサーバーと連結されて通信する。これは、ウェブで使用するＨＴＴＰプロトコルで接続しなくてはならない相手側のウェブサーバーのホスト名とＵＲＬ情報があるために可能である。この場合、単純に使用者がプロキシを指定しないでサーバーに直接接続をできるという意味から使われているが、サーバー側にとっては、実際に接続するクライアントを本来のクライアントとして把握するのではなくプロキシをクライアントとして把握する問題が残っている。したがって、サーバー側からクライアントを正確に把握するのが困難であるだけでなく、ＩＰに基づいた認証体系を採択する場合には致命的な弱点となり得る。また、サーバー側で使用者を把握し難いため、課金などのような問題を解決できない場合には、ゲートウェイを通じた接続に対してはサービスできない場合も発生する。このため、保安などの様々な目的からゲートウェイを採択した多くの企業または団体ではゲートウェイの運営と関連して下記のような問題を抱えている。
【０００５】
第一に、使用者の環境を変更させる作業を追加的に行わなければならない。第二に、使用者にゲートウェイを利用する方法を教育する煩わしい作業を必ず行わなければならない。第三に、問題発生のおそれのある部分に対するヘルプデスク(helpdesk)サービス費用が発生する。第四に、前述したように透過ウェブプロキシを運営するとしてもインターネットの数多くのシステムのうちＩＰに基づく制御を行うサーバー側では正常的なサービスが受けられない。第五に、透過ウェブプロキシはＨＴＴＰのように応用プロトコル内に存在する目的地サーバーの情報がわかるウェブに限って適用可能なものであり、仮に、テルネット(Telnet)やファイル伝送プロトコル(ＦＴＰ)のようなゲートウェイで構成された場合、まず使用者はゲートウェイに接続し、ゲートウェイから再びサーバーのＩＰに接続を試みてこそ望むサーバーに連結可能である。したがって、透過ウェブプロキシだけでなく、ＴＣＰを根幹とする全てのサービスにおける応用プログラムに対して透過プロキシ或いは透過ゲートウェイを具現する必要がある。
【０００６】
ここ数年間急速に成長してきたインターネットは、その構造が、現在のような膨大な連結を予測できなかった数十年前に創案されたため、可用インターネットプロトコル(Internet Protocol：以下、ＩＰと略す)の問題点を補完するためにＮＡＴという概念が登場した。一般にＮＡＴは、私設網住所の再使用概念に基づいたものであって、ルータなどに適用されてルータが各ポート(port)からデータを受け取ってＮＡＴ規則(Mapping Rule)にしたがってＩＰパケットの発信地住所(Source IP Address)領域(field)を公認ＩＰ住所に変換して伝送する。前記ＮＡＴの適用されたネットワーク装備は別途の住所プール(pool)に適当量の公認ＩＰ住所を確保しており、私設網から外部網への接続要請があると、確保していた公認ＩＰ住所のうち使用されない住所を私設網に割り当てる。ここで、公認ＩＰ住所の変換はＮＡＴテーブルを通じて管理する。
【０００７】
図１は、基本ＮＡＴ概念を説明する図である。図１に示すように、基本ＮＡＴの方法では、データフローにおいてアウトゴーイング(outgoing)時には発信地のローカルＩＰ住所に一つのグロバール住所を割り当て、これを変換テーブルに記録した後、ローカルＩＰ住所をグロバールＩＰ住所に変換して伝送し、インカミング(incoming)時には、目的時(つまり、アウトゴーイング時の変換された発信地)のグロバールＩＰ住所を利用してローカルＩＰ住所を検索した後、グロバールＩＰ住所をローカルＩＰに変換する。このような基本ＮＡＴでは目的地ＩＰ住所だけでデータフローが区分でき、複数台のホストが一つのＩＰ住所を同時に共有できないので、住所変換は容易であるが、ＩＰ住所利用率は大幅に劣る。図１を参照してこれを具体的に説明する。
【０００８】
例えば、ローカルネットワークのホストＡとグロバールネットワークのＸが通信し、ローカルネットワークのホストＢとグロバールネットワークのＹが通信をすると仮定する。ＡからＸに向かうデータフローにおいて発信地のＡの住所とここに割り当てられたグロバールＩＰ住所Ｇを変換テーブルに記録する。図１に示すように、仮に、ＢからＹに向かうデータフローに対してもＡからＸに向かうデータフローに割り当てられた同一のＩＰ住所Ｇを割り当てると、基本ＮＡＴではインカミング時Ｙからくるデータを伝達するために目的地住所のＧだけで変換テーブルを検索するとき、ＡとＢのローカル住所が全て検索されるので、どこにデータを伝達したらいいか混乱が生じる。したがって、基本ＮＡＴ方法ではローカルネットワークにおいて各々のローカルＩＰ住所を有する複数台のホストが同時に同一グロバールＩＰに変更できない。これを解決するために通常、ＩＰとポートを含めて変換テーブルに記録する。
【０００９】
図１の例に挙げてさらに具体的に説明する。ＡからＸに向かうデータフローにおいて発信地のＡの住所とポート番号１００に割り当てられたグロバールＩＰ住所Ｇとポート番号１０００を変換テーブルに記録する。ＮＡＴでは、図１に示すように、ＢからＹに向かうデータフローについても、発信地Ｂの住所とポート番号１００にポート番号２０００だけを異にしてグロバール住所Ｇを割り当てることができる。このとき、インカミング時ＹからＢにくるデータを伝達するために、目的地住所のＧとポート番号２０００で変換テーブルを検索すると、Ｂのローカル住所とポート番号１００だけが検索されるので、同一のグロバールＩＰ住所Ｇを持ってもＡからＸへのデータフローとＢからＹへのデータフローが区分できる。
【００１０】
本発明の目的は、前記従来の技術の問題点を解決するために、ネットワーク住所変換手法が具現されたルータ、ゲートウェイまたはスイッチング装備でＮＡＴを変形した手法を使用することによって、透過ゲートウェイまたは透過プロキシが具現できる方法を提供することにある。
【００１１】
【課題を解決するための手段】
前記目的を達成するために、本発明によるネットワーク上における透過ゲートウェイまたは透過プロキシ具現方法は、ネットワーク住所変換テーブルを備えるネットワーク装備を使ってゲートウェイまたはプロキシを含むネットワーク上で透過ゲートウェイまたは透過プロキシを具現する方法において、受信されたパケットに対して出発地または目的地ポートがネットワーク住所変換テーブルに存在するか否か照会する第１段階；前記第１段階で出発地または目的地ポートがネットワーク住所変換テーブルに存在する場合、セッションをセッション情報テーブルに記録する第２段階；前記第２段階以降のパケットに対してＩＰ住所を変更する第３段階；を含むことを特徴とする。
【００１２】
本発明によれば、使用者側からみるとき、まるでゲートウェイ無しに直接サーバー側と通信しているかのように見えるようにする透過ゲートウェイまたは透過プロキシを具現することによって使用者の環境を変更させる作業が要らなくなり、使用者にゲートウェイを利用する方法を教育せずに済むので、ネットワークの構成およびメンテナンスにかかる費用を大幅に節減できる。
【００１３】
また、本発明によれば、ＩＰに基づいて制御を行うサーバー側で正常的なサービスを提供することができ、テルネットやファイル伝送プロトコル(ＦＴＰ)のようにプロトコルの内容から目的地ＩＰがわからないプロトコルに対するプロキシまたはゲートウェイで構成された場合にも透明性が保障できる。
【００１４】
【発明の実施の形態】
図２は、ＩＰヘッダ(IP header)の構成を示す図であり、図３は、ＴＣＰヘッダ(TCP header)の構成を示す図であり、図４は、本発明による透過ゲートウェイを適用したネットワーク構成図である。
【００１５】
図４において、クライアント１０は、サーバー７０と直接通信できるが、通常、保安などの目的からネットワーク中間にはゲートウェイが設置される。この種のゲートウェイの代表的な例が侵入遮断システムである。その他のゲートウェイとしてウェブプロキシ、ＳＭＴＰゲートウェイ、ＦＴＰゲートウェイ、テルネットゲートウェイなど様々な形態のゲートウェイが考えられる。一般に、ゲートウェイをネットワークのトラフィック経路に設置する場合には、クライアントは環境を変えてゲートウェイに接続し、ゲートウェイは再びサーバーと接続しなければならない。このとき、クライアントとサーバー間の通信はＩＰデータグラム(datagram)を通じて行われる。したがって、ネットワーク住所変換(ＮＡＴ)の含まれたネットワーク装備３０のＩＰデータプログラムでＩＰヘッダを変形するのが可能である。仮に、アウトゴーイングパケットがゲートウェイを必要とするパケットであれば、ゲートウェイがパケットを受けるように目的地ＩＰ住所を変更する。すると、パケットはゲートウェイＧ１ ４０やゲートウェイＧ２ ５０に流れ、ゲートウェイは該当パケットを読み取って処理することができる。該当パケットが処理されると、パケットは再びネットワーク装備３０に送信される。ネットワーク装備３０では、そのパケットの発信地ＩＰをゲートウェイのＩＰからクライアントＩＰに変えた後、サーバー７０側に送信する。
【００１６】
次いで、サーバー７０からくるインカミングパケットについて説明する。インカミングパケットがネットワーク装備３０に到達すると、クライアントＩＰになっている目的地ＩＰを変更してゲートウェイ４０、５０のＩＰに変える。ゲートウェイ４０、５０での処理が終わると、処理されたパケットは再びネットワーク装備３０に伝達され、そのパケットの発信地ＩＰをサーバー７０のＩＰに変えてクライアント１０に送信する。このように、クライアント１０とサーバー７０との通信はゲートウェイのＩＰを隠した状態でなされるのである。
【００１７】
図５および図６を参照して本発明による透過ゲートウェイまたは透過プロキシ具現方法の具体的な例を説明する。
図５は、本発明によるネットワーク住所変換を変形した、透過ゲートウェイまたは透過プロキシ具現方法の一実施例を説明するための構成図であり、図６は、一般のゲートウェイとのＴＣＰセッション連結過程を示す例である。
【００１８】
図５で、ホストＣ １００はＩＰ住所がＣであるクライアントであり、ホストＳ １１０はＩＰ住所がＳであるサーバーである。ゲートウェイ１２０はＧというＩＰ住所をもっている。この状態で、ネットワーク装備１３０のＮＡＴテーブルに図示のように定義する。すなわち、２３番ポートを使用するテルネットは目的地ポートが２３であり、ゲートウェイはＧを使用し、８０番ポートを使用するウェブは目的地ポートが８０であり、ゲートウェイはＧを使用する。
【００１９】
図５および図６を参照すれば、まず、ホストＣ １００は、ホストＳ １１０に通信接続を試みる。この過程で、ＴＣＰパケットにはＳＹＮフラグがセッティングされる。(Ｃ：Ｇ、２３ ＳＹＮ)。ＴＣＰヘッダには出発地ポートと目的地ポートが入っている。ネットワーク装備のＮＡＴ １３０では目的地ポートが２３番か、８０ポートであればゲートウェイに送るパケットであることがわかる。すると、目的地ＩＰ住所をＧに変えた後、ゲートウェイ１２０にルーチングする。このとき、ネットワーク装備１３０ではセッション情報テーブルにルーチング情報を含めて登録する。このセッション情報テーブルは次のように構成されている。
【００２０】
【表１】
【００２１】
ゲートウェイ１２０は、そのパケットを読み込んでクライアント１００にＳＹＮとＡＣＫフラグをセッティングしたパケットをネットワーク装備１３０に送る(Ｇ、２３：Ｃ ＳＹＮ＋ＡＣＫ)。ネットワーク装備１３０では既に登録されているセッション情報テーブルを参照してパケットをどのように処理するか判断する。このとき、出発地ポートが２３であるため、このパケットはクライアントの応答パケットであることがわかる。したがって、出発地ＩＰをサーバーのＩＰに変更した後、クライアントに伝送する。
【００２２】
クライアント１００は、再びＡＣＫフラグを載せたパケット(Ｃ：Ｇ、２３ＡＣＫ)を再び伝送し、これにより、クライアントとゲートウェイ間のＴＣＰ連結が完了される。ここまでの過程をみると、ゲートウェイが実際の目的地ＩＰ住所を知らないという問題点がある。したがって、ネットワーク装備１３０のＮＡＴでは前記テーブルの値をゲートウェイ１２０に再び伝送する必要がある。図６においてＮＡＴを含むネットワーク装備１３０からゲートウェイ１２０にセッション情報を伝送する。これにより、ゲートウェイ１２０は実際に接続するサーバーのＩＰを確認できる。
【００２３】
その後、ゲートウェイ１２０は、サーバーとＴＣＰ連結をしなければならないため、ＳＹＮフラグの含まれたパケット(Ｇ：Ｓ、２３ ＳＹＮ)を送信する。ネットワーク装備１３０では前記テーブルを参照して出発地ＩＰのゲートウェイＩＰをクライアントＩＰのＣに変更したパケット(Ｃ：Ｓ、２３ ＳＹＮ)に変更してサーバー１１０に伝送する。サーバー１１０は応答パケット(Ｓ、２３：Ｃ ＳＹＮ＋ＡＣＫ)をクライアント１００に伝送する。このとき、またネットワーク装備１３０でまずパケットを読み取って処理するため、前記セッション情報テーブル値によってゲートウェイ１２０を使用するということがわかる。したがって、目的地ＩＰをクライアントＣからゲートウェイＧに変更したパケット(Ｓ、２３：Ｇ ＳＹＮ＋ＡＣＫ)をゲートウェイ１２０に送信する。
【００２４】
ゲートウェイ１２０は、ＡＣＫフラグが設定されたパケット(Ｇ：Ｓ、２３ ＡＣＫ)を再びサーバー１１０に送ると、中間のネットワーク装備１３０ではセッション情報テーブル値からクライアント情報を得て修正したパケット(Ｃ：Ｓ、２３ ＡＣＫ)をサーバーに伝送する。これにより、ゲートウェイ１００とサーバー１１０間のＴＣＰ連結が完了される。これにより、実質的なクライアント１００とサバー１１０間のＴＣＰ連結がゲートウェイ１２０を介してなされるのである。
【００２５】
図７は、透過プロキシに設定されているゲートウェイとのＴＣＰ連結過程を示す図である。
一般的な商用ゲートウェイ或いはプロキシの中には応用プログラムによって目的地がどこに存在するかわかる場合がある。代表的なものがリレーメールシステム(SYSTEM)とウェブプロキシ(HTTP)である。ここでは応用プログラムのデータ内部から目的地ＩＰを探す。この場合、図６に示すように、セッション情報をゲートウェイに伝達すると、応用プログラムのプロトコルが変更されるので、商用製品をそのまま利用できない問題がある。そこで、前記問題を補完するために図５のＮＡＴテーブルにモードを設定する。このモードの値がＧであれば、一般のゲートウェイ(Global Gateway)という意味であり、モードの値がＴであれば、ゲートウェイが目的地ＩＰを分かる透過ゲートウェイ(Transparent Gateway)という意味を持つ。
【００２６】
仮に、目的地ポートが８０と設定され、ウェブプロキシをゲートウェイとして設定する場合なら、モードはＴと設定し、図７のようにＴＣＰ連結がなされる。図７と図６の違いは、図７ではセッション情報をゲートウェイに伝達しないという点である。
【００２７】
図８は、ＮＡＴによる住所変換方法を示す流れ図である。
まず、パケットが入ってくると、ＴＣＰか否か確認する(Ｓ８００)。ＴＣＰでないとパケットをそのまま伝送し、ＴＣＰパケットなら目的地ポートがＮＡＴテーブルに存在するか確認する(Ｓ８１０)。目的地ポートがＮＡＴテーブルに存在しないと出発地ポートがＮＡＴテーブルに存在するか確認する(Ｓ８２０)。仮に、ＮＡＴテーブルに出発地ポートが存在しないと、このパケットはゲートウェイと関わりのないパケットなので、そのままパケット伝送モジュールに送る。
【００２８】
一方、出発地或いは目的地ポートがＮＡＴテーブルに存在すると、出発地ＩＰがゲートウェイＩＰか確認する(Ｓ８３０)。参考に、目的地ＩＰがゲートウェイＩＰとなることは発生しない。これは、目的地ＩＰをゲートウェイのＩＰに変えることはＮＡＴでの仕事であるからである。
【００２９】
出発地ＩＰがゲートウェイＩＰでないと、これは、クライアントやサーバーのパケットであるのを意味するので、これに対する処理を続け、ＳＹＮフラグのセッティングされたパケットか確認し(Ｓ８４０)、ＳＹＮフラグのセッティングされたパケットならセッションを開始するパケットを意味するので、セッションをセッション情報テーブルに登録する(Ｓ８５０)。
【００３０】
次いで、ゲートウェイモードがＧか確認する(Ｓ８６０)。ゲートウェイモードがＧでなくＴの場合は、ＩＰ住所を変更しないままパケット伝送モジュールに送る。しかし、ゲートウェイモードがＧの場合にはセッション情報テーブルからセッションを照会する(Ｓ８７０)。このとき照会するのは、出発地ＩＰ、出発地ポート、目的地ＩＰ、目的地ポートの情報であって、唯一つのレコードを探索することによってテーブルに結果があるか判断する(Ｓ８８０)。
【００３１】
テーブルに結果があると、目的地ＩＰをゲートウェイＩＰに変更し(Ｓ９００)、パケット伝送モジュールに送る。探索結果テーブルに結果がない場合にはパケットを捨てる(Ｓ８９０)。ここまで説明した内容は、クライアント或いはサーバーからパケットが送られる場合に関する。
【００３２】
一方、ゲートウェイでパケットを処理して送信した場合(Ｓ８３０)には、目的地ＩＰと目的地ポート、ゲートウェイＩＰと出発地ポートを通じてセッション情報テーブルからレコードを探索する(Ｓ９１０)。探索結果、テーブルに結果があるか判断し(Ｓ９２０)、存在する場合には、仮にパケットにＦＩＮフラグのセッティングされたパケットが二番目に発生するか、ＲＳＴフラグがセッティングされたパケットを処理すると(Ｓ９４０)、セッションテーブルからセッションを削除し(Ｓ９５０)、ゲートウェイＩＰとなっている出発地ＩＰをテーブル上の実際のＩＰに変更し(Ｓ９６０)、パケット伝送モジュールに送る。
【００３３】
前記段階Ｓ９４０で、パケットにＦＩＮフラグのセッティングされたパケットが二番目に発生するか、またはＲＳＴフラグがセッティングされたパケットを処理するのでないと、セッションを削除する段階(Ｓ９５０)を省略し、直ぐゲートウェイＩＰとなっている出発地ＩＰをテーブル上の実際のＩＰに変更し(Ｓ９６０)、パケットを伝送するモジュールに送る。
一方、前記段階Ｓ９２０でセッション情報テーブルにレコードが存在しない場合にはパケットを捨てる(Ｓ９３０)。
【００３４】
次いで、本発明による透過ゲートウェイまたは透過プロキシ具現方法の他の実施例を図９および図１０を参照して説明する。前記実施例においては、透過ゲートウェイまたはプロキシの具現に当たって負担となる部分がセッション情報をゲートウェイ側に再び伝送する部分である。仮に、ゲートウェイで目的地ＩＰを用いて別途処理をしないと、クライアントのセッション連結時に出発地ポートが同時に同ポート番号を利用できないというＴＣＰ／ＩＰの特性からセッション情報をゲートウェイに送る部分を省き、その代わりに図９のように具現できる。すなわち、図９のようにセッションテーブルを変更し、ゲートウェイセッションテーブルを追加する。
【００３５】
図９の各テーブルで各項目が作られる過程を説明する。ＳＹＮフラグがあるパケットが入ってくる場合には、出発地ＩＰがゲートウェイＩＰでないと、セッションテーブルにセッションを追加する(Ｓ１０００)と共に、ゲートウェイセッションテーブルを追加する(Ｓ１１００)。そして、セッションテーブルとゲートウェイセッションテーブルを連結する(Ｓ１２００)。同様に、ゲートウェイセッションテーブルでもセッションテーブルが探せるようにセッションテーブルと連結する(Ｓ１３００)。すると、ゲートウェイセッションテーブルにある情報の通りにパケットを修正し(すなわち、目的地ＩＰがＤ１からＧ１に修正)、パケットをパケット伝送モジュールに送る。
【００３６】
ゲートウェイからは目的地ＩＰが分からないため、目的地ＩＰの代わりに出発地ＩＰに連結を試みる。このとき、住所変換機で本来のセッションを確認できなければならないため、目的地ポートも出発地のポートに連結を試みなければならない。つまり、たとえ出発地ＩＰに連結を試みても実質的には目的地ＩＰに連結させるのがこの説明における核心となる。この場合には、ＳＹＮフラグがあるパケットが入ってくるが、出発地ＩＰはゲートウェイＩＰ住所となる。このとき、ゲートウェイセッションテーブルにもう一つを追加する(Ｓ１４００)。このとき追加する項目では目的地ＩＰをゲートウェイＩＰに変更した部分が異なっている。ゲートウェイセッションテーブルからセッションテーブルを探せるようにセッションテーブルと連結する(Ｓ１５００)。このときには目的地ＩＰと出発地ポートを用いてセッションテーブルを探せばいい。最後に、セッションテーブルから再びゲートウェイセッションを探せるように連結する(Ｓ１６００)。
【００３７】
実際データの伝送過程で住所変換方式を説明すると次のようになる。まず、出発地ＩＰがゲートウェイＩＰの場合には、ゲートウェイセッションテーブルを検索する。仮に、目的地ポートがＮＡＴテーブルに存在すると、ゲートウェイセッションテーブルのＳｅｓｓが指すセッションテーブルの情報の通りにＩＰを変換する。しかし、目的地ポートがＮＡＴテーブルに存在しないと、ゲートウェイセッションテーブルのＳｅｓｓが指すセッションテーブルと逆に(つまり、出発地ＩＰはセッションテーブル上の目的地ＩＰに、目的地ＩＰはセッションテーブル上の出発地ＩＰに、出発地ポートはセッションテーブル上の目的地ポートに、目的地ポートはセッションテーブル上の出発地ポートに)ＩＰとポートを変更する。
【００３８】
仮に、出発地ＩＰがゲートウェイＩＰでないと、まず、セッションテーブルを検索する。検索ができたらＣＰＴＲから指すゲートウェイセッションテーブルの形態にＩＰを変更する。検索できなかったら、ＩＰとポートの出発地と到着地を返して再び検索する。検索できたらセッションテーブルのＳＰＴＲから指すゲートウェイセッションテーブルの形態にＩＰを変更する。
【００３９】
次に、セッションテーブルの項目が削除される場合を説明する。入力されたパケットがＦＩＮフラグに二番目に会うか、或いはＲＳＴフラグがセッティングされたパケットの場合は、セッションを完全に終了するという意味である。仮に、出発地ＩＰがゲートウェイＩＰである場合には、実際のデータ伝送過程と同様にパケットを修正して送った後、ゲートウェイセッションテーブルの該当項目を削除する。しかし、出発地ＩＰがゲートウェイＩＰでない場合には、実際のデータ伝送過程と同様にパケットを修正して送った後、セッションテーブルの該当項目を削除する。
【００４０】
図１０は、図９における方法による本発明の他の一実施例を示す流れ図である。
まず、パケットを受信し(Ｓ２０００)、目的地ポートがＮＡＴテーブルに存在するか確認する(Ｓ２０１０)。
ＮＡＴテーブルに目的地ポートが存在すると、ＳＹＮフラグがセッティングされたか確認する(Ｓ２０２０)。ＳＹＮフラグがセッティングされたら、出発地ＩＰがゲートウェイＩＰか確認する(Ｓ２０３０)。
【００４１】
出発地ＩＰがゲートウェイＩＰでない場合には、セッションテーブルに登録し(Ｓ２０４０)、また、ゲートウェイセッションテーブルにも登録する(Ｓ２０５０)。次いで、セッションテーブルのＣｐｔｒを連結し(Ｓ２０６０)、ＳＴ．Ｃｐｔｒと同一にＩＰを変更する(Ｓ２０７０)。
一方、前記段階Ｓ２０３０で、出発地ＩＰがゲートウェイＩＰの場合、ゲートウェイセッションテーブルに登録し(Ｓ２０８０)、セッションテーブルのＳｐｔｒを連結する(Ｓ２０９０)。次いで、ゲートウェイセッションテーブルのＳｅｓｓと同一にＩＰとポートを変更する(Ｓ２１００)。
【００４２】
また、前記段階Ｓ２０２０で、ＳＹＮフラグがセッティングされていない場合、出発地ＩＰがゲートウェイＩＰか確認した後(Ｓ２１１０)、出発地ＩＰがゲートウェイＩＰでない場合セッションテーブルからセッションを照会する(Ｓ２１２０)。出発地ＩＰがゲートウェイＩＰである場合には後述する段階(Ｓ２２００)に進む。
その後、ＩＰにおいて出発地と到着地が反対となっているか確認し(Ｓ２１３０)、出発地と到着地が反対の場合、ＳＴ．Ｓｐｔｒと同一にＩＰとポートを変更する(Ｓ２１４０)。出発地と到着地ＩＰが反対でない場合、ＳＴ．Ｃｐｔｒと同一にＩＰとポートを変更する。
【００４３】
次いで、ＦＩＮまたはＲＳＴフラグをセッティングしたか確認し(Ｓ２１６０)、ＦＩＮまたはＲＳＴフラグをセッティングした場合セッションテーブルを削除し(Ｓ２１７０)、パケット伝送モジュールに送る。
一方、前記段階Ｓ２０１０で、目的地ポートがＮＡＴテーブルに存在しないと、出発地ポートがＮＡＴテーブルに存在するか確認した後(Ｓ２１８０)、ＮＡＴテーブルに存在すると、前記段階Ｓ２０２０に進んで前述と同様に以後の段階を行い、存在しないと、出発地ＩＰがゲートウェイＩＰと同一か判断する(Ｓ２１９０)。
【００４４】
出発地ＩＰがゲートウェイＩＰと同一であれば、ゲートウェイセッションテーブルからセッションを照会し(Ｓ２２００)、テーブルにセッションが存在するか判断する(Ｓ２２１０)。
セッションが存在しないと、パケット伝送モジュールに直接送り、セッションが存在すると、ゲートウェイセッションテーブルのＳｅｓｓと同一にＩＰとポートを変更する(Ｓ２２２０)。
【００４５】
続いて、ＦＩＮまたはＲＳＴフラグセッティングされたか確認し(Ｓ２２３０)、セッティングされていない場合には直ぐパケット伝送モジュールに送り、セッティングされている場合にはゲートウェイセッションを削除した後(Ｓ２２４０)、パケット伝送モジュールに送る。
以上では最も好ましい実施例に上げて本発明の構成およびその作用について説明してきたが、本発明は、前記実施例に限定されなく、後述する特許請求の範囲内で様々な修正および変形が可能なのは当業者にとって明白であろう。
【図面の簡単な説明】
【図１】 基本ネットワーク住所変換技術の概念図。
【図２】 ＩＰヘッダの構成を示す図。
【図３】 ＴＣＰヘッダの構成を示す図。
【図４】 本発明による透過ゲートウェイを適用したネットワーク構成図。
【図５】 変形されたネットワーク住所変換技術の概念図。
【図６】 本発明による一般のゲートウェイとのＴＣＰセッション連結過程の一例を示す流れ図。
【図７】 本発明による透過プロキシに設定されたゲートウェイとのＴＣＰセッション連結過程の例を示す流れ図。
【図８】 本発明による変形されたネットワーク住所変換方法の流れ図。
【図９】 本発明によるネットワーク住所変換方法の他の実施例を説明するための流れ図。
【図１０】 本発明によるネットワーク住所変換方法の他の実施例を説明するための流れ図。
【符号の説明】
１０ クライアント
７０ サーバー
３０ネットワーク装備
４０ ゲートウェイＧ１
５０ ゲートウェイＧ２
６０ 内部ネットワーク
１００ ホストＣ
１２０ ゲートウェイ
【発明の属する技術分野】
本発明は、ネットワーク上における透過ゲートウェイ(transparent gateway)または透過プロキシ(transparent proxy)具現方法に関し、特に、ネットワーク住所変換(Network Address Translation：以下、ＮＡＴと略す)手法が具現されたルータ(Router)、ゲートウェイまたはスイッチング装備などでＮＡＴを変形した手法を使用することによって透過ゲートウェイまたは透過プロキシを具現できる方法に関する。
【０００２】
【従来の技術および発明が解決しようとする課題】
透過ゲートウェイとは、使用者側からみるとき、まるでゲートウェイ無しにサーバーと直接通信しているかのように見えるゲートウェイを意味する。つまり、透過ゲートウェイは、使用者がゲートウェイまたはプロキシを直接設定しなくてもＴＣＰ(Transmission Control Protocol)のサービスポートに該当する全てのパケットがゲートウェイ或いはプロキシに伝送されて付加的な他の作業を可能にする。
【０００３】
一般に、ゲートウェイとして最も広く活用されるのが、侵入遮断システムのプロキシまたはゲートウェイである。一般のプロキシでは全ての使用者がプロキシを設定するか、或いはプロキシに接続した後に実際に接続したいサーバーに再び接続する方式を採択している。しかし、透過ゲートウェイでは、使用者がゲートウェイ或いはプロキシを意識せずに直接接続したいシステムに接続を試みると、透過ゲートウェイで再び検証作業を経て自体的に実際のサーバーと連携して連結を行う。したがって、使用者とサーバーにとってそれらの間にゲートウェイ無しに直接通信しているかのように考えさせるシステムである。
【０００４】
現在使用されている技術によれば、ウェブプロキシ(webproxy)などでは透過プロキシシステムを構成するのが可能である。この方式では、ネットワーク装備でウェブサービスポートが指定されたＴＣＰパケットをプロキシに再伝送(redirection)すると、プロキシから全てのパケットを読み込んだ後、自分のＩＰで再びサーバーと連結されて通信する。これは、ウェブで使用するＨＴＴＰプロトコルで接続しなくてはならない相手側のウェブサーバーのホスト名とＵＲＬ情報があるために可能である。この場合、単純に使用者がプロキシを指定しないでサーバーに直接接続をできるという意味から使われているが、サーバー側にとっては、実際に接続するクライアントを本来のクライアントとして把握するのではなくプロキシをクライアントとして把握する問題が残っている。したがって、サーバー側からクライアントを正確に把握するのが困難であるだけでなく、ＩＰに基づいた認証体系を採択する場合には致命的な弱点となり得る。また、サーバー側で使用者を把握し難いため、課金などのような問題を解決できない場合には、ゲートウェイを通じた接続に対してはサービスできない場合も発生する。このため、保安などの様々な目的からゲートウェイを採択した多くの企業または団体ではゲートウェイの運営と関連して下記のような問題を抱えている。
【０００５】
第一に、使用者の環境を変更させる作業を追加的に行わなければならない。第二に、使用者にゲートウェイを利用する方法を教育する煩わしい作業を必ず行わなければならない。第三に、問題発生のおそれのある部分に対するヘルプデスク(helpdesk)サービス費用が発生する。第四に、前述したように透過ウェブプロキシを運営するとしてもインターネットの数多くのシステムのうちＩＰに基づく制御を行うサーバー側では正常的なサービスが受けられない。第五に、透過ウェブプロキシはＨＴＴＰのように応用プロトコル内に存在する目的地サーバーの情報がわかるウェブに限って適用可能なものであり、仮に、テルネット(Telnet)やファイル伝送プロトコル(ＦＴＰ)のようなゲートウェイで構成された場合、まず使用者はゲートウェイに接続し、ゲートウェイから再びサーバーのＩＰに接続を試みてこそ望むサーバーに連結可能である。したがって、透過ウェブプロキシだけでなく、ＴＣＰを根幹とする全てのサービスにおける応用プログラムに対して透過プロキシ或いは透過ゲートウェイを具現する必要がある。
【０００６】
ここ数年間急速に成長してきたインターネットは、その構造が、現在のような膨大な連結を予測できなかった数十年前に創案されたため、可用インターネットプロトコル(Internet Protocol：以下、ＩＰと略す)の問題点を補完するためにＮＡＴという概念が登場した。一般にＮＡＴは、私設網住所の再使用概念に基づいたものであって、ルータなどに適用されてルータが各ポート(port)からデータを受け取ってＮＡＴ規則(Mapping Rule)にしたがってＩＰパケットの発信地住所(Source IP Address)領域(field)を公認ＩＰ住所に変換して伝送する。前記ＮＡＴの適用されたネットワーク装備は別途の住所プール(pool)に適当量の公認ＩＰ住所を確保しており、私設網から外部網への接続要請があると、確保していた公認ＩＰ住所のうち使用されない住所を私設網に割り当てる。ここで、公認ＩＰ住所の変換はＮＡＴテーブルを通じて管理する。
【０００７】
図１は、基本ＮＡＴ概念を説明する図である。図１に示すように、基本ＮＡＴの方法では、データフローにおいてアウトゴーイング(outgoing)時には発信地のローカルＩＰ住所に一つのグロバール住所を割り当て、これを変換テーブルに記録した後、ローカルＩＰ住所をグロバールＩＰ住所に変換して伝送し、インカミング(incoming)時には、目的時(つまり、アウトゴーイング時の変換された発信地)のグロバールＩＰ住所を利用してローカルＩＰ住所を検索した後、グロバールＩＰ住所をローカルＩＰに変換する。このような基本ＮＡＴでは目的地ＩＰ住所だけでデータフローが区分でき、複数台のホストが一つのＩＰ住所を同時に共有できないので、住所変換は容易であるが、ＩＰ住所利用率は大幅に劣る。図１を参照してこれを具体的に説明する。
【０００８】
例えば、ローカルネットワークのホストＡとグロバールネットワークのＸが通信し、ローカルネットワークのホストＢとグロバールネットワークのＹが通信をすると仮定する。ＡからＸに向かうデータフローにおいて発信地のＡの住所とここに割り当てられたグロバールＩＰ住所Ｇを変換テーブルに記録する。図１に示すように、仮に、ＢからＹに向かうデータフローに対してもＡからＸに向かうデータフローに割り当てられた同一のＩＰ住所Ｇを割り当てると、基本ＮＡＴではインカミング時Ｙからくるデータを伝達するために目的地住所のＧだけで変換テーブルを検索するとき、ＡとＢのローカル住所が全て検索されるので、どこにデータを伝達したらいいか混乱が生じる。したがって、基本ＮＡＴ方法ではローカルネットワークにおいて各々のローカルＩＰ住所を有する複数台のホストが同時に同一グロバールＩＰに変更できない。これを解決するために通常、ＩＰとポートを含めて変換テーブルに記録する。
【０００９】
図１の例に挙げてさらに具体的に説明する。ＡからＸに向かうデータフローにおいて発信地のＡの住所とポート番号１００に割り当てられたグロバールＩＰ住所Ｇとポート番号１０００を変換テーブルに記録する。ＮＡＴでは、図１に示すように、ＢからＹに向かうデータフローについても、発信地Ｂの住所とポート番号１００にポート番号２０００だけを異にしてグロバール住所Ｇを割り当てることができる。このとき、インカミング時ＹからＢにくるデータを伝達するために、目的地住所のＧとポート番号２０００で変換テーブルを検索すると、Ｂのローカル住所とポート番号１００だけが検索されるので、同一のグロバールＩＰ住所Ｇを持ってもＡからＸへのデータフローとＢからＹへのデータフローが区分できる。
【００１０】
本発明の目的は、前記従来の技術の問題点を解決するために、ネットワーク住所変換手法が具現されたルータ、ゲートウェイまたはスイッチング装備でＮＡＴを変形した手法を使用することによって、透過ゲートウェイまたは透過プロキシが具現できる方法を提供することにある。
【００１１】
【課題を解決するための手段】
前記目的を達成するために、本発明によるネットワーク上における透過ゲートウェイまたは透過プロキシ具現方法は、ネットワーク住所変換テーブルを備えるネットワーク装備を使ってゲートウェイまたはプロキシを含むネットワーク上で透過ゲートウェイまたは透過プロキシを具現する方法において、受信されたパケットに対して出発地または目的地ポートがネットワーク住所変換テーブルに存在するか否か照会する第１段階；前記第１段階で出発地または目的地ポートがネットワーク住所変換テーブルに存在する場合、セッションをセッション情報テーブルに記録する第２段階；前記第２段階以降のパケットに対してＩＰ住所を変更する第３段階；を含むことを特徴とする。
【００１２】
本発明によれば、使用者側からみるとき、まるでゲートウェイ無しに直接サーバー側と通信しているかのように見えるようにする透過ゲートウェイまたは透過プロキシを具現することによって使用者の環境を変更させる作業が要らなくなり、使用者にゲートウェイを利用する方法を教育せずに済むので、ネットワークの構成およびメンテナンスにかかる費用を大幅に節減できる。
【００１３】
また、本発明によれば、ＩＰに基づいて制御を行うサーバー側で正常的なサービスを提供することができ、テルネットやファイル伝送プロトコル(ＦＴＰ)のようにプロトコルの内容から目的地ＩＰがわからないプロトコルに対するプロキシまたはゲートウェイで構成された場合にも透明性が保障できる。
【００１４】
【発明の実施の形態】
図２は、ＩＰヘッダ(IP header)の構成を示す図であり、図３は、ＴＣＰヘッダ(TCP header)の構成を示す図であり、図４は、本発明による透過ゲートウェイを適用したネットワーク構成図である。
【００１５】
図４において、クライアント１０は、サーバー７０と直接通信できるが、通常、保安などの目的からネットワーク中間にはゲートウェイが設置される。この種のゲートウェイの代表的な例が侵入遮断システムである。その他のゲートウェイとしてウェブプロキシ、ＳＭＴＰゲートウェイ、ＦＴＰゲートウェイ、テルネットゲートウェイなど様々な形態のゲートウェイが考えられる。一般に、ゲートウェイをネットワークのトラフィック経路に設置する場合には、クライアントは環境を変えてゲートウェイに接続し、ゲートウェイは再びサーバーと接続しなければならない。このとき、クライアントとサーバー間の通信はＩＰデータグラム(datagram)を通じて行われる。したがって、ネットワーク住所変換(ＮＡＴ)の含まれたネットワーク装備３０のＩＰデータプログラムでＩＰヘッダを変形するのが可能である。仮に、アウトゴーイングパケットがゲートウェイを必要とするパケットであれば、ゲートウェイがパケットを受けるように目的地ＩＰ住所を変更する。すると、パケットはゲートウェイＧ１ ４０やゲートウェイＧ２ ５０に流れ、ゲートウェイは該当パケットを読み取って処理することができる。該当パケットが処理されると、パケットは再びネットワーク装備３０に送信される。ネットワーク装備３０では、そのパケットの発信地ＩＰをゲートウェイのＩＰからクライアントＩＰに変えた後、サーバー７０側に送信する。
【００１６】
次いで、サーバー７０からくるインカミングパケットについて説明する。インカミングパケットがネットワーク装備３０に到達すると、クライアントＩＰになっている目的地ＩＰを変更してゲートウェイ４０、５０のＩＰに変える。ゲートウェイ４０、５０での処理が終わると、処理されたパケットは再びネットワーク装備３０に伝達され、そのパケットの発信地ＩＰをサーバー７０のＩＰに変えてクライアント１０に送信する。このように、クライアント１０とサーバー７０との通信はゲートウェイのＩＰを隠した状態でなされるのである。
【００１７】
図５および図６を参照して本発明による透過ゲートウェイまたは透過プロキシ具現方法の具体的な例を説明する。
図５は、本発明によるネットワーク住所変換を変形した、透過ゲートウェイまたは透過プロキシ具現方法の一実施例を説明するための構成図であり、図６は、一般のゲートウェイとのＴＣＰセッション連結過程を示す例である。
【００１８】
図５で、ホストＣ １００はＩＰ住所がＣであるクライアントであり、ホストＳ １１０はＩＰ住所がＳであるサーバーである。ゲートウェイ１２０はＧというＩＰ住所をもっている。この状態で、ネットワーク装備１３０のＮＡＴテーブルに図示のように定義する。すなわち、２３番ポートを使用するテルネットは目的地ポートが２３であり、ゲートウェイはＧを使用し、８０番ポートを使用するウェブは目的地ポートが８０であり、ゲートウェイはＧを使用する。
【００１９】
図５および図６を参照すれば、まず、ホストＣ １００は、ホストＳ １１０に通信接続を試みる。この過程で、ＴＣＰパケットにはＳＹＮフラグがセッティングされる。(Ｃ：Ｇ、２３ ＳＹＮ)。ＴＣＰヘッダには出発地ポートと目的地ポートが入っている。ネットワーク装備のＮＡＴ １３０では目的地ポートが２３番か、８０ポートであればゲートウェイに送るパケットであることがわかる。すると、目的地ＩＰ住所をＧに変えた後、ゲートウェイ１２０にルーチングする。このとき、ネットワーク装備１３０ではセッション情報テーブルにルーチング情報を含めて登録する。このセッション情報テーブルは次のように構成されている。
【００２０】
【表１】
ゲートウェイ１２０は、そのパケットを読み込んでクライアント１００にＳＹＮとＡＣＫフラグをセッティングしたパケットをネットワーク装備１３０に送る(Ｇ、２３：Ｃ ＳＹＮ＋ＡＣＫ)。ネットワーク装備１３０では既に登録されているセッション情報テーブルを参照してパケットをどのように処理するか判断する。このとき、出発地ポートが２３であるため、このパケットはクライアントの応答パケットであることがわかる。したがって、出発地ＩＰをサーバーのＩＰに変更した後、クライアントに伝送する。
【００２２】
クライアント１００は、再びＡＣＫフラグを載せたパケット(Ｃ：Ｇ、２３ＡＣＫ)を再び伝送し、これにより、クライアントとゲートウェイ間のＴＣＰ連結が完了される。ここまでの過程をみると、ゲートウェイが実際の目的地ＩＰ住所を知らないという問題点がある。したがって、ネットワーク装備１３０のＮＡＴでは前記テーブルの値をゲートウェイ１２０に再び伝送する必要がある。図６においてＮＡＴを含むネットワーク装備１３０からゲートウェイ１２０にセッション情報を伝送する。これにより、ゲートウェイ１２０は実際に接続するサーバーのＩＰを確認できる。
【００２３】
その後、ゲートウェイ１２０は、サーバーとＴＣＰ連結をしなければならないため、ＳＹＮフラグの含まれたパケット(Ｇ：Ｓ、２３ ＳＹＮ)を送信する。ネットワーク装備１３０では前記テーブルを参照して出発地ＩＰのゲートウェイＩＰをクライアントＩＰのＣに変更したパケット(Ｃ：Ｓ、２３ ＳＹＮ)に変更してサーバー１１０に伝送する。サーバー１１０は応答パケット(Ｓ、２３：Ｃ ＳＹＮ＋ＡＣＫ)をクライアント１００に伝送する。このとき、またネットワーク装備１３０でまずパケットを読み取って処理するため、前記セッション情報テーブル値によってゲートウェイ１２０を使用するということがわかる。したがって、目的地ＩＰをクライアントＣからゲートウェイＧに変更したパケット(Ｓ、２３：Ｇ ＳＹＮ＋ＡＣＫ)をゲートウェイ１２０に送信する。
【００２４】
ゲートウェイ１２０は、ＡＣＫフラグが設定されたパケット(Ｇ：Ｓ、２３ ＡＣＫ)を再びサーバー１１０に送ると、中間のネットワーク装備１３０ではセッション情報テーブル値からクライアント情報を得て修正したパケット(Ｃ：Ｓ、２３ ＡＣＫ)をサーバーに伝送する。これにより、ゲートウェイ１００とサーバー１１０間のＴＣＰ連結が完了される。これにより、実質的なクライアント１００とサバー１１０間のＴＣＰ連結がゲートウェイ１２０を介してなされるのである。
【００２５】
図７は、透過プロキシに設定されているゲートウェイとのＴＣＰ連結過程を示す図である。
一般的な商用ゲートウェイ或いはプロキシの中には応用プログラムによって目的地がどこに存在するかわかる場合がある。代表的なものがリレーメールシステム(SYSTEM)とウェブプロキシ(HTTP)である。ここでは応用プログラムのデータ内部から目的地ＩＰを探す。この場合、図６に示すように、セッション情報をゲートウェイに伝達すると、応用プログラムのプロトコルが変更されるので、商用製品をそのまま利用できない問題がある。そこで、前記問題を補完するために図５のＮＡＴテーブルにモードを設定する。このモードの値がＧであれば、一般のゲートウェイ(Global Gateway)という意味であり、モードの値がＴであれば、ゲートウェイが目的地ＩＰを分かる透過ゲートウェイ(Transparent Gateway)という意味を持つ。
【００２６】
仮に、目的地ポートが８０と設定され、ウェブプロキシをゲートウェイとして設定する場合なら、モードはＴと設定し、図７のようにＴＣＰ連結がなされる。図７と図６の違いは、図７ではセッション情報をゲートウェイに伝達しないという点である。
【００２７】
図８は、ＮＡＴによる住所変換方法を示す流れ図である。
まず、パケットが入ってくると、ＴＣＰか否か確認する(Ｓ８００)。ＴＣＰでないとパケットをそのまま伝送し、ＴＣＰパケットなら目的地ポートがＮＡＴテーブルに存在するか確認する(Ｓ８１０)。目的地ポートがＮＡＴテーブルに存在しないと出発地ポートがＮＡＴテーブルに存在するか確認する(Ｓ８２０)。仮に、ＮＡＴテーブルに出発地ポートが存在しないと、このパケットはゲートウェイと関わりのないパケットなので、そのままパケット伝送モジュールに送る。
【００２８】
一方、出発地或いは目的地ポートがＮＡＴテーブルに存在すると、出発地ＩＰがゲートウェイＩＰか確認する(Ｓ８３０)。参考に、目的地ＩＰがゲートウェイＩＰとなることは発生しない。これは、目的地ＩＰをゲートウェイのＩＰに変えることはＮＡＴでの仕事であるからである。
【００２９】
出発地ＩＰがゲートウェイＩＰでないと、これは、クライアントやサーバーのパケットであるのを意味するので、これに対する処理を続け、ＳＹＮフラグのセッティングされたパケットか確認し(Ｓ８４０)、ＳＹＮフラグのセッティングされたパケットならセッションを開始するパケットを意味するので、セッションをセッション情報テーブルに登録する(Ｓ８５０)。
【００３０】
次いで、ゲートウェイモードがＧか確認する(Ｓ８６０)。ゲートウェイモードがＧでなくＴの場合は、ＩＰ住所を変更しないままパケット伝送モジュールに送る。しかし、ゲートウェイモードがＧの場合にはセッション情報テーブルからセッションを照会する(Ｓ８７０)。このとき照会するのは、出発地ＩＰ、出発地ポート、目的地ＩＰ、目的地ポートの情報であって、唯一つのレコードを探索することによってテーブルに結果があるか判断する(Ｓ８８０)。
【００３１】
テーブルに結果があると、目的地ＩＰをゲートウェイＩＰに変更し(Ｓ９００)、パケット伝送モジュールに送る。探索結果テーブルに結果がない場合にはパケットを捨てる(Ｓ８９０)。ここまで説明した内容は、クライアント或いはサーバーからパケットが送られる場合に関する。
【００３２】
一方、ゲートウェイでパケットを処理して送信した場合(Ｓ８３０)には、目的地ＩＰと目的地ポート、ゲートウェイＩＰと出発地ポートを通じてセッション情報テーブルからレコードを探索する(Ｓ９１０)。探索結果、テーブルに結果があるか判断し(Ｓ９２０)、存在する場合には、仮にパケットにＦＩＮフラグのセッティングされたパケットが二番目に発生するか、ＲＳＴフラグがセッティングされたパケットを処理すると(Ｓ９４０)、セッションテーブルからセッションを削除し(Ｓ９５０)、ゲートウェイＩＰとなっている出発地ＩＰをテーブル上の実際のＩＰに変更し(Ｓ９６０)、パケット伝送モジュールに送る。
【００３３】
前記段階Ｓ９４０で、パケットにＦＩＮフラグのセッティングされたパケットが二番目に発生するか、またはＲＳＴフラグがセッティングされたパケットを処理するのでないと、セッションを削除する段階(Ｓ９５０)を省略し、直ぐゲートウェイＩＰとなっている出発地ＩＰをテーブル上の実際のＩＰに変更し(Ｓ９６０)、パケットを伝送するモジュールに送る。
一方、前記段階Ｓ９２０でセッション情報テーブルにレコードが存在しない場合にはパケットを捨てる(Ｓ９３０)。
【００３４】
次いで、本発明による透過ゲートウェイまたは透過プロキシ具現方法の他の実施例を図９および図１０を参照して説明する。前記実施例においては、透過ゲートウェイまたはプロキシの具現に当たって負担となる部分がセッション情報をゲートウェイ側に再び伝送する部分である。仮に、ゲートウェイで目的地ＩＰを用いて別途処理をしないと、クライアントのセッション連結時に出発地ポートが同時に同ポート番号を利用できないというＴＣＰ／ＩＰの特性からセッション情報をゲートウェイに送る部分を省き、その代わりに図９のように具現できる。すなわち、図９のようにセッションテーブルを変更し、ゲートウェイセッションテーブルを追加する。
【００３５】
図９の各テーブルで各項目が作られる過程を説明する。ＳＹＮフラグがあるパケットが入ってくる場合には、出発地ＩＰがゲートウェイＩＰでないと、セッションテーブルにセッションを追加する(Ｓ１０００)と共に、ゲートウェイセッションテーブルを追加する(Ｓ１１００)。そして、セッションテーブルとゲートウェイセッションテーブルを連結する(Ｓ１２００)。同様に、ゲートウェイセッションテーブルでもセッションテーブルが探せるようにセッションテーブルと連結する(Ｓ１３００)。すると、ゲートウェイセッションテーブルにある情報の通りにパケットを修正し(すなわち、目的地ＩＰがＤ１からＧ１に修正)、パケットをパケット伝送モジュールに送る。
【００３６】
ゲートウェイからは目的地ＩＰが分からないため、目的地ＩＰの代わりに出発地ＩＰに連結を試みる。このとき、住所変換機で本来のセッションを確認できなければならないため、目的地ポートも出発地のポートに連結を試みなければならない。つまり、たとえ出発地ＩＰに連結を試みても実質的には目的地ＩＰに連結させるのがこの説明における核心となる。この場合には、ＳＹＮフラグがあるパケットが入ってくるが、出発地ＩＰはゲートウェイＩＰ住所となる。このとき、ゲートウェイセッションテーブルにもう一つを追加する(Ｓ１４００)。このとき追加する項目では目的地ＩＰをゲートウェイＩＰに変更した部分が異なっている。ゲートウェイセッションテーブルからセッションテーブルを探せるようにセッションテーブルと連結する(Ｓ１５００)。このときには目的地ＩＰと出発地ポートを用いてセッションテーブルを探せばいい。最後に、セッションテーブルから再びゲートウェイセッションを探せるように連結する(Ｓ１６００)。
【００３７】
実際データの伝送過程で住所変換方式を説明すると次のようになる。まず、出発地ＩＰがゲートウェイＩＰの場合には、ゲートウェイセッションテーブルを検索する。仮に、目的地ポートがＮＡＴテーブルに存在すると、ゲートウェイセッションテーブルのＳｅｓｓが指すセッションテーブルの情報の通りにＩＰを変換する。しかし、目的地ポートがＮＡＴテーブルに存在しないと、ゲートウェイセッションテーブルのＳｅｓｓが指すセッションテーブルと逆に(つまり、出発地ＩＰはセッションテーブル上の目的地ＩＰに、目的地ＩＰはセッションテーブル上の出発地ＩＰに、出発地ポートはセッションテーブル上の目的地ポートに、目的地ポートはセッションテーブル上の出発地ポートに)ＩＰとポートを変更する。
【００３８】
仮に、出発地ＩＰがゲートウェイＩＰでないと、まず、セッションテーブルを検索する。検索ができたらＣＰＴＲから指すゲートウェイセッションテーブルの形態にＩＰを変更する。検索できなかったら、ＩＰとポートの出発地と到着地を返して再び検索する。検索できたらセッションテーブルのＳＰＴＲから指すゲートウェイセッションテーブルの形態にＩＰを変更する。
【００３９】
次に、セッションテーブルの項目が削除される場合を説明する。入力されたパケットがＦＩＮフラグに二番目に会うか、或いはＲＳＴフラグがセッティングされたパケットの場合は、セッションを完全に終了するという意味である。仮に、出発地ＩＰがゲートウェイＩＰである場合には、実際のデータ伝送過程と同様にパケットを修正して送った後、ゲートウェイセッションテーブルの該当項目を削除する。しかし、出発地ＩＰがゲートウェイＩＰでない場合には、実際のデータ伝送過程と同様にパケットを修正して送った後、セッションテーブルの該当項目を削除する。
【００４０】
図１０は、図９における方法による本発明の他の一実施例を示す流れ図である。
まず、パケットを受信し(Ｓ２０００)、目的地ポートがＮＡＴテーブルに存在するか確認する(Ｓ２０１０)。
ＮＡＴテーブルに目的地ポートが存在すると、ＳＹＮフラグがセッティングされたか確認する(Ｓ２０２０)。ＳＹＮフラグがセッティングされたら、出発地ＩＰがゲートウェイＩＰか確認する(Ｓ２０３０)。
【００４１】
出発地ＩＰがゲートウェイＩＰでない場合には、セッションテーブルに登録し(Ｓ２０４０)、また、ゲートウェイセッションテーブルにも登録する(Ｓ２０５０)。次いで、セッションテーブルのＣｐｔｒを連結し(Ｓ２０６０)、ＳＴ．Ｃｐｔｒと同一にＩＰを変更する(Ｓ２０７０)。
一方、前記段階Ｓ２０３０で、出発地ＩＰがゲートウェイＩＰの場合、ゲートウェイセッションテーブルに登録し(Ｓ２０８０)、セッションテーブルのＳｐｔｒを連結する(Ｓ２０９０)。次いで、ゲートウェイセッションテーブルのＳｅｓｓと同一にＩＰとポートを変更する(Ｓ２１００)。
【００４２】
また、前記段階Ｓ２０２０で、ＳＹＮフラグがセッティングされていない場合、出発地ＩＰがゲートウェイＩＰか確認した後(Ｓ２１１０)、出発地ＩＰがゲートウェイＩＰでない場合セッションテーブルからセッションを照会する(Ｓ２１２０)。出発地ＩＰがゲートウェイＩＰである場合には後述する段階(Ｓ２２００)に進む。
その後、ＩＰにおいて出発地と到着地が反対となっているか確認し(Ｓ２１３０)、出発地と到着地が反対の場合、ＳＴ．Ｓｐｔｒと同一にＩＰとポートを変更する(Ｓ２１４０)。出発地と到着地ＩＰが反対でない場合、ＳＴ．Ｃｐｔｒと同一にＩＰとポートを変更する。
【００４３】
次いで、ＦＩＮまたはＲＳＴフラグをセッティングしたか確認し(Ｓ２１６０)、ＦＩＮまたはＲＳＴフラグをセッティングした場合セッションテーブルを削除し(Ｓ２１７０)、パケット伝送モジュールに送る。
一方、前記段階Ｓ２０１０で、目的地ポートがＮＡＴテーブルに存在しないと、出発地ポートがＮＡＴテーブルに存在するか確認した後(Ｓ２１８０)、ＮＡＴテーブルに存在すると、前記段階Ｓ２０２０に進んで前述と同様に以後の段階を行い、存在しないと、出発地ＩＰがゲートウェイＩＰと同一か判断する(Ｓ２１９０)。
【００４４】
出発地ＩＰがゲートウェイＩＰと同一であれば、ゲートウェイセッションテーブルからセッションを照会し(Ｓ２２００)、テーブルにセッションが存在するか判断する(Ｓ２２１０)。
セッションが存在しないと、パケット伝送モジュールに直接送り、セッションが存在すると、ゲートウェイセッションテーブルのＳｅｓｓと同一にＩＰとポートを変更する(Ｓ２２２０)。
【００４５】
続いて、ＦＩＮまたはＲＳＴフラグセッティングされたか確認し(Ｓ２２３０)、セッティングされていない場合には直ぐパケット伝送モジュールに送り、セッティングされている場合にはゲートウェイセッションを削除した後(Ｓ２２４０)、パケット伝送モジュールに送る。
以上では最も好ましい実施例に上げて本発明の構成およびその作用について説明してきたが、本発明は、前記実施例に限定されなく、後述する特許請求の範囲内で様々な修正および変形が可能なのは当業者にとって明白であろう。
【図面の簡単な説明】
【図１】 基本ネットワーク住所変換技術の概念図。
【図２】 ＩＰヘッダの構成を示す図。
【図３】 ＴＣＰヘッダの構成を示す図。
【図４】 本発明による透過ゲートウェイを適用したネットワーク構成図。
【図５】 変形されたネットワーク住所変換技術の概念図。
【図６】 本発明による一般のゲートウェイとのＴＣＰセッション連結過程の一例を示す流れ図。
【図７】 本発明による透過プロキシに設定されたゲートウェイとのＴＣＰセッション連結過程の例を示す流れ図。
【図８】 本発明による変形されたネットワーク住所変換方法の流れ図。
【図９】 本発明によるネットワーク住所変換方法の他の実施例を説明するための流れ図。
【図１０】 本発明によるネットワーク住所変換方法の他の実施例を説明するための流れ図。
【符号の説明】
１０ クライアント
７０ サーバー
３０ネットワーク装備
４０ ゲートウェイＧ１
５０ ゲートウェイＧ２
６０ 内部ネットワーク
１００ ホストＣ
１２０ ゲートウェイ
Claims (4)
- ネットワーク住所変換テーブルを備えるネットワーク装備を使ってゲートウェイまたはプロキシを含むネットワーク上で透過ゲートウェイまたは透過プロキシを具現する方法において、
受信されたパケットに対して出発地または目的地ポートがネットワーク住所変換テーブルに存在するか否か照会する第１段階；
前記第１段階で出発地または目的地ポートがネットワーク住所変換テーブルに存在する場合、パケットの出発地ＩＰがゲートウェイＩＰと同じであるか否かを照会する第２段階；
パケットの出発地ＩＰがゲートウェイＩＰと同じであるか否かによって、前記第２段階以降のパケットに対して出発地ＩＰまたは目的地ＩＰを変更する第３段階；
を含み、
前記第３段階は、
前記第２段階の結果として、前記パケットの出発地ＩＰがゲートウェイＩＰと同じでない照会結果となった場合、
ＳＹＮフラグが前記パケットにセッティングされた場合、前記セッションを登録する段階；
予め設定されたゲートウェイモードが一般のゲートウェイモードの場合、セッション情報テーブルから前記セッションを照会し、前記セッション照会によって照会された結果があると前記パケットの目的地ＩＰをゲートウェイＩＰに変更する段階；
予め設定されたゲートウェイモードが透過ゲートウェイモードである場合、そのまま前記パケットを伝送する段階
を含むことを特徴とするネットワーク上における透過ゲートウェイまたは透過プロキシ具現方法。 - 前記第３段階において出発地ＩＰがゲートウェイＩＰと同じでない場合、前記セッション照会は、出発地ＩＰ、出発地ポート、目的地ＩＰおよび目的地ポートによって検索することを特徴とする請求項１記載のネットワーク上における透過ゲートウェイまたは透過プロキシ具現方法。
- 前記第３段階は、
前記第２段階の結果として、前記パケットの出発地ＩＰがゲートウェイＩＰと同じ照会結果となった場合、
セッション情報テーブルからセッションを照会する段階；および
前記セッション照会によって照会された結果がある場合、ＦＩＮまたはＲＳＴフラグが前記パケットにセッティングされた場合、セッション情報テーブルからセッションを削除した後、出発地ＩＰをゲートウェイＩＰから実際の出発地ＩＰに変更する段階
を含むことを特徴とする請求項２記載のネットワーク上における透過ゲートウェイまたは透過プロキシ具現方法。 - 前記第３段階において出発地ＩＰがゲートウェイＩＰと同じ場合、前記セッション照会は、目的地ＩＰ、目的地ポート、ゲートウェイＩＰおよび出発地ポートによって検索することを特徴とする請求項３記載のネットワーク上における透過ゲートウェイまたは透過プロキシ具現方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| KR10-2001-0035710A KR100405113B1 (ko) | 2001-06-22 | 2001-06-22 | 네트워크상에서의 투명한 게이트웨이 또는 투명한 프록시구현 방법 |
| PCT/KR2002/000600 WO2003001756A1 (en) | 2001-06-22 | 2002-04-04 | Method for implementing transparent gateway or proxy in a network |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2004522368A JP2004522368A (ja) | 2004-07-22 |
| JP2004522368A5 JP2004522368A5 (ja) | 2005-06-23 |
| JP3805771B2 true JP3805771B2 (ja) | 2006-08-09 |
Family
ID=19711225
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2003508029A Expired - Fee Related JP3805771B2 (ja) | 2001-06-22 | 2002-04-04 | ネットワーク上における透過ゲートウェイまたは透過プロキシ具現方法 |
Country Status (5)
| Country | Link |
|---|---|
| US (2) | US20050015510A1 (ja) |
| JP (1) | JP3805771B2 (ja) |
| KR (1) | KR100405113B1 (ja) |
| CN (1) | CN1217516C (ja) |
| WO (1) | WO2003001756A1 (ja) |
Families Citing this family (29)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN100440886C (zh) | 2003-09-02 | 2008-12-03 | 华为技术有限公司 | 多媒体协议穿越网络地址转换设备的实现方法 |
| CN101262502B (zh) * | 2003-09-02 | 2011-09-14 | 华为技术有限公司 | 多媒体协议穿越网络地址转换设备的实现方法 |
| US20050060410A1 (en) * | 2003-09-11 | 2005-03-17 | Nokia Corporation | System and method for proxy-based redirection of resource requests |
| CN1317874C (zh) * | 2003-09-27 | 2007-05-23 | 财团法人资讯工业策进会 | 提供虚拟主机服务快速查询置换的网络地址端口转换网关器与方法 |
| KR100563825B1 (ko) * | 2003-10-28 | 2006-03-24 | 주식회사 엑스큐어넷 | 컨텐츠 분석이 가능한 고성능의 프럭시 서버 및 이를이용한 패킷 처리 방법 |
| JP4533247B2 (ja) * | 2004-06-08 | 2010-09-01 | キヤノン株式会社 | サービス提供システム、サービス提供方法及びサービス提供装置 |
| JP4392029B2 (ja) * | 2004-11-11 | 2009-12-24 | 三菱電機株式会社 | 通信ネットワークにおけるｉｐパケット中継方法 |
| KR100666005B1 (ko) * | 2006-01-24 | 2007-01-09 | 양영수 | 방사선 경화 도전성 잉크와 이를 이용한 제조 방법 |
| US8447802B2 (en) * | 2006-03-08 | 2013-05-21 | Riverbed Technology, Inc. | Address manipulation to provide for the use of network tools even when transaction acceleration is in use over a network |
| US8004973B2 (en) * | 2006-04-25 | 2011-08-23 | Citrix Systems, Inc. | Virtual inline configuration for a network device |
| CN100531158C (zh) * | 2006-06-29 | 2009-08-19 | 华为技术有限公司 | 一种无线接入网关支持透明代理的系统及方法 |
| CN100525251C (zh) * | 2006-11-30 | 2009-08-05 | 中国科学院计算技术研究所 | 一种网络地址转换方法 |
| EP2149093A4 (en) * | 2007-04-17 | 2010-05-05 | Kenneth Tola | METHODS AND DISCRETE SYSTEMS FOR COLLECTING INFORMATION TRANSMITTED OVER A NETWORK |
| US8549157B2 (en) * | 2007-04-23 | 2013-10-01 | Mcafee, Inc. | Transparent secure socket layer |
| KR100891713B1 (ko) * | 2007-05-14 | 2009-04-03 | (주)이지서티 | Ｉｐ 주소 투명화를 위한 게이트웨이 및 방법과 컴퓨터프로그램 기록매체 |
| KR100898371B1 (ko) * | 2007-06-18 | 2009-05-18 | (주)모니터랩 | 투명 프록시 시스템 및 그의 패킷 처리 방법 |
| CN101605153B (zh) * | 2008-06-13 | 2013-10-09 | 中怡(苏州)科技有限公司 | 利用路由装置进行地址协议解析的方法 |
| US9002923B2 (en) | 2008-07-01 | 2015-04-07 | Thomson Licensing | Transparent web proxy |
| US8874693B2 (en) * | 2009-02-20 | 2014-10-28 | Microsoft Corporation | Service access using a service address |
| CN102006337B (zh) * | 2010-11-23 | 2013-12-18 | 华为技术有限公司 | 一种基于cgn实体的数据传输方法、cgn实体、网关及系统 |
| JP5750352B2 (ja) * | 2011-10-04 | 2015-07-22 | 株式会社Ｉｎｔｏ | ネットワークゲートウェイ装置 |
| CN106357590A (zh) * | 2015-07-15 | 2017-01-25 | 艾默生网络能源系统北美公司 | 一种网络协议转换系统、网络协议转换器及其转换方法 |
| CN107483593B (zh) * | 2017-08-22 | 2019-12-31 | 网宿科技股份有限公司 | 双向透明代理方法及系统 |
| US11194930B2 (en) | 2018-04-27 | 2021-12-07 | Datatrendz, Llc | Unobtrusive systems and methods for collecting, processing and securing information transmitted over a network |
| CN108833418B (zh) * | 2018-06-22 | 2021-05-25 | 京东数字科技控股有限公司 | 用于防御攻击的方法、装置和系统 |
| KR102090138B1 (ko) * | 2018-12-21 | 2020-03-17 | (주)모니터랩 | 세션 관리 방법 및 이를 이용한 보안중계장치 |
| KR102085331B1 (ko) * | 2019-01-07 | 2020-03-05 | 주식회사 엑스게이트 | 네트워크 이중화 환경에서 투명 프록시를 이용한 패킷 처리 방법 및 패킷 처리 시스템 |
| CN109587275A (zh) * | 2019-01-08 | 2019-04-05 | 网宿科技股份有限公司 | 一种通信连接的建立方法及代理服务器 |
| CN109921948B (zh) * | 2019-03-27 | 2022-07-29 | 新华三技术有限公司 | 数据平面的故障检测方法、装置及网关设备 |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4677588A (en) * | 1983-11-14 | 1987-06-30 | International Business Machines Corp. | Network interconnection without integration |
| US5493607A (en) * | 1992-04-21 | 1996-02-20 | Boston Technology | Multi-system network addressing |
| US5781550A (en) * | 1996-02-02 | 1998-07-14 | Digital Equipment Corporation | Transparent and secure network gateway |
| US5856974A (en) * | 1996-02-13 | 1999-01-05 | Novell, Inc. | Internetwork address mapping gateway |
| US6473406B1 (en) * | 1997-07-31 | 2002-10-29 | Cisco Technology, Inc. | Method and apparatus for transparently proxying a connection |
| US6389462B1 (en) * | 1998-12-16 | 2002-05-14 | Lucent Technologies Inc. | Method and apparatus for transparently directing requests for web objects to proxy caches |
| US6381638B1 (en) * | 1999-02-24 | 2002-04-30 | 3Com Corporation | System and method for options based address reuse |
| KR100336998B1 (ko) * | 1999-08-02 | 2002-05-30 | 전우직 | 발신지 주소에 의한 네트워크 주소 변환 방법 |
| KR100301026B1 (ko) * | 1999-08-20 | 2001-11-01 | 윤종용 | 망주소 변환 테이블을 사용한 사설망과 공용망의 망연동 방법 및 이를 위한 기록 매체 |
| KR100333530B1 (ko) * | 1999-09-29 | 2002-04-25 | 최명렬 | 네트워크 주소 변환(ｎａｔ) 기능을 이용한 가상 사설망(ｖｐｎ) 구성 방법 및 이를 실현시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 기록 매체 |
| CN1141657C (zh) * | 1999-12-29 | 2004-03-10 | 西安交通大学 | 基于透明网络地址翻译的防火墙代理网关 |
| US6754709B1 (en) * | 2000-03-29 | 2004-06-22 | Microsoft Corporation | Application programming interface and generalized network address translator for intelligent transparent application gateway processes |
| KR100438236B1 (ko) * | 2000-12-28 | 2004-07-02 | 엘지전자 주식회사 | 브이오아이피 게이트웨이에서 네트워크 주소 변환 서버를통한 음성 패킷 전달 방법 |
| US20020152307A1 (en) * | 2001-04-12 | 2002-10-17 | Doyle Ronald Patrick | Methods, systems and computer program products for distribution of requests based on application layer information |
| US7272650B2 (en) * | 2001-04-17 | 2007-09-18 | Intel Corporation | Communication protocols operable through network address translation (NAT) type devices |
| TW588532B (en) * | 2002-03-29 | 2004-05-21 | Realtek Semiconductor Corp | Management device and method of NAT/NAPT session |
| ATE353522T1 (de) * | 2003-12-23 | 2007-02-15 | Cit Alcatel | Verfahren zur ausführung einer symmetrischen adressenumsetzung |
-
2001
- 2001-06-22 KR KR10-2001-0035710A patent/KR100405113B1/ko active IP Right Grant
-
2002
- 2002-04-04 US US10/362,650 patent/US20050015510A1/en not_active Abandoned
- 2002-04-04 JP JP2003508029A patent/JP3805771B2/ja not_active Expired - Fee Related
- 2002-04-04 CN CN028008014A patent/CN1217516C/zh not_active Expired - Fee Related
- 2002-04-04 WO PCT/KR2002/000600 patent/WO2003001756A1/en active Application Filing
-
2007
- 2007-08-14 US US11/838,667 patent/US20080133774A1/en not_active Abandoned
Also Published As
| Publication number | Publication date |
|---|---|
| CN1460347A (zh) | 2003-12-03 |
| CN1217516C (zh) | 2005-08-31 |
| US20050015510A1 (en) | 2005-01-20 |
| JP2004522368A (ja) | 2004-07-22 |
| KR20030000080A (ko) | 2003-01-06 |
| WO2003001756A1 (en) | 2003-01-03 |
| KR100405113B1 (ko) | 2003-11-10 |
| US20080133774A1 (en) | 2008-06-05 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3805771B2 (ja) | ネットワーク上における透過ゲートウェイまたは透過プロキシ具現方法 | |
| US8468259B2 (en) | Middlebox control | |
| US6157950A (en) | Methods and apparatus for interfacing a computer or small network to a wide area network such as the internet | |
| US7894432B2 (en) | Apparatus and method creating virtual routing domains in an internet protocol network | |
| US9288187B2 (en) | Externally controlled reachability in virtual private networks | |
| KR100454502B1 (ko) | 아이피 라우터에서 ＶｏＩＰ 트래픽에 대한 ＱｏＳ를제공하는 장치 및 포워딩방법 | |
| US7574522B2 (en) | Communication data relay system | |
| US7630368B2 (en) | Virtual network interface card loopback fastpath | |
| US8094660B2 (en) | VLAN server | |
| US7782902B2 (en) | Apparatus and method for mapping overlapping internet protocol addresses in layer two tunneling protocols | |
| US20050213591A1 (en) | Router and sip server | |
| US20040158606A1 (en) | Transmission method of multimedia data over a network | |
| KR20000010612A (ko) | 인터넷 프로토콜 필터 | |
| WO2013069161A1 (ja) | ルーティング方法およびネットワーク伝送装置 | |
| US20080279178A1 (en) | Port reduction for voice over internet protocol router | |
| EP1633084B1 (en) | Method for selecting services provided by different network service providers | |
| US8103790B2 (en) | Apparatus and method for supporting multiple traffic categories at a single networked device | |
| JP6007644B2 (ja) | 通信装置、プログラムおよびルーティング方法 | |
| EP1777915A1 (en) | An method and apparatus for implementing the signaling proxy | |
| US6577627B1 (en) | Service selection on IP access networks | |
| KR100519166B1 (ko) | 에이티엠 엠피엘에스 브이피엔 망에서의 반향 요청 방법 | |
| JP7178522B2 (ja) | 中継装置及びローカルブレイクアウトの転送方法 | |
| KR20070108772A (ko) | Ｓｉｐ서버 및 이를 이용한 ｓｉｐ기반의 통신 방법 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20051114 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20051122 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060213 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060411 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060510 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100519 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110519 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120519 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130519 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140519 Year of fee payment: 8 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |