Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Технологии виртуальных частных сетей. Учебное пособие.pdf
X
- •ВВЕДЕНИЕ
- •1.1. ТЕХНОЛОГИИ ТУННЕЛИРОВАНИЯ
- •1.1.1. PPTP
- •1.1.2. L2TP/IPsec
- •1.1.3. SSTP
- •1.2. GRE
- •1.3. DMVPN
- •1.4. МНОГОТОЧЕЧНЫЙ GRE
- •1.6. IPSEC
- •1.7. ВАРИАНТЫ РЕАЛИЗАЦИИ МЕЖСАЙТОВЫХ VPN-РЕШЕНИЙ
- •1.7.1. Выбор топологии VPN для локальной сети
- •1.7.2. Выбор технологии VPN для глобальной сети
- •1.5. NHRP
- •2. GRE
- •2.1. GRE KEEPALIVES
- •2.2. IPSEC В ТУННЕЛЬНОМ И ТРАНСПОРТНОМ РЕЖИМАХ
- •2.3. КОНФИГУРАЦИЯ ПОЛИТИКИ ISAKMP
- •2.4. КОНФИГУРАЦИЯ СПИСКА КОНТРОЛЯ ДОСТУПА
- •2.5. КОНФИГУРАЦИЯ КРИПТОГРАФИЧЕСКОЙ КАРТЫ
- •2.6. ПРИМЕНЕНИЕ КРИПТОГРАФИЧЕСКИХ КАРТ
- •2.7. КОНФИГУРАЦИЯ GRE KEEPALIVE
- •2.8. КОНФИГУРАЦИЯ ПРОТОКОЛА МАРШРУТИЗАЦИИ
- •3. VTI VPN
- •3.1. ПЛАНИРОВАНИЕ VTI SITE-TO-SITE VPN
- •3.2. ВИРТУАЛЬНЫЕ ТУННЕЛЬНЫЕ ИНТЕРФЕЙСЫ
- •3.3. ЗАДАЧИ РАЗВЁРТЫВАНИЯ
- •3.4. ВАРИАНТЫ РАЗВЁРТЫВАНИЯ
- •3.5. ОБЩИЕ ПРИНЦИПЫ РАЗВЁРТЫВАНИЯ
- •3.7. IKE НА ОСНОВЕ PSK
- •3.7.1. Задачи конфигурации
- •3.7.2. Сценарий конфигурации
- •3.8. НАСТРОЙКА СТАТИЧЕСКИХ ТУННЕЛЕЙ IPSEC VTI
- •3.8.1. Задачи конфигурации
- •3.9. НАСТРОЙКА ДИНАМИЧЕСКИХ ТУННЕЛЕЙ IPSEC VTI
- •3.9.1. Виртуальные шаблоны и интерфейсы виртуального доступа
- •3.9.2. Профили ISAKMP
- •3.9.3. Задачи конфигурации
- •4. DMVPN
- •4.1. ЭЛЕМЕНТЫ DMVPN
- •4.2. НАЧАЛЬНОЕ СОСТОЯНИЕ DMVPN
- •4.3. СОЗДАНИЕ ТУННЕЛЯ SPOKE-TO-SPOKE DMVPN
- •4.4. ПРЕИМУЩЕСТВА И ОГРАНИЧЕНИЯ DMVPN
- •4.6. ПРИМЕР КОНФИГУРАЦИИ ТУННЕЛЯ «ТОЧКА–ТОЧКА»
- •4.7. ЗАДАЧИ КОНФИГУРАЦИИ ДЛЯ СЕТИ HUB-AND-SPOKE
- •4.7.1. Сценарий конфигурации
- •4.8. НАСТРОЙКА И ПРОВЕРКА КЛИЕНТА И СЕРВЕРА NHRP
- •4.8.1. Сценарий конфигурации
- •4.8.2. Отладка NHRP
- •4.9. НАСТРОЙКА И ПРОВЕРКА DMVPN НА HUB-МАРШРУТИЗАТОРЕ
- •4.9.1. Сценарий конфигурации
- •4.9.2. Проверка регистрации spoke
- •4.9.3. Детальная проверка регистрации spoke
- •4.10. НАСТРОЙКА И ПРОВЕРКА SPOKE-МАРШРУТИЗАТОРА DMVPN
- •4.11.1. Конфигурация EIGRP на hub-маршрутизаторе
- •4.11.2. Конфигурация OSPF на hub-маршрутизаторе
- •5. КОНЦЕПЦИЯ ИНФРАСТРУКТУРЫ ОТКРЫТЫХ КЛЮЧЕЙ
- •5.1. РУЧНОЙ ОБМЕН КЛЮЧАМИ С ПРОВЕРКОЙ
- •5.2. ДОВЕРЕННОЕ ВНЕДРЕНИЕ
- •5.3. ИНФРАСТРУКТУРА ОТКРЫТОГО КЛЮЧА: ЦЕНТРЫ СЕРТИФИКАЦИИ
- •5.4. СТАНДАРТ X.509
- •5.5. ПРОВЕРКА ОТЗЫВА СЕРТИФИКАТОВ
- •5.5.2. Online Certificate Status Protocol
- •5.7. ВАРИАНТЫ РАЗВЁРТЫВАНИЯ
- •5.8. ШАГИ РАЗВЁРТЫВАНИЯ
- •5.9. НАЧАЛО ПЛАНИРОВАНИЯ
- •5.12. СЦЕНАРИЙ КОНФИГУРАЦИИ
- •5.13. ВОЗМОЖНОСТИ КЛИЕНТА PKI
- •5.13.1. Простой протокол регистрации сертификатов
- •5.13.2. Хранение ключей
- •5.15. СЦЕНАРИЙ КОНФИГУРАЦИИ
- •5.17. УСТРАНЕНИЕ НЕИСПРАВНОСТЕЙ
- •5.18. НАСТРОЙКА И ПРОВЕРКА ИНТЕГРАЦИИ PKI ДЛЯ ЗАДАЧ VPN
- •5.20. СЦЕНАРИЙ КОНФИГУРАЦИИ
- •6. GET VPN
- •6.1. АУТЕНТИФИКАЦИЯ ПИРОВ
- •6.2. ОБМЕН ТРАФИКОМ В GET VPN
- •6.3. СЕРВИСЫ БЕЗОПАСНОСТИ
- •6.4. АРХИТЕКТУРА УПРАВЛЕНИЯ КЛЮЧАМИ
- •6.5. МЕТОДЫ ПЕРЕСОЗДАНИЯ КЛЮЧЕЙ
- •6.6. ИНКАПСУЛЯЦИЯ ТРАФИКА
- •6.8. ПЛАНИРОВАНИЕ РАЗВЁРТЫВАНИЯ IOS GET VPN
- •6.9. ЗАДАЧИ РАЗВЁРТЫВАНИЯ
- •6.10. ВАРИАНТЫ РАЗВЁРТЫВАНИЯ
- •6.11. РУКОВОДСТВО ПО РАЗВЁРТЫВАНИЮ
- •6.12. НАСТРОЙКА И ПРОВЕРКА ЧЛЕНОВ ГРУППЫ GET VPN
- •6.13. СЦЕНАРИЙ КОНФИГУРАЦИИ
- •6.14. УСТРАНЕНИЕ НЕПОЛАДОК
- •ЗАКЛЮЧЕНИЕ
- •СПИСОК ЛИТЕРАТУРЫ

Министерство науки и высшего образования Российской Федерации
Федеральное государственное бюджетное образовательное учреждение
высшего образования
«Тамбовский государственный технический университет»
А. И. ЕЛИСЕЕВ, Ю. В. МИНИН
ТЕХНОЛОГИИ ВИРТУАЛЬНЫХ
ЧАСТНЫХ СЕТЕЙ
Утверждено Учёным советом университета в качестве учебного пособия
для студентов 3–4 курсов направления подготовки 09.03.02 «Информационные
системы и технологии» очной и заочной формы обучения, 3 курса направления
подготовки 27.03.03 «Системный анализ и управление» очной и заочной формы
обучения, 2 курса направления подготовки 27.04.03 «Системный анализ и
управление» очной формы обучения, 3–4 курсов специальности
10.05.03 «Информационная безопасность автоматизированных систем»
очной формы обучения
Учебное электронное издание
Тамбов
• Издательский центр ФГБОУ ВО «ТГТУ» •
2019
1

УДК 004(075.8)
ББК
Á81я73Е-515
Е51
Р е ц е н з е н т ы:
Кандидат технических наук, профессор Института математики, естествознания
и информационных технологий ФГБОУ ВО «ТГУ им. Г. Р. Державина»
И. А. Зауголков
Доктор технических наук, профессор, заведующий кафедрой
информационных технологий управления
ФГБОУ ВО «ВГУ»
М. Г. Матвеев
Е51 Технологии виртуальных частных сетей [Электронный ресурс] : учебное пособие /
Основное внимание уделено анализу технологий виртуальных частных сетей,
Елисеев, А. И.
А. И. Елисеев, Ю. В. Минин. – Тамбов : Издательский центр ФГБОУ ВО «ТГТУ»,
2019. – 1 электрон. опт. диск (CD-ROM). – Системные требования : ПК не ниже класса
Pentium II ; CD-ROM-дисковод ; 28,0 Mb ; RAM ; Windows 95/98/XP ; мышь. – Загл.
с экрана.
ISBN 978-5-8265-2091-8
используемых для построения VPN-сетей типа Site-to-Site, даётся подробное описание их топологии. Рассматривается практическая реализация статических и динамических виртуальных туннелей с частично связанной и полносвязанной топологиями,
использующих технологии GRE, IPsec, IPsec VTI, DMVPN, GET VPN. Отдельное
внимание уделяется масштабированию VPN-решений за счёт применения центров
аутентификации.
Предназначено для студентов 3–4 курсов направления подготовки 09.03.02 «Информационные системы и технологии» очной и заочной формы обучения, 3 курса
правления подготовки 27.03.03 «Системный анализ и управление» очной и заочной
формы обучения, 2 курса направления подготовки 27.04.03 «Системный анализ и
управление» очной формы обучения, 3–4 курсов специальности 10.05.03 «Информационная безопасность автоматизированных систем» очной формы обучения.
на-
УДК 004(075.8)
ББК
Á81я73Е-515
Все права на размножение и распространение в любой форме остаются за разработчиком.
Нелегальное копирование и использование данного продукта запрещено.
ISBN 978-5-8265-2091-8
2
© Федеральное государственное бюджетное образовательное
учреждение высшего образования «Тамбовский
государственный технический университет»
(ФГБОУ ВО «ТГТУ»), 2019

