3.4.3 无法打洞的NAT组网
由于应用了打洞的技术,多层NAT的问题迎刃而解。但是,细心的读者可能已经发现,如果两边NAT设备都是对称模式,显然是无法打洞的——因为客户端或NVR访问服务器时与访问对方的公网映射地址时,己方外层NAT映射的公网地址/端口对是不一样的,打洞流程也就无法进行下去。
那么,究竟什么样的NAT不能通过打洞来穿越呢?有两种情况:一种是当互访的两个节点分别位于两个对称型NAT后;另一种是其中一个节点位于对称型NAT后、另一个节点位于端口限制锥型NAT后。
用穷举法可以证明:经过多个NAT设备的总体效果与其中一个最严格NAT设备的模式相当。比如,两个NAT设备,一个是完全锥型NAT,另一个是端口限制锥型NAT,那么,总体效果就是端口限制锥型NAT。
下面我们举例看看为何这两种组网中的节点是无法通过打洞直接连接上的。例子中假设两边的外层NAT比内层NAT严格,所以我们只关心外层NAT的映射表项即可。
图3-35 两边都是对称型NAT时的打洞情况
第一种情况,假定NVR和客户端的最外层NAT设备NATA2和NATB2是对称型NAT,如上图。客户端发往NATA2报文的目的IP地址和端口(211.109.11.11:2345)与之前发往中间服务器的报文目的IP地址和端口(123.10.11.33:1701)不同,根据之前对对称型NAT的介绍,此时在NATB2上映射的端口(5433)与之前发往服务器的报文映射端口(5432)也就不同。而NATA2在端口2345收到报文时,发现客户端发送过来的报文源IP地址和端口(212.102.12.22:5433)与之前NVR发往中间服务器的报文经NATA2端口2345转发出去的目的IP地址和端口(123.10.11.33:1701)不同,也就是说NATA2的端口2345之前没有向NATB2(212.102.12.22:5433)发送过报文,不能使用之前与中间服务器连接时生成的Session向内网转发报文,将报文丢弃。
此后,NVR发往NATB2的目的IP地址和端口(212.102.12.22:5432)与之前NATB2发往中间服务器的报文的目的IP地址和端口(123.10.11.33:1701)不同,此时在NATA2上映射的端口(2346)与之前发往服务器的报文映射端口(2345)也不同。而NATB2在端口5432上收到NVR发送过来的报文的源IP地址和端口为211.109.11.11:2346,但是NATB2端口5432之前未向NATA2(211.109.11.11:2346)发送过报文,NATB2将报文丢弃。
这样NVR和客户端都无法获取到对方在最外层NAT设备上新映射的端口,而只能向原来中间服务器获取到的老映射端口发送报文,而NAT设备收到对端报文的源端口发生变化,都不是对端NAT设备所期待的老的源端口,将被对端的对称型NAT设备丢弃,两者无法建立起直接的连接。
图3-36 一边是对称型NAT一边是端口限制型NAT时的打洞情况
第二种情况,假定NVR和客户端的最外层NAT设备NATA2和NATB2是分别是端口限制锥形和对称型NAT,如上图。客户端发往NATA2报文的目的IP地址和端口(211.109.11.11:2345)与之前发往中间服务器的报文目的IP地址和端口(123.10.11.33:1701)不同,根据之前对对称型NAT的介绍,此时在NATB2上映射的端口(5433)与之前发往服务器的报文映射端口(5432)不同。而NATA2发现客户端发送过来的报文源IP地址和端口(212.102.12.22:5433)与之前NVR发往中间服务器的目的IP地址和端口(123.10.11.33:1701)不同,也就是说NATA2之前没有向212.102.12.22:5433发送过报文,不能使用之前与中间服务器连接时生成的Session向内网转发报文,将报文丢弃。
此后,NVR发往NATB2的目的IP地址和端口(212.102.12.22:5432)与之前发往中间服务器的IP地址和端口(123.10.11.33:1701)不同,但由于NATA2为端口限制锥型NAT,映射的端口与之前发往中间服务器的相同,都为2345。然而,NATB2只接收源地址为 211.109.11.11:2345,目的地址为212.102.12.22:5433的报文,所以NATB2同样会丢弃来自NVR发送过来的报文。
这样NVR无法获取到客户端在NATB2新映射的端口(5433),而向原来中间服务器获取到的老的映射端口(5432)发送的报文将被对称型NAT设备NATB2丢弃,而客户端发往NATA2的报文的源端口(5433)由于不是NATA2所期待的端口(5432),也将被丢弃,这样两者无法建立连接。
除此之外,其他的NAT模式都适合P2P打洞访问,读者可以自己举例走下流程。
一般情况下,客户端与NVR互访的总体原则是:优选私网互访(如果凑巧在同一私网的话),次选P2P公网地址互访,后选公网服务器转发(如果P2P互访不成功的话)。但是,如果同一路视频有多个客户端点播,这时候就得考虑其他的处理机制了,我们在下一章节详细讨论这个问题。
有段时间亲戚来杭州玩,老U向他们展示了茶室的监控系统。亲戚们很感兴趣,都用手机客户端点播观看。当大家热情的赞叹于这玩意儿的神奇和图像清晰时,老U却发现了一个有趣的现象:4个人点播同一路256Kbps的视频流时,图像却一点都不卡顿;可是自己家里的ADSL上行带宽没这个大,4路视频一共达到1Mbps的码率,远超线路的负荷了。这是怎么回事呢? |