From: Jacques Gelinas (jack_at_solucorp.qc.ca)
Date: Wed 04 Dec 2002 - 05:08:21 GMT
On Tue, 3 Dec 2002 22:49:02 -0500, John Goerzen wrote
> In article <20021203153204.dbfae2a56f4c_at_remtk.solucorp.qc.ca>, Jacques Gelinas wrote:
> >> 2. All packets going out of the vserver have the source IP address
> >> set to the first IPROOT address specified, regardless of which interface
> >> they're going to.
> >
> > Yes, this is how it works. The vserver is forced to use the first IP in IPROOT
> > to communicate. It is allowed to bind before connecting, but it must select
> > one IP in its list.
>
> When you say "it is allowed", do you mean "an application?"
Yes. An application making a connection is allowed to use bind before the connect
to select the source IP and the source port. Otherwise, it is selected on the fly
by connect() based on the routing table.
> > It would be possible for the kernel to select on IP in the IPROOT based on
> > netmask and find the closest to the target address, so if you kind of bind
>
> Hmm, isn't this how it normally works, using the routing tables? If so,
> can't vserver just use that, and therefore just do the Right Thing?
Yes, this is the idea. But a vserver is tied to a precise IP list and is not allowed to
use anything else. So what will be found using the routing table may or may not
be usable, in which case, the vserver will default to use its first IPROOT address.
> For instance, on a machine with two ethernet interfaces, if I telnet to
> 192.168.1.1 it will set the source address on the packets to 192.168.1.2,
> and if I telnet to 10.0.1.1, it will set the source address to 10.0.1.2.
> There's nothing special that I have to do, nor the applications -- lynx,
> mozilla, telnet, ftp, whatever -- they'll just get it right.
Yes. Again, we are closing the gap and getting the proper semantic.
> > This sounds like a valid enhancement. This would also solved the case where
> > one vserver has two public IP and talks to different places using the two
> > interface. Currently, it always uses the first IP unless told otherwise.
>
> Exactly. This is precisely the situation I have; sorry if I've not
> explained it well.
Once I have ctx-15 and the bind(any) fixed, I will work on ctx-16 with
the special support for private loopback and this solution (intelligent selection
of the source IP).
---------------------------------------------------------
Jacques Gelinas <jack_at_solucorp.qc.ca>
vserver: run general purpose virtual servers on one box, full speed!
http://www.solucorp.qc.ca/miscprj/s_context.hc