ˇ ´ UCEN ´I TECHNICKE ´ V BRNE ˇ VYSOKE BRNO UNIVERSITY OF TECHNOLOGY
ˇ ´ICH TECHNOLOGI´I FAKULTA INFORMACN ˇ ´ICH SYSTEM ´ ´ U ˚ USTAV INFORMACN FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS
´ PRO UZIVATELEM ˇ ˇ ´IZENE ´ QOS SYSTEM R
´ PRACE ´ DIPLOMOVA MASTER’S THESIS
´ AUTOR PRACE AUTHOR
BRNO 2007
ˇ OLDRICH PLCHOT
ˇ ´ UCEN ´I TECHNICKE ´ V BRNEˇ VYSOKE BRNO UNIVERSITY OF TECHNOLOGY
ˇ ´ICH TECHNOLOGI´I FAKULTA INFORMACN ˇ ´ICH SYSTEM ´ ´ U ˚ USTAV INFORMACN FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS
´ PRO UZIVATELEM ˇ ˇ ´IZENE ´ QOS SYSTEM R USER ORIENTED QOS SYSTEM
´ DIPLOMOVA´ PRACE MASTER’S THESIS
´ AUTOR PRACE
ˇ OLDRICH PLCHOT
AUTHOR
´ VEDOUC´I PRACE SUPERVISOR
BRNO 2007
ˇ KASP ˇ AREK ´S ´ Ing. TOMA
Abstrakt Tento diplomov´ y projekt se zab´ yv´a moˇznostmi operaˇcn´ıho syst´emu GNU/Linux v oblasti zajiˇstˇen´ı kvality poskytovan´ ych s´ıt’ov´ ych sluˇzeb. Pr´ace porovn´av´a a hodnot´ı prostˇredky k zajiˇstˇen´ı kvality sluˇzeb dostupn´e v operaˇcn´ım syst´emu GNU/Linux. C´ılem pr´ace je diskutovat nedostatky a pˇrednosti tˇechto prostˇredk˚ u a navrhnout syst´em, kter´ y ˇreˇs´ı problematiku zajiˇstˇen´ı kvality sluˇzeb. Navrˇzen´ y syst´em vyuˇz´ıv´a heuristiky, kter´a umoˇzn´ı uˇzivateli nastavit kvalitu sluˇzeb i bez nutnosti studovat specifick´e vlastnosti komunikaˇcn´ıch protokol˚ u na u ´rovni s´ıt’ov´e nebo aplikaˇcn´ı vrstvy. Souˇc´ast´ı projektu je tak´e teoretick´ yu ´vod do problematiky kvality sluˇzeb a architektury poˇc´ıtaˇcov´ ych s´ıt´ı.
Kl´ıˇ cov´ a slova Linux, TCP/IP, IPv6, kvalita sluˇzeb, QoS, Iptables, router, HTB, j´adro, ISO/OSI, paket, hlaviˇcka paketu, neuronov´e s´ıtˇe, klasifikace, datov´ y tok, pcap
Abstract This master’s thesis deals with the possibilities how to guarantee the quality of service in the area of computer networks using a GNU/Linux operating system. This work compares and evaluates tools which are necessary to guarantee the quality of service. The goal of this work is to discuss the advantages and disadvantages of these tools and to design a system which handles the problem of quality of service. Designed system uses a heuristics, which allows the user to set up the quality of service system without studying specific properties of communication protocols on the network or application layer. This work also includes a theoretical introduction into the quality of service and computer networks.
Citace Oldˇrich Plchot: Syst´em pro uˇzivatelem ˇr´ızen´e QoS, diplomov´a pr´ace, Brno, FIT VUT v Brnˇe, 2007
Syst´ em pro uˇ zivatelem ˇ r´ızen´ e QoS Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem tento diplomov´ y projekt vypracoval samostatnˇe pod veden´ım Ing. Tom´ aˇse Kaˇsp´ arka. Uvedl jsem vˇsechny liter´arn´ı prameny a publikace, ze kter´ ych jsem ˇcerpal. ....................... Oldˇrich Plchot 15. kvˇetna 2007
Podˇ ekov´ an´ı R´ad bych na tomto m´ıstˇe podˇekoval pˇredevˇs´ım panu Ing. Tom´aˇsi Kaˇsp´arkovi za odbornou pomoc, poskytnutou pˇri ˇreˇsen´ı probl´em˚ u spojen´ ych s t´ımto projektem.
c Oldˇrich Plchot, 2007.
Tato pr´ ace vznikla jako ˇskoln´ı d´ılo na Vysok´em uˇcen´ı technick´em v Brnˇe, Fakultˇe informaˇcn´ıch technologi´ı. Pr´ ace je chr´ anˇena autorsk´ym z´ akonem a jej´ı uˇzit´ı bez udˇelen´ı opr´ avnˇen´ı autorem je nez´ akonn´e, s v´yjimkou z´ akonem definovan´ych pˇr´ıpad˚ u.
´ Uvod Dneˇsn´ı svˇet si nelze pˇredstavit bez moˇznosti snadn´e a rychl´e komunikace, internetu a multim´edi´ı. St´ ale v´ıce poˇc´ıtaˇcov´ ych s´ıt´ı, a to jak mal´ ych, tak rozlehl´ ych, je pˇripojov´ano k internetu a vznik´ a potˇreba tyto s´ıtˇe chr´anit a zajistit jejich uˇzivatel˚ um moˇznost pohodlnˇe, bezpeˇcnˇe a efektivnˇe pracovat. Vˇetˇsina mal´ ych a stˇredn´ıch s´ıt´ı pˇripojovan´ ych do internetu ˇreˇs´ı probl´em u ´zk´eho hrdla v pˇr´ıpadˇe konektivity do t´eto mezin´arodn´ı s´ıtˇe. V mnoha pˇr´ıpadech dok´ aˇze vhodnˇe nastaven´ y syst´em pro zajiˇstˇen´ı kvality sluˇzeb na pˇr´ıstupov´em bodu do mezin´ arodn´ı s´ıtˇe uˇsetˇrit ˇcas a pen´ıze pˇripojen´ ych uˇzivatel˚ u. Tato pr´ ace se zab´ yv´ a moˇznostmi operaˇcn´ıho syst´emu GNU/Linux v oblasti s´ıt´ı a zajiˇstˇen´ı kvality sluˇzeb pro uˇzivatele pˇripojen´e do internetu. C´ılem pr´ace je porovnat moˇznosti prostˇredk˚ u k tomuto u ´ˇcelu dostupn´ ych, diskutovat jejich pˇrednosti a nedostatky a navrhnout syst´em, kter´ y ˇreˇs´ı problematiku zajiˇstˇen´ı kvality sluˇzeb. Navrˇzen´ y syst´em spojuje moˇznosti poskytovan´e standardn´ımi n´astroji dostupn´ ymi v operaˇcn´ım syst´emu GNU/Linux s nov´ ym pˇristupem ke klasifikaci s´ıt’ov´eho provozu. Souˇc´ ast´ı projektu je teoretick´ y u ´vod do problematiky kvality sluˇzeb a architektury poˇc´ıtaˇcov´ ych s´ıt´ı. V´ ysledkem je porovn´ an´ı moˇznost´ı operaˇcn´ıho sys´emu GNU/Linux slouˇzit jako platforma pro zajiˇstˇen´ı kvality s´ıt’ov´ ych sluˇzeb a implementace navrˇzen´eho syst´emu, kter´ y v re´aln´em ˇcase reaguje na provoz generovan´ y jednotliv´ ymi uˇzivateli a dok´aˇze se mu pˇrizp˚ usobovat. ’ Tento diplomov´ y projekt navazuje na roˇcn´ıkov´ y projekt Srovn´an´ı s´ıt ov´e vrstvy BSD a Linuxu, kter´ y tvoˇr´ı z´ aklady kapitoly 3 a 4. D´ale potom pr´ace navazuje na semestr´aln´ı projekt, kter´ y je souˇc´ ast´ı zad´ an´ı diplomov´eho projektu. V r´amci semestr´aln´ıho projektu byly vypracov´ any kapitoly 2,3,4 a ˇc´ast kapitoly 5. Bˇehem semestr´aln´ıho projektu byly prozkoum´ any teoretick´e mater´ı´ aly a navrˇzena architektura v´ ysledn´eho syst´emu.
5
Kapitola 2
Kvalita sluˇ zeb (QoS) V oblasti dneˇsn´ıch poˇc´ıtaˇcov´ ych s´ıt´ı znamen´a pojem kvalita sluˇzeb schopnost s´ıtˇe dosahovat poˇzadovan´ ych parametr˚ u pro r˚ uzn´e typy s´ıt’ov´ ych aplikac´ı na lince o urˇcit´e ˇs´ıˇrce p´asma, kterou je s´ıt’ pˇripojena do dalˇs´ı s´ıt’ˇe (typicky do internetu). R˚ uzn´a ˇreˇsen´ı, zab´ yvaj´ıc´ı se zajiˇstˇen´ım kvality sluˇzeb pro tyto aplikace, mus´ı poˇc´ıtat nejen s jednoduch´ ym rozdˇelen´ım ˇs´ıˇrky p´ asma, ale tak´e s chybami a probl´emy,[7] kter´e se vyskytuj´ı v nynˇejˇs´ıch s´ıt´ıch, funguj´ıc´ıch na principu pˇrep´ın´ an´ı paket˚ u. ztracen´ e pakety (packet loss) - m˚ uˇze se st´at, ˇze nˇekter´e z router˚ u, vyskytuj´ıc´ıch se v cestˇe paketu, jej nedoruˇc´ı. Tento pˇr´ıpad m˚ uˇze nastat napˇr´ıklad pˇri velk´em vyt´ıˇzen´ı nˇekter´e z cest, kter´ ymi paket proch´az´ı nebo tak´e poruchou nˇekter´eho z router˚ u. V d˚ usledku t´eto chyby potom vznik´a situace, kdy aplikace, kter´a dan´ y paket oˇcek´av´ a, poˇz´ ad´ a o jeho znovu zasl´ an´ı a zp˚ usob´ı tak zpoˇzdˇen´ı. Pokud vˇsak je sluˇzba navrˇzena tak, ˇze nen´ı nutn´e obdrˇzet kaˇzd´ y paket, pak pokraˇcuje v ˇcinnosti, ale je ovlivnˇena touto chybou (napˇr´ıklad kr´ atk´ y v´ ypadek zvuku nebo artefakty v obraze). zpoˇ zdˇ en´ı (delay) - m˚ uˇze trvat r˚ uznou dobu, neˇz paket doputuje do sv´eho c´ıle d´ıky chyb´ am a nebo proto, ˇze putuje jin´ ymi cestami, aby se vyhnul zahlcen´ ym tras´am. Tato doba je pro nˇekter´e aplikace kritick´a a pokud ji nedok´aˇzeme udrˇzet pod urˇcitou hranic´ı, tak doch´ az´ı ke zhorˇsen´ı kvality sluˇzby, pˇr´ıpadnˇe k jej´ı nefunkˇcnosti. zkreslen´ı (jitter) - nast´ av´ a, kdyˇz pakety doraz´ı do c´ıle s r˚ uzn´ ym zpoˇzdˇen´ım. Je probl´emem zejm´ena pro interaktivn´ı pˇrenos audia nebo videa. nespr´ avn´ e poˇ rad´ı paket˚ u - je bˇeˇzn´e, ˇze pakety proch´azej´ı velk´ ym mnoˇzstv´ım router˚ u, kter´e je mohou poslat r˚ uzn´ ymi cestami, a t´ım p´adem tak´e zp˚ usob´ı r˚ uzn´e zpoˇzdˇen´ı a pakety jsou doruˇceny v jin´em poˇrad´ı, neˇz byly vysl´any. Pro nˇekter´e sluˇzby to nepˇredstavuje ˇz´ adn´ y probl´em, ale napˇr´ıklad pro pˇrenos hlasu a videa je spr´avn´e poˇrad´ı obdrˇzen´ ych paket˚ u velmi d˚ uleˇzit´e. chyba v pˇ renosu - pokud bˇehem cesty doˇslo ke zmˇenˇe jednoho nebo v´ıce bit˚ u paketu a oprava chyb v transportn´ı vrstvˇe nedok´aˇze data opravit do spr´avn´eho stavu, tak je s paketem jedn´ ano, jako by byl ztracen a je vyˇz´ad´ano jeho opˇetovn´e zasl´an´ı. Tyto chyby z´ avis´ı na aktu´ aln´ım stavu s´ıtˇe, kter´ y nejsme schopni ovlivnit a je nemoˇzn´e s urˇcitost´ı pˇredpovˇedˇet, kdy nastanou. Nejˇcastˇejˇs´ımi pˇr´ıˇcinami tˇechto chyb b´ yv´a zahlcen´ı nˇekter´e z cest, kter´ ymi jsou pakety routov´any k c´ıli. D˚ uleˇzit´ ym krokem pro zajiˇstˇen´ı kvality sluˇzeb je eliminov´ an´ı u ´zk´ ych hrdel s´ıtˇe. V pˇr´ıpadˇe velk´ ych telekomunikaˇcn´ıch spoleˇcnost´ı, 6
poskytuj´ıc´ıch pˇr´ıstup k p´ ateˇrn´ım s´ıt´ım o velmi vysok´e propustnosti, mus´ı b´ yt s´ıt’ dimenzov´ana tak, aby nedoch´ azelo k jej´ımu zahlcov´an´ı a nebo aby byla pˇredem zajiˇstˇena kvalita sluˇzby. K tomuto u ´ˇcelu existuje napˇr´ıklad protokol RSVP (Resource Reservation Protocol, RFC 2205), kter´ y je navrˇzen za u ´ˇcelem rezervace kapacity pro poˇzadovan´e sluˇzby skrze celou s´ıt’. Podpora tˇechto protokol˚ u je potom obsaˇzena v kaˇzd´em routeru p´ateˇrn´ı s´ıtˇe a zajiˇst’uje ´ ym hrdlem se tedy v mnoha pˇr´ıpadech st´ tak jej´ı vysokou u ´roveˇ n pˇri zajiˇstˇen´ı sluˇzeb. Uzk´ av´ a bod, ve kter´em doch´ az´ı k napojen´ı do t´eto s´ıtˇe. T´ımto zp˚ usobem jsou vˇetˇsinou pˇripojeni bud’ menˇs´ı poskytovatel´e pˇripojen´ı k internetu nebo r˚ uzn´e firmy, kter´e maj´ı sjedn´anu linku o garantovan´e kapacitˇe s oper´atorem, kter´ y m´ a moˇznosti a prostˇredky zajistit s velkou spolehlivost´ı poˇzadovanou ˇs´ıˇrku p´asma. Zajiˇstˇen´ı kvality sluˇzeb pro tyto menˇs´ı subjekty spoˇc´ıv´a tedy pˇredevˇs´ım v prevenci zahlcen´ı sv´eho pˇr´ıstupov´eho bodu. K tomu, abychom byli schopni kontrolovat kvalitu sluˇzeb na urˇcit´e lince, mus´ıme m´ıt pod kontrolou obˇe strany toku dat. Pokud bychom pˇripojili do p´ateˇrn´ı s´ıtˇe pˇr´ımo nˇejak´e koncov´e zaˇr´ızen´ı, pak m˚ uˇzeme u ´ˇcinnˇe kontrolovat pouze tok dat, kter´ y na tomto zaˇr´ızen´ı vznik´ a a putuje do p´ateˇrn´ı s´ıtˇe. Druh´ y smˇer, odkud data pˇrich´azej´ı, m´a pod kontrolou telekomunikaˇcn´ı oper´ ator, kter´ y obvykle vyhrad´ı pouze smluvenou kapacitu a dalˇs´ı kroky k ˇr´ızen´ı kvality sluˇzeb v tomto bodˇe zpravidla jiˇz neposkytuje. Aby bylo moˇzn´e kontrolovat oba dva smˇery toku dat a zajistit nad nimi v r´amci moˇznost´ı poˇzadovan´e parametry, tak je tˇreba, v bodˇe pˇripojen´ı k p´ateˇrn´ı s´ıti, zaˇradit router, kter´ y je schopen definovat kvalitu sluˇzeb.
Obr´ azek 2.1: Typick´e pˇripojen´ı s´ıtˇe do internetu
K tomu, aby byl router schopen efektivnˇe kontrolovat tok dat, pˇredch´azet zahlcen´ı a kontrolovat tak poˇzadovan´e parametry, je nutn´e obˇetovat urˇcitou ˇc´ast ze sjednan´e kapacity linky ve prospˇech ˇr´ızen´ı kvality sluˇzeb. Pokud je linka plnˇe vyt´ıˇzena a fronty na jej´ım koncov´em bodˇe jsou pln´e, zaˇcne doch´azet k zahazov´an´ı paket˚ u, coˇz zp˚ usob´ı zpoˇzdˇen´ı, a to je pro velkou ˇc´ ast aplikac´ı probl´em. Pokud bychom nesn´ıˇzili rychlost linky na vstupn´ım routeru, tak by doch´ azelo k tvoˇren´ı tˇechto front na v´ ystupn´ı stranˇe poskytovatele a router by tedy nebyl schopen kontrolovat pˇr´ıchoz´ı tok dat. Jakmile je na vstupn´ım routeru nastavena rychlost menˇs´ı neˇz na vstupn´ı lince, tak se tyto fronty pˇresunou na v´ ystup do vnitˇrn´ı s´ıtˇe, kter´ y je pod kontrolou routeru a je moˇzn´e nad nimi prov´adˇet operace, kter´e umoˇzn´ı zajistit parametry poˇzadovan´e jednotliv´ ymi sluˇzbami. Pokud paket doraz´ı k routeru a nem˚ uˇze b´ yt okamˇzitˇe odesl´an, tak je zaˇrazen do fronty. Kdyby nebyla definov´ ana ˇz´ adn´ a pravidla kvality sluˇzeb, musel by tento paket ˇcekat, neˇz budou odesl´ any vˇsechny pˇredchoz´ı pakety. To by vˇsak opˇet zp˚ usobilo zpoˇzdˇen´ı. Vstupn´ı router ale dok´ aˇze takov´ y paket zaˇradit na zaˇc´atek fronty a umoˇznit tak napˇr´ıklad aplikaci pro streamov´ an´ı audia neruˇsen´ y provoz.
7
Kapitola 3
Z´ akladn´ı principy s´ıt’ov´ e architektury 3.1
Referenˇ cn´ı OSI model
OSI (Open System Interconnection) je ISO standard, kter´ y vznikl v roce 1978 a zrevidov´ an byl v roce 1984. Popisuje r´ amec s´ıt’ov´e komunikace pro implementaci protokol˚ u v sedmi vrstv´ach. OSI model je zkonstruov´an tak, ˇze ˇr´ızen´ı je pˇred´av´ano z jedn´e vrstvy do druh´e, a to takov´ ym zp˚ usobem, ˇze kaˇzd´ a vrstva m˚ uˇze komunikovat pouze se svou sousedn´ı vrstvou. Referenˇcn´ı OSI model m´ a sedm vrstev, pro kter´e plat´ı n´asleduj´ıc´ı principy: • vrstva by mˇela b´ yt vytvoˇrena tam, kde je potˇreba dos´ahnout r˚ uzn´eho typu abstrakce, • kaˇzd´ a vrstva by mˇela vykon´avat pouze jasnˇe definovan´e funkce, • funkce kaˇzd´e vrstvy by mˇela b´ yt vybr´ana s ohledem na definov´an´ı mezin´arodnˇe uzn´ avan´ ych a standardizovan´ ych protokol˚ u, • rozsah vrstvy by mˇel b´ yt zvolen tak, aby se minimalizoval datov´ y tok mezi zaˇr´ızen´ımi, • poˇcet vrstev by mˇel b´ yt natolik velk´ y, aby nemusely b´ yt rozd´ıln´e funkce sluˇcov´any do jedn´e vrstvy a natolik mal´ y, aby se architektura nestala nepraktickou. Aplikaˇ cn´ı vrstva Tato nejvyˇsˇs´ı vrstva definuje, jak´ ym zp˚ usobem m˚ uˇze aplikace bˇeˇz´ıc´ı na jednom syst´emu komunikovat s aplikac´ı na jin´em syst´emu, ˇc´ımˇz umoˇzn ˇuje aplikac´ım pˇr´ıstup ke komunikaˇcn´ım kan´al˚ um a n´aslednou spolupr´aci. 7 6 5 4 3 2 1
Aplikaˇcn´ı vrstva – Application Layer Prezentaˇcn´ı vrstva – Presentation Layer Relaˇcn´ı vrstva – Session Layer Transportn´ı vrstva – Transport Layer S´ıt’ov´ a vrstva – Network Layer Vrstva datov´ ych spoj˚ u – Data Link Layer Fyzick´ a vrstva – Physical Layer
Prezentaˇ cn´ı vrstva Vrstva poskytuje nez´avislost na rozd´ıln´e reprezentaci dat tak, ˇze pˇrev´ ad´ı data z aplikaˇcn´ıho do s´ıtov´eho form´atu a naopak. Poskytuje napˇr´ıklad kompresi dat nebo ˇsifrov´ an´ı a t´ım zajiˇst’uje, ˇze proch´azej´ıc´ı komunikace je ve spr´avn´e formˇe, kter´e rozum´ı pˇr´ıjemce. Programy v t´eto vrstvˇe urˇcuj´ı tˇri z´akladn´ı vlastnosti. Datov´e form´ aty, napˇr´ıklad ASCII, nebo bin´arn´ı form´at dat, kompatibilitu s operaˇcn´ım syst´emem hostitelsk´eho poˇc´ıtaˇce a zapouzdˇren´ı dat do zpr´av tak, aby mohly b´ yt ’ pos´ıl´ any pˇres poˇc´ıtaˇcovou s´ıt . Relaˇ cn´ı vrstva Tato vrstva vytv´aˇr´ı, udrˇzuje a ukonˇcuje spojen´ı mezi aplikacemi. V internetov´ ych aplikac´ıch je kaˇzd´e sezen´ı pˇriˇrazeno k urˇcit´emu portu, coˇz je ˇc´ıslo pˇridruˇzen´e ke konkr´etn´ı vyˇsˇs´ı vrstvˇe aplikace. Napˇr´ıklad http server m´a obvykle ˇc´ıslo portu 80. ˇ ısla port˚ C´ u pˇridruˇzen´ ych k hlavn´ım internetov´ ym aplikac´ım jsou pˇriˇrazov´ana organizac´ı IANA (Internet Assisgned Numbers Authority) a m˚ uˇzeme je nal´ezt v souboru ˇ ısla port˚ /etc/services. C´ u menˇs´ı neˇz 1024, naz´ yvan´e tak´e privilegovan´e porty, mohou b´ yt otevˇrena pouze superuˇzivatelem. Klienti, kteˇr´ı se pˇripojuj´ı k tˇemto port˚ um si mohou b´ yt jisti, ˇze na nich bˇeˇz´ı nˇekter´a ze standardn´ıch sluˇzeb a ne libovoln´a sluˇzba puˇstˇen´ a uˇzivatelem. Vˇetˇsina port˚ u je nicm´enˇe k dispozici k dynamick´emu pˇriˇrazen´ı ostatn´ım aplikac´ım. Transportn´ı vrstva Tato vrstva poskytuje transparentn´ı pˇrenos dat mezi jednotliv´ ymi koncov´ ymi syst´emy nebo poˇc´ıtaˇci a je zodpovˇedn´a za kontrolu chyb a jejich opravu. Kompletnˇe zajiˇst’uje datov´ y pˇrenos. S´ıt’ov´ a vrstva Poskytuje pˇrep´ınac´ı a smˇerovac´ı technologie pro pˇren´aˇsen´ı dat, pˇrekl´ad´ a logick´e adresy a jm´ena na fyzick´e adresy a urˇcuje optim´aln´ı cestu paketu ze zdroje do c´ıle. Vytv´ aˇr´ı logick´e cesty, kter´e jsou zn´amy jako virtu´aln´ı okruhy (virtual circuits). Jej´ımi funkcemi jsou tak´e pˇresmˇerov´av´an´ı, kontrola chyb, kontrola zahlcen´ı a ˇrazen´ı paket˚ u. Vrstva datov´ ych spoj˚ u Zajiˇst’uje pˇrenos dat tam i zpˇet pˇres fyzick´e spojen´ı v s´ıti, dˇel´ı odchoz´ı data do r´ amc˚ u, kontroluje integritu pˇrijat´ ych dat, spravuje pˇr´ıstup k m´ediu ’ a pouˇzit´ı m´edia a zajiˇst uje spr´avn´e ˇrazen´ı paket˚ u. Tyto funkce jsou vˇetˇsinou poskytov´ any ovladaˇcem s´ıt’ov´e karty, obecnˇeji hardwarem zodpovˇedn´ ym za propojen´ı stroje do s´ıtˇe. Takov´e zaˇr´ızen´ı se oznaˇcuje jako NIC (Network Inteface Card). Fyzick´ a vrstva Tato vrstva vytv´aˇr´ı bitov´ y proud (elektrick´e impulzy, svˇeteln´ y, nebo radiov´ y sign´ al atd.) pˇres komunikaˇcn´ı m´edium na elektrick´e a mechanick´e u ´rovni. Zpˇr´ıstupˇ nuje hardware ve smyslu odes´ıl´an´ı a pˇrij´ım´an´ı dat na nosiˇci.
3.2
Sada protokol˚ u TCP/IP
Z´akladem pro pˇrenos informac´ı vyˇsˇs´ımi protokoly se stal uˇz roku 1980 protokol IP (Internet Protocol). 1 Je pouˇz´ıv´ an na paketovˇe orientovan´ ych s´ıt´ıch a zajiˇst’uje pˇrenos paketu, aniˇz by garantoval u ´spˇeˇsnost doruˇcen´ı, pˇr´ıpadnˇe zajiˇst’oval spr´avnost doruˇcen´ ych dat. Tyto u ´koly pˇrenech´ av´ a vyˇsˇs´ım protokol˚ um, kter´ ym poskytuje abstrakci nad pˇrenosov´ ym m´ediem a umoˇzn ˇuje tak spojovat s´ıtˇe r˚ uzn´ ych typ˚ u (napˇr. ethernet, ATM, FDDI). C´ılem protokolu 1
Tento protokol byl definov´ an jako standard uˇz v lednu roku 1980 v RFC 760 a do podoby pouˇz´ıvan´e dodnes a zn´ am´e jako IPv4 byl upraven v z´ aˇr´ı 1981 dokumentem RFC 791.
9
Referenˇ cn´ı ISO/OSI model Aplikaˇcn´ı vrstva Prezentaˇcn´ı vrstva
TCP/IP S´ıt’ov´e aplikace Rozhran´ı soket˚ u
Relaˇcn´ı Vrstva Transportn´ı vrstva S´ıt’ov´ a vrstva Vrstva datov´ ych spoj˚ u Fyzick´ a vrstva
Tabulka 3.2: Zn´azornˇen´ı TCP/IP do ISO/OSI modelu IP je poskytnout vˇsem zaˇr´ızen´ım v internetu jedineˇcnou adresu v jednodn´em adresn´ım prostoru a umoˇznit tak jejich komunikaci. Protokol TCP/IP byl p˚ uvodnˇe vyvinut jako vˇedeck´ y experiment na univerzitˇe v Berkeley a postupnˇe se stal kl´ıˇcovou technologi´ı Internetu. Protokoly TCP/IP poskytuj´ı uˇzivatel˚ um z´akladn´ı sluˇzby jako napˇr´ıklad World Wide Web (WWW), E-mail a dalˇs´ı. Podobnˇe jako ISO/OSI m´ a vrstvovou architekturu. TCP/IP nen´ı v konfliktu s ISO/OSI standardem a naopak, protoˇze oba dva modely byly vyvinuty soubˇeˇznˇe, ale existuj´ı mezi nimi urˇcit´e rozd´ıly. Nejvˇetˇs´ı rozd´ıl mezi OSI architekturou a TCP/IP je ve zp˚ usobu ˇreˇsen´ı probl´em˚ u ’ nad transportn´ı vrstvou a v s´ıt ov´e vrstvˇe. OSI m´a relaˇcn´ı a prezentaˇcn´ı vrstvu, kdeˇzto TCP/IP kombinuje tyto dvˇe vrstvy do aplikaˇcn´ı vrstvy. Potˇreba implementace protokolu, kter´ y neudrˇzuje stav spojen´ı tak´e pˇrinutila TCP/IP zkombinovat fyzickou vrstvu a vrstvu datov´ ych spoj˚ u do jedn´e vrstvy. TCP/IP je zkratkou dvou nejpouˇz´ıvanˇejˇs´ıch protokol˚ u. TCP (Transmission Control Protocol) je protokol transportn´ı vrstvy, kter´ y pˇrev´ad´ı zpr´avy do posloupnosti paket˚ u na zdrojov´em uzlu a potom je zase sestavuje do p˚ uvodn´ıch zpr´av na c´ılov´em uzlu s´ıtˇe. IP (Internet Protocol) je protokol s´ıt’ov´e vrstvy, kter´ y spravuje adresov´an´ı tak, aby pakety mohly b´ yt smˇerov´ any skrze uzly nebo i cel´e s´ıtˇe pracuj´ıc´ı s r˚ uzn´ ymi komunikaˇcn´ımi protokoly. TCP/IP n´am umoˇzn ˇuje propojen´ı poˇc´ıtaˇc˚ u na aplikaˇcn´ı u ´rovni, coˇz n´am umoˇzn ˇuje zav´adˇet s´ıt’ov´e sluˇzby, kter´e jsou identifikov´ any pomoc´ı port˚ u. Implementaci s´ıt’ov´eho stacku v syst´emech unixov´eho typu si tedy m˚ uˇzeme pˇredstavit tak, jak je zn´ azornˇeno v tabulce. Jde rovnˇeˇz o v´ıcevrstv´ y model, kde urˇcit´e ˇc´asti pln´ı jednu nebo v´ıce funkc´ı z modelu ISO/OSI. V souˇcasn´ ych syst´emech nejv´ıce pˇrevl´ad´a pr´avˇe pouˇzit´ı sady protokol˚ u TCP/IP d´ıky jeho jednoduch´e koncepci, a t´ım p´adem tak´e snadn´e implementaci. Rozˇs´ıˇren´ı tohoto protokolu bylo zp˚ usobeno pˇredevˇs´ım rozmachem internetu a popt´avkou po levn´ ych, ale souˇcasnˇe rychl´ ych s´ıt’ov´ ych zaˇr´ızen´ıch. Kvalitn´ı podpora TCP/IP je absolutn´ı nutnost´ı jak´ehokoliv dnes pouˇz´ıvan´eho operaˇcn´ıho syst´emu. GNU Linux i *BSD syst´emy, kde bylo TCP/IP p˚ uvodnˇe vytvoˇreno, poskytuj´ı v t´eto oblasti sluˇzby na nadstandardn´ı u ´rovni.
3.2.1
Protokol ICMP
Internet Control Message Protocol se star´a o distribuci chybov´ ych a kontroln´ıch zpr´ av zas´ılan´ ych jak routery, tak koncov´ ymi zaˇr´ızen´ımi v s´ıti. Tyto zpr´avy nejsou vˇetˇsinou generov´ any uˇzivatelsk´ ymi aplikacemi, aˇckoliv existuj´ı aplikace jako napˇriklad ping nebo traceroute, pomoc´ı kter´ ych je moˇzno rychle a jednoduˇse diagnostikovat z´akladn´ı stav s´ıtˇe.[5] 10
Datagramy protokolu ICMP jsou pˇren´aˇseny protokolem IP a poskytuj´ı zaˇr´ızen´ım v s´ıti informace o stavu s´ıtˇe. Tyto informace jsou vyuˇz´ıv´any pˇredevˇs´ım routery, kter´e mohou na jejich z´akladˇe zmˇenit sv´e chov´ an´ı tak, aby byla zachov´ana jejich funkce na co nejlepˇs´ı u ´rovni. M˚ uˇze j´ıt napˇr´ıklad o v´ ybˇer nejvhodnˇejˇs´ı trasy pro smˇerovan´e pakety, nebo o vyuˇzit´ı alternativn´ı trasy pˇri v´ ypadku nˇekter´eho sousedn´ıho routeru.2 ICMP byl jako standard definov´an uˇz v z´aˇr´ı roku 1981 a je pops´ an dokumentem RFC 792. Tento protokol je vyuˇz´ıv´an pouze nad komunikac´ı pomoc´ı IPv4. Pro nov´ y protokol IPv6 je definov´ana nov´a verze ICMP naz´ yvan´ a tak´e ICMPv6, kter´ a v sobˇe kombinuje funkce nˇekolika dalˇs´ıch protokol˚ u pouˇz´ıvan´ ych spolu s IPv4. ICMPv6 zahrnuje funkce pˇredchoz´ıho ICMP, IGMP (Internet Group Protocol) a ARP (Address Resolution Protocol).[6]
3.2.2
Protokol TCP
Tento protokol tvoˇr´ı z´ aklad dneˇsn´ı s´ıt’ov´e komunikace a je pouˇz´ıv´an pro sestaven´ı spojen´ı, ’ kter´e zajiˇst uje spolehliv´ y a bezporuchov´ y pˇrenos dat. Nav´ıc je zajiˇstˇeno, ˇze data budou aplikaci dod´ ana v takov´em poˇrad´ı, v jak´em byla vysl´ana. Takov´ ychto spojen´ı mezi jednotliv´ ymi koncov´ ymi body m˚ uˇze b´ yt v´ıce a kaˇzd´e z nich je jednoznaˇcnˇe urˇceno ˇctveˇric´ı zdrojov´ a ip adresa, zdrojov´ y port, c´ılov´ a ip adresa a c´ılov´ y port. Protokol TCP pracuje s proudem dat, kter´ y generuje pˇr´ısluˇsn´ a aplikace. Tento proud dat je d´ale rozdˇelen na segmenty obvykle o maxim´ aln´ı moˇzn´e velikosti (MTU - Maximum Transmision Unit), kter´e podporuje linkov´a vrstva zaˇr´ızen´ı pˇripojen´eho do s´ıtˇe. Tyto segmenty - pakety jsou pot´e pˇred´any do niˇzˇs´ı vrstvy, kde jsou zpracov´ any protokolem IP, kter´ y zajist´ı samotn´ y pˇrenos paketu skrze ’ s´ıt druh´e stranˇe. Pak jej IP pˇred´ a protokolu TCP, kter´ y provede kontroln´ı souˇcet a zjist´ı, zda pˇri pˇrenosu nedoˇslo k chybˇe. Pokud byl paket v poˇr´adku pˇrenesen, pak TCP poˇsle potvrzen´ı, ˇze byl paket pˇrijat. Pokud dojde k chybˇe, tak je vyˇz´ad´ano znovuzasl´an´ı paketu. Pokud vys´ılaj´ıc´ı strana neobdrˇz´ı potvrzen´ı v urˇcit´em ˇcase (RTT - Round Trip Time), tak nast´av´ a timeout a odesl´ an´ı pˇr´ısluˇsn´eho paketu je opakov´ano. Protokol TCP dok´ aˇze tak´e urˇcit´ ym zp˚ usobem zamezovat zahlcen´ı linky. D´ıky ˇcasovaˇc˚ um a zas´ıl´an´ı potvrzen´ı jsou vys´ılaj´ıc´ı strany schopny odhadnout podm´ınky na s´ıti a adekv´atnˇe k nim pak pˇrizp˚ usobit datov´ y tok. Tato kontrola datov´eho toku ale vych´az´ı pouze z informac´ı z´ıskan´ ych z koncov´ ych uzl˚ u spojen´ı. Zp˚ usob, jak´ ym teˇcou data mezi koncov´ ymi body, uˇz m´a na starosti protokol IP, kter´ y pracuje na tˇret´ı vrstvˇe podle ISO/OSI. Na ˇctvrt´e vrstvˇe, kde pracuje protokol TCP tedy nen´ı moˇzn´e pˇresnˇe urˇcit, co zp˚ usobuje zahlcen´ı, pˇr´ıpadnˇe z jak´eho d˚ uvodu. TCP vych´ az´ı pouze z informac´ı o nutnosti pˇreposlat urˇcit´e segmenty dat. Nicm´enˇe TCP mus´ı b´ yt schopno tuto situaci ˇreˇsit, aby nedoˇslo k u ´pln´emu zahlcen´ı linky a t´ım p´adem tak´e k nefunkˇcnosti sluˇzeb vyuˇz´ıvaj´ıc´ıch TCP. Kaˇzd´ y vys´ılan´ y segment dat je um´ıstˇen do fronty s ˇcasovaˇcem, kter´ y urˇc´ı, za jak dlouho m´a b´ yt paket pˇreposl´ an. Pokud by z jak´ehokoliv d˚ uvodu na s´ıti doˇslo k velk´emu zv´ yˇsen´ı provozu a k zahlcen´ı a neexistovaly by mechanismy, kter´e se s touto situac´ı vyrovnaj´ı, tak by nastal´ a situace jeˇstˇe zv´ yˇsila souˇcasn´e zahlcen´ı. Doˇslo by k tomu z toho d˚ uvodu, ˇze by nˇekter´e segmenty nebyly pˇreneseny nebo byly pˇreneseny pozdˇe, coˇz by zp˚ usobilo jejich opˇetovn´e vysl´ an´ı a jeˇstˇe d´ ale zat´ıˇzilo s´ıt’ a situace by mohla doj´ıt tak daleko, ˇze by byla s´ıt’ naprosto nepouˇziteln´ a. T´ım, ˇze TCP urˇc´ı u ´roveˇ n, pˇri kter´e nejsou vys´ılan´e pakety potvrzov´any protˇejˇskem, z´ısk´ a informaci, kter´ a je pouˇzita pˇri zamezen´ı zahlcen´ı. P˚ uvodn´ı standard RFC 793 neobsahoval t´emˇeˇr ˇz´ adn´e instrukce, jak se vyh´ ybat zahlcen´ı linky. Pozdˇeji se ovˇsem uk´azalo, ˇze pr´ avˇe 2 Routery v p´ ateˇrn´ıch s´ıt´ıch m´ısto protokolu ICMP ˇcasto vyuˇz´ıvaj´ı vyspˇel´e routovac´ı protokoly jako jsou napˇr´ıklad OSPF (Open Shortest Path First) nebo BGP (Border Gateway Protocol)
11
zahlcov´ an´ı linky je velk´ y probl´em a byly vyvinuty pˇr´ısluˇsn´e techniky ˇreˇsen´ı, kter´e byly nakonec shrnuty v RFC 2001. Jsou to techniky TCP Slow Start, Congestion Avoidance, Fast Restransmit a Fast Recovery Algorithms. V RFC 3168 byl pops´ an protokol ECN - Explicit Congestion Notification jako doplnˇek do sady TCP/IP. Je to signalizaˇcn´ı protokol, kter´ y m´a pˇredch´azet zahlcen´ı.
3.2.3
Protokol UDP
Tento protokol je dalˇs´ım ze sady protokol˚ u TCP/IP. Je pouˇz´ıv´an pro pˇrenos kr´atk´ ych zpr´ av naz´ yvan´ ych datagramy. UDP (User Datagram Protocol) ale na rozd´ıl od TCP nevytv´ aˇr´ı spojen´ı a neposkytuje bezporuchov´ y pˇrenos dat, pˇrenos dat ve spr´avn´em poˇrad´ı, znovu zas´ıl´an´ı ztracen´ ych paket˚ u, detekce a zahazov´an´ı duplicitn´ıch paket˚ u a podporu pro zamezov´an´ı zahlcen´ı linky. Pokud je nˇekter´a z tˇechto vlastnost´ı aplikac´ı poˇzadov´ana, tak mus´ı b´ yt zajiˇstˇena ve vyˇsˇs´ıch vrstv´ ach. D´ıky absenci reˇzie tˇechto vlastnost´ı je UDP ˇcasto rychlejˇs´ı a v´ ykonnˇejˇs´ı pro aplikace, kde je potˇreba pˇren´est rychle mnoho kr´atk´ ych zpr´av k mnoha klient˚ um. Je tak´e pouˇz´ıv´ ano k multicastu a broadcastu. Mezi konkr´etn´ı aplikace vyuˇz´ıvaj´ıc´ı tohoto protokolu patˇr´ı napˇr´ıklad DNS syst´em, aplikace pro streamov´an´ı multim´edi´ı, hlasov´e sluˇzby, poˇc´ıtaˇcov´e hry atd. T´ım, ˇze chyb´ı jak´ekoliv techniky pro zamezen´ı zahlcen´ı linky, je nutn´e implementovat tyto mechanismy do s´ıt’ov´ ych prvk˚ u, aby se pˇredeˇslo pˇr´ıpadn´emu kolapsu s´ıtˇe d´ıky nekontrolovan´emu provozu, kter´ y aplikace vyuˇz´ıvaj´ıc´ı UDP generuj´ı. V praxi jsou to vˇetˇsinou routery, kter´e d´ıky ˇrazen´ı paket˚ u do front a jejich pˇr´ıpadn´emu zahazov´an´ı dok´aˇz´ı kontrolovat datov´ y tok zp˚ usoben´ y protokolem UDP, pˇredch´azet tak zahlcen´ı a udrˇzet stanovenou u ´roveˇ n kvality i pro ostatn´ı aplikace. V souˇcasn´e dobˇe je vyv´ıjen protokol DCPP - Datagram Congestion Control Protocol (RFC 4340),/indexDCPP (Datagram Congestion Control Protocol) kter´ y zajist´ı kontrolu zahlcen´ı na niˇzˇs´ı vrstvˇe a kaˇzd´ a aplikace, kter´a tuto funkˇcnost bude poˇzadovat, nemus´ı tuto techniku sama implementovat. DCPP je urˇceno aplikac´ım, kter´e potˇrebuj´ı obousmˇern´e unicastov´e spojen´ı s kontrolou zahlcen´ı, ale nepotˇrebuj´ı spolehliv´e doruˇcen´ı datagram˚ u a doruˇcen´ı ve spr´ avn´em poˇrad´ı. Jsou to aplikace pro streamov´an´ı multum´edi´ı a hlasov´e sluˇzby.
3.3
IPv6
Tento protokol, p˚ uvodnˇe naz´ yv´ an IPng (IP next generation), byl navrˇzen jako n´asledn´ık protokolu IPv4 a v roce 1994 byl ofici´alnˇe schv´alen organizac´ı IETF (The Internet Engineering Task Force). Hlavn´ım d˚ uvodem jeho definice byla potˇreba zvˇetˇsen´ı adresov´eho prostoru, protoˇze s rozvojem internetu se uk´azalo, ˇze adresov´ y prostor, poskytovan´ y protokolem IPv4, bude zanedlouho vyˇcerp´an. IPv6 adresa m´a 128 bit˚ u oproti 32 bit˚ um adresy IPv4, coˇz poskytuje obrovsk´e mnoˇzstv´ı jedineˇcn´ ych IP adres a vyˇreˇs´ı se tak na velmi dlouhou dobu probl´em s nedostatkem adres. Aˇckoliv nedostatek IPv4 adres mˇel znaˇcnˇe urychlit n´astup IPv6, tak se tomu doposud nestalo d´ıky implementaci technik CIDR3 a NAT4 , kter´e ˇsetˇr´ı adresov´ y prostor a oddaluj´ı tak nevyhnuteln´ y n´astup nov´eho protokolu. 3
CIDR - Classless Inter-Domain Routing je zp˚ usob interpretace IP adres popsan´ y v RFC 1518 a RFC 1519, kter´ y nahradil pˇredchoz´ı syntaxi IP adres zaloˇzenou na tˇr´ıd´ ach. CIDR pˇrin´ aˇs´ı rozdˇelen´ı velk´ ych s´ıt´ı na pods´ıtˇe, ˇc´ımˇz je umoˇznˇeno efektivnˇejˇs´ı vyuˇzit´ı adresov´eho prostoru a je ulehˇceno smˇerovaˇc˚ um. 4 NAT - Network Address Translation je technika pˇrekladu veˇrejn´e IP adresy na neveˇrejn´e, kter´ a umoˇzn ˇuje pˇristupovat poˇc´ıtaˇc˚ um v priv´ atn´ı s´ıti do Internetu. Tato technika ˇsetˇr´ı adresov´ y prostor a tak´e chr´ an´ı poˇc´ıtaˇce ve vnitˇrn´ı s´ıti pˇred u ´tokem z internetu. Na druh´e stranˇe ale omezuje funkˇcnost mnoha sluˇzeb, zejm´ena tˇech, kter´e vyˇzaduj´ı umoˇznˇen´ı spojen´ı z internetu, nebo sluˇzeb vyuˇz´ıvaj´ıc´ıch bezstavov´e protokoly.
12
Tento nov´ y protokol pˇrinese ovˇsem mnohem v´ıc, neˇz jen vˇetˇs´ı adresov´ y prostor. IPv6 poskytne oproti IPv4 model, kdy se kaˇzd´ y klient s´ıtˇe bude moci spojit s jak´ ymkoliv dalˇs´ım klientem bez nejr˚ uznˇejˇs´ıch omezen´ı, kter´a vyvst´avaj´ı zejm´ena pˇri pouˇzit´ı pˇrekladu adres. Pˇri n´ avrhu protokolu byl br´an velk´ y ohled na moˇznosti ˇr´ızen´ı kvality sluˇzeb, coˇz je dalˇs´ı souˇcasn´ a slabina IPv4, kter´ y p˚ uvodnˇe s t´ımto probl´emem nepoˇc´ıtal. Je zjednoduˇsena hlaviˇcka IPv6 paketu a routery tak maj´ı ulehˇcenou pr´aci se zpracov´an´ım nov´ ych paket˚ u. Dalˇs´ımi d˚ uleˇzit´ ymi vlastnostmi je moˇznost zabezpeˇcen´ı, autentifikace a mobility. Pˇresn´ a specifikace protokolu je pops´ ana v dokumentu RFC 2460. Podpora protokolu IPv6 existuje jak v linuxov´em j´adˇre, tak v j´adrech syst´em˚ u *BSD jiˇz pomˇernˇe dlouhou dobu a tato technologie je jiˇz bez probl´em˚ u pouˇziteln´a ve vˇsech zmiˇ novan´ ych syst´emech. Implementac´ı IPv6 do linuxov´eho j´adra se zab´ yv´a projekt USAGI (Universal Playground for IPv6) a podpora je zaˇclenˇena od j´adra verze 2.2. *BSD syst´emy vyuˇz´ıvaj´ı pr´ ace projektu KAME a obsahuj´ı IPv6 od BSD 4.0. Oba dva tyto v´ yvojov´e t´ ymy samozˇrejmˇe spolupracuj´ı a tedy nejsou nijak velk´e rozd´ıly v n´avrhu a koneˇcn´em ˇreˇsen´ı podpory pro IPv6 v tˇechto syst´emech. D´a se ˇr´ıct, ˇze v t´eto oblasti jsou Linux a *BSD ekvivalentn´ı, a pokud se v nˇekter´em ze syst´em˚ u osvˇedˇc´ı nˇejak´e nov´e postupy a zp˚ usoby implementace, tak se vˇetˇsinou importuj´ı i do ostatn´ıch syst´em˚ u.
3.3.1
Automatick´ a konfigurace
Dalˇs´ı v´ yhodou oproti IPv4 je automatick´a konfigurace zaˇr´ızen´ı v s´ıti. Protokol poˇc´ıt´ a se dvˇema zp˚ usoby nastaven´ı s´ıt’ov´ ych parametr˚ u. Prvn´ım zp˚ usobem je takzvan´a stavov´ a konfigurace, coˇz vlastnˇe nen´ı nic nov´eho, protoˇze se jedn´a o konfiguraci prostˇrednictv´ım DHCPv65 serveru nebo PPP, kdy klient vyˇsle do s´ıtˇe dotaz a pˇr´ısluˇsn´ y server mu pˇridˇel´ı vˇsechny potˇrebn´e parametry, kter´e potˇrebuje vˇedˇet. Novinkou je bezstavov´ a konfigurace[8], kter´a nevyˇzaduje DHCP server. Je zaloˇzena na objevov´an´ı soused˚ u, kdy klient, kter´ y se pˇripojuje do s´ıtˇe, pos´ıl´ a multicastov´ y poˇzadavek RS (Router Solicitation), na kter´ y odpov´ı router takzvan´ ym RA (Router Advertisement) paketem. Klient nemus´ı nutnˇe pos´ılat RS paket, ale m˚ uˇze si pasivnˇe poˇckat na RA paket, kter´ y smˇerovaˇc periodicky zas´ıl´a. Z odpovˇedi smˇerovaˇce se klient dozv´ı prefix identifikuj´ıc´ı danou s´ıt’ a sestav´ı svou IP adresu z tohoto prefixu a identifil´ atoru rozhran´ı (vˇetˇsinou 64 bit˚ u), kter´ y se jednoznaˇcnˇe vygeneruje z jeho MAC adresy. Pokud je v s´ıti v´ıce smˇerovaˇc˚ u, tak klient pouˇz´ıv´a vˇsechny z nich stˇr´ıdavˇe a postupnˇe si upravuje svou smˇerovac´ı tabulku na z´akladˇe ICMPv6 zpr´av generovan´ ych tˇemito smˇerovaˇci. Jestliˇze se klinet pˇripoj´ı do s´ıtˇe, kde nejsou smˇerovaˇce, tak je schopen automaticky vygenerovat pouze tzv. link-local adresu, se kterou bude okamˇzitˇe schopen komunikovat s ostatn´ımi klienty pˇripojen´ ymi na stejn´em segmentu s´ıtˇe. Tato lok´aln´ı adresa nen´ı smˇerovateln´ a do dalˇs´ıch s´ıt´ı. Jak je vidˇet na obr´azku, tak link-local adresa m´ a dan´ y prefix fe80, dalˇs´ıch 48 bit˚ u jsou nuly a ˇc´ast interface ID je vygenerov´ana automaticky podle hardwarov´e adresy. Na m´em poˇc´ıtaˇci je napˇr´ıklad hardwarov´a adresa rozhran´ı eth0 00:13:D3:9B:E7:17 a z n´ı vygenerovan´a link local adresa fe80::213:d3ff:fe9b:e7176 Proces autokonfigurace se nevztahuje na smˇerovaˇce, kter´e mus´ı b´ yt nastaveny manu´alnˇe nebo nˇejak´ ym jin´ ym zp˚ usobem. 5
DHCP servery jsou aplikace komunikuj´ıc´ı prostˇrednictv´ım protokolu DHCP (Dynamic Host Configuration Protocol) a umoˇzn ˇuj´ı zaˇr´ızen´ım pˇripojen´ ych do s´ıtˇe poˇz´ adat o pˇridˇelen´ı IP adresy a dalˇs´ıch s´ıt’ov´ ych parametr˚ u. DHCP server pot´e pˇridˇeluje zaˇr´ızen´ım adresy z definovan´eho rozsahu, kter´ y m´ a k dispozici, tak aby nedoch´ azelo ke konflikt˚ um zaˇr´ızen´ı, kdy m´ a v´ıce zaˇr´ızen´ı stejnou IP adresu. 6 Pokud se v adrese vyskytne nˇekolik po sobˇe jdouc´ıch nulov´ ych skupin, tak je moˇzn´e je nahradit dvojic´ı dvojteˇcek. Ta se vˇsak v z´ apisu kaˇzd´e adresy sm´ı objevit jen jednou, aby z´ apis byl jednoznaˇcn´ y.
13
Obr´ azek 3.1: Form´at link-local IPv6 adresy
D´ıky autokonfiguraci je znaˇcnˇe ulehˇceno vytv´aˇren´ı a dalˇs´ı propojov´an´ı s´ıt´ı. Pˇrin´ aˇs´ı znaˇcn´e v´ yhody mobiln´ım zaˇr´ızen´ım, kter´e se mus´ı neust´ale pˇrihlaˇsovat do jin´ ych s´ıt´ı a konfigurovat sv´e parametry.
3.3.2
Bezpeˇ cnost
Uˇz d´ıky obrovsk´emu rozsahu adres je IPv6 bezpeˇcnˇejˇs´ı protokol. V´ ychoz´ı pods´ıt’ m´a 264 ˇuje u ´toˇcn´ık˚ um efektivnˇe skenovat celou pods´ıt’. I adres (pˇribliˇznˇe 18 ∗ 1018 ), coˇz neumoˇzn kdyby byl schopen u ´toˇcn´ık proskenovat 1 000 000 adres za sekundu, tak by mu trvalo v´ıce ´ cn´ıci budou muset vyvinout jin´e neˇz 500 000 let, neˇz by nalezl vˇsechny poˇc´ıtaˇce v s´ıti. Utoˇ strategie pro z´ısk´ av´ an´ı IP adres, kter´e ovˇsem nejsp´ıˇse nebudou tak pˇr´ımoˇcar´e, jednoduch´e a rychl´e jako souˇcasn´e zp˚ usoby. D´ıky rozˇs´ıˇren´ı bezstavov´eho protokolu popsan´em v RFC 3041 mohou nav´ıc klienti generovat veˇrejn´e adresy, kter´e se v ˇcase mˇen´ı. Zmˇeny adresy je dosaˇzeno zmˇenou pole interface identifier, ˇc´ımˇz se tak´e samozˇrejmˇe zmˇen´ı cel´a adresa a pro potenci´aln´ı u ´toˇcn´ıky je pak mnohem tˇeˇzˇs´ı takov´ y stroj identifikovat a napadnout. IPv6 poskytuje tak´e kryptograficky generovan´e adresy[1]. Kryptograficky generovan´ a adresa (CGA) je IPv6 adresa z´ıskan´a prostˇrednictv´ım zabezpeˇcen´eho objevov´an´ı soused˚ u (SEND - Secure Neighbour Discovery), pro kterou je vygenerov´ana ˇc´ast interface identifier na z´akladˇe vypoˇcten´ı haˇsovac´ı funkce z veˇrejn´eho kl´ıˇce a dalˇs´ıch parametr˚ u. Vazba mezi adresou a veˇrejn´ ym kl´ıˇcem m˚ uˇze b´ yt ovˇeˇrena vypoˇcten´ım haˇsovac´ı funkce a porovn´an´ım s interface ID. Zpr´ avy zas´ılan´e z takov´eto adresy mohou b´ yt chr´anˇeny pˇr´ısluˇsn´ ym soukrom´ ym kl´ıˇcem. Toto zabezpeˇcen´ı ke sv´e funkci nepotˇrebuje ˇz´adnou certifikaˇcn´ı autoritu nebo jinou bezpeˇcnostn´ı infrastrukturu. V IPv6 bylo moˇzn´e se zbavit protokolu ARP (Address Resolution Protocol), kter´ y v IPv4 zajiˇst’uje identifikaci soused˚ u na linkov´e vrstvˇe. Funkce tohoto protokolu je nahrazena nˇekolika funkcemi ICMP a dalˇs´ımi schopnostmi, kter´e jsou dohromady definov´any v protokolu objevov´ an´ı soused˚ u (ND - Neighbour Discovery). D´ıky absenci ARP bude nemoˇzn´e prov´adˇet u ´toky typu ARP cache poisioning.7 Dalˇs´ım pˇr´ınosem pro bezpeˇcnost pˇrenosu dat je sada protokol˚ u IPSec (IP Security) implementovan´ ych pˇr´ımo v IPv6. IPSec zajiˇst’uje bezpeˇcn´ y pˇrenos paket˚ u na s´ıt’ov´e vrstvˇe a v souˇcasn´e dobˇe je pouˇz´ıv´ ano pˇredevˇs´ım k implementaci virtu´aln´ıch priv´atn´ıch s´ıt´ı (VPN). Funkˇcnost, kterou pˇrin´ aˇs´ı IPSec je nezbytn´a pro nˇekter´e vlastnosti, kter´e IPv6 pˇr´ımo poskytuje. Jedn´ a se napˇr´ıklad o podporu mobiln´ıch zaˇr´ızen´ı, kde je vyˇzadov´ano autentizovan´e 7´ Utoˇcn´ıkovi se m˚ uˇze do s´ıtˇe podaˇrit vloˇzit nepravou vazbu mezi IP adresou a MAC adresou (ARP paket), ˇc´ımˇz doc´ıl´ı toho, ˇze data ze stroje obˇeti jsou doruˇcena jinam, nebo v˚ ubec nejsou doruˇcena. Situace se st´ av´ a kritickou, pokud je obˇet´ı u ´toku br´ ana. To m˚ uˇze v´est k odepˇren´ı sluˇzby pro celou s´ıt’ (DOS Attack).
14
spojen´ı mezi zaˇr´ızen´ım a jeho home-agentem.
3.3.3
Kvalita sluˇ zeb
Prvn´ım krokem ke zlepˇsen´ı kvality sluˇzeb, kterou je schopno IPv6 poskytovat, bylo v´ yrazn´e zjednoduˇsen´ı hlaviˇcky IP paketu oproti IPv4. Tato zmˇena umoˇzn´ı rychlejˇs´ı zpracov´an´ı paket˚ u, coˇz bude m´ıt za n´ asledek menˇs´ı n´aroky kladen´e na velmi vyt´ıˇzen´e routery a t´ım p´adem tak´e vˇetˇs´ı propustnost s´ıtˇe.
Obr´ azek 3.2: Form´at IPv6 hlaviˇcky
Podle RFC 2474 se v hlaviˇcce paketu nach´az´ı pole, kter´e slouˇz´ı k rozliˇsen´ı sluˇzeb v iternetu a nastaven´ı priority, s jakou bude paket zpracov´an. Tento model se naz´ yv´a Differentiated Services a nahrazuje pˇredchoz´ı pole ToS (Type of Service) v IPv4 a traffic class v IPv6. DS pole definuje per-hop behavior (PHB), coˇz je rozhodnut´ı o zp˚ usobu, jak´ ym bude paket klasifikov´ an a jak´a strategie se pouˇzije pˇri jeho odesl´an´ı. V dokumentu RFC nen´ı naˇr´ızeno, jak´ ym zp˚ usobem maj´ı syst´emy implementovat takov´eto chov´an´ı. To jak se jednotliv´ a zaˇr´ızen´ı postav´ı k moˇznosti vyuˇz´ıt t´eto vlastnosti, z´avis´ı tedy pouze na v´ yrobci, pˇr´ıpadnˇe na administr´atorovi syst´emu. To se projevilo jako nev´ yhoda, protoˇze r˚ uzn´e smˇerovaˇce se mohou k paket˚ um chovat r˚ uznˇe a nelze pˇredpovˇedˇet chov´an´ı takov´eho spojen´ı. Z komerˇcn´ıho hlediska je nemoˇzn´e zajistit r˚ uzn´e tˇr´ıdy konektivity na z´akladˇe tohoto syst´emu, protoˇze to, co jeden poskytovatel m˚ uˇze povaˇzovat za prioritn´ı provoz, druh´ y tˇreba pˇreˇrad´ı do bˇeˇzn´eho provozu. Tento zp˚ usob funguje pouze pokud vˇsichni dodrˇzuj´ı stanoven´ a pravidla. Realita je ovˇsem takov´a, ˇze nˇekter´e syst´emy jednoduˇse nastav´ı vˇetˇs´ı prioritu sv´emu provozu, i kdyˇz k tomu nemaj´ı patˇriˇcn´ y d˚ uvod. Do IP protokol˚ u byla tak´e pˇrid´ana podpora ECN (Explicit Congestion Notification, RFC 3168). Je to zp˚ usob signalizace smˇerovaˇce o zahlcen´ı linky. D´ıky aktivn´ı spr´avˇe fronty (napˇr. RED - Random Early Detection) jsou schopny smˇerovaˇce detekovat zahlcen´ı jeˇstˇe pˇred t´ım, neˇz fronta pˇreteˇce. A d´ıky ECN uˇz nejsou routery nuceny k zahazov´an´ı paket˚ u, aby indikovaly zahlcen´ı. M´ısto zahozen´ı paketu mohou nastavit pˇr´ıznak CE (Congestion
15
Obr´ azek 3.3: Form´at IPv4 hlaviˇcky
Experienced) v IP hlaviˇcce. D´ıky kombinaci tˇechto technik jsou omezeny neˇz´adouc´ı efekty, kter´e vypl´ yvaly z pˇreteˇcen´ı fronty a v´ ysledkem je nˇekolik zlepˇsen´ı: • Bude zahazov´ ano menˇs´ı mnoˇzstv´ı paket˚ u. • Zv´ yˇs´ı se vyuˇzit´ı linky d´ıky tomu, ˇze bude potˇreba m´enˇe TCP synchronizace. • T´ım, ˇze se bude udrˇzovat rozumn´a velikost fronty, se sn´ıˇz´ı zpoˇzdˇen´ı a zkreslen´ı v jednotliv´ ych toc´ıch. ˇıˇrka p´ • S´ asma bude sd´ılena v´ıce rovnocennˇe mezi jednotliv´ ymi toky. Novinkou oproti IPv4 je 20 bitov´e pole flow label zvolen´e aplikac´ı nebo j´adrem pro dan´ y soket. Flow, neboli tok, je posloupnost paket˚ u vyslan´ ych z urˇcit´eho zdroje do urˇcit´eho c´ıle, pro kterou poˇzaduje zdroj nˇejak´e speci´aln´ı zach´azen´ı pˇr´ısluˇsn´ ymi smˇerovaˇci. Jakmile je oznaˇcen´ı toku vybr´ ano, tak se po cestˇe paketu jiˇz nesm´ı mˇenit. Pokud je oznaˇcen´ı rovno nule, coˇz je v´ ychoz´ı hodnota, tak to znamen´a, ˇze paket nen´aleˇz´ı do ˇz´adn´eho toku. Hlavn´ı v´ yhoda oznaˇcen´ı toku spoˇc´ıv´ a v tom, ˇze smˇerovaˇce nemus´ı zkoumat vnitˇrek paket˚ u k tomu, aby identifikoval tok, ke kter´emu paket patˇr´ı, a to i pokud je pouˇzito ˇsifrov´an´ı. V IPv6 je kaˇzd´ y tok jednoznaˇcnˇe identifikov´an trojic´ı u ´daj˚ u (c´ılov´a adresa, zdrojov´a adresa a flow label), oproti tomu v IPv4 paketu k takov´e identifikaci potˇrebujeme pˇetici (zdrojov´ a a c´ılov´a adresa, protokol, zdrojov´ y a c´ılov´ y port). Jednoduch´a identifikace tok˚ u slouˇz´ı k jejich efektivn´ımu klasifikov´ an´ı a n´ asledn´emu pˇriˇrazen´ı priorit. V souˇcasn´e dobˇe se pracuje na n´avrhu protokolu[4], kter´ y umoˇzn´ı alokaci nezbytn´ ych prostˇredk˚ u jednotliv´emu toku nebo jejich skupinˇe na jejich cestˇe s´ıt´ı. Toto sign´aln´ı sch´ema bude vyˇzadovat podporu v hardwaru pˇr´ısluˇsn´ ych s´ıt’ov´ ych prvk˚ u (nejˇcastˇeji smˇerovaˇc˚ u). Kvalita sluˇzby tak bude nastavena v re´aln´em ˇcase bez u ´ˇcasti nˇejak´e extern´ı softwarov´e signalizaˇcn´ı struktury, jakou je napˇr´ıklad Reservation Protocol (RSVP). Tuto funkˇcnost bude moˇzn´e zaˇclenit jak do IPv4, tak IPv6 paket˚ u. U IPv6 bude s v´ yhodou pouˇzito pole 16
next header, kter´e odk´ aˇze na dalˇs´ı hlaviˇcku, kter´a bude definovat poˇzadavky toku na kvalitu sluˇzeb. V´ yhoda IPv6 spoˇc´ıv´ a v tom, ˇze dok´aˇze vyuˇz´ıt tohoto protokolu i pˇri ˇsifrovan´ ych spojen´ıch pomoc´ı IPSec, kdeˇzto s IPv4 to nen´ı bez u ´pravy IPSec moˇzn´e.
17
Kapitola 4
Prostˇ redky pro podporu QoS v linuxu Kl´ıˇcov´ ymi prvky, na kter´ ych je postavena podpora pro ˇr´ızen´ı kvality sluˇzeb v GNU Linuxu jsou tˇri z´ akladn´ı prvky: ˇ ıc´ı discipl´ına - queuing discipline • Rad´ • Tˇr´ıdy - classes • Filtry/pl´ anovaˇce/klasifik´ atory - Filters/Policers/Classifiers Pakety, pˇrich´ azej´ıc´ı z internetu, spadaj´ı pˇr´ımo do filtru, a odtud jsou pˇriˇrazeny pˇr´ısluˇsn´e ˇrad´ıc´ı discipl´ınˇe, kter´ a je n´ aslednˇe rozdˇel´ı do jednotliv´ ych tˇr´ıd. Kaˇzd´e s´ıt’ov´e zaˇr´ızen´ı v linuxu vlastn´ı frontu (v´ ychoz´ı frontou je FIFO), kter´a definuje, jak jsou zaˇrazen´e pakety ˇ ıc´ı discipl´ıny mohou b´ zpracov´ av´ any a ke kaˇzd´e frontˇe je pˇriˇrazena tˇr´ıda. Rad´ yt r˚ uzn´ ych typ˚ u. Mezi nejpouˇz´ıvanˇejˇs´ı patˇr´ı: • Class Based Queuing (CBQ) • Hiearchical Token Bucket (HTB) • First In First Out (FIFO) • Traffic Equalizer (TEQL) • Stochastic Fair Queuing (SFQ) • Random Early Detection • Generalized RED (GRED) • Priority • Hierarchical Fair Service Curve (HFSC) ˇ Razen´ ı paket˚ u do front a n´ asledn´a obsluha tˇechto front s definovanou prioritou nebo propustnost´ı je velice d˚ uleˇzit´ ym a pouˇz´ıvan´ ym zp˚ usobem zajiˇstˇen´ı poˇzadovan´e kvality sluˇzeb. Toto ˇrazen´ı se dˇeje na u ´rovni s´ıt’ov´e vrstvy podle sch´ematu ISO/OSI a je navrˇzeno tak, ˇze jakmile pakety odes´ılan´e z poˇc´ıtaˇce vstupuj´ı do s´ıt’ov´e vrstvy, tak je ˇrad´ıc´ı mechanismy 18
pˇr´ıtomn´e v j´ adˇre operaˇcn´ıho syst´emu zaˇrad´ı do front, kde ˇcekaj´ı na dalˇs´ı zpracov´an´ı. Modifikac´ı ˇrad´ıc´ıch strategi´ı m˚ uˇzeme dos´ahnout rovnocenn´eho sd´ılen´ı ˇs´ıˇrky p´asma mezi r˚ uzn´ ymi aplikacemi, uˇzivateli nebo poˇc´ıtaˇci. Takov´ y zp˚ usob oˇsetˇren´ı sd´ılen´ı linky je ale pouˇziteln´ y pouze v odchoz´ım smˇeru. Jakmile totiˇz paket doraz´ı na s´ıt’ov´e rozhran´ı v pˇr´ıchoz´ım smˇeru, tak je pozdˇe jej ˇradit do nˇejak´ ych front, protoˇze uˇz spotˇreboval urˇcitou kapacitu p´asma k tomu, ˇze byl pˇrijat vstupn´ım rozˇ sen´ım tohoto probl´emu je nastaven´ı ˇrazen´ı na nadˇrazen´em routeru, a to na hran´ım. Reˇ vnitˇrn´ım rozhran´ı, kde pakety opouˇstˇej´ı router a smˇeˇruj´ı do vnitˇrn´ı s´ıtˇe. Subsyst´em, kter´ y obstar´ av´ a ˇr´ızen´ı toku dat, je postaven na r˚ uzn´ ych modulech, kter´e se zav´adˇej´ı do j´ adra operaˇcn´ıho syst´emu a uˇzivatelsk´ ych n´astroj˚ u jako jsou ip, iptables a tc. Dohromady jsou tyto programy schopny vytvoˇrit velice komplexn´ı syst´em pro zajiˇstˇen´ı kvality r˚ uzn´ ych sluˇzeb nab´ızen´ ych na serverech nebo rovnocenn´e postaven´ı z´akazn´ık˚ u ISP. Kl´ıˇcovou roli v definov´ an´ı jiˇz zn´am´ ych front hraje program tc. Pomoc´ı tc se tak´e pˇriˇrazuj´ı jednotliv´e tˇr´ıdy k front´ am a m˚ uˇzeme ho t´eˇz vyuˇz´ıt k pˇriˇrazen´ı paket˚ u do tˇr´ıd. Pˇr´ıkazem tc bez parametr˚ u vyvol´ ame syntaxi tohoto pˇr´ıkazu: # tc Usage: tc [ OPTIONS ] OBJECT { COMMAND | help } where OBJECT := { qdisc | class | filter | action } OPTIONS := { -s[tatistics] | -d[etails] | -r[aw] | -b[atch] file } Kaˇzd´e s´ıt’ov´e rozhran´ı m´ a definov´ an nˇejak´ y ˇrad´ıc´ı mechanismus paket˚ u, kter´ y urˇcuje, jak´ ym zp˚ usobem budou zpracov´ any. V linuxu se tento mechanismus naz´ yv´a qdisc (queueing discipline) a m˚ uˇze b´ yt zobrazen pˇr´ıkazem ip link show. V´ ychoz´ım algoritmem pro ˇrazen´ı paket˚ u je pfifo fast, kter´ y funguje na principu fronty FIFO. Tuto v´ ychoz´ı hodnotu m˚ uˇzeme zmˇenit pr´ avˇe pouˇzit´ım n´ astroje tc: tc qdisc add dev eth0 root handle 1:0 htb T´ımto pˇr´ıkazem jsme pˇredefinovali v´ ychoz´ı ˇrad´ıc´ı algoritmus na HTB1 na rozhran´ı eth0. Handle je uˇzivatelem specifikovan´e ˇc´ıslo ve tvaru MAJOR:MINOR. MINOR ˇc´ıslo kaˇzd´eho pl´anovaˇce (qdisc) mus´ı b´ yt nula. Koˇrenov´ y qdisc m˚ uˇzeme ch´ apat jako hlavn´ı kontejner, do kter´eho spad´a vˇsechen provoz. Nad t´ımto koˇrenem m˚ uˇzeme vystavˇet potˇrebnou strukturu tˇr´ıd, do kter´ ych rozdˇel´ıme poˇzadovan´e typy provozu tak, aby vyhovovaly dan´ ym poˇzadavk˚ um: tc class add dev eth0 parent 1:0 classid 1:1 htb rate 512kbit tc class add rate tc class add rate tc class add rate
HTB - Hierarchical Token Bucket. Podrobn´e informace o tomto pl´ anovaˇci a jeho implementaci lze nal´ezt v dokumentaci na str´ ank´ ach projektu http://luxik.cdi.cz/ devik/qos/htb/ .
19
V tomto pˇr´ıkladˇe jsme tedy definovali tˇr´ıdu, jej´ıˇz propustnost je 512 kilobit˚ u za sekundu ˇ a n´aslednˇe ji rozdˇelili na tˇri tˇr´ıdy s r˚ uznou prioritou a kapacitou. C´ım menˇs´ı je parametr prio, t´ım je priorita vˇetˇs´ı. Parametr rate urˇcuje minim´aln´ı propustnost tˇr´ıdy a parametr ceil jej´ı maxim´ aln´ı propustnost. Nav´ıc byl ke kaˇzd´e koncov´e tˇr´ıdˇe pˇrid´an SFQ2 pl´anovaˇc, kter´ y zajist´ı rovnocenn´e postaven´ı jednotliv´ ych spojen´ı spadaj´ıc´ıch do t´eto tˇr´ıdy, obzvl´aˇstˇe je-li tˇr´ıda plnˇe vyt´ıˇzen´ a. Nakonec je tˇreba zajistit spr´ avn´e rozdˇelen´ı paket˚ u do jednotliv´ ych tˇr´ıd. Zde se nask´ yt´ a v´ıce moˇznost´ı: Jednou z nich je pˇr´ım´e pouˇzit´ı iptables a c´ıle CLASSIFY, dalˇs´ı moˇznost´ı je pouˇzit´ı c´ıle MARK v iptables pro oznaˇcen´ı jednotliv´ ych paket˚ u a n´asledn´e pˇriˇrazen´ı do tˇr´ıd programem tc. iptables -t mangle -A POSTROUTING -o eth0 -p tcp --sport 22 \ -j MARK --set-mark 20 tc filter add dev eth0 protocol ip parent 1:0 handle 20 fw flowid 1:20 Posledn´ı moˇznost´ı je vyuˇzit´ı u32 selektoru, kter´ y analyzuje hlaviˇcku paketu a podle hodnoty urˇcit´ ych bit˚ u nastavuje pˇr´ısluˇsnou tˇr´ıdu. Pouˇzit´ı tohoto n´astroje vyˇzaduje detailn´ı znalost struktury hlaviˇcky paketu. Pˇr´ıklady pouˇzit´ı tohoto filtru lze naj´ıt na internetu[5].
4.1
Iptables - paketov´ y filter v Linuxu
Linuxov´ a j´ adra mˇela paketov´ y filtr jiˇz od verze 1.1. Tato prvn´ı verze byla zaloˇzena na filtru ipfw z BSD Unixu a byla portov´ana do Linuxu v roce 1997 Alanem Coxem. V Linuxu ˇrady 2.0 byl tento filtr vylepˇsen a vznikl n´astroj ipwadm, kter´ y nastavoval j´adro v oblasti filtrov´an´ı paket˚ u. V j´ adrech ˇrady 2.2 byl uveden n´astroj ipchains, kter´ y pˇrinesl moˇznost definov´an´ı vlastn´ıch ˇretˇezc˚ u a jejich struktur ke standardn´ım zabudovan´ ym ˇretˇezc˚ um (chains) input, output a forward. Kaˇzd´ y paket proch´ azej´ıc´ı routerem musel proj´ıt alespoˇ n tˇremi z´akladn´ımi implicitn´ımi ˇretˇezci. Posledn´ı verz´ı paketov´eho filtru v Linuxu jsou iptables. Tento filtr je standardnˇe v j´adˇre od verze 2.4 a v souˇcasn´ ych j´ adrech 2.6 je jedin´ ym podporovan´ ym filtrem. Velk´ y rozd´ıl oproti ipchains spoˇc´ıv´ a v pouˇzit´ı ˇretˇezc˚ u. Pakety, kter´e proch´azej´ı routerem (ty kter´e nejsou urˇceny pro router samotn´ y), projdou pouze pˇres ˇretˇezec FORWARD. Tuto skuteˇcnost je tˇreba m´ıt na pamˇeti a na takov´em routeru, kter´ y ˇcasto b´ yv´a i firewallem, je nutno m´ıt dvˇe sady pravidel, a to jednak pro pakety urˇcen´e pˇr´ımo pro router a d´ale pro pakety, kter´e budou pˇrepos´ıl´ any do vnitˇrn´ı s´ıtˇe. Syntaxe programu Iptables je d´ıky jeho komplexnosti pomˇernˇe sloˇzit´a a pro podrobn´e informace je vhodn´e nahl´ednout do manu´alov´e str´anky programu, kter´a by mˇela b´ yt dostupn´a na kaˇzd´em poˇc´ıtaˇci s nainstalovan´ ym programem Iptables.
4.1.1
Syntaxe a pouˇ zit´ı iptables
Pravidla, kter´ a urˇcuj´ı, jak maj´ı b´ yt pakety filtrov´any j´adrem operaˇcn´ıho syst´emu, se definuj´ı pˇr´ıkazem iptables a n´ asleduj´ıc´ımi parametry: • Typ paketu - urˇcuje typ paketu, kter´ y bude pravidlo filtrovat (TCP, UDP, ICMP). 2
SFQ - Stochastic Fair Queueing. V ˇsest´e kapitole Traffic Control HOWTO[2] jsou pops´ any beztˇr´ıdn´ı (classless) pl´ anovaˇce s dalˇs´ımi pˇr´ıklady.
20
Obr´ azek 4.1: Cesta paketu j´adrem linuxu
• P˚ uvod nebo c´ıl paketu • C´ıl - urˇcuje, jak´ a akce se provede nad paketem, kter´ y vyhovuje krit´eri´ım definovan´ ych v pravidle. Silnou str´ ankou iptables je moˇznost pouˇzit´ı v´ıce tabulek k rozhodnut´ı o osudu pˇr´ısluˇsn´eho paketu v z´ avislosti na poˇzadovan´e akci, kter´a se m´a s pˇr´ısluˇsn´ ym paketem prov´est a jeho typu. V´ ychoz´ı tabulka se jmenuje filter a obsahuje tˇri zabudovan´e ˇretˇezce: • INPUT pro pakety pˇrich´ azej´ıc´ı na poˇc´ıtaˇc samotn´ y, • OUTPUT pro lok´ alnˇe generovan´e pakety opouˇstˇej´ıc´ı poˇc´ıtaˇc, • FORWARD pro pakety routovan´e skrze poˇc´ıtaˇc. Tato tabulka se pouˇzije v pˇr´ıpadˇe, ˇze nen´ı specifikov´ana explicitnˇe ˇz´adn´a jin´a tabulka. Iptables ale implicitnˇe obsahuj´ı dalˇs´ı dvˇe tabulky, kter´e maj´ı svou specifickou u ´lohu. Tabulka nat m˚ uˇze b´ yt pouˇzita k modifikov´an´ı zdrojov´e nebo c´ılov´e adresy zaznamenan´e v paketu. Tato tabulka obsahuje tˇri ˇretˇezce: • PREROUTING pro pozmˇen ˇov´an´ı paket˚ u ihned, jakmile vstoup´ı pˇres s´ıt’ov´e rozhran´ı, • OUTPUT pro pozmˇen ˇov´ an´ı lok´alnˇe generovan´ ych paket˚ u pˇred routov´an´ım, • POSTROUTING pro pozmˇen ˇov´an´ı paket˚ u, kter´e vystupuj´ı pˇres s´ıt’ov´e rozhran´ı. 21
Dalˇs´ı tabulkou je mangle, kter´a se pouˇz´ıv´a pro r˚ uzn´e dalˇs´ı speci´aln´ı manipulace s pa3 ketem a obsahuje vˇsechny dosud zm´ınˇen´e ˇretˇezce, jejichˇz pouˇzit´ı je na stejn´ ych m´ıstech cesty paketu jako u pˇredchoz´ıch tabulek. Iptables tak´e umoˇzn ˇuj´ı vytvoˇrit si dalˇs´ı ˇretˇezce pro kaˇzdou z tabulek. Vˇetˇsina pˇr´ıkaz˚ u vloˇzen´ı pravidla m´a n´asleduj´ıc´ı strukturu: iptables [-t ] <parameter 1> \
