Re: Select chain from set?

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

 



В Вто, 28/04/2009 в 14:27 +0200, Martin Millnert пишет:
> On Tue, 2009-04-28 at 11:21 +0200, Oskar Berggren wrote:
> > Hello,
> > 
> > is it possible to have iptables query a set of some sort to quickly
> > look up a chain to jump to for a specific packet?
> > 
> > For example the set would contain a mapping from ip-address ->
> > chain-name. Then the destination address is looked up in the set and
> > iptables would jump to the specified chain.
> > 
> > Is it possible, or how difficult would it be to implement something
> > like this? I'd imagine it would be implemented as a target, that would
> > have the ability to "redirect" to another target, which would be a
> > chain.
> > 
> > 
> > /Oskar
> 
> Hi Oskar,
> 
> to my knowledge there is no current such functionality. But I second the
> usefulness of such a function. It would be especially useful to replace
> traditional "match trees" of today, to reach down to a per
> customer-chain for inwards and outwards matching.
> 
> It seems like it would be beneficial to let it be very similar to the
> ipset of today, in that you would be very well of in having multiple
> such sets to jump to as a target.  Thus you could easily use normal
> matchings to decide whether or not to perform this sort of look-up.
>   It would be useful if each such set would contain the possibility to
> match on either source address/netmask and destination address/netmask.

This functionality is more related to a special target than ipset
feature. -j CLASSIFY does half of the work and as to me is the most
ideal to be taken as the base for the new target.

> This all begs the question on how effective some tree structure with -g
> is implemented, to figure out how much of a performance benefit such a
> new target would have over a treelike chain structure.  

If we compare many linear -g with just one function gettarget(ip) the
different is many/one. Tree-like -g structure would save most
comparitions, but is hard to write for every task. Function-like target
is real fast and fully automatic, the only disadvantage is in fact it
doesn't exist :)

> It would indeed be useful to have it all as a single target however,
> save a lot of rules and also be much more readable.

Also, something is telling me that if the deal is comming to write new
target it is good idea to review the whole task as it probably can be
solved in a more effective way.

-- 
Покотиленко Костик <casper@xxxxxxxxxxxx>

--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux