[PATCH] Added so_freebind and so_transparent to the listen directive

[Trygve Vea]

----- 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?


-- 
Trygve Vea
Redpill Linpro AS