Что такое hub and spoke
Технология HP Dynamic VPN. Часть 1
Введение
Приветствую всех читателей в нашем блоге.
Этот цикл статей будет посвящен нашему замечательному решению под названием HP Dynamic VPN (или HP DVPN).
Это первая статья из цикла, и в ней я постараюсь рассказать о том, что представляет собой решение HP DVPN, а также описать его возможности и сценарии применения. В следующих статьях этого цикла речь пойдет о практической реализации возможностей DVPN и настройке самого оборудования.
Что такое DVPN?
Если кратко, то DVPN – это архитектура, которая позволяет множеству филиалов или региональных офисов (spoke) динамически создавать защищенные IPsec VPN туннели поверх любого IP транспорта для подключения к центральному офису или ЦОД (hub).
Для кого и чем это может быть полезно?
Допустим, есть некая организация, у которой имеется множество филиалов или удаленных офисов, раскиданных по всему городу или даже по всей стране (например, некий банк, или сеть магазинов, примеров таких организаций можно привести очень много). Перед нами стоит задача объединить все эти филиалы между собой с помощью одной транспортной сети, а также обеспечить возможность их подключения к центральному офису или ЦОД, в котором размещаются основные IT-ресурсы этого предприятия.
Казалось бы задача является вполне себе тривиальной, однако тут могут быть некоторые нюансы:
Какие же есть приемлимые варианты путей решения данной задачи? Из первого, что приходит на ум – использование защищенных IPsec VPN туннелей между центром и филиалами поверх сети Интернет в топологии «звезда» (т.е. когда каждый филиал строит IPsec-туннель до центра, центр выступает в роли концентратора VPN-туннелей, приходящих из филиалов. При этом, весть трафик филиалов проходит через центр).
Это решение достаточно давно применяется многими организациями, а также поддерживается на оборудовании множества производителей (т.к. IPsec является общепризнанным стандартом), однако, в рамках нашей задачи, и оно не лишено некоторых очень существенных недостатков:
Что позволяет реализовать архитектура DVPN?
Для решения подобных проблем и недостатков, нами была разработана архитектура HP Dynamic VPN (HP DVPN), которая позволяет подключать до 3 000 узлов в единую защищенную транспортную сеть (или DVPN домен).
Основные особенности данной архитектуры:
Компоненты архитектуры DVPN
DVPN состоит из пяти главных компонентов:
Как это выглядит?
Ниже приведена упрощенная схема типичной DVPN сети в топологиях Hub-and-Spoke и Full Mesh соответственно.
Для топологии Hub-and-Spoke характерны следующие признаки:
Оборудование HP с поддержкой DVPN
В таблице ниже представлен перечень оборудования, которое поддерживает DVPN, и рекомендации о том, в роли какого компонента архитектуры DVPN желательно его использовать.
Из таблицы видно, что DVPN поддерживается практически на всех линейках маршрутизаторов HP (HP MSR и HP 6600) за исключением серии HP 8800.
Более подробная информация по портфелю продуктов HP с поддержкой DVPN доступна здесь.
DVPN и динамическая маршрутизация
Без динамической маршрутизации между узлами, все преимущества по простоте конфигурации и масштабированию архитектуры DVPN сошли бы на нет. Очевидно, что при большом количестве узлов в сети, статическая маршрутизация не применима, поэтому DVPN поддерживает следующие протоколы динамической маршрутизации:
Масштабирование и отказоустойчивость DVPN
Как уже было упомянуто, DVPN позволяет масштабироваться до 3000 Spoke узлов на один домен. При необходимости, количество доменов может быть увеличено до 10 (на маршрутизаторе HP 6600, работающем в качестве Hub), тем самым обеспечивая поддержку создания сетей с количеством узлов, достигающим 30,000!
Для обеспечения отказоустойчивости DVPN сети используют дублирование устройств, выполняющих роль VAN сервера, Hub маршрутизатора и сервера аутентификации (при наличии).
При этом, VAM клиент на узлах Spoke регистрируется на обоих VAM серверах, и на маршрутизаторе этих узлов создается два независимых DVPN домена, внутри которых строятся IPsec VPN туннели до основного и резервного Hub маршрутизатора одновременно.
При таком подходе с помощью протоколов динамической маршрутизации существует возможность балансировать трафик между IPsec VPN туннелями обоих DVPN доменов (основного и резервного).
Ниже приведена более детальная схема построения DVPN сети с использованием резервирования.
Механизмы управления
Еще большую эффективность и простоту управления и мониторинга сетью с архитектурой DVPN, поможет осуществить система управления HP Intelligent Management Center (IMC).
Например, с помощью специального модуля для этой системы Branch Intelligent Management System (BIMS) возможно полностью отказаться от ручного конфигурирования Spoke маршрутизаторов в филиалах за счет использования механизмов автоматический настройки абонентских устройств протокола TR-069.
Более подробно про IMC и модуль BIMC вы сможете прочитать в следующих циклах статей по HP Networking в блоге нашей компании.
Заключение
Архитектура DVPN позволяет быстро разворачивать хорошо масштабируемые и защищенные корпоративные сети передачи данных (КСПД) практически любых размеров и различных топологий для предприятий с развитой инфраструктурой территориально распределенных подразделений (филиалов) поверх любого существуюшего L3 транспорта (включая Интернет, выделенные WAN каналы и т.д.).
Что дальше?
В следующей статье из цикла про архитектуру DVPN будет подробно описан пример настройки типовой DVPN сети.
Токарчук Андрей
Мне 34 года. Профессионально занимаюсь PHP-программированием. В работе использую PHP, JS, Symfony, Doctrine и многое другое. А вообще мне нравится всё новое и интересное 🙂
Строим сеть вида Hub and Spoke + L2TP
В этом посте мы будем рассматривать схему организации связи офисов по средством ipsec туннелей на базе оборудования D-Link и Mikrotic. Возьмем схему их предыдущего поста (site-to-site) и развернем её до уровня (hub-and-spoke), также известная как топология звезда.
Нам необходимо построить сеть следующего вида.
В качестве маршрутизатора в центральном офисе будем использоваться D-link dfl-260e. Эта железка открывает серию профессионального оборудования D-link с NetDefendOS. В качестве маршрутизаторов в филиалах будем использовать Mikrotic, широко известные rb2011uias-2hnd-in и 450G. Как сделать один туннель site-to-site между D-link dfl-260e и Mikrotik я уже писал в одной из предыдущих статей.
Задачи
Необходимо настроить два туннеля site-to-site от hub до spoke.
Узлы в центральной сети (HUB lan) должны быть доступными из филиалов (spoke2 lan, spoke1 lan).
Филиалы должны видеть узлы подсети друг друга.
Один из филиалов имеет динамический IP. Ну это, чтобы жизнь медом не казалась.
Удаленные пользователи соединяются с HUB по l2tp протоколу и тоже должны видеть не только подсеть центра, но и подсети филиалов.
Подсети
192.168.0.0/24 — сеть центрального офиса. Шлюз: 192.168.0.1 Публичный IP: x.x.x.x (статический).
192.168.1.0/24 — сеть spoke1. Шлюз: 192.168.1.1 Публичный IP: y.y.y.y (статический).
192.168.2.0/24 — сеть spoke2. Шлюз: 192.168.2.1 Публичный IP: z.z.z.z (динамический).
192.168.3.0/24 — сеть l2tp. Шлюз: 192.168.3.1
LANNET в контексте туннеля
При создании IPSEC туннелей важно понимать, что в контексте туннеля, всё то, LANNET-ами для него будут все сети, которые за ним с другой стороны. На словах звучит ужасно, надо проиллюстрировать. Возьмём туннель HUB<>-SPOKE1. Для него destination network будет SPOKE1-LAN, а lan network будут (HUB-LAN, SPOKE2-LAN). Это касается не только писания туннелей, но и маршрутов, правил firewall и srcnat.
Три вещи, которые должны быть
Чтобы всё работало, должно быть три вещи.
Особенность динамического конца IPSEC туннеля в D-link DFL
ВНИАМНИЕ: Динамический тоннель, может только принимать подключения, но не устанавливать их.
Примечание: Если у вас уже настроены статические тоннели или в будущем вам необходимо будет их использовать, убедитесь, что статические тоннели находятся выше созданного в предыдущем шаге динамического тоннеля. Все тоннели находящиеся ниже созданного тоннеля будут неработоспособны. Для изменения порядка тоннелей нажмите правой кнопкой мышки по имени тоннеля и выберите из контекстного меню поднять или опустить.
ВНИМАНИЕ 2: Динамический тоннель может быть только один. Этот тоннель способен подключить всех клиентов с динамическими адресами, в т.ч. с интерфейса wan2, если корректно настроен PBR.
Настройка D-link dfl-260e
Для начала забиваем объекты в Address book. Очень удобно использовать папки в ней для групп объектов. Я создал папку Tunnels, куда мы будем складывать всё добро, касающиеся туннелей.
Создаём в ней адреса.
Здесь мы указываем внешний адрес филиала spoke1 (Aidar-endpoint), сеть spoke1-net (Aidar-network), внешний адрес филиала spoke2 (Shelk-endpoint), сеть spoke2-network (Shelk-network), сеть для l2tp (l2tp_network), диапазон адресов, из которых будут выдаваться адреса l2tp-пользователям (l2tp_range), адрес l2tp-сервера в этой сети (l2tp_server).
Есть у меня один косяк в конфигурации, у меня локальная сеть lannet сидит на интерфейсе dmz (dmznet) = 192.168.0.0/24 Так исторически сложилось, просто примите это)
Дальше мы указываем сети, которые по отношению к туннелю будут за HUB-ом (центральным маршрутизатором). Де-факто это те сети, которые мы позволяем видеть из этого тоннеля. Например, для тоннеля HUB->Spoke2 (tunnelToShelk-localnet) мы группируем сети dmznet, Aidar-network (Spoke1-lan), l2tp_network. Аналогично с HUB->Spoke1 (tunnel-toAidar-localnet). Именно из-за этой особенности мне долгое время не удавалось поднять тоннель. Важно заметить, что если список сетей отличается с двух сторон тоннеля — то он не поднимется, а будет ошибка «no-phase2» на стороне Mikrotic и ошибка «No proposal» на стороне D-link DFL.
Часть I. Настройка «HUB»
Почему настройки именно такие? Это выяснилось методом проб и ошибок и они таки работают.
Тут добавляем наш ключ типа Pre-Shared Key для IPSec туннеля. Можем один для всех сразу, можем для каждого свой. Главное не забыть и не перепутать потом.
Создаём пользователя L2TP
Группа интерфейсов на DFL
Вот, что у меня получилось.
Дальше пойдут скриншоты настроек тоннеля. Всё, кроме Local Net, Remote Net, Remote Endpoint — одинаковое.
Маршруты на DFL
После поднятия туннелей у нас должны добавиться автоматические маршруты. Выглядеть это будет так:
Policies на DFL
Папка правил tunnels
Сначала я понаделал кучу правил (отображено серым), а потом просто свёл их в одно с помощью группы интерфейсов.
Папка правил vpn_l2tp
Тут первое правило дублирует аналог и папки tunnels так что его в принципе можно убрать.
Правила to-internet-alllow и to-intetnet-nat разрешают трафик из l2tp в Интернет и делают src-nat для него.
L2TP сервер на DFL
Авторизация L2TP
Часть II. Настройка «Spoke»
В этой части мы будем настраивать маршрутизатор филиала Spoke2. Это Mikrotik и мы включаем у него Mikrotic Cloud IP, и получаем DDNS запись.
Делаем базовую настройку для какой-нибудь сети по этому посту. Потом добавляем вторую (и следующие сети) вот так:
При настройки второй части IPSEC тоннеля на Mikrotic нужно будет сделать три вещи: srcnat (firewall), route, ipsec policy. Это при добавлении новой подсети в тоннель.
Добавляем новую IPSec Policy
Обратите внимание Level = requre здесь значит, что мы используем один SA для всех подсетей. Именно так, по-умолчанию ведет себя D-link dfl-260e.
Добавляем правило NAT
В этом правиле мы будем натить трафик с внутренней сети spoke2-network (192.168.2.0/24) на сети hub-network (192.168.0.0/24), spoke1-network (192.168.1.0) и l2tp_network (192.168.3.0/24).
Routes для сетей за HUB
Добавляем маршруты для сетей за центральным маршрутизатором (HUB).
Добавляем правила для firewall для этих подсетей
Возможно этот шаг излишний, ведь уже есть nat. Но на всякий случай оставляю его тут.
Настройки L2TP-клиента
В мобильном телефоне (или кто там у нас l2tp-клиент) выбираем тип сети: L2TP PSK (with Pre-Shared Key).
Пишем логин и пароль от нашего пользователя, а в разделе Общий ключ IPSec указываем PSK-key, который задали ранее.
Замечание про MTU и IPSec
При проверке пинга от узла сегмента spoke2-network на узел сегмента spoke1-network начал наблюдать такие ошибки:
From 192.168.2.1 icmp_seq=27 Frag needed and DF set (mtu = 78)
From 192.168.2.1 icmp_seq=28 Frag needed and DF set (mtu = 68)
From 192.168.2.1 icmp_seq=29 Frag needed and DF set (mtu = 68)
From 192.168.2.1 icmp_seq=30 Frag needed and DF set (mtu = 68)
После того, как ставим его в inheriet — пинги проходят нормально. Также очень вважно поставить в настройках туннеля значение MTU = 1500. Иначе по дефолту оно будет 68 и вы получите ту же ошибку.
Ссылки
Спасибо!
Hub and Spoke
содержание
Хаб и говорил в транспорте
В транспортном секторе ступица и спица представляют собой звездообразное расположение транспортных маршрутов, при этом все они проходят к центральному узлу или от него во всех направлениях, чтобы иметь возможность обслуживать территорию (звездообразная топология).
Системы со звездообразными концентраторами, различаются одиночным назначением ( одиночное распределение ) и множественным назначением ( множественное распределение ). При однократном назначении каждый источник (начальная точка заряда) и каждый приемник (точка приема заряда) имеют ровно одно соединение с ровно одним концентратором. В случае множественного назначения источники и приемники могут устанавливать соединения с несколькими концентраторами. Таким образом, единичное присвоение является особым случаем множественного присвоения. Кроме того, существуют системы со спицами и концентраторами без прямых соединений (чистые системы со спицами и концентраторами) и системы с прямыми соединениями (гибридные системы со спицами и концентраторами) между узлами, не являющимися концентраторами.
Эта система важна практически для всех видов транспорта:
Возможны также системы с несколькими концентраторами, которые связаны между собой прямым трафиком. Одним из примеров этого является сеть GLS в Германии ; Компания описывает хабы как «центральные перевалочные пункты» (ZUP).
В моторизованном частном транспорте метод ступицы и спицы практически бессмыслен, поскольку водитель обычно проезжает по кратчайшему маршруту (в лучшем случае с небольшими объездами по автомагистралям, а не по проселочным дорогам). Однако дело обстоит иначе с приобретенным каршерингом («автостопом»), где в зависимости от метода и дорожной ситуации городам, станциям автомагистралей и пограничным переходам присваиваются свойства узловых пунктов.
Хаб и выступил в сфере коммерческой пассажирской авиации
Хаб и выступил в информационных технологиях
Интеграция корпоративных приложений
сетевые технологии
Телефония
Пользовательские интерфейсы
Примером пользовательских интерфейсов в архитектуре « ступица и спица» является домашний экран смартфонов, с которого можно запускать отдельные приложения. Он характеризуется наличием центрального пользовательского интерфейса, из которого вызываются другие части приложения. В этом случае отдельные части не имеют или имеют только несколько перекрестных соединений. Они не показывают меню навигации, как, например, Википедия.
Звездообразная топология сети
HUB и лучевой — это модель сети для эффективного управления общими требованиями к взаимодействию или безопасности. Она также позволяет избежать ограничений подписки Azure. В этой модели уделяется особое внимание следующим вопросам.
Экономия затрат и эффективное управление: Централизация служб, которые могут совместно использоваться несколькими рабочими нагрузками, такими как сетевые виртуальные устройства (NVA) и DNS-серверы. С одним расположением для служб это может максимально сэкономить избыточные ресурсы и усилия по управлению.
Ограничения лимита подписки: При работе с большими облачными рабочими нагрузками может потребоваться больше ресурсов, чем в одной подписке Azure. Пиринг рабочей нагрузки виртуальных сетей из различных подписок в центральный концентратор может преодолеть эти ограничения. Дополнительные сведения см. в статье ограничения подписки Azure.
Разделение проблем: Вы можете развертывать отдельные рабочие нагрузки между центральными группами ИТ и группами рабочей нагрузки.
Небольшие облачные инфраструктуры могут не воспользоваться преимуществами дополнительной структуры и возможностями, которые предлагает эта модель. Но в сценарии больших внедрений облачных технологий следует рассмотреть возможность применения сетевой звездообразной архитектуры, если у команд есть какие-либо вопросы, перечисленные ранее.
На сайте эталонные архитектуры Azure содержатся примеры шаблонов, которые можно использовать в качестве базиса для реализации собственных сетей hub-and-лучевой сети.
Общие сведения
Рис. 1. Пример топологии сети типа «звезда».
Как показано на диаграмме, среда Azure поддерживает два типа звездообразного проектирования. Первый тип поддерживает связь, общие ресурсы и централизованную политику безопасности. Этот тип помечен как концентратор виртуальной сети на схеме. Второй тип основан на виртуальной глобальной сети Azure, которая помечена как Виртуальная глобальная сеть в схеме. Этот тип предназначен для крупномасштабного обмена данными между ветвями и ветвями и Azure.
Центральная зона (концентратор) контролирует и проверяет входящий и исходящий трафик между зонами, включая Интернет, а также локальные периферийные зоны. Звездообразная топология позволяет ИТ-отделу применять политики безопасности в центральном расположении, одновременно минимизируя уязвимости и ошибки в конфигурации.
В концентраторе часто содержатся общие компоненты службы, используемые периферийными зонами. Примеры распространенных основных служб:
Вы можете минимизировать избыточность, упростить управление и снизить общую стоимость, используя общую инфраструктуру концентратора для поддержки нескольких периферийных зон.
Роль каждой периферийной зоны может заключаться в размещении различных типов рабочих нагрузок. Использование периферийных зон также позволяют реализовать модульный подход для повторяемых развертываний одних и тех же рабочих нагрузок Примеры: Разработка и тестирование, приемочное тестирование пользователя, промежуточное хранение и Рабочая среда.
Также эти зоны можно использовать для разделения и включения различных групп в пределах организации, например, групп DevOps в Azure. В пределах периферийной зоны можно развернуть базовую рабочую нагрузку или сложные многоуровневые рабочие нагрузки с управлением трафиком между уровнями.
Шлюз приложений, показанный на приведенной выше схеме, может жить в своей работе с приложением, которое оно обслуживает для улучшения управления и масштабирования. Однако корпоративная политика может зависеть от размещения шлюза приложений в центре для централизованного управления и разделения полномочий.
Ограничения подписки и несколько центральных зон
В Azure каждый тип компонента развертывается в подписке Azure. Изоляция компонентов Azure в разных подписках Azure позволяет выполнять требования различных бизнес-приложений, например настройку дифференцированных уровней доступа и авторизации.
Единая реализация hub-and-лучевой может масштабироваться до большого количества периферийных серверов, но, как и в случае с каждой ИТ-системой, существуют ограничения платформы. Развертывание концентратора привязано к определенной подписке Azure, которая имеет ограничения, Одним из примеров может быть максимальное число пиринга виртуальных сетей. Дополнительные сведения см. в статье Подписка Azure и ограничения службы.
Если ограничения могут быть проблемой, можно увеличить масштаб архитектуры, расширив модель до кластера узлов и периферийных серверов. Вы можете подключить несколько концентраторов в одном или нескольких регионах Azure с помощью:
Рис. 2. кластер концентраторов и периферийных серверов.
Включение нескольких концентраторов приводит к увеличению затрат и накладных расходов на управление. Это увеличение выравнивается только по следующим параметрам:
В сценариях, требующих использования нескольких концентраторов, все концентраторы должны предоставлять один и тот же набор служб для простоты в работе.
Взаимодействие между периферийными зонами
В пределах отдельной периферийной зоны можно реализовать сложные многоуровневые рабочие нагрузки. Вы можете реализовать многоуровневые конфигурации, используя подсети (по одной для каждого уровня) в одной виртуальной сети, а также используя группы безопасности сети для фильтрации потоков.
Архитектор может развертывать многоуровневые рабочие нагрузки в нескольких виртуальных сетях. Используя пиринг между виртуальными сетями, периферийные зоны могут подключаться к другим периферийным зонам в пределах одного или нескольких концентраторов.
Типичным примером такого сценария является случай, когда серверы обработки приложения располагаются в одной периферийной зоне или виртуальной сети, а база данных развернута в другой периферийной зоне или виртуальной сети. В этом случае периферийные зоны могут легко обмениваться данными через пиринговые виртуальные сети, не используя при этом концентратор. Выполните тщательную проверку архитектуры и безопасности, чтобы обойти центр не обойти важные точки безопасности или аудита, которые находятся только в концентраторе.
Рис. 3. пример периферийных серверов, соединяющихся друг с другом и концентратором.
Периферийные зоны могут также взаимодействовать с периферийной зоной, выполняющей функции концентратора. При таком подходе создается иерархия из двух уровней: спица на более высоком уровне, уровень 0, превращается в концентратор младших периферийных единиц или уровень 1 иерархии. Периферийные серверы должны пересылать трафик в Центральный концентратор. Это требование заключается в том, что трафик может переноситься в место назначения в локальной сети или в общедоступном Интернете. Такая архитектура концентратора представляет сложную маршрутизацию, что сводит на нет преимущества отдельной звездообразной связи.
Дальнейшие действия
Теперь, когда вы изучили рекомендации по работе с сетью, Узнайте, как подходить к управлению удостоверениями и доступом.