Re: ideas for custom iptables rules for libvirt networks.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Apr 26, 2016 at 11:06:23AM -0400, Laine Stump wrote:
> On 04/26/2016 04:15 AM, Daniel P. Berrange wrote:
> > On Mon, Apr 25, 2016 at 01:48:49PM -0400, Laine Stump wrote:
> >> We still periodically get requests to allow custom iptables rules for
> >> libvirt virtual networks (or, more commonly, a mode where libvirt simply
> >> leaves iptables alone, not adding or removing anything), and it's been a
> >> nagging item on my to-do list for a very long time. The problem is that,
> >> although the amount of code required to support *any* solution is very
> >> small, it's one of those things without a single obvious "only" way to do
> >> it. Anyway, I'm going to take one more stab at it.
> >>
> >>
> >> First, some background points:
> >>
> >> * For <forward mode='nat'> libvirt's iptables rules are essential to the
> >> operation of the forwarding, so we shouldn't mess with that.
> >>
> >> * For [no forward mode], libvirt's iptables rules are a part of what keeps
> >> the network isolated from the rest of the network, so we shouldn't mess with
> >> that either.
> >>
> >> * For <forward mode='route'> we currently allow all outgoing and incoming as
> >> long as it is to/from the IP address range defined for the network.
> >>
> >> So we really want something that can be used only for <forward mode='route'>
> >>
> >> I can see 3 different possibilities:
> >>
> >> 1) a new forward mode which is just like 'route', but doesn't add any
> >> iptables rules. (what to call it though? "filterless-route"? Too long and
> >> ugly :-/)
> > I'd suggest this and just call it mode='bare' or mode='open', to avoid
> > implying any specific semantics about the connectivity.
> 
> Thinking about this more, I'm having disturbing memories of trying to 
> combine multiple knobs into a single attribute in the past, only to have 
> it backfire later (I can't recall anything specific though) - for 
> example although I say right now that there's no reason to skip adding 
> rules for isolated or nat networks, we may come up with a valid use case 
> in the future. For that reason, I think it may be safer to add:
> 
>     <forward mode='route' filter='none'/>

I would probably consider using sub-element <filter mode='none'/> or the
mode='manual'.  One example of that design backfiring right now is the
<graphcis> device and it's listen attribute and listen sub-elements.  I'm
working on patches to move also ports into the listen elements and introducing
new types of listen elements and there has to be extra code for backward
compatibility.

Pavel

> 
> (or "manual" as Cole suggested). That way it's still obvious from mode 
> that the traffic will be routed to other networks, and it will be 
> possible to use the filter attribute for other modes (or add other 
> filter settings even for mode='route') in the future. (Validation would 
> be added to make sure that the filter attribute isn't set for any mode 
> other than route). Does that make sense?

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]