KANDÓ KÁLMÁN VILLAMOSMÉRNÖKI KAR HÍRADÁSTECHNIKA INTÉZET. Szállítási réteg vizsgálata Wireshark analizátorral. Dr. Wührl Tibor Dr.

Átírás

1 KANDÓ KÁLMÁN VILLAMOSMÉRNÖKI KAR HÍRADÁSTECHNIKA INTÉZET Infokommunikációs Hálózatok laboratóriumi mérési útmutató Szállítási réteg vizsgálata Wireshark analizátorral

2 Tartalomjegyzék A szállítási és az alkalmazási réteg protokolljainak vizsgálata2 TCP Transmission Control Protocol2 A TCP fejléc szerkezete4 Háromutas kézfogás6 UDP User Datagram Protocol9 UDP mezők jelentése10 Streamek vizsgálata Wireshark segítségével10 Mérési feladatok12 A szállítási és az alkalmazási réteg protokolljainak vizsgálata A TCP/IP protokollgyűjtemény a harmadik rétegben működő IP-re támaszkodva kínál rugalmas kommunikációs lehetőséget, amelyek implementációja a negyedik (szállítási) rétegben történik. A két leggyakoribb ezek közül a megbízható (a megbízhatóság alatt itt a sérülésmentes, sorrendhelyes, hiánytalan átvitelt értjük) átvitelt nyújtó TCP, illetve a sokkal egyszerűbb működésű UDP. Fontos, sokak által használt alkalmazások veszik igénybe a két protokollt saját kommunikációjukhoz, újabb (alkalmazási rétegben működő) protokollok épülnek rájuk. A mérés célja az, hogy a hallgatók megértsék a protokollok működését. TCP Transmission Control Protocol Az IP egy úgynevezett Best Effort jellegű protokoll, vagyis igyekszik a rábízott adatokat célba juttatni, de nem garantálja a hibamentes átvitelt, sőt azt sem, hogy a feladó az adatvesztésről egyáltalán értesül. A TCP/IP (és természetesen az OSI) modell szándékosan nem definiált bonyolultabb átvitelvezérlést a hálózati rétegbe, mivel ez a hálózati kapcsolóeszközök feladatát jelentősen megnehezítette volna. A bonyolultabb hálózati protokollhoz vagy nagyobb teljesítményű és így drágább eszközök kellenének, vagy a hálózat áteresztőképessége lenne jóval kisebb. A szállítási rétegben működő protokolloknak tehát rendelkezniük kell egy absztrakciós funkcióval, ami a magasabb rétegek felé nyújtott szolgáltatásaival elrejti a hálózati adatátvitel

3 részleteit. A TCP napjaink leggyakrabban használt szállítási protokollja, a legtöbb internetes szolgáltatás ezt használja. Meglehetősen komplex felépítésű, mivel a következő szolgáltatásokat biztosítja a magasabb rétegek számára: - Az adatok hibamentes és sorrendhelyes átvitele; - Átvitelvezérlés (Flow Control); - Egy végponton belüli párhuzamos, egymástól függetlenül és egymást nem zavarva működő adatfolyamok kezelése. Az adatok hibamentes átvitele érdekében a TCP két eljárást alkalmaz: egy, a teljes adatcsomagra kiszámított ellenőrző összeg segíti az átviteli hibák észlelését, míg a nyugtázási folyamat segítségével lehetséges a megsérült vagy elveszett adatok újraküldése. A sorrendhelyességet az átvitt adatok sorszámozása biztosítja. Elméletben a TCP minden egyes átvitt adat alapegységnek (byte) ad egy sorszámot, így a fogadó fél nyomon tudja követni a beérkezett adatokat, észlelni tudja, ha adatkimaradás történt. Természetesen nem minden átküldött byte mellé kerül egy sorszám, hanem csak a csomagok kezdetéhez. Az átvitelvezérlés segítségével a fogadó fél lassítani tudja, vagy szélsőséges esetben teljesen le is tudja állítani az adatforgalmat, így hozzáigazítva a saját erőforrásainak foglaltságához. A független adatfolyamok megvalósítására a TCP bevezette a port fogalmát. TCP használatával kommunikáló végpontok mindig jelzik a küldő oldalon értelmezett port (forrás port) és a távoli oldalon értelmezett port (cél port) számát. Egy végponton port lehet nyitva (a 16 bit méretű számábrázolás miatt), vagyis ennyi független átviteli csatorna használható (elméleti érték, az egyes implementációk ettől eltérhetnek). A portok használatára a hagyományos telefonszám és mellék analógiát lehet felhozni, a TCP/IP esetében az IP cím jelenti a telefonszámot, míg a port szám a mellék. Fontos, hogy TCP/IP esetében a kommunikációhoz mindig IP cím és port cím szükséges!

