From: Liam Helmer (linuxlists_at_thevenue.org)
Date: Fri 30 Apr 2004 - 03:27:03 BST
> > Enforcing routing of outgoing packets to always use the vservers's
> > source IP(s)
> this is something which will be solved by the next
> step when I clean up the network implementation of
> vserver (and should already work partially), so I
> think this should not require special rules ...
No... but having it's own routing table to look at is useful. If the
only routing table that it has lists a source IP different from it's
own, that's where it can start to get confused (I've seen it do this).
Implementing this, on the other hand, might get tricky ;)
> > Enforcing routing so that a vserver will only use certain
> > interfaces for routing outgoing packets
> this can already be done by using a separate routing
> table for each vserver (~250 are available) and
> assigning an appropriate rule to map ip ranges to
> the right table ...
... which was how I was planning on doing it. You were asking what the
userspace tools could do with it, so I was presenting that idea.
I think that both of these bits amount to "carrot" type ip enforcement,
where a lot of the vserver enforcement is "stick" type ip enforcement.
This gives routing tables stating definitively how it should do certain
packet operations, instead of just shutting down certain options, and
letting it cope.
> > Allowing NAT of vserver packets when going out certain interfaces
> > Allowing bandwidth control of outgoing vserver bandwidth
> and special accounting rules (by traffic classes) would
> be good candidates for such a tagging ...
Yes, traffic filtering for different types of traffic. Of course, that's
a whole other ball of wax too: it's potentially a very complex system.
> > Actually, there is a way of doing this with the netfilter connmark
> > extension (newer netfilter patch). What you do is mark the connection
> > (not the packet) when the vserver host sends out it's first ack packet:
> > you can identify which context it's coming from at that point. So, no,
> > you can't identify the actual incoming connection, but you can still
> > apply traffic shaping and routing on a per vserver basis that way.
> > This would apply to any protocol supported by conntrack: ftp, http,
> > voip, etc. So, if you can add context id match support to netfilter, I
> > think I should be able to get netfilter to mark the connection, even
> > with incoming packets (on hosts that support this).
> I'm not convinced that connection tracking is such
> a good idear, but I guess we could do something different
> for incoming packets: we could add a per network context
> flag to limit a context to a certain tag, this way a
> netfilter ruleset could decide which packets reach a
> vserver and which don't ... without any need for a
> conenction ...
Hmm, OK. So, you're thinking of reversing this process then: I mark the
packet as being for a vserver, and only then is it able to see that
packet. I think I remember talking to you about the current kernel code
doing an inspection of each packet: this might make that requirement
easier. Basically, IMHO, anywhere you can use netfilter to make your
life easier is probably a good thing.
I'm not sure why you're quite so leery to connection tracking though. I
assume you're thinking of 200 vserver cases where each is receiving 10
web-hits/minute. In my experience, it scales pretty well, but it does
depend on implementation. It takes 350byte of RAM per connection, which
looks like it'll take up ~1MB of RAM in the case I was just describing
(and assuming that the connections are all active simultaneously, and a
few extra database connections, etc, on the side). And the performance
hit is negligible. You'll definitely find that there's more of a CPU hit
in doing bandwidth management than connection tracking under heavy load
(I know, I've done both). The advantage of this is that you're not
reliant on netfilter when you don't want to be: you can turn it off
entirely, without sacrificing security. But, if you want to track
everything, you can. (Disclaimer -> I still have to play with the
conntrack moduleto make sure it'll work for this case...)
Anyways, I'm rambling a little: I'm off to get some dinner.
Cheers,
Liam
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver