[Users] Suggestion for a new parameter: PRIMARY_IP

[Benoit Branciard]

Marcin Owsiany a écrit :
> On Wed, Jan 07, 2009 at 12:41:39PM +0100, Dietmar Maurer wrote:
>>> Oh, just about anything that does: socket(); connect(); (without a
>>> bind() in between), for example default usage of wget, telnet, ssh..
>>> any
>>> TCP client really.
>> If you have a server using several IP addresses, the client IP address
>> used by tcp client is undefined.
> 
> Yes, it seems so, in the general case. However I would be comfortable
> enough with the current-Linux-specific behaviour.

Since the official behaviour of choosing the local bind address is 
undefined, you can't simply trust the way it is currently accomplished 
in linux kernel. It may change without notice, and that would not be 
portable.

> 
>> But what application depends on the client IP used?
> 
> Anything that needs to connect out to the public Internet. This is
> because when it picks an RFC1918 address, the connection cannot be
> established when there is no NAT employed.
> 

I agree that not being able to define a "default source address" is a 
pain, especially when dealing with multiple local IPv6 addresses.

But in your case (internet access vs. private net access), can't you 
manage to direct traffic with adequate routes ?

I believe your RFC1918 addresses only give access to private networks, 
whereas the other(s) give access to internet. So you just need to have 
your default route defined on the public address only, and a 
limited-reach route (say 192.168.0.0/16) on the other addresses. Or if 
you have only one private subnet, no route at all.

Unless I missed something from your setup...

>> Anyways, usually you can specify the bind address:
>>
>> wget: --bind-address=ADDRESS 
>> telnet: -b address
> 
> Yes, but not in all cases.
> 
> Look, I do know there are other ways around this, including carefully
> configuring the applications, NATing, proxying, even site-specific
> tweaking the OpenVZ setup scripts to do some crazy mangling my of
> interfaces.
> 
> However all of these have downsides, and the option I suggested seemed
> to me to give the most "bang for the buck".
> 


-- 
Ce message a ete verifie par MailScanner
pour des virus ou des polluriels et rien de
suspect n'a ete trouve.