Informatika | Hálózatok » Felsőbb rétegek, hálózati eszközök felügyelete

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. Az alkalmazási rétegen belül nem tudjuk az a rétegszemlélet általános logikáját követni, itt egyes alkalmazásokat kell szabványossá tenni. A kommunikációt az alkalmazások szabványossága teszi lehetővé. 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. 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 154 7.21 Az SNMP modell Az SNMP modell összetevői • felügyelt csomópontok • felügyeleti állomások • felügyeleti információ • felügyeleti protokoll Network Management System Network device Network devices SNMP Manager SNMP agent SNMP proxy 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) 155 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ó 156 • null érték Valamennyi változó skalár. 7.22 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) standard(0) registrationauthority(1) joint iso-ccit(2) memberbody(2) identified organization(3) dod(6) Internet(1) directory(1) experimental (3) mgmt(2) 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: 1361 Ezzel teljesen egyenértékű az iso.orgdodinternet

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. 157 Lab. from the root 1361 private(4) Enterprise(1) CISCO(9) other Enterprises(0) Novell(23) local variables (2) temporary variables(3) Fash group(10) AppleTalk group(3) Interface group(2) Chassis group(0) ipx(23) IP group(4) DECnet group(1) RIPSAP(220) system group romID(1) Novell group(4) mibDOC cisco Mgmt(9) Channel Interface Processor group(20) Ping group(10) cisco TCP group(0) VINES group(5) Terminal Services group(9) TCP group(0) XEROX (XNS) 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. 158 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.23 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 724-ben bemutatott példában vizsgálhatnánk, hogy a válasz 159 "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.24 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 160 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.sysUpTime0 A parancssor végén lévő 0 arra utal, hogy a tábla első elemét akarjuk megjeleníteni. 161 A válasz : system.sysUpTime0 = timeticks : (256318123) 7:7:1823 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.25 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. 162 7.26 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. 163