Настройка Eltex и UserGate в территориально распределённой ИТ-инфраструктуре

У нас уже есть статья — описание оборудования Eltex. Но одного обзора возможностей и ассортимента вендора недостаточно, чтобы понять, как оно справляется с реальными задачами. Важны примеры, где можно увидеть, как отечественный продукт показывает себя при интенсивном использовании, особенно внутри средней или крупной инфраструктуры.

В статье разбираем:

• с чем пришёл к нам заказчик
• какие решения мы приняли
• с какими проблемами столкнулись в процессе
• как настраивали
• каких результатов достигли после внедрения

Частые сбои при внедрении UserGate и их причины рассмотрелии в отдельном материале

Отправная точка проекта

К нам обратилась компания с крупной распределённой инфраструктурой, включающей три подразделения. Каждый из филиалов работал в своих условиях, со своими особенностями.

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

Заказчик решил изменить инфраструктуру по двум причинам:

1. Компании нужен был ЦОД. В нём планировали разместить все СХД, организовать DMZ и настроить основную массу серверов, которая переехала бы из подразделений.
2. Организация крупная, столкнулась с требованиями регуляторов по импортозамещению. Чтобы соответствовать новым стандартам, необходимо перейти на отечественное оснащение.

Изначально на границе сетевого контура клиента стояли зарубежные решения, теперь их потребовалось заменить на российские. А с ЦОД решили поступить иначе — строить его целиком на отечественном.

Для клиента импортозамещение означало не только замену ключевой инфраструктуры, но и добавление новых элементов в архитектуру, их настройку. Например, мы планировали перенести поддержание VPN на маршрутизаторы, которых не было на некоторых объектах.

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

Аудит, проектирование и реализация этого проекта стали для нас положительным опытом, которым мы хотим с вами поделиться.

До внедрения нового решения подразделения компании были соединены между собой с помощью VPN-туннелей, построенных на оборудовании FortiGate. Архитектура простая и понятная, но со временем клиент стал упираться в мощности.

Рассмотрим подробнее архитектуру каждого из объектов.

Архитектура сети филиала 1

В первом объекте на границе сети стоял маршрутизатор Cisco. К нему подключались два интернет-провайдера, переключение между ними выполнялось через BGP.

Подсеть принадлежала заказчику, не арендовалась у провайдера. От роутера линк шёл аж до ядра из коммутаторов Cisco, оттуда в МСЭ FortiGate 200E, а затем — внутрь инфраструктуры.

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

Архитектура сети филиала 2

Во втором объекте архитектура была проще. Здесь два интернет-провайдера подключались напрямую к устройству FortiGate, которое выполняло функции маршрутизатора и файрвола. Здесь уже не было BGP, был только default-route.

За отказоустойчивость доступа в интернет отвечал SD-WAN от FortiGate, который переключал каналы при сбоях. Из МСЭ трафик шёл в ядро. Далее по классике древовидных топологий линки спускались на уровень ниже, а оттуда — ещё ниже.

Архитектура сети филиала 3

В третьем объекте FortiGate также был основным сетевым устройством на границе периметра. Интернет подключался через default-route. Структура была простой: провайдер → МСЭ → ядро.

Как видно из описаний архитектуры объектов, компания позаботилась об устойчивости интернет-соединения: даже в самом маленьком подразделении на 20 человек было подключено два провайдера.

Начало переноса

Мы решили начать переход с пограничных маршрутизаторов на всех объектах: на первом заменить Cisco, а на остальных установить роутеры перед МСЭ. Для реализации выбрали Eltex, как самый популярный и перспективный вариант.

Перед переносом мы составили план. В нем обозначили, к чему хотим прийти, получили следующую типовую схему, к которой потом стремились во всех филиалах:

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

Организация ЦОД

Для выполнения всех поставленных задач требовался единый дата-центр. Он должен был управлять всеми VPN-сетями, защищать серверы и контролировать BGP-сеть, идущую от первого филиала. Для ЦОД мы выбрали схему, аналогичную тем, что использовали для других объектов: Ядро → МСЭ → Свич → Роутеры.

Выбор сетевых устройств был очевиден — Eltex. Причины простые: ассортимент, сертификация, функционал. Подробнее о решениях вендора мы рассказали в нашей статье «Всё про Eltex в 2025».

В качестве ядра сети мы выбрали коммутатор MES5448, который на тот момент был одним из самых мощных.

