LINUX.ORG.RU
решено ФорумAdmin

Странности в работе FTP

 , ,


1

2

Приветствую.

Имеем XEN VDS (HVM)...

root@server:~# uname -a
Linux server.ru 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:39:51 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Управляется сервер при помощи ISPmanager Light. На сервер по очереди устанавливались proftpd, vsftpd (обозначенная ниже проблема актуальна в обоих случаях). На сервере отключен фаервол (во всяком случае iptables -L не показывает ничего), в конфигах серверов был разрешён пассивный режим.

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

У тех кто не может нормально работать с FTP фаервол отключен точно и ничего соединение не блокирует (с другими FTP серверами в пасивном режиме они работают нормально). В активном режиме, по SFTP всё так же отлично работает у всех. Права и владелец на файлы и каталоги проверен - там всё корректно. Конфиги в случае с proftpd и vsftpd стандартные, критичных изменений не делалось (разве что в процессе поиска решений в гугле, но потом все изменения откатывались назад).

В логах не найдено никаких сообщений, которые могули бы хоть как-то натолкнуть на решение. Только стандартные записи об удачной авторизации.

Вопрос - что это может быть и как вычислить, по каким причинам у кого-то FTP работает без проблем, а у кого-то в пассивном отваливается по тайм-ауту?

Буду благодарен за направление в нужную сторону, потому как у самого идеи уже закончились.


Посмотри выхлоп tcpdump-а с проблемных мест и с нормальных и сравни

Pinkbyte ★★★★★ ()

Что-то мне подсказывает, что проблема отнюдь не на стороне сервера.

leave ★★★★★ ()

FTP клиента под рукой не оказалось, так что попробовали из браузера...

http://pastebin.com/bXAzRPhj - это от туда где есть проблемы с работой ftp. http://pastebin.com/zNptufcE - это от туда где проблем с доступом нет.

Снимался дамп так... 1) запустили tcpdump -i eth0 | grep 217.73.62.140 2) открыли в браузере ftp://217.73.62.140 3) тот у кого всё работает нормально получил список файлов после авторизации 4) тот у кого не работает, не получил ничего. Браузер просто висит на «Соединение с...»

Не знаю на сколько это правильно, но проблему при помощи браузера так же получить удалось.

kp ()

Для пассивного режима нужно, чтобы сервер имел возможность подключиться к клиенту. Если клиент находится за NAT'ом, то этого не получится, если только не прокидывать порты.

UFO-man ()
Ответ на: комментарий от UFO-man

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

anonymous ()
Ответ на: комментарий от anonymous

Да, действительно, извиняюсь. В любом случае, хотелось бы понять, что они друг другу говорят. Можно воспользоваться telnet'ом, если нет клиента.

 $ telnet host 21
UFO-man ()
Ответ на: комментарий от UFO-man

Про NAT

Ситуация с NAT'ом на стороне тех кто не может подключиться рассматривалась, но... Берём только что засетапленный, чистый сервер, который стоит в ДЦ и имеет белый IP, который однозначно не за натом. Заходим на этот сервер и делаем...

# wget --user=user --password='pass' -r ftp://178.63.63.2
--2012-10-15 13:12:33--  ftp://178.63.63.2/
           => `178.63.63.2/.listing'
Устанавливается соединение с 178.63.63.2:21... соединение установлено.
Выполняется вход под именем user ... Выполнен вход в систему!
==> SYST ... готово.  ==> PWD ... готово.
==> TYPE I ... готово.   ==> CWD не нужен.
==> PASV ... готово.  ==> LIST ... готово.

    [  <=>                                                                                                                         ] 4 715       18,2K/s   в 0,3s     

2012-10-15 13:12:33 (18,2 KB/s) - `178.63.63.2/.listing' сохранён [4715]

Удалён `178.63.63.2/.listing'.
--2012-10-15 13:12:33--  ftp://178.63.63.2/.bash_history
           => `178.63.63.2/.bash_history'
