![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
IpfwNg
В честь 26 годовщины 26 апреля уволился с текущей работы и таки наконец начал проект http://wiki.freebsd.org/IpfwNg — хотя на работе FreeBSD и была основной системой, реальную возможность пилить ядро я так и не получил (хотя тот же NAT64 нам бы понадобился не через полгода, так через год). В ближайшие недели посижу дома и надеюсь сделать хотя бы скелет, который можно будет потом уже в свободное время потихоньку пилить — работы по проекту предстоит очень много.
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
no subject
могу сказать, что человечного там при выборе таблицы маршрутизации довольно мало.
но это такая задача, которая на данный момент везде решается криво и есть ли для нее хорошее решение -- не ясно
no subject
no subject
синтаксисис -- мало ушел от птичьего.
а, не, вру -- натурально птичий, это же iproute. я в нем permit any any не осилил по ману, пришлось в гугл за примером лезть.
iproute2
no subject
1. балансировка каналов (в том числе QoS роутинг)
2. прозрачный прокси
3. отправка "ответов" в интерфейс, откуда был запрос.
п.2 чаще (в других местах) решается средствами nat. тут я думаю надо поступить так же -- в файрволе, natом.
п.1 участия файрвола не требует (по большей части), тут самое то -- отдельный модуль который хуками вцепляется в процесс роутинга и делает свое черное дело.
и остается п.3 -- во-первых не всегда надо отправлять откуда пришел (ну может у нас нормальный провайдинг и bgp) -- значит в файрволе надо сказать, что для этого flow надо экспортить информацию в этот модуль, во-вторых если мы куда отправили ftp cmd, то туда надо и ftp data отправить -- надо уметь разбирать протоколы и отслеживать flow, либо уметь спрашивать файрвол -- кому принадлежит этот пакет? для транзитных тут особой идеологической проблемы нет, а вот для сформированных на хосте пакетов -- видимо надо уметь сохранять результат разбора протокола на данном этапе дабы не делать работу два раза.
no subject
А чего заранее ограничиваться? И не cisco, а вообще. В идеале хочется, чтобы все задачи можно было решать.
> 2. прозрачный прокси
> п.2 чаще (в других местах) решается средствами nat. тут я думаю надо поступить так же -- в файрволе, natом.
Ээ, падажжы. Это ж fwd 127.0.0.1,3128 который? Там nat не нужен и даже близко не стоит. Даже в иптаблесах он емнип делается в таблице nat, но не самим натом.
Описанное в п.1 похоже на iproute2 и синтаксис для выбора таблицы, который - сюрприз - синтаксисом похож на ipfw. Что касается п.3, они это опять же по-моему через CONNMARK делают, т.е. модуль выбора маршрута берет инфу из файрвола берет. Чем у них хуже / что нам надо учесть/сделать лучше?
no subject
нахуй? в cisco policy-map используется и для фильтрации bgp маршрутов и не помню для чего еще. зачем тебе это?
там это совершенно перегруженная и недокументированная комманда/модуль.
я про мнесто в синтаксисе. что это надо отделять от просто pbr. что это на самом деле не pbr.
no subject
no subject
никаких причин это [приземлять на локальный сокет] делать обязательно через PBR нет.
по сути это никакой не PBR и выглядеть это в PBR будет так же не на месте, как и PBR в файрволе.
к нату это ближе, хотя и не нат.
можно это назвать другим термином (типа local termination) и использовать для этого другую директиву.
более того, если мы хотим так редиректить что-то более сложное, чем tcp, то нам надо разбирать протокол и отслеживать все потоки
no subject
ну это от безысходности скорее. есть же такая вундервафля (http://wiki.squid-cache.org/Features/Tproxy4)
afaik, чем-то подобным баловался в питере провайдер webplus.
no subject
no subject
>могу сказать, что человечного там при выборе таблицы маршрутизации довольно мало.
а в чём проблема?
root@laptus:~# ip rule help
Usage: ip rule [ list | add | del | flush ] SELECTOR ACTION
SELECTOR := [ not ] [ from PREFIX ] [ to PREFIX ] [ tos TOS ] [ fwmark FWMARK[/MASK] ]
[ iif STRING ] [ oif STRING ] [ pref NUMBER ]
ACTION := [ table TABLE_ID ]
[ prohibit | reject | unreachable ]
[ realms [SRCREALM/]DSTREALM ]
[ goto NUMBER ]
TABLE_ID := [ local | main | default | NUMBER ]
вполне human readable.
>но это такая задача, которая на данный момент везде решается криво и есть ли для нее хорошее решение -- не ясно
несколько таблиц, где в каждой живёт свой набор маршрутов банально проще для восприятия. т.е. нечто вроде кубиков, которые отладил и поднимаешься вверх по уровням абстракции, строя уже из кубиков что-то более сложное.
no subject
например, нигде не было описанно что стадия PREROUTING (кажется) влияет на возможность bind сокета к локальному адресу и на arp кажется тоже. это осенью было -- вспоминать лень.