From: Eric Dumazet <hidden> Date: 2015-01-12 16:52:00
On Mon, 2015-01-12 at 17:39 +0100, Patrick Schaaf wrote:
quoted
iptables should have used ifindex, its sad we allowed the substring
quoted
match in first place.
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.
A pure ifindex-during-packet-inspection approach might still work, but
the ruleset must IMO keep the interface names. Maybe register them in
a hash, keyed by name, with values an ifindex or ifindex set (for
wildcard names), plus a reverse mapping from active ifindices to all
places in these hash values where an ifindex has been remembered. On
interface creation / destruction that structure could then be updated,
and active packet filtering rules would refer to (and keep a refcount
on) specific hash elements.
Please do not send html messages : Your reply did not reach the lists.
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.
The ruleset can indeed mention interface names, but the kernel part
really should not care about names, which are a 'human' convenient way
to represent things.
From: Patrick Schaaf <hidden> Date: 2015-01-12 17:19:54
On Monday 12 January 2015 08:51:54 Eric Dumazet wrote:
On Mon, 2015-01-12 at 17:39 +0100, Patrick Schaaf wrote:
quoted
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.
Note that I do fully agree that it's sad that iptables rules waste all that
memory for each and every rule! I remember musing about improving that in
talks with Harald Welte back in the 90ies. A simple match would be perfectly
fine for me. Only having ifindex support, isn't.
best regards
Patrick
From: Patrick McHardy <hidden> Date: 2015-01-12 17:31:43
On 12.01, Patrick Schaaf wrote:
On Monday 12 January 2015 08:51:54 Eric Dumazet wrote:
quoted
On Mon, 2015-01-12 at 17:39 +0100, Patrick Schaaf wrote:
quoted
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...
quoted
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.
From: Patrick Schaaf <hidden> Date: 2015-01-12 17:41:47
On Monday 12 January 2015 17:22:57 Patrick McHardy wrote:
On 12.01, Patrick Schaaf wrote:
quoted
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.
Could be, technically.
Is there devgroup support in libvirt, ifcfg, whatever other distros use for
their static interface configuration? Or, do I again have to write pre/post
scripts to set devgroups? Wouldn't bother me too much nowadays, I've automated
that for ifcfg style stuff in my production environment a year ago, but it's
something an admin must actively manage...
There is other stuff, apart from libvirt, that creates and destroys interfaces
on the fly. From my production environment, there's at least keepalived, which
creates macvlan interfaces on the fly for VRRP VMAC support. I can configure
the name for that, but nothing else, nor can I call a script pre/post for
that. And my iptables rules on that boxen _do_ match specially on these
interfaces.
Gooling a bit around does not immediately turn up any good documentation on it
at all (four year old iproute2 commits, once I give that as a search term
too?). Looks very sketchy (although the fundamental idea is clear to me. I'm
looking through the normal admin practise lens....)
best regards
Patrick