基于sni的Haproxy TLS端接和通过。

Question

我有类似的请求路径。

client mydomain.com -> nlb:443 -> haproxy -> cloudfront
client a.mydomain.com -> nlb:443 -> haproxy -> target_group_a

主要的想法是为主域名做tls passthrough，然后在没有TLS终止的情况下发送至云端。请求进入 a.mydomain.com 应运而生 target_group_a 和 它应该终止tls。因此，我的配置是： - 主记录成功通过，我得到了 CloudFront SSL 终止，一切正常。

frontend main
    bind *:443
    mode tcp
    option tcplog
    log global

    tcp-request inspect-delay 5s

    acl is_main req_ssl_sni -i "${pDomainName}"
    acl is_a req_ssl_sni -m beg "a"

    tcp-request content accept if { req_ssl_hello_type 1 }

    use_backend main if is_main
    use_backend a if is_a

backend main
    mode tcp
    option ssl-hello-chk
    server cloudfront "${pCloudFrontUrl}:443" check resolvers aws

backend a
    mode tcp
    server local 127.0.0.1:9666 send-proxy

frontend a
    bind *:9666 ssl crt server.pem ca-file ca.pem verify required accept-proxy
    mode http

    default_backend proxy_a

backend proxy_a
    mode http
    server elb "${pServer}:80" check resolvers aws

主记录成功通过，CloudFront的SSL终止，一切都正常，但对我来说 a.mydomain.com.

此外，我试图观看SNI Haproxy是什么捕捉，但我得到的只有 capture0: - 在日志中。我很喜欢（就在tcp检查行之后）。

tcp-request content capture req_ssl_sni len 15
log-format "capture0: %[capture.req.hdr(0)]"

很奇怪，因为路由是有效的。

我尝试了很多可能性... ... 现在我得到的是 SSL peer handshake failed, the server most likely requires a client certificate to connect 错。不过 如果我真的听了前端 a 在另一个港口和 http 模式，一切都很好。

也许我错过了一些基本的东西，或者没有，但我卡在这上面好久了，也许有人能帮助我。

Answer 1

对于正在遭受或将要遭受这种情况的人来说，只要确定你是用gnu版本的curl进行测试（或者用正确的库来构建它），因为它对我来说在BSD的curl中是行不通的。我的 curl 版本和 libs

curl 7.66.0 (x86_64-apple-darwin17.7.0) libcurl/7.66.0 SecureTransport zlib/1.2.11
Release-Date: 2019-09-11
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IPv6 Largefile libz NTLM NTLM_WB SSL UnixSockets