Az "Internet" napjainkban nem egy technológia a sok közül, hanem önálló életre kelt, a társadalmat befolyásoló eszköz

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.

Pandur B: Számítógép hálózatok. 2004-2013

167

Web browser e-Mail

Other user Applications USER space

Application protocols: HTTP,SMTP,FTP,DNS.. Applications Application Programming Interface (API)

Network ARP

UDP

TCP

Transport ICMP

OS kernel RIP

IP

RARP

Data Link

FDDI

WAN technology

LAN technology

Ethernet

8.2.ábra. TCP/IP protocol stack 8.1. A működés modellje 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. Gyakorlatban elképzelhetetlen egy olyan táblázat, ami a világ összes hosztját tartalmazza a hozzá vezető optimális útvonallal együtt. Egy részhálózatról azonban elképzelhető, hogy pontosan ismert minden tulajdonsága, és ez az ismeret felhasználható a legjobb útvonal meghatározására. Léteznek természetesen olyan útvonalak is, melyeket előre, pontosan meghatároznak a forrástól a célig. 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.


168

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. Az útválasztás folyamatát a 8.4 fejezetben tárgyaljuk. 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.


169

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 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. Pandur B: Számítógép hálózatok. 2004-2013

170

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 daraboltuk volna fel. A célállomás a fel nem darabolható csomagok egymás közötti sorrendjével foglalkozik csak.


171

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). 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. Pandur B: Számítógép hálózatok. 2004-2013

172

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. 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


173

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ímosztályoknak az információ továbbítása során is fontos szerepe van. 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

Hálózat

0

B

C

D

E

10

1.0.0.0-tól 127.255.255.255-ig

Hoszt

Hálózat

110

Hálózat

1110

11110

128.0.0.0-tól 191.255.255.255-ig

Hoszt

Hoszt

Többesküldési cím

Jővőbeni alkalmazásokhoz fenntartva

192.0.0.0-tól 223.255.255.255-ig 224.0.0.0-tól 239.255.255.255-ig 240.0.0.0-tól 255.255.255.255-ig

8.5. ábra IP címosztályok. 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.


174

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 Egy HOST-ot egyértelműen azonosít az IP cím. Ha ez igaz, akkor mi szükség van a címosztályokra? Egyszerűsíti és gyorsítja a csomagok irányítását. A helyi hálózatból kilépve az eszközök csak a célhálózat elérésével foglalkoznak. A hoszt cím célhálózaton belüli értelmezésére csak a fogadóoldali router után van szükség. A címnek a hálózati cím része a címosztályt jelző bitek alapján leválasztható, és a csomagirányításhoz csak ezt a részt kell használni. 8.2.4. Alhálózatok . A nagyszámú géppel rendelkező felhasználó hamar szembe kerül azzal a problémával, hogy az adminisztráló szervezettő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) 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


175

Alhálózat IP cím 193.221.15.32 193.221.15.63

Hálózat címe 110 00001 110 00001

11011101 11011101

00001111 00001111

Hoszt cím 001 00000 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 Decimálisan:

11111111

11111111

11111111

111 00000

255.255.255.224

Példa: alhálózati cím leválasztása a 193.221.15.41 címből 110 00001 ÉS 11111111 = 110 00001 Az alhálózat címe:

11011101

00001111

001 01001

11111111

11111111

111 00000

11011101

00001111

001 00000

193.221.15.32

8.6. ábra. Alhálózat címzése Az alhálózati maszkot valójában a router használja. A kérdés az, hogy egy bejövő üzenetet melyik kimenetre továbbítja az eszköz. Ha C osztályú címünket 8 db 32 címet tartalmazó részre osztottuk, mint a példánkban, akkor ez azt jelenti, hogy a bejövő üzeneteket 8 alhálózati szegmens felé tudjuk irányítani. A maszkban az utolsó nyolc bit 1110 0000. Ennek decimális értéke 224 . A maszk hatására az 1-es portra kerülnek 0-31 végződésű címek, a 2-es portra 32-63 végződésű címek, és így tovább. A router kimenetén a teljes cím információ megjelenik. A maszk azt dönti el, hogy melyik kimenetre kerül a csomag. Az alhálózatból érkező csomag esetén a router azt tudja eldönteni , hogy a célcím az alhálazaton belül, vagy kívül van. Ha célcím az alhálózaton belül van, akkor routernek nincs tennivalója, nem továbbítja a csomagot. Ha nem az adott alhálózathoz tartozó forráscímet tartalmazó csomagot kap, azt szintén nem továbbítja.


