Сказ о том, как мы отечественного производителя поддерживали

Если долго мучиться — что-нибудь получится!
(с) народная мудрость

Настало время увлекательных историй, %username%!

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

В силу своей профессиональной деятельности, нам приходится работать с разными операторами связи. Практически все они — федерального уровня, либо их «дочки» в странах СНГ. Одной из таких компаний является… Пусть он будет Z.
История взаимоотношений с ним давняя и коллеги, наверное, расскажут много интересного. Но это как-нибудь потом, а пока расскажу свою историю я.
Требования к безопасности в этой компании серьезные — положение обязывает (А еще 152-ФЗ «О защите персональных данных»). Причем если раньше требования были драконовские (в духе «Миссия невыполнима»: изолированное помещение, сканер сетчатки, автоматчики...), то сейчас свелись к просто строгим: индивидуальные учетки и шифрованные каналы связи между нами и заказчиком. Шифрование — ГОСТовское, никакого вам буржуйского заграничного IPSec. Рынок таких решений мал, поставщиков — раз-два и кончились. Реализация… ну не Checkpoint и не Cisco, но терпимо.

Но это была присказка, а за сказкой прошу под кат!

1. Ты помнишь, как все начиналось?

Защищенная сеть партнера построена на базе решения ViPNet от отечественного производителя — компании Инфотекс. До недавнего времени использовались индивидуальные клиенты ViPNet client с именными ключами. Однако сотрудников у нас много, а ключей — всего десять, больше партнер не дает. Как-то справлялись, но было жутко неудобно, поэтому решили ставить выделенный шлюз.

После переговоров с менеджером Инфотекса и специалистами партнера остановились на ПАК ViPNet Coordinator HW1000 на базе сервера Aquarius. Импортозамещение же Внутри этого ПАК — обычный debian-based линукс с собственным шеллом (можно выйти в bash) и установленным софтом ViPNet Coordinator (тестовую версию можно скачать в виде пакета).

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

Первым «открытием» после получения оборудования было то, что управляющий софт требует для своей работы 16-bit MS-DOS подсистему (!). Учитывая, что программ две («Центр Управления Сетью» и «Удостоверяющий и Ключевой Центр»), используют они общие папки (хотя в документации описано их разнесение на разные АРМ), то наименее геморройным вариантом стала установка виртуалки с Win2003 x32. 2015й год говорите? x86-64? Не, не слышали. Версия софта, поддерживающего 64-битные ОС, в настоящий момент проходит сертификацию органами — был ответ саппорта.

Инструкция пользователя подробна и многостранична, а описание готовых схем занимает едва ли полтора десятка страниц и наполовину состоит из рисунков. Если бы не помощь коллег, которые уже запускали подобные ПАК (Саша, спасибо!), то процесс только настройки и освоения документации затянулся бы, думаю, на месяц-другой. Сам же Инфотекс настоятельно рекомендует пройти пятидневные курсы (разумеется, платные, но относительно дешевые), либо воспользоваться услугами интегратора. Но мы ведь не ищем легких путей, правда? :) К слову, краткую инструкцию саппорт мне, все же, прислал.

2. Поехали!

Начинается все с установки ПО администратора: Центр Управления Сетью (ЦУС), Удостоверяющий и Ключевой Центр (УКЦ) и ViPNet Client, которым мы будем проверять наш канал. Для работы потребуется лицензия (идет вместе с ПАК). Клиент пока не запускаем, нам для него еще ключи надо сделать. Файлик лицензии копируем в C:\Program files\InfoTecs\{NCC,KC}. Ребутаемся.

Запускаем ЦУС.

Интерфейс ЦУС

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


Структура сети ViPNet

Проверяем командой "Выдать таблицы маршрутизации".
Далее все в том же меню "Службы":
Групповая регистрация узлов в задачах -> Coordinator -> добавляем наши СМ.
Индивидуальная регистрация в задачах -> admin -> добавляем галки ЦУС + УКЦ.
Регистрация типов коллективов — admin -> связи -> добавляем СМ.
Регистрация пользователей -> Добавляем еще одного пользователя в ТК admin и vpn1000
Групповая регистрация узлов в задачах -> Coordinator -> регистрация в задаче hw1000 -> выбираем нужный СМ -> ip адреса -> вводим IP-адреса. (См. в документации «ViPNet NCC» пп. 13.4.2.1 и 13.5). Здесь нужно указать внутренний и внешний адрес нашего координатора и туннелируемые сети.

Теперь проверяем:
Проверка конфигурации
Сформировать все справочники

С ЦУС пока закончили, запускаем наш УКЦ

Внешний вид УКЦ

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

Задать пароль администратора для группы «Вся сеть» (в эту группу по умолчанию входят все сетевые узлы), который используется для входа в режим администратора на Сетевых Узлах (наших координаторах).
Созданные дистрибутивы будут отображены в УКЦ в разделе Ключевой центр > Своя сеть ViPNet > Ключи > Дистрибутивы ключей.

