Всем привет! На связи Николай Едомский, руководитель группы сетевых инженеров в ЕДИНОМ ЦУПИС.
Представляю вашему вниманию первую статью из цикла "IPsecHub+".
В этом цикле статей я хотел бы поделиться своим обобщенным и систематизированным опытом применения стека протоколов IPsec. Накопленный опыт преобразовался в цельное решение, которое позволяет выполнить ряд сложных задач, продиктованных реалиями динамично развивающегося бизнеса и сложным сетевым ландшафтом. Оно хорошо масштабируется, реализуется на разных платформах и легко автоматизируется.
Кому будет полезен цикл статей:
опытным специалистам, перед которыми стоит задача по организации IPsec-концентратора компании.
архитекторам, желающим расширить свой технический кругозор.
Обзор технологии IPsec
Давайте сначала вспомним основы. Что нам нужно помнить о стеке протоколов, чтобы уверенно ориентироваться в вопросе?
Полагаю, каждый сетевой инженер сталкивался с необходимостью обеспечить связность между географически удаленными площадками. Простейший пример - к ресурсам ЦОД должны иметь доступ все офисы компании.
Вариантов решения задачи связности двух или более точек великое множество. Мы же остановимся на рассмотрении конкретного набора технологий, а именно - IPsec в связке с различными протоколами туннелирования. Выбор связан прежде всего с тем, что IPsec - это один из старейших стеков протоколов, его поддерживают все крупные производители, и каждый инженер, наверное, хотя бы раз сталкивался с ним в своей практике.
Итак, чем нам поможет IPsec при организации связности между филиалами? Построение логической или физической линии связи происходит как правило либо через сеть Интернет, либо через приватные каналы (L3VPN, L2VPN…). И даже если связность осуществляется через L1-канал, проходящий по территории третьей стороны, то уже стоит задуматься о шифровании трафика.
Необходимость шифровать трафик будет фундаментальным требованием в нашем дальнейшем обсуждении. Нам нужна схема, которая прежде всего поможет зашифровать данные, при этом оставаясь максимально отказоустойчивой, масштабируемой и управляемой.
Самая простая топология, подразумевающая применение IPsec, выглядит примерно следующим образом - см. рис. 2.
Пограничные маршрутизаторы подключены к сети Интернет, они же являются IPsec-концентраторами. Для начала давайте вспомним, какие два основных вида топологии обычно предполагает применение IPsec. Это важно для погружения в дальнейший контекст проблематики решения.
С вашего позволения, я оставлю за рамками этой статьи обсуждение того, как именно собирается логический IPsec-туннель. Это достаточно объемная тема, которая весьма подробно разобрана в других тематических статьях, в том числе и на этом замечательном ресурсе. Более подробно про устройство IPsec с уклоном в безопасность можно почитать, например, здесь. Мы предположим, что первая и вторая фазы у нас собираются без проблем, и мы уже вышли на этап принятия решения о том, как мы будем заворачивать трафик в построенный IPsec-туннель. Вкратце рассмотрим две основных топологии IPsec и их главные отличия.
Ниже мы рассмотрим основные виды топологий, которые предполагает использование стека протоколов IPsec.
Policy-based IPsec
Его еще иногда называют «классическим» IPsec. Он предполагает, что с обеих сторон IPsec-туннеля находится известный и строго определенный набор подсетей, и мы явно указываем, какие сети с обеих сторон допускаются к взаимодействую через IPsec-туннель. На рис. 3 показан пример такой топологии.
На примере у ЦОД на маршрутизаторе и концентраторе IPsec настроен адрес 4.4.4.4. При этом мы хотим, чтобы хост 172.16.0.1 был бы доступен из филиала.
А на филиальном маршрутизаторе и концентраторе настроен адрес 8.8.8.8, и хост 192.168.1.1 должен иметь связность с хостом в ЦОДе.
Для обеспечения связности мы должны создать зеркальный список доступа в ЦОД и в филиале, который строго задает, какие хосты могут взаимодействовать между собой через IPsec-туннель.
Особенности этого решения:
его тяжело сделать отказоуйстойчивым. Топология получается статичной, так как приходится строго писать маршрут до удаленных подсетей через конкретный маршрутизатор, на котором реализован IPsec-туннель. Этот вопрос в целом решаем, и некоторые вендоры даже выпустили расширения, позволяющие устранить этот недостаток. Например, RRI от Cisco. Это расширение позволяет создать статический маршрут на устройстве, если IPsec-сессия установлена успешно. Но, так или иначе, это все либо проприетарные расширения, которые поддерживаются каким-то определенным вендором, либо обходное решение вроде SLA tracking.
Отсутствует логический интерфейс туннеля. В некоторых случаях наличие полноценного интерфейса в системе критически важно.
Плохо управляется. При необходимости добавить или удалить участников в взаимодействия проходится менять конфигурацию на обеих сторонах туннеля.
Из основных плюсов можно отметить наилучшую совместимость из всех видов реализации IPsec-туннелей. Классический IPsec поддерживается подавляющим большинством IPsec-концентраторов.
Route-based IPsec
В противоположность к «классичекому» IPsec, эта топология предполагает, что между двумя площадками сначала строится IP-туннель (например, всем известный GRE), а затем трафик этого туннеля уже шифруется при помощи IPsec.
Таким образом, для того, чтобы зашифровать трафик и направить его на удаленную площадку, достаточно просто смаршрутизировать пакеты через соответствующий туннельный интерфейс. Что самое важное - мы не привязываемся к конкретным подсетям на одной и на другой сторонах туннеля. Также мы можем реализовать на IP-туннеле динамическую маршрутизацию при помощи любого удобного нам протокола.
Например, в этой статье можно подробнее прочитать про типы туннельных интерфейсов.
Классический GRE
На рис. 4 изображена топология связности двух филиалов с применением зашифрованных GRE-туннелей. Так называемый GRE over IPsec.
В случае с применением GRE в качестве туннелирующего протокола происходит двойная инкапсуляция - сначала клиентский трафик упаковывается в GRE-дейтаграмму, а уже GRE-дейтаграмма упаковывается в IPsec-дейтаграмму с типом IP 50 (или udp-пакет в случае ESP over UDP).
Ниже представлена визуализация такого решения (стянута из брошюры Cisco). См. рис. 5.
Для создания такого туннеля мы должны будем указать, с какого адреса и на какой адрес будет формироваться дейтаграммы GRE-туннеля, то есть определить концы GRE-туннеля. Часто в качестве этих адресов выбираются внешние IP-адреса концентраторов.
Далее мы назначаем непосредственно адресацию на сами GRE-интерфейсы. Это позволит обеспечить IP-связность уже внутри туннеля. Трафик между двумя этими адресами уже будет инкапсулирован в GRE-дейтаграмму и, следовательно, зашифрован при помощи IPsec.
GRE через непубличные адреса
Стоит также отметить возможность построения GRE-туннеля с использованием в качестве двух концов туннеля так называемых «серых» адресов.
Это адреса, которые не маршрутизируются в публичном пространстве сети Интернет (например, RFC1918). Когда это может быть необходимо? Например, в том случае, когда публичный IP-адрес одной из сторон неизвестен заранее, то есть является динамическим. Тогда мы уже не сможем использовать публичный адрес со стороны филиала в качестве конца GRE-туннеля, тк он может меняться, а GRE требует статического назначения адреса в качестве конца туннеля. Мы сейчас не рассматриваем технологии вроде DMVPN, так они являются проприетарными и обычно имеют достаточно ограниченную совместимость. Да, GRE тоже является проприетарным протоколом, разработанным фирмой Cisco, но сейчас его поддерживает подавляющее число производителей. Помнится, Cisco в какой-то момент даже открыла его для всеобщего пользования.
В дальнейшем мы будем рассматривать его как технологическую базу нашего решения. На примере ниже мы рассмотрим ситуацию, когда филиал имеет динамический публичный адрес. См. рис. 6.
Как будут строиться IPsec и GRE туннели в этом случае?
В качестве IP для двух концов GRE-туннелей на обоих сторонах мы возьмем адреса из пространства RFC6598, которое не маршрутизируется в сети Интернет. Назначим статические адреса в качестве концов GRE как со стороны ЦОД, так и со стороны филиала. Адресация интерфейсов GRE может быть произвольной.
Запросы на построение IPsec-туннелей в ЦОД мы должны будем принимать с любого IP-адреса, тк не знаем, какой адрес будет назначен филиальному маршрутизатору. Будет не лишним принять дополнительные меры по обеспечению безопасности в этом случае.
Далее в конфигурации IPsec-деймона нам следует указать, что следует шифровать все IP-дейтаграммы с типом 47 (GRE) и с адресами источника-назначения наших концов GRE-туннелей из диапазона RFC6598.
Что произойдет при такой конфигурации? После создания сетевым стеком операционной системы GRE-дейтаграммы IPsec-деймон перехватит ее, так как она будет совпадать с правилами шифрования, инкапсулирует дейтаграмму в IPsec и отправит далее согласно маршруту. «Серые» адреса, используемые в качестве концов GRE-туннелей, не будут в этом случае выходить в публичное пространство, тк будут инкапсулированы в IPsec-дейтаграммы. А IPsec, в свою очередь, у нас выстроен уже с использованием публичных адресов.
Из минусов данного решения стоит отметить необходимость открывать IPsec-концентратор для взаимодействия со всем публичным пространством.
GRE over IPsec или IPsec over GRE?
Стоит также упомянуть, что построение шифрованного GRE-туннеля может быть выполнено не только представленным выше способом. Мы описали классический вариант - это когда вся IP GRE-дейтаграмма инкапсулируется в IPsec-дейтаграмму. То есть по факту создается новая IP-дейтаграмма уже со своими IP-заголовками (src, dst, IP type и тп).
При этом IPsec работает в так называемом туннельном режиме - исходная IP-дейтаграмма клиента упаковывается в совершенно новую IP-дейтаграмму.
Однако, бывают случаи, когда необходимо сохранить заголовки исходной GRE-дейтаграммы (или любой другой клиентской) нетронутыми. Тогда нам поможет транспортный режим IPsec. В этом режиме IPsec-деймон шифрует только payload исходой IP-дейтаграммы, оставляя нетронутым IP-заголовки. Топология такого взаимодействия представлена на рис. 7.
Особенно важно то, что будет сохранен IP proto 47 (GRE) в поле IP-дейтаграммы. Это бывает очень полезно в случае, когда, например, оператор блокирует ESP-пакеты (то есть IP type 50, основной транспортный протокол IPsec, или UDP порт 4500 в случае NAT-T). Также стоит сказать, что в этом сценарии будет корректно отрабатывать NAT для IP GRE-дейтаграммы. Технология NAT изменит src или dst в полях GRE IP-дейтаграммы, при этом не затронув зашифрованную полезную нагрузку пакета. Это может также быть полезным в некоторых сценариях. Приятным плюсом такого режима также является факт, что экономится 20 байт полезной нагрузки, тк мы не создаем новую IP-дейтаграмму со всеми ее заголовками.
VTI
Немного по другому принципу работает VTI over IPsec. В этом случае заворот трафика в IPsec-туннель происходит на основе внутренних механизмов операционной системы. Предполагается, что в системе создается VTI-интерфейс, где будет указана определенная марка (mark). Иногда они называются ключами (keys). В этом интерфейсе, по аналогии с GRE, также указывается, до какой удаленной станции будет выстроен VTI-туннель (src IP и dst IP VTI-туннеля). На интерфейсах VTI также предполагается назначение адресов. Для удаленной стороны конфигурация IPsec в целом идентична. Она должна содержать в себе указание той марки, которая была присвоена соответствующему VTI-интерфейу. При этом инкапсуляция трафика происходит только при его направлении в VTI-туннель. Создания новой IP-дейтаграммы, как в случае с GRE, не происходит. VTI-туннель служит только для заворота трафика в IPsec-деймон.
Топология с использованием VTI показана на рис. 8.
Итак, основные особенности GRE и VTI:
Из главного плюса реализации GRE хотелось бы отметить хорошую совместимость (GRE более распространен в качестве протокола туннелирования).
Также из плюсов GRE - у нас есть возможность при необходимости выключить шифрование трафика (например, в случае сильной утилизации вычислительных мощностей IPsec-машины), что в случае VTI невозможно. GRE сам по себе уже создает туннелирование, хоть и без шифрования. VTI же туннелировать без IPsec не сможет.
Также VTI требует туннельного режима работы IPsec, тогда как GRE можно запускать в транспортном режиме. В некоторых сценариях это может стать весомым аргументом.
Ввиду того, что VTI сам по себе не создает отдельную IP дейтаграмму, он требует меньше накладных расходов (минус одна IP-инкапсуляция
Также VTI обычно более компактен в настройках.
Но в обоих случаях в системе создаются полноценные логические интерфейсы со своей адресацией, что позволяет значительно расширить область применения нашего IPsec-туннеля.
На этом хотелось бы закончить обзорную часть технологии IPsec. Это очень поверхностное рассмотрение стека протоколов IPsec, но для дальнейшего контекста нам этого будет достаточно. В следующей статье цикла мы приступим к формированию требований для дизайна нашего IPsec-концентратора и рассмотрим основой вектор построения этого дизайна.
Спасибо за внимание, и до новых встреч!
