Каждый системный / сетевой администратор рано или поздно сталкивается с ситуацией: кто-то поправил конфиг, но не очень известно кто и когда. Дифференциальных бэкапов не было, сислог не снимался.
Как узнать что было изменено?
Долго искал подходящее решение. Нашел.
Цели
Найти бесплатное либо OpenSource решение для резервирования конфигураций сетевого оборудования.
Внедрить и использовать.
Технические подробности
Мы используем достаточно большой стэк оборудования от Eltex. Также есть и остатки Cisco, Nortel, Avaya, какое-то количество Mikrotik.
Назрела потребность реализовать управление конфигурациями этого зоопарка. Причем, регионально (по всей РФ), импортозамещенно и, конечно, бесплатно.
Спросил у google gemini
вопрос - Системы оркестрации, совместимые с оборудованием Eltex
ответ Gemini - Отличный вопрос! Выбор системы оркестрации для оборудования Eltex напрямую зависит от масштаба вашей сети, специфических требований и целей автоматизации.
Встроенные инструменты Eltex
Прежде всего, стоит обратить внимание на встроенные инструменты управления самим оборудованием Eltex. Многие модели поддерживают:
SNMP: Стандартный протокол для мониторинга и управления сетевыми устройствами.
CLI: Командная строка для выполнения различных конфигурационных действий.
Web-интерфейс: Графический интерфейс для управления устройством через веб-браузер.
Эти инструменты позволяют осуществлять базовую оркестрацию и автоматизацию, особенно в небольших сетях или для выполнения рутинных задач.
Некоторые популярные системы оркестрации, совместимые с оборудованием Eltex:
Ansible: Сильно автоматизированная система управления конфигурацией, которая использует простой язык для описания желаемого состояния инфраструктуры.
Puppet: Система конфигурации с открытым исходным кодом, которая использует декларативный язык для управления инфраструктурой.
Chef: Еще одна популярная система конфигурации с открытым исходным кодом, которая использует инфраструктуру как код.
SaltStack: Система управления конфигурацией, которая использует мастер-агентскую архитектуру для управления удаленными системами.
CloudForms: Комплексная платформа для управления облачной инфраструктурой, которая включает в себя функции оркестрации.
Посмотрел предложенные варианты
Ansible - мимо., успешных вариантов внедрения для коммутаторов Eltex - или нет, или я не нашел.
Eltex ECCM - всем хороша, но не бесплатна, плюс нельзя подключить оборудование других вендоров (вероятнее всего).
Oxidized - совместима, бесплатна (https://github.com/ytti/oxidized), пробуем.
О решении
Oxidized - это универсальное решение, поддерживающее более 130 видов устройств от различных вендоров, поэтому достаточно установить и настроить его один раз и использовать затем без оглядки на применяемое оборудование. Это значительно удобнее, чем решения, предназначенные для оборудования какого-либо отдельного производителя.
ПОЕХАЛИ НАСТРАИВАТЬСЯ
Для настройки мы будем использовать Ubuntu 22.04 LTS, коммутатор Eltex 2308B.
Oxidized написан на Ruby и поэтому его установка отличается от привычной пользователям Debian. Начнем с установки необходимых зависимостей:
apt install ruby ruby-dev libsqlite3-dev libssl-dev pkg-config cmake libssh2-1-dev libicu-dev zlib1g-dev g++ libyaml-dev
Устанавливаем Oxidized через RubyGems
gem install oxidized
gem install oxidized-script oxidized-web
gem install psych
Далее устанавливаем Git для хранения конфигураций и контроля изменений в них:
apt install git
Создаем пользователя для oxidized
useradd -s /bin/bash -m oxidized
Делаем тестовый вход
su oxidized
oxidized
exit
Прежде всего зададим имя и пароль по умолчанию с которыми oxidized будет соединяться с сетевыми устройствами. Рекомендую использовать для этого отдельного пользователя с нестандартным именем, которого потом следует завести на всех сетевых устройствах.
В нашем случае
0xidiZed // P@$$w0rD
Не забываем добавить привилегий пользователю на коммутаторе, в противном случае - работать не будет.
username 0xidiZed password P@$$w0rD privilege 15
Правим файл конфигурации Oxidized по адресу
~oxidized/.config/oxidized/config
исправляем username | password
изменяем model:eltex
меняем интервалы запроса (interval:86400) для сохранения конфигурации раз в сутки
input - изменяем с telnet на ssh, как более безопасный
output отвечает за хранение собранной с устройств информации о конфигурации, мы будем использовать Git, поэтому конфигурация будет выглядеть следующим образом:
output:
default: git
git:
user: oxidized
email: oxidized@localhost.localdomain
repo: "/home/oxidized/.config/oxidized/devices.git"
Сами ip адреса коммутаторов задаем файле базы данных роутеров (проще говоря файл csv с разделителем : ) расположенный по пути
"/home/oxidized/.config/oxidized/router.db"
создаем необходимый файл
mcedit ~oxidized/.config/oxidized/router.db
В этом файле добавляем наш коммутатор
TstRouter:192.168.72.1
Если необходимо задать параметры авторизации отличающиеся от глобальных, задаем их
TstRouter:192.168.72.1:User:Password
Далее, нам нужно создать юнит Systemd для работы в качестве службы, для этого копируем готовый шаблон:
cp /var/lib/gems/3.0.0/gems/oxidized-0.30.1/extra/oxidized.service /etc/systemd/system
Внимательно смотрим на номер версии, в нашем случае oxidized-0.30.1
Перечитаем содержимое systemd:
systemctl daemon-reload
Создадим директорию в /run:
mkdir /run/oxidized
И сделаем пользователя oxidized ее владельцем:
chown oxidized:oxidized /run/oxidized
Добавляем службу в автозагрузку:
systemctl enable oxidized
И запускаем ее:
systemctl start oxidized
Проверяем работу службы
systemctl status oxidized
Также проверяем, что служба работает на правильном порту
ss -tpln
Настраиваем git:
git config --global user.name "oxidized"
git config --global user.email "oxidized@localhost.localdomain"
git init oxidized.git
Устанавливаем и настраиваем NGINX (oxidized не имеет своего веб сервера).
apt install nginx
перезаписываем конфигурацию по умолчанию
cat /var/lib/gems/3.0.0/gems/oxidized-0.30.1/extra/oxidized.nginx > /etc/nginx/sites-available/default
перезапускаем nginx
nginx -s reload
Заходим на страницу oxidized
Если все настроили правильно - видим аналогичную картинку.
Проверяем работу (сохраняем конфигурацию роутера, изменяем конфигурацию, сохраняем конфигурацию повторно)
Для начала - все.
После необходимо будет добавить оборудование других вендоров, настроить шифрование, TLS, поделить оборудование на группы, и т.д. и т.п.
Продолжение следует.
NAI
Я же правильно понимаю, вы так и не узнаете кто и почему исправил конфиг?
Мы пошли другим путем - инженер правит yml -> git commit\push --(дальше CI\CD) --> jinja2 генерит конфиг в формате коммутатора и заливает на фтп -> ansible через "copy ftp://config.server/sw1234567.cfg runnning-config" применяет настройки на коммуте -> ждет какое-то время\прогоняет тесты -> заливает конфиг в стартап.
Попутно всякие тесты выполняются чтобы не выстрелить себе в ногу.
Сейчас пилим автоматическое выгрузку и сравнение с эталоном (как раз от любителей исправить руками)
Eugene_Kaig Автор
Да, этого не узнаем. Но если включать логирование команд и парсить сислог - узнаем. Отличное у вас решение, мы до такого пока не дошли)
Lenar_S
А вы не смотрели в сторону TACACS+ для логирования кто и какие команды вводит?
Eugene_Kaig Автор
Смотрели, уже прорабатываю.
NAI
TACACS+ не везде есть, второе - при коммите в гит пишется коммент который мало-мальски объясняет зачем эти изменения нужны (иногда, просто ID задачи). Плюс на критичное оборудование оформляется MR который проверяет коллега.
С syslog\TACACS ну увидим мы что джун ошибся октетом и вместо 10.145.233.31 ввел 10.145.233.13, дальше то все равно идти и чинить