posts - 297,  comments - 15,  trackbacks - 0
NAT的优点不必多讲,它提供了一系列相关技术来实现多个内网用户通过一个公网ip和外部通信,有效的解决了ipv4地址不够用的问题.那么位于NAT后 的用户使用私网ip真的和使用公网ip一样吗?NAT解决了所有地址转换的相关问题了吗?
下面主要讲一些NAT不支持的方面,以及所谓的NAT 的"缺陷".

一些应用层协议(如TCP和SIP),在它们的应用层数据中需要包含公网IP地址.拿FTP来说吧,众所周知,FTP是通过 两个不同的连接来传输控制报文和数据报文的.当传输一个文件时,FTP服务器要求通过控制报文得到即将传输的数据报文的网络层和传输层地址 (IP/PORT).如果这个时候客户主机是在NAT之后的,那么服务器端收到的ip/port将会是NAT转化前的私网IP地址,从而会导致文件传输失 效.
SIP(Session Initiation Protocol)主要是来控制音频传输的,这个协议也面临同样的问题.因为SIP建立连接时,需要用到几个不同的端口来通过RTP传输音频流.而且这些 端口以及IP会被编码到音频流中,传输给服务器端,从而实现后续的通信.
如果没有一些特殊的技术(如STUN),那么NAT是不支持这些协议的, 这些协议经过NAT也肯定会失败.
Some Application Layer protocols (such as FTP and SIP) send explicit network addresses within their application data. FTP in active mode, for example, uses separate connections for control traffic (commands) and for data traffic (file contents). When requesting a file transfer, the host making the request identifies the corresponding data connection by its network layer and transport layer addresses. If the host making the request lies behind a simple NAT firewall, the translation of the IP address and/or TCP port number makes the information received by the server invalid. The Session Initiation Protocol (SIP) controls Voice over IP (VoIP) communications and suffers the same problem. SIP may use multiple ports to set up a connection and transmit voice stream via RTP. IP addresses and port numbers are encoded in the payload data and must be known prior to the traversal of NATs. Without special techniques, such as STUN, NAT behavior is unpredictable and communications may fail.

下 面讲一些特殊的技术,来使NAT支持这些特殊的应用层协议.

最直观的想法就是:既然NAT修改了IP/PROT,那么我们也修改应用层数 据中相应的IP/PORT.应用层网关(ALG)(硬件或软件都行)就是这样来解决这个问题的.应用层网关运行在设置了NAT的防火墙设备中,它会更新传 输数据中的IP/PORT.所以,应用层网关也必须能够解析应用层协议,而且对于每一种协议,可能需要不同的应用层网关来做.
Application Layer Gateway (ALG) software or hardware may correct these problems. An ALG software module running on a NAT firewall device updates any payload data made invalid by address translation. ALGs obviously need to understand the higher-layer protocol that they need to fix, and so each protocol with this problem requires a separate ALG.

另外一个解决此问题的办法就是NAT穿透.此方法主要利用STUN或 ICE等协议或者一些和会话控制相关的特有的方法来实现.理论上NAT穿透最好能够同时适用于基于TCP和基于UDP的应用,但是基于UDP的应用相对比 较简单,更广为流传,也更适合兼容一些种类的NAT做穿透.这样,应用层协议在设计的时候,必须考虑到可支持NAT穿透.但一些其他类型的NAT(比如对 称NAT)是无论如何也不能做穿透的.
Another possible solution to this problem is to use NAT traversal techniques using protocols such as STUN or ICE or proprietary approaches in a session border controller. NAT traversal is possible in both TCP- and UDP-based applications, but the UDP-based technique is simpler, more widely understood, and more compatible with legacy NATs. In either case, the high level protocol must be designed with NAT traversal in mind, and it does not work reliably across symmetric NATs or other poorly-behaved legacy NATs.


还有一些方法,比如UPnP (Universal Plug and Play) 或 Bonjour (NAT-PMP),但是这些方法都需要专门的NAT设备.
Other possibilities are UPnP (Universal Plug and Play) or Bonjour (NAT-PMP), but these require the cooperation of the NAT device.


大部分传统的客户-服务器协议(除了FTP),都不定义3层以上的数据格 式,所以,也就可以和传统的NAT兼容.实际上,在设计应用层协议的时候应尽量避免涉及到3层以上的数据,因为这样会使它兼容NAT时复杂化.
Most traditional client-server protocols (FTP being the main exception), however, do not send layer 3 contact information and therefore do not require any special treatment by NATs. In fact, avoiding NAT complications is practically a requirement when designing new higher-layer protocols today.


NAT也会和利用ipsec加密的一些应用冲突.比如SIP电话,如果有很多SIP电话设备在 NA(P)T之后,那么在电话利用ipsc加密它们的信号时,如果也加密了port信息,那么这就意味着NAPT就不能转换port,只能转换IP.但是 这样就会导致回来的数据包都被NAT到同一个客户端,从而导致通信失败(不太明白).不过,这个问题有很多方法来解决,比如用TLS.TLS是运行在第四 层(OSI模型)的,所以它不包含port信息.也可以在UDP之内来封装ipsec,TISPAN 就是用这种方法来实现安全NAT转化的.
NATs can also cause problems where IPsec encryption is applied and in cases where multiple devices such as SIP phones are located behind a NAT. Phones which encrypt their signaling with IPsec encapsulate the port information within the IPsec packet meaning that NA(P)T devices cannot access and translate the port. In these cases the NA(P)T devices revert to simple NAT operation. This means that all traffic returning to the NAT will be mapped onto one client causing the service to fail. There are a couple of solutions to this problem, one is to use TLS which operates at level 4 in the OSI Reference Model and therefore does not mask the port number, or to Encapsulate the IPsec within UDP - the latter being the solution chosen by TISPAN to achieve secure NAT traversal.


Dan Kaminsky 在2008年的时候提出NAPT还会间接的影响DNS协议的健壮性,为了避免DNS服务器缓存中毒,在NA(p)T防火墙之后的DNS服务器最好不要转换 来自外部的DNS请求(UDP)的源端口.而对DNS缓存中毒攻击的应对措施就是使所有的DNS服务器用随机的端口来接收DNS请求.但如果NA(P)T 使DNS请求的源端口也随机化,那么在NA(P)T防火墙后面的DNS服务器还是会崩溃的.
The DNS protocol vulnerability announced by Dan Kaminsky on 2008 July 8 is indirectly affected by NAT port mapping. To avoid DNS server cache poisoning, it is highly desirable to not translate UDP source port numbers of outgoing DNS requests from any DNS server which is behind a firewall which implements NAT. The recommended work-around for the DNS vulnerability is to make all caching DNS servers use randomized UDP source ports. If the NAT function de-randomizes the UDP source ports, the DNS server will be made vulnerable.

位 于NAT后的主机不能实现真的端对端的通信,也不能使用一些和NAT冲突的internat协议.而且从外部发起的TCP连接和一些无状态的协议(利用 udp的上层协议)也不能正常的进行,除非NAT所在设备通过相关技术支持这些协议.一些协议能够利用应用层网关或其他技术,来使只有一端处于NAT后的 通信双方正常通信.但要是双方都在NAT后就会失败.NAT也和一些隧道协议(如ipsec)冲突,因为NAT会修改ip或port,从而会使协议的完整 性校验失败.
Hosts behind NAT-enabled routers do not have end-to-end connectivity and cannot participate in some Internet protocols. Services that require the initiation of TCP connections from the outside network, or stateless protocols such as those using UDP, can be disrupted. Unless the NAT router makes a specific effort to support such protocols, incoming packets cannot reach their destination. Some protocols can accommodate one instance of NAT between participating hosts ("passive mode" FTP, for example), sometimes with the assistance of an application-level gateway (see below), but fail when both systems are separated from the Internet by NAT. Use of NAT also complicates tunneling protocols such as IPsec because NAT modifies values in the headers which interfere with the integrity checks done by IPsec and other tunneling protocols.


端对端的连接是 internet设计时的一个重要的核心的基本原则.而NAT是违背这一原则的,但是NAT在设计的时候也充分地考虑到了这些问题.现在基于ipv6的 NAT已经被广泛关注,但许多ipv6架构设计者认为ipv6应该摒弃NAT.
End-to-end connectivity has been a core principle of the Internet, supported for example by the Internet Architecture Board. Current Internet architectural documents observe that NAT is a violation of the End-to-End Principle, but that NAT does have a valid role in careful design. There is considerably more concern with the use of IPv6 NAT, and many IPv6 architects believe IPv6 was intended to remove the need for NAT.


由于NAT的连接追踪具有短时效性.所以在特定的地址转换关系会在一小段时间后失效, 除非遵守NAT的keep-alive机制,内网主机不时的去访问外部主机.这至少会造成一些不必要的消耗,比如消耗手持设备的电量.
Because of the short-lived nature of the stateful translation tables in NAT routers, devices on the internal network lose IP connectivity typically within a very short period of time unless they implement NAT keep-alive mechanisms by frequently accessing outside hosts. This dramatically shortens the power reserves on battery-operated hand-held devices and has thwarted more widespread deployment of such IP-native Internet-enabled devices.


一些IPS会直接提供给用户私网IP地址,这样用户就必须通过IPS的 NAT来和外部INTERNET通信.这样,用户实际上没有实现端对端通信,中间加了一个IPS的NAT,这有悖于Internet Architecture Board列出的internal核心基本原则.
Some Internet service providers (ISPs) provide their customers only with "local" IP addresses.[citation needed]Thus, these customers must access services external to the ISP's network through NAT. As a result, the customers cannot achieve true end-to-end connectivity, in violation of the core principles of the Internet as laid out by the Internet Architecture Board.

NAT 最后的一个缺陷就是:NAT的推广和使用,解决了ipv4下IP地址不够用的问题,大大的推迟了IPV6的发展.
(说它是优点好呢,还是缺陷好 呢?)
it is possible that its [NAT] widespread use will significantly delay the need to deploy IPv6

Reference:
Network address translation

from:
http://blog.chinaunix.net/u2/86590/showart.php?id=2208148
posted on 2010-07-13 15:28 chatler 阅读(869) 评论(0)  编辑 收藏 引用 所属分类: Network

只有注册用户登录后才能发表评论。
网站导航: 博客园   IT新闻   BlogJava   知识库   博问   管理


<2010年9月>
2930311234
567891011
12131415161718
19202122232425
262728293012
3456789

常用链接

留言簿(10)

随笔分类(307)

随笔档案(297)

algorithm

Books_Free_Online

C++

database

Linux

Linux shell

linux socket

misce

  • cloudward
  • 感觉这个博客还是不错,虽然做的东西和我不大相关,觉得看看还是有好处的

network

OSS

  • Google Android
  • Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This early look at the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language.
  • os161 file list

overall

搜索

  •  

最新评论

阅读排行榜

评论排行榜