[要約] 要約：RFC 5684は、重複するアドレス空間を持つNATデプロイメントの予期しない結果について説明しています。 目的：このRFCの目的は、重複するアドレス空間を使用するNATデプロイメントに関連する問題を特定し、解決策を提案することです。
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
オーバーラップアドレス空間を伴うNAT展開の意図しない結果
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エディターは、このドキュメントの裁量でこのドキュメントを公開することを選択しており、実装または展開に対する価値について声明を発表しません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5684で取得できます。
Copyright
著作権
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http：trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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.
1. インターネット上のホストの総数が爆発するため、32ビットIPv4アドレス空間の枯渇。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デバイスは、プライベートホストからパブリックネットワークホストまで、セッションフローを一方向に渡すことを可能にするフィルタリング機能を提供します。このフィルタリング機能は、セキュリティ利益として広く認識されています。さらに、プライベートネットワーク内のホストの元のIPアドレスとポート番号のNATが無関係の外部IPアドレスとポート番号に翻訳されているのは、プライバシーの利点と見なされます。
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ベンダーは、多くの場合、NAT機能を同じデバイスのDHCPサーバー関数と組み合わせることがよくあります。IPサブネットを構成するよりも、洗練されていない消費者にとって実際に簡単です。市場に出回っている多くの人気のある安価な消費者NATデバイスは、通常、DHCPを介してISPまたは「上流」ネットワークから単一の「パブリック」IPアドレス（[DHCP]）と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 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.
[Nat-Prot]は、NATデバイスによるアプリケーションプロトコルとのさまざまな合併症を特定します。このドキュメントは、[Nat-Prot]の補助として機能します。ドキュメントの範囲は、型破りなNAT展開とプライベートアドレススペースの重複から生じるセクション3および4で特定された2つのシナリオに制限されています。シナリオは型破りなように見えますが、見つけることは珍しくありません。各シナリオについて、ドキュメントは見かけの異常を説明し、トポロジを機能させる最善の方法に関する推奨事項を提供します。
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アドレス192.0.2.1、192.0.2.64、192.0.2.128、および192.0.2.254がパブリックIPアドレスの例として使用されています[RFC5735]。これらのアドレスはすべて同じ /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トラッド]を指します。従来のNATには、基本的なNATおよびネットワークアドレスポート翻訳者（NAPT）の2つのバリエーションがあります。これらのうち、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.
上記のシナリオでは、Bob、Alice、Jim、およびCheapoispはそれぞれ、上流のサービスプロバイダーから「本物の」グローバルにルーティング可能なIPアドレスを取得しています。アリスとジムは、これらのパブリックIPアドレスのそれぞれに単一のマシンのみを添付することを選択し、インターネットの元々意図されたアーキテクチャを保存し、インターネット全体でグローバルにアドレス指定できるホストのAとBを作成します。対照的に、ボブは典型的な消費者NATボックスを購入して添付しています。Bob's Natは、DHCP経由のBoBのISPから外部IPアドレス（192.0.2.1）を取得し、BobのホストCおよびDのプライベート10.1.1.xネットワークを自動的に作成し、このプライベートネットワークのDHCPサーバーおよびデフォルトルーターとして機能します。ボブはおそらくIPアドレスについて何も知らないでしょう。彼は、ISPが指示したようにNATをインターネットに接続することを知っているだけで、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は、世界的にルーティング可能なIPアドレスを1つまたはいくつか割り当て、NATを使用して多くの顧客の間でこれらのパブリックIPアドレスを共有しています。このような取り決めは、特に急速に発展途上国ではますます一般的になりつつあります。この国では、インターネットに取り付けられたホストの爆発的な数が、ISPがグローバルにユニークなIPアドレスを取得する能力を大幅に上回っています。CheapOispは、プライベートネットワークの人気のある10.1.1.xアドレスを選択しました。これは、この目的のために特別に[RFC1918]に割り当てられた3つの有名なプライベートIPアドレスブロックの1つであるためです。
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つのインセンティブのうち、最後の2つはNATを使用するISPの顧客にも適用され、上記の図の右側に示されているようにマルチレベルのNATトポロジーをもたらします。3レベルのNATトポロジーでさえ存在することが知られています。Cheapoispの顧客Ann、Mary、およびLexは、それぞれDHCPを介してCheapoispのネットワーク（プライベートネットワーク2）で単一のIPアドレスを取得しています。メアリーはこの時点で1人のホストのみを添付していますが、アンとレックスはそれぞれ、ボブが上に行ったのと同じように消費者NATを独立して購入して展開します。結局のところ、これらの消費者NATは、ベンダーによってNATにハードコーディングされた構成デフォルトであるため、作成したプライベートネットワークに10.1.1.xアドレスを使用します。AnnとLexはおそらく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.
それにもかかわらず、この直接的な重複にもかかわらず、この場合、すべての「マルチレベルのネートホスト」（F、G、H、およびI）はすべて名目上機能し、パブリックインターネット上のパブリックサーバーへの接続を開始できます。世界的にルーティング可能なIPアドレスがあります。これらのホストからメインインターネットへの接続は、単に2回翻訳されています。1回は消費者NAT（NAT-3またはNAT-44）がCheapoispのプライベートネットワーク2のIPアドレススペースに、そしてcheapoispのNAT-2によってパブリックインターネットのNAT-2に再びグローバル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アドレスを持っています。さまざまなプライベートネットワークのIPアドレスは、通常、個別に管理されます。プライベートネットワーク自体の管理者によって手動で、またはプライベートネットワークが「上流」サービスプロバイダーに接続されているNATによって自動的に管理されます。
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.
慣習により、プライベートネットワーク上のノードは通常、RFC 1918でこの目的に特別に割り当てられたプライベートアドレススペース範囲の1つにIPアドレスが割り当てられ、プライベートIPアドレスが簡単に区別できることを保証し、グローバルにグローバルに割り当てられたパブリック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はそのセッションで構成されるパケットをインターセプトします（通常、デフォルトのルーターであることの結果としてプライベートネットワーク）、およびパケットのIPおよびTCP/UDPヘッダーを変更して、セッションがNAT自体によって開始されたかのように外部から表示されるようにします。
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でホストAへの接続を開始すると、NAT-1はセッションを構成するパケットを変更して、セッションがNAT-1から発生したかのように表示されます。同様に、プライベートネットワーク3のホストFがホストAへの接続を開始すると、NAT-3が発信パケットを変更するため、パケットはIPアドレス10.1.1.10でNAT-3から発信されたかのようにプライベートネットワーク2に表示されます。修正されたパケットがプライベートネットワーク2でNAT-2を横断すると、NAT-2は、パブリックIPアドレス192.0.2.254で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.
このネットワーク組織は、クライアント/サーバースタイルの通信のために実際に機能しますが、クライアントが1つ以上のレベルのNATとサーバーがパブリックインターネット上にあるとき、プライベートネットワーク上のホストのグローバルにルーティング可能なアドレスがないため、直接ピアを作成します。これらのホスト間の間の間の間のコミュニケーションは困難です。たとえば、上記のネットワーク上の2人のプライベートホストFとHは、ホストAなどのパブリックインターネット上のよく知られているサーバーを介して「出会って互いに学習する可能性があり、GとHなしでGとHの間の直接的なコミュニケーションを確立したいという願望各パケットを転送する必要があります。GとHがAが保持しているレジストリからお互いの（プライベート）IPアドレスを単に学習した場合、GとHが異なるプライベートネットワークに存在するため、相互に接続しようとする試みは失敗します。さらに悪いことに、彼らの接続の試みが適切に認証されていない場合、彼らは成功するように見えるかもしれませんが、間違ったホストと話すことになります。たとえば、Gは、ホストHと同じプライベートIPアドレスを持っているプライベートネットワーク3のホストであるホストFと話すことになります。
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を2つのサブ図に分割して、異常をよりよく説明します。図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デバイスは、あるインターフェイスでDHCPサービスを提供し、NAT機能は別のインターフェイスで機能します。消費者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に接続されていると想定しています。消費者は、すべてのプライベートホストが1つの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サービスを提供し、同じプライベートアドレスプールからの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.
結局のところ、ほとんどの消費者展開には単一のLANがあり、そこにはプラグアンドプレイNATデバイスを展開しており、上記の懸念は現実には問題ではありませんでした。
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に面した外部インターフェイスを介してサブネット10.1.1/24に、およびクライアントに面したプライベートインターフェイスホストFとホストGを介して搭載されています。同様に、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）にある必要があると仮定するのは自然です。明らかに、それはここではそうではありません。NAT-3と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の両方は、隣接するネットワーク上の他のノードとトランスポートエンドポイントとして確実に通信することができないはずです（たとえば、NAT-3およびプライベートの場合のプライベートネットワーク2および3NAT-4の場合のネットワーク2および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).
NAT-3とNAT-4の両方が隣接するネットワーク上の同じIPアドレスを持つホストを持っていますが、NATデバイスはエンドポイントとして効果的に通信します。プラグアンドプレイNATデバイスの多くは、それらに限られた数のサービスを提供しています。たとえば、NATデバイスの多くは、いずれかのインターフェイスのホストからのpingに応答します。NATデバイスは積極的に管理されていないことがよくありますが、NATデバイスの多くはプライベートインターフェイスから管理されるように装備されています。NATデバイスとのこの型破りな通信は、NATデバイスの多くが[Beh-udp]のReq-7に準拠しており、2つの分離ルーティングドメインにある2つのインターフェイスを表示し、インターフェイスのホストから開始されたセッションを区別するため、2つのインターフェイスを表示するため、達成可能です。公共）。
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には図内の他のホストに対処する方法はありません。特にホストFは、Host Eがインターネットに接続されているすぐに「上流」プライベートネットワークにあるにもかかわらず、割り当てられたIPアドレスでホストEに対処できません。ホストEはホストGと同じIPアドレスを持っています。しかし、2つのホストは異なるプライベートネットワーク上にあるため、このアドレス指定はNATの世界では「合法」です。
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のエンドユーザーとパブリックインターネットの2つのレベルのNATを示しています。
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が10.1.1.11をDNS Resolverに割り当て、DHCPを介してAnnの家のゲートウェイであるNAT-3に宣伝するとします。NAT-3は、プライベートネットワーク3でF（10.1.1.10）とホストG（10.1.1.11）をホストするDNSリゾルバーとして10.1.1.11を順番に宣伝します。ただし、ホストFがDNSクエリを10.1.1.11に送信すると、CheapoispのDNS Resolverではなく、プライベートネットワーク3でGをホストするためにローカルに配信されます。これは明らかに、Cheapoispが顧客のIPアドレスと潜在的に重複する可能性のあるサーバーを宣伝するため、誤ったアイデンティティのケースです。
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トポロジの誤ったサーバーアイデンティティ
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：ISPは、NATデバイスを使用して顧客への接続を提供するため、顧客に宣伝されているサーバーに重複しないアドレスを割り当てる必要があります。これを行う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）などのアプリケーションは、Simple Source-IP-Addressベースのフィルタリングに依存して、企業ユーザーへのアクセスを制限しています。これらは、リモートアクセスVPNサーバーが、Corporate Private Networkからの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 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クライアントを使用してコーポレートネットワークにアクセスしようとするとすると、コーポレートネットワークは、RFC 1918で定義されている10.0.0.0/8のアドレスプールを使用してレイアウトされています。VPNサーバーは、10.1.1.0/24のアドレスブロックで構成されており、仮想IPアドレスをリモートアクセスVPNクライアントに割り当てます。これで、リモートサイトの従業員がリモートサイトのネットワークに添付されているとします。これは、RFC 1918アドレススペースに基づいてネットワークを使用しており、偶然にもコーポレートネットワークと重複しています。このシナリオでは、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がアクティブである間、企業イントラネットのホストに向けられた発信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クライアントは、IPパケットをエンタープライズホストにアドレス指定し、VPNを介したDHCP更新パケットをリモートVPNサーバーにトンネルしていることを誤って識別します。。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サーバーに向けられたトラフィックを、企業イントラネットにリダイレクトすることは望ましくありません。ターゲットIPアドレスが次のいずれかと一致するIPパケットがVPNを介してリダイレクトされるように許可されていないように、リモートPCのVPNクライアントを構成する必要があります。
a) IP address of the VPN client's next-hop router, used to access the VPN server.
a) VPNサーバーへのアクセスに使用されるVPNクライアントのNext-HopルーターのIPアドレス。
b) IP address of the DHCP server, providing address lease on the remote host network interface.
b) DHCPサーバーの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：ターゲットIPアドレスが（a）または（b）の任意の * *または（b）がVPN上でリダイレクトされることを許可されていないIPパケットのリモートPCのVPNクライアントを構成する必要があります。
a) IP address of the VPN client's next-hop router, used to access the VPN server.
a) VPNサーバーへのアクセスに使用されるVPNクライアントのNext-HopルーターのIPアドレス。
b) IP address of the DHCP server, providing address lease on the remote host network interface.
b) DHCPサーバーの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」構成と呼ばれます。「Split VPN」構成により、リモートユーザーは、リモートサブネットとのアドレスオーバーラップがない限り、リモートサイトまたはパブリックインターネットでホストとの通信を必要とするアプリケーションを実行できます。リモートサイトまたはパブリックインターネットでホストにアクセスする必要があるアプリケーションは、VPNを横断することはないため、VPNを横断するのと比較すると、パフォーマンスが向上する可能性があります。これは、Voice over IP（VoIP）やインタラクティブゲームなどの遅延に敏感なアプリケーションにとって非常に価値があります。リモートサイトまたはパブリックインターネットでホストに直接アクセスするためのオーバーライドセキュリティの懸念がない場合、リモートPCのVPNクライアントは「Split 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：リモートPCのVPNクライアントは、展開目標が（a）の場合は「非スプリット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.
b) リモートサイトまたはパブリックインターネットでホストに直接アクセスするためのオーバーライドセキュリティの懸念がない場合、リモートPCのVPNクライアントは「Split VPN」モードで構成する必要があります。「Split 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アドレスと重複することをお勧めしません。一般的なルールとして、VIPアドレスがリモートユーザーのローカルサブネットのIPアドレスを重複させることはお勧めできません。リモートPCのVPNクライアントは、リモートサイトのARP要求に応答することを余儀なくされ、VPNクライアントはVPNクライアントが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アドレスの競合を検出するための規定を提供し、異なるサブネットを持つ2つ以上のアドレスプールを切り替えるため、割り当てられたVIPアドレスはリモートサイトのアドレススペースと競合しません。このタイプのベンダープロビジョニングをサポートする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ソリューションを展開する企業は、リモートサイトでのサブネットとのVIPアドレスの競合を回避するために、（a）または（b）の戦略を適合させることをお勧めします。
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サーバーが2つ以上のアドレスプールを構成するようにプロビジョニングされている場合、最低2つの異なる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.
「Split 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クライアントは、リモートアタッチメントポイントで使用されるプライベートアドレススペースに関係なく、常に重要なサーバーにアクセスできるようになります。これは、マルチレベルのNAT展開と組み合わせて提供される推奨1に似ています。
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：「Split 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デバイスの適合要件の包括的なリストについては、beveaveプロトコルドキュメント（[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トポロジーをサポートするための推奨事項の概要です。推奨事項は展開固有であり、展開を担当する担当者に宛てられています。これらの担当者には、ISP管理者とエンタープライズIT管理者が含まれます。
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：ISPは、NATデバイスを使用して顧客への接続を提供するため、顧客に宣伝されているサーバーに重複しないアドレスを割り当てる必要があります。これを行う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：ターゲットIPアドレスが（a）または（b）の任意の * *または（b）がVPN上でリダイレクトされることを許可されていないIPパケットのリモートPCのVPNクライアントを構成する必要があります。
a) IP address of the VPN client's next-hop router, used to access the VPN server.
a) VPNサーバーへのアクセスに使用されるVPNクライアントのNext-HopルーターのIPアドレス。
b) IP address of the DHCP server, providing address lease on the remote host network interface.
b) DHCPサーバーの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：リモートPCのVPNクライアントは、展開目標が（a）の場合は「非スプリット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.
b) リモートサイトまたはパブリックインターネットでホストに直接アクセスするためのオーバーライドセキュリティの懸念がない場合、リモートPCのVPNクライアントは「Split VPN」モードで構成する必要があります。「Split 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ソリューションを展開する企業は、リモートサイトでのサブネットとのVIPアドレスの競合を回避するために、（a）または（b）の戦略を適合させることをお勧めします。
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サーバーが2つ以上のアドレスプールを構成するようにプロビジョニングされている場合、最低2つの異なる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：「Split 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.
誤ったエンドのホストIDは、議論された両方のトポロジに存在するセキュリティ上の懸念事項です。レビューされた各トポロジのセクション2.2.4および3.2.4で説明されている誤ったエンドホストIDは、間違ったアプリケーションサーバー（例：メールサーバー）によってハイジャックされる可能性を本質的に指摘しています。セキュリティ違反は、誤ったエンドホスト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.
また、セクション2.1.2では、アプリケーションがエンドツーエンド認証を適合し、認証のためにソースIPアドレスに依存しないことも推奨されています。これを行うと、接続のハイジャックとサービス拒否攻撃が妨げられます。
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.
著者は、ドキュメントを詳細にレビューし、ドキュメント形式を再編成する際に有用な提案をしてくれたDan Wingに感謝したいと考えています。著者はまた、セクション3.2.4のテキストと推奨1の言い換えを手伝ってくれたRalph Dromsと、セクション4.2.2のテキストと推奨事項3の言い換えを手伝ってくれたCullen Jenningsに感謝したいと考えています。
[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.、Ford、B.、Sivakumar、S。、およびS. Guha、「ICMPのNAT行動要件」、BCP 148、RFC 5508、2009年4月。
[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] Guha、S.、Ed。、Biswas、K.、Ford、B.、Sivakumar、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.、ed。、およびC. Jennings、「Unicast UDPのネットワークアドレス変換（NAT）行動要件」、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. Holdrege、「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.、Moskowitz、B.、Karrenberg、D.、De Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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] Holdrege、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] Cotton、M。およびL. Vegoda、「Special Use 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 Corporation 1161 San Antonio Rd。マウンテンビュー、CA 94043 U.S.A.
Phone: +1 408 836 4773
EMail: srisuresh@yahoo.com
Bryan Ford Department of Computer Science Yale University 51 Prospect St. New Haven, CT 06511
ブライアンフォードコンピュータサイエンス局エール大学51プロスペクトセントニューヘイブン、CT 06511
Phone: +1-203-432-1055
EMail: bryan.ford@yale.edu