Na tomto míst¥ bude ociální zadání va²í práce •
Toto zadání je podepsané d¥kanem a vedoucím katedry,
•
musíte si ho vyzvednout na studiijním odd¥lení Katedry po£íta£· na Karlov¥ nám¥stí,
•
v jedné odevzdané práci bude originál tohoto zadání (originál z·stává po obhajob¥ na kated°e),
•
ve druhé bude na stejném míst¥ neov¥°ená kopie tohoto dokumentu (tato se vám vrátí po obhajob¥).
i
ii
eské vysoké u£ení technické v Praze Fakulta elektrotechnická Katedra po£íta£·
Diplomová práce
Omezova£ datového toku Bc. Václav My²ka
Vedoucí práce:
Ing. Jan Kubr
Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský
Obor: Výpo£etní technika
31. prosince 2011
iv
v
Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn¥ a pouºil jsem pouze podklady uvedené v p°iloºeném seznamu. Nemám závaºný d·vod proti uºití tohoto ²kolního díla ve smyslu 60 Zákona £. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm¥n¥ n¥kterých zákon· (autorský zákon).
V Ba²ti dne 6. 12. 2011
.............................................................
vi
Abstract This thesis deals with analysis and implementation of a system that allows simulation of computer network on an another type. The objective is to create a system for a group of developers who debugs network applications under laboratory conditions, but these applications assume running in a network with worse properties (such as GSM). It is essential that the developer, who debugs the application for example on a mobile phone or own PC, could limit bandwidth, delay and jitter to this application. This limitation must not limit the developer at other work that shouldn't be restricted. The possibility of setting variable properties for a network according to a predened scenario is also desired.
Abstrakt Tato práce se zabývá návrhem a implementací systému, který umoº¬uje simulaci sít¥ na jiném typu sít¥. Cílem je vytvo°it systém pro skupinu vývojá°·, kte°í ladí sí´ové aplikace v laboratorních podmínkách, ale tyto aplikace p°edpokládají b¥h v síti s hor²ími vlastnostmi (nap°íklad GSM). Podstatné je, aby vývojá°, který ladí aplikaci nap°íklad na mobilním telefonu nebo vlastním PC, mohl této aplikaci nastavit zejména omezenou ²í°ku pásma, zpoºd¥ní a jitter. Toto omezení zárove¬ nesmí omezovat vývojá°e p°i ostatní práci. ádoucí je také moºnost nastavit prom¥nlivé vlastnosti sít¥ podle p°edem denovaného scéná°e.
vii
viii
Obsah 1 Úvod
1
2 Popis problému, specikace cíle
3
2.1
Poºadavky na cílový systém . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Zp·soby simulace parametr· sít¥
. . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.1
Omezení ²í°ky pásma . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
2.2.2
Zvý²ení zpoºd¥ní . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.3
Zavedení ztrátovosti
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2.4
Po²kozování packet·
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.5
Doru£ování duplicit . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.2.6
Zm¥na po°adí packet· . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
Existující nástroje pro zm¥nu parametr· sítí . . . . . . . . . . . . . . . . . . .
6
2.3
2.3.1
TBF Token Bucket Filter
. . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.2
SFQ Stochastic Fairness Queuing . . . . . . . . . . . . . . . . . . . .
6
2.3.3
WFQ Weighted Fairness Queuing . . . . . . . . . . . . . . . . . . . .
6
2.3.4
CBQ Class Based Queueing . . . . . . . . . . . . . . . . . . . . . . .
6
2.3.5
HTB Hierarchical Token Bucket
. . . . . . . . . . . . . . . . . . . .
7
2.3.6
Netem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.7
Wondershaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.8
NIST Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.9
NetLimiter
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.10 Squid-cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
2.3.11 MasterShaper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8
2.3.12 Dummynet
8
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 Analýza a návrh °e²ení 3.1
Umíst¥ní simulátoru
11 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.1
Simulátor na klientské stanici . . . . . . . . . . . . . . . . . . . . . . .
11
3.1.2
Simulátor na serveru . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1.3
Simulátor na routeru . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.1.4
Simulátor na vloºeném PC . . . . . . . . . . . . . . . . . . . . . . . . .
13
3.1.5
Simulátor na proxy serveru
3.1.6
Volba vhodného umíst¥ní
. . . . . . . . . . . . . . . . . . . . . . . .
14
. . . . . . . . . . . . . . . . . . . . . . . . .
15
3.2
Volba platformy a opera£ního systému
3.3
Výb¥r vhodných nástroj· pro nastavení parametr·
ix
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15 16
x
OBSAH
3.4
Návrh aplikace
3.5
Volba implementa£ního prost°edí
3.6
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.5.1
Opera£ní £ást . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
3.5.2
Kongurátor
3.5.3
Scéná°e
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
Zp·sob uloºení nastavení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
4 Realizace 4.1
4.2
4.3
16
. . . . . . . . . . . . . . . . . . . . . . . . .
19
Problémy p°i °e²ení pomocí proxy serveru
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . .
19
4.1.1
Trac shaping v proxy serveru
4.1.2
Zna£kování packet· v proxy serveru
. . . . . . . . . . . . . . . . . . .
20
19
4.1.3
Vlastní lter pro dekódování pravidel . . . . . . . . . . . . . . . . . . .
20
4.1.4
Trac shaping p°íchozího provozu
. . . . . . . . . . . . . . . . . . . .
20
Routování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
20
4.2.1
Nastavení jednotlivých rozhraní . . . . . . . . . . . . . . . . . . . . . .
20
4.2.2
IP forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.2.3
NAT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
Trac control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
4.3.1
HTB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.3.2
Netem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
22
4.3.3
Návrh hierarchie
22
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.4
P°id¥lení pravidel ke konkrétnímu datovému toku . . . . . . . . . . . . . . . .
23
4.5
Rozli²ení tok· uploadu p°i pouºití NAT
. . . . . . . . . . . . . . . . . . . . .
23
4.6
P°ístup k databázi z limnet skriptu . . . . . . . . . . . . . . . . . . . . . . . .
24
4.7
Popis implementace limnet skriptu
4.8
. . . . . . . . . . . . . . . . . . . . . . . .
24
4.7.1
Spu²t¥ní systému . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
4.7.2
Správa pravidel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.7.3
Scéná°e
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.7.4
Nastavení sít¥ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
25
4.7.5
Jednotky veli£in uvád¥ných v parametrech . . . . . . . . . . . . . . . .
25
Vývoj webové aplikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.8.1
Rules Pravidla
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.8.2
Scenarios Scéná°e . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.8.3
Router . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
31
4.8.4
Gracké práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
5 Testování
37
5.1
Testování ²í°ky pásma
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.2
Testování zpoºd¥ní a jitteru . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
5.3
Testování ztrátovosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
5.4
Zapojení testovací sít¥
38
5.5
Navrºení testovacích úloh
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.5.1
Zm¥°ení parametr· sít¥ bez omezova£e . . . . . . . . . . . . . . . . . .
39
5.5.2
M¥°ení ²í°ky pásma . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
5.5.3
M¥°ení ztrátovosti a zpoºd¥ní . . . . . . . . . . . . . . . . . . . . . . .
40
5.5.4
M¥°ení ostatních parametr· . . . . . . . . . . . . . . . . . . . . . . . .
40
xi
OBSAH
5.5.5 5.6
Testování scéná°· . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Nam¥°ené hodnoty a vyhodnocení výsledk·
40
. . . . . . . . . . . . . . . . . . .
40
5.6.1
Parametry testovací sít¥ . . . . . . . . . . . . . . . . . . . . . . . . . .
40
5.6.2
Nam¥°ené hodnoty s omezova£em . . . . . . . . . . . . . . . . . . . . .
41
5.6.3
Ov¥°ení vedlej²ích parametr·
. . . . . . . . . . . . . . . . . . . . . . .
42
5.6.4
Ov¥°ení funk£nosti scéná°·
. . . . . . . . . . . . . . . . . . . . . . . .
42
6 Záv¥r
43
6.1
Spln¥ní cíl·
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
6.2
Doporu£ení pro nastavení sít¥ . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
6.3
Zabezpe£ení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
6.4
Moºný rozvoj systému
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
44
6.5
Zapojení bez zm¥ny infrastruktury sít¥ . . . . . . . . . . . . . . . . . . . . . .
44
A Seznam pouºitých zkratek
47
B Instala£ní a uºivatelská p°íru£ka
49
B.1
B.2
Instala£ní p°íru£ka
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
B.1.1
Poºadavky na systém
. . . . . . . . . . . . . . . . . . . . . . . . . . .
49
B.1.2
Zkopírujte data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
B.1.3
Nastavení sít¥ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
B.1.4
Vytvo°te databázi v MySQL . . . . . . . . . . . . . . . . . . . . . . . .
49
B.1.5
Vytvo°te konguraci webserveru . . . . . . . . . . . . . . . . . . . . . .
50
B.1.6
Sudoers záznam pro limnet
B.1.7
Kongurace limnetu
B.1.8
Uloºení nastavení sít¥ do databáze
B.1.9
Automatické spu²t¥ní systému
. . . . . . . . . . . . . . . . . . . . . . . .
50
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
50
. . . . . . . . . . . . . . . . . . . .
50
. . . . . . . . . . . . . . . . . . . . . .
50
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
51
B.2.1
Ovládání z p°íkazového °ádku . . . . . . . . . . . . . . . . . . . . . . .
51
B.2.2
Ovládání p°es webové rozhraní
53
Uºivatelská p°íru£ka
C Obsah p°iloºeného CD
. . . . . . . . . . . . . . . . . . . . . .
55
xii
OBSAH
Seznam obrázk· 2.1
Schéma algoritmu Token Bucket . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.2
Schéma algoritmu Leaky Bucket . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.3
Ukázka s vysv¥tlením GUI Xnistnet . . . . . . . . . . . . . . . . . . . . . . . .
8
2.4
Ukázka GUI programu NetLimiter
2.5
Graf z aplikace MasterShaper
3.1
Umíst¥ní limiteru na klientu . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
3.2
Umíst¥ní limiteru na serveru . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
3.3
Umíst¥ní limiteru na routeru
3.4
Umíst¥ní limiteru na vloºeném PC v klientské £ásti sít¥
. . . . . . . . . . . .
14
3.5
Umíst¥ní limiteru na vloºeném PC v serverové £ásti sít¥
. . . . . . . . . . . .
14
3.6
Umíst¥ní limiteru na proxy serveru . . . . . . . . . . . . . . . . . . . . . . . .
14
4.1
Screenshot Seznam pravidel . . . . . . . . . . . . . . . . . . . . . . . . . . .
26
4.2
Screenshot P°idání nového pravidla . . . . . . . . . . . . . . . . . . . . . . .
27
4.3
Screenshot Výb¥r scéná°e ke spu²t¥ní . . . . . . . . . . . . . . . . . . . . . .
28
4.4
Screenshot B¥ºící scéná° . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
29
4.5
Screenshot Seznam scéná°· k editaci . . . . . . . . . . . . . . . . . . . . . .
30
4.6
Screenshot Detail scéná°e
33
4.7
Screenshot Editace pravidla scéná°e
4.8
Screenshot P°idání prázdného scéná°e
4.9
Screenshot Formulá° pro import scéná°e z CSV souboru
. . . . . . . . . . . . . . . . . . . . . . . .
9
. . . . . . . . . . . . . . . . . . . . . . . . . . .
9
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
13
. . . . . . . . . . . . . . . . . . . . . .
34
. . . . . . . . . . . . . . . . . . . . .
35
. . . . . . . . . . .
35
. . . . . . . . . . . . . . . . . . . .
36
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
4.10 Screenshot Nastavení adres sít¥ routeru 5.1
Zapojení testovací sít¥
C.1
Obsah p°iloºeného CD 1. £ást
. . . . . . . . . . . . . . . . . . . . . . . . .
55
C.2
Obsah p°iloºeného CD 2. £ást
. . . . . . . . . . . . . . . . . . . . . . . . .
56
xiii
xiv
SEZNAM OBRÁZK
Seznam tabulek 5.1
Parametry testovací sít¥
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2
Nastavené parametry test·
5.3
Nam¥°ené parametry v testech
. . . . . . . . . . . . . . . . . . . . . . . . . .
41
5.4
Korigované výsledky m¥°ení . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
xv
40 41
xvi
SEZNAM TABULEK
Kapitola 1
Úvod Vývoj aplikací p°iná²í °adu problém·, které p°i vývoji nejsou na první pohled z°etelné. Nasazením aplikace do reálného provozu pak vycházejí napovrch hlediska, která byla p°i vývoji opomenuta, nebo´ vývoj probíhal v laboratorních podmínkách. Sí´ové aplikace bývají £asto zatíºeny problémy sítí, ve kterých jsou provozovány. Tyto sít¥ vykazují odli²né parametry, neº lokální sít¥, které bývají v¥t²inou vyuºívány k vývoji. Z t¥chto d·vod· vzniká pot°eba lad¥ní a testování aplikace v reáln¥ síti, která nemusí být vºdy k dispozici. Toto lze °e²it simulací. Na rychlé kvalitní síti beze ztrát je vºdy moºné simulovat chování sítí s ho²ími parametry. Typický a v praxi nej£ast¥j²í p°íklad je simulace sít¥ GSM na lokální síti Ethernet. Vývojá° a tester sí´ové aplikace tedy pot°ebuje k dispozici simulátor sít¥, u kterého nastaví chování pro testovanou aplikaci a dále m·ºe p°edpokládat, ºe pracuje na reálné síti, ve které by aplikace m¥la být nasazena. Navíc jednotlivé parametry sítí se mohou v £ase m¥nit, coº je m·ºe být zapot°ebí promítnout do testování. Základními parametry, které je zapot°ebí nastavovat, £asto zárove¬, jsou, jak vyplívá i ze zadání, ²í°ka pásma, zpoºd¥ní a ztrátovost. Existují i dal²í, které se mohou hodit v mén¥ £astých p°ípadech. Jsou to nap°íklad vytvá°ení duplicitních packet·, po²kozených packet· nebo zm¥na jejich po°adí. Existuje jiº spousta nástroj·, které umoº¬ují upravovat r·zné parametry sítí, av²ak tyto nástroje bu¤ neumí nastavovat v²echny pot°ebné parametry, p°ípadn¥ mají velmi sloºité nastavování, coº by v p°ípad¥ jejich pouºití zna£n¥ zpomalovalo vývoj. Totéº platí i p°i pouºití nástroj· s jednoduchým nastavením, které v²ak neumí nastavovat v²echny parametry a tudíº je pot°eba jich kombinovat n¥kolik. Mnohem v¥t²í zpomalení vývoje by v²ak znamenalo m¥nit ru£n¥ nastavení parametr· v £ase b¥hem testování. To je p°inejmen²ím velmi sloºité, ne-li v n¥kterých p°ípadech aº nemoºné. Tato práce si klade za úkol vytvo°it systém, který umoº¬uje poskytnout vývojá°·m nástroj, který obslouºí v²echny jejich poºadavky pro nastavení parametr· sítí a zárove¬ bude mít k dispozici i jednoduché nastavení. Musí dokázat vytvo°it základní statické nastavení pro testování, ale musí um¥t i m¥nit parametry sít¥ v £ase podle p°edem denovaného scéná°e. K tomu musí existovat nástroj pro centrální správu pravidel, nebo´ developer m·ºe nap°íklad ladit aplikaci na mobilním za°ízení, zatímco nastavení chce provád¥t na PC. Nástroj, který bude vytvo°en jako cíl této práce, bude pojmenován Limnet.
1
2
KAPITOLA 1.
ÚVOD
Kapitola 2 rozebírá problematiku a uvádí cíle, kterých se tato práce snaºí dosáhnout. Jsou zde uvedeny poºadavky na systém a je zde rozebráno, jak t¥chto poºadavk· dosáhnout. Kapitola 3 analyzuje r·zné zp·soby °e²ení a navrhuje, jak konkrétn¥ bude °e²ení implementováno, volí vhodné postupy a popisuje jejich pozitiva i negativa. Kapitola 4 popisuje zvolené °e²ení z implementa£ní stránky. Uvádí jak byl systém navrºen, jeho rozd¥lení, ale i nav°ºení uºivatelského prost°edí. Kapitola 5 se zabývá ov¥°ením funk£nosti systému, m¥°ením vlastností simulované sít¥ a zhodnocením výsledk· m¥°ení. Sou£ástí této práce je také p°iloºené CD (vlepené k zadním deskám), které obsahuje aplikaci, v²echny její pot°ebné soubory, zdrojové soubory (nap°íklad ke grackým soubor·m), testovací soubory a tento dokument v elektronické podob¥.
Kapitola 2
Popis problému, specikace cíle Jak jiº bylo vý²e uvedeno, cílem této práce je vytvo°it systém, který umoºní skupin¥ vývojá°· ladit a testovat sí´ové aplikace v jejich produk£ním prost°edí. Kaºdý vývojá° musí být schopen nastavit pro svou aplikaci omezení tak, aby neomezoval svou ostatní práci se sítí a zárove¬ ani ºádného ze svých koleg·. Tato omezení mohou být statická (po celou dobu stejná) nebo dynamická, kdy se bude nastavení v £ase automaticky m¥nit podle p°edem denovaného scéná°e. Nastavení systému m·ºe nastavovat kaºdý developer na svém PC.
2.1 Poºadavky na cílový systém •
Omezení ²írky pásma Musí jít nastavit rychlost p°enosu dat, zvlá²´ pro download a zvlá²´ pro upload.
•
Nastavení zpoºd¥ní Packet bude v systému pozdrºen po uvedenou dobu, neº bude p°eposlán dále.
•
Nastavení jitteru Jitter je tolerance zpoºd¥ní, nebo´ zpoºd¥ní zpravidla nebývá konstantní.
•
Zavedení ztrátovosti N¥které sít¥ mají niº²í spolehlivost a dochází u nich ke zvý²enému po£tu výpadk· packet·.
•
Statické nastavení parametr·
•
Dynamické nastavení parametr· podle scéná°· V síti se bude automaticky m¥nit nastavení parametr· podle p°edem denovaného postupu.
•
Centrální správa Musí být moºné nastavit parametry pro datový tok jednoho za°ízení z jiného za°ízení.
3
4
KAPITOLA 2.
•
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Transparentnost z pohledu vývojá°e Sí´ se pro danou aplikaci musí tvá°it jako skute£ná sí´, která je simulována, aniº by se muselo provád¥t n¥jaké dal²í nastavení.
•
Snadný zp·sob pouºívání Vývojá° musí mít moºnost provád¥t nastavení parametr· jednoduchým zp·sobem pomocí grackého rozhraní.
•
Nízká cena
•
Nezávislost na OS Aplikace se vyvíjejí pro r·zné opera£ní systémy, takºe závislost na OS je rozhodn¥ neºádoucí.
•
Otev°ený systém V systému musí být moºné °e²it budoucí nedostatky, proto by to m¥l být open-source.
2.2 Zp·soby simulace parametr· sít¥ 2.2.1
Omezení ²í°ky pásma
Abychom dosáhli sníºení rychlosti, musíme kontrolovat mnoºství procházejících dat. Na vstup limiteru p°icházejí data ve form¥ packet·, ale na výstup m·ºeme pustit jen jejich omezené mnoºství tak, aby výstupní rychlost odpovídala nastavené. Na to existují r·zné algoritmy, nap°íklad Token Bucket nebo Leaky Bucket. Nej£ast¥ji pouºívaným algoritmem je práv¥ Token Bucket. Ten funguje tak, ºe máme zásobník na tokeny s omezenou velikostí. Ten plníme rychlostí r token· za sekundu, kde r je vypo£ítaná konstanta ur£ující výslednou rychlost, neboli rychlost omezení. Pokud je zásobník plný, vygenerované tokeny zahazujeme. Packet pak p°epo²leme ze vstupu na výstup pouze, kdyº máme v zásobníku token. Ten je pak samoz°ejm¥ p°i p°eposlání packetu ze zásobníku vy°azen. Packety jsou na vstupu °azeny do fronty a pokud dojde k vy£erpání její kapacity z d·vodu nedostatku token· (neboli p°íchozí provoz je vy²²í, neº jsme s daným omezením schopni odbavit a dojde k napln¥ní vstupní fronty), následující p°íchozí packety jsou zahazovány. Schéma tototo algoritmu je znázorn¥no na obrázku 2.1. Tento algoritmus se vyzna£uje vlastností, ºe pokud jsme p°id¥lenou ²í°ku pásma po n¥jakou dobu nevyºívali, je v zásobníku token· dostatek token·, m·ºe odchozí provoz chvilkov¥ p°ekro£it p°id¥lenou ²í°ku pásma, a to po dobu, neº dojde k vy£erpání akumulovaných token·. Oproti tomu algoritmus Leaky Bucket ºádné p°ekro£ení rychlosti netoleruje. P°íchozí packety jsou op¥t °azeny do fronty, ale odebírány jsou vºdy pouze rychlostí r packet· za sekundu. To si lze p°edstavit jako d¥ravé v¥dro, ze kterého packety odchází omezenou rychlostí dle velikosti otvoru. Podle toho získal také algoritmus své jméno. Jeho schéma je zobrazeno na obrázku 2.2.
2.2.
5
ZPSOBY SIMULACE PARAMETR SÍT
tokens
bucket
incoming packets
outgoing packets
Obrázek 2.1: Schéma algoritmu Token Bucket
incoming packets
bucket outgoing packets
Obrázek 2.2: Schéma algoritmu Leaky Bucket
2.2.2
Zvý²ení zpoºd¥ní
Do cesty sí´ového provozu je vloºena fronta, do které jsou vkládány packety spole£n¥ s £asovými zna£kami, kdy packety sm¥jí frontu opustit. P°i vkládání packetu do fronty se nastavuje výstupní £as bu¤to prostým p°i£tením konstanty d k aktuálnímu £asu, p°i simulaci reáln¥j²ího chování se tato konstanta je²t¥ výsledný £as t upravuje o náhodnou hodnotu vycházející z jitteru j podle vztahu
t = d + random(j ∗ 2) − j . Pro funkci random je vhodné
volit normální rozloºení. Navíc muºeme zavést korelaci podle zpoºd¥ní p°edchozího packetu. To vede ke zvý²ení reálnosti simulace. Ur£ení vysokého jitteru m·ºe pak vést ke zm¥n¥ po°adí n¥kterých packet·.
2.2.3
Zavedení ztrátovosti
Pro zavedení ztrátovosti sta£í zahazovat packety (nep°eposílat na výstup) s ur£itou pravd¥podobností. Abychom zajistili reáln¥j²í chování, m·ºeme korelovat pravd¥podobnost s pravd¥podobností ztráty p°edcházejícího packetu.
6
2.2.4
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Po²kozování packet·
Nastavíme-li pravd¥podobnost po²kození packetu, sta£í u kaºdého packetu s touto pravd¥podobností p°epnout náhodn¥ 1 nebo více bit·, pokud v²ak neladíme aplikaci vyuºívající samoopravné kódovaní, není ºádný rozdíl, pokud po²kodíme jeden nebo více bit·. Proto v¥t²inou sta£í po²kodit jeden bit.
2.2.5
Doru£ování duplicit
P°i vkládání packetu do fronty s ur£enou pravd¥podobností vloºíme tento packet do fronty dvakrát.
2.2.6
Zm¥na po°adí packet·
Abychom byli schopni docílit zm¥ny po°adí packet· p°i simulaci, sta£í n¥kterým packet·m zvý²it zpoºd¥ní tak, aby daný packet ode²el pozd¥ji, neº packet následující. K docílení zm¥ny po°adí packet· tedy sta£í stejný postup jako ke zvý²ení zpoºd¥ní. Packety, které budeme odesílat aº po následujícím packetu, m·ºeme vybírat bu¤to systematicky, abychom dokázali následn¥ p°edvídat chování p°i lad¥ní aplikace, nebo náhodn¥ s ur£itou pravd¥podobností obdobn¥ jako u ztrátovosti. Stejn¥ tak jako u ztrátovosti m·ºeme zde zavést korelaci.
2.3 Existující nástroje pro zm¥nu parametr· sítí 2.3.1
TBF Token Bucket Filter
Tbf [8] je jednoduchý ltr umoº¬ující tvarování provozu algoritmem Token Bucket. Umoº¬uje omezení ²í°ky pásma. Je sou£ástí jádra GNU/Linux. Nastavuje se prost°ednictvím p°íkazové °ádky.
2.3.2
SFQ Stochastic Fairness Queuing
Sfq [8] je plánova£ datových tok·, který cyklicky obsluhuje fronty. Umoº¬uje omezení ²í°ky pásma a slouºí zejména k férovému rozd¥lování ²í°ky pásma mezi více klient·. Je sou£ástí jádra GNU/Linux. Jeho kongurace je moºná z p°íkazové °ádky.
2.3.3
WFQ Weighted Fairness Queuing
Wfq je obdoba SFQ, ale jednotlivé fronty jsou priorizovány a podle této priority jsou £ast¥ji nebo mén¥ £asto obsluhovány.
2.3.4
CBQ Class Based Queueing
Cbq je tvarova£, který roz°azuje sí´ový provoz do p°edem denovaných t°íd s r·znými parametry. Tyto jsou strukturovány v hierarchickém stromovém uspo°ádání. Umoº¬uje sdílení linky s férovým p°id¥lováním ²í°ky pásma. Je sou£ástí jádra GNU/Linux. Jeho nastavení se op¥t provádí z p°íkazové °ádky.
2.3.
EXISTUJÍCÍ NÁSTROJE PRO ZM
NU PARAMETR SÍTÍ
2.3.5
7
HTB Hierarchical Token Bucket
Htb [1] je tvarova£, který vylep²uje CBQ, ale poskytuje vy²²í výkon. Je vhodný k omezování ²í°ky pásma. Je sou£ástí jádra GNU/Linux. Jedná se o dal²í ltr, který se konguruje z p°íkazové °ádky.
2.3.6
Netem
Netem [3] je sí´ový emulátor. Umoº¬uje nastavení °ady parametr·: zpoºd¥ní, jitter, ztrátovost, duplikování, po²kozování a zm¥na po°adí packet·. Navíc u kaºdého z nich nabízí roz²í°enou konguraci (zejména korelaci daného parametru), aby bylo chování sít¥ emulováno mnohem reáln¥ji. Je sou£ástí jádra GNU/Linux. Tento ltr se také konguruje z p°íkazové °ádky.
2.3.7
Wondershaper
Wondershaper [7] je skript, který umoº¬uje v linuxu nastavit omezení rychlosti (upload, download) pro daný interface (sí´ové rozhraní). Tento skript velmi zjednodu²uje konguraci SFQ. Taktéº se ovládá z p°íkazové °ádky.
2.3.8
NIST Net
NIST Net [5] je linuxový sí´ový emulátor, který umoº¬uje omezení ²í°ky pásma, zpoºd¥ní a ztrátovosti. Tento program navíc podporuje scéna°e pro zm¥nu parametr·. Jedná se o pom¥rn¥ propracovaný nástroj, který je v²ak bohuºel zatím pouze v experimentálním stádiu vývoje a nelze tak zaru£it, ºe bude vºdy °ádn¥ fungovat. Poskytuje rozhraní pro nastavení z p°íkazového °ádku nebo z gracké aplikace. Ukázka a vysv¥tlení GUI jménem Xnistnet je vid¥t na obrázku 2.3.
2.3.9
NetLimiter
NetLimiter [4] je komplexní komer£ní software pro Microsoft Windows. Umoº¬uje omezení ²í°ky pásma zvlá²´ pro kaºdou aplikaci, monitoring sít¥, statistiky, vzdálené ovladání a dal²í. Je nasazen na po£íta£i, na kterém chceme omezovat provoz. Není s ním tedy moºné omezovat toky nap°íklad na mobilních za°ízeních. Program má gracké rozhraní, které je zobrazeno na obrázku 2.4.
2.3.10
Squid-cache
Squid-cache [6] je velmi kvalitní proxy server pro linux, který umoº¬uje omezení ²í°ky pásma pro download pomocí Delay pools. Jeho kongurace je provád¥na prost°ednictvím kongura£ních soubor·. Tento program je open-source.
8
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Obrázek 2.3: Ukázka s vysv¥tlením GUI Xnistnet
2.3.11
MasterShaper
MasterShaper [2] je nástavba pro linux, která umoº¬uje snadno kongurovat pravidla pro omezování ²í°ky pásma pomocí vý²e uvedených ltr· v jád°e linuxu. Nastavení je zprost°edkováno p°es webové rozhraní. Tato aplikace také umí vykreslit grafy s aktuálním vyuºitím ²í°ky pásma a jejím rozloºení. Graf vyºití ²írky pásma je na obrázku 2.5.
2.3.12
Dummynet
Dummynet [9] je velmi pokro£ilý multiplatformní nástroj, p·vodn¥ vyvíjený pro systém BSD, který umoº¬uje omezování ²í°ky pásma, nastavení zpoºd¥ní a ztrátovosti, ale i p°ehazování po°adí packet·. Je ur£en pro b¥h na klientských stanicích nebo routerech. Jeho ovládání je prost°ednictvím p°íkazové °ádky.
2.3.
EXISTUJÍCÍ NÁSTROJE PRO ZM
NU PARAMETR SÍTÍ
Obrázek 2.4: Ukázka GUI programu NetLimiter
Obrázek 2.5: Graf z aplikace MasterShaper
9
10
KAPITOLA 2.
POPIS PROBLÉMU, SPECIFIKACE CÍLE
Kapitola 3
Analýza a návrh °e²ení Jsou dv¥ základní moºnosti, jak tento problém °e²it. První z nich je, ºe m·ºeme navrhnout a vyvinout zcela nový program, coº p°iná²í sloºitou práci na úlohách, které jsou jiº vy°e²eny a vylad¥ny, místo toho bychom vytvo°ili systém, u kterého by se znovu °e²ily stejné problémy, které uº jsou dávno vy°e²eny. Místo toho m·ºeme pouºít jiº existující nástroje, jimº vymyslíme vhodný zp·sob kongurace a pouºití.
3.1 Umíst¥ní simulátoru Je t°eba zvolit, kde bude sytém nasazen a z toho zárove¬ plyne i to, jak bude pouºíván. Zde tedy budou rozebrány jednotlivé varianty a ke kaºdé bude uvedeno, jaké jsou její výhody a nevýhody.
3.1.1
Simulátor na klientské stanici
Simulátor lze umístit na klientskou stanici. Toto °e²ení poskytuje jednoduché nastavení pro r·zné vývojá°e. Dále nep°iná²í ºádné dal²í náklady na hardware, ale je závislé na OS vývojá°e, který v¥t²inou pouºívá Microsoft Windows, nelze ud¥lat jednodu²e centrální správu a problémem m·ºe být i instalace na v²echny pracovní stanice, p°ípadn¥ pak na dal²í za°ízení (jako jsou mobilní telefony). Tento zp·sob °e²ení je znázorn¥n na obrázku 3.1.
Obrázek 3.1: Umíst¥ní limiteru na klientu
11
12
KAPITOLA 3.
•
jednoduché nastavení pro vývojá°e
•
snadné odd¥lení tok· jednotlivých vývojá°·
•
nízká cena
•
závislé na OS
•
problémová centrální správa
3.1.2
ANALÝZA A NÁVRH EENÍ
Simulátor na serveru
Umíst¥ní simulátoru na server je dal²í °e²ení, které nevyºaduje ºadné dal²í náklady na po°ízení HW. Toto °e²ení je nezávislé na OS a umoº¬uje snadnou centrální správu. Problém m·ºe být rozli²ení jednotlivých datových tok·, pokud sí´ s pracovními stanicemi vývojá°· bude umíst¥na za routerem s NAT. Dal²í problémy mohou být, ºe vývojá° m·ºe chtít pracovat s r·znými servery, takºe omezova£ bude muset být nainstalován na v²ech, coº zvý²í sloºitost centrální správy. Navíc ne vºdy musíme mít p°ístup k serveru, se kterým se snaºíme komunikovat a pak je toto °e²ení zcela nepouºitelné. Umíst¥ní simulátoru na server ukazuje obrázek 3.2.
Obrázek 3.2: Umíst¥ní limiteru na serveru
•
snadná centrální správa
•
nízká cena
•
problém s identikací zdrojové pracovní stanice
•
problém p°i práci s více servery
•
nepouºitelné, pokud nemáme p°ístup k serveru
3.1.3
Simulátor na routeru
Pro toto °e²ení musíme mít v síti mezi klientskou stanici a server vloºený router, na kterém bude b¥ºet simulátor. To m·ºe p°inést zvý²ené náklady na po°ízení hardware routeru. Tyto náklady ov²em nemusí být nijak vysoké, nebo´ výkon tohoto hardware nemusí být nijak zvlá²´ vysoký. V p°ípad¥ pouºití PC nap°íklad sta£í oby£ejný kancelá°ský po£íta£ se 2 sí´ovými
3.1.
UMÍST
NÍ SIMULÁTORU
13
rozhraními. Snadná je ur£it¥ centrální správa, nebo´ v²echny klientské stanice jsou umíst¥ny v lokální síti a v²echen provoz tak prochází routerem. Lze zde také snadno odd¥lit jednotlivé toky od r·zných vývojá°·. Toto °e²ení je zobrazeno na obrázku 3.3.
Obrázek 3.3: Umíst¥ní limiteru na routeru
•
jednoduchá centrální správa
•
snadné odd¥lení datových tok· a vývojá°·
•
nezávislé na OS
•
nutná zm¥na zapojení a adresace sít¥
•
zvý²ené náklady na po°ízení routeru
3.1.4
Simulátor na vloºeném PC
Toto °e²ení má více variant. Primárn¥ jde o to, zda-li pracuje na 2. nebo 3. vrstv¥ ISO/OSI modelu. Pokud by m¥lo pracovat na 3. vrstv¥, musí p°ekládat IP adresy a takové °e²ení pak lze povaºovat za umíst¥ní simulátoru na router, nebo´ vykazuje v²echny vlastnosti stejné. Pokud bude toto PC pracovat na 2. vrstv¥, nastává problém p°i rozli²ování datových tok· podle IP adres, p°ípadn¥ £ísel port·, nebo´ IP adresace je záleºitost 3. vrstvy ISO/OSI modelu. Tento postup by byl velmi sloºitý. Vloºené PC m·ºe být p°i p°ítomnosti routeru v síti vloºeno do klientské £ásti sít¥ (viz. obrázek 3.4) nebo do serverové v¥tve (viz. obrázek 3.5). P°i umíst¥ní PC do serverové £ásti nastává problém s rozli²ením zdroje datových tok·, pokud router p°ekládá sí´ové adresy. Pokud budeme tedy p°edpokládat práci na 2. vrstv¥ a umíst¥ní v klientské £ásti, p°iná²í toto °e²ení podobné vlastnosti, jako umíst¥ní na routeru, ale sloºit¥j²í rozli²ování datových tok·. Naopak toto °e²ení nevyºaduje zm¥nu adresace lokální sít¥.
•
jednoduchá centrální správa
•
nezávislé na OS
•
nemusíme m¥nit adresaci
•
sloºité rozli²ení datových tok·
•
náklady na po°ízení PC
14
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
Obrázek 3.4: Umíst¥ní limiteru na vloºeném PC v klientské £ásti sít¥
Obrázek 3.5: Umíst¥ní limiteru na vloºeném PC v serverové £ásti sít¥
3.1.5
Simulátor na proxy serveru
Toto °e²ení p°edstavuje p°ipojení vyhrazeného po£íta£e do lokální sít¥. Tento po£íta£ bude obsahovat simulátor a proxy server. Samoz°ejm¥ s sebou nese náklady na po°ízení tohoto hardware. Výhodou je, ºe lze snadno centráln¥ spravovat nastavení, ºe °e²ení není závislé na OS klienta ani serveru, dokáºeme snadno rozli²ovat datové toky a nemusíme m¥nit ani adresaci, ani zapojení sít¥. Zp·sob zapojení je patrný z obrázku 3.6. Podstatné je, ºe je zapot°ebí do proxy serveru p°esm¥rovat provoz z klienta, coº je moºné pomocí standartních nástroj· a nastavení zvládne i pokro£ilý uºivatel. Dále lze omezovat provoz pouze na datových tocích, které umí p°edávat daný proxy server.
Obrázek 3.6: Umíst¥ní limiteru na proxy serveru
•
jednoduchá centrální správa
3.2.
VOLBA PLATFORMY A OPERANÍHO SYSTÉMU
•
nezávislé na OS
•
nemusíme m¥nit adresaci
•
náklady na po°ízení hardware
•
pot°eba p°esm¥rování provozu
3.1.6
15
Volba vhodného umíst¥ní
Umíst¥ní simulátoru na klienta nebo na server je zcela vylou£eno, nebo´ v n¥kterých typických situacích je nelze pouºít. Je tedy patrné, ºe bez dodate£ných náklad· na HW se kvalitní °e²ení v ºádném p°ípad¥ neobejde. Tyto náklady v²ak vzhledem v vý²e uvedeným skute£nostem nemusí být p°íli² vysoké. P°i porovnání umíst¥ní na routeru a na vloºeném PC zjistíme, ºe jediná výhoda vloºeného PC je, ºe není t°eba m¥nit adresaci, coº není p°íli² limitující faktor. Naopak si v²ak tímto °e²ením zp·sobíme zna£né komplikace, na kterých by °e²ení mohlo zcela selhat. Proto umíst¥ní na vloºeném PC nebudeme jiº dále uvaºovat. Do hledá£ku se nám tak dostávají 2 °e²ení. Prvním je jiº zmín¥né umíst¥ní na router. Druhým °e²ením je pak umíst¥ní na proxy server. Toto °e²ení je velmi p¥kné, nebo´ nemusíme nijak m¥nit zapojení sít¥, pouze je t°eba nastavit na klientské stanici vhodné p°esm¥rování provozu. Bohuºel p°i hlub²ím zkoumání narazíme na technické problémy p°i pouºití konkrétních implementací proxy server·. Tyto potíºe budou pozd¥ji hloub¥ji popsány, ale nyní toto °e²ení zamítáme. Za vhodné °e²ení tedy byl podle vý²e uvedených údaj· bylo vybráno umíst¥ní simulátoru na router.
3.2 Volba platformy a opera£ního systému N¥kolik výrobc· nabízí produkty zaloºené na vlastních produktech (tím mám namysli zejména Cisco a jejich Cisco IOS nebo MikroTik a RouterOS), nicmén¥ velká £ást je zaloºena na otev°ených systémech jako GNU/Linux, p°ípadn¥ odvozených (nap°. OpenWrt). Je tedy moºné navrhnout systém jako modul pro n¥který proprietární systém, nejspí²e Cisco IOS, ale vzhledem k tomu, ºe se snaºíme vytvo°it otev°ený systém s co nejniº²í cenou, budeme volit opera£ní systém Linux. Tento systém navíc lze zprovoznit na velkém mnoºství hardwaru. Kv·li snadné dostupnosti HW se v této práci budeme zabývat platformou PC, ale nic nebrání tomu, aby systém mohl být nainstalován i na jinou platformu, kde je moºné nainstalovat OS GNU/Linux. Výb¥r distribuce linuxu v mém p°ípad¥ jednozna£n¥ vede na Debian-based distribuce, díky tomu, ºe mám jejich pom¥rn¥ hluboké znalosti. K vývoji budu vyuºívat konkrétn¥ Ubuntu Server 10.04, ale systém bude vyvíjen tak, aby fungoval i na nativním Debianu. P°enesení na jinou distribuci nebude patrn¥ úpln¥ jednoduchou operací, zejména bude t°eba zm¥nit £ásti, které se zabývají kongurací sít¥, nebo´ tyto kongura£ní soubory se podle distribuce £asto li²í.
16
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
3.3 Výb¥r vhodných nástroj· pro nastavení parametr· Nebo´ existuje jiº mnoho nástroj·, které umoº¬ují nastavování parametr· sít¥, je kontraproduktivní vyvíjet vlastní. Je vhodné vyuºít n¥které standartní nástroje, které jsou jiº otestované a odlad¥né. Existující nástroje jiº byly uvedeny v kapitole 2.3. Protoºe systém Limnet budeme vyvíjen pro systém GNU/Linux, bude nejlep²í vyuºít moduly v jeho jád°e, pokud to bude dosta£ující. Jejich kongurace nepat°í k nejjednodu²²ím, ale to je úkolem této práce, zjednodu²it ji. P°i bliº²ím pohledu na jednotlivé moduly za£íná být jasné, ºe jist¥ pouºijeme Netem, který umoº¬uje simulovat v¥t²inu parametr·, které pot°ebujeme, dokonce umí i n¥které dal²í. Jediné, co tento modul neumí simulovat, je ²írka pásma. Je proto t°eba vybrat je²t¥ modul, kterým budeme omezovat ²í°ku pásma. K tomu je v linuxu hned n¥kolik modul·, které vyuºívají r·zné algoritmy, ale abychom dokázali moduly snadno kombinovat, je dobré je za°adit do hierarchické struktury. To znamená, ºe musíme vybrat modul, který hierarchickou strukturu podporuje, nebo´ Netem je tzv. classless, neboli bez t°íd, coº znamená, ºe ho lze do hierarchických struktur zav¥sit jedin¥ jako list. Moduly, které slouºí k omezení ²í°ky pásma a zárove¬ podporují hierarchickou strukturu, jsou dva. Jedná se o moduly CBQ a HTB. Vzhledem k tomu, ºe HTB vylep²uje CBQ, budeme volit tento. HTB vyuºívá algoritmu Token Bucket, který má pro nás jednu moºná neºádoucí vlastnost, a to, ºe umí chvilkov¥ p°ekro£it povolenou rychlost, pokud p°edtím n¥jakou dobu nekomunikoval. To v²ak nemusí být nezbytn¥ problém, naopak ve spoust¥ sítí nejsou omezení hardwarová, ale softwarová, a zde jsou zpravidla k omezení pouºity ltry/moduly pouºívající Token Bucket.
3.4 Návrh aplikace Aplikace musí být rozd¥lena minimáln¥ na dv¥ £ásti. První £ást se musí starat o nastavení routeru a parametr· sít¥, dále jí budeme nazývat rozhraní pro konguraci, dále jen sobem budou realizovány
scéná°e
kongurátor.
opera£ní £ást.
Druhá £ást musí být
Pak je d·leºité rozhodnout, jakým zp·-
(dynamické nastavení parametr·). To m·ºe být bu¤to
sou£ástí opera£ní £ásti, p°ípadn¥ interakcí kongurátoru a opera£ní £ásti, a nebo to m·ºe tvo°it samostatnou £ást.
3.5 Volba implementa£ního prost°edí 3.5.1
Opera£ní £ást
Opera£ní £ást m·ºe být bu¤to nativní aplikace (kompilovaná), interpretovaná aplikace (nap°. Java) nebo skript (Python, Bash, ...). Tato £ást musí poskytovat zp·sob p°ipojení pro kongurátor, p°ípadn¥ pro ru£ní zásah administrátora. Pro ru£ní zásah administrátora je vhodný p°íkazový interpret, p°ípadn¥ dialogová aplikace. Obecn¥ rozhraní m·ºe být pomocí p°íkazového °ádku, prost°ednictvím sít¥ (vlastní £i existující protokol) nebo t°eba jmenná pipa (named pipe). Pokud budeme pouºívat jiné
3.5.
VOLBA IMPLEMENTANÍHO PROSTEDÍ
17
rozhraní, neº p°íkazovou °ádku, bude t°eba je²t¥ vytvo°it aplikaci, která bude z p°íkazové °ádky p°edávat p°íkazy na dané rozhraní. Nativní aplikace má výhodu v tom, ºe m·ºe s pomocí socket· komunikovat p°ímo s jádrem systému a nemusí vyuºívat ºádné dal²í aplikace, totéº vlastn¥ platí i o interpretovaných aplikacích. V tomto p°ípad¥ v²ak není t°eba programovat pom¥rn¥ sloºitou aplikaci, kdyº úkol· na ní je sice kladeno hodn¥, ale nejsou sloºité a zvládne to jednodu²e i skript. Opera£ní £ást tedy budeme koncipovat jako skript. Skriptovací jazyk zvolíme tak, aby byl podporován na co nej²ir²ím spektru linuxových distribucí a nezhor²ovali jsme tak portovatelnost. Jazyk, který by m¥l bez potíºí zvládnout v²echny pot°ebné úkony bude tedy n¥který základní shell opera£ního systému. Základem v²ech b¥ºných distribucí (krom¥ embedded za°ízení, neboli vestav¥ných za°ízení, kde je základním shellem v¥t²inou BusyBox) je Bash (Bourne-again shell). Zkusíme tedy opera£ní £ást navrhnout jako bashový skript a nadále jej budeme nazývat limnet skript.
3.5.2
Kongurátor
Tato £ást musí být zaloºena na architektu°e client-server, nebo´ kongurace se bude provád¥t z pracovních stanic. Je spí²e zajímavé, jak tuto architekturu postavíme. M·ºeme bu¤to vytvo°it vlastní klientskou a serverovou aplikaci nebo lze samoz°ejm¥ vyuºít i n¥které existující. Implementace vlastních aplikací bývá zdlouhavá a náro£ná. Velmi dobrou volbou m·ºe být vytvo°ení webové aplikace, kdy budeme vyuºívat existující webový server i klient, kterým bude internetový prohlíºe£ na stran¥ uºivatele. Tímto zp·sobem lze dnes kongurovat v¥t²inu sí´ových za°ízení, které mají p°i°azenu IP adresu. Na webserveru navíc lze snadno volat opera£ní £ást z p°íkazového °ádku a nebude t°eba vyvíjet klientskou aplikaci kongurátoru pro r·zné platformy, nebo´ webový prohlíºe£ je dnes standartní sou£ástí kaºdého systému, p°ípadn¥ je voln¥ ke staºení. Kongurátor tedy budeme vyvíjet jako webovou aplikaci. Nezáleºí p°íli² na tom, jaký jazyk k tomu pouºijeme, ale nejb¥º¬¥j²í varianta na linuxu je patrn¥ kombinace Apache, PHP, MySQL a Javascript. Budeme se toho tedy drºet. Aby se stránky zobrazovaly korektn¥ ve v²ech b¥ºných prohlíºe£ích, musí být stránky validní podle konsorcia W3C. Pro návrh stránek bude zvolen document type (DOCTYPE) XHTML 1.0 Strict.
3.5.3
Scéná°e
Scéná°e, neboli dynamické nastavení parametr·, lze implementovat n¥kolika zp·soby. Bu¤to je moºné je ud¥lat jako sou£ást limnet skriptu, pak je zapot°ebí, aby skript beºel trvale, bylo s ním moºné komunikovat a donutit ho m¥nit parametry podle vybraného scéná°e na vybraném datovém toku. Zárove¬ musí um¥t takto nastavovat n¥kolik datových tok· sou£asn¥. To se zdá jako pom¥rn¥ sloºitý úkol. Dal²í moºností je vytvo°it k tomuto ú£elu samostatný skript, ze kterého je moºné pro kaºdý scéná° vyvolat samostatnou instanci. To uº za£íná být trochu jednodu²²í a ur£it¥ to m·ºe fungovat, ale bude patrn¥ problém ve webovém rozhraní zobrazovat automaticky aktuální stav (neboli aktuáln¥ zvolené parametry). Dal²í moºná varianta m·ºe být Javascript. Tato varianta vypadá výborn¥ ze strany informovanosti uºivatele. Na serveru nemusí kv·li scéná°i nic b¥ºet, tudíº není nijak zatíºen.
18
KAPITOLA 3.
ANALÝZA A NÁVRH EENÍ
Javascript pak ve zvolené okamºiky posílá na server asynchroní dotazy (AJAX), kterými °íká serveru, jak se mají zrovna zm¥nit parametry sít¥. Problém tohoto °e²ení m·ºe být snad pouze v drobné prodlev¥ mezi z voláním z Javascriptu a skute£nou zm¥nou parametr·, nebo´ AJAX request zabere n¥jaký £as. P°edpokladem v²ak je, ºe router bude odd¥len od klientské stanice pouze lokální rychlou sítí, takºe tato prodleva by nem¥la být nijak vysoká (°adov¥ nejvý²e jednotky milisekund), proto si ji m·ºeme dovolit a volíme toto °e²ení.
3.6 Zp·sob uloºení nastavení A£koliv je data moºné ukládat mnoha r·znými zp·soby, a´ uº se jedná o ukládání do soubor· nebo speciálních úloºi²´ (nap°. Java RMI), jako nejvhodn¥j²í se vzhledem k typu ukládaných dat jeví pouºití databáze, obzvlá²´ pro kongurátor, který bude implementován jako webová aplikace. U takto malého projektu nezáleºí na tom, který databázový server pouºijeme, proto vyuºijeme open source databázi MySQL.
Kapitola 4
Realizace Tato kapitola se bude v¥novat konkrétní realizaci jednotlivých £ástí Limnetu. V²echny úkoly budou °e²eny v prost°edí Debian-based Linuxu, konkrétn¥ ve verzi Ubuntu Server 10.04. Tyto postupy pak tedy mohou být odli²né pro jiné distribuce linuxu. Pro portování systému na jinou distribuci linuxu si dovoluji odkázat na manuálové stránky jednotlivých p°íkaz·. D·leºité je zmínit, ºe ve²kerá komunikace systému s uºivatelem, p°ípadn¥ administrátorem, probíhá v anglickém jazyce, nebo´ ten je mezinárodn¥ uznávaným ve sv¥t¥ po£íta£·.
4.1 Problémy p°i °e²ení pomocí proxy serveru Jak bylo uvedeno v kapitole 3.1.6, jedno z moºných °e²ení by bylo pomocí proxy serveru. Toto °e²ení by p°icházelo v úvahu podle poºadavk· na systém, ale bylo zamítnuto zejména z d·vodu technických problém·, které v obecn¥j²í rovin¥ nebyly rozebírány. Zde je tedy vhodné místo pro rozebrání t¥chto technických detail·. Rozli²ování jednotlivých datových tok· je realizováno na sí´ové vrstv¥ a toky jsou rozli²ovány podle rozdílných zdrojových a cílových IP adres a zdrojových a cílových port·. P°i pouºití proxy serveru jsou v²ak packety sm¥rovány na tento server, tedy zdrojová IP adresa a port jsou v po°ádku, ale cílová adresa a port jsou ur£eny proxy serverem. Tento proxy server následn¥ vygeneruje nový packet, který má správnou cílovou IP adresu a port, ale zdrojová adresa IP a port pat°í proxy serveru. Je tedy jasné, ºe jediný £len v tomto °et¥zci zná zárove¬ zdrojové i cílové parametry daného packetu. Tím je práv¥ proxy server. Proto jsou jen omezené moºnosti, jak upravovat tento provoz.
4.1.1
Trac shaping v proxy serveru
Prvním °e²ením je, ºe provoz m·ºe být tvarován p°ímo v proxy serveru. Toto °e²ení p°ichází v úvahu pouze v p°ípad¥, ºe najdeme proxy server, který umoº¬uje nastavovat v²echny pot°ebné parametry, p°ípadn¥ takový proxy server sami vytvo°íme. Proxy server, který by dokázal nastavovat v²echny pot°ebné parametry (jako t°eba ztrátovost) jsem nena²el a jeho vývoj by byl velmi sloºitou záleºitostí.
19
20
4.1.2
KAPITOLA 4.
REALIZACE
Zna£kování packet· v proxy serveru
Druhou variantou, jak odli²ovat r·zné datové toky je, ºe v proxy serveru jednotlivé packety budeme ozna£ovat a tvarování m·ºe probíhat jiº na úrovni jádra systému. K tomu je op¥t pot°eba úzká spolupráce proxy serveru. Na²el jsem variantu pouºití Netlter zna£ek, coº umoº¬uje proxy server squid-cache od verze 3.2, která v²ak v dob¥ p°ípravy této práce je teprve v beta verzi, proto není vhodná k ostrému nasazení.
4.1.3
Vlastní lter pro dekódování pravidel
Dal²í variantou je moºnost vytvo°ení vlastního ltru, který nezávisle na proxy serveru bude packety dekódovat je²t¥ p°ed vstupem do proxy serveru, bude v nich vyhledávat cílové p°esm¥rování a to pak pouºije pro pravidla tvarování provozu. Toto je dal²í zbyte£n¥ p°íli² sloºitá varianta.
4.1.4
Trac shaping p°íchozího provozu
Dále je problémem to, ºe sí´ový provoz (jak bude pozd¥ji vysv¥tleno), je tvarován aº p°i odchodu ze sí´ového rozhraní. Toto v²ak lze pom¥rn¥ snadno vy°e²it pouºitím virtuálního sí´ového rozhraní. Jedno takové je k dispozici i p°ímo v jád°e linuxu. Jmenuje se IFB (Intermediate Functional Block) a vkládá se p°ed vstupní interface. Provoz je pak tvarován p°i odchodu z tohoto virtuálního rozhraní. Jeho vloºení a p°esm¥rování provozu do rozhraní
eth0 lze provést následujícími p°íkazy:
# vytvo°í 1 virtuální za°ízení pojmenované ifb0 modprobe ifb numifbs=1 # p°epne rozhraní ifb0 do provozního stavu ip link set dev ifb0 up # vytvo°í v za°ízení eth0 vstupní frontu tc qdisc add dev eth0 ingress # p°esm¥rování výstupní fronty z ifb0 do eth0 tc filter add dev eth0 parent ffff: protocol ip u32 \ match u32 0 0 flowid 1:1 action mirred egress redirect dev ifb0
4.2 Routování Protoºe °e²ení bude implementováno jako router, je t°eba se nejprve v¥novat zprovozen¥ní routování.
4.2.1
Nastavení jednotlivých rozhraní
K nastavení adres rozhraní slouºí p°íkaz p°íkazem
route
ifcong.
Dále pak m·ºeme nastavit výchozí bránu
a DNS záznamy vloºíme do souboru
/etc/resolv.conf.
Pokud budeme
chtít nastavit rozhraní pomocí DHCP serveru, m·ºeme pouºít nap°íklad program
dhclient.
Konkrétní syntaxe jednotlivých p°íkaz· je z°ejmá z následujících dvou p°íklad·. První p°íklad nastaví na rozhraní eth0 statickou adresu 20.19.18.17 s maskou 8 bit·, nastaví výchozí
4.3.
21
TRAFFIC CONTROL
bránu na 20.19.18.1 a p°idá DNS záznam na server 8.8.8.8. Druhý p°íklad provede nastavení prost°ednictvím DHCP serveru. P°íklad 1:
ifconfig eth0 20.19.18.17 netmask 255.0.0.0 route add default gw 20.19.18.1 echo "nameserver 8.8.8.8" > /etc/resolv.conf P°íklad 2:
dhclient eth0 T¥mito p°íkazy lze nastavit rozhraní po dobu b¥hu systému, ale je t°eba zabezpe£it, aby tato nastavení byla obnovena i po restartu systému. DNS servery z·stanou nastavené, nebo´ jsou uloºeny v souboru, ale ostatní nastavení se ztratí. Obnovení nastavení docílíme uloºením nastavení do kongura£ního souboru. V distribuci debian a jeho odnoºích se jedná o soubor
/etc/network/interfaces.
Jeho konkrétní podobou se zde nebudeme zabývat a odkazuji
na manuálové stránky.
4.2.2
IP forwarding
IP forwarding je vlastn¥ samotné routování. P°edávání musí být povoleno, aby router mohl fungovat. Forwarding lze zapnout n¥kolika zp·soby. První moºnost je po nab¥hnutí systému zapsat £íslo 1 do souboru
/proc/sys/net/ipv4/ip_forward.
Dal²í moºnosti toto automatizují p°i startu systému. Na star²ích systémech debian m·ºeme
/etc/network/options zapsat volbu ip_forward=yes. Nejlep²í moºnost je v²ak vyuºití sysctl.conf v adresá°i /etc. Do tohoto kongura£ního souboru sta£í zapsat volbu net.ipv4.ip_forward=1. zapsat do souboru
4.2.3
NAT
Router bude podporovat p°eklad adres, nebo-li modul NAT. Tento modul lze zapnout na rozhraní eth0 p°íkazem:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Cíl
MASQUERADE
se pouºívá p°i dynamickém p°id¥lování IP adres na WAN rozhraní. V této
práci jej pouºíváme proto, ºe na tomto rozhraní nemusí být p°id¥lena statická IP adresa.
4.3 Trac control Tvarování provozu je v linuxu provád¥no p°i odchodu packetu ve chvíli, kdyº packet opou²tí interface. Vyuºívá se toho, ºe na kaºdém rozhraní je zav¥²en plánova£ packet· (packet scheduler). Ve výchozím stavu tento plánova£ bývá pfo_fast, který reprezentuje t°ípásmovou frontu, kde jsou data klasikována podle typu sluºby a priority p°i°azené packetu.
22
KAPITOLA 4.
REALIZACE
Nastavením trac shapingu, neboli tvarování provozu, se tento výchozí plánova£ nahradí n¥jakým jiným, který vykonává tvarovací funkci. Tomuto plánova£i se °íká
qdisc
(Queue-
ing Discipline) a k n¥mu se p°i°azuje algoritmus, který ur£uje, kdy a jak bude který packet odeslán. Typy t¥chto qdisc· mohou být t°ídní (classful) nebo bez t°íd (classless). N¥které z nich mohou mít hierarchické uspo°ádání. Ty pak musí být t°ídní, pouze jako listy ve stromovém uspo°ádání mohou být zav¥²eny qdiscy bez t°íd. Pro vytvá°ení, zm¥nu £i mazání pravidel tvarování provozu v linuxu slouºí nástroj
tc.
Pouºití tohoto p°íkazu je docela dob°e popsáno v manuálu od Ariane Keller [12]. Dále projdeme zp·sob kongurace qdisc·, které jsou pouºity v Limnetu.
4.3.1
HTB
Modul HTB je t°ídní modul k omezování a rozd¥lování ²í°ky pásma. Pokud pot°ebujeme sloºit¥j²í strukturu rozd¥lování rychlosti, je moºné z t°íd sestavit strom, který ur£í, jak bude rychlost rozd¥lována. Kaºdá t°ída m·ºe mít 2 parametry pro p°id¥lení rychlosti. Parametr
rate ur£uje rychlost, která bude dané t°íd¥ p°id¥lena. Druhý parametr ceil pak udává maximální rychlost, kterou t°ída m·ºe vyuºít, pokud konektivita není vyuºita ostatními t°ídami. Pokud ceil není uveden, je automaticky p°evzata hodnota z parametru rate. Parametr
fault
de-
ur£uje, která t°ída dostane k dispozici nevyuºitou konektivitu, pokud n¥jaká zbývá.
Pokud v n¥m ur£ím¥ neexistující t°ídu, pak to znamená, ºe tuto konektivitu ºádná t°ída vyuºívat nebude. Obdobn¥ to dopadne, pokud tak ur£íme zbytkovou t°ídu, kterou nevyuºívá ºádný datový tok. Následující p°íkazy vytvo°í základní pravidlo pro vytvo°ení jedné t°ídy:
tc qdisc add dev eth0 root handle 1: htb default ff tc class add dev eth0 parent 1: classid 1:1 htb rate 256kbit
4.3.2
Netem
Netem je modul bez t°íd, který umí nastavit spoustu parametr· sít¥. Ty byly jiº vý²e uvedeny. Vzhledem k mnoºství r·zných parametr· se s konkrétní syntaxí odkáºu na návod na domovské stránce [3]. Zde uvedeme p°íklad vloºení qdiscu netem jako list vý²e vytvo°ené t°ídy htb 1:1. Tento qdisc zp·sobí zvý²ení zpoºd¥ní o 100ms.
tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 100ms
4.3.3
Návrh hierarchie
Kaºdý qdisc má svojí handle, která ho jednozna£n¥ identikuje. Ta má 16 bit· rozsah (max. = 65535), ale nejvy²²í hodnota je vyhrazena pro p°esm¥rování provozu (ingress a egress qdiscy), proto muºeme vyuºít nejvý²e hodnotu fe hexadecimáln¥, coº je 65534 decimáln¥. Obdobn¥ má kaºdá t°ída handle sestávající z handle qdiscu, pod který t°ída pat°í, a vlastní handle odd¥lené dvojte£kou. Kaºdý qdisc a t°ída má ur£enu handle rodi£ovského prvku a tímto se dají pravidla seskupit do stromu. Vzhledem k tomu, ºe není snahou prioritizovat n¥kterou klientskou stanici p°ed jinou a zrovna tak se nesnaºíme rozd¥lovat rychlost mezi jednotlivé stanice, posta£í jednoduchý
4.4.
PID
LENÍ PRAVIDEL KE KONKRÉTNÍMU DATOVÉMU TOKU
23
strom s jedním ko°enovým qdiscem. Tento qdisc bude typu HTB, nebo´ HTB podporuje hierarchické uspo°ádání. Na n¥m budou zav¥²eny t°ídy HTB, které budou ur£ovat omezení ²í°ky pásma. Kaºdá t°ída pro jednu klientskou stanici. Na tuto t°ídu pak bude jako list zav¥²en qdisc Netem, který bude pro danou stanici nastavovat v²echny ostatní parametry. Takto vytvo°íme dva stromy. Jeden bude na LAN rozhraní a bude nastavovat pravidla pro datový tok sm¥°ující ke klientské stanici. Druhý strom bude na WAN rozhraní a pravidla bude nastavovat pro toky sm¥°ující k serveru. Tímto zp·sobem m·ºeme nastavit zvlá²´ v²echna pravidla pro download i upload.
4.4 P°id¥lení pravidel ke konkrétnímu datovému toku To, ºe vytvo°íme qdiscy a t°ídy s n¥jakými pravidly, je²t¥ neznamená ovliv¬ování konkrétního provozu. Je²t¥ je zapot°ebí vytvo°it pravidla, která ke konkrétní t°íd¥/qdiscu p°i°azují datový tok. Následující p°íklad nastaví, ºe vý²e uvedené moduly HTB a Netem budou upravovat datové toky pocházející ze zdrojové adresy 192.168.1.1.
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 \ match ip src 192.168.1.1 flowid 1:1 Povaºujeme-li adresu 192.168.1.1 za IP adresu klienta a interface eth0 za WAN routeru, vý²e uvedené pravidlo zp·sobí, ºe limity budou upravovat upload z této pracovní stanice. Obdobn¥ lze upravit i download, který ov²em musíme tvarovat na LAN rozhraní a IP adresu musíme ur£it jako cílovou. M·ºe to vypadat nap°íklad následovn¥:
tc filter add dev eth1 protocol ip parent 1:0 prio 1 u32 \ match ip dst 192.168.1.1 flowid 1:1 Samoz°ejm¥ pravidlo pro download m·ºe být ur£eno jinou t°ídou, neº upload, tak docílíme rozdílných parametr· pro download a upload.
4.5 Rozli²ení tok· uploadu p°i pouºití NAT Vý²e uvedený zp·sob rozli²ení datových tok· p°i uploadu nebude fungovat, pokud na routeru bude nasazen NAT. Problém spo£ívá v tom, ºe p°i tvarování na odchozím rozhraní je jiº p°eloºena zdrojová adresa na adresu routeru. Pravilo ltru pak nerozpozná daný packet. Tento problém lze °e²it nap°íklad pomocí zna£kování packet· zna£kami Netlter. Tyto zna£ky m·ºeme p°i°adit k packet·m je²t¥ p°ed p°ekladem adresy pomocí
iptables. Tato zna£ka není
uloºena fyzicky do packetu, ale je k n¥mu p°i°azena na úrovni jádra systému a není p°ekladem adresy odstran¥na. Následn¥ m·ºeme k ltru p°idat informaci, aby provoz byl tvarován, pokud obsahuje tuto zna£ku. Vý²e uvedená pravidla ltru m·ºeme pak p°epsat nap°íklad následujícím zp·sobem:
# vytvo°it zna£kovací pravidlo pro tcp - p°i zdrojové IP p°idat zna£ku 1 iptables -t mangle -A PREROUTING -i eth1 -p tcp -s 192.168.1.1 \ -j MARK --set-mark 1
24
KAPITOLA 4.
REALIZACE
# vytvo°it zna£kovací pravidlo pro udp - p°i zdrojové IP p°idat zna£ku 1 iptables -t mangle -A PREROUTING -i eth1 -p udp -s 192.168.1.1 \ -j MARK --set-mark 1 # p°i zna£ce 1 (handle) se °ídit pravidly t°ídy 1:1 tc filter add dev eth0 protocol ip parent 1:0 prio 1 handle 1 fw classid 1:1
4.6 P°ístup k databázi z limnet skriptu P°edávat dotazy do databáze a zobrazovat jejich výsledky lze s pomocí klentské aplikace
mysql. Tomuto nástroji lze p°edat parametry p°ipojení do databáze a jako parametr lze p°e-
dat i SQL dotaz, který bude proveden. Výsledek daného dotazu je vyti²t¥n na standartní výstup. První °ádek tohoto výstupu p°edstavuje hlavi£ky výstupní tabulky. Následující p°íklad vypí²e obsah tabulky tbltest v databázi dbtest.
mysql -h localhost -u user --password="password" -D dbtest -s \ -e "select * from tbltest;"
4.7 Popis implementace limnet skriptu Protoºe tvarovací pravidla jsou nastavena v systému a o b¥h scéná°· se bude starat javascript, limnet script nemusí b¥ºet trvale. Jeho úkolem je zpracovat parametry z p°íkazové °ádky a podle nich aplikovat nastavení systému, p°ípadn¥ upravit databázi. Skript zárove¬ musí um¥t aplikovat do systému pravidla z databáze, pokud zatím aplikována nejsou (nap°íklad p°i startu systému). Obdobn¥ je t°eba aplikovat pravidla, pokud bude skript volán p°i AJAXovém volání p°i b¥hu scéná°e. Základem skriptu je tedy zpracování p°íkazové °ádky, p°ípadn¥ kontrola správnosti p°edaných parametr·. Pro kontrolu správnosti parametr· je vyuºito regulárních výraz· a nástroje
grep.
4.7.1
Spu²t¥ní systému
První akcí by m¥lo být aplikování denovaných pravidel do systému. To se provede následujícím p°íkazem.
./limnet start P°i volání tohoto p°íkazu se nejprve zkontroluje, zda pravidla jiº nebyla aplikována. Toho je docíleno vyhledáním ko°enového qdiscu typu HTB. Pokud tento qdisc nebyl nalezen, je na£tena tabulka pravidel z databáze a kaºdé z nich je d°íve uvedeným zp·sobem aplikováno do systému. Zárove¬ je zaveden modul NAT. Obdobn¥ lze p°íkazem
stop
zru²it v²echna aplikovaná pravidla. Tento p°íkaz je v²ak
implementován zejména kv·li celistvosti systému limnet, nebo´ v praxi z°ejm¥ nemá vyuºití. P°i zastavení jsou smazána v²echna pravidla a odstran¥n NAT. To se provede následujícími p°íkazy (pokud jsou rozhraní eth0 a eth1):
4.7.
25
POPIS IMPLEMENTACE LIMNET SKRIPTU
# odstran¥ní ko°enových qdisc· odstraní celý strom tc qdisc del dev eth0 root tc qdisc del dev eth1 root # smaºeme zna£kovací pravidla iptables -t mangle -F # odstraníme NAT iptables -t nat -F Pokud je v²ak t°eba systém restartovat, je implementován i p°íkaz
restart, který vyuºívá
p°íkazu stop.
4.7.2
Správa pravidel
Limnet skript musí um¥t p°idávat, upravovat a mazat tvarovací pravidla. Tato jsou ur£ena kombinací zdojové IP adresy a portu a cílové IP adresy a portu. Z tohoto vý£tu je zdrojová IP adresa povinná, nebo´ kaºdé pravidlo musí být dáno podle klientské stanice. Úkolem skriptu tedy je upravit podle pravidel databázi a pokud jsou aplikována jiº základní pravidla v systému, aplikovat i tuto zm¥nu. Tvrovací pravidla by nem¥la být m¥n¥na jiným zp·sobem, neº za pouºití limnet skriptu, nebo´ by pak nemusela být zachována struktura databáze. Tuto inkosistenci by v²ak vºdy m¥l vy°e²it restart systému.
4.7.3
Scéná°e
P°estoºe scéná°e jsou implementovány ve webovém rozhraní v javascriptu, limnet script musí poskytovat alespo¬ základní podporu pro tento zp·sob °e²ení. Javascript posílá na server requesty na zm¥nu aktuálního nastavení a tato zm¥na se provádí práv¥ v limnet scriptu. Na to je ve scriptu speciální p°íkaz
scenario,
který aplikuje parametry pouze v runtime
prost°edí a neupravuje nic v databázi. Tento p°íkaz by nem¥l být volán ru£n¥.
4.7.4
Nastavení sít¥
Nastavení sít¥ je rovn¥º, jako tvarovací pravidla, uloºeno v databázi. Proto pro zachování konzistence poskytuje limnet script moºnost nastavovat sí´. Skriptu se p°edá nové nastavení sít¥, skript pak toto nastavení zapí²e do databáze, uloºí do kongura£ních souboru a následn¥ aplikuje do aktuálního nastavení systému. Formáty kongura£ních soubor· jsou p°ipraveny pro systém Debian, p°ípadn¥ pro jeho odnoºe. Pro export nastavení jsou p°ipraveny ²ablony v podadresá°i
templates.
Na£ítání
kongura£ního souboru je implementováno p°ímo ve skriptu. Pokud by se skript portoval na jinou distribuci linuxu, je t°eba tuto £ást zm¥nit a upravit ²ablony.
4.7.5
Jednotky veli£in uvád¥ných v parametrech
Pro vy²²í jednoduchost skriptu v rámci tohoto skriptu nedochází k ºádnému p°epo£tu jednotek. V²echny parametry jsou p°edávány jen jako £ísla, ke kterým jsou p°i°azeny výchozí
26
KAPITOLA 4.
REALIZACE
jednotky. Pro nastavení ²í°ky pásma jsou výchozí jednotkou kilobity (kb/s), pro zpoºd¥ní a jitter se jedná o milisekundy a u v²ech ostatních veli£in jsou to procenta (tedy v rozsahu 0 aº 100). Tyto jednotky byly zvoleny jako nejb¥ºn¥ji pouºívané i p°esto, ºe základní fyzikální jednotky jsou odli²né.
4.8 Vývoj webové aplikace Webová aplikace slouºí p°eváºn¥ jako kongura£ní rozhraní systému. Jak bylo uvedeno v kapitole 3.5.2, webové rozhraní je psáno v jazyce PHP, p°i£emº výsledná stránka je renderována ve standardu XHTML 1.0 Strict. Kaºdá stránka je podle tohoto standardu validní. Aplikace je rozd¥lena na t°i základní £ásti. Tyto £ásti jsou p°ístupné z menu v horní £ásti obrazovky. První menu nadepsané Rules, neboli £esky Pravidla, je £ist¥ uºivatelská záleºitost. Druhá nabídka je Scenarios, coº £esky znamená Scéná°e, slouºí k editaci scéná°· k dispozici a zde záleºí na organizaci skupiny vývojá°·, zda je bude editovat uºivatel nebo administrátor systému. Poslední menu Router je £ist¥ administrátorská záleºitost a lze zde nastavit adresy rozhraní LAN a WAN.
4.8.1
Rules Pravidla
Na hlavní obrazovce, která je vid¥t na obrázku 4.1, je seznam pravidel, která jsou aktuáln¥ za°azena. Lze zde vytvo°it nové pravidlo a upravit nebo smazat n¥které z aktuálních. Dále je
Obrázek 4.1: Screenshot Seznam pravidel
moºné zde nad kterýmkoliv pravidlem spustit n¥který scéná°. To ºe je moºnost spu²t¥ní scéná°e práv¥ u pravidel neznamená, ºe scéná°e by n¥jak úzce souvisely s konkrétními pravidly. Jediné co se z t¥chto pravidel vyuºívá pro spu²t¥ní scéná°e jsou data pro ur£ení datového toku, tedy zdrojová IP adresa a port a cílová IP adresa a port.
4.8.
VÝVOJ WEBOVÉ APLIKACE
27
Jednotlivá pravidla jsou ut°íd¥na pod sebou v tabulce. Kaºdé pravidlo je rozloºeno na dvou °ádcích, v prvním °ádku jsou parametry downloadu, ve druhém pak parametry uploadu. Dal²í obrazovka v sekci
Rules
slouºí pro vytvo°ení nového pravidla a je vyobrazena
na obrázku 4.2. Zde lze vyplnit pravidla pro ltr (ta musí být v rámci systému unikátní,
Obrázek 4.2: Screenshot P°idání nového pravidla
neboli nelze vytvo°it dv¥ pravidla, která budou obsahovat stejnou kombinaci zdrojové adresy a portu a cílové adresy a portu), dále pak jednotlivé parametry sít¥. Povinná pole jsou zdrojová adresa a rychlost downloadu a uploadu. Omezení ²í°ky pásma je vºdy povinný údaj, nebo´ pro kaºdé pravidlo je vloºen modul HTB, pro který je uvedení rychlosti povinné. Pokud nechceme rychlost omezovat, sta£í do t¥chto kolonek vyplnit rychlost vy²²í, neº je rychlost lokální sít¥, tedy nap°íklad pro 100 Mb/s ethernet m·ºeme uvést hodnotu 100000, coº p°edstavuje 100 000 kb/s. Ostatní parametry jsou volitelné a nemusíme je vypl¬ovat, pokud je nechceme nijak m¥nit oproti výchozímu stavu. Tímto se postupn¥ dostáváme k moºnosti spu²t¥ní scéná°e nad daným datovým tokem. Pokud v tabulce pravidel klikneme na odkaz start scenario, otev°e se obrazovka z obrázku 4.3, která slouºí pro výb¥r ºádaného scéná°e. Tím jsme se dostali pon¥kud mimo p·vodn¥
28
KAPITOLA 4.
REALIZACE
uvád¥né rozd¥lení na t°i £ásti, nebo´ spou²t¥ní scénár· je vnit°n¥ samostatnou £ástí, ov²em je p°ístupná pouze ze sekce Rules, proto je uvád¥na práv¥ pod touto sekcí. Na obrazovce pro
Obrázek 4.3: Screenshot Výb¥r scéná°e ke spu²t¥ní
výb¥r scéná°e je uvedené pravidlo pro ltrování daného toku a pod ním je seznam scéná°·, které jsou k dispozici. U kaºdého z nich je odkaz select, který slouºí práv¥ pro výb¥r tohoto scéná°e. Pokud scéná° vybereme, dostaneme se kone£n¥ na obrazovku, kde je moºné scéná° spustit. Ta je k vid¥ní na obrázku 4.4. Na této obrazovce jsou krom¥ základních informací o vybraném scéná°i i pravidla pro rozli²ení datového toku a nakonec v²echna pravidla daného scéná°e. Tato pravidla jsou, aby bylo kaºdé pravidlo pouze na jeden °ádek, zapsána trochu nep°ehledn¥ bez jednotek a hlavi£ky tabulky jsou ve zkratkách, coº v²ak vzhledem k tomu, ºe se nám nejedná o maximální £itelnost (ta je dodrºena p°i editaci scéná°e), není na závadu. Pod touto tabulkou jsou tla£ítka
Start
a
Stop.
T¥mi je moºné daný scéná° spustit,
p°ípadn¥ pak b¥ºící scéná° op¥t zastavit. Pokud scéná° dob¥hne dokonce, p°ípadn¥ je ru£n¥ zastaven, nastavení pravidel je vráceno op¥t na p·vodní nastavení ur£ené u dané adresy. Toto samoz°ejm¥ není dodrºeno, pokud je b¥h scéná°e p°eru²en p°echodem na jinou stránku nebo zav°ením prohlíºe£e. Tím je scéná° zastaven, ale nastavení z·stává z posledního pro²lého pravidla scéná°e. P°i b¥hu scéná°e je aktuáln¥ nastavené pravidlo zobrazeno podbarvením daného °ádku tabulky ²edou barvou a vypsáním £erveným písmem. To je ostatn¥ vid¥t i na jiº vý²e zmín¥ném obrázku 4.4. Scéná°e jsou, jak bylo jiº d°íve uvedeno, implementovány pomocí javascriptu. Pro moºné zjednodu²ení této implementace je vyuºita knihovna jQuery [10]. V²e funguje tak, ºe jsou na£teny z tabulky jednotlivá pravidla, která jsou pak v £asových intervalech (op¥t uvedených v tabulce) zasílána pomocí AJAX dotaz· serveru. Ten p°edá parametry limnet skriptu a tím
4.8.
VÝVOJ WEBOVÉ APLIKACE
29
Obrázek 4.4: Screenshot B¥ºící scéná°
dojde k jejich aplikaci. Pokud toto projde úsp¥²n¥, webový server odpoví na AJAX volání zprávou OK. Pokud ne, je zde vrácen textový popis chyby a ta je následn¥ zobrazena i v prohlíºe£i.
4.8.2
Scenarios Scéná°e
Sekce scéná°e je jediná £ást webové aplikace, která upravuje databázi, nebo´ k tomuto nevyuºívá limnet skript. Tato £ást slouºí pouze k editaci scéná°·, které následn¥ mohou být spu²t¥ny ze sekce
Rules. Kaºdý scéná° m·ºe mít název a popis, p°ípadn¥ se m·ºe stále
opakovat (aº do zastavení). Kaºdý scéná° se pak sestává z pravidel, která mají p°id¥lený £as trvání. Na tuto dobu je vºdy platné dané pravidlo, pak je aplikováno pravidlo následující. Na první obrazovce 4.5 je vid¥t seznam denovaných scéná°·. U kaºdého z nich je moºné zobrazit detaily a nebo ho smazat. Dále je na této obrazovce k dispozici odkaz pro vytvo°ení nového scéná°e a importování scéná°e ze souboru CSV.
30
KAPITOLA 4.
REALIZACE
Obrázek 4.5: Screenshot Seznam scéná°· k editaci
Pokud klikneme na detail scéná°e, dostáváme se na obrazovku 4.6, kde je moºné editovat název a popisku scéná°e a je zde vid¥t seznam pravidel tohoto scéná°e. Kaºdé pravidlo je moºné editovat, smazat, p°esunout vý²e nebo níºe. Pak je samoz°ejm¥ moºné p°idat nové pravidlo. Na spodku obrazovky jsou tla£ítka
Save a Cancel. Tla£ítko Save slouºí k uloºení
zm¥n ve jméni a popise scéná°e. Tla£ítko Cancel jakékoliv zm¥ny zru²í a p°echází zp¥t na seznam scéná°·. Editace pravidla scéná°e je vid¥t na obázku 4.7. Op¥t je povinné vyplnit rychlost downloadu a uploadu a navíc £as, po který bude pravidlo platné. Stejn¥ vypadá i okno, ve kterém se dají pravidla ru£n¥ p°idávat, proto ho nemusíme zvlá²´ popisovat. Pokud chceme ru£n¥ vytvo°it nový scéná°, otev°e se okno z obrázku 4.8. Zde se musí vyplnit alespo¬ název scéná°e, který musí být unikátní. Scéná° se pak vytvo°í tla£ítkem
Save.
Zajímav¥j²í, neº vytvá°et scéná°e ru£n¥, je moºnost importovat je z CSV soubor·. Stránka pro import CSV soubor· je na obrázku 4.9. Zde se vypl¬ují stejné volby jako p°i ru£ním vytvá°ení scéná°e, av²ak navíc je povinné p°edat soubor CSV obsahující nový scéná°. Tento CSV soubor má jasn¥ denovanou strukturu. Na kaºdém °ádku je práv¥ jedno pravidlo. Kaºdé pravidlo sestává z £íselných hodnot odd¥lených £árkou. Desetinná £ísla musí mít jako desetinný odd¥lova£ te£ku (neboli mít anglický formát). Protoºe v pravidlech se nevyskytují °et¥zce, uvozovky jsou povaºovány za nepovolený znak. Jednotlivé hodnoty pravidla musí být uvedeny v následujícím po°adí:
•
í°ka pásma downloadu [kbps] (povinné)
•
Zpoºd¥ní downloadu [ms]
•
Jitter downloadu [ms]
•
Ztrátovost downloadu [%]
4.8.
31
VÝVOJ WEBOVÉ APLIKACE
•
Korelace ztrátovosti downloadu [%]
•
Mnoºství duplicit downloadu [%]
•
Mnoºství po²kozených packet· downloadu [%]
•
Mnoºství packet·, které budou doru£eny mimo po°adí downloadu [%]
•
Korelace mnoºství packet· mimo po°adí downloadu [%]
•
í°ka pásma uploadu [kbps] (povinné)
•
Zpoºd¥ní uploadu [ms]
•
Jitter uploadu [ms]
•
Ztrátovost uploadu [%]
•
Korelace ztrátovosti uploadu [%]
•
Mnoºství duplicit uploadu [%]
•
Mnoºství po²kozených packet· uploadu [%]
•
Mnoºství packet·, které budou doru£eny mimo po°adí uploadu [%]
•
Korelace mnoºství packet· mimo po°adí uploadu [%]
•
Doba trvání pravidla [s] (povinné)
V tomto formátu umí generovat CSV soubory aplikace
BandWidth Test,
která je
sou£ástí diplomové práce M¥°ení kvality GSM sítí pana Vladimíra Cibulky z roku 2012 [11].
4.8.3
Router
Protoºe °e²ení je implementováno jako router, je více neº vhodné poskytnout alespo¬ základní nastavení i do webového rozhraní. Za základní nastavní zde povaºujeme nastavení IP adres, respektive moºnost nastavení pomocí DHCP serveru na WAN rozhraní. Pro nastavení routeru je vytvo°ena ve webovém rozhraní zvlá²tní sekce p°ístupná z nabídky. Ta se jmenuje
Router a otevírá stránku zobrazenou na obrázku 4.10.
Protoºe je nastavení zárove¬ uloºeno v databázi, je t°eba k nastavení adres pouºívat limnet skript. Tento skript je zárove¬ pouºit i ke zji²t¥ní aktuálních IP adres p°id¥lených jednotlivým rozhraním. Tyto IP adresy sice nejsou nikde zobrazeny, ale jsou vyuºity v p°ípad¥ pot°eby p°esm¥rování kongura£ního rozhraní na novou IP adresu po její zm¥n¥. P°i zm¥n¥ IP adresy rozhraní, p°es které máme otev°eno webové rozhraní, je vygenerován odkaz pro otev°ení rozhraní na nové adrese. Tento zp·sob nefunguje, pokud k webovému rozhraní p°istupujeme p°es WAN a p°id¥líme mu adresu p°es DHCP, nebo´ b¥hem renderování výsledné stránky není je²t¥ nov¥ p°id¥lená adresa známa.
32
KAPITOLA 4.
4.8.4
REALIZACE
Gracké práce
Na webovém rozhraní je v horní £ásti umíst¥n gracký pruh, který je poskládán z n¥kolika grackých soubor·. Tyto soubory jsou v£etn¥ zdrojové graky a fotograí p°iloºeny k této práci a uvol¬uji je tímto jako volné dílo (public domain). V eské Republice v²ak není moºné se z°íci autorských práv, proto k t¥mto soubor·m ud¥luji bezplatnou licenci ke zcela libovolnému vyuºití. Gracké soubory jsou upraveny v open source grackém editoru GIMP. Tyto soubory jsou p°iloºeny ve formátu XCF.
4.8.
VÝVOJ WEBOVÉ APLIKACE
Obrázek 4.6: Screenshot Detail scéná°e
33
34
KAPITOLA 4.
Obrázek 4.7: Screenshot Editace pravidla scéná°e
REALIZACE
4.8.
VÝVOJ WEBOVÉ APLIKACE
Obrázek 4.8: Screenshot P°idání prázdného scéná°e
Obrázek 4.9: Screenshot Formulá° pro import scéná°e z CSV souboru
35
36
KAPITOLA 4.
Obrázek 4.10: Screenshot Nastavení adres sít¥ routeru
REALIZACE
Kapitola 5
Testování P°i testování se zam¥°íme zejména na parametry, které jsou uvedeny v zadání této práce, nebo´ jsou povaºovány za podstatné. T¥mito parametry jsou ²írka pásma, zpoºd¥ní a ztrátovost.
5.1 Testování ²í°ky pásma Testování ²í°ky pásma je moºné ov¥°it m¥°ením doby, za kterou je p°eneseno ur£ité mnoºství dat. Výsledná rychlost se pak samoz°ejm¥ získá podílem t¥chto dvou veli£in. Testování lze provést r·znými nástroji. V této práci pouºijeme kombinaci webového serveru a p°íkazového klienta
wget.
Nástroj wget p°i skon£ení stahování souboru automat-
icky zobrazí £as, za který byl soubor staºen, takºe je snadné dopo£ítat výslednou rychlost. P°i uploadu souboru sice toto neukazuje, ale zobrazí £asovou zna£ku p°ed uploadem a po jeho skon£ení, takºe situace je vlastn¥ obdobná.
5.2 Testování zpoºd¥ní a jitteru Zpoºd¥ní a jitter lze m¥°it opakovaným vyslíláním packetu do sít¥, na tento packet pak musí být ze serveru zaslána odpov¥¤. Vhodným kandidátem jsou proto ICMP packety, které vytvá°í nap°íklad nástroj
ping.
Toto °e²ení není idelální, nebo´ limnet omezuje na základ¥ IP adres a port·. Protoºe ICMP je protokol, který nemá porty, nebude p°i uploadu nijak upravován. To ºe se jedná pouze o upload zp·sobuje návrh limnetu, kdy p°i downloadu je k ur£ování datových tok· pouºit ltr programu na£ovány programem
tc, zatímco iptables.
p°i uploadu (z vý²e uvedených d·vodu) jsou packety oz-
Download ltr u protokol·, které nemají porty, tyto porty prost¥ ignoruje a tok vºdy tvaruje, zatímco upload bere v potaz pouze protokoly TCP a UDP. Moºností jak toto °e²it je samoz°ejm¥ mnoho. Nap°íklad lze vyuºít n¥kterou variaci http ping. V na²em testování pouºijeme klasický ping, ale na routeru p°ed testem, který omezuje upload, ru£n¥ vloºíme pravidlo, které bude ozna£ovat ICMP packety. To provedemé následujícím p°íkazem:
37
38
KAPITOLA 5.
TESTOVÁNÍ
/sbin/iptables -t mangle -A PREROUTING -i eth1 -p icmp \ -s 10.1.1.2/32 -j MARK --set-mark 0x1 V tomto p°íkazu je provádí test, a
eth1 interface lokální sít¥, 10.1.1.2 je IP adresa klientské stanice, která
0x1 je zna£ka p°i°azená k pravidl·m této stanice.
Je t°eba brát v úvahu, ºe zpoºd¥ní packetu zahrnuje oba sm¥ry jeho cesty. M·ºeme to tedy testovat tak, ºe nejprve nastavíme zpoºd¥ní pro download a provedeme m¥°ení, pak nastavíme zpoºd¥ní uploadu a provedeme m¥°ení. Následn¥ zpozdíme oba sm¥ry a dokáºeme, ºe zpoºd¥ní je sou£tem obou zpoºd¥ní. Jitter ur£íme jako maximální odchylku od pr·m¥rného zpoºd¥ní (vyuºijeme hodnot minimálního a maximálního zpoºd¥ní). Pokud m¥°íme na síti, která nevykazuje ideální vlastnosti, je t°eba provád¥t pat°i£nou korekci podle zanesené chyby.
5.3 Testování ztrátovosti Ztrátovost je t°eba testovat n¥kterým protokolem, který nevysílá znovu ztracené packety. Vhodné jsou op¥t nap°íklad ICMP packety, takºe testujeme obdobn¥, jako v p°ípad¥ zpoºd¥ní nástrojem
ping.
Tento nástroj p°i ukon£ení zobrazí statistiku, ve které jsou uvedeny po£ty
vyslaných a doru£ených packet· a rovn¥º procentuální vyhodnocení mnoºství ztracených packet·. Podobn¥, jako v p°ípad¥ zpoºd¥ní, i zde se m·ºe ztratit packet cestou na server stejn¥ jako se m·ºe ztratit odpov¥d od serveru.
5.4 Zapojení testovací sít¥ Pro testování systému by bylo vhodné pouºít vyhrazený po£íta£ se dv¥ma sí´ovými kartami jako router se systémem limnet. Na lokální sí´ by m¥la být p°ipojena klientská stanice a k WANu pak testovací server. Testovací sí´ by m¥la mít nízkou latenci. Bohuºel pro tuto situaci nemám vhodný hardware. Mám k dispozici sí´, na které je p°ipojeno n¥kolik po£íta£· (které bohuºel nemohu odpojit), s bezdrátovou £ástí, pak dva notebooky, kaºdý s jedním LAN interfacem a jedním WLAN interfacem, a jedno PC. PC je p°ipojeno do switche v lokální síti. Vyuºiji tedy toho, ºe notebook má dv¥ sí´ová rozhraní a £ást sít¥ tedy musí být bezdrátová. To p°iná²í navíc latenci, kterou následn¥ budeme korigovat, a moºnou zvý²enou ztrátovost. Rovn¥º k bezdrátové síti jsou p°ipojeny dal²í pracovní stanice, coº v p°ípad¥ jejich aktivity m·ºe neprediktivn¥ zvy²ovat latenci. Schéma zapojení výsledné testovací sít¥ je na obrázku 5.1. Pouºité po£íta£e mají následující konguraci:
•
Klientská stanice Intel Core i3 @2.4GHz (2 jádra, 4 vlákna), 4GB RAM, 640GB HDD
•
Router s limnetem Intel Atom N280 @1.66GHz (1 jádro, 2 vlákna), 1GB RAM, 160GB HDD
5.5.
39
NAVRENÍ TESTOVACÍCH ÚLOH
Internet
Test server
Limnet router
Test client
Local network
Obrázek 5.1: Zapojení testovací sít¥
•
Testovací server Intel Atom 330 @1.6GHz (2 jádra, 4 vlákna), 2GB RAM, 3TB HDD
Uvedené stroje mají primárn¥ jiné ur£ení, ale pro testování budou dosta£ující.
5.5 Navrºení testovacích úloh 5.5.1
Zm¥°ení parametr· sít¥ bez omezova£e
Nejprve je pot°eba zm¥°it vlastnosti testovací sít¥ bez za°azení omezova£e, abychom pozd¥ji mohli provád¥t podle t¥chto nam¥°ených hodnot korekci výsledk·. M¥°ené parametry jsou:
•
²í°ka pásma sm¥rem k serveru
•
²í°ka pásma sm¥rem k pracovní stanici
•
celkové zpoºd¥ní (oba sm¥ry)
•
celková ztrátovost (oba sm¥ry)
5.5.2
M¥°ení ²í°ky pásma
Abychom správn¥ ov¥°ili funk£nost omezení ²í°ky pásma, je t°eba tuto veli£inu m¥°it samostatn¥ bez za°azení dal²ích omezení, nebo´ ty mají také vliv na ²í°ku pásma. í°ku pásma m¥°íme v obou sm¥rech (k serveru i ke stanici).
40
KAPITOLA 5.
Parametr
Hodnota
í°ka pásma downloadu
18382.4 kbit/s
í°ka pásma uploadu
19531.3 kbit/s
Zpoºd¥ní
1.976 ms
Jitter
0.273 ms
Ztrátovost
0% (0/400)
TESTOVÁNÍ
Tabulka 5.1: Parametry testovací sít¥
5.5.3
M¥°ení ztrátovosti a zpoºd¥ní
Tyto vlastnosti m·ºeme m¥°it sou£asn¥, nebo´ se vzájemn¥ neovliv¬ují. M¥°ení provádíme nejprve zvlá²´ pro kaºdý sm¥r, pak pro omezení obou sm¥r· zárove¬.
5.5.4
M¥°ení ostatních parametr·
Ostatní parametry nastavitelné systémem limnet jsou vytvá°ení duplicit, po²kozování packet· a zm¥na po°adí packet·. Vzhledem k tomu, ºe se jedná o parametry, které nejsou v zadání práce, není t°eba je p°íli² testovat, posta£í ov¥°it jejich funk£nost. To provedeme tak, ºe zachytíme datový tok na klientské stanici a zárove¬ na serveru. K tomu m·ºeme vyuºít °adu nástroj·, nejjednodu²²í je pouºít program
tcpdump.
Záznam
po°ídíme následujícím p°íkazem s administrátorskými (rootovskými) právy:
tcpdump -i eth0 -w sniff.pcap Tento soubor m·ºeme následn¥ otev°ít a analyzovat nap°íklad programem
Wireshark.
Porovnáním obou záznam· prokáºeme funk£nost vý²e uvedených nastavení.
5.5.5
Testování scéná°·
Scéná°e vyuºívají stejné nastavení, které bylo testováno v p°edchozích testech. Zásadní je ov¥°it, ºe p°i zm¥n¥ t¥chto nastavení nedojde k p°eru²ení b¥ºících datových spojení.
5.6 Nam¥°ené hodnoty a vyhodnocení výsledk· 5.6.1
Parametry testovací sít¥
Bez za°azení omezova£e byly v síti nam¥°eny hodnoty z tabulky 5.1. Pro m¥°ení byla vyuºita sada 400 packet·. Jak je vid¥t z tabulky, v síti nedochází k ºádným ztrátám, proto p°i ztrátovosti nemusíme provád¥t ºádnou korekci. Jiná situace nastává p°i m¥°ení zpoºd¥ní. Pr·m¥rné zpoºd¥ní bylo nam¥°eno 3.112 ms, ale b¥hem testu se cekem 7 packet· vrátilo se zpoºd¥ním v¥t²ím, neº je 10-ti násobek pr·m¥rné hodnoty. Nejvy²²í zpoºd¥ní £inilo dokonce 127 ms. Tento jev lze vysv¥tlit tak, ºe b¥hem cesty t¥chto packet· byla sí´ (zejména její bezdrátová £ást) vyuºívána jinou stanicí. V tabulce je pak uvedena korigovaná hodnota zpoºd¥ní 1.976 ms.
5.6.
41
NAM
ENÉ HODNOTY A VYHODNOCENÍ VÝSLEDK
íslo testu
í°ka pásma [kb/s] Zpoºd¥ní [ms] Jitter [ms] Ztrátovost [%] down up down up down up down up
1
512
512
-
-
-
-
-
2
256
512
100
-
50
-
12
-
3
1024
512
-
100
-
50
-
12
4
1024
512
100
100
50
50
5
5
Tabulka 5.2: Nastavené parametry test·
íslo testu
í°ka pásma [kb/s] Zpoºd¥ní [ms] Jitter [ms] Ztrátovost [%] down up
1
477
470
2.021
0.298
0
2
170.3
466.4
102.513
49.955
10
3
947
190.6
102.188
49.606
12
4
166.7
174.6
201.356
87.494
12
Tabulka 5.3: Nam¥°ené parametry v testech
Tento test byl opakován n¥kolikrát a pokaºd¥ s tém¥° stejnými výsledky, proto je zde není t°eba uvád¥t. Z t¥chto d·vod· budeme p°i reprezentování výsledk· ignorovat n¥kolik packet·, které budou vykazovat zjevn¥ nesmyslné hodnoty. Ty budeme hledat na hladin¥ pravd¥podobnosti 5% normálního rozloºení. Dále pak budeme od nominálního zpoºd¥ní ode£ítat hodnotu zpoºd¥ní sít¥ bez omezova£e.
5.6.2
Nam¥°ené hodnoty s omezova£em
Dle vý²e uvedeného návrhu bylo provedeno n¥kolik test·. Nastavení jejich parametr· je uvedeno v tabulce 5.2. Nam¥°ené hodnoty v t¥chto testech jsou uvedeny v tabulce 5.3. Abychom eliminovali vliv nekvalitní sít¥ na m¥r¥ní, byla provedena korekce a korigované hodnoty jsou pak uvedeny v tabulce 5.4. Jak je vid¥t z nam¥°ených hodnot, nastavování zpoºd¥ní, jitteru a ztrátovosti funguje tém¥° dokonale. Trochu hor²í výsledky dává omezování ²í°ky pásma. Jelikoº jsem omezova£ HTB testoval je²t¥ b¥hem vývoje systému, vím ºe omezování dokáºe pracovat lépe (i kdyº
íslo testu
í°ka pásma [kb/s] Zpoºd¥ní [ms] Jitter [ms] Ztrátovost [%] down up
1
477
470
0.045
0.025
0
2
170.3
466.4
100.537
49.682
10
3
947
190.6
100.212
49.333
12
4
166.7
174.6
199.38
87.221
12
Tabulka 5.4: Korigované výsledky m¥°ení
42
KAPITOLA 5.
TESTOVÁNÍ
ne dokonale). Hor²í výsledky v tomto testu tedy p°ipisuji zejména bezdrátovému spoji v testovací síti. Dále je jasn¥ vid¥t, ºe se ²í°ka pásma p°i zavedení ztrátovosti rapidn¥ sniºuje. To je zp·sobeno tím, ºe ztracená data je pot°eba opakovat a tudíº znovu vyuºít pásmo, které by v opa£ném p°ípad¥ bylo jiº k dispozici. Z výsledk· m¥°ení m·ºeme také vid¥t, jak má nastavení ztrátovosti, zpoºd¥ní a jitteru stejný vliv na m¥°ení nástrojem
ping,
a´ je za°azeno v downloadu nebo v uploadu. To se
samoz°ejm¥ nem·ºe týkat ²í°ky pásma, pokud test nebude vypadat tak, ºe vezmeme n¥jaká data, která po²leme serveru a ten je v záp¥tí po²le zp¥t.
5.6.3
Ov¥°ení vedlej²ích parametr·
Byly po°ízeny dva záznamy dle d°íve navrºeného postupu s nastavenými parametry vytvá°ení duplicit, po²kozování packet· a zm¥na po°adí packet·. Porovnáním t¥chto záznam· jsem ov¥°il funk£nost t¥chto nastavení.
5.6.4
Ov¥°ení funk£nosti scéná°·
Po spu²t¥ní stahování dlouhého souboru ze serveru byl zárove¬ spu²t¥n scéná°. Stahování souboru pokra£ovalo podle parametr· denovaných v tomto scéná°i. Na pr·b¥hu stahování byla jasn¥ vid¥t zm¥na t¥chto parametr·.
Kapitola 6
Záv¥r 6.1 Spln¥ní cíl· Dle zadání systém musí emulovat sí´, která omezuje ²í°ku pásma, zvy²uje zpoºd¥ní a ztrátovost. Takový systém byl navrºden, implementován a testován. Z výsledk· testování je patrná jeho funk£nost. Navrºené °e²ení spo£ívá v umíst¥ní speciálního routeru do cesty mezi pracovní stanici a server. Na tomto routru lze pak nastavovat parametry emulace. Krom¥ vý²e uvedeného nabízí router navíc moºnost vytvá°ení duplicitních packet·, po²kozování procházejících packet· a zm¥ny jejich po°adí. Tyto moºnosti byly implementovány, nebo´ tvarovací moduly pouºité pro nastavení pot°ebných parametr· umoº¬ují nastavovat i tyto parametry. P°ínos této práce je v tom, ºe pro cílovou skupinu vývojá°u dosud neexistovalo komplexní °e²ení, které by umoº¬ovalo nastavit na jaké síti má aplikace b¥ºet. Dosud existující °e²ení umoº¬ovala upravovat ve²kerý provoz (tedy nevhodné pro skupinu), p°ípadn¥ nepodporovala v²echna pot°ebná nastavení.
6.2 Doporu£ení pro nastavení sít¥ Sí´, ve které bude tento omezova£ provozován, by m¥la mít co moºná nejvy²²í ²í°ku pásma a naopak co nejniº²í zpoºd¥ní a ztrátovost. To je takové v²eobecné pravidlo, nebo´ omezova£ nenastavuje p°ímo parametry sít¥, ale jejich zm¥nu oproti sou£asné síti. Pokud se snaºíme simulovat sít¥ se ²patnými parametry (nap°. GPRS), není t°eba pro tuto simulaci n¥jak ²pi£ková sí´. Posta£í, pokud ²í°ka pásma dosáhne sou£tu jednotlivých ²í°ek pásma nastavených v simulaci, které budou vyuºívány paraleln¥, a p°idáme 10% rezervu pro moºné výkyvy rychlosti. Podobné vlastnosti platí i pro latenci a ztrátovost. Pokud se snaºíme simulovat sí´ se zpoºd¥ním n¥kolika set milisekund, mohou pro nás být jednotky milisekund zanedbatelné. Samoz°ejm¥ platí, ºe p°esn¥j²í simulace dosáhneme, pokud si dop°edu zm¥°íme vlastnosti sít¥ a tyto hodnoty následn¥ promítneme do nastavení simulace. P°edpokládám, ºe pro v¥t²inu simulací posta£í b¥ºná lokální sí´ ethernet.
43
44
KAPITOLA 6.
ZÁV
R
6.3 Zabezpe£ení Systém v sou£asném stavu nijak nep°ihlíºí k zabezpe£ení kongura£ního rozhraní. Je tedy moºné otev°ít nastavení z lokální sít¥ i p°es WAN rozhraní a do systému není ºádný omezený p°ístup. Zp·sob moºného zabezpe£ení v sou£asném stavu spo£ívá v nastavení webového serveru. Prost°edníctvím toho m·ºeme dosáhnout znep°ístupn¥ní systému z WAN rozhraní stejn¥ jako nastavení hesla pro p°ístup k administraci. Nejjednodu²²í varianta vytvo°ení hesla je pouºití soubor·
.htaccess
a
.htpasswd
6.4 Moºný rozvoj systému •
zlep²ení zabezpe£ení zavedení uºivatelskýh ú£t·
moºnost nastavení parametr· pouze pro IP adresy p°idruºené k uºivatelskému ú£tu
editace scéná°· pouze pro zvolené uºivatele nastavení routeru pouze pro správce
•
lokalizace
•
dle pot°eby import z dal²ích typ· soubor·
•
vytvo°ení instala£ního balí£ku
•
moºnost logování do souboru
6.5 Zapojení bez zm¥ny infrastruktury sít¥ Výsledné °e²ení vyºaduje vloºení routeru mezi klientskou stanici a server. Pokud takový zásah nem·ºeme provést, existuje moºnost p°ipojit ob¥ rozhraní routeru do lokální sít¥, samoz°ejm¥ na t¥chto rozhraních mít IP adresy z ruzných rozsah· sít¥ tak, aby se vzájemn¥ neovliv¬ovaly. Pak sta£í na klientské stanici p°ipojené do lokální sít¥ zm¥nit IP adresu do nového rozsahu (podle LAN rozhraní routeru) a jako bránu zvolit LAN rozhraní routeru. Toto °e²ení by m¥lo fungovat, osobn¥ jsem jej i vyzkou²el, ale nepovaºuji ho za vhodné, nebo´ míchá dv¥ r·zné podsít¥ v rámci jednoho segmentu, a proto ho nedoporu£uji. ist¥j²í varianta tohoto °e²ení vyuºívá VLAN, to v²ak p°edpokládá, ºe v síti je umíst¥n switch, který VLAN podporuje. Pak sta£í od sebe odd¥lit provozy, které mají být za routerem a ty ostatní.
Literatura [1]
HTB Home
qos/htb/>.
[2]
[online]. [cit. 24. 12. 2011]. Dostupné z:
MasterShaper - MasterShaper
[online]. [cit. 24. 12. 2011].
mastershaper.org/index.php/MasterShaper>. [3]
netem | The Linux Foundation
Dostupné z:
[online]. [cit. 24. 12. 2011]. Dostupné z:
linuxfoundation.org/collaborate/workgroups/networking/netem>. [4]
NetLimiter - Ultimate Bandwidth Shaper
//www.netlimiter.com/>. [5]
NIST Net Home Page
[online]. [cit. 24. 12. 2011]. Dostupné z:
Dostupné z:
[online]. [cit. 24. 12. 2011].
nist.gov/nistnet/>.
[6]
squid : Optimising Web Delivery squid-cache.org/>.
[7]
Wonder Shaper
[online].
[cit.
[online]. [cit. 24. 12. 2011]. Dostupné z:
24. 12. 2011].
Dostupné
wondershaper/>.
[8]
Simple, classless Queueing Disciplines
z:
[online]. [cit. 24. 12. 2011]. Dostupné z:
//lartc.org/howto/lartc.qdisc.classless.html>. [9]
Dummynet home page
[online]. [cit. 24. 12. 2011].
unipi.it/~luigi/dummynet/>.
[10]
Dostupné z:
jQuery: The Write Less, Do More, JavaScript Library
[online]. [cit. 27. 12. 2011]. Dos-
tupné z: .
[11] CIBULKA, V. Diplomová práce M¥°ení kvality GSM sítí, 2012. [12] KELLER, A.
Manual tc Packet Filtering and netem
[online]. 2006. [cit. 25. 12. 2011].
Dostupné z: .
45
46
LITERATURA
P°íloha A
Seznam pouºitých zkratek AJAX
Asynchronous JavaScript and XML
Bash
Bourne-again shell
BSD
Berkeley Software Distribution
CBQ
Class Based Queueing
CD
Compact Disc (Kompaktní disk)
CSV
Comma-separated values
DHCP DNS
Dynamic Host Conguration Protocol
Domain Name System
down
Download
GPRS GUI
General Packet Radio Service
Graphical user interface
HDD
Hard disk drive
HTB
Hierarchical Token Bucket
HW
Hardware
ICMP IFB IP
Internet Control Message Protocol
Intermediate Functional Block
Internet Protocol
ISO
International Organization for Standardization
GSM
Global System for Mobile Communications, p·vodn¥ Groupe Spécial Mobile
LAN
Local Area Network
47
48
PÍLOHA A.
NAT OS
Operating system (Opera£ní systém)
OSI PC
Network address translation
Open Systems Interconnection Personal computer (Osobní po£íta£)
Qdisc
Queueing Discipline
RAM
Random-access memory
RMI
Remote Method Invocation
SFQ
Stochastic Fairness Queuing
TBF
Token Bucket Filter
TCP
Transmission Control Protocol
UDP
User Datagram Protocol
up
Upload
URL
Uniform Resource Locator
VLAN W3C
Virtual LAN
World Wide Web Consortium
WAN
Wide Area Network
WFQ
Weighted Fairness Queuing
WLAN XCF
Wireless LAN
eXperimental Computing Facility
SEZNAM POUITÝCH ZKRATEK
P°íloha B
Instala£ní a uºivatelská p°íru£ka B.1 Instala£ní p°íru£ka UPOZORN
Í: V¥t²ina dále popsaných krok· vyºaduje administrátorská práva.
B.1.1
Poºadavky na systém
•
distribuce Debian nebo její odnoº
•
jádro 2.6.16 nebo nov¥j²í
•
podpora Advanced router, HTB a Netem v jád°e
•
nainstalované balí£ky
apache2, php5, libapache2-mod-php5, php5-mysql, mysqlserver, mysql-client
B.1.2
Zkopírujte data
Nyní je t°eba zkopírovat adresá° limnet do cílového umíst¥ní. Výchozí adresá° je
/opt.
Tato
cesta bude uvád¥na i v dal²ích £ástech návodu. Pokud zvolíte jinou, je t°eba to brát v úvahu a adekvátn¥ upravovat i níºe uvedené cesty.
B.1.3
Nastavení sít¥
Nastavení sít¥ (zejména LAN a WAN rozhraní) musí být °ádn¥ provedeno v souborech
/etc/network/interfaces
B.1.4
a
/etc/resolv.conf.
Vytvo°te databázi v MySQL
Pro vytvo°ení databáze slouºí skript
/opt/limnet/init/limnet.sql. Tento soubor sta£í do
databáze importovat následujícím p°íkazem (z init adresá°e):
mysql -h localhost -u mysql_user --password="password" < ./limnet.sql
49
50
PÍLOHA B.
B.1.5
INSTALANÍ A UIVATELSKÁ PÍRUKA
Vytvo°te konguraci webserveru
Nastavte webserver tak, aby byla p°ístupná stránka umíst¥ná v
/opt/limnet/www.
Pokud
chcete, nastavte ke stránce p°ístup s heslem. Rozhraní je psáno v jazyce PHP, proto modul php5 musí být povolen ve webserveru.
B.1.6
Sudoers záznam pro limnet
Limnet musí b¥ºet se správcovskými právy. K tomu vyuºívá p°íkaz sudo. Je proto pot°eba zajistit, aby bylo moºné jej z webového rozhraní spustit s t¥mito právy bez hesla. K tomu slouºí soubor
/etc/sudoers.
Zde uvedeme, ºe skript limnet smí uºivatel, pod kterým b¥ºí
webové rozhraní, spou²t¥t s administrátorskými právy bez zadání hesla. P°edpokládejme výchozího uºivatele
www-data, pak záznam v sudoers m·ºe vypadat následovn¥:
www-data ALL=(ALL) NOPASSWD: /opt/limnet/limnet
B.1.7
Kongurace limnetu
Kongurace je rozd¥lena do dvou soubor·. První £ást je p°ímo v limnet skriptu
/opt/limnet/limnet.
Jedná se o prvních n¥kolik
°ádk·. Nejd·leºit¥j²í je nastavit p°ístup do databáze (tedy uºivatelské jméno a heslo, p°ípadn¥ stanici, pokud chceme pouºívat vzdálenou databázi), názvy sí´ových rozhraní LAN a WAN a pokud jsme zm¥nili výchozí instala£ní cestu, tak i tu. Druhá £ást je v souboru
/opt/limnet/www/inc/config.php. Zde je t°eba nastavit hlavn¥
p°ístup do databáze, základní url (podle kongurace webserveru, v¥t²inou bývá /) a pokud jsme zm¥nili instala£ní cestu, tak i tu.
B.1.8
Uloºení nastavení sít¥ do databáze
Nastavení sít¥ v databázi je d·vod, pro£ musí být sí´ °ádn¥ nastavena v kongura£ních souborech. Jediný zp·sob, jak toto správn¥ udelat, je spustit následující p°íkaz:
/opt/limnet/limnet router init Tento p°íkaz na£te kongura£ní soubory a pot°ebná nastavení uloºí do databáze.
B.1.9
Automatické spu²t¥ní systému
Zajist¥te, aby byl systém spu²t¥n automaticky po spu²t¥ní opera£ního systému. Toho lze docílit nap°íklad z rc skript·. Nap°íklad do souboru
/opt/limnet/limnet start
/etc/rc.local
doplníme °ádek
B.2.
51
UIVATELSKÁ PÍRUKA
B.2 Uºivatelská p°íru£ka B.2.1
Ovládání z p°íkazového °ádku
Systém lze ovládat z p°íkazového °ádku pomocí limnet skriptu. Tento skript je p°i výchozí instalaci umíst¥n jako
/opt/limnet/limnet.
Pro p°íkazové rozhraní budeme p°edpokládat,
ºe p°íkazy budeme spou²t¥t z adresá°e, kde je tento skript umíst¥n. D·leºité je si uv¥domit, ºe lze nastavit pravidlo, které bude tvarovat provoz od routeru ke klientské stanici (download) a p°i vzdáleném p°ipojení m·ºe omezovat toto p°ipojení.
Základní p°íkazy ./limnet ./limnet ./limnet ./limnet ./limnet ./limnet ./limnet
start stop restart status rules statistics version
# # # # # # #
spu²t¥ní systému zastavení systému restart systému zobrazí, zda systém b¥ºí zobrazí pravidla tvarování p°íkazu tc zobrazí podrobnosti u jednotlivých pravidel zobrazí verzi limnet skriptu
Nastavení sít¥ ./limnet router current wanip # zobrazí adresu IP WAN ./limnet router current lanip # zobrazí adresu IP LAN ./limnet router set \ wantype [wan_type] \ wanip [wan_ip_address] \ wanmask [wan_mask] \ gw [default_gateway] \ dns [dns_server_1] \ dns [dns_server_2] \ dns [dns_server_3] \ lanip [lan_ip_address] \ lanmask [lan_mask] Význam jednotlivých parametr·:
•
wan_type typ p°ipojení wan (dhcp automaticky, static ru£n¥), p°i dhcp jsou ostatní wan parametry ignorovány
•
wan_ip_address IP adresa rozhraní WAN
•
wan_mask Maska rozraní WAN (formát IP adresy)
•
default_gateway Výchozí brána
•
dns_server_1 IP adresa DNS serveru, obdobn¥ dns_server_2 a dns_server_3
•
lan_ip_address IP adresa rozhraní LAN
52
PÍLOHA B.
•
INSTALANÍ A UIVATELSKÁ PÍRUKA
lan_mask Maska rozhraní LAN (formát IP adresy)
Nastavení sít¥ zp·sobí nejen zm¥nu parametr· v b¥ºícím systému, ale taktéº exportuje kongura£ní soubory, aby se nastavení udrºelo i po restartu systému.
Nastavení tvarovacích pravidel Kaºdé pravidlo je ur£eno unikátní kombinací zdrojové IP adresy, zdrojového portu, cílové IP adresy a cílového portu. Z tohoto vý£tu je vºdy povinné uvést alespo¬ zdrojovou adresu. Pokud nap°íklad uvedeme pouze zdrojovou IP adresu, bude toto pravidlo ovliv¬ovat v²echny datové toky, ve kterých guruje tato adresa. U cílové adresy m·ºeme uvést navíc i masku jako po£et bit· adresy sít¥ (tedy nap°. 66.109.54.0/24). Tím lze ur£it celou podsí´ cílových stanic. Pravidla je moºné p°idávat, m¥nit a mazat. Pro p°idávání a zm¥nu pravidla je t°eba uvést kombinaci, kterou je/bude pravidlo ur£eno a následn¥ parametry, které ur£ují vlastnosti tvarování. Pro mazání pravidla je t°eba uvést pouze ur£ení pravidla. Jakékoliv ostatní uvedené argumenty budou ignorovány. Syntaxe je následující:
./limnet rule par1 val1 [par2 val2 [par3 val3 ...]] P°íkaz
command m·ºe nabývat hodnot:
•
add p°idat pravidlo
•
change upravit pravidlo
•
del smazat pravidlo
Kaºdý parametr
parN má hodnotu valN a m·ºe být z následujícího seznamu:
•
srcip zdrojová IP adresa
•
srcport zdrojový port
•
dstip cílová IP adresa, m·ºe obsahovat masku
•
dstport cílový port
•
down rychlost stahování [kb/s]
•
loss ztrátovost p°i downloadu [%]
•
losscorr korelace ztrátovosti downloadu [%]
•
delay zpoºd¥ní downloadu [ms]
•
jitter jitter downloadu [ms]
•
duplicate mnoºství duplicit v downloadu [%]
B.2.
53
UIVATELSKÁ PÍRUKA
•
corrupt mnoºství po²kozených packet· v downloadu [%]
•
reorder mnoºství packet· se zm¥n¥ným po°adím v downloadu [%]
•
reordercorr korelace zm¥n po°adí p°i downloadu [%]
•
up rychlost uploadu [kb/s]
•
uploss ztrátovost uploadu [%]
•
uplosscorr korelace ztrátovosti uploadu [%]
•
updelay zpoºd¥ní uploadu [ms]
•
upjitter jitter uploadu [ms]
•
upduplicate mnoºství duplicit v uploadu [%]
•
upcorrupt mnoºství po²kozených packet· v uploadu [%]
•
upreorder mnoºství packet· se zm¥n¥ným po°adím v uploadu [%]
•
upreordercorr korelace zm¥n po°adí p°i uploadu [%]
B.2.2
Ovládání p°es webové rozhraní
Ovládání p°es webové rozhraní poskytuje v¥t²í pohodlí, p°edn¥ je v²ak d·leºité p°ihlédnout k tomu, ºe lze omezit download tak, ºe toto rozhraní bude omezováno. Stránky jsou rozd¥leny na t°i základní £ásti, které lze otev°ít z nabídky umíst¥né v horní £ásti obrazovky pod grackým pruhem.
Nastavení tvarovacích pravidel Pravidla se nastavují v sekci Rules.
Ur£ení pravidel je shodné, jako v p°ípad¥ ovládání
p°íkazovou °ádkou. Lze vytvo°it nové pravidlo odkazem Create new rule, upravit odkazem modify vedle daného pravidla, p°ípadn¥ vedle umíst¥ným odkazem delete toto pravidlo smazat. P°i vytvá°ení a úprav¥ scéná°· sta£í vyplnit zobrazené kolonky a potvrdit formulá°. Povinné údaje jsou: zdrojová IP adresa, rychlost downloadu a rychlost uploadu. Zde lze také spustit scéná° nad daným pravidlem. To se provádí odkazem start scenario u daného pravidla. Pravidlo vybíráme kv·li volb¥ datového toku, nad kterým budeme scéná° provᤥt. To je také jediný d·vod, pro£ je odkaz umíst¥n u pravidla. Po kliknutí na tento odkaz se zobrazí seznam scéná°·, kdy u kaºdého je odkaz select. Tímto odkazem vybereme, který scéná° chceme spustit. Pak uº se zobrazí obrazovka, na které je rozepsaný daný scéná° a pravidla, podle kterých bude vybrán datový tok. Ve spodní £ásti stránky jsou pak tla£ítka Start a Stop. Ta slouºí ke spu²t¥ní, respektive k zastavení daného scéná°e. Pokud scéná° dob¥hne nebo je zastaven, jsou na vybraný datový tok aplikována p·vodní pravidla, která byla nastavena p°ed spu²t¥ním scéná°e. To neplatí, pokud scéná° není ukon£en (zm¥na stránky nebo zav°ení prohlíºe£e). V takovém p°ípad¥ z·stávají pro datový tok pravidla platná v dob¥, kdy bylo provád¥ní scéná°e p°eru²eno.
54
PÍLOHA B.
INSTALANÍ A UIVATELSKÁ PÍRUKA
Editace scéná°· Scéná°e se editují v sekci
Scenarios.
Kaºdý scéná° má t°i základní vlastnosti. První je
jméno, které musí být v rámci systému unikátní. Druhým je popis, který je volitelný, a t°etím je opakování, které ur£uje, ºe scéná° po dob¥hnutí na konec za£ne znovu od za£átku. Vytvá°et scéná°e lze na této stránce odkazem Create new scenario nebo importovat z CSV soubor· odkazem Import new scenario from CSV. Pak je zde zobrazen seznam existujících scéná°·, kdy lze kaºdý z nich smazat odkazem delete, p°ípadn¥ zobrazit obsah/upravit odkazem detail. P°i vytvá°ení nového scéná°e se vºdy musí vyplnit základní vlastnosti. P°i importu ze souboru se navíc p°iloºí tento soubor. Dále se dostáváme k prohlíºení/editaci scéná°e. Kaºdý scéná° obsahuje seznam pravidel v ur£eném po°adí. Tato pravidla (oproti statické variant¥) obsahují navíc délku trvání pravidla. Editace seznamu pravidel probíhá práv¥ ze stránky s detailem scéná°e. Na této stránce tedy lze p°epsat a uloºit základní vlastnosti scéná°e a upravovat seznam jeho pravidel. P°idat nové pravidlo lze odkazem Add new rule. S kaºdým existujícím pravidlem pak lze provád¥t následující operace: smazat (odkaz delete), upravit (odkaz modify), zm¥nit po°adí p°esunout nahoru (odkaz up) a dolu (odkaz down).
Nastavení sít¥ Pro nastavení sít¥ slouºí sekce
Router. Zde lze nastavit IP adresy jednotlivým rozhraním.
P°i zm¥n¥ IP adresy rozhraní, p°es které p°istupujeme k webové aplikaci, se vygeneruje odkaz na novou URL webové aplikace. To bohuºel neplatí p°i p°ístupu p°es WAN a jeho nastavení na DHCP vzhledem k tomu, ºe nová IP adresa není dop°edu známa. Z t¥chto d·vod· se p°edpokládá, ºe IP adresa nebude zm¥n¥na, coº ve výjme£ných situacích m·ºe zp·sobit, ºe na£ítání stránky zapo£ne, ale uº není dokon£eno z d·vodu zm¥ny IP adresy.
P°íloha C
Obsah p°iloºeného CD csv export_20111227022414.csv test1_complete.csv test2_mandatory.csv test3_empty.csv test4_broken.csv limnet COPYING init limnet.sql INSTALL limnet templates interfaces resolv.conf www ajax.php css screen.css gfx top.jpg inc config.php db.php error.php funcs.php menu.php router.php rules.php scenario.php scenarios.php stopped.php index.php js jquery.js jscript.js
testovací soubory CSV pro import export z aplikace BandWidth Test testovací soubor - vše vyplněné testovací soubor - vyplněné jen povinné údaje testovací soubor - prázdný soubor testovací soubor - obsahuje jeden chybný záznam systém limnet licence GPLv3 složka s inicializačními daty inicializační skript návod k instalaci limnet skript šablony konfiguračních souborů konfigurace síťových rozhraní konfigurace DNS serverů webová aplikace rozhraní pro AJAX requesty kaskádové styly základní kaskádový styl grafické soubory horní grafický pruh vnitřně užívané PHP soubory konfigurace PHP aplikace funkce pro práci s databází šablona pro renderování chyb vnitřně užívané funkce šablona pro renderování nabídky šablona pro renderování sekce Router šablona pro renderování sekce Rules šablona pro renderování spuštění scénářů šablona pro renderování editace scénářů šablona pro případ vypnutého systému limnet hlavní vstupní soubor webové aplikace javascripty knihovna jquery soubor s javascripty
Obrázek C.1: Obsah p°iloºeného CD 1. £ást
55
56
PÍLOHA C.
resources cisco_back.jpg diagrams leaky_bucket.dia loc1_client.dia loc2_server.dia loc3_router.dia loc4_pc.dia loc4_pc2.dia loc5_proxy.dia test_network.dia token_bucket.dia http_logo.xcf klavesnice.jpg switch_hp.jpg top.xcf text Myska-thesis-2012.pdf source csplainnat.bst figures leaky_bucket.pdf loc1_client.pdf loc2_server.pdf loc3_router.pdf loc4_pc.pdf loc4_pc2.pdf loc5_proxy.pdf LogoCVUT.pdf mastershaper.jpg netlimiter.png nistnet.png scr10_router_settings.png scr1_rules_list.png scr2_add_rule.png scr3_start_scenario.png scr4_scenario_running.png scr5_scenarios_list.png scr6_scenario_detail.png scr7_modify_scenario_rule.png scr8_import_csv.png scr9_new_scenario.png seznamcd_part1.pdf seznamcd_part2.pdf test_network.pdf token_bucket.pdf hyphen.tex k336_thesis_macros.sty Makefile Myska-thesis-2012.tex reference.bib readme.txt
OBSAH PILOENÉHO CD
zdrojové soubory grafických prací fotografie switche Cisco v provozu adresář s diagramy programu Dia schéma algoritmu Leaky Bucket umístění omezovače na klientu umístění omezovače na serveru umístění omezovače na routeru umístění omezovače na vloženém PC - varianta 1 umístění omezovače na vloženém PC - varianta 2 umístění omezovače na proxy serveru schéma testovací sítě schéma algoritmu Token Bucket zdrojová grafika http loga - formát GIMP fotografie klávesnice fotografie naaranžovaného switche HP zdrojová grafika horního pruhu webové aplikace - formát GIMP text diplomové práce text v elektronické podobě, připraven k tisku zdrojové soubory textové práce formát referencí grafikcké soubory algoritmus Leaky Bucket umístění omezovače na klient umístění omezovače na server umístění omezovače na router umístění omezovače na vložené PC - varianta 1 umístění omezovače na vložené PC - varianta 2 umístění omezovače na router logo ČVUT screenshot aplikace MasterShaper screenshot aplikace NetLimiter screenshot aplikace NIST Net screenshot z limnetu - Nastavení routeru screenshot z limnetu - Seznam pravidel screenshot z limnetu - Přidání pravidla screenshot z limnetu - Výběr scénáře ke spuštění screenshot z limnetu - Běžící scénář screenshot z limnetu - Seznam scénářů screenshot z limnetu - Detail scénáře screenshot z limnetu - Úprava pravidla scénáře screenshot z limnetu - Import ze souboru CSV screenshot z limnetu - Přidání scénáře tento seznam - 1. část tento seznam - 2. část schéma testovací sítě schéma algoritmu Token Bucket definice rozdělení slov marka diplomové práce script pro snadnou kompilaci zdrojový kód textu diplomové práce seznam referencí popis obsahu CD
Obrázek C.2: Obsah p°iloºeného CD 2. £ást