Вадим,
спасибо за некоторое прояснение ситуации.
On 14.06.2011 12:41, Vadim Goncharov wrote:
14.06.11 @ 15:34 Oleg Cherevko wrote:
В качестве workaround'а, по идее, можно было бы совсем отказаться от
ng_ipfw и просто вешать ng_netflow (ради которого вся эта возня и
затевалась изначально) прямо на все нужные интерфейсы, но тут засада в
том, что на той (боевой) машине, для которой это все предназначено,
работет ipfw nat, и хотелось бы, чтобы трафик при выходе в мир попадал
в ng_netflow до за'NAT'ивания, а при входе из мира -- после
раз'NAT'ивания. Потому, цеплять ng_netflow непосредственно на внешний
интерфейс не подходит.
Для данной конкретной задачи есть workaround: отправлять в ng_netflow не
сами пакеты, а их копии через ipfw ngtee (он в свежих версиях починен),
чтобы не было нужды их возвращать из netgraph.
А, кстати, да. Я как-то ngtee сразу мысленно "отложил в сторону" --
хотелось избежать лишнего копирования пакетов. Но, похоже, можно сделать
так: основной траффик все-таки пропускать через ipfw netgraph, а пакеты
идущие на 224.0.0.0/4 через ipfw ngtee:
ipfw add 10 netgraph 1 proto ip in
ipfw add 20 netgraph 1 ip from any to not 224/4 out
ipfw add 21 ngtee 2 ip from any to 224/4 out
Потом ipfw:1 прицепить к netflow:iface0, ipfw:2 к netflow:iface1,
netflow:out0 вернуть обратно, скажем, в ipfw:101, а netflow:out1 никуда
не цеплять. Костыль, конечно, но работать будет. Спасибо за идею.
--
Olwi
