Всем привет! На связи Николай Едомский, руководитель группы сетевых инженеров в ЕДИНОМ ЦУПИС.
Представляю вашему вниманию вторую статью из цикла "IPsecHub+".
Первая статья цикла находится здесь. В первой статье цикла мы немного погрузились в специфику нашей технологической базы, а теперь давайте рассмотрим классический сценарий построения GRE-over-IPsec туннеля. Это будет первый шаг к реализации нашего решения «IPsecHub+».
Итак, сразу к делу. Давайте представим, что с ЦОД (на юге) нам нужно связать два филиала через сеть Интернет (на севере).
Проблематика построения IPsec-хаба
Как и в случае, описанном в первой статье цикла, в этой упрощенной топологии пограничные маршрутизаторы являются по совместительству IPsec-терминаторами. На их WAN-интерфейсах настроены адреса, которые маршрутизируются в сети Интернет ("белые" адреса). См. рис. 1.
Давайте подумаем, чем нас может не устраивать такая топология?
Отсутствие возможности межсетевого экранирования. IPsec-концентратор напрямую соединен с каналами связи с сетью Интернет, поэтому мы не можем централизованно ограничить трафик из сети Интернет до IPsec-концентратора и обратно. Не говоря уже о реализации IPS/IDS и прочих расширенных средств защиты.
Риск критической утилизации ресурсов пограничного маршрутизатора. IPsec - это довольно ресурсоемкий стек протоколов. Его активное применение может вызвать проблемы в работе всего пограничного маршрутизатора, что негативно повлияет на все сервисы, которые он обслуживает. То есть вообще на всю компанию, если мы говорим про маршрутизатор ЦОД.
Трудность масштабировать IPsec. Если нам потребуется расширить ресурсы IPsec, то это заставляет менять пограничный маршрутизатор целиком, хотя он, возможно, с ролью маршрутизации справляется в полной мере. Такое масштабирование мы назовем вертикальным.
Самое критичное из недостатков - это, конечно же, вопросы межсетевого экранирования. Давайте сначала разберемся с ними. У нас может выйти такая вот схема. См. рис. 2.
IPsec-концентратор в данном случае вынесен в качестве отдельного узла ниже пограничного сегмента. Обозначенные выше недостатки дизайна устранены. Мы контролируем межсетевым экраном входящий и исходящий шифрованный трафик до IPsec-концентратора.
Но возникает новая проблема. Расшифрованный трафик из филиалов в этом случае перестает идти через межсетевой экран. Скверная история. Любая станция филиала имеет прямой доступ до ЦОД.
Устраняя этот недостаток топологии, мы можем построить вот такую схему. IPsec-концентратор мы поставим за межсетевой экран. См. рис. 3.
Расшифрованный трафик пойдет через межсетевой зкран. Но отдел иноформационной безопасности говорит, что трафик между филиалами мы тоже должны направлять на межсетевой экран. Ситуация осложняется. Ввиду того, что все GRE и VTI туннели находятся на одном IPsec-концентраторе, который по факту является еще и маршрутизатором, трафик между ними идет по connected-маршрутам. Заворот на межсетевой экран происходить не будет.
Мы не будем рассматривать в качестве решения этой проблемы PBR и прочие технологии source routing, так как это значительно усложнит конфигурацию, да и не все IPsec-концентраторы поддерживают PBR или его аналоги.
Задача межсетевого экранирования направления «филиал-филиал» может быть решена выделением отдельного IPsec-концентратора для каждого из филиалов. Схема приведена ниже, см. рис. 4.
В итоге мы экранируем:
Входящий и исходящий шифрованный трафик до IPsec-концентратора.
Расшифрованный трафик от IPsec-концентратора до ЦОД.
Трафик между филиалами.
В этом случае вопрос межсетевого экранирования решен. IPsec-концентратор каждого филиала соединен с межсетевым экраном, и единственный путь по направлению «филиал-филиал» лежит через межсетевой экран.
Эта схема решает все задачи экранирования. Но при этом у нее есть серьезные недостатки.
Она очень плохо масштабируется. Если филиалов у нас много, и на каждый филиал мы выделяем по одному концентратору, то каждому IPsec-концентратору в ЦОД придется выделять по одному внешнему адресу, что весьма расточительно.
Большое количество виртуальных машин создаст дополнительную нагрузку в плане администрирования и мониторинга.
Тяжело реализовать отказоустойчивость. Концентраторов и так будет много, а если их умножить на два…
забегая вперед, эта схема не позволит использовать bare-metal IPsec со всеми его плюсами.
Минусы весьма серьезные. Рассматривать в качестве основного вектора развития мы ее не будем, нужно искать другой путь.
Целепостановка
Давайте теперь формализуем все требования к дизайну, который нам предстоит создать.
трафик между филиалами должен проходить через централизованный межсетвой экран.
Шифрованный трафик между ЦОД и филиалами должен проходить через централизованный межсетвой экран.
Туннели должны терминироваться на одном IPsec-концентраторе.
Решение дожно быть масштабирумым.
Решение должно быть отказоустойчивым.
Решение должно быть гибким и управляемым.
Решение не должно быть проприетарным.
Решение должно быть технически гибким и приземлять различные типы туннелей в различных конфигурациях (VTI, GRE…).
Решение должно поддерживать динамическую маршрутизацию.
Решение не должно вовлекать межсетевой экран в динамическую маршрутизацию.
Про последнее требование скажу отдельно. После получения богатого опыта эксплуатации различных NGFW мы пришли к выводу, что участие NGFW в процессах динамической маршрутизации создает намного больше проблем, чем приносит пользы. Возможно, «мы просто не умеем их готовить», но тем не менее. Мы решили во что бы то ни стало отказаться от применения BGP, OSPF и другой динамики на межсетевом экране. Это требование продиктовано разбором многих аварий, работы с поддержкой вендора и обобщением всего этого опыта. Мы пришли к выводу, что межсетевой экран должен работать только на статической маршрутизации.
Сегментирование
Начнем с поиска концептуального решения самой главной нашей задачи, которую мы решили в предыдущем примере не самым элегантным способом - задачи изоляции трафика между филиалами.
Как уже было сказано выше, решением заворота трафика на межсетевой экран в рамках одной таблицы маршрутизации могут быть технологии вроде PBR (+ route tables и тп). Но это значительно усложнит конфигурацию и сведет на «нет» все плюсы динамической маршрутизации. К тому же, не все IPsec-концентраторы поддерживают PBR как таковой. Мы же ищем универсальное решение.
Давайте посмотрим в сторону решений, предполагающих использование разных таблиц маршрутизации - попробуем разместить интерфейсы туннелей филиалов в разные таблицы.
Но здесь нужно учесть один нюанс. Погружение GRE-туннелей в отдельные VRF не выглядит чем-то сложным. Но ведь IPsec-туннели мы ни в какие VRF не погружаем. Они все приземляются в одном VRF (default в данном случае) на один IP-адрес. И как это будет работать?
Основной трюк этого решения заключается в том, что вы можете держать IPsec-туннель в основной таблице маршрутизации, а GRE-туннель, который шифруется этим IPsec, перенести уже в другой VRF. Такой подход поддерживает достаточно много операционных систем. Например, IOS от Cisco, а также реализации на Linux/Unix системах.
Такая схема возможна за счет того, что IPsec-деймон создает ловушку-перехватчик трафика на уровне, находящимся ниже уровня логического разлеления трафика на VRF. Это означает, что IPsec-деймон перехватит трафик, совпадающий с его списками шифрования, даже в том случае, если этот трафик был сгенерирован в каком-либо пользовательском VRF.
Графическое представление VRF
Пару слов про визуализацию. Я не обнаружил у кого-либо из вендоров готовой схемы визуализации, которая позволяла бы просто и понятно отображать структуру VRF на устройстве, а также связи между разными VRF. Я решил представить следующие условные обозначения. Далее все построения и схемы будут строиться на такой визуализации.
Для схематичного обозначения VRF на каком-либо маршрутизаторе мы будем использовать горизонтальные линии, идущие от вертикали. См. рис. 5.
А вот как будет выглядеть, например, погружение нескольких интерфейсов в "красный" VRF. См. рис. 6.
При помощи принятого графического представления мне удалось визуализировать даже достаточно сложные схемы взаимодействия между различными VRF, созданными на разных устройствах.
Построение базовой топологии концентратора
Итак, давайте вернемся к практике и построим топологию, где IPsec-туннель будет находиться в default VRF (или можно сказать, что не будет находиться в каком-либо VRF), а GRE-туннель, который зашифрован этим IPsec-туннелем, будет уже находиться в "красном" VRF.
Итоговая схема представлена на рис. 7.
Итак, что мы в итоге сделали?
создали GRE-туннель между IPsec-концентратором с концами 4.4.4.4 (ЦОД) и 8.8.8.8 (филиал).
поместили GRE-интерфейс в отдельный VRF, который назвали «Site 1», на схеме - «красный VRF».
зашифровали этот туннель при помощи IPsec в VRF default.Как итог - IPsec-концентратор филиала будет упаковывать в GRE-дейтаграммы весь трафик, направленный в GRE-туннель, после чего эти GRE-дейтараммы будут зашифрованы. В ЦОДе дейтаграмма будет расшифрована, а трафик, инкапсулированный в GRE, будет декапсулирован уже в нужный нам VRF.
Хорошо, а как нам организовать в этом дизайне interVRF-маршрутизацию? Здесь все просто. На IPsec-концентраторе нам достаточно создать на каждый VRF по vlan-интерфейсу и погрузить их в соответствующие VRF. И уже средствами классического свитчинга мы подадим эти vlan на межсетевой экран, где также будут созданы соответствующие vlan-интерфейсы. Топология представлена на рис. 8.
А вот как будет выглядеть пристыковка второго филиала. См. рис 9.
Этот дизайн решает все поставленные задачи. Предлагаю читателю самостоятельно отследить все возможные направления трафика и убедиться, что все направления проходят через межсетевой экран.
Но в чем может быть проблема? Как ни странно, проблема может заключаться в количестве vlan-интерфейсов, которые нужно содавать на фаерволе при введении в экспулатацию каждого из филиалов. Даже не так - проблема заключается в том, что межсетевой экран вообще задействован в процедуре создания нового филиала. Ну или его удаления.
Особенности масштабирования
Все задачи по фильтрафии трафика на всех направлениях выполняются. Трафик между филиалами всегда будет идти через межсетевой экран, тк он является по сути inter-VRF маршрутизатором. Но у такой схемы есть одна неприятная особенность - она плохо масштабируется на уровне межсетевого экрана. Представим, что у нас возникла необходимость подключить к концентратору достаточно большое количество филиалов. И их число может увеличиваться или уменьшаться каждый месяц. Например, такая ситуация может случиться, если вы решили воспользоваться услугами облачного провайдера и решили стыковать к вашему ЦОД много VPS (virtual private server) или VPC (virtual private cloud). Обе этих сущности можно пристыковать к ЦОД по нашей схеме.
При таких вводных данных получается, что нам нужно постоянно добавлять на концентраторе помимо GRE-интерфейсов также стыковочные vlan-интерфейсы, которые соединяют целевые VRF с межсетевым экраном, а также создавать эти интерфейсы на самом межсетевом экране. При небольшом количестве VRF это, возможно, и не вызовет особых сложностей. Но если VRF нужно добавлять (или удалять) каждую неделю, то становится очевидно, что:
этот процесс лучше автоматизировать
лучше вообще исключить из этого процесса межсетевой экран.
Добавление интерфейса - это достаточно рискованная операция, если речь идет про центральный межсетевой фаервол компании. Практический опыт показал, что иногда эти операции ведут к возникновению накопительного эффекта, который в итоге может привести к очень неприятным последствиям. А на некоторых межсетевых экранах количество сабинтерфейсов и вовсе ограничено.
В итоге у нас сформировалась дополнительная цель - максимально локализовать рутинные процессы. То есть по возможности сконцентрировать их на самом IPsec-концентраторе.
Достижению этой цели будет посвящена следующая статья цикла. Спасибо за внимание, и до новых встреч!
Навигация по циклу:
