Руководство по настройке ПО на базе операционной системы Dionis NX C 1.2-10 Hand UTM (2015 год)

400

сохраняется в памяти LCD. И,наконец, третья команда определяет, что нужно каждый раз при

загрузке системы считывать КД с LCD, куда он ранее был сохранен (см.вторую команду).

После того, как КД был успешно проинициализироваван, можно импортировать ключ DISEC:

# crypto disec import key flash

Поддерживаемые внешние ключевые носители: flash, floppy, all (искать ключи как на flash,

так и на floppy). Если команда успешно выполнилась, будет выведена информация об импорти-

рованном ключе:

Info: key (serial:55; cn:1) successfully imported

В данном случае ключ серии 55 с локальным крипто-номером 1 был успешно импортирован

при инициализации DISEC.

Можно импортировать ключи, указав путь хранения ключей на конкретном устройстве, напри-

мер:

# crypto disec import key flash0.1:/path/to/keys

Также можно осуществить множественный импорт ключей, указав путь базовой директории

на устройстве, например:

# crypto disec import key flash0.1:/keys/*

Команда произведет импорт ключей (если они есть), находящихся в директориях, которые

находятся в директории /keys на устройстве flash0.1. Директории с именами km_k,db1,db2 при

этом будут пропущены.

43.2.2

Создание туннеля

Перед описанием процесса создания туннеля DISEC (далее туннеля) введем необходимые

понятия, и сопроводим их краткими описаниями:

1. имя туннеля: задает имя туннеля, нужно для идентификации туннеля и для большей на-

глядности;

2. параметры туннеля:

• IP-адреса концов туннеля;

• криптографические параметры туннеля;

3. правила отбора в туннель: задают правила для исходящего сетевого трафика, по которым

он попадает в туннель;

4. приоритет правил отбора:

• чем ниже численно приоритет правила,тем выше в списке правил стоит данное прави-

ло;

• правила просматриваются сверху вниз;

• при попадании исходящей датаграммы в правило, просмотр нижележащих правил дан-

ного туннеля прекращается: датаграмма попала в туннель;

401

5. приоритет туннеля:

• определяет приоритет набора правил туннеля;

• чем ниже численно приоритет туннеля,тем выше в списке туннелей стоит данной тун-

нель;

• наборы правил туннелей просматриваются сверху вних;

• при попадании исходящей датаграммы в одно из правил в наборе правил туннеля,

просмотр нижележащих туннелей прекращается.

Будем считать, что DISEC инициализирован с поддержкой криптографии. Для создания тун-

неля следует выполнить команды:

(config)# crypto disec conn t1

(config−disec−t1)# local ip 1.1.1.1

(config−disec−t1)# remote ip 2.2.2.2

(config−disec−t1)# id 1

(config−disec−t1)# serial 55

(config−disec−t1)# local cn 1

(config−disec−t1)# remote cn 2

(config−disec−t1)# alg both

Туннель добавится в конец списка уже имеющихся туннелей под очередным номером.

Если необходимо поместить туннель в список под другим номером, при создании туннеля

можно использовать следующую команду:

(config)# 1 crypto disec conn t2

Данная команда создаст туннель t2 под номером 1. Ранее созданный туннель t1 переместится

ниже под номером 2.

Рассмотрим по порядку параметры туннеля, которые необходимо указать при его создании:

• local ip: задает IP-адрес локального конца туннеля;

• remote ip: задает IP-адрес удаленного конца туннеля;

• id: целое число (до 5 цифр), идентифицирующее туннель; значение этого параметра долж-

но совпадать на обоих концах туннеля;

• serial: номер серии ключей - целое десятичное число, равное номеру серии ключей, исполь-

зуемой в данной криптографической сети;

• local cn: целое число (до 5 цифр), равное номеру данного узла в криптографической сети;

• remote cn: целое число (до 5 цифр), равное номеру в криптографической сети того узла, с

которым будет выполняться обмен информацией по данному туннелю;

• alg both: алгоритм трансформации данных в туннеле; возможные значения:

- compression: только сжатие данных;

- encryption: только зашифрование данных;

- both: и сжатие, и зашифрование данных;

- none: никакой трансформации данных не производится.

Чтобы удалить ненужный более туннель, следует использовать команду:

402

(config)# no crypto disec conn t1

Этой командой удаляется туннель t1.

Чтобы удалить все туннели, следует использовать команду:

(config)# no crypto disec conn *

43.2.3

Правила отбора туннеля

Правила отбора определяют,какой именно сетевой трафик будет попадать в туннель. Пра-

вила отбора туннеля просматриваются сверху вниз: самое приоритетное правило имеет номер

1, следующее правило имеет номер 2 и т.д. Как только для данной датаграммы будет найдено

соответствующее правило отбора, прнимается решение инкапсулировать датаграмму в туннель.

Важную роль в том, в какой именно туннель попадет датаграмма, играет приоритет туннеля. Чем

ниже номер туннеля,тем более приоритетен набор правил отбора данного туннеля по отношению

к наборам других туннелей. Рассмотрим пример:

1 tunnel1

1 rule1a

2 rule1b

2 tunnel2

1 rule2a

2 rule2b

3 rule2c

В данном примере условными обозначениями определено 2 туннеля tunnel1 и tunnel2, в каж-

дом из которых свой набор правил. При принятии решения, каким именно туннелем пересылать

исходящую датаграмму и нужно ли ее вообще пересылать каким-либо туннелем, правила отбора

анализируется в следующем порядке: rule1a, rule1b, rule2a,rule2b,rule2c.

При попадании в одно из первых двух правил датаграмма будет пересылаться через tunnel1,

при попадании в одно из следующих трех правил - через tunnel2, иначе - датаграмма не будет

пересылаться через эти DISEC-тунели.

Теперь перейдем непосредственно к созданию правил отбора.

Формат задания правила следующий: permit|deny [PROTO] src <SRCIP> dst <DSTIP>

[sport <S1> [S2]] [dport <D1> [D2]] [remark <REMARK>]

Рассмотрим аргументы команды задания правила:

• permit - разрешающее правило: трафик, попадающий в правило, будет обрабатываться

данным туннелем;

• deny - исключающее правило: трафик, попадающий в правило, не будет обрабатываться

данным туннелем;

• PROTO - протокол, например IP,TCP,UDP,ICMP и др. или номер протокола; по-умолчанию:

протокол IP;

• SRCIP - адрес сети или узла отправителя датаграммы;

• DSTIP - адрес сети или узла получателя датаграммы;

403

• S1,S2 - начальный и, возможно,конечный порт отправителя датаграммы; если указан S2,

то значения S1,S2 задают интервал портов; по-умолчанию: любой порт;

• D1,D2 - начальный и,возможно,конечный порт получателя датаграммы; если указан S2, то

значения S1,S2 задают интервал портов; по-умолчанию: любой порт;

• REMARK - необязательная пометка(любая строка без пробелов) правила.

Порты S1/S2,D1/D2 можно задать, только если PROTO указывает на tcp- или udp-протокол.

Примеры:

(crypto−disec−t1)# permit tcp src 1.1.1.0/24 dst 192.168.2.2/32 sport 20 80 dport 100 200

remark GOOD

(crypto−disec−t1)# deny src 2.2.0.0/16 dst 192.168.2.2/32 remark BETTER

(crypto−disec−t1)# 1 permit icmp src 2.2.0.0/16 dst 192.168.2.2/32 remark BEST

(crypto−disec−t1)# no 2

(crypto−disec−t1)# no all

Первые три команды задают правила отбора. Четвертая команда удаляет правило под номе-

ром 2, помеченное как GOOD. Пятая команда удаляет все правила.

43.2.4

Включение и выключение туннеля

Вышеописанные параметры и правила отбора в туннель не будут действовать,пока вы не

включите туннель:

(config−disec)# crypto disec enable conn t1

Когда туннель включен вы можете менять его параметры и правила отбора. Если эти парамет-

ры имеют смысл, они будут автоматически применены к данному туннелю.

Чтобы выключить туннель, следует использовать команду:

(config−disec)# crypto disec disable conn t1

Чтобы включить все туннели, следует использовать команду:

(config−disec)# crypto disec enable conn *

Чтобы выключить все туннели, следует использовать команду:

(config−disec)# crypto disec disable conn *

В случае,если какой-либо туннель А не сможет отключиться, будет предпринята попытка

включения успешно отключенных туннелей,если таковые были до момента сбоя в отключении

туннеля А. Таким образом, в случае успешности данной команды ВСЕ туннели будут отключены.

В случае неуспешности - ничего не изменится.

404

43.2.5

Копирование и перемещение туннеля

crypto disec copy <OLD> <NEW> [id <ID>] [PRF] [force] [rules]

Данная команда осуществляет копирование существующего туннеля в новый вместе со всеми

параметрами и,возможно, правилами отбора. Новый туннель в случае успешного копирования

будет находиться в состоянии выключен.

Параметры:

• OLD : старое имя туннеля;

• NEW : новое имя туннеля;

• ID : id, присваиваемый новому туннелю;

• PRF : приоритет, под которым следует создать новый туннель;

• force : если туннель NEW уже существует, он будет отключен и его параметры станут рав-

ными параметрам туннеля OLD, т.е. произойдет замена туннеля;

• rules : копировать также и правила туннеля.

crypto disec move <NAME> <PRF>

Данная команда осуществляет перемещение существующего туннеля NAME: туннелю присва-

ивается новый приоритет PRF. Состояние туннеля (включен/выключен) сохраняется.

43.2.6

Работа с ключами

В данном разделе описывается просмотр,удаление и добавление ключей и абонентов.

43.2.6.1

Просмотр ключей

Чтобы посмотреть установленные в систему крипто-ключи, следует использовать команду:

# show crypto disec keys

Пример вывода команды:

Installed keys:

Serial: 55 , locals: 1

Из вывода следует, что установлен один ключ с локальным криптономером 1 серии 55.

Чтобы посмотреть установленные в систему крипто-ключи определенной серии, следует ис-

пользовать команду:

# show crypto disec key 55

Пример вывода команды:

Installed keys for serial 55: 1

Из вывода следует, что установлен один ключ с локальным криптономером 1 для серии ключей

55.

405

43.2.6.2

Просмотр абонентов

Чтобы посмотреть доступность абонента с крипто-номером 2 для доступа по ключу с серией

55 и крипто-номером 1, следует выполнить команду:

# show crypto disec abonent 55 1 2

Если абонент доступен, выдача команды будет следующей:

Access to abonent 2 for key (sn=55;loc=1), check status: GRANTED

Если абонент не доступен, выдача команды будет следующей:

Access to abonent 2 for key (sn=55;loc=1), check status: DENIED

43.2.6.3

Добавление и удаление ключей

В инициализированную подсистему DISEC вы можете добавлять новые и удалять старые

крипто-ключи.

Чтобы добавить новый ключ, нужно вставить ВКН, например, флэшку, хранящую новый

крипто-ключ, и выполнить команду:

# crypto disec import key flash

Чтобы удалить установленный ключ, следует использовать команду:

# crypto disec remove key 55 1

Команда удалит ключ 1 серии 55.

Чтобы удалить все установленные ключи, следует использовать команду:

# crypto disec remove key all

43.2.6.4

Полное удаление DISEC

Полное удаление из системы всей информации, относящейся к DISEC, состоит в следующих

шагах:

• удаление туннелей командой no crypto disec conn <NAME> (режим configure);

• удаление ключей командой: crypto disec remove key <SERIAL> <LOCAL> (режим enable);

• окончательная очистка от DISEC: crypto disec cleanup (режим enable).

Примечание: Для безопасного удаления ключей с внешних носителей рекомендуется исполь-

зовать команду “clear removable” (см. раздел “Обслуживание”).

406

43.2.6.5

Плановая смена ключей

При плановой смене ключей (далее ПС) производится замена сетевых ключей одной из серий

на ключи новой серии, которая может либо уже иметься в системе, либо быть импортирована с

внешнего носителя.

ПС должна быть выполнена на всех узлах, входящих в криптографическую сеть с данной

серией ключей.

Рассмотрим процесс ПС на одном из концов туннеля на примере.

Предположим, что у нас имеются следующие входные данные:

• туннель Disec с именем: TUN;

• туннель TUN использует серию ключей с номером SER0;

• туннель TUN использует локальный криптономер LOC0;

• туннель TUN использует удаленный криптономер REM0;

• туннель TUN может быть включен или выключен.

Задача: для туннеля TUN осуществить ПС:

• заменить серию ключей SER0 на серию ключей SER1;

• криптономер LOC0 на LOC1;

• криптономер REM0 на REM1;

• новые криптономера LOC1 и/или REM1 могут остаться прежними, в этом случае LOC1=LOC0

и/или REM1=REM0.

