Ошибка 150 ftp

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

Есть идеи, советы, хитрости, помощь?

FTP-сервер и FTP-клиент согласовывают, какие порты будут использоваться для передачи данных (включая список каталогов, когда вы делаете «dir» или «ls»), используя «канал управления» FTP. Таким образом, если ваш «брандмауэр AWS» не выполняет проверку протокола на этом канале, он никак не сможет узнать, какие порты он должен динамически открыть, чтобы разрешить поток трафика (и закрыть, когда эти порты больше не используются).

ИМХО, используя мониторинг сети, чтобы определить, какие порты используются, не стоит усилий, потому что эти порты будут меняться при каждом новом сеансе FTP.

Если вы еще этого не сделали, мой лучший способ устранения этой проблемы — поиск любых изменений в брандмауэре, защищающем ваш FTP-сервер (если я правильно понимаю ваш вопрос, это будет «брандмауэр AWS») и посмотрите, есть ли это любая «ручка» для включения проверки протокола FTP.

Чтобы получить реальную информацию о том, почему соединение застряло, вам нужно будет использовать клиент, который регистрирует все команды протокола, чтобы увидеть, что на самом деле происходит. Вот хороший сайт на FTP с примерами журналов здесь .

Скорее всего, либо

1. ваш клиент находится за (немым или иначе заблокированным SSL) брандмауэром и пытается использовать FTP в активном режиме
2. ваш сервер находится за (немым или иначе заблокированным 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 Firewall». Каждый используемый вами FTP-сайт будет использовать эти диапазоны портов, для отдельных FTP-сайтов эта опция будет выделена серым цветом, поскольку она унаследована из этого раздела.

В поле Диапазон каналов данных укажите количество портов x , в моем случае 10000-10125 .

Теперь в брандмауэре откройте этот диапазон портов TCP как «Диапазон пассивных портов FTP».

Я тогда думал, что проблема будет решена, но не совсем. Обязательно перезапустите службу службы Microsoft FTP, чтобы подобрать новый диапазон портов. Закройте FireFTP / клиент и повторите попытку, и на этот раз вам повезет.

У меня та же проблема с тобой и исправлена ​​сейчас.

Что я сделал, так это открыл брандмауэр Windows (Win7), нажмите «Разрешить программу или функцию через брандмауэр Windows», а затем в списке «Разрешенные программы и компоненты» найдите «Программа передачи файлов» и установите флажок.

После этого откройте командную строку и введите ftp XXXX, войдите в систему, а затем ls / dir / get / put, все работает.

Но мне все равно не удалось подключиться из File Zilla и веб-браузера, надеюсь, это полезно для вас.

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

Ничего не путайте в настройках

Просто добавьте исходящее правило в брандмауэр Windows для повышения безопасности и укажите номер порта 20.

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

Проблема для меня была на локальном ПК, а не на удаленном хосте. Я подтвердил, что служба FTP на удаленном хосте уже правильно открыла все порты брандмауэра сервера, в которых она нуждалась, поэтому проблем не было. Это был мой локальный клиентский компьютер, который не играл. Так,

1. Я открыл брандмауэр Защитника Windows.
2. Затем я щелкнул ссылку слева «Разрешить приложение или функцию через брандмауэр Защитника Windows»:

1. Я прокрутил вниз до Программы передачи файлов и установил флажки для Домена, Личного и Публичного:

Это наконец исправило это для меня! Когда я пошел, чтобы повторить команду LS, ответ был мгновенным и больше не зависало.

Мы решили эту проблему с помощью мастера создания нового правила брандмауэра Windows. Выберите Program, затем 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+

I’m currently having an issue with our network where our stores are not able to send their orders through FTP to our distributor. I’m an intern and recently in the field but I’ve been researching this issue for the past 2 days with no progress. 

We’re able to connect the the FTP server. Using any commands such as dir cd or ls causes the 150 Opening ASCII hang up.

Using active FTP
Ports 20 and 21 set to allow traffic in both directions
I’ve tried removing the antivirus and firewalls and connecting, same issue
I’ve tried connecting with my personal laptop, same issue

This is currently happening at all 15 locations we maintain so it has to be a configuration issue.

The Clients are using Windows 7
We’re also using Cisco meraki MX64s

I feel like I’ve tried almost everything. Anyone out there have any ideas?