У меня аналогичный путь для запросов:
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. Итак, моя конфигурация для этого:
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
Основная запись прошла успешно, и я получаю завершение SSL CloudFront, и все в порядке, но не для a.mydomain.com
.
Также я пытался посмотреть, что SNI Haproxy - это захват, но я получил только capture0: -
в журналах. Мне понравилось (сразу после tcp inspect line)
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
, все работает нормально.
Может быть, я что-то пропускаю c или нет, но я застрял на нем целую вечность и, может быть, кто-нибудь сможет мне помочь.