сайт использует шифрование по госту что это
SSL VPN с поддержкой ГОСТ и перспективы развития этого направления
Благодаря Google всего несколько лет назад организация защищённого соединения с помощью SSL при посещении сайтов стала не только «правилом хорошего тона», но и необходимостью. В нынешних реалиях, при тех скоростях развития сервисов, которые мы наблюдаем, очень важно защитить те сайты, которые являются «лицом» государства и призваны обеспечивать население определёнными услугами и сервисами. Для этого принято решение использовать шифрование по ГОСТ.
Введение
Технология SSL VPN не нова — она рассматривалась на портале Anti-Malware.ru ещё в 2008 году как альтернатива подключению VPN IPsec. Одно из преимуществ этой технологии — подключение пользователей к ресурсам компании с использованием веб-технологий, без прямого соединения с сетью. Таким образом можно избежать объединения недоверенных сетей (например, домашнего провайдера) с сетью предприятия. При этом SSL VPN можно рассматривать как средство не только удалённого доступа к ресурсам своей компании, но и подключения к сервисам, предоставляемым интернет-порталами. Есть ли возможность уйти от привычных сертификатов и использовать сертификаты ГОСТ? Есть ли перспективы у этого направления? Давайте попробуем разобраться.
История государственного регулирования SSL ГОСТ
Веб-сервисы с SSL-сертификатами по ГОСТ не являются чем-то новаторским. Системные администраторы уже порядка 10 лет организовывают HTTPS-соединения с использованием ГОСТ-шифрования. Однако если раньше подобная активность инициировалась независимыми специалистами, то 29 января 2016 года эта тема вышла на государственный уровень. На сайте kremlin.ru появился перечень поручений по итогам первого российского форума «Интернет-экономика». Под 12-м пунктом в перечне значится: «ФСБ России, Минкомсвязи России совместно с заинтересованными федеральными органами исполнительной власти представить предложения по изменению требований к шифрованию данных, передаваемых по сетям связи в Российской Федерации, предусмотрев ответственность за их нарушение». Таким образом, этот день можно считать отправной точкой в истории государственного регулирования стандартов шифрования данных, курсирующих в рунете.
Следующим этапом развития этой истории можно считать утверждение в ноябре 2018 г. создания национального удостоверяющего центра в рамках программы «Цифровая экономика». В соответствии с паспортом проекта, УЦ должен быть создан к концу 2021 г. В ноябре 2019 г. на реализацию этого проекта был назначен НИИ «Восход», подведомственный Минкомсвязи.
Следующий этап (хоть и косвенный) — закон, обязывающий предустанавливать определённые программы на ввозимую в Россию технику (смартфоны, телевизоры с функцией Smart TV): находящийся в реестре «Яндекс.Браузер» поддерживает ГОСТ-шифрование.
Все эти этапы наглядно показывают вектор развития отечественного шифрования: организован системный процесс по переводу российского сегмента интернета на использование отечественных сертификатов, выпущенных по стандарту TLS.
В этом ключе интересна новость о внедрении на портале Госуслуг поддержки TLS с использованием российских криптоалгоритмов. Такие подключения в настоящее время поддерживают браузеры «Спутник», «Яндекс», Internet Explorer и Chromium GOST.
Предпосылки перевода рунета на отечественную криптографию
Зачем вообще массово внедрять отечественную криптографию? А если вопрос ощущается остро — почему не сделали этого раньше?
Российская Федерация уже около 10 лет старается зарезервировать на национальном уровне международные сервисы. «Первой ласточкой» стала национальная платёжная система, закон о которой появился в 2011 году, а реализация последовала в 2014 году.
В 2016 году появились предпосылки к закону о «суверенном интернете», а в 2019-м — соответствующий законодательный акт.
Основной риск, который видится при использовании подобных сервисов в рамках целой страны, — полное их отключение в случае применения санкций в отношении России. Так, в 2014 году, после проведения референдума в Крыму и присоединения полуострова к России, Visa и MasterCard приостановили обслуживание карт нескольких российских банков.
Этот же риск возможен и в отношении сертификатов, выданных зарубежными УЦ. В начале июня 2018 года сайт Общественной палаты при попытке входа на него показывал сообщение «Ваше подключение не защищено. Злоумышленники могут попытаться похитить ваши данные». Причиной стал отзыв SSL-сертификата одним из крупнейших удостоверяющих центров — американской компанией GeoTrust по причине «аффилированности» палаты с Донецкой Народной Республикой, которая находится под санкциями США.
Ещё одним «двигателем» проекта стал так называемый «закон Яровой», в соответствии с которым операторы связи в течение определённого количества времени обязаны хранить трафик пользователей. Получив контроль над выпущенными сертификатами, можно дешифровать этот трафик в случае необходимости. Подобные прецеденты ранее выявляли в Китае, Казахстане и даже такой демократичной стране, как Франция.
Так почему же национальный удостоверяющий центр не был реализован раньше? Ответ вполне прост: это — весьма масштабный проект, требующий больших вложений и наличия соответствующей инфраструктуры. На весь проект было выделено около 1 млрд рублей. Также немаловажный фактор — недооценка возможности отзыва сертификата до первого такого случая, который произошёл с Общественной палатой.
Схема работы национального удостоверяющего центра
Схема работы национального удостоверяющего центра представлена ниже. В соответствии с ней, пользователь при подключении к государственным, муниципальным и иным (а список их будет расширяться) системам будет проходить через инфраструктуру ФГИС «Головной удостоверяющий центр», после чего через VPN ГОСТ попадать на запрошенный ресурс. Для пользователя этот маршрут будет прозрачным, несмотря на прохождение через ряд защитных средств, таких как сервер аутентификации TLS, межсетевые экраны и т. д.
Рисунок 1. Архитектурная схема централизованных решений и взаимосвязи с внешними информационными системами
Участники взаимодействия и перспективы развития
По планам НИИ «Восход» в первую очередь предполагаемыми участниками взаимодействия становятся организации тесно работающие с физическими и юридическими лицами и предоставляющие им определённые сервисы: органы власти, банки и страховые компании, организации распространения информации в сети «Интернет», определённые Роскомнадзором. Также это — системы, непосредственно участвующие в организации взаимодействия: ЕСИА — единая система идентификации и аутентификации, а также СМЭВ — система межведомственного электронного взаимодействия.
Шифрование по ГОСТ уже сейчас работает в браузерах Microsoft Edge (нативно), Internet Explorer (нативно), «Яндекс.Браузер», «Спутник», Сhromium-gost (для последних трёх необходимо установить модуль «КриптоПро CSP 4.0» версии R4 и выше. В браузере «Спутник» при просмотре сайта mos.ru, на котором используется ГОСТ-шифрование, вы можете увидеть вместо привычного замочка двуглавого орла.
Следующие этапы пока не определены, но можно спрогнозировать, что государство постепенно будет переводить на TLS по ГОСТ весь рунет, начиная с организаций с госучастием, крупных торговых площадок (в первую очередь — B2B), операторов сотовой связи и других.
Выводы
Определённо, от внедрения отечественной криптографии на веб-ресурсах выиграет государство, которое получит возможность контролировать зашифрованный трафик, а также защищаться от возможных санкций со стороны других стран. Вторая сторона, которая получит определённые блага, — это удостоверяющие центры, которые будут выпускать ГОСТовые сертификаты для юридических лиц, а также программное обеспечение для работы с ними.
Будут ли проигравшие стороны? Пока неизвестно. Однако, в случае если применение обозначенных сертификатов станет обязательным, проигравшим может стать малый бизнес, который получит новую статью расходов, связанную с выпуском сертификатов и их поддержкой. Также, поскольку сертификаты являются СКЗИ, в соответствии с приказом ФАПСИ № 152 от 13.06.2001 появится необходимость вести их учёт, а их отсутствие станет рычагом давления на бизнес.
Шифрование по ГОСТу: кому оно показано и как применять
Ситуация с рисками информационной безопасности (ИБ) во всем мире развивается таким образом, что специальная защита корпоративных каналов связи становится объективной необходимостью — вопрос только в выборе наиболее удобных и экономически выгодных ИБ-решений. Дополнительными стимулами в этом направлении стали программа «Цифровая экономика» и стратегия импортозамещения в сфере ИТ. Как регулируется VPN-шифрование в нашей стране, почему в целом растет популярность ГОСТ-криптографии и в каких случаях целесообразно приобретать ее как сервис — разбираемся вместе с руководителем направления ГОСТ VPN компании «Ростелеком-Солар» Александром Веселовым.
Содержание
Российская криптография как требование регуляторов
По мере усиления информатизации различных отраслей экономики РФ соответствующие регуляторы вводят требования по защите каналов связи, причем с применением российских средств криптографической защиты информации (СКЗИ). Например, в финансовой отрасли действует Положение Банка России № 672-П, а также ГОСТ Р 57580.1-2017 — базовый стандарт совершения страховыми организациями операций на финансовом рынке. В соответствии с указанием Банка России и ПАО «Ростелеком» №4859-У/01/01/782-18 о Единой биометрической системе (ЕБС), криптозащита необходима на всех этапах передачи данных между инфраструктурой банков, банковскими приложениями и сервисами электронного правительства.
Минздрав РФ выпустил приказ №911н, который вступает в силу с 1 января 2020 года и касается всех медицинских и фармацевтических организаций. Приказ требует использовать сертифицированные средства защиты, в том числе для каналов связи.
В электроэнергетике в конце 2018 г. утвержден приказ Министерства энергетики №1015, в соответствии с которым для защиты Систем Удаленного Мониторинга и Диагностики (СУМиД) необходимо использовать сертифицированные средства защиты. По сути, речь идет о защищенном обмене данными в контуре АСУ ТП.
Криптографическая защита становится проще и доступнее
Первую попытку упростить ситуацию для заказчиков сделали вендоры: ввели техническую поддержку с возможностью обновления версии СКЗИ. Это действительно сняло некоторую головную боль клиентов, но не всю, ведь вопросы эксплуатации, требующие участия высококвалифицированного персонала, остались. Закрыть этот вопрос можно с помощью сервисной модели. В Постановлении Правительства РФ № 313 «Об утверждении Положения о лицензировании деятельности по разработке, производству, распространению шифровальных (криптографических) средств. » указывается, что решение данных задач возможно не только с привлечением сторонней организации на разных этапах проекта, но и посредством сервисной модели.
Поставщиков сервиса класса «VPN с криптографической защитой (ГОСТ) как сервис» можно условно разделить на две группы: операторы связи и облачные провайдеры. Облачные провайдеры (МТС, «Ростелеком», Dataline и др.) предлагают организовать защищенный по ГОСТу доступ к своим сервисам. А операторы связи могут применить отечественное шифрование на своих каналах связи. Такие услуги предоставляют, например, «Ростелеком», «Мегафон», Orange.
Это очень динамичный сегмент рынка, набирающий обороты, отмечает Александр Веселов:
ГОСТ VPN — на примере сервиса «Ростелеком-Солар»
Характеристики защищенности ГОСТ VPN
Требования к СКЗИ различных классов не являются общедоступными, но некоторая их часть изложена в Рекомендациях по стандартизации Р 1323565.1.012-2017 «Информационная технология. Криптографическая защита информации. Принципы разработки и модернизации шифровальных (криптографических) средств защиты информации». Основные технические особенности оборудования класса КС3 – разграничение доступа администраторов безопасности, замкнутая программная среда и криптографический контроль целостности компонентов.
СКЗИ данного класса выпускают в виде программно-аппаратных комплексов различной производительности.
Сервис ГОСТ VPN, обеспечивающий защиту каналов связи, реализует эту защиту на канальном и сетевом уровнях (L2/L3) модели OSI. Выбор того или иного механизма защиты зависит от специфики задач клиента. Скажем, конфигурирование управляемой из облака сети, защищенной на уровне L3, обеспечивает возможности практически неограниченного масштабирования. На подобных принципах базируется, в частности, сетевая архитектура Интернета или крупных дата-центров. На сетевом уровне L3 работают протоколы динамической маршрутизации, например, OSPF и др., позволяя строить кратчайшие пути для пакетов данных или отправлять их одновременно по нескольким путям для балансировки загрузки и т.д.
Особенности эксплуатации защищенных каналов связи в рамках сервисной модели
Провайдер услуги осуществляет работы на каждом этапе жизненного цикла сервиса: от закупки и построения до эксплуатации системы криптозащиты. Заказчику не обязательно выбирать производителя СКЗИ — по его запросу все требуемые действия выполнит поставщик услуги. Сервис-провайдер самостоятельно поддерживает версию СКЗИ в актуальном состоянии (приобретение новой версии, удаленное или локальное обновление), обеспечивает работоспособность аппаратной части (пул запасного оборудования, выезды на объекты, перенос конфигурации), ведет журнал учета СКЗИ и другую документацию. При этом осуществляет актуализацию политик безопасности и обновление ключей, круглосуточный мониторинг работоспособности и устранение инцидентов.
После установки СКЗИ у заказчика за их эксплуатацию полностью отвечает команда квалифицированных ИБ-специалистов «Ростелеком-Солар», что гарантирует:
Важно, что провайдер услуги берет на себя все заботы, связанные с соблюдением законодательства в отношении средств криптозащиты: применение только сертифицированных продуктов лидирующих вендоров, тщательное отслеживание всех изменений нормативной базы – сервис всегда соответствует всем нюансам актуальных законов и регламентов. И это при минимуме бюрократии на стороне клиента и прогнозируемых затратах.
В чем преимущества сервисной модели ГОСТ VPN
Оплата фактически потребляемого сервиса дает прямую экономию:
Экономия на стоимости услуг высококвалифицированного ИБ-персонала:
Как правило, физической границей разделения зон ответственности между заказчиком и поставщиком сервиса являются внутренние порты предоставляемого оборудования. Поскольку оно устанавливаются у клиента, тот должен заботиться о сохранности аппаратных решений и соблюдать ряд условий: по электропитанию, климат-контролю, свободным сетевым интерфейсам, при необходимости — местам в стойке.
Кому «доктор прописал» сервис ГОСТ VPN
Небольшая компания с двумя-тремя офисами вполне может обойтись при создании защищенных каналов собственными силами: начальные расходы на старте проекта невелики, а трудозатраты по эксплуатации решения вполне можно распределить между имеющимися сотрудниками.
Компании среднего бизнеса с 10–40 объектами имеют более сложные сетевые инфраструктуры, им зачастую требуется помощь сторонней профессиональной компании-интегратора для проектирования защищенной сети, внедрения решения, а также дальнейшей технической поддержки. В таких условиях сервисная модель оказывается практически идеальным выбором: сервис-провайдер предоставит оборудование и обеспечит эксплуатацию, а заказчику вообще не придется участвовать в процессах технической поддержки, содержать дополнительный ИТ/ИБ-персонал в офисах. Понятно, что радикально снижается совокупная стоимость системы защиты.
В крупных распределенных компаниях с количеством офисов более 50 всегда есть множество специфических особенностей. И обычно в таких организациях есть свой штат квалифицированного персонала. В этом случае для проектирования и внедрения защищенной сети обмена данными компания может привлечь интегратора, а эксплуатацию осуществлять собственными силами. И здесь переход на сервисную модель поможет распределять во времени затраты на поддержку системы, а также освободит персонал от рутинных работ, позволяя сконцентрироваться на основном бизнесе.
Шифруемся по ГОСТу: памятка по настройке динамической маршрутизации трафика
Если ваша компания передаёт или получает по сети персданные и другую конфиденциальную информацию, подлежащую защите в соответствии с законодательством, требуется применять шифрование по ГОСТу. Сегодня мы расскажем, как внедрили такое шифрование на базе криптошлюза (КШ) S-Terra у одного из заказчиков. Эта история будет интересна ИБ-специалистам, а также инженерам, проектировщикам и архитекторам. Глубоко погружаться в нюансы технической конфигурации в данном посте мы не будем — остановимся на ключевых моментах базовой настройки. Огромные объемы документации по настройке демонов ОС Linux, на которой базируется КШ S-Terra, есть в свободном доступе в интернете. Документация по настройке проприетарного ПО S-Terra располагается также в открытом доступе на портале производителя.
Пара слов о проекте
Топология сети у заказчика была типовая — full mesh между центром и филиалами. Требовалось внедрить шифрование каналов обмена информацией между всеми площадками, коих было 8 штук.
Обычно в подобных проектах всё статично: на криптошлюзах (КШ) задаются статические маршруты в локальную сеть площадки, прописываются списки IP-адресов (ACL) для шифрования. Однако в данном случае у площадок нет централизованного управления, и внутри их локальных сетей может происходить всё, что угодно: сети могут добавляться, удаляться и всячески модифицироваться. Для того чтобы избежать перенастройки маршрутизации и ACL на КШ при изменении адресации локальных сетей на площадках, было принято решение использовать GRE-туннелирование и динамическую маршрутизацию OSPF, в которую включены все КШ и большинство маршрутизаторов уровня ядра сети на площадках (на некоторых площадках администраторы инфраструктуры предпочли использовать SNAT в сторону КШ на маршрутизаторах ядра).
GRE-туннелирование позволило решить две задачи:
1. Использовать в ACL для шифрования IP-адрес внешнего интерфейса КШ, в котором инкапсулируется весь трафик, направляющийся на другие площадки.
2. Организовать p-t-p туннели между КШ, которые позволяют настроить динамическую маршрутизацию (в нашем случае между площадками организован провайдерский MPLS L3VPN).
Клиент заказал реализацию шифрования как услугу. Иначе ему пришлось бы не просто поддерживать криптошлюзы или сдавать в аутсорс какой-то организации, но и самостоятельно отслеживать жизненный цикл сертификатов шифрования, вовремя их продлевать и устанавливать новые. 
А теперь собственно памятка – как и что мы настраивали
Субъекту КИИ на заметку: настраиваем криптошлюз
Базовая настройка сети
Прежде всего запускаем новый КШ и попадаем в консоль администрирования. Начать стоит с изменения пароля встроенного администратора — команда change user password administrator. Затем необходимо с провести процедуру инициализации (команда initialize) в процессе которой вводятся данные лицензии и инициализируется датчик случайных чисел (ДСЧ).
Обратите внимание! При инициализации КШ S-Terra устанавливается политика безопасности, при которой интерфейсы шлюза безопасности не пропускают пакеты. Необходимо либо создать собственную политику, либо с помощью команды run csconf_mgr activate выполнить активацию предустановленной разрешающей политики.
Далее необходимо настроить адресацию внешних и внутренних интерфейсов, а также маршрут по умолчанию. Работу с сетевой конфигурацией КШ и настройку шифрования предпочтительно выполнять через Cisco-like консоль. Данная консоль предназначена для ввода команд, аналогичных командам Cisco IOS. Конфигурация, сформированная с помощью Cisco-like консоли, в свою очередь конвертируется в соответствующие конфигурационные файлы, с которыми работают демоны ОС. Перейти в Cisco-like консоль из консоли администрирования можно командой configure.
Меняем пароли на встроенного пользователя cscons и enable:
>enable
Password: csp(предустановленный)
#configure terminal
#username cscons privilege 15 secret 0 #enable secret 0 Настраиваем базовую сетевую конфигурацию:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#no shutdown
#interface GigabitEthernet0/1
#ip address 192.168.2.5 255.255.255.252
#no shutdown
#ip route 0.0.0.0 0.0.0.0 10.111.21.254
Выходим из Cisco-like консоли, и переходим в debian shell командой system. Устанавливаем собственный пароль для пользователя root командой passwd.
На каждом КШ настраивается отдельный туннель для каждой площадки. Настройка туннельного интерфейса производится в файле /etc/network/interfaces. За создание самого интерфейса отвечает утилита IP tunnel, входящая в предустановленный набор iproute2. Команда создания интерфейса прописывается в опцию pre-up.
Пример конфигурации типового туннельного интерфейса:
auto site1
iface site1 inet static
address 192.168.1.4
netmask 255.255.255.254
pre-up ip tunnel add site1 mode gre local 10.111.21.3 remote 10.111.22.3 key hfLYEg^vCh6p
Обратите внимание! Надо заметить, что настройки туннельных интерфейсов необходимо располагать вне секции
В противном случае данные настройки будут затерты при изменении сетевых настроек физических интерфейсов через Cisco-like консоль.
Динамическая маршрутизация
В S-Terra динамическая маршрутизация реализуется при помощи пакета программ Quagga. Для настройки OSPF нам потребуются включение и настройка демонов zebra и ospfd. Демон zebra отвечает за взаимодействие между демонами маршрутизации и ОС. Демон ospfd, как понятно из названия, отвечает за реализацию протокола OSPF.
Настройка OSPF производится либо через консоль демона, либо напрямую через конфигурационный файл /etc/quagga/ospfd.conf. В файл добавляются все физические и туннельные интерфейсы участвующие в динамической маршрутизации, а также объявляются сети, которые будут анонсироваться и принимать анонсы.
Пример конфигурации, которую требуется добавить в ospfd.conf:
interface eth0
!
interface eth1
!
interface site1
!
interface site2
router ospf
ospf router-id 192.168.2.21
network 192.168.1.4/31 area 0.0.0.0
network 192.168.1.16/31 area 0.0.0.0
network 192.168.2.4/30 area 0.0.0.0
В данном случае адреса 192.168.1.х/31 отведены под туннельные ptp-сети между площадками, адреса 192.168.2.х/30 — под транзитные сети между КШ и маршрутизаторами ядра.
Обратите внимание! Для уменьшения таблицы маршрутизации в крупных инсталляциях можно отфильтровать анонсирование самих транзитных сетей с помощью конструкций no redistribute connected или redistribute connected route-map.
После настройки демонов необходимо изменить статус запуска демонов в /etc/quagga/daemons. В опциях zebra и ospfd no исправить на yes. Запустить демон quagga и установить его автозапуск при запуске КШ командой update-rc.d quagga enable.
Если настройка GRE-туннелей и OSPF выполнена верно, то на КШ и маршрутизаторах ядра должны появится маршруты в сети остальных площадок и, таким образом, возникает сетевая связность между локальными сетями.
Шифруем передаваемый трафик
Как уже было написано, обычно при шифровании между площадками мы указываем диапазоны IP-адресов (ACL), между которыми шифруется трафик: если адреса источника и получателя попадают в эти диапазоны, то трафик между ними шифруется. Однако в данном проекте структура динамическая и адреса могут меняться. Так как мы уже настроили GRE-туннелирование, в качестве адресов источника и получателя для шифрования трафика можем указать внешние адреса КШ — ведь для шифрования приходит трафик, уже инкапсулированный протоколом GRE. Иными словами, шифруется всё, что попадает в КШ из локальной сети одной площадки в сторону сетей, которые были анонсированы другими площадками. А уже внутри каждой из площадок может выполняться любая переадресация. Таким образом, при каком-либо изменении локальных сетей администратору достаточно модифицировать анонсы, идущие из его сети в сторону КШ, и она станет доступной для других площадок.
Шифрование в КШ S-Terra выполняется посредством протокола IPSec. Мы используем алгоритм «Кузнечик» в соответствии с ГОСТ Р 34.12-2015, а для совместимости со старыми версиями можно применить ГОСТ 28147-89. Аутентификация технически может выполняться как на предопределенных ключах (PSK), так и на сертификатах. Тем не менее в промышленной эксплуатации необходимо использовать сертификаты, выпущенные по ГОСТ Р 34.10-2012.
Работа с сертификатами, контейнерами и CRL выполняется с помощью утилиты cert_mgr. Первым делом с помощью команды cert_mgr create необходимо сформировать контейнер закрытого ключа и запрос на сертификат, который будет направлен в Центр управления сертификатами. После получения сертификата его вместе с корневым сертификатом УЦ и CRL (если используется) необходимо импортировать командой cert_mgr import. Убедиться в том, что все сертификаты и CRL установились можно командой cert_mgr show.
После успешной установки сертификатов переходим в Cisco-like консоль для настройки IPSec.
Создаем IKE-политику, в которой указываются желаемые алгоритмы и параметры создаваемого защищенного канала, которые будут предложены партнеру для согласования.
#crypto isakmp policy 1000
#encr gost341215k
#hash gost341112-512-tc26
#authentication sign
#group vko2
#lifetime 3600
Данная политика применяется при построении первой фазы IPSec. Результатом успешного прохождения первой фазы служит установление SA (Security Association).
Далее нам потребуется определить список IP-адресов источника и получателя (ACL) для шифрования, сформировать набор преобразований (transform set), создать криптографическую карту (crypto map) и привязать ее к внешнему интерфейсу КШ.
Задаем ACL:
#ip access-list extended site1
#permit gre host 10.111.21.3 host 10.111.22.3
Набор преобразований (так же, как и для первой фазы, используем алгоритм шифрования «Кузнечик» с использованием режима выработки имитовставки):
#crypto ipsec transform-set GOST esp-gost341215k-mac
Создаем криптокарту, указываем ACL, transform set и адрес пира:
#crypto map MAIN 100 ipsec-isakmp
#match address site1
#set transform-set GOST
#set peer 10.111.22.3
Привязываем криптокарту к внешнему интерфейсу КШ:
#interface GigabitEthernet0/0
#ip address 10.111.21.3 255.255.255.0
#crypto map MAIN
Для шифрования каналов с другими площадками необходимо повторить процедуру создания ACL и криптокарты, изменив название ACL, IP-адреса и номер криптокарты.
Обратите внимание! В том случае, если не используется проверка сертификатов по CRL, это необходимо явно указать:
#crypto pki trustpoint s-terra_technological_trustpoint
#revocation-check none
На этом настройку можно считать завершенной. В выводе команд Cisco-like консоли show crypto isakmp sa и show crypto ipsec sa должны отражаться построенные первые и вторые фазы IPSec. Эту же информацию можно получить с помощью команды sa_mgr show, выполненной из debian shеll. В выводе команды cert_mgr show должны появиться сертификаты удаленных площадок. Статус таких сертификатов будет remote. В том случае если туннели не строятся, необходимо заглянуть в лог VPN-сервиса, который хранится в файле /var/log/cspvpngate.log. Полный список лог-файлов с описанием их содержания присутствует в документации.
Мониторим «здоровье» системы
В КШ S-Terra для мониторинга используется стандартный демон snmpd. Помимо типичных для Linux параметров, S-Terra «из коробки» поддерживает выдачу данных об IPSec-туннелях согласно CISCO-IPSEC-FLOW-MONITOR-MIB, чем мы и пользуемся, отслеживая состояние IPSec-туннелей. Также поддерживается функционал кастомных OID’ов выдающих в качестве значений результаты выполнения скрипта. Эта возможность позволяет нам отслеживать сроки истечения сертификатов. Написанный скрипт парсит вывод команды cert_mgr show и в результате выдает количество дней до истечения локального и корневого сертификатов. Данный прием незаменим при администрировании большого количества КШ. 
В чем цимус такого шифрования
Вся описанная выше функциональность поддерживается «из коробки» КШ S-Terra. То есть не пришлось устанавливать никаких дополнительных модулей, которые могли бы повлиять на сертификацию криптошлюзов и аттестацию всей информационной системы. Каналы между площадками могут быть любые, хоть через интернет.
Благодаря тому, что при изменении внутренней инфраструктуры не нужно перенастраивать криптошлюзы, система работает как услуга, что очень удобно для заказчика: он может свои сервисы (клиентские и серверные), располагать на любых адресах, и все изменения динамически передадутся между шифровальным оборудованием.
Безусловно, шифрование за счет накладных расходов (overhead) влияет на скорость передачи данных, но незначительно — пропускная способность канала может снизиться максимум на 5—10 %. При этом технология протестирована и показала хорошие результаты даже на спутниковых каналах, которые довольно нестабильны и обладают низкой пропускной способностью.
Игорь Виноходов, инженер 2-ой линии администрирования «Ростелеком-Солар»