Усім доброго ранку,
Я розміщую 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 (у нашому випадку тестова система намагалася отримати доступ до тестової папки, але використовуючи виробничі дані; тому нам просто довелося виправити дані системи) .