В качестве роутеров также взяли самые мощные на тот момент — Eltex ESR1511, так как каждый из них должен был работать DMVPN-хабом для трёх объектов. Кроме того, заказчик предупредил, что в будущем он откроет новые филиалы, и нагрузка увеличится.

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

Когда мы уже начали внедрять решение, заказчик захотел проложить «тёмное волокно» от  структурной единицы 1 до ЦОД. Мы учли эти изменения и скорректировали топологию, которая теперь стала выглядеть так:

Впоследствии мы решим проложить ещё одно «тёмное волокно» между  структурной единицей 2 и ЦОД. Причины этого решения опишем далее.

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

Процесс прошёл гладко, за исключением проблемы с настройкой OSPF между Eltex и UserGate. Здесь мы столкнулись с тем, что устройства не могли найти друг друга, когда использовались нестандартные значения таймеров. Поэтому, чтобы не откладывать настройку, мы решили временно откатиться к стандартным значениям таймеров.

По факту мы получили следующую схему:

Особенности настройки Eltex и интеграции

Мы начали интеграцию сразу после того, как закупили технику. В первом подразделении стояли устройства Cisco, HP и FortiGate, их надо было связать с маршрутизаторами и коммутаторами Eltex.

Совместимость оборудования требовала настройки и проверки, но мы стартовали без сложностей.

С коммутаторами работа шла стабильно, что, впрочем, и ожидалось, благодаря стандартам взаимодействия и поддерживаемым протоколам. Маршрутизаторы также не вызвали сложностей на начальном этапе.

Но 2023 год был насыщенным для Eltex: вендор выпускал новые функции, выявляя и устраняя программные ошибки. Большинство задач производитель решал быстро, но, видимо, один из багов ускользнул от внимания разработчиков. Расскажем о нём подробнее.

Маршрутизатор, установленный на границе периметра в филиале 1 и участвующий в DMVPN-облаке, работал стабильно, пока я случайно не пинганул несуществующий IP-адрес из пространства DMVPN.

Пинг несуществующего IP-адреса вызвал сбой: устройство потеряло доступ в интернет, VPN-соединения разорвались, а управление маршрутизатором стало недоступным. Это произошло в рабочее время, поэтому вопрос пришлось решать срочно.

К решению подходили по-разному: тушили интерфейсы, включали и выключали VPN. Но это не помогало: внутренний функционал мониторинга трафика показывал, что по всем портам летят сотни broadcast-пакетов для DMVPN-сети.

Решить задачу получилось только с помощью хард-ресета, после которого маршрутизатор загрузился, подключился к DMVPN и возобновил работу.

Дальнейший анализ показал, что проблема была в прошивке маршрутизатора, проявляется она только при выполнении конкретного действия — пинга в отсутствующий IP внутри VPN. Мы решали вопрос с технической поддержкой, которая причины понять не смогла, но выдала тестовую прошивку, в которой этот баг уже починили.

Ещё мы столкнулись с ошибкой памяти на коммутаторе ядра, но в тот же день получили прошивку, в которой все исправили. Эта ошибка была разовой.

Также нам пришлось учитывать различия в настройках оборудования разных вендоров. Например, обозначения OSPF-area у Eltex и других производителей отличались, что требовало внимательного изучения документации. Однако это не было трудностью  — скорее, обычной задачей по интеграции разнородных устройств.

Хотя весь скелет топологии фактически был построен на отечественном оборудовании, настройка и эксплуатация системы оказались проще, чем мы ожидали. Но всё же без нюансов не обошлось. Расскажем о них подробнее.

Работа с BGP и редистрибуцией маршрутов

У заказчика была подсеть BGP, которую нужно было анонсировать. И на практике проявилась одна особенность: редистрибуция маршрутов в BGP реализуется только с использованием route-map. Даже если route-map пустые, они всё равно обязательны для редистрибуции. Если игнорировать этот момент, маршруты не анонсируются.

Сложности с VPN и нестабильные прошивки Eltex

При настройке VPN на старых версиях прошивок мы заметили, что соединение работает нестабильно. Причиной оказались недоработки программного обеспечения.

На этом этапе мы поняли, что для более стабильной связи между узлами необходимо дополнительное «тёмное волокно». Наша практика показывала, что это обоснованное решение, так как ранее мы уже сталкивались с одним страшным багом — штормом пакетов при пинге несуществующего IP-адреса из VPN-сети.

