FTP 分为2种工作模式: 主动模式和被动模式。
----------服务器不经过NAT----------------
先说说主动模式:
主动模式服务器需要2个端口,控制端口和数据端口,默认情况是TCP 21和TCP 20 。客户端在连接服务器的时候,先通过连接TCP 21登录服务器验证,然后再再本地随机开一个端口,告诉服务器,服务器再连接客户端的这个TCP端口,进行传输数据。此时身份验证的发起方是客户端,而数据传输的发起方是服务器。
如果客户端服务器端都未经过NAT转换那么通过主动模式访问也没什么不方便的地方。8过实际上这种情况却很少,绝大部分客户端都是在NAT设备后面,导致客户端在本机
开启的用于传输FTP数据的端口就不能被服务器端访问。除非在客户端的NAT设备上做好相应的端口映射。但是如果内网用户多,在NAT上做映射和配置显然不现实。
这时候就得跑被动模式了:
被动模式:客户端通连接服务器端的控制端口验证身份,成功以后服务器会告诉客户端一个随机的数据传输端口,比如TCP1234,并告诉客户端,客户端再连接服务器的TCP1234来传输数据。
这样一来,可以解决所有客户端在NAT以后的问题,因为整个通信过程的发起方都在本地。
------------服务器经过NAT--------------------
现在我们再在服务器前面放一个路由器或者防火墙神马的,把公网地址挂在路由器或者防火墙上,服务器上只配个内网地址。
现在不管是对客户端还是服务器都是在NAT后面了。情况就稍有不同。
服务器跑主动模式:这个情况与前面把服务器直接挂在公网上情况一样。做好服务器端的路由器或防火墙的传输端口和控制端口的映射就行了。与上面同样理由,这个方法不切实际。
被动模式:现在服务器也经过NAT了,在NAT设备上配了21端口映射到服务器的21端口上,那么就意味着服务器在随机打开一个数据端口让客户端连接传输的时候,这个端口是客户端无法访问到的,因为NAT设备没办法自动配置端口映射。
为了解决类似问题,防火墙路由器厂商学精了,加入了会话状态检测机制,一旦发现跑的是相关会话如,由tcp21端口引发,立即动态允许服务器随机打开的端口可以被外部连接。
一般来说问题就解决了,可是实际上还会有点问题。就是一旦服务器端口用的不是标准的21端口,那防火墙和路由器就傻了。
比如我把服务器的21映射到外网的9090,在路由器上配置nat server protocol tcp global 218.2.135.1 9090 inside 10.1.1.10 ftp , 这时候路由器就只会开9089对应传输和9090对应控制。
微软的IIS FTP服务端口可是从1024-65535随机开启的,总不能写几万个NAT映射吧。。
为了偷偷懒,可以人为把这些端口的范围缩小一点,少写几条NAT规则。
好,到Inetpub的AdminScripts目录下面运行脚本
adsutil.vbs set /MSFTPSVC/PassivePortRange "9070-9079"
我们人为强制只允许服务器开9070-9079这几个端口作为被动端口,然后在NAT设备上做好这10个端口的NAT。。。现在OK了,FTP又可以被外网客户访问了。
这仅仅只限于少量几个FTP客户端的时候,人多了端口不够了就肯定不能访问。
对于大量用户访问的情况怎么办呢?不能限制随机端口数量,还得把端口切换到21以外的端口上。
要实现这个,就得看你的NAT设备了,把一堆端口都映射出去的方法固然可行,要是把几万个端口都像上面那样做映射也会引起点安全问题,会暴露出其他端口。
如果用的是H3C的设备,可以尝试一下port-mapping ftp port 9090 这个命令。 让协议识别从21端口改到9090端口。这是一个很好的解决方法。
但如果你的设备不支持那就木有办法了。。老老实实的一个一个加NAT吧。