Այս հոդվածը նվիրված է SNMPv3 պրոտոկոլի միջոցով ցանցային սարքերի մոնիթորինգի առանձնահատկություններին: Մենք կքննարկենք SNMPv3-ը, կկիսվիմ իմ փորձով Zabbix-ում ամբողջական տEMPLATE-ներ ստեղծելու վերաբերյալ և ցույց կտամ, թե ինչ կարելի է ձեռք բերել լայն ցանցում բաժանված նախազգուշացման կազմակերպման ժամանակ: SNMP պրոտոկոլը հիմնականն է ցանցային սարքերի մոնիթորինգի համար, իսկ Zabbix-ը միանշանակ հարմար է շատ օբյեկտների մոնիթորինգի և մեծ մետրիկաների հավաքման համար:
Ամենապոքր խոսքեր SNMPv3-ի մասին
Սկզբից սկսենք SNMPv3 պրոտոկոլի նշանակությունից և դրա օգտագործման առանձնահատկություններից: SNMP-ի խնդիրներն են ցանցային սարքերի մոնիթորինգը և էլեմենտար կառավարման իրականացումը՝ շնորհիվ նրանց վրա պարզ հրամաններ ուղարկելու (օրինակ, ցանցային ինտերֆեյսների միացմանը կամ անջատմանը կամ սարքի վերագործարկմանը):
SNMPv3 պրոտոկոլի հիմնական տարբերությունն անցյալ տարբերություններից նրա դասական անվտանգության ֆունկցիաներն են [1-3], սակայն, մասնավորապես:
- վավերացում (Authentication), որը սահմանում է, որ հարցումը ստացվել է վստահելի աղբյուրից;
- Encryption (Encryption), որի միջոցով կանխարգելվում է տվյալների բացահայտումը՝ նրանց երրորդ կողմերի կողմից բռնակալելու ժամանակ;
- ինտեգրություն (Integrity), այսինքն, երաշխիք այդ պիտակը փոխանցման ընթացքում չի եղել կեղծված:
SNMPv3-ն ենթադրում է անվտանգության մոդելի օգտագործումը, որի ընթացքում վավերացման ռազմավարությունը սահմանվում է տեղի օգտվողի և նրա հետ համայնքի վարչության համար (SNMP-ի անցյալ տարբերություններում հարցումը դիտարկվել է էլեկտրոնային հանրույթի հետ, գրական նախադասությունով «паролем», որն անցնում է բաց տեսքով (plain text)):
SNMPv3-ը կներդնի անվտանգության մակարդակների հասկացությունը՝ թույլատրելի անվտանգության մակարդակների, որոնք սահմանում են սարքի կարգավորումներն ու SNMP-գործակալի վարքագիծը մոնիթորինգի օբյեկտի: Ապահովման մոդալի համադրությունը և անվտանգության մակարդակը որոշելու, թե ինչպես է անվտանգությունը մշակվում SNMP բեռի (packet) ընթացակարգի ժամանակ [4].
Այս աղյուսակում նկարագրված են SNMPv3-ի մոդալների և անվտանգության մակարդակների համադրությունները (առաջին երեք սյուները որոշեցի թողնել օրիգինալ տեսքով):
Մեզանում, համապատասխանաբար, SNMPv3-ը կիրառում ենք վավերացումի ռեժիմում՝ օգտագործելով Encryption:
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 կոնֆիգուրացիայում որոշում է, թե որոնց MIB ծառի ճյուղերին կարող է մուտք ունենալ snmpv3group խումբը):
Երկրորդ տողը snmp-server user - որոշում է snmpv3user օգտվողին, նրա պատկանելությունը snmpv3group խմբին, ինչպես նաև md5 վավերականացման կիրառումը (md5 գաղտնաբառը՝ md5v3v3v3) և des շիֆրումը (des գաղտնաբառը՝ des56v3v3v3): Իհարկե, des-ի փոխարեն լավ կլիներ օգտագործել aes, այստեղ ես այն բերեցի պարզապես օրինակ համար: Եթե օգտվողը սահմանվում է, կարելի է ավելացնել մուտքի ցուցակ (ACL), որը կարգավորում է դիտման սարքերի IP հասցեները, որոնք իրավունք ունեն մոնիտորինգ անել այս սարքը՝ սա նույնպես լավագույն պրակտիկայի մասն է, բայց չեմ ուզում բարդացնել մեր օրինակը:
Երրորդ տողը snmp-server view որոշում է ֆունկցիոնալ անվանումը, որը սահմանում է snmpv3name MIB ծառի ճյուղերը, որպեսզի 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:
Ա maintenant, ամենակենցի տանելու համար SNMPv3 կամենի տվյալների տեսակ որոշելու ռեժիմ Zabbix-ին, ես կիրառում եմ թվային OID-ներ:
Ներդրում եմ հիմնական դաշտերում օգտագործողի մաքսանքներ, քանզի դրանք նույնական են ձևի բոլոր տվյալների համար: Դրանք հնարավոր է սահմանել ձևի շրջանակներում, եթե ձեր ցանցում բոլոր ցանցական սարքերի SNMPv3 պարամետրերը նույնական են, կամ ցանցի հանգույցի շրջանակներում, եթե SNMPv3 պարամետրերը տարբեր մոնիտորինգ օբյեկտների համար տարբերվում են:
Խնդրում եմ նկատի ունենալ, որ մոնիտորինգի համակարգը տրամադրում է միայն օգտվողի անունը և վավերացման ու շիֆրման գաղտնաբառերը: Օգտվողների խումբը և MIB օբյեկտների ոլորտը, որոնց մուտք ունի, սահմանվում է մոնիտորինգի օբյեկտի վրա:
Այժմ անցնենք ձևի լրացմանը:
Zabbix-ում հարցման ձևը
Նախագծել ցանկացած հարցման ձևի ժամանակ պարզ օրենք է՝ անել դրանք հնարավորինս մանրամասն:
Ես նշանակալի ուշադրություն եմ դարձնում ներդրումային գործիքներին, որպեսզի մեծ ցանցով ավելի հարմար դառնա աշխատելը: Այդ մասին մի քիչ ավելի ուշ, իսկ այժմ՝ եռանկյուններ:
Հարմարավետության համար, հրահրողների տեսողականացումում դրանց անուններին ներառված են համակարգային մակրոբները {HOST.CONN}, որպեսզի դաշտում ցուցադրվեն ոչ միայն սարքերի անունները, այլ նաև IP հասցեները: Թեև սա ավելի շատ հարմարավետության հարց է, քան անհրաժեշտության: Սարքի հասանելիությունը որոշելու համար, սովորական echo հարցման հետ միասին, ես օգտագործում եմ SNMP պրոտոկոլով узла պիտանիության ստուգում, երբ ունկնդիրը հասանելի է ICMP-ի միջոցով, բայց չի արձագանքում SNMP հարցումներին: Այսպիսի իրավիճակ կարող է առաջանալ, օրինակ, IP հասցեների կրկնության պատճառով տարբեր սարքերում, սխալ կազմաձևված firewall-ների պատճառով կամ SNMP ենթարկվող սարքերի սխալ կարգավորմամբ: Եթե ստուգանշանքի հասանելիությունը իրականացվի միայն ICMP-ի միջոցով, կրթության ընթացքում կազմված տվյալները կարող են բացակայել, ուստի դրանց գալը պետք է վերահսկվի:
Հիալենք ցանցային հանձնումների հայտնաբերմանը. ցանցային սարքերի համար սա չափազանց կարևոր մոնիտորինգի գործառույթ է: Որպեսզի ցանցային սարքում կարող են լինել հարյուրավոր հանձնումներ, անհրաժեշտ է զտել ավելորդները, որպեսզի չեն ծանրաբեռնում տեսողականացումը և բանադatabase-ն:
Ես օգտագործում եմ ստանդարտ հայտնաբերման գործառույթը 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): Իմ շաբլոնների ցանկը ներքևում:
Այժմ՝ հիմնական մոնիտորինգի վահանակը, խստագրված կարևորության մակարդակներով հրահրողներով:
Device models in the network can achieve a comprehensive approach to templates, allowing a tool for predicting failures and emergencies (provided there are appropriate sensors and metrics) to be organized within one monitoring system. Zabbix is well-suited for monitoring network, server, and service infrastructures, and the task of maintaining network equipment clearly demonstrates its capabilities.
Օգտագործված աղբյուրների ցանկ՝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
