Žilinská univerzita v Žiline. Generátor paketov. Elektrotechnická fakulta Katedra telekomunikácií. Diplomová práca

Transcription

1 Žilinská univerzita v Žiline Elektrotechnická fakulta Katedra telekomunikácií Generátor paketov Diplomová práca Žilina, September 2006 Peter Bandzi

2 Abstarkt Diplomová práca sa zaoberá generovaním paketov, ich zachytávaním a filtrovaním v sieti Ethernet. V úvodnej časti sú stručne popísané sieťové protokoly TCP/IP a tiež protokol Ethernet. Ďalšia časť je venovaná postupu pri tvorbe a návrhu sieťových aplikácii a popisu nástrojov používaných na generovanie a odchytávanie paketov. V záverečnej časti popisujem aplikáciu na generovanie paketov, aplikáciu na ich otáčanie späť a aplikáciu ktorá ich zachytáva a vypisuje.

3 Poďakovanie Rád by som poďakoval vedúcemu diplomovej práce pánovi Ing. Kortišovi za jeho prístup a ochotu počas celej doby práce a jeho vecným a odborným pripomienkam. Ďakujem mu za návrh témy, ktorá je z oblasti mojich záujmov.

4 Obsah Obsah Zoznam použitých skratiek... i Zoznam obrázkov... ii Úvod Pakety, segmenty, rámce Generátory paketov Ciele diplomovej práce Ethernet princíp Úvod Protokol Ethernet II Formát rámca Protokol IEEE CSMA/CD Formát rámca Virtuálne LAN (VLAN) Prínosy VLAN Obmedzenia VLAN Štruktúra rámca podľa 802.1q (VLAN) Popis jednotlivých polí Veľkosť rámca VLAN IP (Internetový Protokol) Formát rámcov Internetového protokolu Popis jednotlivých polí v záhlaví IPv Fragmentácia Záhlavie Internetového Protokolu verzie Kvalita služby v internete Integrované služby (IS) Diferencované služby (DS) Per-hop behavior (PHB)...18

5 Obsah 5 Protokoly transportnej vrstvy Úvod Porty a sokety Porty Sokety Základný popis protokolu TCP Formát TCP segmentu Voliteľné položky TCP záhlavia Základný popis protokolu UDP Formát UDP segmentu Návrh koncepcie riešenia Sieťové aplikačné rozhranie v operačnom systéme Linux Posielanie paketov Odkazovanie na sokety Atribúty soketov Soketové domény Typy soketov Soketové protokoly Vytvorenie soketu Soketové adresy Pomenovanie soketu Zatvorenie soketu Odchytávanie paketov Formát pcap aplikácie Otvorenie zariadenia pre sledovanie Filtrovanie prevádzky Skutočné odchytávanie Analyzovanie jednotlivých záhlaví paketu Návod na použitie aplikácií Aplikácia packeth...38

6 Obsah Inštálacia a spustenie Použitie Okno Builder Okno Gen-b Okno Gen-s Aplikácia catch Syntax filtra Záver...48 Literatúra...49

7 Zoznam použitých skratiek API Application programming interface Aplikačné programové rozhranie ARP Address Resolution Protocol Zisťuje linkovú adresu z IP DHCP Dynamic Host Configuration Protocol Protokol pre pridelovanie IP adries DNS Domain Name System Hierarchický systém doménových mien DS Differentiated Services Diferencované služby DSAP Destination Service Access Point Prístupový bod cieľovej služby FTP File Transfer Protocol Protokol pre prenos súborov medzi PC GNU General Public License Licencia pre šírenie softwaru IANA Internet Assigned Numbers Authority Organizácia priraďujúca protokolom identifikačné čísla ICMP Internet Control Message Protocol Protokol na odosielanie chybových správ IEEE Institute of Electrical and Electronics Engineers Organizácia pre štandardy v oblasti počítačového a elektronického priemyslu IGMP Internet Group Management Protocol Protokol na riadenie multicast spojení IP Internet Protocol Internetový protokol ISO International Standards Organization Medzinárodná organizácia pre normalizáciu LAN Local Area Network Lokálna sieť LLC Logical Link Control Podvrstva linkového riadenia MAC Medium Access Control Podvrstva prístupu na médium NFS Network File System Sieťový súborový systém OSI Open Systems Interconnection Prepojenie otvorených systémov PHB Per Hop Behavior Postup rozhodovania pri DS sieťach RARP Reverse Address Resolution Protocol Zisťuje IP adresu z linkovej RFC Request for Comments Štandardy popisujúce internetové protokly RSVP Resource Reservation Protocol Rezervačný protokol SNAP SubNetwork Access Protocol Záhlavie definujúce protokol vyššej vrstvy SSAP Source Service Access Point Prístupový bod zdrojovej služby TCP Transport Control Protocol Spojovo-orientovaný protokol UDP User Datagram Protocol Nespojovo-orientovaný protokol i

8 Zoznam obrázkov Obr. 1 Rozdelenie linkovej vrstvy na dve podvrstvy...6 Obr. 2 Formát rámca Ethernet II...7 Obr. 3 Rámec ISO a SNAP...8 Obr. 4 Topológia virtuálnych LAN...9 Obr. 5 Formát rámca podľa 802.1q...11 Obr. 6 Detail poľa Tag...11 Obr. 7 Formát záhlavia IPv Obr. 8 Príznaky (flags) v záhlaví IPv Obr. 9 Formát DS poľa...18 Obr. 10 Porovnanie referenčných modelov TCP/IP a ISO OSI...20 Obr. 11 Formát TCP segmetu...23 Obr. 12 Niektoré voliteľné položky záhlavia TCP...24 Obr. 13 Záhlavie UDP segmetu...25 Obr. 14 Funkcie vyvíjaných aplikácií...27 Obr. 15 Poissonovský tok...27 Obr. 16 Postup pri spracovávaní paketov...30 Obr. 17 Ovládací panel aplikácie packeth...39 Obr. 18 Definovanie Linkovej vrstvy...39 Obr. 19 Definovanie IP záhlavia...40 Obr. 20 Dialógové okno pre voľbu typu služby u IP paketov...41 Obr. 21 Spôsob generovania paketov...43 Obr. 22 Výstup aplikácie catch...46 ii

9 Úvod História dátových sietí siaha až do 60. rokov 20. storočia, kedy začali prvé pokusy s komunikáciou počítačov. V priebehu vývoja bolo vyvinutých mnoho sieťových technológií. V poslednej dobe sú všetky siete postupne spojované do globálnej celosvetovej siete Internet, ktorá používa sadu protokolov TCP/IP. Sieťová architektúra predstavuje súhrn riadiacich činností umožňujúcich výmenu dát medzi komunikujúcimi systémami. Komunikácia a jej riadenie je zložitý problém, preto sa rozdeľuje tento problém do niekoľkých skupín, tzv. vrstiev. Členenie do vrstiev zodpovedá hierarchii činností, ktoré sa pri riadení komunikácie vykonávajú. Každá vrstva je definovaná skupinou služieb, ktoré sú poskytované vyššej vrstve, a funkciami, ktoré vykonáva v rámci protokolu. Riadenie komunikácie slúži ku spolupráci komunikujúcich uzlov, táto spolupráca musí byť koordinovaná pomocou riadiacich údajov. Koordináciu zaisťujú protokoly, ktoré definujú formálnu stránku komunikácie. Protokoly sú teda tvorené súhrnom pravidiel, formátov a procedúr, ktoré určujú výmenu údajov medzi dvoma alebo viacerými komunikujúcimi prvkami. Architektúra otvorených systémov bola normalizovaná organizáciou ISO, ktorá vytvorila referenčný model OSI. Praktickou realizáciou vrstvovej sieťovej architektúry je sada protokolov TCP/IP, aj keď neozodpovedá presne referenčnému modelu OSI. 1.1 Pakety, segmenty, rámce Pre ujasnenie pojmov treba spomenúť aj termíny, ktoré sa zaužívali pre označenie dátových jednotiek prenášaných cez tzv. siete s prepojovaním paketov. Tieto termíny sú rôzne pre rôzne vrstvy. Pre druhú vrstvu (data link layer) sa zaužíval pojem rámec (frame). Ak by sme si to chceli priblížiť na konkrétnych príkladoch, tak v dnešných lokálnych sieťach býva linková vrstva zabezpečená technológiou Ethernet a z nej vyplývajúcimi prenosovými protokolmi. Takže v tomto prípade je na mieste hovoriť o Ethernetových rámcoch (Ethernet frames). Podobne to platí aj pre ostatné technológie, zasahujúce do úrovne linkovej vrstvy (napr. Token Ring, FDDI). Avšak v prípade technológií Frame Relay, ATM a obdobných technológií, patriacich do linkovej vrstvy, sa pojem rámec nepoužíva, miesto neho sa používa pojem bunka. Blokom dát prenášaných treťou vrstvou (network layer) sa hovorí pakety (packets). Paket sa skladá z dvoch základných prvkov: hlavičky (ktorá obsahuje informácie potrebné pre doručenie paketu do miesta určenia) a dátovej oblasti (ktorá už obsahuje vlastné vyslané 3

10 informácie). Typickými protokolmi sieťovej vrstvy sú protokoly IP (z rodiny TCP/IP) a IPX (od firmy Novell). Počas trvania spojenia je odosielané veľké množstvo paketov. V niektorých druhoch sietí, nemusia ani všetky pakety prejsť rovnakou cestou, ale môžu byť presmerované na rýchlejšie či výhodnejšie spojenie. Veľmi často sa v odborných článkoch alebo literatúre ako ekvivalent paketu používa aj pojem datagram. Pre dátovú jednotku, prenášanú transportnou vrstvou (transport layer) používame pojem segment. Presnejšie pre blok, prenášaný protokolom TCP. Protokol TCP na strane odosielateľa postupne akumuluje jednotlivé bajty do vhodnej vyrovnávacej pamäti (buffer), a po jej naplnení odošle celý jej obsah naraz v tzv. segmente. Analogicky na strane príjemcu sa dátový obsah segmentu ukladá do vyrovnávacej pamäti, a jednotlivé bajty sú entitám aplikačnej vrstvy poskytované z vyrovnávacej pamäti. 1.2 Generátory paketov Hlavnou úlohou generátora paketov je umožniť užívateľovi alebo sieťovému špecialistovi postaviť paket z jedného alebo viacerých protokolov za účelom testovania bezpečnosti, komunikačnej efektívnosti, alebo správnosti smerovania v sieti. Existuje množstvo generátorov líšiacich sa napríklad typom zostavených paketov. Napríklad generátor TCP/IP paketov umožňuje užívateľom postaviť vlastný TCP/IP paket a tým im dáva možnosť zvoliť zdrojovú a cieľovú IP adresu a ďalšie parametre IP záhlavia. Ďalej býva možné nastavovať napr. počet odosielaných paketov, intervaly medzi nimy, ethernetové MAC adresy. Niektoré generátory sú tiež schopné generovať sekvencie paketov za účelom testovania efektívnosti siete, alebo môžu poskytovať možnosť vytvorenia a poslania VoIP paketov cez IP protokol. Generátory sú užitočné aj pre monitorovanie bezpečnosti aplikácii. Napríklad pre kontrolovanie a testovanie firewalov. Väčšinou sa na tvorbu generátorov používajú skriptovacie jazyky ako sú Perl, Python a Tcl alebo aj klasický jazyk C. Generátory sú tiež využiteľné na odhalenie dvoch najčastejších problémov paketových sietí. Prvý z nich je náhodná strata paketov, čo je neúmyselné odhadzovanie paketov, ktoré sa objavuje v starších, poruchových zariadeniach alebo pri dátovom preťažení alebo nepravidelné meškanie paketov. Jednotlivé generátory môžu byť rozdelené podľa špecializácie a ceny. Závisí od požiadaviek, ktoré sú na generátory kladené. Zopár generátorov je vyvíjaných open-source komunitou, zvyčajne sú navrhnuté pre UNIX/Linux. 4

