FTP зависает: 150 Открытие режима передачи данных в режиме ASCII
Я устанавливаю FTP-сервер на моем сервере Windows 2008 (R2).
Кажется, все установлено правильно, но у меня проблемы с использованием FTP-клиента для входа на мой FTP-сервер.
Я могу удаленно подключиться к серверу и с помощью команд DOS войти довольно легко.
Но если я выполняю команду типа "DIR", она зависает с: 150 Открытие соединения для передачи данных в режиме ASCII.
Все, что я исследовал и прочитал, указывает на порты брандмауэра и / или настройки пассивного / активного режима.
Вот что меня беспокоит... если я использую команды DOS FTP, я могу войти в систему и использовать команду "DIR", только если я использую "localhost" в качестве своего адреса.
Если я укажу свой полный URL-адрес FTP, я получу ошибку зависания.
если я укажу URL "localhost", я не получу сообщение об ошибке.
Это заставляет меня поверить, что это проблема брандмауэра (или даже проблема IIS7?), Но я не уверен, какие порты мне нужно открыть?
На моем брандмауэре Windows открыты порты 20, 21. Я также открыл эти порты на своем брандмауэре AWS (Amazon).
Я считаю, что мой FTP-клиент использует некоторые номера портов дальнего радиуса действия, которые могут быть заблокированы одним из двух моих брандмауэров. Я использовал инструменты сетевого мониторинга, чтобы попытаться увидеть, какие порты он вызывает, но я не могу понять это.
Есть идеи, советы, хитрости, помощь?
12 ответов
Я получил то же сообщение при попытке использовать 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-сервер и FTP-клиент согласовывают, какие порты будут использоваться для передачи данных (включая список каталогов, когда вы делаете "dir" или "ls"), используя "канал управления" FTP. Поэтому, если ваш "брандмауэр AWS" не выполняет проверку протокола на этом канале, он никак не сможет узнать, какие порты он должен динамически открыть, чтобы разрешить поток трафика (и закрыть, когда эти порты больше не используются).
ИМХО использовать мониторинг сети для определения используемых портов не стоит усилий, поскольку эти порты будут меняться при каждом новом сеансе FTP.
Если вы еще этого не сделали, мой лучший способ устранения этой проблемы - поиск любых изменений в брандмауэре, защищающем ваш FTP-сервер (если я правильно понимаю ваш вопрос, это будет "брандмауэр AWS") и посмотрите, есть ли любая "ручка" для включения проверки протокола FTP.
Чтобы получить реальную информацию о том, почему соединение застряло, вам нужно будет использовать клиент, который регистрирует все команды протокола, чтобы увидеть, что на самом деле происходит. Вот хороший сайт на FTP с примерами журналов здесь.
Скорее всего, либо
- ваш клиент находится за (немым или иначе заблокированным SSL) брандмауэром и пытается использовать FTP в активном режиме
- ваш сервер находится за (немым или иначе заблокированным SSL) брандмауэром и пытается использовать FTP в пассивном режиме
Если вы используете SSL, единственный ответ - открыть диапазон портов (скажем, 10000-11000) на брандмауэре и настроить FTP-сервер на принудительный пассивный режим и использовать этот диапазон портов. Если ваш сервер использует NAT, вам также необходимо настроить надлежащий IP-адрес для сервера, который будет рекламироваться клиентам, большинство подчиняется тому, что сервер предоставляет в качестве строки подключения в пассивном режиме, и если сервер считает, что это 10.1.1.1, вот что это собирается рассказать клиентам.
Если вы не используете SSL, лучший ответ - посмотреть, сможете ли вы заставить свой брандмауэр выполнять проверку протокола для FTP. Брандмауэр считывает трафик на порте 21 и открывает любой порт, который хочет открыть ваш сервер. Это часто может также исправить адреса NAT (когда межсетевой экран также обрабатывает NAT). Возможно, вы все равно захотите включить пассивный режим, поскольку некоторые люди не знают, как правильно настроить свой FTP-клиент, и почти все в настоящее время находятся за широкополосным маршрутизатором / брандмауэром.
Если вы не можете получить более интеллектуальный брандмауэр, вам придется придерживаться опции "открыть кучу портов" (или переключиться на протокол, который не должен открывать кучу случайных портов, таких как ssh ssh ssh).
У меня была эта проблема, и она была решена путем выполнения следующих действий.
Я использовал FireFTP, который по умолчанию подключается через пассивный режим. При настройке FTP в IIS порт по умолчанию будет 21. Мне пришлось открыть порт 21 в брандмауэре, который продвинул меня дальше, но он зависал при открытии соединения для передачи данных в режиме ASCII.
Оказывается, он выбирает другие динамические порты. Я знал, что это проблема с брандмауэром, так как при отключенном брандмауэре FTP-соединение нормально работает Также локально на сервере - без проблем.
Чтобы исправить это, я загрузил IIS (используя версию 8.0, полагаю, что это то же самое в 7.5), на уровне сервера дерева (то есть верхнего узла), щелкните его один раз и выберите "Поддержка брандмауэра FTP". Каждый используемый вами FTP-сайт будет использовать эти диапазоны портов, для отдельных FTP-сайтов эта опция будет выделена серым цветом, поскольку она унаследована из этого раздела.
В поле " Диапазон каналов передачи данных" укажите количество портов x, в моем случае 10000-10125.
Теперь в брандмауэре откройте этот диапазон портов TCP как "Диапазон пассивных портов FTP".
Я тогда думал, что проблема будет решена, но не совсем. Обязательно перезапустите службу службы Microsoft FTP, чтобы выбрать новый диапазон портов. Закройте FireFTP/ клиент и повторите попытку, и на этот раз вам повезет.:)
Мы решили эту проблему с помощью мастера создания нового правила брандмауэра Windows. Выберите Program, затем C:\Windows\System32\ftp.exe, Разрешить соединение, Проверить параметры; Домен, Приват, Публичный (вы можете ограничить позже, если это необходимо), назовите правило, и все готово.
Теперь перейдите по ftp на сайт ftp и убедитесь, что dir или ls отвечают правильно.
Я только что включил FTP-сервер IIS в Windows 11 и увидел точно такую же проблему на клиентском ПК. Этот сайт оказался самым популярным среди моих поисков решения в Интернете. Ответа так и не нашел, поэтому публикую его здесь:
Исправление оказалось на клиентском ПК, это тоже коробочка с Windows 11 в той же подсети. Видимо, мне пришлось «Разрешить приложение через брандмауэр» на этом компьютере.
Я потратил часы, пытаясь настроить FTP-сервер для работы в пассивном режиме.
Ничего не путайте в настройках
Просто добавьте правило для исходящих сообщений в брандмауэр Windows в целях повышения безопасности и укажите номер порта 20.
Наслаждайтесь FTP на CLI
У меня та же проблема с тобой и исправлена сейчас.
Что я сделал, так это открыл брандмауэр Windows (Win7), нажмите "Разрешить программу или функцию через брандмауэр Windows", а затем в списке "Разрешенные программы и компоненты" найдите "Программа передачи файлов" и установите флажок.
После этого откройте командную строку и введите ftp XXXX, войдите в систему, а затем ls/dir/get/put, все работает.
Но мне все равно не удалось подключиться из File Zilla и веб-браузера, надеюсь, это полезно для вас.
Проблема для меня была на локальном ПК, а не на удаленном хосте. Я подтвердил, что служба FTP на удаленном хосте уже правильно открыла все порты брандмауэра сервера, в которых она нуждалась, поэтому проблем не было. Это был мой локальный клиентский компьютер, который не играл. Так,
- Я открыл брандмауэр Защитника Windows.
- Затем я щелкнул ссылку слева "Разрешить приложение или функцию через брандмауэр Защитника Windows":
- Я прокрутил вниз до Программы передачи файлов и установил флажки для Домена, Личного и Публичного:
Это наконец исправило это для меня! Когда я пошел, чтобы повторить команду 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+
В большинстве случаев, я обнаружил, что соединение блокирует брандмауэр. Как указано в @shieldofsalvation, необходимо разрешить использование брандмауэра. Но список по умолчанию может не содержать опцию "Программа передачи файлов".
Чтобы добавить это в список, щелкните,
Allow another app...
>
Browse...
>
Select
ftp.exe из
System32
папка> щелкните
Add
, то он появится в списке.