4 A TCP leírását az RFC 793 tartalmazza. Az átvinni kívánt adatok előtt egy fejléc található: 8 bit 8 bit 8 bit 8 bit Source Port Destination Port Sequence Number Acknowledgement Number Data Fenntartott Control bitek Window Offset (4) bitek (6) ( 6 bit ) Checksum Urgent Pointer Options Padding Data Az IP csomagba ágyazott TCP datagramot az IP fejléc Protocol mezőjének 6 értéke jelzi. A TCP fejléc szerkezete A TCP keret Source Port elnevezésű mezője a forrás port sorszámát hordozza. A Destination Port mezőben a cél port sorszám található. Mindkét mező 16 bites. A port azonosító feladata a végponton működő küldő- és a fogadó alkalmazás azonosítása, ennek segítségével válik lehetővé az, hogy egy végponton egy időben több különböző alkalmazás is képes legyen adatokat küldeni és fogadni. Az IP önmagában erre nem képes, hiszen az IP csomaginformációi csak a küldő és fogadó végpont IP címét tartalmazza. A port címek hasonlíthatók egy telefonszám (mint az IP cím analógiája) mögött működő mellékek azonosítójához. Ilyen módon, a következő öt paraméter egy adott időpillanatban a hálózaton bonyolított összes adatfolyamot egyértelműen azonosítani tudja: - protokoll (TCP); - forrás IP cím; - forrás port cím; - cél IP cím; - cél port cím; A szállítási réteg a megfelelő port címekhez rendelt folyamatok számára szét tudja válogatni a beérkező datagramokat. A port címeket három csoportba (kategóriába) soroljuk:

5 well-known portok, melyek fixen egy adott szolgáltatáshoz tartoznak; registered portok; dynamic/private portok. A Sequence Number mező 32 bites egész szám, a hasznos adatok kezdetének sorszáma. Kezdőértékének meghatározása a TCP kapcsolat felvételekor történik egy olyan algoritmus segítségével, ami biztosítja, hogy két, egymást követő TCP kapcsolat adatelemei ne keveredhessenek össze egymással. Ez akkor fordulhatna elő, ha egy korábbi TCP kapcsolat megszakadásáról az egyik fél nem szerezne tudomást, és rövid időn belül kezdeményezne egy újabb, ugyanolyan paraméterekkel rendelkező kapcsolatot. Ha ekkor beérkezne egy nagyobb késleltetést szenvedett, az előző kapcsolatból érkező csomag, akkor könnyen az új kapcsolat részének tekinthetnék azt a felek. Emiatt a Sequence Number kezdeti értékét (Initial Sequence Number) egy olyan képzeletbeli számlálóból kell venni, amely 4µs időközönként növeli eggyel az értékét. Mivel 32 biten valamivel több, mint 4 milliárd az ábrázolható legnagyobb egész szám, ezért ezzel a növelési ütemmel mintegy 4,5 óra alatt elérik a maximumot, ekkor a számláló nullázódik, és a folyamat kezdődik elölről. Vagyis, csak abban az esetben fordulhatna elő ugyanaz a Sequence Number érték kétszer, ha a csomag késleltetése 4,5 óra felett lenne, ezt pedig egyéb tényezők (például az IP csomag TTL mezője vagy a TCP időkorlát mechanizmusa) meggátolják. Az Acknowledgement Number mező 32 bites és a feladata a fogadott adatok nyugtázása. Abban az esetben, ha ez a mező egy visszanyugtázott Sequence Number -t tartalmaz, akkor az ACK bit 1 értéken áll. A Data Offset 4 bites mező, mely a TCP Header végét mutatja (vagyis a TCP által hordozott adatmező elejét). Ez azért szükséges, mert a TCP Header hosszúsága az Option mező miatt változhat. A Data Offset biteket 6, további fejlesztésekhez fenntartott bit követi, melyek értéke 0. A Control biteket (6 bit) a következő bitek alkotják: o URG: ha értéke 1, akkor az Urgent Pointer mező feldolgozandó értékkel rendelkezik. o ACK: Visszaigazolást jelző bit. A fogadó fél ezzel a bittel jelzi, hogy az Acknowledgment Number mezőben nyugtázó érték található. o PSH: Push funkció. Segítségével jelezhető, hogy a küldött adatokat a fogadó fél felsőbb rétegeibe kell juttatni.

