Почему 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
Если вы находитесь за внешним брандмауэром, входящее соединение фактически исходит от внешнего брандмауэра. Таким образом, IP-адрес сервера - это его внутренний IP-адрес. Вы описываете «правильное» поведение. FTP-сервер не знает (и не может знать) о внешнем IP-адресе брандмауэра.
Вы можете назначить два IP-адреса FTP-серверу. Один для внешнего использования и один для внутреннего использования. И настройте FTP-сервер так, чтобы он возвращал внешний IP-адрес брандмауэра для подключений на внешний IP-адрес ; и внутренний IP-адрес для соединений на внутреннем IP-адресе .
Хотя я не уверен, позволяет ли vsftpd такую конфигурацию. ProFTPD делает.
FTP очень часто вызывает головной убор, потому что он не выполняет передачу данных по уже установленному управляющему соединению, но требует открытия дополнительного соединения для передачи данных. Первая версия FTP требовала, чтобы сервер открывал это соединение с клиентом - иногда NAT был неизвестен. Чтобы это работало с NAT, был изобретен PASV, чтобы клиент мог открыть это второе соединение. Лучше, но - как вы сами испытали - не оптимально.
На ум приходят три варианта:
- Вместо этого вы используете sftp - он не страдает от этой проблемы, потому что он, по сути, использует ssh для управления и данных в одном и только одно подключение. Конечно, это другой протокол, поэтому в зависимости от вашей среды это может быть не вариант.
- Вместо NAT на вашем брандмауэре Debian вы используете какое-то программное обеспечение ftp-прокси, такое как «ftp-proxy».
- Вы настроили два сервера vsftp, один из которых прослушивает внутренние соединения на стандартном порте, другой, скажем, на 2121, для внешнего использования, который настраивает pasv_address на внешний IP-адрес брандмауэра. NAT необходимо адаптировать для преобразования порта 21 в порт 2121.
Чтобы заставить это работать с помощью vsfptd, я сделал несколько вещей:
- Изменил файл конфи для существующего сервиса vsfptd.
- Слушайте на порту 2121
- Отвечайте внешним IP
- Переадресуйте порт 21 с брандмауэра на порт 2121 на ftp-сервере
- Добавлена вторая служба vsftpd (названная vsftpd-internal).
- Слушайте порт по умолчанию 21
- Отвечайте внутренним IP
Это делает существующую службу обрабатывающей только внешние соединения, а новую службу vsftpd-internal - только внутренние.
Правка, показывающая опции conf (запрашивается в комментариях)
Внешние (/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
В моей лаборатории с двумя интернет-ссылками удалось загрузить файл внутреннего сервера клиенту Windows вне внутренней сети. Тест во внутренней сети тоже работал. Я не знаю, сделал ли я дерьмо! Через много часов это работает! Может кто оценит!!
- БРАНДМАУЭР: => разрешить в 50000:50999/tcp
- МАРШРУТИЗАТОР: => PortForward: 50000:50999/tcp
vsftpd config:
pasv_enable=YES
pasv_addr_resolve=YES
#pasv_address=xxx.xxx.xxx.xxx <=my external Ip
pasv_address=domain.com.br <= my domain
pasv_min_port=50000
pasv_max_port=50999
/etc/hosts:
127.0.0.1 domain.com.br
192.168.1.253 domain.com.br [192.168.1.253] LOCAL IP SERVER
команда загрузки:
wget --no-check-certificate -i -r ftps://user:passwd@domain.com.br:990/files/report.rar