On 12.01, Patrick Schaaf wrote: > On Monday 12 January 2015 08:51:54 Eric Dumazet wrote: > > On Mon, 2015-01-12 at 17:39 +0100, Patrick Schaaf wrote: > > > > > > Not to comment on the ifalias thing, which I think is unneccessary, > > > too, but matching on interface names instead of only ifindex, is > > > definitely needed, so that one can establish a full ruleset before > > > interfaces even exist. That's good practise at boottime, but also > > > needed for dynamic interface creation during runtime. > > > > Please do not send html messages : Your reply did not reach the lists. > > Sigh. Sorry... > > > Then, all you mention could have been solved by proper userspace > > support. > > > > Every time you add an interface or change device name, you could change > > firewalls rules if needed. Nothing shocking here. > > That is totally impractical, IMO. > > Interfaces come and go through many different actions. There's the admin > downing and upping stuff like bridges or bonds. There's stuff like libvirt / > KVM / qemu creating and destroying interfaces. In all these cases, in my > practise, I give the interfaces useful names to that I can prefix-match them > in iptables rules. > > Dynamically modifying the ruleset for each such creation and destruction, > would be a huge burden. The base ruleset would need suitable "hooks" where > these rules were inserted (ordering matters!). The addition would hardly be > atomic (with traditional iptables, unless done by generating a whole new > ruleset and restoring). The programs (e.g. libvirt) would need to be able to > call out to these specially crafted rule generator scripts. The admin would > need to add them as pre/post actions to their static (manual) interface > configuration. Loading and looking at the ruleset before bringing up the > interface would be impossible. devgroups seem like the best solution for this. -- 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
