Mérés laboratórium 4. - 1. mérés

Ez az oldal a korábbi SCH wikiről lett áthozva.

Ha úgy érzed, hogy bármilyen formázási vagy tartalmi probléma van vele, akkor, kérlek, javíts rajta egy rövid szerkesztéssel!

Ha nem tudod, hogyan indulj el, olvasd el a migrálási útmutatót.

1. Ismertesse az alkalmazott protokollanalizátor működési elvét! Hogyan épül be az operációs rendszerbe, és hogyan használja a hardvert?

A WireShark protokollanalizátor és az általa használt WinPcap csomagrögzítő könyvtár első sorban az Ethernet adatkapcsolati rétege és a felette használt kommunikációs protokollok vizsgálatára képes. A WinPcap beépül a Windows NDIS (Network Driver Interface Specification) protokoll stack-jébe. Az alkalmazások felé egy jól definiált interfészen elérhetővé teszi az abban áramló információt; a WireShark ezt az interfészt használja. Egy gépen egy adott hálózati kártya összes forgalmát képes figyelni. A hardver egyes beállításait módosíthatjuk vele. A hardvert monitorozza, de közben a forgalmat nem befolyásolja. A rögzített forgalom elmenthető, visszatölthető.

2. Ismertesse a Capture Filter és az analízis/megjelenítés szűrő működése közötti eltéréseket és alkalmazásának következményeit!

• Capture filter: csak a szűrő feltételnek megfelelő csomagokat rögzíti.
• Analízis/megjelenítés szűrő: a már rögzített üzenetek közül szűkíthetjük a megjelenítést. (Ha például csak a TCP csomagokat akarjuk látni, vagy aminek a címzettje egy adott IP-cím...)

3. Mi a következménye, ha egy Ethernet kártyát promiscuous működési módba helyezünk? Milyen felhasználásban van erre a működési módra szükség a protokollanalizátorokon kívül?

Ha engedélyezve van, akkor a Capture folyamán a Wireshark a WinPcap-en keresztül kikapcsolja az interfészhez tartozó Ethernet kártya hardvercím szűrését, és ennek megfelelően minden, a fizikai rétegen a hálózati kártyához érkező információ elérhetővé válik a Wireshark számára.

4. Milyen forgalom figyelhető meg a WireSharkkal Ethernet hálózatokban? Gondoljon arra, hogy a napjainkban elterjedt Ethernet kapcsolókat használó hálózatokban milyen forgalom jut el egy adott számítógépre, és az a számítógép milyen további szűréseket alkalmaz a különböző hálózati rétegekben!

• Unicast: csak az adott NIC (Network Interface Card) címére küldött Ethernet kereteket juttatja el a kártya a felsőbb rétegeknek, a többit eldobja.
• Multicast: elvileg csak azokat a multicast címtartományokat juttatja el a felsőbb rétegeknek, amikre a gépnek szüksége van, de akár mindet is tovább engedheti (ez a legegyszerűbb megvalósítás).
• Broadcast: mindig eljut a felsőbb rétegekhez.

A switch "szűrőként" viselkedik, így prosmicuous módban sem láthatjuk a teljes hálózati forgalmat. Ugyan a broadcast, multicast és ismeretlen célcímű kereteket alap esetben minden egyes portjára eljuttatja, az ismert című unicast üzeneteket csak a címzetthez kapcsolódó portjára küldi.

5. Ismertesse az Ethernet keretek szerkezetét!

• Ethernet csomag:
  

Fájl:MeresLabor4Ethernet eth.jpg

Meg kell jegyezni, hogy az előtag és a keretkezdet határoló nem tartozik a MAC-kerethez, de megelőzik azt szinkronizációs célból.

6. Ismertesse az Ethernet címek szerkezetét, a címek típusait!

• MAC cím szerkezete:
  

Ezen a helyen volt linkelve a ethcim.png nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

• Lényeg hogy a cím eleje egyértelműen azonosítja a gyártót.
• ipconfig /all paranccsal lekérdezhető.

• Az Ethernet-cím 6 byte-os.
• Az első három byte a gyártót azonosítja.
• A második három az egyedi hardver cím.
• A legelső bit: 0 = egyedi (unicast), 1 = csoport (multicast v. broadcast) cím.
• A második bit: 0 = globális (hardver), 1 = lokális (adminisztrátor által adott) cím.

7. Ismertesse az IP csomagok Ethernet keretekbe ágyazásának módjait és a beágyazás során megoldandó problémákat!

• Fragmentálás, MTU?
• Erre azt mondta a mérésvezető, hogy lehet típus szerint beágyazni (ekkor a Type mezőt beállítjuk például IP-re), s a továbbítás során ezen info alapján továbbít minden eszköz; másrészt lehet az adatmezőbe minden info nélkül is ágyazni.

