Пользователь
0,0
рейтинг
19 декабря 2014 в 11:46

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

Коллеги, здравствуйте. Меня зовут Семенов Вадим и я хочу представить статью, посвященную вопросу масштабируемости 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 spokeN VTI и своя подсеть.
На Spoke требуется добавление маршрутов до удаленных Spoke-в. Пропускает multicast!
По умолчанию на каждый SVTI только одна SA IPSec c traffic selector “IP any any.” Нет команды crypto ACL. В туннель заворачиваются те сети, которые определены через static route на SVTI.
Regular IPSec (Profile, Static VTI and IGP)
isakmp,
IPSec Profile,
VTI (Virtual Tunnel Interface)
isakmp,
IPSec Profile,
VTI (Virtual Tunnel Interface)
Да:
isakmp,
новый VTI (Virtual Tunnel Interface)
Нет
Да
Не масштабируемый.
На каждый Spoke по SVTI.
N spoke – N VTI и своя подсеть. Маршруты от IGP попадают в туннель.
IPSec with dynamic IP (Dynamic VTI and Static VTI and IGP)
keyring,
isakmp policy,
isakmp profile,
ipsec profile,
loopback for unnumbered interface (обязательно),
Virtual-Template type tunnel
keyring,
isakmp policy,
isakmp profile,
ipsec profile,
loopback for unnumbered interface,
Static VTI
Нет
Нет
Да
Очень масштабируемый. Все spoke и hub находятся в одной сети! Dynamic VTI (DVTIs) также point-to-point интерфейс. В режиме point-to-multipoint соседство OSPF не устанавливается.
Использование Unnumbered IP в качестве адреса DVTI обязательно
Easy VPN
ААА – для авторизации клиентов
Isakmp,
isakmp policy,
isakmp profile,
ipsec profile,
interface,
Virtual-Template type tunnel
DHCP для клиентов
Minimum
IPsec client конфигурация, с указанием VPN-сервера, VPN группы, пользователя для ааа,
Указание внутренних и внешний интерфейсов.
Нет
Нет
Да
Масштабируемый.
Если ранее был настроен NAT/PAT, то перед внедрением EASY VPN должна быть эта конфигурация удалена. Есть особенности в настройке transform-set.
 
GRE
Interface Tunnel,
Static route
Interface Tunnel,
Static route
Да
Int tunnel,
Static route
Да
Static route
Да
Не масштабируемый. Образует P2P линк, на каждый туннель – своя подсеть. Прекрасно подходит для туннелирования IGP протоколов.
IGP over GRE
Interface Tunnel,
Static route
Interface Tunnel,
Static route
Да
Int tunnel
Нет
Да
Не масштабируемый.
На каждый туннель – своя подсеть. IGP протоколы работают через туннель при настройках по умолчанию.
DMVPN (проприетарный)
DMVPN phase 1 – кон-ция только mGRE
DMVPN phase 2 – настройка ipsec profile для защиты трафика
Minimum:
DMVPN phase 1 – кон-ция только mGRE
DMVPN phase 2 – настройка ipsec profile для защиты трафика
Нет
Нет:
при добавлении нового spoke – туннель до него строится автоматически
Да:
EIGRP на HUB выключаем расщепление горизонта  и сохранения себя в качестве next-hop в анонсах маршрута
Наиболее масштабируемый протокол. GRE multipoint. Туннели между удаленными офисами создаются динамически.
PPTP
Vpdn-group,
interface Virtual-Template,
IP local pool,
username/password для авториз-и, static route до сетей уд.офиса
service internal (для включения настроек pptp клиента),
vpdn-group, interface Dialer, dialer-list,
static route до сетей центр., удал. офиса
Да
Static route для внутренних сетей за PPTP клиентом
Да
Static route для новых внутренних сетей за новым PPTP клиентом
Да
Масштабируемый с ограничениями.
Морально устаревший протокол, уязвимости в криптографии в протоколе авторизации MSCHAPv2. Чаще всего используется для создания удаленного доступа. Поддерживается множеством популярных версий ОС Windows. Исп только один протокол для шифрования -MPPE (RC4 со 128-битным ключом). Поддерживает мультикаст, т.к. PPP инкапсулируются в GRE.
IGP over PPTP
Vpdn-group,
interface Virtual-Template,
IP local pool,
username/password для авториз-и, IGP protocol (router ospf process)
service internal (для включения настроек pptp клиента),
vpdn-group, interface Dialer, dialer-list,
IGP protocol (router ospf process)
Нет
Нет
Да
Масштабируемый с ограничениями.
Поддерживает мультикаст, т.к. PPP инкапсулируются в GRE.
Морально устаревший протокол  -> альтернатива L2TP over IPSec
L2TPv3
xconnect

