Cisco. DMVPN + OSPF + IPSec

Входные данные

Предположим, что имеется Центральный офис, Филиал А, Филиал Б.

ХАБ DMVPN будем поднимать в ЦО.

ЦО

Внутренняя сеть: 192.168.250.0/24

Адрес внутреннего интерфейса (направленного в локальную сеть): 192.168.250.8

Внешний интерфейс: 172.16.250.1/24 - FastEthernet 6/0

Шлюз провайдера: 172.16.250.8

IP-адрес интерфейса VPN-туннеля: 10.10.254.1/24

Филиал А

Внутренняя сеть: 192.168.17.0/24

Адрес внутреннего интерфейса (направленного в локальную сеть): 192.168.17.8

Внешний интерфейс: 172.16.17.1/24 - FastEthernet 6/0

Шлюз провайдера: 172.16.17.8

IP-адрес интерфейса VPN-туннеля: 10.10.254.17/24

Филиал Б

Внутренняя сеть: 192.168.19.0/24

Адрес внутреннего интерфейса (направленного в локальную сеть): 192.168.19.8

Внешний интерфейс: 172.16.19.1/24 - FastEthernet 6/0

Шлюз провайдера: 172.16.19.8

IP-адрес интерфейса VPN-туннеля: 10.10.254.19/24

Настройка тоннелей

Настройка ЦО (HUB)

crypto isakmp keepalive 10 10

interface Tunnel 0

Внутренний IP-адрес VPN-сервера из нужного диапазона нашей будущей VPN

ip address 10.10.254.1 255.255.255.0

Динамическое изучение данных NHRP от клиентов. Поскольку клиентов у нас множество и они могут быть с динамическими адресами, на хабе нельзя задать явное соответствие внутренних и внешних адресов.

ip nhrp map multicast dynamic

Определяем Network ID – просто идентификатор, который необязательно должен быть одинаковым на всех узлах DMVPN

ip nhrp network-id 1

Привязка к физическому внешнему интерфейсу

tunnel source FastEthernet 6/0

Туннель на центральном узле будет терминировать все туннели от удалённых точек.

То есть он будет точка-многоточка (Point-to-MultiPoint)

tunnel mode gre multipoint

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

Если маршрут достижим через определенный интерфейс, то в обновление, которое отправляется через этот интерфейс не включается этот маршрут

no ip split-horizon

Без этих настроек после перезагрузки хаба тоннели в филиалах поднимутся, но будут недоступны для пингов

ip nhrp registration timeout 30

ip nhrp holdtime 300

Настройка Филиала А (SPOKE A)

crypto isakmp keepalive 10 10

interface Tunnel 0

Внутренний IP-адрес VPN-клиента из нужного диапазона нашей будущей VPN

ip address 10.10.254.17 255.255.255.0

Статическое соотношение внутреннего и внешнего адресов центрального хаба (ЦО)

ip nhrp map 10.10.254.1 172.16.250.1

Мультикастовый трафик должен получать хаб по внешнему IP-адресу ЦО

ip nhrp map multicast 172.16.250.1

Network ID. Не обязательно должен совпадать с таким же на хабе

ip nhrp network-id 1

Статически настроенный внутренний VPN адрес NHRP сервера – хаба

Именно поэтому в центре нам нужен статический публичный адрес

Клиенты отправляют запрос на регистрацию на хаб 10.10.254.1, этот запрос содержит настроенный локальный адрес туннельного интерфейса, а также свой публичный адрес

ip nhrp nhs 10.10.254.1

Если адрес в филиалах выдаётся динамически, эта команда обязательна

ip nhrp registration no-unique

Привязка к физическому внешнему интерфейсу

tunnel source FastEthernet 6/0

Указываем, что тип туннеля mGRE – это позволит создавать динамически туннели не только до хаба, но и до других филиалов

tunnel mode gre multipoint

Без этих настроек после перезагрузки хаба тоннели в филиалах поднимутся, но будут недоступны для пингов

ip nhrp registration timeout 30

ip nhrp holdtime 300

