HAProxy 作為 TCP 負載平衡器（SSL 直通）不起作用？
我在將 HAProxy 設置為 TCP 負載平衡器（第 4 層）時遇到了一些問題，我想听聽您的建議。
我一直在關注網路上的許多指南，我想出了這個配置（在日誌中沒有顯示任何錯誤，它開始很好）：
注意：真實域名被屏蔽
#--------------------------------------------------------------------- # Global settings #--------------------------------------------------------------------- global daemon user haproxy group haproxy log /dev/log local6 debug maxconn 50000 chroot /var/lib/haproxy pidfile /var/run/haproxy.pid #--------------------------------------------------------------------- # common defaults #--------------------------------------------------------------------- defaults mode tcp log global option dontlognull timeout connect 5000 timeout client 50000 timeout server 50000 #--------------------------------------------------------------------- # dedicated stats page #--------------------------------------------------------------------- listen stats mode http bind :22222 stats enable stats uri /haproxy?stats stats realm Haproxy\ Statistics stats auth xxxxxx:xxxxxxxx stats refresh 30s #--------------------------------------------------------------------- # main frontend which proxys to the backends #--------------------------------------------------------------------- frontend main_https_listen bind *:443 mode tcp option tcplog # ------------------------------- # ACLs - SIT # ------------------------------- acl acl_SIT_CI5 req.ssl_sni -i url1.domain.net acl acl_SIT_HR8 req.ssl_sni -i url2.domain.net # ------------------------------- # Conditions - SIT # ------------------------------- use_backend backend_SIT_CI5 if acl_SIT_CI5 use_backend backend_SIT_HR8 if acl_SIT_HR8 #--------------------------------------------------------------------- # Backends #--------------------------------------------------------------------- backend backend_SIT_CI5 mode tcp balance source option ssl-hello-chk server server_SIT_CI5_1 host1.domain.net:443 check server server_SIT_CI5_2 host2.domain.net:443 check backend backend_SIT_HR8 mode tcp balance source option ssl-hello-chk server server_SIT_HR8_1 host1.domain.net:443 check server server_SIT_HR8_2 host2.domain.net:443 check我已將 host1.domain.net 指向我的 haproxy vIP（它後面有一個帶有虛擬 IP 的 keepalived 配置）。
現在當訪問https://url1.domain.net>（甚至是<https://loadbalancerURL但我認為這是正常的）我有一個錯誤這個頁面無法顯示。在高級設置中打開 TLS 1.0、TLS 1.1 和 TLS 1.2 並嘗試再次連接到https://host1.domain.net。
單個 openssl s_client會導致 ssl 握手失敗（無證書 blabla）。
你知道我做錯了什麼嗎？另外，我在收聽 443 時是否需要設置一些證書？（即使我不希望這些證書被解密或者我只希望我的 HAProxy 充當代理）。
我也嘗試啟動調試模式進行日誌記錄，但它沒有顯示任何錯誤（也沒有新日誌）
注意：後端位於防火牆後面，後端與 HAProxy 之間的通信未在 443 上打開（僅從 Haproxy 到後端），是否需要定向？為什麼？
注意2：在haproxy stats中，我可以看到所有後端UP
另外，有沒有辦法知道/檢查基於主機名（SNI）的重定向是否工作正常？（我的印像是連接停留在負載均衡器上並且沒有重定向到後端，這就是我出錯的原因）
haproxy -vv給出：
HA-Proxy version 1.5.18 2016/05/10 Copyright 2000-2016 Willy Tarreau <willy@haproxy.org> Build options : TARGET = linux2628 CPU = generic CC = gcc CFLAGS = -O2 -g -fno-strict-aliasing -DTCP_USER_TIMEOUT=18 OPTIONS = USE_LINUX_TPROXY=1 USE_GETADDRINFO=1 USE_ZLIB=1 USE_REGPARM=1 USE_OPENSSL=1 USE_PCRE=1 Default settings : maxconn = 2000, bufsize = 16384, maxrewrite = 8192, maxpollevents = 200 Encrypted password support via crypt(3): yes Built with zlib version : 1.2.7 Compression algorithms supported : identity, deflate, gzip Built with OpenSSL version : OpenSSL 1.0.2k-fips 26 Jan 2017 Running on OpenSSL version : OpenSSL 1.0.2k-fips 26 Jan 2017 OpenSSL library supports TLS extensions : yes OpenSSL library supports SNI : yes OpenSSL library supports prefer-server-ciphers : yes Built with PCRE version : 8.32 2012-11-30 PCRE library supports JIT : no (USE_PCRE_JIT not set) Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND Available polling systems : epoll : pref=300, test result OK poll : pref=200, test result OK select : pref=150, test result OK Total: 3 (3 usable), will use epoll.
ew，我通過在前端添加它來使它工作（在看了這篇文章之後:)
tcp-request inspect-delay 5s tcp-request content accept if { req_ssl_hello_type 1 }問題是，我不知道這些選項在做什麼……或者為什麼我需要指定它們。這是否意味著 HAProxy 預設行為是拒絕任何東西？
您添加的兩行程式碼確保 HAProxy 在選擇後端之前有足夠的時間讀取 SNI 標頭，並檢查它實際上是 SSL 流量（否則拒絕它）。
您可能還想選擇一個預設後端：
default_backend backend_SIT_CI5對於不匹配的 SNI。