176

Maszk Cím

255.255.255.224 11111111 ÉS 193.225.11.15 11000001 11000001

11111111 11111111 111 00000 11011101 00001111 000 01111 11011101 00001111 000 00000 A csomagot az 1-es portra továbbítja

Maszk Cím

255.255.255.224 11111111 ÉS 193.225.11. 36 11000001 11000001

11111111 11111111 111 00000 11011101 00001111 001 00100 11011101 00001111 001 00000 A csomagot az 2-es portra továbbítja

Maszk Cím

255.255.255.224 11111111 ÉS 193.225.11.152 11000001 11000001

11111111 11111111 111 00000 11011101 00001111 100 11000 11011101 00001111 100 00000 A csomagot az 5-ös portra továbbítja

Ha a tartományt csak 2 részre szeretnénk osztani, akkor a HOST címből egy bitet kell csak elvennünk. A maszk utolsó 8 bitje ekkor 1000 0000. A teljes maszk decimálisan 255.255.255.128. 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 címtartományokat nyilvántartó hivatalhoz kellene kellene fordulnia. CIDR (Classless Internet Domain Routing (RFC 4632) A valós világban ma „A” vagy „B” osztályú címhez jutni gyakorlatilag lehetetlen. A „C” osztályú címek túl kevés hoszt egységes kezelését teszik lehetővé a hálózatokat üzemeltető cégeknek. A nagy hálózatokat szolgáltató szervezetek (Internet Service Provider, ISP) működtetik, és a protokollok tervezésénél ezt figyelembe kell venni. A CIDR a gyakorlati igényekhez jobban alkalmazkodó címzési séma, mint a cím-osztályos megoldás. A CIDR rendszerben a hálózat-azonosító a cím bármekkora része lehet. A hálózati cím hosszát az un. CIDR prefix határozza meg. Az előtagot szokás változó hosszúságú alhálózati maszknak (Variable Length Subnet Mask, VLSM) is nevezni. A CIDR általánosítja az alhálózati címzési rendszert. Tizes számrendszerben megadott címeknél a címet jelölő számsor után, egy „/” jelet követően adjuk meg a hálózati címet tartalmazó bitek számát. Ezzel a módszerrel Pandur B: Számítógép hálózatok. 2004-2013

177

egyszerűsíthető egy „C” osztályú hálózat alhálózatának megadása is. Megadhatunk 24-nél nagyobb bitszámot is. Egy 25 bites hálózati cím pl.:198.223.18.191/25 CIDR formátum megfelel a 193.225.18.191 címnek, 255.255.255.128 alhálózati maszkkal. A maszk utolsó bájtja 10000000 binárisan, tehát a 25. bittel végzett hálózati címet leválasztó ÉS művelet nem befolyásolja a cím 25. bit tartalmát, ami az alhálózatot jelöli ki (Két részre osztottuk a „C” osztályú címtartományt. A cím 25.-dik bitje 0 vagy 1 lehet). A két címtartomány: 193.225.18.1

- 193.225.18.126/25

Broadcast: 193.225.18.127/25

193.225.18.129- 193.225.18.254/25

Broadcast: 193.225.18.255/25

A CIDR lehetővé teszi az egymást követő „C” osztályú címtartományok összevonását is egy logikai címtartománnyá. A CIDR előtag azt jelenti más megközelítésben, hogy a címek hány bitje azonos egy logikai csak, ha a címtartomány folytonos. Nem folytonos címtartományok is kiszolgálhatók ezzel a technológiával. Ilyenkor mindegyik tartományt meghirdeti a tartomány kiszolgáló. A hálózat a leghosszabban illeszkedő prefix felé fogja továbbítani a csomagokat. Egy B osztályú címen belül (pl.193.225.18.0/20) . A megoldás igazi előnyeit az INTERNET szolgáltatók szerint felépített modelljében fogjuk látni, ahol a szolgáltató cégek hierarchikusan kapcsolódnak egymáshoz, és kis szolgáltatók egy-egy zárt csoportot szolgálnak ki. 8.2.5 Címblokkok kiosztása Egy zárt, saját tulajdonú hálózatban olyan IP címeket használunk amilyet akarunk. A saját címek megválasztásánál is célszerű az ajánlásokban szereplő címtartományokat betartani, mivel ezek a címeket nem adják ki publikus IP címként. A privát IP címek soha nem jelenhetnek meg a publikus interneten. Ha ki akarunk lépni az internetes világba, akkor regisztrált és engedélyezett címekre van szükségünk. A címek adminisztrációját korábban a NIC (Network Information Center) végezte. 2007 óta az ICANN (Internet Corporation for Assigned Names and Numbers) utalja ki a cím - tartományokat. A tényleges címkiosztást regionális címnyilvántartó hivatalok (Addres Supporting Organization ICANN).) végzik. Jelenleg öt régió van meghatározva. Az EU-ban a RIPE NCC (Réseaux IP Européens Network Coordination Centre) a regionális hivatal. Jelenleg (2013) Magyarországon a HUNGARNET jogosult címtartományok engedélyezésére. A 2009-ben elfogadott módosítások (pl. díj ellenében tetszőleges zárótag alkalmazható a szövegesen megadott címben) nehezen kezelhető helyzetet hoztak létre. Sze-


