NAT打洞

NAT(Network Address Translation)是一种广域网的接入技术,将私有地址转换为合法的公共IP地址,可以完美的解决IP地址不足问题,而且还能有效避免来自外部网络的攻击,隐藏并保护网络内部的计算机。

NAT的功能通常被集成到路由器、防火墙、ISDN路由器或者单独的NAT设备中。

一、NAT有三种实现方式:

1. 静态转换:即1对1。好处是外部可以访问内部网络;

2. 动态转换:多内部IP对几个外部IP,动态适配。无法实现对网络内部主机的访问;

3. 端口多路复用:即PAT,在NAT中保留NAT内部端口的映射,并向NAT外部端口转换,可以实现多对1,也是最常用的;

4. 几种方法的组合。比如 动态地址+端口复用:一些FTP网站考虑到服务器性能和Internet连接带宽占用问题,会限制同一个IP地址的多线程访问,此时如果只采用端口复用,造成同一外部IP的多个内部主机同时访问Internet,目的网站有可能禁掉该IP。所以最好采用与动态地址相结合的方案(如果有多个公共IP的话)。

二、NAT端口转换的几种方法:

1. Full cone NAT:即一对一NAT,一旦一个内部地址(iADDr:port1)映射到外部地址(eAddr:port2),所有发自iADDr:port1的包都经过eAddr:port2向外发送。同时,任意的外部主机都能通过eAddr:port2发包到(即访问)iADDr:port1。

2. Address-Restricted cone NAT:一旦一个内部地址(iADDr:port1)映射到外部地址(eAddr:port2),所有发自iADDr:port1的包都经过eAddr:port2向外发送。同时,任意的外部主机都能通过eAddr:port2发包到(即访问)iADDr:port1,但有个前提,即,iAddr:port1之前向该外部主机发过包(外部主机的端口不受限制,即之前发送到的外部主机端口和当下访问内部网络的外部主机端口可以不同)。

3. Port-Restricted cone NAT:与2类似,但是要求外部主机的端口保持一致。

4. Symmetric NAT:内网主机建立一个socket(iAddr:prot0),当用这个socket第一次发送数据给外部主机1时,NAT为其映射一个(eAddr1:port1),如果内网主机同时用这个socket向主机2发送数据,NAT为其分配一个(eAddr2:port2),以后发往主机1和主机2的数据分别使用这两个socket。如果NAT有多于一个公网IP,则eAddr1和eAddr2可能不同,如果NAT只有一个公网IP,则port1和port2肯定不同,也就是说,一定不能是eAddr1等于eAddr2且port1等于port2。同时,如果任何外部主机向要发送数据给这个内网主机,那它首先应该收到内网主机发送给他的数据,然后才能往回发送,否则即使知道内网主机的一个映射socket也不能发送数据给内网主机。这种NAT无法实现P2P通信。但是如果另一方是Full cone NAT的话,还是可以穿透的。

三、NAT打洞

NAT打洞发生在当两个主机位于不同的局域网中时,假设分别为A和B,根据几种端口转换方法的特点(除了Full cone NAT),如果没有中间设备(位于外网)辅助的话,A和B永远无法通信。因此,假设有位于公网的中间服务器S,A和B首先会连接到S,S分别记录A和B经过NAT后的IP和端口,当A想要连接到B时,首先向S发出请求,S把B经过NAT后的IP和端口告诉A,同时向B发送A经过NAT后的IP和端口,并要求B发送数据给A,B发送给A的数据会被A的NAT抛弃,但是B的NAT会有B发送数据到A的记录,此时A再向B发送数据时就会被B的NAT放行。也就是说当A向B发送数据时,唯一的阻碍是NAT_B,要想发送成功,必须先把NAT_B打一个洞,这样NAT_B就会误以为A发送的数据是上次会话的一部分而不予阻拦。

关于打洞的分析:

1. 以上的分析是针对双方都是2,3,4的情形。只要A或B有一方为Full cone NAT,那么即可实现双向通信,不需要打洞。

2. 只要两侧NAT都不属于Symmetric NAT,可以打通,也就是说,只要两侧NAT都属于cone NAT,即可双向通信。

3. 一侧属于Symmetric NAT,而另一侧属于Restricted cone,可以打通;

4. 一侧属于Symmetric NAT,而另一侧属于Port-Restricted cone,打不通;(由于Symmetric NAT会使到不同目的主机的端口不同,此时C告知B的A的端口不是A真正发往B的端口,同时Port-Restricted cone要求前后端口一致,而实际上是不一致的,因此打不通)

5. 两侧都属于Symmetric NAT,打不通。

通常来说,只有比较注重安全的大公司会使用Symmetric NAT,禁止使用P2P类型的通信,很多地方使用的都是cone NAT,因此基本都能穿透。

出处:http://blog.csdn.net/woshishuizzz/article/details/8447920

参考:http://wenku.baidu.com/view/6a7892daad51f01dc281f127.html

时间: 2024-10-22 19:53:08

NAT打洞的相关文章

