Оповідь про те, як ми вітчизняного виробника підтримували



Якщо довго мучитися, що-небудь вийде!
© народна мудрість

Настав час захоплюючих історій, %username%!

Відразу обмовлюся, що описана нижче історії ніколи не траплялося. Всі збіги випадкові, всі персонажі вигадані.

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

Але це була приказка, а за казкою прошу під кат!

1. Ти пам'ятаєш, як все починалося?
Захищена мережа партнера побудована на базі рішення ViPNet від вітчизняного виробника — компанії Інфотекс. До недавнього часу використовувалися індивідуальні клієнти ViPNet client з іменними ключами. Однак співробітників у нас багато, а ключів — всього десять, партнер більше не дає. Якось справлялися, але було страшенно незручно, тому вирішили ставити виділений шлюз.

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

Оскільки ринок таких рішень вкрай невеликий, то стандартизацією там і не пахне. Ти повинен купити залізяку у того ж виробника, що і твій партнер, інакше нічого не вийде. Звідси і рівень сервісу — ніяких тобі НБД (хоча вартість підтримки далеко не копійчана), хоча саппорт відповідає досить оперативно, варто відзначити, чого, часом, не скажеш про менеджерів.

Першим «відкриттям» після отримання обладнання було те, що керуючий софт вимагає для своєї роботи 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-клієнті при цьому повинно з'явитися повідомлення про оновлення адресних довідників і з'явитися координатор, з яким ми зв'язуємося.
ЦКМ -> Керування -> Відправити змінені файли -> Ключі вузлів. Відправляємо ключі на координатор і клієнт.

Коротка інструкція для ледарівОтже Номер вашої мережі 1234
довірена мережа 4321

У мережі номер 1234 робимо наступне:
— Робимо резервну копію (архів)
— Формуємо початковий експорт як описано в документації
— Задаємо шлюз для між мережа
— Копіюємо початковий експорт
— Генеруємо ИСММК для мережі 4321 в УКЦ
— Робимо експорт для мережі 4321

потім робимо наступне:
— Передаєте початковий експорт для мережі 4321
— скопіювати початковий експорт з мережі 1234 в папки имопрта ЦКМ та НКЦ мережі 4321.

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

Тепер перейдемо до наступного етапу:
— Передати відповідь експорт для мережі 1234. І далі всі дії буде виконувати.
— Провести імпорт відповідного експорту в ЦКМ та НКЦ і створити і створити заключний експорт.
— Підключити мережевий канал. в ЦКМ
— Подивитися і перевірити чи є зв'язок між ТК двох мереж 1234 і 4321.
— Перевірити чи є аномалії
— Сформувати довідники.
— Зробити імпорт списку сертифікатів ЕП ВУЛ другий мережі в УКЦ першої мережі.
— Сформувати нові ключі вузлів і перенести в ЦКМ
— Рассослать оновлення КУ і адресних довідників з ЦКМ.
— Ще раз перевірити правильність виконання процедури установки міжмережевої взаємодії
— Імпортувати заключний експорт мережі 4321


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

Налаштування failover
[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». Можливо, це вже пофиксили, але ви все одно майте на увазі.

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


Ще з корисного, налаштування модуля шифрування:
iplir show config

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

4. Через терни — до зірок!
Отже, настройка завершена, але канал між нашим ПАК і мережею партнера не піднімається. І тут почалося найцікавіше.

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

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

Були навіть залучені розробники, відповідь яких був по-своєму геніальний: «напевно, ви робили щось не так». Ну зрозуміло, канал-то в підсумку заробив. І працює досі, тьху-тьху.

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

Містика, не інакше. А може, це, свого роду, посвята — система підкоряється тільки наполегливим.

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

Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.