SD-Access без DNAC и ISE08.03.2024 11:15

ee468abe902206cdb44137a17292d68a

В 2019 мы закупили комплект оборудования и лицензий для развертывания Cisco SD‑Access на несколько тысяч портов для замены нашей старой инфраструктуры и одновременного внедрения многих технологических преимуществ, которые предоставляет SD‑Access.

SD-Access вкратце

Для тех, кто глубоко не погружался в детали того как устроен SD-Access, расскажу о его основных компонентах:

  • L3-underlay c динамической маршрутизацией ISIS внутри сети и BGP маршрутизацией наружу из оверлейных L3 сетей (VRF);

  • Поддержка L2 и L3 оверлейных сетей c multicast репликацией BUM;

  • Control‑plain и data‑plain построены на базе LISP;

  • Поддержка 802.1x и Identitybased микро-сегментирования на базе технологии TrustSec;

  • Управление сетью WiFi (но мы эту функцию не использовали, и далее я о ней писать не буду).

Совокупность всех этих свойств позволяет строить надежные, безопасные и относительно легкие в эксплуатации сети.

Так, например, всю офисную сеть можно построить на базе одной большой IP сети на несколько тысяч хостов. В процессе авторизации по 802.1x каждый доменный пользователь будет помещен в одну из групп сетевой безопасности на основе членства этих пользователей в группах AD. Таким группам пользователей назначаются политики доступа вовне, внутри этих групп и/или между группами. Причем при использовании правильных суппликантов конкретный ПК в конкретный момент времени может быть помещен, например, в группу «офисный ПК, на который сейчас никто не залогинен», и такой ПК, например, будет иметь возможность ходить только на сервер обновлений и не будет иметь возможности выхода в Internet. Когда же на этот ПК залогинится, например, бухгалтер (непосредственно или через RDP), ПК будет сразу же переключен в другую группу «бухгалтеры», которая, например, сможет подключаться к 1С и не сможет общаться со своими соседями по группе.

Те подключения, которые не поддерживают 802.1x, с помощью MAB и профилирования попадут в непривилегированные группы, такие как «телефоны» — которые смогут общаться только с телефонной станцией, «принтеры» — на которые можно будет только отправить что-нибудь на печать и т.д. Если же устройство никак не профилировалось, то его можно просто отправить в карантин.

Причем, как мы уже говорили, все эти группы, включая «карантин», могут иметь адреса из нашей единой IP сети, но при этом «карантин» за счет микро-сегментирования, действительно, ни с кем не сможет общаться, включая другие карантинные машины, но сможет взаимодействовать, например, с антивирусом.

Если в качестве супликанта использовать Cisco AnyConnect NAM, то группа будет меняться и при удаленном логине, например, через RDP. В условиях «удалёнки» это очень удобно.

Для развертывания, сопровождения и функционирования сети SD-Access, по мнению производителя, необходим кластер серверов DNAC и кластер серверов ISE, но об этом позже.

LISP вкратце

LISP, как технология построения оверлейных сетей, заслуживает отдельных слов. В отличие от самого распространенного конкурента VXLAN/BGP/EVPN, LISP изначально разрабатывался как технология, предназначенная для решения проблемы недостаточной масштабируемости и ограниченности объема адресного пространства IPv4. Кроме встроенного host mobility, основное ее преимущество заключается в том, что маршрутизаторы, участвующие в инфраструктуре LISP, не обязательно должны иметь полное представление о всех подключенных к сети оконечных устройствах. По мере необходимости, маршрутизаторы могут запросить маршрутную информацию о хостах у специальных сервисов MS/MR и кешировать ее, либо зарегистрировать на том же сервисе локально подключенные хосты. Примерно так же как работает DDNS. Это позволяет строить cети практически неограниченного масштаба из маршрутизаторов с достаточно скромными ресурсами.

TrustSec вкратце

