Запасной VPN (ipsec failover high availability stateless)

0. Вводная

Думаю не нужно объяснять зачем это нужно и где применяется.  Всё просто - если для вас потеря vpn соединения критична и работа останавливается, возможно стоит подумать о конфигурировании некоторой избыточности. Основных подходов в данном случае два:

- отказоустойчивый узел из двух или более устройств при этом активным является только одно устройство и данные о сессиях протокола более высокого уровня не синхронизируются между устройствами (stateless);
- отказоустойчивый узел из двух или более устройств, активно только одно, данные о сессиях синхронизированы (stateful).

Как очевидно основное отличие между двумя подходами в том, что при переключении с основного на резервное устройство и наборот текущие сессии ipsec сбрасываются. Конечно ситуация отрабатывается протоколами инкапсулироваными в ipsec пакеты, как tcp/udp, и скорее всего произойдет только некоторое "замораживание" соединения. Из опыта могу сказать, что задержка обычно немногим больше задержки возникающей при создании нового туннеля. Для большинства приложений этого достаточно.

1. Схема

Шифрации подлежит трафик
10.10.200.0/24  <-> 10.10.1.0/24
10.10.100.0/24  <-> 10.10.1.0/24

2. Конфигурация

Удивительно, но процесс настройки оказался достаточно простым. Основой всего является протокол HSRP (если словосочетание незнакомо, крайне рекомендую пройтись по ссылке) и ipsec собственно. Я не буду вдаваться в нюансы настройки HSRP или ipsec, для этого были написаны специальные заметки - HSRP, static ipsec . :)

По сути изменяется всего две команды.
В первую очередь необходимо добавить имя в конфигурацию hsrp

//конфигурация hsrp, добавлено имя
vpn0(config-if)#standby version 2
vpn0(config-if)#standby 100 ip 10.10.11.1
vpn0(config-if)#standby 100 priority 150
vpn0(config-if)#standby 100 preempt
vpn0(config-if)#standby 100 name vpn

Вторая команда - при применении crypto map к интерфейсу указывается имя hsrp группы которая будет обеспечивать отказоустойчивость.
//применение отказоустойчивого vpn
vpn0(config-if)#crypto map cr_outside redundancy vpn

В качестве дополнения приведу полную конфигурацию.

vpn0
Базовая конфигурация

crypto isakmp policy 200
 encr aes
 authentication pre-share
 group 2
crypto isakmp key MyKey address 10.10.10.10
!
crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac
!
crypto map cr_outside 200 ipsec-isakmp
 set peer 10.10.10.10
 set transform-set ts-aes-sha
 match address 120
!
interface FastEthernet0/0
 ip address 10.10.11.10 255.255.255.0
 duplex auto
 speed auto
 standby version 2
 standby 100 ip 10.10.11.1
 standby 100 priority 150
 standby 100 preempt
 standby 100 name vpn
 crypto map cr_outside redundancy vpn
!
access-list 120 permit ip 10.10.200.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.200.0 0.0.0.255
access-list 120 permit ip 10.10.100.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.100.0 0.0.0.255

vpn1
Совершенна идентична vpn0 за исключением адреса интерфейса и приоритета hsrp


crypto isakmp policy 200
 encr aes
 authentication pre-share
 group 2
crypto isakmp key MyKey address 10.10.10.10
!
crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac
!
crypto map cr_outside 200 ipsec-isakmp
 set peer 10.10.10.10
 set transform-set ts-aes-sha
 match address 120


interface FastEthernet0/0
 ip address 10.10.11.20 255.255.255.0
 duplex auto
 speed auto
 standby version 2
 standby 100 ip 10.10.11.1
 standby 100 priority 101
 standby 100 preempt
 standby 100 name vpn
 crypto map cr_outside redundancy vpn


access-list 120 permit ip 10.10.200.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.200.0 0.0.0.255
access-list 120 permit ip 10.10.100.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.100.0 0.0.0.255

client1
Простейшее из возможного

crypto isakmp policy 200
 encr aes
 authentication pre-share
 group 2
