Привет, Хабр! Меня зовут Ильнар Зайнуллин, я системный инженер в К2Тех. В этой статье хочу показать, как Termidesk Connect ведет себя в реальных сценариях балансировки – от «одного белого IP» до защищенной почты на MS Exchange.

За последние несколько лет мы с вами пережили серьезные сдвиги на рынке сетевой инфраструктуры. Регуляторика и курс на импортозамещение, уход западных вендоров и хакерские атаки на цепочки поставок – все это заставило пересмотреть подходы к построению ИТ-инфраструктуры, в том числе и привычный стек балансировки. В результате появились отечественные альтернативы опенсорсным инструментам. За годы работы с самыми разными запросами заказчиков мы хорошо изучили связки Nginx/HAProxy + Keepalived со всеми их плюсами и минусами. 

Сегодня поделимся опытом практического применения Termidesk Connect от «Группы Астра» в сценариях, с которыми, на первый взгляд, мог бы справиться и опенсорс. Мы взяли три реальных обезличенных кейса из нашей практики внедрений: от небольшой компании, ушедшей в облако, до корпорации с MS Exchange. На их примере расскажем про возможности Termidesk Connect.

В статье не будет сравнения «отечественное против зарубежного» в вакууме, вместо этого рассмотрим прикладные сценарии:

• маршрутизация HTTPS по SNI без терминации TLS;

• L7 reverse proxy (обратный прокси) и трансформация заголовков;

• предаутентификация перед Exchange;

• проверка состояния (health-checks) и отказоустойчивость;

• эксплуатация решения командой без глубокого DevOps-бэкграунда.

Опенсорс и вендорская альтернатива

Прежде всего несколько слов об опенсорсном стеке, с которым мы будем сравнивать российское решение.

HAProxy – надежный и быстрый балансировщик: на L4 и на L7 ему мало равных. Обычно проблемы с ним возникают при использовании rewrite (перезапись запросов/ответов): стоит переписать тело ответа или собрать хитрую логику редиректа, и конфигурационные файлы быстро становятся нечитаемыми.

У Nginx все наоборот: хорошо показывает себя в перезаписи запросов/ответов, проксировании и отдаче статики, зато проверки состояния бэкенда в бесплатной версии практически отсутствуют – нужны либо сторонние модули, либо платная версия, а с ее приобретением сейчас масса проблем.

Ну и куда без Keepalived, который обеспечивает виртуальный IP для переключения на другую ноду в случае падения основной, либо позволяет реализовать простую L4-балансировку.

В сухом остатке это хороший стек, но собирать и поддерживать его приходится самостоятельно. Для нестандартной логики в опенсорсе часто приходится писать кастомные скрипты на Lua. В Termidesk Connect для этих целей предусмотрен механизм работы со сценариями на Lua, а также возможность подключения внешних скриптов для проверок. Разница заключается в том, как этот код эксплуатируется. В самосборном стеке инженеры пишут и поддерживают Lua-модули, рискуя нарушить обратную совместимость при обновлении условного Nginx. В Termidesk Connect сценарии (Lua-скрипты) работают с предопределенным набором понятных системных объектов, а синтаксис проверяется встроенной валидацией платформы. Всю рутину – от обновления интерпретатора до закрытия CVE в движке балансировки – берет на себя вендор. 

Что это меняет на практике?

Коротко сравнение выглядит так:

Понятно, что на чистом опенсорсе можно реализовать абсолютно ту же логику. Разница скорее в подходе: один и тот же саморез можно закрутить и отверткой, и шуруповертом с одинаковым результатом. Если провести аналогию с нашими кейсами, то в случае с «отверткой» вы платите за каждый оборот временем и силами своей команды.

Сценарий 1. Маленькая организация и один белый IP

Итак, небольшая, но быстрорастущая производственная компания. Многие подобные бизнесы расстались с зарубежными партнерами, локализовались и ушли в облако ради экономии. В результате в аренде у нашего клиента остался один белый IPv4, за которым скрывался десяток внутренних сервисов: от веб-портала и CRM до файлообменника. При этом компании нужно было сохранять доступность инфраструктуры для сотрудников, которые постоянно находятся в разъездах.

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

Опенсорсное решение

Обычно эту задачу решают с помощью связки iptables с DNAT для разных портов и Nginx с различными server_name. Однако в такой схеме Nginx забирает TCP-соединение на себя, из-за чего бэкенд вместо реального клиентского адреса получает адрес балансировщика. Для HTTP это можно обойти с помощью заголовка X-Forwarded-For, но использование SSL offload в данном случае нецелесообразно: терминация TLS создает значительную нагрузку на CPU, а также усложняет операционное управление сертификатами при работе с большим числом сервисов.

