时间戳

首页 > 解决方案 > 基于 sni 的 Haproxy TLS 终止和透传

ssl - 基于 sni 的 Haproxy TLS 终止和透传

问题描述

我对请求有类似的路径：

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

主要思想是对主域名进行 tls passthrough 并将其发送到 cloudfront 而无需 TLS 终止。进入的请求a.mydomain.com应该传递给target_group_a 并且它应该终止 tls。所以我的配置是：

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模式下一切正常。

也许我错过了一些基本的东西，但我坚持了很长时间，也许有人可以帮助我。

标签： sslhaproxysni

解决方案

对于正在遭受或将遭受这种情况的人，请确保您正在使用 gnu 版本的 curl 进行测试（或使用适当的库构建它），因为它不适用于 BSD curl。我的 curl 版本和库

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

推荐阅读