HAProxy, разъясните пару вопросов.

[k0st1k]

@vladimirlind
Причем я добился того что присходит редирект на портале с http на https, но все стопорится на том что неверный сертификат(на прямую через порт маппинг работает без проблем).

Automaticaly generated, dont edit manually.

Generated on: 2019-04-24 16:12

global
maxconn 1000
stats socket /tmp/haproxy.socket level admin
gid 80
nbproc 1
hard-stop-after 15m
chroot /tmp/haproxy_chroot
daemon
server-state-file /tmp/haproxy_server_state

listen HAProxyLocalStats
bind 127.0.0.1:2192 name localstats
mode http
stats enable
stats admin if TRUE
stats show-legends
stats uri /haproxy/haproxy_stats.php?haproxystats=1
timeout client 5000
timeout connect 5000
timeout server 5000

frontend http
bind 82.142.165.226:80 name 82.142.165.226:80
mode http
log global
option http-keep-alive
maxconn 500
timeout client 30000
acl httpRedirectACL var(txn.txnhost) -m str -i er.vokod34.ru
http-request set-var(txn.txnhost) hdr(host)
http-request redirect scheme https if httpRedirectACL
default_backend help.vokod34.ru_ipvANY

frontend https
bind 82.142.165.226:443 name 82.142.165.226:443
mode tcp
log global
timeout client 30000
tcp-request inspect-delay 5s
acl er req.ssl_sni -i er.vokod34.ru
tcp-request content accept if { req.ssl_hello_type 1 }
use_backend er.vokod34.ru_ipv4 if er

backend help.vokod34.ru_ipvANY
mode http
id 100
log global
timeout connect 30000
timeout server 30000
retries 3
server help.vokod34.ru 193.125.5.27:80 id 101 weight 50

backend er.vokod34.ru_ipv4
mode tcp
id 10102
log global
timeout connect 30000
timeout server 30000
retries 3
source ipv4@ usesrc clientip
server er.vokod34.ru 193.125.5.9:443 id 10104 ssl weight 50 verify none

[vladimirlind]

@k0st1k said in HAProxy, разъясните пару вопросов.:

acl er req.ssl_sni -i er.vokod34.ru
tcp-request content accept if { req.ssl_hello_type 1 }

Если неправильный сертификат - то, наверное, маршрутизация по acl на фронтенде не срабатывает. Сертификат какой, вебгуя пфсенса? Скриншот настроек acl на фронтенде https было бы интересно посмотреть.

[k0st1k]

@vladimirlind скрин с утра сделаю, для понимания, использовать сертификат сайта не выйдет? придется свой подсовывать?

[k0st1k]

@vladimirlind

[vladimirlind]

@k0st1k В текущей конфигурации у вас SSL устанавливается между сервером и клиентом, без терминации на haproxy. Можно использовать режим SSL offloading - для того того, чтобы SSL сессия клиента перехватывалась haproxy, на котором был бы установлен сертификат сайта. В этом случае надо сертификат сайта импортировать на пфсенс и указать его на фронтенде.
Вы говорите - неверный сертификат при попытке зайти на сайт - а какой сертификат?
Если на фронтенде https убрать ACL и установить на нем er.vokod34.ru_ipv4 как дефолтный бекенд - будет работать?

[vladimirlind]

Если терминировать SSL на haproxy, то стоит попробовать ssl_fc_sni вместо req.ssl_sni в АСL:

[k0st1k]

@vladimirlind доковыярл настройки на столько что откат конфига не спасает и отваливаются правила фаервола) на праздниках планирую переставить с нуля и импортировать бэкапом часть основных настроек.
Как Подскажите как правильно отстроить.
Как я вижу порядок:
1.в бэкенд добавляю нужные ресурсы вида ИП*порт.
2. в фронтенд добавляется правило перекидывания.
необходимо ли дополнительно настраивать NAT?

[vladimirlind]

HAproxy проксирует запросы, приходящие на айпи:порт, указанные на фронтенде с учетом правил ACL, если таковые настроены, на сервер(ы) в в бекенде (тоже с учетом правил, если таковые настроены). Как правило, на фронтенде указывается айпи внешнего интерфейса, а на бекенде - айпи серваков во внутренней сети. Правил НАТ никаких делать не надо.

[k0st1k]

Вот пример бэкенда для сервиса https, все верно?
для каждой пары ип+порт свой бэкенд или в один добавлять как альяс?

[vladimirlind]

сложно сказать - айпи сервера бекенда внешний? Ок, может на то есть причина. Если серверов бекенда несколько - то можно балансировать трафик между ними. Тут много возможностей и вариантов, все зависит от желаемого результата.

[k0st1k]

Нужна одна реализация
domain.ru - 85.125.125.125
er.domain.ru - 85.125.125.125 (но во внутренней сети свой адрес, в примере 193.125.5.9)
post.domain.ru - 85.125.125.125 (так же свой 193.125.5.4)
cloud.domain.ru - 85.125.125.125 (так же свой 193.125.5.2)

адресация 193.125.5.* внутренняя( не я её придумал такой) порталы все разные гдето есть ssl гдето нет.

[vladimirlind]

Я так понимаю, фронтенд один для 85.125.125.125:443 (ну, + еще 80 фронтенд для перенаправления на 443), и с помощью трех правил ACL разруливать на три разных бекенда: если обращение идет к er.domain.ru -> бкенед с 193.125.5.9 и так далее для остальных. Тут еще SSL offloading на фронтенде просится с wildcard сертификатом для *.domain.ru

[k0st1k]

@vladimirlind не совсем, просто по найду на фронтенде был настроен переброс с http на https, а так нам необходимо чтобы отдельно http и https(переброс сделан на стороне веб сервера если требуется).