11 2 Ciele diplomovej práce Cieľom diplomovej práce je vytvorenie aplikácie pre operačný systém Linux, ktorá bude umožňovať generovanie TCP a UDP datagramov v ethernetovej sieti s požadovanou dĺžkou a obsahom, so zvolenými prioritami na druhej a tretej vrstve. Aplikácia by mala umožňovať výber spôsobu generovania paketov a to buď konštantnou rýchlosťou, poissonovským tokom, alebo generovať pakety v zhlukoch. Generátor by mal byť schopný určiť čo najpresnejší časový údaj odoslania jednotlivých paketov a tento údaj vloží spolu s poradovým číslom do dátovej časti každého odosielaného paketu. Pomocou týchto údajov je možné analyzovať stratovosť paketov a jitter (kolísanie oneskorenia, resp. rozptyl oneskorenia medzi prijímanými paketmi) [1]. Na prečítanie časového údaja z paketu je potrebné vytvoriť ďalšiu aplikáciu, ktorá bude schopná zachytávať vygenerované pakety, a filtrovať ich na základe zdrojovej a cieľovej IP adresy a čísla portu. Tiež by mala určiť presný čas prijatia paketu, aby bolo možné porovnať čas odoslania a čas prijatia paketu. Pretože sa jedná o krátke časové intervaly, treba si uvedomiť, že časy na rôznych počítačoch nebudú na mikrosekundu presne rovnaké. Preto by bolo vhodné vytvoriť testovaciu slučku, ktorá bude smerovať prijaté pakety späť ku odosielateľovi, kde sa budú zachytávať a tým dostaneme časové údaje odoslania a prijatia ktoré je možné reálne porovnávať. Tieto aplikácie môžu poslúžiť ako pomôcka pri hodnotení kvality služieb (QoS) ethernetovej siete. Sieť IP má tri základné indikátory, ktoré majú rozhodujúci vplyv na kvalitu služby. Je to oneskorenie (delay), jitter a strata paketov. Zatiaľ čo v sieťach s prepojovaním okruhov je oneskorenie dané iba fyzikálnymi vlastnosťami vedenia a teda je zanedbateľné, v IP sieťach je už z ich princípu podstatné. Pretože priepustnosť siete sa mení v závislosti na jej momentálnom zaťažení, celkový súčet oneskorenia sa nedá vopred presne určiť. Jeho hodnota sa mení s časom. Tento jav nazývame jitter. Je dobré si uvedomiť, že v súvislosti s IP QoS je najväčším problémom jitter. Jeho hodnota má zásadný vplyv na oneskorenie aj na stratovosť paketov. 5

12 3 Ethernet princíp 3.1 Úvod Technológia Ethernet bola pôvodne vyvinutá firmou Xerox. Neskôr sa k nej pridali firmy DEC, Intel a vytvorili konzorcium DIX. Ethernetový variant, ktorý toto konzorcium vytvorilo sa označuje ako Ethernet II. Neskôr bol Ethernet normalizovaný inštitúciou IEEE pod názvom CSMA/CD. Ethernetové štandardy vydávané IEEE neobsahujú názov Ethernet, pretože vlastníkom ochrannej značky Ethernet je firma Xerox. Ďalší vývoj Ethernetu sa odohráva už len na pôde IEEE a jej pracovných skupín. Teda každá nová verzia Ethernetu patrí do vývojovej vetvy IEEE Normy popisujú pre každý typ LAN podvrstvu MAC. Obe verzie Ethernetu sú prakticky totožné ale nie úplne identické. Pre všetky systémy je vypracovaná spoločná norma pre podvrstvu LLC pod označením IEEE 802.2, čo schematicky znázorňuje Obr. 1. Obr. 1 Rozdelenie linkovej vrstvy na dve podvrstvy Problematika linkovej vrstvy pre LAN bola takto rozdelená do dvoch podvrstiev. Spodná vrstva MAC (Medium Access Control), čiastočne zasahujúca do fyzickej vrstvy sa zaoberá prístupom na prenosové médium. Horná vrstva LLC (Logical Link Control) umožňuje nadväzovať, spravovať a ukončovať logické spojenia medzi jednotlivými stanicami LAN Uvedené normy IEEE boli prevzaté neskôr organizáciou ISO. Z normy IEEE tak vznikla norma ISO a z normy IEEE norma ISO atď. Postupom času vznikla norma IEEE 802.3u pre 100 Mb/s Ethernet (Fast Ethernet) a norma IEEE 802.3z pre gigabitový Ethernet. Zdroj [1], [3]. 3.2 Protokol Ethernet II Ethernet II definuje základný formát rámca, ktorý je požadovaný pre všetky MAC implementácie. Základný formát rámca obsahuje šesť polí zobrazených na Obr. 2 6

13 Ethernet Rámec protokolu Ethernet II má na začiatku synchronizačnú preambulu (súčasť fyzickej vrstvy), pri ktorej sa synchronizujú všetky stanice prijímajúce rámec. Na konci rámca je kontrolný súčet, z ktorého sa dá zistiť, či nebol rámec prenosom poškodený. Ďalej obsahuje šesťbajtovú linkovú adresu príjemcu a odosielateľa, pole špecifikujúce protokol vyššej vrstvy (tj. sieťovej vrstvy) a vlastné prenášané dáta. Dátové pole musí byť minimálne 46 bajtov dlhé, takže v prípade, že je potreba prenášať menej dát, tak sa dátové pole sprava doplní bezvýznamnou výplňou Formát rámca Obr. 2 Formát rámca Ethernet II Prvé tri bajty fyzickej adresy (MAC adresy) špecifikujú výrobcu sieťovej karty a zvyšné tri bajty špecifikujú kartu v rámci jedného výrobcu, takže adresy sú celosvetovo unikátne. Toto platí len pre tzv. globálne adresy, ktoré sú celosvetovo jednoznačné. Pri inicializácii karty ovládačom sa môže karte oznámiť aby nepoužívala túto adresu ale adresu inú. V rámci firmy je tak možné používať vlastný systém linkových adries. V poli Protokol (Prot.) nájdeme identifikátor protokolu, ktorý je ethernetovým rámcom prenášaný. Pre IP protokol je to číslo , pre ARP protokol číslo , pre RARP V tomto poli je aj hlavný rozdiel medzi veziami Ehernet II a IEEE Pri sa na tomto mieste udáva dĺžka prenášaných dát. Našťastie je vždy možné korektne rozoznať obe verzie, pretože najväčší ethernetový rámec má dĺžku 1500 bajtov a všetky identifikátory obsahu rámca (pri Ethernet II) sú číselné konštanty väčšie než Tým pádom môžu oba typy ethernetových rámcov vedľa seba koexistovať na jednej sieti a príslušné ovládače sú vždy schopné rozoznať, ktorý rámec je akého typu. Zdroj [2],[3]. 3.3 Protokol IEEE CSMA/CD Situácia so štandardom je oproti štandardu Ethernet II o niečo zložitejšia. Dátový rámec protokolu IEEE sa síce líši iba v jednom poli oproti protokolu, avšak dátové pole nemusí niesť v sebe priamo dáta, ale paket protokolu IEEE (LLC podvrstva), ktorého 7

14 Ethernet záhlavie môže byť rozšírené ešte o ďalšie dve polia tvoriace tzv. SNAP (Obr. 1Obr. 3). Teda stanice môžu medzi sebou komunikovať: Klasickými rámcami protokolu Ethernet II (bez LLC a bez SNAP). Rámcami protokolu IEEE 802.3, v ktorých je zabalený protokol LLC bez SNAP. Rámcami protokolu IEEE 802.3, v ktorých je zabalený protokol LLC spolu so SNAP Formát rámca Obr. 3 Rámec ISO a SNAP Pole Dĺžka vyjadruje dĺžku prenášaných dát. DSAP/SSAP špecifikujú cieľovú aplikáciu resp. zdrojovú aplikáciu, ktorá rámec odosiela resp. prijíma. Napr. pre IP-protokol sa používa DSAP=SSAP=AA 16 a pre NetBIOS sa používa DSAP=SSAP=F0 16. Pri použití protokolu IEEE je možné doručovať dáta až k jednotlivým aplikáciám bežiacim na stanici. Existujú aj sieťové protokoly, ktoré pre komunikáciu na LAN používajú iba túto adresáciu (nepoužívajú sieťovú vrstvu). Použitie takýchto protokolov je síce efektívne (o jednu vrstvu rýchlejšie), ale sú nesmerovateľné, tj. Sú určené iba pre LAN a nie pre WAN. Príklad takéhoto exotického protokolu je napr. NetBEUI. Riadiace pole je analogické riadiacemu poľu HDLC. Medzi stanicami môže komunikovať pomocou U, I a S-rámcov. Rámce môžu byť číslované, v prípade straty alebo chyby v rámci môže byť vyžiadaná retransmisia. Pre potreby protokolu IP sa používajú iba U rámce a P/F bit je nastavený na nulu, tj. Riadiace pole má hodnotu

15 Ethernet Pomocou záhlavia SNAP (Sub-network Acces Protocol) je možné špecifikovať protokol vyššej vrstvy, jedná sa teda o obdobu poľa protokolu v Ethernet II. Taktiež sa používajú aj rovnaké hodnoty pre špecifikáciu vyššej vrstvy. Zdroj [2],[4]. 3.4 Virtuálne LAN (VLAN) Jednou z nevýhod použitia smerovačov je isté spomalenie (latencia), ktoré vzniká pri vysielaní dát zo smerovača do siete. Je to spôsobené tým, že proces smerovania paketu z jednej LAN do druhej potrebuje analyzovať viac dát z paketu a potom musí vybrať rozhranie, kam sa má paket odvysielať. Vitruálna LAN, VLAN môže byť chápaná ako skupina zariadení na fyzicky rôznych LAN segmentoch, ktoré môžu komunikovať akoby boli na spoločnom LAN segmente. Vo všeobecnosti je teda možné vybudovať sieť nezávisle na fyzickom umiestnení jej prvkov. Sieť môže byť vybudovaná napríklad na základe komunikačných potrieb. Napríklad ak je nejaká divizia firmy umiestnená v troch rôznych lokáciach je možné zabezpečiť spojenie zariadení tak akoby boli na jednom mieste. Obr. 4 Topológia virtuálnych LAN Sieťové zariadenia môžu do každého rámca pridávať značku, ktorá hovorí do ktorej virtuálnej siete daný rámec patrí. Takéto rámce sú potom doručené len tým zariadeniam, ktoré 9

16 Ethernet patria do danej virtuálnej LAN siete. Značkovať rámce môžu buď priamo koncové stanice (označované ako VLAN-aware zariadenia) alebo medziľahlé sieťové prvky (prepínače). Značky je možné pridávať v podstate podľa ľubovolných kritérií, napr. podľa typu sieťového protokolu ktorý je obsiahnutý v rámci. Môžeme mať teda vedľa seba virtuálne siete komunikujúce protokolom IP alebo IPX a tieto stanice budú od seba oddelené. Najčastejším kritériom je pridelovanie značiek podľa portu prepínača na ktorom je koncová stanica umiestnená. Tak dosiahneme oddelenie jednotlivých počítačov do samostatných virtuálnych sietí. Súčasťou štandardu je tiež protokol GVRP (GARP VLAN Registartion Protocol), ktorý umožňuje VLAN koncovej stanici zaregistrovať si u najbližšieho prepínača príjem rámcov patriacich do vyžadovanej LAN Prínosy VLAN Zvýšená výkonnosť siete: Zoskupovanie zariadení pomáha zvýšiť výkonnosť hlavne vďaka znižovaniu broadcast komunikácie, ktorá sa uzatvára do menších broadcast domén. Lepšia manažovateľnosť siete: VLAN umožňuje ľahký, flexibilný a menej nákladný spôsob modifikovania logických skupín v meniacom sa prostredí. VLANy umožňujú centralizovanú správu rozsiahlych a fyzický vzdialených sietí. Ladenie siete a jednoduchšia softvérová konfigurácia: VLAN umožní administrátorovi doladiť výkonnosť siete podľa potrieb vďaka zoskupovaniu na základe potrieb komunikácie. Nezávislosť na fyzickej topológii: VLAN poskytuje nezávislosť od fyzickej topológie siete a to tak, že dovoľuje zoskupovať zdroje na sieti podľa logických väzieb do viacerých broadcast domén. Zvlášť užitočné to je pri presunoch zariadení, keď sa sieťová konfigurácia strojov nemení ak sú členmi VLAN siete. Stroj si jednoducho ponechá svoju IP adresu aj pri premiestnení. Vyššia úroveň bezpečnosti: VLAN sieť má vyššiu úroveň bezpečnosti, ktorú siete so zdieľaným médiom nemôžu dosiahnuť. V prepojovanej sieti sú rámce doručované len k adresátovi a broadcast rámce len členom VLANu. Toto umožňuje administrátorovi oddeliť pomocou VLAN stroje s citlivými dátami a ich komunikáciu od bežných účastníkov siete. A navyše účastník VLAN siete môže vidieť vo svojom sieťovom porte len komunikáciu danej VLAN siete teda logickej 10

17 Ethernet topológie siete. Tým sa znižuje možnosť sniffingu celej siete v jednotlivých lokalitách a v sieti ako celku [6]. VLAN značenie taktiež umožňuje niesť v rámcoch informácie o prioritách, a to aj vtedy keď rámec nebol zaradený ako patriaci k niektorej z VLAN Obmedzenia VLAN Obmedzenie pri broadcaste: Niektoré sieťové protokoly, ktoré môžu existovať v VLANe, ako napríklad IPX, AppleTalk sú citlivé a vyžadujú spoľahlivosť broadcastov. Dôsledkom tohto sú určité prahové hodnoty na prepínačoch a broadcast servri, ktoré obmedzujú veľkosť VLAN sietí. Obmedzený počet zariadení: Maximálne je možné použiť 4096 virtuálnych LAN (VLAN). Toto je technický limit a v závislosti na sieti a jej výkonnosti môže v reálnom živote dôjsť k ďalšiemu poklesu počtu použiteľných portov. Obmedzenie kôli starším zariadeniam: Niektoré, hlavne staršie, sieťové zariadenia neumožňujú aby ich porty patrili rôznym VLAN sieťam. V praxi sa teda môže stať, že všetky porty a teda všetky počítače pripojené k nejakému staršiemu hub-u budú musieť patriť to toho istého VLANu [6] Štruktúra rámca podľa 802.1q (VLAN) IEEE 802.1Q používa interný značkovací mechanizmus, ktorý vkladá 4-bajtové pole do pôvodného ethernetového rámca medzi zdrojovú adresu a pole Typ/Dĺžka. Pretože týmto sa rámec zmení, musí byť znova prepočítané pole FCS na modifikovaný rámec. Obr. 5 Formát rámca podľa 802.1q Obr. 6 Detail poľa Tag 11

18 Ethernet Popis jednotlivých polí TPID Tag Protocol Identifier - Je to 16 bitové pole. Nastavuje sa na hodnotu 0x8100 za účelom identifikácie typu rámca ako IEEE 802.1Q-označený rámec. Priorita - Tiež nazývaná ako užívateľská priorita, toto 3-bitové pole odkazuje na IEEE 802.1p prioritu. Ethernet sám o sebe neobsahuje žiadne riadenie priority rámcov. Pôvodne mal pre táketo riadenie vzniknúť štandard 802.1p, ktorý bol ale zahrnutý do štandardu 802.1Q. Stupeň priority, sa využíva pre uprednostňovanie prevádzky. Pole môže reprezentovať 8 úrovní priorít (0 7). CFI Canonical Format Indicator - 1-bitové pole označujúce či sa jedná o kanonický formát MAC adresy (hodnota 0), alebo nekanonický (hodnota 1). Kanonický tvar je little endian (ten sa používa v ethernete), nekanonický je big endian (používaný v Token Ring a FDDI) [2]. VID VLAN Identifier - Je to 12-bitové pole. Priraďuje jednotlivé rámce k nim zodpovedajúcim virtuálnym LAN. Pole môže nadobúdať hodnoty medzi 0 a Veľkosť rámca VLAN Štandard 802.1Q priniesol teda zmenu oproti a to rozšírenie rámca celkovo o 4 bajty. Takže z pôvodných 1518 bajtov pri štandarde na 1518 bajtov pri štandarde 802.1Q. Tento problém sa rieši zväčšením veľkosti vyrovnávacej pamäti. Teda pre stanice ktoré nie sú pripravené na VLAN a zvládajú len jednu LAN sieť, musí túto značku prepínač odstrániť. Zariadenia komerčných výrobcov s touto záležitosťou počítajú a dodávajú zariadenia s vyrovnávacími pamäťami 1530 až 1600 bajtov, niektoré zariadenia počítajú s veľkosťou rámcov až cca 14 kb. Minimálna dĺžka rámca označeného ako 802.1Q je 68 bajtov. Zdroj [2],[5],[6]. 12

19 4 IP (Internetový Protokol) Niektoré linkové protokoly sú určené pre prenášanie dát v rámci siete, iné linkové protokoly dopravujú dáta medzi susednými smerovačmi rozsiahlej siete. IP-protokol pracujúci na sieťovej vrstve na rozdiel od linkových protokolov dopravuje dáta medzi dvomi ľubovoľnými počítačmi v internete, t.j. cez mnohé LAN. Dáta sú od odosielateľa k príjemcovi dopravované (smerované) cez smerovače (router). Na ceste od odosielateľa k príjemcovi sa môže vyskytnúť celý rad smerovačov. Každý smerovač rieši samostatne smerovanie k nasledujúcemu smerovaču. Dáta sú takto posielané od smerovača k smerovaču. V angličtine sa v tomto kontexte používa termín next hop, ako nasledujúci uzol kam sa dáta posielajú. Uzol môže byť smerovač alebo cieľový stroj. IP-protokol je tvorený niekoľkými čiastkovými protokolmi: Vlastným protokolom IP. Služobným protokolom ICMP, slúži hlavne k signalizácii mimoriadnych stavov. Služobným protokolom IGMP, slúži na prepravu adresných obežníkov. Služobnými protokolmi ARP a RARP, ktoré sú často vyčleňované ako samostatné na IP nezávislé protokoly, pretože ich rámce nemajú IP záhlavie. 4.1 Formát rámcov Internetového protokolu Obr. 7 Formát záhlavia IPv4 13

20 IP (Internetový protokol) Popis jednotlivých polí v záhlaví IPv4 Verzia (Version) je prvá položka záhlavia IP paketu. Táto položka, dlhá 4 bity, obsahuje verziu IP protokolu. V tomto prípade ide o verziu 4. Dĺžka záhlavia (header legth) obsahuje dĺžku záhlavia IP paketu. Dĺžka nie je uvádzaná v bajtoch ale v štvorbajtoch, teda napr. dĺžka 20 B bude označená hodnotou 5, lebo 5x4=20. Dĺžka záhlavia musí byť aj v prípade použitia voliteľných položiek násobkom štyroch. Ak by záhlavie nevyšlo na násobok štyroch, bude sa dopĺňať bezvýznamnou výplňou. Maximálna dĺžka záhlavia IP paketu je obmedzená 4 bitovou veľkosťou tejto položky ( =F 16 =15 10 ). Dĺžka záhlavia IP paketu je teda obmedzená na maximálnych 60 B (=15x4). Keďže povinné položky majú 20 B, tak na voliteľné položky zostáva maximálne 40 B. Typ služby (type of service TOS) je položka, ktorá v praxi nenašla svoje uplatnenie. V dokumentoch RFC 791 a RFC 1349 sa nachádzajú konkrétne návrhy využitia. Zámer spočíval v nedostatku pôvodného IP protokolu, že nezaručuje šírku prenosového pásma medzi účastníkmi. Práve pomocou tejto položky je možné označiť niektoré IP pakety, tak aby boli dopravované prednostne alebo aby bola zaručená rýchla odozva. Toto sa využíva napr. aj na indentifikáciu diferencovaných služieb. Celková dĺžka IP paketu (total length) v bajtoch. Keďže je táto položka dvoj-bajtová, tak maximálna dĺžka IP paketu je B. Identifikácia IP paketu (identification) vkladá ju do IP paketu operačný systém odosielateľa. Toto pole sa spolu s položkami príznaky (flags) a posunutie fragmentu (fragment ofset) využíva mechanizmom fragmentácie paketu. Obr. 8 Príznaky (flags) v záhlaví IPv4 Ak je DF bit nastavený na 1, potom je fragmentácia zakázaná. Nastavenie na 0 naopak znamená že fragmentácia je možná. Nastavením bitu MF na 1 sa potom označuje to že sa nejedná o posledný fragment. 14

21 IP (Internetový protokol) Posunutie fragmentu od začiatku indikuje, do ktorej časti originálneho datagramu fragment patrí. Hodnota je násobkom 8 oktetov od začiatku originálneho datagramu. Hodnota tohto poľa pri prvom fragmente je nula. Doba života paketu (time to live TTL) slúži k zamedzeniu nekonečného túlania IP paketu Internetom. Každý smerovač kladnú položku TTL znižuje aspoň o jednotku. Ak už nie je možné hodnotu znížiť, IP paket sa odhodí a odosielateľovi je to signalizované protokolom ICMP. U príkazov ping a traceroute je možné túto hodnotu explicitne nastaviť. Vo všeobecnosti sa však jedná o parameter operačného systému. Protokol vyššej vrstvy (protocol) obsahuje číselnú identifikáciu protokolu vyššej vrstvy. V praxi sa zriedka vyskytne prípad, že by sa komunikovalo priamo s IP protokolom. Vždy je použitý protokol vyššej vrstvy (napr. TCP alebo UDP) alebo jeden zo služobných protokolov ICMP alebo IGMP. Protokoly ICMP a IGMP sú síce formálne súčasťou protokolu IP., avšak chovajú sa ako protokoly vyššej vrstvy, t.j. v prenášanom pakete je záhlavie IP protokolu a nasleduje záhlavie protokolu ICMP (resp. IGMP). Čísla priraďuje protokolom organizácia IANA. Priradené čísla je možné nájsť na adrese Kontrolný súčet z IP záhlavia (header checksum) obsahuje kontrolný súčet, ale len IP záhlavia a nie celého datagramu. Jeho význam je teda obmedzený. Bližšie informácie o výpočte kontrolného súčtu sú v RFC 1071 a RFC Problém s kontrolným súčtom spočíva v tom, že keď smerovač zmení nejaké pole v záhlaví IP paketu (napr. TTL sa vždy musí zmeniť), potom musí zmeniť aj hodnotu kontrolného súčtu. IP adresa odosielateľa a IP adresa príjemcu (source and destination adress) obsahuje štvorbajtovú adresu odosielateľa a príjemcu paketu. Ďalšie možnosti (Options) má premenlivú dĺžku a je určené pre meracie účely a bezpečnostné vlastnosti. Doplnok (Padding) má tiež premenlivú dĺžku a obsahuje samé nuly, tak aby bolo dosiahnuté zarovnanie na 32 bitov. Zdroj: [2],[7],[8] Fragmentácia MTU (Maximum transfer unit) je hodnota udávajúca maximálnu veľkosť prenosovej jednotky na úrovni sieťového rozhrania (v našom prípade ethernetového prenosového rámca). IP pakety sú prenášané medzi počítačmi, ktoré nemusia byť navzájom prepojené, tým pádom cez mnoho sietí LAN. Problém nastáva vtedy ak je IP paket väčší ako maximálna možná veľkosť rámca protokolu nižšej vrstvy. A práve hodnota maximálnej možnej veľkosti rámca 15

