Коллеги, здравствуйте, меня зовут Семенов Вадим и совместно с проектом network-class.net хочу представить статью, посвященную вопросу масштабируемости VPN-ов, причем тех VPN-ов, которые доступны для настройки в обычной корпоративной сети предприятия, а не со стороны провайдера. Надеюсь, что данная статья станет справочным материалом, который может потребоваться при дизайне сети, либо при её апгрейде, либо для того, чтобы освежить в памяти принцип работы того или иного VPN-на. В начале статьи описаны основные моменты стека протоколов IPSec, так как использование данного стандарта далее будет весьма часто встречаться. В конце параграфа об IPSec были включены самые частые причины неработоспособности IPSec канала, а также основные шаги по их устранению.
Типы VPN соединений
Ниже систематизированы VPN-ы, которые доступны для настройки в корпоративной сети. Технологии VPN распределены по уровню предоставляемых клиенту каналов по модели OSI (рис 1):Схема VPN-ов относительно возможности пропуска мультикаста и работы протоколов маршрутизации (рис. 2):Дополнительно приводится структурированная схема VPN-ов (рис.3), которые могут предоставляться провайдером, но в данной статье подробно они не рассматриваются:Итогом работы по систематизации VPN-ов и исследованию их масштабируемости послужила итоговая таблица, в которую заносилась общая информация по типу протокола VPN-а, его особенности, и самое важное, что необходимо сделать, если к существующим VPN-ам подключить еще один. В таблице представлены результаты настроек, исследование полученного формата пакета, настройка протокола маршрутизации (OSPF) через VPN-ы, а также рассмотрены вопросы масштабируемости протокола.
Таблица VPN
Тип VPN | Настройка HUB | Настройка Spoke | Настройка HUB при добавлении нового Spoke | Настройка Spoke при добавлении другого нового Spoke | Использование протоколов динамической маршрутизации OSPF, EIGRP | Особенности |
Regular IPSec(crypto map) | isakmpCrypto-map | isakmpCrypto-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 tunnelDHCP для клиентов | MinimumIPsec 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 – кон-ция только mGREDMVPN phase 2 – настройка ipsec profile для защиты трафика | Minimum:DMVPN phase 1 – кон-ция только mGREDMVPN 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 |
L2TPv3xconnect | pseudowire-classxconnect | pseudowire-classxconnect | Да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 фаз: первая фаза устанавливается для того, чтобы обеспечить безопасный обмен ISAKMP сообщений во второй фазе. А ISAKMP (Internet Security Association and Key Management Protocol) служит для согласования политик безопасности (SA) между участниками VPN соединения, в который как раз и определяются с помощью какого протокола шифровать (AES, 3DES, DES), и с помощью чего аутентифицировать (HMAC SHA, MD5). Режим работы IKE (Internet Key Exchange):
IKE Фаза 1
- (опционально) аутентификация пиров
- Согласование IKE SA между пирами
- Работают в 2 режимах Main Mode (6 сообщений), Aggressive Mode (3 сообщения)
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_MM6Aggressive Mode (3 сообщения) Инициатором в первое сообщение помещается предложение о шифровании, протоколе аутентификации самих сообщений 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 modeQM делает все то, что и 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 0x0 0x46 0x50 0x0*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_AWAITISAKMP:(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 saIPv4 Crypto ISAKMP SA dst src state conn-id status192.168.0.2 192.168.0.1 MM_NO_STATE 0 ACTIVE |
Причина №2ACL на физическом интерфейсе блокируется трафик ISAKMP.
Case2
Если transform set на одном роутере один
R7#sh run | i transformcrypto ipsec transform-set TRANSFORM esp-aes esp-md5-hmac |
…а на другом роутере другой
R10#sh run | i transformcrypto 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 keycrypto isakmp key cisco123 address 172.16.1.2 |
Тогда будет ошибка «retransmitting phase 1 MM_KEY_EXCH»Regular IPSecНастройка через Crypto mapКонфигурация устройств:Проверка работоспособности SPI передается в IPSec пакете для того, чтобы при получении его пир-ом, в данном случае HUB-ом, HUB знал какой SA (security association) использовать, то есть какой протокол шифрования, какой протокол аутентификации и т.д. используется и как пакет расшифровывать. На HUB-е есть точно такая же SA с таким же SPI.Успешное прохождение трафика через VPN на HUB-e Теперь добавим еще один Spoke, посмотрим, какие изменения нам потребуется внести Проверка работы VPN Отсутствие связности до Spoke2 неудивительно — необходимо включать внутренние сети нового удаленного офиса в Crypto ACL, в итоге для обеспечения связности между Spokе-ми через HUB требуется добавление в Crypto ACL N сетей на N spoke-ах.Альтернатива. Множественные Crypto map.Пример конфигурации IPSec множественных VPN-ов с удаленными офисами с динамическими или статическими ip адресами, когда каждый офис получает доступ через интернет канал VPN-HUBа, но при этом все удаленные сети находятся в таблице маршрутизации и до них организована связь без использования NAT-а. В данной схеме и в данной конфигурации на удаленных офисах выставлено в Crypto ACL в качестве сети назначения – ip any, т.е. трафик к любому хосту будет заворачиваться в туннель, и при подключении нового удаленного офиса нет необходимости в изменении во всех остальных Crypto ACL в N удаленных офисах.Независимо от метода подключения: Regular IPSec или (забегая немного вперед, IPSec dynamic IP) в том и другом случае мы сталкиваемся с задачей обеспечения доступности между удаленными площадками. В рамках подключения типа Regular IPSec и IPSec dynamic IP нужно вручную определять сети в crypto ACL, поэтому для уменьшения конфигурации на оконечных устройствах после подключения очередного удаленного офиса, возможно пойти двумя путями:Хорошо задокументированный и разработанный дизайн сети, когда для удаленных офисов выделена большая сеть, которая делится на подсети для каждого удаленного офиса, но это хорошо для новых инсталляций, а не для рабочей сети;
- Отойти от crypto map к VTI и настроить динамическую маршрутизацию.
- Для настройки динамического протокола маршрутизации (OSPF) перейдем от использования метода crypto map к такой же настройке, но только через VTI интерфейс (поддерживает unicast, multicast).
Настройка через Virtual Tunnel Interface + профайлы.Virtual Tunnel Interface обеспечивают маршрутизирующий интерфейс для терминирования IPSec туннелей и более простой способ обеспечения безопасного соединения удаленных корпоративных сетей. VTI поддерживает передачу через туннель только юникаста и мультикаста, что позволяет обеспечить работу динамических протоколов маршрутизации без дополнительной необходимости в инкапсулировании пакета в GRE (дополнительные 4-байта). Существуют два типа виртуальных туннельных интерфейса:Static virtual interface – представляет собой point-to-point туннельDуnamic virtual interface – позволяет масштабировать решение по VPN-ам путем терминирования множественных туннелей на себя с удаленных Spoke-ов, которые могут иметь динамический IP адрес. Единственный недостаток – только удаленные spoke маршрутизаторы могут инициировать установление туннеля (т.к. только у них указан tunnel destination HUB_ip).При настройке DVTI на HUB маршрутизаторе создается шаблон настроек virtual-template, при успешном обмене ключами с удаленным spoke-м и установлении с ним туннеля — из «шаблона» на HUBе создается virtual-access интерфейс, который является как SVTI туннельный интерфейс для данного туннеля.Особенности VTI:
- Traffic selector (т.е. тот трафик, который будет завернут в туннель) у Static VTI всегда ip any any;
- Traffic selector у Dynamic VTI тоже по умолчанию ip any any и поддерживает только одну IPSec SA, но может принимать тот traffic selector, который предлагает ему инициатор;
- Не поддерживается Stateful Failover;
- Режим работы transform-set только в туннельном режиме.
Проверка установления соседства через OSPF over Static VTITraffic Selector для Static VTI ip any any, т.е. все, что мы направим в туннель через статический маршрут либо через протокол маршрутизации, то и будет шифроваться/дешифроваться.interface Tunnel0ip address 10.1.1.254 255.255.255.0ip ospf mtu-ignore OSPF Neighbor осуществляет проверку на использование одинакового значения MTU на интерфейсе. Если neighbor получит размер MTU в DBD пакете бОльший, чем MTU своего входящего интерфейса, то соседство не установится.При подключении второго Spoke2 настраивается второй Tunnel (HUB-Spoke2), на которого выделяется своя отдельная подсеть.IPSec with Dynamic IP, Dynamic VTIРассмотрим на нашем примере схему с использованием Dynamic VTI на HUBе, Static VTI на spoke-ах. К Dynamic VTI могут подключаться также и с настроенными crypto map-ами.Проверим установленные туннели при двух подключенных Spoke-ах:Работа OSPF через туннели: Восстановление канала при падении линкаВыключим Tunnel интерфейс на Spoke, очистим ipsec сессии и обмененными ключами. После этого включим интерфейс обратно:Восстановление туннеля прошло автоматически. EAZY VPNИдея технологии Eazy VPN заключается в облегчении установления VPN-подключения региональным маршрутизаторам засчет того, что часть настроек касательно IPSec сообщается VPN-клиенту самим VPN HUB-ом. Для этого в протокол согласования ассоциаций безопасности (ISAKMP) была внесена дополнительная фаза 1.5. Через эту фазу vpn-клиент может запросить информацию о IP-адресе, DNS-ы, ACL для split tunnel. Чаще всего эта технология используется в организации удаленного подключения через Cisco VPN Client.Три режима работы Easy VPN Remote[1]:
- клиентский режим. В этом случае на VPN-клиенте(маршрутизаторе) вся локальная сеть удаленного офиса подвергается NAT/PAT-трансляции в адрес, который выдан сервером из заданного пула
- режим сетевого расширения. В этом случае, все сетевые устройства, которые находятся за VPN-клиентом (маршрутизатором), получают IP-адреса и являются полноценными участниками IP-маршрутизации. В этом случае PAT не используется, что позволяет конечным рабочим станциям работать друг с другом напрямую.
- режим сетевого расширения «плюс». Аналогичен режиму простого сетевого расширения, но с дополнением в виде возможности запроса IP-адреса в процессе установления защищенного канала связи и его автоматической установки на доступный Loopback-интерфейс. Ассоциации безопасности IPsec для этого IP-адреса автоматически создаются Easy VPN Remote’ом. Этот IP чаще всего используется для устранения неисправностей (ping, telnet, ssh и т.д.).
Есть и особенности в настройках:Cisco Easy VPN Remote не поддерживает transform set с установленной безопасностью без аутентификации (ESP-DES and ESP-3DES) или transform-set, обеспечивающий аутентификацию без шифрования (ESP-NULL ESP-SHA-HMAC and ESP-NULL ESP-MD5-HMAC)Если на VPN-клиенте (маршрутизаторе) настроен NAT/PAT до настройки Cisco Easy VPN Remote, то в первую очередь необходимо удалить NAT-правила (в последствии они создадутся автоматически)Настройка Easy VPN в client modeНа VPN-клиенте (маршрутизаторе) вся локальная сеть удаленного офиса подвергается NAT/PAT-трансляции в адрес, который выдан сервером из заданного пула Автоматически прописывается ip outside nat (ip nat inside мы должны прописать) и добавляются ACL!Проверим, что NAT настроился автоматически, прописался исходящий интерфейс и добавились списки контроля доступа ACL интересующего нас трафика Видно, что добавились автоматически два списка доступа. Посмотрим, какой тип трафика они определяют GRE tunnel. OSPF over GREGre представляет собой транспорт для многих типов остальных протоколов, будь то сигнальные сообщения динамических протоколов маршрутизации (OSPF, EIGRP) либо IPv6 пакеты. Данные пакеты инкапсулируются в еще один IP пакет (тип 47) с GRE заголовком. GRE прост в настройке, хотя и разработан первоначально Cisco, сейчас представляет собой открытый стандарт RFC 2784.GRE туннель создает point-to-point линк со всеми вытекающими из этого проблемами масштабирования. В реальной сети это выливается в создании каждого туннеля для каждого удаленного офиса (маршрутизатора) с выделением отдельной подсети. Проверка работы OSPF Формат пакета: GRE over IPSec Проверка работы GRE over IPSec Формат пакета:Работа OSPF over GRE over IPSecOSPF работает в стандартной конфигурации (как в случае network type broadcast) DMVPNDMVPN реализует multipoint GRE архитектуру, позволяя использовать, во-первых, одно адресное пространство для всех vpn удаленных офисов, во-вторых, пропускать через туннель большой список сторонних протоколов, а также мультикаст, и в-третьих, устанавливать динамически туннели между региональными удаленными площадками в случае возникновения трафика между ними. Однако есть одно но, данная технология реализуема только на моновендорной сети на Cisco.Настройка маршрутизатора HQ как DMVPN HUB, Spoke 1 как DMVPN Client Проверка работы DMVPNПроверяем установился ли туннель до DMVPN HUBa.Обращаем внимание, что NBMA address – реальный адрес HUBa. Создание динамического GRE туннеля от удаленного офиса Spoke1 к Spoke2Вначале загрузки у Spoke 1 был только 1 туннель до HUBа. При генерировании трафика (пинга) до Spoke2, сразу же создался туннель до Spoke2 На данный момент схема сети (рис.13) будет уже выглядеть так: Динамические протоколы маршрутизации через DMVPNНастройка OSPFСделав настройки по DMVPN и включив общую сеть для VPN-а 10.5.5.0 в процесс OSPF – мы будем наблюдать как OSPF на HUBе будет устанавливать смежные отношения сначала со Spoke1 до того момента, как не получит hello пакет со Spoke2, после этого отношения рушатся с ошибкой Neighbor Down: Adjacency forced to reset, так как по умолчанию interface Tunnel выставлен как point-to-point интерфейс. Для корректной работы OSPF необходимо выставить network type как broadcast. Если выставить broadcast только на HUBe, то соседства установятся, но маршрутов через OSPF на Spok-aх не будет, поэтому необходимо выставить broadcast и на HUB, и на Spoke-ах.Ниже приведены таблицы поведения OSPF в зависимости от выбранного значения network type. DMVPN c EIGRPВыключаем на HUBe split-horizonИзбавимся от HUB-а как промежуточного устройства в связности Spoke1 <-> Spoke2 PPTPPPTP стал совместной разработкой консорциумов Microsoft, 3Com, Ascend Communication. Хорошо масштабируемый протокол. Может использоваться для соединения офисов по типу точка-точка, но, больше всего подходит для организации удаленного подключения по архитектуре клиент-сервер. Достаточно настроить центральный PPTP VPN HUB, а удаленные пользователи подключаются через PPTP клиент, который внедрен во всех OC Windows, в том числе MacOS и Linux-дистрибутивах.Существуют криптографические проблемы в протоколе аутентификации MSCHAPv2 [https://technet.microsoft.com/ru-ru/library/security/2743314.aspx], поэтому в большинстве случаев рекомендовано использование даже на той же самой OC Windows протокола L2TP over IPSec вместо PPTP.В качестве средств шифрования используется только один протокол шифрования Microsoft Point-to-Point Encryption (128битный ключ), в качестве аутентификации – MSCHAPv2, PEAP (рекомендовано).PPTP в процессе своей работы устанавливает 2 сессии: PPP сессию с использованием GRE протокола и TCP соединение по порту 1723 для обслуживания PPTP сессии.Установление TCP сессии перед установлением PPP соединенияФормат PPP пакета (рис.15)Проверка установленных PPTP соединений.Пользователь cisco2 авторизован и сессия установлена.Пользователю выдан ip адрес из DHCP Pool-а и создан virtual-access В случае если возникает задача конкретному PPTP клиенту выдавать принадлежащий только ему IP адрес, то тогда можно прибегнуть к созданию TXT файла с перечислением всех PPTP клиентов.Настройка на маршрутизаторе: Сам TXT файлик static2.txt. L2TPL2TP – это стандарт IETF, который вобрал в себя лучшее от протокола L2F от Cisco и PPTP от Microsoft. Не предлагает средств по защите данных, поэтому часто используется с IPSec.L2TP – один из немногих представителей VPN протоколов (к тому же доступный для внедрения в корпоративной сети), который может предложить технологию pseudowire – проброс native vlan-а через L3 сеть. Технологию pseudowire поддерживает только L2TP version 3. Кроме этого L2TPv3 поддерживает следующие L2-протоколы, данные (payloads) которых могут прозрачно передаваться через псевдо-туннель L2TPv3:
- Ethernet
- Ethernet VLAN (802.1q)
- HDLC
- PPP
- MPLS
Главное отличие L2TPv3 перед L2TPv2 это то, что L2TPv3 может туннелировать различный тип трафика (см. выше), в то время как v2 только PPP.L2TPv3 использует два типа сообщений:
- Сигнальные (Control Connection)
- Для данных (Session data)
L2TPv3 сигнальные сообщения так и сообщения с данными могут быть перенесены через IP (protocol ID 115), т.е. L2TPv3 использует меньший overhead L2TPv2 инкапсулирует данные в IP/UDP (UDP порт 1701).L2TPv3 PseudowireВ архитектуре L2TP, равно как и в архитектуре PPTP, используются следующие понятия:Модель работы протоколов для L2TPv3 LNS – LNS, а для L2TPv2 LAC – LNS (подробнее см.ниже).Создадим pseudowire между R5 в Центральном офисе и в R9 в региональном офисе, тем самым расширим сеть 192.168.1.x/24 в региональный офис. Проверка установления сессии: R7 теперь доступен без протоколов маршрутизации: Работа OSPF через L2TPСоседство установилось по умолчанию, включив сеть 192.168.1.0 на R7 и R10 Недостатки:Если L2TP создается на маршрутизаторе как в нашем примере, то через pseudowire соединения не пройдут следующие L2 PDU: CDP, STP, VTP, LLDP. Для туннелирования таких протоколов необходимо создавать L2TPv3 туннель на L3 коммутаторе.Большой минус – мы должны удалить ip адрес на интерфейсе маршрутизатора, который служит маршрутом по умолчанию для всех остальных станций. В итоге у нас ПК остаются без связи с другими сетями.L2 VPN работает в двух режимах:
- обязательный туннельный режим
- добровольный (опциональный) туннельный режим.
Обязательный туннельный режим относится к провайдер-определяемым (provider provisioning) и в таком режиме работают протоколы L2F, PPTP, L2TP. В обязательном туннельном режиме через L2TP удаленные пользователи подключаются к LAC по обычному PPP соединению, LAC их терминирует на себя и туннелирует PPP сессии к LNS. Причем удаленный пользователь даже не подозревает об L2TP.В добровольном /клиентском инициированном туннеле удаленный хост действует как LAC, то есть он согласует и устанавливает L2TP сессию непосредственно с LNS.В нашем примере Cisco R9 (44.1.1.9) будет действовать как LAC и устанавливать L2TP соединение с Cisco R5 в ЦОДе (55.1.1.1), которая будет выступать в роли LNS. Служебный канал установился, теперь устанавливается канал для данных (PPP фреймов).Стоит отметить, что по одному установившемуся туннелю может проходить множество клиентских сессий.Для установки сессии для данных LAC отправляет ICRQ (Call-Request), если на LNS достаточно ресурсов, то LNS отвечает сообщением ICRP (Call-Reply). Для завершения установления сессии – LAC отправляет ICCN Incoming-Call-Connected. В нашем примере сформировался один туннель между LAS и LNS и одна пользовательская сессия.Настройка L2TP в добровольном туннельном режиме очень похожа в настройке с обязательным туннельным режимом. Различие в настройке VPDN группы следующее:
- Команда terminate-from не нужна
- Аутентификация L2TP туннеля выключена командой no l2tp tunnel authentication
Настройка L2TPv2На некоторых типах маршрутизаторов нельзя создать interface virtual-ppp, поэтому привожу в качестве альтернативны другую рабочую конфигурацию через создание interface Dialer. Конфигурация предоставляется «AS IS».Конфигурация L2TPv2 через interface virtual-pppПроверка установления туннеля и заодно проверяем работу сессии через пинг с внутренней сети удаленного клиента (LAC) и просмотра статистики сессионных пакетов на L2TP HUBe (LNS)Формат пакета L2TPv2Overhead UDP (8байт) + L2TPv2 (8байт) + PPP (4 байта) +IPv4 (20 байт) = 40байтРабота OSPF через L2TPv2LSA протокола OSPF через L2TPv2Обратите, пожалуйста, внимание на получившийся overhead.Overhead UDP (8байт) + L2TPv2 (8байт) + PPP (4 байта) +IPv4 (20 байт) = 40байтПроверка установленного соседстваНастройка для L2TPv3Настройка L2TPv3 практически ничем не отличается на удаленных клиентах, в то время как настройка на VPN HUB-е отличается очень разительно.Проверка установленной L2TPv3 сессии на LNSПроверка установленной L2TPv3 сессии на LACФормат пакета L2TPv3Overhead L2TPv3 (4байта) + HDLC (4байта) = 8 байтПроверяем работу сессии через пинг с внутренней сети удаленного клиента (LAC) и просмотра статистики сессионных пакетов на L2TP HUBe (LNS)L2TPv2 over IPSecПротокол L2TP не обеспечивает защищенность передаваемых по нему данных, поэтому для обеспечения целостности и конфиденциальности данных используем набор протоколов IPSec. Из средств безопасности L2TP может предложить аутентификацию хоста, инициализирующего туннель, а также PPP аутентификацию. Так как в нашем примере использован протокол L2TPv2, который использует IP/UDP инкапсуляцию, то достаточно в крипто ACL определить лишь UDP трафик по порту 1701. В настройке IPSec используется транспортный режим, а не туннельный, чтобы шифровать трафик от оконечного клиента оконечному (в транспортном режиме), нежели создавать дополнительные IP туннельные интерфейсы и шифровать трафик только между ними (в туннельном режиме).Схема сети:Проверяем работу сессии через пинг с внутренней сети удаленного клиента (LAC) и просмотра статистики сессионных пакетов на L2TP HUBe (LNS)Формат пакета L2TPv2 over IPSecФормат пакета IP | ESP header | UDP | L2TP | PPP | ESP trailer | Auth trailerOverhead ESP_header (8байт) + UDP (8байт) + L2TPv2 (8байт) + PPP (4 байта) + ESP_trailer (min 2байта) + SHA_auth (160бит = 20 байт) = 50 бaйтРабота OSPF over L2TPv2 over IPSecСоседство через OSPF не было потеряно, hello пакеты по-прежнему приходят через каждый 10 сек. Маршруты анонсируются через удаленный OSPF соседний маршрутизатор.Масштабирование. Подключение нового удаленного офиса через L2TPv2Настройка для LNS, т.е. для L2TPv2 HUBа минимальная – необходимо лишь добавить пользователя для PPP CHAP авторизации. Если этого не сделать, то будет следующая ошибка:Добавляем второго LAC После этого на LNS уже 2 туннеляРабота OSPF в L2TPv2В случае подключение удаленных офисов через L2TPv2 – нет ограничений в использовании динамических протоколов маршрутизации. Для включения OSPF заведем на каждом удаленном маршрутизаторе по сети на loopback-е:Проверяем OSPF соседство и настроенные маршрутыВ случае не использования OSPF, каждое добавление нового регионального офиса требует статического добавления маршрутов на каждом существующем маршрутизаторе (и региональном и L2TP HUBe) с адресом достижения – ip адрес ppp интерфейса.В случае хорошего дизайна распределения IP адресов мы можем ограничиться тем, что на региональных маршрутизаторах 1 раз добавили суммарный маршрут до всей внутренних региональных сетей, например 192.168.25.0/24 на interface virtual-ppp VPN HUBa, тогда при подключении новой подсети а-ля 192.168.25.16/29 нам не нужно будет ничего добавлять на региональных маршрутизаторах, останется только лишь на VPN HUBе указать за каким vitual-ppp интерфейсом нового регионального маршрутизатора находится эта сеть:HUB(conf)#ip route 192.168.25.16 255.255.255.248 16.16.16.16 (<- где 16.16.16.16 это virtual-ppp интерфейс нового регионального маршрутизатора, и который в таблице маршрутизации VPN HUBa будет выглядеть как непосредственно подключенный:
Спасибо самым стойким и усидчивым читателям, дошедшим до конца данной статьи, за Ваше внимание и терпение. Как я уже отмечал в начале статьи, мне бы хотелось, чтобы данный обзор стал небольшим сборником и справочным материалом, который необязательно помнить наизусть, но к которому можно всегда обратиться. Надеюсь, что это реально поможет моим коллегам по «цеху» учесть нюансы в построении качественного, красивого и грамотного сетевого дизайна, избежать подводных камней и в целом сделать свою работу на высшем уровне! С вами был Семенов Вадим и проект сетевой класс network-class.net.P.S.Все дампы пакетов, собранные при обзоре указанных выше VPN-ов, доступны для скачивания здесь.
5 коментариев
В избранное! 🙂
Подскажите, при настройке SVTI, если у Tunnel убрать tunnel mode ipsec ipv4, то получается gre tunnel?
В gns поднял, в случае без tunnel mode ipsec ipv4, пустил ping с loopback HQ на loopback Branch:
Хотелось бы узнать, насколько это корректно?
По какому критерию SSL\TLS отнесли к VPN?
Очень интересная статья.
Но пожайлуста в не посылайте в RSS полностью всю статью.
SSLv3/TLSv1.0 можно отнести к группе протоколов по организации удаленного подключения пользователей к корпоративной сети, они называются как SSL VPN, WebVPN или Clientless VPN, когда удаленному пользователю достаточно авторизоваться на web-браузере корпоративного файервола, чтобы установился SSL туннель и в дальнейшем данные от клиента (telnet, ssh, rdp, http) упаковывались в SSL контейнер. Также программные VPN Client-ы могут использовать в качестве транспорта не IPSec, а SSL/TLS.
В обычной жизни мы встречаемся с SSL чаще всего при использовании HTTPS, SMTPS, FTPS.
Боюсь, что в RSS ушла только та часть, которая до ката.