Введение
Сетевая инфраструктура предприятий и организаций неизбежно растет и покидает пределы одного здания, развиваясь в различных территориально распределенных филиалах. Обеспечение стабильного и безопасного канала связи между офисами компании является рядовой задачей сетевого инженера.
Приведенная схема представляет решение по организации защищенных каналов связи между центральным и дочерними филиалами компании, обеспечивающее помимо безопасности удобство администрирования и масштабирования.
Примечания и предупреждения
Подсказки содержат небольшие пояснения, помогающие быстрее освоить работу с оборудованием, или дополнительную информацию.
Примечания содержат важную информацию о настройке оборудования.
Предупреждения информируют пользователя о ситуациях, которые могут нанести вред, привести к некорректной работе системы или потере данных.
Глоссарий
- AES (Advanced Encryption Standard) — симметричный алгоритм блочного шифрования.
- ARP (Address Resolution Protocol) — протокол, используемый для сопоставления адресов сетевого уровня адресам канального уровня в сетях множественного доступа.
- ARP Proxy — механизм использования протокола ARP, при котором хост отвечает на ARP-запросы для IP-адреса, не назначенного на его сетевой интерфейс.
- BFD (Bidirectional Forwarding Detection) — протокол, предназначенный для быстрого детектирования связности между двумя маршрутизаторами.
- BGP (Border Gateway Protocol) — протокол маршрутизации, используемый для обмена информацией о маршрутах между автономными системами.
- DHCP (Dynamic Host Configuration Protocol) — протокол динамической настройки сетевого узла.
- DMVPN (Dynamic Multipoint Virtual Private Network) — технология развертывания виртуальных частных сетей в схеме «точка-многоточка».
- DMVPN Hub — роль устройства в облаке DMVPN, центральное устройство в схеме «точка-многоточка», обладающее информацией о всех членах облака DMVPN и позволяющее перенаправлять трафик, а также связывать напрямую временными туннелями любого члена облака DMVPN.
- DMVPN Spoke — роль устройства в облаке DMVPN, после подключения к DMVPN Hub позволяет через него перенаправить трафик другим DMVPN Spoke, а также установить временный туннель до другого DMVPN Spoke.
- DMZ (Demilitarized Zone) — сегмент сети, содержащий в себе публично доступные корпоративные сервисы.
- DPD (Dead Peer Detection) — механизм обнаружения неактивного соседа в контексте IPsec-туннелирования.
- ESP (Encapsulating Security Payload) — протокол, используемый в технологии IPsec для обеспечения конфиденциальности передаваемых данных, путем шифрования содержимого передаваемого IP-пакета.
- FIB (Forwarding Information Base) — оптимизированная таблица маршрутизации, используемая для пересылки IP-пакетов.
- Front-Door VRF — схема подключения, в которой транспортная сеть для некой виртуальной сети выносится в отдельное сетевое пространство имен.
- GRE (Generic Routing Encapsulation) — протокол туннелирования IP-пакетов.
- ICMP (Internet Control Message Protocol) — протокол передачи сообщений об ошибках и управляющей информации в сетях TCP/IP.
- IKE (Internet Key Exchange) — протокол управления ключами, используемый для создания и обслуживания IPsec-туннелей.
- IMIX (Internet mix) — шаблон типового трафика сети Интернет, проходящий через сетевое оборудование. Термин используется при описании результатов нагрузочного тестирования сетевого оборудования.
- IPsec (IP security) — технология, реализующая через набор протоколов возможность обеспечения конфиденциальности, целостности и доступности данных, отправляемых по сетям общего пользования.
- LACP (Link Aggregation Control Protocol) — стандартный протокол агрегирования каналов.
- LAG (Link Aggregation Group) — группа агрегированных каналов.
- MD5 (Message Digest 5) — 128-битный алгоритм хеширования.
- MOBIKE — расширение протокола IKE версии 2, позволяющее использовать установленный IPsec-туннель в случае смены IP-адресации у одной из сторон IPsec-туннеля.
- MTU (Maximum Transmission Unit) — максимальный размер пакета данных, который может быть передан по сети без фрагментации.
- NAT (Network Address Translation) — механизм в сетях TCP/IP, позволяющий изменять поля в заголовке пакета, проходящего через маршрутизатор. В данном руководстве упоминаются: Source NAT — преобразование в заголовках пересылаемых IP-пакетов данных об отправителе пакета; Destination NAT — преобразование в заголовках пересылаемых IP-пакетов данных о получателе пакета; и Static NAT — преобразование одного IP-адреса в другой один к одному без изменения прочих заголовков.
- NAT-OA (NAT Original Address) — IP-адрес отправителя пакета до совершения Source-NAT преобразования, используется в протоколах.
- NBMA (Non-Broadcast Multiple Access network) — cеть, в которую подключено несколько устройств, данные между которыми передаются только напрямую с одного устройства на другое. Возможность отправки широковещательной рассылки, которую получат все устройства, при этом отсутствует.
- NHRP (Next Hop Resolution Protocol) — клиент-серверный протокол преобразования адресов, позволяющий всем хостам, которые находятся в NBMA-сети, динамически выучить NBMA-адреса (физические адреса) друг друга.
- PFS (Perfect forward secrecy) — механизм, который вызывает новый обмен ключами Диффи-Хеллмана каждый раз, когда переустанавливается дочерняя ассоциация безопасности IPsec-туннеля.
- PPPoE (Point-to-Point Protocol over Ethernet) — сетевой протокол канального уровня для передачи кадров протокола PPP через сети Ethernet, часто используемый интернет-провайдерами как механизм предоставления доступа абонентам в сеть Интернет.
- RIB (Routing Information Base) — таблица маршрутизации, содержащая в себе всю маршрутную информацию, получаемую из различных источников.
- SFP (Small Form-factor Pluggable) — промышленный стандарт модульных компактных приемопередатчиков (трансиверов), используемых для передачи и приема данных в телекоммуникационном оборудовании.
- SHA2 (Secure Hash Algorithm Version 2) — семейство криптографических алгоритмов, однонаправленных хеш-функций.
- SLA (Service Level Agreement) — технология измерения активных компьютерных сетей путем тестирования качественных и количественных характеристик каналов связи в сети передачи данных стека TCP/IP.
- TCP Adjust-MSS — механизм, позволяющий установить максимальный размер сегмента в TCP-сессии, чтобы предотвратить фрагментацию TCP-пакетов, передаваемых через канал связи с заниженным MTU.
- TTL (Time To Live) — максимальное количество маршрутизаторов, через которое IP-пакет может пройти, прежде чем он будет отброшен.
- VLAN (Virtual Local Area Network) — виртуальная локальная компьютерная сеть.
- VPN (Virtual Private Network) — технология, позволяющая создать безопасное, зашифрованное соединение между двумя хостами в сети.
- VRF (Virtual Routing and Forwarding) — технология, позволяющая разграничить на одном сетевом устройстве несколько пространств сетевых имен со своей адресацией и таблицей маршрутизации.
Постановка задачи
Цель документа
Целью данного документа является демонстрация построения защищенных каналов связи между центральным и дочерними офисами компании с использованием оборудования компании Eltex и практик использования этого оборудования.
Целевая аудитория
Данный документ будет полезен для инженеров, решающих задачи организации каналов связи между географически разнесенными офисами компаний.
Предлагаемая схема сети
Предлагаемое решение представляет построение оверлейной сети поверх сети интернет-провайдеров с использованием технологии DMVPN, реализованной на сервисных маршрутизаторах ESR.
Рисунок 1. Общая схема развертывания облаков DMVPN для обеспечения безопасного канала связи между офисами
Преимущества решения
Предлагаемое решение подразумевает ряд преимуществ. Технология IPsec реализует шифрование канала связи, что обеспечивает безопасную передачу данных между офисами. Использование GRE-туннелирования реализует поддержку multicast- и broadcast-трафика в каналах связи между филиалами, что позволяет использовать всю широту сетевых протоколов, работающих в корпоративных сетях. Протокол NHRP, лежащий в основе технологии DMVPN, позволит минимизировать конфигурацию на маршрутизаторах в головном офисе, а также строить временные туннели между дочерними офисами, что уменьшит нагрузку на маршрутизаторы в головном офисе и уменьшит задержки в канале связи при коммуникации между офисами.
Возможные продуктовые решения
Сервисные маршрутизаторы ESR в роли DMVPN Hub в центральном офисе
Маршрутизаторы, которые планируется использовать в качестве DMVPN Hub, должны иметь большой размер таблицы FIB, а также обеспечивать терминацию большого количества IPsec-туннелей. Рекомендуемые модели маршрутизаторов ESR на роль DMVPN Hub представлены в таблице 1.
Таблица 1. Рекомендованные модели маршрутизаторов ESR на роль DMVPN Hub
| Модель | Интерфейсы | Размер таблицы FIB | Производительность IPsec (IMIX) | Количество поддерживаемых DMVPN Spoke |
|---|---|---|---|---|
| ESR-1700 | 4 × 1G Combo, 8 × 10G SFP+ | 1,7M | 7 Гбит/с; 1308,1k пакетов/c | 750 |
| ESR-3300 | 4 × 25G SFP28, 4 × 100G QSFP28 | 1,7M | 1,4 Гбит/с; 258,5k пакетов/с | 750 |
| ESR-3200 | 12 × 25G SFP28 | 1,7M | 3,6 Гбит/с; 686,8k пакетов/с | 650 |
| ESR-3200L | 8 × 10G SFP+, 4 × 25G SFP28 | 1,7M | 1,88 Гбит/с; 353k пакетов/с | 720 |
| ESR-3250 | 8 × 1G Combo, 4 × 25G SFP28 | 1,7M | 5,3 Гбит/с; 1004,2k пакетов/с | 1710 |
| ESR-3350 | 8 × 1G Combo, 4 × 25G SFP28 | 1,7M | 14,5 Гбит/с; 2727k пакетов/с | 1800 |
Приведённые показатели ESR актуальны в рамках версии ПО 1.37.0. Актуальные значения показателей приведены в Datasheet.
Сервисные маршрутизаторы ESR в роли DMVPN Spoke в дочерних офисах
К маршрутизаторам в роли DMVPN Spoke требования ниже, поскольку объемы маршрутной информации и количество терминируемых IPsec-туннелей в дочерних офисах существенно ниже, чем в головном офисе. В связи с этим список рекомендованных моделей ESR на роль DMVPN Spoke в основном содержит младшие модели линейки маршрутизаторов ESR и отображен в таблице 2.
Таблица 2. Рекомендованные модели маршрутизаторов ESR на роль DMVPN Spoke
| Модель | Интерфейсы | Размер таблицы FIB | Производительность IPsec (IMIX) |
|---|---|---|---|
| ESR-31 | 8 × 1G, 6 × 1G SFP, 2 × 10G SFP+ | 1,4M | 519,8 Мбит/с; 97,1k пакетов/с |
| ESR-30 | 4 × 1G, 2 × 10G SFP+ | 1,4M | 519,8 Мбит/с; 97,1k пакетов/с |
| ESR-15VF | 8 × 1G, 2 × 1G SFP | 1M | 135,5 Мбит/с; 25,2k пакетов/с |
| ESR-15R | 4 × 1G, 2 × 1G SFP | 1M | 135,5 Мбит/с; 25,2k пакетов/с |
| ESR-15 | 4 × 1G, 2 × 1G SFP | 1M | 135,5 Мбит/с; 25,2k пакетов/с |
Приведённые показатели ESR актуальны в рамках версии ПО 1.37.0. Актуальные значения показателей приведены в Datasheet.
Измерения производительности IPsec производились на смешанном трафике Internet MIX. Формат трафика (количество в секунду: размер каждого фрейма) — 8:74; 5:512; 7:1518. При построении IPsec-туннелей использовался алгоритм шифрования AES128 и алгоритм хеширования MD5.
Конфигурация оборудования и проверка работоспособности
Настройка DMVPN Hub в центральном офисе
Стартовая конфигурация оборудования в центральном офисе
В качестве примера инфраструктуры центрального офиса рассмотрим топологию из дизайн-документа «Построение сети большого офиса». В рамках данного дизайн-документа была организована работа офисной сети с выходом локальных пользователей в Интернет через одного из двух доступных интернет-провайдеров. Также на схеме можно заметить сегмент демилитаризованной зоны для размещения сервисов с возможностью их публикации в сети Интернет с использованием технологии 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 достаточно велик, в связи с этим обратим внимание на самые важные пункты настройки:
- Для использования протокола 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 в центральном офисе можно считать завершенной.
Настройка DMVPN Spoke в дочернем офисе (статическая адресация)
Стартовое состояние сети в дочернем офисе
Рассмотрим пример подключения к облаку DMVPN небольшого офиса, в котором присутствует один интернет-провайдер, предоставляющий доступ в Интернет через белый статически-назначаемый IP-адрес:
Рисунок 5. Схема подключения маршрутизатора дочернего офиса с статическим IP-адресом к сети провайдера
Локальная сеть офиса обеспечена одним коммутатором доступа, который подключен непосредственно к маршрутизатору на границе сети. Сразу зададим устройствам имена для удобства дальнейшего конфигурирования.
Организация локального сегмента сети дочернего офиса
В рамках данного руководства рассмотрим простой пример настройки коммутатора доступа для обеспечения подключения оборудования дочернего офиса к пограничному маршрутизатору. Параметры локальной сети офиса описаны в таблице 7.
Таблица 7. Параметры локальной сети дочернего офиса №1
| Назначение | VLAN | Подсеть |
|---|---|---|
| Локальная сеть дочернего офиса №1 | 100 | 192.168.11.0/24 |
Настроим на коммутаторе доступа клиентские порты в режиме general, требуемый VLAN ID будем проставлять нетегированному трафику:
А порт в сторону маршрутизатора настроим как транковый для требуемого VLAN ID:
После чего стерминируем тегированный трафик на физическом саб-интерфейсе пограничного маршрутизатора:
Добавим для саб-интерфейса зону безопасности и разрешим входящий с точки зрения маршрутизатора трафик протокола ICMP из этой зоны безопасности:
Подключение к сети интернет-провайдера с использованием статической адресации
Рассмотрим подключение к сети Интернет с учетом выданных нам интернет-провайдером данных для настройки статической адресации на интерфейсе.
Таблица 8. Данные для настройки статической IP-адресации на пограничном маршрутизаторе дочернего офиса №1
| Параметр | Значение |
|---|---|
| IP-адрес маршрутизатора | 203.0.114.2 |
| Маска сети | 255.255.255.128 |
| IP-адрес шлюза | 203.0.114.1 |
В рамках данного примера интернет-провайдер предоставляет для настройки статической адресации публичный (белый) IP-адрес. Для случая, где интернет-провайдер предоставляет для настройки приватный (серый) IP-адрес с дальнейшим NAT-преобразованием в публичную IP-адресацию настройка будет выглядеть аналогичным образом, наличие NAT интернет-провайдера не окажет влияния на подключение дочернего филиала к головному через облако DMVPN.
Используя предоставленные интернет-провайдером данные, настроим сетевой интерфейс и статическую маршрутизацию. Интерфейс при этом вынесем в отдельный так называемый Front-VRF.
Схема подключения, в которой транспортная сеть для некой виртуальной сети выносится в отдельное сетевое пространство имен называется Front-Door VRF. Такая схема организации транспорта для виртуальной сети дает следующие преимущества:
- возможность использования маршрута по умолчанию как в виртуальной сети, так и в транспортной сети;
- отсутствие пересечения маршрутной информации между транспортной и виртуальной сетью;
- дополнительный уровень безопасности виртуальной сети, поскольку трафик из неё не может попасть в транспортную сеть без настроенной инкапсуляции в туннель.
Укажем для данного сетевого интерфейса отдельную зону безопасности и разрешим входящий с точки зрения маршрутизатора трафик протокола ICMP из этой зоны безопасности:
Настройка IKEv2 и IPsec-туннелирования на DMVPN Spoke
Настройка IPsec для будущего облака DMVPN является важной частью данного руководства. Корректная настройка IPsec гарантирует приватность и защищенность трафика между офисами. При дальнейшей настройке будем использовать параметры IKE и IPsec, представленные в таблице 9.
Таблица 9. Параметры IKE и IPsec, используемые для настройки туннелирования IPsec на маршрутизаторе DMVPN Spoke дочернего офиса №1.
| RT-OFFICE-1 | ||
|---|---|---|
| Параметры IKE | Алгоритм шифрования | AES-256 |
| Алгоритм хеширования | SHA2-256 | |
| Группа Диффи-Хеллмана | 19 | |
| Время жизни IKE-сеcсии в секундах | 86400 | |
| Идентификатор IKE-сессии | spoke1.company.loc | |
| Интервал отправки DPD-сообщений | 40 | |
| Общий таймаут ожидания ответа на DPD-сообщение | 160 | |
| Действие при наступлении таймаута DPD | Закрытие сессии IKE | |
| Параметры IPsec | Алгоритм шифрования | AES-256 |
| Алгоритм хеширования | SHA2-256 | |
| Группа Диффи-Хеллмана для механизма PFS | 19 | |
| Время жизни IPsec-сесcии в секундах | 28800 | |
| Время жизни IPsec-сесcии в килобайтах | 4608000 | |
| Интервал ранней реаутентификации IKE-сессии/Интервал раннего рекеинга IPsec-сессии в секундах | 3600 | |
| Пороговое значение ранней реаутентификации IKE-сессии/Пороговое значение раннего рекеинга IPsec-сессии в килобайтах | 86400 |
Начинается настройка IPsec с настройки наборов криптографических алгоритмов для протокола IKE:
Затем создадим набор ключей аутентификации IKE. Поскольку в дальнейшей настройке планируется использовать в качестве идентификатора IPsec-соседа доменные имена, в наборе ключей тоже используем доменные имена:
Создадим политику IKE. Она включает в себя наборы алгоритмов шифрования, выбор метода аутентификации и время жизни 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 можно объединить в общие VPN-профили. Как и криптошлюзов IKE, получим три IPsec VPN-профиля. Для IPsec VPN-профилей, использующихся на туннелях GRE в схеме DMVPN обязательно включение транспортного режима:
Разрешим прохождение трафика, связанного с IPsec-туннелями. Для этого сначала опишем профили портов для протокола IKE и упакованного в UDP шифрованного трафика протоколов IKE и ESP:
Разрешим входящий трафик IPsec-туннелей:
Настройка mGRE-туннелей на DMVPN Spoke
Настроим туннели GRE в многоточечном режиме с поддержкой протокола NHRP на DMVPN Spoke. Поскольку в центральном офисе развернуто два DMVPN Hub на адресации двух разных интернет-провайдеров, подключение к ним будем осуществлять двумя отдельными mGRE-туннелями. Основные параметры туннелей GRE для подключения обоим DMVPN Hub представлены в таблице 10.
Таблица 10. Параметры туннелей GRE на маршрутизаторе DMVPN Spoke дочернего офиса №1
| DMVPN Hub | DMVPN Cloud | Номер туннеля GRE | Туннельная адресация DMVPN Spoke | Туннельный адрес DMVPN Hub | NBMA-адрес DMVPN Hub | Ключ туннеля GRE | Время жизни NHRP-записей, секунды |
|---|---|---|---|---|---|---|---|
| RT-HUB-1 | ISP-1 Cloud | 11 | 172.16.1.11/24 | 172.16.1.1 | 203.0.113.4 | 1000 | 600 |
| RT-HUB-2 | ISP-2 Cloud | 12 | 172.16.2.11/24 | 172.16.2.1 | 203.0.113.132 | 2000 | 600 |
Сначала изменим общие настройки туннеля GRE на каждом из DMVPN Hub. К таким настройкам относятся:
- режим работы multipoint;
- значение key;
- значение TTL;
- размер MTU;
- значение TCP adjust-mss;
- туннельный IP-адрес;
- интерфейс, с которого будет строиться GRE-туннель;
- имя транспортного VRF.
Маршрутизаторы DMVPN Spoke с точки зрения протокола NHRP выполняют роль NHRP клиентов, которые после регистрации в облаке DMVPN на одном или нескольких DMVPN Hub могут запрашивать у них информацию о других членах облака DMVPN. В связи с этим для корректной работы DMVPN Spoke необходимо описать настройки протокола NHRP для подключения к обоим DMVPN Hub.
Для корректного построения Spoke-to-Spoke-туннелей, маршрутизация на которых направляет весь трафик на DMVPN Hub, включим опцию «ip nhrp shortcut», активирующую на DMVPN Spoke реагирование на специальные сообщения протокола NHRP «Traffic Indication», которые DMVPN Hub будет отправлять в ответ на пакеты предназначенные другому DMVPN Spoke. Обработка такого сообщения приведет к построению Spoke-to-Spoke туннеля и трафик между DMVPN Spoke будет проходить напрямую, минуя DMVPN Hub.
Такая схема организации маршрутизации и построения Spoke-to-Spoke туннелей в облаках DMVPN общепринято именуется третьей фазой DMVPN.
Из-за особенностей декапсуляции трафика из IPsec-туннелей, работающих в транспортном режиме инкапсуляции, трафик после дешифровки попадает на тот же сетевой интерфейс, который терминирует IPsec-туннель. В связи с этим в правилах межсетевого экранирования на DMVPN Spoke необходимо разрешить прием не только шифрованных IPsec-пакетов, но и GRE-пакетов, которые попадают на интерфейс после дешифрования.
Для фильтрации трафика внутри облака DMVPN нужно создать отдельную зону безопасности и назначить её на GRE-туннели. Разрешите прохождение входящего ICMP-трафика в этой зоне:
Конфигурирование маршрутизации для функционирования облака DMVPN в центральном офисе
Настроим BGP-соседей в сторону DMVPN Hub:
В связи с тем, что DMVPN Spoke и DMVPN Hub находятся в разных автономных системах, анонсирование маршрутной информации по умолчанию проводиться не будет. Создадим route-map, разрешающий отправку маршрута до нашей локальной сети на DMVPN Hub.
Созданный route-map указываем для семейства IPv4-маршрутов в созданных BGP-соседях. Также добавим локальную сеть в анонсируемые маршруты:
Включим поддержку BFD для созданных BGP-соседств. Учтем скорость сходимости IPsec и mGRE-туннелей и увеличим BFD-таймеры:
Разрешим прохождение входящего трафика протокола BGP и BFD в зоне безопасности, настроенной на туннелях GRE:
Настройка Zone-Based Firewall для локальной сети
Поскольку теперь построенное облако DMVPN обеспечивает выход трафика локальных пользователей дочернего офиса через интернет-шлюз центрального офиса, необходимо произвести дополнительные настройки Firewall.
Разрешим прохождение транзитного трафика из локальной сети в сторону облака DMVPN:
На этом настройку DMVPN в дочернем офисе можно считать завершенной.
Настройка DMVPN Spoke в дочернем офисе (DHCP)
Стартовое состояние сети в дочернем офисе
Рассмотрим пример подключения к облаку DMVPN небольшого офиса, в котором присутствует один интернет-провайдер, предоставляющий доступ в Интернет через белый IP-адрес, выдаваемый маршрутизатору в офисе по протоколу DHCP:
Рисунок 6. Схема подключения маршрутизатора дочернего офиса к сети провайдера с адресацией, выдаваемой по протоколу DHCP
Локальная сеть офиса обеспечена одним коммутатором доступа, который подключен непосредственно к маршрутизатору на границе сети. Сразу зададим устройствам имена для удобства дальнейшего конфигурирования.
Организация локального сегмента сети дочернего офиса
В рамках данного руководства рассмотрим простой пример настройки коммутатора доступа для обеспечения подключения оборудования дочернего офиса к пограничному маршрутизатору. Параметры локальной сети офиса описаны в таблице 11.
Таблица 11. Параметры локальной сети дочернего офиса №2
| Назначение | VLAN | Подсеть |
|---|---|---|
| Локальная сеть дочернего офиса №2 | 100 | 192.168.12.0/24 |
Настроим на коммутаторе доступа клиентские порты в режиме general, требуемый VLAN ID будем проставлять нетегированному трафику:
А порт в сторону маршрутизатора настроим как транковый для требуемого VLAN ID:
После чего стерминируем тегированный трафик на физическом саб-интерфейсе пограничного маршрутизатора:
Добавим для саб-интерфейса зону безопасности и разрешим входящий с точки зрения маршрутизатора трафик протокола ICMP из этой зоны безопасности:
Подключение к сети интернет-провайдера с получением адресации по DHCP
Рассмотрим подключение к сети Интернет с учетом выдачи нам интернет-провайдером по протоколу DHCP следующих параметров для настройки сетевого интерфейса.
Таблица 12. Параметры настройки сети, предоставляемые пограничному маршрутизатору дочернего офиса №2 интернет-провайдером по протоколу DHCP
| Параметр | Значение |
|---|---|
| IP-адрес маршрутизатора | 203.0.114.130 |
| Маска сети | 255.255.255.128 |
| IP-адрес шлюза | 203.0.114.129 |
В рамках данного примера интернет-провайдер предоставляет по протоколу DHCP публичный (белый) IP-адрес. Для случая, где интернет-провайдер предоставляет по протоколу DHCP приватный (серый) IP-адрес с дальнейшим NAT-преобразованием в публичную IP-адресацию настройка будет выглядеть аналогичным образом, наличие NAT интернет-провайдера не окажет влияния на подключение дочернего филиала к головному через облако DMVPN.
Настроим DHCP-клиент на сетевом интерфейсе, интерфейс при этом вынесем в отдельный, так называемый Front-VRF.
Схема подключения, в которой транспортная сеть для некой виртуальной сети выносится в отдельное сетевое пространство имен называется Front-Door VRF. Такая схема организации транспорта для виртуальной сети дает следующие преимущества:
- возможность использования маршрута по умолчанию как в виртуальной сети, так и в транспортной сети;
- отсутствие пересечения маршрутной информации между транспортной и виртуальной сетью;
- дополнительный уровень безопасности виртуальной сети, поскольку трафик из неё не может попасть в транспортную сеть без настроенной инкапсуляции в туннель.
Укажем для данного сетевого интерфейса отдельную зону безопасности и разрешим входящий с точки зрения маршрутизатора трафик протокола ICMP из этой зоны безопасности:
Настройка IKEv2 и IPsec-туннелирования на DMVPN Spoke
Настройка IPsec для будущего облака DMVPN является важной частью данного руководства. Корректная настройка IPsec гарантирует приватность и защищенность трафика между офисами. При дальнейшей настройке будут использованы параметры IKE и IPsec, представленные в таблице 13.
Таблица 13. Параметры IKE и IPsec, используемые для настройки туннелирования IPsec на маршрутизаторе DMVPN Spoke дочернего офиса №2.
| RT-OFFICE-2 | ||
|---|---|---|
| Параметры IKE | Алгоритм шифрования | AES-256 |
| Алгоритм хеширования | SHA2-256 | |
| Группа Диффи-Хеллмана | 19 | |
| Время жизни IKE-сеcсии в секундах | 86400 | |
| Идентификатор IKE-сессии | spoke2.company.loc | |
| Интервал отправки DPD-сообщений | 40 | |
| Общий таймаут ожидания ответа на DPD-сообщение | 160 | |
| Действие при наступлении таймаута DPD | Закрытие сессии IKE | |
| Параметры IPsec | Алгоритм шифрования | AES-256 |
| Алгоритм хеширования | SHA2-256 | |
| Группа Диффи-Хеллмана для механизма PFS | 19 | |
| Время жизни IPsec-сесcии в секундах | 28800 | |
| Время жизни IPsec-сесcии в килобайтах | 4608000 | |
| Интервал ранней реаутентификации IKE-сессии/Интервал раннего рекеинга IPsec-сессии в секундах | 3600 | |
| Пороговое значение ранней реаутентификации IKE-сессии/Пороговое значение раннего рекеинга IPsec-сессии в килобайтах | 86400 |
Начинается настройка IPsec с настройки наборов криптографических алгоритмов для протокола IKE:
Затем создадим набор ключей аутентификации IKE. Поскольку в дальнейшей настройке планируется использовать в качестве идентификатора IPsec-соседа доменные имена, в наборе ключей тоже используем доменные имена:
Создадим политику IKE. Она включает в себя наборы алгоритмов шифрования, выбор метода аутентификации и время жизни 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 можно объединить в общие VPN-профили. Как и криптошлюзов IKE, получим три IPsec VPN-профиля. Для IPsec VPN-профилей, использующихся на туннелях GRE в схеме DMVPN обязательно включение транспортного режима:
Разрешим прохождение трафика, связанного с IPsec-туннелями. Для этого сначала опишем профили портов для протокола IKE и упакованного в UDP шифрованного трафика протоколов IKE и ESP:
Разрешим входящий трафик IPsec-туннелей:
Настройка mGRE-туннелей на DMVPN Spoke
Настроим туннели GRE в многоточечном режиме с поддержкой протокола NHRP на DMVPN Spoke. Поскольку в центральном офисе развернуто два DMVPN Hub на адресации двух разных интернет-провайдеров, подключение к ним будем осуществлять двумя отдельными mGRE-туннелями. Основные параметры туннелей GRE для подключения к обоим DMVPN Hub представлены в таблице 14.
Таблица 14. Параметры туннелей GRE на маршрутизаторе DMVPN Spoke дочернего офиса №2
| DMVPN Hub | DMVPN Cloud | Номер туннеля GRE | Туннельная адресация DMVPN Spoke | Туннельный адрес DMVPN Hub | NBMA-адрес DMVPN Hub | Ключ туннеля GRE | Время жизни NHRP-записей, секунды |
|---|---|---|---|---|---|---|---|
| RT-HUB-1 | ISP-1 Cloud | 11 | 172.16.1.12/24 | 172.16.1.1 | 203.0.113.4 | 1000 | 600 |
| RT-HUB-2 | ISP-2 Cloud | 12 | 172.16.2.12/24 | 172.16.2.1 | 203.0.113.132 | 2000 | 600 |
Сначала изменим общие настройки туннеля GRE на каждом из DMVPN Hub. К таким настройкам относятся:
- режим работы multipoint;
- значение key;
- значение TTL;
- размер MTU;
- значение TCP adjust-mss;
- туннельный IP-адрес;
- интерфейс, с которого будет строиться GRE-туннель;
- имя транспортного VRF.
Маршрутизаторы DMVPN Spoke с точки зрения протокола NHRP выполняют роль NHRP клиентов, которые после регистрации в облаке DMVPN на одном или нескольких DMVPN Hub могут запрашивать у них информацию о других членах облака DMVPN. В связи с этим для корректной работы DMVPN Spoke необходимо описать настройки протокола NHRP для подключения к обоим DMVPN Hub.
Для корректного построения Spoke-to-Spoke-туннелей, маршрутизация на которых весь трафик заводит на DMVPN Hub, включим опцию «ip nhrp shortcut», активирующую на DMVPN Spoke реагирование на специальные сообщения протокола NHRP «Traffic Indication», которые DMVPN Hub будет отправлять в ответ на пакеты, предназначенные другому DMVPN Spoke. Обработка такого сообщения приведет к построению Spoke-to-Spoke-туннеля и трафик между DMVPN Spoke будет проходить напрямую, минуя DMVPN Hub.
Такая схема организации маршрутизации и построения Spoke-to-Spoke туннелей в облаках DMVPN общепринято именуется третьей фазой DMVPN.
Из-за особенностей декапсуляции трафика из IPsec-туннелей, работающих в транспортном режиме инкапсуляции, трафик после дешифровки попадает на тот же сетевой интерфейс, который терминирует IPsec-туннель. В связи с этим в правилах межсетевого экранирования на DMVPN Spoke необходимо разрешить прием не только шифрованных IPsec-пакетов, но и GRE-пакетов, которые попадают на интерфейс после дешифрования.
Для фильтрации трафика внутри облака DMVPN создадим отдельную зону безопасности и назначим её на GRE-туннели. Разрешим прохождение входящего ICMP-трафика в этой зоне:
Конфигурирование маршрутизации для функционирования облака DMVPN в центральном офисе
Настроим BGP-соседей в сторону DMVPN Hub:
В связи с тем, что DMVPN Spoke и DMVPN Hub находятся в разных автономных системах, анонсирование маршрутной информации по умолчанию проводиться не будет. Создадим route-map, разрешающий отправку маршрута до нашей локальной сети на DMVPN Hub.
Созданный route-map указываем для семейства IPv4-маршрутов в созданных BGP-соседях. Также добавим локальную сеть в анонсируемые маршруты:
Включим поддержку BFD для созданных BGP-соседств. Учтем скорость сходимости IPsec и mGRE-туннелей и увеличим BFD-таймеры:
Разрешим прохождение входящего трафика протокола BGP и BFD в зоне безопасности, настроенной на туннелях GRE:
Настройка Zone-Based Firewall для локальной сети
Поскольку теперь построенное облако DMVPN обеспечивает выход трафика локальных пользователей дочернего офиса через интернет-шлюз центрального офиса, необходимо произвести дополнительные настройки Firewall.
Разрешим прохождение транзитного трафика из локальной сети в сторону облака DMVPN:
На этом настройку DMVPN в дочернем офисе можно считать завершенной.
Настройка DMVPN Spoke в дочернем офисе (PPPoE)
Стартовое состояние сети в дочернем офисе
Рассмотрим пример подключения к облаку DMVPN небольшого офиса, в котором присутствует один интернет-провайдер, предоставляющий доступ в Интернет через PPPoE-туннель:
Рисунок 7. Схема подключения маршрутизатора дочернего офиса к сети интернет-провайдера через туннель PPPoE
Локальная сеть офиса обеспечена одним коммутатором доступа, который подключен непосредственно к маршрутизатору на границе сети. Сразу зададим устройствам имена для удобства дальнейшего конфигурирования.
Организация локального сегмента сети дочернего офиса
В рамках данного руководства рассмотрим простой пример настройки коммутатора доступа для обеспечения подключения оборудования дочернего офиса к пограничному маршрутизатору. Параметры локальной сети офиса описаны в таблице 15.
Таблица 15. Параметры локальной сети дочернего офиса №3
| Назначение | VLAN | Подсеть |
|---|---|---|
| Локальная сеть дочернего офиса №3 | 100 | 192.168.13.0/24 |
Настроим на коммутаторе доступа клиентские порты в режиме general, требуемый VLAN ID будем проставлять нетегированному трафику:
А порт в сторону маршрутизатора настроим как транковый для требуемого VLAN ID:
После чего стерминируем тегированный трафик на физическом саб-интерфейсе пограничного маршрутизатора:
Добавим для саб-интерфейса зону безопасности и разрешим входящий с точки зрения маршрутизатора трафик протокола ICMP из этой зоны безопасности:
Подключение к сети интернет-провайдера через туннель PPPoE
Рассмотрим подключение к сети Интернет с учетом следующих настроек, полученных при поднятии PPPoE-туннеля в сторону интернет-провайдера. Настройки представлены в таблице 16.
Таблица 16. Параметры для настройки PPPoE-туннеля на пограничном маршрутизаторе дочернего офиса №3 в сторону интернет-провайдера
| Параметр | Значение |
|---|---|
| Логин PPPoE | user |
| Пароль PPPoE | password |
| Локальный туннельный адрес | 10.0.0.15 |
| Удаленный туннельный адрес | 172.16.0.1 |
В рамках данного примера интернет-провайдер предоставляет через туннель PPPoE приватный (серый) IP-адрес. Для случая, где интернет-провайдер предоставляет через туннель PPPoE публичный (белый) IP-адрес настройка будет выглядеть аналогичным образом, отсутствие NAT интернет-провайдера не окажет влияния на подключение дочернего филиала к головному через облако DMVPN.
Физический интерфейс, с которого будет поднят PPPoE-туннель, вынесем в отдельный VRF.
Схема подключения, в которой транспортная сеть для некой виртуальной сети выносится в отдельное сетевое пространство имен называется Front-Door VRF. Такая схема организации транспорта для виртуальной сети дает следующие преимущества:
- возможность использования маршрута по умолчанию как в виртуальной сети, так и в транспортной сети;
- отсутствие пересечения маршрутной информации между транспортной и виртуальной сетью;
- дополнительный уровень безопасности виртуальной сети, поскольку трафик из неё не может попасть в транспортную сеть без настроенной инкапсуляции в туннель.
Добавим туннель PPPoE в этот же VRF. В конфигурации не забываем указать логин и пароль для авторизации:
Укажем для туннеля PPPoE отдельную зону безопасности и разрешим входящий с точки зрения маршрутизатора трафик протокола ICMP из этой зоны безопасности:
Настройка IKEv2 и IPsec-туннелирования на DMVPN Spoke
Настройка IPsec для будущего облака DMVPN является важной частью данного руководства. Корректная настройка IPsec гарантирует приватность и защищенность трафика между офисами. При дальнейшей настройке будем использовать параметры IKE и IPsec, представленные в таблице 17.
Таблица 17. Параметры IKE и IPsec, используемые для настройки туннелирования IPsec на маршрутизаторе DMVPN Spoke дочернего офиса №3
| RT-OFFICE-3 | ||
|---|---|---|
| Параметры IKE | Алгоритм шифрования | AES-256 |
| Алгоритм хеширования | SHA2-256 | |
| Группа Диффи-Хеллмана | 19 | |
| Время жизни IKE-сеcсии в секундах | 86400 | |
| Идентификатор IKE-сессии | spoke3.company.loc | |
| Интервал отправки DPD-сообщений | 40 | |
| Общий таймаут ожидания ответа на DPD-сообщение | 160 | |
| Действие при наступлении таймаута DPD | Закрытие сессии IKE | |
| Параметры IPsec | Алгоритм шифрования | AES-256 |
| Алгоритм хеширования | SHA2-256 | |
| Группа Диффи-Хеллмана для механизма PFS | 19 | |
| Время жизни IPsec-сесcии в секундах | 28800 | |
| Время жизни IPsec-сесcии в килобайтах | 4608000 | |
| Интервал ранней реаутентификации IKE-сессии/Интервал раннего рекеинга IPsec-сессии в секундах | 3600 | |
| Пороговое значение ранней реаутентификации IKE-сессии/Пороговое значение раннего рекеинга IPsec-сессии в килобайтах | 86400 |
Начинается настройка IPsec с настройки наборов криптографических алгоритмов для протокола IKE:
Затем создадим набор ключей аутентификации IKE. Поскольку в дальнейшей настройке планируется использовать в качестве идентификатора IPsec-соседа доменные имена, в наборе ключей тоже используем доменные имена:
Создадим политику IKE. Она включает в себя наборы алгоритмов шифрования, выбор метода аутентификации и время жизни 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 можно объединить в общие VPN-профили. Как и криптошлюзов IKE, получим три IPsec VPN-профиля. Для IPsec VPN-профилей, использующихся на туннелях GRE в схеме DMVPN обязательно включение транспортного режима:
Разрешим прохождение трафика, связанного с IPsec-туннелями. Для этого сначала опишем профили портов для протокола IKE и упакованного в UDP шифрованного трафика протоколов IKE и ESP:
Разрешим входящий трафик IPsec-туннелей:
Настройка mGRE-туннелей на DMVPN Spoke
Настроим туннели GRE в многоточечном режиме с поддержкой протокола NHRP на DMVPN Spoke. Поскольку в центральном офисе развернуто два DMVPN Hub на адресации двух разных интернет-провайдеров, подключение к ним будем осуществлять двумя отдельными mGRE-туннелями. Основные параметры туннелей GRE для подключения обоих DMVPN Hub представлены в таблице 18.
Таблица 18. Параметры туннелей GRE на маршрутизаторе DMVPN Spoke дочернего офиса №3
| DMVPN Hub | DMVPN Cloud | Номер туннеля GRE | Туннельная адресация DMVPN Spoke | Туннельный адрес DMVPN Hub | NBMA-адрес DMVPN Hub | Ключ туннеля GRE | Время жизни NHRP-записей, секунды |
|---|---|---|---|---|---|---|---|
| RT-HUB-1 | ISP-1 Cloud | 11 | 172.16.1.13/24 | 172.16.1.1 | 203.0.113.4 | 1000 | 600 |
| RT-HUB-2 | ISP-2 Cloud | 12 | 172.16.2.13/24 | 172.16.2.1 | 203.0.113.132 | 2000 | 600 |
Сначала настроим общие настройки туннеля GRE на каждом из DMVPN Hub. К таким настройкам относятся:
- режим работы multipoint;
- значение key;
- значение TTL;
- размер MTU;
- значение TCP adjust-mss;
- туннельный IP-адрес;
- интерфейс, с которого будет строиться GRE-туннель;
- имя транспортного VRF.
Маршрутизаторы DMVPN Spoke с точки зрения протокола NHRP выполняют роль NHRP клиентов, которые после регистрации в облаке DMVPN на одном или нескольких DMVPN Hub могут запрашивать у них информацию о других членах облака DMVPN. В связи с этим для корректной работы DMVPN Spoke необходимо описать настройки протокола NHRP для подключения к обоим DMVPN Hub.
Для корректного построения Spoke-to-Spoke-туннелей, маршрутизация на которых весь трафик заводит на DMVPN Hub, включим опцию «ip nhrp shortcut»,активирующую на DMVPN Spoke реагирование на специальные сообщения протокола NHRP «Traffic Indication», которые DMVPN Hub будет отправлять в ответ на пакеты, предназначенные другому DMVPN Spoke. Обработка данного сообщения приведет к построению Spoke-to-Spoke-туннеля и трафик между DMVPN Spoke будет проходить напрямую, минуя DMVPN Hub.
Такая схема организации маршрутизации и построения Spoke-to-Spoke-туннелей в облаках DMVPN общепринято именуется третьей фазой DMVPN.
Из-за особенностей декапсуляции трафика из IPsec-туннелей, работающих в транспортном режиме инкапсуляции, трафик после дешифровки попадает на тот же сетевой интерфейс, который терминирует IPsec-туннель. В связи с этим в правилах межсетевого экранирования на DMVPN Spoke необходимо разрешить прием не только шифрованных IPsec-пакетов, но и GRE-пакетов, которые попадают на интерфейс после дешифрования.
Для фильтрации трафика внутри облака DMVPN создадим отдельную зону безопасности и назначим её на GRE-туннели. Разрешим прохождение входящего ICMP-трафика в этой зоне:
Конфигурирование маршрутизации для функционирования облака DMVPN в центральном офисе
Настроим BGP-соседей в сторону DMVPN Hub:
В связи с тем, что DMVPN Spoke и DMVPN Hub находятся в разных автономных системах, анонсирование маршрутной информации по умолчанию проводиться не будет. Создадим route-map, разрешающий отправку маршрута до нашей локальной сети на DMVPN Hub.
Созданный route-map указываем для семейства IPv4-маршрутов в созданных BGP-соседях. Также добавим локальную сеть в анонсируемые маршруты:
Включим поддержку BFD для созданных BGP-соседств. Учтем скорость сходимости IPsec и mGRE-туннелей и увеличим BFD-таймеры:
Разрешим прохождение входящего трафика протокола BGP и BFD в зоне безопасности, настроенной на туннелях GRE:
Настройка Zone-Based Firewall для локальной сети
Поскольку теперь построенное облако DMVPN обеспечивает выход трафика локальных пользователей дочернего офиса через интернет-шлюз центрального офиса, необходимо произвести дополнительные настройки Firewall.
Разрешим прохождение транзитного трафика из локальной сети в сторону облака DMVPN:
На этом настройку DMVPN в дочернем офисе можно считать завершенной.
Настройка DMVPN Spoke в дочернем офисе (с резервным каналом)
Стартовое состояние сети в дочернем офисе
Рассмотрим пример подключения офиса к DMVPN-облаку, где организация использует два канала доступа в Интернет от разных интернет-провайдеров. Оба интернет-провайдера предоставляют белые статически-назначаемые IP-адреса, что позволяет обеспечить резервирование соединения.
Рисунок 8. Схема подключения маршрутизатора дочернего офиса через сети двух интернет-провайдеров.
Маршрутизатор дочернего офиса подключается к двум интернет-провайдерам, каждый из которых предоставляет канал с белым статически-назначаемым IP-адресом. Для удобства конфигурирования сразу зададим именования обоим устройствам в данной схеме.
Организация локального сегмента сети дочернего офиса
В рамках руководства рассмотрим простой пример настройки коммутатора доступа для обеспечения подключения оборудования дочернего офиса к пограничному маршрутизатору. Параметры локальной сети офиса описаны в таблице 19.
Таблица 19. Параметры локальной сети дочернего офиса №4.
| Назначение | VLAN | Подсеть |
|---|---|---|
| Локальная сеть дочернего офиса №4 | 100 | 192.168.14.0/24 |
Перейдем к настройке коммутатора. Необходимо сконфигурировать клиентские порты в режиме general. Требуемый VLAN ID инсталлируется нетегированному трафику.
Физический интерфейс в сторону маршрутизатора настроим в режиме trunk для требуемого VLAN ID:
Перейдем к конфигурации пограничного маршрутизатора. Добавим саб-интерфейс для обработки тегированного трафика с соответственным VLAN ID:
Добавим для саб-интерфейса зону безопасности и обеспечим прием входящего трафика протокола ICMP из данной зоны безопасности:
Подключение к сети интернет-провайдера №1 с использованием статической адресации
Рассмотрим подключение к сети Интернет с учетом выданных интернет-провайдером №1 данных для настройки статической адресации на интерфейсе. Параметры для подключения к интернет-провайдеру описаны в таблице 20.
Таблица 20. Данные интернет-провайдера №1 для настройки статической IP-адресации на пограничном маршрутизаторе дочернего офиса №4
| Параметр | Значение |
|---|---|
| IP-адрес пограничного маршрутизатора | 203.10.1.2 |
| Маска сети | 255.255.255.0 |
| IP-адрес шлюза | 203.10.1.1 |
В рамках данного примера интернет-провайдер №1 и №2 предоставляет для настройки статической адресации публичные (белые) IP-адреса от каждого интернет-провайдера соответственно. Для случая, где интернет-провайдер предоставляет для настройки приватный (серый) IP-адрес с дальнейшим NAT-преобразованием в публичную IP-адресацию, настройка будет выглядеть аналогичным образом.
Перейдем к настройке сетевого интерфейса и статической маршрутизации. Интерфейс разграничим с помощью VRF — далее в настройке будет производиться конфигурация Front-Door VRF-схемы.
Схема подключения, в которой транспортная сеть для некой виртуальной сети выносится в отдельное сетевое пространство имен, называется Front-Door VRF. Такая схема организации транспорта для виртуальной сети дает следующие преимущества:
- возможность использования маршрута по умолчанию как в виртуальной сети, так и в транспортной сети;
- отсутствие пересечения маршрутной информации между транспортной и виртуальной сетью;
- дополнительный уровень безопасности виртуальной сети, поскольку трафик из неё не может попасть в транспортную сеть без настроенной инкапсуляции в туннель.
Сконфигурируем для данного сетевого интерфейса отдельную зону безопасности и разрешим входящий с точки зрения пограничного маршрутизатора трафик протокола ICMP из данной зоны безопасности:
Подключение к сети интернет-провайдера №2 с использованием статической адресации
Необходимо рассмотреть подключение к сети Интернет с учетом выданных интернет-провайдером №2 данных для настройки статической адресации на интерфейсе. Параметры для подключения к интернет-провайдеру описаны в таблице 21.
Таблица 21. Данные интернет-провайдера №2 для настройки статической IP-адресации на пограничном маршрутизаторе дочернего офиса №4
| Параметр | Значение |
|---|---|
| IP-адрес маршрутизатора | 203.10.0.2 |
| Маска сети | 255.255.255.0 |
| IP-адрес шлюза | 203.10.0.1 |
Перейдем к настройке сетевого интерфейса и статической маршрутизации. Интерфейс также разграничим с помощью VRF — далее в настройке будет производиться конфигурация Front-Door VRF-схемы.
Сконфигурируем для сетевого интерфейса, выходящего в сеть интернет-провайдера №2, отдельную зону безопасности и разрешим входящий, с точки зрения пограничного маршрутизатора, трафик протокола ICMP из данной зоны безопасности:
Настройка IKEv2 и IPsec-туннелирования на DMVPN Spoke
Конфигурация IPsec для будущего DMVPN-облака представляет собой ключевой этап данного руководства. Правильная настройка IPsec обеспечивает конфиденциальность и защиту трафика между дочерними офисами. При последующей настройке будут использоваться параметры IKE и IPsec, приведённые в таблице 22.
Таблица 22. Параметры IKE и IPsec, используемые для настройки туннелирования IPsec на маршрутизаторе DMVPN Spoke дочернего офиса №4.
| RT-OFFICE-4 | ||
|---|---|---|
| Параметры IKE | Алгоритм шифрования | AES-256 |
| Алгоритм хеширования | SHA2-256 | |
| Группа Диффи-Хеллмана | 19 | |
| Время жизни IKE-сеcсии в секундах | 86400 | |
| Идентификатор IKE-сессии | spoke4.company.loc | |
| Интервал отправки DPD-сообщений | 40 | |
| Общий таймаут ожидания ответа на DPD-сообщение | 160 | |
| Действие при наступлении таймаута DPD | Закрытие сессии IKE | |
| Параметры IPsec | Алгоритм шифрования | AES-256 |
| Алгоритм хеширования | SHA2-256 | |
| Группа Диффи-Хеллмана для механизма PFS | 19 | |
| Время жизни IPsec-сесcии в секундах | 28800 | |
| Время жизни IPsec-сесcии в килобайтах | 4608000 | |
| Интервал ранней реаутентификации IKE-сессии/Интервал раннего рекеинга IPsec-сессии в секундах | 3600 | |
| Пороговое значение ранней реаутентификации IKE-сессии/Пороговое значение раннего рекеинга IPsec-сессии в килобайтах | 86400 | |
Начало настройки IPsec заключается в настройке наборов криптографических алгоритмов для протокола IKE:
Cоздадим набор ключей аутентификации IKE. Поскольку в дальнейшей настройке планируется использовать в качестве идентификатора IPsec-соседа доменные имена, в наборе ключей тоже будут использоваться доменные имена:
Перейдем к созданию политики IKE. Она включает в себя наборы алгоритмов шифрования, выбор метода аутентификации и время жизни IKE-сессии (Phase 1):
Создадим набор криптошлюзов 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 можно объединить в общие VPN-профили. Как и при получении криптошлюзов IKE получим четыре IPsec VPN-профиля. Для IPsec VPN-профилей, использующихся на туннелях GRE в схеме DMVPN, обязательно включение транспортного режима:
Разрешим прохождение трафика, связанного с IPsec-туннелями. Для этого сначала опишем профили портов для протокола IKE и упакованного в UDP шифрованного трафика протоколов IKE и ESP:
Разрешим входящий трафик IPsec-туннелей для каждого из интернет-провайдеров (Firewall):
Пользовательский трафик запаковывается в протокол ESP, и, при наличии NAT посередине между IPsec-соседями, сообщения протокола ESP, в свою очередь, запаковываются в протокол UDP, порт 4500. Поскольку туннели между DMVPN Spoke могут подняться и без наличия NAT между ними, отдельным правилом разрешим прохождение ESP-пакетов.
Настройка mGRE-туннелей на DMVPN Spoke
Настроим туннели GRE в многоточечном режиме с поддержкой протокола NHRP на DMVPN Spoke. Поскольку в центральном офисе развернуто два DMVPN Hub на адресации двух разных интернет-провайдеров, подключение к ним будем осуществлять двумя отдельными mGRE-туннелями. Отличия настройки DMVPN Spoke с подключением к одному интернет-провайдеру заключается в том, что NBMA-адрес для каждого GRE-туннеля будет отличаться в зависимости от IP-адреса интерфейса к данному интернет-провайдеру. Основные параметры туннелей GRE для подключения обоим DMVPN Hub представлены в таблице 23.
Таблица 23. Параметры туннелей GRE на маршрутизаторе DMVPN Spoke дочернего офиса №4
| DMVPN Hub | DMVPN Cloud | Номер туннеля GRE | Туннельная адресация DMVPN Spoke | Туннельный адрес DMVPN Hub | NBMA-адрес DMVPN Hub | Ключ туннеля GRE | Время жизни NHRP-записей, секунды |
|---|---|---|---|---|---|---|---|
| RT-HUB-1 | ISP-BACKUP Cloud | 11 | 172.16.1.14/24 | 172.16.1.1 | 203.0.113.4 | 1000 | 600 |
| RT-HUB-2 | ISP-CORE Cloud | 12 | 172.16.2.14/24 | 172.16.2.1 | 203.0.113.132 | 2000 | 600 |
Сначала изменим общие настройки туннеля GRE на каждом из DMVPN Hub. К таким настройкам относятся:
- режим работы multipoint;
- значение key;
- значение TTL;
- размер MTU;
- значение TCP adjust-mss;
- туннельный IP-адрес;
- интерфейс, с которого будет строиться GRE-туннель;
- имя транспортного VRF.
Маршрутизаторы DMVPN Spoke с точки зрения протокола NHRP выполняют роль NHRP-клиентов, которые после регистрации в облаке DMVPN на одном или нескольких DMVPN Hub могут запрашивать у них информацию о других членах облака DMVPN. В связи с этим для корректной работы DMVPN Spoke необходимо описать настройки протокола NHRP для подключения к обоим DMVPN Hub.
Для корректного построения Spoke-to-Spoke-туннелей, маршрутизация на которых направляет весь трафик на DMVPN Hub, включим опцию «ip nhrp shortcut», активирующую на DMVPN Spoke реагирование на специальные сообщения протокола NHRP «Traffic Indication», которые DMVPN Hub будет отправлять в ответ на пакеты, предназначенные другому DMVPN Spoke. Обработка такого сообщения приведет к построению Spoke-to-Spoke туннеля, и трафик между DMVPN Spoke будет проходить напрямую, минуя DMVPN Hub.
Такая схема организации маршрутизации и построения Spoke-to-Spoke туннелей в облаках DMVPN общепринято именуется третьей фазой DMVPN.
Следует учитывать, что пересоздание Spoke-to-Spoke туннелей инициируется только после истечения заданного параметра holding-time. Таким образом, при отказе интернет-провайдера и, соответственно, отсутствии связи с DMVPN Hub, реконфигурация Spoke-to-Spoke туннеля резервному интернет-провайдеру произойдёт по завершении времени жизни (Expire time) соответствующего Spoke-to-Spoke туннеля.
Из-за особенностей декапсуляции трафика из IPsec-туннелей, работающих в транспортном режиме инкапсуляции, трафик после дешифровки попадает на тот же сетевой интерфейс, который терминирует IPsec-туннель. В связи с этим в правилах межсетевого экранирования на DMVPN Spoke необходимо разрешить прием не только шифрованных IPsec-пакетов, но и GRE-пакетов, которые попадают на интерфейс после дешифрования.
Для фильтрации трафика внутри облака DMVPN нужно создать отдельную зону безопасности и назначить её на GRE-туннели. Разрешите прохождение входящего ICMP-трафика в этой зоне:
Конфигурирование маршрутизации для функционирования облака DMVPN в центральном офисе
Настроим BGP-соседей в сторону DMVPN Hub:
В связи с тем, что DMVPN Spoke и DMVPN Hub находятся в разных автономных системах, анонсирование маршрутной информации по умолчанию проводиться не будет. Создадим route-map, разрешающий отправку маршрута до нашей локальной сети на DMVPN Hub. При распространении маршрутов по умолчанию они анонсируются с различными метриками, что обеспечивает выбор приоритетного направления. В случае недоступности второго интернет-провайдера, а значит и второго хаба, переключение маршрутизации осуществляется за счёт механизма протокола BFD.
Созданный route-map указываем для семейства IPv4-маршрутов в созданных BGP-соседях. Также добавим локальную сеть в анонсируемые маршруты:
Включим поддержку BFD для созданных BGP-соседств. Учтем скорость сходимости IPsec и mGRE-туннелей и увеличим BFD-таймеры:
Разрешим прохождение входящего трафика протокола BGP и BFD в зоне безопасности, настроенной на туннелях GRE:
Настройка Zone-Based Firewall для локальной сети
Поскольку теперь построенное облако DMVPN обеспечивает выход трафика локальных пользователей дочернего офиса через интернет-шлюз центрального офиса, необходимо произвести дополнительные настройки Firewall.
Разрешим прохождение транзитного трафика из локальной сети в сторону облака DMVPN:
На этом настройку DMVPN в дочернем офисе с резервированием канала можно считать завершенной.
Настройка DMVPN Spoke в дочернем офисе (резервный канал через модем)
Стартовое состояние сети в дочернем офисе
Рассмотрим пример подключения к облаку DMVPN небольшого офиса, в котором присутствует два интернет-провайдера, один из которых предоставляет доступ через проводное подключение, а второй — через stick-модем.
Рисунок 9. Схема подключения маршрутизатора дочернего офиса (с резервным подключением через модем) через сети двух интернет-провайдеров
В рамках данной схемы DMVPN на узле Spoke организуются два GRE-туннеля: первый — к первому DMVPN Hub, второй — ко второму. Узел Spoke обладает IP-связностью по двум независимым интернет-провайдерам; транспорт первого интернет-провайдера используется для построения DMVPN-соединения с первым DMVPN Hub, используя uplink как «проводное» подключение к сети, транспорт второго интернет-провайдера — для соединения со вторым DMVPN Hub с помощью stick-модема. В рамках данного руководства используется stick-модем huawei E8372
Маршрутизатор дочернего офиса подключается к двум интернет-провайдерам, каждый из которых предоставляет канал с белым статическим IP-адресом. Для удобства конфигурирования сразу зададим именования обоим устройствам в данной схеме.
Организация локального сегмента сети дочернего офиса
В рамках руководства рассмотрим простой пример настройки коммутатора доступа для обеспечения подключения оборудования дочернего офиса к пограничному маршрутизатору. Параметры локальной сети офиса описаны в таблице 24.
Таблица 24. Параметры локальной сети дочернего офиса №5
| Назначение | VLAN | Подсеть |
|---|---|---|
| Локальная сеть дочернего офиса №5 | 100 | 192.168.15.0/24 |
Перейдем к настройке коммутатора. Необходимо сконфигурировать клиентские порты в режиме general. Требуемый VLAN ID инсталлируется нетегированному трафику.
Физический интерфейс в сторону маршрутизатора настроим в режиме trunk для требуемого VLAN ID:
Перейдем к конфигурации пограничного маршрутизатора. Добавим саб-интерфейс для обработки тегированного трафика с соответственным VLAN ID:
Добавим для саб-интерфейса зону безопасности и обеспечим прием входящего трафика протокола ICMP из данной зоны безопасности:
Подключение к сети интернет-провайдера №1 с помощью проводного подключения с использованием статической адресации
Рассмотрим подключение к сети Интернет с учетом выданных интернет-провайдером №1 данных для настройки статической адресации на интерфейсе. Параметры для подключения к интернет-провайдеру описаны в таблице 25.
Таблица 25. Данные интернет-провайдера №1 для настройки статической IP-адресации на пограничном маршрутизаторе дочернего офиса №5
| Параметр | Значение |
|---|---|
| IP-адрес пограничного маршрутизатора | 203.11.1.2 |
| Маска сети | 255.255.255.0 |
| IP-адрес шлюза | 203.11.1.1 |
В рамках данного примера интернет-провайдер №1 и №2 предоставляет для настройки статической адресации публичные (белые) IP-адреса от каждого интернет-провайдера соответственно. Для случая, где интернет-провайдер предоставляет для настройки приватный (серый) IP-адрес с дальнейшим NAT-преобразованием в публичную IP-адресацию настройка будет выглядеть аналогичным образом.
Перейдем к настройке сетевого интерфейса и статической маршрутизации. Интерфейс разграничим с помощью VRF — далее в настройке будет производиться конфигурация Front-Door VRF-схемы.
Схема подключения, в которой транспортная сеть для некой виртуальной сети выносится в отдельное сетевое пространство имен, называется Front-Door VRF. Такая схема организации транспорта для виртуальной сети дает следующие преимущества:
- возможность использования маршрута по умолчанию как в виртуальной сети, так и в транспортной сети;
- отсутствие пересечения маршрутной информации между транспортной и виртуальной сетью;
- дополнительный уровень безопасности виртуальной сети, поскольку трафик из неё не может попасть в транспортную сеть без настроенной инкапсуляции в туннель.
Сконфигурируем для данного сетевого интерфейса отдельную зону безопасности и разрешим входящий с точки зрения пограничного маршрутизатора трафик протокола ICMP из данной зоны безопасности:
Подключение к сети интернет-провайдера №2 с помощью stick-модема с использованием статической адресации
Необходимо рассмотреть подключение к сети Интернет с учетом выданных интернет-провайдером №2 данных для настройки статической адресации на модеме. Параметры для подключения к интернет-провайдеру описаны в таблице 26.
Таблица 26. Данные интернет-провайдера №2 для настройки статической IP-адресации на пограничном маршрутизаторе дочернего офиса №5
| Параметр | Значение |
|---|---|
| IP-адрес маршрутизатора | 203.11.0.2 |
| Маска сети | 255.255.255.0 |
| IP-адрес шлюза | 203.11.0.1 |
Перейдем к настройке stick-модема и статической маршрутизации. Интерфейс также разграничим с помощью VRF — далее в настройке будет производиться конфигурация Front-Door VRF-схемы.
Первый шаг к настройке подключения через модем заключается в подключении модема к пограничному маршрутизатору и ожидании определения производителя модема и номера слота, куда подключен модем. Данную информацию можно просмотреть с помощью команды show cellular status modem. При пустой конфигурации в отношении модемов статус модема будет в disabled/Down.
Второй шаг заключается в настройка самого интерфейса stick-модема. Перейдем к нему:
Сконфигурируем для сетевого интерфейса, выходящего в сеть интернет-провайдера №2, отдельную зону безопасности и разрешим входящий с точки зрения пограничного маршрутизатора трафик протокола ICMP из данной зоны безопасности:
Настройка IKEv2 и IPsec-туннелирования на DMVPN Spoke
Конфигурация IPsec для будущего DMVPN-облака представляет собой ключевой этап данного руководства. Правильная настройка IPsec обеспечивает конфиденциальность и защиту трафика между дочерними офисами. При последующей настройке будут использоваться параметры IKE и IPsec, приведённые в таблице 27.
Таблица 27. Параметры IKE и IPsec, используемые для настройки туннелирования IPsec на маршрутизаторе DMVPN Spoke дочернего офиса №5
| RT-OFFICE-5 | ||
|---|---|---|
| Параметры IKE | Алгоритм шифрования | AES-256 |
| Алгоритм хеширования | SHA2-256 | |
| Группа Диффи-Хеллмана | 19 | |
| Время жизни IKE-сеcсии в секундах | 86400 | |
| Идентификатор IKE-сессии | spoke5.company.loc | |
| Интервал отправки DPD-сообщений | 40 | |
| Общий таймаут ожидания ответа на DPD-сообщение | 160 | |
| Действие при наступлении таймаута DPD | Закрытие сессии IKE | |
| Параметры IPsec | Алгоритм шифрования | AES-256 |
| Алгоритм хеширования | SHA2-256 | |
| Группа Диффи-Хеллмана для механизма PFS | 19 | |
| Время жизни IPsec-сесcии в секундах | 28800 | |
| Время жизни IPsec-сесcии в килобайтах | 4608000 | |
| Интервал ранней реаутентификации IKE-сессии/Интервал раннего рекеинга IPsec-сессии в секундах | 3600 | |
| Пороговое значение ранней реаутентификации IKE-сессии/Пороговое значение раннего рекеинга IPsec-сессии в килобайтах | 86400 |
Начало настройки IPsec заключается в настройке наборов криптографических алгоритмов для протокола IKE:
Создадим набор ключей аутентификации IKE. Поскольку в дальнейшей настройке планируется использовать в качестве идентификатора IPsec-соседа доменные имена, в наборе ключей тоже используются доменные имена:
Перейдем к созданию политики IKE. Она включает в себя наборы алгоритмов шифрования, выбор метода аутентификации и время жизни IKE-сессии (Phase 1):
Создадим набор криптошлюзов 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 можно объединить в общие VPN-профили. Как и при получении криптошлюзов IKE получим четыре IPsec VPN-профиля. Для IPsec VPN-профилей, использующихся на туннелях GRE в схеме DMVPN, обязательно включение транспортного режима:
Разрешим прохождение трафика, связанного с IPsec-туннелями. Для этого сначала опишем профили портов для протокола IKE и упакованного в UDP шифрованного трафика протоколов IKE и ESP:
Разрешим входящий трафик IPsec-туннелей для каждого из интернет-провайдеров (Firewall):
Пользовательский трафик запаковывается в протокол ESP, и, при наличии NAT посередине между IPsec-соседями, сообщения протокола ESP, в свою очередь, запаковываются в протокол UDP, порт 4500. Поскольку туннели между DMVPN Spoke могут подняться и без наличия NAT между ними, отдельным правилом разрешим прохождение ESP-пакетов.
Настройка mGRE-туннелей на DMVPN Spoke
Настроим туннели GRE в многоточечном режиме с поддержкой протокола NHRP на DMVPN Spoke. Поскольку в центральном офисе развернуто два DMVPN Hub на адресации двух разных интернет-провайдеров, подключение к ним будем осуществлять двумя отдельными mGRE-туннелями. Отличия настройки DMVPN Spoke с подключением к одному интернет-провайдеру заключается в том, что NBMA-адрес для каждого GRE-туннеля будет отличаться в зависимости от IP-адреса интерфейса к данному интернет-провайдеру. Основные параметры туннелей GRE для подключения обоим DMVPN Hub представлены в таблице 28.
Таблица 28. Параметры туннелей GRE на маршрутизаторе DMVPN Spoke дочернего офиса №5
| DMVPN Hub | DMVPN Cloud | Номер туннеля GRE | Туннельная адресация DMVPN Spoke | Туннельный адрес DMVPN Hub | NBMA-адрес DMVPN Hub | Ключ туннеля GRE | Время жизни NHRP-записей, секунды |
|---|---|---|---|---|---|---|---|
| RT-HUB-1 | ISP-CORE Cloud | 11 | 172.16.1.15/24 | 172.16.1.1 | 203.0.113.4 | 1000 | 600 |
| RT-HUB-2 | ISP-MODEM Cloud | 12 | 172.16.2.15/24 | 172.16.2.1 | 203.0.113.132 | 2000 | 600 |
Сначала изменим общие настройки туннеля GRE на каждом из DMVPN Hub. К таким настройкам относятся:
- режим работы multipoint;
- значение key;
- значение TTL;
- размер MTU;
- значение TCP adjust-mss;
- туннельный IP-адрес;
- интерфейс, с которого будет строиться GRE-туннель;
- имя транспортного VRF.
Маршрутизаторы DMVPN Spoke с точки зрения протокола NHRP выполняют роль NHRP-клиентов, которые после регистрации в облаке DMVPN на одном или нескольких DMVPN Hub могут запрашивать у них информацию о других членах облака DMVPN. В связи с этим для корректной работы DMVPN Spoke необходимо описать настройки протокола NHRP для подключения к обоим DMVPN Hub.
Для корректного построения Spoke-to-Spoke-туннелей, маршрутизация на которых направляет весь трафик на DMVPN Hub, включим опцию «ip nhrp shortcut». Опция активирует на DMVPN Spoke реагирование на специальные сообщения протокола NHRP «Traffic Indication», которые DMVPN Hub будет отправлять в ответ на пакеты, предназначенные другому DMVPN Spoke. Обработка такого сообщения приведет к построению Spoke-to-Spoke туннеля, и трафик между DMVPN Spoke будет проходить напрямую, минуя DMVPN Hub.
Такая схема организации маршрутизации и построения Spoke-to-Spoke туннелей в облаках DMVPN общепринято именуется третьей фазой DMVPN.
Следует учитывать, что пересоздание Spoke-to-Spoke туннелей инициируется только после истечения заданного параметра holding-time. Таким образом, при отказе интернет-провайдера и, соответственно, отсутствии связи с DMVPN Hub реконфигурация Spoke-to-Spoke туннеля резервному интернет-провайдеру произойдёт по завершении времени жизни (Expire time) соответствующего Spoke-to-Spoke туннеля.
Из-за особенностей декапсуляции трафика из IPsec-туннелей, работающих в транспортном режиме инкапсуляции, трафик после дешифровки попадает на тот же сетевой интерфейс, который терминирует IPsec-туннель. В связи с этим в правилах межсетевого экранирования на DMVPN Spoke необходимо разрешить прием не только шифрованных IPsec-пакетов, но и GRE-пакетов, которые попадают на интерфейс после дешифрования.
Для фильтрации трафика внутри облака DMVPN нужно создать отдельную зону безопасности и назначить её на GRE-туннели. Разрешите прохождение входящего ICMP-трафика в этой зоне:
Конфигурирование маршрутизации для функционирования облака DMVPN в центральном офисе
Настроим BGP-соседей в сторону DMVPN Hub:
В связи с тем, что DMVPN Spoke и DMVPN Hub находятся в разных автономных системах, анонсирование маршрутной информации по умолчанию проводиться не будет. Создадим route-map, разрешающий отправку маршрута до нашей локальной сети на DMVPN Hub. При распространении маршрутов по умолчанию они анонсируются с различными метриками, что обеспечивает выбор приоритетного направления. В случае недоступности второго интернет-провайдера, а значит и второго DMVPN Hub, переключение маршрутизации осуществляется за счёт механизма протокола BFD.
Созданный route-map указываем для семейства IPv4-маршрутов в созданных BGP-соседях. Также добавим локальную сеть в анонсируемые маршруты:
Включим поддержку BFD для созданных BGP-соседств. Учтем скорость сходимости IPsec- и mGRE-туннелей и увеличим BFD-таймеры:
Разрешим прохождение входящего трафика протокола BGP и BFD в зоне безопасности, настроенной на туннелях GRE:
Настройка Zone-Based Firewall для локальной сети
Поскольку теперь построенное облако DMVPN обеспечивает выход трафика локальных пользователей дочернего офиса через интернет-шлюз центрального офиса, необходимо произвести дополнительные настройки Firewall.
Разрешим прохождение транзитного трафика из локальной сети в сторону облака DMVPN:
На этом настройку DMVPN в дочернем офисе с резервированием канала можно считать завершенной.
Проверка коммуникации между офисами
Состояние облака DMVPN
При выполнении ранее описанных пунктов настройки DMVPN Hub и DMVPN Spoke получим следующую схему коммуникации между центральным и дочерними офисами:
Рисунок 10. Схема коммуникации между центральным и дочерними офисами на момент завершения настройки
В данной схеме построены два облака DMVPN, участники которых описаны в таблицах 29 и 30:
Таблица 29. Описание участников облака DMVPN Cloud 1
| Имя хоста | Роль в облаке DMVPN | Туннельный IP-адрес | NBMA IP-адрес | NAT-OA IP-адрес | Локальные сети | Тестовые хосты в локальных сетях |
|---|---|---|---|---|---|---|
| RT-HUB-1 | Hub | 172.16.1.1/24 | 203.0.113.4 | 10.0.0.2 | 10.100.0.0/24 | 10.100.0.10 |
| RT-OFFICE-1 | Spoke | 172.16.1.11/24 | 203.0.114.2 | -- | 192.168.11.0/24 | 192.168.11.10 |
| RT-OFFICE-2 | Spoke | 172.16.1.12/24 | 203.0.114.130 | -- | 192.168.12.0/24 | 192.168.12.10 |
| RT-OFFICE-3 | Spoke | 172.16.1.13/24 | 203.0.115.2 | 10.0.0.19 | 192.168.13.0/24 | 192.168.13.10 |
| RT-OFFICE-4 | Spoke | 172.16.1.14/24 | 203.10.0.2 | -- | 192.168.14.0/24 | 192.168.14.10 |
| RT-OFFICE-5 | Spoke | 172.16.1.15/24 | 203.11.1.2 | -- | 192.168.15.0/24 | 192.168.15.10 |
Таблица 30. Описание участников облака DMVPN Cloud 2
| Имя хоста | Роль в облаке DMVPN | Туннельный IP-адрес | NBMA IP-адрес | NAT-OA IP-адрес | Локальные сети | Тестовые хосты в локальных сетях |
|---|---|---|---|---|---|---|
| RT-HUB-2 | Hub | 172.16.2.1/24 | 203.0.113.132 | 10.0.0.10 | 10.100.0.0/24 | 10.100.0.10 |
| RT-OFFICE-1 | Spoke | 172.16.2.11/24 | 203.0.114.2 | -- | 192.168.11.0/24 | 192.168.11.10 |
| RT-OFFICE-2 | Spoke | 172.16.2.12/24 | 203.0.114.130 | -- | 192.168.12.0/24 | 192.168.12.10 |
| RT-OFFICE-3 | Spoke | 172.16.2.13/24 | 203.0.115.2 | 10.0.0.19 | 192.168.13.0/24 | 192.168.13.10 |
| RT-OFFICE-4 | Spoke | 172.16.2.14/24 | 203.10.1.2 | -- | 192.168.14.0/24 | 192.168.14.10 |
| RT-OFFICE-5 | Spoke | 172.16.2.15/24 | 203.11.2.2 | -- | 192.168.15.0/24 | 192.168.15.10 |
За счет настройки протокола BGP прохождение трафика через членов облака Cloud 1 является наиболее приоритетным.
Проверка сетевой связности локальных сетей между центральным и дочерними офисами
Для проверки сетевой связности локальных сетей между центральным и дочерними офисами отправим трафик с тестовых хостов дочерних офисов в сторону тестового хоста локальной сети центрального офиса:
Во всех четырех трассировках можно заметить, что трафик через пограничный маршрутизатор дочерних офисов и облако DMVPN Cloud 1 попадает на DMVPN Hub RT-HUB-1, затем попадает на пограничный маршрутизатор центрального офиса RT-GW-1, после чего достигает тестового хоста в локальной сети центрального офиса.
Проверим корректность прохождения трафика в обратном направлении:
В обратную сторону трафик следует тем же путем. Задача обеспечения связности центрального и дочерних офисов выполнена.
Проверка возможности выхода хостов дочерних офисов в сеть Интернет через интернет-шлюз центрального офиса
Для проверки возможности выхода хостов дочерних офисов в сеть Интернет через интернет-шлюз центрального офиса отправим трафик с тестовых хостов дочерних офисов на публичный ресурс в сети Интернет. В качестве такого ресурса выберем адрес Google Public DNS, используемый как цель для SLA-теста на маршрутизаторе центрального офиса RT-GW-1:
Во всех четырех трассировках можно заметить, что трафик через пограничный маршрутизатор дочерних офисов и облако DMVPN Cloud 1 попадает на DMVPN Hub RT-HUB-1, затем попадает на пограничный маршрутизатор центрального офиса RT-GW-1, откуда уже достигает публичного ресурса в сети Интернет. В случае с RT-OFFICE-4 при переключении на резервный канал трафик пойдет через резервного провайдера на RT-HUB-2.
Задача организации доступа хостов в дочерних офисах в сеть Интернет через пограничный маршрутизатор центрального офиса выполнена.
Проверка сетевой связности локальных сетей между дочерними офисами
Для проверки сетевой связности локальных сетей между дочерними офисами отправим трафик между тестовыми хостами в локальных сетях дочерних офисов.
Начнем с проверки связности между дочерними офисами №1 и №2:
Обратим внимание, что первая трассировка проходит через DMVPN Hub RT-HUB-1, что логично, ведь без построенного Spoke-to-Spoke туннеля между дочерними офисами трафик между офисами проходит через DMVPN Hub:
А после построения Spoke-to-Spoke туннеля появляется короткий маршрут напрямую в сторону Spoke-соседа:
Увидеть построение Spoke-to-Spoke туннеля можно в соответствующих командах на обоих DMVPN Spoke:
Поскольку туннель GRE между DMVPN Spoke защищен технологией IPsec, в show-командах можно еще убедиться в корректном построении Spoke-to-Spoke IPsec-туннеля:
Таким образом, задача организации прямой сетевой связности локальных сетей между дочерними офисами выполнена.
Поддержка и мониторинг
В рамках данного руководства на сервисных маршрутизаторах ESR настраивается ряд сервисов, обеспечивающих работу каналов связи между офисами. Рассмотрим конкретные команды просмотра оперативной информации, которые могут быть полезны при мониторинге и отладке собранной схемы сети.
Просмотр оперативной информации о состоянии модема
Команда «show cellular status modem» отображает состояние подключенных модемов. Команда «show cellular status modem 1» отображает детальную информацию о состоянии «1» сконфигурированного модема:
Просмотр оперативной информации о туннелях IPsec
Команда «show security ike proposal» отображает настроенные в конфигурации наборы криптографических алгоритмов, используемые при построении сессий протокола IKE. Указание имени набора отобразит более подробную информацию о содержимом набора:
Команда «show security ike policy» отображает настроенные в конфигурации политики IKE. Указание имени политики отобразит более подробную информацию о содержимом политики:
Команда «show security ike gateway» отображает настроенные в конфигурации криптошлюзы IKE. Указание имени криптошлюза отобразит более подробную информацию о настройках криптошлюза:
Команда «show security ipsec proposal» отображает настроенные в конфигурации наборы криптографических алгоритмов, используемые при построении сессий протоколов AH или ESP. Указание имени набора отобразит более подробную информацию о содержимом набора:
Команда «show security ipsec policy» отображает настроенные в конфигурации политики для сессии протоколов AH или ESP. Указание имени политики отобразит более подробную информацию о содержимом политики:
Команда «show security ipsec vpn configuration» отображает настроенные в конфигурации VPN-профили. Указание имени VPN-профиля отобразит более подробную информацию о настройках VPN-профиля:
Команда «show security ipsec vpn status» отображает активные IPsec-туннели. Указание имени VPN-профиля отобразит более подробную информацию об IPsec-туннелях, построенных на базе этого VPN-профиля. Для отображения активных туннелей в VRF необходимо добавить соответствующий модификатор:
Команда «show security ipsec vpn authentication» отображает для активных IPsec-туннелей селекторы трафика, которые должен попадать в туннель, и используемый механизм аутентификации. Для отображения информации об IPsec-туннелях в VRF необходимо добавить соответствующий модификатор:
Просмотр оперативной информации о туннелях GRE
Команда «show tunnels status» с модификатором «gre» отображает состояние настроенных в конфигурации туннелей GRE. Указание номера GRE-туннеля отобразит более подробную информацию о GRE-туннеле:
Команда «show tunnels configuration» с модификатором «gre» отображает параметры настроенных в конфигурации туннелей GRE. Указание номера GRE-туннеля отобразит более подробную информацию о GRE-туннеле:
Команда «show tunnels counters» с модификатором «gre» отображает счетчики настроенных в конфигурации туннелей GRE. Указание номера GRE-туннеля отобразит более подробную статистику о GRE-туннеле:
Просмотр оперативной информации о протоколе NHRP
Команда «show ip nhrp peers» отображает информацию об известных NHRP-соседях. Указание модификатора «detailed» отобразит более подробную информацию о NHRP-соседях:
Команда «show ip nhrp peers» отображает информацию о созданных временных маршрутах до локальных сетей за удаленным NHRP-соседом. Появление данных маршрутов возможно в третьей фазе DMVPN при построении Spoke-to-Spoke туннелей:
Команда «show ip route» с модификатором «nhrp» отображает все маршруты, добавленные в результате работы протокола NHRP:
Просмотр оперативной информации о протоколе BGP
Команда «show bgp summary» отображает краткую информацию об установленных BGP-соседствах, а также объемах анонсируемой и принимаемой маршрутной информации:
Команда «show bgp neighbors» отображает подробную информацию о BGP-соседях:
Команда «show bgp ipv4 unicast» отображает состояние RIB протокола BGP:
Команда «show bgp ipv4 unicast neighbor <IP-ADDRESS> routes» отображает принятые от BGP-соседа маршруты:
Команда «show bgp ipv4 unicast neighbor <IP-ADDRESS> advertise-routes» отображает анонсируемые BGP-соседу маршруты:
Команда «show ip route» с модификатором «bgp» отображает все маршруты, добавленные в результате работы протокола BGP:
Просмотр оперативной информации о протоколе BFD
Команда «show bfd neighbors» отображает актуальных BFD-соседей. Указание IP-адреса BFD-соседа отобразит более подробную информацию о BFD-соседе:
Просмотр оперативной информации о состоянии Zone-Based Firewall
Команда «show security zone» отображает список настроенных зон безопасности:
Команда «show security zone-pair» отображает список настроенных пар зон безопасности:
Команда «show security zone-pair configuration <LEFT> <RIGHT>» отображает список правил firewall для указанной пары зон безопасности:
Команда «show ip firewall counters» отображает статистику срабатывания правил firewall:
Команда «show ip firewall sessions» отображает список отслеживаемых firewall сетевых сессий:
Просмотр оперативной информации о состоянии NAT
Команда «show ip nat proxy-arp» отображает список интерфейсов, на которых включена функция ARP-proxy, и для каких IP-адресов она будет срабатывать:
Команда «show ip nat source pools» отображает список настроенных пулов IP-адресов и портов, используемых в правилах Source NAT:
Команда «show ip nat source rulesets» отображает список настроенных наборов правил Source NAT. Указание имени набора отобразит список правил Source NAT этого набора:
Команда «show ip nat translations» отображает список текущих отслеживаемых NAT-сессий:











%20%D1%87%D0%B5%D1%80%D0%B5%D0%B7%20%D1%81%D0%B5%D1%82%D0%B8%20%D0%B4%D0%B2%D1%83%D1%85%20%D0%B8%D0%BD%D1%82%D0%B5%D1%80%D0%BD%D0%B5%D1%82-%D0%BF%D1%80%D0%BE%D0%B2%D0%B0%D0%B9%D0%B4%D0%B5%D1%80%D0%BE%D0%B2.png)


