两个Port-Restricted Cone NAT类型的客户端之间，能建立udp穿透吗

Question

Port-Restricted Cone NAT的本意就是限定ip和port吧，既然这样理应没法用udp穿透啊，我测试的结果也是穿不过，但网上很多资料说，
Full Cone NAT，Restricted Cone NAT，Port-Restricted Cone NAT，这三种类型是可以穿透的，到底能不能穿透呢？

Answer 1

可以穿透,以前CSDN上有一篇文章,写的很全,楼主可以搜一下,大概意思是借助一个中转服务器,往两个内网的ROUTER发包,让rounter建立起内网到外网的映射条目,之后再让内网的A朝B的外网IP发包(外网IP通过转发服务器获得),绝大部分的路由器(R)都可以穿透.

Answer 2

我用了VB 的winsock 控件用 UDP协议做了一个server和client，不成功啊。我先说说我的环境:
s在有公网固定IP，c1和c2分别为两地ADSL拨号后面的路由器后的电脑，
c1和c2不停（每5秒）向S发送心跳包，s记录它们的NAT后的外网IP和端口，并交换告知c2和c1,
现在C1欲发消息给C2，
C1向s发送请求打洞消息，s告诉c2要打洞，c2发送一个打洞包给c1 NAT后的外网IP和端口，c2告诉S已打洞，s告诉c1已打洞，C1发送消息给c2，过程就是这样，如果超时就重发，重发次数设为的5，可是就是不成功，消息发不出去。如果C1和c2都在路由后，则打洞不成功，我又测试了一下，如果其中一方做了DMZ（就是有了公网IP），打洞就会成功。不管C1还是C2做了DMZ都会成功，这排除了路由器不支持锥形NAT的可能。比如C1有公网ip，c1要发消息给C2，c1通过S请求c2向c1打洞后，c1的消息能正常发给c2，反过来也行。于是，我又写了个小工具，跟踪调试它们的IP和端口信息，发现个有趣但又无赖的现象：
假如：
s的IP为 8.8.8.8 ，UDP localport 为 8888
c1的ip和端口为：192.168.1.11:1111
c2的ip和端口为：192.168.2.22:2222c1和C2分别向S端口8888发送心跳包，S得到的：
c1的外网IP为 1.1.1.1 ，UDP localport 为 1111
c2的外网IP为 2.2.2.2 ，UDP localport 为 2222现在C1欲发消息给c2，c1通过S告诉c2向c1打洞，那么c2还用这个winsock不改变LOCALPORT发送打洞包给1.1.1.1:1111，即：2.2.2.2:2222（192.168.2.22:2222） --> 1.1.1.1:1111，此时，这个打洞包会被c1的路由器丢弃，根据地球人公布的打洞原理，此时打洞已成功，C1可以向C2发送消息了，但是：
关键时刻来了：
此时如果c1向C2发送消息时（即：192.168.1.11:1111 --> 2.2.2.2:2222 ），路由器会重新给C1分配端口,即是：1.1.1.1:2342(假设端口号会变成2342，不再是1111) -->2.2.2.2:2222 ，所以导致打洞失败。但是过一会（超时后，大概3分钟），c1再向C2发送消息时（即：192.168.1.11:1111 --> 2.2.2.2:2222 ），又会变成：1.1.1.1:1111 --> 2.2.2.2:2222你可能会说我的路由器是对称型NAT，但是，我想说的是：如果c2不先向C1发送那个打洞包，而先c1向c2发送消息，即：192.168.1.11:1111 --> 2.2.2.2:2222，那么路由器的映射又是正确的1.1.1.1:1111 --> 2.2.2.2:2222 ，心跳包也是1.1.1.1:1111 --> 8.8.8.8:8888，即符合锥形NAT现象，看起来就好像是那个打洞包干扰了路由器的映射，所以此时这个c1发向c2的消息又变相成了c1到c2的打洞包，那c2向C1发消息，外网端口又会被路由器重新映射。
测试了4个路由器，飞鱼星，思科，日立，D-LINK，均是如此