Укрощение строптивого HAPROXY. Работаем ssl <—> ssl с генерацией сертификатов отдельно на каждом сервере

В рамках данного туториала настроим реверс прокси для работы наших сайтов в прозрачном режиме за 10 минут. Поехали.

Мною была поставлена задача что бы на моем сервере под руководством Proxmox с пулом сайтов работала без проблем прозрачная маршрутизация между посетителем и конечным сайтом. Т.к. в инете полно мануалов по базовой настройке Haproxy я столкнулся с проблемой что 99% этих статей описывают работ прокси сервера в режиме терминации а дальше информация идет по не защищенному варианту (от прокси до конечной ВМ). Меня это не устроило и я начал искать по крупицам информацию в сети. К сожалению в нашем русскоязычном сегменте ее мало (читай нет) пришлось шерстить буржуйский сегмент. Конечный результат предлагаю вашему вниманию, думаю кому ни будь он точно сгодится.

global log /dev/log    local0 log /dev/log    local1 notice stats socket /haproxy-admin.sock mode 660 level admin stats timeout 30s daemon defaults maxconn 2000 mode http         log global option dontlognull # bind *:443 ssl crt . option http-server-close timeout http-request 10s timeout connect         5000 timeout client          50000 timeout server         50000 frontend stats bind *:5000 stats enable stats uri /stats stats refresh 10s stats auth admin:mysupersecretpassword #поменяйте на свой пароль

Блок отвечающий за работу ssl на ssl

frontend env_ssl_frontend bind *:443 mode tcp option tcplog tcp-request inspect-delay 10s tcp-request content accept if { req_ssl_hello_type 1 } use_backend bk_app1 if { req.ssl_sni -m end site1.ru } use_backend bk_app2 if { req.ssl_sni -m end counter.site1.ru } use_backend bk_app3 if { req.ssl_sni -m end site2.com }   use_backend bk_app4 if { req.ssl_sni -m end site3.msk.ru } use_backend bk_app5 if { req.ssl_sni -m end site4.ru } use_backend bk_app6 if { req.ssl_sni -m end site5.msk.ru }  backend bk_app1 mode tcp balance leastconn option tcp-check  server main 192.168.1.26:443 send-proxy check  backend bk_app2 mode tcp balance leastconn option tcp-check server main 192.168.1.38:443 send-proxy check  backend bk_app3 mode tcp balance leastconn option tcp-check server main 192.168.1.37:443 send-proxy check  backend bk_app4 mode tcp balance leastconn option tcp-check server main 192.168.1.100:443 check  backend bk_app5 mode tcp balance leastconn option tcp-check server main 192.168.1.31:443 send-proxy check  backend bk_app6 balance leastconn mode tcp option tcp-check server main 192.168.1.200:443 check

Блок отвечающий за работу сайтов на 80 порту

frontend public         bind *:80          # бок сайтов         acl host_subdomain1 hdr(host) -i site1.ru          acl host_subdomain2 hdr(host) -i counter.site1.ru         acl host_subdomain3 hdr(host) -i site2.com         acl host_subdomain4 hdr(host) -i site3.msk.ru         acl host_subdomain5 hdr(host) -i site4.ru         acl host_subdomain6 hdr(host) -i site5.msk.ru         ## блок acl          use_backend subdomain1 if host_subdomain1         use_backend subdomain2 if host_subdomain2         use_backend subdomain3 if host_subdomain3         use_backend subdomain4 if host_subdomain4         use_backend subdomain5 if host_subdomain5         use_backend subdomain6 if host_subdomain6  backend subdomain1         option httpclose         option forwardfor         cookie JSESSIONID prefix         server subdomain-1 192.168.1.26:80 check  backend subdomain2         option httpclose         option forwardfor         cookie JSESSIONID prefix         server subdomain-2 192.168.1.37:80 check  backend subdomain3         option httpclose         option forwardfor         cookie JSESSIONID prefix         server subdomain-3 192.168.1.31:80 check  backend subdomain4         option httpclose         option forwardfor         cookie JSESSIONID prefix         server subdomain-4 192.168.1.100:80 check  backend subdomain5         option httpclose         option forwardfor         cookie JSESSIONID prefix         server subdomain-5 192.168.1.200:80 check  backend subdomain6         option httpclose         option forwardfor         cookie JSESSIONID prefix         server subdomain-6 192.168.1.38:80 check    

Что мы получили в итоге:

1. Генерация ssl сертификатов происходит на каждом сайте отдельно. Терминации на прокси сервере нет, идет прозрачное перенаправление на конечную машину которая и отдает посетителю свой ssl сертификат.
2. Проблем с Яндексом и его роботом дятлом (который мониторит сайт на доступность) не имеем.
3. Имеем быстрый и корректный отклик конечной машины для посетителей и поисковиков.
4. В качестве небольшого бонуса, имеем страничку с статистикой работы прокси сервера и сайтов которые он обслуживает. Для этого перейдите на ip (например у меня 192.168.1.150:5000) на котором он работает с портом 5000 и наслаждайтесь. Логин admin а пароль который вы сами установили в верхней секции этого конфига.

Отдельно хочу сделать замечание касаемо этого файла конфигурации Haproxy.

Весьма вероятно, что когда вы добавите в свой пул сайтов на PROXMOKS-e еще N кол-во виртуальных машин и вам понадобится получить сертификат с Letsencrypt, у вас может не получится это, тк Haproxy не сможет корректно отработать запрос и от вашей машины и к вашей машине.
В таком случае (под диванного сервера) сделайте выход c роутера (или что там у вас) проброс портов на новую ВМ, хотя бы 80 порт и после получения сертификата верните обратно. По крайней мере я так вышел из этой ситуации. Подробнее о проблеме описано по ссылке

Как всегда, приветствуются конструктивные предложения и замечания.

Всем успехов!

PS Сам реверс прокси у меня поднят и прекрасно себя чувствует на Ubuntu 18.04 которая идет в шаблонах Proxmox-a. По началу я его запускал в режиме полноценной виртуалки но это решение себя не оправдало тк потребляло изрядную процессорную и прочие ресурсы хост машины. С переводом прокси сервера на LXC контейнер потребление по ресурсам упало почти до пары единиц процентов ресурсов хост машины и можно сказать что ничего не потребляет.