Надеюсь, данная статья станет справочным материалом, который может потребоваться при дизайне сети, или при её апдейте, или для того, чтоб освежить в памяти механизм работы того либо другого VPN-на.
Сначала статьи описаны главные моменты стека протоколов IPSec, потому что внедрение данного эталона дальше будет очень нередко встречаться. В конце параграфа об IPSec были включены самые нередкие предпосылки неработоспособности IPSec канала, также главные шаги по их устранению.
Типы VPN соединений
Ниже систематизированы VPN-ы, которые доступны для опции в корпоративной сети. Технологии распределены по уровню предоставляемых клиенту каналов по модели OSI (рис 1):
Прирастить
Как раз VPN-ы для корпоративных сетей подвергнутся рассмотрению в данной статье.
Схема VPN-ов относительно способности пропуска мультикаста и работы протоколов маршрутизации (рис. 2):
Прирастить
Дополнительно приводится структурированная схема VPN-ов (рис.3), которые могут предоставляться провайдером, но в данной статье тщательно они не рассматриваются:
Прирастить
Итогом работы по классификации VPN-ов и исследованию их масштабируемости послужила итоговая таблица, в которую заносилась общая информация по типу протокола VPN-а, его особенности, и самое принципиальное, что нужно сделать, если к имеющимся VPN-ам подключить очередной.
В таблице представлены результаты опций, исследование приобретенного формата пакета, настройка протокола маршрутизации (OSPF) через VPN-ы, также рассмотрены вопросы масштабируемости протокола.
Таблица VPN
Тип VPN | Настройка HUB | Настройка Spoke | Настройка HUB при добавлении нового Spoke | Настройка Spoke при добавлении другого нового Spoke | Внедрение протоколов динамической маршрутизации OSPF, EIGRP | Особенности |
Regular IPSec (crypto map) |
isakmp Crypto-map |
isakmp Crypto-map |
Да: isakmp, crypto-map: set peer, transform-set, crypto ACL |
Да: Для обеспечения связности меж Spoke-ми нужно добавить маршруты нового Spoke-a в crypto ACL всех имеющихся Spoke-ах |
Нет | Комфортен в случае кол-ва Spoke <5-10. Для обеспечения связности меж Spokе-ми через HUB требуется добавление в crypto ACL N сетей на N spoke-ах Очень немасштабируемый. |
Regular IPSec (Profile) | isakmp profile, IPSec Profile, сrypto-map |
isakmp profile, IPSec Profile, сrypto-map |
Да: crypto-map: set peer, crypto ACL |
Да: Добавление новых маршрутов в crypto ACL |
Нет | Очень не масштабируемый. Меньше конфигурации засчет объединения типовых опций в profile. |
Regular IPSec (Profile, Static VTI) | isakmp profile, IPSec Profile, VTI (Virtual Tunnel Interface) |
isakmp, IPSec Profile, VTI (Virtual Tunnel Interface) |
Да: isakmp, новый VTI (Virtual Tunnel Interface) |
Да static route до сетей уд. кабинета |
Да | В конфигурации SVTI без IGP – очень не масштабируемый. На каждый Spoke по SVTI. N spoke – N VTI и своя сабсеть. На Spoke требуется добавление маршрутов до удаленных Spoke-в. Пропускает multicast! По дефлоту на каждый SVTI только одна SA IPSec c traffic selector “IP any any.” Нет команды crypto ACL. В туннель заворачиваются те сети, которые определены через static route на SVTI. |
Regular IPSec (Profile, Static VTI and IGP) | isakmp, IPSec Profile, VTI (Virtual Tunnel Interface) |
isakmp, IPSec Profile, VTI (Virtual Tunnel Interface) |
Да: isakmp, новый VTI (Virtual Tunnel Interface) |
Нет | Да | Не масштабируемый. На каждый Spoke по SVTI. N spoke – N VTI и своя сабсеть. Маршруты от IGP попадают в туннель. |
IPSec with dynamic IP (Dynamic VTI and Static VTI and IGP) | keyring, isakmp policy, isakmp profile, ipsec profile, loopback for unnumbered interface (непременно), Virtual-Template type tunnel |
keyring, isakmp policy, isakmp profile, ipsec profile, loopback for unnumbered interface, Static VTI |
Нет | Нет | Да | Очень масштабируемый. Все spoke и hub находятся в одной сети! Dynamic VTI (DVTIs) также point-to-point интерфейс. В режиме point-to-multipoint соседство OSPF не устанавливается. Внедрение Unnumbered IP в качестве адреса DVTI непременно |
Easy VPN | ААА – для авторизации клиентов Isakmp, isakmp policy, isakmp profile, ipsec profile, interface, Virtual-Template type tunnel DHCP для клиентов |
Minimum IPsec client конфигурация, с указанием VPN-сервера, VPN группы, юзера для ааа, Указание внутренних и наружный интерфейсов. |
Нет | Нет | Да | Масштабируемый. Если ранее был настроен NAT/PAT, то перед внедрением EASY VPN должна быть эта конфигурация удалена. Есть особенности в настройке transform-set. |
GRE | Interface Tunnel, Static route |
Interface Tunnel, Static route |
Да Int tunnel, Static route |
Да Static route |
Да | Не масштабируемый. Образует P2P линк, на каждый туннель – своя сабсеть. Отлично подходит для туннелирования IGP протоколов. |
IGP over GRE | Interface Tunnel, Static route |
Interface Tunnel, Static route |
Да Int tunnel |
Нет | Да | Не масштабируемый. На каждый туннель – своя сабсеть. IGP протоколы работают через туннель при настройках по дефлоту. |
DMVPN (проприетарный) | DMVPN phase 1 – кон-ция только mGRE DMVPN phase 2 – настройка ipsec profile для защиты трафика |
Minimum: DMVPN phase 1 – кон-ция только mGRE DMVPN phase 2 – настройка ipsec profile для защиты трафика |
Нет | Нет: при добавлении нового spoke – туннель до него строится автоматом |
Да: EIGRP на HUB выключаем расщепление горизонта и сохранения себя в качестве next-hop в анонсах маршрута |
Более масштабируемый протокол. GRE multipoint. Туннели меж удаленными кабинетами создаются динамически. |
PPTP | Vpdn-group, interface Virtual-Template, IP local pool, username/password для авториз-и, static route до сетей уд.кабинета |
service internal (для включения опций pptp клиента), vpdn-group, interface Dialer, dialer-list, static route до сетей центр., удал. кабинета |
Да Static route для внутренних сетей за PPTP клиентом |
Да Static route для новых внутренних сетей за новым PPTP клиентом |
Да | Масштабируемый с ограничениями. Морально устаревший протокол, уязвимости в криптографии в протоколе авторизации MSCHAPv2. В большинстве случаев употребляется для сотворения удаленного доступа. Поддерживается обилием фаворитных версий ОС Windows. Исп только один протокол для шифрования -MPPE (RC4 со 128-битным ключом). Поддерживает мультикаст, т.к. PPP инкапсулируются в GRE. |
IGP over PPTP | Vpdn-group, interface Virtual-Template, IP local pool, username/password для авториз-и, IGP protocol (router ospf process) |
service internal (для включения опций pptp клиента), vpdn-group, interface Dialer, dialer-list, IGP protocol (router ospf process) |
Нет | Нет | Да | Масштабируемый с ограничениями. Поддерживает мультикаст, т.к. PPP инкапсулируются в GRE. Морально устаревший протокол -> кандидатура L2TP over IPSec |
L2TPv3 xconnect |
pseudowire-class xconnect |
pseudowire-class xconnect |
Да xconnect |
Нет | Да | Не масштабируемый. Прекрасно подходит для разнесения «native» L2 vlan-а через IP сеть. Но, нужно наличие запасного шлюза по дефлоту. Создавая xconnect на интерфейсе маршрутизатора мы должны удалить IP адресок с его интерфейса, тем удалив маршрут по дефлоту для всех устройств снутри этой сети. |
L2TPv2/v3 | aaa new-model, username для авторизации L2TP пира, VPDN-group, interface Virtual-Template, static route до сетей уд. кабинета |
username для авторизации L2TP HUBa, interface virtual-ppp, pseudowire class, static route до сетей центр., удал. кабинета |
Да: static route до внутренних сетей удаленного кабинета |
Да: static route до внутренних сетей удаленного кабинета |
Да | Масштабируемый. L2TPv3 дает огромные достоинства, позволяя инкапсулировать не только лишь PPP трафик, как L2TPv2, да и передавать метку VLANа и, также инкапсулировать HDLC, Frame Relay. |
IGP over L2TPv2/v3 | aaa new-model, username для авторизации L2TP пира, VPDN-group, interface Virtual-Template, IGP (router ospf process) |
username для авторизации L2TP HUBa, interface virtual-ppp, pseudowire class, IGP (router ospf process) |
Нет | Нет | Да | Очень масштабируемый. Позволяет настраивать протоколы маршрутизации «по умолчанию», связь удаленных кабинетов осуществляется через L2TPv2/v3 HUB (в центральном кабинете). |
Установление 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 туннеля. Работающий вариант.
ISAKMP:(1007):Old State = IKE_I_MM6 New State = IKE_I_MM6 *Sep 3 08:59:27.539: ISAKMP:(1007):Input = IKE_MESG_INTERNAL, IKE_PROCESS_COMPLETE *Sep 3 08:59:27.543: ISAKMP:(1007):Old State = IKE_I_MM6 New State = IKE_P1_COMPLETE |
ФАЗА 2
*Sep 3 08:59:27.559: ISAKMP:(1007):beginning Quick Mode exchange, M-ID of 2551719066 *Sep 3 08:59:27.563: ISAKMP:(1007):QM Initiator gets spi *Sep 3 08:59:27.575: ISAKMP:(1007): sending packet to 192.168.0.2 my_port 500 peer_port 500 (I) QM_IDLE *Sep 3 08:59:27.575: ISAKMP:(1007):Sending an IKE IPv4 Packet. *Sep 3 08:59:27.583: ISAKMP:(1007):Node 2551719066, Input = IKE_MESG_INTERNAL, IKE_INIT_QM *Sep 3 08:59:27.587: ISAKMP:(1007):Old State = IKE_QM_READY New State = IKE_QM_I_QM1 *Sep 3 08:59:27.803: ISAKMP:(1007):Checking IPSec proposal 1 |
А сейчас я предлагаю разглядеть пару примеров неработоспособности IPSec.
Case1
“Old State = IKE_I_MM1 New State = IKE_I_MM1”
Причина №1
Не условились по IKE proposal (предложенным IKE) в Фазе 1. На одной стороне указан 3des, на другом aes.
Error while processing SA request: Failed to initialize SA *Sep 3 08:36:38.239: ISAKMP: Error while processing KMI message 0, error 2. *Sep 3 08:36:38.287: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE… *Sep 3 08:40:38.307: ISAKMP (0): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1 *Sep 3 08:40:38.307: ISAKMP:(0): retransmitting phase 1 MM_NO_STATE *Sep 3 08:37:08.339: ISAKMP:(0):deleting SA reason «Death by retransmission P1″ state (I) MM_NO_STATE (peer 192.168.0.2) *Sep 3 08:41:08.359: ISAKMP:(0):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL *Sep 3 08:41:08.359: ISAKMP:(0):Old State = IKE_I_MM1 New State = IKE_DEST_SA |
На маршрутизаторе отображается последующее состояние:
R7#sh crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status 192.168.0.2 192.168.0.1 MM_NO_STATE 0 ACTIVE |
Причина №2
ACL на физическом интерфейсе блокируется трафик ISAKMP.
Case2
Если transform set на одном роутере один
R7#sh run | i transform crypto ipsec transform-set TRANSFORM esp-aes esp-md5-hmac |
…а на другом роутере другой
R10#sh run | i transform crypto ipsec transform-set TRANSFORM esp-aes esp-sha-hmac |
, то не сойдется SA IPSEC (не будет возрастать количество зашифрованных и расшифрованных пакетов
*Sep 3 08:56:08.551: ISAKMP:(1006): IPSec policy invalidated proposal with error 256 *Sep 3 08:56:08.559: ISAKMP:(1006): phase 2 SA policy not acceptable! (local 192.168.0.1 remote 192.168.0.2) *Sep 3 08:56:08.563: ISAKMP: set new node -1456368678 to QM_IDLE *Sep 3 08:56:08.567: ISAKMP:(1006):Sending NOTIFY PROPOSAL_NOT_CHOSEN protocol 3 spi 1785687224, message ID = 2838598618 *Sep 3 08:56:08.575: ISAKMP:(1006): sending packet to 192.168.0.2 my_port 500 peer_port 500 (I) QM_IDLE *Sep 3 08:56:08.579: ISAKMP:(1006):Sending an IKE IPv4 Packet. *Sep 3 08:56:08.583: ISAKMP:(1006):purging node -1456368678 *Sep 3 08:56:08.587: ISAKMP:(1006):deleting node 1350414148 error TRUE reason «QM rejected« *Sep 3 08:56:08.591: ISAKMP:(1006):Node 1350414148, Input = IKE_MESG_FROM_PEER, IKE_QM_EXCH *Sep 3 08:56:08.595: ISAKMP:(1006):Old State = IKE_QM_READY New State = IKE_QM_READY |
Case3
Если некорректно указали preshared key на IPSec пирах:
R7#sh run | i isakmp key crypto isakmp key cisco123 address 172.16.1.2 |
R10#sh run | i isakmp key crypto isakmp key cisco address 0.0.0.0 0.0.0.0 |
Тогда будет ошибка retransmitting phase 1 MM_KEY_EXCH
*Sep 3 09:14:30.659: ISAKMP:(1010): retransmitting phase 1 MM_KEY_EXCH… *Sep 3 09:14:30.663: ISAKMP (1010): incrementing error counter on sa, attempt 3 of 5: retransmit phase 1 *Sep 3 09:14:30.663: ISAKMP:(1010): retransmitting phase 1 MM_KEY_EXCH *Sep 3 09:14:30.663: ISAKMP:(1010): sending packet to 192.168.0.2 my_port 500 peer_port 500 (I) MM_KEY_EXCH *Sep 3 09:14:30.663: ISAKMP:(1010):Sending an IKE IPv4 Packet. *Sep 3 09:14:30.711: ISAKMP (1010): received packet from 192.168.0.2 dport 500 спорт 500 Global (I) MM_KEY_EXCH *Sep 3 09:14:30.715: ISAKMP:(1010): phase 1 packet is a duplicate of a previous packet. *Sep 3 09:14:50.883: ISAKMP:(1011): retransmitting due to retransmit phase 1 *Sep 3 09:14:51.383: ISAKMP:(1011): retransmitting phase 1 MM_KEY_EXCH… *Sep 3 09:14:51.387: ISAKMP:(1011):peer does not do paranoid keepalives. *Sep 3 09:14:51.387: ISAKMP:(1011):deleting SA reason «Death by retransmission P1″ state ® MM_KEY_EXCH (peer 192.168.0.2) *Sep 3 09:14:51.395: ISAKMP:(1011):Input = IKE_MESG_INTERNAL, IKE_PHASE1_DEL |