FTP висить: 150 Відкриття підключення даних в режимі ASCII

Я встановлюю FTP-сервер на своєму сервері Windows 2008 (R2).

Здається, все встановлено правильно, але у мене виникли проблеми з використанням FTP-клієнта для входу на мій FTP-сервер.

Я можу віддалений робочий стіл на сервер і через команди DOS я можу ввійти досить легко.

Але якщо я видаю таку команду, як "DIR", вона зависає з: 150 Відкриття підключення даних в режимі ASCII.

Все, що я досліджував і читав, вказує на порти брандмауера та / або налаштування пасивного / активного режиму.

Ось що мене турбує ... якщо я використовую команди DOS FTP, я можу увійти та використовувати команду "DIR" лише у тому випадку, якщо в якості адреси я використовую "localhost".

Якщо я вкажу повну FTP URL-адресу, я отримаю помилку підвішування.

якщо я вкажу URL "localhost", я не отримаю помилку.

Це змушує мене повірити в проблему з брандмауером (або навіть на проблему IIS7?), Але я не знаю, які порти мені потрібно відкрити?

У мене на брандмауері Windows відкриті порти 20, 21. Я також відкрив порти мого брандмауера AWS (Amazon).

Я вважаю, що мій клієнт FTP використовує деякі порти (ів) далекого діапазону, які потенційно блокуються одним із двох моїх брандмауерів. Я використовував інструменти мережевого моніторингу, щоб перевірити, які порти він викликає, але не можу це зрозуміти.

Будь-які ідеї, поради, хитрощі, допомога?

FTP-сервер і FTP-клієнт узгоджують, які порти будуть використовуватися для передачі даних (включаючи список каталогів, коли ви робите "dir" або "ls"), використовуючи "канал управління" FTP. Отже, якщо ваш "AWS брандмауер" не проводить перевірку протоколу на цьому каналі, немає ніякого способу, він дізнається, які порти він повинен динамічно відкривати, щоб забезпечити потік трафіку (і закрити, коли ці порти більше не використовуються).

IMHO, що використовує мережевий моніторинг, щоб виявити, які порти використовуються, не варто докладати зусиль, оскільки ці порти будуть змінюватися для кожного нового сеансу FTP.

Якщо ви вже цього не зробили, найкращим моїм завданням у вирішенні цієї проблеми було б шукати будь-яку настройку на брандмауері, що захищає ваш FTP-сервер (якщо я правильно розумію ваше запитання, це був б "брандмауер AWS") і подивіться, чи є - це будь-яка "ручка", яка дозволяє перевірити протокол FTP.

Я отримав те саме повідомлення при спробі використовувати lsкоманду для списку файлів, що зберігаються на хост-сервері UNIX FTP, з мого командного рядка Ubuntu. Мені вдалося успішно увійти, використовуючи ftp ftp.example.comі ввівши своє ім’я користувача та пароль, коли з'явиться запит. Однак я отримав би 150 Opening ASCII mode data connectionповідомлення, і ніколи нічого не сталося. Потім я просто ввів опцію -p(змінив її на "пасивний" режим для роботи з брандмауерами) з командою, і вона спрацювала.

 ftp -p ftp.example.com

Коли буде запропоновано, введіть ім'я користувача та пароль, а потім такі команди, як lsі cdбудуть працювати. Я вірю, що ви також можете ввести цю команду, і вона зробить те саме, але я не перевірив її.

pftp ftp.example.com

Я знаю, що питання стосується Windows; однак, враховуючи таку саму помилку, було зрозуміло, що цю пораду варто опублікувати.

Щоб отримати реальну інформацію про те, чому зв’язок застряг, вам доведеться використовувати клієнт, який записує всі команди протоколу, щоб побачити, що насправді відбувається. Хороший сайт на FTP з прикладом журналів тут .

Швидше за все, будь-який

1. ваш клієнт стоїть за (тупою або інакше заблокованою SSL) брандмауером і намагається використовувати FTP в активному режимі
2. ваш сервер знаходиться за (німим або інакше заблокованим SSL) брандмауером і намагається використовувати FTP в пасивному режимі

Якщо ви використовуєте SSL, єдиною відповіддю є відкриття діапазону портів (скажімо, 10000-11000) на брандмауері та налаштування вашого FTP-сервера для застосування пасивного режиму та використання цього діапазону портів. Якщо ваш сервер використовує NAT, вам також знадобиться встановити належну IP-адресу для того, щоб сервер рекламував клієнтів, більшість підкоряється тому, що сервер надає як рядок підключення в пасивному режимі, і якщо сервер вважає, що це 10.1.1.1, ось що це розповість клієнтам.