Настройка Филиала Б (SPOKE B)

crypto isakmp keepalive 10 10

interface Tunnel 0

Внутренний IP-адрес VPN-клиента из нужного диапазона нашей будущей VPN

ip address 10.10.254.19 255.255.255.0

Статическое соотношение внутреннего и внешнего адресов центрального хаба (ЦО)

ip nhrp map 10.10.254.1 172.16.250.1

Мультикастовый трафик должен получать хаб по внешнему IP-адресу

ip nhrp map multicast 172.16.250.1

Network ID. Не обязательно должен совпадать с таким же на хабе

ip nhrp network-id 1

Статически настроенный внутренний VPN адрес NHRP сервера – хаба

Именно поэтому в центре нам нужен статический публичный адрес

Клиенты отправляют запрос на регистрацию на хаб 10.10.254.1, этот запрос содержит настроенный локальный адрес туннельного интерфейса, а также свой публичный адрес

ip nhrp nhs 10.10.254.1

Если адрес в филиалах выдаётся динамически, эта команда обязательна

ip nhrp registration no-unique

Привязка к физическому внешнему интерфейсу

tunnel source FastEthernet 6/0

Указываем, что тип туннеля mGRE – это позволит создавать динамически туннели не только до хаба, но и до других филиалов

tunnel mode gre multipoint

Без этих настроек после перезагрузки хаба тоннели в филиалах поднимутся, но будут недоступны для пингов

ip nhrp registration timeout 30

ip nhrp holdtime 300

Проверка

tmb# ping 10.10.254.1

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 172.16.254.1, timeout is 2 seconds:
    !!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 176/213/284 ms

tmb# ping 10.10.254.19

    Type escape sequence to abort.
    Sending 5, 100-byte ICMP Echos to 172.16.254.19, timeout is 2 seconds:
    !!!
    Success rate is 100 percent (5/5), round-trip min/avg/max = 176/213/284 ms

sh int tun 0

sh ip nhrp brief

Тоннели подняты!

Идем дальше

Динамическая маршрутизация OSPF

Настройка ЦО

interface loopback 0

ip address 10.0.0.250 255.255.255.255

exit

interface Tunnel 0

Поскольку мы имеем широковещательную L2 сеть на туннельных интерфейсах, указываем явно тип сети Broadcast на туннельных интерфейсах на всех узлах

ip ospf network broadcast

Кроме того в такой сети должен выбираться DR. Логично, чтобы им стал хаб. Хабу ставим ip ospf priority 10. Всем остальным Spoke-маршрутизаторам запрещаем участие в выборах DR - ставим ip ospf priority 0:

ip ospf priority 10

exit

(config)# router ospf 1

1 это номер процесса, непринципиален

Номер процесса OSFP на разных маршрутизаторах не обязательно должен быть одинаковым, но лучше, если это будет так

(config)# router-id 10.0.0.250

(config)# log-adjacency-changes

Логирование изменений

Анонсируем сеть VPN

network 10.10.254.0 0.0.0.255 area 0

Анонсируем сумму локальных сетей цо и филиалов за маршрутизаторами

network 192.168.0.0 0.0.255.255 area 0

Настройка Филиала А (Остальные филиалы настраиваются аналогично)

interface loopback 0

ip address 10.0.0.17 255.255.255.255

exit

interface Tunnel 0

Поскольку мы имеем широковещательную L2 сеть на туннельных интерфейсах, указываем явно тип сети Broadcast на туннельных интерфейсах на всех узлах

ip ospf network broadcast

Кроме того в такой сети должен выбираться DR. Логично, чтобы им стал хаб. Всем остальным Spoke-маршрутизаторам запрещаем участие в выборах DR - ставим ip ospf priority 0:

ip ospf priority 0

exit

(config)# router ospf 1

1 это номер процесса, непринципиален

Номер процесса OSFP на разных маршрутизаторах не обязательно должен быть одинаковым, но лучше, если это будет так

(config)# router-id 10.0.0.17

(config)# log-adjacency-changes

Логирование изменений

