Date: Tue 01 Oct 2002 - 22:47:27 BST
Every once in a while there is a question about a per vserver loopback
But two things seem to be mixed up:
1. a feature to be able to connect to 127.0.0.1 within a vserver
but not actually connecting to localhost on the *real* machine.
Thus there could be two different processes listening on the same
port but within different vservers.
2. a feature to securly access the loopback device within a vserver
but the loopback address must not necessarily be on of 127.*.*.*
(i.e the IP dedicated to the vserver).
I personally do not need more than the 2nd option.
Up till now the only way to get this up and running is to have the
*real* machine running chbind'. So that processes like ssh do not listen
to 0.0.0.0 but instead to something like 192.168.1.1.
Thus you could define a firewall ruleset:
iptables -P INPUT DROP
iptables -A INPUT -i lo -s VSERVERIP -d VSERVERIP -j ACCEPT
iptables -A OUTPUT -o lo -s VSERVERIP -d VSERVERIP -j ACCEPT
iptables -A INPUT -i lo -s REALIP -d REALIP -j ACCEPT
iptables -A OUTPUT -o lo -s REALIP -d REALIP -j ACCEPT
Perhaps you could do some tweaking with the new multi-ip support
(haven't thought about it yet).
Letting the real machine run chbind' is not always that easy.
e.g. portmap has to be listen to 0.0.0.0 (right ?) and KDE's Cop-Server
seems to have difficulties if it cannot connect to 127.0.0.1.
Could another solution be to faciliate tun/tap ?
This feature is rarely documented and I don't really know if it might
help but I've seen it once used by User-Mode-Linux.
Yet another solution I thought about is to write an iptables extension,
which would match any packet that is destined to a port *listening* on
another address then the specified one.
iptables -A INPUT -m dstportlistenip -i lo -s VSERVERIP \
--dportlistenip ! VSERVERIP -j DROP
Once again, the dportlistenip is the IP given by netstat -ant next to
the listening port.
Could this be a solution to option no. 2 ?
-- Gerrit Hoetzel http://www.hzhome.mine.nu