crypto isakmp key MyKey address 10.10.11.1
!
crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac
!
crypto map cr_outside 200 ipsec-isakmp
 set peer 10.10.11.1
 set transform-set ts-aes-sha
 match address 120

interface FastEthernet0/0
 ip address 10.10.10.10 255.255.255.0
 duplex auto
 speed auto
 crypto map cr_outside

access-list 120 permit ip 10.10.200.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.200.0 0.0.0.255
access-list 120 permit ip 10.10.100.0 0.0.0.255 10.10.1.0 0.0.0.255
access-list 120 permit ip 10.10.1.0 0.0.0.255 10.10.100.0 0.0.0.255


3. Проверка
Проверялось всё это хозяйство путем установки telnet сессии с маршрутизатора srv на client1 и принудительной остановкой интерфейса FastEthernet0/0 на vpn0. Показательно, что сессия telnet при этом не разорвалась хотя "замерла" на примерно 10-15 секунд.

Также необходимо обратить внимание на правильную маршрутизацию внутри vpn рутеров, в моём случае это сделано с помощью простейшей конфигурации ospf, подобной описанной в одной из прошлых заметок, однако можно использовать тот же hsrp с опцией трекинга outside интерфейса.

Динамический рутинг поверх vpn (ospf over gre ipsec)

0. Зачем
После прочтения заметки о конфигурации gre ipsec может остаться некоторое недопонимание того зачем, собственно, так усложнять достаточно простую первоначальную конфигурацию.
Данная запись призвана ответить на эти вопросы.
Тем читателям, которые попали сюда по поиску из google или еще каким путем я настоятельно рекомендую прочитать предыдущую часть о настройке gre ipsec, а уже потом возвращаться сюда.
Итак речь идёт о запуске динамических протоколов маршрутизации, в данном случае ospf, поверх существующего vpn соединения.
В случае статической конфигурации, необходимо жесткое указание сетей подлежащих шифрованию. Для этого в конфигурации без gre используются crypto acl.
Если же конфигурация сетей меняется необходимо менять и конфигурацию. Представим довольно жизненную ситуацию - головной офис и определённое количество филиалов.
С случае появления в головном отделении новых ip сетей, необходимо произвести перенастройку всех рутеров, как в центрального так и филиальных. При большом количестве филиалов это может быть непосильной задачей.


1. Описание стенда
Настройка продолжается ровно с того места на котором закончилась статья о конфигурировании gre ipsec. Итак у нас есть следующая конфигурации IP сетей.

Внутренняя сеть А: 192.168.1.0/24
Внутренняя сеть Б: 192.168.2.0/24

Внешний интерфейс А: 10.10.11.2/24
Внешний интерфейс Б: 10.10.10.2/24

Допустим, что А это филиал, а Б головное отделение. В случае статического ipsec туннеля указание какой трафик подлежит шифрации с помощью crypto acl.
// routerA
RouterA(config)# access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255

В случае gre ipsec необходимо статическим маршрутом указать куда напрявлять трафик для определённой сети.
RouterA(config)# ip route 192.168.2.0 255.255.255.0 Tunnel10
После этого трафик попадает в туннель, инкапсулируется в gre, а crypto acl настроеные между пирами пропускали его через процедуру шифрации.

Теперь представим, что в центральном офисе (сеть Б) появилась новая сеть, например 10.200.1.0/24, для обеспечения её видимости в филиалах, необходимо либо добавить по строчке вcrypto acl (static ipsec) либо добавить маршрут (gre ipsec ), что конечно не составляет проблемы для десятка устройств. Но мы же помним, что организация у нас большая и туннелей условно бесконечное количество. :)


2. Конфигурация
Простейшая конфигурация ospf достаточно проста и не вызывает особых проблем. Я не буду рассказывать о принципах работы, алгоритме или прочих ньансах работы этого протокола. В сети достаточно много информации по этой теме. Цель данной заметки показать практическое применение и не дать себе забыть эту простую но в то же время крайне эффективную конфигурацию. :)
Описание настройки.
- число после слова ospf обозначает просто номер процесса ospf на данном устройстве, нет смысла стремиться к его идентичности
- логирование изменений
- ключевая строка, описание сети которые будут анонсироваться от данного рутера. О том что такое area можно говорить долго, но не сейчас. Обратите внимание, используется не маска сети, а wildcard, как в acl.


