Привет, Хабр. Десять лет назад я был обычным сетевым инженером, которому надоело править tac_plus.conf руками, и я написал вокруг него веб-морду — TACACSGUI. Она неожиданно разошлась: тысячи инсталляций, форум, письма из мест, о которых я и не думал. Документации там практически не было — интерфейс был устроен так, что люди разбирались сами. Это был главный урок, который я оттуда вынес.
Второй урок был в почте. Самая частая просьба за все годы, с огромным отрывом: «добавьте RADIUS». Прикрутить RADIUS сбоку к обёртке над TACACS-демоном невозможно так, чтобы это не было уродством: получились бы две несвязанные правды, два места настройки. И я решил не прикручивать, а переделать.
Так появился Taranac — TACACS+, RADIUS, NAC. Полтора года проектирования и разработки (не считая времени, которое я просто носил архитектуру в голове). Сегодня это работающая платформа: TACACS+, RADIUS, 802.1X, MFA со своим push-сервисом и мобильным приложением, PKI, captive portal, кластеризация. Free, self-hosted, без лимитов на устройства и пользователей.
Я пришёл сюда не продавать (продавать нечего — оно бесплатное), а за обратной связью. Ниже — что я строил, какие решения принимал и почему. И отдельным разделом — честно про то, чего в проекте нет и что в нём можно не любить.
Сразу неудобное: это не open source
Чтобы не собирать это в комментариях по кускам — проговорю в первом же разделе.
Taranac бесплатный, но исходники закрыты. Распространяется артефактами: Docker-образы плюс тонкий инсталляционный репозиторий, лицензия — Elastic License 2.0. Есть готовый виртуальный апплаенс (OVA / QCOW2), который загружается и работает.
Community-ядро — полное: AAA, NAC, политики, устройства, пользователи, логирование, портал, PKI. Никаких лимитов на количество устройств, пользователей, правил и никакой телеметрии. Единственное, что сегодня закрыто лицензией, — High Availability (кластер или в простонародье - высокая доступность); лицензия проверяется офлайновой Ed25519-подписью, без привязки к железу, и просроченная лицензия не может выключить аутентификацию — только погасить Pro-фичу.
Монетизация — платная поддержка. Всё. Это осознанный выбор человека, который уже однажды раздал проект бесплатно и потом десять лет отвечал на письма в свободное время.
Если ваш критерий — «нет исходников, значит не интересно», дальше можно не читать, и это нормально. Дальше — про инженерные решения.
И сразу про картинки: скриншотов здесь не будет
Обычно статья про продукт — это галерея скриншотов, по которым всё равно ничего не понять. Я так делать не буду по простой причине: система доступна публично. Живое демо, полный интерфейс, ничего не выключено — demo.taranac.pro. Не надо смотреть мои скриншоты, идите и щёлкайте сами.
Вместо скриншотов я нарисовал схемы механики — того, что на скриншоте как раз не видно: как ходит запрос, куда смотрят стрелки, что остаётся, когда ломается верхний уровень. Они анимированные, потому что почти всё интересное здесь — это последовательность, а не картинка.
Часть 1. UX как проектное требование, а не как «потом причешем»
Начну не с протоколов, а с того, что для меня оказалось важнее протоколов.
Я работал с разными системами — вендорскими, опенсорсными, самописными — и везде отмечал, что удобно, а что бесит. Бесило в основном одно и то же.
Режим одного окна
Знакомая картина: вы открываете форму создания политики, заполняете половину полей и понимаете, что забыли завести группу. Или устройство. Или профиль. Дальше — классика: уйти в другой раздел, потерять заполненное, вернуться, заполнить заново.
В Taranac этого нет как принципа. Если в форме нужен объект, которого ещё не существует, — вы создаёте его прямо из этой формы, не выходя из неё и не теряя введённое. Пишете правило политики, а нужной группы устройств нет — заводите её из селектора выбора группы. Нужно устройство — создаёте из поля выбора устройств.
Звучит как мелочь. На практике это разница между «настроил за 5 минут» и «бросил на третьей форме».
Подсказки под каждым параметром
TACACS+ и RADIUS — протоколы, скажем мягко, не самые дружелюбные. Атрибуты, которые надо помнить наизусть; поведение, которое отличается от вендора к вендору; параметры, смысл которых понятен только тому, кто уже наступал.
Поэтому практически под каждым параметром стоит пояснение: что это, на что влияет, что будет, если оставить по умолчанию. Не ссылка «см. документацию», а текст на месте.
Шаблоны вместо «изучите матчасть и вперёд»
Плюс библиотека готовых шаблонов профилей — их можно использовать как есть или брать за основу. Это одновременно и ускорение, и обучающий материал: видно, как выглядит правильно сделанный профиль под конкретного вендора.
Я к этому отношусь так: если администратору нужна документация, чтобы завести пользователя, — виноват не администратор.
Часть 2. Архитектура: политики как ACL на файрволе
Теперь главное архитектурное решение, из которого вырос весь продукт.
Как матёрый сетевик я исходил из простого: инженеру не нужно изобретать новую ментальную модель. Он уже двадцать лет читает списки правил сверху вниз и знает, что срабатывает первое совпавшее. Значит, политика доступа должна выглядеть как правила на файрволе.
Одна упорядоченная таблица. Каждое правило отвечает на четыре вопроса:
Измерение | Вопрос | Что выбирается |
|---|---|---|
WHO | Кто аутентифицируется? | Any / пользователи и группы |
WHERE | Через какое сетевое устройство пришёл запрос? | Any / устройства и группы устройств |
SOURCE | Откуда пришла сессия? | Any / сети-источники / console |
WHEN | Когда? | Always / именованный временной диапазон |
Правило срабатывает, только если совпали все четыре измерения. Первое совпавшее решает исход: разрешить, запретить, какой профиль применить (уровень привилегий, command set, RADIUS-атрибуты) и нужен ли второй фактор.
Внизу списка приколот неудаляемый default-правило — «запретить всё». То есть доступ — это ровно то, что вы явно разрешили, и состояния «система не приняла решение» не существует.
Одна таблица на два протокола
Тонкость, которой я доволен: у правила две независимые колонки действий — одна для TACACS+, одна для RADIUS. Режимы: none, deny, auth_only, profile.
Режим none означает «это правило не про данный протокол — иди дальше». Именно он позволяет одному списку честно обслуживать оба протокола: правило может применять TACACS-профиль с command set и при этом полностью пропускать RADIUS-запросы вниз по таблице.
Пара примеров, как это выглядит в жизни:
1. NOC read-only в рабочие часы WHO=group:noc WHERE=Any SOURCE=Any WHEN=business-hours TACACS+ = profile(read-only) RADIUS = none 2. Полный админ только с jump-хоста WHO=group:net-admins WHERE=Any SOURCE=net:jump-hosts WHEN=Always TACACS+ = profile(priv-15) RADIUS = none MFA = required 3. Break-glass: консоль работает всегда WHO=Any WHERE=group:core SOURCE=console WHEN=Always TACACS+ = auth_only RADIUS = none ──────────────────────────────── default (закреплено): TACACS+ = deny "Access denied by default policy"
Честная деталь про RADIUS и SOURCE
RADIUS при администрировании устройств не передаёт source IP клиента, а «консоль» — понятие вообще TACACS-специфичное. Значит, RADIUS-запрос физически не может удовлетворить правило с ограничением по SOURCE — движок такое правило пропустит и пойдёт дальше.
Это ровно тот класс граблей, на которые наступают все и потом полдня читают логи. Поэтому тестер политик выдаёт явное предупреждение, когда единственное, что мешает RADIUS-правилу сработать, — это ограничение по SOURCE.
Тестер политик
Отдельная кнопка, которую я считаю обязательной для любой системы с правилами: подставляете протокол, пользователя, NAS IP, source IP, тип доступа и время — и получаете, какое правило выиграет и почему, с построчной трассировкой pass/fail по всем правилам. По живым правилам, без трогания продакшн-трафика.
Потому что «я поменял порядок правил и, кажется, ничего не сломал» — это не инженерия.
Подробнее про политику, режимы действий и тестер — в документации.
Часть 3. MFA, и почему я стал писать собственный push
Здесь я закопался глубже всего, и вот почему.
OTP-токены удобны не всегда. Хуже того — иногда их некуда вводить. У TACACS+ нет нативной поддержки второго фактора. При подключении по 802.1X у пользователя вообще нет интерфейса, куда что-то печатать. Классический ответ «ну добавьте OTP к паролю» работает, но это костыль, и пользователи его ненавидят.
Мне очень нравится концепция push, которую я видел у Multifactor: это не просто удобнее — это закрывает случай, когда вводить код физически некуда.
Поэтому в системе пять MFA-провайдеров:
Email push — approve/deny ссылка через ваш же SMTP. Неожиданно для меня самого оказался очень удобным вариантом: ничего не надо ставить и ни с чем интегрироваться;
Telegram-бот — крайне актуально в РФ (сарказм);
Multifactor — довольно распространённая система;
TOTP — классика и самый устойчивый вариант: считается и проверяется локально, живёт даже когда наружу вообще ничего не ходит;
Taranac MFA — то, чем я горжусь.
И сразу деталь, которая хорошо иллюстрирует тезис «вводить некуда»: в 802.1X работает только push. PEAP/MSCHAPv2 и EAP-TTLS физически не могут спросить одноразовый код после того, как EAP-туннель закрылся, — поэтому OTP-провайдеры в этом контексте просто отклоняются. Либо push, либо никакого второго фактора.
Taranac MFA: свой Multifactor, только у вас в DMZ
Это две половины: сервис, который вы запускаете сами (свой контейнер, своя база, свой ключ шифрования) и мобильное приложение, которое ставят пользователи. Между ними нет третьей стороны: ни аккаунта издателя, ни облачного тенанта, ни общего секрета, который можно утечь.
Что мне кажется в нём правильным:
1. Все стрелки смотрят наружу. Сервис специально сделан так, чтобы жить в DMZ. Он открывает один входящий порт — 8443 HTTPS — и не инициирует ни одного соединения внутрь вашей сети. Ядро Taranac всегда клиент; телефон приходит на сервис из интернета. Дырка внутрь периметра не нужна ни для чего.
2. Он переживает потерю Google. Push приходит через Firebase, когда Firebase доступен; через собственный polling приложения, когда нет; а если сети нет совсем — та же самая регистрация выдаёт офлайновый шестизначный код. Телефон без Google-сервисов здесь полноценный гражданин, а не «деградированный режим».
3. Подпись в обе стороны. Challenge подписывает сервер, ответ подписывает телефон ключом, который сгенерирован на устройстве и никогда его не покидает. Ни у одной стороны нет секрета, который могла бы потерять другая.
4. Своя база и свой ключ. У сервиса отдельный ключ шифрования, намеренно не MASTER_KEY платформы: компрометация одного не раскрывает другое. И знает он пользователей по UUID — имя пользователя доезжает до него только как косметическая подпись на QR-коде при регистрации.
Как это выглядит для живого человека
Инженер: ssh admin@core-sw-01 Коммутатор: Username: ivanov Password: ******** ... (ждём) Телефон: 🔔 Taranac — Вход на core-sw-01 Пользователь: ivanov [ Одобрить ] [ Отклонить ] Коммутатор: core-sw-01#
Кнопка «Отклонить» — не для красоты. Это ровно тот момент, когда пользователь узнаёт, что кто-то ходит с его паролем.
Целиком путь одного входа выглядит так:
А если MFA-сервер недоступен и push не придёт — пользователь открывает то же приложение, берёт офлайновый код и входит как пароль+OTP. Тот же самый enrollment, никакой отдельной настройки. Целиком лестница деградации выглядит так:
Как это устроено целиком, включая формат подписи и модель доверия, — на странице Taranac MFA. Там же лежит APK: приложение можно скачать и попробовать прямо сейчас, не дожидаясь, пока я разберусь с маркетами.
Часть 4. NAC: тут амбиции по ISE
802.1X — та часть, где я сознательно замахнулся на территорию Cisco ISE. Путь одного эндпоинта выглядит так:
В базу уже заложено следующее.
Классификаторы конечных устройств. Вместо того чтобы перечислять MAC-адреса в правилах, вы описываете группы, а устройства попадают в них автоматически. Совпадение по точному MAC, по OUI-префиксу (весь адресный блок вендора), по шаблону MAC, по имени вендора, по издателю сертификата. Матчинг — all-matches: устройство может состоять сразу в нескольких группах, а всё, что не совпало ни с чем, падает в «Unclassified». Классификация переигрывается на каждой аутентификации.
Несколько корней доверия. Это то, что в жизни ломает половину внедрений:
доменный УЦ — компьютеры уже имеют сертификаты, ничего перевыпускать не надо;
сторонние УЦ — приходит партнёр и говорит «наши ноутбуки уже настроены на dot1x с нашим сертификатом»;
локальный PKI — со своими корневыми, промежуточными УЦ и нормальной выдачей.
Выдача сертификатов по-человечески. Одноразовые ссылки: единоразовый URL с ограниченным сроком (по умолчанию 72 часа), который отдаёт P12/PEM и показывает пароль — вместо пересылки ключевого материала почтой руками. Плюс EST (RFC 7030) для автоматической выдачи и перевыпуска через MDM — я выбрал его вместо старого SCEP: он поверх HTTPS с нормальной аутентификацией, с чистым flow перевыпуска (simplereenroll) и поддерживается современными iOS, Windows, Android и ChromeOS.
И весь остальной набор: PEAP / EAP-TLS / EAP-TTLS, MAB для принтеров и IoT, динамическое назначение VLAN и ACL, CoA (переаутентификация, bounce порта, смена VLAN, отключение сессии на лету), captive portal с гостевым доступом, BYOD, саморегистрацией и AUP.
Отдельно замечу про архитектуру: NAC-RADIUS живёт в своём контейнере на своих портах (1814/1815), отдельно от RADIUS для администрирования устройств (1812/1813). Аутентификация сотен эндпоинтов на портах и вход админа на маршрутизатор не должны конкурировать за один демон.
Подробнее: обзор NAC, PKI и доверие, captive portal. Есть и пошаговые сценарии — например, 802.1X с PEAP и EAP-TLS с доменным УЦ.
Часть 5. Configuration Tracker и JIT-аккаунты
Это бонусный модуль, который вырос из простого наблюдения.
Система и так знает учётные записи и контролирует доступ к сетевому оборудованию. Значит, она может ходить на устройства сама — под учёткой, пароль которой не знает никто. Так появились JIT-аккаунты (Just In Time): учётка создаётся и ротируется перед началом работы и после её окончания. Секрет не показывается нигде — ни в интерфейсе, ни в логах, ни через API.
Сам Configuration Tracker — обычная NCM-система сбора конфигураций, но с двумя идеями, которые мне нравятся:
1. Свой сборщик как первоклассный вариант. Если у вас что-то сложное и нестандартное — экзотическая железка, хитрая процедура выгрузки, — вы пишете собственный скрипт, который по GET (или POST) отдаёт системе конфигурацию. Не «мы не поддерживаем ваш вендор», а «вот интерфейс, подключайтесь».
2. Диффы, связанные с людьми. К отслеживаемой конфигурации привязывается адрес контролируемого устройства — и вы видите кто заходил и что делал в промежутке между двумя изменениями конфигурации. Это ровно тот вопрос, который задают на разборе инцидента: «конфиг поменялся между вторником и средой — кто там был?». Обычно на него отвечают, сводя вручную NCM и TACACS-логи. Здесь они уже сведены.
Подробнее: Configuration Tracker и учётные данные, включая JIT.
Часть 6. Что ещё есть, коротким списком
Чтобы не раздувать статью, остальное просто перечислю:
Каталоги: MS Active Directory, OpenLDAP, FreeIPA; мультидоменность.
Логирование: authentication / authorization / accounting, NAC-сессии, activity log.
Syslog в разных форматах, внутренний мониторинг и алертинг.
Отчёты с планировщиком рассылки.
RBAC для администраторов самой системы.
Коллекторы - разгружают ядро от рутинной работы (на них у меня большие планы).
Кластеризация / HA (единственная сегодня Pro-фича).
Виртуальный апплаенс — OVA и QCOW2, грузится и работает.
Всё это описано в документации: каталоги и LDAP/AD, RBAC, отчёты, высокая доступность, архитектура целиком. Куда всё это едет дальше — роадмап.
Часть 7. Честно: чего нет и к чему можно придраться
Раздел, ради которого, подозреваю, половина читателей сюда и пролистала. Пишу сам, пока не написали в комментариях.
Исходники закрыты. Уже сказал выше, повторю здесь, потому что это главная претензия. Бесплатно ≠ open source. Если вам нужен аудируемый код — это не ко мне, это к FreeRADIUS напрямую (к слову - пока я разрабатывал этот проект я понял, что FreeRADIUS я бы тоже перекроил, уж много там ограничений и костылей, которые не обойти).
Мобильного приложения нет в сторах. И это моя главная текущая боль. Публикация в маркетах — это бюрократия, которая требует денег и времени, а я делаю проект один. Приложение существует и работает, но путь его установки сейчас не такой, каким должен быть. Я честно сказал бы, что это самое слабое место всей MFA-истории с точки зрения доверия пользователя.
Проект молодой — но это не бета. Я пришёл сюда не с «посмотрите, что я собираю по вечерам». Taranac уже вышел релизами, по нему идёт обратная связь со всего мира, и через него прошли первые пользователи — те, кто решился мигрировать с TACACSGUI на новую систему. Их правки и их грабли уже внутри: часть того, что описано выше, выглядит именно так, потому что кто-то наступил и написал мне.
Чего я при этом не буду делать — рассказывать про многолетний боевой опыт, которого у нового продукта быть не может. TACACSGUI отработал в проде годы, Taranac столько не прожил. 802.1X на пять тысяч портов на нём ещё никто не крутил (хотя нагрузочные тесты проект проходит успешно), и я первый, кому интересно узнать, где он треснет.
Я один. Со всеми вытекающими: bus factor, скорость реакции, объём того, что можно успеть. Часть амбиций пока живёт в роадмапе, а не в релизе.
Это не Cisco ISE. Сравнение по духу и по классу задач — да. По зрелости, интеграциям и покрытию экзотики — очевидно нет, и было бы нечестно говорить иначе.
Как потрогать
Всё, о чём я написал, можно проверить руками — специально сделал так, чтобы это не требовало ни регистрации, ни заполнения формы обратной связи.
Живое публичное демо — demo.taranac.pro. Это не скриншоты и не видео, а работающая система.
Потрогать MFA за пять минут — на сайте есть анонимный мастер: выбираете второй фактор, регистрируете его по-настоящему против живого ядра Taranac и получаете рабочий вход по SSH на демонстрационный Cisco. Без регистрации, всё самоуничтожается через пять минут.
Мобильное приложение Taranac MFA — страница с APK и описанием. Скачивается и ставится сейчас, без ожидания маркетов.
Скачать платформу — taranac.pro/download: готовый апплаенс, OVA для VMware/VirtualBox и QCOW2 для Proxmox/KVM. Текущая версия — 1.2.3.
Документация — taranac.pro/docs. Учитывая прошлый опыт, в этот раз она написана заранее и по-настоящему. Начать проще всего с быстрого старта.
Что я хочу от вас
Я пришёл за критикой, поэтому сформулирую конкретно — на что мне правда важно услышать мнение:
Политика в виде файрвольных правил (WHO / WHERE / SOURCE / WHEN, первое совпавшее) — это действительно та модель, в которой вам удобно думать про AAA? Или на реальном масштабе она разваливается, и нужны, скажем, вложенные наборы правил?
Push-подтверждение для входа на сетевые железки — вы бы включили это у себя? Или в проде это лишний шаг, который заблокирует вас в три часа ночи при аварии?
Свой MFA-сервис в DMZ против облачного провайдера — что перевешивает: контроль или нежелание держать ещё один сервис?
Чего не хватает для пилота у вас? Не «вообще», а конкретно: какой пункт вы бы назвали блокирующим.
И если кто-то дочитал и попробовал — расскажите, где сломалось. Отрицательный опыт для меня сейчас ценнее положительного.
Это не последняя статья
Проект я люблю и горю им — и буду развивать дальше независимо от того, как зайдёт этот текст. Просто одному видно не всё, а со стороны обычно виднее, что стоило бы объяснить.
Здесь я прошёлся по верхам: почти в каждом разделе есть что копать вглубь, но статья и так вышла длинной. Поэтому — скажите, про что писать дальше. Например:
Использую ли я ИИ и как именно. Спойлер: использую, и опыт получился сильно неоднозначный — есть история про то, как я на три дня отдал разработку модуля отчётов команде агентов и в итоге выбросил результат целиком.
Внутренняя архитектура. Как устроено ядро политик, почему TACACS+, RADIUS и 802.1X — это три отдельных движка вокруг одного хранилища, как конфигурация доезжает до демонов и что происходит при деплое изменений. Или самое простое - как я организовал структуру файлов в проекте (это целая история переписывания проекта).
UX-решения по отдельности. Режим одного окна на уровне реализации, инлайновое создание объектов из любой формы, тестер политик, шаблоны, подсказки — что из этого чего стоило и что я бы сделал иначе.
PKI и 802.1X-практика. Несколько корней доверия, EST вместо SCEP, выдача сертификатов пользователям без ручного обращения с ключевым материалом.
Как один человек тащит продукт такого объёма. Планирование, приоритеты, что пришлось выкинуть, где я ошибся в оценке сроков в разы.
Напишите в комментариях, что было бы интересно — с этого и начну.
Спасибо, что дочитали.
