我想从位于 NAT 后面的本地网络连接到 FTP 服务器。
网关是 Win 2008 服务器，配置了路由和远程服务/启用了 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>
正如您所看到的，我在登录过程之前就断开了连接，所以我没有机会使用 PASSV。
工作原理如下：
- 其余一切（即所有与 FTP 无关的连接）
- 从我的 NAT 网关连接到此特定服务器
- 从我的后置计算机连接到其他服务器
- 从我的电脑直接连接到这个特定的 ftp 服务器（即不使用 NAT 服务器）
提供 FTP 的公司表示问题不在于他们，因为我可以从我的 NAT 服务器连接。同样的推理也表明问题也不在我这边（我可以在其他 FTP 服务器上连接）
我应该检查什么？
编辑：这是我在尝试从我的后台计算机进行连接时嗅探网关上的连接时得到的结果：
在面向 Internet 的界面上：
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...
答案1
能通过的那一点点文本表明这可能是某种 MTU 问题。最好的解决方法是在网关上安装 Wireshark 并捕获 FTP 连接中涉及的所有流量。如果您看到一个大数据包被多次发送，那就是 MTU 问题。否则，如果您不清楚，请将跟踪粘贴到某处，有人可以为您解释。
答案2
顺便提一下，CRC 问题通常是由硬件中直接在 NIC 上进行的校验引起的。这样 OS 堆栈就无法再正确看到校验和了。
尝试打开网卡属性，并禁用任何类型的卸载，它应该会删除这些消息。
更新：
进一步分析您的日志后，似乎未收到的数据包只有 166 个字节长（它是BienvenueLAN 接口上反复重新传输的“ ”数据包），因此我认为这里不是 MTU 问题。似乎不是auth/ident因为服务器发送了所有数据包。尽管第一个数据包中有 CRC 错误，但确实如此。
尝试禁用内部网卡上的所有硬件加速（卸载），如果不起作用，最终也禁用外部网卡上的硬件加速。在排除故障时，拥有固定的速度和双工也很不错，可以一次启用一个潜在原因（10/半双工是个不错的开始）。如果有效，只需逐一重新启用，就能查明问题所在。
如果什么都不起作用，那么可能是 FTP-NATing 软件出了问题：FTP 是一种必须经过修改才能通过 NAT 的协议（通常不需要）。尝试使用 FTP 代理（第 7 层）软件。如果可行，您将有一个解决方法，因为它似乎仅适用于 FTP。
答案3
您的 NAT 网关中的 FTP 应用程序代理似乎在“220-”多行响应代码上出现故障。
FTP 响应代码通常都是单行，但数字后面的“-”表示将有更多行输出。
我以前见过这种情况 - 在我的记忆中它是一个 PIX 防火墙。
我似乎记得有些 FTP 服务器可以通过在登录密码前加上“ -”来告诉它们不要发送多行响应， 编辑但是在这种情况下这不是解决办法，因为220-响应是在用户尝试登录之前发送的。
如果您与 FTP 服务器的管理员关系友好，请他们暂时禁用其服务器的登录横幅，然后查看您的登录是否可以继续。
答案4
您可以尝试使用debugWindows 命令行 ftp 中的命令。也许它会向您显示一些额外的信息，从而找到解决方案。