> 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). Cheers, Liam _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