178

rencsére az alkalmazók nem éltek ezzel a lehetőséggel, és a címzési rendszer stabil maradt. (lásd :Domain Name Server fejezet): 8.2.6 Hoszt címek kiosztása A hosztoknak a hálózatban egyedi azonosítóval kell rendelkezni, hogy egyértelműen azonosíthassuk őket. A hálózati eszközök egy részéhez a rendszergazda fix IP címeket rendel, az intézménynél rendelkezésre álló címtartományból. Az eszközök egy másik csoportjához dinamikusan rendelünk IP címet a tartományból. A dinamikus IP cím az üzemeltetők számára számos szempontból előnyös:  ha nincs minden felhasználó állandóan a hálózatra kapcsolódva, akkor több felhasználót tudunk kiszolgálni azonos méretű címtartománnyal;  azonos névkiszolgálóhoz tartozó alhálózatok között lehet „barangolni”, nem kell újra konfigurálni a hosztot (lehetővé tehetjük például, hogy az egyetem területén belül lehessen barangolni az alhálózatok között). Különösen hasznosnak tűnő tulajdonság ez a rádiós hálózatoknál, ahol eleve arra számítunk, hogy a felhasználók mozognak, és csak rövid időre kapcsolódnak egy-egy alhálózathoz. A hoszt-címek kiosztásának automatizálására fejlesztett protokoll a DHCP, Dynamik Host Configuration Protocol (RFC 2131). A DHCP automatizálja az IP címek kiosztását. A DHCP konfigurációjától függően egy host kaphat  fix IP címet  minden bejelentkezéskor új címet  meghatározott ideig állandó címet  lehetőség szerint állandó címet. A „lehetőleg állandó” azt jelenti, hogy nem írjuk felül, ha van még kiosztható IP címünk. Ha változik a hoszt IP címe, akkor ezt az útvonalon található valamennyi forgalomirányító eszköznek be kell jegyezni az új címet a saját táblázataiba. Tehát „olcsóbb”, az IP címek állandóságára törekedni. A DHCP egy kliens-szerver protokoll, ahol a kliens az újonnan csatlakozó hoszt, és van valahol egy DHCP szerver. Ha a DHCP szerver az alhálózaton belül van, akkor kliens egy adatszórásos üzenettel megtalálhatja a szervert. Ha az alhálózaton kívül van,akkor további lépésekre van szükség. A hoszt nem ismeri az alhálózat címét


179

