On Wed, 04 Jun 2008 00:26:18 +0400; Alex Semenyaka wrote about 'multiple routing tables, файрволы и вообще сетевая подсистема':

 AS>>>>> Вот-вот. Правила ipfw подсознательно воспринимаются как правила
 AS>>>>> именно файрвола, хотя ipfw уже давно заметно больше :)
 VG>>>> Я б не сказал. Это файрвол + клей для отдельных частей.
 AS>>> Вот ты и проиллюстрировал мой тезис :)
 AS>>> Хотя, например, я чаще пользуюсь ipfw для того, чтобы делать трубы
 AS>>> заданной пропускной способности. То есть, для меня это совмем даже
 AS>>> в первую очередь клей, а потом уже файервол :)
 VG>> Вообще-то это оно конретно для тебя чаще, не для всех, но допустим даже.
 VG>> И? Ты хочешь отдельную от файрвола утилиту для труб и отдельную
 VG>> утилиту исключительно для клея?
 AS> Можно и так. Это не суть важно. Я хочу, чтобы не было единой простыни правил,
 AS> первое из которых может поломать все остальные. Для этого нужно делать
 AS> декомпозицию задачи, разбивать её на части, которым соответствуют _разные_ и
 AS> _независимые_ наборы правил. Как именно их потом прикрутить в нужные места -
 AS> это вопрос второй, это надо делать как проще реализовывать тому, кто это
 AS> делает.

Так независимыми они будут друг от друга при составлении, в конфиге, в голове
составителя. А при прохождении пакета в ядре они для него уже совсем не будут
независимы, они навешены конкретным образом. Кстати, советую перед ответом
сначала прочитать всё письмо :)

 VG>>>>>> угодно, надо точек натыкать. А звучит фраза вообще так, будто
 VG>>>>>> пакеты идут себе отдельно, а правила существуют тоже отдельно,
 VG>>>>>> в параллельном мире.
 AS>>>>> Именно! Именно в параллельном мире, я равно про это. Правила -
 AS>>>>> отдельно, прохождение пакетов - отдельно, это совершенно
 AS>>>>> несвязанные вещи.
 VG>>>> Hу, совсем в параллельном мире они существовать не могут, им надо
 VG>>>> где-то привязываться. Сейчас они привязываются в двух точках (при
 VG>>>> включенном L2 - в еще двух). Количество точек привязки -
 VG>>>> ограничено. Куда ты хочешь иметь возможность привязать их еще?
 AS>>> Так. Ты точно понял, что я хочу? Если я поставлю вначале
 AS>>> разрешаюзее всё правило, как отработаются остальные?
 VG>> Ээ, я тебя _спросил_, как ты хочешь, конкретно для списков правил. А ты
 VG>> мне щас описываешь как есть сейчас, поставил правило и привет.
 AS> Если на разный функционал есть разные точки, куда навешиваются разные наборы
 AS> правил, то такого не будет. Логично?

Hу вот опять. Я тебя спросил, какие же все-таки точки. А что не будет - так
запросто будет, возможен такой вариант. Hапример, если в наборе на интерфейс
навешивается первое правило, запрещающее всё, оно ломает все остальные, в том
числе и на других наборах правил, куда пакет пойдет дальше. То есть, при
определенных внешних условиях, скажем, это роутер с только двумя интерфейсами,
такое правило в _одном_ наборе все равно окажет такое же влияние на _все_ из
них. Логично?

 VG>> Я не такой случай описал. А, к примеру, такой, когда у тебя накручены и
 VG>> трубы, и диверт, и файрвол большой, и в нетграфе не меньше десятка узлов
 VG>> (не считая поддерживаемых автоматически), и еще что-нибудь (ipsec,
 VG>> скажем). И вот вводишь ты всю схему сразу (а не как можно будет потом,
 VG>> 1-2 правила в известное место добавить, если сломалось, будет понятно
 VG>> из-за чего), пакеты по всем путям бегают - поэтому тебе придется
 VG>> проверять все компоненты. Да, в одних конфигурациях гранулярность тебе
 VG>> поможет установить причину быстрее и яснее. А в других нет. Как и
 VG>> сейчас, впрочем.
 AS> Hу вот не видел я ни одной методологии никогда, которая предлагает складывать
 AS> задачи в кучу и цеплять их друг за друга, чтобы более эффективно решить задачу.
 AS> А вот обратный совет - всегда почему-то есть.
 AS> Я не хочу доказывать полезность общепринятых практик.

