Поговорим о VPN-ах? Типы VPN соединений. Масштабирование VPN

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

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

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

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

Побеседуем о VPN-ах? Типы VPN соединений. Масштабирование VPN
Прирастить

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

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

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

Побеседуем о VPN-ах? Типы VPN соединений. Масштабирование VPN
Прирастить

Итогом работы по классификации 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 spokeN 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
*Sep 3 08:59:27.803: ISAKMP: transform 1, ESP_AES
*Sep 3 08:59:27.807: ISAKMP: attributes in transform:
*Sep 3 08:59:27.807: ISAKMP: encaps is 1 (Tunnel)
*Sep 3 08:59:27.811: ISAKMP: SA life type in seconds
*Sep 3 08:59:27.815: ISAKMP: SA life duration (basic) of 3600
*Sep 3 08:59:27.815: ISAKMP: SA life type in kilobytes
*Sep 3 08:59:27.819: ISAKMP: SA life duration (VPI) of 0×0 0×46 0×50 0×0
*Sep 3 08:59:27.827: ISAKMP: authenticator is HMAC-SHA
*Sep 3 08:59:27.827: ISAKMP: key length is 128
*Sep 3 08:59:27.831: ISAKMP:(1007):atts are acceptable.
*Sep 3 08:59:27.855: ISAKMP:(1007):Old State = IKE_QM_I_QM1 New State = IKE_QM_IPSEC_INSTALL_AWAIT
ISAKMP:(1007):Old State = IKE_QM_IPSEC_INSTALL_AWAIT New State = IKE_QM_PHASE2_COMPLETE

А сейчас я предлагаю разглядеть пару примеров неработоспособности 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
Аналогичный товар: Комментирование на данный момент запрещено, но Вы можете оставить ссылку на Ваш сайт.

Комментарии закрыты.