NAT对FTP的影响
NAT环境下FTP存在的问题
FTP主动模式
FTP服务器在外部网络
在FTP主动模式下，如果网络中存在NAT，且FTP客户端在NAT内部网络中，那么FTP数据连接会出现下面的问题，如图：
内部网络中的FTP客户端和外部网络中的FTP服务器端通过NAT地址转换是可以正常建立控制连接的，控制连接中对于FTP服务器看到的客户端地址和端口是经过NAT转换之后的地址和端口，转换表项如下：
Inside global:port Inside local:port Outside local:port Outside global:port
1.1.1.1:10000 192.168.10.1:58887 1.1.1.2:21 1.1.1.2:21
之后客户端向服务器发送PORT命令，PORT命令中携带的是客户端的私网地址和端口192.168.10.1:58888，服务器端收到后会向该地址和端口发起数据连接，但是无法建立数据连接，原因如下：
- 192.168.10.1是私网地址，1.1.1.2到192.168.10.1是不通的，无法直接向私网地址发起连接，但是在某些场景下客户端是向1.1.1.1发起数据连接的，因为第二个原因，连接也是无法建立成功的；
- 即使服务器端是向1.1.1.1的50000端口发起数据连接，但是1.1.1.1的端口50000并没有和192.168.10.1的端口50000建立nat映射，数据包也无法到达192.168.10.1，数据连接中断。
实际实验中抓包分析如下：
-
客户端
-
服务器端，对比发现载荷中的PORT字段没有被NAT转换，数据连接失败。
FTP服务器在内部网络
对于FTP客户端在外部网络，FTP服务器端在内部网络的场景，是可以正常通过NAT的，如下图：
服务器端一般需要做地址或端口映射，映射到路由器外网端口，路由器会正常生成控制连接和数据连接的转换表项：
抓包如下，这里数据端口服务器使用的不是端口20，而是随机端口：
服务器端：
客户端：
路由器主要配置：
ip access-list extended 1001
10 permit ip 192.168.10.0 0.0.0.255 1.1.1.0 0.0.0.255
exit
interface gigabitethernet0
ip address 192.168.10.254 255.255.255.0
ip nat inside
exit
interface gigabitethernet1
ip address 1.1.1.1 255.255.255.0
ip nat outside
exit
# 关闭FTP ALG
no ip nat support ftp
ip nat inside source static tcp 192.168.10.1 21 1.1.1.1 21
ip nat inside source list 1001 interface gigabitethernet1 overload
FTP被动模式
客户端在外部网络
在FTP被动模式下，如果网络中存在NAT，且FTP客户端在NAT外部网络中，那么FTP数据连接会出现下面的问题，如图：
外部网络中的FTP客户端和内部网络中的FTP服务器端通过NAT地址转换是可以正常建立控制连接的，控制连接中对于FTP客户端看到的服务器端地址和端口是经过地址映射或端口映射之后的地址和端口，转换表项如下：
Inside global:port Inside local:port Outside local:port Outside global:port
1.1.1.1:21 192.168.10.1:21 - -
之后客户端向服务器发送PASV命令，PASV命令中携带的是服务器端的私网地址和端口192.168.10.1:50000，客户端收到后会向该地址和端口发起数据连接，但是无法建立数据连接，原因如下：
- 192.168.10.1是私网地址，1.1.1.2到192.168.10.1是不通的，无法直接向私网地址发起连接，但是在某些场景下客户端是向1.1.1.1发起数据连接的，因为第二个原因，连接也是无法建立成功的；
- 即使客户端是向1.1.1.1的50000端口发起数据连接，但是1.1.1.1的端口50000并没有和192.168.10.1的端口50000建立nat映射，数据包也无法到达192.168.10.1，数据连接中断。
实际实验中抓包如下：
-
服务器端：
) -
客户端，对比发现载荷中的PASV字段没有被NAT转换，数据连接建立失败：
)
客户端在内部网络
对于FTP客户端在内部网络，FTP服务器端在外部网络的场景，是可以正常通过NAT的，如下图：
实际实验中抓包如下：
-
服务器端：
-
客户端，PASV字段没有被NAT转换，因为是内部向外部发起数据连接，数据连接可以正常建立，无需NAT ALG的支持：
-
NAT转换表项：
NAT ALG在FTP中的应用
上面FTP协议穿越NAT遇到的问题就需要通过NAT ALG（应用层网关）功能来解决。
普通的NAT只能转换TCP或UDP数据包中的IP地址和端口号，但是对应用层报文中的IP地址和端口号是无法进行转换的，这就造成了FTP穿越普通NAT数据连接不通的问题。
而NAT ALG技术就可以有效的识别FTP等多通道协议中应用层载荷中IP地址和端口，将载荷中需要进行IP地址和端口转换或者需要特殊处理的字段进行相应的转换和处理，形成NAT转换表项，这样后续数据层面的报文就可以匹配到这个NAT转换表项，执行正常的转换和转发流程。
下面针对FTP的主动模式和被动模式下NAT ALG工作流程进行说明。
FTP主动模式
下面的图是FTP主动模式下NAT ALG和ASPF的工作过程，其中FTP客户端在内部网络中，FTP服务器端在外部网络中。
- 首先FTP客户端向FTP服务器端发起控制连接的三次握手，此处客户端地址会经过源NAT转换后到达服务器；
- 客户端向服务器发送PORT命令，告知服务器自己在数据连接中使用的地址和端口，原始报文应用层载荷中携带的地址和端口是192.168.10.1:61257，这是ASPF会识别到这个信息，生成Server-map表项，表项中记录的客户端的ip和端口就是192.168.10.1:61257，之后由NAT ALG进行处理，将载荷中的地址和端口进行转换，转换后的为1.1.1.1:50199，发送给服务器端，同时防火墙上会生成NAT转换表项，建立192.168.10.1:61257和1.1.1.1:50199的映射关系；
- 服务器收到PORT命令后，根据载荷中的数据，对客户端发起数据连接，这里就会对1.1.1.1:50199发起连接，这里的1.1.1.1是一个公网地址，是可达的，数据自然就会到达防火墙；
- 到达防火墙后会进行目的NAT转换，根据之前NAT ALG生成的NAT表项，将报文中的目的地址和端口转换成192.168.10.1:61257，接着匹配Server-map表现，也可以正常匹配上，无需再检查防火墙策略，该报文就会正常通过防火墙到达客户端，之后就可以正常建立数据连接的三次握手，进行数据传输。
下面使用实验验证上面的理论：
-
路由器基础配置：
ip access-list extended 1001 10 permit ip 192.168.10.0 0.0.0.255 1.1.1.0 0.0.0.255 exit interface gigabitethernet0 ip address 192.168.10.254 255.255.255.0 ip nat inside exit interface gigabitethernet1 ip address 1.1.1.1 255.255.255.0 ip nat outside exit # 开启NAT ALG ip nat support ftp ip nat inside source list 1001 interface gigabitethernet1 overload -
客户端抓包分析
-
服务器端抓包，对比客户端和服务器的PORT字段，可以看出来TCP载荷中的PORT字段被进行了NAT转换；
-
在路由器上查看信息：
NAT转换信息，标红的就是NAT ALG生成的转换表项；
查看NAT ALG的相关参数：
FTP被动模式
下面的图是FTP被动模式下NAT ALG和ASPF的工作过程，其中FTP服务器端在内部网络中，FTP客户端在外部网络中。
- 因为这里FTP客户端在防火墙内部，使用的是私网地址，因此需要把服务器在防火墙上进行端口映射，将192.168.10.1的21端口映射到1.1.1.1的21端口；这样FTP客户端就可以向FTP服务器端（1.1.1.1:21）发起控制连接的三次握手，此处会进行目的地址转换后到达服务器；
- 服务器端向客户端发送PASV命令，告知客户端自己在数据连接中使用的地址和端口，原始报文应用层载荷中携带的地址和端口是192.168.10.1:58888，这是ASPF会识别到这个信息，生成Server-map表项，表项中记录的服务器端的ip和端口就是192.168.10.1:58888，之后由NAT ALG进行处理，将载荷中的地址和端口进行转换，转换后的为1.1.1.1:40000，发送给客户端，同时防火墙上会生成NAT转换表项，建立192.168.10.1:58888和1.1.1.1:40000的映射关系；
- 客户端收到PASV命令后，根据载荷中的数据，对服务器端发起数据连接，这里就会对1.1.1.1:40000发起连接，这里的1.1.1.1是一个公网地址，是可达的，数据自然就会到达防火墙；
- 到达防火墙后会进行目的NAT转换，根据之前NAT ALG生成的NAT表项，将报文中的目的地址和端口转换成192.168.10.1:58888，接着匹配Server-map表现，也可以正常匹配上，无需再检查防火墙策略，该报文就会正常通过防火墙到达服务器端，之后就可以正常建立数据连接的三次握手，进行数据传输。