Основная задумка TrustSec заключается в том, чтобы на входе в сеть промаркировать все пакеты некоторой целочисленной меткой SGT (Security Group Tag). Фактически метка назначается источнику пакетов и поэтому ее еще иногда называют (Source Group Tag). Таким образом мы можем значительно сократить и упростить политики безопасности нашей сети, так как теперь вместо большого множества всех IP адресов нашей сети мы можем строить политики на базе ограниченного разумного множества групп с динамическим членством.

Метка может назначаться источнику: на основе порта или VLAN, через который пакет вошел в нашу сеть, на основе IP адреса его источника, или самое интересное — на основе результатов авторизации пользователя по протоколу 802.1x

Метка SGT, как мы уже говорили, ставится на входе в сеть и передается вместе с пакетом внутри заголовка Ethernet или LISP. Для тех случаев, когда энкапсуляция не позволяет передавать метку внутри пакета, используется специальный протокол SXP, работающий поверх TCP. SXP по сути передает и поддерживает в актуальном состоянии таблицы соответствия IP-SGT на промежуточных устройствах, которым эти данные нужны, например, на FireWall.

Результат внедрения SD-Access

После длительного и кропотливо внедрения/миграции на SD-Access мы фактически получили «сеть свое мечты»)): L3-underlay! Значительно сократилось время и затраты на подключение новых пользователей. Повысилась «прозрачность» подключений. Теперь мы с большей уверенностью знаем, Кто, Где и Когда у нас подключен. Повысилась безопасность офисной сети. Теперь у нас меньше шансов получить горизонтальное распространение возможных зловредов и значительно сложнее получить привилегии другого пользователя, просто скопировав себе его MAC и воткнувшись в его порт в его отсутствие. Ну и еще масса других преимуществ…

Но счастье, как обычно, длится недолго).

Поддержка и лицензии закончились…

Что делать без поддержки и лицензий?

Давайте сначала перечислим, из каких компонентов изначально строится сеть SD-Access и какие лицензии для этого нужны.

  • Коммутаторы с Cisco Catalyst, которые поддерживают SD-Access. Необходимая функциональность LISP и TrustSec лицензируется там по принципу RTU и по умолчанию присуствует в CLI. Лицензия DNA устанавливается на коммутаторы, но фактически не влияет на их функциональность. Наличие этой лицензии проверяет сервер DNAС и при ее наличии берет устройство под свое управление, позволяя через себя управлять полным набором функций. Но если этой лицензии нет, то нам никто не запрещает настроить все те же функции руками через CLI. Лицензии DNA выпускаются на определенный срок или через Smart-Account Reservation можно сделать перманентную лицензию PLR.

  • Кластер из трех серверов DNAC. Основная задача этих серверов производить настройку коммутаторов (включая ZTP), собирать статистику и мониторить состояние сети. По сути, ничего фантастического он не делает, но без наличия кластера из этих серверов производитель не поддерживает функции SD-Access на коммутаторах. («Хмм, но у нас ведь теперь и так нет этой поддержки…») По правде сказать, когда поддержка этих серверов у нас была, они нам и тогда не очень нравились. Пару раз они у нас ломались, и инженеры Cisco их буквально неделями восстанавливали, и все это время мы не могли управлять сетью. Фактически не могли добавлять новые оверлейные сети.

  • Деплой (кластер) серверов ISE. ISE выполняет сразу несколько задач в рамках инфраструктуры SD-Access:

    1) AAA сервер в рамках реализации 802.1x;

    2) профилирование устройств, подключающихся к сети;

    3) Pasture — проверка хостов на соответствие политикам, например, на наличие антивируса и его обновлений;

    4) SXP hub, раздающий маппинг IP-SXP всем заинтересованным устройствам;

    5) Управление политиками TrustSec и их распространение.

    Так же как и от сервера DNAC мы не были в восторге от надежности серверов ISE, они периодически ломались, доставляя нам массу проблем.

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

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

