Стартовая конфигурация оборудования в центральном офисе
В качестве примера инфраструктуры центрального офиса рассмотрим топологию из дизайн-документа «Построение сети большого офиса». В рамках данного дизайн-документа была организована работа офисной сети с выходом локальных пользователей в Интернет через одного из двух доступных интернет-провайдеров. Также на схеме можно заметить сегмент демилитаризованной зоны для размещения сервисов с возможностью их публикации в сети Интернет с использованием технологии Destination или Static NAT.
Рисунок 2. Схема сети центрального офиса из дизайн-документа «Построение сети большого офиса»
Конфигурации оборудования в данной схеме представлены ниже:
Перед базовой конфигурацией коммутаторов уровня агрегации (в рассматриваемой схеме) необходимо настроить стекирование.
После конфигурации cтековых настроек устройства необходимо перезагрузить, чтобы настройки применились. Перезагрузку лучше начать с юнита 1.
Перед базовой конфигурацией коммутаторов DMZ-семента (в рассматриваемой схеме) необходимо настроить стекирование.
После конфигурации cтековых настроек устройства необходимо перезагрузить, чтобы настройки применились. Перезагрузку лучше начать с юнита 1.
Размещение DMVPN Hub в демилитаризованном сегменте сети центрального офиса
Маршрутизаторы, выполняющие роль DMVPN Hub, разместим в DMZ-сегменте сети центрального офиса. Они будут заниматься терминацией IPsec и GRE-туннелей от удаленных DMVPN Spoke и маршрутизировать трафик на интернет-шлюзы центрального офиса.
Разграничение функции DMVPN Hub и корпоративного интернет-шлюза на разные маршрутизаторы рекомендовано с связи с повышенной нагрузкой на плоскость управления маршрутизатора, терминирующего на себе множество DMVPN-туннелей.
Таким образом, схема размещения DMVPN Hub в центральном офисе будет выглядеть так:
Рисунок 3. Размещение DMVPN Hub в демилитаризованном сегменте сети центрального офиса
Оба DMVPN Hub подключим к стеку коммутаторов DMZ-сегмента сети, используя технологию агрегации каналов LAG с включенной поддержкой протокола LACP. За счет того, что коммутаторы DMZ-сегмента собраны в стек, LAG, поднятый до разных коммутаторов, будет восприниматься маршрутизатором ESR как единый агрегированный канал.
Для начала зададим маршрутизаторам DMVPN Hub имена:
Настроим агрегированные интерфейсы на стороне DMVPN Hub:
И аналогично настроим агрегированные интерфейсы в стеке коммутаторов DMZ-сегмента сети:
Организация выхода DMVPN Hub в сети провайдеров центрального офиса с использованием Static NAT
DMVPN Hub должны быть доступны для подключения через сеть Интернет для DMVPN Spoke, то есть они либо должны функционировать на публичных адресах, предоставляемых интернет-провайдером, либо доступ им в публичную сеть должен предоставить интернет-шлюз при помощи Static NAT. Именно второй вариант будет рассмотрен в данном руководстве.
Для организации выхода DMVPN Hub в Интернет организуем сетевую связность между DMVPN Hub и интернет-шлюзами центрального офиса. Для этого через уже построенный L2-сегмент протянем VLAN для каждого интернет-провайдера, а на интернет-шлюзах и DMVPN Hub добавим саб-интерфейсы на агрегированных каналах в сторону коммутаторов ядра и DMZ соответственно. При настройке будем использовать параметры сети, представленные в таблице 3.
Таблица 3. Параметры локальных сетей, используемых для выхода DMVPN Hub в публичные сети интернет-провайдеров центрального офиса
| Интернет-провайдер | VLAN | Подсеть |
|---|---|---|
| ISP-1 | 210 | 10.0.0.0/30 |
| ISP-2 | 220 | 10.0.0.8/30 |
Для начала добавим VLAN подсети до каждого из провайдеров на коммутаторы ядра и DMZ-сегмента:
Создадим саб-интерфейсы на агрегированных каналах интернет-шлюзов, поднятых в сторону коммутаторов ядра:
Аналогично поступим на стороне DMVPN Hub, но создаваемый саб-интерфейс вынесем в отдельный VRF.
Схема подключения, в которой транспортная сеть для некой виртуальной сети выносится в отдельное сетевое пространство имен называется Front-Door VRF. Такая схема организации транспорта для виртуальной сети дает следующие преимущества:
- возможность использования маршрута по умолчанию как в виртуальной сети, так и в транспортной сети;
- отсутствие пересечения маршрутной информации между транспортной и виртуальной сетью;
- дополнительный уровень безопасности виртуальной сети, поскольку трафик из неё не может попасть в транспортную сеть без настроенной инкапсуляции в туннель.
Создадим для данных сетей отдельную зону безопасности на интернет-шлюзах и DMVPN Hub и добавим в неё созданные раннее саб-интерфейсы агрегированных каналов. Разрешим входящий с точки зрения маршрутизаторов трафик протокола ICMP из этой зоны безопасности:
Добавим в существующий профиль IP-адресов, который используется для функционала ARP Proxy на интернет-шлюзах, еще один публичный адрес из пула, выданного нам каждым провайдером:
Добавим новый профиль IP-адресов, в котором укажем адрес DMVPN Hub в локальной сети центрального офиса.
Сконфигурируем правило Static NAT в уже имеющемся наборе правил Source NAT:
И разрешим прохождение транзитного ICMP-трафика из глобальной сети до DMVPN Hub и наоборот:
Подключение DMVPN Hub в локальную сеть центрального офиса
Для маршрутизации трафика между интернет-шлюзами центрального офиса и DMVPN Hub добавим отдельную подсеть, параметры которой описаны в таблице 4.
Таблица 4. Параметры локальной сети, используемой для выхода DMVPN Hub в локальную сеть центрального офиса
| Назначение | VLAN | Подсеть |
|---|---|---|
| Подсеть для IP-связности DMVPN Hub и интернет-шлюзов | 300 | 10.0.0.16/29 |
Добавим VLAN создаваемой сети на коммутаторы ядра и DMZ-сегмента:
Создадим соответствующие саб-интерфейсы на агрегированных каналах:
Создадим для данных сетей отдельную зону безопасности на интернет-шлюзах и DMVPN Hub и добавим в неё созданные раннее саб-интерфейсы агрегированных каналов. Разрешим входящий с точки зрения маршрутизаторов трафик протокола ICMP из этой зоны безопасности:
Настройка IKEv2 и IPsec-туннелирования на DMVPN Hub
Настройка IPsec для будущего облака DMVPN является важной частью данного руководства. Корректная настройка IPsec гарантирует приватность и защищенность трафика между офисами. При дальнейшей настройке будем использовать параметры IKE и IPsec, представленные в таблице 5.
Таблица 5. Параметры IKE и IPsec, используемые для настройки туннелирования IPsec на маршрутизаторах DMVPN Hub
| RT-HUB-1 | RT-HUB-2 | ||
|---|---|---|---|
| Параметры IKE | Алгоритм шифрования | AES-256 | AES-256 |
| Алгоритм хеширования | SHA2-256 | SHA2-256 | |
| Группа Диффи-Хеллмана | 19 | 19 | |
| Время жизни IKE-сеcсии в секундах | 86400 | 86400 | |
| Идентификатор IKE-сессии | hub1.company.loc | hub2.company.loc | |
| Интервал отправки DPD-сообщений | 40 | 40 | |
| Общий таймаут ожидания ответа на DPD-сообщение | 160 | 160 | |
| Действие при наступлении таймаута DPD | Закрытие сессии IKE | Закрытие сессии IKE | |
| Параметры IPsec | Алгоритм шифрования | AES-256 | AES-256 |
| Алгоритм хеширования | SHA2-256 | SHA2-256 | |
| Группа Диффи-Хеллмана для механизма PFS | 19 | 19 | |
| Время жизни IPsec-сесcии в секундах | 28800 | 28800 | |
| Время жизни IPsec-сесcии в килобайтах | 4608000 | 4608000 | |
| Интервал ранней реаутентификации IKE-сессии/Интервал раннего рекеинга IPsec-сессии в секундах | 3600 | 3600 | |
| Пороговое значение ранней реаутентификации IKE-сессии/Пороговое значение раннего рекеинга IPsec-сессии в килобайтах | 86400 | 86400 | |
Начинается настройка IPsec с настройки наборов криптографических алгоритмов для протокола IKE:
Затем создадим набор ключей аутентификации IKE. Поскольку в дальнейшей настройке планируется использовать в качестве идентификатора IPsec-соседа доменные имена, в наборе ключей тоже используем доменные имена:
Создадим политику IKE. Она включает в себя наборы алгоритмов шифрования, выбор метода аутентификации и время жизни IKE-сессии:
Создадим криптошлюз IKE.
- Для использования протокола IKE версии 2 обязательна команда «version v2-only», в противном случае туннель будет использовать протокол IKE версии 1.
- Поддержку протокола MOBIKE необходимо отключать, в схеме DMVPN он может привести к ошибкам построения туннелей между DMVPN Hub и DMVPN Spoke.
- В случае привязки криптошлюза к интерфейсу командой «local interface» привязать локальную сеть к адресу на этом интерфейсе можно командой «local network dynamic».
- В схеме DMVPN в туннели IPsec помещается только GRE-трафик, поэтому корректным будет указывать ключ «protocol gre» в командах «local network» и «remote network».
Настроим политику в отношении дубликатов IKE-сессий — при возникновении дубликатов будем замещать существующие IKE-сессии:
Создадим набор криптографифеских алгоритмов уже непосредственно для туннеля IPsec:
Затем создадим политику IPsec. Она включает в себя наборы алгоритмов шифрования и время жизни IPsec-сессии, непосредственно отвечающей за шифрование пользовательского трафика. В отличие от IKE-сессии, время жизни IPsec-сессии можно задавать как в секундах, так и в объеме пользовательского трафика, прошедшего через туннель. Зададим оба варианта:
Наконец все собранные настройки IKE и IPsec можно объединить в один общий VPN-профиль. Для IPsec VPN-профилей, использующихся на туннелях GRE в схеме DMVPN, обязательно включение транспортного режима:
Разрешим прохождение трафика, связанного с IPsec-туннелями, через сеть центрального офиса. Для этого сначала опишем профили портов для протокола IKE и упакованного в UDP шифрованного трафика протоколов IKE и ESP:
На интернет-шлюзах разрешим прохождение трафика IPsec-туннелей транзитом от интерфейсов в сторону нтернет-провайдеров в сторону DMVPN Hub:
В свою очередь на DMVPN Hub разрешим этот же трафик, но уже как входящий:
Настройка mGRE-туннелей на DMVPN Hub
Настроим туннели GRE в многоточечном режиме с поддержкой протокола NHRP на DMVPN Hub. Основные параметры туннелей GRE для обоих DMVPN Hub представлены в таблице 6.
Таблица 6. Параметры туннелей GRE на маршрутизаторах DMVPN Hub
| Hostname | DMVPN Cloud | Номер туннеля GRE | Туннельная адресация | Ключ туннеля GRE | Время жизни NHRP-записей, секунды |
|---|---|---|---|---|---|
| RT-HUB-1 | ISP-1 Cloud | 10 | 172.16.1.1/24 | 1000 | 600 |
| RT-HUB-2 | ISP-2 Cloud | 10 | 172.16.2.1/24 | 2000 | 600 |
Сначала настроим общие настройки туннеля GRE на каждом из DMVPN Hub. К таким настройкам относятся:
- режим работы multipoint;
- значение key;
- значение TTL;
- размер MTU;
- значение TCP adjust-mss;
- туннельный IP-адрес;
- интерфейс, с которого будет строиться GRE-туннель;
- имя транспортного VRF.
Маршрутизаторы DMVPN Hub с точки зрения протокола NHRP выполняют роль NHRP серверов, регистрирующих новых членов облака DMVPN и сообщающих о доступности члена облака DMVPN через его внешний NBMA адрес. В связи с этим большая часть настроек протокола NHRP будет связана с входящими на DMVPN Hub обращениями.
Для корректного построения Spoke-to-Spoke-туннелей, маршрутизация на которых весь трафик заводит на DMVPN Hub, включим опцию «ip nhrp redirect», которая включит на DMVPN Hub отслеживание неоптимального прохождения трафика между DMVPN Spoke и отправку специального сообщения протокола NHRP «Traffic Indication» тому DMVPN Spoke, чей трафик мог бы идти другому DMVPN Spoke напрямую, минуя DMVPN Hub.
Такая схема организации маршрутизации и построения Spoke-to-Spoke-туннелей в облаках DMVPN общепринято именуется третьей фазой DMVPN.
Из-за особенностей декапсуляции трафика из IPsec-туннелей, работающих в транспортном режиме инкапсуляции, трафик после дешифровки попадает на тот же сетевой интерфейс, который терминирует IPsec-туннель. В связи с этим в правилах межсетевого экранирования на DMVPN Hub необходимо разрешить прием не только шифрованных IPsec-пакетов, но и GRE-пакетов, которые попадают на интерфейс после дешифрования.
Для фильтрации трафика внутри облака DMVPN создадим отдельную зону безопасности и назначим её на GRE-туннель. Разрешим прохождение входящего ICMP-трафика в этой зоне:
Конфигурирование маршрутизации для функционирования облака DMVPN в центральном офисе
В качестве протокола динамической маршрутизации для схемы DMVPN используем BGP. Его возможности обеспечат в текущей схеме весь необходимый функционал, малый размер конфигурации, а в сочетании с протоколом BFD — быстрое определение нарушения связности между BGP-соседями и оперативное перестроение сетевой топологии.
Схема членства настраиваемых маршрутизаторов в автономных системах представлена на рисунке 4:
Рисунок 4. Логическая схема членства маршрутизаторов в автономных системах
Настройку начнем с DMVPN Hub, для входящих BGP-соединений от DMVPN Spoke настроим динамических BGP-соседей. При этом отдавать в сторону DMVPN Spoke мы будем только маршрут по умолчанию, так весь трафик облаков DMVPN будет проходить через Hub:
В связи с тем, что DMVPN Spoke и DMVPN Hub находятся в разных автономных системах, анонсирование маршрутной информации по умолчанию проводиться не будет. Создадим route-map, разрешающий отправку маршрута по умолчанию на DMVPN Spoke.
Для того чтобы выделить роль RT-HUB-1 как основного DMVPN Hub для обработки трафика в облаке DMVPN, в его route-map увеличим значение метрики протокола BGP. Таким образом, для DMVPN Spoke маршрут по умолчанию в его сторону будет более приоритетным.
Созданный route-map указываем для семейства IPv4-маршрутов в существующей peer-group:
Включим поддержку BFD для созданных BGP-соседств. Учтем скорость сходимости IPsec и mGRE-туннелей и увеличим BFD-таймеры:
Разрешим прохождение входящего трафика протокола BGP и BFD в зоне безопасности, настроенной на туннелях GRE:
В сторону интернет-шлюзов центрального офиса также настроим BGP-соседей, только статических. Поскольку настройки подключения к обоим интернет-шлюзам одинаковы, настроим peer-group и уже её укажем в конфигурации статичных BGP-соседей:
Создадим route-map, разрешающий анонсы маршрутной информации в сторону интернет-шлюзов, метрики BGP установим те же, что и для DMVPN Spoke:
Добавим в анонсируемые маршруты туннельные подсети облака DMVPN. За счет указанных route-map информация о туннельных маршрутах поступит только на интернет-шлюзы.
Для статичных BGP-соседей также включим поддержку протокола BFD:
Разрешим прохождение входящего трафика протокола BGP и BFD в зоне безопасности, настроенной на саб-интерфейсах агрегированных каналов в сторону интернет-шлюзов:
Теперь настроим BGP-соседей в сторону DMVPN Hub на стороне интернет-шлюзов. В связи с шаблонностью настроек в сторону DMVPN Hub также воспользуемся peer-group. В сторону DMVPN Hub включим анонс маршрута по умолчанию, поскольку трафик, выходящий за пределы облака DMVPN должен маршрутизироваться на интернет-шлюзах центрального офиса:
Создадим route-map, разрешающий анонсы маршрутной информации в сторону интернет-шлюзов.
Отдельное внимание стоит уделить настройкам метрик BGP-маршрутов. Поскольку выход в глобальную сеть Интернет у каждого из интернет-шлюзов осуществляется через своего интернет-провайдера, маршрут по умолчанию, анонсируемый в сторону DMVPN Hub, должен быть более приоритетным у того интернет-шлюза, у которого сейчас есть выход в сеть Интернет. Поскольку в конфигурации интернет-шлюза RT-GW-1 уже есть настроенный объект отслеживания, благодаря которому переключается VRRP-мастерство для пользователей в локальной сети центрального офиса, этот же объект отслеживания будем использовать в route-map для изменения метрики BGP-маршрута по умолчанию, который RT-GW-1 анонсирует в сторону DMVPN Hub.
Включим поддержку протокола BFD, аналогично настройкам DMVPN Hub увеличим таймеры BFD:
Разрешим прохождение входящего трафика протокола BGP и BFD в зоне безопасности, настроенной на саб-интерфейсах агрегированных каналов в сторону DMVPN Hub:
Настройка Zone-Based Firewall и Source NAT для пользователей удаленных офисов
Поскольку теперь построенное облако DMVPN обеспечивает выход трафика пользователей удаленных офисов через интернет-шлюз центрального офиса, необходимо произвести дополнительные настройки Firewall и NAT.
Начнем с разрешения транзитного трафика из облака DMVPN в сторону интернет-шлюзов центрального офиса:
Теперь разрешим прохождение трафика из облака DMVPN до локальных пользователей центрального офиса. Для этого создадим профиль IP-адресов, в который будем указывать адреса подсетей удаленных офисов:
И для этого профиля разрешим доступ к пользователям локальной сети:
Также разрешим трафику из облака DMVPN выход в Интернет:
Также добавим для трафика из облака DMVPN Source NAT. Производить Source NAT будем в уже созданный NAT pool для пользователей центрального офиса:
На этом настройку DMVPN в центральном офисе можно считать завершенной.


