From: Christian Jaeger (christian.jaeger_at_ethlife.ethz.ch)
Date: Mon 16 Aug 2004 - 16:36:43 BST
At 12:49 Uhr +0200 16.08.2004, Herbert Poetzl wrote:
> > So, the net effect is: If you configure your vservers to use two ip's
>> (for example: one for "localhost" purposes, and a second for public
>
>local host 'purposes' is a bad idea anyway,
>because linux-vserver networking does some
>stuff to replace the local '127.0.0.1' by
>the primary address (which makes using lo
>completely obsolete)
I'm putting "localhost" in into quotes since the localhost string in
/etc/hosts is mapped to that ip.
I've already learned that vserver has this 127.0.0.1 => primary ip mapping.
This suggests that the "locahost" ip (something like 10.0.1.1) should
be the primary address - then if some library has 127.0.0.1 hardcoded
it is translated by the kernel to the primay address which is then
the correct 10.0.1.1 in my example.
> > access), and use UDP port forwarding from the NAT'ing host, and be so
> > unlucky that the order how the two ip's are fed to chbind during the
>> vserver startup is that the first ip is *not* the target ip of the
>> forwarding, you're 'sol'. If the utils (I'm currently using alpha
>> utils 0.29.211) would provide a way to tell the order of the ip's,
>> one could at least work around the problem once being aware of it.
>>
>> BTW it does not matter whether you additionally have SNAT rules for
>> outgoing traffic or not.
>
>this is expected behaviour because:
>
> - the 'first' ip associated with a vserver
> is considered the 'primary' ip, used for
> outgoing traffic, if the source ip can
> no be determined
>
> - if you would have copied the output from
> the netcat -v option, everybody would see
> that the netcat without -s binds to
> 0.0.0.0 [any]
>
> - current networking (not ngn once finished)
> can not allow to bind to arbitrary IPs,
> so it _has_ to decide for one (the primary)
> in this case ...
After some discussion with Herbert on the IRC, I've learned a bit more:
- The issue has been brought up by Herbert already half a year ago:
http://archives.linux-vserver.org/200311/0470.html
- What is the implementation today? Suggestion b) from the above mail
has never been implemented. Today, as Herbert says, <<(the kernel)
does a good efford on guessing what the right ip should be; it does
this mainly based on routing decisions; unfortunately udp binds to
0.0.0.0 do not contain any routing information>>.
That explains why TCP port forwarding doesn't show any problem.
The solution I'm using now is to use the "localhost" ip of the
vservers as target ip in port forwardings. This way (leaving the
order of the ip's as is, with the "localhost" as the primary),
127.0.0.1 is still correctly mapped.
Christian.
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver