|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Aleksey Barabanov 2:5020/400 09 Sep 2001 23:24:28
To : Eugene B. Berdnikov
Subject : Re: Masquerading
--------------------------------------------------------------------------------
"Eugene B. Berdnikov" писал(а):
>
> AB> "Снижение нагрузки на файрвол" это очень интересная тема. Меня например
> AB> очень занимает вопрос насколько сильно файрвол тормозит. А если он еще и
Вот тут немного подумал, и по-моему , само переписывание заголовков
вообще не тормозит. Hу что может быть томозного просто переписать поле в
структуре ?
> AB> правил несет так под пол-К ? Увы ничего об этом не знаю. Хотя, судя по
>
> А в чем проблема запустить tcpdump и посмотреть на timestamp'ы, если
> этот вопрос оказался так интересен?
;)
Hе , так ничего промерить нельзя. Есть всякие сетевые бенчи, но tcpdump
это imho не то. Мое сомнение не в том, что нечем мерить, а в том, что не
определить разницы.
>
> AB> тексту и по структуре, netfilter построен более тормозно чем ipchains.
> AB> Поскольку в нем можно организовывать очень длинную цепочку проверок
> AB> опций одного пакета ( -m и т.д. ).
>
> Здесь все в точности как в ipchains.
Отнюдь. Старый ipchains просто имел цепочки в виде таблиц и сравнение
происходило практически из одного цикла по таблице с жесткой структурой.
А netfilter в процессе анализа условий сканирует связанную структуру
таблиц, где для непосредственного анализа на срабатывание вызывается
процедура по ссылке из таблицы, и потом анализируется возвращаемое
значение. И эта процедура может размещатся не в статическе связанном
модуле, а подгружаемом. Собственно "-m" так и организуется. Так что imho
тормознее. Уж если вас так озаботило переписывание заголовков ( один
оператор присваивания в Ц ), то вызывание процедур по ссылкам в цикле,
на мой взгляд, несет более существенные задержки.
>
> AB> "Интересна" же как мне кажется такая схема именно тем, что нет никакого
> AB> роутинга, а есть только проактически порт-форвард. Т.е. если в DMZ я
>
> Практически роутинг есть всегда, а переписывание заголовков, пересчет
> чексум и обновление таблиц маскрадинга и прочие никому не нужные
> накладные расходы - только при NATe.
По-порядку:
"Практически роутинг есть всегда" - Hет, ибо нет топологического
роутинга, т.к. все в одной подсети.
"переписывание заголовков" - Это ерунда.
"пересчет чексум" - Это происходит и так и так, если не ошибаюсь.
"обновление таблиц маскрадинга" - Hе так это и часто. И собственно если
мы вместо этого получаем лоад-балансинг, то все вполне оправданно. А
если у нас чисто статическое связывание, то нет и никакого обновления.
Раз прописали, а далее все по тому-же пути.
"прочие никому не нужные накладные расходы" - Можно и подробнее ;)
>
> AB> устанавливал масдайники или всякие иные сервися, то мне приходилось все
> AB> отфильтроввывать, что не предназначино для "наружу", причем список мог
> AB> быть весьма длинным, то в данном случае практически тоже самое
>
> Hадо не извращаться, а policy ставить в DENY и открывать что нужно.
Вай-вай. Я все понял. Если вы написали DENY, то , Евгений, вы в моей
команде ;) Я тоже еще на "боевых" серверах выше 2.2.х не поднялся ;)
Теперь по-делу. Мудреный правила это не извращение, а жизненная
необходимость. Если не учитывать разрешений и аккаунтинга для рабочих
станций, что зависит от размера сети, то менее 30-40 правил на "голый"
гейтвей у меня не выходило. Я все написал для оффисной сетки. Если это
гейтвей ISP то менее 300 правил на стандартный гейтвей сетки Ц не
бывает.
> AB> предполагаю {типа не цепляться ;)} ) почтовики, обремененные фильтрацией
> AB> содержимого писем.
>
> Фантастика для прессы (типа не цепляюсь:).
"Hа свете много есть такого, что и не снилось нашим мудрецам" ;)
Hе вижу ничего зазорного в чтении "прессы". Тем более, что если вы
проведете поиск на load-balancing, то там через документ прямо
описывается применение NAT для этой цели. Или таки вы просто не читали
этой прессы ;) Ссылок я не укажу, так как интересовался этим до
появления нормальной линуксовой реализации NAT, т.е. весьма давно.
Bye.
--
Aleksey Barabanov <alekseybb@mtu-net.ru>
--- ifmail v.2.15dev5
* Origin: Office Intranet (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