ВВЕДЕНИЕ
Обеспечение безопасности представляет собой одну из важнейших задач,
возникающих при использовании сетевых технологий. Для защиты данных при
их передаче через открытые сети используются технологии виртуальных частных сетей (VPN – Virtual Private Networks). VPN применяется для создания частного туннеля поверх сети общего доступа. Для защиты данных от несанкционированного доступа можно использовать решения по шифрованию данных в
туннеле, а также аутентификацию.
Основное внимание уделено анализу технологий виртуальных частных сетей, используемых для построения VPN-сетей типа Site-to-Site, даётся подробное описание топологий, используемых при реализации виртуальных частных
сетей такого типа.
В первой главе описываются технологии туннелирования трафика и приводится обзор технологий, которые возможно использовать для реализации сетей VPN.
Во второй главе описаны детали использования протокола туннелирования
сетевых пакетов GRE для совместного использования с фреймворком IPsec.
В третьей главе рассматривается развёртывание статических и динамических туннелей VTI «точка–точка» с использованием программного обеспечения
Cisco IOS и фреймворка IPsec. Интерфейсы виртуальных туннелей IPsec значительно упрощают процесс настройки, необходимый для создания VPN-туннелей между сайтами.
Четвёртая глава посвящена изучению технологии DMVPN, которая упрощает развёртывание крупных топологий VPN с частично связной и полносвязной топологиями за счёт использования решений mGRE и NHRP. В этой главе
приводится реализация технологии DMVPN на устройствах с программным
обеспечением Cisco IOS.
В пятой главе речь идёт о развёртывании масштабируемой аутентификации в сетях IPsec VPN. Такая функциональность позволяет строить масштабируемые и легко управляемые корпоративные VPN-решения.
В шестой главе рассматривается процесс развёртывания технологии виртуальной частной сети GET VPN. Это современное решение компании Cisco, которое позволяет легко разворачивать сложную, избыточную, полносвязную
сеть VPN.
3

