Что-то действительно не работает здесь. У меня есть следующая ошибка в использовании 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)
Теперь, проблема (проблемы) я создал:
pasv_enable=YES
pasv_min_port=10000
pasv_max_port=10000
Вторая проблема я создал: Я пытался связать порт 21 на этот раз, но я думаю, что это испортило filezilla.
pasv_enable=YES
pasv_min_port=21
pasv_max_port=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
Мой маршрутизатор (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
В /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
В моем случае наш брандмауэр заблокировал все пассивные порты FTP, когда мы пробовали FTP в активном режиме, это работало. Мы открыли только порт 21 на нашем брандмауэре.
Убедитесь, что это так, измените настройку клиента FTP с transfer mode
на active
и попробуйте подключиться.
Когда наш FTP-клиент находился в режиме automatic
или passive
, он переключался в режим passive
после отправки запроса LIST
, что приводило к разрыву соединения.
Для меня проблема заключалась не в файле конфигурации "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 внутри с «одинаковыми номерами» (= порты).
Шаг 1 - Отключить брандмауэр Windows (необходимо перезапустить)
Шаг 2 - Открыть клиент Filezilla и изменить тип шифрования Файл -> Менеджер сайта -> Шифрование -> Использовать только обычный FTP