Sˇa´rka Vavrecˇkova´
Pocˇı´tacˇove´ sı´teˇ a decentralizovane´ syste´my pro magistersky´ stupenˇ studia
Slezska´ univerzita v Opaveˇ Filozoficko-prˇ´ırodoveˇdecka´ fakulta ´ stav informatiky U Opava, poslednı´ aktualizace 4. cˇervna 2015
Anotace: Tato skripta jsou urcˇena pro studenty prˇedmeˇtu Pocˇ´ıtacˇove´ sı´teˇ a decentralizovane´ syste´my. Prˇedpokla´dajı´ alesponˇ za´kladnı´ znalosti v oblasti pocˇ´ıtacˇovy´ch sı´tı´, navazujeme na prˇedmeˇt Pocˇ´ıtacˇova´ sı´t’a Internet na bakala´rˇske´m stupni studia.
Pocˇı´tacˇove´ sı´teˇ a decentralizovane´ syste´my RNDr. Sˇa´rka Vavrecˇkova´, Ph.D. Dostupne´ na: http://fpf.slu.cz/~vav10ui/sitedec.html ´ stav informatiky U Filozoficko-prˇ´ırodoveˇdecka´ fakulta Slezska´ univerzita v Opaveˇ Bezrucˇovo na´m. 13, 746 01 Opava Sa´zeno v syste´mu LATEX
Tato inovace prˇedmeˇtu Pocˇ´ıtacˇove´ sı´teˇ a decentralizovane´ syste´my je spolufinancova´na Evropsky´m socia´lnı´m fondem a Sta´tnı´m rozpocˇtem CˇR, projekt cˇ. CZ.1.07/2.3.00/09.0197, „Posı´lenı´ konkurenceschopnosti vy´zkumu a vy´voje informacˇnı´ch technologiı´ v Moravskoslezske´m kraji“.
Prˇedmluva
Co najdeme v teˇchto skriptech ´ stavu informatiky Slezske´ univerTato skripta jsou urcˇena pro studenty informaticky´ch oboru˚ na U zity v Opaveˇ, a to na magisterske´m stupni. Za´beˇr skript je velmi sˇiroky´. Prˇesto, zˇe v prˇedmeˇtu ma´me pouze prˇedna´sˇky, najdeme zde i prˇ´ıklady, zejme´na v oblasti sı´t’ovy´ch funkcı´ v operacˇnı´ch syste´mech Windows a Linux. Neˇktere´ prˇ´ıklady jsou vlozˇeny prˇ´ımo do textu, ale veˇtsˇina je zarˇazena do prˇ´ıloh B a C. Neˇktere´ oblasti jsou take´ „navı´c“ (jsou oznacˇeny ikonami fialove´ barvy), ty nejsou probı´ra´ny a ani se neobjevı´ na testech – jejich u´kolem je motivovat k dalsˇ´ımu samostatne´mu studiu nebo poma´hat v budoucnu prˇi zı´ska´va´nı´ dalsˇ´ıch informacı´ dle potrˇeby v zameˇstna´nı´. Prˇedpokla´da´me, zˇe studentu˚m jesˇteˇ zu˚stalo neˇco ze znalostı´ nabyty´ch v bakala´rˇske´m studiu (prˇedmeˇt Pocˇ´ıtacˇova´ sı´t’a Internet). Prˇesto se prˇedmeˇty cˇa´stecˇneˇ prˇekry´vajı´, protozˇe pameˇt’studentu˚ je deˇrava´ a je to prˇece tak da´vno :-).
Znacˇenı´ Ve skriptech se pouzˇ´ıvajı´ na´sledujı´cı´ barevne´ ikony: • Nove´ pojmy, na´zvy souboru˚, obecne´ postupy, pouzˇ´ıvane´ symboly, apod. jsou znacˇeny modry´m symbolem v pozna´mce na okraj, ktery´ vidı´me take´ zde vpravo.
P
• Konkre´tnı´ postupy a na´stroje (prˇ´ıkazy, programy, soubory, skripty), zpu˚soby rˇesˇenı´ ru˚zny´ch situacı´, do ktery´ch se mu˚zˇe administra´tor dostat, syntaxe prˇ´ıkazu˚ atd. jsou znacˇeny take´ modrou ikonou.
$
• Zvla´sˇt’ je take´ vyznacˇen text, ktery´ je obvykle vy´stupem probı´rany´ch prˇ´ıkazu˚ (vcˇetneˇ teˇch, jejichzˇ spusˇteˇnı´ vyzˇaduje vysˇsˇ´ı prˇ´ıstupova´ opra´vneˇnı´) nebo mu˚zˇe jı´t o obsah neˇktery´ch souboru˚. Barva ikony je oranzˇova´.
M
iii
iv
• V neˇktery´ch prˇ´ıpadech si lze vybrat urcˇity´ pocˇet z neˇkolika mozˇnostı´, nenı´ trˇeba se ucˇit vsˇe. Naprˇ´ıklad v prvnı´ kapitole se studenti nemusı´ ucˇit vsˇechny standardizacˇnı´ instituce, ale vyberou si jen neˇktere´ z nich. • Neˇktere´ cˇa´sti textu jsou oznacˇeny fialovou ikonou, cozˇ znamena´, zˇe jde o nepovinne´ u´seky, ktere´ nejsou probı´ra´ny (veˇtsˇinou; studenti si je mohou podle za´jmu vyzˇa´dat nebo sami prostudovat). Jejich u´cˇelem je dobrovolne´ rozsˇ´ırˇenı´ znalostı´ studentu˚ o pokrocˇila´ te´mata, na ktera´ obvykle prˇi vy´uce nezby´va´ moc cˇasu. • Zˇlutou ikonou jsou oznacˇeny odkazy, na ktery´ch lze zı´skat dalsˇ´ı informace o te´matu. Mu˚zˇe jı´t o zpu˚soby zı´ska´nı´ na´poveˇdy, nejcˇasteˇji vsˇak u te´to ikony najdeme odkazy na internet. • Cˇervena´ je ikona pro upozorneˇnı´ a pozna´mky. Opticky jsou odlisˇeny take´ rˇesˇene´ prˇ´ıklady a nerˇesˇene´ u´lohy. Prˇı´klad Takto vypada´ prostrˇedı´ s prˇ´ıkladem. Nejvı´c prˇ´ıkladu˚ najdeme v prˇ´ıloha´ch B (Windows) a C (Linux).
´ koly U Ota´zky a u´koly, na´meˇty na vyzkousˇenı´, ktere´ se doporucˇuje prˇi procvicˇova´nı´ ucˇiva prova´deˇt, jsou uzavrˇeny v tomto prostrˇedı´. Pokud je v prostrˇedı´ vı´ce u´kolu˚, jsou cˇ´ıslova´ny.
Na stra´nka´ch prˇedmeˇtu je k dispozici orientacˇnı´ seznam ota´zek a u´kolu˚, ktere´ se mohou objevit na zkousˇkove´ pı´semce, ovsˇem v pı´semce se mohou objevit mı´rne´ odlisˇnosti.
J
L
Obsah
1
2
Za´kladnı´ pojmy a na´stroje 1.1 Standardizacˇnı´ instituce . . . . . . . . . . . 1.2 Adresova´nı´ . . . . . . . . . . . . . . . . . . . 1.2.1 Typy adres . . . . . . . . . . . . . . . 1.2.2 Mapova´nı´ adres . . . . . . . . . . . . 1.3 Model TCP/IP . . . . . . . . . . . . . . . . . 1.3.1 Vrstvy . . . . . . . . . . . . . . . . . 1.3.2 Vrstva sı´t’ove´ho rozhranı´ . . . . . . . 1.3.3 Protokoly sı´t’ove´ vrstvy . . . . . . . 1.3.4 Protokoly transportnı´ vrstvy . . . . 1.3.5 Protokoly aplikacˇnı´ vrstvy . . . . . . 1.4 Sady protokolu˚ . . . . . . . . . . . . . . . . 1.5 Protokol IPv4 . . . . . . . . . . . . . . . . . 1.5.1 IPv4 datagramy . . . . . . . . . . . . 1.5.2 Adresy IPv4 . . . . . . . . . . . . . . 1.5.3 Prˇeklad adres . . . . . . . . . . . . . 1.5.4 Adresy podsı´teˇ . . . . . . . . . . . . 1.5.5 Jak stanice mu˚zˇe zı´skat IPv4 adresu 1.6 Protokol IPv6 . . . . . . . . . . . . . . . . . 1.6.1 IPv6 datagramy . . . . . . . . . . . . 1.6.2 Adresy IPv6 . . . . . . . . . . . . . . 1.6.3 Jak stanice mu˚zˇe zı´skat IPv6 adresu 1.6.4 Zo´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 Za´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ı´teˇ 4.1 Spojove´ 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’ove´ prvky . . . . . . . . . . . . . . . . 2.1.3 Linkova´ vrstva . . . . . . . . . . . . . . Prˇenosove´ techniky . . . . . . . . . . . . . . . . 2.2.1 Zajisˇteˇnı´ prˇenosu pro polovicˇnı´ duplex 2.2.2 Zajisˇteˇnı´ prˇenosu pro plny´ duplex . . . 2.2.3 Zajisˇteˇnı´ prˇijetı´ dat . . . . . . . . . . . . 2.2.4 VLAN . . . . . . . . . . . . . . . . . . . Fyzicka´ vrstva . . . . . . . . . . . . . . . . . . . 2.3.1 NIC . . . . . . . . . . . . . . . . . . . . . 2.3.2 Ko´dova´nı´ signa´lu . . . . . . . . . . . . . 2.3.3 Fyzicka´ 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 Krˇ´ızˇ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 . . . . . . . . . . . . . .
Dalsˇı´ te´mata k loka´lnı´m sı´tı´m 3.1 EtherChannel . . . . . . . . . . . . . . . . . 3.1.1 Vlastnosti . . . . . . . . . . . . . . . ˇ ´ızenı´ toku . . . . . . . . . . . . . . 3.1.2 R 3.1.3 Protokoly . . . . . . . . . . . . . . . 3.2 SAN sı´teˇ . . . . . . . . . . . . . . . . . . . . 3.2.1 Fibre Channel . . . . . . . . . . . . . 3.2.2 iSCSI . . . . . . . . . . . . . . . . . . 3.3 Virtua´lnı´ loka´lnı´ sı´t’– VLAN . . . . . . . . . 3.3.1 Cˇlenstvı´ ve skupineˇ . . . . . . . . . . 3.3.2 Urcˇenı´ cˇlenstvı´ . . . . . . . . . . . . 3.3.3 Zajisˇteˇ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 Rozsˇ´ırˇenı´ PPP . . . . . . . . 4.1.6 IEEE 802.2 (LLC) . . . . . . X.25 . . . . . . . . . . . . . . . . . . 4.2.1 Zarˇ´ızenı´ v sı´ti . . . . . . . . 4.2.2 Adresy a nava´za´nı´ spojenı´ . 4.2.3 Vrstvy a protokoly . . . . . Frame Relay . . . . . . . . . . . . . 4.3.1 Zarˇ´ızenı´ v sı´ti . . . . . . . . 4.3.2 Garance informacˇnı´ho toku 4.3.3 Spojova´ vrstva a adresace . 4.3.4 LMI . . . . . . . . . . . . . . 4.3.5 Tabulky na zarˇ´ızenı´ch . . . ˇ esˇenı´ . . . . . . . . . . . . 4.3.6 R
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
70 70 71 72 72 73 73 74 75 75 76 77 78 79
. . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
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
ATM . . . . . . . . . . . . . . . . . 4.4.1 Zarˇ´ızenı´ a cesty v sı´ti . . . . 4.4.2 Bunˇky . . . . . . . . . . . . 4.4.3 Architektura . . . . . . . . . 4.4.4 QoS . . . . . . . . . . . . . . 4.4.5 Adresace a nava´za´nı´ spojenı´ 4.4.6 ILMI . . . . . . . . . . . . . . 4.4.7 Spolupra´ce s LAN . . . . . . MPLS . . . . . . . . . . . . . . . . . . 4.5.1 Prˇepı´na´nı´ znacˇek . . . . . . . 4.5.2 Smeˇrova´nı´ v MPLS . . . . . . 4.5.3 Vytva´rˇenı´ cest . . . . . . . . . 4.5.4 Dalsˇ´ı mozˇnosti . . . . . . . . Opticke´ prˇenosove´ cesty . . . . . . . 4.6.1 SONET/SDH . . . . . . . . . 4.6.2 WDM a DWDM . . . . . . . .
Data a telekomunikacˇnı´ sı´teˇ 5.1 Dial-up technologie . . . . . . . . . . . . . 5.1.1 Shannonu˚v teore´m . . . . . . . . . 5.1.2 Telefonnı´ sı´t’ . . . . . . . . . . . . . 5.1.3 Prˇenos dat na telefonnı´ch linka´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 straneˇ ISP . . . . . . . . . 5.4.4 Dalsˇ´ı xDSL technologie . . . . . . Telefonnı´ sı´teˇ a telefonnı´ u´strˇedny . . . . 5.5.1 Slucˇova´nı´ linek . . . . . . . . . . . 5.5.2 Telefonnı´ u´strˇedny . . . . . . . . . VoIP . . . . . . . . . . . . . . . . . . . . . . 5.6.1 Princip . . . . . . . . . . . . . . . . 5.6.2 Protokoly . . . . . . . . . . . . . . 5.6.3 Videotelefonie a videokonference .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
Bezdra´tove´ a mobilnı´ sı´teˇ 6.1 Bezdra´tove´ technologie . . . . . . . . . . . . . . . . . . . 6.2 Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.1 Za´kladnı´ princip . . . . . . . . . . . . . . . . . . 6.2.2 Rezˇimy . . . . . . . . . . . . . . . . . . . . . . . . 6.2.3 Fyzicka´ vrstva v ISO/OSI, frekvencˇnı´ spektrum 6.2.4 Struktura PHY, modulace . . . . . . . . . . . . . 6.2.5 Ante´ny a MIMO . . . . . . . . . . . . . . . . . . 6.2.6 Podvrstva MAC . . . . . . . . . . . . . . . . . . . ´ vod do sˇifrova´nı´ . . . . . . . . . . . . . . . . . 6.2.7 U 6.2.8 AAA . . . . . . . . . . . . . . . . . . . . . . . . . 6.2.9 Zabezpecˇenı´ Wi-Fi sı´tı´ . . . . . . . . . . . . . . . 6.2.10 Wi-fi cˇtvrte´ a pa´te´ generace . . . . . . . . . . . . 6.3 WiMAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6.3.1 Vlastnosti . . . . . . . . . . . . . . . . . . . . . . 6.3.2 Zarˇ´ızenı´ . . . . . . . . . . . . . . . . . . . . . . . 6.4 Mobilnı´ technologie . . . . . . . . . . . . . . . . . . . . . 6.4.1 Prvnı´ generace (1G) . . . . . . . . . . . . . . . . 6.4.2 Druha´ generace (2G) . . . . . . . . . . . . . . . . 6.4.3 Prˇechodova´ generace (2.5G) . . . . . . . . . . . . 6.4.4 Trˇetı´ generace (3G) . . . . . . . . . . . . . . . . . 6.4.5 Dalsˇ´ı 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 syste´mu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144 7.1.2 Distribuovane´ syste´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 Smeˇrovacˇ . . . . . . . . . . . . . . . . 7.4.2 Smeˇrova´nı´ . . . . . . . . . . . . . . . . 7.4.3 Smeˇ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 Softwarovy´ smeˇrovacˇ . . . . . . . . . CESNET2 . . . . . . . . . . . . . . . . . . . . . 7.5.1 Multimedia´lnı´ prˇenosy . . . . . . . . . 7.5.2 Metacentrum, vy´pocˇetnı´ gridy . . . . 7.5.3 CESNET CSIRT, CERTS . . . . . . . . QoS . . . . . . . . . . . . . . . . . . . . . . . . 7.6.1 Princip QoS . . . . . . . . . . . . . . . 7.6.2 DiffServ . . . . . . . . . . . . . . . . . Jmenne´ a adresa´rˇove´ sluzˇby . . . . . . . . . . 7.7.1 Princip a struktura DNS . . . . . . . . 7.7.2 Dotazy v DNS . . . . . . . . . . . . . . 7.7.3 DNS za´znamy a forma´t dotazu . . . . 7.7.4 Bezpecˇnost v DNS . . . . . . . . . . . 7.7.5 Adresa´rˇove´ sluzˇby a Active Directory
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Bezpecˇnost a spra´va sı´tı´ 8.1 Bezpecˇnost v sı´tı´ch . . . . . . . . . . . . . . . . . . . . . 8.1.1 Typy u´toku˚ . . . . . . . . . . . . . . . . . . . . . 8.1.2 Zabezpecˇenı´ na jednotlivy´ch vrstva´ch ISO/OSI 8.2 Sı´t’ovy´ analyza´tor . . . . . . . . . . . . . . . . . . . . . . 8.3 Firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.3.1 Princip firewallu . . . . . . . . . . . . . . . . . . 8.3.2 Typy filtrova´nı´ . . . . . . . . . . . . . . . . . . . 8.3.3 OpenWRT . . . . . . . . . . . . . . . . . . . . . . 8.4 VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.4.1 IPSec VPN – na sı´t’ove´ vrstveˇ . . . . . . . . . . . 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 Spra´va sı´teˇ . . . . . . . . . . . . . . 8.5.1 NMS . . . . . . . . . . . . . 8.5.2 ISO model rˇ´ızenı´ sı´teˇ . . . . 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 Pouzˇ´ıva´nı´ protokolu SNMP 8.7 Syslog . . . . . . . . . . . . . . . . . 8.8 Monitorova´nı´ sı´teˇ . . . . . . . . . . 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 Dohledove´ syste´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 doporucˇene´ literatury
211
Prˇı´lohy
213
A Co uzˇ bychom meˇli zna´t A.1 Loka´lnı´ sı´teˇ . . . . . . . . . . A.1.1 Vlastnosti spoju˚ . . . A.1.2 Vlastnosti sluzˇeb . . A.1.3 Multiplexova´nı´ . . . A.1.4 Prˇ´ıstupove´ metody . ˇ ´ızenı´ toku dat v sı´ti A.1.5 R
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
215 215 215 217 218 219
. . . . A.2 WAN sı´teˇ . . . . . . . . . . . . . . . A.2.1 Okruhy . . . . . . . . . . . . A.2.2 Komunikace v rozlehle´ 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 standardu˚ IEEE 802 A.4.2 IEEE 802.1 . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
B Pra´ce s adresami a sı´teˇmi ve Windows B.1 Proble´my prˇi pouzˇ´ıva´nı´ prˇ´ıkazu˚ ve Windows . . . B.2 Soubory souvisejı´cı´ se sı´teˇmi . . . . . . . . . . . . . B.3 Pra´ce s adresami a sı´t’ovy´mi kartami . . . . . . . . B.3.1 Za´kladnı´ pra´ce s IP adresami – ipconfig B.3.2 Prˇeklad adres – arp a nslookup . . . . . B.3.3 Smeˇrova´nı´ – route . . . . . . . . . . . . . . B.3.4 Mala´ sı´t’a skupina (workgroup) . . . . . . B.4 Testova´nı´ a statistiky . . . . . . . . . . . . . . . . . B.4.1 Testova´nı´ cesty a pru˚chodnosti . . . . . . . B.4.2 Statistiky v netstatu . . . . . . . . . . . . B.5 Sluzˇba WMI a program wmic . . . . . . . . . . . . B.6 Firewall ve Windows . . . . . . . . . . . . . . . . . B.7 Dalsˇ´ı prˇ´ıkazy . . . . . . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . . . . . . . . .
. . . . . .
. . . . . . . . . . . . .
. . . . . .
. . . . . . . . . . . . .
. . . . . .
. . . . . . . . . . . . .
. . . . . .
. . . . . . . . . . . . .
. . . . . .
. . . . . . . . . . . . .
. . . . . .
. . . . . . . . . . . . .
C Pra´ce s adresami a sı´teˇmi v Linuxu C.1 Specializovane´ distribuce . . . . . . . . . . . . . . . . . . . . . C.2 Soubory souvisejı´cı´ se sı´teˇmi . . . . . . . . . . . . . . . . . . . . C.3 Starsˇ´ı prˇ´ıkazy pro pra´ci s adresami . . . . . . . . . . . . . . . . C.4 Mechanismus iproute2 (prˇ´ıkaz ip) – adresy, sı´t’, smeˇrova´nı´ C.4.1 Konfigurace sı´t’ove´ho rozhranı´ a adres . . . . . . . . . . C.4.2 Smeˇrova´nı´ a filtrova´nı´ . . . . . . . . . . . . . . . . . . . C.4.3 Objevova´nı´ sı´teˇ . . . . . . . . . . . . . . . . . . . . . . . C.4.4 Tunely . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.5 Prˇeklad na´zvu˚ . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.5.1 Na´zev pocˇ´ıtacˇe . . . . . . . . . . . . . . . . . . . . . . . C.5.2 Resolver a soubor resolv.conf . . . . . . . . . . . . C.5.3 Testova´nı´ DNS . . . . . . . . . . . . . . . . . . . . . . . C.5.4 Zjisteˇnı´ informacı´ o dome´neˇ . . . . . . . . . . . . . . . . C.6 Firewall v Linuxu . . . . . . . . . . . . . . . . . . . . . . . . . . C.6.1 Princip firewallu . . . . . . . . . . . . . . . . . . . . . . C.6.2 Za´kladnı´ vnitrˇnı´ prˇ´ıkazy a parametry pro filtrova´nı´ . . C.6.3 SPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C.6.4 NAT a masˇkara´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 Oznacˇova´nı´ paketu˚ C.6.6 Skripty . . . . . . . C.6.7 Ulozˇenı´ zmeˇn . . . C.7 Testova´nı´ a statistiky . . . C.7.1 Za´kladnı´ na´stroje . C.7.2 Pokrocˇile´ testova´nı´ C.8 Vzda´leny´ prˇ´ıstup . . . . . C.9 Dalsˇ´ı prˇ´ıkazy . . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
284 286 286 287 287 290 290 291
Kapitola
1
Za´kladnı´ pojmy a na´stroje Probereme nejdu˚lezˇiteˇjsˇ´ı standardizacˇnı´ instituce, ktere´ se angazˇujı´ v oblasti pocˇ´ıtacˇovy´ch sı´tı´, a da´le se podı´va´me na adresova´nı´, model TCP/IP a zejme´na se budeme veˇnovat protokolu˚m IPv4 a IPv6. V te´to kapitole jizˇ prˇedpokla´da´me, zˇe studenti ovla´dajı´ te´mata z prˇ´ılohy A.
1.1
Standardizacˇnı´ instituce
Slucˇitelnost produktu˚ ru˚zny´ch vy´robcu˚ je du˚lezˇita´ prˇedevsˇ´ım z du˚vodu mozˇnosti spolupra´ce zarˇ´ızenı´. Rozlisˇujeme tato rˇesˇenı´: 1. Proprieta´lnı´ rˇesˇenı´ (proprietary) – vy´robce si vytvorˇ´ı zcela vlastnı´ rˇesˇenı´ neslucˇitelne´ s jiny´mi,
P
2. Standard – rˇesˇenı´ se sta´va´ standardem (protokoly, konvence, parametry) z du˚vodu zajisˇteˇnı´ vza´jemne´ kompatibility zarˇ´ızenı´ odpovı´dajı´cı´ch tomuto standardu; za´visı´ na typu organizace, ktera´ standard vyda´va´: • doporucˇenı´ – standard vyda´n neˇkterou mezina´rodnı´ standardizacˇnı´ institucı´, • norma – standard stanoven vla´dnı´ institucı´, povinny´. Podı´va´me se na neˇkolik nejzna´meˇjsˇ´ıch standardizacˇnı´ch institucı´. Nenı´ nutne´ zna´t u´plneˇ vsˇechny, ale meˇli bychom alesponˇ veˇdeˇt, zˇe existujı´ a cˇ´ım se zaby´vajı´, v na´sledujı´cı´m textu se na neˇktere´ z nich budeme odvola´vat. Mezina´rodnı´ telekomunikacˇnı´ unie (ITU – International Telecommunications Union) je celosveˇtova´ organizace (pracuje v ra´mci OSN). Ma´ trˇi cˇa´sti (reorganizace byla provedena v roce 1993): • radiokomunikacˇnı´ sektor (ITU-R), • telekomunikacˇnı´ normalizacˇnı´ sektor (ITU-T), • sektor rozvoje telekomunikacı´ (ITU-D). ITU-T (pu˚vodneˇ CCITT – Commite´ Consultatif International de Te´legraphique et Te´le´phonique) je cˇa´st ITU, jejı´zˇ cˇinnost souvisı´ take´ s pocˇ´ıtacˇovy´mi sı´teˇmi. Cˇleny s hlasovacı´m pra´vem jsou zemeˇ 1
J
STANDARDIZACˇNI´ INSTITUCE
1.1
2
zastoupene´ telekomunikacˇnı´mi organizacemi z jednotlivy´ch zemı´, cˇleny bez hlasovacı´ho pra´va mohou by´t i dalsˇ´ı organizace. Cˇlenstvı´ nenı´ bezplatne´. Je to nevla´dnı´ instituce, vyda´va´ doporucˇenı´. Nejzna´meˇjsˇ´ı je doporucˇenı´ X.25 pro verˇejne´ datove´ sı´teˇ. ISO (International Organization for Standardization) je nevla´dnı´ organizace, vyda´va´ doporucˇenı´ (nazy´vajı´ se normy, ale nejsou prˇ´ımo za´vazne´). Cˇleny jsou na´rodnı´ standardizacˇnı´ organizace z jednotlivy´ch zemı´. ISO ma´ hierarchickou strukturu: cˇlenı´ se na asi 200 technicky´ch komisı´ (TC – Technical Committee), kazˇda´ TC se cˇlenı´ na subkomise (SC – Subcommittee), kazˇda´ SC se cˇlenı´ na pracovnı´ skupiny (WG). Na´vrhy jsou „zespoda“, od pracovnı´ch skupin – vytvorˇ´ı working paper (WP, pracovnı´ verze), dalsˇ´ım stupneˇm je committee draft (CD, koncept vytvorˇeny´ komisı´, drˇ´ıve draft proposal), na´sleduje draft international standard (DIS, koncept mezina´rodnı´ normy), poslednı´m stupneˇm je international standard (IS, mezina´rodnı´ norma). Nejzna´meˇjsˇ´ım standardem te´to organizace je referencˇnı´ model ISO/OSI. Text tohoto standardu take´ vydala organizace ITU-T jako sve´ doporucˇenı´ X.200. IEEE (Institute of Electrical and Electronics Engineers) je profesnı´ sdruzˇenı´ americky´ch inzˇeny´ru˚ elektroniky a elektrˇiny s vlastnı´m standardizacˇnı´m orga´nem. Nejzna´meˇjsˇ´ım pocˇinem tohoto sdruzˇenı´ je skupina standardu˚ IEEE 802 pro (prˇeva´zˇneˇ) loka´lnı´ sı´teˇ. IEC (International Electrotechnical Commission) je jaky´si doplneˇk ISO. IEC a ISO spolu hodneˇ spolupracujı´, IEC ma´ na starosti vsˇe z pocˇ´ıtacˇovy´ch sı´tı´, co nenı´ v zameˇrˇenı´ ISO (tj. hlavneˇ specifikace elektricky´ch a elektronicky´ch zarˇ´ızenı´, fyzicka´ vrstva). ETSI (European Telecommunications Standard Institute) vytva´rˇ´ı evropske´ standardy v oblasti telekomunikacı´ (naprˇ´ıklad Euro-ISDN), hodneˇ spolupracuje s ostatnı´mi podobny´mi organizacemi (naprˇ´ıklad na GSM a jiny´ch mobilnı´ch sı´tı´ch). Cˇesky´ normalizacˇnı´ institut (CˇNI) je cˇeska´ organizace zajisˇt’ujı´cı´ vytva´rˇenı´ nasˇich na´rodnı´ch norem. Tato cˇinnost vsˇak uzˇ nenı´ povazˇova´na za prioritnı´, za du˚lezˇiteˇjsˇ´ı se povazˇuje harmonizace s mezina´rodnı´mi (prˇedevsˇ´ım evropsky´mi) normami, tedy u´kolem CˇNI je take´ shromazˇd’ova´nı´ a poskytova´nı´ informacı´ o mezina´rodnı´ch norma´ch a u´cˇast na mezina´rodnı´ spolupra´ci v tomto smeˇru. IAB (Internet Architecture Board) je rada pro architekturu Internetu. Vyda´va´ informace o konvencı´ch a sı´t’ovy´ch protokolech, tzv. RFC (Request for Comments), ktere´ jsou volneˇ dostupne´ na Internetu. Naprˇ´ıklad • • • • •
RFC 760 – pu˚vodnı´ na´vrh adresace IP, RFC 768 – protokol UDP, RFC 791 – popis protokolu IP, RFC 792 – protokol ICMP, RFC 793 – protokol TCP,
ADRESOVA´NI´
1.2
• • • • •
3
RFC 826 – protokol ARP, RFC 959 – protokol FTP, RFC 1878 – tabulky konverze adres pro podsı´teˇ v IP a prˇ´ıklady adresova´nı´, RFC 2460 – protokol IPv6, RFC 2462 – autokonfigurace adres IPv6, atd.
ANSI (American National Standards Institute) je nevla´dnı´ organizace, reprezentuje USA v ISO, nejzna´meˇjsˇ´ım standardem je ko´d ASCII, v oblasti sı´tı´ naprˇ´ıklad FDDI, ISDN, Frame Relay. EIA (Electronic Industries Assocation) sdruzˇuje vy´robce zarˇ´ızenı´ pro telekomunikace prˇedevsˇ´ım z USA, nejzna´meˇjsˇ´ım standardem je RS-232-C. Obecneˇ se zameˇrˇuje na specifikaci fyzicke´ u´rovneˇ zarˇ´ızenı´. TIA (Telecommunication Industries Assocation) je sdruzˇenı´ firem z oblasti telekomunikacˇnı´ch technologiı´, spolupracuje s EIA a zameˇrˇuje se na rozhranı´ a kabela´zˇ v telekomunikacˇnı´ch sı´tı´ch. Standardy vydane´ TIA (nebo EIA/TIA) by´valy pu˚vodneˇ oznacˇova´ny na´zvem zacˇ´ınajı´cı´m RS (Recommended Standard).
1.2 1.2.1
Adresova´nı´ Typy adres
Adresovy´ prostor mu˚zˇe by´t • hierarchicky´ – adresy majı´ strukturu vycha´zejı´cı´ z hierarchie sı´teˇ, obvykle´ u veˇtsˇ´ıch adresovy´ch prostoru˚, zarˇ´ızenı´ jsou cˇleneˇna do skupin a prˇ´ıp. podskupin • plochy´ (flat) – adresy nemajı´ vnitrˇnı´ strukturu, adresovy´ prostor nenı´ nijak cˇleneˇn na podprostory (male´ sı´teˇ) Adresy linkove´ vrstvy jsou typicky´m prˇ´ıkladem adres v ploche´m adresove´m prostoru. Tento typ adres prˇedevsˇ´ım jednoznacˇeneˇ urcˇuje zarˇ´ızenı´ v (loka´lnı´) sı´ti. MAC adresy (Media Access Control) patrˇ´ı k adresa´m, ktere´ se pouzˇ´ıvajı´ na linkove´ vrstveˇ, tedy se jedna´ o plochy´ model adresova´nı´ a musı´ (tedy meˇla by) jednoznacˇneˇ identifikovat zarˇ´ızenı´ v sı´ti. MAC adresa mu˚zˇe vypadat naprˇ´ıklad takto (hexadecima´lnı´ cˇ´ıslice, oddeˇlene´ pomlcˇkou nebo dvojtecˇkou): 00-0F-FE-12-34-AB
O MAC adresa´ch v jedne´ z na´sledujı´cı´ch sekcı´ (strana 8). Adresy sı´t’ove´ vrstvy (take´ virtua´lnı´, logicke´ adresy) vyuzˇ´ıvajı´ hierarchicky´ adresovy´ prostor. Narozdı´l od prˇedchozı´ch nejsou fixova´ny na konkre´tnı´ zarˇ´ızenı´, mohou by´t take´ dynamicky prˇideˇlova´ny. Typicky´m prˇ´ıkladem jsou IP adresy. IP adresy jsou definova´ny v protokolu IP. V soucˇasne´ dobeˇ se pouzˇ´ıvajı´ dveˇ verze – starsˇ´ı IPv4 je dnes beˇzˇneˇ dostupna´ prakticky na ktere´mkoliv sı´t’ove´m zarˇ´ızenı´, noveˇjsˇ´ı IPv6 sice (teoreticky) je dostupna´, ale tato verze protokolu jesˇteˇ rozhodneˇ nenı´ vsˇude zprovozneˇna.
P
ADRESOVA´NI´
1.2
4
IP adresa´m se budeme podrobneˇ veˇnovat pozdeˇji, ted’ jen strucˇneˇ pro ilustraci – IP adresa protokolu IPv4 se skla´da´ ze 4 cˇa´stı´, kazˇda´ cˇa´st je cˇ´ıslo zabı´rajı´cı´ 1 B. Obvykle se zapisuje jako cˇtverˇice decima´lnı´ch cˇ´ısel oddeˇleny´ch tecˇkou. IP adresy majı´ take´ vsˇeobecnou adresu – opeˇt jsou vsˇechny bity nastaveny na 1, tj. u IPv4 to je 255.255.255.255 (toto platı´ v ra´mci loka´lnı´ sı´teˇ). Podrobnosti v te´to kapitole v sekci o protokolu IP. Dome´nove´ adresy (na´zvy) se pouzˇ´ıvajı´ jako „uzˇivatelsky prˇ´ıveˇtiveˇjsˇ´ı“ obdoba IP adres (naprˇ´ıklad www.google.com je jedna z dome´novy´ch adres WWW serveru Googlu). Dome´nove´ adresy jsou take´ hierarchicke´ (pozor, v opacˇne´m porˇadı´ nezˇ IP adresy – zatı´mco u IP adresy je „nejsˇirsˇ´ı oblast“ vlevo na zacˇa´tku adresy, u dome´nove´ vpravo). Pro prˇeklad mezi dome´novy´m na´zvem a IP adresou se pouzˇ´ıvajı´ jmenne´ sluzˇby, na Internetu prˇedevsˇ´ım DNS. Dome´novy´m na´zvu˚m se veˇnujeme v kapitole o jmenny´ch sluzˇba´ch (str. 163).
1.2.2
Mapova´nı´ adres
Ru˚zne´ typy adres je trˇeba navza´jem mapovat. To lze prove´st trˇemi zpu˚soby: 1. Pouzˇ´ıva´nı´ mapovacı´ch tabulek, naprˇ´ıklad mezi vrstvami L2/L3 jde typicky o mapova´nı´ sı´t’ovy´ch adres na MAC adresy (tj. jejich vza´jemne´ prˇirˇazova´nı´) protokolem ARP, reverznı´ mapova´nı´ zajisˇt’uje protokol RARP (Reverse ARP). Podobny´ princip funguje i v DNS. 2. Pouzˇ´ıva´nı´ protokolu typu Hello, vza´jemne´ (pravidelne´) sdeˇlova´nı´ adres. 3. Vnorˇenı´ MAC adresy do sı´t’ove´ adresy nebo jina´ (algoritmizovatelna´) za´vislost MAC adresy na sı´t’ove´ adrese – predictable MAC addresses. Zatı´mco protokol IPv4 pouzˇ´ıva´ dynamicke´ mapova´nı´ pomocı´ ARP, IPv6 z du˚vodu zvy´sˇenı´ efektivity umozˇnˇuje take´ cˇa´stecˇne´ staticke´ mapova´nı´, kdy MAC adresa mu˚zˇe by´t soucˇa´stı´ IPv6 adresy. 1. Tabulky. Prˇeklad sı´t’ovy´ch IPv4 adres na MAC adresy (tj. mapova´nı´ sı´t’ove´ adresy na MAC adresu) pomocı´ protokolu ARP, resp. NDP pro IPv6:
P
• ARP tabulky slouzˇ´ı k evidova´nı´ mapova´nı´ sı´t’ovy´ch adres na MAC adresy (ke kazˇde´mu sı´t’ove´mu adapte´ru je vlastnı´ ARP tabulka), • pokud ARP protokol nenajde IP adresu v ARP tabulce, vysˇle broadcast do LAN, • kazˇda´ stanice porovna´ svou IP adresu s adresou ve zpra´veˇ, a pokud souhlası´, odpovı´ paketem se svou MAC adresou („vyplnı´“ chybeˇjı´cı´ u´daj), • dotazujı´cı´ se stanice zarˇadı´ u´daj do ARP tabulky a pouzˇije ho, • pokud se IP adresa nenacha´zı´ v LAN, ale ve vzda´lene´ sı´ti, odesˇle se dotaz na bra´nu, ktera´ ho posˇle da´le. ARP je typicky´ pro IPv4 adresy. Pro IPv6 se pouzˇ´ıva´ mechanismus (protokol) NDP, ktery´ funguje podobneˇ (viz str. 1.6.5). Podle prˇedem ulozˇeny´ch informacı´ se prˇekla´da´ take´ v DNS (veˇtsˇinou jmenna´ adresa na IP adresu). 2. Protokol Hello. Kdyzˇ se syste´m prˇihlasˇuje do sı´teˇ, rozesˇle broadcast (Hello messages) do sı´teˇ – informuje o sve´ MAC adrese, resp. o tom, zˇe je funkcˇnı´ a dostupny´. Ostatnı´ zarˇ´ızenı´ v sı´ti zasˇlou odpoveˇd’. V pravidelny´ch intervalech se tento broadcast opakuje.
P
1.3
MODEL TCP/IP
5
Urcˇitou formou tohoto principu je mechanismus KeepAlive, kdy typicky server ubezpecˇuje sve´ho souseda, zˇe „zˇije“ – pokud zpra´va KeepAlive nedorazı´, znamena´ to, zˇe server nenı´ dostupny´ a tedy je nutne´ zprovoznit cˇi zprˇ´ıstupnit pod danou adresou za´lozˇnı´ server. S dalsˇ´ı formou tohoto principu se setka´va´me pomeˇrneˇ cˇasto – bezdra´tovy´ access point pravidelneˇ ohlasˇuje beacon ra´mcem cele´ sı´ti sve´ kontaktnı´ u´daje (prˇedevsˇ´ım SSID), dı´ky tomu je „viditelny´“. 3. Predictable MAC adresses. Tento mechanismus spocˇ´ıva´ v tom, zˇe MAC adresa je odvoditelna´ ze sı´t’ove´ adresy. V soucˇasne´ dobeˇ mechanismus pouzˇ´ıvajı´ tyto protokoly:
P
• Xerox Network Systems (XNS), • Novell Internetwork Packet Exchange (IPX), • DECnet Phase IV, • cˇa´stecˇneˇ to lze rˇ´ıci o IPv6 (klientska´ cˇa´st IP adresy se mu˚zˇe odvodit z cˇ´ısla EUI-64, ktere´ lze jednodusˇe zjistit z MAC adresy), podrobnosti v sekci o tomto protokolu. Referenc ˇnı´ model ISO/OSI
Protocol Data Units:
Vy ´ znam:
sˇifrova´nı´,
Adresova´nı´:
L7
Aplikacˇnı´ vrstva
Poskytuje sluzˇby aplikacı´m – manipulace s daty, se´manticke´ prˇeklady, bezpecˇnost.
L6
Prezentacˇnı´ vrstva
Prova´dı´ konverze dat – (de)komprese, konverze do/z jine´ho datove´ho forma´tu, . . .
data, zpra´vy
L5
Relacˇnı´ vrstva
L4
Transportnı´ vrstva
Zbezpecˇuje spojenı´ mezi dveˇma koncovy´mi body; segmentace proudu dat prˇed prˇenosem, poskla´da´nı´ po neˇm.
segmenty
porty
L3
Sı´t’ova´ vrstva
Prˇeposı´la´ data k dane´mu cı´li, prova´dı´ smeˇrova´nı´, pracuje s logickou topologiı´ sı´teˇ.
pakety, datagramy
IP addresy
Pracuje s fyzickou topologiı´ sı´teˇ, synchronizuje prˇenos, zde obvykle pracujı´ LAN rˇesˇenı´.
ra´mce
ˇ ´ıdı´ proces posı´la´nı´ a prˇijı´ma´nı´ R proudu dat, definuje fyzika´lnı´ a elektricke´ specifikace zarˇ´ızenı´ (rozhranı´).
bity
L2 L1
Linkova´ vrstva Fyzicka´ vrstva
Otevı´ra´, ˇr´ıdı´ and ukoncˇuje konverzace mezi dveˇma vzda´leny´mi aplikacemi.
LLC MAC
MAC addresy
Obra´zek 1.1: Referencˇnı´ model ISO/OSI
1.3
Model TCP/IP
Model TCP/IP je velmi u´zce spojova´n s Internetem. Pouzˇ´ıvajı´ se tyto pojmy: • sı´t’ovy´ segment je loka´lnı´ sı´t’schopna´ samostatne´ existence, uvnitrˇ se pouzˇ´ıvajı´ nejvy´sˇe rozbocˇovacˇe,
P
1.3
MODEL TCP/IP
6
• podsı´t’ (subnet) je fyzicky´ sı´t’ovy´ segment nebo virtua´lnı´ sı´t’pouzˇ´ıvajı´cı´ stejnou podsı´t’ovou IP adresu, • sı´t’ je jeden nebo vı´ce sı´t’ovy´ch segmentu˚ s ru˚zny´mi typy mezilehly´ch zarˇ´ızenı´ (opakovacˇe, prˇepı´nacˇe, mosty), podsı´teˇ v ra´mci jedne´ sı´teˇ by´vajı´ oddeˇleny smeˇrovacˇi (routery) cˇi prˇepı´nacˇi, • internet (intersı´t’), ve ktere´ jsou jednotlive´ segmenty cˇi sı´teˇ propojeny smeˇrovacˇi, • Internet (s velky´m „I“) je (jizˇ konkre´tnı´) nejveˇtsˇ´ı celosveˇtovy´ internet. • intranet je vnitrˇnı´ sı´t’, obvykle du˚veˇryhodna´, extranet je vneˇjsˇ´ı sı´t’, cˇasto se jedna´ o Internet. Referenc ˇnı´ model ISO/OSI
L7
Referenc ˇnı´ model TCP/IP
Protocol Data Units:
Protokoly:
POP3, IMAP
Aplikacˇnı´ vrstva
SMTP
Aplikacˇnı´ vrstva
data, zpra´vy
L6
Prezentacˇnı´ vrstva
L5
Relacˇnı´ vrstva
L4
Transportnı´ vrstva
Transportnı´ vrstva
segmenty
L3
Sı´t’ova´ vrstva
Internetova´ (sı´t’ova´) vrstva
pakety, datagramy
L2 L1
Linkova´ vrstva Fyzicka´ vrstva
FTP, SFTP
etc. DNS
DHCP
HTTP, HTTPS
ICMP, IGMP IPv4, IPv6 LLC (IEEE 802.2)
LLC MAC
TCP, UDP
ra´mce
Vrstva sı´t’ove´ho rozhranı´ bity
IEEE 802.3, IEEE 802.11, . . .
Obra´zek 1.2: Srovna´nı´ referencˇnı´ch modelu˚ ISO/OSI a TCP/IP, protokoly a adresy
1.3.1
Vrstvy
Model ISO/OSI je obecny´, komplexnı´ a teoreticky´. Zahrnuje (v obecnosti) vsˇechny oblasti, ktere´ v sı´t’ove´m rozhranı´ existujı´, a obsahuje hodneˇ restrikcı´. To je na jednu stranu vy´hodou, na druhou stranu to nenı´ prˇilisˇ prakticke´ z hlediska vy´robcu˚ zarˇ´ızenı´. Prˇedevsˇ´ım z du˚vodu zjednodusˇenı´ a prˇiblı´zˇenı´ praxi vznikl model TCP/IP. TCP/IP (Transmission Control Protocol/Internet Protocol) ma´ me´neˇ vrstev nezˇ ISO/OSI. Neˇktere´ sluzˇby byly za´meˇrneˇ vypusˇteˇny (nevydeˇluje se prezentacˇnı´ a relacˇnı´ vrstva), protozˇe jejich sluzˇby vyuzˇ´ıva´ jen ma´lo aplikacı´ a tedy tyto aplikace si mohou potrˇebne´ sluzˇby implementovat samy. Na obra´zku 1.2 na straneˇ 6 je porovna´nı´ rozvrzˇenı´ vrstev v modelech ISO/OSI a TCP/IP. V modelu TCP/IP jsou vsˇechny vrstvy nad transportnı´ vrstvou sdruzˇeny do jedine´ vrstvy nazy´vane´
1.3
MODEL TCP/IP
7
aplikacˇnı´ vrstva. Take´ nejspodneˇjsˇ´ı dveˇ vrstvy (fyzicka´ a linkova´) jsou sdruzˇeny do jedine´, vrstvy sı´t’ove´ho rozhranı´. Vrstva sı´t’ove´ho rozhranı´ je za´visla´ na konkre´tnı´ implementaci sı´t’ove´ho rozhranı´ – Ethernet, Token Ring, FDDI, X.25 apod. Pro tuto vrstvu nejsou prˇedepsa´ny zˇa´dne´ protokoly, pocˇ´ıta´ se s napojenı´m na neˇktere´ konkre´tnı´ rˇesˇenı´ (naprˇ´ıklad vy´sˇe zmı´neˇny´ Ethernet), ktere´ ma´ vlastnı´ protokoly. Tato vrstva musı´ by´t implementova´na ve vsˇech prvcı´ch sı´teˇ. Sı´t’ova´ vrstva (take´ vrstva internetu) pouzˇ´ıva´ sı´t’ove´ adresy, ma´ na starosti smeˇrova´nı´ a prˇeda´va´nı´ (prˇepojova´nı´) datagramu˚. Tato vrstva je implementova´na v koncovy´ch uzlech sı´teˇ (pocˇ´ıtacˇe, servery apod.) a da´le vsˇech mezilehly´ch prvcı´ch, ktere´ prova´deˇjı´ smeˇrova´nı´ podle sı´t’ovy´ch adres. Typicke´ protokoly jsou IP, ARP, RARP, ICMP, IGMP, IGRP, IPSEC, RIP, OSPF. Transportnı´ vrstva zajisˇt’uje rozhranı´ mezi aplikacˇnı´ vrstvou (neza´vislou na prˇenosove´ metodeˇ) a spodnı´mi vrstvami za´visly´mi na prˇenosove´ metodeˇ, zajisˇt’uje transportnı´ sluzˇby (spojove´ i nespojove´). Tato vrstva je implementova´na jen v koncovy´ch uzlech sı´teˇ. Typicke´ protokoly jsou TCP a UDP. Aplikacˇnı´ vrstva obsahuje entity, ktere´ vyuzˇ´ıvajı´ aplikace, tedy poskytuje sluzˇby smeˇrem k aplikacı´m. Tato vrstva je samozrˇejmeˇ take´ implementova´na jen v koncovy´ch uzlech sı´teˇ. Typicke´ protokoly jsou FTP, HTTP, DHCP, DNS, SMTP, IMAP, POP3, NFS, Telnet, apod. Tyto protokoly komunikujı´ prˇedevsˇ´ım s porty transportnı´ vrstvy prˇes tzv. porty, cozˇ je cˇ´ıselne´ oznacˇenı´ urcˇujı´cı´ konkre´tnı´ prˇ´ıstupovy´ bod smeˇrem k nizˇsˇ´ı vrstveˇ. Rozlisˇujeme porty zna´me´ (cˇ´ısla 0–1023), registrovane´ (1024–49 151, prˇideˇluje organizace IANA) a dynamicke´ cˇi soukrome´ (vysˇsˇ´ı cˇ´ısla). Seznam portu˚ lze najı´t na internetu, naprˇ´ı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 Take´ bychom meˇli veˇdeˇt, se ktery´mi porty konkre´tnı´ spusˇteˇna´ aplikace pracuje. Naprˇ´ıklad ve Windows to zjistı´me bud’ ve firewallu, a nebo v neˇktere´m spra´vci procesu˚ (na Spra´vce u´loh nenı´ moc dobre´ spole´hat, tam moc informacı´ nenı´, ale mu˚zˇeme vyzkousˇet naprˇ´ıklad aplikaci Process Explorer1 . ´ koly U Spust’te alesponˇ jeden z programu˚, ktere´ pracujı´ se sı´teˇmi (naprˇ´ıklad webovy´ prohlı´zˇecˇ nebo e-mailove´ho klienta, prˇ´ıp. obojı´). Zjisteˇte, ktere´ porty pouzˇ´ıvajı´ cˇi na nich naslouchajı´. Pokud pracujete ve Windows, mu˚zˇete pouzˇ´ıt naprˇ´ıklad Process Explorer (sta´hnete ze Sysinternals.com, zna´me z Operacˇnı´ch syste´mu˚). Ve Windows i Linuxu lze pouzˇ´ıt program netstat, na´vod najdete v prˇ´ıloze.
1
http://www.sysinternals.com.
P P P P
1.3
MODEL TCP/IP
1.3.2
8
Vrstva sı´t’ove´ho rozhranı´
Prˇ´ımo v referencˇnı´m modelu TCP/IP nejsou protokoly na te´to vrstveˇ stanoveny, nicme´neˇ ve vztahu k ISO/OSI lze rˇ´ıci, zˇe na L2 (spojove´) vrstveˇ, kterou deˇlı´me na dveˇ podvrstvy, se velmi cˇasto setka´me s protokolem IEEE 802.2, oznacˇovany´m jako LLC (stejneˇ jako dotycˇna´ podvrstva). Tı´mto protokolem se budeme zaby´vat za´rovenˇ s jiny´mi spojovy´mi protokoly v kapitole 4.1.6 o WAN sı´tı´ch, strana 72. Na podvrstveˇ MAC a na fyzicke´ vrstveˇ jizˇ najdeme implementaci konkre´tnı´ sı´teˇ. Pokud se jedna´ o loka´lnı´ sı´t’(typicky Ethernet), pracujeme na podvrstveˇ MAC s fyzicky´mi (MAC) adresami. MAC adresa (take´ fyzicka´ adresa) zabı´ra´ 48 bitu˚, tedy 6 oktetu˚ (resp. 12 hexadecima´lnı´ch cˇ´ıslic) rozdeˇleny´ch na dveˇ poloviny, jak je naznacˇeno v tabulce 1.1. Zapisuje se po jednotlivy´ch oktetech (veˇtsˇinou hexadecima´lneˇ) oddeˇleny´ch dvojtecˇkou nebo pomlcˇkou. 24 bitu˚
24 bitu˚
identifikace vy´robce nebo prodejce (prˇideˇluje IEEE)
identifikace konkre´tnı´ho vy´robku (trˇeba se´riove´ cˇ´ıslo), jedinecˇne´ pro zarˇ´ızenı´ vy´robce/prodejce
P
Tabulka 1.1: Struktura MAC adresy Kazˇde´ sı´t’ove´ zarˇ´ızenı´ (naprˇ´ıklad sı´t’ova´ karta) ma´ z vy´roby prˇideˇlenu jednu MAC adresu, ktera´ se nazy´va´ burned-in address (BIA), protozˇe je napevno v ROM pameˇti zarˇ´ızenı´ (burned – „vypa´lena“) a odtud se v prˇ´ıpadeˇ potrˇeby mapuje do operacˇnı´ pameˇti. BIA MAC adresa je vzˇdy jedinecˇna´, neexistujı´ dveˇ stejne´. MAC adresy jsou obvykle globa´lnı´ (globa´lneˇ jednoznacˇne´), ale mohou by´t take´ loka´lnı´. Prˇideˇlujı´ se v loka´lnı´ sı´ti prˇedevsˇ´ım tehdy, kdyzˇ prˇi zmeˇneˇ sı´t’ove´ho hardwaru je nutne´ zachovat adresu uzlu v sı´ti, ale vyuzˇ´ıvajı´ je take´ lide´, kterˇ´ı chteˇjı´ obejı´t seznamy pro filtrova´nı´ MAC adres (s teˇmito technikami se sezna´mı´me v kapitole 6.2.9). Loka´lnı´ MAC mohou mı´t plnou de´lku 48 bitu˚ nebo mohou by´t zkra´cene´ (16 bitu˚). Loka´lneˇ prˇideˇlene´ zkra´cene´ MAC adresy jsou tedy kratsˇ´ı a jsou spojeny s neˇktery´mi specificky´mi sı´t’ovy´mi protokoly a architekturami (naprˇ´ıklad DECnet nebo Banyan VINES). Existujı´ take´ loka´lnı´ MAC adresy na 48 bitech (plna´ de´lka), ktere´ byly softwaroveˇ pozmeˇneˇny a nenı´ u nich zajisˇteˇna jedinecˇnost (prˇesneˇji – o jejich jedinecˇnost by se meˇl starat spra´vce dane´ sı´teˇ). Aby bylo mozˇne´ je odlisˇit od globa´lnı´ch (BIA) adres, majı´ druhy´ nejnizˇsˇ´ı bit (L/G bit, viz obra´zek 1.3) prvnı´ho oktetu nastaven na 1 (u BIA adres je tento bit vzˇdy nastaven na 0). L/G
I/G
• L/G bit: loka´lnı´ (1) nebo globa´lnı´ (0) adresa • I/G bit: unicast (individua´lnı´, 0) nebo multicast cˇi broadcast (group, 1)
Obra´zek 1.3: Umı´steˇnı´ L/G (local/global) a I/G (individual/group) bitu v MAC adrese
P P
1.3
MODEL TCP/IP
9
MAC adresy deˇlı´me na individua´lnı´, skupinove´ (multicast) a vsˇeobecne´ (broadcast). Pro individua´lnı´ MAC platı´ vsˇe, co jsme dosud cˇetli (jedna´ se o konkre´tnı´ adresu prˇirˇazenou sı´t’ove´mu zarˇ´ızenı´), nejnizˇsˇ´ı bit prvnı´ho oktetu je vzˇdy nastaven na 0.
P
Skupinove´ a vsˇeobecne´ MAC adresy nejsou prˇirˇazeny jednomu konkre´tnı´mu zarˇ´ızenı´. Nejme´neˇ vy´znamny´ bit prvnı´ho oktetu je vzˇdy nastaven na 1 (tento bit by´va´ oznacˇova´n I/G bit – individual/group, viz obra´zek 1.3). Skupinova´ MAC adresa je urcˇena pro skupinove´ vysı´la´nı´ (vybrane´ pocˇ´ıtacˇe v loka´lnı´ sı´ti), vsˇeobecna´ adresuje vsˇechny aktivnı´ pocˇ´ıtacˇe v sı´ti. Vsˇeobecna´ MAC adresa ma´ vsˇechny bity nastaveny na 1, kdezˇto skupinova´ ne (podle identifikace skupiny, prˇedevsˇ´ım nejme´neˇ vy´znamny´ bit prvnı´ho oktetu musı´ by´t 1). Prˇı´klad Prˇ´ıklad individua´lnı´ adresy: Prˇ´ıklad individua´lnı´ loka´lnı´ adresy: Prˇ´ıklad skupinove´ adresy: Vsˇeobecna´ 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
Pozna´mka: Popis prˇ´ıkazu˚ pro pra´ci se sı´teˇmi a prˇedevsˇ´ım ru˚zny´mi typy adres najdeme v prˇ´ıloha´ch (od strany 230 pro Windows, od strany 249 pro Linux). ´ koly U
E
1. Najdeˇte v prˇ´ıloze uka´zky prˇ´ıkazu˚ pro ten operacˇnı´ syste´m, ve ktere´m pra´veˇ pracujete, a vyzkousˇejte alesponˇ „nedestruktivnı´ “ vypisujı´cı´ varianty prˇ´ıkazu˚, na ktere´ ma´te dostatecˇna´ prˇ´ıstupova´ opra´vneˇnı´. Prˇ´ımo v prˇ´ıloze take´ najdete u´koly. 2. Ve zmı´neˇny´ch prˇ´ıloha´ch jsou u Windows a Linuxu vypsa´ny take´ du˚lezˇite´ soubory (obvykle konfiguracˇnı´), ktere´ se sı´teˇmi souvisejı´. Tyto soubory najdeˇte a prohle´dneˇte si je. 3. Zjisteˇte svou MAC adresu. Vsˇimneˇte si nejleveˇjsˇ´ıho oktetu, nastavenı´ L/G a I/G bitu.
1.3.3
Protokoly sı´t’ove´ vrstvy
Rodina protokolu˚ TCP/IP nezahrnuje pouze ty dva protokoly, ktere´ ma´ v na´zvu. Postupneˇ probereme nejdu˚lezˇiteˇjsˇ´ı protokoly (rozhodneˇ ne vsˇechny). IP (Internet Protocol) zajisˇt’uje odesı´la´nı´ a prˇijı´ma´nı´ datagramu˚. Soucˇa´stı´ hlavicˇky datagramu je take´ IP adresa odesı´latele a prˇ´ıjemce a da´le cˇ´ıslo datagramu v posloupnosti z cele´ zpra´vy vysˇsˇ´ı vrstvy. Protokol IP probereme podrobneˇji v samostatne´ sekci. MIP (Mobile IP) je rozsˇ´ırˇenı´ protokolu IP urcˇene´ pro mobilnı´ uzly sı´teˇ, ktere´ meˇnı´ mı´sto sve´ho zapojenı´ v ra´mci Internetu prˇi zachova´nı´ sve´ doma´cı´ IP adresy. Pomocı´ MIP lze implementovat i tunelova´nı´ (tunneling), cozˇ je vzda´lene´ prˇipojova´nı´ do loka´lnı´ sı´teˇ prˇes Internet. ARP (Address Resolution Protocol) slouzˇ´ı k prˇekladu IP adresy na MAC adresu (tj. mapova´nı´ adres). Informace o mapova´nı´ adres si udrzˇuje v tzv. ARP tabulce, a pokud je pozˇadova´na adresa, kterou v tabulce nema´, odesˇle zˇa´dost o informaci na vsˇechny uzly sı´teˇ.
P P
1.3
MODEL TCP/IP
10
Opacˇny´ prˇeklad (MAC adresy na IP adresu) prova´dı´ protokol RARP (Reverse ARP), ale v soucˇasne´ dobeˇ jeho funkce plnı´ spı´sˇe protokol DHCP. Ve skutecˇnosti nenı´ prˇesneˇ stanoveno, na ktere´ vrstveˇ vlastneˇ ARP pracuje. Jeho funkce zasahujı´ i do obou okolnı´ch vrstev. ICMP (Internet Control Message Protocol) slouzˇ´ı k zası´la´nı´ rˇ´ıdicı´ch hla´sˇenı´ (vcˇetneˇ chybovy´ch hla´sˇenı´). 8
8
16
typ zpra´vy
parametr zpra´vy
kontrolnı´ soucˇet
Tabulka 1.2: Datagram protokolu ICMP Prˇı´klad Protokol ICMP je vyuzˇ´ıva´n take´ programem ping (Packet Internet Groper) pro zjisˇteˇnı´ dosazˇitelnosti cı´love´ stanice cˇi sı´teˇ. Ping vysı´la´ zpra´vu ICMP Echo Request s IP adresou cı´love´ stanice a ocˇeka´va´ odpoveˇd’ o dosazˇitelnosti (ICMP Echo Reply). Dalsˇ´ım zpu˚sobem vyuzˇitı´ protokolu ICMP je zjisˇt’ova´nı´ cesty prˇes smeˇrovacˇe k cı´li pomocı´ traceroute. Spocˇ´ıva´ v postupne´m generova´nı´ IP datagramu ˚ s hodnotou TTL (take´ na str. 231)
nastavenou postupneˇ na hodnoty 1, 2, 3, atd. TTL (Time To Live) je omezenı´ zˇivotnosti datagramu, ktere´ se na kazˇde´m smeˇrovacˇi (tj. prˇi kazˇde´m skoku) snizˇuje (nejme´neˇ o 1) a pokud smeˇrovacˇ obdrzˇ´ı zpra´vu s TTL=0, neposı´la´ ji da´l, ale odesˇle zpeˇt zpra´vu ICMP Time Exceeded (cˇas vyprsˇel) se svou adresou. Traceroute tedy vysı´la´ IP datagramy se zvysˇujı´cı´mi se hodnotami TTL a takto postupneˇ zı´ska´ adresy vsˇech smeˇrovacˇu˚ na sı´ti. Programy ping a traceroute (prˇ´ıpadneˇ ve Windows tracert) jsou dostupne´ v kazˇde´m sı´t’ove´m operacˇnı´m syste´mu.
Forma´t datagramu protokolu ICMP je naznacˇen v tabulce 1.2. Vy´znam jednotlivy´ch polı´: • typ zpra´vy (8 bitu˚) urcˇuje typ zası´lane´ zpra´vy; typy zpra´v jsou specifikova´ny v RFC 792 a RFC 1256, mu˚zˇe to by´t naprˇ´ıklad – 0 (Echo Reply) – odpoveˇd’ na zˇa´dost o odezvu, – 3 (Source Unreachable) – cı´l je nedostupny´, – 4 (Source Quench) – cache je zahlcena (zˇa´dost cı´love´ stanice o snı´zˇenı´ rychlosti prˇenosu, aby cı´lova´ stanice meˇla vı´c cˇasu na zpracova´nı´ dat), – 8 (Echo Request) – posla´na mechanismem ping, zˇa´dost o odezvu, – 11 (Time Exceeded) – zˇivotnost datagramu vyprsˇela (TTL=0, viz take´ str. 231 a 10), posı´la´ mezilehly´ uzel uzlu posı´lajı´cı´mu data, – 17 (Address Mask Request) – zˇa´dost o informaci o sı´t’ove´ masce, – 18 (Address Mask Reply) – odpoveˇd’ s informacı´ o sı´t’ove´ masce, atd.
P
1.3
MODEL TCP/IP
11
• parametr zpra´vy (8 bitu˚) slouzˇ´ı k uprˇesneˇnı´ typu zpra´vy, naprˇ´ıklad typ zpra´vy 3 je v ICMPv4 uprˇesnˇova´n na 0 (cı´lova´ sı´t’ nedostupna´), 1 (cı´lovy´ hostitel nedostupny´), 2 (cı´lovy´ protokol nedostupny´), 3 (cı´lovy´ port nedostupny´), atd. • kontrolnı´ soucˇet (16 bitu˚) prˇes prˇedchozı´ dveˇ pole datagramu. Seznam vsˇech typu˚ ICMP zpra´v najdeme naprˇ´ıklad na http://www.iana.org/assignments/icmp-parameters. Zpra´va ICMP Echo Request je podrobneˇ popsa´na na stra´nce http://www.networksorcery.com/enp/protocol/icmp/msg8.htm vcˇetneˇ implementacˇnı´ch detailu˚. Take´ zde najdeme informaci, zˇe Echo zpra´vy musejı´ by´t implementova´ny a zpracova´ny, rozhodneˇ by (ani z bezpecˇnostnı´ch du˚vodu˚) nemeˇly by´t ignorova´ny. K dalsˇ´ım typu˚m ICMP zpra´v se dostaneme mı´rnou u´pravou adresy. IGMP (Internet Group Management Protocol) je, jak na´zev napovı´da´, urcˇen ke spra´veˇ zası´la´nı´ datagramu˚ na skupinove´ adresy. V soucˇasne´ dobeˇ se pouzˇ´ıva´ jeho trˇetı´ verze, tj. IGMPv3. IGMP sve´ zpra´vy zapouzdrˇuje do IP datagramu˚ a pouzˇ´ıva´ vzˇdy TTL=1. Multicast mu˚zˇe by´t dvou typu˚ – bud’ one-to-many (jeden vysı´la´ a mnoho prˇijı´ma´, naprˇ´ıklad aktualizace softwaru, monitorova´nı´ sı´teˇ a uzlu˚, koncerty, zpravodajstvı´, apod.) nebo many-to-many (take´ vysı´lajı´cı´ch uzlu˚ je vı´ce, naprˇ´ıklad multimedia´lnı´ konference, pocˇ´ıtacˇove´ hry apod.). Skupinove´ IP adresy se mapujı´ na skupinove´ MAC adresy (konkre´tneˇ poslednı´ch 23 bitu˚ skupinove´ IP adresy). Proble´m je v tom, zˇe IP adresy majı´ vy´razneˇ me´neˇ bitu˚ nezˇ MAC adresy, proto se za urcˇity´ch okolnostı´ mu˚zˇe sta´t, zˇe mapova´nı´ nebude zcela jednoznacˇne´. Stanice, ktera´ chce by´t soucˇa´stı´ skupiny pro urcˇitou skupinovou adresu, nejdrˇ´ıv nasloucha´ vsˇem datagramu˚m na IP adrese 224.0.0.1, cozˇ je vyhrazena´ skupinova´ adresa oznacˇujı´cı´ vsˇechny stanice v podsı´ti. Pak informuje vsˇechny stanice loka´lnı´ho segmentu, zˇe se prˇihlasˇuje do konkre´tnı´ skupiny, a to zpra´vou IGMP Host Membership Report obsahujı´cı´ adresu te´to skupiny, a pak nasloucha´ vsˇem datagramu˚m pro danou skupinovou adresu. RIP (Routing Information Protokol) je starsˇ´ı jednoduchy´ smeˇrovacı´ protokol. Vyznacˇuje se pomeˇrneˇ snadnou konfiguracı´, ale jeho metriky (odhady de´lky cesty mezi uzly) jsou povazˇova´ny za spı´sˇe me´neˇ prˇesne´. Je to idea´lnı´ smeˇrovacı´ protokol pro mensˇ´ı loka´lnı´ sı´teˇ. OSPF (Open Shortest Path First) je take´ smeˇrovacı´ protokol, ale noveˇjsˇ´ı a slozˇiteˇjsˇ´ı. Je to adaptivnı´ hierarchicky´ distribuovany´ protokol s pomeˇrneˇ prˇesnou metrikou. Pouzˇ´ıva´ se ve veˇtsˇ´ıch loka´lnı´ch sı´tı´ch. O smeˇrovacı´ch protokolech se budeme ucˇit pozdeˇji. ´ koly U Najdeˇte alesponˇ dveˇ ru˚zne´ situace, ve ktery´ch se pouzˇ´ıvajı´ ICMP pakety. Promyslete si, co by se stalo, kdyby neˇktery´ uzel na cesteˇ zahazoval vsˇechny ICMP pakety (nebo alesponˇ ten typ zpra´v, o ktery´ by se pra´veˇ jednalo).
P
$
P P
1.3
MODEL TCP/IP
1.3.4
12
Protokoly transportnı´ vrstvy
Komunikujı´cı´ aplikace z vysˇsˇ´ı vrstvy jsou na te´to vrstveˇ rozlisˇeny podle portu˚ (tj. cˇ´ıslo portu urcˇuje prˇ´ıslusˇny´ SAP mezi transportnı´ a aplikacˇnı´ vrstvou). TCP (Transmission Control Protocol) vytva´rˇ´ı virtua´lnı´ okruh mezi komunikujı´cı´mi uzly, tedy zajisˇt’uje spolehlivou (s potvrzenı´m) sluzˇbu se spojenı´m. V TCP se setka´va´me se trˇemi fa´zemi komunikace – nava´za´nı´m spojenı´, prˇenosem dat (segmenty s porˇadovy´mi cˇ´ısly, kazˇdy´ musı´ by´t pozitivneˇ potvrzen – ne nutneˇ okamzˇiteˇ – druhou stranou a prˇ´ıpadneˇ znovu posla´n, pokud dosˇlo k chybeˇ prˇi prˇenosu) a ukoncˇenı´m spojenı´ (oboustranny´m). Potvrzova´nı´ prˇijetı´ datovy´ch segmentu˚ nemusı´ probı´hat po kazˇde´m obdrzˇenı´. Soucˇa´stı´ za´hlavı´ segmentu je u´daj velikost okna, cozˇ je pocˇet oktetu˚ dat, ktera´ lze prˇene´st v ra´mci spojenı´ bez pru˚beˇzˇne´ho potvrzova´nı´, obvykle to by´va´ vı´ce nezˇ velikost jednoho segmentu. Tento zpu˚sob rˇ´ızenı´ potvrzova´nı´ se nazy´va´ Sliding Window (klouzave´ okno), protozˇe okno zahrnujı´cı´ posloupnost oktetu˚ bez pru˚beˇzˇne´ho potvrzova´nı´ se beˇhem spojenı´ postupneˇ posouva´. 4
6
6
16
port zdroje
port cı´le
porˇadove´ cˇ´ıslo prvnı´ho oktetu dat v segmentu porˇadove´ cˇ´ıslo oktetu pro na´sledujı´cı´ segment de´lka za´hlavı´
rezervova´no =0
funkce rˇ´ızenı´
kontrolnı´ soucˇet
sˇ´ırˇka okna specifikace urgentnı´ch dat
volitelne´ data Tabulka 1.3: Segment protokolu TCP Forma´t segmentu protokolu TCP je naznacˇen v tabulce 1.3. Vy´znam jednotlivy´ch polı´: • port zdroje a port cı´le (oba po 16 bitech) specifikujı´ porty, prˇes ktere´ prˇicha´zejı´ data z aplikacˇnı´ vrstvy na zdrojove´m pocˇ´ıtacˇi, resp. jsou odesı´la´na data na aplikacˇnı´ vrstvu na cı´love´m pocˇ´ıtacˇi, naprˇ´ıklad 21 (FTP rˇ´ızenı´), 20 (FTP prˇenos dat), 25 (SMTP), atd. uvedena´ cˇ´ısla portu˚ se pouzˇ´ıvajı´ prˇedevsˇ´ım pro port cı´le; port zdroje obvykle by´va´ vysˇsˇ´ı nezˇ 1024, cˇasto se pouzˇ´ıva´ pro mechanismus PAT (prˇeklad portu˚), viz da´le ve skriptech. • porˇadove´ cˇ´ıslo prvnı´ho oktetu dat v segmentu (32 bitu˚) urcˇuje, kde v pu˚vodnı´m posı´lane´m proudu dat prˇijate´m z aplikacˇnı´ vrstvy zacˇ´ınajı´ data, ktera´ jsou soucˇa´stı´ tohoto segmentu, • porˇadove´ cˇ´ıslo oktetu pro na´sledujı´cı´ segment (32 bitu˚) podobneˇ pro na´sledujı´cı´ segment, tento u´daj slouzˇ´ı pro cı´lovy´ uzel jako kontrola, zda jsou segmenty spra´vneˇ dorucˇova´ny (aby bylo mozˇne´ odeslat potvrzenı´), • de´lka za´hlavı´ (4 bity), je to cˇ´ıslo urcˇujı´cı´ pocˇet na´sobku˚ 32 bitu˚, ktere´ zabı´ra´ za´hlavı´, naprˇ´ıklad pokud za´hlavı´ zabı´ra´ 576 bitu˚ (= 18 × 32), je zde cˇ´ıslo 18,
P P
1.3
MODEL TCP/IP
13
• funkce rˇ´ızenı´ (6 bitu˚) – kazˇdy´ bit ma´ svu˚j vy´znam: – URG – prˇ´ıznak urgentnı´ch dat (majı´ prˇi dorucˇenı´ prˇednost), – SYN – synchronizacˇnı´ bit, pouzˇ´ıva´ se prˇi navazova´nı´ spojenı´, – ACK – ma´ by´t bra´no v u´vahu pole „porˇadove´ cˇ´ıslo oktetu pro na´sledujı´cı´ segment“, prˇedstavuje potvrzenı´ (acknowledge),kromeˇ prvnı´ho paketu posı´lane´ho prˇi navazova´nı´ spojenı´ by´va´ obvykle nastaven na 1, – RST – zˇa´dost o opeˇtovne´ nava´za´nı´ spojenı´, – PSH – zˇa´dost o okamzˇite´ dorucˇenı´ segmentu protokolu vysˇsˇ´ı vrstvy, – FIN – zˇa´dost o ukoncˇenı´ spojenı´, • sˇ´ırˇka okna (16 bitu˚) je velikost okna (mnozˇstvı´ oktetu˚, ktere´ lze poslat bez pru˚beˇzˇne´ho potvrzova´nı´), • kontrolnı´ soucˇet (16 bitu˚) prˇes cely´ segment vcˇetneˇ tzv. pseudoza´hlavı´ (obsahuje zdrojovou a cı´lovou IP adresu, cˇ´ıslo protokolu a de´lku segmentu, celkem 3×32 = 96 bitu˚), pseudoza´hlavı´ se v transportnı´ vrstveˇ pouzˇ´ıva´ jen k tomuto u´cˇelu (vytvorˇenı´ kontrolnı´ho soucˇtu), nenı´ soucˇa´stı´ segmentu a ani se nevyuzˇ´ıvajı´ informace v neˇm uvedene´, • specifikace urgentnı´ch dat (16 bitu˚) pokud jsou posı´la´na urgentnı´ data, je zde cˇ´ıslo poslednı´ho oktetu urgentnı´ch dat (pouzˇ´ıva´ se k urychlenı´ zpracova´nı´ segmentu), • volitelne´ mozˇnosti (v na´sobku 32 bitu˚) jsou doplnˇkove´ informace urcˇene´ cı´love´ stanici. Jak je to s cˇ´ısly Sequence Number a Acknowledge Number: Wireshark a podobne´ na´stroje obvykle zobrazujı´ jen relativnı´ cˇ´ısla (skutecˇna´ jsou hodneˇ velka´). Nicme´neˇ je mozˇne´ naprˇ´ıklad ve Wiresharku
Obra´zek 1.4: Wireshark – Flow Graph, zobrazena´ cˇ´ı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 zacˇ´ına´ handshake – nava´za´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ı´ u´daje od serveru, od te´to chvı´le existuje spojenı´
Obra´zek 1.5: Pru˚beˇh navazova´nı´ spojenı´ (handshake) podle protokolu TCP zapnout zobrazova´nı´ skutecˇny´ch cˇ´ısel. V menu zvolı´me Edit – Preferences, tam nesmı´ by´t zasˇkrtnute´ „Relative sequence numbers and window scaling“. Provoz s teˇmito cˇ´ısly zobrazı´me takto: Statistics – Flow Graph, zasˇkrtnout TCP Flow. Uzel 1 (klient)
Uzel 2 (server)
ack=1000, window=3000
Posı´la´no po 1000 B, velikost okna 3000
seq=1000 (prvnı´ch 1000 B dat)
Posla´no prvnı´ch 1000 B dat, jesˇteˇ se nepotvrzuje
seq=2000 (druhy´ch 1000 B dat)
Posla´no druhy´ch 1000 B dat, jesˇteˇ se nepotvrzuje
seq=3000 (trˇetı´ch 1000 B dat)
Posla´no trˇetı´ch 1000 B dat, cˇeka´m na potvrzenı´
ack=4000, window=4000
Potvrzeno celkem 3000 B dat, zˇa´dost o dalsˇ´ı, veˇtsˇ´ı okno
seq=4000 (dalsˇ´ı data)
Dalsˇ´ı va´rka dat, atd.
Obra´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)
Posla´no prvnı´ch 1000 B dat, jesˇteˇ se nepotvrzuje
seq=2000 (druhy´ch 1000 B dat)
Posla´no druhy´ch 1000 B dat, nedosˇlo
seq=3000 (trˇetı´ch 1000 B dat)
Posla´no trˇetı´ch 1000 B dat, cˇeka´m
ack=2000
Nedosˇla data pro seq=2000, prosı´m znovu
seq=2000 (druhy´ch 1000 B dat)
Znovu posla´no druhy´ch 1000 B dat
ack=4000, window=3000
Ted’ uzˇ je to vsˇechno, prosı´m dalsˇ´ı
Obra´zek 1.7: Komunikace podle protokolu TCP, chyba prˇi prˇenosu Uzel 1
Uzel 2
ACK, FIN seq=1000
Jeden z uzlu˚ iniciuje ukoncˇenı´ spojenı´
ACK ack=1001
Druhy´ uzel souhlası´ ...
ACK, FIN ack=1001, seq=1470
ACK ack=1471
... a posı´la´ vlastnı´ ukoncˇujı´cı´ segment
Prvnı´ uzel potvrdı´ prˇijetı´, konec
Obra´zek 1.8: Ukoncˇenı´ spojenı´ v protokolu TCP
1.3
MODEL TCP/IP
16
Prˇi navazova´nı´ TCP spojenı´ se prova´dı´ tzv. three-way handshake: 1. prvnı´ strana odesˇle TCP segment s nastaveny´m bitem SYN, 2. druha´ strana odpovı´ TCP segmentem s nastaveny´mi bity SYN/ACK, firewall pozna´ odpoveˇd’ a detekuje navazovane´ spojenı´, 3. prvnı´ strana kontruje TCP segmentem s nastaveny´m ACK, pak je spojenı´ nava´za´no. TCP nepodporuje vysı´la´nı´ na vsˇeobecnou a skupinovou adresu, protozˇe s teˇmito adresami nelze nava´zat obousmeˇrne´ spojenı´. Podrobnosti: http://www.faqs.org/docs/iptables/tcpconnections.html UDP (User Datagram Protocol) poskytuje nespolehlivou sluzˇbu bez nava´za´nı´ spojenı´. Pouzˇ´ıva´ se prˇedevsˇ´ım pro posı´la´nı´ mensˇ´ıho mnozˇstvı´ dat nebo pro prˇ´ıpady, kdy je du˚lezˇita´ rychlost dorucˇenı´ dat (prˇenos nenı´ zdrzˇova´n fa´zı´ nava´za´nı´ spojenı´). Jeho vy´hodou je, zˇe cˇasto funguje i v prˇ´ıpadeˇ, zˇe TCP prˇestane by´t pouzˇitelny´ (pokud nelze s cı´lovy´m uzlem nava´zat standardnı´ spojenı´).
P
P
UDP podporuje skupinove´ a vsˇeobecne´ IP adresy. 16
16
port zdroje
port cı´le
de´lka segmentu
kontrolnı´ soucˇet data
Tabulka 1.4: Segment protokolu UDP Forma´t segmentu protokolu UDP je v tabulce 1.4. Vy´znam jednotlivy´ch polı´: • port zdroje a port cı´le (oba po 16 bitech) majı´ stejny´ vy´znam jako u TCP, • de´lka segmentu (16 bitu˚), je to cˇ´ıslo urcˇujı´cı´ pocˇet na´sobku˚ 32 bitu˚, ktere´ zabı´ra´ cely´ segment, • kontrolnı´ soucˇet (16 bitu˚) prˇes cely´ segment vcˇetneˇ pseudoza´hlavı´ (jako u segmentu TCP). PPP (Point-to-Point Protocol) pracuje neˇkde na rozhranı´ sı´t’ove´ vrstvy a (v ISO/OSI) linkove´ vrstvy, obsahuje dokonce i neˇktere´ sluzˇby aplikacˇnı´ vrstvy. Poskytuje sluzˇby autentizovane´ho spojenı´, sˇifrova´nı´ a komprese na point-to-point spojenı´ch. Pouzˇ´ıva´ se v na´vaznosti na telekomunikacˇnı´ sı´teˇ. ´ koly U V prˇ´ıloze v sekci C.6.2 od strany 276 jsou uka´za´ny postupy pro filtrova´nı´ provozu v Linuxu, kromeˇ jine´ho podle TCP portu˚. Srovntejte uvedene´ prˇ´ıkazy se sche´matem TCP paketu v tabulce 1.3 na straneˇ 12 – ktera´ pole za´hlavı´ TCP paketu jsou v dany´ch prˇ´ıkazech vyuzˇ´ıva´na? Cˇ´ısla portu˚ mu˚zˇete videˇt take´ v na´sledujı´cı´ podsekci o protokolech aplikacˇnı´ vrstvy (naprˇ´ıklad port 80 vyuzˇ´ıvany´ protokolem HTTP).
P
1.3
MODEL TCP/IP
1.3.5
17
Protokoly aplikacˇnı´ vrstvy
Podı´va´me se na nejdu˚lezˇiteˇjsˇ´ı protokoly pracujı´cı´ na aplikacˇnı´ vrstveˇ (aplikacˇnı´ podle TCP/IP). FTP (File Transfer Protocol) je vsˇeobecneˇ zna´my´ protokol pro spolehlivy´ prˇenos souboru˚ mezi uzly v sı´ti bez ohledu na operacˇnı´ syste´m, ktery´ na dane´m uzlu beˇzˇ´ı. Autentizacˇnı´ informace posı´la´ nezasˇifrovane´, proto nenı´ povazˇova´n za prˇ´ılisˇ bezpecˇny´. Vyuzˇ´ıva´ sluzˇeb protokolu TCP na portu 21 (pro rˇ´ıdicı´ spojenı´) a 20 (datove´ spojenı´). Ma´ take´ zabezpecˇene´ varianty, naprˇ´ıklad SFTP. HTTP (Hypertext Transfer Protocol) je objektoveˇ orientovany´ protokol pouzˇ´ıvany´ pro distribuovany´ prˇenos dat obsahujı´cı´ch hypertextove´ informace. Je zna´m prˇedevsˇ´ım jako protokol pro komunikaci webove´ho klienta (internetove´ho prohlı´zˇecˇe) s webovy´m serverem, ale ve skutecˇnosti je jeho pouzˇitı´ sˇirsˇ´ı. Mu˚zˇe take´ slouzˇit ke komunikaci s jiny´mi aplikacˇnı´mi protokoly (SMTP, FTP, apod.). Komunikuje s protokolem TCP na portu 80. NFS (Network File System) je sı´t’ovy´ souborovy´ syste´m (od firmy Sun) umozˇnˇujı´cı´ vzda´leny´ prˇ´ıstup k souboru˚m. Jeho pouzˇ´ıva´nı´ nad ra´mec loka´lnı´ sı´teˇ je diskutabilnı´, prˇedevsˇ´ım vzhledem k neprˇ´ılisˇ dobre´mu zabezpecˇenı´. Telnet (Telecomunication Network) je jizˇ velmi stary´ protokol slouzˇ´ıcı´ ke vzda´lene´mu prˇ´ıstupu k uzlu˚m sı´teˇ pomocı´ protokolu TCP (tj. virtua´lnı´ termina´l), vyuzˇ´ıva´ port 23. Jeho pouzˇ´ıva´nı´ nenı´ povazˇova´no za bezpecˇne´, i proto, zˇe vsˇechny autentizacˇnı´ u´daje prˇena´sˇ´ı nezasˇifrovaneˇ v textove´ podobeˇ. Ma´ mnoho zabezpecˇeny´ch alternativ, naprˇ´ıklad SSH. DNS (Domain Name System) je protokol pro mapova´nı´ dome´novy´ch jmen a IP adres. Pouzˇ´ıva´ port cˇ´ıslo 53. DNS je du˚lezˇity´m protokolem pro implementaci jmenny´ch sluzˇeb, podrobneˇji se o tomto mechanismu budeme ucˇit pozdeˇji. DHCP (Dynamic Host Configuration Protocol) slouzˇ´ı k zı´ska´nı´ IP adresy pro klienta. Pozdeˇji se podı´va´me, jaky´ je rozdı´l v mechanismu DHCP prˇi pouzˇitı´ IPv4 nebo IPv6. SMTP (Simple Mail Transfer Protocol) slouzˇ´ı k prˇenosu elektronicke´ posˇty. Zpra´vu dorucˇuje do posˇtovnı´ schra´nky adresa´ta, ze ktere´ ji adresa´t mu˚zˇe kdykoliv vyzvednout pomocı´ protokolu˚ POP3 nebo IMAP. Pouzˇ´ıva´ port 25. SMTP server by na´s meˇl zajı´mat prˇi odesı´la´nı´ zpra´vy z mailove´ho klienta. Pokud ma´me chybneˇ nakonfigurovane´ spojenı´ k SMTP serveru, neodesˇleme z klienta zpra´vu nebo sice odesˇleme, ale se spoustou chybovy´ch hla´sˇenı´. Tedy bychom si meˇli prˇedem zjistit, jaka´ je adresa SMTP serveru, a vesˇkere´ potrˇebne´ parametry. POP (Post Office Protocol) slouzˇ´ı k zı´ska´va´nı´ (stahova´nı´) elektronicke´ posˇty z posˇtovnı´ schra´nky na serveru do mailove´ho klienta. V soucˇasne´ dobeˇ se pouzˇ´ıva´ verze 3 (POP3), a to na portu 110. IMAP (Internet Message Access Protocol) je alternativou k POP3, umozˇnˇuje pracovat s elektronicky´mi zpra´vami prˇ´ımo v posˇtovnı´ schra´nce (nenı´ nutne´ je stahovat na pracovnı´ stanici). NTP (Network Time Protocol) slouzˇ´ı k synchronizaci hodin v sı´ti. Synchronizovat lze jak s NTP serverem v ra´mci loka´lnı´ sı´teˇ, tak i se vzda´leny´m serverem. Ve Windows naprˇ´ıklad slouzˇ´ı k za´kladnı´ pra´ci s NTP prˇ´ıkaz NET TIME. Pouzˇ´ıva´ port 123. SNMP (Simple Network Management Protocol) slouzˇ´ı k prˇenosu informacı´ souvisejı´cı´ch s rˇ´ızenı´m a spra´vou sı´teˇ. Tomuto protokolu se budeme podrobneˇ veˇnovat pozdeˇji v kapitole o bezpecˇnosti a spra´veˇ sı´teˇ.
P
1.5
PROTOKOL IPV4
18
RPC (Remote Procedure Call) slouzˇ´ı ke vzda´lene´mu vola´nı´ procedur. Klient takto odesˇle serveru zˇa´dost obsahujı´cı´ urcˇenı´ procedury a vstupnı´ parametry (na portu 111), server pak odesˇle odpoveˇd’ s vy´stupem (na portu specifikovane´m v zˇa´dosti). RPC je vyuzˇ´ıva´n naprˇ´ıklad protokolem NFS.
1.4
Sady protokolu˚
Protokol mu˚zˇe vyuzˇ´ıvat sluzˇeb jine´ho protokolu a poskytovat sluzˇby jine´mu protokolu. Protocol suite (sada protokolu˚) je mnozˇina takovy´ch protokolu˚, ktere´ jsou soucˇa´stı´ dane´ho (jednoho) referencˇnı´ho modelu, tj. doka´zˇou navza´jem spolupracovat. Protocol stack (protokolovy´ za´sobnı´k) je mnozˇina protokolu˚ implementovana´ na konkre´tnı´m zarˇ´ızenı´ (podmnozˇina sady protokolu˚ neˇktere´ho referencˇnı´ho modelu), nemusı´ by´t zdaleka u´plna´. Nejzna´meˇjsˇ´ım protokolovy´m za´sobnı´kem je samotny´ TCP/IP, da´le se setka´va´me naprˇ´ıklad s protokolovy´m za´sobnı´kem H.323 implementovany´m na VoIP zarˇ´ızenı´ch, take´ zna´me protokolovy´ za´sobnı´k GSM implementovany´ na GSM zarˇ´ızenı´ch (mobilnı´ telefony a jaka´koliv zarˇ´ızenı´ s GSM cˇipem).
1.5
Protokol IPv4
1.5.1
IPv4 datagramy
IPv4 (protokol IP verze 4) pracuje s datagramy – posı´la´ je na zadanou IP adresu, kterou najde v za´hlavı´ datagramu. Poskytuje sluzˇbu bez spojenı´, a to nespolehlivou (bez potvrzova´nı´, bez detekce chyb), trˇebazˇe s nejlepsˇ´ı vu˚lı´ datagram dorucˇit (tato vlastnost se nazy´va´ Best Effort). 4
4
8
16
verze
de´lka za´hlavı´
typ sluzˇby
celkova´ de´lka
identifikace datagramu TTL
prˇ´ıznaky
cˇ´ıslo protokolu
idenfikace fragmentu (13 bitu˚) zabezpecˇenı´ za´hlavı´
zdrojova´ IP adresa cı´lova´ IP adresa volitelne´ data (max. 65 535 mı´nus de´lka za´hlavı´ oktetu˚) Tabulka 1.5: Datagram protokolu IPv4 Forma´t IPv4 datagramu je naznacˇen v tabulce 1.5. Vy´znam jednotlivy´ch polı´ je na´sledujı´cı´: • verze (4 bity) – verze protokolu (tedy 4), • de´lka za´hlavı´ (4 bity) – u´daj je pocˇtem 32bitovy´ch slov, obvykle je zde cˇ´ıslo 5,
P
1.5
PROTOKOL IPV4
19
• typ sluzˇby (8 bitu˚ ozn. PPPDTRC0) – uprˇesnˇuje zpu˚sob zpracova´nı´ datagramu protokolem vysˇsˇ´ı vrstvy (nejnizˇsˇ´ı bit nenı´ pouzˇ´ıva´n), jednotlive´ bity a skupiny bitu˚ znamenajı´ – – – – –
PPP je urcˇenı´ priority datagramu (precedence), D zpozˇdeˇnı´ zpracova´nı´ (delay), T urcˇuje propustnost (throughput), R znamena´ spolehlivost (reliability), C je cena (cost),
takto se prova´dı´ optimalizace rˇ´ızenı´ dorucˇova´nı´ (naprˇ´ıklad mu˚zˇeme stanovit prioritu nı´zke´ho zpozˇdeˇnı´ a vysoke´ spolehlivosti), nedoporucˇuje se pokusit se optimalizovat vı´ce nezˇ dva parametry, • celkova´ de´lka (16 bitu˚) – de´lka datagramu (vcˇetneˇ za´hlavı´) v oktetech, z toho vyply´va´ maxima´lnı´ de´lka beˇzˇne´ho IPv4 datagramu, tj. 216 = 65 536 oktetu˚, • identifikace datagramu (16 bitu˚) – proud dat z vysˇsˇ´ı vrstvy by´va´ rozdeˇlen (fragmentova´n) do vı´ce datagramu˚, zde je spojujı´cı´ identifikacˇnı´ rˇeteˇzec, vsˇechny fragmenty posı´lany´ch dat by ovsˇem meˇly te´meˇrˇ stejne´ za´hlavı´ lisˇ´ıcı´ se jen v polozˇka´ch souvisejı´cı´ch s fragmentova´nı´m, • prˇ´ıznaky (3 bity, vyuzˇity jsou jen dva) urcˇujı´cı´ mozˇnosti dalsˇ´ı fragmentace datagramu na mezilehly´ch uzlech sı´teˇ, prvnı´ bit (DF – don’t fragment) urcˇuje, zda lze datagram po cesteˇ fragmentovat (hodnota 1 znamena´ nefragmentovat), druhy´ bit (MF – more fragments) je v prˇ´ıpadeˇ dalsˇ´ı fragmentace nastaven na 0 v poslednı´m fragmentu pu˚vodnı´ho datagramu (v ostatnı´ch fragmentech na 1), u nefragmentovane´ho datagramu je nastaven na 0, • identifikace fragmentu (fragment offset, 13 bitu˚) – pokud je tento datagram po cesteˇ da´le fragmentova´n, je zde vzda´lenost zacˇa´tku tohoto fragmentu od zacˇa´tku cele´ho datagramu v na´sobcı´ch 64 bitu˚, prvnı´ fragment by zde meˇl hodnotu 0, • TTL (8 bitu˚, Time to Live) urcˇuje „zˇivotnost“ datagramu, na kazˇde´m mezilehle´m uzlu (smeˇrovacˇi) se snizˇuje (viz str. 231 a 10), slouzˇ´ı k zamezenı´ „bloudeˇnı´ “ nedorucˇitelny´ch datagramu˚ v sı´ti, • cˇ´ıslo protokolu (8 bitu˚) – zde jde o cˇ´ıslo protokolu vysˇsˇ´ı podvrstvy sı´teˇ, a to obvykle 1 (ICMP), 2 (IGMP), 4 (IP-in-IP), 6 (TCP), 17 (UDP), 89 (OSPF), 133 (Fibre Channel) atd., urcˇuje, jaky´ typ dat je uvnitrˇ datagramu, • zabezpecˇenı´ za´hlavı´ (16 bitu˚) – kontrolnı´ soucˇet za´hlavı´, prˇes prˇedchozı´ 2oktetove´ sekvence, • zdrojova´ a cı´lova´ IP adresa (po 32 bitech), zdrojova´ musı´ by´t vzˇdy individua´lnı´, cı´lova´ mu˚zˇe by´t i skupinova´ nebo vsˇeobecna´, • volitelne´ – toto pole se veˇtsˇinou nepouzˇ´ıva´, je urcˇeno pro dodatecˇne´ informace, • data – informace bud’ neˇktere´ho transportnı´ho protokolu a nebo sı´t’ove´ho (ICMP, IGMP nebo neˇktere´ho smeˇrovacı´ho protokolu), typ dat podle pole s cˇ´ıslem protokolu. IP datagram mu˚zˇe by´t da´le fragmentova´n ve smeˇrovacˇ´ıch (tyto mezilehle´ prvky take´ implementujı´ sı´t’ovou vrstvu), naprˇ´ıklad z du˚vodu usnadneˇnı´ prˇenosu (nizˇsˇ´ı vrstvy na jiny´ch zarˇ´ızenı´ch mohou optima´lneˇji pracovat s mensˇ´ımi PDU). Pokud se tak stane, vy´sledne´ fragmenty (cozˇ jsou take´ datagramy) obsahujı´ pu˚vodnı´ za´hlavı´, ve ktere´m jsou pozmeˇneˇna pole prˇ´ıznaku˚ a identifikace fragmentu podle potrˇeby se spolecˇnou hodnotou identifikace datagramu, a samozrˇejmeˇ fragment
$
1.5
PROTOKOL IPV4
20
Data 6980 oktetu˚ oktety 0–6979
MF=0 F.offset=0 ↓ MTU=3100 ↓ Fragmentace
de´lka datagramu: MTU − de´lka za´hlavı´ = 3100 − 20 = 3080 „fragment offset“ pro prvnı´ fragment: 3080/8 = 385 (musı´ by´t cele´ cˇ.)
MF=1 F.offset=385
Data1 3080 oktetu˚ oktety 0–3079
MF=1 F.offset=385
Data2 3080 oktetu˚ oktety 3080–6159
MF=0 F.offset=770
Data3 820 oktetu˚ oktety 6160–6979
Obra´zek 1.9: Fragmentace u IPv4 datove´ cˇa´sti pu˚vodnı´ho datagramu (postup je naznacˇen na obra´zku 1.9). Prˇi sestavova´nı´ fragmentu˚ do pu˚vodnı´ho datagramu na cı´love´m uzlu sı´teˇ lze shroma´zˇdit fragmenty pu˚vodnı´ho datagramu (podle pole id. datagramu), zjistit porˇadı´ fragmentu˚ (podle id. fragmentu) a da´le urcˇit poslednı´ fragment (bit MF). Podle specifikace musı´ vsˇechny uzly sı´teˇ bez proble´mu zpracova´vat datagramy o minima´lnı´ de´lce 576 oktetu˚. Konkre´tnı´ hodnota je na dane´m sı´t’ove´m prvku stanovena hodnotou MTU (Maximum Transmission Unit). Jestlizˇe je datagram moc velky´, je fragmentova´n (pokud je to povoleno v jeho prˇ´ıznacı´ch), jinak musı´ by´t zlikvidova´n a zasla´na informace zdrojove´mu uzlu. Hodnota MTU tedy urcˇuje maxima´lnı´ velikost IP datagramu, ktery´ mu˚zˇe prˇes dane´ zarˇ´ızenı´ projı´t. Obvykla´ hodnota je 1500, cozˇ je standardnı´ prˇedevsˇ´ım pro pakety prˇena´sˇene´ po Ethernetu plus IP za´hlavı´. Pokud vı´me, zˇe po cesteˇ budou paketu prˇida´va´na dalsˇ´ı za´hlavı´ (naprˇ´ıklad prˇes tunel), meˇli bychom MTU pro odchozı´ provoz nastavit radeˇji na nizˇsˇ´ı hodnotu, aby pakety nebyly po cesteˇ zahazova´ny. Jestlizˇe do neˇktere´ho uzlu na cesteˇ prˇijde paket veˇtsˇ´ı nezˇ je MTU na odchozı´m provozu, je zahozen a vysı´lajı´cı´ uzel je informova´n ICMP zpra´vou cˇ. 3 (Destination Unreachable, cı´l nedostupny´) s ko´dem (parametrem zpra´vy) cˇ. 4 (Fragmentation Needed and Don’t Fragment was Set, nutno fragmentovat, prˇicˇemzˇ nastaven prˇ´ıznak Nefragmentovat). Ted’ si prˇedstavte, co se stane, kdyzˇ na neˇktere´m uzlu na cesteˇ administra´tor nastavı´ zahazova´nı´ paketu˚ s ICMP zpra´vami: ICMP zpra´va o nutnosti fragmentace nedojde ke zdroji paketu, tedy du˚sledkem je „cˇerna´ dı´ra“ – spojenı´ funguje, i kdyzˇ prˇi zaka´za´nı´ ICMP paketu˚ asi prˇ´ıkaz ping neplnı´ svou roli tak jak by meˇl, ale mnohe´ IP datagramy neprocha´zejı´, tedy naprˇ´ıklad webovy´ prohlı´zˇecˇ mı´sto stra´nek zobrazuje chybova´ hla´sˇenı´. Podle konvence jsou u´daje v IP datagramu zası´la´ny ve formeˇ big-endian, kdezˇto intelovske´ procesory vyuzˇ´ıvajı´ little-endian (vzpomenˇte si na Operacˇnı´ syste´my, tam jsme rozdı´l probı´rali). Proto prˇi zpracova´nı´ IP datagramu na intelovske´m procesoru je nutne´ prova´deˇt konverzi, cozˇ mu˚zˇe zpracova´nı´ mı´rneˇ zdrzˇet.
P
1.5
PROTOKOL IPV4
21
´ koly U 1. Zkompletujte, co vsˇe se deˇje v prˇ´ıpadeˇ, zˇe na´sˇ uzel poslal do sı´teˇ IPv4 datagram, ktery´ je veˇtsˇ´ı nezˇ hodnota MTU neˇkde na cesteˇ (prˇedpokla´dejme, zˇe ICMP zpra´vy nejsou nikde zahazova´ny). Popisˇte jednotlive´ kroky a u samotne´ fragmentace si ujasneˇte, co bude v jednotlivy´ch polı´ch za´hlavı´ datagramu. 2. V prˇ´ıloze v podsekci C.6.2 od strany 276 najdeˇte prˇ´ıkazy, ktere´ v Linuxu slouzˇ´ı k povolenı´ ICMP provozu ve firewallu.
1.5.2
Adresy IPv4
Adresa protokolu IPv4 zabı´ra´ 32 bitu˚ (4 oktety) a skla´da´ se ze dvou cˇa´stı´ – adresy sı´teˇ a adresy uzlu v sı´ti. 32 bitu˚ by teoreticky znamenalo 232 = 4 294 967 296 mozˇny´ch adres, ale ve skutecˇnosti je to mnohem me´neˇ – kromeˇ jine´ho z „organizacˇnı´ch“ du˚vodu˚.
P
Pu˚vodneˇ se rozlisˇovalo 5 trˇ´ıd adres podle pozice rozhranı´ mezi sı´t’ovou a uzlovou cˇa´stı´ adresy: Trˇ´ıda A pouzˇ´ıva´ prvnı´ oktet pro adresu sı´teˇ, zbytek je adresa uzlu v sı´ti, specia´lnı´ adresa 127.0.0.0 je vyhrazena pro loopback (zpeˇtna´ smycˇka, aby bylo mozˇne´ prˇes sı´t’ove´ protokoly prˇistupovat k te´muzˇ uzlu v sı´ti), adresa s prvnı´m oktetem nulovy´m nenı´ platna´, Trˇ´ıda B pouzˇ´ıva´ pro adresu sı´teˇ prvnı´ dva oktety, zbytek je adresa uzlu v sı´ti, Trˇ´ıda C pouzˇ´ıva´ pro adresu sı´teˇ prvnı´ trˇi oktety, zbytek je adresa uzlu v sı´ti, Trˇ´ıda D slouzˇ´ı pro skupinovou adresaci, neˇktere´ z teˇchto adres jsou vyhrazeny: • 224.0.0.1 – skupina vsˇech stanic prˇipojeny´ch k mı´stnı´ podsı´ti, • 224.0.0.2 – skupina vsˇech smeˇrovacˇu˚ prˇipojeny´ch k mı´stnı´ podsı´ti, • 224.0.0.5 – skupina vsˇech smeˇrovacˇu˚ smeˇrujı´cı´ch podle OSPF, • 224.0.0.6 – skupina vsˇech jmenovany´ch smeˇrovacˇu˚ smeˇrujı´cı´ch podle OSPF. Trˇ´ıda E slouzˇ´ı pro experimenta´lnı´ u´cˇely. Struktura adres teˇchto trˇ´ıd je naznacˇena v tabulce 1.6. Trˇ´ı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. pocˇet stanic v sı´ti 224 − 2 216 − 2 254 – –
Tabulka 1.6: Trˇ´ıdy IPv4 adres Ze trˇ´ıd A–C jsou neˇktere´ adresy vyhrazene´: • samostatna´ adresa sı´teˇ ma´ vsˇechny bity urcˇene´ pro adresu uzlu v sı´ti nastaveny na 0, tedy naprˇ´ıklad pro trˇ´ıdu B to mu˚zˇe by´t 137.24.0.0, adresa neˇktere´ stanice v te´to sı´ti ma´ pak alesponˇ jeden z poslednı´ch dvou oktetu˚ nenulovy´, naprˇ´ıklad 137.24.8.152,
P
1.5
PROTOKOL IPV4
22
• broadcast (vsˇeobecna´ adresa) ma´ naopak vsˇechny bity urcˇene´ pro adresu uzlu v dane´ sı´ti nastaveny na 1, naprˇ´ıklad pro trˇ´ıdu B to mu˚zˇe by´t 137.24.255.255, • broadcast bez urcˇenı´ sı´teˇ (tj. v te´ sı´ti, kde byla zpra´va vysla´na) je 255.255.255.255, tj. vsˇechny bity jsou nastaveny na 1, • loopback (zpeˇtna´ smycˇka) vzˇdy zacˇ´ına´ oktetem 127, nejpouzˇ´ıvaneˇjsˇ´ı je 127.0.0.1 (ale poslednı´ trˇi oktety mohou by´t teoreticky jake´koliv), jde o virtua´lnı´ zarˇ´ızenı´, • adresy soukromy´ch sı´tı´ (bez interakce s vneˇjsˇ´ı sı´tı´) jsou – 10.x.x.x pro trˇ´ıdu A, – 172.16.x.x azˇ 172.31.x.x pro trˇ´ıdu B, – 192.168.0.x azˇ 192.168.255.x pro trˇ´ıdu C (mı´sto „x“ je samozrˇejmeˇ 0, protozˇe jde o adresy sı´teˇ, pı´smeno je zde napsa´no jen pro ilustraci hranice mezi adresou sı´teˇ a uzlu). Hlavnı´m u´cˇelem rozdeˇlenı´ adres do trˇ´ıd bylo zjednodusˇenı´ smeˇrova´nı´ (smeˇrovacˇe nepotrˇebujı´ tak rozsa´hle´ smeˇrovacı´ tabulky), smeˇrova´nı´ bylo mozˇne´ cˇa´stecˇneˇ rˇ´ıdit podle prvnı´ho oktetu adresy. Podobny´ u´cˇel meˇlo take´ zavedenı´ da´le popsany´ch metod. Loopback. Vrat’me se nynı´ k mechanismu loopback (zpeˇtne´ smycˇky). Jak vı´me, jedna´ se vlastneˇ o jaky´si vnitrˇnı´ diagnosticky´ mechanismus, ktery´ ma´ kazˇda´ stanice bez ohledu na jejı´ pozici v sı´ti. Adresa zacˇ´ına´ oktetem 127, ostatnı´ oktety mohou by´t obecneˇ ru˚zne´, ale obvykle je adresa 127.0.0.1. Prˇı´klad Vyzkousˇ´ıme mechanismus loopback. Konkre´tnı´ adresu zpeˇtne´ smycˇky pro svu˚j pocˇ´ıtacˇ zjistı´me v souboru hosts: • v unixovy´ch syste´mech /etc/hosts (neˇkdy to mu˚zˇe by´t /private/etc/hosts) • ve Windows ...\system32\drivers\etc\hosts V obou prˇ´ıpadech bez prˇ´ıpony. Meˇla by tam by´t (kromeˇ prˇ´ıpadny´ch dalsˇ´ıch adres) adresa IPv4 a pravdeˇpodobneˇ i IPv6 loopbacku, naprˇ´ıklad ve Windows: 127.0.0.1 ::1
localhost localhost
Na Prˇ´ıkazove´m rˇa´dku oveˇrˇ´ıme funkcˇnost loopbacku: ping 127.0.0.1
´ koly U Vyzkousˇejte postup z prˇedchozı´ho prˇ´ıkladu. Srovnejte vy´stupy prˇ´ıkazu ping naprˇ´ıklad s tı´mte´zˇ prˇ´ıkazem na adresu 77.75.76.3 (cozˇ je IP adresa web serveru seznam.cz). Vsˇimneˇte si odezvy a hodnoty TTL.
P
1.5
PROTOKOL IPV4
1.5.3
23
Prˇeklad adres
Adresy soukromy´ch (priva´tnı´ch) sı´tı´ se pu˚vodneˇ pouzˇ´ıvaly pro sı´teˇ, ktere´ nebyly prˇipojeny k Internetu, v soucˇasne´ dobeˇ (prˇi akutnı´m nedostatku adres) se vyuzˇ´ıvajı´ pro podnikove´ nebo ISP sı´teˇ, ktere´ tyto soukrome´ adresy skry´vajı´. Jedna´ se o mechanismus NAT (Network Address Translation) a mechanismus Masquerade (tzv. masˇkara´du). V obou prˇ´ıpadech jde o prˇeklad adres, ktery´ je zajisˇt’ova´n NAT serverem (cˇasto jde o implementaci NAT na smeˇrovacˇi). Vysveˇtlı´me si oba tyto pojmy se vsˇemi nuancemi. 1. DNAT (Destination NAT) je prˇeklad cı´love´ (destination) adresy (tj. hodnoty ulozˇene´ v poli „cı´lova´ adresa“ v IP datagramu) obvykle v prˇ´ıchozı´m provozu. Pouzˇ´ıva´ se naprˇ´ıklad v mechanismu proxy pro prˇesmeˇrova´nı´ na uzel sı´teˇ zajisˇt’ujı´cı´ funkcionalitu proxy, adresa, kterou do za´hlavı´ ukla´da´me, musı´ by´t staticka´ (musı´me ji zna´t). 2. SNAT (Source NAT) je prˇeklad zdrojove´ adresy obvykle v odchozı´m provozu. Pouzˇ´ıva´me prˇedevsˇ´ım tehdy, kdyzˇ prˇipojujeme sı´t’se soukromy´mi adresami prˇes router (NAT server) se statickou adresou (zna´me ji), pod touto adresou jsou zvneˇjsˇku viditelne´ vsˇechny stanice ve vnitrˇnı´ sı´ti. Na NAT serveru je vedena tabulka prˇekladu adres (tabulka spojenı´) obsahujı´cı´ dvojice adres [IP adresa z Internetu, soukroma´ IP adresa], tj. evidujı´ se vlastneˇ komunikace (nava´zana´ spojenı´) dane´ soukrome´ IP adresy. Pokud se v nava´zane´m spojenı´ pokracˇuje a zvencˇ´ı dojde na prˇelozˇenou adresu odpoveˇd’, provede se zpeˇtny´ prˇeklad podle u´daju˚ ulozˇeny´ch v tabulce prˇekladu adres, dohleda´ se, komu konkre´tneˇ je odpoveˇd’ urcˇ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 Vytvorˇ za´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 Prˇeklad podle [77.75.76.3 , 10.0.0.1]
Cı´l: 10.0.0.1 Zdroj: 77.75.76.3
Obra´zek 1.10: Prˇeklad adres na smeˇrovacˇi – SNAT (staticke´) nebo Masquerade (dynamicke´)
P
1.5
PROTOKOL IPV4
24
3. SNAT+DNAT (plny´ NAT, take´ bezstavovy´ NAT) prˇedstavuje kombinaci obou prˇedchozı´ch s tı´m, zˇe se prˇekla´da´ 1:1 (jedna staticka´ na druhou statickou) bez zapamatova´nı´ konkre´tnı´ho spojenı´ (proto bezstavovy´, bez zapamatova´nı´ stavu spojenı´), cozˇ nenı´ nutne´, protozˇe pro zpeˇtny´ prˇeklad se pouzˇije DNAT se staticky´mi adresami. Pouzˇ´ıva´me typicky pro skry´va´nı´ adresy serveru˚ z nasˇ´ı sı´teˇ. 4. Masquerade (masˇkara´da) je oproti prˇedchozı´m (prˇedevsˇ´ım oproti jinak podobne´mu SNAT) urcˇena pro plneˇ dynamicky adresovanou sı´t’(tj. sı´t’se soukromy´mi adresami, router je venku viditelny´ take´ pod dynamickou adresou zı´ska´vanou naprˇ´ıklad od DHCP serveru ISP – poskytovatele internetu). Zdrojova´ adresa v paketu z vnitrˇnı´ sı´teˇ je prˇed odesla´nı´m paketu ven prˇelozˇena na (dynamickou) adresu WAN rozhranı´ routeru, do tabulky spojenı´/prˇekladu adres je ulozˇena informace o spojenı´, v opacˇne´m smeˇru se prova´dı´ zpeˇtny´ prˇeklad. Z toho vyply´va´, zˇe SNAT a masˇkara´da jsou urcˇeny k te´muzˇ u´cˇelu, jen SNAT pouzˇ´ıva´me, pokud na´sˇ router ma´ prˇideˇlenu pevnou IP adresu pro WAN port (viditelnou zvencˇ´ı) – nemusı´ by´t verˇejna´, ale musı´ by´t staticka´ (pozor, nenı´ to tote´zˇ). Masˇkara´du zase pouzˇijeme, kdyzˇ adresu pro WAN port dosta´va´me dynamicky. Princip vidı´me na obra´zku 1.10. Konkre´tnı´ zpu˚sob nastavenı´ na routeru s Linuxem najdeme na straneˇ 261 (prˇ´ıkaz ip) a 282 (mechanismus prˇekladu adres ve firewallu NetFilter). Pokud neˇkomu nenı´ jasny´ mechanismus prˇekladu, mohou tam uvedene´ prˇ´ıklady (hlavneˇ na druhe´m odkazu) pomoci. Prˇeklad adres vsˇak pu˚sobı´ proble´my mnoha aplikacı´m, ktere´ pouzˇ´ıvajı´ IP adresu i pro jine´ u´cˇely nezˇ smeˇrova´nı´ (podobneˇ jako trˇeba proxy). Problematicka´ (trˇebazˇe rˇesˇitelna´) je take´ spolupra´ce NAT a protokolu IPSec (IP Security). Obdobou NAT pro porty je PAT (Port Address Translation), kdy se prˇeklad prova´dı´ mezi ru˚zny´mi porty. Toho se vyuzˇ´ıva´ tehdy, kdyzˇ potrˇebujeme prˇekla´dat vı´ce ru˚zny´ch soukromy´ch IP adres na jednu verˇejnou (jednoznacˇnost prˇekladu zajistı´me tak, zˇe soukrome´ adresy jsou sice mapova´ny na jedinou verˇejnou, ale komunikace je rozlisˇena podle portu˚ (kazˇda´ soukroma´ adresa ma´ jiny´ port smeˇrovacˇe). Na straneˇ 12 bylo toto te´ma „nakousnuto“. Jak to funguje ve skutecˇnosti? Prˇedstavme si, zˇe v nasˇ´ı sı´ti s dynamicky´mi adresami chteˇjı´ dva ru˚zne´ pocˇ´ıtacˇe komunikovat s tı´mte´zˇ serverem na internetu. Pokud bychom nepouzˇili PAT, dosˇlo by k te´to situaci: kazˇdy´ z pocˇ´ıtacˇu˚ by poslal paket dotycˇne´mu serveru, prˇicˇemzˇ by dosˇlo k prˇekladu (pravdeˇpodobneˇ pomocı´ Masquerade) zdrojovy´ch adres v paketech (tj. adres odesı´lajı´cı´ch pocˇ´ıtacˇu˚) na adresu routeru. Server na internetu by obdrzˇel oba pakety, ovsˇem oba by meˇly stejnou zdrojovou adresu. Pokud by odeslal odpoveˇd’, v paketu by nastavil cı´lovou adresu na tu, ktera´ byla uvedena v obou dosˇly´ch paketech – adresu routeru. Ted’ by meˇl spra´vneˇ router v tomto paketu prove´st zpeˇtny´ prˇeklad, tentokra´t cı´love´ adresy (tj. svou adresu by meˇl zameˇnit za adresu skutecˇne´ho cı´love´ho uzlu ze sı´teˇ), ale jak ma´ poznat, pro ktery´ z komunikujı´cı´ch pocˇ´ıtacˇu˚ je paket urcˇen? Podle sve´ tabulky by nemohl rozhodnout, protozˇe tam ma´ dveˇ nava´zane´ (rovnocenne´) relace s prˇ´ıslusˇny´m serverem na internetu. PAT tuto situaci rˇesˇ´ı. Kromeˇ mechanismu NAT identifikaci zprˇesnı´me jesˇteˇ tı´m, zˇe kazˇdy´ z nasˇich pocˇ´ıtacˇu˚ v za´hlavı´ UDP nebo TCP segmentu uvede jako zdrojovy´ port cˇ´ıslo veˇtsˇ´ı (nebo rovno) nezˇ 1024, kazˇdy´ pocˇ´ıtacˇ pouzˇije jine´. Zdrojovy´ port ve smeˇru od klienta nenı´ du˚lezˇity´, proto se da´ vyuzˇ´ıt pra´veˇ pro zprˇesneˇnı´ identifikace. V tabulce zarˇ´ızenı´ prova´deˇjı´cı´ho PAT je kromeˇ pa´ru adres
$
P
L
1.5
PROTOKOL IPV4
25
uvedeno i toto cˇ´ıslo. Server z internetu ve sve´m paketu s odpoveˇdı´ pak prˇehodı´ cˇ´ısla zdrojove´ho a cı´love´ho portu, a tedy prˇi zpeˇtne´m prˇekladu se stacˇ´ı podı´vat na cˇ´ıslo cı´love´ho portu v segmentu. Soukrome´ IP adresy se nesmeˇrujı´, smeˇrovacˇ zahazuje kazˇdou datovou jednotku, jejı´zˇ cı´lova´ adresa je soukroma´ (prˇesneˇji, PDU se soukromou adresou se nedostane do jine´ sı´teˇ). To samozrˇejmeˇ nevylucˇuje funkcˇnost NAT na smeˇrovacˇ´ıch, protozˇe zde je soukroma´ adresa obvykle pouzˇita jako zdrojova´, nikoliv cı´lova´ (jak ilustruje obra´zek 1.10). Na tomto obra´zku je adresa 10.0.0.1 soukromou adresou prˇideˇlenou mechanismem DHCP (beˇzˇ´ıcı´m na routeru) pracovnı´ stanici.
1.5.4
E
Adresy podsı´teˇ
Jak bylo vy´sˇe uvedeno, rozdeˇlenı´ IP adres do trˇ´ıd prˇestalo by´t dostacˇujı´cı´. Tento mechanismus byl rozsˇ´ırˇen (prˇesneˇji rozsˇ´ırˇen byl pocˇet mozˇnostı´, jak IP adresu rozdeˇlit na cˇa´sti) na mechanismus podsı´t’ova´nı´ (subnetting). IPv4 adresa se prˇi pouzˇitı´ podsı´t’ova´nı´ deˇlı´ na trˇi cˇa´sti:
P
• adresu sı´teˇ, • adresu podsı´teˇ, • adresu uzlu v (pod)sı´ti. Smeˇrova´nı´ je tedy hierarchicke´ se trˇemi u´rovneˇmi. Kazˇda´ stanice ma´ prˇideˇlenu nejen svou IP adresu, ale musı´ take´ zna´t masku podsı´teˇ, ktera´ urcˇuje hranici mezi adresou podsı´teˇ a adresou uzlu v sı´ti. Na pozicı´ch prvnı´ch dvou cˇa´stı´ adresy (sı´t’a podsı´t’) ma´ maska bity nastaveny na 1, na pozici poslednı´ cˇa´sti (uzel) ma´ bity nastaveny na 0. Tento mechanismus je zpeˇtneˇ kompatibilnı´, naprˇ´ıklad pro adresu trˇ´ıdy B bez rozdeˇlenı´ na podsı´teˇ by maska byla 255.255.0.0, tedy v prvnı´ch dvou oktetech ma´ vsˇechny bity nastaveny na 1. Prˇı´klad Podobneˇ s podsı´tı´ naprˇ´ıklad • IP adresa ve trˇ´ıdeˇ B je 154.56.201.107, bina´rneˇ 10011010.00111000.11001001.01101011 • maska podsı´teˇ je 255.255.255.224, bina´rneˇ 11111111.11111111.11111111.11100000 • adresu podsı´teˇ (vcˇetneˇ adresy sı´teˇ) zjistı´me operacı´ AND na bina´rnı´ch adresa´ch: bina´rneˇ 10011010.00111000.11001001.01100000, adresa podsı´teˇ 154.56.201.96 (z toho prvnı´ dva oktety urcˇujı´ adresu sı´teˇ). V ra´mci te´zˇe sı´teˇ mohou existovat i dalsˇ´ı podsı´teˇ, naprˇ´ıklad adresa 154.56.152.160 mu˚zˇe by´t adresou dalsˇ´ı podsı´teˇ.
Podsı´teˇ jsou vy´hodne´ z mnoha du˚vodu˚, z hlediska spra´vce sı´teˇ je zde prˇedevsˇ´ım mozˇnost rozdeˇlit stanice do skupin (segmentu˚), kde kazˇda´ skupina stanic ma´ svou vlastnı´ adresu podsı´teˇ (ale vsˇechny se stejnou maskou) a smeˇrovacˇe mohou zvla´sˇt’smeˇrovat jednotlive´ segmenty.
P
1.5
PROTOKOL IPV4
26
Prˇı´klad Uka´zˇeme si jeden ze zpu˚sobu˚ vytvorˇenı´ podsı´tı´ ze sı´teˇ trˇ´ıdy C. Postupy jsou popsa´ny naprˇ´ıklad v [2] nebo [3] ze seznamu doporucˇene´ literatury. Prˇedpokla´dejme tedy, zˇe ma´me adresu sı´teˇ trˇ´ıdy C 192.168.35.0/24. Cˇ´ıslo za lomı´tkem znacˇ´ı pocˇet bitu˚ v masce nastaveny´ch na 1, zde je zrˇejme´, zˇe maska bude 255.255.255.0 (tj. adresa trˇ´ıdy C). V te´to sı´ti chceme vytvorˇit 5 podsı´tı´. Nejdrˇ´ıv zjistı´me, kolik bitu˚ z poslednı´ho oktetu, ktery´ je k dispozici, ma´me vyhradit pro adresu podsı´teˇ: 2N − 2 ≥ 5, chceme nejnizˇsˇ´ı N, pro ktere´ rovnice platı´ (funkce 2N − 2 oznacˇuje pocˇet platny´ch podsı´tı´). Vyhovuje N = 3. Poslednı´ oktet tedy rozdeˇlı´me na 3 bity podsı´teˇ a zby´vajı´cı´ch 5 bitu˚ pouzˇijeme pro adresu stanic v dane´ podsı´ti. „nulove´“ hodnoty (vsˇechny bity na 0) jsou zaka´za´ny. Stanovenı´ prvnı´ podsı´teˇ: Prvnı´ platne´ cˇ´ıslo podsı´teˇ je bina´rneˇ 00100000, desı´tkoveˇ 32. To znamena´, zˇe adresa prvnı´ podsı´teˇ je 192.168.35.32/27, prefix se prodlouzˇil o 3. Adresy stanic v prvnı´ podsı´ti jsou 192.168.35.33 azˇ 192.168.35.62, protozˇe poslednı´ oktet mu˚zˇe by´t bina´rneˇ 00100001 ... 00111110
(prvnı´ stanice v podsı´ti) (poslednı´ stanice v podsı´ti)
Adresa vsˇesmeˇrove´ho vysı´la´nı´ (tj. broadcast) pro tuto podsı´t’ je 192.168.35.63/27 (poslednı´ oktet 00111111). Stanovenı´ druhe´ podsı´teˇ: Druha´ podsı´t’ bude mı´t v adrese poslednı´ oktet bina´rneˇ 01000000, desı´tkoveˇ 64. Vsˇimneˇte si, zˇe je o 1 veˇtsˇ´ı nezˇ tenty´zˇ oktet u adresy pro broadcast v prvnı´ podsı´ti. Adresa druhe´ podsı´teˇ je 192.168.35.64/27. Vidı´me, zˇe v adresa´ch stanic bude poslednı´ oktet naby´vat hodnot 01000001 azˇ 01011110, desı´tkoveˇ 65 azˇ 94. Adresa broadcastu pro druhou podsı´t’je 192.168.35.95/27. Podobneˇ postupujeme i da´le – v adrese trˇetı´ podsı´teˇ bude poslednı´ oktet bina´rneˇ 01100000, desı´tkoveˇ 96, v adrese cˇtvrte´ podsı´teˇ bina´rneˇ 10000000, desı´tkoveˇ 128, v adrese pa´te´ podsı´teˇ bina´rneˇ 10100000, desı´tkoveˇ 160. Nesmı´me zapomı´nat, zˇe vsˇech zby´vajı´cı´ch 5 bitu˚ naby´va´ najednou hodnoty 0 pouze v adrese podsı´teˇ a hodnoty 1 pouze v adrese broadcast adresy podsı´teˇ, tedy pro stanice v podsı´ti volı´me hodnoty mezi teˇmito dveˇma mezemi. Shrneme adresy podsı´tı´: Adresa podsı´teˇ 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 bina´rneˇ 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 optima´lnı´ rozdeˇlenı´, neˇktere´ adresy zu˚sta´vajı´ nevyuzˇity, prˇedevsˇ´ım proto, zˇe jsme nevycˇerpali vsˇechny mozˇnosti stanovenı´ podsı´tı´ (trˇi bity podsı´teˇ by jesˇteˇ mohly
$
1.5
PROTOKOL IPV4
27
naby´vat hodnot 110 a 111, ale „same´ jednicˇky“ jsou opeˇt rezervova´ny). Take´ podsı´t’s teˇmito trˇemi bity nulovy´mi nenı´ pouzˇitelna´, protozˇe se jedna´ o adresu cele´ sı´teˇ. Vy´hodou je vsˇak zjednodusˇenı´ smeˇrova´nı´ v sı´ti. Hlavnı´ je, aby se adresy stanic v jednotlivy´ch podsı´tı´ch neprˇekry´valy, cozˇ ma´me zajisˇteˇno vyhrazenı´m trˇ´ı bitu˚ pro jednoznacˇnou adresu podsı´teˇ.
Dalsˇ´ım rozsˇ´ırˇenı´m vyuzˇitı´ podsı´tı´ bylo zavedenı´ mechanismu VLSM (Variable Length Subnet Masks). Tento mechanismus umozˇnˇuje v ra´mci jedne´ sı´teˇ pouzˇ´ıvat neˇkolik ru˚zny´ch masek podsı´teˇ (to znamena´ nejen vı´c ru˚zny´ch adres podsı´teˇ, ale navı´c i ru˚zneˇ dlouhy´ch). Vy´sledne´ adresy stanic prˇesto musejı´ zu˚stat jednoznacˇne´, cozˇ znamena´ urcˇita´ omezenı´ prˇi volbeˇ adres podsı´tı´ a uzlu˚.
P
V praxi se tento mechanismus pouzˇ´ıva´ pro podrobneˇjsˇ´ı hierarchicke´ deˇlenı´ (v ra´mci podsı´teˇ mu˚zˇe by´t vı´ce vnorˇeny´ch podsı´tı´ apod.), cozˇ opeˇt lze s vy´hodou vyuzˇ´ıt prˇi zjednodusˇenı´ smeˇrova´nı´. Prˇı´klad Pocˇet bitu˚ sı´teˇ a podsı´teˇ se zapisuje za adresou. Naprˇ´ıklad • 154.56.0.0/16 je adresa sı´teˇ (trˇ´ıda B), • 154.56.32.0/20 je adresa podsı´teˇ (celkem 20 bitu˚, tj. pro podsı´t’ova´nı´ jsou pouzˇity 4 bity), • 154.56.32.0/26 je adresa vnorˇene´ podsı´teˇ podle VLSM (v ra´mci pu˚vodnı´ podsı´teˇ vytvorˇ´ıme dalsˇ´ı podsı´t’na 6 bitech), bity navı´c zde zu˚sta´vajı´ nastaveny na 0, i kdyzˇ to nenı´ zapotrˇebı´.
Obecneˇ opeˇt nelze vyuzˇ´ıvat „nulove´“ krajnı´ hodnoty, prˇesto vsˇak na neˇktery´ch routerech (naprˇ. od firmy Cisco) lze zapnout mozˇnost jejich vyuzˇ´ıva´nı´.2 Dalsˇ´ı „generacı´“ vylepsˇenı´ je CIDR (Classless Interdomain Routing, beztrˇ´ıdnı´ smeˇrova´nı´), take´ se nazy´va´ nadsı´t’ova´nı´ (supernetting). Jedna´ se o u´plne´ odboura´nı´ cˇleneˇnı´ IP adres do trˇ´ıd (classless). CIDR cˇlenı´ IP adresu na dveˇ cˇa´sti – prefix a adresu uzlu. Prefix je vlastneˇ shrnutı´m pu˚vodnı´ch adres sı´teˇ a podsı´teˇ. Za´pis je zcela zpeˇtneˇ kompatibilnı´. Stejneˇ jako u VLSM se de´lka prefixu zapisuje za adresu a podle tohoto cˇ´ısla lze zjistit hranici mezi prefixem (obdobou adresy sı´teˇ/podsı´teˇ) a adresou uzlu. Prˇı´klad Naprˇ´ıklad u adresy 154.56.129.48/23 je de´lka prefixu 23, to znamena´, zˇe • maska je bina´rneˇ 11111111.11111111.11111110.0, decima´lneˇ 255.255.254.0, • prefix je bina´rneˇ 10011010.111000.10000000.0, decima´lneˇ 154.56.128.0 (prˇevedeme pu˚vodnı´ adresu do bina´rnı´ formy a provedeme operaci AND s maskou). 2
V Cisco IOS noveˇjsˇ´ıch verzı´ se zapnutı´ prova´dı´ prˇ´ıkazem ip subnet-zero.
P
1.5
PROTOKOL IPV4
28
De´lka prefixu 23 necha´va´ zbytek adresy (tj. 9 bitu˚ vpravo) adresa´m stanic, tj. 512 mozˇny´ch adres stanic, kdezˇto naprˇ´ıklad pro prefix 18 by to bylo 15 bitu˚ pro adresy stanic, cozˇ znamena´ 16 384 adresovatelny´ch stanic pro prefix.
Stanovenı´ prefixu˚ a adres stanic je podobne´ jak jsme videˇli na prˇ´ıkladu pro trˇ´ıdy adres, jen nejsme omezeni hranicemi trˇ´ıd a prefixy mohou naby´vat ru˚zny´ch de´lek. Zajı´mavy´m projektem je Subnet Calculator (http://www.subnet-calculator.com/), kde si prˇ´ımo na webu mu˚zˇeme stanovit pocˇet bitu˚ podsı´teˇ a zı´ska´me pocˇet podsı´tı´, pocˇet stanic v podsı´ti a rozpeˇtı´ adres. Problematika stanovova´nı´ podsı´tı´ a rozdeˇlova´nı´ adres je probı´ra´na v mnoha zdrojı´ch, zajı´mavy´ pohled je naprˇ´ıklad v literaturˇe [2] (najdete v seznamu literatury).
1.5.5
Jak stanice mu˚zˇe zı´skat IPv4 adresu
U IPv4 existujı´ dveˇ za´kladnı´ mozˇnosti zı´ska´nı´ adresy – staticky a dynamicky. Staticka´ adresa je pevneˇ prˇideˇlena´, je trˇeba ji stanoveny´m zpu˚sobem nakonfigurovat, at’ uzˇ ve Windows (v Ovla´dacı´ch panelech najdeme na´stroj pro pra´ci se sı´t’ovy´mi prˇipojenı´mi, na´zev za´lezˇ´ı na verzi, v seznamu prˇipojenı´ najdeme to, ktere´ chceme konfigurovat, zvolı´me vlastnosti, tam v seznamu pouzˇ´ıvany´ch protokolu˚ najdeme TCP/IPv4, vlastnosti) nebo v Linuxu (take´ lze v graficke´m rozhranı´). Staticka´ adresa mu˚zˇe by´t verˇejna´ nebo soukroma´. Mnozı´ poskytovatele´ Internetu jesˇteˇ neda´vno inzerovali, zˇe kazˇdy´ klient dostane statickou IP adresu, ale vesmeˇs sˇlo o adresu soukromou. Staticka´ adresa je potrˇebna´ prˇedevsˇ´ım u teˇch uzlu˚ sı´teˇ, ktere´ majı´ by´t (trvale) dostupne´. Prˇedevsˇ´ım jde o servery a du˚lezˇiteˇjsˇ´ı sı´t’ove´ prvky. Dynamicke´ adresy jsou obvykle´ prˇedevsˇ´ım u beˇzˇny´ch pracovnı´ch stanic (takovy´ch, ktere´ majı´ vlastnı´ operacˇnı´ syste´m, nejde o tenke´ klienty). Dynamickou adresu zı´ska´ zarˇ´ızenı´ prˇes protokol DHCP. Komunikace mezi DHCP klientem a DHCP serverem je naznacˇena na obra´zku 1.11. Vsˇimneˇte si, zˇe jde o broadcasty (bud’ adresa 255.255.255.255, a nebo mı´stnı´ broadcast pro danou podsı´t’), protozˇe klient jesˇteˇ nema´ prˇideˇlenou adresu (tudı´zˇ nemu˚zˇe jı´t o unicast pakety). Od prvnı´ho kroku je v parametrech DHCP paketu MAC adresa klienta, tedy by nemeˇlo dojı´t k neu´myslne´ za´meˇneˇ s jiny´m zˇa´dajı´cı´m uzlem. DHCP server si vede za´sobnı´k adres (Address Stack, Pool), cozˇ je vlastneˇ seznam adres, ktere´ mu˚zˇe prˇideˇlit. Po prˇideˇlenı´ je adresa oznacˇena jako pouzˇita´ (prˇideˇlena´) a jsou k nı´ evidova´ny vsˇechny potrˇebne´ informace (prˇedevsˇ´ım MAC adresa zarˇ´ızenı´, ktere´mu je prˇideˇlena). Adresa je ve skutecˇnosti pronajata (leased) na konkre´tnı´ dobu. Tato doba je ru˚zna´, za´lezˇ´ı na konfiguraci DHCP serveru, mu˚zˇe jı´t o hodiny azˇ dny. Po vyprsˇenı´ propu˚jcˇenı´ adresy musı´ zarˇ´ızenı´ opeˇt o adresu pozˇa´dat. Kromeˇ IP adresy DHCP server poskytuje dalsˇ´ı informace, prˇedevsˇ´ım masku podsı´teˇ, vy´chozı´ bra´nu, adresy DNS serveru˚. DHCP server mu˚zˇe beˇzˇet naprˇ´ıklad na smeˇrovacˇi. V sı´ti obvykle by´va´ jeden DHCP server, aby nedocha´zelo ke kolizı´m (nezapomenˇme, zˇe stanice „objevuje“ DHCP server broadcastem, meˇ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 da´ adresu? V DHCP paketu mu˚zˇe by´t zˇa´dost o drˇ´ıve pouzˇ´ı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, bra´na, doba platnosti, DNS servery.
UDP broadcast DHCP Request source 0.0.0.0, sport=68 dest 255.255.255.255, dport=67
ˇ a´dost o konkre´tnı´ adresu (v poZ lı´ch DHCP paketu je zˇa´dana´ adresa a adresa serveru, ktery´ ji nabı´dl).
UDP broadcast DHCP Ack source IP adr. DHCP serveru, sport=67 dest 255.255.255.255, dport=68
Potvrzenı´ (acknowledgement) prˇideˇlenı´ IP adresy, v polı´ch DHCP paketu je opeˇt nabı´dka adres, maska, bra´na, doba platnosti, DNS servery.
Obra´zek 1.11: Obvykly´ postup zı´ska´nı´ dynamicke´ adresy Kombinacı´ staticke´ho a dynamicke´ho prˇ´ıstupu je staticka´ alokace. Jde o to, zˇe klient sice zı´ska´va´ adresu prˇes DHCP, ale vzˇdy stejnou, cozˇ mu˚zˇe usnadnit fungova´nı´ sluzˇeb va´zany´ch na konkre´tnı´ IP adresu. Jde o to, zˇe v konfiguraci DHCP serveru se ke konkre´tnı´ IP adrese rucˇneˇ namapuje konkre´tnı´ MAC adresa. Ovsˇem ne kazˇdy´ DHCP server tuto mozˇnost poskytuje a vy´robci ji oznacˇujı´ ru˚zny´mi na´zvy (Static DHCP, MAC/IP Binding, Reserved IP Address, IP Reservation, apod.). Bezdiskove´ stanice (tenke´ klienty) majı´ specificke´ zpu˚soby zı´ska´va´nı´ adres. Tato problematika je popsa´na take´ na http://www.fi.muni.cz/~kas/p090/referaty/2008-podzim/ct/dhcp.html. ´ koly U V prˇ´ıloha´ch najdeˇte prˇ´ıkazy umozˇnˇujı´cı´ zjistit a nastavit IP adresu ve Windows a v Linuxu. Vyzkousˇejte (v tom operacˇnı´m syste´mu, ktery´ ma´te k dispozici).
1.6
Protokol IPv6
Protokol IP verze 6 (IPv6, take´ IPng – next generation) ma´ vyrˇesˇit zoufalou situaci s akutnı´m nedostatkem adres protokolu IPv4. Zatı´mco adresy IPv4 zabı´rajı´ 32 bitu˚, adresy IPv6 jsou dlouhe´ 128 bitu˚, cozˇ by bohateˇ meˇlo stacˇit pro jaka´koliv zarˇ´ızenı´ na sveˇteˇ (teoreticky jde o pocˇet 1038 adres).
P
1.6
PROTOKOL IPV6
30
Prˇ´ınos IPv6 je vsˇak mnohem sˇirsˇ´ı. Strucˇneˇ lze shrnout rozdı´ly takto: • • • • •
rozsah adres, podpora bezpecˇnostnı´ch funkcı´ (v IPv4 tyto funkce zajisˇt’oval protokol IPSec), zvy´sˇena´ podpora pro mobilnı´ zarˇ´ızenı´ (MIPv6), mozˇnost autokonfigurace stanice (zjednodusˇene´ zı´ska´nı´ IP adresy), QoS – zajisˇt’ova´nı´ u´rovneˇ sluzˇeb na mnohem vysˇsˇ´ı u´rovni, atd.
P
Prˇechod na IPv6 by meˇl by´t vy´hodny´ nejen z hlediska pocˇtu adres a zajisˇteˇnı´ bezpecˇnosti, ale take´ pro sluzˇby VoIP, videokonference, RFID, grid computing, on-line hry, inteligentnı´ budovy apod. Jedno sı´t’ove´ rozhranı´ mu˚zˇe mı´t i vı´ce nezˇ jednu IPv6 adresu. Dalsˇ´ı informace jsou na http://www-01.ibm.com/support/knowledgecenter/ssw i5 54/rzai2/rzai2compipv4ipv6.htm?lang=cs Protokoly IPv4 a IPv6 mohou by´t pouzˇ´ıva´ny za´rovenˇ, dokonce i na tomte´zˇ uzlu v sı´teˇ. Hlavnı´m garantem prˇideˇlova´nı´ IPv6 adres je ICANN (Internet Corporation for Assigned Network Numbers, http://www.icann.org), kdezˇto organizace IANA (Internet Assigned Numbers Authority, http://www.iana.org/) toto prˇideˇlova´nı´ fyzicky prova´dı´.
Celkova´ struktura prˇideˇlova´nı´ adres je hierarchicka´. IANA prˇideˇluje bloky adres regiona´lnı´m registra´toru˚m RIR, cozˇ jsou RIPE (Evropa a cˇa´st Asie), ARIN (Severnı´ Amerika), AfriNIC (Afrika), LACNIC (Latinska´ Amerika), APNIC (Asie a Pacifik). Dalsˇ´ı patro hierarchie tvorˇ´ı loka´lnı´ registra´torˇi (LIR), kterˇ´ı sve´ bloky zı´ska´vajı´ od regiona´lnı´ch registra´toru˚. Od loka´lnı´ch registra´toru˚ pak sve´ rozsahy adres zı´ska´vajı´ za´kaznı´ci nebo dalsˇ´ı subjekty, ktere´ mohou sve´ rozsahy da´le distribuovat.
1.6.1
IPv6 datagramy
Struktura datagramu verze 6 je oproti verzi 4 znacˇneˇ pozmeˇneˇna´. Hlavnı´ odlisˇnost je struktura za´hlavı´. Zatı´mco datagram IPv4 ma´ za´hlavı´ promeˇnne´ de´lky a se spoustou informacı´ (z nichzˇ neˇktere´ obecneˇ nejsou vyuzˇ´ıva´ny), datagram IPv6 ma´ za´hlavı´ pevne´ de´lky a informacı´ je v neˇm mnohem me´neˇ. Du˚sledkem je rychlejsˇ´ı smeˇrova´nı´ (smeˇrovacˇe zpracova´vajı´ za´hlavı´ a takto majı´ usnadneˇnou pra´ci). Datagram IPv6 ma´ jedno povinne´ za´hlavı´ pevne´ de´lky a pak mohou na´sledovat volitelna´ za´hlavı´ s promeˇnnou de´lkou. Forma´t povinne´ho za´hlavı´ IPv6 datagramu je v tabulce 1.7. Vy´znam jednotlivy´ch polı´: • verze (4 bity) – verze protokolu (tedy 6), toto pole ma´ stejny´ rozmeˇr a urcˇenı´ jako u IPv4 (jen logicky jiny´ obsah), • priorita (8 bitu˚) – podobneˇ jako pole typ sluzˇby u IPv4, jednotlive´ bity umozˇnˇujı´ optimalizaci priorit, toto pole (za´rovenˇ s na´sledujı´cı´m) se pouzˇ´ıva´ pro QoS, • oznacˇenı´ datove´ho toku (20 bitu˚) – stanovuje zpu˚sob „specia´lnı´ho zacha´zenı´“ na smeˇrovacˇ´ıch pro neˇktere´ typy protokolu˚, s pakety patrˇ´ıcı´mi do te´hozˇ datove´ho toku se ma´ zacha´zet stejneˇ (zˇa´dny´ datovy´ tok: = 0), ma´ vy´znam take´ pro QoS,
P P
1.6
PROTOKOL IPV6
31
4
8
verze
priorita de´lka dat
4
8
8
oznacˇenı´ datove´ho toku dalsˇ´ı za´hlavı´
hop limit
zdrojova´ IP adresa
cı´lova´ IP adresa Tabulka 1.7: Povinne´ za´hlavı´ datagramu protokolu IPv6 • de´lka dat (16 bitu˚) – de´lka zbytku datagramu (bez povinne´ho za´hlavı´), tj. vsˇech volitelny´ch za´hlavı´ a vlastnı´ch dat; pokud je zde hodnota 0, jedna´ se o tzv. jumbogram – datagram extre´mnı´ velikosti (azˇ 4 GB), cozˇ musı´ by´t podporova´no hardwarem ve vsˇech prvcı´ch sı´teˇ na cesteˇ a je nutne´ mı´t spra´vneˇ nakonfigurovanou hodnotu MTU, • dalsˇ´ı za´hlavı´ (8 bitu˚) – urcˇuje typ na´sledujı´cı´ho (volitelne´ho) za´hlavı´ te´hozˇ datagramu, pokud uzˇ zˇa´dne´ nena´sleduje, je zde cˇ´ıslo 59, • hop limit – obdoba TTL u IPv4, oznacˇuje maxima´lnı´ pocˇet smeˇrovacˇu˚ na cesteˇ, • zdrojova´ a cı´lova´ IP adresa (obeˇ 128 bitu˚, tj. pro kazˇdou adresu 4 rˇa´dky tabulky 1.7). IPv6 nedovoluje fragmentaci datagramu na smeˇrovacˇ´ıch po cesteˇ, datagram mu˚zˇe by´t fragmentova´n pouze na zdrojove´ stanici. Volitelna´ za´hlavı´ na´sledujı´ za povinny´m za´hlavı´m v prˇedem dane´m porˇadı´ (tedy porˇadı´ je du˚lezˇite´, RFC 2460), neˇktera´ (nebo i vsˇechna) mohou by´t vynecha´na. Kazˇdy´ typ volitelne´ho za´hlavı´ ma´ sve´ cˇ´ıslo, toto cˇ´ıslo najdeme v poli „dalsˇ´ı za´hlavı´“ prˇedchozı´ho za´hlavı´ (tj. v povinne´m za´hlavı´ zjistı´me, jake´ho typu je prvnı´ volitelne´ za´hlavı´, v prvnı´m zjistı´me typ druhe´ho volitelne´ho, atd.). Neˇktera´ z pouzˇ´ıvany´ch volitelny´ch za´hlavı´: • hop-by-hop options header (0, informace pro smeˇrovacˇe na cesteˇ, smeˇrovacˇe cˇtou jen toto za´hlavı´), • routing header (cˇ´ıslo 43, zde mohou by´t urcˇeny smeˇrovacˇe, prˇes ktere´ ma´ cesta ve´st, v obra´cene´m porˇadı´ je za´vazne´ i pro odpoveˇd’), • fragment header (44, pokud je datagram na zdrojove´ stanici fragmentova´n, je pouzˇito toto za´hlavı´ s informacı´ o fragmentaci, podobne´ u´daje jako v za´hlavı´ IPv4; stanice musı´ zna´t hodnoty MTU na cesteˇ), • authentication header (cˇ´ıslo 51, obsahuje autentizacˇnı´ informaci), • encapsulating security header (50, u´daje o sˇifrova´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 skla´da´ ze dvou cˇa´stı´ – prefixu a identifika´toru sı´t’ove´ho rozhranı´ (adresy uzlu v ra´mci jednoho prefixu). Podobneˇ jako u IPv4 adres, i zde je snaha o co nejveˇtsˇ´ı zjednodusˇenı´ smeˇrova´nı´, proto adresy cˇasto odra´zˇejı´ fyzickou strukturu sı´teˇ propojene´ smeˇrovacˇi (i v globa´lnı´m meˇrˇ´ıtku). IANA prˇideˇluje za´kladnı´ rozsahy (prvnı´ch 12 bitu˚, tj. prefix ma´ v takove´m rozsahu de´lku 12) jednotlivy´m regiona´lnı´m registra´toru˚m (kryjı´ se prˇiblizˇneˇ s kontinenty – RIR, Regional Internet Registry), ti sve´ rozsahy da´le distribuujı´ (naprˇ´ıklad na 32 bitu˚, kde by de´lka prefixu byla 32). Dalsˇ´ı deˇlenı´ prova´deˇjı´ poskytovatele´ Internetu a samozrˇejmeˇ pro sve´ podsı´teˇ jednotlive´ organizace. Rozlisˇujı´ se adresy • unicast (konkre´tnı´ uzel v sı´ti), • multicast (skupinove´), • anycast (adresace komukoliv ze zadane´ skupiny).
P P
Broadcast adresy jizˇ nejsou podporova´ny. Adresy majı´ jiny´ zpu˚sob za´pisu. Jednotlive´ cˇa´sti (cozˇ jsou dvojice oktetu˚, nikoliv samotne´ oktety jako v IPv4) se oddeˇlujı´ dvojtecˇkou a zapisujı´ se hexadecima´lneˇ. To znamena´, zˇe adresa ma´ celkem 8 cˇa´stı´ (128/16). Adresa mu˚zˇe vypadat naprˇ´ıklad takto: A4CB:57B1:60AA:2F0E:113A:B201:042A:02B1
Adresa je velmi dlouha´ a teˇzˇko si ji neˇkdo zapamatuje (i kdyzˇ vyloucˇeno to samozrˇejmeˇ nenı´). Oproti IPv4 lze za´pis zjednodusˇit odstraneˇnı´m posloupnosti nulovy´ch skupin oktetu˚. V jedne´ adrese tak mu˚zˇeme odstranit pouze jednu posloupnost nul a mı´sto odstraneˇnı´ musı´ by´t oznacˇeno dvojitou dvojtecˇkou, naprˇ´ıklad adresu A4CB:57B1:0000:0000:0000:B201:042A:02B1
lze zkra´tit na A4CB:57B1::B201:042A:02B1
a mu˚zˇeme take´ vynechat nuly ve skupina´ch oktetu˚ vlevo: A4CB:57B1::B201:42A:2B1
Prˇı´klad Opravdu lze kra´tit pouze jednu jedinou posloupnost nul. Naprˇ´ıklad adresu 2001:0db8:3c4d:0000:0000:a011:0000:0000
lze zkra´tit jednı´m z teˇchto zpu˚sobu˚: 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)
sˇpatneˇ by bylo 2001:0db8:3c4d::a011:: protozˇe by takova´ adresa byla nejednoznacˇna´. Podle pocˇtu cˇa´stı´ adresy je zrˇejme´, zˇe nulove´ jsou celkem cˇtyrˇi cˇa´sti (celkem jich musı´ by´t 8), ale kdyzˇ v adrese vidı´me dveˇ mı´sta kra´cenı´, nemu˚zˇeme prˇesneˇ rˇ´ıci, jak jsou mezi neˇ tyto cˇtyrˇi nulove´ cˇa´sti rozmı´steˇny. Mohla by to by´t naprˇ´ıklad i chybna´ mozˇnost 2001:0db8:3c4d:0000:a011:0000:0000:0000
$
1.6
PROTOKOL IPV6
33
U (nejen) veˇtsˇ´ıch organizacı´ by´va´ zvykem deˇlit vnitrˇnı´ sı´t’na podsı´teˇ. Organizace dostane prˇideˇlen vlastnı´ prefix a zarˇ´ızenı´m ve sve´ sı´ti pak prˇideˇluje adresy podle tohoto prefixu. Mu˚zˇe si vsˇak stanovit sˇirsˇ´ı prefixy, ktere´ obsahujı´ pu˚vodnı´ prefix a neˇkolik bitu˚ navı´c, a kazˇdy´ z nich prˇideˇlı´ jedne´ sve´ podsı´ti. Prˇı´klad Organizace mu˚zˇe vyuzˇ´ıvat naprˇ´ıklad takove´to adresova´nı´: A4CB:57B1:B201::/48
prefix prˇideˇleny´ 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 trˇetı´ podsı´t’
A4CB:57B1:B201:1::4A/64
adresa neˇktere´ stanice v prvnı´ podsı´ti
Dveˇ vyhrazene´ adresy: • ::/128 je „nedefinovana´ adresa“ (stanice nema´ prˇideˇlenou adresu, vsˇechny cˇa´sti jsou 0), • ::1/128 je loopback (loka´lnı´ smycˇka).
P
Dalsˇ´ı vyhrazene´ adresy – skupinove´: • FF00::/8 – skupinova´ adresa prˇedstavujı´cı´ vsˇechny dostupne´ DHCP servery, • FF02::2 – skupinova´ adresa vsˇech dostupny´ch smeˇrovacˇu˚, • FF02::1 – skupinova´ adresa vsˇech uzlu˚ sı´teˇ podporujı´cı´ch IPv6. Podobneˇ jako u IPv4, i zde rozlisˇujeme globa´lnı´ a loka´lnı´ adresy, ale u´cˇel a princip je trochu jiny´. Adresy s prefixem 2000::/3 jsou globa´lnı´, pomocı´ teˇchto adres lze komunikovat na Internetu. Da´le existujı´ tyto typy loka´lnı´ch adres:
P
• unique local (ULA adresy) – prefix FD00::/8, slouzˇ´ı k posı´la´nı´ unicast dat v ra´mci loka´lnı´ sı´teˇ (organizace apod.), je to obdoba soukrome´ IP adresy v IPv4, nesmı´ by´t viditelna´ mimo loka´lnı´ sı´t’, ale je zde zarucˇena unika´tnost (narozdı´l od na´sledujı´cı´ho typu adresy), • link local – prefix FE80::/10, tato adresa je loka´lnı´ v ra´mci podsı´teˇ (segmentu, tj. v rozmezı´ viditelnosti linkove´ vrstvy L2 dane´ho zarˇ´ızenı´), link local adresy neprˇejdou prˇes smeˇrovacˇ a obvykle kazˇda´ sı´t’ova´ karta ma´ tuto adresu prˇideˇlenu prˇi sve´ aktivaci. Unika´tnost ULA adresy se zajisˇt’uje odvozenı´m z data (cˇasu) generova´nı´ adresy a z MAC adresy stanice. Pu˚vodneˇ se pocˇ´ıtalo jesˇteˇ s tzv. site local adresou, ktera´ by fungovala prˇesneˇ jako loka´lnı´ adresy v IPv4 (vcˇetneˇ prˇekladu adres), jejı´ prefix je FEC0::/10.
1.6.3
Jak stanice mu˚zˇe zı´skat IPv6 adresu
Prˇedneˇ je du˚lezˇite´, zˇe kazˇdy´ smeˇrovacˇ v sı´ti vysı´la´ v pravidelny´ch intervalech informaci oznacˇenou RA (Router Advertisement, ozna´menı´ smeˇrovacˇe). Soucˇa´stı´ te´to informace je prefix adres v sı´ti a adresa smeˇrovacˇe, prˇes ktery´ lze dostat pakety ven ze sı´teˇ. Pokud tedy stanice potrˇebuje tuto
P
1.6
PROTOKOL IPV6
34
informaci (urcˇiteˇ ji potrˇebuje, kdyzˇ postupneˇ zjisˇt’uje, jakou ma´ mı´t IP adresu), tak bud’ nasloucha´ na sı´ti a nebo necˇeka´ a informaci si vyzˇa´da´ zˇa´dostı´ RS (Router Solicitation, zˇa´dost o informace o smeˇrovacˇi a prefixu). Mechanismus RA nesouvisı´ s DHCP, funguje i v prˇ´ıpadeˇ, zˇe v sı´ti nenı´ zˇa´dny´ DHCP server. Pouzˇ´ıvajı´ se ICMP zpra´vy. Podı´va´me se tedy na jednotlive´ mozˇnosti zı´ska´nı´ cele´ IPv6 adresy. 1. Dynamicky prˇes DHCP server (Stavovy´ rezˇim DHCP, RFC 3315). DHCP server eviduje propu˚jcˇene´ IP adresy a stanice, ktery´m je udeˇlil (tato informace prˇedstavuje momenta´lnı´ stav protokolu), proto stavovy´ rezˇim.
$
Obeˇ strany jsou na zacˇa´tku komunikace identifikova´ny pomocı´ DUID (mı´sto MAC adresy) – DHCP Unique ID. Je to jednoznacˇny´ identifika´tor generovany´ z vı´ce ru˚zny´ch parametru˚, je cˇa´stecˇneˇ neza´visly´ na HW. DUID najdeme ve Windows v registru, v UNIX-like syste´mech obvykle v souboru /var/db. Je du˚lezˇite´, zˇe pokud ma´me vı´c na pocˇ´ıtacˇi vı´c operacˇnı´ch syste´mu˚ (at’uzˇ dı´ky virtualizaci nebo na ru˚zny´ch oddı´lech), kazˇdy´ ma´ jine´ DUID. Ve stavove´m rezˇimu DHCP se postupuje takto: • stanice vysˇle multicast na FF00::/8 s dotazem na DHCP servery, • DHCP server(-y) odpovı´ svou IP adresou na FF02::1 a svy´m DUID s nabı´dkou, • Request – stanice (DHCP klient) si vybere (podle nabı´zeny´ch parametru˚) a posˇle anycast s uvedeny´m DUID serveru zˇa´dost o adresu (uvede take´ sve´ DUID), • Reply – odpoveˇd’ serveru: IPv6 adresa (vcˇetneˇ prefixu), de´lka prefixu v adrese, prˇ´ıpadneˇ IP adresy DNS serveru˚, • stanice zkontroluje, jestli adresa nenı´ duplicitnı´; pokud ano, odmı´tne (Decline) a vra´tı´ se k 3. bodu. Adresa je docˇasna´, je propu˚jcˇena na urcˇitou dobu. Po uplynutı´ te´to doby stanice odesˇle zˇa´dost o potvrzenı´ adresy. DHCP server si prˇi zmeˇneˇ sı´t’ovy´ch parametru˚ mu˚zˇe vynutit reakci u klientu˚ zpra´vou Reconfigure. Pokud klient odcha´zı´ ze sı´teˇ, informuje DHCP server zpra´vou o uvolneˇnı´ (Release). Pokud jen docˇasneˇ opustil sı´t’(trˇeba restart), pak odesı´la´ zˇa´dost o potvrzenı´ pu˚vodnı´ch parametru˚ (Confirm) na skupinovou adresu DHCP serveru˚, DHCP server potvrdı´ nebo odmı´tne. Ostatnı´ zpu˚soby prˇideˇlova´nı´ adres jsou nestavove´ (nestavove´ chova´nı´ DHCPv6), protozˇe nenı´ potrˇeba informace o jiny´ch adresa´ch v sı´ti. 2. Autokonfigurace stanice s EUI-64. Proces autokonfigurace ma´ usnadnit pocˇa´tecˇnı´ konfiguraci (a take´ prˇihlasˇova´nı´) uzˇivatelske´ stanice ze strany ISP, spra´vu prˇipojeny´ch zarˇ´ızenı´, ktera´ nejsou pocˇ´ıtacˇi (naprˇ´ıklad doma´cı´ spotrˇebicˇe), znacˇneˇ se take´ zjednodusˇuje konfigurace stanic propojeny´ch ad-hoc (bez serveru a smeˇrovacˇu˚). Mu˚zˇeme se take´ setkat se zkratkou SLAAC (Stateless Address Autoconfiguration). Abychom si ujasnili vztah RA a SLAAC: nenı´ to tote´zˇ. Staticka´ konfigurace SLAAC vyuzˇ´ıva´ mechanismus RA ke zkompletova´nı´ adresy v sı´t’ove´ cˇa´sti. Autokonfigurace se prova´dı´ prˇes protokol ICMPv6 a spocˇ´ıva´ v mechanismu zjisˇt’ova´nı´ sousedu˚ (neighborhood), viz str. 37. Kazˇda´ stanice ma´ svu˚j jednoznacˇny´ identifika´tor EUI (Extended Unique Identifier) vycha´zejı´cı´ z MAC adresy. EUI-64 (zabı´rajı´cı´ 64 bitu˚) se zı´ska´ z MAC (48bitove´) vlozˇenı´m
$
P
1.6
PROTOKOL IPV6
35
sekvence 0×FFFE prˇesneˇ uprostrˇed a zmeˇnou jednoho bitu – sedme´ho bitu v prvnı´m oktetu na 1 (tento bit je oznacˇova´n jako U/L). Jak bylo vy´sˇe uvedeno, IPv6 adresa mu˚zˇe by´t takto jednodusˇe mapova´na z MAC adresy. Postup prˇi nestavove´m DHCP (RFC 2462, pak RFC 4862): • uzel vytvorˇ´ı link-local adresu (pouzˇije prefix FE80::/10, zbytek adresy vytvorˇ´ı z EUI-64 nebo jiny´m zpu˚sobem), • provede detekci duplicitnı´ch adres, aby bylo jiste´, zˇe ma´ jedinecˇnou adresu v sı´ti (prˇes ICMPv6 se zepta´ souseda, ten se ozve, pokud adresu zna´ ⇒ adresu by uzˇ meˇl jiny´ uzel) – vyuzˇije mechanismus zjisˇt’ova´nı´ sousedu˚, • z RA zı´ska´ informace – prefix podsı´teˇ, dalsˇ´ı informace o smeˇrovacˇi apod. (posloucha´ na adrese FF02::1 – skupina vsˇech zarˇ´ızenı´ podporujı´cı´ch IPv6); pokud nechce cˇekat na RA, posˇle na FF02::2 RS (zˇa´dost o RA), • z toho vsˇeho vytvorˇ´ı svou platnou IPv6 adresu. Zby´va´ zjistit adresy DNS serveru˚. Prˇı´klad EUI-64 se urcˇ´ı na´sledovneˇ: 1234:5678:9ABC:DEF0::/64
je prefix sı´teˇ, stanice ho zjistila vy´sˇe popsany´m zpu˚sobem od smeˇ-
rovacˇe 00-20-ED-89-A0-4E
je MAC adresa stanice
je EUI-64 (v prvnı´m oktetu jsme zameˇnili hodnotu prˇedposlednı´ho bitu na 1, doprostrˇed je vsunut dvojoktet FFFE)
0220:EDFF:FE89:A04E
1234:5678:9ABC:DEF0:0220:EDFF:FE89:A04E
je vy´sledna´ IP adresa stanice
Velky´ proble´m je, zˇe narozdı´l od DHCP nenı´ beˇzˇnou soucˇa´stı´ RA tak du˚lezˇita´ informace jako jsou IP adresy jmenny´ch (DNS) serveru˚. Tyto adresy jsou pro spra´vne´ fungova´nı´ stanice na Internetu du˚lezˇite´, uzˇivatel prˇece nebude pracovat s cˇ´ıselny´mi IP adresami (jesˇteˇ k tomu tak dlouhy´mi). V soucˇasne´ dobeˇ existujı´ trˇi ru˚zna´ rˇesˇenı´: 1. Prˇida´nı´ informace o DNS serverech do RA ohlasˇova´nı´ (standardizova´no na podzim 2010, RFC 6106). Tuto mozˇnost je nutne´ nejdrˇ´ıv implementovat. Zatı´m tuto mozˇnost podporuje jen RA rˇesˇenı´ pro Linux (a neˇktere´ dalsˇ´ı UNIXy) – de´mon radvd. Na dalsˇ´ıch syste´mech (zvla´sˇteˇ u Windows) si jesˇteˇ dlouho pocˇka´me. 2. Specia´lnı´ anycast adresy pro DNS servery. Tato mozˇnost nebyla nikdy dotazˇena do konce, existuje pouze ve verzi draft, prˇedevsˇ´ım proto, zˇe pocˇ´ıta´ se site-local adresami, ktere´ byly ze specifikace IPv6 vypusˇteˇny. Implementaci najdeme v neˇktery´ch rˇesˇenı´ch od Microsoftu, ale nedoporucˇuje se je pouzˇ´ıvat. 3. Kombinace RA a DHCPv6. Prˇes RA (prˇ´ıpadneˇ s pozˇadavkem RS) si stanice vyzˇa´da´ informace o sı´ti a smeˇrovacˇi, dotvorˇ´ı si svou adresu pomocı´ EUI-64 (nebo Privacy Extensions popsany´ch nı´zˇe), info o DNS serverech zı´ska´ z DHCPv6.
$
1.6
PROTOKOL IPV6
36
´ cˇelem tohoto mechanismu je co nejvı´ce ztı´zˇit identi3. Autokonfigurace s Privacy Extensions. U fikaci koncovy´ch zarˇ´ızenı´ (prˇedevsˇ´ım potencia´lnı´mu u´tocˇnı´kovi, ale chaos si cı´l nevybı´ra´). Hostitelska´ cˇa´st adresy (adresa stanice v sı´ti) je dynamicky generova´na a obmeˇnˇova´na prˇiblizˇneˇ jednou za neˇkolik dnu˚ (doba se da´ nakonfigurovat). To ma´ bezpochyby sve´ vy´hody, ale ze strany administra´tora sı´teˇ jde o celkem podstatnou nevy´hodu – do sı´teˇ se mu kazˇdou chvı´li dostane zarˇ´ızenı´ s „novou“ IP adresou.
$
Privacy Extensions se pouzˇ´ıvajı´ prˇedevsˇ´ım ve Windows, kdezˇto unixove´ syste´my ji majı´ standardneˇ vypnutou. Protozˇe vypnutı´ Privacy Extensions ve Windows mu˚zˇe mı´t pro neˇktere´ uzly v sı´ti neocˇeka´vane´ neprˇ´ıznive´ du˚sledky, administra´torˇi si k udrzˇenı´ porˇa´dku v sı´ti a prˇehledu o prˇihla´sˇeny´ch zarˇ´ızenı´ch museli najı´t ru˚zne´ „okliky“ a na´stroje, naprˇ´ıklad volneˇ sˇirˇitelny´ na´stroj MetaNAV.3 Jinak lze vy´znam Privacy Extensions prˇirovnat k EUI-64, takte´zˇ je potrˇeba navı´c zı´skat prefix a dalsˇ´ı informace (cozˇ jsme si popsalı´ pra´veˇ v bodeˇ o EUI-64). 4. Staticka´ konfigurace. Staticky se konfiguruje bud’ cela´ 128bitova´ adresa, nebo jejı´ 64bitovy´ prefix (a zbytek adresy stanice dotvorˇ´ı z EUI-64). IP adresy jmenny´ch serveru˚ nejsou beˇhem staticke´ konfigurace zada´va´ny, stanice je zjistı´ stejneˇ jako u bezstavove´ho DHCPv6.
$
´ koly U Pokud ma´te IPv6 adresu, zjisteˇte, jaky´m zpu˚sobem byla vytvorˇena (do znacˇne´ mı´ry to take´ za´visı´ na tom, v jake´m operacˇnı´m syste´mu pracujete).
1.6.4
Zo´ny
V praxi se lze setkat se zarˇ´ızenı´mi, ktera´ majı´ vı´ce nezˇ jedno sı´t’ove´ rozhranı´ (naprˇ´ıklad zarˇ´ızenı´ se dveˇma sı´t’ovy´mi kartami). Proble´m mu˚zˇe nastat, pokud se pro toto zarˇ´ızenı´ pouzˇije link-local adresa. V prˇ´ıpadeˇ, zˇe kazˇde´ rozhranı´ je prˇipojeno k jine´ sı´ti (naprˇ´ıklad u dvou rozhranı´ s link-local adresami fe80::1/64 a fe80::2/64) a je trˇeba poslat paket neˇktere´mu zarˇ´ızenı´ patrˇ´ıcı´mu jen do jedne´ z teˇchto sı´tı´, ktere´ ma´ taky link-local adresu (naprˇ´ıklad fe80::3/64), nenı´ jasne´, ktere´ rozhranı´ vlastneˇ pouzˇ´ıt, protozˇe k rozlisˇenı´ nenı´ mozˇne´ pouzˇ´ıt prefix. Tato nejednoznacˇnost se rˇesˇ´ı definova´nı´m zo´n. Kromeˇ informace o adrese rozhranı´ je evidova´na take´ zo´na, ktera´ jizˇ jednoznacˇneˇ urcˇuje sı´t’u loka´lnı´ch adres. Na konec IPv6 adresy se prˇipojı´ symbol procenta a za neˇj oznacˇenı´ zo´ny. Obvykle´ oznacˇenı´: • IPv6adresa%cˇ´ıslo (ve Windows), naprˇ´ıklad fe80::94fd:241e:a5a1:d4bb%9
• IPv6adresa%ethcˇ´ıslo (v Linuxu), naprˇ´ıklad fe80::94fd:241e:a5a1:d4bb%eth1 3
http://metanav.uninett.no/
1.6
PROTOKOL IPV6
37
• IPv6adresa%pcncˇ´ıslo (v BSD syste´mech), naprˇ´ıklad fe80::94fd:241e:a5a1:d4bb%pcn1
Ne vsˇechny sı´t’ove´ aplikace vsˇak se zo´nami doka´zˇou pracovat. Zajı´mave´ a celkem podrobne´ pojedna´nı´ o IPv6 najdeme v seria´lu (hlavneˇ od druhe´ho dı´lu) na stra´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
Nove´ funkce ICMPv6. Zpra´va ICMPv6 Neighbour Solicitation slouzˇ´ı k „objevova´nı´“ sousedu˚, a zcela nahrazuje protokol ARP. Uzel touto zpra´vou pravidelneˇ kontroluje funkcˇnost svy´ch sousedu˚ a oni odpovı´dajı´ zpra´vou ICMPv6 Neighbour Advertisement.
P
ICMPv6 ma´ mnohem sˇirsˇ´ı mnozˇinu zpra´v. Kromeˇ vy´sˇe uvedene´ Neighbour Solicitation (NS) jsou to take´ zpra´vy souvisejı´cı´ se skupinovy´m vysı´la´nı´m (Group Membership Query – dotaz cˇlenstvı´ ve skupineˇ a odpovı´dajı´cı´ Group Membership Report, da´le Group Membership Reduction – omezenı´ cˇlenstvı´ ve skupineˇ). Zpra´va Redirect slouzˇ´ı k doporucˇenı´ adresa´tovi, aby datagramy pro urcˇity´ cı´l posı´lal prˇes jine´ho souseda (doporucˇenı´ na odstraneˇnı´ proble´mu ve smeˇrovacı´ tabulce). Tyto zpra´vy (spolu s dalsˇ´ımi mechanismy) plneˇ nahrazujı´ cˇinnost protokolu˚ ARP a IGMP, ktere´ jizˇ nejsou potrˇeba. Sousede´. Neˇktere´ typy komunikace vedou pouze k sousednı´m uzlu˚m v sı´ti. Stanice typicky mı´va´ jen jednoho souseda (neˇktery´ mezilehly´ uzel sı´teˇ), mezilehle´ uzly sı´teˇ vcˇetneˇ smeˇrovacˇu˚ majı´ sousedu˚ vı´ce. NDP (Neighbour Discovery Protocol) slouzˇ´ı k pra´ci se sousedy (take´ k posı´la´nı´ zpra´v mezi sousednı´mi mezilehly´mi prvky). Pracuje na sı´t’ove´ vrstveˇ (jako IP a ICMP) a vyuzˇ´ıva´ ICMP zpra´vy (tj. NDP protokol posı´la´ a prˇijı´ma´ ICMP zpra´vy, ktere´ se zapouzdrˇujı´ do IP datagramu). Jeho hlavnı´m u´kolem je zjisˇt’ova´nı´ a evidence informacı´ o okolnı´ch uzlech (jejich IP a MAC adresy apod.), tedy tote´zˇ, co bylo u IPv4 v ARP tabulka´ch. Je pouzˇ´ıva´n k mnoha ru˚zny´m u´cˇelu˚m, prˇedevsˇ´ım • zjisˇteˇnı´ IP a MAC (nejen MAC, obecneˇ z vrstvy L2) adres okolnı´ch uzlu˚ (zpra´va je adresova´na jako multicast, odpoveˇdi obsahujı´ IP a MAC adresy), prˇedevsˇ´ım se jedna´ o objevova´nı´ smeˇrovacˇu˚, • spolupra´ce na zı´ska´va´nı´ IP adresy, konkre´tneˇ zjisˇteˇnı´ prefixu, • zjisˇt’ova´nı´ duplicitnı´ch IP adres v sı´ti. Mnohe´ z toho, co bylo popsa´no v sekci o zı´ska´va´nı´ IPv6 adresy, zajisˇt’uje pra´veˇ protokol NDP. Mechanismus RS a RA vyuzˇ´ıvany´ prˇi objevova´nı´ routeru˚ (od ktery´ch chceme zı´skat IP adresu a dalsˇ´ı informace) je take´ soucˇa´stı´ mechanismu objevova´nı´ sousedu˚. Prˇı´klad Mechanismus objevova´nı´ sousedu˚ podle RFC 4861 si uka´zˇeme na prˇ´ıkladu zjisˇteˇnı´ MAC adresy souseda (v prˇ´ıpadeˇ, zˇe zna´me IPv6 adresu) – je to obdoba ARP dotazu. Tento prˇ´ıklad je prˇevzat z webu https://www.ipv6.cz/.
P
1.6
PROTOKOL IPV6
38
Postup: • posı´la´m datagram na skupinovou IPv6 adresu s prefixem ff02:0:0:0:0:1:ff00:0/104 • urcˇenı´ cele´ skupinove´ IPv6 adresy: – zna´m IPv6 adresu souseda, naprˇ. 2001:db8:1:1:22a:fff:fe32:5ed1 – z nı´ vezmu poslednı´ch 24 bitu˚ (3 oktety) a doda´m do skupinove´ IPv6 adresy z prvnı´ho bodu: ff02::1:ff32:5ed1 • na tuto adresu posˇlu ICMPv6 zpra´vu Neighbor Solicitation – vy´zvu sousedovi • soused odpovı´ zpra´vou Neighbor Advertisement obsahujı´cı´ jeho MAC adresu
Bezpecˇnost. Objevova´nı´ sousedu˚ ma´ jedno za´vazˇne´ u´skalı´: pokud obdrzˇ´ıme NS paket (paket s informacı´ o mapova´nı´ MAC a IP adres souseda), prˇedpokla´da´ se, zˇe u´daju˚m v tomto paketu budeme veˇrˇit. Jenzˇe tento paket mu˚zˇe by´t podvrzˇeny´ a du˚sledkem pouzˇ´ıva´nı´ te´to IP adresy je odesı´la´nı´ dat na jiny´ pocˇ´ıtacˇ nezˇ prˇedpokla´da´me, cozˇ zvla´sˇteˇ ve firemnı´m prostrˇedı´ mu˚zˇe zpu˚sobit odcizenı´ dat. Pro tento proble´m existuje neˇkolik rˇesˇenı´, z nichzˇ je zajı´mavy´ naprˇ´ıklad protokol SEND (Secure Neighbour Discovery – RFC 3971), ktery´ umozˇnˇuje digita´lneˇ podepisovat ozna´menı´ protokolu NDP. Pouzˇ´ıva´ se pro zajisˇteˇnı´ „objevovacı´“ a keep-alive komunikace se sousedy. Mozˇnosti:
P
• kryptograficky generovane´ adresy (CGA) – RFC 3972: koncept soukrome´ho a verˇejne´ho klı´cˇe, ICMPv6 zpra´vy jsou digita´lneˇ podepsa´ny, • certifikacˇnı´ cesty: ochrana proti falesˇny´m smeˇrovacˇu˚m – rˇeteˇzce navazujı´cı´ch certifika´tu˚ dokazujı´cı´, zˇe urcˇita´ du˚veˇryhodna´ certifikacˇnı´ autorita schva´lila toto zarˇ´ızenı´ jako smeˇrovacˇ poskytujı´cı´ dane´ informace (certifikacˇnı´ autority tvorˇ´ı hierarchii). O objevova´nı´ sousedu˚ najdeme informace naprˇ´ı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 U Ve Windows se da´ k u´daju˚m o NDP dostat v NetShellu, kontextu interface, podkontextu ipv6. Pro IPv4 pouzˇ´ıva´me prˇ´ıkaz arp a da´le lze sousedy zjistit prˇ´ıkazem nbtstat. V Linuxu je uzˇitecˇny´ prˇedevsˇ´ım prˇ´ıkaz ip neighbour (resp. ip neigh), pro IPv4 take´ arp. Najdeˇte v prˇ´ıloha´ch zpu˚sob pouzˇ´ıva´nı´ teˇchto prˇ´ıkazu˚ a zjisteˇte, jak vypsat seznam sousedu˚.
Kapitola
2
Ethernet Tato kapitola je veˇnova´na Ethernetu – IEEE 802.3. Veˇnujeme se strukturˇe Ethernetu, prˇenosovy´m technika´m a souvisejı´cı´m standardu˚m.
2.1
Za´kladnı´ pojmy
2.1.1
Co je to Ethernet
Ethernet vznikl roku 1976, a to dı´ky firma´m Xerox, Digital a Intel. Je standardizova´n jako IEEE 802.3, ale prˇ´ımo v tomto standardu se pojem „Ethernet“ vu˚bec nepouzˇ´ıva´ (kromeˇ jine´ho z licencˇnı´ch du˚vodu˚). Ethernet pouzˇ´ıva´ koliznı´ prˇ´ıstupovou metodu CSMA/CD (kromeˇ nejrychlejsˇ´ıch variant, tam se prakticky zˇa´dna´ koliznı´ metoda nepouzˇ´ıva´). V soucˇasne´ dobeˇ je Ethernet nejpouzˇ´ıvaneˇjsˇ´ım typem loka´lnı´ sı´teˇ (a prosazuje se dokonce i mimo oblast cˇisteˇ loka´lnı´ch sı´tı´) a jeho specifikace je velmi rozveˇtvena´. Vyuzˇ´ıva´ ru˚zne´ typy kabela´zˇe a take´ neˇkolik ru˚zny´ch topologiı´. Pouzˇ´ıva´ se v rychlostech 10, 100, 1000, 10 000, . . . Mb/s (ty nejpomalejsˇ´ı uzˇ ani ne). V ra´mci ISO/OSI modelu na fyzicke´ vrstveˇ se pouzˇ´ıva´ znacˇenı´ „XBASE-Y“, kde • X je rychlost, • BASE je signalizacˇnı´ metoda (Base nebo Broad – za´kladnı´ nebo prˇekla´dane´ pa´smo), • Y urcˇuje kabela´zˇ. Strucˇny´ prˇehled (pozdeˇji probereme podrobneˇji): DIX Ethernet je „stary´“ Ethernet, pu˚vodnı´ specifikace s prˇenosovou rychlostı´ v jednotka´ch Mb/s. Zkratka je utvorˇena z autoru˚ – DEC, Intel, XEROX. Ra´mce majı´ za´hlavı´ nekompatibilnı´ s na´sledujı´cı´mi. 10Mb Ethernet meˇl prˇenosovou rychlost 10 Mb/s, pouzˇ´ıval koaxia´lnı´ kabel se sbeˇrnicovou topologiı´ nebo vza´cneˇji opticky´ kabel s topologiı´ hveˇzda. Znacˇenı´ je 10Base-5 (tlusty´ koax), 10Base-2 (tenky´ koax), 10Base-F (opticke´ kabely), 10Base-T (UTP, byl nejpouzˇ´ıvaneˇjsˇ´ı). 39
O
ZA´KLADNI´ POJMY
2.1
40
Fast Ethernet (100Mb) ma´ prˇenosovou rychlost 100 Mb/s, pouzˇ´ıva´ kroucenou dvojlinku (veˇtsˇinou nestı´neˇnou) nebo opticky´ kabel, fyzicka´ topologie hveˇzda (i u na´sledujı´cı´ch). Gigabit Ethernet (1000Mb) opeˇt prˇiblizˇneˇ desetina´sobne´ zrychlenı´, pouzˇ´ıva´ se opticky´ kabel nebo kroucena´ dvojlinka (nestı´neˇna´ kat. 5e nebo stı´neˇna´). 10G Ethernet (10 Gb) dalsˇ´ı zrychlenı´, pouzˇ´ıva´ se optika, kroucena´ dvojlinka kat. 6 nebo twin-ax. 40/100G Ethernet (40 Gb, 100 Gb) na nejnoveˇjsˇ´ı standardy (rok 2010, IEEE 802.3ba), jsou urcˇeny prˇedevsˇ´ım pro rychle´ prˇipojenı´ datovy´ch center. Prˇedchu˚dcem Ethernetu podle IEEE 802.3 byl firemnı´ DIX Ethernet neboli „stary´ Ethernet“. Pozdeˇji vznikl standard IEEE 802.3, ktery´ se od pu˚vodnı´ho Ethernetu lisˇ´ı prˇedevsˇ´ım forma´tem ra´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’ove´ prvky
Uzly ethernetove´ sı´teˇ jsou • DTE (Data Terminal Equipment) – koncove´ stanice, tedy zarˇ´ızenı´, ktera´ jsou zdrojem nebo cı´lem ra´mcu˚, typicky pocˇ´ıtacˇe, servery,
P
• DCE (Data Communication Equipment) – mezilehla´ sı´t’ova´ zarˇ´ızenı´, ktera´ prˇijı´majı´ ra´mce a odesı´lajı´ je da´l, mohou by´t samostatna´ zarˇ´ızenı´ (router, switch apod.) nebo komunikacˇnı´ rozhranı´ (sı´t’ova´ karta, modem apod.). V kabela´zˇi pouzˇ´ıva´me kroucenou dvojlinku stı´neˇnou (STP – shielded) nebo nestı´neˇnou (UTP – unshielded), a nebo opticke´ kabely. Existuje specifikace pro twin-ax kabel. Drˇ´ıve se pouzˇ´ıval koaxia´lnı´ kabel. Dnes je nejbeˇzˇneˇjsˇ´ı UTP a optika. Topologie a struktura
Celkova´ struktura sı´teˇ je kombinace trˇ´ı prvku˚:
1. Point-to-Point – spojuje dveˇ zarˇ´ızenı´ (DTE-DTE, DTE-DCE nebo DCE-DCE),
P
2. sbeˇrnice – tento prvek se dnes fyzicky nepouzˇ´ıva´, drˇ´ıve na koaxia´lech; de´lka segmentu sbeˇrnice max. 500 m (tlusty´ koax), maxima´lneˇ 100 zarˇ´ızenı´, segmenty lze propojit opakovacˇi, mezi dveˇma DTE musı´ existovat jedina´ cesta, max. pocˇet zarˇ´ızenı´ v sı´ti 1024, 3. hveˇzda – zhruba od prvnı´ poloviny 90. let, struktura slozˇena´ z Point-to-Point segmentu˚ DTEDCE, DCE je HUB nebo switch (spı´sˇe switch, jednotlive´ komunikace jsou oddeˇleny) Cˇasem dosˇlo ke zmeˇna´m ve fyzicke´ topologii. U 10Mb Ethernetu se pouzˇ´ıvala jako fyzicka´ topologie sbeˇrnice, dnes se beˇzˇneˇ setka´va´me s hveˇzdou nebo stromovou strukturou. Logicka´ topologie (tj. popis zpu˚sobu chova´nı´ sı´teˇ, sˇ´ırˇenı´ signa´lu) vsˇak sta´le zu˚sta´va´ sbeˇrnicova´. Postupne´ zmeˇny – rozdeˇlenı´ fyzicke´ vrstvy: u 10Base-T byla fyzicka´ vrstva (PHY) rozdeˇlena na dveˇ podvrstvy (podobneˇ jako drˇ´ıve linkova´), ve specifikaci se mluvı´ spı´sˇe o rozhranı´ch k hornı´ vrstveˇ a vneˇ prˇipojene´mu kabelu cˇi konektoru, nezˇ o podvrstva´ch): • Physical Medium Independent s rozhranı´m MII (Medium Independent Interface) – neza´visla´ na prˇenosove´m me´diu, spolu s linkovou vrstvou je realizova´na na sı´t’ove´ karteˇ (bez konektoru˚), od Gigabit Ethernetu je GMII
P
ZA´KLADNI´ POJMY
2.1
41
• Physical Medium Dependent s rozhranı´m MDI (Medium Dependent Interface) – za´visla´ na me´diu, implementuje vsˇe souvisejı´cı´, tedy ko´dova´nı´ bitu˚, elektricke´ parametry signa´lu˚ atd., realizova´na vneˇjsˇ´ım rozhranı´m sı´t’ove´ karty
2.1.3
Linkova´ vrstva
Ethernet implementuje linkovou (zcˇa´sti) a fyzickou vrstvu modelu. Linkova´ vrstva je rozdeˇlena na podvrstvy • LLC – na DTE • MAC – na DTE i DCE, definova´na prˇ´ımo standardem 802.3, MAC dvou komunikujı´ch zarˇ´ızenı´ musejı´ minima´lneˇ podporovat tute´zˇ prˇenosovou rychlost. Na DCE je podvrstva LLC nahrazena prˇemosteˇnı´m (most umı´ spojovat i sı´teˇ s ru˚zny´mi protokoly, naprˇ´ıklad Ethernet a Token Ring). EtherType V neˇktery´ch typech ra´mcu˚ na LLC se pouzˇ´ıva´ specia´lnı´ identifika´tor EtherType (navzdory tomuto na´zvu zdaleka nesouvisı´ jen s Ethernetem). Tento identifika´tor uda´va´ typ protokolu vysˇsˇ´ı vrstvy pro data zapouzdrˇena´ v LLC, rˇ´ıka´ na´m tedy, „co je uvnitrˇ“. Pole, ktere´ je v urcˇity´ch typech ra´mcu˚ pouzˇ´ıva´no pro ulozˇenı´ EtherType, se v jiny´ch typech ra´mcu˚ pouzˇ´ıva´ pro ulozˇenı´ de´lky paketu (prˇicˇemzˇ podle prˇedchozı´ch polı´ to nenı´ mozˇne´ odlisˇit), proto je du˚lezˇite´, aby bylo mozˇne´ urcˇit, zda v tom poli ma´me hledat EtherType nebo de´lku ra´mce. De´lka ra´mce je vzˇdy mensˇ´ı nezˇ 0×05DC (1500)), proto je EtherType vzˇdy ≥ 0×0600, decima´lneˇ 1536. Konstant pro EtherType je hodneˇ, neˇktere´ nejdu˚lezˇiteˇjsˇ´ı jsou na´sledujı´cı´:
• • • •
0×8870: jumbo frames 0×8100: VLAN ra´mce podle 802.1Q 0×0800: IPv4, 0×86DD: IPv6 0×0806: ARP, 0×0835: RARP
Ra´mce na vrstveˇ L2
• • • •
0×08137, 0×08138: IPX 0×8847: MPLS unicast 0×8914: FCoE Initialization Protocol 0×814C: SNMP
mohou by´t teˇchto typu˚:
• LLC ra´mec pouze podle IEEE 802.2 – v Ethernetu se obvykle nepouzˇ´ıva´ • LLC s rozsˇ´ırˇenı´m SNAP – zapouzdrˇuje se do MAC ra´mce • ra´mec Ethernet II – implementuje celou linkovou vrstvu, nejbeˇzˇneˇjsˇ´ı Nejdrˇ´ıv se podı´va´me, jak vypada´ LLC ra´mec: 1 oktet
1 oktet
1 nebo 2 oktety
N oktetu˚
DSAP prvnı´ bit I/G
SSAP prvnı´ bit C/R
rˇ´ıdicı´ pole
data
Tabulka 2.1: Struktura LLC ra´mce Jednotliva´ pole majı´ tento vy´znam: • SSAP, DSAP (po 1 oktetu) – prˇ´ıstupove´ body (SAP) na cı´love´m (DSAP) a zdrojove´m (SSAP) zarˇ´ızenı´, ktere´ zabı´rajı´ 7 bitu˚ z kazˇde´ho oktetu; zby´vajı´cı´ bit v kazˇde´m oktetu oznacˇuje:
P
2.1
ZA´KLADNI´ POJMY
42
– u cı´love´ho u´daje I/G bit (individual/group) urcˇujı´cı´, zda jde o skupinovou adresu SAP, – u zdrojove´ho u´daje C/R bit (command/response) urcˇujı´cı´ typ paketu (prˇ´ıkaz nebo odpoveˇd’), Prˇ´ıklady DSAP a SSAP: – – – –
0×42: IEEE 802.1 Bridge Spanning Tree Protocol 0×98: ARP 0×E0: Novell Netware 0×FF: Global DSAP
• rˇ´ıdicı´ pole (1 nebo 2 oktety) – urcˇuje typ ra´mce z hlediska sluzˇby, porˇadove´ cˇ´ıslo apod., • data z vysˇsˇ´ı vrstvy, ktera´ jsou v tomto ra´mci zapouzdrˇena. Na´sleduje druhy´ typ ra´mce – LLC s rozsˇ´ırˇenı´m SNAP (SubNetwork Access Protocol). Ra´mec vypada´ takto: 1 oktet
1 oktet
1 oktet
3 oktety
2 oktety
N oktetu˚
DSAP = 0xAA
SSAP = 0xAA
rˇ´ıdicı´ pole = 0x03
OUI
protokol
data
Tabulka 2.2: Struktura SNAP ra´mce SNAP ra´mec prˇirˇazuje pu˚vodnı´m polı´m LLC konstantnı´ hodnoty (0×AA nebo 0×AB). Z toho vyply´va´, zˇe pokud hlavicˇka zacˇ´ına´ AAAA03, jde o SNAP paket. Co se ty´cˇe pole OUI – pokud je nulove´, je v dalsˇ´ım poli hodnota EtherType (mı´sto SAP); jinak je zde ko´d organizace, dalsˇ´ı pole urcˇuje interneˇ tato organizace. Trˇetı´ (nejpouzˇ´ıvaneˇjsˇ´ı) typ ra´mce rozpozna´vane´ho na podvrstveˇ LLC je Ethernet II. 7
1
6
6
2
46–1500
4
PRE
SFD
DA
SA
Length
Data+Pad
FCS
Tabulka 2.3: Struktura ra´mce Ethernet II Jednotliva´ pole majı´ tento vy´znam: • PRE (Preambule, 7 B) – posloupnost strˇ´ıdajı´cı´ch se jednicˇek a nul, ktera´ informuje prˇijı´majı´cı´ stanici, zˇe ma´ ocˇeka´vat ra´mec, jde o synchronizacˇnı´ informaci • SFD (Start-of-frame delimiter, take´ SOF, 1 B) – take´ sekvence strˇ´ıdajı´cı´ch se jednicˇek a nul, ale koncˇ´ı dveˇma jednicˇkami, u´kolem je oddeˇlit na´sledujı´cı´ cˇa´st hlavicˇky • DA (Destination address, 6 B) – urcˇuje, kdo ma´ ra´mec obdrzˇet (MAC adresa); mu˚zˇe by´t i skupinova´ nebo broadcast MAC (zna´me z prˇedchozı´ kapitoly) • SA (Source address, 6 B) – adresa odesı´lajı´cı´ stanice, je vzˇdy unicast • Length/Type (2 B) – pokud jde o SNAP, jde o de´lku vnorˇeny´ch dat – vzˇdy je ≤ 1500, jinak EtherType (to je nejobvyklejsˇ´ı); pak se de´lka pozna´ podle pozice zacˇa´tku dalsˇ´ıho ra´mce (mezera mezi ra´mci je 12 oktetu˚, FCS 4 oktety)
PRˇENOSOVE´ TECHNIKY
2.2
43
• data – de´lka v rozmezi 46–1500 B, spodnı´ hranice je nutna´ pro detekci kolizı´ • datova´ vy´plnˇ (Pad) – pokud de´lka dat je mensˇ´ı nezˇ 46, je nutne´ je doplnit touto vy´plnı´ (do ulozˇene´ de´lky dat se nepocˇ´ıta´), rozhranı´ mezi daty a datovou vy´plnı´ pozna´me podle hodnoty Length (de´lky dat) • FCS (Frame check sequence, 4 B) – do paty ra´mce (traileru) se prˇida´va´ kontrolnı´ soucˇet, generuje se z dat od adresy prˇ´ıjemce (DA) po data vcˇetneˇ (i prˇ´ıpadnou vy´plnˇ), slouzˇ´ı prˇ´ıjemci ke zjisˇteˇnı´ posˇkozenı´ ra´mce
2.2 2.2.1
Prˇenosove´ techniky Zajisˇteˇnı´ prˇenosu pro polovicˇnı´ duplex
Prˇi polovicˇnı´m duplexu mu˚zˇe vysı´lat vzˇdy jen jedna z komunikujı´cı´ch stran. Pro tento typ prˇenosu se pouzˇ´ıva´ prˇenosova´ metoda CSMA/CD, cozˇ znamena´: • CS (Carrier Sense) – stanice neusta´le naslouchajı´ na prˇenosove´m me´diu, i beˇhem vysı´la´nı´,
P
• MA (Multiple Access) – stanice mohou kdykoliv vysı´lat, kdyzˇ nasloucha´nı´m zjistı´, zˇe nikdo nevysı´la´, • CD (Collision Detect) – pokud vı´ce stanic vysı´la´ v te´meˇrˇ stejne´m okamzˇiku, docha´zı´ k posˇkozenı´ signa´lu – kolizi, stanice musı´ by´t schopny kolizi detekovat a osˇetrˇit. V prˇ´ıpadeˇ kolize musı´ prˇestat vysı´lat (ne okamzˇiteˇ!!!, musı´ da´t ostatnı´m vysı´lajı´cı´m uzlu˚m sˇanci, aby rozpoznaly kolizi), vycˇkajı´ na´hodneˇ dlouhy´ okamzˇik urcˇeny´ backoff algoritmem. Backoff algoritmus. Tento algoritmus urcˇuje, jak dlouho ma´ vysı´lacı´ stanice cˇekat s prˇenosem, kdyzˇ zjistı´ kolizi. Po prvnı´m zjisˇteˇnı´ kolize: • • • •
P
vysˇle „Jam“ signa´l pro zrusˇenı´ odesı´la´nı´ vyslane´ho ra´mce cˇeka´ po dobu 0 . . . 51, 2 µs, pak se znovu pokusı´ o prˇenos kdyzˇ znovu prˇenos selzˇe, cˇeka´ po dobu 2 · 0 . . . 51, 2 µs, pak se znovu pokusı´ o prˇenos pokud dojde k dalsˇ´ım selha´nı´m, cˇeka´ po dobu K · 0 . . . 51, 2 µs, kde K je cˇ´ıslo z intervalu 0 . . . 2n − 1
Existujı´ i jine´, slozˇiteˇjsˇ´ı verze backoff algoritmu. Nejhorsˇ´ı prˇ´ıpad nastane, pokud najednou vysı´lajı´ dveˇ nejvzda´leneˇjsˇ´ı stanice (signa´l te´ druhe´ vysı´lacı´ stanice dorazı´ azˇ po dlouhe´ dobeˇ a nenı´ vcˇas detekova´n). Koliznı´ okno (Collision Window, Slot Time) je odvozeno od doby, po kterou se sˇ´ırˇ´ı signa´l mezi dveˇma nejvzda´leneˇjsˇ´ımi stanicemi, po tuto dobu musı´ odesı´lajı´cı´ stanice naslouchat pro detekci kolize. Vliv spodnı´ hranice de´lky ra´mce: • vysˇsˇ´ı ⇒ veˇtsˇ´ı koliznı´ okno a veˇtsˇ´ı koliznı´ dome´na • nizˇsˇ´ı ⇒ mensˇ´ı koliznı´ okno a mensˇ´ı koliznı´ dome´na
P
2.2
PRˇENOSOVE´ TECHNIKY
44
Nastavenı´ koliznı´ dome´ny a de´lky paketu za´visı´ na rychlosti sˇ´ırˇenı´ signa´lu po sı´ti, nastavenı´ spodnı´ hranice de´lky ra´mce a velikosti koliznı´ho okna.
$
• u 10Mb Ethernetu stacˇilo najı´t vhodny´ kompromis, stanovena polovina cˇasu slot time 51, 2 µs, min. de´lka ra´mce 64 B, • u 100Mb Ethernetu bylo nutne´ zmensˇit pru˚meˇr koliznı´ dome´ny prˇiblizˇneˇ 10× (na me´neˇ nezˇ 200 m) prˇi zachova´nı´ minima´lnı´ de´lky ra´mce a koliznı´ho okna. PRE
SFD
DA
SA
Length
Data+Pad
FCS
Ext
1000Base-X: 416 oktetu˚ 1000Base-T: 520 oktetu˚
Tabulka 2.4: MAC ra´mec pro Gigabit Ethernet Pro Gigabit Ethernet (a rychlejsˇ´ı) uzˇ toto rˇesˇenı´ nenı´ pru˚chodne´ pouzˇ´ıva´ se jine´ rˇesˇenı´: • zveˇtsˇ´ı se minima´lnı´ de´lka ra´mce (na 512 B), • aby nebylo nutne´ zasa´hnout do struktury ra´mce, zveˇtsˇenı´ se provede prˇida´nı´m nedatove´ prˇ´ıpony na konec MAC ra´mce (tj. za kontrolnı´ soucˇet), tato prˇ´ıpona ma´ promeˇnnou de´lku a prˇipojuje se pouze k ra´mcu˚m kratsˇ´ım nezˇ je stanovene´ minimum, v tabulce 2.4 je oznacˇena jako Ext. Operace prˇida´nı´/odebra´nı´ prˇ´ıpony se prova´dı´ na MAC vrstveˇ. Parametr
10 Mb
100 Mb
1000 Mb
Min. de´lka ra´mce
64 B
64 B
Koliznı´ dome´na (DTE-DTE) Koliznı´ dome´na pro DCE Max. pocˇet DCE na cesteˇ
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: Porovna´nı´ parametru˚ souvisejı´cı´ch s ra´mci pro 10Mb, Fast a Gigabit Ethernet Burst mode, shlukovy´ mo´d je povolen pouze u gigabitovy´ch prˇenosu˚ (1000Mb Ethernetu a vy´sˇe). Pokud stanice vysı´la´ vı´ce ra´mcu˚ za sebou, mu˚zˇe je poslat ve shluku, ktery´ ma´ tuto strukturu: 1. prvnı´ ra´mec splnˇuje vsˇechny vy´sˇe uvedene´ na´lezˇitosti, vcˇetneˇ prˇ´ıpadne´ho prodlouzˇenı´ prˇ´ıponou, 2. na´sleduje IFG (InterFrame Gap) – sekvence bitu˚, ktere´ oddeˇlujı´ ra´mce, 3. dalsˇ´ı ra´mce, vzˇdy oddeˇlene´ IFG intervaly; pokud jsou kratsˇ´ı nezˇ pozˇadovana´ minima´lnı´ de´lka, nenı´ trˇeba je doplnˇovat o prˇ´ıponu. Struktura je patrna´ v tabulce 2.5.
P
PRˇENOSOVE´ TECHNIKY
2.2
MAC ra´mec+Ext
45
IFG
MAC ra´mec
IFG
...
MAC ra´mec
Tabulka 2.6: Burst mode u Gigabit Ethernetu Vlastnosti v Burst modu: • celkova´ de´lka shluku takto posı´lany´ch ra´mcu˚ by nemeˇla prˇekrocˇit 5.4 na´sobek maxima´lnı´ mozˇne´ de´lky ra´mce, • pokud poslednı´ ra´mec zpu˚sobı´ prˇekrocˇenı´ te´to hodnoty, mu˚zˇe by´t jesˇteˇ jeho prˇenos dokoncˇen. Toto rˇesˇenı´ je urcˇeno prˇedevsˇ´ım pro posı´la´nı´ shluku˚ mensˇ´ıch ra´mcu˚, ktere´ ve shlukove´m mo´du nenı´ nutne´ „vycpa´vat“ na minima´lnı´ povolenou de´lku. Dalsˇ´ı vy´hodou je zachova´nı´ vy´hradnı´ho prˇ´ıstupu k me´diu beˇhem vysı´la´nı´.
2.2.2
Zajisˇteˇnı´ prˇenosu pro plny´ duplex
Plny´ duplex (u Point-to-Point spoju˚) je realizova´n zdvojenı´m prˇenosove´ho me´dia – jedno pro kazˇdy´ smeˇr. Protozˇe je jen u Point-to-Point spoju˚, odpadajı´ proble´my s kolizemi (proto se nepouzˇ´ıva´ zˇa´dna´ koliznı´ metoda) a prakticky nenı´ trˇeba naslouchat na me´diu, ra´mce jsou posı´la´ny hned po zkompletova´nı´.
$
Realizace a vlastnosti plne´ho duplexu: • CSMA/CD by dokonce mohla pu˚sobit proble´my (prˇ´ıjem a vysı´la´nı´ za´rovenˇ by povazˇovala za kolizi), proto je nutne´ ji odstranit, • dı´ky neexistenci kolizı´ je dosah jen za´lezˇitostı´ fyzika´lnı´ch vlastnostı´ prˇenosove´ho me´dia, • obvykle funguje neusta´le v burst mo´du, tj. ra´mce jsou postupneˇ odesı´la´ny oddeˇlene´ IFG sekvencemi. ˇ ı´zenı´ toku dat R • Jestlizˇe prˇijı´majı´cı´ uzel je zahlcen ra´mci, musı´ pozˇa´dat vysı´lajı´cı´ uzel o prˇerusˇenı´ posı´la´nı´ ra´mcu˚, • pause frame – je vygenerova´n v MAC vrstveˇ zahlcene´ho uzlu, obsahuje informaci o de´lce intervalu, po ktery´ ma´ vysı´lajı´cı´ stanice prˇestat zası´lat; aby nedosˇlo k omylu, jsou identifikovatelne´ specifickou hodnotou zapisovanou do u´daje o de´lce dat
P
• pokud je zahlcenı´ vyrˇesˇeno drˇ´ıve, mu˚zˇe by´t vygenerova´n pause frame s nulovy´m cˇasovy´m intervalem, ktery´ informuje uzel s pozastaveny´m zası´la´nı´m, zˇe mu˚zˇe zase zacˇ´ıt posı´lat ra´mce.
2.2.3
Zajisˇteˇnı´ prˇijetı´ dat
Zajisˇteˇnı´ prˇijetı´ dat je stejne´ pro polovicˇnı´ i plny´ duplex, rozdı´l je jen v tom, zˇe u plne´ho duplexu musı´ by´t oddeˇleny vyrovna´vacı´ pameˇti pro odesı´la´nı´/prˇ´ıjem. Postup prˇijetı´: 1. kontrola cı´love´ adresy (DA) – zda jde o unicast/broadcast/multicast, a jestli adresa odpovı´da´ adrese te´to stanice (stanice beˇzˇ´ıcı´ v promiskuitnı´m mo´du prˇijı´majı´ vsˇechny ra´mce bez ohledu na adresy)
$
2.2
PRˇENOSOVE´ TECHNIKY
46
= Collision domains
Hub
Switch
Collision domain = Broadcast domain
Broadcast domain
Router
= Collision domains
Switch
Hub
Broadcast domain
Collision domain = Broadcast domain
Obra´zek 2.1: Koliznı´ a broadcastova´ dome´na prˇi pouzˇitı´ rozbocˇovacˇe, prˇepı´nacˇe a smeˇrovacˇe 2. zjisˇteˇnı´ de´lky ra´mce a porovna´nı´ kontrolnı´ho soucˇtu s u´dajem v FCS 3. kontrola u´daje v Length/Type Field – o jaky´ typ ra´mce jde, prˇ´ıpadneˇ de´lka datove´ cˇa´sti ra´mce (LLC ra´mce), kontrola de´lky LLC ra´mce s uvedeny´m u´dajem 4. rozbalenı´ ra´mce, data jsou prˇeda´na na vysˇsˇ´ı (pod)vrstvu
2.2.4
VLAN
VLAN (Virtua´lnı´ LAN) umozˇnˇuje propojit vzda´lene´ LAN segmenty do jedne´ logicke´ (virtua´lnı´) LAN sı´teˇ s (te´meˇrˇ) vsˇemi vlastnostmi a vy´hodami komunikace v LAN. Lze nastavovat prˇenosove´ ´ cˇelem VLAN je zjednodusˇit jak prˇ´ıstup vzda´lene´ stanice k sı´ti, priority u odcha´zejı´cı´ch ra´mcu˚. U tak i administraci sı´teˇ vzhledem k te´to vzda´lene´ stanici prˇi co nejvysˇsˇ´ım zachova´nı´ bezpecˇnosti prˇipojenı´.
P
FYZICKA´ VRSTVA
2.3
47
VLAN ra´mec v Ethernetu ma´ pozmeˇneˇnou strukturu – navı´c se vkla´da´ VLAN hlavicˇka za adresy DA a SA. Struktura VLAN ra´mce: • VLAN type ID (2 B) – urcˇuje, zˇe jde o VLAN ra´mec, ma´ specifickou hodnotu nezameˇnitelnou s hodnotami beˇzˇneˇ povoleny´mi pro u´daj Length/Type, • TAG control (2 B) – hodnota priority (0–7, cˇ´ım vysˇsˇ´ı cˇ´ıslo, tı´m vysˇsˇ´ı priorita) a identifikace VLAN, do ktere´ ra´mec patrˇ´ı. Prˇ´ıchozı´ VLAN ra´mec je v MAC vrstveˇ zpracova´n takto: • DCE (trˇeba switch) odesˇle VLAN ra´mec beze zmeˇny na vsˇechny porty odpovı´dajı´cı´ identifikaci VLAN s ohledem na uvedenou prioritu, • DTE (obvykle cı´l ra´mce) odstranı´ VLAN hlavicˇku a ra´mec zpracuje jako jaky´koliv jiny´. PRE
SFD
DA
SA
VLAN typ
Tag control
Length
Data+Pad
FCS
Ext
VLAN za´hlavı´
Tabulka 2.7: VLAN ethernetovy´ ra´mec
2.3 2.3.1
Fyzicka´ vrstva NIC
NIC (Network Interface Card, sı´t’ova´ karta) je implementace fyzicke´ vrstvy. Vy´robnı´ oznacˇenı´ se skla´da´ ze trˇ´ı cˇa´stı´ odvozeny´ch od konkre´tnı´ch vlastnostı´ fyzicke´ vrstvy:
P
• prˇenosova´ rychlost, • prˇenosova´ metoda (rozlisˇenı´ za´kladnı´ho a prˇekla´dane´ho prˇenosu nebo BaseBand a BroadBand), • prˇenosove´ me´dium, prˇ´ıpadneˇ typ ko´dova´nı´ signa´lu˚. Se znacˇenı´m jsme se jizˇ sezna´mili na zacˇa´tku kapitoly. Naprˇ´ıklad 100Base-T4 (rychlost 100 Mb/s, BaseBand, kroucena´ dvojlinka s prˇenosem na vsˇech 4 pa´rech). Prˇenosova´ metoda je prakticky u vsˇech noveˇjsˇ´ıch specifikacı´ BaseBand (sı´t’ove´ prvky podporujı´cı´ BroadBand se na trhu neprosadily – objevil se pouze 10Broad36). MAU (transceiver) MAU (Medium Attachment Unit) neboli transceiver (zkra´ceno ze slov transmitter/receiver) je prvek na NIC, ktery´ zajisˇt’uje rozpozna´nı´ prˇ´ıtomnosti signa´lu, kolizi (signa´l jam) a vysı´la´nı´/prˇ´ıjem signa´lu. Transceiver by´va´ u neˇktery´ch forem 802.3 externı´, pak se k NIC prˇipojuje AUI kabelem (Attachment Unit Interface).
P
FYZICKA´ VRSTVA
2.3
2.3.2
48
Ko´dova´nı´ signa´lu
Signa´l je beˇhem prˇenosu po prˇenosove´m me´diu do urcˇite´ mı´ry zeslaben a deformova´n z du˚vodu fyzika´lnı´ch vlastnostı´ me´dia a jeho de´lky, sˇumu, prˇeslechu˚, vneˇjsˇ´ıch vlivu˚, horsˇ´ı synchronizace. ˇ esˇenı´: Prˇesto je nutne´, aby cı´lova´ stanice tento signa´l spra´vneˇ prˇecˇetla. R • pouzˇitı´ vhodny´ch dobrˇe rozmı´steˇny´ch zarˇ´ızenı´ IS (dle pojmu˚ ISO – Intermediate System), ktera´ mohou obnovit kvalitu signa´lu (prosteˇ opakovacˇ), • cˇasovacˇ pouzˇity´ prˇi prˇijı´ma´nı´ dat musı´ by´t spra´vneˇ synchronizova´n s pulsy v prˇ´ıchozı´m proudu dat, • pouzˇijı´ se kompenzacˇnı´ hodnoty pro u´pravu signa´lu. Cˇasovacˇ mu˚zˇe ztratit synchronizaci u signa´lu, ktery´ se po dlouhou dobu nemeˇnı´ (trˇeba dlouha´ sekvence nul), proto je nutne´ zajistit, aby k tomu nedocha´zelo. Jak vyrˇesˇit proble´m se synchronizacı´ cˇasovacˇe a stanovenı´ kompenzacˇnı´ch hodnot: • obojı´ vyrˇesˇ´ı vhodna´ volba ko´dova´nı´ dat, • kazˇdy´ bit je nahrazen urcˇitou sekvencı´ bitu˚, u´cˇelem je zajistit, aby se dostatecˇneˇ cˇasto „strˇ´ıdaly“ hodnoty 0 a 1, • rˇeteˇzec musı´ by´t zpeˇtneˇ deko´dovatelny´, • pro kazˇdou prˇenosovou cestu je charakteristicky´ urcˇity´ idea´lnı´ pru˚beˇh signa´lu (veˇtsˇinou neˇco jako sinusovka), proto je u´cˇelem ko´dova´nı´ prˇiblı´zˇit skutecˇny´ pru˚beˇh signa´lu tomuto idea´lu se zachova´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
Obra´zek 2.2: Ko´dova´nı´ Manchester pro oktet (10110010)2 Ko´dova´nı´ Manchester je velmi jednoduche´. Spocˇ´ıva´ v zako´dova´nı´ bitu˚ do smeˇru kmitu signa´lu – 0 je ko´dova´na jako prˇechod shora dolu˚, 1 je ko´dova´na jako prˇechod zdola nahoru (viz obra´zek 2.2). Vy´sledek mu˚zˇeme reprezentovat pru˚beˇhem signa´lu a nebo opeˇt jako sekvenci jednicˇek a nul s tı´m, zˇe prˇechod shora dolu˚ zapı´sˇeme jako 10 a opacˇny´ prˇechod jako 01. Naprˇ´ıklad sekvence bitu˚ 10111000 je zako´dova´na na 0110010101101010. Jak vidı´me, stejne´ symboly vedle sebe zı´ska´me pouze na teˇch mı´stech, kde se v pu˚vodnı´ sekvenci meˇnily hodnoty bitu˚, a to nejvy´sˇe dva stejne´ symboly. To je vy´hodou ko´dova´nı´ Manchester, nevy´hodou je navy´sˇenı´ de´lky posı´lany´ch dat (de´lka se oproti pu˚vodnı´m zdvojna´sobı´). U 10Base-T to stacˇ´ı, ale u vysˇsˇ´ıch rychlostı´ jsou dalsˇ´ı techniky: 1. data scrambling (promı´cha´nı´ dat) – hodnoty bitu˚ se podle klı´cˇe zameˇnı´ (na opacˇnou hodnotu); u´cˇelem je uve´st data do stavu, kdy se jednodusˇeji synchronizuje cˇasovacˇ a hodnoty 0 a 1 se strˇ´ıdajı´ dostatecˇneˇ cˇasto
2.3
FYZICKA´ VRSTVA
49
2. rozsˇirˇova´nı´ oblasti ko´du – zvla´sˇt’se ko´dujı´ data × rˇ´ıdicı´ signa´ly
3. samoopravitelny´ ko´d – prˇidajı´ se redundantnı´ oblasti s vhodnou strˇ´ıdavou strukturou (u Gigabit Ethernetu) Ko´dova´nı´ 4B/5B Z kazˇde´ cˇtverˇice bitu˚ se vytvorˇ´ı 5 bitu˚ tak, aby v cele´ sekvenci bylo co nejvı´ce jednicˇek (nejme´neˇ dveˇ na peˇtici), na zacˇa´tku peˇtice nejvy´sˇe jedna 0, na konci nejvy´sˇe dveˇ 0. Ko´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 ko´du˚ pro 4B/5B Sekvenci 10111000, kterou jsme v ko´dova´nı´ Manchester zako´dovali do 16 znaku˚, zde zpracujeme na 1011110010 o de´lce 10 znaku˚. Ko´dova´nı´ MLT-3 pouzˇ´ıva´ trˇi u´rovneˇ napeˇtı´ (prˇedchozı´ ko´dova´nı´ pouzˇ´ıvala jen dveˇ u´rovneˇ), a to -, za´kladna, +. Zmeˇna napeˇtı´ probeˇhne pouze na signa´l 1, a to na „sinusovce“, naprˇ´ıklad pro sekvenci jednicˇek by bylo 0, 1, 0, -1, 0, 1, 0, -1, atd. Toto ko´dova´nı´ se obvykle kombinuje s neˇktery´m jiny´m, naprˇ´ıklad signa´l pro MLT-3 mu˚zˇe by´t prˇedzpracova´n ko´dova´nı´m 4B/5B. Oproti Manchestru ma´ signa´l jen cˇtvrtinovou frekvenci, proto me´neˇ vyzarˇuje, generuje mnohem me´neˇ rusˇenı´ do okolı´. Ko´dova´nı´ 8B/6T znamena´, zˇe 8 bitu˚ pu˚vodnı´ sekvence je zako´dova´no 6 zmeˇnami signa´lu (terna´rnı´ symboly, tedy stavy -,0,+). Pouzˇ´ıva´ se na kroucene´ dvojlince kategorie 3 se 4 pa´ry, data se rozdeˇlı´ do 3 pa´ru˚, prˇena´sˇejı´ se vzˇdy jednı´m smeˇrem. Cˇtvrty´ pa´r je pouzˇ´ıva´n pro indikaci kolizı´. Ko´dova´nı´ NRZ (Non Return to Zero) nenı´ 0 (za´kladna), naprˇ´ıklad +1,-1.
pouzˇ´ıva´ pro reprezentaci signa´lu dveˇ u´rovneˇ, z nich zˇa´dna´
Existuje vı´ce variant – unipola´rnı´ (1 je prˇedstavova´na kladny´m napeˇtı´m, 0 take´ kladny´m, ale mensˇ´ım), bipola´rnı´m (0 kladne´, 1 za´porne´), NRZI, atd. Ko´dova´nı´ NRZI (Non Return to Zero – Inverted) znamena´, zˇe 1 vyvola´ zmeˇnu signa´lu, 0 ne. Je to obdoba MLT-3, ale jen na dvou u´rovnı´ch (kladne´ a za´porne´)
2.3.3
Fyzicka´ vrstva v ISO/OSI modelu
Fyzicka´ vrstva se take´ deˇlı´ na podvrstvy, a to za´visle´/neza´visle´ na me´diu s vlastnı´mi komunikacˇnı´mi rozhranı´mi (interface).
P
50
Podvrstvy neza´visle´ na me´diu: • vyrovna´vacı´ podvrstva (reconciliation),
Reconciliation
• MII (10Mb a 100Mb), GMII (Gb) nebo XGMII (10Gb) – zvla´sˇt’ odesı´lacı´ a prˇijı´macı´ datove´ cesty o sˇ´ırˇce 1 bit pro 10Mb (bitserial), 4 bity pro 100Mb (nibble-serial) nebo 1 B (byte-serial).
MII
PCS
Zajisˇt’ujı´ logicke´ spojenı´ mezi MAC a ru˚zny´mi sadami podvrstev za´visly´ch na me´diu.
PMA
Podvrstvy za´visle´ na me´diu: • PCS (physical coding sublayer) – ko´dova´nı´, multiplexing, synchronizace odchozı´ch a opacˇneˇ u prˇ´ıchozı´ch dat,
Auto-negotiation
• PMA (physical medium attachment) – vysı´la´nı´ a prˇijı´ma´nı´ signa´lu, mechanismus zotavenı´ cˇasovacˇe (zajisˇteˇnı´ sesynchronizova´nı´ cˇasovacˇe na zacˇa´tku proudu dat),
MDI
Nezávislé n. m.
STANDARDY PRO FYZICKOU VRSTVU
Závislé na médiu
2.4
• Auto-negotiation (vyjedna´vacı´ podvrstva) – tyto podvrstvy na zacˇa´tku prˇenosu dohodnou konkre´tnı´ vlastnosti spojenı´ vyhovujı´cı´ obeˇma NIC, • MDI (medium-dependent interface) – ke konektoru kabelu. Fyzicka´ vrstva je zcela prˇedefinova´na v 10G Ethernetu.
2.4 2.4.1
Standardy pro fyzickou vrstvu 10Mb Ethernet
Ethernet s rychlostı´ 10Mb/s v soucˇasne´ dobeˇ uzˇ te´meˇrˇ nikde nenajdeme. Nejstarsˇ´ı standardy jsou 10Base-5 (tlusty´/thick Ethernet) a 10Base-2 (tenky´/thin Ethernet). V obou prˇ´ıpadech se pouzˇ´ıva´ koaxia´l (tlusty´ nebo tenky´), topologie je sbeˇrnicova´. Stanice se ke sbeˇrnici prˇipojujı´ pomocı´ cˇlenu nazy´vane´ho T-kus („te´cˇko“) podle sve´ho tvaru. Sbeˇrnice musı´ by´t na obou koncı´ch ukoncˇena termina´torem, aby nedocha´zelo k odrazu˚m a rusˇenı´ signa´lu. Tyto standardy se dnes jizˇ nepouzˇ´ıvajı´. 10Base-T propojuje uzly sı´teˇ nestı´neˇnou dvojlinkou (UTP) kategorie 3 nebo 5. Tento kabel ma´ 4 pa´ry vodicˇu˚, z nichzˇ se pro prˇenos pouzˇ´ıvajı´ pouze 2. Konektory jsou dnes jizˇ beˇzˇneˇ zna´me´ 8pinove´ RJ-45. Fyzicka´ topologie jizˇ nenı´ sbeˇrnice, ale hveˇzda nebo slozˇiteˇjsˇ´ı. V centru hveˇzdy je rozbocˇovacˇ nebo jiny´ mezilehly´ prvek (DCE), k neˇmu jsou prˇipojeny jednotlive´ DTE spojenı´m point-to-point. Polovicˇnı´ i plny´ duplex je implementova´n tak, zˇe ze dvou pouzˇ´ıvany´ch pa´ru˚ vodicˇu˚ v kabelu kazˇdy´ funguje simplexneˇ (v jednom smeˇru). Jako prvnı´ ethernetovy´ standard podporuje oveˇrˇenı´ provozuschopnosti spojenı´ – prˇi zapnutı´ NIC (podvrstva PMA) odesˇle impuls, ktery´m sdeˇlı´, zˇe je na „prˇ´ıjmu“ a ocˇeka´va´ odpoveˇd’, pokud nedostane, opakuje kazˇdy´ch 16 ms. Ko´duje se ko´dova´nı´m 4B/5B kombinovany´m s Manchesterem.
P
2.4
STANDARDY PRO FYZICKOU VRSTVU
51
10Base-F je standard pro opticky´ kabel s topologiı´ hveˇzda. Existuje neˇkolik specifikacı´ vcˇetneˇ jedne´ prˇ´ımo urcˇene´ pro pa´terˇnı´ rozvody. 10Broad-36 je standard pro pouzˇitı´ koaxia´lnı´ho kabelu s impedancı´ 75 Ω, topologie sbeˇrnice. K dispozici jsou 3 kana´ly po 6 MHz pro vysı´la´nı´ a 3 kana´ly po 6 MHz pro prˇ´ıjem, tedy celkem 36 MHz. Vy´hodou tohoto rˇesˇenı´ je mozˇnost vytva´rˇenı´ velmi dlouhy´ch segmentu˚, azˇ 1800 m. Prˇesto se 10Broad-36 nerozsˇ´ırˇil, ale stal se za´kladem pro pozdeˇjsˇ´ı provozova´nı´ Ethernetu v sı´tı´ch kabelovy´ch televizı´.
2.4.2
P P
Fast Ethernet
Fast Ethernet (100Mb/s) je standardizova´n jako IEEE 802.3u. Typicka´ fyzicka´ topologie je jizˇ stabilneˇ hveˇzda (prˇ´ıpadneˇ pozmeˇneˇna´ do stromu). Transceivery mohou by´t externı´, prˇipojene´ k NIC drop kabelem (MII kabelem, AUI), max. 0,5 m.
Transceiver
Attachment Unit Interface
drop cable Transceiver
Attachment Unit Interface
Obra´zek 2.3: Internı´ a externı´ transceiver Pro Fast Ethernet rozlisˇujeme dveˇ trˇ´ıdy opakovacˇu˚: • trˇ´ıda I (translational repeater) – kromeˇ opakova´nı´ a prˇ´ıpadne´ho zesı´lenı´ signa´lu prova´dı´ take´ prˇeklad (naprˇ´ıklad mezi FX a TX), mu˚zˇe propojovat dva kabely ru˚zne´ho typu, du˚sledkem je veˇtsˇ´ı zpozˇdeˇnı´ signa´lu, proto mu˚zˇe by´t pouze jediny´ v koliznı´ dome´neˇ, • trˇ´ıda II (transparent repeater) – neprova´dı´ prˇeklad, propojuje pouze dva kabely stejne´ho typu, mensˇ´ı zpozˇdeˇnı´, proto mohou by´t i dva v jedne´ koliznı´ dome´neˇ. U Fast Ethernetu se objevuje skutecˇna´ technologie auto-negotiation (automaticka´ detekce a vyjedna´nı´ vlastnostı´ spojenı´), ale zatı´m jen detekuje rychlost na me´diu. Take´ se objevily NIC pro 10/100 Mb, ktere´ automaticky rozpoznajı´ rychlost na me´diu a podle toho pracujı´ v 10Mb nebo 100Mb rezˇimu. Da´le se budeme veˇnovat typu˚m rozhranı´ pro Fast Ethernet. 100Base-TX vyuzˇ´ıva´ UTP kabel (nestı´neˇnou kroucenou dvojlinku) kategorie 5 (nebo vy´jimecˇneˇ STP kabel kategorie 1). De´lka segmentu bez opakovacˇu˚ je do 100 m. Kabely kat. 5 obsahujı´ 2 nebo 4 datove´ pa´ry, cozˇ je dostacˇujı´cı´ (vyzˇaduje se pro kazˇdy´ smeˇr jeden pa´r). Ko´duje se 4B/5B kombinovaneˇ s MLT-3. Na 100Base-TX lze celkem bez proble´mu˚ prˇejı´t ze starsˇ´ıho 10Base-T. Kabela´zˇ (pokud je alesponˇ typu 5) mu˚zˇe zu˚stat. Jen je trˇeba vymeˇnit NIC a mezilehle´ prvky sı´teˇ (jako jsou opakovacˇe), cozˇ mu˚zˇe probı´hat postupneˇ, pokud se pouzˇ´ıvajı´ NIC 10/100 s funkcı´ auto-negotiation (tj. prvky podporujı´cı´ oba standardy). 100BASE-T4 vyuzˇ´ıva´ UTP, kde se pro prˇenos dat pouzˇ´ıvajı´ vsˇechny cˇtyrˇi pa´ry, kategorie 3 nebo 4, lze pouzˇ´ıt i kategorii 5, pokud je kabel kvalitnı´ (tj. pokud ma´ vsˇechny 4 pa´ry).
P J
2.4
STANDARDY PRO FYZICKOU VRSTVU
52
Dva pa´ry jedou na half-duplexu (polovicˇnı´m duplexu), v obou smeˇrech, ale v jednom okamzˇiku jen jeden smeˇr, dalsˇ´ı dva pa´ry jsou simplexnı´, tedy jen pro jeden urcˇeny´ smeˇr. Poloduplexnı´ pa´ry a jeden simplexnı´ jsou pro data, dalsˇ´ı simplexnı´ je pro potrˇeby CSMA/CD. Plny´ duplex nenı´ podporova´n. Ko´duje se 8B/6T, specia´lnı´ skupiny 6T jsou urcˇeny pro IDLE (indikuje „ticho“ na lince) a dalsˇ´ı (zacˇa´tek a konec ra´mce apod.). Maxima´lnı´ de´lka segmentu je 100 m. Pozor – levneˇjsˇ´ı kabely kategorie 5 majı´ jen dva datove´ pa´ry, tedy je nelze pro tento typ Fast Ethernetu pouzˇ´ıt. Pozna´me na prvnı´ pohled, stacˇ´ı se podı´vat na konektor. 100BASE-T2 je urcˇena pro starsˇ´ı sı´teˇ na kroucene´ dvojlince kategorie 3 pu˚vodneˇ provozovane´ jako 100Base-T4, mu˚zˇe by´t i kabel kategorie 4 nebo 5. Dva simplexnı´ pa´ry jsou nahrazeny jednı´m plneˇ duplexnı´m spojenı´m, tj. funguje take´ plny´ duplex, oba pu˚vodneˇ poloduplexnı´ pa´ry mohou take´ fungovat plneˇ duplexneˇ. Je tedy podporova´n poloduplexnı´ i plneˇ duplexnı´ provoz. Na Point-to-Point spojenı´ je vzˇdy jedna NIC jako master, druha´ slave; kdo je kdo, se rozhoduje prˇi inicializaci komunikace, master urcˇuje cˇasova´nı´ synchronizace. Pouzˇ´ıva´ se odlisˇne´ ko´dova´nı´ s peˇti u´rovneˇmi napeˇtı´ PAM5 (Five-level Pulse Amplitude Modulation, podobneˇ jako MLT-3, ale peˇt u´rovnı´: -1,-0.5,0,0.5,1) v kombinaci se scramblingem. 100Base-FX je standard pro opticky´ kabel (fiber optic). Pouzˇ´ıvajı´ se dva opticke´ kabely (mnohavidove´ nebo jednovidove´), kazˇdy´ pro jeden smeˇr komunikace. De´lka segmentu za´visı´ na typu opticke´ho kabelu a typu duplexu – 412 m (mnohavidovy´ kabel, half duplex) nebo 10 000 m (jednovidovy´ kabel, plny´ duplex). Pouzˇ´ıva´ se ko´dova´nı´ NRZI prˇedzpracovane´ ko´dova´nı´m 4B/5B. Nevy´hodou rˇesˇenı´ byla ve sve´ dobeˇ prˇedevsˇ´ım cena. 100Base-X vyuzˇ´ıva´ UTP kabel kategorie 5, ve ktere´m pouzˇ´ıva´ pouze dva pa´ry, anebo opticky´ kabel (dva kabely, jeden pro kazˇdy´ smeˇr). Ko´dova´nı´ je 4B/5B. Jedna´ se o kombinaci obou prˇedchozı´ch standardu˚, karty podle 100Base-X podporujı´ oba typy kabela´zˇe (jsou na nich oba typy konektoru˚).
konektor RJ-45 UTP kategorie 5, dva datove´ pa´ry
Protokoly vysˇsˇ´ı vrstvy MAC klient MAC Reconciliation MII PCS PMA TP-PMD Fiber-PMD MDI MDI 6 6 ? (100Base-TX)
? (100Base-FX)
100 Mb/s neza´visla´ na me´diu 100Base-X konektor SC Duplex opticky´ kabel se dveˇma vla´kny
Obra´zek 2.4: Sche´ma pro 100Base-X
L
2.4
STANDARDY PRO FYZICKOU VRSTVU
2.4.3
53
Gigabit Ethernet
Za´kladnı´ specifikace pro gigabitovy´ Ethernet jsou • 1 000Base-T (802.3ab) – pro kroucenou dvojlinku UTP kategorie 5e • 1 000Base-X (802.3z) – pro opticke´ kabely varianty SX a LX, pro STP varianta CX podvrstvy MAC a Reconciliation pro Gigabit Ethernet podvrstvy neza´visle´ na me´diu pro Gigabit Ethernet podvrstvy PCS, PMA a Auto-negociace pro 1000Base-X CX PMD MDI 6 ? STP (2 pa´ry)
LX PMD MDI 6 ? opticky´ single/multi-mode (oba smeˇry)
SX PMD MDI 6 ? opticky´ multimode (oba smeˇry)
podvrstvy PCS, PMA a Auto-negociace pro 1000Base-T 1000Base-T PMD MDI 6666 ???? UTP (4 pa´ry min. kat. 5)
Obra´zek 2.5: Souhrnne´ sche´ma pro Gigabit Ethernet Je mozˇne´ pouzˇ´ıt tyto prvky sı´teˇ: • opakovacˇe (prˇ´ıp. jednoduche´ rozbocˇovacˇe) – pro polovicˇnı´ duplex, max. 100 m na kazˇde´ straneˇ opakovacˇe u UTP,
P
• rozbocˇovacˇe s bufferem – pro plny´ duplex, majı´ vyrovna´vacı´ pameˇt’, prˇijı´majı´ ra´mce z vı´ce vstupnı´ch portu˚ a ukla´dajı´ do pameˇti, prˇi zahlcenı´ podle IEEE 802.3x pouzˇijı´ protokol Xon/X-off a zazˇa´dajı´ uzly o prˇerusˇenı´ vysı´la´nı´, nezˇ pameˇt’vypra´zdnı´, • prˇepı´nacˇe – prˇepı´nany´ duplex (switch doka´zˇe zajistit vı´ce logicky´ch spojenı´ najednou), velke´ zvy´sˇenı´ propustnosti sı´teˇ, jde o plny´ duplex. Prˇepı´nacˇe posı´lajı´ ra´mce jen na ty porty, na ktere´ patrˇ´ı (kontrolujı´ adresu – DA), proto oddeˇlujı´ koliznı´ de´me´ny; pokud jsou v sı´ti pouzˇity jako DCE pouze prˇepı´nacˇe, nenı´ trˇeba pouzˇ´ıvat CSMA/CD. Rozlisˇujeme tedy • sdı´leny´ Ethernet – v jedne´ koliznı´ dome´neˇ je vı´ce nezˇ dva uzly, nutne´ pouzˇ´ıt CSMA/CD, • prˇepı´nany´ Ethernet – v jedne´ koliznı´ dome´neˇ jsou jen dva komunikujı´cı´ uzly, pouzˇ´ıva´ se plny´ duplex (jeden z uzlu˚ by´va´ prˇepı´nacˇ). 1 000Base-T (IEEE 802.3ab) pouzˇ´ıva´ vsˇechny 4 pa´ry UTP kategorie 5e (vyhovujı´ take´ neˇktere´ kabely kategorie 5), na kazˇde´m pa´ru je rychlost 250 Mb/s. Je zpeˇtneˇ kompatibilnı´ s 100Base-TX. Ra´mec se rozdeˇlı´ na 4 cˇa´sti pro 4 pa´ry UTP, zako´duje, na druhe´ straneˇ linky se deko´duje a znovu slozˇ´ı. Existujı´ specia´lnı´ sekvence pro IDLE, indikaci zacˇa´tku ra´mce, indikaci konce ra´mce. Ko´duje se pomocı´ PAM5.
P
2.4
STANDARDY PRO FYZICKOU VRSTVU
54
Je podporova´n polovicˇnı´ i plny´ duplex. CSMA/CD prˇesta´va´ vyhovovat, ale porˇa´d existuje. Hodneˇ se pouzˇ´ıvajı´ switche (aby nebylo nutne´ prˇi vysˇsˇ´ı rychlosti zmensˇovat koliznı´ dome´nu) a spojenı´ jsou spı´sˇe typu Point-to-Point (DTE-DCE). 1 000Base-X (IEEE 802.3z) je za´kladnı´ standard pro opticke´ kabely, od toho se odvı´jı´ i pouzˇite´ ko´dova´nı´ – 8B/10B (8 bitu˚ je ko´dova´no do 10bitove´ skupiny) v kombinaci s NRZ. Je podporova´n polovicˇnı´ i plny´ duplex.
P
Za´kladnı´ standardy jsou • 1 000BaseSX – sveˇtelny´ zdroj je LED-dioda nebo laser, vlnova´ de´lka 850 nm (v rea´lu 770–860 nm), mnohovidove´ kabely (pru˚meˇr ja´dra 50 nebo 62,5 µm), je urcˇen pro pro kratsˇ´ı horizonta´lnı´ vedenı´ nebo pa´terˇe (neˇkolik set metru˚) – 220 m pro kabely 50 µm, 550 m pro kabely 62,5 µm, • 1 000BaseLX – sveˇtelny´ zdroj je laser o vlnove´ de´lce 1300 nm (v rea´lu 1270–1355 nm), jednovidove´ (10 µm) nebo mnohovidove´ kabely (50 nebo 62,5 µm), pouzˇitelne´ pro delsˇ´ı vzda´lenosti (azˇ 5 km s jednovidovy´mi kabely; neˇkterˇ´ı vy´robci garantujı´ i 10 nebo 20 km, pokud jsou pouzˇity jejich produkty na obou koncı´ch linky). 1 000Base-SX je velmi oblı´beny´ ve firma´ch k propojenı´ budov v ra´mci jednoho area´lu. Naproti tomu 1 000Base-LX umozˇnˇuje ve´st kabely na veˇtsˇ´ı vzda´lenost, naprˇ´ıklad jako pa´terˇ propojujı´cı´ vı´ce pobocˇek (podsı´tı´) v ra´mci jednoho meˇsta. Existujı´ take´ neforma´lnı´ (firemnı´) specifikace, ktere´ nejsou standardizovane´: • LH – podobny´ LX, ale na delsˇ´ı vzda´lenost – azˇ 10 km, • ZX – pro jednovidove´ kabely vyuzˇ´ıvajı´cı´ laser o vlnove´ de´lce 1550 nm, vzda´lenosti i 70 km, • BX10 – jednovidovy´ opticky´ kabel, ale nesymetricka´ vlnova´ de´lka – pro downstream (ke koncove´mu zarˇ´ızenı´) 1490 nm, pro upstream (opacˇneˇ) 1310 nm. Vy´sˇe uvedene´ standardy a specifikace jsou pro opticke´ kabely. Do te´to skupiny patrˇ´ı jesˇteˇ jeden standard, ktery´ ma´ vy´jimku: 1 000BaseCX – kabel je STP (stı´neˇna´ dvojlinka) nebo koaxia´l, pouzˇ´ıva´ se kra´tke´ vzda´lenosti do 25 m, moc se neprosadil. Jeho prˇedpokla´danou vy´hodou byla mozˇnost snadneˇjsˇ´ı kombinace s prˇedchozı´mi, naprˇ´ıklad pro kra´tke´ spoje k serveru (propojenı´ serveru a blı´zke´ho prˇepı´nacˇe).
2.4.4
10Gb Ethernet
10 Gb Ethernet (10Gb, 10GbE) je urcˇen pro MAN a WAN sı´teˇ, pouzˇ´ıva´ se take´ v datovy´ch centrech (velke´ mnozˇstvı´ dat na kra´tkou vzda´lenost). propojenı´ serverovy´ch clusteru˚, apod. V rozlehly´ch sı´tı´ch pouzˇ´ıva´ specia´lnı´ podvrstvu WIS (WAN Interface Sublayer) pro prˇipojenı´ k SONET/SDH. Jako prvnı´ vznikla specifikace pro opticke´ sı´teˇ (IEEE 802.3ae, rok 2002), pozdeˇji i metalicke´ kabely. Prˇi takto vysoke´ rychlosti jizˇ nenı´ mozˇne´ efektivneˇ zabra´nit kolizı´m, proto se definitivneˇ prˇesˇlo na plny´ duplex podporovany´ switchi. CSMA/CD nelze aplikovat. Vy´voj take´ speˇje k modula´rnosti a mnohostrannosti. Mezilehla´ zarˇ´ızenı´ pro 10GbE (switche)
P P
2.4
STANDARDY PRO FYZICKOU VRSTVU
55
Obra´zek 2.6: Opticky´ transceiver XENPAK1 veˇtsˇinou podporujı´ vı´ce ru˚zny´ch fyzicky´ch vrstev, pouzˇ´ıvajı´ se vy´meˇnne´ za´suvne´ moduly (transceivery). Opticky´ transceiver ve formeˇ modulu (externı´ transceivery byly pouzˇ´ıva´ny i u drˇ´ıveˇjsˇ´ıch verzı´) nenı´ specifikova´n prˇ´ımo v 802.3, ale zvla´sˇt’ v dokumentech MSA (MultiSource Agreements) – prˇedevsˇ´ım se setka´va´me s MSA XENPAK, X2, XPAK, XFP and SFP+. Prˇipojuje se k rozhranı´ XAUI (jako AUI u starsˇ´ıch verzı´). XAUI spolu se svy´m okolı´m prˇedstavuje GMII, je napojen na MAC podvrstvu. Uka´zku vidı´me na obra´zku 2.6. 10GBase-R
(opticky´ kabel) pouzˇ´ıva´ ko´dova´nı´ 64B/66B. Rozlisˇujeme:
• 10GBase-SR (Short Range) – laser 850 nm, mnohavidovy´ kabel, dosah 62 m
J
• 10GBase-LR (Long Range) – laser 1310 nm, jednovidovy´ kabel, dosah 10 km (v praxi azˇ 25 km je kvalitnı´ signa´l) • 10GBase-LRM (Long Reach Multimode, IEEE 802.3aq) – laser 1310 nm, mnohavidovy´ kabel, dosah 220 m • 10GBase-ER (Extended Range) – laser 1550 nm, jednovidovy´ kabel, dosah 40 km 10GBase-W pouzˇ´ıva´ podvrstvu WIS pro prˇipojenı´ k WAN, opticke´ kabely (stejneˇ jako R, jen navı´c podpora WIS). Take´ ma´ varianty SW, LW a EW. Pouzˇ´ıva´ trochu jiny´ forma´t ra´mce – v ra´mci WIS je zapouzdrˇen beˇzˇny´ LAN ra´mec 10GBase-R Ethernetu), WIS se pak posı´la´ po WAN. 10GBase-T (802.3an) pro horizonta´lnı´ vedenı´ v ra´mci strukturovane´ kabela´zˇe. Ko´dova´nı´ PAM-16 v kombinaci s DSQ128, kroucena´ dvojlinka, a to kategorie 6 (dosah azˇ 55 m) nebo 6a cˇi 7 (dosah azˇ 100 m). 10GBase-CX4 (IEEE 802.3ak) je urcˇen pro datova´ centra a stohovatelne´ prˇepı´nacˇe, obecneˇ pro prˇipojenı´ neˇktere´ho DCE k serveru, • kabel twin-ax, 4 vysı´lacˇe a 4 prˇijı´macˇe po 2.5 Gb/s • cˇasto napojeno na InfiniBand – vysokorychlostnı´ rozhranı´ podporujı´cı´ QoS, se´riove´, obousmeˇrne´, s nı´zkou latencı´, ru˚zne´ sˇ´ırˇky (u CX4 s twin-axem pouzˇ´ıva´me 4×) – kromeˇ pouzˇitı´ v sı´tı´ch se rozhranı´ pouzˇ´ıva´ take´ naprˇ´ıklad k prˇipojenı´ datovy´ch zarˇ´ızenı´ • ko´dova´nı´ 8B/10B, dosah pouze do 15 m • vy´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 zalozˇen na XAUI. Dalsˇ´ı 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/
Obra´zek 2.7: Infiniband a twinax2 10GBase-LX4
lze pouzˇ´ıt pro prˇipojenı´ k infrastrukturˇe SONET/SDH (viz da´le)
• optika (jednovidove´ i mnohavidove´ kabely), 850 nm
P
• pouzˇ´ıva´ WDM (Wavelength-Division Multiplexing) – obdoba frekvencˇnı´ho multiplexu na optice (ru˚zne´ vlnove´ de´lky – „barvy“) • 4 oddeˇlene´ laserove´ zdroje, dosah 300 m/10 km
2.5 2.5.1
Technologie Krˇı´zˇenı´
Vysı´lacˇ (Tx – Transmit) na jednom konci spojenı´ musı´ by´t prˇipojen na prˇijı´macˇ (Rx – Receive) na druhe´m konci a naopak, proto je nutne´ krˇ´ızˇenı´ cesty. Toto krˇ´ızˇenı´ je naznacˇeno na obra´zku 2.8. Krˇ´ızˇenı´ mu˚zˇe by´t provedeno bud’ v kabelu (krˇ´ızˇeny´ kabel), a nebo interneˇ v zarˇ´ızenı´, ale nenı´ prˇesneˇ stanoveno, ktera´ z teˇchto mozˇnostı´ ma´ by´t pouzˇita. Podle doporucˇenı´ 802.3 by meˇlo platit: • • • •
na cesteˇ musı´ by´t lichy´ pocˇet krˇ´ızˇenı´ celkem, pokud je zarˇ´ızenı´ interneˇ opatrˇeno krˇ´ızˇenı´m, musı´ by´t oznacˇeno symbolem ×, internı´ krˇ´ızˇenı´ je volitelne´, prˇi propojenı´ DTE a DCE je doporucˇeno implementovat krˇ´ızˇenı´ interneˇ u DCE.
Rea´lneˇ se setka´va´me s tı´mto rˇesˇenı´m: • • • •
2
u 10Base-T: pro spojenı´ DTE–DCE pouzˇ´ıt nekrˇ´ızˇeny´, pro DTE–DTE pouzˇ´ıt krˇ´ızˇeny´, opticke´ kabely pro Ethernet jsou vzˇdy krˇ´ızˇene´, kroucene´ dvojlinky pro 100Base deˇdı´ pravidlo po 10Base-T, u 1000Base-T: NIC mu˚zˇe obsahovat mozˇnost volby internı´ho krˇ´ızˇenı´ (prˇi navazova´nı´ komunikace se to zjisˇt’uje v ra´mci procesu autonegociace), pokud neobsahuje, platı´ stejne´ 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 (prˇepı´nacˇ)
uzel 2 (stanice) Rx
Tx
Tx
Tx
uzel 1 (stanice)
uzel 2 (stanice) Rx
Rx
Obra´zek 2.8: Krˇ´ızˇenı´ (zde prˇi plne´m duplexu) V oznacˇenı´ch se setka´va´me se zkratkami MDI (Media Dependent Interface, pro koncove´ stanice) a MDIX nebo MDI-X (MDI with Crossover, pro mezilehle´ prvky). Na prˇepı´nacˇ´ıch by´vajı´ neˇktere´ porty vybaveny funkcı´ MDI/MDI-X, cozˇ znamena´, zˇe tento port bud’ umozˇnˇuje prˇepı´na´nı´ mezi pouzˇitı´m prˇ´ıme´ho cˇi krˇ´ızˇene´ho kabelu a nebo prˇ´ıpadneˇ doka´zˇe detekovat typ pouzˇite´ho kabelu (Auto Cross). Toho se vyuzˇ´ıva´ naprˇ´ıklad tehdy, kdyzˇ na port podle potrˇeby prˇipojujeme bud’ stanici (prˇ´ımy´ kabel) nebo jiny´ switch (krˇ´ızˇeny´).
P
Na prˇepı´nacˇi take´ mu˚zˇeme najı´t port oznacˇeny´ Uplink. Ten je prˇ´ımo urcˇen pro prˇipojenı´ k jine´mu mezilehle´mu prvku (nikoliv koncove´ stanici). Dalsˇ´ı informace o kabelech jsou na http://www.svetsiti.cz/view.asp?rubrika=Tipy&clanekID=110 ´ koly U Prohle´dneˇte si ethernetove´ kabely, ktere´ ma´te v dosahu. Vsˇimneˇte si, zda jsou krˇ´ızˇene´ cˇi nekrˇ´ızˇene´ (konektory jsou pru˚hledne´, porovnejte usporˇa´da´nı´ barevny´ch vodicˇu˚). Da´le zjisteˇte kategorii kabelu (obvykle najdete v textu natisknute´m v pravidelny´ch intervalech prˇ´ımo na kabelu). Pokud ma´te kabel kategorie 5, oveˇrˇte si, zda jde o kabel se dveˇma nebo cˇtyrˇmi pa´ry (opeˇt pozna´te na prvnı´ pohled na konektoru).
2.5.2
Auto-negotitation
Auto-negotitation (vyjedna´va´nı´ NIC) prˇedstavuje mechanismus, ktery´ se rozvı´jı´ postupneˇ u standardu˚ na UTP kabel od 10Base-T. NIC ohla´sı´ svou verzi (cˇ´ıslo, naprˇ´ıklad 10Base-T half duplex ma´ 1, 100Base-T full duplex ma´ 6, apod.). Dveˇ ru˚zne´ NIC se domluvı´ na prˇenosovy´ch rezˇimech, ktery´m obeˇ rozumı´, vybere se prˇenosovy´ rezˇim nejvysˇsˇ´ı ze sdı´leny´ch. Pouzˇ´ıvajı´ se dveˇ formy: • NLP (Normal Link Pulse) – umı´ vsˇechny od 10Base-T, • FLP (Fast Link Pulse) – nesou dalsˇ´ı informaci. Pokud NIC nerozumı´ FLP pulsu˚m, je automaticky povazˇova´na za 10Base-T half duplex.
P
2.5
TECHNOLOGIE
2.5.3
58
Multiple-Rate Ethernet
Multiple-Rate Ethernet (Ethernet ve vı´ce u´rovnı´ch) je rˇesˇenı´ pro souvisle´ oblasti (neˇkolik budov) pokryte´ sı´tı´ (campusy), ktere´ sdı´lejı´ jedno prˇipojenı´ na Internet. Rozlisˇujeme neˇkolik typu˚ uzlu˚ (kromeˇ prˇipojovany´ch DTE):
P
• Campus Distributor – by´va´ to (10)Gb switch s mozˇnostı´ prˇipojenı´ k telekomunikacˇnı´ sı´ti nebo jine´ WAN • Building Distributor – rychlejsˇ´ı switch prˇipojeny´ na pa´terˇ campusu, hlavnı´ switch v budoveˇ • Floor Distributor – nizˇsˇ´ı u´rovenˇ v hierarchii, od nı´ da´le vede horizonta´lnı´ vedenı´ • Telecom Outlet (na obra´zku 2.9 oznacˇeno zkratkou TO) – obvykle rozhranı´, ke ktere´mu se prˇipojujı´ pocˇ´ıtacˇe a dalsˇ´ı koncova´ zarˇ´ızenı´, „za´suvka“ Uzly jsou propojeny teˇmito kabely: • Campus Backbone Cabling – hlavnı´ pa´terˇ, typicky optika (jedno- i mnohavidova´), prˇipojenı´ Building Distributoru˚ • Building Backbone Cabling – pa´terˇnı´ sı´t’na u´rovni budov, typicky UTP kat. 5 nebo lepsˇ´ı a nebo mnohavidovy´ kabel • Horizontal Cabling – horizonta´lnı´ kabela´zˇ, obvykle UTP, neˇkde i mnohavidovy´ kabel
2.5.4
PoE
PoE (Power over Ethernet) je standard IEEE 802.3af (rok 2003). Mnoha´ zarˇ´ızenı´ prˇipojena´ k Ethernetu majı´ jen maly´ prˇ´ıkon, tak k cˇemu zvla´sˇt’ napa´jenı´? PoE umozˇnˇuje napa´jet zarˇ´ızenı´ po datovy´ch kabelech (UTP kat. alesponˇ 5). Pro napa´jenı´ jsou pouzˇ´ıva´ny vzˇdy dva prostrˇednı´ pa´ry, a to bud’ vy´hradneˇ, a nebo za´rovenˇ s daty. ISP Campus Distributor hlavnı´ pa´terˇ Building Distributor
Building Distributor
Floor Distributor
pa´terˇnı´ sı´t’ v budoveˇ
horizonta´lnı´ kabela´zˇ
TO
TO
TO
atd. Floor Distributor
Floor Distributor TO
TO
TO
TO
TO
TO
Obra´zek 2.9: Multiple-Rate Ethernet
P
2.5
TECHNOLOGIE
59
Toto rˇesˇenı´ je zpeˇtneˇ kompatibilnı´ i se zarˇ´ızenı´mi nepodporujı´cı´mi PoE (aby zarˇ´ızenı´ nebylo znicˇeno, prˇi prˇipojenı´ se napa´jı´ nejdrˇ´ıve nı´zky´m napeˇtı´m, a kdyzˇ je odezva – podporuje, prˇecha´zı´ se na vysˇsˇ´ı napeˇtı´). Pouzˇ´ıva´ se azˇ 13 W prˇi 48 V, pokud zarˇ´ızenı´ potrˇebuje nizˇsˇ´ı napeˇtı´, samo provede transformaci. Typicky´ prˇ´ıklad zarˇ´ızenı´, ktera´ mohou by´t takto napa´jena, jsou IP telefony, ale podporu PoE najdeme i u neˇktery´ch switchu˚ a dalsˇ´ıch zarˇ´ızenı´. S tı´mto pojmem se setka´me i v kapitole o bezdra´tovy´ch sı´tı´ch (Wi-fi sı´teˇ 4. generace).
2.5.5
EFM
EFM (Ethernet in the First Mile) (IEEE 802.3ah, rok 2004) je mozˇnost vyuzˇitı´ Ethernetu na cele´ cesteˇ prˇes WAN azˇ ke koncovy´m pocˇ´ıtacˇu˚m. Pocˇ´ıta´ se jak s metalicky´mi, tak i opticky´mi spoji. Protozˇe 10G Ethernet je pouzˇitelny´ (a take´ pouzˇ´ıva´n) v rozlehly´ch sı´tı´ch, bylo by prakticke´ pouzˇ´ıt Ethernet take´ na poslednı´ (prvnı´) mı´li prˇipojenı´ k internetu („first mile“).
P
Pro prˇipojenı´ k ATM WAN se pouzˇ´ıva´ naprˇ´ıklad ADSL. Prˇi prˇechodu WAN od ATM k Ethernetu se uvazˇuje o nahrazenı´ ADSL linek Ethernetem, protozˇe by to znamenalo me´neˇ transformacı´ dat na cesteˇ prˇi kombinova´nı´ ru˚zny´ch technologiı´.
2.5.6
Metro Ethernet
V prˇ´ıpadeˇ Metropolitnı´ho Ethernetu (Metro Ethernet) bylo za´meˇrem, aby prˇi propojova´nı´ ru˚zny´ch LAN nebylo trˇeba vyuzˇ´ıvat jinou mezilehlou technologii na u´rovni linkove´ vrstvy (jina´ technologie ⇒ alesponˇ sı´t’ova´ vrstva) s tı´m, zˇe sı´t’by meˇla podporovat VLAN a QoS.
ADSL ADSL EFM
ATM DSLAM Eth DSLAM Eth DSLAM
ATM GbE GbE
ATM switch
P
Eth switch Eth switch
Obra´zek 2.10: Postup zava´deˇnı´ EFM
Metro Ethernet mu˚zˇe by´t implementova´n bud’ jako „cˇisty´“ Ethernet nebo jako na´stavba existujı´cı´ technologie pro metropolitnı´ cˇi rozlehle´ sı´teˇ (vyuzˇije se existujı´cı´ infrastruktura) – Ethernet over SDH, Ethernet over MPLS, apod. Informace o nejrychlejsˇ´ıch standardech IEEE 802.3 a Ethernetu obecneˇ: • 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
Dalsˇ´ı te´mata k loka´lnı´m sı´tı´m Protozˇe v „dra´tovy´ch“ LAN se v praxi setka´va´me te´meˇrˇ vy´hradneˇ s Ethernetem, nebudeme probı´rat dalsˇ´ı beˇzˇne´ typy LAN (FDDI, Token Ring), ale prˇesto se podı´va´me jesˇteˇ na dalsˇ´ı te´mata souvisejı´cı´ s loka´lnı´mi sı´teˇmi. Zde se budeme zaby´vat technologiemi EtherChannel, Fibre Channel a iSCSI (SAN sı´teˇ), a virtua´lnı´mi loka´lnı´mi sı´teˇmi.
3.1 3.1.1
EtherChannel Vlastnosti
EtherChannel je technologie umozˇnˇujı´cı´ spojit (agregovat) azˇ 8 fyzicky´ch ethernetovy´ch linek do jedne´. Dva uzly (typicky servery, prˇepı´nacˇe nebo smeˇrovacˇe podporujı´cı´ tuto technologii) jsou propojeny vı´ce aktivnı´mi fyzicky´mi ethernetovy´mi spoji, PDU procha´zejı´ neˇktery´m z teˇchto spoju˚. Da´le je podporova´no navı´c azˇ 8 za´lozˇnı´ch fyzicky´ch linek (failover) pro prˇ´ıpad, zˇe aktivnı´ linky budou nefunkcˇnı´. V prˇ´ıpadeˇ EtherChannelu se pouzˇ´ıva´ dvojı´ terminologie – zatı´mco u firmy Cisco se mluvı´ o EtherChannel, v syste´mu Solaris se pro tote´zˇ pouzˇ´ıva´ pojem trunk, cozˇ ale u Cisco znamena´ neˇco u´plneˇ jine´ho. Proto kdyzˇ slysˇ´ıme pojem „trunk“, meˇli bychom mı´t jasno v tom, cˇ´ı terminologie je vlastneˇ pra´veˇ pouzˇ´ıva´na. U serveru˚ se take´ pouzˇ´ıva´ pojem NIC Teaming, cozˇ vsˇak nenı´ u´plneˇ tote´zˇ (je to sˇirsˇ´ı termı´n, sdruzˇova´nı´ sı´t’ovy´ch karet do jedne´ „virtua´lnı´“, logicke´). Spoje, ktere´ jsou soucˇa´stı´ EtherChannelu, jsou typu Fast Ethernet nebo rychlejsˇ´ı, a vsˇechny musejı´ by´t stejne´ho typu (tj. naprˇ´ıklad nelze kombinovat spoje Fast Ethernet a 10Gb Ethernet – stejna´ rychlost, da´le stejny´ duplex apod.). Pokud pouzˇ´ıva´me VLAN (virtua´lnı´ sı´teˇ), meˇly by spoje by´t v ra´mci jedne´ VLAN nebo v trunk mo´du se stejny´mi parametry. Celkova´ propustnost se vsˇak nerovna´ soucˇtu propustnostı´ jednotlivy´ch fyzicky´ch cest. Pokud se v ra´mci jedne´ komunikace smeˇrˇujı´cı´ k jednoho uzlu k jine´mu uzlu (ve vy´chozı´m nastavenı´) posı´la´ vı´ce PDU, vsˇechny jsou posı´la´ny po te´zˇe fyzicke´ cesteˇ, tedy komunikaci nelze rozdeˇlit.
60
P
L
3.1
ETHERCHANNEL
3.1.2
61
ˇ ı´zenı´ toku R
Vy´chozı´ nastavenı´ je takove´, zˇe spoje v ra´mci EtherChannelu jsou rozdeˇlova´ny podle cı´love´ MAC adresy, tedy PDU, ktere´ majı´ konkre´tnı´ cı´lovou MAC adresu, jsou vsˇechny smeˇrova´ny na tenty´zˇ spoj. To vsˇak ne vzˇdy vyhovuje, proto je mozˇne´ nastavit i jine´ deˇlenı´:
$
• dvojici [zdrojova´ MAC, cı´lova´ MAC], • pouze podle zdrojove´ MAC, • podobneˇ pro IP adresy a porty.
Rozdeˇlenı´ komunikacˇnı´ch proudu˚ mezi EC porty
Rozdeˇlenı´ za´teˇzˇe (tj. jednotlivy´ch spojenı´) mezi linky v ra´mci EtherChannelu se prova´dı´ podle hashovacı´ho vyvazˇovacı´ho algoritmu, ktery´ trˇ´ıdı´ PDU podle zadane´ho krite´ria (naprˇ´ıklad podle cı´love´ MAC adresy) a celou komunikaci deˇlı´ podle pravidla naznacˇene´ho v tabulce 3.1.
8 1 1 1 1 1 1 1 1
Pocˇet EC portu˚ 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: Hashova´nı´ komunikace v EtherChannelu Kazˇde´mu „proudu dat“ urcˇene´mu podle zvolene´ho krite´ria (naprˇ´ıklad podle cı´love´ adresy) je hashova´nı´m prˇideˇleno cˇ´ıslo z intervalu 0–7 (tj. jedno z 8 cˇ´ısel), a to bez ohledu na skutecˇny´ pocˇet spoju˚ v EtherChannelu. Toto cˇ´ıslo pak urcˇuje konkre´tnı´ fyzicky´ spoj. Naprˇ´ıklad pokud ma´me EtherChannel nad trˇemi fyzicky´mi spojenı´mi (EC porty), budou na prvnı´ spoj smeˇrova´ny PDU se trˇemi konkre´tnı´mi prˇirˇazeny´mi cˇ´ısly, jina´ trˇi cˇ´ısla budou smeˇrova´na na druhy´ spoj a zbyla´ dveˇ na trˇetı´ spoj. Je zrˇejme´, zˇe nejoptima´lneˇji budou spoje vyva´zˇeny, pokud do EtherChannelu sdruzˇ´ıme 2, 4 nebo 8 spoju˚.
3.1.3
Protokoly
Pro EtherChannel (EC) existujı´ dva protokoly vyjedna´vajı´cı´ vlastnosti EC spojenı´: • LACP (Link Aggregation Control Protocol) definovany´ IEEE 802.3ax1 , • PAgP (Port Aggregation Protocol), cozˇ je proprieta´lnı´ protokol firmy Cisco. 1
Spra´vneˇ je IEEE 802.3ax, ale v literaturˇe se beˇzˇneˇ mu˚zˇeme setkat s nespra´vny´m (vy´znamoveˇ mı´rneˇ posunuty´m) IEEE 802.3ad – NIC Teaming.
P
SAN SI´TEˇ
3.2
62
Prvnı´ z teˇchto protokolu˚ je obecneˇ pouzˇitelny´ ve vsˇech zarˇ´ızenı´ch podporujı´cı´ch EtherChannel (vcˇetneˇ zarˇ´ızenı´ firmy Cisco), druhy´ se pouzˇ´ıva´ pouze prˇi propojova´nı´ dvou zarˇ´ızenı´ Cisco. V jedne´ EC sı´ti musı´ by´t pouzˇit vzˇdy jen jediny´ z teˇchto protokolu˚ (a vsˇechna zarˇ´ızenı´ mu musı´ „rozumeˇt“). Oba protokoly umozˇnˇujı´ nastavit zarˇ´ızenı´ do jednoho ze dvou stavu˚ – aktivnı´ho (active u LACP, desirable u PAgP), ve ktere´m zarˇ´ızenı´ aktivneˇ vyjedna´va´ sestavenı´ EtherChannelu, a pasivnı´ho (passive u LACP, auto u PAgP), ve ktere´m zarˇ´ızenı´ pasivneˇ vycˇka´va´ na iniciaci vyjedna´va´nı´ o EtherChannelu od druhe´ strany.
P
EtherChannel lze take´ vytvorˇit manua´lneˇ napevno, stav je oznacˇova´n on. Pak je EtherChannel vytvorˇen na´mi a zˇa´dne´ vyjedna´va´nı´ zarˇ´ızenı´ nenı´ potrˇeba a tedy se vlastneˇ nepouzˇije zˇa´dny´ z prˇedchozı´ch dvou protokolu˚. Dalsˇ´ı informace vcˇetneˇ mnoha prˇ´ıkladu˚ najdeme na adresa´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ı´teˇ
SAN (Storage Area Network) jsou sı´teˇ urcˇene´ k propojenı´ datovy´ch u´lozˇisˇt’(diskovy´ch polı´, NAS, souborovy´ch serveru˚ apod.) s mezilehly´mi prvky sı´teˇ, jde tedy o sı´teˇ urcˇene´ k zajisˇteˇnı´ vysoke´ dostupnosti datovy´ch u´lozˇisˇt’(prˇ´ıp. datovy´ch center).
P
K nejzna´meˇjsˇ´ım SAN technologiı´m patrˇ´ı Fibre Channel (FC) a iSCSI.
3.2.1
Fibre Channel
Fibre Channel je prˇeva´zˇneˇ opticke´ rozhranı´ (tj. na opticky´ch kabelech) pro rychle´ prˇesuny dat na (relativneˇ) kra´tke´ vzda´lenosti. Pu˚vodneˇ bylo urcˇeno pro pouzˇitı´ „uvnitrˇ pocˇ´ıtacˇe“ (konkre´tneˇji serveru) ke komunikaci mezi I/O zarˇ´ızenı´mi a procesory, ale postupneˇ se prosadilo jako sı´t’ovy´ standard. Pod pojmem kana´l (channel) se zde rozumı´ prˇ´ıme´ nebo prˇepı´nane´ predikovatelne´ propojenı´ dvou zarˇ´ızenı´. Jde o plneˇ duplexnı´ se´riove´ rozhranı´ pro point-to-point spoje (i vı´ce point-to-point spoju˚ s vhodny´m hardwarem, prˇepı´nacˇem). Prˇepı´na´nı´ je zde velmi jednoduche´ a rychle´, mu˚zˇe by´t realizova´no hardwaroveˇ. Vy´hodou je tedy vysoka´ rychlost prˇepı´na´nı´ a tedy i dostupnosti dat. Fibre Channel pracuje na stejny´ch vrstva´ch jako Ethernet, veˇtsˇina logiky technologie je v MAC podvrstveˇ. Podle na´zvu by se mohlo zda´t, zˇe jako prˇenosovy´ prostrˇedek je mozˇne´ pouzˇ´ıt pouze opticky´ kabel, ale ve skutecˇnosti je mozˇne´ pouzˇ´ıt take´ koaxia´l nebo STP (stı´neˇnou dvojlinku), cozˇ ale ma´
P
VIRTUA´LNI´ LOKA´LNI´ SI´Tˇ – VLAN
3.3
63
vliv na dosazˇitelne´ vzda´lenosti a rychlost. Zatı´mco s jednovidovy´m opticky´m vla´knem dosa´hneme rychlosti azˇ 1 Gb/s a vzda´lenosti azˇ 10 km (s mnohavidovy´mi vla´kny samozrˇejmeˇ me´neˇ, vzda´lenost je od uzlu k prˇepı´nacˇi), prˇi pouzˇitı´ STP to je 100 m prˇi rychlosti 132 Mb/s nebo 50 m prˇi 265 Mb/s. Nejnoveˇjsˇ´ı standard umozˇnˇuje dosazˇenı´ rychlosti 4 Gb/s. Levneˇjsˇ´ı a jednodusˇsˇ´ı variantou je Fibre Channel se smycˇkou, jehozˇ topologie je kruhova´ bez pouzˇitı´ mezilehly´ch prvku˚, prˇ´ıstupova´ metoda je podobna´ vyuzˇ´ıva´nı´ tokenu. Toto rˇesˇenı´ je vhodne´ jen pro maly´ pocˇet zarˇ´ızenı´, maxima´lneˇ 30. FCoE (Fibre Channel over Ethernet) je pokus o sloucˇenı´ jinak rozdı´lny´ch sı´tı´ Fibre Channel a Ethernet (10Gb). Zatı´mco samotny´ FC doka´zˇe pracovat jen v ra´mci jednoho ethernetove´ho segmentu (k nejblizˇsˇ´ımu smeˇrovacˇi), FCoE dı´ky napojenı´ na technologii Ethernetu se dostane i za smeˇrovacˇe. FCoE vyzˇaduje podporu Jumbogramu˚ (Jumboframe) – viz IPv6 datagramy (str. 31).
3.2.2
P P
iSCSI
iSCSI (Internet Small Computer System Interface) je obdobou FCoE urcˇenou spı´sˇe pro mensˇ´ı SAN sı´teˇ. Jedna´ se vlastneˇ o mozˇnost posı´la´nı´ SCSI prˇ´ıkazu˚ prˇes IP sı´t’ (vzpomenˇte si na rozhranı´ pevny´ch disku˚ – SCSI disky se dnes celkem hodneˇ pouzˇ´ıvajı´ v serverech). Zatı´mco FC pracuje na ethernetovy´ch vrstva´ch ISO/OSI, iSCSI pracuje azˇ na sı´t’ove´ vrstveˇ.
P
Technologie iSCSI mu˚zˇe by´t implementova´na softwaroveˇ nebo hardwaroveˇ. Softwarova´ implementace je levneˇjsˇ´ı (konkre´tneˇ – zdarma), prˇ´ıslusˇny´ software si lze sta´hnout od vy´robce/distributora kazˇde´ho operacˇnı´ho syste´mu nebo je dokonce soucˇa´stı´ instalace syste´mu (jen je obvykle nutne´ aktivovat prˇ´ıslusˇnou sluzˇbu cˇi de´mona). Hardwarova´ implementace znamena´ podporu na NIC (za tu se prˇipla´cı´). Vy´hodou hardwarove´ implementace je vysˇsˇ´ı rychlost, protozˇe pomocny´ procesor na NIC odlehcˇuje hlavnı´m procesoru˚m prˇi zpracova´va´nı´ (nejen) iSCSI pozˇadavku˚. Obecneˇ platı´, zˇe do mensˇ´ı SAN stacˇ´ı softwarova´ implementace, do veˇtsˇ´ı nebo hodneˇ vytı´zˇene´ SAN je dobre´ investovat do sı´t’ovy´ch karet s hardwarovou implementacı´ iSCSI (samozrˇejmeˇ pokud ma´me SCSI disky). Popis architektury Fibre Channel najdeme naprˇ´ıklad na http://www.kiv.zcu.cz/˜simekm/vyuka/pd/zapocty-2004/san-mrnka/fc.html. Cˇla´nek o FCoE (prvnı´ dı´l seria´lu): http://www.abclinuxu.cz/clanky/hardware/fcoe-fibre-channel-over-ethernet Cˇla´nek o iSCSI:
http://www.microsoft.com/cze/technet/clanky/iscsi.mspx Dalsˇ´ı mozˇna´ rˇesˇenı´ SAN sı´tı´ jsou InfiniBand, ATAoE (ATA over Ethernet), apod.
3.3
Virtua´lnı´ loka´lnı´ sı´t’– VLAN
VLAN (Virtual LAN, virtua´lnı´ loka´lnı´ sı´teˇ) vytva´rˇejı´ logickou LAN (obvykle neˇkolik logicky´ch LAN) nad jednou nebo vı´ce fyzicky´mi LAN. VLAN je jednoznacˇneˇ urcˇena bud’ cˇ´ıslem nebo na´zvem, obvyklejsˇ´ı (podporovaneˇjsˇ´ı) je oznacˇova´nı´ VLAN cˇ´ısly.
P
3.3
VIRTUA´LNI´ LOKA´LNI´ SI´Tˇ – VLAN
64
Fyzicka´ sı´t’ se skla´da´ ze sı´t’ovy´ch segmentu˚ oddeˇleny´ch prˇepı´nacˇi nebo zarˇ´ızenı´mi obsahujı´cı´mi funkci prˇepı´nacˇe, jeden sı´t’ovy´ segment mu˚zˇe naprˇ´ıklad prˇi pouzˇitı´ strukturovane´ kabela´zˇe prˇedstavovat jedno patro firemnı´ budovy. VLAN vytvorˇena´ nad touto fyzickou sı´tı´ mu˚zˇe spojovat vybrane´ stanice nacha´zejı´cı´ se take´ v ru˚zny´ch segmentech sı´teˇ.
3.3.1
Cˇlenstvı´ ve skupineˇ
Prˇ´ıslusˇnost stanice do konkre´tnı´ VLAN je urcˇena zarˇazenı´m stanice do skupiny, ktera´ mu˚zˇe by´t urcˇena neˇktery´m z teˇchto krite´riı´: 1. VLAN podle portu˚ – na prˇepı´nacˇ´ıch v sı´ti jsou konkre´tnı´ porty (a tedy stanice k nim prˇipojene´ roztrˇ´ıdeˇny do jednotlivy´ch VLAN. Tato metoda je nejpouzˇ´ıvaneˇjsˇ´ı, je pomeˇrneˇ jednoducha´. Prˇi zmeˇneˇ struktury sı´teˇ (naprˇ´ıklad stanice bude prˇenesena a prˇipojena k jine´mu portu) je vsˇak nutne´ prove´st rucˇnı´ rekonfiguraci, a dalsˇ´ı nevy´hodou je nemozˇnost zarˇazenı´ stanice (portu) do vı´ce nezˇ jedne´ VLAN. 2. VLAN podle MAC adres (na linkove´ vrstveˇ) – tato metoda je na´rocˇneˇjsˇ´ı na pocˇa´tecˇnı´ konfiguraci, protozˇe MAC adresy musejı´ by´t do skupin prˇirˇazeny rucˇneˇ. Odpada´ vsˇak rucˇnı´ rekonfigurace prˇi zmeˇneˇ umı´steˇnı´ stanice a jedna stanice mu˚zˇe by´t i ve vı´ce VLAN. Nevy´hodou je veˇtsˇ´ı cˇasova´ na´rocˇnost prˇepı´na´nı´ a s tı´m souvisejı´cı´ snı´zˇena´ propustnost sı´teˇ (zvla´sˇteˇ pokud jedna MAC adresa prˇ´ıslusˇ´ı do vı´ce VLAN). Je trˇeba da´t pozor na mozˇnost pozmeˇneˇnı´ MAC adresy. 3. VLAN na sı´t’ove´ vrstveˇ – jednou z mozˇnostı´ je seskupit stanice podle IP adresy podsı´teˇ (v TCP/IP sı´ti), dalsˇ´ı mozˇnost je seskupova´nı´ podle sı´t’ove´ho protokolu (TCP/IP, Novell NetWare, AppleTalk apod.). To lze pouze u mezilehly´ch prvku˚ sı´teˇ, ktere´ pracujı´ i na sı´t’ove´ vrstveˇ (prˇepı´nacˇ samotny´ jen na L2). Tento typ VLAN lze zobecnit na VLAN podle informacı´ sı´t’ove´ho protokolu. 4. VLAN podle multicast adresy – cˇlenstvı´ v VLAN za´visı´ na prˇ´ıjmu konkre´tnı´ multicast komunikace. Narozdı´l od prˇedchozı´ch typu˚ VLAN jsou ra´mce posı´lane´ uvnitrˇ te´to VLAN vzˇdy dorucˇeny vsˇem cˇlenu˚m skupiny, ne jen jednomu (adresace je vzˇdy skupinova´). 5. VLAN podle politiky – prˇ´ıslusˇnost do VLAN je urcˇena kombinacı´ i vı´ce krite´riı´ (tj. politikou, „za´sadou“) a mu˚zˇe by´t dynamicky meˇneˇna podle chova´nı´ stanice v sı´ti (umı´steˇnı´, typu a mnozˇstvı´ zası´lany´ch ra´mcu˚, atd.). Chova´nı´ stanic a provoz na sı´ti jsou automaticky monitorova´ny a politiky mohou by´t prˇizpu˚sobova´ny. 6. VLAN s autentizacı´ – mu˚zˇeme pouzˇ´ıt IEEE 802.1x pro autentizaci uzˇivatele (RADIUS) a autorizace pak obsahuje zarˇazenı´ uzˇivatele do prˇ´ıslusˇne´ VLAN. Je take´ mozˇne´ nastavit, zˇe uzˇivatel, ktery´ nebyl autentizova´n (host) bude zarˇazen do specia´lnı´ VLAN pro hosty. Pouze VLAN podle portu˚ neumozˇnˇujı´ definovat vı´ce VLAN na jednom portu ani cˇlenstvı´ stanice ve vı´ce VLAN (resp. je to vy´razneˇ na´rocˇneˇjsˇ´ı). Ovsˇem v soucˇasne´ dobeˇ jsou nejpouzˇ´ıvaneˇjsˇ´ı. Konkre´tnı´ urcˇenı´ stanic, ktere´ majı´ patrˇit do dane´ skupiny, vycha´zı´ z potrˇeb firmy. Rozdeˇlenı´ mu˚zˇe by´t urcˇeno naprˇ´ıklad podle organizacˇnı´ struktury firmy – VLAN pro u´cˇetnı´ oddeˇlenı´, VLAN pro mzdove´ a persona´lnı´ oddeˇlenı´, dalsˇ´ı pro vy´robnı´ u´sek apod., ovsˇem to je relativnı´ a kazˇda´ firma ma´ v tomto smeˇru trochu jine´ potrˇeby.
P
3.3
VIRTUA´LNI´ LOKA´LNI´ SI´Tˇ – VLAN
65
V za´kladu se rˇ´ıdı´me podle toho, jak probı´ha´ obvykla´ komunikace mezi stanicemi, tedy stanice, ktere´ navza´jem hodneˇ komunikujı´, by meˇly by´t v jedne´ VLAN. Dalsˇ´ım krite´riem mu˚zˇe by´t bezpecˇnost a zamezenı´ u´niku˚m informacı´. VLAN naprˇ´ıklad mu˚zˇe propojovat tote´zˇ oddeˇlenı´ v ru˚zny´ch pobocˇka´ch firmy.
3.3.2
Urcˇenı´ cˇlenstvı´
V sı´ti pouzˇ´ıvajı´cı´ VLAN (nejcˇasteˇji na vrstveˇ L2) musı´ by´t mozˇne´ prˇ´ımo z ra´mce urcˇit cˇlenstvı´ v konkre´tnı´ VLAN. Soucˇa´stı´ za´hlavı´ ra´mce podle IEEE 802.1Q mu˚zˇe by´t identifikace VLAN (Frame Tagging), a to hned za cı´lovou a zdrojovou adresou v 4oktetove´m poli. V tomto poli najdeme identifikaci protokolu (pevneˇ 0×8100), 3 bity pro prioritu (podle IEEE 802.1P), 1 bit pro Token Ring (prˇ´ıznak kanonicke´ adresy) a konecˇneˇ 12bitovy´ identifika´tor VLAN – VID (VLAN ID). Pra´veˇ podle VID se prova´dı´ prˇepı´na´nı´.
P
Ve smeˇrovacˇ´ıch Cisco se mu˚zˇeme setkat s jiny´m rˇesˇenı´m prˇida´nı´ VLAN informacı´ do ra´mce, protokolem ISL (Inter-Switch Link). Jde o proprieta´lnı´ protokol firmy Cisco. Zatı´mco IEEE 802.1Q prˇida´va´ nove´ 4oktetove´ pole prˇ´ımo do za´hlavı´ ra´mce, ISL zapouzdrˇuje pu˚vodnı´ ra´mec do vlastnı´ PDU, v jejı´mzˇ za´hlavı´ najdeme potrˇebne´ informace o VLAN a do za´patı´ prˇida´va´ novy´ kontrolnı´ soucˇet.
P
Prˇepı´nacˇ 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 Prˇepı´nacˇ 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
Obra´zek 3.1: Propojenı´ prˇepı´nacˇu˚ trunkem
3.3.3
Zajisˇteˇnı´ komunikace mimo VLAN
Vza´jemneˇ komunikovat mohou pouze ty stanice, ktere´ patrˇ´ı do stejne´ VLAN. Pokud chceme zajistit komunikaci i mezi ru˚zny´mi VLAN (prˇ´ıpadneˇ se zapojenı´m dalsˇ´ıch bezpecˇnostnı´ch mechanismu˚), jde to prˇipojenı´m vneˇjsˇ´ıho smeˇrovacˇe (prˇepı´nacˇ nestacˇ´ı, stejneˇ jako prˇi propojova´nı´ fyzicky´ch LAN) k obeˇma teˇmto VLAN (ovsˇem pozor, mu˚zˇe nastat proble´m s protokolem STP, viz kapitolu 7.2.2, od
P
3.3
VIRTUA´LNI´ LOKA´LNI´ SI´Tˇ – VLAN
66
strany 147). Toto rˇesˇenı´ je vhodne´ tehdy, kdyzˇ opravdu chceme propojit jen dveˇ konkre´tnı´ VLAN, ale kdybychom takto chteˇli propojit vı´ce nezˇ dveˇ VLAN, museli bychom vytvorˇit propojenı´ zvla´sˇt’ pro kazˇdou VLAN, cozˇ je ply´tva´nı´ porty. ˇ esˇenı´m je pouzˇitı´ trunku. Trunk je propojenı´ mezi dveˇma prˇepı´nacˇi prˇena´sˇejı´cı´ ra´mce z vı´ce nezˇ R jedne´ VLAN (port s podporou vı´ce VLAN). Mu˚zˇe ve´st mezi dveˇma prˇepı´nacˇi (z kazˇde´ho prˇepı´nacˇe zabere pouze jeden port, takovy´, ktery´ nenı´ prˇ´ımo prˇirˇazen jedne´ konkre´tnı´ VLAN), nebo mezi prˇepı´nacˇem a vneˇjsˇ´ım smeˇrovacˇem (pak vesˇkera´ komunikace obeˇma smeˇry mezi ru˚zny´mi VLAN jde po jednom spoji, cozˇ snizˇ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
smeˇrovacˇ VLAN 10
Port 0
VLAN 30
Port 1
Port 2
Port 3
VLAN 20
Port 4
Port 5
Port 6
Port 7
Obra´zek 3.2: Prˇepı´nacˇ s vestaveˇnou funkcˇnostı´ L3 Dalsˇ´ı mozˇnost efektivnı´ho propojenı´ VLAN je pouzˇitı´ prˇepı´nacˇe s vestaveˇnou funkcˇnostı´ vrstvy L3 (tj. smeˇrova´nı´), pak nepotrˇebujeme vneˇjsˇ´ı smeˇrovacˇ, ale vyuzˇ´ıva´me internı´ smeˇrovacˇ, ktery´ je vnitrˇneˇ propojen se vsˇemi VLAN v prˇepı´nacˇi a komunikace mezi VLAN nenı´ zdrzˇova´na. Dalsˇı´ 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ı´teˇ V te´to kapitole se budeme zaby´vat spojovy´mi protokoly pro WAN a na nich postaveny´mi rozlehly´mi sı´teˇmi, a to X.25, Frame Relay, ATM, MPLS a dalsˇ´ımi.
4.1
Spojove´ protokoly
Veˇtsˇina bitoveˇ orientovany´ch spojovy´ch protokolu˚ (protokolu˚ na linkove´ vrstveˇ, L2) vycha´zı´ z dnes jizˇ zastarale´ho protokolu SDLC (Synchronous Data Link Control) od firmy IBM. Tento protokol je pomeˇrneˇ univerza´lnı´, pouzˇitelny´ pro point-to-point i vı´cebodove´ spoje, pro ru˚zne´ typy prˇenosovy´ch me´diı´, polovicˇnı´ i plny´ duplex, pro prˇepı´na´nı´ okruhu˚ i paketu˚. Typicky se pouzˇ´ıval pro prˇipojenı´ vy´konne´ho pocˇ´ıtacˇe ke vzda´lene´ LAN.
4.1.1
P
HDLC
Jednı´m z potomku˚ protokolu SDLC je HDLC (High Data Link Control). Stejneˇ jako SDLC, take´ HDLC rozlisˇuje v sı´ti dva typy zarˇ´ızenı´: • prima´rnı´ uzel – rˇ´ıdı´ komunikaci sekunda´rnı´ch uzlu˚, • sekunda´rnı´ uzly – mohou vysı´lat pouze po obdrzˇenı´ povolenı´ od prima´rnı´ho uzlu. Mozˇne´ konfigurace: • point-to-point – pouze dva uzly, jeden prima´rnı´ a jeden sekunda´rnı´ • vı´cebodove´ – jeden prima´rnı´ a vı´ce sekunda´rnı´ch uzlu˚ SDLC naproti tomu prˇida´val jesˇteˇ dalsˇ´ı dva typy konfigurace – smycˇku (kruhova´ topologie, jeden uzel v kruhu je prima´rnı´) a sı´t’s aktivnı´m rozbocˇovacˇem (v sı´ti je jeden prˇ´ıchozı´ a jeden odchozı´ kana´l, po odchozı´m komunikuje prima´rnı´ uzel se sekunda´rnı´mi, po prˇ´ıchozı´m sekunda´rnı´ komunikujı´ s prima´rnı´m uzlem).
67
P
4.1
SPOJOVE´ PROTOKOLY
68
PDU se nazy´va´ ra´mec. Pouzˇ´ıvajı´ se trˇi typy ra´mcu˚: 1. I-frame (Information Frame, informacˇnı´, datovy´) – nese informace z vysˇsˇ´ı vrstvy a prˇ´ıpadneˇ rˇ´ıdicı´ informace, tyto ra´mce podporujı´ rˇazenı´, rˇ´ızenı´ toku, detekci chyb, zotavenı´. Urcˇenı´: prˇenos dat.
P
2. S-frame (Supervisory Frame, take´ sluzˇebnı´ cˇi dohlı´zˇecı´ ra´mec) – obsahuje rˇ´ıdicı´ informace, pouzˇ´ıva´n pro pozˇadavek zaha´jenı´ nebo ukoncˇenı´ spojenı´, hla´sˇenı´ o stavu, potvrzenı´ prˇijetı´ I-ra´mce. 3. U-frame (Unnumbered Frame, necˇ´ıslovany´) – pro rˇ´ıdicı´ informace (dohoda rezˇimu provozu), narozdı´l od prˇedchozı´ho nepodporujı´ cˇ´ıslova´nı´ ra´mcu˚ do posloupnosti, a mu˚zˇe take´ obsahovat data z vysˇsˇ´ı vrstvy. Obecneˇ: pro to, co se vejde do jedine´ho ra´mce. Pro data z vysˇsˇ´ıch vrstev se tedy pouzˇ´ıva´ prˇedevsˇ´ım I-frame. 1 oktet
Flag
1-2
2
Adresa
ˇ ´ızenı´ R
prom. de´lka
2
1
Data
FCS
Flag
P PP PP 8 bitu˚
1
PP PP P 8
Send Sequence Number
PP1 P
Rˇ´ızenı´ pro I-frame:
Receive Sequence Number
P F bit
Rˇ´ızenı´ pro S-frame:
Receive Sequence Number
P F bit
ˇ ´ıdicı´ R informace
0
1
Rˇ´ızenı´ pro U-frame:
ˇ ´ıdicı´ R informace
P F bit
ˇ ´ıdicı´ R informace
1
1
0
Obra´zek 4.1: Forma´t SDLC a HDLC ra´mce Forma´t SDLC a HDLC ra´mce se lisˇ´ı podle jeho typu. Jednotliva´ pole: 1. prˇ´ıznak (flag) na zacˇa´tku ra´mce ma´ vzˇdy hodnotu 01111110 (bina´rneˇ), slouzˇ´ı k rozlisˇenı´ zacˇa´tku a konce ra´mce (je i na konci ra´mce), 2. adresa – adresa sekunda´rnı´ho uzlu (mu˚zˇe by´t take´ skupinova´ nebo broadcast), 3. rˇ´ıdicı´ pole (1 nebo 2 B), jeho obsah je odlisˇny´ u ru˚zny´ch typu˚ ra´mcu˚, forma´t pole pro ru˚zne´ typy ra´mcu˚ probereme o neˇco da´le, 4. data (promeˇnna´ de´lka), 5. FCS (kontrolnı´ soucˇet ra´mce) vytvorˇeny´ polynomia´lnı´m ko´dem, toto pole mu˚zˇe mı´t u HDLC i 32 bitu˚, 6. prˇ´ıznak (flag) na konci ra´mce (platı´ tote´zˇ co pro prˇ´ıznak na zacˇa´tku ra´mce).
P
SPOJOVE´ PROTOKOLY
4.1
69
Forma´t rˇ´ıdicı´ho pole (naznacˇen na obra´zku 4.1): • pro I-frame: – porˇadova´ cˇ´ısla – porˇadove´ cˇ´ıslo vysı´lane´ho ra´mce (tj. tohoto) a da´le porˇadove´ cˇ´ıslo ocˇeka´vane´ho ra´mce od protistrany, – P/F bit (poll/final) – kdyzˇ je nastaven na 1, prima´rnı´ uzel da´va´ naveˇdomı´ sekunda´rnı´mu, zˇe vyzˇaduje okamzˇitou odpoveˇd’, sekunda´rnı´ zase prima´rnı´mu, zˇe tento ra´mec je poslednı´ ze zası´lany´ch ra´mcu˚ • pro S-frame: kromeˇ porˇadovy´ch cˇ´ısel take´ rˇ´ıdicı´ informace (potvrzenı´ prˇijetı´ I-ra´mce, ozna´menı´ stavu sı´teˇ, vyzˇa´da´nı´ nebo ukoncˇenı´ prˇenosu, atd., nema´ datovou cˇa´st • pro U-frame: neobsahujı´ porˇadova´ cˇ´ısla, jen rˇ´ıdicı´ informaci, tento ra´mec mu˚zˇe by´t pouzˇ´ıva´n pro inicializaci sekunda´rnı´ch uzlu˚, podobne´ funkce jako S-frame HDLC podporuje synchronnı´ komunikaci s plny´m duplexem. V HDLC existuje neˇkolik prˇenosovy´ch rezˇimu˚: 1. norma´lnı´ rezˇim odpoveˇdi (NRM, normal response mode) – deˇdı´ od SDLC, sekunda´rnı´ stanice musı´ pocˇkat na vyzva´nı´ od prima´rnı´, aby mohla komunikovat,
P
2. asynchronnı´ rezˇim odpoveˇdi (ARM, asynchronous response mode) – sekunda´rnı´ stanice mu˚zˇe zacˇ´ıt komunikovat s prima´rnı´ bez povolenı´, 3. asynchronnı´ vyva´zˇeny´ rezˇim (ABM, asynchronous balanced mode) – uzly jsou kombinovane´ (schopne´ pracovat jako prima´rnı´ i sekunda´rnı´), kazˇda´ stanice mu˚zˇe zacˇ´ıt komunikovat bez povolenı´, prima´rnı´ uzel je obvykle ten, ktery´ zahajuje komunikaci.
4.1.2
LAP protokoly
LAP (Link Access Procedure) je skupina spojovy´ch protokolu˚, ktere´ jsou do znacˇne´ mı´ry podobne´ protokolu˚m SDLC a HDLC s urcˇity´mi odlisˇnostmi, prˇedevsˇ´ım v podporovany´ch prˇenosovy´ch rezˇimech. LAPB (Link Access Procedure Balanced) je pouzˇ´ıva´n v sı´tı´ch X.25. Je typicky´ pro point-to-point spojenı´ s prˇenosovy´m rezˇimem ABM (asynchronnı´ vyva´zˇeny´). Rozlisˇujı´ se take´ stejne´ typy ra´mcu˚ jako u HDLC. Forma´t ra´mce je prakticky shodny´ s forma´tem ra´mce HDLC, ale v druhe´m poli (tam, kde HDLC ukla´da´ adresu) nemusı´ by´t ulozˇena adresa (veˇtsˇinou nenı´ potrˇeba, protozˇe LAPB pracuje jen na point-to-point spojı´ch). Komunikace je (stejneˇ jako u jiny´ch protokolu˚ tohoto typu) rˇ´ızena povely. Existuje vı´ce ru˚zny´ch povelu˚, naprˇ´ıklad SABM (zaha´jenı´ komunikace), UA (prˇijetı´ komunikace druhy´m uzlem), DM (odmı´tnutı´ komunikace), REJ (zˇa´dost o opakova´nı´ prˇenosu ra´mce, dosˇlo k chybeˇ prˇi prˇenosu), RR (prˇ´ıjem), RNR (prˇenos bude ukoncˇen, zˇa´dost o potvrzenı´ dosud odeslany´ch ra´mcu˚), DISC (rozpojenı´, komunikace je ukoncˇena, zası´la´ prima´rnı´ stanice), atd. LAPD (Link Access Protocol, Channel D) byl pu˚vodneˇ specifikova´n pro ISDN, kana´l D. Je hodneˇ podobny´ protokolu LAPB, take´ pracuje v asynchronnı´m vyva´zˇene´m rezˇimu. Odlisˇnost je v adresove´m poli ra´mce – obsahuje
P
P
SPOJOVE´ PROTOKOLY
4.1
• • • •
70
C/R bit (command/response) – rozlisˇuje, zda jde o prˇ´ıkaz nebo odpoveˇd’ identifika´tor prˇ´ıstupove´ho bodu na vysˇsˇ´ı vrstvu (SAPI, 6 bitu˚) identifika´tor koncove´ho zarˇ´ızenı´ (7 bitu˚) dva prˇ´ıdavne´ bity, v kazˇde´m oktetu jeden
LAPF (Link Access Procedure – Frame) vycha´zı´ z LAPD a prˇejı´ma´ veˇtsˇinu jeho vlastnostı´, ma´ me´neˇ funkcı´. Pouzˇ´ıva´ se v sı´tı´ch Frame Relay. Adresove´ pole ma´ 2 oktety (mu˚zˇe by´t rozsˇ´ırˇeno azˇ na 4) a zcela zmeˇneˇnou strukturu, rˇ´ıdicı´ pole bylo vyrˇazeno. V adresove´m poli je ulozˇeno DLCI, a da´le bity pro rˇ´ızenı´ toku dat a kontrolu chyb (BECN, FECN, DE apod.), podrobneˇji da´le v te´to kapitole (v sekci o Frame Relay).
4.1.3
SLIP
SLIP (Serial Line Internet Protocol) je urcˇen pouze pro prˇenos IP datagramu˚ (nenese informaci o typu protokolu, proto nelze prˇena´sˇet nic jine´ho). Je to stary´ protokol urcˇeny´ pro zajisˇteˇnı´ vyta´cˇene´ho prˇipojenı´ se se´riovy´m rozhranı´m prˇipojeny´m na modem. Nedoka´zˇe detekovat chyby, nezvla´da´ synchronnı´ prˇenosy, nedostatecˇna´ komprese, dalsˇ´ı nevy´hodou je nutnost specifikace IP adresy prˇi kazˇde´m znovu-nava´za´nı´ spojenı´ (pokud nema´me statickou IP adresu).
P
Dnes se jizˇ nepouzˇ´ıva´, byl nahrazen protokolem PPP.
4.1.4
PPP
PPP (Point-to-Point Protocol) je dvoubodovy´ (point-to-point). Nerozlisˇuje prima´rnı´ a sekunda´rnı´ uzly (navazovat spojenı´ mu˚zˇe ktery´koliv uzel), podporuje synchronnı´ i asynchronnı´ prˇenos. Narozdı´l od SLIP doka´zˇe prova´deˇt automatickou konfiguraci prˇi navazova´nı´ spojenı´, prˇicˇemzˇ se testuje kvalita spoje. Soucˇa´stı´ ra´mce je i urcˇenı´ protokolu vysˇsˇ´ı vrstvy, proto doka´zˇe nejen zapouzdrˇovat IP datagramy, ale i jine´ typy paketu˚ vysˇsˇ´ı vrstvy. PPP se skla´da´ ze dvou cˇa´stı´ (prˇesneˇji – obsahuje dveˇ vrstvy): • protokoly rˇ´ızenı´ sı´teˇ (NCP, Network Control Protocol) – protokoly zajisˇt’ujı´cı´ komunikaci s vysˇsˇ´ı vrstvou; existuje vı´ce teˇchto protokolu˚ pro ru˚zne´ sı´t’ove´ architektury (TCP/IP, NetWare, AppleTalk apod.), tato vrstva zasahuje cˇa´stecˇneˇ i do sı´t’ove´ vrstvy v ISO/OSI modelu,
P P
• protokol rˇ´ızenı´ spoje (LCP, Link Control Protocol) – navazova´nı´ a udrzˇova´nı´ spojenı´, dohodnutı´ konfigurace na zacˇa´tku spojenı´ (negociace), mu˚zˇe zajisˇt’ovat take´ testova´nı´ spoje a autentizaci. ´ cˇelem je maxima´lneˇ omezit mnozˇstvı´ funkcı´ vlastnı´ho spojove´ho protokolu (tj. LCP) a takto U zefektivnit jeho fungova´nı´. Autentizace je volitelnou vlastnostı´, lze ji prova´deˇt neˇktery´m z teˇchto protokolu˚: • PAP (Password Authentication Protocol) – textove´ heslo se posı´la´ po spoji, tedy nejde o bezpecˇnou metodu autentizace • CHAP (Challenge Handshake Authentication Protocol) – pouzˇ´ıva´ se asymetricka´ sˇifra (klı´cˇ), iniciujı´cı´ stanice odesˇle zˇa´dost, obdrzˇ´ı na´hodneˇ vygenerovanou sekvenci znaku˚, kterou zpracuje pomocı´ tajne´ho klı´cˇe a odesˇle zpeˇt, po oveˇrˇenı´ prˇ´ıjemcem mu˚zˇe zacˇ´ıt komunikace
P
SPOJOVE´ PROTOKOLY
4.1
71
• EAP (Extensible Authentication Protocol) – zcela oddeˇluje fa´zi navazova´nı´ spojenı´ od fa´ze autentizace, samotna´ autentizace mu˚zˇe probı´hat trˇemi ru˚zny´mi zpu˚soby: 1. MD5 (funguje podobneˇ jako CHAP, take´ pomocı´ klı´cˇe), 2. heslo na jedno pouzˇitı´, 3. token card. PPP take´ podporuje sˇifrova´nı´ a komprimaci. Ra´mec protokolu PPP je do znacˇne´ mı´ry podobny´ prˇedchozı´m: • prˇ´ıznak (opeˇt bina´rneˇ 01111110) • adresa (1 B) – toto pole existuje, ale ma´ vzˇdy konstantnı´ hodnotu (bina´rneˇ same´ 1) • rˇ´ıdicı´ pole (1 B) – obsahuje vzˇdy hodnotu 0000011 (indikuje necˇ´ıslovany´ ra´mec ve sluzˇbeˇ bez spojenı´) • protokol (2 B, toto pole se u jiny´ch protokolu˚ nevyskytuje) – obsahuje identifikaci protokolu vysˇsˇ´ı vrstvy (naprˇ´ıklad pro IPv4 je to 0×0021, pro IPv6 0×0057, pro IPX je zde 0×002B), k nalezenı´ v RFC dokumentech • data – maxima´lneˇ 1500 B • FCS • prˇ´ıznak To byl ra´mec obsahujı´cı´ data pro prˇenos. Pouzˇ´ıvajı´ se take´ sluzˇebnı´ LCP pakety, ktere´ je trˇeba zapouzdrˇit do PPP ra´mce na´sledovneˇ: • v poli protokolu je hodnota 0×C021 • v poli data je samotny´ LCP paket obsahujı´cı´ tyto informace:
P
– ko´d – identifikuje funkci LCP paketu (pozˇadavky na zmeˇnu parametru˚, potvrzenı´ prˇijetı´ pozˇadavku˚ na zmeˇnu, odmı´tnutı´ pozˇadavku˚, ukoncˇenı´ spojenı´, atd.) – identifika´tor – u prˇ´ıkazove´ho paketu obsahuje na´hodneˇ vygenerovanou hodnotu, u odpoveˇdi musı´ obsahovat tute´zˇ hodnotu jako paket s prˇ´ıkazem, na ktery´ odpovı´da´ – de´lka cele´ho LCP paketu v oktetech – data – obvykle posloupnost usporˇa´dany´ch dvojic (volba,hodnota), naprˇ´ıklad typ autentizacˇnı´ho protokolu, vysˇsˇ´ı max. de´lka dat, atd.
4.1.5
Rozsˇı´rˇenı´ PPP
Pro rozsˇ´ırˇenı´ protokolu PPP platı´ vpodstateˇ tote´zˇ co pro PPP (vrstva L2, prˇiblizˇneˇ u´cˇel, sˇifrova´nı´, veˇtsˇinou i forma´t ra´mce). Tato rozsˇ´ırˇenı´ jsou navı´c prˇizpu˚sobena konkre´tnı´mu zpu˚sobu vyuzˇitı´. Multilink PPP (PPP po vı´ce spojı´ch, take´ se oznacˇuje MP, MPPP, MLP; RFC 1990) je varianta PPP pro vı´cebodove´ spoje. Nenı´ tı´m mı´neˇno ani tak vı´ce uzlu˚, jako spı´sˇe vı´ce se´riovy´ch spoju˚ pro jedinou komunikaci. Lze zkombinovat vı´ce se´riovy´ch spoju˚ do jedine´ho logicke´ho kana´lu s vysˇsˇ´ı propustnostı´ (agregace), protokol doka´zˇe data rozdeˇlit, vhodneˇ prˇeusporˇa´dat a pak na druhe´m konci linky opeˇt uve´st do pu˚vodnı´ho stavu.
P
4.2
X.25
72
Tunneling PPP (PPTP, Point-to-point Tunneling Protocol, RFC 1171) je urcˇen pro virtua´lnı´ priva´tnı´ sı´teˇ a k prˇipojenı´ vzda´lene´ho klienta k firemnı´ sı´ti (obecneˇ LAN). Ovsˇem dnes je podporova´n prakticky uzˇ jen ve Windows a jeho podpora se bude omezovat i zde, doporucˇuje se prˇechod na jeho na´sledovnı´ka L2TP (Layer 2 Tunneling Protocol, RFC 3931).
P
L2TP: Do ra´mce protokolu L2TP se zapouzdrˇujı´ ra´mce PPP. Sa´m o sobeˇ nema´ tento protokol zabezpecˇovacı´ funkce, proto se cˇasto kombinuje se zabezpecˇenı´m pomocı´ IPSec nebo jiny´ch metod, viz kapitolu 8.4.2 o GRE a L2TP tunelech na str. 184. Wireless PPP
(W-PPP, bezdra´tovy´ PPP, RFC 2153) je varianta PPP pro bezdra´tove´ sı´teˇ.
Prˇipojenı´ k Internetu se rˇesˇ´ı napojenı´m PPP (iniciacˇnı´ fa´ze prˇipojenı´) na protokoly WAN. Vyuzˇ´ıva´ se take´ v technologiı´ch DSL pro prˇenos prˇes WAN poskytovatele, a to v teˇchto varianta´ch:
P
• PPPoA (PPP over ATM, RFC 2364) – PPP paket je zapouzdrˇen do ATM bunˇky • PPPoE (PPP over Ethernet, RFC 2516) – PPP paket je zapouzdrˇen do Ethernetove´ho ra´mce, dnes beˇzˇne´ Tyto varianty umozˇnˇujı´ nava´zat autentizovane´ spojenı´ s ISP a dynamicky zı´skat IP adresu. Jsou potrˇeba u typu˚ komunikace, kde se navazuje spojenı´, nevyuzˇ´ıvajı´ se u trvale´ho prˇipojenı´ k Internetu (resp. vyuzˇ´ıvajı´ se tehdy, kdyzˇ se navazuje spojenı´; kdyzˇ uzˇ je nava´za´no, nejsou potrˇeba).
4.1.6
IEEE 802.2 (LLC)
Standard IEEE 802.2 definuje podvrstvu LLC (Logical Link Control) na vrstveˇ L2. LLC je urcˇen pro point-to-point spoje, pracuje v asynchronnı´m vyva´zˇene´m rezˇimu (ABM). Opeˇt se rozlisˇujı´ trˇi typy ra´mcu˚ – I-frame, S-frame a U-frame. Forma´t ra´mce je podobny´ jako u HDLC, ale celkoveˇ jednodusˇsˇ´ı, protozˇe LLC ra´mec se vzˇdy zapouzdrˇuje do MAC ra´mce a tedy neˇktera´ pole majı´ jiny´ vy´znam. Pouzˇ´ıva´ se jina´ adresace (prˇ´ıstupove´ body sluzˇeb).
P
LLC nabı´zı´ trˇi typy sluzˇeb: • nepotvrzovana´ sluzˇba bez spojenı´ (typ 1) – nejpouzˇ´ıvaneˇjsˇ´ı, funguje podobneˇ jako dorucˇova´nı´ datagramu˚ (paket je vybaven vsˇemi dostupny´mi informacemi vcˇetneˇ adres zdroje a cı´le a porˇadı´ paketu ve zpra´veˇ), zˇa´dne´ osˇetrˇenı´ chyb, v tomto ohledu spole´ha´ na protokoly vysˇsˇ´ıch vrstev, • sluzˇba se spojenı´m (typ 2) – pro virtua´lnı´ okruhy, zahrnuje nava´za´nı´ spojenı´, potvrzova´nı´ po dorucˇenı´ omezene´ skupiny paketu˚, atd., pouze prvnı´ paket obsahuje informace o adresa´ch, • potvrzovana´ sluzˇba bez spojenı´ (typ 3) – pakety jsou po skupina´ch potvrzova´ny, tato sluzˇba je jen ma´lo vyuzˇ´ıvana´. Koncove´ stanice podporujı´ vzˇdy nejme´neˇ typ 1, a pak obvykle jesˇteˇ jednu ze zby´vajı´cı´ch sluzˇeb.
4.2
X.25
Sı´t’ X.25 je normalizova´na pu˚vodnı´m CCITT (v ra´mci ITU) postupneˇ v neˇkolika verzı´ch, verze z roku 1984 byla prˇedlohou pro ISO 8208. Z na´vrhu je zrˇejme´, zˇe X.25 vznikala v dobeˇ, kdy nebylo
4.2
X.25
73
zvykem pouzˇ´ıvat vrstvene´ architektury, azˇ postupneˇ bylo doporucˇenı´ prˇizpu˚sobova´no modelu ISO/OSI (poslednı´ verze jizˇ ISO/OSI odpovı´daly). X.25 implementuje trˇi vrstvy – fyzickou, linkovou a sı´t’ovou, s du˚razem na sı´t’ovou vrstvu. Komunikace probı´ha´ na okruzı´ch (pevny´ch a prˇepı´nany´ch virtua´lnı´ch okruzı´ch), je to sı´t’s prˇepı´na´nı´m paketu˚. Hlavnı´ a nejdu˚lezˇiteˇjsˇ´ı vlastnostı´ X.25 je extre´mnı´ spolehlivost – vyznacˇuje se prˇemı´rou kontrolnı´ch mechanismu˚, ktere´ dnes zateˇzˇujı´ sı´t’ovou komunikaci, ale na me´neˇ spolehlivy´ch spojı´ch jsou uzˇitecˇne´. Z toho ovsˇem vyply´va´ mala´ propustnost sı´teˇ (nı´zka´ rychlost). V minulosti se pouzˇ´ıvala pro verˇejne´ datove´ sı´teˇ (PDN – Public Data Network), v soucˇasnosti se s nı´ setka´me spı´sˇe v rozvojovy´ch zemı´ch (protozˇe je vhodna´ pro me´neˇ spolehlive´ spoje). Pro svou enormnı´ spolehlivost se s X.25 mu˚zˇeme i u na´s setkat na bezpecˇnostneˇ kriticky´ch spojı´ch, naprˇ´ıklad u prˇipojenı´ platebnı´ch termina´lu˚ a bankomatu˚.
4.2.1
Zarˇı´zenı´ v sı´ti
V sı´ti X.25 jsou rozlisˇova´na tato zarˇ´ızenı´: 1. DTE (Data Terminal Equipment) – pocˇ´ıtacˇe, servery, termina´ly, atd., jde o zarˇ´ızenı´ obvykle umı´steˇna´ v provozovna´ch prˇedplatitelu˚ 2. DCE (Data Circuit-terminating Equipment) – komunikacˇnı´ zarˇ´ızenı´ (modemy, prˇepı´nacˇe apod.), zajisˇt’ujı´ prˇipojenı´ DTE k PSE, jsou v rezˇii prˇepravce 3. PSE (Packet Switching Exchange) – komunikacˇnı´ zarˇ´ızenı´ (veˇtsˇinou prˇepı´nacˇe) v sı´ti prˇepravce 4. PAD (packet assembler/disassembler) – rozhranı´ pro velmi jednoducha´ zarˇ´ızenı´ (naprˇ. termina´ly), ktera´ nezvla´dajı´ protokoly X.25; poskytujı´ vyrovna´vacı´ pameˇt’a prova´deˇjı´ sestavova´nı´ paketu prˇi odesı´la´nı´ a rozebı´ra´nı´ paketu˚ prˇi prˇijı´ma´nı´ dat Z pohledu za´kaznı´ka (uzˇivatele sı´teˇ) jsou nejdu˚lezˇiteˇjsˇ´ı zarˇ´ızenı´ DTE (obvykle ve vlastnictvı´ za´kaznı´ka nebo pronajate´ od telekomunikacˇnı´ spolecˇnosti) a DCE. V dalsˇ´ıch typech WAN sı´tı´, ktere´ budeme probı´rat, zarˇ´ızenı´ DCE a PSE sply´vajı´ v jeden typ (DCE). Relace (session, sezenı´) je spojenı´ mezi dveˇma DTE. Komunikace mezi DTE prˇes sı´t’probı´ha´ po vytvorˇenı´ relace v plne´m duplexu. Ktere´koliv z obou zarˇ´ızenı´ mu˚zˇe relaci ukoncˇit.
4.2.2
Adresy a nava´za´nı´ spojenı´
Adresy okruhu ˚ podle X.121: Jedna´ se o adresy (pouze unicast) pouzˇ´ıvane´ prˇi vytva´rˇenı´ prˇepı´nane´ho virtua´lnı´ho okruhu. Je cˇ´ıselna´ (obdoba telefonnı´ho cˇ´ısla) a skla´da´ se z teˇchto cˇa´stı´: • DNIC (Data Network Identifier Code) – identifikace datove´ sı´teˇ, skla´da´ se ze – zo´na (1 cˇ´ıslice), pro Evropu je to 2 – zemeˇ (2 cˇ´ıslice), pro CˇR platı´ 30 – sı´t’(1 cˇ´ıslice)
4.2
'$
X.25
74
&%
. . . DCE . . . PSE
. . . DTE
Obra´zek 4.2: Sı´t’X.25
pro neˇkterou sı´t’v CˇR by platilo 230x, kde za x by se dosadilo cˇ´ıslo konkre´tnı´ sı´teˇ • NTN (National Terminal Number) – azˇ 10 cˇ´ıslic, urcˇuje konkre´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
Obra´zek 4.3: Sche´ma pru˚beˇhu komunikace v X.25
4.2.3
Vrstvy a protokoly
Vztah protokolu˚ X.25 k vrstva´m modelu ISO/OSI je naznacˇen v tabulce 4.1. Specifikace X.25 je starsˇ´ı nezˇ model ISO/OSI, proto se v neˇktery´ch detailech od neˇho odchyluje (pu˚vodnı´ verze jesˇteˇ mnohem vı´ce), kromeˇ jine´ho v odlisˇne´m na´zvoslovı´. Naprˇ´ıklad vrstva, ktera´ je v ISO/OSI oznacˇena jako sı´t’ova´, je u X.25 nazy´va´na paketova´.
4.3
FRAME RELAY
75
PLP (Packet Layer Protocol) je protokol sı´t’ove´ vrstvy. PLP pakety nesou data, povely, odpoveˇdi a identifikace. Specia´lnı´ typy paketu˚ slouzˇ´ı k teˇmto u´cˇelu˚m: • vytva´rˇenı´ a rusˇenı´ SVC okruhu (nepouzˇ´ıva´ se u PVC) • rˇesˇenı´ poruch a vy´jimecˇny´ch situacı´ – prˇerusˇenı´ (kdyzˇ nedorazı´ potvrzenı´ paketu˚ a povolenı´ vyslat dalsˇ´ı), obnova (prˇedchozı´ nepomu˚zˇe – vycˇistı´ cestu od paketu˚), restart (vsˇechny SVC zrusˇ´ı, vsˇechny PVC obnovı´) PLP tedy pracuje vzˇdy v jednom z teˇchto mo´du˚: nava´za´nı´ spojenı´ (pro SVC), prˇenos dat, idle (necˇinny´ u SVC), obnova, restart. V za´hlavı´ PLP paketu najdeme kromeˇ jine´ho urcˇenı´ typu komunikacˇnı´ho kana´lu a jeho cˇ´ıslo, velikost Sliding Window (pocˇet paketu˚, po jejichzˇ dorucˇenı´ je trˇeba pokazˇde´ potvrdit prˇ´ıjem), atd. Protokol LAPB (Link Access Procedure, Balanced)
byl popsa´n vy´sˇe.
Protokol fyzicke´ vrstvy je specifikova´n v doporucˇenı´ X.21. Definuje elektricke´ a mechanicke´ vlastnosti me´dia. Prˇipojenı´ DTE mu˚zˇe by´t analogove´ s modemem nebo digita´lnı´. ISO/OSI Sı´t’ova´ Linkova´ Fyzicka´
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 pu˚vodneˇ vznikla v ra´mci specifikace ISDN, ale protozˇe se uka´zala dobra´ zˇivotaschopnost tohoto rˇesˇenı´, v r. 1989 se osamostatnila. Frame Relay je na´sledovnı´k X.25 se zmeˇnami – naprˇ´ıklad trochu me´neˇ zabezpecˇenı´ (negarantuje dorucˇenı´ ra´mce), nepracuje na sı´t’ove´ vrstveˇ, ale na linkove´, mı´sto prˇepı´na´nı´ paketu˚ jsou prˇepı´na´ny prˇ´ımo ra´mce. Obecneˇ platı´, zˇe typicky´m pouzˇitı´m Frame Relay je z principu propojova´nı´ loka´lnı´ch sı´tı´, implementace pa´terˇnı´ sı´teˇ. Pocˇ´ıta´ se s prˇenosem po kvalitnı´m a rychle´m vedenı´, tedy Frame Relay poskytuje sice sluzˇbu se spojenı´m, ale nespolehlivou (poskytuje detekci chyb, ale bez mozˇnosti opravy).
4.3.1
Zarˇı´zenı´ v sı´ti
V sı´ti Frame Relay se nacha´zejı´ tato zarˇ´ızenı´: • DTE (Data terminal equipment) – v provozovna´ch za´kaznı´ku˚, vlastnı´kem mu˚zˇe by´t za´kaznı´k (pocˇ´ıtacˇe, servery, termina´ly, smeˇrovacˇe, mosty) • DCE (Data circuit-terminating equipment) – poskytujı´ sluzˇby synchronizace a prˇepı´na´nı´ provozu (obvykle paketove´ prˇepı´nacˇe)
P
4.3
FRAME RELAY
76
'$
Pozor – take´ to, co je DCE v ra´mci loka´lnı´ sı´teˇ (naprˇ´ıklad Ethernetu, trˇeba smeˇrovacˇ), zde vystupuje jako DTE. DTE
DCE
DTE
DCE
&% DCE
DTE
DTE
Obra´zek 4.4: Zarˇ´ızenı´ v sı´ti Frame Relay
U obou existuje komponenta fyzicke´ vrstvy a komponenta linkove´ (spojove´) vrstvy. Na fyzicke´ jde veˇtsˇinou o neˇktere´ se´riove´ rozhranı´, na linkove´ pracuje protokol LAPF. Virtua´lnı´ okruhy ve Frame Relay fungujı´ podobneˇ jako u X.25, pouzˇ´ıvajı´ se SVC (prˇepı´nane´) a PVC (pevne´). Pro SVC se pouzˇ´ıvajı´ operace nava´za´nı´ spojenı´ (vytvorˇenı´ okruhu), prˇenos dat, Idle a ukoncˇenı´ spojenı´ (zrusˇenı´ okruhu). U PVC se pouzˇ´ıva´ jen operace prˇenosu dat a Idle. FRAD (Frame Relay Access Device, Frame Relay Assembler/Disassembler) je zarˇ´ızenı´, ktere´ slouzˇ´ı k prˇ´ıstupu do sı´teˇ Frame Relay. Mu˚zˇe to by´t bud’ samostatne´ zarˇ´ızenı´ (neˇco jako PAD v X.25), a nebo je to soucˇa´st smeˇrovacˇe, prˇes ktery´ je loka´lnı´ sı´t’prˇipojena do Frame Relay sı´teˇ (to je velmi obvykle´). FRAD je tedy prˇedstavitel DTE nebo je soucˇa´stı´ DTE.
4.3.2
P P
Garance informacˇnı´ho toku
Parametr CIR (Committed Information Rate, zarucˇeny´ informacˇnı´ tok) urcˇuje propustnost, kterou ma´ spoj zarucˇovat. Hodnota CIR je pro okruhy PVC dohodnuta mezi poskytovatelem (telekomunikacˇnı´ spolecˇnostı´) a uzˇivatelem (vlastnı´kem loka´lnı´ sı´teˇ, ktera´ ma´ by´t prˇipojena), pro okruhy SVC je dohodnuta prˇi navazova´nı´ spojenı´. Ra´mce posı´lane´ nad hodnotu CIR mohou by´t prˇi veˇtsˇ´ım zatı´zˇenı´ sı´teˇ zahazova´ny.
P
Pro uzˇivatele ma´ hodnota CIR tento vy´znam: • cˇ´ım vysˇsˇ´ı CIR, tı´m je sluzˇba drazˇsˇ´ı, • cˇ´ım mensˇ´ı CIR, tı´m veˇtsˇ´ı pravdeˇpodobnost zahazova´nı´ paketu˚ a potencia´lneˇ pomalejsˇ´ı prˇenos. Na´razovy´ informacˇnı´ tok (take´ EIR, Excess Information Rate) prˇedstavuje maxima´lnı´ informacˇnı´ tok, ktery´ doka´zˇe prˇenosova´ cesta zvla´dnout (prˇesneˇji to, co je navı´c nad CIR). Ra´mce zası´lane´ nad hodnotu CIR, ktere´ neprˇekracˇujı´ hranici EIR, jsou oznacˇeny jako vhodne´ k zahozenı´ (DE, Discard-Eligible). Jsou prˇeda´va´ny prˇepı´nacˇi Frame Relay (tj. do FR sı´teˇ) tak dlouho, dokud nenı´ k dispozici dostatecˇna´ sˇ´ırˇka pa´sma (dokud se nevejdou do CIR). Oznacˇenı´ ra´mce jako vhodne´ho k zahozenı´ obvykle neznamena´, zˇe ra´mec nebude dorucˇen, ale zˇe se jeho dorucˇenı´ mu˚zˇe (i dost hodneˇ) zdrzˇet. Na trhu se mu˚zˇeme setkat s nabı´dkami telekomunikacˇnı´ch opera´toru˚ na Frame Relay s CIR
$
L
4.3
FRAME RELAY
77
´ cˇelem je nabı´dnout co nejnizˇsˇ´ı cenu, cozˇ rovny´m 0, tj. zˇa´dny´ informacˇnı´ tok nenı´ garantova´n. U pro za´kaznı´ka nemusı´ by´t vzˇdy nejlepsˇ´ı rˇesˇenı´ (vsˇechny posı´lane´ ra´mce by byly oznacˇeny jako DE, vhodne´ k zahozenı´). Hodnota CIR pro pevne´ virtua´lnı´ okruhy by meˇla by´t soucˇa´stı´ smlouvy. Doporucˇuje se hodnota CIR alesponˇ na u´rovni 50 % celkove´ho informacˇnı´ho toku. SLA (Service Level Agreement) = dohoda o u´rovni poskytovany´ch sluzˇeb (tento pojem se pouzˇ´ıva´ obecneˇ u tohoto typu sluzˇeb, nejen pro Frame Relay). Jedna´ se o dohodu o parametrech sluzˇby, zde take´ zahrnuje CIR a EIR.
P
Situace na trhu (brˇezen 2012): • obvykle okruhy PVC, CIR=50%, EIR = 50% prˇ´ıstupove´ rychlosti (cena podle rychlosti) • u telekomunikacˇnı´ch firem uzˇ obvykle nenı´ v aktua´lnı´ nabı´dce, nahrazova´na sluzˇbou MPLS
4.3.3
Spojova´ vrstva a adresace
Na spojove´ vrstveˇ pracuje bitovy´ protokol LAPF, ktery´ byl jizˇ popsa´n vy´sˇe. Adresace v okruzı´ch na spojove´ vrstveˇ je zalozˇena na DLCI (Data Link Connection Identifier). Narozdı´l od X.25 nejde o adresu zarˇ´ızenı´, ale o identifikaci okruhu (prˇesneˇji identifikaci jednoho konce okruhu vedoucı´ho od neˇktere´ho DTE k prˇ´ıstupove´mu bodu sı´teˇ Frame Relay). Je to cˇ´ıslo, ktere´ zabı´ra´ veˇtsˇinou 10 bitu˚, take´ 16 nebo 23 bitu˚.
P
DLCI je vzˇdy jedinecˇne´ v ra´mci LAN, zˇa´dna´ dveˇ zakoncˇenı´ virtua´lnı´ch okruhu˚ u DTE v jedne´ LAN nemajı´ tote´zˇ DLCI. Hodnoty DLCI pro DTE v nasˇ´ı LAN zı´ska´me od poskytovatele sluzˇby Frame Relay (typicky telekomunikacˇnı´ spolecˇnost). V cele´ sı´ti WAN (propojujı´cı´ ru˚zne´ loka´lnı´ sı´teˇ) vsˇak mu˚zˇe existovat vı´ce okruhu˚ se stejny´m DLCI, k jednoznacˇne´ adresaci se prˇida´va´ jesˇteˇ oznacˇenı´ DTE na zacˇa´tku okruhu. Navı´c se hodnota DLCI prˇi pru˚chodu prˇes prˇepı´nacˇe meˇnı´, na kazˇde´m konci mı´va´ okruh jine´ DLCI. K mapova´nı´ vztahu IP adres zarˇ´ızenı´ v sı´ti k cˇ´ıslu˚m DLCI se pouzˇ´ıva´ protokol I-ARP (Inverse ARP), ktery´ je obdobou protokolu ARP v Ethernetu. Takto zjisˇteˇne´ dvojice adres a DLCI jsou dynamicke´ za´znamy, ale lze je take´ prˇida´vat napevno (staticky). Neˇktere´ DLCI jsou vyhrazeny pro u´cˇely signalizace stavu˚, proble´mu˚ apod., prˇedevsˇ´ım z rozsahu 0–16. Da´le rozmezı´ 1019–1022 je urcˇeno pro skupinove´ vysı´la´nı´. Do (datove´ho) ra´mce protokolu LAPF se zapouzdrˇuje IP datagram. Ra´mec obsahuje podobne´ informace jako ra´mec HDLC (obklopujı´cı´ synchronizacˇnı´ oktety, kontrolnı´ soucˇet, apod.), ale prostor rˇ´ıdicı´ho pole je „pohlcen“ adresovy´m polem, ktere´ zabı´ra´ 2–4 oktety. V takto rozsˇ´ırˇene´m adresove´m poli je prˇedevsˇ´ım DLCI, na ktery´ ma´ by´t ra´mec smeˇrova´n, a da´le rˇ´ıdicı´ bity: • C/R – command/response bit, urcˇuje, zda jde o prˇ´ıkaz (command) nebo odpoveˇd’ cˇi reakce na drˇ´ıve zaslany´ prˇ´ıkaz (response) • bit FECN (Forward-explicit congestion notification, doprˇedne´ ozna´menı´ o prˇetı´zˇenı´), DCE na cesteˇ oznamuje, zˇe tento ra´mec byl posla´n po prˇetı´zˇene´m spojenı´, a tedy DTE, ktere´ je cı´lem ra´mcu˚ komunikace, by meˇlo snı´zˇit frekvenci prˇ´ıjmu ra´mcu˚ (pokud tak doka´zˇe vysˇsˇ´ı vrstva reagovat)
P
4.3
FRAME RELAY
78
• bit BECN (Backward-explicit congestion notification, zpeˇtne´ ozna´menı´) – ozna´menı´ zdroji vysı´la´nı´ o prˇetı´zˇenı´ linky, zdrojove´ zarˇ´ızenı´ by meˇlo snı´zˇit objem vysı´la´nı´ • bit DE (Discard-Eligible) – v ra´mcı´ch, ktere´ mohou by´t prˇi prˇetı´zˇenı´ zahozeny Kdyzˇ DCE zjistı´ prˇetı´zˇenı´, nastavı´ v posı´lane´m ra´mci bit FECN. Takto prˇijı´majı´cı´ DTE zjistı´, zˇe na lince dosˇlo k zahlcenı´ spoje. Naopak kdyzˇ DCE prˇepı´na´ ra´mec s nastaveny´m FECN, v nejblizˇsˇ´ım ra´mci posı´lane´m v okruhu v opacˇne´m smeˇru nastavı´ bit BECN. Takto vysı´lajı´cı´ DTE zjistı´, zˇe na lince dosˇlo k zahlcenı´ spoje. V sı´ti Frame Relay nenı´ prova´deˇno prˇ´ımo rˇ´ızenı´ toku dat, to je ponecha´no na zarˇ´ızenı´ch DTE (ktera´ vlastneˇ nepatrˇ´ı do vnitrˇnı´ sı´teˇ Frame Relay). Na ozna´menı´ o prˇetı´zˇenı´ (bitem FECN nebo BECN) DTE mu˚zˇe reagovat spusˇteˇnı´m mechanismu rˇ´ızenı´ toku dat. CRC (kontrolnı´ soucˇet, resp. FCS – Frame Check Sequence) je pouzˇ´ıva´n pro kontrolu neporusˇenosti ra´mce. Vadny´ ra´mec je zahozen, linkova´ vrstva se uzˇ nestara´ o zˇa´dost o nove´ vysla´nı´ ra´mce (pouze kontrola chyb, ne na´prava), ale mohou to prove´st protokoly vysˇsˇ´ı vrstvy.
4.3.4
LMI
LMI (Local Management Interface) je rozsˇ´ırˇenı´ za´kladnı´ specifikace pro Frame Relay.1 Protokol LMI slouzˇ´ı ke komunikaci mezi zarˇ´ızenı´m DTE a DCE, prˇedstavuje tedy rozhranı´ mezi loka´lnı´ sı´tı´ a sı´tı´ Frame Relay.
P
Zpra´vy protokolu LMI jsou posı´la´ny vzˇdy po okruhu PVC k tomuto u´cˇelu urcˇene´m. LMI prˇinesl neˇkolik vylepsˇenı´ pu˚vodnı´ho rozhranı´, prˇedevsˇ´ım: • globa´lnı´ adresace – identifika´tor DLCI je nejen loka´lneˇ, ale i globa´lneˇ unika´tnı´, • zpra´vy o stavu virtua´lnı´ho okruhu – u PVC okruhu˚ mezi DTE a DCE jsou pravidelneˇ zası´la´ny zpra´vy o stavu okruhu, u´cˇelem je zamezit zbytecˇny´m ztra´ta´m ra´mcu˚ posı´lany´ch na jizˇ neexistujı´cı´ okruhy, • multicasting – umozˇnˇuje definovat skupiny DTE, sˇetrˇ´ı prˇenosove´ cesty. Existujı´ trˇi LMI protokoly, typ pouzˇite´ho protokolu obvykle urcˇuje DCE: 1. cisco 2. ansi (Annex D) 3. q933a (Annex A) Prvnı´ pouzˇ´ıva´ pro signalizaci DLCI 1023, dalsˇ´ı dveˇ pouzˇ´ıvajı´ DLCI 0. Tedy po spojenı´ jsou prˇena´sˇeny bud’ datove´ ra´mce s DLCI podle cı´le, a nebo sluzˇebnı´ LMI ra´mce (obvykle jeden ze dvou typu˚ zpra´vy – dotaz na stav sı´teˇ smeˇrˇujı´cı´ od za´kaznı´ka nebo stav sı´teˇ od DCE). Ra´mec LMI
Ra´mce v sı´ti podle rozsˇ´ırˇenı´ LMI majı´ zcela odlisˇnou strukturu:
• Flag • LMI DLCI – identifikuje LMI ra´mec, je nastavena na hodnotu 1023 (na 2 B, resp. 6 bitu˚, pak 2 bity pro prˇ´ıznaky, v dalsˇ´ım 4 bity DLCI, zbytek opeˇt prˇ´ıznaky) 1
V roce 1990 publikovaly LMI spolecˇ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 – opeˇt hodnota typicka´ pro LMI (17) Call Reference – nastavena vzˇdy na 0 Message Type – podle smeˇru bud’ Status-inquiry (dotaz na stav sı´teˇ od za´kaznı´ka) nebo Status (stav sı´teˇ) • Information Elements – je zde typ elementu, de´lka a samotna´ data • FCS, Flag
4.3.5
Tabulky na zarˇı´zenı´ch
Na jednotlivy´ch zarˇ´ızenı´ch jsou ra´mce prˇepı´na´ny podle prˇepı´nacı´ch tabulek. Uvnitrˇ FR sı´teˇ najdeme FR switche (to jsou DCE), jejich tabulka je vcelku jednoducha´, jak vidı´me na obra´zku 4.5 (prˇ´ıpadneˇ by byl jesˇteˇ dalsˇ´ı sloupec – informace o tom, zda je dana´ cesta aktivnı´). Prˇijato z IN_Port IN_DLCI P0 P0
100 150
Prˇepnout na OUT_Port OUT_DLCI P1 P2
200 300
P0
-
150 100
P2 FR switch 300 P1 -
.. .
200 Obra´zek 4.5: Uka´zka jednoduche´ prˇepı´nacı´ tabulky Frame Relay switche
Dı´ky jednoduchosti mechanismu je prˇepı´na´nı´ velmi rychle´. Na hranici sı´teˇ jsou zarˇ´ızenı´, ktera´ na jedne´ straneˇ komunikujı´ se zarˇ´ızenı´mi loka´lnı´ sı´teˇ za´kaznı´ka, na druhe´ straneˇ komunikujı´ s FR switchi. Tato zarˇ´ızenı´ (FR routery – v roli DTE) obsahujı´ dveˇ tabulky: • smeˇrovacı´ tabulku urcˇujı´cı´, kam se ra´mec smeˇrˇujı´cı´ do sı´teˇ s danou IP adresou ma´ poslat, • tabulku mapova´nı´ DLCI. Obsah a vy´znam obou tabulek vidı´me na obra´zku 4.6. Na trˇetı´ vrstveˇ je paket nasmeˇrova´n na dany´ DCE (na druhe´ straneˇ FR sı´teˇ) a prˇ´ıslusˇne´ rozhranı´, na druhe´ vrstveˇ je nastaveno DLCI (FR switche uvnitrˇ FR sı´teˇ vidı´ jen na druhou vrstvu).
4.3.6
ˇ esˇenı´ R
Verˇejne´ FR sı´teˇ jsou provozova´ny poskytovatelem telekomunikacˇnı´ch sluzˇeb. DCE jsou ve vlastnictvı´ poskytovatele telekomunikacˇnı´ch sluzˇeb, DTE jsou veˇtsˇinou ve vlastnictvı´ za´kaznı´ka, a nebo mohou by´t za´kaznı´kovi pronajı´ma´ny poskytovatelem telekomunikacˇnı´ch sluzˇeb (mu˚zˇe to by´t trˇeba i smeˇrovacˇ). Za´kaznı´kovi je u´cˇtova´no pouzˇ´ıva´nı´ spojenı´, administrace a u´drzˇba jsou na straneˇ 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ı´teˇ 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
Obra´zek 4.6: Smeˇrova´nı´ na FR routeru (DTE), paket prˇicha´zı´ do FR sı´teˇ Pokud chce organizace vyuzˇ´ıt nabı´dky telekomunikacˇnı´ho opera´tora a propojit sve´ pobocˇky pomocı´ Frame Relay (i mezina´rodneˇ), potrˇebuje obvykle v kazˇde´ pobocˇce nejme´neˇ jeden (veˇtsˇinou) smeˇrovacˇ podporujı´cı´ protokol Frame Relay (tento parametr zjistı´me u prodejce), a samozrˇejmeˇ smlouvu s poskytovatelem. Smeˇrovacˇ pak vede tabulku s hodnotami DLCI pro ru˚zne´ komunikujı´cı´ smeˇrovacˇe z jiny´ch pobocˇek a take´ dalsˇ´ı DLCI s jiny´m vy´znamem (viz podsekci o LMI), smeˇruje podle hodnot DLCI. V sı´ti telekomunikacˇnı´ho opera´tora fungujı´ obvykle prˇepı´nacˇe Frame Relay, ktere´ mohou pracovat nad jinou sı´tı´ (ATM, SDH apod.). Soukrome´ firemnı´ sı´teˇ se vyznacˇujı´ tı´m, zˇe jsou zde vsˇechny prvky sı´teˇ vlastneˇny za´kaznı´kem ´ cˇtova´nı´ se prova´dı´ pouze interneˇ prˇi sledova´nı´ sı´teˇ, administrace (zde firma provozujı´cı´ sı´t’). U a u´drzˇba jsou takte´zˇ na straneˇ firmy.
$
P
Produkty podporujı´cı´ Frame Relay se samozrˇejmeˇ sha´neˇjı´ hu˚rˇe nezˇ beˇzˇne´ smeˇrovacˇe, obvykle se lze setkat s produkty velky´ch firem (Cisco, HP, apod.). Dalsˇı´ 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’ sˇiroce pouzˇ´ıvana´ na telekomunikacˇnı´ch sı´tı´ch. ´ cˇelem je co nejefektivneˇji prˇena´sˇet ru˚zne´ typy dat pra´veˇ po telekomunikacˇnı´ sı´ti. Vyznacˇuje se U vysokou efektivnostı´ (i rychlostı´) prˇenosu a jde prˇedevsˇ´ım o to najı´t kompromis mezi rˇesˇenı´mi pro telekomunikacˇnı´ a rˇesˇenı´mi pro pocˇ´ıtacˇove´ sı´teˇ. Normalizacı´ se zaby´va´ ITU-T, spolupracuje s vy´robci sdruzˇeny´mi ve Fo´ru ATM. Telekomunikacˇnı´ sı´teˇ
Pocˇ´ıtacˇove´ sı´teˇ
prˇepojova´nı´ okruhu˚ mnoho funkcı´ vcˇetneˇ rˇ´ızenı´ chyb spolehliva´ sluzˇba spojovana´ sluzˇba synchronnı´ rezˇim (STM)
veˇtsˇinou prˇepojova´nı´ paketu˚ spı´sˇe samotny´ prˇenos nespolehliva´ sluzˇba, best effort spojovana´ i nespojovana´ ru˚zne´
P
Tabulka 4.2: Porovna´nı´ vlastnostı´ telekomunikacˇnı´ch a pocˇ´ıtacˇovy´ch sı´tı´ „Asynchronnı´“ v na´zvu neznamena´ asynchronnı´ prˇenos, ale nepravidelne´ zası´la´nı´ „plny´ch“ buneˇk na cesteˇ, bunˇky jsou obsazova´ny daty podle potrˇeby, ne podle algoritmu. ATM pracuje na principu komunikace se spojenı´m, nespolehliva´ sluzˇba (tj. bez ozna´menı´ chyb), na plne´m duplexu (ve skutecˇnosti dva simplexy), v statisticke´m multiplexu. Du˚lezˇitou vlastnostı´ je garance kvality sluzˇeb pro ru˚zne´ typy dat. PDU se nazy´vajı´ bunˇky, jsou velmi male´ s konstantnı´ de´lkou 53 oktetu˚ (z du˚vodu jednoduche´ho a rychle´ho prˇepı´na´nı´). Jde o prˇepojova´nı´ na pevny´ch nebo prˇepı´nany´ch virtua´lnı´ch okruzı´ch, proto adresa nemusı´ by´t prˇ´ımo soucˇa´stı´ bunˇky.
4.4.1
P
Zarˇı´zenı´ a cesty v sı´ti
V sı´ti ATM existujı´ dva typy zarˇ´ızenı´: • ATM switch (DCE) • ATM koncove´ zarˇ´ızenı´ (endpoint, DTE) – mu˚zˇe by´t pocˇ´ıtacˇ, router, prˇepı´nacˇ loka´lnı´ sı´teˇ, kodek, atd., prˇipojeno prˇes NIC Jsou definova´ny dva typy rozhranı´: • UNI (User-to-Network Interface) – komunikace mezi endpointem a ATM switchem (DTE– DCE) • NNI (Network-to-Network Interface) – komunikace mezi jednotlivy´mi ATM switchi uvnitrˇ sı´teˇ ATM (DCE–DCE) Lisˇ´ı se za´hlavı´m buneˇk prˇes neˇ posı´lany´ch. ATM stavı´ komunikaci na pevny´ch nebo prˇepı´nany´ch virtua´lnı´ch okruzı´ch, trˇebazˇe se spı´sˇe mluvı´ o virtua´lnı´ch cesta´ch a virtua´lnı´ch kana´lech. Pevne´ okruhy vyzˇadujı´ rucˇ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
Obra´zek 4.7: Virtua´lnı´ cesty a virtua´lnı´ kana´ly v ATM (zjednodusˇeneˇ) Prˇijato z Port VPI VCI A A B
1 3 1
.. .
29 42 18
Prˇepnout na Port VPI VCI B C C
2 1 2
42 8 36
A
-
ATM C switch B
-
-
Obra´zek 4.8: Uka´zka jednoduche´ prˇepı´nacı´ tabulky ATM switche vsˇech prˇepı´nacˇ´ıch na cesteˇ okruhem, tedy jejich vytvorˇenı´ je na´rocˇneˇjsˇ´ı (a tudı´zˇ dlouhodobeˇjsˇ´ı a je mozˇne´ za´rovenˇ specifikovat neˇktere´ dalsˇ´ı parametry vcˇetneˇ QoS), prˇepı´nane´ virtua´lnı´ okruhy zase vyzˇadujı´ jednotnou adresaci v cele´ sı´ti a funkcˇnost signalizacˇnı´ch protokolu˚ pro dynamicke´ vytvorˇenı´ cesty. Virtua´lnı´ cesta a virtua´lnı´ kana´l jsou obdobou virtua´lnı´ho okruhu v telekomunikacı´ch. V jedne´ fyzicke´ prˇenosove´ cesteˇ mu˚zˇe ve´st vı´ce virtua´lnı´ch cest. Virtua´lnı´ cesta sdruzˇuje vı´ce virtua´lnı´ch kana´lu˚, tj. urcˇenı´ (cˇ´ıslo) kana´lu je loka´lnı´ vzhledem k virtua´lnı´ cesteˇ, po ktere´ je veden. Cˇ´ıslo virtua´lnı´ cesty oznacˇujeme VPI (Virtual Path Identifier), cˇ´ıslo virtua´lnı´ho kana´lu oznacˇu-
P
jeme VCI (Virtual Channel Identifier). Hodnota VPI/VCI plneˇ identifikuje prˇenosovou cestu mezi dveˇma sousednı´mi uzly (virtua´lnı´ cesta a v ra´mci te´to cesty virtua´lnı´ kana´l), na kazˇde´m ATM prˇepı´nacˇi se meˇnı´. ATM switch si vede tabulku prˇipojenı´, ve ktere´ jsou prˇidruzˇeny prˇ´ıchozı´ a odchozı´ VPI/VCI, za´znam se tvorˇ´ı beˇhem nava´za´nı´ spojenı´ (vytvorˇenı´ okruhu). Na obra´zku 4.8 je zjednodusˇena´ a zkra´cena´ prˇepı´nacı´ tabulka ATM switche. Jsou v nı´ trˇi virtua´lnı´ cesty. Kazˇdy´ rˇa´dek obsahuje jednu prˇepı´nacı´ informaci, naprˇ´ıklad v prvnı´m rˇa´dku zjistı´me, zˇe bunˇka prˇicha´zejı´cı´ z portu A po cesteˇ 1 v kana´lu 29 je prˇepnuta na port B cestu 2 kana´l 42. Porty jsou oznacˇeny pı´smeny spı´sˇe pro snadneˇjsˇ´ı odlisˇenı´, veˇtsˇinou se setka´me s oznacˇenı´m cˇ´ısly nebo rˇeteˇzci, podle vy´robce.
4.4.2
Bunˇky
ATM bunˇka se skla´da´ ze za´hlavı´ (5 oktetu˚) a datove´ho pole (48 oktetu˚). Za´hlavı´ ma´ na´sledujı´cı´ strukturu: 1. GFC (Generic Flow Control, rˇ´ızenı´ globa´lnı´ho toku, 4 bity) – pouze v UNI bunˇka´ch, a to jen
P
4.4
ATM
83
v prˇ´ıpadeˇ, zˇe na straneˇ uzˇivatele je vı´ce koncovy´ch zarˇ´ızenı´, urcˇuje jednu z 16 u´rovnı´ rˇ´ızenı´ toku; obvykle nastaveno na 0 2. VPI (u UNI 8 bitu˚, u NNI se prˇiberou prˇedchozı´ 4 bity) – identifikace virtua´lnı´ cesty 3. VCI (16 bitu˚) – virtua´lnı´ kana´l, kombinace VPI/VCI tvorˇ´ı dohromady smeˇrovacı´ pole, urcˇuje na´sledujı´cı´ cestu bunˇky v sı´ti (u kazˇde´ho switche se meˇnı´) 4. PT (Payload Type, druh dat, 3 bity) – urcˇuje druh prˇena´sˇeny´ch dat (uzˇivatelska´ nebo sı´t’ova´), prˇ´ıpadne´ prˇetı´zˇenı´ sı´teˇ a zda jde o poslednı´ bunˇku z posloupnosti ra´mce vysˇsˇ´ı vrstvy 5. CLT (Cell Loss Priority, priorita ztra´ty bunˇky, 1 bit) – pokud je nastaven na 1, mu˚zˇe by´t bunˇka v prˇ´ıpadeˇ nutnosti zlikvidova´na 6. HEC (Header Error Control, zabezpecˇenı´ za´hlavı´, 1 B) – obdoba CRC, jde o samoopravny´ ko´d (doka´zˇe opravit chybu v hlavicˇce v rozsahu 1 bit) Zabezpecˇenı´ za´hlavı´ bunˇky – HEC – se pocˇ´ıta´ jako zbytek po deˇlenı´ prˇedchozı´ch bitu˚ za´hlavı´ (xhodnota bitu ) mnohocˇlenem x8 + x2 + x + 1, vy´sledek je mnohocˇlen 31. stupneˇ (tj. je to polynomia´lnı´ ko´d). Slouzˇ´ı k za´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
Bunˇka pro UNI rozhranı´:
HEC
Data →
Bunˇka pro NNI rozhranı´: Data →
Tabulka 4.3: Za´hlavı´ ATM bunˇky Velikost bunˇky je velmi mala´ a konstantnı´. Proto nenı´ mozˇne´ smeˇstnat adresu do za´hlavı´ bunˇky, adresace je neprˇ´ıma´. Takova´to bunˇka je obecneˇ dobrˇe vyuzˇitelna´ pro ru˚zne´ typy dat, vcˇetneˇ multime´diı´. Prˇepı´na´nı´ na ATM switchi je velmi rychle´, s hardwarovou podporou, mu˚zˇe probı´hat paralelneˇ.
4.4.3
Architektura
Referencˇnı´ model ATM je 3dimenziona´lnı´. Kromeˇ vrstev rozlisˇujeme roviny, vrstvy se rozkla´dajı´ prˇes vsˇechny roviny. Podle ISO/OSI jde o fyzickou a linkovou vrstvu, linkova´ je da´le cˇleneˇna. Roviny: • rˇ´ıdicı´ (control) – spra´va spojenı´ (navazova´nı´ a rusˇenı´, rˇ´ızenı´ pru˚beˇhu, generova´nı´ rˇ´ıdicı´ch signa´lu˚) • uzˇivatelska´ (user) – zajisˇt’uje samotny´ prˇenos dat, opravu chyb, rˇesˇenı´ zahlcenı´, atd. • spra´vnı´ (management) – skla´da´ se ze dvou komponent:
P
4.4
ATM
84
– spra´va vrstev (layer management) – naprˇ´ıklad detekce selha´nı´ prˇenosu, rˇ´ıdı´ spolupra´ci vrstev – spra´va rovin (plane management) – obecna´, rˇ´ıdı´ spolupra´ci rovin prˇes vsˇ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.
Obra´zek 4.9: Architektura ATM Vrstvy: • adaptacˇnı´ vrstva ATM (AAL – ATM Adaptation Layer) – rozhranı´ mezi ATM a vysˇsˇ´ımi vrstvami (tj. sı´t’ovy´mi protokoly); multiplexova´nı´ a demultiplexova´nı´, segmentova´nı´ dat na de´lku 48 oktetu˚ a jejich rˇazenı´, QoS; take´ je spı´sˇe rˇazena na linkovou vrstvu, ale ma´ neˇktere´ rysy transportnı´ vrstvy • vrstva ATM (obdoba spodnı´ cˇa´sti linkove´ vrstvy v ISO/OSI) – neza´visla´ na me´diu, spravuje virtua´lnı´ cesty a virtua´lnı´ kana´ly, vede tabulku VPI/VCI a pouzˇ´ıva´ ji; nejvı´ce odpovı´da´ linkove´ vrstveˇ, ale ma´ neˇktere´ rysy sı´t’ove´ vrstvy (smeˇrova´nı´) • fyzicka´ vrstva (obdoba fyzicke´ vrstvy v ISO/OSI) – za´visla´ na prˇenosove´m me´diu Vrstva AAL je pouze na koncovy´ch zarˇ´ızenı´ch sı´teˇ ATM, na ATM prˇepı´nacˇ´ıch najdeme pouze fyzickou vrstvu a vrstvu ATM.
P
4.4
ATM
Fyzicka´ vrstva
85
ma´ dveˇ podvrstvy:
• TC (Transmission Convergence) – rozdeˇlı´ ATM bunˇky na jednotlive´ bity (na opacˇne´m konci spojenı´ je zase pospojuje)
• PMD (Physical Medium Dependent) – zajisˇtuje samotny´ prˇenos, nenı´ specifikova´na (lze pouzˇ´ıt jakoukoliv prˇenosovou technologii) Protozˇe PMD nenı´ pro ATM prˇ´ımo specifikova´na a vysˇsˇ´ı vrstvy take´ neobsahujı´ nic, co by omezovalo rychlost, nenı´ pro ATM obecneˇ da´na zˇa´dna´ maxima´lnı´ rychlost prˇenosu. Na spojovy´ch cesta´ch se obvykle vyuzˇ´ıva´ bud’ SONET nebo SDH (na neˇ se podı´va´me pozdeˇji). Protokol GFP (Generic Framing Procedure) byl vyvinut pro SDH jako na´hrada protokolu HDLC, mapuje/skla´da´ ru˚zne´ typy datovy´ch zpra´v do kontejneru˚ (veˇtsˇ´ıch prˇenosovy´ch jednotek) SDH, ma´ nizˇsˇ´ı rezˇii nezˇ HDLC, navı´c deterministickou.
Aplikační
IP
ATM
MPLS
GEth
SONET/SDH
přenosové médium
Obra´zek 4.10: Mozˇnosti spolupra´ce ATM s jiny´mi sı´teˇmi Adaptacˇnı´ vrstva ATM (AAL) se pouzˇ´ıva´ k adaptaci dat mezi protokoly sı´teˇ ATM a protokoly vysˇsˇ´ıch vrstev. Existuje neˇkolik typu˚ AAL lisˇ´ıcı´ch se prˇedevsˇ´ım garancı´ propustnosti, minimalizace spojenı´ a detekce chyb. Typy AAL: 1. AAL1 – konstantnı´ propustnost (rychlost, CBR), sluzˇba se spojenı´m, vyzˇaduje synchronizaci (za´visı´ na fyzicke´ vrstveˇ) – realtimova´, pro prˇenosy citlive´ na zpozˇdeˇnı´ (hlas, videokonference), podvrstva CS nenı´ vyuzˇita 2. AAL2 – promeˇnna´ propustnost (VBR), se spojenı´m, pro izochronnı´ prˇenosy (garance prˇenosove´ kapacity – sˇ´ırˇka pa´sma, konstantnı´ zpozˇdeˇnı´) jako je prˇenos obrazovy´ch informacı´ promeˇnny´ch v cˇase, nenı´ pouzˇ´ıva´n 3. AAL3/4 – promeˇnna´ propustnost se spojenı´m i bez spojenı´, bez synchronizace, pro data s tolerancı´ zpozˇdeˇnı´, s podporou detekce chyb a rˇazenı´ (cˇ´ıslova´nı´), podobna´ SMDS (take´ doka´zˇe zpracova´vat SMDS pakety), ma´ vysokou prostorovou rezˇii (prodluzˇuje bunˇky)
P
4.4
ATM
86
4. AAL5 – promeˇnna´ propustnost, se spojenı´m i bez spojenı´, bez synchronizace, bez podpory detekce chyb, slouzˇ´ı k prˇepraveˇ IP paketu˚ apod., a emulaci LAN, dnes nejpouzˇ´ıvaneˇjsˇ´ı Protokol AAL5 je take´ zna´m pod na´zvem SEAL (Simple Efficient Adaptation Layer), protozˇe proces zpracova´nı´ PDU je velmi jednoduchy´ – podvrstva SAR jen prˇevezme PDU podvrstvy CS a rozdeˇlı´ na 48oktetove´ u´seky. Postup odesı´la´nı´ dat v AAL5: • podvrstva CS prˇida´ k ra´mci vysˇsˇ´ı vrstvy de´lku ra´mce a kontrolnı´ soucˇet a doplnı´ do velikosti, ktera´ je na´sobkem 48 oktetu˚, vy´sledny´ PDU posˇle da´le
$
• podvrstva SAR tento PDU rozdeˇlı´ na u´seky o de´lce 48 oktetu˚ • vrstva ATM z teˇchto u´seku˚ vytvorˇ´ı bunˇky, tj. prˇida´ za´hlavı´, v za´hlavı´ majı´ vsˇechny bunˇky kromeˇ poslednı´ informaci PT (Payload Type) nastavenu na 0, bunˇky nejsou cˇ´ıslova´ny • fyzicka´ vrstva postupneˇ odesˇle jednotlive´ bunˇky AAL5 umozˇnˇuje zapouzdrˇit PDU podvrstvy LLC obsahujı´cı´ beˇzˇnou komunikaci sluzˇeb bez spojenı´ vcˇetneˇ IP datagramu˚. Podporuje spojenı´ typu • point-to-point jednosmeˇrna´ i obousmeˇrna´, • point-to-multipoint pouze jednosmeˇrna´ (od „korˇene stromu“ k „listu˚m“), neobsahuje podporu spojenı´ typu multipoint-to-multipoint.
4.4.4
QoS
Kvalita sluzˇby (QoS, Quality of Service) umozˇnˇuje poskytovat ru˚zne´ typy sluzˇeb optimalizovane´ pro urcˇite´ druhy aplikacı´, v rozlisˇenı´ podle virtua´lnı´ch kana´lu˚. V ATM jsou tyto trˇ´ıdy sluzˇeb: • CBR (Constant Bit Rate, konstantnı´ propustnost) – garantuje sˇ´ırˇku pa´sma, minima´lnı´ zpozˇdeˇnı´ a odchylku, je vhodna´ pro aplikace v rea´lne´m cˇase (hlas, obraz, videokonference apod.), je navrzˇena pro emulaci prˇepı´na´nı´ okruhu˚, • VBR (Variable Bit Rate, promeˇnna´ propustnost) – nezarucˇuje sˇ´ırˇku pa´sma, minima´lnı´ zpozˇdeˇnı´ ani odchylku, deˇlı´ se na dveˇ podtrˇ´ıdy: – RT-VBR (Real Time VBR) pro aplikace, ktery´m nevadı´ obcˇasna´ ztra´ta bunˇky, ale nemeˇlo by docha´zet ke zpozˇd’ova´nı´ buneˇk (typicky prˇenos hlasu s kompresı´), – NRT-VBR (Non-Real Time VBR) pro aplikace, ktery´m moc nevadı´ mı´rne´ zpozˇdeˇnı´, ale nemeˇlo by docha´zet ke ztra´teˇ buneˇk (naprˇ´ıklad rezervacˇnı´ nebo bankovnı´ syste´my), • ABR (Available Bit Rate, dostupna´ propustnost) – minimalizace ztra´ty buneˇk, prˇicˇemzˇ bunˇky oznacˇene´ nı´zkou prioritou mohou nabrat i veˇtsˇ´ı zpozˇdeˇnı´, bunˇky s vysˇsˇ´ı prioritou mohou prˇedbı´hat, sˇ´ırˇka pa´sma je co nejoptima´lneˇji vyuzˇ´ıva´na (elektronicka´ posˇta, prˇenos souboru˚, apod.), • UBR (Unspecified Bit Rate, nespecifikovana´ propustnost) – bez garancı´, volna´ nepouzˇita´ sˇ´ırˇka pa´sma je vyuzˇ´ıva´na pro postupne´ odesı´la´nı´ cˇekajı´cı´ch buneˇk (pouzˇitelna´ pro vsˇechny typy aplikacı´, ktere´ nevyzˇadujı´ nutnost garance dorucˇenı´, rychlosti cˇi odchylky, naprˇ´ıklad elektronicka´ posˇta).
P
4.4
ATM
87
Pokud je k jednomu ATM prˇepı´nacˇi dopraveno hodneˇ buneˇk za´rovenˇ, mu˚zˇe dojı´t k zahlcenı´ vyrovna´vacı´ pameˇti a bunˇky s nı´zkou prioritou jsou znicˇeny. Jestlizˇe navı´c je hodneˇ teˇchto buneˇk s vysokou prioritou, mu˚zˇe by´t proble´m urcˇit, ktere´ majı´ by´t znicˇeny. Jednı´m z du˚sledku˚ QoS je take´ snadna´ mozˇnost prˇenosu PDU jiny´ch protokolu˚. Beˇzˇneˇ se nad ATM provozujı´ Frame Relay (Frame Relay over ATM), MPLS (v ra´mci ATM Multiprotocol Encapsulation), atd. Informace najdeme naprˇ´ı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 soucˇa´sti: 1. Dohoda o dopraveˇ (traffic contract) – popisuje prˇedpokla´dany´ tok dat (naprˇ´ıklad maxima´lnı´ garantovanou, minima´lnı´ nebo pru˚meˇrnou propustnost), stanovı´ se prˇi prˇipojenı´ zarˇ´ızenı´ do sı´teˇ.
2. Ovlivnˇova´nı´ dopravy (traffic shaping) – regulova´nı´ toku buneˇk v sı´ti prˇi zachova´nı´ jejich porˇadı´. 3. Dozor nad dopravou (traffic policing) – vynucenı´ dodrzˇenı´ pravidel; prˇepı´nacˇe sledujı´ datovy´ tok, a kdyzˇ prˇekracˇuje dohodnute´ parametry, uplatnˇujı´ restriktivnı´ opatrˇenı´. CLP bit (cell loss priority) takovy´ch buneˇk je nastaven na 1 ⇒ bunˇka mu˚zˇe by´t zrusˇena (vy´beˇrove´ rusˇenı´ buneˇk – selective cell discarding) prˇi zahlcenı´.
4.4.5
Adresace a nava´za´nı´ spojenı´
Adresy (20 oktetu˚ dlouhe´) nejsou soucˇa´stı´ kazˇde´ bunˇky, pouzˇ´ıvajı´ se jen prˇi navazova´nı´ spojenı´ (budova´nı´ cesty – stanovenı´ hodnot VPI/VCI na ATM prˇepı´nacˇ´ıch). Pouzˇ´ıva´me tyto typy adres:
P
• ve verˇejny´ch sı´tı´ch adresy podle doporucˇenı´ E.164 (pro ISDN a SMDS), jedna´ se o cˇ´ıselnou adresu podobnou telefonnı´mu cˇ´ıslu (plochy´ adresovy´ prostor), • v soukromy´ch sı´tı´ch je adresace zalozˇena na NSAP (Network Service Access Point), adresa je take´ cˇ´ıselna´, ale hierarchicky cˇleneˇna´, soucˇa´stı´ adresy je take´ 6oktetova´ MAC adresa zarˇ´ızenı´. Prvnı´ch 13 oktetu˚ adresy urcˇuje switch, ke ktere´mu je cı´love´ zarˇ´ızenı´ prˇipojeno, cı´lova´ zarˇ´ızenı´ teˇchto 13 oktetu˚ prˇejı´majı´ od switche, ke ktere´mu jsou prˇipojeny, dalsˇ´ı jizˇ urcˇuje konkre´tnı´ zarˇ´ızenı´ (MAC a 1oktetovy´ suffix, mu˚zˇe to by´t SAP protokolu vysˇsˇ´ı vrstvy). Adresova´ pole: • AFI (Authority and Format Identifier, 1 oktet) – urcˇuje konkre´tnı´ typ adresy (hodnota 45 pro E.164, 47 pro ICD, 39 pro DCC) • da´le: – v adrese typu E.164 je 8 oktetu˚ pro telefonnı´ cˇ´ıslo (ISDN) – v adresa´ch typu DCC a ICD je 2oktetove´ pole pro ko´d zemeˇ (DCC), resp. mezina´rodnı´ ko´d organizace (ICD), na´sleduje identifika´tor adresy v dane´ dome´neˇ (DFI – Domain Specific Part Format Identifier) a spra´vce sı´teˇ (AA – Administrative Authority)
4.4
ATM
88
• RD (Routing Domain, 2 oktety) identifikujı´cı´ smeˇrovacı´ dome´nu • Area (identifika´tor oblasti), uprˇesnˇuje RD • ESI (End System Identifier, 6 oktetu˚) – identifikace koncove´ho zarˇ´ızenı´ (IEEE 802 MAC adresa v loka´lnı´ sı´ti) • selektor (1 oktet) – SAP protokolu vysˇsˇ´ı vrstvy Tedy zacˇa´tek adresy urcˇuje jejı´ typ, na´sleduje konkre´tnı´ adresa podle dane´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
Obra´zek 4.11: Nava´za´nı´ spojenı´ v ATM Vytvorˇenı´ prˇepı´nane´ho virtua´lnı´ho okruhu
(signalizace) probı´ha´ takto:
• zdrojovy´ uzel (UNI) odesˇle zˇa´dost o spojenı´ • zˇa´dost postupuje uzly sı´teˇ (prˇepı´nacˇe, NNI) a tvorˇ´ı se virtua´lnı´ okruh, stanovujı´ se cˇ´ısla virtua´lnı´ch kana´lu˚ a virtua´lnı´ch cest • kdyzˇ se cesta uka´zˇe jako „slepa´“, prˇepı´nacˇ vra´tı´ zˇa´dost o krok zpeˇt a hleda´ se jina´ cesta • cı´lovy´ uzel bud’ potvrdı´ spojenı´, a nebo je spojenı´ odmı´tnuto (nelze nava´zat) Samotna´ signalizace probı´ha´ na vyhrazeny´ch cesta´ch (VPI=0) a kana´lech, soucˇa´stı´ definice NNI jsou smeˇrovacı´ protokoly pouzˇ´ıvane´ pra´veˇ prˇi navazova´nı´ spojenı´ (protokol PNNI – Private NetworkNetwork Interface). ATM a multicast: Multicast a broadcast nejsou v ATM prˇ´ımo podporova´ny, musejı´ by´t pouzˇity pomocne´ mechanismy. Jednı´m z nejpouzˇ´ıvaneˇjsˇ´ıch je multicast server, ktery´ • prˇijı´ma´ zpra´vy urcˇene´ pro multicast na spojenı´ch typu point-to-point, • tyto zpra´vy pak odesı´la´ vsˇem, komu jsou urcˇeny, na spojenı´ch typu point-to-multipoint. V ATM lze totizˇ uva´deˇt pouze adresu prˇ´ıjemce, nikoliv odesı´latele, cozˇ znemozˇnˇuje prˇ´ıme´ zası´la´nı´ multicast dat.
$
4.4
ATM
4.4.6
89
ILMI
ILMI (Integrated Local Management Interface, Interim Local Management Interface) je rozhranı´ (konkre´tneˇ protokol), ktere´ eviduje a zprˇ´ıstupnˇuje informace o stavu komponent koncove´ho zarˇ´ızenı´ jiny´m koncovy´m zarˇ´ızenı´m (prˇesneˇji je to protokol pro specifickou komunikaci mezi koncovy´m zarˇ´ızenı´m a ATM switchem). Pracuje na fyzicke´ vrstveˇ a vrstveˇ ATM, pouzˇ´ıva´ vyhrazene´ VCI=16. ILMI komunikuje pomocı´ protokolu SNMP.
P
Objekty, ktere´ spravuje a zprˇ´ıstupnˇuje, ukla´da´ do databa´ze MIB (Management Information Base) podobneˇ jak to deˇlajı´ protokoly pouzˇ´ıvane´ pro spra´vu loka´lnı´ch sı´tı´.
4.4.7
Spolupra´ce s LAN
Mozˇnosti propojenı´ LAN pomocı´ ATM jsou trˇi: Classical IP over ATM, LANE, MPOA. 1. Classical IP over ATM – IP datagram se ve vrstveˇ AAL5 zapouzdrˇ´ı do LLC/SNAP ra´mce a pak posˇle prˇes ATM. Prˇeklad adres (IP×ATM) prova´deˇjı´ prˇekladove´ servery – ATM ARP servery. Neˇktere´ vlastnosti IP musı´ by´t potlacˇeny (naprˇ. multicast a broadcast). 2. Emulace LAN nad ATM – LANE (LAN Emulation) je standard pro emulaci LAN nad ATM vydany´ ATM fo´rem. Lze prˇena´sˇet pakety vı´ce ru˚zny´ch loka´lnı´ch sı´tı´ (naprˇ´ıklad 802.3 – Ethernet, 802.5 – TokenRing). Propojova´nı´ ru˚zny´ch LAN tı´mto zpu˚sobem je podobne´ virtua´lnı´m sı´tı´m (VLAN). Mozˇnosti implementace LANE: • typ 1: LANE je implementova´n v NIC koncove´ho zarˇ´ızenı´ (ATM NIC), lze prˇipojit k beˇzˇne´mu ATM switchi • typ 2: NIC koncove´ho zarˇ´ızenı´ nenı´ ATM, ale beˇzˇna´ LAN karta, pak se prˇipojuje ke switchi, ktery´ sa´m prova´dı´ prˇeklad mezi MAC a ATM adresami LANE je implementova´n pouze na „okraji“ ATM sı´teˇ, prˇi komunikaci s ATM prˇepı´nacˇi se pouzˇ´ıvajı´ standardnı´ signalizacˇnı´ postupy ATM. Celkova´ implementace je pomeˇrneˇ slozˇita´ a poneˇkud krˇecˇovita´, protozˇe rozdı´ly mezi protokoly, PDU a pru˚beˇhem spojenı´ jsou v ATM zalozˇeny na zcela jine´m principu nezˇ jak je tomu v prˇ´ıpadeˇ loka´lnı´ch sı´tı´. Je neˇkolik typu˚ serveru˚, ktere´ umozˇnˇujı´ LANE provozovat. Nejde pouze o mapova´nı´ MAC/IP/ ATM adres, ale take´ o servery administrativnı´ a take´ existujı´ tzv. BUS servery (Broadcast and Unknown Server), ktere´ na point-to-point spojı´ch prˇijı´majı´ komunikaci, ktera´ je vnitrˇneˇ (podle loka´lnı´ch sı´tı´) broadcast, a da´le ji rozesı´lajı´ na point-to-multipoint spojı´ch, aby to celkoveˇ fungovalo jako broadcast vysı´la´nı´. 3. MPOA (Multiprotocol over ATM) rozsˇirˇuje LANE o mozˇnost rychlejsˇ´ı komunikace mezi emulovany´mi LAN. Pouzˇ´ıva´ se tzv. distribuovany´ smeˇrovacˇ (take´ virtua´lnı´ smeˇrovacˇ), ktery´ se fyzicky skla´da´ z vı´ce zarˇ´ızenı´, mezi tato zarˇ´ızenı´ se distribuujı´ funkce smeˇrova´nı´ a prˇepı´na´nı´. Prˇi pouzˇitı´ MPOA probı´ha´ komunikace na zacˇa´tku stejneˇ jako v LAN a LANE (prˇes smeˇrovacı´ servery), ale beˇhem neˇkolika prvnı´ch ra´mcu˚ je zjisˇt’ova´na „zkratka“ (shortcut), prˇ´ıme´ propojenı´ mezi VLAN sı´teˇmi a komunikace se zrychluje, uzˇ nenı´ nutne´ pouzˇ´ıvat smeˇrovacˇe na cesteˇ.
4.5
MPLS
90
Jde prˇedevsˇ´ım o to zachovat mozˇnosti smeˇrova´nı´ tak, jak jsou na loka´lnı´ch sı´tı´ch, ale prˇitom eliminovat jejich nedostatky – prˇi beˇzˇne´m smeˇrova´nı´ se prova´dı´ zpracova´nı´ sı´t’ove´ho za´hlavı´ PDU na kazˇde´m smeˇrovacˇi, cozˇ znamena´ znacˇnou cˇasovou ztra´tu, ale prˇi pouzˇitı´ MPOA se tento proces prova´dı´ pouze na hranovy´ch (okrajovy´ch) zarˇ´ızenı´ch ATM MPOA sı´teˇ. Na veˇtsˇineˇ cesty datove´ jednotky je pak vyuzˇito prˇ´ıme´ spojenı´ prˇes ATM sı´t’, kde ke smeˇrova´nı´ nedocha´zı´. Tato metoda se take´ nazy´va´ zero-hop nebo cut-through. Hlavnı´ nevy´hodou MPOA je silna´ vazba na ATM, nenı´ pouzˇitelna´ na hybridnı´ch prˇenosovy´ch sı´tı´ch. Dalsˇı´ 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 ru˚zny´ch typu˚ WAN a MAN sı´tı´, nejen ATM)
Jak lze take´ vycˇ´ıst z odkazu˚, ATM postupneˇ ztra´cı´ na populariteˇ (v 90. letech byla velmi popula´rnı´), prˇedevsˇ´ım z du˚vodu kombinace vysoke´ ceny sı´t’ovy´ch prvku˚, pomeˇrneˇ nı´zke´ rychlosti a slozˇite´ kombinace s loka´lnı´mi sı´teˇmi, zvla´sˇteˇ se zrychleny´m rozvojem Internetu a prˇenosu IP datagramu˚.
4.5
MPLS
Dosud jsme se zaby´vali prˇepı´na´nı´m paketu˚ (X.25), ra´mcu˚ (Frame Relay) a buneˇk (ATM), ted’ se podı´va´me na prˇepı´na´nı´ znacˇek.
4.5.1
Prˇepı´na´nı´ znacˇek
MPLS (MultiProtocol Label Switching) je sı´t’ zalozˇena´ na prˇepı´na´nı´ znacˇek (label, take´ na´veˇsˇtı´). ´ cˇelem je prˇesunout co nejvı´ce rezˇie smeˇrova´nı´ (vcˇetneˇ administrace, QoS apod.) na okraj sı´teˇ tak, U aby vnitrˇnı´ oblast sı´teˇ byla co nejrychlejsˇ´ı. MPLS doka´zˇe velmi rychle prˇena´sˇet nejen beˇzˇna´ data, ale take´ hlas a video, a to se zajisˇteˇnı´m QoS. K vy´hoda´m sı´teˇ ATM se tedy prˇida´va´ pruzˇnost a vysˇsˇ´ı rychlost. Dalsˇ´ı vy´hodou je snadneˇjsˇ´ı implementace virtua´lnı´ch sı´tı´. Obrovskou vy´hodou MPLS je mnohotva´rnost. Nema´ prˇ´ımo definova´nu adresaci ani smeˇrova´nı´, (mozˇna´ proto) doka´zˇe spolupracovat s vı´ce odlisˇny´mi protokoly. Pu˚vodneˇ MPLS pracovala pouze nad ATM, ale v soucˇasne´ dobeˇ pracuje take´ nad Ethernetem, Frame Relay, SONET/SDH a dalsˇ´ımi. Takzˇe vy´hody MPLS mu˚zˇeme shrnout takto: • • • •
rychlost prˇepı´na´nı´, zajisˇt’ova´nı´ rˇ´ızenı´ provozu (vyvazˇova´nı´ za´teˇzˇe) a QoS (odlisˇne´ zacha´zenı´ s ru˚zny´mi PDU), podpora VPN, schopnost spolupra´ce s mnoha ru˚zny´mi protokoly, pod MPLS mohou fungovat ru˚zne´ technologie.
P
4.5
MPLS
91
V ISO/OSI modelu bychom mohli MPLS zarˇadit neˇkam mezi druhou (spojovou) a trˇetı´ (sı´t’ovou) vrstvu, take´ se oznacˇuje jako vrstva 2.5 nebo 2+. Technologie byla prˇedstavena firmou Ipsilon Networks pod na´zvem IP Switching. Pozdeˇji firma Cisco vytvorˇila proprieta´lnı´ standard Tag Switching, ktery´ sı´t’ zbavil za´vislosti na ATM, podobny´, ale otevrˇeny´ standard pozdeˇji vydalo sdruzˇenı´ IETF. Kazˇdy´ datagram, ktery´ vstupuje do MPLS sı´teˇ, je na okrajove´m smeˇrovacˇi opatrˇen jednı´m nebo vı´ce MPLS za´hlavı´mi usporˇa´dany´mi do za´sobnı´ku (stack), a to na rozhranı´ mezi za´hlavı´mi druhe´ a trˇetı´ vrstvy. Za´hlavı´ protokolu MPLS ma´ tuto strukturu:
P
• samotna´ znacˇka (na´veˇsˇtı´, label, 20 bitu˚), • Qos informace (3 bity), v prˇ´ıpadeˇ MPLS se setka´me s na´zvem CoS (Cathegory nebo Class of Service) nebo take´ ve vy´znamu Experimental (Exp.), • prˇ´ıznak konce za´sobnı´ku (1 bit); pokud nena´sleduje dalsˇ´ı za´hlavı´, je nastaven na 1 (to znamena´, zˇe na´sleduje uzˇ prˇ´ımo za´hlavı´ IP datagramu), • TTL (Time to Live, 8 bitu˚). Znacˇka ulozˇena´ v MPLS za´hlavı´ jednoznacˇneˇ urcˇuje smeˇrova´nı´ datagramu na cesteˇ k na´sledujı´cı´mu smeˇrovacˇi. Za´hlavı´ ra´mce 2. vrstvy
MPLS Label 1, ES bit = 0
MPLS Label 2, ES bit = 0
MPLS Label 3, ES bit = 1
Za´hlavı´ paketu 3. vrstvy (naprˇ. IP)
Datova´ cˇa´st paketu
Tabulka 4.4: Za´sobnı´k znacˇek v MPLS Vneˇjsˇ´ı (nejvrchneˇjsˇ´ı) za´hlavı´ na za´sobnı´ku je urcˇeno pra´veˇ ke stanovenı´ cest. Nenabı´zı´ vpodstateˇ o moc vı´c nezˇ IP za´hlavı´ (s jednı´m du˚lezˇity´m rozdı´lem – rychleji se zpracova´va´). Dalsˇ´ı za´hlavı´ hloubeˇji v za´sobnı´ku majı´ trochu jiny´, specificky´, u´cˇel, naprˇ´ıklad za´hlavı´ VPN pro urcˇenı´ virtua´lnı´ sı´teˇ, za´hlavı´ pro QoS nebo za´hlavı´ pro rˇ´ızenı´ provozu. Prˇideˇlova´nı´ znacˇek (ve vsˇech za´hlavı´ch ve stacku) probı´ha´ formou trˇ´ıdeˇnı´ datovy´ch jednotek do trˇ´ıd (FEC – Forward Equivalence Class), datove´ jednotky patrˇ´ıcı´ do te´zˇe trˇ´ıdy jsou z uzlu odesı´la´ny se stejny´m za´hlavı´m. Trˇ´ıda je stanovena na za´kladeˇ neˇkolika krite´riı´ – prˇedevsˇ´ım podle prefixu IP adresy a da´le naprˇ´ıklad podle neˇktery´ch charakteristik VPN.
4.5.2
P P
Smeˇrova´nı´ v MPLS
Smeˇrovacˇe (spı´sˇe prˇepı´nacˇe) v sı´ti MPLS jsou nazy´va´ny LSR (Label Switching Router). LSR na okraji sı´teˇ (tj. komunikujı´cı´ take´ s uzly v loka´lnı´ch sı´tı´ch, ktere´ jsou sı´tı´ MPLS propojeny), jsou oznacˇova´ny jako ELSR (Edge LSR, hranove´ smeˇrovacˇe), a jsou bud’ vstupnı´ (Ingress ELSR) nebo vy´stupnı´ (Egress ELSR) podle smeˇru provozu. U firmy Cisco se mu˚zˇeme setkat s odlisˇnou terminologiı´ – LSR jsou nazy´va´ny provider/core router, ELSR se nazy´vajı´ provider edge router (ale v mnoha dokumentech se pouzˇ´ıva´ „pu˚vodnı´“ terminologie).
P
4.5
MPLS
92
Velice cˇasto se take´ setka´va´me s trochu jiny´m oznacˇenı´m: • P (Provider) – prˇepı´nacˇe uvnitrˇ MPLS sı´teˇ, vzˇdy ve vlastnictvı´ poskytovatele (nebo jeho poskytovatele), • PE (Provider Edge) – na hranici MPLS sı´teˇ, • CE (Customer Edge) – na hranici sı´teˇ za´kaznı´ka, bud’ v jeho vlastnictvı´ nebo pronajat od poskytovatele (komunikuje s PE).
'$
Na obra´zku 4.12 je naznacˇena obvykla´ struktura MPLS sı´teˇ s uzly P, PE a CE. CE je soucˇa´stı´ loka´lnı´ sı´teˇ za´kaznı´ka, k jednomu PE mu˚zˇe by´t prˇipojeno vı´ce CE (tj. vı´ce LAN).
P
PE CE
P
PE
CE
&% P
P
CE
PE
Obra´zek 4.12: Struktura MPLS sı´teˇ
Smeˇrova´nı´ (prˇepı´na´nı´ znacˇek) probı´ha´ podobneˇ jako v ATM, ale jesˇteˇ jednodusˇeji. Smeˇrovacˇe si vedou jednoduchou tabulku (take´ se nazy´va´ Label Forwarding Database – LFD), ktera´ je podobna´ tabulce pro ATM, ale mı´sto dvojice VPI/VCI je zde pouze hodnota znacˇky (datagram z portu PPP opatrˇeny´ znacˇkou XXX je opatrˇen znacˇkou YYY a posla´n na port QQQ, apod.). Jedna´ se jen o urcˇenı´ vazby mezi prˇ´ıchozı´ a odchozı´ znacˇkou, cesty jsou jednosmeˇrne´. 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 -
Obra´zek 4.13: Uka´zka jednoduche´ prˇepı´nacı´ tabulky MPLS smeˇrovacˇe Na obra´zku 4.13 je uka´zka tabulky na LSR uvnitrˇ sı´teˇ. Pokud by se jednalo o vstupnı´ Ingress ELSR, hodnoty ze sloupce se vstupnı´ znacˇkou a portem by nebyly pouzˇ´ıva´ny, obdobneˇ u Egress ELSR by nebyly pouzˇ´ıva´ny hodnoty ze sloupce s vy´stupnı´ znacˇkou a portem. Znacˇka ulozˇena´ v datagramu se prˇi pru˚chodu smeˇrovacˇi neusta´le meˇnı´, podle toho, jak to bylo nastaveno prˇi navazova´nı´ spojenı´, podle obsahu tabulek na pru˚chozı´ch LSR. Tento proces se nazy´va´ Label Swapping (vy´meˇna znacˇek/na´veˇsˇtı´).
P
4.5
MPLS
93
Konkre´tnı´ obsah tabulky na LSR za´visı´ take´ na protokolu, se ktery´m MPLS spolupracuje (tj. na sı´ti, nad kterou pracuje). Jestlizˇe naprˇ´ıklad MPLS pracuje nad ATM, jsou MPLS znacˇky pouzˇ´ıva´ny v ATM jako cˇ´ısla VPI/VCI. Je zrˇejme´, zˇe tabulky na smeˇrovacˇ´ıch jsou vlastneˇ loka´lnı´, vztahujı´ se pouze k nejblizˇsˇ´ım okolnı´m smeˇrovacˇu˚m. Zarˇı´zenı´ podporujı´cı´ MPLS obvykle za´kaznı´k zı´ska´ od poskytovatele technologie (naprˇ´ıklad telekomunikacˇnı´ spolecˇnosti, ktera´ ma´ k dispozici prˇenosove´ cesty). Pokud si ale firma chce vytvorˇit vlastnı´ MPLS sı´t’ (ma´ k dispozici sve´ prˇenosove´ cesty), existujı´ zarˇ´ızenı´ naprˇ. od firem Cisco, Mikrotik, Juniper.
4.5.3
P
Vytva´rˇenı´ cest
Protokol LDP (Label Distribution Protocol) slouzˇ´ı k vy´meˇneˇ informacı´ o znacˇka´ch mezi smeˇrovacˇi, vy´meˇna informacı´ o prefixech adres probı´ha´ podle neˇktere´ho smeˇrovacı´ho protokolu obecneˇ oznacˇovane´ho zkratkou IGP (Interior Gateway Protocol), cozˇ mu˚zˇe by´t prakticky ktery´koliv, velmi cˇasto OSPF (nynı´ spı´sˇe OSPFv2). U MPLS se vsˇak setka´va´me i s dalsˇ´ımi protokoly, naprˇ´ıklad prˇi implementaci virtua´lnı´ch sı´tı´ (VPN) se pouzˇ´ıva´ BGP. O smeˇrovacı´ch protokolech se budeme ucˇit pozdeˇ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
Obra´zek 4.14: Prˇipojenı´ nove´ LAN do MPLS Postup prˇida´va´nı´ za´znamu˚ do tabulek v za´kladnı´ varianteˇ MPLS je naznacˇen na obra´zku 4.14. Oznamova´nı´ probı´ha´ „proti smeˇru“ cesty, kazˇdy´ uzel pro prˇ´ıchozı´ pozˇadavek stanovı´ cˇ´ıslo (znacˇku), ktere´ ma´ pra´veˇ volne´, a posˇle pozˇadavek na vsˇechny sousednı´ uzly (i na ten, ze ktere´ho pozˇadavek prˇisˇel). Naprˇ´ıklad podle obra´zku 4.14 je vy´stupnı´m LSR smeˇrovacˇ EL2: • EL2 prˇipojı´ LAN smeˇrovacˇ R2, prefix adresy je 10.4.8.0/24, prˇirˇadı´ znacˇku 7, do tabulky prˇida´ za´znam o tom, zˇe cokoliv prˇijde na tuto znacˇku a prefix, odesˇle smeˇrovacˇi R2 • EL2 odesˇle sousednı´m MPLS smeˇrovacˇu˚m (L1 a L2) informaci „cestu k sı´ti s prefixem 10.4.8.0/24 najdete na znacˇce 7“
$
OPTICKE´ PRˇENOSOVE´ CESTY
4.6
94
• L1 obdrzˇ´ı tuto informaci, najde volnou znacˇku 17, prˇida´ do tabulky za´znam o tom, zˇe cokoliv prˇijde na znacˇku 17 a dany´ prefix, v tom zmeˇnı´ znacˇku na 7 a posˇle na smeˇrovacˇ EL2, odesˇle informaci smeˇrovacˇu˚m EL1 a EL2 • podobneˇ L2, ale nasˇel volnou znacˇku 21 • EL1 obdrzˇ´ı dveˇ informace, ale informace z L2 prˇisˇla drˇ´ıv, tedy ulozˇ´ı vy´stupnı´ znacˇku 21
4.5.4
Dalsˇı´ mozˇnosti
GMPLS (Generalized MPLS, take´ G-MPLS) je rozsˇ´ırˇenı´ MPLS, ktere´ zobecnˇuje MPLS na dalsˇ´ı ´ cˇelem je odstranit co nejvı´ce „komunikacˇnı´ch mezikroku˚“ vrstvy ISO/OSI a dalsˇ´ı rozhranı´. U a umozˇnit nasazenı´ MPLS technologie i nad takovy´mi rˇesˇenı´mi, nad ktery´mi to drˇ´ıv nebylo mozˇne´ (nejen nad rˇesˇenı´mi pouzˇ´ıvajı´cı´mi pakety a ra´mce). Na´veˇsˇtı´ uzˇ nemusı´ by´t jen cˇ´ıslo, ale mu˚zˇe to by´t naprˇ´ıklad vlnova´ de´lka v opticke´ sı´ti, fyzicky´ port, cˇasovy´ slot v TDM apod., cokoliv, podle cˇeho lze rozsˇilit ru˚zne´ komunikace, tedy MPLS lze nasadit naprˇ´ıklad i nad DWDM.
Podobne´ vlastnosti jako GMPLS majı´ sı´teˇ ASON (Automatically Switched Optical Network), take´ beˇzˇ´ı nad opticky´mi cestami cˇi SDH, take´ zahrnujı´ podporu QoS, VPN a rychle´ho transportu. GMPLS a ASON jsou porovna´va´ny naprˇ. na http://www.dataconnection.com/download/asongmpls.pdf. Dalsˇı´ 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. Veˇtsˇina stran dostupna´ 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/
Opticke´ prˇenosove´ cesty SONET/SDH
SONET (Synchronous Optical Network, ANSI T.105) je digita´lnı´ opticky´ (na opticky´ch vla´knech) prˇenosovy´ syste´m vyuzˇ´ıvajı´cı´ cˇasovy´ multiplex, centra´lneˇ synchronizovany´ atomovy´mi hodinami. Je standardizova´n a pouzˇ´ıva´n v USA, Kanadeˇ a Japonsku.
P
4.6
OPTICKE´ PRˇENOSOVE´ CESTY
95
SDH (Synchronous Digital Hierarchy, ITU-T G.707) je obdoba sı´teˇ SONET ve zbytku sveˇta, rozdı´ly jsou jen male´ (mj. v rˇ´ıdicı´ch protokolech). Cˇasto se setka´me s oznacˇenı´m SONET/SDH, odkazujı´cı´m na technologii, kterou majı´ obeˇ rˇesˇenı´ spolecˇnou. SONET/SDH byla vytvorˇena pro hlasovou komunikaci a pro tento u´cˇel je take´ optimalizova´na, sama o sobeˇ nenı´ efektivnı´m rˇesˇenı´m pro prˇenos dat. Proto nad SDH obvykle pracuje jesˇteˇ jiny´ typ WAN/MAN sı´teˇ (nad SDH mu˚zˇe pracovat naprˇ´ıklad ATM, POS – Packet over SONET, MPLS, EoS – Gigabit Ethernet over SONET/SDH). Za´kaznı´k je nucen zvolit si z neˇkolika ma´lo typu˚ sluzˇby podle propustnosti (2 Mb/s, 34 Mb/s, 130 Mb/s), za tuto propustnost take´ platı´, i kdyzˇ ji zrovna nevyuzˇ´ıva´ (pa´smo nelze pronajmout jine´mu za´kaznı´kovi). Podobneˇ jako neˇktere´ prˇedchozı´ WAN, i zde je pouzˇ´ıva´na PDU o konstantnı´ de´lce – blok ma´ de´lku 810 oktetu˚. Pracuje se v cˇasove´m multiplexu, tedy prˇena´sˇene´ bloky dat jsou umı´st’ova´ny do volny´ch slotu˚ vysı´lany´ch v pravidelny´ch intervalech 125 µs.
4.6.2
WDM a DWDM
WDM (Wavelength Division Multiplexing) je technologie multiplexova´nı´ sveˇtla v opticky´ch spojı´ch do vlnovy´ch de´lek. Bez pouzˇitı´ WDM je mozˇne´ jednı´m opticky´m spojem ve´st jen jeden signa´l, s pouzˇitı´m WDM vı´ce signa´lu˚ za´rovenˇ na ru˚zny´ch vlnovy´ch de´lka´ch, na kazˇde´ vlnove´ de´lce podle jine´ho protokolu a o jine´ rychlosti. DWDM (Dense Wavelength Division Multiplexing) umozˇnˇuje prˇena´sˇet kana´ly na vlnovy´ch de´lka´ch s velmi maly´m odstupem, i pod 1 nm. Cˇ´ım mensˇ´ı odstup mezi vlnovy´mi de´lkami, tı´m vı´ce na jednu stranu lze prˇena´sˇet kana´lu˚ paralelneˇ, ale na druhou stranu se mu˚zˇe zhorsˇit kvalita prˇenosu, proto obvykle nenı´ vyuzˇ´ıva´n plneˇ. Do jednoho opticke´ho vla´kna lze poskla´dat azˇ 128 kana´lu˚, ale ve frekventovany´ch datovy´ch pa´terˇnı´ch sı´tı´ch se spı´sˇe setka´me s 32 kana´ly v jednom vla´kneˇ (jmenoviteˇ – CESNET2). Pocˇet kana´lu˚ take´ za´visı´ na pouzˇity´ch opticky´ch multiplexorech (ktere´ prova´deˇjı´ samotne´ mapova´nı´ signa´lu do kana´lu a zpeˇt).
P P
Obvykla´ rychlost na jeden kana´l (jednu vlnovou de´lku) je prˇiblizˇneˇ 10 Gb/s (nebo 40 Gb/s), a celkova´ propustnost jednoho vla´kna je (te´meˇrˇ) soucˇtem propustnostı´ jednotlivy´ch kana´lu˚. Na DWDM (mezi DWDM a TCP/IP) jsou pak implementova´ny dodatecˇne´ technologie, ktere´ majı´ urychlit a obecneˇ zefektivnit prˇenos, v soucˇasne´ dobeˇ prˇedevsˇ´ım IP/MPLS a na okrajı´ch rozlehle´ sı´teˇ pak naprˇ´ıklad EoMPLS (Ethernet over MPLS), ktery´ velmi dobrˇe spolupracuje s prˇipojeny´mi ethernetovy´mi LAN. ROADM (Reconfigurable Add-Drop Multiplexer) jsou multiplexory, ktere´ v sı´tı´ch DWDM (obecneˇ WDM) umozˇnˇujı´ automaticke´ vytva´rˇenı´ a spra´vu opticky´ch prˇenosovy´ch kana´lu˚. Prˇi pouzˇitı´ ROADM nenı´ trˇeba tyto kana´ly vytva´rˇet a konfigurovat rucˇneˇ.
P
Kapitola
5
Data a telekomunikacˇnı´ sı´teˇ V te´to kapitole se zaby´va´me postupy prˇi vyuzˇitı´ telekomunikacˇnı´ch linek pro datove´ prˇenosy. Zacˇneme analogovou dial-up technologiı´, na´sleduje ISDN a pak ru˚zne´ DSL technologie. Pote´ se zameˇrˇ´ıme na telefonnı´ u´strˇedny a VoIP.
5.1
Dial-up technologie
5.1.1
Shannonu˚v teore´m
Claude Elwood Shannon je zakladatel modernı´ teorie informace. Shannonu˚v teore´m uda´va´ strop pro maxima´lnı´ rychlost prˇenosu. „Aby bylo mozˇne´ rekonstruovat (na cı´love´ stanici) spojity´ frekvencˇneˇ omezeny´ analogovy´ signa´l ze vzorku˚, musı´ by´t vzorkova´n s frekvencı´ alesponˇ dvakra´t vysˇsˇ´ı nezˇ je maxima´lnı´ frekvence tohoto signa´lu prˇi prˇenosu.“ Du˚sledkem je ohranicˇenı´ maxima´lnı´ dosazˇitelne´ rychlosti prˇenosu, a to • sˇ´ırˇkou pa´sma (pocˇet stavu˚ v ra´mci pa´sma nelze zvysˇovat do nekonecˇna, ztratili bychom mozˇnost jeho rozlisˇenı´) • kvalitou signa´lu (vyply´va´ z fyzika´lnı´ch vlastnostı´ linky, zhorsˇena´ sˇumem, take´ „odstup signa´lu od sˇumu“) ale neza´visı´ na pouzˇite´ technologii (vcˇetneˇ pouzˇite´ modulace). Vzorec: max(rychlost prˇenosu) = sˇ´ırˇka pa´sma ∗ log2 (1 + signa´l/sˇum)
96
5.1
DIAL-UP TECHNOLOGIE
5.1.2
97
Telefonnı´ sı´t’
Telefonnı´ sı´t’je rˇesˇena hierarchicky: • u´cˇastnicke´ zarˇ´ızenı´ (telefon, modem apod.), prˇipojuje se prˇes u´cˇastnickou prˇ´ıpojku • (verˇejna´) mı´stnı´ telefonnı´ u´strˇedna (MTO) • uzlova´ telefonnı´ u´strˇedna (UTO), tranzitnı´ telefonnı´ u´strˇedna (TTO)
P
V ra´mci firemnı´ho area´lu mu˚zˇe take´ fungovat pobocˇkova´ u´strˇedna (PBX, Private Branch Exchange), ktera´ by´va´ prˇipojena na neˇkterou verˇejnou mı´stnı´ telefonnı´ u´strˇednu (tj. funguje jako bra´na). Prˇi prˇenosu dat prˇes telefonnı´ sı´t’, dimenzovanou pro prˇenos zvuku (prˇedevsˇ´ım hlasu), bylo hlavnı´ motivacı´ vyuzˇitı´ jizˇ existujı´cı´ huste´ sı´teˇ teˇchto linek, tedy snadna´ dostupnost koncovy´ch bodu˚. V telefonnı´ sı´ti platı´: pro prˇenos hlasu plneˇ postacˇuje prˇena´sˇenı´ frekvencı´ z intervalu 300–3400 Hz, orˇeza´nı´ okolnı´ch frekvencı´ prakticky neovlivnı´ kvalitu hovoru. Prˇenos musı´ by´t multiplexova´n, v analogove´ sı´ti je volen frekvencˇnı´ multiplex s sˇ´ırˇkou pa´sma pro jeden prˇenos zaokrouhlenou nahoru (s rezervou) – 4000 Hz.
5.1.3
Prˇenos dat na telefonnı´ch linka´ch
Telefonnı´ linky jsou optimalizova´ny pro prˇenos hlasu, jejich vyuzˇitelnost pro prˇenos dat je omezena´. Princip: • • • ⇒
frekvencˇnı´ omezenı´ je 300–3400 Hz, tj. sˇ´ırˇka 3,1 kHz kvalitnı´ telefonnı´ linka ma´ odstup signa´lu od sˇumu prˇiblizˇneˇ 1000:1 po dosazenı´ do vzorce dostaneme prˇiblizˇneˇ 30 000 b/s kdyzˇ po analogove´ sı´ti prˇena´sˇ´ıme data, musı´me s tı´m pocˇ´ıtat; rˇesˇenı´:
P
a) pouzˇ´ıt veˇtsˇ´ı sˇ´ırˇku pa´sma (modemy 33,6 kb/s) b) obejı´t frekvencˇnı´ omezenı´ (modemy 56 kb/s), jen smeˇr od digita´lnı´ u´strˇedny c) odstranit frekvencˇnı´ omezenı´ (ISDN, ADSL) – na digita´lnı´ch linka´ch se pouzˇ´ıva´ cˇasovy´ multiplex, navı´c (u ADSL) se telekomunikacˇnı´ sı´t’propojuje se sı´tı´ datovou („odbocˇka“) PSTN (Public Switched Telephone Network) prˇenos hlasu
= beˇzˇna´ telefonnı´ sı´t’dimenzovana´ prˇedevsˇ´ım pro
P
• modemy standardu V.21, V.32bis, V.34, . . . , V.90, V.92 – analogove´, lisˇ´ı se mj. prˇenosovy´mi rychlostmi, rychlejsˇ´ı pracujı´ asynchronneˇ (vysˇsˇ´ı rychlost prˇi downloadu) PSTN pocˇ´ıta´ s prˇenosem analogovy´ch dat, ale postupneˇ byla vnitrˇneˇ digitalizova´na (obecneˇ azˇ od mı´stnı´ u´strˇedny), po digitalizaci se mı´sto frekvencˇnı´ho pouzˇ´ıva´ cˇasovy´ multiplex. Aby bylo mozˇne´ po PSTN prˇena´sˇet data, je potrˇeba vytvorˇit „abstraktnı´ na´stavbu“, ktera´ to umozˇnˇuje. Projdeme si neˇktere´ nejzna´meˇjsˇ´ı technologie (chronologicky). Analogovy´ POTS (Plain Old Telephone Service) (PSTN). Ko´dova´nı´:
je zalozˇen na beˇzˇny´ch telefonnı´ch linka´ch
P
5.2
MODEMY
98
• ko´dova´nı´ a deko´dova´nı´ hlasu (analogove´ho) pro prˇenos na digita´lnı´ lince (u digita´lnı´ch u´strˇeden) je prova´deˇno prvkem CODEC (COder-DECoder), • ko´dova´nı´ digita´lnı´ch dat do analogove´ formy je prova´deˇno MODEMem (MOdulator-DEModulator). Existuje vı´ce ru˚zny´ch kodeku˚, naprˇ´ıklad: • PCM (Pulse Coded Modulation) – na pevny´ch telefonnı´ch linka´ch (digita´lnı´ u´strˇedny), snı´ma´ amplitudu signa´lu kazˇdy´ch 125 µs, vzorkuje signa´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 pocˇ´ıta´ s analogovy´mi linkami, dalsˇ´ı technologie jizˇ jsou digita´lnı´ – BRI a PRI. BRI (Basic Rate Interface) je tedy digita´lnı´ technologie, pouzˇ´ıva´ se pro uzˇivatelskou ISDN. Nenı´ trˇeba pouzˇ´ıvat CODEC, digita´lnı´ data jsou posı´la´na prˇ´ımo k (digita´lnı´) u´strˇedneˇ. Komunikacˇnı´ kana´ly: • dva B- (bearer, nosne´) kana´ly pro data a hlas, kazˇdy´ 64 kb/s • jeden D- (delta) kana´l pro rˇ´ıdicı´ informace (signalizaci), a to 16 kb/s, mu˚zˇe slouzˇit pro prˇenos paketu˚ X.25 Kana´ly sdı´lejı´ jeden kabel formou cˇasove´ho multiplexu. PRI (Primary Rate Interface) je take´ digita´lnı´ ISDN rozhranı´, ale je urcˇeno spı´sˇe pro firmy. Je k dispozici 30 (v Evropeˇ) nebo 23 (v USA) B-kana´lu˚ po 64 kb/s, jeden D-kana´l 64 kb/s. Du˚sledkem je vy´razneˇ vysˇsˇ´ı rychlost nezˇ u BRI.
5.2
Modemy
Modem prˇedstavuje DCE, pocˇ´ıtacˇ (nebo jine´ zarˇ´ızenı´) k neˇmu prˇipojeny´ je DTE. Modem (MODulator, DEModulator) je zarˇ´ızenı´, ktere´ moduluje digita´lnı´ data na analogovy´ signa´l (modulace) a zpeˇt (demodulace). Drˇ´ıve se pouzˇ´ıvaly analogove´ modemy, v soucˇasne´ dobeˇ se setka´va´me prˇedevsˇ´ım s digita´lnı´mi modemy (ISDN, DSL). Data se tedy prˇena´sˇejı´ po analogove´m signa´lu, a to pomocı´ kroucene´ dvojlinky (jednoducha´ UTP, telefonnı´ kabel), koaxia´lu (naprˇ´ıklad rozvody pro kabelovou televizi), prˇ´ıpadneˇ bezdra´toveˇ (naprˇ´ıklad mobilnı´ prˇipojenı´ od mobilnı´ch opera´toru˚). Na obra´zku 5.1 je zna´zorneˇn postup digitalizace ve vy´voji od stary´ch cˇisteˇ analogovy´ch modemu˚ podle standardu V.34 po ISDN zarˇ´ızenı´ (DSL zde nema´ smysl uva´deˇt, narozdı´l od ISDN to nenı´ vyta´cˇene´ spojenı´). Vyta´cˇena´ spojenı´ (dial-up) jsou v principu hlasove´, nikoliv datove´ sluzˇby. K digita´lnı´m modemu˚m se vra´tı´me v na´sledujı´cı´ch sekcı´ch te´to kapitoly, zde kra´tce k analogovy´m modemu˚m. Existuje vı´ce ru˚zny´ch standardu˚, pro analogove´ modemy jsou smeˇrodatne´ V.34 (rychlost 28,8 kb/s azˇ 33,6 kb/s) a V.90 (rychlost obvykle 56 kb/s, resp. azˇ 64 kb/s). U modemu˚ V.90 (a take´ V.92) se ve skutecˇnosti standard V.90 pouzˇ´ıva´ jen ve smeˇru k modemu, odesı´la´nı´ dat probı´ha´ 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)
Obra´zek 5.1: Analogove´ a digita´lnı´ linky dle standardu V.34. Analogove´ modemy se prˇipojujı´ pomocı´ konektoru RJ-11, ktery´ je o neˇco uzˇsˇ´ı nezˇ ethernetovy´ RJ-45 (protozˇe se pouzˇ´ıva´ nizˇsˇ´ı typ kroucene´ dvojlinky s me´neˇ pa´ry, tedy nenı´ nutne´ mı´t v konektoru tolik dra´tu˚). Pouzˇ´ıvane´ protokoly: • PPP (viz drˇ´ıve) – autentizace PPP nebo CHAP • Multilink PPP (MPPP) – le´pe vyvazˇuje zatı´zˇenı´ sı´teˇ (umı´ zkombinovat vı´ce portu˚ a tak zvy´sˇit sˇ´ırˇku pa´sma pro prˇenos), pro asynchronnı´ se´riove´ rozhranı´, BRI, PRI • Multichassis Multilink PPP (MPP) – umozˇnˇuje prˇideˇlit uzˇivatelu˚m prˇihlasˇujı´cı´m se na jeden server (s jednı´m modemem) jedine´ telefonnı´ cˇ´ıslo pro dial-up a na vysˇsˇ´ı u´rovni oddeˇlovat jejich komunikaci, vhodne´ 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 pu˚vodneˇ pokusem o vyuzˇitı´ existujı´cı´ch telefonnı´ch rozvodu˚ pro digita´lnı´ telefonii a transport dat ru˚zne´ho charakteru (i obojı´ za´rovenˇ). Zava´deˇnı´ ISDN u´zce souvisı´ s digitalizacı´ telefonnı´ sı´teˇ, hlavneˇ dı´ky ISDN dnes ma´me po cele´ republice digita´lnı´ u´strˇedny. Prˇenos zvuku (telefonnı´ sluzˇby) je realizova´n s vyuzˇitı´m kodeku PCM. Zpoplatneˇnı´ prˇenosu zvuku i dat je za´visle´ na cˇase, jde o vyta´cˇene´ spojenı´. Prˇenosova´ kapacita je rozdeˇlena na B-kana´ly a D-kana´l, existujı´ dva druhy rozhranı´ • BRI (u na´s euroISDN2) pro doma´cnosti a male´ kancela´rˇe • PRI (u na´s euroISDN30) pro veˇtsˇ´ı firmy V BRI je bitovy´ tok rozdeˇlen na cˇasove´ ra´mce po 48 bitech (0,25 ms) – 2 oktety pro kazˇdy´ B-kana´l, 4 bity pro D-kana´l a 12 doplnˇkovy´ch bitu˚, rychlost u BRI je maxima´lneˇ 160 kb/s.
5.3.2
BRI
Zarˇ´ızenı´ v sı´ti • TE1 (Terminal Equipment) – koncove´ zarˇ´ızenı´ s rozhranı´m ISDN • TE2 – nema´ rozhranı´ ISDN (analogovy´ telefon, analogovy´ modem apod.), k ISDN se prˇipojuje pomocı´ TA (adapte´ru) • NT (network termination, ukoncˇenı´ sı´teˇ) – rozhranı´, ke ktere´mu se prˇipojujı´ TE1 a TA, ma´ dveˇ cˇa´sti: – NT1 – zajisˇt’uje fyzicke´ prˇipojenı´, transformuje signa´ly – NT2 – hornı´ cˇa´st, umozˇnˇuje prˇipojit TE1 a TA (azˇ 8) Mezi nimi jsou rozhranı´ U, T (terminal), S (system), R (rate). Struktura je na obra´zku 5.2. ISDN telefon
PC
S
T NT2
Analog. telefon
TA
NT1
U síť
R
Obra´zek 5.2: Zarˇ´ızenı´ v sı´ti ISDN BRI B-kana´ly pracujı´ s prˇepojova´nı´m okruhu˚ a majı´ vysˇsˇ´ı prˇenosovou rychlost, D-kana´ly pracujı´ s pakety, a to se spojenı´m i bez spojenı´.
E
5.4
TECHNOLOGIE XDSL
101
V ISDN je definova´na fyzicka´, linkova´ a sı´t’ova´ vrstva. Model je 3D (podobneˇ jako ATM), existujı´ roviny uzˇivatelska´, rˇ´ıdicı´ a rovina managementu (spra´vnı´). • fyzicka´ vrstva – protokoly fyzicke´ vrstvy zahrnujı´ prˇedevsˇ´ım definici rozhranı´ S, T, U, R • linkova´ vrstva – spojovy´ protokol LAPD • sı´t’ova´ vrstva – protokol sı´t’ove´ vrstvy pouzˇ´ıva´ D-kana´l, po neˇm posı´la´ zpra´vy, princip komunikace je podobny´ jako u sı´tı´ X.25 Spojenı´ je vyta´cˇene´ (tarifikace za´visla´ na de´lce spojenı´) a jeho nava´za´nı´ trva´ jen kolem 2 s, proto nema´ smysl necha´vat spojenı´ aktivnı´ neusta´le. Navazova´nı´ spojenı´ probı´ha´ na D-kana´lu (ten by´va´ neusta´le aktivnı´, veˇtsˇinou nenı´ zpoplatneˇn), odesı´lajı´ se aktivacˇnı´ informace (telefonnı´ cˇ´ıslo prˇ´ıjemce, identifikace volajı´cı´ho uzlu, typ vola´nı´ – hlasove´, datove´ nebo faxove´, apod.), pak je prˇideˇlena IP adresa.
5.4
Technologie xDSL
xDSL (Digital Subscriber Line) je skupina sˇirokopa´smovy´ch technologiı´, ktera´ v sobeˇ sdruzˇuje neˇkolik ru˚zny´ch technologiı´ (ADSL, SDSL, HDSL, HDSL-2, G.SHDL, IDSL, VDSL). Mu˚zˇe to by´t technologie „prvnı´ mı´le“ pro prˇipojenı´ k Internetu, resp. k NSP (Network Service Provider). Jedna´ se o vyhrazenou sluzˇbu, point-to-point.
P
Je to sluzˇba se spojenı´m, ale tarifikace neby´va´ za´visla´ na cˇase.
5.4.1
ADSL
ADSL (Asymmetric Digital Subscriber Line) je asymetricka´ sluzˇba. Asymetricka´ proto, zˇe downstream (stahova´nı´ dat do DTE) je rychlejsˇ´ı nezˇ upstream (odesı´la´nı´ dat do sı´teˇ). Teoreticky lze dosa´hnout rychlostı´ azˇ 24 Mb/s (v noveˇjsˇ´ım standardu dokonce azˇ 48 Mb/s). U na´s nabı´zena´ rychlost je 8 Mb/s nebo 16 Mb/s pro downstream, ale rea´lna´ rychlost mu˚zˇe by´t nizˇsˇ´ı. Upstream by´va´ na rychlosti 1 Mb/s. Rychlost je ovlivneˇna vı´ce ru˚zny´mi krite´rii. Je to nejen pouzˇite´ zarˇ´ızenı´ a prˇenosove´ protokoly, ale take´ de´lka spoje – cˇ´ım veˇtsˇ´ı vzda´lenost k mı´stnı´ u´strˇedneˇ, tı´m pomalejsˇ´ı spojenı´. Rozsah
Sˇ´ırˇka
´ cˇel U
0 kHz –4 kHz 4 kHz –26 kHz 26 kHz –138 kHz 138 kHz –1100 kHz
4 kHz 22 kHz 112 kHz 962 kHz
prˇenos hlasu (telefon) na´raznı´kove´ pa´smo upstream downstream
Tabulka 5.1: Vyuzˇitı´ prˇenosove´ho pa´sma v ADSL V technologii ADSL (a taky v dalsˇ´ıch DSL technologiı´ch) se navy´sˇenı´ rychlosti dosahuje kromeˇ jine´ho i odkloneˇnı´m datove´ho toku z telefonnı´ch linek na datovou sı´t’ poskytovatele (obvykle neˇkterou WAN sı´t’na opticky´ch kabelech). Princip je naznacˇen na obra´zku 5.3.
P
E
5.4
TECHNOLOGIE XDSL
102 telefonní síť DTE
Ústředna
datová síť
Obra´zek 5.3: Provedenı´ ADSL Oddeˇlenı´ upstream a downstream dat
– mozˇnosti:
1. FDM (frekvencˇnı´ multiplex) – frekvence pro upstream a downstream jsou striktneˇ oddeˇleny, neprˇekry´vajı´ se (dajı´ se oddeˇlit jednoduchy´m filtrem)
P
2. potlacˇenı´ ozveˇny (EC, Echo Cancellation) – kana´ly pro upstream a downstream se cˇa´stecˇneˇ prˇekry´vajı´, pak jsou oddeˇleny pomocı´ telekomunikacˇnı´ vidlice FDM je jednodusˇsˇ´ı na implementaci (take´ je mensˇ´ı pravdeˇpodobnost prˇeslechu˚ prˇi velmi velke´m mnozˇstvı´ ADSL zarˇ´ızenı´ na jednom kabelu), EC le´pe vyuzˇ´ıva´ frekvencˇnı´ pa´sma (kana´ly na nizˇsˇ´ıch frekvencı´ch jsou obvykle me´neˇ rusˇeny) a prˇenos je rychlejsˇ´ı. Dnes se pouzˇ´ıva´ spı´sˇe EC. Modulace v ADSL
– pouzˇ´ıva´ se CAP nebo DMT.
CAP (Carrieless amplitude phase modulation) je dalsˇ´ı mozˇny´ typ modulace pro ADSL. Tato modulace je velmi podobna´ QAM modulaci. CAP pouzˇ´ıva´ pro cele´ prˇena´sˇene´ pa´smo (1,1 MHz) jediny´ kmitocˇet, fakticky nedocha´zı´ k deˇlenı´ na kana´ly.
P
DMT (Discrete MultiTone) rozdeˇlı´ cele´ pa´smo na kana´ly prˇiblizˇneˇ po 4 kHz (celkem kolem 255 kana´lu˚), kana´ly 7–32 pro upstream, od 33 pro downstream. Pru˚beˇzˇneˇ se sleduje kvalita prˇenosu v jednotlivy´ch kana´lech, prˇenos se adaptivneˇ rozkla´da´ na ty kana´ly, ktere´ jsou povazˇova´ny za pra´veˇ nejkvalitneˇjsˇ´ı. Narozdı´l od CAP se pouzˇ´ıva´ vı´ce nosny´ch kmitocˇtu˚ (to jsou ty to´ny v na´zvu, take´ se nazy´va´ Multicarrier Modulation). V soucˇasne´ dobeˇ se setka´me spı´sˇe s DMT. Podrobnosti: http://access.feld.cvut.cz/view.php?cisloclanku=2004072903 Standardy pro zarˇı´zenı´ Ve vsˇech standardech se rozlisˇuje varianta Annex A (over POTS – prˇes analogove´ linky)), Annex B (over ISDN) a ADSL Lite. V soucˇasne´ dobeˇ existujı´ tyto standardy: • ADSL (pu˚vodnı´) – Annex A a Annex B s propustnostı´ azˇ 8 Mb/s (download), resp. 1 Mb/s (upload), a da´le ADSL Lite (jesˇteˇ nizˇsˇ´ı propustnost – do 1.5 Mb/s) • ADSL2 – druha´ generace, rychlost na downloadu azˇ 12 Mb/s • ADSL2+ – zvy´sˇenı´ rychlosti azˇ na 24 Mb/s (rea´lneˇ azˇ 16 Mb/s) • ADSL2++ – opeˇt zvy´sˇenı´ rychlosti, teoreticky azˇ 48 Mb/s
P
5.4
TECHNOLOGIE XDSL
103
Annex A u na´s nelze provozovat, proto bychom si prˇi koupi ADSL zarˇ´ızenı´ meˇli da´t pozor na to, aby podporovalo Annex B. ADSL Lite je odlehcˇena´ verze ADSL, kterou bylo mozˇno pouzˇ´ıvat na me´neˇ kvalitnı´ch spojı´ch. Instalace ADSL Lite byla pomeˇrneˇ jednoducha´, ale rychlost byla o neˇco nizˇsˇ´ı nezˇ u klasicke´ ADSL, nepouzˇ´ıval se splitter (viz da´le).
5.4.2
Implementace ADSL
V ADSL se pouzˇ´ıvajı´ tato zarˇ´ızenı´: • datova´ cˇi hlasova´ koncova´ zarˇ´ızenı´ (pocˇ´ıtacˇ, telefon, NAS, atd.), digita´lnı´ a analogova´
P
• modem (MODulator/DEModulator) – moduluje digita´lnı´ signa´l na analogovy´ (sˇ´ırˇka prˇiblizˇneˇ 1,1 MHz) a zpeˇtneˇ demoduluje, prˇipojujı´ se k neˇmu datova´ koncova´ zarˇ´ızenı´ • splitter – sloucˇenı´ hlasove´ho prˇenosu a modulovany´ch dat (frekvencˇnı´ multiplex), prˇipojuje se k neˇmu modem a hlasova´ koncova´ zarˇ´ızenı´ (analogova´), na telefonnı´ linku posı´la´ signa´l v cˇasove´m multiplexu (TDM – time division multiplex), varianta ADSL Lite nepouzˇ´ıva´ splitter • DSLAM (DSL Access Multiplexer) – na straneˇ ISP, sdruzˇuje spojenı´ z ISP splitteru˚ pro jednotliva´ prˇipojenı´ V praxi je u u´cˇastnicky´ch prˇ´ıpojek mohou by´t modem a splitter v jednom zarˇ´ızenı´ (internı´, integrovany´), na straneˇ ISP by´vajı´ oddeˇleny ve dvou zarˇ´ızenı´ch.1 Je vy´hodneˇjsˇ´ı mı´t splitter zvla´sˇt’. Pokud nepouzˇ´ıva´me zˇa´dna´ analogova´ zarˇ´ızenı´ (analogovy´ telefon), meˇli bychom se splitteru zbavit, protozˇe mu˚zˇe by´t zdrojem mı´rny´ch posunu˚ signa´lu a tı´m i poruch. Místní ústředna počítač
modem
telefon
splitter
DSLAM
ISP splitter
PSTN
Obra´zek 5.4: Zarˇ´ızenı´ v sı´ti ADSL Externı´ splitter u u´cˇastnicke´ho modemu (tj. kdyzˇ ho ma´me zvla´sˇt’) je mala´ krabicˇka, do ktere´ se prˇipojujı´ 3 kabely, vsˇechny s rozhranı´m RJ-11. Proto bychom meˇli da´vat pozor, co kam ma´me prˇipojit (vstupy/vy´stupy jsou oznacˇeny): • kabel z rozhranı´ oznacˇene´ho PHONE povede zjevneˇ do analogove´ho telefonu, • kabel z rozhranı´ oznacˇene´ho MODEM povede do ADSL modemu (ADSL routeru), • kabel z rozhranı´ oznacˇene´ho obvykle LINE zapojı´me prˇ´ımo do telefonnı´ za´suvky. Digita´lnı´ telefony samozrˇejmeˇ ke splitteru neprˇipojujeme! 1
Modem a splitter v jednom zarˇ´ızenı´ najdeme spı´sˇe u levneˇjsˇ´ıch rˇesˇenı´ pro SOHO (Small Office–Home Office), tj. pro doma´cnosti a male´ firmy.
$
5.4
TECHNOLOGIE XDSL
104
DTE
Ethernet
.. . DTE
ADSL modem
AD SL
.. . Wi-Fi
ADSL modem
DSLAM L ADS
Obra´zek 5.5: ADSL je technologie prvnı´ mı´le Agregace = sdı´lenı´ prˇı´pojky ADSL. Kazˇdy´ ISP rozdeˇlı´ kapacitu linky, kterou ma´ k dispozici, formou cˇasove´ho multiplexu. Vzorec pro agregacˇnı´ pomeˇr je na´sledujı´cı´:
P
rychlost(ISP ) agregacˇnı´ pomeˇr = P i rychlost(i)
Typicke´ hodnoty agregace mohou by´t naprˇ´ıklad 1 : 50, 1 : 20.
FUP (Fair User Policy) je omezenı´ toku dat (veˇtsˇinou se odvozuje od mnozˇstvı´ prˇena´sˇeny´ch dat). V soucˇasne´ dobeˇ nenı´ u ADSL FUP uplatnˇova´no. FUP v ADSL obvykle souvisı´ s protokolem PPPoA. Proto pokud zjistı´me, zˇe FUP je na nasˇ´ı lince uplatnˇova´no, meˇli bychom projı´t konfiguraci ADSL modemu a zjistit, jestli je mozˇne´ nastavit mı´sto PPPoA (PPP over ATM) protokol PPPoE (PPP over Ethernet). U starsˇ´ıch ADSL modemu˚ to nejde, ale u noveˇjsˇ´ıch by to nemeˇl by´t proble´m.
Obra´zek 5.6: Zapouzdrˇenı´ do PPPoE
P
5.4
TECHNOLOGIE XDSL
ADSL modemy
105
– parametry, ktere´ na´s mohou zajı´mat
1. standard ITU G.922.1, Annex B (tj. prˇ´ıloha B, kdezˇto modemy podle prˇ´ılohy A by v CˇR nefungovaly)
$
2. ADSL2+ (to 2+ znamena´, zˇe modem doka´zˇe dosa´hnout vysˇsˇ´ıch deklarovany´ch rychlostı´, na downstreamu azˇ 24 Mb/s)) 3. skutecˇna´ rychlost (upstream, downstream), obvykle neby´va´ proble´m, pokud nejsme moc daleko od DSLAMu 4. handshake (nava´za´nı´ spojenı´ prˇi zapnutı´, negociace s DSLAM) – veˇtsˇina prˇ´ıstroju˚ se nedrzˇ´ı standardu, DSLAMy nasˇteˇstı´ odchylky veˇtsˇinou tolerujı´, ale ze specifikace veˇtsˇinou tento parametr nevycˇteme (meˇli bychom probrat recenze) 5. ADSL router – za´rovenˇ smeˇrovacˇ, dovoluje prˇipojit vı´ce zarˇ´ızenı´ (LAN) 6. vybavenost Wi-Fi – ADSL modem by´va´ kromeˇ RJ-45 portu˚ cˇasto vybaven rozhranı´m Wi-Fi, vy´hodou je prˇ´ıtomnost tlacˇ´ıtka na vypnutı´ Wi-Fi (vysˇsˇ´ı spotrˇeba proudu) 7. PPPoE, mu˚zˇe by´t PPPoA nebo IPoA (urcˇuje, do paketu ktere´ho protokolu se datove´ pakety zapouzdrˇujı´ prˇi odchodu do WAN, idea´lneˇ do paketu PPPoE) 8. webove´ rozhranı´ – konfigurace (neˇkterˇ´ı vy´robci jsou notoricky zna´mı´ svy´m neprˇehledny´m rozhranı´m), prˇi prvnı´m zapnutı´ modemu by´va´ cˇasto dostupne´ jen prˇes RJ-45 9. diagnosticke´ na´stroje, podpora QoS, HW firewall, atd.
5.4.3
ADSL na straneˇ ISP
DSLAM je bra´na do datove´ sı´teˇ poskytovatele. Existujı´ mensˇ´ı DSLAMy pro prˇipojenı´ 24 nebo 48 DSL linek (a obvykle stejny´ pocˇet pro POTS – analogovy´ telefon), a pak veˇtsˇ´ı pro tisı´ce linek. Obvykle podporuje protokoly PPPoE i PPPoA.
P
DSLAM ma´ rozhranı´ RJ-11 smeˇrem k za´kaznı´kovi a pak dalsˇ´ı rozhranı´ – veˇtsˇinou dveˇ RJ-45 pro Gigabit Ethernet nebo rychlejsˇ´ı, prˇ´ıpadneˇ rozhranı´ pro Fast Ethernet (LAN). Administrace se prova´dı´ prˇes webove´ rozhranı´, a nebo fyzicky prˇes RJ-232 (COM, je dostupna´ redukce RJ-232 na USB), atd. Na obra´zku 5.7 je zjednodusˇeny´ na´kres struktury sı´teˇ na straneˇ poskytovatele Internetu. Pojmy k tomuto obra´zku: • PTA je sˇirokopa´smovy´ server, prova´dı´ se zde konfigurace IP adres, autentifikace uzˇivatelu˚, autorizace, u´cˇtova´nı´ (RADIUS) • AP (Access Point) je prˇ´ıstupovy´ bod pro konkre´tnı´ho ISP, prˇes ktery´ lze prˇistupovat z virtua´lnı´ sı´teˇ tohoto ISP k smeˇrovacˇi na Internet ´ koly U 1. V neˇktere´m internetove´m obchodeˇ proda´vajı´cı´m sı´t’ove´ prvky (http://pc.itek.cz, http://www.intelek.cz, http://www.czechcomputer.cz, atd. podle vlastnı´ho vy´beˇru, prˇ´ıpadneˇ pouzˇijte srovna´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íť
Obra´zek 5.7: ADSL – na straneˇ ISP
jako naprˇ´ıklad http://www.heureka.cz) projdeˇte nabı´dky ru˚zny´ch typu˚ modemu˚. Zjisteˇte, jake´ typy modemu˚ se v nabı´dka´ch nacha´zejı´ (ADSL, GSM, analogovy´ apod.), v jake´m provedenı´ a prˇes ktere´ rozhranı´ se prˇipojujı´ k pocˇ´ıtacˇi (cˇasto prˇes USB, RJ-45, ExpressCard), v jaky´ch cenovy´ch relacı´ch, jaky´ je funkcˇnı´ a cenovy´ rozdı´l mezi samostatny´m modemem a Wi-fi routerem s ADSL modulem. 2. Pokud ma´te prˇ´ıstup k neˇktere´mu ADSL modemu, projdeˇte si jeho konfiguracˇnı´ rozhranı´.
5.4.4
Dalsˇı´ xDSL technologie
High bit-rate Digital Subscriber Line (HDSL) nenı´ urcˇena pro u´cˇastnicke´ prˇ´ıpojky, pouzˇ´ıvajı´ ji ISP pro propojenı´ pobocˇkovy´ch u´strˇeden, prˇ´ıpadneˇ ji mohou vyuzˇ´ıt velke´ firmy pro sve´ vnitrˇnı´ potrˇeby. Vyzˇaduje dva nebo trˇi pa´ry telefonnı´ch vodicˇu˚, cozˇ je povazˇova´no za jednu z nevy´hod. Je to symetricka´ technologie (stejny´ rozsah pa´sem pro downstream a upstream), ale mu˚zˇe pracovat i asymetricky. Podporuje pouze prˇenos dat, neobsahuje podporu telefonnı´ch hovoru˚. Pro oddeˇlenı´ downstreamu a upstreamu pouzˇ´ıva´ pouze Echo Cancellation (EC), ne frekvencˇnı´ multiplex. HDSL-2 (take´ SHDSL – SinglePair HDSL) je varianta HDSL, ktera´ pouzˇ´ıva´ pouze jeden pa´r telefonnı´ch vodicˇu˚, tedy prˇi zava´deˇnı´ technologie HDSL-2 na samotne´m vedenı´ telefonnı´ch linek nenı´ trˇeba nic meˇnit.
P
5.4
TECHNOLOGIE XDSL
107
Symetric Digital Subscriber Line (SDSL) je rozsahem funkcı´ podobna´ technologii ADSL, ale je symetricka´ (stejny´ rozsah pa´sem – pocˇet kana´lu˚ – pro upstream a downstream), neobsahuje podporu telefonnı´ch hovoru˚ (pouze pro data, nelze prˇipojit analogovy´ telefon). Princip prˇenosu je podobny´ HDSL. Pouzˇ´ıva´ se pro u´cˇastnicke´ prˇ´ıpojky, u ktery´ch se preferuje symetricˇnost prˇenosu. Obvykla´ rychlost je azˇ 2,3 Mb/s, dosah azˇ 5 km. IDSL (ISDN Digital Subscriber Line) je hybrid ISDN a xDSL technologiı´. IDSL je poskytova´na tam, kde jesˇteˇ nelze zprovoznit ADSL (v u´strˇedneˇ nenı´ funkcˇnı´ DSLAM), a nebo ISP. Vyuzˇ´ıva´ rozhranı´ „U“ pro ISDN, prˇena´sˇ´ı pouze data, prˇipojenı´ prˇes ISDN BRI. Narozdı´l od ISDN nenı´ vyta´cˇena´ a je rychlejsˇ´ı (pomalejsˇ´ı nezˇ ADSL), pouzˇ´ıva´ stejnou modulaci jako ISDN. VDSL (Very High Bit-Rate Digital Subscriber Line) je povazˇova´na za na´slednı´ka ADSL. Je take´ asymetricka´ (mu˚zˇe by´t nastavena na symetricky´ prˇenos), pouzˇ´ıva´ sˇirsˇ´ı pa´smo nezˇ ADSL (prota´hnutı´ na vysˇsˇ´ı frekvence), a z toho du˚vodu je rychlejsˇ´ı. Rychlost na kvalitnı´ telefonnı´ UTP dosahuje azˇ 52 Mb/s (asymetricka´, downstream) nebo 36 Mb/s (symetricka´ varianta). Teoreticky azˇ 200 Mb/s, rea´lneˇ opravdu jen kolem 50 Mb/s.
P
P
Zatı´mco ADSL prova´dı´ prˇenos na vzda´lenost azˇ 5 km (prˇi vysˇsˇ´ıch rychlostech me´neˇ), VDSL pouze neˇco prˇes 1 km, cozˇ je danˇ za rozsˇ´ırˇenı´ pa´sma. Ovsˇem pokud chceme opravdu vyuzˇ´ıt vysoke´ rychlosti nabı´zene´ VDSL, tak bychom meˇli by´t maxima´lneˇ 500 m od DSLAMu. Upstream a downstream jsou oddeˇleny frekvencˇnı´m multiplexem podobneˇ jako u ADSL.
Obra´zek 5.8: Porovna´nı´ frekvencı´ ADSL a VDSL2 Rozsˇ´ırˇenı´ VDSL bohuzˇel za´visı´ na telekomunikacˇnı´ch organizacı´ch, tato technologie musı´ by´t podporova´na v telekomunikacˇnı´ch u´strˇedna´ch. Dalsˇı´ 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
TELEFONNI´ SI´TEˇ A TELEFONNI´ U´STRˇEDNY
108
´ koly U V roce 2011 se v nabı´dka´ch telefonnı´ch opera´toru˚ konecˇneˇ objevila technologie VDSL. Zjisteˇte, jaka´ zarˇ´ızenı´ podporujı´cı´ VDSL jsou momenta´lneˇ k dispozici (nahle´dneˇte do internetovy´ch obchodu˚) a jake´ jsou jejich parametry.
5.5
Telefonnı´ sı´teˇ a telefonnı´ u´strˇedny
Nynı´ se podı´va´me podrobneˇji na problematiku telefonnı´ch sı´tı´ a u´strˇeden, prˇedevsˇ´ım pobocˇkovy´ch telefonnı´ch u´strˇeden (PBX).
5.5.1
Slucˇova´nı´ linek
Prˇedchu˚dcem sı´teˇ SDH, se kterou jsme se sezna´mili v kapitole o WAN sı´tı´ch, je sı´t’PDH (Pleisochronous Digital Hierarchy). Zatı´mco SDH je „synchronnı´ “ (komunikace je synchronizova´na v cele´ sı´ti, s cˇasovy´m multiplexem), PDH je „te´meˇrˇ synchronnı´ “ – pleisochronnı´, tedy komunikace je te´meˇrˇ synchronizova´na (tolerujı´ se male´ odlisˇnosti v rychlosti). V PDH se zacˇalo vyuzˇ´ıvat slucˇova´nı´ linek za u´cˇelem zvy´sˇenı´ kapacity prˇenosu. Znacˇenı´ a neˇktere´ dalsˇ´ı prvky se odlisˇujı´ v norma´ch platny´ch pro Evropu od norem platny´ch v Americe a Japonsku. Zatı´mco v Americe a Japonsku se setka´me s T-linkami (T-carrier, normy podle ITU-T), v Evropeˇ se pouzˇ´ıvajı´ E-linky (E-carrier, normy podle CEPT – Evropske´ rady pro spra´vu posˇt a telekomunikacı´). Princip vycha´zı´ ze sdruzˇova´nı´ linek do svazku˚, ktere´ majı´ logicky vysˇsˇ´ı prˇenosovou kapacitu a tı´m i rychlost prˇenosu. V obou norma´ch jsou linky rˇa´du 0 (nula) tvorˇeny jedinou linkou o rychlosti 64 kb/s. V rˇa´du 1 se sdruzˇuje bud’ 24 nebo 30 linek datovy´ch a 2 linky signa´lnı´ (neprˇena´sˇejı´ data, ale rˇ´ıdicı´ signa´ly), vznika´ T1-linka (Amerika a Japonsko) nebo E1-linka (Evropa). Sdruzˇenı´m cˇtyrˇ T1 linek vznikne T2 linka, podobneˇ u E-linek. Postup a navysˇova´nı´ prˇenosove´ rychlosti najdeme v tabulce 5.2. Znacˇenı´
Dat. kana´lu˚
Prˇen. rychlost
Znacˇenı´
Dat. kana´lu˚
Prˇ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: Srovna´nı´ T-carrier (Amerika, Japonsko) a E-carrier (Evropa) linek Fyzicky by´vajı´ sdruzˇova´ny spoje na krouceny´ch dvoulinka´ch (UTP), cozˇ pocˇetneˇ souhlası´: 30 + 2 = 32, cozˇ je deˇlitelne´ cˇ´ıslem 4 (pocˇtem dra´tu˚ v UTP). Ra´mec E1 se skla´da´ z 32 timeslotu˚ („oken“ o stejne´ de´lce – 125 µs), prˇena´sˇeny´ch paralelneˇ. Jeden timeslot obsahuje prostor pro jeden oktet (8 bitu˚), od toho se odvı´jı´ prˇenosova´ kapacita.
TELEFONNI´ SI´TEˇ A TELEFONNI´ U´STRˇEDNY
5.5
SONET
SDH
STS-1 STS-3 STS-12 STS-48
STM-0 STM-1 STM-4 STM-16
Prˇen. rychlost 52 Mb/s 156 Mb/s 622 Mb/s 2 488 Mb/s
109 SONET
SDH
Prˇ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
´ rovneˇ a rychlosti v sı´tı´ch SONET a SDH Tabulka 5.3: U SDH se od PDH lisˇ´ı prˇedevsˇ´ım vyuzˇitı´m opticky´ch kabelu˚ (jednovidovy´ch) a dokonalejsˇ´ı synchronizacı´, ktera´ se prova´dı´ prˇes celou sı´t’ pomocı´ atomovy´ch hodin. Velikost timeslotu je stejna´ (125 µs), ale multiplexova´nı´ funguje trochu jinak (protozˇe uzˇ se neodvı´jı´ od UTP kabelu).
P
Slucˇova´nı´ linek take´ zna´me z podkapitoly o ISDN – BRI rozhranı´ definuje slucˇova´nı´ 2 datovy´ch a jedne´ signa´lnı´ linky (uzˇivatelska´ Euro-ISDN2), PRI slucˇuje 30 datovy´ch a jednu signa´lnı´ linku (Euro-ISDN30), s tı´m, zˇe datove´ kana´ly lze da´le deˇlit do podskupin (naprˇ. cˇa´st pro prˇenos dat z pocˇ´ıtacˇove´ LAN a cˇa´st pro Fax).
5.5.2
Telefonnı´ u´strˇedny
Jizˇ vı´me, zˇe telefonnı´ u´strˇedny jsou usporˇa´da´ny hierarchicky – na nejvysˇsˇ´ıch uzlech hierarchie jsou TTO (tranzitnı´ telefonnı´ u´strˇedny), nı´zˇe jsou UTO (uzlove´ telefonnı´ u´strˇedny), pod nimi MTO (mı´stnı´ telefonnı´ u´strˇedny), ke ktery´m se jizˇ prˇipojujı´ u´cˇastnicke´ prˇ´ıpojky a nebo v prˇ´ıpadeˇ veˇtsˇ´ıch firem pobocˇkove´ u´strˇedny (PBX). Pobocˇkove´ u´strˇedny se pouzˇ´ıvajı´ k zajisˇt’ova´nı´ vnitrˇnı´ch hovoru˚ uvnitrˇ firem a take´ ke spojova´nı´ hovoru˚ mezi vnitrˇnı´ a vneˇjsˇ´ı telekomunikacˇnı´ sı´tı´. Jsou vlastneˇ prˇ´ıpojny´m bodem do sı´teˇ poskytovatele te´to sluzˇby (DTE). Telefonnı´ u´strˇedny deˇlı´me na analogove´ a digita´lnı´, ale v soucˇasne´ dobeˇ se veˇtsˇinou jizˇ setka´me jen s digita´lnı´mi. Analogove´ pobocˇkove´ u´strˇedny lze prˇipojit na beˇzˇne´ telefonnı´ linky PSTN sı´teˇ (HTS – hlavnı´ telefonnı´ stanice, drˇ´ıv se rˇ´ıkalo „sta´tnı´ linka“, ale dnes uzˇ tyto linky sta´tu nepatrˇ´ı), digita´lnı´ u´strˇedny navı´c take´ na • • • •
P P
beˇzˇna´ telefonnı´ sı´t’, E1 u starsˇ´ıch digita´lnı´ch u´strˇeden, BRI a PRI ISDN, datovou sı´t’VoIP, datovou bezdra´tovou sı´t’(DECT bezdra´tove´ pobocˇky rozmı´steˇne´ po area´lu), atd.
VoIP je ve sve´ podstateˇ datovou sluzˇbou, tedy nevyzˇaduje prˇipojenı´ do telekomunikacˇnı´ sı´teˇ (pokud ma´me jen cˇisteˇ VoIP u´strˇednu), stacˇ´ı prˇipojenı´ do datove´ sı´teˇ. Tomuto typu sluzˇeb se budeme veˇnovat v na´sledujı´cı´ podkapitole. ´ strˇedna mu˚zˇe by´t bud’ prˇ´ımo hardwarove´ zarˇ´ızenı´, a nebo software nainstalovany´ na vhodneˇ U prˇipojene´m pocˇ´ıtacˇi. Podı´va´me se na neˇkolik softwarovy´ch rˇesˇenı´ (jedna´ se o serverove´ aplikace). Kromeˇ softwaru potrˇebujeme take´ hardware, ktery´m stanici s tı´mto softwarem prˇipojı´me ke zvolene´mu rozhranı´ do sı´teˇ poskytovatele sluzˇby (telekomunikacˇnı´ho opera´tora).
J
5.6
VOIP
110
Asterisk je popula´rnı´ open-source software pro vytva´rˇenı´ VoIP u´strˇeden. Konfiguruje se prˇes webove´ rozhranı´, existuje take´ neˇkolik GUI (nutno zvla´sˇt’ doinstalovat, naprˇ. FreePBX), da´le lze k aplikaci prˇistupovat programoveˇ prˇes API z aplikacı´ napsany´ch v beˇzˇny´ch programovacı´ch jazycı´ch. Asterisk najdeme take´ v mnohy´ch proda´vany´ch hardwarovy´ch u´strˇedna´ch. Cisco Unified Communications Manager (drˇ´ıve Cisco CallManager) lze instalovat na zarˇ´ızenı´ch, ktera´ tento produkt podporujı´ (veˇtsˇinou na serverech Cisco). jedna´ se o komercˇnı´ produkt s obecneˇ dobrou vybavenostı´ funkcemi. Microsoft Response Point je syste´m s jednoduchou konfiguracı´ pro mensˇ´ı telefonnı´ sı´teˇ (do 50 stanic, spı´sˇe me´neˇ, za´lezˇ´ı na konkre´tnı´m hardwaru). Beˇzˇ´ı pouze na syste´mech Windows od verze XP. Tento produkt vsˇak uzˇ oficia´lneˇ nenı´ podporova´n. Dalsˇ´ı 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 U Vyberte si neˇktere´ z vy´sˇe uvedeny´ch rˇesˇenı´ pro u´strˇedny a o zjisteˇte o neˇm podrobneˇjsˇ´ı informace.
5.6 5.6.1
VoIP Princip
VoIP (Voice over IP, „internetova´ telefonie“, IP telefonie) je technologie pro prˇenos digitalizovane´ho hlasu v IP datagramech. Hovor mu˚zˇe by´t veden i mezi vı´ce nezˇ dveˇma u´cˇastnı´ky. Striktneˇ vztato, existujı´ dva typy internetove´ telefonie – ATM telefonie, ktera´ uzˇ vymı´ra´, a IP telefonie, ktera´ je naopak na vzestupu (sve´ho cˇasu se take´ hodneˇ mluvilo o vyuzˇitı´ ISDN). Kazˇdy´ z teˇchto typu˚ ma´ sve´ vy´hody a nevy´hody, ktere´ vesmeˇs vyply´vajı´ z principu prˇenosu (ATM ma´ garanci sluzˇeb, IP je zase snadno prˇ´ıstupny´ a pruzˇny´ syste´m). Koncova´ zarˇ´ızenı´ mohou by´t bud’ hardwarove´ VoIP telefony a nebo jde o software, VoIP aplikaci. Telefonovat mu˚zˇeme • v ra´mci sı´teˇ poskytovatele, • mimo sı´t’poskytovatele, ale porˇa´d v ra´mci datove´ sı´teˇ, • na beˇzˇne´ telefonnı´ cˇ´ıslo do verˇejne´ telekomunikacˇnı´ sı´teˇ.
P
5.6
VOIP
111
Trˇetı´ mozˇnost vyzˇaduje vytvorˇenı´ spojenı´ prˇes VoIP bra´nu, ktera´ tvorˇ´ı rozhranı´ mezi datovou a verˇejnou telekomunikacˇnı´ sı´tı´. Volı´ se VoIP bra´na co nejblı´zˇ cı´li, aby co nejdelsˇ´ı cˇa´st spojenı´ vedla po datovy´ch linka´ch (resp. aby cˇa´st spojenı´ po telekomunikacˇnı´ch linka´ch byla pokud mozˇno „mı´stnı´ hovor“).
P
V soucˇasne´ dobeˇ se setka´va´me s komplexneˇ rˇesˇeny´mi pobocˇkovy´mi u´strˇednami pro firmy, ktere´ si takto mohou zarˇ´ıdit vlastnı´ VoIP sı´t’. Jejich konkurencı´ jsou vsˇak nabı´dky mobilnı´ch opera´toru˚, ktere´ jsou, zvla´sˇteˇ pro veˇtsˇ´ı firmy, velmi vy´hodne´. Obvykle se vyzˇaduje splneˇnı´ teˇchto pozˇadavku˚: • • • •
rychlost prˇipojenı´ k Internetu prˇes 128 kb/s maxima´lnı´ zpozˇdeˇnı´ na spoji k serveru poskytovatele 150 ms maxima´lnı´ kolı´sa´nı´ zpozˇdeˇnı´ 30 ms ztra´tovost datovy´ch jednotek pod 2 %, le´pe kolem 1 %
Da´le si mu˚zˇe poskytovatel stanovit pozˇadavky na zpu˚sob implementace NAT apod. Tyto pozˇadavky jsou vsˇak relativnı´, za´lezˇ´ı na celkove´m vytı´zˇenı´ spoje (proto je du˚lezˇite´ pouzˇ´ıvat QoS) a obvykle´m pocˇtu hovoru˚ na spoji vedeny´ch. VoIP vyzˇaduje sice mensˇ´ı sˇ´ırˇku pa´sma nezˇ datove´ sluzˇby, ale zato pokud mozˇno konstantnı´. Neˇktere´ typy prˇipojenı´ k Internetu nejsou pro VoIP moc vhodne´ (naprˇ´ıklad neˇktera´ mobilnı´ prˇipojenı´, jako je GSM, GPRS cˇi EDGE), u Wi-Fi je vyuzˇitı´ diskutabilnı´ (zvla´sˇteˇ tehdy, kdyzˇ je oblast prˇ´ılisˇ zarusˇena´, mu˚zˇe ztra´tovost datovy´ch jednotek dosa´hnout prˇ´ılisˇ velke´ hodnoty). Nejdrˇ´ıv je nutne´ nava´zat spojenı´. Navazova´nı´ spojenı´ prova´dı´ prˇ´ıslusˇny´ aplikacˇnı´ protokol, a to bud’ SIP nebo H.323. Po nava´za´nı´ spojenı´ se prˇena´sˇeny´ zvuk nejdrˇ´ıv digitalizuje – prova´dı´ se vzorkova´nı´ na 8 kHz. Prˇenos se prova´dı´ pomocı´ kodeku (coder/decoder), ktery´ prova´dı´ ko´dova´nı´ signa´lu a za´rovenˇ jeho kompresi.
$
VoIP je implementova´n i v ru˚zny´ch aplikacı´ch, naprˇ´ıklad v notoricky zna´me´ aplikaci Skype.
5.6.2
Protokoly
SIP (Session Initiation Protocol) je textoveˇ orientovany´ protokol vyvinuty´ prˇ´ımo pro pouzˇitı´ na Internetu (IETF), v roce 1999. Je to protokol aplikacˇnı´ vrstvy pro vytva´rˇenı´, udrzˇova´nı´ a ukoncˇova´nı´ interaktivnı´ch relacı´, kromeˇ jine´ho VoIP. Sa´m o sobeˇ nezajisˇt’uje QoS, ale doka´zˇe spolupracovat s protokoly, ktere´ jsou k tomu urcˇeny. Jeho u´koly: • lokalizuje prˇ´ıjemce vola´nı´, • oveˇrˇ´ı vlastnosti pouzˇite´ho zarˇ´ızenı´, • zajistı´ prˇenos dat a zabezpecˇenı´ u jiny´ch protokolu˚. SIP je distribuovany´, co nejvı´c posouva´ inteligenci prˇenosu ke koncovy´m zarˇ´ızenı´m. Dalsˇ´ı vy´znamnou vlastnostı´ SIP je pruzˇnost. Doka´zˇe spolupracovat s mnoha protokoly a kromeˇ VoIP je pouzˇitelny´ naprˇ´ıklad i pro Instant Messaging a doka´zˇe dobrˇe spolupracovat s mobilnı´mi technologiemi. Lze pouzˇ´ıvat jak cˇ´ıselne´ adresy (telefonnı´ cˇ´ısla), tak i URI (Universal Resource Identifier) – webovou adresaci.
P
5.6
VOIP
112
Na transportnı´ vrstveˇ je vyuzˇ´ıva´n prˇedevsˇ´ım protokol UDP, cozˇ znamena´ vysˇsˇ´ı rychlost prˇenosu (mensˇ´ı zpozˇdeˇnı´). ˇ ´ızenı´ spojenı´ R
ˇ ´ızenı´ R A/V
Audio/video aplikace G.7xx
SIP
SDP
H.26x
RTCP RTP/SRTP TCP, UDP IP
Obra´zek 5.9: Protocol stack protokolu SIP H.323 je sada bina´rnı´ch protokolu˚ pro konverzi signalizace paketove´ho protokolu na signalizaci telefonnı´ sı´teˇ. Je starsˇ´ı nezˇ SIP (rok 1996) a vycha´zı´ ze signalizace obvykle´ v telekomunikacˇnı´ch sı´tı´ch. Jde o komplexneˇjsˇ´ı prˇ´ıstup, H.323 rˇesˇ´ı kromeˇ navazova´nı´ a udrzˇova´nı´ spojenı´ take´ QoS a dalsˇ´ı charakteristiky prˇenosu. Prˇi adresova´nı´ pouzˇ´ıva´ telefonnı´ cˇ´ısla.
P
H.323 ma´ veˇtsˇ´ı zpozˇdeˇnı´ prˇi navazova´nı´ spojenı´ a navı´c jeho spolupra´ce s jiny´mi protokoly je problematicka´. Jedna´ se o protokol do znacˇne´ mı´ry centralizovany´. Na transportnı´ vrstveˇ je vyuzˇ´ıva´n prˇedevsˇ´ım protokol TCP, ktery´ ma´ veˇtsˇ´ı rezˇii prˇenosu, to znamena´ veˇtsˇ´ı zpozˇd’ova´nı´ prˇenosu. ˇ ´ızenı´ spojenı´ R
H.255
H.245
Data
T.120, V.150, T.38
ˇ ´ızenı´ R audia/videa
RTCP
RAS, RSVP
Audio/video aplikace G.7xx
H.26x
RTP/SRTP
TCP, UDP IP
Obra´zek 5.10: Protocol stack protokolu H.323 Podpu ˚rne´ protokoly transportnı´ vrstvy: • RTP (Real-time Transport Protocol) doplnˇuje cˇinnost protokolu UDP v oblasti rychle´ paketizace datove´ho toku v rea´lne´m cˇase, synchronizuje prˇenos a umozˇnˇuje zjistit ztraceny´ paket nebo nespra´vne´ porˇadı´ paketu˚. • SRTP (Secure RTP) je bezpecˇneˇjsˇ´ı varianta protokolu RTP.
5.6
VOIP
113
• RTCP (Real-time Transport Control Protocol) zprostrˇedkova´va´ zpeˇtnou vazbu pro protokol RTP, umozˇnˇuje vyuzˇ´ıvat jeho vy´sˇe popsane´ vlastnosti. Vyuzˇitı´m RTCP lze regulovat datovy´ tok, naprˇ´ıklad dynamicky meˇnit rychlost prˇenosu podle pozˇadavku˚ prˇijı´majı´cı´ho uzlu. • SDP (Session Description Protocol) se pouzˇ´ıva´ u protokolu SIP pro vyjedna´nı´ parametru˚ multimedia´lnı´ komunikace. • RSVP (Resource Reservation Protocol) slouzˇ´ı pro rezervaci zdroju˚ spoje, je to prostrˇedek rˇ´ızenı´ QoS. • G.711, G.729, g.723.1, atd. – audio kodeky, nad nimi beˇzˇ´ı audio aplikace. • H.261, H.263, atd. – video kodeky, nad nimi beˇzˇ´ı video aplikace. • T.120 – konferencˇnı´ datove´ prˇenosy. • RAS (Registration, Admission, Status) – podpu˚rny´ protokol pro vyjedna´nı´ a udrzˇenı´ spojenı´ prˇi pouzˇitı´ H.323. Je soucˇa´stı´ protokolu H.255.0 slouzˇ´ıcı´ho k administraci multimedia´lnı´ komunikace. Z dalsˇ´ıch protokolu˚ se vyuzˇ´ıva´ naprˇ´ıklad STUN nebo TURN pro podporu NAT, SCCP u zarˇ´ızenı´ Cisco, IAX v syste´mu Asterisk, a dalsˇ´ı.
5.6.3
Videotelefonie a videokonference
Videotelefonie je vza´jemny´ hovor dvou cˇi vı´ce u´cˇastnı´ku˚ se soucˇasny´m sledova´nı´m synchronizovane´ho videostreamu (obvykle se snı´ma´ obraz videokamery). Dnes obvykle nejde ani tak o samostatna´ zarˇ´ızenı´ (videotelefony), setka´va´me se hlavneˇ se softwarovou implementacı´ (naprˇ´ıklad vy´sˇe zmı´neˇny´ Skype nebo FaceTime od Applu, obojı´ na principu VoIP). Funkce videotelefonie je take´ obvykle implementova´na v softwaru pro pobocˇkove´ u´strˇedny (naprˇ. ve vy´sˇe zmı´neˇne´m Asterisku). Videotelefonie stojı´ prˇedevsˇ´ım na protokolu H.264. Tento protokol standardizovany´ ITU-T je vlastneˇ notoricky zna´my´m videokodekem pro kompresi videa, mnohy´m bude hodneˇ rˇ´ıkat zkratka MPEG-4. Pouzˇ´ıva´ se vsˇude tam, kde je potrˇeba prˇena´sˇet komprimovane´ digita´lnı´ video. Zatı´mco videotelefonie vyzˇaduje vytvorˇenı´ spoje typu point-to-point, videokonference je jizˇ na´rocˇneˇjsˇ´ı zpu˚sob komunikace. Jde vlastneˇ o spoje typu multipoint-to-multipoint, signa´l je sˇ´ırˇen formou multicastu. Videotelefonii mu˚zˇeme povazˇovat za specia´lnı´ jednodusˇsˇ´ı prˇ´ıpad videokonferencı´. Z aplikacı´ pro videokonference mu˚zˇeme vybrat naprˇ´ıklad: MBone je distribuovany´ syste´m slozˇeny´ z volneˇ dostupny´ch na´stroju˚. Vyzˇaduje vhodneˇ multimedia´lneˇ vybaveny´ pocˇ´ıtacˇ prˇipojeny´ do sı´teˇ, funguje nad protokolem IP. Podporuje sˇiroke´ spektrum operacˇnı´ch syste´mu˚ od Windows po ru˚zne´ unixove´ syste´my. Umozˇnˇuje organizovat videokonference, prˇihla´sit se do existujı´cı´ videokonference, prˇena´sˇet zvuk a obraz, sdı´let text i multime´dia (whiteboard – sdı´lena´ bı´la´ tabule s obra´zkem). VRVS (Virtual Room Videoconferencing System) je komplexnı´ syste´m poskytovany´ zdarma ve formeˇ sluzˇby. Je trˇeba mı´t instalova´nu podporu bud’ MBone nebo H.323. K provozova´nı´ VRVS potrˇebujeme pocˇ´ıtacˇ se syste´mem Solaris nebo Linux (omezenı´ neplatı´ pro klientske´ stanice, tam je du˚lezˇita´ verze Java Virtual Machine). VRVS je velmi dobrˇe zdokumentova´n. V poslednı´ dobeˇ ma´ VRVS proble´m s dostupnostı´.
P P J
5.6
VOIP
114
NetMeeting (v noveˇjsˇ´ıch verzı´ch Windows Meeting Space) je jednoduchy´ videokonferencˇnı´ syste´m pro Windows zalozˇeny´ na protokolu H.323. Pu˚vodneˇ byl navrzˇen pro point-to-point spoje, ale dnes jizˇ funguje i na vı´cebodoby´ch spojı´ch, trˇebazˇe neˇkdy s proble´my. Jeho vy´hodou je dostupnost ve vsˇech dnes dostupny´ch verzı´ch Windows, nevy´hodou proble´my s kompatibilitou s neˇktery´mi jiny´mi videokonferencˇnı´mi rˇesˇenı´mi. Ekiga (GnomeMeeting) je svobodny´ software pro VoIP a videokonference vyvı´jeny´ v ra´mci projektu Gnome. Komunikuje i s jiny´mi klienty podporujı´cı´mi protokol SIP nebo H.323 (vcˇetneˇ MS NetMeeting). Klient je dostupny´ pro Linux i Windows. Dalsˇ´ı 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
Bezdra´tove´ a mobilnı´ sı´teˇ V te´to kapitole se budeme veˇnovat bezdra´tovy´m zpu˚sobu˚m prˇenosu – nejdrˇ´ıv technologiı´m postaveny´m prˇedevsˇ´ım na IEEE 802.11 a na´sledneˇ rozlehly´m mobilnı´m sı´tı´m. Poslednı´ sekce v te´to kapitole je veˇnova´na satelitnı´ komunikaci.
6.1
Bezdra´tove´ technologie
Bezdra´tove´ technologie jsou technologie vedenı´ signa´lu „vzduchem“, bez podpory metalicke´ho nebo opticke´ho kabelu. Rozlisˇujeme tyto bezdra´tove´ technologie: • ra´diova´ – ra´diove´ vlny o urcˇite´ frekvenci (Wi-Fi, WiMAX) • sonicka´ – ultrazvuk, verba´lnı´ komunikace • opticka´ – laser, IR (infracˇervene´ za´rˇenı´), ostatnı´ (ma´va´nı´ vlajkou, blika´nı´, posunkova´ rˇecˇ apod.) Pod pojmem WLAN (Wireless LAN) budeme rozumeˇt loka´lnı´ bezdra´tovou sı´t’. Veˇtsˇinou se takto oznacˇuje Wi-Fi sı´t’. Bezdra´tove´ sı´teˇ deˇlı´me na • fixnı´ – sice bezdra´tove´, ale prˇi pohybu prˇipojene´ho zarˇ´ızenı´ se bud’ silneˇ zhorsˇuje signa´l nebo se dokonce odpojı´,
P P P
• mobilnı´ – prˇipojene´ zarˇ´ızenı´ se mu˚zˇe volneˇ pohybovat, i vysˇsˇ´ı rychlostı´. Mobilnı´ sı´teˇ majı´ slozˇiteˇjsˇ´ı implementaci prˇedevsˇ´ım na u´rovni sı´t’ove´ vrstvy. Mezi ru˚zny´mi typy bezdra´tovy´ch sı´tı´ samozrˇejmeˇ existujı´ i dalsˇ´ı rozdı´ly – mohou by´t u´zkopa´smove´ (narrowband) nebo sˇirokopa´smove´ (broadband), majı´ odlisˇny´ dosah, rychlost, na´chylnost na rusˇenı´, zajisˇteˇnı´ bezpecˇnosti. Uvazˇuje se take´ o uplatneˇnı´ technologie UWB (UltraWide Band), tedy rozlozˇenı´ signa´lu do velmi sˇiroke´ho spektra. Du˚sledkem je vysoka´ odolnost proti rusˇenı´ a velmi nesnadne´ odposloucha´nı´ komunikace. Obecneˇ platı´, zˇe sı´teˇ s velmi maly´m dosahem (naprˇ´ıklad BlueTooth) nevyzˇadujı´ tak vysokou u´rovenˇ zabezpecˇenı´. To se ale mu˚zˇe zmeˇnit, protozˇe naprˇ´ıklad BlueTooth v nejnoveˇjsˇ´ı specifikaci 115
P
6.2
WI-FI
116
zvysˇuje nejen rychlost, ale i dosah, a to formou nava´za´nı´ na technologii Wi-Fi (vyuzˇ´ıva´ prˇ´ıtomnosti Wi-Fi cˇipu v zarˇ´ızenı´). Jednou z nejnoveˇjsˇ´ıch technologiı´ vyuzˇ´ıvajı´cı´ch ra´diove´ vlny na vysoky´ch frekvencı´ch je NFC (Near Field Communication). Jedna´ se o technologii urcˇenou prˇedevsˇ´ım pro mala´ mobilnı´ zarˇ´ızenı´ pro u´cˇely bezdotykovy´ch prˇenosu˚ informacı´, plateb, pouzˇ´ıva´nı´ cˇisteˇ elektronicky´ch vstupenek apod., u´cˇinna´ vzda´lenost je maxima´lneˇ 20 cm. Mala´ vzda´lenost je jednı´m ze zabezpecˇovacı´ch faktoru˚ te´to technologie (cˇ´ım veˇtsˇ´ı vzda´lenost, tı´m pravdeˇpodobneˇjsˇ´ı je zneuzˇitı´).
6.2 6.2.1
P
Wi-Fi Za´kladnı´ princip
Wi-Fi pouzˇ´ıva´ ra´diovy´ signa´l v bezlicencˇnı´m pa´smu 2,4 GHz nebo 5 GHz. Komunikacˇnı´m me´diem nejsou kabely, ale vzduch. Wi-Fi sı´teˇ rˇadı´me mezi sı´teˇ s mensˇ´ım dosahem (loka´lnı´). Pa´smo 2,4 GHz je v dalsˇ´ıch standardech (mikrovlnne´ trouby, BlueTooth, mobilnı´ telefony apod.), proto mohou nastat proble´my, rusˇenı´. Pouzˇ´ıva´ se koliznı´ metoda CSMA/CA (Carrier Sense Medium Access, Collision Avoidance, definova´na v protokolu na MAC):
P P
• CS – Carrier Sense (nasloucha´ na me´diu) • MA – Multiple Access (na me´dium prˇistupuje vı´ce stanic) • CA – with Collision Avoidance (kdyzˇ chce stanice vysı´lat a nasloucha´nı´m zjistı´, zˇe nikdo jiny´ nevysı´la´, informuje ostatnı´ uzly o u´myslu vysı´lat) Vysı´la´ se v polovicˇnı´m (half) duplexu, z principu nenı´ mozˇne´ plneˇ duplexnı´ vysı´la´nı´ (me´diem je vzduch, tedy bezdra´tova´ sı´t’ova´ karta doka´zˇe vzˇdy jen prˇijı´mat nebo vysı´lat, nikoliv obojı´). Wi-Fi je standardizova´na jako IEEE 802.11. Tı´mto standardem se take´ zaby´va´ pru˚myslove´ sdruzˇenı´ Wi-Fi Alliance. Jsou dveˇ mozˇnosti jak rˇesˇit Wi-Fi sı´t’: • ad-hoc rˇesˇenı´ : kazˇda´ komunikujı´cı´ stanice je vybavena Wi-Fi sı´t’ovou kartou, komunikujı´ spolu prˇ´ımo bez mezilehly´ch prvku˚ (pro sı´teˇ o pa´r pocˇ´ıtacˇ´ıch), • infrastruktura: existuje prˇ´ıstupovy´ bod (AC – Access Point), prˇes ktery´ jde vesˇkera´ komunikace (point-to-multipoint), zˇa´dne´ dveˇ stanice spolu nekomunikujı´ prˇ´ımo. Kazˇdy´ prˇ´ıstupovy´ bod pokry´va´ signa´lem za´kladnı´ oblast sluzˇeb (BSA – Basic Service Area), take´ se nazy´va´ bunˇka. V bunˇce se nacha´zejı´ prˇipojene´ koncove´ body, stanice. Prˇekry´va´nı´ buneˇk mu˚zˇe by´t
P P
• cˇa´stecˇne´ – umozˇnˇuje plynuly´ prˇechod z jedne´ do druhe´ (roaming) • (te´meˇrˇ) u´plne´ – mozˇnost sdı´let za´teˇzˇ mezi spolupracujı´cı´mi AP (collocated – va´zane´) Vı´ce pouzˇity´ch prˇ´ıstupovy´ch bodu˚ znamena´ vı´ce buneˇk, mohou by´t propojeny pomocı´ distribucˇnı´ho syste´mu (DS – Distribution system), oblast pokryta´ signa´lem je rozsˇ´ırˇena´ oblast sluzˇeb (ESA – Extended Service Area). Propojenı´ funguje obvykle na linkove´ vrstveˇ (i kdyzˇ to nenı´ ve standardu
P
6.2
WI-FI
117
Obra´zek 6.1: Sche´ma bezdra´tove´ sı´teˇ prˇedepsa´no), kromeˇ jine´ho proto, zˇe poskytuje mozˇnost sˇ´ırˇenı´ broadcastu. Sche´ma najdeme na obra´zku 6.1. Distribucˇnı´ syste´m (zde WDS, Wireless Distribution System) tedy funguje jako pa´terˇnı´ sı´t’propojujı´cı´ prˇ´ıstupove´ body. Obecneˇ lze pouzˇ´ıt distribucˇnı´ syste´m nejen pro propojenı´ (bezdra´tovy´ch) prˇ´ıstupovy´ch bodu˚, ale take´ trˇeba pro propojenı´ dvou metalicky´ch loka´lnı´ch sı´tı´. Nejjednodusˇsˇ´ı distribucˇnı´ syste´m lze vytvorˇit tak, zˇe prˇ´ıstupovy´ bod jedne´ BSA pracuje jako beˇzˇna´ stanice v BSA druhe´ho prˇ´ıstupove´ho bodu (opakovacˇ), ale ne kazˇdy´ prˇ´ıstupovy´ bod podporuje rezˇim opakovacˇe. Za´kladnı´ sluzˇby poskytovane´ Wi-Fi prˇ´ıstupovy´m bodem jsou • autentizace – AP zjisˇt’uje informace o stanici a rozhoduje, zda jı´ dovolı´ prˇ´ıstup do sı´teˇ • asociace (prˇidruzˇenı´) – vznika´ vazba mezi AP a stanicı´, stanice je asociova´na k bunˇce AP • de-asociace – zrusˇenı´ te´to vazby Pro prˇihla´sˇenı´ k sı´ti je nutne´ zna´t jejı´ identifikacˇnı´ ko´d – SSID (Service Set IDentifier), rˇeteˇzec dlouhy´ 0–32 oktetu˚. Standardneˇ prˇ´ıstupovy´ bod vysı´la´ sve´ SSID v ra´mcı´ch beacon v intervalech neˇkolika sekund, a to v otevrˇene´ formeˇ, v takove´m prˇ´ıpadeˇ nenı´ proble´m SSID zjistit. Pokud prˇ´ıstupovy´ bod nevysı´la´ SSID v beacon ra´mcı´ch, lze je odposlechnout i v jiny´ch typech ra´mcu˚ (naprˇ´ıklad prˇi prˇidruzˇova´nı´ jine´ stanice), nebo stacˇ´ı poslat falesˇny´ pozˇadavek na odpojenı´ neˇktere´ (rˇa´dneˇ prˇipojene´) stanice, ktera´ se pak pokusı´ znovu prˇipojit (nenı´ trˇeba dlouho cˇekat na komunikaci obsahujı´cı´ SSID). SSID lze take´ pouzˇ´ıt k jednoduche´ implementaci virtua´lnı´ sı´teˇ (VLAN), kdy jsou SSID pouzˇ´ıvana´ jednotlivy´mi uzˇivateli mapova´na na VLAN, na trˇetı´ vrstveˇ se pak pouzˇ´ıvajı´ prˇ´ıstupova´ opra´vneˇnı´ (ACL seznamy). BSSID (Basic Service Set ID) je identifika´tor fungujı´cı´ v ra´mci jedne´ BSA (tj. u dane´ho prˇ´ıstupove´ho bodu), je dlouhy´ 6 oktetu˚, obvykle se jedna´ o MAC prˇ´ıstupove´ho bodu (u ad-hoc sı´teˇ to je na´hodny´ rˇeteˇzec).
P
P
6.2
WI-FI
118
ESSID (Extended SSID) je tote´zˇ co SSID, zkratka se pouzˇ´ıva´ v ESA (prˇ´ıpadneˇ mu˚zˇe by´t stejny´ jako BSSID). Podle IEEE 802.11 je implementova´na fyzicka´ vrstva a MAC podvrstva. Nad MAC se pouzˇ´ıvajı´ beˇzˇne´ LLC ra´mce (IEEE 802.2).
6.2.2
P
Rezˇimy
Rezˇimy, ve ktery´ch mu˚zˇe wi-fi zarˇ´ızenı´ pracovat: Gateway (bra´na) – zarˇ´ızenı´ je prˇipojeno k Internetu, funguje jako NAT server, zvencˇ´ı je viditelna´ pouze jedina´ IP adresa (tj. oddeˇluje vnitrˇnı´ LAN a vneˇjsˇ´ı sı´t’ WAN). IP adresa tohoto zarˇ´ızenı´ slouzˇ´ı jako adresa bra´ny pro celou LAN, ktera´ je k bra´neˇ prˇipojena, pokud na´m ovsˇem situaci nekomplikujı´ soukrome´ IP adresy. Routery obvykle plnı´ i funkci bra´ny. Router (smeˇrovacˇ, zde prˇesneˇji Wi-fi router) – zarˇ´ızenı´, ktere´ vidı´ na sı´t’ovou vrstvu, pouzˇ´ıva´ IP adresy a doka´zˇe podle IP adres smeˇrovat. Obvykle na neˇm beˇzˇ´ı NAT, firewall a DHCP server, prˇ´ıpadneˇ mu˚zˇe take´ plnit funkci bra´ny do Internetu (cozˇ taky hodneˇ souvisı´ s funkcı´ NAT). Na Wi-fi smeˇrovacˇi beˇzˇ´ı i AP (viz da´le), takzˇe celkoveˇ mu˚zˇeme hovorˇit o zarˇ´ızenı´, ktere´ v sobeˇ kombinuje funkci AP a smeˇrovacˇe. AP (Access Point, prˇ´ıstupovy´ bod) – toto zarˇ´ızenı´ je prˇipojeno k routeru (ktery´ prˇ´ıpadneˇ funguje jako bra´na), a pokud opravdu beˇzˇ´ı v AP mo´du, tak na neˇm nenı´ aktivnı´ NAT, firewall a cˇasto ani DHCP server (ale nenı´ to vyloucˇeno, hlavneˇ na neˇm nebeˇzˇ´ı NAT), funguje vpodstateˇ jako bridge, pracuje pouze na druhe´ vrstveˇ ISO/OSI (nezna´ IP adresy, tedy NAT nemu˚zˇe logicky fungovat).
P P P
AP mu˚zˇeme bra´t jako ethernetovy´ prˇepı´nacˇ, ktery´ ma´ jeden (!!!) port urcˇen pro Wi-fi, nerozlisˇuje ru˚zne´ Wi-fi komunikace. Obvykle ma´ svou vlastnı´ IP adresu, ale ta slouzˇ´ı pouze k prˇ´ıstupu do webove´ho rozhranı´ k administraci (tedy mu˚zˇe „videˇt“ na sı´t’ovou vrstvu, ale jen pro u´cˇely administrace, naprˇ´ıklad nastavenı´ sˇifrova´nı´ Wi-fi). Obeˇ zarˇ´ızenı´ (AP a router) musı´ mı´t nastaveno stejne´ ESSID, protozˇe jsou ve stejne´ Wi-fi sı´ti. AP klient – prˇipojuje se k jine´mu AP, dalsˇ´ı zarˇ´ızenı´ jsou k AP klientovi prˇipojena obvykle kabelem, slouzˇ´ı k distribuci signa´lu jine´ho AP (dva AP standardneˇ nelze propojit, pouze AP plus AP klient). U neˇktery´ch Wi-fi zarˇ´ızenı´ se mu˚zˇeme setkat s oznacˇenı´m rezˇimu „Station“, taky se jedna´ o rezˇim AP klienta. Stanice (pocˇ´ıtacˇe, notebooky, tiska´rny s rozhranı´m Wi-fi, atd.), resp. jejich sı´t’ove´ karty, beˇzˇ´ı v rezˇimu AP klient (Station). Repeater (opakovacˇ) – zarˇ´ızenı´ slouzˇ´ı k prˇeposı´la´nı´ signa´lu, jedna´ se o pasivnı´ rezˇim (na fyzicke´ vrstveˇ, nezna´ ani MAC adresy) umozˇnˇujı´cı´ stanicı´m prˇipojit se (zprostrˇedkovaneˇ) k neˇktere´mu AP nebo bra´neˇ, ktere´ by byly jinak prˇ´ılisˇ vzda´leny, signa´l by byl slaby´. Hlavnı´m u´cˇelem je tedy prˇ´ıchozı´ signa´l zesı´lit, prˇ´ıpadneˇ redukovat sˇum, a poslat da´l. Repeater pracuje na fyzicke´ vrstveˇ, pouze pasivneˇ prˇeposı´la´ signa´l (s prˇ´ıpadny´m zvy´sˇenı´m jeho kvality) bez jake´hokoliv smeˇrova´nı´, prˇepı´na´nı´, apod.
P P
6.2
WI-FI
119
WDS (Wireless Distribution System, distribucˇnı´ syste´m) – pouzˇ´ıva´ se tehdy, kdyzˇ ma´me vı´ce routeru˚, potrˇebujeme distribuovat propojenı´ „ven“ bezdra´toveˇ (tj. pouze na jednom bude vyuzˇ´ıva´n port do WAN sı´teˇ) a navı´c se chceme mezi nimi plynule prˇehlasˇovat. Tyto routery tvorˇ´ı jediny´ distribucˇnı´ syste´m a z pohledu koncove´ho zarˇ´ızenı´ to vypada´, jako by byl prˇipojen porˇa´d k te´muzˇ routeru. WDS pracuje na prvnı´ nebo druhe´ vrstveˇ ISO/OSI, podle toho, jestli potrˇebujeme navı´c funkcionalitu mostu nebo zda stacˇ´ı funkcionalita opakovacˇe.
P
Proble´m je, zˇe zajisˇt’ova´nı´ funkcionality rezˇimu WDS je vy´pocˇetneˇ hodneˇ na´rocˇne´ a navı´c je propustnost nizˇsˇ´ı z du˚vodu pra´ce routeru˚ na stejne´m kmitocˇtu (rusˇenı´, apod.), tedy sı´t’ je ve srovna´nı´ s propojenı´m routeru˚ dra´ty vy´razneˇ pomalejsˇ´ı (azˇ o polovinu). Rezˇim WDS nenı´ standardizova´n, tedy nema´me zarucˇeno, zˇe to bude fungovat prˇi propojenı´ dvou routeru˚ nastaveny´ch do rezˇimu WDS. Pokud opravdu chceme WDS pouzˇ´ıt, pak bychom meˇli nakoupit tato zarˇ´ızenı´ do te´hozˇ vy´robce (nebo alesponˇ sice od jiny´ch vy´robcu˚, ale s wi-fi chipsetem od stejne´ho vy´robce, trˇeba Broadcom). Dalsˇ´ı nevy´hodou je, zˇe WDS obvykle nedoka´zˇe pracovat s dynamicky´mi klı´cˇi, a tedy pro zabezpecˇenı´ komunikace lze obvykle jen WEP, cozˇ je velmi sˇpatne´. Proto WDS je potrˇeba komunikaci zabezpecˇit i jiny´m zpu˚sobem. WISP – zarˇ´ızenı´ se prˇipojı´ v roli AP klienta k AP (tedy bezdra´tova´ komunikace bude zastupovat WAN port) a za´rovenˇ smeˇruje na LAN a WAN porty (tj. k LAN a WAN portu˚m se chova´ jako switch na 2. vrstveˇ ISO/OSI).
P
WISP mo´d vyuzˇijeme naprˇ´ıklad tehdy, kdyzˇ ma´me dosazˇitelne´ho poskytovatele Wi-fi prˇipojenı´ (tj. prˇes bezdra´t se budeme dosta´vat na Internet) a prˇes kabel budeme prˇipojovat dalsˇ´ı zarˇ´ızenı´ (typicky stanice).
6.2.3
Fyzicka´ vrstva v ISO/OSI, frekvencˇnı´ spektrum
Pro fyzickou vrstu existuje v rodineˇ IEEE 802.11 neˇkolik za´kladnı´ch standardu˚: • • • • •
IEEE 802.11b – frekvence 2,4 GHz, rychlost azˇ 11 Mb/s IEEE 802.11a – frekvence 5 GHz, rychlost azˇ 54 Mb/s IEEE 802.11g – frekvence 2,4 GHz, rychlost azˇ 54 Mb/s IEEE 802.11n – frekvence 2,4 nebo 5 GHz, rychlost azˇ 600 Mb/s (spı´sˇe znacˇneˇ nizˇsˇ´ı), OFDM+MIMO IEEE 802.11ac – frekvence 5 GHz, s jednou ante´nou (jeden stream) rychlost azˇ 433 Mb/s, 8 ante´n azˇ 3,47 Gb/s, OFDM+(Mu-)MIMO
Vsˇechny tyto standardy prˇedepisujı´ vyuzˇitı´ frekvencı´ v nelicencovane´m pa´smu (tzn. nepotrˇebujeme licenci pro nasˇe zarˇ´ızenı´). Uvedene´ rychlosti je trˇeba bra´t s rezervou, rea´lneˇ to mu˚zˇe by´t me´neˇ nezˇ polovina. V soucˇasne´ dobeˇ je nejpouzˇ´ıvaneˇjsˇ´ı IEEE 802.11g, ale nabı´dka IEEE 802.11n je sta´le sˇirsˇ´ı. Varianta IEEE 802.11n sice podporuje obeˇ frekvencˇnı´ pa´sma, ale v soucˇasne´ dobeˇ najdeme veˇtsˇinou (nikoliv vy´hradneˇ) zarˇ´ızenı´ podporujı´cı´ pouze pa´smo 2,4 GHz. Neˇktera´ zarˇ´ızenı´ doka´zˇou pracovat na obou frekvencı´ch soucˇasneˇ (dvoupa´smovy´ router), cozˇ znamena´ zvy´sˇenı´ propustnosti (za prˇedpokladu, zˇe v dosahu jsou zarˇ´ızenı´ z jednoho i druhe´ho spektra). Existujı´ zarˇ´ızenı´ IEEE 802.11n Lite, ktera´ implementujı´ jen omezeneˇ pu˚vodnı´ „n“ standard (typicky pouze jedina´ ante´na), du˚sledkem je nizˇsˇ´ı rychlost oproti plne´ implementaci.
P
6.2
WI-FI
120
Standardu˚ (technicky vzato annexu˚ – prˇ´ıloh standardu IEEE 802.11) existuje samozrˇejmeˇ vy´razneˇ vı´ce, vlastneˇ je uzˇ zabrana´ cela´ abeceda a jsou pouzˇity i neˇktere´ dvoupı´smenne´ zkratky (trˇeba ac). Naprˇ´ıklad pozdeˇji se setka´me s IEEE 802.11i, ktery´ se ty´ka´ zabezpecˇenı´ bezdra´tove´ komunikace (WPA2), 802.11p zajisˇt’ujı´cı´ funkcˇnost bezdra´tove´ho prˇipojenı´ mezi pozemnı´ stanicı´ a rychle se pohybujı´cı´m prvkem (trˇeba automobilem nebo vlakem), 802.11e pro QoS, atd. MIX Mode. Standardy 802.11b, g, n jsou zpeˇtneˇ kompatibilnı´ – ale co to znamena´ ve skutecˇnosti? Prˇedpokla´dejme, zˇe ma´me Wi-fi access point (AP) beˇzˇ´ıcı´ podle standardu 802.11g. Pokud jsou v te´to sı´ti pouze zarˇ´ızenı´ zvla´dajı´cı´ standard 802.11g, vsˇechna budou komunikovat podle tohoto standardu s teoretickou rychlostı´ azˇ 54 Mb/s. Ovsˇem pokud se do sı´teˇ dostane byt’jedine´ zarˇ´ızenı´ zvla´dajı´cı´ pouze standard 802.11b (tedy pomalejsˇ´ı), vsˇechna zarˇ´ızenı´ v sı´ti budou reagovat jednı´m z teˇchto zpu˚sobu˚:
P
1. ukoncˇ´ı spojenı´ 2. zu˚stanou prˇipojena, ale budou komunikovat podle 802.11b (tj. max. teoretickou rychlostı´ 11 Mb/s). Druha´ mozˇnost bude pouzˇita u teˇch zarˇ´ızenı´, ktera´ majı´ zapnut tzv. MIX Mode (cozˇ znamena´ mozˇnost pracovat podle vsˇech teˇchto kompatibilnı´ch standardu˚). Podobna´ situace nastane i v prˇ´ıpadeˇ, kdy se do sı´teˇ fungujı´cı´ podle IEEE 802.11n dostane zarˇ´ızenı´ 802.11g (rychlost klesne na max. 54 Mb/s) nebo 802.11b (rychlost klesne na max. 11 Mb/s). Z toho vyply´va´, zˇe pokud na´m v bezdra´tove´ sı´ti zda´nliveˇ bezdu˚vodneˇ klesne propustnost, du˚vodem mu˚zˇe by´t i to, zˇe se do sı´teˇ dostalo „starsˇ´ı“ zarˇ´ızenı´. IEEE 802.11n navysˇuje prˇenosovou rychlost oproti 802.11g neˇkolika zpu˚soby. Prˇedneˇ tato zarˇ´ızenı´ mohou pracovat v obou pa´smech, dalsˇ´ıho zvy´sˇenı´ rychlosti se dociluje zmeˇnou modulace – pouzˇ´ıva´ se modulace typu OFDM, konkre´tneˇ azˇ 64-QAM. Pouzˇ´ıvajı´ se kana´ly o sˇ´ırˇce obvykle 40 MHz. Propustnost navysˇuje i mozˇnost vyuzˇitı´ vı´ce ante´n, prˇicˇemzˇ signa´l je kompletova´n vyuzˇitı´m technologie MIMO (viz da´le). Zarˇ´ızenı´, u neˇhozˇ vidı´me oznacˇenı´ IEEE 802.11n Lite, pouzˇ´ıva´ pouze jednu ante´nu. IEEE 802.11ac je momenta´lneˇ nejnoveˇjsˇ´ı standard (take´ 5G Wi-fi nebo Wi-fi pa´te´ generace). Pracuje pouze ve frekvencˇnı´m pa´smu kolem 5 GHz. Pouzˇ´ıva´ efektivneˇjsˇ´ı modulaci nezˇ 802.11n (azˇ 256-QAM) – konkre´tneˇ za´kladnı´ modulace je OFDM, subnosne´ pak QAM. V jednotlivy´ch generacı´ch se tento parametr meˇnil na´sledovneˇ: • 802.11g: 16-QAM (jeden symbol = 4 bity, 24 = 16 mozˇnostı´ pro hodnotu symbolu), • 802.11n: 64-QAM (jeden symbol = 8 bitu˚), • 802.11ac: 256-QAM (16 bitu˚) Du˚sledkem bylo postupne´ zvysˇova´nı´ efektivity prˇenosu (vı´c prˇeneseny´ch dat za jednotku cˇasu). 802.11ac podporuje azˇ 8 ante´n s MIMO, resp. MU-MIMO (MultiUser-MIMO, mu˚zˇe paralelneˇ komunikovat s vı´ce zarˇ´ızenı´mi). Typicka´ sˇ´ırˇka kana´lu je bud’ 80 MHz nebo 160 MHz. Skutecˇna´ propustnost za´lezˇ´ı na vı´ce faktorech (sˇ´ırˇka kana´lu, pocˇet ante´n, apod.), typicka´ rychlost je kolem 1 Gb/s.
L P P
6.2
WI-FI
121
5GHz pa´smo ma´ sˇpatnou poveˇst co se ty´cˇe prostupnosti steˇn (tak to bylo v IEEE 802.11a), ale kupodivu u IEEE 802.11ac se s tı´mto proble´mem nesetka´va´me zdaleka v tak velke´ mı´rˇe – je to dı´ky algoritmu Beamforming, ktery´ prˇi vyuzˇitı´ vı´ce ante´n „zpozˇd’uje“ signa´l neˇktery´ch ante´n tak, aby po procha´zenı´ prˇeka´zˇkami dospeˇl ze vsˇech ante´n za prˇeka´zˇku ve zhruba stejnou dobu, a tedy se da´ zkompletovat (narozdı´l od prˇ´ıpadu, kdy by signa´ly ru˚zny´ch ante´n prosˇly prˇeka´zˇkou – s ru˚zny´mi u´hly a odrazy – v odlisˇnou dobu, a tedy by se dokonce vza´jemneˇ rusˇily). Existuje take´ standard IEEE 802.11ad (take´ se nazy´va´ WiGig – od Wireless Gigabit Alliance), ktery´ ma´ podobne´ vlastnosti vcˇetneˇ propustnosti jako IEEE 802.11ac, s urcˇity´mi rozdı´ly. Prˇedneˇ vysı´la´ v pa´smu 60 GHz (prˇesneˇji v rozsahu 57–66 GHz) a sˇ´ırˇka pa´sma pro jeden kana´l je 2.16 GHz, cozˇ je vy´razneˇ vı´ce nezˇ u 802.11ac (tam jen max. 160 MHz). V cele´m pa´smu existujı´ 4 kana´ly, ale ne vsˇude je mozˇne´ vsˇechny 4 vyuzˇ´ıt (naprˇ´ıklad v USA je mozˇne´ pouzˇ´ıvat jen prvnı´ trˇi, v Cˇ´ıneˇ jen druhy´ a trˇetı´, v Austra´lii dokonce jen druhy´ a cˇa´st trˇetı´ho, v Evropeˇ vsˇechny cˇtyrˇi).
6.2.4
Struktura PHY, modulace
Fyzicka´ vrstva se deˇlı´ na dveˇ podvrstvy, hornı´ a spodnı´. • PLCP (Physical Layer Convergence Protocol) – horni podvrstva, jejı´ u´koly jsou detekce nosne´ a indikace rychlosti, tvorˇ´ı rozhranı´ k PMD.
• PMD (Physical Media Dependent) – spodnı´ podvrstva, prova´dı´ modulaci (ru˚zne´ formy – DSSS, OFDM, atd.), ko´dova´nı´/deko´dova´nı´. Dodatek IEEE 802.11b pouzˇ´ıva´ modulaci DSSS (Direct Sequence Spread Spectrum, rozprostrˇene´ spektrum), IEEE 802.11a/g modulaci OFDM, v IEEE 802.11n najdeme jejı´ modifikaci MIMO-OFDM (mj. obsahuje podporu komunikace s vı´ce ante´nami na jednom zarˇ´ızenı´). Podvrstva PLCP je odlisˇna´ pro ru˚zne´ podvrstvy PMD (DSSS, OFDM, FHSS apod. na spodnı´ podvrstveˇ), tj. rozlisˇujeme PLCP ra´mec pro DSSS, PLCP ra´mec pro OFDM, atd. Podvrstva MAC na vrstveˇ L2 je pro 802.11a/b/g stejna´, lisˇ´ı se pro 802.11n. Frekvence. O Wi-fi sice rˇ´ıka´me, zˇe pracuje na frekvenci 2,4 GHz nebo 5 GHz, ale ve skutecˇnosti je rozsah frekvencı´ (frekvencˇnı´ pa´smo) trochu sˇirsˇ´ı. Rozsah pro IEEE 802.11b (2,4 GHz) je na obra´zku 6.2 a pro IEEE 802.11a na obra´zku 6.3.
Obra´zek 6.2: Frekvencˇnı´ spektrum a kana´ly pro IEEE 802.11b1 1
Zdroj: http://en.wikipedia.org/wiki/802.11b
P
6.2
WI-FI
122
V ra´mci pouzˇ´ıvane´ho spektra (naprˇ´ıklad na frekvenci 2,4 GHz) je k dispozici vı´ce kana´lu˚ (na zmı´neˇne´ frekvenci 13–14, podle momenta´lnı´ situace v prˇideˇleny´ch frekvencı´ch) s tı´m, zˇe AP komunikujı´cı´ v urcˇite´m kana´lu ve skutecˇnosti zabı´ra´ 5 kana´lu˚ (jeden plus dva na kazˇde´ straneˇ). Na obra´zku 6.2 jsou zvy´razneˇny trˇi kana´ly o sˇ´ırˇce 22 MHz, ktere´ by se teoreticky nemeˇly prˇekry´vat. U frekvence 2,4 MHz: Sˇ´ırˇka kana´lu je 22–24 MHz (podle kvality zpracova´nı´ signa´lu), ale strˇedy frekvencı´ v teˇchto kana´lech jsou od sebe vzda´leny jen 5 MHz. Mozˇny´ch kana´lu˚ pro IEEE 802.11g je celkem 14, ale v mnoha zemı´ch jsou neˇktere´ z nich zaka´za´ny. U na´s lze pouzˇ´ıvat kana´ly na frekvencı´ch vypsany´ch v tabulce 6.1. Kana´l 1. 2. 3.
Frekvence o| 2412 MHz 2417 MHz 2422 MHz
Kana´l 4. 5. 6.
Frekvence o|
Kana´l
2427 MHz 2432 MHz 2437 MHz
7. 8. 9.
Frekvence o|
Kana´l 10. 11. 12. 13.
2442 MHz 2447 MHz 2452 MHz
$
Frekvence o| 2457 MHz 2462 MHz 2467 MHz 2472 MHz
Tabulka 6.1: Kana´ly u frekvence 2,4 MHz vyuzˇitelne´ v CˇR Veˇtsˇina Wi-Fi routeru˚ podporuje automaticky´ vy´beˇr nejvhodneˇjsˇ´ıch kana´lu˚, cozˇ mu˚zˇe proble´m s rusˇenı´m okolnı´ch prˇ´ıstupovy´ch bodu˚ trochu zmensˇit. V konfiguraci vsˇak mu˚zˇeme zvolit neˇktery´ kana´l rucˇneˇ. Seznam kana´lu˚ a frekvencı´ najdeme naprˇ´ı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: Sˇ´ırˇka kana´lu je stejna´ jako u frekvence 2,4 MHz, ale strˇednı´ hodnoty frekvencı´ povoleny´ch kana´lu˚ jsou od sebe vı´ce vzda´leny, tedy je mnohem snazsˇ´ı najı´t skupinu kana´lu˚ s neprˇekry´vajı´cı´mi se frekvencemi (viz tabulku 6.2). Navı´c je na nasˇem trhu pomeˇrneˇ ma´lo zarˇ´ızenı´ pracujı´cı´ch na te´to frekvenci (tj. podporujı´cı´ch IEEE 802.11a), protozˇe tento standard je pomeˇrneˇ mlady´ (mladsˇ´ı nezˇ „b“) a pracuje na jine´ frekvenci nezˇ nejoblı´beneˇjsˇ´ı dalsˇ´ı standardy. O podporˇe IEEE 802.11a mu˚zˇeme uvazˇovat prˇedevsˇ´ım tehdy, kdyzˇ se v nasˇem okolı´ (trˇeba u sousedu˚) vyskytuje vı´ce routeru˚ na frekvenci 2,4 MHz a oblast je zarusˇena´. Nesmı´me vsˇak zapomenout, zˇe do sı´teˇ lze prˇipojit pouze zarˇ´ızenı´ podporujı´cı´ IEEE 802.11a. Kana´l 36 40 44
Frekvence o| 5180 MHz 5200 MHz 5220 MHz
Kana´l 48 52 56
Frekvence o| 5240 MHz 5260 MHz 5280 MHz
Kana´l 60 64 100–140 (deˇl. 4)
Frekvence o|
5300 MHz 5320 MHz 5500–5700 MHz
Tabulka 6.2: Kana´ly u frekvence 5 MHz vyuzˇitelne´ v CˇR Neˇktera´ zarˇ´ızenı´ podle IEEE 802.11n doka´zˇou pracovat na obou za´kladnı´ch frekvencı´ch za´rovenˇ – 2,4 GHz i 5 GHz. Koupeˇ takove´ho zarˇ´ızenı´ ma´ samozrˇejmeˇ smysl jen tehdy, pokud „bude mı´t
$
6.2
WI-FI
123
s ky´m komunikovat“ na frekvenci 5 GHz, cozˇ nenı´ azˇ tak beˇzˇne´. Pokud vsˇak tu mozˇnost ma´me, meˇli bychom se zajı´mat o to, zda na obou teˇchto frekvencı´ch doka´zˇe komunikovat za´rovenˇ (tj. nejen se mezi nimi prˇepı´nat).
Obra´zek 6.3: Frekvencˇnı´ spektrum a kana´ly pro IEEE 802.11a (rozdeˇleno na dveˇ cˇa´sti)2
Obra´zek 6.4: Frekvencˇnı´ spektrum a kana´ly pro IEEE 802.11ac (pro ru˚zne´ sˇ´ırˇky kana´lu˚)3 Interference. Bezdra´tova´ zarˇ´ızenı´ pracujı´cı´ na prˇiblizˇneˇ stejne´ frekvenci se navza´jem rusˇ´ı. Neznamena´ to, zˇe by tato zarˇ´ızenı´ vu˚bec nefungovala, ale du˚sledkem rusˇenı´ jsou cˇaste´ chyby v prˇenosech, tj. hodneˇ (nedorucˇeny´ch cˇi posˇkozeny´ch) paketu˚ je trˇeba poslat znovu ⇒ snizˇuje se rychlost prˇenosu (v nejhorsˇ´ım prˇ´ıpadeˇ te´meˇrˇ na nulu). Teoreticky by bylo rˇesˇenı´m navolit na blı´zky´ch AP kana´ly tak, aby se dotycˇne´ peˇtice co nejme´neˇ prˇekry´valy (tj. 2 azˇ 3 komunikujı´cı´ AP, ktere´ se „vidı´“ a prˇitom se navza´jem nerusˇ´ı), ale to je opravdu jen teorie. Ve skutecˇnosti (dı´ky fyzika´lnı´m za´konu˚m) beˇzˇna´ komunikace na kana´lu „zamorˇuje“ nejen dva okolnı´ kana´ly na kazˇde´ straneˇ, ale bohuzˇel i vzda´leneˇjsˇ´ı, i kdyzˇ v mensˇ´ı mı´rˇ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
obra´zku 6.2 vidı´me trˇi zvy´razneˇne´ obloucˇky, ktere´ se neprˇekry´vajı´ (1., 6. a 11. kana´l). V rea´lu je spodnı´ cˇa´st obloucˇku˚ znacˇneˇ rozta´hnuta, sˇum zasahuje mnohem da´le („do ztracena“), jak vidı´me na obra´zku 6.5 (vy´stup z aplikace Wi-Spy Chanalyzer 4 pro jeden zdroj signa´lu podle IEEE 802.11g, v hornı´ cˇa´sti si vsˇimneˇte amplitudy v ru˚zny´ch kana´lech, kana´ly jsou oznacˇeny frekvencı´ v MHz).
Obra´zek 6.5: Wi-Spy Chanalyzer4 Tj. „vhodne´“ rozdeˇlenı´ kana´lu˚ prakticky neexistuje, dva AP se budou navza´jem rusˇit, i kdyzˇ budou pracovat na „dostatecˇneˇ vzda´leny´ch“ kana´lech. Pokud tedy nema´me jinou mozˇnost, lze dva AP umı´stit tak, aby se jejich dosahy prolı´naly, kana´ly zvolı´me co nejda´l od sebe (nicme´neˇ automaticky se to tak obvykle take´ deˇje), ovsˇem musı´me pocˇ´ıtat s jisty´m snı´zˇenı´m rychlosti. Je zajı´mave´, zˇe za urcˇity´ch okolnostı´ je paradoxneˇ lepsˇ´ı pro vı´ce AP zvolit tenty´zˇ nebo hodneˇ blı´zky´ kana´l, pro dalsˇ´ı informace viz diplomovou pra´ci JEDLICˇKA, T. Diagnostika bezdra´tovy´ch sı´tı´. Diplomova´ pra´ce ´ stavu informatiky FPF SU. Opava, 2012. na U Vy´sˇe popsane´ rusˇenı´ je take´ jednı´m z du˚vodu˚, procˇ prˇi pouzˇitı´ WDS musı´me pocˇ´ıtat s nizˇsˇ´ı propustnostı´ sı´teˇ. Wi-fi sı´t’ mu˚zˇe by´t rusˇena take´ z jiny´ch zdroju˚ (cˇ´ımkoliv na blı´zke´ frekvenci), naprˇ´ıklad mikrovlnnou troubou, nasˇteˇstı´ tento zdroj rusˇenı´ neby´va´ pouzˇ´ıva´n dlouhodobeˇ. Dalsˇ´ım zdrojem interferencı´ mohou by´t bluetooth zarˇ´ızenı´, ale u nich je sı´la signa´lu velmi nı´zka´, tedy na funkcˇnost Wi-fi sı´teˇ nemajı´ vy´znamny´ vliv. Diagnosticke´ na´stroje pro fyzickou vrstvu umozˇnˇujı´ zkoumat frekvencˇnı´ spektrum. Veˇtsˇinou jde o komercˇnı´ na´stroje a nebo sice volneˇ sˇirˇitelne´, ale vyzˇadujı´cı´ kompatibilnı´ hardware (tj. za´lezˇ´ı 4
Zdroj: http://www.wi-spy.com.au/
$
6.2
WI-FI
125
na sˇteˇstı´, jestli takovy´ ma´me). Z nejzna´meˇjsˇ´ıch: • NetStumbler5 – volneˇ sˇirˇitelny´ analyza´tor spektra, • Wi-Spy6 – komercˇnı´ na´stroj (analyza´tor spektra vcˇetneˇ rozdeˇlenı´ na jednotlive´ kana´ly, set se skla´da´ z upravene´ Wi-fi sı´t’ove´ karty do USB konektoru a specia´lnı´ho softwaru), • Chanalyzer7 je sice komercˇnı´ na´stroj (jako soucˇa´st Wi-Spy), ale existuje volneˇ sˇirˇitelna´ varianta; je to vy´konny´ spektra´lnı´ analyza´tor (viz obra´zek 6.5), • AirMagnet WiFi Analyzer8 je komercˇnı´ na´stroj funkcˇnostı´ podobny´ na´stroji Wi-Spy, takte´zˇ spektra´lnı´ analyza´tor (take´ vyzˇaduje specia´lnı´ hardware), • inSSIDer9 – volneˇ sˇirˇitelny´ na´stroj pracujı´cı´ pouze s Wi-fi sı´teˇmi, na jednotlivy´ch kana´lech doka´zˇe zobrazit existujı´cı´ sı´teˇ vcˇetneˇ jejich SSID, • Xirrus Wi-fi Inspector10 – volneˇ sˇirˇitelny´ na´stroj na zjisˇt’ova´nı´ dostupny´ch AP a jejich vlastnostı´, • Iperf 11 (takte´zˇ volneˇ sˇirˇitelny´, ovla´da´ se v textove´m shellu) slouzˇ´ı k ladeˇnı´ parametru˚ sı´teˇ a je to uzˇitecˇny´ take´ jako pomocny´ na´stroj prˇi diagnostice sı´teˇ, doka´zˇe odchyta´vat pakety (sniffer) a generovat „prˇirozeny´ provoz“ na sı´ti (uzˇitecˇne´ prˇi testova´nı´), • Jperf 12 je volneˇ sˇirˇitelna´ graficka´ na´stavba programu Iperf (tj. veˇtsˇina lidı´ si s Iperfem instaluje Jperf). Existujı´ na´stroje urcˇene´ vysloveneˇ pro mapova´nı´ signa´lu, naprˇ´ıklad Ekahau Heatmapper, Ekahau Site Survey, Meraki Wi-fi Mapper, Aerohive Free Wi-fi Planner, Cisco Clean Air, VisiWave Site Survey, RF3D WifiPlanner. Dalsˇ´ı 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 U Pokud ma´te k dispozici Wi-fi router, zjisteˇte, na jake´ frekvenci pracuje (prˇ´ıpadneˇ jestli podporuje obeˇ za´kladnı´ pa´sma) a ktery´ kana´l pouzˇ´ıva´.
6.2.5
Ante´ny a MIMO
Signa´l se sˇ´ırˇ´ı kolmo na ante´nu. To bychom meˇli vzı´t v u´vahu, kdyzˇ ante´ny smeˇrujeme. Pokud chceme signa´lem pokry´t jen jedno patro, ante´na by meˇla smeˇrˇovat nahoru nebo dolu˚, jestlizˇe vsˇ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
signa´l sˇ´ırˇit i do okolnı´ch pater nebo trˇeba na zahradu, ante´nu smeˇrujeme sˇikmo. Existujı´ i smeˇrove´ ante´ny, je take´ mozˇne´ vytvorˇit z vsˇesmeˇrove´ ante´ny smeˇrovou. Jedna´ se o vysokofrekvencˇnı´ za´rˇicˇ, jehozˇ vliv na zdravı´ je cˇasto diskutova´n (Wi-Fi router taky nepatrˇ´ı do lozˇnice nebo deˇtske´ho pokoje). Proto bychom meˇli zkontrolovat sı´lu signa´lu a vhodneˇ ji prˇizpu˚sobit (ostatneˇ, prˇ´ılisˇ silny´ signa´l mu˚zˇe zpu˚sobit rusˇenı´ v okolnı´ch sı´tı´ch). Take´ je doporucˇeno (le´karˇi) alesponˇ na noc Wi-Fi vypı´nat. Lepsˇ´ı ADSL routery nabı´zejı´ mozˇnost vypnutı´ Wi-Fi prˇi zachova´nı´ ADSL prˇipojenı´, toho bychom meˇli vyuzˇ´ıt a Wi-Fi zapı´nat jen tehdy, kdyzˇ je potrˇebujeme. MIMO (Multiple Input Multiple Output) znamena´ vyuzˇitı´ vı´ce ante´n a hlavneˇ algoritmus pro kombinova´nı´ prˇijate´ho signa´lu z teˇchto ante´n. Tento algoritmus je velmi du˚lezˇity´, protozˇe jinak by se ante´ny te´hozˇ zarˇ´ızenı´ navza´jem rusˇily a tlumily a signa´l by se naopak zhorsˇil. Vı´ce ante´n mu˚zˇe by´t na obou komunikujı´cı´ch zarˇ´ızenı´ch – stanici i prˇ´ıstupove´m bodu.
P
Obecneˇ platı´, zˇe cˇ´ım vı´c ante´n, tı´m lepsˇ´ı signa´l (a take´ rychlejsˇ´ı komunikace), ale prakticky se pocˇ´ıta´ s omezenı´m na 4 ante´ny pro vnitrˇnı´ oblast budov a 16 ante´n pro pouzˇitı´ venku. MIMO pracuje na fyzicke´ vrstveˇ. S vı´ce ante´nami se setka´va´me u 802.11n, kde slouzˇ´ı take´ ke zvy´sˇenı´ prˇenosove´ kapacity v du˚sledku paralelnı´ho vysı´la´nı´ (max. 4 × 4 ante´ny). MU-MIMO (Multi-User MIMO) je vylepsˇenı´ pouzˇ´ıvane´ ve WiMAX sı´tı´ch a v bezdra´tovy´ch zarˇ´ızenı´ch podle standardu IEEE 802.11ac. Algoritmus optimalizuje vyuzˇitı´ pa´sma s ohledem na fakt, zˇe v sı´ti komunikuje vı´ce uzˇivatelu˚, je nava´za´no vı´ce spojenı´. Pu˚vodnı´ MIMO lze cha´pat jako SU-MIMO (Single-User MIMO), kde jeden AP doka´zˇe v jednom okamzˇiku komunikovat jen s jednı´m zarˇ´ızenı´m. Frekvence a licence. Frekvencˇnı´ rozsahy kolem 2,4 GHz a 5 GHz patrˇ´ı k tzv. bezlicencˇnı´m pa´smu˚m. ´ To znamena´, zˇe pokud chceme provozovat zarˇ´ızenı´ pracujı´cı´ v tomto pa´smu, nemusı´me zˇa´dat CˇTU (Cˇesky´ telekomunikacˇnı´ u´rˇad) o individua´lnı´ opra´vneˇnı´, udeˇlenı´ licence (u pa´sem, ktera´ podle´hajı´ povinnosti zˇa´dosti o individua´lnı´ opra´vneˇnı´, je povolenı´ podmı´neˇno splneˇnı´m urcˇity´ch pozˇadavku˚ na provoz zarˇ´ızenı´).
P P
Prˇesto je trˇeba urcˇite´ limity dodrzˇovat i v bezlicencˇnı´ch pa´smech, jejich pouzˇitı´ je podmı´neˇno dodrzˇenı´m podmı´nek Vsˇeobecne´ho opra´vneˇnı´ k vyuzˇ´ıva´nı´ ra´diovy´ch kmitocˇtu˚ (cely´ na´zev je delsˇ´ı, viz zdroj da´le). Omezenı´ jsou prˇedevsˇ´ım ve smyslu dodrzˇenı´ maxima´lnı´ho vyza´rˇene´ho vy´konu ante´n, cozˇ ma´ zmensˇit pravdeˇpodobnost vza´jemne´ho rusˇenı´ zarˇ´ızenı´ a take´ jsou zde urcˇite´ medicı´nske´ du˚vody (vysokofrekvencˇnı´ za´rˇenı´ je ve velky´ch da´vka´ch nebezpecˇne´ pro lidsky´ organismus). Pokud dojde k vza´jemne´mu rusˇenı´ zarˇ´ızenı´, obvykle platı´ pravidlo „kdo drˇ´ıv prˇijde, mu˚zˇe ´ je. zu˚stat“. V rea´lu bohuzˇel cˇasto platı´ „moudrˇejsˇ´ı ustoupı´“, nicme´neˇ mozˇnost stı´zˇnosti na CˇTU Text Vsˇeobecne´ho opra´vneˇnı´ k vyuzˇ´ıva´nı´ ra´diovy´ch kmitocˇtu˚ a k provozova´nı´ zarˇ´ızenı´ pro sˇirokopa´smovy´ prˇenos dat na principu rozprostrˇene´ho spektra nebo OFDM v pa´smech 2,4 GHz a 5 GHz najdeme naprˇ´ıklad na http://www.ctu.cz/1/download/Opatreni%20obecne%20povahy/VO R 12 08 2005 34.pdf. ´ koly U 1. U dostupne´ho Wi-fi routeru (nebo neˇjake´ho na webu, kdyzˇ nema´te zˇa´dny´ v dosahu) zjisteˇte: • ktere´ rezˇimy podporuje, • jake´ ma´ SSID,
6.2
WI-FI
127
• zda pro zabezpecˇenı´ pouzˇ´ıva´ mechanismus WEP, WPA nebo WPA2, • ktere´ dalsˇ´ı bezpecˇnostnı´ mechanismy podporuje a ktere´ jsou vyuzˇ´ıva´ny. 2. Jak ma´ by´t natocˇena ante´na, pokud chceme pokry´t signa´lem pouze jedno patro, a jak ma´ by´t natocˇena, pokud chceme pokry´t i okolnı´ patra budovy? (Prˇedpokla´dejme, zˇe nemusı´me rˇesˇit materia´l zdı´, jejich propustnost.)
6.2.6
Podvrstva MAC
Podvrstva MAC je pro IEEE 802.11a/b/g stejna´, odlisˇna´ je MAC pro IEEE 802.11n (za u´cˇelem ´ kolem MAC v teˇchto standardech je zajisˇteˇnı´ prˇidruzˇenı´ stanice k prˇ´ıdalsˇ´ıho zvy´sˇenı´ rychlosti). U stupove´mu bodu, autentizace, prˇenos dat, provoz v rezˇimech DCF, PCF a RTS/CTS (viz da´le). Pouzˇ´ıva´ se cˇasovy´ multiplex, polovicˇnı´ duplex (sloty jsou vyuzˇ´ıva´ny vzˇdy jen v jednom smeˇru). Vysı´lat lze v neˇkolika rezˇimech: 1. DCF (Distributed Coordination Function) je rezˇim bez podpory priorit, je vy´chozı´ v IEEE 802.11. Poskytuje pouze sluzˇbu best effort, tedy bez garance sˇ´ırˇky pa´sma, zpozˇdeˇnı´, bez QoS (lze doplnit podle standardu IEEE 802.11e). Mezi vysı´lane´ ra´mce jsou vkla´da´ny mezery, jejich de´lka odpovı´da´ dobeˇ povinne´ho cˇeka´nı´ s nasloucha´nı´m prˇed zacˇa´tkem vysı´la´nı´. Prˇijı´majı´cı´ stanice po prˇijetı´ ra´mce cˇeka´ kra´tkou dobu a pak posˇle potvrzenı´ prˇijetı´.
P
Pokud stanice beˇhem nasloucha´nı´ zjistı´ vysı´la´nı´, cˇeka´ po dobu na´hodneˇ zvolenou z intervalu 0..velikost „okna sva´ru“. Pokud po uplynutı´ te´to doby opeˇt detekuje vysı´la´nı´, velikost „okna sva´ru“ se zdvojna´sobı´ (atd. i pro dalsˇ´ı intervaly). 2. PCF (Point Coordination Function) je rezˇim s podporou priorit. Prˇ´ıstupovy´ bod v pravidelny´ch intervalech vysı´la´ sluzˇebnı´ ra´mce (beacon ra´mce). Kazˇdy´ interval mezi dveˇma beacony je rozdeˇlen na dveˇ cˇa´sti – doba boje o me´dium (contention) a doba bez boje o me´dium (contention-free). Pokud ma´ stanice k odesla´nı´ prioritnı´ data (QoS), mu˚zˇe zı´skat povolenı´ k vysı´la´nı´ v dobeˇ bez boje o me´dium. Tento rezˇim neby´va´ moc cˇasto implementova´n, nenı´ pouzˇitelny´ v ad-hoc sı´tı´ch. 3. RTS/CTS (Request to Send/Clear to Send) rˇesˇ´ı proble´m „skryty´ch stanic“. Stanice prˇipojene´ k jednomu prˇ´ıstupove´mu bodu se navza´jem nemusejı´ „videˇt“, du˚sledkem jsou pokusy o vysı´la´nı´ v dobeˇ, kdy vysı´la´ jina´ stanice (nastane kolize). V tomto rezˇimu musı´ kazˇda´ stanice prˇed zacˇa´tkem vysı´la´nı´ odeslat zˇa´dost o rezervaci me´dia (RTS) a cˇekat na potvrzenı´ pra´va po stanovenou dobu vysı´lat (CTS). MAC ra´mec.
Existujı´ trˇi typy MAC ra´mcu˚ pro IEEE 802.11:
1. Datovy´ ra´mec (Data Frame) 2. Rˇ´ıcicı´ ra´mec (Control Frame), pouzˇ´ıva´ se pro tyto u´cˇely: • RTS/CTS ra´mce (viz drˇ´ıve, rezˇimy cˇinnosti MAC) • ACK – potvrzenı´ prˇijaty´ch ra´mcu˚
P
6.2
WI-FI
128
3. Ra´mec pro spra´vu (Management Frame), pouzˇ´ıva´ se pro tyto u´cˇely: • • • • • •
beacon ra´mec (AP se ohlasˇuje) probe, probe response (zjisˇt’ova´nı´ prˇ´ıtomnosti uzlu˚ sı´teˇ a jejich mozˇnostı´) association request, association response (zˇa´dost o asociaci od stanice, odpoveˇd’) re-association request, response (prˇechod k jine´mu AP ve stejne´ ESS) diassociation (ukoncˇenı´ spojenı´ k AP) authentication (zˇa´dost o autentizaci uzlu), de-authentication
Ra´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 ra´mec Struktura MAC ra´mce je naznacˇena na obra´zku 6.3. Frame Control obsahuje naprˇ´ıklad verzi protokolu, prˇ´ıznak opakovane´ho prˇenosu, zda je/nenı´ pouzˇito WEP, prˇ´ıznak, zda budou na´sledovat jesˇteˇ dalsˇ´ı ra´mce, prˇ´ıznaky To DS a From DS, adresy atd. To, co obsahujı´ jednotliva´ pole, je ovlivneˇno momenta´lnı´m zdrojem a cı´lem dotycˇne´ho ra´mce, rozlisˇujeme tyto prˇ´ıpady: 1. sı´t’ ad-hoc, jednotliva´ pole ra´mce majı´ tuto hodnotu: • oba prˇ´ıznaky = 0 (odesı´latel i prˇ´ıjemce jsou uzel) • addr1 = MAC prˇ´ıjemce (Destination Address) • addr2 = MAC odesı´latele (Source Address) ... ...
To DS 0
From DS 0
...
Addr 1
Addr 2
Addr 3
...
Addr 4
...
...
MAC prˇ´ıjemce
MAC odesı´latele
–
...
–
...
2. infrastruktura, prˇenos od AP ke stanici, jednotliva´ pole ra´mce majı´ tuto hodnotu: • • • • ... ...
To DS=0 (prˇ´ıjemce je uzel), From DS=1 (odesı´latel je AP/DS) addr1 = MAC prˇ´ıjemce (stanice) addr2 = BSSID (MAC AP), fyzicky´ odesı´latel adr3 = MAC odesı´latele (stanice), logicky´ odesı´latel To DS 0
From DS 1
...
Addr 1
Addr 2
Addr 3
...
Addr 4
...
...
MAC prˇ´ıjemce
BSSID AP
MAC odesı´latele
...
–
...
P
6.2
WI-FI
129
3. infrastruktura, prˇenos k AP, jednotliva´ pole ra´mce majı´ tuto hodnotu: • • • • ... ...
To DS=1 (prˇ´ıjemce je AP/DS), From DS=0 addr1 = BSSID AP (fyzicky´ prˇ´ıjemce) addr2 = MAC odesı´latele addr3 = logicky´ prˇ´ıjemce (MAC) To DS 1
From DS 0
...
Addr 1
Addr 2
Addr 3
...
Addr 4
...
...
BSSID AP
MAC odesı´latele
MAC prˇ´ıjemce
...
–
...
4. infrastruktura, prˇes DS, jednotliva´ pole ra´mce majı´ tuto hodnotu: • • • • • ... ...
To DS=From DS= 1 addr1 = MAC (BSSID) prˇijı´majı´cı´ho AP addr2 = MAC (BSSID) odesı´lajı´cı´ho AP addr3 = DA (MAC logicke´ho prˇ´ıjemce) addr4 = SA (MAC logicke´ho odesı´latele) To DS 1
From DS 1
...
Addr 1
Addr 2
Addr 3
...
Addr 4
...
...
BSSID prˇ´ıjimajı´cı´ho AP
BSSID odesı´lajı´cı´ho AP
MAC prˇ´ıjemce
...
MAC odesı´latele
...
Diagnosticke´ na´stroje pro MAC podvrstvu jsou prˇedevsˇ´ım sniffery, tj. programy, ktere´ odchyta´vajı´ pakety, umozˇnˇujı´ je analyzovat cˇi vizualizovat a prˇ´ıpadneˇ nabı´zejı´ dalsˇ´ı doprovodne´ funkce. Vpodstateˇ se tyto na´stroje pouzˇ´ıvajı´ souhrnneˇ pro dra´tove´ i bezdra´tove´ sı´teˇ, protozˇe u nich vy´znamneˇjsˇ´ı odlisˇnosti na MAC nenajdeme (azˇ na drobnosti, viz forma´t MAC ra´mce vy´sˇe). Sı´t’ove´ rozhranı´, ktere´ je takto analyzova´no, by meˇlo beˇzˇet v promiskuitnı´m mo´du, to znamena´, zˇe by meˇlo prˇijı´mat vsˇechny ra´mce vcˇetneˇ teˇch, ve ktery´ch je cı´lova´ adresa jina´ (urcˇeny´ch jine´mu uzlu v sı´ti). V prˇ´ıpadeˇ na´stroju˚ pro bezdra´tove´ sı´teˇ se take´ setka´va´me s na´stroji pro „prolamova´nı´ “ zapomenuty´ch hesel/WEP, apod. Nejzna´meˇjsˇ´ım a nejpopula´rneˇjsˇ´ım volneˇ sˇirˇitelny´m snifferem je Wireshark13 (pu˚vodneˇ Ethereal). Takte´zˇ oblı´beny´ volneˇ sˇirˇitelny´ je Kismet14 – detektor sı´tı´, sniffer a potencia´lneˇ IDS (budeme se ucˇit pozdeˇji). Dalsˇ´ı jsou komercˇnı´ Eye P.A. a Cascade Pilot.
6.2.7
´ vod do sˇifrova´nı´ U
Prˇi sˇifrova´nı´ potrˇebujeme • sˇifrovacı´ algoritmus = staticka´ soucˇa´st procesu sˇifrova´nı´ • „promeˇnne´“ slozˇky postupu – obvykle je to sˇifrovacı´ klı´cˇ, heslo apod. Na obou teˇchto slozˇka´ch za´visı´ vy´sledne´ zabezpecˇenı´ sˇifrovany´ch dat – potrˇebujeme dostatecˇneˇ kvalitnı´ sˇifrovacı´ algoritmus a dostatecˇneˇ silny´ klı´cˇ/heslo. 13 14
http://www.wireshark.org/ http://www.kismetwireless.net/
$
6.2
WI-FI
130
Existujı´ dva za´kladnı´ typy sˇifrova´nı´: 1. symetricke´ – 1 klı´cˇ (tenty´zˇ) pro sˇifrova´nı´ i desˇifrova´nı´ 2. asymetricke´ – pouzˇ´ıvajı´ se dva odlisˇne´ klı´cˇe (soukromy´ a verˇejny´) 3. hybridnı´ kombinuje oba prˇedchozı´ prˇ´ıstupy Nejdrˇ´ıv se podı´va´me na symetricke´ sˇifrova´nı´, kdy ma´me pouze jeden klı´cˇ pro sˇifrova´nı´ i desˇifrova´nı´. Postup prˇi symetricke´m sˇifrova´nı´ je na´sledujı´cı´:
P
• odesı´latel zasˇifruje data pomocı´ klı´cˇe, odesˇle • prˇ´ıjemce desˇifruje data pomocı´ te´hozˇ klı´cˇe Vy´hodou je rychlost sˇifrova´nı´ a desˇifrova´nı´, nevy´hodou je proble´m s bezpecˇnou distribucı´ klı´cˇe. Proto symetricke´ sˇifrova´nı´ pouzˇ´ıva´me tehdy, kdyzˇ lze pouzˇ´ıt dostatecˇneˇ zabezpecˇeny´ kana´l pro prˇenos klı´cˇe druhe´ straneˇ (osobnı´m prˇeda´nı´m nebo pouzˇitı´m jine´ sˇifrovacı´ metody). Typicky´mi za´stupci symetricke´ho sˇifrova´nı´ jsou DES, AES, RC4. Asymetricke´ sˇifrova´nı´ vyuzˇ´ıva´ dva klı´cˇe a je zalozˇeno na jednocestne´ funkci (tj. kdyzˇ na zasˇifrovana´ data pouzˇijeme inverznı´ funkci, nedostaneme tata´zˇ data, ktera´ jsme meˇli prˇed pu˚vodnı´m sˇifrova´nı´m). Pouzˇ´ıva´me tyto dva klı´cˇe:
P
• soukromy´ klı´cˇ vlastnı´ prˇ´ıjemce sˇifrovane´ zpra´vy • verˇejny´ klı´cˇ byl distribuova´n odesı´lateli zpra´vy (vygeneroval ho prˇ´ıjemce coby pa´rovy´ klı´cˇ ke sve´mu soukrome´mu klı´cˇi) Odesı´latel zpra´vu zasˇifruje verˇejny´m klı´cˇem, ktery´ obdrzˇel od prˇ´ıjemce zpra´vy, odesˇle, prˇ´ıjemce zpra´vu desˇifruje svy´m soukromy´m klı´cˇem. Vy´hodou je, zˇe verˇejny´ klı´cˇ lze poslat i nezabezpecˇeny´m kana´lem (jı´m zasˇifrovana´ data nelze desˇifrovat bez soukrome´ho klı´cˇe), nevy´hodou je vy´razneˇ vysˇsˇ´ı vy´pocˇetnı´ (cˇasova´) na´rocˇnost sˇifrova´nı´. Typicky´mi za´stupci jsou RSA, PGP, mechanismus se vyuzˇ´ıva´ pro certifika´ty, digita´lnı´ podpisy. Hybridnı´ sˇifrova´nı´ je kombinacı´ obou prˇedchozı´ch postupu˚. Je dvoustupnˇove´: • prvnı´ stupenˇ = symetricke´ sˇifrova´nı´ (odesı´latel zasˇifruje data pomocı´ rychle´ho symetricke´ho klı´cˇe) • druhy´ stupenˇ = asymetricke´ sˇifrova´nı´ (symetricky´ klı´cˇ zasˇifruje asymetricky verˇejny´m klı´cˇem prˇ´ıjemce) Samotna´ data jsou sˇifrovana´ symetricky (velky´ objem ⇒ vy´hoda rychlosti symetrie), naproti tomu symetricky´ klı´cˇ (ted’ „v roli dat“) je sˇifrovany´ asymetricky (maly´ objem ⇒ rychlost nenı´ tak du˚lezˇita´).
Hybridnı´ sˇifrova´nı´ si tedy bere z obou mozˇnostı´ to lepsˇ´ı (ze symetricke´ho rychlost, z asymetricke´ho vysˇsˇ´ı bezpecˇnost). Typicky se pouzˇ´ıva´ pro delsˇ´ı komunikaci, kde se posı´la´ vı´ce dat (postupneˇ, s nava´za´nı´m spojenı´) – relace. Symetricky´ klı´cˇ se sˇifruje asymetricky´m postupem pouze jednou pro celou relaci, pak beˇhem komunikace v ra´mci relace se pouzˇ´ıva´ pouze „rychle´“ symetricke´ sˇifrova´nı´.
P
6.2
WI-FI
6.2.8
131
AAA
AAA (autentizace, autorizace, u´cˇtova´nı´ – accounting) probı´ha´ prˇi prˇipojova´nı´ uzlu do sı´teˇ. Autentizace je oveˇrˇova´nı´ a potvrzova´nı´ totozˇnosti komunikujı´cı´ch stran (pokud mozˇno obou). Zdu˚vodu zvy´sˇenı´ bezpecˇnosti je mozˇne´ pouzˇ´ıt autentizaci za asistence trˇetı´ du˚veˇryhodne´ strany (trusted third party).
P
Autentizace mu˚zˇe by´t otevrˇena´ (prakticky nic se nekontroluje) nebo podle autentizacˇnı´ho sdı´lene´ho klı´cˇe. Prvnı´ typ je charakteristicky´ pro verˇejne´ hotspoty. Autorizace znamena´ urcˇenı´ konkre´tnı´ch prˇ´ıstupovy´ch opra´vneˇnı´ prˇihlasˇovane´ho uzˇivatele. Po autentizaci a autorizaci je stanice prˇidruzˇena k prˇ´ıstupove´mu bodu a mu˚zˇe komunikovat. ´ cˇtova´nı´ je zaznamena´va´nı´ vsˇech cˇinnostı´ provedeny´ch uzˇivatelem v syste´mu a prˇ´ıpadne´ na´U sledne´ reakce. Autentizacˇnı´ klı´cˇ se pouzˇ´ıva´ prˇi autentizaci prˇi prˇihlasˇova´nı´ do sı´teˇ, a da´le prˇi sˇifrova´nı´ komunikace. Typy: • WEP – zastaraly´, da´vno prolomen • WPA – pouzˇ´ıva´ WEP klı´cˇe, ale dynamicky je meˇnı´ (protokol TKIP), autentizace pomocı´ RADIUS Serveru (prˇihlasˇova´nı´ jme´nem a heslem) nebo klı´cˇe PSK (Pre-Shared Key) • WPA2 – sˇifrova´nı´ AES WEP (Wired Equivalent Privacy) je mechanismus zabezpecˇenı´, ktery´ poskytuje pouze za´kladnı´ stupenˇ bezpecˇnosti. Jeho jedinou vy´hodou je plna´ kompatibilita se vsˇemi Wi-Fi zarˇ´ızenı´mi, a proto je take´ obvykle nastaven jako vy´chozı´. Pouzˇ´ıva´ stejne´ sˇifrova´nı´ pro autentizaci i prˇenos dat – mozˇnosti: • bez sˇifrova´nı´ (plneˇ otevrˇena´ sı´t’) • symetricka´ sˇifra RC4, 40bitovy´ staticky´ klı´cˇ + 24bitovy´ promeˇnny´ inicializacˇnı´ vektor = 64bitovy´ RC4 klı´cˇ • symetricka´ sˇifra RC4, 104bitovy´ staticky´ klı´cˇ + 24bitovy´ promeˇnny´ inicializacˇnı´ vektor = 128bitovy´ RC4 klı´cˇ IV (inicializacˇnı´) vektor se meˇnı´ pro kazˇdy´ paket ⇒ prˇ´ıjemce musı´ mı´t mozˇnost IV vektor zjistit. Teoreticky mu˚zˇe existovat sdı´leny´ algoritmus pro generova´nı´ IV vektoru, ale prakticky ve WEP je IV vektor soucˇa´stı´ nesˇifrovane´ hlavicˇky WEP paketu!!! (hned prvnı´ prvek uvnitrˇ MAC ra´mce), za´hlavı´ se nesˇifruje. Dalsˇ´ım proble´mem je, zˇe autentizace je jen jednostranna´ (stanice, resp. jejı´ sı´t’ova´ karta, se autentizuje prˇ´ıstupove´mu bodu, ale AP se neautentizuje stanici). Prˇipojenı´ stanice k AP probı´ha´ takto: • • • • •
Stanice odesˇle zˇa´dost o prˇipojenı´, prˇ´ıstupovy´ bod odpovı´ odesla´nı´m na´hodneˇ vygenerovane´ sekvence znaku˚ (bez sˇifrova´nı´), stanice tuto sekvenci zasˇifruje svy´m tajny´m klı´cˇem a zasˇle zpeˇt prˇ´ıstupove´mu bodu, prˇ´ıstupovy´ bod take´ provede sˇifrova´nı´ stejne´ sekvence, pokud se vy´sledky shodujı´, stanice mu˚zˇe by´t prˇidruzˇena k sı´ti.
P
6.2
WI-FI
132
WEP je snadno zneuzˇitelny´ dokonce neˇkolika ru˚zny´mi zpu˚soby, kromeˇ jine´ho take´ dı´ky prˇ´ılisˇ kra´tke´ sekvenci IV vektoru. Da´le prˇi autentizaci je zası´la´na oveˇrˇovacı´ sekvence a hned pote´ jejı´ zasˇifrovana´ podoba, tedy prˇi tak kra´tke´ de´lce tajne´ho klı´cˇe nenı´ proble´m tajny´ klı´cˇ postupneˇ odhalit (pro tento u´cˇel lze dokonce pouzˇ´ıt volneˇ sˇirˇitelne´ na´stroje, WEP crackery, naprˇ´ıklad AirCracku to trva´ neˇkolik minut). Protozˇe je to obvykle vy´chozı´ typ zabezpecˇenı´ v prˇ´ıstupovy´ch bodech, je vhodne´ hned po koupi zmeˇnit typ zabezpecˇenı´ na neˇktery´ jiny´. 802.1x je pokusem o zvy´sˇenı´ bezpecˇnosti WEP. Jedna´ se o mechanismus autentizace uzˇivatelu˚, distribuce klı´cˇu˚ a zajisˇteˇnı´ integrity zpra´v. Principem je zavedenı´ autentizacˇnı´ho serveru, ktery´m je obvykle RADIUS (Remote Authentication Dial-In Usr Service). RADIUS pracuje ve strukturˇe typu klient-server, kde samotny´ RADIUS je server, klienty jsou prˇ´ıstupove´ servery (autentiza´torˇi, naprˇ´ıklad Wi-Fi prˇ´ıstupove´ body), ke ktery´m se prˇihlasˇujı´ uzˇivatele´ (tj. RADIUS sı´t’je tvorˇena RADIUS serverem a prˇ´ıstupovy´mi servery, stanice do nı´ nepatrˇ´ı). K autentizaci klientu˚ u serveru se pouzˇ´ıva´ sdı´lene´ tajne´ heslo, ktere´ se nikdy neprˇena´sˇ´ı po sı´ti. Naopak uzˇivatele´ se u RADIUS klienta (prˇ´ıstupove´ho serveru) autentizujı´ heslem, ktere´ se prˇena´sˇ´ı v zasˇifrovane´ podobeˇ. Komunikace: • uzˇivatel pozˇa´da´ o prˇipojenı´,
P
$
• prˇ´ıstupovy´ server si vyzˇa´da´ prˇihlasˇovacı´ jme´no a heslo, • prˇ´ıstupovy´ server odesˇle RADIUS serveru (prˇes loka´lnı´ nebo rozlehlou sı´t’) zˇa´dost o prˇipojenı´ (RADIUS Access Request), • RADIUS server oveˇrˇ´ı platnost prˇihlasˇovacı´ho jme´na a hesla (dostal je v zasˇifrovane´ podobeˇ), prˇ´ıpadneˇ si vyzˇa´da´ dalsˇ´ı informace, take´ mu˚zˇe zva´zˇit naprˇ. MAC adresu a dalsˇ´ı filtrovacı´ krite´ria, • podle vy´sledku oveˇrˇenı´ odesˇle prˇ´ıstupove´mu serveru souhlas nebo odmı´tnutı´ (RADIUS Access Accept/Deny). Komunikace je naznacˇena na obra´zku 6.6. V komunikaci mezi RADIUS serverem a klienty je mozˇne´ pouzˇ´ıt v ra´mci protokolu RADIUS zabezpecˇenı´ IPSec, v autentizacˇnı´ komunikaci mezi RADIUS klientem a stanicı´ (prˇ´ıpadneˇ take´ mezi RADIUS serverem a klientem) se beˇzˇneˇ pouzˇ´ıva´ neˇktera´ z teˇchto mozˇnostı´: • EAP-TLS (Microsoft) – v kombinaci s protokolem TLS a mechanismem PKI, certifika´ty X.509 (mı´sto jme´na a hesla), dostupny´ na veˇtsˇineˇ verzı´ Windows, MacOS X • LEAP (Cisco) – dynamicke´ klı´cˇe WEP jednora´zove´ pro kazˇdou relaci, relace je cˇasoveˇ omezena´ (neˇkolik minut), oboustranna´ autentizace • EAP-MD5 – ze jme´na a hesla vytvorˇ´ı MD5 hash, pouzˇ´ıva´ pouze staticke´ klı´cˇe WEP, nejme´neˇ bezpecˇna´ mozˇnost • dalsˇ´ı – EAP-TTLS, EAP-PSK, EAP-IKEv2, atd. EAP lze zapouzdrˇovat, naprˇ´ıklad PEAP stanovuje zapouzdrˇenı´ (jake´hokoliv) EAP do zabezpecˇene´ho tunelu. IEEE 802.1x je sice lepsˇ´ı nezˇ samotny´ WEP, ale prˇesto (prˇedevsˇ´ım prˇi pouzˇitı´ hesel, ktera´ nejsou dostatecˇneˇ silna´) je prolomitelny´, na´chylny´ prˇedevsˇ´ım k u´toku˚m typu DoS (Denial of Service)
6.2
WI-FI
133
Wi-fi AP (RADIUS klient)
PC
RADIUS server
EAPOL Start ˇ a´dost o prˇ´ıstup Z EAP Request/Id Autorizuj se EAP Response/ID Aut.informace (U)
RADIUS Access Request/ID Aut. informace (U)
EAP Request/OTP Dalsˇ´ı informace?
RADIUS Acces-Challenge Dalsˇ´ı informace?
EAP Response/OTP Dalsˇ´ı informace (U)
RADIUS Access Request/OTP Dalsˇ´ı informace (U)
EAP Success Spojeno (U)
RADIUS Acces-Accept Spojeno (U)
Vyuzˇ´ıva´nı´ portu, pro ktery´ bylo zarˇ´ızenı´ autorizova´no. EAPOL Logoff Ukoncˇenı´ relace
Obra´zek 6.6: Autentizace podle IEEE 802.1x (RADIUS) a Man-in-the-Middle. Hlavnı´m prˇ´ınosem jsou dynamicke´ klı´cˇe a zavedenı´ trˇ´ıprvkove´ autentizace (autentizacˇnı´ server). Existuje i volneˇ dostupny´ software pro RADIUS server, naprˇ´ıklad open-source projekt FreeRADIUS. Jako rozhranı´ k FreeRADIUSu se cˇasto pouzˇ´ıva´ daloRADIUS.15 Na stanici musı´ beˇzˇet klientska´ aplikace, ale ta je beˇzˇnou soucˇa´stı´ operacˇnı´ch syste´mu˚. WPA (Wi-Fi Protected Access) je docˇasne´ rˇesˇenı´, ktere´ vzniklo prˇed dokoncˇenı´m standardu IEEE 802.11i (WPA2). WPA vznikl „orˇeza´nı´m“ prˇipravovane´ho WPA2 na pouze ty prvky, ktere´ nevyzˇadovaly zmeˇny v hardwaru, zmeˇny v softwaru (vcˇ. firmwaru sı´t’ovy´ch karet) se implementujı´ snadneˇji a rychleji. Je kompatibilnı´ jak s WEP, tak i se svy´m na´stupcem WPA2. Sˇifrova´nı´ probı´ha´ podobneˇ jako u WEP (pouzˇ´ıva´ se RC4), ale IV vektor je 48bitovy´, klı´cˇ 128bitovy´. Podpora sˇifrova´nı´ je zajisˇteˇna protokolem TKIP (Temporal Key Integrity Protocol), ktery´ prova´dı´ dynamickou spra´vu sˇifrovacı´ch klı´cˇu˚ (cely´ klı´cˇ se meˇnı´ pro kazˇdy´ paket) – to je du˚lezˇita´ zmeˇna oproti staticky´m (nemeˇnny´m) klı´cˇu˚m u WEP. Integrita zpra´v je zajisˇteˇna mechanismem MIC (Message-Integrity Check, taky Michael) – to je mechanismus pro kontrolu integrity zpra´v (definovany´ v protokolu TKIP); na konec sˇifrovane´ cˇa´sti ra´mce prˇed kontrolnı´ soucˇet se prˇida´ 64 kontrolnı´ch bitu˚ (MIC) vytvorˇeny´ch z • cı´love´ a zdrojove´ MAC adresy, • dat, • porˇadove´ho cˇ´ısla paketu a na´hodne´ hodnoty (prˇ´ıp. priority) 15
http://freeradius.org/, http://daloradius.com/
$
P
6.2
WI-FI
134
Vpodstateˇ se jedna´ o jaky´si digita´lnı´ podpis paketu. Existujı´ dveˇ varianty WPA: 1. WPA-Enterprise (pro firemnı´ uzˇitı´) – pouzˇ´ıva´ se v kombinaci s IEEE 802.1X – RADIUS 2. WPA-Personal (pro doma´cnosti, SOHO segment; take´ se oznacˇuje WPA-PSK) – autentizace s prova´dı´ jen pomocı´ sdı´lene´ho klı´cˇe PSK, nenı´ trˇeba mı´t specia´lneˇ urcˇeny´ server pro beˇh RADIUSu. WPA-PSK (Pre-Shared Key) jednodusˇe funguje tak, zˇe uzˇivatel zada´va´ heslo 8-63 ASCII znaku˚ (nebo 64 hex. cˇ´ıslic). WPA je bezpochyby lepsˇ´ım rˇesˇenı´m nezˇ WEP, ale protozˇe se vlastneˇ jedna´ jen o vylepsˇenı´ vlastnostı´ WEP+802.1X s prˇida´nı´m kontroly integrity zpra´v, nenı´ to idea´lnı´ rˇesˇenı´. Nicme´neˇ pro doma´cı´ AP mu˚zˇe by´t dostacˇujı´cı´, pokud zvolı´me dostatecˇneˇ silne´ heslo. WPA2 (IEEE 802.11i) pouzˇ´ıva´ mı´sto TKIP protokol CCMP s sˇifrova´nı´m AES (volitelneˇ je mozˇno pouzˇ´ıt TKIP s sˇifrova´nı´m RC4, pro zpeˇtnou kompatibilitu se starsˇ´ımi zarˇ´ızenı´mi). CCMP je zkratka z Counter-mode CBC (Cipher Block Chaining) MAC (Message Authentication Code) Protocol. Autentizace probı´ha´ bud’ prˇes IEEE 802.1X (WPA2-Enterprise) nebo v jednodusˇsˇ´ım prˇ´ıpadeˇ prˇes PSK stejneˇ jako u WPA (WPA2-PSK, Personal). V datovy´ch ra´mcı´ch se mı´sto slabe´ho RC4 pouzˇ´ıva´ sˇifrova´nı´ AES na 128 bitech, MIC pole o de´lce 64 bitu˚ a cˇ´ıslova´nı´ paketu˚.
P
Narozdı´l od WPA je mozˇne´ zabra´nit u´toku˚m typu Man-in-the-Middle, ale nedoka´zˇe zcela zabra´nit existenci neautorizovany´ch prˇ´ıstupovy´ch bodu˚. Pro autentizaci existuje vı´ce mozˇnostı´ – PBC, PIN, NFC, atd. Tlacˇı´tko WPS (PBC – Push Button) je metoda autentizace pro maxima´lnı´ zjednodusˇenı´ prˇipojova´nı´ zarˇ´ızenı´, ktera´ nejsou zrovna „pocˇ´ıtacˇove´ho typu“. Na AP zma´cˇkneme tlacˇ´ıtko „WPS“ (nebo QSS nebo podobneˇ – hardwarove´ nebo „softwarove´“ tlacˇ´ıtko), pak po neˇkolik desı´tek sekund AP skenuje okolı´ a hleda´ nove´ stanice. Stejne´ tlacˇ´ıtko zma´cˇkneme na zarˇ´ızenı´, ktere´ chceme prˇipojit (lednicˇka, televize apod.). AP detekuje nove´ zarˇ´ızenı´, automaticky provede autentizaci a asociaci. Postup nenı´ u´plneˇ bez rizika: neˇkolik desı´tek sekund je sı´t’ prakticky bez ochrany, nasˇteˇstı´ se tento postup obvykle neprova´dı´ prˇ´ılisˇ cˇasto. WPS prˇes PIN je podobna´ metoda takte´zˇ urcˇena´ pro jednoduche´ prˇipojova´nı´ zarˇ´ızenı´. Na prˇipojovane´m zarˇ´ızenı´ zjistı´me PIN (v administraci zarˇ´ızenı´ nebo na na´lepce), PIN zada´me v administraci AP, zarˇ´ızenı´ si opeˇt vsˇe automaticky vyjedna´ s AP, prˇ´ıpadneˇ mu˚zˇe by´t trˇeba zadat prˇ´ıstupove´ u´daje. Riziko se sice zda´ mensˇ´ı nezˇ u prˇedchozı´ho postupu, ale je trˇeba si uveˇdomit na´sledujı´cı´: • AP s podporou tohoto typu WPS nasloucha´ neusta´le • PIN je 8mı´stne´ cˇ´ıslo, poslednı´ cˇ´ıslice je kontrolnı´m soucˇtem • pokud PIN zada´me sˇpatneˇ, AP vracı´ informaci, ktera´ polovina PINu je sˇpatneˇ! V souhrnu se jedna´ o za´vazˇnou bezpecˇnostnı´ dı´ru, ktera´ je ve firmwaru routeru. Cˇa´stecˇneˇ se da´ rˇesˇit tehdy, pokud v administraci routeru existuje volba vypnutı´ skenova´nı´ zarˇ´ızenı´ prˇipojovany´ch prˇes WPS (zapı´nali bychom jen v prˇ´ıpadeˇ potrˇeby).
P P
6.2
WI-FI
6.2.9
135
Zabezpecˇenı´ Wi-Fi sı´tı´
Kromeˇ nastavenı´ dostatecˇneˇ bezpecˇne´ho sˇifrova´nı´ (WPA2) ma´me jesˇteˇ dalsˇ´ı mozˇnosti. SSID se da´ take´ povazˇovat za mozˇnost zabezpecˇenı´ sı´teˇ. Standardneˇ sı´t’vysı´la´ svoje SSID (broadcast), ale nemusı´ (blokova´nı´ vysı´la´nı´ SSID), pak nenı´ beˇzˇny´m zpu˚sobem viditelna´ v seznamu dostupny´ch sı´tı´ (soukroma´ sı´t’). Skry´va´nı´ SSID vsˇak odporuje specifikaci Wi-Fi, navı´c mu˚zˇe prˇine´st komplikace sousedu˚m (pak nemohou prˇijı´t na to, procˇ je oblast tak zarusˇena´, i kdyzˇ zˇa´dnou sı´t’ nevidı´). Tuto ochranu (skrytı´ SSID) lze snadno prˇekonat – kdyzˇ se kdokoliv prˇihlasˇuje, prˇena´sˇ´ı se SSID a lze ho zachytit, stacˇ´ı jen trochu trpeˇlivosti prˇi nasloucha´nı´. Doporucˇuje se vsˇak alesponˇ prˇenastavit si SSID, protozˇe podle jeho vy´chozı´ hodnoty se da´ poznat vy´robce (hacker pak snadneˇji odhaduje slaba´ mı´sta, bezpecˇnostnı´ mezery, vy´chozı´ prˇihlasˇovacı´ jme´no a heslo do administrace routeru, atd.). Filtrova´nı´ MAC adres mu˚zˇe by´t pouzˇito ve formeˇ whitelistu nebo blacklistu. Prˇ´ıstupove´ body veˇtsˇinou umozˇnˇujı´ nastavit blacklist (MAC adresy, ktery´m je prˇihla´sˇenı´ odmı´tnuto) nebo whitelist (prˇihla´sˇenı´ povoleno) MAC adres a tak urcˇit, ktere´ stanice se nemohou/mohou prˇihla´sit. Blacklist (a vlastneˇ i whitelist) se da´ prˇekonat zmeˇnou MAC adresy. MAC adresy se totizˇ prˇena´sˇejı´ v nezasˇifrovane´ podobeˇ, a tedy prˇi pouzˇitı´ whitelistu nenı´ proble´m zachytit neˇkterou „povolenou“ adresu. Prˇı´stupove´ u´daje implicitneˇ nastavene´ z tova´rny je vhodne´ zmeˇnit. Jedna´ se o IP adresu, SSID, ale prˇedevsˇ´ım o prˇihlasˇovacı´ u´daje (pro administraci prˇ´ıstupove´ho bodu). Pokud chceme konfigurovat nastavenı´ prˇ´ıstupove´ho bodu, obvykle to prova´dı´me prˇes webove´ rozhranı´. Je trˇeba zadat IP adresu zarˇ´ızenı´ do adresove´ho rˇa´dku internetove´ho prohlı´zˇecˇe a da´le prˇihlasˇovacı´ jme´no a heslo. Hned po zprovozneˇnı´ prˇ´ıstupove´ho bodu bychom meˇli zmeˇnit minima´lneˇ prˇ´ıstupove´ heslo (jme´no a heslo by´vajı´ obvykle admin–admin, cisco–cisco, root, 1234, airlive, password, public, apod.). Pro monitorova´nı´ WLAN je mozˇne´ pouzˇ´ıt naprˇ´ıklad tyto na´stroje (volneˇ dostupne´): • NetStumbler – identifikuje prˇ´ıstupove´ body, da´ se pouzˇ´ıt pro zjisˇteˇnı´ neautorizovany´ch prˇ´ıstupovy´ch bodu˚ nebo mozˇny´ch zdroju˚ rusˇenı´ vlastnı´ sı´teˇ • Ethereal – analyza´tor LAN sı´tı´, at’uzˇ „dra´tovy´ch“ nebo bezdra´tovy´ch • AirSnort – monitoring sı´teˇ • Kismet – monitoring sı´teˇ, IDS (Intrusion Detection System) U uzˇivatelu˚ se mu˚zˇeme setkat s tvrzenı´m „Kdo by se asi chteˇl nabourat zrovna do me´ho pocˇ´ıtacˇe?“. Kdo? Spousta lidı´ (nebo softwarovy´ch agentu˚). V soucˇasne´ dobeˇ existujı´ rozsa´hle´ sı´teˇ botu˚ (botnety) – bot je malware, ktery´ z pocˇ´ıtacˇe udeˇla´ „zombie“, spı´cı´ho agenta. Botnety jsou zneuzˇ´ıva´ny naprˇ´ıklad k rozesı´la´nı´ spamu nebo DDoS u´toku˚m. V poslednı´ dobeˇ nejsou zrovna nezajı´mava´ take´ osobnı´ data
´ ryvek z bezpecˇnostnı´ho logu Obra´zek 6.7: U
P
P P $
6.2
WI-FI
136
uzˇivatelu˚, ktera´ se dokonce cˇasto va´zˇou k jejich zameˇstna´nı´ nebo jde o prˇ´ıstupove´ u´daje a certifika´ty k internetove´mu bankovnictvı´. Soucˇa´stı´ ADSL Wi-Fi routeru˚ by´va´ hardwarovy´ firewall, ten bychom rozhodneˇ meˇli vyuzˇ´ıvat jako doplneˇk k softwarove´mu firewallu, ktery´ bezpochyby ma´me nainstalova´n a rˇa´dneˇ aktualizova´n (a take´ vedle antiviru a antispywaru). Dalsˇ´ı informace o zabezpecˇenı´ bezdra´tove´ sı´teˇ: • 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 cˇtvrte´ a pa´te´ generace
Veˇtsˇina toho, co jsme se azˇ dosud naucˇili o Wi-fi sı´tı´ch, platilo pro Wi-fi sı´teˇ trˇetı´ generace (nebo starsˇ´ı) – v podstateˇ IEEE 802.11g a starsˇ´ı. Neˇktere´ zdroje rˇadı´ do trˇetı´ generace take´ IEEE 802.11n, jine´ zdroje je rˇadı´ jizˇ do generace cˇtvrte´. Sı´teˇ cˇtvrte´ generace. Ve firemnı´m prostrˇedı´ se zacˇ´ınajı´ prosazovat sı´teˇ cˇtvrte´ generace (takto ten pojem budeme cha´pat v na´sledujı´cı´m textu), kde se zmeˇny oproti starsˇ´ı generaci projevujı´ u mezilehly´ch zarˇ´ızenı´ (routeru˚) – tedy koncova´ zarˇ´ızenı´ (sı´t’ove´ Wi-fi karty v pocˇ´ıtacˇ´ıch apod.) nemajı´ proble´my s kompatibilitou. V prˇ´ıpadeˇ nutnosti pokrytı´ veˇtsˇ´ı oblasti signa´lem se mı´sto klasicky´ch cˇa´stecˇneˇ se prˇekry´vajı´cı´ch buneˇk pouzˇ´ıvajı´ blankety. Blankety jsou definova´ny na fyzicke´ vrstveˇ a na te´to vrstveˇ take´ docha´zı´ k oddeˇlenı´ jednotlivy´ch sluzˇeb. Jeden blanket funguje prˇes vsˇechny AP v sı´ti a vyuzˇ´ıva´ jeden jediny´ kana´l (takte´zˇ pro vsˇechny AP), prˇesto se jednotlive´ AP navza´jem nerusˇ´ı. Dokonce prˇi zvy´sˇenı´ hustoty AP se zvysˇuje kvalita a prˇenosova´ rychlost signa´lu (u prˇedchozı´ generace by se AP na spolecˇne´m kana´le navza´jem rusˇily). Pokud chceme vytvorˇit vı´ce fyzicky oddeˇleny´ch sı´tı´ (s prˇekry´vajı´cı´mi se oblastmi), vytvorˇ´ıme pro neˇ samostatne´ blankety. Zarˇ´ızenı´ v ra´mci jednoho blanketu pracujı´ na stejne´m kana´lu, zarˇ´ızenı´ z ru˚zny´ch blanketu˚ pracujı´ na ru˚zny´ch kana´lech, tedy teoreticky nedocha´zı´ k ovlivneˇnı´ komunikace mezi blankety (blanketu˚ nesmı´ by´t moc). V sı´ti je jediny´ centra´lnı´ prvek, ostatnı´ AP fungujı´ v ultra-tenke´m rezˇimu, tedy pouze prˇeposı´lajı´ signa´l, jsou k centra´lnı´mu prvku prˇipojeny prˇes ethernetovou kabela´zˇ (vcˇetneˇ napa´jenı´ prˇes PoE). Z pohledu uzˇivatelske´ho zarˇ´ızenı´ se cela´ sı´t’ mezilehly´ch prvku˚ (konkre´tneˇji jeden blanket) jevı´ jako jeden jediny´ AP s jedinou MAC adresou. Roaming (prˇecha´zenı´ mezi AP v tomte´zˇ blanketu, prˇehlasˇova´nı´ se mezi AP) je zcela transparentnı´, plynuly´ a bezproble´movy´. Souhrnneˇ o Wi-fi cˇtvrte´ generace: • Jsou kompatibilnı´ s beˇzˇny´mi zarˇ´ızenı´mi IEEE 802.11a/b/g/n.
P P
P
6.3
WIMAX
137
• Existuje jeden centra´lnı´ prvek, ktery´ vsˇe rˇ´ıdı´. • Cˇ´ım vı´c AP, tı´m lepsˇ´ı pokrytı´, signa´l a rychlost, navza´jem se nerusˇ´ı. • Kvalitnı´ zabezpecˇenı´ (rˇesˇenı´ je pro firemnı´ sı´teˇ). Proble´mem tohoto rˇesˇenı´ je cena (zejme´na cena centra´lnı´ho prvku, v rˇa´du cca desı´tky tisı´c korun), proto se vyuzˇ´ıva´ pouze tam, kde jsou tyto na´klady odu˚vodnitelne´ (rozsa´hla´ dobrˇe pokryta´ oblast, hodneˇ AP na jeden centra´lnı´ prvek), typicky v nemocnicı´ch, frekventovany´ch skladovacı´ch prostora´ch, neˇktery´ch firma´ch. Rozhodneˇ se nejedna´ o rˇesˇenı´ pro SOHO. Sı´teˇ pa´te´ generace. Beˇhem roku 2012 se do obchodu˚ dastala zarˇ´ızenı´ pracujı´cı´ podle standardu IEEE 802.11ac. Tato zarˇ´ızenı´ majı´ komunikovat na frekvencı´ch kolem 5 GHz, ktere´ jesˇteˇ nejsou tak zarusˇene´ jako pa´smo 2,4 GHz. Mu˚zˇeme se take´ setkat s oznacˇenı´m 5G Wi-Fi, ktere´ nara´zˇ´ı jak na generaci, tak i na pouzˇite´ pa´smo. O tomto standardu jsme se dozveˇdeˇli uzˇ v prˇedchozı´m textu (viz kap. 6.2.3, str. 120). Dalsˇ´ı 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ı´teˇ-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 vlastneˇ bezdra´tova´ metropolitnı´ sı´t’(WMAN – Wireless MAN). Jejı´m u´cˇelem je prˇedevsˇ´ım poskytnout rychly´ a spolehlivy´ prˇ´ıstup k Internetu, tedy technologie poslednı´ mı´le. Du˚lezˇitou vlastnostı´ je take´ prˇ´ıma´ podpora QoS (to je jedna z odlisˇnostı´ oproti Wi-Fi, kde se setka´va´me pouze s „best effort“, QoS je mozˇne´ zave´st azˇ dodatecˇneˇ pomocı´ IEEE 802.11e).
P
Na standardizaci a certifikaci produktu˚ se podı´lı´ WiMAX Forum, ktere´ je sdruzˇenı´m vy´robcu˚ WiMAX zarˇ´ızenı´ (je to obdoba Wi-Fi Alliance). Pu˚vodnı´ specifikace IEEE 802.16 z roku 2001 stanovila pouzˇitı´ kmitocˇtove´ho pa´sma 10–66 GHz, ktere´ vsˇak vyzˇaduje prˇ´ımou viditelnost komunikujı´cı´ch uzlu˚. Proto byla v roce 2003 tato specifikace zcela nahrazena novou, kde se vyuzˇ´ıva´ kmitocˇtove´ pa´smo 2–11 GHz (u na´s nejcˇasteˇji 3.5 GHz) nevyzˇadujı´cı´ prˇ´ımou viditelnost komunikujı´cı´ch uzlu˚ (NLOS, Non Line of Sight), vyuzˇ´ıva´ odrazu˚ od okolnı´ch objektu˚. Pa´smo je licencovane´, cozˇ se projevuje i na cena´ch zarˇ´ızenı´ a prˇipojenı´. Roku 2005 se objevila mozˇnost mobility (handover, roaming – prˇi pohybu do rychlosti max. 150 km/h) ve standardu IEEE 802.16e-2005, do te´ doby nebylo mozˇne´ zajistit plynule´ prˇeda´va´nı´ pohybujı´cı´ch se uzlu˚ mezi za´kladnovy´mi stanicemi.
P
6.3
WIMAX
138
Teoreticky´ dosah signa´lu je 50 km, v beˇzˇne´ za´stavbeˇ se pocˇ´ıta´ s dosahem 3–5 km. To je porˇa´d vı´c nezˇ Wi-Fi, kde je obvykly´ dosah maxima´lneˇ v desı´tka´ch metru˚. Prˇenosova´ kapacita je 30–75 Mb/s (podle konkre´tnı´ho standardu), tu vsˇak sdı´lejı´ vsˇechny prˇipojene´ stanice. Na fyzicke´ vrstveˇ se pouzˇ´ıva´ OFDM nebo OFDMA (OFDM Access). Prvnı´ zmı´neˇne´ uzˇ zna´me (stovky nosny´ch frekvencı´ – subkana´lu˚, vza´jemneˇ ortogona´lnı´ch, aby je bylo mozˇne´ oddeˇlit). OFDMA je podobne´, jen zatı´mco v OFDM jsou vsˇechny subkana´ly jedine´ho kana´lu na frekvencı´ch „za sebou“ (cely´ kana´l je vyhrazen jedine´mu uzˇivateli), v OFDMA jsou kana´ly jednoho subkana´lu rozprostrˇeny v cele´m spektru a tedy mezi subkana´ly jednoho uzˇivatele lze vybı´rat ty, ktere´ jsou na v tu chvı´li nejkvalitneˇjsˇ´ıch frekvencı´ch. Dalsˇ´ı vylepsˇenı´, S-OFDMA (Scalable OFDMA), ma´ zlepsˇit kvalitu signa´lu prˇi NLOS (bez prˇ´ıme´ viditelnosti).
6.3.2
Zarˇı´zenı´
V soucˇasne´ dobeˇ se setka´va´me se zarˇ´ızenı´mi oznacˇeny´mi jako WiMAX nebo preWiMAX. PreWiMAX zarˇ´ızenı´ odpovı´dajı´ specifikaci IEEE 802.16, ale nenı´ u nich potvrzena interoperatibilita se zarˇ´ızenı´mi stejne´ho typu od ostatnı´ch vy´robcu˚. Jednı´m z nejzna´meˇjsˇ´ıch dodavatelu˚ WiMAX zarˇ´ızenı´ je firma Alvarion, z dalsˇ´ıch naprˇ´ıklad RedMAX nebo AirSpan. Hlavnı´m cˇla´nkem sı´teˇ je za´kladnova´ stanice umı´steˇna´ obvykle na vyvy´sˇene´m mı´steˇ, cozˇ je veˇtsˇinou vysoka´ budova. Dalsˇ´ı u´rovnı´ v hierarchii jsou vneˇjsˇ´ı zarˇ´ızenı´ zahrnujı´cı´ ante´nu, ta se obvykle umı´st’ujı´ na strˇechy nebo venkovnı´ zdi domu˚. Poslednı´ u´rovnı´ jsou vnitrˇnı´ koncova´ zarˇ´ızenı´. Existujı´ take´ zarˇ´ızenı´, ktera´ v sobeˇ sdruzˇujı´ obeˇ posledneˇ jmenovana´, tedy vnitrˇnı´ koncova´ zarˇ´ızenı´ s (integrovanou) ante´nou, ta vsˇak vyzˇadujı´ lepsˇ´ı pokrytı´.
P P
V komunikaci lze pouzˇ´ıt cˇasovy´ (TDD) i frekvencˇnı´ (FDD) duplex (u na´s jsou povolena zarˇ´ızenı´ pouzˇ´ıvajı´cı´ FDD) – nemluvı´me zde o multiplexu, protozˇe komunikace je sice obousmeˇrna´, ale v jednom okamzˇiku na dane´ frekvenci (ve skutecˇnosti ve dvou kana´lech, jednom pro kazˇdy´ smeˇr) jen mezi dveˇma uzly. Zpu˚sob vyuzˇitı´ signa´lu je pomeˇrneˇ volny´, za´lezˇ´ı na poskytovateli prˇipojenı´, jak se se svy´mi za´kaznı´ky dohodne. Spojenı´ mu˚zˇe by´t symetricke´ nebo asymetricke´, je smluvneˇ garantova´na konkre´tnı´ kvalita sluzˇby (QoS). V soucˇasne´ dobeˇ je WiMAX provozova´n na vı´ce mı´stech v CˇR, ale spı´sˇe loka´lneˇ v mensˇ´ıch oblastech (spı´sˇe jde o oblasti ve velky´ch meˇstech, kde se ocˇeka´va´ firemnı´ klientela). Kana´ly 1–14 (o sˇ´ırˇce 3,5 MHz) jsou urcˇeny pro loka´lnı´ opera´tory, kana´ly 15–20 pro celoplosˇne´ opera´tory. Pro WiMAX je typicka´ centralizovanost, jejı´mzˇ cı´lem je prˇedevsˇ´ım odstranit nebezpecˇ´ı kolizı´. Cela´ komunikace s koncovy´mi uzly je vzˇdy rˇ´ızena za´kladnovou stanicı´, ta urcˇuje, kdy kdo bude vysı´lat, prˇideˇluje kana´ly pro komunikaci. Dalsˇı´ 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/
MOBILNI´ TECHNOLOGIE
6.4
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ı´teˇ jsou prˇedevsˇ´ım charakteristicke´ svou mobilitou, tedy stanice, ktera´ je soucˇa´stı´ mobilnı´ sı´teˇ, se mu˚zˇe pohybovat se zachova´nı´m signa´lu. V te´to sekci se budeme zaby´vat prˇedevsˇ´ım mobilnı´mi WAN, trˇebazˇe existujı´ rˇesˇenı´ i pro mensˇ´ı sı´teˇ.
6.4.1
Prvnı´ generace (1G)
Prvnı´ generace mobilnı´ch datovy´ch sı´tı´ byla jesˇteˇ analogova´. Z toho du˚vodu se take´ vyuzˇ´ıval frekvencˇnı´ multiplex (FDMA), kazˇdy´ prˇipojeny´ uzˇivatel ma´ prˇideˇlen jeden kana´l, a to vy´hradneˇ.
Prvnı´ komercˇnı´ mobilnı´ syste´m byl NMT (Nordic Mobile Telephone) fungujı´cı´ nejdrˇ´ıv v Saudske´ Ara´bii a na´sledneˇ v seversky´ch zemı´ch (Norsko, Sˇve´dsko) od roku 1981. Do prvnı´ generace take´ patrˇ´ı americky´ AMPS (Analog Mobile Phone System) z roku 1982 a TACS (Total Access Communications System) vytvorˇeny´ pu˚vodneˇ pro Velkou Brita´nii, ale pozdeˇji se rozsˇ´ırˇil prˇedevsˇ´ım v Asii.
6.4.2
Druha´ generace (2G)
Sı´teˇ druhe´ generace porˇa´d pracujı´ na principu prˇepojova´nı´ okruhu˚. Du˚sledkem je obvykla´ tarifikace odvozena´ od doby prˇipojenı´ (jde o vyta´cˇene´ prˇipojenı´). GSM. Na zacˇa´tku 90. let (1992) vznikla druha´ generace, ktera´ je dodnes funkcˇnı´ (vedle dalsˇ´ıch generacı´). Byl zaveden digita´lnı´ prˇenos dat, ale sı´t’ je optimalizova´na prˇedevsˇ´ım pro hlas, tedy propustnost je na velmi nı´zke´ u´rovni. Prvnı´m za´stupcem te´to generace je syste´m GSM (Global System for Mobile Communications). Prˇestozˇe jde o digita´lnı´ sı´t’, porˇa´d vyuzˇ´ıva´ prˇepojova´nı´ okruhu˚, a to s cˇasovy´m (TDMA) i frekvencˇnı´m (FDMA) multiplexem – kombinace TDMA over FDMA (cˇasove´ sloty se prˇena´sˇejı´ vzˇdy v ra´mci urcˇite´ frekvence). GSM pracuje na trˇech ru˚zny´ch frekvencı´ch, hovorˇ´ıme o GSM900 (frekvence 900 MHz), GSM1800 (1800 MHz) a GSM1900 (1900 MHz). GSM sı´t’se skla´da´ z buneˇk, kazˇda´ bunˇka ma´ svou za´kladnovou stanici (base transceiver station). Za´kladnove´ stanice jsou napojeny na pa´terˇnı´ sı´t’skla´dajı´cı´ se z teˇchto typu˚ uzlu˚: • BSC (Base Station Controller) – rˇ´ıdicı´ uzel za´kladnovy´ch stanic, jeden BSC spravuje neˇkolik za´kladnovy´ch stanic (do pocˇtu 9), komunikace se za´kladnovy´mi stanicemi mu˚zˇe probı´hat na neˇktere´ ra´diove´ frekvenci nebo s vyuzˇitı´m kabelu˚ (opticky´ch cˇi metalicky´ch), • MSC (Mobile Switching Center) – mobilnı´ u´strˇedna, k nı´ je prˇipojeno vı´ce BSC (obvykle kabely), neˇktere´ MSC slouzˇ´ı jako bra´ny do pozemnı´ telekomunikacˇnı´ sı´teˇ nebo jine´ mobilnı´ sı´teˇ, kazˇda´ MSC vede seznam prˇipojeny´ch mobilnı´ch stanic (pokud stanice opustı´ oblast spravovanou touto MSC, je jejı´ za´znam vymaza´n)
P
MOBILNI´ TECHNOLOGIE
6.4
140
• dalsˇ´ı podpu˚rne´ uzly sı´teˇ, naprˇ´ıklad autentizacˇnı´ databa´ze (informace o vsˇech u´cˇastnı´cı´ch, kterˇ´ı mohou by´t prˇipojeni do sı´teˇ), registr stanic (jsou zde ulozˇeny identifika´tory povoleny´ch stanic, da´le identifika´tory, o ktery´ch je zna´mo, zˇe byly ukradeny, a da´le identifika´tory porouchany´ch stanic), SMS centrum, atd. • operacˇnı´ a administrativnı´ subsyste´m (OSS, Operation SubSystem) – prova´dı´ administraci a u´drzˇbu cele´ sı´teˇ, zajisˇt’uje registraci a tarifikaci, pouzˇ´ıva´ registry a databa´ze z prˇedchozı´ho bodu, nenı´ prˇ´ımou soucˇa´stı´ sı´teˇ. Uzly MSC a dalsˇ´ı podpu˚rne´ uzly sı´teˇ jsou hlavnı´ cˇa´stı´ pa´terˇnı´ sı´teˇ, ktera´ se souhrnneˇ nazy´va´ Network Switching Subsystem (NSS). Celou sı´t’tedy mu˚zˇeme rozdeˇlit do trˇ´ı vrstev – vrstva za´kladnovy´ch stanic s jejich rˇ´ıdicı´mi uzly, vrstva NSS a vrstva OSS. Za´kladnove´ stanice jsou rozmı´steˇny tak, aby se bunˇky (prˇiblizˇneˇ kruhove´, i kdyzˇ jsou zobrazova´ny jako sˇestiu´helnı´ky – „pla´stve“) prˇekry´valy. To vsˇak znamena´, zˇe dvojice buneˇk, ktere´ jsou prˇ´ımo vedle sebe, nesmı´ pouzˇ´ıvat tyte´zˇ komunikacˇnı´ kana´ly, tyte´zˇ kana´ly mu˚zˇe pouzˇ´ıvat azˇ bunˇka natolik vzda´lena´, aby nedocha´zelo k inferencı´m. Rozdeˇlenı´ kana´lu˚ se prova´dı´ metodou podobnou obarvova´nı´, kterou zna´me z teorie grafu˚. Prˇi plne´m pokrytı´ signa´lem je mozˇna´ plna´ mobilita stanice, handover – prˇeda´va´nı´ stanice mezi jednotlivy´mi bunˇkami. Oproti prvnı´ generaci je zde prˇedevsˇ´ım prˇechod na digita´lnı´ technologii, da´le veˇtsˇ´ı odolnost proti rusˇenı´ a odposlechu, snadne´ napojenı´ na pozemnı´ telekomunikacˇnı´ syste´my, a take´ vysˇsˇ´ı rychlost. Teoreticka´ rychlost je 13 kb/s pro kazˇdy´ smeˇr, rea´lneˇ 9.6 kb/s. CDMA. Dalsˇ´ı technologiı´, kterou mu˚zˇeme zarˇadit do druhe´ generace, je CDMA (Code Division Multiple Access). Ve specifikaci CDMA se sice pocˇ´ıta´ s prˇenosem dat i hlasu, ale u na´s je CDMA poskytova´na jen jako datova´ sı´t’. Oproti GSM ma´ vy´hodu nizˇsˇ´ıch frekvencı´ (450 MHz), za´kladnove´ stanice CDMA mohou by´t od sebe vı´ce vzda´leny. Teoreticka´ rychlost uploadu je 1024 kb/s, te´ vsˇak lze dosa´hnout jen v mı´stech s vy´konneˇjsˇ´ımi za´kladnovy´mi stanicemi (naprˇ´ıklad v Praze nebo v Brneˇ). Download je o neˇco rychlejsˇ´ı (azˇ 3.1 Mb/s, v rea´lu take´ me´neˇ, neˇkolik set kb/s), jde o asymetricky´ prˇenos.
P
CDMA pouzˇ´ıva´ jiny´ typ multiplexu – ko´dovy´. Spocˇ´ıva´ v tom, zˇe v ra´mci jednoho sdı´lene´ho me´dia se prˇena´sˇ´ı vı´ce digita´lnı´ch signa´lu˚, ktere´ jsou rozlisˇova´ny pomocı´ ko´dova´nı´ (tedy ne rozdeˇlenı´m do cˇasovy´ch slotu˚ ani pouhy´m rozvrzˇenı´m do frekvencı´).
6.4.3
Prˇechodova´ generace (2.5G)
Zatı´mco mobilnı´ sı´teˇ druhe´ generace byly zalozˇeny na prˇepı´na´nı´ okruhu˚, v prˇechodove´ generaci se jizˇ pouzˇ´ıva´ prˇepı´na´nı´ paketu˚, ktere´ je pro prˇenos dat vy´hodneˇjsˇ´ı. Typicka´ tarifikace je bud’ za prˇenesena´ data nebo pausˇa´l, netarifikuje se prˇipojena´ doba (tj. nejedna´ se o vyta´cˇene´ prˇipojenı´). GPRS. Prvnı´ mobilnı´ technologiı´ prˇechodove´ generace je GPRS (General Packet Radio Service). Jedna´ se o na´stavbu GSM (technicky ne nutneˇ GSM, mu˚zˇe by´t va´za´na na jine´ typy sı´tı´), ktera´ umozˇnˇuje jedne´ stanici vyuzˇ´ıvat azˇ 8 GSM kana´lu˚ (pokud jsou zrovna volne´). Nejedna´ se jesˇteˇ o sˇirokopa´smovou technologii, ale dı´ky rozsˇ´ırˇenı´ pa´sma azˇ na 8na´sobek jsou prˇenosove´ rychlosti
P
6.4
MOBILNI´ TECHNOLOGIE
141
vysˇsˇ´ı. Jsou vyuzˇ´ıva´ny ty z osmi GSM kana´lu˚, ktere´ jsou pra´veˇ volne´, tedy prˇenosova´ kapacita sı´teˇ je vyuzˇ´ıva´na u´cˇelneˇji, kana´ly nejsou blokova´ny po celou dobu „prˇipojenı´“. Aby fungovalo napojenı´ na GSM, bylo nutne´ do sı´teˇ GSM prˇidat jesˇteˇ jednu vrstvu. Stanice BSC da´le zu˚sta´vajı´ napojeny na MSC, ale navı´c jsou napojeny na sı´t’ uzlu˚ oznacˇovany´ch SGSN (Serving GPRS Support Node) – podpu˚rny´ch uzlu˚ sı´teˇ GPRS (obdoba MSC u´strˇeden), a da´le soucˇa´stı´ prˇ´ıdavne´ pa´terˇnı´ sı´teˇ jsou uzly GGSN (Gateway GPRS Support Node) slouzˇ´ıcı´ jako bra´ny do datove´ paketove´ IP sı´teˇ. Uzly SGSN a GGSN mezi sebou komunikujı´ protokolem GTP (GPRS Tunelling Protocol), cozˇ je aplikacˇnı´ protokol vyuzˇ´ıvajı´cı´ protokoly TCP a UDP. Uzly SGSN neslouzˇ´ı pouze pro prˇenos, je zde implementova´na take´ spra´va pa´terˇnı´ sı´teˇ a tarifikace. Z toho du˚vodu prˇistupujı´ take´ do specificky´ch uzlu˚ a databa´zı´ sı´teˇ GSM. Prˇenosove´ rychlosti se odvozujı´ od pouzˇite´ho ko´dova´nı´. Cˇ´ım silneˇjsˇ´ı ko´dova´nı´, tı´m nizˇsˇ´ı rychlost. Celkova´ mozˇna´ dosazˇena´ rychlost je 22.8 kb/s na jeden kana´l, ale cˇa´st rychlosti je pohlcena rezˇiı´ ko´dova´nı´. Prˇi nejsilneˇjsˇ´ım ko´dova´nı´ (CS-1) dosahujeme rychlosti maxima´lneˇ kolem 9 kb/s na kana´l, prˇi nejslabsˇ´ım ko´dova´nı´ (CS-4) maxima´lneˇ kolem 21 kb/s na kana´l. Volba ko´dova´nı´ je zcela automaticka´, za´visı´ na vzda´lenosti stanice od za´kladnove´ stanice (cˇ´ım da´l je stanice, tı´m silneˇjsˇ´ı musı´ by´t ko´dova´nı´). Da´le je rychlost prˇenosu ovlivneˇna mnozˇstvı´m kana´lu˚, ktere´ stanice mu˚zˇe vyuzˇ´ıvat (maxima´lneˇ 8 pro kazˇdy´ smeˇr). V za´kladnı´m nastavenı´ musı´ uzˇivatel GPRS vzı´t zavdeˇk tı´m, co „zbude“ po uzˇivatelı´ch GSM hlasovy´ch prˇenosu˚, ale v neˇktery´ch typech tarifu˚ se mu˚zˇeme setkat s garancı´ urcˇite´ho pocˇtu kana´lu˚ (vyhrazenı´m pouze pro data). GPRS zava´dı´ za´kladnı´ mozˇnost rˇ´ızenı´ kvality sluzˇeb (QoS) zalozˇenou na prioriteˇ, propustnosti, zpozˇdeˇnı´ nebo spolehlivosti. Je samozrˇejmeˇ na opera´torovi, zda bude QoS nabı´zet svy´m za´kaznı´ku˚m. EDGE. Technologie EDGE (Enhanced Data rates for GSM Evolution) je sice take´ na´stavbou sı´teˇ GSM a za´kladnı´ princip je podobny´, ale navı´c signa´l moduluje metodou 8-PSK, cozˇ v rea´lu znamena´ azˇ trojna´sobny´ na´ru˚st rychlostı´ oproti GPRS.
6.4.4
P
Trˇetı´ generace (3G)
Trˇetı´ generace prˇina´sˇ´ı mozˇnost soubeˇzˇne´ho vyuzˇ´ıva´nı´ neˇkolika sluzˇeb (u prˇedchozı´ch generacı´ nebylo mozˇne´ kombinovat hlas a data). Technologie jsou zalozˇeny na varianta´ch metody CDMA, tedy se pouzˇ´ıva´ ko´dovy´ multiplex. Narozdı´l od prˇedchozı´ch generacı´, trˇetı´ generace jizˇ nenı´ striktneˇ optimalizova´na pro prˇenos hlasu, vı´ce se pocˇ´ıta´ s datovy´mi prˇenosy. UMTS. Vylepsˇenı´m GSM je technologie UMTS (Universal Mobile Telecommunication System). Nejedna´ se o pouhou na´stavbu, zavedenı´ UMTS znamenalo pomeˇrneˇ velke´ za´sahy do infrastruktury sı´teˇ. V tomto typu sı´teˇ je take´ nabı´zena vylepsˇena´ QoS. Za´kladem je WCDMA (Wideband CDMA), cozˇ je sˇirokopa´smova´ metoda prˇenosu. V metodeˇ WCDMA ma´ kazˇdy´ uzˇivatel prˇideˇleno frekvencˇnı´ pa´smo, ktere´ pouzˇ´ıva´. V ko´dove´m multiplexu mu˚zˇe tote´zˇ pa´smo vyuzˇ´ıvat vı´ce uzˇivatelu˚, jsou odlisˇeni jednoznacˇny´m bina´rnı´m ko´dem. Architektura sı´teˇ je podobna´ sı´ti GPRS a zcˇa´sti na nı´ stavı´. Uzel s na´zvem Node B je obdobou za´kladnove´ stanice. Zprostrˇedkova´va´ komunikaci mezi koncovou stanicı´ a samotnou UMTS sı´tı´,
P
6.4
MOBILNI´ TECHNOLOGIE
142
zajisˇt’uje take´ modulaci, ko´dova´nı´, ochranu proti chyba´m. Dalsˇ´ı vrstvu sı´teˇ tvorˇ´ı rˇ´ıdicı´ jednotka ra´diove´ sı´teˇ (RNC, Radio Network Controller), tyto jednotky jsou obdobou BSC v GSM. Stanice RNC tvorˇ´ı dohromady vrstvu nazvanou UTRAN (UMTS Terrestrial Radio Access Network). RNC majı´ za u´kol rˇ´ıdit uzly Node B, prˇideˇlovat kana´ly, rˇ´ıdit handover (prˇeda´va´nı´ mobilnı´ch stanic), sˇifrovat, atd. Dalsˇ´ı vrstvou je pa´terˇnı´ sı´t’ (CN, Core Network). Soucˇa´stı´ pa´terˇnı´ sı´teˇ jsou obvykle uzly patrˇ´ıcı´ do GSM/GPRS sı´teˇ, ale vyzˇadujı´ drobneˇjsˇ´ı u´pravy, aby doka´zaly spolupracovat s UMTS sı´tı´. Pa´terˇnı´ sı´t’ zajisˇt’uje navazova´nı´ spojenı´, smeˇrova´nı´, vedenı´ provoznı´ch databa´zı´ a provoz bran do jiny´ch sı´tı´. UMTS nenı´ u na´s, ale ani v jiny´ch zemı´ch, moc rozsˇ´ırˇena´. Vzhledem k nutny´m u´prava´m infrastruktury se s UMTS typicky pocˇ´ıta´ pouze ve velky´ch meˇstech. Teoreticka´ rychlost je azˇ 2 Mb/s, ve skutecˇnosti se vsˇak dosahuje pouze rychlosti neˇkolika desı´tek (mı´sty i stovek) kb/s. HSDPA. Dalsˇ´ı zvy´sˇenı´ rychlosti a snı´zˇenı´ latence technologie UMTS prˇina´sˇ´ı HSDPA (High-Speed Downlink Packet Access), jedna´ se tedy o jake´si vylepsˇenı´ UMTS pro download (slovo „Downlink“ v na´zvu). Zmeˇny je docı´leno zvolenou modulacı´ – QPSK (Quadrature Phase Shift Keying, pouzˇ´ıva´ se i v UMTS) nebo 16QAM, a da´le jiny´mi mechanismy pla´nova´nı´ vysı´la´nı´ (pla´nova´nı´ zalozˇene´ na QoS) a rˇ´ızenı´ chyb.
P
Stejneˇ jako UMTS, take´ HSDPA pouzˇ´ıva´ WCDMA, ale navı´c prˇida´va´ nove´ mechanismy a novy´ typ cˇisteˇ datove´ho kana´lu. Zatı´mco v UMTS jsou pakety odesı´la´ny kazˇdy´ch 10 ms, v HSDPA jsou odesı´la´ny kazˇde´ 2 ms. Pro zvy´sˇenı´ propustnosti je take´ mozˇne´ vyuzˇ´ıt technologii MIMO. Prˇenosove´ rychlosti jsou obecneˇ vysˇsˇ´ı nezˇ v prˇ´ıpadeˇ UMTS, v soucˇasne´ dobeˇ kolem 1 Mb/s, ovsˇem stejneˇ jako u jiny´ch mobilnı´ch sı´tı´ s velky´mi odchylkami v obou smeˇrech. Existujı´ varianty HSDPA, ktere´ dosa´hnou azˇ na 14 Mb/s, ale ty u na´s nejsou implementova´ny. HSUPA. Tato technologie je obdobou prˇedchozı´, ale pro upload (High-Speed Uplink Packet Access). Jejı´m u´cˇelem je tedy zvy´sˇit rychlost a celkovou kvalitu (vcˇ. latence) u uploadu. Technologie HSDPA a HSUPA se souhrnneˇ oznacˇujı´ HSPA, ale opera´tor nemusı´ nutneˇ pouzˇ´ıt obeˇ (u na´s O2 implementuje pouze UMTS/HSDPA).
6.4.5
P
Dalsˇı´ generace
Technologie FLASH-OFDM (Fast Low-latency Access with Seamless Handoff-Orthogonal Frequency-Division Multiplexing) je jizˇ rˇazena do cˇtvrte´ generace (4G), za´kaznı´k je cˇasto sezna´men pouze se zkratkou 4G. Ortogona´lnı´ multiplex (OFDM) je zna´m jizˇ velmi dlouho. Ve varianteˇ FLASH-OFDM znamena´ propojenı´ OFDM s metodami CDMA a TDMA. Vy´sledkem jsou vysˇsˇ´ı prˇenosove´ rychlosti (relativneˇ, opeˇt s rozptylem) a nı´zka´ latence. Rychlost se pohybuje i ve stovka´ch kb/s (download je veˇtsˇinou v rozmezı´ 200–300 kb/s, trˇebazˇe se teoreticky uda´va´ azˇ 1,5 Mb/s). Dalsˇ´ı vy´hodou je pokrocˇila´ mozˇnost rˇ´ızenı´ kvality sluzˇeb (QoS). Dı´ky nı´zky´m latencı´m a vyuzˇitı´ QoS je na FLASH-OFDM mozˇne´ pouzˇ´ıvat IP telefonii. LTE (Long Term Evolution) je zatı´m hudba budoucnosti (alesponˇ u na´s, na neˇktery´ch mı´stech ve sveˇteˇ uzˇ funguje). Cı´lem je dosa´hnout velmi vysoky´ch rychlostı´ (azˇ 100 Mb/s na downstreamu,
P
P
MOBILNI´ TECHNOLOGIE
6.4
143
50 Mb/s na upstreamu) prˇi velmi nı´zke´ latenci (10 ms). V soucˇasne´ dobeˇ LTE rea´lneˇ dosahuje na downstreamu te´meˇrˇ 80 Mb/s. Pouzˇitı´ variant CDMA se neprˇedpokla´da´, mı´sto nich se (alesponˇ na downstreamu) vyuzˇ´ıva´ pouze neˇktera´ varianta OFDM. Sˇ´ırˇka kana´lu˚ nenı´ pevna´, OFDM co nejefektivneˇji vyuzˇ´ıva´ pa´smo a pouzˇ´ıva´ adaptivnı´ sˇ´ırˇky signa´lu˚, ktere´ jsou naskla´da´ny tak blı´zko u sebe, jak jen dovoluje nutnost je na druhe´m konci linky zase oddeˇlit. Prvnı´ varianta LTE jesˇteˇ patrˇ´ı do trˇetı´ generace (vpodstateˇ na´stavba UMTS), azˇ na´sledujı´cı´ varianta, LTE Advanced, je rˇazena do cˇtvrte´ generace. Dalsˇı´ 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 te´to poneˇkud netypicky nazvane´ kapitole rozvineme za´kladnı´ kameny pocˇ´ıtacˇovy´ch sı´tı´ – bridging, switching a routing. Podı´va´me se na protokol STP a jeho varianty, virtua´lnı´ sı´teˇ (VLAN), smeˇrovacı´ algoritmy. Da´le se sezna´mı´me s pa´terˇnı´ sı´tı´ CESNET2 a na´sleduje te´ma kvality sluzˇeb (QoS). Poslednı´ sekce te´to kapitoly je veˇnova´na typicke´mu za´stupci distribuovany´ch syste´mu˚ – DNS, a typicke´mu za´stupci centralizovany´ch syste´mu˚ – Active Directory.
7.1 7.1.1
Pojmy Typy syste´mu˚
Centralizovany´ syste´m je syste´m s jedinou centra´lnı´ rˇ´ıdicı´ jednotkou. Komunikace probı´ha´ obvykle ve formeˇ klient-server, kde server je pra´veˇ ta centra´lnı´ rˇ´ıdicı´ jednotka. V oblasti pocˇ´ıtacˇovy´ch sı´tı´ mu˚zˇeme k centralizovany´m architektura´m zarˇadit
P
• protokol RADIUS, kde centralizovanou jednotkou je RADIUS server, komunikujı´cı´ se svy´mi klienty (naprˇ´ıklad access pointy – prˇ´ıstupovy´mi body bezdra´tove´ sı´teˇ), • protokol CMIP (Common Management Information Protocol), cozˇ je protokol z ISO/OSI urcˇeny´ pro spra´vu sı´teˇ (obdoba SNMP). Decentralizovany´ syste´m ma´ vı´ce rˇ´ıdicı´ch jednotek (serverovy´ch/spra´vnı´ch uzlu˚), vı´ceme´neˇ ´ cˇelem (a vy´hodou oproti centralizovany´m syste´mu˚m) je rovnocenny´ch (s podobny´mi funkcemi). U zvy´sˇenı´ robustnosti sı´teˇ (tute´zˇ funkci poskytuje vı´ce „centra´lnı´ch“ – serverovy´ch – uzlu˚, klientske´ uzly mohou komunikovat s ktery´mkoliv uzlem poskytujı´cı´m zˇa´danou sluzˇbu). Je mozˇne´ snadno vyrˇesˇit situaci, kdy jeden ze serverovy´ch uzlu˚ prˇestane sluzˇbu poskytovat (naprˇ´ıklad je odpojen od sı´teˇ).
144
P
7.1
POJMY
145
Nevy´hodou je na´rocˇneˇjsˇ´ı implementace, protozˇe serverove´ uzly musejı´ by´t synchronizova´ny (prˇedevsˇ´ım jejich databa´ze). V oblasti pocˇ´ıtacˇovy´ch sı´tı´ se s decentralizovanou architekturou setka´me naprˇ´ıklad • mnohe´ smeˇrovacı´ protokoly jsou decentralizovane´, • protokol SIP (Session Initiation Protocol), ktery´ se pouzˇ´ıva´ naprˇ´ıklad u VoIP (obecneˇ kdekoliv, kde je nutne´ navazovat relace). Samotny´ Internet byl pu˚vodneˇ decentralizovany´ a do znacˇne´ mı´ry to platı´ i dnes. Ale plna´ decentralizovanost by znamenala zachova´nı´ beˇzˇne´ho chodu syste´mu (trˇeba i s urcˇity´m zpomalenı´m nebo neposkytova´nı´m neˇktery´ch sluzˇeb, ktere´ mohou „pocˇkat“, nejsou cˇasoveˇ kriticke´) i po odpojenı´ naproste´ veˇtsˇiny serverovy´ch uzlu˚, cozˇ Internet nesplnˇuje. Distribuovany´ syste´m (zna´me z prˇedmeˇtu Operacˇnı´ syste´my) je takovy´ syste´m, jehozˇ funkce jsou distribuova´ny (rozdeˇleny) na ru˚zne´ uzly sı´teˇ se zachova´nı´m neˇkolika du˚lezˇity´ch vlastnostı´. Prˇedevsˇ´ım jde o vlastnost transparentnost. Naprˇ´ıklad prˇ´ıstupova´ transparentnost znamena´, zˇe k loka´lnı´m i vzda´leny´m prostrˇedku˚m se prˇistupuje stejny´m zpu˚sobem, zde prˇes protokoly. Migracˇnı´ transparentnost znamena´ mozˇnost prˇesouva´nı´ poskytovany´ch sluzˇeb mezi ru˚zny´mi uzly sı´teˇ bez vy´razneˇjsˇ´ıho vlivu na vy´konnost sı´teˇ.
P
Dalsˇ´ı du˚lezˇitou vlastnostı´ distribuovane´ho syste´mu je flexibilita. Tato vlastnost znamena´ prˇizpu˚sobivost syste´mu zmeˇna´m prostrˇedı´ (vcˇetneˇ poruch a vy´padku˚ cˇa´stı´ syste´mu). To vylucˇuje jakoukoliv centralizaci rozhodova´nı´, kazˇdy´ uzel sı´teˇ musı´ by´t ve sve´ cˇinnosti co nejvı´c samostatny´ a sluzˇby ostatnı´ch uzlu˚ vyzˇaduje se zachova´nı´m transparentnosti. Flexibilnı´ syste´m mu˚zˇe by´t jakkoliv rozsˇirˇova´n (te´meˇrˇ – jsou technicke´ hranice, ktere´ se jen velmi nesnadno prˇekracˇujı´) nebo naopak omezova´n, funkce odstranˇovane´ho uzlu mu˚zˇe plnit jiny´ uzel. S distribuovanostı´ se setka´va´me u neˇktery´ch smeˇrovacı´ch protokolu˚ a da´le naprˇ´ıklad v syste´mu DNS (obecneˇ u dome´novy´ch sluzˇeb).
7.1.2
Distribuovane´ syste´my
Distribuovany´ syste´m mu˚zˇe by´t urcˇen architekturou klient-server, kdy je jednoznacˇneˇ urcˇeno, ktere´ uzly jsou serverove´ (poskytujı´ sluzˇby, implementujı´ funkce) a ktere´ jsou klientske´ (vyuzˇ´ıvajı´ sluzˇeb serveru˚). Jiny´ zpu˚sob zavedenı´ distribuovane´ho syste´mu je integrovana´ architektura (symetricky´ syste´m), kde kazˇdy´ uzel mu˚zˇe by´t serverem i klientem, podle pozˇadavku˚ probı´hajı´cı´ komunikace. Podle zpu˚sobu vyuzˇ´ıva´nı´ pameˇti mu˚zˇeme distribuovane´ syste´my rozdeˇlit na • multiprocesory (multiprocessors) – uzly majı´ spolecˇnou pameˇt’(kazˇdy´ ma´ svou vlastnı´ pameˇt’ a da´le existuje pameˇt’sdı´lena´, ktera´ mu˚zˇe by´t take´ distribuova´na ve vı´ce uzlech), • multipocˇ´ıtacˇe (multicomputers) – uzly nesdı´lejı´ zˇa´dnou pameˇt’, adresove´ prostory jsou zcela oddeˇlene´, tento koncept je u pocˇ´ıtacˇovy´ch sı´tı´ obecneˇ vy´hodneˇjsˇ´ı. Podle zpu˚sobu propojenı´ (platı´ pro oba vy´sˇe zmı´neˇne´ typy) rozlisˇujeme dva typy architektur:
7.2
BRIDGING
146
• sbeˇrnicova´ architektura (bus) – vyuzˇ´ıva´ jedine´ sdı´lene´ me´dium (obvykle kabel), signa´l se sˇ´ırˇ´ı po cele´m me´diu, naprˇ´ıklad kabelova´ televize, • prˇepı´nacˇova´ architektura (switch) – signa´l je prˇena´sˇen vzˇdy mezi dveˇma konkre´tnı´mi uzly (azˇ na vy´jimky jako je broadcast a multicast), mu˚zˇe jı´t o ru˚zne´ topologie: – hierarchicka´ stromova´ struktura, mesh (varianty), kruh, atd., – mrˇ´ızˇka – uzel je propojen se svy´mi nejblizˇsˇ´ımi sousedy, prˇi idea´lnı´m usporˇa´da´nı´ jsou ke kazˇde´mu uzlu kromeˇ okrajovy´ch 4 sousednı´ uzly, – hyperkrychle. Hyperkrychle je n-rozmeˇrna´ krychle (v obvykle´m prˇ´ıpadeˇ je n = 4) s uzly usporˇa´dany´mi do vı´ce rozmeˇru˚ (vı´ceme´neˇ hierarchicky do liniı´, rovin, skupin, atd.). Uzel je prˇ´ımo propojen se dveˇma uzly pro kazˇdy´ podporovany´ rozmeˇr, tedy je prˇ´ımo propojen s celkem n ∗ 2 sousedy (u cˇtyrˇrozmeˇrne´ krychle s 8 sousedy). Cela´ struktura je z principu acyklicka´. Mrˇ´ızˇku lze bra´t jako specia´lnı´ prˇ´ıpad (hyper)krychle pro n = 2. Se sbeˇrnicovou architekturou se uzˇ v distribuovany´ch sı´tı´ch moc nesetka´va´me (azˇ na prˇenosy probı´hajı´cı´ po koaxia´lu). V praxi je zrˇejmeˇ nejbeˇzˇneˇjsˇ´ı propojenı´ multipocˇ´ıtacˇu˚ v hierarchicke´ strukturˇe. Mu˚zˇe dojı´t trochu ke „zmatenı´ pojmu˚“, protozˇe v prˇepı´nacˇove´ architekturˇe nemusı´me jako mezilehle´ prvky nutneˇ pouzˇ´ıvat prˇepı´nacˇe.
7.2 7.2.1
Bridging Most
Most (bridge) je zarˇ´ızenı´ (dnes spı´sˇe jedna z funkcı´ komplexneˇjsˇ´ıho zarˇ´ızenı´), ktere´ pracuje na linkove´ vrstveˇ (L2) podle modelu ISO/OSI. Jeho u´cˇelem je propojova´nı´ segmentu˚ sı´teˇ a filtrace PDU podle informacı´ dostupny´ch na linkove´ vrstveˇ, cozˇ je naprˇ´ıklad u loka´lnı´ch sı´tı´ MAC adresa (tedy PDU pustı´ jen na ten port, jehozˇ MAC adresa patrˇ´ı do dane´ho segmentu). Non-unicast komunikace (multicast a broadcast) je posla´na na vsˇechny porty a tote´zˇ platı´ o nezna´me´ unicast adrese. Dalsˇ´ım du˚lezˇity´m u´kolem je odfiltrova´nı´ posˇkozeny´ch PDU. Rozlisˇujeme dva za´kladnı´ typy pouzˇ´ıva´nı´ mostu˚: • transparent bridging (transparentnı´ prˇemosteˇnı´) – jedna´ se o „samoucˇ´ıcı´ “ mosty, ktere´ si postupneˇ za provozu ve sve´ pameˇti tvorˇ´ı tabulku adres vrstvy L2 (podle zdrojovy´ch adres v PDU) a podle te´to tabulky pak urcˇujı´ segment sı´teˇ pro danou cı´lovou adresu vrstvy L2, • source-route bridging (prˇemosteˇnı´ na cestu k cı´li) – soucˇa´stı´ PDU je seznam mostu˚ (prˇesneˇji mezilehly´ch prvku˚ sı´teˇ, ktere´ mohou slouzˇit jako mosty), prˇes ktere´ ma´ cesta ve´st, tedy cela´ cesta je prˇedem napla´nova´na. Prvnı´ typ se typicky pouzˇ´ıva´ prˇedevsˇ´ım u Ethernetu, druhy´ typ u Token Ring. Existujı´ zarˇ´ızenı´ kombinujı´cı´ oba principy, pak mohou slouzˇit k propojenı´ dvou loka´lnı´ch sı´tı´, z nichzˇ kazˇda´ je postavena na jine´m standardu (heterogennı´ sı´t’; naopak homogennı´ sı´t’ je postavena
P
7.2
BRIDGING
147
na spolecˇne´m standardu, naprˇ´ıklad Ethernet). V heterogennı´ch sı´tı´ch se vyuzˇ´ıva´ prˇedevsˇ´ım toho, zˇe most mu˚zˇe „videˇt“ i na podvrstvu LLC, ktera´ neby´va´ soucˇa´stı´ specifikace Ethernetu ani jine´ LAN. Da´le se budeme veˇnovat transparentnı´m mostu˚m. Kazˇdy´ most tedy udrzˇuje tabulku MAC adres (v syste´mu CatOS je nazy´va´na tabulkou CAM – Content Addresable Memory, jinde je to prosteˇ tabulka MAC adres). Za´znamy v tabulce majı´ jednoduchou formu – adresa L2 + port vedoucı´ k uzlu s touto adresou, komunikace urcˇena´ konkre´tnı´ MAC adrese je posı´la´na jen na port k nı´ vedoucı´.
P
Mosty mohou pracovat v loka´lnı´ sı´ti a propojovat jejı´ segmenty, ale mu˚zˇe jı´t take´ o propojenı´ vzda´leny´ch sı´tı´ (at’uzˇ homogennı´ch nebo heterogennı´ch) prˇes pa´terˇnı´ sı´t’(WAN).
7.2.2
STP
Mosty sice oddeˇlujı´ koliznı´ dome´ny, ale, jak bylo vy´sˇe uvedeno, propousˇteˇjı´ non-unicast komunikaci na vsˇechny porty. Jestlizˇe v sı´ti existuje smycˇka, mu˚zˇe dojı´t k vsˇesmeˇrove´ bourˇi (broadcast storm) a PDU „bloudı´“ porˇa´d dokola mezi ru˚zny´mi segmenty sı´teˇ. Du˚sledkem mu˚zˇe by´t zahlcenı´, cˇemuzˇ je trˇeba prˇedejı´t.
P
Jiny´m proble´mem v sı´ti se smycˇkami jsou nespra´vne´ aktualizace tabulky L2 adres. Podı´vejme se na obra´zek 7.1. Pokud stanice vysˇle broadcast ra´mec, je jejı´ adresa uvedena jako zdrojova´. Protozˇe tento ra´mec bloudı´ v cyklu, most A nejdrˇ´ıv spra´vneˇ urcˇ´ı port k te´to stanici, ale kdyzˇ pozdeˇji tenty´zˇ ra´mec (se stejnou zdrojovou adresou) prˇijde od mostu B, bude prˇedpokla´dat, zˇe stanice byla prˇemı´steˇna a cesta k nı´ vede prˇes most B. Stanice
Most B
Most A
Stanice
Most C
Most A
Most B
Most C
Obra´zek 7.1: Sı´t’s mosty bez pouzˇitı´ STP a s pouzˇitı´m STP STP (Spanning Tree Protocol – protokol kostry, IEEE 802.1D) umozˇnˇuje vytvorˇit a udrzˇovat sı´t’ bez smycˇek. Mechanismus nenı´ urcˇen jen pro mosty, ale obecneˇ pro vsˇechna zarˇ´ızenı´ podporujı´cı´ funkci mostu (v praxi se nejcˇasteˇji setka´me s prˇepı´nacˇi podporujı´cı´mi STP). Sı´t’mostu˚ udrzˇovana´ protokolem STP ma´ formu stromu s jediny´m korˇenem. STP detekuje smycˇky v sı´ti a odstranˇuje je blokova´nı´m neˇktery´ch portu˚ v mostech, mezi jaky´mikoliv dveˇma mosty (a obecneˇ take´ uzly) v sı´ti existuje vzˇdy pra´veˇ jedna cesta. Kazˇdy´ most v sı´ti ma´ prˇirˇazen svu˚j identifika´tor ovlivnˇujı´cı´ pozici mostu ve stromove´ strukturˇe, ktery´ se skla´da´ z priority (2 oktety, standardneˇ 0×8000, decima´lneˇ 32 768) a MAC adresy mostu. Priorita je vlevo od adresy, a tedy jejı´ hodnota ma´ hlavnı´ vliv na cˇ´ıselnou hodnotu cele´ho ID. Priorita proto ovlivnˇuje pozici mostu ve stromove´ strukturˇe (samozrˇejmeˇ vcˇetneˇ fyzicke´ho propojenı´), ale pokud na vsˇech mostech necha´me prˇednastavenou standardnı´ prioritu 0×8000, mosty jsou trˇ´ıdeˇny podle MAC adresy.
P P
7.2
BRIDGING
148
Kazˇdy´ most v sı´ti, ktery´ podporuje STP, vysı´la´ v pravidelny´ch intervalech – 2 sekundy – ra´mce oznacˇovane´ BPDU (Bridge PDU). Tyto ra´mce slouzˇ´ı k udrzˇova´nı´ a prˇ´ıpadneˇ aktualizaci stromove´ struktury mostu˚. Soucˇa´stı´ BPDU je kromeˇ jine´ho ID korˇenove´ho mostu a ID vysı´lajı´cı´ho mostu. STP postupneˇ vybere korˇenovy´ most (root), cozˇ je most s nejvysˇsˇ´ı prioritou. Dalsˇ´ı mosty rˇadı´ pod korˇenovy´ most do stromove´ struktury podle fyzicke´ho propojenı´ mezi nimi. Dı´ky stromove´ strukturˇe existuje mezi ktery´mikoliv dveˇma mosty pra´veˇ jedna cesta. Pokud pu˚vodneˇ mezi dveˇma mosty existovalo vı´ce paralelnı´ch cest, pouze jedna z nich bude vybra´na a vsˇechny ostatnı´ budou uzavrˇeny (prˇ´ıslusˇne´ porty se blokujı´).
P P
Na obra´zku 7.1 ma´me rˇesˇenı´ pro jednoduchou sı´t’ se trˇemi mosty. Most A byl vybra´n jako korˇenovy´. Prˇi vy´beˇru vhodne´ cesty ke korˇenove´mu uzlu z vı´ce ru˚zny´ch cest se zohlednˇuje „cena“ cesty, jejı´ (ne)vy´hodnost. Cena cesty je urcˇena prˇicˇtenı´m priorit vsˇech mostu˚ na cesteˇ ra´mce BPDU k za´kladnı´ ceneˇ cesty a platı´, zˇe cˇ´ım nizˇsˇ´ı cena, tı´m lepsˇ´ı cesta. Du˚sledkem je prˇednost takove´ cesty, ktera´ obsahuje co nejme´neˇ mostu˚ a nejru˚zneˇjsˇ´ıch „oklik“. Zarˇazenı´ mostu do STP stromu. Obvykle platı´, zˇe most podporujı´cı´ STP hned po sve´ aktivaci sa´m sebe povazˇuje za korˇenovy´ most. Pokud vsˇak obdrzˇ´ı BPDU s ID korˇenove´ho mostu vysˇsˇ´ım nezˇ je jeho, zarˇadı´ se nı´zˇe do stromove´ struktury (take´ podle ID mostu, ktery´ tento BPDU poslal). Pokud chceme ovlivnit konkre´tnı´ pozici mostu v STP sı´ti, meˇli bychom podle toho nakonfigurovat priority (prˇedevsˇ´ım mostu, ktery´ chceme mı´t jako korˇenovy´). Jestlizˇe nasta´vajı´ s STP proble´my, by´va´ to obvykle pra´veˇ z du˚vodu sˇpatne´ (nebo i zˇa´dne´) konfigurace priorit mostu˚. Pro kazˇdy´ most je prˇedevsˇ´ım du˚lezˇita´ cesta ke korˇenove´mu mostu. Port, ktery´ vede ke korˇenove´mu mostu a za´rovenˇ urcˇuje nejkratsˇ´ı cestu (s nejnizˇsˇ´ı cenou) ke korˇenove´mu mostu, se nazy´va´ korˇenovy´ port. Ostatnı´ porty vedoucı´ ke korˇenove´mu mostu prˇedstavujı´ alternativnı´ cesty a musejı´ by´t proto blokova´ny. Stavy portu ˚. Norma´lnı´m stavem portu je stav prˇeda´va´nı´ (forwarding), kdy port zpracova´va´ beˇzˇny´ provoz, BPDU ra´mce i pozˇadavky spra´vy sı´teˇ. Jine´ stavy jsou inicializace, nasloucha´nı´ (listening, BPDU jsou prˇijı´ma´ny i odesı´la´ny, ale beˇzˇny´ provoz jesˇteˇ ne), zjisˇt’ova´nı´ (learning, vytva´rˇ´ı se tabulka MAC adres, BPDU jsou prˇijı´ma´ny i odesı´la´ny, beˇzˇny´ provoz nenı´ odesı´la´n), blokova´nı´ a zaka´zany´ port. Blokovany´ port nenı´ ve skutecˇnosti vypnuty´ (naprˇ´ıklad prˇijı´ma´ BPDU a funguje take´ z hlediska spra´vy sı´teˇ), ale nesmı´ prˇeda´vat beˇzˇny´ provoz. Mohou existovat take´ zaka´zane´ porty (disabled), ktere´ reagujı´ pouze na pozˇadavky spra´vy sı´teˇ. RSTP (Rapid STP, pu˚vodneˇ IEEE 802.1w) je vylepsˇenı´m protokolu STP prˇedevsˇ´ım v rychlosti rekonfigurace (tj. zmeˇny stromu prˇi zmeˇneˇ topologie sı´teˇ mostu˚ cˇi prˇepı´nacˇu˚ s podporou tohoto protokolu). Zrychlenı´ je znacˇne´, protozˇe sı´t’ s protokolem STP se rekonfiguruje (tj. konverguje) v pru˚meˇru za 30–50 s, prˇi pouzˇitı´ RSTP jde o neˇkolik sekund, mu˚zˇe i pod 1 s. Du˚vodu˚ zrychlenı´ je vı´ce, naprˇ´ıklad zatı´mco u STP je proces rekonfigurace vı´ceme´neˇ pasivnı´ (BPDU se posı´lajı´ pouze ve stanoveny´ch intervalech a rekonfigurace se „vlecˇe“ po jednotlivy´ch mostech), u RSTP mosty (spı´sˇe prˇepı´nacˇe) aktivneˇ spolupracujı´ na rekonfiguraci sı´teˇ (negociace, spolupra´ce s okolnı´mi zarˇ´ızenı´mi), prˇi zjisˇteˇnı´ otevrˇenı´ dalsˇ´ıho portu k sousedovi automaticky zapnou forwarding.
$
P P
7.3
SWITCHING
149
V noveˇjsˇ´ıch zarˇ´ızenı´ch se uzˇ obvykle nesetka´me s pu˚vodnı´m pomalejsˇ´ım STP, ale spı´sˇe s RSTP nebo jinou variantou. Standard RSTP (IEEE 802.1w) byl prˇida´n do IEEE 802.1D (cozˇ byl pu˚vodneˇ STP). MSTP (Multiple STP, take´ MST nebo MIST, IEEE 802.1s) je vylepsˇenı´ protokolu STP pro pouzˇitı´ v prostrˇedı´ s VLAN (virtua´lnı´ sı´tı´, viz da´le) a pro prˇ´ıpad vyuzˇitı´ za´lozˇnı´ch linek. Pracuje nad RSTP, tedy je dostatecˇneˇ rychly´. A B C
A B C
A B C
P
A B C
A B C
A B C
Obra´zek 7.2: Porovna´nı´ protokolu˚ STP a MSTP Pokud bychom v prostrˇedı´ s virtua´lnı´mi sı´teˇmi pouzˇili pouze STP, pravdeˇpodobneˇ bychom neˇktere´ VLAN prakticky vyrˇadili z cˇinnosti nebo bychom neˇktere´ z linek zbytecˇneˇ zatı´zˇili prˇ´ılisˇ. A B
A B
A B C
A B C
A B C
A B C
Obra´zek 7.3: Prˇerusˇena´ cesta pro jednu VLAN prˇi pouzˇitı´ STP MSTP umozˇnˇuje pouzˇ´ıt jednotlive´ instance spanning tree pro kazˇdou VLAN nebo neˇkolik VLAN zvla´sˇt’. Soucˇa´stı´ nastavenı´ MSTP je prˇirˇazenı´ jednotlivy´ch VLAN k definovany´m instancı´m. Toto je zrˇejmeˇ nejna´rocˇneˇjsˇ´ı cˇa´st konfigurace, meˇli bychom mı´t prˇehled (samozrˇejmeˇ) o tom, na ktery´ch portech ktere´ VLAN komunikujı´ a take´ pokud mozˇno o prˇedpokla´dane´m provozu mezi zarˇ´ızenı´mi v ra´mci jednotlivy´ch VLAN. Na obra´zku 7.2 je sı´t’se trˇemi VLAN (zde pojmenovany´mi A, B a C). Prˇi pouzˇitı´ protokolu STP by VLAN byla funkcˇnı´, ale pokud prˇedpokla´da´me vysˇsˇ´ı za´teˇzˇ prˇi komunikaci v trˇetı´ VLAN, je mnohem lepsˇ´ı vytvorˇit dveˇ instance protokolu, jednu pro VLAN A a B, druhou pro VLAN C. Dalsˇı´ 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
Prˇepı´nacˇ (switch) mu˚zˇeme bra´t jako most, ktery´ ma´ vı´ce nezˇ dva porty, navı´c prˇepı´nacˇe mohou podporovat virtua´lnı´ loka´lnı´ sı´teˇ (VLAN). Prˇepı´nacˇe take´ pracujı´ na vrstveˇ L2 (nebo i vysˇsˇ´ıch vrstva´ch). Rozlisˇujeme vı´ce typu˚ prˇepı´nacˇu˚: • ethernetovy´ prˇepı´nacˇ – pracuje v sı´tı´ch Ethernet (IEEE 802.3), a to na vrstveˇ L2, slouzˇ´ı k oddeˇlenı´ koliznı´ch dome´n a je nezbytnou podmı´nkou implementace plne´ho duplexu, • prˇepı´nacˇ vrstvy 3 (L3) – prˇepı´nacˇ umozˇnˇujı´cı´ smeˇrova´nı´, v soucˇasne´ dobeˇ se spı´sˇe setka´me se zarˇ´ızenı´mi z na´sledujı´cı´ skupiny plnı´cı´mi take´ roli prˇepı´nacˇe L3, • vı´cevrstvy´ prˇepı´nacˇ – pracuje na vı´ce vrstva´ch, obecneˇ L2, L3 a da´le alesponˇ L4 (rˇ´ıdı´ provoz take´ podle informacı´ v za´hlavı´ch TCP a UDP paketu˚, prˇ´ıpadneˇ i PDU vysˇsˇ´ıch vrstev), • prˇepı´nacˇ neˇktere´ WAN nebo MAN sı´teˇ (naprˇ´ıklad sı´teˇ Frame-Relay). Loka´lnı´ prˇepı´nacˇe narozdı´l od mostu˚ obvykle propojujı´ pouze homogennı´ sı´teˇ, nanejvy´sˇ se odlisˇujı´ ru˚zny´mi rychlostmi (naprˇ´ıklad Fast Ethernet a 1G Ethernet). Typy prˇepı´na´nı´: 1. Store and Forward (ulozˇ a posˇli) – prˇ´ıchozı´ ra´mec je nejdrˇ´ıv cely´ prˇijat a ulozˇen do vyrovna´vacı´ pameˇti prˇepı´nacˇe, azˇ po prˇijetı´ cele´ho ra´mce je prˇecˇteno za´hlavı´ a urcˇen vy´stupnı´ port pro odesla´nı´ ra´mce. Doka´zˇe odchyta´vat chybne´ ra´mce, ale velmi pomaly´, vhodne´ pro sı´teˇ s vysˇsˇ´ı chybovostı´.
P
2. Cut-Through (pru˚beˇzˇne´ zpracova´nı´, take´ on-the-fly) – prˇ´ıchozı´ ra´mec se zacˇ´ına´ odesı´lat pru˚beˇzˇneˇ jesˇteˇ beˇhem sve´ho prˇ´ıjmu, hned po nacˇtenı´ informacı´ ze za´hlavı´ potrˇebny´ch k urcˇenı´ vy´stupnı´ho portu. Velmi rychle´ prˇepı´na´nı´, mensˇ´ı potrˇeba cache, ale nedoka´zˇe odchyta´vat chybne´ ra´mce. 3. Fragment Free (s omezenı´m maly´ch ra´mcu˚) – neˇco mezi prvnı´mi dveˇma metodami. Zpraco´ cˇelem va´va´nı´ ra´mce zacˇne po nacˇtenı´ jeho prvnı´ch 64 oktetu˚ (tj. za´hlavı´ a alesponˇ cˇa´st dat). U je odhalenı´ alesponˇ jednoho typu chybny´ch ra´mcu˚, nepovoleny´ch prˇ´ılisˇ kra´tky´ch ra´mcu˚. Jak bylo vy´sˇe rˇecˇeno, prˇepı´nacˇe obvykle podporujı´ VLAN. V tabulce MAC adres obvykle najdeme k cesteˇ do konkre´tnı´ho uzlu tyto u´daje: • • • • •
cˇ´ıslo VLAN, do ktere´ patrˇ´ı, MAC adresa, u´daj, zda byla adresa do tabulky prˇida´na dynamicky nebo rucˇneˇ (staticka´), pocˇet sekund od zarˇazenı´ adresy do tabulky (prˇ´ıp. od poslednı´ zmeˇny tohoto za´znamu), oznacˇenı´ portu, na ktery´ se ma´ ra´mec s touto adresou jako cı´lovou odeslat.
7.4
Routing
7.4.1
Smeˇrovacˇ
Zatı´mco prˇepı´nacˇe pracujı´ v adresami ploche´ho (flat) adresove´ho prostoru, smeˇrovacˇe (routery) pracujı´ s hierarchicky´mi adresami (obvykle IP) a majı´ vestaveˇnou logiku umozˇnˇujı´cı´ rozhodovat o pru˚beˇhu smeˇrova´nı´. Smeˇrovacˇ pracuje na vrstveˇ L3 (sı´t’ove´) v ISO/OSI modelu.
P
7.4
ROUTING
151
Take´ smeˇrovacˇ prova´dı´ vnitrˇnı´ prˇepı´na´nı´ (v trochu jine´m smyslu slova) PDU (obvykle IP datagramu), ale mezi smeˇrovacˇem a prˇepı´nacˇem jsou pomeˇrneˇ velke´ rozdı´ly: • smeˇrovacı´ tabulka obsahuje informace o dostupny´ch sı´tı´ch a podsı´tı´ch (pouzˇ´ıvajı´ se prefixy), nikoliv adresy konkre´tnı´ch uzlu˚, tedy smeˇrovacı´ tabulka je obecneˇ mensˇ´ı nezˇ tabulka MAC adres mostu cˇi prˇepı´nacˇe,
P
• v smeˇrovacı´ tabulce najdeme u kazˇde´ho za´znamu port, na ktery´ ma´ by´t PDU nasmeˇrova´n, a da´le metriku urcˇujı´cı´ na´rocˇnost (de´lku, cenu) cesty, • na vsˇeobecnou (broadcast) adresu reaguje smeˇrovacˇ prˇesneˇ opacˇneˇ nezˇ prˇepı´nacˇ – broadcast nepropustı´ na zˇa´dny´ port (obcˇas je nutne´ toto chova´nı´ obejı´t, ale na druhou stranu nenı´ nutne´ pouzˇ´ıvat protokoly typu STP), • stejneˇ reaguje na nezna´mou unicast adresu – nepustı´ ji na zˇa´dny´ port a datagram je bud’ znicˇen nebo nasmeˇrova´n k implicitnı´ sı´ti (sbeˇrna´ sı´t’), kde lze na prˇ´ıpadny´ zbloudily´ datagram reagovat. Smeˇrovacˇe se zajı´majı´ i o dalsˇ´ı informace ze za´hlavı´ paketu nezˇ jen o adresy. Prˇedevsˇ´ım je du˚lezˇite´ pole s hodnotou TTL (Time-to-Live), se ktery´m jsme se sezna´mili u protokolu IP. Smeˇrovacˇ snizˇuje hodnotu tohoto pole vzˇdy nejme´neˇ o 1, reakce prˇi nalezenı´ datagramu s TTL=0 je popsa´na v sekci o protokolu IP (je dorucˇen jen tehdy, kdyzˇ cı´lova´ sı´t’je prˇ´ımo prˇipojena k tomuto smeˇrovacˇi). Smeˇrovacˇ da´le kontroluje celkovou de´lku datagramu a kdyzˇ tato de´lka prˇekracˇuje velikost povolenou pro dany´ vy´stupnı´ port, datagram je fragmentova´n (pokud je to v za´hlavı´ IPv4 povoleno), IPv6 datagramy nelze fragmentovat. Smeˇrovacˇe navza´jem komunikujı´, navza´jem se informujı´ o momenta´lnı´ situaci v sı´ti a prˇ´ıpadny´ch zmeˇna´ch a proble´mech. Kazˇdy´ smeˇrovacˇ si udrzˇuje (ve sve´ smeˇrovacı´ tabulce) informaci o logicke´m usporˇa´da´nı´ sı´teˇ (topologii). Konvergence sı´teˇ je takovy´ stav sı´teˇ, kde vsˇechny smeˇrovacˇe majı´ stejnou prˇedstavu o topologii sı´teˇ. Pokud dojde k vy´padku neˇktere´ cesty v sı´ti vcˇetneˇ vy´padku neˇktere´ho smeˇrovacˇe, stav konvergence je porusˇen a smeˇrovacˇe se navza´jem informujı´ o potrˇebne´ aktualizaci smeˇrovacı´ch tabulek, cozˇ vede k opeˇtovne´mu prˇechodu do stavu konvergence. Na smeˇrovacˇ´ıch se mu˚zˇe pouzˇ´ıvat jednoducha´ metoda rˇ´ızenı´ propustnosti sı´teˇ nazvana´ Token Bucket. Pracuje na principu virtua´lnı´ho kosˇe (bucket), do ktere´ho jsou konstantnı´ rychlostı´ neusta´le doplnˇova´ny tokeny („povolenky“). Pokud prˇetecˇe, tokeny jsou zahazova´ny. Jeden token prˇedstavuje urcˇite´ mnozˇstvı´ odesı´lany´ch dat (trˇeba jeden oktet).
P P P
Velikost paketu, ktery´ ma´ by´t odesla´n, je porovna´na s mnozˇstvı´m odpovı´dajı´cı´ch tokenu˚ v Token Bucketu. Pokud dostacˇuje, odstranı´ se z Bucketu potrˇebne´ mnozˇstvı´ tokenu˚ a paket mu˚zˇe by´t odesla´n. Jestlizˇe vsˇak nedostacˇuje, paket bude zahozen.
7.4.2
Smeˇrova´nı´
Smeˇrovat lze bud’ staticky nebo dynamicky. Staticke´ smeˇrova´nı´ znamena´ urcˇenı´ cesty k dane´mu cı´li rucˇneˇ administra´torem, dynamicke´ smeˇrova´nı´ znamena´ vyuzˇitı´ smeˇrovacı´ho algoritmu k urcˇenı´ nejvhodneˇjsˇ´ı cesty k cı´li. Staticke´ smeˇrova´nı´ nevyzˇaduje pouzˇitı´ smeˇrovacı´ho algoritmu, proto je rychlejsˇ´ı, ale na druhou stranu prˇi zmeˇneˇ topologie sı´teˇ mu˚zˇe nastat situace, kdy nelze data dorucˇit a je nutne´ rucˇneˇ zmeˇnit u´daje v tabulka´ch. Staticke´ smeˇrova´nı´ se pouzˇ´ıva´ tam, kde tak jako tak existuje jedina´ cesta (point-to-point spoj, smeˇrovacı´ algoritmus by jen zdrzˇoval prˇenos) nebo tam, kde (trˇeba z bezpecˇnostnı´ch du˚vodu˚
P
7.4
ROUTING
152
nebo pro urychlenı´) administra´tor chce cestu urcˇit explicitneˇ. Staticke´ a dynamicke´ smeˇrova´nı´ lze kombinovat, kdy jedna z mozˇnostı´ slouzˇ´ı jako za´loha. Obvykle jsou u´daje ze staticke´ho smeˇrova´nı´ uprˇednostnˇova´ny jako du˚veˇryhodneˇjsˇ´ı, ale toto nastavenı´ lze na mnoha smeˇrovacˇ´ıch obra´tit. Prˇi dynamicke´m smeˇrova´nı´ se hleda´ nejoptima´lneˇjsˇ´ı cesta k cı´li (mu˚zˇe jı´t o suboptima´lnı´ cestu). Kazˇda´ cesta ma´ prˇirˇazenu metriku podle jednoho nebo vı´ce krite´riı´. Lze pouzˇ´ıt naprˇ´ıklad tato krite´ria:
P
• pocˇet smeˇrovacˇu˚ na cesteˇ (skoku˚, hop count) – nejlepsˇ´ı cesta obsahuje nejme´neˇ smeˇrovacˇu˚, • propustnost prˇenosove´ cesty (kb/s, Mb/s, apod.) – cˇ´ım rychleji lze data prˇene´st, tı´m je cesta lepsˇ´ı, • zpozˇdeˇnı´ (latence, v ms) – nejlepsˇ´ı cesta je ta, ktera´ znamena´ nejmensˇ´ı celkove´ zpozˇdeˇnı´, • spolehlivost (pravdeˇpodobnost dorucˇenı´ dat) – nejlepsˇ´ı cesta je ta, kde je nejvysˇsˇ´ı pravdeˇpodobnost dorucˇenı´ dat (bez chyb, bez cˇaste´ho zahazova´nı´ datovy´ch jednotek), • maxima´lnı´ de´lka prˇenosove´ jednotky (MTU) – nejlepsˇ´ı cesta je ta, kde lze prˇena´sˇet dostatecˇneˇ velke´ prˇenosove´ jednotky a nehrozı´ nutnost fragmentace na cesteˇ, • za´teˇzˇ – zohlednˇuje se momenta´lnı´ nebo beˇzˇne´ zatı´zˇenı´ dane´ho prˇenosove´ho prostrˇedku, ktere´ mu˚zˇe mı´t vliv na zpozˇdeˇnı´ dorucˇenı´. Metrika mu˚zˇe za´viset na vı´ce nezˇ jednom krite´riu. Nejen metrika je du˚lezˇita´ prˇi hodnocenı´ cesty. Velmi du˚lezˇity´m krite´riem je take´ zdroj smeˇrovacı´ informace, informace z du˚veˇryhodneˇjsˇ´ıho zdroje je uprˇednostneˇna, i kdyzˇ ma´ o neˇco horsˇ´ı metriku. Pu˚vodneˇ byly cesty ve smeˇrovacˇ´ıch popisova´ny adresou sı´teˇ a maskou podsı´teˇ. Soucˇasne´ smeˇrovacˇe majı´ cesty popsa´ny adresou sı´teˇ a de´lkou prefixu. Pokud v tabulce existujı´ dveˇ cesty k te´muzˇ cı´li, obvykle se uprˇednostnı´ ta, ktera´ ma´ veˇtsˇ´ı de´lku prefixu (tj. je prˇesneˇjsˇ´ı, most specific). Naprˇ´ıklad pokud ma´me u´daje 10.160.0.0/12 10.160.0.0/17 druhy´ u´daj bude uprˇednostneˇn. Jde o dva ru˚zne´ za´znamy, protozˇe se lisˇ´ı v de´lce prefixu, trˇebazˇe adresa v obou prˇ´ıpadech vypada´ jako stejna´. Druha´ adresa zrˇejmeˇ bude podsı´tı´ sı´teˇ urcˇene´ prvnı´ adresou (nebo hloubeˇji v hierarchii). Pokud ve smeˇrovacı´ tabulce nenı´ nalezena zˇa´dna´ cesta, je bud’ paket prˇeda´n bra´neˇ (geteway), protozˇe paket zrˇejmeˇ patrˇ´ı do jine´ sı´teˇ, nebo zahozen (kdyzˇ zˇa´dna´ bra´na nenı´ dostupna´).
7.4.3
$
Smeˇrovacı´ algoritmy a protokoly
Rozlisˇujeme protokoly smeˇrovatelne´ (routed) a smeˇrovacı´ (routing). Smeˇrovatelne´ protokoly (naprˇ´ıklad IP) pracujı´ na sı´t’ove´ vrstveˇ, ale vlastnı´ smeˇrova´nı´ neprova´deˇjı´, to je za´lezˇitostı´ smeˇrovacı´ch protokolu˚. Autonomnı´ syste´m (podle terminologie EIGRP) je skupina smeˇrovacˇu˚ spadajı´cı´ch pod stejnou spra´vu (firmy, organizace apod.). Jine´ protokoly mohou pouzˇ´ıvat jine´ na´zvoslovı´, naprˇ´ıklad u OSPF se nazy´va´ proces. Autonomnı´ syste´m je identifikova´n 16bitovy´m cˇ´ıslem ASN, proces zase PID.
P P
7.4
ROUTING
153
Smeˇrovacı´ protokoly pracujı´cı´ vzˇdy jen uvnitrˇ jednoho autonomnı´ho syste´mu se nazy´vajı´ vnitrˇnı´ smeˇrovacı´ protokoly (interior, internal), smeˇrovacı´ protokoly slouzˇ´ıcı´ ke smeˇrova´nı´ mezi ru˚zny´mi autonomnı´mi syste´my (a tedy mezi ru˚zny´mi vnitrˇnı´mi smeˇrovacı´mi protokoly) jsou vneˇjsˇ´ı smeˇrovacı´ protokoly (exterior, external).
P
Smeˇrovacˇe mohou pracovat jen s jednı´m smeˇrovacı´m protokolem, ale existujı´ take´ multiprotokolove´ smeˇrovacˇe, ktere´ komunikujı´ s vı´ce ru˚zny´mi smeˇrovacı´mi protokoly. Pro kazˇdy´ podporovany´ smeˇrovacı´ protokol existuje (nejme´neˇ) jedna smeˇrovacı´ tabulka a v kazˇde´ by´va´ pro pozˇadovanou cestu uvedena metrika.
P
V jednoprotokolove´m smeˇrovacˇi se smeˇrova´nı´ rˇ´ıdı´ metrikami cest v (jedne´) smeˇrovacı´ tabulce. V multiprotokolove´m smeˇrovacˇi je trˇeba navı´c rozhodnout mezi cestami v ru˚zny´ch tabulka´ch, ktere´ jsou vytva´rˇeny podle ru˚zny´ch krite´riı´ a tedy tak jak jsou, neby´vajı´ navza´jem porovnatelne´. Z toho du˚vodu byla pro kazˇdy´ protokol stanovena prˇepocˇ´ıtavacı´ konstanta nazvana´ administrativnı´ vzda´lenost (administrative distance) umozˇnˇujı´cı´ porovnat vı´ce cest k te´muzˇ cı´li ze smeˇrovacı´ch tabulek ru˚zny´ch protokolu˚. Administrativnı´ vzda´lenosti jsou v tabulce 7.1. Vsˇimneˇte si rozdı´lu˚ u protokolu˚, ktere´ mohou pracovat jako vnitrˇnı´ i vneˇjsˇ´ı (naprˇ´ıklad BGP). Typ cesty
P
Administrativnı´ vzda´lenost
Prˇipojene´ rozhranı´ Staticke´ smeˇrova´nı´ EIGRP summary route (souhrnne´ cesty pro skupinu sı´tı´) External BGP Internal EIGRP IGRP OSPF IS-IS RIP EGP ODR (On Demand Routing) External EIGRP Internal BGP jiny´ (nezna´my´)
0 1 5 20 90 100 110 115 120 140 160 170 200 255
Tabulka 7.1: Administrativnı´ vzda´lenosti smeˇrovacı´ch protokolu˚ Cesta zjisˇteˇna´ v ra´mci beˇzˇne´ho smeˇrova´nı´ je internı´, cesta zjisˇteˇna´ vneˇ smeˇrovacı´ho procesu (z jine´ autonomnı´ oblasti) je externı´. Veˇtsˇina protokolu˚ uprˇednostnˇuje internı´ cesty (tj. vyuzˇ´ıvajı´ administrativnı´ vzda´lenost), ale naprˇ´ıklad u BGP je to naopak a jine´ jejich spolehlivost nerozlisˇujı´ (naprˇ´ıklad OSPF). Smeˇrovacı´ algoritmy jsou algoritmy pouzˇ´ıvane´ prˇi rˇ´ızenı´ smeˇrova´nı´. Mu˚zˇeme je rozdeˇlit do dvou skupin: • algoritmus vektoru˚ vzda´lenostı´ (distance vector), • algoritmus stavu spoje (link state).
P
7.4
ROUTING
154
Algoritmus vektoru ˚ vzda´lenostı´. Smeˇrovacˇ ma´ nejdrˇ´ıv ve sve´ tabulce pouze u´daje o prˇ´ımo prˇipojeny´ch sı´tı´ch (ty majı´ metriku 0) a postupneˇ prˇida´va´ u´daje podle zpra´v od sousednı´ch smeˇrovacˇu˚. Ve zpra´va´ch od sousedu˚ jsou seznamy vektoru˚ „(cı´l, vzda´lenost)“, kde prvnı´ u´daj je adresa dosazˇitelne´ho cı´le a druhy´ u´daj je vzda´lenost (metrika). Algoritmus zveˇtsˇ´ı vzda´lenosti o stanovenou konstantu, veˇtsˇinou o 1 (to znamena´ o vzda´lenost k sousedovi, ktery´ zpra´vu poslal), a porovna´ s u´daji, ktere´ uzˇ v tabulce ma´. Nove´ za´znamy prˇida´, a pokud uzˇ dany´ cı´l v jeho tabulce existuje, porovna´ metriky a prˇ´ıpadneˇ dalsˇ´ı u´daje a rozhodne, zda smeˇrovacı´ informaci o tomto cı´li zmeˇnı´. Tyto zpra´vy si smeˇrovacˇe vymeˇnˇujı´ v pravidelny´ch intervalech (obvykle 30–90 s) formou broadcastu nebo multicastu a posı´la´ se vzˇdy cela´ smeˇrovacı´ tabulka (vzˇdy jen mezi sousedy). To znamena´ veˇtsˇ´ı za´teˇzˇ sı´teˇ, ale zato jednodusˇsˇ´ı pocˇa´tecˇnı´ konfiguraci (administra´tor prˇida´va´ pouze za´znamy o prˇ´ımo prˇipojeny´ch sı´tı´ch). Pro tento algoritmus je typicke´, zˇe smeˇrovacˇe nemajı´ prˇehled o cele´ topologii sı´teˇ, znajı´ jen sve´ sousedy. Podle informacı´ od svy´ch sousedu˚ urcˇujı´, na ktery´ port odeslat pakety pro dany´ cı´l. Jednou z nevy´hod z toho plynoucı´ch je na´chylnost k zacyklenı´ paketu˚ zejme´na v prˇ´ıpadeˇ nedostupnosti cı´le (neˇktere´ smeˇrovacˇe majı´ chybne´ informace a prˇeda´vajı´ je da´le). Tento proble´m se obvykle rˇesˇ´ı omezenı´m de´lky cesty (TTL, obvykle 15 nebo 255) a pak dalsˇ´ımi postupy, ktere´ jsou soucˇa´stı´ smeˇrovacı´ho algoritmu. Naprˇ´ıklad pokud smeˇrovacˇ obdrzˇ´ı informaci o nedostupnosti sı´teˇ, pak po stanovenou dobu (hold-down timer, veˇtsˇinou trojna´sobek intervalu zası´la´nı´ zpra´v sousedu˚m) ignoruje zpra´vy o cesteˇ do te´to sı´teˇ, povazˇuje je za potencia´lneˇ chybne´. Poison reverse (otra´venı´ cesty zpeˇt) je ozna´menı´ smeˇrovacˇe o sve´ nedostupnosti. Tento smeˇrovacˇ odesˇle svy´m sousedu˚m aktualizaci cesty k sobeˇ s hodnotou metriky max(T T L) a sousedi si k tomu jesˇteˇ prˇicˇtou 1, tj. naprˇ´ıklad u RIPv1 to bude hodnota 16 nebo u jiny´ch protokolu˚ hodnota 256. Metrika veˇtsˇ´ı nezˇ maxima´lnı´ stanovena´ oznacˇuje „nedosazˇitelnou“ cestu a tedy na port k odpojovane´mu smeˇrovacˇi nebudou zası´la´ny zˇa´dne´ pakety.
P
P P
Dalsˇ´ı mozˇnost je postup split horizon (rozlozˇeny´ horizont). Smeˇrovacˇ neodesı´la´ jine´mu smeˇrovacˇi celou svou tabulku, ale jen ty za´znamy, ktere´ nevedou k tomuto smeˇrovacˇi (nenı´ trˇeba informovat jiny´ smeˇrovacˇ o tom, o cˇem pu˚vodneˇ informoval on). Takto se snizˇuje nebezpecˇ´ı zacyklenı´ a zası´la´nı´ chybny´ch informacı´. Protokoly vyuzˇ´ıvajı´cı´ algoritmus vektoru˚ vzda´lenostı´: • RIP (Routing Information Protocol) varianty pro IP, IPX, atd. • IGRP (Interior Gateway Protocol) pro IP ´ cˇelem je co nejrychlejsˇ´ı konvergence, aby vsˇechny smeˇrovacˇe meˇly Algoritmus stavu spoje. U vzˇdy co nejaktua´lneˇjsˇ´ı informace. K aktualizacı´m smeˇrovacı´ch tabulek nedocha´zı´ v pravidelny´ch intervalech, ale vzˇdy po jake´koliv zmeˇneˇ v topologii sı´teˇ. Kazˇdy´ smeˇrovacˇ pravidelneˇ testuje stav spojenı´ k sousednı´m smeˇrovacˇu˚m (pakety LSP – Link State Packet) a pokud zjistı´ nedostupnost sve´ho souseda, prˇeda´ tuto informaci da´le (nejen svy´m sousedu˚m, ale vsˇem dostupny´m smeˇrovacˇu˚m, na skupinovou adresu skupiny smeˇrovacˇu˚ pouzˇ´ıvajı´cı´ch dany´ protokol). Smeˇrovacˇ po sve´m zapnutı´ nejdrˇ´ıv analyzuje informace, ktere´ obdrzˇ´ı, a buduje si mapu sı´teˇ – topologickou databa´zi. Pak spustı´ vy´pocˇet nejkratsˇ´ı cesty do ru˚zny´ch cı´lu˚ modifikovany´m Dijkstrovy´m algoritmem Shortest-Path-First (SPF), vy´pocˇet probı´ha´ prˇi kazˇde´ zmeˇneˇ topologie sı´teˇ. Podle vy´sledku si vytvorˇ´ı smeˇrovacı´ tabulku.
P P
7.4
ROUTING
155
Vy´hodou tohoto typu algoritmu je nizˇsˇ´ı zatı´zˇenı´ sı´teˇ sluzˇebnı´mi informacemi a take´ velmi rychla´ konvergence sı´teˇ, nevy´hodou jsou vysˇsˇ´ı na´roky na smeˇrovacˇ. Popsane´ vy´hody jsou du˚lezˇite´ zejme´na ve veˇtsˇ´ıch sı´tı´ch. Protokoly vyuzˇ´ı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 nejstarsˇ´ıch smeˇrovacı´ch protokolu˚, byl vyvinut firmou Xerox r. 1981. Jedna´ se o vnitrˇnı´ smeˇrovacı´ protokol komunikujı´cı´ na portu 520 (vyuzˇ´ıva´ protokol UDP). Jako metrika se pouzˇ´ıva´ pocˇet smeˇrovacˇu˚ na cesteˇ k cı´li. Nejvysˇsˇ´ı akceptovana´ metrika u RIPv1 (verze 1) je 15, cˇ´ıslo 16 jizˇ oznacˇuje nedostupnou sı´t’. V intervalech 30 s je vsˇesmeˇroveˇ (broadcast) vysı´la´na smeˇrovacı´ informace, cozˇ ve velky´ch sı´tı´ch mu˚zˇe znacˇneˇ snizˇovat propustnost sı´teˇ. RIP je protokol vyuzˇ´ıvajı´cı´ trˇ´ıdy adres (nepodporuje beztrˇ´ıdnı´ smeˇrova´nı´), to znamena´, zˇe soucˇa´stı´ smeˇrovacı´ch informacı´ nenı´ maska podsı´teˇ ani de´lka prefixu. To je dalsˇ´ı nevy´hoda, ktera´ RIPv1 prakticky vylucˇuje z velky´ch sı´tı´.
P
L
Prˇı´klad Adresy sı´tı´ 10.10.22.0/24 10.20.10.0/24 by byly povazˇova´ny za stejnou sı´t’, protozˇe RIP smeˇrovacˇ by obeˇ adresy povazˇoval za adresu trˇ´ıdy A, kde je sı´t’urcˇena prvnı´m oktetem. Pokud k teˇmto sı´tı´m vede cesta prˇes ru˚zne´ smeˇrovacˇe, nebude smeˇrova´nı´ probı´hat spra´vneˇ (jeden u´daj bude prˇepsa´n druhy´m, jedna ze sı´tı´ nebude dostupna´).
RIPv2 je aktualizacı´ protokolu RIP z poloviny 90. let 20. stoletı´. Hlavnı´m u´kolem bylo zohledneˇnı´ vyuzˇ´ıva´nı´ prefixu˚ a beztrˇ´ıdnı´ho smeˇrova´nı´ (VLSM a CIDR). Funkcˇnost je podobna´, ale narozdı´l od RIPv1 • lze pouzˇ´ıvat beztrˇ´ıdnı´ smeˇrova´nı´, • max. pocˇet prˇeskoku˚ nenı´ 15, ale 255 (tedy pocˇet smeˇrovacˇu˚ v sı´ti nenı´ omezen na 15), • aktualizace smeˇrovacı´ch informacı´ se neposı´lajı´ jako broadcast zpra´vy, ale jako multicast zpra´vy na adresu 224.0.0.9, v prˇ´ıpadeˇ zna´my´ch sousedu˚ jako unicast pakety, • podpora oveˇrˇova´nı´ mezi dveˇma smeˇrovacˇi. U obou verzı´ RIP je metrika povazˇova´na za neprˇ´ılisˇ kvalitnı´, tedy pouzˇitelnost je pouze v maly´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 cˇ´ıslem 88. Jde o algoritmus vektoru vzda´lenostı´ (s tı´m souvisı´ pomalejsˇ´ı konvergence sı´teˇ), ktery´ ma´ obecneˇ lepsˇ´ı vlastnosti nezˇ RIP, alesponˇ co se ty´cˇe metriky. Soucˇa´stı´ konfigurace protokolu je cˇ´ıslo autonomnı´ho syste´mu (tudı´zˇ je slucˇitelny´ s jiny´mi smeˇrovacı´mi protokoly na jednom zarˇ´ızenı´).
P
Smeˇrovacı´ informace se posı´lajı´ kazˇdy´ch 90 s, a to broadcastem. Metrika je vı´cekriteria´lnı´, vyuzˇ´ıva´ se kombinace krite´riı´ • • • •
zpozˇdeˇnı´ v sı´ti (prodleva) za prˇedpokladu nezatı´zˇene´ sı´teˇ v ms, propustnost v b/s, zatı´zˇenı´ sı´teˇ, hodnota 255 znamena´ 100% zatı´zˇenı´, spolehlivost cesty, hodnota 255 znamena´ 100% spolehlivost.
Prvnı´ dveˇ krite´ria jsou povinna´ (dajı´ se odvodit z topologie sı´teˇ), dalsˇ´ı dveˇ krite´ria jsou nepovinna´ (lze je odvodit z momenta´lnı´ho provozu). Prˇi vy´pocˇtu metriky se postupuje podle zvolene´ho typu sluzˇby (obdoba QoS), hodnoty jednotlivy´ch krite´riı´ jsou na´sobeny konstantami specificky´mi pro dany´ typ sluzˇby (naprˇ´ıklad mu˚zˇe by´t uprˇednostneˇna propustnost sı´teˇ). Dalsˇ´ı krite´ria sice nejsou vyuzˇ´ıva´na prˇi vy´pocˇtu metriky, ale prˇesto jsou soucˇa´stı´ smeˇrovacı´ch informacı´ – pocˇet smeˇrovacˇu˚ na cesteˇ a MTU. EIGRP (Enhanced IGRP) je vylepsˇenı´ protokolu IGRP. Algoritmus smeˇrova´nı´ podle tohoto protokolu jizˇ nenı´ cˇisteˇ algoritmem vektoru vzda´lenostı´, objevujı´ se neˇktere´ prvky algoritmu stavu spoje (jde o hybridnı´ protokol). Metrika je opeˇt vypocˇ´ıta´va´na z propustnosti a zpozˇdeˇnı´ v sı´ti, je mozˇne´ prˇidat krite´ria zatı´zˇenı´ sı´teˇ a spolehlivosti, ale obvykle se to nedeˇla´.
P
EIGRP si udrzˇuje trˇi tabulky – sousedu˚, topologie a smeˇrova´nı´. Tabulky jsou aktualizova´ny prˇi zmeˇna´ch v topologii, a to multicast zpra´vami. Na jednom smeˇrovacˇi mu˚zˇe beˇzˇet vı´ce instancı´ protokolu (E)IGRP, protozˇe soucˇa´stı´ konfigurace je cˇ´ıslo autonomnı´ oblasti ASN.
7.4.6
OSPF
OSPF (Open Shortest Path First) pouzˇ´ıva´ algoritmus stavu spoje (cˇ´ıslo protokolu 89), cozˇ znamena´ rychlou konvergenci sı´teˇ prˇi kazˇde´ zmeˇneˇ topologie. Jde o otevrˇeny´ protokol (narozdı´l od IGRP a EIGRP, ktere´ byly vyvinuty firmou Cisco), a proto se s nı´m setka´me na zarˇ´ızenı´ch od mnoha ru˚zny´ch vy´robcu˚. Jde o beztrˇ´ıdnı´ smeˇrova´nı´, proto nestacˇ´ı pouze informace o adrese, musı´me zadat i de´lku prefixu, a to inverznı´ maskou (v bitove´ podobeˇ bychom invertovali masku takovou, kterou zna´me z kapitoly o protokolu IP). Smeˇrovacı´ informace se zası´lajı´ okamzˇiteˇ po zmeˇneˇ topologie nebo minima´lneˇ kazˇdy´ch 30 minut. Kazˇdy´ smeˇrovacˇ si udrzˇuje topologickou databa´zi sı´teˇ (ve skutecˇnosti ne cele´ sı´teˇ). Topologicka´ databa´ze ma´ formu orientovane´ho grafu s tı´m, zˇe jedna cesta mu˚zˇe mı´t v kazˇde´m smeˇru prˇirˇazenu jinou metriku.
P
7.4
ROUTING
157
Metrika je oznacˇova´na pojmem cena. Cena je kombinacı´ vı´ce krite´riı´ – propustnostı´ sı´teˇ, na´klady na spoje, atd., podle konfigurace, veˇtsˇinou se volı´ pouze vy´pocˇet z krite´ria propustnosti sı´teˇ. Cˇ´ıslo 100 000 000 vydeˇlı´me sˇ´ırˇkou pa´sma v b/s, tedy naprˇ´ıklad 100 Mb/s ma´ cenu 1, 1.2 Mb/s ma´ cenu 84, apod. Pokud je rozhranı´ rychlejsˇ´ı nezˇ 100 Mb/s, standardneˇ ma´ take´ cenu 1 (zaokrouhlujeme nahoru). Te´to nesrovnalosti se prˇedcha´zı´ zmeˇnou vzorce v konfiguraci (zmeˇna referencˇnı´ sˇ´ırˇky pa´sma). Naprˇ´ıklad posloupnost prˇ´ıkazu˚
P
router ospf 100 auto-cost reference-bandwidth 1000
v OSPF s cˇ´ıslem autonomnı´ho syste´mu 100 zmeˇnı´ referencˇnı´ sˇ´ırˇku pa´sma na 1000 kb/s, tedy ve vzorci bychom pouzˇili cˇ´ıslo 1 000 000 000 (to je trˇeba prove´st ve vsˇech smeˇrovacˇ´ıch, abychom si nevyrobili nestabilnı´ sı´t’s neprˇedvı´datelny´m chova´nı´m). Cena cele´ cesty je soucˇtem cen pro jednotlive´ u´seky cesty. OSPF podporuje hierarchicke´ smeˇrova´nı´. To znamena´, zˇe smeˇrovacˇe (a jejich sı´teˇ) lze v ra´mci autonomnı´ oblasti rozdeˇlit do oblastı´ (area). Kazˇdy´ smeˇrovacˇ si udrzˇuje pouze topologickou ba´zi sve´ oblasti, ostatnı´ oblasti mu zu˚sta´vajı´ skryty a aktualizace prˇi zmeˇna´ch topologie se omezuje jen na danou oblast. Rozlisˇujeme vnitrˇnı´ smeˇrovacˇe (uvnitrˇ neˇktere´ oblasti), hranicˇnı´ smeˇrovacˇe oblasti (v neˇkolika oblastech – ABR, Area Border Router) a hranicˇnı´ smeˇrovacˇe autonomnı´ho syste´mu (zprostrˇedkova´vajı´ komunikaci mezi ru˚zny´mi autonomnı´mi syste´my, vcˇetneˇ teˇch s jiny´mi smeˇrovacı´mi protokoly).
P
Pa´terˇnı´ sı´t’ mezi smeˇrovacˇi je oznacˇova´na jako oblast 0, smeˇrovacˇe v pa´terˇnı´ sı´ti jsou pa´terˇnı´ smeˇrovacˇe. Pa´terˇnı´ sı´t’mu˚zˇe by´t i WAN. V rozsa´hlejsˇ´ıch sı´tı´ch by vzˇdy meˇla by´t pa´terˇnı´ sı´t’a vsˇechny „nenulove´“ oblasti by meˇly sousedit pouze s oblastı´ 0. Soucˇa´stı´ smeˇrovacı´ tabulky jsou samozrˇejmeˇ take´ prefixy adres sı´tı´. Podobneˇ jako mnohe´ dalsˇ´ı protokoly, take´ OSPF pouzˇ´ıva´ sumarizaci smeˇrovacı´ch informacı´. Ty´ka´ se to prˇedevsˇ´ım smeˇrova´nı´ na hranicˇnı´ch smeˇrovacˇ´ıch, ktere´ by meˇly adresy v oblasti smeˇrovat souhrnneˇ, cˇ´ımzˇ se urychluje smeˇrova´nı´ paketu˚ na hranicı´ch oblastı´. V loka´lnı´ch sı´tı´ch (obecneˇ v sı´tı´ch s vsˇesmeˇrovy´m vysı´la´nı´m) musı´ existovat jeden poveˇrˇeny´ smeˇrovacˇ (Designated Router), ktery´ rˇ´ıdı´ vesˇkerou aktualizaci smeˇrovacı´ch informacı´ v sı´ti. Pro prˇ´ıpad, zˇe by poveˇrˇeny´ smeˇrovacˇ selhal, by meˇl existovat za´lozˇnı´ poveˇrˇeny´ smeˇrovacˇ. Poveˇrˇeny´ smeˇrovacˇ prova´dı´ vy´pocˇet cest a tı´m snı´ma´ cˇa´st za´teˇzˇe z ostatnı´ch smeˇrovacˇu˚ v oblasti. Vy´beˇr poveˇrˇene´ho smeˇrovacˇe sice lze nechat na protokolu OSPF, ale lepsˇ´ı je prove´st to rucˇneˇ, protozˇe automaticky´ vy´beˇr nedopadne vzˇdy zrovna idea´lneˇ. Rucˇnı´ vy´beˇr poveˇrˇene´ho smeˇrovacˇe se prova´dı´ prˇirˇazenı´m priority (hodnota v rozsahu 0–255), vybereme obvykle nejvy´konneˇjsˇ´ı smeˇrovacˇ nebo hlavnı´ smeˇrovacˇ (resp. nejle´pe obojı´ dohromady v jednom zarˇ´ızenı´). Z dalsˇ´ıch du˚lezˇity´ch vlastnostı´ protokolu OSPF: • podpora rozlozˇenı´ provozu k cı´li mezi cesty se stejnou celkovou cenou (ale bud’ vsˇechny pakety se stejnou cı´lovou – fina´lnı´ – IP adresou jdou stejnou cestou), • podpora smeˇrova´nı´ podle typu sluzˇeb (ToS) IP, • mechanismus oveˇrˇova´nı´ autenticity paketu˚ se smeˇrovacı´ informacı´. OSPF je vhodny´ zejme´na pro veˇtsˇ´ı IP sı´teˇ vcˇetneˇ teˇch, ktere´ majı´ pa´terˇnı´ sı´t’.
P
7.4
ROUTING
7.4.7
158
IS-IS
IS-IS (Intermediate System to Intermediate System) byl pu˚vodneˇ soucˇa´stı´ architektury ISO/OSI, ale po u´praveˇ byl zarˇazen do TCP/IP. Je urcˇen prˇedevsˇ´ım pro smeˇrova´nı´ bez navazova´nı´ spojenı´. By´va´ oblı´beny´ zejme´na u velky´ch ISP.
IS-IS pouzˇ´ıva´ algoritmus stavu spoje a princip jeho cˇinnosti je hodneˇ podobny´ protokolu OSPF. Takte´zˇ se rozlisˇujı´ smeˇrovacˇe uvnitrˇ oblasti (prvnı´ u´rovenˇ – L1) a hranicˇnı´ smeˇrovacˇe (druha´ u´rovenˇ – L2), pozor, neple´st si s L1, L2, atd. u vrstev modelu˚. Neexistuje zˇa´dna´ oblast 0 s pa´terˇ´ı, smeˇrovacˇe L2 poskytujı´ propojenı´ do vsˇech oblastı´. Take´ lze vytvorˇit virtua´lnı´ spoj mezi dveˇma L1 smeˇrovacˇi. Pokud smeˇrovacˇ L1 obdrzˇ´ı paket nepatrˇ´ıcı´ do jeho oblasti, odesˇle ho nejblizˇsˇ´ımu smeˇrovacˇi L2. Potom paket putuje po smeˇrovacˇ´ıch L2 tak dlouho, dokud se nedostane do oblasti, do ktere´ patrˇ´ı. Zatı´mco OSPF posı´la´ smeˇrovacı´ informace v IP paketech, IS-IS vyuzˇ´ıva´ ra´mce linkove´ vrstvy.
7.4.8
EGP a BGP
Pojem EGP ma´ ve skutecˇnosti dva vy´znamy – oznacˇujı´ se tak obecneˇ vneˇjsˇ´ı (externı´) smeˇrovacı´ protokoly, ale take´ jeden konkre´tnı´ externı´ protokol (ten nejstarsˇ´ı). EGP (Exterior Gateway Protocol) je jednoduchy´ vneˇjsˇ´ı smeˇrovacı´ protokol pro vy´meˇnu informacı´ o dostupnosti cˇi nedostupnosti sı´tı´ (prˇedchozı´ popsane´ protokoly byly vnitrˇnı´), cˇ´ıslo protokolu je 8. Smeˇrovacˇe si neusta´le oveˇrˇujı´ funkcˇnost svy´ch sousedu˚ a take´ si s nimi vymeˇnˇujı´ informace o dostupnosti prˇipojeny´ch sı´tı´. Nepouzˇ´ıva´ se zˇa´dna´ metrika, a proto je vyloucˇena existence vı´ce paralelnı´ch cest k te´zˇe sı´ti; nenı´ pouzˇitelny´, pokud se na cesta´ch vyskytuje smycˇka (vyzˇaduje stromovou strukturu smeˇrovacˇu˚). V soucˇasnosti se uzˇ s EGP nesetka´me. BGP (Border Gateway Protocol) je take´ vneˇjsˇ´ı smeˇrovacı´ protokol, ale jizˇ slozˇiteˇjsˇ´ı, funkcˇneˇjsˇ´ı a pouzˇitelneˇjsˇ´ı. Propojuje ru˚zne´ autonomnı´ syste´my. Smeˇrovacˇe vyuzˇ´ıvajı´cı´ BGP udrzˇujı´ „sousedske´ vztahy“ – pravidelneˇ vysı´lajı´ zpra´vy KeepAlive, jejichzˇ u´cˇel je ujisˇt’ova´nı´ o vlastnı´ funkcˇnosti. Sve´ sousedy vsˇak nezjisˇt’ujı´ automaticky, sousedstvı´ musı´ by´t rucˇneˇ nakonfigurova´no. Prˇi prvnı´ vy´meˇneˇ smeˇrovacı´ch informacı´ smeˇrovacˇ informuje o sve´m prefixu a cˇ´ısle ASN a obdrzˇ´ı celou smeˇrovacı´ tabulku, prˇi zmeˇna´ch pak jen cˇa´sti smeˇrovacı´ tabulky, ktery´ch se zmeˇna ty´ka´. Prˇi ozna´menı´ sve´ho prefixu smeˇrovacˇ doplnı´ k prefixu sve´ ASN. Beˇhem prˇeda´va´nı´ mezi smeˇrovacˇi kazˇdy´ smeˇrovacˇ take´ prˇida´ sve´ ASN, tedy celkova´ de´lka identifikacˇnı´ho rˇeteˇzce cesty se neusta´le prodluzˇuje. Vysˇsˇ´ı prioritu ma´ kratsˇ´ı cesta, tedy cesta s mensˇ´ım pocˇtem ASN, vedoucı´ prˇes me´neˇ BGP smeˇrovacˇu˚. Protokol BGP nelze prˇesneˇ zarˇadit mezi algoritmy vektoru vzda´lenostı´ ani algoritmy stavu spoje. Vyuzˇ´ıva´ se algoritmus vektoru cest, tj. vy´sˇe popsana´ sekvence cˇ´ısel ASN doplneˇna´ prefixem. Zatı´mco jine´ smeˇrovacı´ protokoly z du˚vodu veˇtsˇ´ı pruzˇnosti vyuzˇ´ıvajı´ nespolehlive´ prˇenosy (UDP), protokol BGP vyuzˇ´ıva´ spolehlivy´ prˇenos (TCP). Podporuje CIDR (vyuzˇ´ıva´ beztrˇ´ıdnı´ smeˇrova´nı´, prefixy) a agregaci cest. Kvalitu cesty lze ovlivnit konfiguracı´ mnoha parametru˚. Cesty majı´ ru˚zne´ va´hy a take´ jim lze prˇirˇadit ru˚zne´ atributy. Protokol BGP je hlavnı´m smeˇrovacı´m protokolem na Internetu, jeho vyuzˇitı´ je pomeˇrneˇ cˇaste´.
P
7.5
CESNET2
7.4.9
159
Softwarovy´ smeˇrovacˇ
Smeˇrovacˇe by´vajı´ obvykle hardwarove´, ale pro tyto u´cˇely lze pouzˇ´ıt i starsˇ´ı pocˇ´ıtacˇ (smeˇrova´nı´ v mensˇ´ı sı´ti nenı´ moc vy´pocˇetneˇ na´rocˇne´) se specia´lnı´m softwarem.
Zebra1 je velmi oblı´beny´ a pouzˇ´ıvany´ svobodny´ software pro unixove´ syste´my podporujı´cı´ protokoly RIPv1, RIPv2, OSPFv2, BGPv4. Quagga2 je open-source software pro unixove´ syste´my podporujı´cı´ kromeˇ jine´ho protokoly OSPFv2, OSPFv3, RIPv1, RIPv2, BGPv4. Jedna´ se o klon Zebry. XORP3 (Extensible Open Router Platform) je open-source smeˇrovacı´ platforma podporujı´cı´ prakticky vsˇechny zna´me´ smeˇrovacı´ protokoly. Na stra´nka´ch projektu je dokonce mozˇne´ si sta´hnout demonstracˇnı´ LiveCD. NAT32 Windows Software Router4 je software pro Windows (jen pro male´ sı´teˇ, ze smeˇrovacı´ch protokolu˚ podporuje RIP). Je volneˇ ke stazˇenı´, platı´ se za podporu.
7.5
CESNET2
CESNET2 (Czech Education and Scientific NETwork) je na´rodnı´ vysokorychlostnı´ pocˇ´ıtacˇova´ sı´t’ urcˇena´ pro vzdeˇla´va´nı´, veˇdu, vy´zkum a vy´voj, zalozˇena´ roku 1996. Propojuje prˇedevsˇ´ım vysoke´ sˇkoly a vy´zkumne´ u´stavy vcˇetneˇ vsˇech u´stavu˚ Akademie veˇd Cˇeske´ republiky, jsou prˇipojeny take´ neˇktere´ nemocnice a strˇednı´ sˇkoly.
P
Jde uzˇ o druhou generaci te´to sı´teˇ. Pu˚vodnı´ sı´t’ CESNET prvnı´ generace dosahovala rychlostı´ v desı´tka´ch azˇ stovka´ch Mb/s, zatı´mco CESNET2 dosahuje rychlostı´ kolem 10 Gb/s, na neˇktery´ch mı´stech azˇ 100 Gb/s. V polovineˇ 90. let se hodneˇ pouzˇ´ıvala sı´t’ ATM, pozdeˇji kolem roku 2000 byla postupneˇ zava´deˇna technologie PoS (Packet over SDH) a MPLS a prˇenosova´ soustava byla postavena na DWDM. Soucˇasna´ topologie sı´teˇ je naznacˇena na obra´zku 7.4. ´ cˇelem sı´teˇ CESNET2 je poskytova´nı´ vysokorychlostnı´ch prˇenosu˚ pro u´cˇely vy´zkumu a vzdeˇU la´nı´, zaby´va´ se take´ ru˚zny´mi typy vyuzˇitı´ prˇenosove´ kapacity (VoIP, multimedia´lnı´ prˇenosy a videokonference, QoS, vysokorychlostnı´ bezdra´tove´ prˇipojenı´, atd.). V soucˇasne´ dobeˇ se vzhledem k momenta´lnı´ situaci v oblasti sı´tı´ hodneˇ angazˇuje v bezpecˇnostnı´ch technologiı´ch. Zajı´mavy´ projekt je take´ EduRoam.cz, ktery´ umozˇnˇuje prˇipojit se do bezdra´tove´ sı´teˇ ktere´hokoliv cˇlena CESNETu (veˇtsˇinou jde o podporu mobilit zameˇstnancu˚ vysoky´ch sˇkol a vy´zkumny´ch u´stavu˚). CESNET2 je take´ napojena na mezina´rodnı´ sı´teˇ s podobny´m zameˇrˇenı´m, naprˇ´ıklad na evropskou sı´t’GE´ANT, slovenskou SANET, rakouskou ACONET a polskou PIONIER. Dalsˇı´ 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
Obra´zek 7.4: Topologie sı´teˇ CESNET25
7.5.1
Multimedia´lnı´ prˇenosy
Nejmensˇ´ı sˇ´ırˇku pa´sma (do neˇkolika desı´tek kb/s) vyzˇaduje prˇenos zvuku. Veˇtsˇ´ı sˇ´ırˇku pa´sma vyzˇaduje prˇenos obrazu i v nizˇsˇ´ı kvaliteˇ. Kromeˇ prˇenosu zvuku a obrazu existujı´ i dalsˇ´ı mozˇnosti, jak vyuzˇ´ıt kapacitu multimedia´lnı´ch prˇenosu˚, naprˇ´ıklad sdı´lena´ tabule (u´cˇastnı´ci „kreslı´“ na tabuli, ta je viditelna´ a prˇ´ıstupna´ vsˇem u´cˇastnı´ku˚m videokonference). Existujı´ specializovana´ zarˇ´ızenı´ pro videokonference. Na trhu najdeme naprˇ´ıklad zarˇ´ızenı´ LifeSize nebo Polycom. Da´le se setka´me se specializovany´mi softwarovy´mi rˇesˇenı´mi (nenı´ trˇeba porˇizovat dalsˇ´ı hardware, stacˇ´ı pocˇ´ıtacˇ prˇipojeny´ k Internetu), naprˇ´ıklad MBone. V nejjednodusˇsˇ´ıch prˇ´ıpadech lze samozrˇejmeˇ pouzˇ´ıt konferencˇnı´ na´stroje dostupne´ v beˇzˇny´ch operacˇnı´ch syste´mech, jako trˇeba NetMeeting nebo GnomeMeeting.
7.5.2
Metacentrum, vy´pocˇetnı´ gridy
Metacentrum je aktivita CESNETu veˇnovana´ provozu na´rodnı´ho vy´pocˇetnı´ho gridu (distribuovane´ vy´pocˇetnı´ sı´teˇ). V gridu je v soucˇasne´ dobeˇ (2015) neˇkolik vy´konny´ch vy´pocˇetnı´ch center zahrnujı´cı´ch celkem 10 712 procesoru˚. Implementuje ru˚zne´ metody pro BigData, vcˇetneˇ algoritmu Hadoop od spolecˇnosti Google.
7.6
QOS
161
Grid je vyuzˇ´ıva´n prˇedevsˇ´ım akademicky´mi pracovnı´ky pro na´rocˇne´ vy´pocˇty ve vy´zkumu a vy´voji. Cˇlenstvı´ je bezplatne´ pro akademicke´ pracovnı´ky, kterˇ´ı jsou zameˇstnanci nebo studenty cˇlenu˚ CESNETu.
7.5.3
CESNET CSIRT, CERTS
CSIRT (Computer Security Incident Response Team) je (obecneˇjsˇ´ı) oznacˇenı´ pro ty´my zaby´vajı´cı´ se bezpecˇnostı´ v oblasti ICT. Tyto ty´my pracujı´ jak na na´rodnı´ u´rovni, tak i na nizˇsˇ´ıch u´rovnı´ch jak ve sta´tnı´ch sluzˇba´ch, tak i u velky´ch spolecˇnostı´. Ve skutecˇnosti jde o hierarchickou strukturu ty´mu˚ po cele´ zemi, ktere´ vza´jemneˇ dobrovolneˇ spolupracujı´. Hlavnı´ CSIRT ty´m pro CˇR je provozova´n sdruzˇenı´m CZ.NIC (rok 2007).
P
CSIRT ty´m plnı´ tyto u´koly: • rˇesˇenı´ bezpecˇnostnı´ch incidentu˚ ve spolupra´ci s cˇesky´mi provozovateli sı´tı´ a zahranicˇnı´mi partnery, • pomoc provozovatelu˚m sı´tı´ prˇi zrˇizova´nı´ vlastnı´ch CSIRT ty´mu˚, • poskytuje reaktivnı´ i proaktivnı´ sluzˇby, poradenstvı´ a sluzˇby, • mohou zjisˇt’ovat mozˇne´ autory DoS u´toku˚ a prˇeda´vat informace orga´nu˚m, ktere´ pak na toto ozna´menı´ reagujı´, nebo informovat provozovatele sı´teˇ o napadenı´ te´to sı´teˇ. CSIRT ty´my (ani celosta´tnı´) nemajı´ zˇa´dne´ pravomoce k rˇesˇenı´ bezpecˇnostnı´ch incidentu˚ na jine´ nezˇ technicke´ u´rovni, nejde o represivnı´ orga´ny. Mohou pouze monitorovat a radit, pravomoci k razantneˇjsˇ´ım reakcı´m majı´ pouze ve sve´ vlastnı´ sı´ti. CERTS (Computer Emergency Response Team Coordination Center) je CSIRT ty´m CESNETu (rok 2014). Jeho u´koly jsou na´sledujı´cı´:
P
• incident handling – prˇ´ıjem hla´sˇenı´ o bezpecˇnostnı´ch incidentech na CESNETu a jejich rˇesˇenı´, • provoz IDS (Intrusion Detection System) v sı´ti CESNET2, • spolupra´ce na bezpecˇ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 bezpecˇnostnı´ incidenty) tak proaktivnı´ (zlepsˇova´nı´ informovanosti uzˇivatelu˚ apod.) sluzˇby s du˚razem na ty proaktivnı´. Meˇl by poskytovat poradenstvı´ a sluzˇby nekomercˇnı´m organizacı´m zapojeny´m do CESNETu. Pozor, neplet’te si CERTS se zkratkou CzERT, cozˇ je skupina hackeru˚ stojı´cı´ch na opacˇne´ straneˇ barika´dy. Dalsˇ´ı 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) znamena´ zajisˇteˇnı´ kvality prˇenosove´ sluzˇby. Takto se oznacˇujı´ metody, ktere´ nabı´zejı´ garanci urcˇity´ch parametru˚ poskytovane´ sluzˇby. Garantovat lze naprˇ´ıklad:
P
• sˇ´ırˇku pa´sma pro prˇenos, volnou kapacitu sı´teˇ, • minima´lnı´ ztra´tovost datovy´ch jednotek (prˇ´ıpadneˇ te´meˇrˇ nulovou ztra´tovost), • dynamiku ztra´tovosti (tedy aby nedocha´zelo ke ztra´ta´m ve shlucı´ch, to by mohlo mı´t negativnı´ vliv na prˇenos multime´diı´, ktera´ obcˇasnou ztra´tu datove´ jednotky tolerujı´), • zpozˇdeˇnı´, latenci, • zmeˇny – dynamiku – zpozˇdeˇnı´ (jitter), • atd. Beˇzˇne´ sı´t’ove´ protokoly (e-mail, prˇenos souboru˚ apod.) obvykle nemajı´ velke´ na´roky na QoS, ale naopak VoIP a videoprˇenosu˚m mohou vadit vysˇsˇ´ı hodnoty zpozˇdeˇnı´, a take´ vysˇsˇ´ı hodnoty jitter. Technologie QoS je v neˇktery´ch specifikacı´ch dostupna´ prˇ´ımo, naprˇ´ıklad v ATM, Frame Relay a MPLS. Jinde je nutne´ mechanismus QoS prˇidat. Jednou z mozˇnostı´, jak zajistit QoS ve velmi rozsˇ´ırˇeny´ch IP sı´tı´ch (i vzda´leny´ch), je DiffServ.
7.6.2
DiffServ
DiffServ (Differenciated Services, oddeˇlene´ – diferencovane´ sluzˇby) je technologie zavedenı´ QoS (Quality of Service) do IP sı´tı´. Je to jen jedna z vı´ce ru˚zny´ch QoS technologiı´. Pracuje s 6 bity oznacˇeny´mi zkratkou DSCP (Differentiated Service Code Point), cozˇ znamena´ 64 mozˇny´ch trˇ´ıd prˇ´ıstupu (v praxi se vsˇak vyuzˇ´ıva´ jen neˇkolik z nich). Trˇ´ıdy lze rozdeˇlit do trˇ´ı za´kladnı´ch kategoriı´:
P P
1. Urychlene´ prˇeda´va´nı´ (EF, Expedited Forwarding) – garance male´ho a te´meˇrˇ konstantnı´ho zpozˇdeˇnı´, latence, sˇ´ırˇky pa´sma; je slozˇite´, proto mu˚zˇe by´t poskytnuto jen nı´zke´mu pocˇtu prˇenosu˚, je vhodne´ naprˇ´ıklad pro implementaci virtua´lnı´ho okruhu. 2. Zajisˇteˇne´ prˇeda´va´nı´ (AF, Assured Forwarding) – funguje podobneˇ jako vyuzˇ´ıva´nı´ CIR u Frame Relay. Pouzˇ´ıva´ se u sluzˇeb, ktere´ uprˇednostnˇujı´ volitelnou u´rovenˇ QoS. 3. Za´kladnı´ sluzˇba (BE, Best Effort) – pro beˇzˇne´ datove´ prˇenosy. Prˇi vstupu do sı´teˇ jsou pakety klasifikova´ny, oznacˇeny trˇ´ıdou (pokud je to potrˇeba). Pokud ne, jedna´ se o kategorii Best Effort. Klasifikace probı´ha´ pouze prˇi vstupu do sı´teˇ (tj. sı´teˇ uplatnˇujı´cı´ DiffServ, hovorˇ´ıme o DiffServ dome´neˇ ), na na´sledujı´cı´ch smeˇrovacˇ´ıch je tato informace pouze vyuzˇ´ıva´na. Tento zpu˚sob rˇ´ızenı´ QoS je pomeˇrneˇ jednodusˇe slucˇitelny´ s jiny´mi QoS protokoly. Na hranici DiffServ dome´ny (na hranove´m, ingress edge, smeˇrovacˇi) probı´ha´ vy´sˇe popsana´ klasifikace paketu, prˇ´ıpadneˇ prˇeklad z jine´ QoS technologie (ATM, MPLS, atd.). Konkre´tnı´ umı´steˇnı´ pole bitu˚ pro DiffServ za´visı´ na tom, na ktere´ vrstveˇ je tato technologie implementova´na (nemusı´ to by´t na sı´t’ove´ vrstveˇ s IP protokolem). Mu˚zˇe to by´t uvnitrˇ hlavicˇky
P
JMENNE´ A ADRESA´RˇOVE´ SLUZˇBY
7.7
163
datove´ jednotky (pokud je tam mı´sto) nebo vneˇ (prˇed za´hlavı´m). V IPv4 datagramu naprˇ´ıklad jde o 8bitove´ pole trˇ´ıdy sluzˇby (z toho je vyuzˇito 6 bitu˚), v IPv6 datagramu (viz na´kres na str. 31) jde o pole pro prioritu. Hodnota 0 je vy´chozı´, znamena´ Best Effort. DiffServ je podporova´n take´ v MPLS. Mensˇ´ım proble´mem je to, zˇe zatı´mco DiffServ pouzˇ´ıva´ pro urcˇenı´ trˇ´ıdy QoS 6 bitu˚, MPLS jen polovinu (v MPLS hlavicˇce jsou pro QoS vyhrazeny jen 3 bity). Dalsˇı´ 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
Jmenne´ a adresa´rˇove´ sluzˇby
Jmenne´ sluzˇby jsou obecny´m principem prˇekladu jmenny´ch na´zvu˚ (textovy´ch rˇeteˇzcu˚) na cˇ´ıselne´ adresy, se ktery´mi snadneˇji pracujı´ pocˇ´ıtacˇe. Typicky´m prˇedstavitelem jmenny´ch sluzˇeb je DNS, jehozˇ hlavnı´m u´cˇelem je prˇeklad slovnı´ch adres, ktery´m rozumı´me (trˇeba www.google.com) na cˇ´ıselne´ IP adresy. Ke jmenny´m sluzˇba´m mu˚zˇeme ve Windows rˇadit take´ WINS (Windows Internet Name Service, slouzˇ´ı k prˇekladu na´zvu˚ NetBIOS na IP adresy). Ovsˇem WINS se jizˇ moc nepouzˇ´ıva´ (zejme´na z du˚vodu znacˇny´ch omezenı´, naprˇ´ıklad de´lka na´zvu je nejvy´sˇe 15 znaku˚). Oproti tomu adresa´rˇove´ sluzˇby slouzˇ´ı k usporˇa´da´nı´, zabezpecˇenı´ a spra´veˇ prostrˇedku˚ (cˇasto reprezentovany´ch objekty ve strukturˇe). Typicky´m prˇedstavitelem adresa´rˇovy´ch sluzˇeb je naprˇ´ıklad Active Directory.
7.7.1
P P
Princip a struktura DNS
DNS (Domain Name System) je, jak bylo vy´sˇe uvedeno, jmenna´ sluzˇba, a to distribuovana´. Slouzˇ´ı prˇedevsˇ´ım k prˇekladu dome´novy´ch jmen (take´ hostname) na IP adresy zarˇ´ızenı´. Distribuovana´ je z toho du˚vodu, zˇe prˇeklad mu˚zˇe by´t prova´deˇn na jednom z mnoha DNS serveru˚ (uplatnˇuje se princip lokality – prˇekla´da´ prˇedevsˇ´ım ten server, ktery´ je nejblı´zˇ). Distribuovanost funguje take´ z toho du˚vodu, zˇe jmenne´ adresy jsou hierarchicke´ (nejde o flat – plochy´ – adresovy´ prostor, ale o hierarchicky´), a tedy prˇideˇlova´nı´ jmen nemusı´ by´t centralizovane´. Sı´t’ je organizova´na v hierarchicke´m syste´mu dome´n, kde kazˇda´ dome´na ma´ sve´ jme´no, a adresace pomocı´ jme´na se vytva´rˇ´ı podle hierarchie. Mu˚zˇeme si to prˇedstavit jako rˇadu stromu˚, kde kazˇdy´ strom ma´ jeden korˇen nazy´vany´ dome´na prvnı´ u´rovneˇ (TLD, Top Level Domain, naprˇ´ıklad .cz, .uk nebo .org) a da´le se veˇtvı´ v dalsˇ´ıch u´rovnı´ch (dome´ny druhe´, trˇetı´ a prˇ´ıp. dalsˇ´ı u´rovneˇ). Naprˇ´ıklad adresa mail.seznam.cz obsahuje celkem trˇi u´rovneˇ, z nichzˇ prvnı´ u´rovenˇ je zcela vpravo. TLD mohou by´t bud’ na´rodnı´ (naprˇ´ıklad .cz, .uk, .sk) a nebo genericke´ (nesouvisejı´cı´ se sta´tem cˇi na´rodem, naprˇ´ıklad .com, .edu, .org, .net).
P P
JMENNE´ A ADRESA´RˇOVE´ SLUZˇBY
7.7
164
Ve skutecˇnosti i tyto „stromy“ majı´ spolecˇny´ korˇen (tzv. korˇenovou dome´nu), ktera´ se oznacˇuje pouze samotnou tecˇkou (bez dalsˇ´ıch znaku˚). Prˇeklad na´zvu˚ probı´ha´ pomocı´ DNS serveru˚ (jmenny´ch – name – serveru˚). Prˇekla´da´ se ze jmenne´ adresy na cˇ´ıselnou IP adresu, a nebo naopak (reverznı´ prˇeklad). Protozˇe nenı´ technicky realizovatelne´ mı´t jeden jediny´ DNS server se vsˇemi potrˇebny´mi za´znamy, a ani mı´t vı´ce takovy´ch DNS serveru˚, probı´ha´ dotazova´nı´ u DNS serveru˚ distribuovaneˇ. To znamena´, zˇe za´znamy o vztahu jmenny´ch a IP adres jsou rozprostrˇeny mezi mnoho DNS serveru˚. Kazˇdy´ DNS server ma´ za´znamy o sve´ zo´neˇ (oblasti, kterou spravuje). Kazˇda´ dome´na prvnı´ u´rovneˇ ma´ urcˇite´ mnozˇstvı´ tzv. korˇenovy´ch serveru˚. Korˇenovy´ server doka´zˇe poda´vat informace o subdome´na´ch ve sve´ dome´neˇ. Kazˇde´ jme´no (dome´ny, zarˇ´ızenı´ apod.) musı´ splnˇovat urcˇite´ na´lezˇitosti. Prˇedevsˇ´ım jeho de´lka nesmı´ prˇekrocˇit 63 znaku˚ a mohou se pouzˇ´ıvat pouze pı´smena anglicke´ abecedy (bez diakritiky), cˇ´ıslice a pomlcˇky (ne podtrzˇ´ıtka, ta se ale mohou objevit v na´zvu souboru˚ a adresa´rˇu˚). Cele´ dome´nove´ jme´no musı´ mı´t maxima´lneˇ 255 znaku˚ – to platı´ pouze pro dome´nove´ jme´no, soucˇa´stı´ URL adresy by´vajı´ na´zvy souboru˚ a adresa´rˇu˚, pro neˇzˇ tato omezenı´ neplatı´. Existuje mozˇnost pouzˇ´ıva´nı´ ne-ascii znaku˚ v na´zvech dome´n (IDN – International Domain Names), ale prˇeklad (nahrazenı´ teˇchto znaku˚ probı´ha´ v klientske´ aplikaci, nevyskytujı´ se v zo´novy´ch souborech).6 Zo´na je tedy oblast spravovana´ jednı´m spra´vcem (organizacı´), obsahuje jednu nebo vı´ce dome´n. Informace o zo´neˇ spravuje a poskytuje autoritativnı´ DNS server7 pro danou zo´nu (jeden nebo vı´ce). Tyto informace jsou ulozˇeny v zo´nove´m souboru. To by´va´ bud’ textovy´ (DNS pro Windows) nebo bina´rnı´ soubor (BIND).
P
P
V ra´mci organizace ma´me obvykle jednu korˇenovou zo´nu, ktera´ zahrnuje dome´nu prˇideˇlenou organizaci, a da´le mohou existovat dalsˇ´ı zo´ny, ktere´ jsou te´to korˇenove´ zo´neˇ podrˇ´ızene´. Subdome´ny dome´ny organizace (a jejich podstromy dome´n) jsou bud’ v te´zˇe zo´neˇ (korˇenove´), a nebo jsou v jine´ zo´neˇ, tedy jejich spra´va byla delegova´na jine´ nezˇ korˇenove´ zo´neˇ. Takzˇe cela´ struktura vypada´ tak, zˇe ma´me • korˇenovy´ strom dome´n, korˇenem stromu je „bezejmenna´“ dome´na, jejı´zˇ potomci jsou TLD, potomci dome´n TLD jsou dome´ny druhe´ u´rovneˇ (SLD, Second Level Domain), atd., • strukturu zo´n, v jedne´ zo´neˇ je jedna nebo vı´ce dome´n, zo´ny stanovujı´ autoritu (co kdo spravuje), • strukturu DNS (name) serveru˚, platı´, zˇe pro kazˇdou dome´nu ma´me jeden nebo vı´ce DNS serveru˚, z nichzˇ jeden v kazˇde´ dome´neˇ je prima´rnı´. Rozlisˇujeme neˇkolik typu˚ serveru˚ v ra´mci zo´ny: • prima´rnı´ server – obvykle se jedna´ o autoritativnı´ server zo´ny, v zo´neˇ je pra´veˇ jeden; tento server je du˚veˇryhodny´, jeho data musı´ by´t neusta´le v aktua´lnı´m stavu (pokud prova´dı´me 6
IDN se ty´ka´ pouze na´zvu˚ dome´n. Zbytek adresy take´ mu˚zˇe obsahovat ne-ascii znaky (pozor, cˇasto nefunguje, nenı´ zatı´m plneˇ dopracova´no), ale jde o IRI (International Resource Indicator). 7 Pojem „autoritativnı´“ znamena´ dostatecˇneˇ velka´ prˇ´ıstupova´ opra´vneˇnı´ take´ pro prova´deˇnı´ zmeˇn. Tato opra´vneˇnı´ platı´ ve vy´chozı´m nastavenı´ obvykle i pro subdome´ny
P
JMENNE´ A ADRESA´RˇOVE´ SLUZˇBY
7.7
165
zmeˇny, deˇla´me to pra´veˇ zde), tady najdeme zo´novy´ soubor, ktery´ lze prˇ´ıpadneˇ konfigurovat, jde o autoritativnı´ server dome´ny, • sekunda´rnı´ server (i vı´ce nezˇ jeden) – obsahuje kopii dat prima´rnı´ho serveru, ktera´ je cˇasto aktualizova´na (synchronizova´na s prima´rnı´m serverem – zone transfer), slouzˇ´ı jako za´lozˇnı´ prima´rnı´ server nebo pro rozlozˇenı´ za´teˇzˇe, • caching-only server – neobsahuje vsˇechny informace, vzˇdy se dotazuje prima´rnı´ho (sekunda´rnı´ho) serveru, ale odpoveˇdi na k neˇmu smeˇrovane´ dotazy si necha´va´ v cache a vyuzˇ´ıva´ je pro odpoveˇdi na na´sledne´ dotazy. Cache se pouzˇ´ıva´ i na prima´rnı´ch cˇi sekunda´rnı´ch serverech pro informace o cizı´ch dome´na´ch. Zone transfer (prˇenos zo´nove´ho za´znamu) z prima´rnı´ho na sekunda´rnı´ server prova´dı´ sekunda´rnı´ server v pravidelny´ch intervalech, ale take´ prˇi sve´m zapnutı´ a prˇi upozorneˇnı´ (od prima´rnı´ho serveru), zˇe dosˇlo ke zmeˇna´m v zo´nove´m za´znamu. Autoritativnı´ odpoveˇd’ poskytuje prima´rnı´ server. Odpoveˇd’ od caching-only serveru nenı´ autoritativnı´ (protozˇe informace v cache uzˇ nemusejı´ by´t aktua´lnı´), tazatel si mu˚zˇe explicitneˇ vyzˇa´dat autoritativnı´ odpoveˇd’. Odpoveˇd’ sekunda´rnı´ho serveru je obvykle autoritativnı´ (spra´vna´), protozˇe odpovı´da´ se zpozˇdeˇnı´m, ktere´ by meˇlo by´t nastaveno na vysˇsˇ´ı hodnotu nezˇ je de´lka intervalu, ve ktere´m prova´dı´ zone transfer.
7.7.2
P P
Dotazy v DNS
DNS server, jak bylo vy´sˇe uvedeno, si v zo´nove´m za´znamu vede informace o sve´ dome´neˇ, obsazˇeny´ch subdome´na´ch, a take´ informaci o nadrˇ´ızene´m serveru (tj. DNS serveru nadrˇ´ızene´ dome´ny). Kazˇdy´ DNS server zna´ korˇenovy´ DNS server cele´ho syste´mu. Rozlisˇujeme doprˇedne´ vyhleda´va´nı´ (nalezenı´ IP adresy podle dome´nove´ho jme´na) a zpeˇtne´ vyhleda´va´nı´ (reverznı´, nalezenı´ dome´nove´ho jme´na podle IP adresy). Reverznı´ vyhleda´va´nı´ se prova´dı´ prˇes dome´nu in-addr.arpa. Zde je hlavnı´m proble´mem to, zˇe jak jmenne´, tak IP adresy jsou hierarchicke´, ale kazˇda´ „v jine´m smeˇru“ – dome´na TLD ve jmenne´ adrese je zcela vpravo, kdezˇto adresu sı´teˇ (hlavnı´ cˇa´st) v IP adrese najdeme zcela vlevo. Dotazova´nı´ v doprˇedne´m vyhleda´va´nı´ (ma´me jmennou adresu a chceme IP adresu) probı´ha´ distribuovaneˇ – DNS server cˇasto nedoka´zˇe na dotaz odpoveˇdeˇt okamzˇiteˇ podle svy´ch za´znamu˚, proto se obracı´ nebo odkazuje na neˇktery´ z korˇenovy´ch serveru˚ zadane´ dome´ny prvnı´ u´rovneˇ.
P P
Rozlisˇujeme dva typy dotazu˚: • rekurzivnı´ dotazy – tazatel dostane jizˇ hotovou odpoveˇd’, • iterativnı´ dotazy – tazatel postupneˇ zı´ska´va´ odkazy na mı´sta, kde mu˚zˇe dostat odpoveˇd’. Tazatel svu˚j dotaz (jaka´ je IP adresa zarˇ´ızenı´ se jme´nem www.abcd.cz?) posı´la´ tzv. loka´lnı´mu DNS serveru (nejblizˇsˇ´ımu, ktery´ zna´). Pokud tento server jizˇ zna´ odpoveˇd’, poskytne ji. Pokud ne, dalsˇ´ı postup se lisˇ´ı podle pouzˇ´ıvane´ho typu dotazova´nı´: Rekurzivnı´ dotaz. Pokud DNS server nezna´ odpoveˇd’ (adresa nenı´ z jeho dome´ny), obra´tı´ se na korˇenovy´ server nebo DNS server te´ dome´ny z adresy, kterou jesˇteˇ zna´ (to mu˚zˇe by´t TLD).
P
7.7
JMENNE´ A ADRESA´RˇOVE´ SLUZˇBY
166
Dotazovany´ DNS server se chova´ stejneˇ – pokud zna´ cı´l, odpovı´ adresou, pokud cı´l nezna´, dotazuje se da´le (obvykle ve svy´ch subdome´na´ch). Takto rekurzı´vneˇ je dotaz posı´la´n po stromeˇ dome´n smeˇrem dolu˚. Kdyzˇ se konecˇneˇ dostane k DNS serveru, ktery´ zna´ odpoveˇd’, tento server odesˇle odpoveˇd’ prˇ´ımo loka´lnı´mu DNS serveru, na ktere´m dotazova´nı´ zacˇalo, a ten ji odesˇle tazateli. Prˇı´klad Pokud potrˇebujeme zjistit IP adresu pocˇ´ıtacˇe www.firma.cz, obra´tı´me se na loka´lnı´ DNS server. Ten odpoveˇd’ nezna´, tedy prˇeposˇle dotaz na neˇktery´ z korˇenovy´ch serveru˚ dome´ny cz. Dotazovany´ korˇenovy´ server bud’ adresu dohleda´ ve svy´ch za´znamech a nebo dotaz posˇle na neˇktery´ z DNS serveru˚ pro sve´ subdome´ny podle jmenne´ adresy (firma). Dotaz se takto postupneˇ dostane k DNS serveru, ktery´ identifikuje poslednı´ cˇa´st adresy (vlevo), www (obvykle jde o web server). Potom bude odpoveˇd’ (IP adresa pro jmennou adresu www.firma.cz) odesla´na tazateli.
U rekurzivnı´ch dotazu˚ se take´ pouzˇ´ıva´ pojem forwarding (prˇeda´va´nı´). Oproti na´sledujı´cı´mu typu dotazu˚ je mensˇ´ı pravdeˇpodobnost zahlcova´nı´ spoju˚. Iterativnı´ dotaz. Zde je aktivita prˇedevsˇ´ım na straneˇ tazatele. Pokud dotazovany´ DNS server (ktery´koliv, nejdrˇ´ıv loka´lnı´) nezna´ odpoveˇd’, nedotazuje se da´le, ale tazateli odesˇle mı´sto odpoveˇdi seznam DNS serveru˚, ktere´ by mohly zna´t odpoveˇd’ („nevı´m, zeptej se serveru/u˚ xxxx“, doporucˇ´ı bud’ korˇenovy´ server, neˇktery´ TLD, a nebo servery ze svy´ch subdome´n). Tazatel si vybere neˇktery´ z doporucˇeny´ch DNS serveru˚ podle toho, jak odpovı´dajı´ dome´nove´ adrese, a ta´zˇe se da´le. Kazˇdy´ dotazovany´ server opeˇt posˇle bud’ prˇ´ımo odpoveˇd’, a nebo doporucˇenı´ s na´zvy dalsˇ´ıch DNS serveru˚.
P
Prˇı´klad Pokud potrˇebujeme zjistit IP adresu pocˇ´ıtacˇe www.firma.cz, obra´tı´me se opeˇt na loka´lnı´ DNS server. Ten na´m doporucˇ´ı, abychom dotaz odeslali na neˇktery´ z korˇenovy´ch serveru˚ dome´ny cz, cozˇ udeˇla´me. Dotazovany´ korˇenovy´ server bud’ adresu dohleda´ ve svy´ch za´znamech a nebo vra´tı´ pouze adresy name serveru˚, ktere´ mohou zna´t odpoveˇd’. Takto distribuovaneˇ probı´ha´ vyhodnocova´nı´ dotazu (postupneˇ podle vnorˇova´nı´ dome´n ru˚zny´ch u´rovnı´), poslednı´ ta´zany´ name server vra´tı´ pozˇadovanou IP adresu.
Komunikaci zprostrˇedkova´va´ protokol DNS. Tento protokol pouzˇ´ıva´ obvykle UDP pakety (mu˚zˇe pouzˇ´ıvat i TCP, ale je to pomalejsˇ´ı), na portu 53. Na obycˇejne´m desktopu obvykle nebeˇzˇ´ı DNS server, ale pouze resolver. Resolver jen prˇeda´va´ dotazy neˇktere´mu skutecˇne´mu DNS serveru, nerˇesˇ´ı je.
7.7.3
DNS za´znamy a forma´t dotazu
Ke kazˇde´ IP adrese je v zo´nove´m souboru prˇirˇazena alesponˇ jedna jmenna´ adresa, mu˚zˇe jich by´t vı´ce. Tedy jedna z teˇchto jmenny´ch adres je nejdu˚lezˇiteˇjsˇ´ı, nazy´va´ se kanonicke´ jme´no pocˇ´ıtacˇe
P
7.7
JMENNE´ A ADRESA´RˇOVE´ SLUZˇBY
167
(cannonical name, cname). Dalsˇ´ı jmenne´ adresy prˇirˇazene´ te´zˇe IP adrese jsou aliasy. Name servery si uchova´vajı´ v zo´nove´m souboru tyto typy za´znamu˚: • SOA (Start of Authority) – obsahuje administrativnı´ informace o dome´neˇ, • A – za´znam urcˇujı´cı´ vztah mezi konkre´tnı´ IPv4 adresou a k nı´ prˇ´ıslusˇejı´cı´m kanonicky´m jme´nem, • AAAA – tote´zˇ jako za´znam typu A, ale pro IPv6, • CNAME – definice aliasu ke kanonicke´mu jme´nu, tedy narozdı´l od prˇedchozı´ho typu za´znamu jde o dvojici alias–cname, • PTR – pouzˇ´ıva´me prˇi reverznı´m prˇekladu (ma´me IP adresu, potrˇebujeme jmennou adresu), • NS (Name Server) – informace o autoritativnı´m DNS serveru pro danou dome´nu, • MX (Mail eXchanger) – uda´va´ cestu k mail serveru pro danou dome´nu. Da´le existujı´ typy za´znamu˚ urcˇene´ pro zabezpecˇenı´, naprˇ´ıklad za´znam typu KEY obsahuje verˇejny´ klı´cˇ pouzˇ´ıvany´ prˇi autorizaci. Vidı´me, zˇe v zo´nove´m souboru nejsou pouze informace o zpu˚sobu mapova´nı´ jmenne´ adresy na IP adresu (za´znamy typu A). Za´znam typu MX umozˇnˇuje zjednodusˇeneˇ adresovat mail server (emaily obvykle posı´la´me na nejblizˇsˇ´ı mail server, v nasˇ´ı dome´neˇ). Soucˇa´stı´ za´znamu˚ je take´ hodnota TTL, ktera´ plnı´ podobnou u´lohu jako u IP datagramu˚, tedy zachycuje sta´rˇ´ı za´znamu.
Obra´zek 7.5: DNS paket v programu Wireshark
P
JMENNE´ A ADRESA´RˇOVE´ SLUZˇBY
7.7
168
Pakety protokolu DNS jsou pomeˇrneˇ jednoduche´ (zapouzdrˇujı´ se obvykle do UDP paketu), jsou stejne´ pro oba smeˇry (dotaz a odpoveˇd’). Struktura je na´sledujı´cı´: 1. Header (za´hlavı´) – identifikacˇnı´ cˇ´ıslo (pro pa´rova´nı´ dotazu a odpoveˇdi), typ PDU (dotaz/odpoveˇd’), zda ma´ by´t dotaz rekurzivnı´, vyzˇa´da´nı´ si autoritativnı´ odpoveˇdi, atd. 2. Question (pole dotazu) – obvykle jmenna´ adresa a dodatecˇne´ informace, 3. Answer (pole odpoveˇdi) – informace souvisejı´cı´ s odpoveˇdı´ vcˇetneˇ TTL, 4. Authority – autoritativnı´ jmenne´ servery (jejich jmenne´ adresy) ze za´znamu˚ NS, 5. Additional – dodatecˇne´ informace (naprˇ´ıklad take´ IP adresy autoritativnı´ch jmenny´ch serveru˚). Na obra´zku 7.5 vidı´me strukturu DNS paketu zachycene´ho programem Wireshark. V hornı´ cˇa´sti okna je seznam datovy´ch jednotek (ten na´sˇ je v seznamu sˇedeˇ podbarven, prvnı´ zobrazeny´), prostrˇednı´ podokno zobrazuje jednotlive´ cˇa´sti paketu. V rozbalitelny´ch veˇtvı´ch zachycujı´cı´ch jednotlive´ „slupky“ rozbalovane´ho paketu je
P
$
• za´kladnı´ informace o ra´mci (zde nenı´ zobrazen korˇen podstromu; de´lka, cˇasove´ u´daje, atd.), • popis ethernetove´ho ra´mce na L2 (uzel oznacˇen Ethernet II; MAC adresy a IG/LG bity), • IPv4 datagram (IP adresy, hodnoty jednotlivy´ch polı´ v za´hlavı´ vcˇetneˇ nastavenı´ fragmentace, TTL, vnorˇene´ho protokolu), • UDP segment (zdrojovy´ a cı´lovy´ port, de´lka) – tato veˇtev je uzˇ na obra´zku rozbalena´, • konecˇneˇ DNS paket (cˇ´ıslo transakce, jednotlive´ prˇ´ıznaky (podle nich naprˇ´ıklad vidı´me, zˇe jde o dotaz, ktery´ ma´ by´t proveden rekurzı´vneˇ a jsou vyzˇadova´na autorizovana´ data), po cˇ´ıselny´ch polozˇka´ch na´sledujı´ jednotlive´ u´daje dotazu (dome´nova´ adresa, chceme IP adresu typu „A“, tedy IPv4). MAC adresy jsou zakryty. Ve Windows (na serverovy´ch verzı´ch) se setka´me s rolı´ DNS Server. Na jiny´ch syste´mech (vcˇetneˇ Windows, kdyzˇ nedisponujeme serverovou verzı´) se setka´me se syste´mem BIND (program samotny´ je pojmenova´n named), TinyDNS nebo DJBDNS.
$
Take´ na desktopu ma´me mozˇnost nahle´dnout do mechanismu DNS. Ve Windows i v Linuxu lze pouzˇ´ıvat prˇ´ıkaz nslookup (mı´rneˇ se lisˇ´ı v poskytovany´ch mozˇnostech a samozrˇejmeˇ v implementaci). Tento prˇ´ıkaz lze vyuzˇ´ıvat v beˇzˇne´m (jednora´zove´ prˇ´ıkazy) i interaktivnı´m rezˇimu, a to obvykle pro zjisˇteˇnı´ IP adresy k dome´nove´ adrese nebo naopak, zjisˇteˇnı´ adres DNS serveru˚, prˇ´ıpadneˇ zjisˇteˇnı´ parametru˚ prˇekladu. Prˇ´ıklady pouzˇitı´ jsou v prˇ´ıloze (pro Windows to je kapitola B.3.2, strana 234, v Linuxu je syntaxe velmi podobna´ – strana 270). V unixovy´ch syste´mech ma´me k dispozici nejen nslookup, ale take´ na´stroj dig (strana 270). Tento na´stroj je komplexneˇjsˇ´ı a jeho vy´stupy jsou podrobneˇjsˇ´ı (nicme´neˇ je mozˇne´ si vyzˇa´dat kra´tkou odpoveˇd’ ve stylu nslookup).
Existujı´ dalsˇ´ı na´stroje, jizˇ pro profesiona´lnı´ pouzˇitı´, naprˇ´ıklad DNS Staff (http://www.dnsstuff.com/products/over nebo webove´ aplikace (naprˇ´ıklad na http://www.freednsinfo.com/.
7.7.4
Bezpecˇnost v DNS
V poslednı´ dobeˇ se hodneˇ diskutuje o zabezpecˇenı´ DNS. Prˇekladu jmenne´ adresy na IP adresu obvykle veˇrˇ´ıme a mnoho uzˇivatelu˚ vu˚bec nenapadne, zˇe ve skutecˇnosti mohou komunikovat
JMENNE´ A ADRESA´RˇOVE´ SLUZˇBY
7.7
169
s protistranou s jinou IP adresou, nezˇ kterou prˇedpokla´dajı´. Du˚sledkem napadenı´ DNS mu˚zˇe by´t naprˇ´ıklad provedenı´ u´toku Man-in-the-Middle, prˇesmeˇrova´nı´ na napadeny´ server za u´cˇelem sˇ´ırˇenı´ sˇkodlive´ho ko´du, odposlechnutı´ hesla, cˇ´ısla karty apod. V ra´mci zabezpecˇenı´ DNS je tedy trˇeba zajistit, aby DNS pakety s informacı´ o prˇekladu nemohly by´t podvrzˇeny. Je to vpodstateˇ obdoba mechanismu SEND, ktery´ zabezpecˇuje ARP. DNSSEC (DNS Security Extensions) je bezpecˇnostnı´ rozsˇ´ırˇenı´ syste´mu DNS umozˇnˇujı´cı´ DNS klientovi oveˇrˇit pu˚vod dat (zda pocha´zejı´ od spra´vne´ho DNS serveru). Prˇi pouzˇitı´ DNSSEC se pouzˇ´ıva´ asymetricke´ sˇifrova´nı´ na´sledovneˇ: • provozovatel DNS dome´ny vygeneruje dvojici klı´cˇu˚ (soukromy´ a verˇejny´ klı´cˇ), • verˇejny´ klı´cˇ ulozˇ´ı u nadrˇazene´ autority sve´ dome´ny (vytva´rˇ´ı se jaka´si hierarchie du˚veˇry), • soukromy´m klı´cˇem sˇifruje DNS server pakety, ktere´ odesı´la´, • prˇ´ıjemce (DNS klient, resolver) je desˇifruje verˇejny´m klı´cˇem, ktery´ zı´skal od nadrˇazene´ autority DNS serveru. Jedna´ se vlastneˇ o elektronicky podepsane´ DNS pakety. Take´ spra´vce cˇeske´ TLD dome´ny na svy´ch DNS serverech pouzˇ´ıva´ DNSSEC, prˇicˇemzˇ jeho nadrˇazenou autoritou (a mı´stem, kde je prˇ´ıslusˇny´ verˇejny´ klı´cˇ) je spra´vce celosveˇtove´ sı´teˇ DNS serveru˚. Nadrˇ´ızena´ autorita rucˇ´ı za spra´vnost prˇekladu svy´ch bezprostrˇednı´ch podrˇ´ızeny´ch. Dalsˇı´ 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 U Najdeˇte v prˇ´ıloze prˇ´ıkazy pro prˇeklad na´zvu˚ pro Windows nebo Linux, podle syste´mu, na ktere´m pracujete. Vyzkousˇejte uka´zky, ktere´ v prˇ´ıloze najdete.
7.7.5
Adresa´rˇove´ sluzˇby a Active Directory
Pod pojmem adresa´rˇ rozumı´me databa´zi, ktera´ je organizova´na hierarchicky. Zatı´mco u jmenny´ch sluzˇeb jde prˇedevsˇ´ım o prˇeklad na´zvu˚ na cˇ´ısla a hierarchie jmen je udrzˇova´na za u´cˇelem fungova´nı´ tohoto prˇekladu, u adresa´rˇovy´ch sluzˇeb je pra´veˇ adresa´rˇ to hlavnı´ a cela´ funkcionalita spocˇ´ıva´ v pra´ci s adresa´rˇem a rˇ´ızenı´ prˇ´ıstupu k neˇmu. Adresa´rˇova´ sluzˇba je autentizacˇnı´ autorita (tak jako naprˇ´ıklad RADIUS server nebo ve Windows LSA).
P
7.7
JMENNE´ A ADRESA´RˇOVE´ SLUZˇBY
170
Standardem pro adresa´rˇove´ sluzˇby je X.500, protokol DAP (Directory Access Protocol). Tento standard je vsˇak prˇ´ılisˇ obsa´hly´, a proto jej prakticky zˇa´dna´ funkcˇnı´ adresa´rˇova´ sluzˇba neimplementuje cely´. Veˇtsˇina adresa´rˇovy´ch sluzˇeb je postavena na protokolu LDAP (Lightweight Directory Access Protocol). Jde o aplikacˇnı´ protokol pracujı´cı´ nad TCP/IP. V na´zvu ma´ lightweight (odlehcˇeny´), protozˇe jde o zjednodusˇenı´ protokolu˚, ktere´ se pro tyto u´cˇely pouzˇ´ıvaly pu˚vodneˇ (X.500 zahrnujı´cı´ DAP, DSP a dalsˇ´ı). Du˚lezˇitou vlastnostı´, ktera´ zajisˇt’uje snadnou prˇenositelnost, je komunikace mezi uzly prˇes protokoly rodiny TCP/IP. Active Directory je implementace protokolu LDAP pro Windows od verze 2000. Je za´visla´ na DNS (mu˚zˇeme ji cha´pat jako na´stavbu nad dome´nami DNS), naprˇ´ıklad prˇejı´ma´ na´zvy dome´n DNS a vyuzˇ´ıva´ DNS prˇi vyhleda´va´nı´ v dome´na´ch. V loka´lnı´ sı´ti musı´ existovat alesponˇ jeden server DNS, na klientsky´ch pocˇ´ıtacˇ´ıch musı´ by´t nakonfigurova´n klient DNS trˇeba prˇes DHCP. Dome´ny Active Directory vsˇak nejsou totozˇne´ s dome´nami DNS, i kdyby meˇly stejny´ na´zev, jsou jinak reprezentova´ny, ukla´dajı´ se jine´ typy informacı´. Pouzˇ´ıva´me tyto pojmy: • adresa´rˇova´ databa´ze (adresa´rˇ) je databa´ze objektu˚, ktere´ jsou v syste´mu spravova´ny, je hierarchicky usporˇa´dana´ (takzˇe adresa´rˇ je vlastneˇ o objektech a vztazı´ch mezi nimi, to vsˇe je ulozˇeno v souborech),
P
P
• objekty mohou by´t naprˇ´ıklad uzˇivatele´, skupiny, pocˇ´ıtacˇe, dome´ny, apod., kazˇdy´ objekt ma´ sve´ vlastnosti (naprˇ´ıklad prˇ´ıstupova´ pra´va), tyto vlastnosti se v hierarchicke´ strukturˇe mohou deˇdit, • kontejner je objekt, ktery´ mu˚zˇe obsahovat dalsˇ´ı objekty (obdoba slozˇek na disku), • AD sche´ma popisuje objekty, ktere´ mohou by´t ulozˇeny v adresa´rˇi Active Directory (jake´ mohou mı´t atributy, co v nich mu˚zˇe by´t ulozˇeno, obdoba trˇ´ıdy), • dome´na je skupina pocˇ´ıtacˇu˚ sdı´lejı´cı´ch spolecˇnou adresa´rˇovou databa´zi, • organizacˇnı´ jednotka (OU) je podskupina dome´ny (ale ne jake´koliv) oddeˇlena´ za urcˇity´m u´cˇelem (naprˇ´ıklad firma mu˚zˇe mı´t jedinou dome´nu a tu rozcˇlenı´ na organizacˇnı´ jednotky podle svy´ch oddeˇlenı´). OU mohou by´t i vnorˇene´. V sı´ti je Active Directory provozova´n na dome´novy´ch rˇadicˇ´ıch (domain controller, vpodstateˇ jde o dome´nove´ servery), musı´ existovat alesponˇ jeden (prima´rnı´ rˇadicˇ dome´ny) a prˇ´ıpadneˇ dalsˇ´ı (ale za´lezˇ´ı na konkre´tnı´ verzi Windows, neˇktere´ verze majı´ s dalsˇ´ımi rˇadicˇi trochu proble´m). V kazˇde´ sı´ti je nejme´neˇ jeden Globa´lnı´ katalog (prvnı´ globa´lnı´ katalog se vytvorˇ´ı na prima´rnı´m rˇadicˇi dome´ny). V Globa´lnı´m katalogu jsou prˇedevsˇ´ım souhrny informacı´ obsazˇeny´ch v dalsˇ´ıch dome´novy´ch serverech sı´teˇ (ne vsˇechny parametry, jen nejdu˚lezˇiteˇjsˇ´ı), hovorˇ´ıme take´ o replikaci (dynamicke´m vytva´rˇenı´ kopiı´). Globa´lnı´ katalogy slouzˇ´ı prˇi vyhleda´va´nı´ informacı´ v sı´ti a take´ k autentizaci (uzˇivatel se vlastneˇ z technicke´ho hlediska prˇihlasˇuje ke globa´lnı´mu katalogu) a autorizaci. Takzˇe prˇes dome´nove´ rˇadicˇe s globa´lnı´mi katalogy prˇistupujeme k objektu˚m a take´ se na nich prova´dı´ autentizace (kontrola prˇi prˇihlasˇova´nı´) a autorizace (prˇi prˇ´ıstupu k objektu˚m).
P P
JMENNE´ A ADRESA´RˇOVE´ SLUZˇBY
7.7
V Active Directory (take´ ve jmenny´ch sluzˇba´ch vcˇetneˇ DNS) se pouzˇ´ıva´ neˇkolik druhu˚ na´zvu˚ podle typu zanorˇenı´ v dome´na´ch. Jsou to prˇedevsˇ´ım Domain Component (DC, uzel dome´ny), Organization Unit (OU, organizacˇnı´ jednotka, to je Active Directory Container, obdoba slozˇky) a Common Name (CN, objekt). Adresace (popis cesty k objektu) podle struktury na obra´zku 7.6 je cn=novak,ou=zamestnanci,dc=firma,dc=cz
Tento zpu˚sob adresace objektu se oznacˇuje DN (Distinguished Name). Dalsˇ´ı zpu˚sob adresace, UNC, zna´me z DNS na´zvu˚:
171
dc=firma,dc=cz
ou=pocitace
ou=zamestnanci
P
cn=novak
Obra´zek 7.6: Na´zvy v dome´na´ch
firma.cz/zamestnanci/novak
Existujı´ i dalsˇ´ı zpu˚soby adresace, prˇedevsˇ´ım RFC 822 (forma silneˇ prˇipomı´najı´cı´ e-mail) a na´zvy LDAP (ve formeˇ ldap://uncdomeny/CN=....,OU=....). Na desktopu obvykle sluzˇba Active Directory nenı´ nainstalova´na, pracujeme zde pouze se za´sadami8 (politikami), a to v na´strojı´ch Mı´stnı´ za´sady zabezpecˇenı´ a Za´sady skupiny (Group Policies Editor gpedit.msc). V sı´ti se zprovozneˇny´m Active Directory jsou za´sady skupiny napojeny na Active Directory. Dnes jsou beˇzˇne´ heterogennı´ sı´teˇ (tj. na pocˇ´ıtacˇ´ıch v sı´ti jsou ru˚zne´ typy operacˇnı´ch syste´mu˚. Mu˚zˇe se zda´t, zˇe pouzˇ´ıva´nı´ mechanismu Active Directory v heterogennı´ sı´ti je proble´m, ale rˇesˇenı´ existuje, spocˇ´ıva´ v pouzˇitı´ jaky´chsi „prˇekladatelu˚“ – protokolu˚, ktere´ zprostrˇedkujı´ komunikaci mezi pocˇ´ıtacˇi s ru˚zny´mi operacˇnı´mi syste´my. V prˇ´ıpadeˇ pouzˇitı´ Active Directory jde prˇedevsˇ´ım o protokol LDAP implementovany´ take´ na jiny´ch operacˇnı´ch syste´mech vcˇetneˇ Linuxu, da´le pro prˇ´ıstup k datu˚m se pouzˇ´ıva´ protokol SMB. Dalsˇı´ 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 za´sada (politika, policy) obvykle rozumı´me konkre´tnı´ nastavenı´ (obvyke ty´kajı´cı´ se zabezpecˇenı´) pro danou komponentu cˇi vlastnost.
O
Kapitola
8
Bezpecˇnost a spra´va sı´tı´ 8.1 8.1.1
Bezpecˇnost v sı´tı´ch Typy u´toku˚
V pocˇ´ıtacˇove´ sı´ti je trˇeba cˇelit ru˚zny´m typu˚m u´toku˚, z nichzˇ neˇktere´ jsou vza´jemneˇ prova´za´ny. Te´to problematice jsme se veˇnovali v prˇedmeˇtech Praktikum z operacˇnı´ch syste´mu˚ a Operacˇnı´ syste´my, tedy jen strucˇneˇ. Prˇedevsˇ´ım na´s zajı´majı´ tyto u´toky: Mapping (mapova´nı´) – jde vlastneˇ o jakousi prˇ´ıpravu k na´sledujı´cı´m u´toku˚m. Hacker zı´ska´va´ co nejvı´c informacı´, aby vlastnı´ u´tok mohl by´t co neju´speˇsˇneˇjsˇ´ı. Network sniffing (nasloucha´nı´ na sı´ti) – packet sniffer (zachyta´vacˇ nebo odposloucha´vacˇ paketu˚) odklonı´ provoz na sı´ti, zachyta´va´ pakety a zı´ska´va´ z nich informace (pak je posı´la´ da´l k cı´li, nedorucˇene´ pakety by znamenaly jeho odhalenı´). ´ cˇelem sniffingu je prˇedevsˇ´ım zı´ska´vat hesla prˇena´sˇena´ v textove´m tvaru a take´ dalsˇ´ı citlive´ U
P P
informace. Take´ je mozˇne´ zachyta´vat a pozmeˇnˇovat obsah paketu˚ a nebo dokonce cˇ´ıst a pozmeˇnˇovat informace na uzlech v sı´ti (vcˇetneˇ konfiguracˇnı´ch souboru˚ nebo hesel). ´ cˇinnou obranou je prˇedevsˇ´ım spolehlive´ sˇifrova´nı´ (vcˇetneˇ autentizace po sı´ti), a take´ fyzicke´ U zabezpecˇenı´ sı´teˇ, protozˇe tento typ u´toku vyzˇaduje fyzicky´ prˇ´ıstup k sı´ti. To mu˚zˇe by´t proble´m u bezdra´tovy´ch typu˚ prˇipojenı´. Packet sniffer vsˇak mu˚zˇe by´t zcela lega´lneˇ vyuzˇ´ıva´n administra´torem ke sledova´nı´ provozu na sı´ti. IP Spoofing – podvrhnutı´ IP adresy. Komunikujı´cı´ uzel prˇedstı´ra´, zˇe je vlastnı´kem IP adresy, ktera´ ve skutecˇnosti patrˇ´ı jine´mu uzlu (nebo nepatrˇ´ı zˇa´dne´mu uzlu). Obvykle jde o prˇ´ıpad, kdy se u´tocˇnı´k snazˇ´ı prˇedstı´rat, zˇe je rˇa´dny´m cˇlenem priva´tnı´ sı´teˇ pouzˇ´ıvajı´cı´ urcˇity´ rozsah IP adres, prˇ´ıpadneˇ se pokousˇ´ı vyda´vat za konkre´tnı´ uzel v sı´ti. Cˇasty´m zpu˚sobem pouzˇitı´ je zneuzˇitı´ neˇktery´ch protokolu˚, vcˇetneˇ protokolu SMTP pro odesı´la´nı´ e-mailu˚. Tento u´tok spocˇ´ıva´ naprˇ´ıklad ve zmeˇneˇ smeˇrovacı´ch tabulek na routerech v sı´ti. Obranou je tedy prˇedevsˇ´ım zabezpecˇenı´ routeru˚ a bezpecˇna´ implementace smeˇrovacı´ch algoritmu˚. 172
P
8.1
BEZPECˇNOST V SI´TI´CH
173
DoS (Denial of Service) – odmı´tnutı´ sluzˇby. Jde o vynucenı´ odmı´tnutı´ sluzˇby legitimnı´m uzˇivatelu˚m. Tento u´tok probı´ha´ bud’ vyuzˇitı´m chyby v ko´du (neˇktere´ho protokolu nebo operacˇnı´ho syste´mu), vyvolany´m prˇetı´zˇenı´m sı´teˇ nebo podvrzˇeny´mi zpra´vami – pakety o stavu sı´teˇ. Server je zahlcen zˇa´dostmi o spojenı´ (TCP handshake) nebo zˇa´dostmi o data, ktere´ nenı´ schopen vyrˇ´ıdit, a proto i na´sledny´ provoz je zadrzˇen. DDoS (Distributed DoS) – velmi nebezpecˇna´ varianta prˇedchozı´ho typu u´toku, proti ktere´ se te´meˇrˇ nelze bra´nit. Cˇasty´m nedobrovolny´m „u´cˇasnı´kem“ DDoS u´toku˚ jsou sı´teˇ botu˚. Bot je napadeny´ pocˇ´ıtacˇ ovla´dany´ na da´lku hackerem (bez dovolenı´ a veˇtsˇinou take´ bez veˇdomı´ pra´voplatne´ho majitele). Sı´teˇ botu˚, a to i velmi rozsa´hle´ (resp. jejich sluzˇby), jsou „proda´va´ny“ na cˇerne´m trhu kromeˇ jine´ho pra´veˇ k DDoS u´toku˚m. Hijacking (u´nos spojenı´) – jde prˇedevsˇ´ım o u´toky souvisejı´cı´ s vyta´cˇeny´m spojenı´m, ale take´ obecneˇ s jaky´mkoliv placeny´m spojenı´m vyzˇadujı´cı´m autentizaci (naprˇ´ıklad soukrome´ Wi-Fi sı´teˇ). ´ cˇinnou obranou je pouzˇitı´ vhodne´ho sˇifrovacı´ho algoritmu prˇi autentizaci. U ´ toky na zjisˇteˇnı´ hesla – heslo lze zjistit naprˇ´ıklad brute-force u´tokem (hruba´ sı´la), pouzˇitı´m U trojske´ho koneˇ a neˇktery´mi vy´sˇe popsany´mi metodami. Dalsˇ´ı mozˇnostı´ je socia´lnı´ inzˇeny´rstvı´, ktere´ je v soucˇasne´ dobeˇ na vzestupu (uzˇivatel defacto tento u´daj prozradı´ sa´m a dobrovolneˇ, je z neˇho podvodneˇ vyla´ka´n).
P P P P
Brute-force u´tok je veˇtsˇinou veden jako slovnı´kovy´, tj. automaticky jsou zkousˇeny vsˇechny rˇeteˇzce z vytvorˇene´ho slovnı´ku (nemusı´ jı´t jen o anglicka´ slova!), proti cˇemuzˇ se lze bra´nit nastavenı´m maxima´lnı´ho pocˇtu neu´speˇsˇny´ch prˇihla´sˇenı´, po prˇekrocˇenı´ tohoto limitu je prˇ´ıstup zcela zablokova´n. Da´le je mozˇne´ po uzˇivatelı´ch vyzˇadovat pouzˇ´ıva´nı´ tzv. „silne´ho“ hesla (dostatecˇneˇ dlouhe´ho, obsahujı´cı´ho jak pı´smena, tak i cˇ´ıslice a dalsˇ´ı znaky – dvojtecˇka, procento, zavina´cˇ, apod.), s cˇ´ımzˇ ale by´vajı´ proble´my (uzˇivatele´ radeˇji volı´ takove´ heslo, ktere´ si doka´zˇou zapamatovat). Take´ je trˇeba si uveˇdomit, zˇe mnoha´ zarˇ´ızenı´ (routery, modemy, apod.) majı´ heslo administra´tora prˇednastaveno na hodnotu, ktera´ je vsˇeobecneˇ zna´ma´ (zjistitelna´). Proto prˇi instalaci podobny´ch zarˇ´ızenı´ do sı´teˇ je nutne´ zmeˇnit heslo administra´tora. Prˇenosy citlivy´ch informacı´ – zvla´sˇteˇ firemnı´ sı´teˇ by meˇly by´t dobrˇe zabezpecˇeny. Pokud zameˇstnanec prˇistupuje k firemnı´ sı´ti externeˇ (naprˇ´ıklad na pracovnı´ cesteˇ, tj. z jine´ LAN, resp. pocˇ´ıtacˇ nenı´ prˇ´ımo prˇipojen do LAN), meˇlo by by´t spojenı´ zabezpecˇene´ – virtua´lnı´ priva´tnı´ sı´t’(VPN), vytva´rˇ´ı se tzv. tunel, data vcˇetneˇ autentizace se prˇena´sˇejı´ v sˇifrovane´ podobeˇ. Kromeˇ drˇ´ıve zmı´neˇny´ch protokolu˚ se pouzˇ´ıva´ protokol IPSec. Man-in-the-Middle – hacker se dostane mezi dva komunikujı´cı´ pocˇ´ıtacˇe a odposloucha´va´ nebo dokonce pozmeˇnˇuje komunikaci mezi nimi. Tento typ u´toku souvisı´ s neˇktery´mi prˇedchozı´mi – u´nos spojenı´, zjisˇt’ova´nı´ hesla apod. Lidsky´ faktor – „neprˇ´ıtel“ mu˚zˇe by´t i uvnitrˇ sı´teˇ, a to dokonce i takovy´, ktery´ to o sobeˇ netusˇ´ı. Zvla´sˇteˇ v poslednı´ dobeˇ jsou pro u´toky cˇasto voleny metody socia´lnı´ho inzˇeny´rstvı´. Socia´lnı´ inzˇeny´rstvı´ je metoda, jak z uzˇivatele vyta´hnout potrˇebne´ informace trˇeba i bez pouzˇitı´ techniky, a to jeho uvedenı´m v omyl (obelsteˇnı´m). Uzˇivatel je prˇesveˇdcˇen, zˇe informace prˇeda´va´ du˚veˇryhodne´ osobeˇ z naprosto nutny´ch du˚vodu˚.
P P P
BEZPECˇNOST V SI´TI´CH
8.1
174
´ tocˇnı´k se vyda´va´ naprˇ´ıklad za zameˇstnance bezpecˇnostnı´ho oddeˇlenı´, oprava´rˇe, zameˇstnance U telefonnı´ spolecˇnosti, nove´ho kolegu, apod. a nena´padneˇ ze svy´ch obeˇtı´ vyta´hne vsˇe potrˇebne´ (hlavneˇ hesla), prˇ´ıpadneˇ si „vyzkousˇ´ı“ novy´ skveˇly´ pocˇ´ıtacˇ nebo se jinak dostane k technice na pracovisˇti. Sta´va´ se to prˇedevsˇ´ım ve veˇtsˇ´ıch firma´ch, kde se nepocˇ´ıta´ s tı´m, zˇe by se vsˇichni zameˇstnanci znali, ale kontakt mu˚zˇe probı´hat i „neosobneˇ“ prˇes telefon nebo mail. Pra´veˇ do telefonu jsou zameˇstnanci schopni rˇ´ıci o sve´ firmeˇ neuveˇrˇitelne´ veˇci vcˇetneˇ teˇch, ktere´ jsou obchodnı´m tajemstvı´m. Socia´lnı´ inzˇeny´rstvı´ mu˚zˇe mı´t i „materia´lnı´“ povahu – naprˇ´ıklad volneˇ „pohozena´“ prˇenosna´ zarˇ´ızenı´, ktera´ jsou pro mnoho lidı´ neodolatelna´. Podle DHS1 je kolem 60 % beˇzˇny´ch uzˇivatelu˚ schopno na´hodneˇ nalezeny´ USB flash disk prˇipojit ke sve´mu pocˇ´ıtacˇi, trˇebazˇe netusˇ´ı, zda se na neˇm nenacha´zı´ sˇkodlivy´ software. Podobneˇ lze zneuzˇ´ıt i jina´ prˇenosna´ zarˇ´ızenı´, zde je nejlepsˇ´ı ochranou poctivost, tedy odevzdat nalezeny´ prˇedmeˇt do ztra´t a na´lezu˚. Socia´lnı´ inzˇeny´rstvı´ je v soucˇasne´ dobeˇ jedna z nejpouzˇ´ıvaneˇjsˇ´ıch (a taky nejefektivneˇjsˇ´ıch) metod zı´ska´va´nı´ utajeny´ch informacı´. Na to by meˇli myslet zejme´na administra´torˇi firemnı´ch sı´tı´ a zajistit patrˇicˇne´ sˇkolenı´ vsˇech, kdo se do firemnı´ sı´teˇ prˇipojujı´.
L
Jak se bra´nit? • Neveˇrˇit vsˇemu, co kdo povı´da´. Zvla´sˇteˇ kdyzˇ jsem naprˇ´ıklad administra´tor firemnı´ sı´teˇ, musı´m si vsˇe oveˇrˇovat (totozˇnost zˇadatele o nove´ heslo po jeho zapomenutı´, nutnost provedenı´ pozˇadovane´ho za´sahu do syste´mu, apod.). • Heslo cˇi jine´ podobne´ u´daje si nenecha´va´me na papı´rku prˇilepene´m k monitoru (nebo na jiny´ch „obvykly´ch“ mı´stech). Volı´me silna´ hesla. • Kazˇdy´ syste´m zabezpecˇeny´ heslem (vcˇetneˇ operacˇnı´ch syste´mu˚) lze nastavit tak, aby po stanovene´m pocˇtu chybny´ch pokusu˚ o prˇihla´sˇenı´ byl u´cˇet zablokova´n. • Banky ani jine´ instituce nechteˇjı´ po svy´ch zameˇstnancı´ch zası´la´nı´ hesel, certifika´tu˚, TAN, cˇ´ısla kreditnı´ karty a podobny´ch u´daju˚ mailem ani zˇa´dny´m jiny´m nezapezpecˇeny´m zpu˚sobem (jen prˇes zabezpecˇene´ stra´nky prˇ´ımo prˇi prˇihlasˇova´nı´). A rozhodneˇ o neˇ nezˇa´dajı´ mailem ani telefonem. • Spra´vce sı´teˇ by meˇl mı´t kazˇdou zˇa´dost o za´sah do u´cˇtu˚ zameˇstnancu˚ nebo syste´mu vzˇdy „papı´roveˇ“ podlozˇenou. ´ tocˇnı´ci pouzˇ´ıvajı´cı´ socia´lnı´ inzˇeny´rstvı´ deˇlajı´ „doma´cı´ u´koly“ – sha´neˇjı´ co nejvı´c informacı´ • U (vcˇetneˇ osobnı´ch), ktere´ by mohli vyuzˇ´ıt. Firma by meˇla zva´zˇit, co zverˇejnı´ (a tote´zˇ platı´ i o doma´cı´ch uzˇivatelı´ch, take´ naprˇ´ıklad na diskusnı´ch fo´rech a socia´lnı´ch sı´tı´ch). Skartovacˇka nenı´ zbytecˇne´ zarˇ´ızenı´. Du˚lezˇity´m pojmem v bezpecˇnosti je FIRST (Forum of Incident Response and Security Teams). Jedna´ se o seskupenı´ bezpecˇnostnı´ch ty´mu˚ reagujı´cı´ch na ru˚zne´ hrozby a bezpecˇnostnı´ incidenty. FIRST se take´ podı´lı´ na udrzˇova´nı´ standardu CVSS (Common Vulnerability Scoring System – spolecˇny´ syste´m pro hodnocenı´ zranitelnostı´). Informace najdeme na http://www.first.org/cvss/. 1
DHS (Department of Homeland Security, http://www.dhs.gov)
P
SI´TˇOVY´ ANALYZA´TOR
8.2
8.1.2
175
Zabezpecˇenı´ na jednotlivy´ch vrstva´ch ISO/OSI
Na ktere´koliv vrstveˇ lze sˇifrovat data. V ISO/OSI modelu se prˇi toku dat smeˇrem dolu˚ sˇifrujı´ vesˇkera´ data vysˇsˇ´ı vrstvy, tj. vcˇetneˇ za´hlavı´. Da´le: 1. Na linkove´ vrstveˇ se prova´dı´ sˇifrova´nı´ podle dane´ prˇenosove´ techniky (naprˇ. dle IEEE 802.11). 2. Na sı´t’ove´ vrstveˇ se implementuje zabezpecˇenı´ spojenı´ mezi dveˇma uzly vcˇetneˇ vytvorˇenı´ tunelu prˇi VPN spojenı´ (protokol IPSec). 3. Na transportnı´ vrstveˇ pracuje SSL. 4. Na aplikacˇnı´ vrstveˇ se pouzˇ´ıvajı´ klı´cˇe vcˇetneˇ PGP.
8.2
Sı´t’ovy´ analyza´tor
Sı´t’ovy´ analyza´tor je zarˇ´ızenı´, ktere´ se prˇipojuje mezi neˇktery´ prvek sı´teˇ (PC, server, most, router, atd.) a LAN, take´ mu˚zˇe by´t soucˇa´stı´ jine´ho zarˇ´ızenı´. Samostatny´ sı´t’ovy´ analyza´tor (prˇenosny´) mu˚zˇe by´t i velmi maly´, mu˚zˇe prˇipomı´nat mobilnı´ telefon.
P
Obra´zek 8.1: Sı´t’ove´ analyza´tory2 Pracuje na fyzicke´ nebo vysˇsˇ´ıch vrstva´ch, na tom za´lezˇ´ı, ktere´ charakteristiky doka´zˇe sledovat. Na fyzicke´ vrstveˇ prˇedevsˇ´ım stav me´dia, provoz (zatı´zˇenı´), doka´zˇe generovat vlastnı´ provoz, na vysˇsˇ´ıch vrstva´ch mu˚zˇe podporovat take´ virtua´lnı´ sı´teˇ, sledova´nı´ stavu dostupny´ch uzlu˚ sı´teˇ, sledova´nı´ ra´mcu˚, prˇ´ıp. paketu˚, atd. Sı´t’ovy´ analyza´tor „dosa´hne“ pouze tam, odkud se k neˇmu dostanou data. U uzlu sı´teˇ je tedy omezen na jedinou koliznı´ dome´nu (tj. k nejblizˇsˇ´ımu prˇepı´nacˇi nebo smeˇrovacˇi). Proto by´va´ vhodne´ umı´stit sı´t’ovy´ analyza´tor na takovy´ uzel sı´teˇ, ktery´ se vyskytuje ve vı´ce koliznı´ch dome´na´ch, naprˇ´ıklad pra´veˇ smeˇrovacˇ. Prˇehled neˇktery´ch sı´t’ovy´ch analyza´toru˚ najdeme naprˇ´ıklad na http://www.fluketestery.cz/produkty-sitove-analyzatory.html. Hardware of firmy Fluke
je v te´to oblasti vsˇeobecneˇ zna´m. Nejpouzˇ´ıvaneˇjsˇ´ı prˇ´ıstroje:
• LinkRunner – pracuje na fyzicke´ vrstveˇ, identifikace vlastnostı´ Ethernetove´ho spojenı´ – negociace (10/100/1000 Mb, duplex apod.), detekce poruch kabelu˚ vcˇetneˇ vzda´lenosti k porusˇe, za´suvek, provoz na segmentu, atd. 2
Zdroj: http://www.fluketestery.cz/
P
8.3
FIREWALL
176
• NetTool – sı´t’ova´ vrstva, testy na fyzicke´ vrstveˇ (kabela´zˇ, negociace, vyuzˇ´ıva´nı´ segmentu), spojove´ (detekce kolizı´ a chybovy´ch ra´mcu˚, VLAN, vyhleda´va´nı´ MAC adres v sı´ti, apod.), sı´t’ove´ (vyhleda´va´nı´ IP adres v sı´ti, podsı´tı´, routeru˚ a dalsˇ´ıch zdroju˚, ping, atd.), meˇrˇenı´ PoE, monitoring parametru˚ VoIP, atd. • AirCheck – analy´za Wi-fi sı´teˇ 802.11a/b/g/n Hardware of firmy Embedded Technologies obsahuje obvykle vlastnı´ variantu embedded Linuxu (tj. Linuxu upravene´ho pro specia´lnı´ u´cˇely, zde pro sı´t’ova´ zarˇ´ızenı´) za´rovenˇ s dalsˇ´ım potrˇebny´m softwarem. Naprˇ´ıklad:
P
• Sı´t’ovy´ analyza´tor – vestaveˇny´ sniffer Wireshark, NAT, firewall, atd. • Diagnosticky´ switch pro Ethernet Neˇco podobne´ho si lze vytvorˇit vlastnorucˇneˇ ze starsˇ´ıho (nadbytecˇne´ho) pocˇ´ıtacˇe s potrˇebny´m mnozˇstvı´m hardwarovy´ch rozhranı´, distribuce embedded Linuxu jsou dostupne´ na Internetu. Softwarove´ sı´t’ove´ analyza´tory: Sı´t’ove´ analyza´tory mohou by´t take´ softwarove´ – sledujı´ a prˇ´ıpadneˇ ovlivnˇujı´ sı´t’ovy´ provoz souvisejı´cı´ s pocˇ´ıtacˇem, na ktere´m jsou nainstalova´ny (idea´lneˇ server, ale mu˚zˇe to by´t ktery´koliv pocˇ´ıtacˇ v sı´ti). Asi nejzna´meˇjsˇ´ı softwarovy´ sı´t’ovy´ analyza´tor je Wireshark (drˇ´ıve se nazy´val Ethereal) dostupny´ na http://www.wireshark.org/.
P
Diagnostika bezdra´tovy´ch sı´tı´ byla probı´ra´na v kapitole 6.2.4 (str. 124) pro fyzickou vrstvu, v kapitole 6.2.6 (str. 129) pro MAC podvrstvu. Dalsˇ´ı informace o sı´t’ovy´ch analyza´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’ovy´ prvek (hardwarovy´ nebo softwarovy´), ktery´ slouzˇ´ı k rˇ´ızenı´ provozu mezi sı´teˇmi s ru˚znou u´rovnı´ du˚veˇryhodnosti cˇi zabezpecˇenı´. Ve firewallu jsou definova´na pravidla pro komunikaci mezi sı´teˇmi, podle ktery´ch reaguje bud’ povolenı´m komunikace, jejı´m zaka´za´nı´m a nebo zˇa´dostı´ o vyja´drˇenı´ uzˇivatele. Pravidla se obvykle ty´kajı´ teˇchto u´daju˚: • zdroj a cı´l komunikace, mu˚zˇe by´t zada´n IP adresou, • cˇ´ıslo portu, prˇes ktery´ se komunikuje (tj. mu˚zˇeme zablokovat pouzˇ´ıva´nı´ neˇktere´ho portu), mu˚zˇe jı´t o zdrojovy´ i cı´lovy´ port, • pouzˇ´ıvany´ protokol, • stav spojenı´, atd.
P
8.3
FIREWALL
177
Firewall mu˚zˇe by´t bud’ jen jednosmeˇrny´ (filtruje pouze prˇ´ıchozı´ pakety) nebo obousmeˇrny´ (filtruje prˇ´ıchozı´ i odchozı´ pakety). Lepsˇ´ı je samozrˇejmeˇ obousmeˇrny´, doka´zˇe efektivneˇji zachytit prˇ´ıpadne´ vyna´sˇenı´ citlivy´ch informacı´. Kromeˇ softwarovy´ch firewallu˚ existujı´ take´ hardwarove´ firewally fungujı´cı´ jako mezilehle´ prvky sı´teˇ. Dnes jsou veˇtsˇinou soucˇa´stı´ smeˇrovacˇu˚ (routeru˚) nebo jiny´ch beˇzˇny´ch sı´t’ovy´ch prvku˚ (na typu zarˇ´ızenı´ za´visı´, k jaky´m informacı´m se firewall dostane). Hardwarovy´ firewall ma´ velkou vy´hodu v nizˇsˇ´ım riziku napadenı´ (nenı´ za´visly´ na operacˇnı´m syste´mu klientske´ho pocˇ´ıtacˇe). Dalsˇ´ı vy´hodou je neza´vislost na vy´konu pocˇ´ıtacˇe – pokud je procesor pocˇ´ıtacˇe hodneˇ zatı´zˇen, ma´ to vliv i na cˇinnost (prˇedevsˇ´ım rychlost) softwarove´ho firewallu na tomto pocˇ´ıtacˇi nainstalovane´ho. Hardwarovy´ firewall (trˇeba vestaveˇny´ v jine´m sı´t’ove´m zarˇ´ızenı´) takto ovlivneˇn nenı´. Z hlediska bezpecˇnosti je v doma´cnostech a mensˇ´ıch firma´ch za idea´lnı´ povazˇova´na kombinace jednoduche´ho hardwarove´ho firewallu ve smeˇrovacˇi (naprˇ´ıklad ADSL router) a softwarove´ho routeru na pocˇ´ıtacˇi, jazˇdy´ z nich jine´ho typu. Softwarove´ firewally slouzˇ´ı bud’ k ochraneˇ koncovy´ch uzlu˚, a nebo mohou beˇzˇet v operacˇnı´m syste´mu nainstalovane´m na (te´meˇrˇ) jake´mkoliv sı´t’ove´m prvku. Oblasti podle firewallu.
Z pohledu firewallu cˇlenı´me sı´t’do neˇkolika oblastı´:
• vnitrˇnı´ sı´t’ – do te´to oblasti patrˇ´ı vsˇe, co je „nasˇe“, cˇemu mu˚zˇeme du˚veˇrˇovat, uzel z vnitrˇnı´ sı´teˇ mu˚zˇe (s ohledem na prˇ´ıstupova´ opra´vneˇnı´) iniciovat spojenı´ k vnitrˇnı´ i vneˇjsˇ´ı sı´ti, • vneˇjsˇ´ı sı´t’ – typicky Internet, • demilitarizovana´ zo´na (DMZ) – zo´na „nikoho“, z bezpecˇnostnı´ho hlediska neˇkde mezi vnitrˇnı´ a vneˇjsˇ´ı sı´tı´.
P
P
Do DMZ lze umı´stit naprˇ´ıklad to, co je sice „nasˇe“, ale ma´ by´t prˇ´ıstupne´ z vneˇjsˇ´ı sı´teˇ (naprˇ´ıklad web server, mail server, DNS server). Servery v DMZ by meˇly by´t zabezpecˇeny tak, jako by byly opravdu prˇ´ımo na Internetu, trˇebazˇe jsou od Internetu oddeˇleny firewallem. Dalsˇ´ı mozˇnost vyuzˇitı´ DMZ je propojenı´ k trˇetı´ straneˇ, ktere´ vı´ceme´neˇ du˚veˇrˇujeme, typicky dodavateli sluzˇby, kterou si nemu˚zˇeme zajistit vlastnı´mi silami. Obeˇ mozˇnosti mu˚zˇeme zkombinovat a pouzˇ´ıvat dveˇ demilitarizovane´ zo´ny (nebo vı´ce). Na sı´t’ove´m zarˇ´ızenı´ podporujı´cı´m DMZ ma´me obvykle jeden nebo vı´ce (hardwarovy´ch!) portu˚ takto oznacˇeny´ch, prˇ´ıpadneˇ mu˚zˇeme neˇktere´ porty sami nakonfigurovat tak, aby se s nimi zacha´zelo jako s DMZ (naprˇ´ıklad tehdy, kdyzˇ chceme starsˇ´ı pocˇ´ıtacˇ vyuzˇ´ıt jako hardwarovy´ firewall, uka´zky najdeme v prˇ´ıloze). TCP/UDP porty. Beˇzˇny´ uzˇivatel si veˇtsˇinou s nastavenı´m (softwarovy´ch) portu˚ nevı´ rady (viz cˇa´st prvnı´ kapitoly veˇnovanou TCP/UDP paketu˚m). Na internetu najdeme stra´nky se seznamy zna´my´ch a registrovany´ch portu˚ pouzˇ´ıvany´ch ru˚zny´mi protokoly.3 Tyto seznamy jsou vsˇak pouzˇitelne´ pro sledova´nı´ odchozı´ho provozu nebo prˇi nastavova´nı´ portu˚ na serveru. Ve skutecˇnosti aplikace mohou pouzˇ´ıvat i jine´ porty, nezˇ ktere´ jsou beˇzˇne´ pro protokoly, se ktery´mi pracujı´. 3
Seznam portu˚ a prˇ´ıpadneˇ sluzˇeb najdeme naprˇ´ı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 cˇeske´ Wikipedii nenı´ seznam u´plny´.
$
8.3
FIREWALL
8.3.2
178
Typy filtrova´nı´
Rozlisˇujeme ru˚zne´ typy filtrova´nı´ podle toho, na kterou vrstvu ISO/OSI lze danou metodu zarˇadit (a tedy na ktere´ informace v za´hlavı´ch „dosa´hneme“). Obvykle se jedna´ prˇedevsˇ´ım o filtrova´nı´ na sı´t’ove´ vrstveˇ (L3), protozˇe tam lze pracovat s IP adresami. Paketovy´ filtr. Jedna´ se o nejjednodusˇsˇ´ı filtrova´nı´ na L3 a cˇa´stecˇneˇ L4, v pravidlech se uva´deˇjı´ jen IP adresy a cˇ´ısla portu˚. Je to jednoduche´ a rychle´ rˇesˇenı´ (provoz je zdrzˇova´n jen minima´lneˇ), ktere´ se drˇ´ıve beˇzˇneˇ uplatnˇovalo prˇedevsˇ´ım na mezilehly´ch sı´t’ovy´ch prvcı´ch (naprˇ´ıklad starsˇ´ı verze operacˇnı´ho syste´mu IOS pro smeˇrovacˇe), dnes je najdeme v neˇktery´ch nejlevneˇjsˇ´ıch smeˇrovacˇ´ıch. Nevy´hodou je neschopnost nahlı´zˇet do komunikace probı´hajı´cı´ v slozˇiteˇjsˇ´ıch protokolech. ACL na sı´t’ove´ vrstveˇ. ACL (Access Control List – seznam rˇ´ızenı´ prˇ´ıstupu, prˇ´ıstupovy´ seznam) je metoda sˇiroce pouzˇ´ıvana´ jak v desktopovy´ch a serverovy´ch operacˇnı´ch syste´mech, tak i v sı´t’o´ cˇelem je urcˇovat pravidla prˇ´ıstupu pro ru˚zne´ uzˇivatele/komunikace. Vpodstateˇ vy´ch zarˇ´ızenı´ch. U se jedna´ o funkcˇnı´ na´stavbu metody paketove´ho filtru. S ACL v operacˇnı´ch syste´mech jsme se sezna´mili v prˇedmeˇtu Operacˇnı´ syste´my (cvicˇenı´ – Windows i Linux).
P P
Prˇ´ıstupovy´ seznam je vlastneˇ seznam polozˇek v te´to formeˇ: • deny to, co nema´ projı´t • permit to, co mu˚zˇe projı´t • deny all else obvykle poslednı´ polozˇka seznamu, co nebylo zmı´neˇno, nesmı´ projı´t ACL je veˇtsˇinou implementova´n ve formeˇ „co nenı´ dovoleno, je zaka´za´no“, takzˇe najdeme spı´sˇe jen polozˇky permit (a co nenı´ v teˇchto polozˇka´ch, to neprojde). Prˇ´ıpadneˇ se mu˚zˇeme setkat s celou strukturou navza´jem prova´zany´ch ACL. Polozˇky se procha´zejı´ sekvencˇneˇ, jedna po druhe´, a hleda´ se shoda. Take´ porˇadı´ polozˇek je du˚lezˇite´. Filtruje se obvykle podle cı´love´ IP adresy, podle zdrojove´ IP adresy, podle jejich kombinace, a nebo prˇ´ıpadneˇ podle dalsˇ´ıch krite´riı´ (naprˇ´ıklad podle polozˇek v PDU sı´t’ove´ vrstvy – protokolu IP, ICMP, podle TCP/UDP portu, se ktery´m se navazuje spojenı´ ze sı´t’ove´ vrstvy, apod.). Adresa obvykle by´va´ adresou podsı´teˇ, tedy je ulozˇen prefix a jeho de´lka (resp. maska, aby bylo zrˇejme´, u kolika bitu˚ adresy se ma´ hledat shoda). Uka´zky ACL najdeme naprˇ´ı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/ Stavova´ inspekce paketu ˚. Prˇesuneme se o vrstvu vy´sˇe – na transportnı´ vrstveˇ (L4, konkre´tneˇji ted’ jsme na cele´m TCP/IP definovane´m na L3 a L4) se prova´dı´ filtrova´nı´ SPI (Statefull Packet Inspection, stavova´ inspekce paketu˚, take´ stavovy´ paketovy´ filtr). Zatı´mco na L3 se pakety berou jako „jedina´cˇci“ bez vza´jemne´ vazby, na L4 je mozˇne´ bra´t prˇi filtrova´nı´ v u´vahu jejich vza´jemne´ vztahy. naprˇ´ıklad mu˚zˇeme odlisˇit pakety, ktere´ navazujı´ spojenı´, od paketu˚, ktere´ patrˇ´ı do jizˇ existujı´cı´ho spojenı´.
P
8.3
FIREWALL
179
Paket navazujı´cı´ spojenı´ je du˚kladneˇ proveˇrˇen (u´daje z vrstev L3 a L4, naprˇ´ıklad zdrojova´ a cı´lova´ adresa, protokoly, zdrojove´ a cı´love´ porty, prˇ´ıznaky nastavene´ podle jednotlivy´ch protokolu˚, cokoliv, co je v za´hlavı´ch PDU) a pokud projde, vytvorˇ´ı se v stavove´ tabulce za´znam povolujı´cı´ dane´ spojenı´. Pokud paket kontrolou neprojde u´speˇsˇneˇ, za´znam se nevytvorˇ´ı. Pakety, ktere´ patrˇ´ı do jizˇ nava´zane´ho spojenı´ (nebo se za takove´ vyda´vajı´), se filtrujı´ podle toho, zda jejich spojenı´ je zaznamena´no ve stavove´ tabulce. Stavova´ inspekce paketu˚ se obvykle prova´dı´ na firewallu, nebo mu˚zˇe jı´t o zarˇ´ızenı´ prˇ´ımo urcˇena´ k tomuto u´cˇelu. Jako SPI zarˇ´ızenı´ mu˚zˇeme vyuzˇ´ıt take´ beˇzˇny´ pocˇ´ıtacˇ s nainstalovany´m Linuxem a jeho firewallem NetFilter (s rozhranı´m iptables), ktery´ SPI podporuje. V soucˇasne´ dobeˇ je SPI vpodstateˇ standardem kvalitnı´ch firewallu˚. Oproti beˇzˇne´mu paketove´mu filtru nabı´zı´ veˇtsˇ´ı bezpecˇnost prˇi relativneˇ male´m zpomalenı´ provozu prˇi filtrova´nı´. Pokud takovy´ firewall je soucˇa´stı´ ja´dra (rozsˇirˇujı´cı´ modul ja´dra), doka´zˇe chra´nit prˇed napadenı´m i sa´m sebe. IDS/IPS, DPI.
SPI mu˚zˇeme bra´t jako za´klad pro IDS/IPS syste´my:
1. IDS (Intrusion Detection System, syste´m pro detekci u´toku˚) – pracuje podobneˇ jako antivirus, tedy pouzˇ´ıva´
P
• signatury u´toku˚ (vede si jejich databa´zi, kterou je nutne´ aktualizovat nebo „mı´t k dispozici v cloudu“), • heuristiky (vyuzˇ´ıva´ statisticke´ metody vyhodnocujı´cı´ provoz na sı´ti) a • detekci neobvykle´ho chova´nı´ sı´teˇ (zjisˇt’ujı´ se odchylky od beˇzˇne´ho provozu na sı´ti). Detekuje pokusy o pru˚nik do syste´mu a poda´ informaci zarˇ´ızenı´, ktere´ doka´zˇe na u´tok reagovat. Detekce musı´ fungovat i prˇi rozdeˇlenı´ signatury (typicke´ho vzoru) do vı´ce paketu˚. 2. IPS (Intrusion Prevention System) – podobneˇ jako IDS prova´dı´ detekci u´toku˚, ale navı´c aktivneˇ reaguje. Reakce ma´ u´toku zabra´nit, proto take´ konkre´tnı´ mı´sto IPS sondy je trˇeba napla´novat tak, aby mohla prˇ´ıpadneˇ take´ zasahovat do konfigurace jiny´ch sı´t’ovy´ch zarˇ´ızenı´. Firewall mu˚zˇe mı´t integrovanou funkci (modul) IDS/IPS, ale obecneˇ je bezpecˇneˇjsˇ´ı (zvla´sˇteˇ u veˇtsˇ´ıch sı´tı´) nasadit IDS/IPS oddeˇleneˇ od firewallu. Setka´va´me se take´ s na´zvem Stavovy´ paketovy´ filtr s hloubkovou kontrolou (Deep Packet Inspection), to je pra´veˇ firewall s integrovany´m modulem IDS/IPS. Tento typ firewallu prˇida´va´ dalsˇ´ı mozˇnosti definova´nı´ pravidel souvisejı´cı´ s obvykly´mi vlastnostmi komunikace s danou (zna´mou) aplikacı´ cˇi protokolem. Pokud naprˇ´ıklad zjistı´, zˇe protokol http je pouzˇ´ıva´n pro jiny´ typ komunikace nezˇ s WWW server, tento pozˇadavek zablokuje jako podezrˇely´. Dalsˇ´ı 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
Obra´zek 8.2: Sche´ma mozˇne´ho zapojenı´ IDS/IPS4 Proxy na aplikacˇnı´ vrstveˇ. Posuneme se jesˇteˇ o vrstvu vy´sˇe – na aplikacˇnı´ vrstveˇ TCP/IP pracujı´ proxy firewally (take´ aplikacˇnı´ bra´ny). Pracujı´ s aplikacˇnı´mi protokoly, naprˇ´ıklad rozumı´ protokolu HTTP, FTP, IMAP, doka´zˇou pracovat s pakety obsahujı´cı´mi prvky pro ActiveX, apod.
P
Tento typ firewallu oddeˇluje sı´teˇ azˇ do te´ mı´ry, zˇe pocˇ´ıtacˇ (server) ve vneˇjsˇ´ı sı´ti nezna´ IP adresu pocˇ´ıtacˇe ve vnitrˇnı´ sı´ti, se ktery´m komunikuje (vidı´ pouze IP adresu bra´ny). Vesˇkera´ komunikace je zpracova´va´na pomocı´ tzv. proxy – softwarovy´ch bran bud’ naprogramovany´ch pro konkre´tnı´ typ komunikace (protokol) s pomeˇrneˇ vysoky´m stupneˇm zabezpecˇenı´ (naprˇ´ıklad pro protokol FTP nebo HTTP), nebo pomocı´ genericke´ proxy s u´rovnı´ bezpecˇnosti podobnou jako paketovy´ filtr. Proxy defacto zcela oddeˇluje vnitrˇnı´ a vneˇjsˇ´ı sı´t’ (v podobne´m smyslu jako NAT) a prˇi filtrova´nı´ vyuzˇ´ıva´ informace prakticky ze vsˇech vrstev TCP/IP, protozˇe prˇi „prokopa´va´nı´ “ k za´hlavı´ protokolu˚ vrstvy L7 procha´zı´ prˇes za´hlavı´ prˇedchozı´ch vrstev. Rozlisˇujeme dva typy proxy: 1. Beˇzˇny´ (standardnı´) proxy – pro neˇj platı´ vsˇe, co bylo drˇ´ıve o proxy napsa´no. Filtruje vsˇechny pakety podle u´daju˚ z PDU protokolu˚ aplikacˇnı´ vrstvy a nizˇsˇ´ıch vrstev. 2. Dynamicky´ proxy – chova´ se odlisˇneˇ k ru˚zny´m paketu˚m; k zahajujı´cı´m spojenı´ se chova´ stejneˇ jako prvnı´ typ proxy, ale k paketu˚m patrˇ´ıcı´m do jizˇ vytvorˇene´ho spojenı´ se chova´ jako SPI (tj. na nizˇsˇ´ı vrstveˇ TCP/IP). Du˚sledkem je zrychlenı´ odbavova´nı´ prˇ´ıchozı´ho i odchozı´ho provozu. Proxy nejen rozumı´ rˇazenı´ paketu˚ do jednotlivy´ch spojenı´, ale take´ umı´ sa´m spojenı´ navazovat. Dalsˇ´ı informace o proxy najdeme na http://www.vutbr.cz/www base/zav prace soubor verejne.php?file id=15131 Dalsˇı´ 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 prˇ´ıloha´ch najdeme sekce o firewallu ve Windows a v Linuxu vcˇetneˇ potrˇebny´ch prˇ´ıkazu˚ pro konfiguraci. Na straneˇ 246 je sekce o firewallu ve Windows, na straneˇ 274 je sekce o firewallu v Linuxu (velmi podrobna´ vcˇetneˇ prˇ´ıkladu˚ pravidel). ´ koly U V prˇ´ıloze od strany 274 je sekce o firewallu NetFilter, ve ktere´ jsou na prˇ´ıkladech vysveˇtleny nejdu˚lezˇiteˇjsˇ´ı funkce firewallu˚. Projdeˇte si dotycˇnou sekci a ujasneˇte si princip filtrova´nı´, SPI, prˇekladu adres a dalsˇ´ıch.
8.3.3
OpenWRT
Zajı´mavy´m projektem je OpenWRT. Jedna´ se o embedded Linux (tj. Linux upraveny´ pro urcˇity´ konkre´tnı´ typ zarˇ´ızenı´, typicky firmware takove´ho zarˇ´ızenı´) pro routery neˇktery´ch vy´robcu˚, naprˇ´ıklad firmy Mikrotik (RouterBoard). Jeho vy´hodou oproti „origina´lnı´mu“ operacˇnı´mu syste´mu (naprˇ´ıklad u desek RouterBoard je to RouterOS takte´zˇ zalozˇeny´ na Linuxu) je to, zˇe ma´ k beˇzˇny´m linuxovy´m distribucı´m mnohem blı´zˇe nezˇ jine´ embedded Linuxy. Zatı´mco obvykle se firmware aktualizuje jako celek (to mu˚zˇe by´t celkem nebezpecˇne´, dotycˇne´ zarˇ´ızenı´ se prˇi porusˇe prˇi aktualizaci mu˚zˇe zcela odrovnat), OpenWRT je pruzˇny´ syste´m, ktery´ lze aktualizovat, konfigurovat a jakkoliv meˇnit prakticky za provozu a mu˚zˇeme prˇi tom pouzˇ´ıvat jak beˇzˇny´ balı´cˇkovacı´ syste´m, tak prˇi konfiguraci trˇeba textovy´ editor.
Jak bylo vy´sˇe zmı´neˇno, OpenWRT pouzˇ´ıva´ balı´cˇkovacı´ syste´m a tedy lze doinstalovat ru˚zne´ balı´cˇky podle potrˇeby, vy´beˇr je veliky´. Do distribuce patrˇ´ı samozrˇejmeˇ firewall NetFilter s prˇ´ıstupovy´m programem iptables, podporuje ftp, samba, telnet, ssh, lze doinstalovat X Window a neˇjake´ho vhodne´ho spra´vce oken, konfigurujeme obvykle prˇes ssh (prˇ´ıpadneˇ lze prˇes ssh bezpecˇneˇ provozovat graficke´ prostrˇedı´). Ve vy´chozı´m stavu je tato distribuce vybavena typicky pro Wi-fi router, cozˇ ale mu˚zˇeme zmeˇnit podle svy´ch vlastnı´ch potrˇeb.
8.4
VPN
VPN (Virtual Private Network) je, jednodusˇe rˇecˇeno, zabezpecˇene´ spojenı´ procha´zejı´cı´ nedu˚veˇryhodny´m prostrˇedı´m (obvykle Internetem). Pouzˇ´ıva´ se v teˇchto prˇ´ıpadech: • Mobilnı´ zameˇstnanec potrˇebuje na svy´ch cesta´ch zabezpecˇeny´ prˇ´ıstup do firemnı´ (loka´lnı´) sı´teˇ, aby mohl prˇistupovat do firemnı´ho informacˇnı´ho syste´mu a dalsˇ´ıch zabezpecˇeny´ch zdroju˚. Do te´to kategorie bychom mohli zarˇadit i zameˇstnance pracujı´cı´ doma. Tento prˇ´ıpad nazy´va´me remote access (vzda´leny´ prˇ´ıstup).
P
8.4
VPN
182
• Je trˇeba propojit dveˇ vzda´lene´ loka´lnı´ sı´teˇ (naprˇ´ıklad pobocˇky te´zˇe firmy), ale nechceme volit poneˇkud drahe´ rˇesˇenı´ WAN sı´teˇ od telekomunikacˇnı´ firmy. Tento prˇ´ıpad se nazy´va´ site-to-site. • Je trˇeba komunikovat s obchodnı´m partnerem zabezpecˇeny´m komunikacˇnı´m kana´lem, ale za´rovenˇ ho nechceme pustit prˇ´ımo do nasˇ´ı loka´lnı´ sı´teˇ. Mu˚zˇe se jednat o site-to-site nebo remote access, podle skutecˇne´ konfigurace VPN. Ve vsˇech teˇchto prˇ´ıpadech je trˇeba vybudovat zabezpecˇeny´ sˇifrovany´ tunel, prˇes ktery´ povede komunikace nedu˚veˇryhodny´m prostrˇedı´m. Ve trˇetı´m prˇ´ıpadeˇ navı´c musı´me pouzˇ´ıt firewall, ktery´ bude propousˇteˇt pouze komunikaci povolenou pro tento u´cˇel. Pokud chceme vyuzˇ´ıvat VPN, musı´me mı´t potrˇebny´ hardware cˇi software. VPN je podporova´n v mnoha hardwarovy´ch zarˇ´ızenı´ch (firewally, smeˇrovacˇe, prˇ´ıpadneˇ VPN koncentra´tory), ale v jednodusˇsˇ´ıch prˇ´ıpadech mu˚zˇe stacˇit softwarova´ implementace. VPN tunel do firemnı´ sı´teˇ u´stı´ veˇtsˇinou bud’ prˇ´ımo na routeru s firewallem na hranici loka´lnı´ sı´teˇ, ktery´ je viditelny´ na Internetu, a nebo v demilitarizovane´ zo´neˇ (tam se cˇasto umı´st’uje VPN koncentra´tor, cozˇ je vlastneˇ jaka´si VPN bra´na), za´lezˇ´ı, kam v loka´lnı´ sı´ti je trˇeba prˇes tunel prˇistupovat. VPN rˇesˇenı´ by meˇlo zajistit na´sledujı´cı´: • autentizace – je trˇeba oveˇrˇit totozˇnost obou komunikujı´cı´ch bodu˚ (naprˇ. uzˇivatel s notebookem na pracovnı´ cesteˇ a firewall s podporou VPN v LAN firmy), prˇ´ıpadneˇ se zajisˇt’uje autentizace prˇena´sˇeny´ch PDU, • autorizace – stanovenı´ konkre´tnı´ch prˇ´ıstupovy´ch opra´vneˇnı´, • zajisˇteˇnı´ du˚veˇrnosti dat – prˇenos je vzˇdy sˇifrova´n, • zajisˇteˇnı´ integrity dat – detekce pozmeˇneˇnı´ paketu po cesteˇ.
$
Sˇifruje se vzˇdy neˇktery´m algoritmem typicky´m pro dany´ typ rˇesˇenı´. Mu˚zˇe se jednat naprˇ´ıklad o SHA (Secure Hash Algorithm, jednosmeˇrny´ hash algoritmus, cˇasto se pouzˇ´ıva´ prˇi prˇenosu hesel), DES (Data Encryption Standard, algoritmus soukrome´ho klı´cˇe, dnes spı´sˇe 3DES), Diffie-Hellman nebo RSA (Rivest, Shamir and Adleman) – algoritmy verˇejne´ho klı´cˇe (verˇejny´ klı´cˇ se mu˚zˇe vyuzˇ´ıt prˇi transportu soukrome´ho klı´cˇe, ktery´ se pak pouzˇ´ıva´ v na´sledne´ relaci). V soucˇasne´ dobeˇ se zrˇejmeˇ nejvı´ce nasazuje sˇifrovacı´ algoritmus AES, ktery´ je povazˇova´n za nejbezpecˇneˇjsˇ´ı z jmenovany´ch.
8.4.1
IPSec VPN – na sı´t’ove´ vrstveˇ
Protokol IPSec (Internet Protocol Security) umozˇnˇuje vytva´rˇet zabezpecˇena´ spojenı´ point-to-point (tunely) na sı´t’ove´ vrstveˇ. Tunel se vytva´rˇ´ı zapouzdrˇenı´m takto: 1. uvnitrˇ je PDU prˇena´sˇene´ho protokolu, veˇtsˇinou IP (ale mu˚zˇe by´t take´ IPX, NetBEUI nebo jiny´), 2. na´sleduje obalovy´ protokol, cozˇ by´va´ obvykle IPSec (mu˚zˇe by´t naprˇ. GRE, PPTP, L2TP nebo jiny´), zapouzdrˇena´ PDU je zasˇifrova´na a je prˇida´no bezpecˇnostnı´ za´hlavı´, 3. nosny´ protokol sı´t’ove´ vrstvy (obvykle IP) v sobeˇ zapouzdrˇ´ı PDU vytvorˇenou v prˇedchozı´m kroku, aby bylo mozˇne´ prˇene´st paket prˇes „nechra´neˇny´“ Internet cˇi jinou verˇejnou sı´t’.
P
8.4
VPN
183
Bonusem je mozˇnost takto zapouzdrˇit i takove´ protokoly, ktere´ nejsou beˇzˇneˇ ve vneˇjsˇ´ım prostrˇedı´ podporova´ny, prˇ´ıpadneˇ zajistit vyuzˇ´ıva´nı´ soukromy´ch IP adres (vnitrˇnı´ IP PDU je adresova´n soukromou cı´lovou IP adresou, ale aby bylo mozˇne´ celou PDU dorucˇit, vneˇjsˇ´ı IP datagram ma´ verˇejnou cı´lovou IP adresu hranicˇnı´ho zarˇ´ızenı´ firemnı´ sı´teˇ podporujı´cı´ho VPN). IPSec se take´ cˇasto kombinuje s protokoly GRE nebo L2TP pracujı´cı´mi na vrstveˇ L2. Jednı´m z du˚vodu˚ teˇchto kombinacı´ je proble´m IPSec prˇi pru˚chodu prˇes NAT, ktery´ modifikuje IP za´hlavı´. I pro tento prˇ´ıpad vsˇak existuje rˇesˇenı´, lze vyuzˇ´ıt mechanismus NAT-T (NAT Traversal), ktery´ zapouzdrˇ´ı paket do UDP a tı´m znemozˇnı´ pozmeˇneˇnı´ IP za´hlavı´. Oznacˇuje se IPSec over UDP nebo IPSec over NAT-T. Sˇifrova´nı´ v IPSec se prova´dı´ jednı´m z teˇchto dvou zpu˚sobu˚: • tunelovacı´ rezˇim – cely´ pu˚vodnı´ IP datagram se zasˇifruje a prˇipojı´ se za´hlavı´ IPSec (a pak samozrˇejmeˇ za´hlavı´ nosne´ho protokolu s novou IP adresou),
$
• transportnı´ (prˇenosovy´) rezˇim – sˇifruje se datova´ cˇa´st zapouzdrˇovane´ho paketu bez za´hlavı´, pak se prˇida´ IPSec za´hlavı´, prˇed neˇ se prˇedstune pu˚vodnı´ za´hlavı´ zapouzdrˇeny´ch dat. Tunelovacı´ rezˇim je bezpecˇneˇjsˇ´ı (cele´ zapouzdrˇene´ IP za´hlavı´ je skryto, sˇifrova´no), transportnı´ rezˇim je pruzˇneˇjsˇ´ı (mu˚zˇeme pouzˇ´ıvat prvky z pu˚vodnı´ho IP za´hlavı´, naprˇ´ıklad pro QoS) a pakety jsou kratsˇ´ı (tedy mensˇ´ı dopad na propustnost sı´teˇ). Srovna´nı´ vidı´me na obra´zku 8.3. Tunelovacı´ rezˇim je pouzˇ´ıva´n prˇedevsˇ´ım prˇi spojenı´ch site-to-site (propojenı´ dvou pobocˇek nebo firmy a obchodnı´ho partnera), zatı´mco transportnı´ rezˇim je typicˇteˇjsˇ´ı pro prˇipojenı´ jednoho pocˇ´ıtacˇe (mobilnı´ zameˇstnanec cˇi zameˇstnanec pracujı´cı´ doma) s firemnı´ sı´tı´ (tedy remote acces spojenı´). Pu˚vodnı´ IP datagram: IP za´hlavı´1
Teˇlo datagramu
• tunelovacı´ rezˇim: IP za´hlavı´2
IPSec za´hlavı´
Sˇifrova´no: IP za´hlavı´1
Teˇlo datagramu
• transportnı´ (prˇenosovy´) rezˇim: IP za´hlavı´1
IPSec za´hlavı´
Sˇifrova´no: Teˇlo datagramu
Obra´zek 8.3: PDU prˇed a po zasˇifrova´nı´ do IPSec tunelu Technicky vzato, existujı´ dva typy IPSec za´hlavı´ : AH (Authentication Header) a ESP (Encapsulated Security Payload). Zatı´mco AH je jednodusˇsˇ´ı, zajisˇt’uje pouze autentizaci a integritu dat, ale ne sˇifrova´nı´, za´hlavı´ ESP je bezpecˇneˇjsˇ´ı (zajisˇt’uje autentizaci a sˇifrova´nı´). V soucˇasne´ dobeˇ se pouzˇ´ıva´ obvykle jen ESP (lze pouzˇ´ıt dokonce obojı´ najednou, tedy AH/ESP). Prˇi vytva´rˇenı´ jake´hokoliv (tedy i IPSec) tunelu je trˇeba nejdrˇ´ıv dojednat parametry bezpecˇne´ho prˇidruzˇenı´ (SA – Security Association). IPSec pro tento u´cˇel pouzˇ´ıva´ protokol IKE (Internet Key Exchange), nynı´ ve verzi 2.
P
8.4
VPN
184
V protokolu IPv6 je jizˇ IPSec nativneˇ implementova´n (tak to bylo uzˇ v pu˚vodnı´m na´vrhu IPv6, k verzi IPv4 byl IPSec dodatecˇneˇ prˇida´n jako „pomocny´“ protokol zajisˇt’ujı´cı´ sˇifrova´nı´). Proto prˇechod na IPv6 ma´ jeden bonus – snadneˇjsˇ´ı vytva´rˇenı´ IPSec tunelu˚. Jak se IPSec konfiguruje. Na´sledujı´cı´ text se vztahuje ke konfiguraci IPSec v Linuxu za prˇedpokladu, zˇe pouzˇ´ıva´me IPv6 (pro IPv4 by bylo pa´r odlisˇnostı´, prˇedevsˇ´ım v adresa´ch). IPSec se konfiguruje podobny´m zpu˚sobem jako naprˇ´ıklad firewall – definujeme pravidla a dalsˇ´ı parametry (v tzv. tabulce politik). Urcˇujeme naprˇ´ıklad, zˇe pakety prˇ´ıchozı´ z konkre´tnı´ adresy (vzda´lene´ pobocˇky) se majı´ zpracovat mechanismem IPSec (desˇifrovat apod.), pakety odchozı´ na tute´zˇ adresu naopak zasˇifrovat, prˇidat IPSec za´hlavı´ apod., pakety smeˇrˇujı´cı´ do vnitrˇnı´ sı´teˇ se majı´ nechat tak jak jsou, atd.
V Linuxu se pro pra´ci s IPSec pouzˇ´ıvajı´ programy setkey a racoon, obojı´ v balı´ku programu˚ IPSec Tools. Konfigurace se prova´dı´ v textovy´ch konfiguracˇnı´ch souborech (/etc/racoon/racoon.conf a /etc/racoon/setkey.conf, da´le potrˇebujeme chra´neˇny´ soubor s hesly) a urcˇujeme naprˇ´ıklad vy´chozı´ parametry pro typ sˇifrova´nı´ a autentizace, ktery´ klı´cˇ se ma´ pouzˇ´ıt, a samozrˇejmeˇ politiky (za´sady) pro prˇ´ıchozı´ a odchozı´ provoz pro zadane´ adresy sı´tı´. Ve Windows a na sı´t’ovy´ch zarˇ´ızenı´ch konfigurovany´ch prˇes webove´ rozhranı´ se konfigurace prova´dı´ veˇtsˇinou „mysˇ´ı“, naprˇ´ıklad ve Windows Server ma´me k dispozici (grafickou) konzolu v Start ï Programs ï Administrative Tools ï Local Security Settings. Kromeˇ toho je ve Windows Server k dispozici program ipsecpol pro definova´nı´ IPSec politik (za´sad). Na klientovi je prˇipojenı´ vcelku jednoduche´. VPN je prˇedem nakonfigurova´na na serveru, na klientovi vpodstateˇ konfigurujeme nove´ prˇipojenı´ k sı´ti. Naprˇ´ıklad ve Windows XP zvolı´me Ovla´dacı´ panely ï Sı´t’ova´ prˇipojenı´ ï Vytvorˇit nove´ prˇipojenı´, zvolı´me prˇipojenı´ k firemnı´ sı´ti, VPN, atd. V pru˚vodci potrˇebujeme IP adresu VPN serveru, se ktery´m budeme komunikovat. Ve vlastnostech prˇipojenı´ da´le nakonfigurujeme protokol IPSec, vcˇetneˇ bezpecˇnostnı´ch nastavenı´. Podrobnosti prˇedevsˇ´ım o Linuxu najdeme v odkazech na konci sekce o VPN, prˇedevsˇ´ı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 vrstveˇ L2. Jeho vy´hodou je univerza´lnost, doka´zˇe zapouzdrˇit i jine´ typy PDU sı´t’ove´ vrstvy ISO/OSI (nejen TCP/IP) nezˇ jen IP. Jeho hlavnı´m u´cˇelem je prˇeda´vat na da´lku multicast a broadcast vysı´la´nı´. Na druhou stranu, velkou nevy´hodou GRE je, zˇe neprova´dı´ sˇifrova´nı´, proto se ve skutecˇnosti nejedna´ o „pravy´“ VPN tunel. V praxi je GRE zapouzdrˇova´n do tunelu˚ VPN (naprˇ´ıklad v kombinaci s IPSec), aby byla konverzace za´rovenˇ sˇifrova´na. Hlavnı´m u´cˇelem protokolu L2TP je tunelova´nı´ (zapouzdrˇova´nı´) paketu˚ protokolu PPP (ten se pouzˇ´ıva´ pro prˇenos dat prˇes telefonnı´ sı´t’). Stejneˇ jako GRE, ani L2TP neprova´dı´ sˇifrova´nı´, tedy je obvykle kombinova´n s IPSec (v transportnı´m mo´du). L2TP je podporova´n v Linuxu i ve Windows. V Linuxu se dnes doporucˇuje pouzˇitı´ OpenL2TP (s vyuzˇitı´m IPSec), ve Windows se nacha´zı´ klient L2TP/IPSec pro transportnı´ mo´d. Ve Windows
P P
8.4
VPN
185
se take´ mu˚zˇeme setkat s protokolem SSTP (Secure Socket Tunneling Protocol), ktery´ prˇena´sˇ´ı PPP nebo L2TP sˇifrovane´ s vyuzˇitı´m protokolu SSL. V prˇ´ıloze na straneˇ 266 je uka´zka nastavenı´ jednoduche´ho GRE tunelu mezi dveˇma vzda´leny´mi sı´teˇmi (mezi routery s nainstalovany´m Linuxem). ´ koly U V prˇ´ıloze si projdeˇte postup konfigurace GRE tunelu.
8.4.3
SSL/TLS VPN
SSL (Secure Sockets Layer) a jeho na´slednı´k TLS (Transport Layer Security) pracujı´ na vrstva´ch L4 a vysˇsˇ´ıch. Zatı´mco IPSec je sı´t’ove´ rˇesˇenı´ (transparentnı´ pro ru˚zne´ aplikace), SSL/TLS je aplikacˇnı´ rˇesˇenı´ (tj. musı´ by´t podporova´no konkre´tnı´ aplikacı´, jejı´zˇ komunikace ma´ by´t sˇifrova´na). Ve webovy´ch prohlı´zˇecˇ´ıch je podpora SSL/TLS jizˇ da´vno zabudova´na, takzˇe s funkcˇnostı´ tohoto rˇesˇenı´ neby´vajı´ proble´my alesponˇ v prˇ´ıpadech, kdy se komunikuje prˇes protokol HTTP nebo podobne´. Pokud aplikace nepodporuje SSL/TLS, je mozˇne´ to rˇesˇit naprˇ´ıklad pomocı´ STunnel.5
P
Typicke´ pouzˇitı´ tohoto typu tunelu˚ je pro prˇipojenı´ mobilnı´ho cˇi doma pracujı´cı´ho zameˇstnance, tj. typ remote access. SSL sice podporuje oboustrannou autentizaci, ale cˇasto se setka´va´me s rˇesˇenı´mi vyuzˇ´ıvajı´cı´mi jednostrannou autentizaci (autentizuje se dotycˇny´ externı´ zameˇstnanec). Rovneˇzˇ integrita dat a sˇifrova´nı´ jsou tı´mto protokolem zajisˇteˇny, sˇifrujı´ se pouze prˇena´sˇena´ data. Pouzˇ´ıva´ se kombinace verˇejne´ho a soukrome´ho klı´cˇe, je mozˇne´ pouzˇ´ıt certifika´ty. SSL je povazˇova´no za sice me´neˇ bezpecˇne´, ale zato pruzˇneˇjsˇ´ı rˇesˇenı´ (naprˇ´ıklad s mechanismem NAT ma´ IPSec proble´my, kdezˇto SSL si s nı´m poradı´ celkem bez proble´mu˚). Zajı´mavou implementacı´ SSL/TLS VPN je projekt OpenVPN. Beˇzˇ´ı na veˇtsˇineˇ zna´my´ch unixovy´ch syste´mu˚ vcˇetneˇ Linuxu, existuje i varianta pro Windows.
8.4.4
SSH
Pro vzda´leny´ prˇ´ıstup ke konkre´tnı´mu pocˇ´ıtacˇi (remote access) se drˇ´ıve, alesponˇ u pocˇ´ıtacˇu˚ s unixovy´mi syste´my, pouzˇ´ıval Telnet. Tento protokol vsˇak nenı´ bezpecˇny´ (o tunelech se ani neda´ mluvit), protozˇe se nesˇifrujı´ dokonce ani prˇihlasˇovacı´ informace, heslo se obecneˇ prˇena´sˇ´ı v textove´ formeˇ. V soucˇasne´ dobeˇ se velmi cˇasto ke vzda´lene´mu pocˇ´ıtacˇi prˇistupuje prˇes protokol SSH (Secure Shell). Tento protokol se postupneˇ vyvı´jel – v prvnı´ verzi SSH-1 nebyl povazˇova´n za moc bezpecˇny´, jeho implementace obsahovaly pomeˇrneˇ hodneˇ bezpecˇnostnı´ch chyb, navı´c trˇebazˇe pu˚vodneˇ byl uvolneˇn jako freeware, pozdeˇji to bylo s licencemi horsˇ´ı. Dnes se setka´va´me spı´sˇe s implementacemi verze SSH-2 vydany´mi sdruzˇenı´m IETF (od roku 1997), SSH-2 je take´ standardem RFC 4252. 5
$
http://www.stunnel.org/
P
8.4
VPN
186
Jedna´ se o typickou komunikaci typu klient-server (sedı´me u klienta, prˇihlasˇujeme se k serveru), tedy existuje klientska´ a serverova´ implementace SSH. Serverove´ implementace jsou urcˇeny spı´sˇe pro unixove´ syste´my, protozˇe typicke´ vyuzˇitı´ SSH je pra´veˇ pro prˇipojenı´ k unixove´mu serveru. SSH je protokolem vysˇsˇ´ıch vrstev a komunikuje prˇes TCP (protozˇe je trˇeba vytvorˇit spojenı´, ktere´ SSH da´le zabezpecˇuje). Narozdı´l od TLS a neˇktery´ch dalsˇ´ıch podobny´ch protokolu˚ SSH-2 nabı´zı´ spra´vu vı´ce nava´zany´ch relacı´ najednou (TLS pouze jedno spojenı´). SSH podporuje neˇkolik autentizacˇnı´ch metod, ze ktery´ch se pouzˇ´ıva´ nejcˇasteˇji autentizace pomocı´ klı´cˇu˚. Beˇhem autentizace se pouzˇijı´ asymetricke´ autentizacˇnı´ klı´cˇe, v SSH-2 se pouzˇ´ıva´ sˇifrova´nı´ DSA (v SSH-1 to bylo me´neˇ bezpecˇne´ RSA). Beˇhem komunikace se data sˇifrujı´ neˇkterou z rychly´ch symetricky´ch metod, naprˇ´ıklad 3DES. Jinou mozˇnostı´ autentizace, ktera´ se pouzˇ´ıva´ prˇedevsˇ´ım v komercˇnı´ sfe´rˇe (nejen), je GSSAPI. Jedna´ se o vyuzˇitı´ externı´ho autentizacˇnı´ho mechanismu, naprˇ´ıklad Kerberos. Tento protokol je prˇirozeny´m zpu˚sobem vyuzˇitelny´ pro vytva´rˇenı´ sˇifrovany´ch tunelu˚. Funguje na principu prˇeda´va´nı´ (forwardova´nı´) provozu na porty, na ktere´ je napojen SSH tunel. SSH server nasloucha´ na TCP portu 22. Existuje vı´ce ru˚zny´ch implementacı´ SSH. K nejoblı´beneˇjsˇ´ım patrˇ´ı na´stroj OpenSSH, pro ktery´ existuje klientska´ i serverova´ varianta (spı´sˇe pro unixove´ syste´my). Instalace a pouzˇ´ıva´nı´ jsou popsa´ny v prˇ´ıloze na straneˇ 290. Pro Windows existujı´ mezi volneˇ sˇirˇitelny´m softwarem spı´sˇe klienty, naprˇ´ıklad PuTTY.
P P $
Kdyzˇ pouzˇ´ıva´me SSH, meˇli bychom vyuzˇ´ıvat bezpecˇne´ verze softwaru pro prˇenos dat. V Unixu (vcˇetneˇ Linuxu) pouzˇ´ıva´me prˇ´ıkazy scp (kopı´rova´nı´, mı´sto cp) a sftp (mı´sto ftp). Existuje take´ souborovy´ manazˇer WinSCP implementujı´cı´ obdobu teˇchto prˇ´ıkazu˚. ´ koly U Ve zmı´neˇne´ prˇ´ıloze si projdeˇte instalaci a pouzˇ´ıva´nı´ SSH. Jsou tam take´ odkazy na dalsˇ´ı informace.
8.4.5
MPLS VPN
Narozdı´l od prˇedchozı´ho rˇesˇenı´ se MPLS sı´teˇ pouzˇ´ıvajı´ spı´sˇe pro implementaci propojenı´ firemnı´ch pobocˇek tunelem (prˇ´ıp. firmy a obchodnı´ho partnera), tedy VPN typu site-to-site. S MPLS sı´teˇmi jsme se jizˇ sezna´mili a vı´me, zˇe se pouzˇ´ıva´ syste´m za´hlavı´, z nichzˇ jedno je urcˇeno pra´veˇ pro ˇ esˇenı´ pracuje na rozhranı´ vrstev L2 a L3. virtua´lnı´ sı´teˇ. R V sı´ti MPLS VPN rozezna´va´me tato zarˇ´ızenı´: • CE (Customer Edge) – hranicˇnı´ uzel sı´teˇ za´kaznı´ka, prˇes ktery´ se data prˇena´sˇejı´ do MPLS tunelu, • PE (Provider Edge) – hranicˇnı´ uzel sı´teˇ poskytovatele rˇesˇenı´, je prˇ´ımo spojen s uzlem CE, • P (Provider) – vnitrˇnı´ uzly MPLS sı´teˇ poskytovatele, vpodstateˇ Core MPLS smeˇrovacˇe. Uzly CE nejsou soucˇa´stı´ MPLS sı´teˇ, jsou na nich vyzˇadova´ny pouze protokoly TCP/IP (konkre´tneˇ hlavneˇ IP). Uzly PE jsou hranicˇnı´mi (LER) uzly MPLS sı´teˇ a implementujı´ protokol BGP (to je jeden
P
8.4
VPN
187
z externı´ch smeˇrovacı´ch protokolu˚, pro MPLS je typicky´), prˇ´ıp. iBGP (distribuce tabulek mezi uzly). K jednomu PE uzlu mu˚zˇe by´t prˇipojeno vı´ce CE uzlu˚. IP datagram prˇicha´zejı´cı´ z CE na PE je opatrˇen dveˇma MPLS hlavicˇkami • vnitrˇnı´ (B=1) bude vyuzˇita azˇ na druhe´m konci tunelu, urcˇuje CE prˇ´ıjemce, • vneˇjsˇ´ı (B=0) urcˇuje cestu v MPLS sı´ti prˇes P uzly VRF tabulka (VPN Routing and Forwarding Table) je tabulka smeˇrovacı´ch informacı´ pro konkre´tnı´ VPN a sı´teˇ. Nacha´zı´ se na uzlech PE, jeden PE mu˚zˇe obsahovat i vı´ce VRF. V tabulce je konkre´tnı´ port (rozhranı´) asociova´n s konkre´tnı´ VRF (patrˇ´ı do prˇ´ıslusˇne´ VPN), pokud paket prˇijde z rozhranı´ napojene´ho na urcˇitou VRF, podle dane´ VRF se rozhoduje, co s nı´m. To znamena´, zˇe VRF urcˇuje, ke ktere´mu CE se ma´ dostat paket prˇ´ıchozı´ z dane´ho rozhranı´.
Obra´zek 8.4: Sche´ma MPLS VPN a VRF tabulek6 Na obra´zku 8.4 vidı´me uka´zku MPLS VPN sı´teˇ, kde naprˇ´ıklad LAN 2 (Site 2) patrˇ´ı do VPN A a VPN B, proto ve VRF tabulce na prˇ´ıslusˇne´m PE urcˇene´ pro tuto LAN najdeme smeˇrova´nı´ do vsˇech sı´tı´ patrˇ´ıcı´ch do teˇchto dvou VPN (tj. sı´tı´ 1, 2 a 3). Pro MPLS VPN existujı´ 2 za´kladnı´ rˇesˇenı´ – MPLS Layer-3 VPN, MPLS Layer-2 VPN. Dalsˇ´ı 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
SPRA´VA SI´TEˇ
8.5
• • • • • • • • • • • • • • • •
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
Spra´va sı´teˇ NMS
Spra´va sı´teˇ v sobeˇ zahrnuje tyto cˇinnosti: • dohled, kontrola (monitorova´nı´) – na fyzicke´ vrstveˇ (stav me´dia apod.), linkove´ vrstveˇ (chybovost ra´mcu˚, atd.) i vysˇsˇ´ıch, interpretace shroma´zˇdeˇny´ch u´daju˚
P
• diagnostika a rˇesˇenı´ poruch, prˇedcha´zenı´ porucha´m • spra´va jednotlivy´ch prvku˚ sı´teˇ, rˇesˇenı´ zmeˇn topologie (naprˇ´ıklad prˇida´nı´ nove´ho uzlu) • u´cˇtova´nı´ vyuzˇ´ıva´nı´ zdroju˚ V ra´mci modelu ISO/OSI veˇtsˇina teˇchto cˇinnosti probı´ha´ na aplikacˇnı´ vrstveˇ, a to vzˇdy v neˇktere´ formeˇ na vsˇech uzlech sı´teˇ. Spra´va sı´teˇ je sluzˇba vyuzˇ´ıvajı´cı´ rˇadu na´stroju˚, aplikacı´ a zarˇ´ızenı´ k monitorova´nı´, u´drzˇbeˇ a zabezpecˇova´nı´ sı´teˇ, a to v co nejvysˇsˇ´ı mı´rˇe automatizace. ˇ ´ızene´ entity odesı´lajı´ zpra´vy obsahujı´cı´ hla´sˇenı´ o uda´lostech Rozlisˇujeme rˇ´ıdicı´ a rˇ´ızene´ entity. R nebo proble´mech, rˇ´ıdicı´ entity na neˇ adekva´tneˇ reagujı´, naprˇ´ıklad • zpravı´ opera´tora mailem nebo jiny´m zpu˚sobem, • zapı´sˇou uda´lost do LOG souboru (logova´nı´ uda´lostı´), • vypnou nebo restartujı´ syste´m, odhla´sı´ „proble´move´ho“ uzˇivatele, odstrˇelı´ „proble´movy´“ proces, • provedou automatickou u´pravu konfigurace syste´mu, prˇenastavı´ urcˇene´ limity.
P
SPRA´VA SI´TEˇ
8.5
189
Softwarove´ agenty sbı´rajı´ informace z koncovy´ch zarˇ´ızenı´ (rˇ´ızene´ entity) a odesı´lajı´ rˇ´ıdicı´m entita´m. Network Management System (NMS) je syste´m rˇ´ızenı´ sı´teˇ zahrnujı´cı´ rˇ´ıdicı´ entity, databa´zi a protokoly rˇ´ızenı´ sı´teˇ. Nejzna´meˇjsˇ´ı protokoly pro NMS:
P
• SNMP (Simple Network Management Protocol) • CMIP (Common Management Information Protocol)
8.5.2
ISO model rˇı´zenı´ sı´teˇ
ˇ ´ızenı´ sı´teˇ lze rozdeˇlit do neˇkolika oblastı´. R ˇ ı´zenı´ vy´konu (performance management) – u´cˇelem je zajistit, aby vy´kon sı´teˇ byl na prˇijatelne´ R u´rovni. Patrˇ´ı zde promeˇnne´ velicˇiny jako je pru˚chodnost sı´teˇ, lhu˚ty pro odezvu uzˇivatelu˚, optima´lnı´ vyuzˇ´ıva´nı´ kabelu˚ a jiny´ch spojovy´ch cest a prvku˚, atd. Zahrnuje: 1. shroma´zˇdeˇnı´ souvisejı´cı´ch dat o velicˇina´ch 2. analy´za dat a stanovenı´ u´rovneˇ pro norma´lnı´ provoz 3. stanovenı´ hornı´ (resp. u neˇktery´ch velicˇin dolnı´) hranice s tı´m, zˇe prˇekrocˇenı´ te´to hranice je indikova´no jako proble´m, ktery´ je trˇeba rˇesˇit Prˇi prˇekrocˇenı´ stanoveny´ch hranic je informova´n NMS. ˇ ı´zenı´ konfigurace (configuration management) znamena´ monitorova´nı´ konfigurace sı´teˇ a prˇiR pojeny´ch syste´mu˚ (hardware i software) a jejich ovlivnˇova´nı´. Pro kazˇdou sledovanou velicˇinu (verze operacˇnı´ho syste´mu s aktualizacemi, verze protokolu TCP/IP, apod.) je vytvorˇeno pravidlo, a pokud nenı´ splneˇno, musı´ by´t vyvozeny du˚sledky. ˇ ı´zenı´ uzˇivatelsky´ch u´cˇtu R ˚ (accounting management) znamena´ definova´nı´ regulacˇnı´ch parametru˚ pro uzˇivatele a skupiny uzˇivatelu˚. Vhodna´ regulace minimalizuje proble´my v sı´ti, prˇedevsˇ´ım prˇi vyuzˇ´ıva´nı´ zdroju˚ (hardware, vyhrazene´ mı´sto v pameˇti, atd.), a maximalizuje fe´rovost vyuzˇ´ıva´nı´ zdroju˚ v sı´ti vzhledem k ostatnı´m uzˇivatelu˚m. ˇ ı´zenı´ chyb (fault management) prˇedstavuje detekci, evidenci (log soubory), oznamova´nı´ a, R pokud je to mozˇne´, take´ automaticke´ rˇesˇenı´ proble´mu˚, ktere´ v sı´ti mohou vzniknout. o jeden z nejdu˚lezˇiteˇjsˇ´ıch modulu˚ syste´mu˚ rˇ´ızenı´ sı´teˇ, protozˇe neodchycene´ chyby mohou zpu˚sobit zpomalenı´ komunikace, ztra´tu dat nebo obecneˇ neakceptovatelne´ zhorsˇenı´ celkove´ho provozu na sı´ti (prˇ´ıpadneˇ zhroucenı´ sı´teˇ). Modul vyuzˇ´ıva´ u´daje zı´ska´vane´ a ulozˇene´ v ra´mci ostatnı´ch funkcı´ rˇ´ızenı´ sı´teˇ, detekuje mozˇne´ proble´my (aby byly co nejdrˇ´ıve zachyceny), navrhuje a testuje rˇesˇenı´. ˇ ı´zenı´ bezpecˇnosti (security management) znamena´ rˇ´ızenı´ prˇ´ıstupu ke zdroju˚m na sı´ti podle R stanoveny´ch pravidel, zabra´neˇnı´ posˇkozenı´ syste´mu (at’uzˇ u´myslne´mu nebo neu´myslne´mu) a vynesenı´ citlivy´ch informacı´. V hierarchicke´ sı´ti jsou stanoveny oblasti autorizovane´ a neautorizovane´, autorizace mu˚zˇe by´t take´ vı´ceu´rovnˇova´.
8.6
MANAGEMENT V TCP/IP
8.5.3
190
Management v ISO/OSI
Jedna´ se o centralizovany´ syste´m zalozˇeny´ na protokolu CMIP (Common Management Information Protocol). Management mu˚zˇeme rozdeˇlit do trˇ´ı cˇa´stı´: • syste´movy´ management (take´ sı´t’ovy´, network management) – pu˚sobı´ v aplikacˇnı´ vrstveˇ, slouzˇ´ı jako rozhranı´ k ostatnı´m cˇa´stem managementu, tj. prova´dı´ u´koly souvisejı´cı´ s vı´ce vrstvami
P
• vrstvovy´ management – pracuje v ra´mci jedne´ vrstvy • protokolova´ operace – take´ v ra´mci jedne´ vrstvy, ale pouze pro jediny´ prˇ´ıpad komunikace Jedna´ se o objektovy´ model (pracuje s objekty a jejich vlastnostmi – atributy, operacemi, vztahem k jiny´m objektu˚m, pouzˇ´ıva´ ISA hierarchii): • manazˇer (spra´vce) – programove´ vybavenı´ na stanici sı´t’ove´ho managementu (centra´lnı´) • agent – programove´ vybavenı´ na jednotlivy´ch uzlech sı´teˇ, posı´la´ zpra´vy o (mimorˇa´dny´ch) uda´lostech manazˇerovi • MIB (Management Information Base) – objektova´ databa´ze rˇ´ızeny´ch objektu˚, v tomto modelu bina´rnı´ MIB
je tedy databa´ze rˇ´ızeny´ch objektu˚. Pro kazˇdy´ objekt je zde
• jme´no, trˇ´ıda objektu,
P
• atributy jako usporˇa´dane´ dvojice typ–hodnota, • chova´nı´ – reakce prˇedpokla´dana´ a skutecˇna´ na rˇ´ıdicı´ operace • hla´sˇenı´ – o uda´lostech souvisejı´cı´ch s objektem vcˇetneˇ informace, co ma´ by´t agentem sdeˇleno manazˇerovi • vy´cˇet operacı´, ktere´ je mozˇno s objektem prova´deˇt (u trˇ´ıdy) Protokol CMIP pracuje na aplikacˇnı´ vrstveˇ uzlu˚ sı´teˇ. Prˇi komunikaci pouzˇ´ıva´ sluzˇbu se spojenı´m (tj. pokud nelze nava´zat zcela spolehliveˇ spojenı´, CMIP nemu˚zˇe komunikovat s agenty), cozˇ mu˚zˇe by´t svy´m zpu˚sobem nevy´hoda. Pro reprezentaci rˇ´ıdicı´ch informacı´ se pouzˇ´ıva´ jazyk ASN.1 (Abstract Syntax Notation One), ktery´ je pro tyto u´cˇely beˇzˇny´ (setka´me se s nı´m i u SNMP).
8.6 8.6.1
P
Management v TCP/IP SNMP
V TCP/IP je spra´va prova´deˇna pomocı´ protokolu SNMP (Simple Network Management Protocol). Ve skutecˇnosti mu˚zˇe beˇzˇet i nad jiny´m protokolem nezˇ IP, ale te´meˇrˇ vy´hradneˇ se setka´me s pouzˇitı´m nad IP. SNMP (resp. jeho na´stavby) je v soucˇasne´ dobeˇ nejpouzˇ´ıvaneˇjsˇ´ım protokolem pro spra´vu sı´teˇ a je sˇiroce podporova´n prakticky v kazˇde´m zarˇ´ızenı´, ktere´ je mozˇne´ prˇipojit k sı´ti (take´ tiska´rny, nejru˚zneˇjsˇ´ı cˇidla a analyza´tory, prˇ´ıstupove´ 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
Obra´zek 8.5: Komunikace v SNMP Protokol SNMP existuje ve trˇech verzı´ch. Soucˇasna´ verze je SNMPv3, ale prˇesto je momenta´lneˇ nejpouzˇ´ıvaneˇjsˇ´ı verze SNMPv2, prˇesneˇji jejı´ varianta SNMPv2c. Hlavnı´, a velmi du˚lezˇity´ rozdı´l mezi verzı´ 3 a prˇedchozı´mi je u´rovenˇ zabezpecˇenı´ komunikace. Starsˇ´ı verze pouzˇ´ıvajı´ prˇi autentizaci pouze (textove´) heslo – community string (prˇesneˇji dveˇ – read comminity string pro cˇtenı´, write community string pro povolenı´ za´pisu). SNMPv3 jizˇ vyuzˇ´ıva´ bezpecˇneˇjsˇ´ı metody – prˇ´ıstupove´ jme´no a heslo, kontrolnı´ soucˇty MD5, sˇifrova´nı´ DES, rˇ´ızenı´ prˇ´ıstupu k objektu˚m. SNMPv2 prˇinesl oproti prˇedchozı´ verzi naprˇ´ıklad podporu komunikace mezi ru˚zny´mi spra´vci (ve verzi SNMPv1 se s vı´ce spra´vci ani moc nepocˇ´ıtalo) a vylepsˇenı´ zabezpecˇenı´ komunikace. I nada´le se sice pouzˇ´ıvajı´ community strings, ale byly prˇida´ny nove´ mechanismy jednoznacˇne´ identifikace entit. Hlavnı´ vlastnostı´ SNMP je jednoduchost. Podobneˇ jako CMIP, i SNMP pouzˇ´ıva´ koncept agent– spra´vce (manager), ale funkce teˇchto modulu˚ jsou jinak rozdeˇleny. Kazˇdy´ uzel sı´teˇ (spravovane´ zarˇ´ızenı´ – managed device) mu˚zˇe obsahovat jake´koliv mnozˇstvı´ agentu˚ specializovany´ch na urcˇitou cˇinnost. V sı´ti musı´ existovat alesponˇ jeden spra´vce, mu˚zˇe jich by´t vı´ce. Komunikace mezi agentem a spra´vcem probı´ha´ prˇedevsˇ´ım pomocı´ protokolu UDP. Tento protokol vsˇak nepodporuje potvrzenı´ dorucˇenı´ (ale na druhou stranu je rychly´ a zası´la´nı´ obvykle funguje), proto SNMPv2 a vysˇsˇ´ı obsahuje vlastnı´ mechanismus kontroly dorucˇenı´. SNMP podporuje dva typy komunikace: 1. Dotaz–odpoveˇd’ – aktivita je na straneˇ spra´vce, spra´vce odesı´la´ dotazy agentu˚m a prˇijı´ma´ jejich reakce. Spra´vce posı´la´ dotazy agentovi na port 161, agent odpovı´da´ z portu 161 na dynamicky´ port spra´vce (tzn. cˇ´ıslo portu se meˇnı´). 2. Trap – aktivita je na straneˇ agentu˚, agenty odesı´lajı´ trapy (ozna´menı´) spra´vci naprˇ´ıklad prˇi vy´skytu definovane´ uda´losti, prˇekrocˇenı´ zadane´ hodnoty, zmeˇneˇ topologie sı´teˇ (naprˇ´ıklad prˇipojenı´ nove´ho uzlu) nebo v pravidelny´ch intervalech. Agent posı´la´ spra´vci trapy ze sve´ho dynamicke´ho portu (s ru˚zny´mi cˇ´ısly) na port 162. Tento typ komunikace je beˇzˇneˇjsˇ´ı. O skupineˇ NMS v ra´mci jedne´ administrativnı´ dome´ny hovorˇ´ıme jako o komuniteˇ. Kazˇda´ komunita je jednoznacˇneˇ identifikova´na rˇeteˇzcem community name. Ve starsˇ´ıch verzı´ch SNMP se pouzˇ´ıva´ jako jednoznacˇny´ identifika´tor prˇi autentizaci. Protokol SNMP je asynchronnı´, transakcˇneˇ orientovany´, typu klient/server (komunikace je veˇtsˇinou typu dotaz–odpoveˇd’).
P P P
8.6
8.6.2
MANAGEMENT V TCP/IP
192
MIB-II
Take´ se pouzˇ´ıva´ databa´ze MIB, ale ma´ obecneˇ jinou strukturu, data jsou ulozˇena v textove´ formeˇ (obsluzˇny´ modul MIB je naprogramova´n v jazyce ASN.1, ktery´ je pro tyto u´cˇely v TCP/IP typicky´). Je sice objektova´ (v tom smyslu, zˇe pracujeme s objekty), ale narozdı´l od OSI MIB je rˇ´ızena´ atributy (nepouzˇ´ıva´ plneˇ objektovy´ prˇistup, prˇistupujeme prˇes vlastnosti objektu˚).
P
Ve skutecˇnosti se v soucˇasny´ch zarˇ´ızenı´ch setka´me vzˇdy s podporou MIB-II, tedy druhe´ verze MIB. V na´sledujı´cı´m textu budeme pro strucˇnost pouzˇ´ıvat na´zev MIB, ale vzˇdy pu˚jde o MIB-II. MIB je tvorˇena stromem s jediny´m korˇenem. Korˇen obsahuje „pra´zdnou hodnotu“, jeho u´cˇelem je pouze spojovat z neˇho vycha´zejı´cı´ veˇtve. Vsˇechny uzly kromeˇ korˇenu majı´ prˇideˇlen textovy´ na´zev a cˇ´ıselnou hodnotu – OID (Object ID), OID jednoznacˇneˇ odlisˇuje uzly se stejny´m „rodicˇem“ – viz obr. 8.6 na str. 192. Textovy´ na´zev je urcˇen spı´sˇe pro „lidskou orientaci“, nema´ v databa´zi zˇa´dny´ jiny´ vy´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)
Obra´zek 8.6: SNMP MIB (zkra´cena´) Uzly (objekty) v MIB, ktere´ jsou prˇ´ımy´mi potomky korˇene, jsou nazva´ny podle organizacı´, jejichzˇ protokoly vyuzˇ´ıvajı´ podstromy teˇchto uzlu˚ (naprˇ´ıklad ISO nebo ITU). Neˇktere´ cˇa´sti (veˇtve) MIB jsou standardizova´ny orgranizacı´ IETF, dalsˇ´ı vyda´vajı´ vy´robci sı´t’ovy´ch zarˇ´ızenı´. Fyzicky je
P
8.6
MANAGEMENT V TCP/IP
193
tedy MIB ulozˇena obvykle ve vı´ce nezˇ jednom (textove´m) souboru, aby zpracova´nı´ zde ulozˇeny´ch dat bylo dostatecˇneˇ pruzˇne´ a aby byla snadneˇji rozsˇirˇitelna´. Adresa objektu v MIB je sekvence • na´zvu˚ uzlu˚ na cesteˇ od korˇene stromu – pro lidi, objekty oddeˇlujeme lomı´tkem nebo tecˇkou, NEBO
P
• cˇ´ısel OID uzlu˚ na cesteˇ od korˇene stromu – pro kohokoliv/cokoliv jine´ho, objekty oddeˇlujeme tecˇkou (vcˇetneˇ pra´zdne´ho na´zvu korˇene, tedy cely´ rˇeteˇzec vlastneˇ zacˇ´ına´ tecˇkou). Naprˇ´ıklad podle obra´zku 8.6 ma´ uzel enterprise urcˇeny´ pro firemnı´ uzly (zarˇ´ızenı´ ru˚zny´ch vy´robcu˚) tuto textovou a OID adresu: • .iso.org.dod.internet.private.enterprise • .1.3.6.1.4.1 Kazˇde´ sı´t’ove´ zarˇ´ızenı´, protokol cˇi hodnota (resp. prˇirˇazeny´ objekt), ktere´ lze prˇes MIB spravovat, ma´ svou unika´tnı´ OID adresu, ktera´ je stejna´ v jake´koliv MIB, tedy vsˇechny OID adresy musı´ by´t globa´lneˇ jedinecˇne´. Listy stromu MIB jsou skala´rnı´ objekty, jedna´ se o promeˇnne´ obsahujı´cı´ konkre´tnı´ hodnotu vyuzˇ´ıvanou pro u´cˇely rˇ´ızenı´ sı´teˇ (naprˇ´ıklad pocˇet paketu˚ procha´zejı´cı´ch routerem). Promeˇnne´ mohou by´t usporˇa´da´ny i do tabulky (tabulkove´ objekty). SNMP poskytuje omezenou mozˇnost pohybovat se v tabulce – po sloupcı´ch. Typy promeˇnny´ch v MIB: 1. cˇ´ıselne´
2. 3. 4. 5.
• beˇzˇny´ Integer • Counter – pro cˇ´ıtacˇe, prˇi dosa´hnutı´ maxima´lnı´ hodnoty se vynulujı´, slouzˇ´ı prˇedevsˇ´ım pro zjisˇteˇnı´ rychlosti sledova´nı´ zmeˇn • Gauge (mı´ra) – pokud sledovana´ velicˇina prˇesa´hne danou hranici, hodnota Gauge zu˚sta´va´ na maxima´lnı´ hodnoteˇ a „neprˇetecˇe“ • Time Ticks – sleduje cˇas (v setina´ch sekundy) od zadane´ uda´losti, naprˇ´ıklad od spusˇteˇnı´ zarˇ´ızenı´ IP Address – zde by´va´ ulozˇena IP adresa Octet String – posloupnost oktetu˚, pouzˇ´ıva´ se pro ukla´da´nı´ znakovy´ch rˇeteˇzcu˚ Object Identifier – OID rˇeteˇzec neˇktere´ho objektu tabulka hodnot vy´sˇe uvedeny´ch typu˚.
K promeˇnny´m se prˇistupuje poneˇkud zvla´sˇtnı´m zpu˚sobem. Pokud se jedna´ o jednoduchou promeˇnnou (takovou, ktera´ nenı´ tabulkou), syntaxe je .cesta.na ´zev_prome ˇnne ´.0
Pokud se jedna´ o tabulku, pak mı´sto cˇ´ısla 0 na konci pouzˇijeme index v tabulce. Prˇı´klad K promeˇnne´ sysUpTime ve veˇtvi system vede cesta .iso.org.dod.internet.mgmt.mib-2.system.sysUpTime.0 .1.3.6.1.2.1.1.3.0
nebo cˇ´ıselneˇ
P
8.6
MANAGEMENT V TCP/IP
194
K hodnota´m v tabulka´ch prˇistupujeme tak, zˇe mı´sto cˇ´ısla 0 na konci dosadı´me index v tabulce (od 1), naprˇ´ıklad k hodnota´m v tabulce ukazujı´cı´m stav portu˚ zarˇ´ızenı´ (zˇivy´/mrtvy´, v Ethernetu to obvykle znamena´ je/nenı´ neˇco prˇipojeno) prˇ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 mu˚zˇe by´t bud’ up(1) nebo down(2). V interfaces je jednoducha´ cˇ´ıselna´ promeˇnna´ ifNumber, ve ktere´ ma´me ulozˇen pocˇet rozhranı´ v syste´mu (number of interfaces). Je zrˇejme´, zˇe na pracovnı´ stanici bude ifNumber.0 = 2 (jedno fyzicke´ rozhranı´ a jedno loopback), prˇ´ıpadneˇ neˇjaky´ ten vy´tvor virtualizacˇnı´ho softwaru, na smeˇrovacˇi bude rozhranı´ vı´ce.
Uva´dı´me zde sice „absolutnı´“ adresy, ale je mozˇne´ adresovat take´ relativneˇ uvnitrˇ dane´ho MIB souboru (skupiny), naprˇ´ıklad ve skupineˇ interfaces, ip nebo system. Struktura MIB je celkem logicka´. Jak bylo vy´sˇe uvedeno, ve veˇtvi mib-2 najdeme promeˇnne´, ktere´ se nety´kajı´ prˇ´ımo konkre´tnı´ho vy´robce (tj. obecne´ informace), kdezˇto ve veˇtvi private.enterprise jsou promeˇnne´ ty´kajı´cı´ se vy´robku˚ od konkre´tnı´ch vy´robcu˚ (za´lezˇ´ı, co konkre´tneˇ v prˇ´ıslusˇne´m sı´t’ove´m zarˇ´ızenı´ najdeme). Zarˇ´ızenı´, ktera´ nejsou pro MIB standardizovana´, jsou obvykle umı´steˇna ve veˇtvi experimental. Obecne´ informace o zarˇ´ızenı´, s jemib-2 (1) hozˇ MIB pracujeme, najdeme prˇedevsˇ´ım v podstromu uzlu system. Promeˇnne´ v neˇm obsazˇene´ vidı´me na obsystem (1) ra´zku 8.7. Je zde popis zarˇ´ızenı´ (sysDesysDescr sysServices scr), adresa OID vedoucı´ do veˇtve en(1) (7) terprises s podrobneˇjsˇ´ımi informacemi (sysObjectID), doba od zapnutı´ zarˇ´ızenı´ sysObjectID sysUpTime sysContact sysName sysLocation (2) (3) (4) (5) (6) v setina´ch sekundy (sysUpTime), kontaktnı´ u´daje ke spra´vci zarˇ´ızenı´ (sysConObra´zek 8.7: Podstrom uzlu system tact), na´zev zarˇ´ızenı´ prˇirˇazeny´ adminem (sysName), info o fyzicke´m umı´steˇnı´ zarˇ´ızenı´ (sysLocation) a cˇ´ıslo urcˇujı´cı´ vrstvy v ISO/OSI, na ktery´ch zarˇ´ızenı´ pracuje (sysServices). Prˇı´klad Vrat’me se k hodnoteˇ sysServices urcˇujı´cı´ vrstvy v ISO/OSI, na ktery´ch dane´ zarˇ´ızenı´ (to, na ktere´m je ulozˇena databa´ze dane´ho agenta) pracuje. Jednotlive´ bity te´to hodnoty jsou nastaveny podle podpory vrstev (bity zprava doleva od nejme´neˇ vy´znamne´ho bitu). Naprˇ´ıklad sysServices.0 = 10 znamena´, zˇe zarˇ´ızenı´ pracuje na L2 a L4 (22−1 + 24−1, tedy je nastaven druhy´ a cˇtvrty´ bit zprava) a znamena´ to, zˇe jde zrˇejmeˇ o switch (L2) a obsahuje funkcionalitu L4 pro u´cˇely spra´vy (transportnı´ vrstva).
P
8.6
MANAGEMENT V TCP/IP
195
Dalsˇ´ım uzˇitecˇny´m uzlem v obecne´ cˇa´sti MIB je uzel interfaces. Zde zjistı´me informace o rozhranı´ch zarˇ´ızenı´, informace o jednotlivy´ch zarˇ´ızenı´ch jsou v tabulce ifTable (do nı´zˇ jsme uzˇ trochu nahle´dli). Tato tabulka ma´ mnoho sloupcu˚, naprˇ´ıklad ifSpeed (nomina´lnı´ rychlost prˇenosu na rozhranı´), ifOperStatus (operacˇnı´ stav rozhranı´), pocˇet oktetu˚, prˇijaty´ch/odeslany´ch/zahozeny´ch unicast paketu˚, non-unicast paketu˚ (ifOctets, ifInUcastPkts, . . . ), atd.
P
Skutecˇnou rychlost rozhranı´ zjistı´me pouze tak, zˇe dvakra´t za sebou zjistı´me pocˇet prˇijaty´ch oktetu˚, odecˇteme a vydeˇlı´me de´lkou intervalu, ktery´ uplynul mezi teˇmito dveˇma nacˇtenı´mi hodnot.
8.6.3
Pouzˇı´va´nı´ protokolu SNMP
Protokol SNMP definuje prˇ´ıkazy (pro agenty a spra´vce):
• get-request – spra´vce zˇa´da´ informace z MIB; uvede na´zev promeˇnne´, jejı´zˇ hodnotu pozˇaduje, zı´ska´ hodnotu a na´zev te´to promeˇnne´, • get-next-request – u´cˇel je stejny´ (zˇa´dost o informace z MIB), spra´vce take´ uvede na´zev promeˇnne´, ale zı´ska´ hodnotu promeˇnne´ a da´le na´zev na´sledujı´cı´ promeˇnne´ z databa´ze, ktera´ je potomkem te´hozˇ uzlu (tj. pokud zˇa´dal o promeˇnnou ...2.1.1.3, dostane informaci o existenci promeˇnne´ ...2.1.1.4, na kterou se mu˚zˇe dotazovat na´sledneˇ), • set-request – spra´vce ukla´da´ informace do MIB, je nutny´ autorizovany´ prˇ´ıstup spra´vce, • trap – agent prˇeda´va´ spra´vci nevyzˇa´danou informaci o mimorˇa´dne´ uda´losti, • get-response – odpoveˇd’ agenta na prˇedchozı´ get-request od spra´vce, kromeˇ hodnot z MIB obsahuje take´ pu˚vodnı´ dotaz, protozˇe SNMP neumozˇnˇuje spra´vci pa´rovat dotaz/odpoveˇd’ (nestavove´ chova´nı´), • get-bulk – podobneˇ jako get-request, ale je mozˇne´ zˇa´dat i neˇkolik rˇa´dku˚ tabulky (od SNMPv2), • inform – komunikace mezi dveˇma spra´vci (od SNMPv2). Prˇ´ıkaz get-next-request pouzˇity´ ve vhodne´ smycˇce umozˇnˇuje zı´skat postupneˇ hodnoty stejny´ch atributu˚ prˇes vsˇechny objekty stejne´ho typu (sloupcova´ operace). Konkre´tneˇ mu˚zˇeme tyto prˇ´ıkazy (at’ uzˇ v textove´ nebo graficke´ podobeˇ) zada´vat v neˇktere´m z na´stroju˚ vytva´rˇejı´cı´ch rozhranı´ k SNMP. Lze pouzˇ´ıt naprˇ´ıklad tyto na´stroje: • net-snmp7 je open-source na´stroj pracujı´cı´ v textove´m rezˇimu, a to pod Linuxem, dalsˇ´ımi unixovy´mi syste´my a take´ pod Windows. Je to ve skutecˇnosti balı´k programu˚, ktery´ umozˇnˇuje vyuzˇ´ıvat plneˇ SNMP v ktere´koliv jeho verzi, vcˇetneˇ prˇ´ıjmu trapu˚. • MIB Browser8 je volneˇ sˇirˇitelna´ aplikace s graficky´m rozhranı´m umozˇnˇujı´cı´ pracovat s MIB. • GNetWatch9 je open-source aplikace s graficky´m rozhranı´m pro real-time monitoring sı´teˇ prˇes SNMP a ICMP. Dalsˇı´ informace o SNMP: • http://www.samuraj-cz.com/clanek/snmp-simple-network-management-protocol/ 7
net-snmp je ke stazˇenı´ na http://www.net-snmp.org/. MIB Browser je ke stazˇenı´ na http://www.ks-soft.net/hostmon.eng/mibbrowser/index.htm. 9 GNetWatch je dostupny´ 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/kas/p090/referaty/2007-podzim/ct/snmp.html
Syslog
Syslog je mechanismus logova´nı´ a souvisejı´cı´ch u´loh dostupny´ na kazˇde´m zarˇ´ızenı´, na ktere´m beˇzˇ´ı (te´meˇrˇ) jaky´koliv unixovy´ syste´m vcˇetneˇ Linuxu. Ja´drem mechanismu je de´mon10 syslogd. De´mon syslogd cˇte svu˚j vstup ze zarˇ´ızenı´ (socketu) /dev/log. Tento vstup filtruje (vybı´ra´ to, co ho zajı´ma´) podle konfigurace, ktera´ se nacha´zı´ v souboru /etc/syslog.conf (to je tedy jeho konfiguracˇnı´ soubor) a pak podle nastavenı´ ukla´da´ hla´sˇenı´ o takto zjisˇteˇny´ch uda´lostech do jednoho nebo vı´ce LOG souboru˚. Data, ktera´ syslogd prˇijı´ma´, se skla´dajı´ ze trˇ´ı cˇa´stı´: 1. kategorie urcˇuje typ nebo odesı´latele uda´losti, existujı´ tyto kategorie: • auth – autentizace uzˇivatelu˚, • authpriv – informace o autentizaci urcˇena´ pro administra´tora, • cron – zpra´vy od de´mona cron (pla´nova´nı´ procesu˚), • daemon – zpra´vy od ru˚zny´ch de´monu˚, • kern – zpra´vy od ja´dra (kernel), • lpr – zpra´vy od tiskove´ho subsyste´mu, • mail – zpra´vy ty´kajı´cı´ se elektronicke´ posˇty, • mark – cˇasova´ razı´tka (timestamps), ktere´ se pravidelneˇ zapisujı´ do logu, • news – diskusnı´ skupiny, • security – tote´zˇ co auth, • syslog – vlastnı´ zpra´vy syslogu (i z jine´ho uzlu v sı´ti), • user – obvykle zpra´vy od aplikacı´ v uzˇivatelske´m rezˇimu, • local0–local7 – pro tyto kategorie lze definovat vlastnı´ vy´znam, 2. priorita urcˇuje du˚lezˇitost uda´losti: • emerg – syste´m je nepouzˇitelny´ nebo va´zˇneˇ ohrozˇen (emergency), • alert – je nutny´ okamzˇity´ za´sah, • crit – kriticka´ situace, • err – chyba, • warning – varova´nı´, • notice – norma´lnı´, avsˇak vy´znamna´, zpra´va, • info – informativnı´ zpra´va, • debug – ladicı´ zpra´va (debugger), 3. vlastnı´ text zpra´vy. 10
Pro ty, kterˇ´ı zapomneˇli: de´mon je v unixovy´ch syste´mech neˇco podobne´ho jako sluzˇba ve Windows. Jde o syste´movy´ proces, ktery´ beˇzˇ´ı na pozadı´. Na´zvy de´monu˚ obvykle koncˇ´ı pı´smenem „d“.
8.7
SYSLOG
197
Tento typ informacı´ tedy syslog zı´ska´. Jak bylo vy´sˇe uvedeno, ve sve´m konfiguracˇnı´m souboru ma´ urcˇeno, co s takovy´m za´znamem prove´st. V tomto souboru jsou za´znamy ve formeˇ kategorie.priorita TAB cı ´l kategorie.=priorita TAB cı ´l kategorie.!priorita TAB cı ´l kategorie.!=priorita TAB cı ´l
tato a vysˇsˇ´ı priority pouze tato priorita vsˇechny priority kromeˇ te´to a vysˇsˇ´ıch vsˇechny priority kromeˇ te´to
(priorit mu˚zˇe by´t i vı´ce, oddeˇlujı´ se strˇednı´kem, tote´zˇ platı´ i o dvojicı´ch kategorie.priorita). Pokud je prˇed prioritou jen tecˇka, nastavenı´ platı´ pro uvedenou a vsˇechny vysˇsˇ´ı priority. Pokud chceme nastavenı´ omezit jen na zadanou prioritu, prˇida´me prˇed ni „=“. Symbol „!“ znamena´ negaci, tedy pokud je uveden, dana´ priorita (a vsˇechny vysˇsˇ´ı) nebude zahrnuta. Lze kombinovat: „!=“, nebude zahrnuta pouze uvedena´ priorita. Kategorii mu˚zˇeme zadat symbolem *. To znamena´, zˇe se konfigurace ty´ka´ jake´koliv kategorie. Mezi prioritami a cı´lem musı´ by´t vzˇdy alesponˇ jednou stisknuty´ tabula´tor, mezera nestacˇ´ı. Cı´l urcˇuje, kam konkre´tneˇ ma´ by´t uda´lost ozna´mena, logova´na. Mu˚zˇe to by´t bud’ konkre´tnı´ log soubor (vy´chozı´ nebo jaky´koliv jiny´), nebo vy´pis na konzolu cˇi prˇeposla´nı´ na jiny´ pocˇ´ıtacˇ v sı´ti. Pokud chceme, aby byla uda´lost ozna´mena vı´ce cı´lu˚m (naprˇ´ıklad zobrazena urcˇite´mu uzˇivateli a za´rovenˇ ulozˇena do souboru), oddeˇlı´me cı´le cˇa´rkou. Mozˇnosti: • soubor – vy´chozı´ je /var/log/messages, ale mu˚zˇeme si urcˇit na´zvy souboru˚ naprˇ´ıklad pro ru˚zne´ kategorie nebo priority, • @server.firma.cz nebo @IPadresa – uda´lost bude prˇeposla´na, • user1, user2, . . . – uda´lost bude ozna´mena zadane´mu uzˇivateli (to mu˚zˇe by´t root, admin, operator, apod., podle toho, jake´ ma´me vytvorˇene´ uzˇivatele), ale jen tehdy, kdyzˇ je uzˇivatel pra´veˇ prˇihla´sˇen, • * – uda´lost bude ozna´mena vsˇem prˇihla´sˇeny´m uzˇivatelu˚m, • @loghost – mu˚zˇeme pouzˇ´ıt, pokud v souboru /etc/hosts je definova´n cı´l loghost. Lze pouzˇ´ıt take´ prˇesmeˇrova´nı´ do pojmenovane´ roury, ze ktere´ pak mu˚zˇe cˇ´ıst jaky´koliv proces, ktery´ urcˇ´ıme (a pru˚beˇzˇneˇ zpracova´vat ozna´menı´ o uda´lostech), stacˇ´ı uve´st na´zev souboru a prˇed neˇj napsat symbol roury: kern.=err
|/var/log/jadro
Prˇı´klad Takto neˇjak mohou vypadat za´znamy v souboru /etc/syslog.conf: mail.*
/var/log/maillog
Vsˇechny uda´losti z kategorie mail jsou ulozˇeny do souboru /var/log/maillog security.*;security.!=debug
/var/log/secure
Vsˇechny uda´losti z kategorie security kromeˇ uda´losti s prioritou debug jsou ulozˇeny do souboru /var/log/secure cron.*
/var/log/cron
Vsˇechny uda´losti z kategorie cron jsou ulozˇeny do souboru /var/log/cron (to znamena´ uda´losti souvisejı´cı´ s pla´novany´m spousˇteˇnı´m procesu˚)
L
8.7
SYSLOG
kern.debug;auth.notice
198
/dev/console
Uda´losti ty´kajı´cı´ se ladeˇnı´ ja´dra a beˇzˇne´ a prˇesto vy´znamne´ uda´losti autentizace jsou vypsa´ny na syste´move´ konzoli authpriv.*
/var/log/secure
Vsˇechny „citliveˇjsˇ´ı“ uda´losti autentizace jsou ulozˇeny do souboru /var/log/secure lpr.info
/var/log/lpd-info
Informacˇnı´ zpra´vy a vsˇechny s vysˇsˇ´ı prioritou o uda´lostech z tiskove´ho subsyste´mu se ulozˇ´ı do /var/log/lpd-info *.err
admin,/var/log/errors
Vsˇechny chybove´ a va´zˇneˇjsˇ´ı zpra´vy jsou okamzˇiteˇ ozna´meny uzˇivateli admin (pokud je prˇihla´sˇen) a za´rovenˇ ulozˇeny do souboru /var/log/errors *.=crit
/var/log/messages,@loghost,root
Kriticke´ uda´losti jsou ulozˇeny do souboru /var/log/messages, posla´ny na adresu definovanou pod aliasem loghost a za´rovenˇ je okamzˇiteˇ informova´n root, pokud je prˇihla´sˇen *.emerg
*,/var/log/emergency
O mimorˇa´dneˇ nebezpecˇny´ch uda´lostech jsou informova´ni vsˇichni prˇihla´sˇenı´ uzˇivatele´ a za´rovenˇ je prˇida´n za´znam do souboru /var/log/emergency
Pokud chceme, aby syslog prˇijı´mal zpra´vy z jiny´ch syste´mu˚, musı´me spustit de´mona syslogd s parametrem -d (platı´ v Linuxu): /usr/sbin/syslogd -m 0 -r
Prˇepı´nacˇ -m urcˇuje de´lku intervalu, v jake´m se syslogd ozy´va´, tj. do logu zapisuje, zˇe „zˇije“. Nastavenı´m na 0 toto chova´nı´ zrusˇ´ıme. Parametr -r znamena´ „remote“, syslogd pak nasloucha´ na portu 514 a prˇijı´ma´ vsˇechny UDP pakety. Na FreeBSD je nutne´ pouzˇ´ıt jinou syntaxi: /usr/sbin/syslogd
(bez parametru˚, protozˇe nasloucha´nı´ na portu 514 je zde vy´chozı´ chova´nı´). Na FreeBSD je take´ mozˇne´ urcˇit uzly v sı´ti, jejichzˇ UDP pakety budou prˇijı´ma´ny. Odlisˇnou syntaxi (i od te´to) majı´ syste´my OpenBSD, Solaris a jine´, je tedy trˇeba vzˇdy prostudovat manua´lovou stra´nku: man syslogd
Take´ je mozˇne´, zˇe budeme muset povolit nasloucha´nı´ sluzˇby syslogd na UDP portu. To se provede v /etc/services rˇa´dkem syslog 512/UDP, ale je pravdeˇpodobne´, zˇe tam takovy´ za´znam uzˇ je. Na zarˇ´ızenı´ch, ze ktery´ch jsou UDP pakety prˇijı´ma´ny, je pak nastaveno vy´sˇe popsany´m zpu˚sobem zası´la´nı´ na tento „sbeˇrny´“ pocˇ´ıtacˇ. Pokud syslogd pra´veˇ beˇzˇ´ı a my jsme provedli zmeˇnu jeho konfigurace (v souboru /etc/syslog.conf), musı´me syslogd restartovat, aby zaregistroval zmeˇny ve sve´ konfiguraci. Zatı´m jsme si uka´zali, jake´ u´daje dosta´va´ syslogd na svu˚j vstup, podle cˇeho je filtruje a kam je ukla´da´. Zby´va´ na´m podı´vat se, v jake´m forma´tu. Na vy´stupu je za´znam obsahujı´cı´ • cˇas, kdy k uda´losti dosˇlo, • kategorii (kernel, mail apod.), • text zpra´vy.
MONITOROVA´NI´ SI´TEˇ
8.8
199
Soucˇa´stı´ nenı´ priorita, protozˇe ta uzˇ byla uplatneˇna prˇi filtrova´nı´. Mu˚zˇe zde by´t naprˇ´ıklad za´znam: Feb 21 10:00:28 IOL kernel: device eth0 left promiscuous mode
Kdyzˇ syslog nastavujeme, hodı´ se mozˇnost vyzkousˇenı´ jeho funkcˇnosti. K tomu mu˚zˇe slouzˇit na´stroj logger. Naprˇ´ıklad uda´lost kategorie daemon a priority info se zadanou zpra´vou vygenerujeme takto: logger -p daemon.info ”testujeme syslog”
Rucˇnı´ spra´va logu˚ mu˚zˇe by´t celkem na´rocˇna´. Je trˇeba hlı´dat obsah souboru˚ a navı´c sledovat jejich de´lku (vcˇas umazat starsˇ´ı za´znamy), stroj naslouchajı´cı´ na UDP portu by meˇl by´t dostatecˇneˇ chra´neˇn (je zde vysoke´ riziko DoS u´toku˚, tedy firewall je rozhodneˇ na mı´steˇ). S neˇktery´mi u´lohami mohou pomoci prˇ´ıdavne´ na´stroje. Naprˇ´ıklad rotaci logu˚ (vcˇetneˇ oznacˇova´nı´ cˇi odstranˇova´nı´ starsˇ´ıch za´znamu˚) zvla´dne logrotate. Existujı´ take´ propracovaneˇjsˇ´ı verze syslogu, naprˇ´ıklad syslog-ng (umı´ komunikovat i prˇes TCP a zvla´dne take´ regula´rnı´ vy´razy, nejen hveˇzdicˇku), nsyslogd (komunikuje prˇes TCP/SSL), Secure Syslog, Modular Syslog a dalsˇ´ı. Volneˇ sˇirˇitelny´ program NTSyslog11 (vlastneˇ sluzˇba, kterou mu˚zˇeme instalovat), umozˇnˇuje pouzˇ´ıvat syslog take´ ve Windows (logy z Windows lze posı´lat na vzda´leny´ syste´m a tam naprˇ´ıklad vyhodnocovat). Na´stroj logwatch12 mu˚zˇeme pouzˇ´ıt k sumarizaci logu˚, prova´dı´ analy´zu logu˚ za stanovene´ obdobı´ a vytva´rˇ´ı souhrnnou zpra´vu. Program swatch13 je uzˇitecˇny´, kdyzˇ naopak potrˇebujeme by´t o urcˇite´ uda´losti informova´ni pokud mozˇno okamzˇiteˇ – detekuje na´mi definovane´ situace a stanoveny´m zpu˚sobem informuje, a protozˇe je psa´n v perlu, je to velmi pruzˇny´ na´stroj vyuzˇ´ıvajı´cı´ regula´rnı´ vy´razy. Dalsˇı´ 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/
Monitorova´nı´ sı´teˇ Protokol RMON
RMON (Remote Monitoring) je protokol pouzˇ´ıvany´ prˇi monitorova´nı´ sı´teˇ. Je u´zce spjat s TCP/IP a SNMP, sve´ zpra´vy posı´la´ prˇes SNMP. Informace jsou ulozˇeny v MIB ve veˇtvi rmon (OID 1.3.6.1.2.1.16). Narozdı´l od SNMP agentu˚ doka´zˇe kromeˇ soucˇasne´ho stavu sledovat i historii (vy´voj) dane´ velicˇiny a na za´kladeˇ vyvozeny´ch du˚sledku˚ reagovat. 11
NTSyslog najdeme na http://ntsyslog.sourceforge.net. logwatch zı´ska´me na http://www.logwatch.org. 13 Program swatch (Simple Watch) je dostupny´ na http://swatch.sourceforge.net. 12
$
8.8
MONITOROVA´NI´ SI´TEˇ
200 mib-2 (1) rmon (16)
statistic (1)
filter (7)
history (2)
capture (8)
alarm (3)
hosts (4)
hostsTopN (5)
matrix (6)
event (9)
Obra´zek 8.8: Veˇtev rmon v MIB-II Z hlediska protokolu RMON rozlisˇujeme dva druhy zarˇ´ızenı´ v sı´ti: • RMON-compliant console manager (spra´vce) – spra´vce cele´ LAN • RMON probe (sonda) – zası´la´ informace spra´vci, jedna sonda pracuje v ra´mci jednoho segmentu LAN (naprˇ´ıklad uvnitrˇ jedne´ koliznı´ dome´ny) RMON pracuje s tzv. skupinami. Kazˇda´ skupina v sobeˇ zahrnuje urcˇity´ typ informace, ktera´ je sledova´na. Skupiny jsou zvla´sˇt’ definova´ny pro Ethernet a Token Ring, pro Ethernet jsou to tyto skupiny: • Statistics – statistika (okamzˇity´ stav) sledovany´ch zarˇ´ızenı´ (mnozˇstvı´ odeslany´ch paketu˚, broadcast a multicast paketu˚, oktetu˚, chyb v CRC soucˇtech, kolizı´ apod., take´ cˇ´ıtacˇe, naprˇ´ıklad pro pocˇty paketu˚ o velikosti z dane´ho intervalu), • History – tote´zˇ jako statistika, ale evidova´no v historii, • Alarms – pro neˇktere´ sledovane´ velicˇiny jsou stanoveny prahove´ hodnoty, a kdyzˇ je tato prahova´ hodnota prˇekrocˇena, generuje se prˇ´ıslusˇna´ uda´lost, • Hosts – vedou se statistiky typicke´ pro jednotlive´ uzly v sı´ti (segmentu sı´teˇ) – adresa, odeslane´/prˇijate´ pakety, chyby v CRC soucˇtech a zahozene´ pakety cˇi ra´mce, • HostsTopN – podobneˇ jako prˇedchozı´, uzly jsou serˇazeny v tabulka´ch podle konkre´tnı´ sledovane´ velicˇiny, • Matrix – sledujı´ se velicˇiny souvisejı´cı´ s konverzacı´ mezi dveˇma uzly v sı´ti, pro kazˇdou komunikujı´cı´ dvojici uzlu˚, • Filters – umozˇnˇujı´ definovat filtry pro zachycenı´ neˇktery´ch paketu˚ nebo generova´nı´ urcˇite´ uda´losti prˇi pru˚chodu urcˇeny´ch paketu˚, • Packet Capture – definujı´ se podmı´nky pro zachyta´va´nı´ paketu˚ (naprˇ´ıklad velikost vyrovna´vacı´ pameˇti pro zachycene´ pakety, pocˇet zachyceny´ch paketu˚, kdy vyvolat alarm apod.), • Events – generova´nı´ a oveˇrˇova´nı´ uda´lostı´ (eviduje se typ uda´losti, jejı´ popis a cˇasovy´ u´daj poslednı´ho vygenerova´nı´ te´to uda´losti dany´m zarˇ´ızenı´m). Zarˇ´ızenı´ prˇipojena´ v sı´ti obvykle podporujı´ veˇtsˇinu teˇchto skupin, v idea´lnı´m prˇ´ıpadeˇ vsˇechny. Tedy sledujeme ty promeˇnne´ v MIB, ktere´ na´s zajı´majı´. Hlavnı´m prˇ´ınosem RMON je prˇenos velke´ cˇa´sti zpracova´nı´ dat od spra´vcu˚ na agenty (sondy), cˇ´ımzˇ se take´ snizˇuje mnozˇstvı´ prˇena´sˇeny´ch dat v sı´ti.
P P
MONITOROVA´NI´ SI´TEˇ
8.8
8.8.2
201
Snort
Snort14 je jednoduchy´ volneˇ sˇirˇitelny´ syste´m (open-source licence, ale pro aktualizace je nutne´ se registrovat, „okamzˇite´“ aktualizace jsou navı´c placene´), ktery´ mu˚zˇeme zarˇadit mezi NIDS (Network Intrusion Detection System). Snort pracuje v jednom ze trˇ´ı mozˇny´ch rezˇimu˚: • sniffer („prohlı´zˇecˇ“ provozu) – slidicˇ, data z hlavicˇek paketu˚ vypisuje na obrazovku nebo neˇkam posı´la´, • logova´nı´ provozu – data ukla´da´ na disk a/nebo do databa´ze, • plny´ NIDS vcˇetneˇ pouzˇ´ıva´nı´ pravidel – analy´za hlavicˇek paketu˚.
P P
Vy´stupy doka´zˇe Snort bud’ ukla´dat do LOG souboru, nebo zası´lat syslogu, posı´lat jako SNMP trap, ukla´dat do databa´ze a nebo dokonce podle nich nastavovat konfiguraci neˇktery´ch sı´t’ovy´ch prvku˚. Snort funguje na principu detekce signatur v kombinaci s pravidly. Mnoho pravidel je vytvorˇeno uzˇ prˇi instalaci (je jich opravdu hodneˇ, neˇkdy to chce trochu je promazat), a take´ je mozˇne´ prˇidat pravidla vlastnı´ podle konkre´tnı´ situace v sı´ti. Vyuzˇ´ıva´nı´ pravidel da´va´ syste´mu obecneˇ veˇtsˇ´ı sı´lu (naprˇ´ıklad kombinace „mı´rneˇ podezrˇely´ch“ akcı´ je velmi podezrˇela´ a narozdı´l od syste´mu˚ zalozˇeny´ch pouze na signatura´ch syste´m generuje me´neˇ falesˇny´ch poplachu˚. Obecny´ tvar pravidel je action protocol sourceIP sourcePort direction destIP destPort (options)
Action akce) mu˚zˇe by´t naprˇ´ıklad pass (prˇeda´nı´, tj. ignorova´nı´ paketu), log (zaznamena´nı´), alert (vy´straha), drop (zahodit paket), atd. Na´sledujı´ vlastnosti paketu, podle nich pozna´ Snort, zˇe ma´ pravidlo pouzˇ´ıt (protokol, trˇeba TCP, da´le zdrojova´ a cı´lova´ adresa a port, a take´ smeˇr prˇenosu paketu zachyceny´ „sˇipkou“). Poslednı´ cˇa´stı´ pravidla jsou options – volby, ktere´ ve skutecˇnosti popisujı´, co se ma´ sta´t, kdyzˇ Snort zachytı´ paket odpovı´dajı´cı´ u´daju˚m v pravidlu a take´ co dalsˇ´ıho ma´ by´t testova´no (naprˇ´ıklad pole TTL paketu nebo ICMP informace). Naprˇ´ıklad:
$
alert tcp any 3389 -> 81.28.192.0/24 3389 (msg: ”TCP paket na Net5”;)
To znamena´, zˇe ma´ by´t generova´na vy´straha, pokud je nalezen TCP paket z jake´koliv adresy na portu 3389 mı´rˇ´ıcı´ do sı´teˇ s danou IP adresou (pouzˇ´ıvajı´ se CIDR adresy s prefixem), a to na tomte´zˇ portu. S vy´strahou se ma´ vygenerovat zpra´va v zadane´m zneˇnı´ (zpra´va je nahla´sˇena a ulozˇena do logu). Ve skutecˇnosti by´vajı´ pravidla poneˇkud sofistikovaneˇjsˇ´ı a mohou obsahovat take´ naprˇ´ıklad popis porovna´nı´ se signaturou a dalsˇ´ı volby. V uvedene´m prˇ´ıkladu jsou konkre´tnı´ adresy, ale lze vyuzˇ´ıt take´ promeˇnne´, ve ktery´ch ma´ Snort prˇeddefinovanou adresu vnitrˇnı´ sı´teˇ a neˇktere´ dalsˇ´ı adresy, naprˇ´ıklad alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:”ICMP Large ICMP Packet”; dsize: >800;)
Snort funguje podobneˇ jako prˇedchozı´ popsane´ mechanismy vcˇetneˇ SNMP (spra´vce+agenty). Agenty se nazy´vajı´ sondy a nacha´zejı´ se v ru˚zny´ch oblastech infrastruktury, podle potrˇeby (umı´steˇnı´ stanovı´me podle typu informacı´, ktere´ chceme zı´ska´vat, za´lezˇ´ı na tom, jestli je sonda prˇed cˇi za firewallem, v DMZ, v dane´ koliznı´ dome´neˇ apod.). 14
Snort zı´ska´me na http://www.snort.org.
P
MONITOROVA´NI´ SI´TEˇ
8.8
202
Obecneˇ jde o dobrˇe rozsˇirˇitelny´ syste´m. Pokud ma´me vı´ce sond a na sı´ti je veˇtsˇ´ı provoz (cozˇ znamena´ velke´ mnozˇstvı´ za´znamu˚), doporucˇuje se pouzˇ´ıt neˇktery´ databa´zovy´ syste´m, naprˇ´ıklad MySQL. Existujı´ take´ frameworky (rozhranı´), ktere´ zjednodusˇujı´ prˇ´ıstup a analy´zu dat Snortu, naprˇ´ıklad Prelude,15 cozˇ je framework pouzˇitelny´ nejen pro Snort, ale take´ naprˇ´ıklad pro Nessus. Dalsˇ´ı syste´m, ktery´ zjednodusˇuje pouzˇ´ıva´nı´ Snortu, je ACID16 (Analysis Console for Intrusion Databases). ACID je zajı´mavy´ uzˇ proto, zˇe se s jeho pouzˇitı´m pocˇ´ıta´ v doporucˇenı´ch pracovnı´ch skupin CERT (setkali jsme se s nimi u CESNETu). ACID potrˇebuje webovy´ server (trˇeba Apache), funkcˇnı´ PHP a databa´zi, do ktere´ Snort ukla´da´ za´znamy (trˇeba MySQL). Dalsˇı´ 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 toku˚. Tok (flow) je to, co obvykle povazˇujeme za u´plnou sı´t’ovou konverzaci. V prˇ´ıpadeˇ prˇenosu˚ realizovany´ch spojovy´mi stavovy´mi protokoly (jako je naprˇ´ıklad TCP) do jednoho toku patrˇ´ı nejen odesla´nı´ jednoho paketu, ale komunikace v ra´mci cele´ho spojenı´ (ale pouze jednı´m smeˇrem, tedy obousmeˇrna´ komunikace je technicky ve dvou tocı´ch). Do jedine´ho spolecˇne´ho toku take´ patrˇ´ı naprˇ´ıklad sekvence ICMP paketu˚ vyslany´ch v ra´mci jedine´ho prˇ´ıkazu ping. Kazˇdy´ tok je jednoznacˇneˇ popsa´n teˇmito u ´ daji: • zdrojova´ IP adresa • cı´lova´ IP adresa
15
NetFlow
NetFlow je protokol vyvinuty´ firmou Cisco. S jeho podporou se tedy setka´me prˇedevsˇ´ım na zarˇ´ızenı´ch od te´to firmy, ale take´ v zarˇ´ızenı´ch firmy Juniper a neˇktery´ch dalsˇ´ıch firem (prˇesneˇji: tato zarˇ´ızenı´ mohou exportovat informace ve stejne´m forma´tu jako NetFlow). Nemusı´ jı´t jen o smeˇrovacˇe a prˇepı´nacˇe, ale existujı´ take´ jednoducha´ prˇenosna´ zarˇ´ızenı´, ktera´ plnı´ pouze roli sledova´nı´ sı´teˇ tı´mto zpu˚sobem. Na NetFlow je zalozˇen standard IPFIX.
16
$
• zdrojovy´ port • cı´lovy´ port
• IP protokol • typ sluzˇ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 take´ mu˚zˇe by´t rozdeˇlena do vı´ce toku˚, pokud trva´ prˇ´ılisˇ dlouho (na smeˇrovacˇ´ıch Cisco je to naprˇ´ıklad 30 minut), nebo je delsˇ´ı dobu neaktivnı´ a nebo je zaplneˇna vyrovna´vacı´ pameˇt’ zarˇ´ızenı´ (toky nenı´ kam ukla´dat, proto ty starsˇ´ı budou vymaza´ny). Mı´sto zjisˇt’ova´nı´ informacı´ (s protokolem NetFlow) se nazy´va´ Observation Point (take´ NetFlow Exporter). Toto zarˇ´ızenı´ zjisˇt’uje z pru˚chozı´ch paketu˚ potrˇebne´ informace a odesı´la´ je flow kolektoru. Flow kolektor je hardware nebo software, ktery´ prˇijı´ma´ data o tocı´ch a zpracova´va´. Jeden flow kolektor mu˚zˇe prˇijı´mat data od vı´ce observation pointu˚. Kromeˇ ukla´da´nı´ dat na Flow kolektoru jesˇteˇ potrˇebujeme aplikaci, ktera´ by zjednodusˇila analy´zu teˇchto dat. Existuje vı´ce takovy´ch aplikacı´, mnohe´ volneˇ sˇirˇitelne´. • OSU Flow-Tools17 jsou volneˇ sˇirˇitelny´ balı´k programu˚ pro textovy´ rezˇim vyvı´jeny´ na univerziteˇ v Ohiu. V balı´ku najdeme na´stroje na shromazˇd’ova´nı´ dat na flow kolektoru a zpracova´nı´ u´daju˚ o tocı´ch.
P $
• NFDump18 je volneˇ sˇirˇitelny´ kolektor (distribuovany´ pod BSD licencı´). Existuje pro neˇj take´ graficka´ na´stavba NFSen,19 ktera´ je vlastneˇ webovy´m rozhranı´m. Dı´ky „koncentrovaneˇjsˇ´ım“ informacı´m, ktere´ NetFlow umozˇnˇuje zı´ska´vat, lze odhalit naprˇ´ıklad DoS u´tok (vsˇechny pakety v ra´mci tohoto u´toku majı´ spolecˇne´ posuzovane´ parametry, patrˇ´ı do jednoho toku), ale ne naprˇ´ıklad DDoS u´tok (je z mnoha zdroju˚, obvykle z pocˇ´ıtacˇu˚ neˇktere´ho rozsa´hle´ho botnetu) ani skenova´nı´ uzlu˚ v sı´ti (ru˚zne´ cı´love´ adresy).
8.9 8.9.1
WBEM Princip WBEM
WBEM (Web-Based Enterprise Management) je skupina technologiı´ a postupu˚ vytvorˇena´ za u´cˇelem sjednotit spra´vu distribuovany´ch pocˇ´ıtacˇovy´ch prostrˇedı´ (tj. vcˇetneˇ vzda´lene´ spra´vy). Spra´va se prova´dı´ bud’ prˇes webove´ rozhranı´ nebo pomocı´ specializovany´ch shellu˚. Data jsou organizova´na v modelu CIM (Common Information Model), ktery´ je otevrˇeny´m stan´ cˇelem je jednotny´m zpu˚sobem popisovat, uchova´vat a poskytovat potrˇebne´ informace dardem. U bez ohledu na jejich zdroj a pouzˇity´ protokol. Jedna´ se vlastneˇ o objektoveˇ orientovanou databa´zi, kde jednotlive´ objekty jsou zapouzdrˇeny a prˇistupuje se k nim prˇes unifikovane´ rozhranı´. Rozlisˇujeme WBEM server (ukla´da´ a poskytuje informace, prova´dı´ prˇ´ıkazy) a WBEM klienta (reprezentova´n prˇedevsˇ´ım rozhranı´m, se ktery´m pracuje administra´tor, a prˇ´ıslusˇny´m API). Klient odesı´la´ zˇa´dosti, server konfrontuje se skutecˇny´m stavem a prova´dı´ je (prˇ´ıpadneˇ zajisˇt’uje proces autentifikace a autorizace). Spolu komunikujı´ prˇes protokol HTTP nebo HTTPS. Pra´veˇ podle teˇchto protokolu˚ je v na´zvu „web-based“. (Pozor, rozhodneˇ to neznamena´, zˇe se komunikuje prˇes webovy´ prohlı´zˇecˇ!) 17
OSU Flow-Tools zı´ska´me na http://www.splintered.net/sw/flow-tools/. NFDump je dostupny´ na http://nfdump.sourceforge.net/. 19 NFSen je dostupny´ na http://nfsen.sourceforge.net/.
18
P P
8.9
WBEM
204
Architektura je postavena na vzoru model–obraz. Klient cˇte data z „obrazu“, server prˇistupuje k „modelu“ reprezentovane´mu skutecˇny´m stavem hardwaru a softwaru v sı´ti a prˇi jake´koliv zmeˇneˇ modelu aktualizuje obraz. WBEM nema´ nahradit protokoly CMIP a SNMP, ale je jakousi na´stavbou teˇchto modelu˚ zjednodusˇujı´cı´ prˇ´ıstup administra´tora k informacı´m. WBEM ma´ vı´ce ru˚zny´ch implementacı´, naprˇ´ıklad: WMI (Windows Management Instrumentation) je implementace Microsoftu pro Windows. Umozˇnˇuje (i vzda´leneˇ) spravovat pocˇ´ıtacˇe s Windows v sı´ti, je prˇedinstalova´na na vsˇech verzı´ch od Win 2000 (resp. Win ME). Je postavena na VBScriptu a PowerShellu, WMI teˇmto skriptovacı´m jazyku˚m poskytuje prˇ´ıstup prakticky k cˇemukoliv ve Windows. Neˇktere´ dalsˇ´ı na´stroje, ktere´ nejsou instalova´ny se syste´mem, je mozˇne´ sta´hnout ze stra´nek Microsoftu http://www.microsoft.com/downloads/ details.aspx?familyid=6430F853-1120-48DB-8CC5-F2ABDC3ED314&displaylang=en. OpenWBEM od Novellu je implementace urcˇena´ pro Novell Netware, Linux a neˇktere´ jine´ Unixove´ syste´my (vcˇetneˇ Solarisu a MacOSX). Je pouzˇ´ıva´na v komercˇnı´ i nekomercˇnı´ sfe´rˇe a stejneˇ jako WMI nabı´zı´ rozsa´hle´ mozˇnosti za´sahu˚ do konfigurace sı´teˇ a monitorova´nı´. Je ke stazˇenı´ na http://www.openwbem.org/. OpenPegasus je dalsˇ´ı otevrˇena´ implementace pro ru˚zne´ Unixove´ syste´my vcˇetneˇ Linuxu, a Windows. Je ke stazˇenı´ na http://www.openpegasus.org/. V Linuxu (v mensˇ´ıch sı´tı´ch) se hodneˇ pouzˇ´ıva´ na´stroj Webmin, ktery´ zrˇejmeˇ nenı´ prˇ´ımo implementacı´ WBEM, ale ma´ hodneˇ podobne´ mozˇnosti. Poskytuje sjednocene´ rozhranı´ v internetove´m prohlı´zˇecˇi a umozˇnˇuje monitorovat, vyhodnocovat a konfigurovat uzly v sı´ti. Varianta s omezeny´mi pra´vy, kterou mohou pouzˇ´ıvat beˇzˇnı´ uzˇivatele´, se nazy´va´ usermin. Da´le existuje varianta Virtualmin pro hromadnou spra´vu virtua´lnı´ch hostitelu˚ (naprˇ´ıklad v serveru Apache). Webmin je ke stazˇenı´ na http://webmin.com/.
´ vodnı´ okno aplikace WbemTest Obra´zek 8.9: U
P P P P
8.9
8.9.2
WBEM
205
WMI
Jak bylo vy´sˇe uvedeno, WMI je implementace modelu WBEM pro spra´vu Windows. Databa´ze CIM je takte´zˇ objektova´, jde o objekty plnohodnotne´ s implementacı´ trˇ´ıd, vlastnostı´, metod, uda´lostı´, vyuzˇ´ıvajı´cı´ deˇdicˇnost a kompozici. Trˇ´ıdy jsou psa´ny v objektove´m jazyce MOF (Managed Object Format), ktery´ je interpretovany´ (da´ se rˇ´ıct skriptovacı´). Veˇtsˇina komponent WMI (vcˇetneˇ trˇ´ıd) je v adresa´rˇi ...\System32\Wbem. Najdeme tam hodneˇ souboru˚ s prˇ´ıponou MOF. Pokud na´s zajı´ma´, jak vlastneˇ vypadajı´ trˇ´ıdy WMI, mu˚zˇeme se na neˇ podı´vat v na´stroji, ktery´ je soucˇa´stı´ Windows od verze XP. WbemTest se spousˇtı´ prˇ´ıkazem wbemtest a ma´ graficke´ rozhranı´. Po spusˇteˇnı´ se objevı´ za´kladnı´ okno, ktere´ vidı´me na obra´zku 8.9.
P $
Nejdrˇ´ıv je nutne´ se prˇipojit k urcˇite´mu oboru na´zvu˚ (zobrazuje se v leve´m hornı´m rohu okna), na obra´zku 8.9 jsme prˇipojeni k oboru na´zvu˚ CIMV2 (k oboru na´zvu˚ se jednodusˇe prˇipojı´me tak, zˇe klepneme na tlacˇ´ıtko Prˇipojit a zada´me na´zev). Pak mu˚zˇeme volneˇ pracovat se trˇ´ıdami, ktere´ do zvolene´ho oboru na´zvu patrˇ´ı (take´ vytva´rˇet nove´). Pokud si chceme prohle´dnout (nebo upravit) vlastnosti neˇktere´ trˇ´ıdy dane´ho oboru na´zvu˚, klepneme v hlavnı´m okneˇ na tlacˇ´ıtko Vy´cˇet trˇ´ıd. Zobrazı´ se dialogove´ okno (obra´zek 8.10), do ktere´ho bud’ zada´me prˇ´ımo na´zev trˇ´ıdy, a nebo zvolı´me „rekurzivnı´ “ vy´cˇet (to znamena´, zˇe budou vypsa´ny vsˇechny trˇ´ıdy z oboru na´zvu˚). V seznamu pak poklepeme na vybranou trˇ´ıdu a zobrazı´ se okno se vsˇemi jejı´mi vlastnostmi a metodami (obra´zek 8.11).
Obra´zek 8.10: Stanovenı´ trˇ´ıdy
Obra´zek 8.11: Vlastnosti zvolene´ trˇ´ıdy Win32_Process Kromeˇ vy´sˇe uvedene´ho na´stroje WbemTest lze ke sluzˇbeˇ WMI prˇistupovat prˇes konzolu Rˇ´ızenı´ sluzˇby WMI. Spousˇtı´me ji souborem wmimgmt.msc, ale je dostupna´ take´ v konzole Spra´va pocˇ´ıtacˇe, jak vidı´me na obra´zku 8.12. V kontextove´m menu polozˇky Rˇ´ızenı´ sluzˇby WMI zvolı´me Vlastnosti
$
8.9
WBEM
206
a zı´ska´me okno, ktere´ vidı´me na obra´zku 8.12 vpravo. Nastavujeme obecne´ vlastnosti rˇ´ızenı´ WMI jako je zpu˚sob protokolova´nı´ a umı´steˇnı´ protokolu, za´lohova´nı´ (ma´me mozˇnost obnovit databa´zi WMI ze za´lohy) a urcˇujeme zabezpecˇenı´ prvku˚ databa´ze.
Obra´zek 8.12: Vlastnosti v konzole Rˇ´ızenı´ sluzˇby WMI Dalsˇ´ım velmi uzˇitecˇny´m na´strojem pro rˇ´ızenı´ WMI je program wmic.exe, ktere´mu se budeme podrobneˇji veˇnovat da´le. Pomocı´ tohoto na´stroje mu˚zˇeme prˇistupovat k databa´zi WMI a zı´ska´vat z nı´ nejru˚zneˇjsˇ´ı informace. Na webu Microsoftu lze zı´skat WMI Administrative Tools,20 cozˇ je balı´k neˇkolika na´stroju˚ pro pra´ci s WMI objekty. Je uzˇitecˇny´ zejme´na pro programa´tory sluzˇeb, v na´strojı´ch balı´ku se dostaneme prakticky k jaky´mkoliv informacı´m, navı´c prˇehledneˇ a srozumitelneˇ cˇleneˇny´m. Rozhranı´ WMI se velmi cˇasto pouzˇ´ıva´ ve skriptech (pomocı´ VB skriptu se takto dostaneme prakticky k cˇemukoliv, co na pocˇ´ıtacˇi potrˇebujeme, i prˇes sı´t’). Skripty mu˚zˇeme vytva´rˇet bud’ rucˇneˇ, a nebo v neˇktere´m na´stroji pro generova´nı´ WMI skriptu˚. Hodneˇ pouzˇ´ıvane´ jsou naprˇ´ı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 spousˇteˇlo jako sluzˇba s vlastnı´m procesem, od verze XP (Server 2003) jde o sluzˇbu spousˇteˇnou v ra´mci procesu svchost.exe. Kdykoliv se spousˇtı´ neˇco souvisejı´cı´ho s WMI (naprˇ´ıklad pozˇadavek na data z databa´ze CIM), ko´d je spousˇteˇn v procesu wmiprvse.exe, ktery´ je potomkem procesu hostı´cı´ho sluzˇbu RPC. 20
WMI Administrative Tools zı´ska´me na adrese http://www.microsoft.com/downloads/details.aspx?FamilyID= 6430f853-1120-48db-8cc5-f2abdc3ed314. V balı´ku najdeme na´stroje WMI Object Browser (zobrazuje objekty v hierarchicke´ strukturˇe i jejich metody, metody mu˚zˇeme i spousˇteˇt), WMI CIM Studio (pro pra´ci s trˇ´ıdami), WMI Event Registration Tool a WMI Event Viewer (pro pra´ci s uda´lostmi objektu˚). 21 WMI Code Creator je dostupny´ na stra´nce http://www.microsoft.com/downloads/details.aspx?familyid=2CC30A64- EA15-4661-8DA4-55BBC145C30E. 22 Scriptomatic zı´ska´me na adrese http://www.microsoft.com/downloads/details.aspx?familyid=09DFC342- 648B-4119-B7EB-783B0F7D1178.
$
8.10
DOHLEDOVE´ SYSTE´MY
207
Program wmic (WMI Console) je dostupny´ od verze Windows XP/Server 2003. Umozˇnˇuje vyuzˇ´ıvat rozhranı´ WMI na prˇ´ıkazove´m rˇa´dku. pracuje ve dvou rezˇimech – klasicke´m (externı´m) a interaktivnı´m. Tomuto prˇ´ıkazu se veˇnujeme v prˇ´ıloze (kapitola B.5, strana 243). ´ koly U V prˇ´ıloze najdeˇte sekci o programu wmic a vyzkousˇejte neˇktere´ z uvedeny´ch uka´zek jeho pouzˇ´ıva´nı´.
8.10
Dohledove´ syste´my
Dohledovy´ syste´m (network management software) je syste´m, ktery´ doka´zˇe monitorovat stav sı´teˇ (ru˚zne´ velicˇiny), tedy sbı´rat informace z ru˚zny´ch zdroju˚ na sı´ti, generovat reporty a v prˇ´ıpadeˇ proble´mu˚ (abnorma´lnı´ hodnoty sledovany´ch velicˇin, velke´ vy´kyvy apod.) vhodneˇ reagovat (naprˇ´ıklad odeslat informaci adminovi).
P
Kdyzˇ si vybı´ra´me dohledovy´ syste´m, bereme v u´vahu: • co vsˇe mu˚zˇe by´t monitorova´no (mnozˇstvı´ a typy monitorovany´ch sluzˇeb), • konkre´tnost hla´sˇenı´ (neˇktere´ poruchy jsou „hierarchicke´“, tedy pokud neˇco selzˇe v du˚sledku selha´nı´ neˇcˇeho jine´ho, nemeˇl by report zahrnovat vsˇe, ale pouze „korˇen proble´mu“), • rozhranı´, dnes beˇzˇneˇ graficke´, meˇlo by by´t dostatecˇneˇ prˇehledne´ a vhodneˇ hierarchicky cˇleneˇne´, hodneˇ za´lezˇ´ı na tom, co si lze zobrazit a v jake´ formeˇ, mozˇnost vizualizovat nejru˚zneˇjsˇ´ı datove´ toky cˇi cokoliv dalsˇ´ıho, co se mu˚zˇe s cˇasem meˇnit, • zpu˚sob zası´la´nı´ hla´sˇenı´ – prˇes SMTP server (prˇ´ıp. mu˚zˇe by´t i integrovany´), SMS, pager, • mozˇnosti nastavenı´ uzˇivatelsky´ch opra´vneˇnı´ pro prˇ´ıstup k evidovany´m informacı´m, • funkcˇnı´ omezenı´ – zpu˚sob komunikace s hlı´dany´mi zarˇ´ızenı´mi (prˇes ktery´ protokol, naprˇ. SNMP), zpu˚sob logova´nı´, atd. Existujı´ jak open-source, tak i komercˇnı´ dohledove´ syste´my. Ke komercˇnı´m patrˇ´ı naprˇ´ıklad WhatsUp Gold,23 SonicWALL,24 a dalsˇ´ı. Na neˇktere´ open-source produkty se podı´va´me v na´sledujı´cı´m textu.
8.10.1
Nagios
Nagios je velmi oblı´beny´ open-source monitorovacı´ (dohledovy´) syste´m. Zvla´da´ nejen samotne´ monitorova´nı´, ale i vizualizaci. Doka´zˇe monitorovat ru˚zne´ typy sı´t’ovy´ch sluzˇeb (HTTP, POP3, ICMP, SMTP), nema´ proble´my s sˇifrova´nı´m, monitoruje take´ vyuzˇ´ıva´nı´ prostrˇedku˚ na uzlech sı´teˇ (rozumı´ si s ru˚zny´mi operacˇnı´mi syste´my vcˇetneˇ Windows), zvla´da´ vizualizaci stavu sı´teˇ (take´ doka´zˇe vykreslit topologii sı´teˇ vcˇetneˇ 3D grafu). Pro konfiguraci lze pouzˇ´ıt webove´ rozhranı´ (ale je mozˇne´ vyuzˇ´ıvat jina´ rozhranı´, naprˇ´ıklad Centreon v kombinaci s MySQL). Vznikl novy´ fork (odnozˇ) Nagiosu, ktery´ se nazy´va´ Icinga.25 Podle vy´voja´rˇu˚ tohoto forku je u´cˇelem prˇedevsˇ´ım zrychlit a zpruzˇnit vy´voj. 23
http://www.annexnet.cz/ipswitch-whatsupgold-popis-produktu/ http://www.sonicwall.com/ 25 Syste´m Icinga vcˇetneˇ zdu˚vodneˇnı´ jejı´ho vzniku najdeme na http://www.icinga.org/. 24
J
DOHLEDOVE´ SYSTE´MY
8.10
208
Dalsˇı´ 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 dalsˇ´ım oblı´beny´m open-source monitorovacı´m syste´mem. Potrˇebujeme Zabbix Server (ten nainstalujeme na dohledovy´ server, meˇl by na neˇm beˇzˇet neˇktery´ unixovy´ syste´m vcˇetneˇ Linuxu) a Zabbix agenty (na klientsky´ch zarˇ´ızenı´ch, ru˚zne´ operacˇnı´ syste´my vcˇetneˇ Windows). Konfigurace se prova´dı´ opeˇt prˇes webove´ rozhranı´, tedy po za´kladnı´ orientaci nic moc slozˇite´ho.
J
Funkcˇnost je podobna´, snad mı´rneˇ nizˇsˇ´ı, nezˇ v prˇ´ıpadeˇ Nagiosu, obvykle je Zabbix povazˇova´n za jednodusˇsˇ´ı ve vybavenosti a konfiguraci (Nagios je zase povazˇova´n za stabilneˇjsˇ´ı). Takte´zˇ podporuje SNMP a agenty je mozˇne´ instalovat na ru˚zne´ operacˇnı´ syste´my. Dalsˇı´ 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 dohledovy´ syste´m, ktery´ je narozdı´l od prˇedchozı´ch napsa´n v Javeˇ. Je urcˇen pro monitorova´nı´ rozsa´hly´ch sı´tı´ s velky´m mnozˇstvı´m sledovany´ch zarˇ´ızenı´. Monitoring mu˚zˇe by´t distribuovany´ (na vı´ce serverech), dı´ky tomu lze monitorovat tak velke´ mnozˇstvı´ zarˇ´ızenı´.
J
Jde o dobrˇe rozsˇirˇitelny´ syste´m. Monitoring ru˚zny´ch sluzˇeb je rˇesˇen pomocı´ pluginu˚ (podporu monitorova´nı´ dalsˇ´ı sluzˇby lze prˇidat jednodusˇe prˇida´nı´m pluginu). Konfigurace se opeˇt prova´dı´ prˇes webove´ rozhranı´. Pra´ci se syste´mem je mozˇne´ si vyzkousˇet na demo aplikaci na stra´nka´ch projektu. Dalsˇı´ 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 dalsˇ´ı open-source dohledovy´ syste´m (prˇesneˇji jeho jedna varianta je open-source volneˇ ke stazˇenı´, druha´ – Enterprise – je komercˇnı´). Je postaven na mysˇlence vyuzˇitı´ existujı´cı´ch opensource projektu˚. 26
Zabbix je dostupny´ na http://www.zabbix.com/. Informace o OpenNMS najdeme na http://www.opennms.org/wiki/Main Page. 28 Zenoss je dostupny´ na http://www.zenoss.com/. 27
J
DOHLEDOVE´ SYSTE´MY
8.10
209
Jeho ja´drem je objektovy´ webovy´ server Zope napsany´ v jazyce Python, a take´ v Pythonu je mozˇne´ Zenoss da´le rozsˇirˇovat (dokonce lze u´dajneˇ pouzˇ´ıvat i pluginy z Nagiosu, ktery´ je take´ napsa´n v Pythonu). Da´le se prˇida´va´ databa´zovy´ syste´m MySQL a cely´ syste´m beˇzˇ´ı nad Twisted, cozˇ je uda´lostmi rˇ´ızene´ rozhranı´ pro programova´nı´ sı´t’ovy´ch aplikacı´, ktere´ si rozumı´ s mnoha ru˚zny´mi protokoly na vı´ce vrstva´ch ISO/OSI. Du˚lezˇitou soucˇa´stı´ cele´ho syste´mu je RRDTool (Round Robin Database Tool). Tento na´stroj slouzˇ´ı k ukla´da´nı´, zpracova´va´nı´ a vytva´rˇenı´ graficke´ reprezentace (grafu˚) jaky´chkoliv cˇ´ısel, ktera´ mu prˇeda´me. Za´kladem je databa´ze organizovana´ jako kruhova´ fronta (odtud na´zev Round Robin Database) se statickou velikostı´, ve ktere´ jsou starsˇ´ı data prˇepisova´na noveˇjsˇ´ımi.
P
Zenoss si rozumı´ s protokoly SNMP, ICMP, protokoly rodiny TCP/IP, komunikuje s unixovy´mi syste´my (vcˇetneˇ syslogu) a take´ s Windows (podporuje take´ WMI). Na webu firmy najdeme take´ informaci o tom, zˇe jsou podporova´na take´ cloud zarˇ´ızenı´ (pojem Cloud Computing je velmi popula´rnı´). Konfigurace probı´ha´ prˇes prˇehledne´ webove´ rozhranı´. Dalsˇı´ informace o syste´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 dalsˇ´ı open-source na´stavba na´stroje RRDTool, podobneˇ jako Zenoss. Take´ v Cacti jde o to, jak zı´skat data, vhodneˇ je ulozˇit a na´sledneˇ analyzovat a zobrazit. Data mohou by´t zı´ska´va´na z ru˚zny´ch zdroju˚, naprˇ´ıklad od SNMP (Net-SNMP), skriptu˚ v nejru˚zneˇjsˇ´ıch skriptovacı´ch jazycı´ch nebo WMI, a ulozˇena bud’ do SQL databa´ze nebo pomocı´ RRDTool. Syste´m je urcˇen pro mensˇ´ı a strˇednı´ sı´teˇ (stovky, mozˇna´ tisı´ce, uzlu˚ sı´teˇ).
J
Komunita kolem syste´mu Cacti se uteˇsˇeneˇ rozru˚sta´, a tak existuje hodneˇ pluginu˚ a take´ sˇablon pro ru˚zne´ typy hodnot. Stejneˇ jako u prˇedchozı´ch na´stroju˚, take´ zde ma´me k dispozici prˇehledne´ webove´ rozhranı´ pro konfiguraci a manipulaci s daty. Dalsˇı´ 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
DOHLEDOVE´ SYSTE´MY
210
Obra´zek 8.13: Dohledovy´ syste´m Cacti30 ´ koly U Vyberte si jeden ze zminˇovany´ch dohledovy´ch syste´mu˚ a najdeˇte o neˇm co nejvı´ce informacı´. Pokud ma´te mozˇnost, vyzkousˇejte ho.
A jesˇteˇ pa´r odkazu ˚ ty´kajı´cı´ch se zabezpecˇ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 doporucˇene´ literatury
[1] CESNET2. URL: http://www.cesnet.cz/ [cit. 20. 5. 2010] [2] DONAHUE, G. A. Kompletnı´ pru˚vodce sı´t’ove´ho experta. Brno, Computer Press, 2009. [3] EMPSON, S. CCNA: Kompletnı´ prˇehled prˇ´ıkazu˚. Autorizovany´ vy´ukovy´ pru˚vodce. Brno, Computer Press, 2009. [4] HARPER, A. et al. Hacking – manua´l hackera. Praha, Grada, 2008. [5] HORA´K, J. — KERSˇLA´GER, M. Pocˇ´ıtacˇove´ sı´teˇ pro zacˇ´ınajı´cı´ spra´vce. Brno, Computer Press, 2008. [6] HUBERT, B. et al. Linux Advanced routing & Traffic Control [online]. URL: http://lartc.org/howto/, dalsˇ´ı na http://lartc.org/ [cit. 1. 7. 2011] [7] JANECˇEK, J. Distribuovane´ syste´my [online]. URL: https://dsn.felk.cvut.cz/wiki/ media/vyuka/cviceni/x36pko/skripta dsy.pdf [cit. 20. 5. 2010] [8] JONES, D. Automatizace spra´vy a skriptova´nı´ Microsoft Windows. Brno, Computer Press, 2006. [9] Linux Home Networking [online]. Knihy o spra´veˇ pocˇ´ıtacˇovy´ch sı´tı´ v Linuxu. URL: http://www.linuxhomenetworking.com/wiki/index.php [cit. 1. 7. 2011] [10] MINASI, M. — YORK, D. Linux pro administra´tory Windows. Brno, Computer Press, 2004. [11] PETERKA, J. eArchiv: Co je cˇ´ım v pocˇ´ıtacˇovy´ch sı´tı´ch [online]. URL: http://www.earchiv.cz/i coje.php3 [cit. 20. 5. 2010] [12] PETERKA, J. eArchiv: Principy pocˇ´ıtacˇovy´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] PUZˇMANOVA´, R. Modernı´ komunikacˇnı´ sı´teˇ od A do Z. 2. aktualizovane´ vyda´nı´. Brno, Computer Press, 2006. [15] RUEST, D. — RUEST, N. Virtualizace: Podrobny´ pru˚vodce. Brno, Computer Press, 2010. [16] SATRAPA, P. Internetovy´ protokol IPv6. Praha, CZ.NIC, z.s.p.o., 2008. 358 stran. Kniha je dostupna´ v elektronicke´ formeˇ 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. Na´hled veˇtsˇiny stra´nek je dostupny´ na Google Books. [18] SCHRODER, C. Linux: Kucharˇka administra´tora sı´teˇ. Brno, Computer Press, 2009. Z origina´lu Linux Networking Cookbook vydane´ho nakladatelstvı´m O’Reilly Media. [19] Sveˇt sı´tı´, tutoria´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. Zabezpecˇenı´ pocˇ´ıtacˇovy´ch sı´tı´. Autorizovany´ pru˚vodce. Brno, Computer Press, 2005. [22] Vy´ukove´ materia´ly Cisco [online]. URL: http://www.cisco.com/en/US/docs/internetworking/technology/handbook/ito doc.html [cit. 20. 5. 2010]
PRˇI´LOHY
Pˇr´ıloha
A
Co uzˇ bychom meˇli zna´t Zde v prvnı´ prˇ´ıloze jsou uvedena te´mata, ktera´ uzˇ bychom meˇli zna´t z bakala´rˇske´ho studia. Nicme´neˇ, dokonala´ pameˇt’ je veˇcı´ vza´cnou, proto si je pro jistotu rychle zopakujeme.
A.1
Loka´lnı´ sı´teˇ
Pojmy LAN (loka´lnı´ sı´t’), WAN (rozlehla´ sı´t’), MAN (metropolitnı´ sı´t’) a prˇ´ıpadneˇ CAN (campus, sı´t’ v omezene´ oblasti) bychom jizˇ meˇli zna´t. Takte´zˇ se jizˇ prˇedpokla´da´ prˇehled o topologiı´ch – sbeˇrnicova´, kruhova´, hveˇzda, stromova´ (hierarchicka´). Kazˇda´ komunikace probı´ha´ po spoji (mezi uzly sı´teˇ).
A.1.1
Vlastnosti spoju˚
Komunikace (nejen v loka´lnı´ch sı´tı´ch) se cˇlenı´ podle mnoha krite´riı´. Podle typu spoje
rozlisˇujeme spoje
• dvoubodove´ (point-to-point) – komunikace probı´ha´ mezi dveˇma uzˇivateli (zarˇ´ızenı´mi),
P
• vı´cebodove´ (point-to-multipoint) – vı´ce nezˇ dveˇma. Prˇenosy mohou by´t paralelnı´ nebo sekvencˇnı´, a da´le synchronnı´ nebo asynchronnı´. Pojmy „paralelnı´“ a „sekvencˇnı´“ jsou zde ve stejne´m vy´znamu, jaky´ se pouzˇ´ıva´ u na´m dobrˇe zna´my´ch perifernı´ch zarˇ´ızenı´ pocˇ´ıtacˇe. Paralelnı´ prˇenos znamena´ prˇena´sˇenı´ po vı´ce bitech najednou (vı´ce soubeˇzˇny´ch vodicˇu˚). To se mu˚zˇe zda´t vy´hodou vzhledem k rychlosti prˇenosu, ale nasta´va´ zde proble´m synchronizace dat. Paralelnı´ prˇenos je proto pouzˇitelny´ jen pro male´ vzda´lenosti, u sı´tı´ se te´meˇrˇ nepouzˇ´ıva´. Sekvencˇnı´ (se´riovy´) prˇenos znamena´ prˇena´sˇenı´ dat po jednotlivy´ch bitech. S porˇadı´m je trochu proble´m u ru˚zny´ch protokolu˚, naprˇ´ıklad jsou odlisˇnosti u Ethernetu a Token Ring.
215
P
A.1
LOKA´LNI´ SI´TEˇ
216
Prˇena´sˇene´ bity jsou cˇleneˇny na znaky (veˇtsˇinou 7 nebo 8 bitu˚), pouzˇ´ıva´me take´ pojem oktet, ktery´ znamena´ vzˇdy pra´veˇ 8 bitu˚ (veˇtsˇinou jsou tyto pojmy ekvivalentnı´). Sekvencˇnı´ prˇenosy jsou v sı´tı´ch obvykle´. Pozna´mka: Pojem Byte sice obvykle oznacˇuje skupinu 8 po sobeˇ na´sledujı´cı´ch bitu˚, ale v urcˇite´m kontextu mu˚zˇe znamenat 7 po sobeˇ jdoucı´ch bitu˚, proto tento pojem nenı´ z du˚vodu nejednoznacˇnosti v oblasti sı´tı´ moc pouzˇ´ıva´n. Pouzˇitelneˇjsˇ´ı je naopak pojem oktet, ktery´ ma´ prˇ´ımo v sobeˇ zahrnut pocˇet 8. Navı´c se sklonˇuje jednodusˇeji nezˇ Byte. Se´riovy´ asynchronnı´ prˇenos – znak je prˇena´sˇen „vcelku“, ale mezi jednotlivy´mi znaky mohou by´t jakkoliv dlouhe´ cˇasove´ prodlevy. Arytmicky´ prˇenos znamena´ u´pravu asynchronnı´ho prˇenosu cˇa´stecˇnou synchronizacı´, pouzˇ´ıvajı´ se specia´lnı´ znacˇky obklopujı´cı´ data.
L P
Posloupnost v ra´mci jednoho znaku: [start-bit]
[data znaku]
[paritnı´ bit]
[stop-bit]
V na´sledujı´cı´m na´kresu na obra´zku A.1 si vsˇimneˇte porˇadı´ bitu˚ – je opacˇne´ oproti tomu, na ktere´ jsme zvyklı´ na papı´rˇe. Prˇenos znaku (01101001)2: ST 1 0
0 1
0 1
1 0
P SP
P . . . paritnı´ bit ST . . . start bit SP . . . stop bit
Obra´zek A.1: Se´riovy´ asynchronnı´ prˇenos Se´riovy´ synchronnı´ prˇenos – data jsou prˇena´sˇena v blocı´ch, uvnitrˇ bloku˚ nesmı´ dojı´t k cˇasovy´m prodleva´m mezi znaky. Nepouzˇ´ıvajı´ se start-bity ani stop-bity, ale paritnı´ bity mohou by´t pouzˇity. Na zacˇa´tku bloku je jeden nebo vı´ce synchronizacˇnı´ch znaku˚, na konci bloku take´ (mohou by´t vysı´la´ny azˇ do zacˇa´tku dalsˇ´ıho bloku). Prˇenos sekvence dvou znaku˚ (01101001)2 SYN 1
0 0
1 0
1 1
0 1
0 0
P
(01101001)2: 1
0 1
1 0
SYN
SYN. . . synchronizacˇnı´ bit
Obra´zek A.2: Se´riovy´ synchronnı´ prˇenos Typy komunikace v LAN 1. unicast – jeden zdroj a jeden cı´l, paket je odesı´latelem adresova´n prˇ´ıjemci, jde o komunikaci mezi dveˇma uzly v sı´ti,
P
A.1
LOKA´LNI´ SI´TEˇ
217
2. multicast – tenty´zˇ paket je adresova´n mnozˇineˇ uzlu˚ v sı´ti, tj. shodne´ kopie paketu jsou posı´la´ny na vı´ce stanoveny´ch adres v sı´ti (prˇ´ıjemce stanovı´ multicast adresu, ktera´ obsahuje adresy uzlu˚– prˇ´ıjemcu˚), 3. broadcast – tenty´zˇ paket je adresova´n vsˇem uzlu˚m v sı´ti, pouzˇije se broadcast adresa, 4. anycast (v IPv6) – vy´beˇrova´ adresa; je podobna´ skupinove´ (take´ prˇedstavuje skupinu zarˇ´ızenı´), ale datagram je dorucˇen jen jednomu zarˇ´ızenı´ ze skupiny (veˇtsˇinou nejblizˇsˇ´ımu). Duplex
stanovı´, ktery´m smeˇrem komunikace mu˚zˇe ve´st:
• simplexnı´ spojenı´ – pouze jednosmeˇrne´
P
• polovicˇnı´ duplex (half duplex) – spojenı´ je obousmeˇrne´, ale v jednom okamzˇiku lze prˇena´sˇet data pouze jednı´m smeˇrem, • plny´ duplex (full duplex) – spojenı´ je obousmeˇrne´, v jednom okamzˇiku mohou komunikovat obeˇ strany za´rovenˇ. Plny´ duplex je cˇasto sestavova´n pomocı´ dvou navza´jem opacˇny´ch simplexu˚. Tento zpu˚sob komunikace je obvykle mozˇny´ jen na point-to-point spojı´ch.
A.1.2
Vlastnosti sluzˇeb
Spojova´ sluzˇba (connection-oriented) nejdrˇ´ıv nava´zˇe spojenı´ a pak teprve posı´la´ data. Komunikace ma´ trˇi fa´ze: nava´za´nı´ spojenı´, odesla´nı´ dat, ukoncˇenı´ spojenı´. V ra´mci nava´za´nı´ spojenı´ se dohodnou podmı´nky prˇenosu. Tento typ sluzˇby veˇtsˇinou doka´zˇe ohlı´dat ztra´cenı´ paketu˚.
P
Nespojova´ sluzˇba (connectionless) posı´la´ data bez prˇedchozı´ho nava´za´nı´ spojenı´. Data mohou by´t take´ rozdeˇlena na vı´ce cˇa´stı´ (paketu˚, ra´mcu˚), kazˇdy´ z nich musı´ by´t „ocˇ´ıslova´n“ svy´m porˇadı´m v pu˚vodnı´m proudu dat (zpra´veˇ) a musı´ by´t zrˇejme´, ktery´ je prvnı´ a ktery´ poslednı´. Tento typ sluzˇby mu˚zˇe nebo nemusı´ vyzˇadovat potvrzenı´, tedy se deˇlı´ do dvou podskupin: • nepotvrzovana´ sluzˇba bez spojenı´, • potvrzovana´ sluzˇba bez spojenı´ (s potvrzenı´m dorucˇenı´ dat). Prˇi vyuzˇitı´ potvrzovane´ sluzˇby se spojenı´m se potvrzuje prˇijetı´ dat (bud’ po kazˇde´ prˇijate´ datove´ jednotce nebo po dohodnute´m pocˇtu datovy´ch jednotek cˇi oktetu˚, s tı´m se setka´me naprˇ´ıklad u pojmu windowing). Da´le potrˇebujeme zna´t na´sledujı´cı´ pojmy. Prˇenosovy´ kana´l (channel) je souhrn prostrˇedku˚ (kabely, bezdra´tove´ cesty, spojova´ zarˇ´ızenı´ apod.), ktere´ vytva´rˇejı´ komunikacˇnı´ spojenı´ (jednosmeˇrne´). Je charakterizova´n (fyzika´lnı´mi) vlastnostmi jako je prˇenosova´ rychlost, u´rovenˇ sˇumu, sˇ´ırˇka pa´sma apod. Okruh
(circuit) je obousmeˇrne´ spojenı´ sestavene´ z komunikacˇnı´ch kana´lu˚.
Sˇı´rˇka pa´sma (bandwidth) je sˇ´ırˇka intervalu frekvencı´, ktere´ je prˇenosovy´ kana´l schopen prˇene´st (jednotka sˇ´ırˇky pa´sma je stejna´ jako jednotka frekvence). Obecneˇ: cˇ´ım veˇtsˇ´ı sˇ´ırˇka pa´sma, tı´m vysˇsˇ´ı prˇenosova´ rychlost spojenı´.
P
LOKA´LNI´ SI´TEˇ
A.1
A.1.3
218
Multiplexova´nı´
Multiplexing znamena´ sdruzˇova´nı´ ru˚zny´ch datovy´ch proudu˚ do jedne´ fyzicke´ komunikacˇnı´ cesty. Prˇenosovy´ kana´l s dostatecˇneˇ vysokou sˇ´ırˇkou pa´sma rozdeˇlı´me na vı´ce (logicky´ch) subkana´lu˚, ktere´ se jevı´ jako samostatne´. Multiplexing mu˚zˇe probı´hat na ktere´koliv vrstveˇ ISO/OSI.
P
Jde vlastneˇ o dveˇ cˇinnosti: • multiplexova´nı´ probı´ha´ na zdrojove´m zarˇ´ızenı´ (source), • demultiplexova´nı´ probı´ha´ na cı´love´m zarˇ´ızenı´ (destnation) na stejne´ vrstveˇ jako u zdroje, jde o prˇevod multiplexovany´ch dat do pu˚vodnı´ho tvaru. K multiplexova´nı´ slouzˇ´ı multiplexor, k demultiplexova´nı´ slouzˇ´ı demultiplexor. Za´kladnı´ varianty multiplexingu • frekvencˇnı´ multiplex (frequency division multiplexing, FDM) – kazˇdy´ subkana´l ma´ prˇideˇlen vlastnı´ interval frekvencı´; signa´l je prˇi prˇenosu posunut do sˇ´ırˇky pa´sma pro dany´ subkana´l a po prˇenosu je posunut zpeˇt (u´pravy signa´lu se prova´deˇjı´ kmitocˇtovy´m filtrem), v soucˇasne´ dobeˇ se s variantami setka´va´me v satelitnı´ch, kabelovy´ch a neˇktery´ch ra´diovy´ch sı´tı´ch, • cˇasovy´ multiplex (time division multiplexing, TDM) – cely´ kana´l je strˇ´ıdaveˇ (na kra´tke´ cˇasove´ u´seky) prˇideˇlova´n jednotlivy´m subkana´lu˚m, pouzˇ´ıva´ se naprˇ´ıklad v GSM, • statisticky´ multiplex (statistical time division multiplex, STDM) – sˇ´ırˇka pa´sma je dynamicky prˇideˇlova´na podle prˇedpokla´dany´ch potrˇeb (statisticky vypocˇteny´ch z historie); je to vlastneˇ pozmeˇneˇna´ asynchronnı´ varianta TDM, ktera´ podporuje inteligentnı´ rˇ´ızenı´ vytı´zˇenı´ sı´teˇ, • vlnove´ deˇlenı´ (wavelength division multiplex, WDM) se pouzˇ´ıva´ v opticky´ch vla´knech; pracuje na podobne´m principu jako FDM, jen mı´sto frekvencı´ mluvı´me o vlnovy´ch de´lka´ch (take´ barva´ch) sveˇtla, tuto metodu lze take´ kombinovat s TDM cˇi STDM, • ko´dove´ deˇlenı´ (code division multiple access, CDMA) vzniklo pu˚vodneˇ pro potrˇeby arma´dy; spocˇ´ıva´ v rozprostrˇenı´ uzˇitne´ho signa´lu podle dane´ho algoritmu v za´vistlosti (kromeˇ jine´ho) na pocˇtu a umı´steˇnı´ vysı´lajı´cı´ch uzˇivatelu˚, cozˇ znesnadnˇuje odposloucha´nı´ signa´lu (vy´sledny´ signa´l se jevı´ jako silneˇ zasˇumeˇny´ a bez znalosti zpu˚sobu zako´dova´nı´ nelze jednotlive´ pu˚vodnı´ signa´ly oddeˇlit, pro oddeˇlenı´ jednotlivy´ch komunikacı´ je trˇeba pouzˇ´ıt programovy´ ko´d), pouzˇ´ıva´ se naprˇ´ıklad v syste´mech UMTS, • ortogona´lnı´ multiplex s frekvencˇnı´m deˇlenı´m (Orthogonal Frequency Division Multiplexing, OFDM) pouzˇ´ıva´ neˇkolik stovek azˇ tisı´c nosny´ch kmitocˇtu˚ tak, aby jednotlive´ nosne´ byly navza´jem ortogona´lnı´ (to znamena´, zˇe maximum nosny´ch se minima´lneˇ prˇekry´va´ s jiny´mi nosny´mi). Typicke´ vyuzˇitı´ je prˇedevsˇ´ım v bezdra´tovy´ch sı´tı´ch (vcˇetneˇ Wi-Fi) a ADSL.
Obra´zek A.3: Frekvencˇnı´, cˇasovy´ a statisticky´ multiplex (statisticky´: pro idea´lnı´ prˇ´ıpad)
P
A.1
LOKA´LNI´ SI´TEˇ
219
Cˇasove´ u´seky, ktere´ jsou prˇideˇlova´ny v TDM a STDM, se nazy´vajı´ sloty (na obra´zku A.3 to jsou stejneˇ dlouhe´ u´seky v druhe´m a trˇetı´m podobra´zku, do ktery´ch dosazujeme u´seky jednotlivy´ch konverzacı´).
A.1.4
Prˇı´stupove´ metody
Zˇa´dna´ dveˇ zarˇ´ızenı´ by nemeˇla zası´lat data ve stejne´m kana´lu v jednom cˇasove´m okamzˇiku. CSMA/CD (Carrier Sense Multiple Access, Collision Detect) – pouzˇ´ıva´ se u Ethernetu. Vycha´zı´ z toho, zˇe pokud dveˇ zarˇ´ızenı´ vysı´lajı´ data za´rovenˇ, dojde ke kolizi. Postup rˇesˇenı´:
P
• zarˇ´ızenı´, ktere´ chce vysı´lat data, nasloucha´, zda jine´ zarˇ´ızenı´ pra´veˇ vysı´la´, • pokud ne, zacˇne vysı´lat, • po ukoncˇenı´ prˇenosu jednotky opeˇt posloucha´, zda nedosˇlo ke kolizı´m, • kdyzˇ zjistı´ kolizi, vycˇka´ po dobu o na´hodneˇ vygenerovane´ de´lce (tj. kazˇde´ z „kolidujı´cı´ch“ zarˇ´ızenı´ zrˇejmeˇ cˇeka´ jinou dobu) a teprve pak zacˇne vysı´lat znovu. Podrobny´ postup probereme v kapitole o Ethernetu. Cˇ´ım vı´c je vysı´lajı´cı´ch zarˇ´ızenı´, tı´m vysˇsˇ´ı pravdeˇpodobnost kolize a tı´m nizˇsˇ´ı propustnost. Tento proble´m se da´ cˇa´stecˇneˇ rˇesˇit prˇida´nı´m prˇepı´nacˇu˚ (switch), ktere´ mohou oddeˇlit jednotlive´ oblasti sı´teˇ (tzv. koliznı´ dome´ny) a snı´zˇit mnozˇstvı´ kolizı´. CSMA/CA (Carrier Sense Multiple Access, Collision Avoidance) – kolizı´m se prˇ´ımo prˇedcha´zı´ (ne doslova, le´pe to vystihuje pojem „moc nerˇesˇ´ı“), stanice jednodusˇe prˇed vysı´la´nı´m nasloucha´, jestli nevysı´la´ nikdo jiny´, tato metoda je urcˇena pro bezdra´tove´ sı´teˇ (opeˇt probereme v prˇ´ıslusˇne´ kapitole). Token Passing je metoda posı´la´nı´ „pesˇka“ – tokenu. Token se posı´la´ postupneˇ vsˇem zarˇ´ızenı´m v sı´ti, pouze to zarˇ´ızenı´, ktere´ ma´ pra´veˇ token, mu˚zˇe vysı´lat. Pokud zarˇ´ızenı´ dostane token a nema´ co vysı´lat, posˇle token da´l. Pokud zarˇ´ızenı´ dostane token a ma´ co vysı´lat, provede prˇenos a azˇ po jeho ukoncˇenı´ posˇle token da´l. Jina´ forma Token Passing: token mu˚zˇe slouzˇit jako nosna´ datova´ jednotka, tj. pokud je token volny´ a stanice ma´ co vyslat, prˇida´ sva´ data a dalsˇ´ı u´daje (vcˇetneˇ cı´le) k tokenu a posˇle da´l, adresa´t (cı´l) si data vyzvedne a token mu˚zˇe by´t vyuzˇit jiny´m uzlem v sı´ti. Prˇi stanovene´ velikosti prˇena´sˇeny´ch dat (velikost ra´mce nebo paketu) a zna´me´m mnozˇstvı´ zarˇ´ızenı´ schopny´ch vysı´lat je mozˇne´ vypocˇ´ıst maxima´lnı´ dobu cˇeka´nı´ na token, to je vy´hodou v real-time provozech. Poloduplexnı´ a plneˇ duplexnı´ prˇı´stup metody CSMA/CD i Token Passing jsou samy o sobeˇ z principu poloduplexnı´. Pokud prˇida´me switch, u obou metod lze dosa´hnout plneˇ duplexnı´ho prˇ´ıstupu, cozˇ znamena´ zvy´sˇenı´ propustnosti.
A.1.5
ˇ ı´zenı´ toku dat v sı´ti R
Sı´t’ove´ zarˇ´ızenı´ (na´sledujı´cı´ se ty´ka´ mezilehly´ch sı´t’ovy´ch zarˇ´ızenı´ jako jsou naprˇ. prˇepı´nacˇe nebo smeˇrovacˇe) potrˇebuje buffer (cache, vyrovna´vacı´ pameˇt’). Zde ukla´da´ prˇ´ıchozı´ datove´ jednotky bit
P P
A.2
WAN SI´TEˇ
220
po bitu, aby bylo mozˇne´ takovou datovou jednotku zpracovat (prˇedevsˇ´ım potrˇebuje zjistit, na ktery´ port ma´ datovou jednotku odeslat, tedy urcˇita´ adresa, podle typu zarˇ´ızenı´), prˇ´ıp. zkontrolovat, zda je vporˇa´dku (kontrolnı´ soucˇet, platna´ de´lka apod.). Pokud datove´ jednotky prˇicha´zejı´ prˇ´ılisˇ rychle a sı´t’ove´ zarˇ´ızenı´ je nestacˇ´ı odbavovat, mu˚zˇe dojı´t k prˇetecˇenı´ bufferu (vyrovna´vacı´ pameˇt’nestacˇ´ı). Tedy je potrˇeba zabra´nit zahlcenı´ sı´teˇ, prˇetecˇenı´ bufferu apod. – pro tyto u´cˇely existujı´ kromeˇ samotne´ existence vyrovna´vacı´ pameˇti jesˇteˇ trˇi za´kladnı´ metody: 1. Zpra´vy o zahlcenı´ (source-quench messages) – prˇijı´majı´cı´ zarˇ´ızenı´ posı´la´ zdrojove´mu (tj. vysı´lajı´cı´mu) zarˇ´ızenı´ zˇa´dost o snı´zˇenı´ prˇenosove´ rychlosti (resp. intervalu˚) zası´lany´ch paketu˚. Tato metoda se vyuzˇ´ıva´ naprˇ. na trˇetı´ vrstveˇ TCP/IP, existuje ICMP zpra´va cˇ. 4 Source Quench (zpra´va zdroji dat, aby snı´zˇil rychlost odesı´la´nı´).
$
2. Zahazova´nı´ paketu˚ – prˇijı´majı´cı´ zarˇ´ızenı´ mu˚zˇe zahazovat obdrzˇena´ data, aby zabra´nilo prˇetecˇenı´ vyrovna´vacı´ pameˇti, zdrojove´ zarˇ´ızenı´ po urcˇite´ dobeˇ posı´la´ znovu zahozene´ pakety a postupneˇ opeˇt zvysˇuje prˇenosovou rychlost. Jeden z algoritmu˚ je naprˇ´ıklad Token Bucket (pouzˇ´ıva´ se na smeˇrovacˇ´ıch). 3. Windowing – zdroj dostane povolenı´ odeslat urcˇity´ pocˇet paketu˚ (window size = tento pocˇet), kdyzˇ cı´l z neˇjake´ho du˚vodu neobdrzˇ´ı tento pocˇet paketu˚, zdroj je posı´la´ znovu se snı´zˇenou rychlostı´ prˇenosu. Obdoba se pouzˇ´ıva´ naprˇ´ıklad v protokolu TCP, pod na´zvem Sliding Window (sluzˇba se spojenı´m).
A.2
WAN sı´teˇ
A.2.1
Okruhy
Vı´me, zˇe okruh je tvorˇen neˇkolika komunikacˇnı´mi kana´ly. Okruhu˚ existuje take´ vı´ce druhu˚. Typy okruhu˚ podle vlastnictvı´ a mozˇnosti uzˇ´ıva´nı´: • soukrome´ (private) – uzˇivatel (provozovatel) si sa´m zrˇ´ıdı´ prˇenosovou cestu,
P
• verˇejne´ (private) – zrˇizuje spojova´ organizace (obvykle sta´tnı´ nebo monopolnı´ v dane´ zemi), za poplatek mu˚zˇe takove´ okruhy pouzˇ´ıvat kazˇdy´, • pronajate´ (leased) – provozovatel potrˇebuje mı´t okruh neusta´le k dispozici, tak si ho pronajme od spojove´ organizace; zu˚sta´va´ majetkem spojove´ organizace, ale vy´hradnı´ pra´vo k uzˇ´ıva´nı´ ma´ provozovatel. Fyzicky´ okruh je okruh, ktery´ zcela souhlası´ s fyzickou prˇenosovou cestou (porˇa´d stejnou) a nenı´ prˇerusˇen zˇa´dny´m meziuzlem (trˇeba u´strˇednou), obvykle je to soukroma´ prˇenosova´ cesta. Virtua´lnı´ okruh je logicky´ okruh (ne fyzicky´) prˇes sdı´lene´ prˇenosove´ cesty. Je to nejobvyklejsˇ´ı mozˇnost v rozlehly´ch sı´tı´ch. Rozlisˇujeme dva typy virtua´lnı´ch okruhu˚: • pevny´ (trvaly´, PVC) • komutovany´ (prˇepı´nany´, SVC)
P P
A.2
WAN SI´TEˇ
221
1. Pevny´ virtua´lnı´ okruh (take´ non-switched, direct, trvaly´, PVC – permanent virtual circuit), zu˚sta´va´ vyhrazen sve´mu provozovateli po celou dobu vlastnictvı´/prona´jmu. Tento typ okruhu se musı´ vytvorˇit manua´lneˇ, vytvorˇenı´ je proto na´rocˇneˇjsˇ´ı a pomalejsˇ´ı, jeho pouzˇ´ıva´nı´ je obvykle dlouhodobeˇjsˇ´ı – ty´dny/meˇsı´ce/roky. Tento typ okruhu obcha´zı´ meziuzly (u´strˇedny apod.), tedy komunikace je rychlejsˇ´ı, a nety´kajı´ se jich souvisejı´cı´ poruchy, proto je povazˇova´n za kvalitneˇjsˇ´ı. 2. Komutovany´ virtua´lnı´ okruh (take´ switched, dial-up, prˇepı´nany´, SVC – switched virtual circuit) je docˇasneˇ sestaven beˇhem nava´za´nı´ spojenı´, prˇestane existovat po ukoncˇenı´ spojenı´ (proces sestavenı´ okruhu v u´strˇedneˇ = komutace). Vytva´rˇ´ı se automaticky, softwaroveˇ, a to takto: • • • •
A.2.2
zasˇle se pozˇadavek s potrˇebny´mi informacemi, jsou dohodnuty parametry spojenı´ vyhovujı´cı´ vsˇem zainteresovany´m uzlu˚m, vysı´lacı´ uzel obdrzˇ´ı identifika´tor jednoznacˇny´ pro vznikly´ okruh, posı´lana´ data pak neobsahujı´ smeˇrovacı´ informace (stacˇ´ı tento identifika´tor).
Komunikace v rozlehle´ sı´ti
Ve WAN sı´tı´ch se pouzˇ´ıvajı´ trˇi za´kladnı´ typy spojenı´: 1. Point-to-Point 2. Prˇepı´na´nı´ okruhu˚ 3. Prˇepı´na´nı´ paketu˚ Point-to-Point komunikace je jednoducha´ komunikace s nava´za´nı´m spojenı´ prˇes sı´t’poskytovatele (majitele infrastruktury – dra´tu˚ apod.) realizovana´ prˇepravcem (naprˇ´ıklad telefonnı´ spolecˇnostı´). Linka je „pronajata“ od poskytovatele (leased circuit). Prˇi vzniku spojenı´ je trvale vyhrazena dvojice linek pro toto noveˇ vytva´rˇene´ spojenı´ (plny´ duplex). Prˇepı´na´nı´ okruhu ˚ (Circuit Switching) – na zacˇa´tku komunikace se vytvorˇ´ı okruh s pevneˇ nastavenou prˇenosovou kapacitou (obvykle prˇi spojoveˇ orientovany´ch sluzˇba´ch). Narozdı´l od prˇedchozı´ho zde okruhy nejsou sta´le´, ale vznikajı´ a zanikajı´ podle potrˇeby (komutovane´, prˇepı´nane´).
P P
Vy´hodou je jednoduchy´ zpu˚sob u´cˇtova´nı´, spojenı´ (po nava´za´nı´) funguje prakticky „v rea´lne´m cˇase“ (bez zastavova´nı´ v meziuzlech). Nevy´hodou je nutnost rezervace prˇenosovy´ch cest, ktere´ by mohl vyuzˇ´ıvat take´ neˇkdo jiny´. Toto rˇesˇenı´ je obvykle´ pro velke´ verˇejne´ datove´ sı´teˇ (CSPDN – Circuit Switching Public Data Network), typicky´ prˇ´ıklad: ISDN. Prˇepı´na´nı´ paketu ˚ (Packet Switching) – data jsou cˇleneˇna na cˇa´sti (pakety) a posı´la´na sdı´leny´m kana´lem (obvykle prˇi nespojovy´ch sluzˇba´ch). Kazˇdy´ paket musı´ mı´t informaci o adresa´tovi (prˇ´ıpadneˇ take´ o odesı´lateli) a dalsˇ´ı (smeˇrovacı´) informace, cozˇ u prˇedchozı´ch nebylo nutne´. Vy´hodou je, zˇe kapacita prˇenosovy´ch cest mu˚zˇe by´t snadneˇji sdı´lena. Nevy´hodou je, zˇe rychlost prˇenosu paketu˚ je za´visla´ na vytı´zˇenı´ sı´teˇ (v meziuzlech je paket nejdrˇ´ıv ulozˇen do mezipameˇti a azˇ po uvolneˇnı´ linky je posla´n da´l).
P
A.3
MODEL ISO/OSI
222
Dostupný přenosový kanál
Jednotlivé okruhy
-
Dostupný přenosový kanál
Přenášené pakety
-
Obra´zek A.4: Prˇepı´na´nı´ okruhu˚ a prˇepı´na´nı´ paketu˚ ve WAN Toto rˇesˇenı´ je obvykle´ pro loka´lnı´ sı´teˇ. Pokud je pouzˇito pro velkou verˇejnou datovou sı´t’, mluvı´me o PSPDN (Packet Switched Public Data Network). Variantou (podobneˇ fungujı´cı´) ke prˇepı´na´nı´ paketu˚ je take´ prˇepojova´nı´ buneˇk v X.25 nebo ATM, a prˇepojova´nı´ ra´mcu˚ v sı´ti Frame Relay.
A.3
Model ISO/OSI
A.3.1
Princip
ISO/OSI Open System Interconnection Reference Model byl vyda´n sdruzˇ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
Obra´zek A.5: Model ISO/OSI
P
A.3
MODEL ISO/OSI
223
Jedna´ se abstraktnı´ model urcˇeny´ specia´lneˇ pro pouzˇitı´ v pocˇ´ıtacˇovy´ch sı´tı´ch. V normeˇ nejsou nikde specifikova´ny implementace (tj. konkre´tnı´ naprogramova´nı´), najdeme zde pouze principy, popis prˇ´ıstupovy´ch rozhranı´ a funkcı´. Dokonce ani popis komunikacˇnı´ch protokolu˚ nenı´ soucˇa´stı´ normy, protokoly jsou specifikova´ny azˇ v navazujı´cı´ch norma´ch ISO a doporucˇenı´ch ITU-T. Princip je jednoduchy´ – sı´t’ova´ komunikace na zarˇ´ızenı´ je rozcˇleneˇna do sedmi u´rovnı´ (sı´t’ove´ zarˇ´ızenı´ vsˇak nemusı´ nutneˇ implementovat vsˇechny vrstvy, jak pozdeˇji uvidı´me). Kazˇda´ u´rovenˇ (vrstva) ma´ svou vlastnı´ u´lohu a je relativneˇ neza´visla´ na ostatnı´ch. Kazˇda´ vrstva komunikuje pouze s okolnı´mi vrstvami, a to tak, zˇe vrstva poskytuje sve´ sluzˇby vrstveˇ bezprostrˇedneˇ nadrˇ´ızene´ a je klientem (vyuzˇ´ıva´ sluzˇeb) vrstvy bezprostrˇedneˇ podrˇ´ızene´. Na obra´zku A.5 vidı´me rozlozˇenı´ vrstev. Tedy naprˇ´ıklad linkova´ vrstva je klientem fyzicke´ vrstvy (vyuzˇ´ıva´ jejı´ch sluzˇeb) a sve´ sluzˇby poskytuje sı´t’ove´ vrstveˇ. V praxi (prˇedevsˇ´ım v navazujı´cı´m modelu TCP/IP, ale i jinde) se setka´va´me s rozdeˇlenı´m neˇktery´ch vrstev na podvrstvy (obvykle dveˇ), naprˇ´ıklad pra´veˇ linkova´ vrstva by´va´ takto rozdeˇlena (ovsˇem podle jine´ normy, v tomto prˇ´ıpadeˇ naprˇ´ıklad IEEE). Na obra´zku A.5 si take´ mu˚zˇeme vsˇimnout barevne´ho rozdeˇlenı´ vrstev do trˇ´ı zo´n. Spodnı´ (zelena´) zo´na zahrnuje vrstvy orientovane´ na prˇenos, tato zo´na se zaby´va´ prˇedevsˇ´ım technicky´mi detaily prˇenosu (jak vhodneˇ data upravit, rozdeˇlit apod. tak, aby bylo mozˇne´ je prˇene´st). Hornı´ (zˇluta´) zo´na obsahuje vrstvy aplikacˇneˇ orientovane´ (nezaby´vajı´ se prˇ´ımo prˇizpu˚sobova´nı´m dat pro prˇenos, ale spı´sˇe logicky´mi vlastnostmi spojenı´). Mezi teˇmito dveˇma zo´nami je prˇizpu˚sobovacı´ zo´na obsahujı´cı´ pouze transportnı´ vrstvu.
A.3.2
Pojmy
S modelem ISO/OSI souvisejı´ tyto pojmy: Entita je prvek pracujı´cı´ na konkre´tnı´ vrstveˇ, je to konkre´tnı´ prvek, ktery´ bud’ poskytuje sluzˇbu (je poskytovatel sluzˇby) nebo vyuzˇ´ıva´ sluzˇbu neˇktere´ entity z nizˇsˇ´ı vrstvy. Pro mnozˇinu entit, ktere´ jsou vsˇechny v ra´mci jedne´ vrstvy, se take´ pouzˇ´ıva´ pojem peer entities. Prˇı´stupovy´ bod sluzˇby (SAP – Service Access Point) je bod na pomezı´ dvou vrstvev, prˇes ktery´ komunikujı´ dveˇ entity v sousednı´ch vrstva´ch. Kazˇdy´ SAP ma´ jednoznacˇnou adresu. Prˇes jeden SAP mu˚zˇe v jednom okamzˇiku ve´st pouze jedina´ komunikace (ale na druhou stranu entita mu˚zˇe v jednom okamzˇiku komunikovat prˇes vı´ce ru˚zny´ch SAP k jedne´ nebo obou sousednı´ch vrstva´ch). Protokol (obvykle ve spojenı´ komunikacˇnı´ protokol) je sada pravidel a konvencı´ urcˇujı´cı´ch, jaky´m zpu˚sobem probı´ha´ vy´meˇna dat mezi dveˇma prvky (pocˇ´ıtacˇi v sı´ti). Zahrnuje sluzˇby jedne´ nebo vı´ce vrstev v ISO/OSI, obvykle ke komunikaci v ra´mci jedne´ vrstvy. Rozlisˇujeme • mezivrstvove´ protokoly – slouzˇ´ı ke komunikaci mezi entitami v sousednı´ch vrstva´ch v ra´mci jednoho syste´mu (zarˇ´ızenı´), komunikuje se prˇes neˇktery´ SAP, • vrstvove´ protokoly – slouzˇ´ı ke komunikaci mezi entitami na stejne´ vrstveˇ, ale v ru˚zny´ch syste´mech (na ru˚zny´ch zarˇ´ızenı´ch), naprˇ´ıklad mezi linkovy´mi vrstvami na dvou zarˇ´ızenı´ch v sı´ti.
P P P
A.3
MODEL ISO/OSI
224
Vrstvove´ protokoly narozdı´l od mezivrstvovy´ch nefungujı´ „prˇ´ımo“, komunikace mezi ru˚zny´mi syste´my probı´ha´ vzˇdy prˇes nizˇsˇ´ı vrstvy obou syste´mu˚. Soustava protokolu ˚ (Protocol Suite) je skupina protokolu˚ pro konkre´tnı´ model. Pro tute´zˇ cˇinnost mu˚zˇe existovat vı´ce alternativnı´ch protokolu˚. Protokolovy´ za´sobnı´k (Protocol Stack) Ze soustavy protokolu˚ vybereme pro kazˇdou cˇinnost po jednom protokolu (odstranı´me alternativy). Je jednı´m z urcˇujı´cı´ch faktoru˚ implementace architektury sı´teˇ. Nejzna´meˇjsˇ´ı sestavou protokolu˚ je rodina protokolu˚ TCP/IP. Sluzˇba poskytovana´ vrstvou je fyzicky zajisˇt’ova´na entitami v te´to vrstveˇ prˇes body SAP. Kazˇda´ sluzˇba je specifikovana´ dveˇma u´daji: • primitivum urcˇujı´cı´ za´kladnı´ poskytovanou funkci (zˇa´dost o sluzˇbu nizˇsˇ´ı vrstveˇ, ozna´menı´ vedoucı´ k provedenı´ neˇktery´ch kroku˚, odpoveˇd’ o splneˇnı´ kroku˚ v ozna´menı´, potvrzenı´ o splneˇnı´ zˇa´dosti), vsˇe vztazˇene´ k jednomu SAP,
• rˇ´ıdicı´ parametry, ktere´ uprˇesnˇujı´ informaci danou primitivem. Funkce je konkre´tnı´ cˇinnost jedne´ entity vedoucı´ k poskytnutı´ dane´ sluzˇby. PDU (Protocol Data Unit) je protokolova´ datova´ jednotka – stanoveny´ forma´t dat (s prˇ´ıdavny´mi informacemi) pro komunikaci s konkre´tnı´m protokolem. Typicke´ PDU jsou ra´mce nebo pakety. Protozˇe kazˇdy´ protokol by´va´ u´zce spojen s jedinou vrstvou, PDU take´ souvisejı´ s touto vrstvou.
P
PDU veˇtsˇinou obsahuje za´hlavı´ s rˇ´ıdicı´mi informacemi, obvykle (ne vzˇdy) na´sledovane´ prˇena´sˇeny´mi daty. Soucˇa´stı´ take´ mu˚zˇe by´t za´patı´ (pata) s dodatecˇny´mi informacemi, typicky kontrolnı´m soucˇtem. Kazˇda´ PDU postupneˇ prˇecha´zı´ mezi vrstvami ISO/OSI modelu. Prˇi prˇenosu „smeˇrem dolu˚“ je z pu˚vodnı´ PDU vytvorˇena nova´ PDU jine´ho protokolu (jine´ vrstvy) tak, zˇe mu˚zˇe (nemusı´) by´t rozdeˇlena cˇi zrˇeteˇzena s jinou PDU, a da´le je prˇipojeno za´hlavı´ (neˇkdy i za´patı´) dalsˇ´ı vrstvy.
A.3.3
Vrstvy
Na tomto mı´steˇ si pouze strucˇneˇ popı´sˇeme vlastnosti jednotlivy´ch vrstev modelu ISO/OSI. Podrobneˇ (vcˇetneˇ konkre´tnı´ho pouzˇitı´ a protokolu˚) se jimi budeme zaby´vat v na´sledujı´cı´ch kapitola´ch. Fyzicka´ vrstva (physical layer) definuje elektricke´, mechanicke´, procesnı´ a funkcˇnı´ specifikace pro aktivaci, u´drzˇbu a deaktivaci fyzicke´ho spojenı´ dvou zarˇ´ızenı´ (u´rovneˇ napeˇtı´, cˇasova´nı´ zmeˇn napeˇtı´ – jak dlouho trva´ prˇenos bitu, konektory – kolik kontaktu˚, jaky´ majı´ vy´znam, atd.). Do te´to vrstvy nepatrˇ´ı prˇ´ımo zˇa´dne´ prˇenosove´ zarˇ´ızenı´, je nad samotny´m hardwarem (definuje pouze potrˇebne´ vlastnosti zarˇ´ızenı´/konektoru, ktere´ prˇipojujeme). V te´to vrstveˇ pracujeme s jednotlivy´mi bity zası´lany´ch dat (respektive jejich fyzika´lnı´ reprezentacı´), pro data nenı´ definova´na zˇa´dna´ datova´ struktura (zˇa´dny´ paket, ra´mec ani Byte). Funkce vrstvy souvisejı´ s prˇenosem bitu˚ prˇes fyzicke´ rozhranı´. Zajisˇt’uje aktivaci a deaktivaci fyzicke´ho spojenı´, urcˇenı´ duplexu (plne´ho nebo polovicˇnı´ho), provozova´nı´ okruhu˚, identifikaci prˇijı´mane´ posloupnosti bitu˚ nebo znacˇek (bity nemu˚zˇe prˇeusporˇa´da´vat, prˇeda´va´ je vy´sˇe ve stejne´m porˇadı´, v jake´m je dostala), modulaci a demodulaci.
P
A.3
MODEL ISO/OSI
225
Na te´to vrstveˇ se nehovorˇ´ı ani tak o protokolech, jako spı´sˇe o standardech. V tomto textu se jim budeme veˇnovat jen zbeˇzˇneˇ. Patrˇ´ı zde naprˇ´ıklad standardy, ktere´ uzˇ zna´me u konektoru˚ – USB, RS-232, BlueTooth, FireWire, da´le fyzicka´ rozhranı´ pro Ethernet, telekomunikacˇnı´ sı´teˇ apod. Linkova´ (spojova´) vrstva
(data link layer) zajisˇt’uje spolehlivy´ pru˚chod dat z/do fyzicke´ vrstvy.
Narozdı´l od fyzicke´ vrstvy nebere data jako pouhou posloupnost bitu˚, ale cˇlenı´ je do ra´mcu˚ (frame), musı´ umeˇt rozpoznat hranice mezi ra´mci. Porovna´va´ kontrolnı´ soucˇty ra´mcu˚, prˇi zjisˇteˇnı´ chyby si vyzˇa´da´ opakova´nı´ prˇenosu ra´mce.
P
S ra´mci souvisı´ typicke´ funkce – zaha´jenı´ a ukoncˇenı´ prˇenosu, rˇ´ızenı´ porˇadı´ ra´mcu˚, detekce a oprava chyb souvisejı´cı´ch s prˇenosem ra´mcu˚ (ktere´ vznikajı´ na fyzicke´ vrstveˇ), rˇ´ızenı´ vyuzˇ´ıva´nı´ telekomunikacˇnı´ch okruhu˚ ve fyzicke´ vrstveˇ, fyzicka´ adresace. Pracuje totizˇ s fyzicky´mi adresami zarˇ´ızenı´ (MAC adresy). Podle IEEE ma´ linkova´ vrstva dveˇ podvrstvy: 1. LLC (Logical Link Control) 2. MAC (Media Access Control) Veˇtsˇina loka´lnı´ch sı´tı´ (ale ne vsˇechny) implementuje pouze vrstvy fyzickou a linkovou (prˇ´ıpadneˇ z nı´ jen MAC), vysˇsˇ´ı vrstvy nejsou potrˇeba (smeˇrova´nı´ probı´ha´ podle MAC adres). Typicke´ protokoly: LAPB, HDLC, PPP, atd., budeme se jim veˇnovat pomeˇrneˇ hodneˇ v na´sledujı´cı´ch kapitola´ch. Sı´t’ova´ vrstva (network layer) definuje sı´t’ovou adresu zarˇ´ızenı´ (to mu˚zˇe by´t naprˇ´ıklad IP adresa). Zajisˇt’uje smeˇrova´nı´ (routing) – volbu vhodne´ trasy mezi dveˇma sı´t’ovy´mi uzly, tj. pracuje s logickou strukturou sı´teˇ.
P
Vysˇsˇ´ı vrstvy (nad sı´t’ovou vrstvou) cha´pou sı´t’ uzlu˚ jako plneˇ propojenou, zpu˚sob prˇenosu je nezajı´ma´, nizˇsˇ´ı vrstvy naopak vidı´ pouze to propojenı´, ktere´ je urcˇeno sı´t’ovou vrstvou. Hlavnı´ sluzˇbou te´to vrstvy je prˇenos dat mezi entitami transportnı´ vrstvy (na ru˚zny´ch syste´mech), da´le zajisˇt’uje sı´t’ove´ adresova´nı´, identifikaci koncovy´ch bodu˚ spojenı´, atd. Poskytovane´ sluzˇby se deˇlı´ na sluzˇby se spojenı´m a bez spojenı´ (bud’ pouze prˇenos bloku˚ dat nebo kompletnı´ nava´za´nı´ spojenı´–prˇenos–ukoncˇenı´ spojenı´). Sı´t’ova´ vrstva pracuje s pakety transportnı´ vrstvy. Typicke´ protokoly: IP (bez spojenı´), X.25 (se spojenı´m), ARP, RARP (prˇeklad mezi MAC a IP adresou). Do te´to vrstvy ve skutecˇnosti nejsou zarˇazeny smeˇrovacı´ protokoly (i kdyzˇ by se to snad zda´lo logicke´), ty jsou zarˇazeny do protokolu˚ managementu (rˇ´ızenı´) sı´teˇ. Transportnı´ vrstva (transport layer) prˇijı´ma´ data z relacˇnı´ vrstvy a cˇlenı´ je na transportnı´ cˇa´sti – pakety (packet), ktere´ se pak posı´lajı´ da´le do sı´teˇ (z pohledu transportnı´ vrstvy smeˇrem k sı´t’ove´ vrstveˇ). Pakety prˇijate´ zdola od sı´t’ove´ vrstvy naopak serˇazuje a skla´da´ v nich obsazˇena´ data (jeden proud dat mu˚zˇe by´t, a cˇasto by´va´, rozdeˇlen do vı´ce paketu˚). Transportnı´ vrstva je prˇedevsˇ´ım zodpoveˇdna´ za dorucˇova´nı´ dat ve spra´vne´m forma´tu a porˇadı´ (pakety, do ktery´ch je rozdeˇlen jeden proud dat, mohou v sı´ti putovat ru˚zny´mi cestami, a proto je mozˇne´, zˇe dojdou v jine´m porˇadı´, nezˇ v jake´m byly odesla´ny).
P
A.3
MODEL ISO/OSI
226
Vrstvy pod transportnı´ vrstvou jsou za´visle´ na sı´t’ove´ implementaci (prˇenosove´ metodeˇ, hardwaru, apod.), vrstvy nad nı´ nejsou za´visle´ na sı´t’ove´ implementaci. Transportnı´ vrstva tedy plnı´ funkci rozhranı´ (prˇekladatele) i v tomto smyslu, vyrovna´va´ rozdı´ly mezi ru˚zny´mi implementacemi tak, aby na vysˇsˇ´ıch vrstva´ch nebyly patrne´. Transportnı´ vrstva poskytuje relacˇnı´ vrstveˇ dva za´kladnı´ druhy sluzˇeb – transport bez spojenı´ a transport se spojenı´m. Dı´lcˇ´ı sluzˇby jsou pak za´visle´ na jedne´ z teˇchto za´kladnı´ch sluzˇeb (naprˇ´ıklad mu˚zˇe by´t poskytova´na sluzˇba detekce a opravy chyb). Kazˇda´ (komunikujı´cı´) entita z vysˇsˇ´ı, relacˇnı´, vrstvy dostane svou vlastnı´ transportnı´ adresu. Transport pak probı´ha´ mezi dveˇma transportnı´mi adresami na ru˚zny´ch syste´mech (tj. z pohledu relacˇnı´ vrstvy mezi dveˇma entitami, ktere´ vyuzˇ´ıvajı´ neˇktery´ SAP k transportnı´ vrstveˇ). Mezi dveˇma transportnı´mi adresami mu˚zˇe probı´hat (teoreticky) jake´koliv mnozˇstvı´ transportu˚. Na transportnı´ vrstveˇ jsou urcˇeny ru˚zne´ trˇ´ıdy sluzˇeb poskytovany´ch entita´m relacˇnı´ vrstvy. Trˇ´ıdy sluzˇeb se lisˇ´ı v ru˚zny´ch parametrech, naprˇ´ıklad chybovost, propustnost, apod. Na transportnı´ vrstveˇ najdeme mnoho funkcı´, naprˇ´ıklad adresova´nı´ (transportnı´ adrese je prˇirˇazena sı´t’ova´ adresa), detekce a oprava chyb, multiplexova´nı´, deˇlenı´ bloku dat nebo naopak jeho skla´da´nı´, atd. Typicke´ protokoly: prˇenosove´ protokoly TCP (se spojenı´m) nebo UDP (bez spojenı´). Relacˇnı´ vrstva (session layer) pracuje s relacemi (session), tedy nava´zany´mi spojenı´mi. Komunikacˇnı´ relace se skla´da´ ze sluzˇebnı´ch dotazu˚ a odpoveˇdı´ probı´hajı´cı´ch mezi aplikacemi na ru˚zny´ch zarˇ´ızenı´ch v sı´ti. Na te´to vrstveˇ jsou implementova´ny protokoly, ve ktery´ch tato komunikace probı´ha´.
P
Relacˇnı´ vrstva tedy zajisˇt’uje organizova´nı´ spojenı´ – navazova´nı´ a ukoncˇova´nı´ prˇenosu˚ (posı´la´ prˇ´ıslusˇne´ prˇ´ıkazy transportnı´ vrstveˇ), synchronizaci komunikace, prˇeklad jmen na adresy a naopak, bezpecˇnost prˇ´ıstupu (neˇco jako telefonnı´ u´strˇedna v telekomunikacı´ch). Jedna entita relacˇnı´ vrstvy mu˚zˇe ve´st vı´ce relacı´ za´rovenˇ. Typicke´ protokoly: NFS (sı´t’ovy´ souborovy´ syste´m), NetBIOS (zprˇ´ıstupnˇova´nı´ dat v mensˇ´ıch sı´tı´ch), SSL (autentizace podporˇena´ sˇifrova´nı´m). Prezentacˇnı´ vrstva (presentation layer) se stara´ o prezentaci dat (tedy jejich vnitrˇnı´ syntaktickou strukturu). Prova´dı´ konverze dat z aplikacˇnı´ vrstvy (prˇevody do jiny´ch typu˚ datove´ reprezentace) a odpovı´da´ za to, zˇe data z aplikacˇnı´ vrstvy jednoho zarˇ´ızenı´ budou srozumitelna´ aplikacˇnı´ vrstveˇ jine´ho zarˇ´ızenı´. Na te´to vrstveˇ se takte´zˇ implementuje sˇifrova´nı´ a komprese.
P
Typicke´ funkce jsou dohoda o syntaxi prˇena´sˇeny´ch dat, transformace syntaxe dat, sˇifrova´nı´, komprese, zˇa´dost o vytvorˇenı´ cˇi zrusˇenı´ relace (pozor – zˇa´dost, ne samotne´ vytvorˇenı´ a zrusˇenı´). Do struktury dat lze zasahovat pouze v te´to vrstveˇ, ostatnı´ vrstvy mohou data pouze deˇlit, spojovat nebo obohacovat o dalsˇ´ı informace. Typicke´ protokoly: SMB (prˇenos souboru˚ – SAMBA), da´le sˇifrovacı´ nebo komprimacˇnı´ protokoly. Aplikacˇnı´ vrstva (application layer) navzdory sve´mu na´zvu neobsahuje sı´t’ove´ aplikace, ale s aplikacemi komunikuje. Obvykle zahrnuje identifikaci, zjisˇt’ova´nı´ dostupnosti zdroju˚, synchronizaci komunikace. Konkre´tneˇ obsahuje funkce (moduly) vyuzˇ´ıvane´ aplikacemi jako je e-mailovy´ klient, FTP klient,
P
A.4
IEEE 802
227
webovy´ klient (Internetovy´ prohlı´zˇecˇ), aplikacemi prˇistupujı´cı´mi ke vzda´leny´m databa´zı´m, apod. Hlavnı´m u´kolem aplikacˇnı´ vrstvy je tedy zajisˇt’ova´nı´ rozhranı´ mezi sı´t’ovy´mi aplikacemi a sı´t’ovy´m komunikacˇnı´m syste´mem. Typicke´ protokoly: SMTP (posı´la´nı´ posˇty), POP3 a IMAP (stahova´nı´ posˇty), FTP nebo TFTP (prˇenos souboru˚), Telnet nebo SSH (vzda´leny´ prˇ´ıstup), SNMP (spra´va sı´teˇ).
A.3.4
PDU
Na ru˚zny´ch vrstva´ch se pouzˇ´ıvajı´ ru˚zne´ PDU (protocol data unit, datove´ jednotky). Ra´mec
se pouzˇ´ıva´ na linkove´ vrstveˇ. Skla´da´ se ze trˇ´ı cˇa´stı´:
• hlavicˇka linkove´ vrstvy (header), • data z vysˇsˇ´ıch vrstev, • paticˇka (trailer), cˇasto obsahuje kontrolnı´ soucˇet (CRC). Paket se pouzˇ´ıva´ na sı´t’ove´ vrstveˇ, ma´ podobnou strukturu (hlavicˇka sı´t’ove´ vrstvy, data z vysˇsˇ´ı vrstvy, paticˇka sı´t’ove´ vrstvy). Datagram (take´ IP datagram) je obdoba paketu v terminologii protokolu IP (take´ na sı´t’ove´ vrstveˇ, u nespojove´ sluzˇby), datagram musı´ by´t zcela samostatna´ PDU (obsahuje vesˇkere´ informace o adresa´tovi i odesı´lateli a cˇ´ıslo porˇadı´ ve zpra´veˇ vysˇsˇ´ı vrstvy). Segment se pouzˇ´ıva´ na transportnı´ vrstveˇ v protokolech TCP a UDP. Jeho de´lka obecneˇ nenı´ omezena, prˇedpokla´da´ se jeho dalsˇ´ı rozdeˇlenı´ na nizˇsˇ´ı (sı´t’ove´) vrstveˇ. Soucˇa´stı´ segmentu neby´vajı´ adresy zdrojove´ho a cı´love´ho uzlu, ty se prˇirˇazujı´ azˇ na sı´t’ove´ vrstveˇ. Zpra´va (message) – jejı´ entity jsou nad sı´t’ovou vrstvou (veˇtsˇinou v aplikacˇnı´ vrstveˇ), je to tedy forma dat pro vysˇsˇ´ı vrstvy. Bunˇka (cell) je prvek o pevne´ velikosti (obvykle velmi male´) pouzˇ´ıvany´ v neˇktery´ch sı´tı´ch (asynchronnı´ch, jako ATM) na linkove´ vrstveˇ.
A.4
IEEE 802
A.4.1
Skupina standardu˚ IEEE 802
Skupina standardu˚ IEEE 802 se zaby´va´ prˇedevsˇ´ım loka´lnı´mi sı´teˇmi, ale take´ metropolitnı´mi sı´teˇmi, funkcı´ podvrstvy LLC v modelu ISO/OSI, funkcemi fyzicke´ vrstvy a dalsˇ´ımi souvisejı´cı´mi rˇesˇenı´mi. V tabulce A.1 najdeme prˇehled standardu˚ IEEE 802.3 se strucˇny´m komenta´rˇem. Z tabulky lze vypozorovat tyto typy loka´lnı´ch sı´tı´: • Ethernet (IEEE 802.3) pouzˇ´ıvajı´cı´ na´hodny´ (nedeterministicky´) prˇ´ıstup CSMA/CD, • Token Bus (IEEE 802.4) pouzˇ´ıvajı´cı´ deterministicky´ prˇ´ıstup prˇeda´va´nı´ tokenu, uzˇ se moc nepouzˇ´ıva´, • Token Ring (IEEE 802.5) s deterministicky´m prˇ´ıstupem prˇeda´va´nı´ tokenu po dvojite´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 (rozpusˇteˇna´) Broadband TAG (rozpusˇteˇna´) Fiber Optic TAG (rozpusˇteˇna´) Isochronous LAN Working Group (integr. data+hlas) Security Working Group Wireless LAN Working Group Demand Priority Working Group (VG-AnyLAN) Cable Modem Working Group (rozpusˇteˇna´) 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: Prˇehled IEEE 802
• IsoEthernet (izochronnı´ Ethernet, IEEE 802.9) pouzˇ´ıvajı´cı´ na´hodny´ prˇ´ıstup CSMA/CD s prioritami pro ru˚zne´ typy signa´lu, neujal se, • WLAN (IEEE 802.11) s na´hodny´m prˇ´ıstupem CSMA/CA na ra´diove´m signa´lu, • 100VG-AnyLAN (IEEE 802.12) varianta fast Ethernetu s deterministicky´m prˇ´ıstupem DPAM, neujala se. Existujı´ i dalsˇ´ı typy sı´tı´, ale nejsou cˇasto normalizova´ny sdruzˇenı´m IEEE. Dalsˇ´ı informace: • Seznam aktivnı´ch standardu˚ IEEE 802: http://standards.ieee.org/getieee802/portfolio.html • Seznam s podrobnostmi IEEE standardu˚ pro LAN a MAN: http://ieeexplore.ieee.org/ISOL/package.jsp?punumber=9&type=P • IEEE standardy obecneˇ pro informacˇnı´ technologie: http://ieeexplore.ieee.org/ISOL/parent.jsp?punumber=4&type=p • Prˇ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/doplnˇky spolecˇne´ pro vsˇechny loka´lnı´ a metropolitnı´ sı´teˇ definovane´ v ostatnı´ch skupina´ch IEEE 802, normy pro propojova´nı´ sı´tı´ a oblast zabezpecˇenı´. Standard 802.1D obsahuje podporu prioritnı´ho zacha´zenı´ s ra´mci – rozdeˇlenı´ prˇ´ıchozı´ch ra´mcu˚ do neˇkolika front s rozdı´lny´mi prioritami, na cˇemzˇ stojı´ naprˇ´ıklad QoS (Quality of Service). Standard 802.1Q obsahuje podporu VLAN (virtua´lnı´ch sı´tı´), ra´mce MAC podvrstvy mohou obsahovat dodatecˇna´ informacˇnı´ pole rˇ´ıdicı´ dorucˇova´nı´ v ra´mci VLAN. Velmi du˚lezˇity´ je standard 802.1X o bezpecˇnosti komunikace v sı´ti. Umozˇnˇuje autentizaci uzˇivatelu˚, distribuci bezpecˇnostnı´ch klı´cˇu˚, integritu zpra´v, apod. To vsˇe ma´ vy´znam prˇedevsˇ´ım u bezdra´tovy´ch prˇipojenı´. Zˇadatel je uzel (obvykle bezdra´tova´ stanice), ktery´ zˇa´da´ o prˇ´ıstup do sı´teˇ, autentiza´tor (prˇ´ıstupovy´ bod) zprostrˇedkova´va´ autentizacˇnı´ informaci, autentizacˇnı´ server (naprˇ´ıklad RADIUS) autentizaci prova´dı´. V te´to komunikaci slouzˇ´ı 802.1X jako zprostrˇedkovatel pro autentizacˇnı´ protokol vysˇsˇ´ı vrstvy (EAP – Extensible Authentication Protocol), pracuje na sı´t’ove´ vrstveˇ. Do IEEE 802.1 patrˇ´ı vı´ce standardu˚, dalsˇ´ı se ponejvı´ce ty´kajı´ VLAN, fungova´nı´ MAC podvrstvy a autentizace.
P
Pˇr´ıloha
B
Pra´ce s adresami a sı´teˇmi ve Windows V te´to prˇ´ıloze jsou popsa´ny a demonstrova´ny prˇ´ıkazy, ktere´ se pouzˇ´ıvajı´ ve Windows prˇi pra´ci se sı´teˇmi, Linuxu se veˇnujeme v dalsˇ´ı prˇ´ıloze. Mu˚zˇeme je zatı´m bra´t jako inspiraci pro procvicˇova´nı´ a taky jako prˇedehru k zatı´m neexistujı´cı´m cvicˇenı´m z tohoto prˇedmeˇtu.
B.1
Proble´my prˇi pouzˇı´va´nı´ prˇı´kazu˚ ve Windows
V serverovy´ch Windows podobneˇ jako v desktopovy´ch varianta´ch je mozˇne´ pro te´meˇrˇ vsˇe pouzˇ´ıt na´stroje graficke´ho rozhranı´. Velmi cˇasto je vsˇak prakticˇteˇjsˇ´ı pouzˇ´ıt Prˇ´ıkazovy´ rˇa´dek – prˇ´ıkazy neˇkdy umeˇjı´ vı´ce nezˇ na´stroje graficke´ho rezˇimu, lze je snadneˇji pouzˇ´ıvat pro vzda´lenou spra´vu a hlavneˇ prˇ´ıkazy je mozˇne´ skriptovat a tedy automatizovat zpracova´nı´ neˇktery´ch u´loh. Ve Windows je s prˇ´ıkazy pro Prˇ´ıkazovy´ rˇa´dek podobny´ proble´m jako v graficke´m rozhranı´: ru˚zne´ verze Windows se v tomto smeˇru hodneˇ lisˇ´ı a neˇktere´ prˇ´ıkazy pracujı´ v ru˚zny´ch verzı´ch odlisˇneˇ. Komplikace se projevujı´ prˇedevsˇ´ım v heterogennı´ch sı´tı´ch, ve ktery´ch jsou uzly s ru˚zny´mi verzemi a prˇ´ıpadneˇ variantami (edicemi) Windows (kdyzˇ pı´sˇeme skript, musı´me dba´t na to, aby byl pouzˇitelny´ na vsˇech uzlech, kde ho potrˇebujeme spousˇteˇt). S proble´my se setka´me naprˇ´ıklad tehdy, kdyzˇ chceme v ra´mci skupiny propojit dva pocˇ´ıtacˇe, jeden s Windows XP a druhy´ s Windows 7 (mladsˇ´ı vidı´ starsˇ´ıho, ale ne naopak). Jistou komplikacı´ je take´ zmeˇna funkcˇnosti RunAs mechanismu – od verze Vista sice porˇa´d existuje prˇ´ıkaz runas pro spusˇteˇnı´ procesu s odlisˇny´mi prˇ´ıstupovy´mi opra´vneˇnı´mi (pod jiny´m uzˇivatelem), ale je problematicky´. Pokud chceme ve Windows od Visty vy´sˇe spustit prˇ´ıkaz s jiny´mi (typicky administra´torsky´mi) opra´vneˇnı´mi nezˇ pod ktery´mi pra´veˇ pracujeme, zvolı´me v kontextove´m menu ikony programu Prˇ´ıkazove´ho rˇa´dku volbu „Spustit jako spra´vce“ a tedy spustı´me s vysˇsˇ´ımi opra´vneˇnı´mi uzˇ program cmd.exe. Svy´m zpu˚sobem to mu˚zˇe by´t bezpecˇnostnı´ proble´m, protozˇe neˇkterˇ´ı uzˇivatele´ zrˇejmeˇ budou na Prˇ´ıkazove´m rˇa´dku s vysˇsˇ´ımi opra´vneˇnı´mi pracovat i tehdy, kdyzˇ to nenı´ nutne´. Pokud chceme neˇktere´ u´lohy prova´deˇt vzda´leneˇ, take´ mu˚zˇeme narazit na prˇ´ıstupova´ opra´vneˇnı´. Obvykle pomu˚zˇe pouzˇ´ıvat dome´novy´ spra´vcovsky´ u´cˇet, ktery´ lze vyuzˇ´ıt na vsˇech zarˇ´ızenı´ch v dome´neˇ. 230
PRA´CE S ADRESAMI A SI´TˇOVY´MI KARTAMI
B.3
B.2
231
Soubory souvisejı´cı´ se sı´teˇmi
Se sı´tı´ souvisı´ vyuzˇ´ıva´nı´ neˇktery´ch (textovy´ch) souboru˚ – nasˇteˇstı´ nenı´ vsˇe v registru, neˇktere´ z nı´zˇe uvedeny´ch souboru˚ budou zmı´neˇny u popisovany´ch prˇ´ıkazu˚. Prˇedevsˇ´ım z du˚vodu kompatibility se sı´t’ovy´mi protokoly a ne-windows sı´t’ovy´mi klienty existujı´ ve slozˇce ...\system32\drivers\etc tyto soubory:
$
• networks – obsahuje dome´nove´ a IP adresy loka´lnı´ch sı´tı´, • hosts – urychluje mapova´nı´ IP adres na zna´me´ dome´nove´ adresy (hostitele, anglicky hosts), jaky´si staticky´ za´stup DNS sluzˇeb, • services – informace o zna´my´ch sı´t’ovy´ch sluzˇba´ch, • protocol – informace o zna´my´ch sı´t’ovy´ch protokolech, • lmhosts.sam – tento soubor se drˇ´ıve pouzˇ´ıval pro stejne´ u´cˇely jako hosts (ve Windows prˇeklad IP adres na NetBIOS na´zvy), v soucˇasne´ dobeˇ se uzˇ prakticky nevyuzˇ´ıva´ Ve Windows 7 tyto soubory pravdeˇpodobneˇ nenajdeme vu˚bec (nebo je vsˇe zakomentova´no), v ostatnı´ch 64bitovy´ch Windows jde o slozˇku ...\sysWOW64\drivers\etc. Vzpomenˇte si, zˇe v unixovy´ch syste´mech jsou v adresa´rˇi /etc nejru˚zneˇjsˇ´ı konfiguracˇnı´ soubory vcˇetneˇ sı´t’ovy´ch, zde si Microsoft bral inspiraci. ´ koly U Prohle´dneˇte si obsah souboru˚ networks, hosts, services a protocol zmı´neˇny´ch v te´to sekci.
B.3
Pra´ce s adresami a sı´t’ovy´mi kartami
B.3.1
Za´kladnı´ pra´ce s IP adresami – ipconfig
Pro zobrazenı´ informacı´ o adresa´ch mu˚zˇeme pouzˇ´ıt prˇ´ıkaz ipconfig. (nebo ipconfig -?) zobrazı´ seznam parametru˚ ipconfig /all vypı´sˇe podrobne´ informace (IP a MAC adresu, adresu bra´ny, masku podsı´teˇ) ipconfig /release na ´zev_karty uvolneˇnı´ IP adresy prˇideˇlene´ zadane´ sı´t’ove´ karteˇ (kdyzˇ neuvedeme na´zev karty, jsou uvolneˇny IP adresy vsˇech karet, je mozˇne´ take´ pouzˇ´ıt hveˇzdicˇkovou konvenci) ipconfig /renew na ´zev_karty obnovenı´ prˇideˇlenı´ IP adresy pro zadanou sı´t’ovou kartu (kdyzˇ nenı´ na´zev karty uveden, provede se pro vsˇechny dostupne´ karty) ipconfig /displaydns zobrazı´ za´znamy adres prˇideˇleny´ch v syste´mu DNS (informace k prˇ´ıslusˇny´m DNS jme´nu˚m vcˇetneˇ hodnoty TTL1 ), a to jak ve smeˇru dome´nove´ jme´no → IP adresa, tak i ve smeˇru opacˇne´m (reverznı´ adresy, ty jsou v za´hlavı´ oznacˇeny rˇeteˇzcem „in-addr.arpa“); vzˇdy jsou zobrazeny alesponˇ dva za´znamy (localhost a jeho reverznı´ adresa)
ipconfig /?
1
TTL (Time to Live) je cˇ´ıtacˇ ulozˇeny´ v hlavicˇce IP datagramu, ktery´ se prˇi pru˚chodu ktere´hokoliv smeˇrovacˇe na cesteˇ snizˇuje (nejme´neˇ) o 1. Hlavnı´m u´cˇelem je omezenı´ pocˇtu „bloudı´cı´ch“ datagramu˚. Pokud hodnota TTL vyprsˇ´ı (klesne na 0), smeˇrovacˇ, ktery´ vyprsˇenı´ zjistı´, uzˇ da´l datagram neposı´la´, ale odesˇle zdroji datagramu informaci o prˇekrocˇenı´ povolene´ho TTL.
$
B.3
PRA´CE S ADRESAMI A SI´TˇOVY´MI KARTAMI
232
vymazˇe DNS cache (tj. dotazy na dome´nove´ adresy, ktere´ takto z cache smazˇeme, se musejı´ prova´deˇt znovu), pouzˇijeme, pokud DNS prˇeklad funguje nekorektneˇ (ma´me v cache chybne´ cˇi neaktua´lnı´ za´znamy)
ipconfig /flushdns
Prˇı´klad Vy´stup prˇ´ıkazu mu˚zˇe vypadat naprˇ´ıklad takto (za´lezˇ´ı na verzi Windows, nejdrˇ´ıv ve Windows XP): C:\Windows> ipconfig /all Konfigurace protokolu IP syste ´mu Windows Na ´zev hostitele . . . Prima ´rnı ´ pr ˇı ´pona DNS. Typ uzlu . . . . . . Povoleno sme ˇrova ´nı ´ IP WINS Proxy povoleno .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
: : : : :
PCPRACE
M
nezna ´my ´ Ne Ne
Adapte ´r sı ´te ˇ Ethernet Pr ˇipojenı ´ k mı ´stnı ´ sı ´ti: Pr ˇ´ ıpona DNS podle pr ˇipojenı ´ Popis . . . . . . . . . . . Fyzicka ´ Adresa. . . . . . . Protokol DHCP povolen . . . Adresa IP . . . . . . . . . Maska podsı ´te ˇ . . . . . . . Vy ´chozı ´ bra ´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
Vy´stup te´hozˇ prˇ´ıkazu ve Windows 7 je hodneˇ dlouhy´, vyjmeme pouze cˇa´st vy´stupu odpovı´dajı´cı´ jedne´ ethernetove´ karteˇ: ... Adapte ´r sı ´te ˇ Ethernet Pr ˇipojenı ´ k mı ´stnı ´ sı ´ti: Pr ˇı ´pona DNS podle pr ˇipojenı ´ . . . : fpf.slu.cz Popis . . . . . . . . . . . . . . : Atheros AR8131 PCI-E Gigabit Ethernet Controller (NDIS 6.20) Fyzicka ´ Adresa. . . . . . . . . . : E0-CB-4E-45-67-89 Protokol DHCP povolen . . . . . . : Ano Automaticka ´ konfigurace povolena : Ano Mı ´stnı ´ IPv6 adresa v ra ´mci propojenı ´ . . . : fe80::ec8b:a3a6:68bc:9b2f%11 (Preferovane ´) Adresa IPv4 . . . . . . . . . . . : 193.84.194.100(Preferovane ´) Maska podsı ´te ˇ . . . . . . . . . . : 255.255.255.128 Zapu ˚jc ˇeno . . . . . . . . . . . . : 9. c ˇervna 2011 15:25:14 Za ´pu ˚jc ˇka vyprs ˇı ´ . . . . . . . . . : 9. c ˇervna 2011 21:25:14 Vy ´chozı ´ bra ´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
PRA´CE S ADRESAMI A SI´TˇOVY´MI KARTAMI
233
Rˇeteˇzec DUID (DHCP Unique Identifier) jednoznacˇneˇ identifikuje klienta serveru DHCPv6 a naopak (je jedinecˇne´ pro danou konverzaci s DHCP serverem prˇi stanovenı´ konfiguracˇnı´ch parametru˚. Vsˇimneˇte si vazby na MAC adresu. Cˇ´ıslo IAID (Identity Association Identifier) jednoznacˇneˇ identifikuje sadu adres prˇideˇleny´ch DHCP klientovi. Klient mu˚zˇe mı´t k dane´mu sı´t’ove´mu rozhranı´ vı´ce sad IPv6 adres (plus dalsˇ´ı potrˇebne´ adresy, naprˇ´ıklad musı´ zna´t adresu DNS serveru), kazˇda´ takova´ sada musı´ mı´t jine´ IAID.
Prˇı´klad Pokud se nedarˇ´ı nava´zat sı´t’ove´ spojenı´ nebo spojenı´ nefunguje korektneˇ (naprˇ´ıklad tehdy, kdyzˇ nasˇe sı´t’ova´ karta omylem zı´skala IP adresu, ktera´ je jizˇ prˇideˇlena jine´mu zarˇ´ızenı´, a nebo nebyly korektneˇ zı´ska´ny adresy DNS serveru˚), mu˚zˇe pomoci znovuzı´ska´nı´ IP adresy a souvisejı´cı´ch informacı´ (adresa bra´ny, adresy DNS serveru˚). Pouzˇijeme postupneˇ tyto prˇ´ıkazy: procˇistı´me DNS cache, tı´m se zbavı´me starsˇ´ıch potencia´lneˇ chybny´ch za´znamu˚ (tento krok nemusı´ by´t nutny´)
ipconfig /flushdns
uvolneˇnı´ IP adresy prˇideˇlene´ vsˇem sı´t’ovy´m karta´m, ale cˇasto neby´va´ nutne´
ipconfig /release ipconfig /renew ipconfig /all
obnovenı´ prˇideˇlenı´ IP adresy vsˇech sı´t’ovy´ch karet oveˇrˇ´ıme si, zda je vsˇe vporˇa´dku
Tento postup samozrˇejmeˇ nebudeme pouzˇ´ıvat, pokud ma´me pevnou (statickou) IP adresu. Kdybychom se o to pokusili, obdrzˇ´ıme chybove´ hla´sˇenı´ sdeˇlujı´cı´, zˇe dany´ adapte´r (tj. sı´t’ova´ karta) nenı´ ve sluzˇbeˇ DHCP povolen (proto nemu˚zˇe zˇa´dat na DHCP serveru jinou adresu). Kdyzˇ budeme chtı´t takto obnovit adresu pro jedinou konkre´tnı´ kartu, zada´me v prˇ´ıkazech na´zev (mu˚zˇeme pouzˇ´ıvat i hveˇzdicˇkovou konvenci pro zkra´cenı´ na´zvu), naprˇ´ıklad ipconfig /release Pr ˇipojenı ´*1
(pokud ma´me sı´t’ovou kartu s na´zvem „Prˇipojenı´ k mı´stnı´ sı´ti 1“).
B.3.2
Prˇeklad adres – arp a nslookup
ARP je protokol prˇeva´deˇjı´cı´ IP adresy na fyzicke´ (MAC) adresy. Fyzicka´ adresa je v sı´ti zjisˇt’ova´na odesı´la´nı´m tzv. ARP paketu˚ s dotazy. Aby nebylo nutne´ opakovaneˇ posı´lat tyto pakety, udrzˇuje kazˇde´ sı´t’ove´ zarˇ´ızenı´ (tj. take´ zvla´sˇt’kazˇda´ sı´t’ova´ karta) mezipameˇt’, do ktere´ ukla´da´ dosud zjisˇteˇne´ dvojice IP a fyzicky´ch adres (ARP tabulky). ARP tabulku je mozˇne´ prohlı´zˇet a prˇida´vat i mazat za´znamy. Uka´zˇeme si vyuzˇitı´ prˇ´ıkazu arp, ktery´ slouzˇ´ı pra´veˇ k pra´ci s ARP tabulkou. zobrazı´ ARP tabulku, take´ vidı´me, ktere´ za´znamy jsou dynamicke´ (automaticky vytvorˇene´ z komunikace) a ktere´ staticke´ (rucˇneˇ vlozˇene´)
arp -a
arp -a -n 10.0.128.10
zobrazı´ ARP tabulku pouze pro sı´t’ovou kartu, ktera´ ma´ prˇideˇlenu
zadanou IP adresu prˇida´ se do ARP tabulky staticky´ za´znam se vztahem zadane´ IP adresy a MAC (fyzicke´) adresy, MAC adresa se zada´va´ v hexadecima´lnı´ch cˇ´ıslech s pomlcˇkami
arp -s 123.123.123.123 00-12-34-56-78-9A
$
B.3
PRA´CE S ADRESAMI A SI´TˇOVY´MI KARTAMI
arp -d 123.123.123.123 arp -d *
234
odstranı´ z ARP tabulky za´znam pro zadanou IP adresu
odstranı´ z ARP tabulky vsˇechny za´znamy
Lze prˇidat parametr s urcˇenı´m IP adresy sı´t’ove´ karty, pro kterou dana´ ARP tabulka platı´ (kazˇda´ karta ma´ svou tabulku), to ma´ smysl jen v prˇ´ıpadeˇ, kdy je v provozu vı´c nezˇ jedna sı´t’ova´ karta. Prˇı´klad ARP tabulka mu˚zˇe vypadat takto (na Windows 7): C:\Windows> arp -a Rozhranı ´: 193.84.194.100 --- 0xb internetova ´ adresa fyzicka ´ 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 dynamicka ´ dynamicka ´ dynamicka ´ dynamicka ´ dynamicka ´ dynamicka ´ dynamicka ´ dynamicka ´ dynamicka ´ staticka ´ staticka ´ staticka ´ staticka ´ staticka ´ staticka ´
M
Ve Windows nizˇsˇ´ıch verzı´ (prˇedevsˇ´ım od XP nı´zˇe) je ARP tabulka vy´razneˇ kratsˇ´ı. V tabulce vidı´me dynamicke´ i staticke´ za´znamy, u vsˇech je IP a MAC adresa. Vsˇimneˇte si skupinovy´ch a vsˇesmeˇrovy´ch IP a MAC adres (samozrˇejmeˇ platı´, zˇe ke skupinove´ IP adrese bude patrˇit skupinova´ MAC adresa a naopak).
Zatı´mco protokol ARP slouzˇ´ı k prˇekladu IP adresy na MAC adresu, protokol DNS slouzˇ´ı k prˇekladu dome´nove´ adresy na IP adresu. Pro za´kladnı´ prˇ´ıstup k tomuto prˇekladu lze i na klientsky´ch stanicı´ch vyuzˇ´ıt prˇ´ıkaz nslookup. Prˇ´ıkaz lze vyuzˇ´ıvat beˇzˇny´m zpu˚sobem i interaktivneˇ. vypı´sˇe se nejdrˇ´ıv adresa DNS serveru, ktery´ poskytl odpoveˇd’, a pak samotna´ odpoveˇd’ (IP adresy a aliasy pro zadany´ dome´novy´ na´zev)
nslookup www.seznam.cz nslookup 77.76.75.3 nslookup
reverznı´ prˇeklad, takto zjistı´me dome´novou adresu k te´to IP adrese
prˇechod do interaktivnı´ho rezˇimu, tento rezˇim ukoncˇ´ıme prˇ´ıkazem exit
Meˇli bychom si prˇedevsˇ´ım uveˇdomit, zˇe plnou na´poveˇdu k tomuto prˇ´ıkazu zı´ska´me pouze v interaktivnı´m rezˇimu: tedy vy´sˇe uvedeny´m prˇ´ıkazem prˇejdeme do interaktivnı´ho rezˇimu a pak zada´me prˇ´ıkaz ? nebo help. Prˇı´klad Uka´zˇeme si pra´ci v interaktivnı´m rezˇimu: nslookup
spustı´me program nslookup, prompt se zmeˇnı´ na symbol >
$
B.3
PRA´CE S ADRESAMI A SI´TˇOVY´MI KARTAMI
235
zobrazı´me na´poveˇdu, je znacˇneˇ podrobneˇjsˇ´ı nezˇ nslookup /? vneˇ interaktivnı´ho rezˇimu; take´ lze pouzˇ´ıt vnitrˇnı´ prˇ´ıkaz help www.google.com napı´sˇeme dome´novou adresu, zı´ska´me IP adresu, vy´stup (v ru˚zny´ch verzı´ch Windows se ve vy´stupech setka´me s vı´ce cˇi me´neˇ kostrbatou cˇesˇtinou):
?
Server: decsu.fpf.slu.cz Address: 193.84.192.10
M
Neautorizovana odpoved: Na ´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 prˇ´ıkazu set nic nenastavuje, ale informuje na´s o momenta´lnı´m nastavenı´ pro poslednı´ zadanou adresu (v nasˇem prˇ´ıpadeˇ pro www.google.com; pokud jsme prˇedtı´m nic neprˇekla´dali, pak obecneˇ platna´ nastavenı´), vy´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
Takzˇe se naprˇ´ıklad dozvı´me, zˇe se pouzˇil rekurzivnı´ dotaz, jedna´ se o za´znam adresy pro IPv4 i IPv6 (typ A+AAAA), atd.
M
B.3
PRA´CE S ADRESAMI A SI´TˇOVY´MI KARTAMI
236
od te´to chvı´le bude pozˇadova´n iterativnı´ (nerekurzivnı´) typ dotazu˚, zpeˇt nastavı´me prˇ´ıkazem set recurse
set norecurse ls fpf.slu.cz
chceme vypsat adresy (pocˇ´ıtacˇe) v zadane´ dome´neˇ, vy´pis je celkem dlouhy´
ls -t ns fpf.slu.cz
oproti prˇedchozı´mu se vypı´sˇou pouze dome´nove´ servery (typ je NS,
name server) ls -t aaaa slu.cz
vypı´sˇou se zarˇ´ızenı´ s IPv6 adresou (tj. za´znamy typu AAAA) v zadane´
dome´neˇ
B.3.3
Smeˇrova´nı´ – route
Pokud posı´la´me data na urcˇitou IP adresu, pakety obvykle (ne vzˇdy) procha´zejı´ prˇes bra´nu do Internetu cˇi jine´ sı´teˇ. Proto kazˇdy´ uzel sı´teˇ vcˇetneˇ klientsky´ch pocˇ´ıtacˇu˚ zna´ adresu bra´ny a prˇ´ıpadneˇ dalsˇ´ı smeˇrovacı´ informace (tj. ktery´m smeˇrem poslat data do urcˇite´ (pod)sı´teˇ), vede si svou smeˇrovacı´ tabulku. Do tabulky lze vkla´dat za´znamy rucˇneˇ (staticke´ za´znamy) nebo dynamicky (prova´deˇjı´ smeˇrovacı´ protokoly). Ve Windows se s touto tabulkou pracuje prˇ´ıkazem route. route
(nebo s jaky´mkoliv nespra´vny´m parametrem) zobrazı´ na´poveˇdu k prˇ´ıkazu
$
vypı´sˇe smeˇrovacı´ tabulku, v nejnoveˇjsˇ´ıch verzı´ch Windows vlastneˇ dveˇ tabulky – zvla´sˇt’pro IPv4 a IPv6; na zacˇa´tku vy´pisu take´ ma´me seznam vsˇech sı´t’ovy´ch rozhranı´ vcˇetneˇ virtua´lnı´ch, tento seznam mu˚zˇe by´t take´ uzˇitecˇny´
route print
vypı´sˇe pouze ty cı´le ze smeˇrovacı´ tabulky, ktere´ odpovı´dajı´ zadane´mu vy´razu (mu˚zˇeme pouzˇ´ıvat hveˇzdicˇkovou konvenci, take´ 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 prˇida´ staticky´ za´znam urcˇujı´cı´, zˇe k sı´ti s IP adresou 193.84.195.8 a maskou 255.255.255.128 se da´ dostat prˇes bra´nu s IP adresou 193.84.195.63 a metrika (cena trasy) je 8
tote´zˇ jako prˇedchozı´, ale za´znam zu˚stane v tabulce i po restartu syste´mu (bez prˇepı´nacˇe -p by byl za´znam platny´ jen do konce cˇinnosti syste´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 zmeˇna
existujı´cı´ polozˇky tabulky (zmeˇna platı´ i po restartu), zmeˇnili jsme adresu bra´ny, metriku a navı´c jsme nastavili smeˇrova´nı´ na sı´t’ove´ rozhranı´ (kartu) cˇ´ıslo 2, k dane´mu cı´li zada´va´me vzˇdy jen ty polozˇky, ktere´ chceme zmeˇnit route del 193.84.197.0
odstranı´me za´znam z tabulky (lze pouzˇ´ıt i hveˇzdicˇkovou konvenci)
Za´znamy ve smeˇrovacı´ tabulce lze tı´mto prˇ´ıkazem take´ mazat a meˇnit. Kdyzˇ ma´me vı´ce sı´t’ovy´ch karet, lze v prˇ´ıkazu pro prˇida´nı´ do tabulky pouzˇ´ıt i parametr urcˇujı´cı´ sı´t’ove´ rozhranı´. Prˇı´klad Prˇ´ıkaz route print ve Windows XP vypı´sˇe tento vy´stup: =========================================================================== Seznam rozhranı ´
M
B.3
PRA´CE S ADRESAMI A SI´TˇOVY´MI KARTAMI
237
0x1 ........................... MS TCP Loopback interface 0x2 ...00 0f fe 12 34 56 ...... Broadcom NetXtreme Gigabit Ethernet - Packet Scheduler Miniport =========================================================================== =========================================================================== Aktivnı ´ sme ˇrova ´nı ´: Cı ´l v˜sı ´ti Sı ´t’ova ´ maska Bra ´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 Vy ´chozı ´ bra ´na: 193.84.195.1 =========================================================================== Trvale ´ trasy: ˇa Z ´dne ´
V seznamu sı´t’ovy´ch rozhranı´ jsou pouze dveˇ, jedno je loopback (mı´stnı´ smycˇka), druhe´ je ethernetova´ sı´t’ova´ karta. Ve vysˇsˇ´ıch verzı´ch bychom zde videˇli vı´ce za´znamu˚ (rea´lne´ sı´t’ove´ karty ethernetove´, Wi-fi, Bluetooth, ale i virtua´lnı´ zarˇ´ızenı´), a take´ virtua´lnı´ pocˇ´ıtacˇe si instalujı´ vlastnı´ virtua´lnı´ sı´t’ove´ karty. Naprˇ´ıklad pokud pouzˇ´ıva´me virtua´lnı´ pocˇ´ıtacˇ od VMWare, najdeme v seznamu rozhranı´ podobne´ za´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
Vy´pis byl porˇ´ızen na stroji, jehozˇ sı´t’ova´ karta (jedina´) ma´ prˇirˇazenu IP adresu 193.84.195.15, vsˇimneˇte si, kde vsˇude se tato adresa v tabulce vyskytuje (naprˇ´ıklad u mı´stnı´ch a multicast smeˇrova´nı´). Z vy´pisu vidı´me, zˇe zˇa´dne´ staticke´ (trvale´) trasy nejsou definova´ny. Vsˇimneˇte si, zˇe poslednı´ rˇa´dek tabulky obsahuje informaci o vy´chozı´ bra´neˇ – co nenı´ smeˇrova´no podle vy´sˇe uvedeny´ch pravidel, to odcha´zı´ na zadanou vy´chozı´ bra´nu.
Pokud zada´me sı´t’ove´ zarˇ´ızenı´ cˇi na´zev sı´teˇ symbolicky´m na´zvem, prˇ´ıkaz tento na´zev musı´ prˇelozˇit na IP adresu. K tomu vyuzˇije obsah souboru • ...\windows\system32\drivers\etc\networks, pokud jde o na´zev cı´le smeˇrova´nı´ (obvykle to by´va´ sı´t’cˇi podsı´t’), • ...\windows\system32\drivers\etc\hosts, pokud jde o bra´nu (bra´na je konkre´tnı´ uzel v sı´ti, tedy hostitel protokolu, anglicky host). Do teˇchto souboru˚ mu˚zˇeme prˇida´vat vlastnı´ symbolicke´ na´zvy (je to celkem jednoduche´, soubory jsou okomentova´ny). V souboru hosts je vzˇdy nejme´neˇ jeden na´zev uzlu, a to localhost. ´ koly U 1. Zjisteˇte svou IP adresu, masku, adresu bra´ny, adresu DNS serveru. 2. Ma´te statickou IP adresu nebo ji zı´ska´va´te dynamicky od DHCP serveru? Kde to zjistı´te? Pokud ma´te dynamickou adresu, uvolneˇte ji (deaktivujte sı´t’ovou kartu) a zı´skejte novou.
M
B.3
PRA´CE S ADRESAMI A SI´TˇOVY´MI KARTAMI
238
3. Zobrazte ARP tabulku. 4. Zjisteˇte IP adresu serveru extrahardware.cz. 5. Zjisteˇte adresu sve´ho DNS serveru, zda prˇi komunikaci s DNS serverem pouzˇ´ıva´te rekurzivnı´ nebo iterativnı´ dotazy, na ktere´m portu komunikujete, v jake´ jste dome´neˇ. Vypisˇte seznam uzlu˚ ve vasˇ´ı dome´neˇ. 6. Vypisˇte smeˇrovacı´ tabulku na vasˇem pocˇ´ıtacˇi.
B.3.4
Mala´ sı´t’a skupina (workgroup)
Na syste´mech s Windows se setka´va´me take´ se zkratkou NBT (nebo NetBT, NetBIOS over TCP/IP). Samotny´ NetBIOS funguje defacto jako jmenna´, spojovacı´ a komunikacˇnı´ sluzˇba v maly´ch sı´tı´ch s Windows (skupiny pocˇ´ıtacˇu˚ v sı´ti typu peer-to-peer). Umozˇnˇuje ve skupina´ch sdı´let ru˚zne´ prostrˇedky (slozˇky, tiska´rny). Na´zvy pocˇ´ıtacˇu˚, ktere´ zada´va´me v graficke´m rozhranı´ Windows, jsou vlastneˇ na´zvy podle protokolu NetBIOS. Aby bylo mozˇne´ na´zvy NetBIOSu pouzˇ´ıvat i mimo male´ sı´teˇ, pracuje dnes NetBIOS nad protokoly TCP/IP ve formeˇ NBT. Pro pra´ci s na´zvy v NBT mu˚zˇeme vyuzˇ´ıt prˇ´ıkazy hostname a nbtstat: zobrazı´ jme´no nasˇeho pocˇ´ıtacˇe v NBT
hostname nbtstat
$
zobrazı´ na´poveˇdu prˇ´ıkazu nbtstat
zjistı´me vsˇechny na´zvy podle protokolu NBT, ktere´ souvisejı´ s tı´mto zarˇ´ızenı´m (tj. obvykle jen na´zev nasˇeho pocˇ´ıtacˇe, pokud pocˇ´ıtacˇ patrˇ´ı do skupiny, tak i na´zev te´to skupiny), jestlizˇe ma´me vı´ce sı´t’ovy´ch karet (tj. vı´ce rozhranı´), pak se zobrazı´ zvla´sˇt’tabulky pro vsˇechna aktivnı´ rozhranı´ (ktera´ majı´ prˇideˇlenu IP adresu), i kdyzˇ u vsˇech najdeme stejny´ NBT na´zev
nbtstat -n
nbtstat -c
vypı´sˇe se seznam ostatnı´ch pocˇ´ıtacˇu˚ ve skupineˇ (NetBIOS na´zvy a IP adresy)
nbtstat -a poc ˇı ´tac ˇ
tote´zˇ, ale pro jiny´ (zadany´) pocˇ´ıtacˇ patrˇ´ıcı´ do nasˇ´ı skupiny, zada´va´me
NetBIOS jme´no nbtstat -A IP_adresa
tote´zˇ jako prˇedchozı´, ale pocˇ´ıtacˇ zada´va´me jeho IP adresou
Take´ mu˚zˇeme zobrazit tabulku relacı´ s dany´m uzlem v sı´ti (skupineˇ). Prˇı´klad Prˇedpokla´dejme, zˇe ma´me dva pocˇ´ıtacˇe: • pcnotebook s IP adresou 10.0.0.1, • pcdesktop s IP adresou 10.0.0.3, oba prˇipojene´ ve skupineˇ mojeskupina. Na prvnı´m z nich nejdrˇ´ıv vypı´sˇeme tabulku mı´stnı´ch NBT na´zvu˚: C:\Windows> nbtstat -n Pr ˇipojenı ´ k mı ´stnı ´ sı ´ti: Adresa IP uzlu: [10.0.0.1] ID oboru: [] Tabulka mı ´stnı ´ch na ´zvu ˚ syste ´mu NetBIOS
M
B.4
TESTOVA´NI´ A STATISTIKY
239
Na ´zev Typ Stav ---------------------------------------------PCNOTEBOOK <00> UNIQUE Registrovany ´ MOJESKUPINA <00> GROUP Registrovany ´ PCNOTEBOOK <20> UNIQUE Registrovany ´
Ted’ na tomte´zˇ pocˇ´ıtacˇi vypı´sˇeme seznam dostupny´ch pocˇ´ıtacˇu˚: C:\Windows> nbtstat -c Pr ˇipojenı ´ k mı ´stnı ´ sı ´ti: Adresa IP uzlu: [10.0.0.1] ID oboru: []
M
Na ´zev vzda ´lene ´ pame ˇti NetBIOS Tabulka ˇ Na ´zev Typ Adr. hostitele Zivotnost [sek] ----------------------------------------------------------------PCDESKTOP <20> UNIQUE 10.0.0.3 92
Pokud dostaneme jen chybovou hla´sˇku „V mezipameˇti nejsou zˇa´dne´ na´zvy“, du˚vodem mu˚zˇe by´t to, zˇe pocˇ´ıtacˇe nejsou ve stejne´ skupineˇ (tj. nevidı´ se), ale take´ se tento proble´m mu˚zˇe/nemusı´ objevit, pokud na teˇchto pocˇ´ıtacˇ´ıch ma´me ru˚zne´ verze Windows. Mu˚zˇeme take´ vypsat NBT tabulku druhe´ho pocˇ´ıtacˇe (jsme porˇa´d na tomte´zˇ pocˇ´ıtacˇi): C:\Windows> nbtstat -a pcdesktop Pr ˇipojenı ´ k mı ´stnı ´ sı ´ti: Adresa IP uzlu: [10.0.0.1] ID oboru: [] Tabulka na ´zvu ˚ vzda ´leny ´ch poc ˇı ´tac ˇ˚ u NetBIOS Na ´zev Typ Stav ---------------------------------------------PCDESKTOP <00> UNIQUE Registrovany ´ MOJESKUPINA <00> GROUP Registrovany ´ PCDESKTOP <20> UNIQUE Registrovany ´ Adresa MAC = 00-1D-0F-12-34-56
Jiny´ prˇepı´nacˇ pouzˇijeme, pokud prˇ´ıkaz zada´me s vyuzˇitı´m IP adresy: nbtstat -A 10.0.0.3
Vy´stup by byl tenty´zˇ jako v prˇedchozı´m prˇ´ıpadeˇ. Prˇ´ıkaz bohuzˇel neprˇijı´ma´ regula´rnı´ vy´razy ani hveˇzdicˇkovou konvenci, tedy prˇ´ıpadnou automatizaci (naprˇ´ıklad vypsa´nı´ u´daju˚ pro vı´ce ru˚zny´ch adres) bychom mohli rˇesˇit naprˇ´ıklad prˇ´ıkazem for (viz skripta pro Windows z prˇedmeˇtu Operacˇnı´ syste´my).
´ koly U Pokud jste v LAN s vı´ce pocˇ´ıtacˇi, ktere´ jsou ve stejne´ skupineˇ, vyzkousˇejte pouzˇitı´ prˇ´ıkazu nbtstat podle uka´zek v prˇ´ıkladech. Pokud ne, vyzkousˇejte alesponˇ vy´pis NBT na´zvu˚ na vlastnı´m pocˇ´ıtacˇi.
M
B.4
TESTOVA´NI´ A STATISTIKY
B.4
Testova´nı´ a statistiky
B.4.1
Testova´nı´ cesty a pru˚chodnosti
240
To, zda je dostupna´ dome´nova´ nebo IP adresa (resp. prˇ´ıslusˇne´ zarˇ´ızenı´ na sı´ti), zjistı´me prˇ´ıkazem ping. Tento prˇ´ıkaz odesı´la´ k dane´mu zarˇ´ızenı´ ICMP pakety (zpra´vy ICMP Echo Request) a podle zaslany´ch odpoveˇdı´ urcˇuje, zda je pocˇ´ıtacˇ dostupny´ a jaka´ je odezva prˇipojenı´ (pokud ma´ vzda´leny´ pocˇ´ıtacˇ firewall nakonfigurovany´ tak, aby pozˇadavky ping byly ignorova´ny, mu˚zˇe se pocˇ´ıtacˇ jevit jako nedostupny´)
$
zjistı´, zda je zadany´ server dostupny´ (je dostupny´ prakticky vzˇdy, tedy pokud se zobrazı´ hla´sˇka, zˇe tomu tak nenı´, zrˇejmeˇ nejsme prˇipojeni k sı´ti nebo je neˇkde na cesteˇ porucha)
ping www.google.com
tento parametr omezı´ (nebo u veˇtsˇ´ıho cˇ´ısla navy´sˇ´ı) pocˇet odesı´lany´ch testovacı´ch paketu˚, zde na 2; vy´chozı´ hodnota je 4 pakety
ping -n 2 www.google.com
pocˇet odesı´lany´ch paketu˚ nenı´ stanoven, posı´lajı´ se opakovaneˇ azˇ do prˇerusˇenı´ kla´vesovou zkratkou Ctrl+C
ping -t www.google.com
Prˇı´klad Prˇ´ıkaz ping mu˚zˇeme pouzˇ´ıt i pro otestova´nı´ funkcˇnosti vlastnı´ sı´t’ove´ karty: ping loopback nebo ping 127.0.0.1
Prˇı´klad Jestlizˇe se sı´t’ove´ spojenı´ podle parametru˚ zda´ v porˇa´dku, ale ve skutecˇnosti nefunguje, oveˇrˇ´ıme, zda je funkcˇnı´ DNS prˇeklad adres (dome´novy´ch adres na IP adresy): zrˇejmeˇ skoncˇ´ı chybovy´m hla´sˇenı´m, kdyzˇ spojenı´ nefunguje (mu˚zˇeme pouzˇ´ıt adresu jake´hokoliv serveru na Internetu, u ktere´ho ma´me jistotu, zˇe odpovı´da´ na zˇa´dosti prˇ´ıkazu ping)
ping www.google.com
provedeme tote´zˇ, ale pouzˇijeme IP adresu (zde se jedna´ o IP adresu serveru z prˇedchozı´ho prˇ´ıkazu)
ping 74.125.79.104
Pokud byl druhy´ prˇ´ıkaz u´speˇsˇny´, pravdeˇpodobneˇ ma´me adresu nefunkcˇnı´ho DNS serveru (nebo nema´me zˇa´dnou). Meˇli bychom tedy reagovat bud’ zjisˇteˇnı´m spra´vne´ adresy (naprˇ´ıklad u sve´ho poskytovatele prˇipojenı´) nebo pouzˇitı´m adresy verˇejne´ho DNS serveru. Takovy´ch serveru˚ jizˇ existuje dostatek, naprˇ´ıklad Google ma´ verˇejne´ DNS servery na adresa´ch 8.8.8.8 a 8.8.4.4, prˇ´ıpadneˇ mu ˚ zˇeme pouzˇ´ıt DNS servery sdruzˇenı´ CZ.NIC 217.31.204.130 nebo 217.31.204.131. Ve Windows se adresy DNS serveru˚ nastavujı´ v graficke´m rezˇimu, v Sı´t’ovy´ch prˇipojenı´ch (vlastnostech protokolu TCP/IP). Na´vod najdeme naprˇ´ıklad na adrese http://www.nic.cz/page/847/jak-nastavit-verejne-dns-servery-cz.nic/.
L
B.4
TESTOVA´NI´ A STATISTIKY
241
Program tracert pouzˇ´ıva´me, kdyzˇ chceme zna´t cestu, po ktere´ procha´zejı´ nasˇe datagramy (tj. adresy smeˇrovacˇu˚ na cesteˇ). Ve Windows se pouzˇ´ıva´ metoda ICMP paketu˚ posı´lany´ch v IP datagramech s postupneˇ se zvysˇujı´cı´ hodnotou TTL (podrobnosti u protokolu˚ ICMP, IPv4 a IPv6 v prvnı´ kapitole). tracert -?
$
vypı´sˇe na´poveˇdu (pozor, unixova´ syntaxe, prˇepı´nacˇe pı´sˇeme s pomlcˇkou)
chceme trasu k zadane´mu serveru, postupneˇ (celkem pomalu) se vypı´sˇou vsˇechny smeˇrovacˇe na cesteˇ vcˇetneˇ odezvy v ms pocˇ´ıtane´ od prˇedchozı´ho uzlu
tracert www.google.com
Mu˚zˇeme zadat take´ IP adresu. Metoda ICMP paketu˚ je pomeˇrneˇ pomala´. Navı´c neˇktere´ smeˇrovacˇe jsou z bezpecˇnostnı´ch du˚vodu˚ nastaveny tak, aby neodpovı´daly na ICMP pakety (pak od dotycˇne´ho uzlu obdrzˇ´ıme informaci o vyprsˇenı´ cˇasove´ho limitu zˇa´dosti), take´ je obvykle´, zˇe se takto nedostaneme prˇ´ımo ke konkre´tnı´mu serveru, ale jen ke smeˇrovacˇi na okraji sı´teˇ, ve ktere´ je dany´ server. Program pathping slouzˇ´ı k podobny´m u´cˇelu˚m, take´ doka´zˇe vypsat trasu k zadane´mu serveru (jednotlive´ smeˇrovacˇe) a navı´c pro kazˇdy´ tento u´sek vypocˇ´ıva´va´ statistiku stejnou jako prˇ´ıkaz ping. Pracuje na principu zpra´v ICMP Echo Request a ICMP Echo Reply stejneˇ jako prˇ´ıkaz ping.
$
vypı´sˇeme na´poveˇdu
pathping -?
pathping www.google.com
spustı´me vy´pis smeˇrovacˇu˚ a vy´pocˇet statistik
Zjisˇteˇnı´ uzlu˚ na cesteˇ mu˚zˇe by´t mı´rneˇ rychlejsˇ´ı nezˇ u tracert, ale pocˇ´ıta´nı´ statistiky naopak zabere vı´ce nezˇ 100 sekund a opeˇt se nedostaneme moc daleko (dokonce mu˚zˇeme „uva´znout“ v sı´ti poskytovatele Internetu). Pokud se na´m zda´ vy´pocˇet prˇ´ılisˇ dlouhy´, program lze prˇedcˇasneˇ ukoncˇit kla´vesovou zkratkou Ctrl+C .
B.4.2
Statistiky v netstatu
Velice silny´ na´stroj pouzˇitelny´ pro analy´zu statistik souvisejı´cı´ch s protokoly rodiny TCP/IP je netstat. Stejneˇ jako jine´ prˇ´ıkazy pro pra´ci se sı´teˇmi vznikl podle podobneˇ pojmenovany´ch na´stroju˚ z Unixu, u prˇ´ıkazu netstat se vsˇak setka´me se zrˇejmeˇ nejveˇtsˇ´ı podobnostı´. Prˇ´ıkaz nejen zachova´va´ unixovou syntaxi (prˇepı´nacˇe se pı´sˇ´ı za pomlcˇku), ale take´ dokonce umozˇnˇuje sdruzˇovat jednopı´smenne´ prˇepı´nacˇe k jedne´ pomlcˇce. Mnozˇina prˇepı´nacˇu˚ je odlisˇna´ v ru˚zny´ch verzı´ch Windows! vypı´sˇe za´kladnı´ statistiku (nevsˇ´ıma´ si aplikacı´, ktere´ jen naslouchajı´, vypisuje pouze TCP spojenı´)
netstat
netstat -a
vypı´sˇe celou statistiku
netstat -a -o netstat -ao
vypı´sˇe celou statistiku, prˇida´ sloupec s PID prˇ´ıslusˇne´ho procesu tote´zˇ (prˇepı´nacˇe mu˚zˇeme sdruzˇovat do jedine´ho rˇeteˇzce)
navı´c mı´sto dome´novy´ch vypisuje IP adresy, tato forma je velmi pouzˇ´ıvana´ a je dobre´ si ji zapamatovat
netstat -ano
vypı´sˇe vsˇechny procesy (na´zvy i PID), ktere´ pra´veˇ komunikujı´ se sı´tı´ (jakkoliv), vy´sledek je smeˇrova´n do zadane´ho souboru
netstat -ab > seznam.log
$
B.4
TESTOVA´NI´ A STATISTIKY
242
za´kladnı´ statistika pro Ethernet (pocˇet odeslany´ch a prˇijaty´ch paketu˚, pocˇet chyb apod. – ty´ka´ se protokolu˚ rodiny TCP/IP)
netstat -e
netstat -es
podrobna´ statistika vsˇech protokolu˚ z rodiny TCP/IP
podrobna´ statistika, prˇepı´nacˇ -p s prˇidany´m parametrem tcp urcˇuje, zˇe chceme pouze statistiku protokolu TCP (mu˚zˇeme pouzˇ´ıt parametr tcp, udp nebo ip)
netstat -sp tcp
vypisuje svu˚j vy´stup opakovaneˇ kazˇde´ dveˇ sekundy (mu˚zˇeme zadat jaky´koliv interval a take´ kombinovat s jiny´mi prˇepı´nacˇi), cˇinnost prˇ´ıkazu lze ukoncˇit jen kla´vesovou zkratkou Ctrl+C
netstat 2
netstat -r
zobrazı´ smeˇrovacı´ tabulku, stejny´ vy´stup jako prˇ´ıkaz route print
Prˇı´klad Po neˇkolika prohle´dnuty´ch stra´nka´ch v internetove´m prohlı´zˇecˇi mu˚zˇe statistika protokolu IP vypadat takto: C:\Windows> netstat -sp ip Statistika protokolu IPv4 Poc ˇet pr ˇijaty ´ch paketu ˚ Pr ˇijato s chybami hlavic ˇek Pr ˇijato s chybami adresy Pr ˇedane ´ datagramy Pr ˇijato s nezna ´my ´m protokolem Zahozene ´ pr ˇijate ´ pakety Doruc ˇene ´ pr ˇijate ´ pakety Poz ˇadavky na vy ´stup Zahozena ´ sme ˇrova ´nı ´ Zahozene ´ vy ´stupnı ´ pakety Nesme ˇrovatelne ´ vy ´stupnı ´ pakety Vyz ˇadova ´no nove ´ sestavenı ´ ´spe U ˇs ˇna ´ nova ´ sestavenı ´ Chybna ´ nova ´ sestavenı ´ ´spe U ˇs ˇne ˇ fragmentovane ´ datagramy Neu ´spe ˇs ˇne ˇ fragmentovane ´ datagramy Vytvor ˇene ´ fragmenty
= = = = = = = = = = = = = = = = =
30736 0 3509 0 0 1078 26369 23914 0 2 0 0 0 0 0 0 0
´ koly U 1. V prˇedchozı´m textu najdeˇte IP adresy verˇejny´ch DNS serveru˚ (jeden od Googlu, jeden od CZ.NIC) a vyzkousˇejte na neˇ prˇ´ıkaz ping. Vsˇimneˇte si cˇasovy´ch u´daju˚ ve vy´pisech. 2. Vsˇimneˇte si rozdı´lu (vcˇetneˇ cˇasove´ho) ve vy´stupech prˇ´ıkazu˚ tracert www.google.com pathping www.google.com
3. Zjisteˇte PID vsˇech procesu˚, ktere´ pra´veˇ komunikujı´ po sı´ti (prˇ´ıpadneˇ naslouchajı´). 4. Vypisˇte statistiku protokolu˚ rodiny TCP/IP. 5. Vypisˇte podrobnou statistiku protokolu IP.
M
SLUZˇBA WMI A PROGRAM WMIC
B.5
243
6. Vypiste podrobnou statistiku protokolu TCP (je pravdeˇpodobne´, zˇe se ve vy´pisu objevı´ i neˇjake´ dome´nove´ adresy), prˇitom nechte zobrazit i sloupec s PID komunikujı´cı´ho procesu (prˇidejte prˇepı´nacˇ -o, naprˇ´ıklad netstat -osp tcp). Zjisteˇte, ktery´m PID (a prˇ´ıslusˇny´m procesu˚m) patrˇ´ı rˇa´dky s nava´zany´m spojenı´m nebo cˇekajı´cı´ (time-wait) – mu˚zˇe to by´t naprˇ´ıklad Skype, mail klient, webovy´ prohlı´zˇecˇ, antivirovy´ program, apod. O ktery´ proces jde u konkre´tnı´ho PID, zjistı´te naprˇ´ıklad ve Spra´vci u´loh (zobrazte si sloupec s PID), Process Exploreru (od Sysinternals.com) nebo ve vy´stupu prˇ´ıkazu tasklist.
B.5
Sluzˇba WMI a program wmic
Program wmic (WMI Console) je dostupny´ od verze Windows XP/Server 2003. Umozˇnˇuje vyuzˇ´ıvat rozhranı´ WMI na Prˇ´ıkazove´m rˇa´dku. pracuje ve dvou rezˇimech – klasicke´m (externı´m) a interaktivnı´m. Prˇi pouzˇitı´ v klasicke´m rezˇimu zada´va´me prˇ´ıkaz zacˇ´ınajı´cı´ na´zvem programu (wmic) na´sledovany´ parametry, do interaktivnı´ho rezˇimu se dostaneme zada´nı´m prˇ´ıkazu wmic bez dalsˇ´ıch parametru˚ (prompt se zmeˇnı´ na wmic:root\cli> a zada´va´me internı´ prˇ´ıkazy). Na´poveˇdu zı´ska´me bud’ v graficke´m rezˇimu, nebo prˇ´ıkazem wmic /?, a nebo v interaktivnı´m rezˇimu te´to konzoly prˇ´ıkazem /?. Jesˇteˇ podrobneˇjsˇ´ı na´poveˇdu zobrazı´me prˇ´ıkazem /?:FULL. Prˇ´ıkaz wmic je velmi komplexnı´. Ma´ tuto syntaxi: WMIC pr ˇepı ´nac ˇe pr ˇedme ˇt sloveso parametry, kde
• prˇepı´nacˇe nastavujı´ obecne´ chova´nı´ prˇ´ıkazu, mohou by´t naprˇ´ıklad /node:poc ˇı ´tac ˇ – prˇ´ıkaz bude proveden na zadane´m pocˇ´ıtacˇi (prˇed na´zvem pocˇ´ıtacˇe nebu-
deme da´vat opacˇna´ lomı´tka) /user:uz ˇivatel – prˇi vyhodnocova´nı´ bude pouzˇit zadany´ uzˇivatel s jeho prˇ´ıstupovy´mi
opra´vneˇnı´mi (budeme dota´za´ni na heslo) /output:soubor – vy´pis bude smeˇrova´n do zadane´ho souboru
• prˇedmeˇt (take´ alias) urcˇuje to, s cˇ´ım chceme manipulovat nebo na co se dotazujeme, na´sleduje zkra´ceny´ seznam (vsˇechny mozˇnosti zjistı´me v na´poveˇdeˇ): 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 urcˇuje pozˇadovanou akci, ktera´ ma´ by´t provedena s prˇedmeˇtem: – LIST – toto sloveso lze pouzˇ´ıt na vsˇechny prˇedmeˇty, zobrazı´ obecnou informaci o prˇedmeˇtu, mu˚zˇeme uprˇesnit, jak podrobne´ informace chceme (full – vsˇechny, brief – za´kladnı´ v tabulce, writeable – ktere´ lze meˇnit, atd.), – GET – zı´ska´nı´ podrobneˇjsˇ´ıch informacı´ o vsˇech nebo vybrany´ch vlastnostech prˇedmeˇtu, – SET – zmeˇna vlastnostı´ prˇedmeˇtu,
$
B.5
SLUZˇBA WMI A PROGRAM WMIC
244
– ASSOC – vra´tı´ instance zadane´ho objektu (tedy s nı´m asociovane´), – CREATE, DELETE – vytvorˇenı´ nove´ instance, odstraneˇnı´ instance nebo trˇ´ıdy, – CALL – spusˇteˇnı´ metody zadane´ trˇ´ıdy WMI. Prˇ´ıkaz v neinteraktivnı´m rezˇimu pouzˇ´ıva´me takto: wmic bios list
vypı´sˇe se informace o BIOSu (u´plna´)
wmic os list brief wmic os list full wmic memorychip get
strucˇna´ informace o operacˇnı´m syste´mu u´plna´ informace o operacˇnı´m syste´mu bude zobrazena tabulka s informacemi o pameˇt’ovy´ch cˇipech
vypı´sˇe vybrane´ informace o pameˇt’ovy´ch cˇipech (oproti prˇedchozı´mu prˇ´ıkazu jen neˇktere´ sloupce)
wmic memorychip get capacity,devicelocator,name,partnumber
prˇ´ıkaz zobrazı´ seznam vsˇech pameˇt’ovy´ch zarˇ´ızenı´ (i vy´meˇnny´ch), a to vlastnosti z vy´cˇtu oddeˇlene´ cˇa´rkou
wmic diskdrive get model,size,interfacetype,mediatype wmic /output:D:\procinfo.txt cpu get
informace o procesoru (v tabulce) budou ulozˇeny
do zadane´ho souboru wmic cpu get > D:\procinfo.txt
tote´zˇ
vypı´sˇe seznam beˇzˇ´ıcı´ch sluzˇeb (pouze ty vlastnosti, ktere´ byly specifikova´ny), vsˇimneˇte si syntaxe podobne´ SQL (ostatneˇ pracujeme s databa´zı´)
wmic service where state=”running” get caption, name
wmic process call create notepad.exe process pro vytvorˇenı´ procesu)
spustı´ zadany´ proces (zavola´ proceduru create trˇ´ıdy
wmic /node:poc ˇı ´tac ˇ process call create notepad.exe tote´zˇ, ale na jine´m pocˇ´ıtacˇi (to prˇ´ıkaz start neumı´), na´zev pocˇ´ıtacˇe se zada´va´ bez u´vodnı´ch opacˇny´ch lomı´tek wmic os call reboot
restart syste´mu
wmic /node:poc ˇı ´tac ˇ os call shutdown
vzda´lene´ vypnutı´ syste´mu
wmic service ”spooler” call startservice
spustı´ zadanou sluzˇbu (Zarˇazova´nı´ tisku)
wmic /node:ucetni process where name=”explorer.exe” call terminate
zadany´ proces bude ukoncˇen, a to na uvedene´m pocˇ´ıtacˇi (vypada´ to, zˇe u´cˇetnı´mu bude ukoncˇeno graficke´ prostrˇedı´, ale tento proces se obvykle po ukoncˇenı´ znovu spustı´, tedy jde vlastneˇ o restart graficke´ho prostrˇedı´) wmic /node:ucetni /user:dadmin process where name=”explorer.exe” call terminate
tote´zˇ jako prˇedchozı´, ale v prˇ´ıkazu na zadane´m pocˇ´ıtacˇi vystupujeme s prˇ´ıstupovy´mi opra´vneˇnı´mi zadane´ho uzˇivatele Vidı´me, zˇe mu˚zˇeme pouzˇ´ıvat i dotazy filtrovane´ podle vlastnostı´ (where) podobneˇ jako v SQL. Pokud se jedna´ o rˇeteˇzcovou hodnotu, musı´me ji uzavrˇ´ıt do uvozovek (naprˇ´ıklad name=”explorer.exe”, ale cˇ´ısla nebo hodnoty true/false do uvozovek neuzavı´ra´me. Prˇı´klad Uka´zˇeme si pra´ci v interaktivnı´m mo´du.
B.5
SLUZˇBA WMI A PROGRAM WMIC
245
spustı´me interaktivnı´ rezˇim, prompt je wmic:root\cli>
wmic os /?
dota´zˇeme se, co lze pouzˇ´ıt na prˇedmeˇt os (operacˇnı´ syste´m)
os list /?
chceme uprˇesnit parametry pro sloveso list
os list brief os list full
zı´ska´me tabulku s neˇkolika za´kladnı´mi informacemi zı´ska´me seznam (uzˇ ne tabulku) s dvojicemi vlastnost=hodnota
tabulka s hodnotami volne´ho mı´sta (ve fyzicke´ pameˇti, v stra´nkovacı´ch souborech, ve virtua´lnı´ pameˇti)
os list free
/output:D:\procinfo.txt cpu get
do souboru se ulozˇ´ı hodneˇ sˇiroka´ tabulka vlastnostı´ pro-
cesoru /output:D:\procinfo.txt cpu list full
tote´zˇ, ale mı´sto sˇiroke´ tabulky ma´me v souboru
seznam polozˇek vlastnost=hodnota cpu get /?
zepta´me se, co se da´ zjistit o procesoru
zı´ska´me u´daj o pocˇtu logicky´ch procesoru˚ (pocˇet jader nebo jeho dvojna´sobek, pokud procesor podporuje hyperthreading)
cpu get NumberOfLogicalProcessors
cpu get AddressWidth,Caption,CurrentClockSpeed,DataWidth,Description,ExtClock
vypı´sˇe se tabulka s vybrany´mi sloupci vypı´sˇe se seznam beˇzˇ´ıcı´ch procesu˚, u kazˇde´ho je prˇ´ıkaz, ktery´m byl spusˇteˇn (vsˇimneˇte si, zˇe v seznamu je i wmiprvse.exe, ktery´ zajisˇt’uje vyhodnocova´nı´ dotazu˚ na WMI)
process get
process list brief
zı´ska´me tabulku procesu˚ s neˇktery´mi informacemi
process where ThreadCount>8 list brief
podobny´ vy´stup, ale vypı´sˇou se pouze procesy,
ktere´ majı´ vı´ce nezˇ 8 vla´ken service get name,state,serviceType
tabulka s na´zvy, stavy a typy sluzˇeb
service where desktopInteract=true get name,state
zı´ska´me seznam interaktivnı´ch slu-
zˇeb (vsˇimneˇte si, zˇe u nebeˇzˇ´ıcı´ch sluzˇeb je PID=0) service where (desktopInteract=true and startMode=”auto”) get name,processid
vy´beˇrova´ krite´ria mu˚zˇeme kombinovat (jako v SQL), ale v tom prˇ´ıpadeˇ je uzavrˇeme do za´vorky service where desktopinteract=true get name,processid,status /every:5
takto zajistı´me, zˇe dotaz bude automaticky opakova´n v intervalu 5 sekund (stisknutı´m neˇktere´ kla´vesy opakova´nı´ prˇerusˇ´ıme) quit
ukoncˇ´ıme interaktivnı´ rezˇim (funguje take´ prˇ´ıkaz exit)
Mechanismus WMI se hodneˇ pouzˇ´ıva´ pra´veˇ ve skriptu, a to typicky v jazyce VBScript, JScript, Perl nebo PowerShell (je trˇeba mı´t nainstalova´n interpret dane´ho jazyka, cozˇ u druhe´ho a zejme´na trˇetı´ho uvedene´ho musı´me zajistit sami). Prˇi psanı´ WMI skriptu bychom meˇli prˇedevsˇ´ım zajistit prˇ´ıslusˇna´ opra´vneˇnı´, zvla´sˇteˇ kdyzˇ je skript spousˇteˇn na vzda´lene´m pocˇ´ıtacˇi v LAN. Jde o opra´vneˇnı´ v modelu DCOM na dane´m pocˇ´ıtacˇi
B.6
FIREWALL VE WINDOWS
246
(WMI je totizˇ postaveno na COM objektech). Proble´m lze zjednodusˇit spousˇteˇnı´m pod neˇktery´m dome´novy´m spra´vcovsky´m u´cˇtem, pak nenı´ trˇeba rˇesˇit opra´vneˇnı´ zvla´sˇt’na kazˇde´m pocˇ´ıtacˇi. S mnoha WMI skripty se mu˚zˇeme sezna´mit naprˇ´ıklad ve zdroji [8] ze seznamu literatury o automatizaci spra´vy a skriptova´nı´. Dalsˇ´ı informace o WMI (vcˇetneˇ WMI skriptu˚) najdeme naprˇ´ı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/ • Trˇ´ıdı´lny´ seria´l o skriptova´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 U Pokud ma´te dostatecˇna´ prˇ´ıstupova´ opra´vneˇnı´, vyzkousˇejte si alesponˇ „vypisovacı´“ prˇ´ıkazy z vy´sˇe uvedene´ho prˇ´ıkladu.
B.6
Firewall ve Windows
Firewall ve Windows XP je pouze jednosmeˇrny´. Ve verzi Vista a Server 2008 se objevil obousmeˇrny´ firewall, ale filtrova´nı´ odchozı´ch paketu˚ je v desktopove´ verzi standardneˇ vypnuto (da´ se ale zapnout), tedy funguje jako jednosmeˇrny´. Nejzna´meˇjsˇ´ı firewally pro Windows jsou naprˇ´ıklad Comodo Firewall, Sunbelt Personal Firewall (drˇ´ıve Kerio), ZoneAlarm, Norton Personal Firewall, Avast!, Avira. Porty pouzˇ´ıvane´ konkre´tnı´ aplikacı´ (prˇ´ıpadneˇ na ktery´ch portech nasloucha´) zjistı´me naprˇ´ıklad v Process Exploreru – v kontextove´m menu procesu zvolı´me Properties a prˇejdeme na kartu TCP/IP (obra´zek Obra´zek B.1: Konfigurace pravidel firewallu ve Windows XP B.2). Prˇı´klad Prohle´dneme si konfiguraci firewallu. K firewallu budeme prˇistupovat ve Windows (zde verze XP SP2, ve vysˇsˇ´ıch je to obdobne´), a to prˇes NetShell.
B.6
FIREWALL VE WINDOWS
247
Obra´zek B.2: Zjisteˇnı´ portu˚ pro aplikaci v Process Exploreru netsh
spustı´me NetShell
firewall
prˇesun do kontextu firewall, na´sledujı´cı´ prˇ´ıkazy prova´dı´me v tomto kontextu
nejdrˇ´ıv si oveˇrˇ´ıme, co vsˇe lze zobrazit
show
show config show state
zobrazı´me konfiguraci firewallu (je celkem obsa´hla´) zobrazı´ se momenta´lnı´ stav firewallu
zobrazı´ se provoznı´ (operacˇnı´) rezˇim (porovnejte, co se rozumı´ stavem z prˇedchozı´ho prˇ´ıkazu a provoznı´m rezˇimem z tohoto prˇ´ıkazu)
show opmode
tı´mto prˇ´ıkazem zjistı´me, co vsˇe lze nastavovat prˇ´ıkazem set (tj. dana´ vlastnost uzˇ je definova´na, ale my ji mu˚zˇeme zmeˇnit)
set ?
nastavı´me provoznı´ mo´d na dostupny´
set opmode enable show allowedprogram
add allowedprogram ? show portopening
zobrazı´ aplikace, ktere´ majı´ povoleno prˇistupovat ven do sı´teˇ zajı´ma´ na´s, jak lze do seznamu prˇidat dalsˇ´ı aplikaci
zjistı´me porty s nastavenou vy´jimkou (otevrˇene´)
ze seznamu zjistı´me, zˇe je v neˇm port, ktery´ by tam nemeˇl by´t, tedy na´s zajı´ma´, jak ho uzavrˇ´ıt
delete portopening ? show service exit
skoncˇ´ıme
vypı´sˇou se sluzˇby prˇistupujı´cı´ na sı´t’
DALSˇI´ PRˇI´KAZY
B.7
B.7
248
Dalsˇı´ prˇı´kazy
Z dalsˇ´ıch uzˇitecˇny´ch prˇ´ıkazu˚ (s mnohy´mi jsme se sezna´mili v Operacˇnı´ch syste´mech): net
prˇ´ıkaz pro za´kladnı´ spra´vu loka´lnı´ sı´teˇ (sdı´lenı´ zdroju˚ v LAN, prˇ´ıpadneˇ nastavenı´ NTP serveru) a dalsˇ´ı (vcˇetneˇ spra´vy uzˇivatelu˚, skupin, za´sad u´cˇtu˚ apod.)
ftp
FTP klient pro prˇena´sˇenı´ souboru˚ po sı´ti, ve Windows take´ najdeme jednoduchou variantu TFTP
ipseccmd
konfigurace protokolu IPSec, na klientech nemusı´ by´t dostupny´
slouzˇ´ı ke spra´veˇ otevrˇeny´ch souboru˚, mu˚zˇeme si nechat vypsat soubory otevrˇene´ na tomto nebo jine´m pocˇ´ıtacˇi v sı´ti, prˇ´ıpadneˇ otevrˇene´ uzavrˇ´ıt, na klientske´ stanici lze pro podobne´ u´cˇely pouzˇ´ıvat take´ varianty prˇ´ıkazu net
openfiles
Na serverovy´ch verzı´ch Windows najdeme mnoho dalsˇ´ıch prˇ´ıkazu˚, ktere´ na klientech nejsou instalova´ny, prˇedevsˇ´ım jde o prˇ´ıkazy pro spra´vu Active Directory (naprˇ. ntdsutil nebo netdom), cˇi pro spra´vu DNS serveru (naprˇ. dnsutil) a dalsˇ´ı. Seznam s komenta´rˇi najdeme v jednom z nı´zˇe uvedeny´ch odkazu˚. U teˇchto prˇ´ıkazu˚ bychom meˇli da´t pozor prˇedevsˇ´ım na to, zˇe jejich syntaxe se mu˚zˇe v ru˚zny´ch verzı´ch syste´mu mı´rneˇ lisˇit. Seznam prˇ´ıkazu˚ pro Prˇ´ıkazovy´ rˇa´dek ve Windows XP (ne vsˇech) najdeme naprˇ´ı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ˇr´ıloha
C
Pra´ce s adresami a sı´teˇmi v Linuxu V te´to prˇ´ıloze jsou popsa´ny a demonstrova´ny prˇ´ıkazy, ktere´ se pouzˇ´ıvajı´ v Linuxu prˇi pra´ci se sı´teˇmi. Podobneˇ jako ve Windows, i tuto prˇ´ılohu mu˚zˇeme bra´t jako inspiraci pro procvicˇova´nı´ a jako prˇedehru k zatı´m neexistujı´cı´m cvicˇenı´m z tohoto prˇedmeˇtu.
C.1
Specializovane´ distribuce
Na routerech nizˇsˇ´ı a strˇednı´ trˇ´ıdy se beˇzˇneˇ setka´va´me s neˇkterou distribucı´ embedded (vestaveˇne´ho) Linuxu (cˇasto to ani nenı´ zna´t, pokud prˇi spra´veˇ vyuzˇ´ıva´me webove´ rozhranı´), protozˇe tento syste´m je velmi dobrˇe vybaven na´stroji pro pra´ci v sı´ti. Obecneˇ – embedded syste´m je syste´m je urcˇen k ozˇivenı´ zarˇ´ızenı´, ktera´ nejsou beˇzˇny´mi univerza´lnı´mi pocˇ´ıtacˇi, naprˇ´ıklad zmı´neˇny´ch sı´t’ovy´ch zarˇ´ızenı´, ale take´ pru˚myslovy´ch pocˇ´ıtacˇu˚, mobilnı´ch telefonu˚, PDA apod. Podobny´ router cˇi bra´nu nebo switch s Linuxem si mu˚zˇeme vyrobit sami. Lze vyuzˇ´ıt starsˇ´ı pocˇ´ıtacˇ (ovsˇem musı´me pocˇ´ıtat s pomeˇrneˇ vysokou spotrˇebou a hlucˇnostı´), nebo mu˚zˇeme porˇ´ıdit maly´ pocˇ´ıtacˇ pru˚myslove´ho typu (dajı´ se koupit naprˇ´ıklad tzv. jednodeskove´ pocˇ´ıtacˇe, ktere´ majı´ vsˇe integrova´no na za´kladnı´ desce a nepocˇ´ıta´ se s rozsˇirˇujı´cı´mi kartami cˇi pameˇt’ovy´mi moduly) nebo prˇ´ımo zarˇ´ızenı´ urcˇene´ k pra´ci v sı´ti. Zby´va´ zvolit vhodnou distribuci Linuxu. Pouzˇitelna´ je vpodstateˇ jaka´koliv (azˇ na ty typicky multimedia´lnı´), typicky Slackware nebo Debian (Debian je vy´hodny´ pro svou univerza´lnost co se ty´cˇe hardwarovy´ch platforem), ale mu˚zˇeme si sta´hnout distribuci specializovanou na vyuzˇitı´ na sı´t’ove´m zarˇ´ızenı´. Sice budeme zrˇejmeˇ „ochuzeni“ o rozbujele´ graficke´ rozhranı´, ale zato budeme mı´t me´neˇ pra´ce s optimalizacı´ distribuce pro nasˇe vyuzˇitı´, distribuce bude mı´t mensˇ´ı na´roky na zdroje (prˇedevsˇ´ım pameˇt’, veˇtsˇinou je spodnı´ hranice 12 nebo 16 MB), instalace by´va´ neˇkdy mozˇna´ i prˇes USB (naprˇ´ıklad IPCop) a pravdeˇpodobneˇji bude podporovat hardwarove´ platformy, ktere´ se na specializovany´ch zarˇ´ızenı´ch pouzˇ´ıvajı´ (za´lezˇ´ı na tom, jaky´ ma´me hardware, i podle toho vybı´ra´me operacˇnı´ syste´m). Prˇ´ıklady vhodny´ch distribucı´:
249
C.1
SPECIALIZOVANE´ DISTRIBUCE
250
• IPCop1 je prˇedprˇipraven pro instalaci na firewallu a internetove´ bra´neˇ (podporuje i VLAN), lze ho spravovat prˇes webove´ rozhranı´ nebo konzolu. Nabı´zı´ pomeˇrneˇ dost sluzˇeb – DHCP klient a server, NTP klient a server, Dynamic DNS, IDS (program Snort), SSH server, HTTP/FTP proxy (program Squid), stavovy´ firewall, IPSec VPN, atd. • Sentry Firewall CD2 je zajı´mavy´ tı´m, zˇe se spousˇtı´ z bootovacı´ho CD (tudı´zˇ je pouzˇitelny´ prˇedevsˇ´ım na zarˇ´ızenı´ch vybaveny´ch optickou mechanikou, trˇeba starsˇ´ıch pocˇ´ıtacˇ´ıch), „promeˇnlivou“ konfiguraci zapisujeme na vy´meˇnne´ me´dium (trˇeba na disketu, kdyzˇ pouzˇijeme starsˇ´ı pocˇ´ıtacˇ, disketa ma´ vy´hodu velmi snadne´ a rychle´ ochrany proti za´pisu). Mu˚zˇe slouzˇit jako firewall, bra´na (software ebtables), IDS (Snort), router (Zebra a IPRoute2), server, podporuje OpenVPN, atd. • Freesco3 (ze slov „Free Cisco“) je volneˇ sˇirˇitelny´ syste´m obdobny´ syste´mu˚m pro zarˇ´ızenı´ Cisco, Nortel, 3-Com apod. Mu˚zˇe plnit roli routeru (azˇ 10 ethernetovy´ch portu˚), firewallu, serveru pro protokoly DHCP, NTP (cˇas), DNS, FTP, HTTP, SSH, RAS, PPPoE, PPtP, apod., protozˇe jde o Linux, tak samozrˇejmeˇ i firewall a NAT. • Pyramid Linux4 je urcˇen prˇedevsˇ´ım pro bezdra´tove´ prˇ´ıstupove´ body nebo mu˚zˇe plnit roli firewallu, je odvozen z Ubuntu. Typickou hardwarovou platformou je bud’ x86 nebo jednodeskova´ zarˇ´ızenı´. • Bering uClibc5 je mimorˇa´dneˇ mala´ distribuce urcˇena´ pro routery s bra´nou. Jejı´ zdrojovy´ ko´d je natolik upraven smeˇrem k minimalizaci, zˇe nenı´ kompatibilnı´ s jiny´mi distribucemi, tedy se prˇi doinstalova´va´nı´ dalsˇ´ıch balı´cˇku˚ musı´me spolehnout na repozita´rˇ te´to distribuce (nicme´neˇ ten je zcela dostatecˇneˇ vybaven). Obsahuje celkem beˇzˇnou sadu softwaru vcˇetneˇ firewallu, IDS, sledova´nı´ sı´teˇ, podpora bezdra´tu, VPN, atd. • Voyage Linux6 je distribuce odvozena´ z Debianu, urcˇena´ pro hardwarove´ platformy zalozˇene´ na x86 (vcˇetneˇ jednodeskovy´ch zarˇ´ızenı´). Pouzˇ´ıva´ se na firewallech, bezdra´tovy´ch access pointech, NAS, prˇ´ıpadneˇ routerech, ma´ take´ vestaveˇnou podporu pro VoIP bra´nu (software Asterisk, ve varianteˇ Voyage ONE). • Embedded Debian (EmDebian)7 je Debian upraveny´ pro pouzˇitı´ na embedded zarˇ´ızenı´ch, odlehcˇeny´ (spı´sˇe osekany´), schopny´ beˇzˇet na zarˇ´ızenı´ch s velmi nı´zkou spotrˇebou. Prˇedpokla´dajı´ se u´pravy syste´mu krˇ´ızˇovou kompilacı´ (cross-compilation). • Embedded Gentoo8 je deriva´t Gentoo, opeˇt se pocˇ´ıta´ s cross-kompilacı´. • QPlus9 je embedded distribuce Linuxu pro ru˚zne´ typy zarˇ´ızenı´ vcˇetneˇ routeru˚. 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
SOUBORY SOUVISEJI´CI´ SE SI´TEˇMI
C.2
251
Pokud se rozhodneme pouzˇ´ıt neˇkterou beˇzˇnou distribuci, meˇli bychom zajistit co nejlepsˇ´ı zabezpecˇenı´ nasˇeho zarˇ´ızenı´. Velmi dobrou volbou je instalace na´stroje Bastille Linux,10 cozˇ nenı´ distribuce, ale sada skriptu˚, ktere´ formou pru˚vodce zjistı´ informace od syste´mu a uzˇivatele (s uzˇivatelem konverzuje formou ota´zek a odpoveˇdı´) a pak na pokyn (se souhlasem uzˇivatele) provede potrˇebna´ bezpecˇnostnı´ nastavenı´. Skripty je mozˇne´ procha´zet postupneˇ a prˇ´ıpadneˇ volby rusˇit cˇi se k nim vracet. Velmi du˚kladny´ popis prˇizpu˚sobenı´ cˇi vylepsˇenı´ (jake´koliv) distribuce Linuxu pro pouzˇitı´ na sı´t’ove´m zarˇ´ızenı´ najdeme prˇedevsˇ´ım ve zdroji [18] ze seznamu literatury. Dalsˇ´ı 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 take´ neˇktery´ch jiny´ch zarˇ´ızenı´ch v sı´ti vcˇetneˇ servisnı´ch notebooku˚ a serveru˚) se setka´va´me s vı´ce nezˇ jednı´m fyzicky´m sı´t’ovy´m rozhranı´m (naprˇ´ıklad vı´ce ethernetovy´ch portu˚), takova´ zarˇ´ızenı´ nazy´va´me multihomed devices. Pozna´mka: Mnohe´ z da´le uvedeny´ch prˇ´ıkazu˚ vyzˇadujı´ vysˇsˇ´ı prˇ´ıstupova´ opra´vneˇnı´. Mu˚zˇe se take´ sta´t, zˇe prˇ´ıkaz bude fungovat i bez vysˇsˇ´ıch prˇ´ıstupovy´ch opra´vneˇnı´, ale jeho vy´stup bude jiny´ (obvykle kratsˇ´ı nebo pra´zdny´), to se ty´ka´ naprˇ´ıklad prˇ´ıkazu˚ skupiny ip neighbour. Proto je lepsˇ´ı alesponˇ „vypisovacı´“ prˇ´ıkazy zkousˇet s vysˇsˇ´ımi opra´vneˇnı´mi.
C.2
P
L
Soubory souvisejı´cı´ se sı´teˇmi
Vybavenost unixovy´ch syste´mu˚ na´stroji pro pra´ci se sı´teˇmi je obecneˇ vysoka´, ovsˇem v kazˇde´m unixove´m syste´mu svy´m zpu˚sobem specificka´. Neˇktere´ firmy distribuujı´cı´ unixove´ syste´my prˇida´vajı´ sve´ vlastnı´ typicke´ na´stroje. Odlisˇnosti jsou take´ v souborech a adresa´rˇ´ıch, ktere´ se sı´teˇmi souvisejı´. Veˇtsˇina konfiguracˇnı´ch skriptu˚ obvykle by´va´ v adresa´rˇi /etc/sysconfig/network a jeho podadresa´rˇ´ıch (prˇ´ıp. /etc/sysconfig/network-scripts), v neˇktery´ch linuxovy´ch distribucı´ch to je adresa´rˇ /etc/rc.d/rc.inet1 (Slackware), /etc/conf.d/net (Gentoo) nebo /etc/network (Debian).
$
Prˇı´klad Prˇedpokla´dejme, zˇe konfigurace sı´teˇ je v adresa´rˇi /etc/sysconfig/network-scripts. Prˇesuneme se do tohoto adresa´rˇe. Meˇl by tam by´t soubor ifcfg-eth0, ve ktere´m je ulozˇena konfigurace prvnı´ho sı´t’ove´ho rozhranı´ (karty) – IP adresa, maska, zpu˚sob zı´ska´nı´ IP adresy (pokud dynamicky, 10
http://bastille-linux.sourceforge.net/
C.2
SOUBORY SOUVISEJI´CI´ SE SI´TEˇMI
252
tak zde IP adresu nenajdeme) apod. Pokud ma´me vı´ce sı´t’ovy´ch rozhranı´, pro kazˇde´ z nich zde bude jeden takovy´ soubor.
V souboru /etc/resolv.conf nastavujeme kromeˇ jine´ho adresu DNS serveru (tj. kdyzˇ nevı´me, kde tuto adresu zadat, podı´va´me se do tohoto souboru). Jde o rˇa´dek (nebo o vı´ce rˇa´dku˚, kdyzˇ chceme zadat i za´lozˇnı´ DNS servery) ve forma´tu nameserver adresa, naprˇ´ıklad nameserver 193.84.192.10
Zadany´ DNS server bude vyuzˇ´ıva´n okamzˇiteˇ po ulozˇenı´ souboru, nenı´ trˇeba restartovat syste´m ani zˇa´dny´ proces. Prˇı´klad Prˇedpokla´dejme, zˇe z pocˇ´ıtacˇe chceme vytvorˇit router. To nenı´ azˇ tak teˇzˇke´, stacˇ´ı mı´t zarˇ´ızenı´ s vı´ce sı´t’ovy´mi rozhranı´mi a prove´st neˇkolik nastavenı´. Jedno z nich je povolenı´ forwardingu (prˇeposı´la´nı´). To se provede mensˇ´ı zmeˇnou v souboru /etc/sysctl.conf: • najdeme rˇa´dek net.ipv4.ip_forward=0 (je mozˇne´, zˇe mı´sto tecˇek budou lomı´tka, pravidla syntaxe umozˇnˇujı´ obojı´) • zmeˇnı´me na net.ipv4.ip_forward=1 • aby zmeˇna zacˇala platit, musı´me bud’ restartovat syste´m a nebo jednodusˇe prˇimeˇt de´mona sysctl, aby znovu nacˇetl sve´ konfiguracˇnı´ soubory (vcˇetneˇ toho, ktery´ jsme pozmeˇnili a samozrˇejmeˇ ulozˇili): sysctl -p
Ovsˇem zapnutı´ forwardingu nestacˇ´ı, je trˇeba na pocˇ´ıtacˇ´ıch v dotycˇny´ch sı´tı´ch (ktere´ router propojuje) nastavit toto zarˇ´ızenı´ jako bra´nu (naprˇ´ıklad pokud ma´ karta eth0 IP adresu 193.84.200.1, u pocˇ´ıtacˇu˚ v sı´ti, do ktere´ je prˇipojena, nastavı´me tuto adresu jako adresu bra´ny, IP adresu karty eth1 zase pouzˇijeme v druhe´ sı´ti, samozrˇejmeˇ vzˇdy tu adresu, ktera´ je v dane´ sı´ti viditelna´). A pak samozrˇejmeˇ musı´me nakonfigurovat firewall a dalsˇ´ı bezpecˇnostnı´ mechanismy. Vsˇimneˇte si, zˇe nenı´ trˇeba restartovat pocˇ´ıtacˇ, trˇebazˇe jsme provedli podstatnou zmeˇnu v nastavenı´ syste´mu.
V adresa´rˇi /etc najdeme hodneˇ uzˇitecˇny´ch souboru˚ a adresa´rˇu˚, jak vı´me, naprˇ´ıklad /etc/networks, /etc/hosts, /etc/ethers. Dynamicke´ (momenta´lnı´) nastavenı´ sı´teˇ obvykle najdeme v podadresa´rˇ´ıch a souborech v syste´mu /proc, naprˇ´ıklad /proc/net/arp. Prˇı´klad Do neˇktery´ch souboru˚ v /proc lze za urcˇity´ch okolnostı´ zapisovat, naprˇ´ıklad prˇ´ıkazem echo 1 > /proc/sys/net/ipv4/ip_forward
zapneme forwardova´nı´ (prˇeposı´la´nı´ mezi sı´teˇmi) na takove´m zarˇ´ızenı´, ktere´ ma´ dveˇ sı´t’ova´ rozhranı´
C.3
STARSˇI´ PRˇI´KAZY PRO PRA´CI S ADRESAMI
253
(trˇeba dveˇ sı´t’ove´ karty) a je tedy prˇipojeno do dvou ru˚zny´ch sı´tı´. Pokud je v tomto souboru hodnota 0, neprˇeposı´la´ se, hodnota 1 znamena´, zˇe se pakety majı´ prˇeposı´lat mezi rozhranı´mi. Toto nastavenı´ vsˇak platı´ jen do restartu pocˇ´ıtacˇe (to platı´ obecneˇ o cˇemkoliv, co zmeˇnı´me v /proc), proto je vhodne´ tento prˇ´ıkaz ulozˇit take´ do neˇktere´ho skriptu, ktery´ se spousˇtı´ prˇi startu syste´mu, naprˇ´ıklad do /etc/rc.d/rc.local, podle konkre´tnı´ distribuce. Zatı´m jsme si uka´zali dveˇ mozˇnosti, jak zapnout forwardova´nı´ (jiny´ zpu˚sob je v prˇedchozı´m prˇ´ıkladu). Rozdı´l mezi nimi je v tom, zˇe za´pis do souboru v souborove´m syste´mu proc platı´ jen do restartu pocˇ´ıtacˇe, zatı´mco zmeˇna v souboru /etc/sysctl.conf je trvala´.
´ koly U Projdeˇte si zde probı´rane´ soubory na umı´steˇnı´ch platny´ch ve vasˇ´ı distribuci, vcˇetneˇ „sı´t’ovy´ch“ cˇa´stı´ souborove´ho syste´mu /proc.
C.3
Starsˇı´ prˇı´kazy pro pra´ci s adresami
Nejdrˇ´ıv se podı´va´me na prˇ´ıkazy, ktere´ se v unixovy´ch syste´mech pouzˇ´ıvajı´ pro pra´ci s adresami jizˇ desı´tky let. V noveˇjsˇ´ıch distribucı´ch Linuxu se vsˇak mı´sto prˇ´ıkazu˚ ifconfig, route a arp doporucˇuje pouzˇ´ıvat novy´ prˇ´ıkaz ip, protozˇe starsˇ´ı prˇ´ıkazy mohou by´t v neˇktery´ch prˇ´ıpadech navza´jem me´neˇ kompatibilnı´. Prˇ´ıkaz ifconfig slouzˇ´ı ke konfiguraci sı´t’ovy´ch rozhranı´ (interfaces) ja´dra (narozdı´l od Windows jsou v Linuxu sı´t’ova´ rozhranı´ soucˇa´stı´ ja´dra). ifconfig
zobrazı´ informaci o vsˇech sı´t’ovy´ch rozhranı´ch
ifconfig eth0
zobrazı´ informaci o sı´t’ove´m rozhranı´ eth0 (to obvykle by´va´ ethernetova´ karta)
„shodı´“ zarˇ´ızenı´ eth0 (zneaktivnı´ tuto kartu), prova´dı´me naprˇ´ıklad tehdy, kdyzˇ chceme tomuto rozhranı´ prˇirˇadit jinou adresu
ifconfig eth0 down ifconfig eth0 up
aktivuje zarˇ´ızenı´ eth0
ifconfig eth0 down hw ether 00:00:00:00:00:02 kromeˇ toho, zˇe zneaktivnı´ zarˇ´ızenı´ eth0, take´ mu prˇirˇadı´ MAC adresu; vnitrˇnı´ prˇ´ıkaz hw ether adresa znamena´, zˇe jde o etherneto-
vou kartu, ktere´ prˇirˇazujeme danou adresu (prˇed podobny´mi zmeˇnami je vzˇdy nutne´ kartu zneaktivnit) nastavı´ IP adresu a masku podsı´teˇ pro eth0, pak je zaktivnı´ (prˇedpokla´da´me, zˇe prˇedtı´m byla tato karta neaktivnı´)
ifconfig eth0 172.19.124.104 netmask 255.255.255.0 up
zapne promiskuitnı´ mo´d (tj. karta prˇijı´ma´/odposloucha´va´ vsˇechny datagramy, nejen ty, ktere´ jsou jı´ adresovane´)
ifconfig eth0 promisc
ifconfig eth0 -promisc
vypne promiskuitnı´ mo´d
$
STARSˇI´ PRˇI´KAZY PRO PRA´CI S ADRESAMI
C.3
254
Tento prˇ´ıkaz ma´ dalsˇ´ı volby, ktery´mi lze naprˇ´ıklad urcˇovat multicast a broadcast adresy, prˇideˇlovat zdroje (I/O pameˇt’, IRQ apod.), nastavovat metriky, atd. Prˇı´klad Prˇ´ıkaz ifconfig na pocˇ´ıtacˇi s jednou sı´t’ovou kartou bude vypadat takto: sarka@notebook:˜$ ifconfig eth0
Zapouzdr ˇenı ´:Ethernet HWadr 00:1D:72:31:0A:A0 inet adr:10.0.0.2 Vs ˇesme ˇr:10.0.0.255 Maska:255.255.255.0 inet6-adr: fe80::21d:72ff:fe31:aa0/64 Rozsah:Linka ˇESME ´NO VS ˇROVE ´_VYSI ´LA ´NI ´ BE ˇZ ˇI ´ MULTICAST MTU:1500 Metrika:1 AKTIVOVA RX packets:561 errors:0 dropped:0 overruns:0 frame:0 TX packets:556 errors:0 dropped:0 overruns:0 carrier:0 kolizı ´:0 de ´lka odchozı ´ fronty:1000 RX bytes:379302 (370.4 KiB) TX bytes:100735 (98.3 KiB) Pr ˇerus ˇenı ´:169
lo
Zapouzdr ˇenı ´:Mı ´stnı ´ smyc ˇka inet adr:127.0.0.1 Maska:255.0.0.0 inet6-adr: ::1/128 Rozsah:Poc ˇı ´tac ˇ ´NO SMYC ˇKA BE ˇˇ AKTIVOVA Z´ I 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 de ´lka odchozı ´ fronty:0 RX bytes:24914 (24.3 KiB) TX bytes:24914 (24.3 KiB)
M
Vy´pis samozrˇejmeˇ mu˚zˇe by´t cely´ v anglicˇtineˇ, naprˇ´ıklad mı´sto de ´lka odchozı ´ fronty bychom ˇESME ´NO VS ˇROVE ´_VYSI ´LA ´NI ´ BE ˇZ ˇI ´ MULTICAST pak nasˇli rˇeteˇzec txqueuelen, nebo mı´sto AKTIVOVA by bylo UP BROADCAST NOTRAILERS RUNNING MULTICAST. Srovnejte s vy´stupem prˇ´ıkazu˚ ip link show a ip addr show dev eth0 v prˇ´ıkladu na straneˇ 257, vsˇechny tyto prˇ´ıkazy byly spusˇteˇny na tomte´zˇ pocˇ´ıtacˇi, ale v jine´ situaci (tj. naprˇ´ıklad nebudou sedeˇt pocˇty RX a TX bytes/packets).
Pro rychle´ odpojenı´ a aktivova´nı´ sı´t’ove´ho rozhranı´ existujı´ take´ zkra´cene´ verze prˇ´ıkazu: ifdown eth0 deaktivace sı´t’ove´ karty ifup eth0 aktivace karty
Pro pra´ci se smeˇrovacı´ tabulkou lze vyuzˇ´ıt prˇ´ıkaz route.
$
zobrazı´ hlavnı´ smeˇrovacı´ tabulku (k jiny´m smeˇrovacı´m tabulka´m se tı´mto prˇ´ıkazem nedostaneme) route -n -A inet prvnı´ parametr zpu˚sobı´ vypisova´nı´ cˇ´ıselny´ch adres mı´sto dome´novy´ch (u neˇktery´ch prˇ´ıkazu˚ take´ ve formeˇ --no-dns, ale veˇtsˇina rozumı´ pouze -n), druhy´ stanovı´, zˇ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 prˇida´me do smeˇrovacı´ tabulky novy´ za´znam (jde o adresu sı´teˇ se zadanou maskou, poslednı´m parametrem je bra´na, na kterou se majı´ posı´lat datagramy urcˇene´ pro danou sı´t’) route add default gw 193.88.50.10 dev eth0 urcˇ´ıme vy´chozı´ bra´nu pro zadane´ sı´t’ove´ rozhranı´ route
MECHANISMUS IPROUTE2 (PRˇI´KAZ IP) – ADRESY, SI´Tˇ, SMEˇROVA´NI´
C.4
255
odstranı´me rˇa´dek smeˇrovacı´ tabulky (obvykle stacˇ´ı zadat jen u´daj o IP adrese, kterou chceme odstranit z tabulky) route del default odstranı´me smeˇrovacı´ informaci o vy´chozı´ bra´neˇ, typicky kdyzˇ chceme nastavit jinou route -Cn zobrazı´ se cache pro smeˇrova´nı´, a to s cˇ´ıselny´mi IP adresami
route del -net 193.90.100.0 netmask 255.255.255.128 gw 193.90.220.3
Mı´sto prˇ´ıkazu route se doporucˇuje pouzˇ´ıvat prˇ´ıkaz ip route. V Linuxu se take´ pouzˇ´ıva´ prˇ´ıkaz arp, a to s podobnou syntaxı´ jako ve Windows: zobrazı´ ARP tabulku, druhy´ prˇepı´nacˇ znamena´, zˇe vsˇechny adresy se zobrazı´ v cˇ´ıselne´m tvaru (mı´sto dome´novy´ch na´zvu˚), ale mu˚zˇeme pouzˇ´ıt samozrˇejmeˇ arp -a (ovsˇem kdyzˇ docha´zı´ k prˇekladu IP adres na dome´nove´, prˇ´ıkaz pracuje pomaleji) arp -n -i eth1 zobrazı´ ARP tabulku zadane´ho sı´t’ove´ho rozhranı´ (to na´sleduje za prˇepı´nacˇem -i) arp -s 123.123.123.123 00:12:34:56:01:08 -i eth1 prˇida´nı´ staticke´ho za´znamu do ARP tabulky pro kartu eth1 arp -d 123.123.123.123 -i eth1 odebra´nı´ za´znamu z ARP tabulky pro kartu eth1 arp -a -n
$
Je mozˇne´, zˇe v neˇktery´ch distribucı´ch nebude v nejnoveˇjsˇ´ıch verzı´ch neˇktery´ ze starsˇ´ıch prˇ´ıkazu˚ fungovat. Z toho a z dalsˇ´ıch du˚vodu˚ je lepsˇ´ı zvyknout si na prˇ´ıkaz ip. ´ koly U 1. Zjisteˇte, jaka´ sı´t’ova´ rozhranı´ na pocˇ´ıtacˇi ma´te. Zjisteˇte prˇ´ıslusˇne´ MAC adresy a prˇideˇlene´ IP adresy. Pokuste se neˇktere´ sı´t’ove´ zarˇ´ızenı´ deaktivovat a pak znovu aktivovat (ne loopback!), pokud zı´ska´va´te IP adresu od DHCP serveru, srovnejte adresy prˇed deaktivacı´ a po aktivaci. 2. Zjisteˇte, zda ma´te prˇideˇlenu take´ IPv6 adresu. Pokud ano: doplnˇte vynechane´ nulove´ sekce adresy (stacˇ´ı jedna nula na sekci) a oddeˇlte prefix od klientske´ cˇa´sti adresy. Byla klientska´ cˇa´st zı´ska´na autokonfiguracı´? (tj. srovnejte s MAC adresou, zda odpovı´da´ EUI-64, viz stranu 34) 3. Zobrazte hlavnı´ smeˇrovacı´ tabulku tak, aby se IP adresy neprˇekla´daly na dome´nove´. Srovnejte s vy´pisem obsahujı´cı´m dome´nove´ adresy. Zjisteˇte, jakou IP adresu ma´ vy´chozı´ bra´na v hlavnı´ tabulce. Zobrazte smeˇrovacı´ cache (opeˇt s IP adresami mı´sto dome´novy´ch). 4. Zobrazte ARP tabulku (opeˇt tak, aby se IP adresy neprˇekla´daly na dome´nove´, srovnejte s vy´pisem s dome´novy´mi adresami).
C.4
Mechanismus iproute2 (prˇı´kaz ip) – adresy, sı´t’, smeˇrova´nı´
Ve vsˇech noveˇjsˇ´ıch distribucı´ch se setka´me s jesˇteˇ komplexnı´m prˇ´ıkazem ip, ktery´ je soucˇa´stı´ balı´cˇku iproute2. Tento prˇ´ıkaz byl zarˇazen jako na´hrada prˇ´ıkazu˚ ifconfig, route a arp (pro u´plnost jsme se sezna´mili i s nimi), v soucˇasne´ dobeˇ se mı´sto teˇchto trˇ´ı doporucˇuje pouzˇ´ıvat spı´sˇe prˇ´ıkaz ip. Jeho konfiguracˇnı´ soubory najdeme v /etc/iproute2. Ma´ specificke´ vnitrˇnı´ prˇ´ıkazy, postupneˇ probereme nejdu˚lezˇiteˇjsˇ´ı varianty.
$
C.4
C.4.1
MECHANISMUS IPROUTE2 (PRˇI´KAZ IP) – ADRESY, SI´Tˇ, SMEˇROVA´NI´
256
Konfigurace sı´t’ove´ho rozhranı´ a adres
Nejdrˇ´ıv se podı´va´me na formu prˇ´ıkazu ip pro pra´ci se sı´t’ovy´mi rozhranı´mi a IP adresami. pracujeme na vrstveˇ L2 (linkove´) ISO/OSI modelu, vpodstateˇ i L1, tedy pracujeme s MAC adresami a sı´t’ovy´m rozhranı´m (naprˇ´ıklad mu˚zˇeme kartu odpojit cˇi prˇipojit)
ip link ...
$
ip link show zobrazı´ stav spojenı´ (tj. stav sı´t’ove´ho rozhranı´), mı´sto show je mozˇne´ vsˇude pouzˇ´ıvat list nebo ls, na multihomed zarˇ´ızenı´ch mu˚zˇe by´t vy´pis velmi dlouhy´; narozdı´l od ifconfig se vy´pı´sˇou i ta sı´t’ova´ rozhranı´, ktera´ z neˇjake´ho du˚vodu nelze rˇa´dneˇ
aktivovat zadali jsme na´zev rozhranı´ (tj. nebudou se vypisovat informace pro vsˇechna, pokud jich je vı´ce), a navı´c parametr -s znamena´ podrobneˇjsˇ´ı vy´pis link set dev eth0 up aktivuje rozhranı´ eth0 link set dev eth0 down deaktivuje rozhranı´ eth0 link set dev eth0 mtu 1500 zmeˇnı´ hodnotu MTU na 1500 oktetu˚ (Maximum transmission unit, maxima´lnı´ velikosti IP datagramu, kterou je mozˇne´ prˇijmout a odeslat) link set dev eth0 address 02:00:00:00:11:22 zmeˇnı´me MAC adresu sı´t’ove´ karty eth0, vsˇimneˇte si prvnı´ho oktetu; pozor, zmeˇna MAC nemusı´ neˇkdy dopadnout dobrˇe, jde o potencia´lneˇ nebezpecˇnou operaci
ip -s link show eth0 ip ip ip ip
ip addr ... nebo a)
pracujeme na vrstveˇ L3 (sı´t’ove´), tedy s IP adresami (mı´sto addr lze pouzˇ´ıt address
takto zjistı´me IP adresu a souvisejı´cı´ informace, prˇ´ıpadneˇ mu˚zˇeme prˇidat i na´zev karty, ktera´ na´s zajı´ma´, jedna karta mu˚zˇe mı´t i vı´ce nezˇ jednu IPv6 adresu (jednu prima´rnı´ a ostatnı´ sekunda´rnı´) address show tote´zˇ, take´ funguje ip a show nebo ip a ls addr show dev eth0 primary zjistı´me prima´rnı´ adresu zarˇ´ızenı´ eth0 addr add 193.90.220.42/25 brd + dev eth0 nastavı´me IP adresu pro rozhranı´ 11 eth0, broadcast adresu necha´me nastavit na vy´chozı´ (pokud chceme urcˇit jinou nezˇ vy´chozı´, mı´sto symbolu + napı´sˇeme novou broadcast adresu), vsˇimneˇte si, zˇe mı´sto masky zada´va´me de´lku prefixu hned u adresy addr del 193.90.220.42/25 brd + dev eth0 odebereme karteˇ eth0 zadanou adresu; pozor – pokud se jedna´ o prima´rnı´ adresu, odeberou se i vsˇechny sekunda´rnı´ addr flush dev eth0 procˇisˇteˇnı´ (flush, odstraneˇnı´) vsˇech adres na dane´m rozhranı´, zu˚stane pouze IPv6 adresa zı´skana´ autokonfiguracı´ (tu nema´ smysl odstranˇovat, je odvozena z MAC adresy), vnitrˇnı´mu prˇ´ıkazu flush se spı´sˇe vyhy´ba´me (mu˚zˇeme omylem odstranit adresy, ktere´ by meˇly zu˚stat)
ip addr show
ip ip ip
ip ip
11
Jedno rozhranı´ (sı´t’ova´ karta) mu˚zˇe mı´t vı´ce IPv6 adres (vpodstateˇ i IPv4 adres, od ja´dra Linuxu v. 2.2). Jestlizˇe dane´ rozhranı´ (sı´t’ova´ karta) jizˇ ma´ IPv6 adresu prˇirˇazenu, dalsˇ´ı bude sekunda´rnı´. Pokud chceme jednomu sı´t’ove´mu rozhranı´ prˇirˇadit vı´ce IPv6 adres, meˇli bychom kazˇde´ z teˇchto adres prˇirˇadit label (popisek) – viz man ip, prˇedevsˇ´ım z du˚vodu jejich rozlisˇenı´ v prˇ´ıkazech, naprˇ´ıklad ifconfig s tı´m mı´va´ proble´my. Takte´zˇ lze IP adresy jednoho rozhranı´ rozlisˇit pomocı´ aliasu˚, cozˇ je rozlisˇenı´ na nizˇsˇ´ı u´rovni nezˇ v prˇ´ıpadeˇ labelu˚, naprˇ´ıklad prˇ´ıkazem ifconfig eth1:0 193.84.190.99 netmask 255.255.128.0 up vytvorˇ´ıme alias eth1:0 k druhe´ karteˇ (eth1) s vlastnı´ IP adresou, ktery´ lze take´ deaktivovat bez ovlivneˇnı´ rozhranı´ eth1.
$
C.4
MECHANISMUS IPROUTE2 (PRˇI´KAZ IP) – ADRESY, SI´Tˇ, SMEˇROVA´NI´
257
prˇed vnitrˇnı´m prˇ´ıkazem je pouzˇit parametr urcˇujı´cı´, zˇe se bude pracovat pouze s IPv6 adresami (mı´sto -f inet6 je mozˇne´ napsat zkra´ceneˇ -6), provede se odstraneˇnı´ adres IPv6 zı´skany´ch dynamicky (tj. kromeˇ adresy zı´skane´ autokonfiguracı´), pokud chceme prove´st tote´zˇ pro IPv4 adresy, napı´sˇ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
Prˇı´klad Podı´va´me se na vy´stupy neˇkolika prˇ´ıkazu˚: sarka@notebook:˜$ ip link show 1: lo:
mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:1d:72:31:0a:a0 brd ff:ff:ff:ff:ff:ff 3: sit0: mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0
M
sarka@notebook:˜$ ip -s link show 1: lo: 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: 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: 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
Vsˇimneˇte si, zˇe v ostry´ch za´vorka´ch za na´zvem rozhranı´ jsou prˇ´ıznaky rozhranı´ (naprˇ´ıklad zda jde o loopback, jestli je aktivnı´, povolenı´ broadcastu, apod.). sarka@notebook:˜$ ip addr show 1: lo: 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: 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: mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0
M
C.4
MECHANISMUS IPROUTE2 (PRˇI´KAZ IP) – ADRESY, SI´Tˇ, SMEˇROVA´NI´
258
Kdyby na´s zajı´malo pouze zarˇ´ızenı´ eth0, napsali bychom ip addr show dev eth0
´ koly U 1. Vypisˇte u´daje o sve´m sı´t’ove´m rozhranı´, a pak je vypisˇte vcˇetneˇ statistiky (podrobneˇjsˇ´ı informace). Srovnejte oba vy´pisy. Urcˇete, kolik ma´te sı´t’ovy´ch rozhranı´ (na koncove´ stanici to odpovı´da´ pocˇtu sı´t’ovy´ch karet plus prˇ´ıpadny´ch virtua´lnı´ch rozhranı´), jakou ma´te velikost MTU, jake´ ma´te MAC adresy, prˇ´ıp. jaka´ je broadcast MAC adresa, jaky´ je provoz na vstupu/vy´stupu rozhranı´. 2. Zjisteˇte IP adresy (IPv4 i IPv6) na svy´ch sı´t’ovy´ch rozhranı´ch. Ma´te jen prima´rnı´ adresu, nebo i neˇjake´ sekunda´rnı´? 3. Pokud je na rozhranı´ definova´no vı´ce adres, jak zobrazı´te pouze tu prima´rnı´? Co se stane, kdyzˇ sı´t’ove´mu rozhranı´ s vı´ce IP adresami odebereme prima´rnı´/sekunda´rnı´ adresu?
C.4.2
Smeˇrova´nı´ a filtrova´nı´
Prˇ´ıkaz ip se pouzˇ´ıva´ prˇi pra´ci se smeˇrovacı´mi tabulkami a prˇi definova´nı´ pravidel pro filtrova´nı´ obdobneˇ jako u firewallu. V Linuxu neexistuje pouze jedna smeˇrovacı´ tabulka. Ve vy´chozı´m nastavenı´ ma´me vzˇdy alesponˇ hlavnı´ (main) smeˇrovacı´ tabulku, ktera´ je za´rovenˇ vy´chozı´ (default), a loka´lnı´ tabulku (v loka´lnı´ smeˇrovacı´ tabulce najdeme prˇedevsˇ´ım loopback (mı´stnı´ cesty) a smeˇrova´nı´ broadcastu˚ a multicastu˚), dalsˇ´ı tabulky si mu˚zˇeme dle potrˇeb vytvorˇit. Kazˇda´ tabulka je identifikova´na svy´m jme´nem a cˇ´ıslem, v prˇ´ıkazech mu˚zˇeme pouzˇ´ıvat cokoliv z toho. Co se ty´cˇe cˇ´ısel smeˇrovacı´ch tabulek, tak u noveˇ vytvorˇeny´ch mu˚zˇeme pouzˇ´ıt cˇ´ısla z intervalu 1 azˇ 252, cˇ´ısla prˇeddefinovany´ch tabulek vidı´me ve vy´pisu nı´zˇe. Zatı´mco prˇ´ıkaz route, se ktery´m jsme se jizˇ drˇ´ıve sezna´mili, dovoluje prˇistupovat pouze k hlavnı´ tabulce, prˇ´ıkaz ip umozˇnˇuje pracovat s jakoukoliv tabulkou. Seznam smeˇrovacı´ch tabulek je ulozˇen v souboru /etc/iproute2/rt_tables. Vy´chozı´m obsahem je 255 254 253 0
local main default unspec
(plus rˇa´dky s komenta´rˇi, komenta´rˇovy´ symbol je #). Novou smeˇrovacı´ tabulku vytvorˇ´ıme jednodusˇe prˇida´nı´m nove´ho rˇa´dku do tohoto souboru (dalsˇ´ı informace najdeme u prˇ´ıkazu ip rule od strany 260). Obvykle soubor needitujeme prˇ´ımo, ale pouzˇijeme prˇesmeˇrova´nı´ s prˇida´nı´m na konec:
M
C.4
MECHANISMUS IPROUTE2 (PRˇI´KAZ IP) – ADRESY, SI´Tˇ, SMEˇROVA´NI´
259
echo c ˇı ´slo na ´zev >> /etc/iproute2/rt_tables
naprˇ´ıklad echo 15 novatab >> /etc/iproute2/rt_tables
Vsˇimneˇte si, zˇe prˇi prˇesmeˇrova´nı´ jsme pouzˇili dvojitou „sˇipku“, protozˇe nechceme prˇepsat pu˚vodnı´ obsah (na to pozor!), ale prˇidat novy´ za´znam na konec souboru. Prˇ´ıkazy: ip route ...
pracujeme se smeˇrovacı´ tabulkou, takte´zˇ na vrstveˇ L3 (ale nad protokolem IP)
ip route show zobrazı´ hlavnı´ smeˇrovacı´ tabulku (pozor, ne vsˇechny) ip route show table local zobrazı´ loka´lnı´ smeˇrovacı´ tabulku ip route show table 12 zobrazı´ smeˇrovacı´ tabulku cˇ´ıslo 12 (na tabulku se odkazujeme
jme´nem nebo cˇ´ıslem) zobrazı´ vyrovna´vacı´ pameˇt’ smeˇrova´nı´; velmi dlouhy´ vy´stup, je dobre´ prˇidat jesˇteˇ IP adresu, ktera´ na´s zajı´ma´, a nebo vy´stup neˇjak filtrovat (trˇeba grepem) ip -s route show cache 193.90.102.36 zadali jsme IP adresu, ktera´ na´s jako cı´l zajı´ma´, navı´c prˇepı´nacˇem -s vyzˇadujeme podrobneˇjsˇ´ı vy´stup (tj. vlastneˇ statistiku smeˇrova´nı´ na danou adresu) ip route add default via 193.90.220.1 nastavenı´ vy´chozı´ bra´ny pro vsˇechny cı´le, ktere´ ve smeˇrovacı´ tabulce nejsou prˇ´ımo uvedeny ip route add 193.90.100.0/25 via 193.90.220.3 prˇida´nı´ nove´ho (staticke´ho) rˇa´dku do smeˇrovacı´ tabulky (zada´va´me adresu sı´teˇ s prefixem a da´le adresu zarˇ´ızenı´, prˇes ktere´ se k prvnı´ zadane´ adrese da´ dostat)
ip route show cache
ip route add 193.90.100.0/25 via 193.90.220.3 table administrativa za´znam jsme prˇidali do zadane´ smeˇrovacı´ tabulky administrativa, nikoliv do hlavnı´
smeˇrovacı´ tabulky ip route delete 193.90.100.0/25
odstraneˇnı´ rˇa´dku tabulky (prˇ´ıp. lze opeˇt zadat ta-
bulku) takto zaka´zˇeme smeˇrova´nı´ na zadanou adresu, tj. defacto tuto adresu zneprˇ´ıstupnı´me ze zarˇ´ızenı´ s touto tabulkou (pouzˇ´ıvajı´ naprˇ´ıklad zameˇstnavatele´ k zamezenı´ prˇ´ıstupu z dane´ho pocˇ´ıtacˇe/smeˇrovacˇe k urcˇity´m oblastem), zadana´ podsı´t’cˇi uzel je ohla´sˇen(a) jako „no route to host“ (ICMP zpra´va) ip route add prohibit 193.221.88.0/28 from 193.90.102.29 podobneˇ jako prˇedchozı´, ale zablokovali jsme prˇ´ıstup pouze z jednoho (zadane´ho) uzlu, z jiny´ch uzlu˚ bude smeˇrova´nı´ fungovat (klı´cˇove´ slovo from pouzˇijeme typicky na smeˇrovacˇi s Linuxem, na koncove´ stanici nema´ moc smysl) ip route add blackhole 69.63.189.11 pokud neˇkdo z loka´lnı´ sı´teˇ odesˇle paket na tuto adresu (mimochodem, je to jedna z IP adres serveru˚ Facebooku), paket bude zahozen a dotycˇny´ nebude informova´n ip route add unreachable 69.63.189.11 podobneˇ jako prˇedchozı´, ale odesı´latel je informova´n o tom, zˇe paket nedorazil, ICMP zpra´vou „ICMP unreachable“; router tedy mu˚zˇe paket „za´meˇrneˇ“ zahodit trˇemi ru˚zny´mi zpu˚soby (prohibit, blackhole, unreachable). ip route add prohibit 193.221.88.0/28
$
C.4
MECHANISMUS IPROUTE2 (PRˇI´KAZ IP) – ADRESY, SI´Tˇ, SMEˇROVA´NI´
260
stanovı´ NAT prˇeklad pro prˇ´ıchozı´ pakety (prˇicha´zejı´cı´ do LAN): kdyzˇ tento router dostane paket s prvnı´ („virtua´lnı´ “) adresou jako cı´lovou, prˇepı´sˇe ji na druhou uvedenou (skutecˇnou v mı´stnı´ sı´ti) a posˇle da´l
ip route add nat 192.205.120.56 via 193.90.102.29
Prˇı´klad Uka´zˇeme si rozdı´l mezi hlavnı´ a loka´lnı´ smeˇrovacı´ tabulkou na klientske´ 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 meˇli prˇedevsˇ´ım vsˇimnout rˇa´dku zacˇ´ınajı´cı´ho default, to je smeˇrova´nı´ na bra´nu loka´lnı´ sı´teˇ.
Smeˇrova´nı´ lze spojit s filtrova´nı´m cˇi podrobneˇjsˇ´ım rˇ´ızenı´m smeˇrova´nı´ podle zadany´ch pravidel (politik), cˇemuzˇ rˇ´ıka´me Advanced Routing (pokrocˇile´ smeˇrova´nı´). Zatı´mco prˇ´ıkaz ip route pracuje pouze s adresami, pomocı´ ip rule lze smeˇrova´nı´ ovlivnit take´ obsahem jiny´ch polı´ IP datagramu (smeˇrova´nı´ podle za´sad), takto lze implementovat i mechanismus NAT. ip rule ...
pracujeme s pravidly (politikami, za´sadami) pro smeˇrova´nı´
ip rule show
vy´pis pravidel (vlastneˇ za´sad) pro smeˇrova´nı´, jsou tam minima´lneˇ tyto
rˇa´dky: 0: 32766: 32767:
from all lookup local from all lookup main from all lookup default
P $
M
(prˇ´ıpadneˇ mı´sto default mu˚zˇe by´t prˇ´ımo cˇ´ıslo vy´chozı´ smeˇrovacı´ tabulky 253), vy´chozı´ hodnoty pouze odkazujı´ na loka´lnı´, hlavnı´ a vy´chozı´ smeˇrovacı´ tabulku, cˇ´ıslo na zacˇa´tku je tzv. priorita pravidla, toto cˇ´ıslo by meˇlo by´t jedinecˇne´ pro kazˇde´ pravidlo (cˇ´ım mensˇ´ı cˇ´ıslo, tı´m vysˇsˇ´ı priorita) echo 12 pomocnatab >> /etc/iproute2/rt_tables trochu jsme odbocˇili, tı´mto prˇ´ıkazem jsme vytvorˇili smeˇrovacı´ tabulku s cˇ´ıslem 12 a na´zvem pomocnatab ip rule add from 195.200.94.0/24 table 12 priority 354 vsˇechny pakety s uvedenou adresou jako zdrojovou (resp. adresou ze zadane´ sı´teˇ) budou smeˇrova´ny podle smeˇrovacı´ tabulky 12 vytvorˇene´ v prˇedchozı´m prˇ´ıkazu, hodnota pro prioritu pravidla by meˇla by´t u pravidel unika´tnı´ (pokud zvolı´me jizˇ existujı´cı´ prioritu, ja´dro prˇideˇlı´ nejblizˇsˇ´ı mensˇ´ı volne´ cˇ´ıslo, kdyzˇ prioritu neuvedeme vu˚bec, ja´dro neˇjakou zvolı´ samo), cˇ´ım mensˇ´ı cˇ´ıslo, tı´m vysˇsˇ´ı priorita; pokud ted’ zada´me ip rule show, bude vy´stup na´sledujı´cı´ (srovnejte s prvnı´m vy´pisem pravidel):
M
C.4
MECHANISMUS IPROUTE2 (PRˇI´KAZ IP) – ADRESY, SI´Tˇ, SMEˇROVA´NI´
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
urcˇ´ıme, zˇe pakety ze sı´teˇ s prvnı´ zadanou adresou do sı´teˇ s druhou zadanou adresou budou smeˇrova´ny podle hlavnı´ smeˇrovacı´ tabulky (prˇ´ıpadneˇ mu˚zˇeme zadat, ktera´ tabulka se ma´ pouzˇ´ıt), prioritu pravidla zvolı´ ja´dro (vsˇimneˇte si, ktere´ cˇ´ıslo ja´dro zvolilo: o neˇco nizˇsˇ´ı cˇ´ıslo nezˇ poslednı´ uzˇivatelske´), ve vy´stupu prˇ´ıkazu ip rule show prˇibude tento rˇa´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. odcha´zejı´cı´ ze sı´teˇ): pokud ma´ odejı´t ven ze sı´teˇ paket se zdrojovou adresou prvnı´ uvedenou (skutecˇnou), bude zdrojova´ adresa nastavena na druhou uvedenou („virtua´lnı´ “; vsˇimneˇte si, jaky´ je vztah mezi adresami v podobne´m vy´sˇe uvedene´m prˇ´ıkazu ip route, musı´me mı´t provedeny oba prˇ´ıkazy, aby to fungovalo) ip rule add iif lo table 10 priority 560 takto mu˚zˇeme oddeˇlit smeˇrova´nı´ provozu generovane´ho prˇ´ımo na tomto zarˇ´ızenı´ (lo, loopback, poneˇkud netypicke´ pouzˇitı´ loopbacku) od smeˇrova´nı´ prˇeposı´lane´ho (forwarding) provozu, tedy provoz generovany´ procesy na tomto zarˇ´ızenı´ bude smeˇrova´n podle tabulky 10 (prˇ´ıpadneˇ mu˚zˇeme takto oddeˇlit provoz smeˇrovany´ z konkre´tnı´ho rozhranı´, trˇeba eth2 coby trˇetı´ ethernetove´ sı´t’ove´ karty), do seznamu pravidel prˇiby´va´ novy´ rˇa´dek (prˇedpokla´dejme, zˇe tabulka 10 se nazy´va´ 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 (prˇipomenˇme si, zˇe priorita je vlastneˇ porˇadove´ cˇ´ıslo v tabulce pravidel, pravidlo je takto jednoznacˇneˇ identifikova´no)
ip rule del priority 560
Prˇı´klad Podı´va´me se na mozˇnost vytvorˇenı´ jednoduche´ho one-to-one stateless (bezstavove´ho) NAT, tedy prˇekla´da´me mezi jednou vnitrˇnı´ a jednou vneˇjsˇ´ı IP adresou. Toho lze docı´lit bud’ prˇ´ıkazem ip, nebo mechanismem NetFilter (to, jak vı´me, je modul ja´dra obvykle pouzˇ´ıvany´ jako firewall, jehozˇ obrazem v uzˇivatelske´m rezˇimu je iptables). Pokud pouzˇijeme prˇ´ıkaz ip, bude na´sˇ router odpovı´dat na ARP dotazy na NAT IP adresu, cozˇ mu˚zˇe by´t uzˇitecˇne´ (mechanismus NetFilter tuto vlastnost nema´). Prˇedpokla´dejme, zˇe chceme zprˇ´ıstupnit stroj s IP adresou 195.159.200.28 ven ze sı´teˇ pod adresou 207.189.240.28, mu˚zˇe se naprˇ´ıklad jednat o neˇktery´ server v DMZ: ip route add nat 207.189.240.28 via 195.159.200.28
nejdrˇ´ıv zajistı´me prˇeklad cı´love´
adresy v prˇ´ıchozı´m (inbound) provozu, tedy DNAT ip rule add nat 207.189.240.28 from 195.159.200.28
zajistı´me prˇeklad zdrojove´ adresy
v odchozı´m provozu, tedy SNAT ip route flush cache
za´znamy
aby prˇeklad fungoval, musı´me vypra´zdnit smeˇrovacı´ cache se stary´mi
M
M
C.4
MECHANISMUS IPROUTE2 (PRˇI´KAZ IP) – ADRESY, SI´Tˇ, SMEˇROVA´NI´
ip route show table all
262
ve vy´stupu by meˇl by´t kromeˇ jine´ho rˇa´dek
nat 207.189.240.28 via 195.159.200.28 table local scope host
(rˇa´dku˚ je tam obvykle pomeˇrneˇ hodneˇ, tedy mu˚zˇeme vy´stup profiltrovat naprˇ´ıklad prˇ´ıkazem grep) ip rule show podobneˇ zkontrolujeme seznam pravidel pro smeˇrova´nı´, mezi nimi by meˇl by´t rˇa´dek 32386:
from 195.159.200.28 lookup main map-to 207.189.240.28
(pravdeˇpodobneˇ s jinou hodnotou priority) Tote´zˇ lze prove´st s pouzˇitı´m mechanismu NetFilter za´rovenˇ s urcˇenı´m dalsˇ´ıch u´daju˚ pro prˇeklad (naprˇ´ıklad cˇ´ısla TCP portu), uka´zku ma´me na straneˇ 284.
Prˇı´klad Prˇedpokla´dejme, zˇe ma´me dva ISP (poskytovatele prˇipojenı´ k Internetu) prˇipojene´ k te´muzˇ routeru s Linuxem. Tento prˇ´ıpad nenı´ azˇ tak exoticky´, mu˚zˇeme se s nı´m setkat u neˇktery´ch strˇednı´ch/veˇtsˇ´ıch spolecˇnostı´ (respektive, nemusı´ jı´t ani o vı´ce ru˚zny´ch ISP, stacˇ´ı, kdyzˇ ma´me vı´ce bran). Budeme chtı´t vytvorˇit dveˇ smeˇrovacı´ tabulky, zvla´sˇt’pro kazˇde´ho ISP. Situace je zna´zorneˇna na obra´zku C.1.
mı´stnı´ sı´teˇ
Internet
ISP1 bra´na: 10.1.1.1 eth1 eth0
Router eth2 ISP2 bra´na: 10.32.32.1
Obra´zek C.1: Situace pro vı´ce ISP prˇes jeden router Nejdrˇ´ıv „vytvorˇ´ıme“ dveˇ smeˇrovacı´ tabulky, pro kazˇde´ho ISP zvla´sˇt’: echo 10 ISPprvni >> /etc/iproute2/rt_tables echo 20 ISPdruhy >> /etc/iproute2/rt_tables
Ted’ se musı´me rozhodnout, jak se bude deˇlit provoz mezi jednotlive´ bra´ny (a tedy i mezi jednotliva´ rozhranı´ routeru). Prˇedpokla´dejme, zˇe provoz souvisejı´cı´ s loka´lnı´ sı´tı´ 10.192.0.0/24 pu˚jde prˇes prvnı´ bra´nu (rozhranı´ eth1) a bude smeˇrova´n tabulkou 10, provoz sı´teˇ 10.192.128.0/24 pu˚jde prˇes druhou bra´nu a bude smeˇrova´n tabulkou 20, zbytek pu˚jde take´ prˇes druhou bra´nu a bude smeˇrova´n hlavnı´ smeˇrovacı´ tabulkou. Nakonfigurujeme smeˇrovacı´ tabulku a pravidla: ip route add default via 10.32.32.1 dev eth2
sı´tı´ neuvedeny´ch jinde
nastavı´me vy´chozı´ bra´nu pro pakety ze
M
M
C.4
MECHANISMUS IPROUTE2 (PRˇI´KAZ IP) – ADRESY, SI´Tˇ, SMEˇROVA´NI´
263
do tabulky 10 (ISPprvni) jsme prˇidali novy´ za´znam – pro vsˇe, co bude smeˇrova´no podle te´to tabulky, platı´ vy´chozı´ bra´na 10.1.1.1, ke ktere´ se dostaneme prˇ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
podobneˇ pro dalsˇ´ı tabulku,
urcˇ´ıme bra´nu a port ip rule add from 10.192.0.0/24 table 10
vsˇe, co prˇijde ze sı´teˇ se zadanou adresou, bude
smeˇrova´no podle tabulky 10 ip rule add from 10.192.128.0/24 table 20
podobneˇ pro dalsˇ´ı sı´t’, urcˇujeme smeˇrovacı´
tabulku Provoz lze smeˇrovat i podle jiny´ch krite´riı´.
´ koly U 1. Najdeˇte seznam smeˇrovacı´ch tabulek (vypisˇte soubor /etc/iproute2/rt_tables). Da´le zjisteˇte, jak jsou nastavena prˇ´ıstupova´ opra´vneˇnı´ k tomuto souboru: • ls -la /etc/iproute2/rt_tables vypı´sˇe za´kladnı´ opra´vneˇnı´, • getfacl /etc/iproute2/rt_tables vypı´sˇe seznamy POSIX ACL, ktere´ mu˚zˇeme bra´t jako na´stavbu za´kladnı´ch opra´vneˇnı´ uprˇesnˇujı´cı´ pra´va konkre´tnı´ch uzˇivatelu˚ a skupin (nejen vlastnı´ka a skupiny souboru), • lsattr /etc/iproute2/rt_tables zobrazı´ atributy souboru v dane´m souborove´m syste´mu, • getfattr /etc/iproute2/rt_tables zobrazı´ rozsˇ´ırˇene´ atributy souboru. 2. Vypisˇte hlavnı´ smeˇrovacı´ tabulku a porovnejte s vy´pisem pomocı´ prˇ´ıkazu route (je v prˇedchozı´ sekci). Da´le vypisˇte loka´lnı´ smeˇrovacı´ tabulku, a pokud existujı´ dalsˇ´ı, take´ je vypisˇte. Najdeˇte adresu vy´chozı´ bra´ny. Jak byste ji zmeˇnili? 3. Vypisˇte seznam definovany´ch politik (za´sad, pravidel) pro smeˇrova´nı´. Vsˇimneˇte si, na ktere´ smeˇrovacı´ tabulky tyto za´sady odkazujı´.
C.4.3
Objevova´nı´ sı´teˇ
Protokol IPv4 pouzˇ´ıva´ pro objevova´nı´ sı´teˇ protokol ARP, u IPv6 to je NDP (Neighbour Discovery Protocol), respektive mechanismus NDis (Network Discovery). Pro pra´ci s „okolı´m“ ma´me k dispozici dalsˇ´ı vnitrˇnı´ prˇ´ıkaz prˇ´ıkazu ip. Jednotlive´ uzly sı´teˇ mohou by´t v neˇktere´m z na´sledujı´cı´ch stavu˚ (oznacˇujeme NUD, Neighbour Unreachability Detection): • none – stav „nevyplneˇn“ • noarp – soused je platny´ a dosazˇitelny´, nema´ by´t oveˇrˇova´n ARP dotazy, za´znam ma´ stanovenu dobu platnosti (po te´to dobeˇ je vyrˇazen z ARP cache) • permanent – podobneˇ jako noarp je platny´, dosazˇitelny´ a nema´ by´t oveˇrˇova´n ARP dotazy, nema´ stanovenu dobu platnosti (tj. platnost neomezena´), z tabulky sousedu˚ smı´ by´t odstraneˇn jen administra´torem
C.4
MECHANISMUS IPROUTE2 (PRˇI´KAZ IP) – ADRESY, SI´Tˇ, SMEˇROVA´NI´
264
• reachable – soused je platny´ a dosazˇitelny´, za´znam ma´ stanovenu dobu platnosti (zˇivotnost za´znamu), po uplynutı´ te´to doby bude opeˇtovneˇ dynamicky zjisˇt’ova´n ARP dotazem (tento stav je beˇzˇny´ pro dynamicky zjisˇt’ovane´ sousedy) • incomplete – soused je „zjisˇt’ova´n“, proces objevova´nı´ souseda nenı´ ukoncˇen (obvykle znamena´, zˇe k dane´ IP adrese, na kterou se dotazuje neˇktery´ protokol vysˇsˇ´ı vrstvy, neexistuje zˇa´dny´ za´znam) • stale – soused je povazˇova´n za platne´ho, ale jeho dosazˇitelnost musı´ by´t neusta´le oveˇrˇova´na (po kazˇde´m pouzˇitı´ za´znamu tento za´znam prˇecha´zı´ do stavu delay) • delay – je trˇeba za´znam oveˇrˇit, byl napla´nova´n ARP dotaz na tuto adresu, pokud tento soused bude generovat provoz, stav se meˇnı´ zpeˇt na stale • probe – sousedovi s prˇ´ıznakem delay vyprsˇel limit na odpoveˇd’ (nebo generova´nı´ provozu), ja´dro odesˇle ARP dotaz • failed – ARP dotaz selhal, za´znam nenı´ platny´ Veˇtsˇina sousedu˚ je ve stavu reachable, stale nebo permanent. Pokud je soused ve stavu stale a je prˇipojen, pak v tomto stavu tra´vı´ veˇtsˇinu cˇasu (obcˇas prˇecha´zı´ do delay). Pokud je soused ve stavu reachable, obvykle v neˇm zu˚sta´va´, ale kdyzˇ ho odpojı´me, postupneˇ prˇecha´zı´ mezi stavy reachable–stale–delay–probe–failed, dotaz na danou IP adresu pak koncˇ´ı vy´pisem stavu incomplete. Prˇ´ıkazy: pracujeme s vazbami mezi adresami L2 a L3 (tj. MAC a IP) ve stejne´ sı´ti (tj. se „sousedy“, odtud klı´cˇove´ slovo), v prˇ´ıpadeˇ IPv4 jde o pra´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ı´ momenta´lnı´ stav ARP nebo NDP cache (tabulky) neigh show dev eth0 zobrazı´ seznam sousedu˚ prˇipojeny´ch k rozhranı´ eth0 neigh show to 193.168.200/24 zobrazı´ se info o sousedech ze zadane´ podsı´teˇ -s neigh show to 10.0.0.1 podrobneˇjsˇ´ı statistika souseda se zadanou IP adresou
(zjistı´me navı´c pocˇet uzˇivatelu˚ za´znamu a da´le prˇed kolika sekundami byl za´znam pouzˇit/potvrzen/aktualizova´n) ip neigh show nud permanent zobrazı´ vsˇechny sousedy, jejichzˇ stav je „permanent“, obvykle jde o rucˇneˇ prˇidane´ sousedy ip neigh add 193.168.200.1 lladdr 00:0a:1b:2c:3d:4e dev eth2 nud permanent
prˇidali jsme do ARP tabulky staticky´ za´znam o sousedovi (zada´va´me IP adresu, MAC adresu – Link Layer Addr, rozhranı´, prˇes ktere´ je soused dosazˇitelny´, a pak stav) pokud prˇida´va´me novy´ za´znam, mu˚zˇeme hodnotu nud nastavit na jednu z hodnot noarp, reachable, permanent nebo stale, cˇ´ımzˇ take´ urcˇ´ıme, zda za´znam bude mı´t omezenou platnost a jestli ma´ by´t oveˇrˇova´n ip neigh del 193.168.200.1 dev eth2 odstranili jsme za´znam z tabulky Prˇı´klad Zatı´mco mezilehle´ sı´t’ove´ zarˇ´ızenı´ (router, switch) ma´ sousedu˚ pomeˇrneˇ hodneˇ, koncove´ zarˇ´ızenı´ prˇipojene´ prˇes ethernet (konektor RJ-45) ma´ obvykle jedine´ho souseda – router nebo switch.
$
MECHANISMUS IPROUTE2 (PRˇI´KAZ IP) – ADRESY, SI´Tˇ, SMEˇROVA´NI´
C.4
265
Na koncove´m zarˇ´ızenı´ vypadajı´ vy´pisy na´sledovneˇ: 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
Druhy´ vy´pis obsahuje podrobneˇjsˇ´ı u´daje o sousedovi (cozˇ je router, jehozˇ uvnitrˇ viditelna´ IP adresa je 10.0.0.138). Na rˇa´dku postupneˇ vidı´me IP adresu, rozhranı´, prˇes ktere´ jsme k sousedovi prˇipojeni, da´le pocˇet odkazu˚ na toto prˇipojenı´ a trˇi cˇasove´ u´daje (pocˇet sekund od chvı´le, kdy bylo prˇipojenı´ naposledy pouzˇito/potvrzeno/aktualizova´no).
´ koly U 1. Zobrazte seznam svy´ch sousedu˚ (ARP/NDP cache). Pokud ma´te vı´ce aktivnı´ch sı´t’ovy´ch rozhranı´, pak zvla´sˇt’ pro neˇkolik rozhranı´. Vyzkousˇejte zobrazenı´ se statistikou (podrobneˇjsˇ´ımi informacemi) o dane´m propojenı´. 2. Prˇidejte do ARP cache „virtua´lnı´ho“ souseda, jehozˇ MAC adresa (tj. link layer) je 03:00:01:a5:b6:c7, IP adresa 10.0.0.12, je prˇipojen na rozhranı´ eth0 (i kdyzˇ v rea´lu nenı´), stav spojenı´ permanent. Pak vypisˇte seznam sousedu˚ a zkontrolujte, zda je v seznamu prˇidany´ za´znam. Da´le vypisˇte seznam sousedu˚, jejichzˇ prˇipojenı´ je ve stavu permanent. Potom novy´ za´znam odstranˇte a opeˇt zkontrolujte, jestli za´znam opravdu zmizel. 3. Zopakujte si cely´ postup aktivace sı´t’ove´ho rozhranı´ (zkompletujte prˇ´ıkazy): • • • • •
C.4.4
pokud je rozhranı´ aktivnı´, je trˇeba ho deaktivovat nastavı´me IP adresu (vcˇetneˇ de´lky prefixu) nastavı´me bra´nu nastavı´me adresu DNS serveru aktivujeme rozhranı´
Tunely
Mechanismus iproute2 slouzˇ´ı take´ k vytva´rˇenı´ IP/IP tunelu˚. Lze pouzˇ´ıt pro vytvorˇenı´ VPN tunelu, zapouzdrˇenı´ IPv6 do IPv4 na cesteˇ bez podpory IPv6, vytvorˇenı´ mostu mezi vı´ce sı´t’ovy´mi rozhranı´mi na jednom zarˇ´ızenı´ patrˇ´ıcı´mi do ru˚zny´ch sı´tı´, vytvorˇenı´ vzda´lene´ho mostu, apod. Je mozˇne´ pracovat s neˇkolika ru˚zny´mi typy tunelu˚, ale prˇedneˇ musı´me mı´t v ja´drˇe nacˇten prˇ´ıslusˇny´ modul pro dany´ typ tunelu. Nejbeˇzˇneˇjsˇ´ı jsou • IP-IP tunely (modul ipip) – doka´zˇou zapouzdrˇit jen unicast IP datagramy (tj. tunely typu point-to-point), • GRE tunely (modul ip_gre) – zapouzdrˇujı´ take´ jine´ typy paketu˚, a to spojenı´ unicast i multicast, jsou pomeˇrneˇ hodneˇ pouzˇ´ıva´ny, • SIT tunely (Simple Internet Transition, modul ipv6) – k propojenı´ IPv6 sı´tı´ prˇes IPv4 sı´teˇ.
M M
C.4
MECHANISMUS IPROUTE2 (PRˇI´KAZ IP) – ADRESY, SI´Tˇ, SMEˇROVA´NI´
266
V prˇ´ıkazech pro pra´ci s tunely se typ tunelu projevuje v povinne´m parametru mode (tedy mo´d tunelu), urcˇuje zpu˚sob, jaky´m se ma´ s transportovany´m paketem zacha´zet (prˇedevsˇ´ım jak a do cˇeho se ma´ zapouzdrˇit). Pouzˇ´ıva´me na´sledujı´cı´ prˇ´ıkaz: ip tunnel ...
zabezpecˇeny´ prˇenos, tunelova´nı´
zobrazı´ informaci o vytvorˇene´m tunelu s na´zvem mujtunel, zobrazı´ se obvykle typ (mo´d) tunelu, vzda´lena´ a mı´stnı´ IP adresa (konce tunelu), pak dalsˇ´ı zadane´ (nepovinne´) vlastnosti jako na´zev sı´t’ove´ho rozhranı´, ze ktere´ho tunel vede, hodnota TTL pro pakety jdoucı´ do tunelu, hodnota TOS, apod. (vpodstateˇ se zobrazuje to, co se zadalo prˇi vytvorˇenı´ tunelu) ip -s tunnel show mujtunel kromeˇ vy´sˇe uvedeny´ch informacı´ se zobrazı´ take´ statistika tunelu podobna´ vy´stupu prˇ´ıkazu ip -s link show (jde vlastneˇ o stejny´ typ informace, jen se mı´sto sı´t’ove´ho rozhranı´ ty´ka´ tunelu), viz vy´stup na straneˇ 257
ip tunnel show mujtunel
ip tunnel add mujtunel mode ipip local 194.50.20.42 remote 195.84.152.140 ttl 32 vytvorˇili jsme novy´ tunel typu IP-IP se zadanou mı´stnı´
a vzda´lenou adresou a hodnotou TTL ip tunnel del mujtunel zrusˇili jsme tunel ip tunnel change mujtunel remote 195.35.84.15
zmeˇna nastavenı´ tunelu (zmeˇnili
jsme vzda´lenou adresu) Abychom mohli tyto prˇ´ıkazy pouzˇ´ıvat, musı´me mı´t prˇedneˇ v ja´drˇe nacˇten prˇ´ıslusˇny´ modul. Prˇı´klad Uka´zˇeme si vytvorˇenı´ GRE tunelu, ktery´ je zrˇejmeˇ nejcˇasteˇji pouzˇ´ıva´n (protozˇe doka´zˇe zabalit cokoliv, zvla´da´ i multicast a je vsˇeobecneˇ podporova´n prakticky v cˇemkoliv). Prˇedpokla´dejme, zˇe chceme propojit tunelem dveˇ vzda´lene´ sı´teˇ (patrˇ´ıcı´ stejne´ firmeˇ), ve ktery´ch jsou soukrome´ IP adresy. Rozsahy adres v teˇchto sı´tı´ch by se nemeˇly prˇekry´vat, aby nedocha´zelo k proble´mu˚m prˇi smeˇrova´nı´. Pu˚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 vytvorˇenı´ tunelu:
wan0 (194.84.21.52)
eth0 (10.0.2.1) Router 2 wan0 (194.84.21.54)
Internet
Obra´zek C.2: Vytvorˇenı´ GRE tunelu Situaci vcˇetneˇ adres ma´me zna´zorneˇnu na obra´zku C.2 vlevo. Podle prefixu˚ pozna´me, zˇe rozsahy adres v sı´tı´ch se neprˇekry´vajı´. U routeru˚, prˇes ktere´ se sı´teˇ prˇipojujı´ do Internetu, vidı´me take´ adresu
$
C.4
MECHANISMUS IPROUTE2 (PRˇI´KAZ IP) – ADRESY, SI´Tˇ, SMEˇROVA´NI´
267
viditelnou uvnitrˇ (je z rozsahu adres vnitrˇnı´ sı´teˇ) a adresu viditelnou vneˇ (tu ma´me prˇideˇlenou ISP providerem). Aby bylo mozˇne´ vybudovat funkcˇnı´ tunel, musı´me vsˇechny tyto adresy zna´t (zada´vajı´ se do prˇ´ıkazu˚). Na routeru Router1 zada´me tyto prˇ´ıkazy: modeprobe ip_gre
nacˇteme do ja´dra modul pro podporu GRE tunelu˚
ip tunnel add sit2 mode gre local 194.84.21.52 remote 194.84.21.54 ttl 255
vytvorˇ´ıme tunel, vsˇimneˇte si vysˇsˇ´ı hodnoty TTL (nevı´me, prˇes kolik routeru˚ tunel vede, tedy je lepsˇ´ı pouzˇ´ıt vysˇsˇ´ı hodnotu) ip link set sit2 up
aktivujeme nove´ virtua´lnı´ rozhranı´ (tedy na´sˇ tunel)
prˇideˇlı´me nasˇemu konci tunelu IP adresu, meˇla by by´t viditelna´ v nasˇ´ı sı´ti a nemeˇla by by´t pouzˇita pro jine´ zarˇ´ızenı´ (to si musı´me pohlı´dat, prˇ´ıpadneˇ upravit rozsahy adres)
ip addr add 10.0.1.254 dev sit2
do smeˇrovacı´ tabulky prˇida´me pravidlo pro smeˇrova´nı´ do sı´teˇ za tunelem, blizˇsˇ´ı konec tunelu bude fungovat jako bra´na
ip route add 10.0.2.0/24 dev sit2
Obdobneˇ postupujeme na routeru Router2: modeprobe ip_gre
nacˇteme do ja´dra modul pro podporu GRE tunelu˚
ip tunnel add sit1 mode gre local 194.84.21.54 remote 194.84.21.52 ttl 255
vytvorˇ´ıme tunel ip link set sit1 up
aktivujeme nove´ virtua´lnı´ rozhranı´ (tedy na´sˇ tunel)
ip addr add 10.0.2.254 dev sit1
prˇideˇlı´me nasˇemu konci tunelu IP adresu
ip route add 10.0.1.0/24 dev sit1
do smeˇrovacı´ tabulky prˇida´me pravidlo pro smeˇro-
va´nı´ do sı´teˇ za tunelem Na obra´zku C.2 vpravo je zna´zorneˇna situace po vytvorˇenı´ tunelu. Pak bychom meˇli vyzkousˇet, zda jsou pakety dorucˇova´ny spra´vneˇ, naprˇ´ıklad na prvnı´m routeru vyzkousˇ´ıme ping na druhy´ konec tunelu: ping 10.0.2.154
Pokud nefunguje, je mozˇne´, zˇe pakety byly zahozeny neˇktery´m firewallem. Pokud jsou povoleny ICMP pakety a nema´me zˇa´dne´ restrikce na na´mi vytvorˇene´ virtua´lnı´ rozhranı´, meˇli bychom jesˇteˇ zkontrolovat, zda mohou procha´zet GRE pakety (protokol cˇ´ıslo 47), naprˇ´ıklad v chainu FORWARD bychom protokol 47 povolili takto (podrobnosti najdeme v samostatne´ sekci o firewallu v Linuxu): iptables -A FORWARD -p 47 -j ACCEPT
Da´le mu˚zˇe by´t proble´m v zaka´za´nı´ cˇ´ısla portu pouzˇ´ıvane´ho tunelem, tedy pokud nepomu˚zˇe povolenı´ protokolu 47, mu˚zˇeme vyzkousˇet iptables -A FORWARD -p tcp --dport 1723 -j ACCEPT
Prˇ´ıpadneˇ v jiny´ch tabulka´ch nebo s dalsˇ´ımi parametry, podle momenta´lnı´ho nastavenı´ firewallu.
Meˇli bychom si uveˇdomit, zˇe GRE tunely nejsou sˇifrova´ny.
PRˇEKLAD NA´ZVU˚
C.5
268
Dalsˇ´ı veˇc, kterou bychom meˇli promyslet prˇi vytva´rˇenı´ (jake´hokoliv) tunelu, je hodnota MTU (tj. jak velky´ IP datagram mu˚zˇe projı´t, jeho max. velikost). Pokud paket vstupuje do tunelu, prˇida´vajı´ se dalsˇ´ı hlavicˇky (minima´lneˇ jedna, podle typu tunelu). Pokud ma´me sˇpatneˇ nastavenou velikost MTU, pak je typicky´m projevem nedorucˇova´nı´ paketu˚ prˇes tunel (i kdyzˇ ping funguje norma´lneˇ). Kdyby se vsˇichni administra´torˇi uzlu˚ na cesteˇ rˇ´ıdili doporucˇenı´mi RFC, pak by to proble´m nebyl (kdyzˇ na uzel dojde paket s velikostı´ nad MTU, posˇle uzel zpeˇt ICMP zpra´vu o nutnosti fragmentace, ale pokud jsou neˇkde pakety s ICMP zpra´vami zahazova´ny, zpra´va nedojde a paket nebude znovu odesla´n fragmentovany´). Beˇzˇna´ hodnota MTU je kolem 1500, u tunelu bychom ji meˇli nastavit na hodnotu neˇco nad 1200. Dalsˇ´ı 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 te´to sekci nejsou popsa´ny vsˇechny mozˇnosti mechanismu iproute2. Existujı´ naprˇ´ıklad vnitrˇnı´ prˇ´ıkazy pro monitoring, pra´ci s multicast adresami, multicast smeˇrova´nı´, pra´ce s ru˚zny´mi smeˇrovacı´mi protokoly vcˇetneˇ OSPF, atd. Dalsˇ´ı informace o pouzˇ´ıva´nı´ mechanismu iproute2 (velmi uzˇitecˇne´ tutoria´ly a jine´ na´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 da´le samozrˇejmeˇ man ip pouzˇite´ v Linuxu nebo na Googlu.
C.5
Prˇeklad na´zvu˚
C.5.1
Na´zev pocˇı´tacˇe
Take´ v Linuxu se pracuje s na´zvy pocˇ´ıtacˇu˚. Prˇedneˇ je du˚lezˇite´ veˇdeˇt, jak zjistit na´zev sve´ho pocˇ´ıtacˇe. Pro tyto u´cˇely pouzˇ´ıva´me prˇ´ıkaz hostname a jeho varianty: (bez parametru˚) vypı´sˇe na´zev nasˇeho pocˇ´ıtacˇe; stejny´ u´daj, jak vı´me, zjistı´me take´ v souboru /etc/sysconfig/network nebo prˇ´ıpadneˇ /etc/hostname, pokud existuje
hostname
nastavı´me na´zev nasˇeho pocˇ´ıtacˇe, potrˇebujeme vysˇsˇ´ı prˇ´ıstupova´ opra´vneˇnı´ (tudı´zˇ pouzˇijeme prˇ´ıkaz su nebo sudo, podle toho, ktery´ nasˇe distribuce podporuje)
hostname novynazev
$
C.5
PRˇEKLAD NA´ZVU˚
269
nastavı´me na´zev nasˇeho pocˇ´ıtacˇe, tento na´zev je ulozˇen v zadane´m souboru, takte´zˇ potrˇebujeme vysˇsˇ´ı prˇ´ıstupova´ opra´vneˇnı´
hostname -F soubor
(bez parametru˚) vypı´sˇe na´zev nasˇ´ı NIS dome´ny (pozor, ne DNS; NIS je obdoba Active Directory pro unixove´ syste´my, postupneˇ nahrazova´n ru˚zny´mi implementacemi LDAP), pokud ovsˇem ma´me NIS vytvorˇen
domainname
(bez parametru˚) vypı´sˇe na´zev nasˇ´ı DNS dome´ny (to je to, co v plne´m na´zvu pocˇ´ıtacˇe na´sleduje za prvnı´ tecˇkou), podobneˇ hostname -d
dnsdomainname
C.5.2
Resolver a soubor resolv.conf
Konfigurace resolveru (tj. cˇa´sti mechanismu prˇekladu adres, ktera´ zada´va´ dotazy, je na kazˇde´m klientovi) je tedy v souboru /etc/resolv.conf. V tomto souboru mohou by´t za´znamy neˇkolika typu˚: • nameserver adresa dome´novy´ server, obvykle zadany´ IP adresou, takovy´ch za´znamu˚ mu˚zˇe by´t vı´ce (pak je ale du˚lezˇite´ jejich porˇadı´, jako prvnı´ da´me ten server, na ktery´ se chceme obracet nejcˇasteˇji, tj. obvykle nejblizˇsˇ´ı) • domain dome ´na na´zev dome´ny, za´roven ˇ s na´zvem nasˇeho pocˇ´ıtacˇe tvorˇ´ı plne´ jme´no pocˇ´ıtacˇe, pokud nejsme v zˇa´dne´ sı´t’ove´ dome´neˇ, pak je zde za´znam domain localdomain
• search dome ´na dome ´na ... seznam dome´n, ktere´ jsou prˇi vyhleda´va´nı´ pocˇ´ıtacˇe s urcˇity´m na´zvem prˇida´va´ny pro zkompletova´nı´ plne´ho jme´na pocˇ´ıtacˇe (prˇed odesla´nı´m dotazu DNS serveru), naprˇ´ıklad pokud je v seznamu dome´na fpf.slu.cz, pak na´zev uzlu axpsu lze doplnit na axpsu.fpf.slu.cz • options volby naprˇ´ıklad
volby pro konfiguraci resolveru (uva´deˇjı´ se vsˇechny na jednom rˇa´dku!),
– pocˇet pokusu˚ pro vyrˇ´ızenı´ DNS dotazu na kazˇdy´ zna´my´ DNS server se nastavuje takto: options attempts:3
(vy´chozı´ hodnota je 2, zvy´sˇili jsme pocˇet pokusu˚, zrˇejmeˇ ma´me me´neˇ spolehlive´ spojenı´ k DNS serveru˚m, obvykle nenı´ nutne´ meˇnit) – podporu IPv6 zapneme volbou inet6, – volba no-check-names se pouzˇ´ıva´ prˇedevsˇ´ım tehdy, kdyzˇ ma´me v sı´ti take´ pocˇ´ıtacˇe s nainstalovany´mi Windows; Windows totizˇ cˇasto porusˇujı´ RFC 952, ktere´ zakazuje pouzˇ´ıvat v na´zvech dome´n jake´koliv jine´ znaky nezˇ za´kladnı´ ASCII (pı´smena, cˇ´ıslice, pomlcˇky) a bez pouzˇitı´ te´to volby by uzly s Windows s na´zvem obsahujı´cı´m nedovolene´ na´zvy nebyly dostupne´, – atd. Pokud chceme pouzˇ´ıt vı´ce voleb, musı´me je umı´stit na jeden rˇa´dek, naprˇ´ıklad options attempts:1 ipv6 no-check-names
Za´znamy typu domain a search by teoreticky nemeˇly by´t oba najednou pouzˇity (da´ se rˇ´ıct, zˇe domain je specia´lnı´m prˇ´ıpadem search, ve ktere´m zada´va´me jen jednu dome´nu). Prakticky se vyskytovat mohou, ale prˇi nacˇ´ıta´nı´ konfigurace se bere v u´vahu jen poslednı´ uvedeny´ z teˇchto za´znamu˚.
$
C.5
PRˇEKLAD NA´ZVU˚
270
V Linuxu se beˇzˇneˇ pouzˇ´ıva´ DNS server BIND beˇzˇ´ıcı´ jako de´mon named, jeho popis je vsˇak nad ra´mec teˇchto skript. Postup konfigurace vcˇetneˇ uka´zkovy´ch konfiguracˇnı´ch souboru˚ najdeme naprˇ´ıklad v knize [10] ze seznamu literatury.
C.5.3
Testova´nı´ DNS
Podobneˇ jako ve Windows, i v Linuxu ma´me k dispozici prˇ´ıkaz nslookup, ktery´ lze pouzˇ´ıvat v beˇzˇne´m i interaktivnı´m rezˇimu. Zpu˚sob vyuzˇ´ıva´nı´ je podobny´ jako ve Windows, tedy beˇzˇny´ rezˇim funguje takto: nslookup www.google.com nslookup 209.85.148.99
$
takto zjistı´me IP adresy zadane´ho serveru zjistı´me jme´no prˇislusˇejı´cı´ zadane´ IP adrese
Do interaktivnı´ho rezˇimu se dostaneme jednı´m ze dvou zpu˚sobu˚: • jednodusˇe zada´nı´m prˇ´ıkazu bez parametru˚, • prˇ´ıkaz s jediny´m parametrem – na´zvem DNS serveru, prˇed ktery´ napı´sˇeme pomlcˇku, aby byl odlisˇitelny´ od na´zvu, ktery´ chceme prˇelozˇit. Na´zev DNS serveru zada´va´me tehdy, kdyzˇ vy´chozı´ server neposkytuje autorizovane´ odpoveˇdi a nevı´me jisteˇ, zda v jeho cache jsou spra´vne´ za´znamy. Pokud uzˇ jsme v interaktivnı´m rezˇimu, nastavı´me pouzˇ´ıvany´ DNS server prˇ´ıkazem server adresa (zada´me adresu DNS serveru). Vnitrˇnı´ prˇ´ıkazy vpodstateˇ odpovı´dajı´ tomu, co jsme si ukazovali u prˇ´ıkazu pro Windows, tedy naprˇ´ıklad, prˇeklady podobne´ jako v neinteraktivnı´m rezˇimu, zobrazenı´ parametru˚, urcˇenı´ typu dotazu na DNS server, zobrazenı´ hostitelu˚ (uzlu˚) v dome´neˇ, urcˇenı´ typu zobrazovany´ch hostitelu˚ (vy´chozı´ je typ A) atd. Z interaktivnı´ho rezˇimu se dostaneme prˇ´ıkazem exit. Podobny´ u´cˇel ma´ prˇ´ıkaz dig (zkratka z Domain Information Gropher). Tento na´stroj je u administra´toru˚ oblı´beneˇjsˇ´ı nezˇ nslookup, zvla´sˇteˇ pro u´cˇely testova´nı´ nastavenı´ DNS serveru˚.
$
zı´ska´me vycˇerpa´vajı´cı´ odpoveˇd’ se vsˇemi potrˇebny´mi informacemi, kromeˇ zˇa´dane´ IP adresy (resp. vı´ce adres) naprˇ´ıklad adresu DNS serveru, ktery´ odpoveˇdeˇl, jak dlouho trvala komunikace, ke kazˇde´ adrese informaci o trˇ´ıdeˇ za´znamu (kde je platny´), typ za´znamu, atd.
dig www.root.cz
reverznı´ dotaz, chceme dome´novy´ na´zev k zadane´ IP adrese dig www.root.cz +short kra´tka´ odpoveˇd’ ve stylu nslookup (tj. vypı´sˇe se pouze IP adresa) dig -x 91.213.160.118
chceme vsˇechny typy za´znamu˚ ty´kajı´cı´ se dane´ho serveru (vy´chozı´ jsou za´znamy typu A, tj. IPv4 adresy)
dig google.com ANY
vypı´sˇou se dome´nova´ jme´na DNS serveru˚ v zadane´ dome´neˇ, jejich IP adresy mu˚zˇeme zjistit na´sledny´m dotazem podle vypsany´ch dome´novy´ch jmen
dig seznam.cz NS +short
Prˇı´klad Vyzkousˇ´ıme pra´ci s prˇ´ıkazem dig: sarka@notebook:˜$ dig www.root.cz ; <<>> DiG 9.7.1-P2 <<>> www.root.cz ;; global options: +cmd ;; Got answer:
M
C.5
PRˇEKLAD NA´ZVU˚
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 vy´pisu jsou tyto polozˇky: • v za´hlavı´ vy´pisu jsou informace o tom, jaky´m zpu˚sobem byl prˇ´ıkaz vola´n a kterou ma´me verzi, da´le cˇa´st s pocˇetnı´mi u´daji (cˇ´ısla odpovı´dajı´ pocˇtu˚m za´znamu˚ uvedeny´ch v na´sledujı´cı´ch sekcı´ch), prˇ´ıznaky apod., • sekce „Question section“ obsahujı´cı´ u´daje dotazu (zde dome´nova´ adresa, trˇ´ıda „INternet“, typ za´znamu „A“) • sekce „Answer section“ obsahuje u´daje z odpoveˇdi (v za´hlavı´ ma´me uvedeny dva za´znamy v odpoveˇdi, proto zde budou dva rˇa´dky obsahujı´cı´ dome´novy´ na´zev, TTL, trˇ´ıdu, typ za´znamu a hodnotu za´znamu), • v sekci „Authority section“ ma´me seznam dome´novy´ch adres DNS serveru˚, ktere´ o dotazovane´m na´zvu poskytujı´ autoritativnı´ odpoveˇd’ (pokud zı´skany´m informacı´m nedu˚veˇrˇujeme, mu˚zˇeme se zeptat neˇktere´ho z teˇchto serveru˚), • v na´sledujı´cı´ sekci najdeme IP adresy DNS serveru˚ uvedeny´ch v prˇedchozı´ sekci, • vy´pis koncˇ´ı statisticky´mi informacemi. Ted’ podobneˇ zjistı´me informace o hostiteli mail.google.com, ale zepta´me se jine´ho DNS serveru. Na´zev DNS serveru musı´me uve´st symbolem „zavina´cˇe“, aby bylo zrˇejme´, zˇe se nejedna´ o na´zev, ktery´ ma´ by´t prˇelozˇen, za zavina´cˇem mu˚zˇeme zadat dome´novou nebo IP adresu. Zde se (shodou okolnostı´) dota´zˇeme DNS serveru poskytovane´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
PRˇEKLAD NA´ZVU˚
C.5
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 zrˇejme´, zˇe odpoveˇd’ jsme sice dostali, ale vyzˇa´dali jsme si ji od serveru, ktery´ nenı´ pro dany´ za´znam autoritativnı´ (u´daje bere ze sve´ cache nebo se dotazuje jinde). Da´le vyzkousˇ´ıme zkra´ceny´ vy´pis (pouzˇijeme parametr +short), chceme DNS servery v dome´neˇ seznam.cz. sarka@notebook:˜$ dig seznam.cz NS +short ns.seznam.cz ms.seznam.cz
M
Prˇı´klad Prˇ´ıkaz dig mu˚zˇeme take´ pouzˇ´ıt pro zjisˇteˇnı´ cele´ trasy nasˇ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 nezada´me DNS server, ktere´mu ma´ by´t zasla´n dotaz, prˇ´ıkaz dig pouzˇije DNS servery uvedene´ v souboru /etc/resolv.conf.
C.5.4
Zjisteˇnı´ informacı´ o dome´neˇ
Pokud chceme zjistit informace o urcˇite´ dome´neˇ, pouzˇijeme prˇ´ıkaz whois. Tento prˇ´ıkaz na´m vypı´sˇe vesˇkere´ dostupne´ informace o dome´neˇ – kontakt na vlastnı´ka dome´ny, doba, na kterou je dome´na registrova´na apod. Prˇ´ıkaz se hodı´ naprˇ´ıklad tehdy, kdyzˇ chceme registrovat vlastnı´ dome´nu a chceme si oveˇrˇit, zda uzˇ nenı´ neˇky´m registrova´na, a nebo pokud z neˇktere´ dome´ny prˇicha´zı´ malware a chceme upozornit vlastnı´ka, aby „si udeˇlal porˇa´dek“.
$
zjistı´me u´daje o zadane´ dome´neˇ whois -r koupaliste.cz vy´pis bude odlisˇny´, ale za´kladnı´ informace budou shodne´ (uvedeny´m prˇepı´nacˇem jsme si vyzˇa´dali informace z WHOIS databa´ze RIPE obsahujı´cı´ prˇedevsˇ´ım evropske´ servery) whois koupaliste.cz
V manua´love´ stra´nce prˇ´ıkazu bychom zjistili prˇepı´nacˇe pro dalsˇ´ı mozˇne´ WHOIS databa´ze (pozor, manua´love´ stra´nky ru˚zny´ch unixovy´ch syste´mu˚ se lisˇ´ı v tom, jak moc jsou podrobne´ prˇi komentova´nı´ seznamu prˇepı´nacˇu˚ tohoto prˇ´ıkazu, pak je dobre´ pouzˇ´ıt manua´love´ stra´nky na Internetu). Dalsˇ´ı informace o dome´na´ch v Linuxu: • http://www.madboa.com/geek/dig/ • http://www.brennan.id.au/08-Domain Name System BIND.html ´ koly U 1. Zjisteˇte na´zev sve´ho pocˇ´ıtacˇe. Da´le zjisteˇte, jake´ DNS servery pouzˇ´ıva´te. 2. Zobrazte prˇ´ıkazem dig podrobnosti o serveru seznam.cz, a to vsˇechny typy DNS za´znamu˚ (tj. ANY). Srovnejte s vy´pisem pomocı´ prˇ´ıkazu nslookup. 3. To, zˇe se pta´me jine´ho DNS serveru nezˇ je ten od nasˇeho poskytovatele, nemusı´ znamenat, zˇe dostaneme komplexneˇjsˇ´ı informace. Vyzkousˇejte dotaz na dome´nu root.cz postupneˇ bez zada´nı´ DNS serveru a pak se zada´nı´m neˇktere´ho DNS serveru (naprˇ´ıklad ns.seznam.cz nebo 8.8.4.4). Pokud prˇ´ıkaz zkousˇ´ıte v sı´ti neˇktere´ vysoke´ sˇkoly, kde se ucˇ´ı Linux, tak bude vy´stup od vy´chozı´ho serveru komplexneˇjsˇ´ı. 4. Zjisteˇte u´daje o neˇkolika dome´na´ch druhe´ u´rovneˇ podle vlastnı´ho vy´beˇru (naprˇ´ıklad seznam.cz, slu.cz, apod.).
C.6
C.6
FIREWALL V LINUXU
274
Firewall v Linuxu
V linuxovy´ch ja´drech (od verze 2.4) najdeme firewall NetFilter, cozˇ je obousmeˇrny´ stavovy´ firewall (prova´dı´ funkce SPI).12 NetFilter doka´zˇe filtrovat pakety podle u´daju˚ v hlavicˇka´ch protokolu˚ TCP, UDP, IP, ICMP a take´ dalsˇ´ıch uvedeny´ch v souboru /etc/protocols, je pouzˇitelny´ pro mnoho cˇinnostı´ souvisejı´cı´ch se zpracova´nı´m paketu˚, vcˇetneˇ mechanismu NAT.
P
Jedna´ se o modul ja´dra, ke ktere´mu se neprˇistupuje prˇ´ımo, ale prˇes obsluzˇny´ program iptables.13 Takzˇe pozor – firewall je NetFilter, obsluzˇny´ program beˇzˇ´ıcı´ v uzˇivatelske´m rezˇimu je iptables.
C.6.1
Princip firewallu
Za´kladem je tabulka (table), v kazˇde´ tabulce je neˇkolik rˇeteˇzcu˚ chain (cˇti: [cˇejn]), ktere´ jizˇ obsahujı´ pravidla uplatnˇovana´ na pakety (tato pravidla jsou zrˇeteˇzena´ a na paket se uplatnˇujı´ postupneˇ, dokud se nenajde „pasujı´cı´ “ pravidlo, proto se tomu rˇ´ıka´ chain). Tabulka obvykle urcˇuje, co konkre´tneˇ se ma´ dı´t (naprˇ´ıklad jen filtrova´nı´, nebo prˇeklad adres cˇi zmeˇna neˇktery´ch dalsˇ´ıch u´daju˚ v za´hlavı´ procha´zejı´cı´ho paketu), chain obvykle urcˇuje, kdy se to ma´ dı´t (naprˇ´ıklad na vstupu do sı´teˇ, vy´stupu, prˇi prˇeposı´la´nı´ mezi jiny´mi dveˇma uzly, prˇed smeˇrova´nı´m, po smeˇrova´nı´ apod.).
P
Standardneˇ jsou definova´ny tyto tabulky (v prˇ´ıkazu iptables se prˇed na´zev tabulky da´va´ prˇepı´nacˇ -t): • • • •
filter (vy´chozı´) mangle (pro transformace – upravujeme za´hlavı´, hodnoty TTL, pole TOS/QoS, apod.) nat (pro mechanismus NAT) raw a conntrack jsou pomocne´ mechanismy oznacˇova´nı´ (marking) paketu˚ pro pozdeˇjsˇ´ı zpracova´nı´ a stavove´ho filtru (SPI), obvykle je trˇeba jejich funkcionalitu do ja´dra doplnit (nacˇ´ıst moduly)
V kazˇde´ tabulce je tedy neˇkolik chainu˚ (rˇeteˇzcu˚), a to: • Tabulka filter obsahuje standardneˇ tyto chainy: – chain INPUT se uplatnı´ na pakety, ktere´ do syste´mu prˇicha´zejı´, – chain OUTPUT se uplatnı´ na pakety, ktere´ ze syste´mu odcha´zejı´, – chain FORWARD je urcˇen pro pakety, ktere´ nejsou vytvorˇeny uvnitrˇ syste´mu a ani pro neˇj nejsou urcˇeny, prˇeda´vajı´ se jen mezi rozhranı´mi syste´mu (pru˚chozı´ pakety), typicky v zarˇ´ızenı´, ktere´ slouzˇ´ı jako smeˇrovacˇ, pokud jde paket do chainu FORWARD, nepadne uzˇ do zˇa´dne´ho jine´ho chainu. • Tabulka nat obsahuje standardneˇ tyto chainy: – chain PREROUTING pro prˇ´ıchozı´ pakety, na ktere´ se ma´ pouzˇ´ıt DNAT (tj. ma´ se prˇelozˇit cı´lova´ adresa, a to jesˇteˇ prˇed vlastnı´m smeˇrova´nı´m), 12
Stavove´ firewally doka´zˇou pracovat samozrˇejmeˇ nejen se stavovy´mi, ale i s nestavovy´mi protokoly (jako je naprˇ´ıklad UDP), prˇestozˇe se v neˇktery´ch publikacı´ch mu˚zˇeme docˇ´ıst, zˇe ne. 13 Ve starsˇ´ıch ja´drech, se ktery´mi se (doufejme) uzˇ nesetka´me, se pouzˇ´ıval firewall IPChains se stejnojmenny´m obsluzˇny´m programem (ipchains).
P
C.6
FIREWALL V LINUXU
275
– chain POSTROUTING pro odchozı´ pakety, na ktere´ se ma´ pouzˇ´ıt SNAT (prˇekla´da´ se zdrojova´ adresa, azˇ po smeˇrova´nı´), – chain OUTPUT pro odchozı´ pakety, kdy se ma´ modifikace prove´st jesˇteˇ prˇed dalsˇ´ım zpracova´nı´m. • Tabulka mangle obsahuje standardneˇ chainy pojmenovane´ jako vsˇechny, ktere´ jsou uvedeny u prˇedchozı´ch tabulek (INPUT, OUTPUT, FORWARD, PREROUTING, POSTROUTING) s tı´m rozdı´lem, zˇe v nich najdeme pravidla modifikujı´cı´ i jina´ pole za´hlavı´ nezˇ jen ta adresova´. V tabulka´ch si mu˚zˇeme vytvorˇit dalsˇ´ı chainy (uzˇivatelsky definovane´), nemusı´me zu˚stat jen u standardnı´ch, prˇ´ıpadneˇ nove´ tabulky. Nove´ tabulky se vsˇak cˇasto prˇida´vajı´ jako dalsˇ´ı moduly ja´dra.
raw PREROUTE
nat POSTROUTE (SNAT)
[conntrack PREROUTE]
mangle POSTROUTE
g in
w
r
mangle PREROUTE
ard
nat PREROUTE (DNAT)
smeˇrova´nı´
smeˇrova´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 rˇ ı´ c h o z ı´ p r o v o z
Na obra´zku C.3 je zna´zorneˇna dra´ha paketu mezi jednotlivy´mi tabulkami a chainy. Vsˇimneˇte si, zˇe prˇeposı´lane´ (forwarded) pakety nedorazı´ do zˇa´dne´ho chainu typu INPUT ani OUTPUT.
loka´lnı´ proces Obra´zek C.3: Dra´ha paketu mezi vy´chozı´mi tabulkami a chainy v Netfilteru Program iptables umozˇnˇuje pracovat s chainy (vytvorˇit nebo zrusˇit chain, nastavit vy´chozı´ politiku) a s jejich obsahem (prˇida´vat a odstranˇovat pravidla v chainu, vypsat seznam pravidel). U pravidel v chainu za´lezˇ´ı na porˇadı´. Kazˇde´ pravidlo ma´ sve´ porˇadove´ cˇ´ıslo. Nova´ pravidla mu˚zˇeme do chainu vkla´dat na zacˇa´tek cˇi na konec chainu, a nebo na konkre´tnı´ pozici zadanou porˇadovy´m cˇ´ıslem.
C.6
FIREWALL V LINUXU
C.6.2
276
Za´kladnı´ vnitrˇnı´ prˇı´kazy a parametry pro filtrova´nı´
Ve vnitrˇnı´ch prˇ´ıkazech se pouzˇ´ıvajı´ tzv. targety urcˇujı´cı´ akci, ktera´ se ma´ s urcˇeny´m paketem prove´st. Mu˚zˇeme pouzˇ´ıt tyto targety:
P
• ACCEPT akceptuj, paket ma´ povoleno projı´t, obvykle v tabulce filter, • DROP zahod’ bez odezvy (tiche´ zahozenı´), takte´zˇ v tabulce filter, • REJECT odmı´tni (s odezvou), odesˇle ICMP zpra´vu o odmı´tnutı´ (prˇesneˇji – o nedostupnosti adresy) uzlu, od ktere´ho paket prˇisˇel, pro tabulku filter, • DNAT a SNAT patrˇ´ı k tabulce nat, u´cˇel je zrˇejmy´ – akcı´ je prˇeklad cı´love´ nebo zdrojove´ adresy na jinou IP adresu, pouzˇ´ıva´me prˇi prˇekladu staticky´ch adres, • MASQUERADE take´ patrˇ´ı k tabulce nat chainu POSTROUTING, u odchozı´ch paketu˚ prˇekla´da´ cely´ rozsah vnitrˇnı´ch (zdrojovy´ch) adres na jednu vneˇjsˇ´ı (slouzˇ´ı ke skry´va´nı´ loka´lnı´ch adres), narozdı´l od SNAT by´va´ adres vı´ce a cˇasteˇji se pouzˇ´ıva´ pro PAT (prˇeklad portu˚), pouzˇ´ıva´me pouze tehdy, kdyzˇ potrˇebujeme prˇekla´dat dynamicke´ soukrome´ adresy, • TOS a TTL patrˇ´ı k tabulce mangle, meˇnı´ pole TOS (type of service) a TTL v za´hlavı´ paketu, • MARK a CONNMARK se v tabulce mangle pouzˇ´ıvajı´ pro prˇida´va´nı´ znacˇek do za´hlavı´ paketu˚, • LOG umozˇnˇuje logovat informace ze za´hlavı´ paketu, pouzˇ´ıva´ se obvykle s programem syslog, • RETURN pokud jsme beˇhem vyhodnocova´nı´ pravidel odskocˇili do jine´ho chainu, tento target na´s vra´tı´ zpeˇt, a dalsˇ´ı. Jednotlive´ targety obvykle patrˇ´ı ke konkre´tnı´ tabulce, tedy kdyzˇ prˇida´me do ja´dra dalsˇ´ı modul s tabulkou, prˇidajı´ se i dalsˇ´ı pouzˇitelne´ targety. Za targety se take´ povazˇujı´ uzˇivatelsky definovane´ chainy. Prˇ´ıkaz iptables se pouzˇ´ıva´ s nejme´neˇ jednı´m parametrem (obvykle vı´ce), cozˇ by´va´ urcˇenı´ tabulky, vnitrˇnı´ prˇ´ıkaz nebo parametr. Obvykle (ne vsˇak vzˇdy) zada´va´me tabulku, se kterou chceme v prˇ´ıkazu pracovat, k tomu pouzˇijeme prˇepı´nacˇ -t), naprˇ´ıklad -t nat. Zde se podı´va´me na vnitrˇnı´ prˇ´ıkazy a parametry, ktere´ se pouzˇ´ıvajı´ prˇi za´kladnı´m filtrova´nı´, v dalsˇ´ıch podsekcı´ch projdeme dalsˇ´ı (prˇeklady adres, stavovy´ firewall, znacˇenı´ paketu˚). Obvykle tedy pouzˇ´ıva´me neˇktery´ vnitrˇnı´ prˇ´ıkaz (pozor, velka´ pı´smena) prˇedstavujı´cı´: -P nebo --policy
urcˇuje vy´chozı´ za´sadu (politiku) pro chain, ve ktere´m chceme pracovat (pokud na paket nebude pasovat zˇa´dne´ pravidlo chainu, pouzˇije se tato politika), za prˇepı´nacˇem na´sleduje na´zev chainu a da´le target urcˇujı´cı´ akci, ktera´ se ma´ prove´st, vy´chozı´ politiku lze urcˇit pouze pro prˇeddefinovane´ chainy, nikoliv pro uzˇivatelsky definovane´; naprˇ´ıklad iptables -P INPUT -j DROP,
-L nebo --list iptables iptables iptables iptables
vypisuje seznam vsˇech pravidel v zadane´m chainu, naprˇ´ıklad -L (vy´pis by´va´ dlouhy´ dokonce i na desktopu, vsˇechny tabulky) -t filter -L -n -t filter -L -nv -t filter -L INPUT -n
prvnı´ prˇ´ıkaz vypı´sˇe vsˇechna pravidla tabulky filter, necha´va´ IP adresy (neprˇekla´da´ na dome´nove´, dı´ky poslednı´mu parametru), druhy´ prˇ´ıkaz udeˇla´ tote´zˇ, ale ve verbose („upovı´dane´m“) mo´du, tudı´zˇ se dozvı´me vı´ce, trˇetı´ prˇ´ıkaz vypı´sˇe pouze pravidla v chainu INPUT, -A nebo --append
pravidla
prˇipojı´ nove´ pravidlo na konec chainu, na´sleduje na´zev chainu a specifikace
$
C.6
FIREWALL V LINUXU
277
-I nebo --insert
prˇipojı´ nove´ pravidlo na zacˇa´tek chainu (pokud nezada´me zˇa´dny´ index) nebo na zadany´ index (cˇ´ıslo pravidla mu˚zˇeme napsat za na´zev chainu), dto., prvnı´ index je 1,
-R nebo --replace
prˇepı´sˇe existujı´cı´ pravidlo na dane´m indexu,
odstranı´ pravidlo z chainu, na´sleduje na´zev chainu a bud’ cˇ´ıslo pravidla nebo jeho specifikace,
-D nebo --delete -F nebo --flush
na´sledovane´ na´zvem chainu tento chain vypra´zdnı´ (vymazˇe vsˇechna jeho
pravidla) -Z nebo --zero
vynuluje vsˇechny cˇ´ıtacˇe v tabulce, obvykle se pouzˇ´ıva´ za´rovenˇ s prˇ´ıkazem -L, abychom videˇli stav cˇ´ıtacˇu˚ prˇed jejich vynulova´nı´m, tedy naprˇ´ıklad iptables -t filter -LZ
-N nebo --new-chain, -X nebo --delete-chain
pro vytvorˇenı´ nebo odstraneˇnı´ chainu, na´sle-
duje vzˇdy na´zev chainu, -E nebo --rename-chain
pro prˇejmenova´nı´ chainu, na´sleduje pu˚vodnı´ a novy´ na´zev chainu.
Parametry slouzˇ´ı k uprˇesneˇnı´ prˇ´ıkazu (urcˇujı´, podle cˇeho se pakety majı´ filtrovat), narozdı´l od prˇ´ıkazu˚ jsou pro neˇ urcˇena mala´ pı´smena, pouzˇ´ıva´me prˇedevsˇ´ım: -p nebo --protocol
urcˇ´ı protokol, naprˇ´ıklad -p tcp, negace s vykrˇicˇnı´kem, naprˇ. -p ! udp,
--dport nebo --sport
dovoluje k protokolu podle prˇedchozı´ odra´zˇky prˇidat konkre´tnı´ cˇ´ıslo portu (zdrojove´ho nebo cı´love´ho, take´ se da´ oznacˇit na´zvem prˇ´ıslusˇne´ho aplikacˇnı´ho protokolu), naprˇ´ı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ı´ prˇ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 prˇeposı´la´nı´ paketu˚ se stahovanou posˇtou, aplikacˇnı´ protokol IMAP a POP3) --icmp-type mu˚zˇeme pouzˇ´ıt filtrova´nı´ pro urcˇity´ typ ICMP zpra´vy, naprˇ´ıklad iptables -t filter -A FORWARD -p icmp --icmp-type 8 -j DROP
zahazujeme vsˇechny zpra´vy ICMP Echo Request (nenı´ to zrovna podle RFC, protozˇe tı´m zablokujeme odpoveˇdi na ping) v TCP za´hlavı´ je nastaven prˇ´ıznak SYN (samotny´ bez prˇ´ıznaku ACK), cozˇ znamena´, zˇe zrˇejmeˇ jde o paket, ktery´ navazuje nove´ spojenı´ (ne nutneˇ, take´ je du˚lezˇite´ otestovat stav spojenı´, viz da´le o SPI)
--syn
-s nebo --source nebo --src a -d nebo --destination nebo --dst je zdrojova´ a cı´lova´ adresa, u sı´teˇ pı´sˇeme i de´lku prefixu, naprˇ´ıklad -s 192.89.120.0/24, opeˇt mu˚zˇeme pouzˇ´ıt
vykrˇicˇnı´k pro negova´nı´ (tj. vsˇechny adresy kromeˇ te´to), -i nebo --in-interface
zada´va´ vstupnı´ rozhranı´, pouzˇ´ıva´ se v chainech INPUT, FORWARD a PREROUTING, naprˇ´ıklad -i eth0, mu˚zˇeme take´ zada´vat negaci, naprˇ´ıklad -i ! eth4 znamena´ pakety ze vsˇech sı´t’ovy´ch rozhranı´ kromeˇ eth4,
-o nebo --out-interface
podobneˇ pro vy´stupnı´ rozhranı´, na ktere´ je paket smeˇrova´n (v chainech OUTPUT, FORWARD a POSTROUTING), naprˇ´ıklad iptables -t filter -A OUTPUT -o eth1 -j ACCEPT
$
C.6
FIREWALL V LINUXU
278
vesˇkery´ ochozı´ provoz (neodpovı´dajı´cı´ jiny´m pravidlu˚m) odcha´zejı´cı´ prˇes port eth1 bude povolen Dalsˇ´ı parametry slouzˇ´ı k uprˇesneˇnı´ cˇinnosti, ktera´ se ma´ s paketem prove´st: -j nebo --jump
slouzˇ´ı k zada´nı´ provedenı´ targetu (viz vy´sˇe), ktery´ za tı´mto prˇepı´nacˇem na´sleduje, znamena´ tedy odskok (jump) k provedenı´ targetu, ktery´m mu˚zˇe by´t neˇktera´ akce (ACCEPT, DROP, SNAT apod.), a nebo na´zev uzˇivatelsky definovane´ho chainu, do ktere´ho takto „odskocˇ´ıme“ s tı´m, zˇe se po procha´zenı´ uzˇivatelske´ho chainu mu˚zˇeme vra´tit zpeˇt (tj. odskok se zapamatova´nı´m adresy), naprˇ´ıklad
$
iptables -t filter -A INPUT -p tcp -j tcppakety
(pokud jde o TCP paket, prˇesuneme se do chainu tcppakety; pokud v tom chainu nenajdeme zˇa´dne´ vyhovujı´cı´ pravidlo, vra´tı´me se zpeˇt do chainu INPUT a pokracˇujeme na´sledujı´cı´mi pravidly, uzˇivatelsky´ chain tcppakety byl prˇedem vytvorˇen prˇ´ıkazem -N) -g nebo --goto
je pro uzˇivatelsky definovane´ chainy podobne´ jako -j, s tı´m rozdı´lem, zˇe se prˇed odskokem jinam nezapamatuje adresa momenta´lnı´ho chainu (prˇesneˇji – pokud uzˇ byla prˇedtı´m neˇktera´ adresa zapamatova´na pomocı´ -j, neprˇepı´sˇe se jinou adresou, tudı´zˇ prˇi prˇ´ıpadne´m na´vratu beˇhem vyhodnocova´nı´ jednoho paketu se nevra´tı´me do chainu, ze ktere´ho odcha´zı´me, ale bude prˇeskocˇen), naprˇ´ıklad iptables -t filter -A INPUT -p tcp -g tcppakety
podobneˇ jako prˇedchozı´, ale pokud v uzˇivatelske´m chainu nenalezne vhodne´ pravidlo, uzˇ se do INPUT nevracı´ (ovsˇem v tcppakety mu˚zˇe by´t take´ parametr -j nebo -g smeˇrujı´cı´ vyhodnocova´nı´ paketu jinam). Parametr -j tedy lze pouzˇ´ıt pro odskok do jine´ho (obvykle uzˇivatelsky definovane´ho) chainu. Zpeˇt se vra´tı´me bud’ tehdy, kdyzˇ na´sledny´ chain neobsahuje vhodne´ pravidlo, a nebo lze na´vrat vynutit targetem RETURN (prˇ´ıkaz umı´stı´me na konec vlastnı´ho chainu): iptables -A vlastni_chain -j RETURN
(zde by bylo vhodne´ prˇidat jesˇteˇ neˇjakou filtrovacı´ podmı´nku, prˇi jejı´mzˇ splneˇnı´ dojde k na´vratu, jinak pravidlo nema´ moc smysl). chain INPUT: ...
chain prvni:
... ... -j prvni
... ... -j druhy ...
...
...
chain druhy: ... ... ... ... -g treti
chain treti: ... ... -j RETURN ... ...
Obra´zek C.4: Rozdı´l mezi parametry -j a -g ve firewallu Zby´va´ jesˇteˇ neˇkolik pomocny´ch prˇepı´nacˇu˚ pouzˇ´ıvany´ch u prˇ´ıkazu -L: -v nebo --verbose -n nebo --numeric
zapı´na´ verbose („ukecany´“) mo´d, chceme delsˇ´ı vy´pis s vı´ce informacemi, pouzˇijeme, kdyzˇ chceme ve vy´pisu IP adresy mı´sto dome´novy´ch, vy´pis je pak celkoveˇ rychlejsˇ´ı a snadneˇji se hromadneˇ zpracova´va´,
dalsˇ´ı bychom nasˇli v manua´love´ stra´nce prˇ´ıkazu: man 8 iptables
$
C.6
FIREWALL V LINUXU
279
Vy´sˇe uvedeny´ vy´cˇet prˇ´ıkazu˚ a parametru˚ nenı´ zdaleka u´plny´, podrobneˇjsˇ´ı informaci bychom nasˇli opeˇt v manua´love´ stra´nce prˇ´ıkazu, prˇ´ıpadneˇ na odkazech na konci te´to sekce. Pozna´mka: Meˇli bychom si uveˇdomit, zˇe zpracova´va´nı´ paketu v tabulce koncˇ´ı v okamzˇiku, kdy NetFilter najde prvnı´ vyhovujı´cı´ pravidlo s cı´lovou akcı´ akceptujı´cı´ nebo zahazujı´cı´ (naprˇ´ıklad ACCEPT nebo DROP). Pokud je v tomto pravidle akce DROP nebo jina´ „zahazovacı´“, paket bude okamzˇiteˇ zahozen, i kdyby trˇeba hned na´sledujı´cı´ pravidlo tento paket povolovalo (k dalsˇ´ımu pravidlu se nedostaneme). Prˇı´klad Pa´r uka´zek pra´ce s iptables: vy´pis pravidel v tabulce filter /sbin/iptables -L -v -n --line-numbers podrobny´ vy´pis (statistika) vsˇech tabulek, s IP adresami (n), v chainech jsou rˇa´dky cˇ´ıslova´ny /sbin/iptables -P INPUT -j DROP stanovı´me vy´chozı´ politiku pro chain INPUT, ve ktere´ rˇekneme, zˇe vsˇe prˇ´ıchozı´ se ma´ zahodit (samozrˇejmeˇ musı´me kromeˇ jine´ho prˇidat prˇed toto pravidlo take´ pravidla, ktera´ uprˇesnı´, co se zahazovat nema´) /sbin/iptables -P OUTPUT -j ACCEPT vsˇechno odchozı´ povolı´me, propustı´me da´l (opeˇt bychom meˇli uvazˇovat, jestli neprˇida´me „vy´jimky“) /sbin/iptables -A INPUT -i lo -j ACCEPT povolı´me to, co probı´ha´ mezi loka´lnı´mi procesy (komunikujı´ prˇes sockety na loopbacku) /sbin/iptables -A INPUT -p tcp --syn -j DROP budou zahozeny vsˇechny prˇ´ıchozı´ pakety, ktere´ majı´ v TCP za´hlavı´ nastaven pouze SYN bit (to je vzˇdy prvnı´ paket spojenı´, tedy znemozˇnı´me navazova´nı´ spojenı´ zvneˇjsˇku) /sbin/iptables -A INPUT -p icmp --icmp-type echo-request -j ACCEPT povolili jsme pakety s ICMP zpra´vou cˇ. 8 (Echo Request) z vneˇjsˇku, mu˚zˇeme pouzˇ´ıt cˇ´ıselne´ i slovnı´ oznacˇenı´ typu zpra´vy /sbin/iptables -A INPUT -p icmp --icmp-type time-exceeded -j ACCEPT povolili jsme prˇ´ıchozı´ ICMP pakety Time Exceeded (vyprsˇenı´ cˇasu prˇi navazova´nı´ spojenı´) /sbin/iptables -t filter -L
/sbin/iptables -A INPUT -p icmp --icmp-type destination-unreachable -j ACCEPT
povolili jsme prˇ´ıchozı´ ICMP pakety hla´sı´cı´ nedostupnost cı´le
´ koly U 1. Nastavte vy´chozı´ politiku pro odchozı´ provoz na akceptova´nı´. 2. Sestavte sadu pravidel, ktera´ z prˇ´ıchozı´ho provozu zaka´zˇou vsˇechno kromeˇ provozu protokolu HTTP, POP a IMAP. 3. Na koncove´ stanici chceme povolit u prˇ´ıchozı´ch paketu˚ pouze ty, ktere´ jdou na TCP port 80 nebo TCP port 8080, vsˇechny ostatnı´ prˇ´ıchozı´ zaka´zˇeme. Jak budou vypadat pravidla pro prˇ´ıslusˇny´ chain? 4. Sestavte pravidla, ktera´ povolı´ ICMP pakety (jake´koliv, vsˇechny typy ICMP zpra´v) v prˇ´ıchozı´m, odchozı´m i pru˚chozı´m provozu.
L
C.6
FIREWALL V LINUXU
C.6.3
280
SPI
Firewall v Linuxu s ja´drem 2.4 a noveˇjsˇ´ım podporuje take´ SPI (Stateful Packet Inspection). Aby bylo mozˇne´ pracovat se stavy spojenı´, je trˇeba mı´t v ja´drˇe zaveden modul pro sledova´nı´ stavu spojenı´ (connection tracking). Drˇ´ıve se pouzˇ´ıval modul ip_conntrack a dalsˇ´ı s nı´m souvisejı´cı´, nynı´ se spı´sˇe setka´me s bezpecˇneˇjsˇ´ım a funkcˇneˇ sˇirsˇ´ım nf_conntrack a moduly s nı´m souvisejı´cı´mi. nf_conntrack plneˇ podporuje IPv4 a IPv6 vcˇetneˇ jejich kombinova´nı´.
P
Prˇı´klad Jak zjistı´me, jestli je modul v ja´drˇe zaveden (vy´pis by´va´ dlouhy´, prˇefiltrujeme si ho prˇ´ıkazem grep), vy´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 na´zev modulu, v druhe´m jeho velikost, na´sleduje pocˇet uzˇivatelu˚ tohoto modulu a prˇ´ıpadne´ za´vislosti (ktere´ zavedene´ moduly dotycˇny´ modul vyzˇadujı´). Pokud vy´pis vypadal podobneˇ jako ten vy´sˇe, pak je vsˇe OK. Pokud potrˇebne´ moduly v ja´drˇe nejsou, tak je trˇeba je do ja´dra zave´st. U kazˇde´ho potrˇebne´ho modulu nejdrˇ´ıv oveˇrˇ´ıme, zda je dostupny´: /sbin/modeprobe -l *conntr*
(prˇ´ıpadneˇ lze vypsat vsˇe a pak to profiltrovat grepem). S dostupnostı´ obvykle neby´va´ proble´m. Zby´va´ modul dostat do ja´dra: /sbin/modeprobe nf_conntrack
Pro dalsˇ´ı moduly je postup podobny´. Podrobny´ na´vod vcˇetneˇ uka´zek vyuzˇitı´ modulu˚ najdeme na http://www.abclinuxu.cz/blog/pb/2007/2/nf-conntrack
Pokud ma´me modul v ja´drˇe, mu˚zˇeme ve firewallu filtrovat pakety podle stavu spojenı´ (mu˚zˇeme je povazˇovat za stavy paketu˚ ve vztahu ke spojenı´, ke ktere´mu patrˇ´ı). Rozlisˇujı´ se tyto stavy: • NEW: klient prˇes firewall navazuje nove´ spojenı´ (tj. prvnı´ paket spojenı´), mu˚zˇe by´t take´ u jednosmeˇrny´ch spojenı´ • ESTABLISHED: paket je soucˇa´stı´ jizˇ nava´zane´ho spojenı´ • RELATED: paket sice navazuje nove´ spojenı´, ale za´rovenˇ je ve vztahu k neˇktere´mu existujı´cı´mu (typicky u FTP, kdy mohou by´t nava´za´na dveˇ ru˚zna´ spojenı´ na dvou portech) • INVALID: paket nelze prˇirˇadit k zˇa´dne´mu existujı´cı´mu ani navazovane´mu spojenı´ Pak v prˇ´ıkazech programu iptables mu˚zˇeme pouzˇ´ıvat filtrova´nı´ podle stavu˚. Existujı´ take´ virtua´lnı´ stavy SNAT a DNAT pro pakety, kde byla prˇelozˇena zdrojova´ resp. cı´lova´ adresa.
P
C.6
FIREWALL V LINUXU
281
Conntrack ve skutecˇnosti nenı´ samostatna´ tabulka, funkcionalita se pouzˇ´ıva´ v existujı´cı´ch tabulka´ch a chainech (na obra´zku C.3 na straneˇ 275 vidı´me, kde konkre´tneˇ v datove´m toku se vyskytuje). Prˇ´ıklady pravidel pro prˇ´ıchozı´ spojenı´: iptables -A INPUT -p tcp ! --syn -m state --state NEW -j LOG --log-prefix ”Nenastaven SYN:” protokolujı´ se vesˇkere´ pakety navazujı´cı´ spo-
jenı´ zvneˇjsˇku, ktere´ nemajı´ nastaven (samotny´) prˇ´ıznak SYN, toto pravidlo je obvykle na´sledova´no tı´mto: zajı´ma´me se o pakety zapouzdrˇujı´cı´ TCP segment (protokol TCP), ktere´ nemajı´ nastaven (samotny´) prˇ´ıznak SYN (je tam negace) a za´rovenˇ stav spojenı´ je nove´ (tj. navazuje se nove´ spojenı´ a prˇitom nenı´ nastaven SYN bit), vy´slednou akcı´ je tiche´ zahozenı´ paketu
iptables -A INPUT -p tcp ! --syn -m state --state NEW -j DROP
zda´nliveˇ tote´zˇ, co prˇedtı´m, ale pozor – pokud zvenku prˇijde paket navazujı´cı´ nove´ spojenı´ a nebude mı´t (chybneˇ) nastaven prˇ´ıznak SYN, tak projde (tudı´zˇ pokud chceme blokovat prˇ´ıchozı´ navazova´nı´ spojenı´, uvedeme obeˇ pravidla)
iptables -A INPUT -m state --state NEW -j DROP
necha´me projı´t dovnitrˇ pakety, ktere´ patrˇ´ı do existujı´cı´ho spojenı´ nebo s neˇktery´m existujı´cı´m souvisejı´
iptables -A INPUT -m state --state RELATED, ESTABLISHED -j ACCEPT
Pro pra´ci s prˇ´ıchozı´mi a odchozı´mi spojenı´mi a modulem nf_conntrack je mozˇne´ pouzˇ´ıt take´ program conntrack z balı´cˇku conntrack-tools (by´va´ beˇzˇneˇ v repozita´rˇ´ıch, takzˇe pokud nenı´ nainstalova´n, mu˚zˇeme doinstalovat). Seznam aktivnı´ch spojenı´, ktera´ jsou povolena mechanismem conntrack, najdeme takto: cat /proc/net/nf_conntrack
Prˇı´klad Ted’ se podı´va´me na mezilehle´ zarˇ´ızenı´ (hardwarovy´ firewall nebo smeˇrovacˇ), na ktere´m chceme nastavit port pro DMZ. Prˇedpokla´dejme, zˇe eth0 je port do loka´lnı´ sı´teˇ, 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 patrˇ´ıcı´ do existujı´cı´ho spojenı´, vztazˇene´ k existujı´-
cı´mu i navazujı´cı´ spojenı´ (provoz z LAN do DMZ), tento smeˇr prakticky nenı´ omezova´n (azˇ na INVALID pakety), vy´stup prˇ´ı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 podobneˇ pro provoz vedoucı´ z vneˇjsˇ´ı sı´teˇ do DMZ, tady je potrˇeba mı´t
povoleno navazova´nı´ spojenı´, protozˇe v DMZ jsou cˇasto webove´ a dalsˇ´ı servery, se ktery´mi je potrˇeba navazovat spojenı´ i zvneˇjsˇku
C.6
FIREWALL V LINUXU
282
iptables -A FORWARD -i eth2 -o eth0 -m state --state ESTABLISHED, RELATED -j ACCEPT zarˇ´ızenı´ umı´steˇna´ v DMZ jsou obecneˇ povazˇova´na za me´neˇ du ˚ veˇry-
hodna´, tj. navazovana´ spojenı´ nepustı´me do LAN (pouze pakety patrˇ´ıcı´ do nava´zany´ch nebo vztazˇeny´ch spojenı´) iptables -A FORWARD -i eth2 -o eth1 -m state --state ESTABLISHED, RELATED -j ACCEPT podobneˇ pro provoz z DMZ do vneˇjsˇ´ı sı´teˇ, servery obvykle nemajı´ co
navazovat nova´ spojenı´ Pak samozrˇejmeˇ potrˇebujeme zby´vajı´cı´ pravidla pro rˇ´ızenı´ provozu na portech eth0 a eth1. U chainu FORWARD prˇedpokla´da´me jako vy´chozı´ za´sadu „zahazovat vsˇe“ (DROP), tedy co jsme explicitneˇ v pravidlech nepovolili nebo neurcˇili k zahozenı´ s ICMP odezvou, bude zahozeno bez odezvy.
Podpora conntrack je du˚lezˇita´ i pro funkcˇnost SNAT/DNAT/MASQUERADE, protozˇe je trˇeba prˇekla´dat podle jedne´ konkre´tnı´ dvojice adres v ra´mci jednoho spojenı´ (v ra´mci dalsˇ´ıho spojenı´ se mu˚zˇe pouzˇ´ıvat jina´ soukroma´ adresa). ´ koly U 1. Zjisteˇte, zda ma´te v ja´drˇe nacˇtene´ alesponˇ neˇktere´ moduly pro SPI. Pokud ano, zjisteˇte, zda se sledova´nı´ stavu˚ spojenı´ pouzˇ´ıva´ v aktua´lnı´ch pravidlech firewallu (zjistı´te z vy´pisu pravidel). Pokud ma´te dostatecˇna´ prˇ´ıstupova´ opra´vneˇnı´, vypisˇte obsah souboru, ve ktere´m jsou uchova´va´na momenta´lneˇ nava´zana´ spojenı´. 2. Sestavte pravidlo, ktere´ bude zakazovat prˇ´ıchozı´ spojenı´ (prˇedpokla´dejme, zˇe jsme na beˇzˇne´ pracovnı´ stanici). 3. Sestavte pravidlo, ktere´ bude akceptovat pakety z jizˇ nava´zany´ch spojenı´.
C.6.4
NAT a masˇkara´da
Prˇeklad adres se prova´dı´ vzˇdy co nejblı´zˇe sı´t’ove´mu rozhranı´, tj. teˇsneˇ prˇed odesla´nı´m paketu do sı´teˇ (vsˇechny ostatnı´ tabulky se procha´zejı´ prˇedtı´m), resp. okamzˇiteˇ po prˇ´ıchodu paketu ze sı´teˇ (a azˇ potom se prova´deˇjı´ dalsˇ´ı tabulky). Kromeˇ targetu˚ ACCEPT, DROP a jiny´ch mu˚zˇeme vyuzˇ´ıvat take´ targety pro prˇeklad adres: • SNAT (Source NAT) – v odchozı´m provozu prˇekla´da´ statickou adresu odesı´latele na jinou (statickou) adresu viditelnou ve vneˇjsˇ´ı sı´ti • DNAT (Destination NAT) – v prˇ´ıchozı´m provozu prˇekla´da´ statickou adresu prˇ´ıjemce na jinou, obvykle soukromou statickou adresu viditelnou pouze ve vnitrˇnı´ sı´ti, pouzˇ´ıva´ se take´ pro prˇeposı´la´nı´ prˇ´ıchozı´ch paketu˚ na proces, ktery´ ma´ tyto pakety da´le zpracovat • MASQUERADE (masˇkara´da) – je to obdoba SNAT, ale pouzˇ´ıva´me tehdy, kdyzˇ prˇekla´da´me dynamicke´ adresy (v odchozı´m provozu prˇekla´da´ soukrome´ adresy z vnitrˇnı´ sı´teˇ na jednu adresu viditelnou vneˇ nasˇ´ı sı´teˇ, obvykle adresu toho zarˇ´ızenı´, na ktere´m je toto pravidlo)
P
C.6
FIREWALL V LINUXU
283
Nejdrˇ´ıv bychom meˇli nastavit vy´chozı´ politiky: pokud neˇco odcha´zı´ prˇes tabulku nat, necha´me to jı´t (to je obvykla´ vy´chozı´ politika pro tabulku nat)
/sbin/iptables -t nat -P OUTPUT -j ACCEPT
podobneˇ pro chain PREROUTING, prˇ´ıpadne´ zahozenı´ necha´me na jiny´ch tabulka´ch, tote´zˇ bychom mohli prove´st pro POSTROUTING
/sbin/iptables -t nat -P PREROUTING -j ACCEPT
Nejdrˇ´ıv se podı´va´me na prˇeklad staticke´ adresy. Nemusı´ by´t zrovna verˇejna´, ale nemeˇla by se meˇnit a meˇli bychom ji zna´t, protozˇe tuto adresu napevno zada´va´me do prˇ´ıkazu.
$
/sbin/iptables -t nat -A POSTROUTING -o eth2 -j SNAT --to 193.168.210.80 zajistı´me
SNAT na odchozı´m provozu odcha´zejı´cı´m prˇes eth2: zdrojova´ adresa v za´hlavı´ odcha´zejı´cı´ho paketu bude zameˇneˇna za uvedenou (statickou viditelnou venku), do prˇekladove´ tabulky se ulozˇ´ı u´daj o te´to komunikaci (pu˚vodnı´ zdrojova´ plus cı´lova´) pro zpeˇtny´ prˇeklad Pokud ma´ na´sˇ router dynamickou adresu (tj. nevı´me prˇedem, jakou prˇi navazova´nı´ spojenı´ nebo obnovova´nı´ prˇideˇlenı´ adresy dostaneme), pouzˇijeme masˇkara´du. Masˇkara´da funguje podobneˇ jako SNAT, ale vyuzˇ´ıva´ se vy´hradneˇ u dynamicky´ch adres (ostatneˇ, dynamickou adresu bychom stejneˇ nemohli do SNAT pravidla naklepat), u´daje pro prˇeklad se uchova´vajı´ v jednom ze souboru˚ v souborove´m syste´mu /proc (pro kazˇde´ spojenı´ se ukla´da´ dvojice soukroma´ adresa v LAN plus vneˇjsˇ´ı adresa, se kterou se komunikuje).
$
/sbin/iptables -t nat -A POSTROUTING -o eth2 -j MASQUERADE zajistili jsme masˇkara´du
(masquerade) na portu eth2, tj. vsˇe, co odcha´zı´ ven ze sı´teˇ na portu eth2, bude mı´t prˇelozˇenu zdrojovou adresu (obvykle soukromou, prˇideˇlenou DHCP serverem) na adresu routeru, automaticky je zajisˇteˇn za´znam s uvedenı´m portu pro zajisˇteˇnı´ zpeˇtne´ konverzace (tj. PAT) tote´zˇ, jen port je jinak pojmenova´n (to je velice cˇasty´ na´zev u routeru˚ kombinovany´ch s DSL modemem)
/sbin/iptables -t nat -A POSTROUTING -o ppp0 -j MASQUERADE
Pokud ma´ take´ na´sˇ router (firewall) IP adresu viditelnou vneˇ nasˇ´ı sı´teˇ take´ dynamickou (od DHCP serveru nasˇeho ISP), je trˇeba pozmeˇnit hodnotu v jednom ze souboru˚ virtua´lnı´ho soub. syste´mu /proc: echo 7 > /proc/sys/net/ipv4/ip_dynaddr
To je pro prˇ´ıpad, zˇe „vneˇjsˇ´ı“ adresa, ktera´ je prˇi masˇkara´deˇ pouzˇita pro prˇeklad mı´stnı´ch soukromy´ch adres, „vypadne“, je potrˇeba pozˇa´dat o novou, ktera´ je pravdeˇpodobneˇ jina´. Pokud je dotycˇny´ parametr takto nastaven, pak se v takove´ situaci zameˇnı´ stara´ dynamicka´ adresa za noveˇ zı´skanou ve vsˇech zaznamenany´ch pra´veˇ probı´hajı´cı´ch spojenı´ch. Vra´tı´me se ke staticky´m adresa´m. Mechanismus NAT se pouzˇ´ıva´ take´ pro prˇeposı´la´nı´ prˇ´ıchozı´ho provozu: /sbin/iptables -t nat -A PREROUTING -i eth2 -p tcp --dport 80 -j REDIRECT --to-port 3128 pokud prˇijde prˇes rozhranı´ eth2 paket z TCP portu cˇ. 80
(velmi pravdeˇpodobneˇ pro protokol HTTP), prˇesmeˇruj ho na port 3128; to se pouzˇ´ıva´ tehdy, kdyzˇ na portu 3128 nasloucha´ Squid konfigurovany´ jako transparentnı´ proxy, tj. da´le proveˇrˇuje a zpracova´va´ tento typ paketu˚
$
C.6
FIREWALL V LINUXU
284
Vsˇimneˇte si, zˇe filtrova´nı´ a NAT lze jednodusˇe kombinovat s prˇekladem portu˚. Mechanismus NAT mu˚zˇe slouzˇit pro prˇeklad jedne´ staticke´ adresy na jinou statickou, pak je potrˇeba zajistit rucˇneˇ prˇeklad v obou smeˇrech a u kazˇde´ho smeˇru uve´st obeˇ adresy. Vy´hodou tohoto rˇesˇenı´ oproti jednoduche´mu SNAT a masˇkara´deˇ je rychlejsˇ´ı zpracova´nı´ (provoz nenı´ zdrzˇova´n vyhleda´va´nı´m dynamicky prˇideˇleny´ch adres v docˇasny´ch souborech). Prˇedpokla´dejme, zˇe v DMZ ma´me server se soukromou (uvnitrˇ viditelnou) adresou 10.201.51.2, chceme, aby byl vneˇ sı´teˇ viditelny´ pod adresou 195.201.51.2. Je trˇeba zadat na´sledujı´cı´ dveˇ pravidla, jedno pro provoz smeˇrem od serveru ven, druhe´ pro opacˇny´ smeˇr (zpeˇtny´ prˇeklad):
$
/sbin/iptables -t nat -A PREROUTING -d 10.201.51.2 -j DNAT --to-destination 195.201.51.2
nastavenı´ DNAT, tedy prˇekladu cı´love´ adresy v paketu (provoz smeˇrem do sı´teˇ), zameˇnı´ soukromou adresu za uvedenou 195.201.51.2 v za´hlavı´ prˇicha´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 prˇekladu zdrojove´ adresy (provoz smeˇrem ven) Na jednu veˇc bychom si meˇli da´t pozor: mechanismus NAT funguje tak, zˇe se pravidlo s prˇesmeˇrova´nı´m adresy pouzˇije pouze na prvnı´ paket spojenı´, a pouze prvnı´ paket spojenı´ procha´zı´ tabulkou nat. Dalsˇ´ı pakety patrˇ´ıcı´ do te´hozˇ spojenı´ (tj. pakety, ktere´ nejsou „prvnı´“), vu˚bec do tabulky nat neprˇijdou, proto se jich tato pravidla nety´kajı´.
L
´ koly U 1. Ve vy´pisu pravidel firewallu zjisteˇte, zda je nastaven prˇeklad adres. 2. Sestavte pravidlo pro SNAT odchozı´ho provozu na portu wan0, prˇekla´da´ se na statickou adresu 195.49.88.1. 3. Sestavte pravidlo pro masˇkara´du odchozı´ho provozu na portu wan0.
C.6.5
Oznacˇova´nı´ paketu˚
Firewall NetFilter mu˚zˇe do za´hlavı´ paketu˚ prˇida´vat znacˇky (marks), ktery´m rozumı´ jak jeho pravidla, tak i neˇktere´ dalsˇ´ı na´stroje (vcˇetneˇ prˇ´ıkazu ip). Prˇida´va´nı´ znacˇek je jednou z funkcı´ souvisejı´cı´ch s tabulkou mangle (protozˇe jde o zmeˇnu neadresnı´ho u´daje v za´hlavı´) nebo nat, znacˇku pak mu˚zˇeme vyuzˇ´ıvat jinde (typicky v tabulce filter). Rozlisˇujeme dva druhy znacˇek: • NetFilter mark se nastavuje targetem MARK, je viditelny´ i mimo firewall, touto znacˇkou se oznacˇujı´ pakety, v terminologii iproute2 se take´ nazy´va´ fwmark (firewall mark), • connection mark se nastavuje targetem CONNMARK, slouzˇ´ı pouze pro vnitrˇnı´ potrˇebu firewallu; touto znacˇkou se oznacˇuje spojenı´ (pozor, ne paket), znacˇku lze prˇene´st i do za´hlavı´ paketu˚ (pak jde o NetFilter znacˇky), nebo naopak.
P
C.6
FIREWALL V LINUXU
285
Znacˇky NetFilter lze do za´hlavı´ paketu ulozˇit pomocı´ prˇ´ıkazu firewallu iptables targetem MARK, vyuzˇ´ıvat je lze bud’ v tabulka´ch firewallu pro dalsˇ´ı filtrova´nı´ cˇi u´pravy, a nebo mechanismem iproute2 (prˇ´ıkazem ip rule). Uka´zˇeme si neˇkolik prˇ´ıkazu˚ s vyuzˇitı´m znacˇek (prˇ´ıkazy jsou cˇ´ım da´l delsˇ´ı, proto mı´sto cele´ cesty /sbin/iptables budeme psa´t jen iptables):
$
pokud paket prˇisˇel z rozhranı´ eth2, dostane znacˇku 2 (pouzˇijeme target MARK, protozˇe oznacˇenı´ je du˚sledkem, nikoliv podmı´nkou), platı´ jak pro pakety, ktere´ pu˚jdou do chainu INPUT, tak i pro pakety mı´rˇ´ıcı´ do chainu FORWARD v jiny´ch tabulka´ch (na obra´zku C.3 mu˚zˇeme videˇt, zˇe oznacˇujeme prakticky hned na vstupu firewallu, pokud nepouzˇ´ıva´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 ma´ paket znacˇku 2“ (znamena´: pokud ma´ paket znacˇku 2 a za´rovenˇ jde na TCP port 80, akceptuj), vsˇimneˇte si odlisˇnosti pra´ce s oznacˇenı´m oproti prˇedchozı´mu prˇ´ıkazu (zde je targetem ACCEPT) iptables -t nat -A PREROUTING -p tcp --dport 80 -j CONNMARK --set-mark 2
u prˇ´ıchozı´ch spojenı´ mı´rˇ´ıcı´ch na TCP port 80 (http) nastavı´me znacˇku spojenı´ na 2 (protozˇe je pravidlo v tabulce nat, provede se vzˇdy jen pro prvnı´ paket spojenı´, proto se cˇasto rˇadı´ pra´veˇ do tabulky nat) znacˇku spojenı´ mu˚zˇeme nastavit take´ takto: prˇedpokla´dejme, zˇe znacˇka paketu byla nastavena jizˇ prˇedtı´m (v prˇedchozı´ tabulce), pak hodnota te´to znacˇky paketu se ulozˇ´ı do znacˇky spojenı´ (tj. connmark := fwmark)
iptables -t mangle -A PREROUTING -j CONNMARK --save-mark
iptables -t mangle -A POSTROUTING -j CONNMARK --restore-mark opacˇny´ prˇenos informace, znacˇka spojenı´ se ulozˇ´ı do znacˇky paketu (tj. fwmark := connmark)
Pokud firewall oznacˇil paket znacˇkou fwmark, lze tuto znacˇku da´le zpracova´vat beˇhem smeˇrova´nı´, naprˇ´ıklad takto: prˇidali jsme nove´ smeˇrovacı´ pravidlo: pakety oznacˇene´ znacˇkou 4 jsou smeˇrova´ny podle tabulky tabVen (na obra´zku C.3 na straneˇ 275 si vsˇimneˇte, kdy ke smeˇrova´nı´ vzhledem k chainu˚m firewallu docha´zı´, a kdy tedy je trˇeba paket oznacˇit, aby se podle znacˇky dalo smeˇrovat)
ip rule add fwmark 4 table tabVen prio 2021
Dalsˇ´ı informace o te´to problematice (vcˇetneˇ prˇ´ıkladu˚) 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 vhodne´ si vytvorˇit jeden nebo vı´ce skriptu˚ pro konfiguraci firewallu, a to z neˇkolika du˚vodu˚: prˇedneˇ potrˇebujeme, aby vesˇkera´ nastavenı´, ktera´ provedeme, byla platna´ neusta´le (i po prˇ´ıpadne´m restartu), abychom meˇli za´lohu pro prˇ´ıpad poruchy a aby bylo mozˇne´ obcˇas sadu pravidel meˇnit cˇi neˇkdy vypı´nat (mazat pravidla a pak podle potrˇeby obnovit). Uka´zky neˇkolika typicky´ch konfiguracˇnı´ch skriptu˚ s pravidly iptables najdeme naprˇ´ıklad na • http://www.faqs.org/docs/iptables/examplecode.html (to je prvnı´ skript, na dalsˇ´ı se dostaneme klepa´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
Ulozˇenı´ zmeˇn
Aby byla konfigurace nejen platna´, ale take´ ulozˇena pro nacˇtenı´ po vypnutı´ a zapnutı´ pocˇ´ıtacˇe, je nutne´ tuto konfiguraci ulozˇit. Je velmi pravdeˇpodobne´, zˇe distribuce, kterou ma´me, podporuje prˇ´ıkazy iptables-save a iptables-restore, ktere´ na´m mohou velmi usnadnit pra´ci s „hromadny´m“ startova´nı´m cˇi ukoncˇova´nı´m firewallu.14 ulozˇ´ı obsah vsˇech tabulek a chainu˚ (tj. vsˇechna pravidla) na standardnı´ vy´stup, tj. pouzˇ´ıva´me prˇesmeˇrova´nı´, naprˇ´ıklad iptables-save > /etc/firerules
iptables-save
iptables-save -c -t filter prˇi pouzˇitı´ prˇepı´nacˇe -c se ulozˇ´ı take´ stav cˇ´ıtacˇu˚ paketu˚ a oktetu˚, prˇepı´nacˇ -t zase omezı´ ulozˇenı´ pouze na zadanou tabulku (zde tabulku filter)
nacˇte pravidla (tabulky, chainy) ze standardnı´ho vstupu (tj. opeˇt musı´me pouzˇ´ıt prˇesmeˇrova´nı´ nebo trˇeba rouru s prˇ´ıkazem cat, naprˇ´ıklad iptables-restore < /etc/firerules)
iptables-restore
iptables-restore -c
nacˇte take´ hodnoty cˇ´ıtacˇu˚
pokud uzˇ prˇedtı´m byla neˇjaka´ pravidla ve firewallu aktivova´na, nebudou noveˇ nacˇteny´mi prˇepsa´na, nova´ pravidla se pouze prˇidajı´ (bez uvedenı´ parametru -n by po vykona´nı´ prˇ´ıkazu byla pu˚vodneˇ aktivnı´ pravidla prˇepsa´na, odstraneˇna – flushed)
iptables-restore -n
Pokud tyto prˇ´ıkazy nenajdeme, pak musı´me pouzˇ´ıt postup typicky´ pro danou distribuci. Naprˇ´ıklad v distribucı´ch zalozˇeny´ch na RedHat (vcˇetneˇ Mandrivy) je to prˇ´ıkaz /sbin/service iptables save
V distribucı´ch zalozˇeny´ch na Debianu v souboru /etc/default/iptables nastavı´me rˇa´dek enable_iptables_initd=true 14
Pozor – tı´m, zˇe ukoncˇ´ıme program iptables, rozhodneˇ nevypneme firewall, ten je totizˇ modulem ja´dra. Vpodstateˇ je firewall zapnuty´ po celou dobu, co je jeho modul zaveden v ja´drˇe, obdobou vypnutı´ by bylo vypra´zdneˇnı´ vsˇech tabulek vnitrˇnı´m prˇ´ıkazem -F.
$
C.7
TESTOVA´NI´ A STATISTIKY
287
cˇ´ımzˇ ulozˇenı´ povolı´me, samotne´ ulozˇenı´ se provede prˇ´ıkazem /etc/init.d/iptables save_active
Pokud chceme firewall deaktivovat (pojem „vypnout“ nenı´ zrovna spra´vny´), vypra´zdnı´me jeho chainy: iptables -F
L
(prˇ´ıpadneˇ zada´me tabulku a chain). Pokud ale neˇco takove´ho opravdu chceme udeˇlat, meˇli bychom si prˇedem prove´st za´lohu pravidel, trˇeba vy´sˇe popsany´m zpu˚sobem. Nenı´ vzˇdy nutne´ prova´deˇt konfiguraci a jejı´ ulozˇenı´ v textove´m rezˇimu. Existuje dokonce neˇkolik ru˚zny´ch graficky´ch rozhranı´ k programu iptables. V desktopovy´ch distribucı´ch je najdeme celkem beˇzˇneˇ, prˇ´ıpadneˇ je mozˇne´ si neˇktery´ z nich sta´hnout z repozita´rˇe a nainstalovat. V unixovy´ch syste´mech zalozˇeny´ch na BSD (naprˇ´ıklad OpenBSD) se cˇasto setka´me s firewallem PacketFilter (starsˇ´ı byl IPFilter), obsluzˇny´ program je pfctl. Problematika firewallu v Linuxu je velmi rozsa´hla´, sekce v teˇchto skriptech zdaleka nepokry´va´ vsˇechny mozˇnosti, ktere´ NetFilter nabı´zı´. Dalsˇ´ı 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
Testova´nı´ a statistiky
C.7.1
Za´kladnı´ na´stroje
Prˇ´ıkaz ping slouzˇ´ı ke stejny´m u´cˇelu˚m jako ve Windows: v pravidelny´ch intervalech odesı´la´ cı´love´mu zarˇ´ızenı´ ICMP pakety, po prˇerusˇenı´ kla´vesou Ctrl+C ukoncˇ´ı zası´la´nı´ a vypı´sˇe souhrnnou statistiku (kolik paketu˚ bylo odesla´no, prˇijato, podı´l ztraceny´ch, da´le odezvu cı´love´ho pocˇ´ıtacˇe – nejrychlejsˇ´ı, nejpomelejsˇ´ı, strˇednı´ hodnota), cı´lovy´ pocˇ´ıtacˇ mu˚zˇeme zadat take´ IP adresou ping -c 4 www.google.com chova´ se stejneˇ jako ve Windows, tedy zada´me pocˇet zası´lany´ch ICMP paketu˚ (bez tohoto parametru by byly zası´la´ny tak dlouho, dokud bychom nestiskli Ctrl+C) ping -c 1 -R www.google.com parametr -R (pozor, velke´ pı´smeno) znamena´, zˇe se vypı´sˇou vsˇechny uzly na cesteˇ (smeˇrovacˇe) podobneˇ jako naprˇ´ıklad u traceroute (ale zde zı´ska´me me´neˇ podrobny´ vy´pis) ping www.google.com
V manua´love´ stra´nce bychom zjistili dalsˇ´ı mozˇne´ parametry.
$
C.7
TESTOVA´NI´ A STATISTIKY
288
Existuje take´ prˇ´ıkaz arping, ktery´ ma´ podobny´ u´cˇel jako ping, ale pouzˇ´ıva´ jiny´ typ paketu˚ (ARP Request) a je urcˇen prˇedevsˇ´ım pro testova´nı´ v loka´lnı´ sı´ti. zadane´mu cı´li (poslednı´ parametr) prˇes zadane´ rozhranı´ odesˇle maxima´lneˇ cˇtyrˇi ARP pakety, parametr -f urcˇuje, zˇe se nemusejı´ deslat vsˇechny 4, ale pouze tolik, nezˇ vzda´leny´ syste´m odpovı´
arping -f -c 4 -I eth0 209.85.143.99
Zatı´mco ve Windows ma´me prˇ´ıkaz tracert, v unixovy´ch syste´mech vcˇetneˇ Linuxu se setka´me s prˇ´ıkazem traceroute. vypı´sˇe trasu k zadane´mu zarˇ´ızenı´ (zada´va´me dome´novou nebo IP adresu), pouzˇije UDP pakety (pouze metoda s vyuzˇitı´m UDP paketu˚ je pouzˇitelna´ ktery´mkoliv uzˇivatelem)
traceroute www.google.com
$
podobneˇ, ale pouzˇije zpra´vy ICMP Echo Request (prˇepı´nacˇ je velke´ „i“), ekvivalentem je prˇ´ıkaz tracert (s nı´m se setka´me i u Windows)
traceroute -I 209.85.143.99 traceroute -6 209.85.143.99 slouzˇ´ı prˇepı´nacˇ -4
vynucenı´ pouzˇitı´ IPv6 (take´ traceroute6), k vynucenı´ IPv4
Tento prˇ´ıkaz ma´ jesˇteˇ neˇkolik dalsˇ´ıch prˇepı´nacˇu˚ (viz manua´love´ stra´nky) vcˇetneˇ u teˇchto prˇ´ıkazu˚ beˇzˇne´ho -n zakazujı´cı´ho mapova´nı´ IP adres na dome´nove´ na´zvy, urcˇenı´ maxima´lnı´ hodnoty TTL, atd. Podobny´ je prˇ´ıkaz tracepath (v neˇktery´ch distribucı´ch ho vsˇak nenajdeme). Slouzˇ´ı prˇedevsˇ´ım ke zjisˇteˇnı´ hodnot MTU na cesteˇ:
$
vypı´sˇe u´daje o cesteˇ k zadane´mu uzlu sı´teˇ (ke kazˇde´mu u´seku zjistı´me hodnotu odecˇ´ıtane´ho TTL na tomto u´seku, cˇasovy´ u´daj a hodnotu MTU (Path MTU)
tracepath 209.85.143.99
tracepath -n 209.85.143.99
mı´sto dome´novy´ch se vypisujı´ IP adresy
Samozrˇejmeˇ nesmı´ chybeˇt prˇ´ıkaz netstat. Parametry jsou obdobne´ teˇm ve Windows (odkud se tento prˇ´ıkaz asi do Windows dostal), tedy si zde uvedeme jen neˇkolik dalsˇ´ıch motivacˇnı´ch prˇ´ıkladu˚:
$
Prˇı´klad Zobrazı´me seznam otevrˇeny´ch portu˚, postupneˇ: vy´pis numericky´ch IP adres (n), vy´pis UDP portu˚ (u), TCP portu˚ (t), vsˇechny u´daje (a, naslouchajı´cı´ i nenaslouchajı´cı´), vypsat PID procesu˚, ktere´ port pouzˇ´ıvajı´ (p). Vy´pis prˇ´ıkazu na´sleduje. sarka@notebook:/home/sarka# netstat -nutap Aktivnı ´ Internetova ´ spojenı ´ (servery a˜nava ´zana ´ spojenı ´) Proto Pr ˇı ´ch-F Odch-F Mı ´stnı ´ Adresa Vzda ´lena ´ 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
TESTOVA´NI´ 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, zˇe (aktivneˇ) komunikuje prˇedevsˇ´ım Firefox, dalsˇ´ı de´mony spı´sˇe naslouchajı´. Najdeme tam naprˇ´ıklad nechvalneˇ zna´my´ Avahi (prova´dı´ tzv. Zero-conf automaticke´ nastavenı´ parametru˚ sı´teˇ, cozˇ je odbornı´ky hodneˇ kritizova´no), cupsd (tiskovy´ subsyste´m), hpiod (de´mon pro podporu tisku kompatibilnı´ s HP zarˇ´ızenı´mi), exim4 (sı´t’ova´ podpora pro mail klienty, v soucˇasne´ dobeˇ se spı´sˇe doporucˇuje pouzˇ´ıt postfix), inetd,15 dhclient (DHCP klient), atd. (vy´pis byl za´meˇrneˇ mı´rneˇ zkra´cen).
Prˇı´klad V Linuxu si pomocı´ prˇ´ıkazu netstat mu˚zˇeme prohle´dnout tabulku sı´t’ovy´ch rozhranı´ tak, jak ji vidı´ ja´dro: sarka@notebook:/home/sarka# netstat -i Tabulka rozhranı ´ v ja ´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, uzˇ vı´me. Na´sleduje metrika, u´daje pro prˇ´ıchozı´ (RX) a odchozı´ (TX) pakety, kdy se vypisuje pocˇet u´speˇsˇneˇ prˇijaty´ch/odeslany´ch, chybny´ch, zahozeny´ch. Poslednı´ sloupec obsahuje jednopı´smenne´ prˇ´ıznaky: • • • • • 15
B: prˇijı´ma´ broadcast pakety, M: zapnut promiskuitnı´ rezˇim, R: rozhranı´ je pouzˇ´ıva´no (beˇzˇ´ı, running) U: rozhranı´ je aktivnı´ (up) L: loopback
Inetd ma´ podobnou funkci jako ve Windows svchost.exe, mu˚zˇe hostit de´mony. Narozdı´l od svchost je zde pro de´mony „pohostinstvı´“ dobrovolne´, mohou beˇzˇet samostatneˇ. Inetd jednodusˇe nasloucha´ na prˇ´ıslusˇny´ch portech a kdyzˇ zjistı´ pokus o komunikaci s de´monem, jehozˇ hostı´, jeho ko´d spustı´ ve sve´m vlastnı´m procesu, nenı´ trˇeba spousˇteˇt de´mona navı´c (tj. mı´sto vı´ce ru˚zny´ch de´monu˚ beˇzˇ´ı jen jeden, inetd, a prˇ´ıslusˇne´ sluzˇby se spousˇteˇjı´ azˇ na vyzˇa´da´nı´).
M
VZDA´LENY´ PRˇI´STUP
C.8
290
Prˇ´ıkaz netstat-nat je zda´nliveˇ podobny´ prˇ´ıkazu netstat, ale nenı´ tenty´zˇ: vy´pis adres prˇekla´dany´ch mechanismem NAT (pozor, prˇed pomlcˇkou nenı´ mezera, opravdu se jedna´ o cely´ prˇ´ıkaz bez jaky´chkoliv parametru˚)
netstat-nat
$
prˇed druhou pomlcˇkou uzˇ mezera je, vy´znam prˇ´ıkazu je stejny´ jako u prˇedchozı´ho, ale mı´sto na´zvu˚ pocˇ´ıtacˇu˚ se budou vypisovat IP adresy (tj. bez DNS prˇekladu)
netstat-nat -n
C.7.2
Pokrocˇile´ testova´nı´
Pro pokrocˇile´ testova´nı´ stroju˚ a cele´ sı´teˇ existuje mnoho velmi uzˇitecˇny´ch na´stroju˚. V tomto prˇedmeˇtu je bohuzˇel nestacˇ´ıme probrat (ale beˇhem jednoho roku by zde meˇla by´t alesponˇ doplneˇna sekce s jejich popisem). Nama´tkou: • tcpdump • nmap • ettercap
C.8
Vzda´leny´ prˇı´stup
Pokud chceme prˇistupovat k neˇktere´mu uzlu sı´teˇ s Linuxem vzda´leneˇ (z jine´ho pocˇ´ıtacˇe), lze pouzˇ´ıt neˇkolik na´stroju˚. Prˇedneˇ vsˇechny takove´ uzly urcˇiteˇ podporujı´ prˇ´ıkaz telnet. Ovsˇem to, zˇe tento prˇ´ıkaz podporujı´, jesˇteˇ neznamena´, zˇe ho mu˚zˇeme pouzˇ´ıt. Prˇedevsˇ´ım protokol telnet je na mnoha pocˇ´ıtacˇ´ıch uzˇ beˇhem instalace zaka´za´n, a to z bezpecˇnostnı´ch du˚vodu˚. Pokud prˇesto chceme tı´mto zpu˚sobem na dany´ pocˇ´ıtacˇ prˇistupovat, musı´me telnet povolit. Postup je v ru˚zny´ch distribucı´ch odlisˇny´, popis najdeme zde:
$
• Ubuntu: http://www.cyberciti.biz/faq/ubuntu-linux-enable-telnet-service/ • RedHat: http://aplawrence.com/Linux/enable telnet.html atd. (vzˇdy bychom se meˇli radeˇji podı´vat na stra´nky nasˇ´ı distribuce). Nicme´neˇ pouzˇ´ıva´nı´ protokolu telnet se moc nedoporucˇuje, mı´sto neˇho bychom meˇli radeˇji pouzˇ´ıvat protokol SSH (prˇ´ıkaz ssh pro zajisˇteˇnı´ spojenı´ a pak prˇ´ıkaz scp pro zabezpecˇene´ kopı´rova´nı´ s vyuzˇitı´m protokolu SSH), ktery´ je takte´zˇ dostupny´ na prakticky vsˇech uzlech sı´teˇ a klienti jsou dostupnı´ i pro Windows. SSH ma´ vy´hody prˇedevsˇ´ım v oblasti zabezpecˇenı´, sˇifruje se cela´ komunikace vcˇetneˇ zası´la´nı´ prˇihlasˇovacı´ch informacı´.
$
Nejdrˇ´ıv je potrˇeba nainstalovat na „vzda´leny´ stroj“ SSH server, pak na stroj, ze ktere´ho budeme na ten vzda´leny´ prˇistupovat, nainstalujeme SSH klienta. Jako SSH server se v Linuxu beˇzˇneˇ pouzˇ´ıva´ OpenSSH Server, ktery´ najdeme v repozita´rˇi obvykle pod na´zvem openssh-server (za´lezˇ´ı na konkre´tnı´ distribuci, prosteˇ si prohle´dneme obsah repozita´rˇe v neˇktere´m vhodne´m programu, trˇeba i v graficke´m prostrˇedı´). Taky je mozˇne´, zˇe uzˇ ma´me tento balı´cˇek nainstalovany´. Co se ty´cˇe klientu˚, na strojı´ch s Linuxem uzˇ obvykle by´va´ nainstalova´n, ve Windows si mu˚zˇeme sta´hnout trˇeba program puTTY nebo TTSSH. Postup konfigurace a pouzˇ´ıva´nı´ SSH mu˚zˇeme najı´t na teˇchto odkazech: • http://wiki.ubuntu.cz/SSH
C.9
DALSˇI´ PRˇI´KAZY
291
• http://www.xenocafe.com/tutorials/openssh linux/redhat/openssh linux redhat.php (oproti na´vodu lze OpenSSH instalovat i jednodusˇeji z repozita´rˇu˚) • http://www.debianhelp.co.uk/ssh.htm Pokud chceme jen sta´hnout soubor z neˇktere´ho FTP nebo WWW serveru, nepotrˇebujeme vy´sˇe uvedene´ na´stroje. Obvykle na´m stacˇ´ı webovy´ prohlı´zˇecˇ nebo neˇktery´ graficky´ klient, ale neˇkdy se hodı´ i na´stroj pro pouzˇitı´ v textove´m rezˇimu. V tomto smeˇru je k nezaplacenı´ prˇ´ıkaz wget. Tento prˇ´ıkaz tedy slouzˇ´ı ke stahova´nı´ souboru˚ z webu (podporuje protokoly FTP, HTTP, HTTPS vcˇetneˇ proxy), dokonce zvla´da´ i rekurzivnı´ stahova´nı´ (naprˇ´ıklad HTML stra´nky vcˇetneˇ vnitrˇnı´ struktury, vytvorˇ´ı se offline verze stra´nek) a doka´zˇe nava´zat na drˇ´ıveˇjsˇ´ı prˇerusˇene´ stahova´nı´. Jednoduche´ prˇ´ıklady pouzˇitı´: wget http://ftp.edunix.cz/pub/danix/Evolution2/dvd/DANIX-evol2-dvd-2007-11-04.iso
stahujeme DVD Linuxu Danix (pozor, vzˇdy je trˇeba si zjistit adresu pro nejnoveˇjsˇ´ı verzi) nava´zˇe na prˇedchozı´ prˇerusˇene´ stahova´nı´ (prˇ´ıkaz je spousˇteˇn v tomte´zˇ pracovnı´m adresa´rˇi jako prˇi prˇedchozı´m stahova´nı´)
wget -c ftp://adresa/dokument.pripona
´ koly U Zobrazte si manua´lovou stra´nku prˇ´ıkazu wget a zjisteˇte, jak se da´ spustit • ve „spider“ mo´du, tedy dokument, ktery´ ma´ zada´n ke sta´hnutı´, nesta´hne, ale jen zkontroluje, zda je na sve´m mı´steˇ, • bezpecˇneˇ, aby se stahovalo s vyuzˇitı´m neˇktere´ho sˇifrova´nı´ (SSL nebo TLS), • s rekurzivnı´m stahova´nı´m. Vyzkousˇejte si sta´hnutı´ neˇktere´ho dokumentu s prˇ´ıponou PDF z webu (prˇ´ıpadneˇ ISO obsaz neˇktere´ distribuce Linuxu, pokud ma´te dostatecˇneˇ rychle´ prˇipojenı´ bez limitu˚).
C.9
Dalsˇı´ prˇı´kazy
V Linuxu ma´me k dispozici velmi mnoho dalsˇ´ıch prˇ´ıkazu˚, ktere´ souvisejı´ s adresami na sı´ti, naprˇ´ıklad mtr
na´stroj pro aktivnı´ diagnostiku sı´teˇ (pozor, generuje provoz na sı´ti, podle neˇho pak vyhodnocuje parametry sı´teˇ) dalsˇ´ı diagnosticky´ na´stroj
lft
bezpecˇnostnı´ testovacı´ na´stroj, ktery´ zası´la´nı´m TCP nebo UDP paketu˚ (lze urcˇit parametrem) zjisˇt’uje, ktere´ porty jsou na prˇeposı´lajı´cı´ch (forwarding) zarˇ´ızenı´ch v sı´ti otevrˇene´
firewalk
program pro administraci zarˇ´ızenı´ slouzˇ´ıcı´ho jako ethernetovy´ bridge, jako prvnı´ parametr se zada´va´ neˇktery´ z prˇ´ıkazu˚ pro konfiguraci mostu (lze naprˇ´ıklad zobrazovat informace, pracovat s porty cˇi s nastavenı´m protokolu STP, apod.)
brctl
tcpdump
$
C.9
DALSˇI´ PRˇI´KAZY
292
jednoduchy´ program, ktery´ na´m mu˚zˇe pomoci orientovat se v IP adresa´ch sı´tı´/podsı´tı´/uzlu˚ („IP kalkulacˇka“), uka´zka pouzˇitı´ je v prˇ´ıkladu nı´zˇe
ipcalc host
pouzˇ´ıva´ se podobneˇ jako nslookup v neinteraktivnı´m rezˇimu, tedy IP adresu prˇelozˇ´ı na na´zev a naopak (oproti nslookup bere prˇednostneˇ u´daje ze souboru /etc/hosts, azˇ kdyzˇ tam u´daj nenajde, ta´zˇe se DNS serveru)
Pro konfiguraci bezdra´tove´ sı´t’ove´ karty lze pouzˇ´ıt na´stroje iwlist a iwconfig. Prˇı´klad Uka´zˇeme si pra´ci se zajı´mavy´m prˇ´ıkazem ipcalc, ktery´ podle zadane´ IP adresy podsı´teˇ vypı´sˇe masku, inverznı´ masku, rozsah adres uzlu˚ v zadane´ podsı´ti, broadcast adresu a pocˇet mozˇny´ch uzlu˚ v sı´ti. Prˇ´ıkaz chceme spustit na stanici s nainstalovany´m Ubuntu. Tato distribuce sice dotycˇny´ na´stroj ve vy´chozı´ instalaci neobsahuje, ale doka´zˇe poradit, jaky´m zpu˚sobem ma´me na´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
Takzˇe program nenı´ nainstalova´n. Ale byli jsme upozorneˇni, zˇe se nacha´zı´ v repozita´rˇi (jsme prˇipojeni k Internetu, ma´me prˇ´ıstup do repozita´rˇu˚ Ubuntu), ma´me prˇed ocˇima prˇ´ıkaz, ktery´m program nainstalujeme. Protozˇe zna´me administra´torske´ heslo, nenı´ to proble´m (vsˇimneˇte si prˇ´ıkazu sudo, ktery´ v Ubuntu a neˇktery´ch dalsˇ´ıch distribucı´ch slouzˇ´ı k zı´ska´nı´ vysˇsˇ´ıch prˇ´ıstupovy´ch opra´vneˇ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 netrˇeba (nejsme prˇece ve Windows), tedy konecˇneˇ mu˚zˇeme spustit prˇ´ıkaz, jako parametr zada´me IP adresu (pod)sı´teˇ vcˇetneˇ de´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
DALSˇI´ PRˇI´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ı´ ru˚zne´ na´stroje pro testova´nı´ zabezpecˇenı´ sı´teˇ, ktere´ nejsou soucˇa´stı´ beˇzˇny´ch distribucı´, ale rozhodneˇ stojı´ za to si je sta´hnout a pouzˇ´ıvat. Naprˇ´ıklad SATAN 16 (System Administrators Tool for Analyzing Networks) procha´zı´ celou sı´t’ a prova´dı´ bezpecˇnostnı´ testy. Je oblı´beny´ jak u administra´toru˚, tak i u hackeru˚, i kdyzˇ kazˇdy´ z nich ma´ samozrˇejmeˇ jinou motivaci. Dalsˇ´ı informace: • Zajı´mavy´ tutoria´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/ • CˇECˇA´K, O. Linux v prˇ´ıkazech – pra´ce s Wi-Fi [online]. Dostupne´ na http://www.linuxsoft.cz/article.php?id article=1351
16
Ke stazˇenı´ na http://www.porcupine.org/satan/.
