UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO,

RAČUNALNIŠTVO IN INFORMATIKO

Renato Mikša

PROTOKOL SNMP IN NAMESTNIŠKI STREŢNIK

Diplomska naloga

Maribor, september 2008

i

UNIVERZA V MARIBORU

FAKULTETA ZA ELEKTROTEHNIKO, RAČUNALNIŠTVO IN INFORMATIKO 2000 Maribor, Smetanova ul. 17

Diplomska naloga visokošolskega strokovnega študijskega programa

PROTOKOL SNMP IN NAMESTNIŠKI STREŢNIK

Študent: Renato MIKŠA

Študijski program: visokošolski strokovni, Računalništvo in informatika

Smer: Programska oprema

Mentor: izr. prof. dr. Božidar POTOČNIK

Maribor, september 2008

ii

ZAHVALA

Zahvaljujem se mentorju dr. Boţidar Potočniku za

pomoč in vodenje pri opravljanju diplomske

naloge. Prav tako se zahvaljujem zaposlenim v

podjetju MG-Soft, za pomoč pri programski

izvedbi produkta.

Posebna zahvala velja staršem, ki so mi omogočili

študij.

iii

PROTOKOL SNMP IN NAMESTNIŠKI

STREŢNIK

Ključne besede: protokol SNMP, namestniški streţnik, oddaljena diagnostika,

preizkušanje programske opreme

UDK: 004.4.057.4(043.2)

Povzetek

Danes se srečujemo z ogromnim številom različnih računalniških naprav, ki potrebujejo

določen nadzor. Komunikacija med nadzorovano in nadzorno napravo pa seveda mora

potekati po določenem, vnaprej predpisanem protokolu. To je bila glavna motivacija za

nastanek in razvoj protokola SNMP (Simple Network Management Protocol). Danes

obstajajo že tri različice in množica podrazličic protokola SNMP, pri čemer različica 1 ne

zagotavlja nikakršne varnosti in zasebnosti pri komunikaciji, medtem ko različica 3 lahko

zagotovi popolno varnost in zasebnost med komuniciranjem.

Cilj te diplomske naloge je bil podrobno preučiti protokol SNMP in razviti

namestniški strežnik, ki zna delati s tem protokolom in pretvarjati sporočila med različnimi

verzijami protokola SNMP, in sicer med različicami 1, 2c in 3. Naš razviti namestniški

strežnik smo temeljito preizkusili s klasičnimi metodami preizkušanja programske opreme.

Pravilnost delovanja tega programskega produkta smo potrdili na nekaj testnih primerih.

Ob tem smo pregledali še področja v industriji, kjer se protokol SNMP že s pridom

uporablja. Analizirali in raziskali smo tudi trg, kjer smo ugotovili, da programski produkt,

ki bi imel vso funkcionalnost našega namestniškega strežnika, še ne obstaja. Naš izdelek se

trenutno nahaja v testiranju pri določenih končnih uporabnikih. Prve povratne

informacije so pozitivne, saj kažejo na veliko zadovoljstvo končnih uporabnikov

iv

SNMP PROTOCOL AND PROXY SERVER

Key words: SNMP protocol, proxy server, remote diagnostic, software testing

UDK: 004.4.057.4(043.2)

Abstract

Nowadays we face an ever increasing number of computer appliances that need some kind

of control. A communication between the controlling and the controlled computer device

has to use a certain pre-defined protocol to be effective. This was the main motivation for

an origin and development of the SNMP protocol (Simple Network Management Protocol).

There exist already three versions and several sub-versions of this protocol, whereat the

version 1 does not provide any privacy and safety at communication, while the version 3

guarantees a completely safe and private communication.

A purpose of this diploma project was to thoroughly analyze the SNMP protocol

and develop a proxy server which will be able to handle this protocol and transform

messages between different versions of SNMP protocol, namely between versions 1, 2c,

and 3. Our developed proxy server was thoroughly tested by using classical software

testing methods. Correctness of this software was verified by several testing examples.

Besides, we also surveyed fields in the industry, where SNMP protocol is already

prosperously used. We analyzed and researched a targeted market for our product and

found out that there exist no similar programming products, which will have complete

functionality of our proxy server. We offered our software to some of the interested end-

users for testing purposes. The first feedbacks are positive, namely they indicate a great

satisfaction of the end-users.

v

VSEBINA

1 UVOD ............................................................................................................................ 1

2 PREGLED OBSTOJEČIH REŠITEV ........................................................................... 3 3 PROTOKOL SNMP ...................................................................................................... 7

3.1 Pregled in osnovni koncept ..................................................................................... 7

3.2 Podrobnosti protokola ............................................................................................. 9 3.3 Razvoj in uporaba protokola ................................................................................. 12

4 UPORABA PROTOKOLA SNMP V REALNEM OKOLJU .................................... 16 4.1 Potreba po namestniku .......................................................................................... 16 4.2 Opis sistema........................................................................................................... 17

4.3 Primer scenarija delovanja sistema ....................................................................... 17 4.4 Spremembe konfiguracije...................................................................................... 18

4.5 Problem preslikave zahtev..................................................................................... 19 4.5.1 Moţne implementacije preslikav ................................................................. 19

4.6 Problem preslikave odgovorov .............................................................................. 21

5 NAMESTNIK SNMP PROXY AGENT ..................................................................... 22 5.1 Načrt in razvoj programskega produkta ................................................................ 22

5.1.1 Korak 1 – osnovno sprejemanje in posredovanje sporočil........................... 22 5.1.2 Korak 2 – uvedba protokola SNMPv3 ......................................................... 23 5.1.3 Korak 3 – omogočanje večjega števila preslikav ......................................... 23

5.1.4 Korak 4 – zapis podatkov v konfiguracijsko datoteko ................................. 23 5.1.5 Korak 5 – podpora sporočilom SNMP TRAP in INFORM ......................... 26

5.1.6 Korak 6 – prenos na operacijski sistem Unix............................................... 27 5.1.7 Korak 7 – program za urejanje konfiguracijske datoteke ............................ 27

5.2 Implementacija ...................................................................................................... 27

5.2.1 Korak 1 – osnovno sprejemanje in posredovanje sporočil........................... 28 5.2.2 Korak 2 – uvedba protokola SNMPv3 ......................................................... 29

5.2.3 Korak 3 – omogočanje večjega števila preslikav ......................................... 31 5.2.4 Korak 4 – zapis podatkov v konfiguracijsko datoteko ................................. 31 5.2.5 Korak 5 – podpora sporočilom SNMP TRAP in INFORM ......................... 33

5.2.6 Korak 6 – prenos na operacijski sistem Unix............................................... 33 5.2.7 Korak 7 – program za urejanje konfiguracijske datoteke ............................ 34

6 PREIZKUŠANJE NAMESTNIŠKEGA STREŢNIKA .............................................. 40 6.1 Preizkušanje po metodi bele škatle ........................................................................ 40 6.2 Preizkušanje po metodi črne škatle ....................................................................... 41

6.3 Namestnik in oddaljeno diagnosticiranje .............................................................. 41 6.3.1 Oddaljeno diagnosticiranje........................................................................... 41

6.3.2 Uporaba namestniškega streţnika za oddaljeno diagnosticiranje ................ 42 7 REZULTATI IN DISKUSIJA ..................................................................................... 45

7.1 Primer delovanja.................................................................................................... 45

7.1.1 Vnos podatkov za preslikavo v Konfigurator .............................................. 45 7.1.2 Zagon namestnika ........................................................................................ 46

7.1.3 Aktiviranje delovanja namestnika ................................................................ 47 7.1.4 Preverjanje pravilnosti delovanja namestnika .............................................. 50

7.2 Sklep ...................................................................................................................... 52

8 ZAKLJUČEK .............................................................................................................. 53

vi

LITERATURA .................................................................................................................... 54

vii

KAZALO SLIK

Slika 1: Uporabniški vmesnik SnmpFwd. ............................................................................. 3

Slika 2: Delovanje Snmp Proxy Forwarder-ja podjetja AdventNet. ..................................... 4 Slika 3: Prikaz delovanja sorodnih rešitev. ............................................................................ 5

Slika 4: Umestitev namestnika v sistem. ............................................................................. 18 Slika 5: Primer zapisa preslikave brez profilov. .................................................................. 24 Slika 6: Primer zapisa preslikave s profili. .......................................................................... 25

Slika 7: Dva zgleda za zapis profila: levo profil za verzijo SNMPv1, desno profil za verzijo SNMPv3. ............................................................................................................................. 25

Slika 8: Zapis nove preslikave z vnaprej definiranimi profili. ............................................ 25 Slika 9: Definicija preslikave za sporočila tipa SNMP TRAP in INFORM. ....................... 26 Slika 10: Psevdokod preverjanja varnostnega nivoja za verzijo 3 protokola SNMP. ......... 30

Slika 11: Primer zapisa preslikave v konfiguracijski datoteki. ............................................ 32 Slika 12: Uporabniški vmesnik Konfiguratorja. .................................................................. 34

Slika 13: Okno za dodajanje novih preslikav. ..................................................................... 35 Slika 14: Prikaz okna za urejanje preslikave. ...................................................................... 36 Slika 15: Prikaz okna za delo s profili. ................................................................................ 38

Slika 16: Dialog za dodajanje profilov. ............................................................................... 38 Slika 17: Obvestilo o profilu, ki je v uporabi. ..................................................................... 39

Slika 18: Prikaz preslikave v programskem modulu Konfigurator. .................................... 46 Slika 19: Izpisi pri zagonu namestnika. ............................................................................... 47 Slika 20: Vnos podatkov namestnika v program MIB browser. ......................................... 48

Slika 21: Pošiljanje zahteve na naš namestnik s pomočjo programa MIB browser. ........... 49 Slika 22: Podrobnosti zahteve in prejetega odgovora. ......................................................... 50 Slika 23: Vnos podatkov ciljnega računalnika v program MIB browser. ........................... 50

Slika 24: Pošiljanje zahteve na ciljni računalnik s pomočjo programa MIB Browser. ....... 51 Slika 25: Podrobnosti prejetega odgovora pri preverjanju pravilnosti delovanja našega

namestnika. .......................................................................................................................... 52

viii

Uporabljene kratice

SNMP – enostaven protokol za nadzor omreţij (simple network management protocol)

MIB – managerska informacijska baza (management Information Base)

OID – označevalnik objekta (object identifier)

PDU – podatkovna enota protokola (protocol data unit)

VBL – seznam OIDjev (variable binding list)

RFC – zahteva za komentar (request for comment)

SMI – struktura upraviteljskih informacij (Structure of Management Information)

IETF – druţba za definiranje internetnih standardov (Internet Engineering Task Force)

ASN.1 – abstraktna sintaksa zapisa ena (Abstract syntax notation one)

NMS – mreţno-upraviteljski sistemi (Network-management systems)

IP – internetni protokol (Internet protocol)

OSI – medsebojne odprte sistemske povezave (Open Systems Interconnection)

UDP – nepovezovalni protokol za prenašanje paketov (User Datagram Protocol)

CLNS – brezpovezavni mreţni servis (Connectionless Network Service)

DDP – Protokol za povezavo preko AppleTalk omreţij (Datagram-Delivery Protocol)

IPX – Medmreţna izmenjava paketov (Interneworkt Packet Exchange)

USM – uporabniški varnostni model (User-based Security Model)

VACM – uporabniški model za nadzor dostopa (View Access Control Model)

USB – univerzalno serijsko vodilo (universal serial bus)

1

1 UVOD

V današnjem času imamo ogromno računalniško vodenih naprav, ki opravljajo

najrazličnejša dela. Srečujemo se, na primer, z raznimi roboti v proizvodnji,

usmerjevalniki, bančnimi avtomati in še z mnogimi drugimi napravami. Ob svoji osnovni

funkcionalnosti delovanja imajo te naprave običajno vgrajeno še posebno programsko

opremo za njihov nadzor in krmiljenje. Z ustreznim povezovanjem in komuniciranjem,

lahko ti programi posredujejo odgovornim osebah sporočila o stanju naprav. Seveda ne

ţelimo, da bi bilo veliko različnih protokolov, preko katerih bi ti programi za nadzor

delovali oz. komunicirali. Organizacija IETF (Internet Engineering Task Force) je zato

definirala protokol SNMP (simple network management protocol), ki standardizira

komunikacijo s takšnimi napravami.

Primarni namen protokola SNMP je nadzor in upravljanje naprav IP (Internet

Protocol). V tej komunikaciji se na eni strani srečujemo z napravo, ki jo ţelimo

nadzorovati, na drugi strani pa je naprava, ki omogoča nadzorovanje oz. upravljanje prve

naprave. Če ţelimo, da se obe napravi razumeta, je seveda nujno, da govorita isti jezik –

uporabljata isti protokol. Prva verzija protokola SNMP ni zagotavljala nikakršne varnosti.

Uporabniki so to seveda identificirali kot veliko pomanjkljivost, zato se je čez čas razvila

še druga verzija tega protokola (tj. protokol SNMPv2), ki je pa imela več različic. Najbolj

razširjena različica je različica "c" (tj. protokol SNMPv2c). Ker pa protokol še vedno ni bil

tako varen, kot so uporabniki ţeleli in zahtevali, so razvili še tretjo verzijo protokola (tj.

protokol SNMPv3), ki pa ţe vključuje ustrezne varnostne mehanizme. Med evolucijo

