----- 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?
--
Trygve Vea
Redpill Linpro AS
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
