IPsecHub+. Отказоустойчивость и динамическая маршрутизация

Всем привет! На связи Николай Едомский, руководитель группы сетевых инженеров в ЕДИНОМ ЦУПИС.

Представляю вашему вниманию пятую статью из цикла «IPsecHub+«.

В предыдущих статьях мы рассмотрели самые разные функции нашего IPsec-концентратора. При этом за кадром оставался вопрос, без которого не обходится ни одна серьезная топология — вопрос отказоустойчивости. В этой статье мы рассмотрим способы сделать наш концентратор отказоустойчивым.

---

Динамическая маршрутизация

Ну а какая же отказоустойчивость обойдется без динамической маршрутизации, спросите вы. И будете правы. Во всех предыдущих примерах мы рассматривали использование исключительно статических маршрутов. Разумеется, в условиях предприятия такая конфигурация нежизнеспособна — думаю, не нужно уточнять, почему следует все же внедрить динамическую маршрутизацию. 

Внедрение любого протокола динамической маршрутизации на наш IPsec-концентратор не составит труда, так как в основе топологии лежат полноценные логические интерфейсы — GRE, VTI, veth и VLAN. Я предлагаю рассмотреть пример внедрения на концентратор протокола BGP, так как этот протокол позволит создать наиболее гибкую схему.

Все, что нам нужно сделать — это назначить на каждый из наших VRF автономную систему и создать связность по BGP между всеми интерфейсами-участниками. 

Вот как это будет выглядеть:

По схеме видно, что мы соединили BGP-соседством все узлы, которые находятся на пути следования трафика. Общая концепция динамической маршрутизации такая:

• ipsecFROM отдает в целевые VRF филиалов маршруты ЦОД

• ipsecTO принимает маршруты филиалов из их целевых VRF.

• Маршруты ЦОД попадают в филиалы через GRE из целевого VRF.

• Межсетевой экран по-прежнему выступает как inter-VRF маршрутизатор.

Направление подачи префиксов указано на схеме стрелками. При этом на каждый VRF следует выделить отдельный as, это поможет избежать многих проблем, связанных с as loop и тп и путаницы с AD, так у iBGP и eBGP AD разные.

И главное — всегда сдедует помнить главные правила динамической маршрутизации на эскалаторной топологии.

• Эскалаторы к филиалам спускают трафик только до конкретного филиала, и никуда более.

• Эскалаторы в ЦОД поднимают его только до межсетевого экрана, и никуда еще.

Важно очень строго следить, какие префиксы вы отдаете и принимаете на ipsecTO и на ipsecFROM. Вся схема может развалиться, если вы, например, отдадите на ipsecFrom маршруты филиалов. Направление отдачи должно быть строго как на схеме ниже. Префиксы филиалов отдаем через ipsecTO, префиксы ЦОД — через ipsecFROM.

Ситуация, представленная на картинке ниже, недопустима. Из VRF зеленого филиала маршрут через VRF ipsecFROM  протек в VRF красного филиала. Трафик в этом случае между филиалами на указанном направлении не будет завернут на межсетевой экран. Это развалит нашу схему, так как возникнет асимметричное прохождение трафика через межсетевой экран.

---

Отказоустойчивость

После того, как мы реализовали BGP на нашем концентраторе, мы можем поговорить о базовой отказоустойчивости нашего решения. Отказоустойчивость будет заключаться главным образом в аппаратном резервировании наших концентраторов. 

Резервирование в филиалах мы рассмотрим чуть позже.

В чем заключаются основные задачи резервирования?

• мы должны зарезервировать точку принятия трафика от межсетевого экрана. Ввиду того, что межсетевой экран оперирует только статической маршрутизацией, мы должны представить ему точку, которая всегда сможет обработать трафик до филиалов. В простейшем случае это может быть VRRP домен (плавающий IP адрес).

• Мы должны зарезервировать точку принятия трафика от филиалов. Для этого на филиальном маршрутизаторе мы добавляем дополнительный GRE-туннель до второго IPsec-концентратора ЦОД. 

Давайте разместим еще один IPsec-концентратор и впишем его в нашу топологию. Нам достаточно будет клонировать конфигурацию уже существующего окружения. Нужно будет только изменить внешний адрес концентратора, куда будет терминироваться IPsec-туннель, и адреса концов GRE-туннеля с непосредственно адресами GRE-интерфейса. Адреса veth-интерфейсов могут оставаться неизменными, так как не участвуют во взаимодействии с хостами вне внутреннего контура концентратора.

Давайте посмотрим, как будет выглядеть такая схема. Уважаемые читатели, просьба кликать на картинку для более комфортного просмотра, так как мы рассматриваем уже предельно сложные сценарии, и схемы таких сценариев, к сожалению, получаются весьма громоздкими.

Мы видим, что в VRF ipsecTO мы организовали простейший VRRP-домен с плавающим адресом. Именно на этот адрес будет нацелен статический маршрут до сетей филиалов на межсетевом экране. 

BGP-соседство в ipsecTO.

В такой конфигурации есть очень важный момент. Обратите внимание на то, что мы также связали BGP-соседством интерфейсы IPsec-концентраторов в VRF ipsecTO. Зачем это было сделано?

В случае, если на IPsec-концентраторе случится развал IPsec-туннеля до филиала, и он при этом будет VRRP-мастером, то он не сможет смаршрутизировать пакеты, идущие до филиала, тк уже не будет получать через GRE-туннель маршрутов. Чтобы этого не произошло, мы связали BGP-соседством оба IPsec-концентратора. И если хотя бы один из туннелей до филиала работоспособен, то пакеты смаршрутизируются корректно. VRRP-мастер будет получать маршрут до филиала через соседний IPsec-концентратор в случае, если его собственный туннель по каким-то причинам перестанет работать.

Отказоустойчивость и NAT

Сильно усложняется топология в случае, когда мы резервируем схемы с использованием NAT. Основная проблема заключается в том, что когда у нас появляется альтернативный маршрут в ЦОД и в филиалы, возникает риск прохождения запросов через один IPsec-концентратор, а ответов — через другой. Пример такого запроса можно увидеть на схеме ниже. 

Ввиду того, что NAT-запись будет создана только на концентраторе, принявшем запрос, мы должны и ответ также маршрутизировать через него. Сделать это можно разными способами, но наиболее надежный такой.

Закрыть запросы на одном IPsec-концентраторе одной сетью, а на другом IPsec-концентраторе — другой.

Добавляем новую суррогатную сеть, которой будут закрываться соединения из ЦОД через второй концентратор — 100.65.0.0/24. Настраиваем соответствующие NAT-правила на втором IPsec-концентраторе:

Конфигурация по маршрутам в общей схеме будет следующая. Главное — это обеспечить нужное направление трафика до суррогатных подменных префиксов.

А конфигурация динамической маршрутизации при схеме с NAT будет такая. Нам нужно будет отдать в филиал соответсвующие прикрывающие сети с каждого из концентраторов.  

Итоги

Давайте подведем итог этой итерации построения нашей схемы. Какие требования к нашей топологии мы выполнили в этот раз?

• трафик между филиалами должен проходить через централизованный межсетвой экран.

• Шифрованный трафик между ЦОД и филиалами должен проходить через централизованный межсетвой экран.

• Туннели должны терминироваться на одном IPsec-концентраторе.

• Решение должно быть технически гибким и приземлять различные типы туннелей в различных конфигурациях (VTI, GRE…).

• Решение должно быть гибким управляемым.

• Решение должно поддерживать динамическую маршрутизацию.

Требование выполнено. Мы реализовали в нашей схеме динамическую маршрутизацию при помощи протокола BGP.

• Решение не должно вовлекать межсетевой экран в динамическую маршрутизацию.

Требование выполнено. Мы реализовали динамическую маршрутизацию без вовлечения межсетевого экрана в процесс BGP. 

• Решение должно быть отказоустойчивым.

Тоже закрыли. Наше решение сейчас можно назвать отказоустойчивым. Мы зарезервировали аппаратный узел IPsec-концентратора.

• Решение не должно быть проприетарным.

• Решение дожно быть масштабирумым.

У нас осталось всего два пункта. Их закрытие мы рассмотрим в следующей статье цикла.

Спасибо за внимание, и до новых встреч!