Доброе утро всем,
Я размещаю 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 для возможных проблем с доступностью сокетов на стороне сервера.
426
ошибка аборта всегда сопровождала пару секунд после другого сеанса, получая550
ошибку отказа в разрешении. Я подозреваю, что это ошибка в FileZilla, но для нас исправлением было предотвратить 550 (в нашем случае тестовая система пыталась получить доступ к тестовой папке, но с использованием производственных учетных данных; поэтому нам просто пришлось исправить учетные данные этой системы) ,