From: Liam Helmer (linuxlists_at_thevenue.org)
Date: Tue 30 Mar 2004 - 22:46:14 BST
On Tue, 2004-03-30 at 20:27, Enrico Scholz wrote:
> Ok, I implemented the first part of your suggestion into util-vserver;
> for the second one (iptables), I am not sure how to realize it (especially
> the removal of the rules).
I'll work on that one, 'cause it would be useful for me... I'll see if I
can get something that works OK. Basically, to be useful, it would have
to find ways of being very specific, and it would have to keep track of
the state of each rule, as well as having a way to flush all rules in
case of issues with it's state file, etc.
So, you put the changes in CVS? I'm using my own hacked version of
vserver right now, as I've been playing with some of my own designs.
> The creation of the dummy devices is ugly and has races ('dummy0' is
> used by every 'vserver ... start' instance which conflicts with the
> parallel vserver startup). 'dummy<ctx>' would be ideally but is not
> supported by the kernel.
It is supported by the kernel -> that's what the nameif line that I put
in there does. The only race state is before the dummy0 interface gets
renamed... and that could be solved by having the script do some kind of
interface locking while it changes the name, maybe?
> > That offers better security, because it specifically allows any
> > incoming traffic that may occur, as well as concealing the real IP
> > from the vserver, which can be useful from a security standpoint.
> NAT (different external and internal IPs) is usually a pain when you are
> working with UDP based services (Talk, Kerberos) since the "original" IP
> will be often transmitted in the packet data.
Agreed, there's some things that will simply never work in that
scenario. Like I was saying, it's useful for security, but it's
definitely not simpler for setup. What it is simpler for, however, is
providing host-only services, as well as for dealing with boxes that
have dynamic ips. And, it allows boxes with smaller numbers of IPs to
still use ip layer security without the vserver's interfering with
> I can imagine problems with the hostname checking of SSL too so that the
> external IP must have a PTR record for the vserver's hostname (and vice
I think the best way of dealing with this is either dynamically
generated host records, or a host database (like ldap) that keeps track
> I played a little bit with official IPs for the dummy devices and using
> proxy-arp for it but run into some (unrelated) problems on my testmachine
> (what means 'H' process-state under 2.6?). Currently, I do not have time
> to investigate it further.
Fair. I'll play around with it as my time permits.
Vserver mailing list