protokola SNMP so uporabniki v večini primerov samo zamenjali programsko opremo na

nadzorni napravi (manager), medtem ko na nadzorovani napravi (agent) ni bilo moţno

samo zamenjati programske opreme, ampak bi bilo potrebno zamenjati celotno napravo,

kar pa je bil v mnogih primerih prevelik strošek. Tako se v podjetjih, ki so v slabšem

finančnem stanju ali pa preprosto ne ţelijo plačati več tisoč evrov za novo napravo

(agenta), še danes preko mreţe pošiljajo nezavarovani podatki.

Moţna rešitev zgoraj omenjenega problema je v uvedbi t.i. namestniškega streţnika

(proxy server), ki bi bil integriran na strani agenta in bi prestrezal sporočila agenta, ter jih

zakodirana poslal skozi računalniško omreţje k ciljni napravi (managerju). S tem

doseţemo, da se po omreţju pošiljajo zavarovana sporočila, med agentom in namestnikom

2

pa nezavarovana. Slednje v večini primerov niti ni nevarno, saj se agent in namestnik

fizično nahajata skupaj, v mnogih primerih celo v istem računalniškem sistemu.

V tej diplomski nalogi ţelimo podrobno preučiti protokol SNMP in napisati

programsko opremo, ki bo znala delati z najbolj uporabljenimi verzijami protokola in

vsemi tipi sporočil, definiranih za ta protokol. Program bo sprejemal pakete protokola

SNMP, jih preoblikoval v ustrezno verzijo protokola, nastavljal varnostne parametre in

pošiljal pakete protokola SNMP. Da pa se izognemo morebitnim varnostnim luknjam,

bomo program napisali tako, da bo prejemal pakete samo z vnaprej določenimi

varnostnimi parametri in jih pošiljal na vnaprej določene naslove, s prav tako definiranimi

varnostnimi parametri za vsak naslov posebej. Takšno funkcionalnost bomo dosegli s

konfiguracijsko datoteko. Za kreiranje in urejanje konfiguracijske datoteke bomo razvili

posebni programski modul.

Diplomsko delo je sestavljeno iz sedmih poglavij. V drugem poglavju bomo

opravili pregled ţe obstoječih rešitev, ki znajo transformirati sporočila med različnimi

verzijami protokola SNMP. V tretjem poglavju bomo podrobno predstavili protokol

SNMP, v naslednjem poglavju pa bomo opisali, kako je moţno uporabiti protokol SNMP v

realnem okolju, hkrati pa bomo opisali vse gradnike sistema za nadzor naprav. V petem

poglavju bomo podrobno predstavili razvoj in implementacijo našega namestnika. Ob tem

bomo opisali vse probleme, na katere smo naleteli med razvojem, opisali pa bomo tudi,

kako smo jih odpravili. V šestem poglavju si bomo ogledali preizkušanje našega

namestnika. V poglavju z rezultati in diskusijo pa bomo demonstrirali delovanje našega

namestnika ter ovrednotili dobljene rezultate. Diplomsko delo sklenemo s kratkim

zaključkom, kjer povzamemo glavne izsledke tega dela, zapišemo pa tudi glavne smernice

za nadaljnje raziskave.

3

2 PREGLED OBSTOJEČIH REŠITEV

V tem poglavju si bomo pogledali obstoječe rešitve, njihove prednosti in slabosti, ter jih

poskušali primerjati s funkcionalnostjo, ki jo bo imela naša rešitev. Spoznali bomo, da

podobne rešitve ţe obstajajo, vendar z manjšo funkcionalnostjo.

V nadaljevanju bomo predstavili nekaj najpomembnejših obstoječih rešitev, pri

čemer bomo za vsako rešitev uvedli nov razdelek.

a) SNMP v1,v2c,v3 Forwarder Utility

Podjetje LogiSoft AR Ltd. je razvilo produkt imenovan "SNMP v1,v2c,v3 Forwarder

Utility". Njegova funkcionalnost je zelo podobna našim pričakovanim zahtevam, s to

razliko, da ta produkt deluje samo na operacijskem sistemu Windows. Slika 1 prikazuje

uporabniški vmesnik programa SnmpFwd.

Slika 1: Uporabniški vmesnik SnmpFwd.

4

b) SNMP Proxy Forwarder

Kot naslednjo bomo opisal rešitev podjetja AdventNet, ki je poimenovana "SNMP Proxy

Forwarder". Funkcionalnost te programske opreme se v veliki meri sklada z našimi

pričakovanji, vendar pa je ta produkt ponovno omejen zgolj na operacijski sistem

Windows. Na spletni strani proizvajalci piše da podpira tudi verzijo protokola SNMPv3,

vendar pa smo kasneje ugotovili, da ima program še nekaj pomanjkljivosti, med katerimi je

tudi podpora protokolu SNMPv3, katere še niso uspeli dodati. To vsekakor lahko pomeni

večjo trţno vrednost in večjo verjetnost morebitnega uspeha našega produkta. Na sliki 2 je

prikazana shema delovanja SNMP Proxy Forwarderja podjetja AdventNet. Na levi vidimo

več agentov, ki z namestnikom komunicirajo preko protokola verzije 1 ali 2c, na desni pa

so različni managerji, s katerimi namestnik komunicira s protokolom verzije 3 (katera, kot

ţe rečeno, ne deluje v programu). Konfiguracijske podatke namestnik pridobi iz različnih

virov, kot je USM (User-based Security Model), drug agent ali VACM (View Access

Control Model), kot je vidno na sliki spodaj.

Slika 2: Delovanje Snmp Proxy Forwarder-ja podjetja AdventNet.

5

c) Drugo

V literaturi smo odkrili tudi nekaj programskih rešitev, ki pa nimajo popolne

funkcionalnosti, kot je zahtevana za naš produkt. Za nadaljnjo razlago je koristno, da jih na

kratko opišemo. Princip delovanja teh rešitev je prikazan na sliki 3.

Vsi ti produkti so v obliki programske opreme nameščeni na določeno napravo, ki

pa privzeto ne podpira protokola SNMP. Ta programska oprema na nek specifičen način

pridobi podatke od sistema, na primer o temperaturi procesorja, zasedenosti pomnilnika,

porabi električne energije, številu uporabnikov povezanih na to napravo, količini goriva v

avtomobilu, količini barve v kartuši, ali karkoli drugega, kar bi koga utegnilo zanimati.

Primer takega produkta je program podjetja HP (Hewlett-Packard) imenovan HP

SNMP Proxy Agent. Podjetje je razvilo ta produkt za nadzor njihovih tiskalnikov. Za

pravilno delovanje je program potrebno namestiti na vse računalnike, na katere je

priklopljen tiskalnik. Tiskalnik je lahko na računalnik priklopljen preko vodila USB

(universal serial bus) ali paralelne povezave. Sistemski administrator mora imeti nameščen

nadzorni program tega istega podjetja, ki pa zna pridobiti podatke iz vseh tiskalnikov

priklopljenih na računalnike v lokalnem omreţju. Nadzorni program dejansko pridobi

podatke od tiskalnikov v omreţju preko protokola SNMP.

Slika 3: Prikaz delovanja sorodnih rešitev.

6

Po navedbah podjetja HP je nadzor nad tiskalniki skoraj tako dober, kot če bi imeli

tiskalnik povezan lokalno na svoj računalnik. Edini pogoj za takšno delovanje je, da

morajo tiskalniki biti znamke HP in da podpirajo protokol, ki ga uporablja HP SNMP

Proxy Agent.

7

3 PROTOKOL SNMP

Protokol SNMP se uporablja za nadzor naprav povezanih v računalniško omreţje. Z

uporabo tega protokola lahko pridobimo podatke o nadzorovanih sistemih v obliki

spremenljivk, ki med drugim tudi opisujejo konfiguracijo sistema. Namenski nadzorni

programi lahko te spremenljivke prebirajo, včasih pa tudi nastavljajo.

V nadaljevanju bomo opisali bistvene elemente protokola SNMP.

3.1 Pregled in osnovni koncept

V tipičnem sistemu je večje število nadzorovanih naprav. Programska oprema imenovana

agent teče na teh sistemih in sporoča podatke preko protokola SNMP nadzornim sistemom.

Agenti SNMP pošiljajo nadzorne podatke nadzornih sistemov v obliki spremenljivk (npr.

prosti spomin, sistemsko ime, trenutno število procesov). Nadzorni sistem lahko zahteva

informacije z uporabo operacij GET, GETNEXT ali GETBULK protokola SNMP, ali pa

agent sam pošlje podatke (brez zahteve nadzornega sistema) z uporabo operacij TRAP ali

INFORM protokola SNMP. Nadzorni sistemi lahko pošljejo tudi konfiguracijske popravke

ali kontrolne zahteve z operacijo SET. Konfiguracijske in kontrolne operacije se uporabijo

samo takrat, kadar je potrebno izvesti spremembe omreţne infrastrukture. Nadzorne

operacije se izvajajo v rednih intervalih. Spremenljivke v okviru protokola SNMP so

hierarhično organizirane. Organiziranost spremenljivk skupaj z meta podatki (npr. tip in

opis) opisuje managerska informacijska baza (MIB – Management Information Base).

Managerska informacijska baza (MIB)

Protokol SNMP ne definira, katere informacije (spremenljivke) naj nadzorovani sistem

nudi navzven. Raje uporablja razširjeno zasnovo, kjer so razpoloţljive informacije

določene z bazami MIB. Te opisujejo strukturo nadzorovanih podatkov podsistema

naprave, uporabljajo hierarhične imenske prostore (namespace), ki vsebujejo

označevalnike objekta (OID – Object Identifier). Vsak OID določa spremenljivko, ki jo

lahko beremo ali nastavljamo preko protokola SNMP. Označevalnik objekta OID unikatno

8

definira nadzorovan objekt v hierarhiji MIB. Baze MIB uporabljajo zapis imenovan ASN.1

– abstraktna sintaksa zapisa ena (abstract syntax notation one).

Hierarhijo baz MIB si lahko predstavljamo kot drevesno strukturo, pri čemer koren

nima imena, podnivoji pa so dodeljeni različnim organizacijam. Zgornji označevalniki OID

baz MIB pripadajo različnim organizacijam, ki določajo standarde, na niţjem nivoju pa so

označevalniki OID dodeljeni zdruţenim (in manjšim) organizacijam. Takšna struktura

omogoča nadzor nad vsemi plastmi modela OSI (Open Systems Interconnection), sam

nadzor pa se lahko razširja tudi v aplikacije, kot so podatkovne baze ali elektronska pošta,

saj se lahko baze MIB namreč definirajo za najrazličnejša področja informacij in operacij.

Vsaka nadzorovana naprava ima več nadzorovanih objektov (t.i. objekt MIB, ali

povedano kratko objekt oz. MIB). Nadzorovan objekt pa sestoji iz ene ali več instanc

objekta identificiranega z označevalnikom OID. V večini primerov gre za spremenljivke.

Obstajata dva tipa nadzorovanih objektov:

1. skalarni objekti, ki definirajo eno instanco objekta,

2. tabelarni objekti, ki definirajo več sorodnih instanc objekta zdruţenih v tabelo

MIB.

Primer nadzorovanega objekta je atInput. To je skalarni objekt, ki vsebuje eno instanco

objekta (t.j. celoštevilsko vrednost) in hrani skupno število prejetih paketov AppleTalk na

vmesniku usmerjevalnika.

Abstraktna sintaksa zapisa ena (ASN.1)

V telekomunikacijskih in računalniških omreţjih je zapis ASN.1 standarden in prilagodljiv

zapis, ki opisuje strukturo podatkov za predstavitev, kodiranje, prenos, in dekodiranje

podatkov. Nudi mnoţico formalnih pravil za opis struktur objek tov, ki so neodvisni od

strojno-specifičnih kodirnih tehnik. Hkrati pa je natančen formalni zapis, ki odstranjuje

vsake dvoumnosti.

Zapis ASN.1 je skupen standard organizacij ISO in ITU-T, prvotno definiran leta

1984, kot del nekega drugega standarda. Kasneje, leta 1988, je zaradi velike uporabnosti

postal svoj standard. Leta 1995 pa je bil še krepko posodobljen.

9

Prilagojena podmnoţica standarda ASN.1, tj. struktura managerskih informacij

(SMI – structure of management information) je navedena v protokolu SNMP za

definiranje skupin povezanih objektov MIB, drugače imenovanih tudi moduli MIB.

Osnovne komponente protokola SNMP

Omreţje nadzorovano s protokolom SNMP sestavljajo tri ključne komponente:

1. nadzorovane naprave,

2. agenti, in

3. mreţno-managerski sistemi (NMS –network-management system).

Nadzorovana naprava je mreţno vozlišče, ki vsebuje agenta SNMP in se nahaja v

nadzorovanem omreţju. Nadzorne naprave zbirajo in hranijo nadzorovane informacije in

jih dajo na voljo sistemom NMS, ki seveda uporabljajo protokol SNMP. Nadzorovana

naprava (t.i. mreţni elementi) je lahko vsaka naprava, vključno z usmerjevalniki, stikali,

telefoni IP, tiskalniki, računalniki itd.

Agent je mreţno-upraviteljski programski modul, ki se nahaja v nadzorovani

napravi. Agent pozna lokalne nadzorovane informacije, ki jih je zmoţen pretvoriti v

obliko, zdruţljivo s protokolom SNMP.

