Ősz 2017 UNIVERSITAS SCIENTIARUM SZEGEDIENSIS UNIVERSITY OF SZEGED Department of Software Engineering Számítógép-hálózatok 9. gyakorlat ICMP, DHCP Jánki Zoltán Richárd S z e g e d i T u d o m á n y e g y e t e m
Tartalomjegyzék Bevezetés... 3 ICMP... 3 Feladata... 3 Megvalósítása a TCP/IP architektúrában... 3 Ismertebb ICMP üzenetek... 4 DHCP... 5 Feladata... 5 DHCP konfiguráció... 5 DHCP működése... 5 Gyakorlati háttér... 7 Ping... 7 Ping példa... 7 Traceroute... 9 Traceroute példa... 10 DHCP parancsok... 12 Ellenőrző kérdések... 15 Források... 15 2
Bevezetés Ezen a gyakorlaton két újabb protokollal ismerkedünk meg, melyek segítségével még jobban elmélyedhetünk a hálózatban résztvevő eszközök kommunikációjának és IP-címzésének témakörében. Mindkét protokoll még mindig a TCP/IP architektúra szerinti Hálózati rétegben található, nevezetesen ők lesznek az ICMP (Internet Control Message Protocol) és a DHCP (Dynamic Host Configuration Protocol) protokollok. ICMP Feladata Az ICMP csomagokat a host-ok és a router-ek képesek indítani (akik rendelkeznek IP-címekkel), és ezekben a csomagokban hálózati rétegbeli információkat közölnek egymással az eszközök. A protokoll leggyakoribb alkalmazása az ún. hiba jelentés (error reporting). Például, tfh. indítunk egy HTTP kérést a kliensünkkel, azonban válaszként egy hibát kapunk: "Destination network unreachable." Ez a hibaüzenet az ICMP-ből származik. Miért is? Ez tipikusan olyan hiba, amikor egy router nem képes megtalálni a cél alhálózatot, amelyben az elérni kívánt host van. Ilyenkor a router előállít egy ICMP csomagot a megfelelő hibaüzenettel, és visszaküldi a HTTP kérést küldő host-nak (azaz a kliensünknek). De ez nem az egyetlen alkalmazási módja. Megvalósítása a TCP/IP architektúrában Sokan az ICMP-t az IP protokoll részének tekintik, azonban a TCP/IP architektúra szerint ez mégis fölötte található, egész pontosan az IP payload részt tölti ki (akárcsak a TCP vagy az UDP szegmensek), lásd: 1. ábra. 1. ábra ICMP protokoll beágyazódása Az ICMP üzenetek tartalmaznak egy Type és egy Code mezőt. A Type mezőben specifikáljuk, hogy milyen típusú ICMP üzenetről van szó, a Code mező segítségével pedig a típuson belül altípusokat különböztetünk meg. Az alábbi táblázat néhány ismertebb ICMP típust nevez meg (2. ábra). 3
2. ábra ICMP üzenet típusok Ismertebb ICMP üzenetek Ahogy az fentebb tárgyaltuk, az ICMP üzenetek tartalmaznak egy Type és egy Code mezőt, melyek egyértelműen meghatározzák az üzenet "mondanivalóját". A leggyakrabban előforduló típusok a 0-s és 8-as számmal ellátott echo reply és echo request üzenetek. Ezek tulajdonképpen a közismert ping parancs hatására állnak elő. A pingelési folyamat közismert, kérés-válasz interakción alapszik. Egy host vagy router megpingel egy másik host-ot vagy router-t. Aki kezdeményez, az bocsájt ki egy echo request (8) üzenetet, ha eljut a fogadó félhez, azt feldolgozza, majd válaszol egy echo reply-jal (0). Egy igen érdekes megfontolást takar a 4-es Type értékkel ellátott üzenet. Ennek a neve source quench, amely a torlódásokat hivatott szabályozni. A működési elve szerint egy túlterhelt router képes volt küldeni egy 4-es típusú ICMP-t a küldő host-nak, mellyel az átvitel mértékét egy alacsonyabb számra korlátoztatta. Erre azonban tanultunk egy elegánsabb megoldást a TCP témakörében (MSS), a szállítási rétegben. Gyakorlatban nagyon ritkán használt megoldás az ICMPvel végzett torlódáskezelés. A 3-as típussal jelölt üzenetek mindegyike sikertelen ICMP csomag kézbesítés eredményeként jönnek létre. Ezeket jellemzően a router-ektől kapjuk, amelyek nem találják azt a hálózati eszközt vagy hálózati komponenst (alhálózatot), amellyel mi kapcsolatba szeretnénk lépni. Ezeket soroljuk a "Destination unreachable" kategóriába. Érdekesség: Az IPv6-os címek bevezetésével megoldást kellett találni az ICMP üzenetek megvalósításához is, így készültek ICMPv6-os üzenetek, melyekkel számos új típus definiálásra került. 4
DHCP Feladata A címkiosztást eddig csak manuális megoldásokkal vizsgáltuk, azaz mi "pötyögtük be" egyesével, hogy az egyes host-ok és router-ek milyen IP-címeket vegyenek fel a különböző interfészeken. Ez kis hálózatok esetén könnyen kivitelezhető, és talán nincs is értelme az automatizálásnak. Azonban nagy méretű topológiák esetében a statikus IP-címkiosztás igen komoly fejtörést okozhat a rendszergazdák számára. Erre a problémára ad egy kényelmes megoldást a DHCP (Dynamic Host Configuration Protocol) protokoll, melyet magyarul automatikus címkiosztásnak is neveznek. DHCP konfiguráció A rendszergazdák a router-ek IP-címeit jellemzően statikus módon adják meg, ezzel azokat fixálják, így például az átjáró állandó. Viszont az azonos alhálózatban levő host-ok már automatikus címkiosztással kapnak IP-címeket, azaz DHCP-vel. A DHCP lehetővé teszi, hogy egy host automatikus felvegyen magának egy IP-címet. Az, hogy melyik IP-címet veszi fel az adott host, az konfiguráció kérdése. Lehetőség van arra is, hogy egy host a hálózathoz csatlakozáskor mindig ugyanazt az IP-címet kapja meg, de lehetőség van ún. temporális IP-címekkel is dolgozni, amelyek mindig felszabadulnak, ha a host lecsatlakozik a hálózatról. A DHCP-vel elérhető, hogy akár egy IPcímhez tartozó specifikus maszk is hozzárendelődjön az interfészhez, akár az átjáró címe is vagy akár egy lokális DNS-szerver címe is. DHCP működése A DHCP - hasonlóan a korábban tanult protokollokhoz - egy kliens-szerver protokoll. A kliens a hálózathoz újonnan csatlakozó host lesz, a szerver pedig egy ún. DHCP szerver. A legegyszerűbb esetben, mint alhálózatban található egy ilyen DHCP szerver. (Amennyiben mégsem, olyankor egy ún. DHCP relay-agent az (jellemzően egy router), aki ismeri a DHCP szerver címét (3. ábra)). 3. ábra DHCP szerver relay-agent-tel megvalósítva 5
Példánkban a legegyszerűbb esetet vizsgáljuk, azaz amikor van az alhálózatban egy DHCP szerver (nincs szükség relay-agent-re). Az automatikus címkiosztás 4 lépésből áll (lásd: 4. ábra). 1. lépés: DHCP szerver felderítés Az újonnan érkező kliensnek meg kell találnia a DHCP szervert. Ezt egy UDP kapcsolaton keresztül valósítja meg a kliens, mégpedig egy beágyazott DHCP felderítő üzenetet (DHCP discover message) küld a 67-es portra. (A yiaddr mező a "your IP address"-re utal.) Ki a cél? Erről nincs információnk, még arról sem, hogy melyik alhálózatban található. Épp ezért kiküldi az üzenetet egy szórásos címre (255.255.255.255), amelyet mindenki meg fog kapni, és elküldi a yiaddr mezőben a 0.0.0.0-t (azaz még nem kapott IP-címet). 2. lépés: DHCP szerver ajánlás(ok) A DHCP szerver fogadja a szórásos címre küldött üzenetet, és válaszol egy DHCP ajánló üzenettel (DHCP offer message). Ismét felmerül a kérdés, hogy kinek küldje el? Ő is a szórásos címet választja (255.255.255.255), de a port szám, amelyre küldi az üzenetet az a 68-as. Az ajánló üzenet már tartalmazza a kínált IP-címet (223.1.2.4), tranzakciós azonosítót (hogy a kliens meg tudja különböztetni, hogy mely DHCP szerver válaszolt, ha esetleg több is van az alhálózatban), illetve egy Lifetime mezőt, mely az IP-cím érvényességének idejét határozza meg. Ez az érvényességi idő jellemzően több óra vagy akár nap is szokott lenni. 3. lépés: DHCP kérés A kliens fogadja az ajánlatot (vagy ajánlatokat, ha többet is kapott), és választ. A választás egy DHCP kérés üzenettel (DHCP request message) rögzítődik, melyet visszaküld ismét a szervernek, de itt már ismert a szerver helyi IP-címe. Ebben rögzítődik a konfiguráció. 4. lépés: DHCP ACK A szerver fogadja a kérést, és visszaválaszol egy DHCP ACK üzenettel (DHCP ACK message), mellyel megerősíti a kért paramétereket. Amikor a kliens megkapja a DHCP ACK üzenetet, a 4 lépéses folyamat véget ért, és felveheti a felkínált és elfogadott IP-címet a rögzített időtartamra. Előfordulhat természetesen, hogy a kliens a határidőn (Lifetime) túl is szeretné a címet használni. Erre egy ún. "megújító" (renew) mechanizmust kínál a DHCP protokoll. 6
Gyakorlati háttér A következőkben megvizsgáljuk azokat az operációs rendszerbeli programokat, amelyekkel generálhatunk ICMP üzeneteket, és megnézzük, hogy a Wireshark milyen csomagadatokat jelenít meg. Ping A pingelés egyfajta tesztelésként szolgál a hálózatban. Segít abban, hogy a hálózat különböző komponensei, és azon belül az egyes host-ok elérhetőek-e a pingelő eszköz számára. A legtöbb TCP/IP implementáció közvetlenül támogatja a pingelést az operációs rendszerben. Az interneten számos forráskód elérhető a ping kliens programhoz. Ping példa Teszteljük a ping parancs működését és kimenetét! A pingelés legegyszerűbb kivitelezése az, ha nyitunk egy Parancssort (Windows alatt) vagy Terminált (Unix rendszereken), és kiadjuk a ping utasítást. A parancs szintaxisa igen egyszerű: ping [-option] destination Ez a ping általános paraméterezése. A parancsot követően megadhatunk különböző opciókat, valamint fontos, hogy minden esetben meg kell adnunk a célállomás nevét/ip-címét. Ha több állomást szeretnénk megpingelni, akkor az állomások listáját kell megadnunk. Az alábbi táblázat egy útmutatást ad az opciók használatára a teljesség igénye nélkül egy-egy példával. Opció Megnevezés Példa -t A megadott állomás folyamatos pingelése megszakításig (CTRL+C) ping -t www.google.com -n [number] Egy állomás irányába indított ICMP üzenetek száma ping -n 10 www.google.com -S [source address] Előfordulhat, hogy több interfésszel is rendelkezik a gépünk (pl.: vezeték nélküli és Ethernet), és szeretnénk specifikálni, hogy melyikről indítsuk a ping-elést ping -S 192.168.0.1 www.google.com -4 IPv4-es címek használatának kikényszerítése ping -4 www.google.com Indítsunk ICMP üzeneteket a kanadai Macleans magazin web-szervere felé (www.macleans.ca)! 7
4. ábra ping parancs futtatása parancssorban Eredményképp megkaptuk a web-szerver IP-címét, az egyes csomagokra mennyi időn belül érkezett válasz, illetve végül egy teljes statisztikát a pingelési folyamatról. A web-szerver IP-címe: 77.234.72.18 Átlagos válaszidő: 12 ms Veszteség: 4/0 (0%) Tekintsük meg a Wireshark monitorozás eredményét is! 5. ábra Wireshark ping info Láthatjuk, hogy a ping-elés következtében ICMP echo request és echo reply típusú üzenetek mentek keresztül az interfészünkön. A ping-elés indításakor a host-unk indított egy echo requestet, válaszként pedig a web-szerver egy echo reply-t küldött. Nézzük meg az összetartozó kérés-válasz csomagok részleteit! 8
6. ábra ICMP Echo Request részletek (ping) 7. ábra ICMP Echo Reply részletek (ping) Nem meglepő módon a korábban vizsgált táblázatban leírt kódok megtalálhatóak a részletes csomaginformációk között. Az 5. ábrán szereplő csomag az első ICMP kérés volt, így a Type mezőben 8-as szerepel, a Code mezőben pedig 0. A 6. ábrán a válasz csomag látható, melyben a Type mezőben 0 található, és a Code is 0. Van azonban egy nagyon meglepő jelenség, amelyhez kicsit körültekintőbben meg kell vizsgálnunk a csomagot. Az IP-címek specifikálva vannak, azonban a portok sehol sem láthatóak. Mi lehet ennek az oka? Ha visszaemlékszünk a jegyzet elején tárgyaltakra, akkor elmondhatjuk ismét, hogy az ICMP üzenetek a hálózati rétegbeli információkat hivatottak hirdetni. Mivel az ICMP üzenetek típusa és kódja egyértelműen meghatározza az üzeneteket, így nincs szükség az ICMP csomagok átirányítására a megfelelő alkalmazási rétegbeli folyamatokhoz. A Sequence number mezőkben levő értékek összetartozó kérés-válasz esetén mindig megegyeznek. Traceroute A traceroute program segít abban, hogy végigmenjünk azon a "nyomvonalon", amelyen egy tetszőlegesen elindított csomag végighaladna. Eszközről eszközre léphetünk végig a hálózaton, megvizsgálva azt, hogy hány "ugrásra" található a cél, milyen eszközökön és komponenseken kellett keresztülmenni, illetve hiba esetén hol akadhat el az üzenetküldés. Itt is előkerülnek az ICMP üzenetek, azonban egy picit mégis eltér a ping-től. A traceroute a forrás eszköznél hagyományos IP datagram-ok sorozatát állítja elő a cél eszköz IP-címével. Minden ilyen datagram-ba beágyazásra kerül egy UDP szegmens egy valószínűtlen UDP port számmal. A datagram-ok közül az első rendelkezik egy 1-es TTL-lel (Time-To-Live), a második 2-es TTL-lel, a harmadik 3-assal, és így tovább. (Megjegyzés: a Time-To-Live mezőben szereplő érték mondja meg, hogy egy TCP/UDP kapcsolat legfeljebb meddig maradjon nyitva (másodpercekben), ha nincs rajta aktív forgalmazás. Az 1, 2, 3, stb... számok a lépések számával ekvivalensek). A forrás eszköz a 9
kiküldésekkel egyidejűleg egy-egy időzítőt is elindít. Amikor az n-edik datagram megérkezik az n- edik router-hez, akkor az n-edik router észleli, hogy a TTL lejárt, így a csomagot eldobja. Az eldobást követően pedig válaszol a traceroute-ot indító host-nak egy 11-es típusú ICMP üzenettel (TTL expired). Ebben a válasz üzenetben benne van az említett n-edik router neve és IP-címe. A válasz alapján a traceroute-ot indító host képes meghatározni a csomag oda-vissza megtett útjához szükséges időtartamot az időzítő segítségével, valamint az n-edik router nevét és IP-címét az ICMP csomag alapján. Jogosan vetődhet fel az alábbi kérdés: honnan tudja a forrás (küldő), hogy hány IP datagram-ot kell kiküldenie? Mivel folyamatosan növeljük a TTL értékét, így biztosak lehetünk abban, hogy előbb-utóbb egy csomag (és onnantól mindegyik) képes eljutni a célállomásig. Az viszont már képes válaszolni hagyományos echo reply üzenetekkel. Traceroute példa A traceroute folyamat - hasonlóképp a ping-hez - az operációs rendszer szintjén meg van valósítva, így parancssorból ez is elérhető. A szintaxis igen hasonló: tracert [-option] destination Néhány opciót és annak jelentését példákkal itt is megvizsgáljuk! Opció Megnevezés Példa Meghatározhatjuk a maximális -h [max hop] ugrások számát (hány állomáson engedjük meg, hogy tracert -h 10 www.google.com keresztülhaladjon a csomag) -4 IPv4-es címek használatának kikényszerítése tracert -4 www.google.com Indítsunk egy nyomkövetést (traceroute-ot) ugyanúgy a kanadai Macleans magazin web-szervere felé! 8. ábra tracert parancs futtatása parancssorban 10
Látható, hogy itt is megkapjuk a web-szerver IP-címét, továbbá alapértelmezés szerint 30 ugrást kezel a tracert parancs. (Ez az érték természetesen felüldefiniálható a táblázatban szereplő -h opcióval.) Az útvonalkövetés 7 lépésből eljutott a cél web-szerverhez, ami azt jelenti, hogy 5 különböző másik állomáson ment keresztül a csomagunk. 1. lépés: saját router-em IP-címe (azaz a hálózatom átjárója) (192.168.0.1) 2. lépés: Digi egy privát alhálózata (10.0.0.1) 3. lépés: Digi egy másik privát alhálózata (10.1.129.65) 4. lépés: Digi szolnoki központja - itt már globális címmel dolgozunk (94.21.3.13) 5. lépés: Digi budapesti központja - mely összeköttetésben áll a szolnokival (94.21.3.6) 6. lépés: Digi másik budapesti központja (94.21.3.140) 7. lépés: Kanadai web-szerver IP-címe (94.21.255.200) (Most ezzel elárultam, hogy Digi-nél van internet előfizetésem... :).) Ami még érdekes lehet, de nem túl magától értetődő, az a lépésenkénti 3 szám egymás mellett msban megadva. Minden echo request üzenet az adott TTL számmal 3-szor kerül kiküldésre, ezeknek az RTT (round-trip-time) értékei láthatóak, azaz mennyi idő alatt érkezett meg a válasz. Nézzük meg a Wireshark monitorozás eredményét (9. ábra)! 9. ábra Wireshark tracert info A monitorozást vizsgálva láthatjuk - hasonló módon a parancssorhoz -, hogy minden (adott TTLlel ellátott) csomag 3-szor került elküldésre. A válaszok mindig az aktuális router-től érkeznek vissza, amelyiknél a TTL lejárt. Az üzenet pedig egy újabb ICMP csomagba kerül beágyazásra, mégpedig, hogy a TTL lejárt. TTL=1 esetében egy lépést tesz meg a csomag, ez épp a saját router-emnél lesz, és annak az átjárója válaszol. Ez elküldött echo request-et összehasonlítva a ping-nél küldöttel megállapíthatjuk, hogy nincs eltérés a Type és a Code mezők tartalmát tekintve. A válasz azonban annál izgalmasabb, ugyanis egy új Type - Code páros kerül elő, ez pedig a Type=11, Code=0 (lásd: 10. és 11. ábra). A traceroute végén megtalálhatjuk a célba érésért járó 4 elemű echo request - echo reply sorozatot. 11
10. ábra ICMP Echo Request részletek (tracert) 11. ábra ICMP TTL-Exceeded részletek (tracert) DHCP parancsok Amint az elméleti részben tárgyaltuk, a DHCP protokoll egy 4 lépéses folyamatot valósít meg. Ahhoz, hogy egy kliensen ezt a 4 lépést monitorozni tudjuk, egy új alhálózatra kellene csatlakoznunk, ahol van DHCP szerver. Ez nem olyan egyszerűen kivitelezhető, de szerencsére vannak manuális megoldások. A lépéseket követően beszéltünk a címek megújításáról (renew). Nem csak megújítani tudunk címet, hanem elengedni is kézzel. Windows alatt a Parancssorban van erre megfelelő parancs. ipconfig /release Ennek hatására a kliens IP-címe visszaáll a 0.0.0.0-s induló címre. Az elindításhoz a megújítás parancsára lesz szükségünk, és ez fogja kiváltani a 4 lépéses kliens-szerver interakciót. ipconfig /renew 12
Lássuk a két parancs kimenetét a Parancssorban! 12. ábra ipconfig /release 13. ábra ipconfig /renew Ahogy látszik a két ábrán (a bekeretezett rész a lényeges), a vezeték nélküli adapterhez volt hozzárendelve IP-cím, és azt sikeresen felszabadítottuk az ipconfig /release paranccsal. Ezt követően az ipconfig /renew paranccsal kommunikáltunk a DHCP szerverrel, és kértünk egy új IP-címet. 13
Tekintsük meg az e mögött álló üzenetváltásokat Wireshark-ban! 14. ábra Wireshark DHCP üzenetváltás Indítsunk azzal, hogy a DHCP-re történő megjelenítési szűrő nem egészen triviális. A jól megszokott protokoll név beírás a Display filter részbe itt nem működik. Ennek az az oka, hogy a DNS múltjára tekint vissza a szoftver, és egy régebbi protokollt kell megadnunk szűrő kifejezésként. A DHCP az ún. BOOTP (Bootstrap Protocol) protokollból nőtte ki magát, de a régi protokollnak is a fő feladata megegyezett a DHCP-ével. Így a szűrő kifejezés: bootp. 5 üzenetünk van, ebből az első az IP-cím elengedéséért felelős, a maradék 4 pedig a 4 lépéses címkiosztási folyamatért. A csomagokat megvizsgálva láthatjuk, hogy az ipconfig /release parancs következtében valóban a 0.0.0.0-s induló címre állt vissza az adapter, hiszen a DHCP discover message forrás IP-je 0.0.0.0. Valóban igaz volt az is, hogy nem ismert a DHCP szerver címe, ezért szórásos címet választottunk. A DHCP szerverünk jelen esetben a router-ünk maga, hiszen ő volt az, aki válaszolt (elképzelhető más hálózatoknál, hogy a relay agent válaszol vissza). Ha relay agent áll az interakció mögött, akkor annak az IP-címe megtalálható a csomag részletei között (Relay agent IP address:... ). Ha ez a cím 0.0.0.0, akkor nincs relay agent. A port nyitás is az elmélet szerint történik, ugyanis a kliens a 68-as porton küld és fogad, míg a szerver a 67-esen. A ipconfig /renew parancs következtében láthatjuk, hogy ismételten a 192.168.0.101-es IPcímet kapta meg a kliens. A tranzakció azonosítója megegyezik a 4 lépéses interakció alatt, azaz egyetlen DHCP szervertől érkezett csak IP-cím ajánlás. Érdekesség: Ahogy látjuk a DHCP Release-ről nincs visszaigazolás (ellentétben a többi DHCP üzenet típussal). Mi történik vajon, ha a DHCP Release csomag elveszik? Ilyenkor a DHCP szerver kénytelen megvárni a Lifetime lejáratát, hiszen megszakítás hiányában az összerendelés addig életben van. 14
Ellenőrző kérdések 1. Miért nem jelenik meg port szám a pingelés során? 2. Hogyan indíthatunk olyan ping parancsot, melynek megállási feltétele a megszakítás? 3. Egy traceroute-ban jellemzően mely eszközhöz jutunk el az első lépés következtében? 4. Hányszor küldünk ki egy adott TTL-lel ellátott echo request-et traceroute esetén? 5. Mi jelzi azt, hogy egy traceroute célba ért? 6. Milyen Type - Code párossal vannak ellátva a TTL lejártát jelző ICMP válaszok? 7. Hány lépésből áll a DHCP konfiguráció? Melyek ezek a lépések részleteiben? 8. Mely parancs segítségével engedhetünk el egy klienshez rendelt IP-címet? 9. Mely paranccsal újítható meg a kliens IP-cím hozzárendelése? 10. Mely portokat használják a DHCP alatt a kliensek és a szerverek? 11. Ki az a relay agent? Források James F. Kurose, Keith W. Ross: Computer Networking, A Top-Down Approach (Seventh Edition) 15