1. ОБЗОР ТЕХНОЛОГИЙ ВИРТУАЛЬНЫХ ЧАСТНЫХ СЕТЕЙ
Механизм туннелирования позволяет инкапсулировать пакет из одного
типа протокола в блоки данных другого (PDU) протокола. Используя технологии туннелирования, можно реализовать VPN-решение на основе туннельного
протокола типа «точка–точка» (PPTP), протокола туннелирования второго
уровня (L2TP), протокола туннелирования защищённого сокета (SSTP) или защищённого протокола IP (IPsec) с помощью Internet Key Exchange версии 2
(IKEv2).
Решения PPTP, L2TP и SSTP сильно зависят от функций, первоначально
реализованных для двухточечного протокола канального уровня Point-to-Point
Protocol (PPP). Протокол PPP был разработан для пер
мутируемые или выделенные соединения «точка–точка». Для передачи трафика
IP протокол PPP инкапсулирует IP-пакеты внутрь кадров PPP и затем передаёт
инкапсулированные PPP-пакеты по двухточечному каналу. Первоначально PPP
определялся как протокол для использования между клиентом удалённого доступа и сервером доступа к сети. В отличие от других типов туннелей, протокол
IKEv2 не работает поверх PPP.
Протокол Point-to-Point Tunneling Protocol (PPTP) позволяет шифровать
многопротокольный трафик и затем инкапсулировать его в IP-пакет, который
затем может быть отправлен через любую IP-сеть, в том числе и общедоступную. Протокол PPTP можно использовать для организации удалённого доступа
и VPN-соединений «точка–точка». При использовании Интернета в качестве
общедоступной сети VPN-сервером PPTP может быть любой сервер с поддержкой протокола PPTP, у которого оди
рой интерфейс находится в интрасети.
Протокол PPTP выполняет инкапсуляцию PPP-кадров в IP-пакеты для передачи их по сети. PPTP использует TCP-соединение для управления туннелями и модифицированную версию протокола Generic Routing Encapsulation
(GRE) для инкапсуляции кадров PPP при решении задачи туннелированния
данных. Полезная нагрузка инкапсулированных кадров PPP может быть зашифрована, сж
структура PPTP-пакета.
1.1. ТЕХНОЛОГИИ ТУННЕЛИРОВАНИЯ
едачи данных через ком-
1.1.1. PPTP
н интерфейс находится в Интернете, а вто-
ата или и то, и другое одновременно. На рисунке 1.1 показана
4
Рис. 1.1. Структура PPTP-пакета

Кадр PPP зашифровывается с помощью протокола Microsoft Point-to-Point
Encryption (MPPE) с использованием ключей шифрования, сгенерированных с
помощью протокола Microsoft Challenge Handshake Authentication Protocol
(MS-CHAP v2) или процесса аутентификации Extensible Authentication ProtocolTransport Layer Security (EAP-TLS).
Протокол PPTP использует базовое шифрование PPP и инкапсулирует
ранее зашифрованный PPP-фрейм в IP-пакет. В PPTP поддерживается только
128-битный алгоритм шифрования RC4. 40- и 56-битная поддержка RC4 были
удалены из протокола, начиная с версий ОС Windows Vista и Windows Server
2008.
1.1.2. L2TP/IPsec
Механизм L2TP/IPsec позволяет шифровать многопротокольный трафик,
а затем отправлять в любую среду, поддерживающую доставку «точка–точка»,
например сеть IP. L2TP – это комбинация протокола PPTP и технологии Layer 2
Forwarding (L2F), разработанной компанией Cisco. Протокол L2TP представляет собой улучшение функций и PPTP, и L2F.
В отличие от PPTP, реализация L2TP не использует протокол MPPE для
шифрования передаваемых кадров PPP. L2TP использует фреймворк IPsec в
режиме транспорта для служб шифрования. Комбинация L2TP и IP
sec известна
как L2TP/IPsec.
Оба механизма L2TP и IPsec должны поддерживаться как клиентом VPN,
так и VPN-сервером. Клиентская поддержка L2TP встроена в клиенты удалённого доступа настольных операционных систем, а поддержка VPN-сервера для
протокола L2TP встроена в серверные операционные системы.
Инкапсуляция для пакетов L2TP/IPsec состоит из двух слоев. Первый
слой – инкапсуляция L2TP. Кадр PPP обёрнут заголовком L2TP и заголовком
UDP.
На рисунке 1.2 показана структура пакета L2TP
, содержащего IP-пакет.
Второй уровень инкапсуляции – инкапсуляция IPsec. Полученное сообщение L2TP обёрнуто заголовком и трейлером протокола Encapsulating Security
Payload (ESP) и трейлером аутентификации IPsec, который обеспечивает
целостность и аутентификацию сообщений и окончательный IP-заголовок.
В IP-заголовке IP-адрес источника и получателя соответствует адресам VPNклиента и VPN-сервера.
Рис. 1.2. Структура L2TP-пакета
5

Рис. 1.3. Инкапсуляция L2TP и IPsec
На рисунке 1.3 показана инкапсуляция L2TP и IPsec для дейтаграммы PPP.
Сообщение L2TP зашифровывается одним из следующих алгоритмов с
использованием ключей шифрования, сгенерированных в процессе согласования IKE: алгоритмы шифрования Advanced Encryption Standard (AES) 256, AES
192, AES 128 и 3DES.
1.1.3. SSTP
Протокол туннелирования Secure Socket (SSTP) – это протокол туннелирования, который использует протокол HTTPS и 443-й TCP-порт для передачи
трафика через файерволы и прокси-серверы, которые потенциально могут блокировать трафик протоколов PPTP и L2TP/IPsec. SSTP предоставляет механизм
для инкапсуляции трафика PPP по каналу Secure Sockets Layer (SSL) протокола
HTTPS. Использование протокола PPP позволяет поддерживать надёжные методы аутентификации, такие как EAP-TLS. SSL обеспечивает безопасность на
уровне транспорта с расши
ренным согласованием ключей, шифрованием и
проверкой целостности.
Когда клиент пытается установить VPN-соединение на основе протокола
SSTP, SSTP сначала устанавливает двунаправленный HTTPS-канал с сервером
SSTP. На этом уровне пакеты протоколов передаются как полезная нагрузка
данных HTTPS.
Протокол SSTP инкапсулирует PPP-кадры в IP-пакеты для передачи их по
сети. SSTP использует TCP-соединение (через порт 443) для управления туннелями, а так
же кадры данных PPP. А затем сообщения SSTP зашифровываются
каналом SSL протокола HTTPS.
1.2. GRE
Как следует из названия, протокол Generic Routing Encapsulation (GRE)
может инкапсулировать почти все типы данных, которые могут быть отправлены через физический интерфейс маршрутизатора. Фактически GRE может инкапсулировать любой протокол уровня 3, что делает его универсальным.
Протокол GRE сам по себе не обеспечивает решения задачи безопасной
передачи данных. Однако GRE-пакет может быть отправлен через сеть IPsec
VPN, что приведёт к защит
е пакета GRE (и, следовательно, его содержимого).
6

