Проверки на дорогах FTP
2781
13
Проблема вот в чем. По совету здешних знатоков организовал я внутреннюю подсеть 192.168.1.х c выходом во внешний мир через gate с реальным IP-адресом (Linux, настроил ipv4, все как положено), изнутри юзеры ходят в инет без проблем, но вот оказалось, что некоторые FTP-серверы "внутренних" не пускают - проверяют какую-то идентификацию и дают отлуп.
Что проверяется и как это лечить? Не претендую на детальные инструкции, посоветуйте ключевые слова и где почитать.
С уважением
Что проверяется и как это лечить? Не претендую на детальные инструкции, посоветуйте ключевые слова и где почитать.
С уважением
Самое оптимальное было бы узнать, что конкретно вам сообщает FTP-сервер, когда дает отлуп. Но обычно проверка идентификации это проверка сочитания имени пользователя + пароль. Большенство FTP серверов настроены на анонимный доступ поэтому проблем с ними обычно нет. Но некоторые сервера требуют персональную идентификацию, и если вы не знаете имени пользователя и пароль, то соответсвенно они вас не пустят.
Спасибо. Сэр!
но беда в том что здесь речь идет именно об анонимном доступе. С соседнего компьбтера (имющего реальный IP) доступ есть, а с внутри-сетевого (162.198...) фиг вам. Я с такой ситуацией раньше уже сталкивался, но давно было, забыл. В понедельник доложу подробнее, в чем суть отлупа.
С уважением
но беда в том что здесь речь идет именно об анонимном доступе. С соседнего компьбтера (имющего реальный IP) доступ есть, а с внутри-сетевого (162.198...) фиг вам. Я с такой ситуацией раньше уже сталкивался, но давно было, забыл. В понедельник доложу подробнее, в чем суть отлупа.
С уважением
Ок.
Тогда еще вопрос: как организован выход в инет? Через NAT или через прокси? Если через прокси, то может быть просто на этих клиентах неверно прописаны его параметры?
Тогда еще вопрос: как организован выход в инет? Через NAT или через прокси? Если через прокси, то может быть просто на этих клиентах неверно прописаны его параметры?
Если всё ходит через NAT, то надо смотреть в сторону настроек iptables. Смотреть надо, пассивный или активный ФТП пользуется. Например, открой порт 113 на вход.. По этому порту происходит авторизация...
очень сильно смущает то, что "_некоторые_ ftp-сервера"... вот, если бы было: "все ftp-сервера не пускают машины с фейковыми адресами", --- то ответ был бы скорее всего таким:
шлюз в интернет маскарадит "внутренних" клиентов, а для того, чтобы фтп работал через маскарад, нужно загрузить модуль, который это поддерживает (скорее всего ip_masq_ftp), или вкомпилить эту поддержку в ядро
шлюз в интернет маскарадит "внутренних" клиентов, а для того, чтобы фтп работал через маскарад, нужно загрузить модуль, который это поддерживает (скорее всего ip_masq_ftp), или вкомпилить эту поддержку в ядро
Угу. Все почти так. Только осталось услышать автора топика и узнать что же он юзает ipchains, iptables или же поднял для этих целей прокси.
Сейчас читают
Что обратило на себя внимание
97520
999
ЖФ в большом городе
28746
198
Носки и борьба с ними
16452
89
Использую ipchains,
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -s 192.168.1.11 -j MASQ
echo 1 > /proc/sys/net/ipv4/ip_forward
FTP-сервер авторизованый, нам дали логин и пароль для входа, и все работает с компов с реальным IP, а при попытке входа из подсети получаем сообщение
425 Can't redirect to third party
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -s 192.168.1.11 -j MASQ
echo 1 > /proc/sys/net/ipv4/ip_forward
FTP-сервер авторизованый, нам дали логин и пароль для входа, и все работает с компов с реальным IP, а при попытке входа из подсети получаем сообщение
425 Can't redirect to third party
/sbin/ipchains -A forward -s 192.168.1.11 -j MASQ
в данном случае у тебя маскарадинг только для адреса 192.168.1.11. Соответсвенно другие внутренние адреса под это правило не попадают.
в данном случае у тебя маскарадинг только для адреса 192.168.1.11. Соответсвенно другие внутренние адреса под это правило не попадают.
>в данном случае у тебя маскарадинг только для адреса 192.168.1.11
А только этому компьютеру из подсети и нужен выход в инет, именно о нем речь. В инет ходит успешно, а с доступом на определенный FTP сервер проблемы.
А только этому компьютеру из подсети и нужен выход в инет, именно о нем речь. В инет ходит успешно, а с доступом на определенный FTP сервер проблемы.
жаль, что не удалось услышать начальника транспортного цеха...
иными словами: про ip-chains,-tables (можно сказать, что это одно и то же, только первое в ядрах 2.2.хх, а второе в 2.4.хх) было отвечено, а про модули?
итак, что выдает команда `lsmod'? есть ли в списке загруженных модулей ip_mask_ftp?
иными словами: про ip-chains,-tables (можно сказать, что это одно и то же, только первое в ядрах 2.2.хх, а второе в 2.4.хх) было отвечено, а про модули?
итак, что выдает команда `lsmod'? есть ли в списке загруженных модулей ip_mask_ftp?
>что выдает команда `lsmod'? есть ли в списке загруженных модулей ip_mask_ftp?
а нету:
Module Size Used by
nfsd 143844 8 (autoclean)
lockd 31176 1 (autoclean) [nfsd]
sunrpc 52964 1 (autoclean) [nfsd lockd]
eepro100 16180 1 (autoclean)
rtl8139 12416 1 (autoclean)
usb-uhci 19052 0 (unused)
usbcore 42088 1 [usb-uhci]
но при этом доступ из внутр.сети к анонимным FTP как я понял, без проблем. И еще. Я не понимаю, при чем тут FTP -казалось бы шлюзовой компьютер просто манипулирует IP пакетами не интересуясь, что там внутри, или я не прав?
а нету:
Module Size Used by
nfsd 143844 8 (autoclean)
lockd 31176 1 (autoclean) [nfsd]
sunrpc 52964 1 (autoclean) [nfsd lockd]
eepro100 16180 1 (autoclean)
rtl8139 12416 1 (autoclean)
usb-uhci 19052 0 (unused)
usbcore 42088 1 [usb-uhci]
но при этом доступ из внутр.сети к анонимным FTP как я понял, без проблем. И еще. Я не понимаю, при чем тут FTP -казалось бы шлюзовой компьютер просто манипулирует IP пакетами не интересуясь, что там внутри, или я не прав?
>но при этом доступ из внутр.сети к анонимным
FTP как я понял, без проблем.
действительно ли без проблем?! а именно: действительно ли доступаются "нутряные" хосты к _внешним_ (!!!) ftp-серверам? если да, то действительно ли они могут скачивать/передавать с них файлы?
загрузи ip_masq_ftp (прошу прощения за ошибку в наименовании модуля в предыдущем ответе) и проверь, вылечилась беда или нет. модуль можно загрузить, например командой `modprobe'.
в первом письме было сказано, что достаточно ключевых слов в ответе, детальных инструкций не требуется, а вот я вижу как раз, что требуются... нет? а также нужно и обоснование :-) дело в том, что фтп для передачи файлов требует два соединения между клиентом и сервером: по одному принимаются/передаются команды, по другому --- данные (причем второе соединение может быть установлено и с каким-нибудь другим клиентом). параметры второго соединения (адрес и порт) передаются по первому "каналу". т.о., чтобы правильно передать файл через шлюз, нужно на шлюзе изменить данные пакета и открыть соединение для приема/передачи файла.
кстати, сервер отвечает: "425 Can't redirect to third party," --- именно из-за того, что (с его точки зрения) клиент (твой шлюз) просит передать данные кому-то другому --- какому-то 192.168.1.11, а этого ему не позволяет сделать его религия. к тому же то, что ты получаешь ответ сервера говорит о том, что соединение-то таки да, установлено :-) файлы только не передаются.
грузи модуль!
ps. вопрос риторический: а ты после установки линух-то проапдейтил? проапдейть, пока добрые люди не поломали тебе его вдребезги и пополам. особенно свои фтп, rpc и сендмэйл. а также позакрывай открытые не необходимые порты для внешнего мира.
pps. удачи
FTP как я понял, без проблем.
действительно ли без проблем?! а именно: действительно ли доступаются "нутряные" хосты к _внешним_ (!!!) ftp-серверам? если да, то действительно ли они могут скачивать/передавать с них файлы?
загрузи ip_masq_ftp (прошу прощения за ошибку в наименовании модуля в предыдущем ответе) и проверь, вылечилась беда или нет. модуль можно загрузить, например командой `modprobe'.
в первом письме было сказано, что достаточно ключевых слов в ответе, детальных инструкций не требуется, а вот я вижу как раз, что требуются... нет? а также нужно и обоснование :-) дело в том, что фтп для передачи файлов требует два соединения между клиентом и сервером: по одному принимаются/передаются команды, по другому --- данные (причем второе соединение может быть установлено и с каким-нибудь другим клиентом). параметры второго соединения (адрес и порт) передаются по первому "каналу". т.о., чтобы правильно передать файл через шлюз, нужно на шлюзе изменить данные пакета и открыть соединение для приема/передачи файла.
кстати, сервер отвечает: "425 Can't redirect to third party," --- именно из-за того, что (с его точки зрения) клиент (твой шлюз) просит передать данные кому-то другому --- какому-то 192.168.1.11, а этого ему не позволяет сделать его религия. к тому же то, что ты получаешь ответ сервера говорит о том, что соединение-то таки да, установлено :-) файлы только не передаются.
грузи модуль!
ps. вопрос риторический: а ты после установки линух-то проапдейтил? проапдейть, пока добрые люди не поломали тебе его вдребезги и пополам. особенно свои фтп, rpc и сендмэйл. а также позакрывай открытые не необходимые порты для внешнего мира.
pps. удачи