Усім доброго ранку,
Я розміщую 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+, призначених серверу FileZilla FTP (що діє в пасивному режимі).
У мене є запуск Wireshark на VM, розміщеному в Azure; З Wireshark видно, що події "закрито з'єднання 426" насправді узгоджуються за допомогою RST, джерелом якого є VM в 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
Але проблема все ще виникає зрідка.
Я читав широкі технічні дискусії на цьому веб-сайті, а також на сесії технології Az Azure про те, як Azure контролює стан кінцевих точок (коли є частиною набору LB), але це не застосовується в моєму випадку як пасивні передачі FTP (пошук та завантаження) на випадкових портах в межах зарезервованого діапазону пасивних портів FTP, як правило, працюють нормально.
Я можу надати додаткові деталі, якщо потрібно - тим часом я буду вдячний за додаткові пропозиції щодо усунення несправностей / розслідування на стороні сервера та клієнта (майже впевнений, що проблема не пов’язана з мережею або мережевою конфігурацією).
Я також хотів би попросити додаткових пропозицій щодо усунення несправностей / розслідувань / порад щодо того, як налагодити winsock для можливих проблем із доступністю розеток на стороні сервера.
426
помилка переривання вагітності завжди йшла через пару секунд за іншим сеансом, отримуючи 550
дозволу, відхиленого помилку. Я підозрюю, що це помилка з FileZilla, але для нас виправленням було запобігання 550 (у нашому випадку тестова система намагалася отримати доступ до тестової папки, але використовуючи виробничі дані; тому нам просто довелося виправити дані системи) .