Конечно, многим известно, что все необходимые лицензии давно уже сломаны, и PAK основанные flexlm, и PLR первой и второй версий. (Наверное, только PLRv3 еще не сломана, но она пока нигде и не используется.) Но в любом случае, сломанные лицензии это не наш путь. Эти лицензируемые продукты настолько не надежны, что связываться с ними даже с поддержкой не хочется, а без нее и подавно.

Итак, что нам нужно чтобы сохранить нашу сеть SD-Access, но при этом отказаться от сложных, лицензируемых и ненадежных продуктов DNAC и ISE,

  1. Первое, и самое важное, без чего не обойтись, это сами коммутаторы Cisco Catalyst, они сами по себе превосходны, и с ними мы ничего делать не будем. Все необходимые функции на них присутствуют, и при желании можно найти всю необходимую документацию, информацию о багах, обновления и ЗИП.

  2. Функция достаточно сложного конфигурирования LISP на устройствах (выполняет DNAC).

  3. Функция Аутентификации Авторизации и Экаунтинга для 802.1x, MAB и профилирования (выполняет ISE).

  4. Функция распространения информации о текущем отображении IP в SGT по протоколу SXP (выполняет ISE).

  5. Функция централизованного управления и распространения политик TrustSec (выполняет ISE и/или DNAC).

Замена функции конфигурирования

Тут все достаточно просто и прозаично. Мы реализовали централизованное создание эталонных конфигураций для коммутаторов на базе шаблонов jinja2 и ansible, плюс наша собственная разработка предварительного вычисления инкрементальных апдейтов из созданных эталонных конфигураций и их накатывание по расписанию. Это позволяет нам предварительно проверить инкременты перед накатыванием и применять обновления в удобное нам время. Однако, учитывая то, что накатывание конфигурации на коммутаторы является идемпотентной операцией, вычислением инкрементов можно пренебречь.

Замена функции AAA для 802.1x

Эта задача с успехом была переложена на freeradius. Все, что от него требуется, это аутентифицировать пользователя в домене по MSCHAP2. В случае успешной аутентификации сервер по LDAP заберет членство нового пользователя в группах AD и на основе этих данных подготовит правильный набор radius-атрибутов для нового подключения.

Freeradius обладает достаточно удобным и гибким языком unlang, который позволяет реализовать гибкую логику назначения radius-атрибутов наподобие той, что в ISE описывается в policy-set.

Вот в качестве примера кусочек конфигурации на unlang, который назначает VLAN, VRF (VN) и SGT для подключения по 802.1x

update reply { 
	Tunnel-Medium-Type := IEEE-802
	Tunnel-Type := VLAN
	Tunnel-Private-Group-ID := 1040 
	cisco-avpair += cts:vn=MAIN_VRF
}
if ( LDAP-Group == "grp_developers" ) {
	update reply {
		cisco-avpair += cts:security-group-tag=0101-00
	}
}
elsif ( LDAP-Group == "grp_hr" ) {
	update reply {
		cisco-avpair += cts:security-group-tag=0102-00
	}
}

Здесь сначала всем назначается VLAN:1040 в стандартном атрибуте Tunnel-Private-Group-ID и указывается имя VRF: MAIN_VRF в вендорском атрибуте cisco-avpair/cts: vn.

Далее уже на основе анализа членства пользователя в той или иной группе AD назначается метка SGT в атрибуте cisco-avpair/cts: security-group-tag.

Соотвественно, все, кто состоит в группе разработчиков, получат метку 101 и все соотвествующие этой группе сетевые права доступа;, а все кто, не разработчик и состоит в группе HR,- получат метку 102.

Суффикс »-00» в конце строки с меткой — это порядковый номер конфигурации данной метки, и его везде можно одинаково указывать как »-00».

Как вы видите, политики достаточно просты и наглядны.

Замена функции профилирования

Профилирование так же можно возложить на freeradius, но в качестве помощника ему понадобится коммутатор.

