Гэты артыкул прысвечаны асаблівасцям маніторынгу сеткавага абсталявання з дапамогай пратакола 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 правяраюцца адным рэгулярным выразам alias).
Шаблон для збору дадзеных па пратаколе 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