Перейти к содержанию

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

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

Настало время увлекательных историй, %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.
Проверяем командой «Выдать таблицы маршрутизации«.
Далее все в том же меню «Службы«:
Групповая регистрация узлов в задачах -> 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-клиенте при этом должно появиться сообщение об обновлении адресных справочников и появиться координатор, с которым мы связываемся.
ЦУС -> Управление -> Отправить измененные файлы -> Ключи узлов. Отправляем ключи на координатор и клиент.

Краткая инструкция для лентяев

Итак Номер вашей сети 1234
доверенная сеть 4321

В сети номер 1234 делаем следующее:
— Делаем резервную копию (архив)
— Формируем начальный экспорт как описано в документации
— Задаем шлюз для меж сеть
— Копируем начальный экспорт
— Генерируем ИСММК для сети 4321 в УКЦ
— Делаем экспорт для сети 4321

потом делаем следующее:
— Передаете начальный экспорт для сети 4321
— копируете начальный экспорт из сети 1234 в папки имопрта ЦУС и УКЦ сети 4321.

Теперь перейдем в сеть 4321:
— Делаем резервную копию (архив)
— Подключаем межсетевой канал
— Установить связи между ТК 2-х сетей 1234 и 4321
— Сформировать ответный экспорт для сети 1234
— Не забыть задать СМ_шлюз и скопировать ответный экспорт
— Так же не забыть проверить наличии аномальных ситуаций.
— Сформировать справочники
— Импортировать список сертификатов ЭЦП администраторов сети 1234 в УКЦ сети 4321
— Импорт ИСММК из сети 1234
— Сформировать новые КУ в ЦУС и перенести их в ЦУС
— Разослать обновления из ЦУС

Теперь перейдем к следующему этапу:
— Передать ответный экспорт для сети 1234. И далее все действия будет выполнять там.
— Провести импорт ответного экспорта в ЦУС и УКЦ и создать и создать заключительный экспорт.
— Подключить межсетевой канал. в ЦУС
— Посмотреть и проверить есть ли связь между ТК двух сетей 1234 и 4321.
— Проверить имеются ли аномалии
— Сформировать справочники.
— Сделать импорт списка сертификатов ЭП УЛ второй сети в УКЦ первой сети.
— Сформировать новые ключи узлов и перенести в ЦУС
— Рассослать обновления КУ и адресных справочников из ЦУС.
— Еще раз проверить правильность выполнения процедуры установки межсетевого взаимодействия
— Импортировать заключительный экспорт сети 4321

3. Бонус

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

Настройка failover
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
[network]
checktime = 10
timeout = 2
activeretries = 3
channelretries = 3
synctime = 5
fastdown = yes

[channel]
device = eth1
ident = iface-1
activeip = 192.168.1.3
passiveip = 192.168.1.1
testip = 192.168.1.4
checkonlyidle = yes

[channel]
device = eth2
ident = iface-2
activeip = 1.2.3.3
passiveip = 1.2.3.1
testip = 1.2.3.4
checkonlyidle = yes

[sendconfig]
activeip = 192.168.2.2
sendtime = 60
device = eth0
config = yes
keys = yes
journals = yes
port = 10090

[misc]
activeconfig = /etc/iplirpsw
passiveconfig = /etc/iplirpsw
maxjournal = 30 #days
reboot = no

[debug]
debuglevel = 3
debuglogfile = syslog:daemon.debug

[events]

eth1 — это линк в сторону наших внутренних сетей
192.168.1.3 — это внутренний IP кластера
192.168.1.1 — это внутренний IP ноды
192.168.1.4 — это IP-адрес шлюза, через который мы видим клиентские сети
eth2 — линк в сторону интернета
1.2.3.3 — это внешний IP кластера
1.2.3.1 — это внешний IP ноды
1.2.3.4 — это IP шлюза по-умолчанию
eth0 — это интерконнект между нодами кластера
192.168.2.2 — это IP-адрес второй ноды кластера

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

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

1
iplir set cipher-mode cfb

Еще из полезного, настройки модуля шифрования:

1
iplir show config

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

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

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

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

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

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

2 комментария

  1. не удавалось ли ставить пакеты apt или aptitude на hw-1000 ?

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

Добавить комментарий

%d такие блоггеры, как: