Общая логика работы

1.    Размещение устройств.

1.1.     В центральном офисе размещаются: центры выпуска сертификатов (Certification_authority_OLD и Certification_authority_NEW), АРМ администратора (Admin_workstation), криптошлюз «С-Терра Шлюз» (Hub1) и персональный компьютер (host-behind-hub1);

1.2.     В неконтролируемом сегменте (синее облако на схеме взаимодействия (см. рисунок 1)) размещаются: HTTP сервер для распространения списка отозванных сертификатов (CRL_distribution_point), маршрутизаторы (Core-ISP, Client-ISP);

1.3.     В сети филиала 1 размещаются криптошлюз «С-Терра Шлюз» (Spoke1) и персональный компьютер (host-behind-spoke1);

1.4.     В сети филиала 2 размещаются криптошлюз «С-Терра Шлюз» (Spoke2) и персональный компьютер (host-behind-spoke2);

1.5.     За пределами сети центрального офиса размещается компьютеры пользователей с ПО «С-Терра Клиент» (Client1 и Client2).

2.    Подключение к сети Интернет.

2.В данном сценарии для эмуляции сети Интернет используются маршрутизаторы Core-ISP и Client-ISP.

2.1.     Криптошлюз Hub1 подключается к сети Интернет с помощью статической маршрутизации (маршрут по умолчанию через маршрутизатор Core-ISP).

2.2.     Компьютеры пользователей Client1 и Client2 подключается к сети Интернет с помощью статической маршрутизации (маршрут по умолчанию через маршрутизатор Client-ISP).

2.3.     На маршрутизаторе Client-ISP происходит трансляция сетевых адресов (source NAT) в IP-адрес внешнего сетевого интерфейса (ens256).

В данном сценарии предполагается, что в центральном офисе не известно о том, в какой IP-адрес будут транслироваться запросы с компьютеров пользователей Client1 и Client2, так как устройства Client1 и Client2 могут находиться в любой части сети Интернет.

3.    Использование нескольких УЦ.

Использование одновременно нескольких УЦ в VPN сети может быть вызвано разными причинами. В данном же сценарии в качестве причины рассматривается необходимость миграции с сертификатов, выпущенных по ГОСТ 2001, на сертификаты, выпущенные в соответствии с ГОСТ 2012 года. То есть, предполагается, что есть какое-то количество VPN устройств, которые штатно работают и используют сертификаты, выпущенные по ГОСТ 2001 года (в данном сценарии это устройства Hub1, Spoke1 и Client1). Соответственно, требуется, чтобы новые VPN устройства (в данном сценарии это устройства Spoke2 и Client2) использовали уже новые сертификаты, выпущенные по ГОСТ 2012 года. В дополнении к этому требуется обеспечить, чтобы VPN устройства со старыми и новыми сертификатами работали одновременно.

Чтобы на центральном криптошлюзе при помощи консоли cisco-like корректно развести на две группы VPN устройства, использующие старые и новые сертификаты, требуется, чтобы в DN (Distinguished Names) всех новых сертификатов был явно идентифицирующий признак. То есть во всех новых сертификатах должно присутствовать поле, отличающееся от того же поля в старых сертификатах или отсутствующее в них.

Например, DN для старых сертификатов «C=RU, CN=Client1, OU=IT» и DN для новых сертификатов «C=RU, CN=Client2, OU=IT_2012».

4.    Параметры безопасного взаимодействия.

Весь IP трафик между подсетью центрального офиса и подсетями филиалов, а также между подсетью центрального офиса и компьютерами пользователей защищается с использованием алгоритмов ГОСТ и протокола IPsec в туннельном режиме. Доступа со стороны компьютеров пользователей к сетям филиалов в данном сценарии не предусмотрено.

В сценарии предполагается, что вначале УЦ Certification_authority_NEW, филиал 2 и устройство Client2 отсутствуют и криптошлюз Hub1 настроен для взаимодействия с филиалом 1 и Client1 с использованием сертификатов, выпущенных УЦ Certification_authority_OLD по ГОСТ 2001.

После внедрения УЦ Certification_authority_NEW, филиала 2 и устройства Client2, использующих новые сертификаты (по ГОСТ 2012), криптошлюз Hub1 настраивается таким образом, чтобы стоить соединения с устройствами из обеих групп.

4.1.     Параметры протокола IKE для Client1 и Spoke1:

·         Аутентификация при помощи цифровых сертификатов, алгоритм подписи – ГОСТ Р 34.10-2001;

·         Алгоритм шифрования – ГОСТ 28147-89 (ключ 256 бит);

·         Алгоритм вычисления хеш-функции – ГОСТ Р 34.11-94;

·         Алгоритм выработки общего ключа (аналог алгоритма Диффи-Хеллмана) – VKO GOST R 34.10-2001.

4.2.     Параметры протокола IKE для Client2 и Spoke2:

·         Аутентификация при помощи цифровых сертификатов, алгоритм подписи – ГОСТ Р 34.10-2012 (ключ 256 бит);

·         Алгоритм шифрования – ГОСТ 28147-89 (ключ 256 бит);

·         Алгоритм вычисления хеш-функции – ГОСТ Р 34.11-2012 ТК26 (ключ 256 бит);

·         Алгоритм выработки общего ключа (аналог алгоритма Диффи-Хеллмана) – VKO_GOSTR3410_2012_256 (ключ 256 бит).

4.3.     Параметры протокола IKE для Hub1 после полной настройки должны содержать алгоритмы для взаимодействия как с Client1 и Spoke1, так и с Client2 и Spoke2.

4.4.     Параметры протокола ESP (общие):

·         Комбинированный алгоритм шифрования и имитозащиты (контроль целостности) – ESP_GOST-4M-IMIT (ключ 256 бит).