22 IP (Internetový protokol) protokolu nižšej vrstvy je označovaná ako maximálna veľkosť prenosovej jednotky (MTU). V lokálnej nie je možné prenášať IP datagram väčší než je MTU danej siete. Protokol IP umožňuje rozdelenie veľkého IP paketu na menšie celky (fragmenty). Každý fragment je samostatný IP paket má svoje (nové) záhlavie. Každý fragment potom putuje k cieľu samostatne nezávisle na ostatných. U príjemcu sú jednotlivé fragmenty poskladané a je z nich postavený pôvodný celok IP paket. Po rozdelení IP paketu na fragmenty majú všetky fragmenty rovnaký identifikátor (atribút IP záhlavia). Práve podľa tohto identifikátora pozná príjemca fragmenty, ktoré spoločne tvoria celok. Každý fragment má v záhlaví tiež údaj o svojej polohe v pôvodnom IP pakete (pole posunutie fragmentu od začiatku alebo fragmet ofset). IP pakety môže skladať len príjemca. Žiadny iný počítač už nesmie fragmenty skladať do jedného celku. Nie je totiž zaručené, že všetky pakety pôjdu rovnakou cestou. Preto by mohol mať počítač, ktorý by sa pokúsil zložiť IP paket z fragmetov, problém ak k nemu nejaký paket vôbec nedorazil. Zdroj [9] Záhlavie Internetového Protokolu verzie 6 Podstatnou motiváciou vývoja IPv6 je obmedzenosť používanej adresovacej štruktúry v IPv4. IPv6 má oproti IPv4 nasledovné prednosti: Rozšírené možnosti adresovania (128 bitová IP adresa). Zjednodušenie základného dátového formátu (zredukovaný počet polí v záhlaví). Lepšia podpora rozširovania záhlavia dátového formátu. Podpora označovania tokov. Aspekty zabezpečenia. Záhlavie protokolu IPv6 sa skladá z nasledovných polí. Pole trieda dát sa skladá zo štyroch bajtov, t.j. nadobúda hodnoty 0 až 15. Špecifikuje prenášané dáta pre prípad rozhodovania v okamžiku zahltenia siete. V tomto poli sa špecifikuje, ktoré IP pakety je možné zahodiť skôr ako ostatné. Pole identifikácia toku dát spolu s adresou odosielateľa jednoznačne identifikuje jeden tok dát v internete. Nevýhodou smerovania v internete je, že jednotlivé IP pakety sa dopravujú samostatne, t.j. ak internetom prechádza tok IP paketov medzi dvoma aplikáciami, potom smerovače na ceste riešia smerovanie pre každý paket samostatne. V prípade tokov sa rieši len smerovanie toku ako celku. 16

23 IP (Internetový protokol) Pole dĺžka dát špecifikuje dĺžku IP paketu bez základného záhlavia. Kedže je toto pole dlhé 2 bajty, tak najväčšia dĺžka prenášaného IP paketu môže byť bajtov. Je však možné prenášať aj väčšie pakety, čo je treba špecifikovať v poli ďalšie záhlavie. Pole ďalšie záhlavie v základnom záhlaví ukazuje aký typ dát ( aké záhlavie ) nasleduje za základným záhlavím. Teoreticky môže ukazovať na TCP segment alebo iný protokol vyššej vrstvy. Avšak môže tiež ukazovať na ďalšie rozširujúce záhlavia IP protokolu. Pole počet hopov v podstate zodpovedá položke TTL v IPv4. Zdroj [7]. 4.2 Kvalita služby v internete V internete sa pre prenos a spojovanie IP paketov používala donedávna predovšetkým metóda Best Effort. Pri tejto metóde sa zabezpečí, že všetky pakety rôznych dátových tokov sú rovnako spracované. Best Effort smerovač zhromažďuje všetky IP pakety pre určitý výstup do jedného čakacieho radu typu First in First out. Už pri vývoji IP sa predpokladali rôzne stupňe QoS, neboli však využívané. Neskôr organizácia IETF (Internet Engineering Task Force) navrhla dva nové prístupy k zavádzaniu QoS do IP sietí. Tieto nové internetové QoS modely sú známe ako IS (Integrated Services) architektúra, a DS (Differentiated Services) architektúra Integrované služby (IS) Model QoS nazývaný integrované služby predpokladá záruky QoS pre jednotlivé dátové toky po celej trase medzi zdrojovou a cieľovou stanicou. Špecifikácie pre IS nájdeme v RFC V rámci integrovaných služieb sú definované dve triedy QoS: Služba s riadenou záťažou [12] v tomto prípade je zaručené, že pakety patriace príslušnému dátovému toku budú zahadzované ako posledné. Služba s garantovanými parametrami [13] aplikácia tu získava záruku, že sa jej pakety nebudú strácať a ich oneskorenie na trase bude obmedzené danou hodnotu. Aj keď špecifikácia integrovaných služieb je nezávislá na protokole, ktorým sa aktívnym prvkom v sieti signalizujú rezervačné požiadavky aplikácií, v praxi sa pre tento účel používa výhradne protokol RSVP [14], ktorý je prenášaný pomocou IP. RSVP definuje niekoľko typov správ, ktoré sa rozlišujú pomocou osembitového poľa v záhlaví protokolu. Formát RSVP záhlavia možno nájsť [14]. 17

24 IP (Internetový protokol) Diferencované služby (DS) Špecifikácie DS sú definované v niektorých návrhoch IETF a v RFC dokumentoch (RFC 2474, RFC 2475). Diferencované služby vznikli ako alternatíva voči integrovaným službám kvôli nevýhodám protokolu RSVP, ktoré by sa prejavili ak by bolo potrebné realizovať rezerváciu naprieč celým internetom. Pre veľmi zaťažené smerovače, prenášajúce státisíce tokov by boli nároky na pamäť (uchovávanie stavových dát) a výpočtovú kapacitu extrémne. DS architektúra je založená na zoskupovaní dátových tokov do malého počtu tried (Class of Service CoS) a im zodpovedajúcich kvalitatívnych typov služieb. Na rozlišovanie dátových paketov od rôznych zákazníkov v DS podporujúcich sieťových zariadeniach je IP paket modifikovaný v špeciálnom poli. Je to malá jedno bajtová vzorka nazývaná DS pole. DS pole využíva priestor prvého TOS oktetu v IPv4 záhlaví a triedu prevádzky v IPv6 záhlaví Per-hop behavior (PHB) Každé sieťové zariadenie podporujúce DS musí mať informácie ako by mali byť pakety s odlišným DS poľom obslúžené. V špecifikácii DS sa táto informácia nazýva per-hop behavior (PHB). Je to popis forwardovacieho postupu pre paket prijatý na daný sieťový uzol. Hodnota DSCP v poli DS je použitá k vybratiu PHB na každom uzle. Na prevádzkovanie predpokladaných služieb, musí byť PHB dostupné vo všetkých sieťových smerovačoch. PHB môže byť popísané ako súbor parametrov vo vnútri smerovača, ktoré môžu byť využité na riadenie toho ako sú pakety zoradené na výstupné rozhranie. Takto môže byť zoradených viac oddelených radov s nastavenými prioritami, parametrami pre dĺžku radu, alebo vyraďovacie algoritmy a vyraďovacie vlastnosti pre hodnoty paketov. Obr. 9 Formát DS poľa Pole DS používa šesť bitov pre určenie hodnoty typu diferencovaných služieb (DSCP Differentiated Service Code Point). Táto hodnota bude využívaná každým uzlom v sieti pri voľbe PHB. Dvoj-bitové momentálne nevyužité pole (CU) je rezervované. V prípade ak je PHB použité pre prijaté pakety, je hodnota bitov v poli CU je ignorovaná uzlami 18

25 IP (Internetový protokol) spracovávajúcimi diferenciálne služby. Obr. 9 ukazuje štruktúru definovaného DS pola. Zdroj [10], [11]. 19

26 5 Protokoly transportnej vrstvy 5.1 Úvod Táto kapitola poskytuje prehľad najdôležitejších bežných protokolov TCP/IP transportnej vrstvy. Sú to: TCP UDP Termínom TCP/IP sa zvykne označovať rodina protokolov IP, TCP a UDP, ako aj referenčný model týchto protokolov. Pri diskusii o sieťových protokoloch sa zvykne porovnávať s referenčným modelom ISO/OSI, čo je sedem vrstvový štandardný model určený pre sieťovú komunikáciu (nebudeme ho bližšie rozoberať, vymenujeme len vrstvy: fyzická, linková, sieťová, transportná, relačná, prezentačná, aplikačná). Obr. 10 Porovnanie referenčných modelov TCP/IP a ISO OSI Prvým dvom vrstvám v referenčnom modeli OSI/ISO prislúcha v modeli TCP/IP vrstva, ktorá sa zvykne označovať ako vrstva prístupu do siete (host-to-network layer) a nie je bližšie špecifikovaná. Vyžaduje sa od nej iba to, aby vedela prenášať pakety vrstvy IP. Tretej vrstve ISO/OSI prislúcha vrstva IP (internet protokol). Tento protokol je nespoľahlivý (negarantuje doručenie paketu v sieti) protokol, ktorý nevytvára spojenia (pred samotnou komunikáciu oboch strán nie je fáza, ktorá by vytvorila spojenie medzi koncovými stanicami, na konci sa spojenie neruší) a posiela po sieti dátové jednotky nazvané pakety (prúd dát rozdelený na menšie skupiny s doplňujúcimi informáciami, určenými na prenos). Štvrtej vrstve v modeli 20

