Если долго мучиться — что-нибудь получится!
(с) народная мудрость
Настало время увлекательных историй, %username%!
Сразу оговорюсь, что описанной ниже истории никогда не случалось. Все совпадения случайны, все персонажи вымышлены.
В силу своей профессиональной деятельности, нам приходится работать с разными операторами связи. Практически все они — федерального уровня, либо их «дочки» в странах СНГ. Одной из таких компаний является… Пусть он будет Z.
История взаимоотношений с ним давняя и коллеги, наверное, расскажут много интересного. Но это как-нибудь потом, а пока расскажу свою историю я.
Требования к безопасности в этой компании серьезные — положение обязывает (А еще 152-ФЗ «О защите персональных данных»). Причем если раньше требования были драконовские (в духе «Миссия невыполнима»: изолированное помещение, сканер сетчатки, автоматчики...), то сейчас свелись к просто строгим: индивидуальные учетки и шифрованные каналы связи между нами и заказчиком. Шифрование — ГОСТовское, никакого вам
Но это была присказка, а за сказкой прошу под кат!
1. Ты помнишь, как все начиналось?
Защищенная сеть партнера построена на базе решения ViPNet от отечественного производителя — компании Инфотекс. До недавнего времени использовались индивидуальные клиенты ViPNet client с именными ключами. Однако сотрудников у нас много, а ключей — всего десять, больше партнер не дает. Как-то справлялись, но было жутко неудобно, поэтому решили ставить выделенный шлюз.
После переговоров с менеджером Инфотекса и специалистами партнера остановились на ПАК ViPNet Coordinator HW1000 на базе сервера Aquarius.
Т.к. рынок таких решений крайне небольшой, то стандартизацией там и не пахнет. Ты должен купить железку у того же производителя, что и твой партнер, иначе ничего не получится. Отсюда и уровень сервиса — никаких тебе 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-клиенте при этом должно появиться сообщение об обновлении адресных справочников и появиться координатор, с которым мы связываемся.
ЦУС -> Управление -> Отправить измененные файлы -> Ключи узлов. Отправляем ключи на координатор и клиент.
доверенная сеть 4321
В сети номер 1234 делаем следующее:
— Делаем резервную копию (архив)
— Формируем начальный экспорт как описано в документации
— Задаем шлюз для меж сеть
— Копируем начальный экспорт
— Генерируем ИСММК для сети 4321 в УКЦ
— Делаем экспорт для сети 4321
потом делаем следующее:
— Передаете начальный экспорт для сети 4321
— копируете начальный экспорт из сети 1234 в папки имопрта ЦУС и УКЦ сети 4321.
Теперь перейдем в сеть 4321:
— Делаем резервную копию (архив)
— Подключаем межсетевой канал
— Установить связи между ТК 2-х сетей 1234 и 4321
— Сформировать ответный экспорт для сети 1234
— Не забыть задать СМ_шлюз и скопировать ответный экспорт
— Так же не забыть проверить наличии аномальных ситуаций.
— Сформировать справочники
— Импортировать список сертификатов ЭЦП администраторов сети 1234 в УКЦ сети 4321
— Импорт ИСММК из сети 1234
— Сформировать новые КУ в ЦУС и перенести их в ЦУС
— Разослать обновления из ЦУС
Теперь перейдем к следующему этапу:
— Передать ответный экспорт для сети 1234. И далее все действия будет выполнять там.
— Провести импорт ответного экспорта в ЦУС и УКЦ и создать и создать заключительный экспорт.
— Подключить межсетевой канал. в ЦУС
— Посмотреть и проверить есть ли связь между ТК двух сетей 1234 и 4321.
— Проверить имеются ли аномалии
— Сформировать справочники.
— Сделать импорт списка сертификатов ЭП УЛ второй сети в УКЦ первой сети.
— Сформировать новые ключи узлов и перенести в ЦУС
— Рассослать обновления КУ и адресных справочников из ЦУС.
— Еще раз проверить правильность выполнения процедуры установки межсетевого взаимодействия
— Импортировать заключительный экспорт сети 4321
3. Бонус
Failover подразумевает, что железок у вас две, и они работают вместе, представляясь как один кластер. Работа основана на VRRP плюс синхронизация криптосессий.
[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 — импорт-экспорт настроек между ПАК с ключевой информацией и настройками сетей)
Были даже привлечены разработчики, ответ которых был, по-своему, гениален: «наверное, вы делали что-то не так». Ну разумеется, канал-то в итоге заработал. И работает до сих пор, тьфу-тьфу.
Коллеги подсказывают, что они мучались тоже с месяц, и оно, в итоге, «заработало само», когда подключилась техподдержка производителя.
Мистика, не иначе. А может, это, своего рода, посвящение — система покоряется только настойчивым.
В заключение хочу сказать, что не стремлюсь кого-то «полить грязью», просто описываю свой опыт. Особый диссонанс поначалу вызвала терминология, заточенная, как мне кажется, на специалистов ИБ, нежели на сетевиков: абонентские пункты, дистрибутивы ключей, коллективы пользователей, связи и прочее. Хотя, железо рассчитано на крупные компании, а в них, как правило, присутствуют айтишники-безопасники. С другой стороны, явная заточка под госструктуры (а кто еще
Комментарии (38)
Loreweil
17.06.2015 10:15+3Как-то странно вы пишите — сначала, что вы решили заменить клиенты на шлюз HW Coordinator (логичное решение, когда количество конечных точек, которым нужен шифрованный канал растет), потом описываете ЦУС и УКЦ випнета. Дело в том, что ЦУС и УКЦ випнета одни-единственные на всю випнет-сеть и по идее должны стоять у администратора сети, который должен являться сотрудников оператора связи Z, с которым вам нужно было настроить защищенный канал связи. Соответственно, если вы решили просто поднять у себя криптошлюз для випнет-сети партнера, то вам с ЦУС и УКЦ никаких дел иметь не нужно было бы, да и вообще вас туда и пускать-то не должны. Просто администратор випнет-сети выдал бы вам dst-файл с криптоключами/справочниками и парольную фразу для его развертывания на координаторе и все. Или же вы все-таки решили развернуть свою випнет-сеть? Тогда вопрос — зачем покупать свою випнет-сеть, если нужно поднять только один криптошлюз?
P. S. Я не сотрудник Инфотекса, просто в свое время плотно работал с випнетом и представляю себе как он функционирует, поэтому статья вызвала легкий когнитивный диссонанс.
P. P. S. Терминология инфотексовская действительно тяжелая. И как специалист поИБэ, могу сказать, что и не под нас она заточена вовсе. В инфотексе судя по всему вообще своя атмосфера.
Night_Snake Автор
17.06.2015 10:24+1В процессе обсуждения архитектуры с представителями Z и Инфотекса решили, что у нас будет своя vipnet-сеть (по сути состоящая из одного лишь криптошлюза), потому как управлять нашим криптошлюзом партнер, естественно, не собирается. При этом на АРМ сотрудников никакого ПО vipnet не ставится, они все работают прозрачно.
Ну а т.к. у нас «своя» защищенная сеть, то проблемы с ЦУС и УКЦ встали в полный рост.
Ploter
18.06.2015 13:27Хороший у вас «партнёр» — сперва ключи зажимал, потом одну единственную железку в свою сеть не смог добавить…
Night_Snake Автор
18.06.2015 13:28Вы, видимо, никогда не общались с большими компаниями, особенно окологосударственными. Там всем на всех положить
Ploter
18.06.2015 13:41Это проблема железки?
Night_Snake Автор
18.06.2015 13:47А при чем тут проблема железки? Партнер не захотел админить наш ПАК (и правильно сделал) и делать его частью своей защищенной сети.
Ploter
18.06.2015 13:57Я к тому что Ваше недовольство понятно (заставили разбираться со всем этим, хотя можно было этого избежать), но к железке-то какая техническая претензия? Та, что её не Cisco сделала и надо переучиваться?
Night_Snake Автор
18.06.2015 13:59Мое недовольство не в том, что с ней пришлось разбиратсья (учиться новому — добро). А в том, что настраивается эта железка через одно место и, вдобавок, есть крайне неочевидные моменты, которые ни в какой документации не описаны.
Ploter
18.06.2015 14:37Погодите, Вы создавали защищённую сеть с нуля, настраивали админа, который, кстати, выглядит теперь вот так:
И это сложно в первый раз, согласен. Но на то вы и специалист ;)
Железка же настраивается вполне стандартно.Night_Snake Автор
18.06.2015 14:42Гуевая версия ЦУСа не прошла еще полный цикл сертификации ФСТЭК/ФСБ, так что воспользоваться ей мы не могли. Да, согласен, сложности были только в первый-второй раз, когда раз пять проделал одно и то же, то стало как-то проще.
Однако же если вы внимательно прочитали пост, то могли бы заметить, что самые досадные косяки — это банальные баги (ну помимо общеукуренной терминологии).
malan
17.06.2015 10:49+4Вкратце: «как мы отказались от услуг интегратора и проваландались месяц с настройкой».
А если по делу, то либо кросс-сертификация криво прошла, либо где-то МЭ глючил и блокировал канал.Night_Snake Автор
17.06.2015 10:50Не факт, что интегратор не ковырялся бы тот же месяц вместо нас. По факту дело было, скорее всего, в косяке иморта-экспорта настроек.
malan
17.06.2015 11:03Как бывший интегратор уверен, что не ковырялись бы. Пара дней от силы.
Night_Snake Автор
17.06.2015 11:08+1Учитывая, что саппорт инфотекса сам ковырялся с неделю… Не буду спорить, конечно. В сроки мы все равно уложились + приобрели нужный опыт по этому самому ПАКу. Не думаю, что будут новые инсталляции, но, по крайней мере, будет проще траблшутить и обслуживать.
malan
17.06.2015 11:12Саппорт — это саппорт. У них другие задачи. В практическом плане они зачастую знают меньше чем специалисты интегратора.
tangro
17.06.2015 22:40+2Кстати, да. У саппорта и интегратора вообще разные задачи. Саппорту нужно смотреть дальше и глубже — думать что не работает в ядре системы, как это потом исправить, что можно добавить и т.д. Интегратор знает, что то, что он ставит — страшное фуфло и нужно не гнушаясь синей изоленты и такой-то матери тут подкрутить, тут подвязать, там приклеить — и зажужжит. Хотя в инструкции так не написано.
Night_Snake Автор
17.06.2015 23:03Позиция хорошая, мы тут с коллегой ее как раз сегодня обсуждали. В чем-то вы даже правы — интегратор должен знать в т.ч. и косяки того продукта, который он использует, и как их обходить. Но труд интегратора ведь тоже стоит денег, правильно? И вовсе не факт, что месяц работы собственного инженера (а чистого времени там едва ли человеконеделя-полторы вместе с изучением документации) выйдет дороже. А ведь свой инженер никуда не денется, и полученная им экспа тоже.
К тому же, повторюсь, запас по времени был.AtomKrieg
18.06.2015 09:31a) нужна ли этому инженеру такая экспа
б) инженер не может уволиться?Night_Snake Автор
18.06.2015 09:33а) если ему потом с этим же ПАКом работать — думаю да
б) любой инженер может уволиться, вопрос сохранения знаний — это отдельный
elcamlost
18.06.2015 12:17+2Интегратор два месяца думал, почему не работает наш vipnet канал и потом наконец-таки предложил поменять режим шифрования командой iplir set cipher-mode
Так что интегратор интегратору рознь
artemlight
18.06.2015 02:07Мне тут вспомнилось, что на этой штуковине работал клиент-банк Сбербанка года три назад.
Он тогда устанавливал некий впн, которому требовалась подсеть 192.168.1.0/24
Причем работало это счастье не через выделенный адаптер, а при помощи каких-то грязных хуков.
Брррр.
nomadmoon
18.06.2015 02:30Чисто для сведения хотелось бы узнать хотя бы примерную стоимость этого ПАК, если не секрет.
Night_Snake Автор
18.06.2015 08:19Зависит от уровня железки (т.е. количества конкурентных криптосессий). Но где-то от 50к. рублей. В нашем случае комплект из 2 ПАК + саппорт на три года стоил больше 500к рублей.
derwin
18.06.2015 08:21а кто еще в здравом уме будет пользовать ГОСТовское шифрование?
Если вы сетевики, а не специалисты в области ИБ/криптографии/шифрования… откуда такие суждения?
ИМХО алгоритм ГОСТ весьма не плох в плане стойкости. Хоть и схож с 3DES.Night_Snake Автор
18.06.2015 08:27Ну да, я сетевик. ГОСТ может быть хорош в плане криптостойкости, но по части совместимости дело швах. IPSec работает на любой мыльнице, которая говорит о себе как о VPN-шлюзе, не говоря уже о всяких там линуксах. А для ГОСТ надо либо покупать железку, либо ставить специальную (часто кривую) софтину.
derwin
18.06.2015 08:38+2основной акцент делается на 2 буквы — ИБ.
Сисадмин и сетевой инженер во мне соглашается с вами.
А ИБшник говорит, что:
1) для IpSec и других туннелей тоже нужно покупать железку
2) Нужны гарантии, которые производители мыльниц дать не могут. Гарантии на отсутствие закладок, недокументированных возможностей и пр.
Ясно понятно, что особо нужно охранять гос сети. И это отнють не виртуальная угроза. Особенно в свете последних событий.
В одном я с вами безоговорочно соглашусь — качество продукта, сервис, и цена — вне всякой критики. Это ужасно.Night_Snake Автор
18.06.2015 08:41В целом, соглашусь, но отмечу:
1) Стоимость железа для IPSec при сравнимой производительности различается чуть ли не на порядок
2) IPSec открыт — есть и опенсорсные реализации, и железные — выбирай на вкус и цвет.
Chamie
18.06.2015 10:25+2Подождите, как вы так противопоставляете алгоритм шифрования (ГОСТ) сетевым протоколам (IPsec)? Шифрование по ГОСТу возможно и в IPsec, решения от S-Terra, по-моему, именно так и делают.
Night_Snake Автор
18.06.2015 10:29Я противопоставляю IPSec не как семейство протоколов, а как способ реализации защищенного туннеля. Обычно если встречаешь слово ГОСТ — то на 146% это будет довольно убогое отечественное поделие, совместимое, как правило, только с поделием того же производителя. IPSec же определяет довольно стандартный набор протоколов шифрования и аутентификации.
Alexeyco
18.06.2015 11:13+1Помню… помню, как пару лет назад ввязался в авантюру. Решил помочь коллегам с отправкой отчетности в ЕГАИС посредством интернет-приемной. Обратились, говорят «ну ты ж скомпами там». Я еще подумал «да, я ж там с компами» и решил помочь. Там надо получить из специального ПО xml файлики, зашифровать их с помощью нескольких сертификатов контролирующих органов и своего, и загрузить их через веб-форму.
Осталось двоякое ощущение. С одной стороны, было заметно желание сделать «хорошо» у тех, кто делал эту приемную. С другой — полнейшее отсутствие документации. Оно и понятно — попытка склонить компании к аутсорсинговым услугам, которые всю дорогу пытались впарить… В итоге все зашевелилось, и довольно легко — ушло буквально минут 40 на настройку и еще часа 2 на решение проблем. Все проблемы были, повторю, в почти полном отсутствии документации (а в том, что было, были неточности) — но при определенном уровне понимания того, что происходит, все решается довольно легко.
В общем, после контактов со службой поддержки, осталось стойкое убеждение, что там работают такие же люди, которые подчас делают «хорошо» даже в ущерб указивкам сверху.
Dshuffin
Этот VIPNet именно что и заточен под госструктуры. Полнейшее убожество, надо отметить. Не вижу повода частной конторе выбирать VIPNet для решения каких-то задач.
Night_Snake Автор
Мы его «выбрали» ровно потому, что нам нужно через него работать с заказчиком. Вариантов особо небыло, увы.
F1RST
Да не заточен он под госструктуры по сути. Мы тоже с ним намучилась в свое время (может кто помнит первый единый день приема граждан) и по сути продолжаем… Просто выбора нет, дают сверху указание и приходится делать…
Night_Snake Автор
Ну скажем так, есть определенные «якорные» заказчики (типа той же РЖД), под которых пилится функциональность и делаются какие-то патчи. Все остальные едят «что дают» и мирятся с глюками. Добавим к этому лицензии ФСБ и ФСТЭК и получим, как обычно «принудительно-добровольное» решение.
Dshuffin
Заточка под госструктуры это:
1. Идиотские требования со стороны законодательства
2. Некоторые гарантии что именно твое решение выиграет жирные тендеры
3. Почти полное отсутствие конкуренции из-за пункта 2.
Из-за этого сервис отстой, интерфейс отстой, архитектурные решения не выдержали бы честной конкуренции.
AdmAlexus
12 декабря 2012? У нас наоборот категорически предостерегли от установки АРМов на компьютеры с VipNET. Для связи использовались предварительно настроенные Stonegate шлюзы и StoneGate VPN для удаленных АРМов.