Якщо ви не використовуєте SSL, найкраща відповідь - це дізнатися, чи можете ви отримати ваш брандмауер для перевірки протоколу для FTP. Брандмауер прочитає трафік на порт 21 і відкриє той порт, який ваш сервер хоче відкрити. Це також часто може виправити NAT-адреси (коли брандмауер також обробляє NAT). Ви, ймовірно, все ще захочете застосувати пасивний режим, оскільки деякі люди не знають, як правильно настроїти свій FTP-клієнт, і майже всі стоять за широкосмуговим маршрутизатором / брандмауером сьогодні.

Якщо ви не можете отримати більш розумний брандмауер, вам доведеться дотримуватися опції "відкрити купу портів" (або перейти до протоколу, для якого не потрібно відкривати купу випадкових портів, таких як ssh sftp).

У мене була ця проблема, і її вирішили, зробивши наступне.

Я використовував FireFTP, який за замовчуванням підключається через пасивний режим. При встановленні FTP в IIS порт за замовчуванням буде 21. Мені довелося відкрити порт 21 в брандмауері, що дало мені етап, але він завис при відкритті підключення даних в режимі ASCII .

Виявляється, він вибирає деякі інші динамічні порти. Я знав, що це проблема брандмауера, оскільки з брандмауером відключений FTP з'єднується добре. Також локально на сервері - ніяких проблем.

Щоб виправити, я завантажив IIS (використовуючи версію 8.0, вважаю, що це те саме в 7.5), на рівні сервера дерева (тобто верхній вузол) одним клацанням клацніть по ньому та виберіть "Підтримка брандмауера FTP". Кожен FTP-сайт, який ви використовуєте, буде використовувати ці діапазони портів, окремі FTP-сайти матимуть цей параметр замурованим, оскільки він успадкований з цього розділу.

У діапазоні портів каналів даних вкажіть x кількість портів, у моєму випадку 10000-10125 .

Тепер у вашому брандмауері відкрийте діапазон портів TCP як "FTP діапазон пасивних портів".

Тоді я думав, що проблема буде вирішена, але не зовсім. Не забудьте перезапустити послугу Microsoft FTP, щоб отримати новий діапазон портів. Закрийте FireFTP / клієнт і повторіть спробу, і на цей раз за будь-якої удачі ви опинитеся :)

У мене те саме питання з вами і вирішено зараз.

Що я зробив, це відкрити брандмауер Windows (Win7), натиснути "Дозволити програму або функцію через брандмауер Windows", а потім у списку "Дозволені програми та функції" дізнайтеся "Програма передачі файлів" і поставте прапорець.

Після цього відкрийте командний рядок і введіть ftp XXXX, увійдіть, а потім ls / dir / get / put, і все працює зараз.

Але мені все-таки не вдалося підключитися з File Zilla та Web Browser, сподіваюся, це корисно для вас.

Перевірте синхронізацію часу вашого сервера

Не плутайте нічого під час налаштування

Просто додайте вихідне правило у брандмауер Windows із попередньою безпекою та поставте порт №20.

Насолоджуйтесь FTP на CLI

Проблема для мене була на локальному ПК, а не на віддаленому хості. Я підтвердив, що встановлення служби FTP на віддаленому хості вже належним чином відкрило всі порти брандмауера сервера, для чого це потрібно, тому це не було проблемою. Це мій локальний клієнтський ПК не грав разом. Так,

1. Я відкрив брандмауер Windows Defender.
2. Потім я натиснув посилання зліва "Дозволити програму або функцію через брандмауер Windows Defender":

3. Я прокрутився вниз до програми передачі файлів і встановив прапорці для домену, приватного та загальнодоступного:

Це остаточно виправило це для мене! Коли я пішов повторити команду LS, відповідь була миттєвою і більше не зависало.

Ми вирішили цю проблему за допомогою майстра нового вхідного правила брандмауера Windows. Виберіть Програма, потім C: \ Windows \ System32 \ ftp.exe, Дозволити з'єднання, Перевірте параметри; Домен, приватний, загальнодоступний (ви можете обмежити пізніше, якщо потрібно), назвіть правило, і все закінчиться.

Тепер ftp на ftp-сайт і переконайтеся, що dir або ls відповідають правильно.

Я стикався з тим же питанням, що і з ОП

200 PORT команда успішна.
150 Відкриття підключення до даних у режимі ASCII.
425 Неможливо відкрити з'єднання даних.

З цією проблемою я зіткнувся, коли намагався використовувати пасивний режим у командному рядку в Windows.
Я знайшов потрібну інформацію шляхом пошуку матеріалів:

IE зазвичай використовує пасивний режим, тоді як утиліта командного рядка (ftp команда) завжди використовує активний режим.

Я спробував попередню операцію в IE, і вона спрацювала. Проблема вирішена

посилання на матеріали: https://forums.iis.net/t/1207342.aspx?150+Opening+ASCII+mode+data+connection+for+file+list+425+Can+t+open+data+connection+