>>P.P.S. Куски скриптов маскарада, транспарент прокси и пр. ботвы в этой же >>конференции навалом - воспользоваться поиском, и все. Но для того, чтоб >>задать правильный вопрос, нужно знать хотя бы половину ответа. >Ну дык посмотрел... >Мне пока что надо связать 2-е сети и Интернет - Я же >не промышленый Сервер держу? >А скрипт выполняется при загрузке и все...(flush -t nat добавлен, что бы >если перезапустил Его, правила скинуть... >Зачем всем всё разрешаю? Ну скажем так - сейчас нет времени долбатся >над какими-то правилами - против взлома и т.д. ... >Я привел этот скрипт - как "база", на которой Я буду строить >более сложную систему защиты - а пока это так как есть... > > >Насчет понимания как пакеты ходят - Я понимаю (надеюсь правильно) что Мне >надо сделать так: >пакет от сети(192.168.100.0) идет на 192.168.100.1, где локальный ИП переписывается(НАТ) на 192.168.129.146, >когда пакет возвращается(ответ), то Он доставляется на 192.168.129.146, где ИП опять >таки перезаписывается на локальный... >Тоже самое и с выходом в Инет... > >А со сквидом? >Пакеты по протоколу TCP/IP идушие на 80 порт перенаправляются на 3128 порт >- в чем тут загвоздка??? > >Вот из того же Киселева: >Таблица nat используется главным образом для преобразования сетевых адресов (Network Address Translation). > >И последняя цепочка в этой таблице -- POSTROUTING, которая используется для преобразования >пакетов перед выдачей их в сеть. > >Поэтому ничего страшного в использовании POSTROUTING для НАТ не вижу... > >Я же говорю Я строю "простые правила"... >Если Я не вижу чего-то, что является чем-то фундоментальным и значимым, то >пожалуйста - пните Меня туда > >>Ответ на него идет от локального сервиса или попадает/не попадает под >правило ESTABLISHED,RELATED, или чтоб попал под это правило, нужно >подгрузить модуль ... >У Меня вопрос - а не глубо ко ли это? Тобишь не >слишком ли усложняется ситуация когда надо лишь 2-а НАТА и 1-н >редирект??? > >в пространстве ядра, в зависимости от типа протокола, пакеты могут иметь несколько >различных состояний. Однако, вне ядра пакеты могут иметь только 4 состояния. >В основном состояние пакета используется критерием --state. Допустимыми являются состояния NEW, >ESTABLISHED, RELATED и INVALID > >Как это Мне может помочь в установке НАТА и Редиректа в данном >случае??? > >ЗЫ: >Если есть какие-то неточности в моем скрипте, то укажите на НИХ... >Ибо прочтение и осмысление "Iptables Tutorial" не наступает сразу же,а Вы так >говорите,как в том же анектоде... >Но самое смешное - поставленые задачи выполняются с помощью этих правил... >Поэтому -Я не вьеду, что именно Вы хотите донести до Меня? Ну вот... Специально не разбираю по пунктам, цитирование полное (не искажаю первоисточник). >Если Я не вижу чего-то, что является чем-то фундоментальным и значимым, то >пожалуйста - пните Меня туда Пожалуйста. Для начала - фундаментальнейшее. >пакет от сети(192.168.100.0) идет на 192.168.100.1, где локальный ИП переписывается(НАТ) на 192.168.129.146, >когда пакет возвращается(ответ), то Он доставляется на 192.168.129.146, где ИП опять >таки перезаписывается на локальный... Уже ошибка. Пакет от сети (192.168.100.0) идет на 192.168.100.1, но там он _не_должен_ переписываться - цепочка postrouting срабатывает при выходе пакета из пЫнгвина!!! а не из локалки, что абсолютно логично следует из диаграммы в Андерссоне. Посему рассуждать о построутинге для входящих пакетов - бред. Далее - при маскарадинге (действие в том же самом postrouting) пакет попадает в модуль netfilter под названием ipt_conntrack (для ядра 2.6.х), выходит наружу, и ответ на него приходит как ESTABLISHED,RELATED, т.е. обратное преобразование nat не нужно и даже вредно - этот модуль все обеспечивает сам (а Вы, любезный сэр, спрашивали не слишком ли это глубоко - про модули). Это ответ на вопрос >В основном состояние пакета используется критерием --state. Допустимыми являются состояния NEW, >ESTABLISHED, RELATED и INVALID > >Как это Мне может помочь в установке НАТА и Редиректа в данном >случае??? Да вот тут и видно отсутствие знаний даже не линукса или фри, а отсутствие знаний протокола tcp/ip, ибо именно по state и метке и происходит возврат ответа на пакет. Пример в предыдущем абзаце. >Поэтому ничего страшного в использовании POSTROUTING для НАТ не вижу... Да и никто не видит - там nat и должен стоять... но он не должен стоять на выходе в локалку - его нужно ставить только там, где требуется приведение к адресу, т.е. на выходном в иной мир интерфейсе. Ботва с перенаправлением на прокси, натом на выходящем в локалку интерфейсе и недогружеными модулями - я описывать не буду, аналогично этому можно нарисовать. >Поэтому -Я не вьеду, что именно Вы хотите донести до Меня? Я хочу доВести, что прописывание правил не понимая их значения - задача дурная. Оно может даже заработать - как-то, в конце-концов, в том анекдоте мужик таки оказался на земле, а не на дереве, но с результатом... Понимать нужно, что пишется, хотя бы ориентировочно. P.S. Я к Вам обращаюсь на Вы, т.к. Вы ко мне так обращаетесь, но вообще-то по старым правилам нетикета в сети обращаются на "Вы", когда в жизни посылают "на..."
|