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 работает без проблем, а у кого-то в пассивном отваливается по тайм-ауту?

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

★

Последнее исправление: kp (всего исправлений: 1)
← Centos 6.3 и rsync
IPSmanager, создание NS записей →

Посмотри выхлоп 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 ★
() автор топика
Вы не можете добавлять комментарии в эту тему: топик перемещен в архив.
← Centos 6.3 и rsync
Admin
IPSmanager, создание NS записей →