概述

NAT ALG的主要工作就是帮助某些协议在NAT之后还可以正常的工作。比如说FTP协议，我们知道每次FTP要进行数据的传输的时候，都会进行模式的选择，可能是主动模式，也可能是被动模式，如果是主动模式的话客户端就会通过控制通道发送port命令，然后在port命令中携带自己开放的TCP端口，随后服务器端向客户端开放的TCP端口进行数据通道的建立。如果是被动模式，那么首先客户端会向服务器端发送pasv命令，然后服务器端就会从控制通道回送报文，里面携带着服务器端开放的用于数据传输的端口，随后由客户端主动地向服务器开放地TCP端口进行数据通道的建立。那么当FTP遇上NAT之后会出现什么样的问题呢？

ensp上的误区

我们在ensp上进行配置的时候，比如创建了一个如下图的拓扑：

我们在server上创建了FTP的服务，然后在router上进行源NAT地址转换，然后使用client进行FTP服务的使用，在这个过程中即便我们使用主动模式依然可以正常的完成FTP双通道的建立。那么这是为什么？在现网中client一般配置的是私网地址，而这类地址在现实中一般是不会被响应的，但是在模拟器中是会被正常响应的，那么当客户端向服务器发送port命令的时候，虽然port命令中携带的是没有经过改变的客户端的私网地址，但是服务器依然还是会对其进行响应，于是服务器端就会直接向client的私网地址申请进行FTP数据通道的建立，而不是去和源NAT地址转换后的地址进行FTP数据通道的建立。所以整个流程可以归纳为如下所示：

1、服务器端与进行了源NAT的地址进行控制通道的建立

2、客户端向服务器端发送port命令里面携带的是client的私网地址以及client开放的用于FTP数据通道建立的端口，且该报文被路由器进行了源地址的转换。

3、服务器根据port命令中记录的IP地址以及端口，向其发起TCP数据通道连接（注意此时服务器端申请进行FTP数据通道建立的目的IP以及端口都是未经过源NAT操作的client原生IP与端口）

如下图所示：

?这是我之前学习的时候忽略掉的地方，现在分享出来。

NAT ALG

那么上面的例子虽然可以在模拟器中进行正常的FTP服务，但是其实已经完全背离了我们的设想。因为服务器端口已经直接与内网的主机进行FTP的数据通道连接，而这种操作在现网中是完全不行的，因为服务器根本不会去和目的地址为私网地址的主机进行FTP数据通道的建立。所以这时需要NAT ALG的帮助，NAT ALG的主要作用就是在FTP这类协议在交换一些有关与地址相关的信息的时候与NAT进行同步，在进行NAT操作的同时也将报文中的与地址相关的信息进行修改，保证报文中交换的地址信息与进行NAT操作之后的地址是对的上号的。比如FTP，它的PORT命令中会携带自己的IP以及开放的TCP端口信息，那么在进行NAT之后，报文中的信息会被NAT ALG进行修改，比如报文中记录的地址是192.168.0.1 开放的端口是10999，那么在经过NAT之后我的地址以及端口变为了1.1.1.1 22222，那么NAT ALG也会将报文中记录的地址修改为1.1.1.1 22222，这样就保证服务器后面在建立数据通道的连接的时候是和NAT之后的地址进行数据通道的建立，而不是私网的IP地址。一般来说开启了对应协议的ASPF之后，就会开启相对应的NAT ALG，而且如果NAT ALG不支持对应的协议之后，其实从本质上来说就不支持NAT了。

STUN需要NAT ALG帮助吗

那么话说回来，STUN需要NAT ALG帮助吗？其实STUN的原理针对的协议也很有限，针对的是哪些客户端从始至终只使用最开始端口的协议，像tftp，客户端虽然有控制通道，与数据通道，但是客户端都是使用相同的初始端口与服务器端的不同端口建立控制通道以及数据通道，而针对QQ，在外网用户像内网用户发起QQ语音的时候，其目标也是客户端使用的初始的UDP端口，那么其实从STUN的工作原理来说，外网主机如果要创建其他的流，针对的依然还是客户端最初始的端口，当STUN与NAT结合之后会产生如下的server-map表：

?从图中可以看到，即便外网主机还要创建针对私网主机IP地址以及初始端口的额外的流，都是可以被server-map匹配到的，其实根本不用NAT ALG烦心去修改报文中的地址。其本质原因是因为创建的流的形式不同，如下图所示：

?正是因为双通道协议在后续的流的建立的时候，需要一对新端口来建立，而新端口的信息又需要在报文中传递，而传统的NAT技术根本无法去修改报文中的信息，这才导致出现了问题，这也是需要NAT ALG帮助的本质原因。而反观STUN，它从始至终进行流建立的时候都是使用同一个端口，那么只要发布一个上图中server-map表，那么就可以完美解决外部主机想要建立多条流的问题。

?