Надеюсь, данная статья станет справочным материалом, который может потребоваться при дизайне сети, или при её апдейте, или для того, чтоб освежить в памяти механизм работы того либо другого VPN-на.

Сначала статьи описаны главные моменты стека протоколов IPSec, потому что внедрение данного эталона дальше будет очень нередко встречаться. В конце параграфа об IPSec были включены самые нередкие предпосылки неработоспособности IPSec канала, также главные шаги по их устранению.

Типы VPN соединений

Ниже систематизированы VPN-ы, которые доступны для опции в корпоративной сети. Технологии распределены по уровню предоставляемых клиенту каналов по модели OSI (рис 1):

Прирастить

Как раз VPN-ы для корпоративных сетей подвергнутся рассмотрению в данной статье.

Схема VPN-ов относительно способности пропуска мультикаста и работы протоколов маршрутизации (рис. 2):

Прирастить
Дополнительно приводится структурированная схема VPN-ов (рис.3), которые могут предоставляться провайдером, но в данной статье тщательно они не рассматриваются:

Прирастить

Итогом работы по классификации VPN-ов и исследованию их масштабируемости послужила итоговая таблица, в которую заносилась общая информация по типу протокола VPN-а, его особенности, и самое принципиальное, что нужно сделать, если к имеющимся VPN-ам подключить очередной.
В таблице представлены результаты опций, исследование приобретенного формата пакета, настройка протокола маршрутизации (OSPF) через VPN-ы, также рассмотрены вопросы масштабируемости протокола.

Таблица VPN

Установление IPSec, сообщения, режимы работы.

В процессе установления соединения через IPSec двум участникам защищенного канала нужно согласовать значимый ряд характеристик: по необходимости они должны аутентифицировать друг дружку, сгенерировать и поменяться общими ключами (при этом через недоверенную среду), установить какой трафик шифровать (от какого отправителя и к какому получателю), также условиться при помощи каких протоколов шифровать, а при помощи каких — аутентифицировать. Служебной инфы подразумевается поменяться много, не правда ли? По этой причине IPSec и состоит из стека протоколов, обязанность которых обеспечить установление, работу и управление защищенным соединением. Процесс установления соединения состоит из 2 фаз: 1-ая фаза устанавливается для того, чтоб обеспечить неопасный обмен ISAKMP сообщений во 2-ой фазе. А ISAKMP (Internet Security Association and Key Management Protocol) служит для согласования политик безопасности (SA) меж участниками VPN соединения, в который как раз и определяются при помощи какого протокола шифровать (AES, 3DES, DES), и при помощи чего аутентифицировать (HMAC SHA, MD5).

Режим работы IKE (Internet Key Exchange):

IKE Фаза 1

(опционально) аутентификация пиров
Согласование IKE SA меж пирами

Main Mode (6 сообщений)
[First exchange] Начало согласований начинаются с отправки пиром друг дружке предложений о поддерживаемом шифровании, протоколов аутентификации самих сообщений IKE, времени жизни ассоциаций безопасности. Пир выбирает предложенный SA и посылает их предложившему пиру. Эти опции определяются в ISAKMP Policy
[Second exchange] Генерация общих разделяемых ключей через обмен открытыми ключами по Diffie-Hellman. Предстоящий обмен сообщениями происходит уже зашифрованными сообщениями.
[Third exchange] Обмен сообщениями для аутентификации ISAKMP сессии (IKE_I_MM4)

После установки IKE SA (другими словами установления 1-ой фазы), происходит согласование IPSEC в quick mode (QM). Сообщения режима Main Mode (MM):
- IKE_READY New State = IKE_I_MM1
- IKE_I_MM1 New State = IKE_I_MM2
- IKE_I_MM2 New State = IKE_I_MM3
- IKE_I_MM3 New State = IKE_I_MM4
- IKE_I_MM4 New State = IKE_I_MM5
- IKE_I_MM5 New State = IKE_I_MM6
Aggressive Mode (3 сообщения)
Зачинателем в 1-ое сообщение помещается предложение о шифровании, протоколе аутентификации самих сообщений IKE, времени жизни ключей, сообщения об обмене ключами Диффи-Хеллмана (DH), идентификатор сессии, её аутентификация.
Команда для диагностики данной фазы на оборудовании Cisco **show crypto isakmp sa

IKE Фаза 1.5

Не употребляется в стандартном peer-to-peer VPN соединении, используется при организации удаленных подключений.
Имеет два режима:
Xauth (User Authentication)
Дополнительная аутентификация юзеров в границах IKE протокола. Для этого употребляется протокол Extended Authentication.

Mode config (Push Config)
Передается дополнительная информация клиенту о IP адресе, маске, DNS-серверах и т.д.

IKE Фаза 2

IPsec SAs/SPIs
На этом шаге ISAKMP несет ответственность за обмен сессионными ключами и согласование политик безопасности (SA) для обеспечения конфиденциальности и целостности пользовательского трафика. В настройке (в Cisco IOS) за это отвечает transform-set.
Quick mode
QM делает все то, что и IPSec SAs/SPIs за наименьшее количество служебных сообщений. По аналогии с Aggressive Mode.
Разглядим пример обмена служебными сообщениями во время установления IPSec туннеля. Работающий вариант.

ФАЗА 2

А сейчас я предлагаю разглядеть пару примеров неработоспособности IPSec.

Case1

“Old State = IKE_I_MM1 New State = IKE_I_MM1”
Причина №1
Не условились по IKE proposal (предложенным IKE) в Фазе 1. На одной стороне указан 3des, на другом aes.

На маршрутизаторе отображается последующее состояние:

Причина №2
ACL на физическом интерфейсе блокируется трафик ISAKMP.

Case2

Если transform set на одном роутере один

…а на другом роутере другой

, то не сойдется SA IPSEC (не будет возрастать количество зашифрованных и расшифрованных пакетов

Case3

Если некорректно указали preshared key на IPSec пирах:

Тогда будет ошибка retransmitting phase 1 MM_KEY_EXCH