8. Hálózati réteg A hálózati réteg feladata, hogy a csomagokat a forrástól egészen a célig eljuttassa. Ehhez esetleg több routeren is keresztül kell a csomagnak haladnia, ill. előfordulhat, hogy egy másik hálózatba kell azt kézbesíteni. Ez a feladat láthatóan elkülönül az adatkapcsolási réteg feladatától, amely ennél szerényebb: kereteket kell továbbítania a vonal egyik végétől a másikig. E célok elérése érdekében a hálózati rétegnek ismernie kell a kommunikációs alhálózat (vagyis a routerek halmaza) topológiáját, és megfelelő útvonalat kell találnia azon keresztül. Arra is ügyelnie kell, hogy úgy válassza ki a routereket, hogy elkerülje az útvonalak túlterhelését. 8.1. Összeköttetés nélküli szolgálat megvalósítása Ebben az esetben az alhálózatba érkező csomagok egyenként és egymástól függetlenül kerülnek továbbításra; előzetes kapcsolat-felépítésre nincs szükség. Ebben az esetben a csomagokat datagramoknak is nevezzük. Ha összeköttetés alapú szolgálatot használunk, a forrás és a cél router között előre ki kell építeni egy útvonalat, mielőtt megkezdenénk a csomagok továbbítását. Ezt a kapcsolatot virtuális áramkörnek (virtual circiut, VC) nevezzük a telefonhálózat fizikai áramköreinek mintájára. Datagram hálózat esetében ha a H1 gép üzenetet szeretne küldeni a H2 gépnek, akkor először az A routerhez továbbítja. Minden routernek van egy belső táblázata, amely minden lehetséges cél esetére megadja, hogy merrefelé kell továbbítani a csomagokat. A táblázat bejegyzései olyan kettősök, amelyek a címzett router azonosítóját és a címzetthez vezető kimeneti vonal azonosítóját tartalmazzák. A router táblázata C E A- AA AC BB BA BD CC C- CC DB DD DD EC EE E- FC FE FF Csak közvetlen kapcsolatban álló összeköttetéseket lehet használni. Például az A routernek csak két kimeneti vonala van egy a B és egy a C felé így minden bejövő csomagot a két router közül valamelyiknek kell továbbítani, még akkor is, ha a címzett egy ezektől különböző router.
8.2. Összeköttetés alapú szolgálat megvalósítása Ebben az esetben szükség van egy virtuális áramkör alhálózatra. A virtuális áramkörök alapötlete az, hogy elkerülik, hogy minden egyes csomag számára újra és újra útvonalat kelljen választani. Ehelyett, már az összeköttetés felépítésekor kiválasztanak a forrás és a cél hoszt között egy utat, melyet a routerek az összeköttetés-kiépítés során tárolnak a táblázataikban. Ezt az utat használják aztán a kapcsolat teljes forgalmának lebonyolítására. Amikor az összeköttetés megszűnik, a virtuális áramkör is elbomlik. Összeköttetés alapú szolgálat esetén minden csomag tartalmaz egy azonosítót, mely megmondja, hogy a csomag melyik virtuális áramkörhöz tartozik A H1 hoszt kialakított egy összeköttetést a H2-vel, amit a táblázatok első sora tartalmaz. Eszerint ha 1-es azonosítójú csomag érkezik a H1 felől, akkor azt a C router felé kell irányítani szintén 1-es azonosítóval. Hasonlóképp, C első bejegyzése az E-hez továbbítja a csomagot, meghagyva az 1-es azonosítót. A virtuális áramkörök előnye, hogy a csomagoknak csak az áramkörszámokat kell tartalmazniuk a teljes célcímek helyett. Ha a csomagok rövidek, a minden csomagban jelenlévő teljes célcím jelentős mértékű többletet jelent. 8.3. Hálózatok összekapcsolása A fizikai rétegen a hálózatokat ismétlőkkel vagy elosztókkal (hub) köthetjük össze ezek csupán átrakják a biteket az egyik hálózatról egy másik, azonos típusú hálózatra. Az ilyen eszközök a legegyszerűbb hálózati eszközök, semmit sem tudnak a protokollokról csak újragenerálják a jeleket. Egy réteggel feljebb hidakat és kapcsolókat találunk, melyek az adatkapcsolati rétegben működnek. Ezek már kezelik a kereteket, megvizsgálják a MAC címeket, és különböző hálózatok irányába folytatnak kerettovábbítást. A hálózati rétegben vannak a routerek, melyek képesek két hálózatot összekötni, akár két különböző hálózati réteggel rendelkezőket is. Míg a kapcsoló az egész keretet a MAC cím alapján továbbítja, addig a router a csomagot kiveszi a keretből, és a csomagban található cím (pl. IP cím) alapján dönti el, hogy hová küldje a csomagot, méghozzá úgy, hogy megkeresi a forgalomirányító táblázatában a megfelelő útvonalat.
8.4. Az Internet hálózati rétege Az a ragasztó, mely az Internetet egybetartja, az IP (Internet Protocol hálózatközi protokoll). Sok régebbi hálózati rétegbeli protokolltól eltérően, ezt már a kezdetektől a hálózatok összekapcsolását szem előtt tartva tervezték. Eszköze annak, hogy az adatok a forrásgéptől a célgépig eljussanak, függetlenül attól, hogy ezek a gépek ugyanazon a hálózaton vannak-e vagy sem, és vannak-e köztük más hálózatok vagy nincsenek. 8.4.1 Az IP protokoll Az Internet hálózati rétegének tanulmányozásához jó kiindulási pont maguknak az IP datagramoknak a formátuma. Egy IP datagram egy fejrészből és egy üzenetrészből áll. A fejrész formátuma a köv. ábrán látható. A Verzió mező tartja nyilván, hogy az IP protokoll melyik verzióját használja az adott datagram. Azzal, hogy a verzió helyett kapott a datagramban, lehetségessé vált, hogy a verziók közötti átmenet évekig is eltarthasson, miközben egyes gépeken még a régi, másokon pedig már az új verzió fut. Jelenleg az IPv4 és IPv6 közti átmenet zajlik jó néhány éve, és a folyamat még korántsem közelít a végéhez. Az IHL mező adja meg a fejrész hosszát, mivel az nem állandó (van opcionális része is).
A Teljes hosszba a datagram minden része beleértendő, a fejrész és az adatrész is. A maximális hossz 65 535 bájt. A jövőben nagyobb datagramokra lesz szükség gigabites hálózatoknál. Az Élettartam mező egy számláló, amelyet a csomag élettartamának korlátozására használnak. Az ún. átugrásokat számlálja, minden átugrásnál eggyel csökkenteni kell ezt az értéket. Amikor eléri a nullát, a csomagot el kell dobni. Ez a tulajdonság megelőzi, hogy a datagramok végtelenségig kóboroljanak, ami egyébként megtörténhetne, ha a forgalomirányító táblázatokba valamikor hiba csúszna. A Fejrész ellenőrző összeg csak a fejrészt ellenőrzi. Az ilyen ellenőrző összeg hasznos a routereken belüli rossz memóriaszavak által előidézett hibák kiküszöbölésére. Vegyük észre, hogy ezt az összeget minden átugrásnál újra kell számítani, mivel legalább egy mező mindig megváltozik. A Forrás címe és Cél címe mutatja a hálózat számát és a hoszt számát. 8.4.2 IP-címek Az Interneten minden hosztnak és routernek van egy IP címe, amely a hálózat számát és a hoszt címét kódolja. A kombináció egyedi: elméletileg nincs két olyan gép, amelynek ugyanaz az IP-címe. Minden IP cím 32 bit hosszú és a Forrás cím és Cél cím mezőkben vannak elhelyezve az IP protokoll fejlécében. Fontos megjegyezni, hogy egy hosztnak annyi IP-címe lehet, ahány hálózati illesztője van. Az IP címeket több évtizeden keresztül 5 kategóriába sorolták, ezek az A, B, C, D és E osztályok. Habár az irodalom még mindig gyakran hivatkozik rájuk, ma már nem használják. Az első négy bit jelzi az osztályszámot. Az A osztályú címek 128 hálózatot és azokon belül 16 millió hosztot jelölhetnek, a B osztályúak 16 384 hálózatot és 64 ezer hosztot, a C osztályúak pedig kétmillió hálózatot 256 hoszttal. A hálózatszámokat az ICANN (Internet Corporation for Assigned Names and Numbers, Kiosztott Nevek és Számok Internet Társasága) nevű nonprofit szervezet kezeli a konfliktusok elkerülése végett. Az ICANN pedig különböző helyi hatóságokra bízta a címtér egy részét, hogy azok osszák ki az IP-címeket az internetszolgáltatóknak és más vállalatoknak.
A hálózati címeket, amelyek 32 bites számok, rendszerint pontokkal elválasztott decimális jelölésrendszerben írják. Ebben a formátumban minden 8 bájtot tízes számrendszerben írnak ki, 0-tól 255-ig, például 192.41.6.20. A 255.255.255.255 cím adatszórást tesz lehetővé a helyi hálózaton. A helyes hálózatcímmel és csupa 1-es bitet tartalmazó hoszt mezővel rendelkező címek lehetővé teszik adatszóró csomagok küldését az interneten bárhol elhelyezkedő távoli LAN-okra. Az összes 127.x.x.x formájú cím fenntartott a visszacsatolásos tesztelésre. Az erre a címre küldött csomagok nem kerülnek ki a vezetékre, hanem helyileg dolgozzák fel és bejövő csomagokként kezelik azokat. 8.5. CIDR Osztálynélküli körzetek közti forgalomirányítás Az IP-t már évtizedek óta intenzíven használják, s rendkívül jól működött. Sajnos azonban saját népszerűségének áldozata lesz: kezd kifogyni a címekből. Elméletben több mint kétmilliárd cím létezik ugyan, de a címtartomány osztályok szerinti szervezésének gyakorlata ebből milliókat elveszteget. A legtöbb szervezetnek egy 16 millió hoszttal rendelkező A osztályú hálózat túl nagy, míg egy C osztályú hálózat túl kicsi. Egy 65536 címmel rendelkező B osztályú lenne a megfelelő, a valóságban azonban a legtöbb szervezetnek még ez is túlságosan nagy, azaz jó néhány hosztcím nincs kihasználva, mivel nincs annyi hosztjuk. Ebből keletkezett az a megoldás, melyet CIDR-nek (Classless InterDomain Routing, osztálynélküli körzetek közti forgalomirányítás) neveznek. Az alapötlet az volt, hogy az IP címeket változó méretű blokkokban osszák ki, osztályokra való tekintet nélkül. Ha egy helynek pl. 2000 címre van szüksége, akkor egy 2048 címből álló blokkot kap. Ebben az esetben szükség van egy 32 bites maszk jelenlétére is, mely kimaszkolja a hálózat számát. 8.6. NAT hálózati címfordítás Az IP címek szűkös erőforrások. Ha egy internetszolgáltatónak mondjuk B osztályú címe van, akkor ezzel 65 535 darab hosztszámhoz jut. Ha ennél több ügyfele van, bajban van. Az otthoni, tárcsázós kapcsolattal rendelkező előfizetők esetében a probléma megkerülhető azzal, hogy a bejelentkező számítógép dinamikusan kap IP-címet, amit vissza is vesznek, amikor a kapcsolat véget ér. Ily módon 65 535 darab aktív felhasználó is kiszolgálható, ami egy több százezer előfizetővel rendelkező internetszolgáltató számára is elegendő. Amikor egy kapcsolat lebomlik, az IP-címet egy másik hívónak adják. Abban az esetben azonban, ha a felhasználók folyamatos on-line kapcsolatot szeretnének, minden számítógépnek egész nap szüksége van az IP-címére. Ennek
eredményeképp a szolgáltató ügyfeleinek összesen nem lehet több számítógépe, mint ahány IP-címe van a B osztályú szolgáltatónak. Az IP-címek kifogyásának kérdése nem elvi probléma. Hosszú távú megoldás az, hogy az egész Internet átáll az IPv6-ra, ami 128 bites címeket használ. Az átállás lassan megy, ezért gondolták néhányan azt, hogy egy rövid távú megoldást javasoljanak. Ez a gyors javítás a NAT (Network Address Translation hálózati címfordítás). A NAT alapötlete az, hogy az internetforgalom számára minden cégnek egyetlen (vagy legalábbis kevés számú) IP-címet osztanak ki. Egy vállalaton belül minden számítógép egyedi IP-címet kap, amit a hálózaton belüli forgalom irányításához használnak. Amikor viszont egy csomag elhagyja a vállalatot, és kimegy az internetszolgáltató felé, akkor címfordításra kerül sor. Mindezt az teszi lehetővé, hogy három IP-címtartományt jelöltek ki privát használatra. A vállalatok saját berkeiken belül úgy használják fel ezeket, ahogyan akarják. Az egyetlen kikötés az, hogy magán az interneten nem jelenhet meg olyan csomag, ami ezeket a címeket tartalmazza. A három fenntartott címtartomány: 10.0.0.0-10.255.255.255, 172.16.0.0 172.31.255.255, 192.168.0.0 192.168.255.255. A NAT működését a köv. ábra mutatja be. A vállalat határain belül mindegyik gépnek egyedi címe van, 10.x.y.z alakban. Ha azonban egy csomag elhagyja a vállalat területét, akkor áthalad egy NAT-dobozon, ami átalakítja a belső IP-forrás csomópont címét, vagyis az ábrán a 10.0.0.1-et a vállalat tényleges IP-címére, ami példánkban 198.60.42.12. A NAT-dobozt gyakran a tűzfallal együtt, egy eszközben valósítják meg, mert a tűzfal a biztonság érdekében amúgy is gondosan megvizsgálja, hogy mi jön be a vállalathoz, és mi lép ki onnan. Amikor a válasz visszaérkezik (pl. egy webkiszolgálótól), természetesen a 198.60.42.12 címre küldik. Honnan fogja ekkor a NAT-doboz tudni, hogy melyik címre cserélje ezt ki? Ebben rejlik a NAT problémája. Ha lenne még egy maradék mező az IPfejlécben, ezt felhasználhatnánk arra, hogy nyomom kövessük, ki volt az eredeti feladó. A NAT tervezői megfigyelték, hogy a legtöbb IP csomag TCP vagy UDP tartalmat hordoz. Ezen protokollok fejléce tartalmaz egy forrás port és cél port mezőt. A portok 16 bites egész számok, melyek azonosítják az adott alkalmazást a számítógépen. Ezekre a portokra lesz tehát szükség a NAT működéséhez. Amikor egy folyamat egy TCP kapcsolatot szeretne kiépíteni egy másik, távoli folyamattal, akkor hozzácsatolja magát egy addig a saját gépén nem használt TCP porthoz.
Ezt nevezzük forrás portnak (source port), és ez mondja meg, hogy hová küldje az adott kapcsolathoz tartozó bejövő csomagokat. A folyamat megad egy cél portot (destination port) is, hogy megmondja, kinek kell a csomagokat küldeni a távoli oldalon. A 0-1023-ig terjedő portokat a jól ismert szolgáltatások számára tartották fenn. A webkiszolgálók például a 80-as portot használják, így a távoli kliensek könnyen megtalálják őket. A forrás port használatával tehát megoldhatjuk a leképezési problémánkat. Amikor egy kilépő csomag eléri NAT-dobozt, a 10.x.y.z forráscímet lecseréljük a vállalat igazi IPcímére. Ezenkívül a TCP forrás port mezőt lecseréljük egy mutatóra, ami a NAT-doboz 65 536 bejegyzésből álló fordítási táblázatába mutat. A mutatott bejegyzés tartalmazza az eredeti IP-címet és az eredeti forrás portot. Végül az IP- és TCP-fejrészek ellenőrző összegeit is újraszámolják, és az eredmény beírják a csomagba. Azért kell kicserélni a forrás port mezőt, mert pl. a 10.0.0.1 és a 10.0.0.2 gépekből induló összeköttetések is használhatják ugyanazt a portot, vagyis a forrás port önmagában nem elég a feladó folyamat azonosítására. Amikor egy csomag megérkezik a NAT-dobozhoz az internetszolgáltatótól, a TCPfejrészben találhat forrás port mezőt kiveszik, és indexként használják a NAT-doboz leképezési táblázatában. Az így talált bejegyzésből kiveszik a belső IP-címet és az eredeti TCP forrás portot, és belerakják a csomagba. Ezután újraszámolják az ellenőrzőösszegeket, és azokat is beírják a csomagba. A csomagot végül átadják hagyományos továbbításra a vállalati routernek a 10.x.y.z cím használatával.