==> CWD не требуется.
==> PASV ... готово.  ==> RETR .bash_history ... готово.
Длина: 15438 (15K)

100%[=============================================================================================================================>] 15 438      --.-K/s   в 0,09s    

2012-10-15 13:12:33 (166 KB/s) - `178.63.63.2/.bash_history' сохранён [15438]

Т. е. посути, проверяем и убеждаемся что FTP работает.

Ну и пробуем соединиться с проблемным сервером...

# wget --user=user2 --password='pass' -r ftp://217.73.62.140
--2012-10-15 13:11:39--  ftp://217.73.62.140/
           => `217.73.62.140/.listing'
Устанавливается соединение с 217.73.62.140:21... соединение установлено.
Выполняется вход под именем goroda2 ... Выполнен вход в систему!
==> SYST ... готово.  ==> PWD ... готово.
==> TYPE I ... готово.   ==> CWD не нужен.
==> PASV ... ^C

При попытке перейти в пассив - всё останавливается. Напомню, фаервол был на всякий случай очищен и выключен.

В то же время, коллега, находящийся в другом городе, без проблем запускает у себя wget --user=user2 --password='pass' -r ftp://217.73.62.140 и получает закачку файлов.

kp ()
Ответ на: комментарий от kp

Браузер просто висит на «Соединение с...»

на всякий случай, hosts.allow hosts.deny на сервере что в себе содержат?

aol ★★★★★ ()

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

Вобщем проблемы 2:
1) ident (сервер пытается стукнуться в этот севис клиента, лет как Н по дефолту восновном выключено)
2) backresolve - сервер пытается отбэкрезолвить клиентский IP адрес. Соответственно если клиентский провайдер гомосексуалисты, то корректного обратного бэкрезолва сервер не получит и отвалится по таймауту.

Обе опции как в про так и в вс легко отключаемы - ман.

Jetty ★★★★★ ()
Последнее исправление: Jetty (всего исправлений: 1)
Ответ на: комментарий от Jetty

Спасибо за наводку. В данный момент, на сервере установлен proFTPD. От первой возможной проблемы, если я правильно понял спасает IdentLookups off

По backresolve - мне казалось что UseReverseDNS off будет достаточно что бы этой проблемы избежать. Я не прав в данном случае?

P. S. Текущий конфиг http://pastebin.com/fb2gMmM8

kp ()
Ответ на: комментарий от Jetty

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

Выручай, lor.

kp ()
Ответ на: комментарий от Jetty

И всё равно не понял причём здесь backresolve :) Буду благодарен за пояснение, если не затруднит, конечно.

kp ()
Ответ на: комментарий от kp

На практике с таким сталкивался. Хотя казалось бы зачем он клиенту.

Jetty ★★★★★ ()
6 апреля 2013 г.

Лучше поздно чем никогда.

После создания этой темы прошло достаточно много времени, и вот аналогичная проблема вновь дала о себе знать. На этот раз вопрос оказался решён.

На XEN ноде, в файле /etc/sysconfig/iptables-config ищем (примерно такую) строку:

IPTABLES_MODULES="ipt_REJECT ipt_tos ipt_TOS ipt_LOG ip_conntrack ipt_limit ipt_multiport iptable_filter iptable_mangle ipt_TCPMSS ipt_tcpmss ipt_ttl ipt_length ipt_state iptable_nat ip_nat_ftp ipt_owner ipt_REDIRECT"  

Эти модули нужны для работы с OpenVZ, но не с XEN, так что приводим строку к виду:

IPTABLES_MODULES="ip_conntrack_netbios_ns"  

Сохраняем файл, перезапускаем iptables на ноде, проверяем работу FTP на VDS.

Прошу прощения за некропост. Оставлено для тех, кто может на эту тему наткнуться, например, в поиске.

kp ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.