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

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

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

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

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

Я попробовал решения за добавление "pasv_..." строки, но я все еще не могу закончить этап СПИСКА соединения.

Так, приведя это к сбою, какова проблема могла бы быть?

Я читал на этом сайте, в котором я нуждаюсь к портам передачи 20 и 21. Прямо сейчас удаленные сайты имеют порты как 10 000, 11000, 12 000 переданных к внутреннему порту 21 в каждой из систем. Я должен передать некоторые дополнительные порты в 20? это не имеет смысла, потому что тот порт даже не открыт, vsftpd только слушает на 21.

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

благодарен за то, что Joren исправляет мое форматирование!


Править: Я бездельничал со своим тестированием VPS, который непосредственно выставляется Интернету, я установил vsftpd только для наблюдения то, что происходит, и вывод 'netstat - тунец' показывает, что успешное соединение от моего 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 не работает, 'out-of-the-box' как apache2 и sshd, для любых расстроенных системных администраторов новичка там, делают не, думают, что Вы глупы, если он не работает первая вещь...

Мой VPS тестирования не имеет брандмауэра, таким образом, все порты непосредственно доступны для доступа демоном FTP. После запущения этого теста я вижу, что возможно, что это вторичное соединение блокируется на удаленном сайте, где у меня есть проблемы (случайные порты такой как 46 403).

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

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

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


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

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

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

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

pasv_enable=YES
pasv_min_port=10000
pasv_max_port=10000
  1. Подключения Filezilla к удаленному порту 10000, ==> переходит в 21 на внутреннем FTP-сервере (хорошо)
  2. FTP-сервер открывает единственный порт, он может, 10000, [глупый момент], потому что у меня есть тот порт в моей голове, связанной с той системой. Но 10000 на самом деле дубликат стороны WAN для 21 в этой системе. Сервер отправляет сообщение за FileZilla для соединения с 10 000 и слушает внутренне на 10 000
  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 отправляет запрос для СПИСКА к 21, который маршрутизатор не собирается принимать... (перестали работать)

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


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

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

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

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

Новый план:

(примечание: '%' предназначен для показа порта, изменяемого удаленным маршрутизатором.)

 

server #1
    primary connection: 21 <--%--> 10000 
    secondary connection 10001 <-----> 10001
    vsftp.conf:
        pasv_min_port=10001
        pasv_max_port=10001

server #2
    primary connection 21 <--%--> 11000
    secondary connection 11001 <-----> 11001
    vsftp.conf:
        pasv_min_port=11001
        pasv_max_port=11001

server #3
    primary connection 21 <--%--> 12000
    secondary connection 12001 <-----> 12001
    vsftp.conf:
        pasv_min_port=12001
        pasv_max_port=12001
5
задан 23 May 2017 в 15:39

5 ответов

Мой маршрутизатор (fritz.box, Германия) должен был быть настроен, разблокировав более высокие порты в том же wa, исходящем как вступление! (выше: это "pasv_min.. и... макс." здесь вставил/предписал debian-vsftpd):

Добавление диапазона разблокированных портов в Неисправности! Маршрутизатор поля с соответствующей кнопкой:
"Другие Приложения"-> "Portokoll": TCP, von Port: 13450, еще раз Port: 13500 (или высокие порты в диапазоне ~50), "Компьютер": RasPi, "IP_Adresse": (outgreyed, внутренний АДРЕС IP LAN для моего "RasPi", данного fritz.box-маршрутизатором)-> и здесь это прибывает: "Порт" (=the тот же диапазон!): 13450, "еще раз Port": 13450, и это хорошо работает с vsftpd и FTPS (AUTH TLS / SSL-Tranfer с OpenSSL + сильный DES-CBC3-SHA шифр)...

Это передаст правильные порты и соединит запросы с и на мой небольшой "Сервер" RasPi-(позади F.B.-NAT) к incomig/outgoing внешнему запросу IP НА ТОМ ЖЕ ДИАПАЗОНЕ ВЫСОКИХ (ER) - ПОРТЫ, как соединенные с правом "кабели" к тем же портам на внутренней детали...

