Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Технологии виртуальных частных сетей. Учебное пособие.pdf
− в топологии hub-and-spoke hub-маршрутизатор может иметь один ин-
терфейс mGRE, и несколько туннелей могут одновременно использовать этот
единственный интерфейс;
− интерфейс, сконфигурированный для mGRE, способен динамически
формировать туннель GRE, используя протокол разрешения следующего хопа
Next Hop Resolution Protocol (NHRP) для обнаружения IP-адреса устройства на
противоположной стороне туннеля.
Можно развернуть протокол mGRE в топологии hub-and-spoke или spoke-
to-spoke.
На рисунке 1.7 показана топология hub-and-spoke, где hub-маршрутизатор
настроен с использованием инте
рфейса mGRE.
На рисунке 1.8 показана топология mGRE типа spoke-to-spoke. С топологией mGRE типа spoke-to-spoke каждый маршрутизатор имеет интерфейс
mGRE, который позволяет сайтам в сети соединяться с использованием частично связной или полносвязной сети туннелей.
Рис. 1.7. Схема тестовой топологии mGRE hub-and-spoke
11
Рис. 1.8. Схема тестовой топологии mGRE spoke-to-spoke
1.5. NHRP
Технология DMVPN требует, чтобы маршрутизаторы запускали протокол
разрешения следующего хопа Next Hop Resolution Protocol (NHRP), который
использует модель клиент-сервер. Маршрутизатор, назначенный как hub-маршрутизатор, действует в роли сервера. Остальные маршрутизаторы, называемые
spoke, действуют как клиенты. На spoke-маршрутизаторах NHRP сконфигурирован с IP-адресом hab-маршрутизатора NHRP. Когда маршрутизатор spoke
включён, он информирует hub как о физическом IP-адресе (назначенном его
физическому интерфейсу), так и о логическо
м IP-адресе (назначенном его виртуальному туннельному интерфейсу). Оба этих адреса будут использоваться
для построения туннелей.
На рисунке 1.9 маршрутизатор центрального офиса выступает в роли hubмаршрутизатора, а маршрутизаторы Branch A, Branch B и Branch C действуют
как spoke-маршрутизаторы. Когда устройства с ролью spoke появляются в сети,
каждый из них рассылает информацию об IP-адресе своего физического интерфейса, который будет использоваться для формирования туннеля, а та
кже об
IP-адресе интерфейса виртуального туннеля. Например: маршрутизатор Branch A
сообщает маршрутизатору центрального офиса, что IP-адрес его виртуального
12
Рис. 1.9. Заполнение базы данных NHRP
туннельного интерфейса 10.0.0.1, и он доступен по IP-адресу физического интерфейса 192.0.2.1. Маршрутизаторы Branch B и Branch C отправляют аналогичные данные маршрутизатору центрального офиса. В результате маршрутизатор центрального офиса заполняет базу данных NHRP (NHRP data base).
Когда база данных hub-устройства заполнена, spoke может запросить у
hub-маршрутизатора IP-адрес физического интерфейса, который соответствует
IP-адресу конкретного туннельного интерфейса. В качестве примера обратите
внимание на ситуацию, когда прот
окол NHRP помогает маршрутизатору Branch C
построить туннель GRE с маршрутизатором Branch B.
На рисунке 1.10 маршрутизатору Branch C необходимо динамически
сформировать туннель GRE с маршрутизатором Branch B. Маршрутизатор
Branch C знает, что другой конец туннеля, который должен быть в итоге сформирован, имеет IP-адрес 10.0.0.2. Однако маршрутизатор Branch C не знает
IP-адрес физического интерфейса маршрутизатора Branch B, который соответствует IP-адресу виртуального туннеля. Процесс обнаруж
ения удалённого фи-
зического IP-адреса и формирования туннеля заключается в следующем.
Шаг 1. Маршрутизатор Branch C отправляет запрос NHRP hub-маршрутизатору с целью узнать IP-адрес физического интерфейса, связанного с IP-адресом интерфейса туннеля 10.0.0.2.
13
Рис. 1.10. Схема работы протокола NHRP
Шаг 2. Hub-маршрутизатор (т.е. маршрутизатор центрального офиса)
проверяет свою базу данных NHRP и отвечает на запрос, сообщая маршрутизатору Branch C, что IP-адрес физического интерфейса, соответствующий IP-адресу интерфейса туннеля 10.0.0.2 – 203.0.113.1 (IP-адрес маршрутизатора
Branch B).
Шаг 3. Узнав IP-адрес физического интерфейса на маршрутизаторе
Branch B, маршрутизатор Branch C устанавливает туннель GRE с маршрутиза-
тором Branch B.
Пример ниже показывает пример вывода команды show ip nhrp:
Router# show ip nhrp
192.168.0.2 255.255.255.255 , tunnel 100 created 0:00:44 expire 1:59:15
Type: dynamic Flags: authoritative
NBMA address: 10.1111.1111.1111.1111.1111.1111.1111.1111.1111.11
192.168.0.1 255.255.255.255 , Tunnel10 created 0:10:04 expire 1:49:56
Type: static Flags: authoritative
NBMA address: 192.168.1.2
Вывод в примере выше демонстрирует IP-адреса (и соответствующие
маски подсетей) в кеше адресов IP-NBMA (Non-Broadcast Multiple Access). Обратите внимание, что маска подсети для IP-адреса всегда является равной /32,
потому что реализация Cisco NHRP не поддерживает агрегирование информа-
14
ции о множественном доступе. В выводе также отображается имя интерфейса
туннеля и время его существования. Наконец, обратите внимание на флаг
authoritative. Этот флаг указывает, что именно маршрутизатор следующего перехода (next-hop) предоставил информацию NHRP.
1.6. IPSEC
Безопасность в сетях DMVPN обеспечивается фреймворком IPsec. IPsec
предлагает следующие четыре функции безопасности:
− конфиденциальность – конфиденциальность данных обеспечивается
путём шифрования. Если третья сторона перехватит зашифрованные данные,
она не сможет их правильно интерпретировать;
− целостность. Механизмы обеспечения целостности данных гаран-
тирует, что данные не будут изменены при передаче. Например, маршрутизаторы на концах туннеля могут вычислят
ь значение контрольной суммы или хешдайджест данных, и, если оба маршрутизатора получат одно и то же значение,
данные, скорее всего, не были изменены при передаче;
− аутентификация. Механизмы аутентификации позволяют сторонам,
участвующим в передаче данных, проверять, является ли другая сторона стороной той, за которую себя выдаёт;
− защита от повторов. Фреймворк IPsec использует защиту от повто-
ров в целях обеспечения гарантии, что отправленные пакеты не являютс
я повторными. Например, злоумышленник может захватить пакеты, которые содержат данные об учётной записи хоста, и попытаться повторить отправку этих
пакетов, чтобы получить доступ к хосту. Однако IPsec использует порядковые
номера пакетов для определения того, не был ли пакет продублирован. Люб
ые
дублированные пакеты не обрабатываются.
Из этих функций безопасности IPsec особенно полезны в сети DMVPN
шифрование и аутентификация. Например, шифрование может помочь защитить трафик между сайтами (при передаче его через Интернет или через сеть
поставщика услуг). Кроме того, аутентификация может гарантировать, что туннели GRE не будут динамически построены с неизвестными spoke-маршрутизаторами.
Фреймвор
к IPsec использует целый набор протоколов для реализации
своих функций. Одним из ключевых протоколов, используемых IPsec, является
протокол Internet Key Exchange (IKE). В частности, IPsec может обеспечивать
шифрование данных между аутентифицированными пирами с использованием
ключевой информации, которая периодически меняется. Однако IKE также позволяет администратору вручную настраивать заранее определённые ключи
(Preshared Key, PSK).
Существуют два этапа создания туннеля IPsec. Во время первого – IKE
Phase 1 – устанав
ливается безопасная сессия протокола Internet Security Associa-
tion and Key Management Protocol (ISAKMP). В рамках этого этапа пиры IPsec
согласуют набор преобразований (transform sets) (т.е. набор протоколов шифрования и аутентификации), хеш-функции и другие параметры, необходимые для
15
установления безопасного сеанса ISAKMP (иногда называемого туннелем
ISAKMP или туннелем IKE Phase 1). Этот набор параметров называется ассо-
циацией безопасности (security association, SA). IKE Phase 1 SA является двунаправленной, так как передача данных по туннелю происходит в обоих направлениях.
Второй этап – IKE Phase 2 – происходит в рамках защищённого туннеля
IKE Phase 1. Сессию, сформированную в ходе IKE Phase 2, иногда называют
туннелем IKE Phase 2 или просто туннелем IPsec. Однако, в отличие от IKE
Phase 1, IKE Phase 2 формирует однонаправленные SA. Это означает, что в каждом потоке данных используется ра
зный обмен ключами.
В дополнение к IKE, который формирует туннель IPsec, IPsec также использует либо протокол Authentication Header (AH) (IP-протокол № 51), либо
протокол Encapsulating Security Payload (ESP) (IP-протокол № 50). Как AH, так
и ESP реализуют функции аутентификации и целостности.
Однако основное различие между AH и ESP – поддержка шифрования.
ESP шифрует исходный пакет, в то время как AH не предлагает никакого шифрования. В результате ESP гораздо более популярен в современных сетях передачи данных.
Оба протокола AH и ESP могут работать в одном из двух ре
жимов:
в транспортном режиме (transport mode) или в режиме туннеля (tunnel mode).
На рисунке 1.11 показана структура пакета транспортного режима в ESP в
сравнении с пакетом в режиме туннеля в ESP.
Ниже приводится подробное описание этих двух режимов:
− режим транспорт
а. В режиме транспорта используется исходный IP-
заголовок пакета без добавления дополнительного заголовка туннеля. Такой
подход хорошо работает в сетях, где увеличение размера пакета может вызвать
проблему. Кроме того, транспортный режим часто используется для VPN-соединений между клиентами, где ПК с клиентским ПО VPN подключается к устройству терминирования VPN в главном офисе;
– режим туннеля. Режим туннеля, в отличие от режима транспортного,
инкапсулирует весь пакет. В результате инкапсу
заголовок (т.е. заголовок IPsec). Этот новый заголовок содержит
лированный пакет имеет новый
Рис. 1.11. Сравнение структур пакетов в транспортном и туннельном режимах
16
Рис. 1.12. Схема работы туннеля IPsec
информацию о IP-адресе источника и получателя, которая принадлежит двум
устройствам терминирования VPN обоих сайтов. Таким образом, туннельный
режим часто используется в VPN-сетях типа site-to-site.
Процесс установления, поддержания и разрыва IPsec-туннеля для межсайтового VPN состоит из пяти основных этапов, показанных на рис. 1.12.
Шаг 1. PC1 отправляет трафик, предназначенный для PC2. Маршрутизатор R1 классифицирует трафик как «полезный» трафик, который инициирует
создание туннеля I
Psec.
Шаг 2. R1 и R2 согласуют ассоциацию безопасности (SA), используемую
для формирования туннеля IKE фазы 1, который также известен как туннель
ISAKMP.
Шаг 3. В рамках защиты туннелем IKE Phase 1 согласовывается и настраивается туннель IKE Phase 2. Туннель IKE Phase 2 также известен как туннель IPsec.
Шаг 4. После того как туннель IPsec сформирован, через защищённый
туннель IPsec проходит полезный трафик (например, трафик, классифицированный ACL). Обратите внимание, что трафик, который не считается полезным,
всё ра
вно может быть передан между PC1 и PC2. Однако «неполезный» трафик
передаётся за пределами туннеля IPsec.
Шаг 5. Если полезный трафик не передаётся в течение определённого
времени, или если IPsec SA был удалён, происходит разрыв туннеля IPsec.
Ниже показан вывод команды show crypto ipsec sa, которая позволяет
получить информацию о SA, согласов
анной между пирами IPsec:
17
R1# show crypto ipsec sa
interface: FastEthernet0/0
Crypto map tag: test, local addr. 30.1.1.1
local ident (addr/mask/prot/port): ( 20.1.1.0/255.255.255.0 /0/0)
remote ident (addr/mask/prot/port): ( 10.1.1.0/255.255.255.0 /0/0)
current_peer: 30.1.1.2
PERMIT, flags={origin_is_acl,}
#pkts encaps: 7647918, #pkts encrypt: 7647918, #pkts digest 7647918
#pkts decaps: 7640382, #pkts decrypt: 7640382, #pkts verify 7640382
#pkts compressed: 0, #pkts decompressed: 0
#pkts not compressed: 0, #pkts compr. failed: 0,
#pkts decompress failed: 0, #send errors 1, #recv errors 0
local crypto endpt.: 30.1.1.1, remote crypto endpt.: 30.1.1.2
path mtu 1500, media mtu 1500
current outbound spi: 3D3
inbound esp sas:
spi: 0x136A010F(325714191)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 3442, flow_id: 1443, crypto map: test
sa timing: remaining key lifetime (k/sec): (4608000/52)
IV size: 8 bytes
replay detection support: Y
inbound ah sas:
inbound pcp sas:
inbound pcp sas:
outbound esp sas:
spi: 0x3D3(979)
transform: esp-3des esp-md5-hmac ,
in use settings ={Tunnel, }
slot: 0, conn id: 3443, flow_id: 1444, crypto map: test
sa timing: remaining key lifetime (k/sec): (4608000/52)
IV size: 8 bytes
replay detection support: Y
outbound ah sas:
outbound pcp sas:
В рассмотренном примере туннель IPsec формируется между пирами
30.1.1.1 и 30.1.1.2. Туннель реализуется между сетями 10.1.1.0/24 и 20.1.1.0/24.
ACL используется для идентификации (т.е. разрешения) трафика, который
должен быть отправлен через туннель IPsec. Для шифрования используется
протокол Encapsulating Security Payload (ESP) с шифрованием Triple Data
Encryption Standard (3DES), а для аутентификации используется алгоритм
Message Digest 5 (MD5).
1.7. ВАРИАНТЫ РЕАЛИЗАЦИИ МЕЖСАЙТОВЫХ VPN-РЕШЕНИЙ
Межсетевые VPN-соединения (site-to-site) являются популярным способом обеспечения безопасной связи между сетями. Безопасность важна при передаче данных по общедоступным сетям, и фреймворк IPsec обеспечивает защиту конфиденциальных данных. При проектировании архитектур межсетевых
VPN-решений необходимо предусмотреть несколько вариантов реализации,
в том числе следующие:
18
− выбор подходящей топологии VPN LAN;
− выбор подходящей технологии VPN WAN;
− выбор криптограф
ических элементов VPN.
Физическая топология представляет способ соединения узлов в сети с целью организации передачи данных. Сетевые топологии VPN-решений не зависят от того, как выглядит физическая топология, а физическая топология не
влияет на возможности VPN.
Для создания VPN-соединений используются четыре типовые VPN-топологии:
1) одноранговое VPN-соединение «точка–точка» (P2P): два узла соеди-
1.7.1. Выбор топологии VPN для локальной сети
няются друг с другом с использованием технологий VPN. Каждое соединен
ие
между двумя сайтами требует ручного создания VPN-соединения;
2) hub-and-spoke (звездообразная топология): есть один центральный
узел, который называется концентратором (hub), а все остальные узлы – лучи
(spoke) соединены только с концентратором. Большинство типов трафика передаются от spoke-устройства до hub-устройства, данные между лучами могут
быть переданы только через уз
ел-концентратор;
3) partially meshed network (частично связная сеть): представляет собой
несколько сетей, требующих подключения сразу к нескольким другим сетям.
В такой топологии VPN-туннели создаются по мере необходимости, так что
каждая сторона будет иметь несколько VPN-подключений к нескольким другим
сетям;
4) fully meshed network (полносвязная сеть): представляет собой не-
сколько сетей, имеющих VPN-соединение с каждой другой сетью. Эта топология обесп
ечивает оптимальные потоки трафика.
В таблице 1.1 приведены суммарные сведения о вышеупомянутых топологиях VPN.
1.1. Сравнение топологий VPN
P2P-туннель Hub-and-Spoke Частично связная Полносвязная
Независимые
связи между
сайтами
Используется,
когда существует
большое количество сайтов, которые связаны с
центральным
сайтом
Используется, когда небольшое количество сайтов
нуждается в подключении к другим сайтам, но не
обязательно ко
Используется для
оптимальной связи любого типа
всем
Простота
настройки
Обеспечивает
масштабируемую
конфигурацию на
центральном узле
Требует масштабируемую конфигурацию части пиров
Требуется масштабируемая
конфигурация
всех пиров
19
Хотя фреймворк IPsec предоставляет стандарты для защиты передаваемых данных и управления ключами, существует несколько вариантов развёртывания топологии, которые можно реализовать для WAN-сети. Для принятия
решения по развёртыванию той или иной технологии VPN требуется анализ
шаблонов сетевого трафика и бизнес-требований. Основные технологии, которые могут быть выбраны при развёртывании технологий межсайтового VPN,
следующие.
Технология инкапсуляции пользовательского трафика. IPsec предоставля-
1.7.2. Выбор технологии VPN для глобальной сети
ет множество различных методов инк
апсуляции (AH – Authentication Header и
ESP – Encapsulating Security Payload) и несколько режимов инкапсуляции
(транспортный режим, туннельный и смешанный гибридный режим, исполь-
зуемый технологией GET – Group Encrypted Transport VPN). Большинство реализаций используют туннельный режим IPsec или комбинацию IPsec и протокола Generic Routing Encapsulation (GRE) в качестве транспорта. GET – это метод смешанной инкапсуляции, который обычно используется в качестве режима без туннелирования и поэтому его не рекомендуется использовать в публичных сетях.
Масштабирование конфигурации. В среде с большим ко
личеством VPNпиров или в среде, в которой ожидается существенный рост, сетевому архитектору следует выбрать технологию VPN, которая включает в себя механизмы
масштабируемости конфигурации в целях упрощения управления (добавление
и удаление сайтов) сетью VPN.
Масштабирование аутентификации. Как и при масштабировании конф
игурации, решение задачи аутентификации пиров в архитектуре IPsec VPN может
вызвать сложности реализации. Каждый пир VPN должен аутентифицировать
большое количество других пиров, особенно если развёрнута частично связная
или полносвязная топология. Решение с использованием предварительно разделяемого ключа (PSK), который должен быть вручную настроен на пирах, плохо
масш
пирами, можно определить по формуле n
табируется. Количество паролей, которые необходимо настроить между
(n – 1)/2. Для полносвязной сети со
100 узлами требуется ручная настройка 4500 паролей. Использование инфра-
структуры открытого ключа (PKI) для обеспечения аутентификации с использованием сертификатов обеспечивает масштабируемое решение, но требует размещения и поддержания PKI и её обеспечивающей инфраструктуры.
20