8. Internet Az "Internet" napjainkban nem egy technológia a sok közül, hanem önálló életre kelt, a társadalmat befolyásoló eszköz. A technológiai cél: egymástól eltérő fizikai architectúrájú hálózatok összekapcsolása annak érdekében, hogy a hálózatban szereplő gépek egymással kommunikálni tudjanak 8.1 ábra. Eltérő technológiák kapcsolódása az Interneten. Az Internet alapvetően a TCP/IP rétegmodellre épül. A hivatkozási modell rétegeit, és szerepüket más hivatkozási modellekhez képest az 1. fejezet 1.10 és 1.11 ábrán szemléltettük. Az egyes rétegekben működő protokollok áttekintését 8.2 ábrán láthatjuk. A protokollok listája nem teljes, csak néhány jellegzetes elemet tartalmaz. 164
Web browser e-mail Other user Applications Application protocols: HTTP,SMTP,FTP,DNS.. USER space Applications Application Programming Interface (API) Transport Network ICMP TCP IP UDP RIP OS kernel ARP Data Link RARP FDDI WAN technology LAN technology Ethernet 8.1. A működés modellje 8.2.ábra. TCP/IP protocol stack A hálózatban egyedi, egymástól független "csomagok" haladnak, melyeknek a célhoz vezető útvonalát a csomagban lévő cím alapján keressük. Nem biztos, hogy van ilyen útvonal, vagy ha létezik, akkor biztosan megtaláljuk meghatározott időn belül! A hálózat csomópontjain "routerek" vannak, melyek táblázatokat (Routing tables) tartanak fenn a célokhoz vezető útvonalakról. Belátható, hogy elegendő azoknak a szomszédos csomópontoknak a tárolása, ami a célhoz vezet, nem kell a teljes útvonalat tárolni. Ha egy routernek 4 "lába" van, akkor egy beérkező csomag a 3 kimenet valamelyikén továbbítható. Csak azt kell eldöntenünk, hogy melyiken a 3 közül. A további útvonal meghatározása a következő router feladata. 165
DA = Destination Address ( cél cím) SA = Source Address ( forrás cím) 8.3 ábra. Routerek a hálózatban A 8.3 ábrán az x című állomás küld csomagot az y címűnek. A csomagok fejléce tartalmazza yx-et. A routerek az "y" címhez tárolják azoknak a szomszédaiknak a címét, melyeken keresztül "y" a legkedvezőbben elérhető. (Legkevesebb ugrás, legkisebb költség, legrövidebb idő, stb.) A szolgáltatás datagram jellegű: A csomagok ezért elveszhetnek többszöröződhetnek beérkezési sorrendjük megváltozhat A biztonságos átvitelről a felettes rétegeknek kell gondoskodni. 8.2. Az Internet protokolljai A nagy hálózatok összekapcsolásának valódi alapja az Internet Protocol (IP). Eleve a különböző hálózatok összekapcsolására tervezték. Optimális továbbítást biztosít a datagramok számára a forrásgéptől a célgépig. 166
Az alkalmazás a szállítási rétegnek adja át az adatokat. A szállítási réteg max. 64kbyte hosszú darabokra tördeli az üzenetet. Az üzeneteket a hálózati réteg esetleg tovább darabolva továbbítja. A célgépen a hálózati réteg visszaállítja a datagramot, és átadja a szállítási rétegnek. A szállítási réteg protokoll vermeket tart fenn a különböző protokolloknak. Általában négyféle protokoll vermet tartanak fenn az operációs rendszerek. Ha az útvonal más jellegű hálózaton is áthalad, akkor az alagút típusú átvitelt használhatjuk (Pl. SNA hálózatokban). A csomagot tartalmazó keretet beburkoljuk egy az adott hálózaton használatos keretbe, az alagút végén pedig kicsomagoljuk. Hasonló a folyamat ahhoz, ahogy a gépkocsikat berakjuk vasúti kocsikba az alagút előtt, az alagút után pedig az autók saját erőforrásaikkal haladnak tovább. 8.2.1 Ipv4 protokoll Hálózataink jelenleg ezt a protokollt használják. 8.4. ábra. Ipv4 csomagformátum A mezők jelentése: Version (Verzió) Biztosítja, hogy a régebbi verzióval működő gépek csomagjait is megfelelően dolgozzuk fel az átmeneti időszakban. Az átmeneti idő, míg az új verzió elterjed, éveket is jelenthet. IHL - fejrész hossza 167
32 bites szavakban adja meg a fejrész hosszát. Legkisebb értéke 5. Maximális értéke 15. Ez a fejrész hosszát 60 bájtra korlátozza. Az opciós mező így legfeljebb 40 bájt lehet. Néhány opcióhoz ez túl kicsi. (Lásd: opciók) Type of service - szolgálat típusa lehetővé teszi, hogy a hoszt megadja az általa kért szolgálat jellegét. A sebesség és megbízhatóság különböző kombinációit adhatjuk meg. 1 tulajdonsághoz 1 bit tartozik. Pl. hangátvitelnél a sebesség, fájl átvitelnél a megbízhatóság lehet a fontos. Ha a bitenkénti értelmezés helyett a kombináció számértékét adjuk meg, akkor az alábbi táblázat írja le a szolgáltatásokat: TOS mező értékei: Ø normál szolgála 1 minimális költség 2 maximális megbízhatóság 3 maximális átbocsátás 4 minimális késleltetés Precedence mező Ø-7 értékkel jelöli a csomag fontosságát. Ø a legalacsonyabb prioritás 7 a legmagasabb prioritást jelöli, a hálózati vezérlő csomagok szintje. Flags 3 bitet tartalmaz Az első bit használaton kívüli. A Don't fragment annak a jelzésére szolgál, hogy a csomag nem darabolható. Ennek a jelzőnek a beállítása veszélyeket is hordoz. Ha a routerek nem tudnak olyan méretű csomagokat továbbítani, mint amit küldünk, akkor "az útvonal nem létezik" jelzéssel leállhat az adatforgalom. Egy másik lehetőség, hogy a rövidebb csomagok továbbítására alkalmas rendszerszakaszon mégis feldaraboljuk a csomagot, továbbítjuk, és a szakasz végén helyreállítjuk. A lényeg az, hogy nem a célállomásra bízzuk a darabok összeállítását, hanem a szakasz végén lévő routerre. A szakasz után a csomag olyan, mintha nem 168
daraboltuk volna fel. A célállomás a fel nem darabolható csomagok egymás közötti sorrendjével foglalkozik csak. M - More fragments bit azt jelzi, hogy a feldarabolt csomagnak nem ez az utolsó darabja. Ha megkaptuk azt a darabot, ahol M=Ø, akkor tudjuk, hogy ez az utolsó, és ismerjük a "Fragment offset" értékét. Ennek birtokában ellenőrizhető, hogy minden darab megérkezett-e. Fragment offset (Darabeltolás) megadja, hogy a darab hova tartozik a datagramban. A címzésre 13 bit áll rendelkezésre, így a teljes datagram címezhetősége érdekében az eltolást 8 bájtos egységekben adja meg. A 8192 *8 bájt 1-el több mint amit a teljes hossz (Total length) le tud írni. Identification mező szolgál a datagram azonosítására. Egy datagram minden darabja ugyanazt az azonosítót tartalmazza. Ez teszi lehetővé, hogy a cél - hoszt azonosítsa az egy datagramhoz tartozó darabokat. Time to live mező a darab maximális élettartamát adja meg másodpercekben. A 8 bit maximum 255 másodpercet jelent. A számláló értékét minden másodpercben, illetve minden routeren való áthaladáskor csökkentjük 1-el. A routerek sokszor eltérnek ettől a szabálytól, és csak az áthaladáskor csökkentik a számlálót, az időt figyelmen kívül hagyják. Az indok az, hogy a pufferben tárolt adatokra nehézkes a megvalósítás. Az adatokon túl tárolnunk kellene a pufferbe való elhelyezés időpontját is. A csomagjaink tehát nem maradnak végtelen ideig a hálózatban. Az élettartam mező kezdőértéke beállítható. Általában 40-50 közötti érték a szokásos. Gyors hálózatokban 10 körüli érték megadása is indokolt lehet, hogy ne fordulhasson elő az élettartamon belül két azonos sorszám. "Protocol" mező A hálózati réteg összeállítja a datagramot, és a protokoll mezőben meghatározott szállítási folyamatnak adja át. A folyamat általában TCP vagy UDP, de más is lehet. A protokollok számozása egységes, az RFC 1700 definiálja. Header checksum (fejrész ellenőrző összege). 169
Csak a fejrészt ellenőrzi, a tartalmat nem. Képzése rendkívül egyszerű. 1-es komplemens módon összeadjuk a beérkező fél-szavakat (16 bit), és képezzük az eredmény 1-es komplemensét. Az ellenőrző összeget minden routeren újra kell számolni, mert az élettartam mező mindig megváltozik. Source Address, Destination address Forrás és cél címe 32 biten. (Az IP címek szerkezetét, és címfeloldást lásd később.) Options mező 0-40 bájt hosszú lehet. Eddig 5 opciót definiáltak. A biztonság opció az információ titkosságának fokára utal. Használata gyakorlatban nem célszerű, mert felhívja a figyelmet a fontos információra. Eredményesebb álcázás, ha a fontos adatok eltűnnek a lényegtelenek tömegében. Szigorú forrás általi forgalomirányítás IP címek sorozataként megadja a teljes útvonalat Laza forrás általi forgalomirányítás lényegében az útvonal irányát jelöli ki. (Az információ bizonyos országokon ne haladjon át, ne hagyja el az országot, stb) Útvonal feljegyzése opció főként a routerek üzemeltetőinek fontos..lehetővé teszi a hibák felderítését.(miért ment USA-n keresztül a szomszéd épületbe címzett üzenet?) A mai körülmények között sokszor kevés a 40 bájt az útvonal tárolására. Az időbélyeg opció az IP cím mellé egy 32 bites időbélyeget is feljegyez. Főként a router algoritmusok hibakeresésénél hasznos eszköz. 8.2.2. IP címzési rendszer A címzési módokat az RFC791 (1981) írja le. Az Ipv4 cím két részből áll: hálózati cím + hoszt cím. Egy hoszt egyszerre több hálózathoz is csatlakozhat. Ekkor minden hálózatban külön IP címe van. A címet megjeleníthetjük binárisan, vagy decimális formában. 170
Szokásos az u.n. "Dotted decimal" formátum. A 32 bit 4 bájtnak felel meg. Minden bájt decimális értékét írjuk ki, pontokkal elválasztva. Pl.: 193. 221. 15. 179 Az egy hálózatba tartozó gépek száma igen tág határok között változhat, ezért cím - osztályokat alakítottak ki. A címek adminisztrációját a NIC (Network Information Center) végzi. Ez a szervezet osztja ki a cím - tartományokat. A címtartomány korlátozottsága miatt (mindössze 32 bit, és ez sem osztható ki maradéktalanul) belátható időn belül szükség lesz a módosítására az Internet rohamos terjedése miatt. Számos javaslat született a megoldásra, és van szabvány javaslat is (Ipv6), de az áttérés jelentős költségei miatt egyelőre várat magára az áttörés. Valószínű, hogy az Ipv4 világban Ipv6 szigetek jönnek létre, melyeket a meglévő kapcsolatokon keresztül alagút jelleggel kapcsolnak össze mindaddig, míg az Ipv6 általánossá válik. 8.2.3. Címosztályok az Ipv4-ben A címosztály a cím 1.-5. bitje alapján határozható meg. 32 bit Osztály A 0 Hálózat Hoszt 1.0.0.0-tól 127.255.255.255-ig B 10 Hálózat Hoszt 128.0.0.0-tól 191.255.255.255-ig C 110 Hálózat Hoszt 192.0.0.0-tól 223.255.255.255-ig D 1110 Többesküldési cím 224.0.0.0-tól 239.255.255.255-ig E 11110 Jővőbeni alkalmazásokhoz fenntartva 240.0.0.0-tól 255.255.255.255-ig 8.5. ábra IP címosztályok. 171
A címek egy része speciális célokra foglalt. A 0.0.0.0 címmel indul minden hoszt, majd a hálózati paraméterek betöltése után többet nem használja. A 127.xx.yy.zz címek a visszacsatolások címzésére vannak fenntartva. A 127.0.0.1 a hoszt saját maga. A 255.255.255.255 helyi adatszórást jelent. Az adatszórás csak az alhálózaton belülre szól. Egy távolabbi hálózatban is végezhetünk adatszórást, ha egy helyes hálózati cím mögé csupa 1-eket írunk. Hálózati cím + 11.11 A helyi alhálózatunkban egy hosztot úgy is megcímezhetünk, hogy nem adjuk meg a teljes címet, csak az alhálózaton belüli hoszt címet. 0000 00 + hoszt cím 8.2.4. Alhálózatok. A nagyszámú géppel rendelkező felhasználó hamar szembe kerül azzal a problémával, hogy a NIC-től szeretne egy összefüggő címtartományt kapni, ugynakkor ezt a címtartományt szeretné kisebb, külön-külön managelhető tartományra bontani. A hálózati cím és a hoszt cím szétválasztására alkalmas eszköz a netmaszk. A netmaszk a hálózati cím-pozíciókban 1-et, a hoszt - cím helyén Ø-kat tartalmaz. A címosztály meghatározza, hogy a hálózati cím hány bites. Kívülről csak a hálózat címezhető,az alhálózatunk nem, mert a továbbított csomagokban nincs benn a netmaszk. A helyi hálózatunkban azonban valamennyi eszköz tartalmazza a netmaszk-ot, és így kiderül, hogy a csomag melyik alhálózatnak szól. A hoszt címeket egy EXOR művelettel választhatjuk le a teljes címből. (teljes cím) EXOR (netmaszk) = (hoszt cím) 172
Példaként hozzunk létre alhálózatot egy C osztályú címen belül. Az alhálózat max. 32 gépet tartalmaz. A címtartomány legyen: 193.221.15.32-193.221.15.63 Alhálózat IP cím Hálózat címe Hoszt cím 193.221.15.32 110 00001 11011101 00001111 001 00000 193.221.15.63 110 00001 11011101 00001111 001 11111 "C" osztályú a cím Hoszt cím a külső hálózat számára A külső hálózat nem látja az alhálózati maszkot, csak a "C" osztályt ismeri fel!! Alhálózati maszk 11111111 11111111 11111111 111 00000 Decimálisan: 255.255.255.224 Példa: alhálózati cím leválasztása a 193.221.15.41 címből Az alhálózat címe: 193.221.15.32 110 00001 11011101 00001111 001 01001 ÉS 11111111 11111111 11111111 111 00000 = 110 00001 11011101 00001111 001 00000 8.6. ábra. Alhálózat címzése Figyeljük meg, hogy az alhálózati maszk eredményeként a címtartományt 8 részre tudtuk osztani.. A címtartományok részekre osztásának a B osztályú címeknél van igazán jelentősége. Egy nagyvállalat a B osztályú címtartományát szabadon oszthatja fel, változtathatja anélkül, hogy a NIC-hez kellene fordulnia. 8.2.5. Az IP új generációja: IPv6 A fejlesztés céljai: Nagyszámú hoszt támogatása (>10 12 ) Forgalomirányító táblázatok méretének csökkentése Protokollok egyszerűsítése, gyorsabb feldolgozás a routereken Hitelesség és titkosság biztosítása 173
Jobb alkalmazkodás a szolgáltatás típusához, valós idejű adatok jobb kezelése Többesküldés lehetősége, hatósugarak megadásának lehetősége Mozgó hosztok jobb támogatása IPv4 és IPv6 együttélésének biztosítása hosszabb távon is. A fejlesztés 1992-1997 között folyt intenzíven. A javaslatban az eredeti megnevezése Simple Internet Protocol Plus volt. Az IPv6 jelölést azért kapta, mert az IPv5 már foglalt volt egy kísérleti fejlesztés számára. Az IPv6 nem kompatíbilis az IPv4-el, de a protokollok legnagyobb részével igen (TCP, UDP, ICMP, IGMP, OSFP, BGP és DNS). A hálózat vezérlésével és a névfeloldással kapcsolatos protokollok tehát kompatibilisek. Az IPv6 föbb tulajdonságai: 128 bitre növelt címtartomány. Új címzési séma. Hatékonyabb és flexibilisebb csomagformátum, egyszerűbb fejrész A továbbfejlesztés lehetősége az opcionális fejrészek bevezetésével A biztonsági mechanizmusok beépültek a protokollba (hitelesítés, titkosítás) Névfeloldás és a csoportmenedzsment része a protokollnak Az ARP (Address Resolution Protocol) és az IGMP (Internet Group Management Protocol) kikerült a rendszerből. Szolgáltatások a jobb támogatása 8.7.ábra. IPv6 fejrész 174
175
8.2.6. Az Internet szállítási protokolljai TCP - Transmission Control Protocol A protokollt kezdettől fogva sok hálózat összekapcsolására tervezték. Feltételezték, hogy az adattovábbítás megbízhatatlan, és a közbenső csomópontok meghibásodhatnak, megsemmisülhetnek. A modellt TCP/IP néven 1974-ben definiálták. A TCP összeköttetés orientált protokoll. Alapvetően a korábban tárgyalt 3-utas kézfogás módszerét használja. Feltételezi, hogy az alatta lévő hálózat megbízhatatlan (OSI terminológia szerint C-osztályú) összeköttetést nyújt, és a TCP feladata, hogy a csomagok hibátlanságát és helyes sorrendjét biztosítsa. A TCP tartalmaz nyugtázást, így azokon a hálózatokon, ahol jelentős a késleltetés, az adatkapcsolati rétegben valamilyen csúszóablakos protokollt használnak a hatásfok javítása érdekében. A TCP az IP hálózati protokoll ( IPv 4 vagy IPv 6 ) felett fut, használja a szolgáltatásait. Az IP felett azonban más protokollok is használatosak ( UDP, ICMP, ). A TCP tetszőleges hosszúságú adatokat fogad az alkalmazásoktól. Ezeket max. 64 kbyte hosszú darabokra (szegmensekre) tördeli. A darabokat független datagramként továbbítja a hálózaton. A kommunikáció alapvetően "szegmensekben " történik. Egy szegmensnek a TCP fejrésszel együtt bele kell férni az IP 65536 bájtos adatmezejébe. A hálózatban lévő eszközök (router, gateway) a maximális hosszt tovább korlátozzák. A szegmensek hossza általában jóval rövidebb a maximális 64 kbyte-nál, néhány ezer bájt szokott lenni. A szegmens hossza valójában a hálózatban átvihető leghosszabb adategységhez (Maximum Transfer Unit) illeszkedik. Előfordulhat, hogy a hálózat különböző részein ez eltérő, és egy szakaszán az MTU rövidebb, mint a szegmens hossza. Ilyen esetben feldaraboljuk a szegmenst, és minden darabot önálló IP csomagként továbbítunk. A rövidebb szegmensekhez kapcsolódó IP fejrészek jelentős többletterhet jelentenek a hálózatnak. A TCP-ben minden byte-nak sorszáma van. A 32 bájtos sorszám elegendően nagy ahhoz, hogy a kettőződést elkerüljük a többszörös beérkezések esetén. A körülfordulási idő 100 Mbit/sec sebességű hálózaton is nagyobb mint 6 perc. 176
A TCP fejrész a valóságban kiegészül még egy pszeudofejrésszel. A pszeudofejrész az IP-hez tartozó adatokat tartalmaz. A szerepe az, hogy a tévesen továbbított csomagok könnyebben detektálhatók legyenek. A TCP szegmens fejrésze: 32 bit 0 Source IP address Destination IP address Protocol(6) TCP segmenth lenght Pseudo header Source TCP port Destination TCP port Sequence number Acknowledgement number Hdr.l. Flags Window size Checksum Urgent pointer Options Data TCP header Flags URG ACK PSH RST SYN FIN 8.8. ábra. TCP fejrész felépítése A forrásport (source port) és a célport (destination port) szolgáltatásokat azonosítanak. Minden hoszt részben szabadon dönt a portok és a szolgáltatások összerendeléséről, amint azt a szállítási réteg tárgyalásánál már láttuk. Egy portszám és az IP cím együtt alkotja a 48 bites TSAP címet. A TCP bájtonként sorszámoz. A sorszám (sequence number) a szegmens első bájtjának sorszáma. A nyugtaszám (acknowledgement) mező a következő várt bájt (az utolsó helyesen vett sorszáma + 1) sorszámát tartalmazza. A TCP fejrész hossz (TCP header lenght) megadja, hogy hány 32 bites szóból áll a fejrész ( a pszeudofejrész nélkül). A fejrész hossza az opciók miatt változik, így meg kell adnunk a hosszát, hogy az adatmező kezdete ismert legyen. Ezt követi egy 6 bites használaton kívüli rész, majd a jelzőbitek (flags) következnek. Flags: 177
URG = 1 ha használunk sürgősségi mutatót. A sürgősségi mutató a sürgős rész helyét jelöli a sorszám mezőhöz képest. Az URG szerepe hasonló, mint a megszakításé a programok futása közben. ACK = 1 értéke azt jelzi, hogy a szegmens nyugtát tartalmaz. Ha az értéke 0, akkor a nyugtamező figyelmen kívül hagyható. PSH = 1 (PUSH) azt kéri a vevőtől, hogy az adatokat pufferelés nélkül továbbítsa az alkalmazásnak. RST = 1 Restart. Ha az összeköttetés összeomlott, vagy valami más rendellenesség történt, akkor tartalmaz a szegmens RST=1-et. Ha ilyet veszünk, fel kell készülni valami rendkívüli esemény kezelésére. SYN bit-nek az összeköttetés felépítésekor van szerepe. Valójában az ACK-val együttesen van értelme. Ha SYN=1, ACK=0 akkor ez valójában egy CONNECTION REQVEST kérés. A SYN=1, ACK=1 a CONNECTION ACCEPTED-nek felel meg. FIN bit az összeköttetés bontására szolgál. Az ablakméret (windows size) mező azt jelzi, hogy a nyugtában szereplő bájttal kezdődően hány bájtot küldhetünk el. Az ablakméret a csúszóablakos protokollnál tárgyaltaknak felel meg. Ez egy változó méretű csúszó ablak. A Ø hossz is értelmezett. Azt jelenti, hogy a vevő az adás felfüggesztését kéri. Az ellenőrzőösszeg (Checksum) számításába a pszeudofejrész, a fejrész és az adatmezők is beleszámítanak. Az ellenőrző összeg képzése 16 bites 1-es komplemens összeadással történik. Az adatmezőt, ha nem páros számú bájtot tartalmaz, páros számúra egészítjük ki. A kapott összeg 1-es komplemensét véve kapjuk az ellenőrző összeget. A vevő oldalon elvégezve az összeadást a teljes szegmensre 0-t kell kapnunk. Az opciók (Options) mezőt elsősorban a vevő által elfogadható legnagyobb TCP adatmező méretének meghatározására szokták használni. A nagy sebességű és nagy késleltetésű vonalakon a 64 Kbyte nem elegendően nagy ablak. Egy műholdas csatornában (50Mbit/sec) a 64 Kbyte továbbítása 10 msec körüli időt vesz igénybe. A vonali késleltetés minimálisan 2*270 msec a nyugta megérkezéséig. A hatásfok tehát katasztrófális. A hatásfok javítható lenne az ablak hosszának növelésével. Javaslatok vannak a nagyobb (legfeljebb 2 30 ) méretű ablak használatára. A legtöbb TCP implementáció ma már megengedi és támogatja a nagyméretű szegmensek átvitelét. 178
UDP (User Datagram Protocol) Az UDP az Internet összeköttetés nélküli szállítási protokollja. IP datagramok küldését teszi lehetővé összeköttetés létesítése nélkül. Jóval egyszerűbb mint a TCP. Használata ott célszerű, ahol egy kérésre egyetlen válasz érkezik, és a nyugtázásnak nincs jelentősége. Pl.: ha elküldünk egy ARP kérést (lásd 8.2.5), felesleges nyugtázni, mert ha megkaptuk a választ, akkor a nyugta nélkül is biztos, hogy a kérés célba érkezett. Ha nem, akkor egy időzítés lejárta után a kérés újbóli elküldése az egyetlen lehetséges lépés, tehát a nyugta itt is felesleges. Az összeköttetés lebontása és felépítése elmarad, a fejléc is lényegesen egyszerűbb. 32 bit 0 Source IP address Destination IP address Protocol(6) UDP segmenth lenght Pseudo header Source UDP port Destination UDP port UDP UDP Message lenght UDP Checksum header Data 8.9. ábra.udp csomag felépítése A pszeudofejrész az ellenőrző összeg számításakor beleszámít a fejrészbe. Az UDP szegmens hossz a fejrész és az adatrész együttes hosszát adja meg. A forrás és a célport a hosztokon belül azonosítja a végpontokat (szolgáltatásokat). Az UDP-t az RFC 768-ban találjuk meg részletesen. 179
8.2.7. Az Internet vezérlő protokolljai ICMP Az ICMP (Internet Control Message Protocol) Internet vezérlőüzenet protokoll az Internet felügyeletét szolgálja. Összesen mintegy tucatnyi üzenetet definiáltak. Az üzeneteket főként routerek hozzák létre. A visszhang és időbélyeg kérést indíthatja egy hoszt is. A fontosabb ICMP üzenetek: DESTINATION UNREACHABLE Cél elérhetetlen TIME EXCEEDED Időtúllépés PARAMETER PROBLEM Paraméter probléma SOURCE QUENCH Forrás lefojtás REDIRECT Újrairányítás ECHO REQUEST Viszhang kérés TIMESTAMP REQUEST Időbélyeg kérés 8.10. ábra. ICMP üzenetek A CÉL ELÉRHETETLEN üzenet akkor keletkezik, ha a router nem találja a célt, vagy ha olyan üzenetet kapott, ahol áll a DF bit, és a hálózat nem tud akkora csomagot kezelni, mint a beérkezett. IDŐTÚLLÉPÉS üzenetet akkor küld a router, ha a csomag élettartam mezője elérte a nullát. (Torlódás van, hurokba került a csomag, túl alacsony a beállított élettatam). PARAMÉTER PROBLÉMA üzenet az IP fejrész hibáját jelzi. Rendszerint valamelyik router szoftver hibája okozza. FORRÁSLEFOJTÁS üzenetet a túl sok csomagot küldő hosztok kapnak, hogy lassítsanak. Az új forgalomirányító algoritmusok nem használják. (A forgalomszabályozás a szállítási rétegben történik.) 180
ÚJRAIRÁNYÍTÁS üzenetet akkor küld a router, ha a csomag rosszul irányítottnak tűnik. (Teljesen rossz földrajzi irány.) VISSZHANG KÉRÉS és VISSZHANG VÁLASZ üzenetek egy hoszt elérhetőségének tesztelésére használhatók. Az IDŐBÉLYEG KÉRÉS és IDŐBÉLYEG VÁLASZ üzenet a hoszt elérhetőségén túl a hálózat teljesítményét is méri. Az üzenet érkezési ideje és a válasz indulási ideje is szerepel a válaszban. Az ICMP teljes definíciója az RFC 792-ben található. ARP (Adress Resolution Protocol) Minden Internetre csatlakozó gépnek van legalább egy IP címe. Az IP cím logikai cím, amit az interface hardvere nem ért meg. Az IP címeket le kell fordítanunk az adatkapcsolati réteg számára érthető fizikai címekre. Az összerendelést elvileg megoldhatnánk táblázatokkal is, de a gyakorlat számára ez túl nehézkes megoldás, és nem követi a hálózat változásait. (Bekapcsolnak, kikapcsolnak gépeket, hálózati szegmenseket,) A másik nehézség abból adódik, hogy távoli hálózatokban lévő gépeket is meg akarunk szólítani, amelyeknek a fizikai címét nem ismerjük A megoldást nézzük meg egy egyszerű hálózaton: WAN Router3 193.16.35.2 193.16.35.3 193.16.35.1 193.16.35.4 Router1 Router2 193.6.52.254 193.225.18.254 193.6.52.11 193.6.52.19 193.6.52.193 193.225.18.2 193.225.18.7 d31.pte.hu geniusz.pte.hu k19.pte.hu ETHERNET1 ETHERNET2 8.11.ábra. Összekapcsolt C osztályú hálózatok 181
Fel kell tételeznünk, hogy a küldő ismeri a cél címét. A cím egy hierarchikusan felépített szöveges elem, pl.: geniusz.pte.hu A névhez a "Domain Name System" (körzetnév kezelő rendszer) fogja visszaadni az IP címet. A példánkban 193.225.18.2-őt. (A DNS rendszer ismertetése a 8.3. fejezetben.) A küldő gép az IP cím ismeretében kiadhat az alhálózatra egy adatszórást: "kié a 193.225.18.2 cím?" Erre a magát felismerő címzett elküldi a fizikai címet, amit a kérdező eltárol és elküldi az üzenetet. A kérdés és válasz lebonyolítását végző protokoll az ARP. A protokollt az RFC 826 definiálja. Valamivel bonyolultabb a helyzet akkor, ha a küldő és a címzett nem ugyanabban az alhálózatban van. A küldő például a d31.pte.hu. Ekkor a küldő miután visszakapta az IP címet, látja, hogy a cél egy távolabbi hálózatban van. Ekkor az adatkeretet elküldi egy az alhálózaton belüli fix ETHERNET címre, a routernek az alhálózathoz csatlakozó fizikai címére. Minden, az alhálózaton kívülre címzett üzenetet ide kell küldenünk (Default router). Az IP hálózat feladata, hogy eljuttassa a megfelelő alhálózatig a csomagot. Az alhálózaton belül az ottani router fogja megkeresni a fizikai címet, és továbbítani a keretet. A hálózat minden eleme tart fenn táblázatokat, melybe a címfeloldással kapcsolatos adatokat bejegyzi. Az adatok gyors-tárba kerülnek és egy ideig megőrződnek. Ez a módszer csökkenti a hálózati forgalmat, és gyorsítja a címek megtalálását. RARP (Reverse Addres Resolution Protocol) Szükség lehet a korábban tárgyalt ARP fordítottjára is. Fizikai címhez kereshetünk IP címet. Egy diszk nélküli állomás indulásakor adatszórással megkérdezi, hogy az állomás fizikai címéhez ki tud egy IP címet. A RARP szerver kikeresi a táblázatából az IP címet, és elküldi az ismert fizikai címre. A RARP csupa 1-ből álló címet tud csak adatszóráskor megadni, tehát az adatszórás lokális. A kérést a routerek nem továbbítják. Emiatt minden alhálózaton kell lenni egy RARP szervernek. Nem biztos, hogy minden alhálózatban van szerver, és ha nincs, a megoldás nem működik. A probléma megkerülésére használják a BOOTP 182
protokollt. Ez UDP üzeneteket használ, amit a routerek továbbítanak, és nem szükséges minden hálózati szegmensben egy RARP szerver. A RARP definícióját az RFC 903, a BOOTP részleteit az RFC 951 írja le. 8.3. DNS (Domain Name System) Körzeti névkezelő rendszer. A hálózati eszközök bináris címeket ismernek. A legtöbb ember számára az értelmes nevek, vagy rövidítések is sokkal jobban megjegyezhetők, mint a bináris címek. Szükség van tehát a kétféle ábrázolásmód kölcsönös megfeleltetésére. Maguk a nevek is gondot okoznak, hiszen az azonos nevek okozta konfliktusok csak valamilyen központi nyilvántartással, vagy hierarchikus rendszerrel oldhatók meg. A hierarchikus megoldás nagyszámú cím esetén nyilvánvalóan egyszerűbb, és működőképesebb megoldás. Egy tipikusan hierarchikus cím a lakcímünk is. A legtöbb faluban, városban van Petőfi utca. Ennek ellenére könnyen kiválaszthatjuk, hogy melyikről van szó, ha szerepel a helység neve is a címzésben. Az egyes elemeket ponttal elválasztva az alábbi alakja lehetne a címnek: név.házszám.utca.város.ország Hasonló az Internet címzése is, a DNS névtér. 8.3.1 DNS névtér Az Internet a lehetséges címek halmazát néhány száz elsődleges körzetre (domain) bontja. Minden körzet további alkörzetekre bontható, egészen addig, míg a fa leveleiként eljutunk a hosztokig. A legfelső szinten lévő elsődleges körzetek kétfélék lehetnek: általános körzetek országok Az általános körzeteket az USA-n belül használják a különböző szervezetek megkülönböztetésére. Ilyenek a com (kereskedelem), edu (oktatási intézmények), mil (USA fegyveres erői), org (non-profit szervezetek), stb. 183
A felosztást az ISO 3166 tartalmazza. A körzetek egy névtelen gyökérhez kapcsolódnak. A hierarchikus felépítésből adódóan névkonfliktusok földrajzilag kis területen, egy alkörzeten belül fordulhatnak elő, és ott könnyen megoldhatók. Általános Országok com int edu gov mil org.. hu de nl.. hp yale pte axelero tu-bs cs eng mit ktk cs adm bib ai mi-oktat k-229 ibr robots schoenw new golem 8.12. ábra. DNS névtér A körzetnevekben a kisbetűs és nagybetűs írásmód között nincs különbség. A névkomponensek maximális hossza 63 karakter. A teljes útvonalnév rövidebb vagy egyenlő 255 karakterrel. Minden körzet maga ellenőrzi az alatta lévő körzeteket, így elkerülhető egy végtelen méretű központi nyilvántartás létrehozása. Egy új körzet létrehozását az a körzet engedélyezheti, ahova tartozni fog. Az elnevezések a szervezeti hierarchiához igazodnak, nem követik a hálózat fizikai felépítését. 8.3.2 Erőforrás nyilvántartás A név-ip cím megfeleltetésen túl is van szükség adatokra az Internet üzemeltetéséhez. Minden körzethez tartozik egy erőforrás rekord halmaz. Szélsőséges esetben az erőforrás bejegyzés lehet egyetlen IP cím, ha egyetlen gép van a körzetben, de számos más bejegyzés is létezhet. Egy általános erőforrás rekord: Körzet_név Élettartam Osztály Típus Érték Az erőforrás rekordok ASC II formátumban tárolja a Domain Name Server. 184
A Körzet_név azt a körzetet jelenti, amihez a rekord tartozik. A legtöbb esetben egy körzethez sok rekord tartozik. Az adatbázisban a zóna ( több körzet, részletesebben 8.3.3.fejezet) adatai szerepelnek, és a körzet_név az elsődleges kulcs. Az Élettartam mező a bejegyzés stabilitására utal. A legmagasabb érték 86400, ami egy nap másodpercekben kifejezve. Azt mutatja, hogy az adott rekord meddig marad a cache-tárban. Az instabil bejegyzések rövid ideig maradnak a cache-tárban. A "rövid idő" 60 másodperc körüli értéket jelent. Az Osztály a hálózattípusokat különbözteti meg. Az Internethez tartozó információknál, tehát majdnem mindig "IN". A Típus mező az információ jellegére utal. A legfontosabb típusok: SOA a lista kezdete A zónához tartozó névsorról tárol információkat, az adminisztrátor e-mail címét, egy egyedi sorozatszámot, jelzőket és időzítők értékeit adja meg. Az A(ddres) egy 32 bites IP cím egy hoszthoz. MX tartalmazza a körzethez tartozó levelek fogadására alkalmas gépek nevét. A név előtt egy sorszám van, ami a kézbesítési sorrendet jelöli. Elsőnek az 1-es számú gépnek próbálja meg az e.-mail-ek továbbítását. Ha nem működik, akkor a 2-es számú gépnek, és így tovább, amíg van levelező szerver a listán. NS névszerver rekord A névfeloldás működéséhez minden DNS adatbázis tárol az összes elsődleges körzet DNS szerveréhez egy rekordot, és további névszerverek adatait is tárolhatja. A névfeloldás részletesebb vizsgálatánál látni fogjuk ennek szerepét. CNAME bejegyzések álneveket takarnak. Ha megváltozik a körzetnevünk, akkor célszerű a régi nevet álnévként megadni. Korábban a PTE-en belül használtuk a PMMF alkörzetet is. Ha megadjuk a CNAME rekordot, akkor a régi nevén is meg fogják találni a hosztot. Például: almos.pmmf.pte.hu 86400 IN CNAME almos.pte.hu PRT álnév egy IP-címhez 185
HINFO hoszt leírás. A számítógép típusára és az operációs rendszerre utal. TXT szöveges leírás. A számítógépek nem használják, csak az emberek számára teszi olvasmányosabbá az állományt. Érték mező tartalmazhat számot, vagy ASCII karakterláncot. Néhány példa a bejegyzésekre: Az atlas.pte.hu egy szerver, a K_32401 pedig egy munkaállomás. Ez egy részlet az adatbázisból.... atlas.pte.hu 86400 IN HINFO IBM UNIX atlas.pte.hu 86400 IN A 193.225.18.2 atlas.pte.hu 86400 IN MX atlas.pte.hu K_32401.pte.hu IN A 193.225.18.61 IN MX atlas.pte.hu IN HINFO IBM windows A K_32401 gép bejegyzéséből látszik, hogy közvetlenül nem fogad leveleket, a létrehozott levelező fiókoknak szóló üzenetek az atlas.pte.hu gépen fognak tárolódni. Az elsődleges körzetek adatai nem szerepelnek az adatbázisban. Ezeket egy konfigurációs fájl tartalmazza, ami a DNS szerver indításakor betöltődik a gyorsító tárba. A fájl szerkezete hasonló, mint az egyéb erőforrás bejegyzések. $ORIGIN RootServerInfo @SOA server.root. (1997082000 3600 604800 86400) 3600000 NS A.ROOT-SERVERS.NET. 3600000 NS B.ROOT-SERVERS.NET. 3600000 NS C.ROOT-SERVERS.NET.. ; formerly NS.INTERNIC.NET A.ROOT-SERVERS.NET. 3600000 A 198.41.0.4 ; formerly NS1.ISI.EDU B.ROOT-SERVERS.NET. 3600000 A 128.9.0.107. ; housed in Japan, operated by WIDE M.ROOT-SERVERS.NET. 3600000 A 202.12.27.33 186
8.3.3 Név szerverek (Domain Name Servers) Tisztán logikailag az egész névtérnek egyetlen DNS szervere is lehetne, ahol a teljes adatbázist tároljuk. Ez a megoldás sem a hálózati forgalom, sem a biztonság, sem az adminisztráció szempontjából nem elfogadható. A névteret ezért egymást át nem fedő zónákra osztják. Egy zónában több név szerver van a megbízhatóság növelése érdekében. A zónában egy elsődleges, és egy vagy több másodlagos név szerver van. A másodlagos név szerverek másolatai a primer név szervernek. Módosításokat csak a primer név szerveren lehet végrehajtani. A módosítások automatikusan másolódnak a másodlagos szerverekre. Szerepük a terhelés megosztása, és a biztonság növelése. Egy a zónához tartozó név szerver lehet a zónán kívül is. A zónahatárok kijelölése a zóna adminisztrátortól függ. A terheléselosztás és a menedzselés szempontjai a meghatározók. Általános Országok com int edu gov mil org.. hu de nl.. hp yale pte axelero tu-bs cs eng mit ktk cs adm bib ai mi-oktat k-229 ibr robots schoenw new golem 8.13.ábra. DNS névtér egy része a zónák jelölésével A példánk pte.hu részletében a pte zóna ellátja a ktk-t is. A "mit" azonban önálló név szervert üzemeltet. (A példák csak az elvet szemléltetik, nem hitlesek!) Ha egy címfeloldó szeretne tudni valamit egy körzetnévről, akkor elküldi a kérdést egy helyi név szervernek. Ha a körzet az adott szerverhez tartozik, akkor az visszaküldi a hiteles erőforrás bejegyzéseket. A hiteles bejegyzés (authoritative record) azt jelenti, hogy a bejegyzés attól a szervertől származik, amelyik a bejegyzést kezeli. A gyors-tárban lévő adat lehet elavult, ez az adat a diszkről származik. 187
A kérdések azonban távoli körzetekre is irányulhatnak, és ekkor a folyamat bonyolultabb. A lekérdezés alapvető típusai a 8.14. ábrán láthatók. A rekurzív lekérdezéses módszernél a szerver ha nem rendelkezik megfelelő információval a célról, továbbadja egy másik szervernek, amíg eléri a hiteles bejegyzést. A példában andi.pte.hu fordul a lokális szerverhez, az a "hu" elsődleges körzet szerveréhez. A "hu" ismeri a bme.hu címét, és ez a szerver hitelesen tárolja a peter.bme.hu címét, visszakapjuk a hiteles bejegyzést a peter.bme.hu gépről. Az iteratív lekérdezésnél ha a lokális keresés sikertelen, akkor annak a szervernek a címét kapjuk vissza, ahol a legközelebb próbálkozhatunk. Ennél a módszernél az andi.pte.hu elsőnek a "hu" szerver címét kapja vissza. A hu szervertől megkapja a bme.hu címét, ami rendelkezik a peter.bme.hu hiteles bejegyzésével. Recursive Query root Name Server Iterative Query root Name Server 2(Q) 5(R) hu 4(R) 3(Q) hu 3(Q) 4(Rfr) Name Server pte.hu 1(Q) 6(R) bme.hu Name Server (authoritative) Name Server pte.hu 2(Rfr) 1(Q) 5(Q) bme.hu Name Server (authoritative) 6(R) andi.pte.hu peter.bme.hu andi.pte.hu peter.bme.hu 8.14. ábra. Alapvető DNS lekérdezési formák 188
root Name Server ceg.hu NS (intermediate) Cache 3(Q) 4(Rfr) 5(Q) tu.de NS (intermediate) Cache Q= Query R= Response Rfr= Referral data base 8(R) data base 2(Q) 9(R) 6(Q) 7(R) Cache data base reszleg.ceg.hu NS (local NS) Cache data base cs.tu.de NS (authoritative) Cache data base 1(Q) 10(R) teve.reszleg.ceg.hu andi.cs.tu.de Kérdés: mi az IP címe az andi.cs.tu.de hosztnak? 8.15. ábra. Rekurzív és interaktív keresés együttes használata Távoli címek keresésénél a két módszer kombinációja hatékony (8.15.ábra). A teve.reszleg.ceg.hu hosztról keressük andi-t, egy német egyetem informatikai tanszékén. A cím: andi.cs.tu.de. Rekurzív kereséssel jutunk el egy root szerverhez. A ceg.hu szerver ismeri a de primer körzet név szerverének címét (betöltötte a konfigurációs fájlból), ahonnan megkapja a tu.de szerver címét (interaktív keresés). A tu.de rekurzívan megkeresi a cs.tu.de szervert, ahonnan megkapja a hiteles bejegyzést. Ha végiggondoljuk a keresés lépéseit, belátható, hogy ezzel a módszerrel terheljük legkevésbé a nagy forgalmú nemzetközi hálózatot. 189