UDP包穿过路由器。(50)

当一个外网的程序向一个中心发送一个UDP包的时候，中心的路由器把这个端口的包转发到一个服务器上去，譬如，5101端口转发到192.168.2.150上，现在我把路由器上的设置5101转发到192.168.2.161上去，在192.168.2.161上的程序却接收不到这个包，如果把外网的程序重新启动一下，就可以了，这个是为什么？楼上的大概没有理解我的意思，或者我表述的不清楚。主要问题是 ，我一个外网的机器，想一个内网的机器发送一个UDP包，开始的时候是正常（当然我在路由器上做了端口映射），但是过了 一段时间 10个小时，或者5个小时，外网的机器就发不过来了 ，但是我用抓包工具 发现 外网的客户端确实在一直发送数据，端口和Ip多是真确的 ，而且网络是通的，我重新启动程序就好了，我重新启动路由器也要了。

从新打洞,在网上搜一搜P2P,原理差不多,

我没有用P2P呀

我是说原理差不多,又没说你用P2P由于你的路由器在跟192.168.2.150 通信正常的情况下,突然转换成 跟192.168.2.161通信,那么路由器跟192.168.2.161的通信就没有连接,所以就需要192.168.2.161向路由器的方向打洞,让路由器跟192.168.2.161建立连接才行UDP穿越NAT的原理。首先先介绍一些基本概念： NAT(Network Address Translators)，网络地址转换：网络地址转换是在IP地址日益缺乏的情况下产生的，它的主要目的就是为了能够地址重用。NAT分为两大类，基本的NAT和NAPT(Network Address/Port Translator)。 最开始NAT是运行在路由器上的一个功能模块。 最先提出的是基本的NAT，它的产生基于如下事实：一个私有网络（域）中的节点中只有很少的节点需要与外网连接（呵呵，这是在上世纪90年代中期提出的）。那么这个子网中其实只有少数的节点需要全球唯一的IP地址，其他的节点的IP地址应该是可以重用的。 因此，基本的NAT实现的功能很简单，在子网内使用一个保留的IP子网段，这些IP对外是不可见的。子网内只有少数一些IP地址可以对应到真正全球唯一的IP地址。如果这些节点需要访问外部网络，那么基本NAT就负责将这个节点的子网内IP转化为一个全球唯一的IP然后发送出去。(基本的NAT会改变IP包中的原IP地址，但是不会改变IP包中的端口) 关于基本的NAT可以参看RFC 1631 另外一种NAT叫做NAPT，从名称上我们也可以看得出，NAPT不但会改变经过这个NAT设备的IP数据报的IP地址，还会改变IP数据报的TCP/UDP端口。基本NAT的设备可能我们见的不多（呵呵，我没有见到过），NAPT才是我们真正讨论的主角。看下图： Server S1 18.181.0.31:1235 | ^ Session 1 (A-S1) ^ | | 18.181.0.31:1235 | | v 155.99.25.11:62000 v | | NAT 155.99.25.11 | ^ Session 1 (A-S1) ^ | | 18.181.0.31:1235 | | v 10.0.0.1:1234 v | | Client A 10.0.0.1:1234 有一个私有网络10.*.*.*，Client A是其中的一台计算机，这个网络的网关（一个NAT设备）的外网IP是155.99.25.11(应该还有一个内网的IP地址，比如10.0.0.10)。如果Client A中的某个进程（这个进程创建了一个UDP Socket,这个Socket绑定1234端口）想访问外网主机18.181.0.31的1235端口，那么当数据包通过NAT时会发生什么事情呢？ 首先NAT会改变这个数据包的原IP地址，改为155.99.25.11。接着NAT会为这个传输创建一个Session（Session是一个抽象的概念，如果是TCP，也许Session是由一个SYN包开始，以一个FIN包结束。而UDP呢，以这个IP的这个端口的第一个UDP开始，结束呢，呵呵，也许是几分钟，也许是几小时，这要看具体的实现了）并且给这个Session分配一个端口，比如62000，然后改变这个数据包的源端口为62000。所以本来是（10.0.0.1:1234->18.181.0.31:1235）的数据包到了互联网上变为了（155.99.25.11:62000->18.181.0.31:1235）。 一旦NAT创建了一个Session后，NAT会记住62000端口对应的是10.0.0.1的1234端口，以后从18.181.0.31发送到62000端口的数据会被NAT自动的转发到10.0.0.1上。（注意：这里是说18.181.0.31发送到62000端口的数据会被转发，其他的IP发送到这个端口的数据将被NAT抛弃）这样Client A就与Server S1建立以了一个连接。 呵呵，上面的基础知识可能很多人都知道了，那么下面是关键的部分了。 看看下面的情况： Server S1 Server S2 18.181.0.31:1235 138.76.29.7:1235 | | | | +----------------------+----------------------+ | ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^ | 18.181.0.31:1235 | | | 138.76.29.7:1235 | v 155.99.25.11:62000 v | v 155.99.25.11:62000 v | Cone NAT 155.99.25.11 | ^ Session 1 (A-S1) ^ | ^ Session 2 (A-S2) ^ | 18.181.0.31:1235 | | | 138.76.29.7:1235 | v 10.0.0.1:1234 v | v 10.0.0.1:1234 v | Client A 10.0.0.1:1234 接上面的例子，如果Client A的原来那个Socket(绑定了1234端口的那个UDP Socket)又接着向另外一个Server S2发送了一个UDP包，那么这个UDP包在通过NAT时会怎么样呢？ 这时可能会有两种情况发生，一种是NAT再次创建一个Session，并且再次为这个Session分配一个端口号（比如：62001）。另外一种是NAT再次创建一个Session，但是不会新分配一个端口号，而是用原来分配的端口号62000。前一种NAT叫做Symmetric NAT，后一种叫做Cone NAT。我们期望我们的NAT是第二种，呵呵，如果你的NAT刚好是第一种，那么很可能会有很多P2P软件失灵。（可以庆幸的是，现在绝大多数的NAT属于后者，即Cone NAT） 好了，我们看到，通过NAT,子网内的计算机向外连结是很容易的（NAT相当于透明的，子网内的和外网的计算机不用知道NAT的情况）。 但是如果外部的计算机想访问子网内的计算机就比较困难了（而这正是P2P所需要的）。 那么我们如果想从外部发送一个数据报给内网的计算机有什么办法呢？首先，我们必须在内网的NAT上打上一个“洞”（也就是前面我们说的在NAT上建立一个Session），这个洞不能由外部来打，只能由内网内的主机来打。而且这个洞是有方向的，比如从内部某台主机（比如：192.168.0.10）向外部的某个IP(比如：219.237.60.1)发送一个UDP包，那么就在这个内网的NAT设备上打了一个方向为219.237.60.1的“洞”，（这就是称为UDP Hole Punching的技术）以后219.237.60.1就可以通过这个洞与内网的192.168.0.10联系了。（但是其他的IP不能利用这个洞）。呵呵，现在该轮到我们的正题P2P了。有了上面的理论，实现两个内网的主机通讯就差最后一步了：那就是鸡生蛋还是蛋生鸡的问题了，两边都无法主动发出连接请求，谁也不知道谁的公网地址，那我们如何来打这个洞呢？我们需要一个中间人来联系这两个内网主机。 现在我们来看看一个P2P软件的流程，以下图为例： Server S （219.237.60.1） | | +----------------------+----------------------+ | | NAT A (外网IP:202.187.45.3) NAT B (外网IP:187.34.1.56) | (内网IP:192.168.0.1) | (内网IP:192.168.0.1) | |Client A (192.168.0.20:4000) Client B (192.168.0.10:40000) 首先，Client A登录服务器，NAT A为这次的Session分配了一个端口60000，那么Server S收到的Client A的地址是202.187.45.3:60000，这就是Client A的外网地址了。同样，Client B登录Server S，NAT B给此次Session分配的端口是40000，那么Server S收到的B的地址是187.34.1.56:40000。 此时，Client A与Client B都可以与Server S通信了。如果Client A此时想直接发送信息给Client B，那么他可以从Server S那儿获得B的公网地址187.34.1.56:40000，是不是Client A向这个地址发送信息Client B就能收到了呢？答案是不行，因为如果这样发送信息，NAT B会将这个信息丢弃（因为这样的信息是不请自来的，为了安全，大多数NAT都会执行丢弃动作）。现在我们需要的是在NAT B上打一个方向为202.187.45.3（即Client A的外网地址）的洞，那么Client A发送到187.34.1.56:40000的信息,Client B就能收到了。这个打洞命令由谁来发呢，呵呵，当然是Server S。 总结一下这个过程：如果Client A想向Client B发送信息，那么Client A发送命令给Server S，请求Server S命令Client B向Client A方向打洞。呵呵，是不是很绕口，不过没关系，想一想就很清楚了，何况还有源代码呢（侯老师说过：在源代码面前没有秘密 8）），然后Client A就可以通过Client B的外网地址与Client B通信了。 注意：以上过程只适合于Cone NAT的情况，如果是Symmetric NAT，那么当Client B向Client A打洞的端口已经重新分配了，Client B将无法知道这个端口（如果Symmetric NAT的端口是顺序分配的，那么我们或许可以猜测这个端口号，可是由于可能导致失败的因素太多，我们不推荐这种猜测端口的方法）。

