7. Felsőbb rétegek, hálózati eszközök felügyelete 7.1. Felsőbb rétegek Az OSI felsőbb rétegei közül a viszony réteg és a megjelenési réteg nem



Hasonló dokumentumok
7. Felsőbb rétegek, hálózati eszközök felügyelete 7.1. Felsőbb rétegek alkalmazások szabványossága 7.2. SNMP - egyszerű hálózat felügyelő protokoll

IP alapú kommunikáció. 11. Előadás Hálózat Monitoring/Hálózat Manadgement Kovács Ákos

Hálózatok. Alapismeretek. A hálózatok célja, építőelemei, alapfogalmak

vezeték nélküli Turi János Mérnök tanácsadó Cisco Systems Magyarország Kft.

Cisco Catalyst 3500XL switch segédlet

Az alábbi állítások közül melyek a forgalomirányító feladatai és előnyei?

Beállítások 1. Töltse be a Planet_NET.pkt állományt a szimulációs programba! A teszthálózat már tartalmazza a vállalat

CISCO gyakorlati segédlet. Összeállította: Balogh Zoltán

Szilipet programok telepítése Hálózatos (kliens/szerver) telepítés Windows 7 operációs rendszer alatt

Számítógépes munkakörnyezet II. Szoftver

A számítógép-hálózat egy olyan speciális rendszer, amely a számítógépek egymás közötti kommunikációját biztosítja.

Információ és kommunikáció

Hálózati architektúrák és Protokollok GI 8. Kocsis Gergely

Flash és PHP kommunikáció. Web Konferencia 2007 Ferencz Tamás Jasmin Media Group Kft

A számítástechnika gyakorlata WIN 2000 I. Szerver, ügyfél Protokoll NT domain, Peer to Peer Internet o WWW oftp opop3, SMTP. Webmail (levelező)

Léteznek nagyon jó integrált szoftver termékek a feladatra. Ezek többnyire drágák, és az üzemeltetésük sem túl egyszerű.

Tartalom. Hálózati kapcsolatok felépítése és tesztelése. Rétegek használata az adatok továbbításának leírására. OSI modell. Az OSI modell rétegei

Építsünk IP telefont!

Hálózati rendszerek adminisztrációja JunOS OS alapokon

III. előadás. Kovács Róbert

Tájékoztató. Értékelés. 100% = 100 pont A VIZSGAFELADAT MEGOLDÁSÁRA JAVASOLT %-OS EREDMÉNY: EBBEN A VIZSGARÉSZBEN A VIZSGAFELADAT ARÁNYA 40%.

Hálózati alapismeretek

OpenBSD hálózat és NAT64. Répás Sándor

4. Hivatkozási modellek

Adatbázisok elleni fenyegetések rendszerezése. Fleiner Rita BMF/NIK Robothadviselés 2009

Útmutató az IP és Routing mérésekben használt Cisco routerek alapszint konfigurációjához i

Félreértések elkerülése érdekében kérdezze meg rendszergazdáját, üzemeltetőjét!

NETinv. Új generációs informatikai és kommunikációs megoldások

Kommunikációs rendszerek programozása. Switch-ek

Hálózati alapismeretek

Cisco Teszt. Question 2 Az alábbiak közül melyek vezeték nélküli hitelesítési módok? (3 helyes válasz)

OSI-ISO modell. Az OSI rétegek feladatai: Adatkapcsolati réteg (data link layer) Hálózati réteg (network layer)

Hálózati ismeretek. Az együttműködés szükségessége:

Hálózati architektúrák és Protokollok GI - 9. Kocsis Gergely

TRBOnet Térinformatikai terminál és diszpécseri konzol

Szalai Ferenc

Hálózati operációs rendszerek II.

Két típusú összeköttetés PVC Permanent Virtual Circuits Szolgáltató hozza létre Operátor manuálisan hozza létre a végpontok között (PVI,PCI)

Multiprotocol encapsulation (RFC1483) - IETF Classical IP over ATM (RFC1577) - IETF LAN Emulation (LANE) - ATM Forum Multiprotocol over ATM (MPOA) -

Számítógépes Hálózatok Felhasználói réteg DNS, , http, P2P

Felhasználói réteg. Számítógépes Hálózatok Domain Name System (DNS) DNS. Domain Name System

