Independent Submission P. Srisuresh
Request for Comments: 5684 EMC Corporation
Category: Informational B. Ford
ISSN: 2070-1721 Yale University
February 2010
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）设备形成的非传统网络拓扑所产生的两种部署场景。首先，通过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.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问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.
本文件受BCP 78和IETF信托有关IETF文件的法律规定（http:truster.IETF.org/license info）的约束，这些法律规定在本文件出版之日生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
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
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.
Internet最初设计为使用单个全局32位IP地址空间来唯一标识网络上的主机，允许一台主机上的应用程序寻址并启动与任何其他主机上的应用程序的通信，而不管相应主机的拓扑位置或管理域如何。然而，出于各种实际原因，互联网已经逐渐从严格遵守单一平面全局地址空间的理想状态，转向围绕大型中央“公共”地址空间聚集的较小“私有”地址空间[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. 由于Internet上主机总数爆炸式增长，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设备提供过滤功能，允许会话流仅在一个方向上穿过NAT，从私有主机到公共网络主机。这种过滤功能被广泛认为是一种安全优势。此外，NAT将主机在专用网络中的原始IP地址和端口号转换为不相关的外部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（[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]的附件。本文件的范围仅限于以下两个方面：
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地址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-TERM]了解NAT分类和术语的信息。除非以NAT类型作为前缀或另有明确说明，否则本文档中使用的术语NAT指传统NAT[NAT-TRAD]。传统的NAT有两种变体，即基本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
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
在上述场景中，Bob、Alice、Jim和CheapoISP都从上游服务提供商处获得了一个“真正的”全球可路由IP地址。Alice和Jim选择在每个公共IP地址上只连接一台机器，从而保留了最初计划的Internet体系结构，并使其主机a和B可以在整个Internet上进行全局寻址。相反，Bob购买并安装了一个典型的消费者NAT盒。Bob的NAT通过DHCP从Bob的ISP获得其外部IP地址（192.0.2.1），并自动为Bob的主机C和D创建一个专用10.1.1.x网络，充当该专用网络的DHCP服务器和默认路由器。Bob可能对IP地址一无所知；他只知道把NAT接入互联网
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.
按照ISP的指示，然后按照NAT手册的指示将他的主机插入NAT，似乎可以工作，并让他的所有主机都可以访问Internet。
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地址，并使用NAT在其众多客户之间共享这些公共IP地址。这种安排正变得越来越普遍，特别是在快速发展的发展中国家，在这些国家，互联网连接主机的爆炸式增长大大超过了ISP为其获取全球唯一IP地址的能力。CheapoISP为其专用网络选择了流行的10.1.1.x地址，因为这是[RFC1918]中专门为此目的分配的三个众所周知的专用IP地址块之一。
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.
在第1节中列出的NAT部署的三个激励措施中，后两个仍然适用于使用NAT的ISP客户，从而形成了如上图右侧所示的多级NAT拓扑。已知甚至存在三级NAT拓扑。CheapoISP的客户Ann、Mary和Lex各自通过DHCP在CheapoISP的网络（专用网络2）上获得了一个IP地址。Mary此时只连接了一台主机，但Ann和Lex各自独立购买和部署消费者NAT，方式与Bob在上面所做的相同。事实证明，这些消费者NAT也恰好为其创建的专用网络使用10.1.1.x地址，因为这些是供应商硬编码到NAT中的默认配置。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——都名义上正常工作，并且能够启动到公共Internet上具有全局可路由IP地址的任何公共服务器的连接。从这些主机到主互联网的连接仅转换两次：一次由消费者NAT（NAT-3或NAT-44）转换到CheapoISP的专用网络2的IP地址空间，然后再由CheapoISP的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
在由上述务实和经济激励措施产生的“事实”互联网地址体系结构中，只有公共互联网上的节点具有官方IP地址注册机构分配的全球唯一IP地址。不同专用网络上的IP地址通常是独立管理的——或者由
the administrator of the private network itself, or automatically by the NAT through which the private network is connected to its "upstream" service provider.
专用网络本身的管理员，或由NAT自动管理，专用网络通过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中为此目的专门分配的一个专用地址空间范围内分配IP地址，以确保专用IP地址易于区分，并且不会与正式分配给全球可路由Internet主机的公共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修改传出数据包，使数据包出现在专用网络2上，就好像它来自IP地址10.1.1.10处的NAT-3一样。当修改后的分组通过专用网络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上的所有主机都能够与公用Internet上的服务器建立客户端/服务器式的通信会话。
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
虽然这种网络组织实际上用于客户机/服务器式通信，但当客户机位于一个或多个NAT级别之后且服务器位于公共Internet上时，缺少
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.
私有网络上主机的全局可路由地址的减少使得这些主机之间的直接对等通信变得困难。例如，上面所示的网络上的两个私有主机F和H可以通过公共因特网上的知名服务器（例如主机a）彼此“相遇”并相互了解，并且希望在G和H之间建立直接通信，而不需要a转发每个分组。如果G和H只是从a保存的注册表中学习彼此的（私有）IP地址，那么它们相互连接的尝试将失败，因为G和H驻留在不同的私有网络上。更糟糕的是，如果他们的连接尝试没有得到正确的身份验证，他们可能看起来成功了，但最终与错误的主机通信。例如，G可能最终与主机F（专用网络3上碰巧与主机H具有相同的专用IP地址的主机）通话。主机H可能类似地最终无意中连接到主机I。
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
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
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。消费者需要意识到，所有私有主机必须位于单个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设备，而上面提到的问题实际上并不是问题。
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.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上都有两个接口，但NAT设备将这两个接口视为位于两个不相交的子网和路由域上。即插即用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和3以及NAT-4中的专用网络2和4）。这是因为两个NAT设备上的应用程序都不知道如何将数据包与具有相同IP地址的子网上的主机区分开来。如果NAT-3试图通过在其承载相同子网的所有物理接口上广播地址解析协议（ARP）请求，以传统方式解析相邻主机的IP地址，则NAT-3可能会在其每个物理接口上获得不同的响应。
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，并将两个接口视为位于两个不相交的路由域上，并区分从任一接口（专用或公用）上的主机启动的会话。
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将私有主机连接到公共Internet是一种相当常见的做法。许多消费者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地址引用公共Internet上的节点。例如，图1.1中的主机C位于专用网络1上，可以使用分配的IP地址直接寻址主机A、B和D。尽管主机A和B在公共Internet上，而主机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拓扑结构。在这种情况下，专用主机可以连接到公共Internet上的主机。但是，专用主机无法与所有其他专用主机连接。例如，图1.2中的主机F可以使用其分配的IP地址直接寻址主机A、B和G，但F无法寻址图中的任何其他主机。主机F尤其不能通过其分配的IP地址对主机E进行寻址，即使主机E位于F通过其连接到Internet的直接“上游”专用网络上。主机E与主机G具有相同的IP地址。然而，这种地址在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
图1.2中具有多个NAT转换的拓扑结构似乎已被破坏，因为私有主机无法直接相互寻址。然而，网络并没有中断。上的节点
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.
任何专用网络都没有直接寻址其他专用网络上节点的方法。专用网络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形成发夹会话以相互通信。每个主机使用面向Internet的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.
在多层NAT部署的某些情况下，错误的终端主机标识可能导致意外故障。考虑图1.3中的场景。图1.3描述了专用网络3中的最终用户和公共互联网之间的两个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解析器，它通过DHCP向NAT-3播发，NAT-3是安家的网关。NAT-3依次向专用网络3上的主机F（10.1.1.10）和主机G（10.1.1.11）播发10.1.1.11作为DNS解析程序。然而，当主机F向10.1.1.11发送DNS查询时，它将在本地传送到专用网络3上的主机G，而不是CheapoISP的DNS解析器。这显然是由于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
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：使用NAT设备向客户提供连接的ISP应为向客户公布的服务器分配不重叠的地址。一种方法是将全局地址分配给播发的服务器。
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
企业使用远程访问VPN允许在企业场所外工作的员工安全访问。在企业场所之外，员工可能位于其家庭办公室、酒店、会议室或合作伙伴的办公室。在所有情况下，远程站点的员工都希望能够不受阻碍地访问其公司网络和在其上运行的应用程序
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.
公司网络。这样做时，员工不应危害公司网络和网络上运行的应用程序的完整性和机密性。
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服务器通常强制实施不同形式的安全性（例如，IPsec、SSL），以保护VPN客户端和VPN服务器之间运行时流量的完整性和机密性。
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.
许多企业使用RFC1918中定义的专用地址空间部署其内部网络，并使用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|
+--------+
(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
在上述场景中，假设公司员工位于远程位置，并试图使用VPN客户端访问公司网络，公司网络使用RFC 1918中定义的10.0.0.0/8地址池进行布局，VPN服务器配置了10.1.1.0/24的地址块，为远程访问VPN客户端分配虚拟IP地址。现在，假设远程站点的员工连接到远程站点上的网络，该网络也恰好使用基于RFC1918地址空间和
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地址。边缘的许多网络使用来自RFC1918的专用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
当远程站点的员工启动其远程访问VPN客户端时，公司场所的VPN服务器要求VPN客户端进行自我验证。当身份验证成功时，VPN服务器将为客户端分配一个虚拟IP（VIP）地址，以便与公司内部网连接。从这一点开始，当VPN处于活动状态时，定向到公司内部网中主机的传出IP数据包通过VPN进行隧道传输，其中VPN服务器充当这些数据包的下一跳链路，VPN连接充当这些数据包的下一跳链路。在公司内部网中
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.
出站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客户端应该能够成功地与企业中的intranet主机建立连接。
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网络进行通信。如果没有路由器连接到Internet，远程主机无法通过本地子网访问以连接到企业的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服务器的流量路由到企业内部网。远程PC上的VPN客户端的配置应确保目标IP地址与以下任何一项匹配的IP数据包不允许通过VPN重定向：
a) IP address of the VPN client's next-hop router, used to access the VPN server.
a) VPN客户端下一跳路由器的IP地址，用于访问VPN服务器。
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：远程PC上的VPN客户端的配置应确保其目标IP地址与（A）或（b）中*任何*项匹配的IP数据包不允许通过VPN重定向：
a) IP address of the VPN client's next-hop router, used to access the VPN server.
a) VPN客户端下一跳路由器的IP地址，用于访问VPN服务器。
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”配置。“拆分VPN”配置允许远程用户运行需要与远程站点或公共Internet上的主机以及公司内部网上的主机通信的应用程序，除非与远程子网存在地址重叠。需要访问远程站点或公共Internet上的主机的应用程序不会穿越VPN，因此与穿越VPN相比，可能具有更好的性能。这对于IP语音（VoIP）和交互式游戏等对延迟敏感的应用程序非常有价值。如果直接访问远程站点或公共Internet上的主机不存在压倒一切的安全问题，则远程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链路并通过VPN服务器路由，但指向远程站点路由器和DHCP服务器的通信除外。与远程站点上的主机没有其他通信。需要访问公共互联网的应用程序也会穿越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：如果部署目标为（A），则远程PC上的VPN客户端应配置为“非拆分VPN”模式；如果部署目标为（b），则应配置为“拆分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
a) 如果目标是最大限度地提高与公司网络连接的安全性和可靠性，则远程PC上的VPN客户端应配置为“非拆分VPN”模式。“非拆分VPN”模式确保VPN客户端引导所有流量
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.
从远程用户到VPN服务器（在公司站点），但指向远程站点路由器和DHCP服务器的流量除外。
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) 如果直接访问远程站点或公共Internet上的主机不存在压倒一切的安全问题，则远程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地址重叠。作为一般规则，不建议VIP地址与远程用户本地子网中的任何IP地址重叠，因为远程PC上的VPN客户端可能会被迫响应远程站点上的ARP请求，并且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地址与远程站点地址空间冲突的规定，并在具有不同子网的两个或多个地址池之间切换，以便分配的VIP地址不会与远程站点的地址空间冲突。建议部署支持此类供应商配置的VPN的企业使用至少两个不同的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.
或者，企业可以部署两个或多个具有不同地址池的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地址池的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.
当在远程PC上的VPN客户端上配置“拆分VPN”时，由于身份错误，可能存在潜在的安全威胁。例如，在公司站点和远程站点上，在完全相同的IP地址上配置了特定的服务（例如SMTP邮件服务）。用户可能在不知情的情况下使用远程站点上的服务，从而侵犯与该应用程序相关的内容的完整性和机密性。远程用户邮件可能会被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：当在远程PC的VPN客户端上配置“拆分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供应商参考BEHAVE协议文件（[BEH-UDP]、[BEH-TCP]和[BEH-ICMP]），以获取NAT设备一致性要求的全面列表。
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：使用NAT设备向客户提供连接的ISP应为向客户公布的服务器分配不重叠的地址。一种方法是将全局地址分配给播发的服务器。
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地址与（A）或（b）中*任何*项匹配的IP数据包不允许通过VPN重定向：
a) IP address of the VPN client's next-hop router, used to access the VPN server.
a) VPN客户端下一跳路由器的IP地址，用于访问VPN服务器。
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：如果部署目标为（A），则远程PC上的VPN客户端应配置为“非拆分VPN”模式；如果部署目标为（b），则应配置为“拆分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客户端将所有流量从远程用户定向到VPN服务器（在公司站点），但定向到远程站点路由器和DHCP服务器的流量除外。
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) 如果直接访问远程站点或公共Internet上的主机不存在压倒一切的安全问题，则远程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地址池的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：当在远程PC的VPN客户端上配置“拆分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节中针对所审查的每种拓扑所述的错误的终端主机标识，本质上指出了应用程序服务被错误的应用程序服务器（如邮件服务器）劫持的可能性。由于终端主机标识错误而导致的安全违规主要是由于为关键服务器分配了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详细审查了该文件，并在重新组织文件格式方面提出了有益的建议。作者还希望感谢拉尔夫·德罗姆斯（Ralph Droms）帮助改写第3.2.4节中的文本和建议-1，以及库伦·詹宁斯（Cullen Jennings）帮助改写第4.2.2节中的文本和建议-3。
[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，“单播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，“私人互联网地址分配”，BCP 5，RFC 1918，1996年2月。
[DHCP] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[DHCP]Droms，R.，“动态主机配置协议”，RFC 21311997年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，“特殊用途IPv4地址”，BCP 153，RFC 57352010年1月。
Authors' Addresses
作者地址
Pyda Srisuresh EMC Corporation 1161 San Antonio Rd. Mountain View, CA 94043 U.S.A.
美国加利福尼亚州山景城圣安东尼奥路1161号Pyda Srisuresh EMC公司，邮编94043。
Phone: +1 408 836 4773
EMail: srisuresh@yahoo.com
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，康涅狄格州纽黑文，邮编：06511
Phone: +1-203-432-1055
EMail: bryan.ford@yale.edu
Phone: +1-203-432-1055
EMail: bryan.ford@yale.edu