[PATCH] Added so_freebind and so_transparent to the listen directive

[Igor Sysoev]

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.


-- 
Igor Sysoev
http://nginx.com