6 o RST: segítségével a megnyitott TCP kapcsolat azonnal megszakítható. o SYN: a TCP kapcsolat megnyitásakor a kapcsolatot kezdeményező fél ezzel a bittel jelezheti kapcsolat felvételi szándékát. o FIN: a küldő jelzi a kapcsolat befejezésének szándékát (vételekor megindul a kapcsolat lebontása). A Window mező 16 bitből áll, segítségével jelezhetjük a fogadó eszköz rendelkezésére álló buffer méretét, vagyis itt adhatjuk meg a fogadni kész maximális adatmennyiség méretét. Jelentősége a csúszó ablakos (sliding window) nyugtázásnál van. A csúszó ablakos nyugtázás azt jelenti, hogy az adó oldalnak nem kell megvárnia azt, hogy az elküldött TCP csomagra megérkezzen a pozitív nyugta, mert ez nagyon lelassítaná a kommunikációt. E helyett az adó eszköz több csomagot küldhet el a célállomás felé (maximum annyit, amennyit a Window mező engedélyezett), melyekre a nyugta majd később fog érkezni. Amint a nyugta megérkezik az egyik csomagra, az ablak továbbcsúszik és ismét további üzenetek elküldésére van lehetőség. Másik használati célja a torlódásvezérlés: ha a fogadó eszköz valamilyen okból nem tud éppen adatot fogadni (éppen kifogyott a szükséges erőforrásból), akkor egy 0 méretű Window mezővel ideiglenesen leállíthatja az adatok küldését, majd ha ismét képes adatokat fogadni, akkor egy újabb csomaggal ismét engedélyezheti a küldést. A Checksum mező 16 bites, mely értéke, a header és a text minden egyes 16 bites szavának egyes komplemenséből képzett összeg. Az Urgent Pointer mező kizárólag akkor értelmezett, ha az URG bit 1 -ben áll. Ezen a 16 biten adható meg egy eltolási érték, mely a datagramban szereplő sürgős adatokra mutat. Sürgős adat lehet például egy megszakítási üzenet. Háromutas kézfogás A TCP kapcsolatfelvétel úgynevezett háromutas kézfogással ( Three-way handshake ) történik, melyet a következő ábra szemléltet:

7 A fenti ábrán az A állomás kezdeményezi a TCP kapcsolat kiépítést egy TCP csomag küldésével, melynek fejlécében egy x értékű (véletlen) sorszám (Sequence Number) található. Azt, hogy ez egy kiinduló érték, a fejlécben található SYN bit 1 értéke mutatja. A B állomás miután vette a csomagot, egy másik csomaggal válaszol, melyben B is megad egy kiinduló sorszámot (Sequence Number = y és a SYN bit = 1 ), valamint az Acknowledgement Number mezőben visszaküldi az előzőleg vett, A -tól kapott Sequence Number eggyel megnövelt (x+1) értékét. Miután ezt fogadta az A állomás, az is visszanyugtázza az Acknowledgement Number mezőben az y+1 értéket. A nyugtázások során, azt, hogy az Acknowledgement Number mezőben érvényes (nyugta) sorszám szerepel, az ACK bit 1 értéke jelzi. A kapcsolat során a SYN bit a továbbiakban 0 értéken fog állni, hiszen az adatküldések során a Sequence Number mező az átküldött okteteknek megfelelően inkrementálódik. A kapcsolat bontás folyamata úgy indul, hogy a bontani kívánó állomás a TCP fejléc FIN bitjét 1 -be állítja. A másik fél ezt nyugtázza (ACK-val), és nem feltétlenül szükséges, hogy a másik fél is ekkor küldjön bontási kérelmet. A következő ábrán egy olyan bontási folyamatot mutatunk be, ahol az A állomás kezdeményezi a TCP kapcsolat bontását. A teljes bontás akkor zajlik le, ha mindkét állomás a FIN bit 1 -be állításával kérte a bontást és ezt a másik fél ACK-val nyugtázta. A következő ábrán a teljes TCP állapotdiagramját tüntettük fel.

8 A fenti ábrán az állapotok elnevezése és értelmezése a következő: CLOSED LISTEN SYN RCVD SYN SENT = Nincs nyitott, vagy függő kapcsolat = Bejövő kapcsolatra vár = Kapcsolatfelvételi kérés hatására a kapcsolatfelvétel indul = Kapcsolatfelvétel kezdeményezés indult ESTABLISHED = Kapcsolat állapot (Adatátviteli állapot) FIN WAIT1 = Az alkalmazás a kapcsolat bontását kezdeményezte FIN WAIT1 = A másik fél egyetért a kapcsolat bontással TIMED WAIT = Várakozás a csomagok kihalására CLOSING = Szimultán kapcsolatbontási kísérlet CLOSE WAIT = Másik oldalról a kapcsolatbontást kezdeményezték

9 LAST ACK = Utolsó ACK-ra vár Az előző ábrán a CLOSED állapotot kétszer tüntettük fel, de ez ne zavarjon senkit, hiszen ugyanarról az állapotról beszélünk. Az, hogy kétszer jelent meg az ábrán, az csak rajztechnikai kérdés és az átláthatóságot segíti. UDP User Datagram Protocol Vannak olyan alkalmazások, ahol a TCP által nyújtott szolgáltatások nem szükségesek, sőt, károsak is lehetnek. Ilyenek elsősorban a real-time alkalmazások, ahol több problémát okoz az adatok késleltetésének változása, mint esetlegesen néhány csomag elvesztése. A VoIP telefonok esetében a felhasználó könnyebben elviseli a másik fél hangjának rövid ideig tartó megszűnését, mint azt, hogy a hang késleltetése megnő. Ezekben az esetekben kifejezett hátrányt jelent a TCP csomagokat újra elküldő mechanizmusa. Ez indokolja a TCP egy jelentősen leegyszerűsített változatának létét, ami valójában az IP kiegészítése a TCP-nél alkalmazott forrás- és célport címekkel valamint a hibafelfedést szolgáló ellenőrző kóddal. Az UDP az IP-hez hasonlóan nem garantálja a csomagok sorrendhelyességét, ezt a feladatot a magasabb rétegekben működő folyamatoknak kell elvégezniük. A Datagram a csomagkapcsolt hálózaton továbbított olyan adatcsomag, amelynek érkezési sorrendje, vagy egyáltalán, a megérkezése a célállomáshoz, nem garantált. Az UDP összeköttetés-mentes protokoll, így az ezzel küldött csomagok a hálózatban duplikálódhatnak, el is veszhetnek, és a csomagok érkezési sorrendje sem minden esetben egyezik a csomagok küldési sorrendjével. Az UDP keretet a következő ábrán tüntettük fel: Source port address (2 byte) Destination port address (2 byte) Length (2 byte) Checksumm

10 (2 byte) Data UDP mezők jelentése A Source port address 16 bites és a küldő, forrásalkalmazás (source) portjának száma. A Destination port address 16 bites és a fogadó alkalmazás portjának sorszámát hordozza. A Length mező 16 bites. Az UDP csomag payloadjának hossza változó lehet, az aktuális hosszt itt kell megadni. A hossz indikátor magába foglalja a fejléc hosszát is! A legrövidebb UDP csomag hossza (amely payload-ot nem tartalmaz) 8 byte. A Checksum mező 2 byte méretű, segítségével a csomag tartalmának megsérülése fedezhető fel. Használata opcionális. Abban az esetben, ha az ellenőrző összeg nem kerül kiszámításra, akkor ezt a mezőt 0-nak kell hagyni. Streamek vizsgálata Wireshark segítségével A Wireshark alkalmas arra, hogy egy TCP vagy UDP adatfolyamot azonosítson, és a kommunikáció tartalmát szöveges vagy egyéb formátumban megjelenítse. Ehhez egyszerűen meg kell keresni az adatfolyam egy tetszőleges csomagját, majd a jobb egérgombbal lehívható menüben a Follow menüpontban a megfelelő protokoll kiválasztásával megtekinthető a folyam. A Wireshark különböző színekkel jelöli meg a küldő és a fogadó fél által generált adatokat, így könnyen azonosíthatók a szerepek. A formátum alapértelmezetten ASCII, de átváltható Unicode (UTF-8 vagy UTF-16) illetve hexadecimális kijelzésre is, sőt, akár egy C programnyelvben felhasználható definíció is készíthető.

11 Az ábrán egy HTTP/1.1 protokollnak megfelelő kérés-válasz kommunikáció látható, nyers változatban.

12 Mérési feladatok 1. Rögzítse egy http kérés folyamatát. A laborban, a IP címen található szerver tartalmaz egy Apache webkiszolgálót, így alkalmas a feladatra. Nyissa meg a webböngészőt (Mozilla Firefox), majd a címsorba írja be a szerver IP címét. Az IP címre szűrve azonosítsa a TCP stream elemeit. Tanulmányozza a háromutas kézfogás csomagjait, a kapcsolat bontásának elemeit. 2. Elemezze az egyes HTTP kérések és válaszok főbb tulajdonságait. 3. Válasszon ki egy tetszés szerinti weboldalt, majd a Wireshark segítségével rögzítse a kommunikációt. Keresse meg és elemezze az oldal lekérés teljes folyamatát (beleértve a névfeloldás folyamatát is)! Határozza meg a válaszoló DNS szerver IP címét, majd szűrje le a kérés-felelet párosokat! 4. Ismételje meg az előző mérést, de a címet használva. Vizsgálja meg a TCP folyamot! Milyen sajátosságok tapasztalhatók? (Port cím, kérések, válaszok). 5. Kezdeményezzen DNS kéréseket egy tetszőleges domain névre, rögzítse a csomagokat Wireshark segítségével és vizsgálja meg azokat (kérés-felelet módja, használt szállítási protokoll)! a. Nyisson egy terminált, majd a következő paranccsal kérje le a DNS bejegyzést: nslookup -debug -type=any uni-obuda.hu b. Szűkítse a lekérést a domain MX (mail exchanger) rekordjára: nslookup -debug -type=mx uni-obuda.hu c. A Linuxos számítógép névfeloldó mechanizmusa helyett használjon külső névszervert! Ismételje meg az előző két pontot úgy, hogy megad egy külső névszerver IP címet (például a címen elérhető Google névszervert): nslookup -debug -type=any uni-obuda.hu d. Milyen különbségeket tapasztal?