VYSOK ´
E U ˇ
CEN´I TECHNICK ´
E V BRN ˇ
E
BRNO UNIVERSITY OF TECHNOLOGYFAKULTA INFORMA ˇ
CN´ICH TECHNOLOGI´I
´
USTAV INFORMA ˇ
CN´ICH SYST ´
EM ˚
U
FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS
SYST ´
EM PRO U ˇ
ZIVATELEM ˇ
R´IZEN ´
E QOS
DIPLOMOV ´
A PR ´
ACE
MASTER’S THESIS
AUTOR PR ´
ACE
OLD ˇ
RICH PLCHOT
AUTHOR
VYSOK ´
E U ˇ
CEN´I TECHNICK ´
E V BRN ˇ
E
BRNO UNIVERSITY OF TECHNOLOGYFAKULTA INFORMA ˇ
CN´ICH TECHNOLOGI´I
´
USTAV INFORMA ˇ
CN´ICH SYST ´
EM ˚
U
FACULTY OF INFORMATION TECHNOLOGY DEPARTMENT OF INFORMATION SYSTEMS
SYST ´
EM PRO U ˇ
ZIVATELEM ˇ
R´IZEN ´
E QOS
USER ORIENTED QOS SYSTEM
DIPLOMOV ´
A PR ´
ACE
MASTER’S THESIS
AUTOR PR ´
ACE
OLD ˇ
RICH PLCHOT
AUTHOR
VEDOUC´I PR ´
ACE
Ing. TOM ´
A ˇ
S KA ˇ
SP ´
AREK
SUPERVISOR
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 diskuto-vat 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 nasta-vit kvalitu sluˇzeb i bez nutnosti studovat specifick´e vlastnosti komunikaˇcn´ıch protokol˚u na ´
urovni s´ıt’ov´e nebo aplikaˇcn´ı vrstvy. Souˇc´ast´ı projektu je tak´e teoretick´y ´uvod do proble-matiky 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.
Keywords
Linux, TCP/IP, IPv6, quality of service, QoS, Iptables, router, HTB, kernel, ISO/OSI, packet, packet header, neural networks, classification, data flow, pcap
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 in-formaˇ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.
Obsah
1 Uvod´ 5
2 Kvalita sluˇzeb (QoS) 6
3 Z´akladn´ı principy s´ıt’ov´e architektury 8
3.1 Referenˇcn´ı OSI model . . . 8
3.2 Sada protokol˚u TCP/IP . . . 9
3.2.1 Protokol ICMP . . . 10 3.2.2 Protokol TCP . . . 11 3.2.3 Protokol UDP . . . 12 3.3 IPv6 . . . 12 3.3.1 Automatick´a konfigurace . . . 13 3.3.2 Bezpeˇcnost . . . 14
3.3.3 Kvalita sluˇzeb . . . 15
4 Prostˇredky pro podporu QoS v linuxu 18 4.1 Iptables - paketov´y filter v Linuxu . . . 20
4.1.1 Syntaxe a pouˇzit´ı iptables . . . 20
5 R´ˇızen´ı kvality sluˇzeb pomoc´ı klasifikace datov´ych tok˚u 23 5.1 N´avrh syst´emu pro ˇr´ızen´ı QoS pomoc´ı anal´yzy datov´ych tok˚u . . . 25
6 Implementace navrˇzen´eho syst´emu 28 6.1 Zachyt´av´an´ı paket˚u . . . 28
6.2 Rozˇrazen´ı paket˚u do jednotliv´ych tok˚u . . . 29
6.3 Vytvoˇren´ı charakteristick´eho vektoru . . . 30
6.4 Klasifik´ator datov´ych tok˚u . . . 32
6.5 Nastaven´ı priorit paket˚um pomoc´ı iptables . . . 35
6.6 Sch´ema ˇrad´ıc´ıch discipl´ın . . . 36
7 Pouˇzit´ı a testy syst´emu 38 7.1 instalace a pouˇzit´ı . . . 38
7.2 Testy pamˇet’ov´e sloˇzitosti a v´ypoˇcetn´ı n´aroˇcnosti . . . 39
8 Z´avˇer 41
B Popis technick´eho vybaven´ı 49
B.1 Testovac´ı poˇc´ıtaˇce . . . 49 B.1.1 Server . . . 49 B.1.2 Pracovn´ı stanice . . . 49
Seznam tabulek
3.1 ISO/OSI model . . . 8
3.2 Zn´azornˇen´ı TCP/IP do ISO/OSI modelu . . . 10
6.1 Klasifikace do tˇr´ıd . . . 35
Seznam obr´
azk˚
u
2.1 Typick´e pˇripojen´ı s´ıtˇe do internetu . . . 7
3.1 Form´at link-local IPv6 adresy . . . 14
3.2 Form´at IPv6 hlaviˇcky . . . 15
3.3 Form´at IPv4 hlaviˇcky . . . 16
4.1 Cesta paketu j´adrem linuxu . . . 21
5.1 Interaktivn´ı provoz pˇres SSH . . . 24
5.2 Neinteraktivn´ı provoz pˇres SSH . . . 25
5.3 Sch´ema navrˇzen´eho syst´emu pro ˇr´ızen´ı QoS . . . 27
6.1 Plnˇe propojen´a dopˇredn´a s´ıt’ s jednou skrytou vrstvou a bias neurony . . . 34
6.2 Sigmoid´aln´ı aktivaˇcn´ı funkce . . . 35
7.1 Z´avislost obsazen´e pamˇeti na poˇctu spojen´ı . . . 40
A.1 Typ 1 - Download . . . 45
A.2 Typ 2 - Streamovan´e video . . . 46
A.3 Typ 3 - Interaktivn´ı traffic . . . 46
A.4 Typ 4 - Reˇzie spojen´ı . . . 47
A.5 Typ 5 - Voice over IP . . . 47
Kapitola 1
´
Uvod
Dneˇsn´ı svˇet si nelze pˇredstavit bez moˇznosti snadn´e a rychl´e komunikace, internetu a mul-tim´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 inter-netu ˇreˇs´ı probl´em ´uzk´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ˇ s-tˇ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 na-vrhnout 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 ´uvod 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 pro-zkoum´any teoretick´e mater´ı´aly a navrˇzena architektura v´ysledn´eho syst´emu.
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 dosaho-vat 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, fun-guj´ı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´ı ´uzk´ych hrdel s´ıtˇe. V pˇr´ıpadˇe velk´ych telekomunikaˇcn´ıch spoleˇcnost´ı,
poskytuj´ıc´ıch pˇr´ıstup k p´ateˇrn´ım s´ıt´ım o velmi vysok´e propustnosti, mus´ı b´yt s´ıt’ dimen-zov´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 protokolRSVP (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 tak jej´ı vysokou ´uroveˇn pˇri zajiˇstˇen´ı sluˇzeb. ´Uzk´ym hrdlem se tedy v mnoha pˇr´ıpadech st´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.
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ˇzˇnuje aplikac´ım pˇr´ıstup ke komunikaˇcn´ım kan´al˚um a n´aslednou spolupr´aci.
7 Aplikaˇcn´ı vrstva – Application Layer http, ftp, SMTP 6 Prezentaˇcn´ı vrstva – Presentation Layer SSL, TLS 5 Relaˇcn´ı vrstva – Session Layer TCP
4 Transportn´ı vrstva – Transport Layer TCP, UDP, SCTP 3 S´ıt’ov´a vrstva – Network Layer IP, ICMP, ARP 2 Vrstva datov´ych spoj˚u – Data Link Layer Ethernet, ATM, PPP 1 Fyzick´a vrstva – Physical Layer DSL, ISDN, 100BASE-T
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 kom-presi 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 inter-netov´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.
ˇ
C´ısla port˚u pˇridruˇzen´ych k hlavn´ım internetov´ym aplikac´ım jsou pˇriˇrazov´ana organi-zac´ı IANA (Internet Assisgned Numbers Authority) a m˚uˇzeme je nal´ezt v souboru /etc/services. ˇC´ısla port˚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 posky-tov´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 ra-diov´y sign´al atd.) pˇres komunikaˇcn´ı m´edium na elektrick´e a mechanick´e ´urovni. 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).1Je pouˇz´ıv´an na paketovˇe orientovan´ych s´ıt´ıch a zajiˇst’uje pˇrenos paketu, aniˇz by garantoval ´uspˇeˇsnost doruˇcen´ı, pˇr´ıpadnˇe zajiˇst’oval spr´avnost doruˇcen´ych dat. Tyto ´ukoly pˇrenech´av´a vyˇsˇs´ım protokol˚um, kter´ym poskytuje abstrakci nad pˇrenosov´ym m´ediem a umoˇzˇnuje 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.
Referenˇcn´ı ISO/OSI model TCP/IP
Aplikaˇcn´ı vrstva S´ıt’ov´e aplikace Prezentaˇcn´ı vrstva Rozhran´ı soket˚u
Relaˇcn´ı Vrstva
Transportn´ı vrstva TCP UDP S´ıt’ov´a vrstva IP ICMP Vrstva datov´ych spoj˚u ARP, RARP, NDIS
Fyzick´a vrstva Fyzick´e rozhran´ı s´ıt’ov´eho zaˇr´ızeni
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 Pro-tocol) je protokol transportn´ı vrstvy, kter´y pˇrev´ad´ı zpr´avy do posloupnosti paket˚u na zdro-jov´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ˇzˇnuje propojen´ı poˇc´ıtaˇc˚u na aplikaˇcn´ı ´urovni, coˇz n´am umoˇzˇnuje 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 proto-kolu 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´ı ´urovni.
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 ge-nerov´any uˇzivatelsk´ymi aplikacemi, aˇckoliv existuj´ı aplikace jako napˇriklad ping nebo tra-ceroute, pomoc´ı kter´ych je moˇzno rychle a jednoduˇse diagnostikovat z´akladn´ı stav s´ıtˇe.[5]
Datagramy protokolu ICMP jsou pˇren´aˇseny protokolem IP a poskytuj´ı zaˇr´ızen´ım v s´ıti infor-mace 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´ı ´urovni. 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 jednot-liv´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 ob-vykle 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 infor-mac´ı 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 ´upln´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´ı ´uroveˇ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
2Routery v p´ateˇrn´ıch s´ıt´ıch m´ısto protokolu ICMP ˇcasto vyuˇz´ıvaj´ı vyspˇel´e routovac´ı protokoly jako jsou
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 zame-zov´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 nekon-trolovan´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´ı kontrolo-vat datov´y tok zp˚usoben´y protokolem UDP, pˇredch´azet tak zahlcen´ı a udrˇzet stanovenou ´
uroveˇ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 En-gineering 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 proto-kolem 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 dlou-hou 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.
3CIDR - 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ˇzˇnuje 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 ´utokem 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.
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 ad-res. 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 jebezstavov´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 pa-ket, 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´ı ad-resa 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 prefixfe80, 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 Configu-ration Protocol) a umoˇzˇnuj´ı 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.
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 adres (pˇribliˇznˇe 18∗1018), coˇz neumoˇzˇnuje ´utoˇcn´ık˚um efektivnˇe skenovat celou pods´ıt’. I kdyby byl schopen ´utoˇcn´ık proskenovat 1 000 000 adres za sekundu, tak by mu trvalo v´ıce neˇz 500 000 let, neˇz by nalezl vˇsechny poˇc´ıtaˇce v s´ıti. ´Utoˇcn´ıci budou muset vyvinout jin´e 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 gene-rovat 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´ı ´utoˇ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´astinterface 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 pro-tokolu objevov´an´ı soused˚u (ND - Neighbour Discovery). D´ıky absenci ARP bude nemoˇzn´e prov´adˇet ´utoky typu ARP cache poisioning.7
Dalˇs´ım pˇr´ınosem pro bezpeˇcnost pˇrenosu dat je sada protokol˚u IPSec (IP Security) im-plementovan´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 po-skytuje. 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´ı ´utoku br´ana. To m˚uˇze v´est k odepˇren´ı sluˇzby pro celou s´ıt’ (DOS Attack).
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´ı pa-ket˚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 Di-fferentiated 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 to-hoto 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
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.
• ˇS´ıˇrka p´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´ı ´udaj˚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
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 ´upravy IPSec moˇzn´e.
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:
• Rad´ıc´ı discipl´ına - queuing disciplineˇ
• 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 zpracov´av´any a ke kaˇzd´e frontˇe je pˇriˇrazena tˇr´ıda. ˇRad´ıc´ı discipl´ıny mohou b´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 pro-pustnost´ı 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 ´urovni s´ıt’ov´e vrstvy podle sch´ematu ISO/OSI a je navrˇzeno tak, ˇ
pˇr´ıtomn´e v j´adˇre operaˇcn´ıho syst´emu zaˇrad´ı do front, kde ˇcekaj´ı na dalˇs´ı zpracov´an´ı. Modi-fikac´ı ˇ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 vodchoz´ı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-hran´ım. ˇReˇsen´ım tohoto probl´emu je nastaven´ı ˇrazen´ı na nadˇrazen´em routeru, a to na 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 programtc. 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´ıkazemtc
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 dis-cipline) 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 pro-voz. 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 dev eth0 parent 1:1 classid 1:20 htb \
rate 100kbit ceil 100kbit prio 0
tc class add dev eth0 parent 1:1 classid 1:21 htb \ rate 300kbit ceil 512kbit prio 1
tc class add dev eth0 parent 1:1 classid 1:22 htb \ rate 100kbit ceil 512kbit prio 2
tc qdisc add dev eth0 parent 1:20 handle 20:0 sfq perturb 10 tc qdisc add dev eth0 parent 1:21 handle 21:0 sfq perturb 10 tc qdisc add dev eth0 parent 1:22 handle 21:0 sfq perturb 10
1
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/ .
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 programemtc.
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´astrojipchains, 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 impli-citn´ımi ˇretˇezci.
Posledn´ı verz´ı paketov´eho filtru v Linuxu jsouiptables. 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 do-stupn´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 iptablesa 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.
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 jmenujefilter 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 ´ulohu. 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ˇeˇnov´an´ı paket˚u ihned, jakmile vstoup´ı pˇres s´ıt’ov´e rozhran´ı,
• OUTPUT pro pozmˇeˇnov´an´ı lok´alnˇe generovan´ych paket˚u pˇred routov´an´ım,
Dalˇs´ı tabulkou jemangle, kter´a se pouˇz´ıv´a pro r˚uzn´e dalˇs´ı speci´aln´ı manipulace s pa-ketem a obsahuje vˇsechny3 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ˇzˇnuj´ı 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 <table-name>] <command> <chain-name> <parameter 1> \ <option 1> <parameter n> <option n>
Volba<table-name>umoˇzˇnuje vybrat jinou tabulku neˇz implicitn´ı filter. Volba<command>4
je centrum pˇr´ıkazu, kde se specifikuje, jak´a akce se provede, napˇr´ıklad pˇrid´an´ı nebo smaz´an´ı pravidla z pˇr´ısluˇsn´eho ˇretˇezce, kter´y je uveden volbou <chain-name>. Za <chain-name>
jsou dvojice parametr˚u a voleb, kter´e urˇcuj´ı co se stane, jakmile paket vyhov´ı pravidlu. Pro ´
upln´y pˇrehled struktury pˇr´ıkazu iptablesstaˇc´ı zadat pˇr´ıkaziptables -h.
3
Tato tabulka p˚uvodnˇe obsahovala jen dva ˇretˇezce a to PREROUTING a OUTPUT a to aˇz do verze j´adra 2.4.17. Od verze 2.4.18 obsahuje tak´e zb´yvaj´ıc´ı tˇri ˇretˇezce: INPUT, FORWARD a POSTROUTING.
4
V manu´alov´e str´ance lze nal´ezt kompletn´ı popis pˇr´ıkaz˚u a parametr˚u, zde si postupnˇe uk´aˇzeme pouze ty, kter´e budou pouˇzity v pˇr´ıkladech.
Kapitola 5
ˇ
R´ızen´ı kvality sluˇ
zeb pomoc´ı
klasifikace datov´
ych tok˚
u
Vˇetˇsina souˇcasn´ych ˇreˇsen´ı, kter´e se zab´yvaj´ı zajiˇstˇen´ım kvality sluˇzeb v s´ıt’ov´em prostˇred´ı, jsou zaloˇzena na principu klasifikace jednotliv´ych paket˚u a n´asledn´ym pˇriˇrazov´an´ım r˚uzn´ych priorit. Tato ˇreˇsen´ı pracuj´ı vˇetˇsinou na ´urovni s´ıt’ov´e nebo aplikaˇcn´ı vrstvy.
Pokud je klasifikace paket˚u prov´adˇena na ´urovni s´ıt’ov´e vrstvy, tak jedin´ymi infor-macemi, kter´e slouˇz´ı pro rozˇrazen´ı paket˚u do jednotliv´ych front s definovanou prioritou, pˇr´ıpadnˇe i propustnost´ı, jsou data uloˇzen´a v hlaviˇcce paketu. Jsou to zejm´ena ˇc´ısla port˚u, pˇr´ıpadnˇe IP adresy. Pˇri klasifikaci podle ˇc´ısel port˚u je moˇzn´e ´uspˇeˇsnˇe rozliˇsit pouze omezen´e mnoˇzstv´ı sluˇzeb, kter´e maj´ı sv´e ust´alen´e ˇc´ıslo portu.1 Nˇekter´e typy aplikac´ı ale pouˇz´ıvaj´ı
n´ahodn´a ˇc´ısla port˚u a v tomto pˇr´ıpadˇe je nen´ı moˇzno d´ale rozliˇsit, coˇz m´a vˇetˇsinou za n´asledek to, ˇze skonˇc´ı ve stejn´e tˇr´ıdˇe bez ohledu na to, zda se jedn´a o aplikaci vyˇzaduj´ıc´ı prioritn´ı zpracov´an´ı (napˇr. VoIP) nebo aplikaci, kter´a je z hlediska zajiˇstˇen´ı kvality sluˇzeb neprioritn´ı (napˇr. P2P). M˚uˇze b´yt pouˇzito i pole Type of Service, ale toto ˇreˇsen´ı tak´e nen´ı spolehliv´e, protoˇze velk´e mnoˇzstv´ı aplikac´ı, pˇr´ıpadnˇe i nˇekter´e operaˇcn´ı syst´emy naprosto ignoruj´ı spr´avn´e nastaven´ı tohoto pole v hlaviˇcce paketu. Nav´ıc toto pole m˚uˇze b´yt libo-volnˇe zmˇenˇeno kaˇzd´ym routerem, kter´ym paket proch´az´ı a nikdy nen´ı zaruˇceno, ˇze hodnota zde nastaven´a opravdu odpov´ıd´a poˇzadovan´emu zp˚usobu zpracov´an´ı paketu.
Dalˇs´ı moˇznost´ı, jak klasifikovat pakety, je inspekce paketu na ´urovni aplikaˇcn´ı vrstvy, kdy jsou zkoum´ana pˇren´aˇsen´a data, kter´a jsou porovn´av´ana oproti datab´azi typick´ych ˇretˇezc˚u vyskytuj´ıc´ıch se v datech zn´am´ych sluˇzeb. Toto ˇreˇsen´ı nejen ˇze je pomˇernˇe v´ ypo-ˇ
cetnˇe n´aroˇcn´e, ale uˇz ze sv´eho principu nedok´aˇze spr´avnˇe klasifikovat jak´ykoliv ˇsifrovan´y provoz. Probl´em m˚uˇze nastat taky v pˇr´ıpadˇe, ˇze se objev´ı nˇejak´a nov´a sluˇzba, kter´a nen´ı zahrnuta v datab´az´ı zn´am´ych sluˇzeb a t´ım p´adem mohou b´yt takov´eto nezn´am´e pakety ˇspatnˇe klasifikov´any.
Ani kombinac´ı obou pˇredeˇsl´ych metod nelze ve vˇsech pˇr´ıpadech zajistit spr´avn´e roz-ˇrazen´ı paket˚u a n´asledn´e pˇriˇrazen´ı priorit. Na klasifikaci s´ıt’ov´eho provozu lze ale nahl´ednout i z jin´e strany. M˚uˇzeme upustit od snahy pˇriˇradit kaˇzd´emu paketu prioritu pouze na z´akladˇe informac´ı z´ıskan´ych pouze z dat, kter´a jsme schopni vyˇc´ıst z jeho hlaviˇcky a tˇela. Sledujeme-li s´ıt’ov´y provoz, kter´y jednotliv´e aplikace generuj´ı, tak na z´akladˇe jeho charakteristiky jsme schopni odhadnout, do jak´e skupiny dan´a aplikace patˇr´ı.
Kaˇzd´a aplikace komunikuj´ıc´ı pˇres s´ıt’ vytvoˇr´ı spojen´ı, kter´e je jednoznaˇcnˇe identifiko-vateln´e ˇctveˇric´ı ´udaj˚u: zdrojov´a IP adresa, zdrojov´y port, c´ılov´a IP adresa, c´ılov´y port.
1
Na z´akladˇe tˇechto informac´ı jsme schopni rozˇradit vˇsechny pakety do jednotliv´ych spo-jen´ı a t´ım p´adem pˇresnˇe sledovat charakteristiku datov´eho toku, kter´y generuj´ı. Stˇeˇzejn´ı informac´ı, podle kter´e lze odhadnout o jak´y typ aplikace se jedn´a, je z´avislost rychlosti pˇren´aˇsen´ych dat na ˇcase. Tyto charakteristiky se u nˇekter´ych aplikac´ı mohou dokonce v ˇ
case zmˇenit tak, ˇze interaktivn´ı aplikace pˇrejde do neinteraktivn´ıho m´odu. Pokud tedy jed-notliv´e datov´e toky periodicky sledujeme a klasifikujeme, tak i takovou zmˇenu je moˇzno detekovat a n´aleˇzitˇe se podle toho zachovat pˇriˇrazen´ım jin´e priority. Dalˇs´ı v´yhodou tohoto ˇreˇsen´ı je schopnost spr´avnˇe klasifikovat i ˇsifrovan´y provoz.
Obr´azek 5.1: Interaktivn´ı provoz pˇres SSH
Na obr´azku 5.1 je zn´azornˇena situace, kdy je pˇres SSH vzd´alenˇe spuˇstˇena grafick´a apli-kace, se kterou je n´aslednˇe bˇeˇznˇe pracov´ano. Toto je pˇr´ıklad datov´eho toku, kter´y potˇrebuje vˇetˇs´ı prioritu, aby bylo uˇzivateli co moˇzn´a nejl´epe umoˇznˇeno pracovat s aplikac´ı opravdu interaktivnˇe. Na obr´azku 5.2 je naopak zn´azornˇeno spojen´ı pˇres SSH, kdy po chv´ıli bˇeˇzn´e interaktivn´ı pr´ace, jakou bylo proch´azen´ı adres´aˇr˚u, byl spuˇstˇen pˇrenos velk´eho souboru. Od t´eto chv´ıle spojen´ı pˇrest´av´a m´ıt interaktivn´ı charakter, protoˇze uˇzivatel ˇcek´a na pˇrenesen´ı souboru. Z grafu je jasnˇe patrn´a zmˇena charakteristiky takov´eho datov´eho toku.
Jak bylo uk´az´ano na obr´azku, tak lze i z charakteristiky pˇrenosu dat v jednom smˇeru odvodit o jak´y typ datov´eho toku se jedn´a. M˚uˇzeme ale vyuˇz´ıt skuteˇcnosti, ˇze pro ´uspˇeˇsnou komunikaci je vˇetˇsinou potˇreba pˇren´aˇset data v obou smˇerech. Jedn´a se napˇr´ıklad o potvr-zov´an´ı pˇrijat´ych dat pˇri stahov´an´ı souboru pˇres protokol http nebo ftp. Jsme tedy schopni sestavit graf, na kter´em budou zachyceny charakteristky jak v pˇr´ıchoz´ım, tak v odchoz´ım
Obr´azek 5.2: Neinteraktivn´ı provoz pˇres SSH
smˇeru, ˇc´ımˇz dos´ahneme zv´yˇsen´ı informaˇcn´ı hodnoty takov´eho grafu a zjednoduˇs´ıme klasi-fikaci provozu, kter´y dan´a apliace generuje.
5.1
N´
avrh syst´
emu pro ˇ
r´ızen´ı QoS pomoc´ı anal´
yzy datov´
ych
tok˚
u
Tokem budeme rozumˇet ˇradu po sobˇe jdouc´ıch paket˚u, kter´e se shoduj´ı ve ˇctyˇrech z´akladn´ıch atributech: zdrojov´a IP adresa, zdrojov´y port, c´ılov´a IP adresa, c´ılov´y port. Spojen´ı bude povaˇzov´ano za ukonˇcen´e, pokud ubˇehla pˇredem urˇcen´a doba od pˇrijet´ı posledn´ıho paketu v dan´em spojen´ı, a to jak v pˇr´ıchoz´ım, tak odchoz´ım smˇeru. Abychom mohli analyzovat jednotliv´e datov´e toky na urˇcit´em rozhran´ı (Ethernet), tak mus´ıme z´ıskat vˇsechny pakety pˇres toto zaˇr´ızen´ı proch´azej´ıc´ı. Tuto pr´aci obstar´av´a modul aplikace nazvan´ypacket sniffer. Pˇri anal´yze probl´emu z´ısk´av´an´ı paket˚u se jako nejjednoduˇs´ı, a z´aroveˇn z pohledu syst´emu nejbezpeˇcnˇejˇs´ı ˇreˇsen´ı nab´ız´ı vyuˇz´ıt knihovnu, kter´a bude kop´ırovat pakety proch´azej´ıc´ımi pˇres s´ıt’ov´a rozhran´ı do uˇzivatelsk´eho prostoru samotn´e aplikace. Knihovna by souˇcasnˇe mˇela b´yt multiplatformn´ı, aby bylo umoˇznˇeno portovat aplikaci do prostˇred´ı jin´eho operaˇcn´ıho syst´emu. Tyto poˇzadavky splˇnuje knihovna pcap - Packet Capture library.2 Implementace
t´eto knihovny je dostupn´a pro syst´emy unixov´eho typu (Linux, *BSD syst´emy, Solaris a
dalˇs´ı) a je zn´ama jakolibpcap. Existuje tak´e implementace pro Win32 syst´emy zn´ama jako WinPcap.
Z´ıskan´e pakety je nutno v n´asleduj´ıc´ım modulu analyzovat na z´akladˇe informac´ı obsaˇ ze-n´ych v IP hlaviˇcce a rozˇradit do jednotliv´ych datov´ych tok˚u. Vhodnou datovou strukturou pro ukl´ad´an´ı datov´ych tok˚u se jev´ı kombinace asociativn´ıho pole a kruhov´eho bufferu, kdy v kruhov´em bufferu budou uloˇzeny zachycen´e pakety a kl´ıˇcem do asociativn´eho pole bude struktura jednoznaˇcnˇe identifikuj´ıc´ı jednotliv´e datov´e toky.
Dalˇs´ı modul pracuje nad datovou strukturou obsahuj´ıc´ı jednotliv´e toky a periodicky prov´ad´ı vyhodnocen´ı rychlosti pˇren´aˇsen´ych dat v ˇcase a vytv´aˇr´ıvektor dat obsahuj´ıc´ı in-formace, na jejichˇz z´akladˇe bude provedena klasifikace do jednotliv´ych tˇr´ıd reprezentuj´ıc´ıch typ provozu.
Pro to, abychom mohli urˇcit typ provozu, reprezentovan´y vektorem dat z´ıkan´ym v pˇredchoz´ım modulu je potˇreba se
”pod´ıvat“ na jeho tvar a porovnat jej s empiricky zjiˇstˇ e-n´ymi vektory jednotliv´ych typ˚u a vybrat tˇr´ıdu provozu, kter´e se nejv´ıc podob´a. K tomuto ´
uˇcelu se d´a s v´yhodou vyuˇz´ıt moˇznost´ı neuronov´ych s´ıt´ı a jejich schopnosti nauˇcit se podle tr´enovac´ı mnoˇziny vzork˚u rozpozn´avat vzorky jim podobn´e.
Samotn´emu v´ybˇeru implementace neuronov´e s´ıtˇe pˇredch´azelo prozkoum´an´ı moˇznost´ı a v´ykonnosti r˚uzn´ych knihoven poskytuj´ıc´ıch rozhran´ı pro pr´aci s neuronov´ymi s´ıtˇemi. Nejd˚uleˇzitˇejˇs´ımi krit´erii pro v´ybˇer vhodn´e implementace byly pˇredevˇs´ım:
Otevˇren´y zdrojov´y k´od - Svobodn´a licence knihovny nejen ˇze umoˇzˇnujˇe integraci s dal-ˇs´ımi open source knihovnami, ale zaruˇcuje tak´e moˇznost pˇr´ıpadn´eho rozˇsiˇrov´an´ı jejich funkc´ı a podrobn´e studium problematiky neuronov´ych s´ıt´ı. Dostupnost zdrojov´eho k´odu tak´e umoˇzˇnuje experimentov´an´ı a dalˇs´ı v´yzkum na akademick´e ´urovni.
Multiplatformnost - Moˇznosti pouˇzit´ı softwaru v´yraznˇe rostou, je-li moˇzno jej zkompi-lovat a provozovat na r˚uzn´ych hardwarov´ych platform´ach a pod r˚uzn´ymi operaˇcn´ımi syst´emy.
Vazby na r˚uzn´e programovac´ı jazyky - V pˇr´ıpadˇe dalˇs´ıho rozdˇelen´ı funkc´ı programu do na sobˇe nez´avisl´ych ˇc´ast´ı, kter´e mezi sebou komunikuj´ı nen´ı nutn´e pouˇz´ıvat pouze jeden programovac´ı jazyk. Moˇznost vyuˇz´ıt knihovny ve spojen´ı s jin´ymi programo-vac´ımi jazyky m˚uˇze pˇrin´est zjednoduˇsen´ı pˇri v´yvoji dalˇs´ıch rozˇs´ıˇren´ı programu, nebo pˇri jeho integraci do jin´eho jiˇz existuj´ıc´ıho syst´emu.
Rychlost a efektivnost - Knihovna by mˇela poskytovat nejen velikou m´ıru abstrakce pro koncov´eho uˇzivatele, ale mˇela by souˇcasnˇe pouˇz´ıvat vysoce v´ykonn´ych algoritm˚u, ˇc´ımˇz bude vyuˇziteln´a pro ˇsirokou ˇsk´alu aplikac´ı a architektur.
V´yˇse zm´ınˇen´e poˇzadavky dobˇre splˇnuje knihovna Fast Artificial Neural Network Library (FANN).3 S pomoc´ı t´eto knihovny bude sestavena plnˇe propojen´a dopˇredn´a neuronov´a s´ıt’ s jednou skrytou vrstvou. Poˇcet vstupn´ıch neuron˚u se bude rovnat velikosti klasifikovan´eho vektoru a poˇcet v´ystupn´ıch neuron˚u bude ud´avat poˇcet tˇr´ıd, do kter´ych bude neuronov´a s´ıt’ rozdˇelovat datov´e toky.
Rozpoznan´y typ a popis datov´eho pˇrenosu jsou vstupem pro dalˇs´ı modul, kter´y pomoc´ı paketov´eho filtru iptables nastav´ı pˇr´ısluˇsnou prioritu tok˚um dat v pˇr´ıchoz´ım i odchoz´ım smˇeru spojen´ı. Zde jiˇz nen´ı jin´a moˇznost, neˇz pouˇzit´ı syst´emovˇe z´avisl´e implementace, protoˇze v souˇcasnosti neexistuje a ani nejsp´ıˇse nebude existovat jednotn´e rozhran´ı nebo
3
n´astroj, kter´y umoˇzn´ı nastaven´ı parametr˚u j´adra pro zpracov´av´an´ı paket˚u. Tento modul je ovˇsem navrˇzen tak, ˇze d´ıky pouˇzit´ı uˇzivatelsk´eho rozhran´ı iptables nen´ı jeho implementace nijak sloˇzit´a a portace modulu by znamenala jej pozmˇenit tak, aby vyuˇz´ıval jin´eho programu (napˇr´ıklad pf pro OpenBSD a FreeBSD).
Posledn´ı a tak´e syst´emovˇe z´avislou ˇc´ast´ı syst´emu je skript, kter´y nad s´ıt’ov´ym roz-hran´ım definuje pevnˇe dan´e sch´ema ˇrad´ıc´ıch discipl´ın. Tento skript nastav´ı parametry j´adra operaˇcn´ıho syst´emu, kter´y potom bude ˇradit pakety do prioritn´ıch front na z´akladˇe in-formace vloˇzen´e do paketu pomoc´ı programu iptables. V linuxu k tomuto ´uˇcelu existuje uˇzivatelsk´y n´astrojtc. V *BSD syst´emech se ke stejn´emu ´uˇcelu pouˇz´ıv´a napˇr´ıklad n´astroje altq. Pokud bychom chtˇeli portovat syst´em pod jin´y operaˇcn´ı syst´em, tak je nutn´e pˇrepsat tento skript tak, aby vyuˇz´ıval n´astroje v tomto syst´emu dostupn´e.
