IIS FTP 8.5 DataChannel 与 Linux 客户端超时

IIS FTP 8.5 DataChannel 与 Linux 客户端超时

我遇到了一个奇怪的情况。希望有人能帮忙。我有两个独立的 IIS FTP 服务器。

  1. a) IIS 7.5 作为独立虚拟机运行
  2. b)IIS 8.5 在 Azure VM(Windows Server 2012 R2)上运行

当我使用 FileZilla 连接到这些 ftp 服务器时,两者都按预期运行,非常好。被动模式,没有问题。

当我的一个客户的 Linux 客户端连接时,它在 IIS 7.5 上运行良好,但在 IIS 8.5 上不起作用

它在 PASV 命令后因超时而停止。Linux 客户端正在 Fedora 上运行一些包含 FTP 的应用程序。

对于身份验证,我使用 IIS 管理器用户。

有人知道这可能是什么吗?或者如何排除故障?我可以测试,并且看到一切正常,除了客户端进程进入场景时!

经过几个小时的尝试...我完全关闭了 IIS 8.5 上的 Windows 防火墙,并在 Azure 防火墙中添加了一些允许“所有端口”的选项...但没有帮助。对我来说,这似乎是 Azure 或新版本的 IIS FTP 8.5 中的问题...可能是这样吗?

在 IIS 8.5 srvr 上安装 Wireshark 后,我得到了以下信息:

230 User logged in.
USER someuser
PASS somepassword
TYPE A
200 Type set to A.
PASV
227 Entering Passive Mode (xxx,166,145,222,20,18).
ABOR
226 ABOR command successful.

数据包:

297 15.067087   ###.41.121.116  10.0.0.4    FTP 72  Request: PASV
298 15.067223   10.0.0.4    ###.41.121.116  FTP 117 Response: 227 Entering Passive Mode (XXX,166,145,222,20,18).
300 15.083895   ###.41.121.116  10.0.0.4    TCP 66  39240 → 21 [ACK] Seq=46 Ack=143 Win=5888 Len=0 TSval=1985344095 TSecr=659594
370 19.338991   10.0.0.4    ###.41.121.116  TCP 86  [TCP Retransmission] 21 → 58522 [PSH, ACK] Seq=72 Ack=40 Win=131072 Len=20 TSval=660021 TSecr=1985339032
431 23.746259   ###.41.121.116  10.0.0.4    FTP 72  Request: ABOR
432 23.746366   10.0.0.4    ###.41.121.116  FTP 96  Response: 226 ABOR command successful.
433 23.762471   ###.41.121.116  10.0.0.4    TCP 66  45877 → 21 [ACK] Seq=7 Ack=31 Win=46 Len=0 TSval=1985352774 TSecr=660462

软件包 299、301-369、371-430 属于其他进程(主要是 RDP)

答案1

我看到在中止之前有一次 TCP 重传。请确认数据包 370 是否是数据包 298 的重传?如果是,则意味着服务器在发出数据包 298(进入被动模式)时没有收到来自客户端的任何响应。此问题最常见的原因是 Azure 阻止了从客户端到服务器的数据通道的连接。

我们可以在IIS中限制作为数据通道的端口,然后我们可以将这些端口添加到Azure防火墙中,以确保客户端可以向服务器发起数据传输。

这是一个很好的指导关于它。

========================================

更新

如果您在资源管理器模式 (ARM) 中使用 Azure,则需要打开网络安全组中的端口。以下是文章关于ARM和ASM在网络上的区别。

如果您确实在 Azure 中正确打开了端口但仍然不起作用,那么请尝试同时在服务器和客户端执行网络捕获以找出丢弃的数据包。

如果客户端没有收到服务器发来的“进入被动模式”数据包,请检查服务器端的出站防火墙和客户端的入站防火墙。

如果客户端收到服务器发来的数据包但没有响应,那么这应该是客户端的问题。

如果客户端向服务器发送响应但服务器没有收到,那么您应该重新检查网络安全组中的 ACL 是否正确。如果您确定,那么您可能需要向 Azure 支持人员开具一张票据,在 Azure 主机上执行网络捕获,以找出丢弃数据包的原因。

相关内容