[PATCH] Added so_freebind and so_transparent to the listen directive

[Trygve Vea]

----- Opprinnelig melding -----
> 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;

Ah, thank you.

This seems to do the trick.

I spoke with a colleague about this, and he pointed out that this does not cover the use case where you do NOT want to listen on *:443 (which the patch does cover).  However, that is not something I need.

Feel free to both ignore and merge the patch; if you would like to merge it with some modifications, feel free to tell me what to change - and I'd be happy to make them.


Regards
-- 
Trygve Vea
Redpill Linpro AS