//Настройка ospf. RouterA
RouterA(config)# router ospf 100
RouterA(config-router)# log-adjacency-changes
RouterA(config-router)# network 192.168.1.0 0.0.0.255 area 10

Практически анологична настройка ospf на рутере Б, исключение составляет дополнительная сеть.

//Настройка ospf. RouterB
RouterB(config)# router ospf 100
RouterB(config-router)# log-adjacency-changes
RouterB(config-router)# network 10.150.1.0 0.0.0.255 area 10
RouterB(config-router)# network 192.168.2.0 0.0.0.255 area 10

В принципе в документации сказано о том, что для указания процессу ospf работать на конкретном интерфейсе необходимо указать сеть относящуюся к данному интерфейсу в конфигурации network.
Т.е. в данном случае сети 10.10.11.0/24 и 10.10.10.0/24 также должны быть указаны. Если у вас версия IOS менее чем 12.4 так и придется сделать. Я же сделаю немного по-другому.
//Настройка ospf. RouterA
RouterA(config)# interface Tunnel10
RouterA(config)# ip ospf 100 area 10

Это просто указание процессу работать на данном интерфейсе. Об этом трюке я узнал от простого словацкого парня Ивана, чей блог я с удовольствием читаю.
После настройки ospf указание статического маршрута более не нужно. Т.е. для рутера А.
//удаление статического маршрута
RouterA(config)# no ip route 192.168.2.0 255.255.255.0 Tunnel10

Теперь можно взглянуть на таблицу маршрутизации во всей красе.

RouterA#sh ip route | beg Gateway
Gateway of last resort is 10.10.11.1 to network 0.0.0.0

10.0.0.0/8 is variably subnetted, 4 subnets, 2 masks
C 10.10.11.0/24 is directly connected, FastEthernet1/0
O 10.150.1.0/24 [110/11122] via 10.10.10.2, 00:00:22, Tunnel10
C 192.168.1.0/24 is directly connected, FastEthernet0/1
O 192.168.2.0/24 [110/11121] via 10.10.10.2, 00:00:22, Tunnel10
S* 0.0.0.0/0 [1/0] via 10.10.11.1

Как видно, анонсы сетей прошли и рутер А видит маршруты в сети за рутером Б через ospf, что и было необходимо.
Теперь при появлении в центральном отделении новых сетей, конфигурация филиалов не нуждается в изменениях. Всё что необходимо, добавить новую строчкуnetwork в конфигурацию ospf на рутере в центральном офисе. Филиалы узнают об этом практически мгновенно. :)

upd 14.05.08, спасибо Vadim
//Посмотрим на наших соседей.
RouterA#show ip ospf neighbor

Neighbor ID Pri State Dead Time Address Interface
192.168.2.1 0 FULL/ - 00:00:37 10.10.10.2 Tunnel10

Соединяя офисные пространства (lan-2-lan ipsec vpn gre)

0. Вводная
Продолжим разборки с различными технологиями vpn предоставляемыми рутерами cisco. Заметка будет больше практического характера. Ориентирована на тех, кто уже знаком с общей теорией работы ipsec и простейшими примерами построения туннелей. Итак, сегодня в качестве примера рассмотрим построение всё такого-же статического туннеля. Отличие только в том, что в данном примере, все пакеты подлежащие шифрованию будут сначалаинкапсулироваться в gre туннель и только потом в ipsec . Зачем такая сложность может ответить любой кто сталкивался с необходимостью пропускать через туннель мультикаст пакеты, которые в свою очередь любят использовать современные протоколы динамической маршрутизации. Впрочем, обо всём по порядку.
Адресация сети снова выглядит следующим образом.

Внутренняя сеть А: 192.168.1.0/24
Внутренняя сеть Б: 192.168.2.0/24

Внешний интерфейс А: 10.10.11.2/24
Внешний интерфейс Б: 10.10.10.2/24

Между внешними интерфейсами у меня находиться pix. В данном случае это не так важно, но он поможет сниффить проходящий траффик.

