Для создания защищенного подключения извне по протоколу RDP одним из самым популярных способов является настройка роли шлюза терминалов RDP. Однако, для данной роли, в отличие от других компонентов терминальной фермы, Microsoft не предлагает своих инструментов для создания отказоустойчивости внешней точки подключения пользователей. Одним из надежных решений данной проблемы является использование сторонних балансировщиков нагрузки, которые позволяют распределять трафик между несколькими серверами, что позволяет обеспечить повышенную отказоустойчивость, увеличить доступность сервиса и обеспечить легкую масштабируемость структуры.
Покажем, как можно настроить масштабируемый кластер из веб-балансировщиков HAproxy с плавающим IP-адресом при помощи протокола VRRP.
В нашем примере, мы будем использовать операционную систему Debian 11. Для других дистрибутивов команды могут немного отличаться. Опустим первоначальную установку, настройку и обновление Debian, перейдем сразу к установке HAproxy.
Для нашего тестового стенда будем использовать следующую сетевую конфигурацию:
- 10.10.0.1 – плавающий адрес для работы протокола VRRP, проброс 443 порта извне следует выполнять именно на этот адрес для корректной работы кластера
- 10.10.0.10 – 10.10.0.12 – адреса бэкенд-серверов с настроенными ролями шлюза терминалов RDP, между которыми будет происходить балансировка подключений
По умолчанию HAproxy включен в стандартный репозиторий Debian 11. Выполните следующую команду в терминале:
sudo apt -y install haproxy
Затем добавим службу HAproxy в автозагрузку и запустим:
sudo systemctl enable haproxy sudo systemctl start haproxy
Настраиваем основной конфигурационный файл:
nano /etc/haproxy/haproxy.cfg
Приведем конфиг к следующему виду, заменяя необходимые блоки под свою конфигурацию по примеру:
global
log /dev/log local0
log /dev/log local1 notice
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
ssl-default-bind-options no-sslv3
ssl-server-verify none
defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
stats enable
stats uri /stats
stats realm Haproxy Statistics
stats auth stat:1234
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend gateway_rdp-frontend
bind *:443 ssl crt /etc/haproxy/ssl/your-site.ru.pem
mode http
capture request header Host len 32
log global
option httplog
timeout client 300s
maxconn 1000
default_backend gateway_rdp-backend
backend gateway_rdp-backend
balance source
mode http
log global
option forwardfor
http-request add-header X-CLIENT-IP %[src]
option httpchk GET /
cookie RDPWEB insert nocache
default-server inter 3s rise 2 fall 3
server server-ts1 10.10.0.10:443 maxconn 1000 weight 10 ssl check cookie server-ts1
server server-ts2 10.10.0.11:443 maxconn 1000 weight 10 ssl check cookie server-ts2
server server-ts2 10.10.0.12:443 maxconn 1000 weight 10 ssl check cookie server-ts3
Выполняем перезапуск службы HAproxy:
sudo systemctl restart haproxy
Проверяем, что HAproxy запустился корректно и нет ошибок в журналах. Проверить вывод статистики и состояния можно в веб-интерфейсе по адресу: https://haproxy_IP:5443/stats
На этом базовая настройка первого узла закончена. Проводим аналогичные действия по настройке на всех узлах Haproxy, входящих в кластер, конфигурация везде будет идентична.
После завершения конфигурирования Haproxy, рассмотрим процедуру установки keepalived и настройки кластера Master – Slave с плавающим IP-адресом при помощи протокола VRRP. Для работы данного протокола сетевой экран должен пропускать трафик на широковещательный адрес 224.0.0.18. Добавим соответствующее правило:
sudo iptables -I INPUT -p vrrp -d 224.0.0.18 -j ACCEPT
Затем проводим установку keepalived при помощи команды:
sudo apt install keepalived
Создаем конфигурационный файл на сервере с Haproxy, который выберем основным:
nano /etc/keepalived/keepalived.conf
Добавляем следующие строки:
global_defs {
# Keepalived process identifier
lvs_id haproxy_DH
}
# Script used to check if HAProxy is running
vrrp_script check_haproxy {
script "killall -0 haproxy"
interval 2
weight 2
}
# Virtual interface
# The priority specifies the order in which the assigned interface to take over in a failover
vrrp_instance VI_01 {
state MASTER # MASTER для основного сервера, BACKUP для резервного
interface eth0 # Имя интерфейса можно узнать с помощью команды ifconfig
virtual_router_id 183
priority 101 # Для основного сервера с haproxy 101, для резервного 100
# The virtual ip address shared between the two loadbalancers
virtual_ipaddress {
10.10.0.1 # Виртуальный IP, по которому будет доступен keepalived
}
track_script {
check_haproxy
}
}
Данная конфигурация будет регулярно выполнять проверку состояния процесса HAproxy на мастере и в случае его недоступности, либо при отказе всего сервера производить переключение VIP адреса на резервный узел кластера keepalived.
Разрешим автозапуск службы и запустим:
sudo systemctl enable keepalived sudo systemctl start keepalived
Проверим состояние:
systemctl status keepalived ip a
Если все настроено корректно, то мы должны увидеть дополнительный адрес на сетевом интерфейсе. В нашем примере, это 10.10.0.1.
Проводим аналогичные настройки конфигурации на остальных узлах кластера. Отличаться будет только статус и приоритет.
state BACKUP … priority 100
После окончания настройки на всех узлах, можно провести тестирование работы VRRP путем отключения сети, либо процесса Haproxy на Master сервере. VIP адрес должен перейти на резервный сервер.
На этом базовая настройка конфигурации кластера отказоустойчивого балансировщика для роли шлюза терминалов RDP можно считать законченной.
Настройку и обслуживание серверов терминалов мы можем взять на себя. Оставьте заявку или напишите в чат!
