IpfwNg

[nuclight]

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

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

Comments

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

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

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

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

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

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

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

[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 та же история. зачем делать урезанную функциональность, если достаточно простыми и дешевыми средствами можно получить гораздо большую гибкость?

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

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