<![CDATA[Linux Forum — Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?id=25617 Fri, 15 Feb 2013 06:05:06 +0000 PunBB <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=327343#p327343 я вобще в линусках не силен.
про rc.local узнал погуглив.
для меня главное что этот способ работает и удовлетворяет моим нуждам. а насколько он православный я не знаю

]]> Fri, 15 Feb 2013 06:05:06 +0000 https://linuxforum.ru/viewtopic.php?pid=327343#p327343 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=327006#p327006 captain_Negri пишет:

допилил автозагрузку с помощью /etc/rc.local

А разве в Центе автозагрузка пилитса скриптами rc.local?

]]> Wed, 13 Feb 2013 09:45:58 +0000 https://linuxforum.ru/viewtopic.php?pid=327006#p327006 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=327005#p327005 допилил автозагрузку с помощью /etc/rc.local

]]> Wed, 13 Feb 2013 09:35:31 +0000 https://linuxforum.ru/viewtopic.php?pid=327005#p327005 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=326989#p326989 так. я нашел в чем косяк был.
у меня после перезапуска iptables выгружался модуль nf_conntrack_ftp. и автоматически обратно не загружался.
значит нужно сделать автозагрузку модуля.
вот описание настройки netfilter. если топикстартер сделает все как там написано то должно заработать (плюс допилить чтобы модуль автоматически загружался каждый раз):

В состав conntrack входят вспомогательные модули (helpers), обеспечивающие отслеживание протоколов прикладного и сеансового уровней: nf_conntrack_ftp, nf_conntrack_irc, nf_conntrack_pptp, nf_conntrack_netbios_ns и т. п. Требуются далеко не для всех протоколов, а только для тех, отслеживание которых требует знания специфики протокола. Например, протокол FTP использует в одном сеансе два соединения (управляющее соединение и соединение передачи данных), и чтобы корректно отследить соединение передачи данных, необходимо анализировать трафик управляющего соединения и выделять в нем информацию, касающуюся открытия соединения данных.

conntrack - основной критерий, используемый для контроля состояния соединения. Он предоставляет эффективный набор инструментов, позволяющий использовать информацию системы conntrack о состоянии соединения. Затронутую тему весьма проблематично осветить в двух словах и привести по ней простые примеры, не выходя за краткий формат, принятый для нашей статьи. Поэтому ограничимся мы подробно рассмотрим лишь наиболее важный параметр данного критерия — ctstate. Для прочих параметров мы лишь кратко опишем синтаксис и назначение. За более подробной информацией обратитесь к документации, прилагаемой к вашему дистрибутиву. Итак,
--ctstate маска

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

Возможные состояния:
NEW — соединение не открыто, то есть пакет является первым в соединении. Полезные примеры использования этого состояния приведены выше, в частности, при описании TCP-специфичных критериев.
ESTABLISHED — пакет относится к уже установленному соединению. Обычно такие пакеты принимаются без дополнительной фильтрации, как и в случае с RELATED.
RELATED — пакет открывает новое соединение, логически связанное с уже установленными, например, открытие канала данных в пассивном режиме FTP.

Например:
--------------------------------------------------------------------------------------------------------------------
modprobe nf_conntrack_ftp # Подгружаем модуль для распознавания связанных FTP-соединений
# В старых системах этот модуль может называться ip_conntrack_ftp
iptables -F # Очищаем все цепочки таблицы filter
# Ко всем пакетам, которые относятся к уже установленным соединениям, применяем терминальное действие ACCEPT — пропустить
iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -m conntrack --ctstate NEW -p tcp --dport 21 -j ACCEPT # Разрешаем открывать соединения на 21 #TCP-порт.
iptables -P INPUT DROP # В качестве действия по умолчанию устанавливаем DROP — блокирование пакета
iptables -P OUTPUT ACCEPT # Разрешаем все исходящие пакеты
# Правила существуют только пока компьютер включён, после перезагрузки правила автоматически сбрасываются и
# очищаются. Чтобы сохранить правила
/sbin/service iptables save # Правила сохранятся в файле /etc/sysconfig/iptables и будут применяться при запуске,
# перезапуске службы или при перезагрузке компьютера.
--------------------------------------------------------------------------------------------------------------------

Этот набор команд обеспечит функционирование на хосте FTP-сервера с поддержкой как активного, так и пассивного режимов. В пассивном режиме FTP клиент сначала устанавливает управляющее соединение на TCP-порт 21 сервера. Когда возникнет необходимость передачи данных, клиент даст серверу команду PASV. Сервер выберет высокий порт и подключится к нему в режиме прослушивания, отправив номер порта клиенту по управляющему соединению. Система conntrack, при наличии подгруженного модуля ядра nf_conntrack_ftp, зафиксирует это сообщение и выделит номер порта. Когда клиент откроет соединение данных на этот высокий порт, система conntrack присвоит первому пакету статус RELATED, в результате чего пакет пройдет по нашему правилу и будет принят. Остальные пакеты в этом соединении будут иметь уже статус ESTABLISHED и тоже будут приняты.

Возможность корректно обрабатывать пассивный режим FTP, как это было описано выше, из всех unix-фаерволов доступна только в iptables. В других фаерволах для решения данной проблемы используются различные «костыли». Например, в pf управляющие FTP-соединения пропускаются через специальную программу ftp-proxy, которая анализирует трафик подобно conntrack и «на лету» добавляет правила для соединений данных. Однако даже подобные «костыли» существуют далеко не для всех протоколов. Поэтому можно утверждать, что в данном аспекте iptables находится вне конкуренции.

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

]]> Wed, 13 Feb 2013 07:55:56 +0000 https://linuxforum.ru/viewtopic.php?pid=326989#p326989 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=326957#p326957 shurik_7866 пишет:

Отключил пасивный режим
pasv_enable=NO

Для вебраузеров изменился текст ошибки и сама ошибка появляется мгновенно, до этого сначала было зависание прибл на 2 мин:

1. через Total Commander и FAR2 захожу как и раньше без проблем
2. Если зоходить через "Мой компьютор" изменился текст ошибки
    Тепер
    "
     В ходе открытия папки на FTP произошла ошибка. Убедитесь что у вас есть разрешения открывать эту папку


    200 Switching to ASCII mode
    Permission denied
    "
   
    ! Как видно из конфигурационного файла "ASCII mode" отключен 

3. Для Internet Expolrer текст ошибки не изменился

4. через Google Chrome - Пишет "Веб-страница недоступна
                                Веб-страница по адресу ftp://alex:12qwaszx@192.168.0.101/, возможно, временно недоступна или постоянно перемещена по новому адресу.
                                Ошибка 601 (net::ERR_FTP_FAILED): Неизвестная ошибка."

5. через Mozilla FireFox -  Выдает ошибку "550 Permission denied"

6. через Opera -  Пишет "Сервер запросил неподдерживаемый метод аутентификации имени пользователя."

у меня абсолютно такая же ошибка, тоже CentOS.
после этого я подумал и мне пришло в голову отключить netfilter (iptables) "service iptables stop". поскольку закрались подозрения насчет него. так и оказалось что дело в неправильно настроенном фаерволе. хотя я настраивал с помощью модуля nf_conntrack_ftp для распознавания связанных ftp-соединений. видимо браузеры и проводник по сравнению с тем же TotalCommander  используют несколько отличающийся набор протоколов и портов.

]]> Wed, 13 Feb 2013 02:10:36 +0000 https://linuxforum.ru/viewtopic.php?pid=326957#p326957 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=321293#p321293 shurik_7866 пишет:

CentOS 5.8, FTP сервер - vsftpd


Из TotalCommander подключаюсь без проблем и под локальным пользователем и под анонимным пользователем. Могу выполнять все необходимые операции - скачивать, закачивать и т.д.

Из Браузера Windows (мой компьютор и далее в адресной строке ввожу ftp://alex:12qwaszx@192.168.0.101) выдает ошибку:


К тому же если вводить просто ftp://192.168.0.101, не появляется диалоговое окно для ввода логина и пароля

Подскажите кто знает, где и чего я не донастроил

И еще такой прикол - под анонимным пользователем файлы выкладывать могу а удалять нет,  под локальным могу как удалять так и выкладывать файлы.

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

В настройках vsftpd вот этих строк уже достаточно для нормального входа:

anonymous_enable=YES
local_enable=YES

А браузер надо другой попробовать, FireFox пример. И нужно писать всё полностью в адресной строке:

ftp://vasia:123@myhost.lan:21/
ftp://vasia:123@myhost.lan:21/TestDir/

ну и тестирование делайте сначала через команду ftp, из терминала.

Ещё для теста можно дать права на папку ftp 0777, чтобы убедиться, что дело не в этом.

]]> Thu, 17 Jan 2013 12:37:56 +0000 https://linuxforum.ru/viewtopic.php?pid=321293#p321293 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=315449#p315449 kisil пишет:

