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....@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 _______________________________________________ nginx-devel mailing list nginx-devel@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-devel