IpfwNg

[nuclight]

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

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

Comments

[nuclight.livejournal.com]

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

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

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

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

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

И конкретно описанная задача лучше решается не несколькими пространствами, а security-обработчиком flow, который записывает интерфейсы на первых проходящих пакетах в регистры dynrule и сравнивает их далее на каждом проходящем

это криво. это будет плохо работать. особенно если у нас что-то типа {bge0,bge1,bge2}-{bge3,bge4,bge5}

Что касается одинаковых адресов в разных FIB - ну так для этого в ядре таки должны быть сконфигурены разные fib, например.

почему в ядре должны быть сконфигурированны сущности, по которым работает файрвол?
разве для фильтрации транзитного tcp в ядре должны быть tcp сокеты? ну или stcp.
файрволу не требуется поддержка ядра для этих действий.
и я уже приводил пример -- файрвол может фильтровать трафик в транзитном GRE-туннеле, не терминируюя его на машине. точно так же можно фильтровать трафик в езернетовском транке, не терминируя и не заводя vlanы в ядре, просто поставив в режим бриджа и самостоятельно разбирая 802.1q заголовки. ну и с метками mpls та же история. зачем делать урезанную функциональность, если достаточно простыми и дешевыми средствами можно получить гораздо большую гибкость?

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

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