AZ IP KIEGÉSZÍTŐ PROTOKOLLJAI Az előző, IP-t vizsgáló fejezetben többször hivatkoztunk már az ARP és ICMP protokollokra, most végre ezeket is érintjük. ADDRESS RESOLUTION PROTOCOL (ARP) Korábban láttuk, hogy egy adott gépen az IP feladata az, hogy egy továbbítandó csomag célcíme és a gép routing táblája alapján eldöntse, hogy melyik interfészen küldi tovább az IP csomagot. Láttuk azt is, hogy ilyenkor a csomagot közvetlenül a címzetthez vagy csak a címzett felé vezető út következő routeréhez szeretné eljuttatni az IP. Bármelyik esettel legyen is dolgunk, az biztos, hogy a protokoll csak a küldemény következő állomásának IP címét tudja. Ez viszont kevés, mert a hálókártyák MAC címekből értenek. Az ARP feladata az, hogy az IP datagram következő állomásának IP címéhez MAC címet rendeljen (címfeloldás). Az ARP a hálózati réteg kiegészítő protokollja és annak (most az IP) működését támogatja. Az ARP egy belső táblázatának (ARP cache) adatait használja az IP címhez tartozó MAC cím meghatározásakor. Ha a kérdéses MAC cím nem szerepel az ARP táblában, akkor egy broadcast címzésű MAC keretben egy ARP lekérdezést küld a hálózatra. A MAC keret protokoll típus mezőjében a 806H azonosítja az ARP-t. Az a gép, amelyiken az ARP felismeri a kérdésben szereplő IP címet, az egy (unicast) ARP válasz keretben visszaküldi a saját MAC címét a kérdezőnek. Az ARP másik alkalmazási területe az IP címek ütközésének 1 felderítése. Minden induló (vagy IP címcserén átesett) gép egy (broadcast) ARP kérdést küld a hálózatra 2.úgy, hogy a saját IP címéhez tartozó MAC címet kérdezi, így az esetleg azonos IP című gépek felfedezhetők. Az ARP csak ritkán terheli broadcast címzésű kerettel a hálózatot, mert működése közben figyel és egy táblázatot állít össze a MAC és IP címek összerendeléséről. Az összeállítás során más gépek ARP kereteit is figyeli, ezzel gyorsítja a táblázat elkészítését. Azért, hogy az esetleges NIC cserét észrevegye, a régebben frissített táblázat bejegyzéseket szándékosan elfelejti. 1 Másik interfész is ugyanazt az IP címet használja. 2 Gratious ARP Szarka T. 2009.02.24. 1
Az ARP protokollt üzenetszórással működő hálózatokban használják, míg a két pont közötti kapcsolatoknál más címfeloldó protokollok szükségesek. (Pl. ha L2-ben PPP fut, akkor nincs rá szükség, viszont ATM-nél használják.) Az ARP, MAC szintű broadcast kérdése nem jut át a routeren, ezért hálózatok vagy alhálózatok között nem használható. Ebből az következik, hogy minden interfész csak a saját (al)hálózatát tudja az ARP táblájában felvenni. Az alhálózaton kívülre szánt IP csomagokat az általános megoldás szerint a router interfészének IP címére küldjük tovább. (A példákban ezt a módszert használtuk.) Előfordulhat egy speciális, ún. proxy ARP megoldás is. Ez véleményem szerint akkor szükséges, ha valamiért csak a router tud routolni és az IP csomagot küldő gép nem tud. Ehhez a router úgy van beállítva, hogy a mögöttes hálózataiba szóló IP címekre utaló ARP kérdésekre a saját MAC címével válaszoljon. Bármelyik megoldást is választjuk, végeredményben a hálózaton kívüli IP címekre küldendő csomagok a routerre érkeznek. Az ARP keret: Hardwer Type (16 bit) HW Address Lenght Protocol Address Lenght (8 bit) (8 bit) Protocol Type (16 bit) Operation Code (16 bit) Sender HW Address 0.-3. byte Sender HW Address 4.-5. byte Sender Protocol Address 0.-1. byte Sender Protocol Address 2.-3. byte Target HW Address 0.-1. byte Target HW Address 2.-5. byte Target Protocol Address 0.-3. byte Feltételezve, hogy az (Ethernet) MAC címek 6 bájtosak és a hálózati (IP) címek 4 bájtosak. Hardware type: Ethernet esetén 1. Az ARP-t kis átalakítással más MAC protokollok is használják, pl. FDDI, IBM TR. Az átalakítást az indokolja, hogy az ARP épített az Ethernet üzenetszóráson alapuló működésére. Protocol type: A hálózati réteg protokolljának (pl. IP, IPX) azonosítója, pl. IP=800H Hardware Address Lenght: Ethernet esetén 6 bájtos MAC címet használnak. Protocol Address Lenght: A hálózati réteg protokollja (az IP) 4 bájtos címeket használ. Operation Code: 4 műveleti kódot különböztetünk meg az ARP keretben: ARP kérdés=1, ARP válasz=2, RARP kérdés=3, RARP válasz=4. Senders 3 Hardware Address: a keretet küldő interfész MAC címe Senders Protocol Address: annak az IP címe, aki ezt a keretet a hálózatra helyezte. Target Hardware Address: erre a MAC címre megy az ARP keret. Target Protocol Address: erre az IP címre megy az ARP keret. Az utóbbi négy mező jelentése az ARP és a RARP esetén. Protokoll ARP RARP Operation Code S_h_a S_p_a T_h_a T_p_a Kérdés Válasz Kérdés Válasz A kérdező MAC címe A kérdező IP címe Ezt kérdezzük A kérdezett IP címe A válaszban itt a kérdezett hw címe A kérdezett itt küldi az IP címét A válasz erre a MAC címre megy A válasz erre az IP címre megy A kérdést küldő RARP kliens MAC címe? A kérdező kliens a RARP szerver ilyen MAC címére küldi a kérdését? A válaszadó RARP szerver MAC címe. A válaszadó RARP szerver IP címe. Az RARP kliens MAC címe. A RARP kliens IP címe. 3 Az ARP keret Senders és Target mezői csak adatnak minősülnek, a MAC keret tényleges forrását és célját a MAC keret cím mezői tartalmazzák. Szarka T. 2009.02.24. 2
ARP.EXE Az ARP.EXE az ARP gyorstár ellenőrzésére és manipulációjára szolgál 4. A működését kapcsolókkal és paraméterekkel állíthatjuk be. Egyaránt megtalálható Linux alatt, illetve a WINDOWS különböző változataiban. Most a WINDOWS-os változat használatára láthatunk példát. ARP /? Részletes leírás a használatról. ARP a Megjeleníti a hoszt egyes interfészeihez tartozó ARP táblákat. ARP g Ugyanaz mint a ARP s IP cím MAC cím A parancs hatására az ARP tárba bekerül a megadott összerendelés. Az így létrehozott bejegyzés statikus jellegű, tehát a gép kikapcsolásáig megmarad. A bejegyzés felülíródik, ha az adott gép kap egy olyan broadcast üzenetet, amely szerint ez a bejegyzés hibás. A bejegyzés ezután a helyes címeket tartalmazza, de már dinamikus jelleggel. A dinamikus bejegyzések néhány perc élettartamúak. Az előbb említett broadcast üzenetek az ARP működése során gyakoriak, pl.: a régi ARP bejegyzések felújításához direkt kérdéseket tesz fel a protokoll, ill. figyeli a többiek ARP forgalmazását. Példák: >ARP a Interface: 193.17.21.33 Internet Address: Physical Address: Type: 193.194.195.9 20-FA-23-42-86-93 Static 193.194.195.46 10-DF-24-36-11-00 Dynamic 193.194.195.199 21-FF-11-12-22-03 Dynamic >_ Tehát minden interfésznek külön ARP táblázata van az általa látott interfészek IP és MAC címének összerendeléséhez. Látható, hogy az automatikusan keletkezett bejegyzések dinamikus státuszt kapnak. >ARP s 193.194.195.9 20-FA-23-42-86-93 táblába. >ARP d IP_cím MAC_cím statikus bejegyzést tesz az ARP törli a megadott statikus bejegyzést az ARP táblából. REVERSE ADDRESS RESOLUTION PROTOCOL (RARP) Fordított irányú címfeloldás. Többnyire lemez nélküli hosztok használják arra, hogy hálózati (IP) címüket lekérdezzék a RARP szervertől 5. A RARP szervernek a MAC broadcast domain-en belül kell lennie a MAC szintű, broadcast RARP kérdés miatt. A protokoll ezen a hátrányos tulajdonsága, amely szerint minden alhálózatban kellene egy RARP szerver, vezetett újabb protokollok kifejlesztéséhez, pl. Bootp, DHCP. Ezek az új protokollok már UDP szegmenseket használnak a szerviz információk továbbításához, így elméletileg a router sem akadály számukra. A RARP azonosítója az LLC alrétegben 0835H. A RARP által használatos keret formátuma lényegében megegyezik az ARP kerettel. Figyeljünk azonban arra, hogy az Operation Code mező pillanatnyi tartalmának megfelelően néhány mező jelentése módosul. 4 Általános esetben nincs szükség a használatára, mert az ARP tábla kezelése automatikus. 5 Pl. a Linux kernel szinten támogatja a RARP szerver kialakítását. Szarka T. 2009.02.24. 3
Mérés Az Ethereal programmal elkaptunk (capture) két Ethernet keretet. Az első egy kérdés a második pedig a válasz. A forrás és cél MAC címek sajnos nem olvashatók teljesen, mert az Ethereal úgy volt beállítva, hogy a címek gyártót jelölő részét feloldotta INTERNET CONTROL MESSAGE PROTOCOL (ICMP) Az ICMP az IP kiegészítésének is tekinthető. Az IP és más protokollok e protokoll segítségével küldenek és fogadnak forgalmi helyzetjelentéseket (felügyeleti protokollhoz is hasonlítható a szerepe, mert általában rendkívüli helyzetekben kerül sor ilyen üzenetekre). Az ICMP üzenetek IP csomagban továbbítódnak úgy, hogy az IP fejlécben a protocol mező 1. (Csak emlékezzünk arra, hogy ez UDP esetén 17, míg a TCP esetén 6 volt.) Az ICMP üzenet szintén közvetlenül az IP fejléc után helyezkedik el, viszont az előbbi protokollokkal ellentétben nem használ portokat, mert maga a TCP/IP vezérlő program értelmezi az üzeneteket. Az ICMP szolgáltatások az alkalmazói programok, ill. a programozók számára is fontosak, lásd pl. W9X rendszerekben az ICMP.DLL-t, ill a WinSock API-t. Az ICMP üzenet az IP csomagban: IP fejléc ICMP üzenet Szarka T. 2009.02.24. 4
Az ICMP üzenet általános felépítése: Üzenet típusonként változó rész Type: az üzenet típusát és ezzel a formátumát (pl. hosszát, a változó rész mezőit, stb.) határozza meg. Részlet az ICMP üzenet típusokból: Type Name Reference ---- ------------------------- --------- 0 Echo Reply [RFC792] 1 Unassigned [JBP] 2 Unassigned [JBP] 3 Destination Unreachable [RFC792] 4 Source Quench [RFC792] 5 Redirect [RFC792] 6 Alternate Host Address [JBP] 7 Unassigned [JBP] 8 Echo [RFC792] 9 Router Advertisement [RFC1256] 10 Router Selection (solicitation) [RFC1256] 11 Time Exceeded [RFC792] 12 Parameter Problem [RFC792] 13 Timestamp [RFC792] 14 Timestamp Reply [RFC792] 15 Information Request [RFC792] 16 Information Reply [RFC792] 17 Address Mask Request [RFC950] 18 Address Mask Reply [RFC950] http://www.networksorcery.com/enp/default0501.htm Code: az üzenet altípusát, további paramétereit tartalmazza. Checksum: a teljes ICMP üzenetre vonatkozó ellenőrző összeg. Képzése hasonló az IP fejlécnél használt eljáráshoz. Az ICMP üzenet hossza az IP fejrész két hossz mezőjéből kiszámítható. Néhány ICMP üzenet részletes ismertetése A következő három ICMP üzenetpár segítségével az egyes hosztok a hiányzó IP beállításaikat (IP cím, netmaszk, alapértelmezett átjáró) tudják megszerezni. Pl. Windows operációs rendszert használó gépeknél ezeknek már nincs jelentős szerepük, mert DHCP segítségével megszerzett vagy kézzel megadott IP jellemzőkkel dolgoznak. Information Request és Replay: az állomások a hálózatcímüket tudják lekérdezni ezekkel az üzenetekkel. Manapság már DHCP vagy RARP üzeneteket használnak erre a célra. Address Mask Request és Replay: az állomások a saját netmaszk értéküket a routertől tudják lekérdezni ezekkel az üzenetekkel, ha nem ismernék a netmaszk értékét. Router Solicitation és Router Advertisement (Router lekérdezés és hirdetés) Unused (32) Type: 9 (Advertisement), ill. 10 (Solicitation) Code: 0 Unused: 0 Az ICMP Router Discovery Protocol (IRDP) segítségével egy hálózati link gépei aktualizálhatják az alapértelmezett útválasztóra vonatkozó beállításaikat. A protokoll a Szarka T. 2009.02.24. 5
routerek és a hosztok együttműködésén alapszik. A routerek a beállított alhálózatokon periodikusan hirdetményeket (Router Advertisement, azaz ICMP type=9) tesznek közzé a linken a hosztok által ismert All hosts, azaz 224.0.0.1 (TTL=1) címre (felszólításra válaszul unicast címre is küldhetnek Router Advertiement üzenetet), melyekben számos paraméterüket közlik az állomásokkal (többek között IP címüket). Az állomások így megismerik, hogy milyen router-ek vannak a linken és a hirdetésekben legnagyobb precedenciával minősített útválasztót fogják alapértelmezett átjáróként használni. Az állomásoknak nem kell megvárniuk a hirdetmények periodikus közzétételét, hanem felszólításokkal (Router Solicitation ICMP üzenettel az All-routers címre 224.0.0.2 (TTL=1)) soron kívül is kiválthatják azokat. A TTL=1 értékéből látszik, hogy csak a linken belül hatásosak ezek az üzenetek. A következő ICMP üzenetpárral a hálózat L1-L3 rétegeinek működőképességét vizsgálhatjuk. Echo és Echo reply (Echo kérés és Echo válasz, azaz visszhang üzenetek) Identifier (16) Sequence Number (16) Data (n byte) Type=8, ill. 0. Code=0 Egy IP cél elérhetőségét és válaszadási képességét lehet tesztelni. Egy visszhang kérés beérkezésének helyén a TCP/IP részét képező ICMP választ fog küldeni a kérőnek. A kérőt az ICMP üzenetet szállító IP fejlécből határozhatja meg. Az átviteli út minden elemét teszteli: az adó, a gateway és a cél gép szoftver és hardver komponenseit ill. beállításait. A részleteket a PING parancsnál tárgyaljuk. Identifier és Sequence Number mezők segítségével azonosíthatja a kérő az összetartozó visszhang kérés és visszhang válasz párokat. Pl. az Identifier mezőben elhelyez egy véletlen számot és minden kéréskor inkrementálja a Sequence Number mezőt. Data: egy bájtsorozatot küld az adó, amely remélhetőleg visszaérkezik a távolból. Az ECHO kérés üzenetet kapott gép felcseréli a cél és forrás címet, újraszámolja az ellenőrző összeget és visszaküldi ECHO Replay-ként. Az üzenetek alkalmasak a körülfordulási idő (Round Trip Time RTT) mérésére: A B Echo kérés t 1 RTT= t 2-t 1 t e Echo válasz t 2 t t A kapott RTT a célgép feldolgozási idejét (t e ) is tartalmazza, mint hibát. A t e abból adódik, hogy a B gép egy feldolgozási sorba (queue) illeszti a bejött üzenetet vételkor ill. válaszkor. Szarka T. 2009.02.24. 6
A PING 192.168.0.2 mérése: Tehát egy IP címet pingeltünk. Az IP gyorsan hívta az ARP-t, hogy mondja meg mi a MAC címe a 192.168.0.2 interfésznek. Amint megjött a válasz, kimehetett az első ICMP echo kérés. Mi az erre érkező válaszba néztünk bele, láttuk, hogy IP csomagban utazik az ICMP üzenet, konkrétan egy ICMP echo reply (válasz). Az ICMP adatmezőjét kiválasztva kijelölődött az Ethernet keret megfelelő része és láttuk, hogy az abc betűi alkotják az adatokat. A hálózati forgalomból kiderül, hogy a PING alapértelmezésben 4 echo kérést küld. Timestamp és Timestamp Reply (Időbélyeg kérés és időbélyeg válasz) Identifier (16) Sequence Number (16) Originate Timestamp (32) Receive Timestamp (32) Transmit Timestamp (32) Type: 13 (TimeStamp) 14 (Timestamp Reply) Code: 0 Originate Timestamp: a kérés elküldésének ideje. Tartalmazza: a kérés és a válasz Receive Timestamp: ekkor érkezett a célgépbe a kérés. Tartalmazza: a válasz Transmit Timestamp: a választ ekkor adta a célgép. Tartalmazza: a válasz Órák összehasonlítására, hibakeresésre és teljesítménymérésre használható üzenetek. A kérő kitölti az ICMP TimeStamp üzenetében az Identifier, Sequence Number, Originate Timestamp mezőket és elküldi a célállomásnak. Az kitölti a Receive- és Transmit Timestamp mezőt és mint Timestamp Reply üzenet küldi vissza. Például az egyes gépek Szarka T. 2009.02.24. 7
elérési idejét vizsgálja a rendszer az útvonal megválasztás optimalizálása érdekében. Természetesen ehhez átlagolni kell a datagramok haladási idejét: Odaút ideje: Receive Timestamp Originate Timestamp Visszaút ideje: Transmit Timestamp pillanatnyi idő A 32 bites idő mezőkben az éjféltől eltelt időt milliszekundumban ábrázolják. Ezeket az üzeneteket ritkán használják, mert előnyösebb a (Simple) Network Time Protocol (S/NTP). Destination Unreachable (Cél elérhetetlen) Unused (32) IP header + 64 bit a datagramból Type: 3 Code: 0 a hálózat nem érhető el Gw 1 a hoszt nem érhető el, pl. ARP nem látja. Gw 2 a protokoll (pl. TCP, UDP) nem érhető el Host 3 a port (pl. WEB szolgáltatás) nem érhető el Host 4 tördelni kellene, de DF=1 Gw 5 forrás általi routolás hibához vezetett Gw Más Code értékek: http://www.networksorcery.com/enp/protocol/icmp/msg3.htm Az elérhetetlen célba üzenetet küldő forrás kap ilyen ICMP üzenetet. Az ICMP üzenet származhat gateway-tól vagy host-tól. Time Exeeded Message (Idő túllépés) Unused (32) IP header + 64 bit a datagramból Type: 11 Code: 0 TTL számláló járt le (Routertől). 1 A refregmentáció nem fejeződött be időre, mert nem érkezett be az összes darab. (Cél állomástól) Az IP csomag feladója kap értesítést, hogy nem sikerült a csomag élettartalma alatt célba juttatni. Például az útvonal táblák hibája miatt fordul elő, hogy a datagram körforgalomba kerül. Az Exceeded in transit üzenetnek az egyik alkalmazási területe egy adott célhoz vezető útvonal felderítése Traceroute jellegű programmal. (Windows: tracert.exe, tracert6.exe ill. visualroute.exe) Az A hoszton futtatott traceroute (tracert.exe) program a B-hez vezető útvonal felderítéséhez a B egy nem létező portjára küld üzeneteket. (Echo kérés is használható, de ez a lényeget nem érinti.) Az első üzenetben a TTL értéket 1-re állítja, a 2. üzenetben 2-re stb. Az első üzenetre a R1 válaszol, mert a TTL lejárta miatt nem tudja továbbítani az A által küldött csomagot. A második üzenetre az R2 válaszol, mert akkor már ő az aki nem tudja továbbítani a csomagot, stb. A válaszok az A-nak küldött TTL Exceeded in transit (TTL számláló lejárt) üzenetek. Az üzenetek feladóiból megjeleníthető az útvonal. A célból Destination Unreachable üzenet érkezik vissza, jelezve, hogy a célpont nem létezik, de ebből tudjuk, hogy a cél hoszt létezik és be van kapcsolva. (Echo kérésre természetesen Echo válasz jön.) Szarka T. 2009.02.24. 8
Példa avisualroute.exe használatára: A program többször is lekérdezi az útvonalban érintett routereket azért, hogy a statisztikája elfogadható pontosságú legyen. A routerek domain nevét is kiírja, amihez a DNS rendszer szolgáltatásait is igénybeveszi. (Lásd a fordított névfeloldást a DNS fejezetben.) Szarka T. 2009.02.24. 9
Parameter Problem Message (Valamelyik paraméter hibás) Pointer (8) Unused (32) IP header + 64 bit a datagramból Type: 12 Code: 0 Pointer: a hibát okozó bájt sorszáma az adatmezőben. (Az IP fej, illetve IP adat van az adatmezőben.) A példa kedvéért válasszuk a pointer=1 esetet. Ekkor az IP fejléc ToSVC mezőjében érzékelt hibát a vezérlő program. A hibás IP fejléc visszaérkezik az ICMP üzenet adatmezőjében a hibás csomag feladójának. Hoszt vagy router küldheti. Source Quench (Forrás lefojtás) Unused (32) IP header + 64 bit a datagramból Type: 4 Code: 0 Az IP csomag feladója kap értesítést arról, hogy túl gyorsan küldi egymás után az IP csomagokat. Legalábbis a címzetthez képest gyorsan, mert az nem képes ebben a tempóban fogadni azokat, ezért küldi ezt az ICMP üzenetet. Az IP csomagokat egy pufferben várakoztatja a vevő a feldolgozásuk előtt. Mielőtt ez a FIFO megtelne elküldi a forrás lefolytás üzenetet. Hoszt vagy router küldheti. (Használatát nem javasolják, mert kibocsátása tovább növeli a hálózati forgalmat.) Redirect Message (Válassz más útvonalat!) Gateway Internet Address (32) IP header + 64 bit a datagramból Type: 5 Code: 0 Használj más hálózati címet! 1 Használj más hoszt címet! 2 Használj más típusú szolgáltatást a hálózaton! 3 Használj más típusú szolgáltatást a hoszton! Gateway Internet Address mezőben jelzett új paraméter használatával a hibát valószínűleg elháríthatja az IP csomag küldője. A hostok ezekből az üzenetekből tartják karban az útvonaltáblákat. Amikor egy router környezetében változik a topológia, akkor fordulhatnak elő ezek az üzenetek. (Routerek küldhetnek ilyen üzenetet.) A a helyi routing tábla alapján R1 felé küldi B-nek szánt üzenetét. R1 a saját routing táblája alapján látja, hogy neki azon az interfészén kell kiküldeni, amelyiken bejött, mert R2 az optimális útvonal B felé. Ekkor küld A-nak Redirect message -t, hogy az R2-re módosítsa a routing tábláját a B-nek szánt üzenethez. Szarka T. 2009.02.24. 10
Megfontolások ICMP üzenet küldéséhez: nem szabad ICMP üzenetet küldeni, ha: Hibás a csomag forrás IP címe Broadcast vagy multicast címre küldött csomag hibás Az IP fejléc hibás, pl. rossz CRC ICMP csomag okozza a hibát Egy töredék a hibás és a töredék csomag nem az első töredék. A ICMP üzenetek számát korlátozzák, hogy az igényelt sávszélességet csökkentsék: - pl. az ICMP üzenetek közötti minimális időt meghatározva. Packet Internet Gropher Az ICMP alkalmazásai PING A PING 6 segítségével egy ICMP visszhang kérést tudunk küldeni egy IP címre. Ezzel az egész IP kapcsolatot, sőt a távoli alkalmazást is tudjuk ellenőrizni. Az IP cím mellett a tesztelés számos paraméterét is beállíthatjuk. PING /? PING 127.0.0.1 paranccsal a kapcsolók és paraméterek kérdezhetők le. a megadott IP című interfész, ill. hoszt tesztelése A következő pingelése: 127.0.0.1 32 adatbájttal: Válasz a következőtől: 127.0.0.1: bájt=32 idő<10 ezredmp. TTL=128 Válasz a következőtől: 127.0.0.1: bájt=32 idő<10 ezredmp. TTL=128 Válasz a következőtől: 127.0.0.1: bájt=32 idő<10 ezredmp. TTL=128 Válasz a következőtől: 127.0.0.1: bájt=32 idő<10 ezredmp. TTL=128 Pingstatisztika - 127.0.0.1: Csomagok: Küldve = 4, Fogadva = 4, Elveszett = 0 (0% veszteség), Körutazás hozzávetőleges ideje ezredmásodpercben: Minimum = 0ms, Maximum = 0ms, Átlagos = 0ms 6 A PING egy hálózati tesztelő program családot jelöl. Ebből az egyik a PING.EXE. Multicast címekhez viszont az MCAST.EXE használható. Szarka T. 2009.02.24. 11
A következkő módon érdemes egy útvonal tesztelést végrehajtani: 1. Teszteljük az alapértelmezett loopback eszközt 7, pl. PING 127.0.0.1 Ezzel lényegében a gép TCP/IP protokoll vermét mint programot ellenőrizzük. 2. Teszteljük a gépünk azon fizikai interfészét, amelyik a vizsgált útvonalra kapcsolódik. 3. Teszteljük az alapértelmezett átjárót. Ilyenkor először a felénk eső interfészét próbáljuk meg elérni, majd a célhoz közelebbi interfészét. 4. A cél gép IP címére adjuk ki a parancsot és ezzel az útválasztót is teszteljük mindkét irányból. A PING paramétereként IP cím helyet a gép nevét is megadhatjuk. Ha ezt utóbbival nem sikerül elérni a gépet, akkor névfeloldási problémával találkoztunk és ellenőrizni kell a névfeloldási rendszert (lásd az nslookup programot). A PING kapcsolóinak további rövid ismertetése: PING 193.46.26.10 t Folyamatos visszahang kérés. Az alapértelmezett négy üzenet helyett egészen a megszakításig (CTRL+C) pingel. Rész statisztika CTRL+Break hatására jelenik meg. PING 193.46.26.10 a PING 193.46.26.10 -n darab kérést küld. Címfeloldás. Állomásnév visszakeresése IP címből. Az alapértelmezett négy helyett darab visszhang PING 193.46.26.10 -l hossz A küldő puffer méretét állítja. Az alapértelmezett 32 bájtos 8 visszhang csomag helyett más hosszúságú visszhangcsomagot küld. (A csomag max 8192 bájtos lehet.) A fragmentációs problémákat lehet ellenőrizni vagy az adatátviteli sebességet becsülni. PING 193.46.26.10 -i élettartam A TTL-t az élettartam ra állítja PING 193.46.26.10 -v TOS Az ellenőrizendő szolgáltatás típusát állíthatjuk be (ToS=Type of Service) alapértelmezett értéke 0. PING 193.46.26.10 -f datagramban. A fragmentálást megakadályozó (DF) bitet beállítja a PING 193.46.26.10 -r szám Rögzíti a datagram által megtett útvonalat: 1<=szám<=9 gépet jegyez fel. Az érintet gépek akkor jelennek meg, amikor a válasz visszaérkezik. PING 193.46.26.10 -s szám minden érintett állomáskor. Időbélyeget rendel a megadott sorszámú ugrásig PING 193.46.26.10 -j géplista A visszhangcsomagok a megadott gépeket érintve közlekednek. Routerek is megadhatók, de max. 9 gépből állhat a lista. PING 193.46.26.10 -k géplista Mint a j, de routerek nem lehetnek a listában. PING 193.46.26.10 -w idő Megadható, hogy mennyi idő várakozás tartozzon az időtúllépéshez. Az időkorlát milliszekundumban értendő és az alapértelmezése 750 ms. Ha a megadott időn belül nem válaszol, akkor Request timed out. hibaüzenetet kapunk. 7 Ez egy a TCP/IP számára logikailag létező eszköz, teszteléséhez a 127.0.0.1-127.0.0.255 címtartomány használható. 8 32 bájt=8 bájt fejléc + 24 bájt adat Szarka T. 2009.02.24. 12
TRACERT mint a TCP/IP egy másik segédprogramja A TRACERT képes kilistázni egy állomáshoz vezető úton érintett átjárókat és azt, hogy a TRACERT által küldött három csomagot mennyi idő alatt dolgozták fel. (Az említett program csak egy példa a nyomkövető programokra. IPv6 esetén tracert6.exe használható.) TRACERT [-d] [-h ugrásszám] [-j géplista] [-w időkorlát] célgép - d Ne végezzen névfeloldást. - h ugrásszám: a cél eléréséhez felhasználható maximális ugrásszám. - j géplista: a cél eléréséhez felhasználható maximális ugrásszám. - w időkorlát: Az időkorlátban meghatározott ezredmásodpercet vár az egyes válaszok előtt. - célgép: A célgép IP címét vagy nevét kell megadni. Példák: tracert www.ready.hu vagy tracert 195.8.32.11 útvonal követése a következőhöz: elixir.alarmix.net [195.8.32.11] legfeljebb 30 ugrással: 1 125 ms 122 ms 119 ms as-193-1.matav.net [145.236.225.227] 2 119 ms 130 ms 130 ms fe5-1.core0-miskolc.matav.net [145.236.194.5] 3 124 ms 127 ms 128 ms lo1.lsc0-miskolc.matav.net [145.236.225.58] 4 125 ms 129 ms 146 ms lsc2.matav.net [145.236.225.16] 5 131 ms 129 ms 136 ms lsc1.matav.net [145.236.225.11] 6 130 ms 130 ms 139 ms core1.matav.net [145.236.225.5] 7 137 ms 133 ms 131 ms border1.matav.net [145.236.225.2] 8 130 ms 124 ms 131 ms 193.188.137.66 9 187 ms 146 ms 129 ms elixir.alarmix.net [195.8.32.11] útvonalkövetés kész. A tracert.exe által generált útvonalat csak tájékoztatónak tekintsük, mert nincs garancia arra, hogy a következő csomagjaink is az előbbi útvonalon haladnak majd. Pontosabb mérésre alkalmas a pathping.exe, amelyet eredetileg arra fejlesztettek ki, hogy egy útvonalon lefoglaljon bizonyos sávszélességet. Ez akkor lehetséges, ha az érintett routerek támogatják a Resource Reservation Protocol-t. A sávszélesség értéke mellett a szolgáltatásminőség (QoS) is fontos jellemzője egy útvonalnak. Kérdések Mi az ARP és RARP feladata? Hogyan működnek ezek a protokollok? Ismertesse egy olyan Ethernet keret felépítését (mezőit) amely ARP kérést szállít! Mit tárol az ARP cache? Hogyan keletkezik és ellenőrizhető a tartalma? Mi az ICMP szerepe? Milyen ICMP üzenetek vannak és mi ezeknek a szerepe? Ismertesse egy olyan Ethernet keret felépítését (mezőit) amely ICMP üzenetet szállít! Mi a ping típusú programok szerepe és hogyan működnek? Hogyan keresne hibát ping program segítségével egy útvonalban? Hogyan tesztelhető a számítógép hálózati vermét alkotó programrendszer működése? Egy adott cél felé haladó csomagok által érintett útválasztókat hogyan határozná meg? Mi a tracer jellegű programok működésének alapja? ICMP üzenetek küldésének milyen szabályai vannak? Szarka T. 2009.02.24. 13