為什麼我無法從我的win2008 NAT 後面連接到某些ftp 伺服器？
我想從位於 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。