About this list Date view Thread view Subject view Author view Attachment view

From: Liam Helmer (linuxlists_at_thevenue.org)
Date: Thu 29 Apr 2004 - 19:07:22 BST

> hmm, I do not see a problem with implementing a
> netfilter for xid (on outgoing packets), if you
> (or somebody else) volunteers to do the userspace
> part (for netfilter) to configure it ...

I'm up for it. We'd have to all decide on what people want it to do,
exactly, but that's cool. Something along the lines of:

Enforcing routing of outgoing packets to always use the vservers's
source IP(s)
Enforcing routing so that a vserver will only use certain interfaces for
routing outgoing packets
Allowing NAT of vserver packets when going out certain interfaces
Allowing bandwidth control of outgoing vserver bandwidth

This would have to play nice with firewall and network code naturally.
I've implemented something to play nice with gentoo network and
shorewall, some of which is portable.

> this is not an option for incoming packets though
> as you cannot determine the target context, until
> the receiving socket is found (which is too late
> for netfilter stuff ;)

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).


Vserver mailing list

About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Thu 29 Apr 2004 - 19:07:51 BST by hypermail 2.1.3