Tartalom. Router és routing. A 2. réteg és a 3. réteg működése. Forgalomirányító (router) A forgalomirányító összetevői

G Data MasterAdmin 9 0 _ 09 _ _ # r_ e p a P ch e T 1

Számítógép hálózatok gyakorlat

A MAC-cím (Media Access Control) egy hexadecimális számsorozat, amellyel még a gyártás során látják el a hálózati kártyákat. A hálózat többi eszköze

Hálózati beállítások Készítette: Jámbor Zoltán 2016

Utolsó módosítás:

1. Az internet használata

Statikus routing. Hoszt kommunikáció. Router működési vázlata. Hálózatok közötti kommunikáció. (A) Partnerek azonos hálózatban

Számítógépes hálózatok

1. Kapcsolók konfigurálása

IP alapú kommunikáció. 5. Előadás Routing 2 Kovács Ákos

WS 2013 elődöntő ICND 1+ teszt

VIII. Mérés SZÉCHENYI ISTVÁN EGYETEM GYŐR TÁVKÖZLÉSI TANSZÉK

Adatbiztonság PPZH május 20.

Hálózatos adatbázis-kapcsolódási problémák és azok javítása

Hálózati architektúrák és Protokollok GI 7. Kocsis Gergely

Intelligens biztonsági megoldások. Távfelügyelet

Városi tömegközlekedés és utastájékoztatás szoftver támogatása

3.5.2 Laborgyakorlat: IP címek és a hálózati kommunikáció

1/13. RL osztály Hálózati alapismeretek I. gyakorlat c. tantárgy Osztályozóvizsga tematika

Hálózati architektúrák és Protokollok PTI 5. Kocsis Gergely

Megoldás. Feladat 1. Statikus teszt Specifikáció felülvizsgálat

Utolsó módosítás:

Fábián Zoltán Hálózatok elmélet

Advanced PT activity: Fejlesztési feladatok

Internet ROUTER. Motiváció

Everything Over Ethernet

Számítógép hálózatok

ADATBÁZIS-KEZELÉS - BEVEZETŐ - Tarcsi Ádám, ade@inf.elte.hu

IP150 frissítés 4.20-ra

TELE-OPERATOR UTS v.14 Field IPTV műszer. Adatlap

A KASPERSKY SECURITY CENTER

Hálózati architektúrák és Protokollok PTI 6. Kocsis Gergely

20. Tétel 1.0 Internet felépítése, OSI modell, TCP/IP modell szintjenek bemutatása, protokollok Pozsonyi ; Szemenyei

Irányítástechnika Elıadás. PLC rendszerek konfigurálása

UNIX: folyamatok kommunikációja

Adatátviteli rendszerek Mobil IP. Dr. habil Wührl Tibor Óbudai Egyetem, KVK Híradástechnika Intézet

Operációs rendszerek. Az X Window rendszer

WAGO PLC-vel vezérelt hő- és füstelvezetés

Hálózati réteg. WSN topológia. Útvonalválasztás.

Az internet az egész világot behálózó számítógép-hálózat.

Tájékoztató. Használható segédeszköz: számológép

Jogában áll belépni?!

2014 UNIVERSITAS SCIENTIARUM SZEGEDIENSIS UNIVERSITY OF SZEGED

Újdonságok Nexus Platformon

ALKALMAZÁSOK ISMERTETÉSE

Windows rendszeradminisztráció és Microsoft szerveralkalmazások támogatása. 3. óra. Kocsis Gergely, Supák Zoltán

1. Forgalomirányítók konfigurálása

Kérdés Kép Válasz HIBAS Válasz HELYES Válasz HIBAS Válasz HIBAS Kérdés Kép Válasz HIBAS Válasz HELYES Válasz HIBAS Válasz HIBAS Kérdés Kép Válasz

Az RSVP szolgáltatást az R1 és R3 routereken fogjuk engedélyezni.

Windows rendszeradminisztráció és Microsoft szerveralkalmazások támogatása. Kocsis Gergely, Supák Zoltán

Kommunikáció. 3. előadás

MŰSZAKI KÖVETELMÉNYEK, A KÖRKERESŐ SZOFTVER SPECIFIKÁCIÓJA, KÖLTSÉGVETÉS. A) Műszaki követelmények