Функционал «Device Sensor», встроенный в IOS XE, достаточно хорошо профилирует подключенные устройства и в пакетах radius-accounting отправляет распознанный тип подключенного устройства на сервер freeradius.

Алгоритм подключения устройств, не поддерживающих 802.1x, может быть таков:

  1. При подключении нового устройства, не поддерживающего 802.1x, коммутатор создает у себя аутентификационную сессию, назначает ей уникальный номер и отправляет первый radius запрос с типом access-request. В этот запрос помещается вся информация, которая известна коммутатору на текущий момент: уникальный номер сессии, название коммутатора и номер его порта, в поле имени пользователя указывается MAC адрес устройства. Если IP адрес на тот момент уже известен, то и он помещается в запрос;

  2. Получив такой запрос, freeradius может сформировать позитивный ответ access-accept, но поместить в атрибуты карантинную метку. Если на основе MAC адреса или номера порта коммутатора мы сразу можем выдать целевую метку, например, метку «принтер», то это можно сделать уже на этом шаге, но в большинстве случаев на этом этапе данных нам еще не достаточно, и «карантинная» метка будет хорошим решением;

  3. Коммутатор, получив ответ от сервера, поместит новое устройство в карантин и позволит ему контролируемо начать «общаться» с сетью. На этом этапе начинает работать device sensor и распознавать тип устройства на основе его OUI, данных из DHCP, LLDP и CDP;

  4. Когда функция device sensor определит тип подключенного устройства, коммутатор пошлет новые данные серверу freeradius в пекете accounting-request;

  5. На базе новых данных об устройстве freeradius может назначить целевую метку и отправить коммутатору COA запрос на изменение атрибутов уже существующего подключения;

  6. Коммутатор, получив COA, переместит устройство из карантина в целевую группу.

Вот пример обработки accounting-request и отправки COA: 

if ( &Acct-Status-Type == "Stop" ) {
    return
}

update request {
     &Tmp-String-0 := "NONE"
     &Tmp-String-1 := "NONE"
}

foreach Cisco-AVPair {
    if ( "%{Foreach-Variable-0}" =~ /^cts:security-group-tag=([0-9a-f]{4})/i ) {
        update request {
             &Tmp-String-0 := "%{1}"
        }
    }
    if ( "%{Foreach-Variable-0}" =~ /^dc-profile-name=(.+)$/ ) {
        update request {
            &Tmp-String-1 := "%{1}"
        }
    }
}

if ( "%{Tmp-String-1}" =~ /ip-phone/i && &Tmp-String-0 != "0076" ) {
    #	  
    #	IP Phone
    #
    update coa {
                Calling-Station-ID = "%{Calling-Station-ID}"
                NAS-IP-Address = "%{NAS-IP-Address}"
                Packet-Dst-IP-Address =	"%{NAS-IP-Address}"
                Packet-Dst-Port = 1300
                cisco-avpair += cts:vn=VOICE_VRF
                cisco-avpair += cts:security-group-tag=0076-00
        }
}

Сначала мы проверяем статус полученного accounting-request. Если он равен «Stop», то это значит, что сессия завершена, устройство отключилось от сети, и мы просто прекращаем дальнейший анализ этого запроса.

Далее мы инициализируем две временные переменные Tmp-String-0 и Tmp-String-1 (это предопределенные имена, которые уже описаны во freeradius, если вы хотите создать переменные с иными именами, то сначала посмотрите как описаны эти).

В эти временные переменные мы помещаем название профиля из атрибута dc-profile-name, в котором должен находится результат работы device sensor, и текущую метку данной сессии из атрибута cts: security-group-tag.

Далее проверяем, если распознанный коммутатором профиль имеет значение «ip-phone» и текущая метка не соответствует этому профилю, например, там карантинная метка, то мы посылаем COA с новыми атрибутами для данного подключения.

Замена функции SXP хаба

