FTP-сервер за NAT

[techquisitor]

Давеча разглядывал конфигурационный файл в vsftpd на работе и обратил внимание на строки:

pasv_min_port=49152
pasv_max_port=65534

Выяснилось интересное. Как оказалось, диапазон забит очень неслучайно. Связано с тем, что исключительно майкрософтовские клиенты используют только эти порты для пассивного соединения и никакие другие. Это зашито прямо в спецификациях. Данные значения найдены где-то на технете в процессе поступающих жалоб от виндовых пользователей, сообщавших о невозможности использовать наш ftp для загрузки данных.
Что характерно, остальные клиенты работают без проблем в любых указанных сервером диапазонах вне зависимости от ОС.

Век живи — век учись.

Кстати вопрос к знатному собаководу по микротикам тов. klink0v. Почему может требоваться опция passv_address=белый_ip в конфиге в vsftpd за натом, хотя трансляция адресов должна быть уже в цепочке dstnat? Без этого ftp работать отказывается. В выходные весь мозг чуть не сломал, пока не осенило.

UPD:
В комментах разгадка.

Comments

[gunslinger2.livejournal.com]

Dsnat не транслирует содержимое пакетов, а в пассивном режиме ftp-сервер сообщает не только порт, но и свой адрес. Идиотизм, но факт.

А по поводу диапазона - мать его за ногу, так вот почему фар работает, а виндоговно отказывается! Мля...

[techquisitor.livejournal.com]