NAT路由打洞机制

  首先要注意,路由器有一个保护机制,就是不会无缘无故的接受陌生的IP发送过来的SYN包   NAT打洞机制:   1. 当前客户端A想和客户端B建立连接,服务器开了两个端口,一个是主连接端口,一个是辅助连接端口   2. 首先,A,B与主连接端口建立连接.这个时候A要和B建立连接,首先A要和协助端口建立连接,然后在这个端口启动监听   3. 然后服务器主连接将A经过NAT-A转换的公网IP和端口号发送给B,B收到之后首先和协助端口建立连接,发送一些数据之后断开,目的是让服务器知道B经过NAT-

UDP打洞、P2P组网方式研究

catalogue 1. NAT概念 2. P2P概念 3. UDP打洞 4. P2P DEMO 5. ZeroNet P2P 1. NAT概念 在STUN协议中,根据内部终端的地址(LocalIP:LocalPort)到NAT出口的公网地址(PublicIP:PublicPort)的影射方式,把NAT分为四种类型(rfc3489: http://www.ietf.org/rfc/rfc3489.txt) 1. Full Cone: 这种NAT内部的机器A连接过外网机器C后,NAT会打开一个端口

P2P UPD打洞原理

转自:http://blog.pfan.cn/fengfei/18828.html 首先先介绍一些基本概念:            NAT(Network Address             Translators),网络地址转换:网络地址转换是在IP地址日益缺乏的情况下产生的,它的主要目的就是为了能够地址重用.NAT分为两大类,基本的NAT和NAPT(Network             Address/Port Translator).            最开始NAT是运行在路由器

P2P应用中的NAT穿透问题

多年前曾经写过一个关于NAT钻洞的实验.现在发现那个做法在我现在的路由器上已经不管用了.经过一番搜索发现时过境迁,世界变化很快,新路由器已经是UPnP了.在这里重新理一下几种方法. 第一种,也是不太靠谱的一种,因为没有特定的标准.这种方法依靠路由器的特定逻辑: – 路由器尽可能保持内部端口和外部端口一致.所以你可以假设自己的内部端口就是外部端口.或者路由器尽量使用同一外部端口对应某一内部端口.– 在内部应用发出UDP消息后,路由器允许任何外部设备通过上述外部端口发送消息到同一内部端口.– 外部I

UDP 打洞 原理解释

终于找到了一份满意的UDP打洞原理解释,附上正文,自己整理了一下源码 3.3. UDP hole punching UDP打洞技术 The third technique, and the one of primary interest in this document, is widely known as "UDP Hole Punching." UDP hole punching relies on the properties of common firewalls and c

ICE协议下NAT穿越的实现(STUN&TURN)

正文: 一. 首先来简单讲讲什么是NAT? 原来这是因为IPV4引起的,我们上网很可能会处在一个NAT设备(无线路由器之类)之后.NAT设备会在IP封包通过设备时修改源/目的IP地址. 对于家用路由器来说, 使用的是网络地址端口转换(NAPT), 它不仅改IP, 还修改TCP和UDP协议的端口号, 这样就能让内网中的设备共用同一个外网IP. 举个例子, NAPT维护一个类似下表的NAT表: NAT映射 NAT设备会根据NAT表对出去和进来的数据做修改, 比如将192.168.0.3:8888发出

实战rfc5766-turn-server和ice4j广域网通讯

前段时间上手了NAT打洞类库ice4j(ICE框架),当时使用了numb.viagenie.ca的公共STUN服务器.最近又编译了rfc5766-turn-server,于是今天将两者结合起来,一个作为服务端,一个作为Peer端的协议,试验广域网穿透多级路由即时点对点通讯,并取得了成功.服务端编译安装rfc5766-turn-server是谷歌推荐的turn开源项目,经常作WebRTC的服务器端使用.关于rfc5766-turn-server在Windows或Ubuntu(Linux)下的编译,

Android WebRTC 音视频开发总结

www.cnblogs.com/lingyunhu/p/3621057.html 前面介绍了WebRTCDemo的基本结构,本节主要介绍WebRTC音视频服务端的处理,,转载请说明出处(博客园RTC.Blacker). 通过前面的例子我们知道运行WebRTCDemo即可看到P2P的效果,实际应用中我们不可能让用户自己去里面设置对方的IP和音视频端口, 而且即使设置了对方的IP和端口也不一定能运行起来,因为P2P如果双方不在同一个网段则还需穿透NAT,那服务端具体该如何部署呢? 1.信令服务: 想

Android IOS WebRTC 音视频开发总结(九)

下面这篇介绍webrtc的文章不错,我花了大半天翻译了一下. 翻译的时候不是逐字逐句的,而是按照自己的理解翻译的,同时为了便于理解,也加入一些自己组织的语言. 本文主要介绍webrtc的信令,stun,turn (转载请说明出处: http://www.cnblogs.com/lingyunhu). 英文来自:http://www.html5rocks.com/en/tutorials/webrtc/infrastructure/ WEBRTC支持点对点通讯,但是WEBRTC仍然需要服务端,因为