Такая конфигурация довольно часто используется, поскольку фреймворк IPsec
может передавать только одноадресные (unicast) IP-пакеты. Такое ограничение
вызывает проблемы с протоколами маршрутизации, использующими многоадресную рассылку. К счастью, туннель GRE способен инкапсулировать многоадресные пакеты IP. Итоговый пакет GRE представляет собой одноадресный
IP-пакет, который затем может будет защищён туннелем IPsec.
В качестве примера рассмотрим рис. 1.4. Маршрутизаторы R1 и R2 должны установить отношения смежност
и в протоколе Open Shortest Path First
(OSPF) через сеть поставщика услуг. Кроме того, трафик между этими двумя
маршрутизаторами должен быть защищён. Хотя IPsec может защитить одноадресный IP-трафик, OSPF обменивается данными с использованием групповых
IP-адресов. Следовательно, весь трафик между маршрутизаторами R1 и R2
(включая многоадресный трафик OSPF) инкапсулируется внутрь туннеля GRE.
Рис. 1.4. Схема туннелирования GRE
Ниже приведены шаги по настройке туннеля GRE:
Шаг 1. Создайте виртуальный интерфейс туннеля в режиме глобальной
конфигурации с помощью команды interface tunnel id.
Шаг 2. В режиме конфигурации интерфейса туннеля добавьте IP-адрес с
помощью команды ip address ip_address subnet_mask.
Шаг 3. Укажите источник туннеля с помощью команды tunnel source
{interface_id | ip address}.
Шаг 4. Укажите место назначения туннеля с помощью команды tunnel
destination ip_address.
Шаг 5. Повторите предыдущие шаги на маршрутизаторе на другой сторо-
не туннеля.
Чтобы проиллюстрировать процедуру настройки, рассмотрим показан-
ную на рис. 1.5 топологию.
Настройка туннеля на маршрутизаторе R1:
interface Tunnel1
ip address 192.168.0.1 255.255.255.252
tunnel source Loopback0
tunnel destination 4.4.4.4
7

Рис. 1.5. Схема тестовой топологии
Настройка туннеля на маршрутизаторе R4:
Interface Tunnel1
ip address 192.168.0.2 255.255.255.252
tunnel source Loopback0
tunnel destination 1.1.1.1
В примере выше на маршрутизаторе R1 с помощью команды interface
Tunnel 1 создаётся виртуальный интерфейс туннеля. Затем назначается IP-адрес
с помощью команды ip address 192.168.0.1 255.255.255.252. Затем используется
команда tunnel source Loopback0 для указания интерфейса Loopback0 маршрутизатора R1 (и, следовательно, и его IP-адреса 1.1.1.1) в качестве одного из
концов туннеля GRE. Затем команда tunnel destination 4.4.4.4 используется для
указания интерфейса Loopback0 на маршрутизаторе R4 в качестве другого конца туннеля. На маршрутизаторе R4 выполняется зерк
альная конфигурация ин-
терфейса туннеля.
В примере ниже показана проверка туннеля GRE. В выводе команды
show interfaces tunnel 1 обратите вниманиена то, что интерфейс работает на
уровне 1 и 2 модели OSI. Также обратите внимание, что указан тип инкапсуляции TUNNEL. Кроме того, вывод команды traceroute 192.168.0.2 показывает,
что IP-адрес 192.168.0.2 логически является единственным хопом от маршрутизатора R1, хотя он физически находится на удалении трёх хопов:
R1# show interfaces tunnel 1
Tunnel1 is up, line protocol is up
Hardware is Tunnel
Internet address is 192.168.0.1/30
MTU 17916 bytes, BW 100 Kbit/sec, DLY 50000 usec,
reliability 255/255, txload 1/255, rxload 1/255
Encapsulation TUNNEL , loopback not set
Keepalive not set
Tunnel source 1.1.1.1 (Loopback0), destination 4.4.4.4
Tunnel Subblocks:
src-track:
Tunnel1 source tracking subblock associated with Loopback0
Set of tunnels with source Loopback0, 1 member (includes iterators), on
interface <OK>
Tunnel protocol/transport GRE/IP
Key disabled, sequencing disabled
8