pseudowire-class
xconnect
pseudowire-class
xconnect
Да
xconnect
Нет
Да
Не масштабируемый.
Отлично подходит для разнесения «native» L2 vlan-а через IP сеть. Но, необходимо наличие резервного шлюза по умолчанию. Создавая xconnect на интерфейсе маршрутизатора мы должны удалить IP адрес с его интерфейса, тем самым удалив маршрут по умолчанию для всех устройств внутри этой сети.
L2TPv2/v3
aaa new-model,
username для авторизации L2TP пира,
VPDN-group,
interface Virtual-Template,
static route до сетей уд. офиса
username для авторизации L2TP HUBa,
interface virtual-ppp,
pseudowire class,
static route до сетей центр., удал. офиса
Да:
static route до внутренних сетей удаленного офиса
Да:
static route до внутренних сетей удаленного офиса
Да
Масштабируемый.
L2TPv3 дает большие преимущества, позволяя инкапсулировать не только PPP трафик, как L2TPv2, но и передавать метку VLANа и, а также инкапсулировать HDLC, Frame Relay.
IGP over L2TPv2/v3
aaa new-model,
username для авторизации L2TP пира,
VPDN-group,
interface Virtual-Template,
IGP (router ospf process)
username для авторизации L2TP HUBa,
interface virtual-ppp,
pseudowire class,
IGP (router ospf process)
Нет
Нет
Да
Очень масштабируемый. Позволяет настраивать протоколы маршрутизации «по умолчанию», связь удаленных офисов осуществляется через L2TPv2/v3 HUB (в центральном офисе).


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


В процессе установления соединения через IPSec двум участникам защищенного канала необходимо согласовать значительный ряд параметров: по необходимости они должны аутентифицировать друг друга, сгенерировать и обменяться общими ключами (причем через недоверенную среду), установить какой трафик шифровать (от какого отправителя и к какому получателю), а также договориться с помощью каких протоколов шифровать, а с помощью каких — аутентифицировать. Служебной информации предполагается обменяться много, не правда ли? По этой причине IPSec и состоит из стека протоколов, обязанность которых обеспечить установление, работу и управление защищенным соединением. Процесс установления соединения состоит из 2 фаз: первая фаза устанавливается для того, чтобы обеспечить безопасный обмен 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, поэтому для уменьшения конфигурации на оконечных устройствах после подключения очередного удаленного офиса, возможно пойти двумя путями:
  1. Отойти от crypto map к VTI и настроить динамическую маршрутизацию.
  2. Для настройки динамического протокола маршрутизации (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.
Tracing the route to 4.4.4.4
  1 10.5.5.1 88 msec 92 msec 76 msec
  2 10.5.5.4 128 msec *  140 msec


Избавимся от 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.
Tracing the route to 4.4.4.4
  1 10.5.5.4 84 msec *  72 msec

 

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 добавляется автоматически при установлении сессии
LNS#show ip route
7.0.0.0/32 is subnetted, 1 subnets
C 7.7.7.7 is directly connected, Virtual-Access3 )
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 добавляется автоматически при установлении сессии
3.0.0.0/32 is subnetted, 1 subnets
C 3.3.3.3 is directly connected, Virtual-PPP1 )