Hálózati Technológiák és Alkalmazások. Vida Rolland, BME TMIT október 29. HSNLab SINCE 1992

GSM azonosítók, hitelesítés és titkosítás a GSM rendszerben, a kommunikáció rétegei, mobil hálózatok fejlődése

[SZÁMÍTÓGÉP-HÁLÓZATOK]

A DNS64 és NAT64 IPv6 áttérési technikák egyes implementációinak teljesítőképesség- és stabilitás-vizsgálata. Répás Sándor

Számítógépes Hálózatok GY 6.hét

Osztott alkalmazások fejlesztési technológiái Áttekintés

Átírás:

7. Felsőbb rétegek, hálózati eszközök felügyelete 7.1. Felsőbb rétegek Az OSI felsőbb rétegei közül a viszony réteg és a megjelenési réteg nem szerepel a TCP/IP modellben. Ezért nem foglalkozunk velük nagy terjedelemben. Szerepüket az OSI modell általános ismertetésénél tárgyaltuk. A rétegek által megvalósított funkciók egy része azonban nélkülözhetetlen az eltérő rendszerek közti kommunikáció, vagy a hatékonyság eléréséhez. Ezeket a feladatokat az alkalmazási rétegben kell elhelyeznünk. A megjelenítési réteg feladata lenne például az ASCII - UNICODE átalakítás. A levelező programok (alkalmazási réteg!) egy globális szintaktikát használnak, amit minden számítógép a saját lokális szintaktikájának megfelelően fog megjeleníteni. A megjelenítési réteg helyett egy "felhasználói ügynök" hajtja végre az átalakítást. Az alkalmazás fejlesztő számára a hálózat architektúrája adottság, nem befolyásolható jellemző. A hálózat szolgáltatásokat nyújt az alkalmazásoknak, és az alkalmazások kommunikálnak egymással. A kommunikációt az alkalmazások szabványossága teszi lehetővé. Látnunk kell, hogy a hálózat architektúrája és az alkalmazás architektúrája két eltérő terület, ahol az alkalmazás fejlesztő az alkalmazás architektúráját tervezheti meg. A hálózati szolgáltatások közül a szállítási szolgáltatás tartalmaz választási lehetőségeket a tervezőnek. A szállítási szolgáltatások jelentős része többféle szolgáltatást biztosít, amiből választhatunk. Az egyik alapvető lehetőség, hogy megbízható adatszállítást (reliable data transfer), vagy nem megbízható adatszállítást választunk. Az alkalmazások egy részénél elfogadható, ha az adatok egy része nem érkezik meg. Ezek a veszteség tűrő (loss-tolerant applications). A multimédiás alkalmazások (tárolt kép és hangfájlok), valós idejű beszédátvitel számára megengedhető bizonyos mennyiségű adatvesztés. (Az IP telefon esetében 1-2%-os adatvesztés nem okoz érezhető romlást az érthetőségben). Az alkalmazás támaszthat időbeli korlátokat is átvitellel szemben. Egy on-line játék használhatatlan, ha jelentős a késleltetés a végpont között. A telefon rendszerekben 0,8sec a megengedett maximális késleltetés, amikor még nem érezzük természet ellenesnek a szüneteket. (Egy Mars expedícióval soha nem fogunk a megszokott módon telefonálni a nagy késleltetés miatt). Csak üzenet váltásokra lesz lehetőség. A szállítási réteg nyújthat még biztonsági szolgáltatásokat. Beépíthetők titkosító, 154

hitelesítő, adat sértetlenség (integritás) ellenőrző protokollok is a szállítási rétegbe. A leg gyakoribb a kliens szerver és a peer to peer (P2P), egyenrangú társak közötti architektúra. A kliens-szerver architektúra jellemzője, hogy van legalább egy folyamatosan működő, rögzített címmel rendelkező szerver, ami a kliensek kéréseit fogadja és kiszolgálja. A kliensek nem kommunikálnak egymással közvetlenül. Ilyen alkalmazás a WEB, Telnet, Google, vállalati központi kiszolgálók. Az alkalmazás a kliensek számának emelkedésével egyre nagyobb teljesítményű és költségesebb központi eszközöket igényel. Előnye, hogy a folyamatok jól ellenőrizhetők, az adatbiztonság valamilyen szinten kontrollálható. 7.1 ábra. Kliens-szerver architektúra. 155

A P2P architektúra nem, vagy csak minimális mértékben támaszkodik központi szerverre. Az alkalmazás időszakosan összekapcsolt végpontokon fut. A kliensek nincsenek a szolgáltató tulajdonában. Az elrendezésben nehéz a nyomkövetés és a biztonsági kérdések sem oldhatók meg teljes értékűen. Előnye, hogy viszonylag kis teljesítményű központi erőforrást igényel. Ilyen elrendezés pl. a BitTorrent. 7.2 ábra. P2P elrendezés Ma a legtöbb megvalósítás a client-szerver és a P2P valamilyen ötvözete. A belépés, hitelesítés folyamata központosított, az adatforgalom azonban P2P. Jellegzetes példája a megoldásnak a Skype. A P2P erőforrás és sávszélesség takarékossága, költséghatékonysága több nagy szolgáltató érdeklődését is felkeltette (MSN, Yahoo). A nagy mértéken elosztott rendszer biztonságának megoldása azonban további feladatokat jelent a fejlesztőknek. 156

7.2. SNMP - egyszerű hálózat felügyelő protokoll A hálózatok üzemeltetése során egyre nagyobb igény volt olyan eszközökre, melyek lehetővé teszik a hálózati elemek távoli felügyeletét. A cél egy egyszerű protokoll létrehozása volt, amit minden eszközön viszonylag egyszerűen lehet implementálni. A felügyeleti rendszerek nagy valószínűséggel vegyes hálózatban (különböző protokollokat használó) kerülnek alkalmazásra. A hálózaton belül különböző gyártóktól származó, és nagyon különböző eszközök közös menedzselését kell megoldani. A protokoll neve arra utal, hogy egyszerű kérdés/válasz mechanizmust használ. A megvalósítás meglehetősen bonyolult, és aligha nevezhető egyszerűnek. Az ide vágó ajánlást (RFC 1157) 1990-ben definiálták (SNMPv1), majd a tapasztalatok alapján az RFC 1441 és 1452 ben módosították (SNMPv2). A megvalósítás részleteit további társdokumentumok RFC1155, RFC1213, és számos további, tartalmazzák. Jelenleg már létezik az SNMPv3 is. Az eszközök nagy része az SNMPv2 szerint működik, az ábrákon is ez szerepel. Az elvek és a működés módja lényegében nem tér el az egyes változatokban. A változások főként a biztonsági kérdéseket érintik. 157

7.2.1. Az SNMP modell Az SNMP modell összetevői felügyelt csomópontok felügyeleti állomások felügyeleti információ felügyeleti protokoll Network Network Network Management device devices System SNMP SNMP SNMP proxy Manager agent agent get-request, get-next-request get-bulk,set-request get-response,traps SNMP l 7.1 ábra. SNMP modell elemei. A felügyelt csomópont szinte bármi lehet, ami információt tud szolgáltatni a külvilágnak (hoszt, router, híd, nyomtató, stb...). Ahhoz, hogy eszköz közvetlenül SNMP felügyelhető legyen, futtatnia kell az eszközben egy SNMP ügynök folyamatot. Minden ügynök fenntart egy helyi adatbázist, ami leírja az eszköz beállításait, illetve adatokat gyűjt az eseményekről. A hálózati felügyeletet a felügyeleti állomásokon (management stations) történik. Az SNMP felügyelet része lehet egy általánosabb hálózat felügyeleti rendszernek (Network Management System). A felügyeleti állomás SNMP protokoll segítségével tartja a kapcsolatot az ügynökökkel. Az állomás le tudja kérdezni az objektumok értékét, és meg is tudja változtatni azokat. A felügyeleti állomások speciális programot futtató általános számítógépek, ahol a felügyelt eszközök egy grafikus felületen keresztül érhetők el. Sok gyártó programja csak a saját eszközeit jeleníti meg, de azokat valósághűen, mintha a készülék előtt lennénk. A paraméterek elérhetők viszonylag egyszerűen modperl programokból is. Ez parancssoros elérést tesz lehetővé. Előnye, hogy olyan feltételeket is beiktathatunk, amit a grafikus felületen nem tudunk megtenni. A MIB-ben definiálhatunk lényeges eseményeket. Ha ilyen esemény ( torlódás, vonal szakadás, újraindulás, ) történik, akkor az ügynök erről értesíti az összes listájában szereplő felügyeleti állomást. Ezeket a jelentéseket csapdának (trap-nak) 158

nevezik. A jelentés általában csak azt mondja meg, hogy történt valami. Ez után a felügyeleti állomás dolga a részletek lekérdezése. A felügyeleti állomások esemény nélkül is időnként lekérdezik a csomópontok adatait, hogy biztosak lehessünk abban, hogy működnek. Az a feltétel, hogy minden csomópont tud futtatni SNMP ügynököt nem mindig teljesül (régebbi eszközök), vagy nem célszerű. A régebbi készülékek nem alkalmasak erre, az újaknál esetleg gazdaságossági megfontolások miatt választanak más megoldást, a proxy agent alkalmazását. Az SNMP ajánlás definiál egy helyettesítő ügynököt ( proxy agent ), amely több készüléket felügyelhet, és a nevükben kommunikálhat a felügyeleti állomással. A proxy agent a felügyelt állomásokkal valami más, nem SNMP protokollal kommunikál. Tipikus példája egy ilyen megoldásnak, mikor több HUB-ot vagy switchet egymás fölé rakunk egy szekrényben. Az eszközöket egy speciális kábellel összekötjük, létrehozunk egy egyetlen egységnek látszó STACK-et. Ilyenkor elegendő egyetlen egységbe megvásárolnunk az SNMP modult. Itt fog futni a proxy agent, és lehetővé teszi az egész torony managelését. Az SNMP modell jórészt azt definiálja, hogy az ügynök milyen információkat gyűjtsön és milyenparancsokat fogadjon, továbbá részletesen szabályozza a kommunikációt. Az SNMP irodalom a változókat objektumoknak nevezik. Az összes, az eszközökben lehetséges objektumot a MIB (Management Information Base) által definiált adatbázisban tároljuk. A MIB (jelenleg MIBv2) verzió, egy fa strukturát definiál az objektumokhoz. A MIB szerkezete kötött, de nem kötelező minden ág megvalósítása, és van olyan ág, amit tetszőlegesen (a formai kötöttségek betartásával!!!) bővíthetünk. Valójában egyetlen MIB struktúra létezik a világon, és ennek meghatározott helyén lehetnek gyártó specifikus modulok. A kötött szerkezet jelentősen egyszerűsíti a navigálást az adatbázisban, de minden konkrét eszköz esetén szükségünk van az adott eszköz gyártója által specifikált részfa ismeretére. Az SNMP ötféle adattípust ismer: egész szám bit string karakterlánc objektum azonosító 159

null érték Valamennyi változó skalár. 7.2.2. MIB struktúra A fa felső szintjén a szabványosító szervezetek vannak. Az ISO (1) csomópont alatt van az azonosított szervezetek (3) csomópont, és ezen belül a dod (Department of Defense). A DoD alatt található az internet (1). ccit(2) iso(1) joint iso-ccit(2) standard(0) registration- memberauthority(1) body(2) identified organization(3) dod(6) Internet(1) directory(1) mgmt(2) experimental (3) private(4) security(5) snmpv2(6) mib-2(1) system(1) interface(2) at(3) ip(4) icmp(5) tcp(6) udp(7) egp(8) transmision(10) sample(11) 7.2.ábra. MIB struktúra. A 7.2 ábrán a MIB-nek az a részfája látható, ami fontos a hálózati eszközök manageléséhez (mib-2 struktúrából kimaradt a mib-1 ben definiált cmot(9) elem). A nevek mellé írt számok a nevet helyettesítik az Object Indentifier ( OIB ) ben. A nevek helyett pontokkal elválasztott, számokból álló sorozattal adjuk meg az elem helyét a fában. A programok számára ez nyilvánvalóan egyszerűbb, mint a nevekkel történő hivatkozás. A neveket is használhatjuk, ha pontosan ismerjük az írásmódjukat. Például az Internet ág OID-je: 1.3.6.1. Ezzel teljesen egyenértékű az iso.org.dod.internet. megadás. A gyártó specifikus modulok az Internet alatt, a private (4) ágon helyezhetők el. Példaként a " Cisco Private MIB Hierarchy"-t ábrázoltuk a 7.3 ábrán. A keretezetlen csoportok azt jelzik az ábrán, hogy ezekhez a csoportokhoz a felügyelt eszközökben táblázatok tartoznak, melyeket egy-egy eszköz saját MIB leírójában találhatunk meg. 160

Lab. from the root 1.3.6.1. private(4) Enterprise(1) CISCO(9) other local temporary cisco Enterprises(0) variables (2) variables(3) Mgmt(9) Novell(23) Fash group(10) AppleTalk group(3) Channel Interface Processor group(20) mibdoc Interface group(2) Chassis group(0) ipx(23) IP group(4) DECnet group(1) Ping group(10) cisco TCP RIPSAP(220) system group Novell group(4) group(0) romid(1) VINES group(5) Terminal Services group(9) XEROX (XNS) TCP group(0) group(2) 7.3. ábra. Példa a private csoport egy részfájára. A változók közül nézzük meg részletesebben a "local variables" csoportot. Flash group A flash memória tárolja a boot-hoz szükséges szoftver elemeket. A set-request művelettel, TFTP (Trivial File Transport Prototcol) protokollal lehet betölteni a szoftvert tartalmazó fájlt. Interface group A forgalmi statisztikákat (forgalom, vonali állapot, átlagos sebesség, ki és bemenő csomagok száma, hibák száma) tárolja interfészenként. IP group Az IP alapú forgalom statisztikáit tárolja. Tartalmazza a forrás és célállomások címét, az ICMP üzeneteket, a továbbított és elvesztett csomagok számát. System group Az általános információkat (szoftver verziószám, hoszt név, domain név, pufferek mérete, konfigurációs fájlok, stb.) tartalmazza. Terminal Services goup A terminál kiszolgáláshoz szüksége információkat tartalmazza. 161

Ilyenek: fizikai vonalak száma, sebessége, típusa, a nyugtázás típusa, modem típusa. TCP group A TCP csatlakozáson áthaladó bájtok és csomagok számát mindkét irányban, valamint a hibás és elveszett csomagok számát tartja nyilván. Ezek a változók jórészt a kötelezően megvalósítandó csoporthoz tartoznak, alapvető fontosságúak a rendszer felügyeletében. Általános elv, hogy ha megvalósítunk egy a hierarchia alján lévő csoportot, akkor lehetőleg annak minden elemét valósítsuk meg. Ez nem kötelező szabály, de a gyártók nagy része betartja. 7.2.3. Az SNMP protokoll A felügyeleti állomás és a felügyelt csomópont közötti kommunikációhoz viszonylag kevés üzenettípust definiáltak. A kevés művelettípus ellenére a gyártók a műveletek megfelelő paraméterezésével olyan feladatok megoldására is képessé tehetik az egységeiket, melyek eredetileg nem szerepeltek az SNMP specifikációban. Tipikus példa a berendezés újraindítása. Ilyen parancs nincs, de specifikálhat a gyártó egy olyan változót, amelynek meghatározott értéke esetén újraindítás történik. A felügyelő egy get-request művelettel beállítja az értéket, és ezzel kikényszeríti az újraindítást. A leggyakrabban használt műveletek: get - request A get - reqvest művelettel kérhetjük le az SNMP változók értékeit. get - next - request A művelet hasonló a get - reqvest-hez. Akkor szokták használni, ha egy tábla összes elemét le akarjuk kérdezni. Előfordul, hogy nem ismerjük a tábla elemeinek számát, vagy nevét, és így akarjuk elérni a táblát. Fontos az RFC pontos definíciója, hogy a get-next-request a "specifikált elem első lexikográfiai követőjét" adja vissza. Ez egyrészt azt jelenti, hogy "kicsúszhatunk" egy táblázatból, ha ellenőrzés nélkül használjuk, másrészt megtalálhatjuk egy tábla összes elemét akkor is, ha nem ismerjük a méretét. Vizsgálnunk kell a visszaadott válaszokat, hogy azonos lexikográfiai csoportban vagyunk-e? Ha igen folytatjuk a lekérdezést. Így megtalálható a csoport összes eleme. ( A 7.2.4-ben bemutatott példában vizsgálhatnánk, hogy a válasz 162

"system"-el kezdődik-e? Ha igen, kérjük a következőt, ha nem, akkor az előző volt a tábla utolsó eleme.) set - request Megpróbálja beállítani egy változó értékét. Általában a konfiguráció megváltoztatására használjuk. trap/snmpv2trap Az SNMPv1-ben trap, a v2 és v3-ban snmpv2trap a művelet neve. Egy egységet arra utasítunk, hogy valamilyen esemény bekövetkezésekor küldjön jelzést a felügyeleti állomásnak. response A response művelet küldi vissza az összes PDU válaszát. Általában nincs szükség rá, hogy külön parancsként kiadjuk. A függvények többsége külön kérés nélkül kezeli. (Pl.: egy set-request művelet nem csak végrehajtódik hanem vissza is jelzi, hogy az ténylegesen végrehajtódott-e.) A PDU-k teljes listáját az RFC1905 tartalmazza. 7.2.4. ASN_1. Absztrakt szintaxis jelölés 1. A többtulajdonosú kommunikáció szükségessé teszi, hogy az objektumokat szabványos módon definiáljuk. A többszáz gyártó készülékeinek együttműködéséhez nagyon pontos szabályozás kell. Ehhez egy definíciós nyelvre, és a hozzá tartozó kódolási szabályokra van szükség. A létrehozott definíciós nyelv az Abstract Syntax Notation One. A "One" azt sugallja, hogy a tervezés pillanatában tudták, hogy vannak még fejleszthető részei a nyelvnek. Az ASN_1 részben definíciós célokat szolgál, másrészt vannak olyan hálózat felügyelő programok, melyekbe be lehet fordítani az így definiált elemeket, és ezzel bővíthető a felügyelt eszközök köre. A ténylegesen tárolt adatok formátuma a Strukture for Management Information (SMI) dokumentációban található. Az SMI a táblázatok szerkezetét, és a bennük szereplő adatok formátumát definiálja. A MIB tehát egy leíró, ami definiálja a felügyeleti állomás és az SNMP agent számára az adatok szerkezetét, és helyüket a MIB fában. A rendszer intelligenciája a 163

felügyeleti állomásba koncentrálódik, hogy a felügyelt csomópontok minél egyszerűbbek lehessenek. Az ASN_1 lényegét egy példából érthetjük meg a legegyszerűbben. Nézzük meg, hogyan tudnánk lekérdezni SNMP segítségével, hogy mennyi idő telt el egy gép utolsó bekapcsolása óta. Első lépésként meg kell keresnünk a változót, ami ezt az adatot tartalmazza. A változó valószínű elnevezése "uptime", vagy valami hasonló. (A dokumentációkban való keresgélés hosszadalmas lehet a sok hivatkozás miatt.) Az RFC 1213-ban keresve az alábbi ASN_1 kódrészletet találjuk: sysuptime OBJECT-TYPE SYNTAX TimeTicks ACCESS read-only STATUS mandatory DESCRIPTION The time (in hundreadths of second) since the network management portion of the system was re-initialized ::= { system 3 } Az első sor sysuptime objektumot definiálja. A második sor az objektum típusát adja meg. A harmadik sorban definiáljuk, hogy az objektum csak olvasható. Nem végezhetünk rajta set-request műveletet. A "STATUS mandatory" jelentése, hogy az objektumot minden SNMP ügynökprogramnak kötelezően meg kell valósítani. A DESCRIPTION egy szöveges leírás az objektumról. :: = {system3} sor illeszti az objektumot a MIB fába. Eszerint a sysuptime objektum a system csoporton belül a harmadik alcsoport. Ha a csak olvasható közösségben (lásd később) lekérdezzük a változót ( modperl UCD-SNMP modulból) a MIT 55 gépen, akkor a parancssor az alábbi: $snmpget MIT55 MyPulicCommunityName system.sysuptime.0. A parancssor végén lévő 0 arra utal, hogy a tábla első elemét akarjuk megjeleníteni. 164

