Re: [LARTC] "Bug" in howto 4.2.1 Split access and other advice

[Ard van Breemen <ard@telegraafnet.nl>]

On Fri, Jul 05, 2002 at 08:13:53PM +0200, Arthur van Leeuwen wrote:
> On Fri, 5 Jul 2002, Ard van Breemen wrote:
> > http://lartc.org/HOWTO//cvs/2.4routing/html/lartc.rpdb.multiple-links.html
> > I am not sure who wrote this part or what it was based upon, but
> > since I am working a lot longer now with ip rules, I think I want
> > to add some stuff:
> The stuff that is in the HOWTO was designed and tested back in 1999.
> Oh, and I am the author. :)
Ok... I would have written the same example, so I was not sure on
who's experience it was based upon. It was not meant as a "the
author is stupid", but more like "do I know the author...".
I've told this example also to many people (before I even heard
about the lartc. I usually do not read HOWTO's or stuff like
that), because it was the same setup I was using at home. But as
experience evolves, I now know it is not ok.
> > The example 4.2.1 refers to the picture above, and does a plain
> > ip rule add from .... table ....
> > The problem with the exampe is that if you connect from the
> > inside (local network) to your if1 ip or if2 ip, that in this
> > example the replies to the local-network are going out if1 or
> > if2... That is not what you want.
> 
> True. That is indeed a bug. Never saw it in actual practice though: you
> *should*not* connect to the external IP addresses of your router from
> the internal network... for various security reasons and such. But you are
> right.
Hmmmm, to the linux kernel, an IP address is not really interface
bound, so everybody should be able to connect to any ip address
on the router. My filters are usually only based on interface instead
of ip addresses. Usually rp_filter will do the remaining work.
So I see no harm in connecting to the "external" ip addressess.
(Quoted, since they are not really external or completely bound to an
interface, you can always arp for them on another interface...,
eh..., if rp_filter allows that of-course.)
> 
> [snip]
> 
> Whoa, that was large. I'm not sure I entirely follow you though.
> The *point* of the extra routing tables is that they take precedence
> over the default routing tables...
-----------^^^^^^^
That's exactly my point: default routes make the kernel go "hey I
found the route, so I do not have to search anymore", so they
should be *after* the normal routing, but *before* the big
catchall default route.
Anything else not being a default route, should of course go
before the normal routing.

I like the way Julian describes it:
"        Or more correctly, to specify the path between
each two subnets, the more specific rules and routes before the
others."

So, eventually we will get a good description and a good
practices guide.

-- 
begin  ILOVEYOU.VBS 666
<ard@telegraafnet.nl> Telegraaf Elektronische Media
Real geeks don't get viruses
end
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/