浅谈对NAT技术的理解.docx

浅谈对NAT技术的理解 NAT的原理 NAT技术能够让由私有IP构成的局域网内所有的计算机通过一台具有公网IP和NAT功能的网络设备联入公网(Internet)，也就是说一个局域网就只需要一个或很少几个公网IP就行了，从而达到了节约公网IP地址的目的。 内网IP的数据包是根本不可能在公网上传播的，因为公网上的路由器都是屏蔽掉了这些私网IP的，私有IP本来就是人为保留出来专供私有网络通信用的。从另一个角度说，即使私有数据包能够到达公网目标地址，目标地址的响应包也不可能返回真正的源地址，因为源地址是私有IP，目标发送的响应包一种可能是被目标地址所在的拥有相同网络号的内网接收，一种可能就是这种子网不存在，数据包被抛弃。所以内网数据包在进入公网之前，必须被转换成公网IP，这就是NAT的功能，而且NAT技术发展到现在，已不仅局限于翻译IP地址，现在实际转换时，它不仅转换IP地址，还会???TCP/UDP端口进行转换。由于这个功能，NAT通常都位于网关计算机上，起着一种路由器的作用。 下面是NAT转换机制的基本过程(假如局域网的NAT设备公网IP是85，私有IP是，现在客户机8要通过NAT设备访问的网页，的IP是5)。 当客户机8通过IE向发出请求时，它发出的数据包含有下面的信息： 源地址和源端口：8:1234 目标地址和目标端口：5:80 当这个数据包到达NAT设备时，它会检测到这个数据包是要发向公网的，所以它会对源IP地址和端口进行修改(转换)，并在映射表中新建IP和端口的映射条目，然后再把修改的数据包转发出去，下面就是修改后数据包的相关信息： 源：85:8999 目标：5:80 (无需变) 当响应时，它会把数据包发给NAT设备，它的数据包含有下面的信息： 源：5:80 目：85:8999 当NAT设备收到响应时，它会检查它的IP地址/端口映射表，并且会找到85:8999与8:1234的映射条目，于是它又修改数据包，然后把数据包转发给8。相关数据包信息如下： 源：5:80 目：8:1234 从上面可以看出，最开始发起连接的内网计算机(这里是8)对网关进行NAT的转换工作是一无所知的，它根本就不知道网关对它的数据包“做了手脚”，上面所讲的可以说是最理想的转换，这种转换对IP地址和端口信息只存在于IP首部和TCP/UDP首部的数据包是非常适合的，但恰恰这个世界是复杂的，网络世界也不例外，每种技术都会有它的缺陷，下面就来看看NAT所面临的网络连接问题。 NAT的缺陷 NAT是置于两网间的边界，其功能是将外网可见的IP地址与内网所用的地址相映射，这样，每一受保护的内网可重用特定范围的IP地址(192.168.0.x)，而这些地址是不用于公网的。从外网来的含公网地址信息的数据包先到达NAT，NAT使用预设好的规则(其组元包含源地址、源端口、目的地址、目的端口、协议)来修改数据包，然后再转发给内网接受点。对于流出内网的数据包也须经过这样的转换处理。从安全性上来看NAT提供了对外隐藏内网拓扑的一个手段，但也给VoIP应用带来巨大的麻烦。voip协议消息包一般是在特定区段中内嵌IP地址和端口号，而不是放置在IP包头，这样如果仅仅使用NAT，协议里的IP和端口号不能指向正确的地方。虽然可以利用应用层网关等技术来解决，但是针对H.323这种采用的是编码格式的协议来说，需要支付非常高昂的代价。 比如我们在NAT设备后使用MSN Messenger进行语音聊天时却往往不能成功，其实这就是NAT惹的祸。NAT的缺陷主要表现在以下几方面。 (1) 不能处理嵌入式IP地址或端口 NAT设备不能翻译那些嵌入到应用数据部分的IP地址或端口信息，它只能翻译那种正常位于IP首部中的地址信息和位于TCP/UDP首部中的端口信息。由于对方会使用接收到的数据包中嵌入的地址和端口进行通信，这样就可能产生连接故障，如果通信双方都是使用的公网IP，这不会造成什么问题，但如果那个嵌入式地址和端口是内网的，显然连接就不可能成功，原因就如开篇所说的一样。MSN Messenger的部分功能就使用了这种方式来传递IP和端口信息，这样就导致了NAT设备后的客户端网络应用程序出现连接故障。 要解决上面的嵌入式地址和端口问题，现在大多数都是通过特定的NAT编辑器来实现的，比如windows 2000就提供了针对FTP、PPTP、ICMP和TCP上NETBIOS各自的NAT编辑器，按照这种方法，每个应用协议都需要一个独立的NAT编辑器，但应用协议如此众多，显然这种方法不可能满足所有需求，所以我们仍需要更完美的解决方案，下面将会讲到。 (2) 不能从公网访问内部网络服务 网络服务，比如WEB服务，对于这个问题，我们可以采用建立静态映射的方法来