感受VMware NAT对应用层协议的影响（配置guest机FTP server蛋疼实录）

不要问我为什么要在VMware下的guest机配置一个FTP server，但是我确实需要这样做。显然需要端口转发嘛，在virtual network settings里设置下21到21的转发。Done。

这时候问题来了，FTP的passive mode的端口怎么办？多扯几句关于passive/active的区别，这个p和a啊，指的是服务器的行为。在客户端连接到服务器21端口，建立命令连接后，传数据都是靠另外一条tcp连接的，但这一条TCP连接的建立，就比较复杂了。所谓passive，就是服务器（被动地）开放一个高端口监听，等待客户端连接；而active，则是客户端打开一个端口，请求服务器（主动）来连。显然后者听起来比较奇葩，哪有服务器发起连接的？要是客户端是NAT或者有防火墙怎么办？所以一般最好使用passive mode，对客户端环境不高。但反过来，passive mode对服务器网络环境要求就高了，不仅要允许21端口的入站连接，还要允许某一群高端口的入站连接。

于是呢，我就要配置VMware的入站连接的转发了。（这个过程会导致悲剧的结果，如果不想研究，请直接跳到结论）

（在DEBUG前，请关闭防火墙，以防干扰结果）

在guest机中，启动FTP server，设置监听端口21，passive mode的端口范围50000-50100

自然顺理成章地，在vmware NAT中转发50000-50100.但尼玛悲剧的是，它的转发只能一个端口一个端口设置（太不科学了）！忍着爆发的情绪，输了21个端口，即50000-50020，先这么着吧。同时设置passive mode时要求客户端连接的ip（显然是NAT的外网ip啦，要是内网IP人家还怎么连）。

然后我就用外网电脑一客户端连接之，命令连接显然没有问题，但在entered passive mode之后，服务器声称打开了【外网IP：50000】端口，但客户端收到的却是【外网IP：50541】端口，显然后者端口是个随机的，NAT没转发，怎么可能被FTP server收到！但试n遍都是同样的状态，就想到是不是NAT的问题？

于是在文章《VMware Workstation建立FTP服务器并使用PASV模式》中提到的常见问题中，有类似的情况，他提供的解决办法是不要使用默认的21到21的映射，你可以搞一个外网21到内网20021的映射呀，于是我就这样做了。嘿，果然端口号不被篡改了，直来直去爽歪歪！

但是处女座的我对现状依然不满（疑问）：

 

中国的ip地址资源太少，很多情况下ftp会话两端要经过层层NAT、网关、防火墙。 导致PORT PASV中的ip 信息不一定都是正确的。比如client的ip是192.168.0.107，其实它是通过NAT连接上网的，该NAT对外的internet地址是218.2.135.1，那么client 发送的PORT指令中携带的192,168,0,107,xx,yy 对于server是没有意义的。 所幸现在的NAT、防火墙一般都有FTP应用层感知能力，它能够截获ftp会话中的PORT PASSIVE， 自动将private的ip翻译成对外的正确的ip，并实时的在NAT上开放临时端口转发 。刚才的例子就会翻译成 218,2,135,1,xx,yy。 所以一般情况下，ftp还是能够正常工作的。

 

卧槽？NAT原来这么智能啊，你不主动发起连接，他都能帮你开转发啊。。。

想想之前遇到的端口被篡改事件，以及把映射端口变成20021就不影响的现象，应该和NAT有巨大关系。

结论

VMware的NAT是极其智能的，它可以感知应用层数据，帮你在傻瓜状态下实现passive mode。

触发条件：

NAT转发规则：21到21，表示你这个就是FTP服务。（只要任何一端端口换了，它就不管了，因此疑问1得以解释）

工作原理：

检测FTP应用层数据，当发出192,168,0,107,xx,yy时，它自动改成218,2,135,1, zz,ww，并建立外网zzww到内网xxyy的端口转发。

解决方法（正确的配置）：