[PATCH] Added so_freebind and so_transparent to the listen directive

[Igor Sysoev]

On Mar 28, 2014, at 14:45 , Trygve Vea wrote:

> ----- Opprinnelig melding -----
>> On Mar 27, 2014, at 22:14 , Trygve Vea wrote:
>> 
>>> ----- Opprinnelig melding -----
>>>> Hello!
>>> 
>>> Hello!
>>> 
>>>> On Thu, Mar 27, 2014 at 04:34:37PM +0100, Trygve Vea wrote:
>>>>> # HG changeset patch
>>>>> # User Trygve Vea <trygve.vea at redpill-linpro.com>
>>>>> # Date 1395933815 -3600
>>>>> #      Thu Mar 27 16:23:35 2014 +0100
>>>>> # Node ID 13e6a37c2f57443b0d5dd0abce8d9d4ab00e31e3
>>>>> # Parent  2411d4b5be2ca690a5a00a1d8ad96ff69a00317f
>>>>> Added so_freebind and so_transparent to the listen directive
>>>>> 
>>>>> This solves a Linux/IPv6-specific problem.
>>>>> 
>>>>> To be able to listen to an IPv6 address that is not yet available on the
>>>>> host,
>>>>> one need to use the IP_FREEBIND and IP_TRANSPARENT socket options.
>>>>> 
>>>>> The use case in question is for a failover setup with several service-
>>>>> addresses in a IPv6-only environment.
>>>>> 
>>>>> IPv4 has a sysctl available (ip_nonlocal_bind), which is not available
>>>>> for
>>>>> IPv6 - thus making these patches necessary.
>>>> 
>>>> Isn't bind on INADDR_ANY/IN6ADDR_ANY works for you?
>>>> 
>>>> It is expected to work fine and allows to accept connections on
>>>> all addresses currently available on a host without any
>>>> non-portable tricks.
>>> ----- Opprinnelig melding -----
>>>>> IPv4 has a sysctl available (ip_nonlocal_bind), which is not available
>>>>> for
>>>>> IPv6 - thus making these patches necessary.
>>>> 
>>>> Isn't bind on INADDR_ANY/IN6ADDR_ANY works for you?
>>>> 
>>>> It is expected to work fine and allows to accept connections on
>>>> all addresses currently available on a host without any
>>>> non-portable tricks.
>>> 
>>> That would be sufficient for HTTP - and my preferred option, since we can
>>> handle routing after the end-user have provided us with the Host-header,
>>> and thus know where to send the user.
>>> 
>>> However, with SSL enabled - while we have end users that still do not
>>> support SNI
>>> (http://en.wikipedia.org/wiki/Server_Name_Indication#Client_side), and
>>> using multiple SSL-certificates, for multiple applications - we will need
>>> to bind each certificate to its own dedicated service address.  From here,
>>> we can do routing / forward the connections further down the stack.
>> 
>> This can be handled with following configuration:
>> 
>> server {
>>   listen  *:443                     ssl;
>>   listen  any.non.existent.ip1:443  ssl;
>>   ssl_certificate ...
>>   ...
>> }
>> 
>> 
>> server {
>>   listen  any.non.existent.ip2:443  ssl;
>>   ssl_certificate ...
>>   ...
>> }
>> 
>> nginx will bind only to *:443 and then will call getsockname() to get real
>> local address.
> 
> Hm, are you sure?
> 
> I haven't been able to succeed - as this was what I was initially attempting to do.
> 
> server {
>  listen       *:443 ssl;
> 
>  listen [2a02:c0:209::F1]:443 ssl;
> 
> 
> nginx: [emerg] bind() to [2a02:c0:209::f1]:443 failed (99: Cannot assign requested address)
> 
> 
> Are there any additional requirements to make this work?

You need to add also:
   listen  [::]:443   ssl;


-- 
Igor Sysoev
http://nginx.com