Назад | Перейти на главную страницу

Почему vsftpd (за брандмауэром) возвращает свой внутренний IP-адрес для адреса pasv?

Я использую vsftpd на сервере Debian за другим брандмауэром Debian. Наттинг правильный, и я могу подключиться к ftp серверу извне. Однако, когда клиент выдает PASV , ftp-сервер возвращает свой внутренний IP-адрес (192.168.0.19).

У меня нет pasv_address директива установлена ​​внутри файла conf так, чтобы «адрес был взят из входящего подключенного сокета» (скопирован из руководство). Мне кажется, когда внешний клиент выдает PASV, должен быть возвращен внешний IP-адрес брандмауэра, а при подключении внутреннего клиента должен быть возвращен IP-адрес внутреннего FTP-сервера.

Когда я установил pasv_address директиве внешнего IP-адреса брандмауэра, все работает внешне, но затем он ломается внутри. Когда я либо устанавливаю его на внутренний IP-адрес, либо закомментирую pasv_addressвнутренние клиенты работают, а внешние - нет.

У кого-нибудь есть понимание?

Изменить 1: Вот файл журнала на стороне сервера:

Thu Sep  7 10:36:15 2017 [pid 9093] FTP command: Client "x.x.x.x", "USER yyy"
Thu Sep  7 10:36:15 2017 [pid 9093] [yyy] FTP response: Client "x.x.x.x", "331 Please specify the password."
Thu Sep  7 10:36:15 2017 [pid 9093] [yyy] FTP command: Client "x.x.x.x", "PASS <password>"
Thu Sep  7 10:36:15 2017 [pid 9092] [yyy] OK LOGIN: Client "x.x.x.x"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "230 Login successful."
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "OPTS utf8 on"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "200 Always in UTF8 mode."
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "PWD"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "257 "/""
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "CWD /DownloadProduction/"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "250 Directory successfully changed."
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "TYPE A"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "200 Switching to ASCII mode."
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP command: Client "x.x.x.x", "PASV"
Thu Sep  7 10:36:15 2017 [pid 9094] [yyy] FTP response: Client "x.x.x.x", "227 Entering Passive Mode (192,168,0,19,192,27)."

Изменить 2: Я смог заставить это работать с помощью ProFTPD. Вот случай сбоя сервера для этого: Сервер ProFTPd за межсетевым экраном возвращает внутренний IP-адрес для подключений WAN и LAN

Чтобы заставить это работать с помощью vsfptd, я сделал несколько вещей:

  1. Изменен файл conf для существующей службы vsfptd
    • Слушайте порт 2121
    • Ответить с внешнего IP
  2. Перенаправить порт 21 с брандмауэра на порт 2121 на ftp-сервере
  3. Добавлен второй сервис vsftpd (названный vsftpd-internal)
    • Слушайте порт по умолчанию 21
    • Ответить с внутреннего IP

Это заставляет существующую службу обрабатывать только внешние соединения, а новая служба vsftpd-internal обрабатывает только внутренние соединения.

Изменить, чтобы отобразить параметры конфигурации (запрашивается в комментариях)

Внешний (/etc/vsftpd.conf):

listen_port=2121
pasv_address=x.x.x.x # External IP - port forwarded from FW to this machine

Внутренний (/etc/vsftpd-internal.conf):

# nothing special in this one, mostly default

FTP очень часто вызывает головные уборы, потому что он не выполняет передачу данных по уже установленному управляющему соединению, но требует открытия дополнительного соединения для передачи данных. Первая версия FTP требовала, чтобы сервер открывал это соединение с клиентом - иногда NAT был неизвестен. Чтобы это работало с NAT, был изобретен PASV, чтобы клиент мог открыть это второе соединение. Лучше, но, как вы сами убедились, не оптимально.

На ум приходят три варианта:

  • Вместо этого вы используете sftp - он не страдает от этой проблемы, потому что он, по сути, использует ssh для управления и данных в одном и только одном соединении. Конечно, это другой протокол, поэтому в зависимости от вашей среды это может быть не вариант.
  • Вместо NAT на вашем брандмауэре Debian вы используете какое-то программное обеспечение ftp-прокси, такое как ftp-proxy.
  • Вы настраиваете два сервера vsftp, один из которых прослушивает внутренние соединения на стандартном порту, а другой, скажем, на 2121, для внешнего использования, который настраивает pasv_address на внешний IP-адрес брандмауэра. NAT необходимо адаптировать для преобразования порта 21 в порт 2121.

Если вы находитесь за внешним брандмауэром, входящее соединение фактически исходит от внешнего брандмауэра. Таким образом, IP-адрес сервера - это его внутренний IP-адрес. Вы описываете «правильное» поведение. FTP-сервер не знает (и не может знать) о внешнем IP-адресе брандмауэра.

Что вы можете сделать, так это назначить FTP-серверу два IP-адреса. Один для внешний использовать и один для внутренний использовать. И настройте FTP-сервер так, чтобы он возвращал внешний IP-адрес брандмауэра для подключений на внешний Айпи адрес; и внутренний IP-адрес для подключений на внутренний Айпи адрес.

Хотя я не уверен, позволяет ли vsftpd такую ​​конфигурацию. ProFTPD делает.