windows-server-2008 – 为什么我不能从win2008 NAT后面连接到某些ftp服务器?

前端之家收集整理的这篇文章主要介绍了windows-server-2008 – 为什么我不能从win2008 NAT后面连接到某些ftp服务器?前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我想从本地网络连接到FTP服务器,该网络位于NAT后面.

网关是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.否则,将痕迹粘贴到某处,如果您不清楚,有人可以为您解释.

猜你在找的Windows相关文章