Thomas,
On Wed, 08 Aug 2007 03:25:29 +0200
Thomas Weber <l_vserver@mail2news.4t2.com> wrote:
> Am Mittwoch, den 08.08.2007, 01:48 +0200 schrieb Herbert Poetzl:
>
> > > That was like the first thing i've tried. Routing to anything
> > > thats not locally hosted works just fine. But once you try to
> > > reach another vserver on another subnet that happens to be hosted
> > > on the same host it will route internally and not hit the wire at
> > > all - which is bad
> >
> > which is actually quite good, as it avoids flooding
> > the net (even a local network) with unnecessary
> > packets ...
>
> don't try to sell me this as a feature :-)
> If I could opt in/out I'd agree.
That could be an option, I don't see how it would work, though.
> >From inside the vserver you just see your one interface and wouldn't
> expect certain packets to be routed completely different than the
> rest.
>
> > > and actually makes vservers unusable if you want to move vservers
> > > among different hosts.
> >
> > why do you think so? at least exactly this setup
> > works perfectly fine here ...
> >
> > > Firewalling between the vserver clients for example is not
> > > manageable.
You could just leave out the interface and everything would be more or
less the same for filtering (INPUT for both ethX and lo). For NAT and
Mangle it's a bit more complicated, but we use something similar like
our filter and are really happy with that:
We use a two rules in INPUT that put packets in another chain (let's
call it VSERVER) which is filled with data from a database containing
all allowed services by a script (manually called), looks like:
iptables -N VSERVERS
iptables -A INPUT -i eth0 -d <vserver-net> -j VSERVERS
iptables -A INPUT -i lo -d <vserver-net> -j VSERVERS
[rules inserted by script into VSERVERS follow]
We have some more checks, but in principle, it looks like that.
With this design, you can just filter for subnets in the VSERVERS
chain and ignore the incoming interface.
> > you just make the firewall rules for ethX _and_ lo
> > and you are perfectly fine, wherever the guest is
>
> 3 hosts, 2 production, one for development/testing, later maybe more.
> I'd have to manage firewalling rules on the GW and on 3 hosts. The one
> responsible for the GW is not the one responsible for the vserver
> hosts. Managing 3 different systems (GW, production,development) with
> their own firewalling semantics for the same rules on 4+ boxes is
> asking for trouble.
> Don't you think that'd be bad design?
Depends on how you implement it, I'd say.
> > > IDS would be another issue.
> >
> > assuming that IDS stands for Intrusion-Detection System
> > what problem do you see with that?
>
> IDS setup on the GW won't see all vserver-vserver traffic.
> Same with accounting etc.
> In case of an incident when one of the production machines goes down
> and the other hosts all vservers, accounting would show less traffic
> and the IDS wouldn't see anything at all.
I see your point with accounting; just one thing to say anyway: traffic
on lo is _really_ inexpensive anytime, so I probably wouldn't mind
trying to account that.
But about the traffic hitting the wire: IP is routed stuff. Wouldn't
the packets have to have the ARP destination of the localhost, thus not
even hitting the wire when they were sent to the ethernet card?
Imagine an internet router sending packets to itself to a peer
overseas. Would that be good design? Just for an network based IDS to
work? I think it would be more appropriate to consider a different IDS
architecture.
Baltasar
Received on Wed Aug 8 09:30:29 2007