Am 2019-06-25 14:44, schrieb Lukas Tribus:
Hello Rainer,
On Tue, 25 Jun 2019 at 12:53, <[email protected]> wrote:
Hi,
I tried to read up on this but there are many examples and not all of
them seem "correct".
It's simple: do not content-switch based on SNI. Use the host header
instead. That's it.
OK,
I switched that out.
But it's really only a 2ndary-problem at the moment, because I still get
L7 timeouts on the backends.
The example I provided for the backend is actually not what I wanted to
write.
I was under the assumption that all that was needed to enable sni for
healthchecks on a (http) backend was to say "check-sni"
servername.bla.server
http://cbonte.github.io/haproxy-dconv/1.8/configuration.html#check-sni
backend app_api
mode http
server PROD036 10.200.16.36:443 check check-ssl ssl verify none
force-tlsv12 maxconn 3000 cookie s1 check-sni api.app.intern
server PROD037 10.200.16.37:443 check check-ssl ssl verify none
force-tlsv12 maxconn 3000 cookie s2 check-sni api.app.intern
option httpclose
option forwardfor
option httpchk GET / HTTP/1.1\r\nHost:\ api.app.intern\r\nUser-agent:\
LB-Check-API\r\nConnection:\ close
http-check expect string Hello
http-check disable-on-404
cookie SERVERID insert indirect nocache httponly
balance leastconn
#stick-table type string len 52 size 100k expire 60m
The requests from the healthchecks *do* arrive at the right vhosts on
the backend, there's a code 200 in the logs.
So, I wonder what exactly is timing out for haproxy.
The server on the other end does not accept non-SNI connections, there's
an SSL handshake error if you don't do SNI.
At this point, I feel pretty dumb.
I really appreciate your help.
Best Regards
Rainer
