IPsecHub+. Эскалаторная топология
Всем привет! На связи Николай Едомский, руководитель группы сетевых инженеров в ЕДИНОМ ЦУПИС.
Представляю вашему вниманию третью статью из цикла »IPsecHub+».
В предыдущей статье мы пришли к выводу, что желательно максимально сократить количество сущностей, которые участвуют в процессе добавления или удаления нового филиала. В этой статье мы рассмотрим способ достижения такой цели.
Прежде всего, это нужно для максимального упрощения автоматизации процесса. Я думаю, вы согласитесь, что делать автоматизацию для Linux-машин — это одно, а для Linux-машин, какого-нибудь NGFW типа Fortigate и еще для коммутатора Huawei — это совсем другое. Особенно если учесть, что коммутатор и NGFW обслуживают не только сервис стыковки по IPsec, а вообще всю компанию, и последствие ошибки в скриптах автоматизации — это не только падение IPsec-сегмента, но и других сервисов.
Еще раз на всякий случай подчеркну — все описанные ниже усилия по модификации топологии связаны с острой необходимостью максимально исключить из рутины как межсетевой экран, так и прочие сущности.
Давайте приступим к построению топологической основы для нашего проекта «IPsecHub+». Обобщим требования для нашей улучшеной топологии:
Локализовать на IPsec-концентраторе все процессы по удалению и добавлению филиалов.
Разработать максимально дружелюбную к автоматизации топологию.
Сохранить гибкость и прозрачность схемы.
Все эти требования можно реализовать при помощи так называемой эксалаторной топологии.
Описание эксалаторной топологии
Для понимания логики можно провести аналогию с эскалаторами торгового центра с этажами нижних уровней. Представьте, что в холле у входа вы видите эскалаторы, которые работают либо на спуск к нижним этажам, либо на подъем c нижних этажей к вам в холл.
На каждый этаж, как бы глубоко он ни находился, ведет отдельный эскалатор как на спуск, так и на подъем. Для спуска на -5 этаж не нужно проходить -2, -3 и -4. Вы сразу с холла можете попасть на минус-пятый, и с минус-пятого подняться обратно в холл через один пролет эскалатора.
Людей при этом у вас много, и желательно сделать так, чтобы спускающиеся не перемешивались с теми, кто поднимается. У нас получается (см. рис. 2.):
отдельный холл для спуска
отдельный холл для подъема
в каждом холле есть зона досмотра
Понятное дело, что при помощи спускающих эскалаторов вы можете только спускаться, а при помощи поднимающих — только подниматься. Эта вводная будет служить основой для логики нашей топологии.
Вот как будет выглядеть движение на нижние этажи, см. рис. 3.
Аналогичный маршрут будет для -1 этажа.
Применимо к сетям, основные принципы эскалаторной топологии таковы:
В филиал от межсетевого экрана можно попасть ТОЛЬКО через служебный спускающий VRF.
Из филиала к межсетевому экрану можно попасть ТОЛЬКО через служебный поднимающий VRF.
В роли зон досмотра выступает межсетевой экран.
В случае, если у нас будет единый технический этаж как для спуска трафика, так и для его подъема, то трафик из филиала в филиал сможет сразу запрыгнуть из поднимающего эскалатора на спускающий, миновав межсетевой экран. См. рис. 5.
Поэтому нам нужно создать разные технические этажи, трафик между которыми как раз контролируется межсетевым экраном.
Давайте условимся о следующих наименованиях:
технический этаж, предназначенный для спуска трафика в филиалы, будет называться VRF ipsecTo.
технический этаж, предназначенный для подъема трафика от филиалов к межсетевому экрану — VRF ipsecFrom.
Реализация эксалаторной топологии
Теперь главный вопрос -, а как реализовать те самые эскалаторы? Здесь нам поможет особый тип интерфейсов, доступных практически во всех современных Linux-системах — virtual ethernet. Это по сути виртуальный патчкорд внутри системы. Предполагается, что в системе создается патчкорд с двумя интерфейсами вида veth на концах. На них можно назначить IP-адреса, и… погрузить каждый из концов в отдельный VRF. Это готовый эскалатор! Эскалаторную топологию с применением veth-интерфейсов можно мосмотреть на рис. 6.
А как нам определить, какой из veth-эскалаторов будет поднимать трафик, а какой — спускать? Это мы уже задаем при помощи таблицы маршрутизации. В данном случае на межсетевом экране мы маршрутизируем трафик в филиалы через соответствующий vlan10-интерфейс IPsec-концентратора, который погружен в VRF ipsecTo.
В этом VRF также будет присутствовать маршрут, который указывает, через какой эскалатор (veth) будет доступен конкретный филиал. Другой конец veth как раз погружен в VRF, выделенный под нужный нам филиал, и уже в нем есть GRE, который приведет нас непосредственно на удаленную площадку.
Обратный трафик следует смаршрутизировать по схожему принципу. См. рис. 8.
В филиальном VRF мы создаем маршрут, который будет указывать, что адрес ЦОД доступен через veth, погруженный в VRF ipsecFrom. А уже в него, в свою очередь, погружен vlan11-интерфейс, через который доступен межсетевой экран. Вот как будет выглядеть направление обратного трафика, см. рис. 9.
Следующим образом будет выглядеть добавление второго филиала к эскалаторной схеме — см. рис. 10. Трафик маршрутизируем аналогично предыдущему примеру, только хост 192.168.2.1 уже будет доступен через другой спускающий эскалатор.
Такая топология позволит нам пристыковать к VRF ipsecFROM и VRF ipsecTO произвольное количество филиалов. См. рис. 11.
Выводы
Давайте уточним, удовлетворили ли мы все требования?
Ограничить процесс масштабирования IPsec-концентратором. Да, veth, VRF и прочие элементы создаются только на концентраторе. На межсетевом экране нам нужно единоразово создать интерфейсы, погруженные в VRF ipsecFROM и ipsecTO. При добавлении филиалов количество интерфейсов на межсетевом экране не меняется. При удачном супернеттинге можно также один раз добавить маршрут на межсетевом экране до всего филиального супернета и больше вообще не трогать его конфигурацию.
Разработать максимально доступную для автоматизации процедуру. Да, все процедуры ограничены простыми действиями, их легко автоматизировать доступными инструментариями (Ansible и тп).
Сохранить гибкость и прозрачность схемы. Тут можно сказать, что требование удовлетворено частично. Схема, надо признать, вышла не самая простая. Но здесь уже следует выбирать между теми плюсами, которые она дает, и некоторым усложнением ландшафта, которое она вызывает. В том, что она очень гибкая, можно будет убедиться в следующей статье.
Нужно сказать, что у этой схемы есть один минус. Для нас он был незначителен, но у кого-то он может вызвать серьезные трудности. Речь идет про zone-based firewall. При эскалаторном подходе все филиалы будут назначены только на одну зону межсетевого экрана, так как межсетевой экран будет маршрутизировать трафик до филиалов через единственный интерфейс. Это касается экранов, построенных на основе зон. Можно создать гибридную схему, которая предполагает наличие разных ipsecTo/From VRF для разного типа зон, ну или придумать другие обходные пути решения этой особенности. Но про этот момент всегда следует помнить.
И еще важно отметить тот факт, что такая схема является мультивендорной. Если система поддерживает что-то похожее на veth — то схема будет раобтать. Например, у Juniper есть аналог veth, который называется logical tunnel (lt-интерфейсы). У отечественых Eltex veth присутствует в чистом виде, как и в Linux-подобных системах.
В этой статье мы рассмотрели основу того решения, которое позволило нам полностью автоматизировать IPsec-концентратор и сократить время подготовки нового филиала с 5 часов до 15 минут. Количество задействованных устройств сведено к возможному минимуму (1), а конфигурация нового филиала добавляется скриптом с простой логикой. Также сведен к минимуму риск, связанный с конфигурированием высоконагруженого межсетевого экрана.
Если обобщить, то такая топология подойдет для решения концентрации любых VRF, не только IPsec-ориентированных. Но в нашем случае это было актуально больше всего именно в разрезе решения задач со стыковкой удаленных филиалов.
Какие требования к нашему концентратору мы выполнили?
Давайте подведем итог первой итерации построения нашей схемы. Какие требования к нашей топологии мы уже выполнили с помощью применения эскалаторной топологии?
трафик между филиалами должен проходить через централизованный межсетвой экран. Здесь все хорошо. Согласно эскалаторной топологии, трафик из филиала в филиал может попасть только через межсетевой экран.
Шифрованный трафик между ЦОД и филиалами должен проходить через централизованный межсетвой экран. Здесь тоже требование удовлетворено. Шифрованный трафик попадает в default VRF только через межсетевой экран.
Туннели должны терминироваться на одном IPsec-концентраторе. Требование закрыли. Эскалаторная топология позволяет стыковать множество филиалов на одном концентраторе.
Решение должно быть технически гибким и приземлять различные типы туннелей в различных конфигурациях (VTI, GRE…). Конфигурация поддерживает основные типы туннелей, требование закрываем.
Как мы видим, применение эскалаторной топологии закрыло наиболее важные из наших требований. Какие вопросы нам осталось закрыть?
Решение не должно вовлекать межсетевой экран в динамическую маршрутизацию.
Решение должно быть отказоустойчивым.
Решение должно быть управляемым.
Решение не должно быть проприетарным.
Решение должно поддерживать динамическую маршрутизацию.
Решение дожно быть масштабирумым.
Мы обязательно закроем их в следующих статьях.
До новых встреч!
