Добавил:
ivanov666
Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз:
Предмет:
Файл:Технологии виртуальных частных сетей. Учебное пособие.pdf
Spoke(config)# interface tunnel0
Spoke(config-if)# ip address 10.1.1.2 255.255.0.0
Spoke(config-if)# ip mtu 1400
Spoke(config-if)# ip tcp adjust-mss 1360
4.11. НАСТРОЙКА И ПРОВЕРКА
ДИНАМИЧЕСКОЙ МАРШРУТИЗАЦИИ В DMVPN
При использовании динамических протоколов маршрутизации в DMVPN
необходимо учитывать некоторые факторы. Эти факторы особенно важны при
реализации топологии spoke-to-spoke, так как такая топология DMVPN похожа
на сеть NBMA.
Многие протоколы маршрутизации используют многоадресную рассылку
IP для обнаружения других соседей. По этой причине карты многоадресной передачи (multicast maps) NHRP должны быть настроены на spoke-маршрутизаторах для регистрации их возможности многоадресной рассылки на hub-маршрутизаторе. Hub-маршрутизатор может быть настроен с использованием динамической многоадресной карты, которая будет реплицировать многоадресный
трафик на spoke-уст
ройства, которые зарегистрировались для приёма многоадресной рассылки. Это позволяет hub-маршрутизатору и spoke-маршрутизаторам
осуществлять многоадресную рассылку и широковещательную передачу, но это
не позволяет spoke-устройствам получать трансляции от других spoke-устройств.
В DMVP
N отношения смежности в протоколе маршрутизации устанавливаются только между hub-маршрутизатором и каждым spoke-маршрутизатором.
Невозможно состояние соседства типа spoke-to-spoke. Таким образом, hubмаршрутизатор будет распространять информацию из каждой сети spoke на
другие spoke-устройства.
Обратите внимание, что функциональность протокола маршрутизации на
hub-маршрутизаторе является основным фактором при определении того, останется ли DMVPN сетью hub-and-spoke или расширится до частично или полносвязной сети путём распро
странения маршрутов между spoke-устройствами.
Другим фактором является то, используют ли spoke-устройства интерфейс GRE
(допускает только топологию hub-and-spoke) или интерфейс mGRE, который
допускает топологию mesh.
4.11.1. Конфигурация EIGRP на hub-маршрутизаторе
Протокол EIGRP может использоваться как в сетях hub-and-spoke, так и в
сетях частично связных и полносвязных топологий. Выполнить конфигурирование EIGRP при развёртывании DMVPN с топологией hub-and-spoke достаточно несложно. Вообще говоря, необходимо отключить автоматическое суммирование на hub-маршрутизаторе и отключить расщепление горизонта EIGRP,
чтобы hub-маршрутизтор распространил информацию о сетях на другие spokeустройства. Отключить расщепление горизонта можно с помощью команд
ы
конфигурации интерфейса no ip split-horizon eigrp AS-number.
Связная сеть DMVPN вызывает проблему при распространении маршрута, поскольку spoke-маршрутизаторы не могут напрямую обмениваться инфор-
51
мацией друг с другом, даже если они находятся в одной подсети. Для решения
этой задачи требуется, чтобы hub-маршрутизатор анонсировал подсети spokeустройства, а анонсируемый маршрут должен содержать исходный адрес следующего хопа в том виде, в котором его узнал hub-маршрутизатор от исходного
spoke-устройства. Команда конфигурирования интерфейса no ip next-hop-self
eigrp AS-number выполняет это требование. В примерах ниже показана конфи-
гурация для использования EIGRP в обоих топол
Router(config)# router eigrp 1
Router(config-router)# no auto-summary
Router(config-router)# exit
Router(config)# interface tunnel 0
Router(config-if)# no ip split-horizon eigrp 1
Router(config)# router eigrp 1
Router(config-router)# no auto-summary
Router(config-router)# exit
Router(config)# interface tunnel 0
Router(config-if)# no ip next-hop-self eigrp
Router(config-if)# no ip split-horizon eigrp 1
огиях DMVPN:
4.11.2. Конфигурация OSPF на hub-маршрутизаторе
Запуск протокола OSPF в DMVPN создаёт те же проблемы, что и работа
OSPF поверх других сетей. Hub-маршрутизатор должен быть настроен как на-
значенный маршрутизатор (DR), поскольку он находится в прямой связи со
всеми spoke. Как правило, резервный назначенный маршрутизатор (BDR) отсутствует.
В топологии DMVPN hub-and-spoke процесс настройки можно упростить,
включив интерфейс туннеля в процесс маршрутизатора OSPF и указав интерфейс туннеля на hub-ма
ршрутизаторе, как point-to-multipoint, а на spoke-маршрутизаторе – point-to-point. Нет необходимости в устройстве BDR, и это позволяет ветвям рассматривать концентратор как единственный путь от каждой подсети. Это значительно упростит работу алгоритма Дейкстры для области OSPF.
Для связной сети DMVPN настройте туннель mGRE на hub-маршрутизаторе, указав широковещательную сеть для OSPF, а каждый spoke-маршрутизатор с приорите
том OSPF, равным 0, чтобы не дать им стать DR. В примерах
ниже показаны конфигурации OSPF для топологий DMVPN:
Router(config)# interface tunnel 0
Router(config-if)# ip ospf network point-to-multipoint
Router(config-if)# ip ospf priority 10
Router(config)# interface tunnel 0
Router(config-if)# ip ospf network broadcast
Router(config-if)# ip ospf priority 10
4.11.3. Маршрутизация в топологии hub-and-spoke и IKE Peering
Проверку маршрутизации в DMVPN hub-and-spoke можно выполнить,
используя команду show ip route на spoke-маршрутизаторе для гарантирования
того, что все сети доступны через hub-маршрутизатор, как показано в примере
52
ниже. Следующим переходом для каждого префикса spoke должен быть IP-адрес туннеля hub-маршрутизатора. В дополнение к проверке маршрутов убедитесь с помощью команды show crypto isakmp sa, что IKE SA установлены и
определите их состояние QM_IDLE, как показано в примере ниже:
Router# show ip route
Codes: I - IGRP derived, R - RIP derived, O - OSPF derived,
C - connected, S - static, E - EGP derived, B - BGP derived,
* - candidate default route, IA - OSPF inter area route,
i - IS-IS derived, ia - IS-IS, U - per-user static route,
o - on-demand routing, M - mobile, P - periodic downloaded static route,
D - EIGRP, EX - EIGRP external, E1 - OSPF external type 1 route,
E2 - OSPF external type 2 route, N1 - OSPF NSSA external type 1 route,
N2 - OSPF NSSA external type 2 route
Gateway of last resort is 10.119.254.240 to network 10.140.0.0
O E2 172.150.0.0 [160/5] via 10.119.254.6, 0:01:00, Ethernet2
E 172.17.10.0 [200/128] via 10.119.254.244, 0:02:22, Ethernet2
O E2 172.70.132.0 [160/5] via 10.119.254.6, 0:00:59, Ethernet2
O E2 10.130.0.0 [160/5] via 10.119.254.6, 0:00:59, Ethernet2
E 172.30.0.0 [200/128] via 10.119.254.244, 0:02:22, Ethernet2
E 10.129.0.0 [200/129] via 10.119.254.240, 0:02:22, Ethernet2
E 172.80.129.0 [200/128] via 10.119.254.244, 0:02:22, Ethernet2
Router# show crypto isakmp sa
f_vrf/i_vrf dst src state conn-id slot
/vpn2 172.21.114.123 10.1.1.1 QM_IDLE 13 0
53
5. КОНЦЕПЦИЯ ИНФРАСТРУКТУРЫ ОТКРЫТЫХ КЛЮЧЕЙ
VPN-сети IPsec могут использовать инфраструктуру открытого ключа
(PKI – Public Key Infrastructure) для обеспечения масштабируемого решения для
решения задачи аутентификации пиров. Во многих протоколах аутентификации
при передаче данных через ненадёжные или общедоступные сети обычно используются цифровые подписи. В криптографии с открытым ключом, в которой обычно применяют алгоритм RSA, используются пары ключей, называемые открытым ключом и закрытым ключом, дл
рования, и цифровой подписи. Обе эти задачи требуют предварительного обмена открытыми ключами между двумя субъектами, которые хотят передавать
данные друг другу. Для проверки цифровой подписи проверяющая сторона
должна безопасно получить открытый ключ стороны, подписавшей данные
своим закрытым ключом. Получение открытого ключа должно осуществляться
безопасным образом для о
ключа.
беспечения подлинности и целостности открытого
5.1. РУЧНОЙ ОБМЕН КЛЮЧАМИ С ПРОВЕРКОЙ
Один из способов обеспечения безопасного обмена открытыми ключами – это обмен открытыми ключами с применением ненадёжного транспорта, но
с проведением проверки по другому каналу, который считается безопасным.
Этот способ может означать отправку открытого ключа и/или его отпечатка
(хеш-дайджеста) отправителю для проверки. Этот метод очень трудоёмкий, имеет большую вероятность появления оши
бок и является не масштабируемым.
5.2. ДОВЕРЕННОЕ ВНЕДРЕНИЕ
Pretty Good Privacy (PGP) – одна из самых известных попыток преодоления проблемы масштабирования обмена ключами – это система шифрования
отправлений электронной почты и файлов на основе криптографии с открытым
ключом. PGP использует концепцию trusted introducing (доверенное внедрение),
при котором существующие сеансы обмена ключами типа «точка–точка» могут
быть связаны друг с другом для решения проблемы распространения открытого
ключа. На рисунке 5.1 показан пример, в котором пользов
собственные открытые и закрытые ключи, а доверенной стороной (trusted
introducer) является пользователь B. Пользователь B не подписан на рисунке.
Кроме того:
я реализации процессов и шиф-
атели A, B и C имеют
− пользователи A и B надёжно обменялись своими открытыми ключа-
ми, используя ранее упомянутый ручной метод внеполосной проверки;
− пользователи B и C также надёжно обменялись своими открытыми
ключами с применением ручной проверки.
В итоге п
ользователи A и B, а также пользователи B и C могут безопасно
обмениваться сообщениями в рамках созданных отношений «точка–точка».
У них есть два способа использования PKI для решения задачи безопасности.
В одном случае они могут для решения задачи аутентификации и обеспечения
54
Рис. 5.1. Схема концепции доверенного внедрения
целостности подписывать сообщения своим собственным закрытым ключом
как отправители и проверять подпись соответствующим закрытым ключом, являясь получателями. Во втором случае они могут шифровать сообщения с помощью открытого ключа другой стороны, а получатель расшифровывает сообщение с помощью его собственного закрытого ключа.
Этот сценарий обеспечивает два двухточечных защищённых канала. Один
нал между пользователями A и B, а другой – между пользователями B и C.
ка
Вопрос в следующем: можно ли эти два канала использовать для создания канала между A и C? Ответ – да. Пользователь B будет действовать как доверенное лицо, потому что у него есть безопасный канал как с пользователем A,
так и с пользователем C. Когда пользователю A и пользователю C необходи
мо
обменяться открытыми ключами, они могут сделать это с помощью пользователя B, если этот пользователь считается заслуживающим доверия для выполнения этого действия.
Порядок операций.
Шаг 1. Пользователь B подписывает открытый ключ пользователя A и
отправляет его пользователю C.
Шаг 2. Пользователь C может проверить подпись пользователя B (по-
скольку он имеет открытый ключ пользователя B) и может счит
ать открытый
ключ пользователя A подлинным.
Шаг 3. Пользователь B подписывает открытый ключ пользователя C и
отправляет его пользователю A.
Шаг 4. Пользователь A затем может проверить подпись пользователя B
(поскольку он имеет открытый ключ пользователя B) и считать открытый ключ
пользователя C подлинным.
Рассмотренный метод включает в себя использование открытых ключей
RSA, подписанных секретными ключами в целях обеспечения возможности
55
обмена открытыми ключами безопасным способом. Теперь пользователи A и C
могут обмениваться информацией. Этот принцип доверия может быть использован в некоторых сетевых топологиях и является достаточно масштабируемым. Недостатком этого подхода является то, что пользователи могут подвергнуть опасности другие хосты из-за ошибочного установленного доверия к некоторому пользователю. Развитием этой процедуры стало создание криптографического протокола с доверенной третьей стороной (trusted third-party), который имеет гораздо более вы
сокую масштабируемость и обеспечивает гораздо
лучшую управляемость.
5.3. ИНФРАСТРУКТУРА ОТКРЫТОГО КЛЮЧА: ЦЕНТРЫ СЕРТИФИКАЦИИ
Использование криптографического протокола с доверенной третьей стороной совместно с криптографией открытого ключа также основано на подписывании открытых ключей, но расширяет идею до использования одного доверенного центра. Такое решение предполагает наличие только одного центрального доверенного центра (называемого центром сертификации (ЦС) [CA – certificate authority]), который подписывает все открытые ключи в рамках своего
административного домена (серв
еров, пользователей, маршрутизаторов и т.д.).
Кроме того, все сущности в этом административном домене доверяют ЦС. Это
означает, что все сущности имеют открытый ключ ЦС, который используют
для верификаций сообщений ЦС.
На рисунке 5.2 изображена ситуация, в которой каждый объект имеет
свою собственную пару асимметричных криптографических элементов – открытый и закрытый ключи. Пользов
атели A и C хотят надёжно передать данные друг другу. Доверенному узлу (ЦС является доверенным третьим лицом)
доверяют все пользователи.
56
Рис. 5.2. Схема использования ЦС
Все сущности доверяют ЦС по причине безопасного доступа к его публичному ключу. Этот процесс получения открытого ключа центра сертификации безопасным способом (например, внеполосным или воспроизведением по
телефону) называется аутентификацией ЦС.
Для участия в системе PKI все конечные пользователи должны зарегистрироваться в ЦС: они предоставляют свой открытый ключ и имя в ЦС. На рисунке 5.1 показан доверенный узел (центр серти
фикации) и пользователи, которые доверяют ему. После того как пользователь отправляет свой открытый
ключ и имя в ЦС, ЦС проверяет личность и публичный ключ регистрирующегося пользователя. Если он обнаруживает, что информация пользователя (открытый ключ и имя) является подлинной, ЦС подписывает пред
оставленную
информацию своим закрытым ключом. В результате этого действия создаётся
удостоверяющий (идентифицирующий) сертификат. Удостоверяющий сертификат – это информация, которая связывает имя участника PKI с открытым
ключом, представленная в определённом формате. Удостоверяющие сертификаты возвращаются пользователям с подписью ЦС. Пользователи могут использовать их до тех пор, пока сертификаты не перестанут быть акт
ивными или
не будут отозваны.
Теперь, когда каждый объект имеет открытый ключ центра сертификации
вместе с его собственным удостоверяющим сертификатом, который был подписан центром сертификации, пользователь может подтвердить любые данные,
которые подписаны ЦС.
Сущности теперь могут действовать независимо от ЦС и устанавливать
двухточечные связи друг с другом путём передачи информации о себе с помощью удостоверяющего сертификата.
Это означ
ает, что конечные пользователи могут теперь друг с другом обмениваться сертификатами через ненадёжные общедоступные сети и использовать цифровую подпись центра сертификации в качестве механизма доверия
при обмене открытыми ключами. Обратите внимание, что это возможно потому, что каждый объект мож
ет доказать достоверность и целостность подписи
ЦС, поскольку каждый объект имеет открытый ключ ЦС. По сути, удостоверяющий сертификат пользователя является доверенным, поскольку он подкреплён цифровой подписью сервера сертификации. Цифровая подпись сертификационного сервера является надёжной и может быть проверена, поскольку каждый объект надёжно защищён публичным ключом сервера.
Обмен удостоверяющими сертификатами не подтверждает лично
сть отправителя. Сертификаты обеспечивают достаточный уровень уверенности в
том, что определённое имя связано с определённым открытым ключом. Идентификация может быть доказана с помощью протокола аутентификации, в котором могут использоваться сертификаты (содержащие открытые ключи) в определённых процедурах, которые доказывают принадлежность закрытого ключа сущно
сти, соответствующей известному открытому ключу.
57
Удостоверяющий сертификат – это документ, который связывает имя
объекта и его открытый ключ и подписывается центром сертификации, чтобы
каждый другой конечный пользователь мог проверить его (в силу наличия открытого ключа ЦС). Обратите внимание, что сертификаты не являются секретной информацией, и их шифрование не требуется. Они защищены цифровой
подписью, которая подтверждает их подлинность и целостность.
5.4. СТАНДАРТ X.509
Типичными данными, содер
жащимися в удостоверяющем сертификате
стандарта X.509, являются следующие поля:
− имя владельца сертификата;
− открытый ключ владельца;
− цифровая подпись ЦС.
Другие поля, которые могут быть включены в сертификат:
− серийный номер сертификата;
− данные об окончании сертификата;
− алгоритмы, используемые для генерации подписи.
X.509 – хорошо из
вестный стандарт, который определяет базовые форматы данных PKI, такие как сам сертификат и списки отозванных сертификатов
(CRL – Certificate Revocation List) в целях обеспечения функциональной совместимости. Формат, определённый стандартом X.509, широко используется в
современных сетях. Его можно найти в следующих механизмах:
− на защищённых веб-серверах для проверки подлинности веб-сайтов
с использованием протокола Secure Socket Layer (SSL);
− в веб-браузерах для служб, которые использу
ют клиентские серти-
фикаты в протоколах SSL и Transport Layer Security (TLS);
− в почтовых агентах для обеспечения защиты почты с использовани-
ем протокола Secure Multipurpose Internet Mail Extension (S/MIME);
− в VPN-сетях IPsec, где сертификаты используются как механизм рас-
пространения открытого ключа для аутентификации на основе подписей RSA.
5.5. ПРОВЕРКА ОТЗЫВА СЕРТИФИКАТОВ
Одной из проблем, связанной с процессом ручного обмена ключами, которая была решена механизмом PKI, является проблема масштабируемости.
Ещё одна проблема, связанная с процессом ручного обмена ключами, – это
проблема управления ключевой информацией. В случае компрометации закрытого ключа объекта, всем остальным объектам необходимо сообщить о том, что
больше не следует доверять такому ключу.
5.5.1. Списки отозванных сертиф
икатов
В PKI предложено простое решение проблемы управления ключами в виде списков отозванных сертификатов (CRL – Certificate Revocation Lists).
CRL содержит список всех сертификатов, которые больше недействительны.
CRL подписывается ЦС и помечается меткой времени. Он хранится на HTTP-
58
сервере, сервере протокола LDAP или на сервере Simple Certificate Enrollment
Protocol (SCEP). Ответственность конечного пользователя PKI заключается в по-
лучении нового CRL после того, как предыдущий истёк, и проверки того, чтобы
любой из сертификатов, которые пользователь захочет использовать, не находился в текущем списке CRL. Сертификат помещается в CRL, если он больше не
считается доверенным. Это может произойти по следующим причинам:
− компрометация за
крытого ключа;
− прекращение контракта пользователя PKI;
− потеря закрытого ключа из-за потери носителя;
− замена устройства.
CRL может существовать как единый список, который со временем может стать довольно большим, или он может быть разбит на несколько меньших
списков CRL (множественные CRL), которые доступны через разные точки
распространения. URL-адрес точки распространения CRL для сертификата указан в самом сертификате.
5.5.2. Online Certificate Status Protocol
Проблема с CRL заключается в том, что они могут содержать устаревшую информацию. CRL выпускаются периодически, обычно каждые несколько
часов, и поэтому могут содержать устаревшую информацию. Если ключ был
скомпрометирован в середине периода обновления, есть окно времени, в течение которого скомпрометированный ключ может использоваться злоумышленником.
Протокол проверки состояния сертификата (OCSP – Online Certificate
Status Protocol) обеспечивает верификацию серт
ификатов в реальном времени c
базой данных отозванных сертификатов. Когда объект получает сертификат от
другого пользователя, пользователь опрашивает сервер OCSP в режиме реального времени, чтобы проверить, не был ли отменён полученный сертификат.
OSCP устраняет уязвимость CRL, но требует наличия высокостабильного и высокодоступного сервера, с которым пользователи могут проводить проверки.
5.6. ИСПОЛЬЗОВАНИЕ СЕРТИФИКАТОВ
В СЕТЕВЫХ ПРИЛОЖЕ
НИЯХ
PKI – это система, в которой каждый объект имеет свой открытый ключ,
подписанный доверенным ЦС. PKI обеспечивает эффективную модель распределения открытых ключей, которая поддерживает легко масштабируемые технологии с открытым ключом.
PKI предоставляет объектам масштабируемый, безопасный механизм для
распространения, управления и отзыва ключевой информации для решения задач шифрования и идентификации.
Имейте в виду, что PKI – это всего ли
шь способ безопасного обмена открытыми ключами между пользователями и другими объектами. Приложение,
для которого используется открытый ключ, – совершенно иная сущность.
Приложения, в которых используется PKI:
59
− почтовые клиенты просматривают сертификаты получателей в своём
каталоге, после проверки извлекают открытый ключ и используют его для
шифрования почтовых сообщений;
− VPN-маршрутизаторы могут обмениваться сертификатами по нена-
дёжной сети. Открытый ключ внутри сертификата используется для отправки
запроса другому пиру в целях предоставления подтверждения наличия соответствующего закрытого ключа и, следовательно, ау
тентификации другой стороны;
− веб-серверы часто имеют сертификаты, выпущенные известными цен-
трами сертификации. Веб-клиенты имеют сертификаты этих центров сертификации и могут проверить идентификатор веб-сервера, получая сертификат в начале
сеанса HTTPS, проверяя его с помощью сертификата ЦС и извлекая его открытый
ключ; клиенты могут затем использовать эту информацию, чтобы от
править вызов серверу в целях предоставления подтверждения его закрытого ключа. Обычно
это делается путём отправки веб-серверу случайных данных, зашифрованных открытым ключом из сертификата, и проверки того, что сервер сможет эти данные
расшифровать. Этот процесс служит для аутентификации сервера;
− с помощью точно такого же процесса, что и дл
я веб-серверов, Cisco
Unified Communications Manager аутентифицирует IP-телефоны и IP-телефоны
аутентифицируют Cisco Unified Communications Manager, когда тот настроен
для использования сигнализации, защищённой TLS;
− доверенный открытый ключ из сертификата может использоваться
для безопасной передачи сеансового ключа симметричного алгоритма шифрования другой стороне.
5.7. ВАРИАНТЫ РАЗВЁРТЫВАНИЯ
Выбор, который необходимо сделать при развёртывании VPN на основе
PKI, – это использовать выделенный (ограниченный) PKI только для VPN, ко-
торый регистрирует только VPN-устройства в качестве своих конечных пользователей, или использовать более крупную корпоративную PKI, где VPN-устройства – это всего лишь один тип объектов, которые используют тот же PKI
вместе с другими объектами, такими как веб-серверы, пользоват
ели или другие
сетевые устройства.
5.8. ШАГИ РАЗВЁРТЫВАНИЯ
Основными шагами для внедрения IPsec VPN с поддержкой PKI являются
следующие.
Шаг 1 (необязательный). Разверните сервер сертификатов (Certificate
Server) с помощью программного обеспечения Cisco IOS, если вы не используете уже существующее решение PKI.
Шаг 2. Зарегистрируйте все VPN-устройства в PKI. Эта обязательная задача требует генерации пар ключей RSA на всех VPN-устройствах, аутентификации ЦС (безопасная установка сертификата ЦС на каждом устройстве VPN) и
регистрации каждого VPN-устройства в PKI (каждое устройство отправляет
своё им
я и открытый ключ в ЦС и получает удостоверяющий сертификат).
60