Проверка установления туннеля и заодно проверяем работу сессии через пинг с внутренней сети удаленного клиента (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
                                              Vcid, Circuit
46580   40688     60224         LAC, Vi3        est       00:14:12         102

LAC#sho vpdn
L2TP Tunnel and Session Information Total tunnels 1 sessions 1
LocTunID   RemTunID   Remote Name  State   Remote Address   Sessn L2TP Class/
                                                                                                    Count VPDN Group
  63290         60224               LNS          est         55.1.1.3              1 client.init.cla

LocID    RemID    TunID    Username, Intf/    State     Last Chg      Uniq ID
                                            Vcid, Circuit
40688    46580    63290         1,  Vp1            est        00:20:54          8

LNS#sh caller user LAC

User: LAC, line Vi3, service PPPoVPDN
Connected for 00:03:34, Idle for 00:00:04
Timeouts: Limit Remaining Timer Type
— — -
PPP: LCP Open, MS CHAP V2 (<-->), IPCP
IP: Local 3.3.3.3, remote 7.7.7.7
Counts: 101 packets input, 2932 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
78 packets output, 3770 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:03:40, 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: 201 packets input, 13332 bytes, 0 no buffer
0 input errors, 0 CRC, 0 frame, 0 overrun
179 packets output, 15650 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
Проверяем доступность сети Центрального офиса (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/
                                                                                                         Count VPDN Group
3050381103 4168123058          LNS             est         55.1.1.3            1     client.init.cla
 
     LocID               RemID       TunID        Username, Intf/         State       Last Chg   Uniq ID  
                                                                     Vcid, Circuit                                 
 2810410257      2122433254 3050381103      1, Vp1               est        00:15:57        5        

 
Формат пакета 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
карма
19,0
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Администрирование

Комментарии (39)

  • +2
    Отличная статья. По размера охваченного материала вам бы неплохо связаться с создателем цикла Сети для самых маленьких и добавить ее в их библиотечку)
    • +1
      так это они вроде и есть.
    • +4
      Спасибо!
      На самом деле по хронологии событий сначала я написал статью для Сетей для самых маленьких и только потом Марат предложил мне опубликовать её здесь)
  • +1
    Вы забыли предупредить, что Aggressive Mode использовать можно только в случае с PKI. С PSK его использовать нельзя, т.к. он не выполняет аутентификацию сторон.
    • +4
      он не выполняет аутентификацию сторон

      Не так.

      Он не скрывает identity и позволяет выполнять offline атаку на PSK. Однако, двухсторонняя аутентификация там все равно есть.
  • +1
    Это просто прекрасно. Хабр торт!
    • +1
      На LinkMeUp пост появился чуть раньше, видимо НЛО долго соображало.
  • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      Пользовательский → L2/L3.
  • +4
    Могуче! Вот именно такие статьи и создают Хабру славу ресурса, где есть не только корпоративный PR!
  • 0
    sstp уже не сыр?)
  • +3
    Про VXLAN ни слова, хотя вполне себе туннель, причём работающий в интернетах. Алсо, два моих любимых метода организации VPN:

    через ssh
    через tor с помощью ssh (отлично работает, кстати).
    • 0
      Если Вы имеете в виду VXLAN применительно к Дата центрам (а если точнее то для применению их на Nexus 1000v и проч Nexus ), то это уже немного другая религия под названием «Дата центры», туда же можно было бы отнести и технологию OTV, для объединения нескольких дата центров через IP, но это я сознательно опустил.
      Через ssh вполне справедливое замечание и я так понимаю, что она относится к Remote Access? Однако, представьте задачу объяснить, допустим, женщине из бухгалтерии, которой нужно в выходные подключиться к корпоративной сети для сверки баланса, проделать следующее: «запускаете Putty, стучитесь по ssh на такой то IP, авторизуетесь и вуа-ля — теперь можно подключаться на свой лупбэк» ) Если это выглядит как-то по-другому, то поправьте меня.
      • 0
        А что мне мешает поднять vxlan через интернеты? юдипя юдипёй. И без мультикастиков работающая.

        А для бухгалтерии эта штука во-первых будет «в автозапуске», а во-вторых ярлыком на «рабочем столе». Что там шайтан-майтан ключи сысыха её касаться не должно.

        Алсо, при чём тут лупбэк? Я про -w режим. socks proxy — это уже для гурманов и индивидуального использования.
    • 0
      За туннели over ssh не в качестве временного workaround, а production-решения, я бы с волчьим билетом выгонял из профессии.
      • 0
        Продакшен разный бывает. Если ci'ка это делает — и это часть продакшена, почему не?
  • +1
    Постер от Juniper про VPN, если кто захочет на стенку повесить. На английском правда.
  • 0
    Я бы добавил в описание класс ошибок, связанный с тем, что на одной стороне есть SA, а на другой его нет. Такая ситуация может возникнуть например при перезагрузке одного из роутеров, на котором терминируется IPSEC-канал. В общем случае при возникновении данных условий, сторона, которая имеет SA будет по прежнему шифровать трафик, который не может быть расшифрован другой стороной, т.к. она не имеет соответствующего SA. Данная ситуация может сохраняться в течении lifetime для SA, который по умолчанию кажется что-то около суток. Особенно данная ошибка критично там, где используются dynamic crypto map, т.к. в этом случае обмен пакетами ISAKMP может начать только одна сторона, как правило это spoke, и если там есть stale SA, то это закончится описанной ситуацией. Проблема решается включением isakmp keepalive.

    Ну и хотелось бы услышать в статье, чем отличается DMVPN Phase 2 от Phase3. Самое важное архитектурное отличие — Phase3 позволяет строить spoke-to-spoke туннели между разными NBMA.
  • 0
    Добавьте пожалуйста упоминание о vtun. Простой, надежный, популярный, а упоминания нет. Спасибо.
  • 0
    В Linux есть еще multipoint GRE — получается один виртуальный интерфейс на большое поличество туннелей, масштабируется он заметно лучше одноточечных GRE.

    geektimes.ru/post/48276/

    Все маршрутизаторы получаются в одной подсети + своя подсеть на каждый офис.
    На каждом маршрутизаторе настроен один туннельный интерфейс, независимо от количества офисов.
    • 0
      mGRE — это часть технологии DMVPN, о которой тут упоминается. Там кроме mGRE задействован ещё NHRP и IGP. Ну и ipsec естественно.
      • 0
        да, mGRE упоминается как часть DMVPN.
        Я делаю акцент на том что mGRE доступен в Linux системах из коробки, снимает проблему GRE с кучей туннелей и очень прост в настройке.

        Думаю что mGRE вполне может упоминаться в таблице отдельной строкой, наравне с GRE.
        • 0
          GRE и mGRE сам по себе, без ipsec не может считаться VPN-технологией, т.к. он не реализует функции целостности, конфиденциальности, аутентификации и т.п. Это просто туннель, данные идут чистым текстом.
          • 0
            Частично согласен, но тут он ничуть не хуже GRE, который выделен в отдельный тип сети.

            Трафик действительно лучше защищать через ipsec, не только из-за секретности, но из-за фильтрации вложенного трафика. Например в моём случае неожиданно внутри GRE без шифрования стал фильтроваться OSPF-трафик, хотя в дата-центре фильтрация выключена — сейчас дата-центр общается на тему этой фильтрации с поставщиком оборудования.

            Опять же ipsec не добавляет значительных сложностей с настройкой сети, не добавляет туннелей и т.п. — всё остается прозрачным и может настраиваться автоматически простыми скриптами.
          • 0
            К VPN технологии отродясь не предъявлялось тех базовых требований к защите данных. Или будете говорить, что MPLS VPN не VPN? Главное и единственное требование, чтобы считаться VPN — эмуляция выделенного канала по ни разу не выделенной инфраструктуре. Да-да, GRE и даже 802.1q — тоже VPN. Ну и любой вид VPN запросто можно назвать туннелем.

            Для DMVPN IPSec является лишь необязательным дополнением. Можно запросто работать и без него.

            Далее. mGRE — это тот же GRE, но с маленькими отличиями на уровне control plane (адрес получателя пакета не фиксированный, определяется динамически). Обычно для той задачи (определение адреса терминации туннеля по адресу внутри туннеля) используют NHRP.

            Без IGP DMVPN поднимается и работает. Формально, наличие IGP настолько же необязательное, как и наличие IPSec защиты. Вот только неудобно без него будет, мягко говоря.
            • 0
              Главное и единственное требование, чтобы считаться VPN — эмуляция выделенного канала по ни разу не выделенной инфраструктуре.


              Голый IPSEC в транспортном режиме эмулирует выделенный канал? Может ли он считаться VPN? Согласен, с терминологией относительно VPN нужно быть предельно осторожным.
              • 0
                Голый IPSEC в транспортном режиме эмулирует выделенный канал?

                Трафик идет по общей инфре? Да. Есть изолированная труба? Да. Нюансы того, какие инкапсуляции добавляются к трафику и как он заворачивается в трубу, кого-то интересуют? Нет.
                • 0
                  Если под трубой понимать тунель, то в транспортном режиме IPSec никакой трубы нет.
                  • 0
                    Труба есть. Идентифицируется по SPI. То, что нет инкапсулирующих L2/L3 заголовков, несущественно.
                    • 0
                      Следуя Вашей логике тогда udp/tcp — тоже труба, потому что есть порт.
                      • 0
                        Не сказал бы. IPSec криптографически изолирует трафик.

                        Впрочем, тут как с применением модели ISO/OSI к TCP/IP. Многовато условностей, возможны разные мнения.
  • 0
    Очень не хватает фразы «туннели на маршрутизаторах Cisco» в заголовке или в первом абзаце статьи.

    Другими словами: в статье хорошо описаны варианты туннелей, которые реализуются на оборудовании Cisco. Все прочие варианты даже не упомянуты, например, Ethernet over IP, OpenVPN,…
    Если говорить о преимуществах, многими любимый OpenVPN масштабируется ничуть не хуже IPSec.

    • 0
      многими любимый OpenVPN масштабируется ничуть не хуже IPSec.

      Верю. Потому что голый IPSec не масштабируется. Слишком трудоемкое у него сопровождение.

      Для DMVPN с хабами из линейки ASR1k цифры в несколько тысяч узлов на облако (с кучей сервисов вплоть до переключения трафика на резерв за пару секунд в случае появления небольших потерь пакетов, и с гигабитами трафика) вполне достижимы и легко сопровождаются (конфиги всего связанного с DMVPN могут быть в буквальном смысле под копирку, даже IP адреса можно не вводить => работа легко скриптуется). Если строить многоуровневые иерархии, то можно десятки тысяч узлов получить.

      По поводу EoIP — если он потребовался между площадками, то вы что-то делаете не так.
      • 0
        Опять подразумеваете Cisco :-D

        Конкретно EoIP на DD-WRT пришлось сделать в одном месте из-за ограниченности бюджета заказчика. (Ничего другое просто не влезало в маршрутизаторы-мыльницы с 2 Мб NVRAM.) Обычно же я предпочитаю OpenVPN и IPSec, в некоторых случаях PPTP.
        • 0
          Конкретно EoIP на DD-WRT пришлось сделать в одном месте из-за ограниченности бюджета заказчика. (Ничего другое просто не влезало в маршрутизаторы-мыльницы с 2 Мб NVRAM.)

          Вот я и говорю — «что-то делаете не так» :)
          Обычно же я предпочитаю OpenVPN и IPSec, в некоторых случаях PPTP.

          OpenVPN на нормальном оборудовании не поддерживается. Впрочем, для SOHO сгодится. Голый IPSec — кошмар в сопровождении (плавал с сотнями узлов, знаю). PPTP — просто кошмар со всех сторон, у него фактически нет безопасности, проще уж тогда GRE сделать.
          • 0
            У нас разные критерии нормальности :). Я работаю как раз в сегменте SOHO.
            Про «голый» IPSec никто и не говорит, он подходит для соединения двух, максимум трёх точек (дальше сложность становится неприемлимой). Однажды понадобилось соединить две площадки с резервированием — сделал на IPSec+BGP, пришлось потрахаться, чтобы заработали линки 2х2.

            IMHO, «ниша» PPTP — дистанционные пользователи с голым Windows, в том числе мобильные и/или за NAT.
            • 0
              Я работаю как раз в сегменте SOHO.

              Искренне соболезную :) Я больше привык к более серьезным инфраструктурам, мне сложно осознать проблемы SOHO. Вот например я прочитал ваше сообщение и вообще не понял, с чем там можно трахаться в процессе настройки двух линков между двумя площадками с относительно равномерной балансировкой трафика и резервированием — типовая задача, делов на 10 минут от силы.
              «ниша» PPTP — дистанционные пользователи с голым Windows, в том числе мобильные и/или за NAT.

              PPTP — сложный с сетевой точки зрения протокол, вовсе не обязательно заработающий нормально через NAT (зависит собственно от делающей NAT/PAT коробки). Почему не SSTP к примеру (TCP, пролезет в любую дырку), или не L2TP/IPSec (который тоже непрост, но куда более распространен)?

              Опять же, «PPTP» и «безопасность» — не слишком пересекающиеся понятия. Ну и приличных коробок, умеющих терминировать много сессий, нет.
      • 0
        голый IPSec не масштабируется. Слишком трудоемкое у него сопровождение.


        Это не совсем корректно. Вы говорите только об одном аспекте масштабируемости, причём не самом важном, так называемом административном оверхеде. Да, поддержка большого количества туннелей — это головная боль для администратора. Но чем в этом смысле IPSEC хуже, например, full-mesh mpls-TE, где на каждом устройстве может терминироваться тысячи туннелей? На IPSEC ничто чисто технически не мешает построить очень большую сеть, поэтому, всё же, основной ограничивающий фактор масштабируемости ipsec — это топология spoke-and-hub, которая тянет за собой большую нагрузку на хабы по трафику, и увеличение delay в случае телефонии или видео между spoke-сайтами. Развитие DMVPN подтверждает это, т.к. только первая фаза решала проблему административного оверхеда. Вторая и третья фаза направлена на решение более острой проблемы масштабирования — разгрузить хабы от трафика и уменьшить задержку путём ввода spoke-to-spoke туннелей. Кстати, в статье нет ничего про отличие второй и третьей фазы, хотя бы архитектурно. А раз мы говорим про масштабирование, это очень важно. Вторая фаза имела серьёзные проблемы с масштабированием, т.к. она требует использование daisy-chain. Вторая проблема — невозможность создавать spoke-to-spoke между роутерами, которые находятся в разных NBMA. Третья фаза очень эффектно решает эти ограничения.
        • +1
          Вы говорите только об одном аспекте масштабируемости, причём не самом важном, так называемом административном оверхеде.

          Не сказал бы. В небольших или средних сетях (где цифра узлов не более трехзначной) в другие аспекты упереться сложно. А этот напрямую влияет на стоимость сопровождения решения, как и на общую стабильность сети (зоопарк конфигураций — плохо, единая конфигурация на всех — хорошо)…
          Но чем в этом смысле IPSEC хуже, например, full-mesh mpls-TE, где на каждом устройстве может терминироваться тысячи туннелей?

          Ничем. TE еще более ужасен. И там реально рабочих альтернатив нет. Потому приходится всякие сторонние решения закупать для автоматизации сопровождения. Ручному сопровождению это не поддается.
          основной ограничивающий фактор масштабируемости ipsec — это топология spoke-and-hub, которая тянет за собой большую нагрузку на хабы по трафику, и увеличение delay в случае телефонии или видео между spoke-сайтами.

          А вот со spoke-to-spoke туннелями возникает ряд очень трудных вопросов, и нередко правильным ответом на них будет «запретить динамические туннели и пускать всё через хаб».

          К примеру: для голоса и видео фиксированная задержка в 100-200мс не страшна, а вот пара процентов потерь или джиттер в 50мс — почти фатальны. Если вы строите VPN инфраструктуру поверх интернета — у вас нет QoS для входящего в любой конкретный офис трафика. Вообще нет, ни в каком виде.

          Есть интересное решение — per-tunnel QoS. Вроде все здорово — спок сообщает хабу, какие политики к нему применять (шейпер и внутри него приоритезация), и из канала спока становится возможно выжать 100% емкости без проседаний приоритетного трафика. Но вдруг строится динамический туннель до другого спока — и вся схема летит к черту, PE у спока начинает получать трафик больше CIR (хаб ведь не знает, сколько трафика второй спок вдруг вздумает влить в третий в данный момент времени), и соответственно PE без разбора дропает этот трафик вместе с голосом и видео.

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

          Так что да, многие предпочитают вариации на тему phase 1 (не обязательно «tunnel destination», можно и phase 2-3, но со сломанными динамическими туннелями). Которая все-таки вполне нормально масштабируется. Масштабирование ведь зависит от двух вещей:
          1) Data plane. Емкость каналов + возможности железа, первое решается не слишком дорого, если говорим про небольшое число каналов, а для второго есть ASR1k, для которых гигабиты трафика со всеми сервисами — не нагрузка.
          2) Control plane. Например, отсутствие суммаризации как в полноценном phase 2 — сильный ограничивающий фактор в связи с экспоненциальным ростом нагрузки на всех при добавлении новых узлов (так как в сети на тысячи узлов постоянно что-то происходит, слабенькие споки рано или поздно просто захлебнутся от апдейтов, если станут обмениваться маршрутной информацией), ну а если споки не знают друг друга — вопрос только к хабу, и у того же ASR1k хватит ресурсов RP для работы с тысячами споков разом в таком сценарии. Даже после рестарта он сумеет поднять все соседства разом за несколько десятков секунд, без всяких нестабильностей в процессе этого дела, без повторных ребутов из-за диких перегрузок.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.