8. Ismertesse az IP csomagok szerkezetét, az IP címeket és a subnet mask szerepét, különös tekintettel az IP fejrész TTL mezőjének jelentésére és felhasználására a csomagtovábbítás során!

• IP csomag:
  

Ezen a helyen volt linkelve a ip.gif nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

• IP-cím - címzés értelemszerűen.
• IP + subnet mask alapján keresik ki a hálózati eszközök a route táblában a célcsomópontot.
• Parancssori eszköz: route print
• TTL: Time To Live - csomag élettartalma. Minden egyes hop (hálózati eszközön való áthaladás) esetén csökken. A traceroute ezt használja ki, és mindig eggyel nagyobb TTL-ű csomagot küld ki.

9. Ismertesse az ARP protokoll célját és működésének alapjait!

• Az IP-címek és Ethernet-címek közötti fordításra használják.
• Az IP-cím nem elég a kommunikáció létrejöttéhez, az eszköz fizikai címére (MAC) is szükségünk van.
• Az FF:FF:FF:FF:FF:FF broadcast MAC-címre ARP kérést küldünk, amiben a saját IP-címünk, a MAC-címünk és a kérdéses IP-cím szerepel. A válaszban megkapjuk a kérdéses IP-című eszköz MAC-címét.
• Parancssori eszköz: arp

10. Ismertesse a DNS protokoll célját és működésének alapjait!

• Egy hálózathoz tartozó gép domain-nevét lefordítja IP-címmé. Megtalálja a tartományhoz tartozó levelező-kiszolgálót - MX record.
• A névfeloldást a DNS szerver végzi el - 53/UDP, 53/TCP.
• Működése: a kliens gép a szervernek elküldi domain nevet, a DNS szerver megkeresi a fában hozzátartozó IP címet és visszaküldi a kliensnek. Alkalmazásrétegbeli protokoll.
• Parancssori eszköz: nslookup

Részletek: http://hu.wikipedia.org/wiki/Domain_Name_System

11. Ismertesse az ICMP protokoll célját és működésének alapjait!

• Internet Control Message Protocol
• Segítségével értesülhetünk a hibákról, illetve azok típusáról. Hálózati diagnosztizálásban a segítségünkre lehet (_traceroute_, _ping_).
• Az ICMP (a TCP-hez és az UDP-hez hasonlóan) az IP-t használja borítékként (ICMP csomagok csak IP hálózaton mehetnek).

Forrás: http://wiki.hup.hu/index.php/ICMP

12. Ismertesse a TCP és UDP protokollok főbb tulajdonságait!

• Transzport rétegbeli protokollok.
• Mindkettő portokat kezel (multiplexelés/demultiplexelés), ezáltal interface-t nyújtanak az alkalmazói folyamatok felé.
• TCP: garantált kézbesítésű - flow control. Kapcsolatorientált (összeköttetés-alapú) protokoll, így tudja garantálni a sorrendhelyes átvitelt.
• UDP: nem garantál célba juttatást, csak hibajelzést nyújt. Best effort jellegű, továbbításakor a sebesség a fontos. Nincs kapcsolat, nincs újraküldés, összeköttetés-mentes. A flow control hiánya miatt az UDP csomagszerkezete is jóval egyszerűbb, mint a TCP csomagé. Tulajdonságai miatt az UDP-t elsősorban médiafolyam esetén használjuk.

13. Ismertesse a TCP kapcsolat felépülésének és lebontásának lépéseit, a TCP kapcsolat lehetséges állapotait!

• TCP kapcsolat felépítése:
  

Ezen a helyen volt linkelve a tcp-connection-establishment.jpg nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

• TCP kapcsolat bontása:
  

Ezen a helyen volt linkelve a tcp-connection-termination.jpg nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

• TCP állapotok: http://www.wlug.org.nz/TcpStates
  

Ezen a helyen volt linkelve a transServer2.jpg nevű kép a régi wiki ezen oldaláról. (Kérlek hozd át ezt a képet ide, különben idővel el fog tűnni a régi wikivel együtt)

• Aktuális kapcsolatok állapotai: netstat

14. Ismertesse az Ethernet fölött alkalmazott TCP/IP protokoll-stack a mérésben említett protokolljainak (Ethernet, ARP, IP, ICMP, TCP, UDP, HTTP) egymáshoz való viszonyát (rétegszerkezetét)!

• Adatkapcsolati: Ethernet
• Hálózati: IP, ICMP, ARP
• Szállítási: TCP, UDP
• Alkalmazási: HTTP, DNS

Javítva! (http://hu.wikipedia.org/wiki/OSI_modell) -- Pigen - 2012.04.28.

Forrás: http://en.wikipedia.org/wiki/Internet_Protocol