Re: netlink socket filtering

[Patrick McHardy <kaber@trash.net>]

Pablo Neira Ayuso wrote:
> Patrick McHardy wrote:
>> Your patches add a new table, at which point the conntrack
>> will also already have performed the transistion and filtering
>> using state matches will also only see the new state. So I'm
>> wondering, what are the exact filtering needs for replication
>> and would something like this work?
> 
> I mainly need conntrack event filtering capabilities by:
> 
> * protocol states, so that one can replicate TCP Established and 
> whatever state in the connection closure (or even the destroy event), I 
> don't need state transitions.

OK, so that should work.

> * source address and destination, so that the administrator can 
> replicate traffic for certain parts of the networks, eg. 192.168.0.0/24

That also works using BPF.

> I link this BSF-based solution, however, would they be flexible enough 
> for my needs? Another question that comes to my mind, isn't this 
> filtering coming to late? I mean, we have to invest time to build the 
> netlink message and then decide if we want to replicate it or not.

Its quite flexible, but you're right that it only takes place
after the message has already been constructed. The advantage
over selective unicast delivery is that if messages are consumed
by multiple receivers we only need to construct them once.
The downside is that messages that will get filtered on all
sockets are constructed completely unnecessary.