FTP клиент с 1024 портом не может подключиться к серверу

netstat -tuln | grep :1024 нет вывода

Если это вывод непосредственно с сервера - значит, порт 1024 никто не слушает.

конфиг pure-ftpd в области настроек прослушиваемых портов ??

Да, 1024 никто не слушает. Это порт клиента.
FTP сервер слушает 21 порт. Посмотрите на запрос SYNC

123.45.67.88.1024 > 152.34.78.99.21: Flags [S], cksum 0x021e (correct), seq 128001, win 5840, options [mss 536], length 0
152.34.78.99.21 > 123.45.67.88.177.1024: Flags [S.], cksum 0x8adb (incorrect -> 0x0f04), seq 2904120882, ack 128002, win 64240, options [mss 1460], length 0

Клиент с IP 123.45.67.88 и исходящим портом 1024 подключается к серверу 152.34.78.99 на порт 21. Это лог со старого (работающего) сервера. На новом сервере SYNC запросы от клиентов с портом 1024 не отображаются в tcpdump. Я не вижу их в логах. Если поставить у клиента порт 1025, то все норм. SYNC есть.
VPS провайдер утверждает что он не блокирует никакие порты.

Запускаю так:

pure-ftpd-postgresql -l pgsql:/etc/pure-ftpd/db/postgresql.conf -l pam -O clf:/var/log/pure-ftpd/transfer.log -J HIGH -u 1000 -E -B -p 10000:11000 -A```

Извините, не заметил Ваше цитирование. Эту команду привел в пример, что никто на сервере не занимает этот порт.

почитай здесь, может, это решит твою проблему: https://superuser.com/questions/1251224/what-kernel-modules-are-required-for-...

там про настройки iptables и conntrack для FTP.

Отключи ufw на новом сервере и проверь сможет ли проблемный клиент может к нему подключиться.
Напоминаю, что в ftp для получения/передачи данных требуется 2 tcp соединения и возможно проблема как раз со вторым соединением.
Запусти tcpdump на старом сервере и сравни подключение старого и нового клиента.
Трафик лучше всего сохранить («tcpdump -nvi any -s0 -w file.pcap tcp and port 21»), а потом его уже анализировать (например при помощи chaosreader).

Полагаю что дело не в ufw и pure-ftp. Смотрите. На старом сервере (рабочем) я закрыл pure-ftp. В ufw порт 21 разрешен. tcpdump следит за 21 портом.

На домашнем ПК запустил hping3. Ответы приходят. flag=RA. Все норм.

sudo hping3 -S -p 21 -s 1024 -k OLD_SERVER_IP
HPING OLD_SERVER_IP (enp5s0f0 OLD_SERVER_IP): S set, 40 headers + 0 data bytes
len=46 ip=OLD_SERVER_IP ttl=51 DF id=0 sport=21 flags=RA seq=0 win=0 rtt=35.9 ms
DUP! len=46 ip=OLD_SERVER_IP ttl=51 DF id=0 sport=21 flags=RA seq=0 win=0 rtt=1039.8 ms

В это время на сервере tcpdump выдает лог

sudo tcpdump port 21
17:44:51.433582 IP MY_PC_IP.1024 > OLD_SERVER_IP.ftp: Flags [S], seq 1753722940, win 512, length 0
17:44:51.433734 IP OLD_SERVER_IP.ftp > MY_PC_IP.1024: Flags [R.], seq 0, ack 1753722941, win 0, length 0
17:44:52.433727 IP MY_PC_IP.1024 > OLD_SERVER_IP.ftp: Flags [S], seq 2074744841, win 512, length 0
17:44:52.433801 IP OLD_SERVER_IP.ftp > MY_PC_IP.1024: Flags [R.], seq 0, ack 321021902, win 0, length 0

Далее. Если в ufw добавить правило блокирующее 21 порт, то произойдет следующее. На домашнем ПК ответов не будет

sudo hping3 -S -p 21 -s 1024 -k OLD_SERVER_IP
здесь ничего не происходит

На сервере tcpdump печатает лог

17:45:52.385519 IP MY_PC_IP.1024 > OLD_SERVER_IP.ftp: Flags [S], seq 1463070252, win 512, length 0
17:45:53.385567 IP MY_PC_IP.1024 > OLD_SERVER_IP.ftp: Flags [S], seq 2140791741, win 512, length 0

Считаю это нормальным поведением.

Теперь новый сервер. При любом состоянии ufw и pure-ftp, tcpdump не печатает запросы, если у подключающегося клиента исходящий порт <= 1024. pure-ftp и второе tcp подключение вообще никак не влияет. Можно для тестов взять не 21 порт, а 80. Все тоже самое. До сервера не доходит даже TCP SYNC.

Еще заметил, если на новом сервере (неисправном) запустить пинг старого сервера (исправного): sudo hping3 -S -p 21 -s 1024 -k OLD_SERVER_IP, то ответов нет. На старом сервере tcpdump ничего не выводит.

Если на новом запустить сервер: python3 -m http.server 1024, то внешние клиенты успешно подключаются к 1024 порту, но только если у них исходящий порт >1025.

В каких логах, помимо tcpdump, можно увидеть где могут теряться запросы?

Подскажите, может ли что-то в Линукс фильтровать трафик до tcpdump?

Старый сервер - выделенный, новый - VPS. Можно ли как-то проверить что проблема не на стороне провайдера?

Повторюсь, если для всех этих тестов использовать исходящий порт >= 1025, то никаких проблем нет. Но мне нужен именно 1024 из-за старого оборудования.

Спасибо. Информация полезная, но не мой случай. С большей частью клиентов сервер отлично работает в пассивном режиме.

ну, может, там для каких-то портов прописаны правила, а для некоторых нет. мало ли.

А что на интерфейсе сервера или клиента не растет случаем количество ошибок во время попыток подключения?

cat /proc/net/dev

Inter-|   Receive                                                |  Transmit
 face |bytes    packets errs drop fifo frame compressed multicast|bytes    packets errs drop fifo colls carrier compressed
    lo: 21672339361 36421030    0    0    0     0          0         0 21672339361 36421030    0    0    0     0       0          0
  eth0: 48971336963 5881749    0    0    0     0          0         0 980261709 4166384    0    0    0     0       0          0

На сервере и клиенте errs и drop ==0

Нет пакетов в tcpdump, значит их нет на интерфейсе, значит их фильтрует провайдер. Всё, что тут про ufw и pure-ftp написано --просто лишнее.

Спасибо. Буду знать про tcpdump.

Я уже направлял запрос провайдеру, он сказал что с его стороны нет никаких блокировок. Попробую еще раз.

у некоторых хостингов есть внешний фаервол. Открытие портов настраивается через панель управления vps, а не через ufw/iptables.

Посмотрю внимательнее что там есть. Спасибо.

Проблема на стороне провайдера. Он, в целях безопасности, фильтрует весь трафик с source port =< 1024 и сделать с этим ничего нельзя. Всем спасибо.

Объясни провайдеру что фильтровать надо <=1023, а 1024 это уже общепринято юзерский порт. Они просто опечатались скорее всего.

Провайдер GoDaddy. Не знаю чем они руководствовались. Временным решением является промежуточный FTP сервер, который пускает клиентов с 1024 портом и пересылает файлы на проблемный сервер. Я тут подумал, а существует ли FTP прокси?

Провайдер GoDaddy.

Вот это и надо было указать сразу в первом сообщении. Не самый лучший провайдер.

какая дичь. никогда не догадаешься, какие фантазии бывают у провайдеров.

а они об этом предупреждают юзеров, когда предлагают свои услуги?

Обычно нет. Многие из провайдеров, перекрывающие порты, не только не предупреждают пользователей, но и при обращении к ним первый делом играют в несознанку, типа «мы ничего не перекрываем». Иногда быстрее на форумах найти ответ, что этот провайдер фильрует, чем от провайдера добиться признания.

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

мне это нужно было для разделения случаев вероятного вмешательства провайдера от хаотичного вредительства роскомпозора.

а то бывает бьёшься с настройками сети, а она не работает по независящим от тебя внешним причинам.

Ну, это вам ещё повезло. В какой-то момент ведь был домру и свежекупленые им конвекс и акадо(олимпус). И был бардак с переделкой/перенастройкой, что они сами не знали, что фильтруют и зачем.

Ну и нормальная первая линия не даст связи с админом :) Вон Дмитрий Бачило ролик на Ютуб выкладывал и только после этого что-то решилось.

вот я из конвекса туда и попала. а за несколько лет до этого конвекс скупил того провайдера, у которого я изначально регистрировала сеточку. так что в домру я попала ну вообще не по своей воле. и более дебильного сервиса пока не встречала.

Именно так все и было. Первое обращение к провайдеру закончилось примерно таким сообщением: «Мы ничего не блокируем, все порты открыты. Если вам нужна помощь в настройке вашего сервера, переходите на соответствующий тарифный план (с соответствующей арендной платой). После этого наши инженеры посмотрят что там у вас с 1024 портом.»

Были некоторые сомнения, что проблема на стороне провайдера, так как про блокировку 1024 порта не было информации ни на форумах, ни во всяких FAQ от GoDaddy.

Оборудованию уже лет 20. Сменился не первый сервер. Впервые узнали что у некоторых модемов фиксированный 1024 порт и что с ним может быть проблема.

Не лучше ли просто провайдера сменить, если он упёрто некорректные конфиги файрволла навязывает?

Ну или всё-таки попытаться их вразумить перед этим, несмотря на то что это крупная компания.

Надо ещё подумать, что проще: снова переезжать или мириться с костылём в виде промежуточного FTP-сервера. В остальном проблем нет.