RFC1919 日本語訳
1919 Classical versus Transparent IP Proxies. M. Chatel. March 1996. (Format: TXT=87374 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group M. Chatel Request for Comments: 1919 Consultant Category: Informational March 1996
コメントを求めるワーキンググループM.シャテルの要求をネットワークでつないでください: 1919年のコンサルタントカテゴリ: 情報の1996年3月
Classical versus Transparent IP Proxies
透明なIPプロキシに対して古典的です。
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
Many modern IP security systems (also called "firewalls" in the trade) make use of proxy technology to achieve access control. This document explains "classical" and "transparent" proxy techniques and attempts to provide rules to help determine when each proxy system may be used without causing problems.
多くの現代のIPセキュリティシステム(また、業界で「ファイアウォール」と呼ばれる)がアクセスコントロールを達成するプロキシ技術を利用します。 このドキュメントは、「古典的で」「透明な」プロキシのテクニックについて説明して、それぞれのプロキシシステムがいつ問題を起こさないで使用されるかもしれないかを決定するのを助けるために規則を提供するのを試みます。
Table of Contents
目次
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Direct communication (without a proxy) . . . . . . . . . . . 3 2.1. Direct connection example . . . . . . . . . . . . . . . . 3 2.2. Requirements of direct communication . . . . . . . . . . . 5 3. Classical application proxies . . . . . . . . . . . . . . 5 3.1. Classical proxy session example . . . . . . . . . . . . . 6 3.2. Characteristics of classical proxy configurations . . . 12 3.2.1. IP addressing and routing requirements . . . . . . . . 12 3.2.2. IP address hiding . . . . . . . . . . . . . . . . . . 14 3.2.3. DNS requirements . . . . . . . . . . . . . . . . . . . 14 3.2.4. Software requirements . . . . . . . . . . . . . . . . 15 3.2.5. Impact of a classical proxy on packet filtering . . . 15 3.2.6. Interconnection of conflicting IP networks . . . . . . 16 4. Transparent application proxies . . . . . . . . . . . . . 19 4.1. Transparent proxy connection example . . . . . . . . . . 20 4.2. Characteristics of transparent proxy configurations . . 26 4.2.1. IP addressing and routing requirements . . . . . . . . 26 4.2.2. IP address hiding . . . . . . . . . . . . . . . . . . 28 4.2.3. DNS requirements . . . . . . . . . . . . . . . . . . . 28 4.2.4. Software requirements . . . . . . . . . . . . . . . . 29 4.2.5. Impact of a transparent proxy on packet filtering . . 30 4.2.6. Interconnection of conflicting IP networks . . . . . . 31 5. Comparison chart of classical and transparent proxies . . 31 6. Improving transparent proxies . . . . . . . . . . . . . . 32 7. Security Considerations . . . . . . . . . . . . . . . . . 34
1. バックグラウンド. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 コミュニケーション(プロキシのない).32.1を指示してください。 接続例. . . . . . . . . . . . . . . . 3 2.2を指示してください。 ダイレクトコミュニケーション. . . . . . . . . . . 5 3の要件。 古典的なアプリケーションプロキシ. . . . . . . . . . . . . . 5 3.1。 古典的なプロキシセッション例. . . . . . . . . . . . . 6 3.2。 古典的なプロキシ構成. . . 12 3.2.1の特性。 IPアドレシングとルーティング要件. . . . . . . . 12 3.2.2。 IPアドレス隠れること. . . . . . . . . . . . . . . . . . 14 3.2.3。 DNS要件. . . . . . . . . . . . . . . . . . . 14 3.2.4。 ソフトウェア要件. . . . . . . . . . . . . . . . 15 3.2.5。 パケットフィルタリング. . . 15 3.2.6の古典的なプロキシの影響。 闘争IPのインタコネクトは.164をネットワークでつなぎます。 透明なアプリケーションプロキシ. . . . . . . . . . . . . 19 4.1。 見え透いたプロキシ接続例. . . . . . . . . . 20 4.2。 透明なプロキシ構成. . 26 4.2.1の特性。 IPアドレシングとルーティング要件. . . . . . . . 26 4.2.2。 IPアドレス隠れること. . . . . . . . . . . . . . . . . . 28 4.2.3。 DNS要件. . . . . . . . . . . . . . . . . . . 28 4.2.4。 ソフトウェア要件. . . . . . . . . . . . . . . . 29 4.2.5。 パケットフィルタリング. . 30 4.2.6の透明なプロキシの影響。 闘争IPのインタコネクトは.315をネットワークでつなぎます。 古典的で透明なプロキシ. . 31 6の比較チャート。 透明なプロキシ. . . . . . . . . . . . . . 32 7を改良します。 セキュリティ問題. . . . . . . . . . . . . . . . . 34
Chatel Informational [Page 1] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[1ページ]のRFC1919
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 34 9. References . . . . . . . . . . . . . . . . . . . . . . . . 35
8. 承認. . . . . . . . . . . . . . . . . . . . . 34 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . 35
1. Background
1. バックグラウンド
An increasing number of organizations use IP security systems to provide specific access control when crossing network security perimeters. These systems are often deployed at the network boundary between two organizations (which may be part of the same "official" entity), or between an organization's network and a large public internetwork such as the Internet.
増加する数の組織が、ネットワークセキュリティ周辺を越えるとき、特定のアクセスコントロールを提供するのにIPセキュリティシステムを使用します。 これらのシステムは組織のネットワークと、そして、インターネットなどの2つの組織(同じ「公式」の実体の一部であるかもしれない)か、大きい公共のインターネットワークの間のネットワーク限界でしばしば配布されます。
Some people believe that IP firewalls will become commodity products. Others believe that the introduction of IPv6 and of its improved security capabilities will gradually make firewalls look like stopgap solutions, and therefore irrelevant to the computer networking scene. In any case, it is currently important to examine the impact of inserting (and removing) a firewall at a network boundary, and to verify whether specific types of firewall technologies may have different effects on typical small and large IP networks.
人々の中にはIPファイアウォールが商品生産物になると信じている人もいます。 他のものは、ファイアウォールにIPv6とその改良されたセキュリティ能力の導入で徐々に間に合せのソリューションで、したがって、コンピュータのネットワーク化場面と無関係の状態で似ると信じています。 どのような場合でも、ネットワーク限界でファイアウォールを挿入する(そして、取り外します)影響を調べて、特定のタイプのファイアウォール技術が典型的な大小IPネットワークに異なった影響を与えるかもしれないかどうか確かめるのは現在、重要です。
Current firewall designs usually rely on packet filtering, proxy technology, or a combination of both. Packet filtering (although hard to configure correctly in a security sense) is now a well documented technology whose strengths and weaknesses are reasonably understood. Proxy technology, on the other hand, has been deployed a lot but studied little. Furthermore, many recent firewall products support a capability called "transparent proxying". This type of feature has been subject to much more marketing attention than actual technical analysis by the networking community.
通常、現在のファイアウォールデザインは両方のパケットフィルタリング、プロキシ技術、または組み合わせに依存します。 現在、パケットフィルタリング(セキュリティ意味で正しく構成しにくいのですが)は長所と短所が合理的に理解されているよく記録された技術です。 他方では、プロキシ技術は、大いに配布されますが、少ししか研究されていません。 その上、多くの最近のファイアウォール製品が「透明なproxying」と呼ばれる能力をサポートします。 このタイプの特徴はネットワーク共同体のそばで実際のテクニカル分析よりはるかに多くのマーケティング注意を受けることがあります。
It must be remembered that the Internet's growth and success is strongly related to its "open" nature. An Internet which would have been segmented from the start with firewalls, packet filters, and proxies may not have become what it is today. This type of discussion is, however, outside the scope of this document, which just attempts to provide an understandable description of what are network proxies, and of what are the differences, strengths, and weaknesses of "classical" and "transparent" network proxies. Within the context of this document, a "classical" proxy is the older (some would say old- fashioned) type of proxy of the two.
インターネットの成長と成功が強く「開いている」本質に関連したのを覚えていなければなりません。 ファイアウォール、パケットフィルタ、およびプロキシと共に始めから区分されたインターネットは今日それが何であるかということになっていないかもしれません。 このタイプの議論がそうであり、しかしながら、「古典的で」「透明な」ネットワークプロキシの違い、長所、および短所は、ネットワークプロキシであり、何に関する理解できる記述を提供するかをただ試みるこのドキュメントの範囲の外では、ことのものです。 このドキュメントの文脈の中では、「古典的な」プロキシは(作成されて、或るものは古い状態で言うでしょう)より年取ったタイプの2つのもののプロキシです。
Also note that in this document, the word "connection" is used for an application session that uses TCP, while the word "session" refers to an application dialog that may use UDP or TCP.
また、本書では、「接続」という言葉がTCPを使用するアプリケーションセッションに使用されることに注意してください、「セッション」という言葉はUDPかTCPを使用するかもしれないアプリケーション対話を示しますが。
Chatel Informational [Page 2] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[2ページ]のRFC1919
2. Direct communication (without a proxy)
2. ダイレクトコミュニケーション(プロキシのない)
In the "normal" Internet world, systems do not use proxies and simply use normal TCP/IP to communicate with each other. It is important (for readers who may not be familiar with this) to take a quick look at the operations involved, in order to better understand what is the exact use of a proxy.
「正常な」インターネットの世界では、システムは、プロキシを使用して、互いにコミュニケートするのに正常なTCP/IPは絶対に使用しません。 何がプロキシの正確な使用であるかを理解するほうがよいためにかかわる操作をチラッと見るのは重要です(これに詳しくないかもしれない読者のための)。
2.1 Direct connection example
2.1 ダイレクト接続の例
Let's take a familiar network session and describe some details of
its operation. We will look at what happens when a user on a
client system "c.dmn1.com" sets up an FTP connection to the server
system "s.dmn2.com". The client system's IP address is
c1.c2.c3.c4, the server's IP address is s1.s2.s3.s4.
身近なネットワークセッションを取って、操作のいくつかの詳細について説明しましょう。 私たちはサーバシステム「s.dmn2.com」において「c.dmn1.com」がFTP接続に設定するクライアントシステムの上のユーザであるときに、何が起こるか見るつもりです。 クライアントシステムのIPアドレスがc1.c2.c3.c4である、サーバのIPアドレスはs1.s2.s3.s4です。
+---------------+ +----------+ +---------------+
| | / IP \ | |
| c.dmn1.com |----+ network(s) +----| s.dmn2.com |
| (c1.c2.c3.c4) | \ / | (s1.s2.s3.s4) |
+---------------+ +----------+ +---------------+
+---------------+ +----------+ +---------------+ | | /IP\| | | c. dmn1.com|----+ ネットワーク+----| s. dmn2.com| | (c1.c2.c3.c4) | \ / | (s1.s2.s3.s4) | +---------------+ +----------+ +---------------+
The user starts an instance of an FTP client program on the client
system "c.dmn1.com", and specifies that the target system is
"s.dmn2.com". On command-line systems, the user typically types:
ユーザは、クライアントシステム「c.dmn1.com」にFTPクライアントプログラムのインスタンスを始めて、目標システムが「s.dmn2.com」であると指定します。 コマンドラインシステムで、ユーザは通常タイプします:
ftp s.dmn2.com
ftp s.dmn2.com
The client system needs to convert the server's name to an IP
address (if the user directly specified the server by address,
this step is not needed).
クライアントシステムは、サーバの名前をIPアドレスに変換する必要があります(ユーザがアドレスで直接サーバを指定したなら、このステップは必要ではありません)。
Converting the server name to an IP address requires work to be
performed which ranges between two extremes:
実行されるために働くIPアドレスが、必要である2つの極端の間で及ぶサーバー名を変換します:
a) the client system has this name in its hosts file, or has
local DNS caching capability and successfully retrieves the
name of the server system in its cache. No network activity
is performed to convert the name to an IP address.
a) クライアントシステムは、ホストのこの名前をファイルさせるか、地方のDNSに能力をキャッシュさせて、またはキャッシュでサーバシステムの名前を首尾よく検索します。 ネットワーク活動は、全くIPアドレスに名前を変換するために実行されません。
b) the client system, in combination with DNS name servers,
generate DNS queries that eventually propagate close to the
root of the DNS tree and back down the server's DNS branch.
Eventually, a DNS server which is authoritative for the
server system's domain is queried and returns the IP
address associated with "s.dmn2.com" (depending on the case,
it may return this to the client system directly or to an
b) DNSネームサーバと組み合わせて、クライアントシステムは、DNSが結局DNS木と逆下の根の近くでサーバのDNSブランチを伝播する質問であると生成します。 またはサーバシステムのドメインに、正式のDNSサーバが結局質問されて、「s.dmn2.com」に関連しているIPアドレスを返す、(ケースによって、直接クライアントシステムにこれを返すかもしれない。
Chatel Informational [Page 3] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[3ページ]のRFC1919
intermediate name server). Ultimately, the client system
obtains a valid IP address for s.dmn2.com. For simplicity,
we assume the server has only one IP address.
中間的ネームサーバ) 結局、クライアントシステムはs.dmn2.comに、有効なIPアドレスを得ます。 簡単さのために、私たちは、サーバには1つのIPアドレスしかないと思います。
+---------------+ +--------+ +---------------+
| | / IP \ | |
| c.dmn1.com |---+ network(s) +---| s.dmn2.com |
| (c1.c2.c3.c4) | \ / | (s1.s2.s3.s4) |
+---------------+ +--------+ +---------------+
A | / \
| | address for / \
| | s.dmn2.com? / \
| | / \
| | / \
| | +--------+ s.dmn2.com? +--------+
| +---->| DNS |------------->| DNS |
| | server | | server |
+--------| X |<-------------| Y |
s1.s2.s3.s4 +--------+ s1.s2.s3.s4 +--------+
+---------------+ +--------+ +---------------+ | | /IP\| | | c. dmn1.com|---+ ネットワーク+---| s. dmn2.com| | (c1.c2.c3.c4) | \ / | (s1.s2.s3.s4) | +---------------+ +--------+ +---------------+ A| / \ | | /には、\を扱ってください。| | s. dmn2.com? / \ | | / \ | | / \ | | +--------+ s.dmn2.com? +--------+ | +---->| DNS|、-、-、-、-、-、-、-、-、-、-、-、--、>| DNS| | | サーバ| | サーバ| +--------| X| <、-、-、-、-、-、-、-、-、-、-、-、--、| Y| s1.s2.s3.s4+--------+ s1.s2.s3.s4+--------+
Once the client system knows the IP address of the server system,
it attempts to establish a connection to the standard FTP
"control" TCP port on the server (port 21). For this to work, the
client system must have a valid route to the server's IP address,
and the server system must have a valid route to the client's IP
address. All intermediate devices that behave like IP gateways
must have valid routes for both the client and the server. If
these devices perform packet filtering, they must ALL allow the
specific type of traffic required between C and S for this
specific application.
クライアントシステムがいったんサーバシステムのIPアドレスを知っていると、それは、「コントロール」TCPがサーバで移植する標準のFTPに取引関係を築くのを試みます(21を移植してください)。 これが働くように、クライアントシステムはサーバのIPアドレスに有効なルートを持たなければなりません、そして、サーバシステムはクライアントのIPアドレスに有効なルートを持たなければなりません。 IPゲートウェイのように反応するすべての中間的デバイスがクライアントとサーバの両方のための有効なルートを持たなければなりません。これらのデバイスがパケットフィルタリングを実行するなら、それらはこの特定のアプリケーションのためのCとSの間で必要であるトラフィックの特定のタイプをすべて許容しなければなりません。
+---------------+ +---------------+
| c.dmn1.com | | s.dmn2.com |
| (c1.c2.c3.c4) | | (s1.s2.s3.s4) |
+---------------+ +---------------+
| | | |
| | route to S route to C | |
| V V |
| |
| A | A
| | route to C | | route to S
| | | |
| | C S C | |
+----+ <-- +----+ --> +----+ <-- +----+
| G1 |--------| Gx |--------| Gy |---------| Gn |
+----+ --> +----+ <-- +----+ --> +----+
S C S
+---------------+ +---------------+ | c. dmn1.com| | s. dmn2.com| | (c1.c2.c3.c4) | | (s1.s2.s3.s4) | +---------------+ +---------------+ | | | | | | CへのSルートへのルート| | | V V| | | | A| A| | Cへのルート| | Sへのルート| | | | | | C S C| | +----+<--+----+-->+----+<--+----+ | G1|--------| Gx|--------| Gy|---------| Gn| +----+-->+----+<--+----+-->+----+ S C S
Chatel Informational [Page 4] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[4ページ]のRFC1919
The actual application work for the FTP session between the client
and server is done with a bidirectional flow of TCP packets
between the client's and server's IP addresses.
クライアントとサーバとのFTPセッションのための仕事がクライアントとサーバのIPアドレスの間のTCPパケットの双方向の流れで行われる本番適用。
The FTP protocol uses a slightly complex protocol and TCP
connection model which is, luckily, not important to the present
discussion. This allows slightly shortening this document...
FTPプロトコルは現在の議論に運よく重要でないわずかに複雑なプロトコルとTCP接続モデルを使用します。 これで、このドキュメントをわずかに短くします…
2.2 Requirements of direct communication
2.2 ダイレクトコミュニケーションの要件
Based on the preceding discussion, it is possible to say that the
following is required for a direct session between a client and
server to be successful:
前の議論に基づいて、以下がクライアントとサーバとのダイレクトセッションがうまくいっているのに必要であると言うのは可能です:
a) If the client uses the NAME of the server to reference it,
the client must either have a hardcoded name-to-address
binding for the server, or it must be able to resolve the
server name (typically using DNS). In the case of DNS, this
implies that the client and server must be part of the same
DNS architecture or tree.
a) クライアントがそれに参照をつけるのにサーバのNAMEを使用するなら、クライアントにはhardcodedサーバのための名前からアドレス結合がなければならない、さもなければ、それはサーバー名を決議できなければなりません(DNSを通常使用して)。 DNSの場合では、これは、クライアントとサーバが同じDNSアーキテクチャか木の一部であるに違いないことを含意します。
b) The client and server must be part of the same internetwork:
the client must have a valid IP route towards the server,
the server must have a valid IP route towards the client,
and all intermediate IP gateways must have valid routes
towards the client and server ("IP gateway" is the RFC
standard terminology; people often use the term "IP router"
in computer rooms).
b) クライアントとサーバは同じインターネットワークの一部であるに違いありません: クライアントは有効なIPルートをサーバに向かって持たなければなりません、そして、サーバは有効なIPルートをクライアントに向かって持たなければなりません、そして、すべての中間的IPゲートウェイがクライアントとサーバに向かって有効なルートを持たなければなりません。(「IPゲートウェイ」はRFCの標準の用語です。 人々がコンピュータ部屋でしばしば「IPルータ」という用語を使用する、)
c) If there are devices on the path between the client and
server that perform packet filtering, all these devices must
permit the forwarding of packets between the IP address of
the client and the IP address of the server, at least for
packets that fit the protocol model of the FTP application
(TCP ports used, etc.).
c) デバイスがパケットフィルタリングを実行するクライアントとサーバの間の経路にあれば、これらのすべてのデバイスがクライアントのIPアドレスとサーバのIPアドレスの間のパケットの推進を可能にしなければなりません、少なくともFTPアプリケーション(使用されるTCPポートなど)のプロトコルモデルに合うパケットのために。
3. Classical application proxies
3. 古典的なアプリケーションプロキシ
A classical application proxy is a special program that knows one (or more) specific application protocols. Most application protocols are not symetric; one end is considered to be a "client", one end is a "server".
古典的なアプリケーションプロキシは1つ(さらに)の特定のアプリケーション・プロトコルを知っている特別なプログラムです。 ほとんどのアプリケーション・プロトコルはsymetricではありません。 片端は「クライアント」、片端が「サーバ」であるということであると考えられます。
A classical application proxy implements both the "client" and "server" parts of an application protocol. In practice, it only needs to implement enough of the client and server protocols to accomplish the following:
古典的なアプリケーションプロキシは、両方がアプリケーション・プロトコルの「クライアント」と「サーバ」部分であると実装します。 実際には、クライアントとサーバプロトコルが以下を達成する十分を実装するのが必要であるだけです:
Chatel Informational [Page 5] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[5ページ]のRFC1919
a) accept client sessions and appear to them as a server;
a)はクライアントセッションを認めて、サーバとしてそれらにおいて現れます。
b) receive from a client the name or address of the final target
server (this needs to be passed over the "client-proxy" session
in a way that is application-specific);
b) クライアントから、最終的な目標サーバの名前かアドレスを受け取ってください(これは、「クライアントプロキシ」セッションの間、アプリケーション特有の方法で通過される必要があります)。
c) setup a session to the final server and appear to be a client
from the server's point of view;
c)は、最終的なサーバにセッションをセットアップして、サーバの観点からのクライアントであるように見えます。
d) relay requests, responses, and data between the client and
server;
d) クライアントとサーバの間の要求、応答、およびデータをリレーしてください。
e) perform access controls according to the proxy's design
criteria (the main goal of the proxy, after all).
e) プロキシの設計基準(結局プロキシの第一目的)に従って、アクセス制御を実行してください。
The functional goal of the proxy is to relay application data between clients and servers that may not have direct IP connectivity. The security goal of the proxy is to do checks and types of access controls that typical client and server software do not support or implement.
プロキシの機能的な目標はダイレクトIPの接続性を持っていないかもしれないクライアントとサーバの間のアプリケーションデータをリレーすることです。 プロキシのセキュリティ目標は典型的なクライアントとサーバソフトウェアがサポートもしませんし、実装もしないアクセス制御のチェックとタイプをすることです。
The following information will make it clear that classical proxies can offer many hidden benefits to the security-conscious network designer, at the cost of deploying client software with proxy capabilities or of educating the users on proxy use.
以下の情報は、古典的なプロキシが安全志向のネットワーク設計者への多くの隠された利益を提供できると断言するでしょう、プロキシ使用のときにプロキシ能力か教育のクライアントソフトウェアにユーザを配布する費用で。
Client software issues are now easier to handle, given the increasing number of popular client applications (for Web, FTP, etc.) that offer proxy support. Designers developing new protocols are also more likely to plan proxy capability from the outset, to ensure their protocols can cross the many existing large corporate firewalls that are based at least in part on classical proxy technology.
クライアントソフトウェア問題は現在より扱いやすいです、サポートをプロキシに提供するポピュラーなクライアントアプリケーション(ウェブ、FTPなどのための)の増加する数を考えて。 それらのプロトコルが古典的なプロキシ技術に少なくとも一部基づいている多くの既存の大きい法人のファイアウォールを越えることができるのを保証するために、おそらく着手からのプランプロキシ能力には新しいプロトコルを開発するデザイナーがいます。
3.1 Classical proxy session example
3.1 古典的なプロキシセッションの例
We will repeat our little analysis of an FTP session. This time,
the FTP session is passing through a "classical" application proxy
system. As is often the case (although not required), we will
assume that the proxy system has two IP addresses, two network
interfaces, and two DNS names.
私たちは私たちのFTPセッションの少ない分析を繰り返して言うでしょう。 今回、FTPセッションは「古典的な」アプリケーションプロキシシステムを通り抜けています。 よくあるように(必要ではありませんが)、私たちは、プロキシシステムには2つのIPアドレス、2つのネットワーク・インターフェース、および2つのDNS名があると思うつもりです。
The proxy system is running a special program which knows how to
behave like an FTP client on one side, and like an FTP server on
the other side. This program is what people call the "proxy". We
will assume that the proxy program is listening to incoming
requests on the standard FTP control port (21/tcp), although this
is not always the case in practice.
プロキシシステムは半面の上のFTPクライアント、および反対側の上のFTPサーバのように振る舞う方法を知っている特別なプログラムを動かしています。 このプログラムは人々が「プロキシ」と呼ぶものです。 私たちは、プロキシプログラムが標準のFTP制御ポート(21/tcp)に関する入って来る要求を聞いていると思うつもりです、これは実際にはいつもそうであるというわけではありませんが。
Chatel Informational [Page 6] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[6ページ]のRFC1919
+---------------+ +----------+
| | / IP \
| c.dmn1.com |----+ network(s) +----------+
| (c1.c2.c3.c4) | \ / |
+---------------+ +----------+ +-----------------+
| (p1.p2.p3.p4) |
| proxy1.dmn3.com |
| |
| proxy2.dmn4.com |
| (p5.p6.p7.p8) |
+---------------+ +----------+ +-----------------+
| | / IP \ |
| s.dmn2.com |----+ network(s) +----------+
| (s1.s2.s3.s4) | \ /
+---------------+ +----------+
+---------------+ +----------+ | | /IP\| c. dmn1.com|----+ ネットワーク+----------+ | (c1.c2.c3.c4) | \ / | +---------------+ +----------+ +-----------------+ | (p1.p2.p3.p4) | | proxy1.dmn3.com| | | | proxy2.dmn4.com| | (p5.p6.p7.p8) | +---------------+ +----------+ +-----------------+ | | /IP\| | s. dmn2.com|----+ ネットワーク+----------+ | (s1.s2.s3.s4) | \ / +---------------+ +----------+
The user starts an instance of an FTP client program on the client
system "c.dmn1.com", and MUST specify that the target system is
"proxy1.dmn3.com". On command-line systems, the user typically
types:
ユーザは、クライアントシステム「c.dmn1.com」にFTPクライアントプログラムのインスタンスを始めて、目標システムが"proxy1.dmn3.com"であると指定しなければなりません。 コマンドラインシステムで、ユーザは通常タイプします:
ftp proxy1.dmn3.com
ftp proxy1.dmn3.com
The client system needs to convert the proxy's name to an IP
address (if the user directly specified the proxy by address, this
step is not needed).
クライアントシステムは、プロキシの名前をIPアドレスに変換する必要があります(ユーザがアドレスで直接プロキシを指定したなら、このステップは必要ではありません)。
Converting the proxy name to an IP address requires work to be
performed which ranges between two extremes:
プロキシ名をIPアドレスに変換するのは、仕事をするのを必要とします(2つの極端の間で及びます):
a) the client system has this name in its hosts file, or has
local DNS caching capability and successfully retrieves the
name of the proxy system in its cache. No network activity
is performed to convert the name to an IP address.
a) クライアントシステムは、ホストのこの名前をファイルさせるか、地方のDNSに能力をキャッシュさせて、またはキャッシュでプロキシシステムの名前を首尾よく検索します。 ネットワーク活動は、全くIPアドレスに名前を変換するために実行されません。
b) the client system, in combination with DNS name servers,
generate DNS queries that eventually propagate close to the
root of the DNS tree and back down the proxy's DNS branch.
Eventually, a DNS server which is authoritative for the
proxy system's domain is queried and returns the IP
address associated with "proxy1.dmn3.com" (depending on the
case, it may return this to the client system directly or
to an intermediate name server). Ultimately, the client
system obtains a valid IP address for proxy1.dmn3.com.
b) DNSネームサーバと組み合わせて、クライアントシステムは、DNSが結局DNS木と逆下の根の近くでプロキシのDNSブランチを伝播する質問であると生成します。 結局、プロキシシステムのドメインに、正式のDNSサーバは、質問されて、"proxy1.dmn3.com"に関連しているIPアドレスを返します(ケースによって、それは直接か中間的ネームサーバへのクライアントシステムにこれを返すかもしれません)。 結局、クライアントシステムはproxy1.dmn3.comに、有効なIPアドレスを得ます。
Chatel Informational [Page 7] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[7ページ]のRFC1919
+---------------+ +--------+
| | / IP \
| c.dmn1.com |--------+ network(s) +------------+
| (c1.c2.c3.c4) | \ / |
+---------------+ +--------+ +-----------------+
A | / \ | (p1.p2.p3.p4) |
| | address for / \ | proxy1.dmn3.com |
| | proxy1.dmn3.com? / \ | ... |
| | / \ +-----------------+
| | / \
| | / \
| | +--------+ proxy1.dmn3.com? +--------+
| +-------->| DNS |------------------>| DNS |
| | server | | server |
+------------| X |<------------------| Y |
p1.p2.p3.p4 +--------+ p1.p2.p3.p4 +--------+
+---------------+ +--------+ | | /IP\| c. dmn1.com|--------+ ネットワーク+------------+ | (c1.c2.c3.c4) | \ / | +---------------+ +--------+ +-----------------+ A| / \ | (p1.p2.p3.p4) | | | /には、\を扱ってください。| proxy1.dmn3.com| | | proxy1.dmn3.com? / \ | ... | | | / \ +-----------------+ | | / \ | | / \ | | +--------+ proxy1.dmn3.com? +--------+ | +-------->| DNS|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| DNS| | | サーバ| | サーバ| +------------| X| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| Y| p1.p2.p3.p4+--------+ p1.p2.p3.p4+--------+
Once the client system knows the IP address of the proxy system,
it attempts to establish a connection to the standard FTP
"control" TCP port on the proxy (port 21). For this to work, the
client system must have a valid route to the proxy's IP address,
and the proxy system must have a valid route to the client's IP
address. All intermediate devices that behave like IP gateways
must have valid routes to both the client and the proxy. If these
devices perform packet filtering, they must ALL allow the specific
type of traffic required between C and P1 for this specific
application (FTP).
クライアントシステムがいったんプロキシシステムのIPアドレスを知っていると、それは、「コントロール」TCPがプロキシで移植する標準のFTPに取引関係を築くのを試みます(21を移植してください)。 これが働くように、クライアントシステムはプロキシのIPアドレスに有効なルートを持たなければなりません、そして、プロキシシステムはクライアントのIPアドレスに有効なルートを持たなければなりません。 IPゲートウェイのように反応するすべての中間的デバイスがクライアントとプロキシの両方に有効なルートを持たなければなりません。 これらのデバイスがパケットフィルタリングを実行するなら、それらはこの特定のアプリケーション(FTP)にCとP1の間で必要であるトラフィックの特定のタイプをすべて許容しなければなりません。
Finally, the proxy system must accept this incoming connection,
based on the client's IP address (the purpose of the proxy is
generally to do access control, after all).
最終的に、プロキシシステムはこの接続要求を受け入れなければなりません、クライアントのIPアドレスに基づいて(プロキシの目的が一般に、アクセスコントロールをすることです、結局)。
+---------------+ | ... |
| c.dmn1.com | | proxy1.dmn3.com |
| (c1.c2.c3.c4) | | (p1.p2.p3.p4) |
+---------------+ +-----------------+
| | | |
| | route to P1 route to C | |
| V V |
| |
| A | A
| | route to C | | route to P1
| | | |
| | C P1 C | |
+----+ <-- +----+ --> +----+ <-- +----+
| G1 |--------| Gx |--------| Gy |---------| Gn |
+----+ --> +----+ <-- +----+ --> +----+
P1 C P1
+---------------+ | ... | | c. dmn1.com| | proxy1.dmn3.com| | (c1.c2.c3.c4) | | (p1.p2.p3.p4) | +---------------+ +-----------------+ | | | | | | CへのP1ルートへのルート| | | V V| | | | A| A| | Cへのルート| | P1へのルート| | | | | | C P1C| | +----+<--+----+-->+----+<--+----+ | G1|--------| Gx|--------| Gy|---------| Gn| +----+-->+----+<--+----+-->+----+ P1C P1
Chatel Informational [Page 8] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[8ページ]のRFC1919
The actual application work for the FTP session between the client
and proxy is done with a bidirectional flow of TCP packets between
the client's and proxy's IP addresses.
クライアントとプロキシとのFTPセッションのための仕事がクライアントとプロキシのIPアドレスの間のTCPパケットの双方向の流れで行われる本番適用。
For this to work, the proxy FTP application MUST fully support the
FTP protocol and look identical to an FTP server from the client's
point of view.
プロキシFTPアプリケーションは、これが働くように、FTPプロトコルを完全にサポートして、クライアントの観点からFTPサーバと同じに見えなければなりません。
Once the client<->proxy session is established, the final target
server name must be passed to the proxy, since, when using a
"classical" application proxy, a way MUST be defined for the proxy
to determine the final target system. This can be achieved in
three ways:
かつてのクライアント<、->プロキシセッションは確立されて、最終的な目標サーバー名をプロキシに渡さなければなりません、「古典的な」アプリケーションプロキシを使用するとき、プロキシが最終的な目標システムを決定するように道を定義しなければならないので。 3つの方法でこれを達成できます:
a) The client system supplies the name or address of the final
target system to the proxy in a method that is compatible
with the specific application protocol being used (in our
example, FTP). This is generally considered to be the main
problem with classical proxies, since for each application
being proxied, a method must be defined for passing the
name or address of the final target system. This method
must be compatible with every variant of client application
that implements the protocol (i.e. the target-passing
method must fit within the MINIMUM functionalities required
by the specific application protocol).
a) 使用される特定のアプリケーション・プロトコルと互換性があるメソッド(私たちの例のFTP)でクライアントシステムは最終的な目標システムの名前かアドレスをプロキシに提供します。 一般に、これは古典的なプロキシに関する主な問題であると考えられます、最終的な目標システムの名前かアドレスを通過するためにproxiedされる各アプリケーションにおいてメソッドを定義しなければならないので。 このメソッドはプロトコルを実装するクライアントアプリケーションのあらゆる異形と互換性があるに違いありません(すなわち、目標が一時的なメソッドは特定のアプリケーション・プロトコルによって必要とされたMINIMUMの機能性の中で合わなければなりません)。
For the FTP protocol, the generally popular method for
passing the final server name to the proxy is as follows:
FTPプロトコルにおいて、最終的なサーバー名をプロキシに渡すための一般にポピュラーなメソッドは以下の通りです:
When the proxy prompts the FTP client for a username, the
client specifies a string of the form:
プロキシがユーザ名のためにFTPクライアントをうながすとき、クライアントは形式のストリングを指定します:
target_username@target_system_name
or
target_username@target_ip_address
target_username@target_system_name か目標_ユーザ名@target_ip_アドレス
The proxy will then know what is the final target system.
The target_username (and the password supplied by the
client) will be forwarded "as is" by the proxy to the final
target system.
そして、プロキシは、何が最終的な目標システムであるかを知るでしょう。 目標_ユーザ名(そして、クライアントによって提供されたパスワード)はプロキシによって「そのままで」最終的な目標システムに転送されるでしょう。
A well-known example of an FTP proxy that behaves in this way
is the "ftp-gw" program which is part of the Trusted
Information System's firewall toolkit, available by anonymous
FTP at ftp.tis.com. Several commercial firewalls also support
this de-facto standard.
このように振る舞うFTPプロキシのよく知られる例はTrusted情報システムのファイアウォールツールキットの一部である"ftp-gw"プログラムです、公開FTPで、ftp.tis.comで利用可能です。 また、いくつかの商業ファイアウォールがこのデファクト規格をサポートします。
Chatel Informational [Page 9] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[9ページ]のRFC1919
b) If there is only one possible final destination, the proxy
may be configured to know this destination in advance.
Since the IP address of the client system is known when the
proxy must make this decision, the proxy can (if required)
select a different destination based on the IP address of
the client.
b) 1つの可能な最終的な目的地しかなければ、プロキシは、あらかじめこの目的地を知るために構成されるかもしれません。 クライアントシステムのIPアドレスが知られているので、プロキシがこの決定をしなければならないと、(必要なら、)プロキシはクライアントのIPアドレスに基づいて異なった目的地を選択できます。
c) The client software may also support capabilities that allow
it to present to the user the illusion of a direct session
(the user just specifies the final target system, and the
client software automatically handles the problem of
reaching to the proxy system and passing the name or address
of the final target system in whatever mutually-acceptable
form).
c) また、クライアントソフトウェアはそれがダイレクトセッションの幻想をユーザに提示できる能力をサポートするかもしれません(ユーザがただ最終的な目標システムを指定します、そして、クライアントソフトウェアは自動的に、いかなる互いに許容しているフォームでもプロキシシステムに達して、最終的な目標システムの名前かアドレスを通過するという問題を処理します)。
A well-known example of a system that provides modified
client software, proxy software, and that provides the
illusion of transparency is NEC's SOCKS system, available by
anonymous FTP at ftp.nec.com.
変更されたクライアントソフトウェア、プロキシソフトウェアを提供して、透明の幻想を供給するシステムのよく知られる例はNECのSOCKSシステムです、公開FTPで、ftp.nec.comで利用可能です。
Alternatively, several FTP client applications support the
"username@destination_host" de-facto standard implemented
(for example) by the "ftp-gw" proxy application.
あるいはまた、いくつかのFTPクライアントアプリケーションが(例えば、)"ftp-gw"プロキシアプリケーションで実装された" username@destination_host "デファクト規格をサポートします。
Once the FTP proxy application knows the name or IP address of the
target system, it can choose to do two things:
FTPプロキシアプリケーションがいったん目標システムの名前かIPアドレスを知っていると、2つのことをするのを選ぶことができます:
a) Setup a session to the final target system, the more
frequent case.
a) 最終的な目標システムへのセッション、より頻繁なケースをセットアップしてください。
b) Decide (based on some internal configuration data) that it
cannot reach the final target system directly, but must go
through another proxy. This is rare today, but may become
temporarily common due to the current shortage of IP
network numbers which encourages organizations to deploy
"hidden" network numbers which are already assigned
elsewhere. Sessions between systems which have the same
IP network number but which belong to different actual
networks may require going through two proxy systems.
This is discussed in more detail in section 3.2.6,
"Interconnection of conflicting IP networks".
b) 直接最終的な目標システムに達することができませんが、別のプロキシを通らなければならないと決めてください(いくつかの内部のコンフィギュレーション・データに基づいています)。 これは、今日、まれですが、ほかの場所で組織が既に割り当てられる「隠された」ネットワーク・ナンバーを配布するよう奨励するIPネットワーク・ナンバーの現在の不足のために一時一般的になるかもしれません。 同じIPネットワーク・ナンバーを持っていますが、異なった実際のネットワークのものシステムの間のセッションは、2台のプロキシシステムに直面しているのを必要とするかもしれません。セクション3.2.6、さらに詳細に「IPがネットワークでつなぐ闘争のインタコネクト」でこれについて議論します。
If the FTP proxy decides to connect directly to the target system,
and what it has is the target system name, it will need to convert
the target system name into an IP address. If this process
involves DNS resolution, something like the following will happen:
FTPプロキシが、直接目標システムに接続すると決めて、それには何があるかが、目標システム名であるなら、それは、目標システム名をIPアドレスに変換する必要があるでしょう。 以下が起こるようにこのプロセスがDNS解決にかかわるなら:
Chatel Informational [Page 10] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[10ページ]のRFC1919
+-----------------+
| proxy1.dmn3.com |
| (p1.p2.p3.p4) | +--------+
| | / IP \
| proxy2.dmn4.com |--------+ network(s) +------------+
| (p5.p6.p7.p8) | \ / |
+-----------------+ +--------+ +---------------+
A | / \ | (s1.s2.s3.s4) |
| | address for / \ | s.dmn2.com |
| | s.dmn2.com? / \ | |
| | / \ +---------------+
| | / \
| | / \
| | +--------+ s.dmn2.com? +--------+
| +-------->| DNS |------------------>| DNS |
| | server | | server |
+------------| X |<------------------| Y |
s1.s2.s3.s4 +--------+ s1.s2.s3.s4 +--------+
+-----------------+ | proxy1.dmn3.com| | (p1.p2.p3.p4) | +--------+ | | /IP\| proxy2.dmn4.com|--------+ ネットワーク+------------+ | (p5.p6.p7.p8) | \ / | +-----------------+ +--------+ +---------------+ A| / \ | (s1.s2.s3.s4) | | | /には、\を扱ってください。| s. dmn2.com| | | s. dmn2.com? / \ | | | | / \ +---------------+ | | / \ | | / \ | | +--------+ s.dmn2.com? +--------+ | +-------->| DNS|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| DNS| | | サーバ| | サーバ| +------------| X| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| Y| s1.s2.s3.s4+--------+ s1.s2.s3.s4+--------+
Once the proxy system knows the IP address of the server system,
it attempts to establish a connection to the standard FTP
"control" TCP port on the server (port 21). For this to work, the
proxy system must have a valid route to the server's IP address,
and the server system must have a valid route to at least one of
the proxy's IP address. All intermediate devices that behave like
IP gateways must have valid routes to both the proxy and the
server. If these devices perform packet filtering, they must ALL
allow the specific type of traffic required between the proxy and
S for this specific application.
プロキシシステムがいったんサーバシステムのIPアドレスを知っていると、それは、「コントロール」TCPがサーバで移植する標準のFTPに取引関係を築くのを試みます(21を移植してください)。 これが働くように、プロキシシステムはサーバのIPアドレスに有効なルートを持たなければなりません、そして、サーバシステムには、有効なルートが少なくともプロキシのIPアドレスの1つまでなければなりません。 IPゲートウェイのように反応するすべての中間的デバイスがプロキシとサーバの両方に有効なルートを持たなければなりません。これらのデバイスがパケットフィルタリングを実行するなら、それらはこの特定のアプリケーションのためのプロキシとSの間で必要であるトラフィックの特定のタイプをすべて許容しなければなりません。
Chatel Informational [Page 11] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[11ページ]のRFC1919
+-----------------+
| proxy1.dmn3.com |
| (p1.p2.p3.p4) |
| | +----------------+
| proxy2.dmn4.com | | s.dmn2.com |
| (p5.p6.p7.p8) | | (s1.s2.s3.s4) |
+-----------------+ +----------------+
| | | |
| | route to S route to P2 | |
| V V |
| |
| A | A
| | route to P2 | | route to S
| | | |
| | P2 S P2 | |
+----+ <-- +----+ --> +----+ <-- +----+
| G1 |--------| Gx |--------| Gy |---------| Gn |
+----+ --> +----+ <-- +----+ --> +----+
S P2 S
+-----------------+ | proxy1.dmn3.com| | (p1.p2.p3.p4) | | | +----------------+ | proxy2.dmn4.com| | s. dmn2.com| | (p5.p6.p7.p8) | | (s1.s2.s3.s4) | +-----------------+ +----------------+ | | | | | | P2へのSルートへのルート| | | V V| | | | A| A| | P2へのルート| | Sへのルート| | | | | | P2 S P2| | +----+<--+----+-->+----+<--+----+ | G1|--------| Gx|--------| Gy|---------| Gn| +----+-->+----+<--+----+-->+----+ S P2 S
The actual FTP application work between the proxy and server is
done with a bidirectional flow of TCP packets between the proxy's
and server's IP addresses.
プロキシとサーバの間のアプリケーション仕事がプロキシとサーバのIPアドレスの間のTCPパケットの双方向の流れで行われる実際のFTP。
What actually happens BETWEEN THE CLIENT AND SERVER? They both
send replies and responses to the proxy, which forwards data to
the "other" end. When one party opens a data connection and sends
a PORT command to the proxy, the proxy allocates its own data
connection and sends its PORT command to the "other" end. The
proxy also copies data across the connections created in this way.
何が実際に起こるか、BETWEEN THE CLIENT AND SERVER? それらの両方が回答と応答をプロキシに送ります。(プロキシは「他」の終わりにデータを転送します)。 1回のパーティーがデータ接続を公開していて、PORTコマンドをプロキシに送るとき、プロキシは、「他」の終わりにそれ自身のデータ接続を割り当てて、PORTコマンドを送ります。 また、プロキシはこのように創造された接続の向こう側にデータをコピーします。
3.2 Characteristics of classical proxy configurations
3.2 古典的なプロキシ構成の特性
Several IP internetworks may be linked using only classical proxy
technology. It is currently popular to link two specific IP
internetworks in this way: the Internet and some organization's
"private" IP network. Such a proxy-based link is often the key
component of a firewall.
いくつかのIPインターネットワークが、古典的なプロキシ技術だけを使用することでリンクされるかもしれません。 このように2つの特定のIPインターネットワークをリンクするのは現在、ポピュラーです: インターネットと何らかの組織が「個人的な」IPネットワークです。 しばしばそのようなプロキシベースのリンクはファイアウォールの主要な部品です。
When this is done, several benefits and problems are introduced
for network administrators and users.
これが完了していると、いくつかの利益と問題はネットワーク管理者とユーザのために紹介されます。
3.2.1 IP addressing and routing requirements.
3.2.1 IPアドレシングとルーティング要件。
The proxy system must be able to address all client and server
systems to which it may provide service. It must also know
valid IP routes to all these client and server systems.
プロキシシステムはそれがサービスを供給するかもしれないすべてのクライアントとサーバシステムに演説できなければなりません。 また、それはこれらのすべてのクライアントとサーバシステムに有効なIPルートを知らなければなりません。
Chatel Informational [Page 12] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[12ページ]のRFC1919
Client and server systems must be able to address the proxy
system, and must know a valid IP route to the proxy system. If
the proxy system has several IP addresses (and often, several
physical network interfaces), the client and server systems
need only to be able to access ONE of the proxy system's IP
addresses.
クライアントとサーバシステムは、プロキシシステムを扱うことができなければならなくて、有効なIPルートをプロキシシステムに知らなければなりません。 プロキシシステムにいくつかのIPアドレス(そして、しばしばいくつかの物理ネットワークインタフェース)があるなら、クライアントとサーバシステムは、単にプロキシシステムのIPアドレスのONEにアクセスできる必要があります。
Note that client and server systems that use the proxy for
communication DO NOT NEED valid IP addressing or routing
information for systems that they reach through the proxy.
コミュニケーションにプロキシを使用するクライアントとサーバシステムがそれらがプロキシを通して達するシステムのための有効なIPアドレシングかルーティング情報を必要としないことに注意してください。
In this sense, it can be said that systems separated by a
classical proxy are isolated from each other in an IP
addressing sense and in an IP routing sense.
この意味で、それを言うことができます。古典的なプロキシによって切り離されたシステムは互いから感覚を扱うIPとIPルーティング意味で隔離されます。
On the other hand, the classical proxy system (if running a
standard TCP/IP software stack) needs to have a single coherent
view of IP addressing and routing. If such a proxy system
interconnects two IP networks and two systems use the same IP
network/subnetwork number (one system on each network), the
proxy will only be able to address one of the systems.
他方では、古典的なプロキシシステム(標準のTCP/IPソフトウェア・スタックを動かすなら)はIPアドレシングとルーティングのただ一つの論理的な視点を必要とします。 そのようなプロキシシステムが2つのIPネットワークとインタコネクトして、2台のシステムが同じIPネットワーク/サブネットワーク番号(各ネットワークの1台のシステム)を使用すると、プロキシはシステムの1つを扱うことができるだけでしょう。
This restriction can be removed by chaining classical proxies
(this is described later in section 3.2.6, "Interconnection of
conflicting IP networks").
古典的なプロキシを鎖でつなぐことによって、この制限を取り除くことができます(これは後でセクション3.2.6、「IPがネットワークでつなぐ闘争のインタコネクト」で説明されます)。
Using a classical proxy for interconnection of IP
internetworks, it is also possible, with care, to achieve a
desirable "fail-safe" feature: no valid routing entries need to
exist for an internetwork which should be reached only through
the proxy (routing updates that could add such entries shout be
BLOCKED). If the proxy suddenly starts to behave like an IP
router, only one-way attacks become possible.
IPインターネットワークのインタコネクトに古典的なプロキシを使用して、また、望ましい「フェールセイフ」の特徴を獲得するのも慎重に可能です: どんな有効なルーティングエントリーも、プロキシだけを通して達するべきであるインターネットワークのために存在する必要がありません(そのようなエントリーが叫ぶと言い足すことができたアップデートを発送して、BLOCKEDになってください)。 プロキシがIPルータのように突然振る舞い始めるなら、一方向攻撃だけが可能になります。
In other words, assume an attacker has control of the remote
internetwork and has found a way to cause the proxy to route IP
packets, or has found a way to physically bypass the proxy.
言い換えれば、攻撃者がリモートインターネットワークを管理して、プロキシがIPパケットを発送することを引き起こす方法を見つけたか、またはプロキシを物理的に迂回させる方法を見つけたと仮定してください。
The attacker may inject packets, but the attacked internal
systems will be unable to reply to those packets. This
certainly does not make attacks infeasible (as exemplified by
certain holiday-period events in recent years), but it still
makes attacks more difficult.
攻撃者はパケットを注入するかもしれませんが、攻撃された内部のシステムはそれらのパケットに答えることができないでしょう。 これで、攻撃は確かに実行不可能になりませんが(近年ある休暇の時期イベントによって例示されるように)、それで、攻撃はまだより難しくなっています。
Chatel Informational [Page 13] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[13ページ]のRFC1919
3.2.2 IP address hiding
3.2.2 IPアドレス隠れること
Application "sessions" that go through a classical proxy are
actually made of two complete sessions:
古典的なプロキシを通るアプリケーション「セッション」が実際に2つの終了しているセッションで作られています:
a) a session between the client and the proxy
b) a session between the proxy and the server
a) クライアントとプロキシbとのセッション) プロキシとサーバとのセッション
A device on the path sees only the client<->proxy traffic or
the proxy<->server traffic, depending where it is located. If
the two sessions actually pass through the same physical
network, a device on that network may see both traffics, but
may have difficulty establishing the relationship between the
two sessions (depending on the specific application and
activity level of the network).
それがどこに位置しているかによって、経路のデバイスはクライアントだけプロキシトラフィックかプロキシ<の<->>のためにサーバートラフィックを見ます。 2つのセッションが実際に同じ物理ネットワークを通り抜けるなら、そのネットワークのデバイスは、両方の通行を見ますが、2つのセッションの間の関係を確立するのに苦労するかもしれません(ネットワークの特定のアプリケーションと活動レベルによって)。
A by-product of a classical proxy's behavior is commonly known
as "address hiding". Equipments on some side of a classical
proxy cannot easily determine what are the IP addresses used on
another side of the proxy.
古典的なプロキシの振舞いの副産物は「アドレス隠れること」として一般的に知られています。 古典的なプロキシの何らかの側面の上の機器は、何がプロキシの別の側面で使用されるIPアドレスであるかを容易に決定できません。
Address hiding is generally viewed as a Good Thing, since one
of the purposes of deploying proxies is to disclose as little
information about an internetwork as possible.
一般に、アドレス隠れることはGood Thingとして見なされます、プロキシを配布する目的の1つができるだけほとんどインターネットワークの情報を明らかにしないことであるので。
People who are in charge of gathering network statistics, and
who do not have access to the proxy system's reports (if any)
may consider address hiding to be a Bad Thing, since the proxy
obscures the actual client/server relationships where the proxy
was inserted. All IP activity originates and terminates on the
proxy itself (or appears to do so).
集会を担当している人々が統計をネットワークでつなぎます、そして、だれがプロキシシステムのレポート(もしあれば)に近づく手段を持っていないかがプロキシがプロキシが挿入された実際のクライアント/サーバ関係をあいまいにするのでBad Thingになるように隠れるアドレスを考えるかもしれません。 すべてのIP活動が、プロキシ(または、そうするように見える)自体で起因して、終わります。
In the same way, server software that accepts connections that
have gone through a classical proxy do not see the IP address
of the incoming client, unless this information is included in
the application protocol (and even if it is, in many cases, the
proxy will replace this information with its own address for
the protocol to be consistent). This makes server access
control unusable if it is based on client IP address checks.
古典的なプロキシを通った接続が同じ道、受け入れるサーバソフトウェアの入って来るクライアントのIPアドレスを見ません、この情報がアプリケーション・プロトコルに含まれていない場合(多くの場合にそれがあっても、プロキシはプロトコルが一貫しているようにこの情報をそれ自身のアドレスに取り替えるでしょう)。 これで、クライアントIPアドレス検査に基づいているなら、サーバアクセス制御装置は使用不可能になります。
3.2.3 DNS requirements
3.2.3 DNS要件
In most classical-proxy configurations, client systems pass the
desired server name (or address) to the proxy system WITHOUT
INTERPRETING IT. Because of this, the client system DOES NOT
REQUIRE to be able to resolve the name of the server system in
order to access it through a classical proxy. It only needs to
be able to resolve the name of the proxy (if referencing the
ほとんどの古典的なプロキシ構成では、クライアントシステムは必要なサーバー名(または、アドレス)をプロキシシステムWITHOUT INTERPRETING ITに通過します。 これ(古典的なプロキシを通してそれにアクセスするためにサーバシステムの名前を決議できるクライアントシステムDOES NOT REQUIRE) それが、プロキシの名前を決議できる必要があるだけである、(参照をつけること。
Chatel Informational [Page 14] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[14ページ]のRFC1919
proxy system by name).
名前のプロキシシステム)
Because of this, it can be said that a classical proxy system
can offer DNS isolation. If two IP internetworks use completely
separate DNS trees (each with their own DNS root servers),
client software in one IP internetwork may still reference a
server name in the other IP internetwork by passing its name to
the classical proxy.
これのために、古典的なプロキシシステムがDNS分離を提供できると言うことができます。 2つのIPインターネットワークが完全に別々のDNS木(それら自身のDNSルートサーバーがあるそれぞれ)を使用するなら、あるIPインターネットワークにおけるクライアントソフトウェアは、古典的なプロキシに名前を渡すことによって、まだもう片方のIPインターネットワークにおけるサーバー名に参照をつけているかもしれません。
The classical proxy itself will not be able alone to resolve
DNS names in both environments (if running standard DNS
resolution software), since it will need to point to one or the
other of the two DNS "universes".
古典的なプロキシ自体は単独でDNSが両方の環境で命名する決心にできるようにならないでしょう(標準のDNS解決ソフトウェアを動かすなら)、2DNS「宇宙」の1かもう片方を示すのが必要であるので。
A well-known technique called "split-brain DNS" can be used to
relax this restriction somewhat, but such a technique
ultimately involves prioritizing one DNS environment over
another. If a DNS query can return a valid answer in both
environments, only one of the answers will be found by the
proxy.
この規制をいくらか緩和するのに「分裂脳のDNS」と呼ばれるよく知られるテクニックは使用できますが、そのようなテクニックは、結局、別のものの上で1つのDNS環境を最優先させることを伴います。 質問が両方の環境、1だけで有効な答えを返すことができる答えのDNSがプロキシによって見つけられるなら。
3.2.4 Software requirements
3.2.4 ソフトウェア要件
A classical proxy application is a fairly simple piece of
software, often simpler than either a real client
implementation or a real server implementation. Such a program
may run on any system that supports normal TCP/IP connections,
and often does not require "system" or "superuser" privilege.
古典的なプロキシアプリケーションはかなり簡単なソフトウェア一本です、本当のクライアント実装か本当のサーバ実装のどちらかよりしばしば簡単です。 そのようなプログラムは、正常なTCP/IP接続をサポートするどんなシステムでも動くかもしれなくて、しばしば「システム」か"「スーパー-ユーザ」"特権を必要とするというわけではありません。
Classical proxy connections have no impact on normal server
software; the proxy looks like a normal client in most respects
except for its IP address and its "group" nature. All
connections from the network on the other side of the proxy
appear to come from the proxy, which poses problems if access
control by client system is desired.
古典的なプロキシ接続は正常なサーバソフトウェアの上に影響力を全く持っていません。 プロキシはIPアドレスとその「グループ」自然以外のほとんどの点で普通のクライアントに似ています。 プロキシの反対側の上のネットワークからのすべての接続が、プロキシから来るように見えます。(クライアントシステムによるアクセスコントロールが望まれているなら、プロキシは問題を引き起こします)。
Normal client software may access a classical proxy if the user
is willing or able to go through the extra steps necessary to
indicate the final server to the proxy (whatever they are).
Alternatively, modified (or newer) client software may be used
that knows how to negotiate transparently with the proxy.
ユーザが望んでいるか、またはプロキシ(それらはことなら何でもである)に最終的なサーバを示すために付加的な必要なステップに直面できるなら、正常なクライアントソフトウェアは古典的なプロキシにアクセスするかもしれません。 あるいはまた、透過的にプロキシと交渉する方法を知っている変更されて(より新しい)のクライアントソフトウェアは使用されるかもしれません。
3.2.5 Impact of a classical proxy on packet filtering
3.2.5 パケットフィルタリングの古典的なプロキシの影響
If packet filtering is needed around a classical proxy, the
packet filtering rules tend to be simplified, since the only
traffic needed and allowed will originate from or terminate on
the proxy (in an IP sense).
パケットフィルタリングが古典的なプロキシの周りで必要であるなら、パケットフィルタリング規則は、簡素化される傾向があります、必要であり、許容された唯一のトラフィックがプロキシ(IP意味における)で発するか、または終わるので。
Chatel Informational [Page 15] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[15ページ]のRFC1919
If the proxy starts behaving like an IP router, or if it is
physically bypassed, such filtering rules, if deployed
generally within an IP internetwork, will tend to prevent any
direct traffic flow between the "internal" internetwork and
"external" internetworks that are supposed to be only reachable
through the application proxy.
プロキシがIPルータのように振る舞い始めるか、またはそれが物理的に迂回すると、IPインターネットワークの中で一般に配布されるなら規則をフィルターにかけるのであるのは、そのようなアプリケーションプロキシを通して届くだけであるべきである「内部」のインターネットワークと「外部」のインターネットワークの間のどんなダイレクト交通の流れも防ぐ傾向があるでしょう。
3.2.6 Interconnection of conflicting IP networks
3.2.6 IPがネットワークでつなぐ闘争のインタコネクト
By chaining classical proxies, it is possible to achieve some
interconnection of IP networks that have a high level of
conflict. In practice, this type of setup resolves IP
addressing conflicts much better than DNS conflicts. But DNS
conflicts are currently less of a problem because the DNS
"address space" is almost infinitely large (has anybody
calculated the possible DNS address space based on the RFC-
standard maximum host name length?).
古典的なプロキシを鎖でつなぐことによって、高いレベルの闘争を持っているIPネットワークの何らかのインタコネクトを達成するのは可能です。 実際には、このタイプのセットアップは闘争をDNSが闘争するよりはるかによく扱うIPを決議します。 しかし、DNS「アドレス空間」がほとんど無限に大きいので(だれか長さというRFCの標準の最大のホスト名に基づく可能なDNSアドレス空間について計算しましたか?)、問題ではDNS闘争は現在、より少ないです。
Even though RFC 1597 was never more than an informational RFC,
many organizations have been quietly following its suggestions,
for lack of an easier solution. Now assume two organizations
each use class A network number 10 on their network. Suddenly,
they need to interconnect. What can they do?
RFC1597は情報のRFC決して以上ではありませんでしたが、多くの組織が静かに提案に続いています、より簡単なソリューションの不足のために。 今度は、2つの組織がそれぞれそれらのネットワークのクラスAネットワーク・ナンバー10を使用すると仮定してください。 突然、彼らは、内部連絡する必要があります。 彼らは何ができますか?
First possibility: one side changes network number (not as hard
as people think if properly planned, but this still represents
some work)
最初の可能性: 半面はネットワーク・ナンバーを変えます。(人々が、適切に計画されていて、これだけがまだいくらかの仕事を表しているかどうか考えるほど困難でない)です。
Second possibility: they merge the two numbers by renumbering
partially on each side to remove conflicts (actually harder to
do, but has the political advantage that both sides have to do
some work)
2番目の可能性: 彼らは、闘争を取り除くためにそれぞれの側で部分的に番号を付け替えることによって、2つの番号を合併します。(実際により困難である、両側がいくらかの仕事をするために持っている政治上の利点をしますが、持っている、)
Third possibility: they communicate through chained classical
proxies:
3番目の可能性: 彼らはチェーニングされた古典的なプロキシを通って交信します:
+--------+ +--------+ +--------+ +--------+
/ Org. 1 \ | Proxy | | Proxy | / Org. 2 \
+ dmn1.com +---+ system +---+ system +---+ dmn2.com +
\ net 10 / | 1 | | 2 | \ net 10 /
+--------+ +--------+ +--------+ +--------+
+--------+ +--------+ +--------+ +--------+/Org。 1 \ | プロキシ| | プロキシ| /Org。 2\+dmn1.comの+---+ システム+---+ システム+---+ ネットの10dmn2.com+円の/| 1 | | 2 | \ネット10/+--------+ +--------+ +--------+ +--------+
Both proxy 1 and 2 are standard systems running normal TCP/IP
software stacks. Their configuration is not typical, however:
プロキシ1と2の両方が正常なTCP/IPソフトウェア・スタックを動かす標準のシステムです。 しかしながら、それらの構成は典型的ではありません:
Chatel Informational [Page 16] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[16ページ]のRFC1919
a) The link between proxy 1 and proxy 2 may use any IP
network number that is not used (or not needed) on
either side. Nothing on Org.1 and Org.2's networks
need to have an IP route to this network.
a) プロキシ1とプロキシ2とのリンクはどちらの側でも使用されない(または、必要ではありません)少しのIPネットワーク・ナンバーも使用するかもしれません。 Org.1の上の無とOrg.2のネットワークはこのネットワークにIPルートを必要とします。
b) Proxy 1 has an IP route for network 10 that points to
Organization 1's network, and does DNS resolution
(if required) using dmn1.com's name servers.
b) プロキシ1は、Organization1のネットワークを示すネットワーク10のためにIPルートを持って、(必要なら、)dmn1.comのネームサーバを使用することでDNS解決をします。
c) Proxy 2 has an IP route for network 10 that points to
Organization 2's network, and does DNS resolution
(if required) using dmn2.com's name servers.
c) プロキシ2は、Organization2のネットワークを示すネットワーク10のためにIPルートを持って、(必要なら、)dmn2.comのネームサーバを使用することでDNS解決をします。
d) Proxy 1 and proxy 2 only require a host IP route to
each other for communication.
d) プロキシ1とプロキシ2はコミュニケーションのためにホストIPルートを互いに必要とするだけです。
e) For this to be convenient, the classical proxy
applications must support the automatic selection of
a destination based on the client IP address.
e) これが近いように、古典的なプロキシアプリケーションはクライアントIPアドレスに基づく目的地の自動選択をサポートしなければなりません。
f) On proxy system 1, the proxy software treats incoming
sessions from proxy system 2 in the normal way: the
"client" (proxy system 2) will be prompted in an
application-specific way for the final destination.
However, incoming sessions from Org.1 addresses are
immediately and automatically forwarded to proxy
system 2.
f) プロキシシステム1に、プロキシソフトウェアはプロキシシステム2から入って来るセッションを正常な方法で扱います: 「クライアント」(プロキシシステム2)は最終的な目的地へのアプリケーション特有の方法でうながされるでしょう。 しかしながら、すぐに、自動的にOrg.1アドレスからの入って来るセッションをプロキシシステム2に送ります。
Proxy system 2 is configured similarly (that is,
connections coming from proxy 1 are prompted for a
target server name, connections from Org.2 addresses
are immediately and automatically forwarded to
proxy 1.
プロキシシステム2は同様に構成されます。(すなわち、プロキシ1から来る接続は目標サーバー名のためにうながされます、アドレスがすぐに、自動的に転送されるOrg.2からプロキシ1までの接続。
From a user's point of view, the behavior of such a chained
proxy system is not very different from a single classical
application proxy:
ユーザの観点と、そのようなチェーニングされたプロキシシステムの働きは独身の古典的なアプリケーションプロキシとそれほど異なっていません:
a) A user on a client system with address 10.1.2.3
on Org.1's network wishes to do an anonymous FTP to
"server.dmn2.com".
a) アドレスがあるクライアントシステムの上のユーザ、10.1、.2、.3、Orgでは、.1ネットワークは"server.dmn2.com"に公開FTPをしたがっています。
b) The user starts an FTP towards proxy 1. Proxy 1 sees
an incoming connection from an address in network 10,
so it immediately relays the connection to proxy 2.
b) ユーザはプロキシ1に向かってFTPを始めます。 プロキシ1がアドレスからネットワーク10で接続要求を見るので、それはすぐに、プロキシ2に接続をリレーします。
c) Proxy 2 sees a connection coming from proxy 1, so it
prompts the client. The user sees the username prompt
c) プロキシ2が、接続がプロキシ1から来るのを見るので、それはクライアントをうながします。 ユーザは、ユーザ名が迅速であることがわかります。
Chatel Informational [Page 17] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[17ページ]のRFC1919
and types (assuming FTP proxies that behave like TIS's
ftp-gw):
タイプ(振る舞うFTPプロキシがTISのftp-gwが好きであると仮定します):
anonymous@server.dmn2.com
anonymous@server.dmn2.com
This will be resolved IN THE CONTEXT OF Org. 2'S
NETWORK. The user can then complete the dialog and
use the FTP connection.
これは決定しているIN CONTEXT OF Orgになるでしょう。 2によるネットワークです。 ユーザは、次に、対話を完成して、FTP接続を使用できます。
d) Note that this setup will work even if the client and
server have the EXACT SAME IP ADDRESS (10.1.2.3 in
our example).
d) クライアントとサーバにEXACT SAME IP ADDRESSがあってもこのセットアップが働くことに注意してください、(10.1、.2、私たちの例の.3)
If the proxy applications support selecting another
proxy based on the destination supplied by the client,
and if DNS domains are unique, more than two conflicting
IP networks can be linked in this way! Here is an
example configuration:
プロキシアプリケーションがクライアントによって供給された目的地に基づく別のプロキシを選択にサポートして、DNSドメインがユニークであるなら、このように2つ以上の闘争しているIPネットワークをリンクできます! ここに、例の構成があります:
a) Four IP networks that all use network 10 are linked
by four proxy systems. The four proxy systems share a
common, private IP network number and physical link
(LAN or WAN).
a) ネットワーク10を使用する4つのIPネットワークがすべて、4台のプロキシシステムによってリンクされます。4台のプロキシシステムが一般的なプライベートアイピーネットワーク・ナンバーと物理的なリンク(LANかWAN)を共有します。
b) A user on organization 1's network wishes to access
a server on network 3. The user connects to its local
proxy (proxy 1) and supplies that target system name.
b) 1がネットワークでつなぐ組織でのユーザはネットワーク3でサーバにアクセスしたがっています。 ユーザは、地元のプロキシ(プロキシ1)に接して、その目標システム名前を提供します。
c) Proxy 1 determines, based on a configuration rule,
that the target system name is reachable by using
proxy 3. So it connects to proxy 3 and passes the
target system name.
c) プロキシ1は、構成規則に基づいて目標システム名にプロキシ3を使用することによって届いていると決心しています。 それで、それは、プロキシ3に接して、目標システム名を渡します。
d) Proxy 3 determines that the target system name is
local (to itself) and connects to it directly.
d) プロキシ3は目標システム名が地方であり(それ自体への)、直接それに接続すると決心しています。
Security Implications of chained proxies
チェーニングされたプロキシのセキュリティImplications
Obviously, when such "chained" configurations are built,
access control rules and logging based on a
final-client/final-server combination are difficult to
enforce, since the first proxy in the chain sees a
final-client/proxy relationship and the last proxy in
the chain sees a proxy/final-server relationship.
そのような「チェーニングされた」構成が組立しているとき、明らかに、アクセス制御規則と最終的な最終的なクライアント/サーバ組み合わせに基づく伐採は実施するのが難しいです、第1代チェーンのプロキシが最終的なクライアント/プロキシ関係を見て、チェーンの最後のプロキシが最終的なプロキシ/サーバ関係を見るので。
Doing better than this requires that the proxies be
capable of passing the "original-client" and
そしてこれが、プロキシが「オリジナルのクライアント」を通ることができるのを必要とするより上手にする。
Chatel Informational [Page 18] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[18ページ]のRFC1919
"final-destination" information back and forth in the
proxy chain for access control and/or logging purposes.
This requires the proxies to trust each other, and
requires the network path to be trusted (forging this
information becomes an excellent attack).
「最終的な目的地」情報のアクセスのためのチェーンが監督するプロキシの前後方向の、そして/または、登録している目的。 これは、プロキシが互いを信じるのが必要であり、ネットワーク経路が信じられるのを必要とします(この情報を作り出すのは素晴らしい攻撃になります)。
Even if these problems were to be solved reliably, the
original goal of the proxy chains was to solve an IP
and possibly a DNS conflict. The "original-client" and
"final-destination" values may not have the same
meaning everywhere in the overall setup. Tagging the
information with a "universe-name" may help, assuming
it is possible to define unique universe names in the
first place. Obviously this topic requires more study.
プロキシチェーンの元の目標はこれらの問題が確かに解決されることであったなら、IPとことによるとDNS闘争を解決することでした。 「オリジナルのクライアント」と「最終的な目的地」値は総合的なセットアップによるいたる所に同じ意味を持っていないかもしれません。 「宇宙名」を情報にタグ付けするのは助けるかもしれません、第一にユニークな宇宙名を定義するのが可能であると仮定して。 明らかに、この話題は、より多くの研究を必要とします。
4. Transparent application proxies
4. 透明なアプリケーションプロキシ
The most visible problem of classical application proxies is the need for proxy-capable client programs and/or user education so that users know how to use the proxies.
古典的なアプリケーションプロキシの最も目に見える問題がプロキシできるクライアントプログラム、そして/または、ユーザ教育の必要性であるので、ユーザはプロキシを使用する方法を知っています。
When somebody thought of modifying proxies in such a way that normal user procedures and normal client applications would still be able to take advantage of the proxies, the transparent proxy was born.
だれかが、正常なユーザ手順と通常のクライアントアプリケーションがまだプロキシを利用できるだろうような方法でプロキシを変更することを考えたとき、透明なプロキシは生まれました。
A transparent application proxy is often described as a system that appears like a packet filter to clients, and like a classical proxy to servers. Apart from this important concept, transparent and classical proxies can do similar access control checks and can offer an equivalent level of security/robustness/performance, at least as far as the proxy itself is concerned.
透明なアプリケーションプロキシはしばしばクライアントへのパケットフィルタ、およびサーバへの古典的なプロキシのように見えるシステムとして記述されています。 この重要な概念は別として、透明で古典的なプロキシは、同様のアクセス制御チェックができて、同等なレベルのセキュリティ/丈夫さ/性能を提供できます、プロキシ自体は関係があるのと少なくとも同じくらい遠いです。
The following information will make it clear that small organizations that wish to use proxy technology for protection, that wish to rely entirely on one proxy system for network perimeter security, that want a minimal (or zero) impact on user procedures, and that do not wish to bother with proxy-capable clients will tend to prefer transparent proxy technology.
以下の情報はプロキシ有能なクライアントが、見え透いたプロキシ技術を好む傾向があることを保護のためのプロキシ技術、ネットワーク国境保障の1台のプロキシシステムを完全に当てにするというユーザ手順で最小量(または、ゼロ)の影響が欲しく、そうしないその願望が苦にしたい使用に願っているそんなに小さい組織について断言するでしょう。
Organizations with one or more of the following characteristics may prefer deploying classical proxy technology:
以下の特性の1つ以上がある組織は、古典的なプロキシ技術を配布するのを好むかもしれません:
a) own a substantial internal IP router network, and wish to
avoid adding "external" routes on the network
b) wish to deploy "defence in depth", such as internal firewalls,
packet filtering on the internal network
c) wish to keep their DNS environment fully isolated from the
"other side" of their proxy system, or that fear that their
自身のa)のaかなりの内部のIPルータネットワーク、および「深層防護」を配布するというネットワークb)願望の内部のファイアウォール、彼らのプロキシシステムの「反対側」から彼らのDNS環境を完全に隔離し続けるという内部のネットワークc)願望でのパケットフィルタリング、またはそれなどの「外部」のルートがそれを恐れると言い足すのを避けるという願望、彼ら
Chatel Informational [Page 19] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[19ページ]のRFC1919
internal DNS servers may be vulnerable to data-driven attacks
d) use some IP networks that are in conflict with the "other side"
of their proxy system
e) wish to use proxy applications that are easily portable
to different operating system types and/or versions
f) wish to deploy multiple proxy systems interconnecting them
to the SAME remote network without introducing dynamic
routing for external routes on the internal network
内部のDNSサーバはデータ駆動型攻撃d) いくつかの容易に異なったオペレーティングシステムタイプ、そして/または、バージョンf)に携帯用であることのプロキシアプリケーションを使用するという彼らのプロキシシステムe)願望の「反対側」との闘争中であることのIPネットワークが複数のプロキシシステムを配布したがっている内部のネットワークの外部経路にダイナミックルーティングを取り入れないでSAMEのリモートネットワークとそれらとインタコネクトする使用に被害を受け易いかもしれません。
4.1 Transparent proxy connection example
4.1 見え透いたプロキシ接続の例
Let us go through an FTP sesssion again, through a "transparent"
proxy this time. We assume that the proxy system has two IP
addresses, two network interfaces, and two DNS names.
今回、再び「透明な」プロキシを通してFTP sesssionを通りましょう。 私たちは、プロキシシステムには2つのIPアドレス、2つのネットワーク・インターフェース、および2つのDNS名があると思います。
The proxy system is running a special program which knows how to
behave like an FTP client on one side, and like an FTP server on
the other side. This program is what people call the "proxy". This
program, being a transparent proxy, also has a very special
relationship with the TCP/IP implementation of the proxy system.
This relationship may be built in several ways, we will describe
only one such possible way.
プロキシシステムは半面の上のFTPクライアント、および反対側の上のFTPサーバのように振る舞う方法を知っている特別なプログラムを動かしています。 このプログラムは人々が「プロキシ」と呼ぶものです。 また、透明なプロキシでありこのプログラムにはプロキシシステムのTCP/IPインプリメンテーションとの非常に特別な関係があります。 私たちは、この関係がいくつかの方法で築き上げられるかもしれないとそのような方法の可能な1つだけで説明するつもりです。
We will assume that the proxy program is listening to incoming
requests on the standard FTP control port (21/tcp), although this
is not always the case in practice.
私たちは、プロキシプログラムが標準のFTP制御ポート(21/tcp)に関する入って来る要求を聞いていると思うつもりです、これは実際にはいつもそうであるというわけではありませんが。
+---------------+ +----------+
| | / IP \
| c.dmn1.com |----+ network(s) +----------+
| (c1.c2.c3.c4) | \ / |
+---------------+ +----------+ +-----------------+
| (p1.p2.p3.p4) |
| proxy1.dmn3.com |
| |
| proxy2.dmn4.com |
| (p5.p6.p7.p8) |
+---------------+ +----------+ +-----------------+
| | / IP \ |
| s.dmn2.com |----+ network(s) +----------+
| (s1.s2.s3.s4) | \ /
+---------------+ +----------+
+---------------+ +----------+ | | /IP\| c. dmn1.com|----+ ネットワーク+----------+ | (c1.c2.c3.c4) | \ / | +---------------+ +----------+ +-----------------+ | (p1.p2.p3.p4) | | proxy1.dmn3.com| | | | proxy2.dmn4.com| | (p5.p6.p7.p8) | +---------------+ +----------+ +-----------------+ | | /IP\| | s. dmn2.com|----+ ネットワーク+----------+ | (s1.s2.s3.s4) | \ / +---------------+ +----------+
Chatel Informational [Page 20] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[20ページ]のRFC1919
The user starts an instance of an FTP client program on the client
system "c.dmn1.com", and specifies a destination of "s.dmn2.com",
just like if it was reachable directly. On command-line systems,
the user typically types:
ユーザは、クライアントシステム「c.dmn1.com」にFTPクライアントプログラムのインスタンスを始めて、「s.dmn2.com」の目的地を指定して、それが直接届いたなら、ただ好きです。 コマンドラインシステムで、ユーザは通常タイプします:
ftp s.dmn2.com
ftp s.dmn2.com
The client system needs to convert the server's name to an IP
address (if the user directly specified the server by address,
this step is not needed).
クライアントシステムは、サーバの名前をIPアドレスに変換する必要があります(ユーザがアドレスで直接サーバを指定したなら、このステップは必要ではありません)。
Converting the server name to an IP address requires work to be
performed which ranges between two extremes:
実行されるために働くIPアドレスが、必要である2つの極端の間で及ぶサーバー名を変換します:
a) the client system has this name in its hosts file, or has
local DNS caching capability and successfully retrieves the
name of the proxy system in its cache. No network activity
is performed to convert the name to an IP address.
a) クライアントシステムは、ホストのこの名前をファイルさせるか、地方のDNSに能力をキャッシュさせて、またはキャッシュでプロキシシステムの名前を首尾よく検索します。 ネットワーク活動は、全くIPアドレスに名前を変換するために実行されません。
b) the client system, in combination with DNS name servers,
generate DNS queries that eventually propagate close to the
root of the DNS tree and back down the server's DNS branch.
Eventually, a DNS server which is authoritative for the
server system's domain is queried and returns the IP
address associated with "s.dmn2.com" (depending on the
case, it may return this to the client system directly or
to an intermediate name server). Ultimately, the client
system obtains a valid IP address for s.dmn2.com.
b) DNSネームサーバと組み合わせて、クライアントシステムは、DNSが結局DNS木と逆下の根の近くでサーバのDNSブランチを伝播する質問であると生成します。 結局、サーバシステムのドメインに、正式のDNSサーバは、質問されて、「s.dmn2.com」に関連しているIPアドレスを返します(ケースによって、それは直接か中間的ネームサーバへのクライアントシステムにこれを返すかもしれません)。 結局、クライアントシステムはs.dmn2.comに、有効なIPアドレスを得ます。
Chatel Informational [Page 21] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[21ページ]のRFC1919
+---------------+ +--------+
| | / IP \
| c.dmn1.com |--------+ network(s) +------------+
| (c1.c2.c3.c4) | \ / |
+---------------+ +--------+ +-----------------+
A | / | (p1.p2.p3.p4) |
| | address for / +-----+ | proxy system |
| | s.dmn2.com? / / \ | (p5.p6.p7.p8) |
| | / / \ +-----------------+
| | / / \ |
| | / / s.dmn2.com? | |
| | +--------+ / | +--------+
| +-------->| DNS |--+ +-------+ | / IP \
| | server | / \ | + network(s) +
+------------| X |<---+ + | \ /
s1.s2.s3.s4 +--------+ s1.s2.s3.s4| | +--------+
| | |
| + |
| \ +--------+
+ +->| DNS |
\ | server |
+----| Y |
+--------+
+---------------+ +--------+ | | /IP\| c. dmn1.com|--------+ ネットワーク+------------+ | (c1.c2.c3.c4) | \ / | +---------------+ +--------+ +-----------------+ A| / | (p1.p2.p3.p4) | | | /+のためのアドレス-----+ | プロキシシステム| | | s. dmn2.com? / / \ | (p5.p6.p7.p8) | | | / / \ +-----------------+ | | / / \ | | | //s.dmn2.com? | | | | +--------+ / | +--------+ | +-------->| DNS|--+ +-------+ | /IP\| | サーバ| / \ | + ネットワーク++------------| X| <、-、--+ + | \/s1.s2.s3.s4+--------+ s1.s2.s3.s4| | +--------+ | | | | + | | \ +--------+ + +->| DNS| \ | サーバ| +----| Y| +--------+
NOTE: In practice, DNS servers that are authoritative for
s.dmn2.com are highly likely to be located on the OTHER
side of the proxy system. This means that DNS queries
from the inside to the outside MUST be able to cross the
proxy system. If the proxy system wishes to provide
"address hiding", it must make these DNS queries
(originating from the inside) appear to come from the
proxy itself. This can be achieved by using a BIND-based
DNS server (which has some proxy capabilities) or some
simpler DNS proxy program. For full RFC compliance,
the proxy system must be able to relay TCP-based queries
just like UDP-based queries, since some client systems
are rumored to ONLY use TCP for DNS queries.
以下に注意してください。 実際には、s.dmn2.comに、正式のDNSサーバはプロキシシステムのOTHER側面で非常に位置されそうです。 これは、内部から外部までのDNS質問がプロキシシステムに交差できなければならないことを意味します。 プロキシシステムが「アドレス隠れること」を提供したいなら、それで、これらのDNS質問(内部から、発する)はプロキシ自体から来るように見えなければなりません。 BINDベースのDNSサーバ(いくつかのプロキシ能力を持っている)かあるより簡単なDNSプロキシプログラムを使用することによって、これを達成できます。 完全なRFCコンプライアンスにおいて、プロキシシステムはまさしくUDPベースの質問のようなTCPベースの質問をリレーできなければなりません、いくつかのクライアントシステムがDNS質問にTCPを使用するだけであると噂されているので。
The proxy system must be able to detect and block several
classes of attacks based on DNS which (if nothing else)
may cause denial of service:
プロキシシステムは、サービスの否定を引き起こすかもしれない(他に何もであるなら)DNSに基づく数人のクラスの攻撃を、検出して、妨げることができなければなりません:
a) attempts from the outside to return corrupt cache
entries to an internal DNS server
b) attempts to return DNS bindings which have no
relationship to the actual DNS query (some DNS
servers are vulnerable to this). The attacker's goal
may be to prime the cache of internal DNS servers with
a) 外部からリターンまでの試みはサーバb)が実際のDNS質問との関係を全く持っていないリターンDNS結合に試みる内部のDNSにキャッシュエントリーを崩壊させます(いくつかのDNSサーバがこれに被害を受け易いです)。 目標が内部のDNSサーバのキャッシュを用意することになっているかもしれない攻撃者のもの
Chatel Informational [Page 22] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[22ページ]のRFC1919
interesting entries, including entries for internal
DNS names that point to external IP addresses...
c) data-driven stuff similar in style to the "syslog
buffer overrun" type attacks.
おもしろいエントリー、外部のIPアドレスc)を…示す内部のDNS名のためのエントリーを含んでいて、スタイルにおいて「syslogバッファ超過」タイプと同様のデータ駆動型ものは攻撃されます。
Once the client system knows the IP address of the server system,
it attempts to establish a connection to the standard FTP
"control" TCP port on the server (port 21). For this to work, the
client system must have a valid route for the server's IP address
THAT LEADS TO THE PROXY SYSTEM, and the proxy system must have a
valid route for the client's IP address and the server's IP
address. All intermediate devices that behave like IP gateways
must have valid routes for the client, the server, and usually the
proxy. If these devices perform packet filtering, they must ALL
allow the specific type of traffic required between C and S for
this specific application.
クライアントシステムがいったんサーバシステムのIPアドレスを知っていると、それは、「コントロール」TCPがサーバで移植する標準のFTPに取引関係を築くのを試みます(21を移植してください)。 クライアントシステムには、これが働くように、サーバのIPアドレスTHAT LEADS TO THE PROXY SYSTEMに、有効なルートがなければなりません、そして、プロキシシステムには、クライアントのIPアドレスとサーバのIPアドレスのための有効なルートがなければなりません。 IPゲートウェイのように反応するすべての中間的デバイスがクライアント、サーバ、および通常プロキシに、有効なルートを持たなければなりません。 これらのデバイスがパケットフィルタリングを実行するなら、それらはこの特定のアプリケーションのためのCとSの間で必要であるトラフィックの特定のタイプをすべて許容しなければなりません。
A
route to S |
|
+-----------------+
+---------------+ | (p5.p6.p7.p8) |
| c.dmn1.com | | proxy system |
| (c1.c2.c3.c4) | | (p1.p2.p3.p4) |
+---------------+ +-----------------+
| | | |
| | route to S route to C | |
| V V |
| |
| A | A
| | route to C | | route to S
| | | |
| | C S C | |
+----+ <-- +----+ --> +----+ <-- +----+
| G1 |--------| Gx |--------| Gy |---------| Gn |
+----+ --> +----+ <-- +----+ --> +----+
S C S
Sへのルート| | +-----------------+ +---------------+ | (p5.p6.p7.p8) | | c. dmn1.com| | プロキシシステム| | (c1.c2.c3.c4) | | (p1.p2.p3.p4) | +---------------+ +-----------------+ | | | | | | CへのSルートへのルート| | | V V| | | | A| A| | Cへのルート| | Sへのルート| | | | | | C S C| | +----+<--+----+-->+----+<--+----+ | G1|--------| Gx|--------| Gy|---------| Gn| +----+-->+----+<--+----+-->+----+ S C S
At the start of the FTP session, a TCP packet with a source
address of C and a destination address of S travels to the proxy
system, expecting to cross it just like a normal IP gateway.
FTPセッションの始めでは、CのソースアドレスとSの送付先アドレスがあるTCPパケットはプロキシシステムに移動します、まさしく正常なIPゲートウェイのようにそれに交差すると予想して。
This is when the transparent proxy shows its magic:
これは透明なプロキシが魔法を示している時です:
The proxy's TCP/IP software stack sees this incoming packets (and
subsequent ones) for a destination address that is NOT one of its
own addresses. Based on some criteria (a configuration file, for
プロキシのTCP/IPソフトウェア・スタックはそれ自身のアドレスの1つでない送付先アドレスに関してこの入って来るパケット(そして、その後のもの)を見ます。 いくつかの評価基準に基づいている、(構成ファイル
Chatel Informational [Page 23] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[23ページ]のRFC1919
example), it decides NOT to forward or drop the packet (which are
the only two choices an RFC-standard TCP/IP implementation would
have). The proxy system accepts the packet as if it was directed
to one of its own IP addresses.
例)、それは、パケットを進めるか、または下げるためにNOTについて決めます(RFC標準のTCP/IPインプリメンテーションが持っている唯一の2つの選択です)。 まるでそれがそれ自身のIPアドレスの1つに向けられるかのようにプロキシシステムはパケットを受け入れます。
In our example, the incoming packet is a TCP packet. Since
standard TCP/IP stacks store both a LOCAL and REMOTE IP address
field for each TCP connection, the transparent proxy may set the
LOCAL IP address field to the IP address that the client wants to
reach (s1.s2.s3.s4 in our example). The standard TCP/IP stack
probably needs to be modified to do this. UDP examples, although
not connection-based, could be handled in similar ways.
私たちの例では、入って来るパケットはTCPパケットです。 標準のTCP/IPスタックがそれぞれのTCP接続のためにLOCALとREMOTE IPアドレス・フィールドの両方を保存するので、透明なプロキシはクライアントが達したがっているIPアドレス(私たちの例のs1.s2.s3.s4)にLOCAL IPアドレス・フィールドを設定するかもしれません。 標準のTCP/IPスタックは、たぶんこれをするように変更される必要があります。 接続ベースではありませんが、同様の方法でUDPの例を扱うことができました。
Once this is done, the actual FTP proxy application is invoked
since an incoming connection to TCP port 21 has occurred. It can
determine what is the final target destination instantly, since
the LOCAL IP address field of the connection contains the target
server's IP address. There is no need for the proxy application
to ask the client what is the final target system.
これがいったん完了していると、TCPポート21への接続要求が起こったので、実際のFTPプロキシアプリケーションは呼び出されます。 それは、何が即座に最終的な目標の目的地であるかを決定できます、接続のLOCAL IPアドレス・フィールドが目標サーバのIPアドレスを含んでいるので。 プロキシアプリケーションが何が最終的な目標システムであるかをクライアントに尋ねる必要は全くありません。
Since the FTP proxy application knows the IP address of the target
system, it can choose to do two things:
FTPプロキシアプリケーションが目標システムのIPアドレスを知っているので、2つのことをするのを選ぶことができます:
a) Setup a session to the final target system, the more
frequent case.
a) 最終的な目標システムへのセッション、より頻繁なケースをセットアップしてください。
b) Decide (based on some internal configuration data) that it
cannot reach the final target system directly, but must go
through a "classical" proxy. This seems technically
feasible, although no real transparent proxy system is
known to offer this capability. The actual value of such
a feature (if available) would need to be studied.
b) 直接最終的な目標システムに達することができませんが、「古典的な」プロキシを通らなければならないと決めてください(いくつかの内部のコンフィギュレーション・データに基づいています)。 どんな全く見え透いたプロキシシステムもこの能力を提供するのが知られませんが、これは技術的に可能に思えます。 そのような特徴(利用可能であるなら)の実価は、研究される必要があるでしょう。
If the FTP proxy decides to connect directly to the target system,
it has the target system's IP address. It may choose to do a
reverse lookup on the target IP address to obtain a target system
name (possibly needed for access control). If this process
involves DNS resolution, something like the following will happen:
FTPプロキシが、直接目標システムに接続すると決めるなら、それには、目標システムのIPアドレスがあります。 それは、目標システム名(ことによると、アクセスコントロールに必要である)を得るために目標IPアドレスで逆のルックアップをするのを選ぶかもしれません。 以下が起こるようにこのプロセスがDNS解決にかかわるなら:
Chatel Informational [Page 24] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[24ページ]のRFC1919
+-----------------+
| proxy1.dmn3.com |
| (p1.p2.p3.p4) | +--------+
| | / IP \
| proxy2.dmn4.com |--------+ network(s) +------------+
| (p5.p6.p7.p8) | \ / |
+-----------------+ +--------+ +---------------+
A | / \ | (s1.s2.s3.s4) |
| | name for / \ | s.dmn2.com |
| | s1.s2.s3.s4? / \ | |
| | / \ +---------------+
| | / \
| | / \
| | +--------+ s1.s2.s3.s4? +--------+
| +-------->| DNS |------------------>| DNS |
| | server | | server |
+------------| X |<------------------| Y |
s.dmn2.com +--------+ s.dmn2.com +--------+
+-----------------+ | proxy1.dmn3.com| | (p1.p2.p3.p4) | +--------+ | | /IP\| proxy2.dmn4.com|--------+ ネットワーク+------------+ | (p5.p6.p7.p8) | \ / | +-----------------+ +--------+ +---------------+ A| / \ | (s1.s2.s3.s4) | | | \を/にちなんで命名してください。| s. dmn2.com| | | s1.s2.s3.s4? / \ | | | | / \ +---------------+ | | / \ | | / \ | | +--------+ s1.s2.s3.s4? +--------+ | +-------->| DNS|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| DNS| | | サーバ| | サーバ| +------------| X| <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、| Y| s. dmn2.com+--------+ s.dmn2.com+--------+
Once this is done and if the connection is allowed, the proxy
attempts to establish a connection to the standard FTP "control"
TCP port on the target server (port 21), using a technique
identical to a "classical" proxy. For this to work, the proxy
system must have a valid route to the server's IP address, and the
server system must have a valid route to at least one of the
proxy's IP address. All intermediate devices that behave like IP
gateways must have valid routes to both the proxy and the server.
If these devices perform packet filtering, they must ALL allow the
specific type of traffic required between the proxy and S for this
specific application.
一度、これは終わっています、そして、接続が許されているなら、プロキシは「コントロール」TCPが目標サーバで移植する標準のFTPに取引関係を築くのを試みます(21を移植してください)、「古典的な」プロキシに、同じテクニックを使用して。 これが働くように、プロキシシステムはサーバのIPアドレスに有効なルートを持たなければなりません、そして、サーバシステムには、有効なルートが少なくともプロキシのIPアドレスの1つまでなければなりません。 IPゲートウェイのように反応するすべての中間的デバイスがプロキシとサーバの両方に有効なルートを持たなければなりません。これらのデバイスがパケットフィルタリングを実行するなら、それらはこの特定のアプリケーションのためのプロキシとSの間で必要であるトラフィックの特定のタイプをすべて許容しなければなりません。
Chatel Informational [Page 25] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[25ページ]のRFC1919
+-----------------+
| proxy1.dmn3.com |
| (p1.p2.p3.p4) |
| | +----------------+
| proxy2.dmn4.com | | s.dmn2.com |
| (p5.p6.p7.p8) | | (s1.s2.s3.s4) |
+-----------------+ +----------------+
| | | |
| | route to S route to P2 | |
| V V |
| |
| A | A
| | route to P2 | | route to S
| | | |
| | P2 S P2 | |
+----+ <-- +----+ --> +----+ <-- +----+
| G1 |--------| Gx |--------| Gy |---------| Gn |
+----+ --> +----+ <-- +----+ --> +----+
S P2 S
+-----------------+ | proxy1.dmn3.com| | (p1.p2.p3.p4) | | | +----------------+ | proxy2.dmn4.com| | s. dmn2.com| | (p5.p6.p7.p8) | | (s1.s2.s3.s4) | +-----------------+ +----------------+ | | | | | | P2へのSルートへのルート| | | V V| | | | A| A| | P2へのルート| | Sへのルート| | | | | | P2 S P2| | +----+<--+----+-->+----+<--+----+ | G1|--------| Gx|--------| Gy|---------| Gn| +----+-->+----+<--+----+-->+----+ S P2 S
The rest of the transparent proxy's operation is very similar to
what would happen with a classical proxy.
透明なプロキシの操作の残りは古典的なプロキシと共に起こることと非常に同様です。
4.2 Characteristics of transparent proxy configurations
4.2 透明なプロキシ構成の特性
Transparent proxy technology can be used to build the key
component of a "firewall", in a way quite similar to the way
classical proxy technology may be used. Several important details
of the architecture must be different, however.
見え透いたプロキシ技術は使用されて、道の古典的なプロキシ技術と全く同様の方法で「ファイアウォール」の主要なコンポーネントを築き上げるのに、使用されるかもしれないということであるかもしれません。 しかしながら、アーキテクチャのいくつかの重要な詳細が異なっているに違いありません。
4.2.1 IP addressing and routing requirements
4.2.1 IPアドレシングとルーティング要件
The transparent proxy system must be able to address all client
and server systems to which it may provide service. It must
also know valid IP routes to all these client and server
systems.
見え透いたプロキシシステムはそれがサービスを供給するかもしれないすべてのクライアントとサーバシステムに演説できなければなりません。 また、それはこれらのすべてのクライアントとサーバシステムに有効なIPルートを知らなければなりません。
Server systems must be able to address the proxy system, and
must know a valid IP route to the proxy system. If the proxy
system has several IP addresses (and often, several physical
network interfaces), the server systems need only to be able to
access ONE of the proxy system's IP addresses.
サーバシステムは、プロキシシステムを扱うことができなければならなくて、有効なIPルートをプロキシシステムに知らなければなりません。 プロキシシステムにいくつかのIPアドレス(そして、しばしばいくつかの物理ネットワークインタフェース)があるなら、サーバシステムは、単にプロキシシステムのIPアドレスのONEにアクセスできる必要があります。
Client systems MUST HAVE valid IP addressing and routing
information for systems that they reach through the proxy. For
example, in the common case where a transparent proxy is being
used to interconnect a private network and the Internet, the
それらがプロキシを通して達するシステムのための情報を扱って、発送するクライアントシステムのMUST HAVEの有効なIP。 例えばよくある例で中透明なプロキシが私設のネットワークとインターネットとインタコネクトするのに使用されている
Chatel Informational [Page 26] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[26ページ]のRFC1919
private network will effectively need to use a default route
that points to the transparent proxy system. This is a specific
need of transparent proxy configurations.
事実上、私設のネットワークは、見え透いたプロキシシステムを示すデフォルトルートを使用する必要があるでしょう。 これは透明なプロキシ構成の特定の必要性です。
Interconnecting two internetworks with multiple transparent
proxies (for load sharing or fail-over) can be accomplished by
using different techniques from what would be done for
classical proxies:
古典的なプロキシのために行われることと異なったテクニックを使用することによって、複数の透明なプロキシ(負荷分割法かフェイルオーバーのための)と共に2つのインターネットワークとインタコネクトするのを達成できます:
a) with multiple classical proxies to the same remote
network, clients can be configured to access different
proxies manually, or DNS-based techniques, such as
DNS load-balancing may be used to make clients
access a different proxy at different times.
a) 同じリモートネットワークへの複数の古典的なプロキシで、手動で異なったプロキシにアクセスするためにクライアントを構成できますか、またはクライアントをいろいろな時間に異なったプロキシにアクセスさせるのにDNS負荷分散などのDNSベースのテクニックは、使用されるかもしれません。
b) with multiple transparent proxies to the same remote
network, the internal network must be able to provide
dynamic routing towards the proxies (routing updates
may need to be supplied by the proxies themselves).
Client systems (depending on topology) may not need
to see the route changes, but internal backbone
routers probably do.
同じリモートネットワークへの内部のネットワークの複数の透明なプロキシがあるb)はプロキシに向かってダイナミックルーティングを提供できなければなりません(ルーティングアップデートは、プロキシによって自分たちで供給される必要があるかもしれません)。 クライアントシステム(トポロジーによる)はルート変化を見る必要はないかもしれませんが、内部のバックボーンルータはたぶんします。
It is clear that internetworks linked by a transparent proxy
cannot be fully isolated from each other in an IP addressing
and routing sense. The network on which client systems are
located must have effective valid routing entries to the remote
internetwork; these routing entries must point to the proxy.
互いからIPアドレシングとルーティング意味で透明なプロキシによってリンクされたインターネットワークは完全に隔離できるというわけではないのが明確です。 クライアントシステムが見つけられているネットワークは有効な有効なルーティングエントリーをリモートインターネットワークに持たなければなりません。 これらのルーティングエントリーはプロキシを示さなければなりません。
The transparent proxy system (if running a vaguely standard
TCP/IP software stack) needs to have a single coherent view of
IP addressing and routing. If a proxy system interconnects two
IP networks and two systems use the same IP network/subnetwork
number (one system on each internetwork), the proxy will only
be able to address one of the systems. Even if the proxy is
able to manage multiple conflicting IP universes (if, for
example, one instance of a complete TCP/IP stack and its data
structures is bound to each of the proxy network interfaces),
the client systems will still have a problem: Why should it
send packets with this network number to the proxy since this
network number exists also on the internal internetwork?
見え透いたプロキシシステム(ばく然と標準のTCP/IPソフトウェア・スタックを動かすなら)はIPアドレシングとルーティングのただ一つの論理的な視点を必要とします。 プロキシシステムが2つのIPネットワークとインタコネクトして、2台のシステムが同じIPネットワーク/サブネットワーク番号(各インターネットワークの1台のシステム)を使用すると、プロキシはシステムの1つを扱うことができるだけでしょう。プロキシが複数の闘争しているIP宇宙に対処できても(例えば、完全なTCP/IPスタックとそのデータ構造の1つのインスタンスがそれぞれのプロキシネットワーク・インターフェースまで縛られるなら)、クライアントシステムには、それでも、問題があるでしょう: また、このネットワーク・ナンバーが内部のインターネットワークに存在しているので、それはなぜこのネットワーク・ナンバーと共にパケットをプロキシに送るべきですか?
Chaining transparent proxies does not seem at first glance to
solve IP conflicts like it does for classical proxies.
透明なプロキシを鎖でつなぐのは古典的なプロキシのためにするようにIP闘争を解決するように一見したところでは思えません。
From a "security" fail-safe point of view, the transparent
proxy has an undesirable characteristic: the network being
protected must have valid routing entries to the remote
「セキュリティ」フェールセイフの観点から、透明なプロキシには、望ましくない特性があります: 保護されるネットワークは有効なルーティングエントリーをリモートにしなければなりません。
Chatel Informational [Page 27] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[27ページ]のRFC1919
network(s). If the proxy fails (starts behaving like a non-
filtering IP router) or is physically bypassed, it is likely
that the internal network will be immediately able to reply to
"attacker" packets. The attacker does not need to modify
routing tables or to spoof internal IP addresses.
(s)をネットワークでつないでください。 プロキシが失敗するか(非フィルタリングのIPルータのように振る舞い始めます)、または物理的に迂回すると、内部のネットワークはすぐに、「攻撃者」パケットに答えることができそうでしょう。 攻撃者は、経路指定テーブルを変更するか、または内部のIPアドレスを偽造する必要はありません。
This is important for organizations that do not wish to place
ALL their confidence and protection into a proxy system (for
whatever reason).
プロキシシステム(いかなる理由によるも)に彼らのすべての信用と保護を置きたがっているというわけではない組織に、これは重要です。
4.2.2 IP address hiding
4.2.2 IPアドレス隠れること
Application "sessions" that go through a transparent proxy are
actually made of two complete sessions:
透明なプロキシを通るアプリケーション「セッション」が実際に2つの終了しているセッションで作られています:
a) a session between the client and the address of the
server, the session being "intercepted" by the proxy
b) a session between the proxy and the server
a) プロキシb) プロキシとサーバとのセッションで「妨害される」クライアントとサーバのアドレス、セッションとのセッション
A device on the path sees either the client<->server traffic or
the proxy<->server traffic, depending where it is located. The
client<-"server" traffic is actually generated by the
transparent proxy. The two sessions SHOULD NEVER pass through
the same physical network, since in that case (due to the
routing requirements) a total bypass of the proxy at the IP
routing level may easily occur without being detectable.
それがどこに位置しているかによって、経路のデバイスはクライアントサーバートラフィックかプロキシ<の<->>のためにサーバートラフィックを見ます。 クライアント<-「サーバ」トラフィックは実際に透明なプロキシによって生成されます。 検出可能でなくて、IPルーティングレベルにおけるプロキシの総迂回がその場合(ルーティング要件のため)容易にそうするかもしれなくて以来のSHOULD NEVERが同じ物理ネットワークを通り抜ける2つのセッションが起こります。
Like classical proxies, transparent proxies accomplish a form
of IP address hiding. Client IP addresses are hidden from the
servers, since the servers see a session being initiated by the
proxy. Server IP addresses are NOT hidden from the clients
however, so that the illusion of transparency may be
maintained.
古典的なプロキシのように、透明なプロキシはIPアドレス隠れることのフォームを達成します。 サーバが、セッションがプロキシによって開始されているのを見るので、サーバクライアントIPアドレスを隠されます。 しかしながら、クライアント、透明の幻想を維持できるようにサーバIPアドレスを隠されません。
This difference implies that internal (client-side) network
statistics at the IP level will accurately reflect what outside
destinations are being accessed. This can be useful for
analyzing traffic patterns.
この違いは、IPレベルにおける内部(クライアント側)のネットワーク統計が、アクセスされているので外の目的地がものであることを正確に反映するのを含意します。 これはトラフィック・パターンを分析することの役に立つ場合があります。
4.2.3 DNS requirements
4.2.3 DNS要件
In transparent proxy configurations, client systems MUST be
able to resolve server names belonging to remote networks. This
is critical since the proxy will determine the target server
from the destination IP address of the packets arriving from
the client. Because of this, the "client" internetwork needs to
have some form of DNS interconnection to the remote network. If
internal client and name server IP addresses must be hidden
透明なプロキシ構成では、クライアントシステムはリモートネットワークに属すサーバー名を決議できなければなりません。 プロキシが送付先IPアドレスから目標サーバを決定するので、パケットがクライアントから到着するのにおいてこれは重要です。 これのために、「クライアント」インターネットワークは何らかのフォームのDNSインタコネクトをリモートネットワークに必要とします。 内部のクライアントとネームサーバIPアドレスを隠さなければならないなら
Chatel Informational [Page 28] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[28ページ]のRFC1919
from the outside, these DNS queries must also be proxied.
また、外部から、これらのDNS質問をproxiedしなければなりません。
Of course, remote host name/address relationships may be stored
locally on the client systems, but it is well known that such
an approach does not scale...
もちろん、リモートホスト名/アドレス関係はクライアントシステムの上に局所的に保存されるかもしれませんが、そのようなアプローチが比例しないのは、よく知られています…
Because of this, it can be said that a transparent proxy system
cannot offer DNS isolation. If two IP internetworks use
completely separate DNS trees (each with their own DNS root
servers), client software in one IP internetwork will not have
a way of finding name/address relationships in the "other" DNS
tree, and this information must be obtained in order to pass
the desired address to the transparent proxy.
これのために、見え透いたプロキシシステムがDNS分離を提供できないと言うことができます。 2つのIPインターネットワークが完全に別々のDNS木(それら自身のDNSルートサーバーがあるそれぞれ)を使用すると、1つのIPインターネットワークにおけるクライアントソフトウェアには、「他」のDNS木で名前/アドレス関係を見つける方法がないでしょう、そして、必要なアドレスを透明なプロキシに渡すためにこの情報を得なければなりません。
The classical proxy itself (if running standard DNS resolution
software) will not be able alone to resolve DNS names in both
environments, since it will need to point to one or the other
of the two DNS "universes". Running multiple instances of DNS
resolution software can allow the proxy to do this, however.
古典的なプロキシ(標準のDNS解決ソフトウェアを動かすなら)自体は単独でDNSが両方の環境で命名する決心にできるようにならないでしょう、2DNS「宇宙」の1かもう片方を示すのが必要であるので。 しかしながら、DNS解決ソフトウェアの複数の実行しているインスタンスで、プロキシはこれができます。
Because of the requirement placed on some form of DNS
communication through the proxy, it is critical for the proxy
to be able to protect ITSELF, internal clients, and internal
name servers from data-driven attacks at the DNS level.
プロキシを通した何らかのフォームに関するDNSコミュニケーションに置かれた要件のために、プロキシがデータ駆動型攻撃からDNSレベルでITSELF、内部のクライアント、および内部名サーバを保護できるのは、重要です。
4.2.4 Software requirements
4.2.4 ソフトウェア要件
The big advantage of transparent proxies is that normal client
software may access remote servers with no modifications and no
changes to user procedures.
透明なプロキシの大きい利点は正常なクライアントソフトウェアが変更にもかかわらず、ユーザ手順へのどんな変化なしでもリモートサーバにアクセスしないかもしれないということです。
The transparent proxy application itself may not need to be
more complicated than a classical proxy application.
わかりやすいプロキシアプリケーション自体は古典的なプロキシアプリケーションより複雑である必要はないかもしれません。
However, the proxy TCP/IP software stack cannot be a fully-
standard (well, today's standard at least) TCP/IP stack, and
requires specific extensions:
しかしながら、プロキシTCP/IPソフトウェア・スタックは、完全な標準(さて、今日は少なくとも標準である)のTCP/IPスタックであることができるというわけではなく、特定の拡大を必要とします:
a) the ability to specify ranges of IP addresses that
do not belong to the proxy itself, but for which
"intercept" processing will occur: if packets arrive
at the proxy with a destination IP address in those
ranges, the IP stack will not forward or drop the
packets; it will pass them up to application layers.
a) どれが処理を「妨害する」ようにプロキシ自体に属するのではなく、属するIPアドレスの範囲を指定する能力は起こるでしょう: 送付先IPアドレスがそれらの範囲にある状態でパケットがプロキシに到着すると、IPスタックは、パケットを進めもしませんし、下げもしないでしょう。 それはそれらを応用層まで通過するでしょう。
b) This mechanism requires that applications may obtain
both the IP address from which the packets come, and
the address to which the packets were going. Typical
b) このメカニズムは、アプリケーションがパケットが来るIPアドレスとパケットが行く予定であったアドレスの両方を得るかもしれないのを必要とします。 典型的
Chatel Informational [Page 29] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[29ページ]のRFC1919
IP stacks should already have the fields available
to store the info; it is a matter of updating them
properly for these "intercepted" packets.
IPスタックには、インフォメーションを保存するために利用可能な分野が既にあるはずです。 それはこれらの「妨害された」パケットのために適切にそれらをアップデートする問題です。
c) In the case of "intercepted" TCP packets, the TCP
stack must support establishing TCP connections
where the "local" IP address is not one of the
proxy's IP address.
c) 「妨害された」TCPパケットのケースでは、TCPスタックは「地方」のIPアドレスがプロキシのIPアドレスの1つでないところでTCP接続を設立にサポートしなければなりません。
Any TCP/IP software implementation should be modifiable to
perform these tasks. If a standard API becomes widely available
to drive these extensions, and if this API is generally
implemented, transparent proxies may become "portable"
applications.
どんなTCP/IPソフトウェア実行もこれらのタスクを実行するのにおいて修正できるべきです。 標準のAPIがこれらの拡大を追い立てるために広く利用可能になって、このAPIが一般に実装されるなら、透明なプロキシは「携帯用」のアプリケーションになるかもしれません。
Until this occurs, it must be assumed that implementors have
chosen different ways of accomplishing these functions, so that
today's transparent proxy applications cannot be fully
portable. It also remains to be seen how much work is needed to
propagate these "extensions" to IPV6 software stacks.
これが起こるまで、その今日のわかりやすいプロキシアプリケーションが完全に携帯用であるというわけではない場合があるために作成者がこれらの機能を達成する異なった方法を選んだと思わなければなりません。 また、どのくらいの仕事がこれらの「拡大」をIPV6ソフトウェア・スタックに伝播するのに必要であるかはまだ不明です。
4.2.5 Impact of a transparent proxy on packet filtering
4.2.5 パケットフィルタリングの透明なプロキシの影響
The nature of a transparent proxy's functionality makes it
difficult to deploy good packet filtering on the "inside" (or
client-side) of the proxy. The proxy will "masquerade" as all
the external systems. Because of this, internal packet filters
WILL TYPICALLY NEED TO ALLOW IP traffic between internal and
external IP addresses.
透明なプロキシの機能性の本質で、プロキシの“inside"(または、クライアント側)で良いパケットフィルタリングを配布するのは難しくなります。 プロキシはすべての外的システムとして「仮装するでしょう」。これのために、内部のパケットは内部の、そして、外部のIPアドレスの間のWILL TYPICALLY NEED TO ALLOW IPトラフィックをフィルターにかけます。
Depending on the actual security policy of the network, it may
be possible to do filtering based on protocol type and/or on
TCP bits (to filter based on connection setup direction), but
filtering that blocks external IP addresses CANNOT be deployed.
ネットワークの実際の安全保障政策によって、プロトコルタイプに基づいたTCPビットの上でフィルタリングをするのが可能であるかもしれませんが(接続設定方向に基づいてフィルターにかける)、それをブロックの外部のIPが扱うフィルターにかけるのは配布されません。
If the proxy starts behaving like an IP router, or if
physically bypassed, the practical limitations imposed on
internal packet filtering imply that a lot of direct traffic
between the inside and outside network will be allowed to flow.
Furthermore, as we have seen previously, the internal network
will have valid routing entries for external network numbers
that point to the proxy. If multiple proxies have been
deployed, the internal network may even HAVE TO TRUST routing
updates generated by the proxy.
プロキシがIPルータのように振る舞い始めるか、または物理的に迂回すると、内部のパケットフィルタリングに課された実用的な制限は内面の、そして、外のネットワークの間の多くのダイレクトトラフィックが流れるつもりであることができるでしょう。 その上と、周知のごとく以前、内部のネットワークには、プロキシを示す外部のネットワーク・ナンバーのための有効なルーティングエントリーがあるでしょう。 複数のプロキシが配布されたなら、内部のネットワークはプロキシによって生成されたHAVE TO TRUSTルーティングアップデートさえ配布されました。
In general, if an internal network wishes to communicate with
an external network through a transparent proxy, it MUST BE
FUNDAMENTALLY DESIGNED TO COMMUNICATE DIRECTLY with that
一般に、内部のネットワークは透明なプロキシを通して外部のネットワークとコミュニケートしたがっていて、それはそれがあるMUST BE FUNDAMENTALLY DESIGNED TO COMMUNICATE DIRECTLYです。
Chatel Informational [Page 30] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[30ページ]のRFC1919
external network. This is true at the IP addressing level, at
the IP routing level, and at the DNS level. A proxy security
failure in this type of environment is likely to result in
immediate, total, and undetected accessibility of the internal
network by the external network.
外部のネットワーク。 これは、IPルーティングレベルにおけるDNSレベルにおけるレベルを扱いながら、IPで本当です。 このタイプの環境におけるプロキシセキュリティ失敗は外部のネットワークで内部のネットワークの即座の、そして、総、そして、非検出されたアクセシビリティをもたらしそうです。
4.2.6 Interconnection of conflicting IP networks
4.2.6 IPがネットワークでつなぐ闘争のインタコネクト
Unlike classical proxies, transparent proxies do not readily
seem useful in solving IP addressing conflicts.
古典的なプロキシと異なって、透明なプロキシは容易に闘争を扱うIPを解決する際に役に立つように見えません。
If two internetworks use the same network number(s), systems
and routers in each internetwork will have valid routes to
these network numbers. If these routes are changed to point to
a transparent proxy, traffic that is meant to stay within the
same internetwork would start to flow towards the proxy. The
proxy will not be able to distinguish reliably between traffic
between systems of the same internetwork, and traffic which is
meant to cross the proxy.
2つのインターネットワークが同じネットワーク・ナンバーを使用すると、各インターネットワークにおけるシステムとルータには、有効なルートがこれらのネットワーク・ナンバーまであるでしょう。 透明なプロキシを示すためにこれらのルートを変えるなら、同じインターネットワークの範囲内にとどまることになっているトラフィックは、プロキシに向かって流れ始めるでしょう。 プロキシはプロキシに交差することになっている同じインターネットワーク、およびトラフィックのシステムの間のトラフィックを確かに見分けることができないでしょう。
A possible solution to this problem is described in section 6
of this document, "Improving transparent proxies".
「透明なプロキシを改良し」て、可能な解決はこのドキュメントのセクション6でこの問題に説明されます。
5. Comparison chart of classical and transparent proxies
5. 古典的で透明なプロキシの比較チャート
For those who do not like longish discussions of technical details, here is a one-page summary of the strengths/weaknesses/differences of classical and transparent proxies:
技術的詳細の長めの議論が好きでない人のために、古典的で透明なプロキシの強さ/弱点/違いの1ページの概要はここにあります:
-----------------------------------------------------------------
| Issue | Classical Proxy | Transparent Proxy |
|-------------------+---------------------+----------------------|
| IP addressing | systems/gateways on | systems/gateways on |
| | each network need | the "client" network |
| | to address the proxy| need to address the |
| | | remote networks |
| | | |
| IP routing | systems/gateways on | systems/gateways on |
| | each network need a | the "client" network |
| | valid routing entry | also need routing |
| | for the proxy | entries for remote |
| | | entries |
| | | |
| IP address hiding | systems on each side| systems on the |
| | of the proxy are | "client" side are |
| | hidden from each | hidden from the |
| | other | other sides |
| | | |
----------------------------------------------------------------- | 問題| 古典的なプロキシ| 透明なプロキシ| |-------------------+---------------------+----------------------| | IPアドレシング| システム/ゲートウェイ、オン| システム/ゲートウェイ、オン| | | それぞれのネットワークの必要性| 「クライアント」ネットワーク| | | プロキシに演説するために| 扱う必要性| | | | リモートネットワーク| | | | | | IPルーティング| システム/ゲートウェイ、オン| システム/ゲートウェイ、オン| | | 各ネットワークはaを必要とします。| 「クライアント」ネットワーク| | | 有効なルーティングエントリー| 必要性ルーティングも| | | プロキシのために| エントリー、リモート| | | | エントリー| | | | | | IPアドレス隠れること| それぞれの側の上のシステム| システム、オン| | | プロキシはそうです。| 「クライアント」側はそうです。| | | それぞれ隠されます。| 隠されます。| | | 他| 向こう側| | | | |
Chatel Informational [Page 31] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[31ページ]のRFC1919
| DNS | full isolation | resolution of outside|
| | possible | names by inside |
| | | systems is required |
| | | |
| Proxy software | runs on standard | requires special |
| requirements | TCP/IP stack; | TCP/IP stack; |
| | can be portable | not 100% portable |
| | | |
| Client software | requires proxy- | nothing more than for|
| requirements | capable software | a direct connection |
| | or user education | |
| | | |
| User requirements | must use proxy- | nothing more than for|
| | capable software or | a direct connection |
| | know how to use the | |
| | proxy | |
| | | |
| Packet filtering | can filter out | cannot filter out |
| | "external" addresses| "external" addresses |
| | | |
| IP address | can be done with | no obvious way to |
| conflict | chained proxies that| get this to work |
| resolution | support auto-connect| |
----------------------------------------------------------------
| DNS| 完全な分離| 外部の解決| | | 可能| 内部のそばの名前| | | | システムが必要です。| | | | | | プロキシソフトウェア| 規格で動きます。| 特別番組を必要とします。| | 要件| TCP/IPスタック。 | TCP/IPスタック。 | | | 携帯用である場合があります。| 携帯用の100%でない| | | | | | クライアントソフトウェア| プロキシを必要とします。| ただ| | 要件| できるソフトウェア| ダイレクト接続| | | または、ユーザ教育| | | | | | | ユーザ要件| 必須使用プロキシ| ただ| | | またはできるソフトウェア。| ダイレクト接続| | | どのようにが使用するかを知っています。| | | | プロキシ| | | | | | | パケットフィルタリング| だんだん知られることができます。| だんだん知られることができません。| | | 「外部」のアドレス| 「外部」のアドレス| | | | | | IPアドレス| 処理できます。| 当たり前の方法がありません。| | 闘争| プロキシを鎖でつなぐ、それ| これを働かせてください。| | 解決| サポート、自動、接続| | ----------------------------------------------------------------
6. Improving transparent proxies
6. 透明なプロキシを改良します。
The main issues with transparent proxies seem to revolve around the need to force "client" systems to directly access external addresses. To some people, this characteristic makes a transparent proxy look too much like a complicated packet filter. Can this problem be solved?
透明なプロキシの本題は「クライアント」システムを外部アドレスに直接アクセスさせる必要性を中心題目とするように思えます。 人から見たら、この特性で、透明なプロキシは複雑なパケットフィルタに似過ぎます。 この問題を解決できますか?
The first possibility that comes to mind is to use the flexibility of the DNS protocol to build new tricks. If we restrict the "internal" clients so that they MUST ALWAYS use DNS to resolve external host names AND THAT THEY MUST NEVER store permanent copies of external host addresses, the following technique would become theoretically possible (this is a very painful restriction, by the way):
思い浮かぶ最初の可能性は新しい手を築き上げるのにDNSプロトコルの柔軟性を使用することです。 したがって、私たちが「内部」のクライアントを制限する、それ、彼ら、MUST ALWAYSは外部のホスト名AND THAT THEY MUST NEVERが永久的なコピーの外部のホスト・アドレスを保存すると決議するのにDNSを使用して、以下のテクニックは理論的に可能になるでしょう(これが非常に苦痛な制限です、ところで):
a) arrange for all internal queries for external DNS names to
go to the transparent proxy system (this can be done in a
number of ways).
a) すべての内部の質問には、外部のDNS名が見え透いたプロキシシステムに行くように手配してください(多くの方法でこれができます)。
b) arrange for a routing entry to exist for a class A network
number that is not used on the internal network. This IMPLIES
that the internal network may not be part of the Internet. This
routing entry will point to the transparent proxy system. For
b) ルーティングエントリーが内部のネットワークで使用されないクラスAネットワーク・ナンバーのために存在するように手配してください。 内部がネットワークでつなぐこのIMPLIESはインターネットの一部でないかもしれません。 このルーティングエントリーは見え透いたプロキシシステムを示すでしょう。 for
Chatel Informational [Page 32] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[32ページ]のRFC1919
the purpose of our discussion, this special network number will
be X.0.0.0.
私たちの議論の目的、この特別なネットワーク・ナンバーはX.0.0にな.0るでしょう。
c) when an internal system generates a query for an external
address, the query (if no answer is cached on the internal
network) will reach the proxy system. Assuming the query is to
obtain the IP address corresponding to a domain name, the proxy
will go through the following algorithm:
c) 内部のシステムが外部アドレスのための質問を生成するとき、質問(答えが全く内部のネットワークでキャッシュされないなら)はプロキシシステムに達するでしょう。 質問がドメイン名に対応するIPアドレスを得ることであると仮定すると、プロキシは以下のアルゴリズムに直面するでしょう:
- try to find a valid binding for this external domain name in
its local cache
- ローカルなキャッシュにおけるこの外部のドメイン名のための有効な結合を見つけるようにしてください。
- if not found, it will ITSELF launch an external DNS query
for the domain name. When (and if) it receives a valid reply,
it creates a local cache entry containing:
- 見つけられないなら、それは外部のDNSがドメイン名のために質問するITSELF着手を望んでいます。 (and if)であるときに、有効な回答を受け取って、以下を含む地方のキャッシュエントリーを作成します。
Time To Live of the reply
Expiry Time of the cache entry (based on the current time)
External domain name
External IP address
Dynamically allocated IP address of the form X.x1.x2.x3.
キャッシュエントリー(現在の時間に基づいている)の外部のドメイン名External IPアドレスDynamicallyの回答Expiry Timeの時間To LiveはフォームX.x1.x2.x3のIPアドレスを割り当てました。
and returns to the client the dynamically allocated IP address
in the range X.0.0.0, NOT THE REAL ONE.
NOT THE REAL ONE、そして、ダイナミックに割り当てられたクライアントIPへのリターンは範囲でX.0.0.0を扱います。
- the client may (or may not) store the IP address returned in
its cache, and will then attempt to connect to the
dynamically allocated IP address. This traffic will arrive at
the proxy because of the routing setup.
- または、クライアントがそうするかもしれない、()、アドレスがキャッシュで返して、次にダイナミックに割り当てられたIPアドレスに関するのを試みるIPを保存するかもしれなくなってください。 このトラフィックはルーティングセットアップのためにプロキシに到着するでしょう。
- The transparent proxy intercepts the traffic and can identify
the actual desired target it should connect to based on the
dynamically allocated IP address supplied by the client.
- 透明なプロキシは、トラフィックを妨害して、それがクライアントによって供給されたダイナミックに割り当てられたIPアドレスに基づいて接続するべきである実際の必要な目標を特定できます。
Such an approach, if workable, could improve many characteristics of transparent proxies and may even make transparent proxies capable of handling IP network number conflicts.
そのようなアプローチで、実行可能であるなら透明なプロキシの多くの特性を改良して、透明なプロキシは取り扱いIPネットワーク・ナンバー闘争ができるようになりさえするかもしれません。
However, the algorithm above leaves many difficult questions unsolved. Here is a list (by no means exhaustive) of these questions:
しかしながら、上のアルゴリズムは多くの難問題を未解決でおきます。 ここに、これらの質問のリスト(決して徹底的でない)があります:
a) What is the percentage of client DNS resolver and DNS server
implementations that conform to the RFC specifications in their
handling of the Time-To-Live field?
a) クライアントDNSレゾルバと従うDNSサーバ実装対彼らの生きるTime分野の取り扱いにおけるRFC仕様の割合はどのくらいですか?
b) How should the proxy handle other types of DNS queries for
external domain names (inverse queries, queries for other
resource record types)?
b) プロキシはどのように外部のドメイン名のための他のタイプのDNS質問を扱うべきですか?(逆さの質問、他のリソースのための質問はタイプを記録します)
Chatel Informational [Page 33] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[33ページ]のRFC1919
c) A client program may perform a DNS query once for an external
name and then use the response for a long time (a large file
transfer, or a permanent management session, for example).
Should the proxy update the Expiry Time of cache entries based
on the passing IP traffic, and if so, using what algorithm?
c) クライアントプログラムは、外部名のために一度DNS質問を実行して、次に、長い間、応答を使用するかもしれません(例えば、大きいファイル転送、または永久的な管理セッション)。 プロキシが一時的なIPトラフィックに基づくキャッシュエントリーについてExpiry Timeをアップデートして、そうだとすれば、何を使用して、アップデートするべきである、アルゴリズム?
d) What new types of attacks would such a system introduce or
make possible?
d) どんな新しいタイプの攻撃は、そのようなシステムで、可能に導入しますか、なるでしょうか?
e) What data structures and resources (memory, disk) would be
needed for an efficient implementation if the proxy must sustain
a high rate of DNS queries for external names, and where a large
number of different external names are referenced? The class A
network number is used basically to reference cache entries.
Would a 24-bit address space be sufficient for practical use?
e) プロキシが外部名のための高い率のDNS質問を支えなければならなくて、多くの異なった外部名が参照をつけられるところでどんなデータ構造とリソース(メモリ、ディスク)が効率的な実装に必要でしょうか? クラスAネットワーク・ナンバーは基本的に参照キャッシュエントリーに使用されます。 24ビットのアドレスのスペースは実用に十分でしょうか?
f) What happens with the cache (and the functionality) if the proxy
crashes or reboots?
f) プロキシがダウンするか、またはリブートするなら、何がキャッシュ(そして、機能性)で起こりますか?
Such a system would probably exhibit two types of intermittent failures:
そのようなシステムはたぶん2つのタイプのインタミッテント故障を示すでしょう:
a) a client system is still using the result of an external name
query (some X.x1.x2.x3 address dynamically allocated by the
proxy), but this binding no longer exists in the proxy's cache.
The client attempts a connection to this address, which fails.
a) クライアントシステムはまだ外部名質問(プロキシによってダイナミックに割り当てられた何らかのX.x1.x2.x3アドレス)の結果を使用していますが、この結合はもうプロキシのキャッシュでは存在していません。 クライアントはこのアドレスに接続を試みます。(それは、失敗します)。
b) a client's name cache contains a binding for X.x1.x2.x3, but the
proxy has already reused this address for a different external
host name. The client attempts a connection to this address,
sees no obvious errors, but reaches a different system from the
expected one.
b) クライアントの名前キャッシュはX.x1.x2.x3のための結合を含んでいますが、プロキシは異なった外部のホスト名のために既にこのアドレスを再利用しました。 クライアントは、このアドレスに接続を試みますが、どんな明白な誤りも見ませんが、予想されたものから異系統に達します。
If somebody has ever implemented such a scheme, information and live experience in deploying it would be useful to the IP networking community.
だれかが今までにそのような体系を実装したことがあるなら、それを配布する情報とライブ経験はIPネットワーク共同体の役に立つでしょう。
7. Security Considerations
7. セキュリティ問題
Most of this document is concerned with security implications of classical and transparent proxy technology.
このドキュメントの大部分は古典的で見え透いたプロキシ技術のセキュリティ含意に関係があります。
8. Acknowledgements
8. 承認
I could not have written this document without the support of Digital Equipment Corporation for whom I work as a consultant.
私は私がコンサルタントとして働いているDECのサポートなしでこのドキュメントを書くことができませんでした。
Chatel Informational [Page 34] RFC 1919 Classical versus Transparent IP Proxies March 1996
1996年の透明なIPプロキシ行進に対して古典的なシャテル情報[34ページ]のRFC1919
9. References
9. 参照
[1] Cheswick, W., Bellovin, S., "Firewalls and Internet Security:
Repelling the Wily Hacker", Addison-Wesley, 1994.
[1] チェスウィック、W.、Bellovin、S.、「ファイアウォールとインターネットセキュリティ:」 「陰険なハッカーを退けます」、アディソン-ウエスリー、1994。
[2] Chapman, B., Zwicky, E., "Building Internet Firewalls",
O'Reilly and Associates, Inc., September 1995.
[2] チャップマン、B.、ツウィッキー、E.、「ビルインターネットファイアウォール」、オライリー、および仲間Inc.、9月1995日
[3] Comer, D., "Internetworking with TCP/IP volume 1: Principles,
Protocols, and Architecture", Prentice-Hall, 1991.
[3] 新来者、D.、「第1TCP/IP巻があるインターネットワーキング:」 新米のホールの「原則、プロトコル、およびアーキテクチャ」、1991
[4] Comer, D., Stevens, D., "Internetworking with TCP/IP volume 2:
"Design, Implementation, and Internals", Prentice-Hall, 1991.
[4] 新来者、D.、スティーブンス、D.、「第2TCP/IP巻があるインターネットワーキング:」 新米のホールの「デザイン、実装、およびインターナル」、1991
[5] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
STD 9, RFC 959, USC/Information Sciences Institute, October
1985.
[5] ポステル、J.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、科学が1985年10月に設けるUSC/情報。
[6] Huitema, C., "An experiment in DNS Based IP Routing", RFC 1383,
INRIA, December 1992.
[6]Huitema、C.、「DNS Based IPルート設定における実験」、RFC1383、INRIA、1992年12月。
[7] Rekhter Y., Moskowitz B., Karrenberg D., de Groot, G.,
"Address Allocation for Private Internets", RFC 1597,
IBM Corp., Chrysler Corp, RIPE NCC, March 1994.
[7] Rekhter Y.、マスコウィッツB.、Karrenberg D.、deグルート(G.)は「個人的なインターネットのための配分を扱います」、RFC1597、IBM社、クライスラーCorp、RIPE NCC、1994年3月。
[8] The TIS firewall toolkit's documentation, available on
Trusted Information System's anonymous FTP site, ftp.tis.com.
[8] TISファイアウォールツールキットのTrusted情報システムの公開FTPサイト、ftp.tis.comで利用可能なドキュメンテーション。
[9] Many discussions in the last 18 months on the firewalls-digest
mailing list maintained by Great Circle Associates. The
archives of the list are maintained at ftp.greatcircle.com.
[9] すばらしいCircle Associatesによって維持されたファイアウォールダイジェストメーリングリストのここ18カ月で多くの議論。 リストのアーカイブはftp.greatcircle.comで維持されます。
Author's Address
作者のアドレス
Marc Chatel 9, avenue Jean Monnet 74940 ANNECY-LE-VIEUX FRANCE
マーク・シャテル9、大通りジーンモネ74940アヌシー-LE-VIEUX FRANCE
EMail: mchatel@pax.eunet.ch or at Digital Equipment: Marc.Chatel@aeo.mts.dec.com
メール: mchatel@pax.eunet.ch かデジタル・イクイップメントで: Marc.Chatel@aeo.mts.dec.com
Chatel Informational [Page 35]
シャテル情報です。[35ページ]
一覧
スポンサーリンク
