Pocˇıtacˇove´ sıteˇ a decentralizovane´ syste´my

Pocˇıtacˇove´ sıteˇ a decentralizovane´ syste´my

Šárka Vavrečková
Počı́tačové sı́tě
a decentralizované
systémy
pro magisterský stupeň
studia
Slezská univerzita v Opavě
Filozoficko-přı́rodovědecká fakulta
Ústav informatiky
Opava, poslednı́ aktualizace 4. června 2015
Anotace: Tato skripta jsou určena pro studenty předmětu Počı́tačové sı́tě a decentralizované systémy. Předpokládajı́ alespoň základnı́ znalosti v oblasti počı́tačových sı́tı́,
navazujeme na předmět Počı́tačová sı́t’a Internet na bakalářském stupni studia.
Počı́tačové sı́tě a decentralizované systémy
RNDr. Šárka Vavrečková, Ph.D.
Dostupné na: http://fpf.slu.cz/~vav10ui/sitedec.html
Ústav informatiky
Filozoficko-přı́rodovědecká fakulta
Slezská univerzita v Opavě
Bezručovo nám. 13, 746 01 Opava
Sázeno v systému LATEX
Tato inovace předmětu Počı́tačové sı́tě a decentralizované systémy je spolufinancována Evropským
sociálnı́m fondem a Státnı́m rozpočtem ČR, projekt č. CZ.1.07/2.3.00/09.0197, „Posı́lenı́ konkurenceschopnosti výzkumu a vývoje informačnı́ch technologiı́ v Moravskoslezském kraji“.
Předmluva
Co najdeme v těchto skriptech
Tato skripta jsou určena pro studenty informatických oborů na Ústavu informatiky Slezské univerzity v Opavě, a to na magisterském stupni.
Záběr skript je velmi široký. Přesto, že v předmětu máme pouze přednášky, najdeme zde
i přı́klady, zejména v oblasti sı́t’ových funkcı́ v operačnı́ch systémech Windows a Linux. Některé
přı́klady jsou vloženy přı́mo do textu, ale většina je zařazena do přı́loh B a C.
Některé oblasti jsou také „navı́c“ (jsou označeny ikonami fialové barvy), ty nejsou probı́rány
a ani se neobjevı́ na testech – jejich úkolem je motivovat k dalšı́mu samostatnému studiu nebo
pomáhat v budoucnu při zı́skávánı́ dalšı́ch informacı́ dle potřeby v zaměstnánı́.
Předpokládáme, že studentům ještě zůstalo něco ze znalostı́ nabytých v bakalářském studiu
(předmět Počı́tačová sı́t’a Internet). Přesto se předměty částečně překrývajı́, protože pamět’studentů
je děravá a je to přece tak dávno :-).
Značenı́
Ve skriptech se použı́vajı́ následujı́cı́ barevné ikony:
• Nové pojmy, názvy souborů, obecné postupy, použı́vané symboly, apod. jsou značeny modrým symbolem v poznámce na okraj, který vidı́me také zde vpravo.
P
• Konkrétnı́ postupy a nástroje (přı́kazy, programy, soubory, skripty), způsoby řešenı́ různých
situacı́, do kterých se může administrátor dostat, syntaxe přı́kazů atd. jsou značeny také
modrou ikonou.
$
• Zvlášt’ je také vyznačen text, který je obvykle výstupem probı́raných přı́kazů (včetně těch,
jejichž spuštěnı́ vyžaduje vyššı́ přı́stupová oprávněnı́) nebo může jı́t o obsah některých souborů. Barva ikony je oranžová.
M
iii
iv
• V některých přı́padech si lze vybrat určitý počet z několika možnostı́, nenı́ třeba se učit
vše. Napřı́klad v prvnı́ kapitole se studenti nemusı́ učit všechny standardizačnı́ instituce, ale
vyberou si jen některé z nich.
• Některé části textu jsou označeny fialovou ikonou, což znamená, že jde o nepovinné úseky,
které nejsou probı́rány (většinou; studenti si je mohou podle zájmu vyžádat nebo sami prostudovat). Jejich účelem je dobrovolné rozšı́řenı́ znalostı́ studentů o pokročilá témata, na která
obvykle při výuce nezbývá moc času.
• Žlutou ikonou jsou označeny odkazy, na kterých lze zı́skat dalšı́ informace o tématu. Může jı́t
o způsoby zı́skánı́ nápovědy, nejčastěji však u této ikony najdeme odkazy na internet.
• Červená je ikona pro upozorněnı́ a poznámky.
Opticky jsou odlišeny také řešené přı́klady a neřešené úlohy.
Přı́klad
Takto vypadá prostředı́ s přı́kladem. Nejvı́c přı́kladů najdeme v přı́lohách B (Windows) a C (Linux).
Úkoly
Otázky a úkoly, náměty na vyzkoušenı́, které se doporučuje při procvičovánı́ učiva provádět, jsou
uzavřeny v tomto prostředı́. Pokud je v prostředı́ vı́ce úkolů, jsou čı́slovány.
Na stránkách předmětu je k dispozici orientačnı́ seznam otázek a úkolů, které se mohou objevit na
zkouškové pı́semce, ovšem v pı́semce se mohou objevit mı́rné odlišnosti.
J
L
Obsah
1
2
Základnı́ pojmy a nástroje
1.1 Standardizačnı́ instituce . . . . . . . . . . .
1.2 Adresovánı́ . . . . . . . . . . . . . . . . . . .
1.2.1 Typy adres . . . . . . . . . . . . . . .
1.2.2 Mapovánı́ adres . . . . . . . . . . . .
1.3 Model TCP/IP . . . . . . . . . . . . . . . . .
1.3.1 Vrstvy . . . . . . . . . . . . . . . . .
1.3.2 Vrstva sı́t’ového rozhranı́ . . . . . . .
1.3.3 Protokoly sı́t’ové vrstvy . . . . . . .
1.3.4 Protokoly transportnı́ vrstvy . . . .
1.3.5 Protokoly aplikačnı́ vrstvy . . . . . .
1.4 Sady protokolů . . . . . . . . . . . . . . . .
1.5 Protokol IPv4 . . . . . . . . . . . . . . . . .
1.5.1 IPv4 datagramy . . . . . . . . . . . .
1.5.2 Adresy IPv4 . . . . . . . . . . . . . .
1.5.3 Překlad adres . . . . . . . . . . . . .
1.5.4 Adresy podsı́tě . . . . . . . . . . . .
1.5.5 Jak stanice může zı́skat IPv4 adresu
1.6 Protokol IPv6 . . . . . . . . . . . . . . . . .
1.6.1 IPv6 datagramy . . . . . . . . . . . .
1.6.2 Adresy IPv6 . . . . . . . . . . . . . .
1.6.3 Jak stanice může zı́skat IPv6 adresu
1.6.4 Zóny . . . . . . . . . . . . . . . . . .
1.6.5 ICMPv6 a NDP . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
1
3
3
4
5
6
8
9
12
17
18
18
18
21
23
25
28
29
30
32
33
36
37
Ethernet
2.1 Základnı́ pojmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Co je to Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
39
39
39
v
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vi
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
41
43
43
45
45
46
47
47
48
49
50
50
51
53
54
56
56
57
58
58
59
59
.
.
.
.
.
.
.
.
.
.
.
60
60
60
61
61
62
62
63
63
64
65
65
WAN sı́tě
4.1 Spojové protokoly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 HDLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.2 LAP protokoly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
67
67
69
2.2
2.3
2.4
2.5
3
4
2.1.2 Sı́t’ové prvky . . . . . . . . . . . . . . . .
2.1.3 Linková vrstva . . . . . . . . . . . . . .
Přenosové techniky . . . . . . . . . . . . . . . .
2.2.1 Zajištěnı́ přenosu pro polovičnı́ duplex
2.2.2 Zajištěnı́ přenosu pro plný duplex . . .
2.2.3 Zajištěnı́ přijetı́ dat . . . . . . . . . . . .
2.2.4 VLAN . . . . . . . . . . . . . . . . . . .
Fyzická vrstva . . . . . . . . . . . . . . . . . . .
2.3.1 NIC . . . . . . . . . . . . . . . . . . . . .
2.3.2 Kódovánı́ signálu . . . . . . . . . . . . .
2.3.3 Fyzická vrstva v ISO/OSI modelu . . .
Standardy pro fyzickou vrstvu . . . . . . . . .
2.4.1 10Mb Ethernet . . . . . . . . . . . . . .
2.4.2 Fast Ethernet . . . . . . . . . . . . . . .
2.4.3 Gigabit Ethernet . . . . . . . . . . . . .
2.4.4 10Gb Ethernet . . . . . . . . . . . . . . .
Technologie . . . . . . . . . . . . . . . . . . . .
2.5.1 Křı́ženı́ . . . . . . . . . . . . . . . . . . .
2.5.2 Auto-negotitation . . . . . . . . . . . . .
2.5.3 Multiple-Rate Ethernet . . . . . . . . . .
2.5.4 PoE . . . . . . . . . . . . . . . . . . . . .
2.5.5 EFM . . . . . . . . . . . . . . . . . . . .
2.5.6 Metro Ethernet . . . . . . . . . . . . . .
Dalšı́ témata k lokálnı́m sı́tı́m
3.1 EtherChannel . . . . . . . . . . . . . . . . .
3.1.1 Vlastnosti . . . . . . . . . . . . . . .
3.1.2 Řı́zenı́ toku . . . . . . . . . . . . . .
3.1.3 Protokoly . . . . . . . . . . . . . . .
3.2 SAN sı́tě . . . . . . . . . . . . . . . . . . . .
3.2.1 Fibre Channel . . . . . . . . . . . . .
3.2.2 iSCSI . . . . . . . . . . . . . . . . . .
3.3 Virtuálnı́ lokálnı́ sı́t’– VLAN . . . . . . . . .
3.3.1 Členstvı́ ve skupině . . . . . . . . . .
3.3.2 Určenı́ členstvı́ . . . . . . . . . . . .
3.3.3 Zajištěnı́ komunikace mimo VLAN
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
vii
4.2
4.3
4.4
4.5
4.6
5
4.1.3 SLIP . . . . . . . . . . . . .
4.1.4 PPP . . . . . . . . . . . . . .
4.1.5 Rozšı́řenı́ PPP . . . . . . . .
4.1.6 IEEE 802.2 (LLC) . . . . . .
X.25 . . . . . . . . . . . . . . . . . .
4.2.1 Zařı́zenı́ v sı́ti . . . . . . . .
4.2.2 Adresy a navázánı́ spojenı́ .
4.2.3 Vrstvy a protokoly . . . . .
Frame Relay . . . . . . . . . . . . .
4.3.1 Zařı́zenı́ v sı́ti . . . . . . . .
4.3.2 Garance informačnı́ho toku
4.3.3 Spojová vrstva a adresace .
4.3.4 LMI . . . . . . . . . . . . . .
4.3.5 Tabulky na zařı́zenı́ch . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
70
70
71
72
72
73
73
74
75
75
76
77
78
79
4.3.6 Řešenı́ . . . . . . . . . . . . .
ATM . . . . . . . . . . . . . . . . . .
4.4.1 Zařı́zenı́ a cesty v sı́ti . . . . .
4.4.2 Buňky . . . . . . . . . . . . .
4.4.3 Architektura . . . . . . . . . .
4.4.4 QoS . . . . . . . . . . . . . . .
4.4.5 Adresace a navázánı́ spojenı́
4.4.6 ILMI . . . . . . . . . . . . . .
4.4.7 Spolupráce s LAN . . . . . .
MPLS . . . . . . . . . . . . . . . . . .
4.5.1 Přepı́nánı́ značek . . . . . . .
4.5.2 Směrovánı́ v MPLS . . . . . .
4.5.3 Vytvářenı́ cest . . . . . . . . .
4.5.4 Dalšı́ možnosti . . . . . . . .
Optické přenosové cesty . . . . . . .
4.6.1 SONET/SDH . . . . . . . . .
4.6.2 WDM a DWDM . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
79
81
81
82
83
86
87
89
89
90
90
91
93
94
94
94
95
.
.
.
.
.
.
.
96
96
96
97
97
98
100
100
Data a telekomunikačnı́ sı́tě
5.1 Dial-up technologie . . . . . . . . . . . . .
5.1.1 Shannonův teorém . . . . . . . . .
5.1.2 Telefonnı́ sı́t’ . . . . . . . . . . . . .
5.1.3 Přenos dat na telefonnı́ch linkách .
5.2 Modemy . . . . . . . . . . . . . . . . . . .
5.3 ISDN . . . . . . . . . . . . . . . . . . . . .
5.3.1 Princip ISDN . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
viii
5.4
5.5
5.6
6
7
5.3.2 BRI . . . . . . . . . . . . . . . . . .
Technologie xDSL . . . . . . . . . . . . . .
5.4.1 ADSL . . . . . . . . . . . . . . . . .
5.4.2 Implementace ADSL . . . . . . . .
5.4.3 ADSL na straně ISP . . . . . . . . .
5.4.4 Dalšı́ xDSL technologie . . . . . .
Telefonnı́ sı́tě a telefonnı́ ústředny . . . .
5.5.1 Slučovánı́ linek . . . . . . . . . . .
5.5.2 Telefonnı́ ústředny . . . . . . . . .
VoIP . . . . . . . . . . . . . . . . . . . . . .
5.6.1 Princip . . . . . . . . . . . . . . . .
5.6.2 Protokoly . . . . . . . . . . . . . .
5.6.3 Videotelefonie a videokonference .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Bezdrátové a mobilnı́ sı́tě
6.1 Bezdrátové technologie . . . . . . . . . . . . . . . . . . .
6.2 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.1 Základnı́ princip . . . . . . . . . . . . . . . . . .
6.2.2 Režimy . . . . . . . . . . . . . . . . . . . . . . . .
6.2.3 Fyzická vrstva v ISO/OSI, frekvenčnı́ spektrum
6.2.4 Struktura PHY, modulace . . . . . . . . . . . . .
6.2.5 Antény a MIMO . . . . . . . . . . . . . . . . . .
6.2.6 Podvrstva MAC . . . . . . . . . . . . . . . . . . .
6.2.7 Úvod do šifrovánı́ . . . . . . . . . . . . . . . . .
6.2.8 AAA . . . . . . . . . . . . . . . . . . . . . . . . .
6.2.9 Zabezpečenı́ Wi-Fi sı́tı́ . . . . . . . . . . . . . . .
6.2.10 Wi-fi čtvrté a páté generace . . . . . . . . . . . .
6.3 WiMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 Vlastnosti . . . . . . . . . . . . . . . . . . . . . .
6.3.2 Zařı́zenı́ . . . . . . . . . . . . . . . . . . . . . . .
6.4 Mobilnı́ technologie . . . . . . . . . . . . . . . . . . . . .
6.4.1 Prvnı́ generace (1G) . . . . . . . . . . . . . . . .
6.4.2 Druhá generace (2G) . . . . . . . . . . . . . . . .
6.4.3 Přechodová generace (2.5G) . . . . . . . . . . . .
6.4.4 Třetı́ generace (3G) . . . . . . . . . . . . . . . . .
6.4.5 Dalšı́ generace . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
100
101
101
103
105
106
108
108
109
110
110
111
113
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
115
115
116
116
118
119
121
125
127
129
131
135
136
137
137
138
139
139
139
140
141
142
Centralizovanost, decentralizovanost, distribuce
144
7.1 Pojmy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
7.1.1 Typy systémů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
7.1.2 Distribuované systémy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
ix
7.2
7.3
7.4
7.5
7.6
7.7
8
Bridging . . . . . . . . . . . . . . . . . . . . .
7.2.1 Most . . . . . . . . . . . . . . . . . . .
7.2.2 STP . . . . . . . . . . . . . . . . . . . .
Switching . . . . . . . . . . . . . . . . . . . . .
Routing . . . . . . . . . . . . . . . . . . . . . .
7.4.1 Směrovač . . . . . . . . . . . . . . . .
7.4.2 Směrovánı́ . . . . . . . . . . . . . . . .
7.4.3 Směrovacı́ algoritmy a protokoly . . .
7.4.4 RIP . . . . . . . . . . . . . . . . . . . .
7.4.5 IGRP a EIGRP . . . . . . . . . . . . . .
7.4.6 OSPF . . . . . . . . . . . . . . . . . . .
7.4.7 IS-IS . . . . . . . . . . . . . . . . . . .
7.4.8 EGP a BGP . . . . . . . . . . . . . . . .
7.4.9 Softwarový směrovač . . . . . . . . .
CESNET2 . . . . . . . . . . . . . . . . . . . . .
7.5.1 Multimediálnı́ přenosy . . . . . . . . .
7.5.2 Metacentrum, výpočetnı́ gridy . . . .
7.5.3 CESNET CSIRT, CERTS . . . . . . . .
QoS . . . . . . . . . . . . . . . . . . . . . . . .
7.6.1 Princip QoS . . . . . . . . . . . . . . .
7.6.2 DiffServ . . . . . . . . . . . . . . . . .
Jmenné a adresářové služby . . . . . . . . . .
7.7.1 Princip a struktura DNS . . . . . . . .
7.7.2 Dotazy v DNS . . . . . . . . . . . . . .
7.7.3 DNS záznamy a formát dotazu . . . .
7.7.4 Bezpečnost v DNS . . . . . . . . . . .
7.7.5 Adresářové služby a Active Directory
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Bezpečnost a správa sı́tı́
8.1 Bezpečnost v sı́tı́ch . . . . . . . . . . . . . . . . . . . . .
8.1.1 Typy útoků . . . . . . . . . . . . . . . . . . . . .
8.1.2 Zabezpečenı́ na jednotlivých vrstvách ISO/OSI
8.2 Sı́t’ový analyzátor . . . . . . . . . . . . . . . . . . . . . .
8.3 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3.1 Princip firewallu . . . . . . . . . . . . . . . . . .
8.3.2 Typy filtrovánı́ . . . . . . . . . . . . . . . . . . .
8.3.3 OpenWRT . . . . . . . . . . . . . . . . . . . . . .
8.4 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.4.1 IPSec VPN – na sı́t’ové vrstvě . . . . . . . . . . .
8.4.2 GRE a L2TP tunely . . . . . . . . . . . . . . . . .
8.4.3 SSL/TLS VPN . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
146
146
147
150
150
150
151
152
155
156
156
158
158
159
159
160
160
161
162
162
162
163
163
165
166
168
169
.
.
.
.
.
.
.
.
.
.
.
.
172
172
172
175
175
176
176
178
181
181
182
184
185
x
8.4.4 SSH . . . . . . . . . . . . . .
8.4.5 MPLS VPN . . . . . . . . .
8.5 Správa sı́tě . . . . . . . . . . . . . .
8.5.1 NMS . . . . . . . . . . . . .
8.5.2 ISO model řı́zenı́ sı́tě . . . .
8.5.3 Management v ISO/OSI . .
8.6 Management v TCP/IP . . . . . . .
8.6.1 SNMP . . . . . . . . . . . .
8.6.2 MIB-II . . . . . . . . . . . .
8.6.3 Použı́vánı́ protokolu SNMP
8.7 Syslog . . . . . . . . . . . . . . . . .
8.8 Monitorovánı́ sı́tě . . . . . . . . . .
8.8.1 Protokol RMON . . . . . .
8.8.2 Snort . . . . . . . . . . . . .
8.8.3 NetFlow . . . . . . . . . . .
8.9 WBEM . . . . . . . . . . . . . . . .
8.9.1 Princip WBEM . . . . . . .
8.9.2 WMI . . . . . . . . . . . . .
8.10 Dohledové systémy . . . . . . . . .
8.10.1 Nagios . . . . . . . . . . . .
8.10.2 Zabbix . . . . . . . . . . . .
8.10.3 OpenNMS . . . . . . . . . .
8.10.4 Zenoss . . . . . . . . . . . .
8.10.5 Cacti . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
185
186
188
188
189
190
190
190
192
195
196
199
199
201
202
203
203
205
207
207
208
208
208
209
Seznam doporučené literatury
211
Přı́lohy
213
A Co už bychom měli znát
A.1 Lokálnı́ sı́tě . . . . . . . . .
A.1.1 Vlastnosti spojů . .
A.1.2 Vlastnosti služeb .
A.1.3 Multiplexovánı́ . .
A.1.4 Přı́stupové metody
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
215
215
215
217
218
219
A.1.5 Řı́zenı́ toku dat v sı́ti . . . .
A.2 WAN sı́tě . . . . . . . . . . . . . . .
A.2.1 Okruhy . . . . . . . . . . . .
A.2.2 Komunikace v rozlehlé sı́ti
A.3 Model ISO/OSI . . . . . . . . . . .
A.3.1 Princip . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
219
220
220
221
222
222
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
xi
A.3.2 Pojmy . . . . . . . . . . . . .
A.3.3 Vrstvy . . . . . . . . . . . . .
A.3.4 PDU . . . . . . . . . . . . . .
A.4 IEEE 802 . . . . . . . . . . . . . . . .
A.4.1 Skupina standardů IEEE 802
A.4.2 IEEE 802.1 . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
B Práce s adresami a sı́těmi ve Windows
B.1 Problémy při použı́vánı́ přı́kazů ve Windows . . .
B.2 Soubory souvisejı́cı́ se sı́těmi . . . . . . . . . . . . .
B.3 Práce s adresami a sı́t’ovými kartami . . . . . . . .
B.3.1 Základnı́ práce s IP adresami – ipconfig
B.3.2 Překlad adres – arp a nslookup . . . . .
B.3.3 Směrovánı́ – route . . . . . . . . . . . . . .
B.3.4 Malá sı́t’a skupina (workgroup) . . . . . .
B.4 Testovánı́ a statistiky . . . . . . . . . . . . . . . . .
B.4.1 Testovánı́ cesty a průchodnosti . . . . . . .
B.4.2 Statistiky v netstatu . . . . . . . . . . . .
B.5 Služba WMI a program wmic . . . . . . . . . . . .
B.6 Firewall ve Windows . . . . . . . . . . . . . . . . .
B.7 Dalšı́ přı́kazy . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
C Práce s adresami a sı́těmi v Linuxu
C.1 Specializované distribuce . . . . . . . . . . . . . . . . . . . . .
C.2 Soubory souvisejı́cı́ se sı́těmi . . . . . . . . . . . . . . . . . . . .
C.3 Staršı́ přı́kazy pro práci s adresami . . . . . . . . . . . . . . . .
C.4 Mechanismus iproute2 (přı́kaz ip) – adresy, sı́t’, směrovánı́
C.4.1 Konfigurace sı́t’ového rozhranı́ a adres . . . . . . . . . .
C.4.2 Směrovánı́ a filtrovánı́ . . . . . . . . . . . . . . . . . . .
C.4.3 Objevovánı́ sı́tě . . . . . . . . . . . . . . . . . . . . . . .
C.4.4 Tunely . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.5 Překlad názvů . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.5.1 Název počı́tače . . . . . . . . . . . . . . . . . . . . . . .
C.5.2 Resolver a soubor resolv.conf . . . . . . . . . . . .
C.5.3 Testovánı́ DNS . . . . . . . . . . . . . . . . . . . . . . .
C.5.4 Zjistěnı́ informacı́ o doméně . . . . . . . . . . . . . . . .
C.6 Firewall v Linuxu . . . . . . . . . . . . . . . . . . . . . . . . . .
C.6.1 Princip firewallu . . . . . . . . . . . . . . . . . . . . . .
C.6.2 Základnı́ vnitřnı́ přı́kazy a parametry pro filtrovánı́ . .
C.6.3 SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
C.6.4 NAT a maškaráda . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
223
224
227
227
227
229
.
.
.
.
.
.
.
.
.
.
.
.
.
230
230
231
231
231
233
236
238
240
240
241
243
246
248
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
249
249
251
253
255
256
258
263
265
268
268
269
270
273
274
274
276
280
282
xii
C.6.5 Označovánı́ paketů
C.6.6 Skripty . . . . . . .
C.6.7 Uloženı́ změn . . .
C.7 Testovánı́ a statistiky . . .
C.7.1 Základnı́ nástroje .
C.7.2 Pokročilé testovánı́
C.8 Vzdálený přı́stup . . . . .
C.9 Dalšı́ přı́kazy . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
284
286
286
287
287
290
290
291
Kapitola
1
Základnı́ pojmy a nástroje
Probereme nejdůležitějšı́ standardizačnı́ instituce, které se angažujı́ v oblasti počı́tačových sı́tı́, a dále se
podı́váme na adresovánı́, model TCP/IP a zejména se budeme věnovat protokolům IPv4 a IPv6.
V této kapitole již předpokládáme, že studenti ovládajı́ témata z přı́lohy A.
1.1
Standardizačnı́ instituce
Slučitelnost produktů různých výrobců je důležitá předevšı́m z důvodu možnosti spolupráce
zařı́zenı́. Rozlišujeme tato řešenı́:
1. Proprietálnı́ řešenı́ (proprietary) – výrobce si vytvořı́ zcela vlastnı́ řešenı́ neslučitelné s jinými,
P
2. Standard – řešenı́ se stává standardem (protokoly, konvence, parametry) z důvodu zajištěnı́
vzájemné kompatibility zařı́zenı́ odpovı́dajı́cı́ch tomuto standardu; závisı́ na typu organizace,
která standard vydává:
• doporučenı́ – standard vydán některou mezinárodnı́ standardizačnı́ institucı́,
• norma – standard stanoven vládnı́ institucı́, povinný.
Podı́váme se na několik nejznámějšı́ch standardizačnı́ch institucı́. Nenı́ nutné znát úplně všechny,
ale měli bychom alespoň vědět, že existujı́ a čı́m se zabývajı́, v následujı́cı́m textu se na některé
z nich budeme odvolávat.
Mezinárodnı́ telekomunikačnı́ unie (ITU – International Telecommunications Union) je celosvětová organizace (pracuje v rámci OSN). Má tři části (reorganizace byla provedena v roce 1993):
• radiokomunikačnı́ sektor (ITU-R),
• telekomunikačnı́ normalizačnı́ sektor (ITU-T),
• sektor rozvoje telekomunikacı́ (ITU-D).
ITU-T (původně CCITT – Commité Consultatif International de Télegraphique et Téléphonique)
je část ITU, jejı́ž činnost souvisı́ také s počı́tačovými sı́těmi. Členy s hlasovacı́m právem jsou země
1
J
1.1
STANDARDIZAČNÍ INSTITUCE
2
zastoupené telekomunikačnı́mi organizacemi z jednotlivých zemı́, členy bez hlasovacı́ho práva
mohou být i dalšı́ organizace. Členstvı́ nenı́ bezplatné.
Je to nevládnı́ instituce, vydává doporučenı́. Nejznámějšı́ je doporučenı́ X.25 pro veřejné datové
sı́tě.
ISO (International Organization for Standardization) je nevládnı́ organizace, vydává doporučenı́ (nazývajı́ se normy, ale nejsou přı́mo závazné). Členy jsou národnı́ standardizačnı́ organizace
z jednotlivých zemı́.
ISO má hierarchickou strukturu: členı́ se na asi 200 technických komisı́ (TC – Technical Committee), každá TC se členı́ na subkomise (SC – Subcommittee), každá SC se členı́ na pracovnı́ skupiny
(WG).
Návrhy jsou „zespoda“, od pracovnı́ch skupin – vytvořı́ working paper (WP, pracovnı́ verze),
dalšı́m stupněm je committee draft (CD, koncept vytvořený komisı́, dřı́ve draft proposal), následuje
draft international standard (DIS, koncept mezinárodnı́ normy), poslednı́m stupněm je international
standard (IS, mezinárodnı́ norma).
Nejznámějšı́m standardem této organizace je referenčnı́ model ISO/OSI. Text tohoto standardu
také vydala organizace ITU-T jako své doporučenı́ X.200.
IEEE (Institute of Electrical and Electronics Engineers) je profesnı́ sdruženı́ amerických inženýrů
elektroniky a elektřiny s vlastnı́m standardizačnı́m orgánem.
Nejznámějšı́m počinem tohoto sdruženı́ je skupina standardů IEEE 802 pro (převážně) lokálnı́
sı́tě.
IEC (International Electrotechnical Commission) je jakýsi doplněk ISO. IEC a ISO spolu hodně
spolupracujı́, IEC má na starosti vše z počı́tačových sı́tı́, co nenı́ v zaměřenı́ ISO (tj. hlavně specifikace
elektrických a elektronických zařı́zenı́, fyzická vrstva).
ETSI (European Telecommunications Standard Institute) vytvářı́ evropské standardy v oblasti
telekomunikacı́ (napřı́klad Euro-ISDN), hodně spolupracuje s ostatnı́mi podobnými organizacemi
(napřı́klad na GSM a jiných mobilnı́ch sı́tı́ch).
Český normalizačnı́ institut (ČNI) je česká organizace zajišt’ujı́cı́ vytvářenı́ našich národnı́ch
norem. Tato činnost však už nenı́ považována za prioritnı́, za důležitějšı́ se považuje harmonizace
s mezinárodnı́mi (předevšı́m evropskými) normami, tedy úkolem ČNI je také shromažd’ovánı́
a poskytovánı́ informacı́ o mezinárodnı́ch normách a účast na mezinárodnı́ spolupráci v tomto
směru.
IAB (Internet Architecture Board) je rada pro architekturu Internetu. Vydává informace o konvencı́ch a sı́t’ových protokolech, tzv. RFC (Request for Comments), které jsou volně dostupné na
Internetu. Napřı́klad
•
•
•
•
•
RFC 760 – původnı́ návrh adresace IP,
RFC 768 – protokol UDP,
RFC 791 – popis protokolu IP,
RFC 792 – protokol ICMP,
RFC 793 – protokol TCP,
1.2
ADRESOVÁNÍ
•
•
•
•
•
3
RFC 826 – protokol ARP,
RFC 959 – protokol FTP,
RFC 1878 – tabulky konverze adres pro podsı́tě v IP a přı́klady adresovánı́,
RFC 2460 – protokol IPv6,
RFC 2462 – autokonfigurace adres IPv6, atd.
ANSI (American National Standards Institute) je nevládnı́ organizace, reprezentuje USA v ISO,
nejznámějšı́m standardem je kód ASCII, v oblasti sı́tı́ napřı́klad FDDI, ISDN, Frame Relay.
EIA (Electronic Industries Assocation) sdružuje výrobce zařı́zenı́ pro telekomunikace předevšı́m
z USA, nejznámějšı́m standardem je RS-232-C. Obecně se zaměřuje na specifikaci fyzické úrovně
zařı́zenı́.
TIA (Telecommunication Industries Assocation) je sdruženı́ firem z oblasti telekomunikačnı́ch
technologiı́, spolupracuje s EIA a zaměřuje se na rozhranı́ a kabeláž v telekomunikačnı́ch sı́tı́ch.
Standardy vydané TIA (nebo EIA/TIA) bývaly původně označovány názvem začı́najı́cı́m RS (Recommended Standard).
1.2
1.2.1
Adresovánı́
Typy adres
Adresový prostor může být
• hierarchický – adresy majı́ strukturu vycházejı́cı́ z hierarchie sı́tě, obvyklé u většı́ch adresových
prostorů, zařı́zenı́ jsou členěna do skupin a přı́p. podskupin
• plochý (flat) – adresy nemajı́ vnitřnı́ strukturu, adresový prostor nenı́ nijak členěn na podprostory (malé sı́tě)
Adresy linkové vrstvy jsou typickým přı́kladem adres v plochém adresovém prostoru. Tento typ
adres předevšı́m jednoznačeně určuje zařı́zenı́ v (lokálnı́) sı́ti.
MAC adresy (Media Access Control) patřı́ k adresám, které se použı́vajı́ na linkové vrstvě, tedy
se jedná o plochý model adresovánı́ a musı́ (tedy měla by) jednoznačně identifikovat zařı́zenı́
v sı́ti. MAC adresa může vypadat napřı́klad takto (hexadecimálnı́ čı́slice, oddělené pomlčkou nebo
dvojtečkou):
00-0F-FE-12-34-AB
O MAC adresách v jedné z následujı́cı́ch sekcı́ (strana 8).
Adresy sı́t’ové vrstvy (také virtuálnı́, logické adresy) využı́vajı́ hierarchický adresový prostor.
Narozdı́l od předchozı́ch nejsou fixovány na konkrétnı́ zařı́zenı́, mohou být také dynamicky přidělovány. Typickým přı́kladem jsou IP adresy.
IP adresy jsou definovány v protokolu IP. V současné době se použı́vajı́ dvě verze – staršı́ IPv4
je dnes běžně dostupná prakticky na kterémkoliv sı́t’ovém zařı́zenı́, novějšı́ IPv6 sice (teoreticky) je
dostupná, ale tato verze protokolu ještě rozhodně nenı́ všude zprovozněna.
P
1.2
ADRESOVÁNÍ
4
IP adresám se budeme podrobně věnovat později, ted’ jen stručně pro ilustraci – IP adresa
protokolu IPv4 se skládá ze 4 částı́, každá část je čı́slo zabı́rajı́cı́ 1 B. Obvykle se zapisuje jako
čtveřice decimálnı́ch čı́sel oddělených tečkou.
IP adresy majı́ také všeobecnou adresu – opět jsou všechny bity nastaveny na 1, tj. u IPv4 to je
255.255.255.255 (toto platı́ v rámci lokálnı́ sı́tě). Podrobnosti v této kapitole v sekci o protokolu IP.
Doménové adresy (názvy) se použı́vajı́ jako „uživatelsky přı́větivějšı́“ obdoba IP adres (napřı́klad
www.google.com je jedna z doménových adres WWW serveru Googlu). Doménové adresy jsou
také hierarchické (pozor, v opačném pořadı́ než IP adresy – zatı́mco u IP adresy je „nejširšı́ oblast“
vlevo na začátku adresy, u doménové vpravo).
Pro překlad mezi doménovým názvem a IP adresou se použı́vajı́ jmenné služby, na Internetu
předevšı́m DNS. Doménovým názvům se věnujeme v kapitole o jmenných službách (str. 163).
1.2.2
Mapovánı́ adres
Různé typy adres je třeba navzájem mapovat. To lze provést třemi způsoby:
1. Použı́vánı́ mapovacı́ch tabulek, napřı́klad mezi vrstvami L2/L3 jde typicky o mapovánı́ sı́t’ových adres na MAC adresy (tj. jejich vzájemné přiřazovánı́) protokolem ARP, reverznı́
mapovánı́ zajišt’uje protokol RARP (Reverse ARP). Podobný princip funguje i v DNS.
2. Použı́vánı́ protokolu typu Hello, vzájemné (pravidelné) sdělovánı́ adres.
3. Vnořenı́ MAC adresy do sı́t’ové adresy nebo jiná (algoritmizovatelná) závislost MAC adresy
na sı́t’ové adrese – predictable MAC addresses.
Zatı́mco protokol IPv4 použı́vá dynamické mapovánı́ pomocı́ ARP, IPv6 z důvodu zvýšenı́ efektivity umožňuje také částečné statické mapovánı́, kdy MAC adresa může být součástı́ IPv6 adresy.
1. Tabulky. Překlad sı́t’ových IPv4 adres na MAC adresy (tj. mapovánı́ sı́t’ové adresy na MAC
adresu) pomocı́ protokolu ARP, resp. NDP pro IPv6:
P
• ARP tabulky sloužı́ k evidovánı́ mapovánı́ sı́t’ových adres na MAC adresy (ke každému
sı́t’ovému adaptéru je vlastnı́ ARP tabulka),
• pokud ARP protokol nenajde IP adresu v ARP tabulce, vyšle broadcast do LAN,
• každá stanice porovná svou IP adresu s adresou ve zprávě, a pokud souhlası́, odpovı́ paketem
se svou MAC adresou („vyplnı́“ chybějı́cı́ údaj),
• dotazujı́cı́ se stanice zařadı́ údaj do ARP tabulky a použije ho,
• pokud se IP adresa nenacházı́ v LAN, ale ve vzdálené sı́ti, odešle se dotaz na bránu, která ho
pošle dále.
ARP je typický pro IPv4 adresy. Pro IPv6 se použı́vá mechanismus (protokol) NDP, který funguje
podobně (viz str. 1.6.5). Podle předem uložených informacı́ se překládá také v DNS (většinou
jmenná adresa na IP adresu).
2. Protokol Hello. Když se systém přihlašuje do sı́tě, rozešle broadcast (Hello messages) do sı́tě
– informuje o své MAC adrese, resp. o tom, že je funkčnı́ a dostupný. Ostatnı́ zařı́zenı́ v sı́ti zašlou
odpověd’. V pravidelných intervalech se tento broadcast opakuje.
P
1.3
MODEL TCP/IP
5
Určitou formou tohoto principu je mechanismus KeepAlive, kdy typicky server ubezpečuje
svého souseda, že „žije“ – pokud zpráva KeepAlive nedorazı́, znamená to, že server nenı́ dostupný
a tedy je nutné zprovoznit či zpřı́stupnit pod danou adresou záložnı́ server.
S dalšı́ formou tohoto principu se setkáváme poměrně často – bezdrátový access point pravidelně ohlašuje beacon rámcem celé sı́ti své kontaktnı́ údaje (předevšı́m SSID), dı́ky tomu je
„viditelný“.
3. Predictable MAC adresses. Tento mechanismus spočı́vá v tom, že MAC adresa je odvoditelná
ze sı́t’ové adresy. V současné době mechanismus použı́vajı́ tyto protokoly:
P
• Xerox Network Systems (XNS),
• Novell Internetwork Packet Exchange (IPX),
• DECnet Phase IV,
• částečně to lze řı́ci o IPv6 (klientská část IP adresy se může odvodit z čı́sla EUI-64, které lze
jednoduše zjistit z MAC adresy), podrobnosti v sekci o tomto protokolu.
Referenčnı́ model
ISO/OSI
Protocol
Data Units:
Význam:








šifrovánı́,
Adresovánı́:
L7
Aplikačnı́ vrstva
Poskytuje služby aplikacı́m – manipulace s daty, sémantické překlady, bezpečnost.
L6
Prezentačnı́ vrstva
Provádı́ konverze dat –
(de)komprese, konverze do/z jiného
datového formátu, . . .
data, zprávy
L5
Relačnı́ vrstva
L4
Transportnı́ vrstva
Zbezpečuje spojenı́ mezi dvěma koncovými body; segmentace proudu dat
před přenosem, poskládánı́ po něm.
segmenty
porty
L3
Sı́t’ová vrstva
Přeposı́lá data k danému cı́li, provádı́
směrovánı́, pracuje s logickou topologiı́ sı́tě.
pakety, datagramy
IP addresy
Pracuje s fyzickou topologiı́ sı́tě, synchronizuje přenos, zde obvykle pracujı́
LAN řešenı́.
rámce
Řı́dı́ proces posı́lánı́ a přijı́mánı́
proudu dat, definuje fyzikálnı́ a elektrické specifikace zařı́zenı́ (rozhranı́).
bity
L2
L1
Linková vrstva
Fyzická vrstva




Otevı́rá, řı́dı́ and ukončuje konverzace 


mezi dvěma vzdálenými aplikacemi.
LLC
MAC
MAC addresy
Obrázek 1.1: Referenčnı́ model ISO/OSI
1.3
Model TCP/IP
Model TCP/IP je velmi úzce spojován s Internetem. Použı́vajı́ se tyto pojmy:
• sı́t’ový segment je lokálnı́ sı́t’schopná samostatné existence, uvnitř se použı́vajı́ nejvýše rozbočovače,
P
1.3
MODEL TCP/IP
6
• podsı́t’ (subnet) je fyzický sı́t’ový segment nebo virtuálnı́ sı́t’použı́vajı́cı́ stejnou podsı́t’ovou IP
adresu,
• sı́t’ je jeden nebo vı́ce sı́t’ových segmentů s různými typy mezilehlých zařı́zenı́ (opakovače,
přepı́nače, mosty), podsı́tě v rámci jedné sı́tě bývajı́ odděleny směrovači (routery) či přepı́nači,
• internet (intersı́t’), ve které jsou jednotlivé segmenty či sı́tě propojeny směrovači,
• Internet (s velkým „I“) je (již konkrétnı́) největšı́ celosvětový internet.
• intranet je vnitřnı́ sı́t’, obvykle důvěryhodná, extranet je vnějšı́ sı́t’, často se jedná o Internet.
Referenčnı́ model
ISO/OSI
L7
Referenčnı́ model
TCP/IP
Protocol
Data Units:
Protokoly:
POP3, IMAP
Aplikačnı́ vrstva
SMTP
Aplikačnı́ vrstva
data, zprávy
L6
Prezentačnı́ vrstva
L5
Relačnı́ vrstva
L4
Transportnı́ vrstva
Transportnı́ vrstva
segmenty
L3
Sı́t’ová vrstva
Internetová (sı́t’ová)
vrstva
pakety, datagramy
L2
L1
Linková vrstva
Fyzická vrstva
FTP, SFTP
etc.
DNS
DHCP
HTTP, HTTPS
ICMP, IGMP
IPv4, IPv6
LLC (IEEE 802.2)
LLC
MAC
TCP, UDP
rámce
Vrstva sı́t’ového
rozhranı́
bity
IEEE 802.3,
IEEE 802.11, . . .
Obrázek 1.2: Srovnánı́ referenčnı́ch modelů ISO/OSI a TCP/IP, protokoly a adresy
1.3.1
Vrstvy
Model ISO/OSI je obecný, komplexnı́ a teoretický. Zahrnuje (v obecnosti) všechny oblasti, které
v sı́t’ovém rozhranı́ existujı́, a obsahuje hodně restrikcı́. To je na jednu stranu výhodou, na druhou
stranu to nenı́ přiliš praktické z hlediska výrobců zařı́zenı́. Předevšı́m z důvodu zjednodušenı́
a přiblı́ženı́ praxi vznikl model TCP/IP.
TCP/IP (Transmission Control Protocol/Internet Protocol) má méně vrstev než ISO/OSI. Některé služby byly záměrně vypuštěny (nevyděluje se prezentačnı́ a relačnı́ vrstva), protože jejich
služby využı́vá jen málo aplikacı́ a tedy tyto aplikace si mohou potřebné služby implementovat
samy.
Na obrázku 1.2 na straně 6 je porovnánı́ rozvrženı́ vrstev v modelech ISO/OSI a TCP/IP.
V modelu TCP/IP jsou všechny vrstvy nad transportnı́ vrstvou sdruženy do jediné vrstvy nazývané
1.3
MODEL TCP/IP
7
aplikačnı́ vrstva. Také nejspodnějšı́ dvě vrstvy (fyzická a linková) jsou sdruženy do jediné, vrstvy
sı́t’ového rozhranı́.
Vrstva sı́t’ového rozhranı́ je závislá na konkrétnı́ implementaci sı́t’ového rozhranı́ – Ethernet,
Token Ring, FDDI, X.25 apod. Pro tuto vrstvu nejsou předepsány žádné protokoly, počı́tá se s napojenı́m na některé konkrétnı́ řešenı́ (napřı́klad výše zmı́něný Ethernet), které má vlastnı́ protokoly.
Tato vrstva musı́ být implementována ve všech prvcı́ch sı́tě.
Sı́t’ová vrstva (také vrstva internetu) použı́vá sı́t’ové adresy, má na starosti směrovánı́ a předávánı́
(přepojovánı́) datagramů. Tato vrstva je implementována v koncových uzlech sı́tě (počı́tače, servery
apod.) a dále všech mezilehlých prvcı́ch, které provádějı́ směrovánı́ podle sı́t’ových adres.
Typické protokoly jsou IP, ARP, RARP, ICMP, IGMP, IGRP, IPSEC, RIP, OSPF.
Transportnı́ vrstva zajišt’uje rozhranı́ mezi aplikačnı́ vrstvou (nezávislou na přenosové metodě)
a spodnı́mi vrstvami závislými na přenosové metodě, zajišt’uje transportnı́ služby (spojové i nespojové). Tato vrstva je implementována jen v koncových uzlech sı́tě.
Typické protokoly jsou TCP a UDP.
Aplikačnı́ vrstva obsahuje entity, které využı́vajı́ aplikace, tedy poskytuje služby směrem k aplikacı́m. Tato vrstva je samozřejmě také implementována jen v koncových uzlech sı́tě.
Typické protokoly jsou FTP, HTTP, DHCP, DNS, SMTP, IMAP, POP3, NFS, Telnet, apod.
Tyto protokoly komunikujı́ předevšı́m s porty transportnı́ vrstvy přes tzv. porty, což je čı́selné
označenı́ určujı́cı́ konkrétnı́ přı́stupový bod směrem k nižšı́ vrstvě. Rozlišujeme porty známé (čı́sla
0–1023), registrované (1024–49 151, přiděluje organizace IANA) a dynamické či soukromé (vyššı́
čı́sla). Seznam portů lze najı́t na internetu, napřı́klad
• http://www.ports-services.com/
• http://www.iana.org/assignments/port-numbers
• http://en.wikipedia.org/wiki/List of TCP and UDP port numbers
Také bychom měli vědět, se kterými porty konkrétnı́ spuštěná aplikace pracuje. Napřı́klad ve
Windows to zjistı́me bud’ ve firewallu, a nebo v některém správci procesů (na Správce úloh nenı́
moc dobré spoléhat, tam moc informacı́ nenı́, ale můžeme vyzkoušet napřı́klad aplikaci Process
Explorer1 .
Úkoly
Spust’te alespoň jeden z programů, které pracujı́ se sı́těmi (napřı́klad webový prohlı́žeč nebo e-mailového klienta, přı́p. obojı́). Zjistěte, které porty použı́vajı́ či na nich naslouchajı́. Pokud pracujete
ve Windows, můžete použı́t napřı́klad Process Explorer (stáhnete ze Sysinternals.com, známe
z Operačnı́ch systémů). Ve Windows i Linuxu lze použı́t program netstat, návod najdete v přı́loze.
1
http://www.sysinternals.com.
P
P
P
P
1.3
MODEL TCP/IP
1.3.2
8
Vrstva sı́t’ového rozhranı́
Přı́mo v referenčnı́m modelu TCP/IP nejsou protokoly na této vrstvě stanoveny, nicméně ve vztahu
k ISO/OSI lze řı́ci, že na L2 (spojové) vrstvě, kterou dělı́me na dvě podvrstvy, se velmi často
setkáme s protokolem IEEE 802.2, označovaným jako LLC (stejně jako dotyčná podvrstva). Tı́mto
protokolem se budeme zabývat zároveň s jinými spojovými protokoly v kapitole 4.1.6 o WAN
sı́tı́ch, strana 72.
Na podvrstvě MAC a na fyzické vrstvě již najdeme implementaci konkrétnı́ sı́tě. Pokud se jedná
o lokálnı́ sı́t’(typicky Ethernet), pracujeme na podvrstvě MAC s fyzickými (MAC) adresami.
MAC adresa (také fyzická adresa) zabı́rá 48 bitů, tedy 6 oktetů (resp. 12 hexadecimálnı́ch čı́slic)
rozdělených na dvě poloviny, jak je naznačeno v tabulce 1.1. Zapisuje se po jednotlivých oktetech
(většinou hexadecimálně) oddělených dvojtečkou nebo pomlčkou.
24 bitů
24 bitů
identifikace výrobce nebo prodejce (přiděluje
IEEE)
identifikace konkrétnı́ho výrobku (třeba sériové čı́slo), jedinečné pro zařı́zenı́ výrobce/prodejce
P
Tabulka 1.1: Struktura MAC adresy
Každé sı́t’ové zařı́zenı́ (napřı́klad sı́t’ová karta) má z výroby přidělenu jednu MAC adresu,
která se nazývá burned-in address (BIA), protože je napevno v ROM paměti zařı́zenı́ (burned –
„vypálena“) a odtud se v přı́padě potřeby mapuje do operačnı́ paměti. BIA MAC adresa je vždy
jedinečná, neexistujı́ dvě stejné.
MAC adresy jsou obvykle globálnı́ (globálně jednoznačné), ale mohou být také lokálnı́. Přidělujı́
se v lokálnı́ sı́ti předevšı́m tehdy, když při změně sı́t’ového hardwaru je nutné zachovat adresu
uzlu v sı́ti, ale využı́vajı́ je také lidé, kteřı́ chtějı́ obejı́t seznamy pro filtrovánı́ MAC adres (s těmito
technikami se seznámı́me v kapitole 6.2.9). Lokálnı́ MAC mohou mı́t plnou délku 48 bitů nebo
mohou být zkrácené (16 bitů).
Lokálně přidělené zkrácené MAC adresy jsou tedy kratšı́ a jsou spojeny s některými specifickými
sı́t’ovými protokoly a architekturami (napřı́klad DECnet nebo Banyan VINES).
Existujı́ také lokálnı́ MAC adresy na 48 bitech (plná délka), které byly softwarově pozměněny
a nenı́ u nich zajištěna jedinečnost (přesněji – o jejich jedinečnost by se měl starat správce dané sı́tě).
Aby bylo možné je odlišit od globálnı́ch (BIA) adres, majı́ druhý nejnižšı́ bit (L/G bit, viz obrázek
1.3) prvnı́ho oktetu nastaven na 1 (u BIA adres je tento bit vždy nastaven na 0).
L/G
I/G
• L/G bit: lokálnı́ (1) nebo globálnı́ (0) adresa
• I/G bit: unicast (individuálnı́, 0) nebo multicast či broadcast (group, 1)
Obrázek 1.3: Umı́stěnı́ L/G (local/global) a I/G (individual/group) bitu v MAC adrese
P
P
1.3
MODEL TCP/IP
9
MAC adresy dělı́me na individuálnı́, skupinové (multicast) a všeobecné (broadcast). Pro individuálnı́ MAC platı́ vše, co jsme dosud četli (jedná se o konkrétnı́ adresu přiřazenou sı́t’ovému
zařı́zenı́), nejnižšı́ bit prvnı́ho oktetu je vždy nastaven na 0.
P
Skupinové a všeobecné MAC adresy nejsou přiřazeny jednomu konkrétnı́mu zařı́zenı́. Nejméně
významný bit prvnı́ho oktetu je vždy nastaven na 1 (tento bit bývá označován I/G bit – individual/group, viz obrázek 1.3). Skupinová MAC adresa je určena pro skupinové vysı́lánı́ (vybrané
počı́tače v lokálnı́ sı́ti), všeobecná adresuje všechny aktivnı́ počı́tače v sı́ti. Všeobecná MAC adresa
má všechny bity nastaveny na 1, kdežto skupinová ne (podle identifikace skupiny, předevšı́m
nejméně významný bit prvnı́ho oktetu musı́ být 1).
Přı́klad
Přı́klad individuálnı́ adresy:
Přı́klad individuálnı́ lokálnı́ adresy:
Přı́klad skupinové adresy:
Všeobecná adresa:
00–0B–6A–01–82–F4
02–0B–6A–01–82–F4
01–0B–6A–25–F3–0C
FF–FF–FF–FF–FF–FF
Poznámka: Popis přı́kazů pro práci se sı́těmi a předevšı́m různými typy adres najdeme v přı́lohách
(od strany 230 pro Windows, od strany 249 pro Linux).
E
Úkoly
1. Najděte v přı́loze ukázky přı́kazů pro ten operačnı́ systém, ve kterém právě pracujete, a vyzkoušejte alespoň „nedestruktivnı́ “ vypisujı́cı́ varianty přı́kazů, na které máte dostatečná
přı́stupová oprávněnı́. Přı́mo v přı́loze také najdete úkoly.
2. Ve zmı́něných přı́lohách jsou u Windows a Linuxu vypsány také důležité soubory (obvykle
konfiguračnı́), které se sı́těmi souvisejı́. Tyto soubory najděte a prohlédněte si je.
3. Zjistěte svou MAC adresu. Všimněte si nejlevějšı́ho oktetu, nastavenı́ L/G a I/G bitu.
1.3.3
Protokoly sı́t’ové vrstvy
Rodina protokolů TCP/IP nezahrnuje pouze ty dva protokoly, které má v názvu. Postupně probereme nejdůležitějšı́ protokoly (rozhodně ne všechny).
IP (Internet Protocol) zajišt’uje odesı́lánı́ a přijı́mánı́ datagramů. Součástı́ hlavičky datagramu je
také IP adresa odesı́latele a přı́jemce a dále čı́slo datagramu v posloupnosti z celé zprávy vyššı́
vrstvy. Protokol IP probereme podrobněji v samostatné sekci.
MIP (Mobile IP) je rozšı́řenı́ protokolu IP určené pro mobilnı́ uzly sı́tě, které měnı́ mı́sto svého
zapojenı́ v rámci Internetu při zachovánı́ své domácı́ IP adresy. Pomocı́ MIP lze implementovat
i tunelovánı́ (tunneling), což je vzdálené připojovánı́ do lokálnı́ sı́tě přes Internet.
ARP (Address Resolution Protocol) sloužı́ k překladu IP adresy na MAC adresu (tj. mapovánı́
adres). Informace o mapovánı́ adres si udržuje v tzv. ARP tabulce, a pokud je požadována adresa,
kterou v tabulce nemá, odešle žádost o informaci na všechny uzly sı́tě.
P
P
1.3
MODEL TCP/IP
10
Opačný překlad (MAC adresy na IP adresu) provádı́ protokol RARP (Reverse ARP), ale v současné době jeho funkce plnı́ spı́še protokol DHCP.
Ve skutečnosti nenı́ přesně stanoveno, na které vrstvě vlastně ARP pracuje. Jeho funkce zasahujı́
i do obou okolnı́ch vrstev.
ICMP (Internet Control Message Protocol) sloužı́ k zası́lánı́ řı́dicı́ch hlášenı́ (včetně chybových
hlášenı́).
8
8
16
typ zprávy
parametr zprávy
kontrolnı́ součet
Tabulka 1.2: Datagram protokolu ICMP
Přı́klad
Protokol ICMP je využı́ván také programem ping (Packet Internet Groper) pro zjištěnı́ dosažitelnosti cı́lové stanice či sı́tě. Ping vysı́lá zprávu ICMP Echo Request s IP adresou cı́lové stanice
a očekává odpověd’ o dosažitelnosti (ICMP Echo Reply).
Dalšı́m způsobem využitı́ protokolu ICMP je zjišt’ovánı́ cesty přes směrovače k cı́li pomocı́
traceroute. Spočı́vá v postupném generovánı́ IP datagramů s hodnotou TTL (také na str. 231)
nastavenou postupně na hodnoty 1, 2, 3, atd. TTL (Time To Live) je omezenı́ životnosti datagramu,
které se na každém směrovači (tj. při každém skoku) snižuje (nejméně o 1) a pokud směrovač
obdržı́ zprávu s TTL=0, neposı́lá ji dál, ale odešle zpět zprávu ICMP Time Exceeded (čas vypršel)
se svou adresou. Traceroute tedy vysı́lá IP datagramy se zvyšujı́cı́mi se hodnotami TTL a takto
postupně zı́ská adresy všech směrovačů na sı́ti.
Programy ping a traceroute (přı́padně ve Windows tracert) jsou dostupné v každém sı́t’ovém operačnı́m systému.
Formát datagramu protokolu ICMP je naznačen v tabulce 1.2. Význam jednotlivých polı́:
• typ zprávy (8 bitů) určuje typ zası́lané zprávy; typy zpráv jsou specifikovány v RFC 792 a RFC
1256, může to být napřı́klad
– 0 (Echo Reply) – odpověd’ na žádost o odezvu,
– 3 (Source Unreachable) – cı́l je nedostupný,
– 4 (Source Quench) – cache je zahlcena (žádost cı́lové stanice o snı́ženı́ rychlosti přenosu,
aby cı́lová stanice měla vı́c času na zpracovánı́ dat),
– 8 (Echo Request) – poslána mechanismem ping, žádost o odezvu,
– 11 (Time Exceeded) – životnost datagramu vypršela (TTL=0, viz také str. 231 a 10), posı́lá
mezilehlý uzel uzlu posı́lajı́cı́mu data,
– 17 (Address Mask Request) – žádost o informaci o sı́t’ové masce,
– 18 (Address Mask Reply) – odpověd’ s informacı́ o sı́t’ové masce,
atd.
P
1.3
MODEL TCP/IP
11
• parametr zprávy (8 bitů) sloužı́ k upřesněnı́ typu zprávy, napřı́klad typ zprávy 3 je v ICMPv4
upřesňován na 0 (cı́lová sı́t’ nedostupná), 1 (cı́lový hostitel nedostupný), 2 (cı́lový protokol
nedostupný), 3 (cı́lový port nedostupný), atd.
• kontrolnı́ součet (16 bitů) přes předchozı́ dvě pole datagramu.
Seznam všech typů ICMP zpráv najdeme napřı́klad na
http://www.iana.org/assignments/icmp-parameters.
Zpráva ICMP Echo Request je podrobně popsána na stránce
http://www.networksorcery.com/enp/protocol/icmp/msg8.htm včetně implementačnı́ch detailů. Také
zde najdeme informaci, že Echo zprávy musejı́ být implementovány a zpracovány, rozhodně by
(ani z bezpečnostnı́ch důvodů) neměly být ignorovány. K dalšı́m typům ICMP zpráv se dostaneme
mı́rnou úpravou adresy.
IGMP (Internet Group Management Protocol) je, jak název napovı́dá, určen ke správě zası́lánı́
datagramů na skupinové adresy. V současné době se použı́vá jeho třetı́ verze, tj. IGMPv3. IGMP
své zprávy zapouzdřuje do IP datagramů a použı́vá vždy TTL=1.
Multicast může být dvou typů – bud’ one-to-many (jeden vysı́lá a mnoho přijı́má, napřı́klad
aktualizace softwaru, monitorovánı́ sı́tě a uzlů, koncerty, zpravodajstvı́, apod.) nebo many-to-many
(také vysı́lajı́cı́ch uzlů je vı́ce, napřı́klad multimediálnı́ konference, počı́tačové hry apod.). Skupinové IP adresy se mapujı́ na skupinové MAC adresy (konkrétně poslednı́ch 23 bitů skupinové
IP adresy). Problém je v tom, že IP adresy majı́ výrazně méně bitů než MAC adresy, proto se za
určitých okolnostı́ může stát, že mapovánı́ nebude zcela jednoznačné.
Stanice, která chce být součástı́ skupiny pro určitou skupinovou adresu, nejdřı́v naslouchá všem
datagramům na IP adrese 224.0.0.1, což je vyhrazená skupinová adresa označujı́cı́ všechny stanice
v podsı́ti. Pak informuje všechny stanice lokálnı́ho segmentu, že se přihlašuje do konkrétnı́ skupiny,
a to zprávou IGMP Host Membership Report obsahujı́cı́ adresu této skupiny, a pak naslouchá všem
datagramům pro danou skupinovou adresu.
RIP (Routing Information Protokol) je staršı́ jednoduchý směrovacı́ protokol. Vyznačuje se poměrně snadnou konfiguracı́, ale jeho metriky (odhady délky cesty mezi uzly) jsou považovány za
spı́še méně přesné. Je to ideálnı́ směrovacı́ protokol pro menšı́ lokálnı́ sı́tě.
OSPF (Open Shortest Path First) je také směrovacı́ protokol, ale novějšı́ a složitějšı́. Je to adaptivnı́
hierarchický distribuovaný protokol s poměrně přesnou metrikou. Použı́vá se ve většı́ch lokálnı́ch
sı́tı́ch. O směrovacı́ch protokolech se budeme učit později.
Úkoly
Najděte alespoň dvě různé situace, ve kterých se použı́vajı́ ICMP pakety. Promyslete si, co by se
stalo, kdyby některý uzel na cestě zahazoval všechny ICMP pakety (nebo alespoň ten typ zpráv,
o který by se právě jednalo).
P
$
P
P
1.3
MODEL TCP/IP
1.3.4
12
Protokoly transportnı́ vrstvy
Komunikujı́cı́ aplikace z vyššı́ vrstvy jsou na této vrstvě rozlišeny podle portů (tj. čı́slo portu určuje
přı́slušný SAP mezi transportnı́ a aplikačnı́ vrstvou).
TCP (Transmission Control Protocol) vytvářı́ virtuálnı́ okruh mezi komunikujı́cı́mi uzly, tedy
zajišt’uje spolehlivou (s potvrzenı́m) službu se spojenı́m.
V TCP se setkáváme se třemi fázemi komunikace – navázánı́m spojenı́, přenosem dat (segmenty
s pořadovými čı́sly, každý musı́ být pozitivně potvrzen – ne nutně okamžitě – druhou stranou
a přı́padně znovu poslán, pokud došlo k chybě při přenosu) a ukončenı́m spojenı́ (oboustranným).
Potvrzovánı́ přijetı́ datových segmentů nemusı́ probı́hat po každém obdrženı́. Součástı́ záhlavı́ segmentu je údaj velikost okna, což je počet oktetů dat, která lze přenést v rámci spojenı́ bez
průběžného potvrzovánı́, obvykle to bývá vı́ce než velikost jednoho segmentu. Tento způsob řı́zenı́ potvrzovánı́ se nazývá Sliding Window (klouzavé okno), protože okno zahrnujı́cı́ posloupnost
oktetů bez průběžného potvrzovánı́ se během spojenı́ postupně posouvá.
4
6
6
16
port zdroje
port cı́le
pořadové čı́slo prvnı́ho oktetu dat v segmentu
pořadové čı́slo oktetu pro následujı́cı́ segment
délka záhlavı́
rezervováno =0
funkce řı́zenı́
kontrolnı́ součet
šı́řka okna
specifikace urgentnı́ch dat
volitelné
data
Tabulka 1.3: Segment protokolu TCP
Formát segmentu protokolu TCP je naznačen v tabulce 1.3. Význam jednotlivých polı́:
• port zdroje a port cı́le (oba po 16 bitech) specifikujı́ porty, přes které přicházejı́ data z aplikačnı́ vrstvy na zdrojovém počı́tači, resp. jsou odesı́lána data na aplikačnı́ vrstvu na cı́lovém
počı́tači, napřı́klad 21 (FTP řı́zenı́), 20 (FTP přenos dat), 25 (SMTP), atd.
uvedená čı́sla portů se použı́vajı́ předevšı́m pro port cı́le; port zdroje obvykle bývá vyššı́ než
1024, často se použı́vá pro mechanismus PAT (překlad portů), viz dále ve skriptech.
• pořadové čı́slo prvnı́ho oktetu dat v segmentu (32 bitů) určuje, kde v původnı́m posı́laném proudu
dat přijatém z aplikačnı́ vrstvy začı́najı́ data, která jsou součástı́ tohoto segmentu,
• pořadové čı́slo oktetu pro následujı́cı́ segment (32 bitů) podobně pro následujı́cı́ segment, tento
údaj sloužı́ pro cı́lový uzel jako kontrola, zda jsou segmenty správně doručovány (aby bylo
možné odeslat potvrzenı́),
• délka záhlavı́ (4 bity), je to čı́slo určujı́cı́ počet násobků 32 bitů, které zabı́rá záhlavı́, napřı́klad
pokud záhlavı́ zabı́rá 576 bitů (= 18 × 32), je zde čı́slo 18,
P
P
1.3
MODEL TCP/IP
13
• funkce řı́zenı́ (6 bitů) – každý bit má svůj význam:
– URG – přı́znak urgentnı́ch dat (majı́ při doručenı́ přednost),
– SYN – synchronizačnı́ bit, použı́vá se při navazovánı́ spojenı́,
– ACK – má být bráno v úvahu pole „pořadové čı́slo oktetu pro následujı́cı́ segment“,
představuje potvrzenı́ (acknowledge),kromě prvnı́ho paketu posı́laného při navazovánı́
spojenı́ bývá obvykle nastaven na 1,
– RST – žádost o opětovné navázánı́ spojenı́,
– PSH – žádost o okamžité doručenı́ segmentu protokolu vyššı́ vrstvy,
– FIN – žádost o ukončenı́ spojenı́,
• šı́řka okna (16 bitů) je velikost okna (množstvı́ oktetů, které lze poslat bez průběžného potvrzovánı́),
• kontrolnı́ součet (16 bitů) přes celý segment včetně tzv. pseudozáhlavı́ (obsahuje zdrojovou
a cı́lovou IP adresu, čı́slo protokolu a délku segmentu, celkem 3×32 = 96 bitů), pseudozáhlavı́
se v transportnı́ vrstvě použı́vá jen k tomuto účelu (vytvořenı́ kontrolnı́ho součtu), nenı́
součástı́ segmentu a ani se nevyužı́vajı́ informace v něm uvedené,
• specifikace urgentnı́ch dat (16 bitů) pokud jsou posı́lána urgentnı́ data, je zde čı́slo poslednı́ho
oktetu urgentnı́ch dat (použı́vá se k urychlenı́ zpracovánı́ segmentu),
• volitelné možnosti (v násobku 32 bitů) jsou doplňkové informace určené cı́lové stanici.
Jak je to s čı́sly Sequence Number a Acknowledge Number: Wireshark a podobné nástroje obvykle
zobrazujı́ jen relativnı́ čı́sla (skutečná jsou hodně velká). Nicméně je možné napřı́klad ve Wiresharku
Obrázek 1.4: Wireshark – Flow Graph, zobrazená čı́sla Sequence a Acknowledge Number
1.3
MODEL TCP/IP
14
Uzel 1
(klient)
Uzel 2
(server)
SYN
sport=1027, dport=80,
seq=200
Klient začı́ná handshake – navázánı́
spojenı́ („chci komunikovat“), nastavı́ svoje sequence number
SYN, ACK
sport=80, dport=1027,
ack=201, seq=1450
Server souhlası́, nastavuje svoje
sequence number
ACK
sport=1027, dport=80,
seq=201, ack=1451
Klient potvrdı́ údaje od serveru, od
této chvı́le existuje spojenı́
Obrázek 1.5: Průběh navazovánı́ spojenı́ (handshake) podle protokolu TCP
zapnout zobrazovánı́ skutečných čı́sel. V menu zvolı́me Edit – Preferences, tam nesmı́ být zaškrtnuté
„Relative sequence numbers and window scaling“. Provoz s těmito čı́sly zobrazı́me takto: Statistics
– Flow Graph, zaškrtnout TCP Flow.
Uzel 1
(klient)
Uzel 2
(server)
ack=1000, window=3000
Posı́láno po 1000 B, velikost okna
3000
seq=1000 (prvnı́ch 1000 B dat)
Posláno prvnı́ch 1000 B dat, ještě se
nepotvrzuje
seq=2000 (druhých 1000 B dat)
Posláno druhých 1000 B dat, ještě se
nepotvrzuje
seq=3000 (třetı́ch 1000 B dat)
Posláno třetı́ch 1000 B dat, čekám
na potvrzenı́
ack=4000, window=4000
Potvrzeno celkem 3000 B dat, žádost o dalšı́, většı́ okno
seq=4000 (dalšı́ data)
Dalšı́ várka dat, atd.
Obrázek 1.6: Komunikace podle protokolu TCP
1.3
MODEL TCP/IP
15
Uzel 1
(klient)
Uzel 2
(server)
ack=1000, window=3000
Data po 1000 B, velikost okna 3000
seq=1000 (prvnı́ch 1000 B dat)
Posláno prvnı́ch 1000 B dat, ještě se
nepotvrzuje
seq=2000 (druhých 1000 B dat)
Posláno druhých 1000 B dat, nedošlo
seq=3000 (třetı́ch 1000 B dat)
Posláno třetı́ch 1000 B dat, čekám
ack=2000
Nedošla data pro seq=2000, prosı́m
znovu
seq=2000 (druhých 1000 B dat)
Znovu posláno druhých 1000 B dat
ack=4000, window=3000
Ted’ už je to všechno, prosı́m dalšı́
Obrázek 1.7: Komunikace podle protokolu TCP, chyba při přenosu
Uzel 1
Uzel 2
ACK, FIN
seq=1000
Jeden z uzlů iniciuje ukončenı́ spojenı́
ACK
ack=1001
Druhý uzel souhlası́ ...
ACK, FIN
ack=1001, seq=1470
ACK
ack=1471
... a posı́lá vlastnı́ ukončujı́cı́ segment
Prvnı́ uzel potvrdı́ přijetı́, konec
Obrázek 1.8: Ukončenı́ spojenı́ v protokolu TCP
1.3
MODEL TCP/IP
16
Při navazovánı́ TCP spojenı́ se provádı́ tzv. three-way handshake:
1. prvnı́ strana odešle TCP segment s nastaveným bitem SYN,
2. druhá strana odpovı́ TCP segmentem s nastavenými bity SYN/ACK, firewall pozná odpověd’
a detekuje navazované spojenı́,
3. prvnı́ strana kontruje TCP segmentem s nastaveným ACK, pak je spojenı́ navázáno.
TCP nepodporuje vysı́lánı́ na všeobecnou a skupinovou adresu, protože s těmito adresami nelze
navázat obousměrné spojenı́.
Podrobnosti: http://www.faqs.org/docs/iptables/tcpconnections.html
UDP (User Datagram Protocol) poskytuje nespolehlivou službu bez navázánı́ spojenı́. Použı́vá se
předevšı́m pro posı́lánı́ menšı́ho množstvı́ dat nebo pro přı́pady, kdy je důležitá rychlost doručenı́
dat (přenos nenı́ zdržován fázı́ navázánı́ spojenı́). Jeho výhodou je, že často funguje i v přı́padě, že
TCP přestane být použitelný (pokud nelze s cı́lovým uzlem navázat standardnı́ spojenı́).
P
P
UDP podporuje skupinové a všeobecné IP adresy.
16
16
port zdroje
port cı́le
délka segmentu
kontrolnı́ součet
data
Tabulka 1.4: Segment protokolu UDP
Formát segmentu protokolu UDP je v tabulce 1.4. Význam jednotlivých polı́:
• port zdroje a port cı́le (oba po 16 bitech) majı́ stejný význam jako u TCP,
• délka segmentu (16 bitů), je to čı́slo určujı́cı́ počet násobků 32 bitů, které zabı́rá celý segment,
• kontrolnı́ součet (16 bitů) přes celý segment včetně pseudozáhlavı́ (jako u segmentu TCP).
PPP (Point-to-Point Protocol) pracuje někde na rozhranı́ sı́t’ové vrstvy a (v ISO/OSI) linkové
vrstvy, obsahuje dokonce i některé služby aplikačnı́ vrstvy. Poskytuje služby autentizovaného spojenı́, šifrovánı́ a komprese na point-to-point spojenı́ch. Použı́vá se v návaznosti na telekomunikačnı́
sı́tě.
Úkoly
V přı́loze v sekci C.6.2 od strany 276 jsou ukázány postupy pro filtrovánı́ provozu v Linuxu, kromě
jiného podle TCP portů. Srovntejte uvedené přı́kazy se schématem TCP paketu v tabulce 1.3 na
straně 12 – která pole záhlavı́ TCP paketu jsou v daných přı́kazech využı́vána? Čı́sla portů můžete
vidět také v následujı́cı́ podsekci o protokolech aplikačnı́ vrstvy (napřı́klad port 80 využı́vaný
protokolem HTTP).
P
1.3
MODEL TCP/IP
1.3.5
17
Protokoly aplikačnı́ vrstvy
Podı́váme se na nejdůležitějšı́ protokoly pracujı́cı́ na aplikačnı́ vrstvě (aplikačnı́ podle TCP/IP).
FTP (File Transfer Protocol) je všeobecně známý protokol pro spolehlivý přenos souborů mezi
uzly v sı́ti bez ohledu na operačnı́ systém, který na daném uzlu běžı́. Autentizačnı́ informace posı́lá
nezašifrované, proto nenı́ považován za přı́liš bezpečný. Využı́vá služeb protokolu TCP na portu
21 (pro řı́dicı́ spojenı́) a 20 (datové spojenı́).
Má také zabezpečené varianty, napřı́klad SFTP.
HTTP (Hypertext Transfer Protocol) je objektově orientovaný protokol použı́vaný pro distribuovaný přenos dat obsahujı́cı́ch hypertextové informace. Je znám předevšı́m jako protokol pro
komunikaci webového klienta (internetového prohlı́žeče) s webovým serverem, ale ve skutečnosti
je jeho použitı́ širšı́. Může také sloužit ke komunikaci s jinými aplikačnı́mi protokoly (SMTP, FTP,
apod.). Komunikuje s protokolem TCP na portu 80.
NFS (Network File System) je sı́t’ový souborový systém (od firmy Sun) umožňujı́cı́ vzdálený
přı́stup k souborům. Jeho použı́vánı́ nad rámec lokálnı́ sı́tě je diskutabilnı́, předevšı́m vzhledem
k nepřı́liš dobrému zabezpečenı́.
Telnet (Telecomunication Network) je již velmi starý protokol sloužı́cı́ ke vzdálenému přı́stupu
k uzlům sı́tě pomocı́ protokolu TCP (tj. virtuálnı́ terminál), využı́vá port 23. Jeho použı́vánı́ nenı́
považováno za bezpečné, i proto, že všechny autentizačnı́ údaje přenášı́ nezašifrovaně v textové
podobě. Má mnoho zabezpečených alternativ, napřı́klad SSH.
DNS (Domain Name System) je protokol pro mapovánı́ doménových jmen a IP adres. Použı́vá
port čı́slo 53. DNS je důležitým protokolem pro implementaci jmenných služeb, podrobněji se o tomto
mechanismu budeme učit později.
DHCP (Dynamic Host Configuration Protocol) sloužı́ k zı́skánı́ IP adresy pro klienta. Později se
podı́váme, jaký je rozdı́l v mechanismu DHCP při použitı́ IPv4 nebo IPv6.
SMTP (Simple Mail Transfer Protocol) sloužı́ k přenosu elektronické pošty. Zprávu doručuje do
poštovnı́ schránky adresáta, ze které ji adresát může kdykoliv vyzvednout pomocı́ protokolů POP3
nebo IMAP. Použı́vá port 25. SMTP server by nás měl zajı́mat při odesı́lánı́ zprávy z mailového
klienta. Pokud máme chybně nakonfigurované spojenı́ k SMTP serveru, neodešleme z klienta
zprávu nebo sice odešleme, ale se spoustou chybových hlášenı́. Tedy bychom si měli předem
zjistit, jaká je adresa SMTP serveru, a veškeré potřebné parametry.
POP (Post Office Protocol) sloužı́ k zı́skávánı́ (stahovánı́) elektronické pošty z poštovnı́ schránky
na serveru do mailového klienta. V současné době se použı́vá verze 3 (POP3), a to na portu 110.
IMAP (Internet Message Access Protocol) je alternativou k POP3, umožňuje pracovat s elektronickými zprávami přı́mo v poštovnı́ schránce (nenı́ nutné je stahovat na pracovnı́ stanici).
NTP (Network Time Protocol) sloužı́ k synchronizaci hodin v sı́ti. Synchronizovat lze jak s NTP
serverem v rámci lokálnı́ sı́tě, tak i se vzdáleným serverem. Ve Windows napřı́klad sloužı́ k základnı́
práci s NTP přı́kaz NET TIME. Použı́vá port 123.
SNMP (Simple Network Management Protocol) sloužı́ k přenosu informacı́ souvisejı́cı́ch s řı́zenı́m a správou sı́tě. Tomuto protokolu se budeme podrobně věnovat později v kapitole o bezpečnosti
a správě sı́tě.
P
1.5
PROTOKOL IPV4
18
RPC (Remote Procedure Call) sloužı́ ke vzdálenému volánı́ procedur. Klient takto odešle serveru
žádost obsahujı́cı́ určenı́ procedury a vstupnı́ parametry (na portu 111), server pak odešle odpověd’
s výstupem (na portu specifikovaném v žádosti). RPC je využı́ván napřı́klad protokolem NFS.
1.4
Sady protokolů
Protokol může využı́vat služeb jiného protokolu a poskytovat služby jinému protokolu.
Protocol suite (sada protokolů) je množina takových protokolů, které jsou součástı́ daného (jednoho) referenčnı́ho modelu, tj. dokážou navzájem spolupracovat.
Protocol stack (protokolový zásobnı́k) je množina protokolů implementovaná na konkrétnı́m
zařı́zenı́ (podmnožina sady protokolů některého referenčnı́ho modelu), nemusı́ být zdaleka úplná.
Nejznámějšı́m protokolovým zásobnı́kem je samotný TCP/IP, dále se setkáváme napřı́klad s protokolovým zásobnı́kem H.323 implementovaným na VoIP zařı́zenı́ch, také známe protokolový
zásobnı́k GSM implementovaný na GSM zařı́zenı́ch (mobilnı́ telefony a jakákoliv zařı́zenı́ s GSM
čipem).
1.5
Protokol IPv4
1.5.1
IPv4 datagramy
IPv4 (protokol IP verze 4) pracuje s datagramy – posı́lá je na zadanou IP adresu, kterou najde
v záhlavı́ datagramu. Poskytuje službu bez spojenı́, a to nespolehlivou (bez potvrzovánı́, bez
detekce chyb), třebaže s nejlepšı́ vůlı́ datagram doručit (tato vlastnost se nazývá Best Effort).
4
4
8
16
verze
délka
záhlavı́
typ služby
celková délka
identifikace datagramu
TTL
přı́znaky
čı́slo protokolu
idenfikace fragmentu (13 bitů)
zabezpečenı́ záhlavı́
zdrojová IP adresa
cı́lová IP adresa
volitelné
data (max. 65 535 mı́nus délka záhlavı́ oktetů)
Tabulka 1.5: Datagram protokolu IPv4
Formát IPv4 datagramu je naznačen v tabulce 1.5. Význam jednotlivých polı́ je následujı́cı́:
• verze (4 bity) – verze protokolu (tedy 4),
• délka záhlavı́ (4 bity) – údaj je počtem 32bitových slov, obvykle je zde čı́slo 5,
P
1.5
PROTOKOL IPV4
19
• typ služby (8 bitů ozn. PPPDTRC0) – upřesňuje způsob zpracovánı́ datagramu protokolem
vyššı́ vrstvy (nejnižšı́ bit nenı́ použı́ván), jednotlivé bity a skupiny bitů znamenajı́
–
–
–
–
–
PPP je určenı́ priority datagramu (precedence),
D zpožděnı́ zpracovánı́ (delay),
T určuje propustnost (throughput),
R znamená spolehlivost (reliability),
C je cena (cost),
takto se provádı́ optimalizace řı́zenı́ doručovánı́ (napřı́klad můžeme stanovit prioritu nı́zkého
zpožděnı́ a vysoké spolehlivosti), nedoporučuje se pokusit se optimalizovat vı́ce než dva
parametry,
• celková délka (16 bitů) – délka datagramu (včetně záhlavı́) v oktetech, z toho vyplývá maximálnı́
délka běžného IPv4 datagramu, tj. 216 = 65 536 oktetů,
• identifikace datagramu (16 bitů) – proud dat z vyššı́ vrstvy bývá rozdělen (fragmentován) do
vı́ce datagramů, zde je spojujı́cı́ identifikačnı́ řetězec, všechny fragmenty posı́laných dat by
ovšem měly téměř stejné záhlavı́ lišı́cı́ se jen v položkách souvisejı́cı́ch s fragmentovánı́m,
• přı́znaky (3 bity, využity jsou jen dva) určujı́cı́ možnosti dalšı́ fragmentace datagramu na
mezilehlých uzlech sı́tě, prvnı́ bit (DF – don’t fragment) určuje, zda lze datagram po cestě
fragmentovat (hodnota 1 znamená nefragmentovat), druhý bit (MF – more fragments) je
v přı́padě dalšı́ fragmentace nastaven na 0 v poslednı́m fragmentu původnı́ho datagramu
(v ostatnı́ch fragmentech na 1), u nefragmentovaného datagramu je nastaven na 0,
• identifikace fragmentu (fragment offset, 13 bitů) – pokud je tento datagram po cestě dále fragmentován, je zde vzdálenost začátku tohoto fragmentu od začátku celého datagramu v násobcı́ch 64 bitů, prvnı́ fragment by zde měl hodnotu 0,
• TTL (8 bitů, Time to Live) určuje „životnost“ datagramu, na každém mezilehlém uzlu (směrovači) se snižuje (viz str. 231 a 10), sloužı́ k zamezenı́ „blouděnı́ “ nedoručitelných datagramů
v sı́ti,
• čı́slo protokolu (8 bitů) – zde jde o čı́slo protokolu vyššı́ podvrstvy sı́tě, a to obvykle 1 (ICMP),
2 (IGMP), 4 (IP-in-IP), 6 (TCP), 17 (UDP), 89 (OSPF), 133 (Fibre Channel) atd., určuje, jaký typ
dat je uvnitř datagramu,
• zabezpečenı́ záhlavı́ (16 bitů) – kontrolnı́ součet záhlavı́, přes předchozı́ 2oktetové sekvence,
• zdrojová a cı́lová IP adresa (po 32 bitech), zdrojová musı́ být vždy individuálnı́, cı́lová může být
i skupinová nebo všeobecná,
• volitelné – toto pole se většinou nepoužı́vá, je určeno pro dodatečné informace,
• data – informace bud’ některého transportnı́ho protokolu a nebo sı́t’ového (ICMP, IGMP nebo
některého směrovacı́ho protokolu), typ dat podle pole s čı́slem protokolu.
IP datagram může být dále fragmentován ve směrovačı́ch (tyto mezilehlé prvky také implementujı́
sı́t’ovou vrstvu), napřı́klad z důvodu usnadněnı́ přenosu (nižšı́ vrstvy na jiných zařı́zenı́ch mohou
optimálněji pracovat s menšı́mi PDU). Pokud se tak stane, výsledné fragmenty (což jsou také
datagramy) obsahujı́ původnı́ záhlavı́, ve kterém jsou pozměněna pole přı́znaků a identifikace
fragmentu podle potřeby se společnou hodnotou identifikace datagramu, a samozřejmě fragment
$
1.5
PROTOKOL IPV4
20
Data 6980 oktetů
oktety 0–6979
MF=0
F.offset=0
↓ MTU=3100 ↓
Fragmentace
délka datagramu: MTU − délka záhlavı́ = 3100 − 20 = 3080
„fragment offset“ pro prvnı́ fragment: 3080/8 = 385 (musı́ být celé č.)
MF=1
F.offset=385
Data1 3080 oktetů
oktety 0–3079
MF=1
F.offset=385
Data2 3080 oktetů
oktety 3080–6159
MF=0
F.offset=770
Data3 820 oktetů
oktety 6160–6979
Obrázek 1.9: Fragmentace u IPv4
datové části původnı́ho datagramu (postup je naznačen na obrázku 1.9). Při sestavovánı́ fragmentů
do původnı́ho datagramu na cı́lovém uzlu sı́tě lze shromáždit fragmenty původnı́ho datagramu
(podle pole id. datagramu), zjistit pořadı́ fragmentů (podle id. fragmentu) a dále určit poslednı́
fragment (bit MF).
Podle specifikace musı́ všechny uzly sı́tě bez problému zpracovávat datagramy o minimálnı́
délce 576 oktetů. Konkrétnı́ hodnota je na daném sı́t’ovém prvku stanovena hodnotou MTU (Maximum Transmission Unit). Jestliže je datagram moc velký, je fragmentován (pokud je to povoleno
v jeho přı́znacı́ch), jinak musı́ být zlikvidován a zaslána informace zdrojovému uzlu.
Hodnota MTU tedy určuje maximálnı́ velikost IP datagramu, který může přes dané zařı́zenı́
projı́t. Obvyklá hodnota je 1500, což je standardnı́ předevšı́m pro pakety přenášené po Ethernetu
plus IP záhlavı́. Pokud vı́me, že po cestě budou paketu přidávána dalšı́ záhlavı́ (napřı́klad přes
tunel), měli bychom MTU pro odchozı́ provoz nastavit raději na nižšı́ hodnotu, aby pakety nebyly
po cestě zahazovány. Jestliže do některého uzlu na cestě přijde paket většı́ než je MTU na odchozı́m
provozu, je zahozen a vysı́lajı́cı́ uzel je informován ICMP zprávou č. 3 (Destination Unreachable,
cı́l nedostupný) s kódem (parametrem zprávy) č. 4 (Fragmentation Needed and Don’t Fragment
was Set, nutno fragmentovat, přičemž nastaven přı́znak Nefragmentovat). Ted’ si představte, co se
stane, když na některém uzlu na cestě administrátor nastavı́ zahazovánı́ paketů s ICMP zprávami:
ICMP zpráva o nutnosti fragmentace nedojde ke zdroji paketu, tedy důsledkem je „černá dı́ra“ –
spojenı́ funguje, i když při zakázánı́ ICMP paketů asi přı́kaz ping neplnı́ svou roli tak jak by měl,
ale mnohé IP datagramy neprocházejı́, tedy napřı́klad webový prohlı́žeč mı́sto stránek zobrazuje
chybová hlášenı́.
Podle konvence jsou údaje v IP datagramu zası́lány ve formě big-endian, kdežto intelovské
procesory využı́vajı́ little-endian (vzpomeňte si na Operačnı́ systémy, tam jsme rozdı́l probı́rali).
Proto při zpracovánı́ IP datagramu na intelovském procesoru je nutné provádět konverzi, což může
zpracovánı́ mı́rně zdržet.
P
1.5
PROTOKOL IPV4
21
Úkoly
1. Zkompletujte, co vše se děje v přı́padě, že náš uzel poslal do sı́tě IPv4 datagram, který je většı́
než hodnota MTU někde na cestě (předpokládejme, že ICMP zprávy nejsou nikde zahazovány). Popište jednotlivé kroky a u samotné fragmentace si ujasněte, co bude v jednotlivých
polı́ch záhlavı́ datagramu.
2. V přı́loze v podsekci C.6.2 od strany 276 najděte přı́kazy, které v Linuxu sloužı́ k povolenı́
ICMP provozu ve firewallu.
1.5.2
Adresy IPv4
Adresa protokolu IPv4 zabı́rá 32 bitů (4 oktety) a skládá se ze dvou částı́ – adresy sı́tě a adresy uzlu
v sı́ti. 32 bitů by teoreticky znamenalo 232 = 4 294 967 296 možných adres, ale ve skutečnosti je to
mnohem méně – kromě jiného z „organizačnı́ch“ důvodů.
P
Původně se rozlišovalo 5 třı́d adres podle pozice rozhranı́ mezi sı́t’ovou a uzlovou částı́ adresy:
Třı́da A použı́vá prvnı́ oktet pro adresu sı́tě, zbytek je adresa uzlu v sı́ti, speciálnı́ adresa 127.0.0.0 je
vyhrazena pro loopback (zpětná smyčka, aby bylo možné přes sı́t’ové protokoly přistupovat
k témuž uzlu v sı́ti), adresa s prvnı́m oktetem nulovým nenı́ platná,
Třı́da B použı́vá pro adresu sı́tě prvnı́ dva oktety, zbytek je adresa uzlu v sı́ti,
Třı́da C použı́vá pro adresu sı́tě prvnı́ tři oktety, zbytek je adresa uzlu v sı́ti,
Třı́da D sloužı́ pro skupinovou adresaci, některé z těchto adres jsou vyhrazeny:
• 224.0.0.1 – skupina všech stanic připojených k mı́stnı́ podsı́ti,
• 224.0.0.2 – skupina všech směrovačů připojených k mı́stnı́ podsı́ti,
• 224.0.0.5 – skupina všech směrovačů směrujı́cı́ch podle OSPF,
• 224.0.0.6 – skupina všech jmenovaných směrovačů směrujı́cı́ch podle OSPF.
Třı́da E sloužı́ pro experimentálnı́ účely.
Struktura adres těchto třı́d je naznačena v tabulce 1.6.
Třı́da
A
B
C
D
E
Struktura adresy
Prvnı́ bity adresy
S.U.U.U
0xxx...
S.S.U.U
10xx...
S.S.S.U
110x...
skup.
exper.
1110...
1111...
Prvnı́ oktet
0–127
128–191
192–223
224–239
240–255
0–7F
80–BF
C0–DF
E0–EF
F0–FF
Max. počet stanic v sı́ti
224 − 2
216 − 2
254
–
–
Tabulka 1.6: Třı́dy IPv4 adres
Ze třı́d A–C jsou některé adresy vyhrazené:
• samostatná adresa sı́tě má všechny bity určené pro adresu uzlu v sı́ti nastaveny na 0, tedy
napřı́klad pro třı́du B to může být 137.24.0.0, adresa některé stanice v této sı́ti má pak alespoň
jeden z poslednı́ch dvou oktetů nenulový, napřı́klad 137.24.8.152,
P
1.5
PROTOKOL IPV4
22
• broadcast (všeobecná adresa) má naopak všechny bity určené pro adresu uzlu v dané sı́ti
nastaveny na 1, napřı́klad pro třı́du B to může být 137.24.255.255,
• broadcast bez určenı́ sı́tě (tj. v té sı́ti, kde byla zpráva vyslána) je 255.255.255.255, tj. všechny
bity jsou nastaveny na 1,
• loopback (zpětná smyčka) vždy začı́ná oktetem 127, nejpoužı́vanějšı́ je 127.0.0.1 (ale poslednı́
tři oktety mohou být teoreticky jakékoliv), jde o virtuálnı́ zařı́zenı́,
• adresy soukromých sı́tı́ (bez interakce s vnějšı́ sı́tı́) jsou
– 10.x.x.x pro třı́du A,
– 172.16.x.x až 172.31.x.x pro třı́du B,
– 192.168.0.x až 192.168.255.x pro třı́du C
(mı́sto „x“ je samozřejmě 0, protože jde o adresy sı́tě, pı́smeno je zde napsáno jen pro ilustraci
hranice mezi adresou sı́tě a uzlu).
Hlavnı́m účelem rozdělenı́ adres do třı́d bylo zjednodušenı́ směrovánı́ (směrovače nepotřebujı́ tak
rozsáhlé směrovacı́ tabulky), směrovánı́ bylo možné částečně řı́dit podle prvnı́ho oktetu adresy.
Podobný účel mělo také zavedenı́ dále popsaných metod.
Loopback. Vrat’me se nynı́ k mechanismu loopback (zpětné smyčky). Jak vı́me, jedná se vlastně
o jakýsi vnitřnı́ diagnostický mechanismus, který má každá stanice bez ohledu na jejı́ pozici v sı́ti.
Adresa začı́ná oktetem 127, ostatnı́ oktety mohou být obecně různé, ale obvykle je adresa 127.0.0.1.
Přı́klad
Vyzkoušı́me mechanismus loopback. Konkrétnı́ adresu zpětné smyčky pro svůj počı́tač zjistı́me
v souboru hosts:
• v unixových systémech /etc/hosts (někdy to může být /private/etc/hosts)
• ve Windows ...\system32\drivers\etc\hosts
V obou přı́padech bez přı́pony. Měla by tam být (kromě přı́padných dalšı́ch adres) adresa IPv4
a pravděpodobně i IPv6 loopbacku, napřı́klad ve Windows:
127.0.0.1
::1
localhost
localhost
Na Přı́kazovém řádku ověřı́me funkčnost loopbacku:
ping 127.0.0.1
Úkoly
Vyzkoušejte postup z předchozı́ho přı́kladu. Srovnejte výstupy přı́kazu ping napřı́klad s tı́mtéž
přı́kazem na adresu 77.75.76.3 (což je IP adresa web serveru seznam.cz). Všimněte si odezvy
a hodnoty TTL.
P
1.5
PROTOKOL IPV4
1.5.3
23
Překlad adres
Adresy soukromých (privátnı́ch) sı́tı́ se původně použı́valy pro sı́tě, které nebyly připojeny k Internetu, v současné době (při akutnı́m nedostatku adres) se využı́vajı́ pro podnikové nebo ISP sı́tě,
které tyto soukromé adresy skrývajı́. Jedná se o mechanismus NAT (Network Address Translation)
a mechanismus Masquerade (tzv. maškarádu). V obou přı́padech jde o překlad adres, který je zajišt’ován NAT serverem (často jde o implementaci NAT na směrovači). Vysvětlı́me si oba tyto pojmy
se všemi nuancemi.
1. DNAT (Destination NAT) je překlad cı́lové (destination) adresy (tj. hodnoty uložené v poli
„cı́lová adresa“ v IP datagramu) obvykle v přı́chozı́m provozu. Použı́vá se napřı́klad v mechanismu proxy pro přesměrovánı́ na uzel sı́tě zajišt’ujı́cı́ funkcionalitu proxy, adresa, kterou
do záhlavı́ ukládáme, musı́ být statická (musı́me ji znát).
2. SNAT (Source NAT) je překlad zdrojové adresy obvykle v odchozı́m provozu. Použı́váme
předevšı́m tehdy, když připojujeme sı́t’se soukromými adresami přes router (NAT server) se
statickou adresou (známe ji), pod touto adresou jsou zvnějšku viditelné všechny stanice ve
vnitřnı́ sı́ti.
Na NAT serveru je vedena tabulka překladu adres (tabulka spojenı́) obsahujı́cı́ dvojice adres
[IP adresa z Internetu, soukromá IP adresa], tj. evidujı́ se vlastně komunikace (navázaná
spojenı́) dané soukromé IP adresy. Pokud se v navázaném spojenı́ pokračuje a zvenčı́ dojde
na přeloženou adresu odpověd’, provede se zpětný překlad podle údajů uložených v tabulce
překladu adres, dohledá se, komu konkrétně je odpověd’ určena.
Mı́stnı́ sı́t’
Internet
PC
10.0.0.1
Router
IPAdrRouteru
Web server
77.75.76.3
Cı́l: 77.75.76.3
Zdroj: 10.0.0.1
Vytvoř záznam
[77.75.76.3 , 10.0.0.1]
Cı́l: 77.75.76.3
Zdroj: IPAdrRouteru
Cı́l: IPAdrRouteru
Zdroj: 77.75.76.3
Překlad podle
[77.75.76.3 , 10.0.0.1]
Cı́l: 10.0.0.1
Zdroj: 77.75.76.3
Obrázek 1.10: Překlad adres na směrovači – SNAT (statické) nebo Masquerade (dynamické)
P
1.5
PROTOKOL IPV4
24
3. SNAT+DNAT (plný NAT, také bezstavový NAT) představuje kombinaci obou předchozı́ch
s tı́m, že se překládá 1:1 (jedna statická na druhou statickou) bez zapamatovánı́ konkrétnı́ho
spojenı́ (proto bezstavový, bez zapamatovánı́ stavu spojenı́), což nenı́ nutné, protože pro
zpětný překlad se použije DNAT se statickými adresami. Použı́váme typicky pro skrývánı́
adresy serverů z našı́ sı́tě.
4. Masquerade (maškaráda) je oproti předchozı́m (předevšı́m oproti jinak podobnému SNAT)
určena pro plně dynamicky adresovanou sı́t’(tj. sı́t’se soukromými adresami, router je venku
viditelný také pod dynamickou adresou zı́skávanou napřı́klad od DHCP serveru ISP – poskytovatele internetu). Zdrojová adresa v paketu z vnitřnı́ sı́tě je před odeslánı́m paketu
ven přeložena na (dynamickou) adresu WAN rozhranı́ routeru, do tabulky spojenı́/překladu
adres je uložena informace o spojenı́, v opačném směru se provádı́ zpětný překlad.
Z toho vyplývá, že SNAT a maškaráda jsou určeny k témuž účelu, jen SNAT použı́váme, pokud
náš router má přidělenu pevnou IP adresu pro WAN port (viditelnou zvenčı́) – nemusı́ být veřejná,
ale musı́ být statická (pozor, nenı́ to totéž). Maškarádu zase použijeme, když adresu pro WAN port
dostáváme dynamicky. Princip vidı́me na obrázku 1.10.
Konkrétnı́ způsob nastavenı́ na routeru s Linuxem najdeme na straně 261 (přı́kaz ip) a 282
(mechanismus překladu adres ve firewallu NetFilter). Pokud někomu nenı́ jasný mechanismus
překladu, mohou tam uvedené přı́klady (hlavně na druhém odkazu) pomoci.
Překlad adres však působı́ problémy mnoha aplikacı́m, které použı́vajı́ IP adresu i pro jiné účely
než směrovánı́ (podobně jako třeba proxy). Problematická (třebaže řešitelná) je také spolupráce
NAT a protokolu IPSec (IP Security).
Obdobou NAT pro porty je PAT (Port Address Translation), kdy se překlad provádı́ mezi
různými porty. Toho se využı́vá tehdy, když potřebujeme překládat vı́ce různých soukromých
IP adres na jednu veřejnou (jednoznačnost překladu zajistı́me tak, že soukromé adresy jsou sice
mapovány na jedinou veřejnou, ale komunikace je rozlišena podle portů (každá soukromá adresa
má jiný port směrovače).
Na straně 12 bylo toto téma „nakousnuto“. Jak to funguje ve skutečnosti? Představme si, že v našı́
sı́ti s dynamickými adresami chtějı́ dva různé počı́tače komunikovat s tı́mtéž serverem na internetu.
Pokud bychom nepoužili PAT, došlo by k této situaci: každý z počı́tačů by poslal paket dotyčnému
serveru, přičemž by došlo k překladu (pravděpodobně pomocı́ Masquerade) zdrojových adres
v paketech (tj. adres odesı́lajı́cı́ch počı́tačů) na adresu routeru. Server na internetu by obdržel oba
pakety, ovšem oba by měly stejnou zdrojovou adresu. Pokud by odeslal odpověd’, v paketu by
nastavil cı́lovou adresu na tu, která byla uvedena v obou došlých paketech – adresu routeru. Ted’
by měl správně router v tomto paketu provést zpětný překlad, tentokrát cı́lové adresy (tj. svou
adresu by měl zaměnit za adresu skutečného cı́lového uzlu ze sı́tě), ale jak má poznat, pro který
z komunikujı́cı́ch počı́tačů je paket určen? Podle své tabulky by nemohl rozhodnout, protože tam
má dvě navázané (rovnocenné) relace s přı́slušným serverem na internetu.
PAT tuto situaci řešı́. Kromě mechanismu NAT identifikaci zpřesnı́me ještě tı́m, že každý z našich
počı́tačů v záhlavı́ UDP nebo TCP segmentu uvede jako zdrojový port čı́slo většı́ (nebo rovno) než
1024, každý počı́tač použije jiné. Zdrojový port ve směru od klienta nenı́ důležitý, proto se dá
využı́t právě pro zpřesněnı́ identifikace. V tabulce zařı́zenı́ provádějı́cı́ho PAT je kromě páru adres
$
P
L
1.5
PROTOKOL IPV4
25
uvedeno i toto čı́slo. Server z internetu ve svém paketu s odpovědı́ pak přehodı́ čı́sla zdrojového
a cı́lového portu, a tedy při zpětném překladu se stačı́ podı́vat na čı́slo cı́lového portu v segmentu.
Soukromé IP adresy se nesměrujı́, směrovač zahazuje každou datovou jednotku, jejı́ž cı́lová
adresa je soukromá (přesněji, PDU se soukromou adresou se nedostane do jiné sı́tě). To samozřejmě
nevylučuje funkčnost NAT na směrovačı́ch, protože zde je soukromá adresa obvykle použita jako
zdrojová, nikoliv cı́lová (jak ilustruje obrázek 1.10). Na tomto obrázku je adresa 10.0.0.1 soukromou
adresou přidělenou mechanismem DHCP (běžı́cı́m na routeru) pracovnı́ stanici.
1.5.4
E
Adresy podsı́tě
Jak bylo výše uvedeno, rozdělenı́ IP adres do třı́d přestalo být dostačujı́cı́. Tento mechanismus byl
rozšı́řen (přesněji rozšı́řen byl počet možnostı́, jak IP adresu rozdělit na části) na mechanismus
podsı́t’ovánı́ (subnetting).
IPv4 adresa se při použitı́ podsı́t’ovánı́ dělı́ na tři části:
P
• adresu sı́tě,
• adresu podsı́tě,
• adresu uzlu v (pod)sı́ti.
Směrovánı́ je tedy hierarchické se třemi úrovněmi. Každá stanice má přidělenu nejen svou IP
adresu, ale musı́ také znát masku podsı́tě, která určuje hranici mezi adresou podsı́tě a adresou uzlu
v sı́ti. Na pozicı́ch prvnı́ch dvou částı́ adresy (sı́t’a podsı́t’) má maska bity nastaveny na 1, na pozici
poslednı́ části (uzel) má bity nastaveny na 0.
Tento mechanismus je zpětně kompatibilnı́, napřı́klad pro adresu třı́dy B bez rozdělenı́ na
podsı́tě by maska byla 255.255.0.0, tedy v prvnı́ch dvou oktetech má všechny bity nastaveny na 1.
Přı́klad
Podobně s podsı́tı́ napřı́klad
• IP adresa ve třı́dě B je 154.56.201.107,
binárně 10011010.00111000.11001001.01101011
• maska podsı́tě je 255.255.255.224,
binárně 11111111.11111111.11111111.11100000
• adresu podsı́tě (včetně adresy sı́tě) zjistı́me operacı́ AND na binárnı́ch adresách:
binárně 10011010.00111000.11001001.01100000,
adresa podsı́tě 154.56.201.96 (z toho prvnı́ dva oktety určujı́ adresu sı́tě).
V rámci téže sı́tě mohou existovat i dalšı́ podsı́tě, napřı́klad adresa 154.56.152.160 může být adresou
dalšı́ podsı́tě.
Podsı́tě jsou výhodné z mnoha důvodů, z hlediska správce sı́tě je zde předevšı́m možnost rozdělit
stanice do skupin (segmentů), kde každá skupina stanic má svou vlastnı́ adresu podsı́tě (ale všechny
se stejnou maskou) a směrovače mohou zvlášt’směrovat jednotlivé segmenty.
P
1.5
PROTOKOL IPV4
26
Přı́klad
Ukážeme si jeden ze způsobů vytvořenı́ podsı́tı́ ze sı́tě třı́dy C. Postupy jsou popsány napřı́klad
v [2] nebo [3] ze seznamu doporučené literatury.
Předpokládejme tedy, že máme adresu sı́tě třı́dy C 192.168.35.0/24. Čı́slo za lomı́tkem značı́
počet bitů v masce nastavených na 1, zde je zřejmé, že maska bude 255.255.255.0 (tj. adresa třı́dy
C). V této sı́ti chceme vytvořit 5 podsı́tı́. Nejdřı́v zjistı́me, kolik bitů z poslednı́ho oktetu, který je
k dispozici, máme vyhradit pro adresu podsı́tě:
2N − 2 ≥ 5, chceme nejnižšı́ N, pro které rovnice platı́ (funkce 2N − 2 označuje počet platných
podsı́tı́). Vyhovuje N = 3. Poslednı́ oktet tedy rozdělı́me na 3 bity podsı́tě a zbývajı́cı́ch 5 bitů
použijeme pro adresu stanic v dané podsı́ti. „nulové“ hodnoty (všechny bity na 0) jsou zakázány.
Stanovenı́ prvnı́ podsı́tě:
Prvnı́ platné čı́slo podsı́tě je binárně 00100000, desı́tkově 32. To znamená, že adresa prvnı́ podsı́tě
je 192.168.35.32/27, prefix se prodloužil o 3. Adresy stanic v prvnı́ podsı́ti jsou 192.168.35.33 až
192.168.35.62, protože poslednı́ oktet může být binárně
00100001
...
00111110
(prvnı́ stanice v podsı́ti)
(poslednı́ stanice v podsı́ti)
Adresa všesměrového vysı́lánı́ (tj. broadcast) pro tuto podsı́t’ je 192.168.35.63/27 (poslednı́ oktet
00111111).
Stanovenı́ druhé podsı́tě:
Druhá podsı́t’ bude mı́t v adrese poslednı́ oktet binárně 01000000, desı́tkově 64. Všimněte si,
že je o 1 většı́ než tentýž oktet u adresy pro broadcast v prvnı́ podsı́ti. Adresa druhé podsı́tě je
192.168.35.64/27.
Vidı́me, že v adresách stanic bude poslednı́ oktet nabývat hodnot 01000001 až 01011110, desı́tkově 65 až 94. Adresa broadcastu pro druhou podsı́t’je 192.168.35.95/27.
Podobně postupujeme i dále – v adrese třetı́ podsı́tě bude poslednı́ oktet binárně 01100000,
desı́tkově 96, v adrese čtvrté podsı́tě binárně 10000000, desı́tkově 128, v adrese páté podsı́tě binárně 10100000, desı́tkově 160. Nesmı́me zapomı́nat, že všech zbývajı́cı́ch 5 bitů nabývá najednou
hodnoty 0 pouze v adrese podsı́tě a hodnoty 1 pouze v adrese broadcast adresy podsı́tě, tedy pro
stanice v podsı́ti volı́me hodnoty mezi těmito dvěma mezemi.
Shrneme adresy podsı́tı́:
Adresa podsı́tě
192.168.35.32/27
192.168.35.64/27
192.168.35.96/27
192.168.35.128/27
192.168.35.160/27
Poslednı́ oktet binárně
00100000
01000000
01100000
10000000
10100000
Prvnı́ stanice
Broadcast adresa
192.168.35.33/27
192.168.35.65/27
192.168.35.97/27
192.168.35.129/27
192.168.35.161/27
192.168.35.63/27
192.168.35.95/27
192.168.35.127/27
192.168.35.159/27
192.168.35.191/27
Jak vidı́me, nenı́ to zcela optimálnı́ rozdělenı́, některé adresy zůstávajı́ nevyužity, předevšı́m
proto, že jsme nevyčerpali všechny možnosti stanovenı́ podsı́tı́ (tři bity podsı́tě by ještě mohly
$
1.5
PROTOKOL IPV4
27
nabývat hodnot 110 a 111, ale „samé jedničky“ jsou opět rezervovány). Také podsı́t’s těmito třemi
bity nulovými nenı́ použitelná, protože se jedná o adresu celé sı́tě. Výhodou je však zjednodušenı́
směrovánı́ v sı́ti.
Hlavnı́ je, aby se adresy stanic v jednotlivých podsı́tı́ch nepřekrývaly, což máme zajištěno
vyhrazenı́m třı́ bitů pro jednoznačnou adresu podsı́tě.
Dalšı́m rozšı́řenı́m využitı́ podsı́tı́ bylo zavedenı́ mechanismu VLSM (Variable Length Subnet Masks).
Tento mechanismus umožňuje v rámci jedné sı́tě použı́vat několik různých masek podsı́tě (to znamená nejen vı́c různých adres podsı́tě, ale navı́c i různě dlouhých). Výsledné adresy stanic přesto
musejı́ zůstat jednoznačné, což znamená určitá omezenı́ při volbě adres podsı́tı́ a uzlů.
P
V praxi se tento mechanismus použı́vá pro podrobnějšı́ hierarchické dělenı́ (v rámci podsı́tě
může být vı́ce vnořených podsı́tı́ apod.), což opět lze s výhodou využı́t při zjednodušenı́ směrovánı́.
Přı́klad
Počet bitů sı́tě a podsı́tě se zapisuje za adresou. Napřı́klad
• 154.56.0.0/16 je adresa sı́tě (třı́da B),
• 154.56.32.0/20 je adresa podsı́tě (celkem 20 bitů, tj. pro podsı́t’ovánı́ jsou použity 4 bity),
• 154.56.32.0/26 je adresa vnořené podsı́tě podle VLSM (v rámci původnı́ podsı́tě vytvořı́me
dalšı́ podsı́t’na 6 bitech), bity navı́c zde zůstávajı́ nastaveny na 0, i když to nenı́ zapotřebı́.
Obecně opět nelze využı́vat „nulové“ krajnı́ hodnoty, přesto však na některých routerech (např. od
firmy Cisco) lze zapnout možnost jejich využı́vánı́.2
Dalšı́ „generacı́“ vylepšenı́ je CIDR (Classless Interdomain Routing, beztřı́dnı́ směrovánı́), také
se nazývá nadsı́t’ovánı́ (supernetting). Jedná se o úplné odbouránı́ členěnı́ IP adres do třı́d (classless).
CIDR členı́ IP adresu na dvě části – prefix a adresu uzlu. Prefix je vlastně shrnutı́m původnı́ch adres
sı́tě a podsı́tě.
Zápis je zcela zpětně kompatibilnı́. Stejně jako u VLSM se délka prefixu zapisuje za adresu
a podle tohoto čı́sla lze zjistit hranici mezi prefixem (obdobou adresy sı́tě/podsı́tě) a adresou uzlu.
Přı́klad
Napřı́klad u adresy 154.56.129.48/23 je délka prefixu 23, to znamená, že
• maska je binárně 11111111.11111111.11111110.0,
decimálně 255.255.254.0,
• prefix je binárně 10011010.111000.10000000.0,
decimálně 154.56.128.0 (převedeme původnı́ adresu do binárnı́ formy a provedeme operaci
AND s maskou).
2
V Cisco IOS novějšı́ch verzı́ se zapnutı́ provádı́ přı́kazem ip subnet-zero.
P
1.5
PROTOKOL IPV4
28
Délka prefixu 23 nechává zbytek adresy (tj. 9 bitů vpravo) adresám stanic, tj. 512 možných adres
stanic, kdežto napřı́klad pro prefix 18 by to bylo 15 bitů pro adresy stanic, což znamená 16 384
adresovatelných stanic pro prefix.
Stanovenı́ prefixů a adres stanic je podobné jak jsme viděli na přı́kladu pro třı́dy adres, jen nejsme
omezeni hranicemi třı́d a prefixy mohou nabývat různých délek.
Zajı́mavým projektem je Subnet Calculator (http://www.subnet-calculator.com/), kde si přı́mo na
webu můžeme stanovit počet bitů podsı́tě a zı́skáme počet podsı́tı́, počet stanic v podsı́ti a rozpětı́
adres. Problematika stanovovánı́ podsı́tı́ a rozdělovánı́ adres je probı́rána v mnoha zdrojı́ch, zajı́mavý pohled je napřı́klad v literatuře [2] (najdete v seznamu literatury).
1.5.5
Jak stanice může zı́skat IPv4 adresu
U IPv4 existujı́ dvě základnı́ možnosti zı́skánı́ adresy – staticky a dynamicky.
Statická adresa je pevně přidělená, je třeba ji stanoveným způsobem nakonfigurovat, at’ už
ve Windows (v Ovládacı́ch panelech najdeme nástroj pro práci se sı́t’ovými připojenı́mi, název
záležı́ na verzi, v seznamu připojenı́ najdeme to, které chceme konfigurovat, zvolı́me vlastnosti,
tam v seznamu použı́vaných protokolů najdeme TCP/IPv4, vlastnosti) nebo v Linuxu (také lze
v grafickém rozhranı́).
Statická adresa může být veřejná nebo soukromá. Mnozı́ poskytovatelé Internetu ještě nedávno
inzerovali, že každý klient dostane statickou IP adresu, ale vesměs šlo o adresu soukromou.
Statická adresa je potřebná předevšı́m u těch uzlů sı́tě, které majı́ být (trvale) dostupné. Předevšı́m jde o servery a důležitějšı́ sı́t’ové prvky.
Dynamické adresy jsou obvyklé předevšı́m u běžných pracovnı́ch stanic (takových, které majı́
vlastnı́ operačnı́ systém, nejde o tenké klienty). Dynamickou adresu zı́ská zařı́zenı́ přes protokol
DHCP. Komunikace mezi DHCP klientem a DHCP serverem je naznačena na obrázku 1.11. Všimněte si, že jde o broadcasty (bud’ adresa 255.255.255.255, a nebo mı́stnı́ broadcast pro danou podsı́t’),
protože klient ještě nemá přidělenou adresu (tudı́ž nemůže jı́t o unicast pakety). Od prvnı́ho kroku
je v parametrech DHCP paketu MAC adresa klienta, tedy by nemělo dojı́t k neúmyslné záměně
s jiným žádajı́cı́m uzlem.
DHCP server si vede zásobnı́k adres (Address Stack, Pool), což je vlastně seznam adres, které
může přidělit. Po přidělenı́ je adresa označena jako použitá (přidělená) a jsou k nı́ evidovány
všechny potřebné informace (předevšı́m MAC adresa zařı́zenı́, kterému je přidělena). Adresa je ve
skutečnosti pronajata (leased) na konkrétnı́ dobu. Tato doba je různá, záležı́ na konfiguraci DHCP
serveru, může jı́t o hodiny až dny. Po vypršenı́ propůjčenı́ adresy musı́ zařı́zenı́ opět o adresu
požádat.
Kromě IP adresy DHCP server poskytuje dalšı́ informace, předevšı́m masku podsı́tě, výchozı́
bránu, adresy DNS serverů.
DHCP server může běžet napřı́klad na směrovači. V sı́ti obvykle bývá jeden DHCP server, aby
nedocházelo ke kolizı́m (nezapomeňme, že stanice „objevuje“ DHCP server broadcastem, měla by
dostat jen jednu nabı́dku adres).
$
1.6
PROTOKOL IPV6
29
DHCP
klient
DHCP
server
UDP broadcast DHCP Dicscover
source 0.0.0.0, sport=68
dest 255.255.255.255, dport=67
Kdo mi dá adresu?
V DHCP paketu může být žádost
o dřı́ve použı́vanou adresu.
UDP broadcast DHCP Offer
source IP adr. DHCP serveru, sport=67
dest 255.255.255.255, dport=68
V DHCP paketu je nabı́dka adres,
maska, brána, doba platnosti, DNS
servery.
UDP broadcast DHCP Request
source 0.0.0.0, sport=68
dest 255.255.255.255, dport=67
Žádost o konkrétnı́ adresu (v polı́ch DHCP paketu je žádaná adresa
a adresa serveru, který ji nabı́dl).
UDP broadcast DHCP Ack
source IP adr. DHCP serveru, sport=67
dest 255.255.255.255, dport=68
Potvrzenı́ (acknowledgement) přidělenı́ IP adresy, v polı́ch DHCP paketu je opět nabı́dka adres, maska,
brána, doba platnosti, DNS servery.
Obrázek 1.11: Obvyklý postup zı́skánı́ dynamické adresy
Kombinacı́ statického a dynamického přı́stupu je statická alokace. Jde o to, že klient sice zı́skává
adresu přes DHCP, ale vždy stejnou, což může usnadnit fungovánı́ služeb vázaných na konkrétnı́ IP
adresu. Jde o to, že v konfiguraci DHCP serveru se ke konkrétnı́ IP adrese ručně namapuje konkrétnı́
MAC adresa. Ovšem ne každý DHCP server tuto možnost poskytuje a výrobci ji označujı́ různými
názvy (Static DHCP, MAC/IP Binding, Reserved IP Address, IP Reservation, apod.).
Bezdiskové stanice (tenké klienty) majı́ specifické způsoby zı́skávánı́ adres. Tato problematika je
popsána také na http://www.fi.muni.cz/~kas/p090/referaty/2008-podzim/ct/dhcp.html.
Úkoly
V přı́lohách najděte přı́kazy umožňujı́cı́ zjistit a nastavit IP adresu ve Windows a v Linuxu. Vyzkoušejte (v tom operačnı́m systému, který máte k dispozici).
1.6
Protokol IPv6
Protokol IP verze 6 (IPv6, také IPng – next generation) má vyřešit zoufalou situaci s akutnı́m
nedostatkem adres protokolu IPv4. Zatı́mco adresy IPv4 zabı́rajı́ 32 bitů, adresy IPv6 jsou dlouhé
128 bitů, což by bohatě mělo stačit pro jakákoliv zařı́zenı́ na světě (teoreticky jde o počet 1038 adres).
P
1.6
PROTOKOL IPV6
30
Přı́nos IPv6 je však mnohem širšı́. Stručně lze shrnout rozdı́ly takto:
•
•
•
•
•
rozsah adres,
podpora bezpečnostnı́ch funkcı́ (v IPv4 tyto funkce zajišt’oval protokol IPSec),
zvýšená podpora pro mobilnı́ zařı́zenı́ (MIPv6),
možnost autokonfigurace stanice (zjednodušené zı́skánı́ IP adresy),
QoS – zajišt’ovánı́ úrovně služeb na mnohem vyššı́ úrovni, atd.
P
Přechod na IPv6 by měl být výhodný nejen z hlediska počtu adres a zajištěnı́ bezpečnosti, ale také
pro služby VoIP, videokonference, RFID, grid computing, on-line hry, inteligentnı́ budovy apod.
Jedno sı́t’ové rozhranı́ může mı́t i vı́ce než jednu IPv6 adresu.
Dalšı́ informace jsou na
http://www-01.ibm.com/support/knowledgecenter/ssw i5 54/rzai2/rzai2compipv4ipv6.htm?lang=cs
Protokoly IPv4 a IPv6 mohou být použı́vány zároveň, dokonce i na tomtéž uzlu v sı́tě.
Hlavnı́m garantem přidělovánı́ IPv6 adres je ICANN (Internet Corporation for Assigned Network Numbers, http://www.icann.org), kdežto organizace IANA (Internet Assigned Numbers Authority, http://www.iana.org/) toto přidělovánı́ fyzicky provádı́.
Celková struktura přidělovánı́ adres je hierarchická. IANA přiděluje bloky adres regionálnı́m
registrátorům RIR, což jsou RIPE (Evropa a část Asie), ARIN (Severnı́ Amerika), AfriNIC (Afrika),
LACNIC (Latinská Amerika), APNIC (Asie a Pacifik). Dalšı́ patro hierarchie tvořı́ lokálnı́ registrátoři
(LIR), kteřı́ své bloky zı́skávajı́ od regionálnı́ch registrátorů. Od lokálnı́ch registrátorů pak své
rozsahy adres zı́skávajı́ zákaznı́ci nebo dalšı́ subjekty, které mohou své rozsahy dále distribuovat.
1.6.1
IPv6 datagramy
Struktura datagramu verze 6 je oproti verzi 4 značně pozměněná. Hlavnı́ odlišnost je struktura
záhlavı́. Zatı́mco datagram IPv4 má záhlavı́ proměnné délky a se spoustou informacı́ (z nichž
některé obecně nejsou využı́vány), datagram IPv6 má záhlavı́ pevné délky a informacı́ je v něm
mnohem méně. Důsledkem je rychlejšı́ směrovánı́ (směrovače zpracovávajı́ záhlavı́ a takto majı́
usnadněnou práci).
Datagram IPv6 má jedno povinné záhlavı́ pevné délky a pak mohou následovat volitelná záhlavı́
s proměnnou délkou.
Formát povinného záhlavı́ IPv6 datagramu je v tabulce 1.7. Význam jednotlivých polı́:
• verze (4 bity) – verze protokolu (tedy 6), toto pole má stejný rozměr a určenı́ jako u IPv4 (jen
logicky jiný obsah),
• priorita (8 bitů) – podobně jako pole typ služby u IPv4, jednotlivé bity umožňujı́ optimalizaci
priorit, toto pole (zároveň s následujı́cı́m) se použı́vá pro QoS,
• označenı́ datového toku (20 bitů) – stanovuje způsob „speciálnı́ho zacházenı́“ na směrovačı́ch
pro některé typy protokolů, s pakety patřı́cı́mi do téhož datového toku se má zacházet stejně
(žádný datový tok: = 0), má význam také pro QoS,
P
P
1.6
PROTOKOL IPV6
31
4
8
verze
priorita
délka dat
4
8
8
označenı́ datového toku
dalšı́ záhlavı́
hop limit
zdrojová IP adresa
cı́lová IP adresa
Tabulka 1.7: Povinné záhlavı́ datagramu protokolu IPv6
• délka dat (16 bitů) – délka zbytku datagramu (bez povinného záhlavı́), tj. všech volitelných
záhlavı́ a vlastnı́ch dat; pokud je zde hodnota 0, jedná se o tzv. jumbogram – datagram extrémnı́
velikosti (až 4 GB), což musı́ být podporováno hardwarem ve všech prvcı́ch sı́tě na cestě a je
nutné mı́t správně nakonfigurovanou hodnotu MTU,
• dalšı́ záhlavı́ (8 bitů) – určuje typ následujı́cı́ho (volitelného) záhlavı́ téhož datagramu, pokud
už žádné nenásleduje, je zde čı́slo 59,
• hop limit – obdoba TTL u IPv4, označuje maximálnı́ počet směrovačů na cestě,
• zdrojová a cı́lová IP adresa (obě 128 bitů, tj. pro každou adresu 4 řádky tabulky 1.7).
IPv6 nedovoluje fragmentaci datagramu na směrovačı́ch po cestě, datagram může být fragmentován
pouze na zdrojové stanici.
Volitelná záhlavı́ následujı́ za povinným záhlavı́m v předem daném pořadı́ (tedy pořadı́ je
důležité, RFC 2460), některá (nebo i všechna) mohou být vynechána. Každý typ volitelného záhlavı́
má své čı́slo, toto čı́slo najdeme v poli „dalšı́ záhlavı́“ předchozı́ho záhlavı́ (tj. v povinném záhlavı́
zjistı́me, jakého typu je prvnı́ volitelné záhlavı́, v prvnı́m zjistı́me typ druhého volitelného, atd.).
Některá z použı́vaných volitelných záhlavı́:
• hop-by-hop options header (0, informace pro směrovače na cestě, směrovače čtou jen toto záhlavı́),
• routing header (čı́slo 43, zde mohou být určeny směrovače, přes které má cesta vést, v obráceném pořadı́ je závazné i pro odpověd’),
• fragment header (44, pokud je datagram na zdrojové stanici fragmentován, je použito toto
záhlavı́ s informacı́ o fragmentaci, podobné údaje jako v záhlavı́ IPv4; stanice musı́ znát
hodnoty MTU na cestě),
• authentication header (čı́slo 51, obsahuje autentizačnı́ informaci),
• encapsulating security header (50, údaje o šifrovánı́),
• TCP segment (6), UDP segment (17), ICMP paket (58), . . .
L
1.6
PROTOKOL IPV6
1.6.2
32
Adresy IPv6
Adresa v IPv6 se skládá ze dvou částı́ – prefixu a identifikátoru sı́t’ového rozhranı́ (adresy uzlu v rámci
jednoho prefixu).
Podobně jako u IPv4 adres, i zde je snaha o co největšı́ zjednodušenı́ směrovánı́, proto adresy
často odrážejı́ fyzickou strukturu sı́tě propojené směrovači (i v globálnı́m měřı́tku). IANA přiděluje základnı́ rozsahy (prvnı́ch 12 bitů, tj. prefix má v takovém rozsahu délku 12) jednotlivým
regionálnı́m registrátorům (kryjı́ se přibližně s kontinenty – RIR, Regional Internet Registry), ti své
rozsahy dále distribuujı́ (napřı́klad na 32 bitů, kde by délka prefixu byla 32). Dalšı́ dělenı́ provádějı́
poskytovatelé Internetu a samozřejmě pro své podsı́tě jednotlivé organizace.
Rozlišujı́ se adresy
• unicast (konkrétnı́ uzel v sı́ti),
• multicast (skupinové),
• anycast (adresace komukoliv ze zadané skupiny).
P
P
Broadcast adresy již nejsou podporovány.
Adresy majı́ jiný způsob zápisu. Jednotlivé části (což jsou dvojice oktetů, nikoliv samotné oktety
jako v IPv4) se oddělujı́ dvojtečkou a zapisujı́ se hexadecimálně. To znamená, že adresa má celkem
8 částı́ (128/16). Adresa může vypadat napřı́klad takto:
A4CB:57B1:60AA:2F0E:113A:B201:042A:02B1
Adresa je velmi dlouhá a těžko si ji někdo zapamatuje (i když vyloučeno to samozřejmě nenı́).
Oproti IPv4 lze zápis zjednodušit odstraněnı́m posloupnosti nulových skupin oktetů. V jedné
adrese tak můžeme odstranit pouze jednu posloupnost nul a mı́sto odstraněnı́ musı́ být označeno
dvojitou dvojtečkou, napřı́klad adresu
A4CB:57B1:0000:0000:0000:B201:042A:02B1
lze zkrátit na
A4CB:57B1::B201:042A:02B1
a můžeme také vynechat nuly ve skupinách oktetů vlevo:
A4CB:57B1::B201:42A:2B1
Přı́klad
Opravdu lze krátit pouze jednu jedinou posloupnost nul. Napřı́klad adresu
2001:0db8:3c4d:0000:0000:a011:0000:0000
lze zkrátit jednı́m z těchto způsobů:
2001:0db8:3c4d:0000:0000:a011:: (respektive 2001:db8:3c4d:0:0:a011::)
2001:0db8:3c4d::a011:0000:0000 (respektive 2001:db8:3c4d::a011:0:0)
špatně by bylo 2001:0db8:3c4d::a011::
protože by taková adresa byla nejednoznačná. Podle počtu částı́ adresy je zřejmé, že nulové jsou
celkem čtyři části (celkem jich musı́ být 8), ale když v adrese vidı́me dvě mı́sta krácenı́, nemůžeme
přesně řı́ci, jak jsou mezi ně tyto čtyři nulové části rozmı́stěny. Mohla by to být napřı́klad i chybná
možnost 2001:0db8:3c4d:0000:a011:0000:0000:0000
$
1.6
PROTOKOL IPV6
33
U (nejen) většı́ch organizacı́ bývá zvykem dělit vnitřnı́ sı́t’na podsı́tě. Organizace dostane přidělen
vlastnı́ prefix a zařı́zenı́m ve své sı́ti pak přiděluje adresy podle tohoto prefixu. Může si však
stanovit širšı́ prefixy, které obsahujı́ původnı́ prefix a několik bitů navı́c, a každý z nich přidělı́
jedné své podsı́ti.
Přı́klad
Organizace může využı́vat napřı́klad takovéto adresovánı́:
A4CB:57B1:B201::/48
prefix přidělený organizaci
A4CB:57B1:B201:1::/64
prefix pro prvnı́ podsı́t’
A4CB:57B1:B201:2::/64
prefix pro druhou podsı́t’
A4CB:57B1:B201:3::/64
prefix pro třetı́ podsı́t’
A4CB:57B1:B201:1::4A/64
adresa některé stanice v prvnı́ podsı́ti
Dvě vyhrazené adresy:
• ::/128 je „nedefinovaná adresa“ (stanice nemá přidělenou adresu, všechny části jsou 0),
• ::1/128 je loopback (lokálnı́ smyčka).
P
Dalšı́ vyhrazené adresy – skupinové:
• FF00::/8 – skupinová adresa představujı́cı́ všechny dostupné DHCP servery,
• FF02::2 – skupinová adresa všech dostupných směrovačů,
• FF02::1 – skupinová adresa všech uzlů sı́tě podporujı́cı́ch IPv6.
Podobně jako u IPv4, i zde rozlišujeme globálnı́ a lokálnı́ adresy, ale účel a princip je trochu jiný.
Adresy s prefixem 2000::/3 jsou globálnı́, pomocı́ těchto adres lze komunikovat na Internetu. Dále
existujı́ tyto typy lokálnı́ch adres:
P
• unique local (ULA adresy) – prefix FD00::/8, sloužı́ k posı́lánı́ unicast dat v rámci lokálnı́ sı́tě
(organizace apod.), je to obdoba soukromé IP adresy v IPv4, nesmı́ být viditelná mimo lokálnı́
sı́t’, ale je zde zaručena unikátnost (narozdı́l od následujı́cı́ho typu adresy),
• link local – prefix FE80::/10, tato adresa je lokálnı́ v rámci podsı́tě (segmentu, tj. v rozmezı́
viditelnosti linkové vrstvy L2 daného zařı́zenı́), link local adresy nepřejdou přes směrovač
a obvykle každá sı́t’ová karta má tuto adresu přidělenu při své aktivaci.
Unikátnost ULA adresy se zajišt’uje odvozenı́m z data (času) generovánı́ adresy a z MAC adresy
stanice.
Původně se počı́talo ještě s tzv. site local adresou, která by fungovala přesně jako lokálnı́ adresy
v IPv4 (včetně překladu adres), jejı́ prefix je FEC0::/10.
1.6.3
Jak stanice může zı́skat IPv6 adresu
Předně je důležité, že každý směrovač v sı́ti vysı́lá v pravidelných intervalech informaci označenou
RA (Router Advertisement, oznámenı́ směrovače). Součástı́ této informace je prefix adres v sı́ti
a adresa směrovače, přes který lze dostat pakety ven ze sı́tě. Pokud tedy stanice potřebuje tuto
P
1.6
PROTOKOL IPV6
34
informaci (určitě ji potřebuje, když postupně zjišt’uje, jakou má mı́t IP adresu), tak bud’ naslouchá
na sı́ti a nebo nečeká a informaci si vyžádá žádostı́ RS (Router Solicitation, žádost o informace
o směrovači a prefixu). Mechanismus RA nesouvisı́ s DHCP, funguje i v přı́padě, že v sı́ti nenı́
žádný DHCP server. Použı́vajı́ se ICMP zprávy.
Podı́váme se tedy na jednotlivé možnosti zı́skánı́ celé IPv6 adresy.
1. Dynamicky přes DHCP server (Stavový režim DHCP, RFC 3315). DHCP server eviduje propůjčené IP adresy a stanice, kterým je udělil (tato informace představuje momentálnı́ stav protokolu),
proto stavový režim.
$
Obě strany jsou na začátku komunikace identifikovány pomocı́ DUID (mı́sto MAC adresy)
– DHCP Unique ID. Je to jednoznačný identifikátor generovaný z vı́ce různých parametrů, je
částečně nezávislý na HW. DUID najdeme ve Windows v registru, v UNIX-like systémech obvykle
v souboru /var/db. Je důležité, že pokud máme vı́c na počı́tači vı́c operačnı́ch systémů (at’už dı́ky
virtualizaci nebo na různých oddı́lech), každý má jiné DUID.
Ve stavovém režimu DHCP se postupuje takto:
• stanice vyšle multicast na FF00::/8 s dotazem na DHCP servery,
• DHCP server(-y) odpovı́ svou IP adresou na FF02::1 a svým DUID s nabı́dkou,
• Request – stanice (DHCP klient) si vybere (podle nabı́zených parametrů) a pošle anycast
s uvedeným DUID serveru žádost o adresu (uvede také své DUID),
• Reply – odpověd’ serveru: IPv6 adresa (včetně prefixu), délka prefixu v adrese, přı́padně IP
adresy DNS serverů,
• stanice zkontroluje, jestli adresa nenı́ duplicitnı́; pokud ano, odmı́tne (Decline) a vrátı́ se k 3.
bodu.
Adresa je dočasná, je propůjčena na určitou dobu. Po uplynutı́ této doby stanice odešle žádost
o potvrzenı́ adresy. DHCP server si při změně sı́t’ových parametrů může vynutit reakci u klientů
zprávou Reconfigure.
Pokud klient odcházı́ ze sı́tě, informuje DHCP server zprávou o uvolněnı́ (Release). Pokud jen
dočasně opustil sı́t’(třeba restart), pak odesı́lá žádost o potvrzenı́ původnı́ch parametrů (Confirm)
na skupinovou adresu DHCP serverů, DHCP server potvrdı́ nebo odmı́tne.
Ostatnı́ způsoby přidělovánı́ adres jsou nestavové (nestavové chovánı́ DHCPv6), protože nenı́
potřeba informace o jiných adresách v sı́ti.
2. Autokonfigurace stanice s EUI-64. Proces autokonfigurace má usnadnit počátečnı́ konfiguraci
(a také přihlašovánı́) uživatelské stanice ze strany ISP, správu připojených zařı́zenı́, která nejsou
počı́tači (napřı́klad domácı́ spotřebiče), značně se také zjednodušuje konfigurace stanic propojených
ad-hoc (bez serveru a směrovačů). Můžeme se také setkat se zkratkou SLAAC (Stateless Address
Autoconfiguration). Abychom si ujasnili vztah RA a SLAAC: nenı́ to totéž. Statická konfigurace
SLAAC využı́vá mechanismus RA ke zkompletovánı́ adresy v sı́t’ové části.
Autokonfigurace se provádı́ přes protokol ICMPv6 a spočı́vá v mechanismu zjišt’ovánı́ sousedů
(neighborhood), viz str. 37. Každá stanice má svůj jednoznačný identifikátor EUI (Extended Unique
Identifier) vycházejı́cı́ z MAC adresy. EUI-64 (zabı́rajı́cı́ 64 bitů) se zı́ská z MAC (48bitové) vloženı́m
$
P
1.6
PROTOKOL IPV6
35
sekvence 0×FFFE přesně uprostřed a změnou jednoho bitu – sedmého bitu v prvnı́m oktetu na 1
(tento bit je označován jako U/L). Jak bylo výše uvedeno, IPv6 adresa může být takto jednoduše
mapována z MAC adresy.
Postup při nestavovém DHCP (RFC 2462, pak RFC 4862):
• uzel vytvořı́ link-local adresu (použije prefix FE80::/10, zbytek adresy vytvořı́ z EUI-64 nebo
jiným způsobem),
• provede detekci duplicitnı́ch adres, aby bylo jisté, že má jedinečnou adresu v sı́ti (přes ICMPv6
se zeptá souseda, ten se ozve, pokud adresu zná ⇒ adresu by už měl jiný uzel) – využije
mechanismus zjišt’ovánı́ sousedů,
• z RA zı́ská informace – prefix podsı́tě, dalšı́ informace o směrovači apod. (poslouchá na adrese
FF02::1 – skupina všech zařı́zenı́ podporujı́cı́ch IPv6); pokud nechce čekat na RA, pošle na
FF02::2 RS (žádost o RA),
• z toho všeho vytvořı́ svou platnou IPv6 adresu.
Zbývá zjistit adresy DNS serverů.
Přı́klad
EUI-64 se určı́ následovně:
1234:5678:9ABC:DEF0::/64
je prefix sı́tě, stanice ho zjistila výše popsaným způsobem od smě-
rovače
00-20-ED-89-A0-4E
je MAC adresa stanice
je EUI-64 (v prvnı́m oktetu jsme zaměnili hodnotu předposlednı́ho bitu
na 1, doprostřed je vsunut dvojoktet FFFE)
0220:EDFF:FE89:A04E
1234:5678:9ABC:DEF0:0220:EDFF:FE89:A04E
je výsledná IP adresa stanice
Velký problém je, že narozdı́l od DHCP nenı́ běžnou součástı́ RA tak důležitá informace jako jsou
IP adresy jmenných (DNS) serverů. Tyto adresy jsou pro správné fungovánı́ stanice na Internetu
důležité, uživatel přece nebude pracovat s čı́selnými IP adresami (ještě k tomu tak dlouhými).
V současné době existujı́ tři různá řešenı́:
1. Přidánı́ informace o DNS serverech do RA ohlašovánı́ (standardizováno na podzim 2010,
RFC 6106). Tuto možnost je nutné nejdřı́v implementovat. Zatı́m tuto možnost podporuje jen
RA řešenı́ pro Linux (a některé dalšı́ UNIXy) – démon radvd. Na dalšı́ch systémech (zvláště
u Windows) si ještě dlouho počkáme.
2. Speciálnı́ anycast adresy pro DNS servery. Tato možnost nebyla nikdy dotažena do konce,
existuje pouze ve verzi draft, předevšı́m proto, že počı́tá se site-local adresami, které byly ze
specifikace IPv6 vypuštěny. Implementaci najdeme v některých řešenı́ch od Microsoftu, ale
nedoporučuje se je použı́vat.
3. Kombinace RA a DHCPv6. Přes RA (přı́padně s požadavkem RS) si stanice vyžádá informace
o sı́ti a směrovači, dotvořı́ si svou adresu pomocı́ EUI-64 (nebo Privacy Extensions popsaných
nı́že), info o DNS serverech zı́ská z DHCPv6.
$
1.6
PROTOKOL IPV6
36
3. Autokonfigurace s Privacy Extensions. Účelem tohoto mechanismu je co nejvı́ce ztı́žit identifikaci koncových zařı́zenı́ (předevšı́m potenciálnı́mu útočnı́kovi, ale chaos si cı́l nevybı́rá). Hostitelská část adresy (adresa stanice v sı́ti) je dynamicky generována a obměňována přibližně jednou
za několik dnů (doba se dá nakonfigurovat). To má bezpochyby své výhody, ale ze strany administrátora sı́tě jde o celkem podstatnou nevýhodu – do sı́tě se mu každou chvı́li dostane zařı́zenı́
s „novou“ IP adresou.
$
Privacy Extensions se použı́vajı́ předevšı́m ve Windows, kdežto unixové systémy ji majı́ standardně vypnutou. Protože vypnutı́ Privacy Extensions ve Windows může mı́t pro některé uzly
v sı́ti neočekávané nepřı́znivé důsledky, administrátoři si k udrženı́ pořádku v sı́ti a přehledu
o přihlášených zařı́zenı́ch museli najı́t různé „okliky“ a nástroje, napřı́klad volně šiřitelný nástroj
MetaNAV.3
Jinak lze význam Privacy Extensions přirovnat k EUI-64, taktéž je potřeba navı́c zı́skat prefix
a dalšı́ informace (což jsme si popsalı́ právě v bodě o EUI-64).
4. Statická konfigurace. Staticky se konfiguruje bud’ celá 128bitová adresa, nebo jejı́ 64bitový
prefix (a zbytek adresy stanice dotvořı́ z EUI-64).
IP adresy jmenných serverů nejsou během statické konfigurace zadávány, stanice je zjistı́ stejně
jako u bezstavového DHCPv6.
$
Úkoly
Pokud máte IPv6 adresu, zjistěte, jakým způsobem byla vytvořena (do značné mı́ry to také závisı́
na tom, v jakém operačnı́m systému pracujete).
1.6.4
Zóny
V praxi se lze setkat se zařı́zenı́mi, která majı́ vı́ce než jedno sı́t’ové rozhranı́ (napřı́klad zařı́zenı́
se dvěma sı́t’ovými kartami). Problém může nastat, pokud se pro toto zařı́zenı́ použije link-local
adresa. V přı́padě, že každé rozhranı́ je připojeno k jiné sı́ti (napřı́klad u dvou rozhranı́ s link-local
adresami fe80::1/64 a fe80::2/64) a je třeba poslat paket některému zařı́zenı́ patřı́cı́mu jen
do jedné z těchto sı́tı́, které má taky link-local adresu (napřı́klad fe80::3/64), nenı́ jasné, které
rozhranı́ vlastně použı́t, protože k rozlišenı́ nenı́ možné použı́t prefix.
Tato nejednoznačnost se řešı́ definovánı́m zón. Kromě informace o adrese rozhranı́ je evidována
také zóna, která již jednoznačně určuje sı́t’u lokálnı́ch adres. Na konec IPv6 adresy se připojı́ symbol
procenta a za něj označenı́ zóny. Obvyklé označenı́:
• IPv6adresa%čı́slo (ve Windows), napřı́klad
fe80::94fd:241e:a5a1:d4bb%9
• IPv6adresa%ethčı́slo (v Linuxu), napřı́klad
fe80::94fd:241e:a5a1:d4bb%eth1
3
http://metanav.uninett.no/
1.6
PROTOKOL IPV6
37
• IPv6adresa%pcnčı́slo (v BSD systémech), napřı́klad
fe80::94fd:241e:a5a1:d4bb%pcn1
Ne všechny sı́t’ové aplikace však se zónami dokážou pracovat.
Zajı́mavé a celkem podrobné pojednánı́ o IPv6 najdeme v seriálu (hlavně od druhého dı́lu)
na stránce http://www.lupa.cz/serialy/pohneme-s-ipv6/. Informaci o DHCPv6 najdeme na adrese
http://www.networksorcery.com/enp/protocol/dhcpv6.htm.
1.6.5
ICMPv6 a NDP
Nové funkce ICMPv6. Zpráva ICMPv6 Neighbour Solicitation sloužı́ k „objevovánı́“ sousedů,
a zcela nahrazuje protokol ARP. Uzel touto zprávou pravidelně kontroluje funkčnost svých sousedů
a oni odpovı́dajı́ zprávou ICMPv6 Neighbour Advertisement.
P
ICMPv6 má mnohem širšı́ množinu zpráv. Kromě výše uvedené Neighbour Solicitation (NS)
jsou to také zprávy souvisejı́cı́ se skupinovým vysı́lánı́m (Group Membership Query – dotaz členstvı́
ve skupině a odpovı́dajı́cı́ Group Membership Report, dále Group Membership Reduction – omezenı́
členstvı́ ve skupině). Zpráva Redirect sloužı́ k doporučenı́ adresátovi, aby datagramy pro určitý cı́l
posı́lal přes jiného souseda (doporučenı́ na odstraněnı́ problému ve směrovacı́ tabulce).
Tyto zprávy (spolu s dalšı́mi mechanismy) plně nahrazujı́ činnost protokolů ARP a IGMP, které
již nejsou potřeba.
Sousedé. Některé typy komunikace vedou pouze k sousednı́m uzlům v sı́ti. Stanice typicky
mı́vá jen jednoho souseda (některý mezilehlý uzel sı́tě), mezilehlé uzly sı́tě včetně směrovačů majı́
sousedů vı́ce.
NDP (Neighbour Discovery Protocol) sloužı́ k práci se sousedy (také k posı́lánı́ zpráv mezi
sousednı́mi mezilehlými prvky). Pracuje na sı́t’ové vrstvě (jako IP a ICMP) a využı́vá ICMP zprávy
(tj. NDP protokol posı́lá a přijı́má ICMP zprávy, které se zapouzdřujı́ do IP datagramu).
Jeho hlavnı́m úkolem je zjišt’ovánı́ a evidence informacı́ o okolnı́ch uzlech (jejich IP a MAC
adresy apod.), tedy totéž, co bylo u IPv4 v ARP tabulkách. Je použı́ván k mnoha různým účelům,
předevšı́m
• zjištěnı́ IP a MAC (nejen MAC, obecně z vrstvy L2) adres okolnı́ch uzlů (zpráva je adresována jako multicast, odpovědi obsahujı́ IP a MAC adresy), předevšı́m se jedná o objevovánı́
směrovačů,
• spolupráce na zı́skávánı́ IP adresy, konkrétně zjištěnı́ prefixu,
• zjišt’ovánı́ duplicitnı́ch IP adres v sı́ti.
Mnohé z toho, co bylo popsáno v sekci o zı́skávánı́ IPv6 adresy, zajišt’uje právě protokol NDP.
Mechanismus RS a RA využı́vaný při objevovánı́ routerů (od kterých chceme zı́skat IP adresu
a dalšı́ informace) je také součástı́ mechanismu objevovánı́ sousedů.
Přı́klad
Mechanismus objevovánı́ sousedů podle RFC 4861 si ukážeme na přı́kladu zjištěnı́ MAC adresy
souseda (v přı́padě, že známe IPv6 adresu) – je to obdoba ARP dotazu. Tento přı́klad je převzat
z webu https://www.ipv6.cz/.
P
1.6
PROTOKOL IPV6
38
Postup:
• posı́lám datagram na skupinovou IPv6 adresu s prefixem ff02:0:0:0:0:1:ff00:0/104
• určenı́ celé skupinové IPv6 adresy:
– znám IPv6 adresu souseda, např. 2001:db8:1:1:22a:fff:fe32:5ed1
– z nı́ vezmu poslednı́ch 24 bitů (3 oktety) a dodám do skupinové IPv6 adresy z prvnı́ho
bodu: ff02::1:ff32:5ed1
• na tuto adresu pošlu ICMPv6 zprávu Neighbor Solicitation – výzvu sousedovi
• soused odpovı́ zprávou Neighbor Advertisement obsahujı́cı́ jeho MAC adresu
Bezpečnost. Objevovánı́ sousedů má jedno závažné úskalı́: pokud obdržı́me NS paket (paket
s informacı́ o mapovánı́ MAC a IP adres souseda), předpokládá se, že údajům v tomto paketu
budeme věřit. Jenže tento paket může být podvržený a důsledkem použı́vánı́ této IP adresy je
odesı́lánı́ dat na jiný počı́tač než předpokládáme, což zvláště ve firemnı́m prostředı́ může způsobit
odcizenı́ dat.
Pro tento problém existuje několik řešenı́, z nichž je zajı́mavý napřı́klad protokol SEND (Secure
Neighbour Discovery – RFC 3971), který umožňuje digitálně podepisovat oznámenı́ protokolu
NDP. Použı́vá se pro zajištěnı́ „objevovacı́“ a keep-alive komunikace se sousedy. Možnosti:
P
• kryptograficky generované adresy (CGA) – RFC 3972: koncept soukromého a veřejného klı́če,
ICMPv6 zprávy jsou digitálně podepsány,
• certifikačnı́ cesty: ochrana proti falešným směrovačům – řetězce navazujı́cı́ch certifikátů dokazujı́cı́, že určitá důvěryhodná certifikačnı́ autorita schválila toto zařı́zenı́ jako směrovač poskytujı́cı́ dané informace (certifikačnı́ autority tvořı́ hierarchii).
O objevovánı́ sousedů najdeme informace napřı́klad na
• http://www.abclinuxu.cz/clanky/architektura-ipv6-konfigurace-adres-a-objevovani-sousedu
• http://www-public.it-sudparis.eu/~lauren m/articles/M-CGA-Tony-Cheneau-SAR-SSI-2011.pdf
Úkoly
Ve Windows se dá k údajům o NDP dostat v NetShellu, kontextu interface, podkontextu ipv6.
Pro IPv4 použı́váme přı́kaz arp a dále lze sousedy zjistit přı́kazem nbtstat.
V Linuxu je užitečný předevšı́m přı́kaz ip neighbour (resp. ip neigh), pro IPv4 také arp.
Najděte v přı́lohách způsob použı́vánı́ těchto přı́kazů a zjistěte, jak vypsat seznam sousedů.
Kapitola
2
Ethernet
Tato kapitola je věnována Ethernetu – IEEE 802.3. Věnujeme se struktuře Ethernetu, přenosovým technikám
a souvisejı́cı́m standardům.
2.1
Základnı́ pojmy
2.1.1
Co je to Ethernet
Ethernet vznikl roku 1976, a to dı́ky firmám Xerox, Digital a Intel. Je standardizován jako IEEE
802.3, ale přı́mo v tomto standardu se pojem „Ethernet“ vůbec nepoužı́vá (kromě jiného z licenčnı́ch
důvodů).
Ethernet použı́vá koliznı́ přı́stupovou metodu CSMA/CD (kromě nejrychlejšı́ch variant, tam
se prakticky žádná koliznı́ metoda nepoužı́vá).
V současné době je Ethernet nejpoužı́vanějšı́m typem lokálnı́ sı́tě (a prosazuje se dokonce i mimo
oblast čistě lokálnı́ch sı́tı́) a jeho specifikace je velmi rozvětvená. Využı́vá různé typy kabeláže a také
několik různých topologiı́. Použı́vá se v rychlostech 10, 100, 1000, 10 000, . . . Mb/s (ty nejpomalejšı́
už ani ne).
V rámci ISO/OSI modelu na fyzické vrstvě se použı́vá značenı́ „XBASE-Y“, kde
• X je rychlost,
• BASE je signalizačnı́ metoda (Base nebo Broad – základnı́ nebo překládané pásmo),
• Y určuje kabeláž.
Stručný přehled (později probereme podrobněji):
DIX Ethernet je „starý“ Ethernet, původnı́ specifikace s přenosovou rychlostı́ v jednotkách Mb/s.
Zkratka je utvořena z autorů – DEC, Intel, XEROX. Rámce majı́ záhlavı́ nekompatibilnı́
s následujı́cı́mi.
10Mb Ethernet
měl přenosovou rychlost 10 Mb/s, použı́val koaxiálnı́ kabel se sběrnicovou topologiı́ nebo vzácněji optický kabel s topologiı́ hvězda. Značenı́ je 10Base-5 (tlustý koax),
10Base-2 (tenký koax), 10Base-F (optické kabely), 10Base-T (UTP, byl nejpoužı́vanějšı́).
39
O
2.1
ZÁKLADNÍ POJMY
40
Fast Ethernet (100Mb) má přenosovou rychlost 100 Mb/s, použı́vá kroucenou dvojlinku (většinou nestı́něnou) nebo optický kabel, fyzická topologie hvězda (i u následujı́cı́ch).
Gigabit Ethernet (1000Mb) opět přibližně desetinásobné zrychlenı́, použı́vá se optický kabel nebo
kroucená dvojlinka (nestı́něná kat. 5e nebo stı́něná).
10G Ethernet (10 Gb) dalšı́ zrychlenı́, použı́vá se optika, kroucená dvojlinka kat. 6 nebo twin-ax.
40/100G Ethernet (40 Gb, 100 Gb) na nejnovějšı́ standardy (rok 2010, IEEE 802.3ba), jsou určeny
předevšı́m pro rychlé připojenı́ datových center.
Předchůdcem Ethernetu podle IEEE 802.3 byl firemnı́ DIX Ethernet neboli „starý Ethernet“. Později
vznikl standard IEEE 802.3, který se od původnı́ho Ethernetu lišı́ předevšı́m formátem rámce.
Zatı́mco DIX Ethernet specifikuje fyzickou a celou linkovou vrstvu, IEEE 802.3 pouze fyzickou
vrstvu a podvrstvu MAC (LLC bere z IEEE 802.2).
2.1.2
Sı́t’ové prvky
Uzly ethernetové sı́tě jsou
• DTE (Data Terminal Equipment) – koncové stanice, tedy zařı́zenı́, která jsou zdrojem nebo
cı́lem rámců, typicky počı́tače, servery,
P
• DCE (Data Communication Equipment) – mezilehlá sı́t’ová zařı́zenı́, která přijı́majı́ rámce
a odesı́lajı́ je dál, mohou být samostatná zařı́zenı́ (router, switch apod.) nebo komunikačnı́
rozhranı́ (sı́t’ová karta, modem apod.).
V kabeláži použı́váme kroucenou dvojlinku stı́něnou (STP – shielded) nebo nestı́něnou (UTP
– unshielded), a nebo optické kabely. Existuje specifikace pro twin-ax kabel. Dřı́ve se použı́val
koaxiálnı́ kabel. Dnes je nejběžnějšı́ UTP a optika.
Topologie a struktura
Celková struktura sı́tě je kombinace třı́ prvků:
1. Point-to-Point – spojuje dvě zařı́zenı́ (DTE-DTE, DTE-DCE nebo DCE-DCE),
P
2. sběrnice – tento prvek se dnes fyzicky nepoužı́vá, dřı́ve na koaxiálech; délka segmentu sběrnice
max. 500 m (tlustý koax), maximálně 100 zařı́zenı́, segmenty lze propojit opakovači, mezi
dvěma DTE musı́ existovat jediná cesta, max. počet zařı́zenı́ v sı́ti 1024,
3. hvězda – zhruba od prvnı́ poloviny 90. let, struktura složená z Point-to-Point segmentů DTEDCE, DCE je HUB nebo switch (spı́še switch, jednotlivé komunikace jsou odděleny)
Časem došlo ke změnám ve fyzické topologii. U 10Mb Ethernetu se použı́vala jako fyzická topologie
sběrnice, dnes se běžně setkáváme s hvězdou nebo stromovou strukturou. Logická topologie (tj.
popis způsobu chovánı́ sı́tě, šı́řenı́ signálu) však stále zůstává sběrnicová.
Postupné změny – rozdělenı́ fyzické vrstvy: u 10Base-T byla fyzická vrstva (PHY) rozdělena na
dvě podvrstvy (podobně jako dřı́ve linková), ve specifikaci se mluvı́ spı́še o rozhranı́ch k hornı́
vrstvě a vně připojenému kabelu či konektoru, než o podvrstvách):
• Physical Medium Independent s rozhranı́m MII (Medium Independent Interface) – nezávislá na
přenosovém médiu, spolu s linkovou vrstvou je realizována na sı́t’ové kartě (bez konektorů),
od Gigabit Ethernetu je GMII
P
2.1
ZÁKLADNÍ POJMY
41
• Physical Medium Dependent s rozhranı́m MDI (Medium Dependent Interface) – závislá na
médiu, implementuje vše souvisejı́cı́, tedy kódovánı́ bitů, elektrické parametry signálů atd.,
realizována vnějšı́m rozhranı́m sı́t’ové karty
2.1.3
Linková vrstva
Ethernet implementuje linkovou (zčásti) a fyzickou vrstvu modelu. Linková vrstva je rozdělena na
podvrstvy
• LLC – na DTE
• MAC – na DTE i DCE, definována přı́mo standardem 802.3, MAC dvou komunikujı́ch zařı́zenı́
musejı́ minimálně podporovat tutéž přenosovou rychlost.
Na DCE je podvrstva LLC nahrazena přemostěnı́m (most umı́ spojovat i sı́tě s různými protokoly,
napřı́klad Ethernet a Token Ring).
EtherType V některých typech rámců na LLC se použı́vá speciálnı́ identifikátor EtherType (navzdory tomuto názvu zdaleka nesouvisı́ jen s Ethernetem). Tento identifikátor udává typ protokolu
vyššı́ vrstvy pro data zapouzdřená v LLC, řı́ká nám tedy, „co je uvnitř“.
Pole, které je v určitých typech rámců použı́váno pro uloženı́ EtherType, se v jiných typech
rámců použı́vá pro uloženı́ délky paketu (přičemž podle předchozı́ch polı́ to nenı́ možné odlišit),
proto je důležité, aby bylo možné určit, zda v tom poli máme hledat EtherType nebo délku rámce.
Délka rámce je vždy menšı́ než 0×05DC (1500)), proto je EtherType vždy ≥ 0×0600, decimálně 1536.
Konstant pro EtherType je hodně, některé nejdůležitějšı́ jsou následujı́cı́:
•
•
•
•
0×8870: jumbo frames
0×8100: VLAN rámce podle 802.1Q
0×0800: IPv4, 0×86DD: IPv6
0×0806: ARP, 0×0835: RARP
Rámce na vrstvě L2
•
•
•
•
0×08137, 0×08138: IPX
0×8847: MPLS unicast
0×8914: FCoE Initialization Protocol
0×814C: SNMP
mohou být těchto typů:
• LLC rámec pouze podle IEEE 802.2 – v Ethernetu se obvykle nepoužı́vá
• LLC s rozšı́řenı́m SNAP – zapouzdřuje se do MAC rámce
• rámec Ethernet II – implementuje celou linkovou vrstvu, nejběžnějšı́
Nejdřı́v se podı́váme, jak vypadá LLC rámec:
1 oktet
1 oktet
1 nebo 2 oktety
N oktetů
DSAP
prvnı́ bit I/G
SSAP
prvnı́ bit C/R
řı́dicı́ pole
data
Tabulka 2.1: Struktura LLC rámce
Jednotlivá pole majı́ tento význam:
• SSAP, DSAP (po 1 oktetu) – přı́stupové body (SAP) na cı́lovém (DSAP) a zdrojovém (SSAP)
zařı́zenı́, které zabı́rajı́ 7 bitů z každého oktetu; zbývajı́cı́ bit v každém oktetu označuje:
P
2.1
ZÁKLADNÍ POJMY
42
– u cı́lového údaje I/G bit (individual/group) určujı́cı́, zda jde o skupinovou adresu SAP,
– u zdrojového údaje C/R bit (command/response) určujı́cı́ typ paketu (přı́kaz nebo
odpověd’),
Přı́klady DSAP a SSAP:
–
–
–
–
0×42: IEEE 802.1 Bridge Spanning Tree Protocol
0×98: ARP
0×E0: Novell Netware
0×FF: Global DSAP
• řı́dicı́ pole (1 nebo 2 oktety) – určuje typ rámce z hlediska služby, pořadové čı́slo apod.,
• data z vyššı́ vrstvy, která jsou v tomto rámci zapouzdřena.
Následuje druhý typ rámce – LLC s rozšı́řenı́m SNAP (SubNetwork Access Protocol). Rámec
vypadá takto:
1 oktet
1 oktet
1 oktet
3 oktety
2 oktety
N oktetů
DSAP
= 0xAA
SSAP
= 0xAA
řı́dicı́ pole
= 0x03
OUI
protokol
data
Tabulka 2.2: Struktura SNAP rámce
SNAP rámec přiřazuje původnı́m polı́m LLC konstantnı́ hodnoty (0×AA nebo 0×AB). Z toho
vyplývá, že pokud hlavička začı́ná AAAA03, jde o SNAP paket. Co se týče pole OUI – pokud je
nulové, je v dalšı́m poli hodnota EtherType (mı́sto SAP); jinak je zde kód organizace, dalšı́ pole
určuje interně tato organizace.
Třetı́ (nejpoužı́vanějšı́) typ rámce rozpoznávaného na podvrstvě LLC je Ethernet II.
7
1
6
6
2
46–1500
4
PRE
SFD
DA
SA
Length
Data+Pad
FCS
Tabulka 2.3: Struktura rámce Ethernet II
Jednotlivá pole majı́ tento význam:
• PRE (Preambule, 7 B) – posloupnost střı́dajı́cı́ch se jedniček a nul, která informuje přijı́majı́cı́
stanici, že má očekávat rámec, jde o synchronizačnı́ informaci
• SFD (Start-of-frame delimiter, také SOF, 1 B) – také sekvence střı́dajı́cı́ch se jedniček a nul, ale
končı́ dvěma jedničkami, úkolem je oddělit následujı́cı́ část hlavičky
• DA (Destination address, 6 B) – určuje, kdo má rámec obdržet (MAC adresa); může být
i skupinová nebo broadcast MAC (známe z předchozı́ kapitoly)
• SA (Source address, 6 B) – adresa odesı́lajı́cı́ stanice, je vždy unicast
• Length/Type (2 B) – pokud jde o SNAP, jde o délku vnořených dat – vždy je ≤ 1500, jinak
EtherType (to je nejobvyklejšı́);
pak se délka pozná podle pozice začátku dalšı́ho rámce (mezera mezi rámci je 12 oktetů, FCS
4 oktety)
2.2
PŘENOSOVÉ TECHNIKY
43
• data – délka v rozmezi 46–1500 B, spodnı́ hranice je nutná pro detekci kolizı́
• datová výplň (Pad) – pokud délka dat je menšı́ než 46, je nutné je doplnit touto výplnı́ (do
uložené délky dat se nepočı́tá), rozhranı́ mezi daty a datovou výplnı́ poznáme podle hodnoty
Length (délky dat)
• FCS (Frame check sequence, 4 B) – do paty rámce (traileru) se přidává kontrolnı́ součet,
generuje se z dat od adresy přı́jemce (DA) po data včetně (i přı́padnou výplň), sloužı́ přı́jemci
ke zjištěnı́ poškozenı́ rámce
2.2
2.2.1
Přenosové techniky
Zajištěnı́ přenosu pro polovičnı́ duplex
Při polovičnı́m duplexu může vysı́lat vždy jen jedna z komunikujı́cı́ch stran. Pro tento typ přenosu
se použı́vá přenosová metoda CSMA/CD, což znamená:
• CS (Carrier Sense) – stanice neustále naslouchajı́ na přenosovém médiu, i během vysı́lánı́,
P
• MA (Multiple Access) – stanice mohou kdykoliv vysı́lat, když naslouchánı́m zjistı́, že nikdo
nevysı́lá,
• CD (Collision Detect) – pokud vı́ce stanic vysı́lá v téměř stejném okamžiku, docházı́ k poškozenı́ signálu – kolizi, stanice musı́ být schopny kolizi detekovat a ošetřit.
V přı́padě kolize musı́ přestat vysı́lat (ne okamžitě!!!, musı́ dát ostatnı́m vysı́lajı́cı́m uzlům šanci,
aby rozpoznaly kolizi), vyčkajı́ náhodně dlouhý okamžik určený backoff algoritmem.
Backoff algoritmus. Tento algoritmus určuje, jak dlouho má vysı́lacı́ stanice čekat s přenosem,
když zjistı́ kolizi. Po prvnı́m zjištěnı́ kolize:
•
•
•
•
P
vyšle „Jam“ signál pro zrušenı́ odesı́lánı́ vyslaného rámce
čeká po dobu 0 . . . 51, 2 µs, pak se znovu pokusı́ o přenos
když znovu přenos selže, čeká po dobu 2 · 0 . . . 51, 2 µs, pak se znovu pokusı́ o přenos
pokud dojde k dalšı́m selhánı́m, čeká po dobu K · 0 . . . 51, 2 µs, kde K je čı́slo z intervalu
0 . . . 2n − 1
Existujı́ i jiné, složitějšı́ verze backoff algoritmu.
Nejhoršı́ přı́pad nastane, pokud najednou vysı́lajı́ dvě nejvzdálenějšı́ stanice (signál té druhé
vysı́lacı́ stanice dorazı́ až po dlouhé době a nenı́ včas detekován).
Koliznı́ okno (Collision Window, Slot Time) je odvozeno od doby, po kterou se šı́řı́ signál mezi
dvěma nejvzdálenějšı́mi stanicemi, po tuto dobu musı́ odesı́lajı́cı́ stanice naslouchat pro detekci
kolize.
Vliv spodnı́ hranice délky rámce:
• vyššı́ ⇒ většı́ koliznı́ okno a většı́ koliznı́ doména
• nižšı́ ⇒ menšı́ koliznı́ okno a menšı́ koliznı́ doména
P
2.2
PŘENOSOVÉ TECHNIKY
44
Nastavenı́ koliznı́ domény a délky paketu závisı́ na rychlosti šı́řenı́ signálu po sı́ti, nastavenı́
spodnı́ hranice délky rámce a velikosti koliznı́ho okna.
$
• u 10Mb Ethernetu stačilo najı́t vhodný kompromis, stanovena polovina času slot time 51, 2 µs,
min. délka rámce 64 B,
• u 100Mb Ethernetu bylo nutné zmenšit průměr koliznı́ domény přibližně 10× (na méně než
200 m) při zachovánı́ minimálnı́ délky rámce a koliznı́ho okna.
PRE
SFD
DA
SA
Length
Data+Pad
FCS
Ext
1000Base-X: 416 oktetů
1000Base-T: 520 oktetů
Tabulka 2.4: MAC rámec pro Gigabit Ethernet
Pro Gigabit Ethernet (a rychlejšı́) už toto řešenı́ nenı́ průchodné použı́vá se jiné řešenı́:
• zvětšı́ se minimálnı́ délka rámce (na 512 B),
• aby nebylo nutné zasáhnout do struktury rámce, zvětšenı́ se provede přidánı́m nedatové
přı́pony na konec MAC rámce (tj. za kontrolnı́ součet), tato přı́pona má proměnnou délku
a připojuje se pouze k rámcům kratšı́m než je stanovené minimum, v tabulce 2.4 je označena
jako Ext.
Operace přidánı́/odebránı́ přı́pony se provádı́ na MAC vrstvě.
Parametr
10 Mb
100 Mb
1000 Mb
Min. délka rámce
64 B
64 B
Koliznı́ doména
(DTE-DTE)
Koliznı́ doména pro DCE
Max. počet DCE na cestě
100 m UTP
100 m UTP
412 m optika
205 m
2
520 B (1000Base-T)
416 B (1000Base-X)
100 m UTP
316 m optika
200 m
1
2500 m
5
Tabulka 2.5: Porovnánı́ parametrů souvisejı́cı́ch s rámci pro 10Mb, Fast a Gigabit Ethernet
Burst mode, shlukový mód je povolen pouze u gigabitových přenosů (1000Mb Ethernetu a výše).
Pokud stanice vysı́lá vı́ce rámců za sebou, může je poslat ve shluku, který má tuto strukturu:
1. prvnı́ rámec splňuje všechny výše uvedené náležitosti, včetně přı́padného prodlouženı́ přı́ponou,
2. následuje IFG (InterFrame Gap) – sekvence bitů, které oddělujı́ rámce,
3. dalšı́ rámce, vždy oddělené IFG intervaly; pokud jsou kratšı́ než požadovaná minimálnı́
délka, nenı́ třeba je doplňovat o přı́ponu.
Struktura je patrná v tabulce 2.5.
P
2.2
PŘENOSOVÉ TECHNIKY
MAC rámec+Ext
45
IFG
MAC rámec
IFG
...
MAC rámec
Tabulka 2.6: Burst mode u Gigabit Ethernetu
Vlastnosti v Burst modu:
• celková délka shluku takto posı́laných rámců by neměla překročit 5.4 násobek maximálnı́
možné délky rámce,
• pokud poslednı́ rámec způsobı́ překročenı́ této hodnoty, může být ještě jeho přenos dokončen.
Toto řešenı́ je určeno předevšı́m pro posı́lánı́ shluků menšı́ch rámců, které ve shlukovém módu
nenı́ nutné „vycpávat“ na minimálnı́ povolenou délku. Dalšı́ výhodou je zachovánı́ výhradnı́ho
přı́stupu k médiu během vysı́lánı́.
2.2.2
Zajištěnı́ přenosu pro plný duplex
Plný duplex (u Point-to-Point spojů) je realizován zdvojenı́m přenosového média – jedno pro každý
směr. Protože je jen u Point-to-Point spojů, odpadajı́ problémy s kolizemi (proto se nepoužı́vá
žádná koliznı́ metoda) a prakticky nenı́ třeba naslouchat na médiu, rámce jsou posı́lány hned po
zkompletovánı́.
$
Realizace a vlastnosti plného duplexu:
• CSMA/CD by dokonce mohla působit problémy (přı́jem a vysı́lánı́ zároveň by považovala
za kolizi), proto je nutné ji odstranit,
• dı́ky neexistenci kolizı́ je dosah jen záležitostı́ fyzikálnı́ch vlastnostı́ přenosového média,
• obvykle funguje neustále v burst módu, tj. rámce jsou postupně odesı́lány oddělené IFG
sekvencemi.
Řı́zenı́ toku dat
• Jestliže přijı́majı́cı́ uzel je zahlcen rámci, musı́ požádat vysı́lajı́cı́ uzel o přerušenı́ posı́lánı́
rámců,
• pause frame – je vygenerován v MAC vrstvě zahlceného uzlu, obsahuje informaci o délce intervalu, po který má vysı́lajı́cı́ stanice přestat zası́lat; aby nedošlo k omylu, jsou identifikovatelné
specifickou hodnotou zapisovanou do údaje o délce dat
P
• pokud je zahlcenı́ vyřešeno dřı́ve, může být vygenerován pause frame s nulovým časovým
intervalem, který informuje uzel s pozastaveným zası́lánı́m, že může zase začı́t posı́lat rámce.
2.2.3
Zajištěnı́ přijetı́ dat
Zajištěnı́ přijetı́ dat je stejné pro polovičnı́ i plný duplex, rozdı́l je jen v tom, že u plného duplexu
musı́ být odděleny vyrovnávacı́ paměti pro odesı́lánı́/přı́jem. Postup přijetı́:
1. kontrola cı́lové adresy (DA) – zda jde o unicast/broadcast/multicast, a jestli adresa odpovı́dá
adrese této stanice (stanice běžı́cı́ v promiskuitnı́m módu přijı́majı́ všechny rámce bez ohledu
na adresy)
$
2.2
PŘENOSOVÉ TECHNIKY
46
= Collision domains
Hub
Switch
Collision domain
=
Broadcast domain
Broadcast
domain
Router
= Collision domains
Switch
Hub
Broadcast
domain
Collision domain
=
Broadcast domain
Obrázek 2.1: Koliznı́ a broadcastová doména při použitı́ rozbočovače, přepı́nače a směrovače
2. zjištěnı́ délky rámce a porovnánı́ kontrolnı́ho součtu s údajem v FCS
3. kontrola údaje v Length/Type Field – o jaký typ rámce jde, přı́padně délka datové části rámce
(LLC rámce), kontrola délky LLC rámce s uvedeným údajem
4. rozbalenı́ rámce, data jsou předána na vyššı́ (pod)vrstvu
2.2.4
VLAN
VLAN (Virtuálnı́ LAN) umožňuje propojit vzdálené LAN segmenty do jedné logické (virtuálnı́)
LAN sı́tě s (téměř) všemi vlastnostmi a výhodami komunikace v LAN. Lze nastavovat přenosové
priority u odcházejı́cı́ch rámců. Účelem VLAN je zjednodušit jak přı́stup vzdálené stanice k sı́ti,
tak i administraci sı́tě vzhledem k této vzdálené stanici při co nejvyššı́m zachovánı́ bezpečnosti
připojenı́.
P
2.3
FYZICKÁ VRSTVA
47
VLAN rámec v Ethernetu má pozměněnou strukturu – navı́c se vkládá VLAN hlavička za
adresy DA a SA. Struktura VLAN rámce:
• VLAN type ID (2 B) – určuje, že jde o VLAN rámec, má specifickou hodnotu nezaměnitelnou
s hodnotami běžně povolenými pro údaj Length/Type,
• TAG control (2 B) – hodnota priority (0–7, čı́m vyššı́ čı́slo, tı́m vyššı́ priorita) a identifikace
VLAN, do které rámec patřı́.
Přı́chozı́ VLAN rámec je v MAC vrstvě zpracován takto:
• DCE (třeba switch) odešle VLAN rámec beze změny na všechny porty odpovı́dajı́cı́ identifikaci VLAN s ohledem na uvedenou prioritu,
• DTE (obvykle cı́l rámce) odstranı́ VLAN hlavičku a rámec zpracuje jako jakýkoliv jiný.
PRE
SFD
DA
SA
VLAN
typ
Tag
control
Length
Data+Pad
FCS
Ext
VLAN záhlavı́
Tabulka 2.7: VLAN ethernetový rámec
2.3
2.3.1
Fyzická vrstva
NIC
NIC (Network Interface Card, sı́t’ová karta) je implementace fyzické vrstvy. Výrobnı́ označenı́ se
skládá ze třı́ částı́ odvozených od konkrétnı́ch vlastnostı́ fyzické vrstvy:
P
• přenosová rychlost,
• přenosová metoda (rozlišenı́ základnı́ho a překládaného přenosu nebo BaseBand a BroadBand),
• přenosové médium, přı́padně typ kódovánı́ signálů.
Se značenı́m jsme se již seznámili na začátku kapitoly. Napřı́klad 100Base-T4 (rychlost 100 Mb/s,
BaseBand, kroucená dvojlinka s přenosem na všech 4 párech).
Přenosová metoda je prakticky u všech novějšı́ch specifikacı́ BaseBand (sı́t’ové prvky podporujı́cı́
BroadBand se na trhu neprosadily – objevil se pouze 10Broad36).
MAU (transceiver) MAU (Medium Attachment Unit) neboli transceiver (zkráceno ze slov transmitter/receiver) je prvek na NIC, který zajišt’uje rozpoznánı́ přı́tomnosti signálu, kolizi (signál jam)
a vysı́lánı́/přı́jem signálu. Transceiver bývá u některých forem 802.3 externı́, pak se k NIC připojuje
AUI kabelem (Attachment Unit Interface).
P
2.3
FYZICKÁ VRSTVA
2.3.2
48
Kódovánı́ signálu
Signál je během přenosu po přenosovém médiu do určité mı́ry zeslaben a deformován z důvodu
fyzikálnı́ch vlastnostı́ média a jeho délky, šumu, přeslechů, vnějšı́ch vlivů, horšı́ synchronizace.
Přesto je nutné, aby cı́lová stanice tento signál správně přečetla. Řešenı́:
• použitı́ vhodných dobře rozmı́stěných zařı́zenı́ IS (dle pojmů ISO – Intermediate System),
která mohou obnovit kvalitu signálu (prostě opakovač),
• časovač použitý při přijı́mánı́ dat musı́ být správně synchronizován s pulsy v přı́chozı́m
proudu dat,
• použijı́ se kompenzačnı́ hodnoty pro úpravu signálu.
Časovač může ztratit synchronizaci u signálu, který se po dlouhou dobu neměnı́ (třeba dlouhá
sekvence nul), proto je nutné zajistit, aby k tomu nedocházelo.
Jak vyřešit problém se synchronizacı́ časovače a stanovenı́ kompenzačnı́ch hodnot:
• obojı́ vyřešı́ vhodná volba kódovánı́ dat,
• každý bit je nahrazen určitou sekvencı́ bitů, účelem je zajistit, aby se dostatečně často „střı́daly“ hodnoty 0 a 1,
• řetězec musı́ být zpětně dekódovatelný,
• pro každou přenosovou cestu je charakteristický určitý ideálnı́ průběh signálu (většinou něco
jako sinusovka), proto je účelem kódovánı́ přiblı́žit skutečný průběh signálu tomuto ideálu
se zachovánı́m informace.
1
0:
1:
High → Low
Low → High
10
01
↑
0
↓
1
1
↑
↑
0
↓
0
1
↓
↑
0
↓
01 10 01 01 10 10 01 10
Obrázek 2.2: Kódovánı́ Manchester pro oktet (10110010)2
Kódovánı́ Manchester je velmi jednoduché. Spočı́vá v zakódovánı́ bitů do směru kmitu signálu –
0 je kódována jako přechod shora dolů, 1 je kódována jako přechod zdola nahoru (viz obrázek 2.2).
Výsledek můžeme reprezentovat průběhem signálu a nebo opět jako sekvenci jedniček a nul
s tı́m, že přechod shora dolů zapı́šeme jako 10 a opačný přechod jako 01.
Napřı́klad sekvence bitů 10111000 je zakódována na 0110010101101010. Jak vidı́me, stejné symboly vedle sebe zı́skáme pouze na těch mı́stech, kde se v původnı́ sekvenci měnily hodnoty bitů,
a to nejvýše dva stejné symboly. To je výhodou kódovánı́ Manchester, nevýhodou je navýšenı́ délky
posı́laných dat (délka se oproti původnı́m zdvojnásobı́).
U 10Base-T to stačı́, ale u vyššı́ch rychlostı́ jsou dalšı́ techniky:
1. data scrambling (promı́chánı́ dat) – hodnoty bitů se podle klı́če zaměnı́ (na opačnou hodnotu);
účelem je uvést data do stavu, kdy se jednodušeji synchronizuje časovač a hodnoty 0 a 1 se
střı́dajı́ dostatečně často
2.3
FYZICKÁ VRSTVA
49
2. rozšiřovánı́ oblasti kódu – zvlášt’se kódujı́ data × řı́dicı́ signály
3. samoopravitelný kód – přidajı́ se redundantnı́ oblasti s vhodnou střı́davou strukturou (u Gigabit Ethernetu)
Kódovánı́ 4B/5B Z každé čtveřice bitů se vytvořı́ 5 bitů tak, aby v celé sekvenci bylo co nejvı́ce
jedniček (nejméně dvě na pětici), na začátku pětice nejvýše jedna 0, na konci nejvýše dvě 0. Kódy
jsou v tabulce 2.8.
4B
5B
4B
5B
4B
5B
0000
0001
0010
0011
0100
0101
11110
01001
10100
10101
01010
01011
0110
0111
1000
1001
1010
1011
01110
01111
10010
10011
10110
10111
1100
1101
1110
1111
11010
11011
11100
11101
Tabulka 2.8: Tabulka kódů pro 4B/5B
Sekvenci 10111000, kterou jsme v kódovánı́ Manchester zakódovali do 16 znaků, zde zpracujeme
na 1011110010 o délce 10 znaků.
Kódovánı́ MLT-3 použı́vá tři úrovně napětı́ (předchozı́ kódovánı́ použı́vala jen dvě úrovně),
a to -, základna, +. Změna napětı́ proběhne pouze na signál 1, a to na „sinusovce“, napřı́klad pro
sekvenci jedniček by bylo 0, 1, 0, -1, 0, 1, 0, -1, atd.
Toto kódovánı́ se obvykle kombinuje s některým jiným, napřı́klad signál pro MLT-3 může být
předzpracován kódovánı́m 4B/5B.
Oproti Manchestru má signál jen čtvrtinovou frekvenci, proto méně vyzařuje, generuje mnohem
méně rušenı́ do okolı́.
Kódovánı́ 8B/6T znamená, že 8 bitů původnı́ sekvence je zakódováno 6 změnami signálu (ternárnı́ symboly, tedy stavy -,0,+).
Použı́vá se na kroucené dvojlince kategorie 3 se 4 páry, data se rozdělı́ do 3 párů, přenášejı́ se
vždy jednı́m směrem. Čtvrtý pár je použı́ván pro indikaci kolizı́.
Kódovánı́ NRZ (Non Return to Zero)
nenı́ 0 (základna), napřı́klad +1,-1.
použı́vá pro reprezentaci signálu dvě úrovně, z nich žádná
Existuje vı́ce variant – unipolárnı́ (1 je představována kladným napětı́m, 0 také kladným, ale
menšı́m), bipolárnı́m (0 kladné, 1 záporné), NRZI, atd.
Kódovánı́ NRZI (Non Return to Zero – Inverted) znamená, že 1 vyvolá změnu signálu, 0 ne. Je
to obdoba MLT-3, ale jen na dvou úrovnı́ch (kladné a záporné)
2.3.3
Fyzická vrstva v ISO/OSI modelu
Fyzická vrstva se také dělı́ na podvrstvy, a to závislé/nezávislé na médiu s vlastnı́mi komunikačnı́mi rozhranı́mi (interface).
P
50
Podvrstvy nezávislé na médiu:
• vyrovnávacı́ podvrstva (reconciliation),
Reconciliation
• MII (10Mb a 100Mb), GMII (Gb) nebo XGMII (10Gb) – zvlášt’
odesı́lacı́ a přijı́macı́ datové cesty o šı́řce 1 bit pro 10Mb (bitserial), 4 bity pro 100Mb (nibble-serial) nebo 1 B (byte-serial).
MII
PCS
Zajišt’ujı́ logické spojenı́ mezi MAC a různými sadami podvrstev
závislých na médiu.
PMA
Podvrstvy závislé na médiu:
• PCS (physical coding sublayer) – kódovánı́, multiplexing,
synchronizace odchozı́ch a opačně u přı́chozı́ch dat,
Auto-negotiation
• PMA (physical medium attachment) – vysı́lánı́ a přijı́mánı́
signálu, mechanismus zotavenı́ časovače (zajištěnı́ sesynchronizovánı́ časovače na začátku proudu dat),
MDI










































Nezávislé n. m.
STANDARDY PRO FYZICKOU VRSTVU
Závislé na médiu
2.4
• Auto-negotiation (vyjednávacı́ podvrstva) – tyto podvrstvy na začátku přenosu dohodnou
konkrétnı́ vlastnosti spojenı́ vyhovujı́cı́ oběma NIC,
• MDI (medium-dependent interface) – ke konektoru kabelu.
Fyzická vrstva je zcela předefinována v 10G Ethernetu.
2.4
2.4.1
Standardy pro fyzickou vrstvu
10Mb Ethernet
Ethernet s rychlostı́ 10Mb/s v současné době už téměř nikde nenajdeme.
Nejstaršı́ standardy jsou 10Base-5 (tlustý/thick Ethernet) a 10Base-2 (tenký/thin Ethernet).
V obou přı́padech se použı́vá koaxiál (tlustý nebo tenký), topologie je sběrnicová. Stanice se ke
sběrnici připojujı́ pomocı́ členu nazývaného T-kus („téčko“) podle svého tvaru. Sběrnice musı́
být na obou koncı́ch ukončena terminátorem, aby nedocházelo k odrazům a rušenı́ signálu. Tyto
standardy se dnes již nepoužı́vajı́.
10Base-T propojuje uzly sı́tě nestı́něnou dvojlinkou (UTP) kategorie 3 nebo 5. Tento kabel má 4
páry vodičů, z nichž se pro přenos použı́vajı́ pouze 2. Konektory jsou dnes již běžně známé 8pinové
RJ-45.
Fyzická topologie již nenı́ sběrnice, ale hvězda nebo složitějšı́. V centru hvězdy je rozbočovač
nebo jiný mezilehlý prvek (DCE), k němu jsou připojeny jednotlivé DTE spojenı́m point-to-point.
Polovičnı́ i plný duplex je implementován tak, že ze dvou použı́vaných párů vodičů v kabelu každý
funguje simplexně (v jednom směru).
Jako prvnı́ ethernetový standard podporuje ověřenı́ provozuschopnosti spojenı́ – při zapnutı́
NIC (podvrstva PMA) odešle impuls, kterým sdělı́, že je na „přı́jmu“ a očekává odpověd’, pokud
nedostane, opakuje každých 16 ms.
Kóduje se kódovánı́m 4B/5B kombinovaným s Manchesterem.
P
2.4
STANDARDY PRO FYZICKOU VRSTVU
51
10Base-F je standard pro optický kabel s topologiı́ hvězda. Existuje několik specifikacı́ včetně
jedné přı́mo určené pro páteřnı́ rozvody.
10Broad-36 je standard pro použitı́ koaxiálnı́ho kabelu s impedancı́ 75 Ω, topologie sběrnice.
K dispozici jsou 3 kanály po 6 MHz pro vysı́lánı́ a 3 kanály po 6 MHz pro přı́jem, tedy celkem
36 MHz. Výhodou tohoto řešenı́ je možnost vytvářenı́ velmi dlouhých segmentů, až 1800 m.
Přesto se 10Broad-36 nerozšı́řil, ale stal se základem pro pozdějšı́ provozovánı́ Ethernetu v sı́tı́ch
kabelových televizı́.
2.4.2
P
P
Fast Ethernet
Fast Ethernet (100Mb/s) je standardizován jako IEEE 802.3u. Typická fyzická topologie je již stabilně
hvězda (přı́padně pozměněná do stromu). Transceivery mohou být externı́, připojené k NIC drop
kabelem (MII kabelem, AUI), max. 0,5 m.
Transceiver
Attachment
Unit Interface
drop cable
Transceiver
Attachment
Unit Interface
Obrázek 2.3: Internı́ a externı́ transceiver
Pro Fast Ethernet rozlišujeme dvě třı́dy opakovačů:
• třı́da I (translational repeater) – kromě opakovánı́ a přı́padného zesı́lenı́ signálu provádı́ také
překlad (napřı́klad mezi FX a TX), může propojovat dva kabely různého typu, důsledkem je
většı́ zpožděnı́ signálu, proto může být pouze jediný v koliznı́ doméně,
• třı́da II (transparent repeater) – neprovádı́ překlad, propojuje pouze dva kabely stejného typu,
menšı́ zpožděnı́, proto mohou být i dva v jedné koliznı́ doméně.
U Fast Ethernetu se objevuje skutečná technologie auto-negotiation (automatická detekce a vyjednánı́
vlastnostı́ spojenı́), ale zatı́m jen detekuje rychlost na médiu. Také se objevily NIC pro 10/100 Mb,
které automaticky rozpoznajı́ rychlost na médiu a podle toho pracujı́ v 10Mb nebo 100Mb režimu.
Dále se budeme věnovat typům rozhranı́ pro Fast Ethernet.
100Base-TX využı́vá UTP kabel (nestı́něnou kroucenou dvojlinku) kategorie 5 (nebo výjimečně
STP kabel kategorie 1). Délka segmentu bez opakovačů je do 100 m. Kabely kat. 5 obsahujı́ 2
nebo 4 datové páry, což je dostačujı́cı́ (vyžaduje se pro každý směr jeden pár). Kóduje se 4B/5B
kombinovaně s MLT-3.
Na 100Base-TX lze celkem bez problémů přejı́t ze staršı́ho 10Base-T. Kabeláž (pokud je alespoň
typu 5) může zůstat. Jen je třeba vyměnit NIC a mezilehlé prvky sı́tě (jako jsou opakovače), což
může probı́hat postupně, pokud se použı́vajı́ NIC 10/100 s funkcı́ auto-negotiation (tj. prvky
podporujı́cı́ oba standardy).
100BASE-T4 využı́vá UTP, kde se pro přenos dat použı́vajı́ všechny čtyři páry, kategorie 3 nebo
4, lze použı́t i kategorii 5, pokud je kabel kvalitnı́ (tj. pokud má všechny 4 páry).
P
J
2.4
STANDARDY PRO FYZICKOU VRSTVU
52
Dva páry jedou na half-duplexu (polovičnı́m duplexu), v obou směrech, ale v jednom okamžiku
jen jeden směr, dalšı́ dva páry jsou simplexnı́, tedy jen pro jeden určený směr. Poloduplexnı́ páry
a jeden simplexnı́ jsou pro data, dalšı́ simplexnı́ je pro potřeby CSMA/CD. Plný duplex nenı́
podporován.
Kóduje se 8B/6T, speciálnı́ skupiny 6T jsou určeny pro IDLE (indikuje „ticho“ na lince) a dalšı́
(začátek a konec rámce apod.). Maximálnı́ délka segmentu je 100 m.
Pozor – levnějšı́ kabely kategorie 5 majı́ jen dva datové páry, tedy je nelze pro tento typ Fast
Ethernetu použı́t. Poznáme na prvnı́ pohled, stačı́ se podı́vat na konektor.
100BASE-T2 je určena pro staršı́ sı́tě na kroucené dvojlince kategorie 3 původně provozované
jako 100Base-T4, může být i kabel kategorie 4 nebo 5.
Dva simplexnı́ páry jsou nahrazeny jednı́m plně duplexnı́m spojenı́m, tj. funguje také plný
duplex, oba původně poloduplexnı́ páry mohou také fungovat plně duplexně. Je tedy podporován
poloduplexnı́ i plně duplexnı́ provoz.
Na Point-to-Point spojenı́ je vždy jedna NIC jako master, druhá slave; kdo je kdo, se rozhoduje
při inicializaci komunikace, master určuje časovánı́ synchronizace.
Použı́vá se odlišné kódovánı́ s pěti úrovněmi napětı́ PAM5 (Five-level Pulse Amplitude Modulation, podobně jako MLT-3, ale pět úrovnı́: -1,-0.5,0,0.5,1) v kombinaci se scramblingem.
100Base-FX je standard pro optický kabel (fiber optic). Použı́vajı́ se dva optické kabely (mnohavidové nebo jednovidové), každý pro jeden směr komunikace. Délka segmentu závisı́ na typu
optického kabelu a typu duplexu – 412 m (mnohavidový kabel, half duplex) nebo 10 000 m (jednovidový kabel, plný duplex).
Použı́vá se kódovánı́ NRZI předzpracované kódovánı́m 4B/5B. Nevýhodou řešenı́ byla ve své
době předevšı́m cena.
100Base-X využı́vá UTP kabel kategorie 5, ve kterém použı́vá pouze dva páry, anebo optický kabel (dva kabely, jeden pro každý směr). Kódovánı́ je 4B/5B. Jedná se o kombinaci obou předchozı́ch
standardů, karty podle 100Base-X podporujı́ oba typy kabeláže (jsou na nich oba typy konektorů).
konektor RJ-45
UTP kategorie 5,
dva datové páry
Protokoly vyššı́ vrstvy
MAC klient
MAC
Reconciliation
MII
PCS
PMA
TP-PMD
Fiber-PMD
MDI
MDI
6
6
?
(100Base-TX)
?
(100Base-FX)
100 Mb/s
nezávislá na médiu
100Base-X
konektor SC Duplex
optický kabel
se dvěma vlákny
Obrázek 2.4: Schéma pro 100Base-X
L
2.4
STANDARDY PRO FYZICKOU VRSTVU
2.4.3
53
Gigabit Ethernet
Základnı́ specifikace pro gigabitový Ethernet jsou
• 1 000Base-T (802.3ab) – pro kroucenou dvojlinku UTP kategorie 5e
• 1 000Base-X (802.3z) – pro optické kabely varianty SX a LX, pro STP varianta CX
podvrstvy MAC a Reconciliation pro Gigabit Ethernet
podvrstvy nezávislé na médiu pro Gigabit Ethernet
podvrstvy PCS, PMA a Auto-negociace pro
1000Base-X
CX PMD
MDI
6
?
STP
(2 páry)
LX PMD
MDI
6
?
optický
single/multi-mode
(oba směry)
SX PMD
MDI
6
?
optický
multimode
(oba směry)
podvrstvy PCS, PMA a Auto-negociace
pro 1000Base-T
1000Base-T PMD
MDI
6666
????
UTP
(4 páry
min. kat. 5)
Obrázek 2.5: Souhrnné schéma pro Gigabit Ethernet
Je možné použı́t tyto prvky sı́tě:
• opakovače (přı́p. jednoduché rozbočovače) – pro polovičnı́ duplex, max. 100 m na každé straně
opakovače u UTP,
P
• rozbočovače s bufferem – pro plný duplex, majı́ vyrovnávacı́ pamět’, přijı́majı́ rámce z vı́ce
vstupnı́ch portů a ukládajı́ do paměti, při zahlcenı́ podle IEEE 802.3x použijı́ protokol Xon/X-off a zažádajı́ uzly o přerušenı́ vysı́lánı́, než pamět’vyprázdnı́,
• přepı́nače – přepı́naný duplex (switch dokáže zajistit vı́ce logických spojenı́ najednou), velké
zvýšenı́ propustnosti sı́tě, jde o plný duplex.
Přepı́nače posı́lajı́ rámce jen na ty porty, na které patřı́ (kontrolujı́ adresu – DA), proto oddělujı́ koliznı́ démény; pokud jsou v sı́ti použity jako DCE pouze přepı́nače, nenı́ třeba použı́vat CSMA/CD.
Rozlišujeme tedy
• sdı́lený Ethernet – v jedné koliznı́ doméně je vı́ce než dva uzly, nutné použı́t CSMA/CD,
• přepı́naný Ethernet – v jedné koliznı́ doméně jsou jen dva komunikujı́cı́ uzly, použı́vá se plný
duplex (jeden z uzlů bývá přepı́nač).
1 000Base-T (IEEE 802.3ab) použı́vá všechny 4 páry UTP kategorie 5e (vyhovujı́ také některé
kabely kategorie 5), na každém páru je rychlost 250 Mb/s. Je zpětně kompatibilnı́ s 100Base-TX.
Rámec se rozdělı́ na 4 části pro 4 páry UTP, zakóduje, na druhé straně linky se dekóduje a znovu
složı́. Existujı́ speciálnı́ sekvence pro IDLE, indikaci začátku rámce, indikaci konce rámce. Kóduje
se pomocı́ PAM5.
P
2.4
STANDARDY PRO FYZICKOU VRSTVU
54
Je podporován polovičnı́ i plný duplex. CSMA/CD přestává vyhovovat, ale pořád existuje.
Hodně se použı́vajı́ switche (aby nebylo nutné při vyššı́ rychlosti zmenšovat koliznı́ doménu)
a spojenı́ jsou spı́še typu Point-to-Point (DTE-DCE).
1 000Base-X (IEEE 802.3z) je základnı́ standard pro optické kabely, od toho se odvı́jı́ i použité
kódovánı́ – 8B/10B (8 bitů je kódováno do 10bitové skupiny) v kombinaci s NRZ. Je podporován
polovičnı́ i plný duplex.
P
Základnı́ standardy jsou
• 1 000BaseSX – světelný zdroj je LED-dioda nebo laser, vlnová délka 850 nm (v reálu 770–860
nm), mnohovidové kabely (průměr jádra 50 nebo 62,5 µm), je určen pro pro kratšı́ horizontálnı́
vedenı́ nebo páteře (několik set metrů) – 220 m pro kabely 50 µm, 550 m pro kabely 62,5 µm,
• 1 000BaseLX – světelný zdroj je laser o vlnové délce 1300 nm (v reálu 1270–1355 nm), jednovidové (10 µm) nebo mnohovidové kabely (50 nebo 62,5 µm), použitelné pro delšı́ vzdálenosti
(až 5 km s jednovidovými kabely; někteřı́ výrobci garantujı́ i 10 nebo 20 km, pokud jsou
použity jejich produkty na obou koncı́ch linky).
1 000Base-SX je velmi oblı́bený ve firmách k propojenı́ budov v rámci jednoho areálu. Naproti
tomu 1 000Base-LX umožňuje vést kabely na většı́ vzdálenost, napřı́klad jako páteř propojujı́cı́ vı́ce
poboček (podsı́tı́) v rámci jednoho města.
Existujı́ také neformálnı́ (firemnı́) specifikace, které nejsou standardizované:
• LH – podobný LX, ale na delšı́ vzdálenost – až 10 km,
• ZX – pro jednovidové kabely využı́vajı́cı́ laser o vlnové délce 1550 nm, vzdálenosti i 70 km,
• BX10 – jednovidový optický kabel, ale nesymetrická vlnová délka – pro downstream (ke
koncovému zařı́zenı́) 1490 nm, pro upstream (opačně) 1310 nm.
Výše uvedené standardy a specifikace jsou pro optické kabely. Do této skupiny patřı́ ještě jeden
standard, který má výjimku:
1 000BaseCX – kabel je STP (stı́něná dvojlinka) nebo koaxiál, použı́vá se krátké vzdálenosti do
25 m, moc se neprosadil.
Jeho předpokládanou výhodou byla možnost snadnějšı́ kombinace s předchozı́mi, napřı́klad
pro krátké spoje k serveru (propojenı́ serveru a blı́zkého přepı́nače).
2.4.4
10Gb Ethernet
10 Gb Ethernet (10Gb, 10GbE) je určen pro MAN a WAN sı́tě, použı́vá se také v datových centrech
(velké množstvı́ dat na krátkou vzdálenost). propojenı́ serverových clusterů, apod. V rozlehlých
sı́tı́ch použı́vá speciálnı́ podvrstvu WIS (WAN Interface Sublayer) pro připojenı́ k SONET/SDH.
Jako prvnı́ vznikla specifikace pro optické sı́tě (IEEE 802.3ae, rok 2002), později i metalické kabely.
Při takto vysoké rychlosti již nenı́ možné efektivně zabránit kolizı́m, proto se definitivně přešlo
na plný duplex podporovaný switchi. CSMA/CD nelze aplikovat.
Vývoj také spěje k modulárnosti a mnohostrannosti. Mezilehlá zařı́zenı́ pro 10GbE (switche)
P
P
2.4
STANDARDY PRO FYZICKOU VRSTVU
55
Obrázek 2.6: Optický transceiver XENPAK1
většinou podporujı́ vı́ce různých fyzických vrstev, použı́vajı́ se výměnné zásuvné moduly (transceivery).
Optický transceiver ve formě modulu (externı́ transceivery byly použı́vány i u dřı́vějšı́ch verzı́)
nenı́ specifikován přı́mo v 802.3, ale zvlášt’ v dokumentech MSA (MultiSource Agreements) –
předevšı́m se setkáváme s MSA XENPAK, X2, XPAK, XFP and SFP+. Připojuje se k rozhranı́ XAUI
(jako AUI u staršı́ch verzı́). XAUI spolu se svým okolı́m představuje GMII, je napojen na MAC
podvrstvu. Ukázku vidı́me na obrázku 2.6.
10GBase-R
(optický kabel) použı́vá kódovánı́ 64B/66B. Rozlišujeme:
• 10GBase-SR (Short Range) – laser 850 nm, mnohavidový kabel, dosah 62 m
J
• 10GBase-LR (Long Range) – laser 1310 nm, jednovidový kabel, dosah 10 km (v praxi až 25
km je kvalitnı́ signál)
• 10GBase-LRM (Long Reach Multimode, IEEE 802.3aq) – laser 1310 nm, mnohavidový kabel,
dosah 220 m
• 10GBase-ER (Extended Range) – laser 1550 nm, jednovidový kabel, dosah 40 km
10GBase-W použı́vá podvrstvu WIS pro připojenı́ k WAN, optické kabely (stejně jako R, jen
navı́c podpora WIS). Také má varianty SW, LW a EW. Použı́vá trochu jiný formát rámce – v rámci
WIS je zapouzdřen běžný LAN rámec 10GBase-R Ethernetu), WIS se pak posı́lá po WAN.
10GBase-T (802.3an) pro horizontálnı́ vedenı́ v rámci strukturované kabeláže. Kódovánı́ PAM-16
v kombinaci s DSQ128, kroucená dvojlinka, a to kategorie 6 (dosah až 55 m) nebo 6a či 7 (dosah až
100 m).
10GBase-CX4 (IEEE 802.3ak) je určen pro datová centra a stohovatelné přepı́nače, obecně pro
připojenı́ některého DCE k serveru,
• kabel twin-ax, 4 vysı́lače a 4 přijı́mače po 2.5 Gb/s
• často napojeno na InfiniBand – vysokorychlostnı́ rozhranı́ podporujı́cı́ QoS, sériové, obousměrné, s nı́zkou latencı́, různé šı́řky (u CX4 s twin-axem použı́váme 4×) – kromě použitı́
v sı́tı́ch se rozhranı́ použı́vá také napřı́klad k připojenı́ datových zařı́zenı́
• kódovánı́ 8B/10B, dosah pouze do 15 m
• výhoda: cena
1
Zdroj: http://www.pandacomdirekt.com/en/products/transceiver-and-accessory/transceiver/transceiver.html
P
J
J
2.5
TECHNOLOGIE
56
Tento standard je založen na XAUI.
Dalšı́ informace o InfiniBand:
• http://www.infinibandta.org/content/pages.php?pg=technology overview
• http://www.oreillynet.com/pub/a/network/2002/02/04/windows.html
• http://infiniband.sourceforge.net/
Obrázek 2.7: Infiniband a twinax2
10GBase-LX4
lze použı́t pro připojenı́ k infrastruktuře SONET/SDH (viz dále)
• optika (jednovidové i mnohavidové kabely), 850 nm
P
• použı́vá WDM (Wavelength-Division Multiplexing) – obdoba frekvenčnı́ho multiplexu na
optice (různé vlnové délky – „barvy“)
• 4 oddělené laserové zdroje, dosah 300 m/10 km
2.5
2.5.1
Technologie
Křı́ženı́
Vysı́lač (Tx – Transmit) na jednom konci spojenı́ musı́ být připojen na přijı́mač (Rx – Receive) na
druhém konci a naopak, proto je nutné křı́ženı́ cesty. Toto křı́ženı́ je naznačeno na obrázku 2.8.
Křı́ženı́ může být provedeno bud’ v kabelu (křı́žený kabel), a nebo interně v zařı́zenı́, ale nenı́
přesně stanoveno, která z těchto možnostı́ má být použita. Podle doporučenı́ 802.3 by mělo platit:
•
•
•
•
na cestě musı́ být lichý počet křı́ženı́ celkem,
pokud je zařı́zenı́ interně opatřeno křı́ženı́m, musı́ být označeno symbolem ×,
internı́ křı́ženı́ je volitelné,
při propojenı́ DTE a DCE je doporučeno implementovat křı́ženı́ interně u DCE.
Reálně se setkáváme s tı́mto řešenı́m:
•
•
•
•
2
u 10Base-T: pro spojenı́ DTE–DCE použı́t nekřı́žený, pro DTE–DTE použı́t křı́žený,
optické kabely pro Ethernet jsou vždy křı́žené,
kroucené dvojlinky pro 100Base dědı́ pravidlo po 10Base-T,
u 1000Base-T: NIC může obsahovat možnost volby internı́ho křı́ženı́ (při navazovánı́ komunikace se to zjišt’uje v rámci procesu autonegociace), pokud neobsahuje, platı́ stejné podmı́nky
jako u 10Base-T.
Zdroj: http://en.wikipedia.org/wiki/InfiniBand, http://www.sierra-cables.com/, http://www.blackbox.com/
P
2.5
TECHNOLOGIE
57
Tx
Rx
uzel 1
(přepı́nač)
uzel 2
(stanice)
Rx
Tx
Tx
Tx
uzel 1
(stanice)
uzel 2
(stanice)
Rx
Rx
Obrázek 2.8: Křı́ženı́ (zde při plném duplexu)
V označenı́ch se setkáváme se zkratkami MDI (Media Dependent Interface, pro koncové stanice)
a MDIX nebo MDI-X (MDI with Crossover, pro mezilehlé prvky).
Na přepı́načı́ch bývajı́ některé porty vybaveny funkcı́ MDI/MDI-X, což znamená, že tento port
bud’ umožňuje přepı́nánı́ mezi použitı́m přı́mého či křı́ženého kabelu a nebo přı́padně dokáže
detekovat typ použitého kabelu (Auto Cross). Toho se využı́vá napřı́klad tehdy, když na port podle
potřeby připojujeme bud’ stanici (přı́mý kabel) nebo jiný switch (křı́žený).
P
Na přepı́nači také můžeme najı́t port označený Uplink. Ten je přı́mo určen pro připojenı́ k jinému
mezilehlému prvku (nikoliv koncové stanici).
Dalšı́ informace o kabelech jsou na http://www.svetsiti.cz/view.asp?rubrika=Tipy&clanekID=110
Úkoly
Prohlédněte si ethernetové kabely, které máte v dosahu. Všimněte si, zda jsou křı́žené či nekřı́žené
(konektory jsou průhledné, porovnejte uspořádánı́ barevných vodičů). Dále zjistěte kategorii kabelu (obvykle najdete v textu natisknutém v pravidelných intervalech přı́mo na kabelu). Pokud
máte kabel kategorie 5, ověřte si, zda jde o kabel se dvěma nebo čtyřmi páry (opět poznáte na prvnı́
pohled na konektoru).
2.5.2
Auto-negotitation
Auto-negotitation (vyjednávánı́ NIC) představuje mechanismus, který se rozvı́jı́ postupně u standardů na UTP kabel od 10Base-T. NIC ohlásı́ svou verzi (čı́slo, napřı́klad 10Base-T half duplex má
1, 100Base-T full duplex má 6, apod.).
Dvě různé NIC se domluvı́ na přenosových režimech, kterým obě rozumı́, vybere se přenosový
režim nejvyššı́ ze sdı́lených. Použı́vajı́ se dvě formy:
• NLP (Normal Link Pulse) – umı́ všechny od 10Base-T,
• FLP (Fast Link Pulse) – nesou dalšı́ informaci.
Pokud NIC nerozumı́ FLP pulsům, je automaticky považována za 10Base-T half duplex.
P
2.5
TECHNOLOGIE
2.5.3
58
Multiple-Rate Ethernet
Multiple-Rate Ethernet (Ethernet ve vı́ce úrovnı́ch) je řešenı́ pro souvislé oblasti (několik budov)
pokryté sı́tı́ (campusy), které sdı́lejı́ jedno připojenı́ na Internet. Rozlišujeme několik typů uzlů
(kromě připojovaných DTE):
P
• Campus Distributor – bývá to (10)Gb switch s možnostı́ připojenı́ k telekomunikačnı́ sı́ti nebo
jiné WAN
• Building Distributor – rychlejšı́ switch připojený na páteř campusu, hlavnı́ switch v budově
• Floor Distributor – nižšı́ úroveň v hierarchii, od nı́ dále vede horizontálnı́ vedenı́
• Telecom Outlet (na obrázku 2.9 označeno zkratkou TO) – obvykle rozhranı́, ke kterému se
připojujı́ počı́tače a dalšı́ koncová zařı́zenı́, „zásuvka“
Uzly jsou propojeny těmito kabely:
• Campus Backbone Cabling – hlavnı́ páteř, typicky optika (jedno- i mnohavidová), připojenı́
Building Distributorů
• Building Backbone Cabling – páteřnı́ sı́t’na úrovni budov, typicky UTP kat. 5 nebo lepšı́ a nebo
mnohavidový kabel
• Horizontal Cabling – horizontálnı́ kabeláž, obvykle UTP, někde i mnohavidový kabel
2.5.4
PoE
PoE (Power over Ethernet) je standard IEEE 802.3af (rok 2003).
Mnohá zařı́zenı́ připojená k Ethernetu majı́ jen malý přı́kon, tak k čemu zvlášt’ napájenı́? PoE
umožňuje napájet zařı́zenı́ po datových kabelech (UTP kat. alespoň 5). Pro napájenı́ jsou použı́vány
vždy dva prostřednı́ páry, a to bud’ výhradně, a nebo zároveň s daty.
ISP
Campus
Distributor
hlavnı́ páteř
Building
Distributor
Building
Distributor
Floor
Distributor
páteřnı́ sı́t’
v budově
horizontálnı́ kabeláž
TO
TO
TO
atd.
Floor
Distributor
Floor
Distributor
TO
TO
TO
TO
TO
TO
Obrázek 2.9: Multiple-Rate Ethernet
P
2.5
TECHNOLOGIE
59
Toto řešenı́ je zpětně kompatibilnı́ i se zařı́zenı́mi nepodporujı́cı́mi PoE (aby zařı́zenı́ nebylo
zničeno, při připojenı́ se napájı́ nejdřı́ve nı́zkým napětı́m, a když je odezva – podporuje, přecházı́ se
na vyššı́ napětı́). Použı́vá se až 13 W při 48 V, pokud zařı́zenı́ potřebuje nižšı́ napětı́, samo provede
transformaci.
Typický přı́klad zařı́zenı́, která mohou být takto napájena, jsou IP telefony, ale podporu PoE
najdeme i u některých switchů a dalšı́ch zařı́zenı́. S tı́mto pojmem se setkáme i v kapitole o bezdrátových sı́tı́ch (Wi-fi sı́tě 4. generace).
2.5.5
EFM
EFM (Ethernet in the First Mile) (IEEE 802.3ah, rok 2004) je možnost využitı́ Ethernetu na celé cestě
přes WAN až ke koncovým počı́tačům. Počı́tá se jak s metalickými, tak i optickými spoji. Protože
10G Ethernet je použitelný (a také použı́ván) v rozlehlých sı́tı́ch, bylo by praktické použı́t Ethernet
také na poslednı́ (prvnı́) mı́li připojenı́ k internetu („first mile“).
P
Pro připojenı́ k ATM WAN se použı́vá napřı́klad ADSL. Při přechodu WAN od ATM k Ethernetu
se uvažuje o nahrazenı́ ADSL linek Ethernetem, protože by to znamenalo méně transformacı́ dat
na cestě při kombinovánı́ různých technologiı́.
2.5.6
Metro Ethernet
V přı́padě Metropolitnı́ho Ethernetu
(Metro Ethernet) bylo záměrem, aby
při propojovánı́ různých LAN nebylo
třeba využı́vat jinou mezilehlou technologii na úrovni linkové vrstvy (jiná
technologie ⇒ alespoň sı́t’ová vrstva)
s tı́m, že sı́t’by měla podporovat VLAN
a QoS.
ADSL
ADSL
EFM
ATM DSLAM
Eth DSLAM
Eth DSLAM
ATM
GbE
GbE
ATM switch
P
Eth switch
Eth switch
Obrázek 2.10: Postup zaváděnı́ EFM
Metro Ethernet může být implementován bud’ jako „čistý“ Ethernet nebo jako nástavba existujı́cı́ technologie pro metropolitnı́
či rozlehlé sı́tě (využije se existujı́cı́ infrastruktura) – Ethernet over SDH, Ethernet over MPLS,
apod.
Informace o nejrychlejšı́ch standardech IEEE 802.3 a Ethernetu obecně:
• http://sites.google.com/site/40gethernet/
• http://bladeharmony.net/userfiles/file/WP 40G and 100G Tech Brief.pdf
• http://www.computerworlduk.com/news/it-business/19052/100-40g-ethernet-adoption
-held-back-by-price/
• http://www.cisco.com/en/US/docs/interfaces modules/transceiver modules/installation
/note/78 15665.html
• http://www.earchiv.cz/b07/b0200002.php3
• http://www.ieee802.org/3/
Kapitola
3
Dalšı́ témata k lokálnı́m sı́tı́m
Protože v „drátových“ LAN se v praxi setkáváme téměř výhradně s Ethernetem, nebudeme probı́rat dalšı́
běžné typy LAN (FDDI, Token Ring), ale přesto se podı́váme ještě na dalšı́ témata souvisejı́cı́ s lokálnı́mi
sı́těmi. Zde se budeme zabývat technologiemi EtherChannel, Fibre Channel a iSCSI (SAN sı́tě), a virtuálnı́mi
lokálnı́mi sı́těmi.
3.1
3.1.1
EtherChannel
Vlastnosti
EtherChannel je technologie umožňujı́cı́ spojit (agregovat) až 8 fyzických ethernetových linek do
jedné. Dva uzly (typicky servery, přepı́nače nebo směrovače podporujı́cı́ tuto technologii) jsou
propojeny vı́ce aktivnı́mi fyzickými ethernetovými spoji, PDU procházejı́ některým z těchto spojů.
Dále je podporováno navı́c až 8 záložnı́ch fyzických linek (failover) pro přı́pad, že aktivnı́ linky
budou nefunkčnı́.
V přı́padě EtherChannelu se použı́vá dvojı́ terminologie – zatı́mco u firmy Cisco se mluvı́
o EtherChannel, v systému Solaris se pro totéž použı́vá pojem trunk, což ale u Cisco znamená něco
úplně jiného. Proto když slyšı́me pojem „trunk“, měli bychom mı́t jasno v tom, čı́ terminologie je
vlastně právě použı́vána. U serverů se také použı́vá pojem NIC Teaming, což však nenı́ úplně totéž
(je to širšı́ termı́n, sdružovánı́ sı́t’ových karet do jedné „virtuálnı́“, logické).
Spoje, které jsou součástı́ EtherChannelu, jsou typu Fast Ethernet nebo rychlejšı́, a všechny
musejı́ být stejného typu (tj. napřı́klad nelze kombinovat spoje Fast Ethernet a 10Gb Ethernet –
stejná rychlost, dále stejný duplex apod.). Pokud použı́váme VLAN (virtuálnı́ sı́tě), měly by spoje
být v rámci jedné VLAN nebo v trunk módu se stejnými parametry.
Celková propustnost se však nerovná součtu propustnostı́ jednotlivých fyzických cest. Pokud
se v rámci jedné komunikace směřujı́cı́ k jednoho uzlu k jinému uzlu (ve výchozı́m nastavenı́)
posı́lá vı́ce PDU, všechny jsou posı́lány po téže fyzické cestě, tedy komunikaci nelze rozdělit.
60
P
L
3.1
ETHERCHANNEL
3.1.2
61
Řı́zenı́ toku
Výchozı́ nastavenı́ je takové, že spoje v rámci EtherChannelu jsou rozdělovány podle cı́lové MAC
adresy, tedy PDU, které majı́ konkrétnı́ cı́lovou MAC adresu, jsou všechny směrovány na tentýž
spoj. To však ne vždy vyhovuje, proto je možné nastavit i jiné dělenı́:
$
• dvojici [zdrojová MAC, cı́lová MAC],
• pouze podle zdrojové MAC,
• podobně pro IP adresy a porty.
Rozdělenı́ komunikačnı́ch
proudů mezi EC porty
Rozdělenı́ zátěže (tj. jednotlivých spojenı́) mezi linky v rámci EtherChannelu se provádı́ podle
hashovacı́ho vyvažovacı́ho algoritmu, který třı́dı́ PDU podle zadaného kritéria (napřı́klad podle
cı́lové MAC adresy) a celou komunikaci dělı́ podle pravidla naznačeného v tabulce 3.1.
8
1
1
1
1
1
1
1
1
Počet EC portů
7 6 5 4 3
2
1
1
1
1
1
1
2
2
1
1
1
1
2
2
2
1
1
2
2
2
2
3
3
2
2
4
4
Tabulka 3.1: Hashovánı́ komunikace v EtherChannelu
Každému „proudu dat“ určenému podle zvoleného kritéria (napřı́klad podle cı́lové adresy)
je hashovánı́m přiděleno čı́slo z intervalu 0–7 (tj. jedno z 8 čı́sel), a to bez ohledu na skutečný
počet spojů v EtherChannelu. Toto čı́slo pak určuje konkrétnı́ fyzický spoj. Napřı́klad pokud máme
EtherChannel nad třemi fyzickými spojenı́mi (EC porty), budou na prvnı́ spoj směrovány PDU se
třemi konkrétnı́mi přiřazenými čı́sly, jiná tři čı́sla budou směrována na druhý spoj a zbylá dvě na
třetı́ spoj. Je zřejmé, že nejoptimálněji budou spoje vyváženy, pokud do EtherChannelu sdružı́me
2, 4 nebo 8 spojů.
3.1.3
Protokoly
Pro EtherChannel (EC) existujı́ dva protokoly vyjednávajı́cı́ vlastnosti EC spojenı́:
• LACP (Link Aggregation Control Protocol) definovaný IEEE 802.3ax1 ,
• PAgP (Port Aggregation Protocol), což je proprietálnı́ protokol firmy Cisco.
1
Správně je IEEE 802.3ax, ale v literatuře se běžně můžeme setkat s nesprávným (významově mı́rně posunutým)
IEEE 802.3ad – NIC Teaming.
P
3.2
SAN SÍTĚ
62
Prvnı́ z těchto protokolů je obecně použitelný ve všech zařı́zenı́ch podporujı́cı́ch EtherChannel
(včetně zařı́zenı́ firmy Cisco), druhý se použı́vá pouze při propojovánı́ dvou zařı́zenı́ Cisco. V jedné
EC sı́ti musı́ být použit vždy jen jediný z těchto protokolů (a všechna zařı́zenı́ mu musı́ „rozumět“).
Oba protokoly umožňujı́ nastavit zařı́zenı́ do jednoho ze dvou stavů – aktivnı́ho (active u LACP,
desirable u PAgP), ve kterém zařı́zenı́ aktivně vyjednává sestavenı́ EtherChannelu, a pasivnı́ho
(passive u LACP, auto u PAgP), ve kterém zařı́zenı́ pasivně vyčkává na iniciaci vyjednávánı́ o EtherChannelu od druhé strany.
P
EtherChannel lze také vytvořit manuálně napevno, stav je označován on. Pak je EtherChannel
vytvořen námi a žádné vyjednávánı́ zařı́zenı́ nenı́ potřeba a tedy se vlastně nepoužije žádný
z předchozı́ch dvou protokolů.
Dalšı́ informace včetně mnoha přı́kladů najdeme na adresách
• http://www.samuraj-cz.com/clanek/cisco-ios-21-etherchannel-link-agregation-pagp
-lacp-nic-teaming/
• http://www.fit.vutbr.cz/~ivesely/publikace/etherchannel.pdf
• http://www.cisco.com/en/US/tech/tk389/tk213/technologies tech note09186a00800
94714.shtml
• http://www.ciscozine.com/2008/11/04/configuring-link-aggregation-with-etherchannel/
3.2
SAN sı́tě
SAN (Storage Area Network) jsou sı́tě určené k propojenı́ datových úložišt’(diskových polı́, NAS,
souborových serverů apod.) s mezilehlými prvky sı́tě, jde tedy o sı́tě určené k zajištěnı́ vysoké
dostupnosti datových úložišt’(přı́p. datových center).
P
K nejznámějšı́m SAN technologiı́m patřı́ Fibre Channel (FC) a iSCSI.
3.2.1
Fibre Channel
Fibre Channel je převážně optické rozhranı́ (tj. na optických kabelech) pro rychlé přesuny dat
na (relativně) krátké vzdálenosti. Původně bylo určeno pro použitı́ „uvnitř počı́tače“ (konkrétněji
serveru) ke komunikaci mezi I/O zařı́zenı́mi a procesory, ale postupně se prosadilo jako sı́t’ový
standard.
Pod pojmem kanál (channel) se zde rozumı́ přı́mé nebo přepı́nané predikovatelné propojenı́
dvou zařı́zenı́.
Jde o plně duplexnı́ sériové rozhranı́ pro point-to-point spoje (i vı́ce point-to-point spojů s vhodným hardwarem, přepı́načem). Přepı́nánı́ je zde velmi jednoduché a rychlé, může být realizováno
hardwarově. Výhodou je tedy vysoká rychlost přepı́nánı́ a tedy i dostupnosti dat.
Fibre Channel pracuje na stejných vrstvách jako Ethernet, většina logiky technologie je v MAC
podvrstvě.
Podle názvu by se mohlo zdát, že jako přenosový prostředek je možné použı́t pouze optický
kabel, ale ve skutečnosti je možné použı́t také koaxiál nebo STP (stı́něnou dvojlinku), což ale má
P
3.3
VIRTUÁLNÍ LOKÁLNÍ SÍŤ – VLAN
63
vliv na dosažitelné vzdálenosti a rychlost. Zatı́mco s jednovidovým optickým vláknem dosáhneme
rychlosti až 1 Gb/s a vzdálenosti až 10 km (s mnohavidovými vlákny samozřejmě méně, vzdálenost
je od uzlu k přepı́nači), při použitı́ STP to je 100 m při rychlosti 132 Mb/s nebo 50 m při 265 Mb/s.
Nejnovějšı́ standard umožňuje dosaženı́ rychlosti 4 Gb/s.
Levnějšı́ a jednoduššı́ variantou je Fibre Channel se smyčkou, jehož topologie je kruhová bez
použitı́ mezilehlých prvků, přı́stupová metoda je podobná využı́vánı́ tokenu. Toto řešenı́ je vhodné
jen pro malý počet zařı́zenı́, maximálně 30.
FCoE (Fibre Channel over Ethernet) je pokus o sloučenı́ jinak rozdı́lných sı́tı́ Fibre Channel
a Ethernet (10Gb). Zatı́mco samotný FC dokáže pracovat jen v rámci jednoho ethernetového segmentu (k nejbližšı́mu směrovači), FCoE dı́ky napojenı́ na technologii Ethernetu se dostane i za
směrovače. FCoE vyžaduje podporu Jumbogramů (Jumboframe) – viz IPv6 datagramy (str. 31).
3.2.2
P
P
iSCSI
iSCSI (Internet Small Computer System Interface) je obdobou FCoE určenou spı́še pro menšı́ SAN
sı́tě. Jedná se vlastně o možnost posı́lánı́ SCSI přı́kazů přes IP sı́t’ (vzpomeňte si na rozhranı́
pevných disků – SCSI disky se dnes celkem hodně použı́vajı́ v serverech). Zatı́mco FC pracuje na
ethernetových vrstvách ISO/OSI, iSCSI pracuje až na sı́t’ové vrstvě.
P
Technologie iSCSI může být implementována softwarově nebo hardwarově. Softwarová implementace je levnějšı́ (konkrétně – zdarma), přı́slušný software si lze stáhnout od výrobce/distributora
každého operačnı́ho systému nebo je dokonce součástı́ instalace systému (jen je obvykle nutné aktivovat přı́slušnou službu či démona). Hardwarová implementace znamená podporu na NIC (za tu
se připlácı́). Výhodou hardwarové implementace je vyššı́ rychlost, protože pomocný procesor na
NIC odlehčuje hlavnı́m procesorům při zpracovávánı́ (nejen) iSCSI požadavků. Obecně platı́, že do
menšı́ SAN stačı́ softwarová implementace, do většı́ nebo hodně vytı́žené SAN je dobré investovat
do sı́t’ových karet s hardwarovou implementacı́ iSCSI (samozřejmě pokud máme SCSI disky).
Popis architektury Fibre Channel najdeme napřı́klad na
http://www.kiv.zcu.cz/s̃imekm/vyuka/pd/zapocty-2004/san-mrnka/fc.html.
Článek o FCoE (prvnı́ dı́l seriálu):
http://www.abclinuxu.cz/clanky/hardware/fcoe-fibre-channel-over-ethernet
Článek o iSCSI:
http://www.microsoft.com/cze/technet/clanky/iscsi.mspx
Dalšı́ možná řešenı́ SAN sı́tı́ jsou InfiniBand, ATAoE (ATA over Ethernet), apod.
3.3
Virtuálnı́ lokálnı́ sı́t’– VLAN
VLAN (Virtual LAN, virtuálnı́ lokálnı́ sı́tě) vytvářejı́ logickou LAN (obvykle několik logických
LAN) nad jednou nebo vı́ce fyzickými LAN. VLAN je jednoznačně určena bud’ čı́slem nebo názvem,
obvyklejšı́ (podporovanějšı́) je označovánı́ VLAN čı́sly.
P
3.3
VIRTUÁLNÍ LOKÁLNÍ SÍŤ – VLAN
64
Fyzická sı́t’ se skládá ze sı́t’ových segmentů oddělených přepı́nači nebo zařı́zenı́mi obsahujı́cı́mi funkci přepı́nače, jeden sı́t’ový segment může napřı́klad při použitı́ strukturované kabeláže
představovat jedno patro firemnı́ budovy. VLAN vytvořená nad touto fyzickou sı́tı́ může spojovat
vybrané stanice nacházejı́cı́ se také v různých segmentech sı́tě.
3.3.1
Členstvı́ ve skupině
Přı́slušnost stanice do konkrétnı́ VLAN je určena zařazenı́m stanice do skupiny, která může být
určena některým z těchto kritériı́:
1. VLAN podle portů – na přepı́načı́ch v sı́ti jsou konkrétnı́ porty (a tedy stanice k nim připojené
roztřı́děny do jednotlivých VLAN. Tato metoda je nejpoužı́vanějšı́, je poměrně jednoduchá.
Při změně struktury sı́tě (napřı́klad stanice bude přenesena a připojena k jinému portu) je
však nutné provést ručnı́ rekonfiguraci, a dalšı́ nevýhodou je nemožnost zařazenı́ stanice
(portu) do vı́ce než jedné VLAN.
2. VLAN podle MAC adres (na linkové vrstvě) – tato metoda je náročnějšı́ na počátečnı́ konfiguraci,
protože MAC adresy musejı́ být do skupin přiřazeny ručně. Odpadá však ručnı́ rekonfigurace
při změně umı́stěnı́ stanice a jedna stanice může být i ve vı́ce VLAN. Nevýhodou je většı́
časová náročnost přepı́nánı́ a s tı́m souvisejı́cı́ snı́žená propustnost sı́tě (zvláště pokud jedna
MAC adresa přı́slušı́ do vı́ce VLAN). Je třeba dát pozor na možnost pozměněnı́ MAC adresy.
3. VLAN na sı́t’ové vrstvě – jednou z možnostı́ je seskupit stanice podle IP adresy podsı́tě
(v TCP/IP sı́ti), dalšı́ možnost je seskupovánı́ podle sı́t’ového protokolu (TCP/IP, Novell
NetWare, AppleTalk apod.). To lze pouze u mezilehlých prvků sı́tě, které pracujı́ i na sı́t’ové
vrstvě (přepı́nač samotný jen na L2). Tento typ VLAN lze zobecnit na VLAN podle informacı́
sı́t’ového protokolu.
4. VLAN podle multicast adresy – členstvı́ v VLAN závisı́ na přı́jmu konkrétnı́ multicast komunikace. Narozdı́l od předchozı́ch typů VLAN jsou rámce posı́lané uvnitř této VLAN vždy
doručeny všem členům skupiny, ne jen jednomu (adresace je vždy skupinová).
5. VLAN podle politiky – přı́slušnost do VLAN je určena kombinacı́ i vı́ce kritériı́ (tj. politikou,
„zásadou“) a může být dynamicky měněna podle chovánı́ stanice v sı́ti (umı́stěnı́, typu
a množstvı́ zası́laných rámců, atd.). Chovánı́ stanic a provoz na sı́ti jsou automaticky monitorovány a politiky mohou být přizpůsobovány.
6. VLAN s autentizacı́ – můžeme použı́t IEEE 802.1x pro autentizaci uživatele (RADIUS) a autorizace pak obsahuje zařazenı́ uživatele do přı́slušné VLAN. Je také možné nastavit, že uživatel,
který nebyl autentizován (host) bude zařazen do speciálnı́ VLAN pro hosty.
Pouze VLAN podle portů neumožňujı́ definovat vı́ce VLAN na jednom portu ani členstvı́ stanice
ve vı́ce VLAN (resp. je to výrazně náročnějšı́). Ovšem v současné době jsou nejpoužı́vanějšı́.
Konkrétnı́ určenı́ stanic, které majı́ patřit do dané skupiny, vycházı́ z potřeb firmy. Rozdělenı́
může být určeno napřı́klad podle organizačnı́ struktury firmy – VLAN pro účetnı́ oddělenı́, VLAN
pro mzdové a personálnı́ oddělenı́, dalšı́ pro výrobnı́ úsek apod., ovšem to je relativnı́ a každá
firma má v tomto směru trochu jiné potřeby.
P
3.3
VIRTUÁLNÍ LOKÁLNÍ SÍŤ – VLAN
65
V základu se řı́dı́me podle toho, jak probı́há obvyklá komunikace mezi stanicemi, tedy stanice,
které navzájem hodně komunikujı́, by měly být v jedné VLAN. Dalšı́m kritériem může být bezpečnost a zamezenı́ únikům informacı́. VLAN napřı́klad může propojovat totéž oddělenı́ v různých
pobočkách firmy.
3.3.2
Určenı́ členstvı́
V sı́ti použı́vajı́cı́ VLAN (nejčastěji na vrstvě L2) musı́ být možné přı́mo z rámce určit členstvı́
v konkrétnı́ VLAN. Součástı́ záhlavı́ rámce podle IEEE 802.1Q může být identifikace VLAN (Frame
Tagging), a to hned za cı́lovou a zdrojovou adresou v 4oktetovém poli. V tomto poli najdeme
identifikaci protokolu (pevně 0×8100), 3 bity pro prioritu (podle IEEE 802.1P), 1 bit pro Token Ring
(přı́znak kanonické adresy) a konečně 12bitový identifikátor VLAN – VID (VLAN ID). Právě podle
VID se provádı́ přepı́nánı́.
P
Ve směrovačı́ch Cisco se můžeme setkat s jiným řešenı́m přidánı́ VLAN informacı́ do rámce,
protokolem ISL (Inter-Switch Link). Jde o proprietálnı́ protokol firmy Cisco. Zatı́mco IEEE 802.1Q
přidává nové 4oktetové pole přı́mo do záhlavı́ rámce, ISL zapouzdřuje původnı́ rámec do vlastnı́
PDU, v jejı́mž záhlavı́ najdeme potřebné informace o VLAN a do zápatı́ přidává nový kontrolnı́
součet.
P
Přepı́nač 1
Port 8
Port 9
Port 10
VLAN 30
Port 11
Port 12
VLAN 10
Port 0
Port 1
Port 13
Port 14
VLAN 20
Port 2
Port 15
VLAN 30
VLAN 40
Port 3
Port 4
Port 5
Port 6
Port 7
Port 13
Port 14
Port 15
Trunk
Přepı́nač 2
Port 8
Port 9
Port 10
VLAN 20
Port 12
VLAN 40
VLAN 10
Port 0
Port 11
VLAN 10
VLAN 30
Port 1
Port 2
Port 3
VLAN 20
Port 4
Port 5
Port 6
Port 7
Obrázek 3.1: Propojenı́ přepı́načů trunkem
3.3.3
Zajištěnı́ komunikace mimo VLAN
Vzájemně komunikovat mohou pouze ty stanice, které patřı́ do stejné VLAN. Pokud chceme zajistit
komunikaci i mezi různými VLAN (přı́padně se zapojenı́m dalšı́ch bezpečnostnı́ch mechanismů),
jde to připojenı́m vnějšı́ho směrovače (přepı́nač nestačı́, stejně jako při propojovánı́ fyzických LAN)
k oběma těmto VLAN (ovšem pozor, může nastat problém s protokolem STP, viz kapitolu 7.2.2, od
P
3.3
VIRTUÁLNÍ LOKÁLNÍ SÍŤ – VLAN
66
strany 147). Toto řešenı́ je vhodné tehdy, když opravdu chceme propojit jen dvě konkrétnı́ VLAN,
ale kdybychom takto chtěli propojit vı́ce než dvě VLAN, museli bychom vytvořit propojenı́ zvlášt’
pro každou VLAN, což je plýtvánı́ porty.
Řešenı́m je použitı́ trunku. Trunk je propojenı́ mezi dvěma přepı́nači přenášejı́cı́ rámce z vı́ce než
jedné VLAN (port s podporou vı́ce VLAN). Může vést mezi dvěma přepı́nači (z každého přepı́nače
zabere pouze jeden port, takový, který nenı́ přı́mo přiřazen jedné konkrétnı́ VLAN), nebo mezi
přepı́načem a vnějšı́m směrovačem (pak veškerá komunikace oběma směry mezi různými VLAN
jde po jednom spoji, což snižuje propustnost.
Port 8
Port 9
Port 10
VLAN 20
Port 11
Port 12
VLAN 40
Port 13
Port 14
P
Port 15
VLAN 10
směrovač
VLAN 10
Port 0
VLAN 30
Port 1
Port 2
Port 3
VLAN 20
Port 4
Port 5
Port 6
Port 7
Obrázek 3.2: Přepı́nač s vestavěnou funkčnostı́ L3
Dalšı́ možnost efektivnı́ho propojenı́ VLAN je použitı́ přepı́nače s vestavěnou funkčnostı́ vrstvy
L3 (tj. směrovánı́), pak nepotřebujeme vnějšı́ směrovač, ale využı́váme internı́ směrovač, který je
vnitřně propojen se všemi VLAN v přepı́nači a komunikace mezi VLAN nenı́ zdržována.
Dalšı́ informace o VLAN:
• http://www.samuraj-cz.com/clanek/vlan-virtual-local-area-network/
• http://www.svetsiti.cz/view list.asp?rubrika=Tutorialy&temaID=237
• http://www.czela.net/wiki/index.php/VLAN
P
Kapitola
4
WAN sı́tě
V této kapitole se budeme zabývat spojovými protokoly pro WAN a na nich postavenými rozlehlými sı́těmi,
a to X.25, Frame Relay, ATM, MPLS a dalšı́mi.
4.1
Spojové protokoly
Většina bitově orientovaných spojových protokolů (protokolů na linkové vrstvě, L2) vycházı́ z dnes
již zastaralého protokolu SDLC (Synchronous Data Link Control) od firmy IBM. Tento protokol
je poměrně univerzálnı́, použitelný pro point-to-point i vı́cebodové spoje, pro různé typy přenosových médiı́, polovičnı́ i plný duplex, pro přepı́nánı́ okruhů i paketů. Typicky se použı́val pro
připojenı́ výkonného počı́tače ke vzdálené LAN.
4.1.1
P
HDLC
Jednı́m z potomků protokolu SDLC je HDLC (High Data Link Control). Stejně jako SDLC, také
HDLC rozlišuje v sı́ti dva typy zařı́zenı́:
• primárnı́ uzel – řı́dı́ komunikaci sekundárnı́ch uzlů,
• sekundárnı́ uzly – mohou vysı́lat pouze po obdrženı́ povolenı́ od primárnı́ho uzlu.
Možné konfigurace:
• point-to-point – pouze dva uzly, jeden primárnı́ a jeden sekundárnı́
• vı́cebodové – jeden primárnı́ a vı́ce sekundárnı́ch uzlů
SDLC naproti tomu přidával ještě dalšı́ dva typy konfigurace – smyčku (kruhová topologie, jeden
uzel v kruhu je primárnı́) a sı́t’s aktivnı́m rozbočovačem (v sı́ti je jeden přı́chozı́ a jeden odchozı́ kanál,
po odchozı́m komunikuje primárnı́ uzel se sekundárnı́mi, po přı́chozı́m sekundárnı́ komunikujı́
s primárnı́m uzlem).
67
P
4.1
SPOJOVÉ PROTOKOLY
68
PDU se nazývá rámec. Použı́vajı́ se tři typy rámců:
1. I-frame (Information Frame, informačnı́, datový) – nese informace z vyššı́ vrstvy a přı́padně
řı́dicı́ informace, tyto rámce podporujı́ řazenı́, řı́zenı́ toku, detekci chyb, zotavenı́. Určenı́:
přenos dat.
P
2. S-frame (Supervisory Frame, také služebnı́ či dohlı́žecı́ rámec) – obsahuje řı́dicı́ informace,
použı́ván pro požadavek zahájenı́ nebo ukončenı́ spojenı́, hlášenı́ o stavu, potvrzenı́ přijetı́
I-rámce.
3. U-frame (Unnumbered Frame, nečı́slovaný) – pro řı́dicı́ informace (dohoda režimu provozu),
narozdı́l od předchozı́ho nepodporujı́ čı́slovánı́ rámců do posloupnosti, a může také obsahovat data z vyššı́ vrstvy. Obecně: pro to, co se vejde do jediného rámce.
Pro data z vyššı́ch vrstev se tedy použı́vá předevšı́m I-frame.
1 oktet
1-2
2
Flag
Adresa
Řı́zenı́
prom. délka
2
1
Data
FCS
Flag
P
PP
PP
8 bitů
1
PP
PP
P
8
Send
Sequence
Number
PP1
P
Řı́zenı́ pro I-frame:
Receive
Sequence
Number
P
F
bit
Řı́zenı́ pro S-frame:
Receive
Sequence
Number
P
F
bit
Řı́dicı́
informace
0
1
Řı́zenı́ pro U-frame:
Řı́dicı́
informace
P
F
bit
Řı́dicı́
informace
1
1
0
Obrázek 4.1: Formát SDLC a HDLC rámce
Formát SDLC a HDLC rámce se lišı́ podle jeho typu. Jednotlivá pole:
1. přı́znak (flag) na začátku rámce má vždy hodnotu 01111110 (binárně), sloužı́ k rozlišenı́
začátku a konce rámce (je i na konci rámce),
2. adresa – adresa sekundárnı́ho uzlu (může být také skupinová nebo broadcast),
3. řı́dicı́ pole (1 nebo 2 B), jeho obsah je odlišný u různých typů rámců, formát pole pro různé
typy rámců probereme o něco dále,
4. data (proměnná délka),
5. FCS (kontrolnı́ součet rámce) vytvořený polynomiálnı́m kódem, toto pole může mı́t u HDLC
i 32 bitů,
6. přı́znak (flag) na konci rámce (platı́ totéž co pro přı́znak na začátku rámce).
P
4.1
SPOJOVÉ PROTOKOLY
69
Formát řı́dicı́ho pole (naznačen na obrázku 4.1):
• pro I-frame:
– pořadová čı́sla – pořadové čı́slo vysı́laného rámce (tj. tohoto) a dále pořadové čı́slo
očekávaného rámce od protistrany,
– P/F bit (poll/final) – když je nastaven na 1, primárnı́ uzel dává navědomı́ sekundárnı́mu, že vyžaduje okamžitou odpověd’, sekundárnı́ zase primárnı́mu, že tento rámec je
poslednı́ ze zası́laných rámců
• pro S-frame: kromě pořadových čı́sel také řı́dicı́ informace (potvrzenı́ přijetı́ I-rámce, oznámenı́ stavu sı́tě, vyžádánı́ nebo ukončenı́ přenosu, atd., nemá datovou část
• pro U-frame: neobsahujı́ pořadová čı́sla, jen řı́dicı́ informaci, tento rámec může být použı́ván
pro inicializaci sekundárnı́ch uzlů, podobné funkce jako S-frame
HDLC podporuje synchronnı́ komunikaci s plným duplexem.
V HDLC existuje několik přenosových režimů:
1. normálnı́ režim odpovědi (NRM, normal response mode) – dědı́ od SDLC, sekundárnı́ stanice
musı́ počkat na vyzvánı́ od primárnı́, aby mohla komunikovat,
P
2. asynchronnı́ režim odpovědi (ARM, asynchronous response mode) – sekundárnı́ stanice může
začı́t komunikovat s primárnı́ bez povolenı́,
3. asynchronnı́ vyvážený režim (ABM, asynchronous balanced mode) – uzly jsou kombinované
(schopné pracovat jako primárnı́ i sekundárnı́), každá stanice může začı́t komunikovat bez
povolenı́, primárnı́ uzel je obvykle ten, který zahajuje komunikaci.
4.1.2
LAP protokoly
LAP (Link Access Procedure) je skupina spojových protokolů, které jsou do značné mı́ry podobné
protokolům SDLC a HDLC s určitými odlišnostmi, předevšı́m v podporovaných přenosových
režimech.
LAPB (Link Access Procedure Balanced) je použı́ván v sı́tı́ch X.25. Je typický pro point-to-point
spojenı́ s přenosovým režimem ABM (asynchronnı́ vyvážený). Rozlišujı́ se také stejné typy rámců
jako u HDLC.
Formát rámce je prakticky shodný s formátem rámce HDLC, ale v druhém poli (tam, kde HDLC
ukládá adresu) nemusı́ být uložena adresa (většinou nenı́ potřeba, protože LAPB pracuje jen na
point-to-point spojı́ch).
Komunikace je (stejně jako u jiných protokolů tohoto typu) řı́zena povely. Existuje vı́ce různých
povelů, napřı́klad SABM (zahájenı́ komunikace), UA (přijetı́ komunikace druhým uzlem), DM
(odmı́tnutı́ komunikace), REJ (žádost o opakovánı́ přenosu rámce, došlo k chybě při přenosu),
RR (přı́jem), RNR (přenos bude ukončen, žádost o potvrzenı́ dosud odeslaných rámců), DISC
(rozpojenı́, komunikace je ukončena, zası́lá primárnı́ stanice), atd.
LAPD (Link Access Protocol, Channel D) byl původně specifikován pro ISDN, kanál D. Je
hodně podobný protokolu LAPB, také pracuje v asynchronnı́m vyváženém režimu. Odlišnost je
v adresovém poli rámce – obsahuje
P
P
4.1
SPOJOVÉ PROTOKOLY
•
•
•
•
70
C/R bit (command/response) – rozlišuje, zda jde o přı́kaz nebo odpověd’
identifikátor přı́stupového bodu na vyššı́ vrstvu (SAPI, 6 bitů)
identifikátor koncového zařı́zenı́ (7 bitů)
dva přı́davné bity, v každém oktetu jeden
LAPF (Link Access Procedure – Frame) vycházı́ z LAPD a přejı́má většinu jeho vlastnostı́, má
méně funkcı́. Použı́vá se v sı́tı́ch Frame Relay. Adresové pole má 2 oktety (může být rozšı́řeno až
na 4) a zcela změněnou strukturu, řı́dicı́ pole bylo vyřazeno. V adresovém poli je uloženo DLCI,
a dále bity pro řı́zenı́ toku dat a kontrolu chyb (BECN, FECN, DE apod.), podrobněji dále v této
kapitole (v sekci o Frame Relay).
4.1.3
SLIP
SLIP (Serial Line Internet Protocol) je určen pouze pro přenos IP datagramů (nenese informaci
o typu protokolu, proto nelze přenášet nic jiného). Je to starý protokol určený pro zajištěnı́ vytáčeného připojenı́ se sériovým rozhranı́m připojeným na modem. Nedokáže detekovat chyby,
nezvládá synchronnı́ přenosy, nedostatečná komprese, dalšı́ nevýhodou je nutnost specifikace IP
adresy při každém znovu-navázánı́ spojenı́ (pokud nemáme statickou IP adresu).
P
Dnes se již nepoužı́vá, byl nahrazen protokolem PPP.
4.1.4
PPP
PPP (Point-to-Point Protocol) je dvoubodový (point-to-point). Nerozlišuje primárnı́ a sekundárnı́
uzly (navazovat spojenı́ může kterýkoliv uzel), podporuje synchronnı́ i asynchronnı́ přenos. Narozdı́l od SLIP dokáže provádět automatickou konfiguraci při navazovánı́ spojenı́, přičemž se testuje
kvalita spoje.
Součástı́ rámce je i určenı́ protokolu vyššı́ vrstvy, proto dokáže nejen zapouzdřovat IP datagramy, ale i jiné typy paketů vyššı́ vrstvy.
PPP se skládá ze dvou částı́ (přesněji – obsahuje dvě vrstvy):
• protokoly řı́zenı́ sı́tě (NCP, Network Control Protocol) – protokoly zajišt’ujı́cı́ komunikaci s vyššı́
vrstvou; existuje vı́ce těchto protokolů pro různé sı́t’ové architektury (TCP/IP, NetWare,
AppleTalk apod.), tato vrstva zasahuje částečně i do sı́t’ové vrstvy v ISO/OSI modelu,
P
P
• protokol řı́zenı́ spoje (LCP, Link Control Protocol) – navazovánı́ a udržovánı́ spojenı́, dohodnutı́
konfigurace na začátku spojenı́ (negociace), může zajišt’ovat také testovánı́ spoje a autentizaci.
Účelem je maximálně omezit množstvı́ funkcı́ vlastnı́ho spojového protokolu (tj. LCP) a takto
zefektivnit jeho fungovánı́.
Autentizace je volitelnou vlastnostı́, lze ji provádět některým z těchto protokolů:
• PAP (Password Authentication Protocol) – textové heslo se posı́lá po spoji, tedy nejde o bezpečnou metodu autentizace
• CHAP (Challenge Handshake Authentication Protocol) – použı́vá se asymetrická šifra (klı́č),
iniciujı́cı́ stanice odešle žádost, obdržı́ náhodně vygenerovanou sekvenci znaků, kterou zpracuje pomocı́ tajného klı́če a odešle zpět, po ověřenı́ přı́jemcem může začı́t komunikace
P
4.1
SPOJOVÉ PROTOKOLY
71
• EAP (Extensible Authentication Protocol) – zcela odděluje fázi navazovánı́ spojenı́ od fáze
autentizace, samotná autentizace může probı́hat třemi různými způsoby:
1. MD5 (funguje podobně jako CHAP, také pomocı́ klı́če),
2. heslo na jedno použitı́,
3. token card.
PPP také podporuje šifrovánı́ a komprimaci.
Rámec protokolu PPP je do značné mı́ry podobný předchozı́m:
• přı́znak (opět binárně 01111110)
• adresa (1 B) – toto pole existuje, ale má vždy konstantnı́ hodnotu (binárně samé 1)
• řı́dicı́ pole (1 B) – obsahuje vždy hodnotu 0000011 (indikuje nečı́slovaný rámec ve službě bez
spojenı́)
• protokol (2 B, toto pole se u jiných protokolů nevyskytuje) – obsahuje identifikaci protokolu
vyššı́ vrstvy (napřı́klad pro IPv4 je to 0×0021, pro IPv6 0×0057, pro IPX je zde 0×002B),
k nalezenı́ v RFC dokumentech
• data – maximálně 1500 B
• FCS
• přı́znak
To byl rámec obsahujı́cı́ data pro přenos. Použı́vajı́ se také služebnı́ LCP pakety, které je třeba
zapouzdřit do PPP rámce následovně:
• v poli protokolu je hodnota 0×C021
• v poli data je samotný LCP paket obsahujı́cı́ tyto informace:
P
– kód – identifikuje funkci LCP paketu (požadavky na změnu parametrů, potvrzenı́ přijetı́
požadavků na změnu, odmı́tnutı́ požadavků, ukončenı́ spojenı́, atd.)
– identifikátor – u přı́kazového paketu obsahuje náhodně vygenerovanou hodnotu, u odpovědi musı́ obsahovat tutéž hodnotu jako paket s přı́kazem, na který odpovı́dá
– délka celého LCP paketu v oktetech
– data – obvykle posloupnost uspořádaných dvojic (volba,hodnota), napřı́klad typ autentizačnı́ho protokolu, vyššı́ max. délka dat, atd.
4.1.5
Rozšı́řenı́ PPP
Pro rozšı́řenı́ protokolu PPP platı́ vpodstatě totéž co pro PPP (vrstva L2, přibližně účel, šifrovánı́,
většinou i formát rámce). Tato rozšı́řenı́ jsou navı́c přizpůsobena konkrétnı́mu způsobu využitı́.
Multilink PPP (PPP po vı́ce spojı́ch, také se označuje MP, MPPP, MLP; RFC 1990) je varianta
PPP pro vı́cebodové spoje. Nenı́ tı́m mı́něno ani tak vı́ce uzlů, jako spı́še vı́ce sériových spojů pro
jedinou komunikaci. Lze zkombinovat vı́ce sériových spojů do jediného logického kanálu s vyššı́
propustnostı́ (agregace), protokol dokáže data rozdělit, vhodně přeuspořádat a pak na druhém
konci linky opět uvést do původnı́ho stavu.
P
4.2
X.25
72
Tunneling PPP (PPTP, Point-to-point Tunneling Protocol, RFC 1171) je určen pro virtuálnı́ privátnı́
sı́tě a k připojenı́ vzdáleného klienta k firemnı́ sı́ti (obecně LAN). Ovšem dnes je podporován
prakticky už jen ve Windows a jeho podpora se bude omezovat i zde, doporučuje se přechod na
jeho následovnı́ka L2TP (Layer 2 Tunneling Protocol, RFC 3931).
P
L2TP: Do rámce protokolu L2TP se zapouzdřujı́ rámce PPP. Sám o sobě nemá tento protokol
zabezpečovacı́ funkce, proto se často kombinuje se zabezpečenı́m pomocı́ IPSec nebo jiných metod,
viz kapitolu 8.4.2 o GRE a L2TP tunelech na str. 184.
Wireless PPP
(W-PPP, bezdrátový PPP, RFC 2153) je varianta PPP pro bezdrátové sı́tě.
Připojenı́ k Internetu se řešı́ napojenı́m PPP (iniciačnı́ fáze připojenı́) na protokoly WAN. Využı́vá
se také v technologiı́ch DSL pro přenos přes WAN poskytovatele, a to v těchto variantách:
P
• PPPoA (PPP over ATM, RFC 2364) – PPP paket je zapouzdřen do ATM buňky
• PPPoE (PPP over Ethernet, RFC 2516) – PPP paket je zapouzdřen do Ethernetového rámce,
dnes běžné
Tyto varianty umožňujı́ navázat autentizované spojenı́ s ISP a dynamicky zı́skat IP adresu. Jsou
potřeba u typů komunikace, kde se navazuje spojenı́, nevyužı́vajı́ se u trvalého připojenı́ k Internetu
(resp. využı́vajı́ se tehdy, když se navazuje spojenı́; když už je navázáno, nejsou potřeba).
4.1.6
IEEE 802.2 (LLC)
Standard IEEE 802.2 definuje podvrstvu LLC (Logical Link Control) na vrstvě L2.
LLC je určen pro point-to-point spoje, pracuje v asynchronnı́m vyváženém režimu (ABM). Opět
se rozlišujı́ tři typy rámců – I-frame, S-frame a U-frame. Formát rámce je podobný jako u HDLC,
ale celkově jednoduššı́, protože LLC rámec se vždy zapouzdřuje do MAC rámce a tedy některá
pole majı́ jiný význam. Použı́vá se jiná adresace (přı́stupové body služeb).
P
LLC nabı́zı́ tři typy služeb:
• nepotvrzovaná služba bez spojenı́ (typ 1) – nejpoužı́vanějšı́, funguje podobně jako doručovánı́
datagramů (paket je vybaven všemi dostupnými informacemi včetně adres zdroje a cı́le
a pořadı́ paketu ve zprávě), žádné ošetřenı́ chyb, v tomto ohledu spoléhá na protokoly
vyššı́ch vrstev,
• služba se spojenı́m (typ 2) – pro virtuálnı́ okruhy, zahrnuje navázánı́ spojenı́, potvrzovánı́ po
doručenı́ omezené skupiny paketů, atd., pouze prvnı́ paket obsahuje informace o adresách,
• potvrzovaná služba bez spojenı́ (typ 3) – pakety jsou po skupinách potvrzovány, tato služba je
jen málo využı́vaná.
Koncové stanice podporujı́ vždy nejméně typ 1, a pak obvykle ještě jednu ze zbývajı́cı́ch služeb.
4.2
X.25
Sı́t’ X.25 je normalizována původnı́m CCITT (v rámci ITU) postupně v několika verzı́ch, verze
z roku 1984 byla předlohou pro ISO 8208. Z návrhu je zřejmé, že X.25 vznikala v době, kdy nebylo
4.2
X.25
73
zvykem použı́vat vrstvené architektury, až postupně bylo doporučenı́ přizpůsobováno modelu
ISO/OSI (poslednı́ verze již ISO/OSI odpovı́daly).
X.25 implementuje tři vrstvy – fyzickou, linkovou a sı́t’ovou, s důrazem na sı́t’ovou vrstvu. Komunikace probı́há na okruzı́ch (pevných a přepı́naných virtuálnı́ch okruzı́ch), je to sı́t’s přepı́nánı́m
paketů.
Hlavnı́ a nejdůležitějšı́ vlastnostı́ X.25 je extrémnı́ spolehlivost – vyznačuje se přemı́rou kontrolnı́ch mechanismů, které dnes zatěžujı́ sı́t’ovou komunikaci, ale na méně spolehlivých spojı́ch jsou
užitečné. Z toho ovšem vyplývá malá propustnost sı́tě (nı́zká rychlost).
V minulosti se použı́vala pro veřejné datové sı́tě (PDN – Public Data Network), v současnosti
se s nı́ setkáme spı́še v rozvojových zemı́ch (protože je vhodná pro méně spolehlivé spoje). Pro
svou enormnı́ spolehlivost se s X.25 můžeme i u nás setkat na bezpečnostně kritických spojı́ch,
napřı́klad u připojenı́ platebnı́ch terminálů a bankomatů.
4.2.1
Zařı́zenı́ v sı́ti
V sı́ti X.25 jsou rozlišována tato zařı́zenı́:
1. DTE (Data Terminal Equipment) – počı́tače, servery, terminály, atd., jde o zařı́zenı́ obvykle
umı́stěná v provozovnách předplatitelů
2. DCE (Data Circuit-terminating Equipment) – komunikačnı́ zařı́zenı́ (modemy, přepı́nače
apod.), zajišt’ujı́ připojenı́ DTE k PSE, jsou v režii přepravce
3. PSE (Packet Switching Exchange) – komunikačnı́ zařı́zenı́ (většinou přepı́nače) v sı́ti přepravce
4. PAD (packet assembler/disassembler) – rozhranı́ pro velmi jednoduchá zařı́zenı́ (např. terminály), která nezvládajı́ protokoly X.25; poskytujı́ vyrovnávacı́ pamět’a provádějı́ sestavovánı́
paketu při odesı́lánı́ a rozebı́ránı́ paketů při přijı́mánı́ dat
Z pohledu zákaznı́ka (uživatele sı́tě) jsou nejdůležitějšı́ zařı́zenı́ DTE (obvykle ve vlastnictvı́ zákaznı́ka nebo pronajaté od telekomunikačnı́ společnosti) a DCE. V dalšı́ch typech WAN sı́tı́, které
budeme probı́rat, zařı́zenı́ DCE a PSE splývajı́ v jeden typ (DCE).
Relace (session, sezenı́) je spojenı́ mezi dvěma DTE. Komunikace mezi DTE přes sı́t’probı́há po
vytvořenı́ relace v plném duplexu. Kterékoliv z obou zařı́zenı́ může relaci ukončit.
4.2.2
Adresy a navázánı́ spojenı́
Adresy okruhů podle X.121: Jedná se o adresy (pouze unicast) použı́vané při vytvářenı́ přepı́naného virtuálnı́ho okruhu. Je čı́selná (obdoba telefonnı́ho čı́sla) a skládá se z těchto částı́:
• DNIC (Data Network Identifier Code) – identifikace datové sı́tě, skládá se ze
– zóna (1 čı́slice), pro Evropu je to 2
– země (2 čı́slice), pro ČR platı́ 30
– sı́t’(1 čı́slice)
4.2
'$
X.25
74
&%
. . . DCE
. . . PSE
. . . DTE
Obrázek 4.2: Sı́t’X.25
pro některou sı́t’v ČR by platilo 230x, kde za x by se dosadilo čı́slo konkrétnı́ sı́tě
• NTN (National Terminal Number) – až 10 čı́slic, určuje konkrétnı́ DTE v sı́ti
DTE1
DCE1
DCE2
DTE2
žádost o spojení(DA,SA)
[vytváří se SVC]
příchozí spojení(DA,SA)
propojeno
spojení přijato
[zřízen okruh]
posílají se data
žádost o závěr
— NEBO —
ohlášení závěru
následuje
potvrzení závěru
Obrázek 4.3: Schéma průběhu komunikace v X.25
4.2.3
Vrstvy a protokoly
Vztah protokolů X.25 k vrstvám modelu ISO/OSI je naznačen v tabulce 4.1.
Specifikace X.25 je staršı́ než model ISO/OSI, proto se v některých detailech od něho odchyluje
(původnı́ verze ještě mnohem vı́ce), kromě jiného v odlišném názvoslovı́. Napřı́klad vrstva, která
je v ISO/OSI označena jako sı́t’ová, je u X.25 nazývána paketová.
4.3
FRAME RELAY
75
PLP (Packet Layer Protocol) je protokol sı́t’ové vrstvy. PLP pakety nesou data, povely, odpovědi
a identifikace. Speciálnı́ typy paketů sloužı́ k těmto účelům:
• vytvářenı́ a rušenı́ SVC okruhu (nepoužı́vá se u PVC)
• řešenı́ poruch a výjimečných situacı́ – přerušenı́ (když nedorazı́ potvrzenı́ paketů a povolenı́
vyslat dalšı́), obnova (předchozı́ nepomůže – vyčistı́ cestu od paketů), restart (všechny SVC
zrušı́, všechny PVC obnovı́)
PLP tedy pracuje vždy v jednom z těchto módů: navázánı́ spojenı́ (pro SVC), přenos dat, idle
(nečinný u SVC), obnova, restart.
V záhlavı́ PLP paketu najdeme kromě jiného určenı́ typu komunikačnı́ho kanálu a jeho čı́slo,
velikost Sliding Window (počet paketů, po jejichž doručenı́ je třeba pokaždé potvrdit přı́jem), atd.
Protokol LAPB (Link Access Procedure, Balanced)
byl popsán výše.
Protokol fyzické vrstvy je specifikován v doporučenı́ X.21. Definuje elektrické a mechanické
vlastnosti média. Připojenı́ DTE může být analogové s modemem nebo digitálnı́.
ISO/OSI
Sı́t’ová
Linková
Fyzická
X.25 Protocol Suite
PLP
LAPB
X.21 bis, EIA/TIA-232, EIA/TIA-449, EIA-530, G.703
Tabulka 4.1: Vztah X.25 k ISO/OSI
4.3
Frame Relay
Specifikace Frame Relay původně vznikla v rámci specifikace ISDN, ale protože se ukázala dobrá
životaschopnost tohoto řešenı́, v r. 1989 se osamostatnila.
Frame Relay je následovnı́k X.25 se změnami – napřı́klad trochu méně zabezpečenı́ (negarantuje
doručenı́ rámce), nepracuje na sı́t’ové vrstvě, ale na linkové, mı́sto přepı́nánı́ paketů jsou přepı́nány přı́mo
rámce. Obecně platı́, že typickým použitı́m Frame Relay je z principu propojovánı́ lokálnı́ch sı́tı́,
implementace páteřnı́ sı́tě.
Počı́tá se s přenosem po kvalitnı́m a rychlém vedenı́, tedy Frame Relay poskytuje sice službu
se spojenı́m, ale nespolehlivou (poskytuje detekci chyb, ale bez možnosti opravy).
4.3.1
Zařı́zenı́ v sı́ti
V sı́ti Frame Relay se nacházejı́ tato zařı́zenı́:
• DTE (Data terminal equipment) – v provozovnách zákaznı́ků, vlastnı́kem může být zákaznı́k
(počı́tače, servery, terminály, směrovače, mosty)
• DCE (Data circuit-terminating equipment) – poskytujı́ služby synchronizace a přepı́nánı́
provozu (obvykle paketové přepı́nače)
P
4.3
FRAME RELAY
76
'$
Pozor – také to, co je DCE v rámci lokálnı́ sı́tě (napřı́klad Ethernetu, třeba směrovač), zde vystupuje
jako DTE.
DTE
DCE
DTE
DCE
&%
DCE
DTE
DTE
Obrázek 4.4: Zařı́zenı́ v sı́ti Frame Relay
U obou existuje komponenta fyzické vrstvy a komponenta linkové (spojové) vrstvy. Na fyzické
jde většinou o některé sériové rozhranı́, na linkové pracuje protokol LAPF.
Virtuálnı́ okruhy ve Frame Relay fungujı́ podobně jako u X.25, použı́vajı́ se SVC (přepı́nané)
a PVC (pevné). Pro SVC se použı́vajı́ operace navázánı́ spojenı́ (vytvořenı́ okruhu), přenos dat, Idle
a ukončenı́ spojenı́ (zrušenı́ okruhu). U PVC se použı́vá jen operace přenosu dat a Idle.
FRAD (Frame Relay Access Device, Frame Relay Assembler/Disassembler) je zařı́zenı́, které
sloužı́ k přı́stupu do sı́tě Frame Relay. Může to být bud’ samostatné zařı́zenı́ (něco jako PAD v X.25),
a nebo je to součást směrovače, přes který je lokálnı́ sı́t’připojena do Frame Relay sı́tě (to je velmi
obvyklé). FRAD je tedy představitel DTE nebo je součástı́ DTE.
4.3.2
P
P
Garance informačnı́ho toku
Parametr CIR (Committed Information Rate, zaručený informačnı́ tok) určuje propustnost, kterou
má spoj zaručovat. Hodnota CIR je pro okruhy PVC dohodnuta mezi poskytovatelem (telekomunikačnı́ společnostı́) a uživatelem (vlastnı́kem lokálnı́ sı́tě, která má být připojena), pro okruhy
SVC je dohodnuta při navazovánı́ spojenı́. Rámce posı́lané nad hodnotu CIR mohou být při většı́m
zatı́ženı́ sı́tě zahazovány.
P
Pro uživatele má hodnota CIR tento význam:
• čı́m vyššı́ CIR, tı́m je služba dražšı́,
• čı́m menšı́ CIR, tı́m většı́ pravděpodobnost zahazovánı́ paketů a potenciálně pomalejšı́ přenos.
Nárazový informačnı́ tok (také EIR, Excess Information Rate) představuje maximálnı́ informačnı́ tok,
který dokáže přenosová cesta zvládnout (přesněji to, co je navı́c nad CIR).
Rámce zası́lané nad hodnotu CIR, které nepřekračujı́ hranici EIR, jsou označeny jako vhodné
k zahozenı́ (DE, Discard-Eligible). Jsou předávány přepı́nači Frame Relay (tj. do FR sı́tě) tak dlouho,
dokud nenı́ k dispozici dostatečná šı́řka pásma (dokud se nevejdou do CIR). Označenı́ rámce jako
vhodného k zahozenı́ obvykle neznamená, že rámec nebude doručen, ale že se jeho doručenı́ může
(i dost hodně) zdržet.
Na trhu se můžeme setkat s nabı́dkami telekomunikačnı́ch operátorů na Frame Relay s CIR
$
L
4.3
FRAME RELAY
77
rovným 0, tj. žádný informačnı́ tok nenı́ garantován. Účelem je nabı́dnout co nejnižšı́ cenu, což
pro zákaznı́ka nemusı́ být vždy nejlepšı́ řešenı́ (všechny posı́lané rámce by byly označeny jako
DE, vhodné k zahozenı́). Hodnota CIR pro pevné virtuálnı́ okruhy by měla být součástı́ smlouvy.
Doporučuje se hodnota CIR alespoň na úrovni 50 % celkového informačnı́ho toku.
SLA (Service Level Agreement) = dohoda o úrovni poskytovaných služeb (tento pojem se použı́vá
obecně u tohoto typu služeb, nejen pro Frame Relay). Jedná se o dohodu o parametrech služby, zde
také zahrnuje CIR a EIR.
P
Situace na trhu (březen 2012):
• obvykle okruhy PVC, CIR=50%, EIR = 50% přı́stupové rychlosti (cena podle rychlosti)
• u telekomunikačnı́ch firem už obvykle nenı́ v aktuálnı́ nabı́dce, nahrazována službou MPLS
4.3.3
Spojová vrstva a adresace
Na spojové vrstvě pracuje bitový protokol LAPF, který byl již popsán výše.
Adresace v okruzı́ch na spojové vrstvě je založena na DLCI (Data Link Connection Identifier).
Narozdı́l od X.25 nejde o adresu zařı́zenı́, ale o identifikaci okruhu (přesněji identifikaci jednoho
konce okruhu vedoucı́ho od některého DTE k přı́stupovému bodu sı́tě Frame Relay). Je to čı́slo,
které zabı́rá většinou 10 bitů, také 16 nebo 23 bitů.
P
DLCI je vždy jedinečné v rámci LAN, žádná dvě zakončenı́ virtuálnı́ch okruhů u DTE v jedné
LAN nemajı́ totéž DLCI. Hodnoty DLCI pro DTE v našı́ LAN zı́skáme od poskytovatele služby
Frame Relay (typicky telekomunikačnı́ společnost).
V celé sı́ti WAN (propojujı́cı́ různé lokálnı́ sı́tě) však může existovat vı́ce okruhů se stejným
DLCI, k jednoznačné adresaci se přidává ještě označenı́ DTE na začátku okruhu. Navı́c se hodnota
DLCI při průchodu přes přepı́nače měnı́, na každém konci mı́vá okruh jiné DLCI.
K mapovánı́ vztahu IP adres zařı́zenı́ v sı́ti k čı́slům DLCI se použı́vá protokol I-ARP (Inverse
ARP), který je obdobou protokolu ARP v Ethernetu. Takto zjištěné dvojice adres a DLCI jsou
dynamické záznamy, ale lze je také přidávat napevno (staticky).
Některé DLCI jsou vyhrazeny pro účely signalizace stavů, problémů apod., předevšı́m z rozsahu
0–16. Dále rozmezı́ 1019–1022 je určeno pro skupinové vysı́lánı́.
Do (datového) rámce protokolu LAPF se zapouzdřuje IP datagram. Rámec obsahuje podobné
informace jako rámec HDLC (obklopujı́cı́ synchronizačnı́ oktety, kontrolnı́ součet, apod.), ale prostor řı́dicı́ho pole je „pohlcen“ adresovým polem, které zabı́rá 2–4 oktety.
V takto rozšı́řeném adresovém poli je předevšı́m DLCI, na který má být rámec směrován, a dále
řı́dicı́ bity:
• C/R – command/response bit, určuje, zda jde o přı́kaz (command) nebo odpověd’ či reakce
na dřı́ve zaslaný přı́kaz (response)
• bit FECN (Forward-explicit congestion notification, dopředné oznámenı́ o přetı́ženı́), DCE na
cestě oznamuje, že tento rámec byl poslán po přetı́ženém spojenı́, a tedy DTE, které je cı́lem
rámců komunikace, by mělo snı́žit frekvenci přı́jmu rámců (pokud tak dokáže vyššı́ vrstva
reagovat)
P
4.3
FRAME RELAY
78
• bit BECN (Backward-explicit congestion notification, zpětné oznámenı́) – oznámenı́ zdroji
vysı́lánı́ o přetı́ženı́ linky, zdrojové zařı́zenı́ by mělo snı́žit objem vysı́lánı́
• bit DE (Discard-Eligible) – v rámcı́ch, které mohou být při přetı́ženı́ zahozeny
Když DCE zjistı́ přetı́ženı́, nastavı́ v posı́laném rámci bit FECN. Takto přijı́majı́cı́ DTE zjistı́, že na
lince došlo k zahlcenı́ spoje. Naopak když DCE přepı́ná rámec s nastaveným FECN, v nejbližšı́m
rámci posı́laném v okruhu v opačném směru nastavı́ bit BECN. Takto vysı́lajı́cı́ DTE zjistı́, že na
lince došlo k zahlcenı́ spoje.
V sı́ti Frame Relay nenı́ prováděno přı́mo řı́zenı́ toku dat, to je ponecháno na zařı́zenı́ch DTE
(která vlastně nepatřı́ do vnitřnı́ sı́tě Frame Relay). Na oznámenı́ o přetı́ženı́ (bitem FECN nebo
BECN) DTE může reagovat spuštěnı́m mechanismu řı́zenı́ toku dat.
CRC (kontrolnı́ součet, resp. FCS – Frame Check Sequence) je použı́ván pro kontrolu neporušenosti rámce. Vadný rámec je zahozen, linková vrstva se už nestará o žádost o nové vyslánı́ rámce
(pouze kontrola chyb, ne náprava), ale mohou to provést protokoly vyššı́ vrstvy.
4.3.4
LMI
LMI (Local Management Interface) je rozšı́řenı́ základnı́ specifikace pro Frame Relay.1 Protokol
LMI sloužı́ ke komunikaci mezi zařı́zenı́m DTE a DCE, představuje tedy rozhranı́ mezi lokálnı́ sı́tı́
a sı́tı́ Frame Relay.
P
Zprávy protokolu LMI jsou posı́lány vždy po okruhu PVC k tomuto účelu určeném. LMI přinesl
několik vylepšenı́ původnı́ho rozhranı́, předevšı́m:
• globálnı́ adresace – identifikátor DLCI je nejen lokálně, ale i globálně unikátnı́,
• zprávy o stavu virtuálnı́ho okruhu – u PVC okruhů mezi DTE a DCE jsou pravidelně zası́lány zprávy o stavu okruhu, účelem je zamezit zbytečným ztrátám rámců posı́laných na již
neexistujı́cı́ okruhy,
• multicasting – umožňuje definovat skupiny DTE, šetřı́ přenosové cesty.
Existujı́ tři LMI protokoly, typ použitého protokolu obvykle určuje DCE:
1. cisco
2. ansi (Annex D)
3. q933a (Annex A)
Prvnı́ použı́vá pro signalizaci DLCI 1023, dalšı́ dvě použı́vajı́ DLCI 0. Tedy po spojenı́ jsou přenášeny
bud’ datové rámce s DLCI podle cı́le, a nebo služebnı́ LMI rámce (obvykle jeden ze dvou typů zprávy
– dotaz na stav sı́tě směřujı́cı́ od zákaznı́ka nebo stav sı́tě od DCE).
Rámec LMI
Rámce v sı́ti podle rozšı́řenı́ LMI majı́ zcela odlišnou strukturu:
• Flag
• LMI DLCI – identifikuje LMI rámec, je nastavena na hodnotu 1023 (na 2 B, resp. 6 bitů, pak 2
bity pro přı́znaky, v dalšı́m 4 bity DLCI, zbytek opět přı́znaky)
1
V roce 1990 publikovaly LMI společnosti Cisco Systems, StrataCom, Northern Telecom a Digital Eqipment Corporation.
4.3
FRAME RELAY
79
•
•
•
•
Unnumbered Information Indicator – nastaven na hodnotu 3 (v 1 B)
Protocol Discriminator – opět hodnota typická pro LMI (17)
Call Reference – nastavena vždy na 0
Message Type – podle směru bud’ Status-inquiry (dotaz na stav sı́tě od zákaznı́ka) nebo Status
(stav sı́tě)
• Information Elements – je zde typ elementu, délka a samotná data
• FCS, Flag
4.3.5
Tabulky na zařı́zenı́ch
Na jednotlivých zařı́zenı́ch jsou rámce přepı́nány podle přepı́nacı́ch tabulek. Uvnitř FR sı́tě najdeme
FR switche (to jsou DCE), jejich tabulka je vcelku jednoduchá, jak vidı́me na obrázku 4.5 (přı́padně
by byl ještě dalšı́ sloupec – informace o tom, zda je daná cesta aktivnı́).
Přijato z
IN_Port IN_DLCI
P0
P0
100
150
Přepnout na
OUT_Port OUT_DLCI
P1
P2
200
300
P0
-
150 100
P2
FR
switch 300
P1
-
..
.
200
Obrázek 4.5: Ukázka jednoduché přepı́nacı́ tabulky Frame Relay switche
Dı́ky jednoduchosti mechanismu je přepı́nánı́ velmi rychlé.
Na hranici sı́tě jsou zařı́zenı́, která na jedné straně komunikujı́ se zařı́zenı́mi lokálnı́ sı́tě zákaznı́ka, na druhé straně komunikujı́ s FR switchi. Tato zařı́zenı́ (FR routery – v roli DTE) obsahujı́ dvě
tabulky:
• směrovacı́ tabulku určujı́cı́, kam se rámec směřujı́cı́ do sı́tě s danou IP adresou má poslat,
• tabulku mapovánı́ DLCI.
Obsah a význam obou tabulek vidı́me na obrázku 4.6. Na třetı́ vrstvě je paket nasměrován na daný
DCE (na druhé straně FR sı́tě) a přı́slušné rozhranı́, na druhé vrstvě je nastaveno DLCI (FR switche
uvnitř FR sı́tě vidı́ jen na druhou vrstvu).
4.3.6
Řešenı́
Veřejné FR sı́tě jsou provozovány poskytovatelem telekomunikačnı́ch služeb. DCE jsou ve vlastnictvı́ poskytovatele telekomunikačnı́ch služeb, DTE jsou většinou ve vlastnictvı́ zákaznı́ka, a nebo
mohou být zákaznı́kovi pronajı́mány poskytovatelem telekomunikačnı́ch služeb (může to být třeba
i směrovač).
Zákaznı́kovi je účtováno použı́vánı́ spojenı́, administrace a údržba jsou na straně poskytovatele.
P
4.4
ATM
80
Routing Table:
Network
Next Router
Interface
10.5.0.0/16
10.27.0.0/16
172.16.1.2
172.16.1.8
S0
S1
..
.
FR Map:
Next router
DLCI
172.16.1.2
172.16.1.8
100
200
..
.
IP
datagram
do sı́tě
10.5.0.0/16
FR S0
router
100
FR sı́t’
WAN IP routeru:
172.16.1.2
FR
router
sı́t’10.5.0.0/16
Obrázek 4.6: Směrovánı́ na FR routeru (DTE), paket přicházı́ do FR sı́tě
Pokud chce organizace využı́t nabı́dky telekomunikačnı́ho operátora a propojit své pobočky
pomocı́ Frame Relay (i mezinárodně), potřebuje obvykle v každé pobočce nejméně jeden (většinou)
směrovač podporujı́cı́ protokol Frame Relay (tento parametr zjistı́me u prodejce), a samozřejmě
smlouvu s poskytovatelem. Směrovač pak vede tabulku s hodnotami DLCI pro různé komunikujı́cı́
směrovače z jiných poboček a také dalšı́ DLCI s jiným významem (viz podsekci o LMI), směruje
podle hodnot DLCI.
V sı́ti telekomunikačnı́ho operátora fungujı́ obvykle přepı́nače Frame Relay, které mohou pracovat nad jinou sı́tı́ (ATM, SDH apod.).
Soukromé firemnı́ sı́tě se vyznačujı́ tı́m, že jsou zde všechny prvky sı́tě vlastněny zákaznı́kem
(zde firma provozujı́cı́ sı́t’). Účtovánı́ se provádı́ pouze interně při sledovánı́ sı́tě, administrace
a údržba jsou taktéž na straně firmy.
$
P
Produkty podporujı́cı́ Frame Relay se samozřejmě shánějı́ hůře než běžné směrovače, obvykle
se lze setkat s produkty velkých firem (Cisco, HP, apod.).
Dalšı́ informace o Frame Relay:
•
•
•
•
•
•
•
•
http://www.cs.vsb.cz/grygarek/TPS/FrameRelay/frame.html
http://www.comtel.cz/files/download.php?id=5499
http://books.google.cz/books?id=tROBDX-OBrEC&printsec=frontcover&dq=frame+relay
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/Frame-Relay.html
http://www.javvin.com/protocolFrameRelay.html
http://www.techfest.com/networking/wan/frrel.htm
http://www.cs.vsb.cz/grygarek/PS/lect0304/ps1lect11.html
http://www.yourdictionary.com/computer/frame-relay
4.4
ATM
4.4
81
ATM
ATM (Asynchronous Transfer Mode) je WAN sı́t’ široce použı́vaná na telekomunikačnı́ch sı́tı́ch.
Účelem je co nejefektivněji přenášet různé typy dat právě po telekomunikačnı́ sı́ti. Vyznačuje se
vysokou efektivnostı́ (i rychlostı́) přenosu a jde předevšı́m o to najı́t kompromis mezi řešenı́mi
pro telekomunikačnı́ a řešenı́mi pro počı́tačové sı́tě. Normalizacı́ se zabývá ITU-T, spolupracuje
s výrobci sdruženými ve Fóru ATM.
Telekomunikačnı́ sı́tě
Počı́tačové sı́tě
přepojovánı́ okruhů
mnoho funkcı́ včetně řı́zenı́ chyb
spolehlivá služba
spojovaná služba
synchronnı́ režim (STM)
většinou přepojovánı́ paketů
spı́še samotný přenos
nespolehlivá služba, best effort
spojovaná i nespojovaná
různé
P
Tabulka 4.2: Porovnánı́ vlastnostı́ telekomunikačnı́ch a počı́tačových sı́tı́
„Asynchronnı́“ v názvu neznamená asynchronnı́ přenos, ale nepravidelné zası́lánı́ „plných“
buněk na cestě, buňky jsou obsazovány daty podle potřeby, ne podle algoritmu.
ATM pracuje na principu komunikace se spojenı́m, nespolehlivá služba (tj. bez oznámenı́ chyb),
na plném duplexu (ve skutečnosti dva simplexy), v statistickém multiplexu. Důležitou vlastnostı́
je garance kvality služeb pro různé typy dat.
PDU se nazývajı́ buňky, jsou velmi malé s konstantnı́ délkou 53 oktetů (z důvodu jednoduchého
a rychlého přepı́nánı́). Jde o přepojovánı́ na pevných nebo přepı́naných virtuálnı́ch okruzı́ch, proto
adresa nemusı́ být přı́mo součástı́ buňky.
4.4.1
P
Zařı́zenı́ a cesty v sı́ti
V sı́ti ATM existujı́ dva typy zařı́zenı́:
• ATM switch (DCE)
• ATM koncové zařı́zenı́ (endpoint, DTE) – může být počı́tač, router, přepı́nač lokálnı́ sı́tě,
kodek, atd., připojeno přes NIC
Jsou definovány dva typy rozhranı́:
• UNI (User-to-Network Interface) – komunikace mezi endpointem a ATM switchem (DTE–
DCE)
• NNI (Network-to-Network Interface) – komunikace mezi jednotlivými ATM switchi uvnitř
sı́tě ATM (DCE–DCE)
Lišı́ se záhlavı́m buněk přes ně posı́laných.
ATM stavı́ komunikaci na pevných nebo přepı́naných virtuálnı́ch okruzı́ch, třebaže se spı́še
mluvı́ o virtuálnı́ch cestách a virtuálnı́ch kanálech. Pevné okruhy vyžadujı́ ručnı́ konfiguraci na
P
P
4.4
ATM
wg
VP 1
ATM spoj
VP 2
vf
fv
82
VPI/VCI = 1/1
VPI/VCI = 1/2
VPI/VCI = 1/3
VPI/VCI = 2/1
VPI/VCI = 2/2
VPI/VCI = 2/3
Obrázek 4.7: Virtuálnı́ cesty a virtuálnı́ kanály v ATM (zjednodušeně)
Přijato z
Port VPI VCI
A
A
B
1
3
1
..
.
29
42
18
Přepnout na
Port VPI VCI
B
C
C
2
1
2
42
8
36
A
-
ATM C
switch
B
-
-
Obrázek 4.8: Ukázka jednoduché přepı́nacı́ tabulky ATM switche
všech přepı́načı́ch na cestě okruhem, tedy jejich vytvořenı́ je náročnějšı́ (a tudı́ž dlouhodobějšı́
a je možné zároveň specifikovat některé dalšı́ parametry včetně QoS), přepı́nané virtuálnı́ okruhy
zase vyžadujı́ jednotnou adresaci v celé sı́ti a funkčnost signalizačnı́ch protokolů pro dynamické
vytvořenı́ cesty.
Virtuálnı́ cesta a virtuálnı́ kanál jsou obdobou virtuálnı́ho okruhu v telekomunikacı́ch. V jedné
fyzické přenosové cestě může vést vı́ce virtuálnı́ch cest. Virtuálnı́ cesta sdružuje vı́ce virtuálnı́ch
kanálů, tj. určenı́ (čı́slo) kanálu je lokálnı́ vzhledem k virtuálnı́ cestě, po které je veden.
P
Čı́slo virtuálnı́ cesty označujeme VPI (Virtual Path Identifier), čı́slo virtuálnı́ho kanálu označujeme VCI (Virtual Channel Identifier). Hodnota VPI/VCI plně identifikuje přenosovou cestu mezi
dvěma sousednı́mi uzly (virtuálnı́ cesta a v rámci této cesty virtuálnı́ kanál), na každém ATM
přepı́nači se měnı́.
ATM switch si vede tabulku připojenı́, ve které jsou přidruženy přı́chozı́ a odchozı́ VPI/VCI,
záznam se tvořı́ během navázánı́ spojenı́ (vytvořenı́ okruhu).
Na obrázku 4.8 je zjednodušená a zkrácená přepı́nacı́ tabulka ATM switche. Jsou v nı́ tři virtuálnı́
cesty. Každý řádek obsahuje jednu přepı́nacı́ informaci, napřı́klad v prvnı́m řádku zjistı́me, že
buňka přicházejı́cı́ z portu A po cestě 1 v kanálu 29 je přepnuta na port B cestu 2 kanál 42. Porty
jsou označeny pı́smeny spı́še pro snadnějšı́ odlišenı́, většinou se setkáme s označenı́m čı́sly nebo
řetězci, podle výrobce.
4.4.2
Buňky
ATM buňka se skládá ze záhlavı́ (5 oktetů) a datového pole (48 oktetů). Záhlavı́ má následujı́cı́
strukturu:
1. GFC (Generic Flow Control, řı́zenı́ globálnı́ho toku, 4 bity) – pouze v UNI buňkách, a to jen
P
4.4
ATM
83
v přı́padě, že na straně uživatele je vı́ce koncových zařı́zenı́, určuje jednu z 16 úrovnı́ řı́zenı́
toku; obvykle nastaveno na 0
2. VPI (u UNI 8 bitů, u NNI se přiberou předchozı́ 4 bity) – identifikace virtuálnı́ cesty
3. VCI (16 bitů) – virtuálnı́ kanál, kombinace VPI/VCI tvořı́ dohromady směrovacı́ pole, určuje
následujı́cı́ cestu buňky v sı́ti (u každého switche se měnı́)
4. PT (Payload Type, druh dat, 3 bity) – určuje druh přenášených dat (uživatelská nebo sı́t’ová),
přı́padné přetı́ženı́ sı́tě a zda jde o poslednı́ buňku z posloupnosti rámce vyššı́ vrstvy
5. CLT (Cell Loss Priority, priorita ztráty buňky, 1 bit) – pokud je nastaven na 1, může být buňka
v přı́padě nutnosti zlikvidována
6. HEC (Header Error Control, zabezpečenı́ záhlavı́, 1 B) – obdoba CRC, jde o samoopravný
kód (dokáže opravit chybu v hlavičce v rozsahu 1 bit)
Zabezpečenı́ záhlavı́ buňky – HEC – se počı́tá jako zbytek po dělenı́ předchozı́ch bitů záhlavı́
(xhodnota bitu ) mnohočlenem x8 + x2 + x + 1, výsledek je mnohočlen 31. stupně (tj. je to polynomiálnı́
kód). Sloužı́ k základnı́ detekci a korekci chyb.
4 bity
8
16
3
1
8
GFC
VPI
VCI
PT
CLT
HEC
12
16
3
1
8
VPI
VCI
PT
CLT
Buňka pro UNI rozhranı́:
HEC
Data →
Buňka pro NNI rozhranı́:
Data →
Tabulka 4.3: Záhlavı́ ATM buňky
Velikost buňky je velmi malá a konstantnı́. Proto nenı́ možné směstnat adresu do záhlavı́
buňky, adresace je nepřı́má. Takováto buňka je obecně dobře využitelná pro různé typy dat, včetně
multimédiı́. Přepı́nánı́ na ATM switchi je velmi rychlé, s hardwarovou podporou, může probı́hat
paralelně.
4.4.3
Architektura
Referenčnı́ model ATM je 3dimenzionálnı́. Kromě vrstev rozlišujeme roviny, vrstvy se rozkládajı́
přes všechny roviny. Podle ISO/OSI jde o fyzickou a linkovou vrstvu, linková je dále členěna.
Roviny:
• řı́dicı́ (control) – správa spojenı́ (navazovánı́ a rušenı́, řı́zenı́ průběhu, generovánı́ řı́dicı́ch
signálů)
• uživatelská (user) – zajišt’uje samotný přenos dat, opravu chyb, řešenı́ zahlcenı́, atd.
• správnı́ (management) – skládá se ze dvou komponent:
P
4.4
ATM
84
– správa vrstev (layer management) – napřı́klad detekce selhánı́ přenosu, řı́dı́ spolupráci
vrstev
– správa rovin (plane management) – obecná, řı́dı́ spolupráci rovin přes všechny vrstvy
Adaptační vrstva ATM
SAR (podvrstva segmentace)
Vrstva ATM
TC (transmission convergence)
Fyzická vrstva
PMD (podvrstva závislá na médiu)
Správa vrstev
CS (podvrstva konvergence)
Správa rovin
Správa rovin
Správa vrstev
Řídicí rovina Uživatelská r. Obrázek 4.9: Architektura ATM
Vrstvy:
• adaptačnı́ vrstva ATM (AAL – ATM Adaptation Layer) – rozhranı́ mezi ATM a vyššı́mi vrstvami
(tj. sı́t’ovými protokoly); multiplexovánı́ a demultiplexovánı́, segmentovánı́ dat na délku 48
oktetů a jejich řazenı́, QoS; také je spı́še řazena na linkovou vrstvu, ale má některé rysy
transportnı́ vrstvy
• vrstva ATM (obdoba spodnı́ části linkové vrstvy v ISO/OSI) – nezávislá na médiu, spravuje
virtuálnı́ cesty a virtuálnı́ kanály, vede tabulku VPI/VCI a použı́vá ji; nejvı́ce odpovı́dá
linkové vrstvě, ale má některé rysy sı́t’ové vrstvy (směrovánı́)
• fyzická vrstva (obdoba fyzické vrstvy v ISO/OSI) – závislá na přenosovém médiu
Vrstva AAL je pouze na koncových zařı́zenı́ch sı́tě ATM, na ATM přepı́načı́ch najdeme pouze
fyzickou vrstvu a vrstvu ATM.
P
4.4
ATM
Fyzická vrstva
85
má dvě podvrstvy:
• TC (Transmission Convergence) – rozdělı́ ATM buňky na jednotlivé bity (na opačném konci
spojenı́ je zase pospojuje)
• PMD (Physical Medium Dependent) – zajištuje samotný přenos, nenı́ specifikována (lze
použı́t jakoukoliv přenosovou technologii)
Protože PMD nenı́ pro ATM přı́mo specifikována a vyššı́ vrstvy také neobsahujı́ nic, co by omezovalo rychlost, nenı́ pro ATM obecně dána žádná maximálnı́ rychlost přenosu.
Na spojových cestách se obvykle využı́vá bud’ SONET nebo SDH (na ně se podı́váme později).
Protokol GFP (Generic Framing Procedure) byl vyvinut pro SDH jako náhrada protokolu HDLC,
mapuje/skládá různé typy datových zpráv do kontejnerů (většı́ch přenosových jednotek) SDH,
má nižšı́ režii než HDLC, navı́c deterministickou.
Aplikační
IP
ATM
MPLS
GEth
SONET/SDH
přenosové médium
Obrázek 4.10: Možnosti spolupráce ATM s jinými sı́těmi
Adaptačnı́ vrstva ATM (AAL) se použı́vá k adaptaci dat mezi protokoly sı́tě ATM a protokoly
vyššı́ch vrstev. Existuje několik typů AAL lišı́cı́ch se předevšı́m garancı́ propustnosti, minimalizace
spojenı́ a detekce chyb.
Typy AAL:
1. AAL1 – konstantnı́ propustnost (rychlost, CBR), služba se spojenı́m, vyžaduje synchronizaci
(závisı́ na fyzické vrstvě) – realtimová, pro přenosy citlivé na zpožděnı́ (hlas, videokonference), podvrstva CS nenı́ využita
2. AAL2 – proměnná propustnost (VBR), se spojenı́m, pro izochronnı́ přenosy (garance přenosové kapacity – šı́řka pásma, konstantnı́ zpožděnı́) jako je přenos obrazových informacı́
proměnných v čase, nenı́ použı́ván
3. AAL3/4 – proměnná propustnost se spojenı́m i bez spojenı́, bez synchronizace, pro data
s tolerancı́ zpožděnı́, s podporou detekce chyb a řazenı́ (čı́slovánı́), podobná SMDS (také
dokáže zpracovávat SMDS pakety), má vysokou prostorovou režii (prodlužuje buňky)
P
4.4
ATM
86
4. AAL5 – proměnná propustnost, se spojenı́m i bez spojenı́, bez synchronizace, bez podpory
detekce chyb, sloužı́ k přepravě IP paketů apod., a emulaci LAN, dnes nejpoužı́vanějšı́
Protokol AAL5 je také znám pod názvem SEAL (Simple Efficient Adaptation Layer), protože proces
zpracovánı́ PDU je velmi jednoduchý – podvrstva SAR jen převezme PDU podvrstvy CS a rozdělı́
na 48oktetové úseky.
Postup odesı́lánı́ dat v AAL5:
• podvrstva CS přidá k rámci vyššı́ vrstvy délku rámce a kontrolnı́ součet a doplnı́ do velikosti,
která je násobkem 48 oktetů, výsledný PDU pošle dále
$
• podvrstva SAR tento PDU rozdělı́ na úseky o délce 48 oktetů
• vrstva ATM z těchto úseků vytvořı́ buňky, tj. přidá záhlavı́, v záhlavı́ majı́ všechny buňky
kromě poslednı́ informaci PT (Payload Type) nastavenu na 0, buňky nejsou čı́slovány
• fyzická vrstva postupně odešle jednotlivé buňky
AAL5 umožňuje zapouzdřit PDU podvrstvy LLC obsahujı́cı́ běžnou komunikaci služeb bez spojenı́
včetně IP datagramů. Podporuje spojenı́ typu
• point-to-point jednosměrná i obousměrná,
• point-to-multipoint pouze jednosměrná (od „kořene stromu“ k „listům“),
neobsahuje podporu spojenı́ typu multipoint-to-multipoint.
4.4.4
QoS
Kvalita služby (QoS, Quality of Service) umožňuje poskytovat různé typy služeb optimalizované
pro určité druhy aplikacı́, v rozlišenı́ podle virtuálnı́ch kanálů. V ATM jsou tyto třı́dy služeb:
• CBR (Constant Bit Rate, konstantnı́ propustnost) – garantuje šı́řku pásma, minimálnı́ zpožděnı́
a odchylku, je vhodná pro aplikace v reálném čase (hlas, obraz, videokonference apod.), je
navržena pro emulaci přepı́nánı́ okruhů,
• VBR (Variable Bit Rate, proměnná propustnost) – nezaručuje šı́řku pásma, minimálnı́ zpožděnı́ ani odchylku, dělı́ se na dvě podtřı́dy:
– RT-VBR (Real Time VBR) pro aplikace, kterým nevadı́ občasná ztráta buňky, ale nemělo
by docházet ke zpožd’ovánı́ buněk (typicky přenos hlasu s kompresı́),
– NRT-VBR (Non-Real Time VBR) pro aplikace, kterým moc nevadı́ mı́rné zpožděnı́, ale
nemělo by docházet ke ztrátě buněk (napřı́klad rezervačnı́ nebo bankovnı́ systémy),
• ABR (Available Bit Rate, dostupná propustnost) – minimalizace ztráty buněk, přičemž buňky
označené nı́zkou prioritou mohou nabrat i většı́ zpožděnı́, buňky s vyššı́ prioritou mohou
předbı́hat, šı́řka pásma je co nejoptimálněji využı́vána (elektronická pošta, přenos souborů,
apod.),
• UBR (Unspecified Bit Rate, nespecifikovaná propustnost) – bez garancı́, volná nepoužitá
šı́řka pásma je využı́vána pro postupné odesı́lánı́ čekajı́cı́ch buněk (použitelná pro všechny
typy aplikacı́, které nevyžadujı́ nutnost garance doručenı́, rychlosti či odchylky, napřı́klad
elektronická pošta).
P
4.4
ATM
87
Pokud je k jednomu ATM přepı́nači dopraveno hodně buněk zároveň, může dojı́t k zahlcenı́ vyrovnávacı́ paměti a buňky s nı́zkou prioritou jsou zničeny. Jestliže navı́c je hodně těchto buněk s vysokou
prioritou, může být problém určit, které majı́ být zničeny.
Jednı́m z důsledků QoS je také snadná možnost přenosu PDU jiných protokolů. Běžně se
nad ATM provozujı́ Frame Relay (Frame Relay over ATM), MPLS (v rámci ATM Multiprotocol
Encapsulation), atd. Informace najdeme napřı́klad na
• https://www.cz.o2.com/file conver/19051/NN10600 700 71s1.pdf
• https://www.cz.o2.com/file conver/19063/TIMP.TE000005v2.pdf.
QoS (Quality of Service) zahrnuje tyto součásti:
1. Dohoda o dopravě (traffic contract) – popisuje předpokládaný tok dat (napřı́klad maximálnı́
garantovanou, minimálnı́ nebo průměrnou propustnost), stanovı́ se při připojenı́ zařı́zenı́ do
sı́tě.
2. Ovlivňovánı́ dopravy (traffic shaping) – regulovánı́ toku buněk v sı́ti při zachovánı́ jejich pořadı́.
3. Dozor nad dopravou (traffic policing) – vynucenı́ dodrženı́ pravidel; přepı́nače sledujı́ datový
tok, a když překračuje dohodnuté parametry, uplatňujı́ restriktivnı́ opatřenı́.
CLP bit (cell loss priority) takových buněk je nastaven na 1 ⇒ buňka může být zrušena
(výběrové rušenı́ buněk – selective cell discarding) při zahlcenı́.
4.4.5
Adresace a navázánı́ spojenı́
Adresy (20 oktetů dlouhé) nejsou součástı́ každé buňky, použı́vajı́ se jen při navazovánı́ spojenı́
(budovánı́ cesty – stanovenı́ hodnot VPI/VCI na ATM přepı́načı́ch). Použı́váme tyto typy adres:
P
• ve veřejných sı́tı́ch adresy podle doporučenı́ E.164 (pro ISDN a SMDS), jedná se o čı́selnou
adresu podobnou telefonnı́mu čı́slu (plochý adresový prostor),
• v soukromých sı́tı́ch je adresace založena na NSAP (Network Service Access Point), adresa je
také čı́selná, ale hierarchicky členěná, součástı́ adresy je také 6oktetová MAC adresa zařı́zenı́.
Prvnı́ch 13 oktetů adresy určuje switch, ke kterému je cı́lové zařı́zenı́ připojeno, cı́lová zařı́zenı́
těchto 13 oktetů přejı́majı́ od switche, ke kterému jsou připojeny, dalšı́ již určuje konkrétnı́ zařı́zenı́
(MAC a 1oktetový suffix, může to být SAP protokolu vyššı́ vrstvy).
Adresová pole:
• AFI (Authority and Format Identifier, 1 oktet) – určuje konkrétnı́ typ adresy (hodnota 45 pro
E.164, 47 pro ICD, 39 pro DCC)
• dále:
– v adrese typu E.164 je 8 oktetů pro telefonnı́ čı́slo (ISDN)
– v adresách typu DCC a ICD je 2oktetové pole pro kód země (DCC), resp. mezinárodnı́
kód organizace (ICD), následuje identifikátor adresy v dané doméně (DFI – Domain
Specific Part Format Identifier) a správce sı́tě (AA – Administrative Authority)
4.4
ATM
88
• RD (Routing Domain, 2 oktety) identifikujı́cı́ směrovacı́ doménu
• Area (identifikátor oblasti), upřesňuje RD
• ESI (End System Identifier, 6 oktetů) – identifikace koncového zařı́zenı́ (IEEE 802 MAC adresa
v lokálnı́ sı́ti)
• selektor (1 oktet) – SAP protokolu vyššı́ vrstvy
Tedy začátek adresy určuje jejı́ typ, následuje konkrétnı́ adresa podle daného protokolu.
spojit(B,A)
S1
A
ne
spojit(B,A)
žádost(B,A,QoS)
žádost(B,A,QoS)
žádost(B,A,QoS)
S1
S2
A
žádost(B,A,QoS)
žádost(B,A,QoS)
S3
S4
B
A
S2
spojit(B,A)
spojit(B,A)
S3
S4
B
S1
S2
S3
S4
B
Obrázek 4.11: Navázánı́ spojenı́ v ATM
Vytvořenı́ přepı́naného virtuálnı́ho okruhu
(signalizace) probı́há takto:
• zdrojový uzel (UNI) odešle žádost o spojenı́
• žádost postupuje uzly sı́tě (přepı́nače, NNI) a tvořı́ se virtuálnı́ okruh, stanovujı́ se čı́sla
virtuálnı́ch kanálů a virtuálnı́ch cest
• když se cesta ukáže jako „slepá“, přepı́nač vrátı́ žádost o krok zpět a hledá se jiná cesta
• cı́lový uzel bud’ potvrdı́ spojenı́, a nebo je spojenı́ odmı́tnuto (nelze navázat)
Samotná signalizace probı́há na vyhrazených cestách (VPI=0) a kanálech, součástı́ definice NNI jsou
směrovacı́ protokoly použı́vané právě při navazovánı́ spojenı́ (protokol PNNI – Private NetworkNetwork Interface).
ATM a multicast: Multicast a broadcast nejsou v ATM přı́mo podporovány, musejı́ být použity
pomocné mechanismy. Jednı́m z nejpoužı́vanějšı́ch je multicast server, který
• přijı́má zprávy určené pro multicast na spojenı́ch typu point-to-point,
• tyto zprávy pak odesı́lá všem, komu jsou určeny, na spojenı́ch typu point-to-multipoint.
V ATM lze totiž uvádět pouze adresu přı́jemce, nikoliv odesı́latele, což znemožňuje přı́mé zası́lánı́
multicast dat.
$
4.4
ATM
4.4.6
89
ILMI
ILMI (Integrated Local Management Interface, Interim Local Management Interface) je rozhranı́
(konkrétně protokol), které eviduje a zpřı́stupňuje informace o stavu komponent koncového zařı́zenı́ jiným koncovým zařı́zenı́m (přesněji je to protokol pro specifickou komunikaci mezi koncovým
zařı́zenı́m a ATM switchem). Pracuje na fyzické vrstvě a vrstvě ATM, použı́vá vyhrazené VCI=16.
ILMI komunikuje pomocı́ protokolu SNMP.
P
Objekty, které spravuje a zpřı́stupňuje, ukládá do databáze MIB (Management Information
Base) podobně jak to dělajı́ protokoly použı́vané pro správu lokálnı́ch sı́tı́.
4.4.7
Spolupráce s LAN
Možnosti propojenı́ LAN pomocı́ ATM jsou tři: Classical IP over ATM, LANE, MPOA.
1. Classical IP over ATM – IP datagram se ve vrstvě AAL5 zapouzdřı́ do LLC/SNAP rámce
a pak pošle přes ATM. Překlad adres (IP×ATM) provádějı́ překladové servery – ATM ARP servery.
Některé vlastnosti IP musı́ být potlačeny (např. multicast a broadcast).
2. Emulace LAN nad ATM – LANE (LAN Emulation) je standard pro emulaci LAN nad ATM
vydaný ATM fórem. Lze přenášet pakety vı́ce různých lokálnı́ch sı́tı́ (napřı́klad 802.3 – Ethernet, 802.5 – TokenRing). Propojovánı́ různých LAN tı́mto způsobem je podobné virtuálnı́m sı́tı́m
(VLAN). Možnosti implementace LANE:
• typ 1: LANE je implementován v NIC koncového zařı́zenı́ (ATM NIC), lze připojit k běžnému
ATM switchi
• typ 2: NIC koncového zařı́zenı́ nenı́ ATM, ale běžná LAN karta, pak se připojuje ke switchi,
který sám provádı́ překlad mezi MAC a ATM adresami
LANE je implementován pouze na „okraji“ ATM sı́tě, při komunikaci s ATM přepı́nači se použı́vajı́ standardnı́ signalizačnı́ postupy ATM. Celková implementace je poměrně složitá a poněkud
křečovitá, protože rozdı́ly mezi protokoly, PDU a průběhem spojenı́ jsou v ATM založeny na zcela
jiném principu než jak je tomu v přı́padě lokálnı́ch sı́tı́.
Je několik typů serverů, které umožňujı́ LANE provozovat. Nejde pouze o mapovánı́ MAC/IP/
ATM adres, ale také o servery administrativnı́ a také existujı́ tzv. BUS servery (Broadcast and
Unknown Server), které na point-to-point spojı́ch přijı́majı́ komunikaci, která je vnitřně (podle
lokálnı́ch sı́tı́) broadcast, a dále ji rozesı́lajı́ na point-to-multipoint spojı́ch, aby to celkově fungovalo
jako broadcast vysı́lánı́.
3. MPOA (Multiprotocol over ATM) rozšiřuje LANE o možnost rychlejšı́ komunikace mezi
emulovanými LAN. Použı́vá se tzv. distribuovaný směrovač (také virtuálnı́ směrovač), který se fyzicky skládá z vı́ce zařı́zenı́, mezi tato zařı́zenı́ se distribuujı́ funkce směrovánı́ a přepı́nánı́.
Při použitı́ MPOA probı́há komunikace na začátku stejně jako v LAN a LANE (přes směrovacı́
servery), ale během několika prvnı́ch rámců je zjišt’ována „zkratka“ (shortcut), přı́mé propojenı́
mezi VLAN sı́těmi a komunikace se zrychluje, už nenı́ nutné použı́vat směrovače na cestě.
4.5
MPLS
90
Jde předevšı́m o to zachovat možnosti směrovánı́ tak, jak jsou na lokálnı́ch sı́tı́ch, ale přitom
eliminovat jejich nedostatky – při běžném směrovánı́ se provádı́ zpracovánı́ sı́t’ového záhlavı́ PDU
na každém směrovači, což znamená značnou časovou ztrátu, ale při použitı́ MPOA se tento proces
provádı́ pouze na hranových (okrajových) zařı́zenı́ch ATM MPOA sı́tě. Na většině cesty datové
jednotky je pak využito přı́mé spojenı́ přes ATM sı́t’, kde ke směrovánı́ nedocházı́. Tato metoda se
také nazývá zero-hop nebo cut-through.
Hlavnı́ nevýhodou MPOA je silná vazba na ATM, nenı́ použitelná na hybridnı́ch přenosových
sı́tı́ch.
Dalšı́ informace o ATM:
• http://vrs.pasnet.cz/vrs99/prezentace/Horak UVT UK Principy ATM.pdf
• http://www.pasnet.cz/atmgrant/zprava/index.html
• http://www.cisco.com/en/US/tech/tk39/tk49/technologies tech note09186a0080094
84f.shtml
• http://www.lupa.cz/clanky/proc-konci-atm/
• http://www.juniper.net/techpubs/software/erx/erx50x/swconfig-link/html/swconfig-link
TOC.html (konfigurace různých typů WAN a MAN sı́tı́, nejen ATM)
Jak lze také vyčı́st z odkazů, ATM postupně ztrácı́ na popularitě (v 90. letech byla velmi populárnı́),
předevšı́m z důvodu kombinace vysoké ceny sı́t’ových prvků, poměrně nı́zké rychlosti a složité
kombinace s lokálnı́mi sı́těmi, zvláště se zrychleným rozvojem Internetu a přenosu IP datagramů.
4.5
MPLS
Dosud jsme se zabývali přepı́nánı́m paketů (X.25), rámců (Frame Relay) a buněk (ATM), ted’ se
podı́váme na přepı́nánı́ značek.
4.5.1
Přepı́nánı́ značek
MPLS (MultiProtocol Label Switching) je sı́t’ založená na přepı́nánı́ značek (label, také návěštı́).
Účelem je přesunout co nejvı́ce režie směrovánı́ (včetně administrace, QoS apod.) na okraj sı́tě tak,
aby vnitřnı́ oblast sı́tě byla co nejrychlejšı́. MPLS dokáže velmi rychle přenášet nejen běžná data,
ale také hlas a video, a to se zajištěnı́m QoS. K výhodám sı́tě ATM se tedy přidává pružnost a vyššı́
rychlost. Dalšı́ výhodou je snadnějšı́ implementace virtuálnı́ch sı́tı́.
Obrovskou výhodou MPLS je mnohotvárnost. Nemá přı́mo definovánu adresaci ani směrovánı́,
(možná proto) dokáže spolupracovat s vı́ce odlišnými protokoly. Původně MPLS pracovala pouze
nad ATM, ale v současné době pracuje také nad Ethernetem, Frame Relay, SONET/SDH a dalšı́mi.
Takže výhody MPLS můžeme shrnout takto:
•
•
•
•
rychlost přepı́nánı́,
zajišt’ovánı́ řı́zenı́ provozu (vyvažovánı́ zátěže) a QoS (odlišné zacházenı́ s různými PDU),
podpora VPN,
schopnost spolupráce s mnoha různými protokoly, pod MPLS mohou fungovat různé technologie.
P
4.5
MPLS
91
V ISO/OSI modelu bychom mohli MPLS zařadit někam mezi druhou (spojovou) a třetı́ (sı́t’ovou)
vrstvu, také se označuje jako vrstva 2.5 nebo 2+.
Technologie byla představena firmou Ipsilon Networks pod názvem IP Switching. Později firma
Cisco vytvořila proprietálnı́ standard Tag Switching, který sı́t’ zbavil závislosti na ATM, podobný,
ale otevřený standard později vydalo sdruženı́ IETF.
Každý datagram, který vstupuje do MPLS sı́tě, je na okrajovém směrovači opatřen jednı́m nebo
vı́ce MPLS záhlavı́mi uspořádanými do zásobnı́ku (stack), a to na rozhranı́ mezi záhlavı́mi druhé
a třetı́ vrstvy. Záhlavı́ protokolu MPLS má tuto strukturu:
P
• samotná značka (návěštı́, label, 20 bitů),
• Qos informace (3 bity), v přı́padě MPLS se setkáme s názvem CoS (Cathegory nebo Class of
Service) nebo také ve významu Experimental (Exp.),
• přı́znak konce zásobnı́ku (1 bit); pokud nenásleduje dalšı́ záhlavı́, je nastaven na 1 (to znamená, že následuje už přı́mo záhlavı́ IP datagramu),
• TTL (Time to Live, 8 bitů).
Značka uložená v MPLS záhlavı́ jednoznačně určuje směrovánı́ datagramu na cestě k následujı́cı́mu
směrovači.
Záhlavı́
rámce
2. vrstvy
MPLS
Label 1,
ES bit = 0
MPLS
Label 2,
ES bit = 0
MPLS
Label 3,
ES bit = 1
Záhlavı́
paketu
3. vrstvy
(např. IP)
Datová část paketu
Tabulka 4.4: Zásobnı́k značek v MPLS
Vnějšı́ (nejvrchnějšı́) záhlavı́ na zásobnı́ku je určeno právě ke stanovenı́ cest. Nenabı́zı́ vpodstatě
o moc vı́c než IP záhlavı́ (s jednı́m důležitým rozdı́lem – rychleji se zpracovává). Dalšı́ záhlavı́
hlouběji v zásobnı́ku majı́ trochu jiný, specifický, účel, napřı́klad záhlavı́ VPN pro určenı́ virtuálnı́
sı́tě, záhlavı́ pro QoS nebo záhlavı́ pro řı́zenı́ provozu.
Přidělovánı́ značek (ve všech záhlavı́ch ve stacku) probı́há formou třı́děnı́ datových jednotek do
třı́d (FEC – Forward Equivalence Class), datové jednotky patřı́cı́ do téže třı́dy jsou z uzlu odesı́lány
se stejným záhlavı́m. Třı́da je stanovena na základě několika kritériı́ – předevšı́m podle prefixu IP
adresy a dále napřı́klad podle některých charakteristik VPN.
4.5.2
P
P
Směrovánı́ v MPLS
Směrovače (spı́še přepı́nače) v sı́ti MPLS jsou nazývány LSR (Label Switching Router). LSR na okraji
sı́tě (tj. komunikujı́cı́ také s uzly v lokálnı́ch sı́tı́ch, které jsou sı́tı́ MPLS propojeny), jsou označovány
jako ELSR (Edge LSR, hranové směrovače), a jsou bud’ vstupnı́ (Ingress ELSR) nebo výstupnı́ (Egress
ELSR) podle směru provozu. U firmy Cisco se můžeme setkat s odlišnou terminologiı́ – LSR jsou
nazývány provider/core router, ELSR se nazývajı́ provider edge router (ale v mnoha dokumentech
se použı́vá „původnı́“ terminologie).
P
4.5
MPLS
92
Velice často se také setkáváme s trochu jiným označenı́m:
• P (Provider) – přepı́nače uvnitř MPLS sı́tě, vždy ve vlastnictvı́ poskytovatele (nebo jeho
poskytovatele),
• PE (Provider Edge) – na hranici MPLS sı́tě,
• CE (Customer Edge) – na hranici sı́tě zákaznı́ka, bud’ v jeho vlastnictvı́ nebo pronajat od
poskytovatele (komunikuje s PE).
'$
Na obrázku 4.12 je naznačena obvyklá struktura MPLS sı́tě s uzly P, PE a CE. CE je součástı́ lokálnı́
sı́tě zákaznı́ka, k jednomu PE může být připojeno vı́ce CE (tj. vı́ce LAN).
P
PE
CE
P
PE
CE
&%
P
P
CE
PE
Obrázek 4.12: Struktura MPLS sı́tě
Směrovánı́ (přepı́nánı́ značek) probı́há podobně jako v ATM, ale ještě jednodušeji. Směrovače si
vedou jednoduchou tabulku (také se nazývá Label Forwarding Database – LFD), která je podobná
tabulce pro ATM, ale mı́sto dvojice VPI/VCI je zde pouze hodnota značky (datagram z portu PPP
opatřený značkou XXX je opatřen značkou YYY a poslán na port QQQ, apod.). Jedná se jen o určenı́
vazby mezi přı́chozı́ a odchozı́ značkou, cesty jsou jednosměrné.
In
port
In
label
Prefix
adresy
Out
label
Out
port
A
A
B
..
.
29
42
18
128.95.0.0/16
128.101.0.0/16
141.62.0.0/16
2
8
36
B
C
C
P
A MPLS C
router 8 36
29 42 29 -
B
18
2
2 -
Obrázek 4.13: Ukázka jednoduché přepı́nacı́ tabulky MPLS směrovače
Na obrázku 4.13 je ukázka tabulky na LSR uvnitř sı́tě. Pokud by se jednalo o vstupnı́ Ingress
ELSR, hodnoty ze sloupce se vstupnı́ značkou a portem by nebyly použı́vány, obdobně u Egress
ELSR by nebyly použı́vány hodnoty ze sloupce s výstupnı́ značkou a portem.
Značka uložená v datagramu se při průchodu směrovači neustále měnı́, podle toho, jak to
bylo nastaveno při navazovánı́ spojenı́, podle obsahu tabulek na průchozı́ch LSR. Tento proces se
nazývá Label Swapping (výměna značek/návěštı́).
P
4.5
MPLS
93
Konkrétnı́ obsah tabulky na LSR závisı́ také na protokolu, se kterým MPLS spolupracuje (tj. na
sı́ti, nad kterou pracuje). Jestliže napřı́klad MPLS pracuje nad ATM, jsou MPLS značky použı́vány
v ATM jako čı́sla VPI/VCI.
Je zřejmé, že tabulky na směrovačı́ch jsou vlastně lokálnı́, vztahujı́ se pouze k nejbližšı́m okolnı́m
směrovačům.
Zařı́zenı́ podporujı́cı́ MPLS obvykle zákaznı́k zı́ská od poskytovatele technologie (napřı́klad
telekomunikačnı́ společnosti, která má k dispozici přenosové cesty). Pokud si ale firma chce vytvořit
vlastnı́ MPLS sı́t’ (má k dispozici své přenosové cesty), existujı́ zařı́zenı́ např. od firem Cisco,
Mikrotik, Juniper.
4.5.3
P
Vytvářenı́ cest
Protokol LDP (Label Distribution Protocol) sloužı́ k výměně informacı́ o značkách mezi směrovači,
výměna informacı́ o prefixech adres probı́há podle některého směrovacı́ho protokolu obecně označovaného zkratkou IGP (Interior Gateway Protocol), což může být prakticky kterýkoliv, velmi
často OSPF (nynı́ spı́še OSPFv2). U MPLS se však setkáváme i s dalšı́mi protokoly, napřı́klad při
implementaci virtuálnı́ch sı́tı́ (VPN) se použı́vá BGP. O směrovacı́ch protokolech se budeme učit
později.
P
pref. 10.4.8.0/24,
lab. 7
Krok 1
R1
pref. 10.4.8.0/24
L1
EL1
EL2
R2
Krok 2
R1
L1
EL1
EL2
R2
(10.4.8.0/24,7,X,R2)
LAN1
LAN2
L2
LAN1
LAN2
L2
pref. 10.4.8.0/24,
lab. 7
pref. 10.4.8.0/24,
lab. 17
Krok 3
pref. 10.4.8.0/24,
lab. 17
Krok 4
L1
L1
(10.4.8.0/24,17,7,EL2)
(10.4.8.0/24,17,7,EL2)
R1
EL1
EL2
(10.4.8.0/24,21,7,EL2)
LAN1
LAN2
L2
pref. 10.4.8.0/24,
lab. 21
R2
R1
EL1
(10.4.8.0/24,X,21,L2)
(10.4.8.0/24,7,X,R2)
EL2
(10.4.8.0/24,21,7,EL2)
LAN1
L2
R2
(10.4.8.0/24,7,X,R2)
LAN2
pref. 10.4.8.0/24,
lab. 21
Obrázek 4.14: Připojenı́ nové LAN do MPLS
Postup přidávánı́ záznamů do tabulek v základnı́ variantě MPLS je naznačen na obrázku
4.14. Oznamovánı́ probı́há „proti směru“ cesty, každý uzel pro přı́chozı́ požadavek stanovı́ čı́slo
(značku), které má právě volné, a pošle požadavek na všechny sousednı́ uzly (i na ten, ze kterého
požadavek přišel). Napřı́klad podle obrázku 4.14 je výstupnı́m LSR směrovač EL2:
• EL2 připojı́ LAN směrovač R2, prefix adresy je 10.4.8.0/24, přiřadı́ značku 7, do tabulky přidá
záznam o tom, že cokoliv přijde na tuto značku a prefix, odešle směrovači R2
• EL2 odešle sousednı́m MPLS směrovačům (L1 a L2) informaci „cestu k sı́ti s prefixem
10.4.8.0/24 najdete na značce 7“
$
4.6
OPTICKÉ PŘENOSOVÉ CESTY
94
• L1 obdržı́ tuto informaci, najde volnou značku 17, přidá do tabulky záznam o tom, že cokoliv
přijde na značku 17 a daný prefix, v tom změnı́ značku na 7 a pošle na směrovač EL2, odešle
informaci směrovačům EL1 a EL2
• podobně L2, ale našel volnou značku 21
• EL1 obdržı́ dvě informace, ale informace z L2 přišla dřı́v, tedy uložı́ výstupnı́ značku 21
4.5.4
Dalšı́ možnosti
GMPLS (Generalized MPLS, také G-MPLS) je rozšı́řenı́ MPLS, které zobecňuje MPLS na dalšı́
vrstvy ISO/OSI a dalšı́ rozhranı́. Účelem je odstranit co nejvı́ce „komunikačnı́ch mezikroků“
a umožnit nasazenı́ MPLS technologie i nad takovými řešenı́mi, nad kterými to dřı́v nebylo možné
(nejen nad řešenı́mi použı́vajı́cı́mi pakety a rámce). Návěštı́ už nemusı́ být jen čı́slo, ale může to být
napřı́klad vlnová délka v optické sı́ti, fyzický port, časový slot v TDM apod., cokoliv, podle čeho
lze rozšilit různé komunikace, tedy MPLS lze nasadit napřı́klad i nad DWDM.
Podobné vlastnosti jako GMPLS majı́ sı́tě ASON (Automatically Switched Optical Network),
také běžı́ nad optickými cestami či SDH, také zahrnujı́ podporu QoS, VPN a rychlého transportu.
GMPLS a ASON jsou porovnávány např. na http://www.dataconnection.com/download/asongmpls.pdf.
Dalšı́ informace o MPLS:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
4.6
4.6.1
http://www.juniper.net/techpubs/software/junos/junos62/feature-guide-62/html/fg-gmpls.html
http://www.faqs.org/rfcs/rfc6002.html
http://vrs.cuni.cz/vrs2001/prezentace/vrs2001-Pilar.pdf
http://www.ietf.org/dyn/wg/charter/mpls-charter.html
FARREL, A., BRYSKIN, I. GMPLS: Architecture and Applications. San Francisco, Elsevier, 2006. Většina stran dostupná na http://books.google.cz/books?id=cCWS75MlUpcC&printsec=frontcover
http://businessworld.cz/case-studies/Nejmodernejsi-datove-propojeni-firemnich-pobocek-pomoci-sluzby-MPLS-L3-VPN-od-firmy-Dial-Telecom-4610
http://www.cisco.com/en/US/products/ps6557/prod white papers list.html
http://www.cisco.com/univercd/cc/td/doc/product/wanbu/bpx8600/mpls/9 3 1/mpls.pdf
http://www.svetsiti.cz/view.asp?rubrika=Technologie&clanekID=302
http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=219&clanekID=230
http://www.cs.vsb.cz/grygarek/TPS/MPLS/Introduction to MPLS.htm
http://www.cs.vsb.cz/grygarek/TPS/MPLS/Introduction to MPLS II.htm
http://wh.cs.vsb.cz/mil051/index.php/Any Transport over MPLS (AToM)
http://electrosofts.com/sonet/
Optické přenosové cesty
SONET/SDH
SONET (Synchronous Optical Network, ANSI T.105) je digitálnı́ optický (na optických vláknech)
přenosový systém využı́vajı́cı́ časový multiplex, centrálně synchronizovaný atomovými hodinami.
Je standardizován a použı́ván v USA, Kanadě a Japonsku.
P
4.6
OPTICKÉ PŘENOSOVÉ CESTY
95
SDH (Synchronous Digital Hierarchy, ITU-T G.707) je obdoba sı́tě SONET ve zbytku světa,
rozdı́ly jsou jen malé (mj. v řı́dicı́ch protokolech). Často se setkáme s označenı́m SONET/SDH,
odkazujı́cı́m na technologii, kterou majı́ obě řešenı́ společnou.
SONET/SDH byla vytvořena pro hlasovou komunikaci a pro tento účel je také optimalizována,
sama o sobě nenı́ efektivnı́m řešenı́m pro přenos dat. Proto nad SDH obvykle pracuje ještě jiný typ
WAN/MAN sı́tě (nad SDH může pracovat napřı́klad ATM, POS – Packet over SONET, MPLS, EoS
– Gigabit Ethernet over SONET/SDH).
Zákaznı́k je nucen zvolit si z několika málo typů služby podle propustnosti (2 Mb/s, 34 Mb/s,
130 Mb/s), za tuto propustnost také platı́, i když ji zrovna nevyužı́vá (pásmo nelze pronajmout
jinému zákaznı́kovi).
Podobně jako některé předchozı́ WAN, i zde je použı́vána PDU o konstantnı́ délce – blok má
délku 810 oktetů. Pracuje se v časovém multiplexu, tedy přenášené bloky dat jsou umı́st’ovány do
volných slotů vysı́laných v pravidelných intervalech 125 µs.
4.6.2
WDM a DWDM
WDM (Wavelength Division Multiplexing) je technologie multiplexovánı́ světla v optických
spojı́ch do vlnových délek. Bez použitı́ WDM je možné jednı́m optickým spojem vést jen jeden
signál, s použitı́m WDM vı́ce signálů zároveň na různých vlnových délkách, na každé vlnové délce
podle jiného protokolu a o jiné rychlosti.
DWDM (Dense Wavelength Division Multiplexing) umožňuje přenášet kanály na vlnových
délkách s velmi malým odstupem, i pod 1 nm. Čı́m menšı́ odstup mezi vlnovými délkami, tı́m
vı́ce na jednu stranu lze přenášet kanálů paralelně, ale na druhou stranu se může zhoršit kvalita
přenosu, proto obvykle nenı́ využı́ván plně. Do jednoho optického vlákna lze poskládat až 128
kanálů, ale ve frekventovaných datových páteřnı́ch sı́tı́ch se spı́še setkáme s 32 kanály v jednom
vlákně (jmenovitě – CESNET2). Počet kanálů také závisı́ na použitých optických multiplexorech
(které provádějı́ samotné mapovánı́ signálu do kanálu a zpět).
P
P
Obvyklá rychlost na jeden kanál (jednu vlnovou délku) je přibližně 10 Gb/s (nebo 40 Gb/s),
a celková propustnost jednoho vlákna je (téměř) součtem propustnostı́ jednotlivých kanálů.
Na DWDM (mezi DWDM a TCP/IP) jsou pak implementovány dodatečné technologie, které
majı́ urychlit a obecně zefektivnit přenos, v současné době předevšı́m IP/MPLS a na okrajı́ch
rozlehlé sı́tě pak napřı́klad EoMPLS (Ethernet over MPLS), který velmi dobře spolupracuje s připojenými ethernetovými LAN.
ROADM (Reconfigurable Add-Drop Multiplexer) jsou multiplexory, které v sı́tı́ch DWDM (obecně
WDM) umožňujı́ automatické vytvářenı́ a správu optických přenosových kanálů. Při použitı́
ROADM nenı́ třeba tyto kanály vytvářet a konfigurovat ručně.
P
Kapitola
5
Data a telekomunikačnı́ sı́tě
V této kapitole se zabýváme postupy při využitı́ telekomunikačnı́ch linek pro datové přenosy. Začneme
analogovou dial-up technologiı́, následuje ISDN a pak různé DSL technologie. Poté se zaměřı́me na telefonnı́
ústředny a VoIP.
5.1
Dial-up technologie
5.1.1
Shannonův teorém
Claude Elwood Shannon je zakladatel modernı́ teorie informace. Shannonův teorém udává strop
pro maximálnı́ rychlost přenosu.
„Aby bylo možné rekonstruovat (na cı́lové stanici) spojitý frekvenčně omezený analogový signál ze vzorků, musı́ být vzorkován s frekvencı́ alespoň dvakrát vyššı́ než je
maximálnı́ frekvence tohoto signálu při přenosu.“
Důsledkem je ohraničenı́ maximálnı́ dosažitelné rychlosti přenosu, a to
• šı́řkou pásma (počet stavů v rámci pásma nelze zvyšovat do nekonečna, ztratili bychom
možnost jeho rozlišenı́)
• kvalitou signálu (vyplývá z fyzikálnı́ch vlastnostı́ linky, zhoršená šumem, také „odstup signálu od šumu“)
ale nezávisı́ na použité technologii (včetně použité modulace).
Vzorec:
max(rychlost přenosu) = šı́řka pásma ∗ log2 (1 + signál/šum)
96
5.1
DIAL-UP TECHNOLOGIE
5.1.2
97
Telefonnı́ sı́t’
Telefonnı́ sı́t’je řešena hierarchicky:
• účastnické zařı́zenı́ (telefon, modem apod.), připojuje se přes účastnickou přı́pojku
• (veřejná) mı́stnı́ telefonnı́ ústředna (MTO)
• uzlová telefonnı́ ústředna (UTO), tranzitnı́ telefonnı́ ústředna (TTO)
P
V rámci firemnı́ho areálu může také fungovat pobočková ústředna (PBX, Private Branch Exchange),
která bývá připojena na některou veřejnou mı́stnı́ telefonnı́ ústřednu (tj. funguje jako brána).
Při přenosu dat přes telefonnı́ sı́t’, dimenzovanou pro přenos zvuku (předevšı́m hlasu), bylo
hlavnı́ motivacı́ využitı́ již existujı́cı́ husté sı́tě těchto linek, tedy snadná dostupnost koncových
bodů.
V telefonnı́ sı́ti platı́: pro přenos hlasu plně postačuje přenášenı́ frekvencı́ z intervalu 300–3400
Hz, ořezánı́ okolnı́ch frekvencı́ prakticky neovlivnı́ kvalitu hovoru. Přenos musı́ být multiplexován,
v analogové sı́ti je volen frekvenčnı́ multiplex s šı́řkou pásma pro jeden přenos zaokrouhlenou nahoru
(s rezervou) – 4000 Hz.
5.1.3
Přenos dat na telefonnı́ch linkách
Telefonnı́ linky jsou optimalizovány pro přenos hlasu, jejich využitelnost pro přenos dat je omezená.
Princip:
•
•
•
⇒
frekvenčnı́ omezenı́ je 300–3400 Hz, tj. šı́řka 3,1 kHz
kvalitnı́ telefonnı́ linka má odstup signálu od šumu přibližně 1000:1
po dosazenı́ do vzorce dostaneme přibližně 30 000 b/s
když po analogové sı́ti přenášı́me data, musı́me s tı́m počı́tat; řešenı́:
P
a) použı́t většı́ šı́řku pásma (modemy 33,6 kb/s)
b) obejı́t frekvenčnı́ omezenı́ (modemy 56 kb/s), jen směr od digitálnı́ ústředny
c) odstranit frekvenčnı́ omezenı́ (ISDN, ADSL) – na digitálnı́ch linkách se použı́vá časový
multiplex, navı́c (u ADSL) se telekomunikačnı́ sı́t’propojuje se sı́tı́ datovou („odbočka“)
PSTN (Public Switched Telephone Network)
přenos hlasu
= běžná telefonnı́ sı́t’dimenzovaná předevšı́m pro
P
• modemy standardu V.21, V.32bis, V.34, . . . , V.90, V.92 – analogové, lišı́ se mj. přenosovými
rychlostmi, rychlejšı́ pracujı́ asynchronně (vyššı́ rychlost při downloadu)
PSTN počı́tá s přenosem analogových dat, ale postupně byla vnitřně digitalizována (obecně až od
mı́stnı́ ústředny), po digitalizaci se mı́sto frekvenčnı́ho použı́vá časový multiplex.
Aby bylo možné po PSTN přenášet data, je potřeba vytvořit „abstraktnı́ nástavbu“, která to
umožňuje. Projdeme si některé nejznámějšı́ technologie (chronologicky).
Analogový POTS (Plain Old Telephone Service)
(PSTN). Kódovánı́:
je založen na běžných telefonnı́ch linkách
P
5.2
MODEMY
98
• kódovánı́ a dekódovánı́ hlasu (analogového) pro přenos na digitálnı́ lince (u digitálnı́ch
ústředen) je prováděno prvkem CODEC (COder-DECoder),
• kódovánı́ digitálnı́ch dat do analogové formy je prováděno MODEMem (MOdulator-DEModulator).
Existuje vı́ce různých kodeků, napřı́klad:
• PCM (Pulse Coded Modulation) – na pevných telefonnı́ch linkách (digitálnı́ ústředny), snı́má
amplitudu signálu každých 125 µs, vzorkuje signál rychlostı́ 8 kb/s
• FR (Full Rate), HR (Half Rate), EFR (Extended Full Rate) – v sı́tı́ch GSM
• G.729, GSM FR, Speex, iLBC – kodeky pro VoIP
Zatı́mco POTS počı́tá s analogovými linkami, dalšı́ technologie již jsou digitálnı́ – BRI a PRI.
BRI (Basic Rate Interface) je tedy digitálnı́ technologie, použı́vá se pro uživatelskou ISDN. Nenı́
třeba použı́vat CODEC, digitálnı́ data jsou posı́lána přı́mo k (digitálnı́) ústředně. Komunikačnı́
kanály:
• dva B- (bearer, nosné) kanály pro data a hlas, každý 64 kb/s
• jeden D- (delta) kanál pro řı́dicı́ informace (signalizaci), a to 16 kb/s, může sloužit pro přenos
paketů X.25
Kanály sdı́lejı́ jeden kabel formou časového multiplexu.
PRI (Primary Rate Interface) je také digitálnı́ ISDN rozhranı́, ale je určeno spı́še pro firmy. Je
k dispozici 30 (v Evropě) nebo 23 (v USA) B-kanálů po 64 kb/s, jeden D-kanál 64 kb/s. Důsledkem
je výrazně vyššı́ rychlost než u BRI.
5.2
Modemy
Modem představuje DCE, počı́tač (nebo jiné zařı́zenı́) k němu připojený je DTE.
Modem (MODulator, DEModulator) je zařı́zenı́, které moduluje digitálnı́ data na analogový
signál (modulace) a zpět (demodulace). Dřı́ve se použı́valy analogové modemy, v současné době
se setkáváme předevšı́m s digitálnı́mi modemy (ISDN, DSL). Data se tedy přenášejı́ po analogovém
signálu, a to pomocı́ kroucené dvojlinky (jednoduchá UTP, telefonnı́ kabel), koaxiálu (napřı́klad
rozvody pro kabelovou televizi), přı́padně bezdrátově (napřı́klad mobilnı́ připojenı́ od mobilnı́ch
operátorů).
Na obrázku 5.1 je znázorněn postup digitalizace ve vývoji od starých čistě analogových modemů
podle standardu V.34 po ISDN zařı́zenı́ (DSL zde nemá smysl uvádět, narozdı́l od ISDN to nenı́
vytáčené spojenı́). Vytáčená spojenı́ (dial-up) jsou v principu hlasové, nikoliv datové služby.
K digitálnı́m modemům se vrátı́me v následujı́cı́ch sekcı́ch této kapitoly, zde krátce k analogovým modemům.
Existuje vı́ce různých standardů, pro analogové modemy jsou směrodatné V.34 (rychlost 28,8
kb/s až 33,6 kb/s) a V.90 (rychlost obvykle 56 kb/s, resp. až 64 kb/s). U modemů V.90 (a také V.92)
se ve skutečnosti standard V.90 použı́vá jen ve směru k modemu, odesı́lánı́ dat probı́há rychlostı́
P
5.3
ISDN
99
Analogový přenos:
digitálně
(33,6 kb/s)
DTE
analogově
V.34
digitálně
(33,6 kb/s)
analogově
...
MTO
analogově
analogově
Digitalizace sítě, modem V.34:
digitálně
(33,6 kb/s)
DTE
digitálně
(64 kb/s)
analogově
V.34
digitálně
(33,6 kb/s)
...
MTO
digitálně
(64 kb/s)
analogově
Digitalizace sítě, modem V.90:
digitálně
(33,6 kb/s)
DTE
digitálně
(64 kb/s)
analogově
V.90
digitálně
(56 kb/s)
...
MTO
digitálně
(56 kb/s)
digitálně
(64 kb/s)
digitálně
(64 kb/s
digitálně
(64 kb/s)
Digitalizace sítě, ISDN:
digitálně
(64 kb/s)
DTE
ISDN
digitálně
(64 kb/s)
...
MTO
digitálně
(64 kb/s)
digitálně
(64 kb/s)
Obrázek 5.1: Analogové a digitálnı́ linky
dle standardu V.34. Analogové modemy se připojujı́ pomocı́ konektoru RJ-11, který je o něco užšı́
než ethernetový RJ-45 (protože se použı́vá nižšı́ typ kroucené dvojlinky s méně páry, tedy nenı́
nutné mı́t v konektoru tolik drátů).
Použı́vané protokoly:
• PPP (viz dřı́ve) – autentizace PPP nebo CHAP
• Multilink PPP (MPPP) – lépe vyvažuje zatı́ženı́ sı́tě (umı́ zkombinovat vı́ce portů a tak zvýšit
šı́řku pásma pro přenos), pro asynchronnı́ sériové rozhranı́, BRI, PRI
• Multichassis Multilink PPP (MPP) – umožňuje přidělit uživatelům přihlašujı́cı́m se na jeden
server (s jednı́m modemem) jediné telefonnı́ čı́slo pro dial-up a na vyššı́ úrovni oddělovat
jejich komunikaci, vhodné pro ISP
• PPPoA, PPPoE a jejich varianty
5.3
ISDN
5.3
5.3.1
100
ISDN
Princip ISDN
ISDN (Integrated Services Digital Network) byla původně pokusem o využitı́ existujı́cı́ch telefonnı́ch rozvodů pro digitálnı́ telefonii a transport dat různého charakteru (i obojı́ zároveň). Zaváděnı́
ISDN úzce souvisı́ s digitalizacı́ telefonnı́ sı́tě, hlavně dı́ky ISDN dnes máme po celé republice
digitálnı́ ústředny.
Přenos zvuku (telefonnı́ služby) je realizován s využitı́m kodeku PCM. Zpoplatněnı́ přenosu
zvuku i dat je závislé na čase, jde o vytáčené spojenı́.
Přenosová kapacita je rozdělena na B-kanály a D-kanál, existujı́ dva druhy rozhranı́
• BRI (u nás euroISDN2) pro domácnosti a malé kanceláře
• PRI (u nás euroISDN30) pro většı́ firmy
V BRI je bitový tok rozdělen na časové rámce po 48 bitech (0,25 ms) – 2 oktety pro každý B-kanál,
4 bity pro D-kanál a 12 doplňkových bitů, rychlost u BRI je maximálně 160 kb/s.
5.3.2
BRI
Zařı́zenı́ v sı́ti
• TE1 (Terminal Equipment) – koncové zařı́zenı́ s rozhranı́m ISDN
• TE2 – nemá rozhranı́ ISDN (analogový telefon, analogový modem apod.), k ISDN se připojuje
pomocı́ TA (adaptéru)
• NT (network termination, ukončenı́ sı́tě) – rozhranı́, ke kterému se připojujı́ TE1 a TA, má
dvě části:
– NT1 – zajišt’uje fyzické připojenı́, transformuje signály
– NT2 – hornı́ část, umožňuje připojit TE1 a TA (až 8)
Mezi nimi jsou rozhranı́ U, T (terminal), S (system), R (rate). Struktura je na obrázku 5.2.
ISDN
telefon
PC
S
T
NT2
Analog.
telefon
TA
NT1
U síť
R
Obrázek 5.2: Zařı́zenı́ v sı́ti ISDN BRI
B-kanály pracujı́ s přepojovánı́m okruhů a majı́ vyššı́ přenosovou rychlost, D-kanály pracujı́
s pakety, a to se spojenı́m i bez spojenı́.
E
5.4
TECHNOLOGIE XDSL
101
V ISDN je definována fyzická, linková a sı́t’ová vrstva. Model je 3D (podobně jako ATM), existujı́
roviny uživatelská, řı́dicı́ a rovina managementu (správnı́).
• fyzická vrstva – protokoly fyzické vrstvy zahrnujı́ předevšı́m definici rozhranı́ S, T, U, R
• linková vrstva – spojový protokol LAPD
• sı́t’ová vrstva – protokol sı́t’ové vrstvy použı́vá D-kanál, po něm posı́lá zprávy, princip komunikace je podobný jako u sı́tı́ X.25
Spojenı́ je vytáčené (tarifikace závislá na délce spojenı́) a jeho navázánı́ trvá jen kolem 2 s,
proto nemá smysl nechávat spojenı́ aktivnı́ neustále. Navazovánı́ spojenı́ probı́há na D-kanálu
(ten bývá neustále aktivnı́, většinou nenı́ zpoplatněn), odesı́lajı́ se aktivačnı́ informace (telefonnı́
čı́slo přı́jemce, identifikace volajı́cı́ho uzlu, typ volánı́ – hlasové, datové nebo faxové, apod.), pak je
přidělena IP adresa.
5.4
Technologie xDSL
xDSL (Digital Subscriber Line) je skupina širokopásmových technologiı́, která v sobě sdružuje
několik různých technologiı́ (ADSL, SDSL, HDSL, HDSL-2, G.SHDL, IDSL, VDSL). Může to být
technologie „prvnı́ mı́le“ pro připojenı́ k Internetu, resp. k NSP (Network Service Provider). Jedná
se o vyhrazenou službu, point-to-point.
P
Je to služba se spojenı́m, ale tarifikace nebývá závislá na čase.
5.4.1
ADSL
ADSL (Asymmetric Digital Subscriber Line) je asymetrická služba. Asymetrická proto, že downstream (stahovánı́ dat do DTE) je rychlejšı́ než upstream (odesı́lánı́ dat do sı́tě).
Teoreticky lze dosáhnout rychlostı́ až 24 Mb/s (v novějšı́m standardu dokonce až 48 Mb/s).
U nás nabı́zená rychlost je 8 Mb/s nebo 16 Mb/s pro downstream, ale reálná rychlost může být nižšı́.
Upstream bývá na rychlosti 1 Mb/s.
Rychlost je ovlivněna vı́ce různými kritérii. Je to nejen použité zařı́zenı́ a přenosové protokoly,
ale také délka spoje – čı́m většı́ vzdálenost k mı́stnı́ ústředně, tı́m pomalejšı́ spojenı́.
Rozsah
Šı́řka
Účel
0 kHz –4 kHz
4 kHz –26 kHz
26 kHz –138 kHz
138 kHz –1100 kHz
4 kHz
22 kHz
112 kHz
962 kHz
přenos hlasu (telefon)
náraznı́kové pásmo
upstream
downstream
Tabulka 5.1: Využitı́ přenosového pásma v ADSL
V technologii ADSL (a taky v dalšı́ch DSL technologiı́ch) se navýšenı́ rychlosti dosahuje kromě
jiného i odkloněnı́m datového toku z telefonnı́ch linek na datovou sı́t’ poskytovatele (obvykle
některou WAN sı́t’na optických kabelech). Princip je naznačen na obrázku 5.3.
P
E
5.4
TECHNOLOGIE XDSL
102
telefonní síť
DTE
Ústředna
datová síť
Obrázek 5.3: Provedenı́ ADSL
Oddělenı́ upstream a downstream dat
– možnosti:
1. FDM (frekvenčnı́ multiplex) – frekvence pro upstream a downstream jsou striktně odděleny,
nepřekrývajı́ se (dajı́ se oddělit jednoduchým filtrem)
P
2. potlačenı́ ozvěny (EC, Echo Cancellation) – kanály pro upstream a downstream se částečně
překrývajı́, pak jsou odděleny pomocı́ telekomunikačnı́ vidlice
FDM je jednoduššı́ na implementaci (také je menšı́ pravděpodobnost přeslechů při velmi velkém
množstvı́ ADSL zařı́zenı́ na jednom kabelu), EC lépe využı́vá frekvenčnı́ pásma (kanály na nižšı́ch
frekvencı́ch jsou obvykle méně rušeny) a přenos je rychlejšı́. Dnes se použı́vá spı́še EC.
Modulace v ADSL
– použı́vá se CAP nebo DMT.
CAP (Carrieless amplitude phase modulation) je dalšı́ možný typ modulace pro ADSL. Tato modulace je velmi podobná QAM modulaci. CAP použı́vá pro celé přenášené pásmo (1,1 MHz) jediný
kmitočet, fakticky nedocházı́ k dělenı́ na kanály.
P
DMT (Discrete MultiTone) rozdělı́ celé pásmo na kanály přibližně po 4 kHz (celkem kolem 255
kanálů), kanály 7–32 pro upstream, od 33 pro downstream. Průběžně se sleduje kvalita přenosu
v jednotlivých kanálech, přenos se adaptivně rozkládá na ty kanály, které jsou považovány za
právě nejkvalitnějšı́. Narozdı́l od CAP se použı́vá vı́ce nosných kmitočtů (to jsou ty tóny v názvu,
také se nazývá Multicarrier Modulation). V současné době se setkáme spı́še s DMT.
Podrobnosti: http://access.feld.cvut.cz/view.php?cisloclanku=2004072903
Standardy pro zařı́zenı́ Ve všech standardech se rozlišuje varianta Annex A (over POTS – přes
analogové linky)), Annex B (over ISDN) a ADSL Lite. V současné době existujı́ tyto standardy:
• ADSL (původnı́) – Annex A a Annex B s propustnostı́ až 8 Mb/s (download), resp. 1 Mb/s
(upload), a dále ADSL Lite (ještě nižšı́ propustnost – do 1.5 Mb/s)
• ADSL2 – druhá generace, rychlost na downloadu až 12 Mb/s
• ADSL2+ – zvýšenı́ rychlosti až na 24 Mb/s (reálně až 16 Mb/s)
• ADSL2++ – opět zvýšenı́ rychlosti, teoreticky až 48 Mb/s
P
5.4
TECHNOLOGIE XDSL
103
Annex A u nás nelze provozovat, proto bychom si při koupi ADSL zařı́zenı́ měli dát pozor na to,
aby podporovalo Annex B.
ADSL Lite je odlehčená verze ADSL, kterou bylo možno použı́vat na méně kvalitnı́ch spojı́ch.
Instalace ADSL Lite byla poměrně jednoduchá, ale rychlost byla o něco nižšı́ než u klasické ADSL,
nepoužı́val se splitter (viz dále).
5.4.2
Implementace ADSL
V ADSL se použı́vajı́ tato zařı́zenı́:
• datová či hlasová koncová zařı́zenı́ (počı́tač, telefon, NAS, atd.), digitálnı́ a analogová
P
• modem (MODulator/DEModulator) – moduluje digitálnı́ signál na analogový (šı́řka přibližně
1,1 MHz) a zpětně demoduluje, připojujı́ se k němu datová koncová zařı́zenı́
• splitter – sloučenı́ hlasového přenosu a modulovaných dat (frekvenčnı́ multiplex), připojuje
se k němu modem a hlasová koncová zařı́zenı́ (analogová), na telefonnı́ linku posı́lá signál
v časovém multiplexu (TDM – time division multiplex), varianta ADSL Lite nepoužı́vá splitter
• DSLAM (DSL Access Multiplexer) – na straně ISP, sdružuje spojenı́ z ISP splitterů pro jednotlivá připojenı́
V praxi je u účastnických přı́pojek mohou být modem a splitter v jednom zařı́zenı́ (internı́, integrovaný), na straně ISP bývajı́ odděleny ve dvou zařı́zenı́ch.1 Je výhodnějšı́ mı́t splitter zvlášt’. Pokud
nepoužı́váme žádná analogová zařı́zenı́ (analogový telefon), měli bychom se splitteru zbavit, protože může být zdrojem mı́rných posunů signálu a tı́m i poruch.
Místní ústředna
počítač
modem
telefon
splitter
DSLAM
ISP
splitter
PSTN
Obrázek 5.4: Zařı́zenı́ v sı́ti ADSL
Externı́ splitter u účastnického modemu (tj. když ho máme zvlášt’) je malá krabička, do které
se připojujı́ 3 kabely, všechny s rozhranı́m RJ-11. Proto bychom měli dávat pozor, co kam máme
připojit (vstupy/výstupy jsou označeny):
• kabel z rozhranı́ označeného PHONE povede zjevně do analogového telefonu,
• kabel z rozhranı́ označeného MODEM povede do ADSL modemu (ADSL routeru),
• kabel z rozhranı́ označeného obvykle LINE zapojı́me přı́mo do telefonnı́ zásuvky.
Digitálnı́ telefony samozřejmě ke splitteru nepřipojujeme!
1
Modem a splitter v jednom zařı́zenı́ najdeme spı́še u levnějšı́ch řešenı́ pro SOHO (Small Office–Home Office), tj. pro
domácnosti a malé firmy.
$
5.4
TECHNOLOGIE XDSL
104
DTE
Ethernet
..
.
DTE
ADSL
modem
AD
SL
..
.
Wi-Fi
ADSL
modem
DSLAM
L
ADS
Obrázek 5.5: ADSL je technologie prvnı́ mı́le
Agregace = sdı́lenı́ přı́pojky ADSL. Každý ISP rozdělı́ kapacitu linky, kterou má k dispozici,
formou časového multiplexu. Vzorec pro agregačnı́ poměr je následujı́cı́:
P
rychlost(ISP )
agregačnı́ poměr = P
i rychlost(i)
Typické hodnoty agregace mohou být napřı́klad 1 : 50, 1 : 20.
FUP (Fair User Policy) je omezenı́ toku dat (většinou se odvozuje od množstvı́ přenášených dat).
V současné době nenı́ u ADSL FUP uplatňováno.
FUP v ADSL obvykle souvisı́ s protokolem PPPoA. Proto pokud zjistı́me, že FUP je na našı́
lince uplatňováno, měli bychom projı́t konfiguraci ADSL modemu a zjistit, jestli je možné nastavit
mı́sto PPPoA (PPP over ATM) protokol PPPoE (PPP over Ethernet). U staršı́ch ADSL modemů to
nejde, ale u novějšı́ch by to neměl být problém.
Obrázek 5.6: Zapouzdřenı́ do PPPoE
P
5.4
TECHNOLOGIE XDSL
ADSL modemy
105
– parametry, které nás mohou zajı́mat
1. standard ITU G.922.1, Annex B (tj. přı́loha B, kdežto modemy podle přı́lohy A by v ČR
nefungovaly)
$
2. ADSL2+ (to 2+ znamená, že modem dokáže dosáhnout vyššı́ch deklarovaných rychlostı́, na
downstreamu až 24 Mb/s))
3. skutečná rychlost (upstream, downstream), obvykle nebývá problém, pokud nejsme moc
daleko od DSLAMu
4. handshake (navázánı́ spojenı́ při zapnutı́, negociace s DSLAM) – většina přı́strojů se nedržı́
standardu, DSLAMy naštěstı́ odchylky většinou tolerujı́, ale ze specifikace většinou tento
parametr nevyčteme (měli bychom probrat recenze)
5. ADSL router – zároveň směrovač, dovoluje připojit vı́ce zařı́zenı́ (LAN)
6. vybavenost Wi-Fi – ADSL modem bývá kromě RJ-45 portů často vybaven rozhranı́m Wi-Fi,
výhodou je přı́tomnost tlačı́tka na vypnutı́ Wi-Fi (vyššı́ spotřeba proudu)
7. PPPoE, může být PPPoA nebo IPoA (určuje, do paketu kterého protokolu se datové pakety
zapouzdřujı́ při odchodu do WAN, ideálně do paketu PPPoE)
8. webové rozhranı́ – konfigurace (někteřı́ výrobci jsou notoricky známı́ svým nepřehledným
rozhranı́m), při prvnı́m zapnutı́ modemu bývá často dostupné jen přes RJ-45
9. diagnostické nástroje, podpora QoS, HW firewall, atd.
5.4.3
ADSL na straně ISP
DSLAM je brána do datové sı́tě poskytovatele. Existujı́ menšı́ DSLAMy pro připojenı́ 24 nebo
48 DSL linek (a obvykle stejný počet pro POTS – analogový telefon), a pak většı́ pro tisı́ce linek.
Obvykle podporuje protokoly PPPoE i PPPoA.
P
DSLAM má rozhranı́ RJ-11 směrem k zákaznı́kovi a pak dalšı́ rozhranı́ – většinou dvě RJ-45
pro Gigabit Ethernet nebo rychlejšı́, přı́padně rozhranı́ pro Fast Ethernet (LAN). Administrace se
provádı́ přes webové rozhranı́, a nebo fyzicky přes RJ-232 (COM, je dostupná redukce RJ-232 na
USB), atd.
Na obrázku 5.7 je zjednodušený nákres struktury sı́tě na straně poskytovatele Internetu. Pojmy
k tomuto obrázku:
• PTA je širokopásmový server, provádı́ se zde konfigurace IP adres, autentifikace uživatelů,
autorizace, účtovánı́ (RADIUS)
• AP (Access Point) je přı́stupový bod pro konkrétnı́ho ISP, přes který lze přistupovat z virtuálnı́
sı́tě tohoto ISP k směrovači na Internet
Úkoly
1. V některém internetovém obchodě prodávajı́cı́m sı́t’ové prvky (http://pc.itek.cz, http://www.intelek.cz,
http://www.czechcomputer.cz, atd. podle vlastnı́ho výběru, přı́padně použijte srovnávacı́ web
TECHNOLOGIE XDSL
Agregační
bod
DSLAM
ATM
PPPoA
..
.
q
PTA
..
.
GEth
PPPoE
..
.
q
PTA
směrovač
Agregační
bod
DSLAM
'$
106
VPN
MPLS
směrovač
Access
q
point
..
.
..
.
směrovač
q
VPN
Access
point
Internet
5.4
&%
směrovač
MPLS
směrovač
páteřní síť
Obrázek 5.7: ADSL – na straně ISP
jako napřı́klad http://www.heureka.cz) projděte nabı́dky různých typů modemů. Zjistěte, jaké
typy modemů se v nabı́dkách nacházejı́ (ADSL, GSM, analogový apod.), v jakém provedenı́
a přes které rozhranı́ se připojujı́ k počı́tači (často přes USB, RJ-45, ExpressCard), v jakých
cenových relacı́ch, jaký je funkčnı́ a cenový rozdı́l mezi samostatným modemem a Wi-fi
routerem s ADSL modulem.
2. Pokud máte přı́stup k některému ADSL modemu, projděte si jeho konfiguračnı́ rozhranı́.
5.4.4
Dalšı́ xDSL technologie
High bit-rate Digital Subscriber Line (HDSL) nenı́ určena pro účastnické přı́pojky, použı́vajı́ ji
ISP pro propojenı́ pobočkových ústředen, přı́padně ji mohou využı́t velké firmy pro své vnitřnı́
potřeby. Vyžaduje dva nebo tři páry telefonnı́ch vodičů, což je považováno za jednu z nevýhod.
Je to symetrická technologie (stejný rozsah pásem pro downstream a upstream), ale může
pracovat i asymetricky. Podporuje pouze přenos dat, neobsahuje podporu telefonnı́ch hovorů.
Pro oddělenı́ downstreamu a upstreamu použı́vá pouze Echo Cancellation (EC), ne frekvenčnı́
multiplex.
HDSL-2 (také SHDSL – SinglePair HDSL) je varianta HDSL, která použı́vá pouze jeden pár
telefonnı́ch vodičů, tedy při zaváděnı́ technologie HDSL-2 na samotném vedenı́ telefonnı́ch linek
nenı́ třeba nic měnit.
P
5.4
TECHNOLOGIE XDSL
107
Symetric Digital Subscriber Line (SDSL) je rozsahem funkcı́ podobná technologii ADSL, ale
je symetrická (stejný rozsah pásem – počet kanálů – pro upstream a downstream), neobsahuje
podporu telefonnı́ch hovorů (pouze pro data, nelze připojit analogový telefon). Princip přenosu je
podobný HDSL.
Použı́vá se pro účastnické přı́pojky, u kterých se preferuje symetričnost přenosu. Obvyklá
rychlost je až 2,3 Mb/s, dosah až 5 km.
IDSL (ISDN Digital Subscriber Line) je hybrid ISDN a xDSL technologiı́. IDSL je poskytována
tam, kde ještě nelze zprovoznit ADSL (v ústředně nenı́ funkčnı́ DSLAM), a nebo ISP. Využı́vá
rozhranı́ „U“ pro ISDN, přenášı́ pouze data, připojenı́ přes ISDN BRI. Narozdı́l od ISDN nenı́
vytáčená a je rychlejšı́ (pomalejšı́ než ADSL), použı́vá stejnou modulaci jako ISDN.
VDSL (Very High Bit-Rate Digital Subscriber Line) je považována za následnı́ka ADSL. Je
také asymetrická (může být nastavena na symetrický přenos), použı́vá širšı́ pásmo než ADSL
(protáhnutı́ na vyššı́ frekvence), a z toho důvodu je rychlejšı́. Rychlost na kvalitnı́ telefonnı́ UTP
dosahuje až 52 Mb/s (asymetrická, downstream) nebo 36 Mb/s (symetrická varianta). Teoreticky
až 200 Mb/s, reálně opravdu jen kolem 50 Mb/s.
P
P
Zatı́mco ADSL provádı́ přenos na vzdálenost až 5 km (při vyššı́ch rychlostech méně), VDSL
pouze něco přes 1 km, což je daň za rozšı́řenı́ pásma. Ovšem pokud chceme opravdu využı́t
vysoké rychlosti nabı́zené VDSL, tak bychom měli být maximálně 500 m od DSLAMu. Upstream
a downstream jsou odděleny frekvenčnı́m multiplexem podobně jako u ADSL.
Obrázek 5.8: Porovnánı́ frekvencı́ ADSL a VDSL2
Rozšı́řenı́ VDSL bohužel závisı́ na telekomunikačnı́ch organizacı́ch, tato technologie musı́ být
podporována v telekomunikačnı́ch ústřednách.
Dalšı́ informace o DSL technologiı́ch:
•
•
•
•
2
http://www.svetsiti.cz/view list.asp?rubrika=Tutorialy&temaID=166
http://access.feld.cvut.cz/view.php?cisloclanku=2004120302
http://www.earchiv.cz/i potsadsl.php3
http://access.feld.cvut.cz/search.php?rsvelikost=sab&rstext=all-phpRS-all&rstema=
14&stromhlmenu=14
Zdroj: http://access.feld.cvut.cz/view.php?cisloclanku=2004120302
5.5
TELEFONNÍ SÍTĚ A TELEFONNÍ ÚSTŘEDNY
108
Úkoly
V roce 2011 se v nabı́dkách telefonnı́ch operátorů konečně objevila technologie VDSL. Zjistěte, jaká
zařı́zenı́ podporujı́cı́ VDSL jsou momentálně k dispozici (nahlédněte do internetových obchodů)
a jaké jsou jejich parametry.
5.5
Telefonnı́ sı́tě a telefonnı́ ústředny
Nynı́ se podı́váme podrobněji na problematiku telefonnı́ch sı́tı́ a ústředen, předevšı́m pobočkových
telefonnı́ch ústředen (PBX).
5.5.1
Slučovánı́ linek
Předchůdcem sı́tě SDH, se kterou jsme se seznámili v kapitole o WAN sı́tı́ch, je sı́t’PDH (Pleisochronous Digital Hierarchy). Zatı́mco SDH je „synchronnı́ “ (komunikace je synchronizována v celé sı́ti,
s časovým multiplexem), PDH je „téměř synchronnı́ “ – pleisochronnı́, tedy komunikace je téměř
synchronizována (tolerujı́ se malé odlišnosti v rychlosti).
V PDH se začalo využı́vat slučovánı́ linek za účelem zvýšenı́ kapacity přenosu. Značenı́ a některé
dalšı́ prvky se odlišujı́ v normách platných pro Evropu od norem platných v Americe a Japonsku.
Zatı́mco v Americe a Japonsku se setkáme s T-linkami (T-carrier, normy podle ITU-T), v Evropě se
použı́vajı́ E-linky (E-carrier, normy podle CEPT – Evropské rady pro správu pošt a telekomunikacı́).
Princip vycházı́ ze sdružovánı́ linek do svazků, které majı́ logicky vyššı́ přenosovou kapacitu
a tı́m i rychlost přenosu. V obou normách jsou linky řádu 0 (nula) tvořeny jedinou linkou o rychlosti
64 kb/s. V řádu 1 se sdružuje bud’ 24 nebo 30 linek datových a 2 linky signálnı́ (nepřenášejı́ data,
ale řı́dicı́ signály), vzniká T1-linka (Amerika a Japonsko) nebo E1-linka (Evropa). Sdruženı́m čtyř
T1 linek vznikne T2 linka, podobně u E-linek. Postup a navyšovánı́ přenosové rychlosti najdeme
v tabulce 5.2.
Značenı́
Dat. kanálů
Přen. rychlost
Značenı́
Dat. kanálů
Přen. rychlost
T1
T2
T3
T4
24
96
672
4032
1,54 Mb/s
6,31 Mb/s
44,38 Mb/s
274,18 Mb/s
E1
E2
E3
E4
E5
30
120
480
1920
7680
2,05 Mb/s
8,45 Mb/s
34,37 Mb/s
139,27 Mb/s
565,15 Mb/s
P
Tabulka 5.2: Srovnánı́ T-carrier (Amerika, Japonsko) a E-carrier (Evropa) linek
Fyzicky bývajı́ sdružovány spoje na kroucených dvoulinkách (UTP), což početně souhlası́: 30 +
2 = 32, což je dělitelné čı́slem 4 (počtem drátů v UTP).
Rámec E1 se skládá z 32 timeslotů („oken“ o stejné délce – 125 µs), přenášených paralelně. Jeden
timeslot obsahuje prostor pro jeden oktet (8 bitů), od toho se odvı́jı́ přenosová kapacita.
5.5
TELEFONNÍ SÍTĚ A TELEFONNÍ ÚSTŘEDNY
SONET
SDH
STS-1
STS-3
STS-12
STS-48
STM-0
STM-1
STM-4
STM-16
Přen. rychlost
52 Mb/s
156 Mb/s
622 Mb/s
2 488 Mb/s
109
SONET
SDH
Přen. rychlost
STS-192
STS-768
STS-3072
STM-64
STM-256
STM-1024
9 953 Mb/s
39 813 Mb/s
159 252 Mb/s
Tabulka 5.3: Úrovně a rychlosti v sı́tı́ch SONET a SDH
SDH se od PDH lišı́ předevšı́m využitı́m optických kabelů (jednovidových) a dokonalejšı́ synchronizacı́, která se provádı́ přes celou sı́t’ pomocı́ atomových hodin. Velikost timeslotu je stejná
(125 µs), ale multiplexovánı́ funguje trochu jinak (protože už se neodvı́jı́ od UTP kabelu).
P
Slučovánı́ linek také známe z podkapitoly o ISDN – BRI rozhranı́ definuje slučovánı́ 2 datových
a jedné signálnı́ linky (uživatelská Euro-ISDN2), PRI slučuje 30 datových a jednu signálnı́ linku
(Euro-ISDN30), s tı́m, že datové kanály lze dále dělit do podskupin (např. část pro přenos dat
z počı́tačové LAN a část pro Fax).
5.5.2
Telefonnı́ ústředny
Již vı́me, že telefonnı́ ústředny jsou uspořádány hierarchicky – na nejvyššı́ch uzlech hierarchie
jsou TTO (tranzitnı́ telefonnı́ ústředny), nı́že jsou UTO (uzlové telefonnı́ ústředny), pod nimi MTO
(mı́stnı́ telefonnı́ ústředny), ke kterým se již připojujı́ účastnické přı́pojky a nebo v přı́padě většı́ch
firem pobočkové ústředny (PBX).
Pobočkové ústředny se použı́vajı́ k zajišt’ovánı́ vnitřnı́ch hovorů uvnitř firem a také ke spojovánı́ hovorů mezi vnitřnı́ a vnějšı́ telekomunikačnı́ sı́tı́. Jsou vlastně přı́pojným bodem do sı́tě
poskytovatele této služby (DTE).
Telefonnı́ ústředny dělı́me na analogové a digitálnı́, ale v současné době se většinou již setkáme
jen s digitálnı́mi. Analogové pobočkové ústředny lze připojit na běžné telefonnı́ linky PSTN sı́tě
(HTS – hlavnı́ telefonnı́ stanice, dřı́v se řı́kalo „státnı́ linka“, ale dnes už tyto linky státu nepatřı́),
digitálnı́ ústředny navı́c také na
•
•
•
•
P
P
běžná telefonnı́ sı́t’,
E1 u staršı́ch digitálnı́ch ústředen, BRI a PRI ISDN,
datovou sı́t’VoIP,
datovou bezdrátovou sı́t’(DECT bezdrátové pobočky rozmı́stěné po areálu), atd.
VoIP je ve své podstatě datovou službou, tedy nevyžaduje připojenı́ do telekomunikačnı́ sı́tě
(pokud máme jen čistě VoIP ústřednu), stačı́ připojenı́ do datové sı́tě. Tomuto typu služeb se
budeme věnovat v následujı́cı́ podkapitole.
Ústředna může být bud’ přı́mo hardwarové zařı́zenı́, a nebo software nainstalovaný na vhodně
připojeném počı́tači. Podı́váme se na několik softwarových řešenı́ (jedná se o serverové aplikace).
Kromě softwaru potřebujeme také hardware, kterým stanici s tı́mto softwarem připojı́me ke zvolenému rozhranı́ do sı́tě poskytovatele služby (telekomunikačnı́ho operátora).
J
5.6
VOIP
110
Asterisk je populárnı́ open-source software pro vytvářenı́ VoIP ústředen. Konfiguruje se přes
webové rozhranı́, existuje také několik GUI (nutno zvlášt’ doinstalovat, např. FreePBX), dále lze
k aplikaci přistupovat programově přes API z aplikacı́ napsaných v běžných programovacı́ch
jazycı́ch. Asterisk najdeme také v mnohých prodávaných hardwarových ústřednách.
Cisco Unified Communications Manager (dřı́ve Cisco CallManager) lze instalovat na zařı́zenı́ch,
která tento produkt podporujı́ (většinou na serverech Cisco). jedná se o komerčnı́ produkt s obecně
dobrou vybavenostı́ funkcemi.
Microsoft Response Point je systém s jednoduchou konfiguracı́ pro menšı́ telefonnı́ sı́tě (do 50
stanic, spı́še méně, záležı́ na konkrétnı́m hardwaru). Běžı́ pouze na systémech Windows od verze
XP. Tento produkt však už oficiálně nenı́ podporován.
Dalšı́ informace:
•
•
•
•
•
•
•
•
http://www.asterisk.org/
http://www.asteriskguru.com/tutorials/
http://www.abclinuxu.cz/serialy/asterisk-voip-ustredna
http://www.root.cz/serialy/pobockova-voip-ustredna-asterisk/
http://www.freepbx.org/
http://www.cisco.com/en/US/products/sw/voicesw/ps556/index.html
http://www.microsoft.com/responsepoint/
http://www.ustredny.cz/
Úkoly
Vyberte si některé z výše uvedených řešenı́ pro ústředny a o zjistěte o něm podrobnějšı́ informace.
5.6
5.6.1
VoIP
Princip
VoIP (Voice over IP, „internetová telefonie“, IP telefonie) je technologie pro přenos digitalizovaného
hlasu v IP datagramech. Hovor může být veden i mezi vı́ce než dvěma účastnı́ky.
Striktně vztato, existujı́ dva typy internetové telefonie – ATM telefonie, která už vymı́rá, a IP
telefonie, která je naopak na vzestupu (svého času se také hodně mluvilo o využitı́ ISDN). Každý
z těchto typů má své výhody a nevýhody, které vesměs vyplývajı́ z principu přenosu (ATM má
garanci služeb, IP je zase snadno přı́stupný a pružný systém).
Koncová zařı́zenı́ mohou být bud’ hardwarové VoIP telefony a nebo jde o software, VoIP aplikaci.
Telefonovat můžeme
• v rámci sı́tě poskytovatele,
• mimo sı́t’poskytovatele, ale pořád v rámci datové sı́tě,
• na běžné telefonnı́ čı́slo do veřejné telekomunikačnı́ sı́tě.
P
5.6
VOIP
111
Třetı́ možnost vyžaduje vytvořenı́ spojenı́ přes VoIP bránu, která tvořı́ rozhranı́ mezi datovou
a veřejnou telekomunikačnı́ sı́tı́. Volı́ se VoIP brána co nejblı́ž cı́li, aby co nejdelšı́ část spojenı́ vedla
po datových linkách (resp. aby část spojenı́ po telekomunikačnı́ch linkách byla pokud možno
„mı́stnı́ hovor“).
P
V současné době se setkáváme s komplexně řešenými pobočkovými ústřednami pro firmy, které
si takto mohou zařı́dit vlastnı́ VoIP sı́t’. Jejich konkurencı́ jsou však nabı́dky mobilnı́ch operátorů,
které jsou, zvláště pro většı́ firmy, velmi výhodné.
Obvykle se vyžaduje splněnı́ těchto požadavků:
•
•
•
•
rychlost připojenı́ k Internetu přes 128 kb/s
maximálnı́ zpožděnı́ na spoji k serveru poskytovatele 150 ms
maximálnı́ kolı́sánı́ zpožděnı́ 30 ms
ztrátovost datových jednotek pod 2 %, lépe kolem 1 %
Dále si může poskytovatel stanovit požadavky na způsob implementace NAT apod. Tyto požadavky jsou však relativnı́, záležı́ na celkovém vytı́ženı́ spoje (proto je důležité použı́vat QoS)
a obvyklém počtu hovorů na spoji vedených. VoIP vyžaduje sice menšı́ šı́řku pásma než datové
služby, ale zato pokud možno konstantnı́.
Některé typy připojenı́ k Internetu nejsou pro VoIP moc vhodné (napřı́klad některá mobilnı́
připojenı́, jako je GSM, GPRS či EDGE), u Wi-Fi je využitı́ diskutabilnı́ (zvláště tehdy, když je oblast
přı́liš zarušená, může ztrátovost datových jednotek dosáhnout přı́liš velké hodnoty).
Nejdřı́v je nutné navázat spojenı́. Navazovánı́ spojenı́ provádı́ přı́slušný aplikačnı́ protokol, a to
bud’ SIP nebo H.323.
Po navázánı́ spojenı́ se přenášený zvuk nejdřı́v digitalizuje – provádı́ se vzorkovánı́ na 8 kHz.
Přenos se provádı́ pomocı́ kodeku (coder/decoder), který provádı́ kódovánı́ signálu a zároveň jeho
kompresi.
$
VoIP je implementován i v různých aplikacı́ch, napřı́klad v notoricky známé aplikaci Skype.
5.6.2
Protokoly
SIP (Session Initiation Protocol) je textově orientovaný protokol vyvinutý přı́mo pro použitı́ na
Internetu (IETF), v roce 1999. Je to protokol aplikačnı́ vrstvy pro vytvářenı́, udržovánı́ a ukončovánı́
interaktivnı́ch relacı́, kromě jiného VoIP. Sám o sobě nezajišt’uje QoS, ale dokáže spolupracovat
s protokoly, které jsou k tomu určeny.
Jeho úkoly:
• lokalizuje přı́jemce volánı́,
• ověřı́ vlastnosti použitého zařı́zenı́,
• zajistı́ přenos dat a zabezpečenı́ u jiných protokolů.
SIP je distribuovaný, co nejvı́c posouvá inteligenci přenosu ke koncovým zařı́zenı́m.
Dalšı́ významnou vlastnostı́ SIP je pružnost. Dokáže spolupracovat s mnoha protokoly a kromě
VoIP je použitelný napřı́klad i pro Instant Messaging a dokáže dobře spolupracovat s mobilnı́mi
technologiemi. Lze použı́vat jak čı́selné adresy (telefonnı́ čı́sla), tak i URI (Universal Resource
Identifier) – webovou adresaci.
P
5.6
VOIP
112
Na transportnı́ vrstvě je využı́ván předevšı́m protokol UDP, což znamená vyššı́ rychlost přenosu
(menšı́ zpožděnı́).
Řı́zenı́ spojenı́
Řı́zenı́
A/V
Audio/video
aplikace
G.7xx
SIP
SDP
H.26x
RTCP
RTP/SRTP
TCP, UDP
IP
Obrázek 5.9: Protocol stack protokolu SIP
H.323 je sada binárnı́ch protokolů pro konverzi signalizace paketového protokolu na signalizaci
telefonnı́ sı́tě. Je staršı́ než SIP (rok 1996) a vycházı́ ze signalizace obvyklé v telekomunikačnı́ch
sı́tı́ch. Jde o komplexnějšı́ přı́stup, H.323 řešı́ kromě navazovánı́ a udržovánı́ spojenı́ také QoS
a dalšı́ charakteristiky přenosu. Při adresovánı́ použı́vá telefonnı́ čı́sla.
P
H.323 má většı́ zpožděnı́ při navazovánı́ spojenı́ a navı́c jeho spolupráce s jinými protokoly je
problematická. Jedná se o protokol do značné mı́ry centralizovaný.
Na transportnı́ vrstvě je využı́ván předevšı́m protokol TCP, který má většı́ režii přenosu, to
znamená většı́ zpožd’ovánı́ přenosu.
Řı́zenı́ spojenı́
H.255
H.245
Data
T.120,
V.150,
T.38
Řı́zenı́
audia/videa
RTCP
RAS,
RSVP
Audio/video
aplikace
G.7xx
H.26x
RTP/SRTP
TCP, UDP
IP
Obrázek 5.10: Protocol stack protokolu H.323
Podpůrné protokoly transportnı́ vrstvy:
• RTP (Real-time Transport Protocol) doplňuje činnost protokolu UDP v oblasti rychlé paketizace datového toku v reálném čase, synchronizuje přenos a umožňuje zjistit ztracený paket
nebo nesprávné pořadı́ paketů.
• SRTP (Secure RTP) je bezpečnějšı́ varianta protokolu RTP.
5.6
VOIP
113
• RTCP (Real-time Transport Control Protocol) zprostředkovává zpětnou vazbu pro protokol
RTP, umožňuje využı́vat jeho výše popsané vlastnosti. Využitı́m RTCP lze regulovat datový
tok, napřı́klad dynamicky měnit rychlost přenosu podle požadavků přijı́majı́cı́ho uzlu.
• SDP (Session Description Protocol) se použı́vá u protokolu SIP pro vyjednánı́ parametrů
multimediálnı́ komunikace.
• RSVP (Resource Reservation Protocol) sloužı́ pro rezervaci zdrojů spoje, je to prostředek
řı́zenı́ QoS.
• G.711, G.729, g.723.1, atd. – audio kodeky, nad nimi běžı́ audio aplikace.
• H.261, H.263, atd. – video kodeky, nad nimi běžı́ video aplikace.
• T.120 – konferenčnı́ datové přenosy.
• RAS (Registration, Admission, Status) – podpůrný protokol pro vyjednánı́ a udrženı́ spojenı́
při použitı́ H.323. Je součástı́ protokolu H.255.0 sloužı́cı́ho k administraci multimediálnı́
komunikace.
Z dalšı́ch protokolů se využı́vá napřı́klad STUN nebo TURN pro podporu NAT, SCCP u zařı́zenı́
Cisco, IAX v systému Asterisk, a dalšı́.
5.6.3
Videotelefonie a videokonference
Videotelefonie je vzájemný hovor dvou či vı́ce účastnı́ků se současným sledovánı́m synchronizovaného videostreamu (obvykle se snı́má obraz videokamery). Dnes obvykle nejde ani tak o samostatná zařı́zenı́ (videotelefony), setkáváme se hlavně se softwarovou implementacı́ (napřı́klad výše
zmı́něný Skype nebo FaceTime od Applu, obojı́ na principu VoIP). Funkce videotelefonie je také
obvykle implementována v softwaru pro pobočkové ústředny (např. ve výše zmı́něném Asterisku).
Videotelefonie stojı́ předevšı́m na protokolu H.264. Tento protokol standardizovaný ITU-T je
vlastně notoricky známým videokodekem pro kompresi videa, mnohým bude hodně řı́kat zkratka
MPEG-4. Použı́vá se všude tam, kde je potřeba přenášet komprimované digitálnı́ video.
Zatı́mco videotelefonie vyžaduje vytvořenı́ spoje typu point-to-point, videokonference je již náročnějšı́ způsob komunikace. Jde vlastně o spoje typu multipoint-to-multipoint, signál je šı́řen formou
multicastu. Videotelefonii můžeme považovat za speciálnı́ jednoduššı́ přı́pad videokonferencı́.
Z aplikacı́ pro videokonference můžeme vybrat napřı́klad:
MBone je distribuovaný systém složený z volně dostupných nástrojů. Vyžaduje vhodně multimediálně vybavený počı́tač připojený do sı́tě, funguje nad protokolem IP. Podporuje široké spektrum
operačnı́ch systémů od Windows po různé unixové systémy. Umožňuje organizovat videokonference, přihlásit se do existujı́cı́ videokonference, přenášet zvuk a obraz, sdı́let text i multimédia
(whiteboard – sdı́lená bı́lá tabule s obrázkem).
VRVS (Virtual Room Videoconferencing System) je komplexnı́ systém poskytovaný zdarma ve
formě služby. Je třeba mı́t instalovánu podporu bud’ MBone nebo H.323. K provozovánı́ VRVS
potřebujeme počı́tač se systémem Solaris nebo Linux (omezenı́ neplatı́ pro klientské stanice, tam je
důležitá verze Java Virtual Machine). VRVS je velmi dobře zdokumentován. V poslednı́ době má
VRVS problém s dostupnostı́.
P
P
J
5.6
VOIP
114
NetMeeting (v novějšı́ch verzı́ch Windows Meeting Space) je jednoduchý videokonferenčnı́ systém pro Windows založený na protokolu H.323. Původně byl navržen pro point-to-point spoje, ale
dnes již funguje i na vı́cebodobých spojı́ch, třebaže někdy s problémy. Jeho výhodou je dostupnost
ve všech dnes dostupných verzı́ch Windows, nevýhodou problémy s kompatibilitou s některými
jinými videokonferenčnı́mi řešenı́mi.
Ekiga (GnomeMeeting) je svobodný software pro VoIP a videokonference vyvı́jený v rámci
projektu Gnome. Komunikuje i s jinými klienty podporujı́cı́mi protokol SIP nebo H.323 (včetně MS
NetMeeting). Klient je dostupný pro Linux i Windows.
Dalšı́ informace:
•
•
•
•
http://www.vutbr.cz/www base/zav prace soubor verejne.php?file id=27320
http://www.cesnet.cz/videokonference/mbone/prirucka/mbone.pdf
http://oirt.rutgers.edu/cmn/video desktop/vrvs.html
http://www.ekiga.org/
Kapitola
6
Bezdrátové a mobilnı́ sı́tě
V této kapitole se budeme věnovat bezdrátovým způsobům přenosu – nejdřı́v technologiı́m postaveným
předevšı́m na IEEE 802.11 a následně rozlehlým mobilnı́m sı́tı́m. Poslednı́ sekce v této kapitole je věnována
satelitnı́ komunikaci.
6.1
Bezdrátové technologie
Bezdrátové technologie jsou technologie vedenı́ signálu „vzduchem“, bez podpory metalického
nebo optického kabelu. Rozlišujeme tyto bezdrátové technologie:
• rádiová – rádiové vlny o určité frekvenci (Wi-Fi, WiMAX)
• sonická – ultrazvuk, verbálnı́ komunikace
• optická – laser, IR (infračervené zářenı́), ostatnı́ (mávánı́ vlajkou, blikánı́, posunková řeč
apod.)
Pod pojmem WLAN (Wireless LAN) budeme rozumět lokálnı́ bezdrátovou sı́t’. Většinou se takto
označuje Wi-Fi sı́t’.
Bezdrátové sı́tě dělı́me na
• fixnı́ – sice bezdrátové, ale při pohybu připojeného zařı́zenı́ se bud’ silně zhoršuje signál nebo
se dokonce odpojı́,
P
P
P
• mobilnı́ – připojené zařı́zenı́ se může volně pohybovat, i vyššı́ rychlostı́.
Mobilnı́ sı́tě majı́ složitějšı́ implementaci předevšı́m na úrovni sı́t’ové vrstvy.
Mezi různými typy bezdrátových sı́tı́ samozřejmě existujı́ i dalšı́ rozdı́ly – mohou být úzkopásmové (narrowband) nebo širokopásmové (broadband), majı́ odlišný dosah, rychlost, náchylnost na
rušenı́, zajištěnı́ bezpečnosti. Uvažuje se také o uplatněnı́ technologie UWB (UltraWide Band), tedy
rozloženı́ signálu do velmi širokého spektra. Důsledkem je vysoká odolnost proti rušenı́ a velmi
nesnadné odposlouchánı́ komunikace.
Obecně platı́, že sı́tě s velmi malým dosahem (napřı́klad BlueTooth) nevyžadujı́ tak vysokou
úroveň zabezpečenı́. To se ale může změnit, protože napřı́klad BlueTooth v nejnovějšı́ specifikaci
115
P
6.2
WI-FI
116
zvyšuje nejen rychlost, ale i dosah, a to formou navázánı́ na technologii Wi-Fi (využı́vá přı́tomnosti
Wi-Fi čipu v zařı́zenı́).
Jednou z nejnovějšı́ch technologiı́ využı́vajı́cı́ch rádiové vlny na vysokých frekvencı́ch je NFC
(Near Field Communication). Jedná se o technologii určenou předevšı́m pro malá mobilnı́ zařı́zenı́
pro účely bezdotykových přenosů informacı́, plateb, použı́vánı́ čistě elektronických vstupenek
apod., účinná vzdálenost je maximálně 20 cm. Malá vzdálenost je jednı́m ze zabezpečovacı́ch
faktorů této technologie (čı́m většı́ vzdálenost, tı́m pravděpodobnějšı́ je zneužitı́).
6.2
6.2.1
P
Wi-Fi
Základnı́ princip
Wi-Fi použı́vá rádiový signál v bezlicenčnı́m pásmu 2,4 GHz nebo 5 GHz. Komunikačnı́m médiem
nejsou kabely, ale vzduch. Wi-Fi sı́tě řadı́me mezi sı́tě s menšı́m dosahem (lokálnı́).
Pásmo 2,4 GHz je v dalšı́ch standardech (mikrovlnné trouby, BlueTooth, mobilnı́ telefony apod.),
proto mohou nastat problémy, rušenı́.
Použı́vá se koliznı́ metoda CSMA/CA (Carrier Sense Medium Access, Collision Avoidance,
definována v protokolu na MAC):
P
P
• CS – Carrier Sense (naslouchá na médiu)
• MA – Multiple Access (na médium přistupuje vı́ce stanic)
• CA – with Collision Avoidance (když chce stanice vysı́lat a naslouchánı́m zjistı́, že nikdo jiný
nevysı́lá, informuje ostatnı́ uzly o úmyslu vysı́lat)
Vysı́lá se v polovičnı́m (half) duplexu, z principu nenı́ možné plně duplexnı́ vysı́lánı́ (médiem je
vzduch, tedy bezdrátová sı́t’ová karta dokáže vždy jen přijı́mat nebo vysı́lat, nikoliv obojı́).
Wi-Fi je standardizována jako IEEE 802.11. Tı́mto standardem se také zabývá průmyslové
sdruženı́ Wi-Fi Alliance.
Jsou dvě možnosti jak řešit Wi-Fi sı́t’:
• ad-hoc řešenı́: každá komunikujı́cı́ stanice je vybavena Wi-Fi sı́t’ovou kartou, komunikujı́ spolu
přı́mo bez mezilehlých prvků (pro sı́tě o pár počı́tačı́ch),
• infrastruktura: existuje přı́stupový bod (AC – Access Point), přes který jde veškerá komunikace
(point-to-multipoint), žádné dvě stanice spolu nekomunikujı́ přı́mo.
Každý přı́stupový bod pokrývá signálem základnı́ oblast služeb (BSA – Basic Service Area), také se
nazývá buňka. V buňce se nacházejı́ připojené koncové body, stanice. Překrývánı́ buněk může být
P
P
• částečné – umožňuje plynulý přechod z jedné do druhé (roaming)
• (téměř) úplné – možnost sdı́let zátěž mezi spolupracujı́cı́mi AP (collocated – vázané)
Vı́ce použitých přı́stupových bodů znamená vı́ce buněk, mohou být propojeny pomocı́ distribučnı́ho systému (DS – Distribution system), oblast pokrytá signálem je rozšı́řená oblast služeb (ESA –
Extended Service Area). Propojenı́ funguje obvykle na linkové vrstvě (i když to nenı́ ve standardu
P
6.2
WI-FI
117
Obrázek 6.1: Schéma bezdrátové sı́tě
předepsáno), kromě jiného proto, že poskytuje možnost šı́řenı́ broadcastu. Schéma najdeme na
obrázku 6.1.
Distribučnı́ systém (zde WDS, Wireless Distribution System) tedy funguje jako páteřnı́ sı́t’propojujı́cı́ přı́stupové body. Obecně lze použı́t distribučnı́ systém nejen pro propojenı́ (bezdrátových)
přı́stupových bodů, ale také třeba pro propojenı́ dvou metalických lokálnı́ch sı́tı́. Nejjednoduššı́
distribučnı́ systém lze vytvořit tak, že přı́stupový bod jedné BSA pracuje jako běžná stanice v BSA
druhého přı́stupového bodu (opakovač), ale ne každý přı́stupový bod podporuje režim opakovače.
Základnı́ služby poskytované Wi-Fi přı́stupovým bodem jsou
• autentizace – AP zjišt’uje informace o stanici a rozhoduje, zda jı́ dovolı́ přı́stup do sı́tě
• asociace (přidruženı́) – vzniká vazba mezi AP a stanicı́, stanice je asociována k buňce AP
• de-asociace – zrušenı́ této vazby
Pro přihlášenı́ k sı́ti je nutné znát jejı́ identifikačnı́ kód – SSID (Service Set IDentifier), řetězec dlouhý
0–32 oktetů. Standardně přı́stupový bod vysı́lá své SSID v rámcı́ch beacon v intervalech několika
sekund, a to v otevřené formě, v takovém přı́padě nenı́ problém SSID zjistit. Pokud přı́stupový
bod nevysı́lá SSID v beacon rámcı́ch, lze je odposlechnout i v jiných typech rámců (napřı́klad
při přidružovánı́ jiné stanice), nebo stačı́ poslat falešný požadavek na odpojenı́ některé (řádně
připojené) stanice, která se pak pokusı́ znovu připojit (nenı́ třeba dlouho čekat na komunikaci
obsahujı́cı́ SSID).
SSID lze také použı́t k jednoduché implementaci virtuálnı́ sı́tě (VLAN), kdy jsou SSID použı́vaná
jednotlivými uživateli mapována na VLAN, na třetı́ vrstvě se pak použı́vajı́ přı́stupová oprávněnı́
(ACL seznamy).
BSSID (Basic Service Set ID) je identifikátor fungujı́cı́ v rámci jedné BSA (tj. u daného přı́stupového bodu), je dlouhý 6 oktetů, obvykle se jedná o MAC přı́stupového bodu (u ad-hoc sı́tě to je
náhodný řetězec).
P
P
6.2
WI-FI
118
ESSID (Extended SSID) je totéž co SSID, zkratka se použı́vá v ESA (přı́padně může být stejný
jako BSSID).
Podle IEEE 802.11 je implementována fyzická vrstva a MAC podvrstva. Nad MAC se použı́vajı́
běžné LLC rámce (IEEE 802.2).
6.2.2
P
Režimy
Režimy, ve kterých může wi-fi zařı́zenı́ pracovat:
Gateway (brána) – zařı́zenı́ je připojeno k Internetu, funguje jako NAT server, zvenčı́ je viditelná
pouze jediná IP adresa (tj. odděluje vnitřnı́ LAN a vnějšı́ sı́t’ WAN). IP adresa tohoto zařı́zenı́
sloužı́ jako adresa brány pro celou LAN, která je k bráně připojena, pokud nám ovšem situaci
nekomplikujı́ soukromé IP adresy.
Routery obvykle plnı́ i funkci brány.
Router (směrovač, zde přesněji Wi-fi router) – zařı́zenı́, které vidı́ na sı́t’ovou vrstvu, použı́vá
IP adresy a dokáže podle IP adres směrovat. Obvykle na něm běžı́ NAT, firewall a DHCP server,
přı́padně může také plnit funkci brány do Internetu (což taky hodně souvisı́ s funkcı́ NAT). Na Wi-fi
směrovači běžı́ i AP (viz dále), takže celkově můžeme hovořit o zařı́zenı́, které v sobě kombinuje
funkci AP a směrovače.
AP (Access Point, přı́stupový bod) – toto zařı́zenı́ je připojeno k routeru (který přı́padně funguje
jako brána), a pokud opravdu běžı́ v AP módu, tak na něm nenı́ aktivnı́ NAT, firewall a často ani
DHCP server (ale nenı́ to vyloučeno, hlavně na něm neběžı́ NAT), funguje vpodstatě jako bridge,
pracuje pouze na druhé vrstvě ISO/OSI (nezná IP adresy, tedy NAT nemůže logicky fungovat).
P
P
P
AP můžeme brát jako ethernetový přepı́nač, který má jeden (!!!) port určen pro Wi-fi, nerozlišuje různé Wi-fi komunikace. Obvykle má svou vlastnı́ IP adresu, ale ta sloužı́ pouze k přı́stupu
do webového rozhranı́ k administraci (tedy může „vidět“ na sı́t’ovou vrstvu, ale jen pro účely
administrace, napřı́klad nastavenı́ šifrovánı́ Wi-fi).
Obě zařı́zenı́ (AP a router) musı́ mı́t nastaveno stejné ESSID, protože jsou ve stejné Wi-fi sı́ti.
AP klient – připojuje se k jinému AP, dalšı́ zařı́zenı́ jsou k AP klientovi připojena obvykle kabelem,
sloužı́ k distribuci signálu jiného AP (dva AP standardně nelze propojit, pouze AP plus AP klient).
U některých Wi-fi zařı́zenı́ se můžeme setkat s označenı́m režimu „Station“, taky se jedná o režim
AP klienta.
Stanice (počı́tače, notebooky, tiskárny s rozhranı́m Wi-fi, atd.), resp. jejich sı́t’ové karty, běžı́
v režimu AP klient (Station).
Repeater (opakovač) – zařı́zenı́ sloužı́ k přeposı́lánı́ signálu, jedná se o pasivnı́ režim (na fyzické
vrstvě, nezná ani MAC adresy) umožňujı́cı́ stanicı́m připojit se (zprostředkovaně) k některému AP
nebo bráně, které by byly jinak přı́liš vzdáleny, signál by byl slabý. Hlavnı́m účelem je tedy přı́chozı́
signál zesı́lit, přı́padně redukovat šum, a poslat dál.
Repeater pracuje na fyzické vrstvě, pouze pasivně přeposı́lá signál (s přı́padným zvýšenı́m jeho
kvality) bez jakéhokoliv směrovánı́, přepı́nánı́, apod.
P
P
6.2
WI-FI
119
WDS (Wireless Distribution System, distribučnı́ systém) – použı́vá se tehdy, když máme vı́ce
routerů, potřebujeme distribuovat propojenı́ „ven“ bezdrátově (tj. pouze na jednom bude využı́ván
port do WAN sı́tě) a navı́c se chceme mezi nimi plynule přehlašovat. Tyto routery tvořı́ jediný
distribučnı́ systém a z pohledu koncového zařı́zenı́ to vypadá, jako by byl připojen pořád k témuž
routeru. WDS pracuje na prvnı́ nebo druhé vrstvě ISO/OSI, podle toho, jestli potřebujeme navı́c
funkcionalitu mostu nebo zda stačı́ funkcionalita opakovače.
P
Problém je, že zajišt’ovánı́ funkcionality režimu WDS je výpočetně hodně náročné a navı́c je
propustnost nižšı́ z důvodu práce routerů na stejném kmitočtu (rušenı́, apod.), tedy sı́t’ je ve
srovnánı́ s propojenı́m routerů dráty výrazně pomalejšı́ (až o polovinu).
Režim WDS nenı́ standardizován, tedy nemáme zaručeno, že to bude fungovat při propojenı́
dvou routerů nastavených do režimu WDS. Pokud opravdu chceme WDS použı́t, pak bychom měli
nakoupit tato zařı́zenı́ do téhož výrobce (nebo alespoň sice od jiných výrobců, ale s wi-fi chipsetem
od stejného výrobce, třeba Broadcom). Dalšı́ nevýhodou je, že WDS obvykle nedokáže pracovat
s dynamickými klı́či, a tedy pro zabezpečenı́ komunikace lze obvykle jen WEP, což je velmi špatné.
Proto WDS je potřeba komunikaci zabezpečit i jiným způsobem.
WISP – zařı́zenı́ se připojı́ v roli AP klienta k AP (tedy bezdrátová komunikace bude zastupovat
WAN port) a zároveň směruje na LAN a WAN porty (tj. k LAN a WAN portům se chová jako
switch na 2. vrstvě ISO/OSI).
P
WISP mód využijeme napřı́klad tehdy, když máme dosažitelného poskytovatele Wi-fi připojenı́
(tj. přes bezdrát se budeme dostávat na Internet) a přes kabel budeme připojovat dalšı́ zařı́zenı́
(typicky stanice).
6.2.3
Fyzická vrstva v ISO/OSI, frekvenčnı́ spektrum
Pro fyzickou vrstu existuje v rodině IEEE 802.11 několik základnı́ch standardů:
•
•
•
•
•
IEEE 802.11b – frekvence 2,4 GHz, rychlost až 11 Mb/s
IEEE 802.11a – frekvence 5 GHz, rychlost až 54 Mb/s
IEEE 802.11g – frekvence 2,4 GHz, rychlost až 54 Mb/s
IEEE 802.11n – frekvence 2,4 nebo 5 GHz, rychlost až 600 Mb/s (spı́še značně nižšı́), OFDM+MIMO
IEEE 802.11ac – frekvence 5 GHz, s jednou anténou (jeden stream) rychlost až 433 Mb/s,
8 antén až 3,47 Gb/s, OFDM+(Mu-)MIMO
Všechny tyto standardy předepisujı́ využitı́ frekvencı́ v nelicencovaném pásmu (tzn. nepotřebujeme
licenci pro naše zařı́zenı́). Uvedené rychlosti je třeba brát s rezervou, reálně to může být méně než
polovina. V současné době je nejpoužı́vanějšı́ IEEE 802.11g, ale nabı́dka IEEE 802.11n je stále
širšı́. Varianta IEEE 802.11n sice podporuje obě frekvenčnı́ pásma, ale v současné době najdeme
většinou (nikoliv výhradně) zařı́zenı́ podporujı́cı́ pouze pásmo 2,4 GHz. Některá zařı́zenı́ dokážou
pracovat na obou frekvencı́ch současně (dvoupásmový router), což znamená zvýšenı́ propustnosti
(za předpokladu, že v dosahu jsou zařı́zenı́ z jednoho i druhého spektra).
Existujı́ zařı́zenı́ IEEE 802.11n Lite, která implementujı́ jen omezeně původnı́ „n“ standard
(typicky pouze jediná anténa), důsledkem je nižšı́ rychlost oproti plné implementaci.
P
6.2
WI-FI
120
Standardů (technicky vzato annexů – přı́loh standardu IEEE 802.11) existuje samozřejmě výrazně vı́ce, vlastně je už zabraná celá abeceda a jsou použity i některé dvoupı́smenné zkratky (třeba
ac). Napřı́klad později se setkáme s IEEE 802.11i, který se týká zabezpečenı́ bezdrátové komunikace (WPA2), 802.11p zajišt’ujı́cı́ funkčnost bezdrátového připojenı́ mezi pozemnı́ stanicı́ a rychle
se pohybujı́cı́m prvkem (třeba automobilem nebo vlakem), 802.11e pro QoS, atd.
MIX Mode. Standardy 802.11b, g, n jsou zpětně kompatibilnı́ – ale co to znamená ve skutečnosti?
Předpokládejme, že máme Wi-fi access point (AP) běžı́cı́ podle standardu 802.11g. Pokud jsou
v této sı́ti pouze zařı́zenı́ zvládajı́cı́ standard 802.11g, všechna budou komunikovat podle tohoto
standardu s teoretickou rychlostı́ až 54 Mb/s. Ovšem pokud se do sı́tě dostane byt’jediné zařı́zenı́
zvládajı́cı́ pouze standard 802.11b (tedy pomalejšı́), všechna zařı́zenı́ v sı́ti budou reagovat jednı́m
z těchto způsobů:
P
1. ukončı́ spojenı́
2. zůstanou připojena, ale budou komunikovat podle 802.11b (tj. max. teoretickou rychlostı́
11 Mb/s).
Druhá možnost bude použita u těch zařı́zenı́, která majı́ zapnut tzv. MIX Mode (což znamená
možnost pracovat podle všech těchto kompatibilnı́ch standardů). Podobná situace nastane i v přı́padě, kdy se do sı́tě fungujı́cı́ podle IEEE 802.11n dostane zařı́zenı́ 802.11g (rychlost klesne na max.
54 Mb/s) nebo 802.11b (rychlost klesne na max. 11 Mb/s).
Z toho vyplývá, že pokud nám v bezdrátové sı́ti zdánlivě bezdůvodně klesne propustnost,
důvodem může být i to, že se do sı́tě dostalo „staršı́“ zařı́zenı́.
IEEE 802.11n navyšuje přenosovou rychlost oproti 802.11g několika způsoby. Předně tato zařı́zenı́ mohou pracovat v obou pásmech, dalšı́ho zvýšenı́ rychlosti se dociluje změnou modulace –
použı́vá se modulace typu OFDM, konkrétně až 64-QAM. Použı́vajı́ se kanály o šı́řce obvykle 40
MHz. Propustnost navyšuje i možnost využitı́ vı́ce antén, přičemž signál je kompletován využitı́m
technologie MIMO (viz dále).
Zařı́zenı́, u něhož vidı́me označenı́ IEEE 802.11n Lite, použı́vá pouze jednu anténu.
IEEE 802.11ac je momentálně nejnovějšı́ standard (také 5G Wi-fi nebo Wi-fi páté generace).
Pracuje pouze ve frekvenčnı́m pásmu kolem 5 GHz.
Použı́vá efektivnějšı́ modulaci než 802.11n (až 256-QAM) – konkrétně základnı́ modulace je
OFDM, subnosné pak QAM. V jednotlivých generacı́ch se tento parametr měnil následovně:
• 802.11g: 16-QAM (jeden symbol = 4 bity, 24 = 16 možnostı́ pro hodnotu symbolu),
• 802.11n: 64-QAM (jeden symbol = 8 bitů),
• 802.11ac: 256-QAM (16 bitů)
Důsledkem bylo postupné zvyšovánı́ efektivity přenosu (vı́c přenesených dat za jednotku času).
802.11ac podporuje až 8 antén s MIMO, resp. MU-MIMO (MultiUser-MIMO, může paralelně
komunikovat s vı́ce zařı́zenı́mi). Typická šı́řka kanálu je bud’ 80 MHz nebo 160 MHz. Skutečná
propustnost záležı́ na vı́ce faktorech (šı́řka kanálu, počet antén, apod.), typická rychlost je kolem
1 Gb/s.
L
P
P
6.2
WI-FI
121
5GHz pásmo má špatnou pověst co se týče prostupnosti stěn (tak to bylo v IEEE 802.11a), ale
kupodivu u IEEE 802.11ac se s tı́mto problémem nesetkáváme zdaleka v tak velké mı́ře – je to dı́ky
algoritmu Beamforming, který při využitı́ vı́ce antén „zpožd’uje“ signál některých antén tak, aby po
procházenı́ překážkami dospěl ze všech antén za překážku ve zhruba stejnou dobu, a tedy se dá
zkompletovat (narozdı́l od přı́padu, kdy by signály různých antén prošly překážkou – s různými
úhly a odrazy – v odlišnou dobu, a tedy by se dokonce vzájemně rušily).
Existuje také standard IEEE 802.11ad (také se nazývá WiGig – od Wireless Gigabit Alliance),
který má podobné vlastnosti včetně propustnosti jako IEEE 802.11ac, s určitými rozdı́ly. Předně
vysı́lá v pásmu 60 GHz (přesněji v rozsahu 57–66 GHz) a šı́řka pásma pro jeden kanál je 2.16 GHz,
což je výrazně vı́ce než u 802.11ac (tam jen max. 160 MHz). V celém pásmu existujı́ 4 kanály, ale
ne všude je možné všechny 4 využı́t (napřı́klad v USA je možné použı́vat jen prvnı́ tři, v Čı́ně jen
druhý a třetı́, v Austrálii dokonce jen druhý a část třetı́ho, v Evropě všechny čtyři).
6.2.4
Struktura PHY, modulace
Fyzická vrstva se dělı́ na dvě podvrstvy, hornı́ a spodnı́.
• PLCP (Physical Layer Convergence Protocol) – horni podvrstva, jejı́ úkoly jsou detekce nosné
a indikace rychlosti, tvořı́ rozhranı́ k PMD.
• PMD (Physical Media Dependent) – spodnı́ podvrstva, provádı́ modulaci (různé formy –
DSSS, OFDM, atd.), kódovánı́/dekódovánı́.
Dodatek IEEE 802.11b použı́vá modulaci DSSS (Direct Sequence Spread Spectrum, rozprostřené
spektrum), IEEE 802.11a/g modulaci OFDM, v IEEE 802.11n najdeme jejı́ modifikaci MIMO-OFDM
(mj. obsahuje podporu komunikace s vı́ce anténami na jednom zařı́zenı́).
Podvrstva PLCP je odlišná pro různé podvrstvy PMD (DSSS, OFDM, FHSS apod. na spodnı́
podvrstvě), tj. rozlišujeme PLCP rámec pro DSSS, PLCP rámec pro OFDM, atd. Podvrstva MAC
na vrstvě L2 je pro 802.11a/b/g stejná, lišı́ se pro 802.11n.
Frekvence. O Wi-fi sice řı́káme, že pracuje na frekvenci 2,4 GHz nebo 5 GHz, ale ve skutečnosti je
rozsah frekvencı́ (frekvenčnı́ pásmo) trochu širšı́. Rozsah pro IEEE 802.11b (2,4 GHz) je na obrázku
6.2 a pro IEEE 802.11a na obrázku 6.3.
Obrázek 6.2: Frekvenčnı́ spektrum a kanály pro IEEE 802.11b1
1
Zdroj: http://en.wikipedia.org/wiki/802.11b
P
6.2
WI-FI
122
V rámci použı́vaného spektra (napřı́klad na frekvenci 2,4 GHz) je k dispozici vı́ce kanálů
(na zmı́něné frekvenci 13–14, podle momentálnı́ situace v přidělených frekvencı́ch) s tı́m, že AP
komunikujı́cı́ v určitém kanálu ve skutečnosti zabı́rá 5 kanálů (jeden plus dva na každé straně). Na
obrázku 6.2 jsou zvýrazněny tři kanály o šı́řce 22 MHz, které by se teoreticky neměly překrývat.
U frekvence 2,4 MHz: Šı́řka kanálu je 22–24 MHz (podle kvality zpracovánı́ signálu), ale středy
frekvencı́ v těchto kanálech jsou od sebe vzdáleny jen 5 MHz. Možných kanálů pro IEEE 802.11g
je celkem 14, ale v mnoha zemı́ch jsou některé z nich zakázány. U nás lze použı́vat kanály na
frekvencı́ch vypsaných v tabulce 6.1.
Kanál
1.
2.
3.
Frekvence o|
2412 MHz
2417 MHz
2422 MHz
Kanál
4.
5.
6.
Frekvence o|
Kanál
2427 MHz
2432 MHz
2437 MHz
7.
8.
9.
Frekvence o|
Kanál
10.
11.
12.
13.
2442 MHz
2447 MHz
2452 MHz
$
Frekvence o|
2457 MHz
2462 MHz
2467 MHz
2472 MHz
Tabulka 6.1: Kanály u frekvence 2,4 MHz využitelné v ČR
Většina Wi-Fi routerů podporuje automatický výběr nejvhodnějšı́ch kanálů, což může problém
s rušenı́m okolnı́ch přı́stupových bodů trochu zmenšit. V konfiguraci však můžeme zvolit některý
kanál ručně.
Seznam kanálů a frekvencı́ najdeme napřı́klad na
• http://wiki.airdump.cz/Seznam WiFi kan%C3%A1l%C5%AF pro WLAN
• http://www.zyxel.cz/upload/doc/Myty a famy o 802.11n.pdf
U frekvence 5 MHz: Šı́řka kanálu je stejná jako u frekvence 2,4 MHz, ale střednı́ hodnoty frekvencı́ povolených kanálů jsou od sebe vı́ce vzdáleny, tedy je mnohem snazšı́ najı́t skupinu kanálů
s nepřekrývajı́cı́mi se frekvencemi (viz tabulku 6.2). Navı́c je na našem trhu poměrně málo zařı́zenı́
pracujı́cı́ch na této frekvenci (tj. podporujı́cı́ch IEEE 802.11a), protože tento standard je poměrně
mladý (mladšı́ než „b“) a pracuje na jiné frekvenci než nejoblı́benějšı́ dalšı́ standardy.
O podpoře IEEE 802.11a můžeme uvažovat předevšı́m tehdy, když se v našem okolı́ (třeba
u sousedů) vyskytuje vı́ce routerů na frekvenci 2,4 MHz a oblast je zarušená. Nesmı́me však
zapomenout, že do sı́tě lze připojit pouze zařı́zenı́ podporujı́cı́ IEEE 802.11a.
Kanál
36
40
44
Frekvence o|
5180 MHz
5200 MHz
5220 MHz
Kanál
48
52
56
Frekvence o|
5240 MHz
5260 MHz
5280 MHz
Kanál
60
64
100–140 (děl. 4)
Frekvence o|
5300 MHz
5320 MHz
5500–5700 MHz
Tabulka 6.2: Kanály u frekvence 5 MHz využitelné v ČR
Některá zařı́zenı́ podle IEEE 802.11n dokážou pracovat na obou základnı́ch frekvencı́ch zároveň
– 2,4 GHz i 5 GHz. Koupě takového zařı́zenı́ má samozřejmě smysl jen tehdy, pokud „bude mı́t
$
6.2
WI-FI
123
s kým komunikovat“ na frekvenci 5 GHz, což nenı́ až tak běžné. Pokud však tu možnost máme,
měli bychom se zajı́mat o to, zda na obou těchto frekvencı́ch dokáže komunikovat zároveň (tj. nejen
se mezi nimi přepı́nat).
Obrázek 6.3: Frekvenčnı́ spektrum a kanály pro IEEE 802.11a (rozděleno na dvě části)2
Obrázek 6.4: Frekvenčnı́ spektrum a kanály pro IEEE 802.11ac (pro různé šı́řky kanálů)3
Interference. Bezdrátová zařı́zenı́ pracujı́cı́ na přibližně stejné frekvenci se navzájem rušı́. Neznamená to, že by tato zařı́zenı́ vůbec nefungovala, ale důsledkem rušenı́ jsou časté chyby v přenosech,
tj. hodně (nedoručených či poškozených) paketů je třeba poslat znovu ⇒ snižuje se rychlost přenosu
(v nejhoršı́m přı́padě téměř na nulu).
Teoreticky by bylo řešenı́m navolit na blı́zkých AP kanály tak, aby se dotyčné pětice co nejméně
překrývaly (tj. 2 až 3 komunikujı́cı́ AP, které se „vidı́“ a přitom se navzájem nerušı́), ale to je opravdu
jen teorie. Ve skutečnosti (dı́ky fyzikálnı́m zákonům) běžná komunikace na kanálu „zamořuje“
nejen dva okolnı́ kanály na každé straně, ale bohužel i vzdálenějšı́, i když v menšı́ mı́ře. Na
2
3
Zdroj: http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/emob30dg/RFDesign.html
Zdroj: http://www.wirevolution.com/2012/06/24/802-11ac-and-802-11ad-why-both/
L
6.2
WI-FI
124
obrázku 6.2 vidı́me tři zvýrazněné obloučky, které se nepřekrývajı́ (1., 6. a 11. kanál). V reálu je
spodnı́ část obloučků značně roztáhnuta, šum zasahuje mnohem dále („do ztracena“), jak vidı́me
na obrázku 6.5 (výstup z aplikace Wi-Spy Chanalyzer 4 pro jeden zdroj signálu podle IEEE 802.11g,
v hornı́ části si všimněte amplitudy v různých kanálech, kanály jsou označeny frekvencı́ v MHz).
Obrázek 6.5: Wi-Spy Chanalyzer4
Tj. „vhodné“ rozdělenı́ kanálů prakticky neexistuje, dva AP se budou navzájem rušit, i když
budou pracovat na „dostatečně vzdálených“ kanálech. Pokud tedy nemáme jinou možnost, lze dva
AP umı́stit tak, aby se jejich dosahy prolı́naly, kanály zvolı́me co nejdál od sebe (nicméně automaticky se to tak obvykle také děje), ovšem musı́me počı́tat s jistým snı́ženı́m rychlosti. Je zajı́mavé,
že za určitých okolnostı́ je paradoxně lepšı́ pro vı́ce AP zvolit tentýž nebo hodně blı́zký kanál, pro
dalšı́ informace viz diplomovou práci JEDLIČKA, T. Diagnostika bezdrátových sı́tı́. Diplomová práce
na Ústavu informatiky FPF SU. Opava, 2012.
Výše popsané rušenı́ je také jednı́m z důvodů, proč při použitı́ WDS musı́me počı́tat s nižšı́
propustnostı́ sı́tě. Wi-fi sı́t’ může být rušena také z jiných zdrojů (čı́mkoliv na blı́zké frekvenci),
napřı́klad mikrovlnnou troubou, naštěstı́ tento zdroj rušenı́ nebývá použı́ván dlouhodobě. Dalšı́m
zdrojem interferencı́ mohou být bluetooth zařı́zenı́, ale u nich je sı́la signálu velmi nı́zká, tedy na
funkčnost Wi-fi sı́tě nemajı́ významný vliv.
Diagnostické nástroje pro fyzickou vrstvu umožňujı́ zkoumat frekvenčnı́ spektrum. Většinou
jde o komerčnı́ nástroje a nebo sice volně šiřitelné, ale vyžadujı́cı́ kompatibilnı́ hardware (tj. záležı́
4
Zdroj: http://www.wi-spy.com.au/
$
6.2
WI-FI
125
na štěstı́, jestli takový máme). Z nejznámějšı́ch:
• NetStumbler5 – volně šiřitelný analyzátor spektra,
• Wi-Spy6 – komerčnı́ nástroj (analyzátor spektra včetně rozdělenı́ na jednotlivé kanály, set se
skládá z upravené Wi-fi sı́t’ové karty do USB konektoru a speciálnı́ho softwaru),
• Chanalyzer7 je sice komerčnı́ nástroj (jako součást Wi-Spy), ale existuje volně šiřitelná varianta;
je to výkonný spektrálnı́ analyzátor (viz obrázek 6.5),
• AirMagnet WiFi Analyzer8 je komerčnı́ nástroj funkčnostı́ podobný nástroji Wi-Spy, taktéž
spektrálnı́ analyzátor (také vyžaduje speciálnı́ hardware),
• inSSIDer9 – volně šiřitelný nástroj pracujı́cı́ pouze s Wi-fi sı́těmi, na jednotlivých kanálech
dokáže zobrazit existujı́cı́ sı́tě včetně jejich SSID,
• Xirrus Wi-fi Inspector10 – volně šiřitelný nástroj na zjišt’ovánı́ dostupných AP a jejich vlastnostı́,
• Iperf 11 (taktéž volně šiřitelný, ovládá se v textovém shellu) sloužı́ k laděnı́ parametrů sı́tě a je
to užitečný také jako pomocný nástroj při diagnostice sı́tě, dokáže odchytávat pakety (sniffer)
a generovat „přirozený provoz“ na sı́ti (užitečné při testovánı́),
• Jperf 12 je volně šiřitelná grafická nástavba programu Iperf (tj. většina lidı́ si s Iperfem instaluje
Jperf).
Existujı́ nástroje určené vysloveně pro mapovánı́ signálu, napřı́klad Ekahau Heatmapper, Ekahau Site
Survey, Meraki Wi-fi Mapper, Aerohive Free Wi-fi Planner, Cisco Clean Air, VisiWave Site Survey, RF3D
WifiPlanner.
Dalšı́ informace:
• http://www.agilent.com/about/newsroom/tmnews/background/WLAN/
• http://www.wirevolution.com/2012/06/24/802-11ac-and-802-11ad-why-both/
• http://www.cisco.com/en/US/docs/solutions/Enterprise/Mobility/emob30dg/RFDesign.html
• http://lufayo.com/tag/wlan/
Úkoly
Pokud máte k dispozici Wi-fi router, zjistěte, na jaké frekvenci pracuje (přı́padně jestli podporuje
obě základnı́ pásma) a který kanál použı́vá.
6.2.5
Antény a MIMO
Signál se šı́řı́ kolmo na anténu. To bychom měli vzı́t v úvahu, když antény směrujeme. Pokud chceme
signálem pokrýt jen jedno patro, anténa by měla směřovat nahoru nebo dolů, jestliže však chceme
5
http://www.stumbler.net
http://www.metageek.net/products/wi-spy/
7
http://www.metageek.net/products/chanalyzer/
8
http://airmagnet.cz/airmagnet-wifi-analyzer.html
9
http://www.metageek.net/products/inssider/
10
http://www.xirrus.com/Products/Wi-Fi-Inspector.aspx
11
http://sourceforge.net/projects/iperf/
12
http://code.google.com/p/xjperf/
6
$
6.2
WI-FI
126
signál šı́řit i do okolnı́ch pater nebo třeba na zahradu, anténu směrujeme šikmo. Existujı́ i směrové
antény, je také možné vytvořit z všesměrové antény směrovou.
Jedná se o vysokofrekvenčnı́ zářič, jehož vliv na zdravı́ je často diskutován (Wi-Fi router taky
nepatřı́ do ložnice nebo dětského pokoje). Proto bychom měli zkontrolovat sı́lu signálu a vhodně ji
přizpůsobit (ostatně, přı́liš silný signál může způsobit rušenı́ v okolnı́ch sı́tı́ch). Také je doporučeno
(lékaři) alespoň na noc Wi-Fi vypı́nat. Lepšı́ ADSL routery nabı́zejı́ možnost vypnutı́ Wi-Fi při
zachovánı́ ADSL připojenı́, toho bychom měli využı́t a Wi-Fi zapı́nat jen tehdy, když je potřebujeme.
MIMO (Multiple Input Multiple Output) znamená využitı́ vı́ce antén a hlavně algoritmus pro
kombinovánı́ přijatého signálu z těchto antén. Tento algoritmus je velmi důležitý, protože jinak by
se antény téhož zařı́zenı́ navzájem rušily a tlumily a signál by se naopak zhoršil. Vı́ce antén může
být na obou komunikujı́cı́ch zařı́zenı́ch – stanici i přı́stupovém bodu.
P
Obecně platı́, že čı́m vı́c antén, tı́m lepšı́ signál (a také rychlejšı́ komunikace), ale prakticky se
počı́tá s omezenı́m na 4 antény pro vnitřnı́ oblast budov a 16 antén pro použitı́ venku.
MIMO pracuje na fyzické vrstvě. S vı́ce anténami se setkáváme u 802.11n, kde sloužı́ také ke
zvýšenı́ přenosové kapacity v důsledku paralelnı́ho vysı́lánı́ (max. 4 × 4 antény).
MU-MIMO (Multi-User MIMO) je vylepšenı́ použı́vané ve WiMAX sı́tı́ch a v bezdrátových
zařı́zenı́ch podle standardu IEEE 802.11ac. Algoritmus optimalizuje využitı́ pásma s ohledem na
fakt, že v sı́ti komunikuje vı́ce uživatelů, je navázáno vı́ce spojenı́. Původnı́ MIMO lze chápat
jako SU-MIMO (Single-User MIMO), kde jeden AP dokáže v jednom okamžiku komunikovat jen
s jednı́m zařı́zenı́m.
Frekvence a licence. Frekvenčnı́ rozsahy kolem 2,4 GHz a 5 GHz patřı́ k tzv. bezlicenčnı́m pásmům.
To znamená, že pokud chceme provozovat zařı́zenı́ pracujı́cı́ v tomto pásmu, nemusı́me žádat ČTÚ
(Český telekomunikačnı́ úřad) o individuálnı́ oprávněnı́, udělenı́ licence (u pásem, která podléhajı́
povinnosti žádosti o individuálnı́ oprávněnı́, je povolenı́ podmı́něno splněnı́m určitých požadavků
na provoz zařı́zenı́).
P
P
Přesto je třeba určité limity dodržovat i v bezlicenčnı́ch pásmech, jejich použitı́ je podmı́něno
dodrženı́m podmı́nek Všeobecného oprávněnı́ k využı́vánı́ rádiových kmitočtů (celý název je delšı́, viz
zdroj dále). Omezenı́ jsou předevšı́m ve smyslu dodrženı́ maximálnı́ho vyzářeného výkonu antén,
což má zmenšit pravděpodobnost vzájemného rušenı́ zařı́zenı́ a také jsou zde určité medicı́nské
důvody (vysokofrekvenčnı́ zářenı́ je ve velkých dávkách nebezpečné pro lidský organismus).
Pokud dojde k vzájemnému rušenı́ zařı́zenı́, obvykle platı́ pravidlo „kdo dřı́v přijde, může
zůstat“. V reálu bohužel často platı́ „moudřejšı́ ustoupı́“, nicméně možnost stı́žnosti na ČTÚ je.
Text Všeobecného oprávněnı́ k využı́vánı́ rádiových kmitočtů a k provozovánı́ zařı́zenı́ pro širokopásmový
přenos dat na principu rozprostřeného spektra nebo OFDM v pásmech 2,4 GHz a 5 GHz najdeme napřı́klad
na http://www.ctu.cz/1/download/Opatreni%20obecne%20povahy/VO R 12 08 2005 34.pdf.
Úkoly
1. U dostupného Wi-fi routeru (nebo nějakého na webu, když nemáte žádný v dosahu) zjistěte:
• které režimy podporuje,
• jaké má SSID,
6.2
WI-FI
127
• zda pro zabezpečenı́ použı́vá mechanismus WEP, WPA nebo WPA2,
• které dalšı́ bezpečnostnı́ mechanismy podporuje a které jsou využı́vány.
2. Jak má být natočena anténa, pokud chceme pokrýt signálem pouze jedno patro, a jak má být
natočena, pokud chceme pokrýt i okolnı́ patra budovy? (Předpokládejme, že nemusı́me řešit
materiál zdı́, jejich propustnost.)
6.2.6
Podvrstva MAC
Podvrstva MAC je pro IEEE 802.11a/b/g stejná, odlišná je MAC pro IEEE 802.11n (za účelem
dalšı́ho zvýšenı́ rychlosti). Úkolem MAC v těchto standardech je zajištěnı́ přidruženı́ stanice k přı́stupovému bodu, autentizace, přenos dat, provoz v režimech DCF, PCF a RTS/CTS (viz dále).
Použı́vá se časový multiplex, polovičnı́ duplex (sloty jsou využı́vány vždy jen v jednom směru).
Vysı́lat lze v několika režimech:
1. DCF (Distributed Coordination Function) je režim bez podpory priorit, je výchozı́ v IEEE
802.11. Poskytuje pouze službu best effort, tedy bez garance šı́řky pásma, zpožděnı́, bez QoS
(lze doplnit podle standardu IEEE 802.11e). Mezi vysı́lané rámce jsou vkládány mezery, jejich
délka odpovı́dá době povinného čekánı́ s naslouchánı́m před začátkem vysı́lánı́. Přijı́majı́cı́
stanice po přijetı́ rámce čeká krátkou dobu a pak pošle potvrzenı́ přijetı́.
P
Pokud stanice během naslouchánı́ zjistı́ vysı́lánı́, čeká po dobu náhodně zvolenou z intervalu
0..velikost „okna sváru“. Pokud po uplynutı́ této doby opět detekuje vysı́lánı́, velikost „okna
sváru“ se zdvojnásobı́ (atd. i pro dalšı́ intervaly).
2. PCF (Point Coordination Function) je režim s podporou priorit. Přı́stupový bod v pravidelných intervalech vysı́lá služebnı́ rámce (beacon rámce).
Každý interval mezi dvěma beacony je rozdělen na dvě části – doba boje o médium (contention)
a doba bez boje o médium (contention-free). Pokud má stanice k odeslánı́ prioritnı́ data (QoS),
může zı́skat povolenı́ k vysı́lánı́ v době bez boje o médium.
Tento režim nebývá moc často implementován, nenı́ použitelný v ad-hoc sı́tı́ch.
3. RTS/CTS (Request to Send/Clear to Send) řešı́ problém „skrytých stanic“. Stanice připojené
k jednomu přı́stupovému bodu se navzájem nemusejı́ „vidět“, důsledkem jsou pokusy o vysı́lánı́ v době, kdy vysı́lá jiná stanice (nastane kolize). V tomto režimu musı́ každá stanice
před začátkem vysı́lánı́ odeslat žádost o rezervaci média (RTS) a čekat na potvrzenı́ práva po
stanovenou dobu vysı́lat (CTS).
MAC rámec.
Existujı́ tři typy MAC rámců pro IEEE 802.11:
1. Datový rámec (Data Frame)
2. Řı́cicı́ rámec (Control Frame), použı́vá se pro tyto účely:
• RTS/CTS rámce (viz dřı́ve, režimy činnosti MAC)
• ACK – potvrzenı́ přijatých rámců
P
6.2
WI-FI
128
3. Rámec pro správu (Management Frame), použı́vá se pro tyto účely:
•
•
•
•
•
•
beacon rámec (AP se ohlašuje)
probe, probe response (zjišt’ovánı́ přı́tomnosti uzlů sı́tě a jejich možnostı́)
association request, association response (žádost o asociaci od stanice, odpověd’)
re-association request, response (přechod k jinému AP ve stejné ESS)
diassociation (ukončenı́ spojenı́ k AP)
authentication (žádost o autentizaci uzlu), de-authentication
Rámec, v oktetech:
2
Frame
Control
2
6
6
6
2
6
0–2312
Duration Address
Address
Address Sequence Address
Data
ID
1
2
3
Control
4
XX
XXX
XXX
XXX
XXX
XXX
XX
XXX
XXX
XXX
Frame Control, v bitech:
XXX
2
2
4
1
1
1
1
1
1
1 XX4XX
Protocol
Type
Subtype
Version
To
From
More
DS
DS
Frag
Retry
More
Power
Mgmt
WEP
4
FCS
Order
Data
Tabulka 6.3: IEEE 802.11 MAC rámec
Struktura MAC rámce je naznačena na obrázku 6.3. Frame Control obsahuje napřı́klad verzi protokolu, přı́znak opakovaného přenosu, zda je/nenı́ použito WEP, přı́znak, zda budou následovat
ještě dalšı́ rámce, přı́znaky To DS a From DS, adresy atd.
To, co obsahujı́ jednotlivá pole, je ovlivněno momentálnı́m zdrojem a cı́lem dotyčného rámce,
rozlišujeme tyto přı́pady:
1. sı́t’ ad-hoc, jednotlivá pole rámce majı́ tuto hodnotu:
• oba přı́znaky = 0 (odesı́latel i přı́jemce jsou uzel)
• addr1 = MAC přı́jemce (Destination Address)
• addr2 = MAC odesı́latele (Source Address)
...
...
To DS
0
From DS
0
...
Addr 1
Addr 2
Addr 3
...
Addr 4
...
...
MAC
přı́jemce
MAC
odesı́latele
–
...
–
...
2. infrastruktura, přenos od AP ke stanici, jednotlivá pole rámce majı́ tuto hodnotu:
•
•
•
•
...
...
To DS=0 (přı́jemce je uzel), From DS=1 (odesı́latel je AP/DS)
addr1 = MAC přı́jemce (stanice)
addr2 = BSSID (MAC AP), fyzický odesı́latel
adr3 = MAC odesı́latele (stanice), logický odesı́latel
To DS
0
From DS
1
...
Addr 1
Addr 2
Addr 3
...
Addr 4
...
...
MAC
přı́jemce
BSSID
AP
MAC
odesı́latele
...
–
...
P
6.2
WI-FI
129
3. infrastruktura, přenos k AP, jednotlivá pole rámce majı́ tuto hodnotu:
•
•
•
•
...
...
To DS=1 (přı́jemce je AP/DS), From DS=0
addr1 = BSSID AP (fyzický přı́jemce)
addr2 = MAC odesı́latele
addr3 = logický přı́jemce (MAC)
To DS
1
From DS
0
...
Addr 1
Addr 2
Addr 3
...
Addr 4
...
...
BSSID
AP
MAC
odesı́latele
MAC
přı́jemce
...
–
...
4. infrastruktura, přes DS, jednotlivá pole rámce majı́ tuto hodnotu:
•
•
•
•
•
...
...
To DS=From DS= 1
addr1 = MAC (BSSID) přijı́majı́cı́ho AP
addr2 = MAC (BSSID) odesı́lajı́cı́ho AP
addr3 = DA (MAC logického přı́jemce)
addr4 = SA (MAC logického odesı́latele)
To DS
1
From DS
1
...
Addr 1
Addr 2
Addr 3
...
Addr 4
...
...
BSSID
přı́jimajı́cı́ho AP
BSSID
odesı́lajı́cı́ho AP
MAC
přı́jemce
...
MAC
odesı́latele
...
Diagnostické nástroje pro MAC podvrstvu jsou předevšı́m sniffery, tj. programy, které odchytávajı́ pakety, umožňujı́ je analyzovat či vizualizovat a přı́padně nabı́zejı́ dalšı́ doprovodné funkce.
Vpodstatě se tyto nástroje použı́vajı́ souhrnně pro drátové i bezdrátové sı́tě, protože u nich významnějšı́ odlišnosti na MAC nenajdeme (až na drobnosti, viz formát MAC rámce výše). Sı́t’ové rozhranı́,
které je takto analyzováno, by mělo běžet v promiskuitnı́m módu, to znamená, že by mělo přijı́mat
všechny rámce včetně těch, ve kterých je cı́lová adresa jiná (určených jinému uzlu v sı́ti). V přı́padě nástrojů pro bezdrátové sı́tě se také setkáváme s nástroji pro „prolamovánı́ “ zapomenutých
hesel/WEP, apod.
Nejznámějšı́m a nejpopulárnějšı́m volně šiřitelným snifferem je Wireshark13 (původně Ethereal).
Taktéž oblı́bený volně šiřitelný je Kismet14 – detektor sı́tı́, sniffer a potenciálně IDS (budeme se učit
později). Dalšı́ jsou komerčnı́ Eye P.A. a Cascade Pilot.
6.2.7
Úvod do šifrovánı́
Při šifrovánı́ potřebujeme
• šifrovacı́ algoritmus = statická součást procesu šifrovánı́
• „proměnné“ složky postupu – obvykle je to šifrovacı́ klı́č, heslo apod.
Na obou těchto složkách závisı́ výsledné zabezpečenı́ šifrovaných dat – potřebujeme dostatečně
kvalitnı́ šifrovacı́ algoritmus a dostatečně silný klı́č/heslo.
13
14
http://www.wireshark.org/
http://www.kismetwireless.net/
$
6.2
WI-FI
130
Existujı́ dva základnı́ typy šifrovánı́:
1. symetrické – 1 klı́č (tentýž) pro šifrovánı́ i dešifrovánı́
2. asymetrické – použı́vajı́ se dva odlišné klı́če (soukromý a veřejný)
3. hybridnı́ kombinuje oba předchozı́ přı́stupy
Nejdřı́v se podı́váme na symetrické šifrovánı́, kdy máme pouze jeden klı́č pro šifrovánı́ i dešifrovánı́.
Postup při symetrickém šifrovánı́ je následujı́cı́:
P
• odesı́latel zašifruje data pomocı́ klı́če, odešle
• přı́jemce dešifruje data pomocı́ téhož klı́če
Výhodou je rychlost šifrovánı́ a dešifrovánı́, nevýhodou je problém s bezpečnou distribucı́ klı́če.
Proto symetrické šifrovánı́ použı́váme tehdy, když lze použı́t dostatečně zabezpečený kanál pro
přenos klı́če druhé straně (osobnı́m předánı́m nebo použitı́m jiné šifrovacı́ metody).
Typickými zástupci symetrického šifrovánı́ jsou DES, AES, RC4.
Asymetrické šifrovánı́ využı́vá dva klı́če a je založeno na jednocestné funkci (tj. když na zašifrovaná data použijeme inverznı́ funkci, nedostaneme tatáž data, která jsme měli před původnı́m
šifrovánı́m). Použı́váme tyto dva klı́če:
P
• soukromý klı́č vlastnı́ přı́jemce šifrované zprávy
• veřejný klı́č byl distribuován odesı́lateli zprávy (vygeneroval ho přı́jemce coby párový klı́č ke
svému soukromému klı́či)
Odesı́latel zprávu zašifruje veřejným klı́čem, který obdržel od přı́jemce zprávy, odešle, přı́jemce
zprávu dešifruje svým soukromým klı́čem.
Výhodou je, že veřejný klı́č lze poslat i nezabezpečeným kanálem (jı́m zašifrovaná data nelze
dešifrovat bez soukromého klı́če), nevýhodou je výrazně vyššı́ výpočetnı́ (časová) náročnost šifrovánı́.
Typickými zástupci jsou RSA, PGP, mechanismus se využı́vá pro certifikáty, digitálnı́ podpisy.
Hybridnı́ šifrovánı́ je kombinacı́ obou předchozı́ch postupů. Je dvoustupňové:
• prvnı́ stupeň = symetrické šifrovánı́ (odesı́latel zašifruje data pomocı́ rychlého symetrického
klı́če)
• druhý stupeň = asymetrické šifrovánı́ (symetrický klı́č zašifruje asymetricky veřejným klı́čem
přı́jemce)
Samotná data jsou šifrovaná symetricky (velký objem ⇒ výhoda rychlosti symetrie), naproti tomu
symetrický klı́č (ted’ „v roli dat“) je šifrovaný asymetricky (malý objem ⇒ rychlost nenı́ tak důležitá).
Hybridnı́ šifrovánı́ si tedy bere z obou možnostı́ to lepšı́ (ze symetrického rychlost, z asymetrického vyššı́ bezpečnost). Typicky se použı́vá pro delšı́ komunikaci, kde se posı́lá vı́ce dat (postupně,
s navázánı́m spojenı́) – relace. Symetrický klı́č se šifruje asymetrickým postupem pouze jednou pro
celou relaci, pak během komunikace v rámci relace se použı́vá pouze „rychlé“ symetrické šifrovánı́.
P
6.2
WI-FI
6.2.8
131
AAA
AAA (autentizace, autorizace, účtovánı́ – accounting) probı́há při připojovánı́ uzlu do sı́tě. Autentizace je ověřovánı́ a potvrzovánı́ totožnosti komunikujı́cı́ch stran (pokud možno obou). Zdůvodu
zvýšenı́ bezpečnosti je možné použı́t autentizaci za asistence třetı́ důvěryhodné strany (trusted
third party).
P
Autentizace může být otevřená (prakticky nic se nekontroluje) nebo podle autentizačnı́ho sdı́leného klı́če. Prvnı́ typ je charakteristický pro veřejné hotspoty.
Autorizace znamená určenı́ konkrétnı́ch přı́stupových oprávněnı́ přihlašovaného uživatele. Po
autentizaci a autorizaci je stanice přidružena k přı́stupovému bodu a může komunikovat.
Účtovánı́ je zaznamenávánı́ všech činnostı́ provedených uživatelem v systému a přı́padné následné reakce.
Autentizačnı́ klı́č se použı́vá při autentizaci při přihlašovánı́ do sı́tě, a dále při šifrovánı́ komunikace. Typy:
• WEP – zastaralý, dávno prolomen
• WPA – použı́vá WEP klı́če, ale dynamicky je měnı́ (protokol TKIP), autentizace pomocı́
RADIUS Serveru (přihlašovánı́ jménem a heslem) nebo klı́če PSK (Pre-Shared Key)
• WPA2 – šifrovánı́ AES
WEP (Wired Equivalent Privacy) je mechanismus zabezpečenı́, který poskytuje pouze základnı́
stupeň bezpečnosti. Jeho jedinou výhodou je plná kompatibilita se všemi Wi-Fi zařı́zenı́mi, a proto
je také obvykle nastaven jako výchozı́.
Použı́vá stejné šifrovánı́ pro autentizaci i přenos dat – možnosti:
• bez šifrovánı́ (plně otevřená sı́t’)
• symetrická šifra RC4, 40bitový statický klı́č + 24bitový proměnný inicializačnı́ vektor = 64bitový
RC4 klı́č
• symetrická šifra RC4, 104bitový statický klı́č + 24bitový proměnný inicializačnı́ vektor = 128bitový RC4 klı́č
IV (inicializačnı́) vektor se měnı́ pro každý paket ⇒ přı́jemce musı́ mı́t možnost IV vektor zjistit.
Teoreticky může existovat sdı́lený algoritmus pro generovánı́ IV vektoru, ale prakticky ve WEP je
IV vektor součástı́ nešifrované hlavičky WEP paketu!!! (hned prvnı́ prvek uvnitř MAC rámce), záhlavı́
se nešifruje.
Dalšı́m problémem je, že autentizace je jen jednostranná (stanice, resp. jejı́ sı́t’ová karta, se
autentizuje přı́stupovému bodu, ale AP se neautentizuje stanici).
Připojenı́ stanice k AP probı́há takto:
•
•
•
•
•
Stanice odešle žádost o připojenı́,
přı́stupový bod odpovı́ odeslánı́m náhodně vygenerované sekvence znaků (bez šifrovánı́),
stanice tuto sekvenci zašifruje svým tajným klı́čem a zašle zpět přı́stupovému bodu,
přı́stupový bod také provede šifrovánı́ stejné sekvence,
pokud se výsledky shodujı́, stanice může být přidružena k sı́ti.
P
6.2
WI-FI
132
WEP je snadno zneužitelný dokonce několika různými způsoby, kromě jiného také dı́ky přı́liš
krátké sekvenci IV vektoru. Dále při autentizaci je zası́lána ověřovacı́ sekvence a hned poté jejı́
zašifrovaná podoba, tedy při tak krátké délce tajného klı́če nenı́ problém tajný klı́č postupně odhalit
(pro tento účel lze dokonce použı́t volně šiřitelné nástroje, WEP crackery, napřı́klad AirCracku to
trvá několik minut). Protože je to obvykle výchozı́ typ zabezpečenı́ v přı́stupových bodech, je
vhodné hned po koupi změnit typ zabezpečenı́ na některý jiný.
802.1x je pokusem o zvýšenı́ bezpečnosti WEP. Jedná se o mechanismus autentizace uživatelů,
distribuce klı́čů a zajištěnı́ integrity zpráv. Principem je zavedenı́ autentizačnı́ho serveru, kterým
je obvykle RADIUS (Remote Authentication Dial-In Usr Service).
RADIUS pracuje ve struktuře typu klient-server, kde samotný RADIUS je server, klienty jsou
přı́stupové servery (autentizátoři, napřı́klad Wi-Fi přı́stupové body), ke kterým se přihlašujı́ uživatelé (tj. RADIUS sı́t’je tvořena RADIUS serverem a přı́stupovými servery, stanice do nı́ nepatřı́).
K autentizaci klientů u serveru se použı́vá sdı́lené tajné heslo, které se nikdy nepřenášı́ po sı́ti.
Naopak uživatelé se u RADIUS klienta (přı́stupového serveru) autentizujı́ heslem, které se přenášı́
v zašifrované podobě. Komunikace:
• uživatel požádá o připojenı́,
P
$
• přı́stupový server si vyžádá přihlašovacı́ jméno a heslo,
• přı́stupový server odešle RADIUS serveru (přes lokálnı́ nebo rozlehlou sı́t’) žádost o připojenı́
(RADIUS Access Request),
• RADIUS server ověřı́ platnost přihlašovacı́ho jména a hesla (dostal je v zašifrované podobě),
přı́padně si vyžádá dalšı́ informace, také může zvážit např. MAC adresu a dalšı́ filtrovacı́
kritéria,
• podle výsledku ověřenı́ odešle přı́stupovému serveru souhlas nebo odmı́tnutı́ (RADIUS
Access Accept/Deny).
Komunikace je naznačena na obrázku 6.6.
V komunikaci mezi RADIUS serverem a klienty je možné použı́t v rámci protokolu RADIUS
zabezpečenı́ IPSec, v autentizačnı́ komunikaci mezi RADIUS klientem a stanicı́ (přı́padně také mezi
RADIUS serverem a klientem) se běžně použı́vá některá z těchto možnostı́:
• EAP-TLS (Microsoft) – v kombinaci s protokolem TLS a mechanismem PKI, certifikáty X.509
(mı́sto jména a hesla), dostupný na většině verzı́ Windows, MacOS X
• LEAP (Cisco) – dynamické klı́če WEP jednorázové pro každou relaci, relace je časově omezená
(několik minut), oboustranná autentizace
• EAP-MD5 – ze jména a hesla vytvořı́ MD5 hash, použı́vá pouze statické klı́če WEP, nejméně
bezpečná možnost
• dalšı́ – EAP-TTLS, EAP-PSK, EAP-IKEv2, atd.
EAP lze zapouzdřovat, napřı́klad PEAP stanovuje zapouzdřenı́ (jakéhokoliv) EAP do zabezpečeného tunelu.
IEEE 802.1x je sice lepšı́ než samotný WEP, ale přesto (předevšı́m při použitı́ hesel, která nejsou
dostatečně silná) je prolomitelný, náchylný předevšı́m k útokům typu DoS (Denial of Service)
6.2
WI-FI
133
Wi-fi AP
(RADIUS klient)
PC
RADIUS
server
EAPOL Start
Žádost o přı́stup
EAP Request/Id
Autorizuj se
EAP Response/ID
Aut.informace (U)
RADIUS Access Request/ID
Aut. informace (U)
EAP Request/OTP
Dalšı́ informace?
RADIUS Acces-Challenge
Dalšı́ informace?
EAP Response/OTP
Dalšı́ informace (U)
RADIUS Access Request/OTP
Dalšı́ informace (U)
EAP Success
Spojeno (U)
RADIUS Acces-Accept
Spojeno (U)
Využı́vánı́ portu, pro který bylo zařı́zenı́ autorizováno.
EAPOL Logoff
Ukončenı́ relace
Obrázek 6.6: Autentizace podle IEEE 802.1x (RADIUS)
a Man-in-the-Middle. Hlavnı́m přı́nosem jsou dynamické klı́če a zavedenı́ třı́prvkové autentizace
(autentizačnı́ server).
Existuje i volně dostupný software pro RADIUS server, napřı́klad open-source projekt FreeRADIUS. Jako rozhranı́ k FreeRADIUSu se často použı́vá daloRADIUS.15 Na stanici musı́ běžet
klientská aplikace, ale ta je běžnou součástı́ operačnı́ch systémů.
WPA (Wi-Fi Protected Access) je dočasné řešenı́, které vzniklo před dokončenı́m standardu
IEEE 802.11i (WPA2). WPA vznikl „ořezánı́m“ připravovaného WPA2 na pouze ty prvky, které
nevyžadovaly změny v hardwaru, změny v softwaru (vč. firmwaru sı́t’ových karet) se implementujı́
snadněji a rychleji. Je kompatibilnı́ jak s WEP, tak i se svým nástupcem WPA2.
Šifrovánı́ probı́há podobně jako u WEP (použı́vá se RC4), ale IV vektor je 48bitový, klı́č 128bitový.
Podpora šifrovánı́ je zajištěna protokolem TKIP (Temporal Key Integrity Protocol), který provádı́
dynamickou správu šifrovacı́ch klı́čů (celý klı́č se měnı́ pro každý paket) – to je důležitá změna
oproti statickým (neměnným) klı́čům u WEP.
Integrita zpráv je zajištěna mechanismem MIC (Message-Integrity Check, taky Michael) – to je
mechanismus pro kontrolu integrity zpráv (definovaný v protokolu TKIP); na konec šifrované
části rámce před kontrolnı́ součet se přidá 64 kontrolnı́ch bitů (MIC) vytvořených z
• cı́lové a zdrojové MAC adresy,
• dat,
• pořadového čı́sla paketu a náhodné hodnoty (přı́p. priority)
15
http://freeradius.org/, http://daloradius.com/
$
P
6.2
WI-FI
134
Vpodstatě se jedná o jakýsi digitálnı́ podpis paketu.
Existujı́ dvě varianty WPA:
1. WPA-Enterprise (pro firemnı́ užitı́) – použı́vá se v kombinaci s IEEE 802.1X – RADIUS
2. WPA-Personal (pro domácnosti, SOHO segment; také se označuje WPA-PSK) – autentizace
s provádı́ jen pomocı́ sdı́leného klı́če PSK, nenı́ třeba mı́t speciálně určený server pro běh
RADIUSu.
WPA-PSK (Pre-Shared Key) jednoduše funguje tak, že uživatel zadává heslo 8-63 ASCII znaků
(nebo 64 hex. čı́slic).
WPA je bezpochyby lepšı́m řešenı́m než WEP, ale protože se vlastně jedná jen o vylepšenı́
vlastnostı́ WEP+802.1X s přidánı́m kontroly integrity zpráv, nenı́ to ideálnı́ řešenı́. Nicméně pro
domácı́ AP může být dostačujı́cı́, pokud zvolı́me dostatečně silné heslo.
WPA2 (IEEE 802.11i) použı́vá mı́sto TKIP protokol CCMP s šifrovánı́m AES (volitelně je možno
použı́t TKIP s šifrovánı́m RC4, pro zpětnou kompatibilitu se staršı́mi zařı́zenı́mi). CCMP je zkratka
z Counter-mode CBC (Cipher Block Chaining) MAC (Message Authentication Code) Protocol.
Autentizace probı́há bud’ přes IEEE 802.1X (WPA2-Enterprise) nebo v jednoduššı́m přı́padě
přes PSK stejně jako u WPA (WPA2-PSK, Personal). V datových rámcı́ch se mı́sto slabého RC4
použı́vá šifrovánı́ AES na 128 bitech, MIC pole o délce 64 bitů a čı́slovánı́ paketů.
P
Narozdı́l od WPA je možné zabránit útokům typu Man-in-the-Middle, ale nedokáže zcela
zabránit existenci neautorizovaných přı́stupových bodů.
Pro autentizaci existuje vı́ce možnostı́ – PBC, PIN, NFC, atd.
Tlačı́tko WPS (PBC – Push Button) je metoda autentizace pro maximálnı́ zjednodušenı́ připojovánı́ zařı́zenı́, která nejsou zrovna „počı́tačového typu“. Na AP zmáčkneme tlačı́tko „WPS“ (nebo
QSS nebo podobně – hardwarové nebo „softwarové“ tlačı́tko), pak po několik desı́tek sekund AP
skenuje okolı́ a hledá nové stanice. Stejné tlačı́tko zmáčkneme na zařı́zenı́, které chceme připojit
(lednička, televize apod.). AP detekuje nové zařı́zenı́, automaticky provede autentizaci a asociaci.
Postup nenı́ úplně bez rizika: několik desı́tek sekund je sı́t’ prakticky bez ochrany, naštěstı́ se
tento postup obvykle neprovádı́ přı́liš často.
WPS přes PIN je podobná metoda taktéž určená pro jednoduché připojovánı́ zařı́zenı́. Na připojovaném zařı́zenı́ zjistı́me PIN (v administraci zařı́zenı́ nebo na nálepce), PIN zadáme v administraci
AP, zařı́zenı́ si opět vše automaticky vyjedná s AP, přı́padně může být třeba zadat přı́stupové údaje.
Riziko se sice zdá menšı́ než u předchozı́ho postupu, ale je třeba si uvědomit následujı́cı́:
• AP s podporou tohoto typu WPS naslouchá neustále
• PIN je 8mı́stné čı́slo, poslednı́ čı́slice je kontrolnı́m součtem
• pokud PIN zadáme špatně, AP vracı́ informaci, která polovina PINu je špatně!
V souhrnu se jedná o závažnou bezpečnostnı́ dı́ru, která je ve firmwaru routeru. Částečně se dá
řešit tehdy, pokud v administraci routeru existuje volba vypnutı́ skenovánı́ zařı́zenı́ připojovaných
přes WPS (zapı́nali bychom jen v přı́padě potřeby).
P
P
6.2
WI-FI
6.2.9
135
Zabezpečenı́ Wi-Fi sı́tı́
Kromě nastavenı́ dostatečně bezpečného šifrovánı́ (WPA2) máme ještě dalšı́ možnosti.
SSID se dá také považovat za možnost zabezpečenı́ sı́tě. Standardně sı́t’vysı́lá svoje SSID (broadcast), ale nemusı́ (blokovánı́ vysı́lánı́ SSID), pak nenı́ běžným způsobem viditelná v seznamu
dostupných sı́tı́ (soukromá sı́t’). Skrývánı́ SSID však odporuje specifikaci Wi-Fi, navı́c může přinést
komplikace sousedům (pak nemohou přijı́t na to, proč je oblast tak zarušená, i když žádnou sı́t’
nevidı́).
Tuto ochranu (skrytı́ SSID) lze snadno překonat – když se kdokoliv přihlašuje, přenášı́ se SSID
a lze ho zachytit, stačı́ jen trochu trpělivosti při naslouchánı́. Doporučuje se však alespoň přenastavit
si SSID, protože podle jeho výchozı́ hodnoty se dá poznat výrobce (hacker pak snadněji odhaduje
slabá mı́sta, bezpečnostnı́ mezery, výchozı́ přihlašovacı́ jméno a heslo do administrace routeru,
atd.).
Filtrovánı́ MAC adres může být použito ve formě whitelistu nebo blacklistu. Přı́stupové body
většinou umožňujı́ nastavit blacklist (MAC adresy, kterým je přihlášenı́ odmı́tnuto) nebo whitelist
(přihlášenı́ povoleno) MAC adres a tak určit, které stanice se nemohou/mohou přihlásit.
Blacklist (a vlastně i whitelist) se dá překonat změnou MAC adresy. MAC adresy se totiž
přenášejı́ v nezašifrované podobě, a tedy při použitı́ whitelistu nenı́ problém zachytit některou
„povolenou“ adresu.
Přı́stupové údaje implicitně nastavené z továrny je vhodné změnit. Jedná se o IP adresu, SSID,
ale předevšı́m o přihlašovacı́ údaje (pro administraci přı́stupového bodu).
Pokud chceme konfigurovat nastavenı́ přı́stupového bodu, obvykle to provádı́me přes webové
rozhranı́. Je třeba zadat IP adresu zařı́zenı́ do adresového řádku internetového prohlı́žeče a dále
přihlašovacı́ jméno a heslo. Hned po zprovozněnı́ přı́stupového bodu bychom měli změnit minimálně přı́stupové heslo (jméno a heslo bývajı́ obvykle admin–admin, cisco–cisco, root, 1234, airlive,
password, public, apod.).
Pro monitorovánı́ WLAN je možné použı́t napřı́klad tyto nástroje (volně dostupné):
• NetStumbler – identifikuje přı́stupové body, dá se použı́t pro zjištěnı́ neautorizovaných přı́stupových bodů nebo možných zdrojů rušenı́ vlastnı́ sı́tě
• Ethereal – analyzátor LAN sı́tı́, at’už „drátových“ nebo bezdrátových
• AirSnort – monitoring sı́tě
• Kismet – monitoring sı́tě, IDS (Intrusion Detection System)
U uživatelů se můžeme setkat s tvrzenı́m „Kdo by
se asi chtěl nabourat zrovna do mého počı́tače?“.
Kdo? Spousta lidı́ (nebo softwarových agentů).
V současné době existujı́ rozsáhlé sı́tě botů (botnety)
– bot je malware, který z počı́tače udělá „zombie“,
spı́cı́ho agenta. Botnety jsou zneužı́vány napřı́klad
k rozesı́lánı́ spamu nebo DDoS útokům. V poslednı́
době nejsou zrovna nezajı́mavá také osobnı́ data
Obrázek 6.7: Úryvek z bezpečnostnı́ho logu
P
P
P
$
6.2
WI-FI
136
uživatelů, která se dokonce často vážou k jejich zaměstnánı́ nebo jde o přı́stupové údaje a certifikáty k internetovému bankovnictvı́.
Součástı́ ADSL Wi-Fi routerů bývá hardwarový firewall, ten bychom rozhodně měli využı́vat
jako doplněk k softwarovému firewallu, který bezpochyby máme nainstalován a řádně aktualizován (a také vedle antiviru a antispywaru).
Dalšı́ informace o zabezpečenı́ bezdrátové sı́tě:
• http://www.hsc.fr/ressources/articles/hakin9 wifi/hakin9 wifi CZ.pdf
• http://www.security-portal.cz/clanky/bezpe%C4%8Dnost-hacking-wifi-80211-4-%C4%8D
%C3%A1st-wpa-wpa2
• http://computer-network-fundamentals.blogspot.com/2011 07 01 archive.html
• http://www.dcs.fmph.uniba.sk/diplomovky/obhajene/getfile.php/diplomovka szarkova.pdf?
id=160&fid=260&type=application%2Fpdf
• http://radio.feld.cvut.cz/personal/mikulak/MK/MK07 semestralky/charakteristiky siti wlan.pdf
6.2.10
Wi-fi čtvrté a páté generace
Většina toho, co jsme se až dosud naučili o Wi-fi sı́tı́ch, platilo pro Wi-fi sı́tě třetı́ generace (nebo
staršı́) – v podstatě IEEE 802.11g a staršı́. Některé zdroje řadı́ do třetı́ generace také IEEE 802.11n,
jiné zdroje je řadı́ již do generace čtvrté.
Sı́tě čtvrté generace. Ve firemnı́m prostředı́ se začı́najı́ prosazovat sı́tě čtvrté generace (takto
ten pojem budeme chápat v následujı́cı́m textu), kde se změny oproti staršı́ generaci projevujı́
u mezilehlých zařı́zenı́ (routerů) – tedy koncová zařı́zenı́ (sı́t’ové Wi-fi karty v počı́tačı́ch apod.)
nemajı́ problémy s kompatibilitou.
V přı́padě nutnosti pokrytı́ většı́ oblasti signálem se mı́sto klasických částečně se překrývajı́cı́ch
buněk použı́vajı́ blankety. Blankety jsou definovány na fyzické vrstvě a na této vrstvě také docházı́
k oddělenı́ jednotlivých služeb. Jeden blanket funguje přes všechny AP v sı́ti a využı́vá jeden jediný
kanál (taktéž pro všechny AP), přesto se jednotlivé AP navzájem nerušı́. Dokonce při zvýšenı́
hustoty AP se zvyšuje kvalita a přenosová rychlost signálu (u předchozı́ generace by se AP na
společném kanále navzájem rušily).
Pokud chceme vytvořit vı́ce fyzicky oddělených sı́tı́ (s překrývajı́cı́mi se oblastmi), vytvořı́me
pro ně samostatné blankety. Zařı́zenı́ v rámci jednoho blanketu pracujı́ na stejném kanálu, zařı́zenı́
z různých blanketů pracujı́ na různých kanálech, tedy teoreticky nedocházı́ k ovlivněnı́ komunikace
mezi blankety (blanketů nesmı́ být moc).
V sı́ti je jediný centrálnı́ prvek, ostatnı́ AP fungujı́ v ultra-tenkém režimu, tedy pouze přeposı́lajı́
signál, jsou k centrálnı́mu prvku připojeny přes ethernetovou kabeláž (včetně napájenı́ přes PoE).
Z pohledu uživatelského zařı́zenı́ se celá sı́t’ mezilehlých prvků (konkrétněji jeden blanket) jevı́
jako jeden jediný AP s jedinou MAC adresou. Roaming (přecházenı́ mezi AP v tomtéž blanketu,
přehlašovánı́ se mezi AP) je zcela transparentnı́, plynulý a bezproblémový.
Souhrnně o Wi-fi čtvrté generace:
• Jsou kompatibilnı́ s běžnými zařı́zenı́mi IEEE 802.11a/b/g/n.
P
P
P
6.3
WIMAX
137
• Existuje jeden centrálnı́ prvek, který vše řı́dı́.
• Čı́m vı́c AP, tı́m lepšı́ pokrytı́, signál a rychlost, navzájem se nerušı́.
• Kvalitnı́ zabezpečenı́ (řešenı́ je pro firemnı́ sı́tě).
Problémem tohoto řešenı́ je cena (zejména cena centrálnı́ho prvku, v řádu cca desı́tky tisı́c korun),
proto se využı́vá pouze tam, kde jsou tyto náklady odůvodnitelné (rozsáhlá dobře pokrytá oblast, hodně AP na jeden centrálnı́ prvek), typicky v nemocnicı́ch, frekventovaných skladovacı́ch
prostorách, některých firmách. Rozhodně se nejedná o řešenı́ pro SOHO.
Sı́tě páté generace. Během roku 2012 se do obchodů dastala zařı́zenı́ pracujı́cı́ podle standardu
IEEE 802.11ac. Tato zařı́zenı́ majı́ komunikovat na frekvencı́ch kolem 5 GHz, které ještě nejsou tak
zarušené jako pásmo 2,4 GHz. Můžeme se také setkat s označenı́m 5G Wi-Fi, které narážı́ jak na
generaci, tak i na použité pásmo. O tomto standardu jsme se dozvěděli už v předchozı́m textu (viz
kap. 6.2.3, str. 120).
Dalšı́ informace o Wi-fi:
•
•
•
•
•
•
•
•
6.3
6.3.1
http://www.marigold.cz/item/wds-pro-pohodlnou-stavbu-vetsi-wifi-site
http://www.cs.vsb.cz/grygarek/SPS/projekty0607/RADIUS-Stankus.pdf
http://www.security-portal.cz/clanky/wifi-sı́tě-jejich-slabiny
http://www.svethardware.cz/art doc-121AB59EC9127B44C12570A60045C902.html
http://www.intelek.cz/art doc-D7A489A18B634F84C12575550053ECAE.html
http://www.odbornecasopisy.cz/index.php?id document=39716
http://www.intelek.cz/db/media.nsf/w/E4A2BCABAE379135C125732300589FD3/$file/extricom.pdf
http://it.cestuji.info/wifi-router.php
WiMAX
Vlastnosti
WiMAX (IEEE 802.16, Worldwide Interoperability for Microwave Access) je vlastně bezdrátová
metropolitnı́ sı́t’(WMAN – Wireless MAN). Jejı́m účelem je předevšı́m poskytnout rychlý a spolehlivý přı́stup k Internetu, tedy technologie poslednı́ mı́le. Důležitou vlastnostı́ je také přı́má podpora
QoS (to je jedna z odlišnostı́ oproti Wi-Fi, kde se setkáváme pouze s „best effort“, QoS je možné
zavést až dodatečně pomocı́ IEEE 802.11e).
P
Na standardizaci a certifikaci produktů se podı́lı́ WiMAX Forum, které je sdruženı́m výrobců
WiMAX zařı́zenı́ (je to obdoba Wi-Fi Alliance).
Původnı́ specifikace IEEE 802.16 z roku 2001 stanovila použitı́ kmitočtového pásma 10–66 GHz,
které však vyžaduje přı́mou viditelnost komunikujı́cı́ch uzlů. Proto byla v roce 2003 tato specifikace
zcela nahrazena novou, kde se využı́vá kmitočtové pásmo 2–11 GHz (u nás nejčastěji 3.5 GHz)
nevyžadujı́cı́ přı́mou viditelnost komunikujı́cı́ch uzlů (NLOS, Non Line of Sight), využı́vá odrazů
od okolnı́ch objektů. Pásmo je licencované, což se projevuje i na cenách zařı́zenı́ a připojenı́. Roku
2005 se objevila možnost mobility (handover, roaming – při pohybu do rychlosti max. 150 km/h)
ve standardu IEEE 802.16e-2005, do té doby nebylo možné zajistit plynulé předávánı́ pohybujı́cı́ch
se uzlů mezi základnovými stanicemi.
P
6.3
WIMAX
138
Teoretický dosah signálu je 50 km, v běžné zástavbě se počı́tá s dosahem 3–5 km. To je pořád vı́c
než Wi-Fi, kde je obvyklý dosah maximálně v desı́tkách metrů. Přenosová kapacita je 30–75 Mb/s
(podle konkrétnı́ho standardu), tu však sdı́lejı́ všechny připojené stanice.
Na fyzické vrstvě se použı́vá OFDM nebo OFDMA (OFDM Access). Prvnı́ zmı́něné už známe
(stovky nosných frekvencı́ – subkanálů, vzájemně ortogonálnı́ch, aby je bylo možné oddělit).
OFDMA je podobné, jen zatı́mco v OFDM jsou všechny subkanály jediného kanálu na frekvencı́ch
„za sebou“ (celý kanál je vyhrazen jedinému uživateli), v OFDMA jsou kanály jednoho subkanálu
rozprostřeny v celém spektru a tedy mezi subkanály jednoho uživatele lze vybı́rat ty, které jsou na
v tu chvı́li nejkvalitnějšı́ch frekvencı́ch. Dalšı́ vylepšenı́, S-OFDMA (Scalable OFDMA), má zlepšit
kvalitu signálu při NLOS (bez přı́mé viditelnosti).
6.3.2
Zařı́zenı́
V současné době se setkáváme se zařı́zenı́mi označenými jako WiMAX nebo preWiMAX. PreWiMAX zařı́zenı́ odpovı́dajı́ specifikaci IEEE 802.16, ale nenı́ u nich potvrzena interoperatibilita se
zařı́zenı́mi stejného typu od ostatnı́ch výrobců. Jednı́m z nejznámějšı́ch dodavatelů WiMAX zařı́zenı́ je firma Alvarion, z dalšı́ch napřı́klad RedMAX nebo AirSpan.
Hlavnı́m článkem sı́tě je základnová stanice umı́stěná obvykle na vyvýšeném mı́stě, což je většinou vysoká budova. Dalšı́ úrovnı́ v hierarchii jsou vnějšı́ zařı́zenı́ zahrnujı́cı́ anténu, ta se obvykle
umı́st’ujı́ na střechy nebo venkovnı́ zdi domů. Poslednı́ úrovnı́ jsou vnitřnı́ koncová zařı́zenı́. Existujı́ také zařı́zenı́, která v sobě sdružujı́ obě posledně jmenovaná, tedy vnitřnı́ koncová zařı́zenı́
s (integrovanou) anténou, ta však vyžadujı́ lepšı́ pokrytı́.
P
P
V komunikaci lze použı́t časový (TDD) i frekvenčnı́ (FDD) duplex (u nás jsou povolena zařı́zenı́
použı́vajı́cı́ FDD) – nemluvı́me zde o multiplexu, protože komunikace je sice obousměrná, ale
v jednom okamžiku na dané frekvenci (ve skutečnosti ve dvou kanálech, jednom pro každý směr)
jen mezi dvěma uzly. Způsob využitı́ signálu je poměrně volný, záležı́ na poskytovateli připojenı́,
jak se se svými zákaznı́ky dohodne. Spojenı́ může být symetrické nebo asymetrické, je smluvně
garantována konkrétnı́ kvalita služby (QoS).
V současné době je WiMAX provozován na vı́ce mı́stech v ČR, ale spı́še lokálně v menšı́ch
oblastech (spı́še jde o oblasti ve velkých městech, kde se očekává firemnı́ klientela). Kanály 1–14
(o šı́řce 3,5 MHz) jsou určeny pro lokálnı́ operátory, kanály 15–20 pro celoplošné operátory.
Pro WiMAX je typická centralizovanost, jejı́mž cı́lem je předevšı́m odstranit nebezpečı́ kolizı́.
Celá komunikace s koncovými uzly je vždy řı́zena základnovou stanicı́, ta určuje, kdy kdo bude
vysı́lat, přiděluje kanály pro komunikaci.
Dalšı́ informace o WiMAX:
•
•
•
•
•
http://www.intelek.cz/art doc-29B0470BE0F689D6C125740C002F6883.html
http://www.wimax-industry.com/sp/wcm/avr/avrbm4.htm
http://access.feld.cvut.cz/view.php?cisloclanku=2008050005
http://www.wimax.cz/index.php?option=com content&task=view&id=233&Itemid=33
http://etutorials.org/Networking/wimax+technology+broadband+wireless+access/
6.4
MOBILNÍ TECHNOLOGIE
139
Part+Two+WiMAX+Physical+Layer/Chapter+5+Digital+Modulation+OFDM+and+
OFDMA/5.3+OFDMA+and+Its+Variant+SOFDMA/
6.4
Mobilnı́ technologie
Mobilnı́ sı́tě jsou předevšı́m charakteristické svou mobilitou, tedy stanice, která je součástı́ mobilnı́ sı́tě, se může pohybovat se zachovánı́m signálu. V této sekci se budeme zabývat předevšı́m
mobilnı́mi WAN, třebaže existujı́ řešenı́ i pro menšı́ sı́tě.
6.4.1
Prvnı́ generace (1G)
Prvnı́ generace mobilnı́ch datových sı́tı́ byla ještě analogová. Z toho důvodu se také využı́val
frekvenčnı́ multiplex (FDMA), každý připojený uživatel má přidělen jeden kanál, a to výhradně.
Prvnı́ komerčnı́ mobilnı́ systém byl NMT (Nordic Mobile Telephone) fungujı́cı́ nejdřı́v v Saudské Arábii a následně v severských zemı́ch (Norsko, Švédsko) od roku 1981. Do prvnı́ generace
také patřı́ americký AMPS (Analog Mobile Phone System) z roku 1982 a TACS (Total Access Communications System) vytvořený původně pro Velkou Británii, ale později se rozšı́řil předevšı́m
v Asii.
6.4.2
Druhá generace (2G)
Sı́tě druhé generace pořád pracujı́ na principu přepojovánı́ okruhů. Důsledkem je obvyklá tarifikace
odvozená od doby připojenı́ (jde o vytáčené připojenı́).
GSM. Na začátku 90. let (1992) vznikla druhá generace, která je dodnes funkčnı́ (vedle dalšı́ch
generacı́). Byl zaveden digitálnı́ přenos dat, ale sı́t’ je optimalizována předevšı́m pro hlas, tedy
propustnost je na velmi nı́zké úrovni.
Prvnı́m zástupcem této generace je systém GSM (Global System for Mobile Communications).
Přestože jde o digitálnı́ sı́t’, pořád využı́vá přepojovánı́ okruhů, a to s časovým (TDMA) i frekvenčnı́m (FDMA) multiplexem – kombinace TDMA over FDMA (časové sloty se přenášejı́ vždy v rámci
určité frekvence). GSM pracuje na třech různých frekvencı́ch, hovořı́me o GSM900 (frekvence 900
MHz), GSM1800 (1800 MHz) a GSM1900 (1900 MHz).
GSM sı́t’se skládá z buněk, každá buňka má svou základnovou stanici (base transceiver station).
Základnové stanice jsou napojeny na páteřnı́ sı́t’skládajı́cı́ se z těchto typů uzlů:
• BSC (Base Station Controller) – řı́dicı́ uzel základnových stanic, jeden BSC spravuje několik
základnových stanic (do počtu 9), komunikace se základnovými stanicemi může probı́hat na
některé rádiové frekvenci nebo s využitı́m kabelů (optických či metalických),
• MSC (Mobile Switching Center) – mobilnı́ ústředna, k nı́ je připojeno vı́ce BSC (obvykle
kabely), některé MSC sloužı́ jako brány do pozemnı́ telekomunikačnı́ sı́tě nebo jiné mobilnı́
sı́tě, každá MSC vede seznam připojených mobilnı́ch stanic (pokud stanice opustı́ oblast
spravovanou touto MSC, je jejı́ záznam vymazán)
P
6.4
MOBILNÍ TECHNOLOGIE
140
• dalšı́ podpůrné uzly sı́tě, napřı́klad autentizačnı́ databáze (informace o všech účastnı́cı́ch, kteřı́
mohou být připojeni do sı́tě), registr stanic (jsou zde uloženy identifikátory povolených stanic,
dále identifikátory, o kterých je známo, že byly ukradeny, a dále identifikátory porouchaných
stanic), SMS centrum, atd.
• operačnı́ a administrativnı́ subsystém (OSS, Operation SubSystem) – provádı́ administraci a údržbu
celé sı́tě, zajišt’uje registraci a tarifikaci, použı́vá registry a databáze z předchozı́ho bodu, nenı́
přı́mou součástı́ sı́tě.
Uzly MSC a dalšı́ podpůrné uzly sı́tě jsou hlavnı́ částı́ páteřnı́ sı́tě, která se souhrnně nazývá Network
Switching Subsystem (NSS).
Celou sı́t’tedy můžeme rozdělit do třı́ vrstev – vrstva základnových stanic s jejich řı́dicı́mi uzly,
vrstva NSS a vrstva OSS.
Základnové stanice jsou rozmı́stěny tak, aby se buňky (přibližně kruhové, i když jsou zobrazovány jako šestiúhelnı́ky – „plástve“) překrývaly. To však znamená, že dvojice buněk, které jsou
přı́mo vedle sebe, nesmı́ použı́vat tytéž komunikačnı́ kanály, tytéž kanály může použı́vat až buňka
natolik vzdálená, aby nedocházelo k inferencı́m. Rozdělenı́ kanálů se provádı́ metodou podobnou obarvovánı́, kterou známe z teorie grafů. Při plném pokrytı́ signálem je možná plná mobilita
stanice, handover – předávánı́ stanice mezi jednotlivými buňkami.
Oproti prvnı́ generaci je zde předevšı́m přechod na digitálnı́ technologii, dále většı́ odolnost proti
rušenı́ a odposlechu, snadné napojenı́ na pozemnı́ telekomunikačnı́ systémy, a také vyššı́ rychlost.
Teoretická rychlost je 13 kb/s pro každý směr, reálně 9.6 kb/s.
CDMA. Dalšı́ technologiı́, kterou můžeme zařadit do druhé generace, je CDMA (Code Division
Multiple Access). Ve specifikaci CDMA se sice počı́tá s přenosem dat i hlasu, ale u nás je CDMA
poskytována jen jako datová sı́t’. Oproti GSM má výhodu nižšı́ch frekvencı́ (450 MHz), základnové
stanice CDMA mohou být od sebe vı́ce vzdáleny. Teoretická rychlost uploadu je 1024 kb/s, té
však lze dosáhnout jen v mı́stech s výkonnějšı́mi základnovými stanicemi (napřı́klad v Praze nebo
v Brně). Download je o něco rychlejšı́ (až 3.1 Mb/s, v reálu také méně, několik set kb/s), jde
o asymetrický přenos.
P
CDMA použı́vá jiný typ multiplexu – kódový. Spočı́vá v tom, že v rámci jednoho sdı́leného média se přenášı́ vı́ce digitálnı́ch signálů, které jsou rozlišovány pomocı́ kódovánı́ (tedy ne rozdělenı́m
do časových slotů ani pouhým rozvrženı́m do frekvencı́).
6.4.3
Přechodová generace (2.5G)
Zatı́mco mobilnı́ sı́tě druhé generace byly založeny na přepı́nánı́ okruhů, v přechodové generaci
se již použı́vá přepı́nánı́ paketů, které je pro přenos dat výhodnějšı́. Typická tarifikace je bud’ za
přenesená data nebo paušál, netarifikuje se připojená doba (tj. nejedná se o vytáčené připojenı́).
GPRS. Prvnı́ mobilnı́ technologiı́ přechodové generace je GPRS (General Packet Radio Service).
Jedná se o nástavbu GSM (technicky ne nutně GSM, může být vázána na jiné typy sı́tı́), která
umožňuje jedné stanici využı́vat až 8 GSM kanálů (pokud jsou zrovna volné). Nejedná se ještě
o širokopásmovou technologii, ale dı́ky rozšı́řenı́ pásma až na 8násobek jsou přenosové rychlosti
P
6.4
MOBILNÍ TECHNOLOGIE
141
vyššı́. Jsou využı́vány ty z osmi GSM kanálů, které jsou právě volné, tedy přenosová kapacita sı́tě
je využı́vána účelněji, kanály nejsou blokovány po celou dobu „připojenı́“.
Aby fungovalo napojenı́ na GSM, bylo nutné do sı́tě GSM přidat ještě jednu vrstvu. Stanice
BSC dále zůstávajı́ napojeny na MSC, ale navı́c jsou napojeny na sı́t’ uzlů označovaných SGSN
(Serving GPRS Support Node) – podpůrných uzlů sı́tě GPRS (obdoba MSC ústředen), a dále
součástı́ přı́davné páteřnı́ sı́tě jsou uzly GGSN (Gateway GPRS Support Node) sloužı́cı́ jako brány
do datové paketové IP sı́tě. Uzly SGSN a GGSN mezi sebou komunikujı́ protokolem GTP (GPRS
Tunelling Protocol), což je aplikačnı́ protokol využı́vajı́cı́ protokoly TCP a UDP.
Uzly SGSN nesloužı́ pouze pro přenos, je zde implementována také správa páteřnı́ sı́tě a tarifikace. Z toho důvodu přistupujı́ také do specifických uzlů a databázı́ sı́tě GSM.
Přenosové rychlosti se odvozujı́ od použitého kódovánı́. Čı́m silnějšı́ kódovánı́, tı́m nižšı́ rychlost. Celková možná dosažená rychlost je 22.8 kb/s na jeden kanál, ale část rychlosti je pohlcena
režiı́ kódovánı́. Při nejsilnějšı́m kódovánı́ (CS-1) dosahujeme rychlosti maximálně kolem 9 kb/s na
kanál, při nejslabšı́m kódovánı́ (CS-4) maximálně kolem 21 kb/s na kanál. Volba kódovánı́ je zcela
automatická, závisı́ na vzdálenosti stanice od základnové stanice (čı́m dál je stanice, tı́m silnějšı́
musı́ být kódovánı́).
Dále je rychlost přenosu ovlivněna množstvı́m kanálů, které stanice může využı́vat (maximálně
8 pro každý směr). V základnı́m nastavenı́ musı́ uživatel GPRS vzı́t zavděk tı́m, co „zbude“ po
uživatelı́ch GSM hlasových přenosů, ale v některých typech tarifů se můžeme setkat s garancı́
určitého počtu kanálů (vyhrazenı́m pouze pro data).
GPRS zavádı́ základnı́ možnost řı́zenı́ kvality služeb (QoS) založenou na prioritě, propustnosti, zpožděnı́ nebo spolehlivosti. Je samozřejmě na operátorovi, zda bude QoS nabı́zet svým
zákaznı́kům.
EDGE. Technologie EDGE (Enhanced Data rates for GSM Evolution) je sice také nástavbou sı́tě
GSM a základnı́ princip je podobný, ale navı́c signál moduluje metodou 8-PSK, což v reálu znamená
až trojnásobný nárůst rychlostı́ oproti GPRS.
6.4.4
P
Třetı́ generace (3G)
Třetı́ generace přinášı́ možnost souběžného využı́vánı́ několika služeb (u předchozı́ch generacı́ nebylo
možné kombinovat hlas a data). Technologie jsou založeny na variantách metody CDMA, tedy
se použı́vá kódový multiplex. Narozdı́l od předchozı́ch generacı́, třetı́ generace již nenı́ striktně
optimalizována pro přenos hlasu, vı́ce se počı́tá s datovými přenosy.
UMTS. Vylepšenı́m GSM je technologie UMTS (Universal Mobile Telecommunication System).
Nejedná se o pouhou nástavbu, zavedenı́ UMTS znamenalo poměrně velké zásahy do infrastruktury sı́tě. V tomto typu sı́tě je také nabı́zena vylepšená QoS.
Základem je WCDMA (Wideband CDMA), což je širokopásmová metoda přenosu. V metodě
WCDMA má každý uživatel přiděleno frekvenčnı́ pásmo, které použı́vá. V kódovém multiplexu
může totéž pásmo využı́vat vı́ce uživatelů, jsou odlišeni jednoznačným binárnı́m kódem.
Architektura sı́tě je podobná sı́ti GPRS a zčásti na nı́ stavı́. Uzel s názvem Node B je obdobou
základnové stanice. Zprostředkovává komunikaci mezi koncovou stanicı́ a samotnou UMTS sı́tı́,
P
6.4
MOBILNÍ TECHNOLOGIE
142
zajišt’uje také modulaci, kódovánı́, ochranu proti chybám.
Dalšı́ vrstvu sı́tě tvořı́ řı́dicı́ jednotka rádiové sı́tě (RNC, Radio Network Controller), tyto jednotky jsou obdobou BSC v GSM. Stanice RNC tvořı́ dohromady vrstvu nazvanou UTRAN (UMTS
Terrestrial Radio Access Network). RNC majı́ za úkol řı́dit uzly Node B, přidělovat kanály, řı́dit
handover (předávánı́ mobilnı́ch stanic), šifrovat, atd.
Dalšı́ vrstvou je páteřnı́ sı́t’ (CN, Core Network). Součástı́ páteřnı́ sı́tě jsou obvykle uzly patřı́cı́ do
GSM/GPRS sı́tě, ale vyžadujı́ drobnějšı́ úpravy, aby dokázaly spolupracovat s UMTS sı́tı́. Páteřnı́
sı́t’ zajišt’uje navazovánı́ spojenı́, směrovánı́, vedenı́ provoznı́ch databázı́ a provoz bran do jiných
sı́tı́.
UMTS nenı́ u nás, ale ani v jiných zemı́ch, moc rozšı́řená. Vzhledem k nutným úpravám
infrastruktury se s UMTS typicky počı́tá pouze ve velkých městech. Teoretická rychlost je až 2
Mb/s, ve skutečnosti se však dosahuje pouze rychlosti několika desı́tek (mı́sty i stovek) kb/s.
HSDPA. Dalšı́ zvýšenı́ rychlosti a snı́ženı́ latence technologie UMTS přinášı́ HSDPA (High-Speed
Downlink Packet Access), jedná se tedy o jakési vylepšenı́ UMTS pro download (slovo „Downlink“
v názvu). Změny je docı́leno zvolenou modulacı́ – QPSK (Quadrature Phase Shift Keying, použı́vá
se i v UMTS) nebo 16QAM, a dále jinými mechanismy plánovánı́ vysı́lánı́ (plánovánı́ založené na
QoS) a řı́zenı́ chyb.
P
Stejně jako UMTS, také HSDPA použı́vá WCDMA, ale navı́c přidává nové mechanismy a nový
typ čistě datového kanálu. Zatı́mco v UMTS jsou pakety odesı́lány každých 10 ms, v HSDPA jsou
odesı́lány každé 2 ms. Pro zvýšenı́ propustnosti je také možné využı́t technologii MIMO.
Přenosové rychlosti jsou obecně vyššı́ než v přı́padě UMTS, v současné době kolem 1 Mb/s,
ovšem stejně jako u jiných mobilnı́ch sı́tı́ s velkými odchylkami v obou směrech. Existujı́ varianty
HSDPA, které dosáhnou až na 14 Mb/s, ale ty u nás nejsou implementovány.
HSUPA. Tato technologie je obdobou předchozı́, ale pro upload (High-Speed Uplink Packet
Access). Jejı́m účelem je tedy zvýšit rychlost a celkovou kvalitu (vč. latence) u uploadu.
Technologie HSDPA a HSUPA se souhrnně označujı́ HSPA, ale operátor nemusı́ nutně použı́t
obě (u nás O2 implementuje pouze UMTS/HSDPA).
6.4.5
P
Dalšı́ generace
Technologie FLASH-OFDM (Fast Low-latency Access with Seamless Handoff-Orthogonal Frequency-Division Multiplexing) je již řazena do čtvrté generace (4G), zákaznı́k je často seznámen
pouze se zkratkou 4G.
Ortogonálnı́ multiplex (OFDM) je znám již velmi dlouho. Ve variantě FLASH-OFDM znamená
propojenı́ OFDM s metodami CDMA a TDMA. Výsledkem jsou vyššı́ přenosové rychlosti (relativně, opět s rozptylem) a nı́zká latence. Rychlost se pohybuje i ve stovkách kb/s (download je
většinou v rozmezı́ 200–300 kb/s, třebaže se teoreticky udává až 1,5 Mb/s). Dalšı́ výhodou je pokročilá možnost řı́zenı́ kvality služeb (QoS). Dı́ky nı́zkým latencı́m a využitı́ QoS je na FLASH-OFDM
možné použı́vat IP telefonii.
LTE (Long Term Evolution) je zatı́m hudba budoucnosti (alespoň u nás, na některých mı́stech
ve světě už funguje). Cı́lem je dosáhnout velmi vysokých rychlostı́ (až 100 Mb/s na downstreamu,
P
P
6.4
MOBILNÍ TECHNOLOGIE
143
50 Mb/s na upstreamu) při velmi nı́zké latenci (10 ms). V současné době LTE reálně dosahuje na
downstreamu téměř 80 Mb/s.
Použitı́ variant CDMA se nepředpokládá, mı́sto nich se (alespoň na downstreamu) využı́vá
pouze některá varianta OFDM. Šı́řka kanálů nenı́ pevná, OFDM co nejefektivněji využı́vá pásmo
a použı́vá adaptivnı́ šı́řky signálů, které jsou naskládány tak blı́zko u sebe, jak jen dovoluje nutnost
je na druhém konci linky zase oddělit.
Prvnı́ varianta LTE ještě patřı́ do třetı́ generace (vpodstatě nástavba UMTS), až následujı́cı́
varianta, LTE Advanced, je řazena do čtvrté generace.
Dalšı́ informace o mobilnı́ch sı́tı́ch:
•
•
•
•
•
•
•
http://tomas.richtr.cz/mobil/index.htm
http://www.earchiv.cz/a008s200/a008s200.php3
http://rychlost.cz/pripojeni-internetu/
http://coverage.o2.position.cz/
http://www.t-mobile.cz/web/cz/residential/tarifysluzby/mapapokryticr
http://home.pf.jcu.cz/~pepe/Diplomky/velicky.pdf
http://access.feld.cvut.cz/search.php?rsvelikost=sab&rstext=all-phpRS-all&rstema=
10&stromhlmenu=10
Kapitola
7
Centralizovanost, decentralizovanost,
distribuce
V této poněkud netypicky nazvané kapitole rozvineme základnı́ kameny počı́tačových sı́tı́ – bridging, switching a routing. Podı́váme se na protokol STP a jeho varianty, virtuálnı́ sı́tě (VLAN), směrovacı́ algoritmy.
Dále se seznámı́me s páteřnı́ sı́tı́ CESNET2 a následuje téma kvality služeb (QoS). Poslednı́ sekce této kapitoly
je věnována typickému zástupci distribuovaných systémů – DNS, a typickému zástupci centralizovaných
systémů – Active Directory.
7.1
7.1.1
Pojmy
Typy systémů
Centralizovaný systém je systém s jedinou centrálnı́ řı́dicı́ jednotkou. Komunikace probı́há
obvykle ve formě klient-server, kde server je právě ta centrálnı́ řı́dicı́ jednotka.
V oblasti počı́tačových sı́tı́ můžeme k centralizovaným architekturám zařadit
P
• protokol RADIUS, kde centralizovanou jednotkou je RADIUS server, komunikujı́cı́ se svými
klienty (napřı́klad access pointy – přı́stupovými body bezdrátové sı́tě),
• protokol CMIP (Common Management Information Protocol), což je protokol z ISO/OSI určený pro správu sı́tě (obdoba SNMP).
Decentralizovaný systém má vı́ce řı́dicı́ch jednotek (serverových/správnı́ch uzlů), vı́ceméně
rovnocenných (s podobnými funkcemi). Účelem (a výhodou oproti centralizovaným systémům) je
zvýšenı́ robustnosti sı́tě (tutéž funkci poskytuje vı́ce „centrálnı́ch“ – serverových – uzlů, klientské
uzly mohou komunikovat s kterýmkoliv uzlem poskytujı́cı́m žádanou službu). Je možné snadno
vyřešit situaci, kdy jeden ze serverových uzlů přestane službu poskytovat (napřı́klad je odpojen
od sı́tě).
144
P
7.1
POJMY
145
Nevýhodou je náročnějšı́ implementace, protože serverové uzly musejı́ být synchronizovány
(předevšı́m jejich databáze).
V oblasti počı́tačových sı́tı́ se s decentralizovanou architekturou setkáme napřı́klad
• mnohé směrovacı́ protokoly jsou decentralizované,
• protokol SIP (Session Initiation Protocol), který se použı́vá napřı́klad u VoIP (obecně kdekoliv,
kde je nutné navazovat relace).
Samotný Internet byl původně decentralizovaný a do značné mı́ry to platı́ i dnes. Ale plná decentralizovanost by znamenala zachovánı́ běžného chodu systému (třeba i s určitým zpomalenı́m nebo
neposkytovánı́m některých služeb, které mohou „počkat“, nejsou časově kritické) i po odpojenı́
naprosté většiny serverových uzlů, což Internet nesplňuje.
Distribuovaný systém (známe z předmětu Operačnı́ systémy) je takový systém, jehož funkce
jsou distribuovány (rozděleny) na různé uzly sı́tě se zachovánı́m několika důležitých vlastnostı́.
Předevšı́m jde o vlastnost transparentnost. Napřı́klad přı́stupová transparentnost znamená, že
k lokálnı́m i vzdáleným prostředkům se přistupuje stejným způsobem, zde přes protokoly. Migračnı́
transparentnost znamená možnost přesouvánı́ poskytovaných služeb mezi různými uzly sı́tě bez
výraznějšı́ho vlivu na výkonnost sı́tě.
P
Dalšı́ důležitou vlastnostı́ distribuovaného systému je flexibilita. Tato vlastnost znamená přizpůsobivost systému změnám prostředı́ (včetně poruch a výpadků částı́ systému). To vylučuje
jakoukoliv centralizaci rozhodovánı́, každý uzel sı́tě musı́ být ve své činnosti co nejvı́c samostatný
a služby ostatnı́ch uzlů vyžaduje se zachovánı́m transparentnosti.
Flexibilnı́ systém může být jakkoliv rozšiřován (téměř – jsou technické hranice, které se jen
velmi nesnadno překračujı́) nebo naopak omezován, funkce odstraňovaného uzlu může plnit jiný
uzel.
S distribuovanostı́ se setkáváme u některých směrovacı́ch protokolů a dále napřı́klad v systému
DNS (obecně u doménových služeb).
7.1.2
Distribuované systémy
Distribuovaný systém může být určen architekturou klient-server, kdy je jednoznačně určeno, které
uzly jsou serverové (poskytujı́ služby, implementujı́ funkce) a které jsou klientské (využı́vajı́ služeb
serverů). Jiný způsob zavedenı́ distribuovaného systému je integrovaná architektura (symetrický
systém), kde každý uzel může být serverem i klientem, podle požadavků probı́hajı́cı́ komunikace.
Podle způsobu využı́vánı́ paměti můžeme distribuované systémy rozdělit na
• multiprocesory (multiprocessors) – uzly majı́ společnou pamět’(každý má svou vlastnı́ pamět’
a dále existuje pamět’sdı́lená, která může být také distribuována ve vı́ce uzlech),
• multipočı́tače (multicomputers) – uzly nesdı́lejı́ žádnou pamět’, adresové prostory jsou zcela
oddělené, tento koncept je u počı́tačových sı́tı́ obecně výhodnějšı́.
Podle způsobu propojenı́ (platı́ pro oba výše zmı́něné typy) rozlišujeme dva typy architektur:
7.2
BRIDGING
146
• sběrnicová architektura (bus) – využı́vá jediné sdı́lené médium (obvykle kabel), signál se šı́řı́
po celém médiu, napřı́klad kabelová televize,
• přepı́načová architektura (switch) – signál je přenášen vždy mezi dvěma konkrétnı́mi uzly (až
na výjimky jako je broadcast a multicast), může jı́t o různé topologie:
– hierarchická stromová struktura, mesh (varianty), kruh, atd.,
– mřı́žka – uzel je propojen se svými nejbližšı́mi sousedy, při ideálnı́m uspořádánı́ jsou ke
každému uzlu kromě okrajových 4 sousednı́ uzly,
– hyperkrychle.
Hyperkrychle je n-rozměrná krychle (v obvyklém přı́padě je n = 4) s uzly uspořádanými do vı́ce
rozměrů (vı́ceméně hierarchicky do liniı́, rovin, skupin, atd.). Uzel je přı́mo propojen se dvěma uzly
pro každý podporovaný rozměr, tedy je přı́mo propojen s celkem n ∗ 2 sousedy (u čtyřrozměrné
krychle s 8 sousedy). Celá struktura je z principu acyklická. Mřı́žku lze brát jako speciálnı́ přı́pad
(hyper)krychle pro n = 2.
Se sběrnicovou architekturou se už v distribuovaných sı́tı́ch moc nesetkáváme (až na přenosy
probı́hajı́cı́ po koaxiálu). V praxi je zřejmě nejběžnějšı́ propojenı́ multipočı́tačů v hierarchické struktuře.
Může dojı́t trochu ke „zmatenı́ pojmů“, protože v přepı́načové architektuře nemusı́me jako
mezilehlé prvky nutně použı́vat přepı́nače.
7.2
7.2.1
Bridging
Most
Most (bridge) je zařı́zenı́ (dnes spı́še jedna z funkcı́ komplexnějšı́ho zařı́zenı́), které pracuje na
linkové vrstvě (L2) podle modelu ISO/OSI. Jeho účelem je propojovánı́ segmentů sı́tě a filtrace
PDU podle informacı́ dostupných na linkové vrstvě, což je napřı́klad u lokálnı́ch sı́tı́ MAC adresa
(tedy PDU pustı́ jen na ten port, jehož MAC adresa patřı́ do daného segmentu).
Non-unicast komunikace (multicast a broadcast) je poslána na všechny porty a totéž platı́
o neznámé unicast adrese. Dalšı́m důležitým úkolem je odfiltrovánı́ poškozených PDU.
Rozlišujeme dva základnı́ typy použı́vánı́ mostů:
• transparent bridging (transparentnı́ přemostěnı́) – jedná se o „samoučı́cı́ “ mosty, které si postupně za provozu ve své paměti tvořı́ tabulku adres vrstvy L2 (podle zdrojových adres
v PDU) a podle této tabulky pak určujı́ segment sı́tě pro danou cı́lovou adresu vrstvy L2,
• source-route bridging (přemostěnı́ na cestu k cı́li) – součástı́ PDU je seznam mostů (přesněji
mezilehlých prvků sı́tě, které mohou sloužit jako mosty), přes které má cesta vést, tedy celá
cesta je předem naplánována.
Prvnı́ typ se typicky použı́vá předevšı́m u Ethernetu, druhý typ u Token Ring.
Existujı́ zařı́zenı́ kombinujı́cı́ oba principy, pak mohou sloužit k propojenı́ dvou lokálnı́ch sı́tı́,
z nichž každá je postavena na jiném standardu (heterogennı́ sı́t’; naopak homogennı́ sı́t’ je postavena
P
7.2
BRIDGING
147
na společném standardu, napřı́klad Ethernet). V heterogennı́ch sı́tı́ch se využı́vá předevšı́m toho,
že most může „vidět“ i na podvrstvu LLC, která nebývá součástı́ specifikace Ethernetu ani jiné
LAN.
Dále se budeme věnovat transparentnı́m mostům. Každý most tedy udržuje tabulku MAC adres
(v systému CatOS je nazývána tabulkou CAM – Content Addresable Memory, jinde je to prostě
tabulka MAC adres). Záznamy v tabulce majı́ jednoduchou formu – adresa L2 + port vedoucı́ k uzlu
s touto adresou, komunikace určená konkrétnı́ MAC adrese je posı́lána jen na port k nı́ vedoucı́.
P
Mosty mohou pracovat v lokálnı́ sı́ti a propojovat jejı́ segmenty, ale může jı́t také o propojenı́
vzdálených sı́tı́ (at’už homogennı́ch nebo heterogennı́ch) přes páteřnı́ sı́t’(WAN).
7.2.2
STP
Mosty sice oddělujı́ koliznı́ domény, ale, jak bylo výše uvedeno, propouštějı́ non-unicast komunikaci
na všechny porty. Jestliže v sı́ti existuje smyčka, může dojı́t k všesměrové bouři (broadcast storm)
a PDU „bloudı́“ pořád dokola mezi různými segmenty sı́tě. Důsledkem může být zahlcenı́, čemuž
je třeba předejı́t.
P
Jiným problémem v sı́ti se smyčkami jsou nesprávné aktualizace tabulky L2 adres. Podı́vejme se
na obrázek 7.1. Pokud stanice vyšle broadcast rámec, je jejı́ adresa uvedena jako zdrojová. Protože
tento rámec bloudı́ v cyklu, most A nejdřı́v správně určı́ port k této stanici, ale když později
tentýž rámec (se stejnou zdrojovou adresou) přijde od mostu B, bude předpokládat, že stanice byla
přemı́stěna a cesta k nı́ vede přes most B.
Stanice
Most B
Most A
Stanice
Most C
Most A
Most B
Most C
Obrázek 7.1: Sı́t’s mosty bez použitı́ STP a s použitı́m STP
STP (Spanning Tree Protocol – protokol kostry, IEEE 802.1D) umožňuje vytvořit a udržovat sı́t’
bez smyček. Mechanismus nenı́ určen jen pro mosty, ale obecně pro všechna zařı́zenı́ podporujı́cı́
funkci mostu (v praxi se nejčastěji setkáme s přepı́nači podporujı́cı́mi STP).
Sı́t’mostů udržovaná protokolem STP má formu stromu s jediným kořenem. STP detekuje smyčky
v sı́ti a odstraňuje je blokovánı́m některých portů v mostech, mezi jakýmikoliv dvěma mosty
(a obecně také uzly) v sı́ti existuje vždy právě jedna cesta.
Každý most v sı́ti má přiřazen svůj identifikátor ovlivňujı́cı́ pozici mostu ve stromové struktuře,
který se skládá z priority (2 oktety, standardně 0×8000, decimálně 32 768) a MAC adresy mostu.
Priorita je vlevo od adresy, a tedy jejı́ hodnota má hlavnı́ vliv na čı́selnou hodnotu celého ID. Priorita
proto ovlivňuje pozici mostu ve stromové struktuře (samozřejmě včetně fyzického propojenı́), ale
pokud na všech mostech necháme přednastavenou standardnı́ prioritu 0×8000, mosty jsou třı́děny
podle MAC adresy.
P
P
7.2
BRIDGING
148
Každý most v sı́ti, který podporuje STP, vysı́lá v pravidelných intervalech – 2 sekundy – rámce
označované BPDU (Bridge PDU). Tyto rámce sloužı́ k udržovánı́ a přı́padně aktualizaci stromové
struktury mostů. Součástı́ BPDU je kromě jiného ID kořenového mostu a ID vysı́lajı́cı́ho mostu.
STP postupně vybere kořenový most (root), což je most s nejvyššı́ prioritou. Dalšı́ mosty řadı́
pod kořenový most do stromové struktury podle fyzického propojenı́ mezi nimi. Dı́ky stromové
struktuře existuje mezi kterýmikoliv dvěma mosty právě jedna cesta. Pokud původně mezi dvěma
mosty existovalo vı́ce paralelnı́ch cest, pouze jedna z nich bude vybrána a všechny ostatnı́ budou
uzavřeny (přı́slušné porty se blokujı́).
P
P
Na obrázku 7.1 máme řešenı́ pro jednoduchou sı́t’ se třemi mosty. Most A byl vybrán jako
kořenový.
Při výběru vhodné cesty ke kořenovému uzlu z vı́ce různých cest se zohledňuje „cena“ cesty, jejı́
(ne)výhodnost. Cena cesty je určena přičtenı́m priorit všech mostů na cestě rámce BPDU k základnı́
ceně cesty a platı́, že čı́m nižšı́ cena, tı́m lepšı́ cesta. Důsledkem je přednost takové cesty, která
obsahuje co nejméně mostů a nejrůznějšı́ch „oklik“.
Zařazenı́ mostu do STP stromu. Obvykle platı́, že most podporujı́cı́ STP hned po své aktivaci
sám sebe považuje za kořenový most. Pokud však obdržı́ BPDU s ID kořenového mostu vyššı́m
než je jeho, zařadı́ se nı́že do stromové struktury (také podle ID mostu, který tento BPDU poslal).
Pokud chceme ovlivnit konkrétnı́ pozici mostu v STP sı́ti, měli bychom podle toho nakonfigurovat
priority (předevšı́m mostu, který chceme mı́t jako kořenový). Jestliže nastávajı́ s STP problémy,
bývá to obvykle právě z důvodu špatné (nebo i žádné) konfigurace priorit mostů.
Pro každý most je předevšı́m důležitá cesta ke kořenovému mostu. Port, který vede ke kořenovému mostu a zároveň určuje nejkratšı́ cestu (s nejnižšı́ cenou) ke kořenovému mostu, se nazývá
kořenový port. Ostatnı́ porty vedoucı́ ke kořenovému mostu představujı́ alternativnı́ cesty a musejı́
být proto blokovány.
Stavy portů. Normálnı́m stavem portu je stav předávánı́ (forwarding), kdy port zpracovává běžný
provoz, BPDU rámce i požadavky správy sı́tě. Jiné stavy jsou inicializace, naslouchánı́ (listening,
BPDU jsou přijı́mány i odesı́lány, ale běžný provoz ještě ne), zjišt’ovánı́ (learning, vytvářı́ se tabulka
MAC adres, BPDU jsou přijı́mány i odesı́lány, běžný provoz nenı́ odesı́lán), blokovánı́ a zakázaný
port.
Blokovaný port nenı́ ve skutečnosti vypnutý (napřı́klad přijı́má BPDU a funguje také z hlediska
správy sı́tě), ale nesmı́ předávat běžný provoz. Mohou existovat také zakázané porty (disabled),
které reagujı́ pouze na požadavky správy sı́tě.
RSTP (Rapid STP, původně IEEE 802.1w) je vylepšenı́m protokolu STP předevšı́m v rychlosti
rekonfigurace (tj. změny stromu při změně topologie sı́tě mostů či přepı́načů s podporou tohoto
protokolu). Zrychlenı́ je značné, protože sı́t’ s protokolem STP se rekonfiguruje (tj. konverguje)
v průměru za 30–50 s, při použitı́ RSTP jde o několik sekund, může i pod 1 s.
Důvodů zrychlenı́ je vı́ce, napřı́klad zatı́mco u STP je proces rekonfigurace vı́ceméně pasivnı́
(BPDU se posı́lajı́ pouze ve stanovených intervalech a rekonfigurace se „vleče“ po jednotlivých
mostech), u RSTP mosty (spı́še přepı́nače) aktivně spolupracujı́ na rekonfiguraci sı́tě (negociace,
spolupráce s okolnı́mi zařı́zenı́mi), při zjištěnı́ otevřenı́ dalšı́ho portu k sousedovi automaticky
zapnou forwarding.
$
P
P
7.3
SWITCHING
149
V novějšı́ch zařı́zenı́ch se už obvykle nesetkáme s původnı́m pomalejšı́m STP, ale spı́še s RSTP
nebo jinou variantou. Standard RSTP (IEEE 802.1w) byl přidán do IEEE 802.1D (což byl původně
STP).
MSTP (Multiple STP, také MST nebo MIST, IEEE 802.1s) je vylepšenı́ protokolu STP pro použitı́
v prostředı́ s VLAN (virtuálnı́ sı́tı́, viz dále) a pro přı́pad využitı́ záložnı́ch linek. Pracuje nad RSTP,
tedy je dostatečně rychlý.
A B C
A B C
A B C
P
A B C
A B C
A B C
Obrázek 7.2: Porovnánı́ protokolů STP a MSTP
Pokud bychom v prostředı́ s virtuálnı́mi sı́těmi použili pouze STP, pravděpodobně bychom
některé VLAN prakticky vyřadili z činnosti nebo bychom některé z linek zbytečně zatı́žili přı́liš.
A B
A B
A B C
A B C
A B C
A B C
Obrázek 7.3: Přerušená cesta pro jednu VLAN při použitı́ STP
MSTP umožňuje použı́t jednotlivé instance spanning tree pro každou VLAN nebo několik VLAN
zvlášt’. Součástı́ nastavenı́ MSTP je přiřazenı́ jednotlivých VLAN k definovaným instancı́m. Toto
je zřejmě nejnáročnějšı́ část konfigurace, měli bychom mı́t přehled (samozřejmě) o tom, na kterých
portech které VLAN komunikujı́ a také pokud možno o předpokládaném provozu mezi zařı́zenı́mi
v rámci jednotlivých VLAN.
Na obrázku 7.2 je sı́t’se třemi VLAN (zde pojmenovanými A, B a C). Při použitı́ protokolu STP
by VLAN byla funkčnı́, ale pokud předpokládáme vyššı́ zátěž při komunikaci v třetı́ VLAN, je
mnohem lepšı́ vytvořit dvě instance protokolu, jednu pro VLAN A a B, druhou pro VLAN C.
Dalšı́ informace o STP:
• http://www.cs.vsb.cz/grygarek/SPS/projekty0405/MST/mst.htm
• http://www.cisco-secure.com/en/US/docs/switches/lan/catalyst3550/software/release/12.1 13 ea1/configuration/guide/swmstp.pdf
• http://www.s3.kth.se/lcn/courses/2E1623/pdf/STP.pdf
• http://www.samuraj-cz.com/clanek/cisco-ios-10-rapid-spanning-tree-protocol/
7.4
ROUTING
7.3
150
Switching
Přepı́nač (switch) můžeme brát jako most, který má vı́ce než dva porty, navı́c přepı́nače mohou
podporovat virtuálnı́ lokálnı́ sı́tě (VLAN). Přepı́nače také pracujı́ na vrstvě L2 (nebo i vyššı́ch
vrstvách). Rozlišujeme vı́ce typů přepı́načů:
• ethernetový přepı́nač – pracuje v sı́tı́ch Ethernet (IEEE 802.3), a to na vrstvě L2, sloužı́ k oddělenı́ koliznı́ch domén a je nezbytnou podmı́nkou implementace plného duplexu,
• přepı́nač vrstvy 3 (L3) – přepı́nač umožňujı́cı́ směrovánı́, v současné době se spı́še setkáme
se zařı́zenı́mi z následujı́cı́ skupiny plnı́cı́mi také roli přepı́nače L3,
• vı́cevrstvý přepı́nač – pracuje na vı́ce vrstvách, obecně L2, L3 a dále alespoň L4 (řı́dı́ provoz
také podle informacı́ v záhlavı́ch TCP a UDP paketů, přı́padně i PDU vyššı́ch vrstev),
• přepı́nač některé WAN nebo MAN sı́tě (napřı́klad sı́tě Frame-Relay).
Lokálnı́ přepı́nače narozdı́l od mostů obvykle propojujı́ pouze homogennı́ sı́tě, nanejvýš se odlišujı́
různými rychlostmi (napřı́klad Fast Ethernet a 1G Ethernet). Typy přepı́nánı́:
1. Store and Forward (ulož a pošli) – přı́chozı́ rámec je nejdřı́v celý přijat a uložen do vyrovnávacı́
paměti přepı́nače, až po přijetı́ celého rámce je přečteno záhlavı́ a určen výstupnı́ port pro
odeslánı́ rámce. Dokáže odchytávat chybné rámce, ale velmi pomalý, vhodné pro sı́tě s vyššı́
chybovostı́.
P
2. Cut-Through (průběžné zpracovánı́, také on-the-fly) – přı́chozı́ rámec se začı́ná odesı́lat průběžně ještě během svého přı́jmu, hned po načtenı́ informacı́ ze záhlavı́ potřebných k určenı́
výstupnı́ho portu. Velmi rychlé přepı́nánı́, menšı́ potřeba cache, ale nedokáže odchytávat
chybné rámce.
3. Fragment Free (s omezenı́m malých rámců) – něco mezi prvnı́mi dvěma metodami. Zpracovávánı́ rámce začne po načtenı́ jeho prvnı́ch 64 oktetů (tj. záhlavı́ a alespoň část dat). Účelem
je odhalenı́ alespoň jednoho typu chybných rámců, nepovolených přı́liš krátkých rámců.
Jak bylo výše řečeno, přepı́nače obvykle podporujı́ VLAN. V tabulce MAC adres obvykle najdeme
k cestě do konkrétnı́ho uzlu tyto údaje:
•
•
•
•
•
čı́slo VLAN, do které patřı́,
MAC adresa,
údaj, zda byla adresa do tabulky přidána dynamicky nebo ručně (statická),
počet sekund od zařazenı́ adresy do tabulky (přı́p. od poslednı́ změny tohoto záznamu),
označenı́ portu, na který se má rámec s touto adresou jako cı́lovou odeslat.
7.4
Routing
7.4.1
Směrovač
Zatı́mco přepı́nače pracujı́ v adresami plochého (flat) adresového prostoru, směrovače (routery)
pracujı́ s hierarchickými adresami (obvykle IP) a majı́ vestavěnou logiku umožňujı́cı́ rozhodovat
o průběhu směrovánı́. Směrovač pracuje na vrstvě L3 (sı́t’ové) v ISO/OSI modelu.
P
7.4
ROUTING
151
Také směrovač provádı́ vnitřnı́ přepı́nánı́ (v trochu jiném smyslu slova) PDU (obvykle IP datagramu), ale mezi směrovačem a přepı́načem jsou poměrně velké rozdı́ly:
• směrovacı́ tabulka obsahuje informace o dostupných sı́tı́ch a podsı́tı́ch (použı́vajı́ se prefixy),
nikoliv adresy konkrétnı́ch uzlů, tedy směrovacı́ tabulka je obecně menšı́ než tabulka MAC
adres mostu či přepı́nače,
P
• v směrovacı́ tabulce najdeme u každého záznamu port, na který má být PDU nasměrován,
a dále metriku určujı́cı́ náročnost (délku, cenu) cesty,
• na všeobecnou (broadcast) adresu reaguje směrovač přesně opačně než přepı́nač – broadcast
nepropustı́ na žádný port (občas je nutné toto chovánı́ obejı́t, ale na druhou stranu nenı́ nutné
použı́vat protokoly typu STP),
• stejně reaguje na neznámou unicast adresu – nepustı́ ji na žádný port a datagram je bud’
zničen nebo nasměrován k implicitnı́ sı́ti (sběrná sı́t’), kde lze na přı́padný zbloudilý datagram
reagovat.
Směrovače se zajı́majı́ i o dalšı́ informace ze záhlavı́ paketu než jen o adresy. Předevšı́m je důležité
pole s hodnotou TTL (Time-to-Live), se kterým jsme se seznámili u protokolu IP. Směrovač snižuje
hodnotu tohoto pole vždy nejméně o 1, reakce při nalezenı́ datagramu s TTL=0 je popsána v sekci
o protokolu IP (je doručen jen tehdy, když cı́lová sı́t’je přı́mo připojena k tomuto směrovači).
Směrovač dále kontroluje celkovou délku datagramu a když tato délka překračuje velikost
povolenou pro daný výstupnı́ port, datagram je fragmentován (pokud je to v záhlavı́ IPv4 povoleno),
IPv6 datagramy nelze fragmentovat.
Směrovače navzájem komunikujı́, navzájem se informujı́ o momentálnı́ situaci v sı́ti a přı́padných změnách a problémech. Každý směrovač si udržuje (ve své směrovacı́ tabulce) informaci
o logickém uspořádánı́ sı́tě (topologii). Konvergence sı́tě je takový stav sı́tě, kde všechny směrovače
majı́ stejnou představu o topologii sı́tě. Pokud dojde k výpadku některé cesty v sı́ti včetně výpadku
některého směrovače, stav konvergence je porušen a směrovače se navzájem informujı́ o potřebné
aktualizaci směrovacı́ch tabulek, což vede k opětovnému přechodu do stavu konvergence.
Na směrovačı́ch se může použı́vat jednoduchá metoda řı́zenı́ propustnosti sı́tě nazvaná Token
Bucket. Pracuje na principu virtuálnı́ho koše (bucket), do kterého jsou konstantnı́ rychlostı́ neustále doplňovány tokeny („povolenky“). Pokud přeteče, tokeny jsou zahazovány. Jeden token
představuje určité množstvı́ odesı́laných dat (třeba jeden oktet).
P
P
P
Velikost paketu, který má být odeslán, je porovnána s množstvı́m odpovı́dajı́cı́ch tokenů v Token
Bucketu. Pokud dostačuje, odstranı́ se z Bucketu potřebné množstvı́ tokenů a paket může být
odeslán. Jestliže však nedostačuje, paket bude zahozen.
7.4.2
Směrovánı́
Směrovat lze bud’ staticky nebo dynamicky. Statické směrovánı́ znamená určenı́ cesty k danému
cı́li ručně administrátorem, dynamické směrovánı́ znamená využitı́ směrovacı́ho algoritmu k určenı́
nejvhodnějšı́ cesty k cı́li. Statické směrovánı́ nevyžaduje použitı́ směrovacı́ho algoritmu, proto je
rychlejšı́, ale na druhou stranu při změně topologie sı́tě může nastat situace, kdy nelze data doručit
a je nutné ručně změnit údaje v tabulkách.
Statické směrovánı́ se použı́vá tam, kde tak jako tak existuje jediná cesta (point-to-point spoj,
směrovacı́ algoritmus by jen zdržoval přenos) nebo tam, kde (třeba z bezpečnostnı́ch důvodů
P
7.4
ROUTING
152
nebo pro urychlenı́) administrátor chce cestu určit explicitně. Statické a dynamické směrovánı́ lze
kombinovat, kdy jedna z možnostı́ sloužı́ jako záloha. Obvykle jsou údaje ze statického směrovánı́
upřednostňovány jako důvěryhodnějšı́, ale toto nastavenı́ lze na mnoha směrovačı́ch obrátit.
Při dynamickém směrovánı́ se hledá nejoptimálnějšı́ cesta k cı́li (může jı́t o suboptimálnı́ cestu).
Každá cesta má přiřazenu metriku podle jednoho nebo vı́ce kritériı́. Lze použı́t napřı́klad tato
kritéria:
P
• počet směrovačů na cestě (skoků, hop count) – nejlepšı́ cesta obsahuje nejméně směrovačů,
• propustnost přenosové cesty (kb/s, Mb/s, apod.) – čı́m rychleji lze data přenést, tı́m je cesta
lepšı́,
• zpožděnı́ (latence, v ms) – nejlepšı́ cesta je ta, která znamená nejmenšı́ celkové zpožděnı́,
• spolehlivost (pravděpodobnost doručenı́ dat) – nejlepšı́ cesta je ta, kde je nejvyššı́ pravděpodobnost doručenı́ dat (bez chyb, bez častého zahazovánı́ datových jednotek),
• maximálnı́ délka přenosové jednotky (MTU) – nejlepšı́ cesta je ta, kde lze přenášet dostatečně
velké přenosové jednotky a nehrozı́ nutnost fragmentace na cestě,
• zátěž – zohledňuje se momentálnı́ nebo běžné zatı́ženı́ daného přenosového prostředku, které
může mı́t vliv na zpožděnı́ doručenı́.
Metrika může záviset na vı́ce než jednom kritériu.
Nejen metrika je důležitá při hodnocenı́ cesty. Velmi důležitým kritériem je také zdroj směrovacı́
informace, informace z důvěryhodnějšı́ho zdroje je upřednostněna, i když má o něco horšı́ metriku.
Původně byly cesty ve směrovačı́ch popisovány adresou sı́tě a maskou podsı́tě. Současné směrovače majı́ cesty popsány adresou sı́tě a délkou prefixu. Pokud v tabulce existujı́ dvě cesty k témuž
cı́li, obvykle se upřednostnı́ ta, která má většı́ délku prefixu (tj. je přesnějšı́, most specific). Napřı́klad pokud máme údaje
10.160.0.0/12
10.160.0.0/17
druhý údaj bude upřednostněn. Jde o dva různé záznamy, protože se lišı́ v délce prefixu, třebaže
adresa v obou přı́padech vypadá jako stejná. Druhá adresa zřejmě bude podsı́tı́ sı́tě určené prvnı́
adresou (nebo hlouběji v hierarchii).
Pokud ve směrovacı́ tabulce nenı́ nalezena žádná cesta, je bud’ paket předán bráně (geteway),
protože paket zřejmě patřı́ do jiné sı́tě, nebo zahozen (když žádná brána nenı́ dostupná).
7.4.3
$
Směrovacı́ algoritmy a protokoly
Rozlišujeme protokoly směrovatelné (routed) a směrovacı́ (routing). Směrovatelné protokoly (napřı́klad IP) pracujı́ na sı́t’ové vrstvě, ale vlastnı́ směrovánı́ neprovádějı́, to je záležitostı́ směrovacı́ch
protokolů.
Autonomnı́ systém (podle terminologie EIGRP) je skupina směrovačů spadajı́cı́ch pod stejnou
správu (firmy, organizace apod.). Jiné protokoly mohou použı́vat jiné názvoslovı́, napřı́klad u OSPF
se nazývá proces. Autonomnı́ systém je identifikován 16bitovým čı́slem ASN, proces zase PID.
P
P
7.4
ROUTING
153
Směrovacı́ protokoly pracujı́cı́ vždy jen uvnitř jednoho autonomnı́ho systému se nazývajı́ vnitřnı́
směrovacı́ protokoly (interior, internal), směrovacı́ protokoly sloužı́cı́ ke směrovánı́ mezi různými
autonomnı́mi systémy (a tedy mezi různými vnitřnı́mi směrovacı́mi protokoly) jsou vnějšı́ směrovacı́
protokoly (exterior, external).
P
Směrovače mohou pracovat jen s jednı́m směrovacı́m protokolem, ale existujı́ také multiprotokolové směrovače, které komunikujı́ s vı́ce různými směrovacı́mi protokoly. Pro každý podporovaný
směrovacı́ protokol existuje (nejméně) jedna směrovacı́ tabulka a v každé bývá pro požadovanou
cestu uvedena metrika.
P
V jednoprotokolovém směrovači se směrovánı́ řı́dı́ metrikami cest v (jedné) směrovacı́ tabulce.
V multiprotokolovém směrovači je třeba navı́c rozhodnout mezi cestami v různých tabulkách,
které jsou vytvářeny podle různých kritériı́ a tedy tak jak jsou, nebývajı́ navzájem porovnatelné.
Z toho důvodu byla pro každý protokol stanovena přepočı́tavacı́ konstanta nazvaná administrativnı́
vzdálenost (administrative distance) umožňujı́cı́ porovnat vı́ce cest k témuž cı́li ze směrovacı́ch
tabulek různých protokolů. Administrativnı́ vzdálenosti jsou v tabulce 7.1. Všimněte si rozdı́lů
u protokolů, které mohou pracovat jako vnitřnı́ i vnějšı́ (napřı́klad BGP).
Typ cesty
P
Administrativnı́ vzdálenost
Připojené rozhranı́
Statické směrovánı́
EIGRP summary route (souhrnné cesty pro skupinu sı́tı́)
External BGP
Internal EIGRP
IGRP
OSPF
IS-IS
RIP
EGP
ODR (On Demand Routing)
External EIGRP
Internal BGP
jiný (neznámý)
0
1
5
20
90
100
110
115
120
140
160
170
200
255
Tabulka 7.1: Administrativnı́ vzdálenosti směrovacı́ch protokolů
Cesta zjištěná v rámci běžného směrovánı́ je internı́, cesta zjištěná vně směrovacı́ho procesu
(z jiné autonomnı́ oblasti) je externı́. Většina protokolů upřednostňuje internı́ cesty (tj. využı́vajı́
administrativnı́ vzdálenost), ale napřı́klad u BGP je to naopak a jiné jejich spolehlivost nerozlišujı́
(napřı́klad OSPF).
Směrovacı́ algoritmy jsou algoritmy použı́vané při řı́zenı́ směrovánı́. Můžeme je rozdělit do
dvou skupin:
• algoritmus vektorů vzdálenostı́ (distance vector),
• algoritmus stavu spoje (link state).
P
7.4
ROUTING
154
Algoritmus vektorů vzdálenostı́. Směrovač má nejdřı́v ve své tabulce pouze údaje o přı́mo připojených sı́tı́ch (ty majı́ metriku 0) a postupně přidává údaje podle zpráv od sousednı́ch směrovačů.
Ve zprávách od sousedů jsou seznamy vektorů „(cı́l, vzdálenost)“, kde prvnı́ údaj je adresa dosažitelného cı́le a druhý údaj je vzdálenost (metrika). Algoritmus zvětšı́ vzdálenosti o stanovenou
konstantu, většinou o 1 (to znamená o vzdálenost k sousedovi, který zprávu poslal), a porovná
s údaji, které už v tabulce má. Nové záznamy přidá, a pokud už daný cı́l v jeho tabulce existuje,
porovná metriky a přı́padně dalšı́ údaje a rozhodne, zda směrovacı́ informaci o tomto cı́li změnı́.
Tyto zprávy si směrovače vyměňujı́ v pravidelných intervalech (obvykle 30–90 s) formou broadcastu nebo multicastu a posı́lá se vždy celá směrovacı́ tabulka (vždy jen mezi sousedy). To znamená
většı́ zátěž sı́tě, ale zato jednoduššı́ počátečnı́ konfiguraci (administrátor přidává pouze záznamy
o přı́mo připojených sı́tı́ch).
Pro tento algoritmus je typické, že směrovače nemajı́ přehled o celé topologii sı́tě, znajı́ jen své
sousedy. Podle informacı́ od svých sousedů určujı́, na který port odeslat pakety pro daný cı́l. Jednou
z nevýhod z toho plynoucı́ch je náchylnost k zacyklenı́ paketů zejména v přı́padě nedostupnosti
cı́le (některé směrovače majı́ chybné informace a předávajı́ je dále).
Tento problém se obvykle řešı́ omezenı́m délky cesty (TTL, obvykle 15 nebo 255) a pak dalšı́mi
postupy, které jsou součástı́ směrovacı́ho algoritmu. Napřı́klad pokud směrovač obdržı́ informaci
o nedostupnosti sı́tě, pak po stanovenou dobu (hold-down timer, většinou trojnásobek intervalu
zası́lánı́ zpráv sousedům) ignoruje zprávy o cestě do této sı́tě, považuje je za potenciálně chybné.
Poison reverse (otrávenı́ cesty zpět) je oznámenı́ směrovače o své nedostupnosti. Tento směrovač odešle svým sousedům aktualizaci cesty k sobě s hodnotou metriky max(T T L) a sousedi si
k tomu ještě přičtou 1, tj. napřı́klad u RIPv1 to bude hodnota 16 nebo u jiných protokolů hodnota 256. Metrika většı́ než maximálnı́ stanovená označuje „nedosažitelnou“ cestu a tedy na port
k odpojovanému směrovači nebudou zası́lány žádné pakety.
P
P
P
Dalšı́ možnost je postup split horizon (rozložený horizont). Směrovač neodesı́lá jinému směrovači
celou svou tabulku, ale jen ty záznamy, které nevedou k tomuto směrovači (nenı́ třeba informovat
jiný směrovač o tom, o čem původně informoval on). Takto se snižuje nebezpečı́ zacyklenı́ a zası́lánı́
chybných informacı́.
Protokoly využı́vajı́cı́ algoritmus vektorů vzdálenostı́:
• RIP (Routing Information Protocol) varianty pro IP, IPX, atd.
• IGRP (Interior Gateway Protocol) pro IP
Algoritmus stavu spoje. Účelem je co nejrychlejšı́ konvergence, aby všechny směrovače měly
vždy co nejaktuálnějšı́ informace. K aktualizacı́m směrovacı́ch tabulek nedocházı́ v pravidelných
intervalech, ale vždy po jakékoliv změně v topologii sı́tě. Každý směrovač pravidelně testuje stav
spojenı́ k sousednı́m směrovačům (pakety LSP – Link State Packet) a pokud zjistı́ nedostupnost svého
souseda, předá tuto informaci dále (nejen svým sousedům, ale všem dostupným směrovačům, na
skupinovou adresu skupiny směrovačů použı́vajı́cı́ch daný protokol).
Směrovač po svém zapnutı́ nejdřı́v analyzuje informace, které obdržı́, a buduje si mapu sı́tě –
topologickou databázi. Pak spustı́ výpočet nejkratšı́ cesty do různých cı́lů modifikovaným Dijkstrovým algoritmem Shortest-Path-First (SPF), výpočet probı́há při každé změně topologie sı́tě. Podle
výsledku si vytvořı́ směrovacı́ tabulku.
P
P
7.4
ROUTING
155
Výhodou tohoto typu algoritmu je nižšı́ zatı́ženı́ sı́tě služebnı́mi informacemi a také velmi
rychlá konvergence sı́tě, nevýhodou jsou vyššı́ nároky na směrovač. Popsané výhody jsou důležité
zejména ve většı́ch sı́tı́ch.
Protokoly využı́vajı́cı́ algoritmus stavu spoje:
• OSPF (Open Shortest Path First)
• IS-IS (Intermediate System to Intermediate System), Integrated IS-IS (IIS-IS)
7.4.4
RIP
RIP (Routing Information Protocol) je jednı́m z nejstaršı́ch směrovacı́ch protokolů, byl vyvinut
firmou Xerox r. 1981. Jedná se o vnitřnı́ směrovacı́ protokol komunikujı́cı́ na portu 520 (využı́vá
protokol UDP). Jako metrika se použı́vá počet směrovačů na cestě k cı́li. Nejvyššı́ akceptovaná metrika u RIPv1 (verze 1) je 15, čı́slo 16 již označuje nedostupnou sı́t’. V intervalech 30 s je všesměrově
(broadcast) vysı́lána směrovacı́ informace, což ve velkých sı́tı́ch může značně snižovat propustnost
sı́tě.
RIP je protokol využı́vajı́cı́ třı́dy adres (nepodporuje beztřı́dnı́ směrovánı́), to znamená, že
součástı́ směrovacı́ch informacı́ nenı́ maska podsı́tě ani délka prefixu. To je dalšı́ nevýhoda, která
RIPv1 prakticky vylučuje z velkých sı́tı́.
P
L
Přı́klad
Adresy sı́tı́
10.10.22.0/24
10.20.10.0/24
by byly považovány za stejnou sı́t’, protože RIP směrovač by obě adresy považoval za adresu třı́dy
A, kde je sı́t’určena prvnı́m oktetem. Pokud k těmto sı́tı́m vede cesta přes různé směrovače, nebude
směrovánı́ probı́hat správně (jeden údaj bude přepsán druhým, jedna ze sı́tı́ nebude dostupná).
RIPv2 je aktualizacı́ protokolu RIP z poloviny 90. let 20. stoletı́. Hlavnı́m úkolem bylo zohledněnı́
využı́vánı́ prefixů a beztřı́dnı́ho směrovánı́ (VLSM a CIDR). Funkčnost je podobná, ale narozdı́l od
RIPv1
• lze použı́vat beztřı́dnı́ směrovánı́,
• max. počet přeskoků nenı́ 15, ale 255 (tedy počet směrovačů v sı́ti nenı́ omezen na 15),
• aktualizace směrovacı́ch informacı́ se neposı́lajı́ jako broadcast zprávy, ale jako multicast
zprávy na adresu 224.0.0.9, v přı́padě známých sousedů jako unicast pakety,
• podpora ověřovánı́ mezi dvěma směrovači.
U obou verzı́ RIP je metrika považována za nepřı́liš kvalitnı́, tedy použitelnost je pouze v malých
sı́tı́ch, kde to moc nevadı́.
P
7.4
ROUTING
7.4.5
156
IGRP a EIGRP
IGRP (Interior Gateway Routing Protocol) je protokol firmy Cisco s čı́slem 88. Jde o algoritmus
vektoru vzdálenostı́ (s tı́m souvisı́ pomalejšı́ konvergence sı́tě), který má obecně lepšı́ vlastnosti
než RIP, alespoň co se týče metriky. Součástı́ konfigurace protokolu je čı́slo autonomnı́ho systému
(tudı́ž je slučitelný s jinými směrovacı́mi protokoly na jednom zařı́zenı́).
P
Směrovacı́ informace se posı́lajı́ každých 90 s, a to broadcastem. Metrika je vı́cekriteriálnı́,
využı́vá se kombinace kritériı́
•
•
•
•
zpožděnı́ v sı́ti (prodleva) za předpokladu nezatı́žené sı́tě v ms,
propustnost v b/s,
zatı́ženı́ sı́tě, hodnota 255 znamená 100% zatı́ženı́,
spolehlivost cesty, hodnota 255 znamená 100% spolehlivost.
Prvnı́ dvě kritéria jsou povinná (dajı́ se odvodit z topologie sı́tě), dalšı́ dvě kritéria jsou nepovinná
(lze je odvodit z momentálnı́ho provozu). Při výpočtu metriky se postupuje podle zvoleného typu
služby (obdoba QoS), hodnoty jednotlivých kritériı́ jsou násobeny konstantami specifickými pro
daný typ služby (napřı́klad může být upřednostněna propustnost sı́tě).
Dalšı́ kritéria sice nejsou využı́vána při výpočtu metriky, ale přesto jsou součástı́ směrovacı́ch
informacı́ – počet směrovačů na cestě a MTU.
EIGRP (Enhanced IGRP) je vylepšenı́ protokolu IGRP. Algoritmus směrovánı́ podle tohoto protokolu již nenı́ čistě algoritmem vektoru vzdálenostı́, objevujı́ se některé prvky algoritmu stavu
spoje (jde o hybridnı́ protokol). Metrika je opět vypočı́távána z propustnosti a zpožděnı́ v sı́ti, je
možné přidat kritéria zatı́ženı́ sı́tě a spolehlivosti, ale obvykle se to nedělá.
P
EIGRP si udržuje tři tabulky – sousedů, topologie a směrovánı́. Tabulky jsou aktualizovány při
změnách v topologii, a to multicast zprávami.
Na jednom směrovači může běžet vı́ce instancı́ protokolu (E)IGRP, protože součástı́ konfigurace
je čı́slo autonomnı́ oblasti ASN.
7.4.6
OSPF
OSPF (Open Shortest Path First) použı́vá algoritmus stavu spoje (čı́slo protokolu 89), což znamená
rychlou konvergenci sı́tě při každé změně topologie. Jde o otevřený protokol (narozdı́l od IGRP
a EIGRP, které byly vyvinuty firmou Cisco), a proto se s nı́m setkáme na zařı́zenı́ch od mnoha
různých výrobců.
Jde o beztřı́dnı́ směrovánı́, proto nestačı́ pouze informace o adrese, musı́me zadat i délku
prefixu, a to inverznı́ maskou (v bitové podobě bychom invertovali masku takovou, kterou známe
z kapitoly o protokolu IP).
Směrovacı́ informace se zası́lajı́ okamžitě po změně topologie nebo minimálně každých 30 minut. Každý směrovač si udržuje topologickou databázi sı́tě (ve skutečnosti ne celé sı́tě). Topologická
databáze má formu orientovaného grafu s tı́m, že jedna cesta může mı́t v každém směru přiřazenu
jinou metriku.
P
7.4
ROUTING
157
Metrika je označována pojmem cena. Cena je kombinacı́ vı́ce kritériı́ – propustnostı́ sı́tě, náklady
na spoje, atd., podle konfigurace, většinou se volı́ pouze výpočet z kritéria propustnosti sı́tě. Čı́slo
100 000 000 vydělı́me šı́řkou pásma v b/s, tedy napřı́klad 100 Mb/s má cenu 1, 1.2 Mb/s má cenu
84, apod. Pokud je rozhranı́ rychlejšı́ než 100 Mb/s, standardně má také cenu 1 (zaokrouhlujeme
nahoru). Této nesrovnalosti se předcházı́ změnou vzorce v konfiguraci (změna referenčnı́ šı́řky
pásma). Napřı́klad posloupnost přı́kazů
P
router ospf 100
auto-cost reference-bandwidth 1000
v OSPF s čı́slem autonomnı́ho systému 100 změnı́ referenčnı́ šı́řku pásma na 1000 kb/s, tedy ve
vzorci bychom použili čı́slo 1 000 000 000 (to je třeba provést ve všech směrovačı́ch, abychom si
nevyrobili nestabilnı́ sı́t’s nepředvı́datelným chovánı́m).
Cena celé cesty je součtem cen pro jednotlivé úseky cesty.
OSPF podporuje hierarchické směrovánı́. To znamená, že směrovače (a jejich sı́tě) lze v rámci
autonomnı́ oblasti rozdělit do oblastı́ (area). Každý směrovač si udržuje pouze topologickou bázi
své oblasti, ostatnı́ oblasti mu zůstávajı́ skryty a aktualizace při změnách topologie se omezuje jen
na danou oblast. Rozlišujeme vnitřnı́ směrovače (uvnitř některé oblasti), hraničnı́ směrovače oblasti
(v několika oblastech – ABR, Area Border Router) a hraničnı́ směrovače autonomnı́ho systému (zprostředkovávajı́ komunikaci mezi různými autonomnı́mi systémy, včetně těch s jinými směrovacı́mi
protokoly).
P
Páteřnı́ sı́t’ mezi směrovači je označována jako oblast 0, směrovače v páteřnı́ sı́ti jsou páteřnı́
směrovače. Páteřnı́ sı́t’může být i WAN. V rozsáhlejšı́ch sı́tı́ch by vždy měla být páteřnı́ sı́t’a všechny
„nenulové“ oblasti by měly sousedit pouze s oblastı́ 0.
Součástı́ směrovacı́ tabulky jsou samozřejmě také prefixy adres sı́tı́. Podobně jako mnohé dalšı́
protokoly, také OSPF použı́vá sumarizaci směrovacı́ch informacı́. Týká se to předevšı́m směrovánı́
na hraničnı́ch směrovačı́ch, které by měly adresy v oblasti směrovat souhrnně, čı́mž se urychluje
směrovánı́ paketů na hranicı́ch oblastı́.
V lokálnı́ch sı́tı́ch (obecně v sı́tı́ch s všesměrovým vysı́lánı́m) musı́ existovat jeden pověřený
směrovač (Designated Router), který řı́dı́ veškerou aktualizaci směrovacı́ch informacı́ v sı́ti. Pro
přı́pad, že by pověřený směrovač selhal, by měl existovat záložnı́ pověřený směrovač. Pověřený
směrovač provádı́ výpočet cest a tı́m snı́má část zátěže z ostatnı́ch směrovačů v oblasti. Výběr
pověřeného směrovače sice lze nechat na protokolu OSPF, ale lepšı́ je provést to ručně, protože
automatický výběr nedopadne vždy zrovna ideálně. Ručnı́ výběr pověřeného směrovače se provádı́
přiřazenı́m priority (hodnota v rozsahu 0–255), vybereme obvykle nejvýkonnějšı́ směrovač nebo
hlavnı́ směrovač (resp. nejlépe obojı́ dohromady v jednom zařı́zenı́).
Z dalšı́ch důležitých vlastnostı́ protokolu OSPF:
• podpora rozloženı́ provozu k cı́li mezi cesty se stejnou celkovou cenou (ale bud’ všechny pakety
se stejnou cı́lovou – finálnı́ – IP adresou jdou stejnou cestou),
• podpora směrovánı́ podle typu služeb (ToS) IP,
• mechanismus ověřovánı́ autenticity paketů se směrovacı́ informacı́.
OSPF je vhodný zejména pro většı́ IP sı́tě včetně těch, které majı́ páteřnı́ sı́t’.
P
7.4
ROUTING
7.4.7
158
IS-IS
IS-IS (Intermediate System to Intermediate System) byl původně součástı́ architektury ISO/OSI,
ale po úpravě byl zařazen do TCP/IP. Je určen předevšı́m pro směrovánı́ bez navazovánı́ spojenı́.
Bývá oblı́bený zejména u velkých ISP.
IS-IS použı́vá algoritmus stavu spoje a princip jeho činnosti je hodně podobný protokolu OSPF.
Taktéž se rozlišujı́ směrovače uvnitř oblasti (prvnı́ úroveň – L1) a hraničnı́ směrovače (druhá úroveň
– L2), pozor, neplést si s L1, L2, atd. u vrstev modelů. Neexistuje žádná oblast 0 s páteřı́, směrovače
L2 poskytujı́ propojenı́ do všech oblastı́. Také lze vytvořit virtuálnı́ spoj mezi dvěma L1 směrovači.
Pokud směrovač L1 obdržı́ paket nepatřı́cı́ do jeho oblasti, odešle ho nejbližšı́mu směrovači L2.
Potom paket putuje po směrovačı́ch L2 tak dlouho, dokud se nedostane do oblasti, do které patřı́.
Zatı́mco OSPF posı́lá směrovacı́ informace v IP paketech, IS-IS využı́vá rámce linkové vrstvy.
7.4.8
EGP a BGP
Pojem EGP má ve skutečnosti dva významy – označujı́ se tak obecně vnějšı́ (externı́) směrovacı́
protokoly, ale také jeden konkrétnı́ externı́ protokol (ten nejstaršı́).
EGP (Exterior Gateway Protocol) je jednoduchý vnějšı́ směrovacı́ protokol pro výměnu informacı́
o dostupnosti či nedostupnosti sı́tı́ (předchozı́ popsané protokoly byly vnitřnı́), čı́slo protokolu
je 8. Směrovače si neustále ověřujı́ funkčnost svých sousedů a také si s nimi vyměňujı́ informace
o dostupnosti připojených sı́tı́. Nepoužı́vá se žádná metrika, a proto je vyloučena existence vı́ce
paralelnı́ch cest k téže sı́ti; nenı́ použitelný, pokud se na cestách vyskytuje smyčka (vyžaduje
stromovou strukturu směrovačů). V současnosti se už s EGP nesetkáme.
BGP (Border Gateway Protocol) je také vnějšı́ směrovacı́ protokol, ale již složitějšı́, funkčnějšı́
a použitelnějšı́. Propojuje různé autonomnı́ systémy.
Směrovače využı́vajı́cı́ BGP udržujı́ „sousedské vztahy“ – pravidelně vysı́lajı́ zprávy KeepAlive,
jejichž účel je ujišt’ovánı́ o vlastnı́ funkčnosti. Své sousedy však nezjišt’ujı́ automaticky, sousedstvı́
musı́ být ručně nakonfigurováno. Při prvnı́ výměně směrovacı́ch informacı́ směrovač informuje
o svém prefixu a čı́sle ASN a obdržı́ celou směrovacı́ tabulku, při změnách pak jen části směrovacı́
tabulky, kterých se změna týká.
Při oznámenı́ svého prefixu směrovač doplnı́ k prefixu své ASN. Během předávánı́ mezi směrovači každý směrovač také přidá své ASN, tedy celková délka identifikačnı́ho řetězce cesty se
neustále prodlužuje. Vyššı́ prioritu má kratšı́ cesta, tedy cesta s menšı́m počtem ASN, vedoucı́ přes
méně BGP směrovačů.
Protokol BGP nelze přesně zařadit mezi algoritmy vektoru vzdálenostı́ ani algoritmy stavu
spoje. Využı́vá se algoritmus vektoru cest, tj. výše popsaná sekvence čı́sel ASN doplněná prefixem.
Zatı́mco jiné směrovacı́ protokoly z důvodu většı́ pružnosti využı́vajı́ nespolehlivé přenosy
(UDP), protokol BGP využı́vá spolehlivý přenos (TCP). Podporuje CIDR (využı́vá beztřı́dnı́ směrovánı́, prefixy) a agregaci cest. Kvalitu cesty lze ovlivnit konfiguracı́ mnoha parametrů. Cesty majı́
různé váhy a také jim lze přiřadit různé atributy.
Protokol BGP je hlavnı́m směrovacı́m protokolem na Internetu, jeho využitı́ je poměrně časté.
P
7.5
CESNET2
7.4.9
159
Softwarový směrovač
Směrovače bývajı́ obvykle hardwarové, ale pro tyto účely lze použı́t i staršı́ počı́tač (směrovánı́
v menšı́ sı́ti nenı́ moc výpočetně náročné) se speciálnı́m softwarem.
Zebra1 je velmi oblı́bený a použı́vaný svobodný software pro unixové systémy podporujı́cı́
protokoly RIPv1, RIPv2, OSPFv2, BGPv4.
Quagga2 je open-source software pro unixové systémy podporujı́cı́ kromě jiného protokoly
OSPFv2, OSPFv3, RIPv1, RIPv2, BGPv4. Jedná se o klon Zebry.
XORP3 (Extensible Open Router Platform) je open-source směrovacı́ platforma podporujı́cı́
prakticky všechny známé směrovacı́ protokoly. Na stránkách projektu je dokonce možné si stáhnout
demonstračnı́ LiveCD.
NAT32 Windows Software Router4 je software pro Windows (jen pro malé sı́tě, ze směrovacı́ch
protokolů podporuje RIP). Je volně ke staženı́, platı́ se za podporu.
7.5
CESNET2
CESNET2 (Czech Education and Scientific NETwork) je národnı́ vysokorychlostnı́ počı́tačová sı́t’
určená pro vzdělávánı́, vědu, výzkum a vývoj, založená roku 1996. Propojuje předevšı́m vysoké
školy a výzkumné ústavy včetně všech ústavů Akademie věd České republiky, jsou připojeny také
některé nemocnice a střednı́ školy.
P
Jde už o druhou generaci této sı́tě. Původnı́ sı́t’ CESNET prvnı́ generace dosahovala rychlostı́
v desı́tkách až stovkách Mb/s, zatı́mco CESNET2 dosahuje rychlostı́ kolem 10 Gb/s, na některých
mı́stech až 100 Gb/s. V polovině 90. let se hodně použı́vala sı́t’ ATM, později kolem roku 2000
byla postupně zaváděna technologie PoS (Packet over SDH) a MPLS a přenosová soustava byla
postavena na DWDM.
Současná topologie sı́tě je naznačena na obrázku 7.4.
Účelem sı́tě CESNET2 je poskytovánı́ vysokorychlostnı́ch přenosů pro účely výzkumu a vzdělánı́, zabývá se také různými typy využitı́ přenosové kapacity (VoIP, multimediálnı́ přenosy a videokonference, QoS, vysokorychlostnı́ bezdrátové připojenı́, atd.). V současné době se vzhledem
k momentálnı́ situaci v oblasti sı́tı́ hodně angažuje v bezpečnostnı́ch technologiı́ch.
Zajı́mavý projekt je také EduRoam.cz, který umožňuje připojit se do bezdrátové sı́tě kteréhokoliv člena CESNETu (většinou jde o podporu mobilit zaměstnanců vysokých škol a výzkumných
ústavů).
CESNET2 je také napojena na mezinárodnı́ sı́tě s podobným zaměřenı́m, napřı́klad na evropskou sı́t’GÉANT, slovenskou SANET, rakouskou ACONET a polskou PIONIER.
Dalšı́ informace o CESNETu:
1
http://www.zebra.org/
http://www.quagga.net/
3
http://www.xorp.org/
4
http://www.nat32.com/
5
Zdroj: http://www.cesnet.cz
2
http://www.cesnet.cz
7.5
CESNET2
160
Obrázek 7.4: Topologie sı́tě CESNET25
7.5.1
Multimediálnı́ přenosy
Nejmenšı́ šı́řku pásma (do několika desı́tek kb/s) vyžaduje přenos zvuku. Většı́ šı́řku pásma
vyžaduje přenos obrazu i v nižšı́ kvalitě. Kromě přenosu zvuku a obrazu existujı́ i dalšı́ možnosti,
jak využı́t kapacitu multimediálnı́ch přenosů, napřı́klad sdı́lená tabule (účastnı́ci „kreslı́“ na tabuli,
ta je viditelná a přı́stupná všem účastnı́kům videokonference).
Existujı́ specializovaná zařı́zenı́ pro videokonference. Na trhu najdeme napřı́klad zařı́zenı́ LifeSize nebo Polycom. Dále se setkáme se specializovanými softwarovými řešenı́mi (nenı́ třeba pořizovat dalšı́ hardware, stačı́ počı́tač připojený k Internetu), napřı́klad MBone. V nejjednoduššı́ch
přı́padech lze samozřejmě použı́t konferenčnı́ nástroje dostupné v běžných operačnı́ch systémech,
jako třeba NetMeeting nebo GnomeMeeting.
7.5.2
Metacentrum, výpočetnı́ gridy
Metacentrum je aktivita CESNETu věnovaná provozu národnı́ho výpočetnı́ho gridu (distribuované výpočetnı́ sı́tě). V gridu je v současné době (2015) několik výkonných výpočetnı́ch center
zahrnujı́cı́ch celkem 10 712 procesorů. Implementuje různé metody pro BigData, včetně algoritmu
Hadoop od společnosti Google.
7.6
QOS
161
Grid je využı́ván předevšı́m akademickými pracovnı́ky pro náročné výpočty ve výzkumu
a vývoji. Členstvı́ je bezplatné pro akademické pracovnı́ky, kteřı́ jsou zaměstnanci nebo studenty
členů CESNETu.
7.5.3
CESNET CSIRT, CERTS
CSIRT (Computer Security Incident Response Team) je (obecnějšı́) označenı́ pro týmy zabývajı́cı́
se bezpečnostı́ v oblasti ICT. Tyto týmy pracujı́ jak na národnı́ úrovni, tak i na nižšı́ch úrovnı́ch jak
ve státnı́ch službách, tak i u velkých společnostı́. Ve skutečnosti jde o hierarchickou strukturu týmů
po celé zemi, které vzájemně dobrovolně spolupracujı́. Hlavnı́ CSIRT tým pro ČR je provozován
sdruženı́m CZ.NIC (rok 2007).
P
CSIRT tým plnı́ tyto úkoly:
• řešenı́ bezpečnostnı́ch incidentů ve spolupráci s českými provozovateli sı́tı́ a zahraničnı́mi
partnery,
• pomoc provozovatelům sı́tı́ při zřizovánı́ vlastnı́ch CSIRT týmů,
• poskytuje reaktivnı́ i proaktivnı́ služby, poradenstvı́ a služby,
• mohou zjišt’ovat možné autory DoS útoků a předávat informace orgánům, které pak na toto
oznámenı́ reagujı́, nebo informovat provozovatele sı́tě o napadenı́ této sı́tě.
CSIRT týmy (ani celostátnı́) nemajı́ žádné pravomoce k řešenı́ bezpečnostnı́ch incidentů na jiné
než technické úrovni, nejde o represivnı́ orgány. Mohou pouze monitorovat a radit, pravomoci
k razantnějšı́m reakcı́m majı́ pouze ve své vlastnı́ sı́ti.
CERTS (Computer Emergency Response Team Coordination Center) je CSIRT tým CESNETu
(rok 2014). Jeho úkoly jsou následujı́cı́:
P
• incident handling – přı́jem hlášenı́ o bezpečnostnı́ch incidentech na CESNETu a jejich řešenı́,
• provoz IDS (Intrusion Detection System) v sı́ti CESNET2,
• spolupráce na bezpečnostnı́ strategii v sı́ti CESNET2,
• spolupracuje s TERENA (Trans-Europen Research and Education Networking Association)
a FIRST (Forum for Incident Response and Security Team).
Poskytuje jak reaktivnı́ (reakce na bezpečnostnı́ incidenty) tak proaktivnı́ (zlepšovánı́ informovanosti uživatelů apod.) služby s důrazem na ty proaktivnı́. Měl by poskytovat poradenstvı́ a služby
nekomerčnı́m organizacı́m zapojeným do CESNETu.
Pozor, neplet’te si CERTS se zkratkou CzERT, což je skupina hackerů stojı́cı́ch na opačné straně
barikády.
Dalšı́ informace:
•
•
•
•
https://www.csirt.cz/
http://www.earchiv.cz/b08/b0408002.php3
http://www.cert.org/csirts/
http://www.lupa.cz/clanky/csirt-cz-prichazi-kyberzlocincum-navzdory/
7.6
QOS
7.6
7.6.1
162
QoS
Princip QoS
QoS (Quality of Service) znamená zajištěnı́ kvality přenosové služby. Takto se označujı́ metody,
které nabı́zejı́ garanci určitých parametrů poskytované služby. Garantovat lze napřı́klad:
P
• šı́řku pásma pro přenos, volnou kapacitu sı́tě,
• minimálnı́ ztrátovost datových jednotek (přı́padně téměř nulovou ztrátovost),
• dynamiku ztrátovosti (tedy aby nedocházelo ke ztrátám ve shlucı́ch, to by mohlo mı́t negativnı́ vliv na přenos multimédiı́, která občasnou ztrátu datové jednotky tolerujı́),
• zpožděnı́, latenci,
• změny – dynamiku – zpožděnı́ (jitter),
• atd.
Běžné sı́t’ové protokoly (e-mail, přenos souborů apod.) obvykle nemajı́ velké nároky na QoS, ale
naopak VoIP a videopřenosům mohou vadit vyššı́ hodnoty zpožděnı́, a také vyššı́ hodnoty jitter.
Technologie QoS je v některých specifikacı́ch dostupná přı́mo, napřı́klad v ATM, Frame Relay
a MPLS. Jinde je nutné mechanismus QoS přidat. Jednou z možnostı́, jak zajistit QoS ve velmi
rozšı́řených IP sı́tı́ch (i vzdálených), je DiffServ.
7.6.2
DiffServ
DiffServ (Differenciated Services, oddělené – diferencované služby) je technologie zavedenı́ QoS
(Quality of Service) do IP sı́tı́. Je to jen jedna z vı́ce různých QoS technologiı́.
Pracuje s 6 bity označenými zkratkou DSCP (Differentiated Service Code Point), což znamená
64 možných třı́d přı́stupu (v praxi se však využı́vá jen několik z nich). Třı́dy lze rozdělit do třı́
základnı́ch kategoriı́:
P
P
1. Urychlené předávánı́ (EF, Expedited Forwarding) – garance malého a téměř konstantnı́ho
zpožděnı́, latence, šı́řky pásma; je složité, proto může být poskytnuto jen nı́zkému počtu
přenosů, je vhodné napřı́klad pro implementaci virtuálnı́ho okruhu.
2. Zajištěné předávánı́ (AF, Assured Forwarding) – funguje podobně jako využı́vánı́ CIR u Frame
Relay. Použı́vá se u služeb, které upřednostňujı́ volitelnou úroveň QoS.
3. Základnı́ služba (BE, Best Effort) – pro běžné datové přenosy.
Při vstupu do sı́tě jsou pakety klasifikovány, označeny třı́dou (pokud je to potřeba). Pokud ne, jedná
se o kategorii Best Effort. Klasifikace probı́há pouze při vstupu do sı́tě (tj. sı́tě uplatňujı́cı́ DiffServ,
hovořı́me o DiffServ doméně), na následujı́cı́ch směrovačı́ch je tato informace pouze využı́vána.
Tento způsob řı́zenı́ QoS je poměrně jednoduše slučitelný s jinými QoS protokoly. Na hranici
DiffServ domény (na hranovém, ingress edge, směrovači) probı́há výše popsaná klasifikace paketu,
přı́padně překlad z jiné QoS technologie (ATM, MPLS, atd.).
Konkrétnı́ umı́stěnı́ pole bitů pro DiffServ závisı́ na tom, na které vrstvě je tato technologie
implementována (nemusı́ to být na sı́t’ové vrstvě s IP protokolem). Může to být uvnitř hlavičky
P
7.7
JMENNÉ A ADRESÁŘOVÉ SLUŽBY
163
datové jednotky (pokud je tam mı́sto) nebo vně (před záhlavı́m). V IPv4 datagramu napřı́klad jde
o 8bitové pole třı́dy služby (z toho je využito 6 bitů), v IPv6 datagramu (viz nákres na str. 31) jde
o pole pro prioritu. Hodnota 0 je výchozı́, znamená Best Effort.
DiffServ je podporován také v MPLS. Menšı́m problémem je to, že zatı́mco DiffServ použı́vá
pro určenı́ třı́dy QoS 6 bitů, MPLS jen polovinu (v MPLS hlavičce jsou pro QoS vyhrazeny jen 3
bity).
Dalšı́ informace o DiffServ:
•
•
•
•
7.7
http://www.kiv.zcu.cz/~ledvina/Prednasky-PSI-2007/qos-text.pdf
http://www.ipinfusion.com/pdf/IP InfusionQoS MPLS2.pdf
http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=70&clanekID=76
http://www.cesnet.cz/doc/techzpravy/2000-6/diffserv.ps.gz
Jmenné a adresářové služby
Jmenné služby jsou obecným principem překladu jmenných názvů (textových řetězců) na čı́selné
adresy, se kterými snadněji pracujı́ počı́tače. Typickým představitelem jmenných služeb je DNS,
jehož hlavnı́m účelem je překlad slovnı́ch adres, kterým rozumı́me (třeba www.google.com) na
čı́selné IP adresy.
Ke jmenným službám můžeme ve Windows řadit také WINS (Windows Internet Name Service,
sloužı́ k překladu názvů NetBIOS na IP adresy). Ovšem WINS se již moc nepoužı́vá (zejména
z důvodu značných omezenı́, napřı́klad délka názvu je nejvýše 15 znaků).
Oproti tomu adresářové služby sloužı́ k uspořádánı́, zabezpečenı́ a správě prostředků (často reprezentovaných objekty ve struktuře). Typickým představitelem adresářových služeb je napřı́klad
Active Directory.
7.7.1
P
P
Princip a struktura DNS
DNS (Domain Name System) je, jak bylo výše uvedeno, jmenná služba, a to distribuovaná. Sloužı́
předevšı́m k překladu doménových jmen (také hostname) na IP adresy zařı́zenı́. Distribuovaná
je z toho důvodu, že překlad může být prováděn na jednom z mnoha DNS serverů (uplatňuje
se princip lokality – překládá předevšı́m ten server, který je nejblı́ž). Distribuovanost funguje také
z toho důvodu, že jmenné adresy jsou hierarchické (nejde o flat – plochý – adresový prostor, ale
o hierarchický), a tedy přidělovánı́ jmen nemusı́ být centralizované.
Sı́t’ je organizována v hierarchickém systému domén, kde každá doména má své jméno, a adresace pomocı́ jména se vytvářı́ podle hierarchie. Můžeme si to představit jako řadu stromů, kde
každý strom má jeden kořen nazývaný doména prvnı́ úrovně (TLD, Top Level Domain, napřı́klad
.cz, .uk nebo .org) a dále se větvı́ v dalšı́ch úrovnı́ch (domény druhé, třetı́ a přı́p. dalšı́ úrovně).
Napřı́klad adresa mail.seznam.cz obsahuje celkem tři úrovně, z nichž prvnı́ úroveň je zcela vpravo.
TLD mohou být bud’ národnı́ (napřı́klad .cz, .uk, .sk) a nebo generické (nesouvisejı́cı́ se státem či
národem, napřı́klad .com, .edu, .org, .net).
P
P
7.7
JMENNÉ A ADRESÁŘOVÉ SLUŽBY
164
Ve skutečnosti i tyto „stromy“ majı́ společný kořen (tzv. kořenovou doménu), která se označuje
pouze samotnou tečkou (bez dalšı́ch znaků).
Překlad názvů probı́há pomocı́ DNS serverů (jmenných – name – serverů). Překládá se ze
jmenné adresy na čı́selnou IP adresu, a nebo naopak (reverznı́ překlad). Protože nenı́ technicky
realizovatelné mı́t jeden jediný DNS server se všemi potřebnými záznamy, a ani mı́t vı́ce takových
DNS serverů, probı́há dotazovánı́ u DNS serverů distribuovaně. To znamená, že záznamy o vztahu
jmenných a IP adres jsou rozprostřeny mezi mnoho DNS serverů. Každý DNS server má záznamy
o své zóně (oblasti, kterou spravuje). Každá doména prvnı́ úrovně má určité množstvı́ tzv. kořenových
serverů. Kořenový server dokáže podávat informace o subdoménách ve své doméně.
Každé jméno (domény, zařı́zenı́ apod.) musı́ splňovat určité náležitosti. Předevšı́m jeho délka
nesmı́ překročit 63 znaků a mohou se použı́vat pouze pı́smena anglické abecedy (bez diakritiky),
čı́slice a pomlčky (ne podtržı́tka, ta se ale mohou objevit v názvu souborů a adresářů). Celé
doménové jméno musı́ mı́t maximálně 255 znaků – to platı́ pouze pro doménové jméno, součástı́
URL adresy bývajı́ názvy souborů a adresářů, pro něž tato omezenı́ neplatı́.
Existuje možnost použı́vánı́ ne-ascii znaků v názvech domén (IDN – International Domain Names), ale překlad (nahrazenı́ těchto znaků probı́há v klientské aplikaci, nevyskytujı́ se v zónových
souborech).6
Zóna je tedy oblast spravovaná jednı́m správcem (organizacı́), obsahuje jednu nebo vı́ce domén.
Informace o zóně spravuje a poskytuje autoritativnı́ DNS server7 pro danou zónu (jeden nebo vı́ce).
Tyto informace jsou uloženy v zónovém souboru. To bývá bud’ textový (DNS pro Windows) nebo
binárnı́ soubor (BIND).
P
P
V rámci organizace máme obvykle jednu kořenovou zónu, která zahrnuje doménu přidělenou
organizaci, a dále mohou existovat dalšı́ zóny, které jsou této kořenové zóně podřı́zené. Subdomény
domény organizace (a jejich podstromy domén) jsou bud’ v téže zóně (kořenové), a nebo jsou v jiné
zóně, tedy jejich správa byla delegována jiné než kořenové zóně.
Takže celá struktura vypadá tak, že máme
• kořenový strom domén, kořenem stromu je „bezejmenná“ doména, jejı́ž potomci jsou TLD,
potomci domén TLD jsou domény druhé úrovně (SLD, Second Level Domain), atd.,
• strukturu zón, v jedné zóně je jedna nebo vı́ce domén, zóny stanovujı́ autoritu (co kdo spravuje),
• strukturu DNS (name) serverů, platı́, že pro každou doménu máme jeden nebo vı́ce DNS
serverů, z nichž jeden v každé doméně je primárnı́.
Rozlišujeme několik typů serverů v rámci zóny:
• primárnı́ server – obvykle se jedná o autoritativnı́ server zóny, v zóně je právě jeden; tento
server je důvěryhodný, jeho data musı́ být neustále v aktuálnı́m stavu (pokud provádı́me
6
IDN se týká pouze názvů domén. Zbytek adresy také může obsahovat ne-ascii znaky (pozor, často nefunguje, nenı́
zatı́m plně dopracováno), ale jde o IRI (International Resource Indicator).
7
Pojem „autoritativnı́“ znamená dostatečně velká přı́stupová oprávněnı́ také pro prováděnı́ změn. Tato oprávněnı́
platı́ ve výchozı́m nastavenı́ obvykle i pro subdomény
P
7.7
JMENNÉ A ADRESÁŘOVÉ SLUŽBY
165
změny, děláme to právě zde), tady najdeme zónový soubor, který lze přı́padně konfigurovat,
jde o autoritativnı́ server domény,
• sekundárnı́ server (i vı́ce než jeden) – obsahuje kopii dat primárnı́ho serveru, která je často
aktualizována (synchronizována s primárnı́m serverem – zone transfer), sloužı́ jako záložnı́
primárnı́ server nebo pro rozloženı́ zátěže,
• caching-only server – neobsahuje všechny informace, vždy se dotazuje primárnı́ho (sekundárnı́ho) serveru, ale odpovědi na k němu směrované dotazy si nechává v cache a využı́vá je pro
odpovědi na následné dotazy. Cache se použı́vá i na primárnı́ch či sekundárnı́ch serverech
pro informace o cizı́ch doménách.
Zone transfer (přenos zónového záznamu) z primárnı́ho na sekundárnı́ server provádı́ sekundárnı́
server v pravidelných intervalech, ale také při svém zapnutı́ a při upozorněnı́ (od primárnı́ho
serveru), že došlo ke změnám v zónovém záznamu.
Autoritativnı́ odpověd’ poskytuje primárnı́ server. Odpověd’ od caching-only serveru nenı́ autoritativnı́ (protože informace v cache už nemusejı́ být aktuálnı́), tazatel si může explicitně vyžádat
autoritativnı́ odpověd’. Odpověd’ sekundárnı́ho serveru je obvykle autoritativnı́ (správná), protože
odpovı́dá se zpožděnı́m, které by mělo být nastaveno na vyššı́ hodnotu než je délka intervalu, ve
kterém provádı́ zone transfer.
7.7.2
P
P
Dotazy v DNS
DNS server, jak bylo výše uvedeno, si v zónovém záznamu vede informace o své doméně, obsažených subdoménách, a také informaci o nadřı́zeném serveru (tj. DNS serveru nadřı́zené domény).
Každý DNS server zná kořenový DNS server celého systému.
Rozlišujeme dopředné vyhledávánı́ (nalezenı́ IP adresy podle doménového jména) a zpětné vyhledávánı́ (reverznı́, nalezenı́ doménového jména podle IP adresy). Reverznı́ vyhledávánı́ se provádı́
přes doménu in-addr.arpa. Zde je hlavnı́m problémem to, že jak jmenné, tak IP adresy jsou hierarchické, ale každá „v jiném směru“ – doména TLD ve jmenné adrese je zcela vpravo, kdežto adresu
sı́tě (hlavnı́ část) v IP adrese najdeme zcela vlevo.
Dotazovánı́ v dopředném vyhledávánı́ (máme jmennou adresu a chceme IP adresu) probı́há
distribuovaně – DNS server často nedokáže na dotaz odpovědět okamžitě podle svých záznamů,
proto se obracı́ nebo odkazuje na některý z kořenových serverů zadané domény prvnı́ úrovně.
P
P
Rozlišujeme dva typy dotazů:
• rekurzivnı́ dotazy – tazatel dostane již hotovou odpověd’,
• iterativnı́ dotazy – tazatel postupně zı́skává odkazy na mı́sta, kde může dostat odpověd’.
Tazatel svůj dotaz (jaká je IP adresa zařı́zenı́ se jménem www.abcd.cz?) posı́lá tzv. lokálnı́mu DNS
serveru (nejbližšı́mu, který zná). Pokud tento server již zná odpověd’, poskytne ji. Pokud ne, dalšı́
postup se lišı́ podle použı́vaného typu dotazovánı́:
Rekurzivnı́ dotaz. Pokud DNS server nezná odpověd’ (adresa nenı́ z jeho domény), obrátı́ se
na kořenový server nebo DNS server té domény z adresy, kterou ještě zná (to může být TLD).
P
7.7
JMENNÉ A ADRESÁŘOVÉ SLUŽBY
166
Dotazovaný DNS server se chová stejně – pokud zná cı́l, odpovı́ adresou, pokud cı́l nezná, dotazuje
se dále (obvykle ve svých subdoménách). Takto rekurzı́vně je dotaz posı́lán po stromě domén
směrem dolů. Když se konečně dostane k DNS serveru, který zná odpověd’, tento server odešle
odpověd’ přı́mo lokálnı́mu DNS serveru, na kterém dotazovánı́ začalo, a ten ji odešle tazateli.
Přı́klad
Pokud potřebujeme zjistit IP adresu počı́tače www.firma.cz, obrátı́me se na lokálnı́ DNS server. Ten
odpověd’ nezná, tedy přepošle dotaz na některý z kořenových serverů domény cz. Dotazovaný
kořenový server bud’ adresu dohledá ve svých záznamech a nebo dotaz pošle na některý z DNS
serverů pro své subdomény podle jmenné adresy (firma).
Dotaz se takto postupně dostane k DNS serveru, který identifikuje poslednı́ část adresy (vlevo),
www (obvykle jde o web server). Potom bude odpověd’ (IP adresa pro jmennou adresu www.firma.cz)
odeslána tazateli.
U rekurzivnı́ch dotazů se také použı́vá pojem forwarding (předávánı́). Oproti následujı́cı́mu typu
dotazů je menšı́ pravděpodobnost zahlcovánı́ spojů.
Iterativnı́ dotaz. Zde je aktivita předevšı́m na straně tazatele. Pokud dotazovaný DNS server
(kterýkoliv, nejdřı́v lokálnı́) nezná odpověd’, nedotazuje se dále, ale tazateli odešle mı́sto odpovědi
seznam DNS serverů, které by mohly znát odpověd’ („nevı́m, zeptej se serveru/ů xxxx“, doporučı́
bud’ kořenový server, některý TLD, a nebo servery ze svých subdomén). Tazatel si vybere některý
z doporučených DNS serverů podle toho, jak odpovı́dajı́ doménové adrese, a táže se dále. Každý
dotazovaný server opět pošle bud’ přı́mo odpověd’, a nebo doporučenı́ s názvy dalšı́ch DNS serverů.
P
Přı́klad
Pokud potřebujeme zjistit IP adresu počı́tače www.firma.cz, obrátı́me se opět na lokálnı́ DNS server.
Ten nám doporučı́, abychom dotaz odeslali na některý z kořenových serverů domény cz, což
uděláme. Dotazovaný kořenový server bud’ adresu dohledá ve svých záznamech a nebo vrátı́
pouze adresy name serverů, které mohou znát odpověd’.
Takto distribuovaně probı́há vyhodnocovánı́ dotazu (postupně podle vnořovánı́ domén různých úrovnı́), poslednı́ tázaný name server vrátı́ požadovanou IP adresu.
Komunikaci zprostředkovává protokol DNS. Tento protokol použı́vá obvykle UDP pakety (může
použı́vat i TCP, ale je to pomalejšı́), na portu 53.
Na obyčejném desktopu obvykle neběžı́ DNS server, ale pouze resolver. Resolver jen předává
dotazy některému skutečnému DNS serveru, neřešı́ je.
7.7.3
DNS záznamy a formát dotazu
Ke každé IP adrese je v zónovém souboru přiřazena alespoň jedna jmenná adresa, může jich
být vı́ce. Tedy jedna z těchto jmenných adres je nejdůležitějšı́, nazývá se kanonické jméno počı́tače
P
7.7
JMENNÉ A ADRESÁŘOVÉ SLUŽBY
167
(cannonical name, cname). Dalšı́ jmenné adresy přiřazené téže IP adrese jsou aliasy.
Name servery si uchovávajı́ v zónovém souboru tyto typy záznamů:
• SOA (Start of Authority) – obsahuje administrativnı́ informace o doméně,
• A – záznam určujı́cı́ vztah mezi konkrétnı́ IPv4 adresou a k nı́ přı́slušejı́cı́m kanonickým
jménem,
• AAAA – totéž jako záznam typu A, ale pro IPv6,
• CNAME – definice aliasu ke kanonickému jménu, tedy narozdı́l od předchozı́ho typu záznamu jde o dvojici alias–cname,
• PTR – použı́váme při reverznı́m překladu (máme IP adresu, potřebujeme jmennou adresu),
• NS (Name Server) – informace o autoritativnı́m DNS serveru pro danou doménu,
• MX (Mail eXchanger) – udává cestu k mail serveru pro danou doménu.
Dále existujı́ typy záznamů určené pro zabezpečenı́, napřı́klad záznam typu KEY obsahuje veřejný
klı́č použı́vaný při autorizaci.
Vidı́me, že v zónovém souboru nejsou pouze informace o způsobu mapovánı́ jmenné adresy na
IP adresu (záznamy typu A). Záznam typu MX umožňuje zjednodušeně adresovat mail server (emaily obvykle posı́láme na nejbližšı́ mail server, v našı́ doméně). Součástı́ záznamů je také hodnota
TTL, která plnı́ podobnou úlohu jako u IP datagramů, tedy zachycuje stářı́ záznamu.
Obrázek 7.5: DNS paket v programu Wireshark
P
7.7
JMENNÉ A ADRESÁŘOVÉ SLUŽBY
168
Pakety protokolu DNS jsou poměrně jednoduché (zapouzdřujı́ se obvykle do UDP paketu),
jsou stejné pro oba směry (dotaz a odpověd’). Struktura je následujı́cı́:
1. Header (záhlavı́) – identifikačnı́ čı́slo (pro párovánı́ dotazu a odpovědi), typ PDU (dotaz/odpověd’),
zda má být dotaz rekurzivnı́, vyžádánı́ si autoritativnı́ odpovědi, atd.
2. Question (pole dotazu) – obvykle jmenná adresa a dodatečné informace,
3. Answer (pole odpovědi) – informace souvisejı́cı́ s odpovědı́ včetně TTL,
4. Authority – autoritativnı́ jmenné servery (jejich jmenné adresy) ze záznamů NS,
5. Additional – dodatečné informace (napřı́klad také IP adresy autoritativnı́ch jmenných serverů).
Na obrázku 7.5 vidı́me strukturu DNS paketu zachyceného programem Wireshark. V hornı́ části
okna je seznam datových jednotek (ten náš je v seznamu šedě podbarven, prvnı́ zobrazený),
prostřednı́ podokno zobrazuje jednotlivé části paketu. V rozbalitelných větvı́ch zachycujı́cı́ch jednotlivé „slupky“ rozbalovaného paketu je
P
$
• základnı́ informace o rámci (zde nenı́ zobrazen kořen podstromu; délka, časové údaje, atd.),
• popis ethernetového rámce na L2 (uzel označen Ethernet II; MAC adresy a IG/LG bity),
• IPv4 datagram (IP adresy, hodnoty jednotlivých polı́ v záhlavı́ včetně nastavenı́ fragmentace,
TTL, vnořeného protokolu),
• UDP segment (zdrojový a cı́lový port, délka) – tato větev je už na obrázku rozbalená,
• konečně DNS paket (čı́slo transakce, jednotlivé přı́znaky (podle nich napřı́klad vidı́me, že
jde o dotaz, který má být proveden rekurzı́vně a jsou vyžadována autorizovaná data), po
čı́selných položkách následujı́ jednotlivé údaje dotazu (doménová adresa, chceme IP adresu
typu „A“, tedy IPv4).
MAC adresy jsou zakryty.
Ve Windows (na serverových verzı́ch) se setkáme s rolı́ DNS Server. Na jiných systémech
(včetně Windows, když nedisponujeme serverovou verzı́) se setkáme se systémem BIND (program
samotný je pojmenován named), TinyDNS nebo DJBDNS.
$
Také na desktopu máme možnost nahlédnout do mechanismu DNS. Ve Windows i v Linuxu
lze použı́vat přı́kaz nslookup (mı́rně se lišı́ v poskytovaných možnostech a samozřejmě v implementaci). Tento přı́kaz lze využı́vat v běžném (jednorázové přı́kazy) i interaktivnı́m režimu,
a to obvykle pro zjištěnı́ IP adresy k doménové adrese nebo naopak, zjištěnı́ adres DNS serverů,
přı́padně zjištěnı́ parametrů překladu. Přı́klady použitı́ jsou v přı́loze (pro Windows to je kapitola
B.3.2, strana 234, v Linuxu je syntaxe velmi podobná – strana 270).
V unixových systémech máme k dispozici nejen nslookup, ale také nástroj dig (strana 270).
Tento nástroj je komplexnějšı́ a jeho výstupy jsou podrobnějšı́ (nicméně je možné si vyžádat krátkou
odpověd’ ve stylu nslookup).
Existujı́ dalšı́ nástroje, již pro profesionálnı́ použitı́, napřı́klad DNS Staff (http://www.dnsstuff.com/products/over
nebo webové aplikace (napřı́klad na http://www.freednsinfo.com/.
7.7.4
Bezpečnost v DNS
V poslednı́ době se hodně diskutuje o zabezpečenı́ DNS. Překladu jmenné adresy na IP adresu
obvykle věřı́me a mnoho uživatelů vůbec nenapadne, že ve skutečnosti mohou komunikovat
7.7
JMENNÉ A ADRESÁŘOVÉ SLUŽBY
169
s protistranou s jinou IP adresou, než kterou předpokládajı́. Důsledkem napadenı́ DNS může být
napřı́klad provedenı́ útoku Man-in-the-Middle, přesměrovánı́ na napadený server za účelem šı́řenı́
škodlivého kódu, odposlechnutı́ hesla, čı́sla karty apod.
V rámci zabezpečenı́ DNS je tedy třeba zajistit, aby DNS pakety s informacı́ o překladu nemohly
být podvrženy. Je to vpodstatě obdoba mechanismu SEND, který zabezpečuje ARP.
DNSSEC (DNS Security Extensions) je bezpečnostnı́ rozšı́řenı́ systému DNS umožňujı́cı́ DNS
klientovi ověřit původ dat (zda pocházejı́ od správného DNS serveru).
Při použitı́ DNSSEC se použı́vá asymetrické šifrovánı́ následovně:
• provozovatel DNS domény vygeneruje dvojici klı́čů (soukromý a veřejný klı́č),
• veřejný klı́č uložı́ u nadřazené autority své domény (vytvářı́ se jakási hierarchie důvěry),
• soukromým klı́čem šifruje DNS server pakety, které odesı́lá,
• přı́jemce (DNS klient, resolver) je dešifruje veřejným klı́čem, který zı́skal od nadřazené autority DNS serveru.
Jedná se vlastně o elektronicky podepsané DNS pakety. Také správce české TLD domény na svých
DNS serverech použı́vá DNSSEC, přičemž jeho nadřazenou autoritou (a mı́stem, kde je přı́slušný
veřejný klı́č) je správce celosvětové sı́tě DNS serverů. Nadřı́zená autorita ručı́ za správnost překladu
svých bezprostřednı́ch podřı́zených.
Dalšı́ informace o DNS:
•
•
•
•
•
•
•
http://www.fit.vutbr.cz/study/courses/ISA/public/xkupci00.pdf
http://www.lupa.cz/clanky/neplechy-v-dns-a-jak-se-jim-vyhnout/
http://www.linuxzone.cz/index.phtml?ids=9&idc=427
http://www.dnssec.cz/
http://www.samuraj-cz.com/clanek/dns-domain-name-system-zamereno-na-microsoft/
http://www.root.cz/clanky/dnssec-cast-prvni-aneb-je-potreba-zacit-od-piky/
http://www.abclinuxu.cz/clanky/site/nastaveni-dns
Úkoly
Najděte v přı́loze přı́kazy pro překlad názvů pro Windows nebo Linux, podle systému, na kterém
pracujete. Vyzkoušejte ukázky, které v přı́loze najdete.
7.7.5
Adresářové služby a Active Directory
Pod pojmem adresář rozumı́me databázi, která je organizována hierarchicky. Zatı́mco u jmenných
služeb jde předevšı́m o překlad názvů na čı́sla a hierarchie jmen je udržována za účelem fungovánı́
tohoto překladu, u adresářových služeb je právě adresář to hlavnı́ a celá funkcionalita spočı́vá
v práci s adresářem a řı́zenı́ přı́stupu k němu. Adresářová služba je autentizačnı́ autorita (tak jako
napřı́klad RADIUS server nebo ve Windows LSA).
P
7.7
JMENNÉ A ADRESÁŘOVÉ SLUŽBY
170
Standardem pro adresářové služby je X.500, protokol DAP (Directory Access Protocol). Tento
standard je však přı́liš obsáhlý, a proto jej prakticky žádná funkčnı́ adresářová služba neimplementuje celý. Většina adresářových služeb je postavena na protokolu LDAP (Lightweight Directory
Access Protocol). Jde o aplikačnı́ protokol pracujı́cı́ nad TCP/IP. V názvu má lightweight (odlehčený), protože jde o zjednodušenı́ protokolů, které se pro tyto účely použı́valy původně (X.500
zahrnujı́cı́ DAP, DSP a dalšı́). Důležitou vlastnostı́, která zajišt’uje snadnou přenositelnost, je komunikace mezi uzly přes protokoly rodiny TCP/IP.
Active Directory je implementace protokolu LDAP pro Windows od verze 2000. Je závislá na
DNS (můžeme ji chápat jako nástavbu nad doménami DNS), napřı́klad přejı́má názvy domén DNS
a využı́vá DNS při vyhledávánı́ v doménách. V lokálnı́ sı́ti musı́ existovat alespoň jeden server
DNS, na klientských počı́tačı́ch musı́ být nakonfigurován klient DNS třeba přes DHCP. Domény
Active Directory však nejsou totožné s doménami DNS, i kdyby měly stejný název, jsou jinak
reprezentovány, ukládajı́ se jiné typy informacı́.
Použı́váme tyto pojmy:
• adresářová databáze (adresář) je databáze objektů, které jsou v systému spravovány, je hierarchicky uspořádaná (takže adresář je vlastně o objektech a vztazı́ch mezi nimi, to vše je
uloženo v souborech),
P
P
• objekty mohou být napřı́klad uživatelé, skupiny, počı́tače, domény, apod., každý objekt má
své vlastnosti (napřı́klad přı́stupová práva), tyto vlastnosti se v hierarchické struktuře mohou
dědit,
• kontejner je objekt, který může obsahovat dalšı́ objekty (obdoba složek na disku),
• AD schéma popisuje objekty, které mohou být uloženy v adresáři Active Directory (jaké mohou
mı́t atributy, co v nich může být uloženo, obdoba třı́dy),
• doména je skupina počı́tačů sdı́lejı́cı́ch společnou adresářovou databázi,
• organizačnı́ jednotka (OU) je podskupina domény (ale ne jakékoliv) oddělená za určitým účelem
(napřı́klad firma může mı́t jedinou doménu a tu rozčlenı́ na organizačnı́ jednotky podle svých
oddělenı́). OU mohou být i vnořené.
V sı́ti je Active Directory provozován na doménových řadičı́ch (domain controller, vpodstatě jde
o doménové servery), musı́ existovat alespoň jeden (primárnı́ řadič domény) a přı́padně dalšı́ (ale
záležı́ na konkrétnı́ verzi Windows, některé verze majı́ s dalšı́mi řadiči trochu problém).
V každé sı́ti je nejméně jeden Globálnı́ katalog (prvnı́ globálnı́ katalog se vytvořı́ na primárnı́m
řadiči domény). V Globálnı́m katalogu jsou předevšı́m souhrny informacı́ obsažených v dalšı́ch
doménových serverech sı́tě (ne všechny parametry, jen nejdůležitějšı́), hovořı́me také o replikaci
(dynamickém vytvářenı́ kopiı́).
Globálnı́ katalogy sloužı́ při vyhledávánı́ informacı́ v sı́ti a také k autentizaci (uživatel se vlastně
z technického hlediska přihlašuje ke globálnı́mu katalogu) a autorizaci. Takže přes doménové řadiče
s globálnı́mi katalogy přistupujeme k objektům a také se na nich provádı́ autentizace (kontrola při
přihlašovánı́) a autorizace (při přı́stupu k objektům).
P
P
7.7
JMENNÉ A ADRESÁŘOVÉ SLUŽBY
V Active Directory (také ve jmenných službách včetně DNS)
se použı́vá několik druhů názvů podle typu zanořenı́ v doménách. Jsou to předevšı́m Domain Component (DC, uzel domény),
Organization Unit (OU, organizačnı́ jednotka, to je Active Directory Container, obdoba složky) a Common Name (CN, objekt).
Adresace (popis cesty k objektu) podle struktury na obrázku 7.6
je
cn=novak,ou=zamestnanci,dc=firma,dc=cz
Tento způsob adresace objektu se označuje DN (Distinguished
Name). Dalšı́ způsob adresace, UNC, známe z DNS názvů:
171
dc=firma,dc=cz
ou=pocitace
ou=zamestnanci
P
cn=novak
Obrázek 7.6: Názvy v doménách
firma.cz/zamestnanci/novak
Existujı́ i dalšı́ způsoby adresace, předevšı́m RFC 822 (forma silně připomı́najı́cı́ e-mail) a názvy
LDAP (ve formě ldap://uncdomeny/CN=....,OU=....).
Na desktopu obvykle služba Active Directory nenı́ nainstalována, pracujeme zde pouze se
zásadami8 (politikami), a to v nástrojı́ch Mı́stnı́ zásady zabezpečenı́ a Zásady skupiny (Group Policies
Editor gpedit.msc). V sı́ti se zprovozněným Active Directory jsou zásady skupiny napojeny na
Active Directory.
Dnes jsou běžné heterogennı́ sı́tě (tj. na počı́tačı́ch v sı́ti jsou různé typy operačnı́ch systémů.
Může se zdát, že použı́vánı́ mechanismu Active Directory v heterogennı́ sı́ti je problém, ale řešenı́
existuje, spočı́vá v použitı́ jakýchsi „překladatelů“ – protokolů, které zprostředkujı́ komunikaci
mezi počı́tači s různými operačnı́mi systémy. V přı́padě použitı́ Active Directory jde předevšı́m
o protokol LDAP implementovaný také na jiných operačnı́ch systémech včetně Linuxu, dále pro
přı́stup k datům se použı́vá protokol SMB.
Dalšı́ informace o Active Directory:
•
•
•
•
•
•
•
8
http://www.samuraj-cz.com/clanek/active-directory-komponenty-domain-tree-forest-site/
http://www.mcmcse.com/microsoft/guides/ad.shtml
http://www.petri.co.il/ad.htm
http://www.learnthat.com/Software/learn/1295/Introduction-to-Active-Directory/
http://www.samuraj-cz.com/serie/ldap-a-active-directory/
http://www.samuraj-cz.com/clanek/adresarove-sluzby-a-ldap/
http://ldap.zdenda.com/
Pod pojmem zásada (politika, policy) obvykle rozumı́me konkrétnı́ nastavenı́ (obvyke týkajı́cı́ se zabezpečenı́) pro
danou komponentu či vlastnost.
O
Kapitola
8
Bezpečnost a správa sı́tı́
8.1
8.1.1
Bezpečnost v sı́tı́ch
Typy útoků
V počı́tačové sı́ti je třeba čelit různým typům útoků, z nichž některé jsou vzájemně provázány. Této
problematice jsme se věnovali v předmětech Praktikum z operačnı́ch systémů a Operačnı́ systémy,
tedy jen stručně. Předevšı́m nás zajı́majı́ tyto útoky:
Mapping (mapovánı́) – jde vlastně o jakousi přı́pravu k následujı́cı́m útokům. Hacker zı́skává co
nejvı́c informacı́, aby vlastnı́ útok mohl být co nejúspěšnějšı́.
Network sniffing (naslouchánı́ na sı́ti) – packet sniffer (zachytávač nebo odposlouchávač paketů)
odklonı́ provoz na sı́ti, zachytává pakety a zı́skává z nich informace (pak je posı́lá dál k cı́li,
nedoručené pakety by znamenaly jeho odhalenı́).
P
P
Účelem sniffingu je předevšı́m zı́skávat hesla přenášená v textovém tvaru a také dalšı́ citlivé
informace. Také je možné zachytávat a pozměňovat obsah paketů a nebo dokonce čı́st a pozměňovat
informace na uzlech v sı́ti (včetně konfiguračnı́ch souborů nebo hesel).
Účinnou obranou je předevšı́m spolehlivé šifrovánı́ (včetně autentizace po sı́ti), a také fyzické
zabezpečenı́ sı́tě, protože tento typ útoku vyžaduje fyzický přı́stup k sı́ti. To může být problém
u bezdrátových typů připojenı́.
Packet sniffer však může být zcela legálně využı́ván administrátorem ke sledovánı́ provozu na
sı́ti.
IP Spoofing – podvrhnutı́ IP adresy. Komunikujı́cı́ uzel předstı́rá, že je vlastnı́kem IP adresy, která
ve skutečnosti patřı́ jinému uzlu (nebo nepatřı́ žádnému uzlu). Obvykle jde o přı́pad, kdy se útočnı́k
snažı́ předstı́rat, že je řádným členem privátnı́ sı́tě použı́vajı́cı́ určitý rozsah IP adres, přı́padně se
pokoušı́ vydávat za konkrétnı́ uzel v sı́ti. Častým způsobem použitı́ je zneužitı́ některých protokolů,
včetně protokolu SMTP pro odesı́lánı́ e-mailů.
Tento útok spočı́vá napřı́klad ve změně směrovacı́ch tabulek na routerech v sı́ti. Obranou je
tedy předevšı́m zabezpečenı́ routerů a bezpečná implementace směrovacı́ch algoritmů.
172
P
8.1
BEZPEČNOST V SÍTÍCH
173
DoS (Denial of Service) – odmı́tnutı́ služby. Jde o vynucenı́ odmı́tnutı́ služby legitimnı́m uživatelům. Tento útok probı́há bud’ využitı́m chyby v kódu (některého protokolu nebo operačnı́ho
systému), vyvolaným přetı́ženı́m sı́tě nebo podvrženými zprávami – pakety o stavu sı́tě. Server
je zahlcen žádostmi o spojenı́ (TCP handshake) nebo žádostmi o data, které nenı́ schopen vyřı́dit,
a proto i následný provoz je zadržen.
DDoS (Distributed DoS) – velmi nebezpečná varianta předchozı́ho typu útoku, proti které se
téměř nelze bránit. Častým nedobrovolným „účasnı́kem“ DDoS útoků jsou sı́tě botů. Bot je napadený počı́tač ovládaný na dálku hackerem (bez dovolenı́ a většinou také bez vědomı́ právoplatného
majitele). Sı́tě botů, a to i velmi rozsáhlé (resp. jejich služby), jsou „prodávány“ na černém trhu
kromě jiného právě k DDoS útokům.
Hijacking (únos spojenı́) – jde předevšı́m o útoky souvisejı́cı́ s vytáčeným spojenı́m, ale také
obecně s jakýmkoliv placeným spojenı́m vyžadujı́cı́m autentizaci (napřı́klad soukromé Wi-Fi sı́tě).
Účinnou obranou je použitı́ vhodného šifrovacı́ho algoritmu při autentizaci.
Útoky na zjištěnı́ hesla – heslo lze zjistit napřı́klad brute-force útokem (hrubá sı́la), použitı́m
trojského koně a některými výše popsanými metodami. Dalšı́ možnostı́ je sociálnı́ inženýrstvı́, které
je v současné době na vzestupu (uživatel defacto tento údaj prozradı́ sám a dobrovolně, je z něho
podvodně vylákán).
P
P
P
P
Brute-force útok je většinou veden jako slovnı́kový, tj. automaticky jsou zkoušeny všechny řetězce z vytvořeného slovnı́ku (nemusı́ jı́t jen o anglická slova!), proti čemuž se lze bránit nastavenı́m
maximálnı́ho počtu neúspěšných přihlášenı́, po překročenı́ tohoto limitu je přı́stup zcela zablokován. Dále je možné po uživatelı́ch vyžadovat použı́vánı́ tzv. „silného“ hesla (dostatečně dlouhého,
obsahujı́cı́ho jak pı́smena, tak i čı́slice a dalšı́ znaky – dvojtečka, procento, zavináč, apod.), s čı́mž
ale bývajı́ problémy (uživatelé raději volı́ takové heslo, které si dokážou zapamatovat).
Také je třeba si uvědomit, že mnohá zařı́zenı́ (routery, modemy, apod.) majı́ heslo administrátora
přednastaveno na hodnotu, která je všeobecně známá (zjistitelná). Proto při instalaci podobných
zařı́zenı́ do sı́tě je nutné změnit heslo administrátora.
Přenosy citlivých informacı́ – zvláště firemnı́ sı́tě by měly být dobře zabezpečeny. Pokud zaměstnanec přistupuje k firemnı́ sı́ti externě (napřı́klad na pracovnı́ cestě, tj. z jiné LAN, resp. počı́tač nenı́
přı́mo připojen do LAN), mělo by být spojenı́ zabezpečené – virtuálnı́ privátnı́ sı́t’(VPN), vytvářı́
se tzv. tunel, data včetně autentizace se přenášejı́ v šifrované podobě. Kromě dřı́ve zmı́něných
protokolů se použı́vá protokol IPSec.
Man-in-the-Middle – hacker se dostane mezi dva komunikujı́cı́ počı́tače a odposlouchává nebo
dokonce pozměňuje komunikaci mezi nimi. Tento typ útoku souvisı́ s některými předchozı́mi –
únos spojenı́, zjišt’ovánı́ hesla apod.
Lidský faktor – „nepřı́tel“ může být i uvnitř sı́tě, a to dokonce i takový, který to o sobě netušı́.
Zvláště v poslednı́ době jsou pro útoky často voleny metody sociálnı́ho inženýrstvı́. Sociálnı́ inženýrstvı́ je metoda, jak z uživatele vytáhnout potřebné informace třeba i bez použitı́ techniky, a to jeho
uvedenı́m v omyl (obelstěnı́m). Uživatel je přesvědčen, že informace předává důvěryhodné osobě
z naprosto nutných důvodů.
P
P
P
8.1
BEZPEČNOST V SÍTÍCH
174
Útočnı́k se vydává napřı́klad za zaměstnance bezpečnostnı́ho oddělenı́, opraváře, zaměstnance
telefonnı́ společnosti, nového kolegu, apod. a nenápadně ze svých obětı́ vytáhne vše potřebné
(hlavně hesla), přı́padně si „vyzkoušı́“ nový skvělý počı́tač nebo se jinak dostane k technice na
pracovišti. Stává se to předevšı́m ve většı́ch firmách, kde se nepočı́tá s tı́m, že by se všichni
zaměstnanci znali, ale kontakt může probı́hat i „neosobně“ přes telefon nebo mail. Právě do telefonu
jsou zaměstnanci schopni řı́ci o své firmě neuvěřitelné věci včetně těch, které jsou obchodnı́m
tajemstvı́m.
Sociálnı́ inženýrstvı́ může mı́t i „materiálnı́“ povahu – napřı́klad volně „pohozená“ přenosná
zařı́zenı́, která jsou pro mnoho lidı́ neodolatelná. Podle DHS1 je kolem 60 % běžných uživatelů
schopno náhodně nalezený USB flash disk připojit ke svému počı́tači, třebaže netušı́, zda se na
něm nenacházı́ škodlivý software. Podobně lze zneužı́t i jiná přenosná zařı́zenı́, zde je nejlepšı́
ochranou poctivost, tedy odevzdat nalezený předmět do ztrát a nálezů.
Sociálnı́ inženýrstvı́ je v současné době jedna z nejpoužı́vanějšı́ch (a taky nejefektivnějšı́ch)
metod zı́skávánı́ utajených informacı́. Na to by měli myslet zejména administrátoři firemnı́ch sı́tı́
a zajistit patřičné školenı́ všech, kdo se do firemnı́ sı́tě připojujı́.
L
Jak se bránit?
• Nevěřit všemu, co kdo povı́dá. Zvláště když jsem napřı́klad administrátor firemnı́ sı́tě, musı́m
si vše ověřovat (totožnost žadatele o nové heslo po jeho zapomenutı́, nutnost provedenı́
požadovaného zásahu do systému, apod.).
• Heslo či jiné podobné údaje si nenecháváme na papı́rku přilepeném k monitoru (nebo na
jiných „obvyklých“ mı́stech). Volı́me silná hesla.
• Každý systém zabezpečený heslem (včetně operačnı́ch systémů) lze nastavit tak, aby po
stanoveném počtu chybných pokusů o přihlášenı́ byl účet zablokován.
• Banky ani jiné instituce nechtějı́ po svých zaměstnancı́ch zası́lánı́ hesel, certifikátů, TAN, čı́sla
kreditnı́ karty a podobných údajů mailem ani žádným jiným nezapezpečeným způsobem
(jen přes zabezpečené stránky přı́mo při přihlašovánı́). A rozhodně o ně nežádajı́ mailem ani
telefonem.
• Správce sı́tě by měl mı́t každou žádost o zásah do účtů zaměstnanců nebo systému vždy
„papı́rově“ podloženou.
• Útočnı́ci použı́vajı́cı́ sociálnı́ inženýrstvı́ dělajı́ „domácı́ úkoly“ – shánějı́ co nejvı́c informacı́
(včetně osobnı́ch), které by mohli využı́t. Firma by měla zvážit, co zveřejnı́ (a totéž platı́
i o domácı́ch uživatelı́ch, také napřı́klad na diskusnı́ch fórech a sociálnı́ch sı́tı́ch). Skartovačka
nenı́ zbytečné zařı́zenı́.
Důležitým pojmem v bezpečnosti je FIRST (Forum of Incident Response and Security Teams). Jedná
se o seskupenı́ bezpečnostnı́ch týmů reagujı́cı́ch na různé hrozby a bezpečnostnı́ incidenty. FIRST
se také podı́lı́ na udržovánı́ standardu CVSS (Common Vulnerability Scoring System – společný
systém pro hodnocenı́ zranitelnostı́). Informace najdeme na http://www.first.org/cvss/.
1
DHS (Department of Homeland Security, http://www.dhs.gov)
P
8.2
SÍŤOVÝ ANALYZÁTOR
8.1.2
175
Zabezpečenı́ na jednotlivých vrstvách ISO/OSI
Na kterékoliv vrstvě lze šifrovat data. V ISO/OSI modelu se při toku dat směrem dolů šifrujı́
veškerá data vyššı́ vrstvy, tj. včetně záhlavı́. Dále:
1. Na linkové vrstvě se provádı́ šifrovánı́ podle dané přenosové techniky (např. dle IEEE 802.11).
2. Na sı́t’ové vrstvě se implementuje zabezpečenı́ spojenı́ mezi dvěma uzly včetně vytvořenı́
tunelu při VPN spojenı́ (protokol IPSec).
3. Na transportnı́ vrstvě pracuje SSL.
4. Na aplikačnı́ vrstvě se použı́vajı́ klı́če včetně PGP.
8.2
Sı́t’ový analyzátor
Sı́t’ový analyzátor je zařı́zenı́, které se připojuje mezi některý prvek sı́tě (PC, server, most, router,
atd.) a LAN, také může být součástı́ jiného zařı́zenı́. Samostatný sı́t’ový analyzátor (přenosný) může
být i velmi malý, může připomı́nat mobilnı́ telefon.
P
Obrázek 8.1: Sı́t’ové analyzátory2
Pracuje na fyzické nebo vyššı́ch vrstvách, na tom záležı́, které charakteristiky dokáže sledovat.
Na fyzické vrstvě předevšı́m stav média, provoz (zatı́ženı́), dokáže generovat vlastnı́ provoz,
na vyššı́ch vrstvách může podporovat také virtuálnı́ sı́tě, sledovánı́ stavu dostupných uzlů sı́tě,
sledovánı́ rámců, přı́p. paketů, atd.
Sı́t’ový analyzátor „dosáhne“ pouze tam, odkud se k němu dostanou data. U uzlu sı́tě je tedy
omezen na jedinou koliznı́ doménu (tj. k nejbližšı́mu přepı́nači nebo směrovači). Proto bývá vhodné
umı́stit sı́t’ový analyzátor na takový uzel sı́tě, který se vyskytuje ve vı́ce koliznı́ch doménách,
napřı́klad právě směrovač.
Přehled některých sı́t’ových analyzátorů najdeme napřı́klad na
http://www.fluketestery.cz/produkty-sitove-analyzatory.html.
Hardware of firmy Fluke
je v této oblasti všeobecně znám. Nejpoužı́vanějšı́ přı́stroje:
• LinkRunner – pracuje na fyzické vrstvě, identifikace vlastnostı́ Ethernetového spojenı́ – negociace (10/100/1000 Mb, duplex apod.), detekce poruch kabelů včetně vzdálenosti k poruše,
zásuvek, provoz na segmentu, atd.
2
Zdroj: http://www.fluketestery.cz/
P
8.3
FIREWALL
176
• NetTool – sı́t’ová vrstva, testy na fyzické vrstvě (kabeláž, negociace, využı́vánı́ segmentu),
spojové (detekce kolizı́ a chybových rámců, VLAN, vyhledávánı́ MAC adres v sı́ti, apod.),
sı́t’ové (vyhledávánı́ IP adres v sı́ti, podsı́tı́, routerů a dalšı́ch zdrojů, ping, atd.), měřenı́ PoE,
monitoring parametrů VoIP, atd.
• AirCheck – analýza Wi-fi sı́tě 802.11a/b/g/n
Hardware of firmy Embedded Technologies obsahuje obvykle vlastnı́ variantu embedded Linuxu
(tj. Linuxu upraveného pro speciálnı́ účely, zde pro sı́t’ová zařı́zenı́) zároveň s dalšı́m potřebným
softwarem. Napřı́klad:
P
• Sı́t’ový analyzátor – vestavěný sniffer Wireshark, NAT, firewall, atd.
• Diagnostický switch pro Ethernet
Něco podobného si lze vytvořit vlastnoručně ze staršı́ho (nadbytečného) počı́tače s potřebným
množstvı́m hardwarových rozhranı́, distribuce embedded Linuxu jsou dostupné na Internetu.
Softwarové sı́t’ové analyzátory: Sı́t’ové analyzátory mohou být také softwarové – sledujı́ a přı́padně ovlivňujı́ sı́t’ový provoz souvisejı́cı́ s počı́tačem, na kterém jsou nainstalovány (ideálně server,
ale může to být kterýkoliv počı́tač v sı́ti). Asi nejznámějšı́ softwarový sı́t’ový analyzátor je Wireshark
(dřı́ve se nazýval Ethereal) dostupný na http://www.wireshark.org/.
P
Diagnostika bezdrátových sı́tı́ byla probı́rána v kapitole 6.2.4 (str. 124) pro fyzickou vrstvu,
v kapitole 6.2.6 (str. 129) pro MAC podvrstvu.
Dalšı́ informace o sı́t’ových analyzátorech najdeme na
•
•
•
•
•
•
•
8.3
8.3.1
http://www.root.cz/serialy/pruvodce-programem-ethereal/
http://knihy.cpress.cz/DataFiles/Book/00003877/Download/kapitola 3 K1599.pdf
http://www.proficomms.cz/index.php?module=shop catalog&action=view&category id=60&id=51
http://www.etech.cz/cs/products/lan.htm
http://hrazdil.info/school/pds-sitovy-analyzator/
http://computerworld.cz/testy/nastroje-pro-analyzu-provozu-wlan-proveri-vase-pakety-1-4555
http://www.trinstruments.cz/clearsight-analyzer
Firewall
Princip firewallu
Firewall je sı́t’ový prvek (hardwarový nebo softwarový), který sloužı́ k řı́zenı́ provozu mezi sı́těmi
s různou úrovnı́ důvěryhodnosti či zabezpečenı́. Ve firewallu jsou definována pravidla pro komunikaci mezi sı́těmi, podle kterých reaguje bud’ povolenı́m komunikace, jejı́m zakázánı́m a nebo
žádostı́ o vyjádřenı́ uživatele. Pravidla se obvykle týkajı́ těchto údajů:
• zdroj a cı́l komunikace, může být zadán IP adresou,
• čı́slo portu, přes který se komunikuje (tj. můžeme zablokovat použı́vánı́ některého portu),
může jı́t o zdrojový i cı́lový port,
• použı́vaný protokol,
• stav spojenı́, atd.
P
8.3
FIREWALL
177
Firewall může být bud’ jen jednosměrný (filtruje pouze přı́chozı́ pakety) nebo obousměrný (filtruje
přı́chozı́ i odchozı́ pakety). Lepšı́ je samozřejmě obousměrný, dokáže efektivněji zachytit přı́padné
vynášenı́ citlivých informacı́.
Kromě softwarových firewallů existujı́ také hardwarové firewally fungujı́cı́ jako mezilehlé prvky
sı́tě. Dnes jsou většinou součástı́ směrovačů (routerů) nebo jiných běžných sı́t’ových prvků (na
typu zařı́zenı́ závisı́, k jakým informacı́m se firewall dostane). Hardwarový firewall má velkou
výhodu v nižšı́m riziku napadenı́ (nenı́ závislý na operačnı́m systému klientského počı́tače). Dalšı́
výhodou je nezávislost na výkonu počı́tače – pokud je procesor počı́tače hodně zatı́žen, má to
vliv i na činnost (předevšı́m rychlost) softwarového firewallu na tomto počı́tači nainstalovaného.
Hardwarový firewall (třeba vestavěný v jiném sı́t’ovém zařı́zenı́) takto ovlivněn nenı́.
Z hlediska bezpečnosti je v domácnostech a menšı́ch firmách za ideálnı́ považována kombinace
jednoduchého hardwarového firewallu ve směrovači (napřı́klad ADSL router) a softwarového
routeru na počı́tači, jaždý z nich jiného typu.
Softwarové firewally sloužı́ bud’ k ochraně koncových uzlů, a nebo mohou běžet v operačnı́m
systému nainstalovaném na (téměř) jakémkoliv sı́t’ovém prvku.
Oblasti podle firewallu.
Z pohledu firewallu členı́me sı́t’do několika oblastı́:
• vnitřnı́ sı́t’ – do této oblasti patřı́ vše, co je „naše“, čemu můžeme důvěřovat, uzel z vnitřnı́
sı́tě může (s ohledem na přı́stupová oprávněnı́) iniciovat spojenı́ k vnitřnı́ i vnějšı́ sı́ti,
• vnějšı́ sı́t’ – typicky Internet,
• demilitarizovaná zóna (DMZ) – zóna „nikoho“, z bezpečnostnı́ho hlediska někde mezi vnitřnı́
a vnějšı́ sı́tı́.
P
P
Do DMZ lze umı́stit napřı́klad to, co je sice „naše“, ale má být přı́stupné z vnějšı́ sı́tě (napřı́klad
web server, mail server, DNS server). Servery v DMZ by měly být zabezpečeny tak, jako by byly
opravdu přı́mo na Internetu, třebaže jsou od Internetu odděleny firewallem.
Dalšı́ možnost využitı́ DMZ je propojenı́ k třetı́ straně, které vı́ceméně důvěřujeme, typicky dodavateli služby, kterou si nemůžeme zajistit vlastnı́mi silami. Obě možnosti můžeme zkombinovat
a použı́vat dvě demilitarizované zóny (nebo vı́ce).
Na sı́t’ovém zařı́zenı́ podporujı́cı́m DMZ máme obvykle jeden nebo vı́ce (hardwarových!) portů
takto označených, přı́padně můžeme některé porty sami nakonfigurovat tak, aby se s nimi zacházelo jako s DMZ (napřı́klad tehdy, když chceme staršı́ počı́tač využı́t jako hardwarový firewall,
ukázky najdeme v přı́loze).
TCP/UDP porty. Běžný uživatel si většinou s nastavenı́m (softwarových) portů nevı́ rady (viz
část prvnı́ kapitoly věnovanou TCP/UDP paketům). Na internetu najdeme stránky se seznamy
známých a registrovaných portů použı́vaných různými protokoly.3 Tyto seznamy jsou však použitelné pro sledovánı́ odchozı́ho provozu nebo při nastavovánı́ portů na serveru. Ve skutečnosti
aplikace mohou použı́vat i jiné porty, než které jsou běžné pro protokoly, se kterými pracujı́.
3
Seznam portů a přı́padně služeb najdeme napřı́klad na http://www.iana.org/assignments/port-numbers,
http://en.wikipedia.org/wiki/List of TCP and UDP port numbers, http://www.ports-services.com/. Na české Wikipedii
nenı́ seznam úplný.
$
8.3
FIREWALL
8.3.2
178
Typy filtrovánı́
Rozlišujeme různé typy filtrovánı́ podle toho, na kterou vrstvu ISO/OSI lze danou metodu zařadit
(a tedy na které informace v záhlavı́ch „dosáhneme“). Obvykle se jedná předevšı́m o filtrovánı́ na
sı́t’ové vrstvě (L3), protože tam lze pracovat s IP adresami.
Paketový filtr. Jedná se o nejjednoduššı́ filtrovánı́ na L3 a částečně L4, v pravidlech se uvádějı́ jen
IP adresy a čı́sla portů. Je to jednoduché a rychlé řešenı́ (provoz je zdržován jen minimálně), které
se dřı́ve běžně uplatňovalo předevšı́m na mezilehlých sı́t’ových prvcı́ch (napřı́klad staršı́ verze
operačnı́ho systému IOS pro směrovače), dnes je najdeme v některých nejlevnějšı́ch směrovačı́ch.
Nevýhodou je neschopnost nahlı́žet do komunikace probı́hajı́cı́ v složitějšı́ch protokolech.
ACL na sı́t’ové vrstvě. ACL (Access Control List – seznam řı́zenı́ přı́stupu, přı́stupový seznam)
je metoda široce použı́vaná jak v desktopových a serverových operačnı́ch systémech, tak i v sı́t’ových zařı́zenı́ch. Účelem je určovat pravidla přı́stupu pro různé uživatele/komunikace. Vpodstatě
se jedná o funkčnı́ nástavbu metody paketového filtru. S ACL v operačnı́ch systémech jsme se
seznámili v předmětu Operačnı́ systémy (cvičenı́ – Windows i Linux).
P
P
Přı́stupový seznam je vlastně seznam položek v této formě:
• deny to, co nemá projı́t
• permit to, co může projı́t
• deny all else obvykle poslednı́ položka seznamu, co nebylo zmı́něno, nesmı́ projı́t
ACL je většinou implementován ve formě „co nenı́ dovoleno, je zakázáno“, takže najdeme spı́še
jen položky permit (a co nenı́ v těchto položkách, to neprojde). Přı́padně se můžeme setkat s celou
strukturou navzájem provázaných ACL. Položky se procházejı́ sekvenčně, jedna po druhé, a hledá
se shoda. Také pořadı́ položek je důležité.
Filtruje se obvykle podle cı́lové IP adresy, podle zdrojové IP adresy, podle jejich kombinace,
a nebo přı́padně podle dalšı́ch kritériı́ (napřı́klad podle položek v PDU sı́t’ové vrstvy – protokolu
IP, ICMP, podle TCP/UDP portu, se kterým se navazuje spojenı́ ze sı́t’ové vrstvy, apod.). Adresa
obvykle bývá adresou podsı́tě, tedy je uložen prefix a jeho délka (resp. maska, aby bylo zřejmé,
u kolika bitů adresy se má hledat shoda).
Ukázky ACL najdeme napřı́klad na
• http://skola.sssbb.sk/~badani/cisco/semester2/Sem2-11%20ACL.pdf
• http://www.cs.vsb.cz/grygarek/PS/projekt0304/acl priklad.pdf
• http://www.samuraj-cz.com/clanek/cisco-ios-18-inter-vlan-routing-a-acl-smerovani
-mezi-vlany/
Stavová inspekce paketů. Přesuneme se o vrstvu výše – na transportnı́ vrstvě (L4, konkrétněji
ted’ jsme na celém TCP/IP definovaném na L3 a L4) se provádı́ filtrovánı́ SPI (Statefull Packet
Inspection, stavová inspekce paketů, také stavový paketový filtr). Zatı́mco na L3 se pakety berou
jako „jedináčci“ bez vzájemné vazby, na L4 je možné brát při filtrovánı́ v úvahu jejich vzájemné
vztahy. napřı́klad můžeme odlišit pakety, které navazujı́ spojenı́, od paketů, které patřı́ do již
existujı́cı́ho spojenı́.
P
8.3
FIREWALL
179
Paket navazujı́cı́ spojenı́ je důkladně prověřen (údaje z vrstev L3 a L4, napřı́klad zdrojová a cı́lová adresa, protokoly, zdrojové a cı́lové porty, přı́znaky nastavené podle jednotlivých protokolů,
cokoliv, co je v záhlavı́ch PDU) a pokud projde, vytvořı́ se v stavové tabulce záznam povolujı́cı́ dané
spojenı́. Pokud paket kontrolou neprojde úspěšně, záznam se nevytvořı́.
Pakety, které patřı́ do již navázaného spojenı́ (nebo se za takové vydávajı́), se filtrujı́ podle toho,
zda jejich spojenı́ je zaznamenáno ve stavové tabulce.
Stavová inspekce paketů se obvykle provádı́ na firewallu, nebo může jı́t o zařı́zenı́ přı́mo určená
k tomuto účelu. Jako SPI zařı́zenı́ můžeme využı́t také běžný počı́tač s nainstalovaným Linuxem
a jeho firewallem NetFilter (s rozhranı́m iptables), který SPI podporuje.
V současné době je SPI vpodstatě standardem kvalitnı́ch firewallů. Oproti běžnému paketovému
filtru nabı́zı́ většı́ bezpečnost při relativně malém zpomalenı́ provozu při filtrovánı́. Pokud takový
firewall je součástı́ jádra (rozšiřujı́cı́ modul jádra), dokáže chránit před napadenı́m i sám sebe.
IDS/IPS, DPI.
SPI můžeme brát jako základ pro IDS/IPS systémy:
1. IDS (Intrusion Detection System, systém pro detekci útoků) – pracuje podobně jako antivirus,
tedy použı́vá
P
• signatury útoků (vede si jejich databázi, kterou je nutné aktualizovat nebo „mı́t k dispozici v cloudu“),
• heuristiky (využı́vá statistické metody vyhodnocujı́cı́ provoz na sı́ti) a
• detekci neobvyklého chovánı́ sı́tě (zjišt’ujı́ se odchylky od běžného provozu na sı́ti).
Detekuje pokusy o průnik do systému a podá informaci zařı́zenı́, které dokáže na útok
reagovat. Detekce musı́ fungovat i při rozdělenı́ signatury (typického vzoru) do vı́ce paketů.
2. IPS (Intrusion Prevention System) – podobně jako IDS provádı́ detekci útoků, ale navı́c
aktivně reaguje. Reakce má útoku zabránit, proto také konkrétnı́ mı́sto IPS sondy je třeba
naplánovat tak, aby mohla přı́padně také zasahovat do konfigurace jiných sı́t’ových zařı́zenı́.
Firewall může mı́t integrovanou funkci (modul) IDS/IPS, ale obecně je bezpečnějšı́ (zvláště u většı́ch
sı́tı́) nasadit IDS/IPS odděleně od firewallu. Setkáváme se také s názvem Stavový paketový filtr
s hloubkovou kontrolou (Deep Packet Inspection), to je právě firewall s integrovaným modulem
IDS/IPS. Tento typ firewallu přidává dalšı́ možnosti definovánı́ pravidel souvisejı́cı́ s obvyklými
vlastnostmi komunikace s danou (známou) aplikacı́ či protokolem. Pokud napřı́klad zjistı́, že
protokol http je použı́ván pro jiný typ komunikace než s WWW server, tento požadavek zablokuje
jako podezřelý.
Dalšı́ informace:
• http://www.actinet.cz/bezpecnost informacnich technologii/l19/cl25/st1/j1/Uvod do
IDS/IPS.html
• http://www.symantec.com/connect/articles/intrusion-detection-terminology-part-one
• http://www.symantec.com/connect/articles/intrusion-detection-terminology-part-two
• http://www.systemonline.cz/clanky/systemy-pro-detekci-neopravneneho-pruniku.htm
P
8.3
FIREWALL
180
Obrázek 8.2: Schéma možného zapojenı́ IDS/IPS4
Proxy na aplikačnı́ vrstvě. Posuneme se ještě o vrstvu výše – na aplikačnı́ vrstvě TCP/IP pracujı́
proxy firewally (také aplikačnı́ brány). Pracujı́ s aplikačnı́mi protokoly, napřı́klad rozumı́ protokolu
HTTP, FTP, IMAP, dokážou pracovat s pakety obsahujı́cı́mi prvky pro ActiveX, apod.
P
Tento typ firewallu odděluje sı́tě až do té mı́ry, že počı́tač (server) ve vnějšı́ sı́ti nezná IP adresu
počı́tače ve vnitřnı́ sı́ti, se kterým komunikuje (vidı́ pouze IP adresu brány). Veškerá komunikace
je zpracovávána pomocı́ tzv. proxy – softwarových bran bud’ naprogramovaných pro konkrétnı́ typ
komunikace (protokol) s poměrně vysokým stupněm zabezpečenı́ (napřı́klad pro protokol FTP
nebo HTTP), nebo pomocı́ generické proxy s úrovnı́ bezpečnosti podobnou jako paketový filtr.
Proxy defacto zcela odděluje vnitřnı́ a vnějšı́ sı́t’ (v podobném smyslu jako NAT) a při filtrovánı́ využı́vá informace prakticky ze všech vrstev TCP/IP, protože při „prokopávánı́ “ k záhlavı́
protokolů vrstvy L7 procházı́ přes záhlavı́ předchozı́ch vrstev.
Rozlišujeme dva typy proxy:
1. Běžný (standardnı́) proxy – pro něj platı́ vše, co bylo dřı́ve o proxy napsáno. Filtruje všechny
pakety podle údajů z PDU protokolů aplikačnı́ vrstvy a nižšı́ch vrstev.
2. Dynamický proxy – chová se odlišně k různým paketům; k zahajujı́cı́m spojenı́ se chová stejně
jako prvnı́ typ proxy, ale k paketům patřı́cı́m do již vytvořeného spojenı́ se chová jako SPI
(tj. na nižšı́ vrstvě TCP/IP). Důsledkem je zrychlenı́ odbavovánı́ přı́chozı́ho i odchozı́ho
provozu.
Proxy nejen rozumı́ řazenı́ paketů do jednotlivých spojenı́, ale také umı́ sám spojenı́ navazovat.
Dalšı́ informace o proxy najdeme na
http://www.vutbr.cz/www base/zav prace soubor verejne.php?file id=15131
Dalšı́ informace o firewallech:
• http://www.actinet.cz/bezpecnost informacnich technologii/l19/cl44/st4/j1/Soucasnost a trendy
reseni firewallu.html
4
Zdroj: http://www.actinet.cz
8.4
VPN
•
•
•
•
•
181
http://www.actinet.cz/bezpecnost informacnich technologii/l19/cl25/st1/j1/Uvod do IDS/IPS.html
http://www.root.cz/serialy/openwrt/
http://bravenec.org/cs/clanky/openwrt/openwrt1
http://bravenec.org/cs/clanky/openwrt/openwrt2
http://www.vutbr.cz/www base/zav prace soubor verejne.php?file id=15131
V přı́lohách najdeme sekce o firewallu ve Windows a v Linuxu včetně potřebných přı́kazů pro
konfiguraci. Na straně 246 je sekce o firewallu ve Windows, na straně 274 je sekce o firewallu
v Linuxu (velmi podrobná včetně přı́kladů pravidel).
Úkoly
V přı́loze od strany 274 je sekce o firewallu NetFilter, ve které jsou na přı́kladech vysvětleny
nejdůležitějšı́ funkce firewallů. Projděte si dotyčnou sekci a ujasněte si princip filtrovánı́, SPI,
překladu adres a dalšı́ch.
8.3.3
OpenWRT
Zajı́mavým projektem je OpenWRT. Jedná se o embedded Linux (tj. Linux upravený pro určitý
konkrétnı́ typ zařı́zenı́, typicky firmware takového zařı́zenı́) pro routery některých výrobců, napřı́klad firmy Mikrotik (RouterBoard). Jeho výhodou oproti „originálnı́mu“ operačnı́mu systému
(napřı́klad u desek RouterBoard je to RouterOS taktéž založený na Linuxu) je to, že má k běžným
linuxovým distribucı́m mnohem blı́že než jiné embedded Linuxy. Zatı́mco obvykle se firmware
aktualizuje jako celek (to může být celkem nebezpečné, dotyčné zařı́zenı́ se při poruše při aktualizaci může zcela odrovnat), OpenWRT je pružný systém, který lze aktualizovat, konfigurovat
a jakkoliv měnit prakticky za provozu a můžeme při tom použı́vat jak běžný balı́čkovacı́ systém,
tak při konfiguraci třeba textový editor.
Jak bylo výše zmı́něno, OpenWRT použı́vá balı́čkovacı́ systém a tedy lze doinstalovat různé
balı́čky podle potřeby, výběr je veliký. Do distribuce patřı́ samozřejmě firewall NetFilter s přı́stupovým programem iptables, podporuje ftp, samba, telnet, ssh, lze doinstalovat X Window a nějakého
vhodného správce oken, konfigurujeme obvykle přes ssh (přı́padně lze přes ssh bezpečně provozovat grafické prostředı́). Ve výchozı́m stavu je tato distribuce vybavena typicky pro Wi-fi router,
což ale můžeme změnit podle svých vlastnı́ch potřeb.
8.4
VPN
VPN (Virtual Private Network) je, jednoduše řečeno, zabezpečené spojenı́ procházejı́cı́ nedůvěryhodným prostředı́m (obvykle Internetem). Použı́vá se v těchto přı́padech:
• Mobilnı́ zaměstnanec potřebuje na svých cestách zabezpečený přı́stup do firemnı́ (lokálnı́)
sı́tě, aby mohl přistupovat do firemnı́ho informačnı́ho systému a dalšı́ch zabezpečených
zdrojů. Do této kategorie bychom mohli zařadit i zaměstnance pracujı́cı́ doma. Tento přı́pad
nazýváme remote access (vzdálený přı́stup).
P
8.4
VPN
182
• Je třeba propojit dvě vzdálené lokálnı́ sı́tě (napřı́klad pobočky téže firmy), ale nechceme volit
poněkud drahé řešenı́ WAN sı́tě od telekomunikačnı́ firmy. Tento přı́pad se nazývá site-to-site.
• Je třeba komunikovat s obchodnı́m partnerem zabezpečeným komunikačnı́m kanálem, ale
zároveň ho nechceme pustit přı́mo do našı́ lokálnı́ sı́tě. Může se jednat o site-to-site nebo remote
access, podle skutečné konfigurace VPN.
Ve všech těchto přı́padech je třeba vybudovat zabezpečený šifrovaný tunel, přes který povede
komunikace nedůvěryhodným prostředı́m. Ve třetı́m přı́padě navı́c musı́me použı́t firewall, který
bude propouštět pouze komunikaci povolenou pro tento účel.
Pokud chceme využı́vat VPN, musı́me mı́t potřebný hardware či software. VPN je podporován v mnoha hardwarových zařı́zenı́ch (firewally, směrovače, přı́padně VPN koncentrátory), ale
v jednoduššı́ch přı́padech může stačit softwarová implementace.
VPN tunel do firemnı́ sı́tě ústı́ většinou bud’ přı́mo na routeru s firewallem na hranici lokálnı́
sı́tě, který je viditelný na Internetu, a nebo v demilitarizované zóně (tam se často umı́st’uje VPN
koncentrátor, což je vlastně jakási VPN brána), záležı́, kam v lokálnı́ sı́ti je třeba přes tunel přistupovat.
VPN řešenı́ by mělo zajistit následujı́cı́:
• autentizace – je třeba ověřit totožnost obou komunikujı́cı́ch bodů (např. uživatel s notebookem
na pracovnı́ cestě a firewall s podporou VPN v LAN firmy), přı́padně se zajišt’uje autentizace
přenášených PDU,
• autorizace – stanovenı́ konkrétnı́ch přı́stupových oprávněnı́,
• zajištěnı́ důvěrnosti dat – přenos je vždy šifrován,
• zajištěnı́ integrity dat – detekce pozměněnı́ paketu po cestě.
$
Šifruje se vždy některým algoritmem typickým pro daný typ řešenı́. Může se jednat napřı́klad
o SHA (Secure Hash Algorithm, jednosměrný hash algoritmus, často se použı́vá při přenosu hesel),
DES (Data Encryption Standard, algoritmus soukromého klı́če, dnes spı́še 3DES), Diffie-Hellman
nebo RSA (Rivest, Shamir and Adleman) – algoritmy veřejného klı́če (veřejný klı́č se může využı́t
při transportu soukromého klı́če, který se pak použı́vá v následné relaci). V současné době se zřejmě
nejvı́ce nasazuje šifrovacı́ algoritmus AES, který je považován za nejbezpečnějšı́ z jmenovaných.
8.4.1
IPSec VPN – na sı́t’ové vrstvě
Protokol IPSec (Internet Protocol Security) umožňuje vytvářet zabezpečená spojenı́ point-to-point
(tunely) na sı́t’ové vrstvě.
Tunel se vytvářı́ zapouzdřenı́m takto:
1. uvnitř je PDU přenášeného protokolu, většinou IP (ale může být také IPX, NetBEUI nebo
jiný),
2. následuje obalový protokol, což bývá obvykle IPSec (může být např. GRE, PPTP, L2TP nebo
jiný), zapouzdřená PDU je zašifrována a je přidáno bezpečnostnı́ záhlavı́,
3. nosný protokol sı́t’ové vrstvy (obvykle IP) v sobě zapouzdřı́ PDU vytvořenou v předchozı́m
kroku, aby bylo možné přenést paket přes „nechráněný“ Internet či jinou veřejnou sı́t’.
P
8.4
VPN
183
Bonusem je možnost takto zapouzdřit i takové protokoly, které nejsou běžně ve vnějšı́m prostředı́
podporovány, přı́padně zajistit využı́vánı́ soukromých IP adres (vnitřnı́ IP PDU je adresován soukromou cı́lovou IP adresou, ale aby bylo možné celou PDU doručit, vnějšı́ IP datagram má veřejnou
cı́lovou IP adresu hraničnı́ho zařı́zenı́ firemnı́ sı́tě podporujı́cı́ho VPN).
IPSec se také často kombinuje s protokoly GRE nebo L2TP pracujı́cı́mi na vrstvě L2. Jednı́m
z důvodů těchto kombinacı́ je problém IPSec při průchodu přes NAT, který modifikuje IP záhlavı́.
I pro tento přı́pad však existuje řešenı́, lze využı́t mechanismus NAT-T (NAT Traversal), který
zapouzdřı́ paket do UDP a tı́m znemožnı́ pozměněnı́ IP záhlavı́. Označuje se IPSec over UDP nebo
IPSec over NAT-T.
Šifrovánı́ v IPSec se provádı́ jednı́m z těchto dvou způsobů:
• tunelovacı́ režim – celý původnı́ IP datagram se zašifruje a připojı́ se záhlavı́ IPSec (a pak
samozřejmě záhlavı́ nosného protokolu s novou IP adresou),
$
• transportnı́ (přenosový) režim – šifruje se datová část zapouzdřovaného paketu bez záhlavı́,
pak se přidá IPSec záhlavı́, před ně se předstune původnı́ záhlavı́ zapouzdřených dat.
Tunelovacı́ režim je bezpečnějšı́ (celé zapouzdřené IP záhlavı́ je skryto, šifrováno), transportnı́
režim je pružnějšı́ (můžeme použı́vat prvky z původnı́ho IP záhlavı́, napřı́klad pro QoS) a pakety
jsou kratšı́ (tedy menšı́ dopad na propustnost sı́tě). Srovnánı́ vidı́me na obrázku 8.3.
Tunelovacı́ režim je použı́ván předevšı́m při spojenı́ch site-to-site (propojenı́ dvou poboček nebo
firmy a obchodnı́ho partnera), zatı́mco transportnı́ režim je typičtějšı́ pro připojenı́ jednoho počı́tače
(mobilnı́ zaměstnanec či zaměstnanec pracujı́cı́ doma) s firemnı́ sı́tı́ (tedy remote acces spojenı́).
Původnı́ IP datagram:
IP záhlavı́1
Tělo datagramu
• tunelovacı́ režim:
IP záhlavı́2
IPSec záhlavı́
Šifrováno:
IP záhlavı́1
Tělo datagramu
• transportnı́ (přenosový) režim:
IP záhlavı́1
IPSec záhlavı́
Šifrováno:
Tělo datagramu
Obrázek 8.3: PDU před a po zašifrovánı́ do IPSec tunelu
Technicky vzato, existujı́ dva typy IPSec záhlavı́: AH (Authentication Header) a ESP (Encapsulated Security Payload). Zatı́mco AH je jednoduššı́, zajišt’uje pouze autentizaci a integritu dat, ale ne
šifrovánı́, záhlavı́ ESP je bezpečnějšı́ (zajišt’uje autentizaci a šifrovánı́). V současné době se použı́vá
obvykle jen ESP (lze použı́t dokonce obojı́ najednou, tedy AH/ESP).
Při vytvářenı́ jakéhokoliv (tedy i IPSec) tunelu je třeba nejdřı́v dojednat parametry bezpečného
přidruženı́ (SA – Security Association). IPSec pro tento účel použı́vá protokol IKE (Internet Key
Exchange), nynı́ ve verzi 2.
P
8.4
VPN
184
V protokolu IPv6 je již IPSec nativně implementován (tak to bylo už v původnı́m návrhu
IPv6, k verzi IPv4 byl IPSec dodatečně přidán jako „pomocný“ protokol zajišt’ujı́cı́ šifrovánı́). Proto
přechod na IPv6 má jeden bonus – snadnějšı́ vytvářenı́ IPSec tunelů.
Jak se IPSec konfiguruje. Následujı́cı́ text se vztahuje ke konfiguraci IPSec v Linuxu za předpokladu, že použı́váme IPv6 (pro IPv4 by bylo pár odlišnostı́, předevšı́m v adresách).
IPSec se konfiguruje podobným způsobem jako napřı́klad firewall – definujeme pravidla a dalšı́
parametry (v tzv. tabulce politik). Určujeme napřı́klad, že pakety přı́chozı́ z konkrétnı́ adresy
(vzdálené pobočky) se majı́ zpracovat mechanismem IPSec (dešifrovat apod.), pakety odchozı́ na
tutéž adresu naopak zašifrovat, přidat IPSec záhlavı́ apod., pakety směřujı́cı́ do vnitřnı́ sı́tě se majı́
nechat tak jak jsou, atd.
V Linuxu se pro práci s IPSec použı́vajı́ programy setkey a racoon, obojı́ v balı́ku programů IPSec Tools. Konfigurace se provádı́ v textových konfiguračnı́ch souborech (/etc/racoon/racoon.conf
a /etc/racoon/setkey.conf, dále potřebujeme chráněný soubor s hesly) a určujeme napřı́klad
výchozı́ parametry pro typ šifrovánı́ a autentizace, který klı́č se má použı́t, a samozřejmě politiky
(zásady) pro přı́chozı́ a odchozı́ provoz pro zadané adresy sı́tı́.
Ve Windows a na sı́t’ových zařı́zenı́ch konfigurovaných přes webové rozhranı́ se konfigurace
provádı́ většinou „myšı́“, napřı́klad ve Windows Server máme k dispozici (grafickou) konzolu
v Start ï Programs ï Administrative Tools ï Local Security Settings. Kromě toho je ve Windows Server
k dispozici program ipsecpol pro definovánı́ IPSec politik (zásad).
Na klientovi je připojenı́ vcelku jednoduché. VPN je předem nakonfigurována na serveru,
na klientovi vpodstatě konfigurujeme nové připojenı́ k sı́ti. Napřı́klad ve Windows XP zvolı́me
Ovládacı́ panely ï Sı́t’ová připojenı́ ï Vytvořit nové připojenı́, zvolı́me připojenı́ k firemnı́ sı́ti, VPN, atd.
V průvodci potřebujeme IP adresu VPN serveru, se kterým budeme komunikovat. Ve vlastnostech
připojenı́ dále nakonfigurujeme protokol IPSec, včetně bezpečnostnı́ch nastavenı́.
Podrobnosti předevšı́m o Linuxu najdeme v odkazech na konci sekce o VPN, předevšı́m v odkazu http://www.ipsec-howto.org/ipsec-howto.pdf.
8.4.2
GRE a L2TP tunely
Protokol GRE (Generic Routing Encapsulation) pracuje na vrstvě L2. Jeho výhodou je univerzálnost,
dokáže zapouzdřit i jiné typy PDU sı́t’ové vrstvy ISO/OSI (nejen TCP/IP) než jen IP. Jeho hlavnı́m
účelem je předávat na dálku multicast a broadcast vysı́lánı́.
Na druhou stranu, velkou nevýhodou GRE je, že neprovádı́ šifrovánı́, proto se ve skutečnosti
nejedná o „pravý“ VPN tunel. V praxi je GRE zapouzdřován do tunelů VPN (napřı́klad v kombinaci
s IPSec), aby byla konverzace zároveň šifrována.
Hlavnı́m účelem protokolu L2TP je tunelovánı́ (zapouzdřovánı́) paketů protokolu PPP (ten se
použı́vá pro přenos dat přes telefonnı́ sı́t’). Stejně jako GRE, ani L2TP neprovádı́ šifrovánı́, tedy je
obvykle kombinován s IPSec (v transportnı́m módu).
L2TP je podporován v Linuxu i ve Windows. V Linuxu se dnes doporučuje použitı́ OpenL2TP
(s využitı́m IPSec), ve Windows se nacházı́ klient L2TP/IPSec pro transportnı́ mód. Ve Windows
P
P
8.4
VPN
185
se také můžeme setkat s protokolem SSTP (Secure Socket Tunneling Protocol), který přenášı́ PPP
nebo L2TP šifrované s využitı́m protokolu SSL.
V přı́loze na straně 266 je ukázka nastavenı́ jednoduchého GRE tunelu mezi dvěma vzdálenými
sı́těmi (mezi routery s nainstalovaným Linuxem).
Úkoly
V přı́loze si projděte postup konfigurace GRE tunelu.
8.4.3
SSL/TLS VPN
SSL (Secure Sockets Layer) a jeho následnı́k TLS (Transport Layer Security) pracujı́ na vrstvách L4
a vyššı́ch.
Zatı́mco IPSec je sı́t’ové řešenı́ (transparentnı́ pro různé aplikace), SSL/TLS je aplikačnı́ řešenı́
(tj. musı́ být podporováno konkrétnı́ aplikacı́, jejı́ž komunikace má být šifrována). Ve webových
prohlı́žečı́ch je podpora SSL/TLS již dávno zabudována, takže s funkčnostı́ tohoto řešenı́ nebývajı́
problémy alespoň v přı́padech, kdy se komunikuje přes protokol HTTP nebo podobné. Pokud
aplikace nepodporuje SSL/TLS, je možné to řešit napřı́klad pomocı́ STunnel.5
P
Typické použitı́ tohoto typu tunelů je pro připojenı́ mobilnı́ho či doma pracujı́cı́ho zaměstnance,
tj. typ remote access.
SSL sice podporuje oboustrannou autentizaci, ale často se setkáváme s řešenı́mi využı́vajı́cı́mi
jednostrannou autentizaci (autentizuje se dotyčný externı́ zaměstnanec). Rovněž integrita dat a šifrovánı́ jsou tı́mto protokolem zajištěny, šifrujı́ se pouze přenášená data. Použı́vá se kombinace
veřejného a soukromého klı́če, je možné použı́t certifikáty.
SSL je považováno za sice méně bezpečné, ale zato pružnějšı́ řešenı́ (napřı́klad s mechanismem
NAT má IPSec problémy, kdežto SSL si s nı́m poradı́ celkem bez problémů).
Zajı́mavou implementacı́ SSL/TLS VPN je projekt OpenVPN. Běžı́ na většině známých unixových systémů včetně Linuxu, existuje i varianta pro Windows.
8.4.4
SSH
Pro vzdálený přı́stup ke konkrétnı́mu počı́tači (remote access) se dřı́ve, alespoň u počı́tačů s unixovými systémy, použı́val Telnet. Tento protokol však nenı́ bezpečný (o tunelech se ani nedá mluvit),
protože se nešifrujı́ dokonce ani přihlašovacı́ informace, heslo se obecně přenášı́ v textové formě.
V současné době se velmi často ke vzdálenému počı́tači přistupuje přes protokol SSH (Secure
Shell). Tento protokol se postupně vyvı́jel – v prvnı́ verzi SSH-1 nebyl považován za moc bezpečný,
jeho implementace obsahovaly poměrně hodně bezpečnostnı́ch chyb, navı́c třebaže původně byl
uvolněn jako freeware, později to bylo s licencemi horšı́. Dnes se setkáváme spı́še s implementacemi
verze SSH-2 vydanými sdruženı́m IETF (od roku 1997), SSH-2 je také standardem RFC 4252.
5
$
http://www.stunnel.org/
P
8.4
VPN
186
Jedná se o typickou komunikaci typu klient-server (sedı́me u klienta, přihlašujeme se k serveru),
tedy existuje klientská a serverová implementace SSH. Serverové implementace jsou určeny spı́še
pro unixové systémy, protože typické využitı́ SSH je právě pro připojenı́ k unixovému serveru.
SSH je protokolem vyššı́ch vrstev a komunikuje přes TCP (protože je třeba vytvořit spojenı́, které
SSH dále zabezpečuje). Narozdı́l od TLS a některých dalšı́ch podobných protokolů SSH-2 nabı́zı́
správu vı́ce navázaných relacı́ najednou (TLS pouze jedno spojenı́).
SSH podporuje několik autentizačnı́ch metod, ze kterých se použı́vá nejčastěji autentizace pomocı́ klı́čů. Během autentizace se použijı́ asymetrické autentizačnı́ klı́če, v SSH-2 se použı́vá šifrovánı́
DSA (v SSH-1 to bylo méně bezpečné RSA). Během komunikace se data šifrujı́ některou z rychlých
symetrických metod, napřı́klad 3DES. Jinou možnostı́ autentizace, která se použı́vá předevšı́m
v komerčnı́ sféře (nejen), je GSSAPI. Jedná se o využitı́ externı́ho autentizačnı́ho mechanismu,
napřı́klad Kerberos.
Tento protokol je přirozeným způsobem využitelný pro vytvářenı́ šifrovaných tunelů. Funguje
na principu předávánı́ (forwardovánı́) provozu na porty, na které je napojen SSH tunel. SSH server
naslouchá na TCP portu 22.
Existuje vı́ce různých implementacı́ SSH. K nejoblı́benějšı́m patřı́ nástroj OpenSSH, pro který
existuje klientská i serverová varianta (spı́še pro unixové systémy). Instalace a použı́vánı́ jsou
popsány v přı́loze na straně 290. Pro Windows existujı́ mezi volně šiřitelným softwarem spı́še
klienty, napřı́klad PuTTY.
P
P
$
Když použı́váme SSH, měli bychom využı́vat bezpečné verze softwaru pro přenos dat. V Unixu
(včetně Linuxu) použı́váme přı́kazy scp (kopı́rovánı́, mı́sto cp) a sftp (mı́sto ftp). Existuje také
souborový manažer WinSCP implementujı́cı́ obdobu těchto přı́kazů.
Úkoly
Ve zmı́něné přı́loze si projděte instalaci a použı́vánı́ SSH. Jsou tam také odkazy na dalšı́ informace.
8.4.5
MPLS VPN
Narozdı́l od předchozı́ho řešenı́ se MPLS sı́tě použı́vajı́ spı́še pro implementaci propojenı́ firemnı́ch
poboček tunelem (přı́p. firmy a obchodnı́ho partnera), tedy VPN typu site-to-site. S MPLS sı́těmi
jsme se již seznámili a vı́me, že se použı́vá systém záhlavı́, z nichž jedno je určeno právě pro
virtuálnı́ sı́tě. Řešenı́ pracuje na rozhranı́ vrstev L2 a L3.
V sı́ti MPLS VPN rozeznáváme tato zařı́zenı́:
• CE (Customer Edge) – hraničnı́ uzel sı́tě zákaznı́ka, přes který se data přenášejı́ do MPLS
tunelu,
• PE (Provider Edge) – hraničnı́ uzel sı́tě poskytovatele řešenı́, je přı́mo spojen s uzlem CE,
• P (Provider) – vnitřnı́ uzly MPLS sı́tě poskytovatele, vpodstatě Core MPLS směrovače.
Uzly CE nejsou součástı́ MPLS sı́tě, jsou na nich vyžadovány pouze protokoly TCP/IP (konkrétně
hlavně IP). Uzly PE jsou hraničnı́mi (LER) uzly MPLS sı́tě a implementujı́ protokol BGP (to je jeden
P
8.4
VPN
187
z externı́ch směrovacı́ch protokolů, pro MPLS je typický), přı́p. iBGP (distribuce tabulek mezi uzly).
K jednomu PE uzlu může být připojeno vı́ce CE uzlů.
IP datagram přicházejı́cı́ z CE na PE je opatřen dvěma MPLS hlavičkami
• vnitřnı́ (B=1) bude využita až na druhém konci tunelu, určuje CE přı́jemce,
• vnějšı́ (B=0) určuje cestu v MPLS sı́ti přes P uzly
VRF tabulka (VPN Routing and Forwarding Table) je tabulka směrovacı́ch informacı́ pro konkrétnı́
VPN a sı́tě. Nacházı́ se na uzlech PE, jeden PE může obsahovat i vı́ce VRF.
V tabulce je konkrétnı́ port (rozhranı́) asociován s konkrétnı́ VRF (patřı́ do přı́slušné VPN),
pokud paket přijde z rozhranı́ napojeného na určitou VRF, podle dané VRF se rozhoduje, co s nı́m.
To znamená, že VRF určuje, ke kterému CE se má dostat paket přı́chozı́ z daného rozhranı́.
Obrázek 8.4: Schéma MPLS VPN a VRF tabulek6
Na obrázku 8.4 vidı́me ukázku MPLS VPN sı́tě, kde napřı́klad LAN 2 (Site 2) patřı́ do VPN
A a VPN B, proto ve VRF tabulce na přı́slušném PE určené pro tuto LAN najdeme směrovánı́ do
všech sı́tı́ patřı́cı́ch do těchto dvou VPN (tj. sı́tı́ 1, 2 a 3).
Pro MPLS VPN existujı́ 2 základnı́ řešenı́ – MPLS Layer-3 VPN, MPLS Layer-2 VPN.
Dalšı́ informace o VPN:
•
•
•
•
6
http://wh.cs.vsb.cz/sps/images/0/04/Kratos-MPLS-VPN.pdf
http://www.cisco.com/en/US/docs/net mgmt/vpn solutions center/1.1/user/guide/VPN UG1.html
http://www.linuxsoft.cz/article.php?id article=1800
http://www.ipsec-howto.org/ipsec-howto.pdf
Zdroj: http://www.cisco.com/en/US/docs/net mgmt/vpn solutions center/1.1/user/guide/VPN UG1.html
8.5
SPRÁVA SÍTĚ
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
8.5
8.5.1
188
http://openvpn.net/
http://www.root.cz/clanky/openvpn-vpn-jednoduse/
http://www.root.cz/clanky/openvpn-vpn-jednoduse-2/
http://idoc.vsb.cz/cit/servery/ldap/navod prechod na ldaps/ar01s05.html
http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=219&clanekID=230
http://www.samuraj-cz.com/clanek/vpn-1-ipsec-vpn-a-cisco/
http://www.openl2tp.org/documentation
http://www.soom.cz/index.php?name=articles/show&aid=319
http://wh.cs.vsb.cz/mil051/index.php/%C5%A0ifrov%C3%A1n%C3%AD IP provozu
protokolem IPSec
http://dolezel.net/post/2008/03/09/Konfigurace-L2TPIPSec-klienta.aspx
http://www.cs.vsb.cz/grygarek/TPS/projekty/0607Z/L2TP.pdf
http://www.cs.vsb.cz/grygarek/TPS/projekty/0506Z/krs008 TPS projekt.pdf
http://www.datacom.cz/Professional-Computing-clanek-SSLVPN
http://www.cisco.com/en/US/tech/tk436/tk428/technologies tech note09186a0080125b01.shtml
http://net.infocom.uniroma1.it/corsi/Network%20Infrastructures/lucidi/MPLS-QoS&TE.pdf
http://www.itu.int/ITU-D/arb/COE/2009/MPLS/Documents/Doc6-MPLS%20VPN-ppt.pdf
Správa sı́tě
NMS
Správa sı́tě v sobě zahrnuje tyto činnosti:
• dohled, kontrola (monitorovánı́) – na fyzické vrstvě (stav média apod.), linkové vrstvě (chybovost rámců, atd.) i vyššı́ch, interpretace shromážděných údajů
P
• diagnostika a řešenı́ poruch, předcházenı́ poruchám
• správa jednotlivých prvků sı́tě, řešenı́ změn topologie (napřı́klad přidánı́ nového uzlu)
• účtovánı́ využı́vánı́ zdrojů
V rámci modelu ISO/OSI většina těchto činnosti probı́há na aplikačnı́ vrstvě, a to vždy v některé
formě na všech uzlech sı́tě.
Správa sı́tě je služba využı́vajı́cı́ řadu nástrojů, aplikacı́ a zařı́zenı́ k monitorovánı́, údržbě
a zabezpečovánı́ sı́tě, a to v co nejvyššı́ mı́ře automatizace.
Rozlišujeme řı́dicı́ a řı́zené entity. Řı́zené entity odesı́lajı́ zprávy obsahujı́cı́ hlášenı́ o událostech
nebo problémech, řı́dicı́ entity na ně adekvátně reagujı́, napřı́klad
• zpravı́ operátora mailem nebo jiným způsobem,
• zapı́šou událost do LOG souboru (logovánı́ událostı́),
• vypnou nebo restartujı́ systém, odhlásı́ „problémového“ uživatele, odstřelı́ „problémový“
proces,
• provedou automatickou úpravu konfigurace systému, přenastavı́ určené limity.
P
8.5
SPRÁVA SÍTĚ
189
Softwarové agenty sbı́rajı́ informace z koncových zařı́zenı́ (řı́zené entity) a odesı́lajı́ řı́dicı́m entitám.
Network Management System (NMS) je systém řı́zenı́ sı́tě zahrnujı́cı́ řı́dicı́ entity, databázi a protokoly řı́zenı́ sı́tě. Nejznámějšı́ protokoly pro NMS:
P
• SNMP (Simple Network Management Protocol)
• CMIP (Common Management Information Protocol)
8.5.2
ISO model řı́zenı́ sı́tě
Řı́zenı́ sı́tě lze rozdělit do několika oblastı́.
Řı́zenı́ výkonu (performance management) – účelem je zajistit, aby výkon sı́tě byl na přijatelné
úrovni. Patřı́ zde proměnné veličiny jako je průchodnost sı́tě, lhůty pro odezvu uživatelů, optimálnı́
využı́vánı́ kabelů a jiných spojových cest a prvků, atd. Zahrnuje:
1. shromážděnı́ souvisejı́cı́ch dat o veličinách
2. analýza dat a stanovenı́ úrovně pro normálnı́ provoz
3. stanovenı́ hornı́ (resp. u některých veličin dolnı́) hranice s tı́m, že překročenı́ této hranice je
indikováno jako problém, který je třeba řešit
Při překročenı́ stanovených hranic je informován NMS.
Řı́zenı́ konfigurace (configuration management) znamená monitorovánı́ konfigurace sı́tě a připojených systémů (hardware i software) a jejich ovlivňovánı́. Pro každou sledovanou veličinu
(verze operačnı́ho systému s aktualizacemi, verze protokolu TCP/IP, apod.) je vytvořeno pravidlo,
a pokud nenı́ splněno, musı́ být vyvozeny důsledky.
Řı́zenı́ uživatelských účtů (accounting management) znamená definovánı́ regulačnı́ch parametrů
pro uživatele a skupiny uživatelů. Vhodná regulace minimalizuje problémy v sı́ti, předevšı́m při
využı́vánı́ zdrojů (hardware, vyhrazené mı́sto v paměti, atd.), a maximalizuje férovost využı́vánı́
zdrojů v sı́ti vzhledem k ostatnı́m uživatelům.
Řı́zenı́ chyb (fault management) představuje detekci, evidenci (log soubory), oznamovánı́ a,
pokud je to možné, také automatické řešenı́ problémů, které v sı́ti mohou vzniknout. o jeden
z nejdůležitějšı́ch modulů systémů řı́zenı́ sı́tě, protože neodchycené chyby mohou způsobit zpomalenı́ komunikace, ztrátu dat nebo obecně neakceptovatelné zhoršenı́ celkového provozu na sı́ti
(přı́padně zhroucenı́ sı́tě).
Modul využı́vá údaje zı́skávané a uložené v rámci ostatnı́ch funkcı́ řı́zenı́ sı́tě, detekuje možné
problémy (aby byly co nejdřı́ve zachyceny), navrhuje a testuje řešenı́.
Řı́zenı́ bezpečnosti (security management) znamená řı́zenı́ přı́stupu ke zdrojům na sı́ti podle
stanovených pravidel, zabráněnı́ poškozenı́ systému (at’už úmyslnému nebo neúmyslnému) a vynesenı́ citlivých informacı́.
V hierarchické sı́ti jsou stanoveny oblasti autorizované a neautorizované, autorizace může být
také vı́ceúrovňová.
8.6
MANAGEMENT V TCP/IP
8.5.3
190
Management v ISO/OSI
Jedná se o centralizovaný systém založený na protokolu CMIP (Common Management Information
Protocol). Management můžeme rozdělit do třı́ částı́:
• systémový management (také sı́t’ový, network management) – působı́ v aplikačnı́ vrstvě, sloužı́
jako rozhranı́ k ostatnı́m částem managementu, tj. provádı́ úkoly souvisejı́cı́ s vı́ce vrstvami
P
• vrstvový management – pracuje v rámci jedné vrstvy
• protokolová operace – také v rámci jedné vrstvy, ale pouze pro jediný přı́pad komunikace
Jedná se o objektový model (pracuje s objekty a jejich vlastnostmi – atributy, operacemi, vztahem
k jiným objektům, použı́vá ISA hierarchii):
• manažer (správce) – programové vybavenı́ na stanici sı́t’ového managementu (centrálnı́)
• agent – programové vybavenı́ na jednotlivých uzlech sı́tě, posı́lá zprávy o (mimořádných)
událostech manažerovi
• MIB (Management Information Base) – objektová databáze řı́zených objektů, v tomto modelu
binárnı́
MIB
je tedy databáze řı́zených objektů. Pro každý objekt je zde
• jméno, třı́da objektu,
P
• atributy jako uspořádané dvojice typ–hodnota,
• chovánı́ – reakce předpokládaná a skutečná na řı́dicı́ operace
• hlášenı́ – o událostech souvisejı́cı́ch s objektem včetně informace, co má být agentem sděleno
manažerovi
• výčet operacı́, které je možno s objektem provádět (u třı́dy)
Protokol CMIP pracuje na aplikačnı́ vrstvě uzlů sı́tě. Při komunikaci použı́vá službu se spojenı́m (tj. pokud nelze navázat zcela spolehlivě spojenı́, CMIP nemůže komunikovat s agenty), což
může být svým způsobem nevýhoda. Pro reprezentaci řı́dicı́ch informacı́ se použı́vá jazyk ASN.1
(Abstract Syntax Notation One), který je pro tyto účely běžný (setkáme se s nı́m i u SNMP).
8.6
8.6.1
P
Management v TCP/IP
SNMP
V TCP/IP je správa prováděna pomocı́ protokolu SNMP (Simple Network Management Protocol).
Ve skutečnosti může běžet i nad jiným protokolem než IP, ale téměř výhradně se setkáme s použitı́m
nad IP.
SNMP (resp. jeho nástavby) je v současné době nejpoužı́vanějšı́m protokolem pro správu sı́tě
a je široce podporován prakticky v každém zařı́zenı́, které je možné připojit k sı́ti (také tiskárny,
nejrůznějšı́ čidla a analyzátory, přı́stupové body, atd.).
P
8.6
MANAGEMENT V TCP/IP
191
NMS
Agent 1
Agent 2
Agent 3
MIB uzlu 1
MIB uzlu 2
MIB uzlu 3
Obrázek 8.5: Komunikace v SNMP
Protokol SNMP existuje ve třech verzı́ch. Současná verze je SNMPv3, ale přesto je momentálně
nejpoužı́vanějšı́ verze SNMPv2, přesněji jejı́ varianta SNMPv2c. Hlavnı́, a velmi důležitý rozdı́l mezi
verzı́ 3 a předchozı́mi je úroveň zabezpečenı́ komunikace. Staršı́ verze použı́vajı́ při autentizaci
pouze (textové) heslo – community string (přesněji dvě – read comminity string pro čtenı́, write
community string pro povolenı́ zápisu). SNMPv3 již využı́vá bezpečnějšı́ metody – přı́stupové
jméno a heslo, kontrolnı́ součty MD5, šifrovánı́ DES, řı́zenı́ přı́stupu k objektům.
SNMPv2 přinesl oproti předchozı́ verzi napřı́klad podporu komunikace mezi různými správci
(ve verzi SNMPv1 se s vı́ce správci ani moc nepočı́talo) a vylepšenı́ zabezpečenı́ komunikace.
I nadále se sice použı́vajı́ community strings, ale byly přidány nové mechanismy jednoznačné
identifikace entit.
Hlavnı́ vlastnostı́ SNMP je jednoduchost. Podobně jako CMIP, i SNMP použı́vá koncept agent–
správce (manager), ale funkce těchto modulů jsou jinak rozděleny. Každý uzel sı́tě (spravované
zařı́zenı́ – managed device) může obsahovat jakékoliv množstvı́ agentů specializovaných na určitou
činnost. V sı́ti musı́ existovat alespoň jeden správce, může jich být vı́ce.
Komunikace mezi agentem a správcem probı́há předevšı́m pomocı́ protokolu UDP. Tento protokol však nepodporuje potvrzenı́ doručenı́ (ale na druhou stranu je rychlý a zası́lánı́ obvykle
funguje), proto SNMPv2 a vyššı́ obsahuje vlastnı́ mechanismus kontroly doručenı́. SNMP podporuje dva typy komunikace:
1. Dotaz–odpověd’ – aktivita je na straně správce, správce odesı́lá dotazy agentům a přijı́má jejich
reakce. Správce posı́lá dotazy agentovi na port 161, agent odpovı́dá z portu 161 na dynamický
port správce (tzn. čı́slo portu se měnı́).
2. Trap – aktivita je na straně agentů, agenty odesı́lajı́ trapy (oznámenı́) správci napřı́klad při
výskytu definované události, překročenı́ zadané hodnoty, změně topologie sı́tě (napřı́klad
připojenı́ nového uzlu) nebo v pravidelných intervalech. Agent posı́lá správci trapy ze svého
dynamického portu (s různými čı́sly) na port 162. Tento typ komunikace je běžnějšı́.
O skupině NMS v rámci jedné administrativnı́ domény hovořı́me jako o komunitě. Každá komunita
je jednoznačně identifikována řetězcem community name. Ve staršı́ch verzı́ch SNMP se použı́vá jako
jednoznačný identifikátor při autentizaci.
Protokol SNMP je asynchronnı́, transakčně orientovaný, typu klient/server (komunikace je
většinou typu dotaz–odpověd’).
P
P
P
8.6
8.6.2
MANAGEMENT V TCP/IP
192
MIB-II
Také se použı́vá databáze MIB, ale má obecně jinou strukturu, data jsou uložena v textové formě
(obslužný modul MIB je naprogramován v jazyce ASN.1, který je pro tyto účely v TCP/IP typický).
Je sice objektová (v tom smyslu, že pracujeme s objekty), ale narozdı́l od OSI MIB je řı́zená atributy
(nepoužı́vá plně objektový přistup, přistupujeme přes vlastnosti objektů).
P
Ve skutečnosti se v současných zařı́zenı́ch setkáme vždy s podporou MIB-II, tedy druhé verze
MIB. V následujı́cı́m textu budeme pro stručnost použı́vat název MIB, ale vždy půjde o MIB-II.
MIB je tvořena stromem s jediným kořenem. Kořen obsahuje „prázdnou hodnotu“, jeho účelem
je pouze spojovat z něho vycházejı́cı́ větve. Všechny uzly kromě kořenu majı́ přidělen textový
název a čı́selnou hodnotu – OID (Object ID), OID jednoznačně odlišuje uzly se stejným „rodičem“
– viz obr. 8.6 na str. 192. Textový název je určen spı́še pro „lidskou orientaci“, nemá v databázi
žádný jiný význam.
.
ITU-T (0)
standard (0)
joint-iso-itu
(2)
ISO (1)
registration
authority (1)
member
body (2)
org (identified
organization, 3)
DoD (Department
of Defence, 6)
internet (1)
directory (1)
mgmt (management, 2)
experimental
(3)
private (4)
at (3)
interfaces (2)
IP (4)
ICMP (5)
SNMPv2 (6)
enterprise (1)
MIB-2 (1)
system (1)
security (5)
UDP (7)
TCP (6)
SNMP (11)
transmission
(10)
Obrázek 8.6: SNMP MIB (zkrácená)
Uzly (objekty) v MIB, které jsou přı́mými potomky kořene, jsou nazvány podle organizacı́,
jejichž protokoly využı́vajı́ podstromy těchto uzlů (napřı́klad ISO nebo ITU). Některé části (větve)
MIB jsou standardizovány orgranizacı́ IETF, dalšı́ vydávajı́ výrobci sı́t’ových zařı́zenı́. Fyzicky je
P
8.6
MANAGEMENT V TCP/IP
193
tedy MIB uložena obvykle ve vı́ce než jednom (textovém) souboru, aby zpracovánı́ zde uložených
dat bylo dostatečně pružné a aby byla snadněji rozšiřitelná.
Adresa objektu v MIB je sekvence
• názvů uzlů na cestě od kořene stromu – pro lidi, objekty oddělujeme lomı́tkem nebo tečkou,
NEBO
P
• čı́sel OID uzlů na cestě od kořene stromu – pro kohokoliv/cokoliv jiného, objekty oddělujeme
tečkou (včetně prázdného názvu kořene, tedy celý řetězec vlastně začı́ná tečkou).
Napřı́klad podle obrázku 8.6 má uzel enterprise určený pro firemnı́ uzly (zařı́zenı́ různých výrobců)
tuto textovou a OID adresu:
• .iso.org.dod.internet.private.enterprise
• .1.3.6.1.4.1
Každé sı́t’ové zařı́zenı́, protokol či hodnota (resp. přiřazený objekt), které lze přes MIB spravovat,
má svou unikátnı́ OID adresu, která je stejná v jakékoliv MIB, tedy všechny OID adresy musı́ být
globálně jedinečné.
Listy stromu MIB jsou skalárnı́ objekty, jedná se o proměnné obsahujı́cı́ konkrétnı́ hodnotu využı́vanou pro účely řı́zenı́ sı́tě (napřı́klad počet paketů procházejı́cı́ch routerem). Proměnné mohou
být uspořádány i do tabulky (tabulkové objekty). SNMP poskytuje omezenou možnost pohybovat se
v tabulce – po sloupcı́ch. Typy proměnných v MIB:
1. čı́selné
2.
3.
4.
5.
• běžný Integer
• Counter – pro čı́tače, při dosáhnutı́ maximálnı́ hodnoty se vynulujı́, sloužı́ předevšı́m
pro zjištěnı́ rychlosti sledovánı́ změn
• Gauge (mı́ra) – pokud sledovaná veličina přesáhne danou hranici, hodnota Gauge zůstává na maximálnı́ hodnotě a „nepřeteče“
• Time Ticks – sleduje čas (v setinách sekundy) od zadané události, napřı́klad od spuštěnı́
zařı́zenı́
IP Address – zde bývá uložena IP adresa
Octet String – posloupnost oktetů, použı́vá se pro ukládánı́ znakových řetězců
Object Identifier – OID řetězec některého objektu
tabulka hodnot výše uvedených typů.
K proměnným se přistupuje poněkud zvláštnı́m způsobem. Pokud se jedná o jednoduchou proměnnou (takovou, která nenı́ tabulkou), syntaxe je
.cesta.název_proměnné.0
Pokud se jedná o tabulku, pak mı́sto čı́sla 0 na konci použijeme index v tabulce.
Přı́klad
K proměnné sysUpTime ve větvi system vede cesta
.iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0
.1.3.6.1.2.1.1.3.0
nebo čı́selně
P
8.6
MANAGEMENT V TCP/IP
194
K hodnotám v tabulkách přistupujeme tak, že mı́sto čı́sla 0 na konci dosadı́me index v tabulce
(od 1), napřı́klad k hodnotám v tabulce ukazujı́cı́m stav portů zařı́zenı́ (živý/mrtvý, v Ethernetu to
obvykle znamená je/nenı́ něco připojeno) přistupujeme takto:
.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifOperStatus.1
.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifOperStatus.2
.iso.org.dod.internet.mgmt.mib-2.interfaces.ifTable.ifEntry.ifOperStatus.3
atd., hodnota může být bud’ up(1) nebo down(2). V interfaces je jednoduchá čı́selná proměnná
ifNumber, ve které máme uložen počet rozhranı́ v systému (number of interfaces). Je zřejmé, že na
pracovnı́ stanici bude ifNumber.0 = 2 (jedno fyzické rozhranı́ a jedno loopback), přı́padně nějaký
ten výtvor virtualizačnı́ho softwaru, na směrovači bude rozhranı́ vı́ce.
Uvádı́me zde sice „absolutnı́“ adresy, ale je možné adresovat také relativně uvnitř daného MIB
souboru (skupiny), napřı́klad ve skupině interfaces, ip nebo system.
Struktura MIB je celkem logická. Jak bylo výše uvedeno, ve větvi mib-2 najdeme proměnné, které
se netýkajı́ přı́mo konkrétnı́ho výrobce (tj. obecné informace), kdežto ve větvi private.enterprise jsou
proměnné týkajı́cı́ se výrobků od konkrétnı́ch výrobců (záležı́, co konkrétně v přı́slušném sı́t’ovém
zařı́zenı́ najdeme). Zařı́zenı́, která nejsou pro MIB standardizovaná, jsou obvykle umı́stěna ve větvi
experimental.
Obecné informace o zařı́zenı́, s jemib-2 (1)
hož MIB pracujeme, najdeme předevšı́m v podstromu uzlu system. Proměnné v něm obsažené vidı́me na obsystem (1)
rázku 8.7. Je zde popis zařı́zenı́ (sysDesysDescr
sysServices
scr), adresa OID vedoucı́ do větve en(1)
(7)
terprises s podrobnějšı́mi informacemi
(sysObjectID), doba od zapnutı́ zařı́zenı́ sysObjectID sysUpTime sysContact
sysName
sysLocation
(2)
(3)
(4)
(5)
(6)
v setinách sekundy (sysUpTime), kontaktnı́ údaje ke správci zařı́zenı́ (sysConObrázek 8.7: Podstrom uzlu system
tact), název zařı́zenı́ přiřazený adminem (sysName), info o fyzickém umı́stěnı́ zařı́zenı́ (sysLocation) a čı́slo určujı́cı́ vrstvy v ISO/OSI, na kterých zařı́zenı́ pracuje (sysServices).
Přı́klad
Vrat’me se k hodnotě sysServices určujı́cı́ vrstvy v ISO/OSI, na kterých dané zařı́zenı́ (to, na kterém
je uložena databáze daného agenta) pracuje. Jednotlivé bity této hodnoty jsou nastaveny podle
podpory vrstev (bity zprava doleva od nejméně významného bitu).
Napřı́klad sysServices.0 = 10 znamená, že zařı́zenı́ pracuje na L2 a L4 (22−1 + 24−1, tedy
je nastaven druhý a čtvrtý bit zprava) a znamená to, že jde zřejmě o switch (L2) a obsahuje
funkcionalitu L4 pro účely správy (transportnı́ vrstva).
P
8.6
MANAGEMENT V TCP/IP
195
Dalšı́m užitečným uzlem v obecné části MIB je uzel interfaces. Zde zjistı́me informace o rozhranı́ch
zařı́zenı́, informace o jednotlivých zařı́zenı́ch jsou v tabulce ifTable (do nı́ž jsme už trochu nahlédli).
Tato tabulka má mnoho sloupců, napřı́klad ifSpeed (nominálnı́ rychlost přenosu na rozhranı́), ifOperStatus (operačnı́ stav rozhranı́), počet oktetů, přijatých/odeslaných/zahozených unicast paketů,
non-unicast paketů (ifOctets, ifInUcastPkts, . . . ), atd.
P
Skutečnou rychlost rozhranı́ zjistı́me pouze tak, že dvakrát za sebou zjistı́me počet přijatých
oktetů, odečteme a vydělı́me délkou intervalu, který uplynul mezi těmito dvěma načtenı́mi hodnot.
8.6.3
Použı́vánı́ protokolu SNMP
Protokol SNMP definuje přı́kazy (pro agenty a správce):
• get-request – správce žádá informace z MIB; uvede název proměnné, jejı́ž hodnotu požaduje, zı́ská hodnotu a název této proměnné,
• get-next-request – účel je stejný (žádost o informace z MIB), správce také uvede název
proměnné, ale zı́ská hodnotu proměnné a dále název následujı́cı́ proměnné z databáze, která
je potomkem téhož uzlu (tj. pokud žádal o proměnnou ...2.1.1.3, dostane informaci o existenci proměnné ...2.1.1.4, na kterou se může dotazovat následně),
• set-request – správce ukládá informace do MIB, je nutný autorizovaný přı́stup správce,
• trap – agent předává správci nevyžádanou informaci o mimořádné události,
• get-response – odpověd’ agenta na předchozı́ get-request od správce, kromě hodnot
z MIB obsahuje také původnı́ dotaz, protože SNMP neumožňuje správci párovat dotaz/odpověd’
(nestavové chovánı́),
• get-bulk – podobně jako get-request, ale je možné žádat i několik řádků tabulky (od
SNMPv2),
• inform – komunikace mezi dvěma správci (od SNMPv2).
Přı́kaz get-next-request použitý ve vhodné smyčce umožňuje zı́skat postupně hodnoty stejných
atributů přes všechny objekty stejného typu (sloupcová operace).
Konkrétně můžeme tyto přı́kazy (at’ už v textové nebo grafické podobě) zadávat v některém
z nástrojů vytvářejı́cı́ch rozhranı́ k SNMP. Lze použı́t napřı́klad tyto nástroje:
• net-snmp7 je open-source nástroj pracujı́cı́ v textovém režimu, a to pod Linuxem, dalšı́mi
unixovými systémy a také pod Windows. Je to ve skutečnosti balı́k programů, který umožňuje
využı́vat plně SNMP v kterékoliv jeho verzi, včetně přı́jmu trapů.
• MIB Browser8 je volně šiřitelná aplikace s grafickým rozhranı́m umožňujı́cı́ pracovat s MIB.
• GNetWatch9 je open-source aplikace s grafickým rozhranı́m pro real-time monitoring sı́tě přes
SNMP a ICMP.
Dalšı́ informace o SNMP:
• http://www.samuraj-cz.com/clanek/snmp-simple-network-management-protocol/
7
net-snmp je ke staženı́ na http://www.net-snmp.org/.
MIB Browser je ke staženı́ na http://www.ks-soft.net/hostmon.eng/mibbrowser/index.htm.
9
GNetWatch je dostupný na http://gnetwatch.sourceforge.net/.
8
8.7
SYSLOG
•
•
•
•
•
•
8.7
196
http://www.samuraj-cz.com/clanek/zarizeni-v-siti-pod-kontrolou/
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/SNMP.html
http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=129&clanekID=133
http://www.abclinuxu.cz/clanky/system/monitoring-pomoci-nastroju-z-baliku-net-snmp
http://www.snmplink.org/
http://www.fi.muni.cz/k̃as/p090/referaty/2007-podzim/ct/snmp.html
Syslog
Syslog je mechanismus logovánı́ a souvisejı́cı́ch úloh dostupný na každém zařı́zenı́, na kterém běžı́
(téměř) jakýkoliv unixový systém včetně Linuxu. Jádrem mechanismu je démon10 syslogd.
Démon syslogd čte svůj vstup ze zařı́zenı́ (socketu) /dev/log. Tento vstup filtruje (vybı́rá to,
co ho zajı́má) podle konfigurace, která se nacházı́ v souboru /etc/syslog.conf (to je tedy jeho
konfiguračnı́ soubor) a pak podle nastavenı́ ukládá hlášenı́ o takto zjištěných událostech do jednoho
nebo vı́ce LOG souborů.
Data, která syslogd přijı́má, se skládajı́ ze třı́ částı́:
1. kategorie určuje typ nebo odesı́latele události, existujı́ tyto kategorie:
• auth – autentizace uživatelů,
• authpriv – informace o autentizaci určená pro administrátora,
• cron – zprávy od démona cron (plánovánı́ procesů),
• daemon – zprávy od různých démonů,
• kern – zprávy od jádra (kernel),
• lpr – zprávy od tiskového subsystému,
• mail – zprávy týkajı́cı́ se elektronické pošty,
• mark – časová razı́tka (timestamps), které se pravidelně zapisujı́ do logu,
• news – diskusnı́ skupiny,
• security – totéž co auth,
• syslog – vlastnı́ zprávy syslogu (i z jiného uzlu v sı́ti),
• user – obvykle zprávy od aplikacı́ v uživatelském režimu,
• local0–local7 – pro tyto kategorie lze definovat vlastnı́ význam,
2. priorita určuje důležitost události:
• emerg – systém je nepoužitelný nebo vážně ohrožen (emergency),
• alert – je nutný okamžitý zásah,
• crit – kritická situace,
• err – chyba,
• warning – varovánı́,
• notice – normálnı́, avšak významná, zpráva,
• info – informativnı́ zpráva,
• debug – ladicı́ zpráva (debugger),
3. vlastnı́ text zprávy.
10
Pro ty, kteřı́ zapomněli: démon je v unixových systémech něco podobného jako služba ve Windows. Jde o systémový
proces, který běžı́ na pozadı́. Názvy démonů obvykle končı́ pı́smenem „d“.
8.7
SYSLOG
197
Tento typ informacı́ tedy syslog zı́ská. Jak bylo výše uvedeno, ve svém konfiguračnı́m souboru má
určeno, co s takovým záznamem provést. V tomto souboru jsou záznamy ve formě
kategorie.priorita TAB cı́l
kategorie.=priorita TAB cı́l
kategorie.!priorita TAB cı́l
kategorie.!=priorita TAB cı́l
tato a vyššı́ priority
pouze tato priorita
všechny priority kromě této a vyššı́ch
všechny priority kromě této
(priorit může být i vı́ce, oddělujı́ se střednı́kem, totéž platı́ i o dvojicı́ch kategorie.priorita). Pokud
je před prioritou jen tečka, nastavenı́ platı́ pro uvedenou a všechny vyššı́ priority. Pokud chceme
nastavenı́ omezit jen na zadanou prioritu, přidáme před ni „=“. Symbol „!“ znamená negaci,
tedy pokud je uveden, daná priorita (a všechny vyššı́) nebude zahrnuta. Lze kombinovat: „!=“,
nebude zahrnuta pouze uvedená priorita. Kategorii můžeme zadat symbolem *. To znamená, že
se konfigurace týká jakékoliv kategorie.
Mezi prioritami a cı́lem musı́ být vždy alespoň jednou stisknutý tabulátor, mezera nestačı́.
Cı́l určuje, kam konkrétně má být událost oznámena, logována. Může to být bud’ konkrétnı́ log
soubor (výchozı́ nebo jakýkoliv jiný), nebo výpis na konzolu či přeposlánı́ na jiný počı́tač v sı́ti.
Pokud chceme, aby byla událost oznámena vı́ce cı́lům (napřı́klad zobrazena určitému uživateli
a zároveň uložena do souboru), oddělı́me cı́le čárkou. Možnosti:
• soubor – výchozı́ je /var/log/messages, ale můžeme si určit názvy souborů napřı́klad pro
různé kategorie nebo priority,
• @server.firma.cz nebo @IPadresa – událost bude přeposlána,
• user1, user2, . . . – událost bude oznámena zadanému uživateli (to může být root, admin,
operator, apod., podle toho, jaké máme vytvořené uživatele), ale jen tehdy, když je uživatel
právě přihlášen,
• * – událost bude oznámena všem přihlášeným uživatelům,
• @loghost – můžeme použı́t, pokud v souboru /etc/hosts je definován cı́l loghost.
Lze použı́t také přesměrovánı́ do pojmenované roury, ze které pak může čı́st jakýkoliv proces,
který určı́me (a průběžně zpracovávat oznámenı́ o událostech), stačı́ uvést název souboru a před
něj napsat symbol roury:
kern.=err
|/var/log/jadro
Přı́klad
Takto nějak mohou vypadat záznamy v souboru /etc/syslog.conf:
mail.*
/var/log/maillog
Všechny události z kategorie mail jsou uloženy do souboru /var/log/maillog
security.*;security.!=debug
/var/log/secure
Všechny události z kategorie security kromě události s prioritou debug jsou uloženy do souboru /var/log/secure
cron.*
/var/log/cron
Všechny události z kategorie cron jsou uloženy do souboru /var/log/cron (to znamená
události souvisejı́cı́ s plánovaným spouštěnı́m procesů)
L
8.7
SYSLOG
kern.debug;auth.notice
198
/dev/console
Události týkajı́cı́ se laděnı́ jádra a běžné a přesto významné události autentizace jsou vypsány
na systémové konzoli
authpriv.*
/var/log/secure
Všechny „citlivějšı́“ události autentizace jsou uloženy do souboru /var/log/secure
lpr.info
/var/log/lpd-info
Informačnı́ zprávy a všechny s vyššı́ prioritou o událostech z tiskového subsystému se uložı́
do /var/log/lpd-info
*.err
admin,/var/log/errors
Všechny chybové a vážnějšı́ zprávy jsou okamžitě oznámeny uživateli admin (pokud je přihlášen) a zároveň uloženy do souboru /var/log/errors
*.=crit
/var/log/messages,@loghost,root
Kritické události jsou uloženy do souboru /var/log/messages, poslány na adresu definovanou pod aliasem loghost a zároveň je okamžitě informován root, pokud je přihlášen
*.emerg
*,/var/log/emergency
O mimořádně nebezpečných událostech jsou informováni všichni přihlášenı́ uživatelé a zároveň je přidán záznam do souboru /var/log/emergency
Pokud chceme, aby syslog přijı́mal zprávy z jiných systémů, musı́me spustit démona syslogd s parametrem -d (platı́ v Linuxu):
/usr/sbin/syslogd -m 0 -r
Přepı́nač -m určuje délku intervalu, v jakém se syslogd ozývá, tj. do logu zapisuje, že „žije“. Nastavenı́m na 0 toto chovánı́ zrušı́me. Parametr -r znamená „remote“, syslogd pak naslouchá na portu
514 a přijı́má všechny UDP pakety.
Na FreeBSD je nutné použı́t jinou syntaxi:
/usr/sbin/syslogd
(bez parametrů, protože naslouchánı́ na portu 514 je zde výchozı́ chovánı́). Na FreeBSD je také
možné určit uzly v sı́ti, jejichž UDP pakety budou přijı́mány. Odlišnou syntaxi (i od této) majı́
systémy OpenBSD, Solaris a jiné, je tedy třeba vždy prostudovat manuálovou stránku:
man syslogd
Také je možné, že budeme muset povolit naslouchánı́ služby syslogd na UDP portu. To se provede
v /etc/services řádkem syslog 512/UDP, ale je pravděpodobné, že tam takový záznam už je.
Na zařı́zenı́ch, ze kterých jsou UDP pakety přijı́mány, je pak nastaveno výše popsaným způsobem
zası́lánı́ na tento „sběrný“ počı́tač.
Pokud syslogd právě běžı́ a my jsme provedli změnu jeho konfigurace (v souboru /etc/syslog.conf),
musı́me syslogd restartovat, aby zaregistroval změny ve své konfiguraci.
Zatı́m jsme si ukázali, jaké údaje dostává syslogd na svůj vstup, podle čeho je filtruje a kam je
ukládá. Zbývá nám podı́vat se, v jakém formátu. Na výstupu je záznam obsahujı́cı́
• čas, kdy k události došlo,
• kategorii (kernel, mail apod.),
• text zprávy.
8.8
MONITOROVÁNÍ SÍTĚ
199
Součástı́ nenı́ priorita, protože ta už byla uplatněna při filtrovánı́. Může zde být napřı́klad záznam:
Feb 21 10:00:28 IOL kernel: device eth0 left promiscuous mode
Když syslog nastavujeme, hodı́ se možnost vyzkoušenı́ jeho funkčnosti. K tomu může sloužit
nástroj logger. Napřı́klad událost kategorie daemon a priority info se zadanou zprávou vygenerujeme
takto:
logger -p daemon.info ”testujeme syslog”
Ručnı́ správa logů může být celkem náročná. Je třeba hlı́dat obsah souborů a navı́c sledovat
jejich délku (včas umazat staršı́ záznamy), stroj naslouchajı́cı́ na UDP portu by měl být dostatečně
chráněn (je zde vysoké riziko DoS útoků, tedy firewall je rozhodně na mı́stě). S některými úlohami mohou pomoci přı́davné nástroje. Napřı́klad rotaci logů (včetně označovánı́ či odstraňovánı́
staršı́ch záznamů) zvládne logrotate.
Existujı́ také propracovanějšı́ verze syslogu, napřı́klad syslog-ng (umı́ komunikovat i přes TCP
a zvládne také regulárnı́ výrazy, nejen hvězdičku), nsyslogd (komunikuje přes TCP/SSL), Secure
Syslog, Modular Syslog a dalšı́. Volně šiřitelný program NTSyslog11 (vlastně služba, kterou můžeme
instalovat), umožňuje použı́vat syslog také ve Windows (logy z Windows lze posı́lat na vzdálený
systém a tam napřı́klad vyhodnocovat). Nástroj logwatch12 můžeme použı́t k sumarizaci logů, provádı́ analýzu logů za stanovené obdobı́ a vytvářı́ souhrnnou zprávu. Program swatch13 je užitečný,
když naopak potřebujeme být o určité události informováni pokud možno okamžitě – detekuje
námi definované situace a stanoveným způsobem informuje, a protože je psán v perlu, je to velmi
pružný nástroj využı́vajı́cı́ regulárnı́ výrazy.
Dalšı́ informace o syslogu:
•
•
•
•
•
•
•
•
8.8
8.8.1
http://www.linux.cz/noviny/2001-04/clanek03.html
http://linux.about.com/od/commands/l/blcmdl8 syslogd.htm
http://www.precision-guesswork.com/sage-guide/syslog-overview.html
http://books.google.com/books?id=8KUzFBDAT6EC&pg=PA189
http://www.root.cz/clanky/linux-jako-internetova-gateway-9/
http://www.softpanorama.org/Logs/Syslog/syslog configuration examples.shtml
http://unixhelp.ed.ac.uk/CGI/man-cgi?logger+1
http://www.root.cz/clanky/synchronizace-casu/
Monitorovánı́ sı́tě
Protokol RMON
RMON (Remote Monitoring) je protokol použı́vaný při monitorovánı́ sı́tě. Je úzce spjat s TCP/IP
a SNMP, své zprávy posı́lá přes SNMP. Informace jsou uloženy v MIB ve větvi rmon (OID
1.3.6.1.2.1.16). Narozdı́l od SNMP agentů dokáže kromě současného stavu sledovat i historii (vývoj)
dané veličiny a na základě vyvozených důsledků reagovat.
11
NTSyslog najdeme na http://ntsyslog.sourceforge.net.
logwatch zı́skáme na http://www.logwatch.org.
13
Program swatch (Simple Watch) je dostupný na http://swatch.sourceforge.net.
12
$
8.8
MONITOROVÁNÍ SÍTĚ
200
mib-2 (1)
rmon (16)
statistic (1)
filter (7)
history (2)
capture (8)
alarm (3)
hosts (4)
hostsTopN (5)
matrix (6)
event (9)
Obrázek 8.8: Větev rmon v MIB-II
Z hlediska protokolu RMON rozlišujeme dva druhy zařı́zenı́ v sı́ti:
• RMON-compliant console manager (správce) – správce celé LAN
• RMON probe (sonda) – zası́lá informace správci, jedna sonda pracuje v rámci jednoho segmentu LAN (napřı́klad uvnitř jedné koliznı́ domény)
RMON pracuje s tzv. skupinami. Každá skupina v sobě zahrnuje určitý typ informace, která je
sledována. Skupiny jsou zvlášt’ definovány pro Ethernet a Token Ring, pro Ethernet jsou to tyto
skupiny:
• Statistics – statistika (okamžitý stav) sledovaných zařı́zenı́ (množstvı́ odeslaných paketů,
broadcast a multicast paketů, oktetů, chyb v CRC součtech, kolizı́ apod., také čı́tače, napřı́klad
pro počty paketů o velikosti z daného intervalu),
• History – totéž jako statistika, ale evidováno v historii,
• Alarms – pro některé sledované veličiny jsou stanoveny prahové hodnoty, a když je tato
prahová hodnota překročena, generuje se přı́slušná událost,
• Hosts – vedou se statistiky typické pro jednotlivé uzly v sı́ti (segmentu sı́tě) – adresa, odeslané/přijaté pakety, chyby v CRC součtech a zahozené pakety či rámce,
• HostsTopN – podobně jako předchozı́, uzly jsou seřazeny v tabulkách podle konkrétnı́ sledované veličiny,
• Matrix – sledujı́ se veličiny souvisejı́cı́ s konverzacı́ mezi dvěma uzly v sı́ti, pro každou
komunikujı́cı́ dvojici uzlů,
• Filters – umožňujı́ definovat filtry pro zachycenı́ některých paketů nebo generovánı́ určité
události při průchodu určených paketů,
• Packet Capture – definujı́ se podmı́nky pro zachytávánı́ paketů (napřı́klad velikost vyrovnávacı́
paměti pro zachycené pakety, počet zachycených paketů, kdy vyvolat alarm apod.),
• Events – generovánı́ a ověřovánı́ událostı́ (eviduje se typ události, jejı́ popis a časový údaj
poslednı́ho vygenerovánı́ této události daným zařı́zenı́m).
Zařı́zenı́ připojená v sı́ti obvykle podporujı́ většinu těchto skupin, v ideálnı́m přı́padě všechny.
Tedy sledujeme ty proměnné v MIB, které nás zajı́majı́.
Hlavnı́m přı́nosem RMON je přenos velké části zpracovánı́ dat od správců na agenty (sondy),
čı́mž se také snižuje množstvı́ přenášených dat v sı́ti.
P
P
8.8
MONITOROVÁNÍ SÍTĚ
8.8.2
201
Snort
Snort14 je jednoduchý volně šiřitelný systém (open-source licence, ale pro aktualizace je nutné se
registrovat, „okamžité“ aktualizace jsou navı́c placené), který můžeme zařadit mezi NIDS (Network
Intrusion Detection System).
Snort pracuje v jednom ze třı́ možných režimů:
• sniffer („prohlı́žeč“ provozu) – slidič, data z hlaviček paketů vypisuje na obrazovku nebo
někam posı́lá,
• logovánı́ provozu – data ukládá na disk a/nebo do databáze,
• plný NIDS včetně použı́vánı́ pravidel – analýza hlaviček paketů.
P
P
Výstupy dokáže Snort bud’ ukládat do LOG souboru, nebo zası́lat syslogu, posı́lat jako SNMP trap,
ukládat do databáze a nebo dokonce podle nich nastavovat konfiguraci některých sı́t’ových prvků.
Snort funguje na principu detekce signatur v kombinaci s pravidly. Mnoho pravidel je vytvořeno
už při instalaci (je jich opravdu hodně, někdy to chce trochu je promazat), a také je možné přidat
pravidla vlastnı́ podle konkrétnı́ situace v sı́ti. Využı́vánı́ pravidel dává systému obecně většı́ sı́lu
(napřı́klad kombinace „mı́rně podezřelých“ akcı́ je velmi podezřelá a narozdı́l od systémů založených
pouze na signaturách systém generuje méně falešných poplachů.
Obecný tvar pravidel je
action protocol sourceIP sourcePort direction destIP destPort (options)
Action akce) může být napřı́klad pass (předánı́, tj. ignorovánı́ paketu), log (zaznamenánı́), alert
(výstraha), drop (zahodit paket), atd. Následujı́ vlastnosti paketu, podle nich pozná Snort, že má
pravidlo použı́t (protokol, třeba TCP, dále zdrojová a cı́lová adresa a port, a také směr přenosu
paketu zachycený „šipkou“). Poslednı́ částı́ pravidla jsou options – volby, které ve skutečnosti
popisujı́, co se má stát, když Snort zachytı́ paket odpovı́dajı́cı́ údajům v pravidlu a také co dalšı́ho
má být testováno (napřı́klad pole TTL paketu nebo ICMP informace). Napřı́klad:
$
alert tcp any 3389 -> 81.28.192.0/24 3389 (msg: ”TCP paket na Net5”;)
To znamená, že má být generována výstraha, pokud je nalezen TCP paket z jakékoliv adresy na
portu 3389 mı́řı́cı́ do sı́tě s danou IP adresou (použı́vajı́ se CIDR adresy s prefixem), a to na tomtéž
portu. S výstrahou se má vygenerovat zpráva v zadaném zněnı́ (zpráva je nahlášena a uložena do
logu). Ve skutečnosti bývajı́ pravidla poněkud sofistikovanějšı́ a mohou obsahovat také napřı́klad
popis porovnánı́ se signaturou a dalšı́ volby.
V uvedeném přı́kladu jsou konkrétnı́ adresy, ale lze využı́t také proměnné, ve kterých má Snort
předdefinovanou adresu vnitřnı́ sı́tě a některé dalšı́ adresy, napřı́klad
alert icmp $EXTERNAL_NET any -> $HOME_NET any
(msg:”ICMP Large ICMP Packet”; dsize: >800;)
Snort funguje podobně jako předchozı́ popsané mechanismy včetně SNMP (správce+agenty).
Agenty se nazývajı́ sondy a nacházejı́ se v různých oblastech infrastruktury, podle potřeby (umı́stěnı́
stanovı́me podle typu informacı́, které chceme zı́skávat, záležı́ na tom, jestli je sonda před či za
firewallem, v DMZ, v dané koliznı́ doméně apod.).
14
Snort zı́skáme na http://www.snort.org.
P
8.8
MONITOROVÁNÍ SÍTĚ
202
Obecně jde o dobře rozšiřitelný systém. Pokud máme vı́ce sond a na sı́ti je většı́ provoz (což
znamená velké množstvı́ záznamů), doporučuje se použı́t některý databázový systém, napřı́klad
MySQL. Existujı́ také frameworky (rozhranı́), které zjednodušujı́ přı́stup a analýzu dat Snortu,
napřı́klad Prelude,15 což je framework použitelný nejen pro Snort, ale také napřı́klad pro Nessus.
Dalšı́ systém, který zjednodušuje použı́vánı́ Snortu, je ACID16 (Analysis Console for Intrusion
Databases). ACID je zajı́mavý už proto, že se s jeho použitı́m počı́tá v doporučenı́ch pracovnı́ch
skupin CERT (setkali jsme se s nimi u CESNETu). ACID potřebuje webový server (třeba Apache),
funkčnı́ PHP a databázi, do které Snort ukládá záznamy (třeba MySQL).
Dalšı́ informace o Snortu:
•
•
•
•
•
•
•
•
•
•
http://i.iinfo.cz/r/kd/Intrusion Detection with SNORT.pdf
http://www.cs.vsb.cz/grygarek/SPS/projekty0405/IDS/ids.html
http://www.cs.vsb.cz/grygarek/SPS/projekty0506/Snort.pdf
http://www.scribd.com/doc/6777057/Snort-Manual
http://www.snort.org/docs/writing rules/
http://www.dusatko.org/cs/content/snort-network-intrusion-detection-system
http://connect.zive.cz/node/315
http://www.inguardians.com/research/docs/snortguis.pdf
http://www.cert.org/kb/aircert/
http://www.actinet.cz/bezpecnost informacnich technologii/l19/cl18/st1/j1/Jak nasadit
system detekce pruniku.html
• http://www.dusatko.org/cs/node/121
• http://www.prelude-technologies.com/en/development/documentation/index.html
8.8.3
NetFlow pracuje na principu toků. Tok (flow) je to, co obvykle považujeme za úplnou sı́t’ovou
konverzaci. V přı́padě přenosů realizovaných spojovými stavovými protokoly (jako je napřı́klad
TCP) do jednoho toku patřı́ nejen odeslánı́ jednoho paketu, ale komunikace v rámci celého spojenı́
(ale pouze jednı́m směrem, tedy obousměrná komunikace je technicky ve dvou tocı́ch). Do jediného
společného toku také patřı́ napřı́klad sekvence ICMP paketů vyslaných v rámci jediného přı́kazu
ping. Každý tok je jednoznačně popsán těmito údaji:
• zdrojová IP adresa
• cı́lová IP adresa
15
NetFlow
NetFlow je protokol vyvinutý firmou Cisco. S jeho podporou se tedy setkáme předevšı́m na zařı́zenı́ch od této firmy, ale také v zařı́zenı́ch firmy Juniper a některých dalšı́ch firem (přesněji: tato
zařı́zenı́ mohou exportovat informace ve stejném formátu jako NetFlow). Nemusı́ jı́t jen o směrovače a přepı́nače, ale existujı́ také jednoduchá přenosná zařı́zenı́, která plnı́ pouze roli sledovánı́
sı́tě tı́mto způsobem. Na NetFlow je založen standard IPFIX.
16
$
• zdrojový port
• cı́lový port
• IP protokol
• typ služby
• vstupnı́ rozhranı́
Informace o Prelude najdeme na http://www.prelude-technologies.com.
ACID najdeme na http://www.andrew.cmu.edu/user/rdanyliw/snort/snortacid.html.
P
P
8.9
WBEM
203
Komunikace také může být rozdělena do vı́ce toků, pokud trvá přı́liš dlouho (na směrovačı́ch
Cisco je to napřı́klad 30 minut), nebo je delšı́ dobu neaktivnı́ a nebo je zaplněna vyrovnávacı́ pamět’
zařı́zenı́ (toky nenı́ kam ukládat, proto ty staršı́ budou vymazány).
Mı́sto zjišt’ovánı́ informacı́ (s protokolem NetFlow) se nazývá Observation Point (také NetFlow
Exporter). Toto zařı́zenı́ zjišt’uje z průchozı́ch paketů potřebné informace a odesı́lá je flow kolektoru.
Flow kolektor je hardware nebo software, který přijı́má data o tocı́ch a zpracovává. Jeden flow
kolektor může přijı́mat data od vı́ce observation pointů.
Kromě ukládánı́ dat na Flow kolektoru ještě potřebujeme aplikaci, která by zjednodušila analýzu
těchto dat. Existuje vı́ce takových aplikacı́, mnohé volně šiřitelné.
• OSU Flow-Tools17 jsou volně šiřitelný balı́k programů pro textový režim vyvı́jený na univerzitě
v Ohiu. V balı́ku najdeme nástroje na shromažd’ovánı́ dat na flow kolektoru a zpracovánı́
údajů o tocı́ch.
P
$
• NFDump18 je volně šiřitelný kolektor (distribuovaný pod BSD licencı́). Existuje pro něj také
grafická nástavba NFSen,19 která je vlastně webovým rozhranı́m.
Dı́ky „koncentrovanějšı́m“ informacı́m, které NetFlow umožňuje zı́skávat, lze odhalit napřı́klad
DoS útok (všechny pakety v rámci tohoto útoku majı́ společné posuzované parametry, patřı́ do
jednoho toku), ale ne napřı́klad DDoS útok (je z mnoha zdrojů, obvykle z počı́tačů některého
rozsáhlého botnetu) ani skenovánı́ uzlů v sı́ti (různé cı́lové adresy).
8.9
8.9.1
WBEM
Princip WBEM
WBEM (Web-Based Enterprise Management) je skupina technologiı́ a postupů vytvořená za účelem
sjednotit správu distribuovaných počı́tačových prostředı́ (tj. včetně vzdálené správy). Správa se
provádı́ bud’ přes webové rozhranı́ nebo pomocı́ specializovaných shellů.
Data jsou organizována v modelu CIM (Common Information Model), který je otevřeným standardem. Účelem je jednotným způsobem popisovat, uchovávat a poskytovat potřebné informace
bez ohledu na jejich zdroj a použitý protokol. Jedná se vlastně o objektově orientovanou databázi,
kde jednotlivé objekty jsou zapouzdřeny a přistupuje se k nim přes unifikované rozhranı́.
Rozlišujeme WBEM server (ukládá a poskytuje informace, provádı́ přı́kazy) a WBEM klienta
(reprezentován předevšı́m rozhranı́m, se kterým pracuje administrátor, a přı́slušným API). Klient
odesı́lá žádosti, server konfrontuje se skutečným stavem a provádı́ je (přı́padně zajišt’uje proces
autentifikace a autorizace). Spolu komunikujı́ přes protokol HTTP nebo HTTPS. Právě podle těchto
protokolů je v názvu „web-based“. (Pozor, rozhodně to neznamená, že se komunikuje přes webový
prohlı́žeč!)
17
OSU Flow-Tools zı́skáme na http://www.splintered.net/sw/flow-tools/.
NFDump je dostupný na http://nfdump.sourceforge.net/.
19
NFSen je dostupný na http://nfsen.sourceforge.net/.
18
P
P
8.9
WBEM
204
Architektura je postavena na vzoru model–obraz. Klient čte data z „obrazu“, server přistupuje
k „modelu“ reprezentovanému skutečným stavem hardwaru a softwaru v sı́ti a při jakékoliv změně
modelu aktualizuje obraz.
WBEM nemá nahradit protokoly CMIP a SNMP, ale je jakousi nástavbou těchto modelů zjednodušujı́cı́ přı́stup administrátora k informacı́m.
WBEM má vı́ce různých implementacı́, napřı́klad:
WMI (Windows Management Instrumentation) je implementace Microsoftu pro Windows. Umožňuje (i vzdáleně) spravovat počı́tače s Windows v sı́ti, je předinstalována na všech verzı́ch od Win
2000 (resp. Win ME). Je postavena na VBScriptu a PowerShellu, WMI těmto skriptovacı́m jazykům
poskytuje přı́stup prakticky k čemukoliv ve Windows. Některé dalšı́ nástroje, které nejsou instalovány se systémem, je možné stáhnout ze stránek Microsoftu http://www.microsoft.com/downloads/
details.aspx?familyid=6430F853-1120-48DB-8CC5-F2ABDC3ED314&displaylang=en.
OpenWBEM od Novellu je implementace určená pro Novell Netware, Linux a některé jiné
Unixové systémy (včetně Solarisu a MacOSX). Je použı́vána v komerčnı́ i nekomerčnı́ sféře a stejně
jako WMI nabı́zı́ rozsáhlé možnosti zásahů do konfigurace sı́tě a monitorovánı́. Je ke staženı́ na
http://www.openwbem.org/.
OpenPegasus je dalšı́ otevřená implementace pro různé Unixové systémy včetně Linuxu, a Windows. Je ke staženı́ na http://www.openpegasus.org/.
V Linuxu (v menšı́ch sı́tı́ch) se hodně použı́vá nástroj Webmin, který zřejmě nenı́ přı́mo implementacı́ WBEM, ale má hodně podobné možnosti. Poskytuje sjednocené rozhranı́ v internetovém
prohlı́žeči a umožňuje monitorovat, vyhodnocovat a konfigurovat uzly v sı́ti. Varianta s omezenými právy, kterou mohou použı́vat běžnı́ uživatelé, se nazývá usermin. Dále existuje varianta
Virtualmin pro hromadnou správu virtuálnı́ch hostitelů (napřı́klad v serveru Apache). Webmin je
ke staženı́ na http://webmin.com/.
Obrázek 8.9: Úvodnı́ okno aplikace WbemTest
P
P
P
P
8.9
8.9.2
WBEM
205
WMI
Jak bylo výše uvedeno, WMI je implementace modelu WBEM pro správu Windows. Databáze CIM
je taktéž objektová, jde o objekty plnohodnotné s implementacı́ třı́d, vlastnostı́, metod, událostı́,
využı́vajı́cı́ dědičnost a kompozici.
Třı́dy jsou psány v objektovém jazyce MOF (Managed Object Format), který je interpretovaný
(dá se řı́ct skriptovacı́). Většina komponent WMI (včetně třı́d) je v adresáři ...\System32\Wbem.
Najdeme tam hodně souborů s přı́ponou MOF.
Pokud nás zajı́má, jak vlastně vypadajı́ třı́dy WMI, můžeme se na ně podı́vat v nástroji, který
je součástı́ Windows od verze XP. WbemTest se spouštı́ přı́kazem wbemtest a má grafické rozhranı́.
Po spuštěnı́ se objevı́ základnı́ okno, které vidı́me na obrázku 8.9.
P
$
Nejdřı́v je nutné se připojit k určitému oboru názvů (zobrazuje se v levém hornı́m rohu okna),
na obrázku 8.9 jsme připojeni k oboru názvů CIMV2 (k oboru názvů se jednoduše připojı́me tak,
že klepneme na tlačı́tko Připojit a zadáme název). Pak můžeme volně pracovat se třı́dami, které do
zvoleného oboru názvu patřı́ (také vytvářet nové).
Pokud si chceme prohlédnout (nebo upravit) vlastnosti
některé třı́dy daného oboru názvů, klepneme v hlavnı́m
okně na tlačı́tko Výčet třı́d. Zobrazı́ se dialogové okno (obrázek 8.10), do kterého bud’ zadáme přı́mo název třı́dy,
a nebo zvolı́me „rekurzivnı́ “ výčet (to znamená, že budou
vypsány všechny třı́dy z oboru názvů). V seznamu pak
poklepeme na vybranou třı́du a zobrazı́ se okno se všemi
jejı́mi vlastnostmi a metodami (obrázek 8.11).
Obrázek 8.10: Stanovenı́ třı́dy
Obrázek 8.11: Vlastnosti zvolené třı́dy Win32_Process
Kromě výše uvedeného nástroje WbemTest lze ke službě WMI přistupovat přes konzolu Řı́zenı́
služby WMI. Spouštı́me ji souborem wmimgmt.msc, ale je dostupná také v konzole Správa počı́tače,
jak vidı́me na obrázku 8.12. V kontextovém menu položky Řı́zenı́ služby WMI zvolı́me Vlastnosti
$
8.9
WBEM
206
a zı́skáme okno, které vidı́me na obrázku 8.12 vpravo. Nastavujeme obecné vlastnosti řı́zenı́ WMI
jako je způsob protokolovánı́ a umı́stěnı́ protokolu, zálohovánı́ (máme možnost obnovit databázi
WMI ze zálohy) a určujeme zabezpečenı́ prvků databáze.
Obrázek 8.12: Vlastnosti v konzole Řı́zenı́ služby WMI
Dalšı́m velmi užitečným nástrojem pro řı́zenı́ WMI je program wmic.exe, kterému se budeme
podrobněji věnovat dále. Pomocı́ tohoto nástroje můžeme přistupovat k databázi WMI a zı́skávat
z nı́ nejrůznějšı́ informace.
Na webu Microsoftu lze zı́skat WMI Administrative Tools,20 což je balı́k několika nástrojů pro
práci s WMI objekty. Je užitečný zejména pro programátory služeb, v nástrojı́ch balı́ku se dostaneme
prakticky k jakýmkoliv informacı́m, navı́c přehledně a srozumitelně členěným.
Rozhranı́ WMI se velmi často použı́vá ve skriptech (pomocı́ VB skriptu se takto dostaneme
prakticky k čemukoliv, co na počı́tači potřebujeme, i přes sı́t’). Skripty můžeme vytvářet bud’ ručně,
a nebo v některém nástroji pro generovánı́ WMI skriptů. Hodně použı́vané jsou napřı́klad
• WMI Code Creator21 generuje skripty v jazycı́ch VB Script, Visual Basic.NET a C#,
• Scriptomatic.22
Zatı́mco ve Windows 2000 se rozhranı́ WMI spouštělo jako služba s vlastnı́m procesem, od verze
XP (Server 2003) jde o službu spouštěnou v rámci procesu svchost.exe. Kdykoliv se spouštı́ něco
souvisejı́cı́ho s WMI (napřı́klad požadavek na data z databáze CIM), kód je spouštěn v procesu
wmiprvse.exe, který je potomkem procesu hostı́cı́ho službu RPC.
20
WMI Administrative Tools zı́skáme na adrese
http://www.microsoft.com/downloads/details.aspx?FamilyID= 6430f853-1120-48db-8cc5-f2abdc3ed314. V balı́ku najdeme nástroje WMI Object Browser (zobrazuje objekty v hierarchické struktuře i jejich metody, metody můžeme
i spouštět), WMI CIM Studio (pro práci s třı́dami), WMI Event Registration Tool a WMI Event Viewer (pro práci
s událostmi objektů).
21
WMI Code Creator je dostupný na stránce
http://www.microsoft.com/downloads/details.aspx?familyid=2CC30A64- EA15-4661-8DA4-55BBC145C30E.
22
Scriptomatic zı́skáme na adrese
http://www.microsoft.com/downloads/details.aspx?familyid=09DFC342- 648B-4119-B7EB-783B0F7D1178.
$
8.10
DOHLEDOVÉ SYSTÉMY
207
Program wmic (WMI Console) je dostupný od verze Windows XP/Server 2003. Umožňuje
využı́vat rozhranı́ WMI na přı́kazovém řádku. pracuje ve dvou režimech – klasickém (externı́m)
a interaktivnı́m. Tomuto přı́kazu se věnujeme v přı́loze (kapitola B.5, strana 243).
Úkoly
V přı́loze najděte sekci o programu wmic a vyzkoušejte některé z uvedených ukázek jeho použı́vánı́.
8.10
Dohledové systémy
Dohledový systém (network management software) je systém, který dokáže monitorovat stav sı́tě
(různé veličiny), tedy sbı́rat informace z různých zdrojů na sı́ti, generovat reporty a v přı́padě problémů (abnormálnı́ hodnoty sledovaných veličin, velké výkyvy apod.) vhodně reagovat (napřı́klad
odeslat informaci adminovi).
P
Když si vybı́ráme dohledový systém, bereme v úvahu:
• co vše může být monitorováno (množstvı́ a typy monitorovaných služeb),
• konkrétnost hlášenı́ (některé poruchy jsou „hierarchické“, tedy pokud něco selže v důsledku
selhánı́ něčeho jiného, neměl by report zahrnovat vše, ale pouze „kořen problému“),
• rozhranı́, dnes běžně grafické, mělo by být dostatečně přehledné a vhodně hierarchicky členěné, hodně záležı́ na tom, co si lze zobrazit a v jaké formě, možnost vizualizovat nejrůznějšı́
datové toky či cokoliv dalšı́ho, co se může s časem měnit,
• způsob zası́lánı́ hlášenı́ – přes SMTP server (přı́p. může být i integrovaný), SMS, pager,
• možnosti nastavenı́ uživatelských oprávněnı́ pro přı́stup k evidovaným informacı́m,
• funkčnı́ omezenı́ – způsob komunikace s hlı́danými zařı́zenı́mi (přes který protokol, např.
SNMP), způsob logovánı́, atd.
Existujı́ jak open-source, tak i komerčnı́ dohledové systémy. Ke komerčnı́m patřı́ napřı́klad WhatsUp Gold,23 SonicWALL,24 a dalšı́. Na některé open-source produkty se podı́váme v následujı́cı́m
textu.
8.10.1
Nagios
Nagios je velmi oblı́bený open-source monitorovacı́ (dohledový) systém. Zvládá nejen samotné
monitorovánı́, ale i vizualizaci. Dokáže monitorovat různé typy sı́t’ových služeb (HTTP, POP3,
ICMP, SMTP), nemá problémy s šifrovánı́m, monitoruje také využı́vánı́ prostředků na uzlech sı́tě
(rozumı́ si s různými operačnı́mi systémy včetně Windows), zvládá vizualizaci stavu sı́tě (také
dokáže vykreslit topologii sı́tě včetně 3D grafu). Pro konfiguraci lze použı́t webové rozhranı́ (ale je
možné využı́vat jiná rozhranı́, napřı́klad Centreon v kombinaci s MySQL).
Vznikl nový fork (odnož) Nagiosu, který se nazývá Icinga.25 Podle vývojářů tohoto forku je
účelem předevšı́m zrychlit a zpružnit vývoj.
23
http://www.annexnet.cz/ipswitch-whatsupgold-popis-produktu/
http://www.sonicwall.com/
25
Systém Icinga včetně zdůvodněnı́ jejı́ho vzniku najdeme na http://www.icinga.org/.
24
J
8.10
DOHLEDOVÉ SYSTÉMY
208
Dalšı́ informace o Nagiosu:
•
•
•
•
http://www.mfservis.cz/sluzby/dohledove-centrum-nagios.html
http://www.abclinuxu.cz/clanky/site/nagios-plus-centreon-plus-mysql-instalace-a-za-kladni-konfigurace
http://www.nagiosbook.org/
http://nagios.sourceforge.net/docs/3 0/quickstart.html
8.10.2
Zabbix
Zabbix26 je dalšı́m oblı́beným open-source monitorovacı́m systémem. Potřebujeme Zabbix Server
(ten nainstalujeme na dohledový server, měl by na něm běžet některý unixový systém včetně
Linuxu) a Zabbix agenty (na klientských zařı́zenı́ch, různé operačnı́ systémy včetně Windows).
Konfigurace se provádı́ opět přes webové rozhranı́, tedy po základnı́ orientaci nic moc složitého.
J
Funkčnost je podobná, snad mı́rně nižšı́, než v přı́padě Nagiosu, obvykle je Zabbix považován za
jednoduššı́ ve vybavenosti a konfiguraci (Nagios je zase považován za stabilnějšı́). Taktéž podporuje
SNMP a agenty je možné instalovat na různé operačnı́ systémy.
Dalšı́ informace o Zabbixu:
• http://www.root.cz/serialy/dohledovy-system-zabbix/
• http://www.zabbix.com/documentation.php
8.10.3
OpenNMS
OpenNMS27 je open-source dohledový systém, který je narozdı́l od předchozı́ch napsán v Javě.
Je určen pro monitorovánı́ rozsáhlých sı́tı́ s velkým množstvı́m sledovaných zařı́zenı́. Monitoring
může být distribuovaný (na vı́ce serverech), dı́ky tomu lze monitorovat tak velké množstvı́ zařı́zenı́.
J
Jde o dobře rozšiřitelný systém. Monitoring různých služeb je řešen pomocı́ pluginů (podporu
monitorovánı́ dalšı́ služby lze přidat jednoduše přidánı́m pluginu).
Konfigurace se opět provádı́ přes webové rozhranı́. Práci se systémem je možné si vyzkoušet
na demo aplikaci na stránkách projektu.
Dalšı́ informace o OpenNMS:
• http://www.howtoforge.com/opennms network management
• http://www.mifos.org/developers/wiki/MonitoringSeversWithOpenNMS
• http://demo.opennms.org/opennms/acegilogin.jsp
8.10.4
Zenoss
Zenoss28 je dalšı́ open-source dohledový systém (přesněji jeho jedna varianta je open-source volně
ke staženı́, druhá – Enterprise – je komerčnı́). Je postaven na myšlence využitı́ existujı́cı́ch opensource projektů.
26
Zabbix je dostupný na http://www.zabbix.com/.
Informace o OpenNMS najdeme na http://www.opennms.org/wiki/Main Page.
28
Zenoss je dostupný na http://www.zenoss.com/.
27
J
8.10
DOHLEDOVÉ SYSTÉMY
209
Jeho jádrem je objektový webový server Zope napsaný v jazyce Python, a také v Pythonu je
možné Zenoss dále rozšiřovat (dokonce lze údajně použı́vat i pluginy z Nagiosu, který je také
napsán v Pythonu). Dále se přidává databázový systém MySQL a celý systém běžı́ nad Twisted, což
je událostmi řı́zené rozhranı́ pro programovánı́ sı́t’ových aplikacı́, které si rozumı́ s mnoha různými
protokoly na vı́ce vrstvách ISO/OSI.
Důležitou součástı́ celého systému je RRDTool (Round Robin Database Tool). Tento nástroj
sloužı́ k ukládánı́, zpracovávánı́ a vytvářenı́ grafické reprezentace (grafů) jakýchkoliv čı́sel, která
mu předáme. Základem je databáze organizovaná jako kruhová fronta (odtud název Round Robin
Database) se statickou velikostı́, ve které jsou staršı́ data přepisována novějšı́mi.
P
Zenoss si rozumı́ s protokoly SNMP, ICMP, protokoly rodiny TCP/IP, komunikuje s unixovými
systémy (včetně syslogu) a také s Windows (podporuje také WMI). Na webu firmy najdeme také
informaci o tom, že jsou podporována také cloud zařı́zenı́ (pojem Cloud Computing je velmi
populárnı́). Konfigurace probı́há přes přehledné webové rozhranı́.
Dalšı́ informace o systému Zenoss:
•
•
•
•
•
http://www.zenoss.com/product/demo choice
http://www.root.cz/serialy/prechadzame-na-rrdtool/
http://oss.oetiker.ch/rrdtool/tut/
http://dohled.ic.cz/zenoss.html
https://help.ubuntu.com/community/Zenoss
8.10.5
Cacti
Cacti29 je dalšı́ open-source nástavba nástroje RRDTool, podobně jako Zenoss. Také v Cacti jde
o to, jak zı́skat data, vhodně je uložit a následně analyzovat a zobrazit. Data mohou být zı́skávána
z různých zdrojů, napřı́klad od SNMP (Net-SNMP), skriptů v nejrůznějšı́ch skriptovacı́ch jazycı́ch
nebo WMI, a uložena bud’ do SQL databáze nebo pomocı́ RRDTool. Systém je určen pro menšı́
a střednı́ sı́tě (stovky, možná tisı́ce, uzlů sı́tě).
J
Komunita kolem systému Cacti se utěšeně rozrůstá, a tak existuje hodně pluginů a také šablon
pro různé typy hodnot. Stejně jako u předchozı́ch nástrojů, také zde máme k dispozici přehledné
webové rozhranı́ pro konfiguraci a manipulaci s daty.
Dalšı́ informace o Cacti:
• http://www.root.cz/clanky/cacti-vse-dulezite-v-jednom-monitoru/
• http://www.codewalkers.com/c/a/Server-Administration/Monitoring-Temperatures-with-Cacti/
• http://www.ubuntugeek.com/install-and-configure-cacti-monitoring-tool-in-ubuntu-9
-10-karmic-server.html
• http://www.root.cz/clanky/cacti-ziskavani-vlastnich-dat-pomoci-ssh/
• http://www.samuraj-cz.com/clanek/cacti-snmp-monitoring-a-grafy/
• http://forums.cacti.net/about30438.html
8.10
DOHLEDOVÉ SYSTÉMY
210
Obrázek 8.13: Dohledový systém Cacti30
Úkoly
Vyberte si jeden ze zmiňovaných dohledových systémů a najděte o něm co nejvı́ce informacı́. Pokud
máte možnost, vyzkoušejte ho.
A ještě pár odkazů týkajı́cı́ch se zabezpečenı́:
•
•
•
•
29
30
http://www.scycore.com/papers/low linux intro.pdf
http://www.networksecuritytoolkit.org/nst/index.html
http://www.abclinuxu.cz/clanky/bezpecnost/linuxove-dmz-i
http://www.networksecuritytoolkit.org/nst/index.html
Cacti najdeme na http://www.cacti.net/.
Zdroj: http://www.cacti.net/screenshots.php
Seznam doporučené literatury
[1] CESNET2. URL: http://www.cesnet.cz/
[cit. 20. 5. 2010]
[2] DONAHUE, G. A. Kompletnı́ průvodce sı́t’ového experta. Brno, Computer Press, 2009.
[3] EMPSON, S. CCNA: Kompletnı́ přehled přı́kazů. Autorizovaný výukový průvodce. Brno, Computer
Press, 2009.
[4] HARPER, A. et al. Hacking – manuál hackera. Praha, Grada, 2008.
[5] HORÁK, J. — KERŠLÁGER, M. Počı́tačové sı́tě pro začı́najı́cı́ správce. Brno, Computer Press, 2008.
[6] HUBERT, B. et al. Linux Advanced routing & Traffic Control [online].
URL: http://lartc.org/howto/, dalšı́ na http://lartc.org/
[cit. 1. 7. 2011]
[7] JANEČEK, J. Distribuované systémy [online].
URL: https://dsn.felk.cvut.cz/wiki/ media/vyuka/cviceni/x36pko/skripta dsy.pdf
[cit. 20. 5. 2010]
[8] JONES, D. Automatizace správy a skriptovánı́ Microsoft Windows. Brno, Computer Press, 2006.
[9] Linux Home Networking [online]. Knihy o správě počı́tačových sı́tı́ v Linuxu.
URL: http://www.linuxhomenetworking.com/wiki/index.php
[cit. 1. 7. 2011]
[10] MINASI, M. — YORK, D. Linux pro administrátory Windows. Brno, Computer Press, 2004.
[11] PETERKA, J. eArchiv: Co je čı́m v počı́tačových sı́tı́ch [online].
URL: http://www.earchiv.cz/i coje.php3
[cit. 20. 5. 2010]
[12] PETERKA, J. eArchiv: Principy počı́tačových sı́tı́ [online].
URL: http://www.earchiv.cz/i pri.php3
[cit. 20. 5. 2010]
211
212
[13] PRICE, B. Active Directory. Brno, Computer Press, 2005.
[14] PUŽMANOVÁ, R. Modernı́ komunikačnı́ sı́tě od A do Z. 2. aktualizované vydánı́. Brno, Computer
Press, 2006.
[15] RUEST, D. — RUEST, N. Virtualizace: Podrobný průvodce. Brno, Computer Press, 2010.
[16] SATRAPA, P. Internetový protokol IPv6. Praha, CZ.NIC, z.s.p.o., 2008. 358 stran. Kniha je dostupná
v elektronické formě na
http://knihy.nic.cz/files/nic/edice/pavel satrapa ipv6 2008.pdf
[cit. 1. 7. 2011]
[17] SCOTT, C. — WOLFE, P. — ERWIN, M. Virtual Private Networks. 2nd edition. O’Reilly, USA, 1999.
Náhled většiny stránek je dostupný na Google Books.
[18] SCHRODER, C. Linux: Kuchařka administrátora sı́tě. Brno, Computer Press, 2009. Z originálu
Linux Networking Cookbook vydaného nakladatelstvı́m O’Reilly Media.
[19] Svět sı́tı́, tutoriály [online]. URL: http://www.svetsiti.cz/tutorialy.asp
[cit. 20. 5. 2010]
[20] System × Virtualization Strategies Development Space [online]. IBM Redbooks.
URL: http://www-01.ibm.com/redbooks/community/display/REDP4480/Home
[cit. 20. 5. 2010]
[21] THOMAS, T.M. Zabezpečenı́ počı́tačových sı́tı́. Autorizovaný průvodce. Brno, Computer Press,
2005.
[22] Výukové materiály Cisco [online]. URL:
http://www.cisco.com/en/US/docs/internetworking/technology/handbook/ito doc.html
[cit. 20. 5. 2010]
PŘÍLOHY
Přı́loha
A
Co už bychom měli znát
Zde v prvnı́ přı́loze jsou uvedena témata, která už bychom měli znát z bakalářského studia. Nicméně, dokonalá
pamět’ je věcı́ vzácnou, proto si je pro jistotu rychle zopakujeme.
A.1
Lokálnı́ sı́tě
Pojmy LAN (lokálnı́ sı́t’), WAN (rozlehlá sı́t’), MAN (metropolitnı́ sı́t’) a přı́padně CAN (campus,
sı́t’ v omezené oblasti) bychom již měli znát. Taktéž se již předpokládá přehled o topologiı́ch –
sběrnicová, kruhová, hvězda, stromová (hierarchická).
Každá komunikace probı́há po spoji (mezi uzly sı́tě).
A.1.1
Vlastnosti spojů
Komunikace (nejen v lokálnı́ch sı́tı́ch) se členı́ podle mnoha kritériı́.
Podle typu spoje
rozlišujeme spoje
• dvoubodové (point-to-point) – komunikace probı́há mezi dvěma uživateli (zařı́zenı́mi),
P
• vı́cebodové (point-to-multipoint) – vı́ce než dvěma.
Přenosy mohou být paralelnı́ nebo sekvenčnı́, a dále synchronnı́ nebo asynchronnı́.
Pojmy „paralelnı́“ a „sekvenčnı́“ jsou zde ve stejném významu, jaký se použı́vá u nám dobře
známých perifernı́ch zařı́zenı́ počı́tače.
Paralelnı́ přenos znamená přenášenı́ po vı́ce bitech najednou (vı́ce souběžných vodičů). To se může
zdát výhodou vzhledem k rychlosti přenosu, ale nastává zde problém synchronizace dat. Paralelnı́
přenos je proto použitelný jen pro malé vzdálenosti, u sı́tı́ se téměř nepoužı́vá.
Sekvenčnı́ (sériový) přenos znamená přenášenı́ dat po jednotlivých bitech. S pořadı́m je trochu
problém u různých protokolů, napřı́klad jsou odlišnosti u Ethernetu a Token Ring.
215
P
A.1
LOKÁLNÍ SÍTĚ
216
Přenášené bity jsou členěny na znaky (většinou 7 nebo 8 bitů), použı́váme také pojem oktet, který
znamená vždy právě 8 bitů (většinou jsou tyto pojmy ekvivalentnı́).
Sekvenčnı́ přenosy jsou v sı́tı́ch obvyklé.
Poznámka: Pojem Byte sice obvykle označuje skupinu 8 po sobě následujı́cı́ch bitů, ale v určitém
kontextu může znamenat 7 po sobě jdoucı́ch bitů, proto tento pojem nenı́ z důvodu nejednoznačnosti v oblasti sı́tı́ moc použı́ván. Použitelnějšı́ je naopak pojem oktet, který má přı́mo v sobě zahrnut
počet 8. Navı́c se skloňuje jednodušeji než Byte.
Sériový asynchronnı́ přenos – znak je přenášen „vcelku“, ale mezi jednotlivými znaky mohou
být jakkoliv dlouhé časové prodlevy.
Arytmický přenos znamená úpravu asynchronnı́ho přenosu částečnou synchronizacı́, použı́vajı́
se speciálnı́ značky obklopujı́cı́ data.
L
P
Posloupnost v rámci jednoho znaku:
[start-bit]
[data znaku]
[paritnı́ bit]
[stop-bit]
V následujı́cı́m nákresu na obrázku A.1 si všimněte pořadı́ bitů – je opačné oproti tomu, na které
jsme zvyklı́ na papı́ře.
Přenos znaku (01101001)2:
ST 1 0
0 1
0 1
1 0
P SP
P . . . paritnı́ bit
ST . . . start bit
SP . . . stop bit
Obrázek A.1: Sériový asynchronnı́ přenos
Sériový synchronnı́ přenos – data jsou přenášena v blocı́ch, uvnitř bloků nesmı́ dojı́t k časovým
prodlevám mezi znaky. Nepoužı́vajı́ se start-bity ani stop-bity, ale paritnı́ bity mohou být použity.
Na začátku bloku je jeden nebo vı́ce synchronizačnı́ch znaků, na konci bloku také (mohou být
vysı́lány až do začátku dalšı́ho bloku).
Přenos sekvence dvou znaků (01101001)2
SYN 1
0 0
1 0
1 1
0 1
0 0
P
(01101001)2:
1
0 1
1 0
SYN
SYN. . . synchronizačnı́ bit
Obrázek A.2: Sériový synchronnı́ přenos
Typy komunikace v LAN
1. unicast – jeden zdroj a jeden cı́l, paket je odesı́latelem adresován přı́jemci, jde o komunikaci
mezi dvěma uzly v sı́ti,
P
A.1
LOKÁLNÍ SÍTĚ
217
2. multicast – tentýž paket je adresován množině uzlů v sı́ti, tj. shodné kopie paketu jsou posı́lány
na vı́ce stanovených adres v sı́ti (přı́jemce stanovı́ multicast adresu, která obsahuje adresy uzlů–
přı́jemců),
3. broadcast – tentýž paket je adresován všem uzlům v sı́ti, použije se broadcast adresa,
4. anycast (v IPv6) – výběrová adresa; je podobná skupinové (také představuje skupinu zařı́zenı́),
ale datagram je doručen jen jednomu zařı́zenı́ ze skupiny (většinou nejbližšı́mu).
Duplex
stanovı́, kterým směrem komunikace může vést:
• simplexnı́ spojenı́ – pouze jednosměrné
P
• polovičnı́ duplex (half duplex) – spojenı́ je obousměrné, ale v jednom okamžiku lze přenášet
data pouze jednı́m směrem,
• plný duplex (full duplex) – spojenı́ je obousměrné, v jednom okamžiku mohou komunikovat
obě strany zároveň.
Plný duplex je často sestavován pomocı́ dvou navzájem opačných simplexů. Tento způsob komunikace je obvykle možný jen na point-to-point spojı́ch.
A.1.2
Vlastnosti služeb
Spojová služba (connection-oriented) nejdřı́v naváže spojenı́ a pak teprve posı́lá data. Komunikace má tři fáze: navázánı́ spojenı́, odeslánı́ dat, ukončenı́ spojenı́. V rámci navázánı́ spojenı́ se
dohodnou podmı́nky přenosu. Tento typ služby většinou dokáže ohlı́dat ztrácenı́ paketů.
P
Nespojová služba (connectionless) posı́lá data bez předchozı́ho navázánı́ spojenı́. Data mohou
být také rozdělena na vı́ce částı́ (paketů, rámců), každý z nich musı́ být „očı́slován“ svým pořadı́m
v původnı́m proudu dat (zprávě) a musı́ být zřejmé, který je prvnı́ a který poslednı́. Tento typ
služby může nebo nemusı́ vyžadovat potvrzenı́, tedy se dělı́ do dvou podskupin:
• nepotvrzovaná služba bez spojenı́,
• potvrzovaná služba bez spojenı́ (s potvrzenı́m doručenı́ dat).
Při využitı́ potvrzované služby se spojenı́m se potvrzuje přijetı́ dat (bud’ po každé přijaté datové
jednotce nebo po dohodnutém počtu datových jednotek či oktetů, s tı́m se setkáme napřı́klad
u pojmu windowing).
Dále potřebujeme znát následujı́cı́ pojmy.
Přenosový kanál (channel) je souhrn prostředků (kabely, bezdrátové cesty, spojová zařı́zenı́
apod.), které vytvářejı́ komunikačnı́ spojenı́ (jednosměrné). Je charakterizován (fyzikálnı́mi) vlastnostmi jako je přenosová rychlost, úroveň šumu, šı́řka pásma apod.
Okruh
(circuit) je obousměrné spojenı́ sestavené z komunikačnı́ch kanálů.
Šı́řka pásma (bandwidth) je šı́řka intervalu frekvencı́, které je přenosový kanál schopen přenést
(jednotka šı́řky pásma je stejná jako jednotka frekvence).
Obecně: čı́m většı́ šı́řka pásma, tı́m vyššı́ přenosová rychlost spojenı́.
P
A.1
LOKÁLNÍ SÍTĚ
A.1.3
218
Multiplexovánı́
Multiplexing znamená sdružovánı́ různých datových proudů do jedné fyzické komunikačnı́ cesty.
Přenosový kanál s dostatečně vysokou šı́řkou pásma rozdělı́me na vı́ce (logických) subkanálů,
které se jevı́ jako samostatné. Multiplexing může probı́hat na kterékoliv vrstvě ISO/OSI.
P
Jde vlastně o dvě činnosti:
• multiplexovánı́ probı́há na zdrojovém zařı́zenı́ (source),
• demultiplexovánı́ probı́há na cı́lovém zařı́zenı́ (destnation) na stejné vrstvě jako u zdroje, jde
o převod multiplexovaných dat do původnı́ho tvaru.
K multiplexovánı́ sloužı́ multiplexor, k demultiplexovánı́ sloužı́ demultiplexor.
Základnı́ varianty multiplexingu
• frekvenčnı́ multiplex (frequency division multiplexing, FDM) – každý subkanál má přidělen
vlastnı́ interval frekvencı́; signál je při přenosu posunut do šı́řky pásma pro daný subkanál
a po přenosu je posunut zpět (úpravy signálu se provádějı́ kmitočtovým filtrem), v současné
době se s variantami setkáváme v satelitnı́ch, kabelových a některých rádiových sı́tı́ch,
• časový multiplex (time division multiplexing, TDM) – celý kanál je střı́davě (na krátké časové
úseky) přidělován jednotlivým subkanálům, použı́vá se napřı́klad v GSM,
• statistický multiplex (statistical time division multiplex, STDM) – šı́řka pásma je dynamicky
přidělována podle předpokládaných potřeb (statisticky vypočtených z historie); je to vlastně
pozměněná asynchronnı́ varianta TDM, která podporuje inteligentnı́ řı́zenı́ vytı́ženı́ sı́tě,
• vlnové dělenı́ (wavelength division multiplex, WDM) se použı́vá v optických vláknech; pracuje
na podobném principu jako FDM, jen mı́sto frekvencı́ mluvı́me o vlnových délkách (také
barvách) světla, tuto metodu lze také kombinovat s TDM či STDM,
• kódové dělenı́ (code division multiple access, CDMA) vzniklo původně pro potřeby armády;
spočı́vá v rozprostřenı́ užitného signálu podle daného algoritmu v závistlosti (kromě jiného)
na počtu a umı́stěnı́ vysı́lajı́cı́ch uživatelů, což znesnadňuje odposlouchánı́ signálu (výsledný
signál se jevı́ jako silně zašuměný a bez znalosti způsobu zakódovánı́ nelze jednotlivé původnı́
signály oddělit, pro oddělenı́ jednotlivých komunikacı́ je třeba použı́t programový kód),
použı́vá se napřı́klad v systémech UMTS,
• ortogonálnı́ multiplex s frekvenčnı́m dělenı́m (Orthogonal Frequency Division Multiplexing,
OFDM) použı́vá několik stovek až tisı́c nosných kmitočtů tak, aby jednotlivé nosné byly
navzájem ortogonálnı́ (to znamená, že maximum nosných se minimálně překrývá s jinými
nosnými). Typické využitı́ je předevšı́m v bezdrátových sı́tı́ch (včetně Wi-Fi) a ADSL.
Obrázek A.3: Frekvenčnı́, časový a statistický multiplex (statistický: pro ideálnı́ přı́pad)
P
A.1
LOKÁLNÍ SÍTĚ
219
Časové úseky, které jsou přidělovány v TDM a STDM, se nazývajı́ sloty (na obrázku A.3 to jsou
stejně dlouhé úseky v druhém a třetı́m podobrázku, do kterých dosazujeme úseky jednotlivých
konverzacı́).
A.1.4
Přı́stupové metody
Žádná dvě zařı́zenı́ by neměla zası́lat data ve stejném kanálu v jednom časovém okamžiku.
CSMA/CD (Carrier Sense Multiple Access, Collision Detect) – použı́vá se u Ethernetu. Vycházı́
z toho, že pokud dvě zařı́zenı́ vysı́lajı́ data zároveň, dojde ke kolizi. Postup řešenı́:
P
• zařı́zenı́, které chce vysı́lat data, naslouchá, zda jiné zařı́zenı́ právě vysı́lá,
• pokud ne, začne vysı́lat,
• po ukončenı́ přenosu jednotky opět poslouchá, zda nedošlo ke kolizı́m,
• když zjistı́ kolizi, vyčká po dobu o náhodně vygenerované délce (tj. každé z „kolidujı́cı́ch“
zařı́zenı́ zřejmě čeká jinou dobu) a teprve pak začne vysı́lat znovu.
Podrobný postup probereme v kapitole o Ethernetu.
Čı́m vı́c je vysı́lajı́cı́ch zařı́zenı́, tı́m vyššı́ pravděpodobnost kolize a tı́m nižšı́ propustnost. Tento
problém se dá částečně řešit přidánı́m přepı́načů (switch), které mohou oddělit jednotlivé oblasti
sı́tě (tzv. koliznı́ domény) a snı́žit množstvı́ kolizı́.
CSMA/CA (Carrier Sense Multiple Access, Collision Avoidance) – kolizı́m se přı́mo předcházı́
(ne doslova, lépe to vystihuje pojem „moc neřešı́“), stanice jednoduše před vysı́lánı́m naslouchá,
jestli nevysı́lá nikdo jiný, tato metoda je určena pro bezdrátové sı́tě (opět probereme v přı́slušné
kapitole).
Token Passing je metoda posı́lánı́ „peška“ – tokenu. Token se posı́lá postupně všem zařı́zenı́m
v sı́ti, pouze to zařı́zenı́, které má právě token, může vysı́lat.
Pokud zařı́zenı́ dostane token a nemá co vysı́lat, pošle token dál. Pokud zařı́zenı́ dostane token
a má co vysı́lat, provede přenos a až po jeho ukončenı́ pošle token dál. Jiná forma Token Passing:
token může sloužit jako nosná datová jednotka, tj. pokud je token volný a stanice má co vyslat,
přidá svá data a dalšı́ údaje (včetně cı́le) k tokenu a pošle dál, adresát (cı́l) si data vyzvedne a token
může být využit jiným uzlem v sı́ti.
Při stanovené velikosti přenášených dat (velikost rámce nebo paketu) a známém množstvı́
zařı́zenı́ schopných vysı́lat je možné vypočı́st maximálnı́ dobu čekánı́ na token, to je výhodou
v real-time provozech.
Poloduplexnı́ a plně duplexnı́ přı́stup metody CSMA/CD i Token Passing jsou samy o sobě
z principu poloduplexnı́. Pokud přidáme switch, u obou metod lze dosáhnout plně duplexnı́ho
přı́stupu, což znamená zvýšenı́ propustnosti.
A.1.5
Řı́zenı́ toku dat v sı́ti
Sı́t’ové zařı́zenı́ (následujı́cı́ se týká mezilehlých sı́t’ových zařı́zenı́ jako jsou např. přepı́nače nebo
směrovače) potřebuje buffer (cache, vyrovnávacı́ pamět’). Zde ukládá přı́chozı́ datové jednotky bit
P
P
A.2
WAN SÍTĚ
220
po bitu, aby bylo možné takovou datovou jednotku zpracovat (předevšı́m potřebuje zjistit, na který
port má datovou jednotku odeslat, tedy určitá adresa, podle typu zařı́zenı́), přı́p. zkontrolovat, zda
je vpořádku (kontrolnı́ součet, platná délka apod.).
Pokud datové jednotky přicházejı́ přı́liš rychle a sı́t’ové zařı́zenı́ je nestačı́ odbavovat, může dojı́t
k přetečenı́ bufferu (vyrovnávacı́ pamět’nestačı́).
Tedy je potřeba zabránit zahlcenı́ sı́tě, přetečenı́ bufferu apod. – pro tyto účely existujı́ kromě
samotné existence vyrovnávacı́ paměti ještě tři základnı́ metody:
1. Zprávy o zahlcenı́ (source-quench messages) – přijı́majı́cı́ zařı́zenı́ posı́lá zdrojovému (tj. vysı́lajı́cı́mu) zařı́zenı́ žádost o snı́ženı́ přenosové rychlosti (resp. intervalů) zası́laných paketů.
Tato metoda se využı́vá např. na třetı́ vrstvě TCP/IP, existuje ICMP zpráva č. 4 Source Quench
(zpráva zdroji dat, aby snı́žil rychlost odesı́lánı́).
$
2. Zahazovánı́ paketů – přijı́majı́cı́ zařı́zenı́ může zahazovat obdržená data, aby zabránilo přetečenı́ vyrovnávacı́ paměti, zdrojové zařı́zenı́ po určité době posı́lá znovu zahozené pakety
a postupně opět zvyšuje přenosovou rychlost. Jeden z algoritmů je napřı́klad Token Bucket
(použı́vá se na směrovačı́ch).
3. Windowing – zdroj dostane povolenı́ odeslat určitý počet paketů (window size = tento počet),
když cı́l z nějakého důvodu neobdržı́ tento počet paketů, zdroj je posı́lá znovu se snı́ženou
rychlostı́ přenosu. Obdoba se použı́vá napřı́klad v protokolu TCP, pod názvem Sliding Window
(služba se spojenı́m).
A.2
WAN sı́tě
A.2.1
Okruhy
Vı́me, že okruh je tvořen několika komunikačnı́mi kanály. Okruhů existuje také vı́ce druhů.
Typy okruhů podle vlastnictvı́ a možnosti užı́vánı́:
• soukromé (private) – uživatel (provozovatel) si sám zřı́dı́ přenosovou cestu,
P
• veřejné (private) – zřizuje spojová organizace (obvykle státnı́ nebo monopolnı́ v dané zemi),
za poplatek může takové okruhy použı́vat každý,
• pronajaté (leased) – provozovatel potřebuje mı́t okruh neustále k dispozici, tak si ho pronajme
od spojové organizace; zůstává majetkem spojové organizace, ale výhradnı́ právo k užı́vánı́
má provozovatel.
Fyzický okruh je okruh, který zcela souhlası́ s fyzickou přenosovou cestou (pořád stejnou) a nenı́
přerušen žádným meziuzlem (třeba ústřednou), obvykle je to soukromá přenosová cesta.
Virtuálnı́ okruh je logický okruh (ne fyzický) přes sdı́lené přenosové cesty. Je to nejobvyklejšı́
možnost v rozlehlých sı́tı́ch. Rozlišujeme dva typy virtuálnı́ch okruhů:
• pevný (trvalý, PVC)
• komutovaný (přepı́naný, SVC)
P
P
A.2
WAN SÍTĚ
221
1. Pevný virtuálnı́ okruh (také non-switched, direct, trvalý, PVC – permanent virtual circuit),
zůstává vyhrazen svému provozovateli po celou dobu vlastnictvı́/pronájmu. Tento typ okruhu
se musı́ vytvořit manuálně, vytvořenı́ je proto náročnějšı́ a pomalejšı́, jeho použı́vánı́ je obvykle
dlouhodobějšı́ – týdny/měsı́ce/roky.
Tento typ okruhu obcházı́ meziuzly (ústředny apod.), tedy komunikace je rychlejšı́, a netýkajı́
se jich souvisejı́cı́ poruchy, proto je považován za kvalitnějšı́.
2. Komutovaný virtuálnı́ okruh (také switched, dial-up, přepı́naný, SVC – switched virtual
circuit) je dočasně sestaven během navázánı́ spojenı́, přestane existovat po ukončenı́ spojenı́ (proces
sestavenı́ okruhu v ústředně = komutace). Vytvářı́ se automaticky, softwarově, a to takto:
•
•
•
•
A.2.2
zašle se požadavek s potřebnými informacemi,
jsou dohodnuty parametry spojenı́ vyhovujı́cı́ všem zainteresovaným uzlům,
vysı́lacı́ uzel obdržı́ identifikátor jednoznačný pro vzniklý okruh,
posı́laná data pak neobsahujı́ směrovacı́ informace (stačı́ tento identifikátor).
Komunikace v rozlehlé sı́ti
Ve WAN sı́tı́ch se použı́vajı́ tři základnı́ typy spojenı́:
1. Point-to-Point
2. Přepı́nánı́ okruhů
3. Přepı́nánı́ paketů
Point-to-Point komunikace je jednoduchá komunikace s navázánı́m spojenı́ přes sı́t’poskytovatele
(majitele infrastruktury – drátů apod.) realizovaná přepravcem (napřı́klad telefonnı́ společnostı́).
Linka je „pronajata“ od poskytovatele (leased circuit). Při vzniku spojenı́ je trvale vyhrazena dvojice
linek pro toto nově vytvářené spojenı́ (plný duplex).
Přepı́nánı́ okruhů (Circuit Switching) – na začátku komunikace se vytvořı́ okruh s pevně nastavenou přenosovou kapacitou (obvykle při spojově orientovaných službách). Narozdı́l od předchozı́ho
zde okruhy nejsou stálé, ale vznikajı́ a zanikajı́ podle potřeby (komutované, přepı́nané).
P
P
Výhodou je jednoduchý způsob účtovánı́, spojenı́ (po navázánı́) funguje prakticky „v reálném
čase“ (bez zastavovánı́ v meziuzlech). Nevýhodou je nutnost rezervace přenosových cest, které by
mohl využı́vat také někdo jiný.
Toto řešenı́ je obvyklé pro velké veřejné datové sı́tě (CSPDN – Circuit Switching Public Data
Network), typický přı́klad: ISDN.
Přepı́nánı́ paketů (Packet Switching) – data jsou členěna na části (pakety) a posı́lána sdı́leným kanálem (obvykle při nespojových službách). Každý paket musı́ mı́t informaci o adresátovi (přı́padně
také o odesı́lateli) a dalšı́ (směrovacı́) informace, což u předchozı́ch nebylo nutné.
Výhodou je, že kapacita přenosových cest může být snadněji sdı́lena. Nevýhodou je, že rychlost
přenosu paketů je závislá na vytı́ženı́ sı́tě (v meziuzlech je paket nejdřı́v uložen do mezipaměti a až
po uvolněnı́ linky je poslán dál).
P
A.3
MODEL ISO/OSI
222
Dostupný přenosový kanál
Jednotlivé okruhy
-
Dostupný přenosový kanál
Přenášené pakety
-
Obrázek A.4: Přepı́nánı́ okruhů a přepı́nánı́ paketů ve WAN
Toto řešenı́ je obvyklé pro lokálnı́ sı́tě. Pokud je použito pro velkou veřejnou datovou sı́t’,
mluvı́me o PSPDN (Packet Switched Public Data Network).
Variantou (podobně fungujı́cı́) ke přepı́nánı́ paketů je také přepojovánı́ buněk v X.25 nebo ATM,
a přepojovánı́ rámců v sı́ti Frame Relay.
A.3
Model ISO/OSI
A.3.1
Princip
ISO/OSI Open System Interconnection Reference Model byl vydán sdruženı́m ISO v roce 1984 jako
norma IS 7498.
7.
6.
5.
4.
3.
2.
1.
Aplikační vrstva
(application layer)
Prezentační vrstva
(presentation layer)
Relační vrstva
(session layer)
Transportní vrstva
(transport layer)
Síťová vrstva
(network layer)
Linková vrstva
(data link layer)
Fyzická vrstva
(physical layer)
. . . aplikačně orientované vrstvy
. . . přizpůsobovací vrstva
. . . vrstvy orientované na přenos
Obrázek A.5: Model ISO/OSI
P
A.3
MODEL ISO/OSI
223
Jedná se abstraktnı́ model určený speciálně pro použitı́ v počı́tačových sı́tı́ch. V normě nejsou
nikde specifikovány implementace (tj. konkrétnı́ naprogramovánı́), najdeme zde pouze principy,
popis přı́stupových rozhranı́ a funkcı́. Dokonce ani popis komunikačnı́ch protokolů nenı́ součástı́
normy, protokoly jsou specifikovány až v navazujı́cı́ch normách ISO a doporučenı́ch ITU-T.
Princip je jednoduchý – sı́t’ová komunikace na zařı́zenı́ je rozčleněna do sedmi úrovnı́ (sı́t’ové
zařı́zenı́ však nemusı́ nutně implementovat všechny vrstvy, jak později uvidı́me). Každá úroveň
(vrstva) má svou vlastnı́ úlohu a je relativně nezávislá na ostatnı́ch.
Každá vrstva komunikuje pouze s okolnı́mi vrstvami, a to tak, že vrstva poskytuje své služby
vrstvě bezprostředně nadřı́zené a je klientem (využı́vá služeb) vrstvy bezprostředně podřı́zené.
Na obrázku A.5 vidı́me rozloženı́ vrstev. Tedy napřı́klad linková vrstva je klientem fyzické
vrstvy (využı́vá jejı́ch služeb) a své služby poskytuje sı́t’ové vrstvě.
V praxi (předevšı́m v navazujı́cı́m modelu TCP/IP, ale i jinde) se setkáváme s rozdělenı́m
některých vrstev na podvrstvy (obvykle dvě), napřı́klad právě linková vrstva bývá takto rozdělena
(ovšem podle jiné normy, v tomto přı́padě napřı́klad IEEE).
Na obrázku A.5 si také můžeme všimnout barevného rozdělenı́ vrstev do třı́ zón. Spodnı́ (zelená)
zóna zahrnuje vrstvy orientované na přenos, tato zóna se zabývá předevšı́m technickými detaily
přenosu (jak vhodně data upravit, rozdělit apod. tak, aby bylo možné je přenést). Hornı́ (žlutá) zóna
obsahuje vrstvy aplikačně orientované (nezabývajı́ se přı́mo přizpůsobovánı́m dat pro přenos, ale
spı́še logickými vlastnostmi spojenı́). Mezi těmito dvěma zónami je přizpůsobovacı́ zóna obsahujı́cı́
pouze transportnı́ vrstvu.
A.3.2
Pojmy
S modelem ISO/OSI souvisejı́ tyto pojmy:
Entita je prvek pracujı́cı́ na konkrétnı́ vrstvě, je to konkrétnı́ prvek, který bud’ poskytuje službu
(je poskytovatel služby) nebo využı́vá službu některé entity z nižšı́ vrstvy.
Pro množinu entit, které jsou všechny v rámci jedné vrstvy, se také použı́vá pojem peer entities.
Přı́stupový bod služby (SAP – Service Access Point) je bod na pomezı́ dvou vrstvev, přes který
komunikujı́ dvě entity v sousednı́ch vrstvách. Každý SAP má jednoznačnou adresu. Přes jeden
SAP může v jednom okamžiku vést pouze jediná komunikace (ale na druhou stranu entita může
v jednom okamžiku komunikovat přes vı́ce různých SAP k jedné nebo obou sousednı́ch vrstvách).
Protokol (obvykle ve spojenı́ komunikačnı́ protokol) je sada pravidel a konvencı́ určujı́cı́ch,
jakým způsobem probı́há výměna dat mezi dvěma prvky (počı́tači v sı́ti). Zahrnuje služby jedné
nebo vı́ce vrstev v ISO/OSI, obvykle ke komunikaci v rámci jedné vrstvy. Rozlišujeme
• mezivrstvové protokoly – sloužı́ ke komunikaci mezi entitami v sousednı́ch vrstvách v rámci
jednoho systému (zařı́zenı́), komunikuje se přes některý SAP,
• vrstvové protokoly – sloužı́ ke komunikaci mezi entitami na stejné vrstvě, ale v různých systémech (na různých zařı́zenı́ch), napřı́klad mezi linkovými vrstvami na dvou zařı́zenı́ch v sı́ti.
P
P
P
A.3
MODEL ISO/OSI
224
Vrstvové protokoly narozdı́l od mezivrstvových nefungujı́ „přı́mo“, komunikace mezi různými
systémy probı́há vždy přes nižšı́ vrstvy obou systémů.
Soustava protokolů (Protocol Suite) je skupina protokolů pro konkrétnı́ model. Pro tutéž činnost
může existovat vı́ce alternativnı́ch protokolů.
Protokolový zásobnı́k (Protocol Stack) Ze soustavy protokolů vybereme pro každou činnost po
jednom protokolu (odstranı́me alternativy). Je jednı́m z určujı́cı́ch faktorů implementace architektury sı́tě. Nejznámějšı́ sestavou protokolů je rodina protokolů TCP/IP.
Služba poskytovaná vrstvou je fyzicky zajišt’ována entitami v této vrstvě přes body SAP. Každá
služba je specifikovaná dvěma údaji:
• primitivum určujı́cı́ základnı́ poskytovanou funkci (žádost o službu nižšı́ vrstvě, oznámenı́
vedoucı́ k provedenı́ některých kroků, odpověd’ o splněnı́ kroků v oznámenı́, potvrzenı́
o splněnı́ žádosti), vše vztažené k jednomu SAP,
• řı́dicı́ parametry, které upřesňujı́ informaci danou primitivem.
Funkce je konkrétnı́ činnost jedné entity vedoucı́ k poskytnutı́ dané služby.
PDU (Protocol Data Unit) je protokolová datová jednotka – stanovený formát dat (s přı́davnými
informacemi) pro komunikaci s konkrétnı́m protokolem. Typické PDU jsou rámce nebo pakety.
Protože každý protokol bývá úzce spojen s jedinou vrstvou, PDU také souvisejı́ s touto vrstvou.
P
PDU většinou obsahuje záhlavı́ s řı́dicı́mi informacemi, obvykle (ne vždy) následované přenášenými daty. Součástı́ také může být zápatı́ (pata) s dodatečnými informacemi, typicky kontrolnı́m
součtem.
Každá PDU postupně přecházı́ mezi vrstvami ISO/OSI modelu. Při přenosu „směrem dolů“
je z původnı́ PDU vytvořena nová PDU jiného protokolu (jiné vrstvy) tak, že může (nemusı́) být
rozdělena či zřetězena s jinou PDU, a dále je připojeno záhlavı́ (někdy i zápatı́) dalšı́ vrstvy.
A.3.3
Vrstvy
Na tomto mı́stě si pouze stručně popı́šeme vlastnosti jednotlivých vrstev modelu ISO/OSI. Podrobně (včetně konkrétnı́ho použitı́ a protokolů) se jimi budeme zabývat v následujı́cı́ch kapitolách.
Fyzická vrstva (physical layer) definuje elektrické, mechanické, procesnı́ a funkčnı́ specifikace
pro aktivaci, údržbu a deaktivaci fyzického spojenı́ dvou zařı́zenı́ (úrovně napětı́, časovánı́ změn
napětı́ – jak dlouho trvá přenos bitu, konektory – kolik kontaktů, jaký majı́ význam, atd.).
Do této vrstvy nepatřı́ přı́mo žádné přenosové zařı́zenı́, je nad samotným hardwarem (definuje
pouze potřebné vlastnosti zařı́zenı́/konektoru, které připojujeme).
V této vrstvě pracujeme s jednotlivými bity zası́laných dat (respektive jejich fyzikálnı́ reprezentacı́), pro data nenı́ definována žádná datová struktura (žádný paket, rámec ani Byte).
Funkce vrstvy souvisejı́ s přenosem bitů přes fyzické rozhranı́. Zajišt’uje aktivaci a deaktivaci
fyzického spojenı́, určenı́ duplexu (plného nebo polovičnı́ho), provozovánı́ okruhů, identifikaci
přijı́mané posloupnosti bitů nebo značek (bity nemůže přeuspořádávat, předává je výše ve stejném
pořadı́, v jakém je dostala), modulaci a demodulaci.
P
A.3
MODEL ISO/OSI
225
Na této vrstvě se nehovořı́ ani tak o protokolech, jako spı́še o standardech. V tomto textu se jim
budeme věnovat jen zběžně. Patřı́ zde napřı́klad standardy, které už známe u konektorů – USB,
RS-232, BlueTooth, FireWire, dále fyzická rozhranı́ pro Ethernet, telekomunikačnı́ sı́tě apod.
Linková (spojová) vrstva
(data link layer) zajišt’uje spolehlivý průchod dat z/do fyzické vrstvy.
Narozdı́l od fyzické vrstvy nebere data jako pouhou posloupnost bitů, ale členı́ je do rámců
(frame), musı́ umět rozpoznat hranice mezi rámci. Porovnává kontrolnı́ součty rámců, při zjištěnı́
chyby si vyžádá opakovánı́ přenosu rámce.
P
S rámci souvisı́ typické funkce – zahájenı́ a ukončenı́ přenosu, řı́zenı́ pořadı́ rámců, detekce
a oprava chyb souvisejı́cı́ch s přenosem rámců (které vznikajı́ na fyzické vrstvě), řı́zenı́ využı́vánı́
telekomunikačnı́ch okruhů ve fyzické vrstvě, fyzická adresace. Pracuje totiž s fyzickými adresami
zařı́zenı́ (MAC adresy).
Podle IEEE má linková vrstva dvě podvrstvy:
1. LLC (Logical Link Control)
2. MAC (Media Access Control)
Většina lokálnı́ch sı́tı́ (ale ne všechny) implementuje pouze vrstvy fyzickou a linkovou (přı́padně
z nı́ jen MAC), vyššı́ vrstvy nejsou potřeba (směrovánı́ probı́há podle MAC adres).
Typické protokoly: LAPB, HDLC, PPP, atd., budeme se jim věnovat poměrně hodně v následujı́cı́ch
kapitolách.
Sı́t’ová vrstva (network layer) definuje sı́t’ovou adresu zařı́zenı́ (to může být napřı́klad IP adresa).
Zajišt’uje směrovánı́ (routing) – volbu vhodné trasy mezi dvěma sı́t’ovými uzly, tj. pracuje s logickou
strukturou sı́tě.
P
Vyššı́ vrstvy (nad sı́t’ovou vrstvou) chápou sı́t’ uzlů jako plně propojenou, způsob přenosu je
nezajı́má, nižšı́ vrstvy naopak vidı́ pouze to propojenı́, které je určeno sı́t’ovou vrstvou.
Hlavnı́ službou této vrstvy je přenos dat mezi entitami transportnı́ vrstvy (na různých systémech), dále zajišt’uje sı́t’ové adresovánı́, identifikaci koncových bodů spojenı́, atd. Poskytované
služby se dělı́ na služby se spojenı́m a bez spojenı́ (bud’ pouze přenos bloků dat nebo kompletnı́
navázánı́ spojenı́–přenos–ukončenı́ spojenı́).
Sı́t’ová vrstva pracuje s pakety transportnı́ vrstvy.
Typické protokoly: IP (bez spojenı́), X.25 (se spojenı́m), ARP, RARP (překlad mezi MAC a IP
adresou). Do této vrstvy ve skutečnosti nejsou zařazeny směrovacı́ protokoly (i když by se to snad
zdálo logické), ty jsou zařazeny do protokolů managementu (řı́zenı́) sı́tě.
Transportnı́ vrstva (transport layer) přijı́má data z relačnı́ vrstvy a členı́ je na transportnı́ části
– pakety (packet), které se pak posı́lajı́ dále do sı́tě (z pohledu transportnı́ vrstvy směrem k sı́t’ové
vrstvě). Pakety přijaté zdola od sı́t’ové vrstvy naopak seřazuje a skládá v nich obsažená data (jeden
proud dat může být, a často bývá, rozdělen do vı́ce paketů).
Transportnı́ vrstva je předevšı́m zodpovědná za doručovánı́ dat ve správném formátu a pořadı́
(pakety, do kterých je rozdělen jeden proud dat, mohou v sı́ti putovat různými cestami, a proto je
možné, že dojdou v jiném pořadı́, než v jakém byly odeslány).
P
A.3
MODEL ISO/OSI
226
Vrstvy pod transportnı́ vrstvou jsou závislé na sı́t’ové implementaci (přenosové metodě, hardwaru, apod.), vrstvy nad nı́ nejsou závislé na sı́t’ové implementaci. Transportnı́ vrstva tedy plnı́
funkci rozhranı́ (překladatele) i v tomto smyslu, vyrovnává rozdı́ly mezi různými implementacemi
tak, aby na vyššı́ch vrstvách nebyly patrné.
Transportnı́ vrstva poskytuje relačnı́ vrstvě dva základnı́ druhy služeb – transport bez spojenı́
a transport se spojenı́m. Dı́lčı́ služby jsou pak závislé na jedné z těchto základnı́ch služeb (napřı́klad
může být poskytována služba detekce a opravy chyb).
Každá (komunikujı́cı́) entita z vyššı́, relačnı́, vrstvy dostane svou vlastnı́ transportnı́ adresu.
Transport pak probı́há mezi dvěma transportnı́mi adresami na různých systémech (tj. z pohledu
relačnı́ vrstvy mezi dvěma entitami, které využı́vajı́ některý SAP k transportnı́ vrstvě). Mezi dvěma
transportnı́mi adresami může probı́hat (teoreticky) jakékoliv množstvı́ transportů.
Na transportnı́ vrstvě jsou určeny různé třı́dy služeb poskytovaných entitám relačnı́ vrstvy. Třı́dy
služeb se lišı́ v různých parametrech, napřı́klad chybovost, propustnost, apod.
Na transportnı́ vrstvě najdeme mnoho funkcı́, napřı́klad adresovánı́ (transportnı́ adrese je přiřazena sı́t’ová adresa), detekce a oprava chyb, multiplexovánı́, dělenı́ bloku dat nebo naopak jeho
skládánı́, atd.
Typické protokoly: přenosové protokoly TCP (se spojenı́m) nebo UDP (bez spojenı́).
Relačnı́ vrstva (session layer) pracuje s relacemi (session), tedy navázanými spojenı́mi. Komunikačnı́ relace se skládá ze služebnı́ch dotazů a odpovědı́ probı́hajı́cı́ch mezi aplikacemi na různých
zařı́zenı́ch v sı́ti. Na této vrstvě jsou implementovány protokoly, ve kterých tato komunikace probı́há.
P
Relačnı́ vrstva tedy zajišt’uje organizovánı́ spojenı́ – navazovánı́ a ukončovánı́ přenosů (posı́lá
přı́slušné přı́kazy transportnı́ vrstvě), synchronizaci komunikace, překlad jmen na adresy a naopak,
bezpečnost přı́stupu (něco jako telefonnı́ ústředna v telekomunikacı́ch). Jedna entita relačnı́ vrstvy
může vést vı́ce relacı́ zároveň.
Typické protokoly: NFS (sı́t’ový souborový systém), NetBIOS (zpřı́stupňovánı́ dat v menšı́ch
sı́tı́ch), SSL (autentizace podpořená šifrovánı́m).
Prezentačnı́ vrstva (presentation layer) se stará o prezentaci dat (tedy jejich vnitřnı́ syntaktickou
strukturu). Provádı́ konverze dat z aplikačnı́ vrstvy (převody do jiných typů datové reprezentace)
a odpovı́dá za to, že data z aplikačnı́ vrstvy jednoho zařı́zenı́ budou srozumitelná aplikačnı́ vrstvě
jiného zařı́zenı́. Na této vrstvě se taktéž implementuje šifrovánı́ a komprese.
P
Typické funkce jsou dohoda o syntaxi přenášených dat, transformace syntaxe dat, šifrovánı́,
komprese, žádost o vytvořenı́ či zrušenı́ relace (pozor – žádost, ne samotné vytvořenı́ a zrušenı́).
Do struktury dat lze zasahovat pouze v této vrstvě, ostatnı́ vrstvy mohou data pouze dělit, spojovat
nebo obohacovat o dalšı́ informace.
Typické protokoly: SMB (přenos souborů – SAMBA), dále šifrovacı́ nebo komprimačnı́ protokoly.
Aplikačnı́ vrstva (application layer) navzdory svému názvu neobsahuje sı́t’ové aplikace, ale
s aplikacemi komunikuje. Obvykle zahrnuje identifikaci, zjišt’ovánı́ dostupnosti zdrojů, synchronizaci komunikace.
Konkrétně obsahuje funkce (moduly) využı́vané aplikacemi jako je e-mailový klient, FTP klient,
P
A.4
IEEE 802
227
webový klient (Internetový prohlı́žeč), aplikacemi přistupujı́cı́mi ke vzdáleným databázı́m, apod.
Hlavnı́m úkolem aplikačnı́ vrstvy je tedy zajišt’ovánı́ rozhranı́ mezi sı́t’ovými aplikacemi a sı́t’ovým komunikačnı́m systémem.
Typické protokoly: SMTP (posı́lánı́ pošty), POP3 a IMAP (stahovánı́ pošty), FTP nebo TFTP (přenos
souborů), Telnet nebo SSH (vzdálený přı́stup), SNMP (správa sı́tě).
A.3.4
PDU
Na různých vrstvách se použı́vajı́ různé PDU (protocol data unit, datové jednotky).
Rámec
se použı́vá na linkové vrstvě. Skládá se ze třı́ částı́:
• hlavička linkové vrstvy (header),
• data z vyššı́ch vrstev,
• patička (trailer), často obsahuje kontrolnı́ součet (CRC).
Paket se použı́vá na sı́t’ové vrstvě, má podobnou strukturu (hlavička sı́t’ové vrstvy, data z vyššı́
vrstvy, patička sı́t’ové vrstvy).
Datagram (také IP datagram) je obdoba paketu v terminologii protokolu IP (také na sı́t’ové
vrstvě, u nespojové služby), datagram musı́ být zcela samostatná PDU (obsahuje veškeré informace
o adresátovi i odesı́lateli a čı́slo pořadı́ ve zprávě vyššı́ vrstvy).
Segment se použı́vá na transportnı́ vrstvě v protokolech TCP a UDP. Jeho délka obecně nenı́
omezena, předpokládá se jeho dalšı́ rozdělenı́ na nižšı́ (sı́t’ové) vrstvě. Součástı́ segmentu nebývajı́
adresy zdrojového a cı́lového uzlu, ty se přiřazujı́ až na sı́t’ové vrstvě.
Zpráva (message) – jejı́ entity jsou nad sı́t’ovou vrstvou (většinou v aplikačnı́ vrstvě), je to tedy
forma dat pro vyššı́ vrstvy.
Buňka (cell) je prvek o pevné velikosti (obvykle velmi malé) použı́vaný v některých sı́tı́ch
(asynchronnı́ch, jako ATM) na linkové vrstvě.
A.4
IEEE 802
A.4.1
Skupina standardů IEEE 802
Skupina standardů IEEE 802 se zabývá předevšı́m lokálnı́mi sı́těmi, ale také metropolitnı́mi sı́těmi,
funkcı́ podvrstvy LLC v modelu ISO/OSI, funkcemi fyzické vrstvy a dalšı́mi souvisejı́cı́mi řešenı́mi.
V tabulce A.1 najdeme přehled standardů IEEE 802.3 se stručným komentářem.
Z tabulky lze vypozorovat tyto typy lokálnı́ch sı́tı́:
• Ethernet (IEEE 802.3) použı́vajı́cı́ náhodný (nedeterministický) přı́stup CSMA/CD,
• Token Bus (IEEE 802.4) použı́vajı́cı́ deterministický přı́stup předávánı́ tokenu, už se moc
nepoužı́vá,
• Token Ring (IEEE 802.5) s deterministickým přı́stupem předávánı́ tokenu po dvojitém kruhu,
P
A.4
IEEE 802
228
802.1
802.2
802.3
802.4
802.5
802.6
802.7
802.8
802.9
802.10
802.11
802.12
802.14
802.15
802.16
802.17
802.18
802.19
802.20
802.21
802.22
Higher Layer LAN Protocols Working Group
Logical Link Control Working Group
Ethernet Working Group
Token Bus Working Group
Token Ring Working Group
Metropolitan Area Network Working Group (rozpuštěná)
Broadband TAG (rozpuštěná)
Fiber Optic TAG (rozpuštěná)
Isochronous LAN Working Group (integr. data+hlas)
Security Working Group
Wireless LAN Working Group
Demand Priority Working Group (VG-AnyLAN)
Cable Modem Working Group (rozpuštěná)
Wireless Personal Area Network (WPAN) Working Group
Broadband Wireless Access Working Group
Resilient Packet Ring Working Group
Radio Regulatory TAG
Coexistence TAG
Mobile Broadband Wireless Access
Media Independent Handoff Working Group
Wireless Regional Area Networks
Tabulka A.1: Přehled IEEE 802
• IsoEthernet (izochronnı́ Ethernet, IEEE 802.9) použı́vajı́cı́ náhodný přı́stup CSMA/CD s prioritami pro různé typy signálu, neujal se,
• WLAN (IEEE 802.11) s náhodným přı́stupem CSMA/CA na rádiovém signálu,
• 100VG-AnyLAN (IEEE 802.12) varianta fast Ethernetu s deterministickým přı́stupem DPAM,
neujala se.
Existujı́ i dalšı́ typy sı́tı́, ale nejsou často normalizovány sdruženı́m IEEE.
Dalšı́ informace:
• Seznam aktivnı́ch standardů IEEE 802:
http://standards.ieee.org/getieee802/portfolio.html
• Seznam s podrobnostmi IEEE standardů pro LAN a MAN:
http://ieeexplore.ieee.org/ISOL/package.jsp?punumber=9&type=P
• IEEE standardy obecně pro informačnı́ technologie:
http://ieeexplore.ieee.org/ISOL/parent.jsp?punumber=4&type=p
• Přehled IEEE 802.3 (Ethernet, CSMA/CD):
http://www.ieee802.org/3/
A.4
A.4.2
IEEE 802
229
IEEE 802.1
IEEE 802.1 obsahuje standardy/doplňky společné pro všechny lokálnı́ a metropolitnı́ sı́tě definované v ostatnı́ch skupinách IEEE 802, normy pro propojovánı́ sı́tı́ a oblast zabezpečenı́.
Standard 802.1D obsahuje podporu prioritnı́ho zacházenı́ s rámci – rozdělenı́ přı́chozı́ch rámců
do několika front s rozdı́lnými prioritami, na čemž stojı́ napřı́klad QoS (Quality of Service).
Standard 802.1Q obsahuje podporu VLAN (virtuálnı́ch sı́tı́), rámce MAC podvrstvy mohou
obsahovat dodatečná informačnı́ pole řı́dicı́ doručovánı́ v rámci VLAN.
Velmi důležitý je standard 802.1X o bezpečnosti komunikace v sı́ti. Umožňuje autentizaci uživatelů, distribuci bezpečnostnı́ch klı́čů, integritu zpráv, apod. To vše má význam předevšı́m u bezdrátových připojenı́. Žadatel je uzel (obvykle bezdrátová stanice), který žádá o přı́stup do sı́tě,
autentizátor (přı́stupový bod) zprostředkovává autentizačnı́ informaci, autentizačnı́ server (napřı́klad RADIUS) autentizaci provádı́. V této komunikaci sloužı́ 802.1X jako zprostředkovatel pro
autentizačnı́ protokol vyššı́ vrstvy (EAP – Extensible Authentication Protocol), pracuje na sı́t’ové
vrstvě.
Do IEEE 802.1 patřı́ vı́ce standardů, dalšı́ se ponejvı́ce týkajı́ VLAN, fungovánı́ MAC podvrstvy
a autentizace.
P
Přı́loha
B
Práce s adresami a sı́těmi ve Windows
V této přı́loze jsou popsány a demonstrovány přı́kazy, které se použı́vajı́ ve Windows při práci se sı́těmi,
Linuxu se věnujeme v dalšı́ přı́loze. Můžeme je zatı́m brát jako inspiraci pro procvičovánı́ a taky jako předehru
k zatı́m neexistujı́cı́m cvičenı́m z tohoto předmětu.
B.1
Problémy při použı́vánı́ přı́kazů ve Windows
V serverových Windows podobně jako v desktopových variantách je možné pro téměř vše použı́t
nástroje grafického rozhranı́. Velmi často je však praktičtějšı́ použı́t Přı́kazový řádek – přı́kazy
někdy umějı́ vı́ce než nástroje grafického režimu, lze je snadněji použı́vat pro vzdálenou správu
a hlavně přı́kazy je možné skriptovat a tedy automatizovat zpracovánı́ některých úloh.
Ve Windows je s přı́kazy pro Přı́kazový řádek podobný problém jako v grafickém rozhranı́:
různé verze Windows se v tomto směru hodně lišı́ a některé přı́kazy pracujı́ v různých verzı́ch
odlišně. Komplikace se projevujı́ předevšı́m v heterogennı́ch sı́tı́ch, ve kterých jsou uzly s různými
verzemi a přı́padně variantami (edicemi) Windows (když pı́šeme skript, musı́me dbát na to, aby byl
použitelný na všech uzlech, kde ho potřebujeme spouštět). S problémy se setkáme napřı́klad tehdy,
když chceme v rámci skupiny propojit dva počı́tače, jeden s Windows XP a druhý s Windows 7
(mladšı́ vidı́ staršı́ho, ale ne naopak).
Jistou komplikacı́ je také změna funkčnosti RunAs mechanismu – od verze Vista sice pořád
existuje přı́kaz runas pro spuštěnı́ procesu s odlišnými přı́stupovými oprávněnı́mi (pod jiným
uživatelem), ale je problematický. Pokud chceme ve Windows od Visty výše spustit přı́kaz s jinými
(typicky administrátorskými) oprávněnı́mi než pod kterými právě pracujeme, zvolı́me v kontextovém menu ikony programu Přı́kazového řádku volbu „Spustit jako správce“ a tedy spustı́me
s vyššı́mi oprávněnı́mi už program cmd.exe. Svým způsobem to může být bezpečnostnı́ problém,
protože někteřı́ uživatelé zřejmě budou na Přı́kazovém řádku s vyššı́mi oprávněnı́mi pracovat
i tehdy, když to nenı́ nutné.
Pokud chceme některé úlohy provádět vzdáleně, také můžeme narazit na přı́stupová oprávněnı́.
Obvykle pomůže použı́vat doménový správcovský účet, který lze využı́t na všech zařı́zenı́ch
v doméně.
230
B.3
PRÁCE S ADRESAMI A SÍŤOVÝMI KARTAMI
B.2
231
Soubory souvisejı́cı́ se sı́těmi
Se sı́tı́ souvisı́ využı́vánı́ některých (textových) souborů – naštěstı́ nenı́ vše v registru, některé z nı́že
uvedených souborů budou zmı́něny u popisovaných přı́kazů.
Předevšı́m z důvodu kompatibility se sı́t’ovými protokoly a ne-windows sı́t’ovými klienty existujı́ ve složce ...\system32\drivers\etc tyto soubory:
$
• networks – obsahuje doménové a IP adresy lokálnı́ch sı́tı́,
• hosts – urychluje mapovánı́ IP adres na známé doménové adresy (hostitele, anglicky hosts),
jakýsi statický zástup DNS služeb,
• services – informace o známých sı́t’ových službách,
• protocol – informace o známých sı́t’ových protokolech,
• lmhosts.sam – tento soubor se dřı́ve použı́val pro stejné účely jako hosts (ve Windows
překlad IP adres na NetBIOS názvy), v současné době se už prakticky nevyužı́vá
Ve Windows 7 tyto soubory pravděpodobně nenajdeme vůbec (nebo je vše zakomentováno), v ostatnı́ch 64bitových Windows jde o složku ...\sysWOW64\drivers\etc.
Vzpomeňte si, že v unixových systémech jsou v adresáři /etc nejrůznějšı́ konfiguračnı́ soubory
včetně sı́t’ových, zde si Microsoft bral inspiraci.
Úkoly
Prohlédněte si obsah souborů networks, hosts, services a protocol zmı́něných v této sekci.
B.3
Práce s adresami a sı́t’ovými kartami
B.3.1
Základnı́ práce s IP adresami – ipconfig
Pro zobrazenı́ informacı́ o adresách můžeme použı́t přı́kaz ipconfig.
(nebo ipconfig -?) zobrazı́ seznam parametrů
ipconfig /all
vypı́še podrobné informace (IP a MAC adresu, adresu brány, masku podsı́tě)
ipconfig /release název_karty
uvolněnı́ IP adresy přidělené zadané sı́t’ové kartě (když
neuvedeme název karty, jsou uvolněny IP adresy všech karet, je možné také použı́t hvězdičkovou konvenci)
ipconfig /renew název_karty
obnovenı́ přidělenı́ IP adresy pro zadanou sı́t’ovou kartu (když
nenı́ název karty uveden, provede se pro všechny dostupné karty)
ipconfig /displaydns
zobrazı́ záznamy adres přidělených v systému DNS (informace k přı́slušným DNS jménům včetně hodnoty TTL1 ), a to jak ve směru doménové jméno → IP adresa,
tak i ve směru opačném (reverznı́ adresy, ty jsou v záhlavı́ označeny řetězcem „in-addr.arpa“);
vždy jsou zobrazeny alespoň dva záznamy (localhost a jeho reverznı́ adresa)
ipconfig /?
1
TTL (Time to Live) je čı́tač uložený v hlavičce IP datagramu, který se při průchodu kteréhokoliv směrovače na cestě
snižuje (nejméně) o 1. Hlavnı́m účelem je omezenı́ počtu „bloudı́cı́ch“ datagramů. Pokud hodnota TTL vypršı́ (klesne
na 0), směrovač, který vypršenı́ zjistı́, už dál datagram neposı́lá, ale odešle zdroji datagramu informaci o překročenı́
povoleného TTL.
$
B.3
PRÁCE S ADRESAMI A SÍŤOVÝMI KARTAMI
232
vymaže DNS cache (tj. dotazy na doménové adresy, které takto z cache
smažeme, se musejı́ provádět znovu), použijeme, pokud DNS překlad funguje nekorektně
(máme v cache chybné či neaktuálnı́ záznamy)
ipconfig /flushdns
Přı́klad
Výstup přı́kazu může vypadat napřı́klad takto (záležı́ na verzi Windows, nejdřı́v ve Windows XP):
C:\Windows> ipconfig /all
Konfigurace protokolu IP systému Windows
Název hostitele . . .
Primárnı́ přı́pona DNS.
Typ uzlu . . . . . .
Povoleno směrovánı́ IP
WINS Proxy povoleno .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
PCPRACE
M
neznámý
Ne
Ne
Adaptér sı́tě Ethernet Připojenı́ k mı́stnı́ sı́ti:
Přı́pona DNS podle připojenı́
Popis . . . . . . . . . . .
Fyzická Adresa. . . . . . .
Protokol DHCP povolen . . .
Adresa IP . . . . . . . . .
Maska podsı́tě . . . . . . .
Výchozı́ brána . . . . . . .
Servery DNS . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
:
:
:
:
:
:
:
:
Broadcom NetXtreme Gigabit Ethernet
00-0F-FE-12-34-56
Ne
193.84.195.15
255.255.255.128
193.84.195.1
193.84.192.10
Výstup téhož přı́kazu ve Windows 7 je hodně dlouhý, vyjmeme pouze část výstupu odpovı́dajı́cı́
jedné ethernetové kartě:
...
Adaptér sı́tě Ethernet Připojenı́ k mı́stnı́ sı́ti:
Přı́pona DNS podle připojenı́ . . . : fpf.slu.cz
Popis . . . . . . . . . . . . . . : Atheros AR8131 PCI-E Gigabit Ethernet
Controller (NDIS 6.20)
Fyzická Adresa. . . . . . . . . . : E0-CB-4E-45-67-89
Protokol DHCP povolen . . . . . . : Ano
Automatická konfigurace povolena : Ano
Mı́stnı́ IPv6 adresa v rámci propojenı́ . . . : fe80::ec8b:a3a6:68bc:9b2f%11
(Preferované)
Adresa IPv4 . . . . . . . . . . . : 193.84.194.100(Preferované)
Maska podsı́tě . . . . . . . . . . : 255.255.255.128
Zapůjčeno . . . . . . . . . . . . : 9. června 2011 15:25:14
Zápůjčka vypršı́ . . . . . . . . . : 9. června 2011 21:25:14
Výchozı́ brána . . . . . . . . . . : 193.84.194.129
Server DHCP . . . . . . . . . . . : 193.84.192.10
IAID DHCPv6 . . . . . . . . . . : 248613215
DUID klienta DHCPv6. . . . . . . : 00-01-00-01-12-F4-7B-66-E0-CB-4E-45-67-89
Servery DNS . . . . . . . . . . . : 193.84.192.10
Rozhranı́ NetBios nad protokolem TCP/IP. . . . . . . . : Povoleno
...
M
B.3
PRÁCE S ADRESAMI A SÍŤOVÝMI KARTAMI
233
Řetězec DUID (DHCP Unique Identifier) jednoznačně identifikuje klienta serveru DHCPv6 a naopak
(je jedinečné pro danou konverzaci s DHCP serverem při stanovenı́ konfiguračnı́ch parametrů.
Všimněte si vazby na MAC adresu.
Čı́slo IAID (Identity Association Identifier) jednoznačně identifikuje sadu adres přidělených
DHCP klientovi. Klient může mı́t k danému sı́t’ovému rozhranı́ vı́ce sad IPv6 adres (plus dalšı́
potřebné adresy, napřı́klad musı́ znát adresu DNS serveru), každá taková sada musı́ mı́t jiné IAID.
Přı́klad
Pokud se nedařı́ navázat sı́t’ové spojenı́ nebo spojenı́ nefunguje korektně (napřı́klad tehdy, když
naše sı́t’ová karta omylem zı́skala IP adresu, která je již přidělena jinému zařı́zenı́, a nebo nebyly korektně zı́skány adresy DNS serverů), může pomoci znovuzı́skánı́ IP adresy a souvisejı́cı́ch
informacı́ (adresa brány, adresy DNS serverů). Použijeme postupně tyto přı́kazy:
pročistı́me DNS cache, tı́m se zbavı́me staršı́ch potenciálně chybných
záznamů (tento krok nemusı́ být nutný)
ipconfig /flushdns
uvolněnı́ IP adresy přidělené všem sı́t’ovým kartám, ale často nebývá nutné
ipconfig /release
ipconfig /renew
ipconfig /all
obnovenı́ přidělenı́ IP adresy všech sı́t’ových karet
ověřı́me si, zda je vše vpořádku
Tento postup samozřejmě nebudeme použı́vat, pokud máme pevnou (statickou) IP adresu. Kdybychom se o to pokusili, obdržı́me chybové hlášenı́ sdělujı́cı́, že daný adaptér (tj. sı́t’ová karta) nenı́
ve službě DHCP povolen (proto nemůže žádat na DHCP serveru jinou adresu).
Když budeme chtı́t takto obnovit adresu pro jedinou konkrétnı́ kartu, zadáme v přı́kazech
název (můžeme použı́vat i hvězdičkovou konvenci pro zkrácenı́ názvu), napřı́klad
ipconfig /release Připojenı́*1
(pokud máme sı́t’ovou kartu s názvem „Připojenı́ k mı́stnı́ sı́ti 1“).
B.3.2
Překlad adres – arp a nslookup
ARP je protokol převádějı́cı́ IP adresy na fyzické (MAC) adresy. Fyzická adresa je v sı́ti zjišt’ována
odesı́lánı́m tzv. ARP paketů s dotazy. Aby nebylo nutné opakovaně posı́lat tyto pakety, udržuje
každé sı́t’ové zařı́zenı́ (tj. také zvlášt’každá sı́t’ová karta) mezipamět’, do které ukládá dosud zjištěné
dvojice IP a fyzických adres (ARP tabulky). ARP tabulku je možné prohlı́žet a přidávat i mazat
záznamy. Ukážeme si využitı́ přı́kazu arp, který sloužı́ právě k práci s ARP tabulkou.
zobrazı́ ARP tabulku, také vidı́me, které záznamy jsou dynamické (automaticky vytvořené z komunikace) a které statické (ručně vložené)
arp -a
arp -a -n 10.0.128.10
zobrazı́ ARP tabulku pouze pro sı́t’ovou kartu, která má přidělenu
zadanou IP adresu
přidá se do ARP tabulky statický záznam se
vztahem zadané IP adresy a MAC (fyzické) adresy, MAC adresa se zadává v hexadecimálnı́ch
čı́slech s pomlčkami
arp -s 123.123.123.123 00-12-34-56-78-9A
$
B.3
PRÁCE S ADRESAMI A SÍŤOVÝMI KARTAMI
arp -d 123.123.123.123
arp -d *
234
odstranı́ z ARP tabulky záznam pro zadanou IP adresu
odstranı́ z ARP tabulky všechny záznamy
Lze přidat parametr s určenı́m IP adresy sı́t’ové karty, pro kterou daná ARP tabulka platı́ (každá
karta má svou tabulku), to má smysl jen v přı́padě, kdy je v provozu vı́c než jedna sı́t’ová karta.
Přı́klad
ARP tabulka může vypadat takto (na Windows 7):
C:\Windows> arp -a
Rozhranı́: 193.84.194.100 --- 0xb
internetová adresa
fyzická adresa
193.84.194.129
00-0d-66-22-11-00
193.84.194.162
00-1e-4f-33-22-11
193.84.194.185
00-1e-4f-dd-bb-00
193.84.194.186
00-26-2d-ff-ee-11
193.84.194.188
00-1f-d0-66-77-88
193.84.194.212
00-1e-4f-aa-11-bb
193.84.194.220
00-1e-4f-dd-cc-bb
193.84.194.227
00-24-be-77-66-55
193.84.194.229
00-1e-4f-ee-dd-44
193.84.194.255
ff-ff-ff-ff-ff-ff
224.0.0.2
01-00-5e-00-00-02
224.0.0.22
01-00-5e-00-00-16
224.0.0.252
01-00-5e-00-00-fc
239.255.255.250
01-00-5e-7f-ff-fa
255.255.255.255
ff-ff-ff-ff-ff-ff
...
typ
dynamická
dynamická
dynamická
dynamická
dynamická
dynamická
dynamická
dynamická
dynamická
statická
statická
statická
statická
statická
statická
M
Ve Windows nižšı́ch verzı́ (předevšı́m od XP nı́že) je ARP tabulka výrazně kratšı́. V tabulce vidı́me
dynamické i statické záznamy, u všech je IP a MAC adresa. Všimněte si skupinových a všesměrových IP a MAC adres (samozřejmě platı́, že ke skupinové IP adrese bude patřit skupinová MAC
adresa a naopak).
Zatı́mco protokol ARP sloužı́ k překladu IP adresy na MAC adresu, protokol DNS sloužı́ k překladu
doménové adresy na IP adresu. Pro základnı́ přı́stup k tomuto překladu lze i na klientských
stanicı́ch využı́t přı́kaz nslookup. Přı́kaz lze využı́vat běžným způsobem i interaktivně.
vypı́še se nejdřı́v adresa DNS serveru, který poskytl odpověd’, a pak
samotná odpověd’ (IP adresy a aliasy pro zadaný doménový název)
nslookup www.seznam.cz
nslookup 77.76.75.3
nslookup
reverznı́ překlad, takto zjistı́me doménovou adresu k této IP adrese
přechod do interaktivnı́ho režimu, tento režim ukončı́me přı́kazem exit
Měli bychom si předevšı́m uvědomit, že plnou nápovědu k tomuto přı́kazu zı́skáme pouze v interaktivnı́m režimu: tedy výše uvedeným přı́kazem přejdeme do interaktivnı́ho režimu a pak zadáme
přı́kaz ? nebo help.
Přı́klad
Ukážeme si práci v interaktivnı́m režimu:
nslookup
spustı́me program nslookup, prompt se změnı́ na symbol >
$
B.3
PRÁCE S ADRESAMI A SÍŤOVÝMI KARTAMI
235
zobrazı́me nápovědu, je značně podrobnějšı́ než nslookup /? vně interaktivnı́ho režimu; také
lze použı́t vnitřnı́ přı́kaz help
www.google.com
napı́šeme doménovou adresu, zı́skáme IP adresu, výstup (v různých verzı́ch
Windows se ve výstupech setkáme s vı́ce či méně kostrbatou češtinou):
?
Server: decsu.fpf.slu.cz
Address: 193.84.192.10
M
Neautorizovana odpoved:
Název:
www.l.google.com
Addresses: 209.85.149.147
209.85.149.99
209.85.149.103
209.85.149.104
209.85.149.105
209.85.149.106
Aliases: www.google.com
tato forma přı́kazu set nic nenastavuje, ale informuje nás o momentálnı́m nastavenı́
pro poslednı́ zadanou adresu (v našem přı́padě pro www.google.com; pokud jsme předtı́m
nic nepřekládali, pak obecně platná nastavenı́), výstup:
set all
Vychozı́ server:
decsu.fpf.slu.cz
Address: 193.84.192.10
Hostitel =
www.l.google.com
Addresses: 209.85.149.147
209.85.149.99
209.85.149.103
209.85.149.104
209.85.149.105
209.85.149.106
Aliases: www.google.com
Nastaveni moznosti:
nodebug
defname
search
recurse
nod2
novc
noignoretc
port=53
typ=A+AAAA
trida=IN
doba vyprseni casoveho limitu=2
obnoveni=1
koren=A.ROOT-SERVERS.NET.
domena=fpf.slu.cz
MSxfr
verze IXFRversion=1
srchlist=fpf.slu.cz/slu.cz
Takže se napřı́klad dozvı́me, že se použil rekurzivnı́ dotaz, jedná se o záznam adresy pro
IPv4 i IPv6 (typ A+AAAA), atd.
M
B.3
PRÁCE S ADRESAMI A SÍŤOVÝMI KARTAMI
236
od této chvı́le bude požadován iterativnı́ (nerekurzivnı́) typ dotazů, zpět nastavı́me přı́kazem set recurse
set norecurse
ls fpf.slu.cz
chceme vypsat adresy (počı́tače) v zadané doméně, výpis je celkem dlouhý
ls -t ns fpf.slu.cz
oproti předchozı́mu se vypı́šou pouze doménové servery (typ je NS,
name server)
ls -t aaaa slu.cz
vypı́šou se zařı́zenı́ s IPv6 adresou (tj. záznamy typu AAAA) v zadané
doméně
B.3.3
Směrovánı́ – route
Pokud posı́láme data na určitou IP adresu, pakety obvykle (ne vždy) procházejı́ přes bránu do
Internetu či jiné sı́tě. Proto každý uzel sı́tě včetně klientských počı́tačů zná adresu brány a přı́padně dalšı́ směrovacı́ informace (tj. kterým směrem poslat data do určité (pod)sı́tě), vede si svou
směrovacı́ tabulku. Do tabulky lze vkládat záznamy ručně (statické záznamy) nebo dynamicky
(provádějı́ směrovacı́ protokoly). Ve Windows se s touto tabulkou pracuje přı́kazem route.
route
(nebo s jakýmkoliv nesprávným parametrem) zobrazı́ nápovědu k přı́kazu
$
vypı́še směrovacı́ tabulku, v nejnovějšı́ch verzı́ch Windows vlastně dvě tabulky –
zvlášt’pro IPv4 a IPv6; na začátku výpisu také máme seznam všech sı́t’ových rozhranı́ včetně
virtuálnı́ch, tento seznam může být také užitečný
route print
vypı́še pouze ty cı́le ze směrovacı́ tabulky, které odpovı́dajı́ zadanému
výrazu (můžeme použı́vat hvězdičkovou konvenci, také symbol ? pro jeden znak)
route print 193.*
route add 193.84.197.0 mask 255.255.255.128 193.84.195.8 metric 4
do tabulky přidá statický záznam určujı́cı́, že k sı́ti s IP adresou 193.84.195.8 a maskou 255.255.255.128
se dá dostat přes bránu s IP adresou 193.84.195.63 a metrika (cena trasy) je 8
totéž jako
předchozı́, ale záznam zůstane v tabulce i po restartu systému (bez přepı́nače -p by byl
záznam platný jen do konce činnosti systému)
route -p add 193.84.197.0 mask 255.255.255.128 193.84.195.8 metric 4
route change 193.84.197.0 mask 255.255.255.128 193.84.195.9 metric 3 if 2 změna
existujı́cı́ položky tabulky (změna platı́ i po restartu), změnili jsme adresu brány, metriku a navı́c jsme nastavili směrovánı́ na sı́t’ové rozhranı́ (kartu) čı́slo 2, k danému cı́li zadáváme vždy
jen ty položky, které chceme změnit
route del 193.84.197.0
odstranı́me záznam z tabulky (lze použı́t i hvězdičkovou konvenci)
Záznamy ve směrovacı́ tabulce lze tı́mto přı́kazem také mazat a měnit. Když máme vı́ce sı́t’ových
karet, lze v přı́kazu pro přidánı́ do tabulky použı́t i parametr určujı́cı́ sı́t’ové rozhranı́.
Přı́klad
Přı́kaz route print ve Windows XP vypı́še tento výstup:
===========================================================================
Seznam rozhranı́
M
B.3
PRÁCE S ADRESAMI A SÍŤOVÝMI KARTAMI
237
0x1 ........................... MS TCP Loopback interface
0x2 ...00 0f fe 12 34 56 ...... Broadcom NetXtreme Gigabit Ethernet - Packet
Scheduler Miniport
===========================================================================
===========================================================================
Aktivnı́ směrovánı́:
Cı́l v˜sı́ti
Sı́t’ová maska
Brána
Rozhranı́ Metrika
0.0.0.0
0.0.0.0
193.84.195.1
193.84.195.15
10
127.0.0.0
255.0.0.0
127.0.0.1
127.0.0.1
1
193.84.195.0 255.255.255.128
193.84.195.15
193.84.195.15
10
193.84.195.15 255.255.255.255
127.0.0.1
127.0.0.1
10
193.84.195.255 255.255.255.255
193.84.195.15
193.84.195.15
10
224.0.0.0
240.0.0.0
193.84.195.15
193.84.195.15
10
255.255.255.255 255.255.255.255
193.84.195.15
193.84.195.15
1
Výchozı́ brána:
193.84.195.1
===========================================================================
Trvalé trasy:
Žádné
V seznamu sı́t’ových rozhranı́ jsou pouze dvě, jedno je loopback (mı́stnı́ smyčka), druhé je ethernetová sı́t’ová karta. Ve vyššı́ch verzı́ch bychom zde viděli vı́ce záznamů (reálné sı́t’ové karty
ethernetové, Wi-fi, Bluetooth, ale i virtuálnı́ zařı́zenı́), a také virtuálnı́ počı́tače si instalujı́ vlastnı́
virtuálnı́ sı́t’ové karty. Napřı́klad pokud použı́váme virtuálnı́ počı́tač od VMWare, najdeme v seznamu rozhranı́ podobné záznamy:
20...00 50 56 c0 00 01 ......VMware Virtual Ethernet Adapter for VMnet1
21...00 50 56 c0 00 08 ......VMware Virtual Ethernet Adapter for VMnet8
Výpis byl pořı́zen na stroji, jehož sı́t’ová karta (jediná) má přiřazenu IP adresu 193.84.195.15, všimněte si, kde všude se tato adresa v tabulce vyskytuje (napřı́klad u mı́stnı́ch a multicast směrovánı́).
Z výpisu vidı́me, že žádné statické (trvalé) trasy nejsou definovány. Všimněte si, že poslednı́
řádek tabulky obsahuje informaci o výchozı́ bráně – co nenı́ směrováno podle výše uvedených
pravidel, to odcházı́ na zadanou výchozı́ bránu.
Pokud zadáme sı́t’ové zařı́zenı́ či název sı́tě symbolickým názvem, přı́kaz tento název musı́ přeložit
na IP adresu. K tomu využije obsah souboru
• ...\windows\system32\drivers\etc\networks, pokud jde o název cı́le směrovánı́ (obvykle to bývá sı́t’či podsı́t’),
• ...\windows\system32\drivers\etc\hosts, pokud jde o bránu (brána je konkrétnı́ uzel
v sı́ti, tedy hostitel protokolu, anglicky host).
Do těchto souborů můžeme přidávat vlastnı́ symbolické názvy (je to celkem jednoduché, soubory
jsou okomentovány). V souboru hosts je vždy nejméně jeden název uzlu, a to localhost.
Úkoly
1. Zjistěte svou IP adresu, masku, adresu brány, adresu DNS serveru.
2. Máte statickou IP adresu nebo ji zı́skáváte dynamicky od DHCP serveru? Kde to zjistı́te?
Pokud máte dynamickou adresu, uvolněte ji (deaktivujte sı́t’ovou kartu) a zı́skejte novou.
M
B.3
PRÁCE S ADRESAMI A SÍŤOVÝMI KARTAMI
238
3. Zobrazte ARP tabulku.
4. Zjistěte IP adresu serveru extrahardware.cz.
5. Zjistěte adresu svého DNS serveru, zda při komunikaci s DNS serverem použı́váte rekurzivnı́
nebo iterativnı́ dotazy, na kterém portu komunikujete, v jaké jste doméně. Vypište seznam
uzlů ve vašı́ doméně.
6. Vypište směrovacı́ tabulku na vašem počı́tači.
B.3.4
Malá sı́t’a skupina (workgroup)
Na systémech s Windows se setkáváme také se zkratkou NBT (nebo NetBT, NetBIOS over TCP/IP).
Samotný NetBIOS funguje defacto jako jmenná, spojovacı́ a komunikačnı́ služba v malých sı́tı́ch
s Windows (skupiny počı́tačů v sı́ti typu peer-to-peer). Umožňuje ve skupinách sdı́let různé prostředky (složky, tiskárny). Názvy počı́tačů, které zadáváme v grafickém rozhranı́ Windows, jsou
vlastně názvy podle protokolu NetBIOS. Aby bylo možné názvy NetBIOSu použı́vat i mimo malé
sı́tě, pracuje dnes NetBIOS nad protokoly TCP/IP ve formě NBT. Pro práci s názvy v NBT můžeme
využı́t přı́kazy hostname a nbtstat:
zobrazı́ jméno našeho počı́tače v NBT
hostname
nbtstat
$
zobrazı́ nápovědu přı́kazu nbtstat
zjistı́me všechny názvy podle protokolu NBT, které souvisejı́ s tı́mto zařı́zenı́m (tj.
obvykle jen název našeho počı́tače, pokud počı́tač patřı́ do skupiny, tak i název této skupiny),
jestliže máme vı́ce sı́t’ových karet (tj. vı́ce rozhranı́), pak se zobrazı́ zvlášt’tabulky pro všechna
aktivnı́ rozhranı́ (která majı́ přidělenu IP adresu), i když u všech najdeme stejný NBT název
nbtstat -n
nbtstat -c
vypı́še se seznam ostatnı́ch počı́tačů ve skupině (NetBIOS názvy a IP adresy)
nbtstat -a počı́tač
totéž, ale pro jiný (zadaný) počı́tač patřı́cı́ do našı́ skupiny, zadáváme
NetBIOS jméno
nbtstat -A IP_adresa
totéž jako předchozı́, ale počı́tač zadáváme jeho IP adresou
Také můžeme zobrazit tabulku relacı́ s daným uzlem v sı́ti (skupině).
Přı́klad
Předpokládejme, že máme dva počı́tače:
• pcnotebook s IP adresou 10.0.0.1,
• pcdesktop s IP adresou 10.0.0.3,
oba připojené ve skupině mojeskupina. Na prvnı́m z nich nejdřı́v vypı́šeme tabulku mı́stnı́ch NBT
názvů:
C:\Windows> nbtstat -n
Připojenı́ k mı́stnı́ sı́ti:
Adresa IP uzlu: [10.0.0.1] ID oboru: []
Tabulka mı́stnı́ch názvů systému NetBIOS
M
B.4
TESTOVÁNÍ A STATISTIKY
239
Název
Typ
Stav
---------------------------------------------PCNOTEBOOK
<00> UNIQUE
Registrovaný
MOJESKUPINA
<00> GROUP
Registrovaný
PCNOTEBOOK
<20> UNIQUE
Registrovaný
Ted’ na tomtéž počı́tači vypı́šeme seznam dostupných počı́tačů:
C:\Windows> nbtstat -c
Připojenı́ k mı́stnı́ sı́ti:
Adresa IP uzlu: [10.0.0.1] ID oboru: []
M
Název vzdálené paměti NetBIOS Tabulka
Název
Typ
Adr. hostitele
Životnost [sek]
----------------------------------------------------------------PCDESKTOP
<20> UNIQUE
10.0.0.3
92
Pokud dostaneme jen chybovou hlášku „V mezipaměti nejsou žádné názvy“, důvodem může být
to, že počı́tače nejsou ve stejné skupině (tj. nevidı́ se), ale také se tento problém může/nemusı́
objevit, pokud na těchto počı́tačı́ch máme různé verze Windows.
Můžeme také vypsat NBT tabulku druhého počı́tače (jsme pořád na tomtéž počı́tači):
C:\Windows> nbtstat -a pcdesktop
Připojenı́ k mı́stnı́ sı́ti:
Adresa IP uzlu: [10.0.0.1] ID oboru: []
Tabulka názvů vzdálených počı́tačů NetBIOS
Název
Typ
Stav
---------------------------------------------PCDESKTOP
<00> UNIQUE
Registrovaný
MOJESKUPINA
<00> GROUP
Registrovaný
PCDESKTOP
<20> UNIQUE
Registrovaný
Adresa MAC = 00-1D-0F-12-34-56
Jiný přepı́nač použijeme, pokud přı́kaz zadáme s využitı́m IP adresy:
nbtstat -A 10.0.0.3
Výstup by byl tentýž jako v předchozı́m přı́padě. Přı́kaz bohužel nepřijı́má regulárnı́ výrazy ani
hvězdičkovou konvenci, tedy přı́padnou automatizaci (napřı́klad vypsánı́ údajů pro vı́ce různých
adres) bychom mohli řešit napřı́klad přı́kazem for (viz skripta pro Windows z předmětu Operačnı́
systémy).
Úkoly
Pokud jste v LAN s vı́ce počı́tači, které jsou ve stejné skupině, vyzkoušejte použitı́ přı́kazu nbtstat
podle ukázek v přı́kladech. Pokud ne, vyzkoušejte alespoň výpis NBT názvů na vlastnı́m počı́tači.
M
B.4
TESTOVÁNÍ A STATISTIKY
B.4
Testovánı́ a statistiky
B.4.1
Testovánı́ cesty a průchodnosti
240
To, zda je dostupná doménová nebo IP adresa (resp. přı́slušné zařı́zenı́ na sı́ti), zjistı́me přı́kazem
ping. Tento přı́kaz odesı́lá k danému zařı́zenı́ ICMP pakety (zprávy ICMP Echo Request) a podle
zaslaných odpovědı́ určuje, zda je počı́tač dostupný a jaká je odezva připojenı́ (pokud má vzdálený
počı́tač firewall nakonfigurovaný tak, aby požadavky ping byly ignorovány, může se počı́tač jevit
jako nedostupný)
$
zjistı́, zda je zadaný server dostupný (je dostupný prakticky vždy, tedy
pokud se zobrazı́ hláška, že tomu tak nenı́, zřejmě nejsme připojeni k sı́ti nebo je někde na
cestě porucha)
ping www.google.com
tento parametr omezı́ (nebo u většı́ho čı́sla navýšı́) počet odesı́laných testovacı́ch paketů, zde na 2; výchozı́ hodnota je 4 pakety
ping -n 2 www.google.com
počet odesı́laných paketů nenı́ stanoven, posı́lajı́ se opakovaně až
do přerušenı́ klávesovou zkratkou Ctrl+C
ping -t www.google.com
Přı́klad
Přı́kaz ping můžeme použı́t i pro otestovánı́ funkčnosti vlastnı́ sı́t’ové karty:
ping loopback
nebo
ping 127.0.0.1
Přı́klad
Jestliže se sı́t’ové spojenı́ podle parametrů zdá v pořádku, ale ve skutečnosti nefunguje, ověřı́me,
zda je funkčnı́ DNS překlad adres (doménových adres na IP adresy):
zřejmě skončı́ chybovým hlášenı́m, když spojenı́ nefunguje (můžeme
použı́t adresu jakéhokoliv serveru na Internetu, u kterého máme jistotu, že odpovı́dá na
žádosti přı́kazu ping)
ping www.google.com
provedeme totéž, ale použijeme IP adresu (zde se jedná o IP adresu
serveru z předchozı́ho přı́kazu)
ping 74.125.79.104
Pokud byl druhý přı́kaz úspěšný, pravděpodobně máme adresu nefunkčnı́ho DNS serveru (nebo
nemáme žádnou). Měli bychom tedy reagovat bud’ zjištěnı́m správné adresy (napřı́klad u svého
poskytovatele připojenı́) nebo použitı́m adresy veřejného DNS serveru.
Takových serverů již existuje dostatek, napřı́klad Google má veřejné DNS servery na adresách
8.8.8.8 a 8.8.4.4, přı́padně můžeme použı́t DNS servery sdruženı́ CZ.NIC 217.31.204.130
nebo 217.31.204.131. Ve Windows se adresy DNS serverů nastavujı́ v grafickém režimu, v Sı́t’ových připojenı́ch (vlastnostech protokolu TCP/IP). Návod najdeme napřı́klad na adrese
http://www.nic.cz/page/847/jak-nastavit-verejne-dns-servery-cz.nic/.
L
B.4
TESTOVÁNÍ A STATISTIKY
241
Program tracert použı́váme, když chceme znát cestu, po které procházejı́ naše datagramy (tj.
adresy směrovačů na cestě). Ve Windows se použı́vá metoda ICMP paketů posı́laných v IP datagramech s postupně se zvyšujı́cı́ hodnotou TTL (podrobnosti u protokolů ICMP, IPv4 a IPv6
v prvnı́ kapitole).
tracert -?
$
vypı́še nápovědu (pozor, unixová syntaxe, přepı́nače pı́šeme s pomlčkou)
chceme trasu k zadanému serveru, postupně (celkem pomalu) se
vypı́šou všechny směrovače na cestě včetně odezvy v ms počı́tané od předchozı́ho uzlu
tracert www.google.com
Můžeme zadat také IP adresu. Metoda ICMP paketů je poměrně pomalá. Navı́c některé směrovače
jsou z bezpečnostnı́ch důvodů nastaveny tak, aby neodpovı́daly na ICMP pakety (pak od dotyčného uzlu obdržı́me informaci o vypršenı́ časového limitu žádosti), také je obvyklé, že se takto
nedostaneme přı́mo ke konkrétnı́mu serveru, ale jen ke směrovači na okraji sı́tě, ve které je daný
server.
Program pathping sloužı́ k podobným účelům, také dokáže vypsat trasu k zadanému serveru
(jednotlivé směrovače) a navı́c pro každý tento úsek vypočı́vává statistiku stejnou jako přı́kaz ping.
Pracuje na principu zpráv ICMP Echo Request a ICMP Echo Reply stejně jako přı́kaz ping.
$
vypı́šeme nápovědu
pathping -?
pathping www.google.com
spustı́me výpis směrovačů a výpočet statistik
Zjištěnı́ uzlů na cestě může být mı́rně rychlejšı́ než u tracert, ale počı́tánı́ statistiky naopak zabere
vı́ce než 100 sekund a opět se nedostaneme moc daleko (dokonce můžeme „uváznout“ v sı́ti
poskytovatele Internetu). Pokud se nám zdá výpočet přı́liš dlouhý, program lze předčasně ukončit
klávesovou zkratkou Ctrl+C .
B.4.2
Statistiky v netstatu
Velice silný nástroj použitelný pro analýzu statistik souvisejı́cı́ch s protokoly rodiny TCP/IP je
netstat. Stejně jako jiné přı́kazy pro práci se sı́těmi vznikl podle podobně pojmenovaných nástrojů z Unixu, u přı́kazu netstat se však setkáme se zřejmě největšı́ podobnostı́. Přı́kaz nejen
zachovává unixovou syntaxi (přepı́nače se pı́šı́ za pomlčku), ale také dokonce umožňuje sdružovat jednopı́smenné přepı́nače k jedné pomlčce. Množina přepı́načů je odlišná v různých verzı́ch
Windows!
vypı́še základnı́ statistiku (nevšı́má si aplikacı́, které jen naslouchajı́, vypisuje pouze
TCP spojenı́)
netstat
netstat -a
vypı́še celou statistiku
netstat -a -o
netstat -ao
vypı́še celou statistiku, přidá sloupec s PID přı́slušného procesu
totéž (přepı́nače můžeme sdružovat do jediného řetězce)
navı́c mı́sto doménových vypisuje IP adresy, tato forma je velmi použı́vaná a je
dobré si ji zapamatovat
netstat -ano
vypı́še všechny procesy (názvy i PID), které právě komunikujı́ se
sı́tı́ (jakkoliv), výsledek je směrován do zadaného souboru
netstat -ab > seznam.log
$
B.4
TESTOVÁNÍ A STATISTIKY
242
základnı́ statistika pro Ethernet (počet odeslaných a přijatých paketů, počet chyb
apod. – týká se protokolů rodiny TCP/IP)
netstat -e
netstat -es
podrobná statistika všech protokolů z rodiny TCP/IP
podrobná statistika, přepı́nač -p s přidaným parametrem tcp určuje, že
chceme pouze statistiku protokolu TCP (můžeme použı́t parametr tcp, udp nebo ip)
netstat -sp tcp
vypisuje svůj výstup opakovaně každé dvě sekundy (můžeme zadat jakýkoliv interval a také kombinovat s jinými přepı́nači), činnost přı́kazu lze ukončit jen klávesovou
zkratkou Ctrl+C
netstat 2
netstat -r
zobrazı́ směrovacı́ tabulku, stejný výstup jako přı́kaz route print
Přı́klad
Po několika prohlédnutých stránkách v internetovém prohlı́žeči může statistika protokolu IP vypadat takto:
C:\Windows> netstat -sp ip
Statistika protokolu IPv4
Počet přijatých paketů
Přijato s chybami hlaviček
Přijato s chybami adresy
Předané datagramy
Přijato s neznámým protokolem
Zahozené přijaté pakety
Doručené přijaté pakety
Požadavky na výstup
Zahozená směrovánı́
Zahozené výstupnı́ pakety
Nesměrovatelné výstupnı́ pakety
Vyžadováno nové sestavenı́
Úspěšná nová sestavenı́
Chybná nová sestavenı́
Úspěšně fragmentované datagramy
Neúspěšně fragmentované datagramy
Vytvořené fragmenty
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
=
30736
0
3509
0
0
1078
26369
23914
0
2
0
0
0
0
0
0
0
Úkoly
1. V předchozı́m textu najděte IP adresy veřejných DNS serverů (jeden od Googlu, jeden od
CZ.NIC) a vyzkoušejte na ně přı́kaz ping. Všimněte si časových údajů ve výpisech.
2. Všimněte si rozdı́lu (včetně časového) ve výstupech přı́kazů
tracert www.google.com
pathping www.google.com
3. Zjistěte PID všech procesů, které právě komunikujı́ po sı́ti (přı́padně naslouchajı́).
4. Vypište statistiku protokolů rodiny TCP/IP.
5. Vypište podrobnou statistiku protokolu IP.
M
B.5
SLUŽBA WMI A PROGRAM WMIC
243
6. Vypiste podrobnou statistiku protokolu TCP (je pravděpodobné, že se ve výpisu objevı́ i nějaké doménové adresy), přitom nechte zobrazit i sloupec s PID komunikujı́cı́ho procesu
(přidejte přepı́nač -o, napřı́klad netstat -osp tcp). Zjistěte, kterým PID (a přı́slušným
procesům) patřı́ řádky s navázaným spojenı́m nebo čekajı́cı́ (time-wait) – může to být napřı́klad Skype, mail klient, webový prohlı́žeč, antivirový program, apod. O který proces jde
u konkrétnı́ho PID, zjistı́te napřı́klad ve Správci úloh (zobrazte si sloupec s PID), Process
Exploreru (od Sysinternals.com) nebo ve výstupu přı́kazu tasklist.
B.5
Služba WMI a program wmic
Program wmic (WMI Console) je dostupný od verze Windows XP/Server 2003. Umožňuje využı́vat rozhranı́ WMI na Přı́kazovém řádku. pracuje ve dvou režimech – klasickém (externı́m)
a interaktivnı́m. Při použitı́ v klasickém režimu zadáváme přı́kaz začı́najı́cı́ názvem programu
(wmic) následovaný parametry, do interaktivnı́ho režimu se dostaneme zadánı́m přı́kazu wmic bez
dalšı́ch parametrů (prompt se změnı́ na wmic:root\cli> a zadáváme internı́ přı́kazy).
Nápovědu zı́skáme bud’ v grafickém režimu, nebo přı́kazem wmic /?, a nebo v interaktivnı́m
režimu této konzoly přı́kazem /?. Ještě podrobnějšı́ nápovědu zobrazı́me přı́kazem /?:FULL.
Přı́kaz wmic je velmi komplexnı́. Má tuto syntaxi:
WMIC přepı́nače předmět sloveso parametry, kde
• přepı́nače nastavujı́ obecné chovánı́ přı́kazu, mohou být napřı́klad
/node:počı́tač – přı́kaz bude proveden na zadaném počı́tači (před názvem počı́tače nebu-
deme dávat opačná lomı́tka)
/user:uživatel – při vyhodnocovánı́ bude použit zadaný uživatel s jeho přı́stupovými
oprávněnı́mi (budeme dotázáni na heslo)
/output:soubor – výpis bude směrován do zadaného souboru
• předmět (také alias) určuje to, s čı́m chceme manipulovat nebo na co se dotazujeme, následuje
zkrácený seznam (všechny možnosti zjistı́me v nápovědě):
bios
bootconfig
cpu
dcomApp
desktop
diskdrive
fsdir
irq
job
memLogical
memPhysical
netuse
NIC
NICConfig
NTEvent
onBoardDevice
OS
pageFile
printer
process
registry
service
share
temperature
useraccount
• sloveso určuje požadovanou akci, která má být provedena s předmětem:
– LIST – toto sloveso lze použı́t na všechny předměty, zobrazı́ obecnou informaci o předmětu, můžeme upřesnit, jak podrobné informace chceme (full – všechny, brief – základnı́
v tabulce, writeable – které lze měnit, atd.),
– GET – zı́skánı́ podrobnějšı́ch informacı́ o všech nebo vybraných vlastnostech předmětu,
– SET – změna vlastnostı́ předmětu,
$
B.5
SLUŽBA WMI A PROGRAM WMIC
244
– ASSOC – vrátı́ instance zadaného objektu (tedy s nı́m asociované),
– CREATE, DELETE – vytvořenı́ nové instance, odstraněnı́ instance nebo třı́dy,
– CALL – spuštěnı́ metody zadané třı́dy WMI.
Přı́kaz v neinteraktivnı́m režimu použı́váme takto:
wmic bios list
vypı́še se informace o BIOSu (úplná)
wmic os list brief
wmic os list full
wmic memorychip get
stručná informace o operačnı́m systému
úplná informace o operačnı́m systému
bude zobrazena tabulka s informacemi o pamět’ových čipech
vypı́še vybrané informace o pamět’ových čipech (oproti předchozı́mu přı́kazu jen některé sloupce)
wmic memorychip get capacity,devicelocator,name,partnumber
přı́kaz zobrazı́ seznam všech
pamět’ových zařı́zenı́ (i výměnných), a to vlastnosti z výčtu oddělené čárkou
wmic diskdrive get model,size,interfacetype,mediatype
wmic /output:D:\procinfo.txt cpu get
informace o procesoru (v tabulce) budou uloženy
do zadaného souboru
wmic cpu get > D:\procinfo.txt
totéž
vypı́še seznam běžı́cı́ch služeb
(pouze ty vlastnosti, které byly specifikovány), všimněte si syntaxe podobné SQL (ostatně
pracujeme s databázı́)
wmic service where state=”running” get caption, name
wmic process call create notepad.exe
process pro vytvořenı́ procesu)
spustı́ zadaný proces (zavolá proceduru create třı́dy
wmic /node:počı́tač process call create notepad.exe
totéž, ale na jiném počı́tači (to
přı́kaz start neumı́), název počı́tače se zadává bez úvodnı́ch opačných lomı́tek
wmic os call reboot
restart systému
wmic /node:počı́tač os call shutdown
vzdálené vypnutı́ systému
wmic service ”spooler” call startservice
spustı́ zadanou službu (Zařazovánı́ tisku)
wmic /node:ucetni process where name=”explorer.exe” call terminate
zadaný proces bude ukončen, a to na uvedeném počı́tači (vypadá to, že účetnı́mu bude
ukončeno grafické prostředı́, ale tento proces se obvykle po ukončenı́ znovu spustı́, tedy jde
vlastně o restart grafického prostředı́)
wmic /node:ucetni /user:dadmin process where name=”explorer.exe” call terminate
totéž jako předchozı́, ale v přı́kazu na zadaném počı́tači vystupujeme s přı́stupovými oprávněnı́mi zadaného uživatele
Vidı́me, že můžeme použı́vat i dotazy filtrované podle vlastnostı́ (where) podobně jako v SQL. Pokud se jedná o řetězcovou hodnotu, musı́me ji uzavřı́t do uvozovek (napřı́klad name=”explorer.exe”,
ale čı́sla nebo hodnoty true/false do uvozovek neuzavı́ráme.
Přı́klad
Ukážeme si práci v interaktivnı́m módu.
B.5
SLUŽBA WMI A PROGRAM WMIC
245
spustı́me interaktivnı́ režim, prompt je wmic:root\cli>
wmic
os /?
dotážeme se, co lze použı́t na předmět os (operačnı́ systém)
os list /?
chceme upřesnit parametry pro sloveso list
os list brief
os list full
zı́skáme tabulku s několika základnı́mi informacemi
zı́skáme seznam (už ne tabulku) s dvojicemi vlastnost=hodnota
tabulka s hodnotami volného mı́sta (ve fyzické paměti, v stránkovacı́ch souborech, ve virtuálnı́ paměti)
os list free
/output:D:\procinfo.txt cpu get
do souboru se uložı́ hodně široká tabulka vlastnostı́ pro-
cesoru
/output:D:\procinfo.txt cpu list full
totéž, ale mı́sto široké tabulky máme v souboru
seznam položek vlastnost=hodnota
cpu get /?
zeptáme se, co se dá zjistit o procesoru
zı́skáme údaj o počtu logických procesorů (počet jader
nebo jeho dvojnásobek, pokud procesor podporuje hyperthreading)
cpu get NumberOfLogicalProcessors
cpu get AddressWidth,Caption,CurrentClockSpeed,DataWidth,Description,ExtClock
vypı́še se tabulka s vybranými sloupci
vypı́še se seznam běžı́cı́ch procesů, u každého je přı́kaz, kterým byl spuštěn
(všimněte si, že v seznamu je i wmiprvse.exe, který zajišt’uje vyhodnocovánı́ dotazů na
WMI)
process get
process list brief
zı́skáme tabulku procesů s některými informacemi
process where ThreadCount>8 list brief
podobný výstup, ale vypı́šou se pouze procesy,
které majı́ vı́ce než 8 vláken
service get name,state,serviceType
tabulka s názvy, stavy a typy služeb
service where desktopInteract=true get name,state
zı́skáme seznam interaktivnı́ch slu-
žeb (všimněte si, že u neběžı́cı́ch služeb je PID=0)
service where (desktopInteract=true and startMode=”auto”) get name,processid
výběrová kritéria můžeme kombinovat (jako v SQL), ale v tom přı́padě je uzavřeme do
závorky
service where desktopinteract=true get name,processid,status /every:5
takto zajistı́me, že dotaz bude automaticky opakován v intervalu 5 sekund (stisknutı́m některé
klávesy opakovánı́ přerušı́me)
quit
ukončı́me interaktivnı́ režim (funguje také přı́kaz exit)
Mechanismus WMI se hodně použı́vá právě ve skriptu, a to typicky v jazyce VBScript, JScript,
Perl nebo PowerShell (je třeba mı́t nainstalován interpret daného jazyka, což u druhého a zejména
třetı́ho uvedeného musı́me zajistit sami).
Při psanı́ WMI skriptu bychom měli předevšı́m zajistit přı́slušná oprávněnı́, zvláště když je
skript spouštěn na vzdáleném počı́tači v LAN. Jde o oprávněnı́ v modelu DCOM na daném počı́tači
B.6
FIREWALL VE WINDOWS
246
(WMI je totiž postaveno na COM objektech). Problém lze zjednodušit spouštěnı́m pod některým
doménovým správcovským účtem, pak nenı́ třeba řešit oprávněnı́ zvlášt’na každém počı́tači.
S mnoha WMI skripty se můžeme seznámit napřı́klad ve zdroji [8] ze seznamu literatury o automatizaci správy a skriptovánı́. Dalšı́ informace o WMI (včetně WMI skriptů) najdeme napřı́klad
na
• http://64.4.11.252/en-us/library/aa561208%28BTS.10%29.aspx
• http://www.computerperformance.co.uk/vbscript/wmi.htm
• http://etutorials.org/Server+Administration/Active+directory/Part+III+Scripting+Active+
Directory+with+ADSI+ADO+and+WMI/Chapter+26.+Scripting+with+WMI/
• Třı́dı́lný seriál o skriptovánı́ WMI v PowerShellu:
http://www.powershellpro.com/powershell-tutorial-introduction/powershell-scripting-with-wmi/
http://www.powershellpro.com/powershell-tutorial-introduction/powershell-wmi-methods/
http://www.powershellpro.com/powershell-tutorial-introduction/wmi-part3/
• http://flylib.com/books/en/2.679.1.8/1/
Úkoly
Pokud máte dostatečná přı́stupová oprávněnı́, vyzkoušejte si alespoň „vypisovacı́“ přı́kazy z výše
uvedeného přı́kladu.
B.6
Firewall ve Windows
Firewall ve Windows XP je pouze jednosměrný. Ve
verzi Vista a Server 2008 se objevil obousměrný firewall, ale filtrovánı́ odchozı́ch paketů je v desktopové
verzi standardně vypnuto (dá se ale zapnout), tedy
funguje jako jednosměrný.
Nejznámějšı́ firewally pro Windows jsou napřı́klad
Comodo Firewall, Sunbelt Personal Firewall (dřı́ve
Kerio), ZoneAlarm, Norton Personal Firewall, Avast!,
Avira.
Porty použı́vané konkrétnı́ aplikacı́ (přı́padně na
kterých portech naslouchá) zjistı́me napřı́klad v Process Exploreru – v kontextovém menu procesu zvolı́me Properties a přejdeme na kartu TCP/IP (obrázek Obrázek B.1: Konfigurace pravidel firewallu ve Windows XP
B.2).
Přı́klad
Prohlédneme si konfiguraci firewallu. K firewallu budeme přistupovat ve Windows (zde verze XP
SP2, ve vyššı́ch je to obdobné), a to přes NetShell.
B.6
FIREWALL VE WINDOWS
247
Obrázek B.2: Zjistěnı́ portů pro aplikaci v Process Exploreru
netsh
spustı́me NetShell
firewall
přesun do kontextu firewall, následujı́cı́ přı́kazy provádı́me v tomto kontextu
nejdřı́v si ověřı́me, co vše lze zobrazit
show
show config
show state
zobrazı́me konfiguraci firewallu (je celkem obsáhlá)
zobrazı́ se momentálnı́ stav firewallu
zobrazı́ se provoznı́ (operačnı́) režim (porovnejte, co se rozumı́ stavem z předchozı́ho přı́kazu a provoznı́m režimem z tohoto přı́kazu)
show opmode
tı́mto přı́kazem zjistı́me, co vše lze nastavovat přı́kazem set (tj. daná vlastnost už je
definována, ale my ji můžeme změnit)
set ?
nastavı́me provoznı́ mód na dostupný
set opmode enable
show allowedprogram
add allowedprogram ?
show portopening
zobrazı́ aplikace, které majı́ povoleno přistupovat ven do sı́tě
zajı́má nás, jak lze do seznamu přidat dalšı́ aplikaci
zjistı́me porty s nastavenou výjimkou (otevřené)
ze seznamu zjistı́me, že je v něm port, který by tam neměl být, tedy
nás zajı́má, jak ho uzavřı́t
delete portopening ?
show service
exit
skončı́me
vypı́šou se služby přistupujı́cı́ na sı́t’
B.7
DALŠÍ PŘÍKAZY
B.7
248
Dalšı́ přı́kazy
Z dalšı́ch užitečných přı́kazů (s mnohými jsme se seznámili v Operačnı́ch systémech):
net
přı́kaz pro základnı́ správu lokálnı́ sı́tě (sdı́lenı́ zdrojů v LAN, přı́padně nastavenı́ NTP
serveru) a dalšı́ (včetně správy uživatelů, skupin, zásad účtů apod.)
ftp
FTP klient pro přenášenı́ souborů po sı́ti, ve Windows také najdeme jednoduchou variantu
TFTP
ipseccmd
konfigurace protokolu IPSec, na klientech nemusı́ být dostupný
sloužı́ ke správě otevřených souborů, můžeme si nechat vypsat soubory otevřené
na tomto nebo jiném počı́tači v sı́ti, přı́padně otevřené uzavřı́t, na klientské stanici lze pro
podobné účely použı́vat také varianty přı́kazu net
openfiles
Na serverových verzı́ch Windows najdeme mnoho dalšı́ch přı́kazů, které na klientech nejsou instalovány, předevšı́m jde o přı́kazy pro správu Active Directory (např. ntdsutil nebo netdom), či
pro správu DNS serveru (např. dnsutil) a dalšı́. Seznam s komentáři najdeme v jednom z nı́že
uvedených odkazů. U těchto přı́kazů bychom měli dát pozor předevšı́m na to, že jejich syntaxe se
může v různých verzı́ch systému mı́rně lišit.
Seznam přı́kazů pro Přı́kazový řádek ve Windows XP (ne všech) najdeme napřı́klad na
• http://technet.microsoft.com/en-us/library/cc772390%28WS.10%29.aspx
• http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us
/ntcmds.mspx?mfr=true.
• http://commandwindows.com/
Přı́loha
C
Práce s adresami a sı́těmi v Linuxu
V této přı́loze jsou popsány a demonstrovány přı́kazy, které se použı́vajı́ v Linuxu při práci se sı́těmi.
Podobně jako ve Windows, i tuto přı́lohu můžeme brát jako inspiraci pro procvičovánı́ a jako předehru
k zatı́m neexistujı́cı́m cvičenı́m z tohoto předmětu.
C.1
Specializované distribuce
Na routerech nižšı́ a střednı́ třı́dy se běžně setkáváme s některou distribucı́ embedded (vestavěného)
Linuxu (často to ani nenı́ znát, pokud při správě využı́váme webové rozhranı́), protože tento
systém je velmi dobře vybaven nástroji pro práci v sı́ti. Obecně – embedded systém je systém
je určen k oživenı́ zařı́zenı́, která nejsou běžnými univerzálnı́mi počı́tači, napřı́klad zmı́něných
sı́t’ových zařı́zenı́, ale také průmyslových počı́tačů, mobilnı́ch telefonů, PDA apod.
Podobný router či bránu nebo switch s Linuxem si můžeme vyrobit sami. Lze využı́t staršı́
počı́tač (ovšem musı́me počı́tat s poměrně vysokou spotřebou a hlučnostı́), nebo můžeme pořı́dit
malý počı́tač průmyslového typu (dajı́ se koupit napřı́klad tzv. jednodeskové počı́tače, které majı́
vše integrováno na základnı́ desce a nepočı́tá se s rozšiřujı́cı́mi kartami či pamět’ovými moduly)
nebo přı́mo zařı́zenı́ určené k práci v sı́ti.
Zbývá zvolit vhodnou distribuci Linuxu. Použitelná je vpodstatě jakákoliv (až na ty typicky
multimediálnı́), typicky Slackware nebo Debian (Debian je výhodný pro svou univerzálnost co se
týče hardwarových platforem), ale můžeme si stáhnout distribuci specializovanou na využitı́ na
sı́t’ovém zařı́zenı́. Sice budeme zřejmě „ochuzeni“ o rozbujelé grafické rozhranı́, ale zato budeme
mı́t méně práce s optimalizacı́ distribuce pro naše využitı́, distribuce bude mı́t menšı́ nároky na
zdroje (předevšı́m pamět’, většinou je spodnı́ hranice 12 nebo 16 MB), instalace bývá někdy možná
i přes USB (napřı́klad IPCop) a pravděpodobněji bude podporovat hardwarové platformy, které
se na specializovaných zařı́zenı́ch použı́vajı́ (záležı́ na tom, jaký máme hardware, i podle toho
vybı́ráme operačnı́ systém).
Přı́klady vhodných distribucı́:
249
C.1
SPECIALIZOVANÉ DISTRIBUCE
250
• IPCop1 je předpřipraven pro instalaci na firewallu a internetové bráně (podporuje i VLAN), lze
ho spravovat přes webové rozhranı́ nebo konzolu. Nabı́zı́ poměrně dost služeb – DHCP klient
a server, NTP klient a server, Dynamic DNS, IDS (program Snort), SSH server, HTTP/FTP
proxy (program Squid), stavový firewall, IPSec VPN, atd.
• Sentry Firewall CD2 je zajı́mavý tı́m, že se spouštı́ z bootovacı́ho CD (tudı́ž je použitelný
předevšı́m na zařı́zenı́ch vybavených optickou mechanikou, třeba staršı́ch počı́tačı́ch), „proměnlivou“ konfiguraci zapisujeme na výměnné médium (třeba na disketu, když použijeme
staršı́ počı́tač, disketa má výhodu velmi snadné a rychlé ochrany proti zápisu). Může sloužit jako firewall, brána (software ebtables), IDS (Snort), router (Zebra a IPRoute2), server,
podporuje OpenVPN, atd.
• Freesco3 (ze slov „Free Cisco“) je volně šiřitelný systém obdobný systémům pro zařı́zenı́ Cisco,
Nortel, 3-Com apod. Může plnit roli routeru (až 10 ethernetových portů), firewallu, serveru
pro protokoly DHCP, NTP (čas), DNS, FTP, HTTP, SSH, RAS, PPPoE, PPtP, apod., protože jde
o Linux, tak samozřejmě i firewall a NAT.
• Pyramid Linux4 je určen předevšı́m pro bezdrátové přı́stupové body nebo může plnit roli
firewallu, je odvozen z Ubuntu. Typickou hardwarovou platformou je bud’ x86 nebo jednodesková zařı́zenı́.
• Bering uClibc5 je mimořádně malá distribuce určená pro routery s bránou. Jejı́ zdrojový kód je
natolik upraven směrem k minimalizaci, že nenı́ kompatibilnı́ s jinými distribucemi, tedy se
při doinstalovávánı́ dalšı́ch balı́čků musı́me spolehnout na repozitář této distribuce (nicméně
ten je zcela dostatečně vybaven). Obsahuje celkem běžnou sadu softwaru včetně firewallu,
IDS, sledovánı́ sı́tě, podpora bezdrátu, VPN, atd.
• Voyage Linux6 je distribuce odvozená z Debianu, určená pro hardwarové platformy založené
na x86 (včetně jednodeskových zařı́zenı́). Použı́vá se na firewallech, bezdrátových access
pointech, NAS, přı́padně routerech, má také vestavěnou podporu pro VoIP bránu (software
Asterisk, ve variantě Voyage ONE).
• Embedded Debian (EmDebian)7 je Debian upravený pro použitı́ na embedded zařı́zenı́ch, odlehčený (spı́še osekaný), schopný běžet na zařı́zenı́ch s velmi nı́zkou spotřebou. Předpokládajı́
se úpravy systému křı́žovou kompilacı́ (cross-compilation).
• Embedded Gentoo8 je derivát Gentoo, opět se počı́tá s cross-kompilacı́.
• QPlus9 je embedded distribuce Linuxu pro různé typy zařı́zenı́ včetně routerů.
1
http://www.ipcop.org/
http://www.sentryfirewall.com/
3
http://www.freesco.org/
4
http://code.google.com/p/pyramidlinux/
5
http://leaf.sourceforge.net/bering-uclibc/,
http://www.csg.ethz.ch/education/lectures/pps firewall/SS2006/doc/bering installation guide.pdf
6
http://linux.voyage.hk/
7
http://www.emdebian.org/
8
http://www.gentoo.org/proj/en/base/embedded/, http://www.gentoo.org/proj/en/base/embedded/handbook/
9
http://sourceforge.net/projects/qplus/
2
C.2
SOUBORY SOUVISEJÍCÍ SE SÍTĚMI
251
Pokud se rozhodneme použı́t některou běžnou distribuci, měli bychom zajistit co nejlepšı́ zabezpečenı́ našeho zařı́zenı́. Velmi dobrou volbou je instalace nástroje Bastille Linux,10 což nenı́ distribuce,
ale sada skriptů, které formou průvodce zjistı́ informace od systému a uživatele (s uživatelem
konverzuje formou otázek a odpovědı́) a pak na pokyn (se souhlasem uživatele) provede potřebná
bezpečnostnı́ nastavenı́. Skripty je možné procházet postupně a přı́padně volby rušit či se k nim
vracet.
Velmi důkladný popis přizpůsobenı́ či vylepšenı́ (jakékoliv) distribuce Linuxu pro použitı́
na sı́t’ovém zařı́zenı́ najdeme předevšı́m ve zdroji [18] ze seznamu literatury. Dalšı́ informace
o embedded Linuxu:
• Embedded Linux Platform Specification. LinuxFoundation.org. URL:
http://www.linuxfoundation.org/en/ELC
• Embedded Linux Interfacing. URL: http://www.embeddedlinuxinterfacing.com/
• eLinux (Embedded Linux) wiki. URL: http://elinux.org/Main Page
• Embedded Linux. Felk.cvut.cz. URL: http://support.dce.felk.cvut.cz/osp/cviceni/2/
• THELIN, J. Introduction: a Typical Embedded System [online]. Linux Journal, 2009. WWW:
http://www.linuxjournal.com/magazine/introduction-typical-embedded-system
Na routerech (a také některých jiných zařı́zenı́ch v sı́ti včetně servisnı́ch notebooků a serverů) se
setkáváme s vı́ce než jednı́m fyzickým sı́t’ovým rozhranı́m (napřı́klad vı́ce ethernetových portů),
taková zařı́zenı́ nazýváme multihomed devices.
Poznámka: Mnohé z dále uvedených přı́kazů vyžadujı́ vyššı́ přı́stupová oprávněnı́. Může se také
stát, že přı́kaz bude fungovat i bez vyššı́ch přı́stupových oprávněnı́, ale jeho výstup bude jiný
(obvykle kratšı́ nebo prázdný), to se týká napřı́klad přı́kazů skupiny ip neighbour. Proto je lepšı́
alespoň „vypisovacı́“ přı́kazy zkoušet s vyššı́mi oprávněnı́mi.
C.2
P
L
Soubory souvisejı́cı́ se sı́těmi
Vybavenost unixových systémů nástroji pro práci se sı́těmi je obecně vysoká, ovšem v každém unixovém systému svým způsobem specifická. Některé firmy distribuujı́cı́ unixové systémy přidávajı́
své vlastnı́ typické nástroje.
Odlišnosti jsou také v souborech a adresářı́ch, které se sı́těmi souvisejı́. Většina konfiguračnı́ch skriptů obvykle bývá v adresáři /etc/sysconfig/network a jeho podadresářı́ch (přı́p.
/etc/sysconfig/network-scripts), v některých linuxových distribucı́ch to je adresář /etc/rc.d/rc.inet1
(Slackware), /etc/conf.d/net (Gentoo) nebo /etc/network (Debian).
$
Přı́klad
Předpokládejme, že konfigurace sı́tě je v adresáři /etc/sysconfig/network-scripts. Přesuneme
se do tohoto adresáře. Měl by tam být soubor ifcfg-eth0, ve kterém je uložena konfigurace
prvnı́ho sı́t’ového rozhranı́ (karty) – IP adresa, maska, způsob zı́skánı́ IP adresy (pokud dynamicky,
10
http://bastille-linux.sourceforge.net/
C.2
SOUBORY SOUVISEJÍCÍ SE SÍTĚMI
252
tak zde IP adresu nenajdeme) apod. Pokud máme vı́ce sı́t’ových rozhranı́, pro každé z nich zde
bude jeden takový soubor.
V souboru /etc/resolv.conf nastavujeme kromě jiného adresu DNS serveru (tj. když nevı́me,
kde tuto adresu zadat, podı́váme se do tohoto souboru). Jde o řádek (nebo o vı́ce řádků, když
chceme zadat i záložnı́ DNS servery) ve formátu
nameserver adresa, napřı́klad
nameserver 193.84.192.10
Zadaný DNS server bude využı́ván okamžitě po uloženı́ souboru, nenı́ třeba restartovat systém
ani žádný proces.
Přı́klad
Předpokládejme, že z počı́tače chceme vytvořit router. To nenı́ až tak těžké, stačı́ mı́t zařı́zenı́
s vı́ce sı́t’ovými rozhranı́mi a provést několik nastavenı́. Jedno z nich je povolenı́ forwardingu
(přeposı́lánı́). To se provede menšı́ změnou v souboru /etc/sysctl.conf:
• najdeme řádek net.ipv4.ip_forward=0 (je možné, že mı́sto teček budou lomı́tka, pravidla
syntaxe umožňujı́ obojı́)
• změnı́me na net.ipv4.ip_forward=1
• aby změna začala platit, musı́me bud’ restartovat systém a nebo jednoduše přimět démona
sysctl, aby znovu načetl své konfiguračnı́ soubory (včetně toho, který jsme pozměnili a samozřejmě uložili):
sysctl -p
Ovšem zapnutı́ forwardingu nestačı́, je třeba na počı́tačı́ch v dotyčných sı́tı́ch (které router propojuje) nastavit toto zařı́zenı́ jako bránu (napřı́klad pokud má karta eth0 IP adresu 193.84.200.1,
u počı́tačů v sı́ti, do které je připojena, nastavı́me tuto adresu jako adresu brány, IP adresu karty
eth1 zase použijeme v druhé sı́ti, samozřejmě vždy tu adresu, která je v dané sı́ti viditelná).
A pak samozřejmě musı́me nakonfigurovat firewall a dalšı́ bezpečnostnı́ mechanismy.
Všimněte si, že nenı́ třeba restartovat počı́tač, třebaže jsme provedli podstatnou změnu v nastavenı́ systému.
V adresáři /etc najdeme hodně užitečných souborů a adresářů, jak vı́me, napřı́klad /etc/networks,
/etc/hosts, /etc/ethers.
Dynamické (momentálnı́) nastavenı́ sı́tě obvykle najdeme v podadresářı́ch a souborech v systému /proc, napřı́klad /proc/net/arp.
Přı́klad
Do některých souborů v /proc lze za určitých okolnostı́ zapisovat, napřı́klad přı́kazem
echo 1 > /proc/sys/net/ipv4/ip_forward
zapneme forwardovánı́ (přeposı́lánı́ mezi sı́těmi) na takovém zařı́zenı́, které má dvě sı́t’ová rozhranı́
C.3
STARŠÍ PŘÍKAZY PRO PRÁCI S ADRESAMI
253
(třeba dvě sı́t’ové karty) a je tedy připojeno do dvou různých sı́tı́. Pokud je v tomto souboru hodnota
0, nepřeposı́lá se, hodnota 1 znamená, že se pakety majı́ přeposı́lat mezi rozhranı́mi.
Toto nastavenı́ však platı́ jen do restartu počı́tače (to platı́ obecně o čemkoliv, co změnı́me
v /proc), proto je vhodné tento přı́kaz uložit také do některého skriptu, který se spouštı́ při startu
systému, napřı́klad do /etc/rc.d/rc.local, podle konkrétnı́ distribuce.
Zatı́m jsme si ukázali dvě možnosti, jak zapnout forwardovánı́ (jiný způsob je v předchozı́m
přı́kladu). Rozdı́l mezi nimi je v tom, že zápis do souboru v souborovém systému proc platı́ jen do
restartu počı́tače, zatı́mco změna v souboru /etc/sysctl.conf je trvalá.
Úkoly
Projděte si zde probı́rané soubory na umı́stěnı́ch platných ve vašı́ distribuci, včetně „sı́t’ových“
částı́ souborového systému /proc.
C.3
Staršı́ přı́kazy pro práci s adresami
Nejdřı́v se podı́váme na přı́kazy, které se v unixových systémech použı́vajı́ pro práci s adresami
již desı́tky let. V novějšı́ch distribucı́ch Linuxu se však mı́sto přı́kazů ifconfig, route a arp
doporučuje použı́vat nový přı́kaz ip, protože staršı́ přı́kazy mohou být v některých přı́padech
navzájem méně kompatibilnı́.
Přı́kaz ifconfig sloužı́ ke konfiguraci sı́t’ových rozhranı́ (interfaces) jádra (narozdı́l od Windows jsou v Linuxu sı́t’ová rozhranı́ součástı́ jádra).
ifconfig
zobrazı́ informaci o všech sı́t’ových rozhranı́ch
ifconfig eth0
zobrazı́ informaci o sı́t’ovém rozhranı́ eth0 (to obvykle bývá ethernetová karta)
„shodı́“ zařı́zenı́ eth0 (zneaktivnı́ tuto kartu), provádı́me napřı́klad tehdy,
když chceme tomuto rozhranı́ přiřadit jinou adresu
ifconfig eth0 down
ifconfig eth0 up
aktivuje zařı́zenı́ eth0
ifconfig eth0 down hw ether 00:00:00:00:00:02
kromě toho, že zneaktivnı́ zařı́zenı́ eth0,
také mu přiřadı́ MAC adresu; vnitřnı́ přı́kaz hw ether adresa znamená, že jde o etherneto-
vou kartu, které přiřazujeme danou adresu (před podobnými změnami je vždy nutné kartu
zneaktivnit)
nastavı́
IP
adresu
a masku podsı́tě pro eth0, pak je zaktivnı́ (předpokládáme, že předtı́m byla tato karta neaktivnı́)
ifconfig eth0 172.19.124.104 netmask 255.255.255.0 up
zapne promiskuitnı́ mód (tj. karta přijı́má/odposlouchává všechny
datagramy, nejen ty, které jsou jı́ adresované)
ifconfig eth0 promisc
ifconfig eth0 -promisc
vypne promiskuitnı́ mód
$
C.3
STARŠÍ PŘÍKAZY PRO PRÁCI S ADRESAMI
254
Tento přı́kaz má dalšı́ volby, kterými lze napřı́klad určovat multicast a broadcast adresy, přidělovat
zdroje (I/O pamět’, IRQ apod.), nastavovat metriky, atd.
Přı́klad
Přı́kaz ifconfig na počı́tači s jednou sı́t’ovou kartou bude vypadat takto:
sarka@notebook:˜$ ifconfig
eth0
Zapouzdřenı́:Ethernet HWadr 00:1D:72:31:0A:A0
inet adr:10.0.0.2 Všesměr:10.0.0.255 Maska:255.255.255.0
inet6-adr: fe80::21d:72ff:fe31:aa0/64 Rozsah:Linka
AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST MTU:1500 Metrika:1
RX packets:561 errors:0 dropped:0 overruns:0 frame:0
TX packets:556 errors:0 dropped:0 overruns:0 carrier:0
kolizı́:0 délka odchozı́ fronty:1000
RX bytes:379302 (370.4 KiB) TX bytes:100735 (98.3 KiB)
Přerušenı́:169
lo
Zapouzdřenı́:Mı́stnı́ smyčka
inet adr:127.0.0.1 Maska:255.0.0.0
inet6-adr: ::1/128 Rozsah:Počı́tač
AKTIVOVÁNO SMYČKA BĚŽÍ MTU:16436 Metrika:1
RX packets:270 errors:0 dropped:0 overruns:0 frame:0
TX packets:270 errors:0 dropped:0 overruns:0 carrier:0
kolizı́:0 délka odchozı́ fronty:0
RX bytes:24914 (24.3 KiB) TX bytes:24914 (24.3 KiB)
M
Výpis samozřejmě může být celý v angličtině, napřı́klad mı́sto délka odchozı́ fronty bychom
pak našli řetězec txqueuelen, nebo mı́sto AKTIVOVÁNO VŠESMĚROVÉ_VYSÍLÁNÍ BĚŽÍ MULTICAST
by bylo UP BROADCAST NOTRAILERS RUNNING MULTICAST.
Srovnejte s výstupem přı́kazů ip link show a ip addr show dev eth0 v přı́kladu na straně
257, všechny tyto přı́kazy byly spuštěny na tomtéž počı́tači, ale v jiné situaci (tj. napřı́klad nebudou
sedět počty RX a TX bytes/packets).
Pro rychlé odpojenı́ a aktivovánı́ sı́t’ového rozhranı́ existujı́ také zkrácené verze přı́kazu:
ifdown eth0 deaktivace sı́t’ové karty
ifup eth0 aktivace karty
Pro práci se směrovacı́ tabulkou lze využı́t přı́kaz route.
$
zobrazı́ hlavnı́ směrovacı́ tabulku (k jiným směrovacı́m tabulkám se tı́mto přı́kazem
nedostaneme)
route -n -A inet
prvnı́ parametr způsobı́ vypisovánı́ čı́selných adres mı́sto doménových
(u některých přı́kazů také ve formě --no-dns, ale většina rozumı́ pouze -n), druhý stanovı́,
že se majı́ vypsat pouze IPv4 adresy (pro IPv6 by bylo -A inet6)
route add -net 193.90.100.0 netmask 255.255.255.128 gw 193.90.220.3 dev eth0 přidáme
do směrovacı́ tabulky nový záznam (jde o adresu sı́tě se zadanou maskou, poslednı́m parametrem je brána, na kterou se majı́ posı́lat datagramy určené pro danou sı́t’)
route add default gw 193.88.50.10 dev eth0
určı́me výchozı́ bránu pro zadané sı́t’ové
rozhranı́
route
C.4
MECHANISMUS IPROUTE2 (PŘÍKAZ IP) – ADRESY, SÍŤ, SMĚROVÁNÍ
255
odstranı́me řádek směrovacı́ tabulky (obvykle stačı́ zadat jen údaj o IP adrese, kterou chceme
odstranit z tabulky)
route del default
odstranı́me směrovacı́ informaci o výchozı́ bráně, typicky když chceme
nastavit jinou
route -Cn
zobrazı́ se cache pro směrovánı́, a to s čı́selnými IP adresami
route del -net 193.90.100.0 netmask 255.255.255.128 gw 193.90.220.3
Mı́sto přı́kazu route se doporučuje použı́vat přı́kaz ip route.
V Linuxu se také použı́vá přı́kaz arp, a to s podobnou syntaxı́ jako ve Windows:
zobrazı́ ARP tabulku, druhý přepı́nač znamená, že všechny adresy se zobrazı́ v čı́selném tvaru (mı́sto doménových názvů), ale můžeme použı́t samozřejmě arp -a (ovšem
když docházı́ k překladu IP adres na doménové, přı́kaz pracuje pomaleji)
arp -n -i eth1
zobrazı́ ARP tabulku zadaného sı́t’ového rozhranı́ (to následuje za přepı́načem
-i)
arp -s 123.123.123.123 00:12:34:56:01:08 -i eth1 přidánı́ statického záznamu do ARP
tabulky pro kartu eth1
arp -d 123.123.123.123 -i eth1
odebránı́ záznamu z ARP tabulky pro kartu eth1
arp -a -n
$
Je možné, že v některých distribucı́ch nebude v nejnovějšı́ch verzı́ch některý ze staršı́ch přı́kazů
fungovat. Z toho a z dalšı́ch důvodů je lepšı́ zvyknout si na přı́kaz ip.
Úkoly
1. Zjistěte, jaká sı́t’ová rozhranı́ na počı́tači máte. Zjistěte přı́slušné MAC adresy a přidělené IP
adresy. Pokuste se některé sı́t’ové zařı́zenı́ deaktivovat a pak znovu aktivovat (ne loopback!),
pokud zı́skáváte IP adresu od DHCP serveru, srovnejte adresy před deaktivacı́ a po aktivaci.
2. Zjistěte, zda máte přidělenu také IPv6 adresu. Pokud ano: doplňte vynechané nulové sekce
adresy (stačı́ jedna nula na sekci) a oddělte prefix od klientské části adresy. Byla klientská část
zı́skána autokonfiguracı́? (tj. srovnejte s MAC adresou, zda odpovı́dá EUI-64, viz stranu 34)
3. Zobrazte hlavnı́ směrovacı́ tabulku tak, aby se IP adresy nepřekládaly na doménové. Srovnejte
s výpisem obsahujı́cı́m doménové adresy. Zjistěte, jakou IP adresu má výchozı́ brána v hlavnı́
tabulce. Zobrazte směrovacı́ cache (opět s IP adresami mı́sto doménových).
4. Zobrazte ARP tabulku (opět tak, aby se IP adresy nepřekládaly na doménové, srovnejte
s výpisem s doménovými adresami).
C.4
Mechanismus iproute2 (přı́kaz ip) – adresy, sı́t’, směrovánı́
Ve všech novějšı́ch distribucı́ch se setkáme s ještě komplexnı́m přı́kazem ip, který je součástı́
balı́čku iproute2. Tento přı́kaz byl zařazen jako náhrada přı́kazů ifconfig, route a arp (pro
úplnost jsme se seznámili i s nimi), v současné době se mı́sto těchto třı́ doporučuje použı́vat spı́še
přı́kaz ip. Jeho konfiguračnı́ soubory najdeme v /etc/iproute2. Má specifické vnitřnı́ přı́kazy,
postupně probereme nejdůležitějšı́ varianty.
$
C.4
C.4.1
MECHANISMUS IPROUTE2 (PŘÍKAZ IP) – ADRESY, SÍŤ, SMĚROVÁNÍ
256
Konfigurace sı́t’ového rozhranı́ a adres
Nejdřı́v se podı́váme na formu přı́kazu ip pro práci se sı́t’ovými rozhranı́mi a IP adresami.
pracujeme na vrstvě L2 (linkové) ISO/OSI modelu, vpodstatě i L1, tedy pracujeme
s MAC adresami a sı́t’ovým rozhranı́m (napřı́klad můžeme kartu odpojit či připojit)
ip link ...
$
ip link show
zobrazı́ stav spojenı́ (tj. stav sı́t’ového rozhranı́), mı́sto show je možné všude
použı́vat list nebo ls, na multihomed zařı́zenı́ch může být výpis velmi dlouhý; narozdı́l od ifconfig se výpı́šou i ta sı́t’ová rozhranı́, která z nějakého důvodu nelze řádně
aktivovat
zadali jsme název rozhranı́ (tj. nebudou se vypisovat informace
pro všechna, pokud jich je vı́ce), a navı́c parametr -s znamená podrobnějšı́ výpis
link set dev eth0 up
aktivuje rozhranı́ eth0
link set dev eth0 down
deaktivuje rozhranı́ eth0
link set dev eth0 mtu 1500
změnı́ hodnotu MTU na 1500 oktetů (Maximum transmission unit, maximálnı́ velikosti IP datagramu, kterou je možné přijmout a odeslat)
link set dev eth0 address 02:00:00:00:11:22
změnı́me
MAC
adresu
sı́t’ové karty eth0, všimněte si prvnı́ho oktetu; pozor, změna MAC nemusı́ někdy dopadnout dobře, jde o potenciálně nebezpečnou operaci
ip -s link show eth0
ip
ip
ip
ip
ip addr ...
nebo a)
pracujeme na vrstvě L3 (sı́t’ové), tedy s IP adresami (mı́sto addr lze použı́t address
takto zjistı́me IP adresu a souvisejı́cı́ informace, přı́padně můžeme přidat
i název karty, která nás zajı́má, jedna karta může mı́t i vı́ce než jednu IPv6 adresu (jednu
primárnı́ a ostatnı́ sekundárnı́)
address show
totéž, také funguje ip a show nebo ip a ls
addr show dev eth0 primary
zjistı́me primárnı́ adresu zařı́zenı́ eth0
addr add 193.90.220.42/25 brd + dev eth0
nastavı́me IP adresu pro rozhranı́
11
eth0, broadcast adresu necháme nastavit na výchozı́ (pokud chceme určit jinou než
výchozı́, mı́sto symbolu + napı́šeme novou broadcast adresu), všimněte si, že mı́sto
masky zadáváme délku prefixu hned u adresy
addr del 193.90.220.42/25 brd + dev eth0
odebereme kartě eth0 zadanou adresu; pozor – pokud se jedná o primárnı́ adresu, odeberou se i všechny sekundárnı́
addr flush dev eth0
pročištěnı́ (flush, odstraněnı́) všech adres na daném rozhranı́,
zůstane pouze IPv6 adresa zı́skaná autokonfiguracı́ (tu nemá smysl odstraňovat, je odvozena z MAC adresy), vnitřnı́mu přı́kazu flush se spı́še vyhýbáme (můžeme omylem
odstranit adresy, které by měly zůstat)
ip addr show
ip
ip
ip
ip
ip
11
Jedno rozhranı́ (sı́t’ová karta) může mı́t vı́ce IPv6 adres (vpodstatě i IPv4 adres, od jádra Linuxu v. 2.2). Jestliže dané
rozhranı́ (sı́t’ová karta) již má IPv6 adresu přiřazenu, dalšı́ bude sekundárnı́. Pokud chceme jednomu sı́t’ovému rozhranı́
přiřadit vı́ce IPv6 adres, měli bychom každé z těchto adres přiřadit label (popisek) – viz man ip, předevšı́m z důvodu
jejich rozlišenı́ v přı́kazech, napřı́klad ifconfig s tı́m mı́vá problémy.
Taktéž lze IP adresy jednoho rozhranı́ rozlišit pomocı́ aliasů, což je rozlišenı́ na nižšı́ úrovni než v přı́padě labelů, napřı́klad přı́kazem ifconfig eth1:0 193.84.190.99 netmask 255.255.128.0 up vytvořı́me alias eth1:0 k druhé
kartě (eth1) s vlastnı́ IP adresou, který lze také deaktivovat bez ovlivněnı́ rozhranı́ eth1.
$
C.4
MECHANISMUS IPROUTE2 (PŘÍKAZ IP) – ADRESY, SÍŤ, SMĚROVÁNÍ
257
před vnitřnı́m přı́kazem je použit parametr určujı́cı́,
že se bude pracovat pouze s IPv6 adresami (mı́sto -f inet6 je možné napsat zkráceně
-6), provede se odstraněnı́ adres IPv6 zı́skaných dynamicky (tj. kromě adresy zı́skané
autokonfiguracı́), pokud chceme provést totéž pro IPv4 adresy, napı́šeme
ip -f inet addr flush dynamic nebo
ip -4 addr flush dynamic nebo
ip -f inet6 addr flush dynamic
ip -4 a flush dynamic
Přı́klad
Podı́váme se na výstupy několika přı́kazů:
sarka@notebook:˜$ ip link show
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:1d:72:31:0a:a0 brd ff:ff:ff:ff:ff:ff
3: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
M
sarka@notebook:˜$ ip -s link show
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes packets errors dropped overrun mcast
24914
270
0
0
0
0
TX: bytes packets errors dropped carrier collsns
24914
270
0
0
0
0
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:1d:72:31:0a:a0 brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
379366
562
0
0
0
9
TX: bytes packets errors dropped carrier collsns
100799
557
0
0
0
0
3: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
RX: bytes packets errors dropped overrun mcast
0
0
0
0
0
0
TX: bytes packets errors dropped carrier collsns
0
0
0
0
0
0
M
Všimněte si, že v ostrých závorkách za názvem rozhranı́ jsou přı́znaky rozhranı́ (napřı́klad zda jde
o loopback, jestli je aktivnı́, povolenı́ broadcastu, apod.).
sarka@notebook:˜$ ip addr show
1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000
link/ether 00:1d:72:31:0a:a0 brd ff:ff:ff:ff:ff:ff
inet 10.0.0.2/24 brd 10.0.0.255 scope global eth0
inet6 fe80::21d:72ff:fe31:aa0/64 scope link
valid_lft forever preferred_lft forever
3: sit0: <NOARP> mtu 1480 qdisc noop
link/sit 0.0.0.0 brd 0.0.0.0
M
C.4
MECHANISMUS IPROUTE2 (PŘÍKAZ IP) – ADRESY, SÍŤ, SMĚROVÁNÍ
258
Kdyby nás zajı́malo pouze zařı́zenı́ eth0, napsali bychom
ip addr show dev eth0
Úkoly
1. Vypište údaje o svém sı́t’ovém rozhranı́, a pak je vypište včetně statistiky (podrobnějšı́ informace). Srovnejte oba výpisy. Určete, kolik máte sı́t’ových rozhranı́ (na koncové stanici
to odpovı́dá počtu sı́t’ových karet plus přı́padných virtuálnı́ch rozhranı́), jakou máte velikost MTU, jaké máte MAC adresy, přı́p. jaká je broadcast MAC adresa, jaký je provoz na
vstupu/výstupu rozhranı́.
2. Zjistěte IP adresy (IPv4 i IPv6) na svých sı́t’ových rozhranı́ch. Máte jen primárnı́ adresu, nebo
i nějaké sekundárnı́?
3. Pokud je na rozhranı́ definováno vı́ce adres, jak zobrazı́te pouze tu primárnı́? Co se stane,
když sı́t’ovému rozhranı́ s vı́ce IP adresami odebereme primárnı́/sekundárnı́ adresu?
C.4.2
Směrovánı́ a filtrovánı́
Přı́kaz ip se použı́vá při práci se směrovacı́mi tabulkami a při definovánı́ pravidel pro filtrovánı́
obdobně jako u firewallu.
V Linuxu neexistuje pouze jedna směrovacı́ tabulka. Ve výchozı́m nastavenı́ máme vždy alespoň
hlavnı́ (main) směrovacı́ tabulku, která je zároveň výchozı́ (default), a lokálnı́ tabulku (v lokálnı́
směrovacı́ tabulce najdeme předevšı́m loopback (mı́stnı́ cesty) a směrovánı́ broadcastů a multicastů), dalšı́ tabulky si můžeme dle potřeb vytvořit. Každá tabulka je identifikována svým jménem
a čı́slem, v přı́kazech můžeme použı́vat cokoliv z toho. Co se týče čı́sel směrovacı́ch tabulek, tak
u nově vytvořených můžeme použı́t čı́sla z intervalu 1 až 252, čı́sla předdefinovaných tabulek
vidı́me ve výpisu nı́že.
Zatı́mco přı́kaz route, se kterým jsme se již dřı́ve seznámili, dovoluje přistupovat pouze k hlavnı́
tabulce, přı́kaz ip umožňuje pracovat s jakoukoliv tabulkou.
Seznam směrovacı́ch tabulek je uložen v souboru /etc/iproute2/rt_tables. Výchozı́m obsahem je
255
254
253
0
local
main
default
unspec
(plus řádky s komentáři, komentářový symbol je #).
Novou směrovacı́ tabulku vytvořı́me jednoduše přidánı́m nového řádku do tohoto souboru
(dalšı́ informace najdeme u přı́kazu ip rule od strany 260). Obvykle soubor needitujeme přı́mo,
ale použijeme přesměrovánı́ s přidánı́m na konec:
M
C.4
MECHANISMUS IPROUTE2 (PŘÍKAZ IP) – ADRESY, SÍŤ, SMĚROVÁNÍ
259
echo čı́slo název >> /etc/iproute2/rt_tables
napřı́klad
echo 15 novatab >> /etc/iproute2/rt_tables
Všimněte si, že při přesměrovánı́ jsme použili dvojitou „šipku“, protože nechceme přepsat původnı́
obsah (na to pozor!), ale přidat nový záznam na konec souboru.
Přı́kazy:
ip route ...
pracujeme se směrovacı́ tabulkou, taktéž na vrstvě L3 (ale nad protokolem IP)
ip route show
zobrazı́ hlavnı́ směrovacı́ tabulku (pozor, ne všechny)
ip route show table local
zobrazı́ lokálnı́ směrovacı́ tabulku
ip route show table 12
zobrazı́ směrovacı́ tabulku čı́slo 12 (na tabulku se odkazujeme
jménem nebo čı́slem)
zobrazı́ vyrovnávacı́ pamět’ směrovánı́; velmi dlouhý výstup, je
dobré přidat ještě IP adresu, která nás zajı́má, a nebo výstup nějak filtrovat (třeba
grepem)
ip -s route show cache 193.90.102.36
zadali jsme IP adresu, která nás jako cı́l zajı́má, navı́c přepı́načem -s vyžadujeme podrobnějšı́ výstup (tj. vlastně statistiku směrovánı́ na danou adresu)
ip route add default via 193.90.220.1
nastavenı́ výchozı́ brány pro všechny cı́le,
které ve směrovacı́ tabulce nejsou přı́mo uvedeny
ip route add 193.90.100.0/25 via 193.90.220.3
přidánı́ nového (statického) řádku
do směrovacı́ tabulky (zadáváme adresu sı́tě s prefixem a dále adresu zařı́zenı́, přes které
se k prvnı́ zadané adrese dá dostat)
ip route show cache
ip route add 193.90.100.0/25 via 193.90.220.3 table administrativa
záznam jsme přidali do zadané směrovacı́ tabulky administrativa, nikoliv do hlavnı́
směrovacı́ tabulky
ip route delete 193.90.100.0/25
odstraněnı́ řádku tabulky (přı́p. lze opět zadat ta-
bulku)
takto zakážeme směrovánı́ na zadanou adresu, tj. defacto tuto adresu znepřı́stupnı́me ze zařı́zenı́ s touto tabulkou (použı́vajı́
napřı́klad zaměstnavatelé k zamezenı́ přı́stupu z daného počı́tače/směrovače k určitým
oblastem), zadaná podsı́t’či uzel je ohlášen(a) jako „no route to host“ (ICMP zpráva)
ip route add prohibit 193.221.88.0/28 from 193.90.102.29
podobně jako předchozı́, ale zablokovali jsme přı́stup pouze z jednoho (zadaného) uzlu, z jiných uzlů bude
směrovánı́ fungovat (klı́čové slovo from použijeme typicky na směrovači s Linuxem, na
koncové stanici nemá moc smysl)
ip route add blackhole 69.63.189.11
pokud někdo z lokálnı́ sı́tě odešle paket na
tuto adresu (mimochodem, je to jedna z IP adres serverů Facebooku), paket bude zahozen
a dotyčný nebude informován
ip route add unreachable 69.63.189.11
podobně jako předchozı́, ale odesı́latel je
informován o tom, že paket nedorazil, ICMP zprávou „ICMP unreachable“;
router tedy může paket „záměrně“ zahodit třemi různými způsoby (prohibit, blackhole,
unreachable).
ip route add prohibit 193.221.88.0/28
$
C.4
MECHANISMUS IPROUTE2 (PŘÍKAZ IP) – ADRESY, SÍŤ, SMĚROVÁNÍ
260
stanovı́ NAT překlad pro přı́chozı́ pakety (přicházejı́cı́ do LAN): když tento router dostane paket s prvnı́ („virtuálnı́ “)
adresou jako cı́lovou, přepı́še ji na druhou uvedenou (skutečnou v mı́stnı́ sı́ti) a pošle
dál
ip route add nat 192.205.120.56 via 193.90.102.29
Přı́klad
Ukážeme si rozdı́l mezi hlavnı́ a lokálnı́ směrovacı́ tabulkou na klientské stanici:
sarka@notebook:˜$ ip route show
193.84.195.0/25 dev eth0 proto kernel
default via 193.84.195.1 dev eth0
scope link
src 193.84.195.30
sarka@notebook:˜$ ip route show table local
broadcast 127.255.255.255 dev lo proto kernel scope link src 127.0.0.1
broadcast 193.84.195.0 dev eth0 proto kernel scope link src 193.84.195.30
local 193.84.195.30 dev eth0 proto kernel scope host src 193.84.195.30
broadcast 193.84.195.127 dev eth0 proto kernel scope link src 193.84.195.30
broadcast 127.0.0.0 dev lo proto kernel scope link src 127.0.0.1
local 127.0.0.1 dev lo proto kernel scope host src 127.0.0.1
local 127.0.0.0/8 dev lo proto kernel scope host src 127.0.0.1
M
M
V hlavnı́ tabulce bychom si měli předevšı́m všimnout řádku začı́najı́cı́ho default, to je směrovánı́
na bránu lokálnı́ sı́tě.
Směrovánı́ lze spojit s filtrovánı́m či podrobnějšı́m řı́zenı́m směrovánı́ podle zadaných pravidel
(politik), čemuž řı́káme Advanced Routing (pokročilé směrovánı́). Zatı́mco přı́kaz ip route pracuje
pouze s adresami, pomocı́ ip rule lze směrovánı́ ovlivnit také obsahem jiných polı́ IP datagramu
(směrovánı́ podle zásad), takto lze implementovat i mechanismus NAT.
ip rule ...
pracujeme s pravidly (politikami, zásadami) pro směrovánı́
ip rule show
výpis pravidel (vlastně zásad) pro směrovánı́, jsou tam minimálně tyto
řádky:
0:
32766:
32767:
from all lookup local
from all lookup main
from all lookup default
P
$
M
(přı́padně mı́sto default může být přı́mo čı́slo výchozı́ směrovacı́ tabulky 253), výchozı́
hodnoty pouze odkazujı́ na lokálnı́, hlavnı́ a výchozı́ směrovacı́ tabulku, čı́slo na začátku
je tzv. priorita pravidla, toto čı́slo by mělo být jedinečné pro každé pravidlo (čı́m menšı́
čı́slo, tı́m vyššı́ priorita)
echo 12 pomocnatab >> /etc/iproute2/rt_tables
trochu jsme odbočili, tı́mto přı́kazem jsme vytvořili směrovacı́ tabulku s čı́slem 12 a názvem pomocnatab
ip rule add from 195.200.94.0/24 table 12 priority 354
všechny pakety s uvedenou adresou jako zdrojovou (resp. adresou ze zadané sı́tě) budou směrovány podle
směrovacı́ tabulky 12 vytvořené v předchozı́m přı́kazu, hodnota pro prioritu pravidla
by měla být u pravidel unikátnı́ (pokud zvolı́me již existujı́cı́ prioritu, jádro přidělı́ nejbližšı́ menšı́ volné čı́slo, když prioritu neuvedeme vůbec, jádro nějakou zvolı́ samo),
čı́m menšı́ čı́slo, tı́m vyššı́ priorita; pokud ted’ zadáme ip rule show, bude výstup
následujı́cı́ (srovnejte s prvnı́m výpisem pravidel):
M
C.4
MECHANISMUS IPROUTE2 (PŘÍKAZ IP) – ADRESY, SÍŤ, SMĚROVÁNÍ
0:
354:
32766:
32767:
from
from
from
from
261
all lookup local
195.200.94.0/24 lookup pomocnatab
all lookup main
all lookup 253
určı́me, že pakety ze sı́tě
s prvnı́ zadanou adresou do sı́tě s druhou zadanou adresou budou směrovány podle
hlavnı́ směrovacı́ tabulky (přı́padně můžeme zadat, která tabulka se má použı́t), prioritu
pravidla zvolı́ jádro (všimněte si, které čı́slo jádro zvolilo: o něco nižšı́ čı́slo než poslednı́
uživatelské), ve výstupu přı́kazu ip rule show přibude tento řádek:
ip rule add from 195.80.94.0/24 to 194.200.24.0/24
353:
from 195.200.94.0/24 to 194.200.24.0/24 lookup main
NAT pravidlo pro odchozı́
pakety (tj. odcházejı́cı́ ze sı́tě): pokud má odejı́t ven ze sı́tě paket se zdrojovou adresou prvnı́ uvedenou (skutečnou), bude zdrojová adresa nastavena na druhou uvedenou
(„virtuálnı́ “; všimněte si, jaký je vztah mezi adresami v podobném výše uvedeném
přı́kazu ip route, musı́me mı́t provedeny oba přı́kazy, aby to fungovalo)
ip rule add iif lo table 10 priority 560
takto můžeme oddělit směrovánı́ provozu generovaného přı́mo na tomto zařı́zenı́ (lo, loopback, poněkud netypické použitı́
loopbacku) od směrovánı́ přeposı́laného (forwarding) provozu, tedy provoz generovaný
procesy na tomto zařı́zenı́ bude směrován podle tabulky 10 (přı́padně můžeme takto
oddělit provoz směrovaný z konkrétnı́ho rozhranı́, třeba eth2 coby třetı́ ethernetové sı́t’ové karty), do seznamu pravidel přibývá nový řádek (předpokládejme, že tabulka 10
se nazývá dalsitabulka):
ip rule add from 193.90.102.29 nat 192.205.120.56
560:
from all iif lo lookup dalsitabulka
odstranı́me pravidlo se zadanou prioritou (připomeňme si,
že priorita je vlastně pořadové čı́slo v tabulce pravidel, pravidlo je takto jednoznačně
identifikováno)
ip rule del priority 560
Přı́klad
Podı́váme se na možnost vytvořenı́ jednoduchého one-to-one stateless (bezstavového) NAT, tedy
překládáme mezi jednou vnitřnı́ a jednou vnějšı́ IP adresou. Toho lze docı́lit bud’ přı́kazem ip, nebo
mechanismem NetFilter (to, jak vı́me, je modul jádra obvykle použı́vaný jako firewall, jehož obrazem v uživatelském režimu je iptables). Pokud použijeme přı́kaz ip, bude náš router odpovı́dat
na ARP dotazy na NAT IP adresu, což může být užitečné (mechanismus NetFilter tuto vlastnost
nemá).
Předpokládejme, že chceme zpřı́stupnit stroj s IP adresou 195.159.200.28 ven ze sı́tě pod adresou
207.189.240.28, může se napřı́klad jednat o některý server v DMZ:
ip route add nat 207.189.240.28 via 195.159.200.28
nejdřı́v zajistı́me překlad cı́lové
adresy v přı́chozı́m (inbound) provozu, tedy DNAT
ip rule add nat 207.189.240.28 from 195.159.200.28
zajistı́me překlad zdrojové adresy
v odchozı́m provozu, tedy SNAT
ip route flush cache
záznamy
aby překlad fungoval, musı́me vyprázdnit směrovacı́ cache se starými
M
M
C.4
MECHANISMUS IPROUTE2 (PŘÍKAZ IP) – ADRESY, SÍŤ, SMĚROVÁNÍ
ip route show table all
262
ve výstupu by měl být kromě jiného řádek
nat 207.189.240.28 via 195.159.200.28 table local scope host
(řádků je tam obvykle poměrně hodně, tedy můžeme výstup profiltrovat napřı́klad přı́kazem
grep)
ip rule show
podobně zkontrolujeme seznam pravidel pro směrovánı́, mezi nimi by měl být
řádek
32386:
from 195.159.200.28 lookup main map-to 207.189.240.28
(pravděpodobně s jinou hodnotou priority)
Totéž lze provést s použitı́m mechanismu NetFilter zároveň s určenı́m dalšı́ch údajů pro překlad
(napřı́klad čı́sla TCP portu), ukázku máme na straně 284.
Přı́klad
Předpokládejme, že máme dva ISP (poskytovatele připojenı́ k Internetu) připojené k témuž routeru
s Linuxem. Tento přı́pad nenı́ až tak exotický, můžeme se s nı́m setkat u některých střednı́ch/většı́ch
společnostı́ (respektive, nemusı́ jı́t ani o vı́ce různých ISP, stačı́, když máme vı́ce bran).
Budeme chtı́t vytvořit dvě směrovacı́ tabulky, zvlášt’pro každého ISP. Situace je znázorněna na
obrázku C.1.
mı́stnı́
sı́tě
Internet
ISP1
brána: 10.1.1.1
eth1
eth0
Router
eth2
ISP2
brána: 10.32.32.1
Obrázek C.1: Situace pro vı́ce ISP přes jeden router
Nejdřı́v „vytvořı́me“ dvě směrovacı́ tabulky, pro každého ISP zvlášt’:
echo 10 ISPprvni >> /etc/iproute2/rt_tables
echo 20 ISPdruhy >> /etc/iproute2/rt_tables
Ted’ se musı́me rozhodnout, jak se bude dělit provoz mezi jednotlivé brány (a tedy i mezi
jednotlivá rozhranı́ routeru). Předpokládejme, že provoz souvisejı́cı́ s lokálnı́ sı́tı́ 10.192.0.0/24
půjde přes prvnı́ bránu (rozhranı́ eth1) a bude směrován tabulkou 10, provoz sı́tě 10.192.128.0/24
půjde přes druhou bránu a bude směrován tabulkou 20, zbytek půjde také přes druhou bránu
a bude směrován hlavnı́ směrovacı́ tabulkou.
Nakonfigurujeme směrovacı́ tabulku a pravidla:
ip route add default via 10.32.32.1 dev eth2
sı́tı́ neuvedených jinde
nastavı́me výchozı́ bránu pro pakety ze
M
M
C.4
MECHANISMUS IPROUTE2 (PŘÍKAZ IP) – ADRESY, SÍŤ, SMĚROVÁNÍ
263
do tabulky 10 (ISPprvni) jsme
přidali nový záznam – pro vše, co bude směrováno podle této tabulky, platı́ výchozı́ brána
10.1.1.1, ke které se dostaneme přes rozhranı́ eth1
ip route add default via 10.1.1.1 dev eth1 table 10
ip route add default via 10.32.32.1 dev eth2 table 20
podobně pro dalšı́ tabulku,
určı́me bránu a port
ip rule add from 10.192.0.0/24 table 10
vše, co přijde ze sı́tě se zadanou adresou, bude
směrováno podle tabulky 10
ip rule add from 10.192.128.0/24 table 20
podobně pro dalšı́ sı́t’, určujeme směrovacı́
tabulku
Provoz lze směrovat i podle jiných kritériı́.
Úkoly
1. Najděte seznam směrovacı́ch tabulek (vypište soubor /etc/iproute2/rt_tables). Dále
zjistěte, jak jsou nastavena přı́stupová oprávněnı́ k tomuto souboru:
• ls -la /etc/iproute2/rt_tables vypı́še základnı́ oprávněnı́,
• getfacl /etc/iproute2/rt_tables vypı́še seznamy POSIX ACL, které můžeme
brát jako nástavbu základnı́ch oprávněnı́ upřesňujı́cı́ práva konkrétnı́ch uživatelů a skupin (nejen vlastnı́ka a skupiny souboru),
• lsattr /etc/iproute2/rt_tables zobrazı́ atributy souboru v daném souborovém
systému,
• getfattr /etc/iproute2/rt_tables zobrazı́ rozšı́řené atributy souboru.
2. Vypište hlavnı́ směrovacı́ tabulku a porovnejte s výpisem pomocı́ přı́kazu route (je v předchozı́ sekci). Dále vypište lokálnı́ směrovacı́ tabulku, a pokud existujı́ dalšı́, také je vypište.
Najděte adresu výchozı́ brány. Jak byste ji změnili?
3. Vypište seznam definovaných politik (zásad, pravidel) pro směrovánı́. Všimněte si, na které
směrovacı́ tabulky tyto zásady odkazujı́.
C.4.3
Objevovánı́ sı́tě
Protokol IPv4 použı́vá pro objevovánı́ sı́tě protokol ARP, u IPv6 to je NDP (Neighbour Discovery Protocol), respektive mechanismus NDis (Network Discovery). Pro práci s „okolı́m“ máme
k dispozici dalšı́ vnitřnı́ přı́kaz přı́kazu ip.
Jednotlivé uzly sı́tě mohou být v některém z následujı́cı́ch stavů (označujeme NUD, Neighbour
Unreachability Detection):
• none – stav „nevyplněn“
• noarp – soused je platný a dosažitelný, nemá být ověřován ARP dotazy, záznam má stanovenu
dobu platnosti (po této době je vyřazen z ARP cache)
• permanent – podobně jako noarp je platný, dosažitelný a nemá být ověřován ARP dotazy, nemá
stanovenu dobu platnosti (tj. platnost neomezená), z tabulky sousedů smı́ být odstraněn jen
administrátorem
C.4
MECHANISMUS IPROUTE2 (PŘÍKAZ IP) – ADRESY, SÍŤ, SMĚROVÁNÍ
264
• reachable – soused je platný a dosažitelný, záznam má stanovenu dobu platnosti (životnost
záznamu), po uplynutı́ této doby bude opětovně dynamicky zjišt’ován ARP dotazem (tento
stav je běžný pro dynamicky zjišt’ované sousedy)
• incomplete – soused je „zjišt’ován“, proces objevovánı́ souseda nenı́ ukončen (obvykle znamená, že k dané IP adrese, na kterou se dotazuje některý protokol vyššı́ vrstvy, neexistuje
žádný záznam)
• stale – soused je považován za platného, ale jeho dosažitelnost musı́ být neustále ověřována
(po každém použitı́ záznamu tento záznam přecházı́ do stavu delay)
• delay – je třeba záznam ověřit, byl naplánován ARP dotaz na tuto adresu, pokud tento soused
bude generovat provoz, stav se měnı́ zpět na stale
• probe – sousedovi s přı́znakem delay vypršel limit na odpověd’ (nebo generovánı́ provozu),
jádro odešle ARP dotaz
• failed – ARP dotaz selhal, záznam nenı́ platný
Většina sousedů je ve stavu reachable, stale nebo permanent.
Pokud je soused ve stavu stale a je připojen, pak v tomto stavu trávı́ většinu času (občas
přecházı́ do delay). Pokud je soused ve stavu reachable, obvykle v něm zůstává, ale když ho odpojı́me,
postupně přecházı́ mezi stavy reachable–stale–delay–probe–failed, dotaz na danou IP adresu pak končı́
výpisem stavu incomplete.
Přı́kazy:
pracujeme s vazbami mezi adresami L2 a L3 (tj. MAC a IP) ve stejné sı́ti (tj.
se „sousedy“, odtud klı́čové slovo), v přı́padě IPv4 jde o práci s ARP tabulkami, u IPv6 jsou
to neighbour tabulky (slovo neighbour lze zkracovat na neighbor, neigh nebo n)
ip neighbour ...
ip
ip
ip
ip
neigh show
zobrazı́ momentálnı́ stav ARP nebo NDP cache (tabulky)
neigh show dev eth0
zobrazı́ seznam sousedů připojených k rozhranı́ eth0
neigh show to 193.168.200/24
zobrazı́ se info o sousedech ze zadané podsı́tě
-s neigh show to 10.0.0.1
podrobnějšı́ statistika souseda se zadanou IP adresou
(zjistı́me navı́c počet uživatelů záznamu a dále před kolika sekundami byl záznam
použit/potvrzen/aktualizován)
ip neigh show nud permanent
zobrazı́ všechny sousedy, jejichž stav je „permanent“,
obvykle jde o ručně přidané sousedy
ip neigh add 193.168.200.1 lladdr 00:0a:1b:2c:3d:4e dev eth2 nud permanent
přidali jsme do ARP tabulky statický záznam o sousedovi (zadáváme IP adresu, MAC
adresu – Link Layer Addr, rozhranı́, přes které je soused dosažitelný, a pak stav)
pokud přidáváme nový záznam, můžeme hodnotu nud nastavit na jednu z hodnot
noarp, reachable, permanent nebo stale, čı́mž také určı́me, zda záznam bude mı́t
omezenou platnost a jestli má být ověřován
ip neigh del 193.168.200.1 dev eth2
odstranili jsme záznam z tabulky
Přı́klad
Zatı́mco mezilehlé sı́t’ové zařı́zenı́ (router, switch) má sousedů poměrně hodně, koncové zařı́zenı́
připojené přes ethernet (konektor RJ-45) má obvykle jediného souseda – router nebo switch.
$
C.4
MECHANISMUS IPROUTE2 (PŘÍKAZ IP) – ADRESY, SÍŤ, SMĚROVÁNÍ
265
Na koncovém zařı́zenı́ vypadajı́ výpisy následovně:
sarka@notebook:/home/sarka# ip neigh show
10.0.0.138 dev eth0 lladdr 00:21:63:e2:0f:98 STALE
sarka@notebook:/home/sarka# ip -s neigh show
10.0.0.138 dev eth0 lladdr 00:21:63:e2:0f:98 ref 12 used 172/172/152 STALE
Druhý výpis obsahuje podrobnějšı́ údaje o sousedovi (což je router, jehož uvnitř viditelná IP adresa
je 10.0.0.138). Na řádku postupně vidı́me IP adresu, rozhranı́, přes které jsme k sousedovi připojeni,
dále počet odkazů na toto připojenı́ a tři časové údaje (počet sekund od chvı́le, kdy bylo připojenı́
naposledy použito/potvrzeno/aktualizováno).
Úkoly
1. Zobrazte seznam svých sousedů (ARP/NDP cache). Pokud máte vı́ce aktivnı́ch sı́t’ových rozhranı́, pak zvlášt’ pro několik rozhranı́. Vyzkoušejte zobrazenı́ se statistikou (podrobnějšı́mi
informacemi) o daném propojenı́.
2. Přidejte do ARP cache „virtuálnı́ho“ souseda, jehož MAC adresa (tj. link layer) je 03:00:01:a5:b6:c7,
IP adresa 10.0.0.12, je připojen na rozhranı́ eth0 (i když v reálu nenı́), stav spojenı́ permanent.
Pak vypište seznam sousedů a zkontrolujte, zda je v seznamu přidaný záznam. Dále vypište
seznam sousedů, jejichž připojenı́ je ve stavu permanent. Potom nový záznam odstraňte a opět
zkontrolujte, jestli záznam opravdu zmizel.
3. Zopakujte si celý postup aktivace sı́t’ového rozhranı́ (zkompletujte přı́kazy):
•
•
•
•
•
C.4.4
pokud je rozhranı́ aktivnı́, je třeba ho deaktivovat
nastavı́me IP adresu (včetně délky prefixu)
nastavı́me bránu
nastavı́me adresu DNS serveru
aktivujeme rozhranı́
Tunely
Mechanismus iproute2 sloužı́ také k vytvářenı́ IP/IP tunelů. Lze použı́t pro vytvořenı́ VPN
tunelu, zapouzdřenı́ IPv6 do IPv4 na cestě bez podpory IPv6, vytvořenı́ mostu mezi vı́ce sı́t’ovými
rozhranı́mi na jednom zařı́zenı́ patřı́cı́mi do různých sı́tı́, vytvořenı́ vzdáleného mostu, apod.
Je možné pracovat s několika různými typy tunelů, ale předně musı́me mı́t v jádře načten
přı́slušný modul pro daný typ tunelu. Nejběžnějšı́ jsou
• IP-IP tunely (modul ipip) – dokážou zapouzdřit jen unicast IP datagramy (tj. tunely typu
point-to-point),
• GRE tunely (modul ip_gre) – zapouzdřujı́ také jiné typy paketů, a to spojenı́ unicast i multicast, jsou poměrně hodně použı́vány,
• SIT tunely (Simple Internet Transition, modul ipv6) – k propojenı́ IPv6 sı́tı́ přes IPv4 sı́tě.
M
M
C.4
MECHANISMUS IPROUTE2 (PŘÍKAZ IP) – ADRESY, SÍŤ, SMĚROVÁNÍ
266
V přı́kazech pro práci s tunely se typ tunelu projevuje v povinném parametru mode (tedy mód
tunelu), určuje způsob, jakým se má s transportovaným paketem zacházet (předevšı́m jak a do
čeho se má zapouzdřit). Použı́váme následujı́cı́ přı́kaz:
ip tunnel ...
zabezpečený přenos, tunelovánı́
zobrazı́ informaci o vytvořeném tunelu s názvem mujtunel,
zobrazı́ se obvykle typ (mód) tunelu, vzdálená a mı́stnı́ IP adresa (konce tunelu), pak
dalšı́ zadané (nepovinné) vlastnosti jako název sı́t’ového rozhranı́, ze kterého tunel vede,
hodnota TTL pro pakety jdoucı́ do tunelu, hodnota TOS, apod. (vpodstatě se zobrazuje
to, co se zadalo při vytvořenı́ tunelu)
ip -s tunnel show mujtunel
kromě výše uvedených informacı́ se zobrazı́ také statistika tunelu podobná výstupu přı́kazu ip -s link show (jde vlastně o stejný typ informace, jen se mı́sto sı́t’ového rozhranı́ týká tunelu), viz výstup na straně 257
ip tunnel show mujtunel
ip tunnel add mujtunel mode ipip local 194.50.20.42 remote
195.84.152.140 ttl 32 vytvořili jsme nový tunel typu IP-IP se zadanou mı́stnı́
a vzdálenou adresou a hodnotou TTL
ip tunnel del mujtunel
zrušili jsme tunel
ip tunnel change mujtunel remote 195.35.84.15
změna nastavenı́ tunelu (změnili
jsme vzdálenou adresu)
Abychom mohli tyto přı́kazy použı́vat, musı́me mı́t předně v jádře načten přı́slušný modul.
Přı́klad
Ukážeme si vytvořenı́ GRE tunelu, který je zřejmě nejčastěji použı́ván (protože dokáže zabalit
cokoliv, zvládá i multicast a je všeobecně podporován prakticky v čemkoliv). Předpokládejme,
že chceme propojit tunelem dvě vzdálené sı́tě (patřı́cı́ stejné firmě), ve kterých jsou soukromé IP
adresy. Rozsahy adres v těchto sı́tı́ch by se neměly překrývat, aby nedocházelo k problémům při
směrovánı́.
Původnı́ stav:
eth0
(10.0.1.1)
eth0
(10.0.2.1)
Router 1
Router 2
wan0
(194.84.21.52)
wan0
(194.84.21.54)
Internet
Sı́t’1
10.0.1.0/24
eth0
(10.0.1.1)
Router 1
Sı́t’2
10.0.2.0/24
sit1
(10.0.2.254)
Sı́t’2
10.0.2.0/24
sit2
(10.0.1.254)
Sı́t’1
10.0.1.0/24
Po vytvořenı́ tunelu:
wan0
(194.84.21.52)
eth0
(10.0.2.1)
Router 2
wan0
(194.84.21.54)
Internet
Obrázek C.2: Vytvořenı́ GRE tunelu
Situaci včetně adres máme znázorněnu na obrázku C.2 vlevo. Podle prefixů poznáme, že rozsahy
adres v sı́tı́ch se nepřekrývajı́. U routerů, přes které se sı́tě připojujı́ do Internetu, vidı́me také adresu
$
C.4
MECHANISMUS IPROUTE2 (PŘÍKAZ IP) – ADRESY, SÍŤ, SMĚROVÁNÍ
267
viditelnou uvnitř (je z rozsahu adres vnitřnı́ sı́tě) a adresu viditelnou vně (tu máme přidělenou
ISP providerem). Aby bylo možné vybudovat funkčnı́ tunel, musı́me všechny tyto adresy znát
(zadávajı́ se do přı́kazů).
Na routeru Router1 zadáme tyto přı́kazy:
modeprobe ip_gre
načteme do jádra modul pro podporu GRE tunelů
ip tunnel add sit2 mode gre local 194.84.21.52 remote 194.84.21.54 ttl 255
vytvořı́me tunel, všimněte si vyššı́ hodnoty TTL (nevı́me, přes kolik routerů tunel vede, tedy
je lepšı́ použı́t vyššı́ hodnotu)
ip link set sit2 up
aktivujeme nové virtuálnı́ rozhranı́ (tedy náš tunel)
přidělı́me našemu konci tunelu IP adresu, měla by být
viditelná v našı́ sı́ti a neměla by být použita pro jiné zařı́zenı́ (to si musı́me pohlı́dat, přı́padně
upravit rozsahy adres)
ip addr add 10.0.1.254 dev sit2
do směrovacı́ tabulky přidáme pravidlo pro směrovánı́ do sı́tě za tunelem, bližšı́ konec tunelu bude fungovat jako brána
ip route add 10.0.2.0/24 dev sit2
Obdobně postupujeme na routeru Router2:
modeprobe ip_gre
načteme do jádra modul pro podporu GRE tunelů
ip tunnel add sit1 mode gre local 194.84.21.54 remote 194.84.21.52 ttl 255
vytvořı́me tunel
ip link set sit1 up
aktivujeme nové virtuálnı́ rozhranı́ (tedy náš tunel)
ip addr add 10.0.2.254 dev sit1
přidělı́me našemu konci tunelu IP adresu
ip route add 10.0.1.0/24 dev sit1
do směrovacı́ tabulky přidáme pravidlo pro směro-
vánı́ do sı́tě za tunelem
Na obrázku C.2 vpravo je znázorněna situace po vytvořenı́ tunelu. Pak bychom měli vyzkoušet,
zda jsou pakety doručovány správně, napřı́klad na prvnı́m routeru vyzkoušı́me ping na druhý
konec tunelu:
ping 10.0.2.154
Pokud nefunguje, je možné, že pakety byly zahozeny některým firewallem. Pokud jsou povoleny ICMP pakety a nemáme žádné restrikce na námi vytvořené virtuálnı́ rozhranı́, měli bychom
ještě zkontrolovat, zda mohou procházet GRE pakety (protokol čı́slo 47), napřı́klad v chainu FORWARD bychom protokol 47 povolili takto (podrobnosti najdeme v samostatné sekci o firewallu
v Linuxu):
iptables -A FORWARD -p 47 -j ACCEPT
Dále může být problém v zakázánı́ čı́sla portu použı́vaného tunelem, tedy pokud nepomůže
povolenı́ protokolu 47, můžeme vyzkoušet
iptables -A FORWARD -p tcp --dport 1723 -j ACCEPT
Přı́padně v jiných tabulkách nebo s dalšı́mi parametry, podle momentálnı́ho nastavenı́ firewallu.
Měli bychom si uvědomit, že GRE tunely nejsou šifrovány.
C.5
PŘEKLAD NÁZVŮ
268
Dalšı́ věc, kterou bychom měli promyslet při vytvářenı́ (jakéhokoliv) tunelu, je hodnota MTU
(tj. jak velký IP datagram může projı́t, jeho max. velikost). Pokud paket vstupuje do tunelu, přidávajı́ se dalšı́ hlavičky (minimálně jedna, podle typu tunelu). Pokud máme špatně nastavenou
velikost MTU, pak je typickým projevem nedoručovánı́ paketů přes tunel (i když ping funguje
normálně). Kdyby se všichni administrátoři uzlů na cestě řı́dili doporučenı́mi RFC, pak by to problém nebyl (když na uzel dojde paket s velikostı́ nad MTU, pošle uzel zpět ICMP zprávu o nutnosti
fragmentace, ale pokud jsou někde pakety s ICMP zprávami zahazovány, zpráva nedojde a paket
nebude znovu odeslán fragmentovaný). Běžná hodnota MTU je kolem 1500, u tunelu bychom ji
měli nastavit na hodnotu něco nad 1200.
Dalšı́ informace o tunelech:
•
•
•
•
•
http://www.root.cz/clanky/tuneluji-tunelujes-tunelujeme-jak-a-k-cemu/
http://tier.cs.berkeley.edu/drupal/howto/ip-tunnel-using-gre-on-linux
http://kovyrin.net/2006/03/17/how-to-create-ip-ip-tunnel-between-freebsd-and-linux/
http://www.abclinuxu.cz/clanky/site/ipv6-konfigurace-site-tunely
IP-IP tunel: http://fengnet.com/book/ICUNA/ch11lev1sec5.html
GRE tunel: http://fengnet.com/book/ICUNA/ch11lev1sec6.html
• http://www.informit.com/articles/article.aspx?p=29039&seqNum=3
• http://www.linuxfoundation.org/collaborate/workgroups/networking/tunneling
• http://www.policyrouting.org/iproute2.doc.html
L
V této sekci nejsou popsány všechny možnosti mechanismu iproute2. Existujı́ napřı́klad vnitřnı́
přı́kazy pro monitoring, práci s multicast adresami, multicast směrovánı́, práce s různými směrovacı́mi protokoly včetně OSPF, atd.
Dalšı́ informace o použı́vánı́ mechanismu iproute2 (velmi užitečné tutoriály a jiné návody):
•
•
•
•
•
http://linux-ip.net/gl/ip-cref/
http://linux-ip.net/html/index.html
http://www.policyrouting.org/iproute2-toc.html
http://lartc.org/howto/index.html
http://www.faqs.org/docs/Linux-mini/Remote-Bridging.html
A dále samozřejmě man ip použité v Linuxu nebo na Googlu.
C.5
Překlad názvů
C.5.1
Název počı́tače
Také v Linuxu se pracuje s názvy počı́tačů. Předně je důležité vědět, jak zjistit název svého počı́tače.
Pro tyto účely použı́váme přı́kaz hostname a jeho varianty:
(bez parametrů) vypı́še název našeho počı́tače; stejný údaj, jak vı́me, zjistı́me také
v souboru /etc/sysconfig/network nebo přı́padně /etc/hostname, pokud existuje
hostname
nastavı́me název našeho počı́tače, potřebujeme vyššı́ přı́stupová oprávněnı́ (tudı́ž použijeme přı́kaz su nebo sudo, podle toho, který naše distribuce podporuje)
hostname novynazev
$
C.5
PŘEKLAD NÁZVŮ
269
nastavı́me název našeho počı́tače, tento název je uložen v zadaném souboru, taktéž potřebujeme vyššı́ přı́stupová oprávněnı́
hostname -F soubor
(bez parametrů) vypı́še název našı́ NIS domény (pozor, ne DNS; NIS je obdoba
Active Directory pro unixové systémy, postupně nahrazován různými implementacemi LDAP),
pokud ovšem máme NIS vytvořen
domainname
(bez parametrů) vypı́še název našı́ DNS domény (to je to, co v plném názvu
počı́tače následuje za prvnı́ tečkou), podobně hostname -d
dnsdomainname
C.5.2
Resolver a soubor resolv.conf
Konfigurace resolveru (tj. části mechanismu překladu adres, která zadává dotazy, je na každém
klientovi) je tedy v souboru /etc/resolv.conf. V tomto souboru mohou být záznamy několika
typů:
• nameserver adresa doménový server, obvykle zadaný IP adresou, takových záznamů
může být vı́ce (pak je ale důležité jejich pořadı́, jako prvnı́ dáme ten server, na který se
chceme obracet nejčastěji, tj. obvykle nejbližšı́)
• domain doména název domény, zároveň s názvem našeho počı́tače tvořı́ plné jméno počı́tače, pokud nejsme v žádné sı́t’ové doméně, pak je zde záznam
domain localdomain
• search doména doména ... seznam domén, které jsou při vyhledávánı́ počı́tače s určitým
názvem přidávány pro zkompletovánı́ plného jména počı́tače (před odeslánı́m dotazu DNS
serveru), napřı́klad pokud je v seznamu doména fpf.slu.cz, pak název uzlu axpsu lze
doplnit na axpsu.fpf.slu.cz
• options volby
napřı́klad
volby pro konfiguraci resolveru (uvádějı́ se všechny na jednom řádku!),
– počet pokusů pro vyřı́zenı́ DNS dotazu na každý známý DNS server se nastavuje takto:
options attempts:3
(výchozı́ hodnota je 2, zvýšili jsme počet pokusů, zřejmě máme méně spolehlivé spojenı́
k DNS serverům, obvykle nenı́ nutné měnit)
– podporu IPv6 zapneme volbou inet6,
– volba no-check-names se použı́vá předevšı́m tehdy, když máme v sı́ti také počı́tače
s nainstalovanými Windows; Windows totiž často porušujı́ RFC 952, které zakazuje
použı́vat v názvech domén jakékoliv jiné znaky než základnı́ ASCII (pı́smena, čı́slice,
pomlčky) a bez použitı́ této volby by uzly s Windows s názvem obsahujı́cı́m nedovolené
názvy nebyly dostupné,
– atd.
Pokud chceme použı́t vı́ce voleb, musı́me je umı́stit na jeden řádek, napřı́klad
options attempts:1 ipv6 no-check-names
Záznamy typu domain a search by teoreticky neměly být oba najednou použity (dá se řı́ct, že
domain je speciálnı́m přı́padem search, ve kterém zadáváme jen jednu doménu). Prakticky se
vyskytovat mohou, ale při načı́tánı́ konfigurace se bere v úvahu jen poslednı́ uvedený z těchto
záznamů.
$
C.5
PŘEKLAD NÁZVŮ
270
V Linuxu se běžně použı́vá DNS server BIND běžı́cı́ jako démon named, jeho popis je však
nad rámec těchto skript. Postup konfigurace včetně ukázkových konfiguračnı́ch souborů najdeme
napřı́klad v knize [10] ze seznamu literatury.
C.5.3
Testovánı́ DNS
Podobně jako ve Windows, i v Linuxu máme k dispozici přı́kaz nslookup, který lze použı́vat
v běžném i interaktivnı́m režimu. Způsob využı́vánı́ je podobný jako ve Windows, tedy běžný
režim funguje takto:
nslookup www.google.com
nslookup 209.85.148.99
$
takto zjistı́me IP adresy zadaného serveru
zjistı́me jméno přislušejı́cı́ zadané IP adrese
Do interaktivnı́ho režimu se dostaneme jednı́m ze dvou způsobů:
• jednoduše zadánı́m přı́kazu bez parametrů,
• přı́kaz s jediným parametrem – názvem DNS serveru, před který napı́šeme pomlčku, aby byl
odlišitelný od názvu, který chceme přeložit.
Název DNS serveru zadáváme tehdy, když výchozı́ server neposkytuje autorizované odpovědi
a nevı́me jistě, zda v jeho cache jsou správné záznamy. Pokud už jsme v interaktivnı́m režimu,
nastavı́me použı́vaný DNS server přı́kazem server adresa (zadáme adresu DNS serveru).
Vnitřnı́ přı́kazy vpodstatě odpovı́dajı́ tomu, co jsme si ukazovali u přı́kazu pro Windows, tedy
napřı́klad, překlady podobné jako v neinteraktivnı́m režimu, zobrazenı́ parametrů, určenı́ typu
dotazu na DNS server, zobrazenı́ hostitelů (uzlů) v doméně, určenı́ typu zobrazovaných hostitelů
(výchozı́ je typ A) atd. Z interaktivnı́ho režimu se dostaneme přı́kazem exit.
Podobný účel má přı́kaz dig (zkratka z Domain Information Gropher). Tento nástroj je u administrátorů oblı́benějšı́ než nslookup, zvláště pro účely testovánı́ nastavenı́ DNS serverů.
$
zı́skáme vyčerpávajı́cı́ odpověd’ se všemi potřebnými informacemi, kromě
žádané IP adresy (resp. vı́ce adres) napřı́klad adresu DNS serveru, který odpověděl, jak
dlouho trvala komunikace, ke každé adrese informaci o třı́dě záznamu (kde je platný), typ
záznamu, atd.
dig www.root.cz
reverznı́ dotaz, chceme doménový název k zadané IP adrese
dig www.root.cz +short
krátká odpověd’ ve stylu nslookup (tj. vypı́še se pouze IP adresa)
dig -x 91.213.160.118
chceme všechny typy záznamů týkajı́cı́ se daného serveru (výchozı́ jsou
záznamy typu A, tj. IPv4 adresy)
dig google.com ANY
vypı́šou se doménová jména DNS serverů v zadané doméně, jejich
IP adresy můžeme zjistit následným dotazem podle vypsaných doménových jmen
dig seznam.cz NS +short
Přı́klad
Vyzkoušı́me práci s přı́kazem dig:
sarka@notebook:˜$ dig www.root.cz
; <<>> DiG 9.7.1-P2 <<>> www.root.cz
;; global options: +cmd
;; Got answer:
M
C.5
PŘEKLAD NÁZVŮ
271
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 55084
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 2
;; QUESTION SECTION:
;www.root.cz. IN A
;; ANSWER SECTION:
www.root.cz. 5 IN CNAME root.cz.
root.cz. 5 IN A˜91.213.160.118
;; AUTHORITY SECTION:
root.cz. 5 IN NS ns.iinfo.cz.
root.cz. 5 IN NS ns6.adminit.cz.
;; ADDITIONAL SECTION:
ns6.adminit.cz. 5 IN A˜81.91.85.230
ns6.adminit.cz. 5 IN AAAA 2001:1568:b:149::1
;;
;;
;;
;;
Query time: 18 msec
SERVER: 192.168.184.2#53(192.168.184.2)
WHEN: Mon Jul 11 07:09:03 2011
MSG SIZE rcvd: 152
Ve výpisu jsou tyto položky:
• v záhlavı́ výpisu jsou informace o tom, jakým způsobem byl přı́kaz volán a kterou máme verzi,
dále část s početnı́mi údaji (čı́sla odpovı́dajı́ počtům záznamů uvedených v následujı́cı́ch
sekcı́ch), přı́znaky apod.,
• sekce „Question section“ obsahujı́cı́ údaje dotazu (zde doménová adresa, třı́da „INternet“,
typ záznamu „A“)
• sekce „Answer section“ obsahuje údaje z odpovědi (v záhlavı́ máme uvedeny dva záznamy
v odpovědi, proto zde budou dva řádky obsahujı́cı́ doménový název, TTL, třı́du, typ záznamu
a hodnotu záznamu),
• v sekci „Authority section“ máme seznam doménových adres DNS serverů, které o dotazovaném názvu poskytujı́ autoritativnı́ odpověd’ (pokud zı́skaným informacı́m nedůvěřujeme,
můžeme se zeptat některého z těchto serverů),
• v následujı́cı́ sekci najdeme IP adresy DNS serverů uvedených v předchozı́ sekci,
• výpis končı́ statistickými informacemi.
Ted’ podobně zjistı́me informace o hostiteli mail.google.com, ale zeptáme se jiného DNS serveru.
Název DNS serveru musı́me uvést symbolem „zavináče“, aby bylo zřejmé, že se nejedná o název,
který má být přeložen, za zavináčem můžeme zadat doménovou nebo IP adresu. Zde se (shodou
okolnostı́) dotážeme DNS serveru poskytovaného Googlem:
sarka@notebook:˜$ dig @8.8.4.4 mail.google.com
; <<>> DiG 9.7.1-P2 <<>> @8.8.4.4 mail.google.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20135
M
C.5
PŘEKLAD NÁZVŮ
272
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;mail.google.com. IN A
;; ANSWER SECTION:
mail.google.com. 86399 IN CNAME
googlemail.l.google.com. 299 IN
googlemail.l.google.com. 299 IN
googlemail.l.google.com. 299 IN
googlemail.l.google.com. 299 IN
;;
;;
;;
;;
googlemail.l.google.com.
A˜74.125.232.246
A˜74.125.232.248
A˜74.125.232.247
A˜74.125.232.245
Query time: 56 msec
SERVER: 8.8.4.4#53(8.8.4.4)
WHEN: Mon Jul 11 07:21:14 2011
MSG SIZE rcvd: 124
Je zřejmé, že odpověd’ jsme sice dostali, ale vyžádali jsme si ji od serveru, který nenı́ pro daný
záznam autoritativnı́ (údaje bere ze své cache nebo se dotazuje jinde).
Dále vyzkoušı́me zkrácený výpis (použijeme parametr +short), chceme DNS servery v doméně
seznam.cz.
sarka@notebook:˜$ dig seznam.cz NS +short
ns.seznam.cz
ms.seznam.cz
M
Přı́klad
Přı́kaz dig můžeme také použı́t pro zjištěnı́ celé trasy našeho dotazu:
sarka@notebook:˜$ dig seznam.cz +trace
; <<>> DiG 9.7.1-P2 <<>> seznam.cz +trace
;; global options: +cmd
. 5 IN NS i.root-servers.net.
. 5 IN NS j.root-servers.net.
. 5 IN NS k.root-servers.net.
. 5 IN NS l.root-servers.net.
. 5 IN NS m.root-servers.net.
. 5 IN NS a.root-servers.net.
. 5 IN NS b.root-servers.net.
. 5 IN NS c.root-servers.net.
. 5 IN NS d.root-servers.net.
. 5 IN NS e.root-servers.net.
. 5 IN NS f.root-servers.net.
. 5 IN NS g.root-servers.net.
. 5 IN NS h.root-servers.net.
;; Received 272 bytes from 192.168.184.2#53(192.168.184.2) in 12 ms
cz.
cz.
cz.
cz.
cz.
172800
172800
172800
172800
172800
IN
IN
IN
IN
IN
NS
NS
NS
NS
NS
f.ns.nic.cz.
d.ns.nic.cz.
a.ns.nic.cz.
c.ns.nic.cz.
b.ns.nic.cz.
M
C.6
FIREWALL V LINUXU
273
;; Received 334 bytes from 192.5.5.241#53(f.root-servers.net) in 10 ms
seznam.cz. 18000 IN NS ms.seznam.cz.
seznam.cz. 18000 IN NS ns.seznam.cz.
;; Received 93 bytes from 194.0.14.1#53(c.ns.nic.cz) in 43 ms
seznam.cz. 300 IN A˜77.75.72.3
;; Received 43 bytes from 77.75.77.77#53(ms.seznam.cz) in 9 ms
Pokud nezadáme DNS server, kterému má být zaslán dotaz, přı́kaz dig použije DNS servery
uvedené v souboru /etc/resolv.conf.
C.5.4
Zjistěnı́ informacı́ o doméně
Pokud chceme zjistit informace o určité doméně, použijeme přı́kaz whois. Tento přı́kaz nám vypı́še veškeré dostupné informace o doméně – kontakt na vlastnı́ka domény, doba, na kterou je
doména registrována apod. Přı́kaz se hodı́ napřı́klad tehdy, když chceme registrovat vlastnı́ doménu a chceme si ověřit, zda už nenı́ někým registrována, a nebo pokud z některé domény přicházı́
malware a chceme upozornit vlastnı́ka, aby „si udělal pořádek“.
$
zjistı́me údaje o zadané doméně
whois -r koupaliste.cz
výpis bude odlišný, ale základnı́ informace budou shodné (uvedeným přepı́načem jsme si vyžádali informace z WHOIS databáze RIPE obsahujı́cı́ předevšı́m
evropské servery)
whois koupaliste.cz
V manuálové stránce přı́kazu bychom zjistili přepı́nače pro dalšı́ možné WHOIS databáze (pozor,
manuálové stránky různých unixových systémů se lišı́ v tom, jak moc jsou podrobné při komentovánı́ seznamu přepı́načů tohoto přı́kazu, pak je dobré použı́t manuálové stránky na Internetu).
Dalšı́ informace o doménách v Linuxu:
• http://www.madboa.com/geek/dig/
• http://www.brennan.id.au/08-Domain Name System BIND.html
Úkoly
1. Zjistěte název svého počı́tače. Dále zjistěte, jaké DNS servery použı́váte.
2. Zobrazte přı́kazem dig podrobnosti o serveru seznam.cz, a to všechny typy DNS záznamů
(tj. ANY). Srovnejte s výpisem pomocı́ přı́kazu nslookup.
3. To, že se ptáme jiného DNS serveru než je ten od našeho poskytovatele, nemusı́ znamenat,
že dostaneme komplexnějšı́ informace. Vyzkoušejte dotaz na doménu root.cz postupně bez
zadánı́ DNS serveru a pak se zadánı́m některého DNS serveru (napřı́klad ns.seznam.cz
nebo 8.8.4.4). Pokud přı́kaz zkoušı́te v sı́ti některé vysoké školy, kde se učı́ Linux, tak bude
výstup od výchozı́ho serveru komplexnějšı́.
4. Zjistěte údaje o několika doménách druhé úrovně podle vlastnı́ho výběru (napřı́klad seznam.cz,
slu.cz, apod.).
C.6
C.6
FIREWALL V LINUXU
274
Firewall v Linuxu
V linuxových jádrech (od verze 2.4) najdeme firewall NetFilter, což je obousměrný stavový firewall
(provádı́ funkce SPI).12 NetFilter dokáže filtrovat pakety podle údajů v hlavičkách protokolů TCP,
UDP, IP, ICMP a také dalšı́ch uvedených v souboru /etc/protocols, je použitelný pro mnoho
činnostı́ souvisejı́cı́ch se zpracovánı́m paketů, včetně mechanismu NAT.
P
Jedná se o modul jádra, ke kterému se nepřistupuje přı́mo, ale přes obslužný program iptables.13
Takže pozor – firewall je NetFilter, obslužný program běžı́cı́ v uživatelském režimu je iptables.
C.6.1
Princip firewallu
Základem je tabulka (table), v každé tabulce je několik řetězců chain (čti: [čejn]), které již obsahujı́
pravidla uplatňovaná na pakety (tato pravidla jsou zřetězená a na paket se uplatňujı́ postupně,
dokud se nenajde „pasujı́cı́ “ pravidlo, proto se tomu řı́ká chain). Tabulka obvykle určuje, co konkrétně se má dı́t (napřı́klad jen filtrovánı́, nebo překlad adres či změna některých dalšı́ch údajů
v záhlavı́ procházejı́cı́ho paketu), chain obvykle určuje, kdy se to má dı́t (napřı́klad na vstupu do
sı́tě, výstupu, při přeposı́lánı́ mezi jinými dvěma uzly, před směrovánı́m, po směrovánı́ apod.).
P
Standardně jsou definovány tyto tabulky (v přı́kazu iptables se před název tabulky dává
přepı́nač -t):
•
•
•
•
filter (výchozı́)
mangle (pro transformace – upravujeme záhlavı́, hodnoty TTL, pole TOS/QoS, apod.)
nat (pro mechanismus NAT)
raw a conntrack jsou pomocné mechanismy označovánı́ (marking) paketů pro pozdějšı́ zpracovánı́ a stavového filtru (SPI), obvykle je třeba jejich funkcionalitu do jádra doplnit (načı́st
moduly)
V každé tabulce je tedy několik chainů (řetězců), a to:
• Tabulka filter obsahuje standardně tyto chainy:
– chain INPUT se uplatnı́ na pakety, které do systému přicházejı́,
– chain OUTPUT se uplatnı́ na pakety, které ze systému odcházejı́,
– chain FORWARD je určen pro pakety, které nejsou vytvořeny uvnitř systému a ani pro
něj nejsou určeny, předávajı́ se jen mezi rozhranı́mi systému (průchozı́ pakety), typicky
v zařı́zenı́, které sloužı́ jako směrovač,
pokud jde paket do chainu FORWARD, nepadne už do žádného jiného chainu.
• Tabulka nat obsahuje standardně tyto chainy:
– chain PREROUTING pro přı́chozı́ pakety, na které se má použı́t DNAT (tj. má se přeložit
cı́lová adresa, a to ještě před vlastnı́m směrovánı́m),
12
Stavové firewally dokážou pracovat samozřejmě nejen se stavovými, ale i s nestavovými protokoly (jako je napřı́klad
UDP), přestože se v některých publikacı́ch můžeme dočı́st, že ne.
13
Ve staršı́ch jádrech, se kterými se (doufejme) už nesetkáme, se použı́val firewall IPChains se stejnojmenným obslužným programem (ipchains).
P
C.6
FIREWALL V LINUXU
275
– chain POSTROUTING pro odchozı́ pakety, na které se má použı́t SNAT (překládá se
zdrojová adresa, až po směrovánı́),
– chain OUTPUT pro odchozı́ pakety, kdy se má modifikace provést ještě před dalšı́m
zpracovánı́m.
• Tabulka mangle obsahuje standardně chainy pojmenované jako všechny, které jsou uvedeny
u předchozı́ch tabulek (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING) s tı́m
rozdı́lem, že v nich najdeme pravidla modifikujı́cı́ i jiná pole záhlavı́ než jen ta adresová.
V tabulkách si můžeme vytvořit dalšı́ chainy (uživatelsky definované), nemusı́me zůstat jen u standardnı́ch, přı́padně nové tabulky. Nové tabulky se však často přidávajı́ jako dalšı́ moduly jádra.
raw PREROUTE
nat POSTROUTE (SNAT)
[conntrack PREROUTE]
mangle POSTROUTE
g
in
w
r
mangle PREROUTE
ard
nat PREROUTE (DNAT)
směrovánı́
směrovánı́
filter OUTPUT
mangle FORWARD
nat OUTPUT (DNAT)
filter FORWARD
mangle OUTPUT
mangle input
[conntrack OUTPUT]
filter input
raw OUTPUT
o d c h o z ı́ p r o v o z
sı́t’
fo
p ř ı́ c h o z ı́ p r o v o z
Na obrázku C.3 je znázorněna dráha paketu mezi jednotlivými tabulkami a chainy. Všimněte
si, že přeposı́lané (forwarded) pakety nedorazı́ do žádného chainu typu INPUT ani OUTPUT.
lokálnı́ proces
Obrázek C.3: Dráha paketu mezi výchozı́mi tabulkami a chainy v Netfilteru
Program iptables umožňuje pracovat s chainy (vytvořit nebo zrušit chain, nastavit výchozı́
politiku) a s jejich obsahem (přidávat a odstraňovat pravidla v chainu, vypsat seznam pravidel).
U pravidel v chainu záležı́ na pořadı́. Každé pravidlo má své pořadové čı́slo. Nová pravidla
můžeme do chainu vkládat na začátek či na konec chainu, a nebo na konkrétnı́ pozici zadanou
pořadovým čı́slem.
C.6
FIREWALL V LINUXU
C.6.2
276
Základnı́ vnitřnı́ přı́kazy a parametry pro filtrovánı́
Ve vnitřnı́ch přı́kazech se použı́vajı́ tzv. targety určujı́cı́ akci, která se má s určeným paketem provést.
Můžeme použı́t tyto targety:
P
• ACCEPT akceptuj, paket má povoleno projı́t, obvykle v tabulce filter,
• DROP zahod’ bez odezvy (tiché zahozenı́), taktéž v tabulce filter,
• REJECT odmı́tni (s odezvou), odešle ICMP zprávu o odmı́tnutı́ (přesněji – o nedostupnosti
adresy) uzlu, od kterého paket přišel, pro tabulku filter,
• DNAT a SNAT patřı́ k tabulce nat, účel je zřejmý – akcı́ je překlad cı́lové nebo zdrojové adresy
na jinou IP adresu, použı́váme při překladu statických adres,
• MASQUERADE také patřı́ k tabulce nat chainu POSTROUTING, u odchozı́ch paketů překládá
celý rozsah vnitřnı́ch (zdrojových) adres na jednu vnějšı́ (sloužı́ ke skrývánı́ lokálnı́ch adres),
narozdı́l od SNAT bývá adres vı́ce a častěji se použı́vá pro PAT (překlad portů), použı́váme
pouze tehdy, když potřebujeme překládat dynamické soukromé adresy,
• TOS a TTL patřı́ k tabulce mangle, měnı́ pole TOS (type of service) a TTL v záhlavı́ paketu,
• MARK a CONNMARK se v tabulce mangle použı́vajı́ pro přidávánı́ značek do záhlavı́ paketů,
• LOG umožňuje logovat informace ze záhlavı́ paketu, použı́vá se obvykle s programem syslog,
• RETURN pokud jsme během vyhodnocovánı́ pravidel odskočili do jiného chainu, tento target
nás vrátı́ zpět,
a dalšı́. Jednotlivé targety obvykle patřı́ ke konkrétnı́ tabulce, tedy když přidáme do jádra dalšı́
modul s tabulkou, přidajı́ se i dalšı́ použitelné targety. Za targety se také považujı́ uživatelsky
definované chainy.
Přı́kaz iptables se použı́vá s nejméně jednı́m parametrem (obvykle vı́ce), což bývá určenı́
tabulky, vnitřnı́ přı́kaz nebo parametr. Obvykle (ne však vždy) zadáváme tabulku, se kterou chceme
v přı́kazu pracovat, k tomu použijeme přepı́nač -t), napřı́klad -t nat. Zde se podı́váme na vnitřnı́
přı́kazy a parametry, které se použı́vajı́ při základnı́m filtrovánı́, v dalšı́ch podsekcı́ch projdeme
dalšı́ (překlady adres, stavový firewall, značenı́ paketů).
Obvykle tedy použı́váme některý vnitřnı́ přı́kaz (pozor, velká pı́smena) představujı́cı́:
-P nebo --policy
určuje výchozı́ zásadu (politiku) pro chain, ve kterém chceme pracovat (pokud na paket nebude pasovat žádné pravidlo chainu, použije se tato politika), za přepı́načem
následuje název chainu a dále target určujı́cı́ akci, která se má provést, výchozı́ politiku lze
určit pouze pro předdefinované chainy, nikoliv pro uživatelsky definované; napřı́klad
iptables -P INPUT -j DROP,
-L nebo --list
iptables
iptables
iptables
iptables
vypisuje seznam všech pravidel v zadaném chainu, napřı́klad
-L
(výpis bývá dlouhý dokonce i na desktopu, všechny tabulky)
-t filter -L -n
-t filter -L -nv
-t filter -L INPUT -n
prvnı́ přı́kaz vypı́še všechna pravidla tabulky filter, nechává IP adresy (nepřekládá na doménové, dı́ky poslednı́mu parametru), druhý přı́kaz udělá totéž, ale ve verbose („upovı́daném“)
módu, tudı́ž se dozvı́me vı́ce, třetı́ přı́kaz vypı́še pouze pravidla v chainu INPUT,
-A nebo --append
pravidla
připojı́ nové pravidlo na konec chainu, následuje název chainu a specifikace
$
C.6
FIREWALL V LINUXU
277
-I nebo --insert
připojı́ nové pravidlo na začátek chainu (pokud nezadáme žádný index) nebo
na zadaný index (čı́slo pravidla můžeme napsat za název chainu), dto., prvnı́ index je 1,
-R nebo --replace
přepı́še existujı́cı́ pravidlo na daném indexu,
odstranı́ pravidlo z chainu, následuje název chainu a bud’ čı́slo pravidla nebo
jeho specifikace,
-D nebo --delete
-F nebo --flush
následované názvem chainu tento chain vyprázdnı́ (vymaže všechna jeho
pravidla)
-Z nebo --zero
vynuluje všechny čı́tače v tabulce, obvykle se použı́vá zároveň s přı́kazem -L,
abychom viděli stav čı́tačů před jejich vynulovánı́m, tedy napřı́klad
iptables -t filter -LZ
-N nebo --new-chain, -X nebo --delete-chain
pro vytvořenı́ nebo odstraněnı́ chainu, násle-
duje vždy název chainu,
-E nebo --rename-chain
pro přejmenovánı́ chainu, následuje původnı́ a nový název chainu.
Parametry sloužı́ k upřesněnı́ přı́kazu (určujı́, podle čeho se pakety majı́ filtrovat), narozdı́l od
přı́kazů jsou pro ně určena malá pı́smena, použı́váme předevšı́m:
-p nebo --protocol
určı́ protokol, napřı́klad -p tcp, negace s vykřičnı́kem, např. -p ! udp,
--dport nebo --sport
dovoluje k protokolu podle předchozı́ odrážky přidat konkrétnı́ čı́slo
portu (zdrojového nebo cı́lového, také se dá označit názvem přı́slušného aplikačnı́ho protokolu), napřı́klad
iptables -t filter -A OUTPUT -p tcp --dport 80 -j DROP
iptables -t filter -A OUTPUT -p tcp --dport http -j DROP
(obojı́: zablokovali jsme odchozı́ tcp spojenı́ přes http port)
iptables -t filter -A FORWARD -p tcp --dport imap -j ACCEPT
iptables -t filter -A FORWARD -p tcp --dport pop3 -j ACCEPT
(povolili jsme přeposı́lánı́ paketů se stahovanou poštou, aplikačnı́ protokol IMAP a POP3)
--icmp-type
můžeme použı́t filtrovánı́ pro určitý typ ICMP zprávy, napřı́klad
iptables -t filter -A FORWARD -p icmp --icmp-type 8 -j DROP
zahazujeme všechny zprávy ICMP Echo Request (nenı́ to zrovna podle RFC, protože tı́m
zablokujeme odpovědi na ping)
v TCP záhlavı́ je nastaven přı́znak SYN (samotný bez přı́znaku ACK), což znamená, že
zřejmě jde o paket, který navazuje nové spojenı́ (ne nutně, také je důležité otestovat stav
spojenı́, viz dále o SPI)
--syn
-s nebo --source nebo --src a -d nebo --destination nebo --dst
je zdrojová a cı́lová adresa, u sı́tě pı́šeme i délku prefixu, napřı́klad -s 192.89.120.0/24, opět můžeme použı́t
vykřičnı́k pro negovánı́ (tj. všechny adresy kromě této),
-i nebo --in-interface
zadává vstupnı́ rozhranı́, použı́vá se v chainech INPUT, FORWARD
a PREROUTING, napřı́klad -i eth0, můžeme také zadávat negaci, napřı́klad -i ! eth4
znamená pakety ze všech sı́t’ových rozhranı́ kromě eth4,
-o nebo --out-interface
podobně pro výstupnı́ rozhranı́, na které je paket směrován (v chainech OUTPUT, FORWARD a POSTROUTING), napřı́klad
iptables -t filter -A OUTPUT -o eth1 -j ACCEPT
$
C.6
FIREWALL V LINUXU
278
veškerý ochozı́ provoz (neodpovı́dajı́cı́ jiným pravidlům) odcházejı́cı́ přes port eth1 bude
povolen
Dalšı́ parametry sloužı́ k upřesněnı́ činnosti, která se má s paketem provést:
-j nebo --jump
sloužı́ k zadánı́ provedenı́ targetu (viz výše), který za tı́mto přepı́načem následuje, znamená tedy odskok (jump) k provedenı́ targetu, kterým může být některá akce
(ACCEPT, DROP, SNAT apod.), a nebo název uživatelsky definovaného chainu, do kterého
takto „odskočı́me“ s tı́m, že se po procházenı́ uživatelského chainu můžeme vrátit zpět (tj.
odskok se zapamatovánı́m adresy), napřı́klad
$
iptables -t filter -A INPUT -p tcp -j tcppakety
(pokud jde o TCP paket, přesuneme se do chainu tcppakety; pokud v tom chainu nenajdeme
žádné vyhovujı́cı́ pravidlo, vrátı́me se zpět do chainu INPUT a pokračujeme následujı́cı́mi
pravidly, uživatelský chain tcppakety byl předem vytvořen přı́kazem -N)
-g nebo --goto
je pro uživatelsky definované chainy podobné jako -j, s tı́m rozdı́lem, že se
před odskokem jinam nezapamatuje adresa momentálnı́ho chainu (přesněji – pokud už byla
předtı́m některá adresa zapamatována pomocı́ -j, nepřepı́še se jinou adresou, tudı́ž při přı́padném návratu během vyhodnocovánı́ jednoho paketu se nevrátı́me do chainu, ze kterého
odcházı́me, ale bude přeskočen), napřı́klad
iptables -t filter -A INPUT -p tcp -g tcppakety
podobně jako předchozı́, ale pokud v uživatelském chainu nenalezne vhodné pravidlo, už se
do INPUT nevracı́ (ovšem v tcppakety může být také parametr -j nebo -g směrujı́cı́ vyhodnocovánı́ paketu jinam).
Parametr -j tedy lze použı́t pro odskok do jiného (obvykle uživatelsky definovaného) chainu. Zpět
se vrátı́me bud’ tehdy, když následný chain neobsahuje vhodné pravidlo, a nebo lze návrat vynutit
targetem RETURN (přı́kaz umı́stı́me na konec vlastnı́ho chainu):
iptables -A vlastni_chain -j RETURN
(zde by bylo vhodné přidat ještě nějakou filtrovacı́ podmı́nku, při jejı́mž splněnı́ dojde k návratu,
jinak pravidlo nemá moc smysl).
chain INPUT:
...
chain prvni:
...
... -j prvni
...
... -j druhy
...
...
...
chain druhy:
...
...
...
... -g treti
chain treti:
...
... -j RETURN
...
...
Obrázek C.4: Rozdı́l mezi parametry -j a -g ve firewallu
Zbývá ještě několik pomocných přepı́načů použı́vaných u přı́kazu -L:
-v nebo --verbose
-n nebo --numeric
zapı́ná verbose („ukecaný“) mód, chceme delšı́ výpis s vı́ce informacemi,
použijeme, když chceme ve výpisu IP adresy mı́sto doménových, výpis je
pak celkově rychlejšı́ a snadněji se hromadně zpracovává,
dalšı́ bychom našli v manuálové stránce přı́kazu: man 8 iptables
$
C.6
FIREWALL V LINUXU
279
Výše uvedený výčet přı́kazů a parametrů nenı́ zdaleka úplný, podrobnějšı́ informaci bychom
našli opět v manuálové stránce přı́kazu, přı́padně na odkazech na konci této sekce.
Poznámka: Měli bychom si uvědomit, že zpracovávánı́ paketu v tabulce končı́ v okamžiku, kdy
NetFilter najde prvnı́ vyhovujı́cı́ pravidlo s cı́lovou akcı́ akceptujı́cı́ nebo zahazujı́cı́ (napřı́klad
ACCEPT nebo DROP). Pokud je v tomto pravidle akce DROP nebo jiná „zahazovacı́“, paket bude
okamžitě zahozen, i kdyby třeba hned následujı́cı́ pravidlo tento paket povolovalo (k dalšı́mu
pravidlu se nedostaneme).
Přı́klad
Pár ukázek práce s iptables:
výpis pravidel v tabulce filter
/sbin/iptables -L -v -n --line-numbers
podrobný výpis (statistika) všech tabulek, s IP
adresami (n), v chainech jsou řádky čı́slovány
/sbin/iptables -P INPUT -j DROP
stanovı́me výchozı́ politiku pro chain INPUT, ve které
řekneme, že vše přı́chozı́ se má zahodit (samozřejmě musı́me kromě jiného přidat před toto
pravidlo také pravidla, která upřesnı́, co se zahazovat nemá)
/sbin/iptables -P OUTPUT -j ACCEPT
všechno odchozı́ povolı́me, propustı́me dál (opět bychom měli uvažovat, jestli nepřidáme „výjimky“)
/sbin/iptables -A INPUT -i lo -j ACCEPT
povolı́me to, co probı́há mezi lokálnı́mi procesy (komunikujı́ přes sockety na loopbacku)
/sbin/iptables -A INPUT -p tcp --syn -j DROP budou zahozeny všechny přı́chozı́ pakety,
které majı́ v TCP záhlavı́ nastaven pouze SYN bit (to je vždy prvnı́ paket spojenı́, tedy
znemožnı́me navazovánı́ spojenı́ zvnějšku)
/sbin/iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT povolili jsme
pakety s ICMP zprávou č. 8 (Echo Request) z vnějšku, můžeme použı́t čı́selné i slovnı́ označenı́
typu zprávy
/sbin/iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT povolili jsme
přı́chozı́ ICMP pakety Time Exceeded (vypršenı́ času při navazovánı́ spojenı́)
/sbin/iptables -t filter -L
/sbin/iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
povolili jsme přı́chozı́ ICMP pakety hlásı́cı́ nedostupnost cı́le
Úkoly
1. Nastavte výchozı́ politiku pro odchozı́ provoz na akceptovánı́.
2. Sestavte sadu pravidel, která z přı́chozı́ho provozu zakážou všechno kromě provozu protokolu HTTP, POP a IMAP.
3. Na koncové stanici chceme povolit u přı́chozı́ch paketů pouze ty, které jdou na TCP port 80
nebo TCP port 8080, všechny ostatnı́ přı́chozı́ zakážeme. Jak budou vypadat pravidla pro
přı́slušný chain?
4. Sestavte pravidla, která povolı́ ICMP pakety (jakékoliv, všechny typy ICMP zpráv) v přı́chozı́m, odchozı́m i průchozı́m provozu.
L
C.6
FIREWALL V LINUXU
C.6.3
280
SPI
Firewall v Linuxu s jádrem 2.4 a novějšı́m podporuje také SPI (Stateful Packet Inspection). Aby
bylo možné pracovat se stavy spojenı́, je třeba mı́t v jádře zaveden modul pro sledovánı́ stavu
spojenı́ (connection tracking). Dřı́ve se použı́val modul ip_conntrack a dalšı́ s nı́m souvisejı́cı́,
nynı́ se spı́še setkáme s bezpečnějšı́m a funkčně širšı́m nf_conntrack a moduly s nı́m souvisejı́cı́mi.
nf_conntrack plně podporuje IPv4 a IPv6 včetně jejich kombinovánı́.
P
Přı́klad
Jak zjistı́me, jestli je modul v jádře zaveden (výpis bývá dlouhý, přefiltrujeme si ho přı́kazem grep),
výstup v SUSE Linuxu:
sarka@notebook:/home/sarka# /sbin/lsmod | grep conntr
nf_conntrack_ipv6
20196
4
nf_conntrack_netbios_ns
2152
0
nf_conntrack_ipv4
10480
4
nf_conntrack
67400
5 nf_conntrack_ipv6,xt_NOTRACK,xt_state,
nf_conntrack_netbios_ns,nf_conntrack_ipv4
ipv6
242608
25 ip6t_REJECT,nf_conntrack_ipv6,ip6table_mangle
M
V prvnı́m sloupci je název modulu, v druhém jeho velikost, následuje počet uživatelů tohoto
modulu a přı́padné závislosti (které zavedené moduly dotyčný modul vyžadujı́). Pokud výpis
vypadal podobně jako ten výše, pak je vše OK.
Pokud potřebné moduly v jádře nejsou, tak je třeba je do jádra zavést. U každého potřebného
modulu nejdřı́v ověřı́me, zda je dostupný:
/sbin/modeprobe -l *conntr*
(přı́padně lze vypsat vše a pak to profiltrovat grepem). S dostupnostı́ obvykle nebývá problém.
Zbývá modul dostat do jádra:
/sbin/modeprobe nf_conntrack
Pro dalšı́ moduly je postup podobný.
Podrobný návod včetně ukázek využitı́ modulů najdeme na
http://www.abclinuxu.cz/blog/pb/2007/2/nf-conntrack
Pokud máme modul v jádře, můžeme ve firewallu filtrovat pakety podle stavu spojenı́ (můžeme je
považovat za stavy paketů ve vztahu ke spojenı́, ke kterému patřı́). Rozlišujı́ se tyto stavy:
• NEW: klient přes firewall navazuje nové spojenı́ (tj. prvnı́ paket spojenı́), může být také
u jednosměrných spojenı́
• ESTABLISHED: paket je součástı́ již navázaného spojenı́
• RELATED: paket sice navazuje nové spojenı́, ale zároveň je ve vztahu k některému existujı́cı́mu (typicky u FTP, kdy mohou být navázána dvě různá spojenı́ na dvou portech)
• INVALID: paket nelze přiřadit k žádnému existujı́cı́mu ani navazovanému spojenı́
Pak v přı́kazech programu iptables můžeme použı́vat filtrovánı́ podle stavů. Existujı́ také virtuálnı́ stavy SNAT a DNAT pro pakety, kde byla přeložena zdrojová resp. cı́lová adresa.
P
C.6
FIREWALL V LINUXU
281
Conntrack ve skutečnosti nenı́ samostatná tabulka, funkcionalita se použı́vá v existujı́cı́ch tabulkách a chainech (na obrázku C.3 na straně 275 vidı́me, kde konkrétně v datovém toku se vyskytuje).
Přı́klady pravidel pro přı́chozı́ spojenı́:
iptables -A INPUT -p tcp ! --syn -m state --state NEW
-j LOG --log-prefix ”Nenastaven SYN:” protokolujı́ se veškeré pakety navazujı́cı́ spo-
jenı́ zvnějšku, které nemajı́ nastaven (samotný) přı́znak SYN, toto pravidlo je obvykle následováno tı́mto:
zajı́máme se o pakety zapouzdřujı́cı́ TCP segment (protokol TCP), které nemajı́ nastaven (samotný) přı́znak
SYN (je tam negace) a zároveň stav spojenı́ je nové (tj. navazuje se nové spojenı́ a přitom nenı́
nastaven SYN bit), výslednou akcı́ je tiché zahozenı́ paketu
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
zdánlivě totéž, co předtı́m, ale pozor
– pokud zvenku přijde paket navazujı́cı́ nové spojenı́ a nebude mı́t (chybně) nastaven přı́znak
SYN, tak projde (tudı́ž pokud chceme blokovat přı́chozı́ navazovánı́ spojenı́, uvedeme obě
pravidla)
iptables -A INPUT -m state --state NEW -j DROP
necháme projı́t dovnitř pakety, které patřı́ do existujı́cı́ho spojenı́ nebo s některým existujı́cı́m souvisejı́
iptables -A INPUT -m state --state RELATED, ESTABLISHED -j ACCEPT
Pro práci s přı́chozı́mi a odchozı́mi spojenı́mi a modulem nf_conntrack je možné použı́t také
program conntrack z balı́čku conntrack-tools (bývá běžně v repozitářı́ch, takže pokud nenı́ nainstalován, můžeme doinstalovat).
Seznam aktivnı́ch spojenı́, která jsou povolena mechanismem conntrack, najdeme takto:
cat /proc/net/nf_conntrack
Přı́klad
Ted’ se podı́váme na mezilehlé zařı́zenı́ (hardwarový firewall nebo směrovač), na kterém chceme
nastavit port pro DMZ. Předpokládejme, že eth0 je port do lokálnı́ sı́tě, eth1 bude WAN rozhranı́
a eth2 povede do DMZ:
iptables -A FORWARD -i eth0 -o eth2 -m state --state NEW, ESTABLISHED,
RELATED -j ACCEPT povolı́me pakety patřı́cı́ do existujı́cı́ho spojenı́, vztažené k existujı́-
cı́mu i navazujı́cı́ spojenı́ (provoz z LAN do DMZ), tento směr prakticky nenı́ omezován (až
na INVALID pakety), výstup přı́kazu iptables -L -v bude:
Chain FORWARD (policy DROP)
target
prot opt in
out
...
ACCEPT
all -eth0 eth2
source
destination
anywhere
anywhere
M
state ESTABLISHED,RELATED
iptables -A FORWARD -i eth1 -o eth2 -m state --state NEW, ESTABLISHED,
RELADED -j ACCEPT podobně pro provoz vedoucı́ z vnějšı́ sı́tě do DMZ, tady je potřeba mı́t
povoleno navazovánı́ spojenı́, protože v DMZ jsou často webové a dalšı́ servery, se kterými
je potřeba navazovat spojenı́ i zvnějšku
C.6
FIREWALL V LINUXU
282
iptables -A FORWARD -i eth2 -o eth0 -m state --state ESTABLISHED,
RELATED -j ACCEPT zařı́zenı́ umı́stěná v DMZ jsou obecně považována za méně důvěry-
hodná, tj. navazovaná spojenı́ nepustı́me do LAN (pouze pakety patřı́cı́ do navázaných nebo
vztažených spojenı́)
iptables -A FORWARD -i eth2 -o eth1 -m state --state ESTABLISHED,
RELATED -j ACCEPT podobně pro provoz z DMZ do vnějšı́ sı́tě, servery obvykle nemajı́ co
navazovat nová spojenı́
Pak samozřejmě potřebujeme zbývajı́cı́ pravidla pro řı́zenı́ provozu na portech eth0 a eth1. U chainu
FORWARD předpokládáme jako výchozı́ zásadu „zahazovat vše“ (DROP), tedy co jsme explicitně
v pravidlech nepovolili nebo neurčili k zahozenı́ s ICMP odezvou, bude zahozeno bez odezvy.
Podpora conntrack je důležitá i pro funkčnost SNAT/DNAT/MASQUERADE, protože je třeba
překládat podle jedné konkrétnı́ dvojice adres v rámci jednoho spojenı́ (v rámci dalšı́ho spojenı́ se
může použı́vat jiná soukromá adresa).
Úkoly
1. Zjistěte, zda máte v jádře načtené alespoň některé moduly pro SPI. Pokud ano, zjistěte,
zda se sledovánı́ stavů spojenı́ použı́vá v aktuálnı́ch pravidlech firewallu (zjistı́te z výpisu
pravidel). Pokud máte dostatečná přı́stupová oprávněnı́, vypište obsah souboru, ve kterém
jsou uchovávána momentálně navázaná spojenı́.
2. Sestavte pravidlo, které bude zakazovat přı́chozı́ spojenı́ (předpokládejme, že jsme na běžné
pracovnı́ stanici).
3. Sestavte pravidlo, které bude akceptovat pakety z již navázaných spojenı́.
C.6.4
NAT a maškaráda
Překlad adres se provádı́ vždy co nejblı́že sı́t’ovému rozhranı́, tj. těsně před odeslánı́m paketu do sı́tě
(všechny ostatnı́ tabulky se procházejı́ předtı́m), resp. okamžitě po přı́chodu paketu ze sı́tě (a až
potom se provádějı́ dalšı́ tabulky).
Kromě targetů ACCEPT, DROP a jiných můžeme využı́vat také targety pro překlad adres:
• SNAT (Source NAT) – v odchozı́m provozu překládá statickou adresu odesı́latele na jinou
(statickou) adresu viditelnou ve vnějšı́ sı́ti
• DNAT (Destination NAT) – v přı́chozı́m provozu překládá statickou adresu přı́jemce na jinou,
obvykle soukromou statickou adresu viditelnou pouze ve vnitřnı́ sı́ti, použı́vá se také pro
přeposı́lánı́ přı́chozı́ch paketů na proces, který má tyto pakety dále zpracovat
• MASQUERADE (maškaráda) – je to obdoba SNAT, ale použı́váme tehdy, když překládáme
dynamické adresy (v odchozı́m provozu překládá soukromé adresy z vnitřnı́ sı́tě na jednu
adresu viditelnou vně našı́ sı́tě, obvykle adresu toho zařı́zenı́, na kterém je toto pravidlo)
P
C.6
FIREWALL V LINUXU
283
Nejdřı́v bychom měli nastavit výchozı́ politiky:
pokud něco odcházı́ přes tabulku nat, necháme to jı́t (to je obvyklá výchozı́ politika pro tabulku nat)
/sbin/iptables -t nat -P OUTPUT -j ACCEPT
podobně pro chain PREROUTING, přı́padné zahozenı́ necháme na jiných tabulkách, totéž bychom mohli provést pro POSTROUTING
/sbin/iptables -t nat -P PREROUTING -j ACCEPT
Nejdřı́v se podı́váme na překlad statické adresy. Nemusı́ být zrovna veřejná, ale neměla by se měnit
a měli bychom ji znát, protože tuto adresu napevno zadáváme do přı́kazu.
$
/sbin/iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to 193.168.210.80 zajistı́me
SNAT na odchozı́m provozu odcházejı́cı́m přes eth2: zdrojová adresa v záhlavı́ odcházejı́cı́ho
paketu bude zaměněna za uvedenou (statickou viditelnou venku), do překladové tabulky se
uložı́ údaj o této komunikaci (původnı́ zdrojová plus cı́lová) pro zpětný překlad
Pokud má náš router dynamickou adresu (tj. nevı́me předem, jakou při navazovánı́ spojenı́ nebo
obnovovánı́ přidělenı́ adresy dostaneme), použijeme maškarádu. Maškaráda funguje podobně
jako SNAT, ale využı́vá se výhradně u dynamických adres (ostatně, dynamickou adresu bychom
stejně nemohli do SNAT pravidla naklepat), údaje pro překlad se uchovávajı́ v jednom ze souborů
v souborovém systému /proc (pro každé spojenı́ se ukládá dvojice soukromá adresa v LAN plus
vnějšı́ adresa, se kterou se komunikuje).
$
/sbin/iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE zajistili jsme maškarádu
(masquerade) na portu eth2, tj. vše, co odcházı́ ven ze sı́tě na portu eth2, bude mı́t přeloženu
zdrojovou adresu (obvykle soukromou, přidělenou DHCP serverem) na adresu routeru,
automaticky je zajištěn záznam s uvedenı́m portu pro zajištěnı́ zpětné konverzace (tj. PAT)
totéž, jen port je jinak
pojmenován (to je velice častý název u routerů kombinovaných s DSL modemem)
/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Pokud má také náš router (firewall) IP adresu viditelnou vně našı́ sı́tě také dynamickou (od DHCP
serveru našeho ISP), je třeba pozměnit hodnotu v jednom ze souborů virtuálnı́ho soub. systému
/proc:
echo 7 > /proc/sys/net/ipv4/ip_dynaddr
To je pro přı́pad, že „vnějšı́“ adresa, která je při maškarádě použita pro překlad mı́stnı́ch soukromých adres, „vypadne“, je potřeba požádat o novou, která je pravděpodobně jiná. Pokud je
dotyčný parametr takto nastaven, pak se v takové situaci zaměnı́ stará dynamická adresa za nově
zı́skanou ve všech zaznamenaných právě probı́hajı́cı́ch spojenı́ch.
Vrátı́me se ke statickým adresám. Mechanismus NAT se použı́vá také pro přeposı́lánı́ přı́chozı́ho
provozu:
/sbin/iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80
-j REDIRECT --to-port 3128 pokud přijde přes rozhranı́ eth2 paket z TCP portu č. 80
(velmi pravděpodobně pro protokol HTTP), přesměruj ho na port 3128; to se použı́vá tehdy,
když na portu 3128 naslouchá Squid konfigurovaný jako transparentnı́ proxy, tj. dále prověřuje a zpracovává tento typ paketů
$
C.6
FIREWALL V LINUXU
284
Všimněte si, že filtrovánı́ a NAT lze jednoduše kombinovat s překladem portů.
Mechanismus NAT může sloužit pro překlad jedné statické adresy na jinou statickou, pak je potřeba
zajistit ručně překlad v obou směrech a u každého směru uvést obě adresy. Výhodou tohoto
řešenı́ oproti jednoduchému SNAT a maškarádě je rychlejšı́ zpracovánı́ (provoz nenı́ zdržován
vyhledávánı́m dynamicky přidělených adres v dočasných souborech). Předpokládejme, že v DMZ
máme server se soukromou (uvnitř viditelnou) adresou 10.201.51.2, chceme, aby byl vně sı́tě
viditelný pod adresou 195.201.51.2. Je třeba zadat následujı́cı́ dvě pravidla, jedno pro provoz
směrem od serveru ven, druhé pro opačný směr (zpětný překlad):
$
/sbin/iptables -t nat -A PREROUTING -d 10.201.51.2 -j DNAT
--to-destination 195.201.51.2
nastavenı́ DNAT, tedy překladu cı́lové adresy v paketu (provoz směrem do sı́tě), zaměnı́
soukromou adresu za uvedenou 195.201.51.2 v záhlavı́ přicházejı́cı́ho paketu
/sbin/iptables -t nat -A POSTROUTING -s 195.201.51.2 -j SNAT
--to-source 10.201.51.2
nastavenı́ SNAT, tedy překladu zdrojové adresy (provoz směrem ven)
Na jednu věc bychom si měli dát pozor: mechanismus NAT funguje tak, že se pravidlo s přesměrovánı́m adresy použije pouze na prvnı́ paket spojenı́, a pouze prvnı́ paket spojenı́ procházı́ tabulkou
nat. Dalšı́ pakety patřı́cı́ do téhož spojenı́ (tj. pakety, které nejsou „prvnı́“), vůbec do tabulky nat
nepřijdou, proto se jich tato pravidla netýkajı́.
L
Úkoly
1. Ve výpisu pravidel firewallu zjistěte, zda je nastaven překlad adres.
2. Sestavte pravidlo pro SNAT odchozı́ho provozu na portu wan0, překládá se na statickou
adresu 195.49.88.1.
3. Sestavte pravidlo pro maškarádu odchozı́ho provozu na portu wan0.
C.6.5
Označovánı́ paketů
Firewall NetFilter může do záhlavı́ paketů přidávat značky (marks), kterým rozumı́ jak jeho pravidla, tak i některé dalšı́ nástroje (včetně přı́kazu ip). Přidávánı́ značek je jednou z funkcı́ souvisejı́cı́ch
s tabulkou mangle (protože jde o změnu neadresnı́ho údaje v záhlavı́) nebo nat, značku pak můžeme
využı́vat jinde (typicky v tabulce filter).
Rozlišujeme dva druhy značek:
• NetFilter mark se nastavuje targetem MARK, je viditelný i mimo firewall, touto značkou se
označujı́ pakety, v terminologii iproute2 se také nazývá fwmark (firewall mark),
• connection mark se nastavuje targetem CONNMARK, sloužı́ pouze pro vnitřnı́ potřebu firewallu; touto značkou se označuje spojenı́ (pozor, ne paket), značku lze přenést i do záhlavı́
paketů (pak jde o NetFilter značky), nebo naopak.
P
C.6
FIREWALL V LINUXU
285
Značky NetFilter lze do záhlavı́ paketu uložit pomocı́ přı́kazu firewallu iptables targetem MARK,
využı́vat je lze bud’ v tabulkách firewallu pro dalšı́ filtrovánı́ či úpravy, a nebo mechanismem
iproute2 (přı́kazem ip rule).
Ukážeme si několik přı́kazů s využitı́m značek (přı́kazy jsou čı́m dál delšı́, proto mı́sto celé
cesty /sbin/iptables budeme psát jen iptables):
$
pokud paket přišel
z rozhranı́ eth2, dostane značku 2 (použijeme target MARK, protože označenı́ je důsledkem,
nikoliv podmı́nkou), platı́ jak pro pakety, které půjdou do chainu INPUT, tak i pro pakety
mı́řı́cı́ do chainu FORWARD v jiných tabulkách (na obrázku C.3 můžeme vidět, že označujeme
prakticky hned na vstupu firewallu, pokud nepoužı́váme tabulku raw)
iptables -t mangle -A PREROUTING -i eth2 -j MARK --set-mark 2
iptables -t filter -A INPUT -m mark --mark 2 -p tcp --dport 80 -j ACCEPT chceme
filtrovat pakety s podmı́nkou „pokud má paket značku 2“ (znamená: pokud má paket
značku 2 a zároveň jde na TCP port 80, akceptuj), všimněte si odlišnosti práce s označenı́m oproti předchozı́mu přı́kazu (zde je targetem ACCEPT)
iptables -t nat -A PREROUTING -p tcp --dport 80 -j CONNMARK --set-mark 2
u přı́chozı́ch spojenı́ mı́řı́cı́ch na TCP port 80 (http) nastavı́me značku spojenı́ na 2 (protože je
pravidlo v tabulce nat, provede se vždy jen pro prvnı́ paket spojenı́, proto se často řadı́ právě
do tabulky nat)
značku spojenı́ můžeme
nastavit také takto: předpokládejme, že značka paketu byla nastavena již předtı́m (v předchozı́
tabulce), pak hodnota této značky paketu se uložı́ do značky spojenı́ (tj. connmark := fwmark)
iptables -t mangle -A PREROUTING -j CONNMARK --save-mark
iptables -t mangle -A POSTROUTING -j CONNMARK --restore-mark
opačný přenos informace, značka spojenı́ se uložı́ do značky paketu (tj. fwmark := connmark)
Pokud firewall označil paket značkou fwmark, lze tuto značku dále zpracovávat během směrovánı́,
napřı́klad takto:
přidali jsme nové směrovacı́ pravidlo: pakety označené značkou 4 jsou směrovány podle tabulky tabVen (na obrázku C.3 na straně 275
si všimněte, kdy ke směrovánı́ vzhledem k chainům firewallu docházı́, a kdy tedy je třeba
paket označit, aby se podle značky dalo směrovat)
ip rule add fwmark 4 table tabVen prio 2021
Dalšı́ informace o této problematice (včetně přı́kladů) najdeme na
• http://www.linuxexpres.cz/praxe/ipp2p-kladivo-na-stahovace
• http://blog.khax.net/2009/12/01/multi-gateway-balancing-with-iptables/
• http://nerdboys.com/2006/05/05/conning-the-mark-multiwan-connections-using
-iptables-mark-connmark-and-iproute2/
• http://home.regit.org/netfilter-en/netfilter-connmark/
• http://ornellas.apanela.com/dokuwiki/pub:firewall and adv routing
C.6
FIREWALL V LINUXU
C.6.6
286
Skripty
Je vhodné si vytvořit jeden nebo vı́ce skriptů pro konfiguraci firewallu, a to z několika důvodů:
předně potřebujeme, aby veškerá nastavenı́, která provedeme, byla platná neustále (i po přı́padném restartu), abychom měli zálohu pro přı́pad poruchy a aby bylo možné občas sadu pravidel
měnit či někdy vypı́nat (mazat pravidla a pak podle potřeby obnovit). Ukázky několika typických
konfiguračnı́ch skriptů s pravidly iptables najdeme napřı́klad na
• http://www.faqs.org/docs/iptables/examplecode.html (to je prvnı́ skript, na dalšı́ se dostaneme
klepánı́m na odkaz Next dole).
• http://www.pmoghadam.com/blog/categories/Scripts/Round-robin%20load%20
balancing%20NAT.txt
• http://tldp.org/HOWTO/IP-Masquerade-HOWTO/firewall-examples.html
• http://tldp.org/HOWTO/pdf/VPN-Masquerade-HOWTO.pdf
• http://jk.frozen-doe.net/hack/iptables/
C.6.7
Uloženı́ změn
Aby byla konfigurace nejen platná, ale také uložena pro načtenı́ po vypnutı́ a zapnutı́ počı́tače,
je nutné tuto konfiguraci uložit. Je velmi pravděpodobné, že distribuce, kterou máme, podporuje
přı́kazy iptables-save a iptables-restore, které nám mohou velmi usnadnit práci s „hromadným“ startovánı́m či ukončovánı́m firewallu.14
uložı́ obsah všech tabulek a chainů (tj. všechna pravidla) na standardnı́ výstup,
tj. použı́váme přesměrovánı́, napřı́klad iptables-save > /etc/firerules
iptables-save
iptables-save -c -t filter
při použitı́ přepı́nače -c se uložı́ také stav čı́tačů paketů a oktetů,
přepı́nač -t zase omezı́ uloženı́ pouze na zadanou tabulku (zde tabulku filter)
načte pravidla (tabulky, chainy) ze standardnı́ho vstupu (tj. opět musı́me
použı́t přesměrovánı́ nebo třeba rouru s přı́kazem cat, napřı́klad
iptables-restore < /etc/firerules)
iptables-restore
iptables-restore -c
načte také hodnoty čı́tačů
pokud už předtı́m byla nějaká pravidla ve firewallu aktivována, nebudou nově načtenými přepsána, nová pravidla se pouze přidajı́ (bez uvedenı́ parametru -n by
po vykonánı́ přı́kazu byla původně aktivnı́ pravidla přepsána, odstraněna – flushed)
iptables-restore -n
Pokud tyto přı́kazy nenajdeme, pak musı́me použı́t postup typický pro danou distribuci. Napřı́klad
v distribucı́ch založených na RedHat (včetně Mandrivy) je to přı́kaz
/sbin/service iptables save
V distribucı́ch založených na Debianu v souboru /etc/default/iptables nastavı́me řádek
enable_iptables_initd=true
14
Pozor – tı́m, že ukončı́me program iptables, rozhodně nevypneme firewall, ten je totiž modulem jádra. Vpodstatě
je firewall zapnutý po celou dobu, co je jeho modul zaveden v jádře, obdobou vypnutı́ by bylo vyprázdněnı́ všech
tabulek vnitřnı́m přı́kazem -F.
$
C.7
TESTOVÁNÍ A STATISTIKY
287
čı́mž uloženı́ povolı́me, samotné uloženı́ se provede přı́kazem
/etc/init.d/iptables save_active
Pokud chceme firewall deaktivovat (pojem „vypnout“ nenı́ zrovna správný), vyprázdnı́me jeho
chainy:
iptables -F
L
(přı́padně zadáme tabulku a chain). Pokud ale něco takového opravdu chceme udělat, měli bychom
si předem provést zálohu pravidel, třeba výše popsaným způsobem.
Nenı́ vždy nutné provádět konfiguraci a jejı́ uloženı́ v textovém režimu. Existuje dokonce několik různých grafických rozhranı́ k programu iptables. V desktopových distribucı́ch je najdeme
celkem běžně, přı́padně je možné si některý z nich stáhnout z repozitáře a nainstalovat.
V unixových systémech založených na BSD (napřı́klad OpenBSD) se často setkáme s firewallem
PacketFilter (staršı́ byl IPFilter), obslužný program je pfctl.
Problematika firewallu v Linuxu je velmi rozsáhlá, sekce v těchto skriptech zdaleka nepokrývá
všechny možnosti, které NetFilter nabı́zı́. Dalšı́ informace o iptables:
•
•
•
•
•
•
•
•
•
http://www.netfilter.org/documentation/index.html
http://security.maruhn.com/iptables-tutorial/x9125.html
http://lartc.org/lartc.html
http://www.frozentux.net/iptables-tutorial/iptables-tutorial.html
http://www.root.cz/serialy/vse-o-iptables/
http://www.webstep.net/media/PDF/iptables.pdf
http://www.faqs.org/docs/iptables/
http://ornellas.apanela.com/dokuwiki/pub:firewall and adv routing
http://www.asia-oss.net/aoss25 slides/TH Sawangpong Kernel Development
and Embedded System.pdf
C.7
Testovánı́ a statistiky
C.7.1
Základnı́ nástroje
Přı́kaz ping sloužı́ ke stejným účelům jako ve Windows:
v pravidelných intervalech odesı́lá cı́lovému zařı́zenı́ ICMP pakety, po
přerušenı́ klávesou Ctrl+C ukončı́ zası́lánı́ a vypı́še souhrnnou statistiku (kolik paketů bylo
odesláno, přijato, podı́l ztracených, dále odezvu cı́lového počı́tače – nejrychlejšı́, nejpomelejšı́,
střednı́ hodnota), cı́lový počı́tač můžeme zadat také IP adresou
ping -c 4 www.google.com
chová se stejně jako ve Windows, tedy zadáme počet zası́laných
ICMP paketů (bez tohoto parametru by byly zası́lány tak dlouho, dokud bychom nestiskli
Ctrl+C)
ping -c 1 -R www.google.com
parametr -R (pozor, velké pı́smeno) znamená, že se vypı́šou
všechny uzly na cestě (směrovače) podobně jako napřı́klad u traceroute (ale zde zı́skáme
méně podrobný výpis)
ping www.google.com
V manuálové stránce bychom zjistili dalšı́ možné parametry.
$
C.7
TESTOVÁNÍ A STATISTIKY
288
Existuje také přı́kaz arping, který má podobný účel jako ping, ale použı́vá jiný typ paketů
(ARP Request) a je určen předevšı́m pro testovánı́ v lokálnı́ sı́ti.
zadanému cı́li (poslednı́ parametr) přes zadané
rozhranı́ odešle maximálně čtyři ARP pakety, parametr -f určuje, že se nemusejı́ deslat
všechny 4, ale pouze tolik, než vzdálený systém odpovı́
arping -f -c 4 -I eth0 209.85.143.99
Zatı́mco ve Windows máme přı́kaz tracert, v unixových systémech včetně Linuxu se setkáme
s přı́kazem traceroute.
vypı́še trasu k zadanému zařı́zenı́ (zadáváme doménovou nebo
IP adresu), použije UDP pakety (pouze metoda s využitı́m UDP paketů je použitelná kterýmkoliv uživatelem)
traceroute www.google.com
$
podobně, ale použije zprávy ICMP Echo Request (přepı́nač je
velké „i“), ekvivalentem je přı́kaz tracert (s nı́m se setkáme i u Windows)
traceroute -I 209.85.143.99
traceroute -6 209.85.143.99
sloužı́ přepı́nač -4
vynucenı́ použitı́ IPv6 (také traceroute6), k vynucenı́ IPv4
Tento přı́kaz má ještě několik dalšı́ch přepı́načů (viz manuálové stránky) včetně u těchto přı́kazů
běžného -n zakazujı́cı́ho mapovánı́ IP adres na doménové názvy, určenı́ maximálnı́ hodnoty TTL,
atd.
Podobný je přı́kaz tracepath (v některých distribucı́ch ho však nenajdeme). Sloužı́ předevšı́m
ke zjištěnı́ hodnot MTU na cestě:
$
vypı́še údaje o cestě k zadanému uzlu sı́tě (ke každému úseku
zjistı́me hodnotu odečı́taného TTL na tomto úseku, časový údaj a hodnotu MTU (Path MTU)
tracepath 209.85.143.99
tracepath -n 209.85.143.99
mı́sto doménových se vypisujı́ IP adresy
Samozřejmě nesmı́ chybět přı́kaz netstat. Parametry jsou obdobné těm ve Windows (odkud se
tento přı́kaz asi do Windows dostal), tedy si zde uvedeme jen několik dalšı́ch motivačnı́ch přı́kladů:
$
Přı́klad
Zobrazı́me seznam otevřených portů, postupně: výpis numerických IP adres (n), výpis UDP portů
(u), TCP portů (t), všechny údaje (a, naslouchajı́cı́ i nenaslouchajı́cı́), vypsat PID procesů, které port
použı́vajı́ (p). Výpis přı́kazu následuje.
sarka@notebook:/home/sarka# netstat -nutap
Aktivnı́ Internetová spojenı́ (servery a˜navázaná spojenı́)
Proto Přı́ch-F Odch-F Mı́stnı́ Adresa
Vzdálená Adresa
Stav
PID/Program name
tcp
0
0 127.0.0.1:2208
0.0.0.0:*
LISTEN
2725/hpiod
tcp
0
0 127.0.0.1:49702
0.0.0.0:*
LISTEN
2728/python
tcp
0
0 0.0.0.0:113
0.0.0.0:*
LISTEN
3038/inetd
tcp
0
0 127.0.0.1:631
0.0.0.0:*
LISTEN
2850/cupsd
tcp
0
0 127.0.0.1:25
0.0.0.0:*
LISTEN
3018/exim4
tcp
0
0 10.0.0.2:54255
74.125.232.216:443
SPOJENO
3517/firefox-bin
M
C.7
TESTOVÁNÍ A STATISTIKY
tcp
0
0 10.0.0.2:54260
SPOJENO
3517/firefox-bin
tcp
0
0 10.0.0.2:54265
SPOJENO
3517/firefox-bin
tcp
0
0 10.0.0.2:39412
SPOJENO
3517/firefox-bin
tcp
0
0 10.0.0.2:32819
SPOJENO
3517/firefox-bin
tcp
0
0 127.0.0.1:47622
tcp
1
0 10.0.0.2:55360
CLOSE_WAIT 3597/python
udp
0
0 0.0.0.0:32768
2929/avahi-daemon:
udp
0
0 0.0.0.0:68
3152/dhclient
udp
0
0 0.0.0.0:714
3082/rpc.statd
udp
0
0 0.0.0.0:5353
2929/avahi-daemon:
udp
0
0 0.0.0.0:631
2850/cupsd
289
74.125.232.216:443
74.125.232.216:443
74.125.232.213:443
74.125.232.194:80
127.0.0.1:111
91.189.90.132:80
TIME_WAIT
-
0.0.0.0:*
0.0.0.0:*
0.0.0.0:*
0.0.0.0:*
0.0.0.0:*
Vidı́me, že (aktivně) komunikuje předevšı́m Firefox, dalšı́ démony spı́še naslouchajı́. Najdeme tam
napřı́klad nechvalně známý Avahi (provádı́ tzv. Zero-conf automatické nastavenı́ parametrů sı́tě,
což je odbornı́ky hodně kritizováno), cupsd (tiskový subsystém), hpiod (démon pro podporu tisku
kompatibilnı́ s HP zařı́zenı́mi), exim4 (sı́t’ová podpora pro mail klienty, v současné době se spı́še
doporučuje použı́t postfix), inetd,15 dhclient (DHCP klient), atd. (výpis byl záměrně mı́rně zkrácen).
Přı́klad
V Linuxu si pomocı́ přı́kazu netstat můžeme prohlédnout tabulku sı́t’ových rozhranı́ tak, jak ji
vidı́ jádro:
sarka@notebook:/home/sarka# netstat -i
Tabulka rozhranı́ v jádru
Iface
MTU Met
RX-OK RX-ERR RX-DRP RX-OVR
eth0
1500 0
2218
0
0
0
lo
16436 0
48
0
0
0
TX-OK TX-ERR TX-DRP TX-OVR Flg
1919
0
0
0 BMRU
48
0
0
0 LRU
Co je to MTU, už vı́me. Následuje metrika, údaje pro přı́chozı́ (RX) a odchozı́ (TX) pakety, kdy se
vypisuje počet úspěšně přijatých/odeslaných, chybných, zahozených. Poslednı́ sloupec obsahuje
jednopı́smenné přı́znaky:
•
•
•
•
•
15
B: přijı́má broadcast pakety,
M: zapnut promiskuitnı́ režim,
R: rozhranı́ je použı́váno (běžı́, running)
U: rozhranı́ je aktivnı́ (up)
L: loopback
Inetd má podobnou funkci jako ve Windows svchost.exe, může hostit démony. Narozdı́l od svchost je zde pro démony
„pohostinstvı́“ dobrovolné, mohou běžet samostatně. Inetd jednoduše naslouchá na přı́slušných portech a když zjistı́
pokus o komunikaci s démonem, jehož hostı́, jeho kód spustı́ ve svém vlastnı́m procesu, nenı́ třeba spouštět démona
navı́c (tj. mı́sto vı́ce různých démonů běžı́ jen jeden, inetd, a přı́slušné služby se spouštějı́ až na vyžádánı́).
M
C.8
VZDÁLENÝ PŘÍSTUP
290
Přı́kaz netstat-nat je zdánlivě podobný přı́kazu netstat, ale nenı́ tentýž:
výpis adres překládaných mechanismem NAT (pozor, před pomlčkou nenı́ mezera, opravdu se jedná o celý přı́kaz bez jakýchkoliv parametrů)
netstat-nat
$
před druhou pomlčkou už mezera je, význam přı́kazu je stejný jako u předchozı́ho, ale mı́sto názvů počı́tačů se budou vypisovat IP adresy (tj. bez DNS překladu)
netstat-nat -n
C.7.2
Pokročilé testovánı́
Pro pokročilé testovánı́ strojů a celé sı́tě existuje mnoho velmi užitečných nástrojů. V tomto předmětu je bohužel nestačı́me probrat (ale během jednoho roku by zde měla být alespoň doplněna
sekce s jejich popisem). Namátkou:
• tcpdump
• nmap
• ettercap
C.8
Vzdálený přı́stup
Pokud chceme přistupovat k některému uzlu sı́tě s Linuxem vzdáleně (z jiného počı́tače), lze použı́t
několik nástrojů. Předně všechny takové uzly určitě podporujı́ přı́kaz telnet. Ovšem to, že tento
přı́kaz podporujı́, ještě neznamená, že ho můžeme použı́t. Předevšı́m protokol telnet je na mnoha
počı́tačı́ch už během instalace zakázán, a to z bezpečnostnı́ch důvodů. Pokud přesto chceme tı́mto
způsobem na daný počı́tač přistupovat, musı́me telnet povolit. Postup je v různých distribucı́ch
odlišný, popis najdeme zde:
$
• Ubuntu: http://www.cyberciti.biz/faq/ubuntu-linux-enable-telnet-service/
• RedHat: http://aplawrence.com/Linux/enable telnet.html
atd. (vždy bychom se měli raději podı́vat na stránky našı́ distribuce). Nicméně použı́vánı́ protokolu
telnet se moc nedoporučuje, mı́sto něho bychom měli raději použı́vat protokol SSH (přı́kaz ssh pro
zajištěnı́ spojenı́ a pak přı́kaz scp pro zabezpečené kopı́rovánı́ s využitı́m protokolu SSH), který
je taktéž dostupný na prakticky všech uzlech sı́tě a klienti jsou dostupnı́ i pro Windows. SSH má
výhody předevšı́m v oblasti zabezpečenı́, šifruje se celá komunikace včetně zası́lánı́ přihlašovacı́ch
informacı́.
$
Nejdřı́v je potřeba nainstalovat na „vzdálený stroj“ SSH server, pak na stroj, ze kterého budeme
na ten vzdálený přistupovat, nainstalujeme SSH klienta. Jako SSH server se v Linuxu běžně použı́vá
OpenSSH Server, který najdeme v repozitáři obvykle pod názvem openssh-server (záležı́ na
konkrétnı́ distribuci, prostě si prohlédneme obsah repozitáře v některém vhodném programu,
třeba i v grafickém prostředı́). Taky je možné, že už máme tento balı́ček nainstalovaný.
Co se týče klientů, na strojı́ch s Linuxem už obvykle bývá nainstalován, ve Windows si můžeme
stáhnout třeba program puTTY nebo TTSSH.
Postup konfigurace a použı́vánı́ SSH můžeme najı́t na těchto odkazech:
• http://wiki.ubuntu.cz/SSH
C.9
DALŠÍ PŘÍKAZY
291
• http://www.xenocafe.com/tutorials/openssh linux/redhat/openssh linux redhat.php
(oproti návodu lze OpenSSH instalovat i jednodušeji z repozitářů)
• http://www.debianhelp.co.uk/ssh.htm
Pokud chceme jen stáhnout soubor z některého FTP nebo WWW serveru, nepotřebujeme výše
uvedené nástroje. Obvykle nám stačı́ webový prohlı́žeč nebo některý grafický klient, ale někdy se
hodı́ i nástroj pro použitı́ v textovém režimu. V tomto směru je k nezaplacenı́ přı́kaz wget.
Tento přı́kaz tedy sloužı́ ke stahovánı́ souborů z webu (podporuje protokoly FTP, HTTP, HTTPS
včetně proxy), dokonce zvládá i rekurzivnı́ stahovánı́ (napřı́klad HTML stránky včetně vnitřnı́
struktury, vytvořı́ se offline verze stránek) a dokáže navázat na dřı́vějšı́ přerušené stahovánı́.
Jednoduché přı́klady použitı́:
wget http://ftp.edunix.cz/pub/danix/Evolution2/dvd/DANIX-evol2-dvd-2007-11-04.iso
stahujeme DVD Linuxu Danix (pozor, vždy je třeba si zjistit adresu pro nejnovějšı́ verzi)
naváže na předchozı́ přerušené stahovánı́ (přı́kaz
je spouštěn v tomtéž pracovnı́m adresáři jako při předchozı́m stahovánı́)
wget -c ftp://adresa/dokument.pripona
Úkoly
Zobrazte si manuálovou stránku přı́kazu wget a zjistěte, jak se dá spustit
• ve „spider“ módu, tedy dokument, který má zadán ke stáhnutı́, nestáhne, ale jen zkontroluje,
zda je na svém mı́stě,
• bezpečně, aby se stahovalo s využitı́m některého šifrovánı́ (SSL nebo TLS),
• s rekurzivnı́m stahovánı́m.
Vyzkoušejte si stáhnutı́ některého dokumentu s přı́ponou PDF z webu (přı́padně ISO obsaz některé
distribuce Linuxu, pokud máte dostatečně rychlé připojenı́ bez limitů).
C.9
Dalšı́ přı́kazy
V Linuxu máme k dispozici velmi mnoho dalšı́ch přı́kazů, které souvisejı́ s adresami na sı́ti,
napřı́klad
mtr
nástroj pro aktivnı́ diagnostiku sı́tě (pozor, generuje provoz na sı́ti, podle něho pak vyhodnocuje parametry sı́tě)
dalšı́ diagnostický nástroj
lft
bezpečnostnı́ testovacı́ nástroj, který zası́lánı́m TCP nebo UDP paketů (lze určit parametrem) zjišt’uje, které porty jsou na přeposı́lajı́cı́ch (forwarding) zařı́zenı́ch v sı́ti otevřené
firewalk
program pro administraci zařı́zenı́ sloužı́cı́ho jako ethernetový bridge, jako prvnı́ parametr se zadává některý z přı́kazů pro konfiguraci mostu (lze napřı́klad zobrazovat informace,
pracovat s porty či s nastavenı́m protokolu STP, apod.)
brctl
tcpdump
$
C.9
DALŠÍ PŘÍKAZY
292
jednoduchý program, který nám může pomoci orientovat se v IP adresách sı́tı́/podsı́tı́/uzlů
(„IP kalkulačka“), ukázka použitı́ je v přı́kladu nı́že
ipcalc
host
použı́vá se podobně jako nslookup v neinteraktivnı́m režimu, tedy IP adresu přeložı́ na
název a naopak (oproti nslookup bere přednostně údaje ze souboru /etc/hosts, až když
tam údaj nenajde, táže se DNS serveru)
Pro konfiguraci bezdrátové sı́t’ové karty lze použı́t nástroje iwlist a iwconfig.
Přı́klad
Ukážeme si práci se zajı́mavým přı́kazem ipcalc, který podle zadané IP adresy podsı́tě vypı́še
masku, inverznı́ masku, rozsah adres uzlů v zadané podsı́ti, broadcast adresu a počet možných
uzlů v sı́ti. Přı́kaz chceme spustit na stanici s nainstalovaným Ubuntu. Tato distribuce sice dotyčný nástroj ve výchozı́ instalaci neobsahuje, ale dokáže poradit, jakým způsobem máme nástroj
nainstalovat:
sarka@notebook:˜$ ipcalc 10.1.0.0/16
The program ’ipcalc’ is currently not installed.
sudo apt-get install ipcalc
You can install it by typing:
M
Takže program nenı́ nainstalován. Ale byli jsme upozorněni, že se nacházı́ v repozitáři (jsme připojeni k Internetu, máme přı́stup do repozitářů Ubuntu), máme před očima přı́kaz, kterým program
nainstalujeme. Protože známe administrátorské heslo, nenı́ to problém (všimněte si přı́kazu sudo,
který v Ubuntu a některých dalšı́ch distribucı́ch sloužı́ k zı́skánı́ vyššı́ch přı́stupových oprávněnı́).
sarka@notebook:˜$ sudo apt-get install ipcalc
[sudo] password for sarka: **************
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages were automatically installed and are no longer required:
python-pylibacl python-brasero rdiff-backup python-pyxattr
Use ’apt-get autoremove’ to remove them.
The following NEW packages will be installed:
ipcalc
0 upgraded, 1 newly installed, 0 to remove and 378 not upgraded.
Need to get 26.6kB of archives.
After this operation, 131kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu/ maverick/universe ipcalc all 0.41-2 [26.6kB]
Fetched 26.6kB in 0s (72.0kB/s)
Selecting previously deselected package ipcalc.
(Reading database ... 162465 files and directories currently installed.)
Unpacking ipcalc (from .../archives/ipcalc_0.41-2_all.deb) ...
Processing triggers for man-db ...
Setting up ipcalc (0.41-2) ...
M
Instalace je hotova, restartovat netřeba (nejsme přece ve Windows), tedy konečně můžeme spustit
přı́kaz, jako parametr zadáme IP adresu (pod)sı́tě včetně délky prefixu:
sarka@notebook:˜$ ipcalc 10.1.0.0/16
Address:
Netmask:
Wildcard:
10.1.0.0
255.255.0.0 = 16
0.0.255.255
00001010.00000001. 00000000.00000000
11111111.11111111. 00000000.00000000
00000000.00000000. 11111111.11111111
M
C.9
DALŠÍ PŘÍKAZY
=>
Network:
HostMin:
HostMax:
Broadcast:
Hosts/Net:
10.1.0.0/16
10.1.0.1
10.1.255.254
10.1.255.255
65534
293
00001010.00000001. 00000000.00000000
00001010.00000001. 00000000.00000001
00001010.00000001. 11111111.11111110
00001010.00000001. 11111111.11111111
Class A, Private Internet
Existujı́ různé nástroje pro testovánı́ zabezpečenı́ sı́tě, které nejsou součástı́ běžných distribucı́,
ale rozhodně stojı́ za to si je stáhnout a použı́vat. Napřı́klad SATAN 16 (System Administrators
Tool for Analyzing Networks) procházı́ celou sı́t’ a provádı́ bezpečnostnı́ testy. Je oblı́bený jak
u administrátorů, tak i u hackerů, i když každý z nich má samozřejmě jinou motivaci.
Dalšı́ informace:
• Zajı́mavý tutoriál o sı́tı́ch v Linuxu najdeme na adrese
http://linux-ip.net/html/part-concepts.html.
• http://www.linuxsoft.cz/wifi/
• http://www.root.cz/serialy/linux-jako-internetova-gateway/
• http://www.root.cz/clanky/luci-webove-rozhrani-pro-openwrt/
• ČEČÁK, O. Linux v přı́kazech – práce s Wi-Fi [online]. Dostupné na
http://www.linuxsoft.cz/article.php?id article=1351
16
Ke staženı́ na http://www.porcupine.org/satan/.