Re: [libvirt] [PATCH V4] nwfilter: Add support for ipset
On 05/14/2012 09:00 PM, Stefan Berger wrote:
This patch adds support for the recent ipset iptables extension
to libvirt's nwfilter subsystem. Ipset allows to maintain 'sets'
of IP addresses, ports and other packet parameters and allows for
faster lookup (in the order of O(1) vs. O(n)) and rule evaluation
to achieve higher throughput than what can be achieved with
individual iptables rules.
On the command line iptables supports ipset using
iptables ... -m set --match-set <ipset name> <flags> -j ...
where 'ipset name' is the name of a previously created ipset and
flags is a comma-separated list of up to 6 flags. Flags use 'src' and
'dst'
for selecting IP addresses, ports etc. from the source or
destination part of a packet. So a concrete example may look like this:
iptables -A INPUT -m set --match-set test src,src -j ACCEPT
Since ipset management is quite complex, the idea was to leave ipset
management outside of libvirt but still allow users to reference an
ipset.
The user would have to make sure the ipset is available once the VM is
started so that the iptables rule(s) referencing the ipset can be
created.
I think that at least a subset of it needs to be in libvirt, if only so
that the use of ipset makes sense when it isn't available natively on a
host. On that topic - could the new XML you're proposing be made
useful/applicable with a packet filtering system other than iptables
(or, for that matter, on a system with iptables but no ipset?). Or is it
specific to ipset? (I haven't thought about it enough to come up with my
own answer; I'm just at the stage of questions).
I'm concerned that we might add something by definition
iptables-specific, and even within that requiring a particular version
of iptables, which would then be difficult/impossible to translate to
some other filtering system. If there are too many features like that,
we can be guaranteed that we'll never see any support other than iptables.
(Yes, I know we currently only have a driver for iptables, but it seems
like a good idea to not lock us into that. I've got this thought in the
back of my head that maybe someday firewalld could (should?) be
supported as a separate driver, rather than just using its passthrough
mode (which bypasses some of the automatic management it's trying to
provide, for better or for worse)) (It's really too bad nobody has
written an ipf (or whatever) filter driver for libvirt - that would help
keep us honest when adding new features :-)
I may be worrying about nothing, as it does seem like a simple addition,
but thought I should bring it up anyway, to make sure we go through due
diligence.
Using XML to describe an ipset in an nwfilter rule would then look as
follows:
<rule action='accept' direction='in'>
<all ipset='test' ipsetflags='src,src'/>
</rule>
The two parameters on the command line are also the two distinct XML
attributes
'ipset' and 'ipsetflags'.
FYI: Here is the man page for ipset:
https://ipset.netfilter.org/ipset.man.html
(That link fails for me unless I change https to http)