Люди, помогите!!!
В локальной сетке 192.168.0.x надо выделить супер секретную подсетку (скажем 10.0.0.х) и спрятать за файрвол. Чтобы типа эта секретная подсетка была недоступна для людей с шаловливыми рученками из основной сети. Файрвол под линукс с ipchains.
хождение через файрвол на web, почту и т.п. настроил, но не могу решить проблему с доступом к файловому серваку.
Помогите настроить файрвол так, чтобы из секретной сетки можно было залезать на файловый сервак и монтировать расшаренные ресурсы (типа net use disk: \\compname\diskname). Плиииз.
Файрвол под ipchains, но принимаю решения и на iptables :))))
порты 137:139 открыты, на файрволле запустил самбу и она видна в обеих сетках.
Видимо надо правильно настроить форвардинг... тока чето не получается
>Люди, помогите!!!
>В локальной сетке 192.168.0.x надо выделить супер секретную подсетку (скажем 10.0.0.х) и
>спрятать за файрвол. Чтобы типа эта секретная подсетка была недоступна для
>людей с шаловливыми рученками из основной сети. Файрвол под линукс с
>ipchains.
>хождение через файрвол на web, почту и т.п. настроил, но не могу
>решить проблему с доступом к файловому серваку.
>Помогите настроить файрвол так, чтобы из секретной сетки можно было залезать на
>файловый сервак и монтировать расшаренные ресурсы (типа net use disk: \\compname\diskname).
>Плиииз.
>Файрвол под ipchains, но принимаю решения и на iptables :))))
>порты 137:139 открыты, на файрволле запустил самбу и она видна в обеих
>сетках.
>Видимо надо правильно настроить форвардинг... тока чето не получается
Ты знаеш - как в линухе у вас там не знаю )) но в ФриБСД
есть такая штука как ipnat так вот она мапит порты и делает редирект
Посотри у себя - должно такое подобно быть
очень удобно и прикольно получается
правило типа
rdr fxp0 10.10.10.1/32 port 3128 -> 192.168.1.1 port 3128
и т.д.
початай МАН а то синтаксис может ошибочен )
Удачи ...
Samael
\\<ip-address> доступно из второй подсетки?
Если да, тогда разбирайтесь с browsing и nbname. Варианты - WINS, lmhosts. Учитывайте, что w2k ищет доменконтроллер по DNS, а потом уже по nb. см. MSKB по ключевым словам wins, browsing.
>\\<ip-address> из внутренней подсетки не доступно. Пока экспериментирую с одной тачкой, на которой банальная 98-я.
делаю nbtstat -A \\ipaddr и смотрю на tcpdump через внешний интерфейс файрволла. он показывает типа:
10.0.0.79.137 > 192.168.0.77.137: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
192.168.0.77.137 > 10.0.0.79.137: NBT UDP PACKET(137): QUERY; POSITIVE; RESPONCE
вроде через файрвол наружу прошло и вернулся к файрволлу ответ.
но внутрь не проходит.
специально делаю цепочку правил:
# из внутренней сетки наружу:
$IPCHAINS -A input -i $L_INT -p udp -s 10.0.0.79 137 -j ACCEPT
$IPCHAINS -A forward -i $E_INT -p udp -s 10.0.0.79 137 -d 192.168.0.77 137 -j ACCEPT
$IPCHAINS -A output -i $E_INT -p udp -s 10.0.0.79 137 -d 192.168.0.77 137 -j ACCEPT
# снаружи внутрь
$IPCHAINS -A input -i $E_INT -p udp -s 192.168.0.77 137 -d -j ACCEPT
$IPCHAINS -A forward -i $L_INT -p udp -s 192.168.0.77 137 -d 10.0.0.79 137 -j ACCEPT
$IPCHAINS -A output -i $L_INT -p udp -s 192.168.0.77 137 -d 10.0.0.79 137 -j ACCEPT
L_INT - внутренний интерфейс
E_INT - наружный интерфейс
10.0.0.79 - ip внутри файрволла
192.168.0.77 - внешний ipгде тут грабли?
блин, стока раз правила переписывал, что скоро крышак съедет :)
Включите лог отбракованных пакетов в конце каждой таблицы. см. -j LOG.
Также, коль скоро iptables уже есть, посмотрите в сторону -m state --state ESTABLISHED,RELATED - будут попроще правила. Попробуйте переписать правила в iptables (с учетом того, что там форвардный пакет не попадает в input и output). Включите tcpdump на внутрненнем интерфейсе и на внешнем одновременно, и посмотрите логи отфильтрованных пакетов.
Меня вот слово BROADCAST смутило. Придется смотреть на MAC адреса этих пакетов. Если MAC широковещательный (обычно все FF), то такой пакет через маршрутизатор не пройдет.
При чем тут ip broadcast? это относится к протоколу SMB - возможно, это тап узла netbios ответившей машины.
вообще, imho, при диагностике неисправностей идут обычно снизу вверх - сначала добиваются connectivity на уровне железа, потом tcp/ip, потом прикладных протоколов - вот и стоит, на мой взгляд, пройти всю цепочку еще раз и проверить, где мрут пакеты. Чего уже проще - повесить tcpdump на всех возможных интерфейсах и сравнивать различия... :)
надо открывать не только udp, но и tcp