Интересно и в системный лог ничего не сыплетса???
Ну могу посоветовать посмотреть через tcpdump на активность на портах 21 и 20, когда вы подключаетесь из браузера.

Захожу на сервак через мой компьютер
В адресную строку ввожу ftp://alex:12qwaszx@192.168.0.101

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

Но честно говоря мало что понял из прослушки. По моему сервак и клиент обмениваются пакетами пока клиент не получит отказ, и причина отказа в доступе не отображается в прослушке

прослушка по порту 21

# Входящие пакеты
[root@CentOS-58 ~]# tcpdump -i eth1 -vvn tcp src port 21 | strings
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
13:58:34.618256 IP (tos 0x0, ttl  64, id 4134, offset 0, flags [DF], proto: TCP (6), length: 50) 192.168.0.101.ftp > 192.168.0.1.privatechat: P, cksum 0x6e5a (correct), 1618798011:1618798021(10) ack 1999283599 win 5840
13:58:34.618299 IP (tos 0x0, ttl  64, id 4135, offset 0, flags [DF], proto: TCP (6), length: 70) 192.168.0.101.ftp > 192.168.0.1.privatechat: P, cksum 0x9a87 (correct), 10:40(30) ack 1 win 5840
13:58:34.618937 IP (tos 0x0, ttl  64, id 4136, offset 0, flags [DF], proto: TCP (6), length: 64) 192.168.0.101.ftp > 192.168.0.1.privatechat: FP, cksum 0x594c (correct), 40:64(24) ack 1 win 5840
13:59:00.793596 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.0.101.ftp > 192.168.0.1.remote-winsock: S, cksum 0x8993 (correct), 4159784289:4159784289(0) ack 803269851 win 5840 <mss 1460,nop,nop,sackOK>
13:59:00.798362 IP (tos 0x0, ttl  64, id 40846, offset 0, flags [DF], proto: TCP (6), length: 60) 192.168.0.101.ftp > 192.168.0.1.remote-winsock: P, cksum 0x5b2c (correct), 1:21(20) ack 1 win 5840
13:59:00.800935 IP (tos 0x0, ttl  64, id 40847, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.0.101.ftp > 192.168.0.1.remote-winsock: ., cksum 0xb638 (correct), 21:21(0) ack 12 win 5840
13:59:00.801107 IP (tos 0x0, ttl  64, id 40848, offset 0, flags [DF], proto: TCP (6), length: 74) 192.168.0.101.ftp > 192.168.0.1.remote-winsock: P, cksum 0x6eed (correct), 21:55(34) ack 12 win 5840
13:59:00.825791 IP (tos 0x0, ttl  64, id 40849, offset 0, flags [DF], proto: TCP (6), length: 63) 192.168.0.101.ftp > 192.168.0.1.remote-winsock: P, cksum 0xd46f (correct), 55:78(23) ack 27 win 5840
13:59:00.828294 IP (tos 0x0, ttl  64, id 40850, offset 0, flags [DF], proto: TCP (6), length: 66) 192.168.0.101.ftp > 192.168.0.1.remote-winsock: P, cksum 0xf50e (correct), 78:104(26) ack 41 win 5840
13:59:00.830461 IP (tos 0x0, ttl  64, id 40851, offset 0, flags [DF], proto: TCP (6), length: 59) 192.168.0.101.ftp > 192.168.0.1.remote-winsock: P, cksum 0x4e57 (correct), 104:123(19) ack 47 win 5840
14 packets captured
14 packets received by filter
0 packets dropped by kernel

# Исходящие пакеты
[root@CentOS-58 ~]# tcpdump -i eth1 -vvn tcp dst port 21 | strings
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
13:58:34.617994 IP (tos 0x0, ttl 128, id 21055, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.0.1.privatechat > 192.168.0.101.ftp: F, cksum 0xc51e (correct), 1999283598:1999283598(0) ack 1618798011 win 65328
13:58:34.620332 IP (tos 0x0, ttl 128, id 21056, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.0.1.privatechat > 192.168.0.101.ftp: R, cksum 0xc441 (correct), 1:1(0) ack 11 win 0
13:58:34.620624 IP (tos 0x0, ttl 128, id 21057, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.0.1.privatechat > 192.168.0.101.ftp: R, cksum 0xedd9 (correct), 1999283599:1999283599(0) win 0
13:58:34.620635 IP (tos 0x0, ttl 128, id 21058, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.0.1.privatechat > 192.168.0.101.ftp: R, cksum 0xedd9 (correct), 1999283599:1999283599(0) win 0
13:59:00.793540 IP (tos 0x0, ttl 128, id 21061, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.0.1.remote-winsock > 192.168.0.101.ftp: S, cksum 0xddc7 (correct), 803269850:803269850(0) win 65535 <mss 1460,nop,nop,sackOK>
13:59:00.795761 IP (tos 0x0, ttl 128, id 21062, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.0.1.remote-winsock > 192.168.0.101.ftp: ., cksum 0xcd27 (correct), 803269851:803269851(0) ack 4159784290 win 65535
13:59:00.800918 IP (tos 0x0, ttl 128, id 21067, offset 0, flags [DF], proto: TCP (6), length: 51) 192.168.0.1.remote-winsock > 192.168.0.101.ftp: P, cksum 0x239b (correct), 0:11(11) ack 21 win 65515
13:59:00.803172 IP (tos 0x0, ttl 128, id 21072, offset 0, flags [DF], proto: TCP (6), length: 55) 192.168.0.1.remote-winsock > 192.168.0.101.ftp: P, cksum 0x69e5 (correct), 11:26(15) ack 55 win 65481
13:59:00.828161 IP (tos 0x0, ttl 128, id 21075, offset 0, flags [DF], proto: TCP (6), length: 54) 192.168.0.1.remote-winsock > 192.168.0.101.ftp: P, cksum 0x9f9f (correct), 26:40(14) ack 78 win 65458
15 packets captured
15 packets received by filter
0 packets dropped by kernel

# Все пакеты
[root@CentOS-58 ~]# tcpdump -i eth1 -vvn tcp src port 21 or -i eth1 -vvn tcp dst port 21  | strings
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
13:58:34.618118 IP (tos 0x0, ttl 128, id 21055, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.0.1.1735 > 192.168.0.101.21: F, cksum 0xc51e (correct), 1999283598:1999283598(0) ack 1618798011 win 65328
13:58:34.618256 IP (tos 0x0, ttl  64, id 4134, offset 0, flags [DF], proto: TCP (6), length: 50) 192.168.0.101.21 > 192.168.0.1.1735: P, cksum 0x6e5a (correct), 1:11(10) ack 1 win 5840
13:58:34.618299 IP (tos 0x0, ttl  64, id 4135, offset 0, flags [DF], proto: TCP (6), length: 70) 192.168.0.101.21 > 192.168.0.1.1735: P, cksum 0x9a87 (correct), 11:41(30) ack 1 win 5840
13:58:34.618937 IP (tos 0x0, ttl  64, id 4136, offset 0, flags [DF], proto: TCP (6), length: 64) 192.168.0.101.21 > 192.168.0.1.1735: FP, cksum 0x594c (correct), 41:65(24) ack 1 win 5840
13:58:34.620332 IP (tos 0x0, ttl 128, id 21056, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.0.1.1735 > 192.168.0.101.21: R, cksum 0xc441 (correct), 1:1(0) ack 11 win 0
13:58:34.620624 IP (tos 0x0, ttl 128, id 21057, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.0.1.1735 > 192.168.0.101.21: R, cksum 0xedd9 (correct), 1999283599:1999283599(0) win 0
13:58:34.620635 IP (tos 0x0, ttl 128, id 21058, offset 0, flags [none], proto: TCP (6), length: 40) 192.168.0.1.1735 > 192.168.0.101.21: R, cksum 0xedd9 (correct), 1999283599:1999283599(0) win 0
13:59:00.793540 IP (tos 0x0, ttl 128, id 21061, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.0.1.1745 > 192.168.0.101.21: S, cksum 0xddc7 (correct), 803269850:803269850(0) win 65535 <mss 1460,nop,nop,sackOK>
13:59:00.793596 IP (tos 0x0, ttl  64, id 0, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.0.101.21 > 192.168.0.1.1745: S, cksum 0x8993 (correct), 4159784289:4159784289(0) ack 803269851 win 5840 <mss 1460,nop,nop,sackOK>
13:59:00.795761 IP (tos 0x0, ttl 128, id 21062, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.0.1.1745 > 192.168.0.101.21: ., cksum 0xcd27 (correct), 1:1(0) ack 1 win 65535
13:59:00.798362 IP (tos 0x0, ttl  64, id 40846, offset 0, flags [DF], proto: TCP (6), length: 60) 192.168.0.101.21 > 192.168.0.1.1745: P, cksum 0x5b2c (correct), 1:21(20) ack 1 win 5840
13:59:00.800918 IP (tos 0x0, ttl 128, id 21067, offset 0, flags [DF], proto: TCP (6), length: 51) 192.168.0.1.1745 > 192.168.0.101.21: P, cksum 0x239b (correct), 1:12(11) ack 21 win 65515
13:59:00.800935 IP (tos 0x0, ttl  64, id 40847, offset 0, flags [DF], proto: TCP (6), length: 40) 192.168.0.101.21 > 192.168.0.1.1745: ., cksum 0xb638 (correct), 21:21(0) ack 12 win 5840
13:59:00.801107 IP (tos 0x0, ttl  64, id 40848, offset 0, flags [DF], proto: TCP (6), length: 74) 192.168.0.101.21 > 192.168.0.1.1745: P, cksum 0x6eed (correct), 21:55(34) ack 12 win 5840
13:59:00.803172 IP (tos 0x0, ttl 128, id 21072, offset 0, flags [DF], proto: TCP (6), length: 55) 192.168.0.1.1745 > 192.168.0.101.21: P, cksum 0x69e5 (correct), 12:27(15) ack 55 win 65481
13:59:00.825791 IP (tos 0x0, ttl  64, id 40849, offset 0, flags [DF], proto: TCP (6), length: 63) 192.168.0.101.21 > 192.168.0.1.1745: P, cksum 0xd46f (correct), 55:78(23) ack 27 win 5840
13:59:00.828161 IP (tos 0x0, ttl 128, id 21075, offset 0, flags [DF], proto: TCP (6), length: 54) 192.168.0.1.1745 > 192.168.0.101.21: P, cksum 0x9f9f (correct), 27:41(14) ack 78 win 65458
13:59:00.828294 IP (tos 0x0, ttl  64, id 40850, offset 0, flags [DF], proto: TCP (6), length: 66) 192.168.0.101.21 > 192.168.0.1.1745: P, cksum 0xf50e (correct), 78:104(26) ack 41 win 5840
13:59:00.829961 IP (tos 0x0, ttl 128, id 21076, offset 0, flags [DF], proto: TCP (6), length: 46) 192.168.0.1.1745 > 192.168.0.101.21: P, cksum 0xd8f9 (correct), 41:47(6) ack 104 win 65432
13:59:00.830461 IP (tos 0x0, ttl  64, id 40851, offset 0, flags [DF], proto: TCP (6), length: 59) 192.168.0.101.21 > 192.168.0.1.1745: P, cksum 0x4e57 (correct), 104:123(19) ack 47 win 5840
13:59:00.832305 IP (tos 0x0, ttl 128, id 21079, offset 0, flags [DF], proto: TCP (6), length: 51) 192.168.0.1.1745 > 192.168.0.101.21: P, cksum 0xe535 (correct), 47:58(11) ack 123 win 65413
13:59:00.832382 IP (tos 0x0, ttl  64, id 40852, offset 0, flags [DF], proto: TCP (6), length: 62) 192.168.0.101.21 > 192.168.0.1.1745: P, cksum 0xf71c (correct), 123:145(22) ack 58 win 5840
13:59:00.834331 IP (tos 0x0, ttl 128, id 21084, offset 0, flags [DF], proto: TCP (6), length: 45) 192.168.0.1.1745 > 192.168.0.101.21: P, cksum 0x2e7d (correct), 58:63(5) ack 145 win 65391
13:59:00.834449 IP (tos 0x0, ttl  64, id 40853, offset 0, flags [DF], proto: TCP (6), length: 49) 192.168.0.101.21 > 192.168.0.1.1745: P, cksum 0xfde6 (correct), 145:154(9) ack 63 win 5840
13:59:00.847203 IP (tos 0x0, ttl 128, id 21086, offset 0, flags [DF], proto: TCP (6), length: 48) 192.168.0.1.1745 > 192.168.0.101.21: P, cksum 0xfaef (correct), 63:71(8) ack 154 win 65382
13:59:00.847340 IP (tos 0x0, ttl  64, id 40854, offset 0, flags [DF], proto: TCP (6), length: 70) 192.168.0.101.21 > 192.168.0.1.1745: P, cksum 0x2ed8 (correct), 154:184(30) ack 71 win 5840
29 packets captured
29 packets received by filter
0 packets dropped by kernel



Прослушка по порту 20

[root@CentOS-58 ~]# tcpdump -i eth1 -vvn tcp src port 20 or -i eth1 -vvn tcp dst port 20  | strings
tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 96 bytes
0 packets captured
0 packets received by filter
0 packets dropped by kernel

]]> Wed, 19 Dec 2012 12:06:34 +0000 https://linuxforum.ru/viewtopic.php?pid=315449#p315449 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=315200#p315200 shurik_7866 пишет:

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

"Интересно девки пляшут!" (с) Тогда с Вашим серваком точно что-то не так!

]]> Tue, 18 Dec 2012 03:08:25 +0000 https://linuxforum.ru/viewtopic.php?pid=315200#p315200 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=315188#p315188 Интересно и в системный лог ничего не сыплетса???
Ну могу посоветовать посмотреть через tcpdump на активность на портах 21 и 20, когда вы подключаетесь из браузера.

]]> Mon, 17 Dec 2012 19:58:13 +0000 https://linuxforum.ru/viewtopic.php?pid=315188#p315188 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=315187#p315187 kisil пишет:

Ну и неплохо бы какойто лог посмотреть

Установление дериктивы ACCEPT по умолчанию для цепочки INPUT ничего не изменило


в конфигурационный файл добавил - вести системный лог (syslog_enable=YES), для файла /var/log/vsftpd.log дал права на чтение и запись всем, перезагрузил сервак.
Но в этот файл неуспешные и успешные попытки подключения не пишутся, даже после перезагрзки системы остается пустой - поэтому лог показать не могу

]]> Mon, 17 Dec 2012 19:44:18 +0000 https://linuxforum.ru/viewtopic.php?pid=315187#p315187 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=315119#p315119 Ну и неплохо бы какойто лог посмотреть

]]> Mon, 17 Dec 2012 12:16:19 +0000 https://linuxforum.ru/viewtopic.php?pid=315119#p315119 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=315118#p315118 А сделайте в iptables "всё разрешено" и тогда смотрите

shurik_7866 пишет:

-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 64000:65535 -j ACCEPT

Это пока уберите.

]]> Mon, 17 Dec 2012 12:07:01 +0000 https://linuxforum.ru/viewtopic.php?pid=315118#p315118 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=315106#p315106 Отключил пасивный режим
pasv_enable=NO

Для вебраузеров изменился текст ошибки и сама ошибка появляется мгновенно, до этого сначала было зависание прибл на 2 мин:

1. через Total Commander и FAR2 захожу как и раньше без проблем
2. Если зоходить через "Мой компьютор" изменился текст ошибки
    Тепер
    "
     В ходе открытия папки на FTP произошла ошибка. Убедитесь что у вас есть разрешения открывать эту папку


    200 Switching to ASCII mode
    Permission denied
    "
   
    ! Как видно из конфигурационного файла "ASCII mode" отключен 

3. Для Internet Expolrer текст ошибки не изменился

4. через Google Chrome - Пишет "Веб-страница недоступна
                                Веб-страница по адресу ftp://alex:12qwaszx@192.168.0.101/, возможно, временно недоступна или постоянно перемещена по новому адресу.
                                Ошибка 601 (net::ERR_FTP_FAILED): Неизвестная ошибка."

5. через Mozilla FireFox -  Выдает ошибку "550 Permission denied"

6. через Opera -  Пишет "Сервер запросил неподдерживаемый метод аутентификации имени пользователя."



#Настройки NetFilter которые касаются vsftpd
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 20 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 21 -j ACCEPT
-A INPUT -p tcp -m state --state NEW -m tcp --dport 64000:65535 -j ACCEPT

]]> Mon, 17 Dec 2012 10:23:54 +0000 https://linuxforum.ru/viewtopic.php?pid=315106#p315106 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=315077#p315077 Возможно. Я такими настройками не занималса и потому ничего конкретного сказать не могу, но думаю что здесь проблема тока в этих режымах.

]]> Mon, 17 Dec 2012 07:02:00 +0000 https://linuxforum.ru/viewtopic.php?pid=315077#p315077 <![CDATA[Re: Проблема при подключении к FTP из браузера Windows]]> https://linuxforum.ru/viewtopic.php?pid=315070#p315070 kisil пишет:

Может у вас iptables на лиеуксе прикрывает какойто порт, кроме 21. Как я понимаю должен быть открыт ещё и 20.

А может придется открыть вообще диапазон портов.

]]> Mon, 17 Dec 2012 06:51:38 +0000 https://linuxforum.ru/viewtopic.php?pid=315070#p315070