Тайм-аут канала IIS FTP 8.5 DataChannel с клиентом Linux

Question

У меня странная ситуация. Надеюсь, кто-то может помочь. У меня есть два независимых FTP-сервера IIS.

1. а) IIS 7.5 работает как автономная виртуальная машина
2. б) IIS 8.5 работает на виртуальной машине Azure (Windows Server 2012 R2)

Когда я подключаюсь к этим ftp-серверам с помощью FileZilla, оба работают, как и ожидалось, очень хорошо. Пассивный режим, без проблем.

Когда один из клиентов Linux моего клиента подключается, он отлично работает на IIS 7.5, но не работает на IIS 8.5

Останавливается после команды PASV с тайм-аутом. На Linux-клиенте на Fedora запущено какое-то приложение, в которое встроен FTP.

Для аутентификации я использую IIS Manager Users.

Кто-нибудь имеет представление о том, что это может быть? Или как решить эту проблему ?? Я могу проверить и увидеть, как все работает, кроме случаев, когда клиентские процессы выходят на сцену!

После нескольких часов попыток ... я полностью отключил брандмауэр Windows на IIS 8.5 и добавил некоторые разрешающие "все порты" в брандмауэр Azure ... но это не помогло. Мне кажется, что-то в Azure или в новой версии IIS FTP 8.5 ... это может быть?

После установки Wireshark на IIS 8.5 srvr я получил это:

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)

Answer 1

Я вижу ретрансляцию TCP до аборта. Не могли бы вы подтвердить, является ли пакет 370 повторной передачей пакета 298? Если да, это означает, что сервер не получает никакого ответа от клиента, когда он отправляет пакет 298 (вход в пассивный режим). Наиболее распространенной причиной этой проблемы является то, что Azure блокирует соединение клиента с каналом данных сервера.

Мы можем ограничить порт, используемый в качестве канала данных в IIS. Затем мы можем добавить эти порты в брандмауэр Azure, чтобы убедиться, что клиент может инициировать передачу данных на сервер.

Вот хорошее руководство по этому поводу.

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

Обновить

Если вы используете Azure в режиме диспетчера ресурсов (ARM), вам нужно будет открыть порты в группе сетевой безопасности. Вот хорошая статья о разнице между ARM и ASM в сети.

Если вы правильно открыли порт в Azure, но он по-прежнему не работает, попробуйте одновременно выполнить захват сети как на стороне сервера, так и на стороне клиента, чтобы определить пропущенные пакеты.

Если клиент не получает пакет "Вход в пассивный режим" с сервера, проверьте исходящий межсетевой экран на стороне сервера и входящий межсетевой экран на стороне клиента.

Если клиент получает пакеты от сервера, но не отвечает на него. Тогда это должно быть проблемой на стороне клиента.

Если клиент отправляет ответ на сервер, но сервер не получает его, вам следует еще раз проверить правильность списков ACL в группе безопасности сети. Если вы уверены в этом, вам может потребоваться открыть тикет с поддержкой Azure, чтобы выполнить захват сети на узле Azure, чтобы найти, что отбрасывает пакеты.