IpfwNg

[nuclight]

В честь 26 годовщины 26 апреля уволился с текущей работы и таки наконец начал проект http://wiki.freebsd.org/IpfwNg — хотя на работе FreeBSD и была основной системой, реальную возможность пилить ядро я так и не получил (хотя тот же NAT64 нам бы понадобился не через полгода, так через год). В ближайшие недели посижу дома и надеюсь сделать хотя бы скелет, который можно будет потом уже в свободное время потихоньку пилить — работы по проекту предстоит очень много.

Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).

Comments

[http://users.livejournal.com/_slw/]

1. уход от ipfw синтаксиса и идеологии.
2. интеграция и совмещение с nat.

1+2. скорее ближе к asa, но идти надо еще дальше. у asa nat и acl все же не одно и то же.
4. наконец-то поддержка ftp в файрволе!

[kondybas.livejournal.com]

1. Это уже будет не ипфв. Лично меня устраивает его идеология, а синтакс и подавно.
2. Зачем совмещать концептуально разные вещи?
1+2 вам надо - идите.
4. Существует масса протоколов и сервисов. Это что, все их "поддерживать в файрволле"? Гггггг.....

[http://users.livejournal.com/_slw/]

1. а) пох б) давно требуется что-то лучшее
2. затем что это удобно. затем что это близкие вещи. затем, что один без другого -- калека на костылях.
4. да, поддерживать.

[kondybas.livejournal.com]

"Вы просто не умеете их готовить" (с)

[http://users.livejournal.com/_slw/]

умею. но я ел и слаще морковки.

[nuclight.livejournal.com]

2 по ссылке и так есть, просто недоописано еще, а шо конкретно ты имеешь в виду под 1 ? И если с идеологией еще что-то могу нателепатировать, с синтаксисом-то что не так?

Идеология по крайней мере немного, да изменится, с синтаксисом вот хуже - если широкие массы userbase его не воспримут, такое изменение нафиг не сдалось.

[http://users.livejournal.com/_slw/]

тут надо очень много излагать, возможно имело бы смысл поговорить (по скайпу к примеру).
значит надо делать хорошо, что бы понравилось. вообще, кмк, фанатов синтаксиса ipfw нет.
есть те, кто говорят "приемлимо".
синтаксис растет из доисторических времен, когда он был простым и логичным. потом его расширяли сохраняя совместимость и получили уродца (ipfw table show или list? а nat? и т.п.).
у ipfw список правил со счетчиками -- они должны исполняться последовательно (что очень не эффективно), ты не можешь провести оптимизацию и проверить пакет сразу по всем правилам

новый файрвол должен быть statefull по умолчанию. таблиц state должно быть несколько в пределах нескольких fib (настраиваемо), т.е. что бы можно было сказать, что пакеты по пути em0/em1 организуют satet, не пересекающеся с пакетами bge0/bge1 (мы не хотим видеть ответ на пакет, отправленный с интерфейса em0 на интерфейсе bge1).

[actika.livejournal.com]

>новый файрвол должен быть statefull по умолчанию. таблиц state должно быть несколько в пределах нескольких fib (настраиваемо), т.е. что бы можно было сказать, что пакеты по пути em0/em1 организуют satet, не >пересекающеся с пакетами bge0/bge1 (мы не хотим видеть ответ на пакет, отправленный с интерфейса em0 на интерфейсе bge1).

Если вам так мила идеалогия IPTABLES поставьте себе линукс. Ненужно тянуть эту безумную модель в freebsd.

>у ipfw список правил со счетчиками -- они должны исполняться последовательно (что очень не эффективно)
На удафф в нетленки :-))

[http://users.livejournal.com/_slw/]

iptables родился в твоем безумном мозгу

[denis-sotchenko.livejournal.com]

ipfw задаёт алгоритм обработки пакета. как можно "проверить пакет сразу по всем правилам", если задано много ветвлений?

ну и наконец, если посмотреть на "старшего брата" - Juniper - там правила тоже просматриваются последовательно. и как мне кажется, вполне эффективно :D

[http://users.livejournal.com/_slw/]

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

так же, как у джунипера не знаю, а у кошек существует компиляция acl, которая ускоряет обработку длинных списков

[denis-sotchenko.livejournal.com]

Таблица роутинга - это именно таблица. Есть чёткое соответствие X->Y, она логически однозначна и вполне очевидным образом компилируется в radix tree.

А под ветвлениями я имею в виду условные переходы, которых в таблицах роутинга нет.
В отличие от таблицы роутинга, логика обработки пакета в ipfw не зависима однозначно от содержимого этого пакета.
Может быть задана вероятность, может вернуть тот или иной результат вызванный через divert или netgraph внешний модуль, пакет может быть отброшен/пропущен dummynet'ом.
ipfw фактически является языком программирования.

Компьютеры тоже последовательно просматривают инструкции, и что-то я не слышал про универсальное решение оптимизации кода, которое могло бы свернуть программу в дерево. Оптимизируются только частные случаи.

[http://users.livejournal.com/_slw/]

Таблица роутинга - это именно таблица. Есть чёткое соответствие X->Y, она логически однозначна и вполне очевидным образом компилируется в radix tree.

ну разумеется нет. и соответсвия нет и однозначности. или по твоему правило "наилучшее совпадение" от нечего делать вводили? и radix tree там очень специальный.

Компьютеры тоже последовательно просматривают инструкции, и что-то я не слышал про универсальное решение оптимизации кода, которое могло бы свернуть программу в дерево. Оптимизируются только частные случаи.

вот в этом и состоит недостаток синтаксиса ipfw -- автоматически оптимизировать обработку части правил можно, но не все, а если хочется все остальное -- то надо либо явно указывать (т.е. менять синтаксис) или применять эвристики (что чревато)

[denis-sotchenko.livejournal.com]

Есть чёткая логическая однозначность - действует более специфичный маршрут. Для каждого конкретного dsp ip есть конкретный шлюз.

А про синтаксис - автоматически однозначно оптимизировать можно только линейный набор правил. Но линейный набор правил не годится для очень многих практических задач.

[http://users.livejournal.com/_slw/]

"более специфичный" -- это искуственно внесенное правило для возможности паралельной обработки.
собственно для файрвольных правил это тоже может работать (хоть и не всегда и вообще предмет для дискурсии).
шлюз, кстати, не конкретный -- бывает и в интерфейс (даже езернетовский и я этим пользовался) и бывает несколько шлюзов.

А про синтаксис - автоматически однозначно оптимизировать можно только линейный набор правил. Но линейный набор правил не годится для очень многих практических задач.

пфф. основная проблема к производительности файрволов -- то, что они медленно отрабатывают тысячу другую правил. которые скорее будут типа

permit from {список} to host dst-port 443
deny from any to host dst-port 443

и так для 100500 разных хостов и портов, а вовсе не цепочкой из 100500 дивертов и нетграфов. т.е. они тоже могут встретиться, но их не будет 100500 последовательных и это никак не мешает 100500 линейных обрабатывать паралельно. но более другой синтаксис мог бы эту задачу облегчить и/или избавить от глупых ошибок типа

permit 10.0.0.0/8 to host
deny 10.0.1.0/24 to host

второе правило никогда не сработает.

[nuclight.livejournal.com]

> вот в этом и состоит недостаток синтаксиса ipfw -- автоматически оптимизировать обработку части правил можно, но не все, а если хочется все остальное -- то надо либо явно указывать (т.е. менять синтаксис) или применять эвристики (что чревато)

А это уже не синтаксиса проблема, а семантики - возможностей дохуя. Синтаксис их просто отражает и по большому счету не важен.

[nuclight.livejournal.com]

> тут надо очень много излагать, возможно имело бы смысл поговорить (по скайпу к примеру).

Скайпа у меня нет, и вообще на слух я воспринимаю плохо - мне нужно видеть буквы перед глазами. Тут разве что в реале еще куда ни шло, где можно бумажки порисовать. Из вариантов неплох IRC, и я и тот же denis_sotchenko (ibl) в RusNet обитаем, реалтаймовый чат. Еще он предложил всем заинтересованным в реале собраться обсудить, благо погода позволяет, но мы в Мск, как с Питером, хз.

По остальному - да, ессно stateful, про несколько разных таблиц _стейтов_ - надо смотреть, зачем оно может быть нужно на практик, и каким быть.

По правилам последовательно - я там в wiki черканул про nf-hipac и про счетчики, погляди.

[http://users.livejournal.com/_slw/]

не, я имел ввиду именно поговорить, поскольку текста слишком много набирать.
что бы картинки рисовать -- ну можно найти с desctop sharing, в конце концов у webex вроде бесплатный месяц есть.

про несколько разных таблиц _стейтов_ - надо смотреть, зачем оно может быть нужно на практик, и каким быть.

если файрвол применяется в корпоративной среде, то там может быть требование, что пакет от серверов в dmz не может прилететь иначе, чем с bge0. а lan -- исключительно на bge1. вот что бы не думать -- мы говорим, что bge0-bge1 -- относятся к одной таблице состояний, а bge1-bge2 -- к другой. а может быть так, что пакет может прилететь и em0 и em1. тогда у нас будет bge0-{em0,em1}. ну или вообще без разницы.

По правилам последовательно - я там в wiki черканул про nf-hipac и про счетчики, погляди.

не очень понял-то. т.е. некоторые мысли от капитана очевидность, ну да, сложно в чем-то. а кто обещал просто? ну и исходник можно вместе с компиленым хранить и показывать его.

[http://users.livejournal.com/_dyr/]

Чтобы не думать, в ipfw специально для целей rpf check есть antispoof и verrev-path.

[http://users.livejournal.com/_slw/]

ты никогда не имел дела с корпоративными сетями и файрволами для них?

нет, на эти проверки роутинг вляеть не должен. наличие протоколов динамической маршрутизации и анонс кем-то нехорошим такого роута не должен приводить ни к гроханию стэйта ни к допустимости нового такого стейта

[dadv.livejournal.com]

В динамике есть фильтрация маршрутов, конкретно в OSPF есть md5 для нейборов.

[http://users.livejournal.com/_dyr/]

Ваш набор слов почему-то совершенно не складывается в осмысленную фразу. Поясните, что вы хотите сказать и при чём здесь роутинг?

Способ коммуникации лучше тот, который удобен мне, а не

[nuclight.livejournal.com]

Нащот всего коммента разом - я только из ветки ответивших людей понял, что на самом деле потребность не в нескольких таблицах состояний, а в фиксировании исходный интерфейсов в стейте с отсеканием при не тех (опционально с воплями). Рисовать на компе - это тот еще пиздец, совсем не реалтаймовый. Скайпы и прочее - пардон, _мне_ аудио-режим неудобен. Разговаривать в реале и на бумажке при этом чёркать - это да, это может быть продуктивно. Написать несколько экранов текста в оффлайне с картинками - это тоже продуктивно. Всё остальное - варьируется, и поскольку реализовывать мне - причем мне за это не платят - то и выбирать мне. Если хочешь что-то донести, то уж будь добр, приложи к тому усилия - от тебя их и так на порядки меньше требуется, чем от меня. А пока что меня несколько раздражает даже корявое оформление комментариев - больших букв в предложениях нет, цитаты не отделены, приходится тратить лишнее время и напрягать глаза, чтобы распарсить и поскипать ненужное.

[http://users.livejournal.com/_slw/]

Нащот всего коммента разом - я только из ветки ответивших людей понял, что на самом деле потребность не в нескольких таблицах состояний, а в фиксировании исходный интерфейсов в стейте с отсеканием при не тех (опционально с воплями).

фактически для реализации этого и надо несколько пространств стейтов. поскольку, например, адрес A в двух разных FIB может являться разным адресом. ну в двух разных VIRTNET -- просто однозначно. но (я про это не писал, но это есть следствие того, за что я агитирую) -- должен ли файрвол [транзитный] для своей работы иметь в ядре сконфигурированные сущности (протоколы, virtnetы), по которым работает? я считаю -- нет, не обязательно. т.е. например фильтрацию в vlan можно устраивать не создавая интерфейс vlan в ядре.

Скайпы и прочее - пардон, _мне_ аудио-режим неудобен. Разговаривать в реале и на бумажке при этом чёркать - это да, это может быть продуктивно. Написать несколько экранов текста в оффлайне с картинками - это тоже продуктивно.

это правильно, но долго. все это можно было бы проговорить за полчаса, а у нас ушел месяц астрономического времени и несколько часов долбежа по кнопкам. да, на данный момент уже не так актуально, большая часть уже изложена.

А пока что меня несколько раздражает даже корявое оформление комментариев - больших букв в предложениях нет, цитаты не отделены, приходится тратить лишнее время и напрягать глаза, чтобы распарсить и поскипать ненужное.

скажем спасибо жж. на почту твои каменты тоже приходят в несколько странном виде. в вебинтерфейсе с цитатами понятнее. хорошо хоть лимит на объем камента подняли, с четыремя килобайами вообще ничего длинного не изложить было.

[nuclight.livejournal.com]

По нескольким пространствам стейтов - для генерализованного решения да, это полезно. Но задачи, их требующие, не столь часты, и даже в линуксе поддержка неймспейсов появилась очень недавно. И конкретно описанная задача лучше решается не несколькими пространствами, а security-обработчиком flow, который записывает интерфейсы на первых проходящих пакетах в регистры dynrule и сравнивает их далее на каждом проходящем. Что касается одинаковых адресов в разных FIB - ну так для этого в ядре таки должны быть сконфигурены разные fib, например. Не всё везде так однозначно.

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