我想从位于 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...
确实通过的一点点文本表明它可能是某种 MTU 问题。前进的最佳方式是在网关上安装 Wireshark 并捕获 FTP 连接中涉及的所有流量。如果您看到一个大数据包被多次发送，那就是 MTU。否则，将跟踪粘贴到某处，如果您不清楚，有人可以为您解释它。
附带说明一下，CRC 问题通常是由硬件中直接在 NIC 上完成的校验和引起的。操作系统堆栈不再正确地看到校验和。
尝试打开网卡属性，并禁用任何类型的卸载，它应该删除这些消息。
更新：
在进一步分析您的日志后，似乎没有收到的数据包只有 166 个字节长（它是
Bienvenue在 LAN 接口上一遍又一遍地重新传输的“”），所以我认为这不是 MTU 问题这里。似乎不是auth/ident因为服务器发送了所有数据包。虽然第一个有 CRC 错误。尝试禁用内部网卡上的所有硬件加速（卸载），如果没有帮助，最终也禁用外部网卡。在进行故障排除以一次启用一个潜在原因时，具有固定速度和双工也非常好（10/半双工是一个好的开始）。如果它有效，只需一个接一个地重新启用，以便能够查明问题出在哪里。
如果没有任何效果，则可能是 FTP-NATing 软件有问题：FTP 是一种必须经过修改才能通过 NAT 工作的协议（通常不在这里）。尝试使用 FTP 代理（第 7 层）软件。如果可行，您将有一个解决方法，因为它似乎只适用于 FTP。
您的 NAT 网关中的 FTP 应用程序代理似乎在“220-”多行响应代码上运行。
FTP 响应代码通常都是单行，但数字后面的“-”表示即将输出更多行。
我以前见过这种情况——在我的记忆中，它是一个 PIX 防火墙。
-我似乎记得可以通过在登录密码前加上 ' ', EDIT来告诉某些 FTP 服务器不要发送多行响应，但是在这种情况下，这不是解决方法，因为220-响应是在用户尝试登录之前发送的.如果您对 FTP 服务器的管理员友好，请让他们暂时禁用服务器的登录横幅，并查看您的登录是否继续进行。
我想，我的办公室也遇到了与 IPtables 相同的烦人问题，但我们知道它会发生并且不想修复它。
检查您为传入流量阻止的端口可能会有所帮助。我很确定 FTP 只使用 21 进行传入连接（即你可以连接到某个东西，但你不能对其进行 dir）。
我很确定你得到的端口是可以协商的，所以如果可以的话，在这种情况下废弃 FTP 并使用 SFTP 可能是个好主意。
您可以尝试
debug在 Windows 命令行 ftp 中使用该命令。也许它会向您显示一些导致解决方案的额外信息。病人：医生，医生！当我喝一杯茶时，我的眼睛会刺痛。
医生：试着把勺子从杯子里拿出来！
重点是：为什么将服务器用作 NAT 网关？你的调制解调器/路由器不这样做吗？为什么不将服务器从路径中取出？
我们的 FTP 服务器 (proftpd) 的工作方式是它侦听端口 21 上的连接，然后*一旦连接，将连接提升到 60000 范围**（在 proftpd.conf 中设置为PassivePorts）
我们的 NAT 最初设置为仅将端口 21 转发到 FTP 服务器，我们看到的行为与您所看到的类似。
通过将 PassivePorts 限制为特定范围，并在 NAT 配置中转发该范围，它解决了我们的问题。
当然，那是从服务器端的角度
但是，可以通过暂时对所有端口进行 NAT 并查看它是否解决问题来轻松测试它。