Возможный vsftp-файл-конфигурации "/etc/vsftpd.conf":

listen=YES
anonymous_enable=NO
local_enable=YES
write_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
force_dot_files=YES

ssl_enable=YES
force_local_data_ssl=NO
force_local_logins_ssl=NO
allow_anon_ssl=NO
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
# rsa_cert_file=/etc/ssl/private/vsftpd.pem   # not working alright, so single-lined:
rsa_cert_file=/etc/ssl/private/vsftpd.crt
rsa_private_key_file=/etc/ssl/private/vsftpd.key

pasv_enable=YES
# pasv_promiscuous=YES
# port_promiscuous=YES
pasv_addr_resolve=YES
pasv_address=[yourDNSadress.no-ip.com] # for Dynamic-DNS the routers daily changing IP.
# port_enable=YES
pasv_min_port=13450
pasv_max_port=13500
file_open_mode=0755
2
ответ дан 23 May 2017 в 15:39

В /etc/vsftpd.conf вы должны предоставить диапазон портов, по крайней мере, 2 или 3, с настройками pasv_min_port и pasv_max_port.

Когда вы подключаетесь к vsftpd в пассивном режиме с клиентом FileZilla, vsftpd ответит подключением к данным на другом случайно выбранном порту в диапазоне, заданном pasv_min_port и pasv_max_port. Если вы пытаетесь сделать все на одном порту, это, вероятно, вызовет проблемы.

Если вы работаете с портом 12001, попробуйте:
pasv_min_port = 12001
pasv_max_port = 12005

0
ответ дан 23 May 2017 в 15:39

В моем случае наш брандмауэр заблокировал все пассивные порты FTP, когда мы пробовали FTP в активном режиме, это работало. Мы открыли только порт 21 на нашем брандмауэре.

Убедитесь, что это так, измените настройку клиента FTP с transfer mode на active и попробуйте подключиться.

Когда наш FTP-клиент находился в режиме automatic или passive, он переключался в режим passive после отправки запроса LIST, что приводило к разрыву соединения.

0
ответ дан 23 May 2017 в 15:39

Для меня проблема заключалась не в файле конфигурации "vsftpd.conf" на FTP- (мини) сервере Raspberry-Pi (с его программным обеспечением: vsftpd), а в ПО МОЕМ доме-маршрутизаторе с его брандмауэром, который не пропускал через «сигналы», сообщая мне о моей программе Windows FTPS (я не использую Filezilla, но CoreFTP) -> «192,168,178,21,71,27 -> 500 Команда недопустимого PORT». Таким образом, освобождая вручную на МОЕМ МАРШРУТИЗАТОРЕ не только «Порт 21», но и относительно более высокий диапазон разблокировки порта (здесь только для примера, цифры могут быть также намного выше диапазона, например 35000, 40000 или даже больше). .) пропустить входящие / исходящие сигналы через один из этих портов, случайно выбранных из программного обеспечения, через внутренний брандмауэр маршрутизатора , (мой RasPi «отстает» от них в моей локальной сети!), как показано ниже (на маршрутизаторе):

Active  Description  Protocol  Port          an Computer(RasPi)  an Port
(OK)    FTPS-Server  TCP       13450-13500   192.168.178.120     13450-13500

Таким образом, оба порта: Nonigig и Outbound-порты на ROUTER теперь одинаковые (высокочастотные), как кабели, соединяющие ROUTER внутри с «одинаковыми номерами» (= порты).

0
ответ дан 23 May 2017 в 15:39

Шаг 1 - Отключить брандмауэр Windows (необходимо перезапустить)

Шаг 2 - Открыть клиент Filezilla и изменить тип шифрования Файл -> Менеджер сайта -> Шифрование -> Использовать только обычный FTP

0
ответ дан 23 May 2017 в 15:39

Другие вопросы по тегам:

Похожие вопросы: