结论1:只要单侧NAT属于Full Cone NAT,即可实现双向通信。
结论2:只要两侧NAT都不属于Symmetric NAT,也可双向通信。换种说法,只要两侧NAT都属于Cone NAT,即可双向通信
结论3:一侧NAT属于Symmetric NAT,另一侧NAT属于Restricted Cone,也可双向通信。
结论4,两个都是Symmetric NAT或者一个是Symmetric NAT、另一个是Port Restricted Cone,则不能双向通信。
STUNU协议(Rfc3489、详见http://www.ietf.org/rfc/rfc3489.txt) 提出了4种NAT类型的定义及其分类,并给出了如何检测
在用的NAT究竟属于哪种分类的标准。但是,具体到P2P程序如何应用Stun协议及其分类法穿越NAT,则是仁者见仁、智者见智。
(因为STUN协议并没有给出也没有必要给出如何穿越NAT的标准)
在拙作“iptables与stun”一文中,笔者花大幅精力阐述了iptables理论上属于Symmetric NAT而非Port Restricted Cone。
对此,很多人(包括笔者最初学习Stun协议时)心中都有一个疑惑,即仅就Stun协议本身来说,Port Restricted Cone和
Symmetric NAT的区别似乎不大,虽然两者的映射机制是有点不同,但他们都具有端口受限的属性。初看起来,这两者在
穿越NAT方面的特性也差不多,尤其是对于外部地址欲往NAT内部地址发包的情况。既然如此,又为何有必要把iptables分得
这么清呢,本文顺带解决了读者在这一方面的疑惑。
网站http://midcom-p2p.sourceforge.net/给出了P2P程序具体如何穿越NAT的一个思路,并提供了一个P2P协议穿越NAT兼容性的
测试工具natcheck。让我们仍旧用实例(例1)来说明这一思路吧!
A机器在私网(192.168.0.4)
A侧NAT服务器(210.21.12.140)
B机器在另一个私网(192.168.0.5)
B侧NAT服务器(210.15.27.140)
C机器在公网(210.15.27.166)作为A和B之间的中介
A机器连接过C机器,假使是 A(192.168.0.4:5000)-> A侧NAT(转换后210.21.12.140:8000)-> C(210.15.27.166:2000)
B机器也连接过C机器,假使是 B(192.168.0.5:5000)-> B侧NAT(转换后210.15.27.140:8000)-> C(210.15.27.166:2000)
A机器连接过C机器后,A向C报告了自己的内部地址(192.168.0.4:5000),此时C不仅知道了A的外部地址
(C通过自己看到的210.21.12.140:8000)、也知道了A的内部地址。同理C也知道了B的外部地址(210.15.27.140:8000)和
内部地址(192.168.0.5:5000)。之后,C作为中介,把A的两个地址告诉了B,同时也把B的两个地址告诉了A。
假设A先知道了B的两个地址,则A从192.168.0.4:5000处同时向B的两个地址192.168.0.5:5000和210.15.27.140:8000发包
,由于A和B在两个不同的NAT后面,故从A(192.168.0.4:5000)到B(192.168.0.5:5000)的包肯定不通,现在看
A(192.168.0.4:5000)到B(210.15.27.140:8000)的包,分如下两种情况:
1、B侧NAT属于Full Cone NAT
则无论A侧NAT属于Cone NAT还是Symmetric NAT,包都能顺利到达B。如果P2P程序设计得好,使得B主动到A的包也能借用
A主动发起建立的通道的话,则即使A侧NAT属于Symmetric NAT,B发出的包也能顺利到达A。
结论1:只要单侧NAT属于Full Cone NAT,即可实现双向通信。
2、B侧NAT属于Restricted Cone或Port Restricted Cone
则包不能到达B。再细分两种情况
(1)、A侧NAT属于Restricted Cone或Port Restricted Cone
虽然先前那个初始包不曾到达B,但该发包过程已经在A侧NAT上留下了足够的记录:
A(192.168.0.4:5000)->(210.21.12.140:8000)->B(210.15.27.140:8000)。如果在这个记录没有超时之前,
B也重复和A一样的动作,即向A(210.21.12.140:8000)发包,虽然A侧NAT属于Restricted Cone或Port Restricted Cone,
但先前A侧NAT已经认为A已经向B(210.15.27.140:8000)发过包,故B向A(210.21.12.140:8000)发包能够顺利到达A。
同理,此后A到B的包,也能顺利到达。
结论2:只要两侧NAT都不属于Symmetric NAT,也可双向通信。换种说法,只要两侧NAT都属于Cone NAT,即可双向通信。
(2)、A侧NAT属于Symmetric NAT
因为A侧NAT属于Symmetric NAT,且最初A到C发包的过程在A侧NAT留下了如下记录:
A(192.168.0.4:5000)->(210.21.12.140:8000)-> C(210.15.27.166:2000),故A到B发包过程在A侧NAT上留下的记录为:
A(192.168.0.4:5000)->(210.21.12.140:8001)->B(210.15.27.140:8000)(注意,转换后端口产生了变化)。
而B向A的发包,只能根据C给他的关于A的信息,发往A(210.21.12.140:8000),因为A端口受限,故此路不通。
再来看B侧NAT,由于B也向A发过了包,且B侧NAT属于Restricted Cone或Port Restricted Cone,故在B侧NAT上留下的记录为:
B(192.168.0.5:5000)->(210.15.27.140:8000)->A(210.21.12.140:8000),此后,如果A还继续向B发包的话
(因为同一目标,故仍然使用前面的映射),如果B侧NAT属于Restricted Cone,则从A(210.21.12.140:8001)来的包能够顺利到达B;
如果B侧NAT属于Port Restricted Cone,则包永远无法到达B。
结论3:一侧NAT属于Symmetric NAT,另一侧NAT属于Restricted Cone,也可双向通信。
显然,还可得出另一个不幸的结论4,两个都是Symmetric NAT或者一个是Symmetric NAT、另一个是Port Restricted Cone,
则不能双向通信。
上面的例子虽然只是分析了最初发包是从A到B的情况,但是,鉴于两者的对称性,并且如果P2P程序设计得足够科学,
则前面得出的几条结论都是没有方向性,双向都适用的。
通过上述分析,我们得知,在穿越NAT方面,Symmetric NAT和Port Restricted Cone是有本质区别的,尽管他们表面上看起来相似。
我们上面得出了四条结论,而natcheck网站则把他归结为一条:只要两侧NAT都属于Cone NAT
(含Full Cone、Restricted Cone和Port Restricted Cone三者),即可双向通信。
而且natcheck网站还建议尽量使用Port Restricted Cone,以充分利用其端口受限的属性确保安全性。
It is assumed that the reader is familiar with NATs. It has been
observed that NAT treatment of UDP varies among implementations. The
four treatments observed in implementations are:
Full Cone: A full cone NAT is one where all requests from the
same internal IP address and port are mapped to the same external
IP address and port. Furthermore, any external host can send a
packet to the internal host, by sending a packet to the mapped
external address.
Restricted Cone: A restricted cone NAT is one where all requests
from the same internal IP address and port are mapped to the same
external IP address and port. Unlike a full cone NAT, an external
host (with IP address X) can send a packet to the internal host
only if the internal host had previously sent a packet to IP
address X.
Port Restricted Cone: A port restricted cone NAT is like a
restricted cone NAT, but the restriction includes port numbers.
Specifically, an external host can send a packet, with source IP
address X and source port P, to the internal host only if the
internal host had previously sent a packet to IP address X and
port P.
Symmetric: A symmetric NAT is one where all requests from the
same internal IP address and port, to a specific destination IP
address and port, are mapped to the same external IP address and
port. If the same host sends a packet with the same source
address and port, but to a different destination, a different
mapping is used. Furthermore, only the external host that
receives a packet can send a UDP packet back to the internal host.
Determining the type of NAT is important in many cases. Depending on
what the application wants to do, it may need to take the particular
behavior into account.
NAT的区别
本文假定读者对NAT很熟悉。目前已知各种NAT实现对UDP的处理是有差异的,共有四种不同的处理方式:
FULL CONE方式:所有从同一个内部IP地址和端口的请求都被映射到同一个外部IP地址和端口上。而且,任何外部主机可以通过向被映射到的外部地址发送数据包(packet)的方式向此内部主机发送数据包。
Restricted Cone方式:所有从同一个内部IP地址和端口的请求都被映射到同一个外部IP地址和端口上。与FULL CONE方式不同的是,一个外部主机(IP地址为X)仅能向先前已经向IP地址X发送了数据包的内部地址发送数据包。
Port Restricted Cone方式:此方式类似Restricted Cone方式,但限制范围还包括了端口号。
即是,一个外部主机仅能向先前已经向IP地址X的端口P发送了数据包的内部主机发送指定源IP为X和源端口为P的数据包。
Symmetric方式:所有从同一个内部IP地址和端口到指定目标IP和端口的请求都被映射到同一个外部IP地址和端口上。同一个主机使用相同的源IP地址和端口但发送到不同目标的话,将使用不同的映射。而且,只有接收方外部主机才能发送UDP数据包到内部主机。
确定NAT的类型在很多情况下是十分重要的。需要根据应用程序所要达到的效果选择特定的方式。
结论2:只要两侧NAT都不属于Symmetric NAT,也可双向通信。换种说法,只要两侧NAT都属于Cone NAT,即可双向通信
结论3:一侧NAT属于Symmetric NAT,另一侧NAT属于Restricted Cone,也可双向通信。
结论4,两个都是Symmetric NAT或者一个是Symmetric NAT、另一个是Port Restricted Cone,则不能双向通信。
STUNU协议(Rfc3489、详见http://www.ietf.org/rfc/rfc3489.txt) 提出了4种NAT类型的定义及其分类,并给出了如何检测
在用的NAT究竟属于哪种分类的标准。但是,具体到P2P程序如何应用Stun协议及其分类法穿越NAT,则是仁者见仁、智者见智。
(因为STUN协议并没有给出也没有必要给出如何穿越NAT的标准)
在拙作“iptables与stun”一文中,笔者花大幅精力阐述了iptables理论上属于Symmetric NAT而非Port Restricted Cone。
对此,很多人(包括笔者最初学习Stun协议时)心中都有一个疑惑,即仅就Stun协议本身来说,Port Restricted Cone和
Symmetric NAT的区别似乎不大,虽然两者的映射机制是有点不同,但他们都具有端口受限的属性。初看起来,这两者在
穿越NAT方面的特性也差不多,尤其是对于外部地址欲往NAT内部地址发包的情况。既然如此,又为何有必要把iptables分得
这么清呢,本文顺带解决了读者在这一方面的疑惑。
网站http://midcom-p2p.sourceforge.net/给出了P2P程序具体如何穿越NAT的一个思路,并提供了一个P2P协议穿越NAT兼容性的
测试工具natcheck。让我们仍旧用实例(例1)来说明这一思路吧!
A机器在私网(192.168.0.4)
A侧NAT服务器(210.21.12.140)
B机器在另一个私网(192.168.0.5)
B侧NAT服务器(210.15.27.140)
C机器在公网(210.15.27.166)作为A和B之间的中介
A机器连接过C机器,假使是 A(192.168.0.4:5000)-> A侧NAT(转换后210.21.12.140:8000)-> C(210.15.27.166:2000)
B机器也连接过C机器,假使是 B(192.168.0.5:5000)-> B侧NAT(转换后210.15.27.140:8000)-> C(210.15.27.166:2000)
A机器连接过C机器后,A向C报告了自己的内部地址(192.168.0.4:5000),此时C不仅知道了A的外部地址
(C通过自己看到的210.21.12.140:8000)、也知道了A的内部地址。同理C也知道了B的外部地址(210.15.27.140:8000)和
内部地址(192.168.0.5:5000)。之后,C作为中介,把A的两个地址告诉了B,同时也把B的两个地址告诉了A。
假设A先知道了B的两个地址,则A从192.168.0.4:5000处同时向B的两个地址192.168.0.5:5000和210.15.27.140:8000发包
,由于A和B在两个不同的NAT后面,故从A(192.168.0.4:5000)到B(192.168.0.5:5000)的包肯定不通,现在看
A(192.168.0.4:5000)到B(210.15.27.140:8000)的包,分如下两种情况:
1、B侧NAT属于Full Cone NAT
则无论A侧NAT属于Cone NAT还是Symmetric NAT,包都能顺利到达B。如果P2P程序设计得好,使得B主动到A的包也能借用
A主动发起建立的通道的话,则即使A侧NAT属于Symmetric NAT,B发出的包也能顺利到达A。
结论1:只要单侧NAT属于Full Cone NAT,即可实现双向通信。
2、B侧NAT属于Restricted Cone或Port Restricted Cone
则包不能到达B。再细分两种情况
(1)、A侧NAT属于Restricted Cone或Port Restricted Cone
虽然先前那个初始包不曾到达B,但该发包过程已经在A侧NAT上留下了足够的记录:
A(192.168.0.4:5000)->(210.21.12.140:8000)->B(210.15.27.140:8000)。如果在这个记录没有超时之前,
B也重复和A一样的动作,即向A(210.21.12.140:8000)发包,虽然A侧NAT属于Restricted Cone或Port Restricted Cone,
但先前A侧NAT已经认为A已经向B(210.15.27.140:8000)发过包,故B向A(210.21.12.140:8000)发包能够顺利到达A。
同理,此后A到B的包,也能顺利到达。
结论2:只要两侧NAT都不属于Symmetric NAT,也可双向通信。换种说法,只要两侧NAT都属于Cone NAT,即可双向通信。
(2)、A侧NAT属于Symmetric NAT
因为A侧NAT属于Symmetric NAT,且最初A到C发包的过程在A侧NAT留下了如下记录:
A(192.168.0.4:5000)->(210.21.12.140:8000)-> C(210.15.27.166:2000),故A到B发包过程在A侧NAT上留下的记录为:
A(192.168.0.4:5000)->(210.21.12.140:8001)->B(210.15.27.140:8000)(注意,转换后端口产生了变化)。
而B向A的发包,只能根据C给他的关于A的信息,发往A(210.21.12.140:8000),因为A端口受限,故此路不通。
再来看B侧NAT,由于B也向A发过了包,且B侧NAT属于Restricted Cone或Port Restricted Cone,故在B侧NAT上留下的记录为:
B(192.168.0.5:5000)->(210.15.27.140:8000)->A(210.21.12.140:8000),此后,如果A还继续向B发包的话
(因为同一目标,故仍然使用前面的映射),如果B侧NAT属于Restricted Cone,则从A(210.21.12.140:8001)来的包能够顺利到达B;
如果B侧NAT属于Port Restricted Cone,则包永远无法到达B。
结论3:一侧NAT属于Symmetric NAT,另一侧NAT属于Restricted Cone,也可双向通信。
显然,还可得出另一个不幸的结论4,两个都是Symmetric NAT或者一个是Symmetric NAT、另一个是Port Restricted Cone,
则不能双向通信。
上面的例子虽然只是分析了最初发包是从A到B的情况,但是,鉴于两者的对称性,并且如果P2P程序设计得足够科学,
则前面得出的几条结论都是没有方向性,双向都适用的。
通过上述分析,我们得知,在穿越NAT方面,Symmetric NAT和Port Restricted Cone是有本质区别的,尽管他们表面上看起来相似。
我们上面得出了四条结论,而natcheck网站则把他归结为一条:只要两侧NAT都属于Cone NAT
(含Full Cone、Restricted Cone和Port Restricted Cone三者),即可双向通信。
而且natcheck网站还建议尽量使用Port Restricted Cone,以充分利用其端口受限的属性确保安全性。
It is assumed that the reader is familiar with NATs. It has been
observed that NAT treatment of UDP varies among implementations. The
four treatments observed in implementations are:
Full Cone: A full cone NAT is one where all requests from the
same internal IP address and port are mapped to the same external
IP address and port. Furthermore, any external host can send a
packet to the internal host, by sending a packet to the mapped
external address.
Restricted Cone: A restricted cone NAT is one where all requests
from the same internal IP address and port are mapped to the same
external IP address and port. Unlike a full cone NAT, an external
host (with IP address X) can send a packet to the internal host
only if the internal host had previously sent a packet to IP
address X.
Port Restricted Cone: A port restricted cone NAT is like a
restricted cone NAT, but the restriction includes port numbers.
Specifically, an external host can send a packet, with source IP
address X and source port P, to the internal host only if the
internal host had previously sent a packet to IP address X and
port P.
Symmetric: A symmetric NAT is one where all requests from the
same internal IP address and port, to a specific destination IP
address and port, are mapped to the same external IP address and
port. If the same host sends a packet with the same source
address and port, but to a different destination, a different
mapping is used. Furthermore, only the external host that
receives a packet can send a UDP packet back to the internal host.
Determining the type of NAT is important in many cases. Depending on
what the application wants to do, it may need to take the particular
behavior into account.
NAT的区别
本文假定读者对NAT很熟悉。目前已知各种NAT实现对UDP的处理是有差异的,共有四种不同的处理方式:
FULL CONE方式:所有从同一个内部IP地址和端口的请求都被映射到同一个外部IP地址和端口上。而且,任何外部主机可以通过向被映射到的外部地址发送数据包(packet)的方式向此内部主机发送数据包。
Restricted Cone方式:所有从同一个内部IP地址和端口的请求都被映射到同一个外部IP地址和端口上。与FULL CONE方式不同的是,一个外部主机(IP地址为X)仅能向先前已经向IP地址X发送了数据包的内部地址发送数据包。
Port Restricted Cone方式:此方式类似Restricted Cone方式,但限制范围还包括了端口号。
即是,一个外部主机仅能向先前已经向IP地址X的端口P发送了数据包的内部主机发送指定源IP为X和源端口为P的数据包。
Symmetric方式:所有从同一个内部IP地址和端口到指定目标IP和端口的请求都被映射到同一个外部IP地址和端口上。同一个主机使用相同的源IP地址和端口但发送到不同目标的话,将使用不同的映射。而且,只有接收方外部主机才能发送UDP数据包到内部主机。
确定NAT的类型在很多情况下是十分重要的。需要根据应用程序所要达到的效果选择特定的方式。
转自:http://www.cnblogs.com/ymy124/archive/2012/04/05/2433739.html