nuclight: (Default)
nuclight ([personal profile] nuclight) wrote2012-04-26 03:11 am
Entry tags:

IpfwNg

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

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

[identity profile] nuclight.livejournal.com 2012-05-18 01:47 am (UTC)(link)
> pbr решает обычно (в ipfw, cisco не берем -- там больше) три задачи:

А чего заранее ограничиваться? И не cisco, а вообще. В идеале хочется, чтобы все задачи можно было решать.

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

Ээ, падажжы. Это ж fwd 127.0.0.1,3128 который? Там nat не нужен и даже близко не стоит. Даже в иптаблесах он емнип делается в таблице nat, но не самим натом.

Описанное в п.1 похоже на iproute2 и синтаксис для выбора таблицы, который - сюрприз - синтаксисом похож на ipfw. Что касается п.3, они это опять же по-моему через CONNMARK делают, т.е. модуль выбора маршрута берет инфу из файрвола берет. Чем у них хуже / что нам надо учесть/сделать лучше?

[identity profile] http://users.livejournal.com/_slw/ 2012-05-18 02:31 pm (UTC)(link)
А чего заранее ограничиваться? И не cisco, а вообще. В идеале хочется, чтобы все задачи можно было решать.

нахуй? в cisco policy-map используется и для фильтрации bgp маршрутов и не помню для чего еще. зачем тебе это?
там это совершенно перегруженная и недокументированная комманда/модуль.

Ээ, падажжы. Это ж fwd 127.0.0.1,3128 который? Там nat не нужен и даже близко не стоит. Даже в иптаблесах он емнип делается в таблице nat, но не самим натом.

я про мнесто в синтаксисе. что это надо отделять от просто pbr. что это на самом деле не pbr.


[identity profile] nuclight.livejournal.com 2012-05-31 10:03 pm (UTC)(link)
А надо ли? И зачем? Вот есть у нас два основных legacy-рулесета как сейчас (точнее один, просто вызывается из pfil на in и out), есть еще другие рулесеты, и есть модуль PBR где-то в ip_forward(). В каком месте стека должен быть этот редирект на локальный порт самого файрвола? Почему бы не оставить его в основном legacy-рулесете?

[identity profile] http://users.livejournal.com/_slw/ 2012-06-01 06:34 am (UTC)(link)
делать надо так, как будет логичнее выглядеть в конфиге.
никаких причин это [приземлять на локальный сокет] делать обязательно через PBR нет.
по сути это никакой не PBR и выглядеть это в PBR будет так же не на месте, как и PBR в файрволе.

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