![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
IpfwNg
В честь 26 годовщины 26 апреля уволился с текущей работы и таки наконец начал проект http://wiki.freebsd.org/IpfwNg — хотя на работе FreeBSD и была основной системой, реальную возможность пилить ядро я так и не получил (хотя тот же NAT64 нам бы понадобился не через полгода, так через год). В ближайшие недели посижу дома и надеюсь сделать хотя бы скелет, который можно будет потом уже в свободное время потихоньку пилить — работы по проекту предстоит очень много.
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
no subject
Идеология по крайней мере немного, да изменится, с синтаксисом вот хуже - если широкие массы userbase его не воспримут, такое изменение нафиг не сдалось.
no subject
значит надо делать хорошо, что бы понравилось. вообще, кмк, фанатов синтаксиса ipfw нет.
есть те, кто говорят "приемлимо".
синтаксис растет из доисторических времен, когда он был простым и логичным. потом его расширяли сохраняя совместимость и получили уродца (ipfw table show или list? а nat? и т.п.).
у ipfw список правил со счетчиками -- они должны исполняться последовательно (что очень не эффективно), ты не можешь провести оптимизацию и проверить пакет сразу по всем правилам
новый файрвол должен быть statefull по умолчанию. таблиц state должно быть несколько в пределах нескольких fib (настраиваемо), т.е. что бы можно было сказать, что пакеты по пути em0/em1 организуют satet, не пересекающеся с пакетами bge0/bge1 (мы не хотим видеть ответ на пакет, отправленный с интерфейса em0 на интерфейсе bge1).
no subject
Если вам так мила идеалогия IPTABLES поставьте себе линукс. Ненужно тянуть эту безумную модель в freebsd.
>у ipfw список правил со счетчиками -- они должны исполняться последовательно (что очень не эффективно)
На удафф в нетленки :-))
no subject
no subject
ну и наконец, если посмотреть на "старшего брата" - Juniper - там правила тоже просматриваются последовательно. и как мне кажется, вполне эффективно :D
no subject
так же, как у джунипера не знаю, а у кошек существует компиляция acl, которая ускоряет обработку длинных списков
no subject
А под ветвлениями я имею в виду условные переходы, которых в таблицах роутинга нет.
В отличие от таблицы роутинга, логика обработки пакета в ipfw не зависима однозначно от содержимого этого пакета.
Может быть задана вероятность, может вернуть тот или иной результат вызванный через divert или netgraph внешний модуль, пакет может быть отброшен/пропущен dummynet'ом.
ipfw фактически является языком программирования.
Компьютеры тоже последовательно просматривают инструкции, и что-то я не слышал про универсальное решение оптимизации кода, которое могло бы свернуть программу в дерево. Оптимизируются только частные случаи.
no subject
ну разумеется нет. и соответсвия нет и однозначности. или по твоему правило "наилучшее совпадение" от нечего делать вводили? и radix tree там очень специальный.
вот в этом и состоит недостаток синтаксиса ipfw -- автоматически оптимизировать обработку части правил можно, но не все, а если хочется все остальное -- то надо либо явно указывать (т.е. менять синтаксис) или применять эвристики (что чревато)
no subject
А про синтаксис - автоматически однозначно оптимизировать можно только линейный набор правил. Но линейный набор правил не годится для очень многих практических задач.
no subject
собственно для файрвольных правил это тоже может работать (хоть и не всегда и вообще предмет для дискурсии).
шлюз, кстати, не конкретный -- бывает и в интерфейс (даже езернетовский и я этим пользовался) и бывает несколько шлюзов.
пфф. основная проблема к производительности файрволов -- то, что они медленно отрабатывают тысячу другую правил. которые скорее будут типа
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
второе правило никогда не сработает.
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
А это уже не синтаксиса проблема, а семантики - возможностей дохуя. Синтаксис их просто отражает и по большому счету не важен.
no subject
у функциональных языков обычно синтаксис несколько отличный от процедурных и отражает их идеологию.
т.е. я не говорю, что синтаксис весь нафиг другой должен быть (ну как в примере к nftables -- мне не нравится), но должно быть явное выделение блоков правил, которые проверяются одновременно и как они разделяются всякими divert/netgraph (или вообще просто разделяются, если я хочу вначале влепить permit any any), к примеру.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Скайпа у меня нет, и вообще на слух я воспринимаю плохо - мне нужно видеть буквы перед глазами. Тут разве что в реале еще куда ни шло, где можно бумажки порисовать. Из вариантов неплох IRC, и я и тот же
По остальному - да, ессно stateful, про несколько разных таблиц _стейтов_ - надо смотреть, зачем оно может быть нужно на практик, и каким быть.
По правилам последовательно - я там в wiki черканул про nf-hipac и про счетчики, погляди.
no subject
что бы картинки рисовать -- ну можно найти с desctop sharing, в конце концов у webex вроде бесплатный месяц есть.
если файрвол применяется в корпоративной среде, то там может быть требование, что пакет от серверов в dmz не может прилететь иначе, чем с bge0. а lan -- исключительно на bge1. вот что бы не думать -- мы говорим, что bge0-bge1 -- относятся к одной таблице состояний, а bge1-bge2 -- к другой. а может быть так, что пакет может прилететь и em0 и em1. тогда у нас будет bge0-{em0,em1}. ну или вообще без разницы.
не очень понял-то. т.е. некоторые мысли от капитана очевидность, ну да, сложно в чем-то. а кто обещал просто? ну и исходник можно вместе с компиленым хранить и показывать его.
no subject
no subject
нет, на эти проверки роутинг вляеть не должен. наличие протоколов динамической маршрутизации и анонс кем-то нехорошим такого роута не должен приводить ни к гроханию стэйта ни к допустимости нового такого стейта
no subject
no subject
в любом случае закладываться на то, что не проанонсят -- неверно.
т.е. кому-то может и достаточно, но принципиально рубить такую возможность -- неверно.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
роутинг тут при rpf и verrev.
Способ коммуникации лучше тот, который удобен мне, а не
no subject
фактически для реализации этого и надо несколько пространств стейтов. поскольку, например, адрес A в двух разных FIB может являться разным адресом. ну в двух разных VIRTNET -- просто однозначно. но (я про это не писал, но это есть следствие того, за что я агитирую) -- должен ли файрвол [транзитный] для своей работы иметь в ядре сконфигурированные сущности (протоколы, virtnetы), по которым работает? я считаю -- нет, не обязательно. т.е. например фильтрацию в vlan можно устраивать не создавая интерфейс vlan в ядре.
это правильно, но долго. все это можно было бы проговорить за полчаса, а у нас ушел месяц астрономического времени и несколько часов долбежа по кнопкам. да, на данный момент уже не так актуально, большая часть уже изложена.
скажем спасибо жж. на почту твои каменты тоже приходят в несколько странном виде. в вебинтерфейсе с цитатами понятнее. хорошо хоть лимит на объем камента подняли, с четыремя килобайами вообще ничего длинного не изложить было.
no subject
По переписке - ну, если большая часть уже изложена, это хорошо. Здесь ветки уж слишком разрослись, надо уточнить некоторые моменты здесь, а потом сухой остаток предварительного итога в новый пост вынести.
no subject
это проблемы линуха. почему это должно меня волновать? виртуальные файрволы в asa появились очень давно. не регулируемое поведение было вообще изначально, в pix. регулируемое появилось относительно недавно, но достаточно давно на самом деле, кажется даже раньше нэймспэйсов. и это с твоей колокольни они не часты -- это типичная задача в корпоративной среде. ну да, как ее можно увидеть не работая там? просто поверь мне.
это криво. это будет плохо работать. особенно если у нас что-то типа {bge0,bge1,bge2}-{bge3,bge4,bge5}
почему в ядре должны быть сконфигурированны сущности, по которым работает файрвол?
разве для фильтрации транзитного tcp в ядре должны быть tcp сокеты? ну или stcp.
файрволу не требуется поддержка ядра для этих действий.
и я уже приводил пример -- файрвол может фильтровать трафик в транзитном GRE-туннеле, не терминируюя его на машине. точно так же можно фильтровать трафик в езернетовском транке, не терминируя и не заводя vlanы в ядре, просто поставив в режим бриджа и самостоятельно разбирая 802.1q заголовки. ну и с метками mpls та же история. зачем делать урезанную функциональность, если достаточно простыми и дешевыми средствами можно получить гораздо большую гибкость?
может я и не прав и мне не удалось многое до тебя до нести. но раз в неделю -- я уже непомню что сказал, что нет.