HAProxy for RDP

https://habr.com/ru/articles/335872/

Совершенно случайно, в пассивном поиске альтернативы устаревшему 2X-LoadBalancer и тяжелому, непонятному Remote Connection Broker от MS наткнулся на HAProxy и его умению проксировать RDP трафик. В выдачах поисковиков практически не выдается haproxy в качестве прокси для RDP. Сейчас вдруг пачками стал выдавать. Вместе с тем, коммерческие продукты с таким же функционалом, такие как упоминались выше, стоят приличных денег.

В общем, мне показалось, что это может быть кому-то интересным. Поэтому я решил осветить это решение. Плюс, в конце продемонстрирую гибкость использования HAProxy, которой нет у именитых конкурентов.

Как это работает, вкратце

HAProxy умеет идентифицировать RDP, проксировать его и парсить rdp_cookie для выуживания из них нужной информации и последующего использования ее в механизме маршрутизации.

Клиент подключается к прокси, тот вытаскивает логин из rdp_cookie, выбирает для него сервер, записывает значения «логин — сервер» в stick-table и подключает пользователя к серверу.

Соотвественно, при следующем подключении этого же клиента(с этим логином) прокси находит запись в таблице и подключает его к тому серверу на котором у пользователя открытая сессия. Гениально и просто!

stick-table — это таблица, хранящаяся в памяти процесса, где для каждой записи можно определить время жизни. Выставить 8 часов, и весь день клиент будет попадать на один и тот же сервер.

Ниже стандартный конфиг:

#/usr/local/etc/haproxy.conf
global
daemon
stats socket /var/run/haproxy.sock mode 600 level admin
stats timeout 2m

defaults
log     global
mode tcp
option tcplog
option  dontlognull

frontend fr_rdp
  mode tcp
  bind *:3389 name rdp
  log global
  option tcplog
  tcp-request inspect-delay 2s
  tcp-request content accept if RDP_COOKIE
  default_backend BK_RDP

backend BK_RDP
  mode tcp
  balance leastconn
  timeout server 5s
  timeout connect 4s
  log global
  option tcplog
  stick-table type string len 32 size 10k expire 8h
  stick on rdp_cookie(mstshash),bytes(0,6)

  stick on rdp_cookie(mstshash)
  option tcp-check
  tcp-check connect port 3389
  default-server inter 3s rise 2 fall 3
  server TS01 172.16.50.11:3389 weight 10 check
  server TS02 172.16.50.12:3389 weight 20 check
  server TS03 172.16.50.13:3389 weight 10 check
  server TS04 172.16.50.14:3389 weight 20 check
  server TS05 172.16.50.15:3389 weight 10 check
  server TS06 172.16.50.16:3389 weight 10 check
  server TS07 172.16.50.17:3389 weight 20 check
  server TS08 172.16.50.18:3389 weight 20 check

listen stats
 bind *:9000
 mode http
 stats enable
 #stats hide-version
 stats show-node
 stats realm Haproxy\ Statistics
 stats uri /

Трудности

Так как stick-table располагается в памяти, при перезагрузки процесса теряется вся информация о парах «клиент-сервер», а это критическая информация в нашем случае. Для выхода из ситуации я написал скриптик, который использую для перезагрузки процесса. Скрипт перед остановкой процесса скидывает stick-table в файл, затем после старта процесса записывает данные обратно(текущие сессии при этом не обрываются):

Что еще?

Еще можно гибко управлять тем, на какие сервера проксировать тех или иных клиентов. Делать это можно на основании логина, ip адреса, сети, времени суток и т.п.

Я же приведу пример как на основе групп из AD можно разбить сервера фермы по отделам, например:

два сервера для Бухгалтерии

два сервера для Маркетинга

два сервера для Продажников

два для всех остальных.

Понятно, что в каждой группе серверов могут быть различные мощности: установленное ПО и какие-то специфические настройки, поэтому мы их разделим.

HAProxy позволяет на основании определенных политик гибко определять к какому серверу подключать пользователя, имея одну точку входа для всех RDP подключений (что несомненно удобно).

Для это необходимо немного модифицировать конфиг HAProxy и скрипт перезагрузки:

модифицированный скрипт перезагрузки:

Как это работает:

В AD создаются группы (и наверняка такие группы уже есть) Accounts, Marketing и Sales, в эти группы помещаются сотрудники. Скрипт подключается к AD и получает список сотрудников по выбранным группам. Список сотрудников сохраняется в файл с именем группы.

В конфиге HAProxy настроены ACL источником которых являются эти файлы групп. Если в группу добавляется новый сотрудник, необходимо выполнить скрипт для обновления файла группы.

Прокси проверяет, есть-ли логин в указанном файле. Если есть, отправляет на определенный для этой группы бакенд. Все очень просто!

Параметры запуска скрипта:

haproxy.py group group_name — перезагрузка группы, текущие сессии при этом не обрываются.

haproxy.py restart — перезагрузка процесса (перечитать конфиг), при этом текущие сессии не обрываются.

Отказоустойчивость

Ее нет!

В данном примере решение не обладает никакой отказоустойчивостью.

Во первых, не зарезервирован haproxy.

Во вторых, решение с записью значений «клиент-сервер» в stick-table не позволяет haproxy подключать пользователей к живым серверам, чьи записи уже есть в таблице, и сервер к которому они были подключены в данным момент недоступен. Он тупо будет пытаться отправить их на сервер из таблицы, несмотря на то, что он не в сети.

Первое, резервирование haproxy можно сделать различными способами.

Один из них — модифицированый скрипт перезагрузки. В него можно добавить копирование и загрузку сохраненных таблиц на другом haproxy, с запуском этого скрипта переодически по крону.

Спасибо vasilevkirill, есть встроенное решение, которым он поделился в комментарии

habrahabr.ru/post/335872/#comment_10369854

Второе сложнее. Нужен механизм, который бы точно определял, что с сервером. Сервер может по каким то легальным и не очень причинам быть не доступен по сети некоторое время, скажем 1 минуту, к примеру. Но при этом иметь открытыми все RDP сессии. И если мы решим, что сервер больше не доступен, и нужно всех пользователей переключать на другие сервера, то можем получить несохраненные данные, клиенты могут потерять большой обьем работ и тп.

Технически же, реализовать очистку stick-table не вызывает трудности. Для отслеживания состояния серверов можно использовать различные мониторинговые системы. В том же Zabbix, по событиям можно вызывать локальные скрипты.В нашем случае можно вызывать скрипт очистки stick-table.

В заключении, с учетом тех недостатков, которые я указал выше, HAProxy работает очень стабильно и надежно.

Last updated

Was this helpful?