![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
nuclightВ честь 26 годовщины 26 апреля уволился с текущей работы и таки наконец начал проект http://wiki.freebsd.org/IpfwNg — хотя на работе FreeBSD и была основной системой, реальную возможность пилить ядро я так и не получил (хотя тот же NAT64 нам бы понадобился не через полгода, так через год). В ближайшие недели посижу дома и надеюсь сделать хотя бы скелет, который можно будет потом уже в свободное время потихоньку пилить — работы по проекту предстоит очень много.
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
Способ коммуникации лучше тот, который удобен мне, а не
Date: 2012-05-25 01:53 am (UTC)no subject
Date: 2012-05-25 05:01 am (UTC)фактически для реализации этого и надо несколько пространств стейтов. поскольку, например, адрес A в двух разных FIB может являться разным адресом. ну в двух разных VIRTNET -- просто однозначно. но (я про это не писал, но это есть следствие того, за что я агитирую) -- должен ли файрвол [транзитный] для своей работы иметь в ядре сконфигурированные сущности (протоколы, virtnetы), по которым работает? я считаю -- нет, не обязательно. т.е. например фильтрацию в vlan можно устраивать не создавая интерфейс vlan в ядре.
это правильно, но долго. все это можно было бы проговорить за полчаса, а у нас ушел месяц астрономического времени и несколько часов долбежа по кнопкам. да, на данный момент уже не так актуально, большая часть уже изложена.
скажем спасибо жж. на почту твои каменты тоже приходят в несколько странном виде. в вебинтерфейсе с цитатами понятнее. хорошо хоть лимит на объем камента подняли, с четыремя килобайами вообще ничего длинного не изложить было.
no subject
Date: 2012-05-31 10:30 pm (UTC)По переписке - ну, если большая часть уже изложена, это хорошо. Здесь ветки уж слишком разрослись, надо уточнить некоторые моменты здесь, а потом сухой остаток предварительного итога в новый пост вынести.
no subject
Date: 2012-06-01 06:47 am (UTC)это проблемы линуха. почему это должно меня волновать? виртуальные файрволы в asa появились очень давно. не регулируемое поведение было вообще изначально, в pix. регулируемое появилось относительно недавно, но достаточно давно на самом деле, кажется даже раньше нэймспэйсов. и это с твоей колокольни они не часты -- это типичная задача в корпоративной среде. ну да, как ее можно увидеть не работая там? просто поверь мне.
это криво. это будет плохо работать. особенно если у нас что-то типа {bge0,bge1,bge2}-{bge3,bge4,bge5}
почему в ядре должны быть сконфигурированны сущности, по которым работает файрвол?
разве для фильтрации транзитного tcp в ядре должны быть tcp сокеты? ну или stcp.
файрволу не требуется поддержка ядра для этих действий.
и я уже приводил пример -- файрвол может фильтровать трафик в транзитном GRE-туннеле, не терминируюя его на машине. точно так же можно фильтровать трафик в езернетовском транке, не терминируя и не заводя vlanы в ядре, просто поставив в режим бриджа и самостоятельно разбирая 802.1q заголовки. ну и с метками mpls та же история. зачем делать урезанную функциональность, если достаточно простыми и дешевыми средствами можно получить гораздо большую гибкость?
может я и не прав и мне не удалось многое до тебя до нести. но раз в неделю -- я уже непомню что сказал, что нет.