Я настраиваю FTP-сервер на своем сервере Windows 2008 (R2).
Кажется, все установлено правильно, но у меня возникают проблемы с использованием FTP-клиента для входа на мой FTP-сервер.
Я могу подключать удаленный рабочий стол к серверу и с помощью команд DOS довольно легко могу войти в систему.
Но если я введу команду типа «DIR», она зависнет с: 150 Открытие соединения для передачи данных в режиме ASCII.
Все, что я исследовал и читал, указывает на порты брандмауэра и / или настройки пассивного / активного режима.
Вот что меня беспокоит ... если я использую команды FTP DOS, я могу войти в систему и использовать команду «DIR», только если я использую «localhost» в качестве своего адреса.
Если я укажу свой полный URL-адрес FTP, я получаю сообщение об ошибке.
если я укажу URL "localhost", я не получу сообщение об ошибке.
Это заставляет меня думать, что это проблема с брандмауэром (или даже с IIS7?), Но я не уверен, какие порты мне нужно открыть?
У меня на брандмауэре Windows открыты порты 20, 21. Я также открыл эти порты на своем брандмауэре AWS (Amazon).
Я считаю, что мой FTP-клиент использует некоторые номера портов дальнего действия, которые потенциально заблокированы одним из двух моих брандмауэров. Я использовал инструменты сетевого мониторинга, чтобы попытаться увидеть, какие порты он вызывает, но я не могу этого понять.
Есть идеи, советы, хитрости, помощь?
Сервер FTP и клиент FTP согласовывают, какие порты будут использоваться для передачи данных (включая список каталогов, когда вы выполняете «dir» или «ls»), используя «канал управления» FTP. Поэтому, если ваш «брандмауэр AWS» не проверяет протокол на этом канале, он не сможет узнать, какие порты он должен динамически открывать, чтобы разрешить поток трафика (и закрывать, когда эти порты больше не используются).
IMHO использование сетевого мониторинга для обнаружения используемых портов не стоит усилий, потому что эти порты будут меняться для каждого нового сеанса FTP.
Если вы еще не сделали это, моим лучшим способом устранения этой проблемы будет поиск любых настроек в брандмауэре, который защищает ваш FTP-сервер (если я правильно понимаю ваш вопрос, это будет «брандмауэр AWS») и посмотреть, есть ли там - это любая «ручка» для включения проверки протокола FTP.
Я получил такое же сообщение при попытке использовать ls
чтобы вывести список файлов, хранящихся на FTP-сервере UNIX, из командной строки 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 с примерами логов Вот.
Скорее всего, либо
Если вы используете 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 Firewall». Каждый FTP-сайт, который вы используете, будет использовать эти диапазоны портов, для отдельных FTP-сайтов этот параметр будет выделен серым цветом, поскольку он унаследован от этого раздела.
В поле Data Channel Port Range укажите Икс количество портов, в моем случае 10000-10125.
Теперь в вашем брандмауэре откройте этот диапазон портов TCP как «диапазон пассивных портов FTP».
Тогда я подумал, что проблема будет решена, но не совсем. Обязательно перезапустите Служба Microsoft FTP сервис подобрать новый диапазон портов. Закройте FireFTP / клиент и повторите попытку, и на этот раз, если вам повезет, вы попадете. :)
У меня такая же проблема с вами, и я ее исправил.
Что я сделал, так это открыл брандмауэр Windows (Win7), щелкнул «Разрешить программу или функцию через брандмауэр Windows», а затем в списке «Разрешенные программы и функции» найти «Программа передачи файлов» и установить флажок.
После этого откройте командную строку и введите ftp X.X.X.X, войдите в систему, а затем ls / dir / get / put, теперь все работает.
Но мне все еще не удалось подключиться из File Zilla и веб-браузера, надеюсь, это будет полезно для вас.
Проверьте синхронизацию времени вашего сервера
Ничего не портите в своей настройке
Просто добавьте правило исходящего трафика в брандмауэр Windows с повышенной безопасностью и укажите порт номер 20.
Наслаждайтесь FTP через CLI
Проблема для меня была на локальном ПК, а не на удаленном хосте. Я подтвердил, что установка службы FTP на удаленном хосте уже правильно открыла все необходимые порты на брандмауэре сервера, так что проблема не в этом. Это был мой локальный клиентский компьютер, который не подыгрывал. Так,
Это наконец исправило это для меня! Когда я попытался повторить команду LS, ответ был мгновенным и больше никаких зависаний.
Мы решили эту проблему с помощью мастера создания правила для входящих подключений брандмауэра Windows. Выберите Программа, затем C: \ Windows \ System32 \ ftp.exe, Разрешите подключение, Проверьте параметры; Доменное, Частное, Общедоступное (вы можете ограничить позже, если потребуется), назовите правило, и все готово.
Теперь перейдите по ftp на сайт ftp и проверьте, правильно ли отвечает dir или ls.
Я столкнулся с той же проблемой, что и OP
Команда 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+