![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
IpfwNg
В честь 26 годовщины 26 апреля уволился с текущей работы и таки наконец начал проект http://wiki.freebsd.org/IpfwNg — хотя на работе FreeBSD и была основной системой, реальную возможность пилить ядро я так и не получил (хотя тот же NAT64 нам бы понадобился не через полгода, так через год). В ближайшие недели посижу дома и надеюсь сделать хотя бы скелет, который можно будет потом уже в свободное время потихоньку пилить — работы по проекту предстоит очень много.
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
Желающие обсудить по делу — велкам в каменты (хотя я туда еще не все наброски оформил).
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