upstream (tcp stream mode) doesn't detect connecton failure

[Cecile, Adam]

Hello,


I tried the following configuration but it's still not working as expected. Client browser receive connection closed and the failing server does not seem to get blacklisted...


Any idea ?


Thanks



map $ssl_preread_server_name $name {
    default local_https;
    "" mag_strip_proxy_protocol;
    maintenance.domain.com mag_strip_proxy_protocol;
}


upstream mag {
    server 10.0.0.32:443 max_conns=10 weight=100 max_fails=1 fail_timeout=300;

    server 10.0.0.33:443 max_conns=10 weight=50  max_fails=1 fail_timeout=300;

    server 10.0.0.26:443 max_conns=10 weight=10  max_fails=1 fail_timeout=300 backup;
    server 10.0.0.27:443 max_conns=10 weight=10  max_fails=1 fail_timeout=300 backup;
}

upstream mag_strip_proxy_protocol {
    server 127.0.0.1:8080;
}

upstream local_https {
    server 127.0.0.1:8443;
}


log_format stream_routing '$remote_addr [$time_local] '
                          'with SNI name "$ssl_preread_server_name" '
                          'proxying to "$name" '
                          '$protocol $status $bytes_sent $bytes_received '
                          '$session_time';

log_format upstream_routing '$proxy_protocol_addr [$time_local] '
                            'proxying to "mag":$upstream_addr '
                            '$protocol $status $bytes_sent $bytes_received '
                            '$session_time';


server {
    listen 443;
    ssl_preread on;
    proxy_pass $name;
    proxy_protocol on;
    access_log /var/log/nginx/stream_443.log stream_routing;
}

server {
    listen 8080 proxy_protocol;
    proxy_pass mag;
    access_log /var/log/nginx/mag.log upstream_routing;
}


________________________________
De : nginx <nginx-bounces at nginx.org> de la part de Adam Cecile <adam.cecile at hitec.lu>
Envoyé : mercredi 10 janvier 2018 20:02:59
À : nginx at nginx.org; Maxim Dounin
Objet : Re: upstream (tcp stream mode) doesn't detect connecton failure

[This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at http://aka.ms/LearnAboutSpoofing]

On 01/10/2018 07:58 PM, Maxim Dounin wrote:
> Hello!
>
> On Wed, Jan 10, 2018 at 07:18:36PM +0100, Adam Cecile wrote:
>
> [...]
>
>>> Ok, so you use multiple proxy layers to be able to combine
>>> backends which support/need PROXY protocol and ones which do not,
>>> right?  This looks like a valid reason, as "proxy_protocol" is
>>> either on or off in a particular server.
>> Yes exactly !
>>
>> Aim of this setup is to do SNI routing to TCP endpoints (with failover)
>> or HTTPS virtual hosts.
>>> If you want nginx to switch to a different backend while
>>> maintaining two proxy layers, consider moving balancing to the
>>> second layer instead.  This way balancing will happen where
>>> connection errors can be seen, and so nginx will be able to switch
>>> to a different server on errors.
>> Could you be more specific and show me how to do this with my current
>> configuration ? I'm a bit lost...
> At the first level, differentiate between hosts based on
> $ssl_preread_server_name.  Proxy to either "local_https" or to a
> second-level server, say 8080.  On the second level server, proxy
> to an upstream group with servers you want to balance.  Example
> configuration (completely untested):
>
>      map $ssl_preread_server_name $name {
>          default                  local_https;
>          ""                       second;
>          pub.domain.com           second;
>      }
>
>      upstream local_https {
>          server 127.0.0.1:8443;
>      }
>
>      upstream second {
>          server 127.0.0.1:8080;
>      }
>
>      upstream u {
>          server 10.0.0.1:443;
>          server 10.0.0.2:443;
>      }
>
>      server {
>          listen 443;
>          ssl_preread on;
>          proxy_pass $name;
>          proxy_protocol on;
>      }
>
>      server {
>          listen 127.0.0.1:8080 proxy_protocol;
>          proxy_pass u;
>      }
>
> Logging and timeouts omitted for clarity.
>
Very nice !

I'll give a try tomorrow morning and let you know, thanks.

_______________________________________________
nginx mailing list
nginx at nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20180115/16dab43d/attachment.html>