В вендорском варианте эту функцию выполняет ISE. Он «знает», кому какую метку он выдал. Все статические мапинги определяются тоже на нем. Соотвественно, он выступает в роли золотого источника этой информации. Все firewall могут подключаться к нему и забирать нужную информацию. Freeradius, к сожалению, так не умеет, и тут нам придется прибегнуть к недокументированной хитрости.

В протоколе SXP у устройства есть две роли: listener и speaker,- которые могут как сосуществовать вместе на одном устройстве, так и жить отдельно. В вендорском варианте коммутаторы доступа вообще не участвуют в SXP обмене, но если на коммутаторе доступа настроить SXP speaker, то он будет отдавать соответствие IP-SGT для тех устройств, которые подключены к нему непосредственно.

Проблема заключается в том, что таблица и сессии SXP привязаны к тому VRF, в котором живут соотвествующие устройства. Т.е. если у нас все подключения оконечных устройств живут в MAIN_VRF, то и сессии SXP должны быть построены в рамках данного VRF, но SD-Access устроен так, что на uplink-ах у нас живет только default VRF, и сессию построить не получается.

На помощь нам приходит NHRP, который позволяет построить тоннели из нужных нам VRF внутри default vrf и внутри этих тоннелей поднять SXP сессии от всех коммутаторов доступа, например, до двух агрегирующих коммутаторов, которые у нас теперь возьмут на себя еще и роль SXP listener&speaker, т.е. по сути станут SXP хабами.

Единственное неудобство заключается в том, что если у нас несколько VRF, то NHRP тоннели и SXP сессии придется настроить для каждого VRF отдельно.

Замена функции централизованного управления политиками TrustSec

В вендорском варианте эту функцию выполняет тоже ISE. Политики можно изменять через GUI DNAC, но хранятся они все равно на ISE и с него же распространяются, обычно в атрибутах radius, но могут и через rest запросы. Подробнее можно почитать здесь

Политики trustsec состоят из трех взаимосвязанных частей.

  1. Environment data. Здесь хранится список используемых в нашей сети SGT меток с их мнемоническими именами и параметры всех policy серверов, которые могут раздавать политики в нашей сети.

  2. Список листов доступа, которые в данном случае называются SGACL.

  3. Матрица доступов. Квадратная таблица, в строках и колонках которой располагаются Source SGT и Destination SGT, а в ячейках — список соответствующих SGACLs.

REST запросы достаточно примитивны. 

curl --user-agent "cisco-IOS" -u "User:Password" -k\
     -H "Content-Type: application/json" \
     -H "Connection: Keep-Alive" \
     -H 'Accept:' \
     -d '{"CTSEnvData":{"deviceName":"Switch","sgTablesFilter":[],"capability":["ENV_DATA_BASIC","SG_TABLES","SGTAGS","SERVERS"]}}' \
     -X POST https://1.1.1.1:9063/ers/config/ctsapi/ctsenvdata | json_xs

curl --user-agent "cisco-IOS" -u "User:Password" -k\
     -H "Content-Type: application/json" \
     -H "Connection: Keep-Alive" \
     -H 'Accept:' \
     -d '{"CtsMatrix":{"dstSgtArr":["ffff"],"srcSgtArr":[],"offset":"0","limit":"500"}}' \
     -X POST https://1.1.1.1:9063/ers/config/ctsapi/ctsmatrix | json_xs

curl --user-agent "cisco-IOS" -u "User:Password" -k\
     -H "Content-Type: application/json" \
     -H "Connection: Keep-Alive" \
     -H 'Accept:' \
     -d '{"SGACLs":{"names":[]}}' \
     -X POST https://1.1.1.1:9063/ers/config/ctsapi/sgacls | json_xs

Мы можем использовать существующий ISE сервер для исследования формата запросов, чтобы потом повторить этот функционал на собственном простеньком сервере.

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

© Habrahabr.ru