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

Как узнать что было изменено?

Долго искал подходящее решение. Нашел. 

Цели

  1. Найти бесплатное либо OpenSource решение для резервирования конфигураций сетевого оборудования. 

  2. Внедрить и использовать.

Технические подробности

Мы используем достаточно большой стэк оборудования от 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, поделить оборудование на группы, и т.д. и т.п.

Продолжение следует.

Комментарии (7)


  1. NAI
    21.11.2024 11:38

    кто-то поправил конфиг...меняем интервалы запроса (interval:86400) для сохранения конфигурации раз в сутки

    Я же правильно понимаю, вы так и не узнаете кто и почему исправил конфиг?

    Мы пошли другим путем - инженер правит yml -> git commit\push --(дальше CI\CD) --> jinja2 генерит конфиг в формате коммутатора и заливает на фтп -> ansible через "copy ftp://config.server/sw1234567.cfg runnning-config" применяет настройки на коммуте -> ждет какое-то время\прогоняет тесты -> заливает конфиг в стартап.

    Попутно всякие тесты выполняются чтобы не выстрелить себе в ногу.

    Сейчас пилим автоматическое выгрузку и сравнение с эталоном (как раз от любителей исправить руками)


    1. Eugene_Kaig Автор
      21.11.2024 11:38

      • Да, этого не узнаем. Но если включать логирование команд и парсить сислог - узнаем. Отличное у вас решение, мы до такого пока не дошли)


    1. Lenar_S
      21.11.2024 11:38

      А вы не смотрели в сторону TACACS+ для логирования кто и какие команды вводит?


      1. Eugene_Kaig Автор
        21.11.2024 11:38

        Смотрели, уже прорабатываю.


      1. NAI
        21.11.2024 11:38

        TACACS+ не везде есть, второе - при коммите в гит пишется коммент который мало-мальски объясняет зачем эти изменения нужны (иногда, просто ID задачи). Плюс на критичное оборудование оформляется MR который проверяет коллега.

        С syslog\TACACS ну увидим мы что джун ошибся октетом и вместо 10.145.233.31 ввел 10.145.233.13, дальше то все равно идти и чинить