Sistem NMS izvaja programe, ki spremljajo in nadzirajo nadzorovane naprave.

Sistemi NMS zagotovijo potreben procesorski čas in pomnilniški prostor za nadzor

omreţja. V vsakem nadzorovanem omreţju je lahko eden ali več sistemov NMS.

3.2 Podrobnosti protokola

Podatkovni tipi SMI v verziji SNMPv1

Verzija SNMPv1 za strukturo SMI določa uporabo številnih podatkovnih tipov, ki jih

delimo v dve skupini:

1. preprosti podatkovni tipi in

2. aplikacijski podatkovni tipi.

10

V strukturi SMI verzije SNMPv1 so definirani trije preprosti podatkovni tipi:

1. celo številčni tip podatkov v območju med -231 do 231-1,

2. oktetni niz znakov – to so urejena zaporedja od 0 do 65535 oktetov,

3. označevalniki OID – dobimo jih iz skupka vseh OID, glede na pravila definirana v

zapisu ASN.1.

V strukturi SMI verzije SNMPv1 obstaja sedem aplikacijskih podatkovnih tipov:

1. Omreţni naslovi – predstavljajo naslov iz določene druţine protokola. Verzija

SNMPv1 podpira samo 32 bitne naslove IP.

2. Števci – vsebujejo ne-negativne številčne vrednosti, ki se povečujejo dokler ne

doseţejo največje dovoljene vrednosti, nato se vrnejo na nič. V verziji SNMPv1

poznamo samo 32 bitne števce.

3. Merilniki (gauges) – vsebujejo ne-negativne številčne vrednosti, ki se lahko

povečujejo ali zmanjšujejo med vnaprej predpisano najmanjšo in največjo

dovoljeno vrednostjo.

4. Časovna enota (time tick) – predstavlja čas nekega dogodka, izraţen v stotinkah

sekunde.

5. Prosojnost (opaque) – določa kodiranje, ki se uporablja za pridobivanje informacij

iz niza znakov, ki ne podpirajo standarda določenega z zapisom ASN.1.

6. Predznačena celoštevilčna vrednost (integer).

7. Nepredznačena celoštevilčna vrednost (unsigned integer).

Tabele MIB v verziji SNMPv1

Struktura SMI v verziji SNMPv1 definira strogo strukturirane tabele, ki se uporabljajo za

zdruţevanje tabelaričnih objektov (tj. objekt, ki vsebuje več spremenljivk). Tabele imajo

nič ali več vrstic, ki so oštevilčene tako, da lahko protokol SNMP pridobi ali spremeni

celotno vrstico z eno operacijo, npr. GET, GETNEXT ali SET.

11

Strukture SMI v SNMPv2

Struktura SMI v verziji SNMPv2 je opisana v določilu RFC 2578 (request for comment).

Prinaša nekaj dopolnil in izboljšav glede na podatkovne tipe SMI v verziji SNMPv1, kot

na primer bitne nize znakov, omreţne naslove in števce. Bitni nizi znakov so definirani

samo v verziji SNMPv2 in so sestavljeni iz nič ali več bitov. Omreţni naslov predstavlja

naslov iz določene druţine protokolov. Števci so ne-negativna cela števila, ki se povečujejo

do največje dovoljene vrednosti, potem pa se vrnejo na nič. V verziji SNMPv2 poznamo

tako 32- kot tudi 64-bitne števce.

Protokol SNMP deluje v aplikacijski plasti 7 modela OSI. V verziji SNMPv1 je

specificiranih pet podatkovnih enot protokola (PDU – Protocol data unit):

1. GET zahteva – se uporablja za pridobitev dela nadzorovanih informacij.

2. GETNEXT zahteva – se uporablja iterativno za zaporedno pridobitev nadzorovanih

informacij.

3. GET odgovor – uporabi agent kot odgovor na GET ali SET zahtevo.

4. SET zahteva – se uporabi za inicializacijo in spreminjanje vrednosti.

5. TRAP – se uporabi za sporočanje alarmov ali drugih asinhronih dogodkov na

nadzorovanem podsistemu. V verziji SNMPv1 so asinhroni dogodki imenovani

"trap", v vseh poznejših verzijah pa "inform". V modulih MIB v strukturi SMI

verzije SNMPv1 so "trapi" definirani z uporabo makroja TRAP-TYPE, v verziji

SNMPv2 pa jih definiramo z uporabo makroja NOTIFICATION-TYPE.

V verziji SNMPv2 sta bili dodani naslednji enoti PDU:

1. GETBULK zahteva – hitrejša metoda za pridobitev več nadzorovanih podatkov.

2. INFORM –podobna operaciji TRAP, vendar zahteva odgovor.

Običajno SNMP uporablja vrata UDP (User Datagram Protocol) številka 161 za agenta in

vrata številka 162 za managerja. Manager lahko pošlje zahtevo iz poljubnih vrat (izvorna

vrata) na vrata številka 161, ki pripadajo agentu (ciljna vrata). Odgo vor agenta se pošlje

nazaj na izvorna vrata. Manager sprejema "trape" na vratih številka 162, agent pa jih lahko

pošilja iz poljubnih vrat.

12

Informacijski moduli SMI v verziji SNMPv2

Strukture SMI v verziji SNMPv2 prav tako navajajo informacijske module, ki določajo

skupine sorodnih definicij. Obstajajo tri skupine informacijskih modulov SMI:

1. moduli MIB – vsebujejo definicije sorodnih nadzorovanih objektov.

2. Izjave ustreznosti – zagotavljajo sistematičen način za opis skupine nadzorovanih

objektov.

3. Izjave zmoţnosti – uporabljene so za prikaz natančnega nivoja podpore, ki ga

pričakuje agent od skupine MIB. Sistem NMS lahko prilagodi odnos do agenta

glede na agentovo izjavo zmoţnosti.

Verzija SNMPv3

Verzija SNMPv3 je definirana z določili RFC 3411 do RFC 3418. Verzija SNMPv3

zagotavlja večjo varnost komunikacije, hkrati pa izboljša moţnost oddaljenega

konfiguriranja. Ta verzija je od leta 2004 standardna verzija protokola SNMP.

Organizacija IETF je označila verzijo SNMPv3 za popoln internetni standard, kar je

najvišje priznanje, ki ga lahko prejme protokol, določen z določili RFC. Prejšnje verzije

protokola SNMP so zastarele (obsolete). Verzija SNMPv3 nudi pomembne varnostne

funkcije:

1. Integriteta sporočil – zagotavlja, da nihče ne more prestreči paketa na poti.

2. Overitev (authentication) – zagotavlja, da je paket iz veljavnega vira.

3. Šifriranje paketov (encryption) – onemogoči nepooblaščenim virom prisluškovanje

komunikaciji.

3.3 Razvoj in uporaba protokola

a) Verzija 1

Verzija SNMPv1 je prvotna implementacija protokola SNMP. Verzija SNMPv1 deluje na

osnovi protokolov, kot so UDP, IP, CLNS (Connectionless Network Service), DDP

(Datagram-Delivery Protocol) in IPX (Internetwork Packet Exchange). Zaradi svoje

13

uporabnosti je verzija SNMPv1 kmalu postala zelo priljubljena, hkrati pa je pridobila

status de facto standarda za mreţni nadzor naprav v internetni skupnosti.

Prve zahteve RFC za protokol SNMP, sedaj poznan kot verzija SNMPv1, so se

pojavili leta 1988, in sicer:

RFC 1065 – struktura in identifikacija nadzorovanih informacij za TCP/IP.

RFC 1066 – baze MIB za mreţni nadzor v TCP/IP omreţjih.

RFC 1067 – preprost mreţni nadzorni protokol.

Zgoraj navedeni protokoli so zastareli in so jih kasneje zamenjali naslednji:

RFC 1155 – struktura in identifikacija nadzorovanih informacij za omreţje TCP/IP.

RFC 1156 – baze MIB za mreţni nadzor v omreţjih TCP/IP.

RFC 1157 – preprost mreţni nadzorni protokol.

Po določenem času je zahtevo RFC 1156 zamenjala zahteva RFC 1213, ki vsebuje verzijo

2 za baze MIB (tj. MIB-2) za mreţni nadzor omreţij TCP/IP.

Verzija 1 protokola SNMP je bila pogosto tarča kritik in to predvsem zaradi slabe

varnosti pri komunikaciji. Overitev agentov je bila izvedena z nizom znakov, ki je imel

vlogo gesla, le-ta pa se je po omreţju prenašal kot navadno oz. golo besedilo.

b) Verzija 2

Verzija SNMPv2, definirana z zahtevami od RFC 1441 do RFC 1452, je nadgradnja

verzije 1 in vsebuje izboljšave pri zmogljivosti, varnosti, tajnosti in medupraviteljski

komunikaciji. Vpeljuje operacijo GETBULK, kot alternativo iterativni operaciji

GETNEXT, in sicer za pridobivanje večjih količin nadzorovanih podatkov z eno zahtevo.

Mnogim uporabnikom se je zdel nov varnostni mehanizem v verziji SNMPv2 preveč

kompleksen, zaradi česar ta različica ni bila širše sprejeta v javnosti.

Verzija SNMPv2c je definirana v zahtevah RFC 1901 do RFC 1908. V začetku je

bila neformalno znana tudi kot verzija SNMPv1.5. Verzija SNMPv2c je dejansko verzija

SNMPv2 brez kompleksnega varnostnega mehanizma. Ta različica uporablja enako

varnostno shemo kot verzija SNMPv1. Čeprav uradno ta različ ica ni pravi standard, se je v

širši javnosti veliko uporabljala in je bila obravnavana kot de facto standard.

14

Verzija SNMPv2u je definirana v zahtevah RFC 1909 in RFC 1910. Gre za

kompromis, ki nudi večjo varnost kot verzija SNMPv1, vendar pa brez kompleksnega

varnostnega mehanizma, kot je v osnovni verziji SNMPv2. Podrazličica te verzije se je

prodajala pod oznako SNMPv2*. Določeni deli tega mehanizma so bili pozneje

uporabljeni v verziji SNMPv3.

Kompatibilnost verzij SNMPv1 in SNMPv2c

Verzija SNMPv2c ni kompatibilna z verzijo SNMPv1 v dveh ključnih področjih: 1)

formatu sporočila in 2) operacijah protokola. Sporočila v verziji SNMPv2c uporabljajo

drugačno glavo paketa in format PDU kot verzija SNMPv1. Verzija SNMPv2c prav tako

uporablja dve operaciji, ki jih verzija SNMPv1 ne pozna. Obstaja pa zahteva RFC 1908, ki

definira dve moţnosti soobstajanja teh dveh protokolov, in sicer namestniške agente in

dvojezične mreţno-nadzorne sisteme (bi-lingual network management systems).

Namestniški agent prejme sporočila, jim ustrezno spremeni protokol, ter posreduje

na cilj. Dvojezični mreţno-nadzorni sistem pa vsebuje podporo za obe verzije protokola.

Ob prejemu sporočila preveri, na osnovi katere verzije protokola je zgrajen prejeti paket, z

agentom pa nato komunicira po ustrezni verziji protokola.

c) Verzija 3

Verzija SNMPv3 je definirana z zahtevami od RFC 3411 do RFC 3418. To verzijo

obravnava organizacija IETF od leta 2004 kot trenutno standardno verzijo protokola

SNMP. Prejšnje verzije so označene kot zastarele. Pri implementaciji protokola SNMP pa

so v praksi ponavadi podprte kar vse tri verzije, in sicer verzija SNMPv1, SNMPv2c in

SNMPv3.

Verzija SNMPv3 vsebuje tri nove pomembne varnostne mehanizme:

1. Overitev – primer overitve je vpis uporabniškega imena in gesla, ki se morata

ujemati na obeh straneh povezave.

2. Zasebnost – onemogoča prisluškovanje paketom na poti od pošiljatelja do

naslovnika.

15

3. Kontrola dostopa – različnim uporabnikom lahko določimo dostop do različnih

podatkov z različnimi pravicami.

16

4 UPORABA PROTOKOLA SNMP V REALNEM OKOLJU

V tem poglavju bomo v celoti predstavili, kako je moţno uporabiti protokol SNMP za

nadzor omreţnih sistemov. Opisali bomo vse gradnike, ki sodelujejo v tej komunikaciji, in

sicer od naprave, ki jo ţelimo nadzorovati, do naprave, s katero bomo opravljali nadzor. V

ta sistem bomo v nadaljevanju umestili naš programski produkt in ga ustrezno povezali z

napravami.

4.1 Potreba po namestniku

Potreba po namestnikih se je začela pojavljati ţe pred leti, ko je bil javnosti predstavljen

protokol SNMPv2. Ker ni bilo velikih razlik med protokolom SNMPv1 in SNMPv2 se je v

industriji še vedno uporabljal kar protokol SNMPv1. Z leti se je uporaba interneta zelo

razširila, ob tem pa je bil predstavljen tudi protokol SNMPv3. Uporabniki protokola SNMP

so se začeli zavedati nevarnosti interneta, kar je imelo posledico, da se je nova različica

protokola začela vse bolj uveljavljati.

Takojšen prehod delovanja naprav na protokol SNMPv3 seveda ni moţen, zato se

je ta sprememba dogajala postopoma. Na trgu najdemo vedno več naprav, ki podpirajo

protokol SNMPv3, kljub temu pa obstaja še mnoţica naprav, ki podpirajo samo starejši

verziji protokola. Zaradi vedno bolj razširjenega spletnega kriminala je varnost na spletu

ena izmed temeljnih strategij podjetij. Zaţelen je seveda varen prenos podatkov od

pošiljatelja do naslovnika, zaradi česar se podjetja posluţujejo najrazličnejših metod, da bi

zagotovila varnost. Ena izmed moţnih je uporaba namestnika, ki prestreza sporočila

preden pridejo v javno omreţje in jim, v primeru, da niso zgrajena v protokolu SNMPv3,

ustrezno spremeni obliko paketa in protokol, ter šele tako spremenjeno sporočilo pošlje

naslovniku.

Namestnika lahko uporabimo na več načinov. Če naprava (npr. računalnik)

omogoča dodajanje novih aplikacij, ga lahko namestimo na agenta oz. managerja, ali pa

ga, v primeru, da naprava ne podpira dodajanja novih aplikacij, namestimo kar na svoj

računalnik in le-tega poveţemo z agentom oz. managerjem.

17

4.2 Opis sistema

Naš sistem vsebuje napravo, ki jo ţelimo nadzorovati (agent) in napravo, s katero bomo to

drugo napravo nadzorovali (manager). Agenti so lahko različne naprave, in sicer od raznih

robotov v proizvodnji, tiskalnikov, usmerjevalnikov, gospodinjskih naprav ipd. Manager

pa je v večini primerov osebni računalnik ali naprava s primernim uporabniškim

vmesnikom, kjer lahko uporabnik prebira in zahteva ţelene podatke. Za laţje razumevanje

bomo v nadaljevanju predstavili primer scenarija delovanja takšnega sistema.

4.3 Primer scenarija delovanja sistema

Recimo, da je na strani agenta bančni avtomat, na strani managerja pa računalnik v banki.

Podatki, ki se prenašajo po omreţju, so seveda zato lahko izredno občutljive narave. To je

razlog, da je potrebno zagotoviti veliko varnost med prenosom podatkov in njihovo

kriptiranje. Predpostavimo, da bančni avtomat in računalnik v banki ne podpirata protokola

SNMPv3, podpirata pa protokol SNMPv1 in SNMPv2c. Zaradi tega bi se preko omreţja

seveda prenašali nezavarovani podatki. Problem bi lahko rešili tako, da bi na računalniku v

banki namestili programsko opremo, ki bi podpirala protokol SNMPv3. Bančnemu

avtomatu pa seveda ne moremo kar tako zamenjati programske opreme, nakup novega pa

bi bil predrag.

Da bi rešili takšen problem, moramo namestiti naš programski produkt (tj.

namestnik) na svoj računalnik in ga fizično postaviti k bančnemu avtomatu. Bančni

avtomat poveţemo z računalnikom, ki ima nameščen namestnik, računalnik pa priklopimo

na zunanje omreţje. Bančni avtomat bo od sedaj naprej pošiljal sporočila našemu

namestniku, ta pa jih bo prevedel v protokol SNMPv3 in posla l v banko na nadzorni

računalnik. S tem doseţemo, da se po omreţju pošiljajo kriptirana sporočila. Med bančnim

avtomatom in namestnikom so sporočila nezavarovana, kar pa ne predstavlja posebnega

problema, saj sta obe napravi praktično na isti fizični lokaciji in zato nihče ne more

prestreči sporočil. Seveda moramo ustrezno prilagoditi (configure) bančni avtomat,

namestnika in nadzorni računalnik v banki. Na drugi strani pa bo namestnik prestrezal vsa

sporočila od nadzornika namenjena agentu. Sporočila bo pretvoril v ustrezno verzijo

18

protokola SNMP in jih nato poslal na bančni avtomat. Potrebne spremembe konfiguracije

bomo podrobneje predstavili v nadaljevanju. Slika 4 predstavlja primer našega sistema.

4.4 Spremembe konfiguracije

Potrebne spremembe v konfiguraciji naprav v našem sistemu bomo razloţili na primeru

scenarija delovanja sistema opisanega v prejšnjem podpoglavju. Bančni avtomat moramo

na novo konfigurirati tako, da bo pošiljal vsa sporočila na namestnika. Spremeniti mu

moramo izhodni in vhodni naslov IP, vrata in varnostne parametre. Na drugi strani pa

moramo računalniku v banki prav tako ustrezno določiti vhodni in izhodni naslov IP, vrata

in varnostne parametre. Namestniku pa moramo povedati tudi iz katerega naslova IP in na

katerih vratih naj pričakuje pakete od bančnega avtomata in varnostne parametre prejetih

paketov. Določiti moramo tudi na kateri naslov IP, vrata in s kakšnimi varnostnimi

parametri naj posreduje te pakete.

Konfigurirati pa moramo tudi v obratni smeri, in sicer iz katerega naslova IP, na

katera vrata in s kakšnimi varnostnimi parametri naj prejme zahteve od računalnika v banki

in na kateri naslov, vrata in s kakšnimi varnostnimi parametri naj posreduje sporočila na

bančni avtomat. V praksi je lahko namestnik vmesnik med več kot dvema sistemoma, zato

moramo uvesti primerno preslikavo med managerji in agenti. Probleme pri preslikavi si

bomo pogledali v naslednjem podpoglavju.

Slika 4: Umestitev namestnika v sistem.

19

4.5 Problem preslikave zahtev

Namestnik mora za vsako prejeto sporočilo vedeti, kam ga naj posreduje. Za vsako

sporočilo, poslano od managerja, mora torej vedeti, kateremu agentu je namenjeno in

obratno. Prvi problem lahko rešimo na več načinov.

Prvi moţni način je, da pošiljamo sporočila z agenta namestniku na različna vrata.

V namestniku pa moramo imeti ustrezno konfigurirano preslikavo iz vrat na managerjev

naslov IP. Namestnik mora hkrati poslušati za sporočila na več različnih vratih.

Druga moţnost je, da pošiljamo sporočila z različnimi parametri protokola

SNMPv1 oz. SNMPv2c. V praksi to pomeni, da jim določimo različne SNMP skupine

(SNMP community). En agent oz. naprava SNMP lahko namreč pripada več SNMP

skupinam. Prednost tega je, da namestnik ne potrebuje poslušati na toliko različnih vratih,

ampak zgolj na enih. V tem primeru pa potrebujemo preslikavo iz skupine dostopa

(community) v naslov IP ciljnega računalnika.

Pri implementaciji našega sistema smo se odločili za prvo moţnost, tj. preslikavo

preko različnih vrat. Imamo več moţnosti imp lementacije. Prednosti in slabosti

posameznega pristopa pa si bomo ogledali v naslednjem podpoglavju.

4.5.1 Moţne implementacije preslikav

Prvi moţen način implementacije je, da programer ţe v fazi razvoja predvidi vse moţne

preslikave. Ta način ima prednost v tem, ker lahko vse te preslikave ţe vnaprej ustrezno

preizkusi, hkrati pa ne obstaja moţnost, da bi končen uporabnik kakorkoli vplival na

delovanje oz. zanesljivost delovanja naprav. Rešitev ima pa tudi slabosti. Ena izmed

največjih slabosti je, da je onemogočeno dodajanje novih preslikav. Ob dodajanju novih

preslikav bi jih moral programer vnesti direktno v programsko kodo in ponovno narediti

izvedljivi programski modul. Enako bi morali postopati, če bi ţeleli kakšno preslikavo

odstraniti ali spremeniti. Takšna programska oprema je seveda specifična in je izredno

prilagojena na enega naročnika. Pri vsakem novem naročniku bi imel razvijalec programov

dodatno delo, kar pa seveda ni v interesu podjetja, razvijalca oz. programerja, niti

naročnika. Slednji bi moral čakati na svoj programski produkt, da programer v njem

ustrezno spremeni kodo ter ga preizkusi.

20

Druga, bolj praktična rešitev je z uporabo konfiguracijskih datotek. V tej

implementaciji uporabnik vnese v konfiguracijsko datoteko vse preslikave, ki jih potrebuje.

Če se pojavi potreba po novi preslikavi, potem uporabnik enostavno spremeni

konfiguracijsko datoteko, novo preslikavo pa lahko takoj za tem ţe uporablja. Ta pristop je

seveda veliko bolj uporaben, sam program pa je ob tem tudi veliko bolj prenosljiv. Takšen

programski produkt lahko v nespremenjeni obliki prodamo večkrat, kupec pa dobi program

takoj, ko ga potrebuje. Ima pa tudi ta rešitev svojo slabost. Programski produkt namreč

pričakuje pravilno zapisano konfiguracijsko datoteko. Vsaka napaka v tej datoteki lahko

povzroči nepravilno delovanje ali celo izpad s istema. Uporabnik zato potrebuje veliko

znanja, da lahko pravilno oblikuje ter ureja konfiguracijsko datoteko. Ob tem pa je treba

upoštevati še človeški faktor. Ljudje smo seveda zmotljivi, zato se lahko zelo hitro dogodi,

da, na primer, pri dodajanju nove preslikave kopiramo staro preslikavo, pri tem pa

pozabimo spremeniti določen nabor parametrov. S tem vnesemo napačne podatke, kar pa

pogosto privede do izpada sistema. Da bi se temu problemu izognili, smo v naši rešitvi

napisali program za urejanje konfiguracijskih datotek, ki smo ga poimenovali kar

konfigurator.

Konfigurator

Ideja konfiguratorja je, da uporabniku poenostavi delo s konfiguracijsko datoteko, hkrati

pa zmanjša ali celo popolnoma odstrani moţnost napak. Uporabniku pri dostopu do

konfiguracijskih datotek s pomočjo konfiguratorja sedaj ni potrebno več poznati sintakse,

uporabljene v konfiguracijski datoteki. Ker pa ta datoteka še vedno fizično obstaja na

disku, kjer ima uporabnik sistemske pravice za dostop in njeno urejanje, moramo

uporabniku dati jasna navodila, kako naj z njo ravna. V praksi to pomeni, da moramo v

kazalo, kjer se nahaja konfiguracijska datoteka dodati še posebno datoteko z navodili (npr.

PreberiMe.txt). Lahko pa na začetek konfiguracijske datoteke dodamo tudi komentar, kjer

skušamo uporabniku razumljivo in na prijazen način svetovati, da te datoteke ne sme ročno

spreminjati, ampak samo s pomočjo konfiguratorja.

21

4.6 Problem preslikave odgovorov

Ta problem je enostavnejši od problema preslikave zahtev. Kadar agent pošlje zahtevo

namestniku, si le-ta zapomni podrobnosti zahteve ter iz katerega agenta je bila poslana. Ko

pa namestnik prejme odgovor od managerja, potem namestnik zgolj poišče v svojih

internih podatkovnih strukturah, kateri agent je zahteval ta podatek ter ga ustreznemu

agentu tudi posreduje.

Za implementacijo takšne rešitve je potrebno natančno poznavanje zgradbe paketov

protokola SNMP. Vsak paket vsebuje podatek o operaciji, številko vrat, varnostne

parametre in mnoţico drugih parametrov, med katerimi je tudi številka zahteve. Med

komunikacijo agent določi unikatno številko zahteve, manager pa mora vrniti odgovor s to

isto številko. Ker pa v tej komunikaciji sodeluje še namestnik, se lahko zgodi, da bi

namestnik iz dveh ali več različnih agentov dobil zahteve z isto zaporedno številko za

istega managerja. Odziv managerja je v takšnem izjemnem primeru neznan in je odvisen

od konkretne implementacije.

Moţna implementacija je naslednja. Namestnik vsakemu paketu preden ga pošlje k

managerju določi novo zaporedno številko. Ko pa namestnik prejme odgovor, mora

ustreznemu agentu odgovoriti z zaporedno številko, ki jo je le-ta v osnovi določil. Da

doseţemo takšno delovanje, si moramo ob prejemu zahteve zapomniti podatke o agentu,

zaporedno številko prejetega paketa in zaporedno številko poslanega paketa. Ko dobimo

odgovor od managerja, pa zgolj poiščemo v tabeli, kateremu agentu je odgovor namenjen.

Odgovoru nato spremenimo zaporedno številko in ga posredujemo agentu. Zapis iz tabele

izbrišemo po posredovanju odgovora.

22

5 NAMESTNIK SNMP PROXY AGENT

V tem poglavju bomo najprej pogledali, zakaj je namestnik sploh potreben, kakšne teţave

lahko pričakujemo pri implementaciji, opisali pa bomo tudi teţave, na katere smo dejansko

naleteli med implementacijo. Poglavje bomo zaključili s predstavitvijo moţnih rešitev in

kakšen pristop smo ubrali pri naši rešitvi.

5.1 Načrt in razvoj programskega produkta

Implementacije našega namestnika smo se lotili postopoma, in sicer tako, da smo v vsakem

koraku dodajali nove funkcionalnosti oz. razširjali obstoječe. Razvoj programa smo v

grobem razdelili na 7 korakov oz. faz razvoja. Za vsako fazo smo zapisali pričakovano

funkcionalnost našega programskega produkta. Z naslednjim korakom smo nadaljevali šele

takrat, ko je bil predhodni korak temeljito pre izkušen in potrjen. Na koncu bomo razvili še

pomoţni program, katerega naloga bo urejanje konfiguracijske datoteke in zagotavljanje

njene pravilnosti za pravilno delovanje namestnika.

5.1.1 Korak 1 – osnovno sprejemanje in posredovanje sporočil

Najprej smo naredili osnovni sprejem sporočil protokola SNMP verzije 1 in 2c, nato pa

smo implementirali preslikavo med verzijama 1 in 2c, ter pošiljanje na ciljni računalnik.

Sprejemanja sporočil v tem koraku nismo omejevali, pošiljali pa smo na vnaprej določen

naslov, kjer smo lahko preverjali ustreznost poslanega paketa. Zatem smo dodali še

funkcionalnost sprejemanja povratnih sporočil (SNMP Response), njihovo preoblikovanje

v ţeleno verzijo protokola ter posredovanje odgovora agentu. Na koncu tega koraka pa

smo dodali podporo še ostalim tipom sporočil, k i so opisani v podpoglavju 3.2, razen tipov

SNMP TRAP in NOTIFICATION.

23

5.1.2 Korak 2 – uvedba protokola SNMPv3

V drugem koraku smo dodali podporo verziji 3 protokola SNMP. Najprej smo izvedli

implementacijo tega protokola brez overjanja in brez zasebnosti. Šele po pravilnem

delovanju osnovne različice verzije 3, smo postopoma dodajali overitev in zasebnost. Po

tem koraku pričakujemo sposobnost sprejemanja vseh paketov verzije 1 in 2c, ter

posredovanje sporočil v poljubni verziji protokola. Prejeti odgovor se mora pravilno

obdelati in odgovor vrniti agentu.

5.1.3 Korak 3 – omogočanje večjega števila preslikav

Do tega koraka smo imeli preslikavo samo med enim managerjem in agentom. Sedaj

ţelimo uvesti večje število preslikav, k i smo jih na začetku zapisali kar v sam program.

Vsaka preslikava se je zaradi večje hitrosti delovanja izvajala v svoji niti. S tem smo

naredili naš program večnitni (multi-threaded). Za nas je to pomenilo, da je bilo vsako

nepravilnost teţje odkriti ter smo zato morali biti pri programiranju še posebej previdni.

Pravilnost delovanja smo temeljito preizkusili z vsemi kombinacijami preslikav in vsemi

moţnimi tipi sporočil.

5.1.4 Korak 4 – zapis podatkov v konfiguracijsko datoteko

V prejšnjem koraku smo preslikave napisali kar v sam program, kar pa je za končni

produkt nesprejemljivo. V nadaljevanju smo zato realizirali branje preslikav iz datoteke

shranjene na disku. To branje se mora izvesti ob zagonu programa. Zaradi nedvoumnosti

zapisa smo definirali pravila za zapis preslikav. Najbolj preprost način je prikazan na sliki

5.

24

Slika 5: Primer zapisa preslikave brez profilov.

Na tem primeru vidimo, da poslušamo sporočila tipa QUERY (GET, GETNEXT,

GETBULK, WALK in SET) na vratih 6160. Sporočilo mora biti verzije 1 (SNMPv1) z

nastavljeno skupino dostopa "public" oz. "private", če je sporočilo tipa SNMP SET.

Sporočilo pretvorimo v verzijo 3 (SNMPv3) z overitvenim geslom "AuthPassword",

zasebnim geslom "PrivPassword" in uporabniškim imenom "SHA_DES_User", ter ga

pošljemo na naslov 193.77.187.11 na vrata 161 (ki so privzeta za vsa sporočila SNMP tipa

QUERY).

Predstavimo, da imamo n naprav, ki na identičen način sprejemajo ali pošiljajo

sporočila. Potemtakem bi imeli n zapisov po 17 vrstic, kar pa pri velikem n lahko zasede

ogromno prostora, hkrati pa branje takšne datoteke lahko preseţe pričakovan odzivni čas.

Zato smo se odločili, da uvedemo profile, ki nedvoumno določajo tip sporočila z vsemi

potrebnimi parametri. Če bi imele vse naprave različne nastavitve, potem s takšnim

pristopom nismo naredili nobenega napredka. V praksi pa se pogosto dogaja, da ima več

naprav iste nastavitve, hkrati pa sprejemajo sporočila istega tipa z enakimi varnostnimi

parametri. Zaradi tega smo zapis v konfiguracijski datoteki spremenili v zapis, ki je

prikazan na sliki 6.

25

Slika 6: Primer zapisa preslikave s profili.

Vidimo lahko, da smo vse zapise, ki se navezujejo na tip sporočila zamenjali z dvema

profiloma. Oba profila smo v nadaljevanju konfiguracijske datoteke tudi definirali (glej

sliko 7).

Slika 7: Dva zgleda za zapis profila: levo profil za verzijo SNMPv1, desno profil za verzijo

SNMPv3.

Pri konfiguraciji neke druge (nove) naprave lahko uporabimo obstoječe profile, s čimer

prihranimo nekaj diskovnega prostora, pohitrimo pa tudi sam zagon programa. Pri

sklicevanju na profil uporabimo ime profila, ki je zapisano pod ključem

PROFILE_NAME. Če ţelimo, na primer, definirati novo preslikavo med agentom in

managerjem, kjer oba uporabljata protokol SNMPv1 s standardnimi varnostnimi parametri,

kjer je skupina dostopa za branje "public" in skupina dostopa za pisanje "private", lahko to

na kratko zapišemo kot je prikazano na sliki 8.

Slika 8: Zapis nove preslikave z vnaprej definiranimi profili.

26

Profila "V1_Public" nam tako ni potrebno še enkrat definirati, saj smo ga ţe definirali pri

preslikavi "proxy1" (glej sliko 7).

Ljudje smo zmotljivi, zato bi se pri ročnem vnašanju podatkov v takšno strukturo

hitro zmotili ali pa bi postala datoteka preveč obseţna, da bi uspeli slediti vsem oznakam in

številkam. Zato smo razvili še kratek program z ustreznim uporabniškim vmesnikom, s

katerim uporabniku poenostavimo delo pri konfiguriranju.

Naš program z razširjeno funkcionalnostjo smo nato temeljito preizkusili, hkrati pa

smo izvedli še prvi obremenitveni test, kjer smo program pustili delovati najmanj 24 ur, da

bi se pokazale morebitne pomanjkljivosti pri daljšem delovanju, kot so konstantno

povečanje porabe pomnilnika (memory leak) ali procesorskega časa.

5.1.5 Korak 5 – podpora sporočilom SNMP TRAP in INFORM

V petem koraku smo dodali funkcionalnost obdelave sporočil tipa SNMP TRAP in

INFORM. Pri teh sporočilih je posebnost, da jih pošilja agent in ne manager, zato moramo

omogočiti tudi preslikovanje v obratni smeri. Tudi te preslikave moramo definirati v

konfiguracijski datoteki. Primer takšne definicije je prikazan na sliki 9.

Slika 9: Definicija preslikave za sporočila tipa SNMP TRAP in INFORM.

Vidimo, da je zapis preslikave zelo podoben ţe omenjenim zapisom (glej sliki 6 in 8), od

njih se loči le po ključu "TYPE". Za ta ključ imamo v splošnem dve moţnosti, in sicer

"Query" ali "Notification".

27

5.1.6 Korak 6 – prenos na operacijski sistem Unix

Ena izmed glavnih zahtev delovanja našega programa je bila, da bi deloval tudi v drugih

operacijskih sistemih (predvsem v OS Unix). Zato smo med samo implementacijo morali

upoštevati razlike med sistemskimi klici v različnih operacijskih sistemih, in uporabljati

čim bolj splošne klice.

Izbrali smo OS Linux in distribucijo Red Hat 9.0. V tem koraku smo prenesli vso

izvorno kodo programa iz OS Windows na izbrani sistem. Ustrezno smo napisali datoteko

Makefile ter zatem prevedli izvorno kodo v izvedljivi modul. Cilj je seveda bil, da bi bila

izvorna koda enaka na obeh operacijskih sistemih.

Delujoči program smo temeljito preizkusili na obeh operacijskih sistemih. Prav

tako smo še izvedli obremenitveni test na OS Linux. Ko je bila poraba pomnilnika

enakomerna skozi celoten čas delovanja in ko tudi sicer nismo zasledili programskih

napak, smo sklepali, da je program uspešno napisan.

5.1.7 Korak 7 – program za urejanje konfiguracijske datoteke

Čisto na koncu pa smo razvili še kratek programski modul za urejanje konfiguracijskih

datotek. Zahtevana funkcionalnost je bila, da mora uporabniški vmesnik tega programa biti

napisan razumljivo in brez dvoumnosti, tako da bo njegova uporaba kar najbolj enostavna.

Vsebovati pa mora tudi zaščito proti brisanju profilov, in sicer tistih profilov, ki so trenutno

v uporabi pri kateri izmed preslikav. Zaţelena je moţnost preizkušanja določene

preslikave. Namestnik in program za konfiguriranje morata uporabljati isto izvorno kodo

za branje in pisanje v konfiguracijsko datoteko.

5.2 Implementacija

Naš programski produkt smo implementirali v programskem jeziku C++ v razvojnem

okolju Visual Studio 2005. Program je dejansko konzolna aplikacija. Med implementacijo

smo morali še paziti, da ga je bilo moţno prevesti tudi na OS Linux. Implementacije smo

se lotili na osnovi grobega in detajlnega načrta (grobi načrt je bil opisan v podpoglavju

28

5.1). Pri implementaciji smo si pomagali s programskimi razredi, ki so jih napisali v

podjetju MG-Soft. Ta programska koda je namreč dobro preizkušena, hkrati pa smo s tem

tudi poenostavili in pohitrili razvoj programa.

5.2.1 Korak 1 – osnovno sprejemanje in posredovanje sporočil

Za implementiranje sprejemanja sporočil smo uporabili obstoječi razred podjetja MG-Soft,

ki se uspešno uporablja v nekaterih drugih programskih produktih. S tem smo zagotovili

pravilnost delovanje, saj je ta razred ţe dodobra preizkušen.

Preslikave med verzijama 1 in 2c protokola SNMP smo se lotili postopoma. Najprej

smo prejeti paket razstavili na dele, v drugi funkciji pa smo sestavili nov paket. V prejetem

paketu nas zanimajo naslednji podatki: a) verzija protokola – uporabimo funkcijo

SnmpGetProtocolVersion(), b) tip sporočila (številska koda operacije SNMP) in c)

struktura VBL (variable binding list) – jo dobimo iz strukture PDU s klicem funkcije

SnmpGetPduData(). V drugi funkciji pa ustvarimo nov paket. Zanj ustvarimo lasten PDU s

funkcijo SnmpCreatePdu(), kjer kot argument podamo številsko kodo operacije SNMP ter

VBL (ki smo ju pridobili iz podatkov prejetega sporočila), identifikacijsko številko

izhodnega paketa in še nekaj manj pomembnih podatkov. Paket pošljemo s klicem funkcije

SnmpSendMsg(), kjer kot argumente podamo kazalec na strukturo PDU, varnostne

parametre in podatke o ciljnem računa lniku.

Na ciljnem računalniku preverimo ustreznost poslanega paketa in vrnemo odgovor,

tj. paket tipa SNMP RESPONSE. Odgovor se vrne na isti naslov od kjer je bila poslana

zahteva, v enaki verziji protokola in z enakimi varnostnimi parametri. V našem

programskem produktu sprejmemo odgovor na enak način kot zahteve, tj. z uporabo

obstoječega razreda. Tudi ta paket razdelimo na dele, ustvarimo nov paket, ki ga pošljemo

izvornemu računalniku. Pri kre iranju novega paketa moramo paziti, da so varnostni

parametri enaki tistim, s katerimi smo zahtevo prejeli, prav tako pa mora biti

identifikacijska številka paketa z odgovorom enaka identifikaciji, ki jo je nosil paket z

zahtevo. Zaradi tega moramo hraniti te podatke od trenutka prejetja zahteve pa vse do

trenutka, ko pošljemo odgovor.

29

S takšno implementacijo smo dejansko podprli še ostale tipe sporočil, saj smo

izhodnemu sporočilu vedno priredili isti tip, kot ga ima vhodno sporočilo. Sledil je

temeljit preizkus delovanja programa.

Med preizkusom smo opazili, da se poraba pomnilnika s časom izvajanja povečuje.

Ker si podatkov ne shranjujemo, bi morala biti poraba pomnilnika večino časa konstantna,

s kratkotrajnimi nihanji. Na osnovi posvetovanja smo ugotovili, da je za razliko od

navadnih podatkovnih tipov (npr. število in niz), treba vse uporabljene tipe v tej

komunikaciji na koncu vsake funkcije sprostiti, za kar obstajajo namenske funkcije.

Problem so predstavljali naslednji podatkovni tipi: HSNMP_VBL, HSNMP_CONTEXT,

HSNMP_PDU, HSNMP_ENTITY, smiOID, smiVALUE in smiOCTETS. Za sprostitev

prostora, ki ga zasedajo spremenljivke teh tipov, pa se uporabljajo naslednje namenske

funkcije, in sicer SnmpFreeDescriptor(), SnmpFreeVbl(), SnmpFreeEntity(),

SnmpFreeContext() in SnmpFreePdu().

Tako smo na koncu vsake funkcije poskrbeli za sproščanje uporabljenih

spremenljivk in poraba pomnilnika se je ustalila.

5.2.2 Korak 2 – uvedba protokola SNMPv3

V tem koraku smo omogočili, da se izhodna zahteva lahko preoblikuje v verzijo 3