Что делает Termidesk Connect

На этот случай в Termidesk Connect можно использовать SNI-роутинг. Балансировщик анализирует поле SNI (Server Name Indication) в сообщении TLS Client Hello: эта часть рукопожатия еще не зашифрована. Он видит, куда обращается клиент, например, mail.company.ru или crm.company.ru, и маршрутизирует трафик по имени сервера – Server Name. Сам запрос остается зашифрованным, поэтому ставить сертификаты на балансировщик не нужно.

Это хорошо видно в дампе трафика: в пакете Client Hello поле Server Name читается прямым текстом – по нему Termidesk Connect и принимает решение, не вскрывая зашифрованное содержимое.

Клиентский IP сохраняется одним из двух способов:

• если сервис поддерживает PROXY protocol, передаем адрес через него;

• в случае с легаси-сервисом без поддержки PROXY protocol, балансировщик размещается так, чтобы на обратном пути пакеты проходили через него, и бэкенд получал исходный Source IP.

При этом небольшая компания вполне может обойтись одной нодой, а по мере роста добавить вторую и развернуть Active-Passive-кластер. Termidesk Connect поддерживает его из коробки.

Сценарий 2. Продуктовый гигант и раздробленный сайт

Теперь посмотрим на средний бизнес: это может быть, например, популярный интернет-магазин или другой сайт с большим количеством посетителей. За ним стоит микросервисная архитектура: админка расположена в одной сети, статика и картинки – в другой, динамический API – в третьей, и заведуют ими разные команды. Одна группа пишет мобильную версию, другая – десктопную, а третья занимается локализацией.

Задача балансировщика в такой ситуации – собрать лоскутное одеяло в единый контур: распределить запросы по бэкендам в зависимости от содержимого (URL, страна, User-Agent), по дороге добавить нужные заголовки, переписать Host, а из ответа убрать лишнее. Например, строку Server: nginx/1.18.0, по которой любопытные хакеры и конкуренты могут определить технологический стек.

Опенсорсное решение

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

Как с этим справляется Termidesk Connect

Termidesk Connect в этом сценарии обеспечивает L7-роутинг и трансформацию (как в Nginx) и продвинутые алгоритмы балансировки (как в HAProxy), но в одном продукте с единой точкой поддержки и удобным обслуживанием.

Для активации L7-балансировки включаем режим reverse proxy. Балансировщик сам принимает HTTP/HTTPS-трафик и расшифровывает его, то есть терминирует SSL/TLS. После этого для маршрутизации можно настроить ряд простых правил:

• если URL начинается с /admin → отправляем в бэкенд 10.10.1.10;

• если время сервера между 9:00 и 12:00 – подставляем в запрос заголовок X-Time-Mood: morning, и бэкенд отдает легкую версию сайта;

• если запрос пришел, например, из Казахстана, балансировщик подставляет реальный IP клиента в заголовок X-Forwarded-For, и бэкенд отдает локализованную версию сайта.

Чтобы убрать из ответа бэкенда строку Server: nginx/1.18.0, можно скрыть соответствующий заголовок на уровне proxy-правила.

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

Сценарий 3. Корпорация и защищенная почта

Третий кейс – самый сложный и связан с крупной распределенной компанией. Таких много в промышленности или финансах, и многие из них до сих пор используют MS Exchange просто потому, что переход на российское решение представляется долгим и болезненным.

Следовательно, компании нужно обезопасить Exchange на этот переходный период: выставить корпоративную почту в интернет, но с жесткой фильтрацией, обеспечив внешний доступ только тем, кому он действительно нужен в разъездах. А сотрудников с доступом к чувствительным данным (например, бухгалтеров, финансистов) пускать в почту только из офиса или по VPN.

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

Как это работает на опенсорсе

Чтобы заставить опенсорсный балансировщик работать с Exchange и Kerberos-делегированием, нужна особая сборка с модулями вроде mod_auth_kerb и mod_lua, которые нужно интегрировать и настроить под конкретную инфраструктуру. Собрать такое реально, но сопровождать придется самостоятельно.

Что дает проприетарное решение

Здесь используются встроенные механизмы безопасной NTLM- и Kerberos-аутентификации. Пользователь открывает Outlook, а Termidesk Connect извлекает идентификатор пользователя напрямую из сертификата и валидирует его в AD/LDAP, включая проверку членства в целевой группе. Если сертификат невалиден или пользователь не состоит в группе, доступ не предоставляется, и Exchange о таком запросе даже не узнает.

Дальше начинается самое интересное: Kerberos. Когда между клиентом и Exchange встает балансировщик, цепочка доверия рвется. Connect восстанавливает ее через Constrained Delegation, точнее – через S4U2Proxy (Service for User to Proxy).

1. Балансировщик, имея свою сервисную учетную запись в AD, использует протокол S4U2Self, чтобы получить forwardable-билет (специальный сетевой пропуск безопасности) для пользователя без его пароля – только на основании факта аутентификации на балансировщике.

2. Далее, используя S4U2Proxy, Termidesk Connect говорит KDC: «Я, сервис-аккаунт балансировщика, авторизован делегировать пользователя для сервиса Exchange-backend». KDC выдает билет для Exchange.

3. Termidesk Connect устанавливает соединение с Exchange и предъявляет этот билет. Для Exchange все выглядит так, будто пользователь пришел напрямую, и Single Sign-On продолжает работать. Да, от уязвимости в самом Exchange такая схема не спасет, но поверхность атаки заметно сужается.

Почему именно Constrained Delegation, а не обычная? При неограниченном, или unconstrained, делегировании балансировщик мог бы ходить от имени пользователя в любые сервисы домена – слишком много прав для машины на периметре. S4U2Proxy ограничивает делегирование списком разрешенных сервисов, в нашем случае – только Exchange, так что принцип наименьших привилегий соблюдается.

Заодно балансировщик берет на себя проверку состояния самих почтовых нод. Если из десятка серверов у одного перестала работать OWA, а сам он пингуется, то останавливать его целиком незачем: Connect проведет проверку состояния, обнаружит проблему в конкретном сервисе и переведет запросы на рабочие ноды. В Nginx для этого приходится брать платную версию или сторонние модули.

Для тяжелых легаси-протоколов вроде SMTP можно использовать режим DSR (Direct Server Return): сервер отвечает клиенту напрямую и видит реальный клиентский IP. Работает он в другом режиме балансировки, без классических сокетов, поэтому SNI-роутинг из первого сценария там уже неприменим.

Где опенсорс все еще сильнее

Nginx, HAProxy и Keepalived не становятся плохими решениями только потому, что появился коробочный продукт. У опенсорса по-прежнему есть сильные стороны: гибкость, прозрачные конфигурации, огромная база знаний, удобная интеграция в Ansible/Terraform/GitOps и возможность тонкой кастомизации под конкретную инфраструктуру.

Если у вас сильная DevOps-команда, конфигурации живут в Git, изменения проходят review, обновления тестируются на стенде, а CVE закрываются по понятному процессу, опенсорс остается отличным выбором. В такой ситуации менять рабочий стек только ради замены смысла нет.

Опенсорс, лицензии и зрелость рынка

Итак, с технической точки зрения Termidesk Connect конкурентоспособен – и не только по функциям: по производительности он держится на уровне привычных решений, мы это уже замеряли в отдельной статье. Но есть ли для него место на рынке?

Все решают три фактора:

1. Вендорская поддержка, о которой мы сегодня много говорили. Если в штате работают инженеры, знающие все тонкости Nginx и HAProxy, волноваться не о чем, но таких специалистов мало, и стоят они все дороже. И дело не только в зарплатах: когда в опенсорсном компоненте всплывает критическая уязвимость, сроки устранения своими силами никто не гарантирует. Коммерческий вендор в такой ситуации должен как минимум подтвердить применимость CVE, дать workaround, сроки исправления и сопровождение обновления по SLA.

2. Еще один сюжет – лицензии на зарубежное ПО. F5, Citrix и Nginx Plus давно перешли на подписку, а NetScaler этой весной ужесточил лицензирование, теперь нужно платить ежегодно. Да и нет гарантий, что лицензию однажды просто не заблокируют. К тому же российский бизнес, особенно в КИИ и госсекторе, привык к бессрочным лицензиям: купил – пользуешься без оглядки на календарь.

3. Пользователей у отечественного ПО пока меньше, чем у иностранных решений, но для локального вендора вы приоритетнее, и на запросы он отвечает быстрее крупной зарубежной корпорации. Запись в реестре отечественного ПО и адаптация под другие реалии местного рынка снимают вопросы регуляторов.

Таким образом, если у вас сильная DevOps-команда и зрелые практики, опенсорс остается отличным выбором, и менять его незачем (разве что потребуют регуляторы, что в общем не редкость). А если такой команды нет, но инфраструктуру надо выставлять наружу уже сейчас, есть смысл развернуть пилот Termidesk Connect и проверить наши выводы на своих сценариях. Делитесь в комментариях, какие сценарии балансировки у вас оказались самыми болезненными в эксплуатации. На каком стеке вы их в итоге реализовали и в какой момент решили, что «собирать самим» уже не окупается?