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 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)
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)
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: 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 Enterprises(0)
local variables (2)
Novell(23)
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.
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