protokola SNMP. To pomeni, da lahko namestniku pošljemo zahtevo v verziji 1 ali 2c, on

pa jo bo znal preoblikovati v verzijo 3. Koda za sprejemanje zahtev ostane enaka kot v

koraku 1, nadgraditi moramo le drugi del, tj. kreiranje izhodnega sporočila in prejem

odgovora.

Za nastavljanje varnostnih parametrov za verzijo 3 protokola SNMP smo napisali

novo funkcijo SetSecurityParams(). V verziji 3 imamo tri varnostne nivoje, zato moramo

najprej preveriti, kateri varnostni nivo potrebujemo. Varnostni nivoji so:

- SNMP_SEC_LEVEL_NOAUTH_NOPRIV – brez overitve in brez zasebnosti,

- SNMP_SEC_LEVEL_AUTH_NOPRIV – z overitvijo in brez zasebnosti,

- SNMP_SEC_LEVEL_AUTH_PRIV – z overitvijo in z zasebnostjo.

Varnostne parametre nastavljamo s klicem funkcije SnmpSetContextParameters(), ki ima

naslednje parametre:

30

- hContext: kontekstni objekt

- pContextName: ime kontekstnega objekta

- pContextEngineID: ID kontekstnega motorja

- pSecurityName: varnostno ime

- pSecurityEngineID: ID varnostnega motorja

- nSecurityModel: varnostni model

- nMinSecurityLevel: minimalen varnostni nivo

- nMaxSecurityLevel: maksimalen varnostni nivo

- nSecurityLevel: varnostni nivo

- nAuthProtocol: overitven protokol

- pAuthKey: overitven ključ

- nPrivProtocol: protokol zasebnosti

- pPrivKey: ključ zasebnosti.

Nastavljanje različnih varnostnih nivojev smo preprosto rešili s switch stavkom.

Psevdokod takšnega delovanja je prikazan na sliki 10.

Slika 10: Psevdokod preverjanja varnostnega nivoja za verzijo 3 protokola SNMP.

Verzija 3 protokola SNMP ima lastnost, da moramo nastaviti identifikacijske številko

ciljne naprave (t.i. engine ID), ki jo dobimo tako, da pošljemo agentu zahtevo. Le-ta

ugotovi, da številka ni pravilna, zato nam ne vrne odgovora (RESPONSE), ampak poročilo

(REPORT), kar je nova vrsta paketa, ki ga je uvedla verzija 3. V tem poročilu je zapisano

identifikacijsko število, ki si ga moramo zapomniti in uporabiti pri vsakem naslednjem

paketu. Ker to poročilo ni odgovor, k i bi ga ţelel manager, zato moramo zahtevo ponovno

poslati. Paket je popolnoma enak kot pri prvem pošiljanju, le da je spremenjena oz.

31

vnesena pravilna identifikacijska številka. Vendar tudi tokrat, agent še ne vrne odgovora,

ampak še eno poročilo. Gre za poročilo, s katerim usklajujemo uro, kar je še en varnostni

mehanizem verzije 3. Po obdelavi tega drugega poročila, pošljemo isto zahtevo še tretjič

(ura je sedaj sinhronizirana). Šele tokrat dobimo pričakovan odgovor, k i ga obdelamo in

vrnemo managerju.

Zgoraj opisani postopek je treba izvesti le ob prvem pošiljanju zahteve agentu.

Prejete podatke si moramo zato shraniti. Vsaki naslednji zahtevi pa te podatke takoj

priredimo. Na ta način nam agent ţe v prvem povratnem paketu vrne pričakovan odgovor.

5.2.3 Korak 3 – omogočanje večjega števila preslikav

V tem koraku smo izvajanje vsake preslikave implementirali v svoji niti. V primeru

manjšega števila preslikav se razlika v hitrosti izvajanja med klasično implementacijo

preslikav in implementacijo preslikav z nitenjem ne bi poznala prav veliko. Pričakuje pa

se, da bo število preslikav v posameznih primerih preseglo število 100. Zato je

implementacija z uvajanjem nitenja nujno potrebna. Pri implementaciji tega koraka smo si

prav tako pomagali z obstoječim in dobro preizkušenim razredom podjetja MG-Soft

(razred MgWThread).

Nadgrajeni programski sistem smo preizkusili z več različnimi preslikavami.

Preizkus smo izvedli s petimi nitmi, kjer smo uporabili različne kombinacije preslikav in

vse tipe sporočil.

5.2.4 Korak 4 – zapis podatkov v konfiguracijsko datoteko

V tem koraku smo naš program dopolnili tako, da ob zagonu prebere dovoljene preslikave

iz konfiguracijske datoteke. Zapis oz. obliko konfiguracijske datoteke smo definirali ţe v

podpoglavju 5.2.4, tukaj moramo le še implementirati branje iz te datoteke.

Podoben zapis, kot je v konfiguracijski datoteki, uporabljamo še na drugih mestih,

zato za implementacijo branja uporabimo kar obstoječi razred CDataFile podjetja MG-

Soft, ki ga malenkostno modificiramo. Razred je ţe v osnovi napisan tako, da deluje pod

32

OS Windows, Unix in Apple. Ta razred dejansko vrača posamezne sektorje iz datoteke,

zato moramo v našem programu zgolj še poskrbeti za pravilno interpretacijo teh zapisov.

Zapise iz datoteke dobimo s pomočjo funkcije GetSection(), kjer kot argument

podamo ime sekcije. V spodnjem primeru je ime sekcije "proxy1" (glej sliko 11). S

funkcijo GetKey() dobimo posamezen ključ. Tej funkciji kot argument podamo ime sekcije

(ali strukturo, ki jo vrne funkcija GetSection()) in ime ključa, ki nas zanima. Ključi so v

spodnjem primeru SEND_ADDRESS, RCV_PORT in SEND_PORT, če naštejemo le

nekatere. Funkcijo GetValue() pa uporabimo, če nas zanima vrednost posameznega ključa.

Kot argument podamo ime sekcije (ali strukturo, ki jo vrne funkcija GetSection()) in

ustrezno ime ključa. Po seznamu sekcij in ključih se lahko tudi pomikamo, in sicer s

funkcijami GetFirstSectionName(), GetNextSectionName(), GetFirstSection(),

GetNextSection(), GetFirstKey() in GetNextKey().

Slika 11: Primer zapisa preslikave v konfiguracijski datoteki.

Ob zagonu programa s pomočjo zgoraj opisanih funkcij preberemo podatke iz datoteke in

jih zapišemo v ustrezne spremenljivke. Pri tem smo predpostavili, da je konfiguracijska

datoteka zapisana brez napak. Ta predpostavka je razumna, saj bo uporabnik vnašal vse

preslikave s pomočjo namenskega programa (le-tega bomo predstavili v nadaljevanju).

Sledil je temeljit preizkus programa, kjer smo vključili tudi prvi obremenitveni test.

Program smo pustili neprekinjeno delovati 24 ur. Na ta način smo ţeleli odkriti morebitne

pomanjkljivosti, predvsem neprimerno povečanje porabe pomnilnika. Preizkus smo izvedli

tako, da smo najprej v konfiguracijsko datoteko vnesli nekaj pravilnih in nekaj namerno

nepravilnih preslikav. Nato smo vnesli še 10 pravilnih preslikav ter pustili program

delovati 24 ur. V tem času smo programu pošiljali v povprečju 3000 zahtev na sekundo.

33

Poraba pomnilnika se je v prvih minutah povečala za 20 %, nato pa v naslednjih 24 urah še

za dodatnih 10 %, kar je pri takšni obremenitvi popolnoma sprejemljivo.

5.2.5 Korak 5 – podpora sporočilom SNMP TRAP in INFORM

Do polne funkcionalnosti našega programa manjka le še podpora sporočilom SNMP TRAP

in INFORM. V tem koraku smo implementirali razred za sprejem in posredovanje teh dveh

tipov sporočil. Pošiljanje sporočil poteka le v eni smeri, saj odgovora ne pričakujemo. Tudi

pri pošiljanju teh sporočil potrebujemo preslikave. Zapis za preslikave smo definirali ţe v

podpoglavju 5.1.4. Razlika med prejšnjimi in tem zapisom je zgolj v ključu "TYPE", kjer

imamo dve moţnosti, in sicer "QUERY" (za vse ţe prej omenjene tipe sporočil) ali

"NOTIFICATION" (za sporočila tipa TRAP ali INFORM).

Funkcionalnost tega razreda je podobna delovanju razreda za obdelavo ostalih

sporočil protokola SNMP. Sporočilo torej sprejmemo, ga obdelamo in po potrebi zapišemo

v drugi verziji protokola. Nov sestavljen paket pa pošljemo ciljnemu računalniku.

Z dodajanjem te funkcionalnosti smo program dokončali. Program smo nato še

temeljito preizkusili.

5.2.6 Korak 6 – prenos na operacijski sistem Unix

Na zadnje pa smo naš program prenesli še na OS Linux. Najprej je bilo potrebno napisati

Makefile. To je dejansko skriptna oz. paketna datoteka, ki vsebuje zaporedje ukazov.

Datoteko Makefile aktiviramo z ukazom make v ukazni lupini.

V datoteki Makefile se uporabljajo spremenljivke, ki pa jih ni treba definirati. Le-te

se namreč definirajo avtomatsko ob prvi uporabi, na njih pa se sklicujemo po naslednji

sintaksi: znaku $ sledi v oklepajih zapisano ime spremenljivke (npr. "$(CC)").

Večino razlik med operacijskima sistemoma Windows in Linux smo identificirali

ţe med implementiranjem, zato se je izvorna koda z manjšimi popravki zelo hitro prevedla

v izvedljivi modul. Izvedljivi modul smo nato izčrpno preizkusili. Test je odkril določene

napake, ki smo jih uspešno popravili.

34

Sledil je obremenitveni test na OS Linux, kjer smo ugotovili, da poraba

pomnilniškega prostora bolj niha kot na OS Windows. Razlog za takšno obnašanje je

značilnost OS Linux, ki pomnilnika ne sprošča sproti, ampak v rednih časovnih intervalih.

Kodo na obeh operacijskih sistemih smo nato dokončno uskladili ter izvedli še hitri

preizkus delovanja. Med zadnjim preizkušanjem nismo odkrili napak.

5.2.7 Korak 7 – program za urejanje konfiguracijske datoteke

Uporabniku ţelimo čimbolj olajšati delo z namestnikom, zato smo razvili še poseben

program, ki je namenjen aţuriranju podatkov v konfiguracijski datoteki. Ta program smo

poimenovali Konfigurator.

Osnovni namen Konfiguratorja je, da uporabniku poenostavi delo s konfiguracijsko

datoteko. Tako več ni potrebno ročno vpisovanje v konfiguracijsko datoteko, hkrati pa ta

programski modul tudi zagotovi, da je konfiguracijska datoteka pravilno zapisana, s čimer

se izognemo morebitnim napakam pri branje datoteke oz. napačnemu interpretiranju

prejetih sporočil.

Program mora biti čimbolj preprost, zato smo zgradili preprost uporabniški

vmesnik, kjer so vsi izpisi berljivi in lahko razumljivi. Končni izgled uporabniškega

vmesnika z ţe prebranim primerom konfiguracijske datoteke je prikazan na sliki 12.

Slika 12: Uporabniški vmesnik Konfiguratorja.

35

Podatki so urejeni po vrstnem redu, in sicer so najprej podatki o sprejemu, nato o obdelavi,

na koncu pa o pošiljanju paketa. V prvi vrstici vidimo, da program posluša na vratih 6160

(glej sliko 12). Pričakujemo, da bodo sporočila, ki bodo prispela na ta vrata, imela

varnostne parametre definirane v profilu V1_Public. Prejeto sporočilo pretvorimo tako, da

ustreza varnostnim parametrom definiranim v profilu SHA_DES_User ter ga pošljemo na

vrata 161 računalnika z naslovom IP 193.77.187.70.

Na sliki 12 vidimo 2 zavihka. V prvem zavihku (Query) so prikazane preslikave za

vse tipe sporočil, razen za tipa TRAP in INFORM. V drugem zavihku (Notification) pa so

prikazane preslikave samo za sporočila tipa TRAP in INFORM. Uporabniški vmesnik je

tudi v tem zavihku popolnoma identičen zgoraj opisanem, razlika je le v prikazanih

podatkih.

Na dnu tega vmesnika najdemo standardne kontrolne gumbe, kot so Exit (zapre

okno, vse ne shranjene spremembe pa zavrţe), Apply (shrani spremembe ter ponovno

zaţene Konfigurator) in OK (shrani spremembe in zapre program). Na desni strani

uporabniškega vmesnika pa imamo gumbe za upravljanje s preslikavami. Funkcionalnosti

teh gumbov so enake ne glede na izbran zavihek. V nadaljevanju bomo na kratko

predstavili funkcionalnost teh kontrolnikov.

Gumb Add

Ob pritisku na gumb Add se odpre okno za vnos nove preslikave (glej sliko 13).

Slika 13: Okno za dodajanje novih preslikav.

36

V vnosno polje Recieve port vnesemo številko vrat, kjer bomo poslušali/tipali sporočila.

Pri drugem in tretjem kontrolniku imamo spustni meni, kjer iz menija izberemo ţeleni

profil za prejem in pošiljanje. V polje Send port vnesemo vrata ciljnega računalnika, v

kontrolnik Send Address pa naslov ciljnega računalnika. Če odgovora ne dobimo, pa

vnosno polje Timeout določa čas (v sekundah) po katerem sporočilo ponovno pošljemo.

Dovoljeno število teh poizkusov oz. ponovitev je določeno s kontrolnikom Retries. Ob

pritisku na gumb OK se vnesena preslikava shrani v notranjo podatkovno strukturo, ki jo

lahko zatem (od pritisku na gumb Apply ali OK glavnega okna) shranimo v konfiguracijsko

datoteko. Gumb Cancel ta dialog zapre, hkrati pa se vsi vnosi zavrţejo.

Gumb Edit

Če ţelimo aktivirati gumb Edit moramo najprej izbrati ţeleno preslikavo iz seznama

preslikav. Če povezave ne izberemo, se ob pritisku na ta gumb privzeto izbere kar prva

povezava v seznamu. Enak učinek doseţemo, če dvakrat kliknemo na ţeleno preslikavo v

seznamu. Dialog, ki se odpre (viden na sliki 14), ima enak nabor vnosnih polj kot vmesnik

na sliki 13, le da so vnosna polja ţe izpolnjena. Vrednosti polj lahko po potrebi

spremenimo in shranimo.

Slika 14: Prikaz okna za urejanje preslikave.

37

Gumb Delete

Ob pritisku na gumb Delete se odpre dialog, kjer potrdimo ali prekličemo brisanje izbrane

preslikave.

Gumb Test

Z akcijo Test lahko preizkusimo delovanje agenta izbrane preslikave z nastavitvami, ki so

določene v profilu Forward Profile. Z aktiviranjem tega gumba preverimo tudi, če je

naprava (agent) v omreţju dosegljiva. Ta operacija pošlje paket z identifikacijo OID=0,

operacijo GETNEXT in varnostnimi parametri definiranimi v izbranem izhodnem profilu

za tega agenta. Če dobimo odgovor, potem uporabniku javimo, da naprava deluje, v

nasprotnem primeru pa sporočimo napako, ki lahko pomeni, da je preslikava narobe

definirana oz. naprava ni dosegljiva.

Gumb Profiles

S pritiskom na gumb Profiles (glej sliko 12) se odpre dialog s seznamom vseh vnesenih

profilov. Iz slike 15 vidimo, da lahko profile dodajamo (Add), urejamo (Edit) ali brišemo

(Delete). Dialog se odpre kot aplikacijsko modalno okno, kar pomeni, da moramo

dokončati delo v tem dialogu preden se vrnemo v glavno okno Konfiguratorja. Gumbe na

dnu tega dialoga pa uporabljamo za zapiranje okna in shranjevanje sprememb (gumb OK),

zgolj za shranjevanje sprememb (gumb Apply) ali pa za zapiranje okna in zavračanje vseh

neshranjenih sprememb (gumb Exit).

38

Slika 15: Prikaz okna za delo s profili.

Za dodajanje novega profila aktiviramo gumb Add. Odpre se dialog, prikazan na sliki 16.

Vanj vpišemo zahtevane lastnosti profila. Tukaj določimo ime profila in verzijo protokola

SNMP. Glede na izbrano verzijo protokola SNMP se omogočijo oz. onemogočijo ostale

lastnosti profila. Pri verziji 1 ali 2c moramo samo vpisati niz znakov za skupino dostopa za

branje in pisanje (Read in Write Community). Če smo pa kot verzijo protokola izbrali

verzijo 3 pa moramo vpisati še preostale podatke, kot so uporabniško ime, vrsta overitve

(Authorisation), overitveno geslo, vrsto zasebnosti (Privacy) in geslo za zasebnost.

Slika 16: Dialog za dodajanje profilov.

39

Pri urejanju profila se odpre enak dialog, kot je prikazan na sliki 16, le da so vsa polja

ustrezno zapolnjena glede na izbran profil, ki ga urejamo.

Pri brisanju profila se odpre dialog, kjer potrdimo oz. prekličemo brisanje. Če se

profil uporablja v kateri izmed ţe vnesenih preslikav, se pri poskusu brisanja takšnega

profila odpre dialog z obvestilom, ki uporabnika opozori, da je profil v uporabi in ga ni

moţno izbrisati (glej sliko 17). Tedaj moramo bodisi izbrisati preslikavo, ki uporablja

izbrani profil ali pa preslikavi ustrezno spremeniti profil. Šele ko tega profila ne uporablja

nobena preslikava več, je izbris profila dovoljen.

Slika 17: Obvestilo o profilu, ki je v uporabi.

40

6 PREIZKUŠANJE NAMESTNIŠKEGA STREŢNIKA

V tem poglavju bomo opisali preizkus delovanja našega namestnika, ki smo ga preizkusili

po metodi bele in črne škatle. Razloţili bomo, kaj pomeni posamezna metoda preizkušanja

ter opisali njene prednosti ter slabosti. Na koncu poglavja pa bomo pregledali še moţnosti

uporabe namestnika SNMP pri oddaljenem diagnosticiranju.

6.1 Preizkušanje po metodi bele škatle

Preizkušanje po metodi bele škatle je preizkušanje, kjer imamo znan vhod, vemo kaj

ţelimo na izhodu, zanima pa nas, kako iz vhodnih podatkov, po korakih, dobimo izhodne.

S to metodo lahko pribliţno ocenimo tudi pokritost preizkušanja kode in nastavimo takšne

vhodne podatke, da je pokritost kar največja. To vrsto preizkušanja imenujemo tudi

strukturno preizkušanje.

To preizkušanje smo izvajali med programiranjem, kjer smo preizkušali posamezne

funkcije in razrede. Naš programski produkt smo razvili v okolju Microsoft Visual Studio

2005, ki ima vgrajen zelo pregleden očiščevalnik (debuger). To vrsto preizkušanja smo

izvajali ves čas programiranja in sproti izvajali potrebne popravke programske kode.

Druga metoda preizkušanja po metodi bele škatle je preizkušanje z izpisi. Kot smo

omenili v podpoglavju 5.1.3 imamo opravka z večnitnim programom, ki ga ne moremo v

celoti preizkusiti z očiščevalnikom. V posamezne dele programske kode – predvsem v tiste

dele, ki se izvajajo v več nitih – smo zato dodali različne izpise, s katerimi smo lahko po

koncu izvajanja iskali morebitne napake. V primeru, da se je pokazala nepravilnost, smo

najprej identificirali programsko kodo, kjer se je nahajal ustrezen izpis, zatem pa smo še

popravili ta del kode, ki je vsebovala programsko napako.

Moduli oz. posamezni deli našega programa so primerne velikosti, zato smo jih

lahko brez večjih teţav preizkusili po metodi bele škatle. Za preizkušanje delovanja

programa kot celote pa smo uporabili metodo črne škatle.

41

6.2 Preizkušanje po metodi črne škatle

Pri preizkušanju po metodi črne škatle poznamo vhod in vemo, kaj pričakujemo na izhodu,

vendar pa vpogleda v potek izvajanja nimamo oz. strukture programa ne poznamo. V tej

metodi zato zgolj primerjamo dobljene izhode s pričakovanimi.

To preizkušanje smo v našem produktu izvedli na ţe končanem programu (po fazi

integracije). Izvajali smo ga tako, da smo na ciljnem računalniku preverili podatke, ki smo

jih zahtevali, nato pa smo poslali zahtevo. Prejete podatke smo nato primerjali z

dejanskimi podatki, ki smo jih dobili neposredno iz ciljnega računalnika. Če so se podatki

ujemali, smo predpostavili, da naš namestnik deluje pravilno.

Preizkus smo ponovili večkrat, vendar vsakokrat z različnimi zahtevami. Na ta

način smo dosegli kar se da veliko pokritost preizkušanja kode. To metodo preizkušanja

smo uporabili tudi pri preizkušanju programa z obremenitvijo (glej podpoglavje 5.1.4).

6.3 Namestnik in oddaljeno diagnosticiranje

V nadaljevanju bomo opisali pojem oddaljeno diagnosticiranje, ob tem pa se bomo

dotaknili tudi moţnosti, kako lahko uporabimo namestniški streţnik pri oddaljenem

diagnosticiranju. Opise bomo podkrepili s praktičnimi primeri in moţnimi scenariji

uporabe.

6.3.1 Oddaljeno diagnosticiranje

Oddaljeno diagnosticiranje je diagnosticiranje strojne računalniške opreme, kjer nadzor oz.

preizkušanje naprave opravljamo oddaljeno preko določene komunikacijske povezave. V

praksi srečamo oddaljeno diagnosticiranje na različnih področjih, npr. v medicini, pri

nadzoru mnoţice računalniških sistemov povezanih v omreţje, pri spremljanju dirkalnih

avtomobilov, v vesoljskih plovilih, v letalih itd. Oddaljeno diagnosticiranje je po eni strani

priljubljeno in koristno. Razlogov je več. Prvi razlog je zagotovo niţji stroški nadzora. Pri

vesoljskih plovilih bi bilo nesmiselno voziti mnoţico ljudi, ki bi opravljala

42

diagnosticiranje. Drugi razlog pa je zagotovo večja varnost, saj lahko pri oddaljenem

nadzoru vesoljskih plovil le-to opravimo kar iz varnega in nadzorovanega prostora (npr.

pisarne). Nekaj podobnega je tudi pri nadzorovanju dirkalnih avtomobilov, kjer je

ključnega pomena vsak dodaten kilogram teţe avtomobila.

Oglejmo si primer uporabe oddaljene diagnostike pri spremljanju stanja dirkalnega

avtomobila med dirkanjem. Inţenirji, ki se običajno nahajajo v garaţi, imajo s pomočjo

računalnikov in oddaljene diagnostike moţnost spremljati vso dogajanje v dirkalnem

avtomobilu na stezi. Na vpogled imajo različne podatke, in sicer od osnovnih podatkov,

kot so npr. pritisk zraka v pnevmatikah, količina goriva v rezervoarju, izbrana prestava,

lokacija na stezi, hitrost, število vrtljajev motorja, pa vse do kompleksnih podatkov, kot je

npr. količina goriva vbrizgana v posamezen cilinder na takt motorja, porazdelitev zavorne

sile glede na pritisk v amortizerjih, pre-krmarjenje, pod-krmarjenje ipd. Inţenirji imajo

torej moţnost preučiti vse te podatke, hkrati pa lahko s pomočjo namenskih programov

identificirajo, katero nastavitev avtomobila je smiselno prilagoditi. Tako lahko med

obveznim postankom avtomobila zaradi menjave izrabljenih pnevmatik hitro spremenijo še

druge nastavitve avtomobila. Takšno posodabljanje praktično zahteva minimalno časa,

hkrati pa lahko dirkalnemu avtomobilu bistveno izboljša vozne lastnosti, kar se seveda

pozna na dirkalni stezi.

V opisanem zgledu je bila oddaljena diagnostika ob ţe zgoraj opisanih dveh

razlogih koristna še zaradi bistvenega zmanjšanja količine ročnih posegov serviserjev na

avtomobilu med dirko, saj se večina dela lahko opravi kar oddaljeno. S tem seveda lahko

zmanjšamo število serviserjev (lokalno osebje) na minimum, kar po eni strani pomeni niţje

stroške, po drugi strani pa tudi večjo varnost pri delu, saj te serviserje lahko zelo dobro

izurimo za majhno število ročnih posegov, ki jih bodo med d irko opravljali.

6.3.2 Uporaba namestniškega streţnika za oddaljeno diagnosticiranje

Iz opisanih prednosti oddaljenega diagnosticiranja opazimo, da je protokol SNMP zelo

primeren za takšno delo. Z njim je namreč omogočen vpogled v vsako, še tako majhno

podrobnost računalniškega sistema. Kot ţe vemo pa je protokol SNMP izredno hiter in

učinkovit, omogoča pa tudi spreminjanje nastavitev.

43

V zgledih, opisanih v podpoglavju 6.3.1, bi lahko zelo učinkovito uporabili tudi naš

namestniški streţnik za oddaljeno diagnosticiranje. Treba je vsekakor omeniti, da se danes

v praksi uporabljajo drugačne rešitve (namenska programska oprema in namenski

protokoli), vendar bi te probleme ekvivalentno rešili tudi s protokolom SNMP in našim

namestnikom. Naš namestnik deluje na operacijskem sistemu Linux, Windows in Mac OS.

Pri svojem delu zelo malo obremeni centralno procesorsko enoto, hkrati pa porabi tudi zelo

majhno količino delovnega pomnilnika. Za njegovo izvajanje ne potrebujemo posebej

zmogljivega računalniškega sistema. Takšni računalniki pa so danes lahko zelo majhnih

dimenzij in teţe.

V nadaljevanju bomo opisali nekaj scenarijev, kako bi naš namestnik uporabili v

zgledih, predstavljenih v podpoglavju 6.3.1. Predpostavimo še, da je na vseh sistemih

podprta verzija 1 in/ali 2c protokola SNMP. Naša zahteva pa je, da ţelimo varen prenos

podatkov na osnovi protokola SNMP.

V dirkalnem avtomobilu ni prostora za osebni računalnik. Zato bi morali uporabiti

manjši namenski računalniški sistem, na katerega bi namestili posebne specifične

uporabniške programe. Takšen sistem bi prenašal nezavarovane podatke do managerja. To

pa seveda ni sprejemljivo, saj bi lahko tudi druge ekipe spremljale, kaj se dogaja z

avtomobilom. S tem bi druge ekipe dobile moţnost, da bi na nepošten način prišle do

tajnih podatkov o dirkalnem avtomobilu, kar bi bilo moţno uporabiti pri posodabljanju

nastavitev svojih avtomobilov, lahko pa bi celo izvedli sabotaţo ter bi posegli v nastavitve

našega avtomobila. Spreminjanje funkcionalnosti (še bolj pa protokola prenosa podatkov)

takšne uporabniške aplikacije običajno predstavlja velik strošek, hkrati pa je tudi

preizkušanje takšne programske opreme v praksi lahko zelo nevarno. Dosti enostavneje je

zgolj spremeniti ciljni naslov IP, kamor naj računalniški sistem avtomobila pošilja podatke.

Ceneje in preprosteje bi bilo, da na ta računalniški sistem namestimo naš namestnik, v

obstoječi aplikaciji pa spremenimo ciljni naslov IP tako, da bo vsa sporočila pošiljal

našemu namestniku. Namestnik bi prejete podatke zakodiral (tj. jih pretvoril v verzijo 3) in

jih poslal na ciljni računalniški sistem (managerja), ki se običajno nahaja v boksu ob

dirkalni stezi. Ciljni računalniški sistem je ponavadi eden ali več osebnih računalnikov/

streţnikov, na katerega lahko prav tako brez problema namestimo naš namestnik. S tem bi

inţenirji lahko varno spremljali dogajanje in stanje v dirkalnem avtomobilu.

44

Podobno bi lahko postopali pri nadzorovanju vesoljskih plovil, letal ipd.

Uporabniška programska oprema, ki delujejo lokalno na teh plovilih je običajno zelo dobro

preizkušena. Vsako spreminjanje te programske opreme bi, preden bi jo dali v ponovno

produkcijsko delovanje, zahtevalo ogromno truda in preizkušanja. Ker je tudi v tem

primeru varnost ključnega pomena, bi lahko na popolnoma enak način integrirali

namestnik, s katerim pa bi zagotovili varnost prenesenih podatkov.

45

7 REZULTATI IN DISKUSIJA

Temeljni rezultat tega diplomskega dela je vsekakor nov namestnik SNMP. V okviru tega

poglavja bomo demonstrirali delovanje našega novega programskega produkta. Pravilnost

delovanja bomo izkazovali s pomočjo posnetkov zajetih zaslonskih mask. Poglavje bomo

sklenili s kratkim sklepom.

7.1 Primer delovanja

V tem primeru si bomo pogledali postopek, ki je potreben za preslikavo sporočil iz verzije

SNMPv1 protokola SNMP v verzijo SNMPv3, pri čemer uporabljamo overitev in

zasebnost. Opisali bomo celoten postopek, dobljen rezultat pa bomo preverili z rezultatom,

ki ga dobimo, če pošljemo isto zahtevo neposredno na ciljni računalnik, brez posredovanja

našega namestnika.

7.1.1 Vnos podatkov za preslikavo v Konfigurator

Najprej v programski modul Konfigurator vnesemo vse podrobnosti preslikave. Gre za

naslednje podatke, in sicer številka vhodnih vrat, zahtevani varnostni parametri vhodnega

sporočila (določeno s profilom), zahtevani varnostni parametri izhodnega sporočila

(profil), vrata ciljnega računalnika in naslov ciljnega računalnika. Rezultat vnosa teh

podatkov v Konfigurator je viden na sliki 18.

46

Slika 18: Prikaz preslikave v programskem modulu Konfigurator.

7.1.2 Zagon namestnika

Šele ko se podatki o preslikavi shranijo v konfiguracijsko datoteko lahko zaţenemo

namestnik. Za laţje razumevanje tega postopka oz. korakov, ki se izvršijo ob zagonu, smo

program zagnali v konzolnem načinu. Na sliki 19 lahko tako vidimo inicializacijske zapise.

Za nas pomembne vrstice smo označili s kvadratkom. Te vrstice bomo v nadaljevanju tudi

na kratko opisali.

Pri izpisu v prvi označeni vrstici se izvede branje podatkov iz konfiguracijske

datoteke, zatem pa sledi izpis najbolj ključnih podatkov za posamezno preslikavo. Na

osnovi tega izpisa lahko morebitno napako v konfiguracijski datoteki hitro izsledimo. V

našem primeru so prebrane vrednosti pravilne (glej tudi sliko 18).

Pri naslednjih treh označenih vrsticah se izvedejo inicializacijske metode, ki

pripravijo preslikavo za uporabo. Inicializacijske metode se izvedejo za vsako preslikavo,

ki se nahaja v konfiguracijski datoteki. Ob morebitnih napakah pri inicializaciji lahko prav

tako na osnovi teh izpisov hitro ugotovimo, kje je prišlo do problemov ter jih lahko

ustrezno popravimo.

47

Slika 19: Izpisi pri zagonu namestnika.

7.1.3 Aktiviranje delovanja namestnika

Pri preizkušanju pravilnosti delovanja namestnika smo si pomagali s programom MIB

Browser podjetja MG-Soft d.o.o. Ta program je ţe temeljito preizkušen, hkrati pa je zelo

primeren za preizkušanje našega namestnika. V dialog programa MIB Browser najprej

vnesemo naslov računalnika, kjer se nahaja naš namestnik (v našem primeru je to na

lokalnem računalniku, zato naslov 127.0.0.1), nato pa vnesemo še varnostne parametre, ki

smo jih določili s profilom V1_Public, in vhodna vrata namestnika (glej definiranje

profilov v podpoglavju 7.1.1). Vnos teh podatkov je prikazan na sliki 20.

48

Slika 20: Vnos podatkov namestnika v program MIB browser.

Sledi pošiljanje zahteve na ciljni računalnik. V tem zgledu smo v obliki zahteve ţeleli

dobiti podatek o imenu sistema, ki je shranjeno v spremenljivki sysName. V programu MIB

Browser na to spremenljivko preprosto kliknemo z desno miškino tipko ter izberemo

operacijo GET, kar je prikazano tudi na sliki 21.

49

Slika 21: Pošiljanje zahteve na naš namestnik s pomočjo programa MIB browser.

Na sliki 22 so prikazani podatki o poslanem paketu in prejetem odgovoru. Vidimo lahko,

da je bila poslana zahteva s protokolom SNMPv1 na naslov 127.0.0 in vrata 6160,

uporabljena operacija pa je bila GET, v seznamu VBL pa je bila zapisana zahteva

sysName.0.

V prejetem paketu pa lahko vidimo, da smo prejeli podatek, da je ime ciljne

naprave APOLLO-OUT, v oglatih oklepajih pa je zapisana še njena šestnajstiška vrednost.

50

Slika 22: Podrobnosti zahteve in prejetega odgovora.

7.1.4 Preverjanje pravilnosti delovanja namestnika

Pravilnost rezultatov, ki smo jih dobili z našim namestnikom, smo preverili tako, da smo v

program MIB Browser vnesli podatke ciljne naprave in poslali paket neposredno na ciljno

napravo, brez posredovanja našega namestnika. V našem zgledu smo za naslov ciljne

naprave vnesli 212.30.73.70 in varnostne parametre za verzijo SNMPv3. Vneseni podatki

so prikazani na sliki 23. Vsi varnostni parametri niso vidni, saj tudi program MIB Browser,

podobno kot naš namestnik in Konfigurator, uporablja profile.

Slika 23: Vnos podatkov ciljnega računalnika v program MIB browser.

51

Ko smo vnesli vse zahtevane podatke lahko pošljemo zahtevo na ciljni računalnik. Na

popolnoma enak način, kot v zgoraj opisanem zgledu, pošljemo zahtevo po podatku

sysName (glej sliko 24).

Slika 24: Pošiljanje zahteve na ciljni računalnik s pomočjo programa MIB Browser.

Po pričakovanjih dobimo tudi tokrat enak rezultat, čeprav oba izpisa nista popolnoma

enaka (glej sliki 22 in 25 – pomembna je zadnja vrstica obeh izpisov). Na sliki 25 vidimo

vse izpise, s katerimi nam postreţe program MIB Browser. Le-ta nam omogoča vpogled v

dogajanje med pošiljanjem paketov protokola SNMPv3. V zadnji vrstici izpisa pa vidimo

rezultat poizvedbe, to je ime ciljnega računalnika. To ime je seveda identično imenu, ki

smo ga prejeli s pomočjo našega namestnika, s čimer lahko potrdimo pravilnost delovanja

našega namestnika v tem zgledu.

52

Slika 25: Podrobnosti prejetega odgovora pri preverjanju pravilnosti delovanja našega

namestnika.

7.2 Sklep

Opisani zgled v podpoglavju 7.1 je le eden izmed mnoţice preizkusov našega namestnika,

ki smo jih opravili.

Programski produkt, ki je nastal v okviru tega diplomskega dela, bo z nekaj majhnimi

modifikacijami, trţilo podjetje MG-Soft d.o.o., in sicer pod blagovno znamko "MG-Soft

SNMP ProxyAgent". Ta produkt smo tudi razvili v okviru tega istega podjetja. Podjetje

MG-Soft d.o.o. sicer nima posebnega tesnega oddelka, zato smo morali opraviti tudi

celotno preizkušanje programa. Preizkušanje produkta je v zadnji fazi pred uradno izdajo.

Omenjeni programski produkt ţe uporabljajo nekateri končni uporabniki. Le-ti so pokazali

veliko mero zadovoljstva z delovanjem naše rešitve, hkrati pa smo od njih prejeli tudi

povratne informacije, kako bi ta program lahko še dodatno izboljšali oz. nadgradili. Vse

predloge smo preučili, najbolj smiselne pa bomo vključili v eno izmed prihodnjih verzij

produkta.

53

8 ZAKLJUČEK

V tem diplomskem delu smo podrobno spoznali protokol SNMP in njegove najbolj

uporabljene verzije. Ogledali smo si tudi uporabo tega protokola v realnem okolju.

Raziskali smo literaturo ter identificirali potencialne programske produkte, ki izkazujejo

podobno funkcionalnost, kot smo jo ţeleli za naš namestniški streţnik. Program, ki bi

izkazoval ţeleno funkcionalnost, nismo uspeli najti. To je bila za nas pri razvoju še

dodatna motivacija. Razvili in implementirali smo lasten programski produkt za delo s

protokolom SNMP. Gre za prvi produkt s tako obseţno funkcionalnostjo. Ta program zna

pretvarjati med sporočili napisanimi v različnih verzijah protokola SNMP, deluje pa

samostojno v vlogi namestniškega streţnika. Razviti program smo v podjetju MG-Soft

d.o.o. še dodatno nadgradili. Trenutno se naš nadgrajeni programski produkt nahaja v

zadnji fazi preizkušanja pred uradno izdajo.

Protokol SNMP je širši javnosti manj znan protokol. To seveda nikakor ne pomeni,

da je protokol slab. Da je ta protokol zelo dobro razvit in dodelan gre zahvala predvsem

večjim podjetjem, kot so Cisco, BAE Systems, Ericsson, HP, Motorola, Nokia, Siemens in

še mnogim drugim manjšim podjetjem.

Moţnosti nadgradnje našega produkta je še vedno veliko in verjamemo, da se bo

program v prihodnosti še nadgrajeval. Ena izmed moţnih nadgradenj je podpora vsem trem

verzijam protokola SNMP v obe smeri (tj. sprejem in pošiljanje sporočil). To bi vsekakor

naredilo naš program še robustnejši in bi hkrati odprlo še nova področja uporabe. Takšna

dodatna funkcionalnost bi zahtevala le nekaj manjših sprememb v izvorni kodi.

Naslednja moţna nadgradnja našega produkta pa sodi na področje preslikav. Pri

načrtovanju smo se odločali med dvema metodama za preslikovanje, ki smo ju opisali v

podpoglavju 4.4. V naši rešitvi smo se odločili za preslikavo gleda na vrata, na katera smo

prejeli paket. Od nekaterih naših potencialnih končnih uporabnikov smo prejeli povratno

informacijo, kjer so izrazili potrebo po implementaciji preslikav, glede na prejete varnostne

parametre paketa SNMP. Moţna nadgradnja našega produkta je torej tudi v tem, da v

prihodnosti podpremo obe vrsti preslikav.

54

LITERATURA

[1] Protokol SNMP, Wikipedia,

http://en.wikipedia.org/wiki/Simple_Network_Management_Protocol

[2] MG-Soft d.o.o., http://www.mg-soft.si/

[3] Programski produkt SNMP Proxy Forwarder, AdventNet Ltd.,

http://www.adventnet.com/products/snmputilities/index.html

[4] Programski produkt SNMP Forwarder Utility, Logisoft AR Ltd.,

http://www.logisoftar.com/ProductsSnmpForwarder.htm

[5] HP SNMP Proxy Agent, Hewlett-Packard,

http://www.hp.com/bizsupport/wja/live/manual/8.1/documents/readme_snmpproxy_

en.txt

[6] The Internet Engineering Task Force, http://www.ietf.org/rfc.html

[7] D. T. Perkins, E. McGinnis, Understanding SNMP MIBs, Prentice Hall PTR, Upper

Saddle River, New Jersey, 1996.

[8] D. Zazula, Preizkušanje računalniške opreme, Univerza v Mariboru, Fakulteta za

elektrotehniko, računalništvo in informatiko, Maribor, 2006.