Checksumming of packets disabled
Tunnel TTL 255, Fast tunneling enabled
Tunnel transport MTU 1476 bytes
Tunnel transmit bandwidth 8000 (kbps)
Tunnel receive bandwidth 8000 (kbps)
Last input 00:00:01, output 00:00:01, output hang never
Last clearing of "show interface" counters 00:54:43
Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
Queueing strategy: fifo
Output queue: 0/0 (size/max)
5 minute input rate 0 bits/sec, 0 packets/sec
5 minute output rate 0 bits/sec, 0 packets/sec
779 packets input, 67357 bytes, 0 no buffer
Received 0 broadcasts (0 IP multicasts)
0 runts, 0 giants, 0 throttles
0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored, 0 abort
787 packets output, 68037 bytes, 0 underruns
0 output errors, 0 collisions, 0 interface resets
0 unknown protocol drops
0 output buffer failures, 0 output buffers swapped out
R1# traceroute 192.168.0.2
Type escape sequence to abort.
Tracing the route to 192.168.0.2
VRF info: (vrf in name/id, vrf out name/id)
1 192.168.0.2 108 msec 100 msec 108 msec
1.3. DMVPN
Рассмотрим сеть VPN с топологией hub-and-spoke, в которой несколько
удалённых cетей (сайт, site) имеют VPN-соединение типа «точка–точка» (pointto-point) с центральным офисом. В такой топологии, если один удалённый сайт
хочет безопасно связываться с другим удалённым сайтом, трафик будет передаваться между сайтами через центральный офис, а не напрямую между сайтами. Одним из решений данной проблемы являет
ся создание полносвязной (fullmesh) сети VPN-соединений IPsec типа site-to-site, которая обеспечивала бы
прямое VPN-соединение IPsec между любыми двумя удалёнными сайтами. Однако такое решение может быть сложным и дорогостоящим в плане настройки
и обслуживания.
Более экономичным решением, не требующим топологии full-mesh, является технология Dynamic Multipoint VPN (DMVPN). Технология DMVPN позволяет динамически создавать туннели VPN между двумя удалёнными сайтами и разрывать их по мере необходим
ости. Рассмотрим пример ниже, в котором показана топология hub-and-spoke (рис. 1.6). Причём центральный офис
выступает в качестве hub-маршрутизатора. Как только офисы B и C инициируют передачу данных друг другу, между этими двумя участниками обмена данными создаётся туннель DMVPN.
С точки зрения устранения неполадок общая проблема, возникающая в
сетях DMVPN, – это проблема «схлопывания» (flapping) (т.е. туннели DMVP
N
неоднократно обрываются и восстанавливаются).
9

Рис. 1.6. Схема тестовой топологии hub-and-spoke
При возникновении такой проблемы рекомендуется проверить отношение
смежности в протоколе маршрутизации между маршрутизаторами на каждом
конце туннеля DMVPN. Если состояние смежности не установлено, туннель
DMVPN может оборваться.
1.4. МНОГОТОЧЕЧНЫЙ GRE
Масштабируемость, присущая технологии DMVPN, стала возможной, в
частности, благодаря многоточечному варианту протокола GRE (Multipoint
GRE, mGRE), который позволяет маршрутизатору поддерживать несколько
туннелей GRE на одном GRE-интерфейсе.
Некоторые особенности mGRE:
− подобно традиционному протоколу GRE, mGRE может передавать
широкий спектр протоколов (например, одноадресный, многоадресный и широковещательный IP-трафик);
10
Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]