A válasz : system.sysuptime.0. = timeticks : (256318123) 7:7:18.23 Az eredmény 7 óra 7 perc, 18.23 másodperc. A zárójeles rész az eltelt időt 1/100 másodpercben adja meg. A példából megismerhettük az ASN_1 felhasználásának elvét. Részletes ismeretére akkor van szükségünk, ha mi is akarunk új elemet létrehozni, vagy parancssorból kívánunk elérni változókat. 7.2.5. SNMP biztonsága Az SNMP-vel meglehetősen sok mindent meg tudunk tenni. Rosszindulatú használata a hálózatban jelentős károkat tud okozni. Indokolt tehát a védelem kérdése. Az SNMPv1 mindössze annyit tett, hogy az eszköz tartalmazott egy jelszót. A jelszó a hálózaton kódolatlan formában került továbbításra, tehát "elkapása" nem okozott túlzott nehézséget. Az első változatra tréfásan szokták emlegetni, hogy az SNMP valójában a "Security Not My Problem" rövidítése. Az SNMPv2 jelentősen javított a helyzeten, sőt helyenként túlzottan erős kódolást használ. Az elérhetőség definiálására az SNMP néhány új fogalmat vezetett be. Az SNMP egységek között (SNMPv1 és SNMPv2C) lehet adminisztratív kapcsolatot, úgynevezett közösséget (communities) definiálni. Egy közösségre lehet azonos korlátozásokat beállítani. Általában célszerű egy csak olvasható jogú közösséget, és egy írás-olvasás jogú közösséget létrehozni. Az olvasási jogra szüksége lehet mindazoknak az elemeknek, melyek egy adott részhálózat felügyeletével foglalkoznak (pl.: a szomszédos routerek). Minden objektumhoz beállítható egy MIB nézet (MIB view). Azt mutatja meg, hogy mihez férhetünk hozzá. Minden objektum lehet read-only, read-write vagy none elérésű. Ez az objektum elérési módjának nevezik. A közösség, a MIB nézet, az elérési mód együttesen képezi az SNMP elérési házirendet (SNP acces policy). A házirend, a jelszavak és adatok kódolt átvitele általában kielégítő védelmet nyújt a rosszindulatú beavatkozások ellen. 165

7.2.6. SNMP a gyakorlatban Az SNMP-vel felügyelhető egységeknek a kezdetben nincs IP címűk, közösségük, stb. Így a hálózaton keresztül nem menedzselhetők. Az első beállításokat lokálisan kell elvégezni. Ha nincs az egységen saját képernyő, billentyűzet, akkor általában soros porton keresztül tudunk csatlakozni, és terminál program segítségével tudjuk a kezdeti értéket beállítani. A felparaméterezett eszköz a hálózaton keresztül menedzselhető. Ha a hálózat működésképtelensége esetén is szeretnénk elérni az eszközt (pl.: egy routert), akkor a soros portra telepített modemmel megtehetjük. A funkciókat a felhasználó szemszögéből is csoportosíthatjuk: Monitor group Megjeleníti a csomagok számát, típusát, hibák számát, típusát Basic group Portok tiltása, engedélyezése, állapot megjelenítése Address Tracking group Fizikai címek keresése és hozzárendelése a logikai címhez Specific group Gyártó specifikus elemek csoportja. Az első 3 csoport megvalósítása kötelező, a speciális csoportból minden gyártó azt valósít meg, amit fontosnak ítél. A kötelezően megvalósítandó elemek is részei lehetnek a "privat" csoportnak. Vannak olyan kötelező elemek az általános MIB struktúrában, melyek függetlenek a hardver megoldásoktól és gyártóktól (Pl.: mindig kötelező a mib-2 csoporton belül a system group). Fontos alkalmazási területe az SNMP-nek a redundás rendszerek létrehozása. Ha két hálózati elemet többszörösen el lehet érni, akkor az ütközésekhez, hibás működéshez vezet. Az SNMP lehetővé teszi, hogy tartalék útvonalakat hozunk létre fizikailag, melyek akkor aktivizálódnak, ha a primer útvonal valamilyen okból nem működik. A redundáns útvonalakat a redundancia táblázatban (Data Path Redundancy Table), adhatjuk meg, amivel jelentősen csökkenthető a fizikai összeköttetés meghibásodásából adódó működésképtelenség valószínűsége. 166