Какое оборудование требуется для диагностики криптошлюза

1

Опыт внедрения криптошлюзов ViPNet в ЕРИС

ЕРИС (Единый Радиологический Информационный Сервис) представляет собой информационную систему, объединяющую высокотехнологичную медицинскую технику, рабочие места рентгенологов и единый архив диагностических изображений. В настоящее время ЕРИС объединяет магнитно-резонансные, цифровые аппараты классического рентгена, аппараты для проведения флюорографии и компьютерные томографы в 64 поликлиниках города Москвы, включая амбулаторные учреждения Зеленограда.

Основные задачи ЕРИС — повысить эффективность лучевой диагностики в Москве, создать единую сеть, объединяющую диагностическую аппаратуру, обеспечить современную и надежную систему хранения получаемых в результате исследований изображений, описаний и заключений.

Необходимость применения криптошлюзов

Так как в информационной системе ЕРИС обрабатываются персональные данные пациентов, то необходимо выполнять требования ФЗ-152 «О персональных данных» и подзаконных актов, связанных с этим законом. Одним из требований по защите персональных данных является организация защищенных каналов связи с помощью средств криптографической защиты информации (СКЗИ). В соответствии с этим требованием мы приступили к проектированию системы защиты персональных данных в целом и СКЗИ в частности.

Критерии выбора, схема тестирования, пилот, финальный выбор

Нашей компании Элефус Заказчик в лице компании Лаваль выдвинул ряд требований, которым должны были соответствовать СКЗИ, среди них основные:

• задержки в канале (это был самый важный критерий, потому что медицинский персонал с помощью клиентского приложения на рабочем месте подключается к серверной части в ЦОДе, и задержки в канале сильно влияют на производительность системы и скорость работы с пациентом);
• наличие сертификата ФСБ России на криптосредства (требование нормативных документов, касающихся защиты персональных данных (Приказ ФСБ №378 от 10 июля 2014 г. «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности»));
• масштабируемость решения (предполагается расширение системы на дополнительные объекты, поэтому мы изначально должны были заложить оборудование с запасом и возможность масштабирования как горизонтального, так и вертикального);
• отказоустойчивость (если вы были в московских поликлиниках, то прекрасно знаете, что очередь в радиологические кабинеты всегда присутствует, поэтому немаловажным фактором было обеспечение отказоустойчивости решения);
• достаточная производительность (в радиологические кабинеты необходимо было установить оборудование небольшой производительности, но достаточное, чтобы обеспечить хороший канал связи до ЦОД, нашим ориентиром была полоса пропускания в 20 мб/с);
• мониторинг (так как инфраструктура распределена по всей Москве, необходимо обеспечить постоянный мониторинг оборудования и отслеживать нагрузки на сеть);
• простота обслуживания (выезд на объекты осуществляют инженеры широкого профиля, которые, не обладая глубокими познаниями в ViPNet (потому что это не является их основной задачей), должны решить проблему на месте по инструкции).

• ViPNet Coordinator;
• АПКШ «Континент»;
• КриптоПро IPsec;
• МагПро КриптоПакет исполнение «OpenVPN-ГОСТ»

Схема тестирования была следующая:

Рисунок 1 — Схема тестирования

В ходе тестирования передавались снимки трех типов: КТ, ММГ, ПЭТКТ (они отличаются размерами файлов, частотой взаимодействия клиент-сервер), различные варианты снимков позволили смоделировать различные типы нагрузок на криптошлюзы. Замеры задержек и скорость в канале производились программами WinMTR и iperf3.

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

Дальше после взаимодействия с вендорами Заказчиком было принято финальное решение в пользу ViPNet. Оставим финальный выбор за скобками данной статьи, с технической точки зрения Континент и ViPNet практически одинаковые.

ИнфоТеКС (производитель ViPNet) предоставил для пилотного тестирования следующее оборудование:

• HW50 – 2 шт. для радиологических кабинетов
• HW1000 – 1 шт. для ЦОД

Как внедряли? Схема, сложности, преднастройка

К внедрению нам необходимо было подойти с особой тщательностью. Как я говорил выше, медицинские работники радиологических кабинетов постоянно загружены, поэтому на внедрение СКЗИ на объекте нам отводилось 15 минут. Внедрение мы проводили совместно с инженерами Лаваль, которые хорошо знали местное оборудование.

Внедрение состояло из следующих этапов:

• Преднастройка (оборудование было преднастроено нашими инженерами (выпуск и установка dst-на ПАК, настройка сетевых интерфейсов, настройка snmp-агента, заведение ПАК в ViPNet Administrator);
• Установка криптошлюзов в ЦОД (настройка альтернативного канала для того, чтобы не прерывать работы ЕРИС);
• Установка криптошлюзов в поликлиники (в 15минутный интервал инженеру необходимо было переткнуть оборудование и убедиться, что туннель в ЦОД поднят. Естественно, в идеальных случаях все происходило за минуты, но всегда есть какое-то время на то, чтобы скорректировать возникающие проблемы. В целом, 15-ти минут хватает на то, чтобы выполнить работы);
• Подключение криптошлюзов к системе мониторинга (на этом этапе выявили баг системы, о котором сообщили вендору, периодически snmp агент самопроизвольно отваливался, его приходится перезапускать. Так как мы знаем, что ViPNet работает на базе ОС Linux (Debian), мы написали скрипт, который автоматически перезапускал процесс. В новой версии ИнфоТеКС исправил этот момент).

Мониторинг. Нагрузка на процессор, оперативную память, сеть

Дальше мы покажем скриншоты из системы мониторинга, где можно посмотреть нагрузки на оборудование отдельно за полгода и отдельно за один рабочий день (ЦП, ОЗУ, сеть). Названия сетевых устройств скрыты, с точки зрения смысловой нагрузки это ни на что не влияет.

Нагрузка на ЦП

alt=»image» />
Рисунок 2 — Загрузка ЦП за полгода HW1000

Рисунок 3 — Загрузка ЦП за 1 день HW1000

Рисунок 4 — Загрузка ЦП за полгода HW50

Рисунок 5 — Загрузка ЦП за 1 день HW50

Нагрузка на оперативную память

Рисунок 6 — Загрузка ОЗУ за полгода HW1000

Рисунок 7 — Загрузка ОЗУ за 1 день HW1000

Рисунок 8 — Загрузка ОЗУ за полгода HW50

Рисунок 9 — Загрузка ОЗУ за 1день HW50

Нагрузки на сеть

Рисунок 10 — Загрузка сеть за полгода HW1000

Рисунок 11 — Загрузка сеть за 1 день HW1000

Рисунок 12 — Загрузка сеть за полгода HW50

Рисунок 13 — Загрузка сеть за 1 день HW50

Какое оборудование требуется для диагностики криптошлюза

Рисунок 1 — Схема тестирования

• HW50 – 2 шт. для радиологических кабинетов
• HW1000 – 1 шт. для ЦОД

• Преднастройка (оборудование было преднастроено нашими инженерами (выпуск и установка dst-на ПАК, настройка сетевых интерфейсов, настройка snmp-агента, заведение ПАК в ViPNet Administrator);
• Установка криптошлюзов в ЦОД (настройка альтернативного канала для того, чтобы не прерывать работы ЕРИС);
• Установка криптошлюзов в поликлиники (в 15минутный интервал инженеру необходимо было переткнуть оборудование и убедиться, что туннель в ЦОД поднят. Естественно, в идеальных случаях все происходило за минуты, но всегда есть какое-то время на то, чтобы скорректировать возникающие проблемы. В целом, 15-ти минут хватает на то, чтобы выполнить работы);
• Подключение криптошлюзов к системе мониторинга (на этом этапе выявили баг системы, о котором сообщили вендору, периодически snmp агент самопроизвольно отваливался, его приходится перезапускать. Так как мы знаем, что ViPNet работает на базе ОС Linux (Debian), мы написали скрипт, который автоматически перезапускал процесс. В новой версии ИнфоТеКС исправил этот момент).

Рисунок 3 — Загрузка ЦП за 1 день HW1000

Рисунок 4 — Загрузка ЦП за полгода HW50

Рисунок 5 — Загрузка ЦП за 1 день HW50

Рисунок 6 — Загрузка ОЗУ за полгода HW1000

Рисунок 7 — Загрузка ОЗУ за 1 день HW1000

Рисунок 8 — Загрузка ОЗУ за полгода HW50

Рисунок 9 — Загрузка ОЗУ за 1день HW50

Рисунок 10 — Загрузка сеть за полгода HW1000

Рисунок 11 — Загрузка сеть за 1 день HW1000

Рисунок 12 — Загрузка сеть за полгода HW50

Рисунок 13 — Загрузка сеть за 1 день HW50

Варианты установки криптошлюза: inline или on-a-stick (VLAN)

ViPNet в деталях: разбираемся с особенностями криптошлюза

Для начала разберемся, как это все работает. Итак, координатор ViPNet выполняет несколько функций. Во-первых, это криптошлюз (КШ), который позволяет реализовать как Site-to-site, так и RA VPN. Во-вторых, он является сервером-маршрутизатором конвертов, содержащих зашифрованные служебные данные (справочники и ключи) или данные клиентских приложений (файловый обмен, деловая почта). Кстати, именно в справочниках хранятся файлы, содержащие информацию об объектах сети ViPNet, в том числе об их именах, идентификаторах, адресах, связях. Координатор также является источником служебной информации для своих клиентов.
Помимо этого, он может туннелировать трафик от компьютеров сети, где не установлено ПО ViPNet. Кстати, специалисты, работающие с этим решением, часто называют открытые хосты не «туннелируемыми узлами», а просто «туннелями». Это может сбить с толку инженеров, которые привыкли к другим VPN-решениям, где под туннелем подразумевают PtP-соединение между КШ.

В качестве протокола шифрования в ViPNet используется IPlir, также разработанный «Инфотексом». Для инкапсуляции трафика применяются транспортные протоколы IP/241 (если трафик не покидает широковещательный домен), UDP/55777 и TCP/80 (при недоступности UDP).
В концепции построения защищенных соединений лежат так называемые «связи», которые бывают двух типов. Первые (на уровне узлов) нужны для построения защищенного соединения между узлами, вторые (на уровне пользователей) необходимы для работы клиентских приложений. Но есть исключение: узлы администратора сети ViPNet требуют обоих типов связи.
Что же может в этой схеме пойти не так? Как показывает практика, особенностей работы действительно много, и далеко не все проблемы можно решить интуитивно, без «помощи зала», а что-то нужно просто принять как данность.

(Un)split tunneling

В нашей практике нередко встречается пересечение туннелируемых адресов за разными координаторами.

Именно для таких случаев в продуктах ViPNet существует виртуализация адресов. Виртуализация – это своеобразный NAT без контроля состояния соединения один к одному или диапазон в диапазон. По умолчанию на координаторах эта функция выключена, хотя потенциальные виртуальные адреса вы можете найти в iplir.conf в строке «tunnel» после «to» в секциях соседних координаторов. Для того, чтобы включить виртуализацию глобально для всего списка, необходимо в секции [visibility] изменить параметр «tunneldefault» на «virtual». Если же хотите включить для конкретного соседа, то необходимо в его секцию [id] добавить параметр «tunnelvisibility=virtual». Также стоит убедиться, что параметр tunnel_local_networks находится в значении «on». Для редактирования виртуальных адресов параметр tunnel_virt_assignment необходимо перевести в режим «manual». На противоположной стороне нужно выполнить аналогичные действия. За настройки туннелей также отвечают параметры «usetunnel» и «exclude_from_tunnels». Результат выполненной работы можно проверить с помощью утилиты «iplirdiag», о которой я говорил выше.

Конечно, виртуальные адреса приносят некоторые неудобства, поэтому администраторы инфраструктуры предпочитают минимизировать их использование. Например, при подключении организаций к информационным системам (ИС) некоторых госорганов этим организациям выдается DST-файл c фиксированным диапазоном туннелей из адресного плана ИС. Как мы видим, пожелания подключающегося при этом не учитываются. Как вписываться в этот пул, каждый решает для себя сам. Кто-то мигрирует рабочие станции на новую адресацию, а кто-то использует SNAT на пути от хостов к координатору. Не секрет, что некоторые администраторы применяют SNAT для обхода лицензионных ограничений младших платформ. Не беремся оценивать этичность такого «лайфхака», однако не стоит забывать, что производительность самих платформ все-таки имеет предел, и при перегрузке начнется деградация качества канала связи.

Само собой, у каждого решения в IT есть свои ограничения по поддерживаемым сценариям использования, и ViPNet Coordinator не исключение. Достаточно назойливой проблемой является невозможность работы GRE (и протоколов, которые его используют) от нескольких источников к одному адресу назначения через SNAT. Возьмем, к примеру, систему банк-клиент, которая поднимает PPTP-туннель к публичному адресу банка. Проблема в том, что протокол GRE не использует порты, поэтому после прохождения трафика через NAT, socketpair такого трафика становится одинаковым (адрес назначения у нас одинаковый, протокол тоже, а трансляцию адреса источника мы только что произвели так же в один адрес). Координатор реагирует на такое блокировкой трафика на фоне ошибки 104 – Connection already exists. Выглядит это так:

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

ViPNet в деталях: разбираемся с особенностями криптошлюза

Жизнь сетевого инженера была счастливой и беззаботной, пока в ней не появился сертифицированный криптошлюз. Согласитесь, разбираться с решениями, предназначенными для шифрования каналов передачи данных по ГОСТу, задача не из легких. Хорошо, если это известные и понятные продукты. Вспомним ту же «С-Терра» (об их «С-Терра Шлюз» мы уже писали ). Но что делать с более экзотичными решениями на базе собственных протоколов шифрования, например, «Континент» (от «Кода Безопасности») или ViPNet Coordinator HW (от «Инфотекса»)? В этой статье я постараюсь облегчить погружение в мир ViPNet (про «Континент» тоже когда-нибудь поговорим) и рассказать, с какими проблемами столкнулся сам и как их решал.

Сразу оговорюсь, что мы поговорим о сертифицированной на сегодня ФСБ и ФСТЭК версии 4.2.1. В актуальных версиях 4.3.х появилось много интересного, например, DGD и измененный механизм кластеризации, обеспечивающий практически бесшовное переключение, но пока это будущее. Я не буду глубоко погружаться в недра конфигурационных команд и файлов, акцентировав внимание на ключевых командах и переменных, а подробное описание по этим «ключам» можно будет найти в документации.

Для начала разберемся, как это все работает. Итак, координатор ViPNet выполняет несколько функций. Во-первых, это криптошлюз (КШ), который позволяет реализовать как Site-to-site, так и RA VPN. Во-вторых, он является сервером-маршрутизатором конвертов, содержащих зашифрованные служебные данные (справочники и ключи) или данные клиентских приложений (файловый обмен, деловая почта). Кстати, именно в справочниках хранятся файлы, содержащие информацию об объектах сети ViPNet, в том числе об их именах, идентификаторах, адресах, связях. Координатор также является источником служебной информации для своих клиентов.
Помимо этого, он может туннелировать трафик от компьютеров сети, где не установлено ПО ViPNet. Кстати, специалисты, работающие с этим решением, часто называют открытые хосты не «туннелируемыми узлами», а просто «туннелями». Это может сбить с толку инженеров, которые привыкли к другим VPN-решениям, где под туннелем подразумевают PtP-соединение между КШ.

В качестве протокола шифрования в ViPNet используется IPlir, также разработанный «Инфотексом». Для инкапсуляции трафика применяются транспортные протоколы IP/241 (если трафик не покидает широковещательный домен), UDP/55777 и TCP/80 (при недоступности UDP).
В концепции построения защищенных соединений лежат так называемые «связи», которые бывают двух типов. Первые (на уровне узлов) нужны для построения защищенного соединения между узлами, вторые (на уровне пользователей) необходимы для работы клиентских приложений. Но есть исключение: узлы администратора сети ViPNet требуют обоих типов связи.
Что же может в этой схеме пойти не так? Как показывает практика, особенностей работы действительно много, и далеко не все проблемы можно решить интуитивно, без «помощи зала», а что-то нужно просто принять как данность.

Координатор недоступен

«У нас недоступен координатор/клиент/туннель. Что делать?» – самый частый вопрос, с которым приходят новички при настройке VipNet. Единственно верное действие в такой ситуации – включать регистрацию всего трафика на координаторах и смотреть в журнал IP-пакетов, который является важнейшим инструментом траблшутинга всевозможных сетевых проблем. Этот способ спасает в 80% случаев. Работа с журналом IP-пакетов также помогает лучше усвоить механизмы работы узлов ViPNet-сети.

Конверт не доставлен

Но журнал IP-пакетов, увы, бесполезен, когда речь заходит о конвертах. Они доставляются с помощью транспортного модуля (mftp), у которого есть свой журнал и своя очередь. Конверты по умолчанию передаются на «свой» координатор клиента (то есть тот, на котором зарегистрирован узел), и далее по межсерверным каналам, которые настроены между Координаторами (то есть не напрямую по защищенному каналу). Значит, если вы захотите отправить письмо по деловой почте, то клиент упакует его в конверт и отправит сначала на свой координатор. Далее на пути могут быть еще несколько координаторов, и только после этого конверт попадет на узел адресата.

Из этого следуют два вывода. Во-первых, между клиентами не обязательно должна проверяться связь (по нажатию на F5 и соответствующей иконки в меню) для доставки конвертов. Во-вторых, если связь межу ними все-таки проверяется, это не гарантирует доставку, так как проблема может быть в одном из межсерверных каналов.

Диагностировать прохождение конвертов межсерверным каналам или между клиентом и координатором в неочевидных случаях можно с помощью журнала и очереди конвертов, а также логов на координаторе. Также транспортный модуль VipNet-клиента можно настроить на прямую доставку конвертов, доставку через общую папку илиSMTP/POP3 (но это совсем экзотичный вариант). Погружаться в эти настройки мы не будем.

Последствия перепрошивки

Проблемной может оказаться перепрошивка на актуальную версию старых железок, которые долго лежали, например, в качестве ЗИП. В процессе может появится ошибка «unsupported hardware», которая сообщает либо о том, что у вас действительно неподдерживаемая аппаратная платформа устаревшей линейки G1 (это HW100 E1/E2 и HW1000 Q1), либо о проблемах в настройке BIOS или в некорректной информации, зашитой в DMI. Править ли самостоятельно DMI, каждый решает для себя сам, поскольку есть риск превратить оборудование в бесполезный «кирпич». С BIOS чуть проще: неверные настройки системы заключаются в выключенной функции HT (Hyper Threading) или выключенном режиме ACHI (Advanced Host Controller Interface) для HDD. Чтобы не гадать, в чем конкретно проблема, можно обратиться к флешке, с которой производится прошивка. На ней создаются файлы с диагностической информацией, в частности, в файле verbose.txt перечислены все поддерживаемые платформы с результатом сверки с вашей. Например, ошибка cpu::Vendor(#3)=='GenuineIntel' 24 times => [Failed], скорее всего, сообщает о выключенном HT. Кстати, перепрошивку часто путают с обновлением, но это разные процессы. При обновлении сохраняются все настройки, а параметры, о которых было написано выше, не проверяются. А при перепрошивке вы возвращаетесь к заводским параметрам.

Неинформативные конфиги

Основным конфигурационным файлом HW является «iplir.conf», однако он не всегда отражает текущие параметры. Дело в том, что в момент загрузки драйвера IPlir происходит интерпретация этого конфига в соответствии с заложенной логикой, и не вся информация может быть загружена в драйвер (например, при наличии конфликтов IP-адресов). Инженеры, работавшие с программным координатором для Linux, наверняка знают о существовании команды «iplirdiag», которая отображает текущие настройки узлов, прогруженные в драйвер. В HW эта команда также присутствует в режиме «admin escape».

Самые популярные выводы это:
iplirdiag -s ipsettings —node-info <идентификатор узла> ##отображение информации об узле
iplirdiag -s ipsettings —v-tun-table ##отображение всех загруженных в драйвер туннелей

Немного остановимся на режиме «admin escape». По сути это выход из ViPNet shell в bash. Тут я солидарен с вендором, который рекомендует использовать данный режим только для диагностики и вносить какие-либо модификации только под присмотром техподдержки вендора. Это вам не обычный Debian, здесь любое неосторожное движение может вывести из строя ОС, защитные механизмы которой воспримут вашу «самодеятельность» как потенциальную угрозу. В связке с заблокированным по умолчанию BIOS это обрекает вас на негарантийный (читай «дорогой») ремонт.

(Un)split tunneling

Еще один факт, который знают далеко не все: по умолчанию ViPNet-клиент работает в режиме split tunnel (когда можно указать, какой трафик заворачивать в туннель, а какой нет). У ViPNet существует технология «Открытого Интернета» (позже переименована в «Защищенный интернет-шлюз»). Многие ошибочно приписывают этот функционал координатору, а не клиенту. На клиенте, который зарегистрирован за координатором с такой функцией, создается два набора предустановленных фильтров. Первый разрешает взаимодействие только с самим координатором и его туннелями, второй – с остальными объектами, но запрещает доступ к координатору ОИ и его туннелям. Причем, согласно концепции вендора, в первом случае координатор должен либо туннелировать прокси-сервер, либо сам являться прокси-сервером. Служебный трафик, а также прием и передача конвертов (как служебных, так и приложений), работают в любой конфигурации.

Служебные порты и TCP-туннель

Однажды я столкнулся с приложением, которое ни в какую не хотело работать через координатор. Так я узнал, что у координатора есть служебные порты, по которым незашифрованный трафик блокируется без возможности какой-либо настройки. К ним относятся UDP/2046,2048,2050 (базовые службы ViPNet), TCP/2047,5100,10092 (для работы ViPNet Statewatcher) и TCP/5000-5003 (MFTP). Тут подвела функции TCP-туннеля. Не секрет, что провайдеры любят фильтровать высокие порты UDP, поэтому администраторы, стремясь улучшить доступность своих КШ, включают функцию TCP-туннеля. Ресурсы в зоне DMZ (по порту TCP-туннеля) при этом становятся недоступны. Это происходит из-за того, что порт TCP-туннеля также становится служебным, и никакие правила межсетевых экранов и NAT (Network Address Translation) на него уже не действуют. Затрудняет диагностику тот факт, что данный трафик не регистрируется в журнале IP-пакетов, как будто его вовсе нет.

Замена координатора

Рано или поздно встает вопрос о замене координатора на более производительный или временный вариант. Например, замена HW1000 на HW2000 или программного координатора – на ПАК и наоборот. Сложность заключается в том, что у каждого исполнения своя «роль» в ЦУС (Центре управления сетью). Как правильно изменить роль, не потеряв связность? Сначала в ЦУС меняем роль на новую, формируем справочники, но не отправляем(!) их. Затем в УКЦ выпускаем новый DST-файл и проводим инициализацию нового Координатора. После производим замену и, убедившись, что все взаимодействия работоспособны, отправляем справочники.

Кластеризация и сбой ноды

Горячий резерв – это must have для любой крупной площадки, поэтому на них всегда закупался кластер старших моделей (HW1000, HW2000, HW5000). Однако создание кластера из более компактных криптошлюзов (HW50 и HW100) было невозможно из-за лицензионной политики вендора. В итоге владельцам небольших площадок приходилось серьезно переплачивать и покупать HW1000 (ну, или никакой отказоустойчивости). В этом году вендор, наконец, сделал дополнительные лицензии и для младших моделей координаторов. Так что с выходом версий 4.2.x появилась возможность собирать в кластер и их.

При первичной настройке кластера можно серьезно сэкономить время, не настраивая интерфейсы в режиме мастера или командами CLI. Можно сразу вписывать необходимые адреса в конфигурационный файл кластера (failover config edit), только не забудьте указать маски. При запуске демона failover в кластерном режиме он сам назначит адреса на соответствующие интерфейсы. Многие при этом боятся останавливать демон, предполагая, что адреса сменяются на пассивные или адреса сингл-режима. Не волнуйтесь: на интерфейсах останутся те адреса, которые были на момент остановки демона.

В кластерном исполнении существует две распространенные проблемы: циклическая перезагрузка пассивной ноды и ее непереключение в активный режим. Для того чтобы понять суть этих явлений, разберемся в механизме работы кластера. Итак, активная нода считает пакеты на интерфейсе и в случае, если за отведенное время пакетов нет, отправляет пинг на testip. Если пинг проходит, то счетчик запускается заново, если не проходит, то регистрируется отказ интерфейса и активная нода уходит в перезагрузку. Пассивная нода при этом отправляет регулярные ARP-запросы на всех интерфейсах, описанных в failover.ini (конфигурационный файл кластера, где указаны адреса, которые принимает активная и пассивная ноды). Если ARP-запись хоть одного адреса пропадает, то пассивная нода переключается в активный режим.

Вернемся к кластерным проблемам. Начну с простого – неперключение в активный режим. В случае если активная нода отсутствует, но на пассивной в ARP-таблице (inet show mac-address-table) ее mac-адрес все еще присутствует, необходимо идти к администраторам коммутаторов (либо так настроен ARP-кэш, либо это какой-то сбой). С циклической перезагрузкой пассивной ноды немного сложнее. Происходит это из-за того, что пассивная не видит ARP-записи активной, переходит в активный режим и (внимание!) по HB-линку опрашивает соседа. Но сосед-то у нас в активном режиме и аптайм у него больше. В этот момент пассивная нода понимает, что что-то не так, раз возник конфликт состояний, и уходит в перезагрузку. Так продолжается до бесконечности. В случае возникновения данной проблемы необходимо проверить настройки IP-адресов в failover.ini и коммутацию. Если все настройки на координаторе верны, то пришло время подключить к вопросу сетевых инженеров.

Пересечения адресов

В нашей практике нередко встречается пересечение туннелируемых адресов за разными координаторами.

Именно для таких случаев в продуктах ViPNet существует виртуализация адресов. Виртуализация – это своеобразный NAT без контроля состояния соединения один к одному или диапазон в диапазон. По умолчанию на координаторах эта функция выключена, хотя потенциальные виртуальные адреса вы можете найти в iplir.conf в строке «tunnel» после «to» в секциях соседних координаторов. Для того, чтобы включить виртуализацию глобально для всего списка, необходимо в секции [visibility] изменить параметр «tunneldefault» на «virtual». Если же хотите включить для конкретного соседа, то необходимо в его секцию [id] добавить параметр «tunnelvisibility=virtual». Также стоит убедиться, что параметр tunnel_local_networks находится в значении «on». Для редактирования виртуальных адресов параметр tunnel_virt_assignment необходимо перевести в режим «manual». На противоположной стороне нужно выполнить аналогичные действия. За настройки туннелей также отвечают параметры «usetunnel» и «exclude_from_tunnels». Результат выполненной работы можно проверить с помощью утилиты «iplirdiag», о которой я говорил выше.

Конечно, виртуальные адреса приносят некоторые неудобства, поэтому администраторы инфраструктуры предпочитают минимизировать их использование. Например, при подключении организаций к информационным системам (ИС) некоторых госорганов этим организациям выдается DST-файл c фиксированным диапазоном туннелей из адресного плана ИС. Как мы видим, пожелания подключающегося при этом не учитываются. Как вписываться в этот пул, каждый решает для себя сам. Кто-то мигрирует рабочие станции на новую адресацию, а кто-то использует SNAT на пути от хостов к координатору. Не секрет, что некоторые администраторы применяют SNAT для обхода лицензионных ограничений младших платформ. Не беремся оценивать этичность такого «лайфхака», однако не стоит забывать, что производительность самих платформ все-таки имеет предел, и при перегрузке начнется деградация качества канала связи.

Невозможность работы GRE

Само собой, у каждого решения в IT есть свои ограничения по поддерживаемым сценариям использования, и ViPNet Coordinator не исключение. Достаточно назойливой проблемой является невозможность работы GRE (и протоколов, которые его используют) от нескольких источников к одному адресу назначения через SNAT. Возьмем, к примеру, систему банк-клиент, которая поднимает PPTP-туннель к публичному адресу банка. Проблема в том, что протокол GRE не использует порты, поэтому после прохождения трафика через NAT, socketpair такого трафика становится одинаковым (адрес назначения у нас одинаковый, протокол тоже, а трансляцию адреса источника мы только что произвели так же в один адрес). Координатор реагирует на такое блокировкой трафика на фоне ошибки 104 – Connection already exists. Выглядит это так:

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

Не забываем про время

Тему блокировок продолжаем событием номер 4 – IP packet timeout. Тут все банально: это событие возникает при расхождении абсолютного (без учета часовых поясов) времени между узлами сети ViPNet (координаторы и ViPNet-клиенты). На координаторах HW максимальная разница составляет 7200 секунд и задается в параметре «timediff» конфигурационного файла IPlir. Я не рассматриваю в этой статье координаторы HW-KB, но стоит отметить, что в версии KB2 timediff по умолчанию 7 секунд, а в KB4 – 50 секунд, и событие там может генерироваться не 4, а 112, что, возможно, собьет с толку инженера, привыкшего к «обычным» HW.

Нешифрованный трафик вместо зашифрованного

Новичкам бывает сложно понять природу 22 события – Non-encrypted IP Packet from network node – в журнале IP-пакетов. Оно означает, что координатор ждал с этого IP-адреса шифрованный трафик, а пришел нешифрованный. Чаще всего это происходит так:

1) пользователь забыл залогиниться в ViPNet-клиент, или случайно разлогинился, но при этом пытается попасть на защищаемые ресурсы. В этом случае драйвер IPlir неактивен, а трафик, который по маршрутизации дошел до координатора, не был зашифрован на АРМ пользователя. По заголовкам пакета координатор видит, что все легально: адрес источника принадлежит АРМ с ViPNet-клиентом, адрес назначения – защищенному или туннелируемому узлу. Значит, и трафик должен приходить зашифрованным, но это не так, поэтому его надо заблокировать. Частным случаем данного сценария является ситуация, когда в сети поменялись адреса, и на том адресе, на котором был защищенный ViPNet-клиент, АРМ оказался туннелируемый. Но координатор все еще считает, что на этом адресе есть ViPNet-клиент, и поэтому нешифрованный трафик блокируется;

2) с одной стороны взаимодействия отсутствуют связи. Например, вы связали два координатора, а справочники и ключи отправили только на один (или до второго они не дошли). В этом случае первый будет ждать зашифрованный трафик, но второй, так как не знает о существовании первого, будет присылать только незашифрованный;

3) туннели прописываются вручную локально на КШ. Чтобы смоделировать такой сценарий, нужно два связанных координатора. На одном прописываем собственные туннели и туннели соседа, на втором «забываем» это сделать. При такой настройке трафик, исходящий от туннелей второго координатора к туннелям первого, шифроваться не будет, и на первом координаторе возникнет 22 событие.

