IT - Modul 1izm.euweb.cz/informacni_technologie_pocitacove_site.pdf · 2010. 11. 14. · 4 Modul 1:...

Výukový program:

Informační technologie

Modul 1: Počítačové sítě

Ing. Petr Grygárek, Ph.D.

Výukový program: Informační technologie 1

1 Počítačové sítě

Osnova:

1.1 Moderní technologie přepínaných lokálních sítí 1.2 Protokol IP verze 6 1.3 Směrování v počítačových sítích a v Internetu. 1.4 Podpora multimediálních aplikací v Internetu 1.5 Bezpečnost počítačových sítí

Návod na práci s modulem: Jednotlivé kapitoly tohoto modulu jsou zpřístupněny prostřednictvím záložek. Bližší vysvětlení některých zkratek a odborných termínů je dostupné pomocí hypertextového odkazu. Každá podkapitola má osnovu a stručnou anotaci.

Cíl modulu:

• Připomenutí a prohloubení znalostí z oblasti moderních technologií přepínaných lokálních sítí

• Seznámení s protokolem IP verze 6 a s důvody pro jeho nasazení

• Vysvětlení charakteristik a základních principů protokolů užívaných v současné době pro směrování v Internetu

• Seznámení s principy mechanismů skupinového vysílání a zajištění parametrů kvality služby pro implementaci provozu multimediálních aplikací v rozlehlé počítačové síti.

• Obeznámení s problematikou bezpečnosti počítačových sítí z pohledu ochrany přenášených dat i síťové infrastruktury

2 Modul 1: Počítačové sítě

1.1 Moderní technologie přepínaných lokálních sítí

1.1.1 Přepínání a přepínače Většina současných instalací lokálních sítích je založena na technologii Ethernet

s použitím přepínačů (angl. switch). Přepínače propojují stanice do hvězdicové topologie s tím, že jednotlivé hvězdy mohou být dále propojeny do stromu a za předpokladu použití algoritmu Spanning Tree pro dynamické zablokování smyček i do složitějších topologií s redundantními spoji.

1.1.1.1 Funkce přepínače Oproti rozbočovačům (angl. hub) přinášejí přepínače tu výhodu, že zavedením

vyrovnávacích pamětí eliminují kolize v síti a dovolují plně duplexní přenos na dvoubodových spojích mezi stanicí a přepínačem a přepínači navzájem. Přepínače také šetří přenosové pásmo tím, že podobně jako dříve mosty analyzují hlavičky procházejících rámců a posílají rámce selektivně na správně cílové porty, za kterými leží stanice s MAC adresou příjemce. V případě potřeby současného přenosu více rámců na tentýž výstupní port přepínače dočasně uloží rámce ve vyrovnávací paměti (bufferu). Na rozdíl od klasických mostů (bridge), což jsou více či méně specializované počítače, jsou přepínače realizovány hardwarově a dovolují současný průchod více rámců přepínačem, pokud procházejí mezi vzájemně různými dvojicemi portů.

Osnova: 1.1.1 Přepínání a přepínače

1.1.1.1 Funkce přepínače 1.1.1.2 Automatické učení přepínací tabulky

1.1.2 Virtuální lokální sítě 1.1.2.1 Trunk spoje a standard IEEE 802.1q 1.1.2.2 Přiřazování stanic do virtuální sítě 1.1.2.3 Další použití trunk spojů

1.1.3 Protokol Spanning Tree 1.1.3.1 Problém smyček v přepínané síti 1.1.3.2 Základní funkce protokolu Spanning Tree 1.1.3.3 Rapid Spanning Tree (IEEE 802.1w) 1.1.3.4 Spanning Tree v prostředí s virtuálními sítěmi

1.1.4 Přepínání na více vrstvách 1.1.4.1 Princip přepínání na více vrstvách 1.1.4.2 Modely použití VLAN v prostředí s přepínači na 3. vrstvě

Anotace: V této kapitole bude připomenuta základní funkce přepínače a přepínaných lokálních sítí a princip a použití virtuálních lokálních sítí (VLAN). Bude také vysvětlena potřeba implementace protokolu Spanning Tree a možnosti jeho použití v síti používající VLAN. Na závěr budou popsány některé mechanismy přepínání na více vrstvách.


1.1.1.2 Automatické učení přepínací tabulky Přepínač je zařízení, které není třeba nijak konfigurovat. Přepínací tabulky, které udržují

informaci, za kterým portem se nachází která MAC adresa, si totiž budují zcela automaticky z procházejících rámců. Kdykoli do přepínače vstoupí rámec, přepínač se podívá na MAC adresu zdroje a zaeviduje si, ze kterého portu rámec s touto adresou vstoupil. Jelikož aktivní topologie nesmí obsahovat smyčky, bude rámec od jisté pevně připojené stanice vstupovat vždy jediným konkrétním portem. Zaznamenanou informaci o portu, za kterým leží jistá MAC adresa, přepínač využije v okamžiku, kdy bude mít za úkol na správný port přeposlat rámec právě s touto cílovou MAC adresou.

Jestliže na přepínač dojde rámec s cílovou MAC adresou, který v přepínací tabulce doposud není, přepínač jej rozešle na všechny porty (což principiálně odpovídá chování rozbočovače). Tomuto rozeslání říkáme flooding (zaplavování). Přepínač bude posílat rámec s neznámou MAC adresou na všechny porty do té doby, než cílová stanice sama vyšle nějaký rámec, čímž přepínači prozradí, za kterým portem se ukrývá. V souvislosti s automatickým učením přepínací tabulky často mluvíme o samoučících nebo také transparentních mostech (přepínačích).

Aby si přepínač nemusel pamatovat MAC adresy všech stanic, které se v síti jedenkrát objevily a pak byly odpojeny (např. notebooky zákazníků apod.), udržuje se každá MAC adresa v přepínací tabulce jen po určitou dobu (typicky 3 minuty od okamžiku, kdy z dané MAC adresy přišel poslední rámec). Pokud měl uživatel stanici zapojenu v některém portu a následně ji přemístí do jiného, budou se rámce pro danou stanici posílat na původní port až do té doby, než stanice vyšle nový rámec se svou zdrojovou MAC adresu z nového portu. V tomto okamžiku se v přepínací tabulce ihned přepíše port, za kterým je daná stanice právě připojena a další provoz se již k této stanici bude posílat správně.

1.1.2 Virtuální lokální sítě Řada výrobců v posledních letech do přepínačů implementujte podporu tzv. virtuálních

sítí (virtual LAN, VLAN). Tento mechanismus dovolují rozdělit porty přepínače do skupin - virtuálních sítí (obr. 1.1a) s tím, že provoz může procházet vždy jen mezi porty téže skupiny (na obr. 1.1a zobrazené toutéž barvou).

Obr. 1.1a Přiřazení portů přepínače do virtuálních sítí

Pro každou virtuální síť si přepínač buduje a používá samostatnou přepínací tabulku. Přepínač je tak logicky rozdělen na více nezávislých logických přepínačů a to čistě na základě konfigurace přepínače, bez potřeby jakéhokoli fyzického přepojování (obr. 1.1b). Správce sítě tak získává možnost seskupování stanic do vzájemně nezávislých (virtuálních) sítí vzdáleně, zpravidla pomocí WWW rozhraní nebo Telnetu. Logická struktura sítě se tím stává nezávislou na fyzické topologii.


Obr. 1.1b Rozdělení přepínače na oddělené logické přepínače pro jednotlivé VLAN

1.1.2.1 Trunk spoje a standard IEEE 802.1q Pro praktické použití je často užitečné seskupit do společné virtuální sítě nejen porty

jediného přepínače, ale porty různých, vzájemně propojených přepínačů. Spoje mezi přepínači však v tomto případě musí nést současně provoz z více virtuálních sítí. Protože přepínač, na který došel rámec musí být schopen rozlišit, do jaké virtuální sítě příchozí rámec patří, je nutné na spojích mezi přepínači identifikovat příslušnost jednotlivých rámců k virtuální síti, ze které byl vyslány (obr. 1.2). K tomu se ke každému rámci připojuje zvláštní hlavička – tzv. značka (angl. tag). Spoje mezi přepínači, na kterých jsou rámce označovány značkou, jsou často nazývány „trunk“ linkami a musí být do tohoto režimu zpravidla explicitně konfigurovány. Jen některé modely přepínačů se (s použitím proprietárních protokolů) dokáží samy dohodnout, zda linka bude pracovat v režimu trunk nebo standardní.

Obr. 1.2 Indikace příslušnosti rámce k virtuální síti na trunk linkách

Je zřejmé, že na trunk spojích musí být rámce Ethernetu poněkud modifikovány, aby bylo kam uložit značku identifikující VLAN. V počátcích implementace virtuálních sítí do přepínačů jednotliví výrobci zaváděli svůj vlastní formát rámce rozšířeného o značku a tudíž nebylo možné trunk linkami propojovat zařízení různých výrobců. Později došlo ke standardizaci a dnes prakticky všichni výrobci podporují standard IEEE 802.1q, který používá standardního formátu rámce Ethernetu a přítomnost hlavičky obsahující číslo VLAN v rozsahu 0-4095 vložené na začátek datového pole rámce indikuje zvláštní hodnotou pole EtherType (obr. 1.3). Mimo čísla VLAN hlavička podle normy 802.1q může nést i prioritu rámce. Původní hodnota pole EtherType pak následuje za hlavičkou 802.1q.

Trunk linky

značka (tag)

B A

A B


Obr. 1.3 Rámec Ethernetu s hlavičkou 802.1q nesoucí identifikátor VLAN

Záhlaví podle IEEE 802.1q prodlužuje rámec o 2B. Hardware síťových karet, resp. portů přepínačů tak musí být schopny zpracovávat rámce s maximální délkou (MTU) o 2B vyšší, než definuje klasická norma Ethernetu.

Rámce vyslané na broadcast adresu nebo rámce, u kterých není přepínači znám port příjemce, jsou zaslány na všechny porty přepínače v téže VLAN a dále označkované na všechny trunk porty (obr. 1.4). Zde však dochází k situaci, kdy přes trunk linky k cílovému přepínači rámce putují rámce i z těch VLAN, do nichž není na přijímajícím přepínači zařazen žádný port. Proto přepínače některých výrobců implementují protokol pro prořezávání topologie jednotlivých VLAN, jímž se jednotlivé přímo propojené přepínače informují o číslech VLAN, do nichž mají připojení aktivní porty (obr. 1.5). Jedná se zpravidla o protokoly proprietární (např. Cisco VTP), bylo však již definováno i standardní řešení GVRP (GARP VLAN Registration Protocol ) na bázi IEEE protokolu Generic Attribute Registration Protocol (GARP) . V situacích, kdy jsou kombinována zařízení různých výrobců, která nepodporují shodný protokol dynamického prořezávání, je často možné filtrovat VLAN, která mají být propouštěny jednotlivými trunk linkami s použítím statické konfigurace (obr. 1.6).

Obr. 1.4 Rozeslání rámce po virtuální síti

Trunk linky


Obr. 1.5 Pořezávání topologie jednotlivých VLAN

Obr. 1.6 Statické omezení topologie VLAN

1.1.2.2 Přiřazování stanic do virtuální sítě Stanice mohou být do virtuálních sítí přiřazovány buďto staticky nebo dynamicky.

Statické přiřazení je založeno na statickém přiřazení jednotlivých portů přepínačů do VLAN a stanice je pak přiřazena do VLAN na základě toho, přes který port se do přepínače připojí. U dynamického přiřazování naopak nezáleží na tom, do kterého portu přepínače je stanice připojena a její přiřazení se děje na základě údajů z rámce, který do portu vstupuje – typicky podle zdrojové MAC adresy, ale lze (alespoň teoreticky) uvažovat i o přiřazení na základě IP adresy, protokolu nebo i údajů ze 4. vrstvy OSI RM, určujících aplikaci.

Z implementačních důvodů dynamické přiřazování stanic do VLAN typicky předpokládá, že na portu je připojena jen jediná stanice nebo je stanic i více, ale všechny mají být přiřazeny do téže VLAN. Pak stačí přepínači zjistit přiřazení stanice do VLAN jen při příchodu prvního rámce na port (obvykle jde o DHCP request), svázat tento port se zjištěnou VLAN a dále již pracovat stejným způsobem jako u statického přiřazení portu do VLAN. Přiřazení stanic do VLAN na základě MAC adresy se realizuje za použití databáze, která požadované mapování udržuje. V současné době bohužel neexistuje protokol, který by formát dotazu a odpovědi na přiřazení do VLAN standardizoval.

Obecně lze říci, že dynamické přiřazování do VLAN v dnešní době není běžné. Známá je hlavně implementace na přepínačích Cisco, které ke komunikaci se strojem udržujícím přiřazení stanic do VLAN používají proprietární protokol VLAN Query Protocol (VQP). Databázi mapování MAC adres do VLAN zde udržuje tzv. VLAN Membership Server (VMPS Server), který prostřednictvím VQP odpovídá na dotazy přepínačů -VMPS klientů- dynamicky zařazujících stanice do VLAN (obr. 1.7). Stanice, které nejdou v databázi

Žádný (aktivní) port přepínače není v červeném VLAN,ani sem rámce označené červeně neposílej (prořezání stromu)


explicitně uvedeny, je možné nechat přiřazovat do implicitní (default) VLAN. Poněkud nepříjemný je fakt, že zatímco funkci VMPS klienta mohou zastávat i nejnižší modely přepínačů Cisco, funkce VMPS serveru je implementována pouze ve vyšších a dražších modelech. To dosti omezuje použitelnost dynamického přiřazování stanic do VLAN v menších sítích, ve kterých vyšší modely Cisco přepínačů schopné provozovat VMPS server nejsou obvykle k dispozici. Toto však lze řešit např. použitím OpenVMPS – implementace VMPS serveru pro OS Linux [1]

Obr. 1.7 Přiřazování stanic do VLAN pomocí VMPS serveru

1.1.2.3 Další použití trunk spojů

Trunk linky nesoucí značkované rámce z různých VLAN nemusí vždy vést pouze mezi přepínači. Často však bývá užitečné trunk linku přivést i ke směrovači a umožnit směrování mezi VLAN s použitím směrovače s jediným rozhraním (obr. 1.8) – tzv. „router on the stick“, „router na tyči“. Výhodou tohoto přístupu je ušetření počtu rozhraní směrovače a lepší škálovatelnost, kdy počet požadovaných rozhraní směrovače neroste s počtem VLAN, mezi kterými má směrovač směrovat (viz „klasické“ řešení na obr. 1.9). Nevýhodou je naopak nižší propustnost, protože při směrování paketu mezi VLAN, musí paket vždy projít trunk linkou k routeru a pak (s jinou značkou VLAN) zpět k přepínači.

Obr. 1.8 Směrování mezi VLAN pomocí trunk portu směrovače („router on the stick“)

Uživatelské zařízení s danou MAC adresou (pošle např. DHCP request)

VMPS server

VMPS klient

Databáze přiřazení MAC adres do VLAN

(+ definice Default VLAN)

VLAN Query Protocol (VQP)


Obr.1.9 Klasické řešení směrování mezi VLAN

Další možností užitečnou možností použití je přivést trunk linku k serveru, který je vybaven kartou s podporou 802.1q (obr. 1.10). Operačnímu systému se pak tato síťová karta jeví jako více nezávislých logických síťových rozhraní, z nichž každé přísluší k jedné virtuální síti. Na jednom počítači tak může běžet více procesů svázaných s jednotlivými virtuálními sítěmi, což může být výhodné pro různé poskytovatele služeb.

Obr. 1.10 Přivedení trunk linky k serveru se síťovou kartou s podporou 802.1q

1.1.3 Protokol Spanning Tree

Princip samoučících se mostů předpokládá stromovou topologii. V praxi však často potřebujeme zapojit i redundantní linky, které v topologii sítě vytvoří smyčky. Na těchto smyčkách by však docházelo k nekonečné cirkulaci rámců, pročež musíme hledat způsoby, jak smyčky v topologii sítě eliminovat.

1.1.3.1 Problém smyček v přepínané síti Problém cirkulace rámců v topologii se smyčkami ukazuje názorně obr. 1.11. Uvažujme

dvě lokální sítě pro názornost ve sběrnicové topologii (místo sběrnic si můžeme představit i rozbočovač) propojené více než jedním přepínačem, čímž vzniká smyčka. Představme si nyní, že stanice A vyšle broadcast (ve skutečnosti by mohlo jít o rámec s libovolnou adresou, která není v přepínací tabulkách přepínačů). Vyslaný rámec každý přepínač kopíruje na všechny porty mimo příchozího. Oba přepínače tedy přenesou rámec na LAN2, na které se tak postupně objeví dvě kopie původního rámce od stanice A. Obě tyto kopie převezmou všechny přepínače na LAN2 mimo toho, který každou kopii vyslal (zde to bude druhý z přepínačů) a zašlou jej zpět na LAN1. Tím vznikne situace, kdy v síti budou donekonečna


protisměrně cirkulovat dva broadcast rámce.

LAN 1

LAN 2

Stanice A Obr. 1.11 Cirkulace rámců v topologii se smyčkami

V případě, že by obě LAN byly propojeny pomocí třech paralelních přepínačů, počet broadcast rámců v síti by dokonce neustále exponenciálně narůstal. Broadcast vyslaný ze stanice A by se totiž dostal na LAN2 každým ze třech přepínačů (pozdržený v bufferech, aby nedošlo ke kolizi), takže se na LAN2 objeví 3 kopie. Každá z těchto kopií vyslaná jedním ze tří přepínačů dorazí k ostatním dvěma, které ji přepošlou opět na LAN1, čímž z každé kopie na LAN2 vzniknou 2 kopie na LAN1, tedy celkově 6 rámců. V následných krocích vznikne 12 rámců, 24 rámců a tak dále až do úplného zahlcení přepínačů rámci, které budou donekonečna cirkulovat sítí.

Všimněme si, že přítomnost smyčky nejen vede k cirkulaci nebo generování kopií rámců, ale zcela nabourává i samotný princip automatického učení přepínací tabulky. Cirkulující rámce se zdrojovou adresou stanice A jednou přicházejí do přepínačů z LAN1 a jindy z LAN2, čímž si přepínače neustále střídavě a v polovině případů nesprávně podle portu příchozího rámce aktualizují informaci, za kterým portem je vlastně stanice A připojena.

Z uvedeného příkladu je vidět, že si smyčku v topologii nesmíme dovolit. Při správě sítě však smyčka může omylem při zapojování nebo i zlým úmyslem uživatele velmi snadno vzniknout. Také z praktických důvodů není obvykle vhodné konstruovat topologii sítě jako strom, ale poskytnout i redundantní linky pro případ výpadku a izolace některé větve. Proto musíme mít k dispozici mechanismus, který v topologii obsahující smyčky zablokuje některé porty přepínačů tak, aby výsledná topologie byla stromová. A právě takovýto mechanismus poskytuje protokol Spanning Tree, standardizovaný v normě IEEE 802.1d a podporovaný většinou přepínačů alespoň střední třídy.

1.1.3.2 Základní funkce protokolu Spanning Tree Algoritmus (resp. protokol) Spanning Tree má za úkol zkonstruovat a neustále udržovat

nad danou topologii přepínačů strom, který pokryje celou topologii – odtud také jeho anglický název. Je důležité si uvědomit, že linky tvořící smyčky nejsou blokovány z obou stran, ale vždy jen na jednom konci. Je tomu tak proto, že linka může být ve skutečnosti segmentem sítě, kde jsou připojeny stanice, které samozřejmě musí být do stromu také napojeny (viz obr. 1.12).


Obr. 1.12 Způsob blokování smyček v topologii

Je důležité, že algoritmus pracuje neustále - v případě výpadku linky nebo portu přepínače se strom automaticky přepočte (odblokuje se některý doposud zablokovaný port).

Konstrukce stromu se děje ve dvou krocích, které však probíhají neustále a současně:

1. volba kořenu stromu (root bridge),

2. vytvoření stromu nejkratších (nejlevnějších) cest z každého přepínače ke kořeni.

Kořen stromu se volí podle nakonfigurovaných priorit, v případě shody (např. pokud byla ponechána tovární nastavení) podle Bridge ID pevně přiděleného každému přepínači (má tvar MAC adresy). Priority přepínačů je obvykle vhodné konfigurovat tak, aby kořenem byl přepínač blízko směrovače do WAN nebo k serveru. Volba kořenového přepínače funguje tak, že každý přepínač ze začátku prohlásí za kořen sám sebe a vysílá o tom do svém okolí tzv. BPDU (Bridge Protocol Data Unit), které mj. obsahují nastavenou prioritu přepínače. Pokud přepínač přijme BPDU, ve kterém se za kořen prohlašuje přepínač s prioritou nižší, než má on sám, BPDU zahodí. V opačném případě BPDU rozešle do svého okolí a sám přestane BPDU generovat (podřídí se kořeni s lepší prioritou). Tímto způsobem po chvíli na síti zbude jediný přepínač generující BPDU – vybraný kořen stromu.

Při vytváření stromu nejkratších (nejlevnějších) cest z každého přepínače ke kořeni se bere v úvahu nakonfigurovaná preference (cena) jednotlivých linek. Pokud cena nebyla nastavena, implicitně se zpravidla počítá jako nepřímo úměrná přenosové rychlosti linky. Cena linky se konfiguruje zpravidla stejně na všech portech přepínačů připojených k lince (nebo segmentu sítě). Pokud by ceny portů na témže segmentu byly různé, počítal by se segment s různou cenou podle toho, na které straně segmentu by byl zvolený kořenový přepínač.

Porty, které jsou součástí vytvořeného stromu, budou funkční (forwarding), ostatní budou blokovány (blocking).

Technicky algoritmus funguje tak, že kořenový přepínač generuje co 2 sekundy zprávu BPDU, která se postupně šíří po topologii a při tom do sebe „sbírá“ sumární cenu linek, kterými už prošla. Když přepínač slyší BPDU z různých portů, vybere si tu z nich, ve které je menší sumární cena cesty ke kořeni a připojí se do stromu právě tímto portem (tzv. root port). Pokud by BPDU z root portu přestaly přicházet, znamená to výpadek v topologii a jako root port se zvolí ten, ze kterého přicházejí BPDU s nejnižší hodnotou sumární ceny cesty ke kořeni.

Z důvodu zabránění smyčkám během konvergence (přechodu na jiný strom) algoritmus definuje přechodné stavy portů Learning a Listening. Port ve stavu Listening nepřeposílá rámce, ale pouze po dobu 15 sekund sleduje okolní provoz, aby mohl rozhodnout, zda se

BLK


přepne do stavu Forwarding nebo Blocking. Před přechodem do stavu Forwarding se navíc 15 sekund ve stavu Learning bez přeposílání rámců pouze učí MAC adresy okolních stanic, aby se omezilo procento rámců, jejichž příjemce není v přepínací tabulce a musí být tudíž rozeslány na všechny porty.

S ohledem na skutečnost, že přepínač prohlásí původní cestu za nefunkční až ve chvíli, kdy z portu nepřicházejí po dobu 20 sekund BPDU, může po výpadku přechod na nový strom trvat až 50 sekund. To bylo naprosto dostačující v době před několika desetiletími, kdy standard 802.1d vznikal, avšak pro dnešní požadavky sítí přenášející multimédia již tato hodnota příliš uspokojivá není (a to ani ve srovnání s rychlostí konvergence sítí založených na směrovačích a moderních směrovacích protokolech).

1.1.3.3 Rapid Spanning Tree (IEEE 802.1w) Pro vyřešení neuspokojivé konvergence klasického protokolu Spanning Tree byl nově

navržen a postupně je implementován protokol Rapid Spanning Tree, jehož specifikaci lze najít v normě IEEE 802.1w. Od tohoto protokolu je očekáváno, že poskytne konvergenci v řádu jednotek sekund. To je zajištěno kompletní změnou filosofie oproti klasickému Spanning Tree (802.1d) založenému na časovačích. Rapid Spanning Tree je založen na reakci na oznamované události a na aktivních dotazech mezi sousedními přepínači, které vedou k rychlejšímu přechodu portů do stavu Forwarding. Další změnou je i to, že BPDU převzaly funkci dozoru nad funkčností linek (keepalives) a negeneruje je pouze kořenový, ale nezávisle každý přepínač. Také informace o změně topologie se již neposílá nejprve na kořenový přepínač a následně dolů po stromu, ale šíří se přímo z přepínače, který změnu topologie detekoval. Podle toho, zda je linka halfduplexní nebo fullduplexní rozlišuje Rapid Spanning Tree dva typy linek – dvoubodové a sdílené. Funkce algoritmu na dvoubodových linkách je jednodušší a tedy konvergence rychlejší.

Mimo uvedené změny principu zavádí Rapid Spanning Tree řadu vylepšení, které byly již jako rozšíření k dispozici i v některých implementacích standardního Spanning Tree, avšak nebyly obsaženy ve standardu. Jedná se zejména o možnost explicitního označení portu za hraniční (tzv. edge port), za kterým již není žádný přepínač, ale pouze koncová stanice a tak může být ihned po hardwarovém náběhu odblokován bez dalších testů. Jsou rovněž k dispozici mechanismy, které dovolují přepínači připojenému dvěmi redundantními linkami k přepínačům vyšší hierarchické úrovně bez čekání ve stavech Listening a Learning odblokovat redundantní linku ve velmi krátké době poté, co detekuje výpadek dříve aktivní linky,

1.1.3.4 Spanning Tree v prostředí s virtuálními sítěmi Zajímavým problémem je způsob aplikace protokolu Spanning Tree v prostředí

používajícím virtuální sítě. Jelikož virtuální sítě jsou na sobě vzájemně nezávislé a jsou logicky zcela odděleny, provozují se obvykle na jednotlivých VLAN nezávislé instance protokolu Spanning Tree. To dává možnost pro jednotlivé VLAN nastavit různé stromy a tím využít některé linky pro provoz určitých VLAN a jiné linky pro provoz jiných VLAN a tím zefektivnit využití infrastruktury. Je si však třeba uvědomit, že při velkém množství VLAN toto představuje značnou zátěž pro procesory jednotlivých přepínačů. Např. pro 500 VLAN a standardní časování vysílání BPDU co 2 sekundy v každé VLAN musí CPU každého přepínače za sekundu zpracovat 250 BPDU.


Opačný přístup, kdy bude pro všechny VLAN použito téhož stromu (tzv. Common Spanning Tree), navrhuje norma pro virtuální sítě IEEE 802.1q. V tomto případě běží pouze jedna instance Spanning Tree a to ve VLAN 1, jejíž výpočet se použije pro všechny VLAN. Zatížení procesorů přepínačů se tak minimalizuje, ale za cenu dosti neefektivního využití infrastruktury.

Kompromisní řešení definuje norma IEEE 802.1s (Multiple Spanning Tree nebo též Multi-Instance Spanning Tree), která dovoluje provozovat na síti několik nezávislých instancí (Rapid) Spanning Tree a pro jednotlivé VLAN definovat, od které instance převezmou strom určující zablokované a funkční porty.

1.1.4 Přepínání na více vrstvách V poslední době se často hovoří o přepínaní na třetí vrstvě či obecně o přepínání na více

vrstvách (multilayer switching, MLS). Principiálně se jedná o různé technologie, které mají za cíl urychlit hardwarovými prostředky směrování a přepínat pakety, resp. jednotlivé (jednosměrné) datové toky definované i parametry z vyšších vrstev (např. porty TCP/UDP) bez potřeby zpracování každého paketu procesorem a časově náročného procházení celé směrovací tabulky. Cílem je dosáhnout rychlosti přepínaných sítí, avšak využít při tom všech výhod škálovatelnosti sítí směrovaných. Technicky může být multilayer switching realizován různými způsoby, buďto formou specializovaného zařízení (tzv. L3 přepínače) integrujícího celou funkci nebo speciální vazby mezi přepínačem a směrovačem, dovolující přepínači na základě informace ze směrovače hardwarově přímo přepínat rámce i mezi porty různých segmentů (virtuálních sítí), mezi nimiž by normálně provoz musel procházet přes směrovač.

1.1.4.1 Princip přepínání na více vrstvách Prvotní implementace MLS byly realizovány jako vylepšení funkcionality přepínačů a

definice speciálního protokolu mezi přepínačem a směrovačem (obr. 1.13). Směrovač může být realizován buďto jako externí (s dodatečnou funkcionalitou pro MLS), nebo jako směrovací modul do modulárního přepínače. Protokol mezi přepínačem a směrovačem není bohužel standardizován, my jej zde (v souladu s implementací firmy Cisco) budeme označovat jako MLSP – Multilayer Switching Protocol.

Obr. 1.13 Způsob implementace MLS


Princip fungování MLS je následující. Směrovač nejprve pomocí speciální zprávy MLSP oznámí formou skupinového vysílání přepínači (resp. všem přepínačům, je-li jich vzájemně propojeno více) MAC adresy všech svých virtuálních rozhraní, jimiž jsou ke směrovači přivedeny jednotlivé VLAN. Na základě této informace může přepínač rozlišit, které rámce jsou připojenými zařízeními posílány na směrovač (typicky na výchozí bránu nakonfigurovanou na stanicích umístěných na jednotlivých VLAN) nebo naopak přicházejí (po přesměrování mezi VLAN) ze směrovače. Dále se u MLS předpokládá, že na určitou cílovou adresu (resp. i port TCP/UDP) typicky nebude zaslán pouze jeden paket, ale že první paket tvoří pouze začátek déle trvajícího datového toku. Přepínač se tak snaží ke každému prvnímu paketu toku jdoucímu na směrovač (tzv. candidate packet) najít odpovídající paket (tzv. enable packet) v některé jiné VLAN, do které byl candidate packet přesměrován. Candidate packet bude mít jako cílovou adresu MAC adresu virtuálního rozhraní směrovače pro některou VLAN, enable packet naopak ponese MAC adresu některého virtuálního rozhraní směrovače jako zdrojovou. Spárování candidate a enable paketu se samozřejmě nepodaří v případě, že odchozí candidate paket směrovač přesměroval mimo přepínanou doménu ven do páteře, resp. Internetu.

Při příchodu candidate paketu si přepínač vytvoří zárodek položky pro budoucí přímé přepínání dalších paketů toku. Uvede v něm MAC adresu zdroje, cílovou MAC adresu (adresu rozhraní směrovače) a kompletní hlavičku třetí a čtvrté vrstvy, podle kterých později nalezne enable paket. Při příchodu každého rámce z některé MAC adresy virtuálního rozhraní směrovače přepínač testuje, zda se nejedná o enable paket. Pokud se obsah hlaviček 3. a 4. vrstvy shoduje s informací uloženou v některém zárodku položky tabulky pro přímé přepínání, příslušná položka je doplněna o zdrojovou a cílovou MAC adresu z enable paketu a číslo VLAN, ze které enable paket přišel.

Pokud zárodek položky tabulky pro přímé přepínání není do určité doby dokončen, odešel patrně příslušný candidate paket pryč do páteře a zárodek je odstraněn.

Samotný multilayer switching pak pracuje tak, že každý rámec jdoucí na MAC adresu některého virtuálního rozhraní směrovače je testován, zda nevyhovuje některé položce tabulky pro přímé přepínání. V kladném případě je z této položky vyzvednuta zdrojová MAC adresa a VLAN odpovídající rozhraní směrovače, ze kterého odešel enable paket a MAC adresa cílové stanice. Tyto adresy v rámci přepíší původní MAC adresy, zmenší se pole TTL v IP hlavičce, přepočte se kontrolní součet záhlaví a rámec se pošle do příslušné VLAN. Přijímající stanice pak rámec vnímá jako by normálně prošel směrovačem.

Při testování shody paketů s položkami tabulky pro přímé přepínání běžně postačí shoda cílové IP adresy. Pouze v případě, že by na směrovači byly aplikovány paketové filtry (Access Control Lists, ACL), je nezbytné testovat i další položky, aby enable paket vyhovující ACL neotevřel možnost přímého průchodu i pro jiné toky na tutéž cílovou adresu, ale nevyhovující ACL (např. jdoucí z nepovolené zdrojové IP adresy nebo směřující na nepovolený TCP/UDP port). Proto v případě aplikace ACL na směrovači musí být tato skutečnost pomocí protokolu MLSP oznámena přepínači, který pak musí příslušnost paketu k toku a shodu s položkou tabulky pro přímé přepínání testovat důkladněji, tj. v závislosti na obsahu daného ACL i podle zdrojové IP adresy, protokolu 4. vrstvy nebo zdrojového a cílového portu 4. vrstvy.

Nevýhodou uvedeného mechanismu je skutečnost, že při jakékoli změně směrovací tabulky nebo úpravě ACL na směrovači musí být tabulka pro přímé přepínání na přepínači (resp. všech přepínačích, je-li jich více) kompletně vymazána. Požadavek na vymazání je přepínačům distribuován pomocí protokolu MLSP.

Pro úplnost poznamenejme, že směrovač nutně nemusí být k přepínači připojen pouze


trunk linkou, ale jeho jednotlivé VLAN mohou být připojeny k normálním rozhraním směrovače. V takovémto případě musí MLSP propagovat MAC adresy všech rozhraní, které slouží pro přesměrovávání mezi VLAN účastnícími se mechanismu multilayer switchingu.

Druhým typickým způsobem realizace přepínání na více vrstvách je L3 přepínač. Obecně jde o integrované řešení přepínače a směrovače s maximem přepínacích funkcí realizovaným hardwarovými prostředky a současně s plnou funkcionalitou směrovače provozujícího software implementující dynamické směrovací protokoly. Konkrétní technická realizace může být různá a v úplnosti téměř nikdy není výrobcem zveřejněna. A pohledu konfigurace se L3 přepínač jeví jako standardní přepínač podporující VLAN a směrování mezi nimi. Jehož jednotlivé porty mohou být navíc přepnuty do režimu směrovaných portů. Logicky se pak L3 přepínač může jevit jako virtuální topologie podobná té na obr. 1.14. Výhodou je nejen rychlost, ale i velká flexibilita konfigurace takového zařízení. Oproti standardním směrovačům však postrádá WAN rozhraní, všechna rozhraní jsou z důvodu realizovatelnosti maxima funkcí v hardware stejná (typicky Ethernet). Množství rozhraní zpravidla odpovídá přepínači, tj. je výrazně vyšší, než u klasického směrovače (typicky např. 24).

Obr. 1.14 Logická struktura L3 přepínače

1.1.4.2 Modely použití VLAN v prostředí s přepínači na 3. vrstvě S nástupem L3 přepínačů se poněkud mění filosofie používání VLAN v rozsáhlejších

lokálních sítích. Ukázalo se, že rozsáhlé VLAN pokrývající celou topologii nejsou efektivní jedna z důvodu nižší stability protokolu Spanning Tree (ten je dimenzován na průměr grafu sítě max 7 přepínačů) a jednak proto, že není možné využít rozkládání zátěže (load balancing) mezi redundantní spoje v topologii. Proto je dnes tendence využívat VLAN spíše jen v okrajových částech lokální sítě a v částech blíže páteře raději aplikovat rychlé L3 přepínače, poskytující všechny výhody směrování za cenu stále více se blížící ceně kvalitních L2 přepínačů.


KONTROLNÍ OTÁZKY • Vysvětlete princip automatického učení přepínací tabulky přepínače • Vysvětlete pojem a použití virtuální lokální sítě. K čemu slouží trunk spoj mezi

přepínači a mezi přepínačem a serverem ? • Podle čeho mohou být stanice připojené k přepínači zařazovány do správné virtuální

sítě? • Jak lze realizovat směrování mezi virtuálními sítěmi? • Vysvětlete smysl a princip funkce protokolu Spanning Tree. • Jaké znáte možnosti aplikace protokolu Spanning Tree v prostředí s virtuálními sítěmi?• Vysvětlete funkci přepínání na více vrstvách (Multilayer Switching) a možnosti použití

L3 přepínače.


1.2 Protokol IP verze 6

1.2.1 Nedostatky protokolu IPv4 Donedávna byl provoz v Internetu na úrovni síťové vrstvy zajišťován výhradně

protokolem IP verze 4 (IPv4) definovaným v RFC791. Tento protokol je již po mnoho let provozován pouze s minimálními změnami1. Díky masovému nárůstu počtu připojených zařízení (včetně zařízení jako PDA, mobilní telefony či výrobky spotřební elektroniky) se však koncem devadesátých let ukázalo, že přestává dostačovat původně navržený prostor IP adres. Zejména se ukázal omezující způsob dělení tohoto prostoru na třídy A,B a C, který neodpovídá současné realitě velmi variabilního počtu stanic v jednotlivých nově připojovaných sítích. Ačkoli byl před časem velmi ožehavý problém nedostatku IP adres dočasně vyřešen zrušením tříd a přidělováním délek prefixů sítí podle reálné potřeby a hlavně obecným rozšířením využívání privátních adres překládaných na malý počet veřejných pomocí mechanismu NAT (Network Address Translator), není toto řešení výhodné proto, že neumožňuje univerzální komunikaci a jednoznačnou adresovatelnost všech do Internetu připojitelných zařízení. Právě s cílem vyřešit problém nedostatku adres byl v roce 1995 navržen protokol IP verze 62).

1 např. upřesnění významu pole Type of Service v hlavičce IP paketu 2 protokol IP verze 5 existoval pouze ve verzi experimentální

Anotace: Tato kapitola seznámí čtenáře s protokolem IP verze 6 a s důvody k jeho nasazení. Budou vysvětleny základní změny a rozšíření oproti IP verze 4, zmíněny protokoly pro směrování IPv6 a zhodnoceny možnosti podpory IPv6 v současných systémech včetně předpokládaných způsobů migrace na tento protokol.

Osnova: 1.2.1 Nedostatky protokolu IPv4 1.2.2 Adresování v IPv6

1.2.2.1 Typy adres v IPv6 1.2.2.2 Zápis adres 1.2.2.3 Automatická konfigurace

1.2.3 Paket IPv6 1.2.3.1 Hlavička paketu 1.2.3.2 Řetězení hlaviček

1.2.4 Podpůrné protokoly IPv6 1.2.4.1 ICMPv6 1.2.4.2 DNS a IPv6 adresy

1.2.5 Pokročilé vlastnosti protokolu IPv6 1.2.5.1 Bezpečnost 1.2.5.2 Mobilita 1.2.5.3 Podpora zabezpečení kvality služby

1.2.6 Směrování a protokol IPv6 1.2.7 Současný stav podpory protokolu IPv6

1.2.7.1 Možnosti přechodu z protokolu IPv4


Jelikož je návrh a zejména široká implementace nového protokolu síťové vrstvy pro prostředí Internetu záležitostí, která se děje jen velmi zřídka, bylo rozhodnuto změny využít a do protokolu zapracovat také další rozšíření, umožňující řešit aktuální požadavky na protokol, se kterými návrháři IPv4 původně nepočítali. Jedná se zejména o následující vylepšení:

• možnost automatické konfigurace adres na základě adres spojové vrstvy (MAC adres) a prefixu získaného od směrovače na dané LAN,

• podpora šifrování a autentizace,

• podpora pro mobilitu komunikujících stanic,

• rozšířená podpora skupinového vysílání (multicast),

• podpora QoS.

Přechod na nový protokol není uskutečnitelný ze dne na den a to nejen z organizačních důvodů. V Internetu pracuje velké množství hardware, který IPv6 nepodporuje a nikdy podporovat nebude. Proto se předpokládá několikaletá koexistence obou protokolů a byly navrženy mechanismy, jak současné používání obou těchto protokolů realizovat.

1.2.2 Adresování v IPv6 Při návrhu adresního schématu protokolu IPv6 se autoři poučili z problémů, které

přinesly v posledních letech adresy IPv4 a z řešení, jimiž internetová komunita alespoň některé nedostatky obešla. Nedostatek adres byl v IPv6 pravděpodobně jednou pro vždy vyřešen čtyřnásobným prodloužením IP adresy (ta má nyní 16 bajtů) a zavedením víceúrovňové hierarchické struktury adres, která umožní při jejich rozumném přidělování dobrou agregovatelnost směrovacích záznamů v páteřních směrovačích. Mimo běžných individuálních (unicast) adres IPv6 rovněž rozšiřuje užití adres skupinových (multicast) a zavádí nový speciální typ adresy, tzv. anycast (česky někdy nazývané jako "výběrové adresy"). Jednotlivé třídy adres se odlišují prefixem - nejvýznamnějšími bity adresy.

1.2.2.1 Typy adres v IPv6 Individuální adresy jsou v terminologii IPv6 plným jménem nazývány agregovatelné

globální unicast adresy. Standardem RFC2374 původně navrhovaná struktura globální individuální adresy IPv6 se skládala z těchto částí:

• prefix 001 - – příznak, že jde o globální individuální adresu,

• Top-Level Aggregation (TLA) - identifikátor autority přidělující adresu,

• Next-Level Aggregation (NLA) – identifikátor ISP,

• Site-Level Aggregation (SLA) – „podsíť“ v rámci instituce,

• Identifikátor rozhraní (64 bitů) - obvykle bývá zkonstruován dále popisovaným způsobem na základě MAC adresy příslušného rozhraní. To umožňuje automatickou konfiguraci adresy rozhraní bez explicitního zásahu správce.

Délky polí TLA a NLA nebyly pevně určeny, ale byla mezi nimi ponechána rezerva dovolující rozšířit kterékoli z nich podle potřeb praxe. Dvouúrovňový hierarchický systém se však příliš neujal, protože nekopíruje realitu v rozdělování adres mezi poskytovatele, která je


velmi různorodá. Proto bylo později od formálního rozdělení na TLA a NLA upuštěno a v současné době se v rámci „veřejné infrastruktury“ přidělují prefixy síťové adresy odpovídající délky podle potřeby.

Podstatné je, že pro směrovače není vnitřní struktura adresy tak jako tak zajímavá - orientují se pouze podle prefixu a jeho délky s tím, že paket je přeposílán na základě řádku směrovací tabulky, u kterého se prefix shoduje s prefixem cílové adresy paketu na co největší počet míst.

V obecné struktuře IPv6 adresy bylo pro identifikátor rozhraní vyhrazeno 64 bitů. Ačkoli adresu rozhraní lze obecně nastavit jakkoli, je výhodné ji převzít z MAC adresy, která sama o sobě je již unikátní a na spojové vrstvě využívána většinou současných síťových technologií. Pro identifikátor rozhraní se používá mírně modifikovanému standardu IEEE EUI-64, definujícího celosvětově jednoznačné 64-bitové identifikátory pro síťová rozhraní. Převod MAC adresy na EUI-64 spočívá ve vložené hodnoty FFFEh mezi třetí a čtvrtý bajt (tedy doprostřed) MAC adresy. Mimo to je třeba invertovat příznak globality - ten je u MAC adres umístěn stejně jako v EUI-64 jako druhý nejméně významný bit nejvyššího bajtu, avšak s opačnou logikou). Například z MAC adresy 00:CC:01:A1:D5:80 tak vznikne identifikátor rozhraní s hodnotou 02CC:01FF:FEA1:D5803.

Mimo globálních individuálních adres definuje IPv6 také tzv. lokální individuální linkové adresy (prefix FE80::/10 doplněný zprava o MAC adresu), které mají platnost pouze v rámci lokálního segmentu a používají se pro vysílání paketů některých podpůrných protokolů. Také existuje obdoba privátních adres známých z IPv4, tzv. lokální individuální místní (angl. „site“) adresy začínající prefixem FEC0::/10.

Dalším zajímavým rozšířením u protokolu IPv6 je skutečnost, že rozhraní může mít více globálních individuálních adres (tzv. multihoming). To je užitečné např. během přeadresování sítě při přechodu k jinému poskytovateli.

Adresy typu multicast (skupinové) slouží pro aplikace, které chtějí zajistit doručení paketu celé skupině příjemců (např. rozhlasové či televizní vysílání po Internetu). Obecná struktura adresy typu multicast vypadá u IPv6 následovně:

• FF00:/8 – prefix skupinové adresy,

• příznaky (4b),

• identifikátor dosahu (4b),

• identifikátor skupiny (112b).

Dosah skupiny určuje oblast, v rámci níž mohou být příjemci dané skupiny rozprostřeni (lokální linka, místo, organizace, globální dosah). Skupiny v IPv6 se dále dělí na obecně známé permanentní (well-known) a dočasné (transient). Lze to rozeznat podle jednoho z příznakových bitů. Identifikátory permanentní skupiny jsou plošně (tj. nehierarchicky) přidělovány organizací IANA a jsou nezávislé na dosahu - bez ohledu na dosah vždy identifikují tutéž skupinu. Naopak identifikátory u adres transientních skupin jsou vždy unikátní pouze v rámci svého dosahu. Stejný identifikátor v rámci dvou různých tranzientních skupinových adres lišících se pouze dosahem tak vždy označuje různé skupiny. Problém

3 Všimněme si, že narozdíl od IPv4 můžeme při takovémto způsobu konstrukce identifikátoru rozhraní z IP adresy u IPv6 vyčíst celosvětově jednoznačnou identifikaci fyzického zařízení, se kterým komunikujeme. Jelikož toto může být vnímáno jako zásah do soukromí uživatelů, byly navrženy způsoby, jak s použitím dynamického generování střídavě používaných alternativních adres možnosti identifikace konkrétního zařízení zamezit.


přidělování jednoznačných multicastových adres navrhuje IPv6 řešit také na základě adres odvozených z přidělených prefixů adres individuálních (tzv. unicast-prefix-based adresy).

Ačkoli má pole identifikátoru skupiny délku 112 bitů, v současné době se předpokládá použití pouze nejnižších 32 z nich (zbývajících bity jsou nulové). Ty pak lze snadno mapovat na šestibajtové MAC adresy - první dva bajty multicastových MAC adres nesoucích pakety IPv6 pro skupinovou adresu mají hodnotu 3333h, zatímco zbývající čtyři jsou přímo zkopírovány z 32-bitového identifikátoru skupiny. Tím bylo dosaženo jednoznačnosti mapování skupinových adres IPv6 na MAC adresy, které bylo u protokolu IPv4 víceznačné.

Nově zavedeny byly tzv. výběrové adresy, nebo-li adresy adresy typu anycast. Výběrová adresa může být přiřazena několika různým fyzickým rozhraním a to i rozprostřeným v rámci WAN. Pakety zaslané na adresu anycast jsou doručeny některému (nejbližšímu) rozhraní s touto adresou. Smyslem je zajistit vyhledání nejbližšího člena nějaké skupiny (např. proxy DNS serverů). Takovéto mechanismy mohou být užitečné pro automatické vyhledávání různých služeb nebo pro rozkládání zátěže mezi redundantní servery. Směrování na adresy typu anycast může být zajištěno propagováním této adresy ("host route") z několika zdrojů. V současné době jsou mechanismy související s využitím adres typu anycast spíše ve stádiu experimentálním a to zejména kvůli nevyjasněnosti některých aspektů bezpečnosti a návaznosti na vyšší vrstvy a protokoly stavového charakteru, zejména použití spolu s protokolem TCP.

Adresy typu anycast nemají speciální prefix, jsou totiž zařazeny pod stejný prefix, jako adresy individuální. Z pohledu na adresy tak není možné rozhodnout, zda se jedná o adresu individuální nebo anycast.

Všimněme si rozdílu skupinových adres oproti adresám výběrovým. Zatímco paket zaslaný na výběrovou adresu má být doručen některému členu skupiny, paket zaslaný na adresy skupinovou je určen pro všechny členy skupiny. Také si všimněme, že IPv6 zcela vypustila adresu typu broadcast. Její dosah byl u IPv4 totiž reálně omezen na jeden segment sítě, takže se ukázalo vhodnější nahradit ji pro každý jednotlivý způsob použití samostatnou adresou typu multicast s příslušným dosahem.

1.2.2.2 Zápis adres Adresy IPv6 mají 128 bitů, tedy 16 bajtů. Zapisujeme je na rozdíl od IPv4

v hexadecimálním tvaru, vždy po dvojicích bajtů oddělených dvojtečkami, například FEDC:02A5:0000:002A:00C0:7600:0C12:1C47.

Nevýznamné (úvodní) nuly každé čtveřice můžeme z výše uvedeného zápisu vypustit a adresu zapsat jako FEDC:2A5:0:2A:C0:7600:C12:1C47. Jelikož často bývá delší část adresy nulová, můžeme více následných nulových bitů vyjádřit symbolem "::". Například adresu FEDC:02A5:0000:0000:00C0:7600:0C12:1C47 můžeme zkrátit na FEDC:2A5::C0:7600:C12:1C47. Použili jsme zde navíc možnost vypustit nevýznamné úvodní nuly. Zápis "::" se může vyskytovat i na začátku nebo konci adresy, např. ::FE12:CCD0 nebo DC80:FD87:A800:: Dvě dvojtečky na začátku adresy využijeme zejména u tzv. IPv4-kompatibilních adres (viz dále); dvě dvojtečky na konci zase při zápisu prefixu, kde nevýznamné pozice v pravé části adresy jsou všechny nulové. Všimněme si, že z důvodu jednoznačnosti se zápis "::" může v adrese objevit pouze jednou. Např. adresu FD08:0000:0000:DAC8:0000:0000:0000:DACD můžeme zapsat jako FD08::DAC8:0000:0000:0000:DACD nebo FD08:0000:0000:DAC8::DACD. Kdybychom použili (nesprávného) zápisu FD08::DAC8::DACD, nebyla by adresa jednoznačná, jelikož by ze zápisu nebylo zřejmé, kolik nulových pozic reprezentuje první a kolik druhý výskyt


symbolu "::".

Poslední variantou, jak vyjádřit adresu IPv6, je zápis tzv. IPv4-kompatibilních adres. Ty byly zavedeny z důvodu koexistence s adresami IPv4. IPv4-kompatibilní adresy mají prefix 0:0:0:0:0:0, poslední dvě čtveřice hexadecimálních číslic se však zapisují jako čtyři dekadické hodnoty bajtů adresy IPv4 oddělených tečkami. Například 0:0:0:0:0:0:158.196.1.10.

Často potřebujeme vyjádřit také prefix adresy. Počet bitů tvořících prefix zapisujeme za lomítko za hodnotu prefixu, zapsanou podle konvencí zápisu adres IPv6. Jedná se o stejný zápis, na jaký jsme již zvyklí z beztřídního adresování u IPv4 (CIDR). Například 60-bitový prefix s hodnotou AAAABBBBCCCCDDDh zapíšeme AAAA:BBBB:CCCC:DDD0::/60 Zápisem "::" na konci prefixu dáváme najevo, že zbývající bity adresy jsou z pohledu prefixu nevýznamné, a mohou být stejně jako při označování sítí jako takových u adres protokolu IPv4 chápány jako nulové. Adresa ::0/128 je používána jako tzv. nedefinovaná adresa. Používá se pro vyjádření faktu, že adresa nějakého rozhraní doposud nebyla přiřazena. Adresa ::1/128 je představuje zpětnovazební smyčku (loopback) a odpovídá adrese 127.0.0.1 používané pro tento účel u IPv4.

1.2.2.3 Automatická konfigurace Při návrhu IPv6 byl kladen důraz na to, aby uživatelé při připojení do sítě nemuseli

pokud možno nic nastavovat a aby jim všechny potřebné parametry pro síťovou komunikaci byly přiděleny automaticky službami v sítí. K tomu účelu IPv6 nabízí dvě možnosti – tzv. stavovou a bezestavovou automatickou konfiguraci.

Stavová konfigurace předpokládá zprovoznění speciálního serveru, který parametry připojení na žádost přiděluje. Jde o stejný princip jako u známého protokolu DHCP (Dynamic Host Configuration Protocol, RFC2131), hojně používaného v IPv4. Protokol DHCPv6, určený pro přidělování parametrů v IPv6 má oproti klasickému DHCP některá rozšíření, avšak princip zůstává stejný – stanice nejprve s použitím skupinové adresy vyhledá DHCP server, který ji nabídne na určitou dobu pronájem jisté síťové adresy a spolu s ní další parametry, jako výchozí bránu a adresu DNS serveru. Stanice si jednu z nabídek vybere a s DHCP serverem, který tuto adresu nabídnul, si požadavek na přidělení vzájemně potvrdí.

Je pamatováno i na případ, kdy chceme jednomu fyzickému zařízení přidělovat pokaždé tutéž adresu – na rozdíl od standardního DHCP však nejsou stanice jednoznačně identifikovány pouze MAC adresou (síťová karta může být vyměněna), ale jsou navrženy i jiné identifikátory odvozené z různých forem jednoznačné identifikace hardware konkrétních stanic.

DHCP server musí být s klienty na témže segmentu, avšak specifikace DHCPv6 pamatuje i na přeposílání požadavků přes prostředníka (proxy). Oproti DHCP pro IPv4 si může v DHCPv6 server aktivně vynutit, aby klient změnil parametry, které mu server předtím přidělil.

Druhou alternativou dynamického přidělování adres v IPv6 je bezestavová konfigurace. Ta nevyžaduje DHCP servery, ale vychází z toho, že stanice si svou adresu zkonstruuje ze své MAC adresy a prefixu lokální sítě, kterou periodicky ohlašuje směrovač na všech rozhraních svých LAN. K tomu se používá zpráva protokolu ICMPv6 Router Advertisement. Směrovač pak rovněž stanici poslouží jako výchozí brána. Pokud stanice nechce čekat celou periodu na zprávu ICMPv6 Router Advertisement, může si její okamžité zaslání všemi směrovači na segmentu vyžádat zprávou ICMPv6 Router Solicitation na skupinovou adresu pro všechny směrovače.


1.2.3 Paket IPv6 1.2.3.1 Hlavička paketu

Podíváme-li se na základní formát paketu protokolu IPv6, vidíme, že je oproti paketu IPv4 značně zjednodušen (obr. 1.15). Stejně jako u IPv4 je tvořen hlavičkou a datovou částí, která však může mít délku až 4GB (tzv. Jumbo Packet). Připomeňme, že pakety IPv4 mohou mít délku maximálně 64kB. Hlavička paketu IPv6 byla oproti IPv4 zjednodušena. Mnohá pole byla vypuštěna, některá však také pozměněna nebo i přidána. Zjednodušení hlavičky má za cíl urychlit zpracování paketů, které nevyžadují žádné speciální zacházení. Takovýchto paketů se v síti pohybuje nejvíce. Pakety, které speciální zacházení vyžadují, si k tomu účelu nesou přídavnou informaci ve volitelných rozšiřujících hlavičkách, které se mohou jedna za druhou řetězit. K rozšiřujícím hlavičkám i mechanismu řetězení se vrátíme později.

Obr. 1.15 Srovnání hlaviček IPv6 a IPv4

Nejdůležitější části základní hlavičky IPv6 je zdrojová a cílová IP adresa. Ty byly v protokolu IPv6 rozšířeny na 16 bajtů. Dále je přítomné pole odpovídající poli Time to Live u protokolu IPv4, kterému však byl upraven název s ohledem na způsob, jakým je pole skutečně využíváno (dekrementace hodnoty při každém průchodu směrovačem a likvidace pravděpodobně cyklujícího paketu v případě dosažení nulové hodnoty).

Novým polem hlavičky je pole Next Header. To umožňuje za popisovanou základní hlavičku volitelně připojit hlavičky další a základní hlavičku minimalizovat (viz kap. 1.2.3.2). Vypuštěním polí, která nejsou u konkrétního paketu využita, se sníží režie a zrychlí zpracování paketů ve směrovačích. Další zrychlení přináší vypuštění kontrolního součtu hlavičky, který se tak nemusí při předávání paketu neustále přepočítávat. Předpokládá se,


že zabezpečení zajistí spojová vrstva, nebo vrstvy vyšší.

Dále byla zavedena položka Flow Label. Její použití není doposud přesně specifikováno, ale předpokládá se, že pomůže omezit opakované pomalé a někdy i rekurzivní vyhledávání ve směrovacích tabulkách pro pakety jednoho datového toku. Datovým tokem zde rozumíme posloupnost paketů na některém transportním protokolu (TCP/UDP), vycházející z jisté zdrojové aplikace dané zdrojovou adresou a portem a směřující do cílové aplikace, opět identifikované IP adresou a portem. Podrobněji je předpokládané použití položky Flow Label vysvětleno v kapitole 1.2.5.3.

1.2.3.2 Řetězení hlaviček Aby v hlavičkách paketu nebylo nutné rezervovat pole na pomocné mechanismy jako

např. fragmentaci, nebo volby, které nemusí být zdaleka vždy použity, byl zaveden princip řetězení hlaviček. Za základní hlavičkou může následovat jedna nebo více tzv. rozšiřujících hlaviček, z nichž každá je chápána jako samostatný blok nesoucí informace týkající se jednoho z rozšiřujících mechanismů. Řetěz obsahuje pouze hlavičky, které jsou v daném paketu nutné. V současné době jsou definovány tyto hlavičky:

• Volby pro všechny/volby pro cíl - jedná se o standardní nepovinné volby známé z protokolu IPv4. V IPv6 však byly rozšířeny na volby pro cíl a volby pro všechny prvky na cestě, aby se prvky na cestě nemusely zabývat prohledáváním voleb, které pro ně nejsou určeny.

• Explicitní směrování – stejně jako v IPv4 lze u paketu určit, přes které směrovače má procházet a to buďto striktním vyjmenováním jednoznačné sekvence směrovačů nebo volným určením jen několika z nich.

• Fragmentace – hlavička nesoucí informace, podle kterých lze složit fragmenty původně jediného paketu, který však musel být z důvodu malého MTU u odesílatele fragmentován na větší počet menších paketů (fragmentů). Je důležité vědět, že IPv6 nedovoluje z důvodu šetření výkonu fragmentaci na směrovačích, kvůli kompatibilitě se softwarem počítajícím s IPv4 však umožňuje fragmentovat alespoň odesílateli.

• Autentizace odesílatele.

• Šifrování obsahu.

• Mobilita – hlavička nesoucí informace týkající se komunikace s uzly, které mají svou původní IP adresu, avšak právě hostují v cizí síti.

Propojení hlaviček se děje pomocí pole “Další hlavička”, umístěném jednak v základní hlavičce a jednak na pevné pozici v každé z rozšiřujících hlaviček. V poli Další hlavička je vždy uveden typ rozšiřující hlavičky, která bude následovat (formou pevně definovaných kódů rozšiřujících hlaviček). Protože rozšiřující hlavičky mohou mít různou délku, je na pevné pozici na začátku každé z nich uvedena její délka, takže i při zpracování neznámých hlaviček je vždy zřejmé, kde začíná hlavička další. U poslední rozšiřující hlavičky (nebo přímo v základní hlavičce, pokud paket rozšiřující hlavičky nemá) je uveden kód protokolu 4. vrstvy stejně, jako tomu bývalo v poli Protocol hlavičky IPv4. Bližší popis mechanismu řetězení a detailní strukturu nejpoužívanějších rozšiřujících hlaviček lze nalézt např. v [3].


1.2.4 Podpůrné protokoly IPv6 1.2.4.1 ICMPv6

Protokol IPv4 používá ke své funkci dva pomocné (služební) protokoly: ARP a ICMP. Protokol ARP (Address Resolution Protocol, RFC826) slouží k mapování IP adres na adresy spojové vrstvy (MAC adresy); protokol ICMP (Internet Control Message Protocol, RFC792) informuje o zvláštních stavech během šíření paketu sítí. Pro použití v souvislosti s protokolem IPv6 byly oba zmíněné protokoly modifikovány a sloučeny do jediného protokolu ICMPv6.

1.2.4.2 DNS a IPv6 adresy Zatímco adresy IPv4 byli správcové a dokonce i někteří uživatelé schopni si

zapamatovat, u šestnáctibajtových adres IPv6 je to již velmi problematické. O to důležitější je mít možnost používat doménová jména a mapovat je na IPv6 adresy pomocí systému DNS. Pro mapování doménového jména na IPv6 adresu byl nově zaveden záznam AAAA (označení vyjadřuje fakt, že IPv6 adresa je čtyřikrát delší než IPv4 adresa uváděná v klasických A záznamech). Pro mapování IPv6 adresy na doménové jméno se používá osvědčená konstrukce se záznamem typu PTR, kdy se jednotlivé hexadecimální číslice IPv6 adresy zapíší zprava doleva a za tento zápis se připojí doména ip6.arpa.

Během vývoje se také objevily záznamy typu A6 a DNAME, umožňující snadnější změnu adresace, resp. lepší delegování provádění změn jak pro dopředné tak reverzní dotazy. V praxi se však jejich používání nevžilo. Podrobnější informaci o těchto typech záznamů lze nalézt např. v [2].

1.2.5 Pokročilé vlastnosti protokolu IPv6 1.2.5.1 Bezpečnost

Data přenášena původním protokolem IPv4 nebyla nijak šifrována ani autentizovována. To znamená, že si data na cestě mohl nejen kdokoli přečíst, ale také je pozměnit nebo dokonce podvrhnout vyslání dat z nějaké IP adresy, aniž by se o tom příjemce mohl dozvědět. Proto byly postupně vyvíjeny různé mechanismy, jak data šifrovat, zajistit jejich integritu (tj. zabránit modifikaci na cestě) a autentizovat zdroj dat, tedy ověřit zda data skutečně vyslat zdroj, který to o sobě v paketu tvrdí. Pro účely zabezpečení na síťové vrstvě OSI modelu je v současné době v prostředí IPv4 de facto standardem protokol IPSec (kap. 1.5.3.2.1), který je volitelným doplňkem IPv4. Protokol IPv6 standard IPSec integruje a předepisuje jeho implementaci jako povinnou (což se však bohužel dnes u mnohých implementací stále neděje). Protože mechanismy zajištění bezpečnosti u IPv6 jsou prakticky totožné jako u standardu IPSec, odkazujeme čtenáře na kapitolu 1.5.3.2.1, kde jsou jeho principy popsány detailněji.

1.2.5.2 Mobilita V dnešní době je vcelku běžné, že uživatel může (po více či méně silné autentizaci)

připojovat své mobilní zařízení postupně do různých sítí podle toho, jak se s tímto zařízením pohybuje. Nicméně protože adresace v protokolu IP má hierarchický charakter (adresa sítě-adresa uzlu), není možné, aby si zařízení ponechalo stále tutéž adresu – její síťová část musí odpovídat adrese sítě, do které je právě připojeno. V mnoha případech, kdy uživatel zařízení


chce vystupovat jen jako klient síťových služeb, toto není problémem. Zařízení si pouze vyžádá při připojení do sítě pronájem vhodné adresy protokolem DHCP a z pohledu uživatele vše funguje automaticky. Jiná situace však nastává, když má být mobilní zařízení serverem a jako takové být neustále dostupné pod jednou a toutéž IP adresou, registrovanou v DNS pod určitým všeobecně známým doménovým jménem.

Uvedený případ lze řešit právě s podporou technologie Mobile IP, která je na rozdíl od protokolu IPv4, kde je poskytována formou dodatečného rozšíření (viz RFC3220), do IPv6 přímo vestavěna (RFC3775). Princip spočívá v tom, že aktuální polohu každého mobilního uzlu neustále sleduje jeden ze směrovačů v síti, kam mobilní uzel patří, když uživatel není na cestách (tzv. domácí síť). Tento pověřený směrovač se nazývá Domácí agent (Home Agent, HA). Jestliže se mobilní stanice přesune do cizí sítě, zaregistruje u svého domácího agenta adresu, pod kterou bude po dobu pobytu v této cizí síti dostupná. Tato adresa je označována jako Care-Of Address (CoA). Domácí agent pak všechny pakety došlé na adresu stanice, která právě dočasně hostuje v cizí síti, přeposílá na zaregistrovanou adresu CoA (obr. 1.16). Odpovědi mobilní stanice partnerovi, který s ní komunikuje (tzv. correspondent node), již samozřejmě jdou přímou cestou. Existuje zde také možnost, aby mobilní stanice v cizí síti sdělila svému partnerovi pomocí speciální volby svou dočasnou CoA adresu a partner pak posílal všechny pakety přímo na ní s použitím hlavičky explicitního směrování. Před entitami transportní vrstvy však musí zůstat veškeré tyto mechanismy samozřejmě utajeny.

Obr. 1.16 Princip podpory mobility

Pro reálnou použitelnost MobileIP je nutné zajistit autentizaci všech zúčastněných komponent, aby nemohlo například dojít k podvržení registrace u domácího agenta a tím ke stažení provozu pro jistou stanici na stanici útočníka. K tomu může být velmi dobře využito standardních mechanismů pro autentizaci, případně šifrování, obsažených v IPv6.

Všimněme si na závěr, že na rozdíl od implementace Mobile IP v IPv4 nepředpokládá implementace v IPv6 vůbec existenci cizích agentů (foreign agents).

1.2.5.3 Podpora zabezpečení kvality služby Kvalita služby na úrovni rozlišovaných služeb (Differentiated Services, kap. 1.4.1.4) je

v IPv6 zajišťována stejným způsobem, jako v IPv4. Pole Třída provoz lze strukturovat stejně, jako pole DSCP v hlavičce IPv4 s tím, že další zpracování s ohledem na zajištění kvality služby je již věcí správy front směrovačů, případně i přepínačů.


Se zajištění kvality služby souvisí i pole Flow Label v hlavičce IPv6 paketu, zmíněné již v kapitole 1.2.3.1. Hlavním smyslem tohoto pole je omezení prohledávání směrovacích tabulek na směrovačích, kterými prochází jistý datový tok. Jestliže zdrojová stanice zajistí, že bude paketům každého takovéhoto datového toku přidělovat vždy stejnou a od jiných datových toků se lišící hodnotu a tuto vkládat do pole Flow Label, může každý směrovač provést vyhledání ve směrovací tabulce pouze jedenkrát a výsledek vložit pro další použití do paměti cache. Ta již může být organizovaná jako paměť asociativní a je vždy prohlížena předtím, než bude zahájeno náročné vyhledávání ve směrovací tabulce. Záznamy v cache paměti tak budou mít tvar n-tic

<zdrojová adresa, flow label, next_hop_IP, výstupní_rozhraní, hlavička_spojové_vrstvy>

Ukládání položky Flow Label i se zdrojovou adresou je nezbytné, protože přidělování hodnot Flow Label se děje na jednotlivých zdrojových stanicích nezávisle. Předpřipravení hlavičky spojové vrstvy pro výstupní rozhraní může směrování opět urychlit, protože odpadá potřeba opakovaného prohledávání ARP tabulky výstupního rozhraní.

S podporou kvality služby souvisí pole Flow Label tak, že pomáhá identifikovat pakety téhož datového toku, s nimiž mohou směrovače na cestě zacházet jistým jednotným způsobem, který může směrovačům vhodným způsobem signalizovat zdroj datového toku. Konkrétní mechanismy jsou však dosud pouze ve stádiu návrhů.

1.2.6 Směrování a protokol IPv6 Pro směrování v sítích s IPv6 lze samozřejmě využít léty prověřené mechanismy

používané v současné době v sítích s protokolem IPv4. Mimo statického směrování se tak ve světě IPv6 se tak setkáme jak se směrovacími protokoly třídy vektoru vzdáleností (distance-vector), tak s protokoly založenými na stavu linek (link-state), se stejnými výhodami a nevýhodami jako u IPv4. Nemůžeme však přímo převzít ty směrovací protokoly z prostředí IPv4, které počítaly s jediným konkrétním formátem adres – adresami IPv4. Těch je bohužel většina. Proto musely být některé protokoly reimplementovány (např. RIPNG (RFC2080), který nahradil původní RIP) nebo byly vypracovány nové verze (např. u OSPF může adresy protokolu IPv6 nést až implementace OSPF verze 3). Pro směrování IPv6 mezi autonomními systémy se s výhodou používá BGP verze 4+, který bývá často označován jako Multiprotocol BGP a je schopen nést formou atributů prefixy síťových adres v nejrůznějších formátech, mezi jinými i IPv6.

1.2.7 Současný stav podpory protokolu IPv6 Reálná situace s IPv6 je v současné době taková, že přechod z IPv4 na IPv6 probíhá

velmi pozvolna. Je tomu tak proto, že původně prorokovaný akutní nedostatek adres IPv4 se stal méně ožehavým zavedením jejich efektivnějšího přidělování a širokým využíváním překladu adres. Také ostatní pokročilé mechanismy vestavěné do IPv6 jsou v současné době nabízeny formou dodatečných standardů (IPSec, Mobile IP) již i v IPv4. Protože pro uživatele v současné době nepřináší přechod na IPv6 přímý užitek, za který by byli ochotni zaplatit, raději (stejně jako poskytovatelé, kteří nechtějí zbytečně zasahovat a investovat do fungující infrastruktury) vyčkávají. Existují pouze ostrůvky používající spolu s protokolem IPv4 i IPv6, avšak globální konektivita mezi všemi sítěmi Internetu pomocí IPv6 ještě z daleka


vybudována není. V moderních operačních systémech (Linux, Windows XP) i na kvalitnějších směrovačích je však více či méně široká implementace IPv6 k dispozici a jen vývoj v oblasti ukáže, kdy a zda vůbec bude IPv6 hlavním síťovým protokolem v Internetu.

1.2.7.1 Možnosti přechodu z protokolu IPv4 Návrhářům protokolu IPv6 bylo od začátku jasné, že přechod z IPv4 na IPv6 není

technicky ani organizačně uskutečnit skokově. Předpokládá se, že se IPv6 bude v Internetu zavádět postupně a jak stanice, tak směrovače budou ještě dlouhou dobu schopny pracovat současně s původním IPv4 i nově zaváděným IPv6. Pro postupný přechod z IPv4 na IPv6 byly navrženy následující mechanismy:

• Dvojí protokolový zásobník – zařízení má implementováno paralelně podporu jak IPv4, tak IPv6 a umožňuje komunikovat oběma těmito protokoly.

• Tunelování – tunelováni paketů IPv6 v paketech IPv4 přes části sítě, které IPv6 dosud nepodporují. Zde samozřejmě musíme řešit překlad mezi adresami IPv6 sítí a adresami koncových bodů IPv4 tunelů, za kterými se tyto sítě ukrývají. V nejjednodušším případě lze toto přiřazení konfigurovat staticky.

• Překlad protokolů – vzájemná konverze paketů mezi protokoly IPv4 a IPv6 pomocí speciální brány.

V praxi se v současné době setkáme nejčastěji s prvními dvěma způsoby.

KONTROLNÍ OTÁZKY • Jaké nedostatky protokolu IPv4 řeší nasazení protokolu IPv6 ? • S použitím obrázku v textu srovnejte hlavičky paketů protokolů IPv4 a IPv6. Jaký

význam mají jednotlivá pole hlavičky IPv6 ? • Vysvětlete princip řetězení hlaviček protokolu IPv6 a jaké má výhody. • Uveďte strukturu adresy protokolu IPv6 a způsob, jakým se zapisuje (vč. možností

zkracování zápisu). • Vysvětlete pojem výběrového vysílání (anycast). • Jak jsou adresy IPv6 začleněny do systému DNS ? • Jaké směrovací protokoly slouží pro směrování protokolu IPv6 • Jak hodnotíte současný stav implementace protokolu IPv6 v operačních systémech

a síťových prvcích ? Jaké jsou předpokládáné postupy přechodu z protokolu IPv4 na IPv6 ?


1.3 Směrování v počítačových sítích a v Internetu.

Abychom mohli paketovou sítí směrovat pakety od zdroje k cíli, potřebujeme správným způsobem naplnit směrovací tabulky všech směrovačů na trase. V malých sítích nebo v sítích, z nichž veškerý provoz ven odchází po jediné implicitní (default) cestě, lze toto vyřešit manuálním vložením potřebných informací, tj. statickým směrováním. V rozlehlejších sítích s měnící se topologií (z nichž největší je bezesporu Internet) jsou však nutné dynamické směrovací protokoly, které zajistí správné naplnění směrovacích tabulek automaticky na základě výměny informací mezi směrovači.

1.3.1 Hierarchické směrování, autonomní systémy Současný Internet je natolik rozsáhlý a proměnlivý, že není reálné udržovat

ve směrovačích úplnou informaci o jeho topologii. Tato informace by navíc byla velmi nestabilní, protože by se měnila s výpadkem nebo zapojením linky kdekoli na světě. Proto bylo rozhodnuto směrování v Internetu řešit hierarchickým způsobem. Předpokladem jeho použití je rozdělení Internetu do tzv. autonomních systémů (AS). Autonomním systémem rozumíme souvislou skupinu sítí a směrovačů, které jsou pod společnou správou a řídí se společnou směrovací politikou. Pod společnou směrovací politikou si představme zejména dohodnutý vnitřní směrovací protokol (např. OSPF nebo RIP), ale také speciální požadavky administrátorů na směrování některých druhů provozu (traffic engineering, load balancing). Příkladem autonomního systému tak může být autonomní systém jednoho konkrétního poskytovatele Internetu (ISP) nebo velké firmy.

Princip hierarchického směrování spočívá v tom, že z pohledu směrování mezi AS jsou autonomní systémy chápány jako základní jednotky, jejichž struktura již není mimo hranice autonomního systému známa. Z každého autonomního systému se pouze do okolí sděluje,

Anotace: V této kapitole budou vysvětleny základní charakteristiky směrovacích protokolů používaných v Internetu. Bude objasněn pojem autonomního systému a smysl hierarchického směrování, rozdíl mezi vnitřními a vnějšími směrovacími protokoly a jejich základní principy. Dále budou naznačeny možné postupy pro optimalizaci směrování.

Osnova: 1.3.1 Hierarchické směrování, autonomní systémy

1.3.1.1 Vnitřní a vnější směrovací protokoly 1.3.2 Vnitřní směrovací protokoly

1.3.2.1 Klasifikace vnitřních směrovacích protokolů 1.3.2.2 Standardizované vnitřní směrovací protokoly používané v Internetu

1.3.2.2.1 RIP 1.3.2.2.2 OSPF

1.3.2.2.2.1 Optimalizace směrování u vnitřních směrovacích protokolů 1.3.3 Vnější směrovací protokoly

1.3.3.1 Charakteristika vnějších směrovacích protokolů 1.3.3.2 Směrovací protokol BGP

1.3.3.2.1 Optimalizace směrování v protokolu BGP


které adresy sítí autonomní systém obsahuje. Autonomní systémy jsou číslovány celosvětově jednoznačnými šestnáctibitovými čísly.

Cílem hierarchického směrování je vždy nejprve doručit paket určený pro některou ze sítí autonomního systému na hranice tohoto autonomního systému. O další směrování ke konkrétní síti uvnitř AS se již postará vnitřní směrovací protokol, který topologii (nebo alespoň cesty ke všem sítím) svého vlastního AS zná. Směrovač, který je na hranici autonomního systému a účastní se jak na směrování mezi AS tak ve směrovacím protokolu svého AS, se nazývá hraniční směrovač (angl. border gateway).

Podle počtu linek, kterými je autonomní systém připojen k okolnímu světu, můžeme autonomní systémy rozdělit na tzv. single-homed a multi-homed . Single-homed autonomní systém je připojen jedinou linkou k jinému AS (typicky poskytovateli Internetu), zatímco multi-homed systém je připojen více linkami. Linky multi-homed autonomního systému mohou vést k tomutéž ISP nebo (častěji) k více různým ISP. Autonomní systém, který dovoluje průchod provozu, který v něm nezačíná ani nekončí, se nazývá tranzitní autonomní systém. Tranzitní samozřejmě mohou být pouze multi-homed AS. Ne každý multi-homed AS je však používán jako tranzitní - multi-homed AS je např. každý AS firmy, která chce mít záložní spojení k více než jednomu ISP. Firma však nemusí mít zájem na tranzitu cizího provozu přes svou síť. Naopak tranzitní systém samozřejmě musí být multi-homed (single-homed AS je připojen pouze jedinou linkou, takže přes něj nemůže žádný provoz procházet).

Pokud k tomu není speciální důvod, nepřiděluje se síti každého zákazníka zvláštní AS. Naopak sítě zákazníků bývají často součástí AS poskytovatele. K žádosti o vlastní jednoznačné číslo AS zákazník typicky přistupuje pouze v případě, že se v budoucnu hodlá připojit k více různým poskytovatelům.

Všimněme si, že z pohledu počtu přeskoků, resp. cen spojů či jiné obvyklé metriky není směrování v Internetu optimální. Optimalita směrování však v praxi není z mnoha důvodů dosažitelná a kvůli potřebě aplikace různých směrovacích politik ani žádaná. Základní technickou komplikací pro dosažení optimálního směrování je neexistence společně interpretované metriky - každý vnitřní směrovací protokol používá svou, s ostatními nesrovnatelnou, metriku (např. počet přeskoků u RIP, cena cesty u OSPF, kompozitní metrika u Cisco IGRP). Suboptimální hierarchické směrování kompenzuje tuto nevýhodu tím, že omezuje počet záznamů ve směrovací tabulce s využitím agregace a položky default pro všechny sítě mimo autonomní systém.

1.3.1.1 Vnitřní a vnější směrovací protokoly Při směrování v rámci jednotlivých autonomních systémů se používají tzv. vnitřní

směrovací protokoly - Interior Gateway Protocols, IGP. Naopak pro směrování mezi autonomními systémy se používají vnější směrovací protokoly - Exterior Gateway Protocols, EGP. Situace je vyobrazena na obr. 1.17. Typickými vnitřními směrovacími protokoly jsou dnes např. OSPF nebo starší RIP, jako vnější směrovací protokol se používá téměř výhradně protokol BGP.


AS 1

AS 3

AS 2

EGP

EGP

EGP

IGP1

IGP2

IGP3

Obr. 1.17 Interní a externí směrovací protokoly

1.3.2 Vnitřní směrovací protokoly

V dnešní době se používá celá řada vnitřních směrovacích protokolů. V následující kapitole si popíšeme, jak se tyto protokoly rozdělují, jaké jsou jejich základní principy, jak lze optimalizovat cesty nalezené těmito protokoly a na závěr si představíme typické reprezentanty jednotlivých tříd vnitřních směrovacích protokolů.

1.3.2.1 Klasifikace vnitřních směrovacích protokolů Během vývoje byla postupně navrženo a aplikováno mnoho vnitřních směrovacích

protokolů. Funkcionalita novějších protokolů zpravidla překonává protokoly starší, avšak z důvodu historických nebo pro jednoduchost implementace či konfigurace nebo výhodnosti pro konkrétní použití jsou stále prakticky využívány i protokoly starší. Při volbě vhodného směrovacího protokolu musíme zvážit zejména tato kritéria:

• Základní princip funkce a míra informovanosti o topologii sítě. Rozlišujeme dvě základní třídy směrovacích protokolů: protokoly založené na vektoru vzdálenosti (distance-vector) a na stavech linek (link-state).

• Doba konvergence, tedy po jak dlouhé době od změny topologie se upraví a ve všech směrovačích ustálí nové směrovací tabulky.

• Použitá metrika, tedy kritérium, podle něhož směrovací protokol vybírá nejlepší z alternativních cest. Může jít např. o počet přeskoků (tj. směrovačů) na cestě, součet manuálně nakonfigurovaných cen linek tvořících cestu nebo třeba i kombinaci šířky pásma, zatížení, zpoždění a spolehlivosti linek.

• Podpora pro vyvažování zátěže přes alternativní cesty a to případně i přes alternativní cesty s různou cenou.

• Zda směrovací protokol šíří s adresami sítí i jejich masku podsítě nebo spoléhá na to, že maska podsítě bude odvozena podle dnes již téměř nepoužívané třídy IP adresy.

Algoritmy třídy distance vector jsou historicky starší a jejich implementace je jednodušší. Pracují na principu Bellman-Fordova algoritmu, kdy si sousední směrovače navzájem vyměňují své směrovací tabulky a doplňují si informace, které se naučí od sousedů. Topologii celé sítě však neznají, musí se spokojit s adresami sousedů, přes která mají posílat pakety do jednotlivých cílových sítí a vzdálenostmi k těmto sítím, které společně tvoří tzv. distanční vektory.


Na začátku směrovací tabulka každého směrovače obsahuje pouze adresy přímo připojených sítí, které jsou staticky nakonfigurovány administrátorem. Směrovací tabulka je periodicky zasílána všem sousedů. Každý směrovač si z došlých směrovacích tabulek sousedů (obsahujících vzdáleností sousedů od jednotlivých cílových sítí) výběrem nejlepší cesty do každé sítě postupně doplňuje a upravuje svou směrovací tabulku. Jestliže je mu sousedem nabízena cesta do sítě, kterou dosud nemá, do směrovací tabulky si ji přidá. Pokud soused nabízí cestu, kterou směrovač již má, ale má ji s horší metrikou, do směrovací tabulky se místo ní zaznamená lepší cesta od souseda. Ostatní nabízené cesty jsou ignorovány.

Odstraňování již neaktuálních cest se děje tak, že informace o každé cestě musí být sousedem pravidelně občerstvována - pokud cesta nebyla delší dobu sousedem inzerována, ze směrovací tabulky se odstraní.

Příklad šíření cesty do sítě symbolicky označené jako b a postupné doplňování směrovacích tabulek směrovačů R1, R2 a R3 o cestu do sítě b je vidět na obr. 1.18a až 1.18c. Paralelně s tím se samozřejmě šíří informace o ostatních sítích, ta však není z důvodu přehlednosti do příkladu zahrnuta.

R1:-----a 0 –f 0 –d 0 -

c

R1 R2

R3

ba def

c

R1 R2

R3

ba def

R2:-----b 0 –d 0 –e 0 -

Obr. 1.18 a Informace předkonfigurované ve směrovacích tabulkách směrovačů

R1:-----a 0 –f 0 –d 0 –b 1 R2

R2:-----b 0 –d 0 –e 0 -

R3:-----c 0 –e 0 –f 0 –b 1 R2

c

R1 R2

R3

ba def

c

R1 R2

R3

ba def

b,0

b,0

Obr. 1.18 b R2 poslal směrovací tabulku sousedům, ti ji zkombinovali se svými


R1:-----a 0 –f 0 –d 0 –b 1 R2b 2 R3

R2:-----b 0 –d 0 –e 0 -

R3:-----c 0 –e 0 –f 0 –b 1 R2b 2 R1

c

R1 R2

R3

ba def

b,1 b,1

b,1

b,1

c

R1 R2

R3

ba def

b,1 b,1

b,1

b,1

nechci ! (mámlepší)

nechci ! (mámlepší)

Obr. 1.18 c R3 a R2 poslali své směrovací tabulky sousedům, ti je zkombinovali se svými

Metrikou protokolů třídy distance vector je typicky počet přeskoků na cestě do cílové sítě. Ten však nezohledňuje skutečné parametry linek (zejména přenosovou rychlost), které se mohou i velmi zásadně lišit. Konvergence při změnách topologie je velmi pomalá, o změně v topologii směrovač informuje až v příští periodě pro vysílání směrovací tabulky sousedům. Všechny uzly sítě jsou navíc zahlcovány rozesíláním kompletních směrovacích tabulek formou broadcastu. Směrovací protokoly třídy distance vector jsou také až příliš "optimistické" - směrovač se rychle učí dobré cesty, ale pomalu „zapomíná“ cesty nefunkční, protože musí čekat na vypršení časového limitu, po který cesta není sousedem inzerována.

Protokoly třídy distance vector trpí také mnohými riziky, při nichž může dojít k zasmyčkování nebo šíření nesprávné informace. Přestože dnes existují osvědčené mechanismy, jak tato rizika výrazně omezit a také zrychlit šíření informace o změně topologie, je z důvodu aplikace různých pomocných časovačů pro zabránění tvorby smyček v mnohých případech doba konvergence i u malých sítí v řádu mnoha minut.

Novější protokoly třídy link state mají sice složitější implementaci, ale výrazně rychlejší konvergenci v řádu desítek sekund a netrpí tolik problémy chování ve „speciálních situacích“.

Směrování zde probíhá na základě znalosti "stavu" jednotlivých linek sítě (funkčnost, cena) s tím, že směrovače znají topologii celé sítě, kterou si udržují v topologické databázi. Topologická databáze je tvořena záznamy o linkách vedoucích k sousedům ode všech směrovačů a udržuje se tak, že každý směrovač neustále sleduje stav a funkčnost k němu připojených linek a při změně okamžitě a spolehlivým mechanismem šíří informaci o aktuálním stavu svého okolí všem ostatním směrovačům. Všechny směrovače tak stále udržují identickou topologickou databázi. Na základě topologické databáze si každý směrovač počítá strom nejkratších cest ke všem ostatním směrovačům a k nim připojeným sítím pomocí Dijkstrova algoritmu. Z vypočteného stromu pak snadno zkonstruuje správnou směrovací tabulku, kterou na rozdíl od protokolů třídy distance vector všechny směrovače počítají na základě stejných a úplných dat

Výhodou algoritmů třídy link state je, že v síti se šíří pouze informace o změnách a není zapotřebí žádné periodické rozesílání směrovacích tabulek jako u protokolů třídy distance vector. Informace o změně se rozšíří prakticky okamžitě do celé sítě, takže konvergence je


velmi rychlá.

1.3.2.2 Standardizované vnitřní směrovací protokoly používané v Internetu Z vnitřních směrovacích protokolů, které jsou definovány otevřenými standardy a

poskytují interoperabilitu mezi nejrůznějšími platformami směrovačů je dnes asi nejčastěji používán směrovací protokol OSPF, u menších sítí také již velmi starý protokol RIP. Každý z nich je typickým reprezentantem jedné ze tříd směrovacích protokolů, proto se nyní podíváme podrobněji na jejich vlastnosti.

1.3.2.2.1 RIP Protokol RIP (Routing information protocol), definovaný v RFC1058 je velmi starý, ale

pro jednoduchost implementace a prakticky nulové nároky na znalosti správce stále často používaný v malých sítích. Jeho metrikou je počet směrovačů na cestě k cílové síti. Jelikož eliminuje problém vzniku smyček mechanismem tzv. „počítání do nekonečna“ [4] omezením metriky na hodnotu 15, nemůže být použit v rozsáhlejších sítích, kde by počet směrovačů na kterékoli cestě mohl být větší než 15. V současné době jsou do implementací RIP běžně zahrnovány různé pomocné mechanismy jako Triggered Updates, Split Horizon, Holddown nebo Route Poissoning [4], které výrazně zrychlují konvergenci okamžitým šířením změn bez čekání na čas periody rozesílání směrovací tabulky, omezují riziko vzniku smyček nebo okamžitě informují o cestách, které se staly nedostupnými. V některých případech zajišťují okamžité odstranění neaktuálních cest bez čekání na vypršení časového limitu, po který nebyla cesta sousedem inzerována.

Směrovací tabulka se v RIP rozesílá každých 30 sekund. Pokud směrovač neslyšel o cestě po dobu 180 sekund, zahájí proces jejího odstranění.

Některé implementace RIP podporují rozkládání zátěže mezi cestami se stejnou metrikou, což je dosaženo jednoduše tím, že si směrovač ukládá do směrovací tabulky ne pouze jednu, ale všechny cesty do cílové sítě s nejnižší hodnotou metriky, pokud je mu takovýchto cest inzerováno více.

Původní protokol RIP nešířil masky podsítě, takže jej nebylo možné použít v sítích s adresací s maskou podsítě proměnné délky (VLSM). Proto byla v RFC2453 později definována verze 2 tohoto protokolu, která mimo šíření masek podsítě propagovaných sítí dále podporuje autentizaci sousedů a umožňuje distribuovat směrovací tabulky multicastem místo broadcastu, čímž se omezí rušení činnosti stanic provozem směrovacího protokolu RIPv2 mezi směrovači.

1.3.2.2.2 OSPF

Protokol OSPF (Open Shortest Path First) byl vytvořen organizací IETF přibližně v letech 1988 až 1991 a je dnes jedním z nejpoužívanějších směrovacích protokolů. Jeho nejnovější verze je definována v RFC2328. Jméno protokolu je odvozeno jednak z toho, že jde o otevřený standard a jednak z faktu, že směrovač nejprve vypočte strom nejkratších cest a až pak z něj vytvoří směrovací tabulku.

OSPF je typickým představitelem směrovacího protokolu typu link state. Vytváří tedy v paměti směrovače kompletní mapu celé sítě, označovanou jako topologická databáze. Nad touto databází potom pomocí Dijkstrova algoritmu provádí výpočty potřebné k nalezení


nejvýhodnější cesty do jednotlivých sítí. Protokol OSPF používá metriku označovanou jako cena (angl. cost). To je číslo v rozsahu 1 až 65535, přiřazené ke každému rozhraní směrovače. Čím menší číslo, tím má linka lepší metriku a bude tedy více preferována. Standardně je ke každému rozhraní přiřazena cena automaticky a je nepřímo úměrná šířce pásma linky na daném rozhraní.

OSPF šíří informace o sítích včetně masek podsítí, takže může být použit i v sítích používajících VLSM adresování. Pro provoz používá multicastových adres. Tím je zajištěno, že rámce nesoucí OSPF pakety budou přijímat pouze směrovače podporující tento protokol a nebudou zbytečně přijímány pracovními stanicemi. OSPF může zvládat vyvažování zátěže mezi cestami se stejnou cenou a autentizaci výměny směrovací informace mezi sousedními směrovači.

Ve velmi zjednodušené podobě můžeme funkci protokolu OSPF popsat následovně :

1. Směrovač vysílá přes svá rozhraní tzv. Hello pakety. Pokud se dva navzájem propojené routery provozující protokol OSPF pomocí těchto paketů dohodnou na určitých společných parametrech, stávají se sousedy. Na segmentech, ke kterým je připojeno současně více směrovačů, je zvolen tzv. pověřený směrovač (designated router), který bude koncentrovat výměnu informace mezi směrovači na segmentu, aby si je nemusely vyměňovat každý s každým a tím zbytečně zatěžovat síť.

2. Sousední směrovače si vzájemně vyměňují pakety označované jako LSA (Link State Advertisement) informace. Ty popisují stav dvoubodových rozhraní jednotlivých směrovačů včetně identifikace k nim připojených sousedů nebo obsahují seznam směrovačů připojených k síti, na kterou může být připojeno současně více směrovačů (typicky jde o segment Ethernetu)

3. Všechny směrovače si ukládají přijaté LSA do své lokální topologické databáze a zároveň je přeposílají na ostatní přilehlé směrovače. Tím se informace postupně rozšíří mezi všechny směrovače v síti. Výsledkem bude shodná topologická databáze na všech směrovačích.

4. Po naplnění databáze každý směrovač provede výpočet pomocí SPF (Dijkstrova) algoritmu. Jeho výsledkem bude nalezení nejkratší cesty ze směrovače do každé známé sítě.

5. Na základě vypočtených dat je možné naplnit směrovací tabulku směrovače.

6. Pokud dojde ke změně topologie sítě, směrovač na kterém ke změně došlo odešle přilehlým směrovačům informaci v podobě LSA paketu. Ta se postupně rozšíří po celé síti a každý směrovač upraví svou topologickou databázi a provede nový výpočet SPF algoritmu.

Výpočet SPF algoritmu představuje pro směrovač poměrně velkou zátěž a je žádoucí, aby neprobíhal příliš často. K tomu by mohlo dojít například v případě, že některá z linek je nestabilní a opakovaně nabíhá a vypadává. Proto bývá definován minimální časový interval mezi dvěmi výpočty.

Velkou výhodou protokolu OSPF proti starším směrovacím protokolům je jeho schopnost pracovat v relativně velkých sítích. Toho se dosáhlo zavedením dvou úrovní hierarchie. Síť je rozdělené na takzvané oblasti (area). Oblast je logická skupina směrovačů a linek mezi nimi. LSA se šíří pouze uvnitř dané oblasti a také výpočet SPF algoritmu se spouští pro každou oblast samostatně. Směrovače v oblasti znají detailně pouze topologii sítě ve své oblasti a z ostatních oblastí dostávají jen souhrnné informace. Změna topologie sítě v jedné oblasti tedy nevyvolá přepočet SPF algoritmu v ostatních oblastech.


Oblasti jsou navzájem propojeny pomocí tzv. hraničních směrovačů (Area Border Router, ABR). K jiným autonomním systémům pak může být autonomní systém s protokolem OSPF připojen pomocí hraničního směrovače autonomního systému (AS Border Router, ASBR), který může do OSPF redistribuovat externí cesty. Příklad sítě rozdělené na více oblastí, která je navíc přes ASBR připojena k dalšímu AS, je vidět na obr. 1.19.

area 0

area 1

DR

ABR

ASBR

BDR

foreign AS

Obr. 1.19 Síť složená z více oblastí

Každá oblast je označena 32 bitovým číslem, které může být uvedeno ve dvou formátech. Buď jako běžné číslo (např. area 10) nebo ve formátu IP adresy (area 0.0.0.10). Zvláštní úlohu mezi oblastmi hraje area 0, někdy označována jako páteřní oblast (backbone). Ta navzájem propojuje všechny ostatní oblasti. Veškerý provoz, který teče z jedné oblasti do druhé, musí procházet přes oblast 0 a každá oblast musí být přes ABR napojená na oblast 0.

Adresování v síti s oblastmi je vhodné navrhnout tak, aby adresy jednotlivých sítí propagovaných sumárně ven z oblasti bylo možné sumarizovat a propagovat jako jedinou sumární cestu (tzv. supernet). Například čtyři za sebou následující sítě 192.168.4.0/24, 192.168.5.0/24, 192.168.6.0/24 a 192.168.7.0/24 můžeme propagovat jako cestu do supernetu 192.168.4.0/22.

Oblasti v OSPF mohou být konfigurovány jako oblasti různých typů podle toho, jaké informace chceme mít ve směrovacích tabulkách směrovačů v oblasti. Můžeme tak snížit požadavky na paměť i procesor směrovačů v dané oblasti. Nejčastěji se setkáme s oblastmi typu „stub“ nebo s jejich modifikací, oblastmi typu „totally stubby“.

Do oblasti typu „stub“ nebudou ABR směrovačem propagovány externí cesty, ale jen cesty nalezené OSPF protokolem v daném autonomním systému. Směrování do externích sítí bude řešeno pomocí implicitní (default cesty), která je do oblasti automaticky propagována z ABR. Jako stub je nejvýhodnější konfigurovat takovou oblast, ze které vede jen jediná cesta ven. Je to však možné i v případě, že cest z oblasti je více, pak ale nemusí pakety směrované do externích sítí procházet nejkratší možnou cestou.

Koncepce oblasti typu „totally stubby“ rozvíjí myšlenku stub oblasti ještě dále. Pokud z oblasti existuje jen jediná cesta ven, proč do ní propagovat cesty z ostatních oblastí stejného AS ? Do oblasti typu „totally stubby“ tedy bude z ABR propagována pouze a jedině default cesta. Ve směrovací tabulce směrovačů uvnitř oblasti typu totally stubby tak nalezneme jen cesty uvnitř oblasti a default cestu, která bude použitá pro dosahování cílů v ostatních oblastech autonomních systémů i sítí mimo autonomní systém.


Posledním typem oblasti je oblast typu NSSA (Not-So-Stubby Area), která má všechny vlastnosti oblasti typu stub, avšak připouští, aby v ní ležel hraniční směrovač autonomního systému (ASBR) a redistribuoval prostřednictvím této stub oblasti do páteřní oblasti externí cesty.

Optimalizace směrování u vnitřních směrovacích protokolů Vnitřní směrovací protokoly volí používané cesty do cílových sítí automaticky jako

nejkratší cesty vypočtené na základě metriky daného směrovacího protokolu. V některých případech je však výhodné výpočet nejkratších cest směrovacího protokolu vhodným způsobem ovlivnit. Podle konkrétního použitého směrovacího protokolu lze toto realizovat nejrůznějšími způsoby. U směrovacích protokolů třídy link state jde zpravidla o nastavením cen linek na rozhraních směrovačů a vhodné definice oblastí a sumarizace informace propagované mezi oblastmi. Naopak u směrovacích protokolů třídy distance vector lze snadno vyfiltrovat informaci o některých cestách propagovaných do určitých částí sítě nebo definovat, že pro určité propagované nebo přijímané cesty bude uměle zvýšen počet přeskoků, čímž bude cestě dána nižší preference.

Pro konkrétní směrovač můžeme také definovat lokální pravidla pro směrování paketů, která budou mít přednost před dynamickými směrovacími protokoly. Ty mohou mimo adresy cílové sítě zahrnovat i jiná kritéria, jako zdrojovou adresu nebo třídu služby přicházejících paketů.

V sítích, které z různých důvodů používají současně více směrovacích protokolů, můžeme volit vzájemnou prioritu protokolů pro případ, že by směrovač získal různé cesty do téže sítě od různých směrovacích protokolů. Prioritu můžeme dát i “záložní“ staticky nakonfigurované cestě, která bude normálně neaktivní a použije se pouze v případě, že se ztratí primární cesta propagovaná dynamickým směrovacím protokolem.

Směrovací informaci mezi částmi sítě používajícími různé směrovací protokoly také můžeme mezi protokoly redistribuovat, přičemž musíme dát pozor na možnost zacyklení a řešit problém zpravidla nekompatibilních metrik jednotlivých protokolů.

1.3.3 Vnější směrovací protokoly V následující kapitole se podíváme na protokoly pro směrování mezi autonomními

systémy. Po krátkém shrnutí vlastností vnějších směrovacích protokolů se zaměříme na protokol BGP, který se v současném Internetu pro směrování mezi AS používá výhradně.

1.3.3.1 Charakteristika vnějších směrovacích protokolů Vnější směrovací protokoly propagují z každého autonomního systému všechny sítě,

které mají být z vnějšího světa dostupné nebo do kterých nechává autonomní systém přes sebe procházet tranzitní provoz (obr. 1.20). Protože sítí propagovaných z autonomního systému může být velké množství, je výhodné, když sítě v rámci autonomního systému mají společný prefix adresy a mohou být propagovány společně jako jediná supersíť.


AS1

20.0.1.0/2420.0.2.0/24

AS2

30.0.10.0/2430.0.20.0/24

AS3 (Tranzitní AS)

100.80.0.0/16100.81.0.0/16

IBGP

EBGP EBGP

20.0.1.0/2420.0.2.0/24

30.0.10.0/2430.0.20.0/24

30.0.10.0/2430.0.20.0/24

100.80.0.0/16100.81.0.0/16

20.0.1.0/2420.0.2.0/24100.80.0.0/16100.81.0.0/16

Obr. 1.20 Propagování vlastních nebo dosažitelných prefixů sítí z AS

Směrovací informace se mezi autonomními systémy vyměňuje prostřednictvím hraničních routerů, angl. border gateway. Z tohoto názvu je odvozeno i jméno v současnosti prakticky jediného používaného vnějšího směrovacího protokolu: Border Gateway Protocol - BGP. Pomocí BGP si hraniční směrovače vyměňují informace o sítích v jednotlivým autonomních systémech a o tom, přes které autonomní systémy se lze k jednotlivým sítím dostat. V dnešní době se používá téměř výhradně protokol BGP ve verzi 4 RFC2283 nebo 4+, nazývaný někdy Multiprotocol BGP.

1.3.3.2 Směrovací protokol BGP Protokol BGP nepracuje s grafem propojení jednotlivých směrovačů a sítí (jako to dělá

např. OSPF), ale s grafem propojení autonomních systémů. V tomto grafu jsou pak vyhledávány cesty mezi sítěmi v různých autonomních systémech. Cestou (AS PATH) k nějaké síti se v terminologii BGP rozumí posloupnost čísel autonomních systémů, přes které se lze k cílové síti dostat.

Na rozdíl od vnitřních směrovacích protokolů nemá BGP jednoznačnou metriku, podle níž by za všech okolností automaticky volil nejkratší cesty do jednotlivých cílových sítí. Při směrování mezi AS totiž směrujeme provoz přes cizí AS, jejichž provozovatelé mají nejrůznější zájmy a provozní i obchodní podmínky. Respektováním všech těchto faktorů pak určíme tzv. směrovací politiku (angl. routing policy). Směrovací politika například určuje

• do kterých AS necháme tranzitovat provoz přes náš AS,

• ze kterých zdrojových AS necháme tranzitovat provoz přes náš AS,

• kterou výstupní linkou z našeho AS necháme odcházet provoz k daným sítím,

• kterou vstupní linkou do našeho AS necháme vstupovat provoz ke kterým sítím.

Protože je třeba do konfigurace protokolu BGP všechny faktory směrovací politiky zahrnout, je jeho konfigurace mnohem více manuální, než jsme zvyklí z protokolů třídy IGP. U protokolů IGP jsou obvykle sousední směrovače vyhledávány automaticky a předpokládá se, že komunikovat spolu mohou všechny nalezené směrovače a že cesty do jednotlivých cílových sítí nejsou omezeny žádnými dodatečnými podmínkami a hledá se vždy cesta s minimální hodnotou metriky. Naopak u BGP jsou sousední směrovače konfigurovány manuálně, stejně jako transformace prováděné nad cestami předávanými mezi jednotlivými sousedy.


Vnitřní směrovací protokoly se tradičně rozdělují na distance-vector a link-state. Z pohledu úrovně znalosti topologie sítě, způsobu předávání i obsahu směrovací informace se protokol BGP řadí na jejich pomezí. Někdy bývá označován jako protokol speciální třídy, nazývané path-vector. Termínem path vector rozumíme posloupnost čísel autonomních systémů, přes které vede cesta k nějaké síti. Spolu s každou cestou je šířen i její path vector, který se postupně prodlužuje tím, jak každý AS, přes který cesta projde, na začátek path vectoru připojí své číslo. Protože cesta nesmí obsahovat smyčku, může se číslo autonomního systému v path vector objevit nejvýše jednou. Smyčky při předávání směrovací informace se automaticky eliminují tak, že AS zahazuje nabízené cesty, které již v path vectoru obsahují jeho vlastní číslo autonomního systému (obr. 1.21).

Obr. 1.21 zamezení smyčkám při předávání směrovací informace pomocí Path vector

Path vector také slouží k výběru nejkratší cesty do jednotlivých sítí. Za nejkratší bude

považována ta cesta, která prochází nejmenším počtem autonomních systémů. Při výběru z alternativních cest do sítí tedy budou preferovány ty cesty, jejichž path vector je kratší.

Směrovací informace (routing updates) se v BGP vyměňuje vždy mezi sousedními směrovači. BGP směrovače jsou vždy na hranicích autonomního systému4. Každému BGP směrovači jsou při konfiguraci manuálně přiřazeni sousedé, se kterými si bude směrovací informaci vyměňovat. Aby výměna směrovací informace byla spolehlivá, probíhá s použitím protokolu TCP (port 179). Po navázání spojení mezi sousedy se mezi těmito sousedy vymění kompletní směrovací informace, která je oběma známa. Dále se pak již předávají pouze změny (směrovač propaguje novou přes něj dostupnou síť nebo odvolává dostupnost dříve inzerované sítě).

Předávané směrovací informace mají tvar dvojic <prefix_adresy_sítě, délka_prefixu>. Sítě s IP adresou začínající inzerovaným prefixem jsou dostupné přes AS, jehož hraniční směrovač prefix inzeruje. Ke každé cestě může být dále přiřazeno libovolné množství tzv. atributů, pomocí nichž se realizují směrovací politiky, jak bude vysvětleno dále

BGP směrovače si periodicky (obvykle 1x za minutu) testují dostupnost každého svého nakonfigurovaného souseda pomocí tzv. keepalive zpráv. Pokud soused přestane být dostupný, musí směrovač odstranit všechny cesty vedoucí přes tohoto souseda a informovat ostatní sousedy o nedostupnosti cest

Informace o cestách získaných od sousedů se směrovač ukládá do databáze, nazývané někdy BGP tabulkou. Do každé sítě směrovač zvolí některou z cest uložených v databázi a

4 výjimku tvoří tzv. interní BGP v tranzitních AS


vloží si tuto cestu jako záznam směrovací tabulky. Cesty, které směrovač sám používá (tj. vybral si je do směrovací tabulky) pak propaguje pomocí BGP svým sousedům. Výběr cesty z BGP tabulky do směrovací tabulky se děje jednak na základě délky path vector a jednak na základě hodnot atributů, jak si vysvětlíme dále.

1.3.3.2.1 Optimalizace směrování v protokolu BGP Vyhledávání cest na základě algoritmu path-vector umožní nalézt nejkratší cesty

do všech autonomních systémů. Abychom však byli schopni explicitně ovlivňovat směrovací politiky, je potřebný mechanismus, kterým bychom vyjádřili preferenci, resp. zákaz některých cest podle nejrůznějších kritérií. K tomuto účelu v protokolu BGP slouží atributy, které můžeme každé propagované cestě k cílové síti přiřadit. Je definováno několik atributů, z nichž některé jsou povinné a některé nepovinné. Dále je definován způsob zacházení s případnými neznámými atributy tak, aby postupně mohly být dodefinovávány další.

Ke každé cestě propagované v BGP musí být přiřazeny jisté povinné atributy (přinejmenším atribut AS_PATH nesoucí path vector příslušné cesty) a dále volitelně i další atributy, k jejímž hodnotám může být při propagování cesty mezi AS a při výběru nejlepší cesty do směrovací tabulky přihlíženo.

Realizace směrovací politiky mezi AS se děje pomocí manipulací s atributy cest přijímaných od jednotlivých sousedů, resp. propagovaných k jednotlivým sousedů a také filtraci těchto cest. Atributy jsou nastavovány a zpracovávány při přijetí směrovací informace od souseda v tzv. Input Processing Engine a také před odesláním informace sousedovi v tzv. Output Processing Engine BGP směrovače (obr. 1.22). Mezi tím jsou uchovávány v tzv. BGP tabulce, odkud jsou na základě pevně stanoveného algoritmu zohledňujícího hodnoty atributů vybírány do směrovací tabulky.

Obr. 1.22 Zpracování atributů příchozích a odchozích cest v BGP

U každého souseda můžeme samostatně stanovit, jaké transformace atributů se mají dít při příchodu informace od tohoto souseda a také při formulování informace pro tohoto souseda. Hodnoty atributů a prefixy cest mohou být testovány na různé podmínky a při shodě vhodným způsobem měněny hodnoty jiných atributů. Na základě hodnot atributů nebo prefixů cest mohou být také některé cesty filtrovány. Toto testování a nastavování se děje


nezávisle při přijetí cesty a před její propagací.

Mezi nejpoužívanější atributy patří atribut AS_PATH, NEXT_HOP, LOCAL_PREFERENCE, MED a COMMUNITY. Atribut AS_PATH obsahuje řetězec čísel autonomních systémů, přes které vede cesta k cílové síti. Pokud se vybírá z cest lišících se pouze v AS_PATH, volí se vždy cesta s "kratším" AS_PATH, tedy s hodnotou AS_PATH obsahující menší počet čísel AS. Textový řetězec v AS_PATH lze testovat na výskyt definovaného podřetězce pomocí regulárních výrazů. Takto lze např. vyloučit nebo naopak preferovat cesty procházející přes některé konkrétní AS. Také lze řetězec AS_PATH modifikovat, např. uměle jej prodlužovat vícenásobným vkládáním čísla AS, kterým propagovaná cesta prochází.

Druhým z atributů, který musí být povinně uveden u každé cesty, je atribut NEXT_HOP. Je v něm obsažena adresa rozhraní hraničního směrovače sousedního AS, který informaci o cestě do AS zaslal (tedy adresa směrovače z cizího AS). Tím se BGP značně odlišuje od protokolů třídy IGP, kde se předpokládá, že adresa nejbližšího souseda na cestě k cílové síti (next hop) je vždy adresa některého bezprostředně sousedícího směrovače. Cestu k rozhraní hraničního směrovače propagovaného v atributu NEXT_HOP musí směrovač zjistit z vnitřního směrovacího protokolu svého autonomního systému, který tak musí mít informaci i o adrese sítě spojovací linky mezi AS.

S použitím nepovinného atributu LOCAL_PREFERENCE se mohou směrovače (multihomed) autonomního systému dohodnout na společné volbě cesty k nějaké cizí síti, která je dostupná přes více alternativních linek. Naopak atributem MED (Multi-Exit Discriminator) lze ovlivnit volbu cesty používanou sousedním AS pro dosažení jednotlivých sítí uvnitř našeho AS, resp. za naším AS pokud dovolíme přes náš AS tranzitovat provoz.

Atributem COMMUNITY můžeme cestě přiřadit „značku“ a dále v síti pak cesty označené jistou značkou zpracovávat speciálním způsobem, například je filtrovat nebo naopak preferovat.

Pokud má směrovač v BGP tabulce k dispozici více alternativních cest k nějaké síti, musí vybrat jednu z nich do směrovací tabulky. Při jistém zjednodušení vypadá pořadí kritérií ovlivňujících výběr nejlepší cesty následovně:

1. Hodnota atributu LOCAL_PREFERENCE

2. Preference cesty generované směrovačem samotným (a pocházející z jeho AS) – např. cesty získané redistribucí z IGP

3. Kratší AS_PATH (menší počet čísel AS v hodnotě AS_PATH)

4. Hodnota atributu MED

5. Propagovaný next_hop dostupný přes kratší cestu vnitřkem AS

6. Nižší hodnota identifikátoru směrovače, od kterého byla cesta získána, tzv. Router ID. Router ID se používá pro definitivní rozhodnutí v případě, že podle žádného "rozumnějšího" kritéria nebylo možné rozhodnout.

Je užitečné si uvědomit, že počet AS v atributu AS_PATH je až čtvrtým kritériem v pořadí.

Na závěr naší diskuse o BGP si všimněte, že manipulací s atributy můžeme nezávisle ovlivňovat, kterými linkami bude procházet provoz ven z AS a provoz dovnitř do AS. Můžeme také dosáhnout jistého vyvažování zátěže, např. použitím jedné linky pro provoz k některým sítím a druhé linky k sítím ostatním. Při tom však musíme mít na zřeteli, že z mnoha důvodů je velmi dobré udržet symetrii směrování, tj. provoz do sítí odcházející


určitou linkou by se měl touto linkou také vracet. Požadavky na vyvažování zátěže a symetrii směrování bývají často protichůdné, proto je obvykle třeba hledat vhodný kompromis. Na rozdíl od vnitřních směrovacích protokolů se tak v BGP vyvažování zátěže do jednoho cíle více linkami příliš často nepoužívá.

KONTROLNÍ OTÁZKY • Vysvětlete pojem autonomního systému a důvody dělení Internetu na autonomní

systémy. Vysvětlete princip hierarchického směrování a funkci vnitřních a vnějších směrovacích protokolů v něm.

• Uveďte konkrétní kritéria, podle nichž je možné klasifikovat vnitřní směrovací protokoly.

• Vysvětlete základní princip funkce protokolů třídy distance-vector. Jaká informace se předává, mezi kým, jak často ? Jak si router z příchozí informace buduje směrovací tabulku ? Jaké časovače se při tom uplatní ?

• Vysvětlete kroky, ve kterých u směrovacích protokolů třídy link-state probíhá výměna informace o topologii a budování směrovací tabulky.¨

• Proč se u protokolů třídy link-state využívá principu hierarchického směrování, v čem spočívá a jak se implementuje pomocí oblastí ? Proč je výhodné navrhnout adresní plán sítě hierarchicky s ohledem na oblasti?

• Jak v protokolu OSPF nazýváme směrovače, které leží uvnitř nebo na hranici oblasti nebo na hranici autonomního systému ?

• Jaké typy oblastí protokolu OSPF znáte ? Proč se rozlišují různé typy oblastí ? • Jakou funkci mají vnější směrovací protokoly ? • Kde byste hledali směrovací protokol BGP ? Nad jakým transportním protokolem

pracuje ? Jaké informace se v něm přenášejí ? • Vysvětlete princip šíření směrovací informace a výběru cest na bázi algoritmu

"path vector" používaného v protokolu BGP. • Jak v protokolu BGP administrativně ovlivnit výběr cest pomocí filtrace prefixů a

atributů ?


1.4 Podpora multimediálních aplikací v Internetu

1.4.1 Požadavky multimediálních aplikací na kvalitu služby (QoS)

Uspokojivá funkce současných multimediálních aplikací realizujících přenosy dat, hlasu i videa včetně konferencí v reálném čase je závislá na kvalitě přenosové služby poskytované počítačovou sítí. Donedávna nebyla kvalita služby v Internetu příliš řešena a směrování paketů se dělo výhradně metodou ”best effort“, kdy se síť sice snažila každý paket doručit k cíli, avšak v případě zahlcení nijak nerozlišovala mezi pakety důležitějšími a méně důležitými. V poslední době je snaha zabezpečit mechanismy, které dovolí provoz v síti priorizovat, nebo dokonce rezervovat přenosové pásmo pro určité konkrétní datové toky. Je důležité si uvědomit, že kvalita služby je ovlivněna všemi komponentami sítě, a to zejména

• stanicemi (pracovními stanicemi i servery)

• síťovými prvky (směrovači, přepínači)

• linkami (spojovací linky mezi směrovači, technologie LAN segmentů)

Podporu mechanismů zajišťujících dodržení parametrů kvality služby tak můžeme najít

Anotace: V této kapitole budou vysvětleny principy skupinového vysílání a mechanismy zajištění parametrů kvality služby pro implementaci provozu multimediálních aplikací v lokální i rozlehlé počítačové síti. Čtenář se seznámí se dvěma základními přístupy k implementaci QoS – modely Diffserv a Intserv.

Osnova: 1.4.1 Požadavky multimediálních aplikací na kvalitu služby (QoS)

1.4.1.1 Parametry QoS v paketových sítích 1.4.1.1.1 Omezování a tvarování provozu

1.4.1.2 Intserv a Diffserv - modely integrovaných a rozlišovaných služeb 1.4.1.3 Intserv

1.4.1.3.1 Rezervace zdrojů a protokol RSVP 1.4.1.4 Diffserv

1.4.1.4.1 Klasifikace provozu 1.4.1.4.2 Mechanismy priorizace provozu 1.4.1.4.3 Mechanismy předcházení zahlcení

1.4.1.5 Nasazování mechanismů řízení kvality služby 1.4.2 Skupinové vysílání v sítích s protokolem IP

1.4.2.1 Použití skupinového vysílání 1.4.2.2 Skupinové adresy na 2. a 3. vrstvě modelu OSI RM

1.4.2.2.1 Skupinové MAC adresy 1.4.2.2.2 Skupinové adresy v IPv4 a IPv6, výběrové adresy 1.4.2.2.3 Mapování skupinových IP adres na MAC adresy

1.4.2.3 Skupinové vysílání v LAN 1.4.2.3.1 Protokol IGMP

1.4.2.4 Skupinové vysílání ve WAN 1.4.2.4.1 Distribuční stromy 1.4.2.4.2 Reverse Path Forwarding


na všech vrstvách modelu OSI-RM.

1.4.1.1 Parametry QoS v paketových sítích Kvalita služby (nebo-li QoS z anglického „Quality of Service“) chápeme jako schopnost

sítě podporovat aplikaci bez omezení funkce nebo výkonu aplikace. Formálně definuje norma ITU-T E.800 kvalitu služby jako "souhrnný výsledek výkonnosti služby, který určuje stupeň spokojenosti uživatele služby". Z technického hlediska je kvalita služby měřitelná zejména hodnotami následujících parametrů:

• šířka pásma (bandwidth),

• zpoždění (delay),

• rozptyl zpoždění (jitter),

• ztrátovost paketů (packet loss).

Šířka pásma je limitována nejméně propustnou linkou mezi komunikujícími zařízeními, ale také mírou zatížení síťových prvků na cestě. Zpoždění v síti je způsobeno dvěmi příčinami. Pevná složka zpoždění je dána jednak dobou šíření signálu médiem a jednak tzv. serializačním zpožděním, které vznikne tak, že při průchodu paketu síťovým prvkem (směrovačem či přepínačem) je třeba vždy paket nejprve celý přečíst do paměti, rozhodnout o výstupním rozhraní a pak opět z paměti serializovat bit po bitu na výstupní linku. Zpoždění v každém síťovém prvku tak bude dáno podílem délky paketu a přenosové rychlosti5. Mimo pevné složky má zpoždění i složku proměnnou, která je způsobena čekáním paketu ve frontách jednotlivých síťových prvků na cestě. Právě různý způsob zacházení s pakety v jednotlivých síťových prvcích co do obsluhy front je jednou ze základních příčin rozptylu zpoždění, jehož vysoké hodnoty jsou nepříjemné zejména pro multimediální aplikace v reálném čase. Sjednocení způsobu zacházení s pakety určité třídy provozu ve všech síťových prvcích je jedním z postupů, jak vylepšit kvalitu služby poskytovanou paketovou sítí.

Příčinou ztrátovosti paketů jsou jednak chyby přenosu na fyzické vrstvě, může však jít i o zahazování paketů síťovými prvky. Síťové prvku typicky pakety zahazují buďto při přetížení procesoru přerušeními od vstupního provozu (tzv. input drops) nebo při přeplnění výstupních front (tzv. output drops). Ztrátovost paketů by měla být co nejmenší, multimediální aplikace jako přenos hlasu a videa jsou však k určitým ztrátám paketů tolerantní. Krátké výpadky totiž nemusí uživatel zaznamenat, nebo lze malé množství vypadlých vzorků přenášeného signálu dokonce částečně zrekonstruovat.

1.4.1.1.1 Omezování a tvarování provozu Před tím, než jsou pakety vůbec vpuštěny do sítě a předloženy k rozhodnutí, s jakou

preferencí mají být mají být síťovými prvky přeposílány, jsou na hranici sítě aplikovány mechanismy omezování provozu (traffic policing) s ohledem na to, jakou přenosovou kapacitu má uživatel s provozovatelem své sítě nebo poskytovatele Internetu smluvenu. Zde si je však třeba uvědomit, že charakter provozu u dnešních klient-server aplikací je velmi shlukový a často asymetrický. Proto se zpravidla nedefinuje jen maximální bitová rychlost, ale spíše jen množství bajtů, které je uživatel průměrně oprávněn přenést za určitý časový

5 U některých přepínačů sice není třeba rámec načítat celý, čekání na načtení alespoň části hlavičky obsahující cílovou adresu se však před zahájením předávání rámce na výstupní port nevyhneme.


interval a dále míra shlukovitosti, jakou provoz může vykazovat (tj. do jaké míry je možné množství bajtů, které nebyly přeneseny v předchozích intervalech přenést navíc v intervalu současném). Traffic policing je zpravidla realizován pomocí algoritmu Token Bucket [5].

Jelikož správcové uživatelských sítí připojených k poskytovateli znají úmluvy se svým poskytovatelem a tedy mohou odhadnout, jaký provoz již traffic policing poskytovatele nebude propouštět, je pro ně výhodné provoz na lince k poskytovateli tvarovat (tzv. traffic shaping). Tvarování provozu spočívá v pozdržení některých (typicky méně prioritních) paketů ve frontách tak, aby byly nepřípustné shluky rozloženy do delšího časového intervalu. Tím se sice zvětší zpoždění některých méně prioritních paketů, avšak zamezí se paušálnímu zahazování všech paketů mechanismem traffic policing u poskytovatele, jelikož uživatelem správně tvarovaný provoz již poskytovatelem vyžadovaným kritériím vyhoví.

Tvarování provozu je obzvláště užitečné v situacích, kdy fyzická přenosová rychlost rozhraní přesahuje dohodnutou průměrnou přenosovou rychlost. Jelikož podstatou tvarování provozu je dočasné pozdržování vysílaných paketů v bufferech směrovače, je nutné, aby příslušný směrovač disponoval odpovídajícím množstvím paměti RAM.

1.4.1.2 Intserv a Diffserv - modely integrovaných a rozlišovaných služeb V současných paketových sítích implementujeme dva základní modely pro zajištění

kvality služby -- rozlišované služby (differentiated services) a integrované služby (integrated services). Třetím modelem je původní strategie „best effort“ (absence podpory QoS) historicky dříve používaná v Internetu, kde se síť sice snaží o přenesení paketu, avšak bez jakékoli priorizace při vysílání paketů na zahlcenou výstupné linku i při volbě paketu, který bude zahozen, pokud se přeplňuje fronta příslušného rozhraní.

1.4.1.3 Integrované služby (intserv) Model integrovaných služeb (integrated services, IntServ) je založen na explicitní

rezervaci zdrojů sítě (kapacity linek, paměti ve frontách, podílu času CPU síťových prvků) pro jednotlivé datové toky ještě před zahájením přenosu. Je tedy nutná podpora explicitní rezervace v operačním systému, resp. v aplikačním software koncových stanic. Požadavky na rezervaci přenosového pásma stanice signalizují síťovým prvkům pomocí protokolu RSVP (Resource Reservation Protocol) . Model intserv je přirozený pro spojově orientované sítě (např. ATM), není však příliš vhodný pro sítě paketové. Důvodem je jeho malá škálovatelnost, kdy přes páteřní prvky typicky prochází značné množství (často i krátce trvajících) datových toků a tyto prvky nemají kapacitu udržovat pro všechny procházející toky stav související s rezervací pásma a dostatečně rychle obsluhovat rezervační požadavky pro desítky tisíc neustále vznikajících a zanikajících datových toků.

1.4.1.3.1 Rezervace zdrojů a protokol RSVP Protokol RSVP (RFC2205) definuje způsob signalizace od příjemce datového toku

postupně k aktivním prvkům na cestě ke zdroji určitého datového toku. Požadavek na rezervaci pásma se tedy šíří od příjemce toku proti směru toku a týká se konkrétního datového toku, ať již určeného pro unicast adresu nebo multicastovou skupinu. Rezervace může být unikátní pro jeden konkrétní tok (distinct reservation) nebo sdílená pro skupinu toků (shared reservation).


1.4.1.4 Diffserv Z důvodu špatné škálovatelnosti modelu Intserv je v dnešní době mnohem rozšířenější

model Diffserv. Na rozdíl od Intserv model Diffserv negarantuje absolutní dobu doručení dat, ale řeší pouze upřednostnění některých paketů před jinými (statistická preference). Při dostatečně dimenzovaných linkách a omezení provozu vstupujícího do sítě na úroveň, pro kterou jsou linky dimenzovány, zajišťuje model Diffserv požadovanou kvalitu služby, aniž by trpěl omezeným množství současných toků, jelikož na rozdíl od modelu Intserv neudržuje Diffserv pro jednotlivé datové toky žádnou stavovou informaci.

Principem Diffserv je klasifikace provozu do tříd na hranici sítě (nebo přímo na zdrojové stanici) označováním paketů podle třídy, do které náleží a jejich další zpracování na základě této značky. Značka třídy je připojena do hlavičky paketu (resp. rámce). Tříd bývá obvykle jen několik (zpravidla ne více než deset), takže problém škálovatelnosti zde nevyvstává. Pro každou třídu mají všechny síťové prvky definováno, jak mají s pakety patřící do dané třídy zacházet co do režimu uchovávání ve frontách (tzv. Per-Hop Behavior - PHB). Výhodou tohoto mechanismu je, že pakety jsou klasifikovány do tříd pouze jednou na hranici sítě a vnitřní prvky sítě již dále nemusí paket zkoumat, pouze aplikují příslušný PHB podle značky obsažené v hlavičce paketu. Také není třeba řešit příslušnost paketů k tokům a pakety lze zpracovávat jednotlivě jen na základě značky.

1.4.1.4.1 Klasifikace provozu Jak jsme se již zmínili, principem Diffserv je klasifikace a značkování provozu již

na vstupu do sítě, jejíž vnitřní prvky již označkování paketů důvěřují a podle značky na ně aplikují příslušné PHB. Klasifikaci lze realizovat buďto přímo v operačním systému stanice nebo na přístupovém prvku sítě (přepínači a následně na směrovači nebo integrovaně na L3 přepínači). Výhodou značkování stanicí je, že se děje přímo u zdroje dat (aplikace), který sám může nejlépe rozhodnout, do jaké třídy data zařadit a jak je označkovat. Na druhou stranu však může docházet k tomu, že uživatelé budou hledat způsoby, jak veškerý svůj provoz označkovávat jako prioritní a tím si vynucovat lepší kvalitu služby i pro své méně důležité aplikace na úkor jiných uživatelů. Proto se v praxi častěji realizuje značkování provozu na přístupovém síťovém prvku. To však představuje pro síťový prvek zvýšenou zátěž, jelikož musí sledovat provoz od uživatele, podle obsahu rozpoznávat použitou aplikaci a na základě toho jednotlivé pakety odpovídajícím způsobem značkovat (tzv- Network-Based Application Recongition). Použitelnost tohoto řešení je ovlivněna množstvím aplikací, které je síťový prvek schopen rozpoznávat a zda lze uživatelsky doplňovat signatury dalších aplikací. Klasifikovat provoz lze obecně podle informací z třetí (někdy i druhé) až sedmé vrstvy modelu OSI RM (např. protokolu, IP adres, TCP/UDP portů, URL, MIME typu, ...) nebo podle rozhraní, kterým provoz do síťového prvku vstupuje.

Při implementaci QoS si je třeba uvědomit, že PHB pro pakety určité třídy provozu je třeba respektovat po celé trase, tedy jak ve směrovačích intranetu nebo sítě WAN, tak v přepínačích koncových LAN segmentů. Jelikož standardní přepínače zpracovávají pouze hlavičku druhé vrstvy OSI RM, musí být pro ně značka určující třídu QoS umístěna do hlavičky 2. vrstvy. Protože původní hlavička rámce Ethernet žádné pole pro identifikaci třídy QoS neobsahovala, byl normou IEEE 802.1p definován nový standard, který před začátek dat dovolí vložit dvoubajtovou pomocnou hlavičku, ve které jsou vyhrazeny 3 bity pro specifikace jedné z 8 tříd Class of Service (CoS). Přítomnost rozšiřující hlavičky je indikována vyhrazenou hodnotou 0x8100 v poli EtherType (obr. 1.3) s tím, že původní hodnota EtherType je zopakována za přídavnou hlavičkou. Všimněme si, že rozšiřující


hlavička je současně využívána pro určení čísla VLAN, pokud přenášíme rámec přes trunk linku.

Na třetí vrstvě (tj. v hlavičce IP paketu) je třída provozu identifikována hodnotou v 8-bitovém poli DSCP (Differentiated Service Code Point) . Původně se jednalo o 3- bitové pole Type of Service (ToS) umožňující zvolit jednu z předdefinovaných 8 tříd IP Precedence, později však bylo toto pole při zachování zpětné kompatibility hodnot rozšířeno a nyní lze mimo původních 8 tříd použít ještě 64 různých dalších tříd provozu. Do pole DSCP však není možné vložit libovolnou hodnotu, jelikož je dále strukturováno – rozlišují se zde dvě kategorie služeb - Expedited Forwarding a Assured Forwarding. Expedited Forwarding (RFC2598) slouží jako jakási "virtuální pevná linka", tedy služba konec-konec s malými ztrátami, malým, ale proměnným zpožděním a garantovanou šířkou pásma. V rámci Assured Forwarding (RFC2597) jsou definovány 4 třídy a v z nich 3 precedence pro zahazování paketů daného typu provozu v případě potřeby. Zmíněné strukturování je však spíše pouze konvence, jak třídy provozu na síti rozdělovat - pro pochopení funkčnosti Diffserv není podstatné a proto se jim dále nebudeme zabývat - detaily lze najít např. v [4]

Když paket vstupuje do oblasti sítě podporující QoS, musí být označkován na 2. i na 3. vrstvě. Značka na 2. vrstvě umožní správně priorizovaný průchod rámce přepínanou částí sítě (typicky LAN), značka na 3. vrstvě pak odpovídající průchod směrovanou částí sítě po vybalení paketu z rámce na lokálním přístupovém směrovači na hranici páteře. Na směrovači na hranici cílové lokální sítě pak paket musí být opět zabalen do rámce označkovaného příslušnou prioritou podle 802.1p, aby i v posledním úseku sítě bylo s paketem zacházeno podle požadavků na příslušnou třídu provozu. Přístupový směrovač cílové sítě tak musí podle hodnoty DSCP v IP hlavičce vytvořit hodnotu CoS, kterou vloží do rámce, jenž ponese paket k cílové stanici. Mapování DSCP na CoS není jednoznačné, jelikož značky na 2. a 3. vrstvě mají rozdílný počet bitů. Mapování DSCP na CoS je obvykle na směrovači konfigurováno staticky.

1.4.1.4.2 Mechanismy priorizace provozu Dokud není linka, na kterou mají být síťovým prvkem směrovány pakety různých tříd

provozu zcela vytížena, není třeba mechanismy QoS vůbec aplikovat, protože by pouze přinášely zbytečnou režii6. Pakety jsou tedy na linku zasílány podle pravidla FIFO (First In-First Out). Pokud se však začíná plnit výstupní fronta některé linky, nastupují algoritmy, jež mají za cíl určit, který z paketů bude z fronty jako další vybrán a vyslán na linku. Cílem mechanismů zajištění QoS je pro datový tok garantovat alespoň určitou minimální šířku pásma, shora omezené zpoždění a minimální rozptyl zpoždění (jitter).

Technicky se priorizace provozu realizuje zavedením více front pro pakety odcházejících na každou jednotlivou linku a aplikací vhodného režimu obsluhy těchto front. Zpravidla se konfiguruje, které třídy provozu mají být zařazovány do které fronty. Provoz explicitně nevyjmenovaný bývá zařazován do implicitní (default) fronty. Nejčastěji se můžeme setkat s těmito režimy obsluhy front:

• Priority Queuing (PQ) – Fronty mají absolutní priority. Z fronty z větší prioritou se vybírá, dokud není prázdná, až pak může dojít na pakety čekající ve frontě s nižší prioritou. Front může být několik s prioritami od nejvyšší do nejnižší. Nevýhodou PQ je možnost tzv. vyhladovění (starvation) paketů ve frontách s nižšími prioritami,

6 až na výjimky, jako např. mechanismus Link Fragmentation & Interleaving


protože dokud tečou jakákoli data s prioritou vyšší, na data s nižší prioritou nikdy nedojde.

• Custom Queuing (CQ) – Pakety se střídavě (round robin) odebírají cyklicky ze všech front. U každé fronty je definováno, kolik bajtů se z ní smí při jednom průchodu nejvýše odebrat. Jedná se v podstatě o proporcionální cyklické přidělování kapacity každé třídě provozu

• Weighted Fair Queuing (WFQ) – Síťový prvek automaticky vyhledává datové toky v příchozím provozu, pakety toků zařazuje do dynamicky vytvářených front a tyto fronty cyklicky obsluhuje. K jednotlivým datovým tokům (určenými protokolem 4. vrstvy, IP adresami a porty transportní vrstvy komunikujících stran) se tak síťový prvek chová férově ve smyslu shodného přidělování částí pásma zahlcené linky. WFQ navíc preferuje kratší pakety, což vede k žádoucí preferenci interaktivního provozu. Slovo „weighted“ (váhovaný) v názvu metody říká, že podíl pásma přidělovaný jednotlivým datovým tokům je navíc ovlivněn hodnotou DSCP v paketech jednotlivých toků.

• Low-Latency Queuing (LLQ) – Jedná se v podstatě o WFQ s jednou další prioritní frontou. Během cyklu výběru z front pomocí WFQ se vždy mezi výběry z jednotlivých front obsluhovaných WFQ nahlédne do prioritní fronty a odebere z ní jeden paket.

Existují i složitější kombinované režimy obsluhy. Například metoda Class-Based Weighted Fair Queuing (CBWFQ) je vlastně kombinací Custom Queueing a Weighted Fair Queuing. Při této metodě jsou jednotlivé kategorie provozu rozdělovány do několika front, z nichž každé je přiřazena určitá část kapacity výstupní linky. Pakety explicitně nezařazené do žádné z front jsou ukládány do implicitní fronty, v rámci níž jsou vyhledávány datové toky a těm je ze zbývající kapacity výstupní linky přidělováno pásmo metodou WFQ.

Ne všechny mechanismy podporující zajištění kvality služby musí být realizovány pouze režimem obsluhy front. Poměrně častým problémem je zajištění malého zpoždění pro interaktivní aplikace s krátkými pakety, pokud jsou tyto provozovány na pomalých linkách (typicky pod 800 kbps), na nichž je významné serializační zpoždění a po kterých rovněž prochází datový provoz s dlouhými pakety. Aby nemohlo dojít k situaci, že vysílání dlouhého datového paketu obsadí linku na tak dlouhou dobu, že nebudou moci být vysílány krátké pakety interaktivní aplikace (např. IP telefonie) s požadovaným maximálním rozestupem, mohou být dlouhé pakety před zahájením vysílání fragmentovány a jednotlivé fragmenty proloženy pakety aplikací citlivých na zpoždění. Uvedený mechanismus bývá označován jako Link Fragmentation & Interleaving (LFI).

1.4.1.4.3 Mechanismy předcházení zahlcení V předchozí kapitole jsme popsali, jakým způsobem mohou síťové prvky řešit zahlcení

(congestion management). Existují však také mechanismy, jak zahlcení předcházet. Předcházení zahlcení (congestion avoidance) je založeno na zpomalování zdroje dat na principu ovlivňování zpětné vazby od přijímače. Zpomalovat tak lze samozřejmě jen toky, které takovouto zpětnou vazbu implementují. Přímo na transportní vrstvě je zpětná vazba vestavěna do protokolu TCP, který je v současné době používá převládající množství síťových aplikací.

Problémem, který v sítích bez správné implementace mechanismů QoS často nastává, je globální synchronizace TCP spojení. Jestliže totiž dojde ve směrovači k úplnému zaplnění výstupní fronty některé linky, jsou všechny další pakety určené pro tuto linku zahazovány


(mluvíme o tzv. tail drop, jelikož se zahazují pakety na konci fronty, resp. za ním). Pokud přes zmíněnou linku prochází větší množství TCP spojení, budou ze všech těchto spojení zahazovány pakety, takže nedorazí na přijímač, čímž ani vysílač neobdrží několik následných potvrzení. Na základě toho vysílač dojde k závěru, že síť je momentálně zahlcena, klesne s intenzitou vysílání na nulu a aplikuje pomalý exponenciální náběh intenzity vysílání (proceduru Slow start). Nepříjemné však je, že proceduru Slow start zahájí téměř ve stejném okamžiku všechny toky, které byly přerušeny následkem likvidace jejich paketů směrovačem z důvodu nedostatečné kapacity fronty. Zatížení v síti tak začne oscilovat mezi nulovým (všechny toky současně zahájily Slow start) a maximem, při kterém opět dojde k přeplnění front, zahazování paketů všech toků a opětovnému pomalému náběhu současně u všech toků. Podstata problému tkví v tzv. globální synchronizaci TCP spojení, kdy nejsou pomalé náběhy jednotlivých TCP spojení náhodně rozložené v čase, čímž by sumární intenzita toku na lince vedla k jisté průměrné hodnotě, ale vzájemně synchronizované a vytvářející pilovitý průběh zatížení sítě (obr. 1.23).

Obr. 1.23 Globální synchronizace TCP spojení

Globální synchronizaci lze efektivně předejít aplikaci mechanizmu nazývaného Random Early Discard (RED), resp. Weighted Random Early Discard (WRED). Jeho princip spočívá v tom, že při zaplnění fronty nad určitou hranici se začnou se vzrůstající pravděpodobností (exponenciálně úměrnou zaplnění fronty) zahazovat pakety. Tím se jedno z TCP spojení, kterému zahozený paket patřil, zbrzdí dříve než ostatní, jejichž data dosud stále procházejí. Slow start všech spojení tak nenastává synchronně při úplném zaplnění fronty a zahazování všech dalších paketů přicházejících do fronty (tail drop), jelikož některé spojení zahájí vlivem zásahu algoritmu WRED proceduru Slow start dříve, čímž celkové zahlcení linky klesne.

V praxi se RED častěji aplikuje ve váhované verzi WRED, kdy se při překročení hranice pro náhodné zahazování paketů přednostně zahazují pakety s nižší prioritou (DSCP). Pravděpodobnost zahození v tomto případě není jen funkcí míry naplnění fronty, ale i priority paketu.


Při aplikaci RED je třeba pamatovat na to, že tato metoda omezuje pouze toky nad TCP protokolem. Pro omezení toků nad protokolem UDP by bylo třeba ovlivňovat zpětnou vazbu na aplikační úrovni, pokud takovouto vazbu konkrétní aplikace vůbec implementuje.

1.4.1.5 Nasazování mechanismů řízení kvality služby Nasazování mechanismů podpory QoS do počítačové sítě zpravidla probíhá v těchto

krocích:

1. Zjištění provozovaných aplikací a jejich požadavků, monitorování stávajícího provozu.

2. Vytvoření strategie podpory QoS a aplikace příslušných mechanismů QoS.

3. Ověření chování mechanismů QoS. Zde se může ukázat, že výsledné chování sítě je z pohledu uživatelů horší, než před implementací. V této situaci je samozřejmě nutné strategii implementace QoS přehodnotit.

Úspěšnou implementací podpory QoS samozřejmě proces nekončí. Jelikož na živé síti postupně vyvstává potřeba provozu dalších a dalších aplikací, požadavky na QoS z pohledu uživatelů se budou neustále vyvíjet. Proto je třeba požadavky periodicky analyzovat a výše uvedené kroky vždy znovu opakovat.

1.4.2 Skupinové vysílání v sítích s protokolem IP

Pro implementaci multimediálních aplikací, při jejichž provozu je obvykle třeba distribuovat identický intenzivní tok dat k menší či velké skupině příjemců, je mimo podpory QoS užitečné v síti podporovat skupinové vysílání. Skupinové vysílání (angl. multicasting) znamená možnost vysílání pro určitou skupinu příjemců. Na rozdíl od všesměrového vysílání (broadcastingu), kdy je možno poslat paket všem příjemcům na lokální síti, však skupinové vysílání není omezeno hranicí lokální sítě. Příjemci skupinového vysílání mohou být rozprostřeni po rozlehlé síti nebo i po Internetu (resp. těch částech Internetu, které skupinové vysílání podporují).

Skupinové vysílání je výhodné použít všude tam, kde je třeba jednu informaci doručit skupině stanic, které mají o tuto danou informaci v jistém okamžiku zájem, aniž bychom museli jednotlivé proudy dat nesoucí požadovanou informaci od zdroje posílat nezávisle ke všem zájemcům. Zdroj generuje pouze jeden tok dat, které prvky síťové infrastruktury zasílají pouze do směrů, ve kterých leží zájemci o daný datový tok. Pro jednotlivé příjemce se pakety duplikují až v místech, kde se datový tok rozděluje do více větví sítě obsahujících příjemce multicastové skupiny (obr. 1.24). Spotřebované přenosové pásmo na linkách, za nimiž leží více příjemců, je tak výrazně menší, než kdyby jimi procházely toky generované zdrojem zvlášť pro jednotlivé příjemce.


Obr. 1.24 Srovnání zátěže při samostatných tocích a skupinovým vysílání

Způsob distribuce multicast paketů se poněkud liší v současných typických LAN a WAN sítích. V LAN je situace jednodušší že topologie neobsahují smyčky, takže není třeba řešit mechanismy vytváření logického stromu, po kterém se od zdroje budou multicast pakety šířit jen do větví sítě, kde je zájem o příjem příslušné skupiny.

1.4.2.1 Použití skupinového vysílání Praktických aplikací, ve kterých je tentýž tok dat užitečné distribuovat skupině zájemců,

je celá řada. Patří mezi ně zejména

• distribuce vysílání videa či hlasu (televize, rozhlas),

• videokonference mezi skupinou účastníků,

• vyhledávání služeb určitého typu v rozlehlé síti,

• distribuované simulace (včetně nejrůznějších typů internetových her).

1.4.2.2 Skupinové adresy na 2. a 3. vrstvě modelu OSI RM Filosofii skupin při skupinovém vysílání lze pojmout různým způsobem. Skupinové

vysílání v současných technologiích LAN i v protokolu IP využívá koncepce otevřených skupin. Otevřenost skupin znamená jednak to, že do skupiny se může přihlásit kterákoli stanice a jednak že do skupiny smí vysílat i stanice, která členem skupiny sama není. Stanice může být současně členem i více skupin. Přihlašování do skupiny je zcela v režii potenciálního přijímače každé skupiny, zdroj dat vysílající do skupiny nemůže žádným způsobem zjistit identitu ani počet příjemců, kteří v daném okamžiku data skupiny přijímají.

1.4.2.2.1 Skupinové MAC adresy Na druhé vrstvě OSI RM používá většina technologií LAN k adresování stanic MAC

adresy. Jejich rozsahy (první 3 bajty) jsou přidělovány jednotlivým výrobcům, kteří pak druhé tři bajty přidělují jednoznačně jednotlivým kusům jimi vyráběných síťových rozhraní. Mimo jednoznačně přidělených adres však MAC adresy mohou být i skupinové. IEEE definuje skupinové adresy jako ty, které mají první bit prvního bajtu MAC adresy vysílaného na médium nastaven na hodnotu 1 (zde si je dobré uvědomit, že u technologie Ethernet je to


nejméně významný bit-LSB). V souvislosti s protokolem IP se však jako skupinové MAC adresy využívají pouze adresy začínající na trojici bajtů 01-00-5E, jak bude vysvětleno v další kapitole.

Je důležité si uvědomit, že na 2. i 3. vrstvě mohou multicastové adresy být vždy jen adresami cíle - zdrojová adresa je vždy jednoznačná a identifikuje odesílatele dat. Této skutečnosti se využívá i při mnohých metodách distribuce dat skupinového vysílání k příjemcům ve WAN.

1.4.2.2.2 Skupinové adresy v IPv4 a IPv6, výběrové adresy V protokolu IPv4 je pro skupinové adresy vyhrazen rozsah adres třídy D, tedy adresy

224.0.0.0 až 239.255.255.255. Rozsah adres 224.0.0.0 - 224.0.0.255 je rezervován pro služební (zejména směrovací) protokoly vyměňující si informace pouze mezi sousedy na lokálním segmentu (TTL v hlavičce paketu je pro jistotu vždy nastaveno na 1). Pro aplikace univerzálního použití využívající multicastingu (např. NTP) přiděluje organizace IANA jednoznačné adresy z rozsahu 224.0.1.0 - 238.255.255.255. Adresy začínající trojicí bajtů 233.x.y mohou využívat bez dalších přidělovacích procedur správcové autonomního systému s číslem kódovaným do dvojice bajtů s hodnotami x a y (tzv. GLOP adresy). Existují také „privátní“ skupinové IP adresy s platností omezenou pouze na určitou oblast sítě 239.0.0.0 - 239.255.255.255, kterou nesmí opustit (tzv. Limited Scope Addresses, RFC 2365).

U protokolu IPv6 je skupinové vysílání využíváno ještě šířeji. Mimo otevřených skupin ve stylu IPv4 jsou zde definovány také tzv. výběrové adresy, umožňující vysílat nejen všem, ale jen „nejbližšímu“ členovi určité skupiny. Detaily lze najít v kapitole 1.2.2.1.

1.4.2.2.3 Mapování skupinových IP adres na MAC adresy V koncových lokálních sítích musíme řešit mechanismus mapování skupinových IP

adres na skupinové MAC adresy, podobně jako to pro individuální adresy řeší takovéto mapování protokol ARP. Mapování potřebujeme proto, abychom IP paket se skupinovou adresou mohli vložit do rámce a správně určit jeho cílovou MAC adresu.

Způsob mapování skupinových IPv4 adres na MAC adresy, který se v současné době ujal v praktických aplikacích se může zdát poněkud neefektivní, je to však dáno historickými důvody, za nichž v akademickém prostředí s omezenými prostředky na nákup rozsahů MAC adres mechanismus vznikal. Pro skupinové MAC adresy odpovídající skupinovým IPv4 adresám je vyhrazena polovina rozsahu daného prefixem 0x01-00-5E (všimněte si, že bit identifikující "multicast" v prvním bitu vysílaném na médium je nastaven). Z důvodu použití jen poloviny rozsahu adres začínajících na 0x01-00-5E je v nejvyšším bitu 4. bajtu MAC adresy vždy 0, takže pro mapování zbývá 23 bitů MAC adresy. Mapovaná IPv4 adresa má délku 32 bitů, ale protože všechny skupinové IP adresy patří do třídy D, začínají vždy kombinací bitů 1110, které není třeba mapovat. K mapování tedy zbývá 32-4=28bitů, které však musí být namapovány pouze na 23 bitů MAC adresy, jež jsou pro namapování k dispozici. Mapování se děje jednoduše tak, že se posledních 23 bitů skupinové IPv4 adresy přímo zkopíruje do posledních 23 bitů MAC adresy (obr. 1.25). Všimněme si, že 5 nejvyšších bitů skupinové IPv4 adresy se nemapuje, takže se vždy 32 multicast skupin protokolu IP mapuje na tutéž skupinovou MAC adresu. Například adresa 224.10.8.5 se mapuje na 01.00.5e.0a.08.05, stejně tak ale i další adresy vyjádřené binárním schématem 1110xxxx.x0001010.00001000.00000101, v němž hodnota bitu označeného symbolem x je libovolná.


Obr. 1.25 Mapování skupinových adres IPv4 na MAC adresy

Nejednoznačnost mapování, při kterém síťové rozhraní spolu s požadovanou skupinou přijímá rámce i 31 dalších skupin, řeší až ovladače IP protokolu, které nežádoucí pakety odfiltrují. Proto je vhodné adresy používaných skupin volit tak, aby k překrývání prakticky nedocházeno.

U skupinových adres IPv6 je mapování poněkud jednodušší. Je pevně stanoven 2-bajtový prefix multicastových MAC adres a nejnižší 4 bajty IPv6 adresy se přímo kopírují do nejnižších 4 bajtů MAC adresy, jak je detailněji vysvětleno v kap. 1.2.2.1.

1.4.2.3 Skupinové vysílání v LAN

Skupinové vysílání v lokální síti je poměrně jednoduché, jelikož topologie lokální sítě neobsahuje smyčky. Výjimkou je kruhová topologie, zde však rámec vždy po oběhu kruhem odstraňuje stanice, která jej vyslala. Pokud jsou stanice připojeny na sdílené médium, rámec vyslaný pro skupinu stanic slyší všechny stanice. Je tedy na jednotlivých stanicích, zda rámec přijmou či nikoli. Pokud aplikace (resp. operační systém) na některé stanici rozhodne, že chce přijímat rámce určité skupiny, pouze instruuje hardware síťové karty, je má mimo rámců s její vlastní cílovou MAC adresou přijímat i rámce s MAC adresou některé konkrétní multicastové skupiny.

Poněkud složitější může být situace v síti obsahující přepínače. Díky použití protokolu Spanning Tree ani zde nikdy nevzniká smyčka, takže lze multicastové rámce stejně jako broadcast rámce bez nebezpečí kopírovat na všechny porty mimo příchozího, čímž se dostanou ke všem stanicím. Přesně tímto způsobem se k multicastům chovají levné přepínače. Dokonalejší přepínače však dokáží zohlednit fakt, že na rozdíl od broadcast rámců není třeba multicast pakety kopírovat všude, ale pouze do větví, ve kterých se vyskytují příjemci dané multicastové skupiny. To se mohou dozvědět buďto nahlížením do protokolu IGMP (viz. dále), kterým si stanice vyžádávají od lokálního směrovače provoz multicastové skupiny (tzv. IGMP Snooping) nebo od speciálního (proprietárního) protokolu zavedeného mezi lokálním směrovačem a přepínačem, jímž směrovač přepínači sděluje, které MAC adresy u něj projevily zájem o příjem multicastové skupiny s adresou mapovanou na určitou skupinovou MAC adresu.

1.4.2.3.1 Protokol IGMP Pokud se stanice na LAN chtějí přihlásit k příjmu provozu určité multicastové skupiny,

použijí k tomu protokol IGMP (Internet Group Membership Protocol, RFC1112). Jeho


prostřednictvím signalizují lokálnímu směrovači, že má požádat směrovače v páteři o rozšíření distribučního stromu, aby pokrýval segment s přijímačem. Podobně mohou stanice signalizovat protokolem IGMP i situaci, že chtějí příjmu provozu určité skupiny zanechat. Směrovač lokálního segmentu v tomto případě ještě dotazem ověří, zda na segmentu skutečně nezbývá žádná další stanice se zájmem o provoz skupiny a v negativním případě zasílání multicastů na lokální segment ukončí a do WAN zašle žádost o prořezání distribučního stromu. Jelikož přijímač multicastového provozu může být nekorektně vypnut, aniž by informoval pomocí IGMP lokální směrovač, ověřuje směrovač periodickými dotazy na segmentu, zda stanice mají o příjem své multicastové skupiny stále ještě zájem.

1.4.2.4 Skupinové vysílání ve WAN Distribuce multicast paketu ve WAN obsahující smyčky vyžaduje konstrukci

tzv. distribučního stromu, jehož větve budou pokrývat všechny části WAN obsahující zájemce o příjem dané multicastové skupiny. Kořenem distribučního stromu je buďto směrovač sítě, kde je umístěn zdroj multicastů nebo dohodnutý směrovač na který zdroje multicastů tunelem posílají své pakety, pokud nechceme pro skupinu vytvářet tolik distribučních stromů, kolik je zdrojů skupinového vysílání.

Směrovač ve WAN síti musí na základě znalosti své pozice v distribučním stromu rozlišit, zda rozhraní, kterým multicast pakety přichází, vedou ke kořeni distribučního stromu a určit rozhraní, za kterými existují aktivní příjemci dané multicastové skupiny. Na základě informace o pozici směrovače v distribučním stromu pro danou skupinu si směrovače pro účely šíření multicastu budují zvláštní formu směrovací tabulky, obsahující informaci, které rozhraní vede ke zdroji multicastů a která do větví obsahující příjemce.

1.4.2.4.1 Distribuční stromy Distribuční strom tvoří acyklický podgraf grafu topologie sítě zahrnující všechny sítě,

na nichž jsou přijímače dané multicastové skupiny. Jak se do skupiny přihlašují nové přijímače a odhlašují existující, musí se do stromu připojovat nové větve a odstraňovat větve neaktuální (mluvíme o „roubování“ a "prořezávání" stromu, angl. „grafting“, resp. "pruning").

Existuje několik přístupů, jak distribuční strom konstruovat. Podle toho, kam je umístěn kořen stromu rozlišujeme stromy na zdrojové (Source Tree, někdy též Shortest-Paths Tree) a sdílené (Shared Tree). Šíření provozu po stromě může být buďto jednosměrné (od kořene k listům) nebo obousměrné, při kterém se provoz šíří všemi směry od zdroje umístěného v některém (nekořenovém) uzlu stromu. Zdrojový strom jako strom nejkratších cest ze zdroje ke všem sítím s přijímači skupiny představuje optimální, ale málo škálovatelné řešení. Provoz má sice nejmenší zpoždění, ale pro každý zdroj vysílání do každé multicastové skupiny musí existovat samostatný strom (ten se označuje < S,G >, kde S je zdrojová adresa, G je adresa multicastové skupiny). Příklad zdrojového stromu je vidět na obr. 1.26.


Obr. 1.26 Zdrojový distribuční strom (vyznačen šipkami)

Sdílený strom je naproti tomu společný pro všechny zdroje ve skupině. Kořenem je vhodně zvolený směrovač (tzv. Rendezvous point, RP). Zdroje svá data zasílají na RP, ze kterého se pak šíří směrem dolů po distribučním stromě. Sdílené stromy se označují notací < *,G >, kde hvězdička informuje, že strom používají všechny zdroje přispívající do skupiny G. Pro mutlicastovou skupinu pak postačí jediný strom bez ohledu na počet přispívajících zdrojů. Nevýhodou je poněkud delší cesta paketů od zdroje k přijímačům přes RP a tím i větší zpoždění. Příklad zdrojového stromu ukazuje obr. 1.27.

Obr. 1.27 Sdílený distribuční strom(vyznačen šipkami)

Některé multicastové směrovací protokoly používají nejprve sdílený strom, který spotřebovává méně systémových zdrojů a až v případě příliš intenzivního provozu z některé zdrojové adresy (S) se zřídí pro danou multicastovou skupinu a tento zdroj < S,G > strom. Pokud existuje v multicastové směrovací tabulce záznam < S,G > i < *,G > a multicastový paket vyhoví oběma z nich, bude se směrování provádět podle specifičtějšího (< S,G >)


záznamu po zdrojovém stromě.

1.4.2.4.2 Reverse Path Forwarding Pro vytváření distribučního stromu byla postupně navržena celá řada mechanismů.

Historicky prvním byl protokol DVMRP (Distance Vector Multicast Routing Protocol, RFC1075), který na obdobném principu jako RIP vyhledává nejkratší cesty ke všem zdrojům skupinového vysílání. Dále bylo navrženo rozšíření protokolu OSPF pro multicast (MOSPF) spočívající v tom, že jednotlivé směrovače formou LSA inzerují k nim připojené zájemce o jednotlivé multicastové skupiny a všechny směrovače na základě toho počítají strom nejkratších cest pokrývající přijímače jednotlivých skupin. V současné době se však téměř výhradně používá směrování na základě informace o zpětné cestě, tzv. Reverse Path Forwarding (RPF), které může být dále optimalizováno s použitím protokolu PIM (Protocol Independent Multicast).

Reverse Path Forwarding je metoda šíření multicast paketů od zdroje vysílání (resp. RP) po distribučním stromu. Je důležité si uvědomit, že při směrování multicastů se na rozdíl od běžného směrování směrovače orientují podle zdrojové adresy. Smyslem je paket šířit po distribučním stromu stále dál od zdroje vysílání (resp. RP), aniž by docházelo k jeho cyklování.

K určení rozhraní, kterými se má příchozí multicast paket dále rozesílat, slouží běžná (unicast) směrovací tabulka, vybudovaná jakýmkoli standardním směrovacím protokolem nebo i zadaná staticky. Proto hovoříme o směrování multicastů nezávislém na směrovacím protokolu (protocol independent multicast)

Z pohledu distribučního stromu pro danou multicastovou skupinu (a případně pro daný zdroj u < S,G > stromu) dělíme rozhraní každého směrovače na "downstream" a "upstream". Upstream rozhraní je právě jedno a vede směrem ke kořeni distribučního stromu. Je to rozhraní, kterým se vysílají běžné (unicast) pakety na adresu odpovídající kořeni distribučního stromu. Downstream rozhraní jsou rozhraní, která vedou do segmentů sítě, v nichž se vyskytují příjemci dané multicastové skupiny, ať už přímo stanice nebo další směrovače, které mají takové příjemce za svými downstream rozhraními.

Po rozdělení rozhraní směrovačů při směrování provozu určité skupiny na upstream a downstream můžeme vcelku jednoduše zajistit směrování provozu multicastové skupiny s vyloučením cyklení pomocí jednoduchého pravidla, nazývaného RPF Check, které můžeme formulovat takto:

Pokud multicast paket přišel z rozhraní, které se podle (unicast) směrovací tabulky používá pro směrování paketů ke zdrojové adrese multicastového paketu, resp. adrese RP (tedy upstream rozhraní), paket se rozešle na downstream rozhraní. V opačném případě se paket zahodí.

Pravidlo RPF Check zajistí rozšíření multicast paketu po celém distribučním stromě a vyloučí cyklování paketů ve smyčce. Pokud předpokládáme, že downstream rozhraní jsou všechna kromě jediného upstream rozhraní, zajistí se tím rozšíření paketu do celé sítě. Samotný RPF check však nedokáže zaručit, že multicast paket neprojde některou síti vícekrát, jak je ukázáno na obr. 1.28.


Obr. 1.28 Duplikování části provozu při použití RPF check

Pro vyloučení tohoto případu je třeba mezi směrovači připojenými na tutéž síť zavést speciální protokol, kterým se mezi sebou dohodnou, který z nich bude na síť provoz multicastové skupiny šířit (bude to ten, který má k síti se zdrojem lepší metriku ve směrovací tabulce) . To je právě jedna z funkcí protokolu PIM. Dalšími funkcemi PIM jsou prořezávání větví, ve kterých nejsou žádní příjemci multicastové skupiny nebo naopak připojování větví, ve kterých se zájemci o skupinu objevili. Pomocí PIM se také směrovače na segmentu domlouvají, který z nich bude pomocí protokolu IGMP periodicky ověřovat, zda zájem příjemců o jistou multicastovou skupinu stále trvá (viz kap. 1.4.2.3.1). Řídící zprávy pro pořezání nebo připojení větve do distribučního stromu se vždy zasílají o úroveň distribučního stromu výše směrem ke kořeni (tj. zdroji multicast provozu nebo RP). Správný směr se určí pomocí standardní směrovací tabulky jako nejkratší cesta k síti se s adresou kořene distribučního stromu. Podle těchto zpráv se pro danou multicastovou skupinu na směrovačích rozšiřuje nebo naopak omezuje množina downstream rozhraní. Záznamy multicastové směrovací tabulky pak popisují aktuální stav distribučního stromu dané skupiny v okolí směrovače a pro zdrojové stromy budou mít tvar

< cílová multicast adresa, adresa zdroje multicastu, upstream rozhraní,

množina downstream rozhraní >

Při použití zdrojového stromu musí směrovače na distribučním stromu udržovat tolik záznamů, kolik je vysílačů v multicastové skupině. Pro sdílené stromy se uchovává pro celou skupinu pouze jediný záznam, který bude mít tvar

< cílová multicast adresa, upstream rozhraní, množina downstream rozhraní >

Směrovače mimo distribuční strom dané skupiny nemusí o multicastové skupině uchovávat žádnou informaci.

Ke konstrukci distribučních stromů lze principiálně přistoupit dvěma způsoby. Jeden z nich bývá označován jako hustý režim (Dense mode), druhý jako řídký (Sparse Mode). V hustém režimu se předpokládá, že zájemci o multicastovou skupinu jsou skoro na všech segmentech sítě. Proto je provoz implicitně směrován do všech segmentů (všechna rozhraní


směrovačů mimo upstream jsou na počátku považována za downstream). Pokud směrovač při příjmu multicastového paketu zjistí, že na žádném svém rozhraní nemá zájemce o multicastovou skupinu, pošle směrovači ve vyšší úrovni distribučního stromu žádost o "prořezání" (prune). Směrovač ve vyšší úrovni stromu na jejím základě přestane do větve multicastový provoz dané skupiny vysílat. Pokud se ve větvi časem objeví zájemce o multicastovou skupinu, může lokální směrovač segmentu větev do distribučního stromu opětovně přihlásit.

V řídkém režimu nejsou naproti tomu multicast pakety implicitně zasílány nikam. Většina větví by totiž z důvodu řídkého výskytu příjemců byla multicasty zaplavována zbytečně. Až když se na segmentu objeví zájemce o danou skupinu, pošle se směrem ke kořeni žádost o připojení nové větve distribučního stromu. Po této větvi pak k novému zájemci poteče provoz požadované multicastové skupiny.

Připojení větve do distribučního stromu v řídkém režimu nebo její prořezání v režimu hustém není trvalé. Každý směrovač distribučního stromu si totiž žádost o připojení, resp. prořezání pamatuje pouze po jistou omezenou dobu a po jejím vypršení přejde k původnímu chování. Proto se musí žádost o připojení a prořezání větve distribučního stromu periodicky opakovat.

Žádosti o připojení a prořezání větve stromu se mezi směrovači zpravidla zasílají prostřednictvím zpráv protokolu PIM. Z hlediska směrovače tak není rozdílu, jestli mulicastový provoz na rozhraní vyžaduje na segmentu připojená stanice nebo jiný směrovač, který multicastový provoz požaduje pro segmenty na jeho rozhraních.

V řídkém režimu se na řízení směrování účastní méně směšovačů - pouze ty, které vytvářejí obvykle ne příliš rozvětvený distribuční strom. Proto jsou protokoly pracující v řídkém režimu vhodnější pro rozlehlé WAN sítě.

Protokol PIM umí podporovat jak řídký, tak hustý režim – hovoříme pak o protokolu PIM v hustém (PIM-DM) nebo řídkém (PIM-SM) režimu. V současné době se v Internetu používá téměř výhradně protokolu PIM-SM.


KONTROLNÍ OTÁZKY

• Uveďte konkrétní parametry přenosu, které určují kvalitu služby poskytovanou sítí. Co vše ovlivňuje hodnoty těchto jednotlivých parametrů ?

• Vysvětlete pojmy omezování a tvarování provozu (Traffic Policing a Traffic Shaping). Jaký je smysl aplikace těchto mechanismů a kde se typicky aplikují ?

• Vysvětlete rozdíl mezi Differentiated Services a Integrated Services. Jaké jsou výhody a nevýhody obou těchto přístupů k zajištění QoS ?

• Vysvětlete pojem klasifikace provozu. Kde se provoz klasifikuje, kam se umísťuje značka a jak může značka ovlivnit další zpracování paketu či rámce v síťových prvcích ?

• Jaké režimy obsluhy front znáte a jaké jsou jejich výhody, nevýhody a typické použití ?

• Vysvětlete smysl a princip předcházení zahlcení metodou (Weighted) Random Early Discard.

• Popište výhody skupinového vysílání (multicastingu) a typické aplikace, ve kterých se používá

• Jaké adresy IP a MAC adresy se využívají pro skupinové vysílání ? • Popište způsob mapování multicastových IP adres na MAC adresy. Je mapování

jednoznačné ? Jak se nejednoznačnost vyřeší ? • Vysvětlete, k čemu slouží protokol IGMP a jak funguje. • Popište možnosti, jak mohou přepínače zpracovávat multicasty. Vysvětlete princip

techniky IGMP Snooping. • Vysvětete pojem distribučního stromu pro šíření multicastů. Vysvětlete rozdíl mezi

stromem nejkratších cest (Shortest Path Tree) a sdíleným stromem (Shared Tree). V čem spočívají výhody/nevýhody obou typů ?

• V čem se liší hustý (dense) a řídký (sparse) režim konstrukce distribučního stromu? • Vysvětlete princip směrování multicastů s použitím mechanismu Reverse Path

Forwarding.


1.5 Bezpečnost počítačových sítí

Zajištění bezpečnosti počítačových sítí, která byla ještě donedávna dosti opomíjena, se v dnešní době stává prakticky samozřejmostí. To do značné míry souvisí s tím, že použití informačních systémů i počítačem řízených procesů je dnes běžné a na jejich funkčnosti jsou již mnohé instituce přímo závislé. Současně je třeba tyto systémy bránit proti zneužití neoprávněnými osobami, ať už ve smyslu vyřazení z funkce nebo odcizení či modifikace citlivých dat. Toto riziko samozřejmě narůstá v prostředí, kdy prakticky veškeré organizace provozující počítačové sítě jsou alespoň nějakým způsobem připojeny k Internetu.

Přestože se to řada manažerů v IT domnívá, bezpečnost sítí nelze zajistit jednorázově a ani nákupem libovolného drahého a výkonného zařízení. Zajištění bezpečnosti sítě je totiž neustálý proces, který zahrnuje nejen implementaci technických opatření, ale také stanovení a vynucování

Konkrétní politiky k používání sítě, včetně sankcí pro uživatele za její za porušení. Jelikož se však požadavky instituce na provozované aplikace a způsoby sdílení informace mezi uživateli neustále vyvíjejí, musí být i bezpečnostní politika organizace periodicky revidována.

Je třeba si uvědomit, že implementace bezpečnostní politiky je vždy pro uživatele omezující. Smyslem rozumného návrhu bezpečnostní politiky je najít vhodný kompromis mezi pohodlím uživatelů a bezpečností sítě tak, aby síť mohla nepřetržitě a efektivně pomáhat v práci svým uživatelům.

Anotace: Tato kapitola seznamuje se základy problematiky bezpečnosti počítačových sítí. Budou vysvětleny základní pojmy z kryptografie a představeny nejpoužívanější postupy pro ochranu přenášených dat i síťové infrastruktury.

Osnova: 1.5.1 Základní pojmy

1.5.1.1 Utajení, integrita a autentizace 1.5.1.2 Symetrický a asymetrický kryptografický systém

1.5.1.2.1 Autentizace v symetrickém a asymetrickém systému 1.5.2 Bezestavová a stavová filtrace provozu

1.5.2.1 Bezestavová filtrace pomocí ACL 1.5.2.2 Stavová filtrace pomocí firewallu

1.5.3 Virtuální privátní sítě (VPN) 1.5.3.1 Použití VPN 1.5.3.2 Technologie VPN na 3. a 4. vrstvě modelu OSI RM

1.5.3.2.1 IPSec 1.5.3.2.2 SSL VPN

1.5.4 Útoky na počítačové sítě 1.5.4.1 Útoky typu Denial of Service 1.5.4.2 Detekce útoků a obrana proti průnikům

1.5.5 Bezpečnostní mechanismy přepínaných a směrovaných sítí 1.5.5.1 Možnosti zabezpečení v přepínaných sítích LAN 1.5.5.2 Základní zabezpečení v intranetech a WAN s protokolem IP


Druhým mnohdy opomíjeným faktem je, že problematika bezpečnosti nezahrnuje pouze síťovou infrastrukturu jako takovou (inspekce provozu a filtrace nežádoucích toků, obrana před útoky na síťové prvky) ale i operační systémy koncových stanic. Síťové prvky mohou účinně pomáhat proti šíření virů mezi koncovými stanicemi a také proti útokům typu Denial of Service, kdy se útočník pokouší zahlcením serveru nebo využitím známých slabin v software přivést operační systém nebo software serveru k havárii. Zamezení šíření virů je ovšem důležité i pro správce síťové infrastruktury, poněvadž infikované stanice mohou útočit i na síťovou infrastrukturu, v nejjednodušším případě pokusem o její zahlcení.

Mimo zabezpečení síťové infrastruktury a koncových stanic zahrnuje problematika bezpečnosti sítí samozřejmě i otázky zabezpečení dat přenášených mezi uživateli, které se bude věnovat následující kapitola.

1.5.1 Základní pojmy Data přenášena sítí mezi uživateli nebo síťovými službami procházejí mnohými linkami

a síťovými prvky, o jejichž provozovatelích komunikující strany nic nevědí. Proto je často potřeba data při přenosu šifrovat. Také budeme chtít zajistit, aby u dat nemohla být podvržena identifikace jejich odesílatele. Ujednoťme si nejprve termíny používané v oblasti kryptografie, tedy vědy zabývající se utajením dat při jejich přenosu.

1.5.1.1 Utajení, integrita a autentizace

Pojmem utajení (angl. confidentality) rozumíme přenos dat takovým způsobem, že cizí posluchač naslouchající na přenosovém kanále významu přenášených dat nerozumí. Autentizace (angl. authentication) zdroje dat dává příjemci jistotu, že odesílatel dat je skutečně tím, za koho se vydává. Zajištěná integrita dat (data integrity) dává příjemci jistotu, že data nebyla na cestě nikým zmodifikována.

Pro praktické aplikace je také často užitečná nepopiratelnost (angl. non-repudiation), což je mechanismus zajišťující, že zdroj dat nemůže popřít, že jistá konkrétní data odeslal.

1.5.1.2 Symetrický a asymetrický kryptografický systém Kryptografickým systémem rozumíme systém, který na straně odesílatele dat šifruje

zprávu (angl. plain text), přenáší ji zašifrovanou (angl. cyphertext) a na straně příjemce původní zprávu dešifruje (obr. 1.29 ). Šifrování lze principiálně realizovat dvěma způsoby. Prvním z nich je vyvinout konkrétní šifrovací algoritmus a ten přede všemi mimo příjemce utajit. V případě prozrazení je však (možná i hardwarová) implementace takovéhoto systému k ničemu. Proto se zpravidla používá druhý způsob a to použít (i veřejně známý) algoritmus, jenž však bude parametrizován pomocí klíčů, které jediné musí zůstat utajeny. Podmínkou je pouze to, aby bylo dost možných klíčů, aby útočník nebyl schopen jednoduše vyzkoušet všechny z nich.


Šifrování Dešifrování

Klíč

plaintext

plaintext

cypertext

Klíč Obr. 1.29 Šifrování a dešifrování informací během přenosu

S ohledem na způsob zacházení s klíči rozlišujeme kryptografické systémy symetrické a asymetrické. U symetrického systému je použit sdílený klíč, totožný na vysílači a přijímači. Existuje řada rychlých, efektivních a i hardwarově dobře implementovatelných symetrických algoritmů (DES, 3DES, AES). Problémem je však distribuce klíčů, aby se klíč používaný vysílačem dostal pouze a jedině k zamýšlenému příjemci. Toto je třeba typicky zajistit osobním předáním nebo jiným dostatečně bezpečným způsobem nesouvisejícím se sítí přenášející šifrovaná data.

Naopak v asymetrickém systému se klíče generují jako doplňující se pár - veřejný (public) a soukromý (private) klíč. Jeden z těchto klíčů je vždy použit pro šifrování, druhý pro dešifrování. Je lhostejné, který z nich bude použit k čemu. Výhodou je, že generování páru si může každý uživatel uskutečnit lokálně, privátní klíč si bezpečně ukrýt a veřejný klíč zveřejnit. Na obr. 1.30 je vidět, jak uživatel Alice při přenosu zprávy uživateli BOB zašifrovala zprávu všem dostupným veřejným klíčem uživatele BOB (KB_PUBLIC) a jedině uživatel BOB, vlastnící svůj soukromý klíč (KB_PRIVATE), je schopen tímto soukromým klíčem zprávu dešifrovat.

Šifrování Dešifrování

veřejnýklíč

KB_PUBLIC

ALICE BOB

soukromý klíč

KB_PRIVATE

KB_PUBLICKB_PRIVATE

KA_PUBLICKA_PRIVATE

Certifikačníautorita

KA_PUBLICKB_PUBLIC

Obr. 1.30 Šifrování veřejným a soukromým klíčem

V asymetrickém systému odpadá problém s utajenou distribucí klíčů. Používané algoritmy (např. RSA, El-Gammal) jsou však mnohem složitější, náročnější na výpočty a tudíž pomalejší. Asymetrický systém se tak typicky využívá pro předávání (dynamicky generovaných a periodicky měněných) klíčů pro symetrické šifrování.

I v asymetrickém systému však narážíme na problém s bezpečnou distribucí veřejných klíčů. Obsah klíče sice již nemusí být utajen, ale musíme zabránit jeho podvržení. Pokud by např. na obr. 1.30 místo veřejného klíče KB_PUBLIC podvrhnul zlovolný uživatel C svůj veřejný klíč KC_PUBLIC , byl by C schopen zprávu od A dešifrovat, avšak uživatel B nikoli. Uživatel A by přitom nic nepoznal.

Podvržení veřejně distribuovaných veřejných klíčů se obvykle zabraňuje s použitím tzv. certifikační autority. Certifikační autorita je instituce, které je veřejně důvěřováno a


která svým privátním klíčem “podepisuje“ certifikáty jednotlivých uživatelů. Certifikátem rozumíme blok dat tvořený jednak veřejným klíčem a jednak identifikací vlastníka veřejného klíče. Pravost podpisu lze ověřit pomocí veřejného klíče certifikační autority, která certifikát podepsala. Jednotlivým uživatelům tak stačí spolehlivým způsobem získat jediný veřejný klíč certifikační autority, který mu již zajistí ověření pravosti veřejných klíčů ostatních uživatelů. Veřejné klíče některých obecně používaných certifikačních autorit bývají typicky vypáleny na originálních instalačních CD a instalovány spolu s operačním systémem.

1.5.1.2.1 Autentizace v symetrickém a asymetrickém systému Šifrování v symetrickém i asymetrickém systému je realizováno konkrétním šifrovacím

algoritmem. Podívejme se ale nyní, jak lze v obou těchto systémech prakticky zrealizovat autentizaci a na ní se vážící zabezpečení integrity dat.

V symetrickém systému založeném na sdíleném tajemství (hesle) mezi vysílačem a přijímačem můžeme uživatele autentizovat jednoduše tak, že jeho uživatelské jméno zašifrujeme klíčem a na přijímači je opět dešifrujeme a porovnáme se seznamem autorizovaných uživatelů. Pokud nemáme na přijímači správný klíč, dešifrováním vznikne nesmyslný řetězec a ten v seznamu uživatelů nenajdeme. Jestliže chceme pouze ověřit identitu odesílatele, aniž bychom k tomu potřebovali seznam uživatelských jmen na přijímači, můžeme postupovat tak, že na vysílači nejprve ke jménu uživatele připojíme jeho otisk (hash) a celou zprávu poté zašifrujeme. Přijímač, který zprávu jako celek dešifruje, pak může smysluplnost dešifrované informace ověřit tak, že z dešifrovaného uživatelského jména stejnou hash funkcí jako předtím vysílač vypočte otisk a srovná jeho shodu s dešifrovaným otiskem.

Pro výpočet otisku používáme vhodnou jednosměrnou funkci (hash), která z velkého bloku dat vypočte tzv „otisk“ – blok několika bajtů, jenž blok dat charakterizuje. Hash funkce je volena tak, aby nebylo možné najít a podvrhnout jiný text zprávy, který bude mít stejný otisk jako zpráva původní.

Společně s autentizací odesílatele se zpravidla implementuje i zajištění integrity přenášených dat.

Zajištění integrity mezi uživateli sdílejícími tajný klíč se realizuje tak, že odesílatel v paměti za zprávu připojí sdílený tajný klíč a z celého bloku [zpráva+sdílený tajný klíč] vypočte otisk. Poté vyšle původní zprávu a otisk celé dvojice. Přijímač pak za došlou zprávu v paměti připojí sdílený klíč a stejnou hash funkcí jako vysílač vypočte otisk. Ten poté srovná s otiskem, který spolu se zprávou vyslal vysílač.

V asymetrickém systému se autentizuje poněkud odlišným způsobem, na kterém jsou mj. založeny i elektronické podpisy. Princip je vidět z obr. 1.31. Uživatel Alice chce poslat zprávu uživateli Bob. Z dat nejprve vypočte otisk a ten zašifruje svým soukromým KA_PRIVATE . Data zprávy zašifruje veřejným klíčem Boba, který jako jediný může zprávu dešifrovat svým soukromým klíčem KB_PRIVATE . Mimo to Bob prověří, zda zprávu vyslala Alice tak, si z dešifrované přijaté zprávy sám spočítá otisk a dešifrovaný otisk od Alice dešifruje všem dostupným veřejným klíčem Alice KA_PUBLIC. Dešifrování proběhne úspěšně pouze v případě, že byl otisk zašifrován soukromým klíčem Alice, který vlastní jedině ona. A pouze v případě úspěšného dešifrování otisku se bude dešifrovaný otisk zprávy shodovat s otiskem vypočteným Bobem a Alice bude považována za autentizovaného odesílatele přijaté zprávy.


Data

KB_PUBLIC

ALICE BOB

KA_PRIVATE

KB_PUBLICKB_PRIVATE

KA_PUBLICKA_PRIVATE

Porovnání

Hash Data

KB_PRIVATE KA_PUBLIC

Hash

Hash

Obr. 1.31 Autentizace v asymetrickém systému

1.5.2 Bezestavová a stavová filtrace provozu Zabezpečení operačních systémů a na nich běžícího software před útoky nebo

neoprávněným přístupem v prostředí počítačové sítě se nejjednodušeji řeší vhodnou filtrací nežádoucího provozu. Filtrace může probíhat buďto na úrovni inspekce jednotlivých paketů za použití tzv. paketových filtrů, výsledkem jejichž vyhodnocení je vždy propuštění nebo zahození kontrolovaného paketu. Hovoříme zde o filtraci bezestavové, jelikož jednotlivé pakety jsou kontrolovány nezávisle na sobě, aniž by se filtrující zařízení (typicky směrovač) snažil rekonstruovat datový proud nesený pakety, které k sobě logicky patří. Bezestavová filtrace se tedy děje pouze na základě dat obsažených v paketu, nikoli podle „stavu“ logického spojení zprostředkovávaného jednotlivými pakety.

Náročnější variantou filtrace je filtrace stavová, při které si filtrující zařízení z procházejících paketů rekonstruuje obsah jednotlivých datových toků. Tímto zařízením může být buďto proxy server, nakonfigurovaný v jednotlivých komunikujících zařízeních jako prostředník-firewall, nebo může být filtrující zařízení pro komunikující účastníky zcela transparentní (typicky realizováno jako inteligentní most). Stavová filtrace dovoluje filtrovat na základě chování aplikačních protokolů na 7. vrstvě OSI RM, avšak platí za to omezenou škálovatelností, kdy pro každé jednotlivé spojení je třeba udržovat v paměti jeho stav a procesor musí nahlížet nejen do hlaviček, ale i do aplikačních dat.

1.5.2.1 Bezestavová filtrace pomocí ACL Implementačně nejjednodušší metodou filtrace je inspekce jednotlivých procházejících

paketů bez ohledu na ostatní pakety, s nimiž společně tvoří jeden datový tok. Výhodou je, že není třeba procházející pakety rozřazovat do datových toků a udržovat informaci o každém z nich, nevýhodou zase skutečnost, že můžeme kontrolovat pouze korektnost dat zcela obsažených v jednom paketu, nikoli tedy nebezpečná data rozložená do více samostatných paketů7.

Nejčastější forma implementace bezestavové inspekce paketů jsou tzv. Access Control Lists (ACL). ACL je v podstatě filtr umístěný na některé rozhraní aktivního prvku. Zpravidla se jedná o směrovač nebo L3 přepínač, i když i některé přepínače dovolují vložit na port nebo VLAN ACL filtrující podle zdrojové nebo cílové MAC adresy, popřípadě typu protokolu 3. vrstvy. Dále se budeme zabývat jen ACL na směrovačích, které budou kontrolovat informace ze 3., popřípadě 4. vrstvy OSI RM. 7 Nebezpečí pro úspěšné použití bezestavové inspekce plyne i z fragmentace.V hlavičce fragmentů s výjimkou prvního totiž není záhlaví 4. vrstvy, takže podle něj nelze filtrovat. Lze to řešit např. timeoutem na propouštění fragmentů se shodnou hodnotou v poli Identification spouštěným prvním fragmentem, ale to již nese potřebu ukládat stavovou informaci. Častá implementace kontroluje 4. vrstvu jen je-li v IP hlavičce Fragment Offset=0 (tedy u prvního fragmentu), ostatní fragmenty propouští. To přináší nebezpečí, pokud první fragment úmyslně nepřenáší celou hlavičku 4. vrstvy.


ACL je sekvence položek zakazujících nebo povolujících průchod paketů vyhovující kritériím definovaným danou položkou. Při průchodu paketu rozhraním, na němž je ACL aplikován, se postupně odshora procházejí jednotlivé položky ACL, až se narazí na první položku, jejímž kritériím zkoumaný paket vyhovuje. Podle toho, zda je položka definována jako příkaz k propuštění vyhovujícího paketu nebo k jeho zahození se pak paket propustí nebo zlikviduje. Další položky ACL se pak už dále nezkoumají. Na konci ACL typicky bývá implicitní položka přikazující „zahodit vše“, vlivem čehož ACL respektují filosofii „co není explicitně povoleno, je zakázáno“.

Při návrhu filtrace provozu pomocí ACL je vždy třeba stanovit

• na kterém rozhraní kterého směrovače bude ACL aplikován,

• zda bude filtrovat provoz vstupující do tohoto rozhraní nebo z tohoto rozhraní vystupující,

• jaká kritéria způsobující propuštění nebo zahození procházejících paketů bude ACL obsahovat.

Zabezpečení sítě není zpravidla možné zajistit pouze jedním ACL, ale kombinuje se funkčnost několika různých ACL umístěných na vhodná rozhraní. Na každé rozhraní lze typicky umístit vždy jeden ACL filtrující provoz vstupující do rozhraní a jeden ACL filtrující provoz vystupující.

Při aplikaci bezestavové filtrace zpravidla postupujeme tak, že nejprve analyzujeme aplikace, které v síti hodláme podporovat. Definice požadavků v konkrétním prostředí může vypadat například takto (viz obr. 1.32):

• Firma provozuje svůj vlastní poštovní server (SMTP) přístupný zvenčí na adrese 158.196.135.103.

• Firma provozuje svůj vlastní WWW server (HTTP, HTTPS) přístupný zvenčí na adrese 158.196.135.102.

• Přístup lokálních klientů ke službě WWW (HTTP i HTTPS) jde výhradně přes proxy server s adresou 158.196.135.101.

• Ze stanic na LAN lze do Internetu otevírat pouze spojení SSH.

• DNS server provádějící rekurzivní vyhledávání jmen pro všechny klienty na LAN je u poskytovatele Internetu (ISP) na adrese 200.1.1.100.

• Je povolen ping z LAN do Internetu, v opačném směru však z bezpečnostních důvodů nikoli.

• Vzdálený administrátor je schopen připojit se odkudkoli z Internetu na počítač s WWW serverem pomocí služby SSH.


Obr. 1.32 Příklad bezpečnostní politiky realizované pomocí ACL

U každé aplikace přesně zjistíme, jaký protokol transportní vrstvy a jaké porty tohoto protokolu používá. Komplikaci přinese případ, kdy zjistíme, že aplikace si porty volí dynamicky a zvolená čísla portů předává účastníkům komunikace v aplikačním protokolu.

Následně rozhodneme, na kterém rozhraní směrovače chceme provoz filtrovat. V typickém případě používáme jeden ACL pro filtraci provozu dovnitř firemní sítě a jiný pro filtraci provozu ven Následně definujeme obsah jednotlivých ACL s tím, že nesmíme zapomínat na povolení zpětného směru provozu. Obvykle je dobré vycházet ze zásady, že implicitně je vše zakázáno a pouze provoz protokolů explicitně vyjmenovaných v ACL je povolen. Zvláštní pozornosti musíme dbát, pokud ACL aplikujeme na směrovači při jeho vzdálené správě, abychom neodfiltrovali protokol, pomocí něhož směrovač vzdáleně konfigurujeme.

U situace vyobrazené na obrázku 1.32 by analýza používaných protokolů mohla vypadat např. jako v tabulce 1.1.

Tab. 1.1 Použité aplikační protokoly

Služba (aplikační protokol)

Protokol Port serveru

HTTP TCP 80

HTTPS TCP 443

SMTP TCP 25

DNS UDP 53

ping ICMP Zprávy Echo request a Echo reply

Internet

e0

s0firelmní LAN

158.196.135.0/24

.1

Administrátor(vzdálený přístup)

WWW proxy.101 uživatelé

LAN

DNS Server (u ISP)200.1.1.100

WWW server (HTTP.HTTPS)

.102

SMTP.103

cizí uživatelé(potenciální škůdci)


Žádná z použitých služeb nevyužívá dynamicky přidělované serverové porty. Naopak porty klientů jsou vždy přidělovány dynamicky operačním systémem, takže jejich hodnotu ACL nekontroluje.

Dále bychom zavedli dva ACL, označili je a přiřadili k nim rozhraní a směr toku, který budou filtrovat. V našem případě označíme číslem 101 ACL na rozhraní s0 filtrující provoz vstupující do tohoto rozhraní, tedy do vnitřní sítě. Číslem 102 označíme ACL filtrující provoz vstupující do rozhraní e0. Filtraci bychom tedy prováděli ještě před tím, než necháme směrovač vyhledávat cílové rozhraní při směrování přicházejících paketů.

Obsah ACL 101 a 102 můžeme vyjádřit bez ohledu na syntaxi používanou konkrétní implementací ACL tabulkami podobnými Tab. 1.2 a Tab. 1.3.

Tab. 1.2 Filtrace provozu přicházejícího z Internetu - ACL 101 (s0, in)

Pořadí položky

Povolení / zákaz Protokol

Zdrojová IP adresa

Zdrojový port

Cílová IP adresa

Cílový port

poznámka

1 zakázat IP 158.196.135.0/24 * anti-spoofing filtr (podvržení src IP)

2 povolit TCP * * 158.196.135.103 25 SMTP do LAN 3 povolit TCP * * 158.196.135.102 80 HTTP do LAN 4 povolit TCP * * 158.196.135.102 443 HTTPS do LAN 5 povolit TCP * * 158.196.135.102 22 SSH do LAN

na stroj WWW serveru

6 povolit UDP 200.1.1.100 53 158.196.135.0/24 * DNS odpovědi 7 povolit ICMP * 158.196.135.0/24 odpovědi ping

(zpráva Echo reply)

8 povolit TCP * 80 158.196.135.101 * odpovědi pro HTTP proxy

9 povolit TCP * 443 158.196.135.101 * odpovědi pro HTTPS proxy

10 povolit TCP * 22 158.196.135.0/24 * odpovědi SSH klientům

11 zakázat IP * * zákaz ostatního provozu

Tab. 1.3 Filtrace provozu odcházejícího z LAN - ACL 102 (e0, in)

Pořadí položky

Povolení / zákaz Protokol

Zdrojová IP adresa

Zdrojový port

Cílová IP adresa

Cílový port

poznámka

1 povolit TCP 158.196.135.101 * * 80 HTTP z WWW proxy do Internetu

2 povolit TCP 158.196.135.101 * * 443 HTTPS z WWW proxy do Internetu

3 povolit TCP 158.196.135.0/24 * * 22 SSH do Internetu 4 povolit UDP 158.196.135.0/24 * 200.1.1.100 53 DNS dotazy 5 Povolit ICMP 158.196.135.0/24 * dotazy ping (Echo

request) 6 povolit TCP 158.196.135.103 25 * * odpovědi cizím SMTP

klientům 7 povolit TCP 158.196.135.102 80 * * odpovědi cizím

klientům HTTP 8 povolit TCP 158.196.135.102 443 * * odpovědi cizím

klientům HTTPS


9 povolit TCP 158.196.135.102 22 * * odpovědi administračního SSH

10 zákaz IP * * zákaz ostatního provozu

Implementaci výše uvedeného příkladu ve formě ACL pro operační systém Cisco IOS lze najít v [6].

Při návrhu ACL je třeba mít neustále na zřeteli, že nestačí povolit datový tok povoleného aplikačního protokolu pouze ve směru k serveru, ale i „odpovědi“ ve směru opačném. Při tom si je třeba vždy ujasnit, že čísla zdrojového a cílového portu budou pro zpětný směr přehozená. Nerespektování tohoto faktu je nejčastější chybou při konfiguraci ACL.

Implementace ACL mohou být nejrůznějším způsobem vylepšovány. Časté a užitečné rozšíření je například uvedení časového intervalu, ve kterém má konkrétní položka ACL platit. Tím je např. možné v pracovních hodinách zakázat přístup na WWW servery nesouvisející s pracovní činností a v mimo ně přístup umožnit.

1.5.2.2 Stavová filtrace pomocí firewallu Stavovou filtraci na základě nedovolených aktivit detekovaných v datových tocích aplikačních protokolů realizuje zpravidla firewall (obr. 1.33). Ten může být pro komunikující strany transparentní nebo ve funkci proxy serveru.

Obr.1.33 Funkce firewallu

Firewall oddělují důvěryhodnou a nedůvěryhodnou část sítě, zkoumá datové toky mezi nimi a podle nakonfigurovaných pravidel je dovoluje nebo naopak zakazuje. Implementace firewallu může být buďto „hardwarová“ (specializované zařízení) nebo „softwarová“ s použitím vhodného operačního systému (Linux, NetBSD, …)

Firewally se často implementují ne pouze se dvěma rozhraními jako na obr. 1.33, ale s dalším třetím rozhraním, ke kterému je připojena tzv „demilitarizovaná zóna“ (DMZ). V DMZ se typicky vyskytují servery, které mají být přístupny jak z vnitřní sítě, tak z Internetu. Tyto servery (tzv. „bastillon hosts“) mají řádně zabezpečený operační systém, aby nemohlo dojít k jejich napadení. Na servery v DMZ smějí přistupovat jak uživatelé z vnitřní sítě, tak uživatelé z Internetu. Přímý přístup uživatelů z Internetu do vnitřní sítě je však zakázán.

INTERNET

Firewall

Vnitřní síťorganizace

iMac

iMac

WWW server iMacuživatel

hacker

uživatel

iMac

hacker


1.5.3 Virtuální privátní sítě Virtuální privátní sítě (VPN) jsou mechanismem, umožňujícím organizacím budovat

„privátní“ sítě s použitím sdílené infrastruktury, např. veřejného Internetu. Při tom je ale dosaženo stejné úrovně Flexibility a bezpečnosti, jako při použití vlastní infrastruktury. Princip VPN spočívá v tunelování šifrovaných dat přes sdílenou infrastrukturu za použití autentizace mezi jednotlivými konci tunelů (obr. 1.34). Tunelem zde rozumíme virtuální dvoubodové spojení přes sdílenou infrastrukturu, které nese pakety jednoho protokolu zabalené v jiném (nebo i tomtéž) protokolu. Obalujícím protokolem je v Internetu vždy IP, protokolem tunelovaným může být také IP, lze ale přenášet i jiné síťové protokoly (např. Novell IPX) nebo dokonce přímo rámce 2. vrstvy OSI RM.

Obr. 1.34 Implementace VPN s použitím firewallů a veřejné infrastruktury

Výhodou použití VPN oproti udržování vlastní privátní infrastruktury je nižší cena, flexibilita (virtuální) topologie dána pouze konfigurací firewallů/směrovačů na koncích VPN tunelů. O realizované virtuální topologii nemusí poskytovatel sdílené infrastruktury nic vědět. Také odpadá potřeba dozoru nad vlastními WAN linkami, který je přenechán poskytovateli veřejné infrastruktury.

1.5.3.1 Použití VPN VPN bývají nejčastěji aplikovány ve dvou základních modelech – virtuální propojení

sítí a připojování vzdálených uživatelů.

Model s tunelem mezi směrovači (firewally) lokalit propojených s použitím VPN přes veřejný Internet je vidět na obr. 1.35. Obecně lze vytvářet i složitější topologie tunelů mezi více lokalitami.


Obr. 1.35 VPN propojující dvě odlehlé lokality

Obrázek 1.36 ukazuje připojení vzdálených uživatelů do domovské sítě prostřednictvím směrovače/firewallu ukončujícího tunely od jednotlivých uživatelů, tzv. VPN koncentrátoru. Konec tunelu na straně uživatele je vytvářen pomocí speciálního software, který má uživatel nainstalován – obvykle hovoříme o tzv. VPN klientu.

Obr. 1.36 Použítí VPN klienta pro bezpečný přístup do intranetu

Při připojení uživatele přes operátora telekomunikační sítě připadá v úvahu i varianta, že tunel z intranetu organizace nebude ukončen až u uživatele, ale na přístupovém serveru (Network Access Server, NAS) realizujícím přemostění spojení od uživatelů sítě operátora do Internetu. Této varianty se však v naších podmínkách zatím příliš nevyužívá.

1.5.3.2 Technologie VPN na 3. a 4. vrstvě modelu OSI RM Z praktického hlediska lze šifrování a autentizaci využívající principů uvedených v kap.

1.5.1 realizovat na všech vrstvách OSI modelu a to třeba i na více vrstvách současně. Můžeme


se např. setkat s šifrováním na 2. vrstvě, to však není pro komunikaci v Internetu příliš efektivní, protože zpráva musí být vždy při každém přeskoku mezi směrovači znovu a znovu šifrována a dešifrována. Naopak šifrování na 7. vrstvě bude sice efektivní v tom, že každá aplikace může zvolit optimální algoritmus s ohledem na charakter přenášených utajovaných dat, avšak nevýhodou bude, že jednotlivé aplikace budou muset bezpečnostní mechanismy implementovat opakovaně jako součást svého vlastního kódu. V praxi se také setkáváme s šifrováním na principu vkládání bezpečnostní vrstvy SSL (Secure Sockets Layer) nad protokol TCP, to však není použitelné pro aplikace využívající na transportní vrstvě datagramově orientovaný protokol UDP. Proto se z praktického hlediska jeví výhodné řešit bezpečnost na vrstvě síťové, čímž zajistíme nezávislost na konkrétní síťové technologii a současně i na aplikaci. Standard, který řeší šifrování, autentizaci a zabezpečení integrity dat u protokolu IP se nazývá IPSec a je dnes chápán jako vcelku široce implementované rozšíření protokolu IPv4.

1.5.3.2.1 IPSec IPSec (RFC2401) je architektura pro zajištění autentizace, integrity dat a šifrování,

technicky realizovanou pomocí dynamicky navazovaných zabezpečených tunelů na síťové vrstvě OSI RM. Není závislá na konkrétních algoritmech, jedná se spíše o obecný framework, v rámci něhož se mezi konci tunelů konkrétní šifrovací a autentizační algoritmy dynamicky dohadují.

Soubor parametrů dohodnutých pro šifrování a autentizaci mezi konci tunelu se nazývá bezpečnostní asociace (Security Association, SA). SA obsahuje informaci o dohodnutých šifrovacích a autentizačních algoritmech a příslušné klíče. Pro každý směr provozu je dohodnuto zvláštní SA a každá SA má omezenou životnost, takže se bezpečnostní parametry periodicky mění, což ztěžuje potenciálním útočníkům odposlech.

Technicky se dynamická dohoda SA mezi konci tunelu realizuje pomocí protokolu IKE (Internet Key Exchange), což je konkrétní implementace protokolu pro bezpečnou dohodu klíčů vyhovující obecnému rámci pro protokoly tohoto určení nazývanému ISAKMP (Internet Security Association and Key Management Protocol). Parametry pro autentizaci a šifrování jednotlivých paketů se přenášejí přímo v těchto paketech v pomocných hlavičkách, nazývaných Authentication Header (AH) a Encapsulating Security Payload (ESP). AH zabezpečuje autentizaci odesílatele a chrání integritu IP hlavičky i přenášených dat a také obsahuje ochranu před útoky zachycením provozu a jeho zopakovaným přeposíláním (tzv. replay útoky). Novější ESP hlavička může zajistit všechny tyto funkce a navíc šifrování.

Je samozřejmé, že IP hlavička, kterou potřebují směrovače sítě pro přenos paketu k cíli, nemůže být šifrována. Také při použití autentizaci IP hlavičky si musíme uvědomit, že nemůže být použita spolu s mechanismy, které hlavičku modifikují, například s překladem adres (NAT).

IPSec může pracovat v jednom ze dvou režimů – transportním a tunelovém (obr. 1.37). Transportní režim zajišťuje bezpečnost mezi koncovými zařízeními a vyžaduje podporu operačních systémů koncových stanic. Hlavičky AH, resp. ESP jsou zde vkládány mezi hlavičky 3. a 4. vrstvy, takže data od transportní vrstvy výše jsou šifrována. Originální IP hlavička samozřejmě šifrována není, ale je chráněna mechanismem autentizace a zabezpečení integrity dat.


Obr. 1.37 Tunelový a transportní režim IPSec

Častěji se můžeme setkat s režimem tunelovým, kdy je zřízen tunel mezi směrovači (tzv. IPSec branami) připojujícími LAN považované na bezpečné na nebezpečnou sdílenou infrastrukturu. IPSec brány tunelují a detunelují pakety z koncových zařízení, která nemusí o IPSec vůbec vědět. Tunelují se celé pakety z lokálních sítí včetně hlaviček, takže není ani možné odposlouchat, které konkrétní stanice z tunelem propojených sítí spolu komunikují.

Nevýhodou IPSec je, že jej lze použít pouze pro protokol IP a nepodporuje ani multicast provoz. To však lze v některých případech technicky obejít tak, že provoz jiných protokolů nebo provoz multicastový před předáním do IPSec jednoduše zabalíme do protokolu IP.

Druhou nevýhodou je, že provoz IPSec nesmí omezovat operátor sdílené infrastruktury. Vložení hlaviček AH a ESP je v originální IP hlavičce indikováno číslem protokolu vyšší vrstvy 51, resp. 50 a původní číslo protokolu transportní vrstvy je uvedeno až v přídavné hlavičce. Také provoz protokolu IKE vyžaduje průchodnost datagramů UDP na portu 500. Operátor podporující IPSec proto musí implementovat případné paketové filtry tak, aby provoz těchto protokolů neomezil.

1.5.3.2.2 SSL VPN Nejnovějším typem VPN je technologie založená na kombinaci symetrické a

asymetrické kryptografie, nejčastěji nazývaná SSL VPN (Secure Socket Layer Virtual Private Network) [7].

Termínem SSL VPN je dnes označována řada často vzájemně nekompatibilních technologií, nicméně všechny jsou postaveny na stejné základní myšlence. Je jí využití asymetrické kryptografie a knihoven SSL (Secure Socket Layer) pro šifrovanou komunikaci. Protože SSL VPN pracují na transportní vrstvě, je jejich použití pro síťovou infrastrukturu (a tedy i poskytovatele Internetu) transparentní.

Prakticky se SSL VPN technologie realizuje nejčastěji jako SSL brána (obr. 1.38), což úplně neodpovídá definici VPN. SSL brána je zařízení mezi vnitřní síti obsahující standardní služby a vzdáleným klientem realizujícím šifrování svého připojení pomocí protokolu SSL. K využití SSL VPN často není třeba žádný specializovaný software na straně klienta, protože se vzdálenou SSL bránou je možné komunikovat i standardním HTTPS protokolem a tedy přes běžný WWW prohlížeč. SSL brána emuluje obě protistrany jak klientovi tak i serveru. Provádí dešifrování příchozím požadavků a šifrování odpovědí serveru předtím, než je odešle zpět klientovi. SSL relace existuje tedy mezi SSL bránou a vzdáleným počítačem.


Obr. 1.38 SSL VPN se SSL bránou

Konkrétní funkce SSL brány se může pro jednotlivé scénáře použití i dosti odlišovat. Pro aplikační protokoly, které je možné adaptovat na protokol HTTP, je někdy výhodné použít SSL brány provádějící překlad aplikačního protokolu (obr. 1.39). Klient této služby je standardní webový prohlížeč s podporou HTTPS a také server může zůstat zcela bez modifikací. Překlad aplikačního protokolu je zcela záležitostí brány a z pohledu klienta i serveru je transparentní.

Obr. 1.39 Překlad aplikačního protokolu

Další variantou implementace SSL brány je použití předávání portů (port forwarding), viz obr. 1.40. Vzdálený klient zde ze SSL brány získá komponentu (Java, ActiveX), která bude ve vzdáleném stroji vystupovat jako VPN SSL Proxy. Klientská aplikace (prohlížeč) bude komunikovat přímo s touto komponentou, jako by se jednalo o lokální proxy server. Lokální proxy server (komponenta) provádí port forwarding. Mění tedy cílovou adresu IP paketu (případně cílový TCP port) v závislosti na původním cílovém TCP portu v paketu zaslaném klientem. SSL relace je tedy navázána přímo mezi komponentou vzdáleného klienta a SSL bránou. SSL brána žádným způsobem nemanipuluje s obsahem zasílaných dat, pouze spravuje mapování portů příchozích SSL relací na cílové adresy a porty serverů a jejich aplikací. Problémem při této koncepci jsou služby, které nepoužívají jeden fixní port, ale rozsah dynamicky přidělovaných portů (např. služba FTP).

Obr. 1.40 Předávání portu


1.5.4 Útoky na počítačové sítě Útoky na počítačové sítě mohou mít velmi různorodý charakter. Rozlišujeme pokusy

o průnik, kdy se útočník dostává k zařízením, ke kterým měl být provoz od něj filtrován a útoky, kdy se útočník pokouší úplně zničit, případně ve svůj prospěch modifikovat chování sítě nebo serveru poskytujícího jistou službu.

1.5.4.1 Útoky typu Denial of Service V dnešní době se nejčastěji setkáváme s útoky, jejichž cílem je zhroucení infrastruktury

oběti a zamezení funkčnosti jí poskytované služby. Proto hovoříme o útocích typu „Denial of Service“ (DoS). Cílem je zpravidla diskreditovat provozovatele služby před svými uživateli (zákazníky), což oběti může přinést nemalé finanční ztráty.

Cílem útočníka provádějícího DoS útok je vyčerpání systémových prostředků síťového prvku nebo serveru a jeho zhroucení nebo změna požadovaného chování ve prospěch útočníka (např. zhroucení systému obrany proti útočníkovým dalším aktivitám). Systémovými prostředky, o jejichž vyčerpání může být usilováno, jsou typicky paměť, procesorový čas nebo šířka pásma jistého segmentu sítě.

DoS útoky zpravidla přicházejí z podvržených zdrojových adres, aby útočníci obešli případné paketové filtry. Nejnebezpečnější jsou DoS útoky v distribuované variantě (Distributed Denial of Service Attacks, DDoS), kdy na útoku spolupracuje velké množství útočníků rozmístěných na různých místech Internetu. Nebezpečí DDoS útoků spočívá hlavně v tom, že charakter útočného provozu se mění rychleji, než stačí správce reagovat a škodlivý provoz analyzovat a odfiltrovávat.

1.5.4.2 Detekce útoků a obrana proti průnikům Pro detekci útoků a průniků dnes existuje celá řada systému, obecně nazývaná Intrusion

Detection Systems (IDS). Tyto systémy neustále sledují provoz na sítí a na základě podezřelých vzorů chování vyhodnocují stavy, které mohou s jistou pravděpodobností indikovat nějaký typ útoku. Vyhledávání provozu indikujícího útok je věcí dosti komplikovanou a může zahrnovat jak různé heuristiky, tak i prvky umělé inteligence. Způsob reakce na oznámené riziko je v IDS již ponechán na administrátorovi. U systému typu IPS (Intrusion Prevention Systems) je automatizace dotažena dále – při vyhodnocení rizika je automaticky provedeno opatření, aby byl další provoz od útočníka odfiltrován. Typicky se jedná o automatickou definici a aplikaci vhodného ACL.

Systémy pro detekci a prevenci útoků jsou nezbytné zejména v souvislosti s distribuovanými DoS útoky, u kterých již není v lidských silách dostatečně rychle reagovat na měnící se charakter strojově generovaného útočného provozu a aplikovat příslušná protiopatření.

1.5.5 Bezpečnostní mechanismy přepínaných a směrovaných sítí Zabezpečit síť před útoky je úkol velmi komplexní. Potenciální rizika jsou samozřejmě

závislá na použitých technologiích a protokolech a není možné zabývat se jimi v tomto textu v plné šíři. Proto si dále ukážeme jen nejzákladnější možnosti zabezpečení v lokálních sítích založených na přepínačích a ve směrovaných sítích s protokolem IP.


Pro bezpečnost sítě je samozřejmě nejdůležitější zabezpečení managementu síťových prvků, aby neoprávněná osoba nemohla změnit jejich konfiguraci. Je třeba používat vhodné přístupové heslo a vyhnout se manažovacím protokolům, které heslo přenášejí v nešifrované podobě (Telnet, HTTP, SNMP). Je vhodné pomocí ACL specifikovat zdrojové adresy, ze kterých může být management uskutečňován, také bývá užitečné pro management vyhradit samostatnou VLAN. Často opomíjeno také zůstává zabránění neoprávněnému fyzického přístupu k zařízení, bez něhož jsou ostatní způsoby zajištění bezpečnosti managementu zpravidla k ničemu.

1.5.5.1 Možnosti zabezpečení v přepínaných sítích LAN V přepínaných lokálních sítích patří mezi základní zabezpečení omezení zařízení

vpouštěných do sítě pouze na zařízení autorizovaná. Chceme zpravidla zajistit, že na jistý port přepínače může být připojeno jen určité konkrétní zařízení nebo naopak že jisté zařízení se smí připojit jen na určitou množinu portů. Na mnohých přepínačích lze u portu explicitně vyjmenovat zdrojové MAC adresy, zařízení, které se smí přes daný port připojovat. Často také máme možnost omezit počet MAC adres na portu, což zabraňuje útokům typu source-spoof DoS, u kterých útočník generováním velkého množství rámců s různými podvrženými zdrojovými MAC adresami dosáhne přeplnění přepínací tabulky a následného rozesílání rámců na všechny porty, kde mohou být odposlouchávány. U některých přepínačů také můžeme využít dynamického zařazování zařízení do VLAN na základě zdrojové MAC adresy, popsaného v kapitole 1.1.2.2.

Dalším typickým způsobem zabezpečení je omezení provozu mezi porty přepínače. Na port může být u některých přepínačů aplikován ACL, který filtruje podle zdrojové či cílové MAC adresy, někdy i podle informací ze síťové a transportní vrstvy. ACL lze také někdy aplikovat na veškerý provoz procházející jistou VLAN jako celkem.

Užitečná je také možnost zákazu vzájemné komunikace mezi klientskými porty, kdy je klientům dovolen přístup pouze na porty se servery nebo vedoucí do páteřní sítě. Tím se zabrání nežádoucím aplikacím typu peer-to-peer často nelegálně provozovanými mezi uživateli (hry, chat, DirectConnect apod.).

Vpouštění do sítě na základě identifikace konkrétního hardwarového zařízení je nevýhodné v tom, že nezabrání vpuštění útočníka, který oprávněné zařízení zcizil. Jedno zařízení také může být legálně sdíleno několika uživateli. Proto je často výhodné vázat oprávnění k přístupu ne na konkrétní zařízení, ale na uživatele s tímto zařízením pracujícího. Uživatel se v takovém případě před připojením do sítě musí autentizovat různými formami hesel nebo certifikátů, které jsou přístupovému přepínači předány pomocí k tomu určeného protokolu IEEE 802.1x. Přístupový přepínač autentizační parametry uživatele ověří u autentizačního serveru (typicky RADIUS-Remote Access Dial-In User Server) a pouze v případě pozitivního výsledku autentizace provoz z portu, kterým je uživatel připojen, do sítě vpustí.

Dosti užitečné je také chránit v přepínaných sítích protokol Spanning Tree. Pro útočníka totiž často může být výhodné přitáhnout k sobě kořen stromu, protože přes ten bude procházet velká část provozu. Na portech, kde mají být připojeny pouze klientské stanice, je tedy vhodné filtrovat vstupující BPDU, aby tyto nemohly chování algoritmu Spanning Tree nežádoucím způsobem ovlivnit.


1.5.5.2 Základní zabezpečení v intranetech a WAN s protokolem IP V sítích s protokolem IPv4 přináší velké riziko možnost zneužití protokolu ARP.

Jelikož MAC adresy strojů, jimž má být zaslán paket s určitou IP adresou jsou hledány dynamicky, existuje zde riziko falešných odpovědí na ARP dotaz, jimiž může stanice na sebe stáhnout provoz určený pro stanici jinou. Zabránit tomu lze pouze tak, že protokol ARP zcela vypustíme a na celém segmentu vložíme do ARP cache záznamy pro všechny komunikující stanice staticky. Jelikož toto není příliš praktické a v případě jakékoli změny v připojených stanicích je třeba ARP cache všech strojů rekonfigurovat, setkáváme se se statickým vkládáním záznamů do ARP obvykle jen u směrovačů – výchozích bran segmentů LAN.

V sítích, ve kterých je použit dynamický směrovací protokol, je dobré se chránit také proti falešné směrovací informaci generované útočníkem. V některých směrovacích protokolech (RIPv2, OSPF, EIGRP, BGP) mohou být zdroje směrovací informace (sousedé) autentizováni pomocí hesla nebo ještě lépe pomocí otisku zprávy, na směrovači lze také aplikovat ACL definující adresy, ze kterých jsou směrovací informace akceptovány. Cesty propagované sousedy lze před dalším zpracováním také filtrovat.

Samostatnou kapitolou je bezpečnost systému DNS. Jelikož v současné době ještě příliš nejsou implementována rozšíření dovolující autentizovat zdroje informace, existuje zde reálné riziko podvržení informací z DNS a tím i falešného mapování doménových jmen na IP adresy, které může klienty zavést na podvržené servery. Podobně lze podvrhnout například falešné MX záznamy, čímž může být odchozí pošta pro určité domény směřována na podvržené poštovní servery. Je tedy vhodné povolit zasílání odpovědí z DNS pouze z portu, kde je připojen skutečný DNS server.

KONTROLNÍ OTÁZKY • Definujte pojmy utajení, autentizace a integrita. • Čím se liší symetrický a asymetrický kryptografický systém ? Jaké jsou jejich

výhody a nevýhody ? • K čemu lze použít soukromá a veřejný klíč ? • Jak lze realizovat autentizaci v symetrickém a asymetrickém systému ? • K čemu slouží certifikační autorita ? • Jak lze ověřit integritu zprávy ? • Vysvětlete, v čem spočívá filtrace provozu na základě bezestavové inspekce

paketů. Proč se nazývá bezestavová a v čem jsou její omezení oproti plnohodnotnému stavovému firewallu ? V čem je výhodnější ?

• Vysvětlete pojem virtuální privátní sítě a tunelu. • K čemu slouží mechanismus IPSec ? • Co jsou DoS a DDoS útoky ? Uveďte konkrétní příklad. • Co jsou IDS systémy ? • Uveďte některá bezpečnostní rizika související se současnými technologiemi sítí

LAN a WAN a naznačte způsoby, jak je lze omezit


Seznam použité literatury: [1] GRYGÁREK, Petr. Virtuální lokální sítě v prostředí Linuxu. In Ostravský linuxový

seminář (OLS). Ostrava, říjen 2005. Dostupný z WWW: <http://ols.vsb.cz/2005-11-10>.

[2] SATRAPA, Pavel. IPv6. Praha: Neocortex, 2002. ISBN 80-86330-10-9.

[3] DOSTÁLEK, Libor, KABELOVÁ, Alena. Velký průvodce protokoly TCP/IP a systémem DNS. Praha: Computer Press, 2000. ISBN 80-7226-323-4.

[4] PUŽMANOVÁ, Rita. TCP/IP v kostce. České Budějovice: Kopp, 2004. ISBN 80-7232-236-2.

[5] VESEGNA, Srinivas. IP Quality of Service. Indianopolis (USA) : Cisco Press, 2001. ISBN 1-57870-116-3.

[6] GRYGÁREK, Petr. Příklad konfigurace ACL [online]. Dostupný z WWW: <http://www.cs.vsb.cz/grygarek/PS/projekt0304/acl_priklad.pdf>.

[7] KRSIČKA, Daniel. Technologie SSL VPN a jejich řešení firmou Cisco Systems : Semestrální projekt předmětu Technologie počítačových sítí [online]. Ostrava : FEI, VŠB-TU Ostrava. Dostupný z WWW: <http://www.cs.vsb.cz/grygarek/TPS/Projekty0506Z.html>.


Seznam použitých zkratek: ABR Area Border Router Hraniční směrovač oblasti ACL Access Control List Přístupový seznam AES Advanced Encryption Standard Pokročilý algoritmus pro šifrování dat AH Authentication Leader Autentizační hlavička ARP Address Resolution Protocol Protokol pro vyhledávání adres AS Autonomous System Autonomní systém ASBR Autonomous System Border Router Hraniční směrovač autonomního systému ATM Asynchronous Transfer Mode Síť ATM s přepínáním buněk BGP Border Gateway Protocol Směrovací protokol BGP BPDU Bridge Protocol Data Unit Protokolová datová jednotka mostů CIDR Classless Interdomain Routing Beztřídní směrování CoA Care-of Address Zástupná adresa CoS Class of Service Třída služby CQ Custom Queueing Uživatelsky definovaný režim obsluhy

front DDoS Distributed Denial of Service Odepření služby způsobené

distribuovaným útokem DES Data Encryption Standard Standardní algoritmus pro šifrování dat DHCP Dynamic Host Configuration Protokol pro dynamickou konfiguraci

Protocol stanic DNS Domain Name System Systém doménových jmen DoS Denial of Service Odepření služby DSCP Differentiated Service Code Point Kódová značka pro rozlišované služby EGP Exterior Gateway Protocol Vnější směrovací protokol EIGRP Enhanced Internet Gateway Vylepšený protokol IGRP

Routing Protocol ESP Encapsulating Security Payload Bezpečnostní enkapsulační hlavička FTP File Transfer Protocol Protokol pro přenos souborů GARP Generic Attribute Registration Generický protokol pro registraci atributů

Protocol GVRP GARP VLAN Registration Protocol Protokol pro registraci VLAN pomocí

GARP HA Home Agent Domácí agent HTTP Hypertext Transport Protocol Protokol pro přenos hypertextu HTTPS Hypertext Transport Protocol Zabezpečený protokol pro přenos

Secure hypertextu IANA Internet Assigned Number Autorita pro přidělování čísel v Internetu Authority ICMP Internet Control Message Protocol Protokol řídících zpráv Internetu IDS Intrusion Detection Systems Systém pro detekci průniku IEEE Institute of Electrical Profesní organizace elektrotechniků a

and Electronics Engineers elektroniků IETF Internet Engineering Task Force Organizace pro architekturu Internetu IGMP Internet Group Membership Protokol obsluhující členství ve skupinách Protocol IGP Interior Gateway Protocol Vnitřní směrovací protokol IKE Internet Key Exchange Protokol pro výměnu klíčů přes Internet IP Internet Protocol Protokol IP IPv4 Internet Protocol version 4 Protokol IP verze 4


IPv6 Internet Protocol version 6 Protokol IP verze 6 IPS Intrusion Prevention System Systém pro prevenci průniků ISAKMP Internet Security Association Protokol pro správu bezpečnostních

and Key Management Protocol asociací a klíčů přes Internet ISP Internet Service Provider Poskytovatel Internetu IT Information Technology Informační technologie LAN Local Area Network Lokální síť LFI Link Fragmentation & Interleaving Fragmentace a prokládání na spoji LLQ Low-Latency Queuing Režim obsluhy front s nízkým zpožděním LSA Link State Advertisement Informace o stavu linky LSB Least Significant Bit Bit s nejnižší vahou MAC Media Access Control Řízení přístupu k médiu MIME Multipurpose Internet Mail Rozšíření elektronické pošty pro přenos

Extension multimédií MLS Multilayer Switching Přepínání na více vrstvách MLSP Multilayer Switching Protocol Protokol pro přepínání na více vrstvách MTU Maximum Transfer Unit Maximální délka protokolové datové jednotky NAS Network Access Server Přístupový server NAT Network Address Translator Překlad síťových adres NSSA Not-So-Stubby Area Neúplně koncová oblast NTP Network Time Protocol Protokol pro synchronizaci času v síti OSPF Open Shortest Path First Směrovací protokol OSPF OSI RM Open System Interconnection Referenční model pro propojování

Reference Model otevřených systémů PHB Per-Hop Behaviour Chování na jednotlivých přeskocích PIM Protocol Independent Multicast Protokol pro směrování multicastů

nezávislý na unicastovém směrovacím protokolů

PIM-DM Protocol Independent Protokol PIM v hustém režimu Multicast-Dense Mode

PIM-SM Protocol Independent Protokol PIM v řídkém režimu Multicast-Dense Mode

PQ Priority Queueing Prioritní režim obsluhy front QoS Quality of Service Kvalita služby RADIUS Remote Access Dial-In User Server Server pro autentizaci vzdálených uživatelů RAM Random Access Memory Paměť s náhodným přístupem RED Random Early Discard Náhodné předčasné zahazování paketů RFC Request For Comment Standardy organizace IETF protokolů

Internetu RIP Routing Information Protocol Směrovací protokol RIP RIPNG Routing Information Protocol Next Protokol RIPNG

Generation RP Rendezvous Point Kořen sdíleného stromu RPF Reverse Path Forwarding Směrování podle zpětné cesty RSVP Resource Reservation Protocol Protokol pro rezervaci zdrojů SA Security Association Bezpečnostní asociace SNMP Simple Network Management Protokol pro management sítě


Protocol SPF Shortest Path First Algoritmus výpočtu nejkratších cest SSH Secure Shell Bezpečná vzdálená emulace terminálu SSL Secure Sockets Layer Vrstva zabezpečených soketů TCP Transmission Control Protocol Protokol TCP ToS Type of Service Typ služby TTL Time to Live Doba životnosti UDP User Datagram Protocol Protokol UDP URL Uniform Resource Locator Unifikovaný identifikátor umístění zdroje VLAN Virtual Local Area Network Virtuální lokální síť VLSM Variable-length Subnet Mask Maska podsítě proměnné délky VMPS VLAN Membership Server Server řídící členství ve VLAN VPN Virtual Private Network Virtuální privátní síť VQP VLAN Query Protocol Protokol pro dotazování na členství

ve VLAN WAN Wide Area Network Rozlehlá síť WFQ Weighted Fair Queuing Váhovaný rovnoměrný režim obsluhy

front WRED Weighted Random Early Discard Váhované náhodné předčasné zahazování paketů WWW World-Wide Web Systém WWW

IT - Modul 1izm.euweb.cz/informacni_technologie_pocitacove_site.pdf · 2010. 11. 14. · 4 Modul 1:...

Documents

Transcript of IT - Modul 1izm.euweb.cz/informacni_technologie_pocitacove_site.pdf · 2010. 11. 14. · 4 Modul 1:...