В данном случае алгоритм смены ключей следующий:

1. В случае, если производится удаленная ПС, то необходимо войти в систему, на которой нуж-

но осуществить ПС, по защищенному туннелю. Например, если это туннель Disec, то нужно

иметь для этого туннеля специальную серию ключей, используемую только для процедуры

ПС.

2. В случае, если производится локальная ПС, то защищенный туннель для ПС не нужен -

администратор просто заходит в систему локально, используя свое имя пользователя и па-

роль.

3. После входа в систему (локально или удаленно), необходимо удостовериться в наличии

новой серии ключей SER1, выполнив следующую команду:

DionisNX# show crypto disec key SER1

Выдача команды покажет, какие локальные криптономера доступны для данной серии ключей.

Необходимо удостовериться, что новый локальный криптономер LOC1 туннеля TUN перечислен в

выдаче данной команды.

Если LOC1 не найден в выдаче команды, значит ПС не будет выполнена успешно.

407

4. Далее необходимо проверить, возможен ли доступ по данной серии ключей к нужному уда-

ленному абоненту REM1, выполнив следующую команду:

DionisNX# show crypto disec abonent SER1 LOC1 REM1

Если удаленный абонент является доступным по данной серии ключей, то выдача данной

команды будет следующей:

Access to abonent REM1 for key (sn=SER1;loc=LOC1): GRANTED.

Если удаленный абонент является недоступным по данной серии ключей, то выдача данной

команды будет следующей:

Access to abonent REM1 for key (sn=SER1;loc=LOC1): DENIED.

Если удаленный абонент недоступен (команда выдала DENIED), значит ПС не будет выполне-

на успешно.

5. Затем следует войти в настройки туннеля TUN и выполнить следующие команды:

DionisNX# configure

DionisNX(config)# crypto disec conn TUN

DionisNX(config−disec−TUN)# serial SER1

Если криптономер LOC1 не равен LOC0, то дополнительно необходимо будет выполнить сле-

дующую команду:

DionisNX(config−disec−TUN)# local cn LOC1

Если криптономер REM1 не равен REM0, то дополнительно необходимо будет выполнить сле-

дующую команду:

DionisNX(config−disec−TUN)# remote cn REM1

6. На этом плановая смена ключей завершена. Пункты 3 и 4 алгоритма не обязательны и

нужны исключительно для проверки того, что туннель будет корректно работать на новой

серии ключей.

После проверки связи со всеми удаленными узлами криптографической сети, необходимо

удалить старую серию ключей следующей командой:

DionisNX# crypto disec remove key SER0 LOC

Эту команду следует повторить для каждого локального криптономера в серии SER0 до пол-

ного удаления старой серии ключей SER0 из системы.

43.2.6.6

Действия при неплановой смене ключа доступа

Если ключ доступа после импорта ключей был изменен способом, отличным от «Плановой

замены КД», то для корректной работы туннелей необходимо:

• удалить установленные ключи;

• выполнить crypto disec cleanup;

• вновь осуществить импорт нужных ключей.

408

43.2.6.7

Удаление абонентов

Чтобы заблокировать возможность криптографической связи с абонентом, определяемым уда-

ленным крипто-номером, следует удалить его из локального ключа:

# crypto disec remove abonent 55 1 10

Команда навсегда блокирует абонента 10 для ключа 1 серии 55. Чтобы разблокировать або-

нента, необходимо удалить и снова добавить ключ 1 серии 55 с ВКН.

43.2.7

Работа с туннелями

43.2.7.1

Просмотр туннелей

Чтобы посмотреть таблицу имеющихся туннелей, следует использовать команду:

# show crypto disec conns

Пример выдачи команды:

[#]NAME

ID SRC

DST

LOC REM A B

192.168.2.1

192.168.2.2

−

− N N

#t2

192.168.4.1

192.168.4.2

E N

Рассмотрим столбцы таблицы:

• [#]NAME - имя туннеля; если перед именем стоит знак #, значит туннель выключен;

• ID - идентификатор туннеля;

• SRC - адрес локального конца туннеля;

• DST - адрес удаленного конца туннеля;

• SN - номер серии ключей;

• LOC - локальный крипто-номер туннеля;

• REM - удаленный крипто-номер туннеля;

• A - тип трансформации данных в туннеле: E - шифрование, C - компрессия, B - шифрование

и компрессия, N - нет трансформации;

• B - туннель заблокирован: Y - да, N - нет.

Чтобы посмотреть информацию по конкретному туннелю, следует использовать команду:

# show crypto disec conn t1

В дополнение к информации, которая была рассмотрена для предыдущей команды, будут

выведены правила данного туннеля, например:

[#]NAME

ID SRC

DST

LOC REM A B

id1

192.168.0.5

192.168.0.4

E N

1 permit src 0.0.0.0/0 dst 192.168.32.0/24

2 permit src 0.0.0.0/0 dst 192.168.16.0/24

3 permit src 0.0.0.0/0 dst 192.168.3.0/24

409

43.2.7.2

Просмотр правил отбора

Чтобы посмотреть информацию по конкретному туннелю, следует использовать команду:

# show crypto disec rules id1

Пример выдачи команды:

1 permit src 0.0.0.0/0 dst 192.168.32.0/24

2 permit src 0.0.0.0/0 dst 192.168.16.0/24

3 permit src 0.0.0.0/0 dst 192.168.3.0/24

43.2.7.3

Блокирование туннеля

Иногда бывает необходимо полностью заблокировать трафик через включенный туннель. Это

делается следующей командой:

(config−disec−t1)# block

Чтоб разблокировать трафик через туннель, следует использовать команду:

(config−disec−t1)# no block

43.2.8

Прочая работа с DISEC

43.2.8.1

Инкапсуляция DISEC в UDP

Для инкапсуляции датаграмм DISEC в UDP-датаграммы в дополнение к основным параметрам

туннеля следует использовать следующую команду:

(config−disec−t1)# encap sport 500 dport 600

Параметры sport и dport - номер UDP-порта отправителя и получателя, соответственно, они

не обязательны. По умолчанию равны 500.

43.2.8.2

Блокирование DISEC трафика

Чтоб полностью заблокировать трафик через все включенные туннели, следует использовать

команду:

(config−disec)# crypto disec noipcrypto

Чтоб разблокировать трафик через все включенные туннели, следует использовать команду:

(config−disec)# no crypto disec noipcrypto

Трафик будет разблокирован только для тех туннелей, которые не заблокированны индиви-

дуально командой block.

410

43.2.8.3

Просмотр состояния

Чтобы посмотреть версию подсистемы DISEC, следует использовать команду:

# show crypto disec version

Чтобы посмотреть статистику обработки пакетов через подсистему DISEC, следует использо-

вать команду:

# show crypto disec statistic

Рассмотрим пример выдачи данной команды:

TUNNEL

XP_OUT XP_IN XP_FWD XS_OUT

XS_IN

tun1

17:49:20 17:49:20 17:49:20 1235557106676

108258340540

tun2

17:49:20 17:49:20 17:49:20 1302550192329

609146127844

Рассмотрим столбцы данной таблицы:

• TUNNEL : имя туннеля;

• XP_OUT : последнее время попадания исходящей датаграммы в туннель;

• XP_FWD : последнее время попадания в туннель входящей датаграммы, не предназначен-

ной для текущей системы;

• XP_IN : последнее время попадания в туннель входящей датаграммы, предназначенной для

текущей системы;

• XS_OUT : число байт исходящего трафика, прошедшего через туннель;

• XS_IN : число байт входящего трафика, прошедшего через туннель.

43.2.8.4

Режим отладки

При возникновении проблем в работе каких-либо команд подсистемы DISEC можно включить

режим отладочных сообщений:

(config−disec)# crypto disec debug

Более глубокий режим отладки можно включить при помощи команды:

(config−disec)# crypto disec debug trace

43.3

PSK (совместно используемые ключи)

Совместно используемые ключи (Pre-shared Keys, PSK) представляют из себя конфиденци-

альную последовательность байт (от 8 до 256) и используются для взаимной аутентификации

оппонентов IPsec. Для успешной аутентификации pre-shared ключи должны совпадать (по длине

и содержимому) у обоих оппонентов. Ключи PSK сохраняются в системе с уникальными имена-

ми. Контейнеры сохранённых ключей PSK защищаются шифрованием с помощью ключа доступа

(КД).

411

43.3.1

Ввод/импорт PSK

Pre-shared ключи можно загрузить с внешнего носителя или ввести вручную.

Рекомендуемый способ ввода pre-shared ключа в систему - это импорт ключа из контейнера

DSRF. Контейнер DSRF содержит набор 32-байтных симметричных ключей, идентифицирующихся

по номеру абонента.

Чтобы просмотреть информацию о DSRF-контейнере на внешнем носителе, необходимо ввести

команду в enable-режиме:

# show crypto psk keys <носитель>

Если контейнер существует на внешнем носителе (в корневой директории), то будет отобра-

жена следующая информация:

• Номер зоны (Zone);

• Номер серии ключей (Serial);

• Номер абонента, для которого выпущен данный DSRF-контейнер (Abonent);

• Количество ключей в контейнере (Number of abonents).

Далее можно импортировать нужный ключ из контейнера с помощью команды:

# crypto psk set key <имя_ключа_в_системе> <носитель> @<номер_абонента>

Номер абонента задаётся в десятичном виде и может быть от 1 до «Number of abonents» вклю-

чительно. Перед номером обязательно нужно указать символ «@».

Пример:

# show crypto psk keys flash

DSRF key container on ’/dev/sdb1’ device:

Zone: 1

Serial: 1234

Abonent: 1

Number of abonents: 9999

# crypto psk set key dsrf_key @9000

Info: Found possible DSRF container on ’/dev/sdb1’ device.

Info: Read 32 bytes of pre−shared key.

Info: Saving the key with internal name ’dsrf_key’.

# show crypto psk keys

dsrf_key

В данном примере в качестве pre-shared ключа загружается ключ номер 9000 из DSRF-

контейнера с внешнего флеш-носителя и сохраняется в системе с внутренним именем ‘dsrf_key’.

Список ключей, загруженных в систему, можно просмотреть с помощью команды ‘show crypto psk

keys’ (без параметра <носитель>).

Также ключ можно загрузить из произвольного файла на внешнем носителе (не рекомендует-

ся). Это можно сделать с помощью команды:

412

# crypto psk set key <имя_ключа_в_системе> <носитель> <путь_к_файлу>

Всё содержимое файла воспринимаются как ключ. Файл должен иметь длину от

8 до

256

байт.

Пример:

# ls flash0:

total 12

drwxrwxr−x 2 adm adm 4.0K Jul 11 17:42

psks/

drwxrwxr−x 2 adm adm 4.0K Jul 11 17:42

keys/

drwxrwxr−x 2 adm adm 4.0K Jul 11 17:42

certs/

# ls flash0:/psks

total 8

−rwxrwxr−x 1 adm adm

32 Jul 11 17:42

key1

−rwxrwxr−x 1 adm adm

256 Jul 11 17:42

key2

# crypto psk set key psk1 flash /psks/key1

Info: Read 32 bytes of pre−shared key.

Info: Saving the key with internal name ’psk1’.

# crypto psk set key psk2 flash /psks/key2

Info: Read 256 bytes of pre−shared key.

Info: Saving the key with internal name ’psk2’.

# show crypto psk keys

dsrf_key

psk1

psk2

В данном примере в качестве pre-shared ключей загружаются файлы ‘key1’ и ‘key2’ с внешнего

флеш-носителя и сохраняются в системе с внутренними именами ‘psk1’ и ‘psk2’ соответственно.

Если необходимо ввести ключ вручную, то рекомендуется это делать с помощью команды:

# crypto psk set key <имя_ключа> pass

При этом будет предложено ввести ключ в текстовом виде два раза (как пароль). Содержи-

мое ключа при вводе отображаться не будет. В качестве ключа сохраняется введённый текст (в

кодировке UTF-8) без заключительного символа перевода строки.

Также можно ввести ключ в открытом текстовом или 16-ричном виде, но эти варианты ввода

не рекомендуются как небезопасные. После ввода ключей таким способом необходимо удалить

журнал командной оболочки.

Пример:

# crypto psk set key psk3 text ”123”

# crypto psk set key psk4 hex 0x313233

# rm log:/dish.log

# show crypto psk keys

dsrf_key

psk1

413

psk2

psk3

psk4

43.3.2

Ассоциация ключей с туннелями IPsec

Чтобы ключ мог быть использован для взаимной аутентификации оппонентов IPsec, его необ-

ходимо ассоциировать с IP-адресами концов IPsec-туннеля. Это можно сделать с помощью следу-

ющей команды режима configure:

(config)# crypto psk map <локальный_IP> <удалённый_IP> <имя_ключа>

Примеры:

(config)# crypto psk map 10.1.0.1 10.2.0.1 psk1

(config)# crypto psk map 192.168.0.1 * psk2

(config)# crypto psk map * 10.3.0.1 psk3

Звёздочка означает любой IP. Не допускается использование сочетания «* *».

43.3.3

Удаление ключей и ассоциаций

Чтобы удалить pre-shared ключ, нужно выполнить следующую команду режима enable:

# crypto psk clear key <имя_ключа>

Удалить все pre-shared ключи можно следующей командой:

# crypto psk clear keys

Удалить ассоциацию PSK с IPsec можно командой режима configure:

(config)# no crypto psk map <локальный_IP> <удалённый_IP>

Чтобы удалить все ассоциации, нужно выполнить следующую команду в режиме configure:

(config)# no crypto psk maps

Для безопасного удаления ключей с внешних носителей рекомендуется использовать команду

“clear removable” (см. раздел “Обслуживание”).

43.4

PKI (закрытые ключи, сертификаты, СОС)

43.4.1

Базовые понятия PKI

PKI - Public Key Infrastructure, Инфраструктура открытых ключей - технология аутентифи-

кации с помощью открытых ключей, связывающая открытые ключи с личностью пользователя

посредством удостоверяющего центра (УЦ).

414

Закрытый ключ - конфиденциальный компонент пары асимметричных ключей, используемый

для создания электронно-цифровой подписи (ЭЦП).

Открытый ключ - неконфиденциальный компонент пары асимметричных ключей, используе-

мый для проверки электронно-цифровой подписи.

Имя

X500

(DN,

Distinguished

Name)

последовательность

типа

«имя_параметра1=значение_параметра1, имя_параметра2=значение_параметра2,

…», кото-

рая однозначно определяет конкретный субъект (человек, организация, маршрутизатор и т.д.).

«Имя_параметра» определяется конкретным объектным идентификатором OID, который также

определяет синтаксис «значения_параметра».

Удостоверяющий центр (УЦ) - организация, пользующаяся доверием и выпускающая X509-

сертификаты.

Сертификат X509 - зафиксированная (неизменяемая) последовательность бинарных данных,

которая содержит следующую информацию:

• Серийный номер сертификата;

• X500-имя удостоверяющего центра, выпустившего сертификат;

• Дата начала и конца действия сертификата;

• X500-имя субъекта, кому выдан сертификат;

• Открытый ключ субъекта;

• Дополнительная информация (область применения сертификата, точки распространения

списков отзывов сертификата и т.д.);

• Электронно-цифровая подпись по вышеуказанным данным, сформированная закрытым

ключом удостоверяющего центра, выпустившего данный сертификат.

Сертификат является неконфиденциальной информацией. Целостность сертификата можно

проверить с помощью открытого ключа из сертификата удостоверяющего центра. Сертификат

удостоверяющего центра может быть выпущен вышестоящим удостоверяющим центром. В ре-

зультате для проверки сертификата необходима вся цепочка сертификатов УЦ до корневого.

Корневой (самоподписанный) сертификат - сертификат самого главного удостоверяющего

центра, который пользуется абсолютным доверием. Корневой сертификат подписан закрытым

ключом этого же УЦ и может быть проверен собственным открытым ключом. Также X500-имя

издателя эквивалентно x500-имени субъекта. Корневой сертификат должен доставляться и уста-

навливаться в систему доверенным способом.

Если закрытый ключ субъекта скомпрометирован до окончания срока действия соответствую-

щего сертификата, то удостоверяющему центру необходимо выпустить (и распространить) список

отозванных сертификатов, содержащий серийный номер скомпрометированного сертификата.

Список отозванных сертификатов (СОС, Certificate Revocation List, CRL) - зафиксированная

бинарная последовательность, содержащая следующую информацию:

• X500-имя удостоверяющего центра, выпустившего данный список;

• Дата выпуска;

• Предельная дата выпуска следующего СОС;

• Список отозванных сертификатов (серийный номер, время отзыва, причина отзыва и т.д.);

• Дополнительная информация;

415

• Электронно-цифровая подпись по выше указанным данным, сформированная закрытым

ключом удостоверяющего центра, выпустившего данный СОС.

OCSP - (Online Certificate Status Protocol) - протокол немедленного выяснения действитель-

ности сертификата. Данный протокол позволяет отзывать сертификаты более оперативно, чем

СОС. Протокол работает по механизму «запрос-ответ» от клиента к УЦ (или уполномоченному

OCSP-серверу). Запрос содержит идентификатор сертификата, статус которого требуется выяс-

нить. Ответ содержит информацию о статусе сертификата (действительный/отозванный/неизвест-

ный). Запрос может быть подписан ключом клиента. Ответ всегда подписан ключом УЦ или упол-

номоченным OCSP-сервером.

43.4.2

Полная очистка PKI

Если необходимо удалить все закрытые ключи, сертификаты и СОС из системы, следует вы-

полнить команду привилегированного режима:

# crypto pki clear all

43.4.3

Управление закрытыми ключами

Закрытые ключи устанавливаются в систему с внешних носителей.

ВАЖНО: Установка закрытого ключа является доверенной процедурой, и должны быть обес-

печены все необходимые административные меры безопасности при доставке и установке ключа,

с целью избежания его компрометации или подмены. После установки в систему закрытый ключ

защищается ключом доступа.

Поддерживаются закрытые ключи для алгоритмов: ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2012

(256 и 512 бит).

Поддерживаются форматы контейнеров закрытых ключей Фактор-ТС и PKCS#15.

43.4.3.1

Импорт ключей

Если на внешнем носителе находится один закрытый ключ (в корневой директории), то для

установки его в систему достаточно выполнить команду привилегированного режима:

# crypto pki import key

Найденный ключ сохранится в системе с тем же именем файла, который имеет контейнер на

внешнем носителе. Если в системе уже существует ключ с таким именем, то будет выдано пред-

варительное уведомление (о перезаписывании). Если необходимо дать импортируемому ключу

другое системное имя, то следует выполнить команду с параметром «to»:

# crypto pki import key to <новое_имя>

Если на внешнем носителе находится несколько ключей (или они находятся в поддиректори-

ях), то для просмотра имён контейнеров следует использовать команду:

416

# show crypto pki keys flash|floppy [<путь_к_директории>]

Далее следует импортировать ключ с указанием пути к контейнеру. Общий формат import-

команды:

# crypto pki import key [flash|floppy] [from <путь_к_контейнеру>] [to <новое_имя>]

Пример:

Вставляем внешний флэш-носитель и выполняем команду просмотра:

# show crypto pki keys flash

certs/

crls/

keys/

pkcs15/

Видно, что на внешнем носителе в корневой директории контейнеров с ключами не содержит-

ся. Поэтому следует вывести содержимое поддиректории keys.

# show crypto pki keys flash keys

key1.nam oldfactor

key2.nam oldfactor

Видно, что в данной директории находятся два ключа в формате Фактор-ТС. Принимается

решение импортировать ключ key1.nam с внутреннем именем old_key1. Для этого следует выпол-

нить команду:

# crypto pki import key from keys/key1.nam to old_key1

Поскольку предполагается, что в поддиректории pkcs15 тоже могут содержаться контейнеры

с ключами, её следует также просмотреть:

# show crypto pki keys flash pkcs15

cred1.p15/

cred2.p15/

В выводе команды видны две «поддиректории». На самом деле, этими «поддиректориями»

могут оказаться PKCS#15-контейнеры, которые отображаются как поддиректории, потому что

они могут содержать в себе несколько ключей. Контейнеры PKCS#15 можно просматривать так

же, как поддиректории:

# show crypto pki keys flash pkcs15/cred1.p15

@00000001

pkcs15

mykey

pkcs15

CN=Иванов Иван Иванович, O=Хорошая организация, C=RU

Действительно, «поддиректория» cred1.p15 оказалась файлом контейнера PKCS#15, который

содержит два закрытых ключа. В контейнерах PKCS#15 с закрытым ключом могут быть ассоцииро-

ваны текстовая метка и X500-имя субъекта, которому этот ключ принадлежит. В данном примере

ключ mykey имеет эти атрибуты. Если же такие атрибуты у ключа отсутствуют, то он отобража-

ется по своему внутреннему числовому идентификатору (в данном примере - ключ @00000001),

и о владельце данного ключа можно только догадываться.

Принимается решение импортировать оба ключа (с внутренними именами unknown_key1 и

ivan_key соответственно):

417

# crypto pki import key from pkcs15/cred1.p15/@00000001 to unknown_key1

# crypto pki import key from pkcs15/cred1.p15/mykey to ivan_key

Если контейнер PKCS#15 защищён паролем, то потребуется его ввести.

43.4.3.2

Просмотр импортированных ключей

Чтобы вывести список ключей, импортированных в систему, нужно выполнить следующую

команду в привилегированном режиме:

# show crypto pki keys

В примере, описанном выше, данная команда выведет следующую информацию:

ivan_key

old_key1

unknown_key1

43.4.3.3

Удаление ключей из системы

Чтобы удалить закрытый ключ из системы, нужно выполнить следующую команду в привиле-

гированном режиме:

# crypto pki clear key <имя_ключа>

Чтобы удалить все закрытые ключи, нужно выполнить следующую команду:

# crypto pki clear keys

Для безопасного удаления ключей с внешних носителей рекомендуется использовать команду

“clear removable” (см. раздел “Обслуживание”).

43.4.4

Управление сертификатами

различаются следующие виды сертификатов:

• Корневые сертификаты (главных УЦ);

• Сертификаты подчинённых УЦ;

• Клиентские сертификаты;

• Сертификаты для подписи/проверки OCSP запросов/ответов.

Сертификаты импортируются в систему вручную с внешних носителей, за исключением чу-

жих клиентских сертификатов, получаемых автоматически службой IPsec IKE (см. Туннели IPsec

ниже). Автоматически полученные сертификаты не сохраняются в локальном хранилище.

Поддерживаемые алгоритмы ЭЦП:

• ГОСТ Р 34.10-2001 с ГОСТ Р 34.11-94;

418

• ГОСТ Р 34.10-2012 (256 бит) с ГОСТ Р 34.11-2012 (256 бит);

• ГОСТ Р 34.10-2012 (512 бит) с ГОСТ Р 34.11-2012 (512 бит).

Поддерживаемые форматы для импорта: DER, PEM, PKCS#15, P7B.

Каждому типу сертификата соответствует отдельное локальное хранилище. Сертификаты

идентифицируются по локальным именам, которые им присваиваются при импорте. Имена серти-

фикатов разных типов могут пересекаться. (Однако рекомендуется избегать пересечения имён

между сертификатами корневых и подчинённых УЦ, если необходимо настраивать дополнитель-

ные точки распространения СОС-командами «crypto ike cainfo» - см. Туннели IPsec ниже).

ВАЖНО: Импорт корневого сертификата является доверенной процедурой, и поэтому долж-

ны быть соблюдены все необходимые административные меры по безопасной доставке носителя

с корневым сертификатом. Импортированный корневой сертификат защищается от подмены ими-

товставкой, рассчитанной с помощью ключа доступа.

Для клиентских сертификатов, относящихся к данному узлу, должны быть импортированы

соответствующие закрытые ключи (см. выше). Совпадение внутренних системных имён ключей

и соответствующих сертификатов необязательно.

Для проверки ЭЦП OCSP-ответов используются сертификаты удостоверяющих центров. Ес-

ли OCSP-ответы формируются уполномоченным OCSP-сервером, то для проверки OCSP-ответа

будет использоваться сертификат OCSP-сервера. Данный сертификат должен содержать OID

1.3.6.1.5.5.7.3.9 («ocspSigning») в поле «Extended Key Usage». Данный сертификат обычно пе-

редаётся в теле OCSP-ответа. Если он не передаётся, то его следует импортировать в хранилище

OCSP-сертификатов.

Если необходимо подписывать OCSP-запросы, то следует импортировать необходимые сер-

тификаты в хранилище OCSP-сертификатов, а также соответствующие им закрытые ключи. Ес-

ли OCSP-запрос должен подписываться клиентским сертификатом, то последний можно скопи-

ровать в хранилище OCSP-сертификатов командой «crypto pki copy cert» (см. ниже). Подпись

OCSP-запроса формируется следующим образом:

1. Допустим, требуется проверка на отзыв некоторого сертификата A;

2. Ищется сертификат удостоверяющего центра, выпустившего сертификат A - сертификат B;

3. Если сертификат B не найден, то сертификат A считается заведомо недействительным;

4. В хранилище OCSP-сертификатов ищется сертификат, подписанный сертификатом B (выпу-

щенный тем же УЦ) - сертификат С;

5. Если сертификат C не найден, OCSP-запрос не будет подписан;

6. Ищется закрытый ключ, соответствующий сертификату C;

7. Если ключ не найден, OCSP-запрос не будет подписан;

8. OCSP-запрос подписывается найденным ключом.

43.4.4.1

Импорт сертификатов

Команды просмотра и импорта сертификатов имеют синтаксис, похожий на команды просмот-

ра и импорта ключей.

Чтобы просмотреть сертификаты на внешнем носителе, нужно выполнить команду (в приви-

легированном режиме):

419

# show crypto pki certs flash|floppy [<путь>]

Пример вывода команды:

subdir1/

subdir2/

file1

root CN=Главный удостоверяющий центр, O=Хорошая организация, C=RU

file2

CN=УЦ первого отдела, O=Хорошая организация, C=RU

file3

user CN=Иван Иванович Иванов, O=Хорошая организация, C=RU

Список сертификатов выводится в формате: имя файла, тип, X500-имя субъекта.

Следующие команды выполняют импорт соответственно корневых, промежуточных, клиент-

ских и OCSP-сертификатов:

# crypto pki import root ca cert [<внешний_носитель>] [from <путь_к_файлу>] [to

<новое_имя>]

# crypto pki import ca cert [<внешний_носитель>] [from <путь_к_файлу>] [to <новое_имя>]

# crypto pki import cert [<внешний_носитель>] [from <путь_к_файлу>] [to <новое_имя>]

# crypto pki import ocsp cert [<внешний_носитель>] [from <путь_к_файлу>] [to <новое_имя>]

Чтобы скопировать клиентский сертификат в хранилище OCSP-сертификатов, следует исполь-

зовать команду:

# crypto pki copy cert <имя_клиентского_сертификата> to ocsp cert [<новое_имя>]

Пример:

Вставляем внешний флэш-носитель и выполняем команду просмотра контейнеров сертифика-

тов:

# show crypto pki keys flash

certs/

crls/

keys/

pkcs15/

Просмотрим директорию «certs»:

# show crypto pki certs flash certs

ca.cer

root CN=УЦ, O=Правильная организация, С=RU

ocsp.cer user CN=OCSP сервер, O=Правильная организация, С=RU

В данной директории мы видим корневой сертификат “дружественной нам” организации. Мы

принимаем решение его установить в систему, так как доверяем данной организации и сертифи-

катам, выпущенным её УЦ:

# crypto pki import root ca cert from certs/ca.cer to right_org_ca_cert

Также мы видим сертификат доверенного OCSP-сервера, который будет использоваться для

проверки OCSP-ответов от этого сервера. Мы его тоже устанавливаем:

# crypto pki import ocsp cert from certs/ocsp.cer to right_org_ocsp_cert

Мы знаем что директория «pkcs15» содержит контейнеры PKCS#15 с ключами и необходимы-

ми цепочками сертификатов. Просматриваем эти контейнеры:

420

# show crypto pki certs flash pkcs15

cred1.p15/

cred2.p15/

# show crypto pki certs flash pkcs15/cred1.p15

@00000001

user CN=Петров Пётр Петрович, O=Хорошая организация, C=RU

@00000002

root CN=Главный УЦ, O=Хорошая организация, C=RU

@00000003

ca CN=УЦ первого филиала, O=Хорошая организация, C=RU

mycert

user CN=Иванов Иван Иванович, O=Хорошая организация, C=RU

Мы видим сертификаты удостоверяющих центров нашей организации, а также сертификат

Иванова Ивана Ивановича, чей ключ мы уже импортировали. Сертификатам УЦ не присвоена

текстовая метка в PKCS#15 контейнере, поэтому мы видим их идентификаторы.

Также мы видим сертификат Петрова Петра Петровича, который имеет внутренний идентифи-

катор 0x00000001. В формате PKCS#15 есть требование о том, что если в контейнере хранится

закрытый ключ и соответствующий ему сертификат, то их идентификаторы должны совпадать. Мы

вспоминаем, что мы импортировали некий неизвестный нам ключ с идентификатором 0x00000001

(в примере с закрытыми ключами - см. выше) и присвоили ему внутреннее имя «unknown_key1».

Теперь мы видим, что этот ключ принадлежит Петрову Петру Петровичу. Мы понимаем, что его

ключ и сертификат нам не нужны, и принимаем решение удалить этот ключ:

# crypto pki clear key unknown_key1

Мы импортируем сертификаты наших удостоверяющих центров и сертификат Иванова Ивана

Ивановича:

# crypto pki import root ca cert from pkcs15/cred1.p15/@00000002 to our_main_ca_cert

# crypto pki import ca cert from pkcs15/cred1.p15/@00000003 to our_local_ca_cert

# crypto pki import cert from pkcs15/cred1.p15/mycert to ivan_cert

Мы знаем, что наш локальный удостоверяющий центр также является OCSP-сервером (ответы

от него будут проверяться сертификатом «our_local_ca_cert»), но также мы знаем, что наш OCSP-

сервер разрешает только подписанные запросы к нему. Мы копируем сертификат Иванова Ивана

Ивановича в хранилище сертификатов для OCSP, чтобы запрос OCSP подписывался его закрытым

ключом (импортированном в предыдущем примере):

# crypto pki copy cert ivan_cert to ocsp cert

Контейнеры P7B, как и контейнеры PKCS#15, отображаются как «директории», и могут со-

держать сертификаты и СОС. Пример:

# show crypto pki certs flash

cacer.p7b/

Файл «cacer.p7b» отображается как директория, потому что он содержит хотя бы один серти-

фикат. Просматриваем сертификаты в контейнере:

# show crypto pki certs flash cacer.p7b

cert01

root CN=Главный УЦ, O=Хорошая организация, C=RU

cert02

ca CN=УЦ первого филиала, O=Хорошая организация, C=RU

Внутри контейнера P7B сертификаты идентифициируются по порядковым номерам. Импорти-

руем сертификаты:

421

# crypto pki import root ca cert from cacer.p7b/cert01 to our_main_ca_cert

# crypto pki import ca cert from cacer.p7b/cert02 to our_local_ca_cert

43.4.4.2

Просмотр импортированных сертификатов

Следующие команды выводят списки сертификатов, находящихся в локальных хранилищах

(соответственно, корневые сертификаты, сертификаты подчинённых УЦ, клиентские сертифика-

ты, сертификаты для OCSP):

# show crypto pki root ca certs

# show crypto pki ca certs

# show crypto pki certs

# show crypto pki ocsp certs

Вывод осуществляется в формате:

<внутреннее_имя>

<X500-имя субъекта>

Пример:

Просмотрим наши хранилища сертификатов после выполнения команд предыдущего примера:

# show crypto pki root ca certs

right_org_ca_cert CN=УЦ, O=Правильная организация, С=RU

our_main_ca_cert CN=Главный УЦ, O=Хорошая организация, C=RU

# show crypto pki ca certs

our_local_ca_cert CN=УЦ первого филиала, O=Хорошая организация, C=RU

# show crypto pki certs

ivan_cert

CN=Иванов Иван Иванович, O=Хорошая организация, C=RU

# show crypto pki ocsp certs

ivan_cert

CN=Иванов Иван Иванович, O=Хорошая организация, C=RU

right_org_ocsp_cert CN=OCSP сервер, O=Правильная организация, С=RU

Также можно посмотреть подробную информацию о конкретном сертификате с помощью ко-

манд:

# show crypto pki root ca cert <имя>

# show crypto pki ca cert <имя>

# show crypto pki cert <имя>

# show crypto pki ocsp cert <имя>

Просмотреть отпечатки (fingerprints) открытых ключей сертификатов можно с помощью ко-

манд:

# show crypto pki root ca cert <имя> keyids

# show crypto pki ca cert <имя> keyids

# show crypto pki cert <имя> keyids

# show crypto pki ocsp cert <имя> keyids

422

43.4.4.3

Удаление сертификатов из системы

Удалить сертификат из системы можно с помощью одной из команд (для соответствующего

хранилища):

# crypto pki clear root ca cert <имя>

# crypto pki clear ca cert <имя>

# crypto pki clear cert <имя>

# crypto pki clear ocsp cert <имя>

Чтобы удалить все сертификаты из соответствующего хранилища, следует выполнить одну из

команд:

# crypto pki clear root ca certs

# crypto pki clear ca certs

# crypto pki clear certs

# crypto pki clear ocsp certs

43.4.5

Управление списками отозванных сертификатов

Обычно списки отозванных сертификатов могут быть получены динамически по сети (напри-

мер, службой IPsec IKE - см. ниже). Они хранятся в оперативной памяти и динамически обновляют-

ся. Но бывают ситуации, когда надо их установить вручную с внешнего носителя. Также службы

могут кэшировать СОС в данном хранилище, чтобы они были доступны сразу после перезагрузки

системы (см. опции «crl cache» и «crl policy strict» службы IPsec IKE).

Поддерживаются форматы: DER, PEM, PKCS#15, P7B.

43.4.5.1

Импорт СОС

Импорт списков отозванных сертификатов похож на импорт закрытых ключей. (Если контей-

нер PKCS#15 защищён паролем, то ввод пароля не потребуется, потому что СОС не является

конфиденциальной информацией).

Для просмотра СОС на внешних носителях и импорта следует использовать команды приви-

легированного режима:

# show crypto pki crls flash|floppy [<путь_к_директории>]

# crypto pki import crl [flash|floppy] [from <путь_к_файлу>] [to <новое_имя>]

Контейнеры P7B помимо самих сертификатов могут содержать списки отзыва сертификатов.

Если контейнер содержит хотя бы один СОС, то следующая команда отобразит его как «директо-

рию»:

# show crypto pki crls flash

cacer.p7b/

Пытаемся импортировать СОС из P7B:

# crypto pki import crl from cacer.p7b

Error: Multiple CRLs found on flash device. Use ’from’ option to specify a CRL.

423

Мы видим, что наш контейнер содержит более одного СОС. в таком случае следует просмот-

реть содержимое контейнера:

# show crypto pki crls flash cacer.p7b

crl01

CN=Главный УЦ, O=Хорошая организация, C=RU

crl02

CN=УЦ первого филиала, O=Хорошая организация, C=RU

Мы видим, что контейнер содержит списки отзывов, выпущенные главным УЦ и УЦ первого

филиала. Импортируем оба списка:

# crypto pki import crl from cacer.p7b/crl01 to our_main_ca_crl

# crypto pki import crl from cacer.p7b/crl02 to our_local_ca_crl

43.4.5.2

Просмотр СОС

Чтобы вывести список СОС, находящихся в локальном хранилище, следует использовать ко-

манду:

# show crypto pki crls

В выводе команды будут также показаны имена издателей соответствующих СОС. Пример:

our_main_ca_crl CN=Главный УЦ, O=Хорошая организация, C=RU

our_local_ca_crl CN=УЦ первого филиала, O=Хорошая организация, C=RU

Получить детальную информацию о СОС можно с помощью команды:

# show crypto pki crl <имя>

43.4.5.3

Удаление СОС из системы

Удалить конкретный СОС из системы можно с помощью команды:

# crypto pki clear crl <имя>

Удалить все СОС можно с помощью команды:

# crypto pki clear crls

43.5

Туннели IPsec

IPsec представляет собой набор протоколов для обеспечения защиты данных, передавае-

мых по межсетевому протоколу IP, посредством шифрования и подтверждения подлинности IP-

пакетов. Также средствами IPsec обеспечивается взаимная двусторонняя аутентификация сторон,

устанавливающих между собой крипто-туннель.

IPsec состоит из двух протоколов:

• IKE (Internet Key Exchange) - протокол взаимной аутентификации сторон и выработки клю-

чевого материала для протокола ESP;

424

• ESP (Encapsulating Security Payload) - протокол шифрования и проверки подлинности IP-

пакетов, передаваемых через крипто-туннель.

реализованы протоколы IKE версии 1 (RFC2407-2409) и ESP (RFC4303) на основе

стандарта, разработанного ООО «Крипто-Про», с использованием российских криптоалгоритмов

ГОСТ 28147-89, ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2012, ГОСТ Р 34.11-94, ГОСТ Р 34.11-2012.

В IKE реализована взаимная аутентификация на основе инфраструктуры открытых ключей

PKI (см. выше).

протокол IKE реализован в виде службы, которая при установлении туннеля фор-

мирует симметричный ключевой материал и загружает его в подсистему XFRM ядра Linux. Прото-

кол ESP реализуется подсистемой XFRM и подсистемой TCP/IP на уровне ядра Linux.

43.5.1

Базовые понятия протокола IKEv1

Основная цель протокола IKE - аутентифицировать удалённый узел, с которым требуется уста-

новить защищённое соединение, и выработать ключевой материал, используемый для симметрич-

ного шифрования IP-пакетов в протоколе ESP.

Протокол IKE представляет собой протокол «рукопожатия». Для обмена пакетами между сто-

ронами в качестве транспорта используется протокол UDP (порты 500, 4500). Протокол IKE со-

стоит из двух основных фаз.

В фазе 1 производится первоначальное согласование криптопараметров, используемых при

шифровании IKE-пакетов фазы 1 и 2, а также взаимная аутентификация сторон.

В фазе 2 производится согласование криптопараметров для протокола ESP и выработка клю-

чевого материала для шифрования/проверки подлинности IP-пакетов, передаваемых по туннелю.

43.5.1.1

Фаза 1

В протоколе IKE вводятся понятия инициатора и ответчика.

Инициатор - это тот узел, который пытается первым установить IPsec-туннель. Ответчик -

противоположная (слушающая) сторона.

В зависимости от настроек сторон роли инициатора и ответчика могут быть либо жёстко за-

креплены за каждым из узлов (модель клиент-сервер), либо стороны могут меняться ролями по

своему усмотрению (модель peer-to-peer).

На рисунке 43.1 изображён обмен IKE-пакетами между инициатором и ответчиком на фазе 1

(аутентификация по сертификатам, Main Mode, Aggressive Mode не реализован).

Условные обозначения:

• HDR - Header, заголовок пакета IKE. «*» означает, что пакет IKE зашифрован;

• SAi - Security Association, предложение наборов криптографических и технологических па-

раметров IKE от инициатора ответчику;

425

Рис. 43.1: Фаза 1 (PKI)

• VIDs - идентификаторы VendorID, уведомляющие о дополнительных возможностях: Dead

Peer Detection (RFC3706), NAT Traversal (RFC3947), GOST - IPsec по стандарту ООО «Крипто-

Про»;

• SAr - конкретный набор параметров, выбранный ответчиком из предложенных, и уведом-

ление инициатора о сделанном выборе;

• KEi/r - Key Exchange, обмен временными открытыми ключами для генерации общего секре-

та;

• Ni/r - Nonce, обмен случайными значениями для усиления криптографической защиты;

• - параметр, который может отсутствовать при определённых настройках сторон;

• NAT-D - NAT Detection, хэши реальных IP-адресов концов туннеля для определения ситуа-

ции «IPsec через NAT»;

• CRi - Certificate Request, уведомление ответчиком инициатора о доверяемом УЦ;

• CRr - уведомление инициатором ответчика о доверяемом УЦ;

• IDii/r - X500-имена инициатора и ответчика;

• CERTi/r - сертификаты инициатора и ответчика;

• SIGi/r - электронно-цифровые подписи инициатора/ответчика, сформированные по ранее

переданным параметрам.

Краткое описание фазы 1:

1. Инициатор желает установить защищённое соединение с ответчиком;

2. Инициатор знает IP-адрес ответчика и шлёт ему первый пакет (порт 500), содержащий

предлагаемые наборы параметров (криптопараметры для фазы 1 и 2, время жизни фазы 1,

и т.д.) и идентификатор, уточняющий реализацию протокола IKE;

3. Если ответчик не поддерживает данную реализацию протокола IKE или не может выбрать

ни один набор параметров, соединение не устанавливается;

426

Если ответчик выбрал набор из предлагаемых параметров, он шлёт ответный пакет с вы-

бранным набором;

Инициатор генерирует временную пару асимметричных ключей и шлёт открытый ключ от-

ветчику;

Ответчик получает временный открытый ключ инициатора, генерирует свою временную

асимметричную пару и шлёт открытый ключ инициатору;

Ответчик также может послать Certificate Request, то есть X500-имя удостоверяющего цен-

тра, чей сертификат должен обязательно присутствовать в цепочке сертификатов при про-

верки сертификата инициатора;

Ответчик вычисляет секрет на основе открытого ключа инициатора и собственного времен-

ного закрытого ключа;

Инициатор получает временный открытый ключ ответчика и вычисляет секрет на основе

полученного открытого ключа и собственного временного закрытого ключа. Секрет иници-

атора равен секрету ответчика;

10.

Инициатор и ответчик обмениваются хэшами своих реальных IP-адресов (NAT-D), чтобы

определить ситуацию «IPsec через NAT». Если NAT обнаружен, то последующий обмен (на-

чиная с 3-их пакетов) будет производиться через порт UDP 4500. Также трафик протокола

ESP будет инкапсулирован в UDP/4500;

11.

Инициатор формирует 3-й пакет из следующих данных:

12.

IDii - X500-имя инициатора;

13.

Сертификат инициатора (может не передаваться в зависимости от настроек). X500-имя

субъекта сертификата должно совпадать с IDii;

14.

Электронно-цифровая подпись, вычисленная с помощью закрытого ключа инициатора (со-

ответствующего сертификату) по переданным полям (в том числе IDii), которая удостове-

ряет, что X500-имя и сертификат действительно принадлежат данному инициатору;

15.

Также может быть послан Certificate Request - X500-имя УЦ, сертификат которого должен

обязательно присутствовать в цепочке сертификатов при проверки сертификата ответчика;

16.

Содержимое 3-го пакета инициатора зашифровывается на симметричном ключе, получен-

ном из общего секрета, значений Ni/r и т.д. Пакет передаётся ответчику;

17.

Ответчик расшифровывает пакет;

18.

Ответчик анализирует IDii и проверяет (согласно своим настройкам), разрешено ли устано-

вить соединение с данным субъектом;

19.

Ответчик анализирует полученный сертификат. Если сертификат не передан, то он ищет

его в локальном хранилище по имени IDii. Если сертификат не найден, соединение не уста-

навливается;

20.

Если IDii не соответствует X500-имени субъекта сертификата, соединение не устанавлива-

ется;

21.

Ответчик проверяет срок действия сертификата;

22.

Если есть информация о серверах OCSP для данного сертификата, сертификат проверяется

на отзыв;

23.

Если OCSP недоступен, ищется соответствующий список отзыва для данного сертификата.

СОС может быть загружен локально или может быть доступен по точкам распространения

СОС;

24.

Если сертификат отозван, соединение не устанавливается;

25.

Если OCSP и СОС недоступны, и включена строгая политика проверки на отзыв («crl policy

strict», см. ниже), то сертификат считается недействительным, и соединение не устанавли-

вается;

427

26. В локальных хранилищах сертификатов УЦ ищется сертификат УЦ, выпустившего данный

сертификат. Если он не найден, соединение не устанавливается;

27. Проверяется подпись сертификата открытым ключом сертификата УЦ. Если подпись не про-

шла проверку, соединение не устанавливается;

28. Сертификат УЦ проверяется так же, как описано выше;

29. Проверка осуществляется вплоть до корневого сертификата. (На корневой сертификат не

распространяется строгая политика проверки на отзыв);

30. Если хотя бы один сертификат оказался недействительным, соединение не устанавливает-

ся;

31. Если аутентификация инициатора прошла успешно, ответчик формирует свой 3-й IKE-пакет

аналогичным образом и шлёт его инициатору;

32. Инициатор аутентифицирует ответчика аналогично, как описано выше;

33. Если аутентификация ответчика прошла успешно, инициатор переходит к фазе 2.

В случае аутентификации по pre-shared ключам фаза 1 выглядит следующим образом (см. рис.

43.2).

Рис. 43.2: Фаза 1 (PSK)

Условные обозначения:

• IDii/r - IP-адреса концов туннеля (идентификация сторон осуществляется по IP-адресам);

• HASHi/r - хэши, сформированные по pre-shared ключу и по переданным параметрам.

Если pre-shared ключ совпадает на обеих сторонах, то инициатор/ответчик успешно проверят

присланные им HASHr и HASHi, соответственно, и аутентификация пройдёт успешно.

428

Рис. 43.3: Фаза 2

43.5.1.2

Фаза 2

Фаза 2 показана на рисунке 43.3.

Условные обозначения:

• HASH(1,2,3) - HMAC по некоторым переданным полям на основе общего секрета (для защи-

ты от подмены);

• SAi - предлагаемые наборы криптографических и технологических параметров ESP ответ-

чику инициатором;

• SAr - выбор ответчиком конкретного набора;

• Ni,r - дополнительные случайные значения для усиления криптографической защиты;

• KEi,r - обмен временными открытыми ключами для формирования дополнительного общего

секрета в режиме Perfect Forward Secrecy (PFS);

• IDci - адрес и маска внутренней (защищаемой) подсети, находящейся за инициатором. Так-

же могут быть заданы протокол и порт для конкретизации трафика;

• IDcr - адрес и маска внутренней (защищаемой) подсети, находящейся за ответчиком. (Оп-

ционально - протокол, порт);

Краткое описание фазы 2:

Все пакеты фазы 2 зашифрованы на основе общего секрета, выработанного на фазе 1.

1. Инициатор предлагает наборы параметров (криптопараметры туннеля ESP, время жизни

фазы 2/туннеля ESP, и т.д.) ответчику;

2. Также в SAi формируется Security Parameters Index (SPI) туннеля от инициатора к ответчику

- SPIir;

429

Также инициатор предлагает адреса/маски внутренних защищаемых подсетей (своей и от-

ветчика). (А также возможна конкретизация протокола и портов. См. пояснение ниже);

Если указан протокол, то в туннель будут попадать только трафик данного протокола. Для

протоколов TCP/UDP может быть указан порт;

Инициатор может передать дополнительный временный открытый ключ (KEi), предложив

тем самым режим Perfect Forward Secrecy (PFS). В этом случае ответчик передаёт свой KEr, и

производится формирование дополнительного общего секрета (так же, как описано в фазе

1), участвующего в вычислении ключевого материала для ESP;

Ответчик получает пакет от инициатора, расшифровывает его и проверяет HASH(1);

Ответчик анализирует IDci, IDcr и проверяет, согласуются ли желаемые инициатором под-

сети/маски/протокол/порт с настройками ответчика. Если нет, соединение не будет уста-

новлено;

Ответчик анализирует предлагаемые наборы параметров. Если ни один не подходит, соеди-

нение не будет установлено;

Ответчик выбирает конкретный набор параметров и формирует ответный пакет. В SAr фор-

мируется SPI туннеля от ответчика к инициатору - SPIri;

10.

Инициатор получает пакет от ответчика, расшифровывает его и проверяет HASH(2);

11.

Если успешно, туннель со стороны инициатора считается установленным. Инициатор фор-

мирует ключевой материал для туннеля и передаёт его в систему управления протоколом

ESP;

12.

Инициатор высылает ответчику пакет подтверждения об успешном установлении туннеля;

13.

Ответчик получает пакет, расшифровывает и проверяет HASH(3);

14.

Если успешно, туннель со стороны ответчика считается установленным. Ответчик формиру-

ет ключевой материал для туннеля и передаёт его в систему управления протоколом ESP.

Пояснение к полю протокол/порт в IDci, IDcr:

Действуют следующие правила:

1. Если протокол/порт не заданы в IDci, то их также не должно быть в IDcr (и наоборот). В этом

случае весь трафик, идущий из подсети инициатора в подсеть ответчика и обратно, будет

идти через туннель. (Исключение составляет трафик UDP/500/4500 - трафик IKE никогда в

туннель не попадает);

2. Если задан протокол в IDci, то должен быть задан такой же протокол в IDcr. В этом случае

в туннель будет попадать только трафик указанного протокола (из подсети инициатора в

подсеть ответчика и обратно);

3. Для протоколов UDP и TCP можно указывать порт;

4. Если порт не указан, в туннель попадает весь трафик TCP/UDP;

5. В IDci/IDcr могут быть указаны разные порты. Также возможна ситуация наличия порта в

IDci и отсутствие в IDcr (и наоборот).

В случае указания портов в туннель будет попадать следующий трафик:

• Инициатор Ответчик: порт отправителя из IDci, порт получателя из IDcr;

• Ответчик Инициатор: порт отправителя из IDcr, порт получателя из IDci.

Из фазы 1 может быть порождено несколько фаз 2. Обычно следующая фаза 2 порождается

незадолго до истечения времени жизни старой фазы 2 (времени жизни туннеля) для обновления

ключевого материала туннеля.

430

43.5.1.3

Фаза ModeConfig

Иногда при использовании модели «клиент - сервер» необходимо назначать клиенту внут-

ренний (виртуальный) IP-адрес из пула сервера. В этом случае параметр фазы 2 IDci не может

быть сформирован заранее. Поэтому для назначения клиенту внутреннего IP-адреса использует-

ся дополнительная фаза ModeConfig (см. рис. 43.4), которая происходит между фазой 1 и фазой

Рис. 43.4: Фаза ModeConfig

Условные обозначения:

• ADDR_REQ - запрос клиентского адреса у сервера;

• ADDR_REPLY - назначение адреса клиенту.

43.5.1.4

Уведомление сторон

Стороны могут слать друг другу асинхронные уведомления на любом этапе установления тун-

неля или в процессе работы туннеля (см. рис. 43.5).

Условные обозначения

• N - Notification. Уведомление (как правило, о причине отторжения пакета, пришедшего от

противоположной стороны);

• D - Delete. Требование закрыть активную фазу 1 или 2 (удалить состояние конечного авто-

мата IKE). Удаление фазы 2 равносильно закрытию установленного туннеля.

431

Рис. 43.5: Сообщения уведомлений

43.5.2

Базовые понятия протокола ESP

ESP - это IP-протокол с номером 50. В ситуации «IPsec через NAT» протокол ESP инкапсули-

руется в UDP/4500 (RFC3948).

Протокол ESP инкапсулирует IP-трафик и зашифровывает его на основе симметричных клю-

чей, выработанных протоколом IKE. Также для проверки подлинности передаваемых данных фор-

мируется контрольная сумма пакета, выработанная с помощью симметричного ключа.

Содержимое пакета ESP:

• Security Parameters Index (SPI) - идентификатор контекста симметричных ключей (иденти-

фикатор туннеля);

• Sequence Number - порядковый номер пакета;

• Init Vector (IV) - синхропосылка для симметричного алгоритма шифрования;

• Зашифрованные данные (выровненные до шифрования);

• Integrity Check Value (ICV) - защищённая контрольная сумма.

При установлении туннеля (протоколом IKE) формируются два контекста симметричных клю-

чей (Security Association, SA) для направлений от инициатора к ответчику и от ответчика к ини-

циатору. Эти SA идентифицируются, соответственно, индексами SPIir и SPIri.

Наборы SA для всех туннелей данного узла формируют базу данных SA (SA Database, SAD).

Каждый SA-элемент содержит:

• Номер SPI;

• Идентификатор протокола (ESP);

432

• Идентификаторы криптоалгоритмов и криптопараметров;

• Симметричные ключи для шифрования и проверки подлинности IP-пакетов;

• IP-адреса концов туннеля;

• Режим туннеля;

• Идентификатор соответствия элементу в базе данных IPsec-политик (SPD, см. ниже) - reqid;

• Другую служебную информацию.

Наличие пар SA на обоих криптомаршрутизаторах означает успешно установленный IPsec-

туннель.

Политика IPsec (Security Policy, SP) представляет собой набор правил, на основе которых

принимается решение о направлении трафика в IPsec-туннель. Совокупность политик на данном

узле формирует базу данных политик (SP Database, SPD). Каждый SP-элемент содержит:

• Правило отбора трафика по направлению (in/out/fwd);

• Правило отбора трафика по IP-адресу отправителя;

• Правило отбора трафика по IP-адресу назначения;

• Правило отбора трафика по протоколу/порту (опционально);

• Правило отбора трафика по метке (опционально);

• Приоритет политики;

• Идентификаторы соответствия с SA (reqid, IP-адреса концов туннеля и т.д.);

• Управляющие флаги и другую служебную информацию.

При установленном туннеле в системе присутствуют политики SP и соответствующие им крип-

токонтексты SA.

К выходящему (открытому) трафику сначала применяются политики SP (направление «out»).

Если трафик попадает под критерии определённой политики, то осуществляется попытка поиска

соответствующего SA. Если SA не найден, трафик отбрасывается. Если SA найден, то происходит

инкапсуляция трафика в пакеты ESP на основе найденного криптоконтекста, и зашифрованный

трафик отправляется в систему маршрутизации.

Входящий (зашифрованный) трафик обрабатывается в обратном порядке. Из пакета ESP из-

влекается SPI, и ищется соответствующий криптоконтекст SA (по SPI и IP-адресам концов тунне-

ля). Если SA не найден, трафик отбрасывается. Если SA найден, производится расшифрование и

проверка подлинности инкапсулированного IP-пакета. При неудаче пакет отбрасывается. Ищет-

ся политика SP, которая соответствует данному криптоконтексту SA. Анализируются IP-адреса

отправителя и назначения и выполняется проверка расшифрованного пакета на соответствие

найденной политике (по направлению, IP-адресам, протоколу/порту, метке). Для пакетов, адре-

сованных данному узлу, используется политика с направлением «in». Для транзитных пакетов

используется политика с направлением «fwd». Если пакет не удовлетворяет политике SP, то он

отбрасывается. Далее выполняется маршрутизация расшифрованного пакета.

Существуют 2 режима инкапсуляции IP-трафика в ESP:

• Транспортный режим;

• Туннельный режим.

433

В транспортном режиме заменяется заголовок IP-пакета, и шифруется содержимое. В транс-

портном режиме возможно соединение только типа «точка-точка».

В туннельном режиме инкапсулируется весь исходный IP-пакет. В этом режиме возможны

соединения как «точка-точка», так «подсеть-подсеть». Рекомендуется использовать туннельный

режим.

43.5.3

Соединения IPsec

Необходимо ввести понятие «соединения IPsec».

Одно соединение IPsec - это одна из следующих конфигураций сети (см. рис. 43.6).

Если требуется направить трафик из нескольких (разных) подсетей в туннель, то необходимо

настроить несколько соединений (ограничение протокола IKEv1).

В случае соединения типа «клиенты-сервер» будет порождено несколько подчинённых соеди-

нений.

43.5.4

Минимальные настройки IPsec (PKI)

Рассмотрим самый простой пример настройки соединения типа «точка-точка» со взаимной

аутентификацией по сертификатам X.509. В данном примере даны минимально необходимые на-

стройки, для установления туннеля IPsec. Более подробная информация будет дана в следующих

разделах. Также в следующем разделе показаны минимально необходимые настройки со взаим-

ной аутентификацией по предварительно разложенным ключам (pre-shared keys).

Допустим у нас есть два узла

с IP-адресами 192.168.1.1 и 192.168.2.1.

Настройка узла 1:

Импортируем сертификат узла, сертификат удостоверяющего центра и закрытый ключ узла с

внешнего носителя. (См. PKI выше):

# crypto pki import key from keys/router1.nam

# crypto pki import root ca cert from certs/ca.cer

# crypto pki import cert from certs/router1.cer

Входим в режим конфигурации и запускаем службу IKE:

# configure terminal

(config)# crypto ike enable

Создаём настройку соединения. Назовём его «t1»:

(config)# crypto ike conn t1

(config−ike−conn−t1)# _

Вид строки приглашения говорит о том, система находится в режиме редактирования настроек

соединения «t1».

По умолчанию действует режим аутентификации по сертификатам X.509, что эквивалентно

опции:

435

(config−ike−conn−t1)# auth pubkey

Задаём IP-адреса концов туннеля - локального и удалённого:

(config−ike−conn−t1)# local ip 192.168.1.1

(config−ike−conn−t1)# remote ip 192.168.2.1

Задаём имя используемого сертификата:

(config−ike−conn−t1)# local cert router1.cer

Задаём X500-имя сертификата нашего оппонента:

(config−ike−conn−t1)# remote id ”CN=Узел 2, O=Хорошая организация, C=RU”

ПРИМЕЧАНИЕ: Практический опыт показывает, что набор X500-имени вручную является тру-

доёмкой задачей и часто приводит к опечаткам, из-за которых впоследствии происходит отказ

в установлении соединения. Чтобы этого избежать, можно импортировать X500-имя непосред-

ственно из сертификата оппонента. Для этого необходимо предварительно загрузить сертификат

оппонента в систему. Пример:

(config−ike−conn−t1)# do crypto pki import cert from certs/router2.cer

(config−ike−conn−t1)# remote id from cert router2.cer

(config−ike−conn−t1)# exit

(config)# _

Минимальная настройка соединения «точка-точка» закончена.

Проверим статус заданного соединения командой режима привилегированного режима «show

crypto ike conns»:

(config)# do show crypto ike conns

disabled

Новые созданные соединения изначально находятся в выключенном состоянии. Чтобы наше

соединение смогло стать активным, его необходимо включить:

(config)# crypto ike enable conn t1

(config)# do show crypto ike conns

listen

Теперь соединение включено и находится в «слушающем» состоянии, то есть оно готово на-

чать установление туннеля IPsec. Установление туннеля может быть инициировано данным узлом

(см. ниже), либо может быть инициировано нашим оппонентом.

Теперь выполним настройку узла 2, которая, по сути, будет симметричной настройке узла 1.

# crypto pki import key from keys/router2.nam

# crypto pki import root ca cert from certs/ca.cer

# crypto pki import cert from certs/router2.cer

# configure terminal

(config)# crypto ike enable

(config)# crypto ike conn t1

(config−ike−conn−t1)# local ip 192.168.2.1

(config−ike−conn−t1)# remote ip 192.168.1.1

436

(config−ike−conn−t1)# local cert router2.cer

(config−ike−conn−t1)# remote id ”CN=Узел 1, O=Хорошая организация, C=RU”

(config−ike−conn−t1)# crypto ike enable conn t1

(config)# do show crypto ike conns

listen

Теперь оба узла готовы к установлению соединения. В данной конфигурации любой из узлов

может стать инициатором.

Инициируем соединение с любого из узлов командой «crypto ike initiate conn» из привилеги-

рованного режима:

(config)# exit

# crypto ike initiate conn t1

Если установление туннеля прошло успешно, то на обоих узлах статус соединения «t1» дол-

жен стать «online»:

# show crypto ike conns

online

Теперь весь трафик (типа «точка-точка») между узлами 1 и 2 будет инкапсулироваться в про-

токол ESP. Важно помнить, что если к узлу 1, например, подключены другие сети, то проходящий

трафик через узел 1 к узлу 2 из этих сетей НЕ будет попадать в туннель и (если не настрое-

ны фильтры) будет идти в открытом виде. Ибо данный трафик будет являться трафиком типа

«подсеть-точка» и не будет попадать в туннель типа «точка-точка».

43.5.5

Минимальные настройки IPsec (PSK)

Минимальные настройки IPsec с аутентификацией по pre-shared ключам выглядят ещё проще.

(За основу взят пример из предыдущего раздела).

Настройка узла 1:

Загружаем pre-shared ключ с внешнего носителя (допустим, из файла /psks/key1):

# crypto psk set key psk1 flash /psks/key1

Ассоциируем загруженный ключ с концами туннеля:

# configure terminal

(config)# crypto psk map 192.168.1.1 192.168.2.1 psk1

Создаём соединение, указываем метод аутентификации по PSK и IP-адреса концов туннеля:

(config)# crypto ike conn t1

(config−ike−conn−t1)# auth psk

(config−ike−conn−t1)# local ip 192.168.1.1

(config−ike−conn−t1)# remote ip 192.168.2.1

Включаем туннель и службу IKE:

437

(config−ike−conn−t1)# crypto ike enable

(config)# crypto ike enable conn t1

(config)# do show crypto ike conns

listen

Выполняем симметричные настройки узла 2:

# crypto psk set key psk1 flash /psks/key1

# configure terminal

(config)# crypto psk map 192.168.2.1 192.168.1.1 psk1

(config)# crypto ike conn t1

(config−ike−conn−t1)# auth psk

(config−ike−conn−t1)# local ip 192.168.2.1

(config−ike−conn−t1)# remote ip 192.168.1.1

(config−ike−conn−t1)# crypto ike enable

(config)# crypto ike enable conn t1

Инициируем соединение с любого из узлов:

(config)# do crypto ike initiate conn t1

(config)# do show crypto ike conns

online

43.5.6

IPsec и фильтрация

ВАЖНО помнить, что подсистема IPsec не занимается фильтрацией трафика. Подсистема

IPsec только принимает решение, направлять ли его в туннель. Решение принимается на основе

настроек соединений (опции «local/remote ip», «local/remote subnet», «local/remote source ip»,

«local/remote protoport» - см. ниже) и на основе текущего состояния соединения. Например, если

соединение неактивно (находится в состоянии «listen»), то трафик не будет направлен в туннель,

но будет пропущен, как есть.

Из этого следует, что совместно с настройкой IPsec необходимо настроить соответствующую

фильтрацию.

Например:

# configure terminal

(config)# ip access−list ipsec_only

(config−acl−ipsec_only)# permit udp sport 500 dport 500

(config−acl−ipsec_only)# permit udp sport 4500 dport 4500

(config−acl−ipsec_only)# permit esp

(config−acl−ipsec_only)# deny

(config−acl−ipsec_only)# interface ethernet 0

(config−if−ethernet0)# ip access−group ipsec_only in

(config−if−ethernet0)# ip access−group ipsec_only out

В данном примере мы предполагаем, что интерфейс «ethernet 0» подключён к внешней (опас-

ной) сети. И мы фильтруем весь трафик, проходящий через этот интерфейс, за исключением

трафика IKE и ESP.

438

43.5.7

Управление и диагностика службы IKE

Управление туннелями IPsec осуществляется через службу IKE.

43.5.7.1

Запуск/останов службы

Служба IKE может находиться в двух состояниях: остановленном (по умолчанию) и запущен-

ном.

При остановленной службе IKE установление IPsec-туннелей невозможно. Чтобы запустить

службу, необходимо выполнить команду режима конфигурации:

(config)# crypto ike enable

По данной команде служба запускается, загружает все закрытые ключи и сертификаты УЦ

из локальных хранилищ, активирует включённые («enabled») соединения (см. ниже) и начинает

«слушать» на портах 500/4500 протокола UDP (на всех интерфейсах) входящие IKE-запросы. Если

по каким-то причинам запуск службы оказался неудачным (не загружен ключ доступа, фатальная

ошибка при активации соединения и т.д.), служба переводится в остановленное состояние.

Остановить службу можно командой режима конфигурации:

(config)# crypto ike disable

При останове службы IKE закрываются все IPsec-соединения.

43.5.7.2

Диагностика службы

В процессе работы теоретически могут возникать ситуации, когда служба IKE может завер-

шаться аварийно. В этом случае она автоматически переходит в остановленное состояние. В слу-

чае возникновения таких ситуаций следует уведомить разработчиков.

Чтобы узнать текущее состояние службы IKE, необходимо выполнить команду режима enable:

# show crypto ike status

В процессе своей работы служба IKE ведёт журнал. Просмотреть журнал можно с помощью

команды режима enable:

# show crypto ike log [параметры]

Команда без параметров выдаёт последние 25 строк журнала.

Возможные параметры команды «show crypto ike log» (могут использоваться в различных ком-

бинациях):

• nostamp - выводить только текст журнала, без временных заголовков;

• all - вывести весь файл журнала;

• number <n> - вывести последние n строк журнала;

• follow - следить за журналом в реальном времени (Ctrl-C - выход из режима);

• archive <n> - посмотреть архивный файл журнала (чем n больше, тем старше архив).

439

Чтобы очистить журнал (и все архивы), необходимо выполнить команду:

# crypto ike clear log

43.5.7.3

Глобальные настройки службы

У службы IKE есть ряд глобальных настроек (см. разделы ниже). Чтобы отредактировать эти

настройки, надо войти в режим настроек IKE с помощью команды режима configure:

(config)# crypto ike config

Следует помнить, что если настройки редактируются при запущенной службе IKE, они не при-

меняются немедленно. Чтобы они применились, необходимо перезапустить службу (что повлечёт

за собой закрытие всех туннелей):

(config)# crypto ike disable

(config)# crypto ike enable

43.5.7.4

Особенности обновления PKI/PSK-данных

Следует помнить, что изменения в PKI/PSK (сертификаты, ключи, СОС, cainfo и др.) не повли-

яют на запущенную службу IKE, так как она хранит все PKI/PSK-данные в оперативной памяти.

Если требуется перезагрузить PKI-данные без перезапуска службы IKE, нужно выполнить коман-

ду режима enable:

# crypto ike reload

Однако, если были изменены глобальные настройки службы IKE, команда «crypto ike reload»

выполнит полный перезапуск службы IKE (с предварительным предупреждением).

ВАЖНО: Следует помнить, что команда «crypto ike reload» перезагружает только сертификаты

УЦ. Чтобы перезагрузить клиентские сертификаты, следует выключить/включить соответствую-

щие соединения (см. ниже).

43.5.7.5

Удаление всех настроек IKE

Чтобы удалить все настройки службы IKE со всеми настройками соединений, нужно выполнить

команду режима configure:

# no crypto ike

При этом все активные соединения закрываются, и служба IKE останавливается.

43.5.8

Управление и диагностика состояний соединений

43.5.8.1

Создание соединения

Как уже было сказано выше, новое соединение создаётся командой режима configure:

440

(config)# crypto ike conn <имя>

(config-ike-conn-<имя>)# _

Данная команда служит как для создания новых соединений, так и для редактирования на-

строек существующих соединений. Соединение IPsec идентифицируется по имени.

Новое соединение создаётся в выключенном («disabled») состоянии (см. ниже).

43.5.8.2

Удаление соединения

Если требуется удалить соединение со всеми настройками, используется команда режима

configure:

(config)# no crypto ike conn <имя>

Если соединение было активно, то перед удалением оно закрывается.

43.5.8.3

Состояния соединений

Соединения IPsec могут находиться в различных состояниях.

Чтобы вывести состояния всех соединений, нужно выполнить команду режима enable:

# show crypto ike conns

Пример вывода:

disabled

listen

routed

t4 [1] online

t4 [2] online

Несколько соединений с одним именем и разными номерами, это порождённые соединения от

соединения типа «клиенты-сервер» (см. ниже).

Для вывода состояния одного соединения можно использовать команду:

# show crypto ike conn <имя_соединения>

Краткое описание состояний соединения:

disabled

Соединение выключено;

enabled

Соединение помечено, как «влючённое», но

служба IKE остановлена;

unresolved

Настройки соединения содержат доменные

имена, которые не были разрешены в IP-

адреса;

invalid

После разрешения IP-адресов выявлены

некорректные настройки соединения. Соеди-

нение заблокировано;

listen

Cоединение включено, но неактивно;

441

routed

Соединение неактивно, но загружены полити-

ки IPsec (SP);

pending1

Соединение пытается стать активным, но не

завершилась IKE фаза 1;

pending_mdcfg

Не завершилась фаза ModeConfig, или ожида-

ется начало фазы 2;

pending2

Не завершилась фаза 2;

online

Соединение активно. Установлен IPsec-

туннель;

unknown

Внутренняя ошибка.

43.5.8.4

Состояние “disabled”

Состояние «disabled» равносильно отсутствию соединения, как такового. В данном состоянии

существуют только настройки соединения, но никакого влияния на систему они оказывать не

будут. Настройки соединения следует редактировать именно в этом состоянии. Позволяется ре-

дактировать настройки и в других состояниях, но следует помнить, что они не будут применены

немедленно. Чтоб они вступили в силу, потребуется сначала перевести соединение обратно в

состояние «disabled», а потом снова в состояние «enabled». Если настройки производятся в со-

стоянии «enabled», но при остановленной службе IKE, то выключать/включать соединение не

требуется (но требуется запустить службу IKE - см. выше).

В состояние «disabled» соединение переводится командой режима configure:

(config)# crypto ike disable conn <имя>

Если соединение было активно, то данная команда закрывает IPsec-туннель.

43.5.8.5

Состояние “enabled”

После редактирования настроек соединения, необходимо его включить командой режима

configure:

(config)# crypto ike enable conn <имя>

При остановленной службе IKE соединение будет только помечено, как включённое

(«enabled»). После запуска службы IKE будет сделана попытка перевести соединение в состо-

яние, согласно настройке «auto» (см. ниже).

При активации соединения при запущенной службе IKE сразу будет сделана попытка переве-

сти соединение в состояние, согласно настройки «auto».

Активация соединения с помощью команды «crypto ike enable conn» также загружает в память

соответствующий клиентский сертификат. Если во время включённого соединения сертификат

был заменён с помощью команды «crypto pki import cert», то для того, чтобы он вступил в силу,

надо выключить/включить соединение.

442

43.5.8.6

Состояние “unresolved”

Если соединение содержит доменные имена и/или ссылку на интерфейс (см. «Динамическое

разрешение адресов» ниже), и IP-адреса не могут быть разрешены немедленно, то соединение

попадёт в состояние «unresolved» и будет находиться в нём до тех пор, пока не будут получены

все необходимые IP-адреса. В состоянии «unresolved» инициирование соединения невозможно.

При разрешении всех IP-адресов соединение перейдёт в соответствующее состояние согласно

настройке «auto».

43.5.8.7

Состояние “invalid”

Если соединение находилось в состоянии «unresolved», и произошло успешное разрешение

IP-адресов, но при этом выяснилось, что соединение настроено некорректно, то оно попадает в

состояние «invalid». В этом состоянии соединение никогда не станет активным. Для того, чтобы

вывести соединение из этого состояния, необходимо его перевести в состояние «disabled» (или

остановить службу IKE) и отредактировать настройки соответствующим образом для устранения

некорректности. Чтобы диагностировать причину состояния «invalid», необходимо просмотреть

журнал службы IKE. В частности, состояние «invalid» может быть вызвано ситуацией, описанной

в разделе «Особенности настройки некоторых параметров фазы 1» (см. ниже).

43.5.8.8

Настройка “auto”

Настройка «auto» задаётся для каждого соединения в режиме редактирования его настроек.

Например:

(config)# crypto ike conn t1

(config−ike−conn−t1)# auto route

Существуют 4 значения настройки «auto», в зависимости от которых осуществляется попытка

перевести соединение в соответствующее состояние автоматически после включения соедине-

ния.

Настройка

Желаемое состояние

Состояние при неуда-

Эквивалент ручной

че

команды

auto listen

listen

crypto ike close conn

<имя>

auto route

routed

listen

crypto ike route conn

<имя>

auto initiate

online

pending, listen

crypto ike initiate conn

<имя>

auto route initiate

online

pending, routed

crypto ike route conn

<имя>, crypto ike

initiate conn <имя>

По умолчанию действует настройка «auto listen».

443

43.5.8.9

Состояние “listen”

В состоянии «listen» соединение неактивно, но готово к установлению. Соединение может

быть инициировано либо со стороны данного узла (командой enable-режима «crypto ike initiate

conn»), либо со стороны оппонента. Также это состояние можно назвать «слушающим».

Чтобы принудительно привести соединение в состояние «listen» из других состояний, можно

выполнить команду enable-режима:

# crypto ike close conn <имя>

Данная команда закрывает туннель (удаляет криптоконтексты SA), очищает состояния конеч-

ных автоматов соответствующих фаз 1 и 2 и удаляет соответствующие политики SP.

43.5.8.10

Состояние “routed”

Состояние «routed» похоже на состояние «listen» за исключением того, что инсталлируются

специальные политики в SPD. Если будет обнаружен трафик, удовлетворяющий правилам отбо-

ра в данный туннель, то это приведёт к автоматическому инициированию соединения. Следует

отметить, что первые пакеты трафика (до установления соединения) будут отброшены, так как

ещё не существует соответствующих криптоконтекстов SA.

Примечание: Повторное инициирование соединения по трафику возможно только по проше-

ствии 165 секунд после начала предыдущего инициирования по трафику.

Чтобы принудительно привести соединение в состояние «routed» из других состояний, можно

выполнить команду enable-режима:

# crypto ike route conn <имя>

Данная команда закрывает туннель (если он был активным) и инсталлирует политики SP для

перехвата трафика для инициации соединение.

43.5.8.11

Ручная инициация соединения. Состояние “online”

Чтобы принудительно инициировать соединение, следует выполнить команду enable-режима:

# crypto ike initiate conn <имя>

В случае успешной инициации соединение переходит в состояние «online», не задержива-

ясь в состояниях «pending*». В состоянии «оnline» на обоих концах туннеля существуют пары

криптоконтекстов SA.

В случае неуспешной инициации команда «crypto ike initiate conn» будет продолжать попыт-

ки установления соединения, блокируя при этом консоль примерно в течение 1 минуты. Далее

консоль будет разблокирована, однако соединение будет продолжать попытки установиться (см.

раздел «Таймеры»). Разблокировать консоль можно нажатием клавиш Ctrl-C.

Чтобы избежать блокировки консоли при принудительной инициации соединения, следует

выполнить команду с параметром «async».

# crypto ike initiate conn <имя> async

444

43.5.8.12

Состояния “pending”. Причины неудачного соединения

Состояние «pending1» означает, что IKE-фаза 1 не смогла успешно завершиться. Это может

быть вызвано следующими причинами:

• Нет связи с оппонентом;

• Несовместимость систем IPsec между собой (уведомление ATTRIBUTES_NOT_SUPPORTED);

• Оппонент не поддерживает предлагаемые криптопараметры IKE

(уведомление

NO_PROPOSAL_CHOSEN);

• X500-имя инициатора/ответчика отвергнуто противоположной стороной

(уведомление

INVALID_ID_INFORMATION);

• Не найден собственный закрытый ключ для формирования подписи

(уведомление

AUTHENTICATION_FAILED);

• Неправильная ЭЦП от оппонента (уведомление AUTHENTICATION_FAILED);

• Невозможно проверить сертификат оппонента из-за отсутствия, недействительности, отзы-

ва, неполной цепочки сертификатов и т.д. (уведомление AUTHENTICATION_FAILED);

• Неправильная область применения сертификата (уведомление INVALID_CERTIFICATE);

• Рассинхронизация криптоконтекста из-за выше перечисленных причин или из-за внутрен-

ней ошибки (уведомление PAYLOAD_MALFORMED).

Состояние «pending_mdcfg» означает незавершённую фазу выдачи виртуального адреса мо-

бильному клиенту. Также со стороны ответчика данное состояние может означать ожидание на-

чала (или неудачное начало) фазы 2.

Состояние «pending2» означает незавершённость фазы 2. Это может быть вызвано следую-

щими причинами:

• Оппонент не поддерживает предлагаемые криптопараметры ESP

(уведомление

NO_PROPOSAL_CHOSEN);

• Конфигурации правил отбора трафика (подсети, протокол, порт) оппонентов не совпадают

(уведомление INVALID_ID_INFORMATION);

• Неправильная область применения сертификата (уведомление INVALID_CERTIFICATE);

• Рассинхронизация криптоконтекста (уведомление PAYLOAD_MALFORMED);

• Мобильный клиент не инициировал фазу ModeConfig, и ему не был назначен виртуальный

адрес (уведомление ADDRESS_NOTIFICATION).

43.5.8.13

Особенности инициирования соединений из состояний “listen” и “routed”

Существует разница между инициированием соединений из состояний «listen» и «routed». Ес-

ли соединение было инициировано из состояния «listen», то при закрытии данное соединение бу-

дет возвращено в состояние «listen». Если соединение было инициировано из состояния «routed»,

то при закрытии оно будет возвращено в состояние «routed». Если необходимо автоматически

инициировать соединение при запуске службы IKE, и также необходимо, чтобы соединение воз-

вращалось в состояние «routed» при его закрытии, то вместо опции «auto initiate» необходимо

указать опцию «auto route initiate».

445

43.5.8.14

Причины инициирования и закрытия соединений

Причины, вызывающие инициирование соединения:

• Ручная команда «crypto ike initiate conn»;

• Настройка «auto initiate» или «auto route initiate»;

• Инициация соединения со стороны оппонента;

• Исходящий трафик, попадающий в правила отбора (из состояния «routed»);

• Настройка «dpd; action initiate» или «action route initiate» (если соединение было закрыто

по Dead Peer Detection, см. ниже).

Причины, вызывающие закрытие соединения:

• Ручная команда «crypto ike close conn»;

• Закрытие соединения со стороны оппонента (см. примечание ниже);

• Истечение времени жизни туннеля и отсутствие инициативы его продления хотя бы с одной

стороны (см. опцию «no rekey» ниже);

• Закрытие соединения по Dead Peer Detection (при настройках «dpd action close» или «action

route»);

• Деактивация соединения командой «crypto ike disable conn»;

• Останов службы IKE.

ПРИМЕЧАНИЕ: Если соединение было инициировано с нашей стороны (одной из «initiate»

настроек/команд), то при закрытии со стороны оппонента оно будет заново инициировано нашей

стороной. Если соединение было инициировано с нашей стороны по первому исходящему трафику

из состояния «routed», то при закрытии соединения со стороны оппонента оно будет переведено

обратно в состояние «routed», и инициации с нашей стороны не последует (до нового исходящего

трафика). Во всех остальных случаях при закрытии соединения со стороны оппонента оно будет

переведено в исходное пассивное состояние («routed» или «listen»).

43.5.8.15

Диагностика соединений

Информацию о процессе установления соединения можно посмотреть в журнале службы IKE

(см. команду «show crypto ike log» выше). Также в журнале записываются принятые уведомления,

перечисленные выше. Для вывода в журнал более подробной отладочной информации (кроме

криптографической) можно включить опцию:

(config)# crypto ike config

(config−ike)# debug control

В штатном режиме рекомендуется использовать опцию по умолчанию:

(config−ike)# no debug

Чтобы вывести подробную информацию о состоянии соединения, можно выполнить команду

enable-режима:

# show crypto ike conn <имя> verbose

446

Идентификаторы типа «STATE_MAIN_I4» или «STATE_QUICK_R1» обозначают состояния фаз

IKE, где:

• MAIN - фаза 1 (Main Mode);

• QUICK - фаза 2 (Quick Mode);

• I - инициатор;

• R - ответчик;

• цифра - порядковый номер состояния конечного автомата для данной фазы.

43.5.8.16

Диагностика политик и криптоконтекстов IPsec

Чтобы вывести базу данных политик IPsec (SPD), нужно выполнить команду:

# show crypto xfrm policy [verbose]

Чтобы вывести базу данных криптоконтекстов (SAD), нужно выполнить команду:

# show crypto xfrm state [verbose]

43.5.8.17

Вывод всех настроек соединения

Чтобы вывести полную конфигурацию соединения вместе с настройками по умолчанию, нужно

выполнить команду:

# show crypto ike conn <имя> config

43.5.9

Копирование настроек соединений

Так как IKEv1 не поддерживает множественные правила отбора, то часто возникает необхо-

димость создать новое соединение на основе настроек старого. В этом случае рекомендуется со-

здать новое соединение путём копирования из старого. Это делается с помощью команды режима

configure:

(config)# crypto ike copy conn <старое_соединение> to <новое_соединение>

Новое соединение создаётся в выключенном состоянии («disabled»).

43.5.10

Туннельный и транспортный режим

По умолчанию IPsec-туннель будет работать в туннельном режиме. Если необходимо включить

транспортный режим, то следует указать опцию в режиме конфигурации соединения:

(config)# crypto ike conn <имя>

(config-ike-conn-<имя>)# type transport

Вернуть туннельный режим можно командой:

447

(config-ike-conn-<имя>)# type tunnel

Без необходимости данную настройку менять не нужно.

Также следует помнить, что данная настройка имеет смысл для соединений типа «точка-

точка». Для соединений других типов (с подсетями) будет всегда действовать туннельный режим

(например, если присутствуют опции «remote subnet» или «local subnet»).

43.5.11

Соединения “подсеть-подсеть” и “точка-подсеть”

Для того, чтобы соединение работало в режиме «подсеть-подсеть» (см. выше), нужно ука-

зать адреса/маски локальной и удалённой подсетей, защищаемых криптомаршрутизаторами. Это

делается с помощью опций режима конфигурации соединения:

(config-ike-conn-<имя>)# local subnet <IP/mask>

(config-ike-conn-<имя>)# remote subnet <IP/mask>

Пример:

Допустим, существуют два криптомаршрутизатора: Dionis1 и Dionis2.

Dionis1 защищает внутреннюю сеть 10.1.0.0/16, а Dionis2 - свою внутреннюю сеть

10.2.0.0/16.

Dionis1 и Dionis2 образуют криптотуннель, IP-адреса концов которого 11.1.0.1

11.2.0.1

со-

ответственно.

Настройка Dionis1:

(config)# crypto ike conn t1

(config−ike−conn−t1)# auto route

(config−ike−conn−t1)# local cert dionis1.cer

(config−ike−conn−t1)# remote id ”CN=Dionis 2, O=Хорошая организация, C=RU”

(config−ike−conn−t1)# local ip 11.1.0.1

(config−ike−conn−t1)# remote ip 11.2.0.1

(config−ike−conn−t1)# local subnet 10.1.0.0/16

(config−ike−conn−t1)# remote subnet 10.2.0.0/16

(config−ike−conn−t1)# exit

(config)# crypto ike enable conn t1

Настройка Dionis2:

(config)# crypto ike conn t1

(config−ike−conn−t1)# auto route

(config−ike−conn−t1)# local cert dionis2.cer

(config−ike−conn−t1)# remote id ”CN=Dionis 1, O=Хорошая организация, C=RU”

(config−ike−conn−t1)# local ip 11.2.0.1

(config−ike−conn−t1)# remote ip 11.1.0.1

(config−ike−conn−t1)# local subnet 10.2.0.0/16

(config−ike−conn−t1)# remote subnet 10.1.0.0/16

(config−ike−conn−t1)# exit

(config)# crypto ike enable conn t1

448

При данных настройках любой трафик из сети 10.1.0.0/16 в 10.2.0.0/16 (и обратно) вызовет

инициацию туннеля (опция «auto route»).

Следует отметить, что при такой конфигурации в туннель будет попадать трафик между подсе-

тями, то есть трафик 10.1.0.0/16 10.2.0.0/16. Но следующие типы трафиков в туннель попадать

не будут:

• 10.1.0.0/16 11.2.0.1 ;

• 11.1.0.1 10.2.0.0/16 ;

• 11.1.0.1 11.2.0.1 .

Если необходимо, чтобы данный трафик тоже попадал в туннель, то нужно настроить допол-

нительные соединения соответственно типов «подсеть-точка», «точка-подсеть», «точка-точка».

Это можно сделать, например, с помощью копирования соединений.

Дополнительная настройка Dionis1:

(config)# crypto ike copy conn t1 to t1−net−host

(config)# crypto ike conn t1−net−host

(config−ike−conn−t1−net−host)# no remote subnet

(config−ike−conn−t1−net−host)# crypto ike enable conn t1−net−host

(config)# crypto ike copy conn t1 to t1−host−net

(config)# crypto ike conn t1−host−net

(config−ike−conn−t1−host−net)# no local subnet

(config−ike−conn−t1−host−net)# crypto ike enable conn t1−host−net

(config)# crypto ike copy conn t1 to t1−host−host

(config−ike−conn−t1−host−host)# no local subnet

(config−ike−conn−t1−host−host)# no remote subnet

(config−ike−conn−t1−host−host)# crypto ike enable conn t1−host−host

(config)# _

Дополнительная настройка Dionis2:

(config)# crypto ike copy conn t1 to t1−net−host

(config)# crypto ike conn t1−net−host

(config−ike−conn−t1−net−host)# no local subnet

(config−ike−conn−t1−net−host)# crypto ike enable conn t1−net−host

(config)# crypto ike copy conn t1 to t1−host−net

(config)# crypto ike conn t1−host−net

(config−ike−conn−t1−host−net)# no remote subnet

(config−ike−conn−t1−host−net)# crypto ike enable conn t1−host−net

(config)# crypto ike copy conn t1 to t1−host−host

(config−ike−conn−t1−host−host)# no local subnet

(config−ike−conn−t1−host−host)# no remote subnet

(config−ike−conn−t1−host−host)# crypto ike enable conn t1−host−host

(config)# _

В данном примере создаётся ещё 3 соединения путём копирования. Чтобы эти соединения ста-

ли типа «подсеть-точка», «точка-подсеть» и «точка-точка», из них удаляются соответствующие

опции «local/remote subnet» с помощью команд «no».

449

43.5.12

Динамическое разрешение IP-адресов

Бывают ситуации, когда IP-адреса концов туннеля (задаваемые опциями «local ip» и «remote

ip») заранее неизвестны или могут меняться. Например, адрес локального конца туннеля назна-

чается через протокол DHCP, а адрес удалённого конца неизвестен, но известно доменное имя

оппонента. В этих случаях опции «local ip» и/или «remote ip» можно задавать в следующем виде:

(config)# crypto ike conn <имя_соединения>

(config-ike-conn-<имя>)# local ip from <сетевой_интерфейс>

(config-ike-conn-<имя>)# remote ip <доменное_имя>

В этом случае при активации командой «crypto ike enable conn» соединение перейдёт в со-

стояние «unresolved» до тех пор, пока не выяснятся конкретные IP-адреса для «local/remote ip».

Попытка разрешить адреса будет повторяться каждые 10 секунд. При успешном разрешении ад-

ресов соединение перейдёт в соответствующее состояние («listen»/«routed»/«online») в зависи-

мости от настройки «auto».

Следует отметить, что после удачного разрешения адресов нового разрешения производиться

не будет. И если IP-адреса изменятся, то соединение прервётся и будет оставаться в состояниях

«listen» или «pending». Для повторного разрешения адресов необходимо выключить и заново

включить соединение с помощью команд режима конфигурации:

(config)# crypto ike disable conn <имя>

(config)# crypto ike enable conn <имя>

См. также «remote ip *» в разделе «Соединения «клиенты-сервер».

43.5.13

Соединения “клиенты-сервер”

43.5.13.1

Шаблонные соединения

В некоторых настройках соединения допустимо использование шаблонов (символ «*»). В этом

случае узел может быть только ответчиком (сервером), и самостоятельная инициация соединения

становится невозможной.

При использовании шаблонов становится возможным установление соединений типа «клиент-

сервер» сразу со множеством клиентов. В этом случае порождается несколько соединений из

одного, и команда просмотра состояния соединения выдаст информацию о порождённых соеди-

нениях, помеченных индексом. Например:

# show crypto ike conn t1

[1] online

[2] online

[3] pending2

В этом случае команда «crypto ike close conn» закроет сразу все порождённые соединения:

# crypto ike close conn t1

# show crypto ike conn t1

listen

Руководство по настройке ПО на базе операционной системы Dionis NX C 1.2-10 Hand UTM (2015 год) - часть 9