Vipnet syslocker для варианта исполнения кс3 что это
Что такое ViPNet CSP 4.2
Программный комплекс для электронной подписи совместим с системами Windows, служит для создания ключей, хэширования и шифрования данных. Программа выполняет следующие функции:
Криптопровайдер, разработанный в РФ, сертифицирован в качестве высокоэффективного и удобного средства криптографической защиты информации и электронной подписи.
Для обеспечения класса защищенности КС3 продукт ViPNet CSP 4.2 используется совместно с сертифицированным АПМДЗ и ViPNet SysLocker для создания и контроля замкнутой программной среды.
ViPNet CSP используется в системах юридически значимого защищенного электронного документооборота, для сдачи электронной отчетности, защищенной работы с веб-сервисами и для встраивания криптографических функций в сторонние приложения.
Преимущества программы
Программный комплекс поддерживает работу с внешними устройствами (токенами), что облегчает интеграцию новых устройств с ViPNet CSP 4. Возможность экспорта и импорта ключей в формате #PKCS12 повышает совместимость форматов ключей с решениями других производителей.
Еще один немаловажный фактор — поддержка вызова криптографических функций CSP сторонними приложениями через API PKCS#11, Microsoft CryptoAPI и Microsoft CNG. Выделенное множество функций API позволяет клиентским приложениям ограничивать объемы сертификационных испытаний только проведением оценки влияния.
Продукт может быть перемещен через границу Таможенного союза юридическими или физическими лицами без оформления дополнительных документов для разрешения благодаря полученной нотификации о характеристиках шифровального средства.
ViPNet CSP 4.2 может использоваться для реализации функций ЭП в соответствии с Федеральным законом от 6 апреля 2011г № 63-ФЗ «Об электронной подписи».
Vipnet syslocker для варианта исполнения кс3 что это
ViPNet CSP 4.2 позволяет:
Базовый вариант ViPNet CSP 4.2 (вариант исполнения 1) обеспечивает класс защищенности КС1.
Для обеспечения класса защищенности КС2 продукт ViPNet CSP 4.2 (вариант исполнения 2) следует использовать совместно с сертифицированным аппаратно-программным модулем доверенной загрузки (АПМДЗ).
Для обеспечения класса защищенности КС3 продукт ViPNet CSP 4.2 (вариант исполнения 3) используется совместно с сертифицированным АПМДЗ и специализированным ПО ViPNet SysLocker для создания и контроля замкнутой программной среды.
Сценарии использования
Преимущества
На ViPNet 4.2 получена нотификация о характеристиках шифровального средства. Данный документ позволяет перемещать продукт ViPNet CSP 4.2 через границу Таможенного союза любому юридическому или физическому лицу без оформления дополнительных разрешающих документов
Удостоверяющий Центр ViPNet
Удостоверяющий Центр ViPNet представляет собой программное обеспечение технологии ViPNet с криптографическим ядром «Домен-К», предназначенное для создания инфраструктуры электронной цифровой подписи в корпоративных вычислительных сетях коммерческих и государственных организаций, обеспечивающей выполнение требований Федерального закона «Об ЭЦП», высокий уровень безопасности ее функционирования и требований к составу и техническим характеристикам программно-аппаратного комплекса «Удостоверяющий центр».
В состав Удостоверяющего Центра ViPNet входит следующее программное обеспечение:
— ПО ViPNet [КриптоСервис], предназначено для обеспечения необходимой функциональности работы с электронной цифровой подписью «Домен-К» (подпись, проверка подписи и т.д.), а также для автоматизированного защищенного обновления ключей, справочников и сертификатов электронной цифровой подписи.
В качестве дополнительного ПО может быть использовано:
Данное программное обеспечение в защищенном варианте обеспечивает все необходимые механизмы использования ЭЦП с сертификатами X.509, предусмотренные Законом об ЭЦП и международными стандартами.
Алгоритмы для хэширования и подписи реализованы в соответствии со стандартами ГОСТ Р 34.10-94, Р 34.11-94, Р 34.10-2001. Алгоритм шифрования реализован в соответствии со стандартом 28147-89
ПО ViPNet [Удостоверяющий и ключевой центр]
Программу ViPNet [Удостоверяющий и Ключевой Центр] можно условно разделить на две программы: Ключевой центр и Удостоверяющий центр.
Удостоверяющий центр предназначен для обслуживания следующих запросов: на издание сертификатов ЭЦП, на отзыв, приостановление и возобновление приостановленного действия сертификатов абонентов, сформированных на сетевых узлах или в Центрах Регистрации для внешних пользователей.
Программное обеспечение УЦ обеспечивает следующую функциональность:
— Генерация секретных и открытых ключей Главных абонентов УЦ, сертификатами которых заверяются сертификаты пользователей. Сертификаты главных абонентов могут быть самоподписанными или заверенными вышестоящим УЦ.
— Первое издание сертификата подписи абонентов происходит в УЦ вместе с генерацией секретного ключа для него. Дальнейшее переиздание сертификата может происходить как в УЦ одновременно с формированием нового секретного ключа (для задач, требующих централизованной генерации и распределения ключей), так и по запросу пользователя корпоративной сети, сформированного на его сетевом узле.
— Издание и регистрация сертификатов ЭЦП по запросу абонентов сети. Запрос на сертификат представляет собой шаблон сертификата, содержащий информацию об абоненте, его новый открытый ключ подписи, предполагаемый срок действия сертификата, а также другие параметры, соответствующие стандарту X.509. Запрос может быть зарегистрирован или автоматически или в результате действий администратора УЦ. Запрос может быть отклонен. После заполнения полей сертификата сертификат через Центр управления отправляется к пользователю на компьютер.
— Отзыв сертификатов, приостановление действия сертификатов, возобновление действия сертификатов ЭЦП абонентов сети. Эти действия выполняются администратором УЦ. Справочник отозванных сертификатов рассылается абонентам сети.
— Регистрация справочников сертификатов ЭЦП главных абонентов других УЦ ViPNet. После просмотра сертификатов главных абонентов других УЦ и принятия их производится подпись такого справочника своим главным абонентом (кросс сертификация). Заверенный справочник рассылается по сети в соответствии со связями своих абонентов, и используются при проверке сертификатов ЭЦП абонентов других УЦ, приславших подписанную информацию на какой-либо узел своей сети.
— Аналогичным образом выполняется импорт, кросс сертификация и рассылка сертификатов УЦ других производителей на основе сертифицированных СКЗИ «КриптоПро» и «Верба-О». Документы, подписанные с использованием указанных СКЗИ, будут проверены только при наличии на компьютере сертификата соответствующего УЦ, заверенного Главным абонентом своего УЦ. По соображениям безопасности УЦ ViPNet требует кросс сертификации даже для сертификатов других УЦ, в цепочке сертификатов которых содержится сертификат, которому доверяет УЦ ViPNet,
— Регистрация справочников отозванных сертификатов ЭЦП из других УЦ ViPNet. Такие справочники поступают из других сетей автоматически, заверяются главным абонентом и рассылаются по сети в соответствии со связями абонентов сети. Импорт справочников отозванных сертификатов из УЦ других производителей не производится. Доступ к ним осуществляется в процессе проверки подписи по пути, указанному в ЭЦП.
— Обслуживание запросов внешних пользователей. Внешний пользователь регистрируется на одном из пунктов регистрации Администратором программы ViPNet [Центр Регистрации]. Администратор ЦР создает запрос на сертификат ЭЦП для внешнего пользователя и отсылает его в УЦ для издания сертификата. Запрос на сертификат перед отправкой в УЦ подписывается ключом подписи этого Администратора. После введения в действие сертификата внешний пользователь сможет пользоваться им (подписывать документы) на любом узле сети с установленным ПО ViPNet. Администратор ЦР может создавать запросы на отзыв, приостановление действия, возобновление действия приостановленного сертификата ЭЦП внешних пользователей.
— Издание и регистрация сертификатов ЭЦП для внешних пользователей выполняется только по запросу из Центра регистрации. Запрос может быть зарегистрирован или отклонен. Вторичные запросы на сертификаты, если в них нет изменений, и выдача сертификатов могут обрабатываться и выдаваться автоматически. Сертификаты через ЦУС отправляется в УЦ.
— Отзыв сертификатов, приостановление действия сертификатов, возобновление действия сертификатов ЭЦП внешних пользователей может происходить по запросу из ЦР, или самим Администратором УЦ без запроса из ЦР. Справочники отозванных сертификатов рассылаются по узлам сети.
— Просмотр запросов и сертификатов ЭЦП. В программе УЦ возможен просмотр любых запросов, сертификатов, действующих списков отзыва, сохранение их в файл или вывод на печать.
— Сервисные функции УЦ.
УЦ информирует администратора об истечении сроков действия различных сертификатов за заданное число дней до этого срока путем формирования соответствующих списков.
Автоматически формирует архивы информации через заданные интервалы времени при наличии изменений, что обеспечивает возможность восстановления актуальной информации.
Обеспечивает различные режимы функционирования УЦ.
Ключевой центр (КЦ) обеспечивает защиту инфраструктуры ЭЦП посредством создания системы шифрования информации во всех процедурах управления инфраструктурой ЭЦП на основе симметричной схемы распределения ключей:
— Защита секретных ключей ЭЦП, распределяемых централизовано;
— Защита сертификатов главных абонентов сети;
— Защита транспортного уровня системы, обеспечивающего работу процедур запросов и получения сертификатов, доставки других файлов инфраструктуры ЭЦП;
— Формирование других ключей, обеспечивающих обновление симметричной ключевой информации и работу другого ПО ViPNet.
Первоначальный набор симметричных ключей выдается пользователю в составе файла ключевого дистрибутива, зашифрованного на пароле, и который пользователь получает при его первичной регистрации. В состав ключевого дистрибутива входит персональный ключ связи с УКЦ, ключ связи со своим ViPNet-координатором, первичный секретный ключ подписи и сертификат, сертификаты главных абонентов УЦ. Другая ключевая информация поступает на компьютер после инсталляции ПО ViPNet[КриптоСервис] и в процессе обновлений.
ПО ViPNet [Центр управления сетью]
Программа Центра управления обеспечивает:
— Регистрацию узлов и абонентов корпоративной сети, регистрацию «Центров регистрации» внешних пользователей.
— Взаимодействие с УКЦ и пользователями при управлении сертификатами.
— Формирование защищенных справочников доступа для узлов сети и справочников связей узлов и абонентов для УКЦ при штатной эксплуатации и компрометации ключей абонентов.
Взаимодействие абонентов с УКЦ производится только через Центр управления. При этом обе программы могут устанавливаться на один компьютер. Однако для повышения уровня безопасности функционирования УКЦ предусмотрена возможность установки УКЦ и Центра управления на разных компьютерах.
ПО ViPNet [Центр регистрации]
Программа Центр Регистрации предназначена для регистрации внешних пользователей и получения для них в УКЦ цифровых сертификатов. Право работать в данной программе определяется программой Центра управления путем регистрации узла в задаче ЦР и формирования соответствующего справочника доступа. В системе может присутствовать произвольное количество ЦР.
В Центре Регистрации при предъявлении документов внешним пользователем, подтверждающих его полномочия, создается запрос на сертификат, производится отправка его в УКЦ и осуществляется ввод в действие изданного в УКЦ сертификата. В Центре Сертификации сертификат будет либо удовлетворен, либо отклонен. Только запрос на сертификат со статусом «удовлетворен» становится сертификатом подписи, и этот сертификат может быть введен в действие. После введения в действие сертификата, внешний пользователь сможет пользоваться им (подписывать документы) на любом узле с установленным ПО ViPNet.
Программа выполняет следующие функции:
— Генерация секретного ключа подписи и сохранение его на персональном ключевом носителе внешнего пользователя.
— Ввод персональных данных для сертификата внешнего пользователя.
— Формирование запроса на сертификат.
— Подпись запроса на сертификат ключом действующего администратора ЦР.
— Отправка заверенного запроса в УКЦ (через ЦУС).
— Автоматический прием сертификатов из УКЦ.
— Просмотр запросов и принятых сертификатов.
— Ввод в действие сертификата (сохранение на персональном ключевом носителе внешнего пользователя).
— Формирование запроса на отзыв сертификата.
— Формирование запроса на приостановление сертификата.
— Формирование запроса на возобновление сертификата.
Кроме того, программа выполняет экспорт сертификатов в различных кодировках. Всю процедуру создания запроса на получение сертификата обеспечивает соответствующий мастер.
Секретный ключ внешнего пользователя и его сертификат заносятся на его персональный носитель. Это может быть дискета, E-Token, смарт-карта, Touch memory и другие.
Секретный ключ зашифровывается на пароле, вырабатываемом программой. Тип пароля может быть один из следующих:
— Случайная легко запоминаемая фраза,
— Собственный цифровой пароль,
— Случайный цифровой пароль.
ПО ViPNet [КриптоСервис]
ПО ViPNet [КриптоСервис] содержит набор функций работы с ЭЦП, необходимых для использования другими приложениями.
Пользователь сети, используя меню программы, может в любое время создать для себя новый секретный ключ и отправить запрос в УКЦ для получения нового сертификата. Однако пользователь не может изменить поля в запросе, кроме полей сроков действия. Редактирование полей сертификата возможно только в УКЦ.
Пользователь может сменить пароль, защищающий секретные ключи. Задать тип и срок действия пароля. Назначить срок, за который программа должна сообщить ему о приближающемся сроке окончания действия его сертификата и предложить сформировать новый запрос.
ПО ViPNet [Координатор]
Это многофункциональный программный модуль, который обеспечивает следующую функциональность:
— межсетевое экранирование в соответствии с требованиями Гостехкомиссии по 3 классу. За Координатор устанавливается УКЦ и ЦУС;
— выполнение функций почтового сервера для обеспечения безопасного обмена сообщениями инфраструктуры ЭЦП, управляющими сообщениями системы защиты, а также почтовыми сообщениями приложений системы ViPNet;
функции NAT (Network address translation) для VPN-соединений из локальной в общественную сеть;
туннелирование и шифрование трафика компьютеров, установленных за ViPNet [Координатор] и взаимодействующих с компьютерами за другими ViPNet [Координаторами] или с установленным ПО ViPNet [Клиент].
Требуемый уровень безопасности (класс 1 В) обеспечивается использованием программного обеспечения технологии ViPNet, сертифицированного по указанному классу, а также по другим требованиям безопасности. К основным техническим мерам, которые гарантируют высокий уровень безопасности использования инфраструктуры ЭЦП, можно отнести следующие:
— Весь информационный обмен, связанный с обеспечением работы инфраструктуры ЭЦП, производится в зашифрованном виде, что исключает любые стратегии модификации, подмены, навязывания ложной информации, несанкционированного доступа к передаваемой информации.
— Весь служебный информационный обмен по ЭЦП обеспечивается специализированным защищенным транспортным модулем MFTP, входящим в состав сертифицированного продукта и использующим протокол сетевого уровня TCP по портам 5000, 5001, 5002, что позволяет путем настроек для пропуска этого протокола на межсетевых экранах исключить возможные сетевые атаки через стандартные протоколы.
— Программное обеспечение ViPNet на клиентских станциях обеспечивает криптографический контроль целостности справочников сертификатов Главных абонентов УКЦ, что гарантирует их защиту от подмены. Все другие справочники защищены от подмены криптографическими контрольными суммами и подписью УКЦ.
— УКЦ ViPNet производит кросс сертификацию сертификатов других удостоверяющих центров, что позволяет центральной администрации контролировать надежность других удостоверяющих центров. Подпись лица, которому сертификат выдан другим удостоверяющим центром, признается действительной, только в случае наличия на компьютере заверенного своим УКЦ сертификата этого другого удостоверяющего центра, выдавшего сертификат данному лицу.
— Межсетевой экран ViPNet [Координатор], защищающий УКЦ, совмещен с сервером транспортного модуля MFTP. Сетевые узлы имеют возможность взаимодействовать только с координатором и не имеют возможности прямого взаимодействия с УКЦ и Центром управления, что позволяет на межсетевом экране пресечь любые сетевые атаки даже со стороны зарегистрированных пользователей.
— Если на клиентские компьютеры возможны сетевые атаки, то для защиты криптографических модулей и ключей ЭЦП на них целесообразна установка модуля ViPNet [Клиент] или его составляющей ViPNet [Персональный сетевой экран], сертифицированной ФАПСИ для использования в органах государственной власти. Модуль ViPNet [Клиент] дополнительно к персональному сетевому экрану создает зашифрованный туннель до ViPNet [Координатора], блокируя при этом любой открытый трафик, что полностью исключает любые сетевые атаки на компьютер пользователя.
Центр управления и УКЦ ViPNet могут обеспечить автоматическое защищенное взаимодействие более чем с 65 000 сетевыми узлами. При этом в одном УКЦ может быть зарегистрировано более чем 65 000 абонентов сети для выдачи им сертификатов.
JaCarta
Разработчик: ЗАО «Алладин Р.Д.» 
JaCarta PKI
JaCarta PKI – USB-, MicroUSB-токен или смарт-карта для строгой двухфакторной аутентификации пользователей при доступе к защищённым информационным ресурсам предприятия, безопасного хранения ключей, ключевых контейнеров программных СКЗИ.
JaCarta PKI – базовая, или основная, модель семейства. Её функциональности обычно бывает достаточно для 60-70% выполняемых проектов.
Выпускается в трёх базовых форм-факторах: USB-токен (в корпусе XL и Nano), MicroUSB-токен и смарт-карта (чёрный пластик, чип с палладиевыми контактами):
Если предполагается использовать смарт-карты или токены JaCarta PKI вместе с продуктами, ранее выпущенными компанией Aladdin, или в уже созданной инфраструктуре, с имеющимися в эксплуатации продуктами компании, то при заказе следует выбрать опцию «Обратная совместимость с продуктами Aladdin».
JaCarta-2 ГОСТ
Новое поколение USB-токенов, смарт-карт и модулей безопасности с аппаратной поддержкой ГОСТ Р 34.10-2012 и ГОСТ Р 34.11-2012
Назначение JaCarta-2 ГОСТ
JaCarta-2 ГОСТ — новое поколение USB-токенов, смарт-карт, модулей безопасности с аппаратной реализацией российских криптографических алгоритмов
Средство электронной подписи и полноценное СКЗИ
JaCarta-2 ГОСТ предназначена для использования в качестве сертифицированного средства ЭП (усиленной квалифицированной подписи — УКЭП) и полноценного СКЗИ в системах электронного документооборота (ЭДО), дистанционного банковского обслуживания (ДБО) и др. для обеспечения юридической значимости и неотказуемости действий пользователей, а также для обеспечения целостности и конфиденциальности передаваемых данных.
Для обеспечения совместимости с существующими системами и плавного перехода на использование нового российского стандарта ЭП JaCarta-2 ГОСТ поддерживает как старые криптографические алгоритмы ГОСТ Р 34.11-94 и ГОСТ Р 34.10-2001, выводимые из использования с 2019 г., так и новые — ГОСТ Р 34.11-2012 и ГОСТ Р 34.10-2012.
Средство строгой двухфакторной аутентификации
Устройства JaCarta-2 ГОСТ могут применяться для обеспечения безопасного доступа пользователей или терминального оборудования в информационные системы, Web-порталы и облачные сервисы.
Средство безопасного хранения пользовательских данных
Возможности устройств JaCarta-2 ГОСТ позволяют обеспечить безопасное хранение ключевых контейнеров программных СКЗИ (например, КриптоПро CSP и ViPNet CSP), цифровых сертификатов, паролей, пользовательских и прочих данных в защищённой энергонезависимой памяти (EEPROM).
Различные исполнения
Комбинированные модели
Функциональность устройств JaCarta может быть расширена: на их базе выпускается целая линейка комбинированных моделей
ViPNet в деталях: разбираемся с особенностями криптошлюза
Для начала разберемся, как это все работает. Итак, координатор 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».
Немного остановимся на режиме «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-адреса шифрованный трафик, а пришел нешифрованный. Чаще всего это происходит так:
Обработка прикладных протоколов (ALG)
На многих межсетевых экранах, включая ViPNet Coordinator, могут возникать проблемы с прохождением SIP через NAT. С учетом того, что виртуальные адреса – это внутренний NAT, проблема может возникать, даже когда в явном виде NAT не используется, а используются только виртуальные адреса. Координатор обладает модулем обработки прикладных протоколов (ALG), который должен эти проблемы решать, но не всегда это работает так, как хотелось бы. Не буду останавливаться на механизме работы ALG (на эту тему можно написать отдельную статью), принцип одинаков на всех МСЭ, изменяются лишь заголовки прикладного уровня. Для корректной работы протокола SIP через координатор необходимо знать следующее:
В заключение
Я постарался рассмотреть самые злободневные проблемы, обозначить их корни и рассказать о решениях. Конечно, это далеко не все особенности ViPNet, поэтому рекомендую не стесняться – обращаться в поддержку и спрашивать совета в коммьюнити (на форуме вендора, в телеграмм-канале, в комментариях под этим постом). А если вам не хочется погружаться во все сложности работы с ViPNet или это слишком трудозатратно, то всегда можно отдать управление вашей ViPNet-сетью в руки профессионалов.
Автор: Игорь Виноходов, инженер 2-ой линии администрирования «Ростелеком-Солар»