From: Enrico Scholz (enrico.scholz_at_informatik.tu-chemnitz.de)
Date: Tue 30 Mar 2004 - 21:27:11 BST
linuxlists_at_thevenue.org (Liam Helmer) writes:
> One possible scenario is the following. I'll work on a patch for
> vserver-utils if anyone's interested in this:
Ok, I implemented the first part of your suggestion into util-vserver[1];
for the second one (iptables), I am not sure how to realize it (especially
the removal of the rules).
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.
> 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.
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
versa).
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.
Enrico
Footnotes:
[1] http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/scripts/vserver.functions.diff?r1=1.26&r2=1.28
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver