我想从本地networking连接到FTP服务器，这是在NAT后面。
网关是Win 2008服务器，configuration了路由和远程服务/ Nat启用。 从XP，Vista sp1和Vista sp2计算机存在问题。
这是我得到的（使用默认的DOS ftp客户端，但是使用FileZilla获得同样的结果）
ftp> open ftp.foo.com Connected to ftp.foo.com. 220- [here I wait for 30s before getting the following line] Connection closed by remote host. ftp> 正如你所看到的，我在login过程之前断开连接，所以我没有机会使用PASSV。
这是什么工作：
提供ftp的公司说问题不在他们的最后，因为我可以从我的NAT服务器连接。 同样的理由导致问题不在我身边（我可以在其他FTP服务器上连接）
我应该检查什么？
编辑：这是当我嗅探网关上的连接，同时尝试从我的后面的nat计算机连接时得到的：
在面向互联网的界面上：
No. Time Source Destination Protocol Info 1312 320.576218 213.186.xx.xxx 192.168.1.1 FTP Response: 220- 1313 320.576602 213.186.xx.xxx 192.168.1.1 FTP Response: 220-Bienvenue, 1315 320.610911 213.186.xx.xxx 192.168.1.1 FTP Response: 220-
并在我的内部LAN接口上：
No. Time Source Destination Protocol Info 9288 118.698920 213.186.xx.xx 192.168.0.100 FTP Response: 220- 9293 118.890406 213.186.xx.xx 192.168.0.100 FTP Response: 220-Bienvenue, Frame 9293 (166 bytes on wire, 166 bytes captured) Ethernet II, Src: Tp-LinkT_c6:e2:3f (00:21:27:c6:e2:3f), Dst: Giga-Byt_22:b0:99 (00:1f:d0:22:b0:99) Internet Protocol, Src: 213.186.xx.xx(213.186.xx.xx), Dst: 192.168.0.100 (192.168.0.100) Transmission Control Protocol, Src Port: ftp (21), Dst Port: jini-discovery (4160), Seq: 7, Ack: 1, Len: 112 Source port: ftp (21) Destination port: jini-discovery (4160) Sequence number: 7 (relative sequence number) [Next sequence number: 119 (relative sequence number)] Acknowledgement number: 1 (relative ack number) Header length: 20 bytes Flags: 0x18 (PSH, ACK) Window size: 65536 (scaled) Checksum: 0xa5bc [incorrect, should be 0x96cb (maybe caused by "TCP checksum offload"?)] [SEQ/ACK analysis] File Transfer Protocol (FTP) 9306 119.187327 213.186.xx.xx 192.168.0.100 FTP [TCP Retransmission] Response: 220-Bienvenue, 9326 119.787350 213.186.xx.xx 192.168.0.100 FTP [TCP Retransmission] Response: 220-Bienvenue, No. Time Source Destination Protocol Info 9373 120.987450 213.186.xx.xx 192.168.0.100 FTP [TCP Retransmission] Response: 220-Bienvenue,
任何想法为什么这个CRC问题可能会发生？
顺便说一句，这是我的MTU设置（在网关上），他们在我的电脑上是相同的。
C:\Windows\system32>netsh interface ipv4 show interfaces Idx Met MTU State Name --- --- ----- ----------- ------------------- 1 50 4294967295 connected Loopback Pseudo-Interface 1 10 30 1500 connected Local Area Connection 13 20 1500 connected Local Area Connection 2
以下是我电脑上的一些MTU分析：
Pinging 192.168.0.1 with 1472 bytes of data: Reply from 192.168.0.1: bytes=1472 time<1ms TTL=128 Pinging 192.168.0.1 with 1473 bytes of data: Packet needs to be fragmented but DF set.
如果我尝试使用telnet进行连接，这就是我所得到的结果：
220- Connection to host lost. Press any key to continue...
通过的一点点文本表明这可能是某种MTU问题。 向前迈进的最佳方式是在网关上安装Wireshark，并捕获FTP连接中涉及的所有stream量。 如果你看到一个大包被多次发送，那就是MTU。 否则，把痕迹粘贴到某个地方，如果不清楚的话，有人可以为你解释。
作为一个方面说明，CRC问题通常是由在硬件上直接在NIC上进行校验和而引起的。 那么操作系统堆栈就不会再正确地看到校验和了。
尝试打开网卡属性，并禁用任何types的卸载，它应该删除这些消息。
更新：
在进一步分析你的日志的时候，看起来没有收到的数据包只有166字节长（这是在LAN接口上重复传输的“ Bienvenue ”），所以我不认为这是一个MTU问题在这里。 它似乎不是auth/ident因为服务器发送所有数据包。 它虽然是第一个有CRC错误的地方。
尝试禁用内部网卡上的所有硬件加速（卸载），并最终在外部网卡上停用，如果没有帮助的话。 有一个固定的速度和双工，也是相当不错的，当解决一次启用一个潜在的原因（10 /半双工是一个很好的开始）。 如果能够运作的话，一个接一个地重新启用，以便能够确定问题所在。
如果什么都行不通，可能是FTP-NATing软件有问题：FTP是一个协议，必须通过NAT（通常不在这里）来改变。 尝试使用FTP代理（第7层）软件。 如果这样做，你会有一个解决办法，因为它似乎只有FTP。
NAT网关中的FTP应用程序代理似乎在“220-”多行响应代码中出现。
FTP响应代码通常都是单行的，但数字后面的“ – ”表示有更多的输出行。
我以前见过这种情况 – 从我的情况来看，这是一个PIX防火墙。
我似乎还记得，有些FTP服务器可以通过在“ - ”， EDIT前添加login密码来避免发送多行响应，但在这种情况下，这不是修复，因为220-响应是在用户之前发送的尝试login。
如果您对FTP服务器的pipe理员友好，请让他们暂时禁用他们的服务器的login横幅，并查看您的login是否继续。
我想，我在IPtables的办公室里也遇到了同样令人讨厌的问题，除非我们知道它发生了，不想修复它。
这可能有助于检查您阻止传入stream量的端口。 我很确定FTP只使用21来传入连接（即你可以连接到某些东西，但是你不能指向它）。
我很确定你得到的端口是可以协商的，因此，如果可以的话，在这种情况下，废弃FTP并使用SFTP可能是一个好主意。
您可以尝试在Windows命令行ftp中使用debug命令。 也许它会告诉你一些额外的信息，导致解决scheme。
病人：医生，医生！ 当我喝了一杯茶时，我的眼睛里充满了刺痛。
医生：尝试把勺子从杯子里拿出来！
关键是：你为什么要使用你的服务器作为NAT网关？ 你的调制解调器/路由器不这样做吗？ 为什么不把服务器从path中取出？
我们的FTP服务器（proftpd）的工作方式是监听端口21上的连接，然后*一旦连接，就将连接打到 60000范围**（在proftpd.conf中设置为PassivePorts ）
我们的NAT最初设置为只将端口21转发到FTP服务器，我们看到了类似的行为，你所看到的。
通过将PassivePorts限制在特定的范围内 ，并在NATconfiguration中转发该范围 ，解决了我们的问题。
当然，那是从服务器端来看的
可以通过临时对所有端口进行NAT转换，然后查看是否可以解决问题，从而轻松进行testing。