27 Protokoly transportnej vrstvy ISO/OSI prislúcha protokol TCP (Transmission Control Protokol) ako aj protokol UDP (User Datagram Protokol). V súčasnosti je TCP protokol dominantným protokolom používaným v IP sieťach. Vrstve 5 a 6 v modeli ISO/OSI neprislúcha žiaden protokol v modeli TCP/IP. Siedmej vrstve ISO/OSI prislúcha rovnako nazvaná vrstva v modeli TCP/IP - aplikačná vrstva. Sem sa zvyknú zaradiť všetky protokoly, ktoré na svoj prenos používajú protokoly TCP alebo UDP. Patria sem napríklad protokoly TELNET, SSH, FTP, HTTP, NFS a mnoho ďalších. 5.2 Porty a sokety Na základe funkčnosti poskytovanej IP, transportné protokoly doručujú dáta aplikáciám bežiacim na hostiteľskom počítači. To je umožnené využitím portov a soketov. Transportné protokoly môžu poskytnúť dodatočné funkcie ako sú riadenie preťaženia, spoľahlivé doručenie dát, potlačenie dupliticity dát, a riadenie toku. Koncept portu a soketu je využívaný na určenie, ktorý lokálny proces v danom počítači skutočne komunikuje s procesom na vzdialenom počítači, s použitím akého protokolu. Poskytuje spôsob rovnomerne a jedinečne identifikovať spojenia a programy a hostiteľov, ktorý sa zúčastňujú spojenia, bez ohľadu na špecifický identifikátor procesu Porty Každý proces, ktorý chce komunikovať s iným, sa identifikuje jedným alebo viacerými portmi. Port je 16 bitové číslo, používané transportnými protoklmi na identifikáciu vyššej protokolovej vrstvy alebo aplikačného programu (procesu), ktorému dodáva prichádzajúce správy. Sú dva typy portov: Well-known (dobre známy): Tieto porty patria k štandardným serverom, napr. Telnet používa port 23. Sú v rozsahu od 1 do Well-known porty sú zvyčajne nepárne, pretože staršie systémy používajúce koncept portov vyžadovali pár portov (párny/nepárny) pre duplexné operácie. Väčšina serverov vyžaduje iba jeden port. Výnimky sú BOOTP server (67 a 68) a FTP server (20 a 21). Well-known porty sú riadené a priraďované IANA (Internet Assigned Number Authority) a na väčšine systémov môžu byť použité iba systémovými procesmi alebo programami spustenými superužívaťeľmi. Dôvodom zavedenia Well-known portov je umožnenie klientom byť schopný nájsť potrebné serveri bez konfiguračných informácii. Well-known porty sú definované v STD 2 - Assigned Internet Numbers. Dočasné (Ephemeral) - Klient nepotrebuje well-known čísla portov, pretože inicializujú komunikáciu so servermi a čísla portov, ktoré použijú sú obsiahnuté v UDP datagramoch 21

28 Protokoly transportnej vrstvy poslaných serveru. Každému klientskému procesu je pridelené číslo portu tak dlho ako je potrebné. Dočasné čísla portov majú hodnoty väčšie než 1023, (rozsah ). Dočasné porty nie sú riadené IANA a môžu byť využité bežnými užívateľskými programami na väčšine systémoch Sokety Soketové rozhranie je jedným z niekoľkých programových aplikačných rozhraní (API) ku komunikačným protokolom. Prvý krát bolo použité v BSD 4.2. Aj keď nebolo štandardizované, stalo sa de facto priemyselným štandardom. 5.3 Základný popis protokolu TCP TCP je štandardný protokol s STD číslom 7. Je popísaný v RFC 793. TCP poskytuje niektoré rozšírené funkcie oproti UDP, napr. opravu chýb, riadenie toku a spoľahlivosť. TCP je spojovo-orientovaný protokol, na rozdiel od UDP. Väčšina užívateľských aplikačných protokolov, ako je TELNET a FTP, používa TCP. Cieľom protokolu TCP je prenos dát, ktorý by sa dal charakterizovať nasledovnými vlastnosťami: spojovaný (pred samotným vysielaním dát sa vytvorí spojenie) potvrdzovaný (pre každý poslaný segment (jednotka posielaná po sieti na úrovni protokolu TCP) sa generuje potvrdzovacia správa ACK) spoľahlivý (protokol garantuje, že sa dáta prenesú, alebo ak to nie je možné, tak to oznámi vyššej vrstve) zachovávajúci poradie prenášaných údajov (dáta prichádzajú vyššej vrstve v tom poradí v akom boli vyslané) 22

29 Protokoly transportnej vrstvy Formát TCP segmentu Obr. 11 Formát TCP segmetu Kde: Zdrojový port: 16-bitové číslo užívateľského procesu v zdrojovom počítači, ktorý inicializoval spojenie. Cieľový port: 16-bitové číslo užívateľského procesu v cieľovom počítači, do ktorého sú dáta adresované. Poradové číslo odosielaného bajtu: Údaj čísluje vyslané TCP segmenty. Poradové číslo prijatého bajtu: Slúži cieľovému počítaču pre potvrdenie prijatého TCP segmentu. Ak je ACK riadiaci bit nastavený, potom toto pole obsahuje hodnotu nasledujúceho poradového čísla, ktoré príjemca očakáva. Dĺžka záhlavia: Počet 32-bitových slov v TCP záhlaví. Označuje kde sa začínajú dáta. Rezerva: 6 bitov rezervovaných pre prípadné použitie v budúcnosti. Musia byť nulové. Riadiace flagy: slúžia k dodatočnému riadeniu virtuálnych spojení. URG: Indikuje, že pole naliehavosti je v tomto segmente označené. ACK: Indikuje, že pole pre potvrdzovanie je v tomto segmente označené. PSH: funkcia Push. RST: Obnovenie spojenia. 23

30 Protokoly transportnej vrstvy SYN: Synchronizuje poradové čísla. FIN: Žiadne ďalšie dáta od zasielateľa. Ukončenie vysielania. Dĺžka okna: Používané v ACK segmentoch. Týmto údajom, ktorý sa využíva k riadeniu toku pomocou oknového mechanizmu, riadi cieľový počítač počet vyslaných dátových jednotiek bez potvrdenia. Kontrolný súčet: 16-bitový doplnok. Umožňuje na prijímacej strane skonštatovať, či IP záhlavie ako aj TCP záhlavie bolo prenesené bezchybne (bez bitovej chyby). Ukazovateľ naliehavých dát: TCP protokol umožňuje dôležité (naliehavé) a najčastejšie krátke správy zasunúť do normálnych dát a takto ich preniesť komunikačnému partnerovi. Takéto dáta sú označované ako Naliehavé dáta. Ukazovateľ označuje polohu týchto dát v prenášanom toku ostatných dát Voliteľné položky TCP záhlavia Povinné položky tvoria 20 B. Za povinnými položkami môžu nasledovať voliteľné položky. Voliteľná položka sa skladá z typu voliteľnej položky, dĺžky voliteľnej položky a hodnoty. Dĺžka TCP záhlavia musí byť deliteľná štyrmi. V prípade, že dĺžka záhlavia by nebola deliteľná štyrmi, potom sa záhlavie doplňuje prázdnou voliteľnou položkou NOP. Keďže pole dĺžka záhlavia je dlhé len 4 bity, potom toto pole môže nadobúdať maximálnu hodnotu = Dĺžka záhlavia sa udáva v násobkoch štvorky, teda záhlavie môže byť dlhé maximálne 15x4 = 60 bajtov. Povinné položky zaberú 20 bajtov, takže na voliteľné zostáva najviac 40 bajtov. Niektoré voliteľné položky záhlavia vrátane ich štruktúry sú uvedené na Obr. 12 Obr. 12 Niektoré voliteľné položky záhlavia TCP 24

31 Protokoly transportnej vrstvy Napríklad použitím TCP voľby timestamp, odosielateľ umiestni časovú značku do každého dátového segmentu a príjemca posiela tieto značky späť segmentoch ACK. Potom jednoduchým odčítaním dostane odosielateľ presnú hodnotu tzv. RTT (Round-Trip Time) pre každý ACK segment. Táto metóda sa nazýva RTTM (RTT Measurement). 5.4 Základný popis protokolu UDP UDP je jednoduchá alternatíva popri TCP. V záhlaví IP je identifikovaný STD číslom 17. Protokol UDP podporuje len nespojovo orientovanú službu, t.j. nenadväzuje spojenie. Odosielateľ odošle UDP datagram príjemcovi a už sa nestará o to, či sa náhodou nestratil Formát UDP segmentu Obr. 13 Záhlavie UDP segmetu Z predchádzajúceho obrázku je zjavné, že záhlavie UDP protokolu je jednoduché. Obsahuje čísla zdrojového a cieľového portu. Treba dodať, že čísla portov protokolu UDP nesúvisia s číslami portov protokolu TCP. Protokol UDP má svoju nezávislú sadu čísiel portov. Pole dĺžka dát obsahuje dĺžku UDP datagramu (dĺžku záhlavia + dĺžku dát). Minimálna dĺžka je 8, t.j. datagram obsahuje iba záhlavie a žiadne dáta. Zaujímavé je, že pole kontrolný súčet nemusí byť povinne vyplnené. Výpočet kontrolného súčtu je teda v protokole UDP nepovinný. Fragmentácia je povolená aj pre UDP datagramy. Avšak v UDP protokole sa jej snažíme vyhýbať. Typickým príkladom je DNS. DNS klient zadá požiadavku protokolom UDP. Ak potom odpoveď serveru by mala presiahnuť 512 B, potom server odošle len toľko informácií, aby neprekročil hranicu 512 B a tiež v aplikačných dátach nastaví príznak TC (Truncation) špecifikujúci, že odpoveď bola skrátená. Potom ak klientovi takáto odpoveď 25

32 Protokoly transportnej vrstvy nestačí, tak ju zopakuje protokolom TCP, ktorým mu server vráti kompletnú odpoveď. Zdroj [1], [2], [3], [10], 26

33 6 Návrh koncepcie riešenia Už samotné zadanie diplomovej práce nabáda k rozdeleniu problému na tri časti resp. aplikácie. Okrem samotného generátora, potrebujeme prijímač so schopnosťou filtrovať pakety a forwarder, ktorý okrem schopnosti filtrovania musí zabezpečiť preposlanie paketu späť ku odosielateľovi. Uvedená koncepcia je znázornená na Obr. 14. Obr. 14 Funkcie vyvíjaných aplikácií Na generovanie paketov som použil program packeth, ktorý je dostupný na adrese Tento program je možné distribuovať a upravovať v súlade s podmienkami licencie GNU verzie 2 vydanej organizáciou Free Software Foundation. PackETH je aplikácia s grafickým užívateľským rozhraním pre operačný systém Linux. Umožňuje vytvoriť a posielať mnoho druhov paketov, ktoré vkladá do ethernetového rámca. Pre potreby zadania bolo treba mierne modifikovať zdrojový kód tejto aplikácie. Doplnil som možnosť generovania Poissonovského toku a zhlukovitý charakter toku a možnosť vložiť do dátovej časti paketu časový údaj odoslania paketu, pre neskoršiu analýzu merania oneskorenia paketu v sieti. Aplikácia je naprogramovaná v jazyku C a na generovanie paketov používa soketové rozhranie, ktorého základný popis je uvedený v kapitole 7. Pre Poissonov tok platí, že medzery medzi udalosťami sa riadia exponenciálnym rozdelením a počet udalostí za jednotku času sa riadi Poissonovým rozdelením. Z toho vyplýva, že sa často vyskytujú krátke medzery medzi udalosťami a sem tam sa objaví dlhšia pauza. Na Obr. 15 vidíme príklad simulácie elementárneho toku: Obr. 15 Poissonovský tok 27

