8

Доброе утро всем,

Я размещаю FTP-сервер FileZilla (пассивный режим) на сервере WIN 2012 R2, размещенном в MS Azure.

Передачи по FTP обычно работают нормально. Несколько загрузок и загрузок по FTP выполняются ежедневно.

Я открыл относительно большой диапазон портов (конечных точек) на портале / стороне Azure, чтобы разрешить пассивный режим.

Спорадически (в среднем раз в 2 дня) я вижу проблемы с передачей по FTP, подобные следующим:

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> MDTM dev_updates/file1

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 213 20160728071048

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> MDTM dev_updates/file2

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 213 20160728071048

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> MDTM dev_updates/file3

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 213 20160728071050

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> CWD dev_updates/Infrastructure/folder

8/8/2016 9:09:59 AM - USER_FILEZILLA (62.154.Y.X)> 250 CWD successful. "dev_updates/Infrastructure/folder" is current directory.

8/8/2016 9:10:00 AM - USER_FILEZILLA (62.154.Y.X)> PASV

8/8/2016 9:10:00 AM - USER_FILEZILLA (62.154.Y.X)> 227 Entering Passive Mode (104,40,Y,X,234,235)

8/8/2016 9:10:00 AM - USER_FILEZILLA (62.154.Y.X)> 426 Connection closed; aborted transfer of ""

8/8/2016 9:10:01 AM - USER_FILEZILLA (62.154.Y.X)> disconnected.

8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> Connected on port 21, sending welcome message...

8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 220-FileZilla Server 0.9.57 beta

8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 220-written by Tim Kosse (tim.kosse@filezilla-project.org)

8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 220 Please visit https://filezilla-project.org/

8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> USER USER_FILEZILLA

8/8/2016 9:10:01 AM - (not logged in) (62.154.Y.X)> 331 Password required for 

Как уже упоминалось, существует несколько передач по FTP, которые выполняются ежедневно (автоматически) и охватывают диапазон портов более 140, назначенный FTP-серверу FileZilla (действующий в пассивном режиме).

У меня есть перехват Wireshark, запущенный на виртуальной машине, размещенной в Azure; Из снимков Wireshark видно, что события "426 закрытое соединение" на самом деле соответствуют RST, полученному от виртуальной машины в Azure, и отправлены обратно клиенту, который выполнил команду PASV (то есть в приведенном выше примере сервер FTP отвечает клиентская команда PASV с портом: 234,235 -> 60139; клиент пытается открыть канал данных для порта 60139, чтобы начать передачу -> FTP-сервер немедленно отвечает (в пределах MS согласно перехвату Wireshark), выдавая RST клиенту).

Я подумал о некоторой проблеме выделения эфемерных портов на стороне сервера FTP -> поэтому я уменьшил допустимый диапазон эфемерных портов динамической ОС, чтобы не перекрывать диапазон пассивных портов FTP - используя

netsh int ipv4 set dynamicport tcp start=49152 num=10000

также я явно добавил резервирование диапазона портов в стек netsh с помощью команды

netsh int ip add excludeportrange protocol=tcp startport=60000 numberofports=141 store=persistent

Тем не менее, проблема все еще иногда возникает.

На этом веб-сайте, а также в техническом сеансе MS Azure я прочитал подробные технические обсуждения о том, как Azure отслеживает состояние конечных точек (когда оно входит в набор LB), но в моем случае это неприменимо в качестве пассивных передач FTP (поиск и загрузка). на случайных портах в пределах зарезервированного диапазона пассивных портов FTP, как правило, работает нормально.

Я могу предоставить дополнительные сведения, если это необходимо - тем временем я был бы признателен за дополнительные предложения по устранению неполадок / расследованиям на стороне сервера и клиента (почти уверен, что проблема не связана с сетью или конфигурацией сети).

Я также хотел бы попросить дополнительные советы по устранению неполадок / расследованию / советы по отладке winsock для возможных проблем с доступностью сокетов на стороне сервера.

0