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.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
