Independent Submission P. Srisuresh
Request for Comments: 5684 EMC Corporation
Category: Informational B. Ford
ISSN: 2070-1721 Yale University
February 2010
Unintended Consequences of NAT Deployments
with Overlapping Address Space
Abstract
抽象
This document identifies two deployment scenarios that have arisen from the unconventional network topologies formed using Network Address Translator (NAT) devices. First, the simplicity of administering networks through the combination of NAT and DHCP has increasingly lead to the deployment of multi-level inter-connected private networks involving overlapping private IP address spaces. Second, the proliferation of private networks in enterprises, hotels and conferences, and the wide-spread use of Virtual Private Networks (VPNs) to access an enterprise intranet from remote locations has increasingly lead to overlapping private IP address space between remote and corporate networks. This document does not dismiss these unconventional scenarios as invalid, but recognizes them as real and offers recommendations to help ensure these deployments can function without a meltdown.
この文書では、ネットワークアドレス変換（NAT）デバイスを用いて形成された独創的なネットワークトポロジから生じた2つの展開シナリオを特定します。まず、NATとDHCPの組み合わせにより投与したネットワークの簡素化がますます重複プライベートIPアドレス空間を含むマルチレベル相互接続されているプライベートネットワークの展開につながるました。第二に、企業、ホテルや会議でのプライベートネットワークの普及、および遠隔地から企業のイントラネットにアクセスするための仮想プライベートネットワーク（VPN）の広範な使用はますますリモートと企業ネットワーク間のプライベートIPアドレス空間の重複につながりました。この文書では、無効としてこれらの型破りなシナリオを退けるが、実際としてそれらを認識し、これらの展開がメルトダウンせずに機能することができます確保するための推奨事項を提供していますしません。
Status of This Memo
このメモのステータス
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、独立して、他のRFCストリームの、RFCシリーズへの貢献です。 RFC Editorはその裁量でこの文書を公開することを選択し、実装や展開のためにその値についての声明を出すていません。 RFC編集者によって公表のために承認されたドキュメントは、インターネット標準の任意のレベルの候補ではありません。 RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5684.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5684で取得することができます。
Copyright
著作権
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http:trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントの発行日に有効な：（trustee.ietf.org/license-info HTTP）この文書では、BCP 78とIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
Table of Contents
目次
1. Introduction and Scope ..........................................3
2. Terminology and Conventions Used ................................4
3. Multi-Level NAT Network Topologies ..............................4
3.1. Operational Details of the Multi-Level NAT Network .........6
3.1.1. Client/Server Communication .........................7
3.1.2. Peer-to-Peer Communication ..........................7
3.2. Anomalies of the Multi-Level NAT Network ...................8
3.2.1. Plug-and-Play NAT Devices ..........................10
3.2.2. Unconventional Addressing on NAT Devices ...........11
3.2.3. Multi-Level NAT Translations .......................12
3.2.4. Mistaken End Host Identity .........................13
4. Remote Access VPN Network Topologies ...........................14
4.1. Operational Details of the Remote Access VPN Network ......17
4.2. Anomalies of the Remote Access VPNs .......................18
4.2.1. Remote Router and DHCP Server Address Conflict .....18
4.2.2. Simultaneous Connectivity Conflict .................20
4.2.3. VIP Address Conflict ...............................21
4.2.4. Mistaken End Host Identity .........................22
5. Summary of Recommendations .....................................22
6. Security Considerations ........................................24
7. Acknowledgements ...............................................24
8. References .....................................................25
8.1. Normative References ......................................25
8.2. Informative References ....................................25
The Internet was originally designed to use a single, global 32-bit IP address space to uniquely identify hosts on the network, allowing applications on one host to address and initiate communications with applications on any other host regardless of the respective host's topological locations or administrative domains. For a variety of pragmatic reasons, however, the Internet has gradually drifted away from strict conformance to this ideal of a single flat global address space, and towards a hierarchy of smaller "private" address spaces [RFC1918] clustered around a large central "public" address space. The most important pragmatic causes of this unintended evolution of the Internet's architecture appear to be the following.
インターネットはもともと、一意のネットワーク上のホストを識別するために単一のグローバル32ビットのIPアドレス空間を使用するように設計された1つのホスト上のアプリケーションに関係なく、それぞれのホストのトポロジー的位置の他のホスト上のアプリケーションとの通信に対処し、開始することができ、または管理されましたドメイン。実用的な様々な理由のために、しかし、インターネットは徐々にシングルフラットグローバルアドレス空間のこの理想的に厳密に準拠から離れて漂流し、大規模な中央の「公共の周りにクラスタ化された小さな「プライベート」アドレス空間[RFC1918]の階層に向けました「アドレス空間。インターネットのアーキテクチャのこの予期せぬ進化の最も重要な実用的な原因は、次のように見えます。
1. Depletion of the 32-bit IPv4 address space due to the exploding total number of hosts on the Internet. Although IPv6 promises to solve this problem, the uptake of IPv6 has in practice been slower than expected.
インターネット上のホストの爆発総数に対する32ビットのIPv4アドレス空間の1枯渇。 IPv6はこの問題を解決することを約束しますが、IPv6の取り込みは、実際には予想より遅くなっています。
2. Perceived Security and Privacy: Traditional NAT devices provide a filtering function that permits session flows to cross the NAT in just one direction, from private hosts to public network hosts. This filtering function is widely perceived as a security benefit. In addition, the NAT's translation of a host's original IP addresses and port number in a private network into an unrelated, external IP address and port number is perceived by some as a privacy benefit.
セキュリティとプライバシーを知覚2：従来のNATデバイスは、プライベートホストからパブリックネットワークホストに、ただ一つの方向にNATを横断するセッションフローを許可するフィルタリング機能を提供します。このフィルタリング機能は、広くセキュリティ上の利点として知覚されます。また、関係のない、外部IPアドレスとポート番号へのプライベートネットワーク内のホストの元のIPアドレスとポート番号のNATの翻訳は、プライバシー上の利益などの一部によって知覚されます。
3. Ease-of-Use: NAT vendors often combine the NAT function with a DHCP server function in the same device, which creates a compelling, effectively "plug-and-play" method of setting up small Internet-attached personal networks that is often much easier in practice for unsophisticated consumers than configuring an IP subnet. The many popular and inexpensive consumer NAT devices on the market are usually configured "out of the box" to obtain a single "public" IP address from an ISP or "upstream" network via DHCP ([DHCP]), and the NAT device in turn acts as both a DHCP server and default router for any "downstream" hosts (and even other NATs) that the user plugs into it. Consumer NATs in this way effectively create and manage private home networks automatically without requiring any knowledge of network protocols or management on the part of the user. Auto-configuration of private hosts makes NAT devices a compelling solution in this common scenario.
3.使いやすさ：NATベンダーは多くの場合、小さなインターネット接続されたパーソナルネットワークを設定するための説得力のある、効果的に「プラグアンドプレイ」方式を作成し、同じデバイスでDHCPサーバ機能とNAT機能を組み合わせIPサブネットを設定するよりも洗練されていない消費者のために実際には、多くの場合、はるかに簡単。市場には多くの人気と安価な民生用NATデバイスは、通常、DHCP（[DHCP]）を介してISPまたは「上流」ネットワークからのシングル「パブリック」IPアドレスを取得するために、「箱から出して」構成され、NATデバイスでされていますユーザーがそれに差し込むことを任意の「下流」のホスト（さらに他のNAT）用のDHCPサーバーとデフォルトルータの両方として機能をオンにします。このように消費者のNATは効果的に作成し、ユーザーの一部にネットワークプロトコルや管理の知識を必要とせずに自動的にプライベートホームネットワークを管理します。プライベートホストの自動設定は、NATデバイスにこの一般的なシナリオでは魅力的なソリューションになります。
[NAT-PROT] identifies various complications with application protocols due to NAT devices. This document acts as an adjunct to [NAT-PROT]. The scope of the document is restricted to the two
[NAT-PROTは】によるNATデバイスにアプリケーションプロトコルと様々な合併症を識別する。この文書では、[NAT-PROT]の補助として機能します。文書の範囲は2つに制限されています
scenarios identified in sections 3 and 4, arising out of unconventional NAT deployment and private address space overlap. Even though the scenarios appear unconventional, they are not uncommon to find. For each scenario, the document describes the seeming anomalies and offers recommendations on how best to make the topologies work.
セクション3と4で特定されたシナリオ、型破りなNAT展開とプライベートアドレス空間の重なりから生じます。シナリオは型破り表示されていても、彼らは見つけることは珍しくありません。各シナリオでは、文書は見せかけの異常を説明し、トポロジを動作させるために最善の方法に関する推奨事項を提供しています。
Section 2 describes the terminology and conventions used in the document. Section 3 describes the problem of private address space overlap in a multi-level NAT topology, the anomalies with the topology, and recommendations to address the anomalies. Section 4 describes the problem of private address space overlap with remote access Virtual Private Network (VPN) connections, the anomalies with the topology, and recommendations to address the anomalies. Section 5 describes the security considerations in these scenarios.
第2節では、文書内で使用される用語と表記規則について説明します。第3節では、マルチレベルのNATトポロジー、トポロジーでの異常、および異常に対処するための勧告でプライベートアドレス空間の重複の問題について説明します。第4章では、リモートアクセス仮想プライベートネットワーク（VPN）接続、トポロジでの異常、および異常に対処するための勧告にプライベートアドレス空間の重複の問題について説明します。第5節では、これらのシナリオにおけるセキュリティの考慮事項について説明します。
In this document, the IP addresses 192.0.2.1, 192.0.2.64, 192.0.2.128, and 192.0.2.254 are used as example public IP addresses [RFC5735]. Although these addresses are all from the same /24 network, this is a limitation of the example addresses available in [RFC5735]. In practice, these addresses would be on different networks.
この文書では、IPは、例えば、パブリックIPアドレス[RFC5735]として使用される192.0.2.1、192.0.2.64、192.0.2.128、192.0.2.254とに対処します。これらのアドレスは、同じ/ 24ネットワークからのすべてであるが、これは[RFC5735]で使用可能な例示的なアドレスの制限です。実際には、これらのアドレスは、異なるネットワーク上だろう。
Readers are urged to refer to [NAT-TERM] for information on NAT taxonomy and terminology. Unless prefixed with a NAT type or explicitly stated otherwise, the term NAT, used throughout this document, refers to Traditional NAT [NAT-TRAD]. Traditional NAT has two variations, namely, Basic NAT and Network Address Port Translator (NAPT). Of these, NAPT is by far the most commonly deployed NAT device. NAPT allows multiple private hosts to share a single public IP address simultaneously.
読者は、NATの分類と用語については、[NAT-TERM]を参照するように付勢されています。 NATタイプ接頭辞または特に明記しない限り、本書で使用される用語NATは、従来のNAT [NAT-TRAD]を参照します。従来のNATは2つのバリエーション、つまり、基本的なNATおよびネットワークアドレスポート翻訳（NAPT）を持っています。このうち、NAPTは、これまでで最も一般的に展開NATデバイスです。 NAPTは、複数のプライベートホストが同時に単一のパブリックIPアドレスを共有することができます。
Due to the pragmatic considerations discussed in the previous section and perhaps others, NATs are increasingly, and often unintentionally, used to create hierarchically interconnected clusters of private networks as illustrated in figure 1 below. The creation of multi-level hierarchies is often unintentional, since each level of NAT is typically deployed by a separate administrative entity such as an ISP, a corporation, or a home user.
実用前のセクションで説明した考慮事項と多分他の人に、NATはますますであり、しばしば意図せず、以下の図1に示すように、プライベートネットワークの階層的に相互接続されたクラスタを作成するために使用されます。 NATの各レベルは、通常、ISP、企業、または家庭ユーザーとして個別の管理エンティティによって展開されているので、マルチレベルの階層の作成は、多くの場合、意図的でないです。
Public Internet
(Public IP Addresses)
----+---------------+---------------+---------------+----
| | | |
| | | |
192.0.2.1 192.0.2.64 192.0.2.128 192.0.2.254
+-------+ Host A Host B +-------------+
| NAT-1 | (Alice) (Jim) | NAT-2 |
| (Bob) | | (CheapoISP) |
+-------+ +-------------+
10.1.1.1 10.1.1.1
| |
| |
Private Network 1 Private Network 2
(Private IP Addresses) (Private IP Addresses)
----+--------+---- ----+-----------------------+----
| | | | |
| | | | |
10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11 10.1.1.12
Host C Host D +-------+ Host E +-------+
| NAT-3 | (Mary) | NAT-4 |
| (Ann) | | (Lex) |
+-------+ +-------+
10.1.1.1 10.1.1.1
| |
| |
Private Network 3 | Private Network 4
(Private IP Addresses)| (Private IP Addresses)
----+-----------+---+ ----+-----------+----
| | | |
| | | |
10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11
Host F Host G Host H Host I
Figure 1. Multi-Level NAT Topology with Overlapping Address Space
重複アドレス空間を持つ図1.マルチレベルNATトポロジ
In the above scenario, Bob, Alice, Jim, and CheapoISP have each obtained a "genuine", globally routable IP address from an upstream service provider. Alice and Jim have chosen to attach only a single machine at each of these public IP addresses, preserving the originally intended architecture of the Internet and making their hosts, A and B, globally addressable throughout the Internet. Bob, in contrast, has purchased and attached a typical consumer NAT box. Bob's NAT obtains its external IP address (192.0.2.1) from Bob's ISP via DHCP, and automatically creates a private 10.1.1.x network for Bob's hosts C and D, acting as the DHCP server and default router for this private network. Bob probably does not even know anything about IP addresses; he merely knows that plugging the NAT into the Internet as instructed by the ISP, and then plugging his hosts into the NAT as the NAT's manual indicates, seems to work and gives all of his hosts access to Internet.
上記のシナリオでは、ボブ、アリス、ジム、とCheapoISPは、各アップストリームサービスプロバイダからグローバルにルーティング可能なIPアドレス、「本物」を取得しています。アリスとジムは、インターネットの本来のアーキテクチャを維持し、そのホスト、AとB、インターネットを通じてグローバルにアドレスを作り、これらのパブリックIPアドレスのそれぞれに単一のマシンのみを添付することを選択しました。ボブは、対照的に、典型的な消費者のNATボックスを購入し、添付しています。ボブのNATは、DHCP経由でボブのISPからその外部IPアドレス（192.0.2.1）を取得し、自動的にこのプライベートネットワークのDHCPサーバーとデフォルトルータとして動作し、ボブのホストCとDのプライベート10.1.1.xのネットワークを作成します。ボブはおそらくIPアドレスについては何も知りません。 NATのマニュアルは、示して動作しているようですし、彼のすべてのホストがインターネットにアクセスすることができますように彼は単にISPの指示に従って、インターネットへのNATを差し込む、その後、NATに彼のホストを差し込むことを知っています。
CheapoISP, an inexpensive service provider, has allocated only one or a few globally routable IP addresses, and uses NAT to share these public IP addresses among its many customers. Such an arrangement is becoming increasingly common, especially in rapidly developing countries where the exploding number of Internet-attached hosts greatly outstrips the ability of ISPs to obtain globally unique IP addresses for them. CheapoISP has chosen the popular 10.1.1.x address for its private network, since this is one of the three well-known private IP address blocks allocated in [RFC1918] specifically for this purpose.
CheapoISP、安価なサービスプロバイダは、1つまたは少数のグローバルにルーティング可能なIPアドレスを割り当てられ、その多くの顧客の間でこれらのパブリックIPアドレスを共有するためにNATを使用しています。このような構成は、特にインターネット接続ホストの爆発回数が大幅に彼らのためにグローバルに一意のIPアドレスを取得するためのISPの能力を上回っ急速に発展途上国では、ますます一般的になっています。これは特にこの目的のために[RFC1918]に割り当てられた3よく知られているプライベートIPアドレスブロックの1つであることからCheapoISPは、そのプライベートネットワークのための人気の10.1.1.xアドレスを選択しました。
Of the three incentives listed in section 1 for NAT deployment, the last two still apply even to customers of ISPs that use NAT, resulting in multi-level NAT topologies as illustrated in the right side of the above diagram. Even three-level NAT topologies are known to exist. CheapoISP's customers Ann, Mary, and Lex have each obtained a single IP address on CheapoISP's network (Private Network 2), via DHCP. Mary attaches only a single host at this point, but Ann and Lex each independently purchase and deploy consumer NATs in the same way that Bob did above. As it turns out, these consumer NATs also happen to use 10.1.1.x addresses for the private networks they create, since these are the configuration defaults hard-coded into the NATs by their vendors. Ann and Lex probably know nothing about IP addresses, and in particular they are probably unaware that the IP address spaces of their own private networks overlap not only with each other but also with the private IP address space used by their immediately upstream network.
NAT展開のためのセクション1に記載されている3つのインセンティブ、最後の二つはまだも上の図の右側に示すように、マルチレベルNATトポロジーをもたらす、NATを使用するISPの顧客に適用されます。でも、3レベルNATトポロジが存在することが知られています。 CheapoISPの顧客アン、メアリー、とレックスは、各DHCP経由して、CheapoISPのネットワーク（プライベートネットワーク2）上の単一のIPアドレスを取得しています。メアリーは、この時点では、単一のホストを添付しますが、アンとレックスは、それぞれ独立して、ボブは上記と同じ方法で、消費者のNATを購入して展開します。結局のところ、これらの消費者のNATはまた、これらはそのベンダーがNATのにハードコードされたコンフィギュレーションのデフォルトであるため、彼らが作成したプライベートネットワーク用の10.1.1.xアドレスを使用して起こります。アンとレックスはおそらくIPアドレスについて何も知らない、特に彼らはおそらく、自分のプライベート・ネットワークのIPアドレス空間が互いにだけでなく、彼らのすぐ上流のネットワークで使用されるプライベートIPアドレス空間だけではなく重複していることに気付いていません。
Nevertheless, despite this direct overlap, all of the "multi-level NATed hosts" -- F, G, H, and I in this case -- all nominally function and are able to initiate connections to any public server on the public Internet that has a globally routable IP address. Connections made from these hosts to the main Internet are merely translated twice: once by the consumer NAT (NAT-3 or NAT-44) into the IP address space of CheapoISP's Private Network 2 and then again by CheapoISP's NAT-2 into the public Internet's global IP address space.
それにもかかわらず、この直接オーバーラップにもかかわらず、「マルチレベルNAT変換ホスト」のすべて - F、G、H、及びIこの場合 - すべての名目関数とその公衆インターネット上の任意の公開サーバへの接続を開始することができますグローバルにルーティング可能なIPアドレスを持っています。公共のインターネットのにCheapoISPのNAT-2で再びCheapoISPのプライベートネットワーク2のIPアドレス空間に、消費者のNAT（NAT-3またはNAT-44）で一度：メインインターネットにこれらのホストから作られた接続は、単に二回変換されますグローバルIPアドレス空間。
In the "de facto" Internet address architecture that has resulted from the above pragmatic and economic incentives, only the nodes on the public Internet have globally unique IP addresses assigned by the official IP address registries. IP addresses on different private networks are typically managed independently -- either manually by the administrator of the private network itself, or automatically by the NAT through which the private network is connected to its "upstream" service provider.
上記の実用的かつ経済的なインセンティブに起因している「事実上の」インターネット・アドレスのアーキテクチャでは、公共のインターネット上の唯一のノードは、公式のIPアドレスレジストリによって割り当てられたグローバルに固有のIPアドレスを持っています。プライベートネットワークは、その「上流」のサービスプロバイダに接続されてNATにより、プライベートネットワーク自体、または自動の管理者が手動で - 異なるプライベートネットワーク上のIPアドレスは、典型的には、独立して管理されています。
By convention, nodes on private networks are usually assigned IP addresses in one of the private address space ranges specifically allocated to this purpose in RFC 1918, ensuring that private IP addresses are easily distinguishable and do not conflict with the public IP addresses officially assigned to globally routable Internet hosts. However, when plug-and-play NATs are used to create hierarchically interconnected clusters of private networks, a given private IP address can be and often is reused across many different private networks. In figure 1 above, for example, private networks 1, 2, 3, and 4 all have a node with IP address 10.1.1.10.
慣例により、プライベートネットワーク上のノードは通常、プライベートIPアドレスは容易に区別され、正式にグローバルに割り当てられたパブリックIPアドレスと競合しないことを保証し、プライベートアドレス空間の一つ、具体的RFC 1918で、この目的に割り当てられた範囲のIPアドレスが割り当てられていますルーティング可能なインターネットホスト。プラグアンドプレイのNATは、プライベートネットワークの階層的に相互接続されたクラスタを作成するために使用されている場合しかし、与えられたプライベートIPアドレスをすることができ、多くの場合、多くの異なるプライベートネットワークで再利用されます。上記図1において、例えば、プライベートネットワーク1、2、3、および4のすべては、IPアドレス10.1.1.10を持つノードを有します。
When a host on a private network initiates a client/server-style communication session with a server on the public Internet, via the server's public IP address, the NAT intercepts the packets comprising that session (usually as a consequence of being the default router for the private network), and modifies the packets' IP and TCP/UDP headers so as to make the session appear externally as if it were initiated by the NAT itself.
プライベートネットワーク上のホストは、サーバのパブリックIPアドレスを経由して、公共のインターネット上のサーバーとクライアント/サーバ形式の通信セッションを開始すると、NATは、通常のデフォルトルータであることの結果として、（そのセッションを備えたパケットを傍受しますプライベートネットワーク）、そしてそれはNAT自体によって開始されたかのように、セッションが外部に表示させるように、パケットのIPおよびTCP / UDPヘッダを変更します。
For example, if host C above initiates a connection to host A at IP address 192.0.2.64, NAT-1 modifies the packets comprising the session so as to appear on the public Internet as if the session originated from NAT-1. Similarly, if host F on private network 3 initiates a connection to host A, NAT-3 modifies the outgoing packet so the packet appears on private network 2 as if it had originated from NAT-3 at IP address 10.1.1.10. When the modified packet traverses NAT-2 on private network 2, NAT-2 further modifies the outgoing packet so as to appear on the public Internet as if it had originated from NAT-2 at public IP address 192.0.2.254. The NATs in effect serve as proxies that give their private "downstream" client nodes a temporary presence on "upstream" networks to support individual communication sessions.
ホストCは、上記のIPアドレス192.0.2.64でホストへの接続を開始する場合、例えば、NAT-1は、セッションがNAT-1に由来するかのように公共のインターネット上に表示するようにセッションを含むパケットを修正します。プライベートネットワーク上のホスト3 Fは、ホストへの接続を開始した場合、それがIPアドレス10.1.1.10でNAT-3に由来していたかのように、パケットがプライベートネットワーク2に表示されますので、同様に、NAT-3は、発信パケットを変更します。変更されたパケットは、プライベートネットワーク2上のNAT-2を横断するとき、それはパブリックIPアドレス192.0.2.254でNAT-2に由来していたかのように公共のインターネット上で表示されるように、NAT-2は、さらに発信パケットを変更します。実際にはNATは自分の秘密「下流」のクライアントは、個々の通信セッションをサポートするための「上流」ネットワーク上の一時的な存在感を与えるノードのプロキシとして機能します。
In summary, all hosts on the private networks 1, 2, 3, and 4 in figure 1 above are able to establish a client/server-style communication sessions with servers on the public Internet.
要約すると、図1中のすべてのプライベートネットワーク1、2、3上のホスト、および4は、上記の公共のインターネット上のサーバとクライアント/サーバ形式の通信セッションを確立することができます。
While this network organization functions in practice for client/server-style communication, when the client is behind one or more levels of NAT and the server is on the public Internet, the lack of globally routable addresses for hosts on private networks makes direct peer-to-peer communication between those hosts difficult. For example, two private hosts F and H on the network shown above might "meet" and learn of each other through a well-known server on the public Internet, such as host A, and desire to establish direct communication between G and H without requiring A to forward each packet. If G and H merely learn each other's (private) IP addresses from a registry kept by A, their attempts to connect to each other will fail because G and H reside on different private networks. Worse, if their connection attempts are not properly authenticated, they may appear to succeed but end up talking to the wrong host. For example, G may end up talking to host F, the host on private network 3 that happens to have the same private IP address as host H. Host H might similarly end up unintentionally connecting to host I.
クライアントがNATの1つ以上のレベルの背後にあると、サーバがパブリックインターネット上にある、プライベートネットワーク上のホストのグローバルルーティング可能なアドレスの不足が直接peer-を行い、クライアント/サーバ形式の通信のために実際には、このネットワーク組織化機能は、しばらく難しいそれらのホストの間のピアツーピア通信。例えば、2つのプライベート例えばホストAとして上記に示したネットワーク上のホストFとH「満たす」と公衆インターネット上でよく知られているサーバーを介してお互いを知るかもしれない、とすることなく、GとHとの間の直接通信を確立したいという願望各パケットを転送するためにAを必要とします。 GとHは、単にAが保管し、レジストリから互いの（プライベート）IPアドレスを学習した場合GとHは、異なるプライベートネットワーク上に存在するため、相互に接続するために彼らの試みは失敗します。その接続試行が正しく認証されていない場合はさらに悪いことに、彼らは成功したように見えますが、間違ったホストに話してしまうことがあります。例えば、GはF、同様にIをホストに接続する意図せずに終わるかもしれないホストH.ホストHと同じプライベートIPアドレスを持って起こる、プライベートネットワーク3上のホストをホストするために話し終わる可能性が
In summary, peer-to-peer communication between hosts on disjoint private networks 1, 2, 3, and 4 in figure 1 above is a challenge without the assistance of a well-known server on the public Internet. However, with assistance from a node in the public Internet, all hosts on the private networks 1, 2, 3, and 4 in figure 1 above are able to establish a peer-to-peer-style communication session amongst themselves as well as with hosts on the public Internet.
要約すると、上記図1にばらばらプライベートネットワーク上のホスト1、2、3、及び4の間のピア・ツー・ピア通信は、公衆インターネット上でよく知られているサーバの支援なし課題です。しかし、公衆インターネット内のノードからの支援を受けて、図1中のすべてのプライベートネットワーク1、2、3にホスト、および4は、上記同様と同様に、それ自体で、ピア・ツー・ピア形式の通信セッションを確立することができます公共のインターネット上のホスト。
Even though conventional wisdom would suggest that the network described above is seriously broken, in practice it still works in many ways. We break up figure 1 into two sub-figures to better illustrate the anomalies. Figure 1.1 is the left half of figure 1 and reflects the conventional single NAT deployment that is widely prevalent in many last-mile locations. The deployment in figure 1.1 is popularly viewed as a pragmatic solution to work around the depletion of IPv4 address space and is not considered broken. Figure 1.2 is the right half of figure-1 and is representative of the anomalies we are about to discuss.
従来の知恵は、実際にはまだ多くの方法で動作し、上記ネットワークが真剣に壊れていることを示唆しているにもかかわらず。私たちはより良い異常を示すために、二つのサブ図形に図1を破ります。図1.1は、図1の左半分であり、多くのラストマイルの場所に広く普及している従来の単一のNATの展開を反映しています。図1.1での展開は、一般にIPv4アドレス空間の枯渇を回避するために実用的なソリューションとして見ていると壊れたとはみなされません。図1.2は、図1の右半分であり、我々は議論しようとしている異常の代表です。
Public Internet
(Public IP Addresses)
----+---------------+---------------+-----------
| | |
| | |
192.0.2.1 192.0.2.64 192.0.2.128
+-------+ Host A Host B
| NAT-1 | (Alice) (Jim)
| (Bob) |
+-------+
10.1.1.1
|
|
Private Network 1
(Private IP Addresses)
----+--------+----
| |
| |
10.1.1.10 10.1.1.11
Host C Host D
Figure 1.1. Conventional Single-level NAT Network topology
図1.1。従来のシングルレベルNATネットワークトポロジ
Public Internet
(Public IP Addresses)
---+---------------+---------------+----
| | |
| | |
192.0.2.64 192.0.2.128 192.0.2.254
Host A Host B +-------------+
(Alice) (Jim) | NAT-2 |
| (CheapoISP) |
+-------------+
10.1.1.1
|
|
Private Network 2
(Private IP Addresses)
----+---------------+-------------+--+-------
| | |
| | |
10.1.1.10 10.1.1.11 10.1.1.12
+-------+ Host E +-------+
| NAT-3 | (Mary) | NAT-4 |
| (Ann) | | (Lex) |
+-------+ +-------+
10.1.1.1 10.1.1.1
| |
| |
Private Network 3 Private Network 4
(Private IP Addresses) (Private IP Addresses)
----+-----------+------ ----+-----------+----
| | | |
| | | |
10.1.1.10 10.1.1.11 10.1.1.10 10.1.1.11
Host F Host G Host H Host I
Figure 1.2. Unconventional Multi-Level NAT Network Topology
図1.2。非在来型マルチレベルNATネットワークトポロジ
Consumer NAT devices are predominantly plug-and-play NAT devices, and assume minimal user intervention during device setup. The plug-and-play NAT devices provide DHCP service on one interface and NAT function on another interface. Vendors of the consumer NAT devices make assumptions about how their consumers configure and hook up their PCs to the device. When consumers do not adhere to the vendor assumptions, the consumers can end up with a broken network.
消費者のNATデバイスは、主にプラグアンドプレイNATデバイスを、デバイスのセットアップ時に、最小限のユーザーの介入を想定しています。プラグアンドプレイのNATデバイスは、別のインターフェイス上のインターフェイスとNAT機能上のDHCPサービスを提供しています。消費者のNATデバイスのベンダーは、消費者がデバイスに自分のPCを設定し、フックアップ方法についての仮定を行います。消費者がベンダーの前提条件に準拠していない場合は、消費者が切断されたネットワークで終わることができます。
A plug-and-play NAT device provides DHCP service on the LAN attached to the private interface, and assumes that all private hosts at the consumer site have DHCP client enabled and are connected to the single LAN. Consumers need to be aware that all private hosts must be on a single LAN, with no router in between.
プラグアンドプレイのNATデバイスは、プライベートインターフェイスに接続されたLAN上のDHCPサービスを提供し、消費者のサイトのすべてのプライベートホストは、DHCPクライアントが有効になっていると、単一のLANに接続されていることを前提としています。消費者は、すべてのプライベートホストが、間に無ルーターで、単一のLAN上になければならないことに注意する必要があります。
A plug-and-play NAT device also assumes that there is no other NAT device or DHCP server device on the same LAN at the customer premises. When there are multiple plug-and-play NAT devices on the same LAN, each NAT device will offer DHCP service on the same LAN, and may even be from the same private address pool. This could result in multiple end nodes on the same LAN ending up with identical IP addresses and breaking network connectivity.
プラグアンドプレイのNATデバイスは、顧客宅内で同じLAN上の他のNATデバイスまたはDHCPサーバ装置が存在しないことを前提としています。同じLAN上の複数のプラグアンドプレイのNATデバイスがある場合は、それぞれのNATデバイスは、同じLAN上でDHCPサービスを提供します、とさえ同じプライベートアドレスプールからのものであってもよいです。これは、同じLANが同一のIPアドレスで終わるとネットワーク接続を破るに複数のエンド・ノードにつながる可能性があります。
As it turns out, most consumer deployments have a single LAN where there they deploy a plug-and-play NAT device and the concerns raised above have not been an issue in reality.
結局のところ、ほとんどの消費者の展開は、彼らがプラグアンドプレイのNATデバイスを配置し、上記の懸念が現実に問題にされていないが、単一のLANを持っています。
Let us consider the unconventional addressing with NAT-3 and NAT-4. NAT-3 and NAT-4 are apparently multi-homed on the same subnet through both their interfaces. NAT-3 is on subnet 10.1.1/24 through its external interface facing NAT-2, as well as through its private interface facing clients host F and host G. Likewise, NAT-4 also has two interfaces on the same subnet 10.1.1/24.
私たちは、NAT-3およびNAT-4でのアドレッシング型破りを考えてみましょう。 NAT-3およびNAT-4は、明らかに、マルチホームの両方それらのインタフェースを介して同じサブネット上にあります。 NAT-3はNAT-2、ならびにクライアントが同様にFとホストG.ホスト面するプライベートインターフェイスを介して対向する外部インターフェースを介してサブネット10.1.1 / 24上で、NAT-4はまた、同じサブネット10.1の2つのインターフェイスを有しています。 1/24。
In a traditional network, when a node has multiple interfaces with IP addresses on the same subnet, it is natural to assume that all interfaces with addresses on the same subnet must be on a single connected LAN (bridged LAN or a single physical LAN). Clearly, that is not the case here. Even though both NAT-3 and NAT-4 have two interfaces on the same subnet 10.1.1/24, the NAT devices view the two interfaces as being on two disjoint subnets and routing realms. The plug-and-play NAT devices are really not multi-homed on the same subnet as in a traditional sense.
ノードが同じサブネット上でIPアドレスを持つ複数のインターフェイスを有する場合に従来のネットワークでは、同じサブネット上のアドレスを持つすべてのインターフェイスは、単一の接続されたLAN（ブリッジLANまたは単一の物理LAN）上になければならないと仮定することが自然です。明らかに、それはここではそうではありません。 3-NATとNAT-4の両方が同じサブネット10.1.1 / 24の2つのインターフェイスを有しているにもかかわらず、NATデバイスは、2つの互いに素のサブネットとルーティングレルム上にあるように、2つのインターフェースを表示します。プラグアンドプレイのNATデバイスは、実際にマルチホーム伝統的な意味では同じサブネット上にありません。
In a traditional network, both NAT-3 and NAT-4 in figure 1.2 should be incapable of communicating reliably as a transport endpoint with other nodes on their adjacent networks (e.g., private networks 2 and 3 in the case of NAT-3 and private Networks 2 and 4 in the case of NAT-4). This is because applications on either of the NAT devices cannot know to differentiate packets from hosts on either of the subnets bearing the same IP address. If NAT-3 attempts to resolve the IP address of a neighboring host in the conventional manner by broadcasting an Address Resolution Protocol (ARP) request on all of its physical interfaces bearing the same subnet, it may get a different response on each of its physical interfaces.
従来のネットワークでは、図1.2にNAT-3およびNAT-4の両方は、それらの隣接ネットワーク上の他のノード（例えば、プライベートネットワーク2及び3 NAT-3の場合には、専用とトランスポートエンドポイントとして確実に通信が不可能であるべきですネットワーク2及びNAT-4の場合は4）。 NATデバイスのいずれかのアプリケーションが同じIPアドレスを保有するサブネットのいずれかの上のホストからのパケットを区別するために知ることができないためです。 NAT-3試みが同じサブネットを担持その物理インターフェイスのすべてにアドレス解決プロトコル（ARP）要求をブロードキャストすることによって、従来の方法で、隣接ホストのIPアドレスを解決する場合は、その物理的の各々に異なる応答を得ることができインタフェース。
Even though both NAT-3 and NAT-4 have hosts bearing the same IP address on the adjacent networks, the NAT devices do communicate effectively as endpoints. Many of the plug-and-play NAT devices offer a limited number of services on them. For example, many of the NAT devices respond to pings from hosts on either of the interfaces. Even though a NAT device is often not actively managed, many of the NAT devices are equipped to be managed from the private interface. This unconventional communication with NAT devices is achievable because many of the NAT devices conform to REQ-7 of [BEH-UDP] and view the two interfaces as being on two disjoint routing domains and distinguish between sessions initiated from hosts on either interface (private or public).
3-NATとNAT-4の両方が、隣接するネットワーク上で同じIPアドレスを保有するホストを持っているにもかかわらず、NATデバイスは、エンドポイントとして有効に通信ありません。プラグアンドプレイのNATデバイスの多くは、それらのサービスの数が限られています。例えば、NATデバイスの多くは、インターフェイスのいずれかの上のホストからのpingに応答します。 NATデバイスは、多くの場合、積極的に管理されていないにもかかわらず、NATデバイスの多くはプライベートインターフェイスから管理するために装備されています。 NATデバイスの多くは、[BEH-UDP]の-7 REQ及び2つの互いに素ルーティングドメイン上にあるように、2つのインターフェイスを表示し、いずれかのインターフェイス上のホストから開始されたセッションを区別するために適合するので、NAT装置と、この異例の通信が達成可能である（プライベートまたは公）。
Use of a single NAT to connect private hosts to the public Internet as in figure 1.1 is a fairly common practice. Many consumer NATs are deployed this way. However, use of multi-level NAT translations as in figure 1.2 is not a common practice and is not well understood.
図1.1のように公共のインターネットへのプライベートホストを接続するための単一のNATの使用は、かなり一般的です。多くの消費者のNATは、このように展開されています。しかし、図1.2のようなマルチレベルNAT変換を使用することは一般的ではなく、十分に理解されていません。
Let us consider the conventional single NAT translation in figure 1.1. Because the public and private IP address ranges are numerically disjoint, nodes on private networks can make use of both public and private IP addresses when initiating network communication sessions. Nodes on a private network can use private IP addresses to refer to other nodes on the same private network, and public IP addresses to refer to nodes on the public Internet. For example, host C in figure 1.1 is on private network 1 and can directly address hosts A, B, and D using their assigned IP addresses. This is in spite of the fact that hosts A and B are on the public Internet and host D alone is on the private network.
私たちは、図1.1において、従来の単一のNAT変換を考えてみましょう。パブリックとプライベートIPアドレスの範囲は、数値的にばらばらであるため、ネットワークの通信セッションを開始するとき、プライベートネットワーク上のノードは、両方のパブリックおよびプライベートIPアドレスを利用することができます。プライベートネットワーク上のノードは、公衆インターネット上のノードを参照するために同じプライベートネットワーク上の他のノード、およびパブリックIPアドレスを参照するためにプライベートIPアドレスを使用することができます。例えば、図1.1のホストCは、プライベートネットワーク1上に直接、割り当てられたIPアドレスを使用するホストA、B、およびDに対処することができます。これだけでAとBは、公共のインターネットおよびホストD上にあるホストのプライベートネットワーク上にあるという事実にもかかわらずです。
Next, let us consider the unconventional multi-level NAT topology in figure 1.2. In this scenario, private hosts are able to connect to hosts on the public Internet. But, private hosts are not able to connect with all other private hosts. For example, host F in figure 1.2 can directly address hosts A, B, and G using their assigned IP addresses, but F has no way to address any of the other hosts in the diagram. Host F in particular cannot address host E by its assigned IP address, even though host E is located on the immediately "upstream" private network through which F is connected to the Internet. Host E has the same IP address as host G. Yet, this addressing is "legitimate" in the NAT world because the two hosts are on different private networks.
次に、私たちは図1.2で型にはまらないマルチレベルNATトポロジを考えてみましょう。このシナリオでは、プライベートホストは、パブリックインターネット上のホストに接続することができます。しかし、プライベートホストは、他のすべてのプライベートホストと接続することができません。例えば、図1.2にホストFは、直接、割り当てられたIPアドレスを使用するホストA、B、及びGを扱うことができるが、Fは、図中の他のホストのいずれかに対処する方法がありません。ホストEは、Fは、インターネットに接続されてすぐに、「上流」のプライベートネットワーク上にあるにもかかわらず、その割り当てられたIPアドレスでホストEに対処することはできません特にFをホストします。 2台のホストが異なるプライベートネットワーク上にあるので、NATの世界では「正当」であるホストEは、ホストG.と同じIPアドレスを持っているけれども、これは対処します。
It would seem that the topology in figure 1.2 with multiple NAT translations is broken because private hosts are not able to address each other directly. However, the network is not broken. Nodes on any private network have no direct method of addressing nodes on other private networks. The private networks 1, 2, 3, and 4 are all disjoint. Hosts on private network 1 are unable to directly address nodes on private networks 2, 3, or 4 and vice versa. Multiple NAT translations were not the cause of this.
プライベートホストが互いに直接に対処することができないので、複数のNAT変換と図1.2のトポロジが壊れていると思われます。しかし、ネットワークが壊れていません。任意のプライベートネットワーク上のノードは、他のプライベートネットワーク上のノードに対処するには直接的な方法を持っていません。プライベートネットワーク1、2、3、および4はすべて互いに素です。プライベートネットワーク1上のホストが直接プライベートネットワーク2、3、または4、およびその逆にノードをアドレス指定することができません。複数のNAT変換は、この原因はありませんでした。
As described in sections 3.1.1 and 3.1.2, client-server and peer-to-peer communication can and should be possible even with multi-level NAT topology deployment. A host on any private network must be able to communicate with any other host, no matter to which private network the host is attached or where the private network is located. Host F should be able to communicate with host E and carry out both client-server communication and peer-to-peer communication, and vice versa. Host F and host E form a hairpin session through NAT-2 to communicate with each other. Each host uses the public endpoint assigned by the Internet-facing NAT (NAT-2) to address its peer.
セクション3.1.1および3.1.2に記載されているように、クライアント - サーバ及びピア・ツー・ピア通信は、さらに、マルチレベルNATトポロジ展開に可能であるべきであることができます。プライベートネットワーク上のホストが他のホストと通信できる必要があり、プライベートネットワークに関係なくホストが取り付けられているか、プライベートネットワークが配置されます。ホストFは、ホストEと通信し、その逆クライアント - サーバ通信及びピア・ツー・ピア通信との両方を行うことができなければなりません。ホストFとホストEは、互いに通信するためにNAT-2を介してヘアピンセッションを形成します。各ホストは、そのピアに対処するためにインターネットに接続しているNAT（NAT-2）によって割り当てられたパブリックエンドポイントを使用しています。
When the deployed NAT devices conform to the hairpin translation requirements in [BEH-UDP], [BEH-TCP], and [BEH-ICMP], peer nodes are able to connect even in this type of multi-level NAT topologies.
展開NATデバイスは、ヘアピン変換要件に適合するとき、[BEH-UDP]、[BEH-TCP]、および[BEH-ICMP]、ピアノードはマルチレベルNATトポロジのこのタイプにも接続することが可能です。
Mistaken end host identity can result in accidental malfunction in some cases of multi-level NAT deployments. Consider the scenario in figure 1.3. Figure 1.3 depicts two levels of NATs between an end-user in private network 3 and the public Internet.
間違えエンドホストIDは、マルチレベルのNATの展開のいくつかのケースでは、偶発故障の原因になります。図1.3にシナリオを検討してください。図1.3は、プライベートネットワーク3及び公衆インターネットにおけるエンドユーザとの間のNAT 2つのレベルを示しています。
Suppose CheapoISP assigns 10.1.1.11 to its DNS resolver, which it advertises through DHCP to NAT-3, the gateway for Ann's home. NAT-3 in turn advertises 10.1.1.11 as the DNS resolver to host F (10.1.1.10) and host G (10.1.1.11) on private network 3. However, when host F sends a DNS query to 10.1.1.11, it will be delivered locally to host G on private network 3 rather than CheapoISP's DNS resolver. This is clearly a case of mistaken identity due to CheapoISP advertising a server that could potentially overlap with its customers' IP addresses.
CheapoISPが、それはNAT-3、アンの家庭用ゲートウェイにDHCP経由アドバタイズそのDNSリゾルバ、に10.1.1.11を割り当てたとします。 NAT-3ターンでは、ホストFは、それは意志10.1.1.11にDNSクエリを送信F（10.1.1.10）とただし、プライベートネットワーク上のホスト3. G（10.1.1.11）をホストするDNSリゾルバとして10.1.1.11をアドバタイズプライベートネットワーク3ではなくCheapoISPのDNSリゾルバにGをホストするために、ローカルに配信されます。これは明らかに、潜在顧客のIPアドレスと重複する可能性があり、サーバーを公示によるCheapoISPに人違いのケースです。
Public Internet
(Public IP Addresses)
---+---------------+---------------+----
| | |
| | |
192.0.2.64 192.0.2.128 192.0.2.254
Host A Host B +-------------+
(Alice) (Jim) | NAT-2 |
| (CheapoISP) |
+-------------+
10.1.1.1
|
|
Private Network 2
(Private IP Addresses)
------------+------------------+-------+----------
| |
10.1.1.10 |
+-------+ 10.1.1.11
| NAT-3 | Host E
| (Ann) | (DNS Resolver)
+-------+
10.1.1.1
| Private Network 3
| (Private IP Addresses)
----+---+-----------+----------------
| |
| |
10.1.1.10 10.1.1.11
Host F Host G
Figure 1.3. Mistaken Server Identity in Multi-Level NAT Topology
図1.3。マルチレベルNATトポロジで間違えサーバーID
Recommendation-1: ISPs, using NAT devices to provide connectivity to customers, should assign non-overlapping addresses to servers advertised to customers. One way to do this would be to assign global addresses to advertised servers.
勧告-1：顧客への接続を提供するために、NATデバイスを使用するISPは、顧客に広告サーバに、重複しないアドレスを割り当てる必要があります。これを行う1つの方法は、アドバタイズされたサーバにグローバルアドレスを割り当てることであろう。
Enterprises use remote access VPN to allow secure access to employees working outside the enterprise premises. While outside the enterprise premises, an employee may be located in his/her home office, hotel, conference, or a partner's office. In all cases, it is desirable for the employee at the remote site to have unhindered access to his/her corporate network and the applications running on the corporate network. While doing so, the employee should not jeopardize the integrity and confidentiality of the corporate network and the applications running on the network.
企業は、企業の敷地外で働く従業員への安全なアクセスを許可するリモートアクセスVPNを使用します。企業施設外の一方で、従業員は彼/彼女のホームオフィス、ホテル、会議、またはパートナーのオフィスに配置することができます。リモートサイトの従業員が妨害されていない彼/彼女の企業ネットワークへのアクセスや、企業ネットワーク上で動作するアプリケーションを持っているため、すべてのケースでは、それが望ましいです。そうしながら、従業員には、整合性と企業ネットワークの機密性とネットワーク上で実行中のアプリケーションを危険にさらすべきではありません。
IPsec, Layer 2 Tunneling Protocol (L2TP), and Secure Socket Layer (SSL) are some of the well-known secure VPN technologies used by the remote access vendors. Besides authenticating employees for granting access, remote access VPN servers often enforce different forms of security (e.g., IPsec, SSL) to protect the integrity and confidentiality of the run-time traffic between the VPN client and the VPN server.
IPsecは、レイヤ2トンネリングプロトコル（L2TP）、およびセキュア・ソケット・レイヤー（SSL）は、リモートアクセスベンダーによって使用される、よく知られたセキュアなVPN技術の一部です。アクセスを許可するために従業員を認証するだけでなく、リモートアクセスVPNサーバは、多くの場合、VPNクライアントとVPNサーバー間の実行時のトラフィックの完全性と機密性を保護するためのセキュリティ（例えば、IPsecの、SSL）の異なる形式を適用します。
Many enterprises deploy their internal networks using private address space as defined in RFC 1918 and use NAT devices to connect to the public Internet. Further, many of the applications in the corporate network refer to information (such as URLs) and services using private addresses in the corporate network. Applications such as the Network File Systems (NFS) rely on simple source-IP-address-based filtering to restrict access to corporate users. These are some reasons why the remote access VPN servers are configured with a block of IP addresses from the corporate private network to assign to remote access clients. VPN clients use the virtual IP (VIP) address assigned to them (by the corporate VPN server) to access applications inside the corporate network.
多くの企業は、RFC 1918で定義されているプライベートアドレス空間を使用して社内ネットワークを展開し、公衆インターネットに接続するためにNATデバイスを使用しています。さらに、企業ネットワーク内のアプリケーションの多くは、企業ネットワーク内のプライベートアドレスを使用して、サービス情報（URLなど）を参照してください。そのようなネットワークファイルシステム（NFS）などのアプリケーションは、企業ユーザーへのアクセスを制限するために、単純なソースIPアドレスベースのフィルタリングに依存しています。これらは、リモートアクセスVPNサーバーがリモートアクセスクライアントに割り当てるために、企業のプライベートネットワークからIPアドレスのブロックで構成されているいくつかの理由です。 VPNクライアントは、企業ネットワーク内のアプリケーションにアクセスするために（企業のVPNサーバーによって）それらに割り当てられた仮想IP（VIP）アドレスを使用します。
Consider the remote access VPN scenario in figure 2 below.
以下の図2にリモートアクセスVPNのシナリオを検討してください。
(Corporate Private Network 10.0.0.0/8)
---------------+----------------------
|
10.1.1.10
+---------+-------+
| Enterprise Site |
| Remote Access |
| VPN Server |
+--------+--------+
192.0.2.1
|
{---------+------}
{ }
{ }
{ Public Internet }
{ (Public IP Addresses) }
{ }
{ }
{---------+------}
|
192.0.2.254
+--------+--------+
| Remote Site |
| Plug-and-Play |
| NAT Router |
+--------+--------+
10.1.1.1
|
Remote Site Private Network |
-----+-----------+-----------+-------------+-----------
| | | |
10.1.1.10 10.1.1.11 10.1.1.12 10.1.1.13
Host A Host B +--------+ Host C
| VPN |
| Client |
| on a PC|
+--------+
Figure 2. Remote Access VPN with Overlapping Address Space
重複アドレス空間を持つ図2.リモートアクセスVPN
In the above scenario, say an employee of the corporation is at a remote location and attempts to access the corporate network using the VPN client, the corporate network is laid out using the address pool of 10.0.0.0/8 as defined in RFC 1918, and the VPN server is configured with an address block of 10.1.1.0/24 to assign virtual IP addresses to remote access VPN clients. Now, say the employee at the remote site is attached to a network on the remote site that also happens to be using a network based on the RFC 1918 address space and
上記のシナリオでは、企業の従業員が遠隔地にあり、RFC 1918で定義されているVPNクライアントを使用して企業ネットワークは、企業ネットワークは10.0.0.0/8のアドレスプールを使用してレイアウトされているアクセスしようと言いますそして、VPNサーバーは、リモートアクセスVPNクライアントに仮想IPアドレスを割り当てるために10.1.1.0/24のアドレスブロックで構成されています。さて、リモートサイトの従業員はまた、RFC 1918アドレス空間に基づいてネットワークを使用しているとたまたまリモートサイト上のネットワークに接続されていると言うと、
coincidentally overlaps the corporate network. In this scenario, it is conventionally problematic for the VPN client to connect to the server(s) and other hosts at the enterprise.
偶然企業ネットワークと重なります。 VPNクライアントは企業のサーバ（複数可）および他のホストに接続するために、このシナリオでは、従来問題となります。
Nevertheless, despite the direct address overlap, the remote access VPN connection between the VPN client at the remote site and the VPN server at the enterprise should remain connected and should be made to work. That is, the NAT device at the remote site should not obstruct the VPN connection traversing it. Additionally, the remote user should be able to connect to any host at the enterprise through the VPN from the remote desktop.
それにも関わらず、直接アドレスの重複にもかかわらず、企業のリモートサイトのVPNクライアント間のリモートアクセスVPN接続とVPNサーバーが接続されたままにすべきであると動作するようになされるべきです。これは、リモートサイトのNATデバイスは、それを通過するVPN接続を妨げてはならない、です。また、リモートユーザは、リモートデスクトップからVPNを介して企業に任意のホストに接続することができなければなりません。
The following subsections describe the operational details of the VPN, anomalies with the address overlap, and recommendations on how best to address the situation.
以下のサブセクションでは、最高の状況に対処する方法についての運用VPNの詳細、アドレスの重複を持つ異常、および推奨事項について説明します。
As mentioned earlier, in the "de facto" Internet address architecture, only the nodes on the public Internet have globally unique IP addresses assigned by the official IP address registries. Many of the networks in the edges use private IP addresses from RFC 1918 and use NAT devices to connect their private networks to the public Internet. Many enterprises adapted the approach of using private IP addresses internally. Employees within the enterprise's intranet private network are "trusted" and may connect to any of the internal hosts with minimal administrative or policy enforcement overhead. When an employee leaves the enterprise premises, remote access VPN provides the same level of intranet connectivity to the remote user.
前述したように、「事実上の」インターネットアドレスのアーキテクチャでは、公共のインターネット上の唯一のノードは、公式のIPアドレスレジストリによって割り当てられたグローバルに固有のIPアドレスを持っています。エッジでのネットワークの多くはRFC 1918からプライベートIPアドレスを使用して、公共のインターネットに自分のプライベートネットワークを接続するためにNATデバイスを使用しています。多くの企業は、内部のプライベートIPアドレスを使用してのアプローチを適応しました。企業のイントラネット、プライベートネットワーク内の従業員は、「信頼」であり、最小限の管理やポリシー施行オーバーヘッドで内部ホストのいずれかに接続することができます。従業員が企業の施設を離れると、リモートアクセスVPNはリモートユーザへのイントラネット接続の同じレベルを提供します。
The objective of this section is to provide an overview of the operational details of a remote access VPN application so the reader has an appreciation for the problem of remote address space overlap. This is not a tutorial or specification of remote access VPN products, per se.
このセクションの目的は、読者は、リモートアドレス空間の重なりの問題のために感謝を持っているので、リモートアクセスVPNアプリケーションの動作の詳細の概要を提供することです。これは、チュートリアルやリモートアクセスVPN製品自体の仕様ではありません。
When an employee at a remote site launches his/her remote access VPN client, the VPN server at the corporate premises demands that the VPN client authenticate itself. When the authentication succeeds, the VPN server assigns a Virtual IP (VIP) address to the client for connecting with the corporate intranet. From this point onwards, while the VPN is active, outgoing IP packets directed to the hosts in the corporate intranet are tunneled through the VPN, in that the VPN server serves as the next-hop and the VPN connection as the next-hop link for these packets. Within the corporate intranet, the outbound IP packets appear as arriving from the VIP address. So, IP packets from the corporate hosts to the remote user are sent to the remote user's VIP address and the IP packets are tunneled inbound to the remote user's PC through the VPN tunnel.
リモートサイトの従業員は、彼/彼女のリモートアクセスVPNクライアントを起動すると、企業の敷地内でのVPNサーバーは、VPNクライアントが自身を認証することを要求しています。認証が成功すると、VPNサーバーは、企業のイントラネットに接続するためのクライアントに仮想IP（VIP）アドレスを割り当てます。 VPNがアクティブである間にVPNサーバが次のホップとのネクストホップリンクとしてVPN接続として機能するという点で以降この点から、企業イントラネットのホストに向けられた発信IPパケットは、VPNを介してトンネリングされこれらのパケット。企業のイントラネット内では、アウトバウンドIPパケットは、VIPアドレスから到着として表示されます。だから、リモートユーザへの企業のホストからのIPパケットは、リモートユーザーのVIPアドレスに送信され、IPパケットがVPNトンネルを経由してリモートユーザのPCへのインバウンドトンネル化されています。
This works well so long as the subnets in the corporate network do not conflict with subnets at the remote site where the remote user's PC is located. However, when the corporate network is built using RFC 1918 private address space and the remote location where the VPN client is launched is also using an overlapping network from RFC 1918 address space, there can be addressing conflicts. The remote user's PC will have a conflict in accessing nodes on the corporate site and nodes at the remote site bearing the same IP address simultaneously. Consequently, the VPN client may be unable to have full access to the employee's corporate network and the local network at the remote site simultaneously.
これは、あまりにも長い間、企業ネットワーク内のサブネットは、リモートユーザのPCが配置されているリモートサイトでのサブネットと競合しないよううまく動作します。企業ネットワークは、RFC 1918プライベートアドレス空間とVPNクライアントはまた、RFC 1918アドレス空間から重複したネットワークを使用している起動されるリモートロケーションを使用して構築されている場合しかし、競合が対処することができます。リモートユーザのPCが同時に同じIPアドレスを保有するリモートサイトで、企業サイトのノードとノードにアクセスする際の競合を持っています。そのため、VPNクライアントは、従業員の企業ネットワークへのフルアクセスと同時に、リモートサイトのローカルネットワークを持つことができない場合があります。
In spite of address overlap, remote access VPN clients should be able to successfully establish connections with intranet hosts in the enterprise.
アドレスの重複にもかかわらず、リモートアクセスVPNクライアントが正常に企業内のイントラネットホストとの接続を確立することができるはずです。
Even though conventional wisdom would suggest that the remote access VPN scenario with overlapping address space would be seriously broken, in practice it still works in many ways. Let us look at some anomalies where there might be a problem and identify solutions through which the remote access VPN application could be made to work even under the problem situations.
従来の知恵は、実際には、アドレス空間が重複するリモートアクセスVPNシナリオを真剣に壊れてしまうことを示唆しているにもかかわらず、それはまだ多くの方法で動作します。私たちが問題になるとリモートアクセスVPNのアプリケーションでも、問題の状況の下で動作させることができ、それを通してソリューションを識別かもしれないいくつかの異常を見てみましょう。
Routing and DHCP service are bootstrap services essential for a remote host to establish a VPN connection. Without DHCP lease, the remote host cannot communicate over the IP network. Without a router to connect to the Internet, the remote host is unable to access past the local subnet to connect to the VPN server at the enterprise. It is essential that neither of these bootstrap services be tampered with at the remote host in order for the VPN connection to stay operational. Typically, a plug-and-play NAT device at the remote site provides both routing and DHCP services from the same IP address.
ルーティングとDHCPサービスは、VPN接続を確立するリモートホストに不可欠なブートストラップサービスです。 DHCPリースがなければ、リモートホストはIPネットワーク上で通信することはできません。インターネットに接続するルータがなければ、リモートホストは、企業のVPNサーバーに接続するために、ローカルサブネットを越えてアクセスすることができません。これらのブートストラップサービスのどちらもVPN接続が動作して滞在するために、リモートホストで改ざんされることが不可欠です。一般的に、リモートサイトでのプラグアンドプレイのNATデバイスは、同じIPアドレスからルーティングおよびDHCPサービスの両方を提供します。
When there is address overlap between hosts at the corporate intranet and hosts at the remote site, the remote VPN user is often unaware of the address conflict. Address overlap could potentially cause the remote user to lose connectivity to the enterprise entirely or lose connectivity to an arbitrary block of hosts at the enterprise.
リモート・サイトで、企業のイントラネットでホストとホスト間のアドレス重複がある場合は、リモートVPNユーザは、多くの場合、アドレスの競合を認識しません。アドレス重複は、潜在的に、リモートユーザが企業への接続を完全に失う、または企業でホストの任意のブロックへの接続を失う可能性があります。
Consider, for example, a scenario where the IP address of the DHCP server at the remote site matched the IP address of a host at the enterprise network. When the remote user's PC is ready to renew the lease of the locally assigned IP address, the remote user's VPN client would incorrectly identify the IP packet as being addressed to an enterprise host and tunnel the DHCP renewal packet over the VPN to the remote VPN server. The DHCP renewal requests simply do not reach the DHCP server at the remote site. As a result, the remote PC would eventually lose the lease on the IP address and the VPN connection to the enterprise would be broken.
例えば、リモートサイトのDHCPサーバーのIPアドレスは、企業ネットワークでホストのIPアドレスに一致したシナリオを考えてみましょう。リモートユーザのPCにローカルに割り当てられたIPアドレスのリースを更新する準備ができている場合は、リモートユーザのVPNクライアントが誤っ企業のホストとトンネルへのリモートVPNサーバーへのVPNを越えたDHCPの更新パケットをアドレス指定されているように、IPパケットを識別します。 DHCPの更新要求は、単にリモートサイトにDHCPサーバーに到達しません。その結果、リモートPCは、最終的にはIPアドレスと壊れてしまう企業へのVPN接続のリースを失うことになります。
Consider another scenario where the IP address of the remote user's router overlapped with the IP address of a host in the enterprise network. If the remote user's PC were to send a ping or some type of periodic keep-alive packets to the router (say, to test the liveness of the router), the packets would be intercepted by the VPN client and simply redirected to the VPN tunnel. This type of unintended redirection has the twin effect of hijacking critical packets addressed to the router as well as the host in the enterprise network (bearing the same IP address as the remote router) being bombarded with unintended keep-alive packets. Loss of connectivity to the router can result in the VPN connection being broken.
リモートユーザのルータのIPアドレスは、企業ネットワーク内のホストのIPアドレスと重複し、別のシナリオを検討してください。リモートユーザのPCは、（たとえば、ルータの生存性をテストするために）ルータにpingや定期的なキープアライブパケットのいくつかのタイプを送信した場合、パケットがVPNクライアントによって傍受され、簡単にVPNトンネルにリダイレクトされます。意図しないリダイレクトのこのタイプは、意図しないキープアライブパケットが殺到している重要なパケットがルータ宛のハイジャックの双子の効果だけでなく、（リモートルータと同じIPアドレスを保有する）は、企業ネットワーク内のホストを持っています。ルータへの接続の損失は、VPN接続が破壊されることになります。
Clearly, it is not desirable to route traffic directed to the local router or DHCP server to be redirected to the corporate intranet. A VPN client on a remote PC should be configured such that IP packets whose target IP address matches any of the following are disallowed to be redirected over the VPN:
明らかに、それは企業のイントラネットにリダイレクトするローカルルータやDHCPサーバーに向けトラフィックをルーティングするように望ましいものではありません。リモートPC上のVPNクライアントは、そのターゲットIPアドレスIPパケットがVPN経由でリダイレクトすることが禁止されている次のいずれかに一致するように構成する必要があります。
a) IP address of the VPN client's next-hop router, used to access the VPN server.
VPNサーバーにアクセスするために使用されるVPNクライアントのネクストホップルータのa）のIPアドレス。
b) IP address of the DHCP server, providing address lease on the remote host network interface.
DHCPサーバのb）のIPアドレス、リモートホストのネットワークインタフェース上のアドレスのリースを提供します。
Recommendation-2: A VPN client on a remote PC should be configured such that IP packets whose target IP address matches *any* of (a) or (b) are disallowed to be redirected over the VPN:
勧告-2：リモートPC上のVPNクライアントを設定する必要があり、その結果、ターゲットがIPアドレスと一致するIPパケット*のいずれか*（a）または（b）はVPN経由でリダイレクトすることが禁止されています。
a) IP address of the VPN client's next-hop router, used to access the VPN server.
VPNサーバーにアクセスするために使用されるVPNクライアントのネクストホップルータのa）のIPアドレス。
b) IP address of the DHCP server, providing address lease on the remote host network interface.
DHCPサーバのb）のIPアドレス、リモートホストのネットワークインタフェース上のアドレスのリースを提供します。
Ideally speaking, it is not desirable for the corporate intranet to conflict with any of the hosts at the remote site. As a general practice, if simultaneous communication with end hosts at the remote location is important, it is advisable to disallow access to any corporate network resource that overlaps the client's subnet at the remote site. By doing this, the remote user is able to connect to all local hosts simultaneously while the VPN connection is active.
企業イントラネットは、リモート・サイトでホストのいずれかと競合するために理想的に言えば、それは望ましいことではありません。遠隔地でのエンドホストとの同時通信が重要な場合、一般的なプラクティスとして、リモートサイトで、クライアントのサブネットと重複する任意の企業ネットワークリソースへのアクセスを禁止することをお勧めします。これにより、リモートユーザーはVPN接続がアクティブである間、同時にすべてのローカルホストに接続することができます。
Some VPN clients allow the remote PC to access the corporate network over VPN and all other subnets directly without routing through the VPN. Such a configuration is termed as "Split VPN" configuration. "Split VPN" configuration allows the remote user to run applications requiring communication with hosts at the remote site or the public Internet, as well as hosts at the corporate intranet, unless there is address overlap with the remote subnet. Applications needing access to the hosts at the remote site or the public Internet do not traverse the VPN, and hence are likely to have better performance when compared to traversing the VPN. This can be quite valuable for latency-sensitive applications such as Voice over IP (VoIP) and interactive gaming. If there is no overriding security concern to directly accessing hosts at the remote site or the public Internet, the VPN client on remote PC should be configured in "Split VPN" mode.
一部のVPNクライアントは、リモートPCがVPNを経由せずに直接VPNおよび他のすべてのサブネットを介して企業ネットワークにアクセスすることを可能にします。このような構成は、「スプリットVPN」構成と呼ばれています。リモートサブネットとアドレスの重複がない限り、「スプリットVPN」の設定は、リモートユーザが企業イントラネットにリモートサイトまたは公共のインターネットでのホストだけでなく、ホストとの通信を必要とするアプリケーションを実行することができます。リモートサイトまたは公共のインターネットでホストへのアクセスを必要とするアプリケーションは、VPNを横断し、ひいてはVPNを横断に比べ、より良い性能を持っている可能性がありません。これは、ボイスオーバーIP（VoIP）のように遅延の影響を受けやすいアプリケーションやインタラクティブなゲームのために非常に貴重であることができます。直接リモートサイトまたは公共のインターネットでホストにアクセスするには、noオーバーライドセキュリティ上の問題がない場合は、リモートPC上のVPNクライアントは、「スプリットVPN」モードに設定する必要があります。
If simultaneous connectivity to hosts at the remote site is not important, the VPN client may be configured to direct all communication traffic from the remote user to the VPN. Such a configuration is termed as "Non-Split VPN" configuration. "Non-Split VPN" configuration ensures that all communication from the remote user's PC traverses the VPN link and is routed through the VPN server, with the exception of traffic directed to the router and DHCP server at the remote site. No other communication takes place with hosts at the remote site. Applications needing access to the public Internet also traverse the VPN. If the goal is to maximize the security and reliability of connectivity to the corporate network, the VPN client on remote PC should be configured in "Non-Split VPN" mode. "Non-Split VPN" configuration will minimize the likelihood of access loss to corporate hosts.
リモートサイトのホストへの同時接続が重要でない場合は、VPNクライアントはVPNへのリモートユーザからのすべての通信トラフィックを導くように構成することができます。このような構成は、「非分割VPN」構成と呼ばれています。 「非分割VPN」の設定は、リモートユーザのPCからのすべての通信はVPNリンクを横断し、リモートサイトのルータやDHCPサーバへのトラフィックを除いて、VPNサーバー経由でルーティングされることを保証します。他の通信は、リモートサイトのホストと場所を取りません。公共のインターネットへのアクセスを必要とするアプリケーションはまた、VPNを横断します。目標は、企業ネットワークへの接続のセキュリティと信頼性を最大にすることである場合は、リモートPC上のVPNクライアントは、「非スプリットVPN」モードに設定する必要があります。 「非分割VPN」の設定は、企業のホストへのアクセス損失の可能性を最小限に抑えることができます。
Recommendation-3: A VPN client on a remote PC should be configured in "Non-Split VPN" mode if the deployment goal is (a), or in "Split VPN" mode if the deployment goal is (b):
勧告-3：展開の目標は、（b）のであれば、展開の目標は、（a）に、または「スプリットVPN」モードになっている場合は、リモートPC上のVPNクライアントが「非スプリットVPN」モードで構成する必要があります。
a) If the goal is to maximize the security and reliability of connectivity to the corporate network, the VPN client on the remote PC should be configured in "Non-Split VPN" mode. "Non-Split VPN" mode ensures that the VPN client directs all traffic from the remote user to the VPN server (at the corporate site), with the exception of traffic directed to the router and DHCP server at the remote site.
目標は、企業ネットワークへの接続のセキュリティと信頼性を最大化することであるならば、A）、リモートPC上のVPNクライアントは、「非スプリットVPN」モードに設定する必要があります。 「非スプリットVPN」モードでは、VPNクライアントがリモートサイトのルータやDHCPサーバーへのトラフィックを除いて、（企業サイトでの）VPNサーバーへのリモートユーザからのすべてのトラフィックを指示することを保証します。
b) If there is no overriding security concern to directly accessing hosts at the remote site or the public Internet, the VPN client on the remote PC should be configured in "Split VPN" mode. "Split VPN" mode ensures that only the corporate traffic is directed over the VPN. All other traffic does not have the overhead of traversing the VPN.
直接リモートサイトまたは公共のインターネットでホストにアクセスするには、noオーバーライドセキュリティ上の問題が存在しない場合b）に、リモートPC上のVPNクライアントは、「スプリットVPN」モードに設定する必要があります。 「スプリットVPN」モードのみ、企業のトラフィックがVPNを介して送られることを保証します。他のすべてのトラフィックはVPNを横断するオーバーヘッドを持っていません。
When the VIP address assigned to the VPN client at the remote site is in direct conflict with the IP address of the existing network interface, the VPN client might be unable to establish the VPN connection.
リモートサイトでのVPNクライアントに割り当てられたVIPアドレスは、既存のネットワーク・インタフェースのIPアドレスと直接競合している場合は、VPNクライアントはVPN接続を確立できないことがあります。
Consider a scenario where the VIP address assigned by the VPN server directly matched the IP address of the networking interface at the remote site. When the VPN client on the remote host attempts to set the VIP address on a virtual adapter (specific to the remote access application), the VIP address configuration will simply fail due to conflict with the IP address of the existing network interface. The configuration failure in turn can result in the remote access VPN tunnel not being established.
VPNサーバーによって割り当てられたVIPアドレスを直接リモートサイトでのネットワークインタフェースのIPアドレスに一致したシナリオを考えてみましょう。リモートホスト上のVPNクライアントは仮想アダプタ（リモートアクセスアプリケーションに固有）のVIPアドレスを設定しようとすると、VIPアドレスの設定は、単純に起因する既存のネットワーク・インタフェースのIPアドレスとの競合に失敗します。ターンで構成故障が確立されていないリモートアクセスVPNトンネルをもたらすことができます。
Clearly, it is not advisable to have the VIP address overlap the IP address of the remote user's existing network interface. As a general rule, it is not advisable for the VIP address to overlap any IP address in the remote user's local subnet, as the VPN client on the remote PC might be forced to respond to ARP requests on the remote site and the VPN client might not process the handling of ARP requests gracefully.
明らかに、VIPアドレスは、リモートユーザーの既存のネットワーク・インタフェースのIPアドレスと重複していすることはお勧めできません。一般的なルールとして、それは、リモートPC上のVPNクライアントとしてリモートサイトとのVPNクライアントのかもしれない上のARP要求に応答することを余儀なくされる可能性があります、リモートユーザのローカルサブネット内の任意のIPアドレスをオーバーラップするVIPアドレスのことはお勧めできません優雅にARP要求の処理を処理しません。
Some VPN vendors offer provisions to detect conflict of VIP addresses with remote site address space and switch between two or more address pools with different subnets so the VIP address assigned is not in conflict with the address space at remote site. Enterprises deploying VPNs that support this type of vendor provisioning are advised to configure the VPN server with a minimum of two distinct IP address pools. However, this is not universally the case.
一部のVPNベンダーは、リモートサイトのアドレス空間でVIPアドレスの競合を検出するための規定を提供し、割り当てられたVIPアドレスは、リモートサイトのアドレス空間と競合しないように、異なるサブネットを持つ2つの以上のアドレスプールに切り替えます。ベンダー・プロビジョニングのこのタイプをサポートしてVPNを導入する企業は、2つの異なるIPアドレスプールの最小でVPNサーバを設定することをお勧めします。しかし、これは普遍的にそうではありません。
Alternately, enterprises may deploy two or more VPN servers with different address pools. By doing so, a VPN client that detects conflict of a VIP address with the subnet at the remote site will have the ability to switch to an alternate VPN server that will not conflict.
代わりに、企業は異なるアドレスプールを持つ2台の以上のVPNサーバーを展開します。そうすることによって、リモートサイトでのサブネットとVIPアドレスの競合を検出したVPNクライアントが競合しない代替VPNサーバーに切り替えることができるようになります。
Recommendation-4: Enterprises deploying remote access VPN solutions are advised to adapt a strategy of (a) or (b) to avoid VIP address conflict with the subnet at the remote site.
勧告-4：リモートアクセスVPNソリューションを導入企業は戦略を適応することをお勧めします（a）又は（b）のリモートサイトのサブネットとVIPアドレスの競合を避けるために。
a) If the VPN server being deployed has been provisioned to configure two or more address pools, configure the VPN server with a minimum of two distinct IP address pools.
a）は、展開されたVPNサーバは、二つ以上のアドレスプールを構成する二つの異なるIPアドレスプールの最小値とVPNサーバを設定するようにプロビジョニングされている場合。
b) Deploy two or more VPN servers with distinct IP address pools. By doing so, a VPN client that detects conflicts of VIP addresses with the subnet at the remote site will have the ability to switch to an alternate VPN server that will not conflict.
b）は個別のIPアドレスプールを持つ2台の以上のVPNサーバーを展開。そうすることによって、リモートサイトのサブネットとVIPアドレスの衝突を検知するVPNクライアントは、競合しない代替VPNサーバーに切り替えることができるようになります。
When "Split VPN" is configured on the VPN client on a remote PC, there can be a potential security threat due to mistaken identity. Say, a certain service (e.g., SMTP mail service) is configured on exactly the same IP address on both the corporate site and the remote site. The user could unknowingly be using the service on the remote site, thereby violating the integrity and confidentiality of the contents relating to that application. Potentially, remote user mail messages could be hijacked by the ISP's mail server.
「スプリットVPNは、」リモートPC上のVPNクライアント上で設定されている場合、人違いによる潜在的なセキュリティ上の脅威が存在することができます。言って、特定のサービス（例えば、SMTPメールサービス）は、企業サイトとリモートサイトの両方で正確に同じIPアドレスに設定されています。ユーザーが知らないうちに、それによって、そのアプリケーションに関連するコンテンツの完全性と機密性に違反し、リモートサイト上のサービスを使用することができます。潜在的には、リモートユーザーのメールメッセージは、ISPのメールサーバーによってハイジャックすることができます。
Enterprises deploying remote access VPN servers should allocate global IP addresses for the critical servers the remote VPN clients typically need to access. By doing this, even if most of the private corporate network uses RFC 1918 address space, this will ensure that the remote VPN clients can always access the critical servers regardless of the private address space used at the remote attachment point. This is akin to Recommendation-1 provided in conjunction with multi-level NAT deployments.
リモートアクセスVPNサーバーを展開する企業は、リモートVPNクライアントは一般的にアクセスする必要のある重要なサーバのグローバルIPアドレスを割り当てる必要があります。企業のプライベートネットワークのほとんどは、RFC 1918アドレス空間を使用している場合でも、このようにすることで、これはリモートVPNクライアントは常にリモート取付点で使用するプライベートアドレス空間に関わらず、重要なサーバにアクセスできることを保証します。これは、勧告-1マルチレベルNATの展開に関連して提供さに似ています。
Recommendation-5: When "Split VPN" is configured on a VPN client of a remote PC, enterprises deploying remote access VPN servers are advised to assign global IP addresses for the critical servers the remote VPN clients are likely to access.
勧告-5：「スプリットVPNは、」リモートPCのVPNクライアント上で設定されている場合、リモートアクセスVPNサーバーを展開する企業がリモートVPNクライアントがアクセスする可能性のある重要なサーバのグローバルIPアドレスを割り当てることをお勧めします。
NAT vendors are advised to refer to the BEHAVE protocol documents ([BEH-UDP], [BEH-TCP], and [BEH-ICMP]) for a comprehensive list of conformance requirements for NAT devices.
NATのベンダーは、NATデバイスのための適合性要件の包括的なリストについては、BEHAVEプロトコル文書（[BEH-UDP]、[BEH-TCP]、および[BEH-ICMP]）を参照することをお勧めします。
The following is a summary of recommendations to support the unconventional NAT topologies identified in this document. The recommendations are deployment-specific and addressed to the personnel responsible for the deployments. These personnel include ISP administrators and enterprise IT administrators.
以下は、この文書で特定され型破りなNATトポロジをサポートするための提言をまとめたものです。勧告は、展開固有であり、展開の責任者に宛て。これらの担当者は、IT管理者ISPの管理者およびエンタープライズが含まれます。
Recommendation-1: ISPs, using NAT devices to provide connectivity to customers, should assign non-overlapping addresses to servers advertised to customers. One way to do this would be to assign global addresses to advertised servers.
勧告-1：顧客への接続を提供するために、NATデバイスを使用するISPは、顧客に広告サーバに、重複しないアドレスを割り当てる必要があります。これを行う1つの方法は、アドバタイズされたサーバにグローバルアドレスを割り当てることであろう。
Recommendation-2: A VPN client on a remote PC should be configured such that IP packets whose target IP address matches *any* of (a) or (b) are disallowed to be redirected over the VPN:
勧告-2：リモートPC上のVPNクライアントを設定する必要があり、その結果、ターゲットがIPアドレスと一致するIPパケット*のいずれか*（a）または（b）はVPN経由でリダイレクトすることが禁止されています。
a) IP address of the VPN client's next-hop router, used to access the VPN server.
VPNサーバーにアクセスするために使用されるVPNクライアントのネクストホップルータのa）のIPアドレス。
b) IP address of the DHCP server, providing address lease on the remote host network interface.
DHCPサーバのb）のIPアドレス、リモートホストのネットワークインタフェース上のアドレスのリースを提供します。
Recommendation-3: A VPN client on a remote PC should be configured in "Non-Split VPN" mode if the deployment goal is (a), or in "Split VPN" mode if the deployment goal is (b):
勧告-3：展開の目標は、（b）のであれば、展開の目標は、（a）に、または「スプリットVPN」モードになっている場合は、リモートPC上のVPNクライアントが「非スプリットVPN」モードで構成する必要があります。
a) If the goal is to maximize the security and reliability of connectivity to the corporate network, the VPN client on the remote PC should be configured in "Non-Split VPN" mode. "Non-Split VPN" mode ensures that the VPN client directs all traffic from the remote user to the VPN server (at the corporate site), with the exception of traffic directed to the router and DHCP server at the remote site.
目標は、企業ネットワークへの接続のセキュリティと信頼性を最大化することであるならば、A）、リモートPC上のVPNクライアントは、「非スプリットVPN」モードに設定する必要があります。 「非スプリットVPN」モードでは、VPNクライアントがリモートサイトのルータやDHCPサーバーへのトラフィックを除いて、（企業サイトでの）VPNサーバーへのリモートユーザからのすべてのトラフィックを指示することを保証します。
b) If there is no overriding security concern to directly accessing hosts at the remote site or the public Internet, the VPN client on the remote PC should be configured in "Split VPN" mode. "Split VPN" mode ensures that only the corporate traffic is directed over the VPN. All other traffic does not have the overhead of traversing the VPN.
直接リモートサイトまたは公共のインターネットでホストにアクセスするには、noオーバーライドセキュリティ上の問題が存在しない場合b）に、リモートPC上のVPNクライアントは、「スプリットVPN」モードに設定する必要があります。 「スプリットVPN」モードのみ、企業のトラフィックがVPNを介して送られることを保証します。他のすべてのトラフィックはVPNを横断するオーバーヘッドを持っていません。
Recommendation-4: Enterprises deploying remote access VPN solutions are advised to adapt a strategy of (a) or (b) to avoid VIP address conflict with the subnet at the remote site.
勧告-4：リモートアクセスVPNソリューションを導入企業は戦略を適応することをお勧めします（a）又は（b）のリモートサイトのサブネットとVIPアドレスの競合を避けるために。
a) If the VPN server being deployed has been provisioned to configure two or more address pools, configure the VPN server with a minimum of two distinct IP address pools.
a）は、展開されたVPNサーバは、二つ以上のアドレスプールを構成する二つの異なるIPアドレスプールの最小値とVPNサーバを設定するようにプロビジョニングされている場合。
b) Deploy two or more VPN servers with distinct IP address pools. By doing so, a VPN client that detects conflicts of VIP addresses with the subnet at the remote site will have the ability to switch to an alternate VPN server that will not conflict.
b）は個別のIPアドレスプールを持つ2台の以上のVPNサーバーを展開。そうすることによって、リモートサイトのサブネットとVIPアドレスの衝突を検知するVPNクライアントは、競合しない代替VPNサーバーに切り替えることができるようになります。
Recommendation-5: When "Split VPN" is configured on a VPN client of a remote PC, enterprises deploying remote access VPN servers are advised to assign global IP addresses for the critical servers the remote VPN clients are likely to access.
勧告-5：「スプリットVPNは、」リモートPCのVPNクライアント上で設定されている場合、リモートアクセスVPNサーバーを展開する企業がリモートVPNクライアントがアクセスする可能性のある重要なサーバのグローバルIPアドレスを割り当てることをお勧めします。
This document does not inherently create new security issues. Security issues known to DHCP servers and NAT devices are applicable, but not within the scope of this document. Likewise, security issues specific to remote access VPN devices are also applicable to the remote access VPN topology, but not within the scope of this document. The security issues reviewed here only those relevant to the topologies described in sections 2 and 3, specifically as they apply to private address space overlap in the topologies described.
この文書は、本質的に新しいセキュリティ問題を作成しません。 DHCPサーバーとNATデバイスに知られているセキュリティ上の問題はなく、この文書の範囲内で、適用されます。同様に、リモートアクセスVPNデバイスに固有のセキュリティ問題は、リモートアクセスVPNトポロジに適用されている、ではなく、この文書の範囲内です。セキュリティの問題は、彼らが示したトポロジにプライベートアドレス空間の重複には適用され、具体的として、ここでの唯一のセクション2と3で説明したトポロジに関連したものを検討しました。
Mistaken end host identity is a security concern present in both topologies discussed. Mistaken end host identity, described in sections 2.2.4 and 3.2.4 for each of the topologies reviewed, essentially points the possibility of application services being hijacked by the wrong application server (e.g., Mail server). Security violation due to mistaken end host identity arises principally due to critical servers being assigned RFC 1918 private addresses. The recommendation suggested for both scenarios is to assign globally unique public IP addresses for the critical servers.
間違えエンドホストのアイデンティティは議論両方のトポロジに存在するセキュリティ上の問題です。セクション2.2.4、レビュートポロジのそれぞれについて3.2.4に記載誤っエンドホストアイデンティティは、本質的に間違ったアプリケーションサーバ（例えば、メールサーバ）によってハイジャックされているアプリケーションサービスの可能性を指します。誤解エンドホストIDにセキュリティ違反が原因クリティカルなサーバに主に発生するRFC 1918のプライベートアドレスが割り当てられています。勧告は、両方のシナリオのために提案され、重要なサーバに対してグローバルに一意のパブリックIPアドレスを割り当てることです。
It is also recommended in section 2.1.2 that applications adapt end-to-end authentication and not depend on source IP address for authentication. Doing this will thwart connection hijacking and denial-of-service attacks.
また、アプリケーションは、エンドツーエンドの認証を適応し、認証用の送信元IPアドレスに依存しないセクション2.1.2で推奨されます。こうすることで、接続の乗っ取りやサービス拒否攻撃を阻止します。
The authors wish to thank Dan Wing for reviewing the document in detail and making helpful suggestions in reorganizing the document format. The authors also wish to thank Ralph Droms for helping with rewording the text and Recommendation-1 in section 3.2.4 and Cullen Jennings for helping with rewording the text and Recommendation-3 in section 4.2.2.
作者は詳細に文書をレビューし、文書フォーマットの再編成に役立つ提案を行うためのダン・ウィングに感謝したいです。著者らはまた、セクション4.2.2におけるテキスト及び勧告-3をrewordingを助けるためのセクション3.2.4とカレンジェニングスのテキストと勧告-1をrewordingを助けるためラルフDromsに感謝したいです。
[BEH-ICMP] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.
[BEH-ICMP] Srisuresh、P.、フォード、B.、シバクマー、S.、およびS.グハ、BCP 148、RFC 5508、2009年4月、 "ICMPのためのNAT行動要件"。
[BEH-TCP] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.
[BEH-TCP]グハ、S.編、ビスワス、K.、フォード、B.、シバクマー、S.、およびP. Srisuresh、 "TCPのためのNAT行動要件"、BCP 142、RFC 5382、2008年10月。
[BEH-UDP] Audet, F., Ed., and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[BEH-UDP] Audet、F.、エド。、およびC.ジェニングス、 "ネットワークアドレス変換（NAT）ユニキャストUDPのための行動の要件"、BCP 127、RFC 4787、2007年1月。
[NAT-TERM] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[NAT-TERM] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[NAT-TRAD] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[NAT-TRAD] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、モスコウィッツ、B.、Karrenberg、D.、グルート、G.、およびE.リアド、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[DHCP] Droms、R.、 "動的ホスト構成プロトコル"、RFC 2131、1997年3月。
[NAT-PROT] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[NAT-PROT]ホールドレッジ、M.とP. Srisuresh、 "IPネットワークアドレス変換とプロトコルの合併症"、RFC 3027、2001年1月。
[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.
[RFC5735]コットン、M.およびL. Vegoda、 "特別の使用のIPv4アドレス"、BCP 153、RFC 5735、2010年1月。
Authors' Addresses
著者のアドレス
Pyda Srisuresh EMC Corporation 1161 San Antonio Rd. Mountain View, CA 94043 U.S.A.
Pyda Srisuresh EMCコーポレーション1161年サンアントニオRdを。マウンテンビュー、CA 94043 U.S.A.
Phone: +1 408 836 4773 EMail: srisuresh@yahoo.com
電話：+1 408 836 4773 Eメール：srisuresh@yahoo.com
Bryan Ford Department of Computer Science Yale University 51 Prospect St. New Haven, CT 06511
コンピュータサイエンスエール大学のブライアン・フォード部門51プロスペクトセントニューヘブン、コネチカット06511
Phone: +1-203-432-1055 EMail: bryan.ford@yale.edu
電話：+ 1-203-432-1055 Eメール：bryan.ford@yale.edu