Обработка прикладных протоколов (ALG)

На многих межсетевых экранах, включая ViPNet Coordinator, могут возникать проблемы с прохождением SIP через NAT. С учетом того, что виртуальные адреса – это внутренний NAT, проблема может возникать, даже когда в явном виде NAT не используется, а используются только виртуальные адреса. Координатор обладает модулем обработки прикладных протоколов (ALG), который должен эти проблемы решать, но не всегда это работает так, как хотелось бы. Не буду останавливаться на механизме работы ALG (на эту тему можно написать отдельную статью), принцип одинаков на всех МСЭ, изменяются лишь заголовки прикладного уровня. Для корректной работы протокола SIP через координатор необходимо знать следующее:

• при использовании NAT должен быть включен ALG;
• при использовании виртуальной адресации ALG должен быть включен на обоих узлах, участвующих во взаимодействии (координатор-координатор, координатор-клиент), даже если виртуальная видимость установлена только с одной стороны;
• при использовании реальной видимости и отсутствии NAT необходимо выключить ALG для того, чтобы он не вмешивался в работу SIP;
• ALG-линейки 3.х и 4.х несовместимы (строго говоря, в линейке 3.х вообще не было возможности как-то им управлять). В таком сценарии гарантировать корректную работу SIP вендор не может.

