Что такое vpn гост
ГОСТ-шифрование для VPN
Глобальный локдаун, вызванный пандемией, привёл к взрывному росту потребности в защищенных удаленных подключениях к сетевым ресурсам. Компании, вынужденные перевести сотрудников на удалённый режим работы, срочно перенастроили инфраструктуру для новой реальности. Чаще всего использовались типовые решения, основанные на OpenVPN, WireGuard и их аналогах.
Вскоре выяснилось, что эти продукты имеют общий недостаток: в них нет поддержки отечественных стандартов шифрования ГОСТ 28147-89, ГОСТ 34.10/34.11-2012, ГОСТ 34.12/34.13-2015. А в соответствии с требованиями различных нормативных документов, выпущенных российскими регулирующими органами, при защите каналов связи должны применяться отечественные средства криптографической защиты информации (СКЗИ).
Это значит, что для многих «отсидеться» на OpenVPN с RSA-шифрованием уже не получится. Даже если сделать 4096-битные ключи.
Законодательные требования
Разумеется, все нормативные документы появились значительно раньше начала пандемии. Регуляторы вводили требования по защите каналов связи с использованием отечественной криптографии постепенно.
Приведём перечень нормативных актов, устанавливающих требования к защите каналов передачи данных:
ГОСТ-шифрование в Traffic Inspector Next Generation
Отслеживая законодательные требования, мы своевременно дополнили функциональные возможности Traffic Inspector Next Generation поддержкой отечественных алгоритмов шифрования.
ГОСТ-шифрование в VPN обеспечивает разработанный нашими программистами плагин os-gostvpn. Установить его можно в разделе «Система → Прошивка».
После установки плагина нужно создать внутренний центр сертификации, сертификаты сервера и клиента.
Далее нужно создать VPN сервер в разделе VPN → GOST VPN → Серверы.
После этого можно определить сетевые настройки нового сервера и экспортировать файлы конфигурации для установки на клиентских устройствах в разделе VPN →GOST VPN → Clients export.
Заключение: кому пригодится VPN с поддержкой ГОСТ-шифрования
В обязательном порядке ГОСТ-шифрование в VPN должны использовать государственные организации и госкомпании, банки, медицинские и страховые компании, операторы персональных данных, а также организации и предприятия, входящие в состав КИИ или подключенные к системе ГосСОПКА.
ГОСТ VPN: три примера, когда сервис лучше собственного проекта
На фоне цифровизации экономики вопросу шифрования корпоративных каналов связи уделяется всё больше внимания. В некоторых отраслях, например госсекторе, энергетике или финансах, законодательство требует использовать только российские криптоалгоритмы. Ниже мы разберём на конкретных примерах, когда заказчик может организовать шифрование по ГОСТ самостоятельно, а когда ему выгоднее обратиться к услугам сервис-провайдера.
Введение
Рисунок 1. Законодательство в части требований ИБ при передаче данных
Основные отрасли, которые подпадают под это регулирование:
Потребность в создании защищённых каналов связи во всех этих сферах, как правило, возникает при:
Для построения зашифрованного канала связи заказчик может выбрать два варианта: решение on-premise или сервис. Первое предполагает установку оборудования и управление им локально, то есть внутри организации (силами штатных специалистов или через вендора). Второе — аутсорсинг защиты каналов связи, когда услугу полностью предоставляет сервис-провайдер. Он, в свою очередь, покупает СКЗИ и ведёт их учёт, занимается документированием, настройкой, эксплуатацией, обновлением ключей шифрования, физической заменой оборудования и т. п.
Выбирая способ защиты сети по ГОСТ, заказчик может руководствоваться несколькими критериями. Разберём каждый из них.
Траты заказчика
Затраты на старте
Для небольших проектов (когда речь идёт всего о нескольких криптошлюзах) капитальные затраты невелики и могут быть заказчику по карману. Если количество устройств приближается к нескольким десяткам, уже стоит задуматься о сервисной модели; если к сотням — альтернатива в виде сервиса почти наверняка станет лучшим решением по соотношению цены и качества.
Периодические затраты
Сотрудники
Хорошо, если сотрудники ИТ- или ИБ-службы организации уже знакомы со средствами криптозащиты основных производителей. Но если это не так, им потребуется обучение по каждому конкретному вендору, а при текучке кадров этот процесс станет постоянным. При этом собственные специалисты часто и так перегружены работой и физически не успевают изучать новые продукты и системы. Для сотрудников сервис-провайдера регулярное обучение работе с решениями вендоров-партнёров — одна из ключевых задач, а не дополнение к основной деятельности.
Получение лицензий
В проекте «для собственных нужд» лицензия не требуется, но при необходимости подключать другие юрлица (пусть даже дочерние компании) она понадобится. Стоит ли её получать — зависит от объёма деятельности, связанной с криптографией. Если это — не ключевая составляющая бизнеса организации, то приобретение лицензии очевидно будет лишним.
Доступность
Многие виды деятельности полностью зависят от качества канала связи, так как сотрудники удалённых офисов работают в системах, расположенных в ЦОД или центральном офисе. При этом собственные специалисты заказчика обычно работают по чёткому графику, в то время как неисправности могут возникнуть в любой момент. Захочет ли штатный специалист подключаться к решению проблемы из дома или ехать ночью в офис? Наверное, не захочет, но ему придётся. Сервис-провайдер организует свою работу посменно, и дежурная бригада всегда готова устранить неполадки.
Размещение
Этот вопрос актуален при организации работы через ЦОД сервис-провайдера. Поставить собственное СКЗИ в ЦОД обычно можно при аренде юнитов или отдельных стоек, в облаке это сделать невозможно. В этом случае даже при небольшом количестве оборудования лучше сервисная модель.
Описание проектов и сводный расчёт
Основываясь на этих критериях, рассмотрим оптимальные подходы для каждого из трёх кейсов: объединение офисов в целую сеть, подключение дочерних компаний и контрагентов, организация доступа к ресурсам ЦОД.
Объединение офисов в целую сеть
На этапе инсталляции требуются значительные капитальные затраты на закупку оборудования. В дальнейшем необходима техническая поддержка его работоспособности и периодическое обновление версий ПО от вендора. К операционным затратам также относятся зарплата и обучение штатных специалистов.
Рассмотрим пример: пропускная способность канала связи в центральном офисе компании составляет 100 Мбит/c, в 19 филиалах — по 20–30 Мбит/c. Есть штатные ИТ- и ИБ-подразделения. Необходимо организовать защищённую сеть передачи данных с резервированием в центре.
При проектной модели (on-premise) на старте необходима закупка оборудования примерно на 3,5 млн рублей (эта сумма включает систему управления, криптошлюзы, запасное оборудование). Проектирование и внедрение обойдутся примерно в 750 тыс. рублей с учётом доставки оборудования и работ в регионах. Обслуживание будет осуществляться собственными силами, поэтому необходимо обучить двух сотрудников — ещё по 20 тыс. рублей за каждого.
Ежегодные затраты на вендорскую техподдержку составят 700 тыс. рублей. Затраты на сотрудников — около 250 тыс. рублей (на двух специалистов с зарплатой от 30 до 60 тыс. рублей каждый (после вычета налогов), коэффициент накладных расходов — 1,5, загруженность сотрудников задачей — 10–15 %).
Стоимость обновления ПО, которое потребуется через 3 года, составит примерно 1,5 млн рублей (работы выполняются сотрудниками компании). Обновление оборудования через 6 лет — ещё 3,5 млн рублей.
При выборе сервисной модели заказчик должен оплатить только ежегодную подписку — в данном случае она составляет 2 млн рублей в год. Таким образом, экономия в сравнении с моделью on-premise в первый год составит 56 %, во второй — 27 %, в третий — 17 %. С четвёртого по шестой год on-premise становится более выгодной моделью, но на шестом году из-за покупки нового оборудования взамен устаревшего затраты выравниваются с сервисом.
В итоге сервисная модель поможет распределить финансовые вложения при ограниченном бюджете. Вариант on-premise, в свою очередь, подойдёт для реализации небольших проектов, но только при наличии собственной ИБ-службы заказчика.
Подключение дочерних компаний и контрагентов
Во-вторых, когда каждая организация администрирует оборудование «на своей стороне», отсутствует единая точка ответственности. Непонятно, кто будет устранять неисправности в каждом конкретном случае: специалисты центрального офиса или местные работники.
Сервисная модель освободит заказчика от выполнения лицензионных требований и обеспечит высокую доступность и качество услуги. On-premise подойдёт в том случае, если у каждой из подключаемых организаций налажен процесс приобретения СКЗИ и ключей шифрования, а также если для них не будет критически важным время восстановления после сбоя (несколько часов, а не минут).
Организация доступа к ресурсам ЦОД
Для этого в ЦОД должно быть оборудование, предназначенное для установления ГОСТовых туннелей. Иногда это может быть виртуальная машина, но её класс защиты минимален — КС1. Для более высоких классов — КС2 и КС3 — нужно «железо» рядом с облаком, то есть установка СКЗИ непосредственно в стойку рядом с сервером, на котором расположены защищаемые ресурсы.
Стоимость криптошлюза, устанавливаемого в стойку в ЦОД, составляет порядка 250 тыс. рублей. Ещё один шлюз должен быть установлен на площадке заказчика — минимальный вариант для офиса стоит около 80 тыс. рублей. Необходимо также приобрести ещё один резервный шлюз за 80 тыс. рублей, чтобы при поломке не ждать месяц ремонта в сервис-центре. Суммарно стоимость такого решения составляет 410 тыс. рублей на старте. Ежегодная техподдержка вендора обойдётся ещё в 100 тыс. рублей. Затраты на работы и аренду юнитов могут сильно различаться в зависимости от условий размещения в конкретном ЦОД.
Однако для большинства заказчиков это — слишком дорогой и сложный проект, поэтому они выбирают либо сервис, либо программное решение в виде виртуальной машины (шлюза). Стоимость виртуального шлюза составляет около 100 тыс. рублей (их должно быть два), ежегодная техподдержка составляет 40 тыс. рублей. Резервирование в этом случае осуществляется средствами виртуализации. При этом спустя 5–7 лет потребуется обновление ПО (то есть самого шлюза), а также серверов, на которых работает виртуальная инфраструктура заказчика.
У сервис-провайдеров оборудование обычно уже установлено на логической границе инфраструктуры и заказчику требуется только приобрести подписку на сервис: стоимость защищённого доступа к ЦОД составляет 25 тыс. рублей в месяц. При этом провайдер предоставляет СКЗИ более высокого класса защиты.
В периоде трёх лет совокупные затраты для сервисной и локальной (on-premise) моделей примерно одинаковы. Однако первый вариант обеспечивает высокий класс защиты (КС3) и удобный защищённый доступ к ресурсам в облаке. Решение on-premise подойдёт для организаций, которым достаточно минимального класса защиты в виртуальной среде.
Таблица 1. Краткие выводы по всем трём описанным кейсам
Не требует от заказчика выполнения лицензионных требований и гарантирует высокое качество услуг.
Расходы:
• минимальная цена для одной площадки составляет 10 тыс. рублей в месяц (цена варьируется в зависимости от производительности и требований к отказоустойчивости оборудования).
Расходы:
• обучение персонала — примерно 120 тыс. рублей;
• зарплата профильных сотрудников — 60–90 тыс. рублей в месяц;
• стоимость лицензии сильно варьируется.
Расходы:
• подписка на услуги сервис-провайдера — 25 тыс. рублей в месяц (300 тыс. рублей в год).
Подходит организациям, которым достаточно минимального класса защиты в виртуальной среде.
Расходы:
• 200 тыс. рублей для организации ГОСТ VPN c минимальным классом защиты в первый год, техподдержка в размере 40 тыс. рублей ежегодно, а также расходы на построение виртуальной среды, которые ранее понесла компания, и траты на её поддержку.
• 410 тыс. рублей — в первый год для организации ГОСТ VPN c высоким классом защиты, а также ежегодная техподдержка вендора в размере 100 тыс. рублей. Суммарно за 7 лет — 1,4 млн руб.
Выводы
Что такое vpn гост
НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ
КАЧЕСТВО УСЛУГИ «ПРЕДОСТАВЛЕНИЕ ВИРТУАЛЬНОЙ ЧАСТНОЙ СЕТИ (VPN)»
Quality of service «allocation of the Virtual Private Network». Quality indices
Дата введения 2011-01-01
Сведения о стандарте
1 РАЗРАБОТАН Учреждением «Центр сертификации услуг связи»
2 ВНЕСЕН Управлением развития, информационного обеспечения и аккредитации Федерального агентства по техническому регулированию и метрологии
3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 15 декабря 2009 г. N 1193-ст
1 Область применения
Настоящий стандарт предназначен для использования представителями государственных органов, осуществляющих регулирование в области связи, научными и проектными организациями при разработке и проектировании сетей и служб, при разработке стандартов в области связи, хозяйствующими субъектами, действующими в области оказания услуг предоставления виртуальной частной сети, контролирующими их органами, включая органы сертификации, а также пользователями услуг связи.
На основании данного стандарта хозяйствующими субъектами, действующими в области оказания услуг предоставления виртуальной частной сети, могут разрабатываться собственные (внутренние) нормативные документы, определяющие систему показателей качества на услугу предоставления виртуальной частной сети.
Нормы, конкретные требования к показателям качества, значения этих показателей и методы их контроля (оценки) должны быть определены соответствующей нормативной документацией, утверждаемой в установленном порядке.
2 Нормативные ссылки
В настоящем стандарте использованы ссылки на следующие стандарты:
ГОСТ Р 53724-2009 Качество услуг связи. Общие положения
ГОСТ Р 53731-2009 Качество услуг связи. Термины и определения.
3 Термины и определения
В настоящем стандарте применены термины по ГОСТ Р 53731, а также следующие термины с соответствующими определениями:
3.1 абонент: Пользователь услуг связи, с которым заключен договор об оказании таких услуг при выделении для этих целей абонентского номера или уникального кода идентификации.
3.3 оператор связи: Юридическое лицо или индивидуальный предприниматель, оказывающие услуги связи на основании соответствующей лицензии.
3.5 услуга предоставления виртуальной частной сети: Совокупность действий оператора связи по построению и обеспечению функционирования виртуальной частной сети абонента с произвольной топологией на основе сетевой инфраструктуры оператора.
4 Качество услуги «Предоставление виртуальной частной сети (VPN)»
4.1 Общее описание услуги
4.1.1 Услуга заключается, в первую очередь, в предоставлении исполнителем (оператором связи) возможности абонентам объединить локальные сети удаленных офисов в единую корпоративную сеть на основе технологии VPN.
4.1.2 Для построения виртуальных частных сетей исполнитель (оператор) может использовать разные технологии:
— шифрование туннелей в сети Интернет,
— беспроводные технологии и др.
4.1.3 Возможны несколько видов топологии виртуальной частной сети:
— «без полной связности».
4.1.4 При оказании услуги исполнитель (оператор) обязан обеспечить предоставление абоненту:
а) доступа к соответствующей сети VPN;
б) возможности интегрированной передачи по сети VPN (согласно классу обслуживания): данных различных видов, голосовой информации, видео-, факсимильных сообщений.
Оператор связи обязан устранять в установленные сроки неисправности, препятствующие пользованию услугой.
4.1.5 Деятельность по оказанию услуги «Предоставление виртуальной частной сети (VPN)» включает следующие основные этапы:
— предоставление доступа к услуге (4.1.7);
— собственно оказание услуги в штатном режиме (4.1.8);
— расчеты за услугу (4.1.0)*;
— обслуживание обращений абонента (4.1.10);
— техническая поддержка услуги (4.1.11).
Каждый этап характеризуется рядом потребительских свойств. Для оценки потребительских свойств используются показатели качества.
4.1.6 Оказание услуги осуществляется оператором в соответствии с действующим законодательством Российской Федерации и нормативно-правовыми актами в области связи.
4.1.7 Доступ к узлу сети оператора может быть организован: с использованием выделенных цифровых каналов, путем подключения через мультисервисные сети других операторов.
4.1.8 Собственно оказание услуги в штатном режиме производится при выполнении следующих условий:
— заключен договор между абонентом и оператором;
— абонентом выполнены условия договора в части оплаты;
— оператором обеспечена техническая возможность доступа к услуге.
Показатели качества услуги VPN, характеризующие этап собственно оказания услуги в штатном режиме, предназначены для того, чтобы оценить следующие основные потребительские свойства этого этапа:
— качество передачи пользовательской информации.
Границы ответственности оператора за качество предоставляемой услуги определяются в SAP, что оговаривается условиями договора.
SAP всегда находится на оборудовании оператора [3].
4.1.10 Обращения абонента к оператору могут быть вызваны следующими причинами:
— потребностью получить данные, связанные с предоставлением услуги;
— потребностью получить справочную информацию;
— техническими неисправностями и др.
Оператор обязан предоставлять абонентам данные, касающиеся предоставления услуг, а также оказывать пользователям информационно-справочные услуги: обязательные (бесплатные) и другие, по собственному усмотрению (платные) [1], [2], [3].
Оператор обязан бесплатно принимать от абонентов информацию о технических неисправностях.
Действия (или бездействие) оператора связи, касающиеся предоставления услуги, могут быть обжалованы абонентом.
Показатели качества услуги VPN, характеризующие этап обслуживания обращений абонентов, предназначены для того, чтобы оценить следующие основные потребительские свойства этого этапа:
— доступность служб оператора;
— своевременность и (или) скорость обслуживания;
4.1.11 Техническая поддержка услуги заключается в устранении службами оператора неисправностей, препятствующих или затрудняющих пользование услугой. Службы оператора обязаны устранять неисправности в установленные сроки и по договоренности с абонентом.
4.2 Показатели качества услуги VPN
Основные показатели качества услуги VPN приведены в таблице 1.
Предоставление доступа к услуге
Своевременность и (или) скорость выполнения работ:
Доля заявок на подключение услуги, обслуженных в пределах установленной нормы
Собственно оказание услуги в штатном режиме
Коэффициент готовности оборудования сети оператора
Время восстановления оборудования сети оператора
Качество передачи пользовательской информации:
Процент потерянных пакетов
Средние сетевые задержки пакетов
Средние колебания сетевых задержек пакетов
Время переноса кадра
Коэффициент потери кадров
Правильность расчетов за услуги:
Доля обоснованных претензий, связанных с расчетами за услуги, в общем количестве обоснованных претензий абонентов
Обслуживание обращений абонента
Доступность служб оператора:
Доля успешных вызовов службы
Своевременность и (или) скорость обслуживания:
Доля обращений, обслуженных в пределах установленных норм (по видам обращений)
Доля пользователей, удовлетворенных качеством обслуживания
Техническая поддержка услуги
Своевременность и (или) скорость выполнения работ:
Доля работ по устранению неисправностей, выполненных в пределах установленных сроков
Шифруемся по ГОСТу: памятка по настройке динамической маршрутизации трафика
Пара слов о проекте
Топология сети у заказчика была типовая — 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-ой линии администрирования «Ростелеком-Солар»