Продолжая тему настройки VPN, расскажу об интересной закономерности: на Eltex в s2s GRE один раз в сутки возникает разрыв соединения, длящийся секунды. Но если настроить IP SLA до второго узла, с которым организован туннель, проблема исчезает.

Эта практика не только стала для нас стандартом, но и позволила избавиться от сбоев VPN-соединения. Почему такие сбои происходят — ответ на этот вопрос мы пока не нашли. Но решение, которое мы применяем, на практике эффективно.

Ошибки после обновлений прошивки Eltex

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

Несмотря на мелкие ошибки и сложности, сетевая инфраструктура Eltex проявила себя стабильно. Мы не зафиксировали критических падений по питанию, конфигурации сохранялись без сбоев, обновления проходили просто и быстро.

Проблемы с аппаратной частью UserGate

При настройке UserGate, который мы использовали как брандмауэр, оказалось, что одна из двух нод для ЦОД вроде бы включалась, но никакой индикации и жизни в интерфейсах не было.

Мы отправили ноду производителю. Там её проверили, сказали, что это сбой в оперативной памяти, и вернули. Но она снова не завелась, пришлось отправлять её ещё раз. На второй раз нам привезли уже рабочую ноду и извинились.

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

Неожиданные сложности кластером UserGate

Главная беда UserGate — его кластер. Да, он функционален, работает и на моей памяти не отваливался ни разу. Но проблемы вытекают из логики работы устройства внутри кластера.

Напомню, что в сетевой архитектуре внутри ЦОД мы использовали OSPF, ядром которого был MES5448, по совместительству являющийся ядром сетевого контура. И тут обнаружилась особенность UserGate — в режиме кластера каждая нода ощущает себя отдельным OSPF-устройством.

По большому счёту затруднения в этом нет — поиграть с приоритетами и дело с концом. Но всё это банально было видно на контрастах — уезжали-то с фортиков.

Также, хотя в данном проекте нам это было не нужно, но я обязан рассказать: настраивать VPN на основе кластера — это головная боль. Вместо одного туннеля с мастер-ноды каждый из Юзергейтов в кластере начинает строить свой туннель с идентичными вводными.

Обойти эту особенность можно с помощью NAT, тогда будет всего один туннель. Но об этом у вендора нигде не написано.

Объяснили, что такое кластер UserGate и как он работает.

Заключение

С момента, когда мы начали работать с заказчиком, и до сегодняшнего дня прошло полтора года. За это время мы установили и настроили оборудование, а потом наблюдали за его работой. Обобщим этапы, через которые мы прошли:

• Этап 1 — проектирование. Провели аудит существующей сети, разработали схемы и топологии будущей инфраструктуры.
• Этап 2 — замена пограничных устройств. Заменили Cisco на Eltex, установили оборудование Eltex перед FortiGate, провели настройку корректного взаимодействия.
• Этап 3 — построение ЦОД. Согласовали топологию, собрали стойки, настроили базовые параметры и сетевые соединения с провайдером.
• Этап 4 — организация оптических каналов. Обеспечили L2-соединение между объектом 1 и ЦОД для более надёжной передачи данных.
• Этап 5 — построение VPN. Настроили DMVPN-хабы на ESR1511 в ЦОД, обеспечили резервирование соединений.
• Этап 6 — резервирование. Организовали дополнительное L2-соединение с ещё одним офисом, усложнив сеть, но повысили её надёжность.

В результате заказчик получил современную, надёжную и масштабируемую инфраструктуру: собранный кластер стабильно работает уже полтора года, обеспечивая безопасность в ЦОД.

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

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

Оборудование Eltex превзошло ожидания. Перед выбором вендора мы изучали форумы, где было много информации о забагованности. Но нас обнадёживало то, что большая часть негатива концентрировалась годом ранее. Мы сделали ставку на обновление ПО и рост компании и не пожалели.

Спустя полтора года работ у нас даже осталось ощущение недосказанности: мы ожидали критичных проблем, но в итоге столкнулись с единичными, быстро решаемыми багами.

UserGate также показал себя неплохо. Определённые сложности были, но они возникали до использования в проде и даже до установки в стойку. Сейчас межсетевой экран продолжает работать в ЦОД, а собранный нами кластер стабильно решает вопросы безопасности.

Мы собрали в бесплатный онлайн-курс наш опыт настройки и эксплуатации UserGate. В нем пошаговые инструкции и реальные сценарии: