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

 

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

 

поиск по сайту            правообладателям  

 

   

 

    

 

содержание      ..     8      9      10      11     ..

 

 

 

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

 

 

450
43.5.13.2
Шаблон IP-адреса клиента
Следующая опция позволяет устанавливать туннель с любого IP-адреса:
(config-ike-conn-<имя>)# remote ip *
43.5.13.3
Шаблон X500-имени клиента
Существует возможность задавать шаблон в X500-имени клиентов. Например:
(config-ike-conn-<имя>)# remote id ”CN=*, O=Хорошая организация, C=RU”
В данном примере любой клиент из «Хорошей организации» может инициировать соединение.
Допускается задавать несколько «*», например:
(config-ike-conn-<имя>)# remote id ”CN=*, O=*, C=RU”
Примечание: Символ «*» распознаётся как шаблон, если больше нет никаких других симво-
лов после «=» в паре «параметр=значение». То есть следующая конструкция воспримется как
конкретное X500-имя, содержащее «*», но не как шаблон:
CN=Клиент*, O=Хорошая организация, C=RU
Также допускается использовать глобальный шаблон в «remote id» (но только в сочетании с
«remote ip *»):
(config-ike-conn-<имя>)# remote id *
(config-ike-conn-<имя>)# remote ip *
В данном примере разрешается установление соединений с любых IP-адресов для любых кли-
ентов, чьи сертификаты выпущены доверяемыми УЦ.
43.5.13.4
“Уникальные” клиенты
По умолчанию в службе IKE действует глобальная настройка «unique ids»:
(config)# crypto ike config
(config−ike)# unique ids
При включённой настройке «unique ids» происходит автоматическое закрытие старых соеди-
нений, если оппонент с тем же самым X500-именем инициировал новое соединение с другого
IP-адреса. То есть соблюдается правило «уникальности» оппонентов: один оппонент может од-
новременно соединяться только с одного IP. Такая настройка является полезной для мобильных
клиентов, чтобы избежать множества «висячих» соединений.
Если требуется разрешить подключаться одному субъекту одновременно с нескольких IP, то
данную настройку можно отключить:
(config−ike)# no unique ids
451
43.5.13.5
Шаблон клиентских правил отбора
Иногда бывают ситуации, когда серверу заранее неизвестны точный адрес и точная маска
защищаемой подсети клиента. В этом случае можно указать неточный адрес удалённой подсети
с меньшей маской. Это делается с помощью опции режима конфигурации соединения:
(config-ike-conn-<имя>)# remote subnet within <ip/mask>
В этом случае удалённая подсеть будет «уточнена» при установлении соединения от конкрет-
ного клиента. Также эта опция необходима, когда требуется принимать соединения от нескольких
клиентов, защищающих свои внутренние подсети.
Пример:
Допустим, нескольким филиалам требуется подключаться к центральному серверу. Точное
количество филиалов неизвестно заранее. Есть договорённость, что внутренние сети филиалов
должны иметь префикс 10.0.0.0/8. Например, подсеть филиала 1 - 10.1.0.0/16, подсеть фили-
ала 2 - 10.2.0.0/16 и т.д. Также есть договорённость, что X500-имена криптомаршрутизаторов
филиалов должны соответствовать шаблону «CN=Шлюз, OU=<название_филиала>, O=Хорошая
организация, C=RU».
Настройка центрального сервера:
(config)# crypto ike conn filialy
(config−ike−conn−filialy)# local ip 11.1.0.1
(config−ike−conn−filialy)# local subnet 11.2.0.0/16
(config−ike−conn−filialy)# local cert mycert.cer
(config−ike−conn−filialy)# remote ip *
(config−ike−conn−filialy)# remote id ”CN=Шлюз, OU=*, O=Хорошая организация, C=RU”.
(config−ike−conn−filialy)# remote subnet within 10.0.0.0/8
43.5.13.6
Мобильные клиенты с внутренним IP-адресом
Для мобильных клиентов может быть полезна возможность создания виртуального внутренне-
го адреса при соединении с сервером по IPsec. В этом случае клиент не потеряет связь с Интер-
нетом, потому что трафик, не попадающий в туннель, будет отправляться с основного IP-адреса
клиента. А трафик, предназначенный для туннеля, - с виртуального. Если клиентом является
DionisNX, то виртуальный адрес назначается интерфейсу как вторичный IP, и инсталлируются спе-
циальные правила маршрутизации, отправляющие трафик, предназначенный для туннеля, через
виртуальный адрес.
Виртуальные адреса управляются с помощью опций «local source ip» на стороне клиента, и
«remote source ip» на стороне сервера.
43.5.13.7
Пример 1. Клиент предлагает серверу собственный виртуальный адрес
Настройка клиента:
crypto ike conn office−vpn
local ip 192.168.1.1
remote ip 192.168.2.1
452
local cert client.cer
remote id ”CN=Сервер доступа, O=Хорошая организация, C=RU”
local source ip 10.0.0.1 next−hop 192.168.1.100
remote subnet 10.2.0.0/16
Настройка сервера:
crypto ike conn office−vpn
local ip 192.168.2.1
remote ip *
local cert server.cer
remote id ”CN=*, O=Хорошая организация, C=RU”
local subnet 10.2.0.0/16
remote subnet within 10.0.0.0/16
В данном примере клиент предлагает серверу свой виртуальный адрес 10.0.0.1. Сервер при-
мет предложение, потому что виртуальный адрес клиента попадает в допустимый диапазон, уста-
новленный опцией «remote subnet within 10.0.0.0/16».
При использовании опции «local source ip» необходимо указывать адрес непосредственного
следующего маршрутизатора (next hop). Можно указать либо конкретный IP-адрес, либо опцию
«default-route», если в системе существует маршрут по умолчанию, и он подходит для данного
IPsec-траффика.
43.5.13.8
Пример 2. Сервер назначает клиенту виртуальный адрес (режим ModeConfig)
Настройка клиента:
crypto ike conn office−vpn
local ip 192.168.1.1
remote ip 192.168.2.1
local cert client.cer
remote id ”CN=Сервер доступа, O=Хорошая организация, C=RU”
local source ip modeconfig next−hop default−route
remote subnet 10.2.0.0/16
Настройка сервера:
crypto ike conn office−vpn
local ip 192.168.2.1
remote ip *
local cert server.cer
remote id ”CN=Иванов Иван Иванович, O=Хорошая организация, C=RU”
local subnet 10.2.0.0/16
remote source ip 10.0.0.1
В данном примере у клиента действует настройка «local source ip modeconfig», которая означа-
ет, что клиент ожидает назначения виртуального адреса сервером (с помощью фазы ModeConfig).
Опция сервера «remote source ip 10.0.0.1» предписывает назначить клиенту виртуальный адрес
10.0.0.1.
453
43.5.13.9
Пример 3. Сервер назначает клиентам виртуальные адреса из пула (режим
ModeConfig)
Также реализована возможность назначения разных адресов разным клиентам из пула.
Настройка сервера:
crypto ike conn office−vpn
local ip 192.168.2.1
remote ip *
local cert server.cer
remote id ”CN=*, O=Хорошая организация, C=RU”
local subnet 10.2.0.0/16
remote source ip 10.0.0.0/24
В данном примере опция «remote source ip 10.0.0.0/24» создаёт пул адресов от 10.0.0.1 до
10.0.0.254. Каждому новому подключающемуся клиенту будет назначаться свой виртуальный ад-
рес.
Просмотреть состояние пула(ов) можно с помощью команды режима enable:
# show crypto ike pool [<имя_соединения>]
Удалить опции «local/remote source ip» из конфигурации соединения можно с помощью соот-
ветствующих команд «no».
43.5.13.10
Уведомление мобильного клиента о внутреннем DNS-сервере
В примерах 2 и 3 сервер может передавать мобильным клиентам адреса внутренних DNS-
серверов. Для этого на стороне сервера необходимо указать опцию:
crypto ike conn office−vpn
modeconfig dns <DNS_IP_1> [<DNS_IP_2>]
ПРИМЕЧАНИЕ: Возможность передачи внутренних адресов DNS предназначена для мобильных
Windows-клиентов DiSEC. Если мобильным клиентом является DionisNX, то он игнорирует адреса
DNS, присланные сервером.
43.5.14
Соединения через NAT
Если предполагается, что IPsec-туннель будет проходить через маршрутизаторы, выполняю-
щие трансляцию адресов (NAT), то на обоих концах туннеля необходимо включить поддержку
механизма NAT Traversal (RFC3947). Это делается с помощью опции службы IKE:
(config)# crypto ike config
(config−ike)# nat traversal
По умолчанию NAT Traversal отключён, что равносильно опции:
(config−ike)# no nat traversal
454
Как было описано выше, если возникает ситуация «IPsec через NAT», IKE-обмен происходит
следующим образом:
• Первая фаза начинается стандартно - через UDP/500;
• После обмена 2-м и 3-м пакетами оппоненты определяют наличие NAT;
• Весь последующий IKE-обмен ведётся через UDP/4500;
• Протокол ESP инкапсулируется также в UDP/4500 (RFC3948).
При использовании «IPsec через NAT» ACL-фильтры должны быть настроены таким образом,
чтобы пропускать трафик UDP/4500. При этом следует учитывать, что порт оппонента может быть
любым (из-за NAT).
Для поддержания соединения через NAT оппоненты периодически посылают друг другу спе-
циальные пакеты «Keep Alive». Интервал по умолчанию - 20 с. Если требуется изменить это зна-
чение, то это можно сделать с помощью опции:
(config)# crypto ike config
(config−ike)# nat keep−alive interval <secs>
«IPsec через NAT» возможен только при выполнении следующих условий:
• Используется туннельный режим ESP. Транспортный режим отключён из-за проблем с без-
опасностью;
• Если оппонент находится за NAT, то опция «remote ip» для данного узла должна быть «*»;
• Если оппонент находится за NAT, то на данном узле необходимо наличие одной из оп-
ций: «remote subnet [within]» (для «подсеть-клиент==NAT==сервер-…»), «remote source
ip» (для «клиент==NAT==сервер-…»);
• Если используется аутентификация по pre-shared ключам (не рекомендуется), то на узле,
противоположном оппоненту, и находящимся за NAT, необходимо ассоциировать PSK с «*»
(совпадает с опцией «remote ip *»).
Примечание: Если предполагается использование NAT Traversal совместно с режимом
ModeConfig (выделение адресов клиентам из пула), то также настоятельно рекомендуется исполь-
зование механизма Dead Peer Detection (см. раздел «Продление и закрытие туннелей. Таймеры»)
со стороны сервера для избежания истощения пула в случае обрывов связи.
43.5.15
Принудительная инкапсуляция ESP в UDP
Иногда бывает необходимо инкапсулировать ESP-трафик в UDP, даже если NAT не присутству-
ет. Для этого необходимо на стороне инициатора в настройках соединения указать опцию:
(config)# crypto ike conn t1
(config−ike−conn−t1)# udp encap force
Также необходимо, чтобы на стороне ответчика и инициатора была включена поддержка NAT
Traversal:
455
(config)# crypto ike config
(config−ike)# nat traversal
Примечание: Для инициации принудительной инкапсуляции в UDP достаточно, чтобы опция
«udp encap force» была указана хотя бы у одного из оппонентов (желательно, у инициатора).
Если она указана на стороне ответчика, то во избежание ложных срабатываний/несрабатываний
данная опция должна быть также указана для всех остальных соединений между данными
оппонентами (если таких соединений несколько).
Отключение принудительной инкапсуляции осуществляется командой:
(config−ike−conn−t1)# no udp encap force
ВАЖНО: В текущей реализации
опция принудительной инкапсуляции в UDP рабо-
тает корректно только для соединений типа «клиент-сервер». То есть на стороне сервера обяза-
тельно должна присутствовать опция «remote ip *».
43.5.16
Отбор трафика по протоколу и порту
В предыдущих примерах в туннель попадал трафик любых протоколов
(кроме IKE
-
UDP/500/4500).
Если необходимо направлять в туннель трафик определённого протокола, то следует указать
опции «local protoport» и «remote protoport» на обоих сторонах. Например:
(config)# crypto ike conn t1
(config−ike−conn−t1)# local protoport ospf
(config−ike−conn−t1)# remote protoport ospf
Протоколы для «local» и «remote» должны совпадать. Также протоколы можно указывать по
номеру:
(config)# crypto ike conn t1
(config−ike−conn−t1)# local protoport 89
(config−ike−conn−t1)# remote protoport 89
Для протоколов TCP и UDP можно указывать порты. В этом случае в туннель будет попадать
трафик определённого порта. Порты для «local/remote» могут не совпадать, но настройки на
концах должны быть симметричны. (См. раздел «Базовые понятия протокола IKE, Фаза 2»).
Пример (настройка web-доступа через IPsec):
Сервер:
local protoport tcp/80
remote protoport tcp
Клиенты:
local protoport tcp
remote protoport tcp/80
В данном примере в IPsec-туннель будет попадать только web-трафик.
Удалить опции «local/remote protoport» из конфигурации соединения можно с помощью соот-
ветствующих команд «no».
456
43.5.17
Исключение трафика из туннеля
Иногда возникает необходимость исключить часть трафика из IPsec-туннеля.
Для этого можно воспользоваться командой «exceptions» в режиме конфигурации соединения.
(config)# crypto ike conn t1
(config−ike−conn−t1)# exceptions
(config−ike−conn−t1−exc)# _
Данная команда вводит консоль в режим редактирования правил исключений.
Добавить/вставить правило можно с помощью команды:
[<n>] deny [<протокол>] [src <локальная_подсеть>] [dst <удалённая_подсеть>] [sport
<локальный_порт> [<локальный_порт2>]] [dport <удалённый_порт>
[<удалённый_порт2>]]
Команда «deny» исключает определённый вид трафика из туннеля. Параметры команды:
<n> - номер позиции, куда должно быть вставлено правило. Если правило с таким номером
уже существует, то оно сдвигается вниз. Если <n> не указан - правило добавляется в конец
списка;
<протокол> - номер или название IP-протокола. Если указан, исключается трафик только
данного протокола;
<локальная_подсеть> - IP-адрес/маска диапазона локальной подсети. Если адрес отправи-
теля исходящего трафика (адрес получателя входящего трафика) попадает в данный диапазон,
трафик исключается из туннеля;
<удалённая_подсеть> - IP-адрес/маска диапазона удалённой подсети. Если адрес получате-
ля исходящего трафика (адрес отправителя входящего трафика) попадает в данный диапазон,
трафик исключается из туннеля;
<локальный_порт> - (только для TCP/UDP). Исключается только трафик указанного порта
(для исходящего - порт отправителя, для входящего - порт получателя);
<локальный_порт2> - если указан, то исключается трафик для диапазона портов - от <ло-
кальный_порт> до <локальный_порт2>;
<удалённый_порт> - (только для TCP/UDP). Исключается только трафик указанного порта
(для исходящего - порт получателя, для входящего - порт отправителя);
<удалённый_порт2> - если указан, то исключается трафик для диапазона портов - от <уда-
лённый_порт> до <удалённый_порт2>.
Добавляемому правилу присваивается номер. Просмотреть номера правил можно с помощью
команды «do show» из режима редактирования исключений:
(config−ike−conn−t1−exc)# do show
1 deny tcp src 192.168.1.0/24 dst 192.168.2.1/32 dport 80
2 deny src 192.168.1.24/29
(config−ike−conn−t1−exc)# _
Удалить правило можно с помощью команды «no <номер>». Оставшиеся правила перенуме-
ровываются. Удалить все правила можно с помощью команды «no all».
457
Чтобы выключить режим исключения трафика из туннеля и удалить все исключающие прави-
ла, нужно выполнить команду режима конфигурации соединения:
(config-ike-conn-имя)# no exceptions
43.5.18
Настройка криптопараметров
Как было сказано выше, на IKE-фазе 1 происходит согласование криптографических пара-
метров, определяющих способ шифрования и проверки подлинности пакетов IKE. А на фазе 2
происходит согласование криптографических параметров протокола ESP.
43.5.18.1
Значения по умолчанию
По умолчанию действуют следующие значения:
Криптопараметры IKE:
Предлагается 1 набор криптопараметров;
Шифрование и имитовставка: Алгоритм ГОСТ 28147-89, режим GOST-CFB-IMIT, узел замены
CryptoPro Set B;
Выработка общего секрета: Алгоритм ГОСТ Р 34.10-2001, режим VKO, параметры CryptoPro
Set XchB;
Политика выбора набора криптопараметров: строгая;
Режим Perfect Forward Secrecy (PFS): предлагать PFS, принимать любой.
Криптопараметры ESP:
Предлагается 1 набор криптопараметров;
Шифрование и имитовставка: Алгоритм ГОСТ 28147-89, режим GOST-4M-IMIT, узел замены
CryptoPro Set B;
Политика выбора набора криптопараметров: строгая.
43.5.18.2
Настройка и согласование криптопараметров. “Строгость” политики согласо-
вания
Согласование криптопараметров происходит следующим образом:
1. Инициатор соединения предлагает один или несколько наборов криптопараметров (сорти-
рованных по приоритету);
2. Ответчик анализирует предложения (proposals), выбирает первое подходящее и уведомля-
ет инициатора о выборе;
3. Если ничего не выбрано, соединение отвергается.
458
В настройках соединения можно явно задать предлагаемые наборы и их последовательность в
предложениях с помощью команд «ph1 transforms» (криптопараметры для IKE) и «ph2 transforms»
(криптопараметры для ESP). Для ответчика различаются две политики выбора набора предлага-
емых криптопараметров: строгая и нестрогая. При нестрогой политике выбирается первый по-
павшийся набор, который поддерживается системой IPsec ответчика (то есть любой, если оба
оппонента - узлы
). При строгой политике выбирается первый попавшийся набор, кото-
рый присутствует в списке наборов, заданном командой «ph1/ph2 transforms».
Чтобы войти в режим редактирования списка предлагаемых наборов криптопараметров IKE,
нужно ввести команду «ph1 transforms» в режиме конфигурации соединения:
(config)# crypto ike conn t1
(config−ike−conn−t1)# ph1 transforms
(config−ike−conn−t1−ph1)# _
Если необходимо выключить строгую политику выбора, то следует указать опцию:
(config−ike−conn−t1−ph1)# no strict
Строгая политика включается противоположной опцией:
(config−ike−conn−t1−ph1)# strict
Для добавления набора криптопараметров IKE выполняется команда «add». Очередной набор
всегда добавляется в конец списка.
43.5.18.3
Криптопараметры фазы 1
Формат команды «add» для «ph1 transforms»:
add <алгоритм_шифрования> <алгоритм_выработки_общего_секрета>
Возможные алгоритмы шифрования:
gost89-a
Алгоритм ГОСТ 28147-89, режим GOST-CFB-IMIT, узел замены CryptoPro Set A
gost89-b
Алгоритм ГОСТ 28147-89, режим GOST-CFB-IMIT, узел замены CryptoPro Set B
gost89-c
Алгоритм ГОСТ 28147-89, режим GOST-CFB-IMIT, узел замены CryptoPro Set C
gost89-d
Алгоритм ГОСТ 28147-89, режим GOST-CFB-IMIT, узел замены CryptoPro Set D
gost89-z
Алгоритм ГОСТ 28147-89, режим GOST-CFB-IMIT, узел замены CryptoPro Set Z
Возможные алгоритмы выработки общего секрета:
gost2001-vko-a
Алгоритм ГОСТ Р 34.10-2001, режим VKO, па-
раметры CryptoPro Set XchA
gost2001-vko-b
Алгоритм ГОСТ Р 34.10-2001, режим VKO, па-
раметры CryptoPro Set XchB
gost2012-256-vko-a
Алгоритм ГОСТ Р 34.10-2012 (256 бит), режим
VKO, параметры CryptoPro Set XchA
gost2012-256-vko-b
Алгоритм ГОСТ Р 34.10-2012 (256 бит), режим
VKO, параметры CryptoPro Set XchB
gost2012-512-vko-a
Алгоритм ГОСТ Р 34.10-2012 (512 бит), режим
VKO (с выходом 256 бит), параметры TC26A
459
gost2012-512-vko-b
Алгоритм ГОСТ Р 34.10-2012 (512 бит), режим
VKO (с выходом 256 бит), параметры TC26B
Пример:
(config−ike−conn−t1−ph1)# add gost89−a gost2001−vko−b
(config−ike−conn−t1−ph1)# add gost89−d gost2001−vko−a
Чтобы очистить список наборов и вернуть значение по умолчанию, следует выполнить коман-
ду:
(config−ike−conn−t1)# no ph1 transforms
ПРИМЕЧАНИЕ: При настройке криптопараметров фазы 1 следует учитывать требования, опи-
санные в разделе «Особенности настройки некоторых параметров фазы 1» (см. ниже).
ПРИМЕЧАНИЕ: На фазе 1 также согласуется функция хэширования (ГОСТ Р 34.11-94, ГОСТ
Р 34.11-2012 512 бит). Согласуемый тип функции зависит от алгоритма открытого ключа серти-
фиката, указанного в настройке “local cert”. Если алгоритм ключа - ГОСТ Р 34.10-2001, то ини-
циатором предлагается (ответчиком допускается) только одна хэш-функция - ГОСТ Р 34.11-94.
Если алгоритм ключа - ГОСТ Р 34.10-2012, то инициатором предлагаются (ответчиком допускают-
ся) обе хэш-функции (функция ГОСТ Р 34.11-2012 (512 бит) имеет больший приоритет). В этом
случае инициатор дублирует все пропоузалы. В режиме PSK всегда согласуются оба типа хэша.
Также вне зависимости от опции “strict” алгоритмы хэш-функций сравниваются всегда по строгой
политике.
43.5.18.4
Криптопараметры фазы 2
Наборы криптопараметров ESP и политика выбора настраиваются аналогично с помощью ко-
манды «ph2 transforms»:
(config)# crypto ike conn t1
(config−ike−conn−t1)# ph2 transforms
(config−ike−conn−t1−ph2)# add <алгоритм_шифрования> [esn]
Возможные алгоритмы шифрования для ESP:
gost89-4m-imit-a
Алгоритм ГОСТ 28147-89, режим GOST-4M-
IMIT, узел замены CryptoPro Set A
gost89-4m-imit-b
Алгоритм ГОСТ 28147-89, режим GOST-4M-
IMIT, узел замены CryptoPro Set B
gost89-4m-imit-c
Алгоритм ГОСТ 28147-89, режим GOST-4M-
IMIT, узел замены CryptoPro Set C
gost89-4m-imit-d
Алгоритм ГОСТ 28147-89, режим GOST-4M-
IMIT, узел замены CryptoPro Set D
gost89-4m-imit-z
Алгоритм ГОСТ 28147-89, режим GOST-4M-
IMIT, узел замены CryptoPro Set Z
gost89-1k-imit-a
Алгоритм ГОСТ
28147-89, режим GOST-1K-
IMIT, узел замены CryptoPro Set A
460
gost89-1k-imit-b
Алгоритм ГОСТ
28147-89, режим GOST-1K-
IMIT, узел замены CryptoPro Set B
gost89-1k-imit-c
Алгоритм ГОСТ
28147-89, режим GOST-1K-
IMIT, узел замены CryptoPro Set C
gost89-1k-imit-d
Алгоритм ГОСТ
28147-89, режим GOST-1K-
IMIT, узел замены CryptoPro Set D
gost89-1k-imit-z
Алгоритм ГОСТ
28147-89, режим GOST-1K-
IMIT, узел замены CryptoPro Set Z
Если указан параметр «esn», то для данного алгоритма будет согласовываться режим 64-
разрядного счётчика пакетов (Extended Sequence Numbers, RFC4304). Также возможно ввести
оба варианта для одного алгоритма - с ESN и без. Например:
(config−ike−conn−t1)# ph2 transforms
(config−ike−conn−t1−ph2)# add gost89−1k−imit−b esn
(config−ike−conn−t1−ph2)# add gost89−1k−imit−b
43.5.18.5
Perfect Forward Secrecy
Для выработки более криптостойкого ключевого материала при использовании протокола ESP
на фазе 2 инициатор и ответчик могут обменяться дополнительными временными открытыми клю-
чами (KEi, KEr) и сформировать дополнительный общий секрет. Данный режим называется режи-
мом совершенной прямой секретности (Perfect Forward Secrecy) и может настраиваться командой
«pfs mode» в режиме конфигурации соединения.
По умолчанию действует режим:
(config-ike-conn-<имя>)# pfs mode propose
Если данный режим включён на узле, выступающем в роли инициатора, то он передаёт KEi на
фазе 2, инициируя тем самым режим PFS. Если данный режим включён на ответчике, то последний
поддерживает оба режима (PFS и Non-PFS) и делает выбор в зависимости от того, прислал ли
инициатор KEi или нет.
В режиме
(config-ike-conn-<имя>)# pfs mode off
инициатор не передаёт KEi, инициируя тем самым режим Non-PFS. Ответчик может принимать
оба режима.
Режим Non-PFS можно запретить опцией:
(config-ike-conn-<имя>)# pfs mode force
В этом случае и инициатор, и ответчик будут работать только в режиме PFS, причём опция
«pfs mode force» должна быть включена у обоих оппонентов для успешного согласования фазы
1. (Согласуется атрибут «PFS Control - Disable Non-PFS»).
В таблице представлено поведение при согласовании PFS в зависимости от опции «pfs mode»
на инициаторе (I) и ответчике (R):
461
I\R
off
propose
force
off
Non-PFS
Non-PFS
Отказ
propose
PFS
PFS
Отказ
force
Отказ
Отказ
PFS
ПРИМЕЧАНИЕ: При настройке параметра «pfs mode» следует учитывать требования, описан-
ные в разделе «Особенности настройки некоторых параметров фазы 1» (см. ниже).
По умолчанию при согласовании дополнительного общего секрета используются криптопара-
метры фазы 1. Если требуется их изменить, то это можно сделать командой:
(config-ike-conn-<имя>)# pfs group <алгоритм_выработки_общего_секрета>
Если у ответчика действует режимы «ph2 transforms; strict» и «pfs mode propose/force», а
также указана «pfs group», то для успешного согласования параметров инициатор должен пред-
ложить именно эту группу VKO. Во всех остальных случаях ответчик примет любую (им поддер-
живаемую) группу VKO, предложенную инициатором, а настройка «pfs group» будет иметь смысл
только на стороне инициатора.
43.5.18.6
Максимальное количество фаз 2 из одной фазы 1
Из одной фазы 1 может быть порождено несколько фаз 2. Существует криптографическое
ограничение на количество таких фаз 2. (В данном случае «фазой 2» также считается посылка
каждого уведомительного сообщения). При режиме «pfs mode force» - максимальное количество
фаз 2 - 65536. При режиме «pfs mode off/propose» - 16384. Если необходимо ещё уменьшить
данный предел, то это можно сделать с помощью опции:
(config-ike-conn-<имя>)# ph2 max <n>
Согласование значений «ph2 max» между оппонентами происходит по следующим правилам:
• Если инициатор не пересылает ответчику атрибут «Max-messages», ответчик использует
своё значение (без уведомления инициатора);
• Если значение, пересылаемое инициатором, меньше значения ответчика, обе стороны ис-
пользуют значения инициатора;
• Если значение, пересылаемое инициатором, больше значения ответчика, то ответчик ис-
пользует своё (меньшее) значение БЕЗ уведомления инициатора. Инициатор использует
своё значение.
Рекомендуются одинаковые настройки «ph2 max» на обеих сторонах.
ПРИМЕЧАНИЕ: При настройке параметра «ph2 max» следует учитывать требования, описан-
ные в разделе «Особенности настройки некоторых параметров фазы 1» (см. ниже).
43.5.18.7
Максимально допустимое количество ESP-пакетов с неправильной контроль-
ной суммой
Как было сказано выше, если ESP-пакет не прошёл проверку подлинности (не совпала кон-
трольная сумма ICV), то он отбрасывается. По умолчанию узел
готов принимать любой
462
«правильный» пакет (с учётом replay-окна), несмотря на количество предыдущих «неправиль-
ных». Существует вероятность «brute-force»-подбора злоумышленником контрольной суммы ICV.
Чтобы от этого защититься, можно согласовать с оппонентом атрибут «Max-Integrity-Fails». Он
представляет собой максимальное число принятых пакетов ESP с неправильной контрольной сум-
мой ICV (но с правильным значением IVCounter - см. стандарт IPsec от «Крипто-Про»). При пре-
вышении данного числа криптоконтекст SA будет удалён и, в случае включённой опции «rekey»,
инициирован новый. (Опцию «rekey» см. ниже).
Включить данное ограничение можно с помощью опции:
(config-ike-conn-<имя>)# esp max icv fails <n> margin <m>
где n - максимальное количество «неправильных» пакетов, при превышении которого крип-
токонтекст будет удалён; m - «отступ» заблаговременного инициирования нового туннеля (при
включённой опции «rekey»). Инициация нового туннеля начнётся при достижении счётчика
«неправильных» пакетов значения (n - m + 1). Старый туннель будет закрыт согласно настройкам
«ph margin …» (см. ниже).
Отключить опцию можно с помощью команды:
(config-ike-conn-<имя>)# no esp max icv fails
ВНИМАНИЕ: Включение данного ограничения хотя и повышает криптостойкость, но одновре-
менно даёт возможность злоумышленнику организовать DoS-атаку. Злоумышленнику достаточно
прослушать хотя бы один «правильный» ESP-пакет, чтобы сгенерировать (n + 1) «неправильных»
пакетов, вызвав тем самым удаление криптоконтекста. Слушая ESP-трафик, злоумышленник мо-
жет вызвать многократную переустановку туннеля.
Согласование атрибута «Max-Integrity-Fails» происходит по следующим правилам:
• Инициатор передаёт ответчику только значение «n» (см. выше). Значение «m» не переда-
ётся;
• Если инициатор не согласует атрибут, то инициатор не использует ограничение «неправиль-
ных» пакетов. Ответчик может использовать ограничение без уведомления инициатора;
• Если инициатор согласует атрибут, а у ответчика ограничение не настроено, ответчик будет
использовать значение «n» от инициатора и m=0;
• Если значение «n» инициатора меньше значения «n» ответчика, ответчик будет использо-
вать значение «n» от инициатора. Значение «m» ответчика будет пропорционально умень-
шено;
• Если значение «n» инициатора больше значения «n» ответчика, ответчик будет использо-
вать собственные значения «n» и «m» без уведомления инициатора.
Рекомендуются одинаковые настройки «esp max icv fails» на обеих сторонах.
43.5.19
Продление и закрытие туннелей. Таймеры
43.5.19.1
Времена жизни туннелей/фаз IKE
Установленные фазы 1 и 2 имеют определенные времена жизни. По умолчанию время жизни
фазы 1 - 3 часа, фазы 2 - 1 час.
463
Изменить время жизни фазы 1 можно командой конфигурации соединения:
(config-ike-conn-<имя>)# ph1 life time <секунды>
ПРИМЕЧАНИЕ: При настройке параметра «ph1 life time» следует учитывать требования, опи-
санные в разделе «Особенности настройки некоторых параметров фазы 1» (см. ниже).
Изменить время жизни фазы 2 можно командой:
(config-ike-conn-<имя>)# ph2 life time <секунды>
Время жизни фазы 2 эквивалентно времени жизни текущего криптоконтекста туннеля (SA).
43.5.19.2
Продление туннелей
По умолчанию для соединения действует настройка:
(config-ike-conn-<имя>)# rekey
Для этой настройки при истечении времени жизни фазы 2 будет произведена попытка уста-
новить новую фазу 2 из существующей фазы 1. Если истекает время жизни фазы 1, то будет
произведена попытка установления новой фазы 1 и затем новой фазы 2. Таким образом настрой-
ка «rekey» означает продление туннеля.
Если продление туннеля не требуется, то его можно отключить опцией:
(config-ike-conn-<имя>)# no rekey
Данная опция полезна для серверов, потому что обязанность поддерживать соединения обыч-
но возлагается на клиентов. Если клиент не продлит соединение, то оно будет закрыто.
43.5.19.3
Заблаговременное установление нового туннеля
При продлении соединения, чтобы связь по туннелю не прерывалась, осуществляется забла-
говременное установление нового криптоконтекста SA еще до истечения времени жизни старого.
Данный временной отступ контролируется опциями:
(config-ike-conn-<имя>)# ph margin time <секунды>
(config-ike-conn-<имя>)# ph margin fuzz <проценты>
Для инициатора временной отступ от момента истечения времени жизни старого туннеля вы-
числяется по формуле: margin_time * (1 + rnd(0..margin_fuzz) / 100). Привнесение случайной
составляющей помогает избежать пиков трафика, если одновременно переустанавливается боль-
шое количество туннелей.
Для ответчика временной отступ вычисляется по формуле: margin_time / 2. Настройка «ph
margin fuzz» в этом случае не влияет.
ПРИМЕЧАНИЕ: Опции «ph margin …» являются общими для первой и второй фазы IKE. То есть
первая фаза будет также заблаговременно продлена согласно вышеприведённым формулам.
По умолчанию действуют значения:
ph margin time 540 (9 минут)
ph margin fuzz 100
464
ВНИМАНИЕ: Для обеспечения стабильного продления туннелей (без временных потерь свя-
зи) рекомендуется использовать одинаковые значения опций «ph1/2 life time», «ph margin
time», «ph margin fuzz» на стороне инициатора и на стороне ответчика. Средствами IKE согла-
суются только «ph1/2 life time», причём только в одну сторону (инициатор ￿ ответчик). То есть
ответчик может уменьшить своё значение «life time» согласно значению от инициатора, но ини-
циатор никогда не уменьшит своё, так как ответчик его не уведомляет о своих значениях «life
time». Значения «ph margin time/fuzz» не согласуются вообще.
ПРИМЕЧАНИЕ: При настройке параметров «ph margin …» следует учитывать требования, опи-
санные в разделе «Особенности настройки некоторых параметров фазы 1» (см. ниже).
43.5.19.4
Таймеры pending-состояний. Число попыток установления соединений
Если установление (переустановление) соединения не прошло успешно, то оно задерживается
в соответствующем состоянии «pending*», и инициатор пытается повторить попытку установле-
ния через некоторое время. Цикл попыток можно описать следующим образом:
1. Первая посылка пакета;
2. Неудача. Ожидание 10 секунд;
3. Вторая попытка посылки того же пакета;
4. Ожидание 20 секунд;
5. Третья попытка посылки того же пакета;
6. Ожидание 40 секунд;
7. Неудачное завершение цикла.
Предельное количество таких циклов попыток можно определить опцией:
(config-ike-conn-<имя>)# keying tries <n>
Если очередной цикл завершается неудачно, то соединение переводится в состояние
«pending1», и в новом цикле начнётся инициация соединения с самого начала фазы 1. Если все n
циклов завершились неудачно, соединение переводится в соответствующее состояние «routed»
или «listen».
По умолчанию количество циклов не ограничено, что эквивалентно опции:
(config-ike-conn-<имя>)# keying tries forever
Для серверов рекомендуется настройка «keying tries 1».
43.5.19.5
Обнаружение “мёртвых” оппонентов (Dead Peer Detection)
Бывают ситуации, когда соединение установилось успешно, но потом по каким-то причинам
пропала связь с оппонентом. Причины могут быть следующими:
• Временная потеря связи с оппонетом;
• Окончательная (долговременная) потеря связи с оппонетом;
• Аварийная перезагрузка или завершение работы системы оппонента.
465
Во всех этих случаях на одной стороне продолжит существование криптоконтекст SA, и со-
единение будет находиться в состоянии «online», хотя пакеты, направляемые в туннель, будут
пропадать в «чёрную дыру». Если другая сторона утратила свой криптоконтекст окончательно
(без уведомительного сообщения об удалении своего контекста), такая «чёрная дыра» будет
продолжать существовать до истечении времени жизни фазы 2.
Данная ситуация может оказаться неприемлемой, и поэтому для её избежания в службе IKE
реализован механизм обнаружения «умерших» оппонентов (Dead Peer Detection, DPD, RFC 3706).
Суть этого механизма заключается в регулярной посылке специальных сообщений «R_U_THERE»
(«ты здесь?») оппоненту. Если оппонент способен их получить, и он не утратил соответствую-
щий криптоконтекст, то он шлёт ответное подтверждающее сообщение «R_U_THERE_ACK». Если
оппонент не отвечает в течение некоторого времени, то он считается «умершим», и соединение
закрывается (или инициируется вновь - см. ниже).
По умолчанию механизм DPD работает в пассивном режиме. То есть данная сторона не шлёт
«R_U_THERE» оппоненту, но готова ответить на запросы оппонента.
Чтобы активировать DPD, нужно ввести команду режима конфигурации соединения:
(config-ike-conn-<имя>)# dpd
(config-ike-conn-<имя>-dpd)# _
Данная команда переводит консоль в режим редактирования опций DPD.
Опция «action» определяет действие с соединением, когда обнаружено, что оппонент «умер».
Возможные действия:
• close - Перевести соединение в состояние «listen»;
• route - Перевести соединение в состояние «routed»;
• initiate - Пытаться заново установить соединение (из состояния «listen», минуя состяние
«routed»);
• route initiate - Перевести соединение в состояние «routed» и пытаться заново инициировать
соединение.
Опция «interval» позволяет установить интервал посылки сообщений «R_U_THERE» (в секун-
дах).
Опция «timeout» устанавливает предельное время, после которого оппонент считается «умер-
шим», если он не ответил ни на одно сообщение «R_U_THERE».
По умолчанию действуют настройки:
«action» − close
«interval» − 30
«timeout» − 150
43.5.20
Особенности настройки некоторых параметров фазы 1
Настройки IPsec-соединений должны отвечать следующему требованию:
Если существует несколько соединений с одинаковым набором следующих опций:
466
• auth;
• local ip;
• remote ip;
то необходимо, чтобы эти соединения также имели одинаковые наборы следующих опций:
• ph1 transforms;
• ph1 life time;
• ph margin time;
• ph margin fuzz;
• pfs mode;
• ph2 max.
Набор считается одинаковым, если значение каждой опции набора равно значению соответ-
ствующей опции другого набора. Также считается, что «remote ip *» равен только «remote ip *»,
но не равен «remote ip A.B.C.D» (или «remote ip <fqdn>»). Для опции «pfs mode» значения «off»
и «propose» равны друг другу, но не равны значению «force».
Несоблюдение данного требования не позволит активировать соединение.
43.5.21
Обязательный удостоверяющий центр
Как уже было сказано выше, для проверки сертификата используется вся цепочка сертифи-
катов удостоверяющих центров вплоть до корневого. И соединение разрешается только в том
случае, если все сертификаты в цепочке действительны и успешно проверены. Если в систему
установлено, например, несколько корневых сертификатов, и нет договорённости между удосто-
веряющими центрами о единой политике назначения X500-имён субъектам, то может возникнуть
ситуация, когда два разных сертификата, выпущенные разными УЦ, будут иметь одинаковые
X500-имена. И может возникнуть необходимость различать эти сертификаты (например, прини-
мать соединение от одного, но не принимать от другого).
В этом случае можно с помощью опции «remote ca» (в режиме конфигурации соединения) ука-
зать X500-имя удостоверяющего центра, чей сертификат обязательно должен присутствовать в
цепочке сертификатов при проверке.
Например:
(config)# crypto ike conn t1
(config−ike−conn−t1)# remote id ”CN=*, O=Хорошая организация, C=RU”
(config−ike−conn−t1)# remote ca ”CN=УЦ 1, O=Хорошая организация, C=RU”
В данном примере соединения будут приниматься от всех субъектов, чьи сертификаты вы-
пущены удостоверяющим центром №1. Соединения от субъектов, чьи сертификаты выпущены,
например, УЦ №2, приниматься не будут, даже если имена субъектов удовлетворяют указанному
шаблону.
Чтобы не вводить X500-имена удостоверяющих центров вручную, можно их импортировать
непосредственно из сертификатов УЦ. Например:
467
(config−ike−conn−t1)# remote ca from root ca cert ca1.cer
или
(config−ike−conn−t1)# remote ca from ca cert ca2.cer
В первом случае X500-имя импортируется из корневого сертификата «ca1.cer», а во втором
случае - из сертификата промежуточного УЦ «ca2.cer».
43.5.22
Проверка использования сертификата по назначению
Сертификаты X509 могут содержать в себе дополнительные поля «Key Usage» и «Extended Key
Usage», в которых описывается область применения данного сертификата и соответствующего
ему закрытого ключа. Поле «Key Usage» представляет из себя набор предопределённых флагов
(см. RFC5280, п. 4.2.1.3), а поле «Extended Key Usage» может содержать в себе произвольное
количество OID-ов, описывающих область применения сертификата и ключа.
По умолчанию в
проверяются клиентские сертификаты (локальные и присланные
от оппонента) на наличие следующих флагов/OID-oв:
• Флаг digitalSignature;
• Флаг nonRepudiation;
• OID
1.3.6.1.5.5.8.2.2
{iso(1) identified-organization(3) dod(6) internet(1) security(5)
mechanisms(5) ipsec(8) certificate(2) iKEIntermediate(2)}.
Данное поведение можно изменить с помощью настройки проверки области применения. Для
этого необходимо войти в режим конфигурации «cert usage» для соответствующего соединения:
(config)# crypto ike conn t1
(config−ike−conn−t1)# cert usage
(config−ike−conn−t1−cu)# _
В данном режиме можно включать/выключать проверку соответствующих флагов/OID-ов с
помощью команд:
[no] digital-signature
Проверять/не проверять наличие флага digitalSignature
[no] non-repudiation
Проверять/не проверять наличие флага nonRepudiation
[no] key-encipherment
Проверять/не проверять наличие флага keyEncipherment
[no] data-encipherment
Проверять/не проверять наличие флага dataEncipherment
[no] key-agreement
Проверять/не проверять наличие флага keyAgreement
[no] key-cert-sign
Проверять/не проверять наличие флага keyCertSign
[no] crl-sign
Проверять/не проверять наличие флага cRLSign
[no] encipher-only
Проверять/не проверять наличие флага encipherOnly
[no] decipher-only
Проверять/не проверять наличие флага decipherOnly
[no] ike-intermediate
Проверять/не проверять наличие OID-a 1.3.6.1.5.5.8.2.2
Также можно добавить проверку наличия других OID-ов, вводя команды вида:
468
(config−ike−conn−t1−cu)# oid <n.n.n.n.n>
Удалить проверку OID-а можно с помощью соответствующей команды:
(config−ike−conn−t1−cu)# no oid <n.n.n.n.n>
Удалить все OID-ы из списка проверки можно с помощью команды:
(config−ike−conn−t1−cu)# no oids
(Данная команда не влияет на флаг «ike-intermediate»).
Если локальный сертификат не удовлетворяет заданной области применения, произойдёт
ошибка при попытке перевода соединения в состояние «enabled».
Если присланный сертификат не удовлетворяет области применения, то будет послано уве-
домление INVALID_CERTIFICATE, и соединение будет задержано в следующих состояниях в зави-
симости от ситуации:
Состояние инициатора
Состояние ответчика
Плохой инициатор
pending2
pending_mdcfg
Плохой ответчик
pending1
pending_mdcfg
43.5.23
СОС и OCSP
Как было сказано выше, проверка сертификата, помимо проверки подписи и срока действия,
включает в себя проверку на отзыв. Проверка на отзыв может производиться как с помощью
протокола OCSP, так и с помощью списков отозванных сертификатов (СОС). Протокол OCSP имеет
больший приоритет, как более оперативный.
43.5.23.1
Ручная загрузка СОС
Списки отозванных сертификатов могут быть загружены в систему вручную с помощью коман-
ды «crypto pki import crl» (см. выше). При запуске службы IKE, все СОС, находящиеся в локальном
хранилище, загружаются в оперативную память. Если при работающей службе IKE в локальное
хранилище были загружены дополнительные СОС, то для того, чтобы они вступили в силу, тре-
буется выполнить команду режима enable:
# crypto ike reload
43.5.23.2
“Строгость” политики проверки сертификата на отзыв
Различаются две политики проверки сертификатов на отзыв: строгая и нестрогая (по умолча-
нию).
При строгой политике сертификат обязательно должен быть проверен на отзыв (либо по про-
токолу OCSP, либо по СОС). Если OCSP-информация недоступна и нет соответствующего действи-
тельного СОС, то сертификат считается заведомо недействительным.
469
При нестрогой политике сертификат проверяется на отзыв, если есть соответствующая ин-
формация (OCSP или СОС). Если её нет, то сертификат на отзыв не проверяется.
Для корневых сертификатов всегда действует нестрогая политика.
Строгую политику проверки на отзыв можно включить с помощью глобальной опции службы
IKE:
(config)# crypto ike config
(config−ike)# crl policy strict
Отключить строгую политику можно соответствующей командой «no»:
(config−ike)# no crl policy strict
43.5.23.3
Загрузка новых СОС по сети
Помимо статически загруженных СОС, служба IKE может динамически получать СОС по про-
токолам HTTP/FTP/LDAP.
ВАЖНО: По умолчанию динамическая загрузка СОС и запросы к OCSP выключены. Чтобы их
включить, необходимо задать глобальную опцию службы IKE:
(config−ike)# crl fetch interval <секунды>
Также данной опцией задаётся интервал между попытками загрузки СОС и OCSP-запросами.
Следует отметить, что данный интервал используется только тогда, когда нет загруженного дей-
ствительного СОС и OCSP-статуса. Если СОС и OCSP-статус действительны, обновления не про-
изводится.
Отключить динамическую загрузку СОС и запросы по OCSP можно командой:
(config−ike)# no crl fetch
Адреса загрузки СОС и OCSP-серверов получаются из двух источников:
1. Настройки «cainfo»;
2. Информация о точках распространения СОС и OCSP-серверах, записанная в сертификатах.
43.5.23.4
Ручная настройка точек распространения СОС и OCSP
Если необходимо задать точки распространения СОС и OCSP вручную, то это можно сделать,
создав настройки «cainfo». Настройки «cainfo» имеют больший приоритет, чем точки распростра-
нения, записанные в сертификатах.
«cainfo» представляет собой объект, содержащий адреса точек распространения СОС и OCSP,
и ассоциированный с внутренним системным именем соответствующего сертификата УЦ. СОС и
OCSP-статусы для сертификатов, выпущенных данным УЦ, будут пытаться загрузиться с указан-
ных адресов.
Чтобы создать/отредактировать объект «cainfo», необходимо ввести команду режима конфи-
гурации:
470
(config)# crypto ike cainfo <имя_сертификата_УЦ>
(config-ike-cainfo-<имя>)# _
Данная команда вводит консоль в режим редактирования настроек «cainfo».
Для вывода списка имён сертификатов УЦ, установленных в систему, можно использовать
команды режима enable:
# show crypto pki root ca certs
# show crypto pki ca certs
В режиме редактирования «cainfo» доступны следующие опции:
crl uri main <uri>
Основная точка распространения СОС
(HTTP/FTP/LDAP)
crl uri alt <uri>
Дополнительная точка распространения СОС
(HTTP/FTP/LDAP)
ldap host <hostname>|<ip>
Сервер LDAP (если не указано в URI)
ocsp uri <uri>
Адрес сервера OCSP
ocsp mode factor-ts|crypto-pro
Режим совместимости OCSP (см. ниже)
Пример:
(config)# crypto ike cainfo ca.cer
(config−ike−cainfo−ca.cer)# crl uri main ”ldap:///O=Хорошая организация,
C=RU?certificateRevocationList”
(config−ike−cainfo−ca.cer)# crl uri alt ”ftp://ftp.good−org.ru/my.crl”
(config−ike−cainfo−ca.cer)# ldap host ”ldap.good−org.ru”
(config−ike−cainfo−ca.cer)# ocsp uri ”http://ocsp.good−org.ru:8880”
Объекты «cainfo» можно копировать командой режима конфигурации:
(config)# crypto ike copy cainfo <имя_сертификата_УЦ_1> to <имя_сертификата_УЦ_2>
Если нужно удалить объект «cainfo», то это делается командой режима конфигурации:
(config)# no crypto ike cainfo <имя_сертификата>
Если объекты «cainfo» редактируются во время запущенной службы IKE, то новые настройки
не применяются немедленно. Чтобы они вступили в силу, необходимо выполнить команду «crypto
ike reload».
Чтобы вывести список объектов «cainfo», нужно выполнить команду режима enable:
# show crypto ike cainfos
Чтобы вывести подробную информацию об объектах «cainfo», нужно выполнить команду:
# show crypto ike cainfos verbose
Данная команда работает только при запущенной службе IKE. Если некоторые объекты
«cainfo» отсутствуют в выводе, это означает, что не были найдены соответствующие сертифи-
каты УЦ.
471
43.5.23.5
Диагностика загрузки СОС и OCSP
Чтобы вывести подробную информацию об известных точках распространения СОС и OCSP, о
попытках загрузки, о времени окончания действия СОС и OCSP-статусов, и т.д., нужно выполнить
команду режима enable:
# show crypto ike revocation
43.5.23.6
Кэширование СОС
Иногда бывает полезно сохранять динамически загруженные СОС в локальном хранилище
(например, при использовании строгой политики проверки на отзыв). Для этого надо включить
глобальную опцию службы IKE:
(config)# crypto ike config
(config−ike)# crl cache
Управлять сохранёнными СОС можно таким же образом, как и загруженными вручную, то есть
с помощью команд «*crypto pki * crl*» (см. выше).
Выключить сохранение загружаемых СОС можно соответствующей опцией «no».
(config−ike)# no crl cache
43.5.23.7
Настройка протокола OCSP
В
реализованы два режима совместимости протокола OCSP:
• Режим совместимости «Крипто-Про» (с использованием хэш-функции SHA1);
• Режим совместимости «Фактор-ТС» (с использованием только криптографии ГОСТ).
Этот режим устанавливается глобальной опцией службы IKE, а также на уровне объектов
«cainfo». Если для объекта «cainfo» не задана опция, то для данного удостоверяющего центра
действует глобальная опция. По умолчанию действует режим «Фактор-ТС».
Команды переключения режима совместимости OCSP:
(config)# crypto ike config
(config−ike)# ocsp mode default crypto−pro
(config−ike)# ocsp mode default factor−ts
(config−ike)# exit
(config)# crypto ike cainfo ca.cer
(config−ike−cainfo−ca.cer)# ocsp mode crypto−pro
(config−ike−cainfo−ca.cer)# ocsp mode factor−ts
(config−ike−cainfo−ca.cer)# no ocsp mode
В
имеется настройка максимального количества запросов статусов сертификатов в
одном OCSP-запросе:
(config)# crypto ike config
(config−ike)# ocsp max certs <n>
472
Данный параметр означает, какое максимальное количество сертификатов будет обработано в
одном OCSP-запросе (к одному OCSP-серверу). Если системе требуется выяснить статус большего
количества сертификатов, то будет сформировано несколько последовательных OCSP-запросов.
По умолчанию этот параметр равен 10, и без особой надобности менять его не нужно. Данный
параметр нужно уменьшать, если OCSP-сервер отвергает длинные OCSP-запросы; и нужно увели-
чивать, если узлу
требуется обрабатывать большое количество соединений от разных
оппонентов.
43.5.23.8
Очистка информации по отзывам
Если требуется очистить текущие статусы сертификатов, полученных по OCSP, то можно вы-
полнить команду режима enable:
# crypto ike clear ocsp cache
Динамически загруженные СОС очищаются только перезапуском службы IKE.
43.5.23.9
Особенности онлайн-проверки на отзыв
Для защиты от DoS-атак динамическая загрузка СОС и обмен по OCSP имеют следующие осо-
бенности. При проверки сертификата, пришедшего от оппонента, не производится немедленного
запроса к OCSP или немедленной загрузки СОС. Запрос к OCSP и инициирование загрузки СОС
производятся в параллельном потоке, чтобы не блокировать логику конечного автомата IKE. Из
этого следует, что при строгой политике проверки на отзыв, первая попытка установления соеди-
нения от нового оппонента может оказаться неудачной, так как соответствующий статус OCSP и
динамический СОС ещё не получены. Для устранения данной проблемы можно указать опцию «crl
cache» и/или заранее указать точки распространения СОС в объектах «cainfo» для соответствую-
щих удостоверяющих центров. В этом случае СОС будут загружены сразу после запуска службы
IKE.
43.5.24
Политика пересылки сертификатов
Сертификат оппонента может пересылаться по протоколу IKE, а может и не пересылаться. В
последнем случае он должен быть загружен заранее в локальное хранилище клиентских сертифи-
катов, и в конфигурации соединения должна присутствовать опция (на принимающей стороне):
(config)# crypto ike conn <имя>
(config-ike-conn-<имя>)# remote cert <имя_сертификата_оппонента>
Данную опцию можно очистить соответствующей командой «no»:
(config-ike-conn-<имя>)# no remote cert
Политика пересылки собственного сертификата задаётся опцией в конфигурации соединения:
(config)# crypto ike conn <имя>
(config-ike-conn-<имя>)# send cert <политика>
Возможные политики:
473
• always - всегда пересылать свой сертификат;
• never - никогда не пересылать свой сертификат;
• ifasked - (по умолчанию) пересылать свой сертификат только по требованию.
В случае политики «ifasked» сертификат будет пересылаться только тогда, когда от оппонента
получен запрос Certificate Request (CR).
При необходимости можно отключить посылку CR глобальной опцией службы IKE:
(config)# crypto ike config
(config−ike)# no send cert req
Включить посылку CR (вернуть поведение по умолчанию) можно опцией:
(config−ike)# send cert req
43.5.25
Плановая смена ключей
Как было сказано выше, взаимная аутентификация узлов IPsec может осуществляться либо с
помощью симметричных предварительно распространённых ключей (pre-shared keys, PSK), либо
с помощью асимметричных ключей и сертификатов X.509. Когда согласно регламенту истекает
срок действия ключей/сертификатов, то необходима их плановая смена.
Смена симметричных ключей (PSK)
Плановая смена ключей PSK проводится в несколько этапов:
1. Установка новых ключей PSK на каждый узел IPsec.
2. Переключение IPsec-туннелей на новые ключи.
3. Удаление старых ключей.
Каждый этап должен быть выполнен для всех узлов перед переходом к следующему этапу.
Этап 1 выполняется только локально. Этапы 2 и 3 могут выполняться как локально, так и
удалённо. При удалённом выполнении этапов канал управления должен защищаться отдельным
туннелем IPsec на отдельных ключах. Удалённая смена ключей для туннеля канала удалённого
управления имеет особый порядок (см. ниже), отличающийся от порядка смены ключей других
туннелей.
Во избежание частых выездов на удалённый объект на этапе 1 можно установить сразу
несколько ключей для нескольких последующих удалённых смен.
Этап 1:
Данный этап одинаков для обычных туннелей и для туннеля канала удалённого управления.
На каждый узел импортируется новый pre-shared ключ c помощью команды ‘crypto psk set
key’. Новый ключ сохраняется с новым именем.
Пример:
Существующая конфигурация узла 1:
474
# show crypto psk keys
psk1
# configure
(config)# do show
crypto psk map 10.1.0.1 10.2.0.1 psk1
crypto ike conn t1
auth psk
auto initiate
local ip 10.1.0.1
remote ip 10.2.0.1
Существующая конфигурация узла
2:
# show crypto psk keys
psk1
# configure
(config)# do show
crypto psk map 10.2.0.1 10.1.0.1 psk1
crypto ike conn t1
auth psk
auto listen
local ip 10.2.0.1
remote ip 10.1.0.1
Действия на узле 1:
# 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 psk2 @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 ’psk2’.
# show crypto psk keys
psk1
psk2
Действия на узле 2:
# crypto psk set key psk2 @9000
475
# show crypto psk keys
psk1
psk2
В данном примере новый симметричный pre-shared ключ сохранён с новым именем psk2.
Этап 2 (для обычных туннелей):
На данном этапе необходимо выполнить следующие действия:
1. Установить новую ассоциацию IP-адресов концов IPsec-туннеля с новым ключом с помощью
команды ‘crypto psk map’.
2. Перезагрузить секреты службы IKE с помощью команды ‘crypto ike reload’.
3. Перезагрузить IPsec-туннель(и), использующий(е) данный PSK, с помощью команд ‘crypto
ike disable conn <имя_туннеля>’ и ‘crypto ike enable conn <имя_туннеля>’.
4. Убедиться, что туннель успешно установился, с помощью команды ‘show crypto ike conn
<имя_туннеля>’. (Должен иметь статус ‘online’). Если необходима ручная инициация тунне-
ля, выполнить команду ‘crypto ike initiate conn <имя_туннеля>’.
Примечание: Пункты 2 и 3 можно заменить (для простоты) на выполнение команд ‘crypto ike
disable’ и ‘crypto ike enable’ (но при этом будут прерваны все остальные туннели).
Пример:
Действия на узле 1:
# configure
(config)# crypto psk map 10.1.0.1 10.2.0.1 psk2
(config)# do crypto ike reload
(config)# crypto ike disable conn t1
(config)# crypto ike enable conn t1
(config)# do write
(config)# do show crypto ike conn t1
t1
pending1
Связь по t1 прервана, потому что на втором узле ещё не заменён ключ. Узел
1
продолжит
пытаться установить соединение, так как действует настройка ‘auto initiate’.
Действия на узле 2:
# crypto psk set key psk2 @9000
# configure
(config)# crypto psk map 10.2.0.1 10.1.0.1 psk2
(config)# do crypto ike reload
(config)# crypto ike disable conn t1
(config)# crypto ike enable conn t1
(config)# do write
(config)# do show crypto ike conn t1
t1
listen
476
... Узел 1 ещё не успел инициировать соединение. Ждём 40 секунд...
(config)# do show crypto ike conn t1
t1
online
Этап 2 (для туннеля канала удалённого управления):
Действия:
1. Установить новую ассоциацию IP-адресов концов IPsec-туннеля с новым ключом с помощью
команды ‘crypto psk map’.
2. Сохранить текущую конфигурацию командой ‘write’.
3. Перезагрузить узел командой ‘reboot’.
4. Сменить ключ на терминале удалённого управления.
Если всё было сделано верно, то после перезагрузки узла
канал с ним должен
восстановиться.
ВНИМАНИЕ: Удалённое переключение ключа узла
является необратимой операци-
ей, и поэтому она должна осуществляться с особой внимательностью. Неправильное выполнение
процедуры может привести к потере связи и необходимости выезда администратора на удалён-
ный объект.
Пример:
Конфигурация узла
:
# show crypto psk keys
psk1
# configure
(config)# do show
crypto psk map 10.2.0.1 10.1.0.1 psk1
crypto ike conn t1
auth psk
auto listen
local ip 10.2.0.1
remote ip 10.1.0.1
local protoport tcp/ssh
remote protoport tcp
Действия (после этапа 1):
(config)# crypto psk map 10.2.0.1 10.1.0.1
psk2
(config)# do write
(config)# do reboot
477
Этап 3:
Данный этап одинаков для всех туннелей.
На данном этапе на всех узлах удаляются старые pre-shared ключи с помощью команды ‘crypto
psk clear key’.
Пример:
# crypto psk clear key psk1
Смена асимметричных ключей (PKI)
При использовании PKI (в отличие от PSK) не предусматривается предварительный выпуск
нескольких ключей и сертификатов для их удалённых последовательных смен в будущем. Поэто-
му удалённая смена ключей PKI невозможна.
В данном разделе рассматривается ситуация, когда новые сертификаты X.509 выпускаются
с помощью старого ключа подписи удостоверяющего центра (то есть цепочку сертификатов УЦ
менять не нужно). О смене сертификатов удостоверяющих центров см. ниже.
Во избежание долговременного вывода из эксплуатации IPsec-туннелей новые сертификаты
должны выпускаться за некоторое время до окончания срока действия старых.
Порядок действий:
1. Импортировать новый закрытый ключ с новым именем (команда ‘crypto pki import key’).
2. Импортировать новый сертификат узла с новым именем (команда ‘crypto pki import cert’).
3. Создать копию действующего туннеля IPsec (команда ‘crypto ike copy conn’).
4. Изменить настройку ‘local cert’ в новом туннеле. Указать имя нового сертификата.
5. Вывести из эксплуатации старый туннель командой ‘crypto ike disable conn’.
6. Перезагрузить секреты службы IKE (команда ‘crypto ike reload’).
7. Активировать новый туннель командой ‘crypto ike enable conn’. Если необходимо ручное
установление соединения, выполнить команду ‘crypto ike initate conn’.
8. Проверить установления соединения командой ‘show crypto ike conn’.
9. Если соединение установилось успешно, удалить старые ключ, сертификат и туннель соот-
ветственно командами ‘crypto pki clear key’, ‘crypto pke clear cert’, ‘no crypto ike conn’.
Данные действия выполняются на каждом узле. Причём выполнять их можно последовательно
(поэтапно). (Т.е. допускаются длительные перерывы между изменениями конфигураций разных
узлов). При этом связь не будет потеряна на долгое время, так как протокол IKE позволяет пересы-
лать сертификат оппонента. При установлении нового туннеля будет передан новый сертификат.
Причём возможно установление соединения “новый-со-старым”, так как новые сертификаты вы-
пущены старым ключом подписи УЦ, и новый сертификат успешно пройдёт проверку на узле со
старой конфигурацией.
Пример (для одного узла):
Существующая конфигурация узла 1:
478
# show crypto pki keys
user1.key
# show crypto pki certs
user1.cer CN=user1,O=Фактор-ТС,C=RU
# show
crypto ike conn t1
auth pubkey
auto listen
local ip 10.1.0.1
remote ip 10.2.0.1
local cert user1.cer
remote id ”CN=user2,O=Фактор-ТС,C=RU”
Действия на узле 1:
# show crypto pki keys flash
user1.p15/
# crypto pki import key from user1.p15 to user1.key.2
# show crypto pki certs flash
user1.cer user CN=user1,O=Фактор-ТС,C=RU
# crypto pki import cert from user1.cer to user1.cer.2
# configure
(config)# crypto ike copy conn t1 to t1−2
(config)# crypto ike conn t1−2
(config−ike−conn−t1−2)# local cert user1.cer.2
(config−ike−conn−t1−2)# exit
(config)# crypto ike disable conn t1
(config)# do crypto ike reload
(config)# crypto ike enable conn t1−2
(config)# do crypto ike initiate conn t1−2
(config)# do show crypto ike conn t1−2
t1−2
online
(config)# no crypto ike conn t1
(config)# exit
# crypto pki clear key user1.key
# crypto pki clear cert user1.cert
# write
Смена сертификата удостоверяющего центра
Как и любой сертификат, сертификат удостоверяющего центра имеет срок действия. По ис-
течении данного срока все сертификаты, подписанные данным сертификатом, становятся недей-
ствительными. Чтобы избежать долговременного вывода IPsec-туннелей из эксплуатации, реко-
мендуется выпустить новый сертификат удостоверяющего центра за некоторое время до оконча-
ния срока действия старого. Также необходимо выпустить новые закрытые ключи и сертификаты,
подписанные новым сертификатом УЦ, для всех узлов IPsec. Далее необходимо установить новый
сертификат УЦ, новый ключ, новый сертификат узла на каждый IPsec-узел. (При этом туннели
продолжат работать на старых сертификатах). Когда новые сертификаты/ключи будут установ-
479
лены на всех узлах, можно начинать поэтапную смену настройки ‘local cert’ IPsec-туннелей. При
этом связь не будет прерываться на долгое время, так как для проверки сертификатов узлов мо-
жет использоваться как старый сертификат УЦ, так и новый. После того, как на всех узлах будут
задействованы новые туннели (с новой настройкой ‘local cert’), старые сертификаты УЦ/узлов,
старые ключи и старые туннели можно будет удалить.
Для импорта сертификатов УЦ используются команды ‘crypto pki import [root] ca cert’. Для
удаления - ‘crypt pki clear [root] ca cert’.
Пример (для одного узла):
Существующая конфигурация узла 1:
# show crypto pki keys
user1.key
# show crypto pki certs
user1.cer CN=user1,O=Фактор-ТС,C=RU
# show crypto pki root ca certs
ca.cer
CN=УЦ,O=Фактор-ТС,C=RU
# show
crypto ike conn t1
auth pubkey
auto listen
local ip 10.1.0.1
remote ip 10.2.0.1
local cert user1.cer
remote id ”CN=user2,O=Фактор-ТС,C=RU”
Импорт нового сертификата УЦ/узла, нового закрытого ключа:
# show crypto pki certs flash
ca.cer
root CN=УЦ,O=Фактор-ТС,C=RU
user1.cer user CN=user1,O=Фактор-ТС,C=RU
# crypto pki import root ca cert from ca.cer to ca.cer.2
# crypto pki import cert from user1.cer to user1.cer.2
# show crypto pki keys flash
user1.p15/
# crypto pki import key from user1.p15 to user1.key.2
# configure
(config)# crypto ike copy conn t1 to t1−2
(config)# crypto ike conn t1−2
(config−ike−conn−t1−2)# local cert user1.cer.2
(config−ike−conn−t1−2)# do write
Далее, когда на всех узлах данная процедура будет выполнена, можно начинать деактивацию
старых туннелей и активацию новых:
(config)# crypto ike disable conn t1
(config)# do crypto ike reload
(config)# crypto ike enable conn t1−2
480
(config)# do crypto ike initiate conn t1−2
(config)# do show crypto ike conn t1−2
t1−2
online
(config)# do write
После полного перехода всех узлов на новые туннели, старые туннели/ключи/сертификаты
можно удалить:
(config)# no crypto ike conn t1
(config)# exit
# crypto pki clear key user1.key
# crypto pki clear cert user1.cert
# crypto pki clear root ca cert ca.cer
# write
43.5.26
Внеплановая смена ключей
Процедуры внеплановой смены ключей аналогичны плановой. В случае внеплановой смены
закрытых ключей (PKI) также необходимо уведомить (по доверенному каналу) соответствующий
удостоверяющий центр (выпустивший сертификат для данного ключа) для того, чтобы сертифи-
кат скомпрометированного ключа был включён с список отозванных сертификатов.
43.5.27
Защита от DoS-атак
Протокол IKE подвержен DoS-атакам. Основная уязвимость заключается в том, что при по-
лучении первого пакета от инициатора (возможно, злоумышленника) службе IKE необходимо
создать структуру в памяти, чтобы адекватно ответить на последующие пакеты. Это происходит
до аутентификации и до выработки общего секрета, и поэтому невозможно заранее отличить
злоумышленника от «честного» клиента. Поэтому злоумышленник может сгенерировать поток
пакетов, которые приведут к возникновению большого количества структур (состояний соедине-
ний) в памяти, что может привести к замедлению работы системы и к аварийному завершению
службы IKE из-за нехватки памяти.
Чтобы этого избежать, в службе IKE введено ограничение на количество полуоткрытых со-
единений (неаутентифицированных фаз 1). Если службе необходимо создать новое состояние, и
превышен лимит полуоткрытых соединений, то удаляется наиболее старое полуоткрытое соеди-
нение.
По умолчанию лимит полуоткрытых соединений равен 10000. Это адекватное значение для
системы с ОЗУ объёмом 512 МБ. Данное значение можно регулировать опцией службы IKE:
(config)# crypto ike config
(config−ike)# anti−dos max states <n>
Следует помнить, что увеличение лимита состояний потребует большего объёма ОЗУ и приве-
дёт к замедлению работы системы. Однако, значительное уменьшение лимита хотя и повышает
481
реакцию системы, но может привести к отказам в установлении соединений от «честных» клиен-
тов, если данный узел в данный момент находится под DoS-атакой.
Также при превышении лимита полуоткрытых соединений вырабатывается сигнал тревоги (см.
show log alert).
43.5.28
Защита от replay-атак
В реализации протокола ESP в системе предусмотрена защита от replay-атак. Она заклю-
чается в учёте порядковых номеров ESP-пакетов и отбрасывании пакета, если уже был принят
пакет с таким же номером, либо если номер пакета слишком «стар». Так как учитывать все номе-
ра пришедших пакетов невозможно, реализовано «окно» номеров пришедших пакетов. Данное
окно представляет из себя битовый массив, элементы которого показывают, был ли принят па-
кет с таким номером или нет. При принятии очередного пакета взводится соответствующий бит в
окне. Если номер пакета новее, чем самый «новый» элемент окна, то окно продвигается вперёд.
«Старые» пакеты, которые оказались позади окна считаются «принятыми», и если придёт пакет,
номер которого оказался позади окна, то он будет отброшен вне зависимости от того, был он
принят раньше или нет.
По умолчанию размер anti-replay окна равен 512 пакетам.
На высокоскоростных сетевых интерфейсах этот размер может оказаться недостаточным (из-
за большой степени неупорядоченности пришедших пакетов), и его можно увеличить с помощью
глобальной опции службы IKE:
(config)# crypto ike config
(config−ike)# anti−replay window <n>
43.5.29
Лицензии на соединения
В некоторых конфигурациях возможно лицензионное ограничение на максимальное
количество IPsec-соединений. Чтобы узнать максимальное и оставшееся количество лицензий на
соединения, необходимо ввести команду:
# show crypto ike license
Примеры вывода команды:
1)
Connection licenses: UNLIMITED
Connection licenses: 100
3)
Connection licenses left: 95 of 100
482
В примере (1) количество соединений не ограничено. В примере (2) показан вывод команды
при отключённой службе IKE. В примере (3) показан вывод команды при включённой службе IKE.
В данном примере израсходовано 5 лицензий на данный момент (активно 5 соединений).
Правила блокировки/освобождения лицензий:
В случае нешаблонного соединения (когда данный узел может быть инициатором) расходу-
ется одна лицензия при включении данного соединения (с помощью команды “crypto ike enable
conn”). Лицензия освобождается при выключении соединения с помощью команды “crypto ike
disable conn”.
В случае шаблонного соединения (когда данный узел не может быть инициатором) при вклю-
чении данного соединения лицензия не расходуется. Шаблонные соединения могут порождать
множества частных соединений. Лицензия расходуется при установлении очередного частного
соединения (от клиента) и освобождается при закрытии очередного частного соединения. Лицен-
зий будет израсходовано ровно столько, сколько клиентов будет подключено одновременно к
данному узлу.
Примечание: В случае шаблонного соединения для успешного установления очередного
частного соединения необходимо, чтобы в запасе было не менее 2 свободных лицензий. (Осо-
бенности архитектуры).
43.5.30
Синхронный и асинхронный режим обработки ESP-пакетов
По умолчанию ядро пытается распараллеливать обработку входящих и исходящих ESP-
пакетов. Зашифрование/дешифрование пакетов производится на разных процессорах/ядрах. В
результате пакеты могут отправляться/попадать в систему фактически не в том порядке, в ко-
тором они были отправлены/получены. Если такое поведение неприемлемо, то можно включить
синхронный режим обработки ESP-пакетов:
(config)# crypto ike config
(config−ike)# esp sync
Вернуть поведение по умолчанию (асинхронный режим) можно с помощью команды:
(config−ike)# no esp sync
43.5.31
Другие настройки
Фаза ModeConfig может работать в двух режимах (см. draft-dukes-ike-mode-cfg-02):
• Запрос/ответ (pull);
• Предложение/подтверждение (push).
По умолчанию включён режим «pull», и без особой надобности его менять не нужно.
Если по каким-то причинам необходимо поменять данный режим, то это можно сделать с по-
мощью опции конфигурации соединения:
483
(config-ike-conn-<имя>)# modeconfig mode push|pull
Настройки «modeconfig mode» должны быть одинаковыми у обоих оппонентов.
484
485
44. VRRP-кластер
VRRP (Virtual Router Redundancy Protocol) — сетевой протокол, предназначенный для увели-
чения доступности маршрутизаторов, выполняющих роль шлюза по умолчанию. Это достигается
путём объединения группы маршрутизаторов в один виртуальный маршрутизатор и назначения
им общего IP-адреса, который и будет использоваться как шлюз по умолчанию для компьютеров
в сети.
44.1
Основные понятия
•
VRRP-маршрутизатор (VRRP Router) — маршрутизатор, на котором работает протокол VRRP.
Он может участвовать в одном или более виртуальных маршрутизаторах;
•
Виртуальный маршрутизатор (Virtual Router, VR) — абстрактный объект, которым управля-
ет VRRP. Выполняет роль маршрутизатора по умолчанию для компьютеров в сети. Факти-
чески, виртуальный маршрутизатор — это группа интерфейсов маршрутизаторов, которые
находятся в одной сети и разделяют Virtual Router Identifier (VRID) и виртуальный IP-адрес;
•
Владелец IP-адреса (IP Address Owner) — VRRP-маршрутизатор, который использует IP-
адрес, назначенный виртуальному маршрутизатору, как реальный IP-адрес, присвоенный
интерфейсу;
•
VRRP-объявление
(ADVERTISEMENT)
— сообщения, которые отправляет Master-
маршрутизатор;
•
Виртуальный IP-адрес (Virtual IP address) — это IP-адрес, присвоенный интерфейсу одного
из маршрутизаторов, которые составляют Virtual Router. Используется также название —
основной IP-адрес (Primary IP Address). В VRRP-объявлениях в качестве адреса отправителя
всегда используется виртуальный IP-адрес;
•
Virtual Router Master или VRRP Master router — VRRP-маршрутизатор, который отвечает за
отправку пакетов, отправленных на IP-адрес, который ассоциирован с виртуальным марш-
рутизатором, и за ответы на ARP-запросы, отправленные на этот адрес. Если владелец IP-
адреса доступен, то он всегда становится Master;
•
Virtual Router Backup или VRRP Backup router — это группа маршрутизаторов, которые на-
ходятся в режиме ожидания и готовы взять на себя роль VRRP Master router, как только
текущий VRRP Master router станет недоступным;
•
Виртуальный MAC-адрес (Virtual MAC) — 0000:5E00:01xx, где xx — номер группы VRRP.
44.2
Настройка кластера
Для настройки VRRP в режиме configure для всех участников кластера необходимо перейти в
режим конфигурации VRRP:
Router(config)# service vrrp
В этом режиме можно активировать и деактивировать службу VRRP с помощью команд
enable/disable, а также создавать и удалять участников (экземпляры) кластера и группы.
486
44.2.1
Создание участников кластера
Для функционирования кластера необходимо создать хотя бы одного участника кластера.
Для этого необходимо создать instance (экземпляр) кластера:
Router(service−vrrp)# instance outside
outside здесь любое удобное администратору имя. При этом осуществляется переход в режим
настройки данного экземпляра участника кластера.
В этом режиме осуществляется связь виртуального IP-адреса с участником кластера и зада-
ются другие параметры:
Команда
Назначение
description текст
Описание instance для администратора
id <идентификатор>
Задание номера группы для кластера
iface <интерфейс>
Привязка к интерфейсу
ip address <адрес/маска>
Задание виртуального IP-адреса
adv-interval <секунды>
Интервал advertisement-оповещений
garp-delay <секунды>
Время в секундах для перехода в состояние Master
priority <приоритет>
Приоритет данного instance в кластере
state <master|backup>
Первоначальное состояние данного instance
password <пароль>
Защита сообщений паролем
vmac
Включить режим подмены виртуального MAC-адреса
preempt
Перехватывать роль у instance с низким приоритетом
preempt-delay <секунды>
Задержка для перехвата роли
Для всех описанных команд существуют аналоги с префиксом “no”, которые используются
для удаления соответствующей настройки. Например:
Router(service−vrrp−outside)# no vmac
Для удаления экземпляра следует пользоваться командой:
Router(service−vrrp)# no instance outside
При наличии хотя бы двух маршрутизаторов с созданными instance на них, принадлежащих од-
ной группе и разделяющий одинаковый IP-адрес, кластер (после включения его командой enable)
может выполнять роль виртуального маршрутизатора с заданным виртуальным IP-адресом. При
наличии одного маршрутизатора с созданным instance, маршрутизатор также будет выполнять
роль виртуального маршрутизатора, но без функций резервирования.
44.2.2
Создание групп синхронизации
По умолчанию, если участник кластера с ролью backup перестает получать сообщения от
master, то он переходит в режим master и становится владельцем виртуального IP-адрес. Иногда
487
бывает необходимым рассматривать группу виртуальных IP-адресов как одно целое. Это означа-
ет, что при сбое любого члена группы, должно происходить резервирование. Для этого существу-
ет понятие группы синхронизации участников кластера:
Router(service−vrrp)# group myrouter
При этом происходит переход в режим конфигурации группы, в котором можно добавлять и
удалять instance с помощью команд member и no member, например:
Router(service−vrrp−myrouter)# member outside
Router(service−vrrp−myrouter)# no member outside
Группа рассматривается кластером как единое целое, и при сбое любого из instance группы,
происходит смена роли (один из backup становится master).
Для удаления группы, воспользуйтесь командой:
Router(service−vrrp)# no group myrouter
44.2.3
Диагностика
Для просмотра сообщений от службы VRRP следует пользоваться командой show service vrrp
log из режима enable:
Router# show service vrrp log
Кроме стандартных параметров для этой команды, существует параметр states, которые поз-
воляет просмотреть только смену состояний (ролей).
Для просмотра текущей информации о состоянии кластера, следует пользоваться командой:
Router# show service vrrp state
Для получения более подробной и, наоборот, выборочной информации, можно воспользовать-
ся командами: show service vrrp state all, show service vrrp state sgroups (информация по группам),
show service vrrp state topology.
488
489
45. Отказоустойчивый кластер
Типичная схема использования отказоустойчивого кластера на основе маршрутизаторов
представлена на рисунке:
Рис. 45.1: Отказоустойчивый кластер
Предположим, маршрутизатор используется для связи сетей #1 и #2. При выходе из строя
маршрутизатора связь между сетями будет утеряна. Чтобы этого не произошло, используется
резервирование. Вместо одного маршрутизатора, устанавливается два одинаковых маршрутиза-
тора. В каждый момент времени активен только один из них. Второй находится в резерве. Один
из маршрутизаторов считается основным (master), второй резервным (slave). Когда работает ос-
новной маршрутизатор, резервный блокирует все свои интерфейсы, кроме одного служебного.
Резервный маршрутизатор связан с основным специальной выделенной линией связи (dedicated
link). Резервный маршрутизатор прослушивает выделенную линию связи и получает от основ-
ного маршрутизатора всю информацию, характеризующую состояние компонента TCP/IP, и спе-
циально сформированные «пакеты жизни» (heartbeat или advertizing message), которые служат
признаком того, что основной маршрутизатор работоспособен. Если пакетов нет слишком дол-
го, считается, что основной маршрутизатор вышел из строя. При этом резервный маршрутизатор
временно становится основным (temp master), разблокирует свои интерфейсы и берет на се-
бя все функции по обработке трафика. Если, после проведения ремонта или замены, основной
маршрутизатор становится снова доступен и начинает генерировать пакеты жизни, резервный
маршрутизатор возвращается в состояние ожидания.
Кроме обмена пакетами жизни, выделенная линия связи между основным и резервным марш-
рутизатором используется для синхронизации настроек маршрутизаторов и обмена информацией
о текущих соединениях.
45.1
Требования к оборудованию
Для организации отказоустойчивого кластера на основе системы рекомендуется
использовать два одинаковых маршрутизатора, с одинаковым количеством интерфейсов и произ-
водительностью. Наличие выделенной линии связи основного маршрутизатора с резервным яв-
ляется обязательным условием. Также обязательным условием является установка на оба марш-
рутизатора одинаковой версии ПО
490
45.2
Подготовка к организации кластера
Перед объединением двух маршрутизаторов в кластер, на каждый из них необходимо уста-
новить одинаковую версию системы и выполнить первичную настройку. Первичная настройка
необходима для организации выделенной линии связи.
Перед настройкой параметров кластера, необходимо убедиться в том, что интерфейсы на каж-
дом маршрутизаторе пронумерованы единообразно (п. 5.2. Настоятельно рекомендуется нумеро-
вать все интерфейсы маршрутизаторов кластера единым образом во избежание путаницы, так
как впоследствии настройки резервного маршрутизатора будут синхронизированы с настройка-
ми основного. Важно заметить, что нумерация интерфейсов входит в состав локальных настроек
и не входит в состав конфигурации системы, и поэтому, не будет синхронизирована. На каждом
маршрутизаторе нумерацию нужно провести отдельно.
После этого необходимо выбрать интерфейс для организации выделенной линии связи. На
основном и резервном маршрутизаторе это должны быть одноименные интерфейсы.
Необходимо выбрать подсеть для организации выделенной линии связи. Подсеть служит для
автоматического формирования IP-адресов основного и резервного маршрутизатора, а также для
уникальной идентификации кластера. Для кластеров, находящихся в одной физической сети,
выбранные подсети выделенной линии должны отличаться.
Для установки параметров кластера необходимо выполнить следующую команду в режиме
конфигурирования:
Router(config)# cluster
Конфигурирование кластеров осуществляется с использованием команды aux. Она указыва-
ет, по какому интерфейсу и по какой подсети организуется выделенная линия. Для минимальной
предварительной настройки основного маршрутизатора, необходимо выполнить следующие ко-
манды в режиме конфигурирования кластера:
Router(config−cluster)# aux interface ethernet 2
Router(config−cluster)# aux network 192.168.10.0/24
Router(config−cluster)# enable
В данном примере «ethernet 2» и «192.168.10.0/24» - выбранные для организации выделен-
ной линии связи интерфейс и подсеть, соответственно. Для минимальной предварительной на-
стройки резервного маршрутизатора, необходимо в режиме конфигурирования кластера выпол-
нить следующие команды :
Router(config−cluster)# slave
Router(config−cluster)# aux interface ethernet 2
Router(config−cluster)# aux network 192.168.10.0/24
Router(config−cluster)# enable
Команда «slave» в данном примере говорит о том, что данный маршрутизатор является ре-
зервным. По-умолчанию, маршрутизатор считается основным.
Сформированную таким образом конфигурацию следует сохранить в startup-config. После это-
го маршрутизаторы можно объединять в кластер. Интерфейсы выделенной линии связи должны
быть соединены друг с другом напрямую. Кластер практически готов к работе. Всю остальную
настройку можно выполнить позже.
491
45.3
Настройки кластера
Все настройки кластера производятся в режиме конфигурирования кластера (config-cluster).
Чтобы указать маршрутизатору, является ли он основным или резервным, используется ко-
манда «slave». Для резервного маршрутизатора «slave» должен быть установлен, для основного
- сброшен. Перевести резервный маршрутизатор в режим основного можно с помощью команды:
Router(config−cluster)# no slave
Настройка интерфейса и подсети для организации выделенной линии связи между маршрути-
заторами внутри кластера описана в п. 45.2.
Для кластера может быть настроен интервал между посылками пакета жизни 45 основным
маршрутизатором и тайм-аут, после которого резервный маршрутизатор должен считать, что ос-
новной маршрутизатор вышел из строя.
Router(config−cluster)# advert 1000
Router(config−cluster)# timeout 3000
Времена задаются в милисекундах. В данном примере периодичность посылки пакетов жиз-
ни равна одной секунде, а тайм-аут, после истечения которого резервный маршрутизатор станет
временно основным, равен трем секундам. В этом примере резервный маршрутизатор станет вре-
менно основным, если он не получил три подряд пакета жизни от основного маршрутизатора
кластера. По умолчанию эти времена (advert и timeout) равны 500 мс и 1500 мс, соответственно.
Основной и резервный маршрутизатор обмениваются информацией об активных соединениях
(conntrack), чтобы резервный маршрутизатор (а в случае перезагрузки основного, то и основной)
«подхватил» уже установленные соединения автоматически. Интервал времени между операци-
ями обмена информацией можно установить командой:
Router(config−cluster)# conntrack poll 10
Интервал времени выражается в секундах и по умолчанию равен 5 секундам.
Чтобы запустить кластер, необходимо выполнить следующую команду:
Router(config−cluster)# enable
Чтобы остановить кластер, необходимо выполнить следующую команду:
Router(config−cluster)# disable
После запуска кластера администратор может менять его настройки, но эти изменения не
будут сразу применены. Чтобы применить введенные настройки, необходимо остановить кластер
и вновь его запустить. Если администратор изменил настройки при работающем кластере, он
будет предупрежден об этом с помощью значка »~» в приглашении командной строки в режиме
конфигурирования кластера:
Router(config−cluster)~#
Знак »~» означает рассинхронизацию между настройками работающего кластера и текущими
настройками в running-config.
492
45.4
Получение информации о кластере
Получить информацию о текущем состоянии кластера можно с помощью следующей команды,
выполненной из привилегированного режима:
Router# show cluster
State:
enable
Mode:
master
Interface:
ethernet2
Network:
192.168.77.0/24
Advert period:
500 ms (default)
Advert timeout: 1500 ms (default)
ConnTrack poll: 5 sec (default)
Current config settings (not active):
Mode:
master
Interface:
ethernet2
Network:
192.168.77.0/24
Advert period:
1000 ms
Advert timeout: 1500 ms (default)
ConnTrack poll: 10 sec
Warning: The current settings is not equal to active settings.
Warning: Disable cluster and then enable it to fix differencies.
В данном примере показан самый полный вывод команды «show cluster» - в случае рассинхро-
низации настроек работающего кластера и настроек в running-config. В начале вывода показаны
настройки работающего кластера. Далее показаны измененные настройки из текущей конфигу-
рации. В завершении выводятся предупреждения о рассинхронизации.
Если кластер запущен и рассинхронизации настроек нет, то будут показаны только настройки
работающего кластера. Если кластер остановлен, будут показаны только настройки из текущей
конфигурации.
Свойство «State» показывает, запущен ли кластер:
• enable - кластер запущен;
• disable - кластер остановлен.
Свойство «Mode» отображает текущий режим работы маршрутизатора:
• master - маршрутизатор является основным;
• slave - маршрутизатор является резервным;
• slave (temp master) - маршрутизатор является резервным, но выполняет функции основно-
го, так как основной вышел из строя.
Свойства «Interface» и «Network» отображают настройки интерфейса и подсети для выделен-
ной линии связи между основным и резервным маршрутизаторами.
493
Свойства «Advert period» и «Advert timeout» отображают период посылки пакета жизни ос-
новным маршрутизатором и тайм-аут, по истечении которого основной маршрутизатор считается
неработоспособным.
Свойство «ConnTrack poll» отображает период времени между операциями обмена информа-
цией об установленных соединениях.
45.5
Синхронизация настроек между маршрутизаторами
Так как маршрутизаторы в кластере взаимозаменяемы, то их системные настройки должны
быть идентичны. Для этого предусмотрена возможность синхронизации настроек. После настрой-
ки системы на основном маршрутизаторе, конфигурация может быть полностью перенесена на
резервный маршрутизатор.
Для удобства последующей синхронизации необходимо однократно выполнить ряд действий
на основном маршрутизаторе (предполагается, что кластер запущен) в привилегированном ре-
жиме:
Router# cluster key generate
Router# cluster key export
Эти команды предназначены для шифрования соединения между основным и резервным
маршрутизаторами. Первая команда генерирует ключ для шифрования, а вторая - передает этот
ключ на резервный маршрутизатор. При выполнении второй команды будет запрошен пароль
администратора на резервном маршрутизаторе. После выполнения этих действий последующее
взаимодействие между основным и резервным маршрутизаторами не потребует ручного ввода
пароля администратора.
FIXME TODO - Написать о разных типах ключей. С.Каличев
Для синхронизации системной конфигурации необходимо выполнить следующие действия из
привилегированного режима:
Router# cluster sync
При этом конфигурация (с добавлением служебной информации) основного маршрутизатора
будет скопирована на резервный маршрутизатор. Так как заранее неизвестно, какие настройки
были изменены, для применения новых настроек требуется перезагрузка резервного маршрути-
затора. Поэтому, если настройка на основном маршрутизаторе завершена, то можно использовать
команду:
Router# cluster sync reboot
При этом, после синхронизации настроек, резервный маршрутизатор будет автоматически
перезагружен, чтобы применилась новая конфигурация системы.
Для того, чтобы администратор с основного маршрутизатора мог зайти на резервный маршру-
тизатор, предусмотрена команда:
Router# cluster connect
494
К имени хоста в приглашении командной строки на резервном маршрутизаторе будет добав-
лена строка »-slave» для того, чтобы администратор легко мог отличить основной маршрутизатор
от резервного.
Router−slave#
45.6
Дополнительные команды
В разделе «Синхронизация настроек между маршрутизаторами» были указаны команды для
исключения ручного ввода команд при взаимодействии маршрутизаторов внутри кластера. Од-
нако при замене одного из маршрутизаторов в кластере или в случае, если маршрутизаторы ис-
ключаются из кластера и становятся самостоятельными, может потребоваться очистка некоторых
настроек.
Так на основном маршрутизаторе сохраняются параметры для взаимодействия с резервным.
Поэтому при замене резервного маршрутизатора необходимо очистить параметры, которые соот-
ветствовали старому маршрутизатору, иначе взаимодействие с новым резервным маршрутизато-
ром будет заблокировано. Для этого используется команда привилегированного режима:
Router# clear cluster known−hosts all
На резервном маршрутизаторе также хранятся параметры основного маршрутизатора. Поэто-
му, при замене основного маршрутизатора, на резервном следует выполнить команду:
Router−slave# clear cluster authorized−keys all
495
46. Обновление системы
Администратор имеет возможность производить обновление системы. Обновление может
быть локальным, если администратор имеет физический доступ к оборудованию, или уда-
лённым, если оборудование физически недоступно. Работы по установке и управлению обновле-
ниями администратор должен производить из командной строки в привилегированном режиме.
46.1
DIP-пакеты
Обновления системы предоставляются в виде DIP-пакетов. Аббревиатура DIP рас-
шифровывается как «Dionis Package». DIP пакет - это файл с именем вида «dionisnx-1.0-
0.x86_64.dip», где «1.0» - версия системы, «0» - номер редакции (релиз), «x86_64» - архитектура
целевой платформы. Пакет содержит информацию о предоставляемой системе - версия, дата со-
здания, характеристики и т.д., ядро системы, образ корневой файловой системы
DIP-пакет привязан к конкретному экземпляру оборудования, для которого он был создан. Он
не может быть установлен на другой маршрутизатор. Для маршрутизатора вычисляется идентифи-
катор оборудования (Platform ID). Для каждого экземпляра маршрутизатора этот идентификатор
имеет уникальное значение. Администратор может узнать идентификатор текущей платформы с
помощью команды привилегированного режима:
Router# show version
Platform ID: 4F7F−7879−F676−E85B−5369
46.2
Инфраструктура DIP
На маршрутизаторе может быть одновременно установлено несколько экземпляров операци-
онной системы. Это могут быть и разные версии ОС,и несколько экземпляров системы одной
версии. Возможность использования нескольких версий ОС нужна для безопасного об-
новления системы, а также для организации отката (fallback) к работоспособному экземпляру
системы при возникновении сбоев работы текущей работающей системы.
Все установленные экземпляры операционной системы (будем называть их пакетами ОС или
OS package) доступны только для чтения. Дополнительные данные для операционных систем
(конфигурация, настройки и т.д.) хранятся отдельно и доступны для чтения и записи. Эти данные
хранятся в области внутреннего диска маршрутизатора, называемом «слот данных» (data slot).
Одновременно на диске может существовать несколько слотов данных.
Обычно каждый пакет ОС связан (bind) со своим слотом данных, где он и хранит данные.
Однако пакеты и слоты данных не связаны друг с другом жестко. Могут существовать пакеты ОС,
не имеющие своего слота данных, а также слоты данных, не привязанные ни к одному пакету.
496
К примеру, вновь установленное обновление ОС не имеет своего слота данных. Пакет получит
слот данных либо автоматически при загрузке, либо администратор вручную свяжет этот пакет
с уже существующим слотом данных. В случае загрузки операционной системы, не имеющей на
текущий момент своего слота данных, новый слот данных будет создан автоматически и привязан
к загружаемой системе. Таким образом, пакет может существовать без слота данных в пассивном
режиме, но не может без него работать.
Каждый установленный пакет ОС идентифицируется уникальным именем. Каждый слот дан-
ных также идентифицируется уникальным именем. Используя эти уникальные имена, админи-
стратор системы может производить различные действия над пакетами ОС и слотами данных.
Операции над текущим (активным) пакетом ОС и активным слотом данных ограничены, так как
невозможно, к примеру, удалить текущий слот данных, не нарушив работу маршрутизатора.
Команды для пакетов ОС:
Команда
Назначение
os install
Установка нового пакета OC. Источником яв-
ляется DIP-пакет
os remove
Удаление существующего пакета ОС. Невоз-
можно для активного пакета
os rename
Переименование существующего пакета ОС.
Меняется уникальное имя пакета в системе
os export
Экспорт существующего пакета ОС. Будет со-
здан DIP-пакет
os bind
Привязка пакета ОС к существующему слоту
данных. Невозможно для активного пакета ОС.
Невозможно для уже привязанного слота дан-
ных
os bind
Отвязывание пакета ОС от слота данных.
Невозможно для активного пакета ОС
show os
Получение списка установленных пакетов ОС
show os info
Получение подробной информации об уста-
новленных пакетах ОС
Команды для слотов данных:
Команда
Назначение
os data create
Создание нового пустого слота данных
os data clone
Клонирование слота данных. Создается но-
вый слот, дублирующий содержимое исходно-
го слота
os data remove
Удаление существующего слота данных.
Невозможно для слотов, привязанных к
какому-либо пакету ОС
os data rename
Переименование существующего слота дан-
ных
os data backup
Создание резервной копии данных на основа-
нии существующего слота данных. Создается
файл - резервная копия
497
os data restore
Восстановление слота данных на основании
резервной копии данных. Невозможно для ак-
тивного слота данных
schedule backup
Безопасное создание резервной копии актив-
ного слота с перезагрузкой
schedule restore
Восстановление текущего слота данных на ос-
новании резервной копии
schedule migrate
Миграция на другой пакет ОС с сохранением
текущего слота данных. Требуется перезагруз-
ка
show os data
Получить список существующих слотов дан-
ных
Команды загрузки системы:
Команда
Назначение
boot default
Задать пакет ОС, который будет загружаться
по умолчанию
boot fallback
Задать пакет ОС, который будет загружен в
случае необходимости отката к предыдущей
версии (fallback).
boot experimental
Установить для пакета ОС признак того, что
эта ОС является экспериментальной
show boot
Получить текущую конфигурацию загрузчика
Общие операции:
Команда
Назначение
show os summary
Получить сводку состояния DIP-инфраструктуры
46.3
Установка обновления
Для начала установки DIP-пакет обновления должен быть скопирован в локальную файловую
систему маршрутизатора. Это может сделать администратор с помощью команд привилегирован-
ного режима «copy» или «ssh get» (п. 28.4). В случае локального обновления источником пакета
обновления будет служить флеш-диск. В случае удаленного копирования (с помощью команды
«ssh get»), между рабочим местом администратора и маршрутизатором должен быть установлен
доверенный канал передачи информации. Копирование обновлений без установления доверен-
ного канала передачи информации не допускается.
Локальными хранилищами файлов на диске маршрутизатора являются пространства имен
«file:» и «share:». Хранилище «file:» доступно только из текущей загруженной версии системы.
Каждая установленная версия системы имеет собственное хранилище «file:»,
недоступное для других версий. Хранилище «share:» доступно для всех установленных систем.
Это хранилище может быть использовано для передачи данных между разными версиями уста-
498
новленных ОС.
Копирование может быть выполнено при помощи команды:
Router# copy flash0.1:/dionisnx−1.0−0.x86_64.dip file:
После этого можно начать установку обновления:
Router# os install file:/dionisnx−1.0.1.x86_64.dip
Если операция прошла успешно, на машине будет установлено две системы
. Список
установленных систем можно получить с помощью команды:
Router# show os
Можно получить подробную информацию о конкретной установленной системе при помощи
команды:
Router# show os info dionisnx−1.0−0
Любой установленный пакет ОС может быть переименован. Новое название должно быть уни-
кально:
Router# os rename dionisnx−1.0−0 mysystem
После этого пакет ОС в системе идентифицируется новым именем «mysystem».
Если какой-либо пакет ОС устарел и не используется, его можно удалить:
Router# os remove dionisnx−0.9−0
46.4
Параметры загрузки
После установки обновления нужно указать первичному загрузчику, какую из установлен-
ных систем следует загружать по умолчанию. Следующая команда покажет текущие установки
первичного загрузчика:
Router# show boot
0 dionisnx−1.0−0 (D) (F) (C)
1 dionisnx−1.0−1
Первое поле - порядковый номер установленной системы (начиная с 0). Второе - идентифи-
катор установленной системы. Отображаемые в строке признаки имеют следующее значение:
• (D) - (default). После перезагрузки данная система будет загружена по-умолчанию;
• (F) - (fallback). При возникновении проблем с загрузкой системы по-умолчанию (помечен-
ной флагом »(D)»), произойдет откат к системе, помеченной флагом »(F)» (резервная си-
стема);
• (C) - (current). Текущая система, т.е. система, загруженная сейчас;
• (E15) - (experimental). Система загружена в «экспериментальном» режиме. Описание экспе-
риментального режима работы ОС приведено в данном разделе ниже. Число после символа
«E» означает количество минут до перезагрузки;
499
• (d) - (user default). Система была помечена администратором, как система по умолчанию,
но по какой-либо причине произошел откат к резервной системе.
Указать загрузчику, какая система является загружаемой по умолчанию, а какая является
резервной, можно следующими командами:
Router# boot default dionisnx−1.0−1
Router# boot fallback dionisnx−1.0−0
Типичные параметры первичного загрузчика при локальном обновлении системы:
Router# show boot
0 dionisnx−1.0−0 (F) (С)
1 dionisnx−1.0−1 (D)
Старая система становится резервной. По умолчанию загружается новая система.
Для удаленного обновления предусмотрен дополнительный механизм, обеспечивающий до-
ступ администратора к системе при возникновении проблем со вновь установленной системой -
работа в экспериментальном режиме. Администратор может пометить систему, как «эксперимен-
тальную». При загрузке экспериментальной системы будет взведен специальный таймер и, по
истечении указанного тайм-аута, маршрутизатор будет автоматически перезагружен. После пе-
резагрузки экспериментальной системы произойдет автоматический откат к резервной системе.
Механизм работы в экспериментальном режиме позволяет защититься от неверных сетевых на-
строек в новой системе, при которых удаленный администратор потеряет возможность входа в
систему. Если новая система загрузилась успешно и доступна, администратор может дать команду
для снятия экспериментального режима. После этого таймер будет остановлен и автоматической
перезагрузки не произойдет.
Установка экспериментального режима:
Router# boot experimental dionisnx−1.0−1 15
Последним параметром задается время в минутах до автоматической перезагрузки. После этой
команды, параметры первичного загрузчика будут выглядеть так:
Router# show boot
0 dionisnx−1.0−0 (F) (C)
1 dionisnx−1.0−1 (D) (E15)
Предположим, что экспериментальная система загрузилась успешно и доступна. Администра-
тор может войти в систему и узнать текущий статус системы и время, оставшееся до автоматиче-
ской перезагрузки:
Router# show boot experimental
Далее администратор может снять экспериментальный режим и сделать новую систему “си-
стемой по умолчанию”:
Router# no boot experimental dionisnx−1.0−1
Router# boot default dionisnx−1.0−1

 

 

 

 

 

 

 

содержание      ..     8      9      10      11     ..