Amin Azez wrote:
* Patrick McHardy wrote, On 27/11/07 00:19:
The version Jan posted doesn't match on mac but on IP address.
It should be refusing to match mac if the ip's do match in the --gateway
match, because if the IP matches then the host is being addressed
directly and not as a gateway.
That's why it also checks IP.
+ if (memcmp(&info->gateway_v4, &neigh->primary_key, tbl->key_len) != 0)
+ return false;
It checks mac as the primary key of the neighbour table.
The primary key is the IP address.
So I still don't see the point. You have a route with a gateway
address, which you can match on. The fact that some MAC spoofing
is done seems irrelevant.
Take the case of a numbered layer 2 bridge. The bridged packets are not
routed by the bridge, but you might still want to snat or dnat some
certain packets to a certain gateway. I know networks that do this.
(Maybe the nat helpers are better on the bridge than on the nat-ing
router or something). Hey - thats what brouters are for.
If there is mac spoofing where you are not routing, then it helps to
identify the box doing the spoofing; and it is best to do so by IP
address which in such cases usually identifies the role.
For example, if you have a win2K box doing internet connection sharing
on an ISDN dialup to another office on the same subnet, the box doing
the sharing (which may change) will generally have the same IP address.
There is no route to that box, but the xt_gateway match still has a use
here to recognize traffic that will be going over the ISDN link and may
want to be marked for shaping.
I don't even see how that would work, if the box is doing mac spoofing
then you have an arp entry for every IP behind the ISDN link. So you
have the choice of adding n "gateway" rules or n destination IP rules.
In case of destination IP rules it might at least be able to use masks.
If I'm still not getting you (which might be possible since my brain is
not really up to 100% because of sickness), just make an example using
the actual rules you'd use.
Since we already have a crapload of stuff in the kernel, I prefer to
only add things that extend the expressiveness of iptables to things
not possible otherwise. Mere simplifications can be done in userspace
IMO.
This mere simplification is, in user-space, (as explained above) a
complication, and doubly so because there are no generally available
routing table manipulation tools to match iptables-save/iptables-restore.
However, I think then by your criteria above you will accept xt_gateway
because it extends the expressiveness of iptables to do things not
possible by realm (detection of gateways on a box that did not route)
and to do other things which are possible, but in (as you say) a simpler
way (albeit not in userspace), and by my judgement, a more expressive way.
I think I met your criteria.... :-)
Possibly, but I didn't get it :) So please explain it using an example.
A completely different issue is that the neighbour entry is created
after a packet has traversed all netfilter hooks, so you might set up
incorrect NAT mappings (in your example). How do you deal with that?
-
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
