В настоящее время я пытаюсь настроить VSFTPD на сервере ubuntu 16.04, и я хочу использовать FTPS (в идеале я бы использовал SFTP, но, к сожалению, я ограничен устаревшей системой)
Мне удалось настроить его, используя конфигурацию по умолчанию и без TLS, и я могу нормально подключиться через filezilla. Хотя в течение последних 2 дней я пытался включить TLS, и никакие вопросы по SE или где-либо еще не привели к положительный результат.
Детали моего сертификата в файле vsftpd.conf приведены ниже:
rsa_cert_file=/path/to/fullchain.pem
rsa_private_key_file=/path/to/privkey.pem
allow_anon_ssl=NO
ssl_enable=YES
force_local_data_ssl=YES
force_local_logins_ssl=YES
Однако я больше не могу подключиться к следующему, показанному в консоли filezilla:
Status: Verifying certificate...
Status: TLS connection established.
Status: Server does not support non-ASCII characters.
Status: Logged in
Status: Retrieving directory listing...
Status: Server sent passive reply with unroutable address. Using server address instead.
Command: LIST
Error: Connection timed out after 20 seconds of inactivity
Error: Failed to retrieve directory listing
Это мой первый раз, когда я настраиваю VSFTPD, поэтому я следил за некоторыми учебниками в Интернете. Они также задействовали UFW, и я открыл порты, как показано.
Я также пробовал добавить следующие строки в свой файл vsftpd.conf
ssl_tlsv1=YES
ssl_sslv2=NO
ssl_sslv3=NO
require_ssl_reuse=NO
ssl_ciphers=HIGH
Я видел другие сообщения, в которых упоминалась опция pasv_address
поэтому я попытался добавить это в свою конфигурацию с внешним IP-адресом моего сервера - обратите внимание, что он размещен на Google Compute Engine, и я также обновил свои правила брандмауэра в Compute, чтобы разрешить те же порты и т. д., которые были указаны в руководстве . Это тоже не работает.
Я могу только предположить, что это как-то связано с портами / брандмауэрами или другими параметрами TLS, но я полностью озадачен. Думаю, не помогает то, что у меня есть брандмауэр облачной сети Google, а затем ufw (хотя отключение ufw не имеет никакого эффекта)
Мои правила ufw выглядят следующим образом:
20/tcp ALLOW Anywhere
21/tcp ALLOW Anywhere
990/tcp ALLOW Anywhere
40000:50000/tcp ALLOW Anywhere
и если кто-то хочет узнать больше, то я следил за мной: настройка ftp-доступа
Похоже, что в vsftpd.log нет журналов, которые указывали бы на проблему, но включение подробного ведения журнала в filezilla показывает следующее:
Привязка IP-адреса источника подключения к данным для управления IP-адресом источника подключения 192.168.1.100
что, как я полагаю, может быть проблемой, поскольку он выглядит как локальный IP-адрес. Хотя я не понимаю, как это исправить, особенно потому, что в моем файле vsftpd.conf есть следующее:
pasv_address = (ВНЕШНИЙ IP-адрес GOOGLE COMPUTE)
Правила брандмауэра My Google Cloud:
IP ranges: 0.0.0.0/0
tcp:20-21
Allow
1000
default
pass-ports
sftp
IP ranges: 0.0.0.0/0
tcp:40000-50000
(в конечном итоге они будут заблокированы по IP, но даже при тестировании со всем, что я не могу заставить это работать)
А также в моем файле vsftpd.conf, я считаю, что добавил эти порты как те, которые нужно использовать через:
port_enable=YES
pasv_enable=YES
pasv_min_port=40000
pasv_max_port=41000
Теперь я могу подключиться к нему из самого окна, используя lftp и следующие аргументы
установить ftp: ssl-force true
Я подключаюсь через доменное имя, а не через IP, поскольку сертификат сопоставлен с доменом, поэтому он не будет работать с IP.
Затем я могу создавать новые каталоги и т. Д. Через командную строку. Однако, если я попытаюсь сделать ls я получил ls at 0 [Making data connection...] и он там просто висит. Я также получаю сообщение об ошибке через внешний FTP-клиент, например filezilla. Это просто тайм-аут в LIST команда
Command: LIST
Error: The data connection could not be established: ETIMEDOUT - Connection attempt timed out
Response: 425 Failed to establish connection.
Error: Failed to retrieve directory listing
Error: GnuTLS error -15: An unexpected TLS packet was received.
Status: Disconnected from server: ECONNABORTED - Connection aborted
Единственная другая информация, которая, на мой взгляд, может быть актуальной, - это то, что домен - это порт, перенаправленный NGINX в приложение узла. Но я предполагаю, что это должно делать это только для портов 80 и 443, поэтому не должно влиять на порт 21.
У кого-нибудь есть идеи?