После этого перезапускаем УКЦ — он спросит пароль. Вводим тот самый пароль администратора, который только что сгенерировали.

Маленькая ремарка: если при первой установке какой-то из паролей вы вдруг забыли, то проще всего будет перенастроить все заново (удалить ЦУС и УКЦ, удалить папку InfoTecs) — со второго-третьего раза настройка занимает минут пятнадцать и идет почти на автомат).

Формируем экспорт для сети нашего партнера.
В ЦУС: Службы -> Экспорт. Т.к. у нас пока ничего нет, добавляем сеть для экспорта (это доверенная сеть вашего партнера). Добавляем туда все наши СУ и все ТК. Жмем Копировать.
Полученные файлики нужно будет забрать в папке NCC\EXPORT, запихнуть в зашифрованный архив и передать администратору сети-партнера.
Принимаем импорт. Копируем содержимое архива в папку IMPORT, перезпускаем ЦУС. Службы -> необработанный импорт.

Возвращаемся в УКЦ
Принимаем симметричный мастер-ключ (см. мануал по УКЦ) либо создаем свой — тут как договоритесь с партнером
Создаем ключи узлов (см. мануал по УКЦ)
Своя сеть -> Ключи -> Ключи узлов. На каждом узле ПКМ -> перенести в ЦУС

ЦУС
Сформировать все справочники, затем делаем повторный экспорт и отсылаем партнеру. Принимаем импорт.

Готовим дистрибутивы ключей
УКЦ -> КЦ -> СУ -> Открыть. Задаем пароль администратора.
ЦУС -> Службы -> Файлы для… УКЦ -> Дистрибутивов... (копируем оба СУ: VPN1000 и admin)
УКЦ -> Сервис -> Автоматически создать -> Дистрибутивы ключей

Переносим дистрибутивы (файлы *.dst) на съемный носитель (с помощью команды Перенести в папку в контекстном меню).
Копируем на этот же носитель пароли пользователей (меню Сервис > Сохранить пароли в файле > Пароли пользователей).

Импортируем сертификаты
УКЦ -> УЦ -> Доверенные сети -> Входящие. Импортируем все сертификаты

Наконец, добираемся, собственно, до железа
Импортируем ключи и справочники на HW. С помощью мастера настраиваем сетевые интерфейсы. Это можно будет сделать позже из консоли. Пароль по умолчанию для входа vipnet/vipnet
После установки ключей логин: vipnet, пароль: пароль от дистрибутива с ключами СМ, enable: пароль администратора СУ (тот что для УКЦ).
В ЦУС добавляем связи между импортированным ТК и своими. Снова делаем у себя экспорт и принимаем импорт. Импорт-экспорт повторяем, пока с обеих сторон не прекратятся аномалии.
После каждого импорта делаем «Сформировать все справочники», Управление -> Отправить измененные файлы -> Справочники узлов -> выбираем наши СУ (admin, vpn1000) и отправляем.
В ViPNet-клиенте при этом должно появиться сообщение об обновлении адресных справочников и появиться координатор, с которым мы связываемся.
ЦУС -> Управление -> Отправить измененные файлы -> Ключи узлов. Отправляем ключи на координатор и клиент.

3. Бонус

Failover подразумевает, что железок у вас две, и они работают вместе, представляясь как один кластер. Работа основана на VRRP плюс синхронизация криптосессий.



Обратите внимание на секцию [misc] и опцию «reboot = no». По умолчанию она установлена в yes, и если failover с первого раза не запустится, то вам придется переустанавливать ОС ПАК заново из образа. При этом в инструкции указано, что значение по умолчанию именно «no». Возможно, это уже пофиксили, но вы все равно имейте ввиду.

Проверяем, что и у вас и у партнера установлен одинаковый тип шифрования:
iplir set cipher-mode cfb

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

4. Через тернии — к звездам!

Итак, настройка завершена, но канал между нашим ПАК и сетью партнера не поднимается. И тут-то началось самое интересное.

Естественно, был заведен тикет в саппорте, были уточняющие вопросы, неоднократный сброс ПАК «в дефолт», перепроверка всех настроек, в т.ч. самим саппортом через удаленную сессию…

Через месяц стучания в бубен и копирования очередного файлика из одной папки в другую канал поднялся. Бинго? В общем, да, но осадочек-то остался немалый! Месяц, потраченный почти впустую, сотни писем в саппорт и администратору партнера, бесконечный обмен настройками (одна из фишек ViPNet — импорт-экспорт настроек между ПАК с ключевой информацией и настройками сетей) и письмо от руководства в сторону Инфотекс с предложением забрать глючную железку взад.

Были даже привлечены разработчики, ответ которых был, по-своему, гениален: «наверное, вы делали что-то не так». Ну разумеется, канал-то в итоге заработал. И работает до сих пор, тьфу-тьфу.

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

Мистика, не иначе. А может, это, своего рода, посвящение — система покоряется только настойчивым.

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