Привет, я занимаюсь проектированием, внедрением и тестированием средств защиты информации в Т1 Интеграция.

Часто бывает, что требуется решить задачу максимально оперативно. Это значит, что на покупку и установку специализированного оборудования может не быть ни времени, ни средств, и приходится обходиться тем, что есть. Скажем, это может быть балансировка трафика между различными устройствами, которые имеют одинаковую функциональность и по каким‑то причинам не могут быть объединены в кластер, или не имеют встроенных механизмов распределения нагрузки, или требуется эту самую нагрузку распределить, увеличив таким образом пропускную способность. Примерами могут быть: WAF, TLS‑шлюзы, серверы веб‑приложений.

Если под рукой нет сетевого балансировщика, то можно попробовать настроить балансировку между вашими нодами на межсетевом экране. Конечно, в эпоху импортозамещения не у каждого МСЭ есть такая функция, но в нашем случае балансировка в UserGate была, а трафик требовалось распределить между тремя TLS‑шлюзами. Покажу, как это проверялось на тестовом стенде, а в дальнейшем использовалось в проде.

Схема такая: Client (пользователь) находится где‑то в Интернете и пытается попасть во внутреннюю сеть компании через один из TLS‑шлюзов: red, green, blue. Между клиентом и внутренней сетью расположен кластер UserGate версии 7.1.2. В данном случае IP‑адрес 10.10.1.1 имитирует публичный адрес кластера UserGate, куда приходят все запросы от пользователей, и далее они транслируются на TLS‑шлюзы.

Я разворачивал все виртуальные машины для проверки в VMware. После первоначальной настройки интерфейсов на каждом устройстве собираем кластер и проверяем настройки на интерфейсах.

Кластер собран и готов к работе:

Поскольку это эксперимент, с маршрутизацией особо заморачиваться не стал. Для проверки достаточно написать маршрут по умолчанию в сторону UserGate на TLS‑шлюзах red, green и blue:

На Client аналогично:

На самом UserGate какие-либо маршруты отсутствуют, потому что для него все сети directly-connected:

Далее в политиках сети настраиваем балансировку: «Политики сети» → «Балансировка нагрузки» → «Добавить» → «Добавить балансировщик TCP/UDP».

Для проверки настроим доступ по 80 порту, а в реальности, конечно же, будет порт 443. На вкладке «Общие» надо выбрать IP‑адрес виртуального сервера (публичный адрес ресурса), его порт и протокол, а также метод балансировки (вернёмся к этому чуть позже) — пусть пока это будет обычный RoundRobin, то есть выбор между TLS‑шлюзами будет последовательный 1, 2, 3, 1, 2.. и т. д.

Здесь выбираем зону источника — Untrusted, в нашем случае трафик идёт из Интернета, адреса источников заранее неизвестны, поэтому в правой колонке пусто. Если вы знаете, с каких адресов к вам будут поступать запросы, то лучше ограничить перечень возможных источников подсетью или конкретными адресами.

Далее выбираем реальные серверы, это те самые адреса TLS‑шлюзов и их порты. В этом примере публичные порты и порты на шлюзах совпадают, но это не обязательно, для внешних и внутренних адресов можно задать разные.

Кроме того, при настройке адресов можно задать такие параметры, как вес и режим:

Вес влияет на распределение нагрузки между TLS‑шлюзами (бэкенд‑серверами), а вес может быть целым числом от 1 до 100. Если задать такие веса, что соотношение между ними будет 1:2:3, то в соответствующей пропорции трафик будет распределяться между серверами, при условии, что метод балансировки будет «Weighted round robin».

Режим может быть трёх видов:

• Шлюз: трафик просто маршрутизируется на бэкенды. Может быть полезно, если используется только во внутренней сети, но в нашем случае не актуально, потому что трафик приходит из Интернета и внешние хосты ничего не знают о нашей внутренней сети.

• Маскарадинг: происходит DNAT на конечные серверы, адрес источника при этом сохраняется — наш выбор.

• Маскарадинг с подменой источника (SNAT): то же самое, что маскарадинг, но при этом подменяется ещё и адрес источника. Сходу сложно придумать сценарии применения, хотелось бы понимать, кто конкретно обращался к ресурсу, и видеть это в журналах.

Следующая вкладка — «Аварийный режим»: практически то же самое, что реальные серверы, но используется только в том случае, если реальные серверы недоступны. Таким образом можно организовать bypass трафика, к примеру, сразу на сервер за TLS‑шлюзом, но для этого нужно, чтобы для ваших серверов была допустима политика «fail‑open». Обычно с точки зрения бизнеса это неприемлемо, и в нашем случае тоже, поэтому этот пункт пропускаем.

На вкладке «Мониторинг» можно настроить проверку доступности серверов и исключать автоматически те из них, которые не прошли проверку:

Параметры по умолчанию очень консервативные, и в среде, где необходима высокая доступность, лучше их подкрутить. Я оставил такие:

По большому счёту это все настройки, необходимые для балансировки, потому что правила балансировки имеют более высокий приоритет, чем маршрутизация и DNAT.

Кроме того, для них не требуется отдельная настройка правил межсетевого экранирования. На стенде были настроены только SNAT для выхода «в Интернет», поэтому настраивать балансировку надо аккуратно, соблюдая принцип «минимальной необходимости».

И правила для выхода «в Интернет»:

При этом всё прекрасно работало, на выходе видно, что при обращении из разных источников ротируются серверы, обрабатывающие запросы (red, green и blue соответственно):

И напоследок пара слов о двух других режимах балансировки:

• Least connections: межсетевой экран будет отправлять трафик на устройство в пуле балансировки, которым установлено в данный момент наименьшее количество соединений.

• Weighted least connections: то же самое, но при этом можно ещё влиять на распределение нагрузки при помощи весов, которые мы задавали на вкладке «Реальные серверы».