Попытка подключиться к vsftpd, не удалось получить список каталогов

Что-то здесь действительно не работает. У меня есть следующая ошибка при использовании FileZilla для подключения к удаленной машине, работающей vsftpd:

Command:    LIST
Error:  Connection timed out
Error:  Failed to retrieve directory listing

Я пытаюсь настроить службы FTP на 3 компьютерах за домашним брандмауэром интернет-провайдера. Все они являются Ubuntu 12.04 Server LTS, и я не могу использовать порт 21 извне на удаленном сайте.

Ну, ладно, признаюсь, это ограничение накладывает я сам. Я просто хотел звучать так, будто я работаю в настоящей компании. В любом случае, только 1 из 3 систем могла быть назначена 21, так что это все равно будет проблемой.

Я пробовал решения для добавления строк "pasv _...", но я все еще не могу пройти этап подключения LIST.

• https://stackoverflow.com/questions/4723023/vsftpd-error-listing-directories
• http://www.linuxquestions.org/questions/linux-server-73/vsftpd-error-failed-to-retrieve-directory-listing-878838/
• https://serverfault.com/questions/421161/how-to-configure-vsftpd-to-work-with-passive-mode
• http://www.linuxquestions.org/questions/linux-networking-3/vsftpd-cannot-list-files-but-can-change-dirs-519340/

Итак, если это не удалось, в чем может быть проблема?

На этом сайте я прочитал, что мне нужно переадресовать порты 20 и 21. Сейчас у удаленных сайтов есть порты, такие как 10000, 11000, 12000, которые перенаправляются на внутренний порт 21 в каждой из систем. Должен ли я переслать несколько дополнительных портов на 20? это не имеет смысла, потому что этот порт даже не открыт, vsftpd только слушает 21.

Все, что я хочу, это для успешного соединения ftp через эти перенаправленные порты, я расстроен, потому что я успешно переадресован для таких служб, как SSH, apache2 и т. Д., И я не понимаю, что здесь сломано.

спасибо Джорен за исправление моего форматирования!

РЕДАКТИРОВАТЬ: я возился с моим тестированием VPS, который напрямую подключен к Интернету, я установил vsftpd, просто чтобы посмотреть, что происходит, и вывод 'netstat -tuna' показывает, что успешное соединение с моим клиентом filezilla выглядит так:

tcp        0      0 vps.vps.vps.vps:21       fi.le.zil.la:54288      ESTABLISHED
tcp        0      0 vps.vps.vps.vps:46403    fi.le.zil.la:54289      TIME_WAIT

Примечание: FTP-сервер на моем VPS также сначала не работал из-за совершенно не связанной проблемы, связанной с виртуализированными средами ("500 OOPS: priv_sock_get_cmd"). Читайте: я начинаю видеть, что vsftpd в Ubuntu не работает "из коробки", как apache2 и sshd, для любых разочарованных начинающих системных администраторов, не думайте, что вы глупы, если это не так работает первым делом...

У моего тестируемого VPS нет брандмауэра, поэтому все порты напрямую доступны для доступа демону FTP. После выполнения этого теста я вижу, что возможно, что это вторичное соединение блокируется на удаленном сайте, где у меня возникают проблемы (случайные порты, такие как 46403).

По крайней мере, теперь я подтвердил, что с моим Filezilla нет проблем с NAT, потому что filezilla явно открывает случайные порты и общается с моим VPS.

Единственное, что не имеет смысла, это то, что config 'connect_from_port_20=YES' установлен в моей конфигурации VPS FTP, но я не вижу никаких соединений, используя порт 20!!! Вот почему я даже не знаю, нужно ли перенаправлять этот порт за брандмауэр.

Один из моих недостатков в знаниях - я даже не знаю, что делает порт 20, и я не могу учиться на опыте, потому что я никогда не видел признаков того, что порт когда-либо использовался из-за подключения, загрузки или выгрузки.

Хорошо, я обнаружил некоторые проблемы (явно больше, чем одна вещь не так) - Это связано с переадресацией портов.

Подозреваю оригинальную проблему (перед настройкой vsftpd.conf)

1. Filezilla изначально подключается к удаленному порту 10000, ==> идет на 21 на внутреннем FTP-сервере (хорошо)
2. FTP-сервер открывает случайный порт (НЕ 20), как 45678, но у маршрутизатора, очевидно, нет правила для этого случайно назначенного порта. Он отправляет сообщение о том, что filezilla также подключается к 45678.
3. Клиент Filezilla открывает собственный порт на моем конце за NAT(хорошо)
4. Filezilla отправляет запрос на соединение 45678, но удаленный маршрутизатор не принимает соединение, поскольку для этого порта нет правила переадресации.

Теперь проблема (ы), которые я создал:

pasv_enable=YES
pasv_min_port=10000
pasv_max_port=10000

1. Filezilla подключается к удаленному порту 10000, ==> идет на 21 на внутреннем FTP-сервере (хорошо)
2. FTP-сервер открывает единственный порт, который он может, 10000, [глупый момент], потому что у меня в голове этот порт связан с этой системой. Но 10000 - это фактически аналог стороны WAN для 21 в этой системе. Сервер отправляет сообщение для FileZilla для подключения к 10000 и прослушивает внутренне на 10000
3. Клиент Filezilla открывает свой собственный случайный порт на моем конце (хорошо)
4. Filezilla пробует вторичное соединение на порту 10000, удаленный маршрутизатор снова отклоняет его на порт 21, где его следует игнорировать или потерять, в то время как FTP-сервер ожидает подключения к внутреннему порту 10000, которое никогда не приходит. (потерпеть поражение)

Вторая проблема, которую я создал: я пытался связать порт 21 на этот раз, но я думаю, что испортил filezilla.

pasv_enable=YES
pasv_min_port=21
pasv_max_port=21

1. Filezilla подключается к удаленному порту 10000, ==> идет на 21 на внутреннем FTP-сервере (хорошо)
2. FTP-сервер открывает порт 21 (или, может быть, отказывает, потому что 21 уже используется), если это удалось, он отправил сообщение для filezilla для подключения к порту 21.
3. Клиент Filezilla открывает свой собственный случайный порт на моем конце (хорошо)
4. Filezilla отправляет запрос на LIST на 21, который маршрутизатор не собирается принимать...(ошибка)

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

Я опробую решение и сообщу здесь результаты.

Я думаю, поскольку протокол FTP-сервера сообщает клиенту, к какому порту подключаться, это вторичное соединение ДОЛЖНО иметь тот же номер внешнего порта, что и внутренний.

Я назову это "вторичным соединением", и я думаю, что оно как-то связано с портом 20, что я не понимаю.

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

Новый план:

(примечание: "%" означает, что порт был изменен удаленным маршрутизатором.)

 

сервер № 1
    первичное соединение: 21 <-% -> 10000 
    вторичное соединение 10001 <-----> 10001
    vsftp.conf:
        pasv_min_port = 10001
        pasv_max_port = 10001

сервер № 2
    первичное соединение 21 <-% -> 11000
    вторичное соединение 11001 <-----> 11001
    vsftp.conf:
        pasv_min_port = 11001
        pasv_max_port = 11001

сервер № 3
    первичное соединение 21 <-% -> 12000
    вторичное соединение 12001 <-----> 12001
    vsftp.conf:
        pasv_min_port = 12001
        pasv_max_port = 12001