Анонсируем сеть VPN

network 10.10.254.0 0.0.0.255 area 0

Анонсируем сумму локальных сетей цо и филиалов за маршрутизаторами

network 192.168.0.0 0.0.255.255 area 0

Проверка

Должны увидеть маршруты OSPF до 192.168.250.0/24 и 192.168.19.0/24

tmb# sh ip route

tmb# ping 192.168.19.36

tmb# ping 192.168.250.36

Тут важно понимать, что несмотря на то, что общение между филиалами осуществляется в обход центрального узла, хаб однако несёт тут жизненно важную вспомогательную функцию и без него ничего работать не будет: он предоставляет клиентам таблицу NHRP, а также анонсирует все маршруты – филиалы распространяют маршрутную информацию не непосредственно друг другу, а через хаб.

На данный момент решены следующие проблемы:

1) Связность. Филиалы подключены и доступны.

2) Маршрутизация. Через mGRE туннели успешно запущены IGP.

3) Масштабируемость. При добавлении нового spoke-маршрутизатора настраивается только он сам и нет необходимости лезть в конфигурацию уже существующих узлов.

4) Разгрузили хаб – через него передаётся только служебный трафик.

Осталось уладить вопрос с безопасностью.

Шифрование IPSec

Настройка (на всех узлах одинаковая)

Если для Site-to-Site VPN мы ещё могли использовать pre-shared key, потому что мы жёстко задавали адрес IPSec-пира, то в случае DMVPN нам нужна гибкость, а заранее мы не знаем адреса соседей.

В связи с этим рекомендуется использование сертификатов.

Но мы для упрощения возьмём всё же настройку с pre-shared ключом.

!Опасность здесь в том, что установить IPSec-сессию с хабом, зная ключ, может любое устройство!

crypto isakmp policy 1

authentication pre-share

От Tunnel Protection и VTI настройка будет отличаться использованием шаблонного адреса:

crypto isakmp key 6 PASSWORD address 0.0.0.0 0.0.0.0

Тут можно спокойно использовать транспортный режим:

crypto ipsec transform-set AES128-SHA esp-aes esp-sha-hmac

mode transport

Создаем профиль с именем DMVPN-P

crypto ipsec profile DMVPN-P

Применяем ранее настроенный тип шифрования с именем AES128-SHA

set transform-set AES128-SHA

Далее созданный профиль применяется на туннельный интерфейс. Настройка на всех узлах одинаковая.

interface Tunnel0

tunnel protection ipsec profile DMVPN-P

Проверка

На выводе сразу после настройки будут вот такие сообщения:

*Mar  1 00:11:18.223: %CRYPTO-6-ISAKMP_ON_OFF: ISAKMP is ON
*Mar  1 00:11:23.131: %OSPF-5-ADJCHG: Process 1, Nbr 192.168.250.8 on Tunnel0 from LOADING to FULL, Loading Done

Должны увидеть маршруты OSPF до 192.168.250.0/24 и 192.168.19.0/24

tmb# sh ip route

Должны пинговаться узлы из локальной сети за маршрутизаторами

tmb# ping 192.168.19.36

tmb# ping 192.168.250.36

TroubleShoot IPSec

Напоследок хочется сказать пару слов о том, как решать проблемы с IPSec. Процедура-то далеко не тривиальная.

При траблшутинге VPN огромную роль играют дебаги. Метод пристального взгляда на конфиг менее надежен – легко пропустить небольшую ошибку.

Исключительно ценным инструментом в траблшутинге IPSec является sh crypto ipsec sa. Нет, дело даже не в бинарном «поднялось — не поднялось», а в счетчиках, в первую очередь encaps-decaps. Можно пустить непрерывный пинг и наблюдать, какой из счетчиков растет. Большинство проблем удается локализовать именно таким образом.

Счетчики вообще не растут? См. куда применен крипто мап и все ли в порядке с ACL.

Растут error? Что-то не так с согласованием, см. дебаг.

Растут encaps, но нет decaps? Вперед изучать противоположную сторону туннеля, тут все хорошо.