IPsecHub+. Сложные сценарии

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

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

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

Сразу скажу, что пока что эти сценарии рассматриваются без учета отказоустойчивой схемы IPsec-концентратора. Описание отказоустойчивой схемы будет приведено в следующей статье. Она значительно усложнит нашу топологию, поэтому для простоты восприятия стыковку сложных сценариев мы рассмотрим на примере standalone-концентратора.

Итак, с чем мы можем столкнуться?

Скрытие адресов ЦОД или филиалов

Некоторые задачи, обычно связанные со сферой ИБ, предполагают скрытие адресов ЦОД в филиалах, или же наоборот, ЦОД не должен видеть реальные адреса филиалов. Такое требование иногда встречается в зонах повышенной безопасности (DMZ). Такая задача также иногда актуальна и в том случае, когда вам нужно вписать какой-то ну очень старый филиал в новую схему адресации. Иногда одна сеть, не попадающая в «феншуй», может сильно осложнить конфигурацию и потребовать создание исключений в префикс-листах, увеличение конфигурации и тому подобное. Да это просто некрасиво, в конце концов. При этом изменение адресации филиала в некоторых случаях либо нецелесообразно, либо вообще невозможно.

Давайте рассмотрим пример, когда мы хотим скрыть один из филиальных адресов в нашей инфраструктуре. Кто-то догадался назначить на нужный нам ресурс в филиале адрес 192.168.1.1. Из-за этого от удаленных пользователей, работающих через vpn, постоянно идут жалобы о недоступности этого ресурса. Происходит это из-за того, что 192.168.1.0/24 — это одна из самых популярных сетей у домашних роутеров.

Что нам нужно сделать для сокрытия реального адреса филиала?

• Вместо одиозного 192.168.1.1 выделим ему нейтральный 100.64.1.1 из RFC6598. Основная процедура подмены будет происходить в целевом красном VRF.

• В этом же VRF нам нужно будет создать соответствующее правило DNAT.

• Не забываем также оставить маршрут на реальный адрес хоста в этом VRF. Это позволит корректно смаршрутизировать трафик после DNAT-процедуры.

• Добавляем маршрут на суррогатный адрес на межсетевом экране и в VRF ipsecTo. Здесь нужно будет указать в качестве шлюза  соответствующий адрес veth-интерфейса, который находится в целевом красном VRF.

Вот что у нас получается, см. рис. 1.

В нижней части рис. 1 вы можете отследить, как будут меняться заголовки IP дейтаграммы по мере прохождения всех правил DNAT. В данном случае оно у нас единственное.

Исходная задача достигнута. Единственное место, где мы будем оперировать нежелательным адресом 192.168.1.1 — это изолированный красный VRF. Во всей остальной сети нежелательный адрес будет вписан в «феншуй».

Ситуация с конфликтами адресов 

Давайте теперь рассмотрим более сложный сценарий. Часто пристыковка удаленной площадки может быть сопряжена с дополнительными трудностями из-за того, что удаленная площадка находится не под нашим управлением. Помимо проблем с диагностикой мультивендорного IPsec может возникнуть, например, сложность с пересечением адресного пространства удаленной площадки с нашим ЦОД. Также мы можем столкнуться с наложением номеров as в BGP. Об этом чуть позже.

Как мы можем решить подобные трудности при помощи нашего концентратора? Здесь уже придется делать вот что:

• Присваивать суррогатный адрес удаленному хосту.

• Прикрывать суррогатным адресом также наши соединения из ЦОД.

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

Давайте рассмотрим как раз такой пример. Хост в филиале имеет такой же адрес, как и хост в ЦОД — 172.16.0.1.

Что мы можем сделать в такой ситуации? Нам поможет так называемое каскадирование целевого VRF.

• Создаем VRF Site 1 INT: нам следует создать VRF первого эшелона, где мы сначала закроем наш адрес суррогатным. Назовем его «Site 1 INT», так как он маршрутизирует трафик до реального адреса нашего ЦОД (internal addresses).

• В этом же VRF обязательно нужно выполнить прикрытие нашего реального адреса суррогатным. 

• Создаем VRF Site 1 EXT: затем приступим к созданию VRF «Site 1 EXT», куда будет помещен GRE до удаленной площадки.

• В VRF Site 1 EXT мы будем преобразовывать суррогатный адрес удаленной площадки в реальный (external addresses).

• И последниее — эти два VRF следует соединить при помощи все того же veth, обеспечив межу ними связность. 

Еще важное по маршрутизации. В VRF «site 1 INT» мы должны создать маршрут, ведущий до суррогатного хоста филиала 100.64.1.1 через veth, находящийся в VRF «site 1 EXT». То же самое в VRF «site 1 EXT» — создаем маршрут, ведущий до суррогатного хоста ЦОД 100.64.0.1 через veth, находящийся в VRF «site 1 INT»

Результирующую схему см. на рис. 3. Схема достаточно объемная, поэтому лучше кликнуть на нее для увеличения.

При помощи такой конструкции нам удалось полностью изолировать пересекающиеся адреса филиала и ЦОД. Но что делать, если у нас пересечение не хостов, а целых подсетей?

Принятие пересекающихся подсетей

Предлагаю рассмотреть сценарий, когда мы обеспечиваем стыковку с контрагентом целой подсетью, а не только одним целевым хостом. В этом случае нам поможет технология Netmap. Она поддерживается не на всех платформах, но, например, она представлена на iptables в Linux-системах. С ее помощью мы можем обеспечивать прикрытие не только хостов, но и целых подсетей. Например, заменить 192.168.1.0/24 филиала на 100.64.1.0/24. Хост при такой конфигурации будет прикрыт соответствующим суррогатным адресом по правилу «подменяются первые три отктета, последний остается». 

Давайте посмотрим результирующую схему, см. рис. 4.

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

Итоги

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

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

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

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

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

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

Можно сказать, что сегодняшняя статья была про управляемость и гибкость. Мы показали, что при помощи концентратора можно решать самые разные задачи без применения дополнительных инструментов. Добавили в список решенных одно из требований. Что у нас осталось?

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

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

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

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

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

Решение этих задач мы обсудим в следующих статьях цикла.

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