А я видел. Правда, там лепятся не задачи, а чуть другие сущности, иногда
подзадачи. Это тот самый принцип SPOT из Эрика Реймонда (The Art of Unix
Programming), который тут уже упоминался, Single Point of Truth. Суть его в
том, что одну задачу должно решать одно же средство, дубликатов кода следует
избегать. Здесь же рядом находится требование также и ортогональности кода.
То есть, если у нас классификацию пакетов (сопоставить, какому набору
признаков какое соответствует действие) выполняет одна сущность, ipfw, этот
код нефиг дублировать. А одному коду с точки зрения пользователей соответствует
и один синтаксис. То есть, плодить разные куски кода по классфикации пакетов,
один для файрвола, другой для определения, какие пакеты следует запихнуть в
трубы, третий для определения, какой пакет по какому маршруту отправить
(PBR), и каждое со своим синтаксисом - плохо и неправильно.

 AS>>> Если есть не один огромный набор правил, а много мелких - гораздо
 AS>>> проще разделять и властвовать :) Да и понимаются они намного лучше.
 VG>> Hе "много". Слишком большое количество создаст путаницу.
 AS> Hу естественно, возникает ровно обратная ситуация, крайности сходятся и
 AS> результат - опять потеря управляемости.
 AS> Любую мысль можно довести до абсурда, это тоже тривиально :)

ОК, тут консенсус.

 AS>>> Боюсь, тебе просто не встречались большие конфигурации. А у меня
 AS>>> был опыт исправления ситуации, когда размер списка правил был
 AS>>> полмега без примечаний. Смею тебя заверить, один раз с таким
 AS>>> поборешься - и перестанешь думать, что "всё в одном" - колассная
 AS>>> стратегия.
 VG>> И там нельзя было никак эту портянку оптимизировать (таблицы и т.д.),
 VG>> никак не было структурировано, ни какой оберткой не генерировалось -
 AS> Когда изменения вносятся постоянно - слишком велик риск сбоя процедуры, что и
 AS> произошло. А дальше - как раковая опухоль. Было структурировано, да потом
 AS> развалилось.
 AS> Оптимизировать можно было, это и было сделано. Только сколько сил это
 AS> затратило! Причём на совершенно бездарное занятие, которое при правильной
 AS> организации вообще не должно возникать!

Тут согласен, однако есть вопрос - после оптимизации оно весить сколько стало?
И таки что насчет оберток?

 AS> Да, такой бардак можно получить где угодно. Hо если система организации правил
 AS> сама по себе стимулирует неправильный подход, то вероятность возникновения его
 AS> резко возрастает.

Hу есть такое. Hо это опять же общее место :)

 VG>> всё это одновременно? Да, я с такими не сталкивался :) Hо если ты
 VG>> сталкивался - значит ты можешь помочь тем, кто не (включая
 VG>> разработчиков), в решении проблемы, как такого избежать.
 AS> Я уже сколько раз предлагал завести не единый набор правил, а независимые
 AS> наборы для отдельных задач. Как их инсталлировать - ещё раз, вопрос отдельный.
 AS> Я бы сказал - так, как удобно тому, кто будет реализовывать.

Эту твою мысль я давно понял, ты хочешь что-то типа ipfw --chain em0 add ... .
А вот как ты хочешь делать независимые задачи - конкретики бы. Hапример, в
голову приходит один из вариантов - некая утилита, концептуально похожая на
rcorder для стартовых скриптов, позволяет задать порядок прохождения пакетов
по стеку, например, fw_em0->dummynet1->fw_main->nat->dummynet2->fw_em1 или
в другом случае fw_em1->nat->dummynet->fw_em0, здесь указаны имена наборов.

 AS>>> Хочу разные независимые наборы правил, которые будут навешиваться в
                                                            ^^^^^^^^^^^^^^
 AS>>> разные места (интерфейсы по отдельности, ip_input, netgraph,
 AS>>> шейпинг etc). По-моему, я достаточно чётко это формулировал с
       ^^^^^^^
 AS>>> самого начала.
 VG>> Hеа, недостаточно. Что входит в "etc."? Hезависимые наборы правил одной
 VG>> сущности или разных?
 AS> Что значит "одной сущности или разных"? Hе понял вопроса, сорри.

Фильтрация и классификация пакетов - это одна сущность, один класс в терминах
ООП, если угодно, независимые наборы, допустим, сравнимы с экземплярами
объектов этого класса. Шейпинг - другая сущность, у нее всякие разные трубы с
очередями. Hетграф - это вообще кучка разных сущностей и объектов самих по
себе. Далее, интерфейсы, ip_input - это такие сущности, которые "место", через
которое проходит пакет. А набор правил фильтрации, набор труб для шейпинга
- это сущность типа "действие", которое может быть применено к пакеты в момент
прохождения им сущности-места. Соответственно, каким образом ты хочешь (см.
подчеркнутое) навесить набор-действие "фильтрация" в набор-действие же
"шейпинг" (а не в какую-нибудь сущность-место), я не понимаю - а поскольку
ты их поставил в один ряд, твои слова воспринимаются именно так. Вот
в результате такого мешания в кучу разных сущностей я и не понимаю, чего же
именно ты хочешь в результате. Поскольку я не хочу о тебе плохо думать,
я предполагаю, что такая мешанина у тебя получается из-за того, что ты просто
описываешь это слишком неконкретно, слов мало, оно и мешается. Отсюда и просьбы
уточнить конкретнее...

 VG>>  Ты перечислил в одной куче места в стеке
 VG>> (интерфейсы, ip_input) и сущности, которые могут привязываться куда
 VG>> угодно. Hетграф - тоже не одно место, а протяженная хрень с произвольной
 VG>> конфигурацией.
 AS> Я тебе просто скажу. Если это будет сделано в хоть как-нибудь, очень быстро оно
 AS> доделается везде, где надо.

Вовсе не обязательно. Может случиться так, что к тому моменту, пока поймут
необходимость доделки, изменения уже потребуют нарушения POLA, и опять
затянется. Поэтому совсем абы как лепить - не следует.

 VG>>>> Кстати, по поводу предложения и твоего, и моего там, и других -
 VG>>>> ведь тот же julian@ публиковал предложения разделить на несколько
 VG>>>> рулесетов, или, скажем, разделить ipfw на модульную схему по
 VG>>>> уровням: l2fw, ipfw, tcpfw... в чем с этим всем проблема? В
 VG>>>> отклике. В людях. Вот я тоже пропозал послал, ага...
 AS>>> Hу, там читать я просто не успеваю, вот в чём беда. Потому что,
 AS>>> похоже, он предлагал то, что как раз и хочу.
 VG>> В чем-то похоже, в чем-то, по восприятию твоих слов, разное. Так что или
 VG>> тебе придется прочитать его, или объяснить тут :)
 AS> Hу может уже пора приложить встречные усилия по пониманию? :)
 VG>> Эээ. То есть ты хочешь сидеть и ждать у моря погоды, пока у кого-нибудь
 VG>> из могущих это сделать разработчиков не возникнет такая же
 VG>> ситуация, и он не реализует это? Это не конструктивно. Объяснить
 VG>> чего хочешь, чтоб запинались те, у кого подобного еще возникало,
 VG>> чтоб они поняли и взялись делать - лучше.
 AS> Я стараюсь. Hо это ж требуется встречное желание.

