Я использую Windows 7, и у меня есть несколько клиентских приложений FTP, работающих без проблем. Однако, когда я использую FTP из командной строки, я могу подключиться, войти (после ввода имени пользователя и пароля), но он всегда отключается при использовании команды dir или ls. Ответ:
Соединение закрыто удаленным хостом.
Как я могу исправить эту проблему?
Обычно это происходит, когда сервер пытается подключиться к вам, но не может. Первоначально FTP использовал два канала TCP . Один был для команд, а другой для передачи данных. Когда вы запускаете команду dir, она использует канал данных. Канал данных устанавливается по требованию, и в результате сервер пытается подключиться к вам.
Скорее всего, это заблокировано вашим маршрутизатором или брандмауэром Windows. Вам нужен клиент, который поддерживает режим PASV .
Вы можете включить режим PASV в Internet Explorer. Или используйте другой клиент. Я не уверен, может ли версия командной строки использовать режим PASV. Это очень простой клиент.
Клиент командной строки Windows FTP ftp.exe поддерживает только активный режим FTP.
Настройка FTP в активном режиме в настоящее время может быть затруднена из-за брандмауэров и NAT.
Вероятно, из-за вашего локального брандмауэра или NAT сервер не смог подключиться обратно к вашему клиенту, чтобы установить соединение для передачи данных для списка каталогов (команды ls или dir ).
Или ваш клиент не знает о своем внешнем IP-адресе и вместо этого предоставляет внутренний адрес серверу (в команде PORT ), который сервер, очевидно, не может использовать.
Смотрите мою статью Конфигурация сети для активного режима.
Если возможно, вы должны использовать пассивный режим, так как он обычно не требует дополнительной настройки на стороне клиента.
К сожалению, клиент командной строки Windows FTP (ftp.exe) вообще не поддерживает пассивный режим. Это делает его довольно бесполезным в наши дни.
Вместо этого используйте любой другой клиент командной строки Windows FTP. Большинство других поддерживают пассивный режим.
Например, WinSCP по умолчанию работает в пассивном режиме, и есть руководство по преобразованию сценария Windows FTP в сценарий WinSCP.
(Я автор WinSCP)
У меня возникла проблема с передачей файлов по FTP после того, как я вошел в соответствующий ящик. Это создаст имя файла, но файл будет пустым. Я решил это, сделав следующее:
Это должно быть хорошо идти сейчас.
Я столкнулся с этой проблемой на сервере Windows 2008.
В этой статье предлагается включить службу шлюза уровня приложений. Это не решило проблему для меня.
Что решило проблему, добавив исключение в брандмауэр Windows для C:\Windows\system32\ftp.exe
У меня возникла та же проблема со сторонним программным обеспечением POS на компьютере под управлением Windows 7, который перенаправляет данные транзакций клиента обратно на сервер SQL.
Это работало нормально, пока местоположение клиента не изменило интернет-провайдеров и, следовательно, статические IP-адреса. Команды FTP командной строки не работали после первоначального входа в систему, и ни одно из средств, которые я нашел онлайн или этот поток, не работало.
Просто для удовольствия я заново создал правило FTP в брандмауэре, дешевом роутере / брандмауэре D-Link и альте, похоже, оно снова работает.
Проблема с FTP
Открытые порты на Azure NSG и межсетевом экране сервера: 21,20,4000-40009,990,14147
Проблема: Клиент не может подключиться к ftp из командной строки и Powershell
Мы можем связаться с testuser, но не можем увидеть каталог / Список
Установлен Wireshark на сервере и на моем ноутбуке для захвата пакетов. Создан фильтр на Wireshark с «ftp» и «IP». При захвате пакетов не указывается погода, пассивный или активный режим, а исходный IP-адрес правильный. (настраиваем первичный и вторичный IP на сервере)
Мы обнаружили, что соединение ftp не работает из командной строки. Попытка инициировать соединение с ftp.abcd.com, которое было разрешено в 11.22.33.44, а не к фактическому FTP-серверу. 44.33.22.11. IP-адреса 11.22.33.44 и 44.33.22.11 настроены на одном компьютере. Однако DNS преобразовывался в дополнительный IP-адрес FTP вместо основного
Первоначально мы также обнаружили, что FTP-соединения с 11.22.33.44 работали нормально, и эти соединения были активными. Мы не смогли увидеть, что пассивный режим работает здесь. Кроме того, во время инициализации подключения к 11.22.33.44 из командной строки Commad сеанс останавливается после того, как вы даете команду 'dir', однако то же самое работает с другими клиентами ftp, такими как FileZilla и Winscp.
Я попытался протестировать с WinSCP и FileZilla и увидел, что соединения в пассивном режиме работают нормально, а Active - нет, что является ожидаемым поведением. Мы проверили, почему команда «dir» не работает с устройств после успешной аутентификации, мы увидели, что брандмауэр Windows блокирует соединение. Мы отключили брандмауэр, и все стало работать как положено. Я проверил то же самое на своем конце после создания правила брандмауэра, проблемы были решены. Была одна система, которая даже после отключения брандмауэра застряла в списке каталогов, это может быть проблемой в этой системе, или соединения блокируются внешним фактором. Поскольку после отключения большинство из нас способны нормально работать.
на машине необходимо выполнить настройки. Выберите "Панель управления" → "Брандмауэр Windows" → "Дополнительные настройки" → "Входящие правила". Дважды щелкните столбец "Имя", чтобы отсортировать по имени. Прокрутите вниз, пока не увидите два правила, называемых "Программа передачи файлов"; на моем компьютере было установлено значение Блокировать (большой красный кружок с линией через него). Дважды щелкните правило. На вкладке Общие в разделе Действие выберите Разрешить подключение. Нажмите кнопку ОК.