34 Návrh koncepcia riešenia Pôvodný program generoval sekvenciu paketov takým spôsobom, že počítal časové medzery medzi paketmi. Z tohto dôvodu som Poissonov tok implementoval tak aby menil dĺžku časovej medzery podľa vzťahu: 1 x = ln( random(0 1)) (1) λ Kde: x dĺžka medzery medzi paketmi, ktoré tvoria poissonovský tok λ priemerný počet paketov vyslaných za 1 sekundu Poissonove rozdelenie náhodnej premennej X má pravdepodobnostnú funkciu a strednú hodnotu a rozptyl ( ) P x = e x! ; x= 0,1, 2, 3,... P x = 0 ; inak ( ) x λ λ (2) E( X) = D( X) = λ. (3) Dá sa dokázať, že keď počet paketov, ktoré prídu do sieťového zariadenia za jednotku času je daný poissonovým rozdelením, potom dĺžka časových medzier medzi príchodmi paketov má exponenciálne rozdelenie s hustotou rozdelenia pravdepodobnosti ( ) ( ) λx f x = λ. e ; x 0, (4) f x = 0 ; x< 0 distribučná funkcia, stredná hodnota a rozptyl (v tomto poradí) exponenciálneho rozdelenia sú: ( ) ( ) λx F x = 1 e ; x 0, (5) F x = 0 ; x< 0 ( ) E X ( ) 2 D X 1 =, (6) λ 1 =. (7) λ Z uvedeného vyplýva, že ak je intenzita príchodov paketov λ (napr. 5 paketov/s), potom je stredná doba medzi príchodmi paketov daná ako 1 (číselne z príkladu 0,2 s). Túto λ súvislosť je možné pozorovať na stredných hodnotách oboch rozdelení, t.j. na vzťahoch (3) a (6). 28