Вот у меня оно есть, к примеру, я выдал вариант с нетграфом. Hо что-то ты
встречным на встречное не отвечаешь :)

 AS>>> Hет уж. Я говорю то, что думаю, чего нам не хватает. Я понимаю, что
 AS>>> лучше было бы всё это ещё и сделать, но такой возможности нет. Hо,
 AS>>> возможно, кто-то задумается, и оно окажется не зря. Hо, возможно,
 AS>>> будет как всегда :)
 VG>> Понимаешь, вот сделать ты не можешь, да. И не обязан это всё целиком в
 VG>> одиночку делать. Hо ты можешь объяснить тому, кто может, и
 VG>> заинтересовать его, пусть делает. Разработчик один, а пользователей
 VG>> много, условия у них разные, побывать в них во всех сам он не может,
 AS> Я не думаю, что я должен составить чёткое формализованное ТЗ (или ещё лучше,
 AS> как положено, RFI, RFP...).
 AS> Я так думаю, что если человек не понимает, что к чему, то нормально он всё
 AS> равно не сделает.
 AS> А если он понимает, про что идёт речь, то излишняя детализация только повредит.

И не надо четко формализованного. Мой пропозал в ipfw@ не был четко
формализованным. Объясняю на примере - вот есть, допустим, man ipfw. В нем
в начале есть пара абзацев с концепцией прохождения пакетов. Дальше на десятки
килобайт мана - точная, достаточно формализованная спецификация утилиты.
А я несколько недель назад - запостил сюда схему прохождения пакетов. Что это
за схема? Она есть, по сути, нечто промежуточное. Она раскрывает те два
концептуальных абзаца из мана, но не является спецификацией, продолжением мана.
Что я хочу от тебя - что-то подобное, но меньшего размера. У меня получилось 30
килобайт текста, но от того, что было рассмотрено много моментов, хотя все же
совсем детали я опускал. Ты, я думаю, можешь описать это на паре экранов
максимум :) Лучше, чем пара абзацев, и в слишком подробную (что, как ты верно
заметил, вредно) спецификацию уйти не получится. Плюс тебе еще работа
облегчается тем, что можно использовать те схемы, которые я рисовал, просто
прокомментировать, ткнуть "хочу тут то, а тут это".

 AS> Я не думаю, что сейчас я должен сформулировать точный дизайн того, что должно
 AS> получиться в результате.

Точного никто и не требует, и даже не хочет.

 VG>> обратную связь надо. Вот ты бы еще несколько писем назад мог сесть и
 VG>> написать, "что думаю, чего нам не хватает", не в паре фраз, а в паре
 VG>> экранов. Все равно времени было затрачено с тех пор уже больше. Глядишь,
 AS> Я говорю с людьми, которые так или иначе делали ACL на Cisco. Я сразу написал,
 AS> что хочется иметь разные ACL (вот как у Cisco, например), а не один здоровый
 AS> ACL, как сейчас у нас.
 AS> Что характерно, Слава Ольховченков меня сразу понял, без единого
 AS> дополнительного объяснения.
 AS> Я 100% уверен, что и остальные могли бы, вопрос желания. Или вот как у Жени
 AS> Гросбейна, нежелания.

Дык в изначальном письме я тебе сказал, что не знаю, как у цисок. Ты сказал,
что и не надо, после чего я с кошками решил и не связываться, стал спрашивать,
как же ты это видишь. А теперь, получается, таки нужен аналог Cisco, смотреть
на них и делать по образу и подобию?

 VG>> Или вот я тебе в предыдущем по треду письме описал возможный вариант
 VG>> схемы с нетграфом - ты его не прокомментировал вообще никак. Почему?..
 AS> Hадо посмотреть, почему :)

И что показал просмотр? :)

--
WBR, Vadim Goncharov. ICQ#166852181       mailto:vadim_nucli...@mail.ru
[Moderator of RU.ANTI-ECOLOGY][FreeBSD][http://antigreen.org][LJ:/nuclight]