Если верно понимаю, мне надо не dstnat использовать в микротике? Просто обычно форвардинг делают везде через него или netmap (http://wiki.mikrotik.com/wiki/Manual:IP/Firewall/NAT#1:1_mapping) ещё, вроде.

[gunslinger2.livejournal.com]

Да не, DNAT вполне валидное решение. Но там нужны еще модули ip_nat_ftp и ip_conntrack_ftp.

[dadv.livejournal.com]

А можно ссылочку на источник? Потому что муть какая-то написана.

При использовании пассивного режима клиент командой PASV просит сервер выбрать порт по своему усмотрению, открыть его и пассивно ждать второго соединения от клиента для передачи данных (файла или листинга каталога), а в ответ на эту команду сервер сообщает клиенту выбранный порт.

Сервер, конечно, выбирает порт из фиксированного диапазона, но фраза "клиенты используют только эти порты" не имеет смысла, потому что клиент при пассивном режиме не выбирает порт, а использует тот, что выбрал сервер и клиенту глубоко фиолетово, какой именно динамический порт сервер выбрал.

[techquisitor.livejournal.com]

Это надо коллегу спрашивать. Но нарыл он именно на технете и сетевик он сам весьма и весьма неплохой. Сомневаться в том, что он говорит не приходится. Но выше вон тоже очевидец. И да, факт есть факт. Пока не пропишешь именно эти диапазоны именно родной MSовский клиент работать не будет. Хоть тресни. Проверено многократно.

Остальным же клиентам пофиг, они работают именно так, как ты описал.

[dadv.livejournal.com]

Боюсь, тут эффект глухого телефона и при пересказе кто-то что-то напутал. Либо спутали пассивный режим с активным, либо забыли упомянуть роль NAT в схеме, либо что-то ещё потерялось при пересказе, потому что в такой формулировке - неправда.

[techquisitor.livejournal.com]

Вот в том-то и дело, что нет. Когда впервые услышал, сам не совсем поверил. Но проблема реально есть. Через NAT виндовый клиент работает только на этих портах. Это абсурд, но вот наблюдали воочию.

Коллега два дня бился тогда над этой проблемой. Я попробую завтра у него ссылку спросить.

[dadv.livejournal.com]

Я не говорил, что проблем с виндовыми FTP-клиентами нет. Я говорил, что утверждение "через NAT виндовый клиент работает только на этих портах" не ложно, а бессмысленно. Порты указаны в конфигурации сервера и это сервер "работает на этих портах", а не клиент. При использовании пассивного режима клиенту безразличны эти серверные порты.

Одна из проблем с виндовыми FTP-клиентами в том, что они по дефолту в зависимости от версии могут использовать наоборот *активный* режим, который плохо совместим с NAT на стороне клиента и/или брандмауэром там же. Точнее, совместим лишь при определенных условиях/настройках на стороне клиента, которые нынешне пользователи настраивать не умеют.

А "FAR работает" как раз потому, что использует пассивный режим вместо активного.

[starcat13.livejournal.com]

Виндовый клиент вообще не умеет же пассивный режим:
например https://stackoverflow.com/questions/18643542/how-to-use-passive-ftp-mode-in-windows-command-prompt

[dadv.livejournal.com]

В топике речь шла не об ftp.exe

[dadv.livejournal.com]

Что касается passv_address=белый_ip, как уже выше отмечено, это требуется в том случае, когда NAT не умеет залезть внутрь пакета управляющего соединения FTP и странслировать внутренний IP сервера ftp во внешний не только в заголовке IP-пакета, но и в теле - когда сочиняли FTP, трансляция адресов IPv4 не была актуальной и, к сожалению, FTP передаёт IP-адреса внутри своих данных в управляющем соединении.

Если же NAT достаточно умён, чтобы править адрес внутри payload, то passv_address в конфигурации ftp-сервера менять не надо.

[techquisitor.livejournal.com]

Значит всё-таки косяк Mikrotik, похоже.

[dadv.livejournal.com]

Вообще, в контексте FTP и винды за натом важность использования портов 49152 и выше реально может быть в следующих случаях:

* винда является FTP-сервером, а не клиентом и тогда да, клиенты в пассивном режиме будут идти к винде на динамические порты такого вида, но это не тот случай, который рассматривается в посте;
* винда является FTP-клиентом и клиент использует активный режим вместо пассивного и сам выбирает порт для передачи данных, но тогда упомянутый в посте серверный конфиг не имеет никакого значения и никак не влияет на успех/неуспех коннекта;
* винда является FTP-клиентом и клиент использует пассивный режим и исходящие коннекты клиента фильтруются брандмауэром с жесткой политикой, разрешающей исходящие коннекты не на произвольные порты, а только на избранные, прописанные в этой политике и в ней разрешены коннекты, в частности, на диапазон 49152 и выше, а на другие ограничены. И вот в этом случае - да, указанный в посте конфиг решает проблему, но суть проблемы тут вовсе не в NAT, а в брандмауэре и если клиенты на реальных адресах и NAT нет, но есть такой пакетный фильтр - проблема будет та же самая и решается так же (как указано в посте). Но почему-то в посте ни слова про пакетный фильтр нет, а это самое главное. Но в этом случае проблема будет у любых FTP-клиентов за таким брандмауэром, хоть MS-овских, хоть нет.

[techquisitor.livejournal.com]

Первые два варианта однозначно отпадают. Вот скорее всего место могла иметь третья ситуация ещё. Вот этот момент реально не исключён, пожалуй.

[techquisitor.livejournal.com]

Коллега почитал тред наш. Говорит, я не ошибся. Именно последний вариант имел место быть. Этот диапазон является стандартным для FTP на базе Windows Server, и он реально прописан в виндовом файрволле. Чтобы не объяснять куче людей как перенастроить стандартный файрволл, проще было перенастроить сервер.

[dadv.livejournal.com]

То есть, фраза из поста "Связано с тем, что исключительно майкрософтовские клиенты используют только эти порты для пассивного соединения и никакие другие" на самом деле не имеет отношения к проблеме, клиент не выбирает "эти порты" (их выбирает сервер) и может использовать любые выбранные сервером порты. И NAT тоже не имеет отношения к проблеме.

[techquisitor.livejournal.com]

Да, безусловно так. :) Псто обновил.

[pan-2.livejournal.com]

>>Этот диапазон является стандартным для FTP на базе Windows Server
Для FTP на IIS.
И вполне есть крутилка в реестре/веб.конфиг для подкручивания диапазона.

[techquisitor.livejournal.com]

На сервере-то да, но вот с клиентами проблема. :) Собственно, по треду выяснилось в чём косяк на самом деле.

[pan-2.livejournal.com]

Странное описание, у винды штатно нет в WF ограничений на исходящие коннекты на любые порты для FTP.
Не говоря уж о стандартном поведении "разрешить все исходящие" для domain/private сетей.
Ну а касаемо Port range - ссылка на Технет может быть, я даже догадываюсь какая, но она не нужна.
Указанный port range относится к dynamic, описанных в RFC:
o the Dynamic Ports, also known as the Private or Ephemeral Ports,
from 49152-65535 (never assigned)
Так что только следование стандартам может быть, а не "опять MS что-то там"