11:45 a.m.
Le 03/28/2013 16:59, Laine Stump wrote :
On 03/25/2013 05:12 PM, Benoit Friry wrote:
> On 03/25/2013 16:21, Eric Blake wrote:
>> On 03/25/2013 03:09 AM, Benoit Friry wrote:
>>> - starting default network (nat) adds rules in netfilter. I have
>>> not seen how to create another network nat conf without calling
>>> clean-traffic nwfilter (it is not explicit in network XML file).
nwfilter rules are applied to individual *guest interfaces* by adding a
<filterref> element to the guest's <interface> element. They are
completely unrelated to the netfilter rules added when a libvirt network
is started.
Indeed, I thought the added rules where from nwfilter. I did not
checked precisely. I did not suspect there were another set of rules
for networks.
The rules added for a libvirt virtual network change depending on
the
setting of "<forward mode='xxx'>" in the network config
1) for <forward mode='route'> a set of rules allowing all traffic in
both directions is added
2) for <forward mode='nat'> rules are added to allow outbound traffic
from the guests to any destination, prevent inbound traffic from
anywhere except a) the host and b) other guests attached to the same
network, AND to mangle the source address of packets outbound to places
beyond the host (so that they appear to be coming from the host itself).
3) if there is *no* <forward> (aka an "isolated" network), rules are
added to allow traffic only between guests on the same network and the
host, but block all other traffic.
The rules for each of these cases is hardcoded (and also very
simplistic) and can't be configured in any more finely grained manner.
It's a pity. There is nothing between all hardcoded rules and all manual
rules (in mode='bridge'). Manual rules are to be managed outside. It
would have been nice to be able to start/stop specific rules from
libvirt, linked to network start/stop commands.
Thanks for the explanation.
>>> - to be able to change the templates, for instance: -
not
>>> including any nwfilter when creating a network, - script called
>>> when adding a file in a dir pool, - and so on.
> Another example: what if I want to use BIND9 instead of dnsmasq? BIND9
> has a dns64 capability, dnsmasq has not.
>
> dnsmasq, radvd, brctl are hardcoded. Don't you think it would be
> better to call a helper script, that can be tweaked by admins?
No. That would be a nightmare to support; we specifically avoid doing
something that free-form. If you would like a network driver that uses
different utilities in place of dnsmasq and radvd, the proper way to do
that is with a different network driver to be built in place of
src/network/bridge_driver.c.
Ouch. Isn't it overkill? I can manage some scripts. I will not manage
patches, to be rebuild with every new release. Few organization can
afford such thing!
What about a overwrite conf file? Hardcoded conf by default, but one can
change some element. Support only when no overwrited conf.
But before you go to that trouble, are you certain that dnsmasq
still
doesn't have what you need? Recent versions of libvirt (since 1.0.1)
have support for many new IPv6 features of dnsmasq 2.66+, including
DHCP6, and I think dnsmasq has had support for IPv6 DNS resolution for
quite a long time. (I couldn't figure out from a quick google search
whether or not dnsmasq directly supports DNS64, or if that may be
unnecessary if the dns server upstream from dnsmasq has DNS64 support.)
AFAIK, dnsmasq has no DNS64 support.
Thanks,
Benoit