35 Návrh koncepcia riešenia Generovanie náhodných čísel s exponenciálnym rozdelením možno vykonať pomocou inverznej funkcie k distribučnej funkcii. Ak je distribučná funkcia exponenciálneho rozdelenia pre kladné hodnoty argumentu x daná predpisom potom k nej inverzná funkcia je daná predpisom y = 1 e λx, (8) λy λy 1 x = 1 e 1 x= e y = ln( 1 x ). (9) λ Pri generovaní náhodných čísel s exponenciálnym rozdelením s parametrom λ možno využiť vzťah (9), kde za náhodnú premennú rozdelením z intervalu x sa dosadí náhodné číslo s rovnomerným 0;1 ), pričom y je číslo s exponenciálnym rozdelením. Pretože rovnomerné rozdelenie je symetrické, možno vzťah (9) upraviť na tvar: 1 ln ( x) y =. (10) λ Pozn.: Vzťahy (1) a (10) sú totožné. V prípade použitia vzťahu (10) je potrebné generovať náhodné čísla x (0;1. Časová značka odoslania paketu sa vkladá do dátovej časti UDP alebo TCP segmentu s presnosťou na mikrosekundy (v tvare HH:MM:SS.xxxxxx). Ukladá sa vo forme reťazca teda každý vložený znak zväčší veľkosť paketu o jeden bajt. Aplikácia packeth implementuje generovanie sekvencie už vopred postavených paketov. Z toho dôvodu sa neprerátavajú kontrolné súčty záhlaví pred každým odoslaním, ale sú prepočítané len na začiatku. Po vložení času do paketu sa zmenia niektoré polia v jednotlivých záhlaviach protokolov. Konkrétne v IP záhlaví sa zmení pole dĺžka paketu, tým pádom je potrebné znova prerátať kontrolný súčet IP záhlavia aj TCP záhlavia (pretože TCP počíta kontrolu aj z IP). Dĺžka paketu však bude konštantná, keďže pridávame stále rovnako dlhú značku, preto stačí tieto kontrolné súčty prepočítať len na začiatku. Pri UDP datagramoch je situácia ešte jednoduchšia, pretože tu je pole kontrolný súčet nepovinné. Pred každým odoslaním paketu však musíme znova prerátať CRC ethernetového rámca. Pretože každý jeden paket obsahuje inú časovú značku, a preto je z pohľadu rámca iný. Aplikáciu, ktorá na opačnej strane pakety prijíma a posiela späť, som programoval tiež v Linuxe z dôvodu uľahčenia testovania, keďže som mal väčšinu času k dispozícii len jeden počítač. Tento program je tiež naprogramovaný v jazyku C. Na odchytávanie paketov využíva funkcie voľne dostupnej knižnice libpcap (základné funkcie libpcap sú uvedené v kapitole 7). 29

36 Návrh koncepcia riešenia V každom zachytenom pakete ktorý prejde filtrom sa navzájom menia zdrojová a cieľová MAC adresa a tiež zdrojová a cieľová IP adresa. Potom je paket pomocou soketového rozhrania odoslaný späť. Prijímač, ktorý chytá odrazené pakety je veľmi podobný forwarderu pokiaľ sa jedná o zachytávanie a filtrovanie paketov, avšak po zachytení paketu sa snaží analyzovať aj jeho dátovú časť a prečítať hodnotu času ktorú tam vložil generátor. Postup a princíp analyzovania jednotlivých záhlaví som popísal v kapitole 7 po načrtnutí významu niektorých funkcií libpcap. Postup pri spracovávaní prichádzajúcich paketov operačným systémom je znázornený na Obr. 16. Začína sa na úrovni sieťového ovládača, pokračuje rutinami pre spracovanie rôznych rodín protokolov (kapitola 7). Na tomto mieste sa aplikuje filter a do ďalšieho spracovávania prepúšťa len pakety, ktoré vyhovujú definovaným podmienkam, ostatné pakety sú vyradené. V ďalšom procese sa spracovávajú jednotlivé protokoly až kým sa dáta s paketu dostanú ku konkrétnej aplikácii. Obr. 16 Postup pri spracovávaní paketov 30

37 7 Sieťové aplikačné rozhranie v operačnom systéme Linux Aplikácia packeth využíva na posielanie paketov nízko úrovňové soketové rozhranie. Soketové rozhranie je komunikačný nástroj, ktorý bol prvý krát použitý v Berkley UNIXe. Proces na jedom stroji môže soket využiť pri komunikácii s procesom na inom stroji a umožňuje tak vytvárať systémy klient/server distribuované po sieti. Soketové rozhranie bolo použité tiež v systéme Microsoft Windows vďaka verejne dostupnej špecifikácii, známej ako Windows Sockets alebo WinSock. Služby soketu poskytuje systémový súbor Winsock.dll. Vďaka tomu môžu programy v Microsoft Windows komunikovať cez sieť s unixovými počítačmi a obrátene v systéme klient-server. Programové rozhranie pre WinSock nie je síce rovnaké ako sokety v Unixe, ale stále má sokety ako základ. Treba spomenúť, že Soketové programové aplikačné rozhranie (Socket API) nie je jediný spôsob programovania sieťových aplikácii, avšak je najpopulárnejší. Zdroj [9], [15], [16], [17]. 7.1 Posielanie paketov Sokety majú niektoré špeciálne vlastnosti, ktoré sú veľmi podobné súborovým deskriptorom. Napríklad, keď otvoríme súbor použitím linuxového volania open, dostaneme ako návratovú hodnotu súborový deskriptor. Potom môžeme tento deskriptor použiť ako parameter volaní read, write, lseek, close. Keďže v unixových systémoch sa takmer všetko tvári ako súbor, môžeme aj k soketom pristupovať pomocou týchto funkcií. Avšak existujú aj rozdiely medzi soketmi a otvorenými súbormi. V nasledujúcom zozname sú uvedené niektoré z nich: sokety majú sieťové adresy k nim priradené, na rozdiel od súborov, ktoré nemajú sieťové adresy. sokety majú rozdielne voliteľné nastavenia a vlastnosti, na ktoré sa môže odvolávať volanie ioctl(). sokety musia byť v správnom stave pri vykonávaní vstupu alebo výstupu. Naopak do otvorených diskových súborov sa môže zapisovať alebo čítať z nich kedykoľvek. 31

38 Návod na použitie aplikácií Odkazovanie na sokety Súborový deskriptor môže nadobúdať hodnoty 0 alebo kladné celé číslo, ktoré je použité pri odvolávaní sa na daný súbor. Táto obsluha je použitá na všetky ostatné funkcie, ktoré pracujú s otvorenými súbormi. Vieme, že deskriptor súboru môže tiež odkazovať na špecifický soket. Linux nerobí rozdiely medzi súbormi a soketmi keď alokuje deskriptory. To znamená že je možná ich ľubovoľná zámena, čo poskytuje veľké množstvo flexibility Atribúty soketov Soket je charakterizovaný tromi atribútmi: doménou (domain), typom (type) a protokolom (protocol). Majú tiež adresu, ktorá sa používa ako názov. Formáty adries sa líšia podľa domény, tiež rozlišujeme tzv. rodiny protokolov (protocol family). Každá rodina protokolov môže pre určenie formátu adresy použiť jednu alebo viac adresových rodín Soketové domény Domény určujú sieťové médium, ktoré budú používať pri soketovej komunikácii. Najobvyklejšou soketovou doménou je AF_INET, vzťahujúca sa k sieťam na internete. Jedna z ďalších domén je doména unixového systému súborov AF_UNIX, ktorá môže byť využívaná soketmi jedného počítača, ktorý ani nemusí byť v sieti. Ďalšie použiteľné domény sú napr. AF_ISO, použitá u sietí postavených na štandardných protokoloch ISO, alebo AF_NS pre Xerox Network System. Týmto doménam sa ale nebudem venovať, spomenul som ich len kvôli prehľadu. Niekedy sa miesto AF_xxx môžeme stretnúť s doménami PF_xxx. V minulosti bola myšlienka, že možno jedna adresová rodina (AF_INET, "AF" znamená Address Family) by mohla podporovať niekoľko protokolov, na ktoré bude odkazované ich protokolovou rodinou (PF_INET, "PF" znamená Protocol Family). Takže korektné použitie by malo byť že AF_INET sa použije v štruktúre sockaddr_in a PF_INET vo volaní socket(). V neskorších verziách linuxu (od 2.0) bola predstavená nová rodina protokolov s názvom PF_PACKET. Používa ju na odosielanie paketov aj program packeth. Táto rodina umožňuje aplikáciám posielať a prijímať pakety spracovávané priamo s ovládačom sieťovej karty, týmto sa vyhneme zvyčajnej obsluhe paketov v zásobníku (IP/TCP alebo IP/UDP processing). Takže paket poslaný cez socket bude priamo pustený na ethernetové rozhranie, a paket prijatý cez ethernetové rozhranie môže byť priamo spracovaný aplikáciou. 32

39 Návod na použitie aplikácií Typy soketov Prúdové sokety SOCK_STREAM, sú implementované v doméne AF_INET pomocou pripojenia TCP. Oproti tomu datagramový soket, určený typom SOCK_DGRAM, je v doméne AF_INET implementovaný pomocou UDP. Pri týchto soketoch sa nemusíme starať o záhlavia, ale len o prenášané dáta. V rodine soketov PF_PACKET môžeme vytvoriť typy SOCK_DGRAM a SOCK_RAW. Typ SOCK_RAW pracuje aj so záhlavím aj zapätím linkových rámov. Takže pokiaľ chceme generovať rôzne typy ethernetových rámcov, musíme použiť tento typ soketu Soketové protokoly Tam, kde základný prenosový mechanizmus dovoľuje pri poskytovaní požadovaného typu soketu použiť viac protokolov, môžeme zvoliť protokol pre soket Vytvorenie soketu Systémové volanie socket vytvára a vracia deskriptor, ktorý je možné využiť pre prístup k soketu. #include <sys/types.h> #include <sys/socket.h> int socket(int domain, int type, int protocol) Soketové adresy Každá soketová doména vyžaduje vlastný adresný formát. V doméne AF_INET je adresa určená pomocou štruktúry sockaddr_in, definovanej v hlavičkovom súbore netinet/in.h, kde sú zastúpené aspoň tieto členy. struct sockaddr_in { short int sin_family; unsigned short int struct in_addr sin_port; sin_addr; } 33

40 Návod na použitie aplikácií Pomenovanie soketu Aby bol soket k dispozícii ďalším procesom, musí ho program pomenovať. Systémové volanie bind priraďuje adresu, určenú v parametre address nepomenovanému soketu, združenom s deskriptorom súborov. #include <sys/socket.h> int bind(int socket, const struct sockaddr *address, size_t address_len) Zatvorenie soketu Soketové pripojenie sa ukončuje pomocou volania close, rovnako ako u súborových deskriptoroch.[15], [16], [17], [18]. 7.2 Odchytávanie paketov Programy umožňujúce sledovanie sieťovej prevádzky a teda aj odchytávanie paketov sa nazývajú sniffery (sniffers). V linuxe sú najrozšírenejšie tcpdump a ethereal. Oba využívajú funkcie knižnice libpcap. Knižnica libpcap poskytuje implementačne nezávislý prístup k základnému odchytávaniu paketov priamo zo sieťovej karty. Samozrejme, že existujú aj ďalšie spôsoby ako odchytávať pakety, sú to napríklad BPF (Berkley Packet Filter), DLPI (Data Link Provider Interface) a pomocou soketového typu SOCKET_PACKET (iba v Linuxe). Obdoba knižnice pcap sa v operačnom systéme Windows nazýva Winpcap Formát pcap aplikácie Knižnica pcap je podrobne popísaná na manuálových stránkach tcpdump. Začneme určením rozhrania (interface), ktoré chceme sledovať. V Linuxe to môže byť sú väčšinou nazvané eth0, v BSD xl1 atď. Tiež môžeme definovať toto zariadenie v reťazci, alebo môžeme požiadať pcap o poskytnutie názvu rozhrania, s ktorým budeme pracovať. V prípade ak chceme iba sledovať špecifickú prevádzku (napr. Len TCP/IP, atd.) musíme vytvoriť sadu pravidiel, skompilovať ich, a aplikovať. Je to troj-fázový proces. Zoznam pravidiel je uchovávaný v reťazci a je konvertovaný do formátu, ktorý pcap môže čítať (odtiaľ je to spomenuté kompilovanie). Kompilácia je teda v skutočnosti len volaním funkcie vnútri nášho programu. Nepotrebujeme k tomu externú aplikáciu. Potom môžeme toto pravidlo aplikovať na ľubovoľnú reláciu, ktorú chceme filtrovať. Nakoniec voláme funkciu, ktorá čaká kým zachytí ľubovoľné množstvo paketov. Vždy keď zachytí nový paket, volá ďalšiu funkciu, ktorú je potrebné vopred definovať. Táto funkcia môže robiť čokoľvek 34

41 Návod na použitie aplikácií chceme, môže rozčleniť paket a vytlačiť ho užívateľovi, môže ho uložiť do súboru, alebo nemusí urobiť nič Otvorenie zariadenia pre sledovanie Na vytvorenie sledovanej relácie používame funkciu pcap_open_live(). Prototyp tejto funkcie (pcap manulálová stránka) je nasledovný: pcap_t *pcap_open_live(char *device, int snaplen, int promisc, int to_ms,char *ebuf) Funkcia vracia identifikátor relácie. Tak ako pri otváraní súborov, musíme špecifikovať aj tu sledovanú reláciu, tak aby sme mohli od seba jednotlivé relácie rozoznať Filtrovanie prevádzky Často sa náš snifer zaujíma len o špecifickú prevádzku. Na odfiltrovanie zachytávaných paketov slúži filter, ktorý sa definuje funkciami pcap_compile() a pcap_setfilter(). Proces je úplne jednoduchý. Po tom ako sme volali pcap_open_live() a máme fungujúcu sledovanú reláciu, môžeme pomocou uvedených funkcií jednoducho použiť náš filter. Sú dva hlavné dôvody prečo sa nepoužívajú podmienkové príkazy. Prvý je, že filter z knižnice pcap je výkonnejší, pretože má priamy prístup ku BPF filtru, eliminujeme tak veľký počet krokov, pretože BPF to robí priamo. A po druhé je to o mnoho jednoduchšie. BPF (Berkley Packet Filter) je špeciálny jazyk, určený na zapisovanie filtra. BPF sa dosť podobá skutočnému assembleru s množstvom registrov a zopár inštrukciami určenými k ukladaniu, načítavaniu hodnôt, vykonávaniu aritmetických operácií a vykonávaniu podmienených príkazov. Pred použitím nášho filtra ho musíme "skompilovať". Filtrovací výraz je uchovávaný v bežnom reťazci (char array). Syntax je dokumentovaná v manuálových stránkach tcpdump. Na kompilovanie voláme funkciu pcap_compile(). Jej prototyp je: int pcap_compile(pcap_t *p, struct bpf_program *fp, char *str, int optimize, bpf_u_int32 netmask) Prvý argument je identifikátor sledovanej relácie (definovaný funkciou pcap_open_live). Nasleduje odkazom na miesto, kde bude uložená kompilovaná verzia filtra. Potom nasleduje samotný výraz ako reťazec. Ďalej tam je celé číslo, ktoré rozhoduje či bude výraz optimalizovaný alebo nie (0 false, 1 true). Nakoniec špecifikujeme sieťovú masku na ktorú sa má aplikovať filter. Funkcia vracia hodnotu -1 pri zlyhaní, všetky ostatné hodnoty 35

42 Návod na použitie aplikácií označujú úspech. Po tom ako bude výraz skompilovaný, je čas na jeho aplikáciu. Zadáme pcap_setfilter(), ktorého prototyp je: int pcap_setfilter(pcap_t *p, struct bpf_program *fp) To je priamočiare. Prvý argument je náš identifikátor relácie, druhý poukazuje na kompilovanú verziu filtrovacieho výrazu Skutočné odchytávanie Sú dve hlavné techniky odchytávania paketov. Môžeme chytiť len jeden paket, alebo môžeme vstúpiť do cyklu, ktorý čaká na n počet paketov, ktoré sa odchytia. Začneme ukážkou ako sa chytá jeden paket. Pre toto nám slúži pcap_next(). Prototyp je: u_char *pcap_next(pcap_t *p, struct pcap_pkthdr *h) Prvý argument je náš identifikátor relácie. Druhý je ukazovateľ na štruktúru ktorá drží všeobecné informácie o pakete, špecifikuje čas, v ktorom bol paket chytený, dĺžku tohto paketu a dĺžku jeho špecifickej časti (v prípade ak je fragmentovaný). Pcap_next() vracia u_char pointer na paket, ktorý je popísaný touto štruktúrou. Ďalšia technika, ktorú môžeme použiť je viac komplikovaná, ale je aj viac užitočná. Oveľa častejšie sa na odchytávanie paketov používa pcap_loop() alebo pcap_dispatch() (ktorá tiež vlastne volá pcap_loop()). Na porozumenie týmto dvom funkciám treba porozumieť myšlienke spätného volania funkcie (callback). Funkcie callback nie sú nič nové, a sú veľmi bežné v mnohých API. Koncept v pozadí funkcií callback je úplne jednoduchý. Predpokladajme, že máme program, ktorý čaká nejakú udalosť. Napr. Vždy keď je stlačená klávesa, chcem volať funkciu, ktorá potom určí čo robiť. Funkcia ktorú pri tom využijem je callback funkcia. Callback funkcie sú tiež využívané pcap, ale miesto toho aby volané po stlačení klávesy, sa volajú keď je odchytený paket. Dve funkcie, ktoré môžu byť použité sú pcap_loop() a pcap_dispatch(). Ich použitie je tiež veľmi podobné. Obe z nich volajú callback funkciu vždy keď je chytený paket, vyhovujúci naším filtrovacím požiadavkám. Prototyp: int pcap_loop(pcap_t *p, int cnt, pcap_handler callback, u_char *user) Prvý argument identifikátor relácie. Nasleduje celým číslom, ktoré hovorí koľko paketov by malo byť odchytených (záporná hodnota značí že by mal chytať pokým sa neobjaví chyba). Tretí argument je názov identifikátora callback funkcie. Posledný argmunet 36

43 Návod na použitie aplikácií je využiteľný niektorými aplikáciami, ale často býva NULL. Prototyp funkcie callback nemôžeme ľubovolne definovať, ale je treba sa pridržiavať predpísaného protoypu: void got_packet(u_char *args, const struct pcap_pkthdr *header, const u_char *packet); Funkcia má návratový typ void. To je logické, pretože pcap_loop() by aj tak nevedela čo robiť z návratovou hodnotou. Prvý argument korešponduje s posledným vo funkcii pcap_loop(). Akákoľvek hodnota, ktorá je predaná ako posledný argument v pcap_loop(), je použitá ako argument got_packet(). Druhý argument obsahuje informácie o tom kedy bol paket chytený aký je veľký atď. Definícia z pcap.h : struct pcap_pkthdr { struct timeval ts; /* časová značka */ bpf_u_int32 caplen; /* dĺžka odchyteného paketu */ bpf_u_int32 len; /* skutočná dĺžka paketu */ }; Tieto hodnoty sú samo vysvetľujúce. Posledný argument môže byť mätúci. Je to pointer na u_char a ukazuje na prvý bajt chyteného paketu Analyzovanie jednotlivých záhlaví paketu Premenná packet je ukazovateľ (premenná, obsahujúca adresu v pamäti) na reťazec u_char, kde sú uložené dáta paketu. Samotný paket obsahuje mnoho atribútov, takže si môžeme predstaviť že to nie je reťazec ale kolekcia štruktúr. Aby tieto štruktúry mohli byť využiteľné, musíme spraviť pretypovanie tohto u_char ukazovateľa na štruktúry ktoré zodpovedajú formátom záhlaví jednotlivých protokolov. Tieto štruktúry musíme samozrejme definovať pred tým ako chceme začať pretypovávať. V princípe vlastne posudzujeme schému paketu v pamäti. Pre jednoduchosť, povedzme, že adresa ukazovateľa je nastavená na hodnotu X. Potom ak naše tri štruktúry nasledujú za sebou, tak prvá z nich (ethernet) bude umiestnená v pamäti na adrese X. Potom môžeme jednoducho nájsť adresy štruktúr nasledujúcich za ňou. A to tak že X + dĺžka ethernetového záhlavia = IP atď. Podobne ak máme adresu záhlavia, adresu štruktúry za ním získame tak že pripočítame veľkosť daného záhlavia k adrese. IP záhlavie na rozdiel od Ethernetového nemá stálu dĺžku, ale dĺžka je uvedená v záhlaví. Minimálna dĺžka je 20 B. TCP záhlavie má tiež premenlivú dĺžku a jeho dĺžka je tiež daná v záhlaví (data offset) a minimálna je 20 B. Zdroj [19] 37

44 Návod na použitie aplikácií 8 Návod na použitie aplikácií 8.1 Aplikácia packeth Aplikácia packeeth je GUI nástroj umožňujúci generovať pakety v ethernetovej sieti. Podporuje nasledovné protokoly: Ethernet II, IEEE 802.3, 802.1q, QinQ. ARP, IPv4, alebo manuálne užívateľom definované dáta sieťovej vrstvy. UDP, TCP, ICMP, IGMP, možnosť manuálneho definovania transportnej vrstvy. RTP (s možnosťou odoslať vzorky harmonického signálu s ľubovoľnou akustickou frekvenciou pri použití kodeku G.711) Podporuje tiež posielanie sekvencií paketov: s možnosťou zadávania časového oneskorenia a počtu paketov na odoslanie. posielanie s maximálnou rýchlosťou, ohraničenou len teoretickými medzami. Zmena parametrov počas posielania (zmena IP a MAC adresa, UDP dáta, dva užívateľom definované bajty, atď.) A samozrejme možnosť uloženia konfigurácie do textového súboru a opätovného načítania, bez potreby znova definovať jednotlivé polia paketu. Keďže ku aplikácii packeth neexistuje žiadna dokumentácia, pokúsim sa objasniť jej základné ovládanie a možnosti Inštalácia a spustenie Aplikáciu je potrebné pred použitím skompilovať tak aby mohla byť spustená na konkrétnej distribúcii. Ak máme potrebné knižnice, uvedené v súbore Makefile, tak by sa mala aplikácia zostaviť do spustiteľnej podoby po zadaní príkazu make. Týmto príkazom sa vytvorí súbor s názvom packeth a ten spustíme jednoduchým zadaním príkazu./packeth Použitie Aplikácia sa skladá z troch hlavných okien: Builder, Gen-b, Gen-s. Medzi týmito oknami je možné sa prepínať prvými troma tlačítkami umiestnenými vľavo na hornom ovládacom paneli (Obr. 17). Predtým ako pustíme pakety do siete je potrebné najskôr definovať v okne Builder aspoň základné parametre jednotlivých protokolov, z ktorých je paket zostavený. V okne Gen-b sa nastavujú parametre posielania paketov. V tomto okne 38

45 Návod na použitie aplikácií možné nastaviť aj to aké údaje chceme počas posielania meniť. Tretie okno Gen-s umožní posielať rôzne sekvencie zhlukov vopred definovaných paketov. Obr. 17 Ovládací panel aplikácie packeth Okno Builder Po spustení packethu sa nachádzame v okne nazvanom Builder. V tomto okne môžeme poskladať paket použitím rôznej kombinácie ponúkaných protokolov. Okno Builder sa delí na tri časti, podľa jednotlivých prenosových vrstiev. Úplne hore sa nachádza časť Link Layer (Obr. 18), ktorá vlastne zodpovedá linkovej vrstve. Tu je možné si nadefinovať vlastný prenosový ethernetový rámec. Obr. 18 Definovanie Linkovej vrstvy U ethernetového rámca verzie II je možné zadať zdrojovú a cieľovú MAC adresu a typ protokolu ktorý bude rámec prenášať. Okrem klasického ethernetového rámca verzie II môžeme pakety vkladať aj do rámcov zostavených podľa štandardu IEEE A to tak, že označíme možnosť Týmto sa sprístupní pole v pravej časti okna s názvom LLC field values, v ktorom si zvolíme či sa budú generovať rámce protokolu IEEE 802.3, v ktorých je zabalený protokol LLC bez pola SNAP (prvá možnosť LLC ), alebo spolu so SNAP (druhá možnosť LLC-SNAP ). 39

46 Návod na použitie aplikácií Ak chceme pakety prenášať v rámcoch podporujúcich VLAN, alebo aby sme mohli definovať priority pre prenosový rámec, je potrebné zaškrtnúť políčko 802.1q. Môžeme definovať nasledovné druhy priorít. 0 Best Effort bežná LAN priorita. 1 Background používa sa pre väčšie prenosy, hry atď. 2 Spare je nedefinovaná priorita. 3 Excelent Effort priorita pre dôležitých užívateľov. 4 Controled Load niektoré dôležité aplikácie. 5 Video pre túto prioritu je vyžadovaná čakacia doba menej ako 100 milisekúnd. 6 Voice čakacia doba menej ako 10 milisekúnd. 7 Network Control vysoké požiadavky, používa sa pre riadenie a údržbu siete. Označením pola QinQ, vytvoríme dve 4 bajtové značky. Obsah druhej značky môžeme vyplniť manuálne v textovom poli ktoré sa zvýrazní. Hodnoty sa zadávajú v šestnástkovej sústave. Prvý znak reprezentuje bit CFI a zvyšné tri definujú ďalšiu virtuálnu LAN. Q-in-Q (označuje 802.Qover802.1Q) sa v praxi používa vtedy ak poskytovateľ, ktorý vlastní VLAN infraštruktúru predá zákazníkovi ethernetový spoj v rámci svojej siete a zákazník chce cez tento spoj prenášať svoje už predtým označené rámce. Teda chce využívať viac virtuálnych sietí v rámci jednej virtuálnej siete. V takom prípade prvé označenie spraví zariadenie zákazníka, druhé označkovanie zariadenie poskytovateľa. Službu Q-in-Q nemusia podporovať ani zariadenia zákazníka ani medziľahlé zariadenia, ale len tie, ktoré vykonávajú druhé značenie rámca a samozrejme jeho odznačenie v opačnom smere. Ostatné zariadenia si prečítajú len druhý tag (presnejšie prvý v poradí dotyčného rámca, bol ale pridaný ako druhý) a považujú tento rámec za súčasť jednej VLAN a ďalší obsah rámca ich nezaujíma. Obr. 19 Definovanie IP záhlavia 40

47 Návod na použitie aplikácií Podľa toho akú vyberieme ďalšiu vrstvu, sa zmení aj rozvrhnutie zvyšnej dolnej časti okna Builder. Možnosť je vybrať z protokolu ARP, IP a užívateľom definovanom protokole. Pri ponechaní zaškrtnutej voľby IPv4, bude okno pre definovanie IP záhlavia vyzerať ako na Obr. 19. Tu je potrebné vyplniť aspoň zdrojovú a cieľovú IP adresu. Ak chceme zvoliť prioritu generovaných paketov na tretej vrstve stlačíme tlačítko Select pri značke TOS. Objaví sa dialógové okno (Obr. 20), v ktorom je možné definovať kvalitu služby (zaškrtnutím políčka Type of Service). Jednotlivé položky v tomto dialógovom okne majú nasledovný význam: Precedence bity znamenajú prioritu akú by mal mať paket prioritu. 3 bity sú schopné vyjadriť 8 úrovní 0 (nízka) 7 (vysoká) D-bit (Delay) používajú uzly, ktoré požadujú malé oneskorenie (1) alebo im stačí normálne oneskorenie (0). T-bit (Throughput) používajú uzly, ktoré požadujú vysokú priepustnosť (1) alebo im stačí normálna priepustnosť (0) R-bit (Reliability) požiadavka na vysokú spoľahlivosť (1) alebo normálna spoľahlivosť (0) Niektoré mechanizmy TOS ignorujú ale napríklad smerový protokol OSPF (Open Shortest Path First) je schopný zachytiť smerovanie na základe požiadaviek definovaných v tomto poli záhlavia. Pri voľbe DS je možné zadať číslo označujúce typ diferencovanej služby v rozsahu hodnôt (0-63). Obr. 20 Dialógové okno pre voľbu typu služby u IP paketov 41

48 Návod na použitie aplikácií V poli pre definovanie IP vyberáme aj typ protokolu, ktorý sa bude prenášať na transportnej vrstve. Máme možnosť výberu z protokolov UDP, TCP, ICMP, IGMP a vlastné užívateľom definované dáta prenášané v dátovej časti protokolu IP. Pri protokole UDP sa musí zadať zdrojový a cieľový port. Po zaškrtnutí voľby UDP payload zadávame dátovú časť protokolu UDP. Máme možnosť vypísať každý jeden bajt zvlášť a to zapisovaním priamo do vedľajšieho okna v šestnástkovom tvare. Alebo môžeme aplikovať krátky opakujúci sa vzor pomocou voľby Apply Pattern v pravej časti okna. Voľba Time-stamp slúži na vloženie časového údaju odoslania paketu do dátovej časti. Rovnaké možnosti sú pri definovaní protokolu TCP, pribudli ale možnosti zadania poradového a potvrdzovacieho čísla, veľkosti okna, príznakov a ukazovateľa naliehavých dát. Keď je paket postavený, je potrebné zadať ešte sieťové rozhranie na ktoré sa bude paket odosielať. Sieťové rozhranie sa vyberá v dialógovom okne Interface, ku ktorému sa dostaneme stlačením tlačidla s označením I v ovládacom paneli. Postavený paket je možné uložiť do súboru, čím si ušetríme zdĺhavé zadávanie všetkých hodnôt pri opätovnom spustení aplikácie. Použijeme na to tlačidlo Save a po otvorení dialógového okna pre ukladanie súborov napíšeme názov vytvoreného paketu. Opätovné nahranie paketu dosiahneme tak, že po stlačení tlačítka Load vyberieme z dialógového okna vopred uložený paket. Uvedená operácia sa dá ešte viac zjednodušiť použitím tlačidiel Default. V tomto prípade nemusíme vyberať paket z dialógového okna, ale sa hneď nahrá z predvoleného súboru. Stlačením tlačítka Send pošleme na dané rozhranie jeden paket. Ak sme definovali všetky potrebné hodnoty v jednotlivých záhlaviach paketu, mal by sa v stavovom riadku, ktorý je umiestnený v dolnej časti aplikačného okna, objaviť údaj koľko bajtov bolo odoslaných. Ak chceme generovať sekvenciu pozostávajúci s postavených paketov, prepneme sa do ďalšieho okna aplikácie, stlačením tlačidla Gen-b v ovládacom paneli Okno Gen-b Toto okno sa delí na dve časti. Vpravo sa zdáva spôsob generovania paketov (Obr. 21). Ak sme v okne Builder zadali správne všetky potrebné hodnoty, objavia sa ľavej časti zobrazené hodnoty jednotlivých bajtov paketu. V opačnom prípade v tejto časti okna uvidíme nápis Packet constructed in Builder is not ok. Taktiež tu môžeme nastaviť niektoré parametre, ktoré sa budú meniť počas posielania. 42

49 Návod na použitie aplikácií Obr. 21 Spôsob generovania paketov Pri definovaní spôsobu generovania je možné zadať počet paketov, ktoré budú odoslané, v prípade zaškrtnutia voľby Infinite dosiahneme, že pakety sa budú generovať až dokým nestlačíme tlačítko Stop umiestnené v vpravo v hornom ovládacom paneli. Do textového okna Delay between packets zadávame časový údaj v mikrosekundách medzi odosielaním jednotlivých paketov (t.j. hodnota označuje sekundovú pauzu). Taktiež je možnosť výberu Max speed. Tento údaj sa vzťahuje k voľbám Absolute delay, Relative delay, Poison flow, Burst flow. Pri každej voľbe má ale mierne odlišný význam. Voľba Absolute delay znamená absolútne omeškanie paketov. Čas odoslania je pre každý paket vypočítaný na základe časového rozdielu medzi jednotlivými paketmi a začiatkom vysielania prvého paketu. Takže sa vlastne len kontroluje či je práve čas na poslanie alebo čas na pauzu. Inak povedané, ak sa posielanie nejakého paketu omešká, ostatné sú posielané hneď ako nadíde ich čas. Voľba Relative delay znamená že časová medzera medzi paketmi sa snaží byť konštantná. Nedbajúc na to či sa predošlý paket omeškal alebo nie. Pri voľbe Poison flow sa generátor pokúša generovať pakety v poisonovskom toku. V tomto prípade zadaný časový údaj značí strednú (priemernú) medzeru medzi jednotlivými paketmi. Ak chceme dosiahnuť aby sa vygenerovalo za jednu sekundu napríklad 10 paketov, je potrebné zadať čas 0,1 s (teda do okna Delay between packets napíšeme číslo , bez medzier). 43