User Tools

Site Tools


Sidebar


Здравствуйте!

Меня зовут Михаил!
Я системный администратор
и наполняю эту wiki,
решая разнообразные IT-задачки.

Моя специализация - виртуализация!

Я всегда готов помочь Вам
наладить IT-инфраструктуру
за скромное вознаграждение!

mike@autosys.tk
+7 (910) 911-96-23

citrix:haproxy-балансировщик-нагрузки-и-reverse-proxy-для-xenapp-и-других-https-сервисов-на-одном-ip

Исходная ситуация

На одном физическом сервере, который имеет единственный реальный IP-адрес работают несколько виртуальных HTTPS web-серверов. В том числе и XenApp с Citrix Secure Gateway. У каждого сервера свой сертификат.

Задача - настроить reverse-proxy для этих сервисов, чтобы на real_IP:443 работали все сервисы и терминация SSL трафика происходила не на reverse-proxy, а на web-серверах.

До этого момента в качестве reverse-proxy использовался nginx. И на первый взгляд он пригоден для этой цели. Например, сайт XenApp открывался. Но как оказалось, для работы с Citrix Secure Gateway он не подходит. При запуске приложения Citrix Receiver делал нестандартный HTTPS-запрос (вероятно - без SNI), который не проходил через nginx. Однако на последних версиях Citrix Secure Gateway 3.3.5 и Linux Citrix Receiver 13.7 x64, вероятно, все заработает и через nginx.

Видимо нужен reverse-proxy, работающий в режиме tcp и поддерживающий SNI (Server Name Indication), подумал я и начал искать.

Решение

Решением стало внедрение haproxy (версии не ниже 1.5).
Устанавливать на Ubuntu 16.04 можно из стандартного репозитория. Устанавливаем haproxy и проверяем версию:

sudo apt-get install haproxy
haproxy -vv

В выводе этой команды должно быть:

HA-Proxy version 1.6.3 2015/12/25

и

OpenSSL library supports TLS extensions : yes
OpenSSL library supports SNI : yes

Теперь в файл конфигурации /etc/haproxy/haproxy.cfg пишем что-то такое:

global
  log 127.0.0.1 local5 notice
  user haproxy
  group haproxy

# Adjust the timeout to your needs
defaults
  timeout client 30000s
  timeout server 30000s
  timeout connect 10s

#############################################################
############ Frontend HTTPS in tcp mode
###########################################################
frontend https_proxy
  bind *:443
  mode tcp
  log 127.0.0.1 local6
  option tcplog
  tcp-request inspect-delay 5s
  tcp-request content accept if { req_ssl_hello_type 1 }

  use_backend ssh if { payload(0,7) -m bin 5353482d322e30 }
  use_backend xd_https if { req_ssl_sni -i xd.autosys.tk }
  use_backend sstp_https if { req_ssl_sni -i sstp.autosys.tk }
#  default_backend xd_https
  default_backend sstp_https
  
##########################################################
###-------------- FrontEnds HTTP ------------########
######################################################

frontend http
#   option httplog
   log 127.0.0.1 local7 debug                   #/var/log/http.log
   mode tcp
   bind *:80
# redirect to HTTPS
   redirect scheme https if { hdr(Host) -i xenapp.autosys.tk } !{ ssl_fc }
   use_backend ssh if { payload(0,7) -m bin 5353482d322e30 }
   
#########################################################################
####----- Backends----------######################
########################################################################

backend sstp_https
  mode tcp
  server sstp_ssl 192.168.77.138:443

backend xd_https
  mode tcp
#  option ssl-hello-chk
  server xdwebi xd.autosys.tk:443 check

backend ssh
  mode tcp
  server ssh_haproxy 127.0.0.1:22

Старые версии продуктов Citrix (Citrix Secure Gateway и Citrix Receiver) не работали без строки default_backend xd_https (вероятно не в каждом запросе HTTPS был заголовок SNI), однако на последних версиях (Citrix Secure Gateway 3.3.5 и Linux Citrix Receiver 13.7 x64) все работает без этой строки, что позволяет запустить на порте 443 еще и SSTP-VPN на базе SoftEther, указав именно его в качестве дефолтного бекенда для SSL-траффика :).
Также в приведенном конфиге показано как пробросить SSH с портов 80 и 443.

Отказоустойчивая балансировка Secure Gateway

Предположим, у нас работает Citrix SecureGateway, но иногда нам нужно с его хостом производить какие-то манипуляции без остановки сервиса. Выход - настройка балансировки. Поднимаем второй хост с Web-интерфейсом и Secure Gateway и настраиваем также как и первый. Сертификат берем тот же что и на первом хосте. Вся магия будет на haproxy в раздельчике backend. В него нужно добавить balance source, тип хеширования IP-адреса источника hash-type consistent и второй сервер с SecureGateway.

backend xenapp
  option tcplog
  log ${LOCAL_SYSLOG}:514 local1 debug
  hash-type consistent 
  balance source
  mode tcp
  option ssl-hello-chk
  server xenappsrv xenapp.domain.com:443 check
  server xenappsrv2 xenapp2.domain.com:443 check

В результате у нас будет балансировка типа source, при которой клиент будет работать с тем сервером, к которому он подключился изначально. Тип хеширования можно не задавать (по-умолчанию это map-based), но иногда лучше работает consistent. Также, иногда нужно немного расширить таймаут проверки ssl-hello-check. Для этого перед строкой option ssl-hello-chk добавить timeout check 5000 (ну или сколько надо в миллисекундах).

Включаем логи на для haproxy

HAproxy очень продвинутый балансировщик, поэтому писать логи в просто файлы он не может…
Но может писать логи на удаленный или локальный сервер syslogd.

Сначала нужно разрешить syslogd принимать логи по UDP.
Для этого в файле /etc/default/syslogd нужно заменить SYSLOGD=““ на SYSLOGD=”-r”.

Затем в файле /etc/syslog.conf нужно прописать facilities для логов. Напомню, что логи можно писать как в один файл все, так и в разные файлы и на разные сервера. Прямо в начало /etc/syslog.conf я добавил:

# Log HAproxy events
local0.*        -/var/log/haproxy.log
local1.*        -/var/log/xenapp.mydomain.org.log
local2.*        -/var/log/mydomain.org.log

Тем самым я объявил facilities с именами local10, local1 и local2.

А теперь можно настроить логи в конфигурации haproxy. У меня получилось примерно так:

global
log ${LOCAL_SYSLOG}:514 local0 notice


defaults
  option tcplog
  log global
# Adjust the timeout to your needs
  timeout client 3000s
  timeout server 3000s
  timeout connect 10s

# Single VIP
listen ssl :443
  tcp-request inspect-delay 5s
  tcp-request content accept if { req_ssl_hello_type 1 }
  use_backend xenapp if { req_ssl_sni -i xenapp.mydomain.org }
  use_backend mydomain if { req_ssl_sni -i mydomain.org }
  default_backend xenapp

backend xenapp
  log ${LOCAL_SYSLOG}:514 local1 debug
  mode tcp
  server xenappsrv xenapp.local:443

backend mydomain
  log ${LOCAL_SYSLOG}:514 local2 debug
  mode tcp
  server mydomainsrv mydomain.local:443

ВСе. Еще может понадобиться создать файлы логов, а то syslogd откажется стартовать.
Перезапускаем haproxy и syslogd и радуемся логам.

Discussion

Enter your comment. Wiki syntax is allowed:
W T D Q J
 
citrix/haproxy-балансировщик-нагрузки-и-reverse-proxy-для-xenapp-и-других-https-сервисов-на-одном-ip.txt · Last modified: 2017/11/29 20:20 by admin