楼上的大概没有理解我的意思，或者我表述的不清楚。主要问题是 ，我一个外网的机器，想一个内网的机器发送一个UDP包，开始的时候是正常（当然我在路由器上做了端口映射），但是过了 一段时间 10个小时，或者5个小时，外网的机器就发不过来了 ，但是我用抓包工具 发现 外网的客户端确实在一直发送数据，端口和Ip多是真确的 ，而且网络是通的，我重新启动程序就好了，我重新启动路由器也要了。为什么?

我说的是重新启动外网客户端程序，而且抓包工具也是抓的是外网的客户端机器上的包，当然内网的服务器程序没有问题的。

lqcros 已经说的够清楚了。

UDP 的传透，我很早以前就实现过，但是这个跟穿透没有任何关系，边多挨不上！这个有两个可能，1。客户端的包没有到达路由器。这个是为什么？2。到达了路由器没有转到指定的服务起，这个是为什么？

2。到达了路由器没有转到指定的服务起，这个是为什么？因为你改IP了，这个跟穿透一样，有数据来的时候即使你改了规则，也不生效了，除非这个SESSION被释放了。

学习。感觉网络太高深了。

to :白河愁我没有做任何修改。我修改之前，我在内网的机器上已经收不到外网客户端发过来的包，所以我修改一下，验证一下是不是我的服务程序出了问题。我只是第一天晚上把客户端程序，和服务端程序开者，第二天早上过来看，发现 服务器端没有收到客户端数据，而且客户端程序一直在向路由器上发包。就算我在服务器上改了IP（端口重向改了），当路由器收到外网发到该端口上的包的时候，也会根据重定向找到，我该过后的iP地址，然后把这个包发到该IP上。但是我在我改过后的IP地址的机器上没有收到任何包。

