Я пытаюсь использовать команду "ls" в анонимном сеансе FTP, но когда я набираю команду "ls", я получаю:
Команда 200 PORT выполнена успешно. Подумайте об использовании PASV.
И зависает вот так (нет возврата к приглашению ftp).
Я перезапустил сеанс ftp и вошел в пассивный режим (цитата PASV), но у меня возникает другая проблема: "Нет маршрута к хосту"
Есть ли у вас предложения ?
quote PASV не входит в пассивный режим так, как вы думаете - "PASV" - это немедленная команда (которая предшествует каждой передаче) вместо постоянной команды переключения режимов.
Скорее, клиенту нужно указывать использовать PASV вместо PORT всякий раз, когда требуется ls или передача файла.
Используя inetutils-ftp, используйте passive команду или запустите клиент как pftp или ftp --passive .
Я помню эту проблему однажды, когда я забыл открыть порт 20 в брандмауэре. Хотя порт, обычно связанный с FTP, равен 21, данные обычно отправляются через порт 20.
Убедитесь, что и 20, и 21 открыты как на клиенте, так и на сервере, чтобы любой, кто инициирует соединение через порт 20, мог пройти.
Есть ли у вас предложения ?
Да, канава 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 могут быть более простым маршрутом.