1. Труба (она же туннель).
Итак, необходимо установить туннель между внешними интерфейсами маршрутизаторов, в данном случае 10.10.11.2 и 10.10.10.2.
Минимальные параметры настройки:
- каждый туннель "привязывается" к конкретному физическому интерфейсу, в данном случае это FastEthernet 1/0.
- поскольку это layer 3 соединения, необходима ip адресация. Для уменьшения путаницы с "лишними" адресами будем использовать адреса физических интерфейсов. Ссылка.
- совершенно очевидно, что раз есть у туннеля начало, значит еть где-то и конец :) Указание второго пира, также обязательный параметр.
В примере приведена конфигурация только одной стороны туннеля, очевидно другая сторона конфигурируется идентично за исключением адреса пира.

//пример конфигурации gre туннеля
RouterA(config)# interface Tunnel10
RouterA(config-if)# tunnel source FastEthernet1/0
RouterA(config-if)# tunnel destination 10.10.10.2
RouterA(config-if)# ip unnumbered FastEthernet1/0

Итак туннель поднят, но не совсем понятно для каких целей, поскольку по нему еще ничего не ходит. Развернем рутинг для сетей 192.168.1.0/24 и 192.168.2.0/24, соответственно в сторону туннеля.
//рутинг в туннель
RouterA(config)# ip route 192.168.2.0 255.255.255.0 Tunnel10

Для рутера Б, нужно развернуть сеть 192.168.1.0/24.
Теперь внутренние сети находящиеся за рутерами видят друг друга.
//простейшая проверка - ping
RouterA#ping
Protocol [ip]:
Target IP address: 192.168.2.1
Repeat count [5]:
Datagram size [100]:
Timeout in seconds [2]:
Extended commands [n]: y
Source address or interface: 192.168.1.1
Type of service [0]:
Set DF bit in IP header? [no]:
Validate reply data? [no]:
Data pattern [0xABCD]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Sweep range of sizes [n]:
Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 192.168.2.1, timeout is 2 seconds:
Packet sent with a source address of 192.168.1.1
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 32/61/104 ms


Как видно пинг проходит успешно, но всегда интересно посмотреть, что же там внутри туннеля, для этих целей на стенде используется PIX с правильно настроеным capture.

// sniff
pixfirewall# show cap anyin
10 packets captured
1: 16:01:56.004577 10.10.11.2 > 10.10.10.2: ip-proto-47, length 104
2: 16:01:56.024870 10.10.10.2 > 10.10.11.2: ip-proto-47, length 104
(skip)
9: 16:01:56.232715 10.10.11.2 > 10.10.10.2: ip-proto-47, length 104
10: 16:01:56.249163 10.10.10.2 > 10.10.11.2: ip-proto-47, length 104
10 packets shown

Как и предпологалось, туннель работает нормально. Протокол 47 стека IP И есть gre.

2. Шифруем

Дальше всё просто. Принципиальных отличий между данной и минимальной конфигурацией практически никаких. Всё что нужно сделать это изменить crypto acl определяющий какой трафик подлежит шифрации.
Поскольку сниффер нам показал только gre пакеты между двумя пирами шифровать будем только их. Что в принципе достаточно очевидно. :)
//crypto acl, конечно они должны быть зеркальны с обоих сторон туннеля
RouterA(config)# access-list 150 permit gre host 10.10.11.2 host 10.10.10.2


isakmp, crypto map и прочие безобразия настраиваются совершенно идентично. На всякий случай привожу кусок конфигурации рутера А.

//пример окончательной конфигурации
!
crypto isakmp policy 200
encr aes 256
authentication pre-share
group 2
lifetime 36000
crypto isakmp key sUpeRkEy address 10.10.10.2
!
crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac
!
crypto map cr_outside 200 ipsec-isakmp
set peer 10.10.10.2
set transform-set ts-aes-sha
match address 150
!
interface Tunnel10
ip unnumbered FastEthernet1/0
tunnel source FastEthernet1/0
tunnel destination 10.10.10.2
!
interface FastEthernet1/0
ip address 10.10.11.2 255.255.255.0
duplex auto
speed auto
crypto map cr_outside
!
ip route 192.168.2.0 255.255.255.0 Tunnel10
!
access-list 150 permit gre host 10.10.11.2 host 10.10.10.2
!

// Проведем то же элементарное тестирование с помощью ping. Ниже представлен вывод сниффера.
pixfirewall# show capture anyin
17 packets captured
1: 15:33:57.516788 10.10.11.2.500 > 10.10.10.2.500: udp 144
2: 15:33:57.741477 10.10.10.2.500 > 10.10.11.2.500: udp 104
3: 15:33:57.911284 10.10.11.2.500 > 10.10.10.2.500: udp 304
4: 15:33:58.126153 10.10.10.2.500 > 10.10.11.2.500: udp 304
5: 15:33:58.186025 10.10.11.2.500 > 10.10.10.2.500: udp 108
6: 15:33:58.206059 10.10.10.2.500 > 10.10.11.2.500: udp 76
7: 15:33:58.219852 10.10.11.2.500 > 10.10.10.2.500: udp 172
8: 15:33:58.259401 10.10.10.2.500 > 10.10.11.2.500: udp 172
9: 15:33:58.268388 10.10.11.2.500 > 10.10.10.2.500: udp 60
10: 15:33:59.395807 10.10.11.2 > 10.10.10.2: ip-proto-50, length 164
11: 15:33:59.444541 10.10.10.2 > 10.10.11.2: ip-proto-50, length 164
(skip)
17: 15:33:59.556703 10.10.10.2 > 10.10.11.2: ip-proto-50, length 164
17 packets shown

Как и ожидалось, конфигурация работает и даже шифрует трафик.
Первые 9 пакетов показывают обмен небольшими udp пакетами по 500 порту. Этот порт используется isakmp при установлении SA.
Далее идёт обмен пакетами протокола 50 стека IP, что и есть, собственно, ipsec.

Соединяя офисные пространства (lan-2-lan vpn pre-shared)

0. Общие слова
Зачем нужен vpn и что с ним делать рассказывать не буду, в сети достаточно много информации на эту тему. Скажу только, что под vpn подразумевается ipsec и в данной заметке описывается построение site to site vpn используя pre-shared keys, т.е. соединение двух локальных сетей, например центрального отделения и филиала через открытую сеть типа интернет. Используемое оборудование - рутер cisco. Заметка сугубо практическая, поскольку рассмотрение теории займет достаточно много места и времени. Краткий обзор: что происходит при построении ipsec туннеля можно найти в одной из предыдущих заметок.

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

Внутренняя сеть А: 192.168.1.0/24
Внутренняя сеть Б: 192.168.2.0/24

Внешний интерфейс А: 10.10.11.2/24
Внешний интерфейс Б: 10.10.10.2/24


Необходимо убедиться, что существующие acl совместимы с ipsec. Как требует документация необходимо разрешить прохождения трафика по протоколам 51 (ah) и 50 (esp) стека ip, зависит от желаемой конфигурации. Порт 500/udp и echo/echo-replay. Впрочем без разрешенного icmp у меня туннель заработал.

1. Установка триггера на трафик подлежащий шифрованию

Задача, соответственно, состоит в том, чтобы позволить пользователям из сети 192.168.1.0/24 получать доступ к компьютерам находящимся в сети 192.168.2.0/24 и наоборот.
На первом этапе ipsec рутер просматривает проходящий через него трафик и если находит пакет совпадающий с определенным acl, шифрует его и передает дальше. Таким образом первая задача - определить трафик подлежащий шифрованию с помощью acl. Логично, что acl должны быть совершенно зеркальны на обоих сторонах туннеля, поскольку SA создаются уникальные для source и destination в прямом и обратном направлении. Соответственно, если acl будут не зеркальны, то и туннель не установится.

//Пример acl
// routerA
RouterA(config)# access-list 120 permit ip 192.168.1.0 0.0.0.255 192.168.2.0 0.0.0.255
// routerB
RouterB(config)# access-list 120 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255


2. Первая фаза IKE
Следующий этап - создание IKE SA.
Поскольку на каждому рутере может создаваться несколько IKE SA для различных туннелей с различными настройками безопасности используются политики IKE с различными уровнями приоритета (<1-10000), id="ce4u">Каждая политика характеризуется следующими параметрами: алгоритм шифрования, алгоритм хеширования, метод аутентификации, используемая реализация алгоритма Диффи-Хелмана, время жизни SA. Настройки по-умолчанию можно посмотреть следующим образом:

//политика IKE по-умолчанию
RouterA#sh crypto isakmp policy

Global IKE policy
Default protection suite
encryption algorithm: DES - Data Encryption Standard (56 bit keys).
hash algorithm: Secure Hash Standard
authentication method: Rivest-Shamir-Adleman Signature
Diffie-Hellman group: #1 (768 bit)
lifetime: 86400 seconds, no volume limit

Минимально необходимых, а мы сейчас говорим именно о них, параметров не так много. В данном случае изменим метод аутентификации на pre-shared keys, заменим не рекомендуемый аглоритм шифрования данных, на продвинутый (DES & AES) и Диффи-Хелмана на вторую группу, 1024 бита.
Поскольку в качестве метода аутентификации выбран метод распределенного ключа, его необходимо также указать.
Манипуляции производятся следующими командами.

// Настройки необходимые для IKE SA, в данном случае политика с приоритетом 200
// ключ указывается отдельно от политики, поскольку в общем случае он почти ничего общего с ней не имеет,
// политика может использоваться многократно для нескольких туннелей. Ключ желательно оставлять уникальным для каждого пира.
// Конечно, настройки для рутера Б должны быть идентичны за исключением адреса другого конца туннеля.
RouterA(config)# crypto isakmp policy 200
RouterA(config-isakmp)# encr aes
RouterA(config-isakmp)# authentication pre-share
RouterA(config-isakmp)# group 2
RouterA(config)# crypto isakmp key sUpeRkEy address 10.10.10.2

3. Вторая фаза IKE
В рамках второй фазы IKE происходит установка ipsec SA которые потом будут использоваться непосредственно для шифрования трафика.
Для этого необходимо указать желаемые параметры: алгоритм и шифрования и хеширования. Происходит это путем создания так называемого transform-set.

// В данном случае:
// ts-aes-sha - имя данного transform-set
// esp-aes 256 - алгоритм шифрования и длина его ключа
// esp-sha-hmac - алгорим хеширования
RouterA(config)# crypto ipsec transform-set ts-aes-sha esp-aes 256 esp-sha-hmac

Следущим этапом идет создание специальной крипто карты, которая связывает всё вместе. Именно эта карта потом привязывается к конкретному интерфейсу.
Поскольку для каждого интерфейса может быть определена только одна крипто карта, здесь используется тот же принцип приоритетов, позволяющий создавать туннели к разным пирам и с различными параметрами безопасности.
Параметров не так много: адрес другого конца туннеля, имя желаемомого transform-set, acl который будет использваться как триггер для данной крипто карты.

//Пример crypto map
RouterA(config)# crypto map cr_outside 200 ipsec-isakmp
RouterA(config-crypto-map)# set peer 10.10.10.2
RouterA(config-crypto-map)# set transform-set ts-aes-sha
RouterA(config-crypto-map)# match address 120

4. Нормальная работа
Почти всё необходимые настойки произведены, осталось только указать интерфейс используемый как источник для создния туннеля и включить "глобальный выключатель" разрешающий использовать IKE и слушать 500/udp порт.

//Привязка созданной крипто карты к интерфейсу
RouterA(config-if)#crypto map cr_outside

//Включить IKE
RouterA(config)#crypto isakmp enable

Туннель создается не сразу, а только после появления трафика подлежащего шифрованию. Посмотреть реально ли создан туннель и шифруется ли трафик можно с помощью следущей команды:

// Просмотр активных туннелей
RouterA#sh crypto engine connections active
ID Interface IP-Address State Algorithm Encrypt Decrypt
2001 FastEthernet1/0 10.10.11.2 set AES256+SHA 9 0
2002 FastEthernet1/0 10.10.11.2 set AES256+SHA 0 9

Насколько видно из примера, создано две SA каждая используется для одного направления. В данном случае SA c ID 2001 используется для шифрования, а c ID 2002 для расшифровывания, что видно по счетчикам пакетов.