amiben saját maga van, nem ismeri a DHCP szerver IP címét, de még a sajátját sem, hiszen ez után fogja megkapni. Ha a DHCP szerver más alhálózatban van, akkor szükség van egy olyan eszközre, ami ismeri az alhálózathoz tartozó DHCP szerver címét. Ezt a szerepet (DHCP relay agent) gyakran egy útválasztó látja el. (RFC1542 kompatibilis útválasztók). A kapcsolódás lépései:  DHCP szerver felderítése A belépő eszköz generál egy DHCP felderítés üzenetet, a 67-es portra; saját címként 0.0.0.0. címet tüntet fel.  A válasz egy „DHCP ajánlat üzenet” (DHCP offer message). Az üzenet tartalmazza a tranzakció azonosítóját,kliens számára ajánlott IP címet, az alhálózati maszkot, és az IP- cím bérleti időt (address lease time, vagyis az érvényesség idejét. A DHCP szerver ismerheti a kérést küldő fizikai címét, így elvileg egyes-küldéses keretben tud válaszolni. Ez felel meg a http://tools.ietf.org/html/rfc1541 ajánlásnak. A gyakorlati esetek többségében a DHCP szerver nem a kérést küldő gép alhálózatában van, így szükség van egy DHCP továbbító ügynökre. Az ügynök ismeri a DHCP szerver címét. A DHCP ügynök és a DHCP ügyfél ugyanabban az alhálózatban van, a válasz üzenetszórásos is lehet (nem az ajánlásnak megfelelő megoldás). Egyes megvalósítások csak az üzenetszórásos változatot tartalmazzák. Egy kérésre több DHCP szerver is válaszolhat, amiből a kliens választhat.  DHCP kérés A kliens az ajánlat-üzenetre egy DHCP kérés üzenettel (DHCP request message) válaszol.A válasz tartalmazza az üzenetből kimásolt, kliens által kért paramétereket. A válasz RFC1541 szerint üzenetszórásos, hogy azok a DHCP szerverek, melyeknek az ajánlatát nem kéri a kliens, a címet felszabadíthassák. A valóságban nem minden kliens küld üzenetszórásos választ. Az igénybe nem vett címek ilyenkor egy időzítés után szabadulnak fel. 

DHCP nyugtaüzenet (DHCP ACK message) A szerver DHCP nyugtaüzenettel válaszol, és megerősíti a paramétereket.


180

A DHCP megoldás automatizálja a címkiosztást, ezzel sok gondot megold. Hátrányai is vannak azonban. Ha barangolunk az alhálózatok között (kezünkben egy tablettel átmegyünk egy másik alhálózatba) akkor a TCP kapcsolatok megszakadnak. A rádiós hálózatoknál a mobil-IP oldja meg a problémát, ahol az alhálózatok közötti váltásnál az IP címünk állandó maradhat. 8.2.7 Hálózati címfordítás (Network Address Translation, RFC 2663,RFC 3022) A hálózaton lévő valamennyi IP-t támogató eszköznek rendelkeznie kell IP címmel. A kisméretű hálózatok egyszerű adminisztrációja és az IP címekkel való takarékoskodás egyaránt azt sugallja, hogy egy alhálózatot tudjunk egyetlen IP címmel üzemeltetni. Ha egy otthoni hálózatot bővíteni akarunk, akkor ne kelljen a szolgáltatóhoz fordulnunk további IP címekért. Ha az alhálózati címek kiosztására van automatizálási lehetőség (DHCP), akkor vélhetően ez a feladat is megoldható. A megoldás a NAT. A NAT fogalmát az irodalom meglehetősen önkényesen használja. Az RFC 2663 több altípust különböztet meg aszerint, hogy a kapcsolat jellege egy az egyhez ( oneto-one),

több az egyhez (many-to-one). Egy az egyhez kapcsolatra akkor van szükség, ha címzési szempontból inkompatibilis hálózatokat kapcsolunk össze, vagy a privát hálózat egyes gépeit közvetlenül címezhetővé akarjuk tenni a külső hálózatról. Ezt nevezi az ajánlás NAT-nak, vagy statikus NAT –nak. A használt további kifejezések: NAPT (network address and port translation), cím és port fordítás. Hasonló értelemben használt kifejezések: PAT (port address translation) IP masquerading, IP elfedés; NAT Overload (CISCO konfigurációs állományokban); many-to-one NAT. Valamennyi kifejezés több az egyhez kapcsolatot jelöl, és általában ezt szokás egyszerűen NAT-nak nevezni. Az alhálózat a külvilág felé általában egyetlen IP címmel rendelkezik. Ha van több statikus NAT cím is, akkor minden ilyen belső címhez tartozik egy további külső, WAN oldali cím is. A belső, privát címek nem jelennek meg a nyilvános interneten. A statikus NAT általában biztonsági célokat szolgál. A külvilág és a belső un. privát hálózat között elhelyezkedő útválasztó kívülről nem útválasztónak, hanem egyetlen Pandur B: Számítógép hálózatok. 2004-2013

181

(+ a statikus NAT címek) eszköznek tűnik. A privát hálózatok számára fenntartott címtatományok: 10.0.0.0/8 172.16.0.0/12 192.168.0.0/16 A több az egyhez működés azon alapul, hogy az útválasztó az egyes kapcsolatokhoz port-számot is hozzárendel, és a hozzárendelést a NAT címfordító táblában tárolja. A külvilág felé egyetlen IP cím jelenik meg, ahonnan különböző port-számokról indítanak folyamatokat. Elvileg a 16 biten leképezhető , mínusz a foglalt portok számú kapcsolat hozható létre. A portszám kiválasztása véletlenszerű, de nem lehet un. „ismert port”, vagy használatban lévő port sem. Példaként tételezzük fel, hogy 193.225.18.29 szerver 80-as portjáról akarunk egy WEB oldalt lekérni. A kérést előállító gép 10.0.0.2 belső címmel rendelkezik. A kliens a kérést önkényesen pl.: 4301 porton továbbítja. A NAT útválasztó önkényesen kijelölheti a külvilág felé a kérést előállító portszámot, pl.: 5002. A kérés elküldésekor az útválasztó a saját WAN oldali címét és az 5002-es portszámot tünteti fel a kérésen, mikor 193.225.18.29:80 –as címhez fordul. A beérkező válaszhoz megkeresi a NAT címfordító táblában az 5002-es bejegyzéshez tartozó belső IP címet és portszámot. Sokan bírálják a NAT-os megoldásokat, mivel több hálózatos alapelvet is sért a megoldás (végponttól-végpontig elv, a port cím folyamatokhoz rendelt és nem hoszt címzésre való,…). Problémát akkor jelent a NAT, ha az alhálózatba szervert szeretnénk üzemeltetni,ami a „jól ismert port”-számokon várja a kéréseket. A NAT zavarja a P2P hálózatok működését, mivel a NAT mögött lévő eszköz nem tud szerverként működni. A probléma megkerülhető az un. NAT áthidalás alkalmazásával. Igazi megoldás az alkalmazás szintű átjárók (Gateway) használata (pl.: SKYPE átjátszók), vagy áttérés az IPv6 protokollra. Más megközelítése a problémának, amikor a privát hálózat és a külvilág közé olyan eszközt telepítünk, ami több publikus IP címmel rendelkezik. A privát hálózat éppen aktív hosztjai egy az egyhez kapcsolattal csatlakozhatnak a külvilághoz. A lehetséges egyidejű kapcsolatok száma a publikus IP címek számával egyezik meg.


182

UPnP (Universal Plug and Play) protokoll A protokoll a NAT áthidalására létrehozott eszköz. A működés feltétele, hogy mind a hoszt, mind az útválasztó implementálja a protokollt, mindkettő UPnP kompatibilis legyen. Az alapgondolat az, hogy az útválasztó által meghirdetett portszámot az alkalmazás határozza meg, ne az útválasztó. Ez lehetővé teszi, hogy az alkalmazás meghirdesse az elérhetőségét. Az alkalmazás tehát azt kéri az útválasztótól, hogy hozzon létre leképzést a privát IP cím, privát portszám és egy nyilvános IP cím, nyilvános portszám között. Ha ez megtörtént a hálózaton lévő csomópontok képesek lesznek TCP vagy UDP kapcsolat kialakítására. Pl.: egy BitTorrent alkalmazás meghirdetheti a nyomkövetőjének (tracker , a résztvevő partnerek nyilvántartása), hogy milyen publikus címen érhető el. Legyen a BitTorrent alkalmazás privát címe 10.0.0.2:4301. Az útválasztó publikus címe 193.93.41.9. Az alkalmazás által választott port 5201. Az alkalmazás azt kéri, hogy az útválasztó feleltesse meg (írja be a NAT táblájába) 193.93.41.9:5201 és a 10.0.0.1:4301 megfeleltetést, hirdesse meg 193.93.41.9:5201 címet. A külső hosztok most már kezdeményezhetnek kapcsolatot (küldhetnek TCP SYN szegmenst tartalmazó csomagot) a NAT mögötti hosztnak. A megoldás hatékony , és megbízhatóan működik. A NAT azonban számos biztonsági és megvalósítási problémát takar, (DNS szerver bejegyzések a NAT mögött üzemelő kiszolgálókról, biztonsági kérdések,kapcsolat a hitelesítő szerverekkel) melyek tárgyalása túlmutat a félév anyagán. Sok hasznos ismeretet találhatunk az „upnp.org” fórumon, vagy a CISCO NAT fórumon is. Irodalom: http://www.cisco.com/en/US/docs/security/asa/asa82/configuration/guide/asa82cfg.pdf, Routing with NAT -Part of the documentation for the IBM iSeries

8.2.5. Az IP új generációja: IPv6 A fejlesztés céljai: 

Nagyszámú hoszt támogatása (>1012 )



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


183



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.

Az IPV6 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 magyarországi mérföldkövei ( Idézet Wikipedia szócikkből) 

A BME Folyamatszabályozási Tanszékén már 1997-ben folytak kutatások a IPv6 hálózatok kiépítésének tesztelésére.



A NIIF által üzemeltetett és fejlesztett felsőoktatási és kutatói hálózaton 2001ben kezdődtek meg az IPv6-os kísérletek és 2005 óta szolgáltatásként elérhető az IPv6 az egyetemek, kutatóintézetek és közgyűjtemények számára.



Az Externet 2009. május 19-én zárta le a közel egy éves tesztidőszakot és azóta nyújtja rendes szolgáltatásként az IPv6-ot.



A Magyar Telekom 2009. november 2-án kezdte meg hálózatában az IPv6 nyilvános tesztelését.[5][6]



A Magyar Telekom 2011. június 3-án kapcsolta be az IPv6 hálózatát.

Az IPv6 előnyei a végfelhasználó számára 

Az IPv6 amellett, hogy a jelenlegi dinamikus IP-cím kiosztás helyett minden végfelhasználó kaphat egy fix IP-címet, a biztonság terén is hoz újításokat a jelenleg használt IPv4-hez képest. A 128 bites címtartomány több ezer milliárd eszköz számára biztosíthat IP-címet, így gyakorlatilag kimeríthetetlen a kapacitása. Lefordítva ezt a háztartásokra, az otthonokban minden internetképes eszköz önálló IP-címet kaphat, így azok zavar nélkül kommunikálhatnak egymással. Ha az eszközök az internethez kapcsolódnak, akár a fűtőberendezéseket vagy a mosógépet is bekapcsolhatjuk mobiltelefonunkon keresztül.



Sokan magát az IPv6-ot tekintik „killer application”-nek, mint ami megteremti a hálózatcentrikus világ létrehozásának lehetőségét. Ideális esetben az IPv6 használata a végfelhasználó számára láthatatlan marad. Az egyetlen változás,


184

hogy az internetezés egyes esetekben egyszerűbbé válhat, illetve megjelennek majd olyan szolgáltatások/alkalmazások melyek IPv4 alapon csak igen bonyolult módon lennének nyújthatóak. Az IPv6 a végfelhasználó szempontjából egy ajtó, mely megteremti a lehetőséget a változásra. Éppen úgy, mint ahogyan anno a vezetékes világban a DSL, vagy a mobil világában a 3G megjelenése indított el egy-egy kommunikációs forradalmat.

IPv6 szabványok és migrációs stratégiák [szerkesztés] Az IPv6-ra vonatkozó, annak alapvető működését rögzítő szabványok az IETF szervezetében születnek.[10] Ugyanakkor érdemes nyomon követni más szabványosítási szervezetek munkáját is, hiszen fontos irányelveket fogalmaznak meg például a Broadband Forum (BBF) munkacsoportjai, melyek a meglévő szabványokon alapuló szolgáltatói környezet tekintetében rögzítenek ajánlásokat.[11] Az IPv6-bevezetési megoldások tekintetében számos eltérő – a szabványosítás különböző fázisában lévő – metódus látott napvilágot (pl. 6to4, 6rd, DS-lite, Softwire, Carrier Grade NAT, stb.). Az egyes megoldásoknak természetesen eltérő előnyei ill. hátrányai vannak, így folyamatos vitatémát biztosítanak a szakértők számára. Egyetértés van azonban a tekintetében, hogy a felhasználók számára egyidejűleg kell mind IPv4, mind IPv6 kapcsolódást biztosítani. Az ilyen megoldást nevezik dualstack elérésnek. A dual-stack[12] megoldás egyik fő előnye, hogy nincs szükség IPv4 és IPv6 hálózati átjárók létrehozására, melyek segítségével a csak egyik vagy másik verziót támogató végpontok kommunikálni tudnának egymással“ 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


185

32 bit

verzió

prioritás Adat mező hossza

folyamatcímke Következő fejrész

Átugrás korlát

Forrás címe (16 byte)

Cél címe (16 byte)

 8.7.ábra. IPv6 fejrész A verzió mező az IPv4-nél mindig 4, az IPv6-nál mindig 6. A prioritás mezőben a 0-7 értékek olyan alkalmazásokhoz tartoznak, melyek képesek lassítani egy esetleges torlódásnál. A 8-15 értékek real-time folyamatokhoz tartoznak. Ezek az alkalmazások akkor sem lassítanak, ha minden csomag elvész. (Élő beszéd, mozgókép). Az alkalmazás szintjén természetesen más a helyzet. Egy videó átvitelnél esetleg tudom rontani a képpontok számát, a színmélységet, a képváltások számát, stb. Ez azonban nem a hálózat feladata, és nem is tudja befolyásolni. Mindkét csoporton belül az alacsonyabb szám alacsonyabb prioritást jelent. A folyamatcímke címke a virtuális áramkörök előnyei próbálja „becsempészni” a datagram típusú rendszerekbe. Az összeköttetést a forrás és célcím, valamint a folyamatcímke együttesen azonosítja. Ez lehetővé teszi, hogy több folyamat legyen aktív egy időben két IP cím között. Az egyes címkékhez különleges elbánást is rendelhetünk a routerekben , ami hasonló hatású lehet, mint a virtuális áramkörök létrehozása. Az adatmező hossza a tényleges adatmező hosszát jelöli, nem számolják bele a 40 byte hosszú fejrészt ( IPv4-nél bele számít!). A következő fejrész azt mutatja , hogy milyen további opcionális fejrészek vannak a csomagban, ha vannak. Az opcionális fejrész bevezetése tette lehetővé a kötelező fejrész jelentős egyszerűsítését. A kiegészítő fejrészek az 

átugrási opciókra



forgalomirányításra



darbolásra


186



hitelesítésre



titkosítottságra



cél opciókra

vonatkozhatnak. Az átugrás korlát itt valóban az ugrások számát jelöli , nem tartalmaz időt. A címek 16 byte, azaz 128 bit hosszúságúak. A címmező rossz kihasználása esetén is belátható ideig elég a címtartomány. Az IPv6 - ból kimaradt az ellenőrzőösszeg, ami jelentősen csökkenti a routerek terhelését, és a felettes rétegeket sem terheli túlságosan az ellenőrzés a mai, viszonylag megbízható fizikai réteg felett.


187

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.


188

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

Source IP address Destination IP address Protocol(6) TCP segmenth lenght

0

Source TCP port Destination TCP port Sequence number Acknowledgement number Hdr.l. Flags Window size Checksum Urgent pointer Options Data

Pseudo header

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: Pandur B: Számítógép hálózatok. 2004-2013

189

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 hoszszának növelésével. Javaslatok vannak a nagyobb (legfeljebb 230) 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. Pandur B: Számítógép hálózatok. 2004-2013

190

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

Source UDP port UDP Message lenght Data

Destination UDP port UDP Checksum

Pseudo header

UDP header

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.


191

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.)


192

Ú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: W AN Router3 193.16.35.2 193.16.35.3 193.16.35.1 Router1 193.6.52.254

193.6.52.11 193.6.52.19 d31.pte.hu ETHERNET1

193.16.35.4 Router2 193.225.18.254

193.6.52.193

193.225.18.2 193.225.18.7 geniusz.pte.hu k19.pte.hu ETHERNET2

8.11.ábra. Összekapcsolt C osztályú hálózatok


193

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 ?" Az adatszórás természetesen ETHERNET szintű, tehát fizikai cím szerinti adatszórás. A kérés tartalmazza a kérdező gép fizikai címét is. A magát felismerő címzett eltárolja a kérő fizikai címét, majd elküldi a saját fizikai címét a kérdezőnek (a kérésből ismeri annak a fizikai címét) amit a kérdező eltárol és elküldi az üzenetet. Látnunk kell, hogy az ETHERNET alhálózatban a keretek csak fizikai címekre küldhetők. 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.


194

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 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


195

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. 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. Root szerverek

Á lta lá n o s

com

in t

edu

hp

gov

m il

o rg … ..

ya le cs

O rs zá g o k

p te

eng

ai

m it m i-o k ta t

k -2 2 9

hu

de

a x e le ro

tu -b s

k tk

cs ib r

ro b o ts

adm

n l… … ..

b ib schoenw

new

g o le m

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.


196

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. 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


197

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 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

atlas.pte.hu

86400

IN

A

193.225.18.2

atlas.pte.hu

86400

IN

MX

atlas.pte.hu

IN

A

193.225.18.61

IN

MX

atlas.pte.hu

IN

HINFO

IBM

K_32401.pte.hu

UNIX

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 Pandur B: Számítógép hálózatok. 2004-2013

198

A.ROOT-SERVERS.NET.

3600000

A

198.41.0.4

3600000

A

128.9.0.107

A

202.12.27.33

; formerly NS1.ISI.EDU B.ROOT-SERVERS.NET. …………………. ; housed in Japan, operated by WIDE M.ROOT-SERVERS.NET.

3600000

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

com

int

Országok

edu

hp

gov

mil

org…..

yale cs

pte

eng

ai

mit mi-oktat

k-229

ktk

hu

de

axelero

tu-bs cs

adm

ibr robots

nl……..

bib 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!) Pandur B: Számítógép hálózatok. 2004-2013

199

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. Egy a gyors-tárban lévő adat lehet elavult is , de ez az adat biztosan meg fog egyezni a diszken tárolt adattal, hiteles. 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

Iterative Query

root Name Server 3(Q)

hu

2(Q) 5(R)

root Name Server hu

3(Q)

4(R)

Name Server

Name Server (authoritative) pte.hu

bme.hu

Name Server

Name Server (authoritative) pte.hu 2(Rfr)

1(Q)

6(R)

4(Rfr)

5(Q)

bme.hu

1(Q) 6(R)

andi.pte.hu

andi.pte.hu peter.bme.hu

peter.bme.hu

8.14. ábra. Alapvető DNS lekérdezési formák Pandur B: Számítógép hálózatok. 2004-2013

200

root Name Server

3(Q) ceg.hu NS (intermediate)

4(Rfr)

tu.de NS (intermediate)

5(Q)

Cache

Cache

8(R)

data base

2(Q)

data base

1(Q)

data base

6(Q)

9(R) reszleg.ceg.hu NS (local NS)

Cache

Q= Query R= Response Rfr= Referral

Cache

7(R)

cs.tu.de NS (authoritative)

data base

10(R)

Cache data base 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, és visszaküldi a cég.hu szervernek, ahonnan eljut a teve.reszleg.ceg.hu gépig. 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. A keresési típusok beállítása a Name Server-t üzemeltető adminisztrátor feladata. Belátható, hogy a jó konfiguráció jelentősen gyorsíthatja a rendszer működését, vagy egy ügyetlenebb beállítás jelentős erőforrásokat köthet le.


201

Az "Internet" napjainkban nem egy technológia a sok közül, hanem önálló életre kelt, a társadalmat befolyásoló eszköz

Recommend Documents