Управляется модуль командами группы «alg module» из привилегированного режима (enable).

В заключение

Я постарался рассмотреть самые злободневные проблемы, обозначить их корни и рассказать о решениях. Конечно, это далеко не все особенности VipNet, поэтому рекомендую не стесняться – обращаться в поддержку и спрашивать совета в коммьюнити (на форуме вендора, в телеграмм-канале, в комментариях под этим постом). А если вам не хочется погружаться во все сложности работы с ViPNet или это слишком трудозатратно, то всегда можно отдать управление вашей ViPNet-сетью в руки профессионалов.

Автор: Игорь Виноходов, инженер 2-ой линии администрирования «Ростелеком-Солар»

Какое оборудование требуется для диагностики криптошлюза

ЕРИС (Единый Радиологический Информационный Сервис) представляет собой информационную систему, объединяющую высокотехнологичную медицинскую технику, рабочие места рентгенологов и единый архив диагностических изображений. В настоящее время ЕРИС объединяет магнитно-резонансные, цифровые аппараты классического рентгена, аппараты для проведения флюорографии и компьютерные томографы в 64 поликлиниках города Москвы, включая амбулаторные учреждения Зеленограда.

Основные задачи ЕРИС — повысить эффективность лучевой диагностики в Москве, создать единую сеть, объединяющую диагностическую аппаратуру, обеспечить современную и надежную систему хранения получаемых в результате исследований изображений, описаний и заключений.

Необходимость применения криптошлюзов

Так как в информационной системе ЕРИС обрабатываются персональные данные пациентов, то необходимо выполнять требования ФЗ-152 «О персональных данных» и подзаконных актов, связанных с этим законом. Одним из требований по защите персональных данных является организация защищенных каналов связи с помощью средств криптографической защиты информации (СКЗИ). В соответствии с этим требованием мы приступили к проектированию системы защиты персональных данных в целом и СКЗИ в частности.

Критерии выбора, схема тестирования, пилот, финальный выбор

Нашей компании Элефус Заказчик в лице компании Лаваль выдвинул ряд требований, которым должны были соответствовать СКЗИ, среди них основные:

• задержки в канале (это был самый важный критерий, потому что медицинский персонал с помощью клиентского приложения на рабочем месте подключается к серверной части в ЦОДе, и задержки в канале сильно влияют на производительность системы и скорость работы с пациентом);
• наличие сертификата ФСБ России на криптосредства (требование нормативных документов, касающихся защиты персональных данных (Приказ ФСБ №378 от 10 июля 2014 г. «Об утверждении состава и содержания организационных и технических мер по обеспечению безопасности персональных данных при их обработке в информационных системах персональных данных с использованием средств криптографической защиты информации, необходимых для выполнения установленных правительством Российской Федерации требований к защите персональных данных для каждого из уровней защищенности»));
• масштабируемость решения (предполагается расширение системы на дополнительные объекты, поэтому мы изначально должны были заложить оборудование с запасом и возможность масштабирования как горизонтального, так и вертикального);
• отказоустойчивость (если вы были в московских поликлиниках, то прекрасно знаете, что очередь в радиологические кабинеты всегда присутствует, поэтому немаловажным фактором было обеспечение отказоустойчивости решения);
• достаточная производительность (в радиологические кабинеты необходимо было установить оборудование небольшой производительности, но достаточное, чтобы обеспечить хороший канал связи до ЦОД, нашим ориентиром была полоса пропускания в 20 мб/с);
• мониторинг (так как инфраструктура распределена по всей Москве, необходимо обеспечить постоянный мониторинг оборудования и отслеживать нагрузки на сеть);
• простота обслуживания (выезд на объекты осуществляют инженеры широкого профиля, которые, не обладая глубокими познаниями в ViPNet (потому что это не является их основной задачей), должны решить проблему на месте по инструкции).

• ViPNet Coordinator;
• АПКШ «Континент»;
• КриптоПро IPsec;
• МагПро КриптоПакет исполнение «OpenVPN-ГОСТ»

Схема тестирования была следующая:

Рисунок 1 — Схема тестирования

В ходе тестирования передавались снимки трех типов: КТ, ММГ, ПЭТКТ (они отличаются размерами файлов, частотой взаимодействия клиент-сервер), различные варианты снимков позволили смоделировать различные типы нагрузок на криптошлюзы. Замеры задержек и скорость в канале производились программами WinMTR и iperf3.

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

Дальше после взаимодействия с вендорами Заказчиком было принято финальное решение в пользу ViPNet. Оставим финальный выбор за скобками данной статьи, с технической точки зрения Континент и ViPNet практически одинаковые.

ИнфоТеКС (производитель ViPNet) предоставил для пилотного тестирования следующее оборудование:

• HW50 – 2 шт. для радиологических кабинетов
• HW1000 – 1 шт. для ЦОД

Как внедряли? Схема, сложности, преднастройка

К внедрению нам необходимо было подойти с особой тщательностью. Как я говорил выше, медицинские работники радиологических кабинетов постоянно загружены, поэтому на внедрение СКЗИ на объекте нам отводилось 15 минут. Внедрение мы проводили совместно с инженерами Лаваль, которые хорошо знали местное оборудование.

Внедрение состояло из следующих этапов:

• Преднастройка (оборудование было преднастроено нашими инженерами (выпуск и установка dst-на ПАК, настройка сетевых интерфейсов, настройка snmp-агента, заведение ПАК в ViPNet Administrator);
• Установка криптошлюзов в ЦОД (настройка альтернативного канала для того, чтобы не прерывать работы ЕРИС);
• Установка криптошлюзов в поликлиники (в 15минутный интервал инженеру необходимо было переткнуть оборудование и убедиться, что туннель в ЦОД поднят. Естественно, в идеальных случаях все происходило за минуты, но всегда есть какое-то время на то, чтобы скорректировать возникающие проблемы. В целом, 15-ти минут хватает на то, чтобы выполнить работы);
• Подключение криптошлюзов к системе мониторинга (на этом этапе выявили баг системы, о котором сообщили вендору, периодически snmp агент самопроизвольно отваливался, его приходится перезапускать. Так как мы знаем, что ViPNet работает на базе ОС Linux (Debian), мы написали скрипт, который автоматически перезапускал процесс. В новой версии ИнфоТеКС исправил этот момент).

Мониторинг. Нагрузка на процессор, оперативную память, сеть

Дальше мы покажем скриншоты из системы мониторинга, где можно посмотреть нагрузки на оборудование отдельно за полгода и отдельно за один рабочий день (ЦП, ОЗУ, сеть). Названия сетевых устройств скрыты, с точки зрения смысловой нагрузки это ни на что не влияет.

Нагрузка на ЦП

alt=»image» />
Рисунок 2 — Загрузка ЦП за полгода HW1000

Рисунок 3 — Загрузка ЦП за 1 день HW1000

Рисунок 4 — Загрузка ЦП за полгода HW50

Рисунок 5 — Загрузка ЦП за 1 день HW50

Нагрузка на оперативную память

Рисунок 6 — Загрузка ОЗУ за полгода HW1000

Рисунок 7 — Загрузка ОЗУ за 1 день HW1000

Рисунок 8 — Загрузка ОЗУ за полгода HW50

Рисунок 9 — Загрузка ОЗУ за 1день HW50

Нагрузки на сеть

Рисунок 10 — Загрузка сеть за полгода HW1000

Рисунок 11 — Загрузка сеть за 1 день HW1000

Рисунок 12 — Загрузка сеть за полгода HW50

Рисунок 13 — Загрузка сеть за 1 день HW50

Какое оборудование требуется для диагностики криптошлюза

Рисунок 1 — Схема тестирования

• HW50 – 2 шт. для радиологических кабинетов
• HW1000 – 1 шт. для ЦОД

• Преднастройка (оборудование было преднастроено нашими инженерами (выпуск и установка dst-на ПАК, настройка сетевых интерфейсов, настройка snmp-агента, заведение ПАК в ViPNet Administrator);
• Установка криптошлюзов в ЦОД (настройка альтернативного канала для того, чтобы не прерывать работы ЕРИС);
• Установка криптошлюзов в поликлиники (в 15минутный интервал инженеру необходимо было переткнуть оборудование и убедиться, что туннель в ЦОД поднят. Естественно, в идеальных случаях все происходило за минуты, но всегда есть какое-то время на то, чтобы скорректировать возникающие проблемы. В целом, 15-ти минут хватает на то, чтобы выполнить работы);
• Подключение криптошлюзов к системе мониторинга (на этом этапе выявили баг системы, о котором сообщили вендору, периодически snmp агент самопроизвольно отваливался, его приходится перезапускать. Так как мы знаем, что ViPNet работает на базе ОС Linux (Debian), мы написали скрипт, который автоматически перезапускал процесс. В новой версии ИнфоТеКС исправил этот момент).

Рисунок 3 — Загрузка ЦП за 1 день HW1000

Рисунок 4 — Загрузка ЦП за полгода HW50

Рисунок 5 — Загрузка ЦП за 1 день HW50

Рисунок 6 — Загрузка ОЗУ за полгода HW1000

Рисунок 7 — Загрузка ОЗУ за 1 день HW1000

Рисунок 8 — Загрузка ОЗУ за полгода HW50

Рисунок 9 — Загрузка ОЗУ за 1день HW50

Рисунок 10 — Загрузка сеть за полгода HW1000

Рисунок 11 — Загрузка сеть за 1 день HW1000

Рисунок 12 — Загрузка сеть за полгода HW50

Рисунок 13 — Загрузка сеть за 1 день HW50

Варианты установки криптошлюза: inline или on-a-stick (VLAN)

ViPNet в деталях: разбираемся с особенностями криптошлюза

Для начала разберемся, как это все работает. Итак, координатор ViPNet выполняет несколько функций. Во-первых, это криптошлюз (КШ), который позволяет реализовать как Site-to-site, так и RA VPN. Во-вторых, он является сервером-маршрутизатором конвертов, содержащих зашифрованные служебные данные (справочники и ключи) или данные клиентских приложений (файловый обмен, деловая почта). Кстати, именно в справочниках хранятся файлы, содержащие информацию об объектах сети ViPNet, в том числе об их именах, идентификаторах, адресах, связях. Координатор также является источником служебной информации для своих клиентов.
Помимо этого, он может туннелировать трафик от компьютеров сети, где не установлено ПО ViPNet. Кстати, специалисты, работающие с этим решением, часто называют открытые хосты не «туннелируемыми узлами», а просто «туннелями». Это может сбить с толку инженеров, которые привыкли к другим VPN-решениям, где под туннелем подразумевают PtP-соединение между КШ.

В качестве протокола шифрования в ViPNet используется IPlir, также разработанный «Инфотексом». Для инкапсуляции трафика применяются транспортные протоколы IP/241 (если трафик не покидает широковещательный домен), UDP/55777 и TCP/80 (при недоступности UDP).
В концепции построения защищенных соединений лежат так называемые «связи», которые бывают двух типов. Первые (на уровне узлов) нужны для построения защищенного соединения между узлами, вторые (на уровне пользователей) необходимы для работы клиентских приложений. Но есть исключение: узлы администратора сети ViPNet требуют обоих типов связи.
Что же может в этой схеме пойти не так? Как показывает практика, особенностей работы действительно много, и далеко не все проблемы можно решить интуитивно, без «помощи зала», а что-то нужно просто принять как данность.

(Un)split tunneling

В нашей практике нередко встречается пересечение туннелируемых адресов за разными координаторами.

Именно для таких случаев в продуктах ViPNet существует виртуализация адресов. Виртуализация – это своеобразный NAT без контроля состояния соединения один к одному или диапазон в диапазон. По умолчанию на координаторах эта функция выключена, хотя потенциальные виртуальные адреса вы можете найти в iplir.conf в строке «tunnel» после «to» в секциях соседних координаторов. Для того, чтобы включить виртуализацию глобально для всего списка, необходимо в секции [visibility] изменить параметр «tunneldefault» на «virtual». Если же хотите включить для конкретного соседа, то необходимо в его секцию [id] добавить параметр «tunnelvisibility=virtual». Также стоит убедиться, что параметр tunnel_local_networks находится в значении «on». Для редактирования виртуальных адресов параметр tunnel_virt_assignment необходимо перевести в режим «manual». На противоположной стороне нужно выполнить аналогичные действия. За настройки туннелей также отвечают параметры «usetunnel» и «exclude_from_tunnels». Результат выполненной работы можно проверить с помощью утилиты «iplirdiag», о которой я говорил выше.

Конечно, виртуальные адреса приносят некоторые неудобства, поэтому администраторы инфраструктуры предпочитают минимизировать их использование. Например, при подключении организаций к информационным системам (ИС) некоторых госорганов этим организациям выдается DST-файл c фиксированным диапазоном туннелей из адресного плана ИС. Как мы видим, пожелания подключающегося при этом не учитываются. Как вписываться в этот пул, каждый решает для себя сам. Кто-то мигрирует рабочие станции на новую адресацию, а кто-то использует SNAT на пути от хостов к координатору. Не секрет, что некоторые администраторы применяют SNAT для обхода лицензионных ограничений младших платформ. Не беремся оценивать этичность такого «лайфхака», однако не стоит забывать, что производительность самих платформ все-таки имеет предел, и при перегрузке начнется деградация качества канала связи.

Само собой, у каждого решения в IT есть свои ограничения по поддерживаемым сценариям использования, и ViPNet Coordinator не исключение. Достаточно назойливой проблемой является невозможность работы GRE (и протоколов, которые его используют) от нескольких источников к одному адресу назначения через SNAT. Возьмем, к примеру, систему банк-клиент, которая поднимает PPTP-туннель к публичному адресу банка. Проблема в том, что протокол GRE не использует порты, поэтому после прохождения трафика через NAT, socketpair такого трафика становится одинаковым (адрес назначения у нас одинаковый, протокол тоже, а трансляцию адреса источника мы только что произвели так же в один адрес). Координатор реагирует на такое блокировкой трафика на фоне ошибки 104 – Connection already exists. Выглядит это так:

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

Криптографический шлюз

Критошлюз – программный или аппаратно-программный комплекс, работающий на основе технологии VPN (Virtual Private Network – «виртуальная частная сеть») и обеспечивающий «прозрачное» шифрование информационных сетевых потоков между объектами, отдаленными друг от друга.

Использование криптографических шлюзов необходимо в том случае, если нужно обеспечить целостность и конфиденциальность передаваемых данных, которые отправляются по незащищенным или непроверенным каналам связи. VPN в таком случае может быть организована по принципу «сеть-сеть» или «сеть-удаленный пользователь». Если используется принцип «сеть-сеть», то криптографический шлюз необходимо установить с обеих сторон канала связи. В таком случае трафик между ними будет зашифрован. В случае использования принципа «сеть-удаленный пользователь» программный или аппаратный криптошлюз устанавливается на стороне сервера, пользователю достаточно лишь установить программный клиент.

Доступ к ресурсам защищенной сети

Сервер доступа (программное обеспечение криптошлюза) идентифицирует и аутентифицирует пользователей и связывает их с необходимыми узлами сети. Созданные защищенные каналы образовывают VPN-сети. Для обеспечения работы такой сети используется специализированное ПО (центр управления), которое управляет локальными политиками безопасности клиентов и отправляет всем пользователям конфигурационные данные, ведет системные журналы.

Функциональные возможности

Базовые функции криптошлюзов следующие:

• защита конфиденциальности и целостности передающихся IP-пакетов;
• аутентификация удаленных узлов и пользователей;
• скрытие топологии внутренней сети с помощью инкапсуляции трафика в зашифрованном канале передачи данных.

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

Отличия и особенности криптографических шлюзов

На сегодняшний день разработано много технологических и схемных решений для организации защищенной передачи данных через сеть. Самая распространенная технология – средство криптографической защиты класса Hub-and-Spoke, в котором каждый канал связи соединяется с центром, и Full Mesh, при котором все каналы соединяются между собой. Отдельно взятые разработчики могут по-своему реализовывать технологии использования VPN.

С точки зрения применяемых протоколов криптошлюзы с Virtual Private Network можно разделить на:

Шесть устройств для сетевого шифрования: плюсы и минусы

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

Все рассматриваемые устройства представляют собой программно-аппаратные комплексы, которые состоят из оборудования (платформы) и среды функционирования СКЗИ. Последняя, в свою очередь, включает в себя базовую ОС и криптомодуль, который и выполняет криптографические функции: шифрование, расшифровку, формирование и проверку кода аутентификации сообщения.

Нужно сразу оговориться, что в фокусе этого обзора – функция межсайтового шифрования. Дело в том, что 4 из 6 устройств в этом обзоре – это конвергентные (многоцелевые) устройства, которые, кроме собственно шифрования трафика, выполняют много других функций. Можно долго спорить о том, что лучше – специализированные средства для решения отдельных задач, или «швейцарский нож», который решает сразу несколько задач, пусть даже и ценой каких-то компромиссов. Набор этих функций может быть разным, и чтобы не ограничивать себя только одним классом устройств, а, наоборот, идти от задач, в этом обзоре все остальные функции, не относящиеся к межсайтовому шифрованию, как бы «вынесены за скобки». При желании их можно оценить и учесть отдельно.

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

С-Терра Шлюз и Шлюз 10G

Линейка Шлюз компании С-Терра обозначается как программно-аппаратный комплекс для обеспечения безопасности сети, по сути же представляет собой классический шлюз безопасности (криптошлюз, криптомаршрутизатор). Как и большинство других конвергентных устройств, устройства компании С-Терра, помимо функции сетевого шифрования, обеспечивает поддержку межсайтовых VPN, межсетевого экранирования и доступа VPN-клиентов. Модель 10G, хотя и имеет много общего с остальной линейкой, имеет другое назначение: она предназначена для защиты отдельных высокоскоростных каналов связи на L2 в линейном режиме («точка-точка»).

Шлюз / Шлюз 10G. Источник: С-Терра

Устройства состоят из аппаратной платформы (здесь есть довольно широкий выбор как по производительности, так и по конструктивному исполнению, в том числе с поддержкой сторонних АПМДЗ для исполнений, сертифицированных по классам КС2 и КС3) с предустановленным ПО и набора лицензий на криптомодуль, средства управления и поддержку. В качестве программного обеспечения аппаратных средств используется ОС Debian Linux с криптомодулем, поддерживающим набор алгоритмов ГОСТ, в том числе блочные шифры из ГОСТ Р 34.12-2015 – «Магма» и «Кузнечик».

Подобно другим шлюзам безопасности, устройства поддерживают большой набор сетевых функций и функций обеспечения безопасности. Реализован по существу весь стек протоколов IPsec, в частности, для межсайтового шифрования L3 и L2 в серии Шлюз используется протокол IPsecESP в транспортном или туннельном режиме, причем большое внимание уделяется строгому следованию RFC и российским ГОСТам.

Одна из схем подключения Шлюз. Источник: С-Терра

Шлюз 10G захватывает кадры из доверенной локальной сети, инкапсулирует их в IP, который потом шифруется тем же IPsec.

Схема подключения Шлюз 10G. Источник: С-Терра

Серия Шлюз отличается умеренной на сегодняшний день производительностью. Максимальная пропускная способность у верхней в линейке модели – около 3 Гбит/с на больших пакетах, на IMIX она составляет около 2 Гбит/с. В общем, работой на скорости линии в 10-гигабитном канале Ethernet эти устройства похвастаться не могут. Так как известны и протоколы, и режимы их работы, можно довольно точно рассчитать накладные расходы пропускной способности: для небольших пакетов они могут превышать 50%. В режиме L2 они еще больше: кадры инкапсулируются в UDP-заголовки, к которым потом добавляются новые (транспортные) IP- и MAC-заголовки.

У модели 10G пропускная способность выше: до 12 Гбит/с на больших пакетах и 10 Гбит/с на IMIX. Правда, как сообщает сама компания, речь идет о суммарной пропускной способности шифрования, то есть для симметричного полнодуплексного трафика эти цифры, видимо, нужно делить пополам, то есть и эта модель не может работать на полной скорости 10-гигабитной линии. Что касается накладных расходов, то, хотя применяемый здесь протокол инкапсуляции EtherIP отличается компактным 4-октетным заголовком, это всё же туннельный режим, и накладные расходы составляют десятки байтов на пакет. Вносимая задержка при полной нагрузке (когда устройство еще не начало терять пакеты) составляет около 1 мс. Для увеличения пропускной способности модели обеих серий могут объединяться в фермы агрегирования.

Шлюз и Шлюз 10G могут работать в сетях любых размеров, не накладывая своих ограничений на масштаб сети. Серия Шлюз отличается отменной гибкостью, причем как в сетевых возможностях, так и в криптографических алгоритмах. Поскольку используются стандартные протоколы шифрования, то Шлюз может работать в паре с шлюзами безопасности ГОСТ других производителей (такими, где тоже реализован «честный» IPsec). Кстати, помимо прочих в устройстве поддерживается и набор алгоритмов для AES, что позволяет связывать Шлюз с зарубежными устройствами IPsec. А вот Шлюз со Шлюзом 10G связать не получится: режим L2 в этих сериях реализован по-разному.

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

Для обеих серий предусмотрены разнообразные средства управления, включающие в себя интерфейс командной строки, веб-интерфейс и фирменную систему управления, которая состоит из сервера управления и клиента управления (станции администратора). Управление через сеть возможно во вне полосном (через отдельный сетевой порт устройства) и внутриполосном (через общий туннель IPsec) режимах. Интерфейс командной строки интересен тем, что содержит, кроме оболочки Linux, еще и специальную консоль с синтаксисом команд Cisco. Вообще система ориентирована на специалистов с хорошим знанием сетевых технологий. В руководстве пользователя честно написано, что «желательно обладать знаниями на уровне сертификата CCNA или аналогичного»! В частности, достаточно трудоемким процессом будет настройка соединений IPsec (правда, мастер настройки и возможность применения конфигурационных файлов облегчают его). Начальная настройка шлюзов включает в себя разумное количество ручных операций, в частности, ввод номеров лицензий и инициализация датчика случайных чисел (нажатиями на клавиши или использованием внешней гаммы). Управление ключами – централизованное автоматическое с аутентификацией на базе PKI (для этого при начальной настройке нужно сгенерировать и установить на каждый шлюз безопасности сертификат). В качестве внутреннего удостоверяющего центра используется Microsoft CA, внешние тоже поддерживаются.

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

Модели серии Шлюз в зависимости от состава оборудования и набора лицензий будет стоить до 1,3 млн рублей, Шлюз 10G – примерно 3,6 млн рублей.

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

• слабую производительность: большую задержку, низкую пропускная способность, большие накладные расходы
• сложное управление: обилие настроек, ручное управление зашифрованными соединениями, высокие требования к квалификации персонала, сложность разграничения задач между ИБ и ИТ
• ограниченную гибкость в сценариях подключения модели Шлюз 10G
• ограниченную совместимость с сетями L2

ViPNet Coordinator HW

Это семейство устройств, разработанных компанией «ИнфоТеКС». Производитель называет их шлюзами безопасности. Устройства являются частью фирменной архитектуры сетевой безопасности ViPNet. Выполняют функции VPN-шлюза сетевого (L2) и канального (L2) уровней. Кроме того, они обеспечивают фильтрацию трафика (являясь межсетевыми экранами) и поддерживают большой набор сетевых функций L3 и L2. В общем, их тоже можно отнести к той же категории конвергентных устройств российского производства. Текущее поколение продукта – четвертое.

Продукт состоит из специализированной сетевой платформы (до 8 гигабитных и 10-гигабитных портов в зависимости от модели) и криптомодуля, разработанного «Инфотекс». В качестве базовой ОС используется Linux.

ViPNet Coordinator HW5000. Источник: ИнфоТеКС

В устройствах применяется фирменный протокол сетевого шифрования – разработчик иногда называет его IPlir. Одно время «ИнфоТеКС» даже предпринимал попытки стандартизовать его в рамках комитета ТК26. Протокол использует инкапсуляцию зашифрованных блоков данных в нестандартный протокол с номером 241 в заголовке IP. Этот протокол используется, когда смежные шлюзы находятся в одном широковещательном домене и могут без проблем найти друг друга, в этом случае обнаружение и поддержание связи между шлюзами происходит автоматически. Если же устройства находятся в разных подсетях, в том числе за NAT, то блок данных инкапсулируется в UDP или (если связи по этому протоколу нет) в TCP.

Схема подключения ViPNet Coordinator HW. Источник: ИнфоТеКС

При организации связи на L2 используется обычный подход L2overIPс захватом кадров из локального сегмента, их инкапсуляцией в IP-пакеты и отправкой этих пакетов другому шлюзу в нужный сегмент на другой стороне сети. Устройство обрабатывает и передает все широковещательные и все однонаправленные кадры с известными (заученными) адресами, а кадры с неизвестными либо передает во все порты, либо сбрасывает. При этом не должно быть альтернативных маршрутов на любом из уровней сети в сегменты L2, иначе, как об этом предупреждают в руководстве, «это может парализовать работу всей сети»! Количество подключаемых сегментов L2 (портов виртуального коммутатора) не может превышать 31, кроме того, в этом режиме рекомендуется придерживаться (по соображениям производительности) максимального количества 252 IP-адресов.

В целом такой подход годится для построения виртуальной частной сети L2 (в том числе через сеть L3) для некоторых сценариев, но не обеспечивает интеграции защищенных сегментов с опорной сетью L2 для построения масштабных сетей L2.

Схема подключения ViPNet Coordinator HW на L2. Источник: ИнфоТеКС

Интересно, что в качестве криптографического алгоритма используется старый ГОСТ 28147–89 в режиме гаммирования (CTR) или гаммирования с обратной связью по шифротексту (CFB), а не разработанный при участии «ИнфоТеКСа» «Кузнечик».

Согласно опубликованным данным, производительность шифрования на старших моделях достигает 6,8 Гбит/с, то есть на скорости 10-гигабитной линии и эти устройства работать не могут. Правда, «ИнфоТеКС» заявляет, что использует свою методику тестирования, так что неясно, к трафику какого профиля относятся эти цифры. В режиме L2 производительность падает примерно на 15-20 %. Накладные расходы при использовании инкапсуляции в IP должны быть невелики (хотя открытых данных с форматами пакетов нет), но при инкапсуляции в UDP они неизбежно возрастают, и будут сравнимы с накладными расходами IPsec в туннельном режиме. Для повышения пропускной способности можно агрегировать порты на самом устройстве, а также (в режиме L2) объединять устройства в фермы внутри агрегированного канала.

Архитектура ViPNet вместо простых туннелей «точка-точка» позволяет создавать виртуальные частные сети с замысловатой структурой, сложными правилами адресации и маршрутизации, резервированием, приоритизацией и так далее. Благодаря этому поддерживается большое разнообразие сценариев межсайтового шифрования, в том числе федерация разных защищенных сетей ViPNet. Так как всё это работает поверх обычной IP-сети, где тоже есть свои настройки, понятно, что простоты в эксплуатации это не добавляет. Фактически появляется отдельная самостоятельная задача по планированию, развертыванию и сопровождению защищенной сети, требующая хороших знаний сетевых технологий, и вопрос в том, на кого эту задачу возложить.

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

У шлюзов нет резервирования важнейших узлов (таких, как блоки питания), заявленное время наработки на отказ – 50 тыс. часов. Для защиты от отказов можно использовать кластер «активный-пассивный» с быстрым (порядка нескольких секунд) переключением, а также агрегацию портов на устройстве и резервирование внешних каналов.

Цена старшей модели составляет 2 млн. рублей.

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

• низкая производительность: пропускная способность не дотягивает до 10 Гбит/с, работа на скорости линии не поддерживается
• ограниченная функциональность, производительность и масштабируемость L2
• сложное управление структурой и настройками защищенной сети
• ручная настройка сегментов L2
• ручное управление ключами
• ограниченная защита от физического вскрытия

АПКШ «Континент»

Это семейство продуктов, разработанное компанией «Код безопасности», позиционируется как «централизованный комплекс для защиты сетевой инфраструктуры и создания VPN-сетей с использованием алгоритмов ГОСТ». Это конвергентное устройство с набором алгоритмов ГОСТ и обычным набором функций, включая межсайтовое шифрование (оно нас интересует прежде всего) в сочетании с VPN, шлюз доступа VPN-клиентов, межсетевой экран и систему обнаружения вторжений. Текущая версия продукта – 3.9 (именно ее и будем рассматривать в обзоре), но поставляется и предыдущая версия 3.7, и уже представлена (но пока не сертифицирована в ФСБ и не поставляется) следующая версия – 4.

Итак, семейство построено на базе сетевых платформx86 (как обычно, в компактных и стоечных корпусах) под управлением ОС FreeBSD. Производительность шифрования, а также некоторые функциональные возможности определяются выбранной моделью платформы в сочетании с набором лицензий. В зависимости от модели есть от 3 до 16 сетевых интерфейсов, что позволяет реализовывать разнообразные конфигурации (подключение к одному шлюзу нескольких защищенных сегментов, подключение к нескольким внешним каналам, агрегация каналов и прочее). Платформы оснащены датчиками вскрытия и АПМДЗ. В одной из моделей используется криптоускоритель на FPGA.

АПКШ «Континент» IPC-3000FC. Источник: Код безопасности

Для межсайтового шифрования используется ГОСТ 28147-89 в режиме гаммирования с обратной связью (CFB) с имитозащитой по тому же ГОСТу. Межсайтовое шифрование L3 работает в сочетании с VPN и фильтрацией пакетов. Используется фирменный протокол L3 туннельного режима (инкапсуляция IP-пакетов в UDP). Редкая функция – это сжатие IP-пакетов по алгоритму Deflate (причем можно устанавливать минимальную длину шифруемых пакетов), она должна компенсировать накладные расходы.

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

Еще одна редко встречающаяся особенность – это внешнее подключение через телефонный модем (с дозвоном по требованию, как у теперь забытых дозванивающихся маршрутизаторов из 90-х годов!) и USB-модем 3G (разумеется, скорости у таких каналов соответствующие, и не все функции через них работают). Есть механизм QoS (на базе поля ToS протокола IP в режимах IPPи DSCP) c классификацией и приоритизацией трафика (правда, не для интерфейсов 10 Гбит/с).

Схема подключения АПКШ «Континент» в режиме L3. Источник: Код безопасности

В режиме шифрования L2 защищенные сегменты, подключенные к внутренним портам устройств, как бы «сшиваются» в виртуальный коммутатор с помощью туннелей между парами АПКШ. Кадры инкапсулируются в UDP и маршрутизируются через IP-сеть. По заявлению производителя, поддерживаются любые протоколы и форматы кадров Ethernet, в том числе jumboframes. Поддерживается пропускили сброс кадровотдельных служебных протоколов L2. Для маршрутизации кадров через виртуальный коммутатор используются таблицы с динамическими (заученными) и статическими MAC-адресами.

Так как компания «Код безопасности» применяет свою собственную методику измерения производительности, то с опубликованными цифрами нужно работать с осторожностью. Но, как следует из опубликованных компанией материалов, даже модель с криптоускорителем, которая работает только в режиме L2, не обеспечивает работу на скорости линии во всем диапазоне длин пакетов. Для остальных моделей с «программным» шифрованием суммарная пропускная способность зависит от модели платформы, и для старшей модели составляет 6,4 Гбит/с. Фирменный протокол шифрования из-за длинного криптографического заголовка и инкапсуляции в UDP отличается довольно высокими накладными расходами (свыше 50 байт на пакет в L3, свыше 70 в L2). Что касается вносимой задержки, то для модели с криптоускорителем она не превышает 60 мкс – очень хороший результат, достигнутый благодаря использованию FPGA. Для остальных моделей задержка существенно (в разы) больше. Для наращивания пропускной способности можно использовать фермы устройств (в качестве балансировщика может выступать либо «Континент», либо стороннее устройство) и агрегацию портов устройства.

Схема подключения АПКШ «Континент» в режиме L2. Источник: Код безопасности

С ограничениями по масштабированию можно столкнуться, пожалуй, только в режиме L2, где есть «потолок» по суммарному количеству портов виртуального коммутатора (впрочем, оно довольно велико). Заметно ограничивает гибкость то, что IPv6 можно использовать исключительно на внешних интерфейсах, причем без динамического назначения адресов. В «Континенте» есть явная поддержка некоторых сервисов L3 и L2, а с помощью механизма выборочного шифрования можно обеспечить прозрачность для некоторых других (но не всех) протоколов.

Так как используется проприетарный протокол шифрования, интероперабельности с другими производителями нет. Совместимость между текущей (3.9) и предыдущей (3.7) версиями в общем поддерживается, но с некоторыми ограничениями и неудобствами.

Управление комплексом обеспечивается с помощью фирменной трехзвенной среды управления (станция управления на ПК под Windows – АПКШ с сервером управления – управляемые устройства). Сервер управления может работать на выделенном или одном из рабочих шлюзов, в выделенном или одном из рабочих сегментов сети. С помощью этой среды происходит выработка ключей, установка VPN-туннелей, и вообще вся архитектура комплекса сильно «завязана» на сервер управления и без него не работает. Поэтому для сохранения работоспособности при отказе сервера управления предусмотрено резервное копирование его БД, а также «горячее» резервирование самого сервера.

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

Для инициализации (ввода в эксплуатацию) любого из устройств требуются клавиатура и монитор. При инициализации сервера управления нужно выполнить около десятка ручных несколько ручных операций, зато для инициализации прочих устройств сначала через среду управления создаются соответствующие им логические объекты, а уже потом конфигурация и начальный набор ключей выгружаются на внешний носитель. При первом запуске нового устройства эта конфигурация копируется и применяется к нему – в духе централизованной идеологии управления «Континентом». Установка туннелей L3 выполняется вручную, а вот связи между портами виртуального коммутатора L2 настраиваются автоматически.

Заявленное среднее время на работки на отказ для всех аппаратных платформ – 50 тыс. часов. Отказоустойчивость защищенной сети обеспечивается, во-первых, с помощью резервирования отдельных аппаратных узлов (только в старших моделях) и агрегации портов. Во-вторых, средствами кластера «активный-пассивный» со временем переключения порядка секунд (настройка кластера имеет свои особенности, но в целом не превосходит по трудоемкости добавление пары обычных шлюзов). В-третьих, путем объединения устройств в фермы. Устройства также могут обеспечивать резервирование внешних каналов.

Для управления ключами «Континента» используется централизованная система генерации и распределения ключей. Есть ключи нескольких типов: для шифрования трафика, для шифрования данных в устройстве и для защиты канала связи с сервером управления. Ключи последних двух типов генерируются, выгружаются на внешний носитель, передаются через сеть, устанавливаются, отзываются и так далее вручную, смена заранее сгенерированных ключей, а также выработка и установка ключей для защиты туннелей происходит автоматически. При так называемой усиленной схеме для генерации ключей и случайных чисел используется выделенное оффлайновое (изолированное от сети) устройство (платформа начального уровня) с АПМДЗ.

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

Цена старшей модели (с криптоускорителем) составляет почти 4 млн. рублей.

• низкая задержка и высокая пропускная способность у модели с криптоускорителем
• функция сжатия трафика
• гибкость в топологиях L3
• автоматическая настройка туннелей L2

• высокие накладные расходы при передаче трафика
• нет работы на скорости линии
• ручное конфигурирование сети, в том числе установка туннелей L3
• ручное управление ключами
• полная зависимость от сервера управления
• нет управления через веб-интерфейс и командную строку
• нет эффективных механизмов разделения ролей между ИТ и ИБ

Diamond VPN/FW

Серия многофункциональных комплексов сетевой защиты (МКСЗ), разработанных компанией TSS. Предлагается в качестве единого средства защиты от сетевых угроз, сочетает в себе межсетевой экран, средства построения зашифрованных виртуальных частных сетей и систему обнаружения вторжений. То есть это тоже типичное конвергентное устройство, напрямую конкурирующее с тремя описанными выше.

Так же точно оно состоит из ПО на основе Linuх и аппаратной платформы. Поддерживается довольно разнообразный набор оборудования, но, как и упомянутые ранее производители, TSS отдает предпочтение платформам Lanner, специально предназначенным для сетевых устройств различного назначения.

Для шифрования и построения VPN используется протокол DTLS – датаграммная, основанная на UDP разновидность TLS. По своим основным характеристикам (в частности, накладным расходам на установку туннелей и передачу данных) этот протокол примерно соответствует IPsec, отличаясь, правда, гораздо меньшей гибкостью. То есть шифрование происходит на L4, но за счет использования режимов L2overVPN и L3overVPN (очевидно, инкапсуляции) можно связывать сегменты на 2-м и 3-м уровнях сетевой модели соответственно.

Схема подключения Diamond VPN/FW. Источник: TSS

В качестве алгоритма шифрования используется ГОСТ 28147-89 с учетом рекомендаций ГОСТ Р34.12-2015, то есть фактически это «Магма». В полнодуплексном режиме старшие модели достигают пропускной способности 16 Гбит/с, но, как следует из опубликованного TSS графика производительности, она быстро падает с уменьшением размера пакета, причем это падение нельзя объяснить только накладными расходами – очевидно, устройство начинает терять пакеты. Что касается накладных расходов, то их можно оценить как средние – несколько десятков байт на пакет. Сетевая задержка, согласно опубликованным данным, не превышает 1,5 мс – довольно большой даже для «программного» шифрования показатель.

В довольно формальной и неудобной документации никакие ограничения на масштаб сети не указаны. Реализована явная поддержка некоторых сетевых технологий L3 (например, динамическая маршрутизация) и L2 (в частности, LACP и STP). Интероперабельность устройств на базе TLS и особенно менее популярного пока DTLS довольно слабая, так что рассчитывать на возможность взаимодействия с оборудованием других производителей не стоит.

Для управления устройствами используется обычный набор технологий: интерфейс командной строки через консольный порт или ssh, веб-интерфейс (с ограниченной функциональностью) и фирменная среда управления. Как и в описанных выше устройствах, общая идеология управления ориентирована скорее на «сетевиков», чем на «безопасников», хотя среда управления позволяет создавать собственные роли, комбинируя разные права. Управление идет через одно из устройств, которое становится ведущим – для него потребуется приобрести лицензию на управление. Начальная настройка, как и везде, идет через консоль. Автоматической установки туннелей нет, их нужно конфигурировать вручную (одно из устройств становится сервером, другое / другие – клиентом VPN). Поддерживаются АПМДЗ и дополнительные модули (платы) для внеполосного управления. Для централизованного управления ключами применяется PKI, причем используются либо встроенные в среду управления внутренние, либо сторонние УЦ.

В модельном ряду есть устройства с резервированием блоков питания, плюс поддерживаются кластеры «активный-пассивный», агрегация портов и резервирование туннелей VPN (список из нескольких серверов, которые может перебирать клиент).

К плюсам решения можно отнести:

• высокую пропускную способность на длинных пакетах
• автоматическое управление ключами

• большую вносимую задержку
• падение производительности на коротких пакетах
• ручную настройку туннелей
• неудобную документацию

Недавно компания TSS объявила о подготовке к выпуску устройства шифрования нового поколения под условным пока названием Dcrypt XG. Для этого устройства заявлена:

• высокая пропускная способность (до 100 Гбит/с)
• низкие задержки (20 микросекунд)
• алгоритм ГОСТ «Магма»
• аппаратные модули шифрования (криптоускорители)

Так как официальная спецификация на этот продукт отсутствует, он пока оставлен за рамками обзора (были выбраны только уже поставляемые, присутствующие на рынке модели). Согласно плану развития Dcrypt XG, его доведение до полной функциональности запланировано на август 2020 года.

«Квазар»

Интересная серия устройств, разработанных компанией СПБ (сейчас она входит в группу компаний «ИнфоТеКС»). Это единственное на сегодняшний день решение с ГОСТ для шифрования L1 в синхронных оптических сетях. Устройства называются модулями шифрования и встроены в транспондеры и мукспондеры (мультиплексирующие/агрегирующие транспондеры) для сетей OTN. Хотя OTN относится к другому, нежели Ethernet, стеку технологий, в качестве одного из клиентских (подключаемых со стороны локальной сети) интерфейсов можно использовать Ethernet, поверх которого можно пустить любые протоколы верхних уровней. То есть такой защищенный оптический канал (или даже оптическую сеть) можно использовать в качестве одного из сегментов опорной сети Ethernet L2 или L3. Вот почему мы рассматриваем здесь это устройство наравне с другими, принимая во внимание все его плюсы и минусы.

«Квазар» H-172A. Источник: ИнфоТеКС

Итак, этот комплекс предназначен для криптографической защиты магистральных каналов связи на базе OTN. Он помещает протокольные блоки данных (то есть кадры целиком) клиентских протоколов L2 в кадры (своеобразные конверты) синхронной сети, и потом шифрует их. Далее эти кадры доставляются через оптическую сеть и распаковываются модулем шифрования на другом ее конце. Сами модули выполнены либо как телекоммуникационные устройства высотой 1U и с 48-вольтным питанием, либо как модуль для шасси «Волга» компании T8. Для обработки потока данных и шифрования применяется ПЛИС. Устройства имеют 2 контроллера, подключенных к ПЛИС: один для управления потоком данных и мониторинга, другой для управления ключевой информацией (аутентификация администратора, ввод ключей, контроль, стирание).

Схема подключения «Квазар». Источник: СПБ

На операторской стороне модули используют сигнал OTU2 с битовой скоростью примерно 10 Гбит/с, что соответствует скорости клиентского интерфейса (то есть полосе пропускания Ethernet) чуть меньшей, чем 10 Гбит/с, что вынуждает использовать отдельную разновидность физического уровня Ethernet–WANPHY. Шифрование идет на полной скорости линии. Используется проверенный алгоритм ГОСТ «Магма» в режиме гаммирования. Что касается накладных расходов, то они здесь нулевые: вся избыточная информация помещается за пределами кадра Ethernet. Сетевая задержка тоже невелика, и составляет примерно 50 микросекунд.

На масштабируемость сети, построенной с элементами технологий OTN, модули шифрования никак не влияют. Разумеется, гибкость решения шифрования диктуется особенностями стандарта OTN. В качестве транспортной технологии может использоваться либо «темное» (без активного оборудования) оптоволокно, либо канал с аппаратурой частотного разделения (DWDM), либо опорная сеть оператора, использующая OTN. Так как все заголовки L2 и выше шифруются, то возможно только позвенное шифрование (в том числе в кольцевых сетях OTN). Это вынуждает использовать большое количество таких шифраторов. Зато обеспечивается доставка кадров не только Ethernet, но и FibreChannel, поэтому нет необходимости упаковывать трафик FCв Ethernet или IP. В сочетании с низкой задержкой это делает такие устройства привлекательным решением для сетей хранения данных (SAN), в частности, для синхронной репликации баз данных.

Так как, как уже упоминалось выше, стандартов шифрования в OTN пока нет, поэтому интероперабельности с устройствами других производителей тоже нет. В сочетании с большим «расходом» шифраторов при позвенном шифровании и высокой ценой одного модуля (4,6 млн рублей) это делает порог входа в такие решения весьма высоким.

Устройство ориентировано на необслуживаемый, удаленный от администраторов режим работы. Поддерживаются полноценные функции защиты от физического вскрытия, в частности, стирание всей ключевой информации при потере питания, вскрытии корпуса или нажатии на кнопку экстренного сброса. Управление обеспечивается через выделенные сетевые порты, причем как локальное, так и удаленное (внутриполосное и внеполосное). Сами средства управления разделены на сетевые/коммуникационные и криптографические – удобное решение. Огорчает только отсутствие централизованного управления ключами – весь ключевой материал (ключ администратора и ключи шифрования данных) должны генерироваться на отдельной станции, записываться на смарт-карты, физически доставляться к модулям шифрования и записываться на них. Конечно, это неудобно.

Отказоустойчивость обеспечивается с помощью дублирования операторских (WAN) портов и технологии автоматического выключения лазера (ALS) –аналога LLF в Carrier Ethernet.

• низкие (нулевые) накладные расходы пропускной способности, работа на скорости линии, низкая задержка
• поддержка других протоколов L2 (мультисервисность)
• защита от физического вскрытия
• разделение функций управления
• резервирование линий

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

«Палиндром»

Завершает обзор семейство высокоскоростных шифраторов (ВСШ) Ethernet серии «Палиндром». Их выпускает российская компания «СИС крипто». Это пока единственные на российском рынке шифраторы Ethernet L2 с поддержкой алгоритмов шифрования ГОСТ. Семейство состоит из двух серий: 4000-й в двух вариантах (с портами RJ45 или гнездами SFP) и скоростью 1 Гбит/с, и 6000-й с гнездами SFP+ и скоростью 10 Гбит/с.

В отличие от многофункциональных шлюзов безопасности, описанных выше, это специализированные устройства, предназначенные исключительно для сетевого шифрования (защиты каналов) в сетях Ethernet L2. У шифратора есть только 2 сетевых порта (кроме выделенных для управления) – один к локальному сегменту, другой – к внешнему каналу. Устройства построены на специализированной платформе шифрованияc ПЛИС и криптомодулем, реализующим шифрование ГОСТ. Используется блочный шифр 34.12-2015 «Кузнечик» в режиме гаммирования с алгоритмом согласования ключей VKO.

ВСШ «Палиндром-6140». Источник: СИС Крипто

В шифраторах используется фирменный протокол шифрования Ethernet в транспортном режиме. Шифруется всё поле данных кадра – отсюда следует, что через сети L3 (с маршрутизацией по заголовку IP) такие устройства работать не смогут, перед каждым маршрутизатором кадры придется расшифровывать. Так как заголовок кадра Ethernet не шифруется (и не изменяется), зашифрованные кадры могут быть скоммутированы через сеть L2, как обычно. Это делает возможным сквозное групповое многоточечное шифрование, при котором три и более шифраторов образуют единое защищенное соединение, через которое кадры будут доставляться только в нужный сегмент.

Шифраторы поддерживают работу на скорости линии во всем диапазоне длин кадров, то есть не теряют кадров почти никогда. Накладные расходы пропускной способности не превышают 8 байт на кадр, а в линейном режиме (между парой шифраторов), если опорная сеть между ними гарантирует надежность и порядок доставки кадров, вообще равны нулю! В сочетании с рекордной задержкой (до 10 микросекунд) во всём диапазоне длин кадров это обеспечивает этим устройствам ощутимое преимущество. Их также можно устанавливать в агрегированном канале, позволяя кратно масштабировать пропускную способность.

Многоточечное соединение ВСШ «Палиндром». Источник: СИС Крипто

Устройства умеют работать с кадрами Q-in-Q и MAC-in-MAC, применяющимися в больших операторских сетях, и таким образом обеспечивают поддержку VPN L2 со своим пространством MAC-адресов и VLAN. А вот организовать «своими силами» VPN L3 нельзя, это придется делать другими средствами.

Единственным заметным ограничением на масштаб сети может стать количество VLAN, используемых как идентификаторы защищенных соединений – до 100. Но зато эти шифраторы никак не ограничивают гибкость сетей Ethernet, где они применяются: поддерживаются все виды топологий Carrier Ethernet («точка-точка», «дерево», многоточечное), разные виды физического транспорта Ethernet («темное» оптоволокно, сети OTN, Ethernet c коммутацией на L2, псевдопровода через MPLS и IP.) При использовании по модели управляемого сервиса шифраторы поддерживают мультитенантность (взаимную криптографическую изоляцию трафика разных абонентов одного оператора).

С точки зрения интеграции в сеть устройства полностью реализуют принцип «узел на проводе»: они совместимы с кадрами Ethernet любых форматов, не вмешиваются в работу протоколов слоя контроля L2 (тем более верхних уровней). Полноценно реализованы мутация (временная замена) Ethertype, отступ шифрования перед заголовками и пропуск незашифрованными кадров с особыми MAC-адресами, Ethertype и VLAN. Так как протокол шифрования фирменный, то ВСШ не могут работать в паре с другими устройствами шифрования, но зато совместимы между собой модели 4000-й и 6000-й серий.

Для управления используется интерфейс командной строки (через последовательный консольный порт) и фирменная система управления (станция управления под Windows через сеть во внеполосном или внутриполосном режимах). Отдельного сервера управления нет, и после отключения станции управления защищенная сеть может работать автономно. Ручные операции при начальной настройке устройства включают в себя загрузку начальной последовательности датчика случайных чисел, настройку IP-адреса, времени и даты, смену пароля по умолчанию и генерацию-подписывание-загрузку сертификатов, которые используются для централизованного автоматического управления ключами. Поддерживаются внутренний (встроенный в среду управления) или сторонние УЦ. Управление включает в себя в основном настройки, связанные с криптографией, защищенными соединениями и политиками обработки кадров в зависимости от содержимого их полей. Защищенные соединения (туннели) могут устанавливаться автоматически, в том числе и в многоточечном режиме – главное, чтобы шифраторы были в одном широковещательном домене.

Шифраторы могут обнаруживать отказ других устройств в группе шифрования, а также сигнализировать о потере сигнала оборудованию, которое установлено у них «за спиной». Их можно встраивать в отказоустойчивые конфигурации с агрегацией портов и резервированием каналов. Модель 6140 имеет дублированные блоки питания и вентиляторы. Корпус шифраторов всех моделей защищен от физического взлома без вскрытия (зондирования), а также имеет датчик вскрытия. При срабатывании этого датчика устройство останавливается, вся ключевая информация стирается, и администратор получает уведомление о взломе.