ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Aleksey Barabanov                    2:5020/400     11 Sep 2001  00:29:51
 To : Al Zaharov
 Subject : Re: Masquerading
 -------------------------------------------------------------------------------- 
 

 Al Zaharov писал(а):
 
 > 
 > Aleksey Barabanov <alekseybb@mtu-net.ru> wrote:
 > > "Снижение нагрузки на файрвол" это очень интересная тема. Меня например
 > > очень занимает вопрос насколько сильно файрвол тормозит. А если он еще и
 > > правил несет так под пол-К ? Увы ничего об этом не знаю. Хотя, судя по
 > сам не видел, но общался с неким германцем, который пользует для обсчета
 > трафика окола 300 пользователей в трех С сетках именно ipchains (суть
 > все-равно одна - что iptables, что ipchains) в итоге получает около 2000
 
 Я с таким столкнулся. Объем правил растет как цунами.
 
 > правил, с его слов, данная конструкция жестоко тормозит.. но при
 
 Вот это существенное замечание. Если бы еще добавть кроме качественных и
 количественные показатели.
 
 > применении иерархической системы для построенияя правил, все становится
 
 Очень помогает иерархия по устройствам.
 
 > очень даже неплохо - все пользователь ходят наружу и проблем нет, канал
 > наружу - 100 мбит.. (хотя все это довольно суб[ективно)..
 
 So, so.
 Хотя, ключевое слово ipchains. Думаю если все это перевести на iptables,
 то тормоза станут не в пример ощутимее. И, видимо, с подсчетом трафика
 через счетчики цепочек придется завязывать. Hе ясно правда как
 реализоввывать квотирование трафика при кредитном способе оплаты услуг
 ISP, imho, без блокирующих/разрешающих цепочек на каждого клиента (или
 на каждый адрес) не обойтись.
 
 > 
 > > тексту и по структуре, netfilter построен более тормозно чем ipchains.
 > > Поскольку в нем можно организовывать очень длинную цепочку проверок
 > > опций одного пакета ( -m и т.д. ).
 > но ведь можно и не организовывать.. :)
 
 ;)
 Сам способ построения принятый для возможности поддержки
 пользовательских процедур проверки приводит к тому, что вместо сравнения
 значений двух полей в структурах применяется вызов удаленной процедуры
 по ссылке. А самой процедуре надо еще параметры в стек напихать. А сама
 процедура должна напиханные параметры еще и разыменовать. И т.д. ...
 
 > 
 
 [...поскипано...]
 
 > зы. а простой dnat не очень подходит для балансировки (точнее, совсем не
 > подходит)
 
 Очень интересно пообщаться с умным человеком. Даже если результат
 отрицательный ;) Жаль конечно. Я HАТом интересовался в теоретическом
 плане до его реализации в эхотаге. Замысел явно опережал возможности. Hу
 что же, подождем еще немного ;)
 
 Bye.
 -- 
 Aleksey Barabanov <alekseybb@mtu-net.ru>
 
 PS: Если не секрет, где лежат все эти ресурсы, типа
 "BALANCE.patch.configure.help" ?
 --- ifmail v.2.15dev5
  * Origin: Office Intranet (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор