IpfwNg

[nuclight]

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

Comments

[_slw]

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

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

[kondybas]

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

[_slw]

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

[kondybas]

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

[_slw]

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

[nuclight]

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

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

[_slw]

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

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

[actika]

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

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

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

[_slw]

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

[denis_sotchenko]

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

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

[_slw]

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

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

[denis_sotchenko]

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

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

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

[_slw]

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

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

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

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

[denis_sotchenko]

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

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

[_slw]

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

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

[nuclight]

Собсно, про эту штуку я и имею в виду, там в wiki линуксовый nf-hipac описан кратко, и ссылка на презентацию, где с 9 слайда описывается принцип, как это сворачивается в деревья. Вот только это для однозначной фунциональной (в математическом смысле) зависимости результата от полей пакета, а с divert/netgraph так не получится.