Коллеги, здравствуйте. Меня зовут Семенов Вадим и я хочу представить статью, посвященную вопросу масштабируемости VPN-ов, причем тех VPN-ов, которые доступны для настройки в обычной корпоративной сети предприятия, а не со стороны провайдера. Надеюсь, данная статья станет справочным материалом, который может потребоваться при дизайне сети, либо при её апгрейде, либо для того, чтобы освежить в памяти принцип работы того или иного 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 фаз: первая фаза устанавливается для того, чтобы обеспечить безопасный обмен 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 между пирами
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 сообщения)
Инициатором в первое сообщение помещается предложение о шифровании, протоколе аутентификации самих сообщений 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 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_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 sport 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 |
Regular IPSec
Настройка через Crypto map
Конфигурация устройств:
| HUB | Spoke1 |
| Настройка первой фазы IPSec для обмена сессионного ключа: crypto isakmp policy 1 hash md5 authentication pre-share group 5 crypto isakmp key cisco123 address 172.16.1.2 ! Настройка второй фазы IPSec c заданием алгоритма шифрования и аутентификации crypto ipsec transform-set Trans_HUB1_SP1 esp-aes 256 esp-md5-hmac ! crypto map HUB_SPOKEs 1 ipsec-isakmp set peer 172.16.1.2 set transform-set Trans_HUB1_SP1 match address TO_Spoke1 reverse-route static ! |
crypto isakmp policy 1 hash md5 authentication pre-share group 5 crypto isakmp key cisco123 address 192.168.1.1 ! crypto ipsec transform-set Trans_SP1_HUB1 esp-aes 256 esp-md5-hmac ! crypto map SP1_HUB 1 ipsec-isakmp set peer 192.168.1.1 set transform-set Trans_SP1_HUB1 match address TO_HUB reverse-route static ! |
| Настройка заворачивания маршрутов в туннель | |
| ip access-list extended TO_Spoke1 permit ip 10.0.0.0 0.0.0.255 1.1.1.0 0.0.0.255 ! Interface Ethernet0/0 ip address 192.168.1.1 255.255.255.0 crypto map HUB_SPOKEs ! |
ip access-list extended TO_HUB permit ip 1.1.1.0 0.0.0.255 10.0.0.0 0.0.0.255 ! Interface Ethernet0/0 ip address 172.16.1.1 255.255.255.0 crypto map SP1_HUB ! |
Проверка работоспособности
| HUB#ping 1.1.1.1 source 10.0.0.1 .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 4/4/5 ms |
Spoke1#ping 10.0.0.1 source 1.1.1.1 .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 4/4/5 ms |
| Проверка сходимости VPN: | |
| Успешный обмен ключами: Spoke1#show crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status 192.168.1.1 172.16.1.2 QM_IDLE 1007 ACTIVE Успешное прохождение трафика через VPN: Spoke1#show crypto ipsec sa interface: Ethernet0/0 Crypto map tag: SP1_HUB, local addr 172.16.1.2 protected vrf: (none) local ident (addr/mask/prot/port): (1.1.1.0/255.255.255.0/256/0) remote ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/256/0) current_peer 192.168.1.1 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4 #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 172.16.1.2, remote crypto endpt.: 192.168.1.1 path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0 current outbound spi: 0xA7424886(2806139014) PFS (Y/N): N, DH group: none |
|
SPI передается в IPSec пакете для того, чтобы при получении его пир-ом, в данном случае HUB-ом, HUB знал какой SA (security association) использовать, то есть какой протокол шифрования, какой протокол аутентификации и т.д. используется и как пакет расшифровывать. На HUB-е есть точно такая же SA с таким же SPI.
Успешное прохождение трафика через VPN на HUB-e
| HUB#sho crypto ipsec sa interface: Ethernet0/0 Crypto map tag: HUB_SPOKEs, local addr 192.168.1.1 protected vrf: (none) local ident (addr/mask/prot/port): (10.0.0.0/255.255.255.0/256/0) remote ident (addr/mask/prot/port): (1.1.1.0/255.255.255.0/256/0) current_peer 172.16.1.2 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 4, #pkts encrypt: 4, #pkts digest: 4 #pkts decaps: 4, #pkts decrypt: 4, #pkts verify: 4 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 192.168.1.1, remote crypto endpt.: 172.16.1.2 path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0 current outbound spi: 0x10101858(269490264) PFS (Y/N): N, DH group: none inbound esp sas: spi: 0xA7424886(2806139014) transform: esp-256-aes esp-md5-hmac , in use settings ={Tunnel, } conn id: 19, flow_id: SW:19, sibling_flags 80000040, crypto map: HUB_SPOKEs sa timing: remaining key lifetime (k/sec): (4360017/2846) IV size: 16 bytes replay detection support: Y Status: ACTIVE(ACTIVE) |
Теперь добавим еще один Spoke, посмотрим, какие изменения нам потребуется внести
| Настройка на HUB | Настройка на новом Spoke |
| HUB# crypto isakmp policy 1 hash md5 authentication pre-share group 5 crypto isakmp key cisco123 address 172.16.1.2 crypto isakmp key cisco456 address 172.16.2.3 ! ! crypto ipsec transform-set Trans_HUB1_SP1 esp-aes 256 esp-md5-hmac ! crypto map HUB_SPOKEs 1 ipsec-isakmp set peer 172.16.1.2 set peer 172.16.2.3 set transform-set Trans_HUB1_SP1 match address TO_Spokes reverse-route static ! ip access-list extended TO_Spokes permit ip 10.0.0.0 0.0.0.255 1.1.1.0 0.0.0.255 permit ip 10.0.0.0 0.0.0.255 2.2.2.0 0.0.0.255 т.е. для добавления N spoke-ов, нужно 3N дополнительный строчек |
Настройка такая же как и на первом Spoke1 (с учетом поправки внутренних сетей в ACL) Spoke2# crypto isakmp policy 1 hash md5 authentication pre-share group 5 crypto isakmp key cisco456 address 192.168.1.1 ! ! crypto ipsec transform-set Trans_SP2_HUB1 esp-aes 256 esp-md5-hmac ! crypto map SP2_HUB 1 ipsec-isakmp set peer 192.168.1.1 set transform-set Trans_SP2_HUB1 match address TO_HUB reverse-route static ! ip access-list extended TO_HUB permit ip 2.2.2.0 0.0.0.255 10.0.0.0 0.0.0.255 |
Проверка работы VPN
| Проверка доступности второго удаленного офиса: HUB#ping 2.2.2.2 source 10.0.0.1 .!!!! Success rate is 80 percent (4/5), round-trip min/avg/max = 4/4/5 ms На HUBе теперь появилась дополнительная сессия обмена ключами со вторым Spoke: HUB#sho crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status 192.168.1.1 172.16.2.3 QM_IDLE 1009 ACTIVE 192.168.1.1 172.16.1.2 QM_IDLE 1008 ACTIVE Однако связи между офисами нет (даже через HUB). Spoke1#ping 2.2.2.2 source 1.1.1.1 ..... Success rate is 0 percent (0/5) |
Отсутствие связности до Spoke2 неудивительно — необходимо включать внутренние сети нового удаленного офиса в Crypto ACL, в итоге для обеспечения связности между Spokе-ми через HUB требуется добавление в Crypto ACL N сетей на N spoke-ах.
Альтернатива. Множественные Crypto map.
Пример конфигурации IPSec множественных VPN-ов с удаленными офисами с динамическими или статическими ip адресами, когда каждый офис получает доступ через интернет канал VPN-HUBа, но при этом все удаленные сети находятся в таблице маршрутизации и до них организована связь без использования NAT-а.
| HUB# crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac mode tunnel ! crypto ipsec profile Spokes_VPN_Profile set security-association lifetime seconds 86400 set transform-set 3DES-MD5 set reverse-route distance 1 reverse-route ! crypto dynamic-map hq-vpn 30 set profile Spokes_VPN_Profile match address VPN33-32-TRAFFIC crypto dynamic-map hq-vpn 3348 set profile Spokes_VPN_Profile match address VPN3348-TRAFFIC crypto dynamic-map hq-vpn 50 set profile Spokes_VPN_Profile match address VPN33-64-TRAFFIC ! crypto map VPN 1 ipsec-isakmp dynamic hq-vpn ! interface GigabitEthernet1/0 ip address 55.1.1.5 255.255.255.0 <omitted...> crypto map VPN ! ip access-list extended VPN33-32-TRAFFIC permit ip any 192.168.33.32 0.0.0.15 ip access-list extended VPN33-48-TRAFFIC permit ip any 192.168.33.48 0.0.0.15 ip access-list extended VPN33-64-TRAFFIC permit ip any 192.168.33.64 0.0.0.15 |
Spoke# crypto ipsec transform-set 3DES-MD5 esp-3des esp-md5-hmac mode tunnel ! crypto map VPN 1 ipsec-isakmp set peer 55.1.1.5 set transform-set 3DES-MD5 match address TO_HUB reverse-route static ! interface FastEthernet0/0 ip address negotiated <omitted...> crypto map VPN ! ip access-list extended TO_HUB permit ip 192.168.33.32 0.0.0.15 any |
В данной схеме и в данной конфигурации на удаленных офисах выставлено в 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 только в туннельном режиме.
| Настройка Static VTI через профайлы | |
| HUB# crypto isakmp policy 1 hash md5 authentication pre-share group 5 crypto isakmp key cisco123 address 172.16.1.2 ! crypto ipsec transform-set Trans_HUB_SP esp-aes esp-sha-hmac ! crypto ipsec profile P1 set transform-set Trans_HUB_SP ! interface Tunnel0 ip address 10.1.1.254 255.255.255.0 ip ospf mtu-ignore*(см.ниже) load-interval 30 tunnel source 192.168.1.1 tunnel mode ipsec ipv4 tunnel destination 172.16.1.2 tunnel protection ipsec profile P1 ! router ospf 1 network 10.0.0.0 0.0.0.255 area 0 network 10.1.1.0 0.0.0.255 area 0 |
Spoke1# crypto isakmp policy 1 hash md5 authentication pre-share group 5 crypto isakmp key cisco123 address 192.168.1.1 ! crypto ipsec transform-set Trans_HUB_SP esp-aes esp-sha-hmac ! crypto ipsec profile P1 set transform-set Trans_HUB_SP ! interface Tunnel0 ip address 10.1.1.1 255.255.255.0 ip ospf mtu-ignore load-interval 30 tunnel source 172.16.1.2 tunnel mode ipsec ipv4 tunnel destination 192.168.1.1 tunnel protection ipsec profile P1 ! router ospf 1 network 1.1.1.0 0.0.0.255 area 0 network 10.1.1.0 0.0.0.255 area 0 |
Проверка установления соседства через OSPF over Static VTI
| HUB#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 0 FULL/ - 00:00:33 10.1.1.1 Tunnel0 Сеть на Spoke 1 теперь доступна через туннель HUB#sh ip route 1.0.0.0/32 is subnetted, 1 subnets O 1.1.1.1 [110/1001] via 10.1.1.1, 00:02:56, Tunnel0 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks C 10.0.0.0/24 is directly connected, Loopback0 L 10.0.0.1/32 is directly connected, Loopback0 C 10.0.1.0/24 is directly connected, Loopback1 L 10.0.1.1/32 is directly connected, Loopback1 C 10.1.1.0/24 is directly connected, Tunnel0 L 10.1.1.254/32 is directly connected, Tunnel0 Проверка доступности сетей в Центральном офисе со Spoke 1 Spoke1#ping 10.0.0.1 source 1.1.1.1 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 5/5/5 ms |
Traffic Selector для Static VTI ip any any, т.е. все, что мы направим в туннель через статический маршрут либо через протокол маршрутизации, то и будет шифроваться/дешифроваться.
| Spoke1#sho crypto ipsec sa interface: Tunnel0 Crypto map tag: Tunnel0-head-0, local addr 172.16.1.2 protected vrf: (none) local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0) current_peer 192.168.1.1 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 76, #pkts encrypt: 76, #pkts digest: 76 #pkts decaps: 65, #pkts decrypt: 65, #pkts verify: 65 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 |
interface Tunnel0
ip address 10.1.1.254 255.255.255.0
ip ospf mtu-ignore
OSPF Neighbor осуществляет проверку на использование одинакового значения MTU на интерфейсе. Если neighbor получит размер MTU в DBD пакете бОльший, чем MTU своего входящего интерфейса, то соседство не установится.
При подключении второго Spoke2 настраивается второй Tunnel (HUB-Spoke2), на которого выделяется своя отдельная подсеть.
| HUB#sho ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 2.2.2.2 0 FULL/ - 00:00:31 10.1.2.2 Tunnel1 1.1.1.1 0 FULL/ - 00:00:30 10.1.1.1 Tunnel0 Маршруты на Spoke1 Spoke1#sh ip route Gateway of last resort is 172.16.1.5 to network 0.0.0.0 <...ommited...> C 1.1.1.0/24 is directly connected, Loopback0 L 1.1.1.1/32 is directly connected, Loopback0 2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/2001] via 10.1.1.254, 01:53:04, Tunnel0 <-Сеть Spoke2 10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks O 10.0.0.1/32 [110/1001] via 10.1.1.254, 02:04:11, Tunnel0 <-Сеть Головного офиса O 10.0.1.1/32 [110/1001] via 10.1.1.254, 02:04:11, Tunnel0 <-подсеть туннеля HUB-Spoke1 C 10.1.1.0/24 is directly connected, Tunnel0 L 10.1.1.1/32 is directly connected, Tunnel0 O 10.1.2.0/24 [110/2000] via 10.1.1.254, 01:53:14, Tunnel0 <-подсеть туннеля HUB-Spoke2 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks Сообщение до второго удаленного офиса через Центральный офис: Spoke1#traceroute 2.2.2.2 Type escape sequence to abort. Tracing the route to 2.2.2.2 VRF info: (vrf in name/id, vrf out name/id) 1 10.1.1.254 5 msec 4 msec 5 msec 2 10.1.2.2 5 msec 10 msec * |
IPSec with Dynamic IP, Dynamic VTI
Рассмотрим на нашем примере схему с использованием Dynamic VTI на HUBе, Static VTI на spoke-ах. К Dynamic VTI могут подключаться также и с настроенными crypto map-ами.
| HUB# crypto keyring KEY_Dynamic_connection pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123 ! crypto isakmp policy 1 hash md5 authentication pre-share group 5 crypto isakmp profile DVTI keyring KEY_Dynamic_connection match identity address 0.0.0.0 virtual-template 1 ! crypto ipsec transform-set Trans_HUB_SP esp-aes esp-sha-hmac ! crypto ipsec profile P1 set transform-set Trans_HUB_SP set isakmp-profile DVTI ! interface Loopback1 ip address 10.1.1.254 255.255.255.0 ! interface Virtual-Template1 type tunnel ip unnumbered Loopback1 ip ospf mtu-ignore tunnel mode ipsec ipv4 tunnel protection ipsec profile P1 ! router ospf 1 network 10.0.0.0 0.0.0.255 area 0 network 10.1.1.0 0.0.0.255 area 0 |
Spoke1# crypto keyring KEY_Dynamic_connection pre-shared-key address 0.0.0.0 0.0.0.0 key cisco123 ! crypto isakmp policy 1 hash md5 authentication pre-share group 5 crypto isakmp profile DVTI keyring KEY_Dynamic_connection match identity address 0.0.0.0 ! crypto ipsec transform-set Trans_HUB_SP esp-aes esp-sha-hmac ! crypto ipsec profile P1 set transform-set Trans_HUB_SP set isakmp-profile DVTI ! interface Loopback1 ip address 10.1.1.1 255.255.255.0 ! interface Tunnel0 ip unnumbered Loopback1 ip ospf mtu-ignore tunnel source Ethernet0/0 tunnel mode ipsec ipv4 tunnel destination 192.168.1.1 tunnel protection ipsec profile P1 ! router ospf 1 network 1.1.1.0 0.0.0.255 area 0 network 10.1.1.0 0.0.0.255 area 0 |
Проверим установленные туннели при двух подключенных Spoke-ах:
| HUB#sh crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status 192.168.1.1 172.16.2.3 QM_IDLE 1047 ACTIVE 192.168.1.1 172.16.1.2 QM_IDLE 1046 ACTIVE HUB# sh ip int br Interface IP-Address OK? Method Status Protocol Ethernet0/0 192.168.1.1 YES NVRAM up up Ethernet0/1 unassigned YES manual up up Ethernet0/2 unassigned YES NVRAM down down Ethernet0/3 unassigned YES manual up up Loopback0 10.0.0.1 YES manual up up Loopback1 10.1.1.254 YES manual up up Virtual-Access1 10.1.1.254 YES unset up up Virtual-Access2 10.1.1.254 YES unset up up Virtual-Template1 10.1.1.254 YES manual up down HUB#sho crypto ipsec sa interface: Virtual-Access2 Crypto map tag: Virtual-Access2-head-0, local addr 192.168.1.1 protected vrf: (none) local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0) current_peer 172.16.1.2 port 500 interface: Virtual-Access1 Crypto map tag: Virtual-Access1-head-0, local addr 192.168.1.1 protected vrf: (none) local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/256/0) current_peer 172.16.2.3 port 500 |
Работа OSPF через туннели:
| HUB#sh ip ospf neighbor Все spoke-и находятся в одной сети! Neighbor ID Pri State Dead Time Address Interface 1.1.1.1 0 FULL/ - 00:00:32 10.1.1.1 Virtual-Access2 2.2.2.2 0 FULL/ - 00:00:35 10.1.1.2 Virtual-Access1 Маршруты Центрального Офиса HUB#sh ip route Gateway of last resort is not set 1.0.0.0/32 is subnetted, 1 subnets O 1.1.1.1 [110/2] via 10.1.1.1, 00:05:00, Virtual-Access2 <-Сеть Spoke1 2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/2] via 10.1.1.2, 00:44:01, Virtual-Access1 <-Сеть Spoke2 10.0.0.0/8 is variably subnetted, 6 subnets, 2 masks C 10.0.0.0/24 is directly connected, Loopback0 L 10.0.0.1/32 is directly connected, Loopback0 C 10.1.1.0/24 is directly connected, Loopback1 O 10.1.1.1/32 [110/2] via 10.1.1.1, 00:05:00, Virtual-Access2 <-Туннельные интерфейсы Spoke1 O 10.1.1.2/32 [110/2] via 10.1.1.2, 00:44:01, Virtual-Access1 <-Туннельные интерфейсы Spoke2 L 10.1.1.254/32 is directly connected, Loopback1 172.16.0.0/24 is subnetted, 3 subnets 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks C 192.168.1.0/24 is directly connected, Ethernet0/0 L 192.168.1.1/32 is directly connected, Ethernet0/0 Маршруты на Spoke1: Spoke1#sh ip route Gateway of last resort is 172.16.1.5 to network 0.0.0.0 S* 0.0.0.0/0 [1/0] via 172.16.1.5 1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks C 1.1.1.0/24 is directly connected, Loopback0 L 1.1.1.1/32 is directly connected, Loopback0 2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/1002] via 10.1.1.254, 00:05:38, Tunnel0 <-Сеть Spoke2 10.0.0.0/8 is variably subnetted, 5 subnets, 2 masks O 10.0.0.1/32 [110/1001] via 10.1.1.254, 00:05:38, Tunnel0 <- Сети Центрального офиса C 10.1.1.0/24 is directly connected, Loopback1 L 10.1.1.1/32 is directly connected, Loopback1 O 10.1.1.2/32 [110/1002] via 10.1.1.254, 00:05:38, Tunnel0 <-Туннельный интерфейс Spoke2 O 10.1.1.254/32 [110/1001] via 10.1.1.254, 00:02:26, Tunnel0 <-Туннельный интерфейс HUBa 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks C 172.16.1.0/24 is directly connected, Ethernet0/0 L 172.16.1.2/32 is directly connected, Ethernet0/0 Spoke1#traceroute 2.2.2.2 1 10.1.1.254 5 msec 5 msec 5 msec 2 10.1.1.2 9 msec 5 msec * Spoke1#traceroute 10.1.1.2 1 10.1.1.254 5 msec 5 msec 5 msec 2 10.1.1.2 5 msec 10 msec * |
Восстановление канала при падении линка
Выключим Tunnel интерфейс на Spoke, очистим ipsec сессии и обмененными ключами. После этого включим интерфейс обратно:
| Spoke1(config-if)#no shutdown *Aug 6 10:02:27.669: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON *Aug 6 10:02:27.702: %LINEPROTO-5-UPDOWN: Line protocol on Interface Tunnel0, changed state to up *Aug 6 10:02:27.713: %OSPF-5-ADJCHG: Process 1, Nbr 10.0.0.1 on Tunnel0 from LOADING to FULL, Loading Done |
Восстановление туннеля прошло автоматически.
EASY VPN
Идея технологии Easy 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-трансляции в адрес, который выдан сервером из заданного пула
| VPN_HUB# aaa new-model ! aaa authorization network LOCAL-AUTHOR local crypto isakmp policy 10 authentication pre-share group 2 ! crypto isakmp client configuration group VPN-CLIENT-GROUP key vpnclientcisco pool VPN-LOCAL-POOL acl 100 crypto isakmp profile PROFILE-ISAKMP match identity group VPN-CLIENT-GROUP isakmp authorization list LOCAL-AUTHOR client configuration address respond client configuration group VPN-CLIENT-GROUP virtual-template 1 ! crypto ipsec transform-set TRANSFORM-IPSEC esp-aes esp-sha-hmac ! crypto ipsec profile PROFILE-IPSEC set transform-set TRANSFORM-IPSEC set isakmp-profile PROFILE-ISAKMP interface Ethernet0/0 ip address 192.168.1.2 255.255.255.0 ip nat inside ip virtual-reassembly in ! interface Ethernet0/1 ip address 77.1.1.2 255.255.255.0 ip nat outside ip virtual-reassembly in ! interface Virtual-Template1 type tunnel ip unnumbered Ethernet0/1 ip nat inside ip virtual-reassembly in tunnel mode ipsec ipv4 tunnel protection ipsec profile PROFILE-IPSEC ! ip local pool VPN-LOCAL-POOL 172.16.40.1 172.16.40.100 ! ip nat inside source list TONAT interface Ethernet0/1 overload |
(задаем ip адрес VPN HUBа, указываем VPN-группу, режим работы VPN-клиента и аутентификационные данные) VPN_Client# crypto ipsec client ezvpn EZVPN-CLIENT connect auto group VPN-CLIENT-GROUP key vpnclientcisco mode client peer 77.1.1.2 username cisco password cisco xauth userid mode local ! interface Ethernet0/0 ip address 172.16.1.7 255.255.255.0 crypto ipsec client ezvpn EZVPN-CLIENT ! interface Ethernet0/2 ip address 192.168.2.7 255.255.255.0 ip nat inside crypto ipsec client ezvpn EZVPN-CLIENT inside |
| Клиенту выдается автоматически IP VPN_Client#sh ip int br Interface IP-Address OK? Method Status Protocol Ethernet0/0 172.16.1.7 YES NVRAM up up Ethernet0/2 192.168.2.7 YES NVRAM up up Loopback0 7.7.7.7 YES NVRAM up up Loopback10000 172.16.40.49 YES TFTP up up NVI0 172.16.1.7 YES unset up up |
|
Автоматически прописывается ip outside nat (ip nat inside мы должны прописать) и добавляются ACL!
Проверим, что NAT настроился автоматически, прописался исходящий интерфейс и добавились списки контроля доступа ACL интересующего нас трафика
| VPN_Client#sh ip nat statistics Total active translations: 0 (0 static, 0 dynamic; 0 extended) Peak translations: 0 Outside interfaces: Ethernet0/0 Inside interfaces: Ethernet0/2 Hits: 0 Misses: 0 CEF Translated packets: 0, CEF Punted packets: 0 Expired translations: 0 Dynamic mappings: — Inside Source [Id: 106] access-list EZVPN-CLIENT_internet-list interface Ethernet0/0 refcount 0 [Id: 105] access-list EZVPN-CLIENT_enterprise-list pool EZVPN-CLIENT refcount 0 pool EZVPN-CLIENT: netmask 255.255.255.0 start 172.16.40.49 end 172.16.40.49 type generic, total addresses 1, allocated 0 (0%), misses 0 |
Видно, что добавились автоматически два списка доступа. Посмотрим, какой тип трафика они определяют
| VPN_Client#sh access-lists EZVPN-CLIENT_internet-list (не локальные сети пускать в инет) Extended IP access list EZVPN-CLIENT_internet-list 10 deny ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 20 deny ip 192.168.2.0 0.0.0.255 2.2.2.0 0.0.0.255 30 permit ip 192.168.2.0 0.0.0.255 any ! VPN_Client#sh access-lists EZVPN-CLIENT_enterprise-list (локальные сети натить в назначенный IP) Extended IP access list EZVPN-CLIENT_enterprise-list 10 permit ip 192.168.2.0 0.0.0.255 192.168.1.0 0.0.0.255 20 permit ip 192.168.2.0 0.0.0.255 2.2.2.0 0.0.0.255 |
GRE tunnel. OSPF over GRE
Gre представляет собой транспорт для многих типов остальных протоколов, будь то сигнальные сообщения динамических протоколов маршрутизации (OSPF, EIGRP) либо IPv6 пакеты. Данные пакеты инкапсулируются в еще один IP пакет (тип 47) с GRE заголовком. GRE прост в настройке, хотя и разработан первоначально Cisco, сейчас представляет собой открытый стандарт RFC 2784.
GRE туннель создает point-to-point линк со всеми вытекающими из этого проблемами масштабирования. В реальной сети это выливается в создании каждого туннеля для каждого удаленного офиса (маршрутизатора) с выделением отдельной подсети.
| LNS# interface Tunnel1 ip address 10.3.7.3 255.255.255.0 tunnel source Ethernet0/1 tunnel destination 77.1.1.7 |
LAC# interface Tunnel1 ip address 10.3.7.7 255.255.255.0 tunnel source Ethernet0/0 tunnel destination 55.1.1.3 |
| Если мы выбрали GRE, то воспользуемся сразу его преимуществом и настроим OSFP | |
| LNS# router ospf 1 network 10.3.9.0 0.0.0.255 area 0 network 10.3.7.0 0.0.0.255 area 0 network 192.168.1.0 0.0.0.255 area 0 |
LAC# router ospf 1 network 10.3.7.0 0.0.0.255 area 0 network 172.30.1.0 0.0.0.255 area 0 |
Проверка работы OSPF
| LAC#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 3.3.3.3 0 FULL/ - 00:00:30 10.3.7.3 Tunnel1 Все маршруты, полученные через OSPF, теперь доступны через туннельный интерфейс. LAC#sh ip route ospf 10.3.9.0/8 is variably subnetted, 3 subnets, 2 masks O 10.3.9.0/24 [110/2000] via 10.3.7.3, 00:19:02, Tunnel1 < — подсеть туннеля R3 <-> R9 99.0.0.0/32 is subnetted, 1 subnets O 99.99.99.99 [110/2001] via 10.3.7.3, 00:19:02, Tunnel1 < — loopback на R9 O 192.168.1.0/24 [110/1010] via 10.3.7.3, 00:19:02, Tunnel1 < — локальная сеть HQ LAC#ping 192.168.1.1 source 172.30.1.7 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: Packet sent with a source address of 172.30.1.7 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/1/1 ms |
Формат пакета:
GRE over IPSec
| LNS# crypto isakmp policy 10 encr 3des authentication pre-share group 2 ! crypto isakmp key ipseckey123 address 77.1.1.7 ! crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac mode transport ! crypto map GREoverIPSec 5 ipsec-isakmp set peer 77.1.1.7 set transform-set ESP-AES256-SHA1 match address GRE ! ! Так как GRE помечается как тип трафика 47, то достаточно определить для шифрования весь трафик по порту 47 ip access-list extended GRE permit gre any any ! interface Ethernet0/1 ip address 55.1.1.3 255.255.255.0 crypto map GREoverIPSec |
LAC# crypto isakmp policy 10 encr 3des authentication pre-share group 2 ! crypto isakmp key ipseckey123 address 55.1.1.3 ! crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac mode transport ! crypto map GREoverIPSec 5 ipsec-isakmp set peer 55.1.1.3 set transform-set ESP-AES256-SHA1 match address GRE ! ! ip access-list extended GRE permit gre any any ! interface Ethernet0/0 ip address 77.1.1.7 255.255.255.0 crypto map GREoverIPSec ! ! |
Проверка работы GRE over IPSec
| LAC#ping 192.168.1.1 source 172.30.1.7 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: Packet sent with a source address of 172.30.1.7 !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 4/5/6 ms Проверка сходимости IPSec LAC#sh crypto isakmp sa IPv4 Crypto ISAKMP SA dst src state conn-id status 55.1.1.3 77.1.1.7 QM_IDLE 1001 ACTIVE Проверка установления политик безопасности (SA) LAC#sh crypto ipsec sa interface: Ethernet0/0 Crypto map tag: GREoverIPSec, local addr 77.1.1.7 protected vrf: (none) local ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0) remote ident (addr/mask/prot/port): (0.0.0.0/0.0.0.0/47/0) current_peer 55.1.1.3 port 500 PERMIT, flags={origin_is_acl,} #pkts encaps: 109, #pkts encrypt: 28559, #pkts digest: 28559 #pkts decaps: 184, #pkts decrypt: 28784, #pkts verify: 28784 #pkts compressed: 0, #pkts decompressed: 0 #pkts not compressed: 0, #pkts compr. failed: 0 #pkts not decompressed: 0, #pkts decompress failed: 0 #send errors 0, #recv errors 0 local crypto endpt.: 77.1.1.7, remote crypto endpt.: 55.1.1.3 path mtu 1500, ip mtu 1500, ip mtu idb Ethernet0/0 current outbound spi: 0xBCF71DA2(3170311586) PFS (Y/N): N, DH group: none |
Формат пакета:
Работа OSPF over GRE over IPSec
OSPF работает в стандартной конфигурации (как в случае network type broadcast)
| LAC#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 3.3.3.3 0 FULL/ - 00:00:31 10.3.7.3 Tunnel1 |
DMVPN
DMVPN реализует multipoint GRE архитектуру, позволяя использовать, во-первых, одно адресное пространство для всех vpn удаленных офисов, во-вторых, пропускать через туннель большой список сторонних протоколов, а также мультикаст, и в-третьих, устанавливать динамически туннели между региональными удаленными площадками в случае возникновения трафика между ними. Однако есть одно но, данная технология реализуема только на моновендорной сети на Cisco.
Настройка маршрутизатора HQ как DMVPN HUB, Spoke 1 как DMVPN Client
| HUB# interface Tunnel1 description DMVPN_HUB /// настройка mGRE ip address 10.5.5.1 255.255.255.0 tunnel source FastEthernet0/0 tunnel mode gre multipoint tunnel key 111001 no ip redirects ip mtu 1416 /// настройка NHRP ip nhrp map multicast dynamic ip nhrp network-id 101 ip nhrp server-only ip tcp adjust-mss 1376 end |
Spoke# interface Tunnel1 ip address 10.5.5.3 255.255.255.0 no ip redirects ip mtu 1416 ip nhrp map multicast dynamic ip nhrp map multicast 192.168.1.1 (физ.адрес) ip nhrp map 10.5.5.1 192.168.1.1 ip nhrp network-id 101 ip nhrp nhs 10.5.5.1 (туннельный адрес) ip tcp adjust-mss 1380 keepalive 10 3 tunnel source FastEthernet0/0 tunnel mode gre multipoint tunnel key 111001 end |
Проверка работы DMVPN
Проверяем установился ли туннель до DMVPN HUBa.
Обращаем внимание, что NBMA address – реальный адрес HUBa.
| Spoke#sh dmvpn Legend: Attrb --> S — Static, D — Dynamic, I — Incomplete N — NATed, L — Local, X — No Socket # Ent --> Number of NHRP entries with same NBMA peer NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting UpDn Time --> Up or Down Time for a Tunnel ========================================================================== Interface: Tunnel1, IPv4 NHRP Details Type:Spoke, NHRP Peers:1, # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb — — — — — ----- 1 192.168.1.1 10.5.5.254 UP 00:02:59 S На HUBe видны два подключенных удаленных офиса: HUB#sh dmvpn Legend: Attrb --> S — Static, D — Dynamic, I — Incomplete N — NATed, L — Local, X — No Socket # Ent --> Number of NHRP entries with same NBMA peer NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting UpDn Time --> Up or Down Time for a Tunnel ========================================================================== Interface: Tunnel1, IPv4 NHRP Details Type:Hub, NHRP Peers:2, # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb — — — — — ----- 1 172.16.1.2 10.5.5.1 UP 00:04:08 D 1 172.16.2.3 10.5.5.2 UP 00:02:57 D Связка туннельного адреса и реального (физического) HUB#sh ip nhrp brief Target Via NBMA Mode Intfc Claimed 10.5.5.1/32 10.5.5.1 172.16.1.2 dynamic Tu1 < > 10.5.5.2/32 10.5.5.2 172.16.2.3 dynamic Tu1 < > |
Создание динамического GRE туннеля от удаленного офиса Spoke1 к Spoke2
Вначале загрузки у Spoke 1 был только 1 туннель до HUBа. При генерировании трафика (пинга) до Spoke2, сразу же создался туннель до Spoke2
| Router#ping 10.5.5.2 Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 10.5.5.2, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 1/4/5 ms Смотрим установленные туннели на данный момент: Router#sh dmvpn Legend: Attrb --> S — Static, D — Dynamic, I — Incomplete N — NATed, L — Local, X — No Socket # Ent --> Number of NHRP entries with same NBMA peer NHS Status: E --> Expecting Replies, R --> Responding, W --> Waiting UpDn Time --> Up or Down Time for a Tunnel ========================================================================== Interface: Tunnel1, IPv4 NHRP Details Type:Spoke, NHRP Peers:2, # Ent Peer NBMA Addr Peer Tunnel Add State UpDn Tm Attrb — — — — — ----- 1 172.16.2.3 10.5.5.2 UP 00:04:04 D 1 192.168.1.1 10.5.5.254 UP 00:09:31 S |
На данный момент схема сети (рис.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.
| HUB | Spoke 1 | Spoke 2 |
| BROADCAST | BROADCAST | BROADCAST |
| HUB#sh ip ospf neighbor Neighbor I Pri State Dead Time Address Interface 1.1.1.1 0 FULL/DROTHER 00:00:34 10.5.5.1 Tunnel1 2.2.2.2 0 FULL/DROTHER 00:00:31 10.5.5.2 Tunnel1 Spoke_1#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.0.0.1 1 FULL/DR 00:00:36 10.5.5.254 Tunnel1 Spoke_1#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 10.0.0.1 1 FULL/DR 00:00:36 10.5.5.254 Tunnel1 Известные маршруты на Spoke 1 через OSPF Spoke_1#sh ip route Gateway of last resort is 172.16.1.5 to network 0.0.0.0 S* 0.0.0.0/0 [1/0] via 172.16.1.5 1.0.0.0/32 is subnetted, 1 subnets C 1.1.1.1 is directly connected, Loopback1 2.0.0.0/32 is subnetted, 1 subnets O 2.2.2.2 [110/1001] via 10.5.5.3, 00:00:07, Tunnel1 < — внутренняя сеть Spoke2 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks O 10.0.0.0/24 [110/1001] via 10.5.5.254, 00:05:19, Tunnel1 < — внутренняя сеть Центрального офиса C 10.5.5.0/24 is directly connected, Tunnel1 L 10.5.5.1/32 is directly connected, Tunnel1 172.16.0.0/16 is variably subnetted, 2 subnets, 2 masks C 172.16.1.0/24 is directly connected, GigabitEthernet0/0 L 172.16.1.2/32 is directly connected, GigabitEthernet0/0 Связность между Spoke 1 и Spoke 2 осуществляется напрямую: Spoke_1#traceroute 2.2.2.2 source 1.1.1.1 Type escape sequence to abort. Tracing the route to 2.2.2.2 VRF info: (vrf in name/id, vrf out name/id) 1 10.5.5.3 216 msec 256 msec 216 msec |
||
DMVPN c EIGRP
| HUB (R1) | Spoke (R3) | Spoke (R4) |
| По умолчанию, маршруты на Spoke только HUB (из-за split-horizon не видны маршруты Spoke 2) | ||
| HUB#sh ip route eigrp 1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks D 1.0.0.0/8 is a summary, 00:04:18, Null0 D 3.0.0.0/8 [90/409600] via 10.5.5.3, 00:04:24, Tunnel1 D 4.0.0.0/8 [90/409600] via 10.5.5.4, 00:03:51, Tunnel1 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks D 10.0.0.0/8 is a summary, 00:04:18, Null0 Нет маршрута до 4.4.4.4 Spoke_1#sh ip route eigrp D 1.0.0.0/8 [90/324096] via 10.5.5.1, 00:04:04, Tunnel4 3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks D 3.0.0.0/8 is a summary, 00:04:11, Null0 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks D 10.0.0.0/8 is a summary, 00:04:11, Null0 |
||
Выключаем на HUBe split-horizon
| HUB (R1) | Spoke (R3) | Spoke (R4) |
| HUB(conf)# router eigrp 1 no ip split-horizon eigrp 1 |
Нет доп.настройки | Нет доп.настройки |
| HUB#sh ip route eigrp 1.0.0.0/8 is variably subnetted, 2 subnets, 2 masks D 1.0.0.0/8 is a summary, 00:04:18, Null0 D 3.0.0.0/8 [90/409600] via 10.5.5.3, 00:04:24, Tunnel101 D 4.0.0.0/8 [90/409600] via 10.5.5.4, 00:03:51, Tunnel101 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks D 10.0.0.0/8 is a summary, 00:04:18, Null0 Маршрут на Spoke1 появился, но ведет через HUB Spoke_1#sh ip route eigrp D 1.0.0.0/8 [90/324096] via 10.5.5.1, 00:05:45, Tunnel4 3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks D 3.0.0.0/8 is a summary, 00:00:26, Null0 D 4.0.0.0/8 [90/435200] via 10.5.5.1, 00:00:26, Tunnel4 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks D 10.0.0.0/8 is a summary, 00:05:51, Null0 R3#traceroute 4.4.4.4 source 3.3.3.3 Type escape sequence to abort. |
||
Избавимся от HUB-а как промежуточного устройства в связности Spoke1 <-> Spoke2
| HUB (R1) | Spoke (R3) | Spoke (R4) |
| HUB(conf)# router eigrp 1 no ip split-horizon eigrp 1 no ip next-hop-self eigrp 1 |
Нет доп.настройки | Нет доп.настройки |
| Теперь маршрут до сети Spoke_2 ведет напрямую: R3#sh ip route eigrp 1 D 1.0.0.0/8 [90/324096] via 10.5.5.1, 00:00:06, Tunnel4 3.0.0.0/8 is variably subnetted, 2 subnets, 2 masks D 3.0.0.0/8 is a summary, 00:00:06, Null0 D 4.0.0.0/8 [90/435200] via 10.5.5.4, 00:00:04, Tunnel4 10.0.0.0/8 is variably subnetted, 3 subnets, 2 masks D 10.0.0.0/8 is a summary, 00:19:55, Null0 R3#traceroute 4.4.4.4 source 3.3.3.3 Type escape sequence to abort. |
||
PPTP
PPTP стал совместной разработкой консорциумов 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_HUB # Username cisco2 password cisco2 ! interface Loopback1 ip address 192.168.2.2 255.255.255.0 ! vpdn enable ! vpdn-group 1 ! Default PPTP VPDN group accept-dialin protocol pptp virtual-template 1 ! interface Virtual-Template1 ip unnumbered Loopback1 ip mtu 1400 ip tcp adjust-mss 1360 peer default ip address pool PPTP-Pool ppp encrypt mppe auto ppp authentication ms-chap-v2 chap callin ! ip local pool PPTP-Pool 192.168.2.5 192.168.2.50 ! |
Проверка установленных PPTP соединений.
Пользователь cisco2 авторизован и сессия установлена.
| PPTP_HUB #sho vpdn session %No active L2TP tunnels PPTP Session Information Total tunnels 1 sessions 1 LocID RemID TunID Intf Username State Last Chg Uniq ID 55592 0 17168 Vi3 cisco2 estabd 00:04:13 6 |
Пользователю выдан ip адрес из DHCP Pool-а и создан virtual-access
| PPTP_HUB#sh ip int br Interface IP-Address OK? Method Status Protocol Ethernet0/0 unassigned YES NVRAM administratively down down GigabitEthernet0/0 192.168.1.3 YES NVRAM up up GigabitEthernet1/0 77.1.1.3 YES NVRAM up up Loopback0 3.3.3.3 YES NVRAM up up Loopback1 192.168.2.2 YES NVRAM up up Virtual-Access1 unassigned YES unset down down Virtual-Access2 unassigned YES unset up up Virtual-Access3 192.168.2.5 YES unset up up Virtual-Template1 192.168.2.5 YES unset down down |
В случае если возникает задача конкретному PPTP клиенту выдавать принадлежащий только ему IP адрес, то тогда можно прибегнуть к созданию TXT файла с перечислением всех PPTP клиентов.
Настройка на маршрутизаторе:
| ip dhcp pool STATIC import all origin file flash:/static2.txt default-router 192.168.2.2 dns-server 8.8.8.8 8.8.4.4 domain-name lab.local lease 3 ! interface Virtual-Template1 ip unnumbered Loopback1 ip mtu 1400 ip tcp adjust-mss 1360 peer default ip address pool STATIC (PPTP-Pool нам уже не нужен) ppp encrypt mppe auto ppp authentication ms-chap-v2 chap callin |
Сам TXT файлик static2.txt.
| *time* Mar 01 2002 12:23 AM *version* 2 !IP address Type Hardware address Lease expiration VRF 192.168.2.77 /25 1000c.2984.4f84 Infinite 192.168.2.17 /25 1000c.2946.1575 Infinite 192.168.2.18 /25 10000.0000.1111 Infinite |
L2TP
L2TP – это стандарт 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
| IP_add_s_global IP_add_d_global Type 115 |
| L2TP_header |
| L2_sublayer |
| Data |
L2TPv2 инкапсулирует данные в IP/UDP (UDP порт 1701).
| IP_add_s_global IP_add_d_global |
| UDP_s_port UDP_d_port(1701) |
| L2TP_header |
| PPP_header |
| IP_add_s_local IP_add_d_local |
| Data |
L2TPv3 Pseudowire
В архитектуре L2TP, равно как и в архитектуре PPTP, используются следующие понятия:
| LAC | L2TP access concentrator | LAC принимает на себя запросы от клиента и согласует L2TP параметры туннелей и сессий с LNS и передает запрос LNS |
| LNS | L2TP network server | LNS согласует L2TP параметры туннелей и сессий с LAC |
| LCCE | L2TP Control Connection Endpoint | Это LAC, который участвует в сигнальном соединении. |
Модель работы протоколов для L2TPv3 LNS – LNS, а для L2TPv2 LAC – LNS (подробнее см.ниже).
Создадим pseudowire между R5 в Центральном офисе и в R9 в региональном офисе, тем самым расширим сеть 192.168.1.x/24 в региональный офис.
| R5# pseudowire-class L2TP_Class encapsulation l2tpv3 protocol none (то есть не используется динамическое установление сессии) ip pmtu ip local interface GigabitEthernet1/0 ! interface GigabitEthernet0/0 no ip address xconnect 44.1.1.9 1 encapsulation l2tpv3 manual pw-class L2TP_Class l2tp id 1 2 l2tp cookie local 4 55111 l2tp cookie remote 44119 |
R9# pseudowire-class L2TP_Class encapsulation l2tpv3 protocol none (то есть не используется динамическое установление сессии) ip pmtu ip local interface GigabitEthernet0/0 ! interface GigabitEthernet1/0 no ip address xconnect 55.1.1.1 1 encapsulation l2tpv3 manual pw-class L2TP_Class l2tp id 2 1 l2tp cookie local 4 44119 l2tp cookie remote 4 55111 |
Проверка установления сессии:
| R5_VPN_HUB_Pr#sh l2tp session L2TP Session Information Total tunnels 0 sessions 1 LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit 1 2 n/a 1, Gi0/0 est 00:00:03 1 R5_VPN_HUB_Pr#sh l2tp session all L2TP Session Information Total tunnels 0 sessions 1 Session id 1 is up, logical session id 33356, tunnel id n/a Remote session id is 2, remote tunnel id n/a Locally initiated session Unique ID is 4 Session Layer 2 circuit, type is Ethernet, name is GigabitEthernet0/0 Session vcid is 1 Circuit state is UP Local circuit state is UP Remote circuit state is UP Call serial number is 0 Remote tunnel name is Internet address is 44.1.1.9 Local tunnel name is Internet address is 55.1.1.5 IP protocol 115 Session is manually signaled Session state is established, time since change 02:29:58 1130 Packets sent, 1982 received 151213 Bytes sent, 197759 received Last clearing of counters never |
R7 теперь доступен без протоколов маршрутизации:
| R10#ping 192.168.1.7 repeat 10 Type escape sequence to abort. Sending 10, 100-byte ICMP Echos to 192.168.1.7, timeout is 2 seconds: !!!!!!!!!! Success rate is 100 percent (10/10), round-trip min/avg/max = 128/142/180 ms |
Работа OSPF через L2TP
Соседство установилось по умолчанию, включив сеть 192.168.1.0 на R7 и R10
| R7_DATA_Center_Servers#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 192.168.1.10 1 FULL/DR 00:00:37 192.168.1.10 GigabitEthernet0/0 R10#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 7.7.7.7 1 FULL/BDR 00:00:35 192.168.1.7 GigabitEthernet0/0 |
Недостатки:
Если 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.
| *Oct 20 19:52:55.861: L2X tnl 08287:________: Create logical tunnel *Oct 20 19:52:55.865: L2TP tnl 08287:________: Create tunnel *Oct 20 19:52:55.869: L2TP tnl 08287:________: version set to V2 (протокол L2TPv2) *Oct 20 19:52:55.873: L2TP tnl 08287:________: remote ip set to 44.1.1.9 *Oct 20 19:52:55.873: L2TP tnl 08287:________: local ip set to 55.1.1.1 *Oct 20 19:52:55.877: L2TP tnl 08287:00003073: FSM-CC ev Rx-SCCRQ (Start-Control-Connection-Request) LNS проверяет валидность отправителя и наличие собственных ресурсов, также на этом этапе согласуется список поддерживаемых типов pseudowire (Ethernet, Frame Relay) *Oct 20 19:52:55.877: L2TP tnl 08287:00003073: FSM-CC Idle->Proc-SCCRQ *Oct 20 19:52:55.877: L2TP tnl 08287:00003073: FSM-CC do Rx-SCCRQ *Oct 20 19:52:55.881: L2X _____:________: Tunnel author started for LAC *Oct 20 19:52:55.901: L2X _____:________: Tunnel author found *Oct 20 19:52:55.905: L2TP tnl 08287:00003073: Author reply, data source: "VPDN-L2TP" *Oct 20 19:52:55.909: L2X _____:________: class [AAA author, group "VPDN-L2TP"] *Oct 20 19:52:55.913: L2X _____:________: created *Oct 20 19:52:55.917: L2TP tnl 08287:00003073: FSM-CC ev SCCRQ-OK *Oct 20 19:52:55.917: L2TP tnl 08287:00003073: FSM-CC Proc-SCCRQ->Wt-SCCCN Start-Control-Connection-Connected (SCCCN) ожидаем состояния Connected *Oct 20 19:52:55.917: L2TP tnl 08287:00003073: FSM-CC do Tx-SCCRP Start-Control-Connection-Reply (SCCRP) отправили ответное сообщение *Oct 20 19:52:55.917: L2X _____:________: l2x_open_socket: is called *Oct 20 19:52:55.921: L2TP tnl 08287:00003073: Open sock 55.1.1.1:1701->44.1.1.9:1701 Используется UDP с портом 1701 для служебных сообщений *Oct 20 19:52:55.925: L2TP tnl 08287:00003073: FSM-CC ev Sock-Ready *Oct 20 19:52:55.929: L2TP tnl 08287:00003073: FSM-CC in Wt-SCCCN *Oct 20 19:52:55.929: L2TP tnl 08287:00003073: FSM-CC do Ignore-Sock-Up *Oct 20 19:52:55.941: L2X _____:________: Disabled security for VPDN *Oct 20 19:52:56.053: L2TP tnl 08287:00003073: FSM-CC ev Rx-SCCCN *Oct 20 19:52:56.053: L2TP tnl 08287:00003073: FSM-CC Wt-SCCCN->Proc-SCCCN *Oct 20 19:52:56.053: L2TP tnl 08287:00003073: FSM-CC do Rx-SCCCN *Oct 20 19:52:56.053: L2TP tnl 08287:00003073: Got a response in SCCCN from LAC *Oct 20 19:52:56.057: L2TP tnl 08287:00003073: Tunnel Authentication success *Oct 20 19:52:56.061: L2TP tnl 08287:00003073: FSM-CC ev SCCCN-OK *Oct 20 19:52:56.065: L2TP tnl 08287:00003073: FSM-CC Proc-SCCCN->established *Oct 20 19:52:56.069: L2TP tnl 08287:00003073: FSM-CC do Established *Oct 20 19:52:56.073: L2TP tnl 08287:00003073: Control channel up *Oct 20 19:52:56.077: L2TP tnl 08287:00003073: 55.1.1.1<->44.1.1.9 |
Служебный канал установился, теперь устанавливается канал для данных (PPP фреймов).
Стоит отметить, что по одному установившемуся туннелю может проходить множество клиентских сессий.
Для установки сессии для данных LAC отправляет ICRQ (Call-Request), если на LNS достаточно ресурсов, то LNS отвечает сообщением ICRP (Call-Reply). Для завершения установления сессии – LAC отправляет ICCN Incoming-Call-Connected.
| *Oct 20 19:52:56.117: L2X _____:_____:________: Create logical session *Oct 20 19:52:56.121: L2TP _____:_____:________: Create session *Oct 20 19:52:56.121: L2TP _____:_____:________: Using ICRQ FSM Incoming-Call-Request (ICRQ) Здесь передается требуемый pseudowire тип, требуемый для уровня L2 *Oct 20 19:52:56.125: L2TP _____:_____:________: remote ip set to 44.1.1.9 *Oct 20 19:52:56.125: L2TP _____:_____:________: local ip set to 55.1.1.1 *Oct 20 19:52:56.129: L2TP tnl 08287:00003073: FSM-CC ev Session-Conn *Oct 20 19:52:56.129: L2TP tnl 08287:00003073: FSM-CC in established *Oct 20 19:52:56.129: L2TP tnl 08287:00003073: FSM-CC do Session-Conn-Est *Oct 20 19:52:56.129: L2TP tnl 08287:00003073: Session count now 1 *Oct 20 19:52:56.129: L2TP _____:08287:0000754C: Session attached *Oct 20 19:52:56.129: L2TP _____:08287:0000754C: FSM-Sn ev Rx-ICRQ *Oct 20 19:52:56.129: L2TP _____:08287:0000754C: FSM-Sn Idle->Proc-ICRQ *Oct 20 19:52:56.129: L2TP _____:08287:0000754C: FSM-Sn do Rx-ICRQ *Oct 20 19:52:56.129: L2TP _____:08287:0000754C: Chose application VPDN *Oct 20 19:52:56.133: L2TP _____:08287:0000754C: App type set to VPDN *Oct 20 19:52:56.133: L2TP tnl 08287:00003073: VPDN Session count now 1 *Oct 20 19:52:56.189: L2TP 00005:08287:0000754C: FSM-Sn ev ICRQ-OK *Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn Proc-ICRQ->Wt-Tx-ICRP *Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn do Tx-ICRP-Local-Check *Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn ev Local-Cont *Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn Wt-Tx-ICRP->Wt-Rx-ICCN *Oct 20 19:52:56.193: L2TP 00005:08287:0000754C: FSM-Sn do Tx-ICRP Incoming-Call-Reply (ICRP) *Oct 20 19:52:56.197: L2TP 00005:08287:0000754C: Open sock 55.1.1.1:1701->44.1.1.9:1701 *Oct 20 19:52:56.197: L2TP 00005:08287:0000754C: FSM-Sn in Wt-Rx-ICCN (ожидаем ICCN) *Oct 20 19:52:56.397: L2TP 00005:08287:0000754C: FSM-Sn ev Rx-ICCN (ICCN получили) *Oct 20 19:52:56.401: L2TP 00005:08287:0000754C: FSM-Sn Wt-Rx-ICCN->Proc-ICCN *Oct 20 19:52:56.405: L2TP 00005:08287:0000754C: FSM-Sn do Rx-ICCN *Oct 20 19:52:56.437: L2TP 00005:08287:0000754C: FSM-Sn ev ICCN-OK *Oct 20 19:52:56.441: L2TP 00005:08287:0000754C: FSM-Sn Proc-ICCN->established *Oct 20 19:52:56.445: L2TP 00005:08287:0000754C: FSM-Sn do Established *Oct 20 19:52:56.449: L2TP 00005:08287:0000754C: Session up (Ceccия для данных установилась) *Oct 20 19:52:58.197: L2TP 00005:08287:0000754C: FSM-Sn in established *Oct 20 19:52:58.241: %LINEPROTO-5-UPDOWN: Line protocol on Interface Virtual-Access3, changed state to up *Oct 20 19:52:58.273: %LINK-3-UPDOWN: Interface Virtual-Access3, changed state to up |
В нашем примере сформировался один туннель между LAS и LNS и одна пользовательская сессия.
| ISP_NAT#sh l2tun tunnel L2TP Tunnel Information Total tunnels 1 sessions 1 LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/ Count VPDN Group 30933 12403 LNS est 55.1.1.1 1 1 ISP_NAT#sh l2tp session L2TP Session Information Total tunnels 1 sessions 1 LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit 32700 30028 30933 LNS, Vi1 est 00:51:35 0 |
Настройка L2TP в добровольном туннельном режиме очень похожа в настройке с обязательным туннельным режимом. Различие в настройке VPDN группы следующее:
- Команда terminate-from не нужна
- Аутентификация L2TP туннеля выключена командой no l2tp tunnel authentication
Настройка L2TPv2
На некоторых типах маршрутизаторов нельзя создать interface virtual-ppp, поэтому привожу в качестве альтернативны другую рабочую конфигурацию через создание interface Dialer. Конфигурация предоставляется «AS IS».
| LNS# aaa new-model aaa authorization network default local ! vpdn enable vpdn-group VPDN-L2TP accept-dialin protocol l2tp virtual-template 2 lcp renegotiation on-mismatch terminate-from hostname LAC l2tp tunnel password 0 cisco123 ip pmtu ! interface Virtual-Template2 ip unnumbered GigabitEthernet0/0 autodetect encapsulation ppp peer default ip address pool L2TP-pool ppp authentication ms-chap-v2 |
LAC# vpdn enable ! vpdn-group 1 request-dialin protocol l2tp pool-member 1 initiate-to ip 55.1.1.1 source-ip 44.1.1.9 local name LAC (имя должно совпадать с terminate-from на LNS) l2tp tunnel password 0 cisco123 ! interface Dialer1 ip address negotiated encapsulation ppp dialer pool 1 dialer idle-timeout 0 dialer string 123 dialer vpdn dialer-group 1 ppp authentication chap callin ppp chap hostname LNC ppp chap password 0 cisco123 ! ip route 192.168.1.0 255.255.255.0 Dialer1 |
Конфигурация L2TPv2 через interface virtual-ppp
| LNS# aaa new-model ! aaa authorization network default local ! username LAC password 0 cisco123 ! vpdn enable vpdn-group VPDN-L2TP accept-dialin protocol l2tp virtual-template 2 terminate-from hostname LAC l2tp tunnel password 0 cisco123 ! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface Virtual-Template2 ip unnumbered Loopback0 autodetect encapsulation ppp no peer default ip address ppp authentication ms-chap-v2 ! ip route 172.30.1.0 255.255.255.0 7.7.7.7 ! добавляем статический маршрут до сети удаленного офиса R7 (P.S. маршрут до 7.7.7.7 добавляется автоматически при установлении сессии |
LAC# username LNS password 0 cisco123 ! l2tp-class client.init.class authentication password cisco123 ! pseudowire-class pwclass1 encapsulation l2tpv2 protocol l2tpv2 client.init.class ip local interface Ethernet0/0 ! interface Loopback0 ip address 7.7.7.7 255.255.255.255 ! interface Virtual-PPP1 ip unnumbered loopback0 ppp authentication ms-chap-v2 no cdp enable pseudowire 55.1.1.3 1 pw-class pwclass1 ! ip route 192.168.1.0 255.255.255.0 Virtual-PPP1 ! добавляем статический маршрут до ЦО (P.S. маршрут до 3.3.3.3 добавляется автоматически при установлении сессии |
Проверка установления туннеля и заодно проверяем работу сессии через пинг с внутренней сети удаленного клиента (LAC) и просмотра статистики сессионных пакетов на L2TP HUBe (LNS)
| LNS#show vpdn L2TP Tunnel and Session Information Total tunnels 1 sessions 1 LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/ Count VPDN Group 60224 63290 LAC est 77.1.1.7 1 VPDN-L2TP LocID RemID TunID Username, Intf/ State Last Chg Uniq ID LAC#sho vpdn LocID RemID TunID Username, Intf/ State Last Chg Uniq ID |
| LNS#sh caller user LAC
User: LAC, line Vi3, service PPPoVPDN <после прохождения всех ping-ов проверяем вновь> User: LAC, line Vi3, service PPPoVPDN |
Проверяем доступность сети Центрального офиса (LNS) с R7 LAC#ping 192.168.1.1 source 172.30.1.7 repeat 100 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: Packet sent with a source address of 172.30.1.7 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), round-trip min/avg/max = 1/4/6 ms |
Формат пакета L2TPv2
Overhead UDP (8байт) + L2TPv2 (8байт) + PPP (4 байта) +IPv4 (20 байт) = 40байт
Работа OSPF через L2TPv2
| OSPF работает словно через broadcast сеть LNS# router ospf 1 network 3.3.3.3 0.0.0.0 area 0 network 192.168.1.0 0.0.0.255 area 0 default-information originate always |
Объявим сеть 3.3.3.3 в ospf area 0 LAC# interface Loopback1 ip address 77.77.77.77 255.255.255.255 ! router ospf 1 network 3.3.3.3 0.0.0.0 area 0 network 77.77.77.77 0.0.0.0 area 0 |
LSA протокола OSPF через L2TPv2
Обратите, пожалуйста, внимание на получившийся overhead.
Overhead UDP (8байт) + L2TPv2 (8байт) + PPP (4 байта) +IPv4 (20 байт) = 40байт
Проверка установленного соседства
| LNS#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 7.7.7.7 0 FULL/ - 00:00:30 7.7.7.7 Virtual-Access3 LAC#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 3.3.3.3 0 FULL/ - 00:00:35 3.3.3.3 Virtual-PPP1 |
Настройка для L2TPv3
Настройка L2TPv3 практически ничем не отличается на удаленных клиентах, в то время как настройка на VPN HUB-е отличается очень разительно.
| LNS# username LAC password 0 cisco123 ! pseudowire-class client.init.pw encapsulation l2tpv3 protocol l2tpv3 client.inint.class ip local interface Ethernet0/1 ! interface Virtual-PPP1 ip unnumbered Loopback0 ppp authentication ms-chap-v2 pseudowire 77.1.1.7 1 pw-class client.init.pw ! interface Loopback0 ip address 3.3.3.3 255.255.255.255 ! interface Virtual-PPP1 ip unnumbered Loopback0 ppp authentication ms-chap-v2 pseudowire 77.1.1.7 1 pw-class client.init.pw ! ip route 172.30.1.0 255.255.255.0 Virtual-PPP1 |
LAC# username LNS password 0 cisco123 ! pseudowire-class pwclass2 encapsulation l2tpv3 protocol l2tpv3 client.init.class ip local interface Ethernet0/0 ! interface Virtual-PPP1 ip address negotiated ppp authentication ms-chap-v2 no cdp enable pseudowire 55.1.1.3 1 pw-class pwclass2 ! ip route 192.168.1.0 255.255.255.0 Virtual-PPP1 |
Проверка установленной L2TPv3 сессии на LNS
| LNS#show vpdn L2TP Tunnel and Session Information Total tunnels 1 sessions 1 LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/ Count VPDN Group 4168123058 3050381103 LAC est 77.1.1.7 1 client.inint.cl LocID RemID TunID Username, Intf/ State Last Chg Uniq ID Vcid, Circuit 2122433254 2810410257 4168123058 1, Vp1 est 00:16:22 53 Сессия в состояние established, туннельные ID совпадают |
Проверка установленной L2TPv3 сессии на LAC
| LAC#show vpdn L2TP Tunnel and Session Information Total tunnels 1 sessions 1 LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/ |
Формат пакета L2TPv3
Overhead L2TPv3 (4байта) + HDLC (4байта) = 8 байт
Проверяем работу сессии через пинг с внутренней сети удаленного клиента (LAC) и просмотра статистики сессионных пакетов на L2TP HUBe (LNS)
| Проверка установления L2TPv3 сессии LNS#show caller user LAC User: LAC, line Vp1, service PPP Connected for 00:01:52, Idle for 00:01:52 Timeouts: Limit Remaining Timer Type - - - PPP: LCP Open, MS CHAP V2 (<-->), IPCP IP: Local 3.3.3.3, remote 7.7.7.7 Counts: 1241 packets input, 74748 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 1078 packets output, 78056 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets <после прохождения всех ping-ов проверяем вновь> LNS#show caller user LAC User: LAC, line Vp1, service PPP Connected for 00:02:02, Idle for 00:02:02 Timeouts: Limit Remaining Timer Type - - - PPP: LCP Open, MS CHAP V2 (<-->), IPCP IP: Local 3.3.3.3, remote 7.7.7.7 Counts: 1343 packets input, 84976 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 1180 packets output, 88552 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets |
Пропингуем 100 пакетов удаленной сети через туннель LAC#ping 192.168.1.1 source 172.30.1.7 repeat 100 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: Packet sent with a source address of 172.30.1.7 !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Success rate is 100 percent (100/100), round-trip min/avg/max = 2/4/29 ms |
L2TPv2 over IPSec
Протокол L2TP не обеспечивает защищенность передаваемых по нему данных, поэтому для обеспечения целостности и конфиденциальности данных используем набор протоколов IPSec. Из средств безопасности L2TP может предложить аутентификацию хоста, инициализирующего туннель, а также PPP аутентификацию. Так как в нашем примере использован протокол L2TPv2, который использует IP/UDP инкапсуляцию, то достаточно в крипто ACL определить лишь UDP трафик по порту 1701. В настройке IPSec используется транспортный режим, а не туннельный, чтобы шифровать трафик от оконечного клиента оконечному (в транспортном режиме), нежели создавать дополнительные IP туннельные интерфейсы и шифровать трафик только между ними (в туннельном режиме).
Схема сети:
| LNS# crypto isakmp policy 10 encr 3des authentication pre-share group 2 ! crypto isakmp key ipseckey123 address 77.1.1.7 ! crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac mode transport ! crypto map L2TP_VPN 10 ipsec-isakmp set peer 77.1.1.7 set transform-set ESP-AES256-SHA1 match address L2TP_TRAFFIC ! ! Так как мы используем L2TPv2, то достаточно! определить для шифрования весь UDP трафик! по порту 1701 ip access-list extended L2TP_TRAFFIC permit udp host 55.1.1.3 eq 1701 host 77.1.1.7 eq 1701 ! interface Ethernet0/1 ip address 55.1.1.3 255.255.255.0 crypto map L2TP_VPN |
LAC# crypto isakmp policy 10 encr 3des authentication pre-share group 2 ! crypto isakmp key ipseckey123 address 55.1.1.3 ! crypto ipsec transform-set ESP-AES256-SHA1 esp-aes 256 esp-sha-hmac mode transport ! crypto map L2TP_VPN 10 ipsec-isakmp set peer 55.1.1.3 set transform-set ESP-AES256-SHA1 match address L2TP_TRAFFIC ! ! ip access-list extended L2TP_TRAFFIC permit udp host 77.1.1.7 eq 1701 host 55.1.1.3 eq 1701 ! interface Ethernet0/0 ip address 77.1.1.7 255.255.255.0 crypto map L2TP_VPN ! ! |
Проверяем работу сессии через пинг с внутренней сети удаленного клиента (LAC) и просмотра статистики сессионных пакетов на L2TP HUBe (LNS)
| Проверяем статистики L2TPv3 сессии LNS#sh caller user LAC User: LAC, line Vi3, service PPPoVPDN Connected for 00:04:10, Idle for 00:00:05 Timeouts: Limit Remaining Timer Type - - - PPP: LCP Open, MS CHAP V2 -->), IPCP IP: Local 3.3.3.3, remote 7.7.7.7 Counts: 247 packets input, 16456 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 129 packets output, 3846 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets <после прохождения всех ping-ов проверяем вновь> LNS#sh caller user LAC User: LAC, line Vi3, service PPPoVPDN Connected for 00:04:45, Idle for 00:00:02 Timeouts: Limit Remaining Timer Type - - - PPP: LCP Open, MS CHAP V2 (ß>), IPCP IP: Local 3.3.3.3, remote 7.7.7.7 Counts: 327 packets input, 23288 bytes, 0 no buffer 0 input errors, 0 CRC, 0 frame, 0 overrun 188 packets output, 4226 bytes, 0 underruns 0 output errors, 0 collisions, 0 interface resets |
Пропингуем 100 пакетов удаленной сети через туннель LAC#ping 192.168.1.1 repeat 100 source 172.30.1.7 Type escape sequence to abort. Sending 100, 100-byte ICMP Echos to 192.168.1.1, timeout is 2 seconds: !.!!!!!!!.!!!!!.!!!!!.!!!.!!!!!..!.!!!!!!!!!!!!.!!!!!..!!!!. |
Формат пакета L2TPv2 over IPSec
Формат пакета IP | ESP header | UDP | L2TP | PPP | ESP trailer | Auth trailer
Overhead 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 соседний маршрутизатор.
| LNS#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 7.7.7.7 0 FULL/ - 00:00:35 7.7.7.7 Virtual-Access3 192.168.1.1 1 FULL/DR 00:00:33 192.168.1.1 Ethernet0/0 LNS#sh ip route C 7.7.7.7 is directly connected, Virtual-Access3 O 77.77.77.77/32 [110/2] via 7.7.7.7, 21:54:59, Virtual-Access3 172.30.0.0/24 is subnetted, 1 subnets S 172.30.1.0 [1/0] via 7.7.7.7 192.168.1.0/24 is variably subnetted, 2 subnets, 2 masks |
Масштабирование. Подключение нового удаленного офиса через L2TPv2
Настройка для LNS, т.е. для L2TPv2 HUBа минимальная – необходимо лишь добавить пользователя для PPP CHAP авторизации. Если этого не сделать, то будет следующая ошибка:
| *Nov 9 10:31:35.178: VPDN uid:123 disconnect (AAA) IETF: 17/user-error Ascend: 26/PPP CHAP Fail *Nov 9 10:31:35.178: VPDN uid:123 vpdn shutdown session, result=2, error=6, vendor_err=0, syslog_error_code=8, syslog_key_type=1 |
Добавляем второго LAC
| LNS# username LAC_9 password 0 cisco123 |
LAC_9# username LNS password 0 cisco123 ! l2tp-class client.init.class authentication password cisco123 ! pseudowire-class pwclass1 encapsulation l2tpv2 protocol l2tpv2 client.init.class ip local interface Ethernet0/0 ! interface Loopback0 ip address 9.9.9.9 255.255.255.255 ! interface Virtual-PPP1 ip address loopback0 ppp authentication ms-chap-v2 no cdp enable pseudowire 55.1.1.3 1 pw-class pwclass1 ! ip route 192.168.1.0 255.255.255.0 Virtual-PPP1 |
После этого на LNS уже 2 туннеля
| LNS#sh vpdn tunnel L2TP Tunnel Information Total tunnels 2 sessions 2 LocTunID RemTunID Remote Name State Remote Address Sessn L2TP Class/ Count VPDN Group 35949 21672 LAC est 77.1.1.7 1 VPDN-L2TP 49973 18492 LAC_9 est 44.1.1.9 1 VPDN-L2TP |
Работа OSPF в L2TPv2
В случае подключение удаленных офисов через L2TPv2 – нет ограничений в использовании динамических протоколов маршрутизации. Для включения OSPF заведем на каждом удаленном маршрутизаторе по сети на loopback-е:
| LNS# interface Loopback0 ip address 3.3.3.3 255.255.255.255 router ospf 1 network 3.3.3.3 0.0.0.0 area 0 |
LAC# interface Loopback0 ip address 7.7.7.7 255.255.255.255 ! interface Loopback1 ip address 77.77.77.77 255.255.255.255 ! router ospf 1 router-id 7.7.7.7 network 7.7.7.7 0.0.0.0 area 0 network 77.77.77.77 0.0.0.0 area 0 |
LAC_9# interface Loopback0 ip address 9.9.9.9 255.255.255.255 ! interface Loopback1 ip address 99.99.99.99 255.255.255.255 ! router ospf 1 router-id 9.9.9.9 network 9.9.9.9 0.0.0.0 area 0 network 99.99.99.99 0.0.0.0 area 0 |
Проверяем OSPF соседство и настроенные маршруты
| LNS#sh ip ospf neighbor Neighbor ID Pri State Dead Time Address Interface 9.9.9.9 0 FULL/ - 00:00:39 9.9.9.9 Virtual-Access3 7.7.7.7 0 FULL/ - 00:00:39 7.7.7.7 Virtual-Access4 192.168.1.1 1 FULL/DR 00:00:39 192.168.1.1 Ethernet0/0 Все региональные офисы видят маршруты друг друга через R3 – L2TPv2 HUB LAC_9#sh ip route ospf (видны маршруты маршрутизатора R7) 7.0.0.0/32 is subnetted, 1 subnets O 7.7.7.7 [110/3] via 3.3.3.3, 00:02:14, Virtual-PPP1 77.0.0.0/32 is subnetted, 1 subnets O 77.77.77.77 [110/3] via 3.3.3.3, 00:02:14, Virtual-PPP1 Трассировка между удаленными офисами: LAC_9#traceroute 77.77.77.77 source 99.99.99.99 Type escape sequence to abort. Tracing the route to 77.77.77.77 VRF info: (vrf in name/id, vrf out name/id) 1 3.3.3.3 5 msec 2 msec 4 msec 2 7.7.7.7 5 msec 4 msec * |
В случае не использования 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 будет выглядеть как непосредственно подключенный:
| C 16.16.16.16 is directly connected, Virtual-Access4) |
Спасибо самым стойким и усидчивым читателям, дошедшим до конца данной статьи, за ваше внимание и терпение. Как я уже отмечал в начале статьи, мне бы хотелось, чтобы данный обзор стал небольшим сборником и справочным материалом, который необязательно помнить наизусть, но к которому можно всегда обратиться. Надеюсь, что это реально поможет моим коллегам по «цеху» учесть нюансы в построении качественного, красивого и грамотного сетевого дизайна, избежать подводных камней и в целом сделать свою работу на высшем уровне! С вами был Семенов Вадим.
P.S.
Ну и на десерт: для любопытных и пытливых умов, желающих ознакомиться поглубже в способе инкапсуляции того или иного типа VPN-а, поглубже разобраться в формате различных заголовков — возможно скачать дампы пакетов, собранных при обзоре указанных выше VPN-ов здесь.
С радостью отвечу на возникшие вопросы по статье.
Автор: vadims06
