Ця стаття присвячена особливостям моніторингу мережі за допомогою протоколу SNMPv3. Ми поговоримо про SNMPv3, я поділюся своїми доробками зі створення повноцінних шаблонів в Zabbix, і покажу, чого можна досягти при організації розподіленого алертингу у великій мережі. Протокол SNMP є основним при моніторингу мережного обладнання, а Zabbix відмінно підходить для моніторингу великої кількості об'єктів і узагальнення значних обсягів метрик.
Декілька слів про SNMPv3
Почнемо з призначення протоколу SNMPv3 та особливостей його використання. Завдання SNMP – моніторинг мережевих пристроїв, та елементарне керування, за допомогою відправки на них простих команд (наприклад, увімкнення та вимкнення мережевих інтерфейсів, або перезавантаження пристрою).
Головна відмінність протоколу SNMPv3 від його попередніх версій, це класичні функції безпеки [1-3], а саме:
- автентифікація (Authentication), що визначає, що запит отримано від довіреного джерела;
- шифрування (Encryption), для запобігання розкриття даних, що передаються при їх перехопленні третіми особами;
- цілісність (Integrity), тобто гарантія того, що пакет не був підроблений під час передачі.
SNMPv3 має на увазі використання моделі безпеки, при якій стратегія аутентифікації встановлюється для заданого користувача та групи, до якої він відноситься (у попередніх версіях SNMP у запиті від сервера до об'єкта моніторингу порівнювалося лише «community», текстовий рядок з «паролем», що передається у відкритому вигляді (Plain text)).
SNMPv3 вводить поняття рівнів безпеки – допустимих рівнів безпеки, що визначають налаштування обладнання та поведінку SNMP-агента об'єкта моніторингу. Поєднання моделі безпеки та рівня безпеки визначає, який механізм безпеки використовується для обробки пакету SNMP [4].
У таблиці описані комбінації моделей та рівнів безпеки SNMPv3 (перші три стовпці я вирішив залишити як в оригіналі):
Відповідно, ми будемо використовувати SNMPv3 в режимі автентифікації із застосуванням шифрування.
Налаштування SNMPv3
Моніторинг мережного обладнання передбачає однакову настройку протоколу SNMPv3 і на сервері моніторингу, і на об'єкті, що спостерігається.
Почнемо з налаштування мережевого пристрою Cisco, його мінімально необхідна конфігурація виглядає наступним чином (для конфігурування використовуємо CLI, імена та паролі я спростив, щоб уникнути плутанини):
snmp-server group snmpv3group v3 priv read snmpv3name
snmp-server user snmpv3user snmpv3group v3 auth md5 md5v3v3v3 priv des des56v3v3v3
snmp-server view snmpv3name iso includedПерший рядок snmp-server group - визначає групу SNMPv3-користувачів (snmpv3group), режим читання (read), і право доступу групи snmpv3group на перегляд певних гілок MIB-дерева об'єкта моніторингу (snmpv3name далі в конфігурації задає, до яких вет snmpv3group зможе отримати доступ).
Другий рядок snmp-server user – визначає користувача snmpv3user, його приналежність до групи snmpv3group, а також застосування аутентифікації md5 (пароль для md5 – md5v3v3v3) та шифрування des (пароль для des – des56v3v3v3). Зрозуміло, замість des краще використовувати aes, тут я наводжу його просто для прикладу. Так само при визначенні користувача можна додати список доступу (ACL), що регламентує IP-адреси серверів моніторингу, що мають право здійснювати моніторинг даного пристрою - це так само best practice, але я не ускладнюватиму наш приклад.
Третій рядок snmp-server view визначає кодове ім'я, яке задає гілки MIB-дерева snmpv3name, щоб їх могла запитувати група користувачів snmpv3group. ISO, замість строгого визначення однієї гілки, дозволяє групі користувачів snmpv3group отримувати доступ до всіх об'єктів MIB-дерева об'єкта моніторингу.
Аналогічна настройка обладнання Huawei (так само в CLI) виглядає так:
snmp-agent mib-view included snmpv3name iso
snmp-agent group v3 snmpv3group privacy read-view snmpv3name
snmp-agent usm-user v3 snmpv3user group snmpv3group
snmp-agent usm-user v3 snmpv3user authentication-mode md5
md5v3v3v3
snmp-agent usm-user v3 snmpv3user privacy-mode des56
des56v3v3v3Після налаштування мережевих пристроїв необхідно перевірити наявність доступу з сервера моніторингу за протоколом SNMPv3, я скористаюся snmpwalk:
snmpwalk -v 3 -u snmpv3user -l authPriv -A md5v3v3v3 -a md5 -x des -X des56v3v3v3 10.10.10.252
Наочніший інструмент для запиту конкретних OID-об'єктів, з використанням MIB-фалів – snmpget:
Тепер перейдемо до налаштування типового елемента даних для SNMPv3 у рамках Zabbix-шаблону. Для простоти та незалежності від MIB, я використовую цифрові OID:
Я використовую в ключових полях макроси, оскільки вони будуть однакові для всіх елементів даних у шаблоні. Задавати їх можна в рамках шаблону, якщо у Вашій мережі у всіх мережних пристроїв параметри SNMPv3 однакові, або в рамках вузла мережі, якщо параметри SNMPv3 для різних об'єктів моніторингу відрізняються:
Зверніть увагу, система моніторингу має лише ім'я користувача, і паролі для аутентифікації та шифрування. Група користувачів та область MIB-об'єктів, до яких дозволено доступ, задається на об'єкті моніторингу.
Тепер перейдемо до заповнення шаблону.
Шаблон опитування в Zabbix
Просте правило під час створення будь-яких шаблонів опитування – робити їх максимально докладними:
Я приділяю велику увагу інвентаризації, щоби з великою мережею було зручніше працювати. Про це трохи пізніше, а поки що – тригери:
Для зручності візуалізації тригерів в їх назви закладені системні макроси {HOST.CONN}, щоб на дашборді в розділі аллертингу виводилися не тільки імена пристроїв, але й IP-адреси, хоча це питання зручності більше, ніж необхідності. Для визначення недоступності пристрою, окрім звичайного echo-запиту, я використовую перевірку на недоступність вузла за протоколом SNMP, коли об'єкт доступний за ICMP, але не відповідає на SNMP-запити – така ситуація можлива, наприклад, при дублюванні IP-адрес на різних пристроях, через некоректно налаштовані міжмережеві екрани, або неправильні установки SNMP на об'єктах моніторингу. Якщо використовувати перевірку доступності вузлів тільки з ICMP, в момент розслідування інцидентів у мережі, даних моніторингу може не виявитися, тому їх надходження потрібно контролювати.
Перейдемо до виявлення мережевих інтерфейсів – для мережного обладнання це найважливіша функція моніторингу. Оскільки на мережному пристрої можуть бути сотні інтерфейсів, необхідно фільтрувати непотрібні, щоб не захаращувати візуалізацію та не захаращувати базу даних.
Я використовую стандартну функцію виявлення для SNMP, з великою кількістю параметрів, що виявляються, для більш гнучкої фільтрації:
discovery[{#IFDESCR},1.3.6.1.2.1.2.2.1.2,{#IFALIAS},1.3.6.1.2.1.31.1.1.1.18,{#IFADMINSTATUS},1.3.6.1.2.1.2.2.1.7]
При такому виявленні, можна фільтрувати мережеві інтерфейси за їх типами, описами користувача «description», і адміністративним статусам портів. Фільтри та регулярні вирази для фільтрації в моєму випадку виглядають так:
При виявленні будуть виключені такі інтерфейси:
- вимкнені вручну (adminstatus<>1), завдяки IFADMINSTATUS;
- які не мають текстового опису, завдяки IFALIAS;
- що мають у текстовому описі символ *, завдяки IFALIAS;
- є службовими або технічними, завдяки IFDESCR (у моєму випадку, у регулярних виразах IFALIAS та IFDESCR перевіряються одним регулярним виразом або).
Шаблон для збору даних протоколу SNMPv3 майже готовий. Не будемо докладніше зупинятись на прототипах елементів даних для мережних інтерфейсів, перейдемо до результатів.
Підсумки моніторингу
Для початку – інвентаризація невеликої мережі:
Якщо підготувати шаблони для кожної серії мережевих пристроїв - можна домогтися зручної для аналізу компонування зведених даних за актуальним програмним забезпеченням, серійними номерами, і оповіщення про прихід до серверної прибиральниці (через малого Uptime). Витримка мого списку шаблонів нижче:
А тепер – головна панель моніторингу, з розподіленими за рівнем важливості тригерами:
Завдяки комплексному підходу до шаблонів для кожної моделі пристроїв у мережі можна домогтися того, що в рамках однієї системи моніторингу буде організовано інструмент для прогнозування несправностей та аварій (за наявності відповідних датчиків і метрик). Zabbix добре підходить для моніторингу мережевих, серверних, сервісних інфраструктур і завдання обслуговування мережного обладнання наочно демонструє її можливості.
Список використаних джерел:1. Hucaby D. CCNP Routing and Switching SWITCH 300-115 Official Cert Guide. Cisco Press, 2014. pp. 325-329.
2. RFC 3410.
3. RFC 3415.
4. SNMP Configuration Guide, Cisco IOS XE Release 3SE. Chapter: SNMP Version 3.
Джерело: habr.com