Более подробную информацию может дать команда show crypto ipsec sa.

// Доступные SA на рутере.
RouterA#sh crypto ipsec sa

interface: FastEthernet1/0
Crypto map tag: cr_outside, local addr 10.10.11.2

protected vrf: (none)
local ident (addr/mask/prot/port): (192.168.1.0/255.255.255.0/0/0)
remote ident (addr/mask/prot/port): (192.168.2.0/255.255.255.0/0/0)
current_peer 10.10.10.2 port 500
PERMIT, flags={origin_is_acl,}
#pkts encaps: 9, #pkts encrypt: 9, #pkts digest: 9
#pkts decaps: 9, #pkts decrypt: 9, #pkts verify: 9
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0
#pkts not decompressed: 0, #pkts decompress failed: 0
#send errors 1, #recv errors 0

local crypto endpt.: 10.10.11.2, remote crypto endpt.: 10.10.10.2
path mtu 1500, ip mtu 1500
current outbound spi: 0xB2259128(2988806440)

inbound esp sas:
spi: 0x8A02CA5F(2315438687)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2002, flow_id: SW:2, crypto map: cr_outside
sa timing: remaining key lifetime (k/sec): (4533541/3425)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xB2259128(2988806440)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2001, flow_id: SW:1, crypto map: cr_outside
sa timing: remaining key lifetime (k/sec): (4533541/3425)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE


inbound ah sas:

inbound pcp sas:

outbound esp sas:
spi: 0xB2259128(2988806440)
transform: esp-256-aes esp-sha-hmac ,
in use settings ={Tunnel, }
conn id: 2001, flow_id: SW:1, crypto map: cr_outside
sa timing: remaining key lifetime (k/sec): (4533541/3363)
IV size: 16 bytes
replay detection support: Y
Status: ACTIVE

outbound ah sas:

outbound pcp sas:

Фазы (этапы) IPSec

Сырая версия, но ньансов настолько много, что хочеться записать то что помниться, чтобы потом дополнять.
Итак, поговорим о ipsec. Знать это полезно при траблшутинге проблем связаных с установлением VPN туннеллями.

1. Определение трафика подлежащего шифрованию.
Чаще всего используеются так называемые crypto acl.

2. Первая фаза IKE.
2.1. Аутентификация обоих концов туннеля.
2.2. Создается IKE SA которая используется для защиты процесса IKE.
2.3. Выполняется алгоритм Диффи-Хелмана, который гарантирует, что на каждом конце туннеля будет использоватся одинаковый shared secret, без пересылания этого shared secret.
2.4. Создается туннель для работы второй фазы IKE.


Первая фаза IKE может проходить в двух режимах:
- Main mode
проходит в три этапа:
- согласование используемых алгоритмов
- обе стороны используеют алгоритм Диффи-Хелмана для определения ключей
- используя ключи стороны аутентифицируют друг-друга.
- Aggressive mode
Все что посылается в Main mode в три этапа, посылается в одном пакете. Основная проблема, что стороны обмениваются информацией до того как безопасное соединение будет установлено.

3. Вторая фаза IKE.
Основаня задача этого этапа подготовить IPSec SA которые будут использоватся непосредственно для шифрования трафика. Сюда входит согласование параметров и собственно установка.
IPSec может переходить из фазы 4 к фазе 4 и назад в нескольких случаях:

- каждая SA имеет определенное время жизни (например 1 час в Checkpoint), соостветственно по истечении этого часа необходимо пересоздать SA.
При этом для создания новой SA используется тот же shared secret, что и раньше.
- использование perfect forward secrecy (PFS). Алгоритм PFS гарантирует, что при создании новой SA предыдущий shared secret использоватся не будет, более того не будет никакой корреляции между старым и новым shared secret. Для реализации PFS используется алгоритм Диффи-Хелмана в quick mode.

Quick mode: для ренерации новой SA используется текущая SA (нет отброса на первую фазу IKE).


4. Нормальная работа.
На этой фазе туннель работает в нормальном режиме шифруя и расшифровывая трафик.

5. Закрытие туннеля.
Может быть принудительным (clear SA) либо по истечении тайм-аута.