不会把，除非外网程序对于内网的电信IP改变了(重新启动或拨号)，否者NAT应该不会改变的，要么就是Link硬件的问题！

to wql:现在就是这样的现象，而且我现在 Client,Server放在一个子网内，重新启动Client,server上的程序多没有用，但是我把目的地址改成局域网内的IP,Server可以收到包，但是我发到路由器上，然后端口转发到Server，Server 就收不到包。即使按照你说的，外网的机器IP变了，但是他的mac地址没有变，他还是会过的来，及时重新拨号的时候，自己的Arp缓存把目的的Mac地址清掉了，UDP在分装成IP包的时候，找不到目的Mac 他会发一个包去请求目的地址的 Mac 的，所以无论如何，他这个包都到达了路由器（硬件链路没有问题），即使，某一个包可能会多个路由器，有生存周期的问题，（他不是同时到达），在目的地址的路由器上去抛弃掉，但是客户端会重发这个包。他不可能每次多抛弃吧，而且更难以理解的是，我现在是局域网内。但是重新启动路由器就好了

既然是重启路由器就好了，那就换一个路由器测试。

而且，我把5300-5320，tcp/Ip多做了转发，单单只有我用的5301的Udp端口不能转发到目的机器上，其他的端口 tcp/udp 多可以转发，而且5301的tcp端口也能转发到目的机器上。