Я пытаюсь использовать команду «ls» в анонимном сеансе FTP, но при вводе команды «ls» получаю:
200 Команда PORT выполнена успешно. Рассмотрите возможность использования PASV.
И он зависает вот так (нет возврата к приглашению FTP).
Я перезапустил сеанс ftp и вошел в пассивный режим (цитирую PASV), но у меня возникла другая проблема: «Нет маршрута к хосту».
Есть ли у вас предложения ?
решение1
quote PASV не делаетвойти в пассивный режим так, как вы думаете – «PASV» – это немедленная команда (которая предшествует каждой передаче), а не постоянная команда переключения режима.
Скорее,клиентнеобходимо указать использовать PASV вместо PORT всякий раз ls, когда запрашивается передача файла.
Сinetutils-ftp, использоватьpassiveкоманду или запустите клиент как pftpили ftp --passive.
решение2
Помню, как однажды я столкнулся с этой проблемой, когда забыл открыть порт 20 в брандмауэре. Хотя порт, обычно связанный с FTP, — 21, данные обычно отправляются через порт 20.
Убедитесь, что порты 20 и 21 открыты как на клиенте, так и на сервере, чтобы любой, кто инициирует соединение через порт 20, мог пройти.
решение3
Есть ли у вас предложения ?
Да, откажитесь от FTP.
Я знаю, что это, возможно, не тот ответ, который вы хотели услышать, но позвольте мне объяснить, почему это действительно необходимо, и тогда вы, возможно, будете более склонны сделать это. Я также дам вам еще одну альтернативу.
FTP был написан, когда Интернет считался экспериментальным проектом. Крупные университеты и крупные организации имели правила поведения, которые соблюдались уважаемыми институтами, и поэтому люди в Интернете (тогда он назывался ARPAnet) пользовались доверием.
FTP был разработан для того, чтобы клиент использовал TCP-соединение для отправки запроса на файл. Затем сервер получал запрос и инициировал отдельное TCP-соединение с клиентом.
Это сломалось, когда клиенты начали использовать брандмауэры для защиты своих данных. Так что FTP-клиенты могли устанавливать исходящие соединения, но входящие соединения блокировались.
Обойти это можно было с помощью пассивного режима: клиент отправляет запрос, используя TCP-порт 21, затем сервер сообщает, что хочет установить другое соединение, используя случайный TCP-порт (например, 43728), а затем клиент устанавливает второе соединение, используя указанный случайный TCP-порт (например, 43728).
Это работало, если у клиента был брандмауэр. Многие начали узнавать, что "пассивный режим" исправлял проблемы FTP. Однако на самом деле "пассивный режим" исправлял только эту конкретную проблему. Если на сервере есть брандмауэр, который разрешает входящий трафик только на определенных портах, например, порт 21 для FTP, то даже "пассивный режим" не исправляет все, что требуется для работы.
Теоретически это можно исправить, если брандмауэр FTP-сервера поддерживает FTP-прокси, который отслеживает трафик и открывает другой порт при необходимости. Многие считают, что это немного сложно настроить.
Поскольку все больше организаций стали больше заботиться о безопасности и меньше о FTP, люди начали узнавать, что FTP становится все более нестабильным (это означает, что все больше и больше FTP-серверов становилось сложными для использования из все большего и большего количества мест, где люди могли попытаться использовать FTP-клиент). Проблемы с FTP начали становиться все более распространенными.
Некоторое время люди знали, что «пассивный режим» был волшебной «панацеей», которая исправляла проблемы FTP. (Многие не понимали, почему FTP перестал работать. Они просто узнали, что если FTP начинал вести себя странно, «пассивный режим», похоже, исправлял эту странную проблему, с которой сталкивался FTP. Позже вера в то, что «пассивный режим» был волшебной «панацеей», была повсеместно заменена другим убеждением, которое заключалось в том, что FTP, похоже, больше не работает (и близко не так хорошо, как раньше). Даже если многие люди не понимали, почему FTP сломался, они понимали, что жизнь, похоже, работала более успешно, когда они пробовали другую технику, которая заключалась в том, чтобы просто начать использовать другие протоколы. По мере того, как загрузка по HTTPS стала становиться все более популярной, люди просто перестали использовать FTP почти так же часто.
Поэтому лучшим решением будет просто отказаться от старого протокола FTP, который не работает с современными мерами безопасности в Интернете. FTP просто не был разработан для этого. NAT также используется для того, чтобы помочь нескольким устройствам использовать один IP-адрес.
NAT часто реализуется брандмауэром, хотя он может иметь и другие цели, помимо безопасности (например, увеличение количества поддерживаемых устройств). Какова бы ни была цель использования NAT, конечный результат заключается в том, что NAT по сути разрывает соединение FTP по тем же причинам (не позволяя соединению достичь нужного устройства). Таким образом, FTP также не был разработан для поддержки NAT.
В свое время FTP был всего лишь экспериментальной попыткой заставить работать передачу файлов. FTP достиг своей изначальной цели. Поэтому, несмотря на то, что он не очень хорошо работал с сегодняшним дизайном Интернета, FTP не был на самом деле плохо спроектирован. Его дизайн действительно имел большой успех в то время. Он был просто разработан для другого стиля Интернета, нежели тот, который использует сегодняшние распространенные технологии.
У HTTP не так много проблем, поскольку он использует одно TCP-соединение вместо нескольких. Как и у многих безопасных альтернатив: HTTPS, SFTP, FTPS, SCP.
Я обещал другую альтернативу. Это: заставить FTP работать. Стратегии включают: * Заставить ваш клиентский брандмауэр запустить FTP-прокси * Заставить брандмауэр FTP-сервера запустить FTP-прокси
Проблема в том, что вы часто не можете контролировать одну сторону соединения. Так что один из них может быть неподходящим для вас вариантом.
Вы можете попробовать просто удалить свой брандмауэр вообще. Однако это, скорее всего, приведет к рискам безопасности, которые большинство людей считает НЕ приносящими пользы. Вместо этого просто откажитесь от идеи использования старого протокола FTP, который не очень хорошо работает с современным Интернетом, и получите современное программное обеспечение для передачи файлов через HTTPS или FTPS (или SCP). Обычно оно лучше работает с брандмауэрами, лучше работает с NAT и дает вам преимущества конфиденциальности. (Вы ведь не хотели передавать свой пароль в незашифрованном виде через Интернет, не так ли?)
Если только вы не пытаетесь получить общедоступные файлы, в этом случае HTTPS или HTTP могут оказаться более простым путем.