Technické řešení univerzální služby připojení k Internetu

MASARYKOVA UNIVERZITA V BRNĚ FAKULTA INFORMATIKY

Technické řešení univerzální služby připojení k Internetu DIPLOMOVÁ PRÁCE

David Kutálek

Brno,2006

Prohlášení Prohlašuji, že tato diplomová práce je mým původním autorským dílem, které jsem vypra­ coval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování použí­ val nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.

Vedoucí práce: Mgr. Karel Taft 11

Shrnutí Komunikační infrastruktura je jednou z osmi prioritních oblastí Státní informační politiky ČR, neboť jde o podstatný předpoklad rozvoje informační společnosti. Dynamický rozvoj komunikačních sítí a služeb byl u nás odstartován liberalizací telekomunikací v roce 2001. Zvláště ve venkovských a odlehlých oblastech však není rozvoj dostatečný a hrozí riziko rozdělení společnosti (digital divide). Jedním z možných řešení problému je koncepce tzv. univerzální služby připojení k In­ ternetu, která staví přístup k Internetu na úroveň hlasových služeb. U hlasových služeb je již univerzální služba zavedena a určuje právo občana na univerzální službu dané kvality za danou maximální cenu. Na univerzální službu připojení k Internetu se dá nahlížet jako na zobecnění stávající univerzální služby, neboť díky technologiím VoIP zahrnuje i služby hlasové. Moderní univerzální služba musí mít vzhledem k finanční podpoře z veřejných zdrojů vhodný poměr mezi užitnou hodnotou a cenou. Přesnou specifikaci univerzální služby lze potom považovat za etalon, určující doporučené parametry minimálního internetového při­ pojení pro domácnosti. V úvodu tato práce uvádí a obhajuje jednu z možných definic, obsa­ hující mimo jiné požadavek na podporu multimediálních konferencí, garantovanou kvalitu služeb a bezpečnost. K vlastnostem univerzální služby by měla patřit i nezávislost na konkrétní technologii a následná realizovatelnost širším spektrem alternativních telekomunikačních operátorů. Na základě daných požadavků tedy práce sumarizuje a porovnává stávající technologie. Diskutovány jsou varianty založené na pevných metalických a optických linkách, mobilních bezdrátových technologiích a pevných bezdrátových sítích. V dalším výkladu se již práce zabývá detailním návrhem pevné bezdrátové přístupové a páteřní sítě technologiemi WiFi a WiMAX. Návrh obsahuje podporu kvality služeb a silné bezpečnosti. Řešení je dále doplněno nástroji pro správu a dohled sítě, účtování uživatelů, dokumentaci sítě a zmiňuje i základní pracovní postupy. V práci je kladen důraz na respek­ tování aktuálních telekomunikačních standardů a na otevřené technologie.

m

Klíčová slova internet, připojení, univerzální služba, venkov, přístupové sítě, páteřní sítě, bezdrátové sítě, technické řešení, bezpečnost, rozšiřitelnost, kvalita služeb, QoS, embedded, Linux

Obsah 1

Úvod 1.1 Rostoucí význam komunikační infrastruktury 1.1.1 Veřejné on-line služby informační společnosti 1.2 Současný stav rozvoje připojení k Internetu v CR 1.3 Státní podpora připojení k Internetu 1.3.1 Podpora regionální komunikační infrastruktury 1.3.2 Koncept univerzální služby 2 Specifikace univerzální služby 2.1 Požadavky na přenosovou rychlost 2.1.1 Aplikační data 2.1.2 Interaktivní audio a video 2.1.3 Proudované video 2.2 Požadavky na kvalitu 2.2.1 Ztrátovost paketů 2.2.2 Zpoždění 2.2.3 Jitter 2.3 Míra agregace a Fair User Policy 2.4 Bezpečnost a dostupnost 2.5 Souhrnná specifikace 3 Technologie přístupových sítí 3.1 Místní účastnické vedení - xDSL 3.2 Televizní kabelové sítě - DOCSIS 3.3 Optické pasivní sítě - PON 3.4 Obousměrné satelitní přijímače 3.5 Mobilní bezdrátové sítě 3.6 Pevné bezdrátové sítě - FWA 4 Architektura sítě 4.1 Topologie 4.2 Adresace 4.2.1 Interní IPv4 adresace 4.2.2 Umístění veřejných adres v síti 4.2.3 IPv6 adresace 4.3 Směrování 4.3.1 Statické směrování a jeho nevýhody 4.3.2 Vnitřní dynamické směrování 5 Systémová platforma směrovačů a přístupových bodů 5.1 Hardwarové vybavení 5.2 Operační systém a programové vybavení 5.2.1 Použití souborového systému JFFS2 na kartách CF 5.2.2 Instalace základů systému Debian GNU/Linux na CF kartu

1 1 2 2 4 4 5

8 8 8 8 8 9 9 10 10 11 12 12 13 13 14 14 15 17 17 20 21 22 24 26 27 28 30 30 31 33 34 v

5.2.3 Tvorba repositáře a vlastních balíčků 5.2.4 Kompilace vlastního jádra 5.2.5 Konfigurační soubory a výchozí nastavení 5.3 Bezdrátové moduly a jejich ovladače 5.4 Praktické ověření výkonnosti 6 Management sítě 6.1 Monitoring sítě a éteru 6.1.1 Monitorovací systém Nagios 6.1.2 Tvorba grafů pomocí RRDtool a odvozených nástrojů 6.1.3 Skenování éteru programem Kismet 6.2 Správa konfigurací aktivních prvků 6.2.1 Řešení pomocí systému správy verzí 6.2.2 Systém Netopeer pro pokročilou správu konfigurací 6.3 Správa a účtování uživatelů 6.3.1 Identifikace uživatele v síti a řízení přístupu 6.3.2 Paketový filtr a účtování přenesených dat 6.3.3 Nastavení uživatelských rychlostí a implementace FUP 6.4 Kvalita služeb 6.5 Bezpečnost 7 Závěr Bibliografie Rejstřík A Obsah přiloženého CD B Přehled programového vybavení systémové platformy C Přehled důležitých konfiguračních souborů C.l Základní konfigurace systému C.2 Nastavení sítě C.3 Konzole přes sériový port C.4 Nastavení rozšiřujících balíčků D Konfigurace linuxového jádra E Základní datový model pro management sítě

35 36 37 38 38 41 42 43 44 45 46 46 48 48 49 49 51 52 54 58 59 60 61 62 63 63 64 64 64 65 71

VI

Kapitola 1

Úvod Koncem devadesátých let dvacátého století začalo být jisté, že následující třetí tisíciletí bude érou informační společnosti. Informační technologie lidstvu přinesly rapidní zrychlení ko­ munikace jak v osobním životě, tak v pracovním procesu. Společnost se tak mění dříve ne­ vídaným tempem směrem k ekonomice orientované na znalosti, založené na zacházení s in­ formacemi a jejich dynamickém zpracovávání. Tento živelný proces samozřejmě nemohl uniknout pozornosti státníků, na jejichž bedrech spočívá zodpovědnost za průběh probíha­ jícího přechodu na informační společnost. Komunikační infrastruktura se tak stala jednou z osmi prioritních oblastí Státní informační politiky ČR: „Cílem je vybudování komunikační infrastruktury jako podstatného předpokladu rozvoje informační společnosti." [19].

1.1

Rostoucí význam komunikační infrastruktury

Bez telefonu, elektronické pošty, webových a dalších online služeb by již dnešní globalizovaný svět nemohl fungovat. Elektronická komunikace je na vzestupu a její role ve společ­ nosti je zcela klíčová. Historie sítě Internet je obecně známá, zde stojí za zmínku alespoň vývoj jeho uživatelské základny, který dobře ilustruje postupné pronikání Internetu do ži­ vota každého z nás. Původně armádní počítačovou síť Arpanet, budovanou od roku 1969 americkým mi­ nisterstvem obrany pro čistě armádní účely, začala postupně využívat i akademická obec. V devadesátých letech se Internetu chopil komerční sektor a začal vznikat první obsah za­ měřený na širší veřejnost. Díky tomu bylo začátkem 21. století připojení k Internetu běžným vybavením firem a domácností. Tento posun pak zpětně stimuluje rozvoj dalších internetových služeb. Některé z nich jsou jen další formou zábavního průmyslu, jiné ale mohou přinést státu i jeho občanům nový prostor pro růst vzdělanosti a ekonomiky. Například elektronické obchodování je velmi pří­ nosné pro firmy i konečné spotřebitele, neboť jim umožňuje snadnější a rychlejší přístup na globalizovaný trh. Tzv eBusiness a snadná dostupnost telekomunikačních služeb zmír­ ňuje překážku vzdáleností a zavádí práci z domu, čímž zvyšuje flexibilitu firem a snižuje náklady na zaměstnance a jejich dopravu. Pokud by se práce z domu uplatnila v širším měřítku, může to mít i pozitivní ekologický dopad. 1

1.2. SOUČASNÝ STAV ROZVOJE PŘIPOJENÍ K INTERNETU V ČR 1.1.1 Veřejné on-line služby informační společnosti Je dobré si uvědomit, že v konečném důsledku dokonce i čistě zábavní služby mohou mít pro stát svůj význam. Pokud se díky zájmu občanů o zábavní služby rozšíří a zaplatí vyso­ korychlostní Internet do domácností, rozšíří se zároveň i potřebné veřejné služby informační společnosti. Které to jsou? Evropský akční plán eEurope 2005 1 uvádí následující oblasti ve­ řejných on-line služeb: •

eLearning Pro nastávající globalizovanou a na znalostech založenou ekonomiku je kvalitní a systematické vzdělávání nezbytným předpokladem. Studenti musí být neje­ nom vzdělaní ve svém oboru, ale i tzv. digitálně gramotní, čehož může eLearning ja­ kožto účelné spojení ICT a vzdělávacího systému dosáhnout. Navíc eLearning díky podpoře distančního vzdělávání usnadňuje přístup ke vzdělanosti i v odlehlých ob­ lastech a rozvíjí princip celoživotního vzdělávání. Moderní systém elektronického vzdělávání zahrnuje multimediální knihovny studijních materiálů a videokonferenční prostředky pro spolupráci s ostatními studenty a školiteli.

•

eGovernment Vzdálený přístup k veřejné správě pomocí Internetu dvacet čtyři hodin denně slibuje efektivnější a personalizované veřejné služby. Při dobře promyšlené reorganizaci a nasazení ICT tak může veřejná správa fungovat levněji, průhledněji a s větším důrazem na občana, jeho práva a svobody. Díky elektronickému podpisu umožňuje eGovernment provádět jednotlivé operace ekvivalentně u přepážky i na dálku.

•

eHealth Oblast zdravotní péče se dotýká každého z nás. Cílem eHealth je vyhovět po­ mocí ICT potřebám občanů, pacientů, zdravotního personálu i státu, který je tvůrcem politiky ve zdravotnictví. Občan tak může na eHealth nahlížet jako na zefektivnění správy svého zdraví. Konkrétním příkladem může být elektronická zdravotní karta s rychlým vzdáleným přístupem k informacím o svém zdravotním stavu. Vzhledem k citlivé povaze lékařských záznamů je u aplikací eHealth kladen důraz především na bezpečnost.

1.2

Současný stav rozvoje připojení k Internetu v ČR

S rostoucím významem internetového připojení se rapidně zvyšuje i celkový počet zákaz­ níků jednotlivých poskytovatelů připojení. Během dynamického rozvoje služby jsou sebe­ lepší statistiky počtu přípojek záhy neaktuální, přesto však mohou jasně ukazovat dlouho­ dobější trendy v zavádění vysokorychlostního připojení do domácností. Poptávka po in­ formacích o penetraci Internetu do domácností i firemního sektoru je velká, proto můžeme čerpat hned z několika nezávislých zdrojů a průzkumů. 1. eEurope 2005 Action Plan < h t t p : / / e u r o p a . e u . i n t / i n f o r m a t i o n _ s o c i e t y / e e u r o p e / 2 00 5 / a l l about/action_plan/index_en.htm> 2

1.2. SOUČASNÝ STAV ROZVOJE PŘIPOJENÍ K INTERNETU V ČR Průzkumy se liší jak šíří svého záběru, tak pochopitelně metodikou. Relevantními sle­ dovanými ukazateli jsou procentuální množství domácností vybavených počítačem, resp. připojením k Internetu a vysokorychlostním připojením. Některé průzkumy, založené na dotazování náhodných respondentů, však uvádí procenta obyvatel s domácím přístupem k Internetu. Jednotliví členové domácnosti ovšem často sdílí společné připojení, proto nelze hodnoty těchto průzkumů přímo srovnávat. Celkové údaje o stavu telekomunikací v EU 15 na počátku roku 2004 uvádí studie vypra­ covaná pro Evropskou komisi společností IPSOS-INRA [20]. Studie uvádí 39 % domácností s přístupem k Internetu a vzestup vysokorychlostního přístupu k Internetu z 5% v roce 2003 na 12% v roce 2004. Z domácích zdrojů zaujme především výzkum Českého statistic­ kého úřadu [ ], který je založen na modelovém šetření Eurostatu a proto je metodologicky i obsahově kompatibilní. Vyplývá z něj bohužel značné zaostávání České republiky oproti průměru EU. Dánsko

|

64%

Spojené království N ěm ecko Finsko Lucem bursko EU R akousko Irsko Itálie Španělsko P ortugalsko Řecko ČR (4.Čtvrtletí 2003) \

|15%

podíl na celkovém počtu domácnosti dané země

Obrázek 1.1: Přístup domácností k Internetu v ČR a zemích EU (Zdroj: ČSÚ) Technologie xDSL a kabelového připojení, ale stále více i technologie bezdrátové celosvě­ tově vytlačují klasické vytáčené připojení. V České republice tento trend nastoupil výrazněji až v roce 2004, kdy došlo k masovějšímu nasazení již dříve zkoušeného ADSL, ke zpro­ voznění nové vysokorychlostní mobilní sítě CDMA a značný rozmach zažilo též připojení bezdrátovou technologií WiFi. Situaci u nás na přelomu let 2004/2005 z hlediska hlavních vysokorychlostních technologií upřesňuje následující přehled: •

ADSL Dle údajů Českého telecomu bylo do konce roku 2004 zavedeno celkem 100 tis. přípojek ADSL, včetně přípojek provozovaných alternativními operátory. Vět3

1.3. STÁTNÍ PODPORA PŘIPOJENÍ K INTERNETU šina z nich ovšem připadá na nejlevnější variantu, která reálně nedosahuje minimální rychlosti označované jako broadband, tj. 256 Kb/s. ADSL přípojky byly na přelomu roku k dispozici na 88 % pevných telefonních linek. •

CDMA Služba byla spuštěna společností Eurotel v srpnu 2004. Během prvních pěti měsíců provozu bylo podle údajů Eurotelu pokryto cca. 80 % populace a zřízeno 30 tis. přípojek.

•

WiFi Celkový počet těchto pevných bezdrátových přípojek lze vzhledem k velkému množství operátorů odhadovat jen zhruba. Podle sdružení Internet pro všechny mohlo být v České republice ke konci roku 2004 až na 80 tis. přípojek.

1.3

Státní podpora připojení k Internetu

Oblast telekomunikací byla tradičně kompletně v rukou státu, státní monopol však fun­ guje neefektivně a brzdí rozvoj. Za nejvýznamnější krok státu ke zlepšení služeb lze proto považovat vytvoření zdravého konkurenčního prostředí. Poskytování veřejných datových služeb bylo v ČR oficiálně liberalizováno již v roce 1995, kdy Eurotel přišel o svou exklu­ zivní licenci. Následně začalo rychle vznikat mnoho komerčních poskytovatelů připojení k Internetu. Podrobnější informace o historii liberalizace telekomunikací lze najít v [6]. Představitelé ČR však velmi dlouho rostoucí význam Internetu přehlíželi a pozornost soustředili spíše na dokončení liberalizace hlasových služeb. Přitom fakt, že v roce 2004 stále neexistovalo paušální vytáčené připojení k Internetu, lze považovat za jednoznačné selhání státu a nezávislého regulátora, Českého telekomunikačního úřadu. Státní podpora připojení k Internetu tak ještě v roce 2003 prakticky neexistovala. Až v roce 2004 nastalo mírné zlepšení situace. Po vstupu ČR do EU začala podpora bu­ dování komunikační infrastruktury ze Strukturálních fondů. V souvislosti s úpravou daňo­ vého systému se objevila snaha o daňové zvýhodnění internetového připojení, která však zatím nemohla být realizována. V rámci implementace nového regulačního rámce EU se zároveň rozvinula diskuze o rozšíření univerzální služby z hlasových služeb i na službu připojení k Internetu. 1.3.1 Podpora regionální komunikační infrastruktury V dnešní době je možno poměrně snadno budovat vlastní bezdrátovou telekomunikační in­ frastrukturu, značně nezávislou na zavedených telekomunikačních operátorech. Jde přede­ vším o přístupové sítě, jejichž nedostatek v některých lokalitách je příčinou nedostupnosti vysokorychlostního přístupu k Internetu. Nejedno město či obec vzala zodpovědnost do svých rukou a zřídila pro své občany připojení vlastními prostředky. Mnoho z nich najdeme například v přehledu bezdrátových sítí v České republice [1]. Právě tímto směrem jsou v zemích Evropské unie již tradičně zacíleny programy Struk­ turálních fondů, které se formou dotací snaží podporovat a rozvíjet jednotlivé projekty míst4

1.3. STÁTNÍ PODPORA PŘIPOJENÍ K INTERNETU nich samospráv, nejrůznějších neziskových organizací, ale i firem a podniků. Klíčovým ry­ sem je zde předání zodpovědnosti za řešení daného dílčího, často regionálního problému ze státních rukou na jiný subjekt. Organizace, které vidí cestu k řešení problému a troufnou si zpracovat projekt, jsou tak za předem daných podmínek podpořeny z veřejných rozpočtů. V souvislosti s rozvojem komunikační infrastruktury je relevantní konkrétně Společný regionální operační program (SROP), opatření 2.2 Rozvoj informačních a komunikačních technologií v regionech. Podrobně toto opatření popisuje Programový dodatek SROP [5], odtud citujme jeho zaměření: „Opatření řeší podporu investic v oblasti informačních a ko­ munikačních technologií (IKT) pro obyvatelstvo a pro regionální a místní veřejnou správu. Jeho součástí je podpora aktivit spojených s veřejným přístupem k internetu pro občany, mimo jiné v knihovnách, komunitních centrech, ve školách, a se zajištěním IKT pro regio­ nální a místní veřejnou správu." Podpora ze SROP byla připravena jako kontinuální program na roky 2004 až 2006 v po­ době tří kol výzev k podávání projektů. V praxi se však ukazuje, že problémy a překážky spojené se složitou administrativou vyžadují dobře finančně i personálně zajištěné žadatele. Prostředky programu jsou navíc poměrně omezené, takže ačkoliv program jistě mnohde situaci zlepší, z celorepublikového hlediska jde jen o částečné řešení daného problému. I z tohoto důvodu by na podobném principu mělo fungovat také Fórum pro vysoko­ rychlostní přístup, zřízené Ministerstvem informatiky ČR. Tento poradní orgán dostal za úkol stanovit podmínky a zásady pro dotační titul na rozvoj broadbandu, který bude dispo­ novat jedním procentem z výnosu privatizace Českého telecomu. 1.3.2 Koncept univerzální služby Institut tzv. univerzální služby má v evropských zemích silnou tradici, můžeme jej ale nalézt například i v USA. Smyslem univerzální služby je zaručit dostupnost dané telekomunikační služby v potřebné kvalitě každému zájemci. Pod dostupností služby je v tomto případě zahrnut i cenový aspekt, vycházející z ekonomických reálií dané země. Univerzální služba je tedy zamýšlena jako záchranná síť pro situace, kde samotný telekomunikační trh selhává při zajištění základních telekomunikačních potřeb občanů. Forma realizace uvedeného principu se v čase vyvíjí a zdokonaluje s cílem regulovat co nejšetrněji vzhledem k tržnímu prostředí sektoru. Dříve byla povinnost poskytovat univer­ zální službu přidělena striktně jen dominantnímu operátorovi, zatímco ostatní operátoři mu přispívali na provozní náklady služby, jež byla prodělečná. Nyní jde dle nového Zákona č. 127/2005 Sb. o elektronických komunikacích 2 spíše o právo provozovat univerzální službu. Regulátor na základě analýzy relevantních trhů vyzve poskytovatele k získání tohoto práva prostřednictvím veřejné soutěže. Přínosem je také členění na menší správní celky, v nichž mohou soutěž vyhrát různé subjekty. Předmětem univerzální služby jsou v Evropě tradičně hlasové služby, včetně povinnosti provozovat veřejné automaty, vést telefonní seznamy a podobně. Zatím spíše nepatrný po2. ZoEK

5

1.3. STÁTNÍ PODPORA PŘIPOJENÍ K INTERNETU sun směrem k internetovým službám lze vysledovat v evropské direktivě 2002/22/ES 3 , která u služeb připojení k PSTN vyžaduje i vytáčené připojení k Internetu. Vytáčené připojení je ovšem nyní zcela nedostačující pro valnou většinu aplikací infor­ mační společnosti. V budoucnu by tedy univerzální služba měla být rozšířena o vysoko­ rychlostní variantu připojení. Legislativně by zřejmě nemělo jít o výraznější přepracování stávajících norem, nýbrž jen o dodatek v podobě specifikace další služby. A právě specifi­ kací a následným ukázkovým technickým řešením univerzální služby se dále zabývá tato práce.

3. Direktiva 2002/22/ES

6

Kapitola 2

Specifikace univerzální služby Aby mohla být univerzální služba připojení k Internetu řádně a bezproblémově implemen­ tována, je nutno ji správně technicky specifikovat. V případě nekompletnosti, nejasnosti či nepřesnosti přijaté specifikace hrozí riziko nejednoznačného výkladu jednotlivých operá­ torů, regulátora i státu. Naopak příliš podrobná, omezující či těsná specifikace může ohrozit technologickou nezávislost univerzální služby a tím podkopat její smysluplnost a oprávně­ nost. Vyvážená specifikace univerzální služby může zároveň sloužit jako etalon domácího internetového připojení. Zde uvedená specifikace univerzální služby je založena především na požadavcích uve­ dených veřejných služeb, jež jsou pro úspěšný rozvoj informační společnosti nezbytné. Zá­ roveň poskytuje prostor pro multimediální služby zábavního průmyslu a tím rozšiřuje port­ folio svých potenciálních uživatelů. 2.1

Požadavky na přenosovou rychlost

Internetová přípojka univerzální služby musí být schopna zajistit v dostatečné kvalitě tzv. „tripple play", neboli přenos běžných aplikačních dat, interaktivních audio a video přenosů a proudování multimediálního obsahu. Hlavním parametrem určujícím, zda je připojení schopno tyto aplikace poskytovat, je samozřejmě maximální přenosová rychlost.

Voice over IP

:

Videotelefon

D Kb/s TV over IP

Aplikační data 0

500

1 000

1 500

2 000

2 500

Obrázek 2.1: Požadavky aplikací na přenosovou rychlost

7

2.2. POŽADAVKY NA KVALITU 2.1.1 Aplikační data Národní politika pro vysokorychlostní přístup 1 považuje za minimální hranici vysokorych­ lostního přístupu k Internetu nominální rychlost 256 Kb/s. Důraz musí být kladen přede­ vším na dokonalou interaktivitu služeb. S narůstající velikostí běžně používaných typů do­ kumentů a s rostoucí složitostí interaktivních služeb dochází ale při této minimální rychlosti často ke zdržením, která vyrušují v práci. Proto je výhodnější mít k dispozici rychlejší pří­ pojku, i za cenu vyšší agregace či omezeného množství přenesených dat. Rychlost připojení 2 M b / s s agregací 1:4 by měla být dostatečná. Rychlost směrem od uživatele (upload) může být i nižší, minimálně však 512 Kb/s. 2.1.2 Interaktivní audio a video Ačkoliv přímé osobní setkání je v některých ohledech nenahraditelné, mnohdy je časově i finančně výhodnější komunikovat vzdáleně. S nárůstem kapacity linek se prostá telefonie rozvíjí do dalších podob, obohacena o vizuální složku a možnost vytvářet konference o více účastnících. I díky pokroku v technologii kódování (např. nový standardní video kodek H.264) lze již pořádat velmi kvalitní a plnohodnotné videokonference na přípojce o garan­ tované rychlosti 512 Kb/s. 2.1.3 Proudované video Z hlediska internetového poskytovatele nabývá proudované video několika různých podob. Může to být např. forma televizního vysílání (TV over IP, TVoIP), virtuální video knihovny (Video on Demand, VoD) či osobního videorekordéru (Personal Video Recorder, PVR). Ná­ roky na přenosovou rychlost pro proudování videa jsou oproti video konferencím zpravidla vyšší. Pro video v kvalitě blízké DVD dostačuje většinou, podle typu použitého kodeku a úrovně komprese, rychlost 1,5 Mb/s. 2.2

Požadavky na kvalitu

Pro bezproblémové využívání uvedených služeb je potřebné zaručit i dostatečnou kvalitu připojení. Problémy s kvalitou se projevují zejména při interaktivních audio a video přeno­ sech skrze výpadky hovorů, zasekávání obrazu a podobně. Na kvalitu služeb jsou citlivé i některé datové aplikace, např. vzdálený přístup k systémům a online hry. Kvalitu připo­ jení určují následující parametry přístupové a páteřní sítě, vztažené na trasu od konečného uživatele do českého výměnného uzlu NIX jako celek. 2.2.1 Ztrátovost paketů Ztráty paketů v síti mohou být způsobeny mnoha faktory, např. přetížením směrovačů, chy­ bovostí spojů či kompletním výpadkem spoje s následným procesem hledání nové cesty 1.

Národní politika pro vysokorychlostní přístup < h t t p : / / w w w . m i c r . c z / f i l e s / 2 0 6 0/NBBS .pdf>

8

2.2. POŽADAVKY NA KVALITU v síti. Jaké jsou praktické důsledky ztrátovosti paketů? U aplikací založených na protokolu TCP dochází při ztrátě paketu k retransmisi, takže ztracená data do cíle vždy nakonec dorazí. Bohužel však mají retransmise negativní vliv na propustnost daného TCP spojení a mohou tak připojení značně zpomalit. Dochází tím sa­ mozřejmě i ke značnému zpoždění a znehodnocení interaktivních služeb (ssh, on-line hry). U hlasových a videokonferenčních služeb postavených na protokolu UDP a RTP je situ­ ace ještě horší. Jde o nepotvrzované protokoly, takže k retransmisím nedochází - vzhledem k povaze daných služeb by retransmise ani neměla smysl. Občasnou a ojedinělou ztrátu paketu hlasového toku umí hlasový kodek zpravidla úspěšně maskovat. Jakmile však do­ jde ke ztrátě několika paketů za sebou, je problém rozpoznatelný uživatelem. Při náhodném rozložení ztrát paketů považujeme za horní hranici použitelnosti VoIP služeb ztrátovost 1%. 2.2.2 Zpoždění Při cestě paketu sítí dochází ke zpoždění v závislosti na zatížení linek a směrovačů, na je­ jich výpočetní síle a v ne poslední řadě na fyzické rozlehlosti sítě, resp. jejich tras. Celkové zpoždění trasy je vždy dáno součtem zpoždění pasivních a aktivních prvků sítě. Některé prodlevy je možno minimalizovat - např. instalací výkonnějšího směrovače. Jiná zpoždění jsou určena fyzikálními zákony, zejména délkami tras a rychlostmi šíření signálů, a nelze je již zmírnit. Vysoké zpoždění znamená pro datové toky protokolu TCP opět určité zpomalení. V kom­ binaci se ztrátou paketů pak dochází ke zpomalení TCP spojení až do téměř nepoužitelného stavu. Dále, u hlasových služeb je pro vysokou kvalitu vyžadováno jednosměrné zpoždění od úst k uchu maximálně 150ms (ITU G.114), jako dostačující bývá udáváno zpoždění až 200ms (Cisco). Naopak pro proudovaná multimédia není vzhledem k velikosti používaných vyrovnávacích pamětí vyšší zpoždění problémem. Vzhledem ke schopnosti internetového poskytovatele garantovat pouze parametry své vlastní sítě je při stanovení maximálního zpoždění do uzlu NIX nutno vyhradit dostatečný čas na cestu mimo síť samotného poskytovatele. Maximální RTT latence do NIXu by se při prázdné lince uživatele měla vejít do 50ms a při vytížení linky nepřekročit 150ms. 2.2.3 Jitter Jelikož zpoždění paketů při cestě sítí závisí na proměnlivých faktorech, je zpoždění jednotli­ vých paketů rozdílné, čímž vzniká jitter. Díky různým cestám mohou dokonce přijít pakety v přeházeném pořadí, což je např. pro hlasové služby zásadní problém. Řešením jsou zpra­ vidla opět vyrovnávací paměti, které přetváří asynchronně přijaté pakety na synchronní tok paketů s konstantním zpožděním mezi pakety. Vyrovnávací paměti musí být dostatečně velké, aby dokázaly zahladit jitter. Bohužel je ale nelze u interaktivních služeb libovolně zvětšovat, neboť by zanesly do zpracování dat nepřijatelné zpoždění. Odtud tedy dostáváme, že i vysoký jitter může univerzální službu znehodnotit. Literatura uvádí jako horní hranici jitteru 30ms. 9

2.3. MÍRA AGREGACE A FAIR USER POLICY 2.3

Míra agregace a Fair User Policy

Přístupové sítě poskytovatelů internetových služeb obvykle bývají poddimenzované v tom smyslu, že prodaná kapacita připojení je (mnohdy výrazně) větší, než kolik činí kapacita samotné sítě. Mluvíme o míře agregace, která udává poměr přeprodeje dané kapacity. Dále pojmem Fair User Polky (FUP) bývá označován souhrn pravidel a technických opatření, jejichž cílem je zabránit uživatelům paušálních tarifů nadměrnému využívání agregovaných zdrojů na úkor ostatních uživatelů. Mezi hlavní důvody k zavádění agregace patří samozřejmě snižování nákladů na budo­ vání a provoz sítě a jejich rozložení mezi více platících uživatelů. Z obchodního hlediska jde vlastně o další nástroj pro diferenciaci služeb podle nároků klienta. Zvláště u bezdrátových a mobilních technologií jde ale také o technologické omezení dané sdílením omezeného pře­ nosového média. K zavádění FUP pak poskytovatele připojení nutí typicky jednociferné procento klientů, kteří intenzivním využíváním agregovaných služeb ohrožují použitelnost služby pro většinového uživatele. Správně implementovaný systém agregace a FUP se tedy stará o co nejspravedlivější rozložení síťových zdrojů mezi aktivní uživatele služby. Pojem spravedlivého rozložení je samozřejmě značně nejednoznačný a musí vycházet především z požadavků a způsobů vy­ užívání služby většinou jejich uživatelů. Navíc i při dobře koncipovaném systému agregace nemusí být uspokojen většinový uživatel - uvažme například masové sledování hlavní tele­ vizní zpravodajské relace přes Internet. Vzhledem k cílům univerzální služby požadujeme po systému agregace především ne­ přetržitou dostupnost vysokorychlostního připojení (tj. minimálně 256 Kb/s) a dodržení kvalitativních parametrů zajišťujících funkčnost základních interaktivních audio a video přenosů. FUP uplatňující například po přenesení nadměrného množství dat zpomalení na rychlost 64 Kb/s je nepřijatelná. 2.4

Bezpečnost a dostupnost

Přestože běžný uživatel služeb elektronických komunikací neklade na zabezpečení zvlášť vysoké nároky, je třeba určitou základní míru bezpečnosti zajistit. Jde zejména o důvěrnost a integritu přenášených dat, ale také o autentizaci a ochranu před zneužitím internetové pří­ pojky neznámým pachatelem. Univerzální služba se tak např. musí vyvarovat problémům s neoprávněným účtováním služeb, známým z mnoha případů vysokých účtů za vytáčené připojení. •

Důvěrnost a integrita přenášených dat nemůže být z principu dokonale řešena jen na straně poskytovatele připojení. Má-li uživatel potřebu dokonalého utajení svých dat, musí individuálně využít vhodných kryptografických nástrojů. Nicméně tak jako existuje u papírového dopisu předpoklad, že si jej nemůže přečíst jakýkoliv návštěv­ ník pošty, měl by existovat podobný princip i u internetového připojení. Při použití sdíleného přenosového média se všesměrovým šířením v síti provozovatele univer10

2.5. SOUHRNNÁ SPECIFIKACE zální služby proto musí být zajištěno dostatečně robustní šifrování. Podpora stan­ dardu IPsec pro šifrování dat v celé přístupové síti poskytovatele může být pouze volitelnou součástí služby. •

Autentizace a autorizace uživatelů univerzální služby je důležitá zejména tam, kde je pro přístup využito bezdrátových případně mobilních terminálů. Jednoznačně je třeba vyloučit možnost neoprávněného využití uživatelského účtu třetí osobou mi­ nimálně ze dvou důvodů. Za prvé by mohla být jménem uživatele páchána z jeho účtu nezákonná činnost. Za druhé by mohly být uživateli vyúčtovány nadstandardní služby (např. nadměrná data) bez jeho vědomí.

•

Dostupnost časová je velmi důležitým parametrem přípojky. Je dána typem, kvali­ tou, a tedy i cenou použité přenosové technologie a samozřejmě úrovní technické podpory poskytovatele. Pro univerzální službu postačuje dostupnost 99 %, tj. až při­ bližně sedm hodin výpadků za měsíc. Vyšší požadavky na dostupnost by pravděpo­ dobně vedly ke znevýhodnění některých, zejména bezdrátových technologií.

•

Dostupnost geografická musí být z definice univerzální služby na území vymezeném regulátorem stoprocentní. Prakticky musí být provozovatel schopen připojit každého zájemce v rozumném čase - maximálně do třech měsíců od žádosti o připojení.

2.5

Souhrnná specifikace

Každé technické řešení univerzální služby přístupu na Internet musí splňovat následující parametry: •

Přenosová rychlost k uživateli minimálně 2 Mb/s, od uživatele minimálně 512 Kb/s

•

Ztrátovost paketů maximálně 1 %

•

Zpoždění paketů (RTT) maximálně 150 ms

•

Jitter maximálně 30 ms

•

Agregace maximálně 1:4

•

FUP nesmí zpomalit linku více než na 256 Kb/s

•

Při použití média se všesměrovým šířením povinné silné šifrování

•

Povinná autentizace a autorizace při přístupu k síti

•

Časová dostupnost 99 %

•

Zřízení služby kdekoliv na území určeném regulátorem do 3 měsíců

11

Kapitola 3

Technologie přístupových sítí Cílem třetí kapitoly je předložit čtenáři stručný, avšak kompletní přehled dostupných tech­ nologií přístupových sítí a zhodnotit jejich použitelnost pro implementaci univerzální služby Následující výklad lze vlastně chápat i jako důkaz technologické nezávislosti univerzální služby definované v předchozí kapitole. Každé technické řešení má pochopitelně své problémy a nevýhody, které však nesmí negativně ovlivnit schopnost splnit požadavky dané univerzální službou. Naopak přednosti jednotlivých řešení mohou mít pozitivní vliv na oblíbenost služby a rozšířit okruh zájemců. U jednotlivých technologií je třeba při hodnocení jejich použitelnosti k univerzální službě vzít v potaz zejména následující aspekty: •

Soulad s požadovanými vlastnostmi univerzální služby, tj. splnění nároků na rychlost připojení, kvalitu služby, mírou agregace a zabezpečení.

•

Skálovatelnost pro masové nasazení. Kolik procent domácností může být připojeno? Čím jsou dány limity technologie? Má technologie kapacitní rezervy do budoucna?

•

Rizika spojená s praktickým nasazením technologie. Co může ohrozit chod služby? Jaké problémy lze při provozu technologie očekávat? Je technologie dostatečně spo­ lehlivá pro zajištění požadované časové dostupnosti?

•

Různá omezení určující, kdy lze a nelze technologii nasadit. Za jakých okolností a kde nelze technologii zavést? Z jakých potenciálně omezených zdrojů technologie vychází?

3.1

Místní účastnické vedení - xDSL

Celosvětově nejrozšířenějším typem vysokorychlostního připojení je připojení klasickou te­ lefonní přípojkou technologií xDSL. Za svoji oblibu vděčí především využití stávajících mě­ děných telefonních kabelů zavedených do většiny domácností. Ačkoliv jde oproti telefon­ nímu modemu o zcela jinou technologii, z hlediska laického uživatele jde vlastně jen o "vý­ měnu krabičky". Na rozdíl od telefonního modemu řeší technologie rodiny xDSL vždy jen poslední míli. Přístupová síť sestává ze speciálních mnoha portových tzv. DSLAM jednotek v místní ústředně, 12

3.2. TELEVIZNÍ KABELOVÉ SÍTĚ - DOCSIS k nimž se skrze měděné účastnické vedení připojují xDSL modemy. Napojení na páteřní in­ frastrukturu je pak zpravidla řešeno optickou technologií ATM či Ethernet. V současnosti existuje celá řada standardů typu xDSL, lišících se v symetričnosti, maximálních vzdálenos­ tech a rychlostech. Z asymetrických jmenujme nyní převažující a novější verzi ADSL2+, ze symetrických v ČR již implementované SHDSL či vysoce rychlostní VDSL. Pro univerzální službu jde o poměrně perspektivní technologii, zvláště ve své symet­ rické podobě. Linkové rychlosti jsou dostatečné, agregace se provádí až na páteřním spoji z ústředny a tudíž není technologicky nutná přísná FUP. Vzhledem k absenci sdíleného mé­ dia je kvalita služeb na slušné úrovni a podobně i bezpečnost je dostačující. Skálovatelnost, časová dostupnost i míra rizik jsou výborné, neboť jde o značně centralizované kabelové řešení. Zásadním technickým omezením xDSL přípojek tak zůstává jejich relativně malý dosah od ústředny - podle typu a rychlosti cca do 4 Km. Při řešení univerzální služby touto cestou je tedy nutné zapojit i další, nejčastěji bezdrátové technologie. 3.2

Televizní kabelové sítě - DOCSIS

Dalším velmi rozšířeným typem vysokorychlostního připojení jsou sítě kabelové televize, rozšířené o zpětný přenosový kanál. Jde většinou o logické rozšíření služeb stávajících ka­ belových sítí. Budování zcela nových sítí tohoto typu primárně pro účely šíření Internetu není vzhledem k nákladům na pokládku kabeláže i technologii samotnou typické. Převa­ žujícím standardem v těchto sítích je DOCSIS ve verzi 1.1 a nyní i v rychlejší verzi 2. Tato disponuje celkovým zpětným kanálem 30 Mb/s, podporou kvality služby se zaměřením na multimediální přenosy. Z hlediska univerzální služby je použitelnost technologie velmi podobná jako u xDSL. Jedná se o síť se sdíleným médiem s poměrně slušnou přenosovou rychlostí, podporou kvality a bezpečnosti. Její geografická dostupnost je ovšem celorepublikově jen zlomková a nelze předpokládat masivnější budování nových kabelových rozvodů v odlehlých venkov­ ských oblastech. Smysl má naopak ve městech, kde může být problém s rušením u bezdrá­ tových řešení. 3.3

Optické pasivní sítě - P O N

Nejperspektivnější jsou samozřejmě přípojky optické, které mohou dosahovat až gigabitových rychlostí. Souhrnně bývají různé druhy optických přípojek poslední míle označovány jako FTTx, konkrétně např. FTTH označuje optickou přípojku až do domu. Technologicky jde o tzv. pasivní optické sítě (PON), u nichž je možno optický kabel větvit s použitím pa­ sivních optických rozdělovačů. To přináší menší náklady na pořízení i provozní úspory, neboť pasivní komponenty jsou prakticky bezporuchové a nepotřebují žádný servis. Po­ stupně byly zaváděny standardy pro ATM verzi PON (APON) a ethernetové verze BPON, EPON a nejnověji gigabitový GEPON (IEEE802.3ah). Přestože jde o technologii nákladnou na zavedení, v některých zemích se již masově uplatnila. 13

3.4. OBOUSMĚRNÉ SATELITNÍ PŘIJÍMAČE Pro univerzální službu by sítě PON byly technologicky velmi vhodné, neboť mají do­ statek výkonu a velkou morální životnost. Jde však stále o relativně novou technologii a pokládky kabelů jsou samozřejmě také velmi nákladné. Využití se proto pravděpodobně omezí na ojedinělé lokality, kde bude možno kabel připoložit do stávajících výkopů či např. městských chrániček. Z hlediska univerzální služby nemají masivní investice do pokládky optiky do domu opodstatnění.

3.4

Obousměrné satelitní přijímače

Satelitní přijímače vybavené zpětným kanálem byly v minulosti velice zajímavou, i když přeci jen okrajovou alternativou k vytáčenému připojení. Poskytují rychlosti až několik M b / s směrem k uživateli a o řád méně směrem od uživatele. Jejich výhodou je plošné po­ krytí celého území státu, bohužel jsou pro univerzální službu zcela nevhodné pro svoji vyso­ kou latenci. Vzhledem ke vzdálenosti a rychlosti šíření signálu bývá u satelitních přijímačů přibližně jednosekundové zpoždění.

3.5

Mobilní bezdrátové sítě

Zcela z jiného soudku jsou mobilní přístupové sítě, umožňující uživateli službu využívat na různých místech a dokonce i při pohybu. Podpora mobility je u hlasových služeb velmi podstatnou vlastností a díky tomu došlo celosvětově k masovému rozšíření mobilních sítí GSM. Provozovatelé mobilních sítí následně začali poskytovat na svých licencovaných pás­ mech i služby datové. Mobilní datové služby nejsou pro většinu populace tolik zajímavé jako hlasové, přesto si své uživatele našly a stále jsou zdokonalovány. S blížící se třetí gene­ rací mobilních sítí označovaných jako 3G sítě (standard IMT-2000) jsou již k dispozici megabitové přenosové rychlosti. Mezi tyto 3G technologie patří například UMTS aneb W-CDMA či CDMA2000. Bohužel při pečlivějším pohledu je zřejmé, že ani nastupující mobilní datové technologie nejsou pro univerzální službu vhodné. Mají k dispozici pouze 5MHz široký kanál, uváděné megabitové rychlosti jsou sdílené všemi uživateli dané buňky, respektive jejího sektoru. A to je stále příliš pomalé a vzhledem k velikostem buňek nedostatečně škálovatemé. Zpoždění je navíc u většiny 3G technologií poměrně vysoké a nevyhovující. Uvedené problémy se zpožděním mohou být ale jen dočasné, první ukázky úspěšného řešení již existují (např. Flarion a jeho Flash OFDM). Kapacita bude zvyšována pokroky v modulaci, přidělováním dalších licencí (450MHz, 872MHz) a možná se objeví i mobilní sítě na volných frekvenčních pásmech (Mobile WiMAX). Oproti fixním typům připojení jsou rychlosti mobilního připojení samozřejmě vždy nižší, v budoucnu by ale mobilita mohla univerzální službě slušet jako další přidaná hodnota. 14

3.6. PEVNÉ BEZDRÁTOVÉ SÍTĚ - FWA 3.6

Pevné bezdrátové sítě - FWA

Fixní bezdrátový přístup (FWA) je zajímavým kompromisem mezi kabelovým a plně mo­ bilním řešením. Z jedné strany již dosahuje rychlosti, kvality i bezpečnosti DSL služeb. Z té druhé umožňuje rychlou a na operátorech nezávislou instalaci přípojek, bez nutnosti vy­ užívat cizí kabeláž či vyřizovat a platit pokládku vlastní. FWA může být implementován mikrovlnnými spoji a přístupovými body v licencovaném či volném frekvenčním pásmu, případně někdy i bezdrátovou optikou (FSO). V minulosti byly mikrovlnné bezdrátové systémy převážně proprietární záležitostí, dnes to však již tolik neplatí. Díky masivnímu úspěchu standardu IEEE 802.11b, označovanému též jako WiFi, převládá snaha standardizovat i další varianty FWA. Standardizace přináší operátorům a uživatelům bezdrátových sítí nezávislost na jediném výrobci, neboť lze kom­ binovat certifikovaná zařízení od různých výrobců. Zatímco rodina protokolů IEEE 802.11 řeší primárně místní bezdrátové sítě, pro rozsáhlejší metropolitní sítě vzniká nová sada stan­ dardů IEEE 802.16, označovaná jako WiMax. Pro univerzální službu může být vhodné i WiFi, ovšem nikoliv v původní variantě 802.11b, která je již nevyhovující z hlediska rychlosti. Zaměřme se proto na použitelnost varianty 802.11a, resp. evropské varianty 802.11h, která je doplněna o pokročilé mitigační techniky pro lepší sdílení volného frekvenčního pásma: •

Dostatečná rychlost a škálovatelnost. Přístupový bod (AP) disponuje linkovou rych­ lostí až 54 M b / s polovičního duplexu, reálné rychlosti dosahují ale jen cca 20 Mb/s. Podle požadavků univerzální služby je tudíž možné na jedno AP připojit až 8 kli­ entů bez agregace, s agregací 1:4 až 32 klientů. Množství AP v dané lokalitě je pak omezeno zejména počtem volných kanálů (kterých je nyní 12+6) a kapacitou jejich páteřního napojení. Další optimalizací je sektorizace s násobným využitím stejného kanálu. Např. při 16 klientech na AP a osmi dvojnásobně využitých kanálech do­ stáváme 256 přípojek na jednu buňku sítě. Do budoucna by zvýšení rychlostí mohl přinést standard 802. l l n využitím MIMO antén.

•

Zvýšená kvalita služeb a bezpečnost. Dosáhnout vynikající kvality služeb a bezpeč­ nosti v mikrovlnných sítích je poměrně náročný a komplexní úkol. Přesto díky znač­ nému zájmu o tato vylepšení vznikly doplňující standardy, jejichž implementací se dosahuje uspokojivých výsledků. Podporu komplexního silného zabezpečení defi­ nuje standard IEEE 802.11i (obchodním názvem WPA2), podrobnosti lze najít v [9]. Nové varianty MAC protokolů pro spolehlivější zajištění multimediálních služeb pak zavádí standard IEEE 802.11e (detaily např. v [8]).

•

Případná rizika vychází především z využívání volného frekvenčního pásma. S na­ růstajícím množstvím prodaných zařízení se zvyšuje pravděpodobnost rušení od ji­ ných operátorů či přímo od samostatných domácích uživatelů. V odlehlejších oblas­ tech je velmi nepravděpodobné, že by nebyl k dispozici volný kanál. V hustě obydle­ ných lokalitách bývá situace horší. K minimalizaci problémů je proto přímo v přísluš15

3.6. PEVNÉ BEZDRÁTOVÉ SÍTĚ - FWA ném veřejném oprávnění uvedena povinnost používat dynamickou volbu frekvence (DFS) a doporučeno používat regulaci vysílacího výkonu (TPC). Nastupující standard WiMax bude podle všeho splňovat požadavky operátora univer­ zální služby ještě lépe. Celkový návrh totiž na rozdíl od WiFi počítá s nasazením na roz­ sáhlejším území, čemuž je přizpůsobena především vrstva přístupu k médiu. Dále standard počítá s uplatněním na vícero různých frekvenčních pásmech, jak licencovaných, tak bezlicenčních. Vysoké přenosové rychlosti, kvalita služeb a bezpečnost je zde již samozřejmostí. Návrh technického řešení, detailně řešený v následující kapitole, přesto snad poněkud konzervativně preferuje pro přístupové body technologii WiFi, zatímco WiMax uvažuje nyní jen pro páteřní spoje. Jakmile dosáhne WiMax dostatečného rozšíření a bude časem prověřen a doladěn, nebude problém jej postupně nasadit ve velkém i na přístupové body.

16

Kapitola 4

Architektura sítě Návrh rozsáhlejší přístupové sítě, vhodně navázaný na síť páteřní, je velmi komplexní úkol. Při tvorbě návrhu je třeba mít na zřeteli především požadavky kladené na síť, neboť bez ucelené představy o způsobu využití a správy sítě riskujeme následné problémy při imple­ mentaci. Díky specifikaci univerzální služby tuto představu máme a zde uvedený návrh technického řešení ji respektuje. Množství potřebných aktivních prvků, systémů a programů, z nichž je výsledná síť se­ stavena, je rovněž značně rozsáhlý a nelze proto od mé práce očekávat hotový "instantní" produkt. Objem práce nutné k prvotnímu zbudování, nastavení a odladění sítě operátora je velký a vyžaduje zkušený tým pracovníků. Pro takový tým by měla být má práce naopak spíše jakousi cestovní mapou na cestě k zavedení kvalitní a dobře vedené sítě operátora, jenž jejím prostřednictvím univerzální službu poskytuje. Navrhnout architekturu sítě znamená integrovat několik vhodně nastavených funkčních celků do jednotné koncepce. Celý návrh je pochopitelně založen na protokolech TCP/IP, s ohledem na budoucnost v podobě IPv6. Před výstavbou každé rozsáhlejší sítě je na místě pečlivě zvážit nejen topologii sítě, její adresaci a směrování, ale také výběr technologií spojů a aktivních prvků sítě. Na bezpečnost, snadnou konfiguraci a dohled sítě je pak třeba myslet prakticky v každém kroku. 4.1

Topologie

Logická struktura páteřní a přístupové sítě může nabývat hned několika podob. Každá z nich má specifické předpoklady pro nasazení, výhody i nedostatky. Stromová topologie je velmi často používaná, zvláště u menších přístupových sítí. Ko­ řen topologického stromu tvoří brána do páteřní sítě, listy jsou koncoví klienti. Je vhodná pro bezdrátové sítě, kde možnosti vytváření okruhů jsou mnohdy omezeny viditelnostmi v členitém terénu. Nevýhodou je samozřejmě náchylnost k výpadkům větších částí sítě a nemožnost dělit špičkový datový tok do více alternativních cest. Topologie s okruhy může vzniknout i ze stromové topologie přidáním záložních spojů. Z okruhů jsou však budovány především páteřní sítě, ať už optické, bezdrátové či v různých kombinacích. Okruhy můžeme zajišťovat již na linkové vrstvě, např. technologiemi SDH, případně v levnější variantě Ethernet s nastaveným STP, který zaručí využití vždy jen jedné cesty. Pro vytvoření optimálně využitých okruhů na úrovni síťové vrstvy je nutné aplikovat vhodné dynamické směrování s podporou vyvažování datového toku. Jde v podstatě o nej17

4.1. TOPOLOGIE

4 ^.

Přístupové brány : i ;

D o h I e d

/

\

Smerovánľ a směrovací protokoly Topologie

Adresace

Směrovače

\

AAA

Dokumentace

Páteřní spoje

v Přístupové body

sítě a informační systém operátora

I ; j

Obrázek 4.1: Funkční celky při návrhu architektury sítě výkonnější a nejstabilnější řešení, na úkor větší nákladnosti a složitosti. U bezdrátových sítí navíc hraje roli i dostupná šířka pásma, která je omezená a její využití pro záložní linky se může jevit jako plýtvání. Topologie typu mesh. V mesh síti jsou uzly propojeny s větším množstvím okolních uzlů, čímž vzniká velmi hustá pavučina cest. Jde o variantu, která v přístupových sítích za­ tím není příliš běžná. Zvláště u bezdrátových sítí se však prosazuje v situacích, kdy je třeba rychle pokrýt větší územní celek, např. město. Jsou k tomu využívány všesměrové ad-hoc jednotky a speciální sady protokolů k vyhledávání nových linek a směrování 1 . Výhodou je především vysoká dynamika sítě a poměrně snadná konfigurace, díky níž mohou jednotlivé prvky sítě být i mobilní. Jde ovšem o méně výkonné řešení, náchylné vzhledem k využití všesměrových spojů k rádiovému rušení. Pro síť univerzální služby jsem zvolil topologii klasického stromu pro přístupovou síť a plně kruhovou topologii pro navazující síť páteřní. Při mé volbě topologie sítě jsem vzal v potaz zejména: •

pravděpodobné fyzické rozmístění spojů a aktivních prvků sítě

•

použité přenosové technologie

•

požadavky na výkon a dostupnost sítě

•

vlastní praktické zkušenosti

Páteřní síť univerzální služby tedy sestává ze spojů bod-bod založených na technologii Ethernet (IEEE 802.3). Předpokládám primární využití optických vláken, jsou-li k dispozici, 1. Např. OLSR (RFC3626), AODV (RFC3561) nebo TBRPF (RFC3684).

18

4.1. TOPOLOGIE

Páteřní okruh Přístupová síť

Obrázek 4.2: Příklad přístupové sítě podoby stromu

jinak je třeba nasadit kvalitní rádiové spoje v licenčních pásmech 2 . Každý spoj je ukončen ve směrovací vlastním rozhraním a spoje dohromady tvoří jeden či více okruhů. Do okruhů pak vede minimálně jeden, lépe však více spojů do Internetu (tj. typicky do propojovacího centra NIX a do zahraničních sítí). Přístupová síť univerzální služby sestává z distribučních spojů, směrovačů a konco­ vých přístupových bodů. Zálohovat připojení až k uživateli by znamenalo redundanci obou součástí a v konečném důsledku by službu zbytečně prodražilo. Proto je možné záložní linky implicitně vynechat a budovat je až v případě reálné potřeby. Ta v praxi nastat může, s čímž je počítáno při výběru směrovacího protokolu.

2. Licencovaná frekvenční pásma jsou u nás zpoplatněna podle směrovosti, výkonu, šířky pásma, typu frek­ vence a použitého zařízení. Při podpoře univerzální služby bych proto doporučil službu přednostně dotovat formou slevy na těchto poplatcích.

19

4.2. ADRESACE 4.2

Adresace

Z hlediska protokolu IP se síť univerzální služby skládá z mnoha podsítí, určených svou adresou a maskou. Každé koncové zařízení připojené do sítě disponuje adresou z rozsahu některé z těchto podsítí. Směrovač je ze své podstaty vždy součástí hned několika podsítí, mezi kterými směruje provoz. Po volbě topologie bylo nutno připravit vhodné adresní schéma, určující pravidla tvorby adres podsítí a přidělování jednotlivých adres strojům v síti. Od přidělených adres se ná­ sledně odvíjí nejen samotné směrování, ale i nastavení celé řady dalších subsystémů, např. paketových filtrů, dohledových a účetních nástrojů a podobně. Pravidla by proto měla být jednoduchá a dostatečně intuitivní. V současnosti je většina Internetu adresována protokolem IPv4, zatímco prosazení nové verze IPv6 zatím nenabralo dostatečnou dynamiku. Znamená to, že z hlediska koncového uživatele je většina internetových zdrojů dostupná na původních 32-bitových adresách. Těchto adres je s růstem Internetu k dispozici čím dál méně a internetoví operátoři proto pro připojení koncových uživatelů používají překlad síťových adres (NAT). Mechanismus překladu adres využívá tzv. lokálních adres, které jsou protokolem IPv4 určeny pro neveřejné použití. Síť je adresována v neveřejném adresním rozsahu a až na bráně do veřejného Internetu jsou lokální adresy překládány na jednu či více adres veřej­ ných. Jaké jsou tedy možnosti pro adresaci sítě univerzální služby? Adresace veřejnými adresami by byla technicky vzato optimálním řešením, neboť ne­ zavádí žádný potenciálně problémový překlad adres. Stroje s veřejnými adresami jsou pl­ nohodnotně přístupné jak ze sítě operátora, tak z celého Internetu. Na druhou stranu však vznikají následující problémy: •

Nedostatek veřejných adres pro vlastní síť vede k úsporným, avšak méně čitelným adresním schématům. Nutí administrátora používat mnoho malých nespojitých pod­ sítí. Konečný uživatel může také chtít více adres. Přitom operátor jich tolik vůbec nemusí mít k dispozici a uživatel je nucený použít NAT

•

Pokud jde o menšího operátora, jenž má veřejné adresy jen zapůjčené od dodavatele internetové konektivity, vzniká tím pro něj přímá závislost na dodavateli. Přechod jinam pak znamená organizačně komplikované a pracné přeadresování, během něhož je nutné odebírat dvojí konektivitu.

Adresace lokálními adresami sestává z použití dostatečně velkého lokálního adresního prostoru a omezeného množství adres veřejných. Na hranici sítě je aplikován NAT, který může překládat lokální adresy podle různých kritérií na jednu či více adres veřejných. V IPv4 je k dispozici několik lokálních adresních prefixů, včetně velikostí zcela dostačujícího prefixu 10.0.0.0/8. Adresní schéma tak může být volnější a klienti mají k dispozici dostatek adres. Z nedostatků pak můžeme zmínit např. nekompatibilitu NAT s některými protokoly, např. IPSec. Pro shora uvedenou topologii jsem zvolil veřejnou adresaci pro páteřní síť a lokální ad­ resaci pro síť přístupovou. Vhodné je doplnění o paralelní adresaci veřejnými IPv6 adresami 20

4.2. ADRESACE v síti jako celku. S postupným přechodem na novou verzi protokolu pak bude možno starší variantu pozvolna opouštět. Zda a jak se prosadí NAT ve světě IPv6 je zatím otázkou, teprve v roce 2005 proběhlo schválení lokálních adres i pro IPv6. Nyní si popíšeme adresní schéma univerzální služby. 4.2.1 Interní IPv4 adresace V uvedeném rozsahu 10.0.0.0/8 máme k dispozici přes 16 milionů adres, nebo také přes 65 tisíc podsítí typu C resp. 256 podsítí typu B. Volného prostoru je dostatek a můžeme si proto dovolit strukturovat prostor do přirozené hierarchie, vycházející ze stromové topologie sítě. Adresu si rozdělíme po bitech podle přiložené tabulky. Význam jednotlivých částí adresy je poté následující:

Počet bitů adresy Teoretický počet prvků Z toho rezervováno Reálný počet prvků

Prefix '10' 8 1 1 0

Oblast 8 256 0 256

PoP 5 32 0 32

AP 3 8 1 7

Klient 5 32 1 31

Zařízení 3 8 3 5

Tabulka 4.1: Struktura lokální IPv4 adresy Prefix '10' je neměnný osmibitový prefix, určující lokální adresy. Oblast určuje větší síťový a územní celek. Podle velikosti obsluhovaného území a hustoty sítě tím může být myšlena např. vesnice, shluk vesnic či město. Při posky­ tování služby na území rozlohy kraje či větším předpokládám rozsáhlejší páteřní síť bez propojení jednotlivých přístupových sítí na úrovni vnitřních adres. PoP (Point of Presence) reprezentuje v terminologii ISP přístupové místo k síti. V na­ šem případě si číslem PoP označíme fyzickou lokalitu sítě v rámci oblasti, jenž může obsahovat i několik směrovačů a přístupových bodů. AP reprezentuje koncový přístupový bod sítě v rámci PoP z pohledu klienta. Kon­ krétní přístupový bod může mít více rozhraní a tudíž i více těmito čísly určených rozsahů. Naproti tomu klient vždy patří (v daný okamžik) jen do jednoho rozsahu. Pro adresaci rozhraní, jenž nejsou určena pro koncové klienty, si rezervujeme jednu, nejvyšší hodnotu. Klient, resp. jeho adresy jsou určeny pětibitovým číslem klienta v rámci AP. Vzhle­ dem k vysokým nárokům na rychlost a kvalitu univerzální služby více než uvádě­ ných 31 klientů na AP není možné očekávat. V případě posunu technologií k lepšímu pak lze přiřadit jednomu rozhraní více rozsahů, na úkor přehlednosti ovšem. Jedna rezervovaná hodnota, tentokrát ta první, je určena pro hlavní bránu a případné do­ datečné lokální služby či servery. 21

4.2. ADRESACE •

Zařízení u klienta může mít jednu z pěti adres, které na klienta připadají. Podle mých dosavadních zkušeností je pět adres pro běžnou domácnost dostatečné množství pro počítače i telefony. Tři rezervované adresy pak mohou sloužit jako číslo klientské podsítě, výchozí brána a adresa všesměrového vysílání. Rozdíly mezi použitím spo­ lečné podsítě pro všechny klienty na AP, versus použití jednotlivých podsítí, spočívají v možnostech vzájemné komunikace a zařazení této komunikace do front pro řízení kvality služeb.

Při implementaci uvedeného schématu pro novou síť si nejprve připravíme tabulku ob­ lastí. Při adresaci jednotlivých PoP jdeme směrem od kořene k listům, adresy pro vnitřní spoje přístupové sítě máme vyhrazeny v každém bloku PoP adres. Pro snadné rozlišení vnitřních rozsahů od rozsahů určených pro připojení klientů bereme adresy z opačné strany, tedy odshora. Vesměs jde o spoje bod-bod či segmenty s malým množstvím připojených směrovačů, proto nám při použití malých podsítí jedna podsíť typu C na spoje v rámci PoP či z PoP směrem k listům jistě postačí. 4.2.2 Umístění veřejných adres v síti Ačkoliv to u domácích uživatelů není úplně běžné, veřejné IP adresy bývají občas potřeba a síť je musí být schopna zprostředkovat. V síti s interní adresací a překladem adres na bráně je můžeme uživatelům poskytnout několika různými způsoby, jenž se svým chová­ ním mírně liší. Přitom ne všechny varianty umožňují provozovat libovolné aplikace vyža­ dující veřejnou adresu. Možná řešení jsou zakreslena na následujícím obrázku. Vnitřní adresa s NAT 1:1 na bráně. Technicky jde o kombinaci SŇAT a DNAT, která na bráně překládá jednu lokální adresu na jednu veřejnou adresu. Přesněji, SŇAT zajišťuje pře­ klad požadavků z vnitřní sítě, zatímco DNAT obslouží požadavky zvenčí. Koncové zařízení tak vlastně o veřejné adrese ani neví, z čehož mohou plynout potíže. Implementace pomocí linuxového subsystému Netfilter vypadá následovně: # přidání adresy na bránu; # to není nutné, pokud je z~vhodně směrovaného rozsahu ip address add $PUBLIC_IP/$MASK brd + dev $INET iptables -t nat -A POSTROUTING -o $INET -s $LOCAL_IP \ -j SŇAT --to-source $PUBLIC_IP iptables -t nat -A PREROUTING -i $INET -d $PUBLIC_IP \ -j DNAT --to-destination $LOCAL_IP

Na místě je upozornit na nepřístupnost takto přidělené veřejné IP adresy ze vnitřní sítě, pokud adresa na bráně nebyla zavedena. V opačném případě dokonce odpoví místo po­ žadovaného stroje brána. Určitým řešením je např. úprava vnitřního DNS serveru tak, aby záznamy odkazující na veřejné adresy uvnitř sítě odkazoval přímo na odpovídající lokální adresu. Veřejná adresa bez veřejných adres na cestě k bráně. Cílem je přinést veřejnou IP až na koncové zařízení, aniž by se musely dát veřejné adresy všem směrovačům po cestě. Jde 22

4.2. ADRESACE

Internet

Internet

Páteř Brána

Páteř

Páteř

NAT 1:1

Brána

VIP klient

Vnitřní IP adresy

VIP klient

/

Veřejné IP adresy

Obrázek 4.3: Možné implementace veřejných IPv4 adres v síti

tedy o tunelování, jenž můžeme vytvořit opět více způsoby. Můžeme zavést dvojitý NAT, jenž veřejným adresám vytvoří pomyslný adresní tunel skrze neveřejnou síť. Implementace: # Na b r á n ě ip address add $PUBLIC_IP/$MASK brd + dev $INET iptables -t nat -A POSTROUTING -o $INET -s $LOCAL_IP \ -j SŇAT --to-source $PUBLIC_IP iptables -t nat -A PREROUTING -i $INET -d $PUBLIC_IP \ -j DNAT --to-destination $LOCAL_IP # Na koncovém AP ip address add $(($PUBLIC_IP-1))/30 brd + dev $AP iptables -t nat -A POSTROUTING -O $UPLINK -s $PUBLIC_IP \ -j SŇAT --to-source $LOCAL_IP iptables -t nat -A PREROUTING -i $UPLINK -d $LOCAL_IP \ -j DNAT --to-destination $PUBLIC_IP

Pokud se chceme vyhnout zavádění NAT, můžeme veřejné adresy tunelovat. Jeden konec tunelu umístíme na vnitřní rozhraní brány, druhý na přístupový bod. Možné je též dovedení tunelu přímo na klientský počítač, pokud jej jeho operační systém podporuje. Za účelem tunelování veřejné adresy není třeba šifrování, postačí obyčejný GRE tunel dle [14]. Řešení jsem úspěšně ověřil následujícími příkazy: 23

4.2. ADRESACE # Na bráně modprobe ip_gre ip tunnel add vip mode gre remote 10.2.128.14 local 10.12.1.1 ttl 255 ip link set vip up ip address add 212.111.24.105/30 dev vip iptables -A INPUT -p gre -s 10.2.128.14 -j ACCEPT iptables -A FORWARD -o ethl -s 212.111.24.106 -j ACCEPT iptables -A FORWARD -i ethl -d 212.111.24.106 -j ACCEPT # U~klienta: modprobe ip_gre ip tunnel add vip mode gre remote 10.12.1.1 local 10.2.128.14 ttl 255 ip link set vip up ip address add 212.111.24.106/30 dev vip ip route add 10.0.0.0/8 via 10.2.128.1 ip route replace default via 212.111.24.105

Nativní veřejná adresa Nejčistší řešení, spočívající v paralelním nasazení veřejných ad­ res při adresách lokálních. Výhodou je jednoduchost a stoprocentní kompatibilita, nevýho­ dou množství vyplýtvaných veřejných adres. Pro každý spoj po cestě k uživateli veřejné adresy ve vnitřní síti jsou třeba typicky 4 veřejné adresy, což není málo. Má dosavadní zkušenost s udělením přibližně stovky veřejných adres prvním uvede­ ným způsobem je veskrze kladná. Protokolů, jenž pracují v těle paketu se svou adresou a tudíž s tímto způsobem přidělenou adresou nefungují, není mnoho. Mezi domácnostmi, na něž je univerzální služba především zacílena, nejsou navíc příliš často používány. Na druhou stranu protokoly jako IPSec jsou natolik významné, že musí být sítí podporovány. V praxi proto předpokládám hromadné nasazení jednoduchého NAT jedna ku jedné a ob­ časné využití GRE tunelů. 4.2.3 IPv6 adresace Jak již bylo řečeno, hlavním motivem pro vytvoření nové verze internetového protokolu byl malý adresní prostor. Přechod na nový protokol je složitý proces, proto byla snaha vyře­ šit problémy s místem jednou pro vždy. Návrh standardu pro adresaci v IPv6 definovaný v [13] a [18] zavádí adresy o délce 128 bitů, tedy čtyřnásobně dlouhé oproti IPv4. Podle ně­ kterých propočtů to znamená až tisíce adres na metr čtvereční pevninského povrchu Země. Minimálně pro pozemský Internet máme tedy IPv6 adres dost pro každého. Důležitým problémem je otázka přechodu na nový protokol, jenž pochopitelně nemůže být jednorázový, provedený ze dne na den. Existuje proto celá řada návrhů pro plynulý přechod z IPv4 na IPv6, jejichž cílem je vzájemná interoperabilita obou protokolů po onu přechodnou dobu. Jde o vzájemně se doplňující či stále ještě navzájem soupeřící návrhy, založené na dvojitém zásobníku, tunelech či překladačích. Pro praktické využití v síti univerzální služby doporučuji použití dvojitých zásobníků na všech směrovacích a přístupových bodech. Paralelní provoz obou protokolů pak obnáší 24

4.2. ADRESACE adresaci vnitřními adresami verze IPv4 plus adresaci veřejnými adresami IPv6, čímž kon­ cový uživatel získá možnost výběru. Další pomocné mechanismy pak mohou být řešeny jako doplňkové služby sítě. Ačkoliv s sebou nový protokol přináší celou řadu zásadních změn a novinek, základní principy adresace i nadále zůstávají. Stále je vzhledem k velikosti směrovacích tabulek nutné agregovat cesty do společných směrovacích pravidel, čehož se dosahuje využitím hierarchie adresních prefixů na úkor využitelnosti adresního prostoru. Snaha standardizovat podobu veřejné části adresní hierarchie (původní návrh viz. [12]) se však nesetkala s úspěchem. Hierarchii si proto nyní určují přímo jednotliví regionální internetoví registrátori (RIR) na základě doporučení [17]. Unicast adresa v IPv6 se skládá z globálně směrovaného prefixu, identifikace podsítě a identifikátoru rozhraní, přičemž oba identifikátory definují rozsahy pro koncové uzly. Doporučené množství adres přidělovaných koncovým uzlům odpovídá podsítím s prefixem pevné délky 48, což má mnohé v uvedeném dokumentu diskutované výhody. Umožňuje mimo jiné využít 2B adresy pro vnitřní směrování každého uživatele a 6B pro standardní adresu rozhraní. Právě z politiky přidělování adres 3 , určené pro Evropu organizací RIPE NCC, je třeba vycházet při návrhu veřejné adresace IPv6. Nových adres je sice obrovské množství, i to by ovšem neuváženým přidělováním mohlo dojít dříve, než je zamýšleno. Při každém hierar­ chickém členění adresního prostoru dochází totiž k určité neefektivitě ve využití prostoru. Na jednu stranu daná vrstva hierarchie nemůže být příliš malá, což by vedlo k nutnosti roz­ šiřovat či přeadresovávat, na straně druhé nám zůstávají nevyužité adresní oblasti. Politika regionálního internetového registrátora tak nabádá na jednu stranu k intenzivnějšímu vyu­ žívání prostoru, současně však usiluje i o účinější agregaci cest. V protikladech, mezi nimiž musí registrátor manévrovat, by se dalo pokračovat. Jak tedy adresovat? Půjde použít podobná hierarchie jako u IPv4 adres, aby byla situace v síti přehledná? Od RIPE NCC můžeme coby internetový operátor, resp. místní internetový registrátor, získat jako nejmenší podsíť prefix velikosti 32. Tím získáváme 16 bitů pro vy­ tvoření vlastní veřejné hierarchie adres. Budeme-li chtít další či větší prefix, musíme nejprve prokázat dostatečné využití stávajících prefixů či dostatek stávajících IPv4 klientů. Z těchto důvodů není vždy možné vzít strukturu našich neveřejných IPv4 adres a aplikovat ji celou do jednoho místa IPv6 adresy. Potřebné změny jsou vyobrazeny v přiloženém schématu. Poslední tři bity rozhraní v IPv6 supluje celých 80 posledních bitů adresy. Při celkové délce naší hierarchie 16 bitů nám zbývá pouhých 8 oblastí. Za dané situace můžeme např. vrstvu oblastí sloučit s vrst­ vou PoP a při nedostatku požádat o další blok IPv6 adres, případně rovnou požádat o prefix o pár bitů kratší. Zbývá si ukázat, co autority rozumí pod dostatečným využitím adresního prostoru. Po­ suzování je založeno na teorii, vycházející z pozorování adresních systémů těsně před je­ jich vynuceným prostorovým rozšířením. Jedná se o tzv. poměr H, jenž udává logaritmický 3. IPv6 Address Allocation and Assignment Policy, < h t t p : //www. r i p e . n e t / r i p e / d o c s/ipv6pol i c y . html>

25

4.3. SMĚROVÁNÍ Globálně s m ě r o v a t e Iný prefix

|

O PoP AP K R

ID oblasti ID lokality PoP ID přístupového bodu ID klienta ID dtroje

o

10

1

2

3

O

4

5

PoP

PoP

AP

ID podsítě

7

6

.

AP

ID rozhraní v u p r a v e n é m EUI-64 f o r m á t u

1 Q

K

K

10

11

12

13

14

15

16 |

IPv6 veřejné R

IPv4 lokální

Obrázek 4.4: Hierarchie IPv6 adres v porovnání s hierarchií IPv4 adres poměr mezi skutečně přidělenými adresami a celkovou velikostí přidělitelného prostoru v bitech (viz [10]): log (počet_objektů)

(l)

počet b i t ů resp. o jeho novější a čitelnější podobu HD (Host-Density): (2) log (počet_objektů) HD

log (maximální_počet_objektů)

Následující tabulka uvádí prahové počty klientů a příslušné procentuální využití adresního prostoru v mnou navržených adresních schématech při efektivitě HD=0,8. Právě tuto hod­ notu hustoty zvolilo RIPE NCC jako hranici pro přidělení dalšího adresního prostoru v IPv6.

IPv4 - 1 oblast IPv4 - 256 oblastí IPv6 - 1 oblast IPv6 - 8 oblasti IPv6 - 32 oblasti

Celkem prvků 8192 2097152 8192 65536 262144

Prvků v adresaci 6944 1777664 6944 55552 444416

Počet bitů 13 21 13 16 18

Práh 1351 114104 1351 7132 21619

Využití 16% 5% 16% 11% 8%

Tabulka 4.2: Hranice efektivního využití prostoru adresními schématy při HD=0,8

4.3

Směrování

Zajistit dostupnost IP adres v síti a směrování paketů mezi nimi je hlavní operátorovou sta­ rostí. Pro obsluhu sítě to znamená především správu směrovacích tabulek, případně kon26

4.3. SMĚROVÁNÍ figurací směrovacích démonů. Funkce směrovače je obecně známá a pěkný popis lze najít např. v [7]. Směrovače univerzální služby jsou založeny na Linuxu, jehož síťová část jádra pro naše použití plně dostačuje. Podrobnou technickou dokumentaci k linuxovému směro­ vání lze najít hojně na Internetu 4 . Podle velikosti sítě a preferencí operátora je možno směrovat b u ď staticky ručním zása­ hem do nastavení směrovače, nebo dynamicky využitím směrovacích protokolů resp. smě­ rovacích démonů. V případě použití okruhů lze zajistit velmi rychlou konvergenci sítě při výpadcích a do určité míry i vyvažování provozu agregací vícenásobných cest5. Při směrování v síti univerzální služby si vystačíme s běžným směrováním podle cílové adresy, i když ve zvláštních případech si můžeme vypomoci i složitějšími pravidly. Klíčové je využívání pravidel pro výchozí bránu, pomocí kterých vždy směrujeme všechen provoz v topologickém stromu směrem ke kořeni. Každý směrovač dále musí znát pravidla pro cesty ke všem svým následníkům, tj. směrem k listům topologického stromu.

4.3.1 Statické směrování a jeho nevýhody Statické směrování je tím nejjednodušším řešením, pokud začínáme budovat menší síť. Není třeba instalovat a konfigurovat směrovací démony, stačí napsat pár řádků směrovacích pra­ videl pro každý stroj. Mezi další výhody statického řešení patří lepší bezpečnost a úspora systémových prostředků sítě. S rostoucím množstvím směrovačů a podsítí či při větších to­ pologických změnách sítě se však správa pravidel může stát noční můrou administrátora. Máme-li síť s topologií stromu a vhodnou adresací, může být přesto statické směro­ vání stále ještě rozumně spravovatelné. Přidání nových podsítí na okraj sítě znamená ruční úpravu všech směrovačů po cestě ke kořeni sítě, aby měly opět přehled o všech svých ná­ slednících. Díky použitému adresování můžeme tento neduh zmírnit pomocí agregujících prefixů, zahrnujících celé oblasti. Agregace prefixů je mimochodem obecně používaný ná­ stroj pro šetření nároků směrovačů na systémové zdroje. Na směrovacích, jenž mají jako své následníky celé oblasti, typicky zapisujeme jen jedno směrovací pravidlo pro každou oblast. Naopak detailní struktura oblasti se promítne pouze do pravidel směrovačů v oblasti. Přidání nové podsítě do oblasti proto znamená v nejhor­ ším případě úpravu všech směrovačů v oblasti, mnohdy stačí ale upravit jediný směrovač. Přidání nové oblasti může již být pracnější. K přidání směrovacích pravidel použijeme sek­ venci příkazů ip route add $PREFIX via $GATEWAY

4. Např. Linux Advanced Routing and Traffic HOWTO, «chttp: / / l a r t c . o r g / h o w t o / > nebo Guide to IP Layer Network Administration with Linux, «chttp: / / l i n u x - i p . n e t / l i n u x - i p . p d f > 5. Směrování vícenásobnými cestami (multipath routing) je na Linuxu možné zavést i staticky. Vzhledem k po­ užití vyrovnávacích pamětí směrovače (tzv. Forwarding Information Base) je agregace účinná zejména při vět­ ším množství uživatelů sítě. Implementaci těchto optimalizací diskutují v detailech [15] a [16].

27

4.3. SMĚROVÁNÍ 4.3.2 Vnitřní dynamické směrování Pokud chceme předcházet budoucím problémům s rozšiřitelností sítě a minimalizovat ruční práci, je třeba implementovat některý ze směrovacích protokolů. Jejich úkolem je zajistit vzájemnou výměnu směrovacích pravidel mezi směrovací v síti, čehož dosahují sofistiko­ vanými algoritmy. Existují dva hlavní typy směrovacích protokolů - protokoly založené na vektoru vzdálenosti a protokoly se stavem linky. Směrování s vektorem vzdálenosti je nejjednodušší formou dynamického směrování. Směrovače předávají svým sousedům své směrovací tabulky a přeposílají tabulky přijaté od sousedů, zvětšené o své vlastní vzdálenosti. Směrování spoléhá na jedinou metriku vzdá­ lenosti, bez zohlednění dalších důležitých údajů o síti. Celý proces sestává z pravidelné aktualizace v předem zadaných intervalech, což bohužel prodlužuje dobu konvergence při změnách v síti a generuje mnohdy zbytečný provoz. Obvyklým protokolem tohoto typu je RIP, nyní ve verzi 2. Směrování se stavem linky je pokročilejší formou směrování, použitelnou i ve složitějších a rozsáhlejších sítích. Směrovače si udržují podrobnou databázi informací o směrovacích a o topologii sítě. Následná výměna informací probíhá formou oznámení o stavu linky jen při vzniku události v síti, tj. např. při výpadku linky či přidání směrovače. Konvergence tudíž probíhá mnohem rychleji, cenou je vyšší výpočetní náročnost algoritmů. Pro síť uni­ verzální služby preferuji pro svou škálovatelnost a robustnost nejoblíbenější z těchto proto­ kolů, OSPF [' ]. Z hlediska architektury sítě je pro zavedení protokolu OSPF nutné nejprve vyřešit dvě klíčové otázky: rozdělení na oblasti a definici nákladů linek. Rozdělením na OSPF oblasti získává síť na robustnosti a škálovatelnosti. Výpočet data­ báze stavu linek (LSDB) se provádí pro každou oblast zvlášť, čímž můžeme více oblastmi snížit nároky protokolu na systémové zdroje. Jedna oblast (označovaná jako 0, případně 0.0.0.0) musí být vždy páteřní a musí figurovat v každé komunikaci mezi dvěma oblastmi. Jinými slovy, všechny oblasti se připojují přímo k oblasti páteřní. Uvedené omezení nám mírně komplikuje vytvoření struktury oblastí, neboť v praxi ne­ musí být možné připojit každou lokalitu přímo do páteřní oblasti. Administrativně výhodné by přitom bylo ztotožnit OSPF oblasti se zavedenými geografickými oblastmi v hierarchii adres z předchozího textu. Máme několik možností, jak se zachovat, můžeme: •

Vytvořit a číslovat OSPF oblasti podle adresních prefixů geografických oblastí. V pří­ padech, kdy není možno propojit některou oblast přímo na páteřní oblast, je nutné využít tzv. virtuálních linek, jenž umožní propojení s páteří i skrze jinou než páteřní oblast. Za zachování čitelného adresního plánu zde platíme zvýšenou režií virtuál­ ních linek.

•

Vytvořit naopak adresaci oblastí tak, aby respektovala předpokládanou topologii sítě. Výhoda ztotožnění však nemusí být trvalá, neboť zásadnější změna topologie opět přinese dilema - zda raději přeadresovat, nebo nasadit virtuální linku. Prakticky vzato nelze pro svou závislost na topologii připravit tímto způsobem dopředu plošné roz­ dělení adres pro větší území a přeadresování je též nereálné. 28

4.3. SMĚROVÁNÍ •

Opustit na pohled hezkou myšlenku ztotožnění obou typů oblastí jedna ku jedné, OSPF oblast může následně zahrnovat vícero adresních oblastí. V případě změny to­ pologie znamená přesun části sítě do jiné oblasti pouze opravu konfigurací dotyčných OSPF démonů, což je již realizovatelné.

Vzhledem k faktu, že s virtuálními linkami nemám zatím praktické zkušenosti, ponechávám výběr varianty na operátorovi univerzální služby. V síti Slovácko Free Net jsme s kolegy zvolili třetí možnost. Definice nákladů na jednotlivé linky může odrážet více charakteristik. Běžně se uvádí zejména přenosová kapacita spojů, případně jejich latence či další kvalitativní parametry. Pro univerzální službu, založenou převážně na bezdrátových spojích, jsem připravil orien­ tační tabulku metrik, odvozenou od momentálně dostupných přenosových technologií. Ve výjimečných případech po pečlivém prostudování reálné situace může samozřejmě admi­ nistrátor nastavit i jiné hodnoty. Nižší hodnota znamená vyšší prioritu. Technologie Gigabit Ethernet Fast Ethernet Spoj E3 v licenčním pásmu Spoj 20 M b / s Full-Duplex v pásmu 10GHz Spoj 20 M b / s Half-Duplex v pásmu 5GHz Mírně zarušený spoj v pásmu 5GHz

Metrika 250 500 750 1000 2000 5000

Tabulka 4.3: Tabulka metrik pro OSPF Při dynamickém směrování již úkolem správce není přímá úprava pravidel, nýbrž ko­ rektní nastavení směrovacího démona. Prakticky vzato ubude správci manuální práce, na druhou stranu ale musí znát detailně daný protokol a při konfiguraci být velmi obezřetný. Jeden špatně nakonfigurovaný směrovač může aktivně rozšířit problémy na celou síť. Na Linuxu máme k dispozici hned několik otevřených implementací směrovacích dé­ monů. Dříve oblíbená Zebra 6 nebyla již dva roky aktualizována, proto vznikla odštěpením novější vývojová větev, Quagga 7 . Za zmínku stojí i český směrovací software BIRD8, vyví­ jený na Karlově Univerzitě. V distribuci přiložené na CD je předinstalována Quagga. Její konfigurace není i díky nepřesné dokumentaci úplně triviální, ukázky jejího nastavení pro síť univerzální služby proto čtenář najde na přiloženém CD. Jedná se o její společnou konfiguraci pro všechny protokoly (zebra.conf) a konfiguraci jejího démona pro OSPF (ospfd.conf).

6. 7.

GNU Zebra, < h t t p : //www. z e b r a . o r g > Quagga Routing Software Suite, < h t t p : //www. q u a g g a . n e t >

8. BIRD, < h t t p : / / b i r d . n e t w o r k . c z >

29

Kapitola 5

Systémová platforma směrovačů a přístupových bodů Výběr směrovačů je pro výstavbu jakékoliv rozsáhlejší počítačové sítě zásadní. Pod pojmem platforma směrovačů zde rozumíme komplexní souhrn hardwarového a softwarového vy­ bavení, zajišťující v síti směrování a dodatečnou funkcionalitu. Platforma přístupových bodů pak zajišťuje bezdrátový přístup koncových klientů k síti. Jak si ukážeme, lze s vý­ hodou použít jedno unifikované otevřené řešení, vhodné pro oba zmiňované účely - rozdíly budou jen v konfiguraci. Jako součást platformy práce prezentuje též pracovní nástroje a postupy, nutné pro rutinní nasazování a údržbu technologie. Platforma je založená na běžné PC architektuře s otevřeným operačním systémem Linux. To umožňuje plnou kontrolu nad všemi aspekty řešení až na úroveň zdrojového kódu, je-li třeba. Že jde o perspektivní směr vývoje ukazuje i projekt Liberouter, který se zaměřuje na vývoj vysokorychlostního PC směrovače pro optické páteře. Výstupem této části práce je též obraz prezentovaného systému na přiloženém CD, včetně pomocných skriptů a ukázkového nastavení všech podstatných komponent. 5.1

Hardwarové vybavení

Při volbě hardwarového vybavení pro směrovače jsem přihlížel k následujícím kritériím: preferovaná architektura x86 (důvody uvádím níže) podpora hardware v OS Linux spolehlivost a životnost výkon a rozšiřitelnost aktuální a výhledová dostupnost na trhu V praxi se dobře osvědčilo použití běžných počítačů PC, které je vhodné pro naše spefické nasazení mírně modifikovat. Na rozdíl od aplikačních serverů v data centrech jsou směrovače přístupových sítí značně geograficky roztroušené. Především je proto třeba maxi­ málně omezit veškeré pohyblivé součásti, které by jinak při non-stop provozu způsobovaly svojí nespolehlivostí výpadky. Vhodné je tedy vyměnit pevný disk za paměť typu Com­ pact Flash (CF karta s redukcí) a pokud je to možné, omezit množství větráčků. Procesor a chipset můžeme chladit např. s pomocí Peltierových článků, zdroje lze pořídit i v provedení 30

5.2. OPERAČNÍ SYSTÉM A PROGRAMOVÉ VYBAVENÍ bez větráčků. Vhodné je též zavedení určité míry redundance, například právě zdroj bývá v serverech běžně zdvojený. Takto upravené PC je vhodné zejména na páteřní směrovače, kde je požadován vysoký výkon a kde příliš nezáleží na velikosti, odběru a produkovaném teple. V praxi je podobné řešení využíváno dokonce i na místech, kde se běžně využívají osvědčené značky jako Cisco či Juniper - např. jako brána operátora do NIXu. Pro směrovač přístupové sítě a přístupové body je ovšem vhodnější využít miniaturizo­ vaný a specializovaný hardware - tzv. embedded pc. Důležité je vybrat takový model, který je osazen procesorem architektury x86. Díky tomu lze v případě potřeby okamžitě přenést systém na výše uvedené klasické PC a při provozování obou typů hardwaru není třeba ak­ tualizovat dvě verze operačního systému. Provozovatel sítě tak šetří lidské zdroje a navíc má jistotu, že pokud by z jakýchkoliv důvodů nebylo embedded řešení byť jen dočasně k dispozici, běžné PC zde bude vždy. V současné době jsou na trhu k dispozici desky osazené x86 čipy AMD z produktové řady Geode™ 1 . Jde např. o desky firmy Soekris nebo u nás zavedenější desky WRAP od PCEngines 2 . Právě desky WRAP se mi velmi dobře osvědčily v reálném provozu, proto bude následující řešení optimalizováno pro WRAP Mezi nejpodstatnější vlastnosti těchto systémů patří: •

procesor AMD Geode SCI 100 266MHz (i586) se 128MB SDRAM

•

1 slot na Compact Flash (CF) kartu v IDE režimu

•

až 2 rozšiřující sloty mini-PCI

•

až 3 nezávislé Ethernet porty

•

1 sériový port s přesměrováním konzole

•

rozhraní GPIO a LPC pro další rozšíření

•

integrovaný hardware watchdog

•

spotřeba cca 4W, minimální tepelný výkon

5.2

Operační systém a programové vybavení

Chceme-li v síti použít dostatečně stabilní, otevřený a svobodný operační systém, můžeme vybírat hned z několika unixových systémů typu BSD či mnoha distribucí Linuxu. Má volba padla na linuxovou distribuci Debian GNU/Linux 3 , a to hned z několika důvodů. Debian je 1. AMD Geode Processor Family, 2. PC Engines WRAP, < h t t p : //www.pcengines . ch/wrap. htm> 3. Debian GNU/Linux, < h t t p : //www. debian . org>

31

5.2. OPERAČNÍ SYSTÉM A PROGRAMOVÉ VYBAVENÍ tradičně konzervativní distribuce, má širokou vývojářskou základnu, bohatý výběr balíčků včetně bezpečnostních aktualizací a přesto je základní instalace poměrně nenáročná na dis­ kový prostor. Svoji roli samozřejmě hrají také osobní preference a dobré zkušenosti, které s tímto systémem mám. Výklad je tedy psán na míru Debianu, metodika by se ale v případě použití jiné linuxové distribuce neměla významněji lišit. V případě použití systému typu BSD by již byly rozdíly větší. Debian, stejně jako většina klasických distribucí systému Linux, je určen pro instalaci na pevný disk. Paměti flash, na které chceme systém instalovat, mají však oproti pevným dis­ kům určitá omezení a zvláštnosti, které je třeba zohlednit. Totiž, flash disky jsou zpravidla řádově menší kapacity a mají omezený počet zápisů, podléhajících zvláštnímu režimu. Z to­ hoto důvodu je vhodné instalaci z originální distribuce mírně modifikovat. Prakticky vzato znamená z hlediska telekomunikačního operátora správa těchto modifikací zvýšené nároky na lidské zdroje. Proto se v následujícím výkladu držím pravidla: čím méně vlastních mo­ difikací, tím lépe. Teoreticky by stačilo jednorázově vytvořit obraz modifikovaného systému a následně jej už jenom kopírovat na jednotlivá zařízení, tak jako se tomu děje v továrnách na různé produkty vybavené linuxovým firmware. Nicméně i taková zařízení občas potřebují aktua­ lizovat a v našem případě tomu nebude jinak. Pro správu modifikované distribuce a jejich aktualizací si proto zavedeme vlastní repositář Debian balíčků. Mimo jiné do něj následně můžeme přidávat balíčky, obsahující programy vlastní výroby. Shrňme si nyní postupy, které uplatníme při instalaci, údržbě a distribuci programového vybavení směrovačů a přístupových bodů. Nejprve nainstalujeme originální systém Debian GNU/Linux na pevný disk nástrojem Debootstrap. Tuto instanci systému poté zeštíhlíme pro naše použití odebráním nepotřeb­ ných balíčků, naopak přidáme potřebné balíčky týkající se převážně síťových služeb. Vytvo­ říme si vlastní repositář balíčků s obslužnými skripty, do něj nakopírujeme použité balíčky, které můžeme ještě zeštíhlit odstraněním nepotřebných částí, např. dokumentace a locales. Opět pokud možno skriptovaně, neboť vlastní repositář bude nutno synchronizovat s bez­ pečnostními aktualizacemi původní distribuce. Připravíme si vlastní optimalizované jádro a vytvoříme výchozí nastavení. Dále vycházím z prakticky ověřeného předpokladu, že zatímco u první, testovací insta­ lace je dobré postupovat pečlivě podle standardního instalačního postupu dané distribuce, při praktickém nasazování je lepší uplatnit předem připravené obrazy systému. Usnadní se tím instalační proces nového stroje a eliminují se nechtěné odlišnosti v jednotlivých in­ stancích. S pomocí automatických aktualizací z vlastního repositáře operátora je i následná údržba strojů pod jeho plnou kontrolou. Možnosti správy konfigurací jednotlivých strojů rozvádím podrobněji na jiném místě práce.

32

5.2. OPERAČNÍ SYSTÉM A PROGRAMOVÉ VYBAVENÍ 5.2.1 Použití souborového systému JFFS2 na kartách CF Specifikum flash pamětí spočívá ve způsobu zápisu, neboť nastavení bitu na hodnotu 0 (mluvíme o zápisu) se technologicky liší nastavení bitu na hodnotu 1 (mluvíme o mazání). Zatímco zápis je možný tak jako u pevného disku po sektorech velikosti maximálně jed­ notek KB, mazání je možné jen po blocích (eraseblock) velikosti řádově stovek KB. Jinými slovy, zápis do smazaného bloku je přímý, ale změna byť jediného zapsaného bajtu zna­ mená přepis celého bloku. Je tedy třeba data aktualizovat nejprve mimo flash (v operační paměti), což může mít za následek i jejich ztrátu v případě výpadku napájení. Předcházet ztrátě dat a zároveň šetřit médium před výše uvedeným zbytečným opo­ třebením je možné nasazením specializovaného souborového systému se strukturou logu. U takového systému jsou modifikace ukládány jako další přídavné záznamy (logy), které zneplatní původně uložené verze. Jednou z mála 4 opensource implementací pro Linux je ča­ sem prověřený JFFS25, který navíc podporuje kompresi hned několika různými algoritmy, čímž zároveň šetří i kapacitu média. Naopak mezi nevýhody patří zejména lineární paměťová náročnost, neboť index pro čtení souborů je na rozdíl od běžných souborových systémů veden výhradně v paměti. Li­ neární je také čas potřebný k připojení systému, tento problém ale řeší zavedení takzvaných Erase Block Summary 6 . JFFS2 proto bývá využíváno především v malých embedded zařízeních s přímým přístu­ pem k paměti flash pomocí linuxových ovladačů Memory Technology Devices 7 . Rozhraní MTD na rozdíl od běžných blokových zařízení systému Unix respektuje specifika pamětí flash. Např. eraseblocks pamětí flash jsou typicky větší než maximální velikost bloku u blo­ kového zařízení systému Unix atd. Karty CF však obsahují vlastní IDE kontrolér kompatibilní s rozhraním PCMCIA-ATA, a proto se chovají z hlediska operačního systému jako běžné blokové zařízení. Na jednu stranu nám tato skutečnost může zjednodušit přístup k médiu, na stranu druhou nás bo­ hužel i omezuje. Zda a jak tento integrovaný kontrolér řeší opotřebení média nám totiž vět­ šinou zůstane výrobcem utajeno. Přesto má smysl JFFS2 používat i s kartami CF pro svou odolnost vůči výpadkům a kompresi. Je k tomu zapotřebí navíc modul blkmtd do jádra, emulující rozhraní MTD nad blokovým zařízením. Otázkou zůstává, jak zjistit správnou velikost mazacích bloků. Jedinou mne známou možností je získat tuto informaci přímo od výrobce, což nemusí být vždy možné. Další drobnou nepříjemností je fakt, že JFFS2 nepodporuje sdílené zapisovatelné ma­ pování do operační paměti (v linuxu funkce mmap). Nejde o nedostatek v implementaci, ale o vlastnost všech souborových systémů se strukturou logu. Z tohoto důvodu je potřeba upravit některé aplikace, využívající tuto funkci. Zejména jde o samotný balíčkovací systém Apt, na který musíme aplikovat neoficiální záplatu 8 . Je s podivem, že ačkoliv tento problém 4. Pro Linux jsou k dispozici implementace YAFFS, JFFS a JFFS2. V přípravě je implementace JFFS3 a LOGFS. 5. Journaling Flash File System 2, < h t t p : / / s o u r c e s . r e d h a t . com/j f f s 2 / > 6. JFFS2 improvement project, < h t t p : //www. i n f . u - s z e g e d . h u / j f f s 2 /mount .php> 7. Memory Technology Devices, < h t t p : //www. l i n u x - m t d . i n f r a d e a d . o r g > 8. Debian Bug #314334 < h t t p : / / b u g s . d e b i a n . o r g / c g i - b i n / b u g r e p o r t . c g i ? b u g = 3 1 4 33 4>

33

5.2. OPERAČNÍ SYSTÉM A PROGRAMOVÉ VYBAVENÍ s Aptem byl znám již v roce 2001, jako chyba byl nahlášen až v roce 2005 a v době psaní této práce stále ještě nebyl oficiálně odstraněn. 5.2.2 Instalace základů systému Debian GNU/Linux na CF kartu Pro instalaci a veškeré následující kroky jsem použil svoji stávající instanci Debianu na pra­ covním notebooku. Ta obsahuje v balíčcích všechny potřebné nástroje a v případě potřeby je lze snadno dohledat nástrojem apt-cache. Základní instalaci Debian GNU/Linuxu ve verzi Sarge jsem provedl programem Debootstrap nejprve do pomocného adresáře. Již v této fázi bylo možno předem vyloučit nepo­ třebné balíčky, avšak bez kontroly závislostí. Proto jsem raději jejich odstranění nechal na později. Jako distribuční zdroj jsem použil jedno z českých zrcadel, sekvence příkazů pak vypadala následovně: # p ř í k a z y j e t ř e b a vykonávat jako s u p e r u ž i v a t e l su # i n s t a l a c e základních systémových b a l í č k ů mkdir / m n t / i n s t a l l d e b o o t s t r a p - - a r c h Í386 sarge / m n t / i n s t a l l h t t p : / / d e b i a n . s h . c v u t . c z # n a s t a v e n í s p o u š t ě n í nového systému na v i r t u á l n í konzoli t t y 8 echo " p r o c - i n s t a l l / m n t / i n s t a l l / p r o c proč none 0 0" >> / e t c / f s t a b mount / m n t / i n s t a l l / p r o c echo " 8 : 2 3 : r e s p a w n : / u s r / s b i n / c h r o o t / m n t / i n s t a l l " \ " / s b i n / g e t t y 38400 t t y 8 " >> / e t c / i n i t t a b init q Tím jsem získal příkazovou řádku standardně instalovaného systému, se kterým jsem začal vývoj vlastních úprav systému. Především bylo potřeba: •

Sestavit kolekci balíčků. Tzn. doinstalovat chybějící software, včetně samotného já­ dra a opravené verze Apt podporující JFFS2. Odstranit nepotřebný software a zkont­ rolovat závislosti. Výsledný přehled nezbytného programového vybavení uvádím ve zvláštní příloze.

•

Připravit základní nastavení. Abych systém mohl poprvé vyzkoušet na samostat­ ném stroji, bylo třeba nastavit zavaděč systému GRUB a sériovou konzoli. Následo­ vala samozřejmě další nastavení, jejichž výstupem je sada textových konfiguračních souborů na přiloženém CD.

•

Rozdělit systém na oddíly a vytvořit testovací obrazy systému na CF. Více oddílů je zapotřebí pro použití JFFS2, ze kterého neumí GRUB načíst svoji konfiguraci. Je také vhodné vytvořit oddíl zvlášť pro ukládání stavových informací.

•

Vytipovat nepotřebné soubory v systému. Výsledkem je seznam souborů, které mů­ žeme ze systému beze ztráty funkčnosti odstranit. Tento seznam je poté využíván pro 34

5.2. OPERAČNÍ SYSTÉM A PROGRAMOVÉ VYBAVENÍ automatickou tvorbu vlastního repositáře balíčků. Hodně místa lze ušetřit obecným pravidlem pro odstranění dokumentace, odstraněním locales a podobně. Tento krok není nezbytně nutný v případě použití CF karet velké kapacity. Výsledkem tohoto mého vývoje je jednoduché prostředí pro softwarovou instalaci směrovačů a přístupových bodů. Instalační skript pro interaktivní přípravu nového systému za­ hrnuje všechny výše uvedené kroky. Bere také v potaz vlastní repositář balíčků, o němž se zmiňuji v následující části textu. Pro vývoj jsem použil CF kartu velikosti 128MB. S ohledem na budoucí případné roz­ šiřování funkcionality a především ukládání stavových informací a statistik bych ale raději doporučil velikost 256MB. Karta byla připojena redukcí do PCMCIA slotu pracovního no­ tebooku, kde jí bylo systémem přiřazeno zařízení / d e v / h d e . Kartu jsem rozdělil na oddíly příkazem fdisk následovně: Oddíl /dev/hdel /dev/hde2 /dev/hde3

Velikost 8MB 20 MB 100 MB

Cesta /boot /var /

Souborový systém ext2 jffs2 jffs2

Poznámka aktivní oddíl pro boot systému pro ukládání dynamických dat hlavní systémový oddíl

Tabulka 5.1: Tabulka oblastí a jejich použití na CF kartě

5.2.3 Tvorba repositáře a vlastních balíčků Důraz jsem kladl na systematičnost, díky které bude další údržba vlastního repositáře ča­ sově nenáročná. Máme v podstatě dvě varianty použití vlastního repositáře: •

Použití jako jediného zdroje balíčků. Co jsme si do repositáře nedali, to na strojích nebude k dispozici. Tento přístup nás vede k pečlivé probírce originálních balíčků při jejich postupném zařazování, a tudíž k pečlivému testování. Na druhou stranu to znamená nutnost každodenně sledovat a zařazovat bezpečnostní aktualizace a nepo­ hodlným se stane testování nových programů.

•

Použití jen jako doplňujícího zdroje balíčků. Systém Apt umožňuje brát balíčky z více zdrojů a detailně nastavit jejich priority (tzv. Pinning 9 ). Např. balíčky s jádrem (kvůli vlastní konfiguraci) a samotným Aptem (kvůli podpoře JFFS2) chceme vždy jen z našeho zdroje, nezávisle na verzích. Naopak, nad námi jen mírně upravovanými balíčky (redukce velikosti) by měly mít z bezpečnostních důvodů přednost originální aktualizace. Pro mou práci jsem zvolil tuto druhou variantu, která mi pro použití u operátora přijde praktičtější.

Příprava a údržba repositáře je snadná díky několika jednoduchým nástrojům, jejichž použití je dobře zdokumentováno v manuálových stránkách. Nástrojů pro tvorbu indexů 9. Apt-Pinning for Beginners, < h t t p : / / j a q q u e . s b i h . o r g / k p l u g / a p t - p i n n i n g .html>

35

5.2. OPERAČNÍ SYSTÉM A PROGRAMOVÉ VYBAVENÍ repozitáře je ve skutečnosti dokonce několik, což může být matoucí. Proto zde pro rychlou orientaci uvádím alespoň jejich stručný přehled: •

dpkg-deb - slouží k manipulaci s binárními balíčky. Posloupnost příkazů pro odstra­ nění dokumentace z balíčku pak může vypadat následovně: dpkg-deb - - e x t r a c t . / f o o . d e b /tmp/foo dpkg-deb - - c o n t r o l . / f o o . d e b /tmp/foo/DEBIAN rm - r f / t m p / f o o / u s r / s h a r e / d o c rm - r f / t m p / f o o / u s r / s h a r e / m a n dpkg-deb - - b u i l d /tmp/foo . / s t r i p p e d / f o o . d e b rm - r f /tmp/foo

•

dpkg-buildpackage - slouží k překladu zdrojových balíčků do binární podoby. Je potřeba použít spíše výjimečně, např. pokud chceme na zdrojové kódy aplikovat zá­ platu či provést specifickou optimalizaci překladačem.

•

dpkg-scanpackages - vygeneruje seznam balíčků pro minimální verzi repositáře. Vy­ tvořený repozitář ale nepodporuje Pinning, proto jej v našem případě nemůžeme po­ užít.

•

apt-f tparchive - vytváří komplexní indexy balíků, umožňující plnohodnotné použití repositáře. Pro každý repositář je nutno připravit odpovídající konfiguraci, následné vygenerování indexových souborů pak je již prosté, lze ho vložit i do Cronu: apt-ftparchive generate apt-ftparchive.conf a p t - f t p a r c h i v e -c l o c a l - s a r g e - r e l e a s e . c o n f r e l e a s e d i s t s / s a r g e / \ > dists/sarge/Release

Na přiloženém CD lze opět dohledat mé drobné obslužné skripty k údržbě balíčků a repositáře i ukázku samotného repositáře. 5.2.4 Kompilace vlastního jádra Pro optimální chod linuxového operačního systému v podobně specializované roli je vždy vece než rozumné připravit vlastní jádro. Je pro to hned několik dobrých důvodů, které se promítají do následujících úprav jádra, jenž jsem provedl: •

Aplikace záplat, opravujících známé chyby či rozšiřujících jádro o nestandardní, a přesto potřebné funkce. V našem případě např. přidání některých plánovačů paketů, podpora watchdogů a zrušení klávesnice pro jednotky WRAP

•

Vypnutí přebytečných ovladačů a funkcí, jenž vede k menšímu, efektivnějšímu a odolnějšímu jádru, úzce zaměřenému na realizaci požadovaných úkolů. Pro směrovače a přístupové body je skutečně většina ovladačů zcela nepotřebná (namátkou vstupní zařízení, multimediální karty, mnohé disky a usb zařízení a podobně). 36

5.2. OPERAČNÍ SYSTÉM A PROGRAMOVÉ VYBAVENÍ •

Optimalizace a ladění výkonu, určené s ohledem na použitý hardware a detaily za­ mýšleného využití stroje. Jde zejména o volbu procesoru - pro WRAP a PC lze pou­ žít kód pro procesory 586 a vyšší. Samozřejmostí je maximum funkcí přímo v jádře, v odůvodněných případech v modulech, a to vše bez použití initrd.

Přípravu jádra nám Debian opět značně zjednodušuje. Nástroj jménem kernel-package poskytuje přímočaré rozhraní pro komplexní úkol záplatování, kompilace a balíčkování já­ dra. Výsledný balíček obsahuje jádro i skripty, jenž se při jeho instalaci postarají o jeho ko­ rektní přidání do zavaděče systému. Stručný postup vypadá následovně: su cd / u s r / s r c

# kompilaci provádíme jako r o o t # v~příslušném a d r e s á ř i

# stáhnout a r o z b a l i t j á d r o wget h t t p : / / k e r n e l . o r g / p u b / l i n u x / k e r n e l / v 2 . 4 / l i n u x - 2 . 4 . 3 2 . t a r . b z 2 t a r xvjf . / l i n u x - 2 . 4 . 3 2 . t a r . b z 2 cd . / l i n u x - 2 . 4 . 3 2 # p ř i p r a v i t z á p l a t y do / u s r / s r c / k e r n e l - p a t c h e s # p ř i p r a v i t s i k o n f i g u r a c i j á d r a , s~vyjímkou změn ze z á p l a t make menuconfig # vytvořit balíček make-kpkg c l e a n make-kpkg - - a p p e n d - t o - v e r s i o n ' - s f n ' - - r e v i s i o n 1 \ - - a d d e d - p a t c h e s esfq,watchdog,kbd - - c o n f i g o l d c o n f i g Před prvním použitím doporučuji pročíst manuálovou stránku pro make-kpkg. V době psaní práce jsem měl na výběr mezi již poměrně starou, ale velmi zažitou a osvěd­ čenou řadou jádra 2.4 a novější stabilní řadou 2.6. V příloze najde čtenář kompletní konfigu­ raci mnou uprednostneného jádra 2.4.32, na přiloženém CD pak obdobnou konfiguraci pro verzi 2.6.14.2. Samozřejmostí jsou hotové balíčky, využívané mým instalačním skriptem. 5.2.5 Konfigurační soubory a výchozí nastavení Součástí každého balíčku distribuce jsou i soubory, označené jako konfigurační. Dále balíčky obsahují instalační skripty, jenž zpravidla s interakcí uživatele provedou úpravu těchto po­ čátečních nastavení. Praxe u internetových poskytovatelů však zpravidla počítá se zaříze­ ními, jenž jsou již nainstalována a připravena pro konfiguraci přes webové rozhraní. Naše systémová platformu může být v případě potřeby připravena podobně. Jeden pracovník může provádět instalace systému, zatímco jeho kolega si již zařízení nastaví sám, aniž by musel mít podrobné znalosti Linuxu. Přehled důležitých konfiguračních souborů s popisem jejich funkce najde čtenář v pří­ loze. Možné implementace systému správy konfigurací shrnuje jiná kapitola práce. 37

5.3. BEZDRÁTOVÉ MODULY A JEJICH OVLADAČE 5.3

Bezdrátové moduly a jejich ovladače

Pro zabezpečení funkce přístupového bodu, případně bezdrátového směrovače, je třeba roz­ šířit systém o bezdrátové moduly a nainstalovat pro ně vhodné ovladače. V současné době je na trhu dostatek různých modulů standardu 802.11 s různými chipsety. Moduly standardu 802.16 jsem zatím na trhu nezaznamenal, neboť tato technologie je zatím teprve v rané fázi praktického nasazování. Podle zkušeností s nástupem WiFi se dají v první vlně očekávat zejména hotové externí zařízení renomovaných značek. Vzhledem k angažovanosti firmy Intel na vývoji nového standardu však též očekávám rychlý nástup rozšiřujících modulů pro notebooky. Použitelnost nových modulů v Linuxu nelze předem odhadnout. Bude záviset přede­ vším na ochotě výrobců chipsetů podporovat vývoj opensource ovladačů. Tento vývoj vy­ žaduje nejen čas a zájem širší programátorské veřejnosti, ale též dostupnost dokumentace chipsetů. Příklady z minulosti to jasně potvrzují. Chipset Prism II jenž má výbornou do­ kumentaci, byl záhy podporován a posloužil i vědecké veřejnosti pro vývoj nejrůznějších experimentálních úprav MAC protokolu. Naopak chipsety značky Atheros disponují do­ kumentací pouze za podmínek NDA, proto trvá vývoj opensource ovladačů déle. Někdy pomůže i tlak samotných uživatelů - Intel například po nátlaku ze strany linuxové komu­ nity poskytl podporu pro vývoj ovladačů bezdrátové části Centrina. Pro bezdrátové spoje WiMAX tak musí univerzální služba minimálně v počátcích počítat s nasazováním hotových externích produktů, s menším potenciálem pro správu a rozšiřitel­ nost o další funkce vlastními prostředky. 5.4

Praktické ověření výkonnosti

Z výše popsaného řešení systémové platformy nemusí být zcela zřejmé, zda disponuje výko­ nem dostačujícím pro poskytování univerzální služby. Zejména procesory jednotek WRAP jsou úzkým hrdlem systému. Proto zde uvádím několik zajímavých statistik, zaznamena­ ných během reálného nasazení v naší bezdrátové síti 10 . Sledován byl WRAP jménem Kryton, běžící na operačním systému Linux s jádrem 2.4.27. Na zatížení stroje má do značné míry vliv použití paketového filtru. Tento vliv byl však minimalizován, ve filtru bylo zadáno jenom 8 obecných pravidel. Kryton je osazen dvěma bezdrátovými mini-PCI moduly: •

ZCom XI-625 - standard 802.11b. Modul je založený na několik let starém chipsetů Prism II, který je dodnes velmi oblíbený pro dostupnost dokumentace a opensource ovladače HostAP Na Krytonovi je použito HostAP 0.2.4 v režimu AP pro připojení koncových klientů.

•

Wistron CM9 - standardy 802.11a/b/g. Obsahuje chipset Atheros 5212, použity jsou stále ještě experimentální opensource ovladače Madwifi verze 0.9.4.5. Modul byl v re-

10. Slovácko Free Net, < h t t p : //www. slovácko free .net>

38

5.4. PRAKTICKÉ OVĚŘENÍ VÝKONNOSTI zimu 802.11a klient pro páteř směrem do Internetu, k protistraně nebyl připojen žádný další klient. Cílem měření bylo zjistit, zda WRAP jako takový je schopen obsloužit dostatečné množství klientů požadovanou rychlostí. Sledováno proto bylo zejména celkové vytížení procesoru, ale také počet klientů na modulu ZCom a celkové datové průtoky na obou modulech (na páteři bylo měření prováděno na protistraně). Pro zaznamenání grafů jsem napsal vlastní skripty, které jsou opět na přiloženém CD. V y t í ž e n i procesoru za poslední týden

Wed I System

• Nice

Thu

Fri

Sat

Sun

Hon

Tue

• User

Obrázek 5.1: Celkové vytížení procesoru

Obrázek 5.2: Počet klientů asociovaných na modulu XI-625 Pozorování. Z grafů lze vyčíst poměrně jasnou korelaci mezi vytížením procesoru a po­ čtem bezdrátových klientů. Naopak samotná velikost datového toku již nemá na procesor tak významný vliv. Z toho můžeme usuzovat, že úzkým místem jsou právě ovladače rádi­ ových modulů. Po prostudování jejich dokumentace se ukázalo, že HostAP nepoužívá PCI Bus Mastering, což způsobuje procesoru zvýšenou zátěž. Závěr. Podle dosažených výsledků usuzuji, že WRAP bude schopen zvládnout i větší zátěž, požadovanou univerzální službou. Hodně však záleží na optimalizaci ovladačů bez­ drátových modulů a vhodně napsaných pravidlech paketového filtru. Jeho uplatnění před­ pokládám zejména v roli koncového přístupového bodu, případně samostatného směro­ vače. Výkon i stabilitu v roli směrovače lze navíc zlepšit přesunutím páteřních rádiových 39

5.4. PRAKTICKÉ OVĚŘENÍ VÝKONNOSTI

Obrázek 5.3: Datový tok na modulu XI-625

—i

• •i

i

i.....i.

i

J....E--------

i

i

i--- - i

i

i

Í-....Í

i

i

í-.-.-o

i

i

i.—

•i i !•-! ! I--J-! zs.

••i

i

••:

••|

j

Í-...-Í.

i

i-

T - - T

:

:••

Í....-Í-

j

U

1•

—

—

—

*

j- .

^sJJyAueft

>

Bits per second

w

Tue

Wed

Tnu

Fri

Sat

Sun

i

i

i

o •••••>

i

i

o •••••>••

:

;

Ť - - 7

:

:

Ť

1

1

í-.... í-

|

|

.;......;... , —i

T--T

:

:

T- - T

:

:

-.-..-

:

:

j

j - -• —H — j -

j

j

:

Mon

-

Ť

-

••

•

^ _

s

•

M

±.......

.j......j...

Tue

Obrázek 5.4: Datový tok na modulu CM9 modulů na dedikované stroje. Kombinované použití v roli přístupového bodu a směrovače je vhodné zejména na okrajích sítě. Naopak na páteřní směrovače a na stroje s dodatečnými požadavky na filtrování či prioritizaci provozu pak jednoznačně patří výkonnější PC hard­ ware.

40

Kapitola 6

Management sítě Nyní již víme, jakým způsobem a z jakých komponent síť stavět. Zbývá dořešit ne méně důležitou otázku provozu potenciálně velmi rozsáhlé sítě univerzální služby. Operátor musí mít dokonalý přehled o síti jako celku, o jejích službách a přípojkách. Za účelem evidence prvků sítě, služeb a uživatelů si operátoři mnohdy připravují vlastní informační systémy, jenž jim též umožňují udržet přehled o struktuře sítě a zachovat vysokou úroveň péče o zá­ kazníka i při dynamickém nárůstu jejich množství. Dále používají nejrůznější dohledové systémy, umožňující rychle reagovat na problémy v síti a pokud možno i problémům ak­ tivně předcházet. Detailní návrh a implementace uvedených systémů je mimo rozsah této práce. Proto je zde prezentován pouze přehled dílčích problémů správy a dohledu sítě a jejich možných řešení pomocí volně dostupného softwarového vybavení. Každý nástroj pro dohled a správu sítě potřebuje být pro svou funkci řádně konfiguro­ ván a to na hlavním dohledovém serveru, případně i na jednotlivých směrovacích. Stejně tak konfigurace samotného směrovače bývá obsáhlá. Tyto konfigurace vždy vyžadují zna­ losti sítě, jenž bývají uloženy typicky právě v databázi informačního systému. Ačkoliv bývá kompletní informační systém operátora značně rozsáhlý, část databáze nutná pro genero­ vání konfigurací může být poměrně kompaktní. Ukázkový datový model zapsaný v SQL pro opensource databázi MySQL najde čtenář v příloze. Zde jen orientační popis tabulek: •

net_router - tabulka směrovačů v síti obsahuje informace o směrovací jako celku, např. jednoznačný identifikátor, jméno, komentář, typ platformy (Linux WRAP, Li­ nux PC, jiná) a informace o svém umístění (příslušnost k PoP). Směrovač obsahuje dvě či více rozhraní. Za směrovač zde považujeme i koncový přístupový bod.

•

net_interface - tabulka rozhraní ve směrovacích obsahuje informace o použité tech­ nologii, číslo metriky a oblasti pro OSPF, příslušnost ke směrovací, parametry ke tvorbě grafů a komentář. K rozhraní se následně mohou přiřazovat klienti.

•

net_link - tabulka definující propojení mezi rozhraními obsahuje pouze identifikátory dvou rozhraní.

•

net_wireless - tabulka bezdrátových parametrů rozhraní. Obsahuje údaje jako jméno bezdrátové sítě (ESSID), zvolený kanál, zvolený provozní režim, ale také základní po­ známky k použité anténě a samozřejmě identifikátor rozhraní. Vzhledem k bezdrá41

6.1. MONITORING SÍTĚ A ÉTERU tovému způsobu připojení klientů je tabulka využívána i pro generování konfigurací pro klienty. net_address - tabulka síťových adres použitých na směrovacích, ale i u koncových klientů. Zároveň s adresami obsahuje i její typ (brána, adresa směrovače, adresa kli­ enta), velikost prefixu s různým významem pro jednotlivé typy adres, jméno pro zá­ znam do DNS a komentář. Obsahuje odkaz na síťové rozhraní. net_area - tabulka přiřazuje podsítě OSPF oblastem. Je nutná pro generování konfigu­ race Quaggy, pokud máme více dříve zmiňovaných adresních oblastí na jednu OSPF oblast. net_tech_router - přehled typů směrovačů, používaných v síti. Jedná se o praktickou informaci, jenž musí být po ruce nejen při generování konfigurací, ale i pro řešení případných provozních problémů. net_tech_interf ace - přehled typů síťových rozhraní. Pochopitelně jde prakticky vždy o Ethernet, nicméně další upřesnění je potřeba. Každý typ rozhraní má především svoji metriku a přepínač, zda se jedná o rozhraní bezdrátové. net_pop - evidence PoP lokalit sítě, určená především pro provozní techniky. Obsa­ huje adresy lokalit s kontakty na majitele objektů a podrobnosti k jednotlivým insta­ lacím síťových prvků. net_connection - základní informace o uživatelské přípojce. Mezi hlavní parametry přípojky patří příslušnost k rozhraní, použitá adresa (resp. adresní rozsah), příznaky pro monitoring, pole pro statistiky, přístupový klíč a samozřejmě identifikátor klienta.

6.1

Monitoring sítě a éteru

Operátor univerzální služby by měl pro zajištění požadované dostupnosti služby dispono­ vat síťovým operačním centrem (NOC) a nástroji pro co nejpřesnější diagnostiku stavu sítě. Správa sítě by měla být proaktivní, operátoři v centru by měli včas upozorňovat na pro­ blémy příslušné techniky a administrátory. Za tímto účelem je potřeba připravit sadu nástrojů, jenž nám umožní stav sítě v reálném čase sledovat. Monitorovat bychom měli jak samotnou funkčnost sítě, tak parametry důle­ žité pro sledování dlouhodobějších trendů, např. nárůstu zatížení sítě. Konkrétně můžeme sledovat např.: •

Zdraví aktivních prvků, tzn. například vytížení procesoru, využití paměti, provozní teplotu, stav jejich portů a rozhraní.

•

Zdraví a vytížení linek, tzn. zejména datový tok na portech a rozhraních (bajty a pakety za sekundu), latenci a ztrátovost paketů. U bezdrátových spojů též parametry jako odstup signál/šum (SNR) případně čítače různých chyb na příjmu. 42

6.1. MONITORING SÍTĚ A ÉTERU •

Obsazení frekvenčních kanálů v éteru, jenž se u nelicencovaných frekvenčních pá­ sem často mění ze dne na den díky využívání pásma širokou veřejností. Pravidelné skenování éteru může operátora včas upozornit na nutnost přeladit na jiný kanál.

•

Aktivitu uživatelů, samozřejmě jen na nezbytně nutné úrovni, což typicky znamená počítání přenesených dat, souhrnné počty aktivních uživatelů na jednotlivých přístu­ pových bodech a odhalování případných prohřešků proti podmínkám služby (útoky na cizí zdroje, přetěžování sítě, šíření nevyžádané pošty, virů a podobně).

Monitoring má zpravidla formu grafů a textových přehledů. Užitečné jsou též alarmy, upo­ zorňující na nové problémy a pro celkový přehled je dobrá kompletní stavová mapa sítě. Nyní si již pojďme představit příslušný software s možnostmi jeho nastavení. 6.1.1 Monitorovací systém Nagios Nagios je v praxi prověřený nástroj pro kompletní monitoring sítě a jejich služeb. Tento soft­ ware je uvolněn pod licencí GPL, což snižuje náklady na jeho zavedení a zároveň umožňuje modifikaci podle potřeb operátora. Systém může být provozován na jednom či více moni­ torovacích strojích (redundantní či failover monitoring) a sledovány mohou být tisíce strojů a služeb. Podporuje rozšiřování pomocí pluginů a externích příkazů a je proto možné mo­ nitorovat prakticky cokoliv. Existují i specializované společnosti, jenž s využitím Nagiosu poskytují kompletní dohledové služby. Z pohledu Nagiosu sestává síť ze strojů a jimi poskytovaných služeb. Stroje můžeme dále členit do skupin, např. podle tabulky net_tech_router. Zadáním vazeb mezi stroji (v na­ šem případě směrovací) z tabulky net_lmk získáme topologii sítě, kterou nám systém po­ sléze vizualizuje a mimo jiné podle ní následně vyhodnocuje dostupnost strojů a služeb. Ke každému směrovací si přiřadíme základní službu Ping, jenž nám bude monitorovat dostup­ nost samotného směrovače a jeho latenci. Tato konfigurace se odehrává v několika textových souborech: •

/etc/nagios/nagios.cfg - hlavní konfigurace systému

•

/etc/nagios/hosts.cfg - seznam strojů a vazeb mezi nimi

•

/etc/nagios/hostgroups.cfg - zařazení strojů do skupin

•

/etc/nagios/services.cf g - přiřazení služeb ke strojům Systém disponuje rozsáhlým webovým rozhraním, poskytujícím přehledy strojů, služeb alarmů a nejrůznější statistiky a historické přehledy. Velmi pěkně též zobrazuje stav sítě na 2D a s využitím VRML dokonce i 3D topologické mapě. Díky podrobným přístupovým právům k rozhraní je možné dát přístup široké škále uživatelů, např. pracovníkům podpory, technikům, administrátorům či dokonce obchodním zástupcům. Podrobnější přehled architektury a možností systému Nagios najde čtenář v [4] a na domovských stránkách projektu 1 . Ukázková konfigurace je přiložena na CD. 1.

43

6.1. MONITORING SÍTĚ A ÉTERU 6.1.2 Tvorba grafů pomocí RRDtool a odvozených nástrojů Sběr statistických dat pro dohled sítě je specifický svými nároky na přesnost v závislosti na čase. Přesněji řečeno, pro řešení problémů a reklamací jsou potřeba co nejpřesnější záznamy za poslední den či týden, zatímco rok staré záznamy už nás v takových detailech nezajímají. Z uvedeného pozorování vychází návrh databáze pevné velikosti s cyklickou strukturou tzv. Round Robin Database (RRD) a související nástroj pro ukládání záznamů a tvorbu grafů - RRDtool. Při ukládání nových dat do databáze jsou přepisovány nejstarší záznamy, které je možné i archivovat v menších detailech pro delší období. Jde o jednoduchý princip a velmi mocný nástroj, jehož typické využití spočívá ve třech krocích: •

Inicializace databáze příkazem rrdtool create. Pomocí sady parametrů jsou defino­ vány datové zdroje, tj. sledované proměnné a jejich typ, obor hodnot a frekvence zá­ pisu. Zároveň jsou zadefinovaný jejich archivy, jenž ukládají potenciálně agregované hodnoty pro určitý časový úsek - např. jeden archiv pro poslední týden a druhý pro poslední měsíc.

•

Aktualizace obsahu databáze spočívá ve sběru dat v pevném a pravidelném inter­ valu a jejich ukládání do databáze příkazem rrdtool update. Samotný RRDtool sběr dat nijak neřeší, je nutné použít externí programy či skripty. Lze tudíž ukládat prak­ ticky cokoliv, např. množství přenesených dat, teplotu procesoru či vstupní napětí na rádiových spojích.

•

Generování grafů příkazem rrdtool graph a jejich vystavení na webovém serveru, většinou opět pravidelně programem Cron. Graf může obsahovat přímo datové zdroje z jedné či více RRD databází, ale i jejich různé kombinace a odvozeniny. Lze tak např. přepočítávat bajty na bity nebo vytvářet pětiminutové průměry. Grafické možnosti zahrnují kresbu čar, výplní, legendy a podobné.

Obdobně jsem tedy připravil balíček graphing, přiložený na CD a použitý pro výše uvá­ děné výkonostní testy. Skript sfn-rrd-datagrab inicializuje a plní databáze, skript sfn-rrdgraphgen generuje grafy. Pravidelné volání obou skriptů zajišťuje konfigurační soubor sfnrrd pro Cron, ke konfiguraci jednotlivých databází a grafů slouží komentovaná konfigurace rrd.conf. Uvedené skripty využívají přímo RRDtool a svoji jednoduchou funkci plní spolehlivě. Pokud však chceme sledovat větší množství strojů, což se v případě univerzální služby předpokládá, narazíme pracnost podobných manuálních řešení. Naštěstí je však RRDtool již natolik rozšířeným a typickým řešením, že si můžeme vybírat ze široké škály nadstaveb. Některé mnou vyzkoušené zde stojí za zmínku: •

2.

Smokeping je nástroj pro pokročilou tvorbu grafů latencí a ztrátovosti paketů, s jed­ noduchou konfigurací a hodnotnými grafy. Princip spočívá v testování mnohonásob­ ným pingem a následném zobrazení procenta ztrát, mediánu a rozptylu latencí.2 Smokeping,

44

6.1. MONITORING SÍTĚ A ÉTERU •

MRTG neboli Multi Router Traffic Grapher založený na sběru informací o síťovém provozu skrze snmp a následném ukládání a zobrazení skrze RRD. Výhodný např. v situacích, kdy chceme tvořit grafy průtoků na portech vzdálených přepínačů. 3

•

Weathermap4RRD je RRD variací klasické mapy vytížení sítě. Na základě RRD da­ tabází provozu na rozhraních směrovačů dokáže vykreslovat mapy vytížení, ze kte­ rých jde rychle vypozorovat úzká místa sítě. Vhodné zejména pro sledování páteřních okruhů. 4

6.1.3 Skenování éteru programem Kismet Mezi každodenní starosti operátora bezdrátové sítě patří řešení plánování rozvoje sítě a ře­ šení problémů s rušením. Pro správné plánování frekvenčního pásma je třeba znát nejen nastavení vlastních prvků sítě, ale i situaci v reálném éteru. Je třeba prokazovat ohledupl­ nost vůči stávajícím provozovatelům sítí a jimi zabraným pásmům. Pochopitelně však kolize v bezlicenčním pásmu vyloučit nelze, přičemž následné problémy je třeba rychle diagnosti­ kovat a řešit. Za tímto účelem obsahuje prezentovaná platforma program Kismet 5 , jenž poskytuje dobrý základ pro sledování a diagnostiku éteru. Pomocí speciálního monitorovacího módu rfmon ovladačů bezdrátových modulů je možné pasivně zachytávat rámce na druhé síťové vrstvě, včetně všech detailů protokolu 802.11. Oproti jiným nástrojům dokáže vysledovat nejen pří­ stupové body, ale i klienty bezdrátových sítí, kteří jsou mnohdy se špatně nastaveným kon­ covým zařízením zdrojem rušení. Kismet obsahuje i kód pro rozpoznání útoků proti bez­ drátovým sítím či pro rozpoznání aktivních skenerů. Díky modulární architektuře můžeme bezdrátový monitorovací systém vystavět následovně. Systém sestává ze tří základních sou­ částí: •

kismet_drone je malý nástroj, určený pro samotný sběr dat. Jedná se vlastně o agenta, jenž naslouchá na bezdrátových modulech daného stroje a získané informace nabízí dále po síti serverům. Dokáže zpracovávat více těchto zdrojů zároveň a stejně tak se k němu může připojit i více serverů.

•

kismet_server centrálně shromažďuje data od agentů v síti v několika různých for­ mátech. Např. informace o nalezených sítích ukládá ve formátu XML či CSV, kom­ pletní obsah zachycených rámců pak ve formátu analyzátoru Ethereal 6 . Server umož­ ňuje například data sloučená z více zdrojů v reálném čase filtrovat podle adres a vý­ sledek nabízí uživatelům k vizualizaci opět i dálkově po síti.

•

kismet_ui je frontend pro vizualizaci dat, agregovaných serverem. Jednoduché tex­ tové rozhraní poskytuje vše potřebné pro získání dokonalého přehledu éteru. Lze

3. 4. 5. 6.

MRTG, Weathermap4RRD,

45

6.2. SPRÁVA KONFIGURACÍ AKTIVNÍCH PRVKŮ třídit nalezené sítě podle kanálu, síly signálu, množství přenášených dat a podobně. K dispozici jsou i další frontendy, např. grafický GKismet 7 a díky dostupnosti kniho­ ven je možno napsat i vlastního, např. jako součást informačního systému či jako plugin pro Nagios. Asi největším praktickým nedostatkem je nemožnost naslouchání za běžného provozu, neboť modul je vždy přepnut do módu rfmon a tudíž přestává plnit svou původní funkci klienta či přístupového bodu. Vzácnou výjimkou jsou některé ovladače, jenž za tímto úče­ lem při přechodu do rfmon módu původní funkci karty zachovávají. Elegantním, i když trochu dražším řešením může být připojení jedné antény slučovačem ke dvěma radiovým modulům, přičemž jeden bude provozován pouze za účelem monitoringu. V tomto případě lze uvažovat o dalších rozšířeních systému směrem k nepřetržitému a automatickému vy­ hledávání a řešení frekvenčních kolizí. Jinak má operátor alespoň v pohotovosti koncové agenty pro případné problémy s bezdrátovými spoji. 6.2

Správa konfigurací aktivních prvků

Správci linuxových serverů typicky využívají manuální úpravy textových konfiguračních souborů skrze vzdálený terminál ssh. I když jde o jednoduchou a bezpečnou metodu, při velkém rozsahu provozované sítě již nedostačuje svou pracností a nesystematičností. Je tedy třeba najít další nástroje a zároveň pečlivě rozmyslet postupy tvorby a správy konfigurací aktivních prvků. Pamatovat musíme například na následující situace: •

instalace nového stroje

•

příležitostná ruční změna konfigurace

•

výměna problémového stroje kus za kus

•

výměna slabšího stroje za výkonnější

•

obnova některé z předchozích konfigurací

•

nahlédnutí technické podpory do aktuální konfigurace

6.2.1 Řešení pomocí systému správy verzí Jak již bylo řečeno, konfigurace má podobu textových souborů. Operace nad konfigurač­ ními soubory tedy zahrnují podle situace tvorbu, úpravu, čtení či aktivaci změn. Zároveň je ale zřejmý požadavek na archivaci a dostupnost více variant nastavení, jež se měnilo v čase. Odtud pramení myšlenka využít některý systém správy verzí, určený pro úschovu zdro­ jových kódů. Dobrou volbou je Subversion 8 , jenž je oproti obdobnému CVS modernější a disponuje i aplikačním rozhraním. 7. Nagios, 8. Subversion,

46

6.2. SPRÁVA KONFIGURACÍ AKTIVNÍCH PRVKŮ Informační

systém

Repozitář

konfigurací

export

1 DB (net_*)

Editace konfigurace

svn commit

A kopie

Pracovní repozitáře

ptm Linuxový

svn update

směrovač

LV-Ď Záložní konfigurace

Hlavní konfigurace

Administrátor

Obrázek 6.1: Blokové schéma systému správy konfigurací Princip řešení spočívá v záměně přímé editace textových konfigurací na směrovací za editaci skrze rozhraní informačního systému. Celkově řešení zahrnuje následující čtyři en­ tity: •

Informační systém s dříve popsanou databází, uživatelským rozhraním a pracovní kopií repositáře 9 . V informačním systému je aktuální konfigurace uložena přímo v da­ tabázi, pracovní kopie slouží pouze jako mezičlánek exportu do repositáře.

•

Subversion repositář obsahující textové konfigurace v podobě přímo použitelné smě­ rovací a přístupovými body. Jako vhodný doplněk k repositáři může administráto­ rům posloužit webové rozhraní, nám se v praxi osvědčil Trac10. Mimo jiné lze re­ positář a Trac zároveň využít i pro vedení dokumentace sítě a k vývoji pomocných skriptů.

•

Linuxový směrovač či přístupový bod s nástrojem svn pro načítání konfigurace z re­ positáře. Mechanismus spuštění aktualizace konfigurace může vypadat různě. Proces může spustit administrátor přímo přes ssh nebo webové rozhraní, případně kom­ fortněji přes informační systém. Směrovač si nejprve pro jistotu zazálohuje původní

9. Jde o zcela jiný typ repositáře, než byl probírán v předchozí kapitole - viz podrobnosti v následujícím textu. 10. Trac,

47

6.3. SPRÁVA A ÚČTOVÁNÍ UŽIVATELŮ konfiguraci a následně zapíše novou. Pokud po restartu nová konfigurace způsobí nedostupnost stroje, může se stroj vrátit k předchozímu funkčnímu nastavení. •

Administrátor nyní pracuje převážně s informačním systémem a přímo na směrovač se přihlásí jen občas, když potřebuje konfiguraci interaktivně ladit. Typicky může jít např. o výběr nejlepšího kanálu přístupového bodu a podobně. Konfiguraci však na stroji neukládá a po odladění ji zapíše opět do informačního systému.

Pozorný čtenář jistě vidí, že popsaný proces je v podstatě jednosměrný - směrem od administrátora, přes informační systém a repositář na koncový stroj. Ve většině případů to není na škodu - pro instalaci, výměnu i rekonfiguraci směrovačů to plně dostačuje. Díky w w w rozhraní může i technická podpora nahlédnout na změny a aktuální nastavení. Mohou se však objevit synchronizační problémy, kdy na koncovém stroji a v databázi jsou rozdílné verze konfigurace. Proces aktualizace může zadrhnout např. kvůli dočasné nedostupnosti koncového stroje. V tomto případě by měl informační systém po zpřístupnění stroje administrátora informovat o nutnosti spuštění aktualizace, případně ji sám provést. Složitější synchronizační problém nastává v momentě, kdy se rozhodneme přejít ke starší konfiguraci. V ten moment je totiž třeba opravit podle verze z repositáře i aktuální kon­ figuraci v databázi. Za tímto účelem si proto systém musí ke konfiguracím do repositáře přikládat i příslušný stav relevantní části databáze, aby ji mohl následně snadněji obnovit. 6.2.2 Systém Netopeer pro pokročilou správu konfigurací Poněkud propracovanější přístup ke správě nastavení aktivních prvků pojal tým z projektu Liberouter. V současné době vyvíjí systém Netopeer 11 pro komplexní správu a distribuci konfigurací. Jejich řešení je podobné, je např. použitý stejný správce verzí. Přitom je však vše založeno na jazyku XML a odvozených transformacích. Jedním z cílů je mimojiné i ne­ závislost na platformě směrovače, takže bude možné z jednoho XML popisu konfigurace nastavovat jak linuxové, tak např. i Cisco směrovače. 6.3

Správa a účtování uživatelů

Uživatelé univerzální služby, poskytované navrhovanou bezdrátovou sítí, jsou zpravidla připojováni na některý z bezdrátových přístupových bodů. Jak již bylo řečeno, vzhledem k praktické nedostupnosti zařízení dle nově prosazovaného standardu 802.16 se zde zamě­ říme na implementaci pomocí stávajících přístupových bodů standardu 802.11h, jenž jsou pro univerzální službu též dostačující. Občasnou výjimku mohou tvořit uživatelé z domácností, na jejichž domě je umístěna infrastruktura přístupové sítě a kteří jsou tudíž k prvnímu směrovací připojeni zpravidla strukturovanou kabeláží. V těchto případech je však zajištění jejich identifikace, účtování i bezpečnosti jednodušší, proto zde tento případ dále nerozebírám. 11. Netopeer, < h t t p : //www. l i b e r o u t e r . o r g / n e t o p e e r / i n d e x . p h p >

48

6.3. SPRÁVA A ÚČTOVÁNÍ UŽIVATELŮ 6.3.1 Identifikace uživatele v síti a řízení přístupu Koncový uživatel sítě se připojuje pomocí klientského adaptéru. Nejčastější a z mnoha ohledů nejpraktičtější je použití externí verze, kdy není třeba zasahovat do počítače uživatele a jeho propojení s adaptérem se provede pomocí strukturované kabeláže. Z technického hlediska potom pod identifikací uživatele rozumíme identifikaci adaptéru, jemuž podle potřeby po­ mocí řízení přístupu povolíme či zakážeme připojení na přístupový bod. Základním a často používanou metodou je identifikace a řízení přístupu podle MAC adresy adaptéru. Tato MAC je od výroby jedinečná a na přístupovém bodě lze snadno za­ vést seznamy povolených či zakázaných adres. Na našich linuxových přístupových bodech zavádíme pravidla následovně: INTERFACE=wlanO iwpriv $INTERFACE iwpriv $INTERFACE iwpriv $INTERFACE iwpriv $INTERFACE iwpriv $INTERFACE # . . .

maccmd maccmd maccmd addmac addmac

4 # odhlásí stávající klienty 3 # smaže stávající seznam adres 1 # přístup jen adresám v seznamu "0 0:eO:98:be:ca:b7" "00:eO:98:be:cd:cb"

Nejde však o metodu zcela bezpečnou, neboť MAC adresy lze bohužel snadno falšovat. Po­ tenciální záškodník se může do sítě snadno dostat následujícím postupem. Pomocí PCMCIA adaptéru v notebooku a programu Kismet nejprve chvíli poslouchá, aby zjistil jméno sítě a používané MAC a IP adresy. Vytipuje si málo využívanou IP adresu a svojí kartě nastaví vybranou odposlechnutou MAC a IP adresu a přístupový bod ho pustí. Řešením uvedeného problému je nasazení komplexních bezpečnostních opatření, za­ ložených na standardech IETF 802.1X a 802.11i, někdy též zvaném WPA2. Více informací o uvedených opatřeních, včetně možné implementace pomocí opensource nástrojů čtenář nalezne v části věnující se bezpečnosti. 6.3.2 Paketový filtr a účtování přenesených dat Každý směrovač v síti operátora by pochopitelně měl mít nastaven paketový filtr z bez­ pečnostních důvodů. Ukázkovou implementaci najde čtenář na přiloženém CD. Z hlediska správy a účtování uživatelů můžeme navíc rozeznat dvě místa v sítí, kde je vhodné apliko­ vat speciální pravidla. Z pohledu uživatele je to první směrovač v síti (někdy přímo přístu­ pový bod) a poslední směrovač v operátorově síti, čili internetová brána. Na prvním směrovací je dobré zavést pravidla, hlídající kombinace MAC a IP adres. Jedná se o pojistku pro případ, kdy by si uživatel změnil IP adresu. Zároveň můžeme využít počitadel u jednotlivých pravidel pro využití ve FUP či účtování. Pravidla zapsaná pomocí iptables vypadají následovně: i p t a b l e s -A FORWARD -s $IP -m mac --mac-source $MAC -j RETURN Na bráně je pravidel pro paketový filtr pochopitelně více, navíc jsou především pravidla pro překlad adres: univerzální pravidlo pro běžné uživatele a speciální pravidla pro uživa49

6.3. SPRÁVA A ÚČTOVÁNÍ UŽIVATELŮ tele s veřejnou adresou, přiřazenou jedna ku jedné. Dále jsou zde opět pravidla pro kontrolu přístupu uživatelů. Protože na bráně agregujeme již velké množství uživatel, řádově tisíce, je vhodné pro dlouhý seznam uživatelských pravidel zavést stromovou hierarchii. Struktura musí opět vycházet z principu agregace IP adres, agregovat můžeme např. podle adresní oblasti následovně: # vytvoření i p t a b l e s -N i p t a b l e s -A i p t a b l e s -N i p t a b l e s -A

v l a s t n í c h řetězců pravidel pro první oblast-1-in FORWARD - i $INETIF -d 1 0 . 1 . 0 . 0 / 1 6 - j oblast-1-out FORWARD - o $INETIF - s 1 0 . 1 . 0 . 0 / 1 6 - j

oblast oblast-1-in oblast-1-out

# p r a v i d l o pro povoleného u ž i v a t e l e z~první o b l a s t i i p t a b l e s -A v e s n i c e - 2 - o u t - s 1 0 . 1 . 1 . 8 / 2 9 - j ACCEPT i p t a b l e s -A v e s n i c e - 2 - i n -d 1 0 . 1 . 1 . 8 / 2 9 - j ACCEPT

#

Uživatel č.

...

Implementaci kompletního nastavení paketového filtru brány najde čtenář na CD. Za zmínku ještě stojí výkon linuxového paketového filtru, jenž bývá označován jako Netfilter12. Na výkonnostní problémy můžeme narazit už při zavádění velkého množství pravi­ del. Např. zavedení 6000 pravidel na stroji Celeron 1,1 GHz trvá celých šest minut. Zavádění nových pravidel lze proto optimalizovat pomocí nástrojů iptables-save a iptables-restore. Podstatnější je však výkon v propustnosti při určitém počtu pravidel. Netfilter funguje na principu lineárního průchodu každého paketu řetězcem pravidel. Při dlouhém řetězci a velkém množství paketů může teoreticky docházet problémům s propustností. Z praxe mám vyzkoušenou konfiguraci brány pro cca tisíc uživatelů (celkem 6000 pravidel) a rych­ lost 20 Mb. Na stroji Pentium 4 s frekvencí 3 GHz je tato konfigurace funkční bez jakýchkoliv výkonnostních problémů. Přesto pokud by operátor narazil na výkonnostní problémy, může zkusit nasadit alternativní paketový filtr pro Linux, HiPAC 13 . Disponuje stejným rozhraním pro příkazový řádek jako Netfilter, osobně jsem jej však zatím nezkoušel. Z hlediska účtování dat přenesených uživateli můžeme tedy mít k dispozici dva zdroje informací o přenesených datech - z brány a z prvního směrovače. Přitom tyto údaje se ne­ musí shodovat v případě, že operátor nebude blokovat provoz mezi uživateli v rámci své sítě. Operátor má tedy k dispozici informaci o celkovém provozu uživatele, o jeho internetovém a tudíž i lokálním provozu a může je využít např. pro aplikaci FUP Uvedené řešení pomocí počitadel paketového filtru je v podstatě nízkoúrovňové a neo­ bejde se bez pomocných nástrojů pro další zpracování. Je poměrně snadné si na míru vy­ tvořit své vlastní nástroje, využít však můžeme i některé z hotových opensource programů. V praxi využívám spíše z historických důvodů balíček IPAC-NG14, jenž mi sumarizuje data do podoby jednoduchých hodinových statistik, vhodných pro další zpracování. Program je použitelný i pro větší nasazení, ale trpí několika neduhy. Zejména si pravidla pro účto­ vání zavádí sám podle sebe a tím prakticky zdvojuje celkový počet pravidel, navíc bez dříve 12. Netfilter, «Chttp: //www. net f i l t e r . o r g / > 13. HiPAC, «chttp: //www. hipac . org/> 14. IPAC-NG, «Chttp: / / i p a c - n g . sourcef orge . n e t / >

50

6.3. SPRÁVA A ÚČTOVÁNÍ UŽIVATELŮ uvedených výkonnostních optimalizací. Pro úplnost ještě zbývá zmínit podporu IPv6 pro Netfilter. Existuje příkaz ipótables, jenž v současnosti podporuje základní typy cílů. Některé volby však zatím nejsou implemento­ vány a hotov zatím bohužel není ani connection tracking. 6.3.3 Nastavení uživatelských rychlostí a implementace FUP Specifikace univerzální služby uvádí rychlostní parametry, jenž má přípojka splňovat. K im­ plementaci proto nutně musíme použít nástroj, jenž dokáže regulovat šířku přenosového pásma jednotlivých uživatelů. Na Linuxu máme k dispozici celou řadu plánovačů paketů a související nástroj do příkazové řádky tc (název odvozen od traffic control - kontrola pro­ vozu). S výhodou využijeme moderního hierarchického plánovače HTB, jenž nám umožní definovat již na prvním směrovací, resp. přístupovém bodu, sadu uživatelských linek se vzájemným propůjčováním kapacity. Dále využijeme SFQ pro plánování paketů v rámci jednotlivých linek. Rozdělování dostupné šířky pásma spočívá v plánování odchozích paketů vždy pro jed­ notlivá rozhraní zvlášť 15 . Přitom je třeba především znát celkové množství kapacity, kterou můžeme rozdělit. Pokud bychom zadefinovali více než máme k dispozici, plánovací algo­ ritmy by nefungovaly korektně. V těchto případech záleží chování systému především na ovladačích bezdrátových modulů (může docházet např. ke zpožděním či zahazování pa­ ketů) a je lepší se jim vyhnout. Skript pro nastavení konfigurace začíná zavedením disciplíny (qdisc) HTB a vytvoření jejich tříd (class) pro jednotlivé uživatele. U každé třídy definujeme zajištěnou rychlost (rate) a horní mez (ceil), přičemž třídy si mohou půjčovat kapacitu od nevyužívaných tříd až po danou mez. Třídy tvoří strom v (našem případě jen o dvou patrech), k listům dále přiřa­ zujeme další disciplíny. Použijeme přitom disciplínu SFQ, jenž plánuje pakety rovnoměrně podle spojení. Uživatel stahující např. větší soubor proto nebude mít problém s dalšími spo­ jeními. Nakonec nastavíme filtry, jenž určí příslušnost paketů do tříd. Pojďme si nyní možné způsoby dělení pásma předvést na menších příkladech. Mějme přístupový bod s rozhraním athO pro připojování klientů. Ti jsou zatím připojeni jen tři, každý z nich proto dostane své 2 M b / s bez agregace na přístupovém bodě. Skript vypadá následovně: IF="athO";

# zavedení HTB, jeho kořenové třídy a implicitní minimální třídy, # jenž by při správně nastavených filtrech měla zůstat nevyužitá tc qdisc del dev $IF root tc qdisc add dev $IF root handle 1: htb default 1000 tc class add dev $IF parent 1: classid 1:1 htb rate 6208kbit ceil 6208kbit tc class add dev $IF parent 1:1 classid 1:1000 htb rate 64kbit ceil 64kbit 15. Existuje i neoficiální rošíření jádra IMQ pro plánování na více rozhraních, jenž zároveň umožňuje plánovat i pakety příchozí. Z principu však odesílání paketů až při jejich přijetí přímo neovlivníme, nástroj je určen spíše pro některé speciální případy. Více viz < h t t p : //www. l i n u x i m q . n e t > .

51

6.4. KVALITA SLUŽEB

# uživatel č. 1 - class, qdisc, filter tc class add dev $IF parent 1:1 classid 1:1001 htb \ rate 2048kbit ceil 2048kbit burst 32k tc qdisc add dev $IF parent 1:1001 handle 1001: sfq perturb 10 tc filter add dev $IF protocol ip parent 1:0 prio 1 \ u32 match ip dst $IP_1 flowid 1:1001 # obdobne pro další dva uživatele...

Nyní uvažme případ, kdy se nám přístupový bod více zaplnil uživateli, kterých je nyní připojených již dvanáct. Musíme zde tedy zavést agregaci, neboť jsme narazili na maxi­ mální reálnou přenosovou rychlost přístupového bodu. V našem skriptu změníme následu­ jící řádky týkající se HTB tříd: # zvětšíme kapacitu hlavní (kořenové) třídy

t c c l a s s add dev $IF p a r e n t 1: c l a s s i d 1:1 htb r a t e 16448kbit c e i l

16448kbit

# upravíme u ž i v a t e l s k é t ř í d y pro a g r e g a c i t c c l a s s add dev $IF p a r e n t 1:1 c l a s s i d 1:1001 htb \ r a t e 1024kbit c e i l 2048kbit b u r s t 32k Více podrobností o možnostech správy přenosového pásma najde čtenář např. na stránkách projektu HTB 16 . V předchozím jsme nahlédli, jakým způsobem můžeme modelovat agregaci na přístupo­ vém bodu. Nahlédli jsme též, jakým způsobem lze získávat účtovací data z pravidel paketového filtru. Další metody pro tvorbu FUP jsou založené právě na informacích o množství přenesených dat, na jejichž základě lze např. upravovat parametry rate a ceil, případně na­ stavovat prioritu provozu uživatelům služby. Zbývá nastínit možné podoby pravidel FUP, implementovaných typicky informačním systémem. Nejobvyklejším pravidlem bývá stanovení absolutního maxima přenesených dat pro účtovací období, nejčastěji jeden měsíc. Po jeho překročení dochází ke zpomalení až do konce období. Jinou strategií je algoritmus klouzajícího okna, jenž pro posouzení nadměr­ ného využívání služby používá zpravidla menší období několika posledních hodin či dnů. Přitom nastolené sankce trvají jen tak dlouho, dokud se při některé další pravidelné kon­ trole dostatečně neprojeví snížené využití služby. Konkrétní pravidlo může znít např. ná­ sledovně: pokud za poslední tři hodiny přesáhla průměrná rychlost uživatele 1 M b / s (pře­ neseno více než 1350MB), sniž rate na 256 Kb/s a ceil na 512 Kb/s na dobu jedné hodiny. Pravidlo můžeme kontrolovat v intervalech jedné hodiny, případně i častěji. 6.4

Kvalita služeb

Dodržet všechny kvalitativní parametry univerzální služby nemusí být úplně triviální. Zá­ sadní vliv má typ použitých bezdrátových modulů, svou roli hraje též celá řada mnohdy 16. HTB,http://luxik.cdi.cz/~devik/qos/htb/ < h t t p : / / l u x i k . cdi . c z / ~ d e v i k / q o s / h t b / >

52

6.4. KVALITA SLUŽEB velmi proměnlivých faktorů, stavem frekvenčního pásma počínaje a stavem směrovačů konče. Vliv faktorů a možná opatření pro kvalitní chod připojení můžeme rozdělit do následujících vrstev: •

Fyzická vrstva je v našem případě realizována mikrovlnami v bezlicenčním pásmu. Vyžaduje zpravidla přímou viditelnost včetně fresnelovy zóny a je více či méně ná­ chylná na vlivy počasí a zarušení (podrobnosti lze nalézt např. v [< 1]). Spoj s poddi­ menzovaným rádiovým ziskem na příjmu či s blízkým rušením je nucen k retransmisím, čímž zvyšuje latenci i jitter, může docházet ke ztrátám a snížení propustnosti. Podobně problémovému spoji již nepomohou sebelepší algoritmy vyšších vrstev a je nutné jej opravit, přeladit, nahradit či přesunout.

•

Na linkové vrstvě je z hlediska kvality služeb hlavním bodem zájmu protokol pří­ stupu ke sdílenému médiu (MAC), jenž má značný vliv především na latenci a jitter. Standard 802.11 předpokládá dvě různé funkce pro koordinaci přístupu: Distributed Coordination Function (DCF) a Point Coordination Function (PCF). Zatímco funkce DCF pracující na principu soupeření o médium, jenž není schopna garantovat stabilní kvalitativní parametry, je povinná, funkce PCF nikoliv. Právě centrálně koordinovaná funkce PCF měla umožnit přenosy v reálném čase, avšak v praxi nakonec vůbec ne­ byla implementovaná. Situací se snaží řešit standard 802.11e pomocí třetí koordinační funkce, Enhanced DCF (EDCF). Jedná se v podstatě o diferenciaci různých typů pro­ vozu rozdílnými časy v algoritmu DCF. Praktická implementace plného standardu pokud je mi známo zatím pro Linux bohužel neexistuje. Nicméně ovladače Madwifi disponují alespoň podporou Wireless Multimedia Extension (WME), jenž funguje na podobném principu.

•

Síťová vrstva nemá s kvalitou služeb souvislost jen zdánlivě. Ve skutečnosti může mít dynamické směrování jak příznivý, tak i nepříznivý vliv. Poprvé když dokáže v síti s okruhy a záložními linkami automaticky vybrat cestu lepších kvalit. Podruhé když nastane kolísání tras a dochází k rychlému přepínání, spojeným s krátkými vý­ padky a zvýšenou zátěží některých linek.

•

Transportní vrstva nám umožňuje plánovat odesílání paketů na rozhraních směro­ vačů a tím prioritizovat provoz citlivý na zpoždění a jitter. Nastavení parametrů front a konfigurací plánovačů paketů se na Linuxu ovládá komplexním nástrojem tc, jak již bylo prezentováno v předchozí kapitole.

Praktickým problémem ovlivňujícím kvalitu služby může být též vnitřní provoz v rámci jednoho přístupového bodu, jenž v obvyklé konfiguraci neopustí kód ovladače modulu a vyhne se tak plánování transportní vrstvy. Řešení existuje celá řada, ať už s podporou či bez podpory ovladačů samotných. Standardně lze například zavést na přístupovém bodě pro každého uživatele samostatnou podsíť a bránu. Méně tradičně lze pomocí ovladače vypnout vnitřní provoz a pomocí upravených arp odpovědí ze strany přístupového bodu na dotazy klientů 'stahovat' provoz skrze přístupový bod. 53

6.5. BEZPEČNOST 6.5

Bezpečnost

Mluvíme-li o bezpečnosti přístupové sítě operátora univerzální služby, je třeba nejprve iden­ tifikovat možná rizika pro samotného operátora, ale i koncového uživatele služby. Jejich společným zájmem je přitom především dodržení definovaných parametrů služby, ale též vyloučení možných omylů a podvodů včetně neoprávněných zásahů třetích stran. Teprve na základě analýzy rizik a jejich možných následků lze kompetentně rozhodnout, která rizika má bezpečnostní politika postihovat a kolik finančních i jiných zdrojů je třeba na bezpečnost vyčlenit. V našem případě můžeme rozlišit zejména následující specifická rizika pro operátora: •

Fyzické poškození infrastruktury nejčastěji vlivem přírodních živlů při špatně pro­ vedené instalaci, případně zásahem nepovolané osoby. Je třeba si uvědomit geogra­ fický rozsah sítě, při němž každá porucha vede k výjezdům, delším výpadkům a vyš­ ším nákladům na opravy. Riziko lze dostatečně eliminovat kvalitními instalacemi, ale zcela ho vyloučit nelze.

•

Hardwarové selhání bohužel zcela vyloučit nelze, faktory ovlivňující riziko selhání jsou uvedeny v předchozí kapitole. Riziko však není pro většinu instalací natolik vy­ soké, aby bylo třeba hardwarové redundance. Výjimky např. v podobě náročných výškových instalací potvrzují pravidlo. Samozřejmostí je dobře zásobený sklad ná­ hradních dílů a dostatek techniků.

•

Softwarové problémy mohou být pro bezdrátovou přístupovou síť fatální zejména v případě neodladěných ovladačů bezdrátových modulů. Důsledkem může být ztráta kvality a dostupnosti služby, při masovém nasazení hrozí i přetížení servisních pra­ covníků operátora. Doporučuji proto ovladače a systémovou platformu jako celek před nasazením důkladně testovat, a to i v reálném nasazení.

•

Lidská chyba při administraci může způsobit výpadek služby a následný výjezd do terénu. Hrozí však zejména při manuálním řešení procesů, jenž by měly být zpraco­ vány automatizovaně přes informační systém.

•

DoS útok na bezdrátovou infrastrukturu může nabývat různých forem, např. formu přímého radiového rušení či podvržených 802.11 management rámců. Útok je v prin­ cipu velmi snadno realizovatelný, obrana je mnohdy prakticky nemožná. Standardi­ zační skupina IEEE se při návrhu bezpečnosti 802.11i nakonec přiklonila k zachování kompatibility na úkor řešení problému. Z hlediska operátora je proto třeba s rizikem počítat alespoň při formulování smluvních podmínek.

•

Radiové rušení od jiných sítí je rizikem velmi podstatným, které bude postupem času stále pravděpodobnější i v nově otevřeném pásmu 5,4 GHz. Riziko lze mírnit využíváním monitoringu éteru a pečlivým plánováním frekvencí a anténních sestav. 54

6.5. BEZPEČNOST Z hlediska operátora univerzální služby je třeba v hustěji obydlených oblastech po­ čítat s nasazením alternativních přístupových technologií, neboť rušení typicky zna­ mená ztrátu kvality i výkonu. •

Neoprávněné připojení do sítě může znamenat zvýšené náklady bez korespondu­ jících příjmů, tedy finanční ztráty. Zároveň s sebou nese dodatečná rizika, např. na­ padení hackerem. Je třeba již od začátku řešit systémově na úrovni autentizace a ří­ zení přístupu, neboť dodatečné zavádění nových standardů může být příliš bolestivé nejen pro operátora, ale i uživatele.

Z hlediska uživatele navíc připadají v úvahu následující rizika: •

Neoprávněné užívání síťových zdrojů třetí stranou je pro uživatele v zásadě nepři­ jatelné, zvláště pokud by se nadlimitní spotřeba projevila i na finančním vyúčtování služby či razantnější aplikaci FUP. Nastává typicky při špatně zvládnutém řízení pří­ stupu a je dalším závažným důvodem pro pečlivou implementaci bezpečnostních protokolů.

•

Odposlech přenášených dat a hovorů třetí stranou je rizikem, jenž mohou vnímat uživatelé různě citlivě a jenž nelze podcenit. Pro skutečnou důvěrnost dat je samo­ zřejmě vždy nutné použít patřičné protokoly a nástroje na uživatelské úrovni. Nicméně minimálně např. razantní nástup nešifrovaného VoIP znamená, že uživatelské hovory mohou být z nešifrované bezdrátové sítě snadno odposlechnuty ve velkém geogra­ fickém prostoru.

•

Zneužití uživatelovy identity třetí stranou může hrát významnou roli při páchání trestné činnosti. Uživatel potřebuje mít rozumnou míru jistoty, že na něj neprávem nedolehnou důsledky činnosti jiné osoby, předstírající svou identitu v síti. Typickým identifikátorem uživatele v síti je jeho IP adresa a operátor by proto mě eliminovat možnost jejího zneužití neoprávněnou osobou.

Na základě uvedeného rozboru rizik a podle samotné specifikace univerzální služby proto pod zajištěním bezpečnosti služby rozumím bezchybnou implementaci autentizace a silného šifrování dle standardů 802.1X a 802.11i. Detailní popis používaných bezpečnostních mechanismů je mimo rozsah této práce, čtenář najde dostatek informací např. v [ ]. Ve struč­ nosti zde uvádím alespoň krátké shrnutí principů pro přehled, potřebný pro kvalifikované nasazení systému. Standard 802.11i definuje pojem robustní bezpečné sítě, RSN (Robust Security Network). Pod tímto pojmem můžeme rozumět síť se sadou bezpečnostních opatření, umožňujících šifrování přenášených dat a omezení přístupu na prokazatelně autentizované a autorizo­ vané uživatele. Standard zejména zahrnuje bezpečnostní protokol AES-CCMP (Advanced Encryption Standard - Counter Mode CBC MAC Protocol) a z důvodů zpětné hardwa­ rové kompatibility se stávajícími zařízeními též TKIP (Temporary Key Integrity Protocol). Oba protokoly poskytují mechanismy pro ustanovení sady potřebných symetrických klíčů 55

6.5. BEZPEČNOST z hlavního tajemství, sdíleného mezi klientským zařízením, a autentizačním serverem (mas­ ter secret). Přitom je dbáno na jedinečnost klíčů pro každé připojení k přístupovému bodu, což společně eliminuje potenciální bezpečnostní problémy, jak je známe z původní verze zabezpečení sítí 802.11 (Wired Equivalent Privacy, WEP). Standard 802.1X definuje pro kontrolu přístupu trojstranný protokol Radius mezi při­ pojovaným klientem, vrátným (Network Access Server, NAS) a jeho nadřízeným s právem autentizace a autorizace (Authentification Server, AS). Oproti klasickému použití pro dialup je však situace u bezdrátových sítí složitější, neboť je zde vysoká pravděpodobnost únosu spojení třetí stranou. Obranou je obalení zpráv protokolu Radius do bezpečnostních proto­ kolů vyšších vrstev, např. TLS (Transport Layer Security) či PEAP (Protected EAP). Ačkoliv RSN umožňuje i zabezpečení bez využití protokolu Radius, v praxi je pro ope­ rátora nasazení autentizačního serveru nutností. S velkou pravděpodobností již stejně Ra­ dius operátor používá, obvykle pro autentizaci klientů připojených přes dialup či xDSL. Navíc se již objevily metody útoku na RSN bez autentizačního serveru, tj. se sdílenými klíči (Pre-Shared Keys, PSK), resp. na algoritmy pro generování plnohodnotných klíčů z kratších, uživatelem snadno zapamatovatelných frází. V současné době již můžeme implementaci postavit kompletně na opensource řešení, jak ilustruje přiložený diagram. Všimněme si zde certifikační autority v podání OpenCA 17 , jenž je nutná k ověřování certifikátů pro použití v TLS. Zprovoznění kompletního zázemí pro certifikaci není triviální, pro jednodušší konfigurace a zejména testování lze vytvořit ome­ zené certifikáty i pomocí balíku open-ssl. Podrobnosti k nastavení jednotlivých komponent jsou k dispozici v příslušné programové dokumentaci. Uvedená kombinace programů je podle internetových zdrojů funkční, i když ovladače Madwifi ještě nejsou zcela odladěné. Zda a případně s jakými obtížemi spolupracuje FreeRADIUS18 a hostapd 19 s komerčně dostupnými klientskými adaptéry je však třeba vždy vyzkoušet. Naopak podrobné testy kompatibility programu wpa_supplicant 20 s různými implementacemi Radius serverů jsou k dispozici na webu projektu. Z praktického hlediska stojí též za pozornost klientský adaptér, jenž musí disponovat jak implementací žadatele o přístup (tzv. supplicant), tak podporu na úrovni ovladače bez­ drátového modulu. Zde můžeme narazit na potenciální problémy s kompatibilitou, které nemusí být bez spolupráce s výrobcem řešitelné. Podle mých zkušeností bohužel moc dostupných adaptérů požadovaných vlastností na trhu není, zvláště pro poměrně nové pásmo 5,4 GHz. V případě potřeby proto operátor může využít připravenou systémovou platformu i v roli klientského adaptéru, případně zkusit zadat požadované úpravy svému dodavateli k implementaci. Vzhledem k faktu, že většina adaptérů používá linuxový firmware, s trochou ochoty ze strany dodavatele a vý­ robce by neměl být problém vlastnosti doplnit. Za běžný bezpečnostní nešvar klientských adaptérů lze označit používání nešifrovaného 17. 18. 19. 20.

OpenCA, FreeRADIUS, hostapd, wpa_supplicant,

56

6.5. BEZPEČNOST Koncoví uživatelé přístupové sítě

Přístupová sít operátora

Autentizacni

server

FreeRADIUS

Certifikační

Přístupový bod, NAS

hosta pd

802.11a madwifi

Klientský

adaptér

802.11a madwifi

autorita Klientský počítač

OpenCA

IP Telefon

Obrázek 6.2: Entity autentizačního procesu v bezdrátové síti http spojení pro konfiguraci. Při vzdálené změně konfigurace může snadno dojít k prozra­ zení hesla a tím i hlavního sdíleného tajemství, což se dá připodobnit k rozdávání klíčů od domu neznámým kolemjdoucím.

57

Kapitola 7

Závěr Cílem mé práce bylo navrhnout technické řešení nově definované univerzální služby pří­ stupu k Internetu. V prvé řadě jsem se proto pokusil stručně vysvětlit význam a přínos nové služby pro jednotlivce i společnost jako celek. Prezentoval jsem též podle mého dů­ ležitý aspekt, totiž že připojení k Internetu můžeme s nástupem VoIP chápat jako plynulé rozšíření stávající univerzální služby. Za nezbytné jsem též považoval před dalším výkladem jasně specifikovat výkonnostní i kvalitativní parametry služby. Druhou a třetí kapitolu jsem tedy věnoval definici služby a krátkému rozboru dostupných technologií. Prokázal jsem, že služba může být technologicky nezávislá a realizovatelná i pomocí pevných bezdrátových sítí. Při tak komplexním zadání jsem dále musel na poměrně omezeném prostoru poskytnout alespoň rámcový přehled všech podstatných technických aspektů. Vždy jsem se přitom sna­ žil poukazovat na dostupnost a možnosti otevřených řešení, postavených na uznávaných standardech a svobodném programovém vybavení. Většinu prezentovaných komponent jsem si přitom ověřil v praxi na pozici síťového správce rychle rostoucího bezdrátového operátora. Věřím proto, že stanovený úkol se mi podařilo splnit a že laskavý čtenář našel v mém textu i na přiloženém médiu užitečné a praktické informace.

58

Literatura [1] Internet pro všechny:, Bezdrátové sítě v České republice, 2005. 1.3.1 [2] Český statistický úřad:, Statistiky o informační společnosti, 2004. 1.2 [3] Kolektiv autorů:, Linux Dokumentační projekt, 2003, 80-7226-761-2. C [4] Galstad, E.:, Prezentace programu Nagios na konferenci FOSDEM 2005, 2005. 6.1.1 [5] Ministerstvo pro místní rozvoj:, Programový dodatek SROP, 2004. 1.3.1 [6] Peterka, J.:, Liberalizace telekomunikací

v ČR, 2005. 1.3

[7] Armitage, G.: , Quality of Service in IP Networks: Foundations for a Multi-Service Internet, MTP, 2000,1-57870-189-9. 4.3 [8] Garg, P. a jiní:, Using IEEE 802.11e MAC for QoS over Wireless, 2003. 3.6 [9] Edney, J. a Arbaugh, A.: , Real 802.11 Security: Wi-Fi Protected Access and 802.11i, Addison-Wesley Professional, 2003, 0-321-13620-9. 3.6, 6.5 [10] Huitema, C : , RFC 1715 - The H Ratio for Address Assignment Efficiency, 1994. 4.2.3 [11] Moy, J.:, RFC2328 - OSPF Version 2,1998. 4.3.2 [12] Hinden, R. a O'Dell, M. a Deering, S.:, RFC 2374 - An IPv6 Aggregatable Global Unicast Address Format, 1998. 4.2.3 [13] Deering, S. a Hinden, R.:, RFC 2460 - Internet Protocol, Version 6 (IPv6) Specification, 1998. 4.2.3 [14] Farinacci, D. a jiní:, RFC 2784 - Generic Routing Encapsulation (GRE), 2000. 4.2.2 [15] Thaler, D. a Hopps, C : , RFC 2991 - Multipath Issues in Unicast and Multicast Hop Selection, 2000. 5

Next-

[16] Hopps, C : , RFC 2992 - Analysis of an Equal-Cost Multi-Path Algorithm, 2000. 5 [17] Moy, J.: , RFC 3177 - IAB/IESG Recommendations Sites, 2001. 4.2.3

on IPv6 Address Allocations to

[18] Hinden, R. a Deering, S.: , RFC 3513 - Internet Protocol Version 6 (IPv6) Architecture, 2003. 4.2.3

Addressing

[19] Vláda CR:, Státní informační politika - Cesta k informační společnosti, 1999. 1 [20] Ipsos-INRA:, Telecoms services indicators 2004, 2004. 1.2 [21] Stallings, W.: , Wireless Communications Prentice Hall, 2002, 0-13-040864-6. 6.4

and Networks,

Upper Saddle River: NJ:

59

Index AES-CCMP (Advanced Encryption Standard - Counter Mode CBC MAC Protocol), 55 AP (Access Point), 15 AS (Authorization Server), 56 CVS, 46 DCF (Distributed Coordination Function), 53 DFS (Dynamic Frequency Selection), 16 DOCSIS (Data Over Cable Service Interface Specification), 13 EDCF (Enhanced DCF), 53 Ethernet, 18 FreeRADIUS, 56 FSO (Free Space Optics), 15 FTTH (Fiber To The Home), 13 FWA (Fixed Wireless Access), 15 HiPAC, 50 HTB (Hierarchical Token Bucket), 51 IPAC-NG, 50 JFFS2 0ournalling Flash File System 2), 33 MAC (Media Access Control), 15,53 Madwifi, 56 MIMO (Multiple In Multiple Out), 15

PSTN (Public Switched Telephone Service), 6 Radius, 56 rfmon, 45 RIR (Regional Internet Registry), 25 RRD (Round Robin Database), 44 RSN (Robust Security Network), 55 RTT (Round Trip Time), 9 SDH (Synchronous Digital Hierarchy), 17 SFQ (Stochastic Fairness Queuing), 51 SNR (Signal to Noise Ratio), 42 STP (Spanning Tree Protocol), 17 Subversion, 46,47 tc, 51 TKIP (Temporary Key Integrity Protocol), 55 TLS (Transport Layer Security), 56 TPC (Transmit Power Control), 16 Trac, 47 WEP (Wired Equivalent Privacy), 56 WME (Wireless Multimedia Extensions, 53 wpa_supplicant, 56 xDSL, 12, 56 ADSL (Asymetrie DSL), 13 SHDSL (Symetrie High-Bitrate DSL), 13 VDSL (Very High-Bitrate DSL), 13

NAS (Network Access Server), 56 NAT (Network Address Translation), 20 Netfilter, 50 NOC (Network Operation Centre), 42 OpenCA, 56 OpenSSL, 56 PCF (Point Coordination Function), 53 PEAP (Protected EAP), 56 PON (Passive Optical Network), 13 PSK (Pre-Shared Keys), 56 60

Dodatek A

Obsah přiloženého CD Technické řešení univerzální služby připojení k~Internetu

(C) Copyright 2005 David Kutálek, OBSAH CD FILES Přehled souborů obsažených na CD. diploma Zdrojové kódy diplomové práce. linux Systémová platforma směrovačů a přístupových bodů. linux/baliky Seznam balíčků a vlastní či upravené balíčky. linux/skripty Pomocné programy potřebné pro instalaci a údržbu systému. linux/konfigurace Základní konfigurace systému, konfigurace jádra. linux/obrazy Systém ve formě obrazů k~instalaci na CF kartu. linux/src Důležité volně šiřitelné zdrojové kódy a záplaty. management/dbnet.txt Základní datový model pro management sítě.

61

Dodatek B

Přehled programového vybavení systémové platformy Kompletní seznam balíčků: adduser apt apt-utils aptitude at base-config base-files basepasswd bash bsdmainutils bsdutils console-common console-data console-tools coreutils cpio cron debconf debconf-il8n debianutils dhcp-client diff dpkg dselect e2fslibs e2fsprogs ed exim4 exim4-base exim4-config exim4-daemon-l fdutils findutils gcc-3.3-base gettextbase grep groff-base gzip hostname ifupdown info initscripts ipchains iptables iputils-ping klogd libacll libattrl libblkidl libc6 libcapl libcomerr2 libconsole libdbl-compat libdb3 libdb4.2 libgccl libgcryptll libgdbm3 libgnutlsll libgpg-errorO liblocale-gett liblockfilel liblzol libncurses5 libnewtO.51 libopencdk8 libpam-modules libpam-runtime libpamOg libpcap0.7 libpcre3 libpoptO libsigc++-1.2- libss2 libsslO.9.7 libstdc++5 libtasnl-2 libtext-charwi libtexticonv- libtext-wrapil libtextwrapl libuuidl libwrapO login logrotate mailx makedev man-db manpages mawk modutils mount nano ncurses-base ncurses-bin net-tools netbase netkitinetd nvi passwd pciutils perl-base ppp pppconfig pppoe pppoeconf procps psmisc sed slangla-utf8 sysklogd sysv-rc sysvinit tar tasksel tcpd telnet util-linux wget whiptail zliblg

62

Dodatek C

Přehled důležitých konfiguračních souborů Uvádím především soubory, jenž je nutné či vhodné upravit pro každý další stroj. Více po­ drobností o uvedených konfiguracích a dalších možnostech konfigurace systému Linux na­ jde čtenář v příslušných manuálových stránkách, případně v [3].

C.l

Základní konfigurace systému

/etc/apt/apt.conf Nastavení apt-pinning, pokud si vedeme vlastní repozitář. /etc/apt/sources. list Seznam zdrojů balíčků, tj. originálního zdroje a vlastního repozitáře. /etc/default/ntp-servers Seznam časových serverů pro synchronizaci času. Síťová synchronizace je nutností, neboť např. desky WRAP nemají baterii pro úschovu aktuálního data. /etc/fstab Definice diskových oddílů a příslušných souborových systémů. Liší se pouze podle volby mezi JFFS2 a Ext2 pro kořenový svazek. /etc/hostname Definuje jméno stroje, které by mělo být v~rámci sítě unikátní /etc/modules Seznam jaderných modulů k~zavedení při startu. Nutno uvést zejména ovladače síťových karet a bezdrátových modulů. /etc/ssmtp/ssmtp.conf Konfigurace jednoduchého balíčku pro odesílání pošty. /etc/syslog.conf Vzhledem k~povaze CF karet je vhodné logovat na centrální server.

63

C.2. NASTAVENÍ SÍTĚ C.2

Nastavení sítě

/etc/inetd.conf V~konfiguraci internetového superserveru doporučuji vše nepotřebné, tudíž prakticky vše vypnout, a to především z~bezpečnostních důvodů. /etc/network/interfaces Hlavní konfigurační soubor pro nastavování rozhraní směrovače, včetně jejich bezdrátových parametrů a spouštění akcí souvisejících se změnou stavu rozhraní. Tzn. odtud spouštíme např. skripty a příkazy pro nastavování kvality služeb či obsluhu paketového filtru. Pokud nepoužíváme dynamické směrování, zapisujeme zde i všechna směrovací pravidla. /etc/network/options Několik základních nastavení sítě, zejména aktivace přeposílání paketů a vypnutí rp filtru, pokud máme v~síti okruhy. /etc/quagga/* Nastavení démona pro dynamické směrování. /etc/resolv.conf Nastavení primárního a sekundárního dns serveru. /etc/snmp/* Chceme-li monitorovat stroje protokolem snmp, provedeme konfiguraci zde.

C.3

Konzole přes sériový port

/etc/inittab V~konfiguraci procesu init přiřadíme sériové konzoli terminál: TO:23:respawn:/sbin/getty -L ttySO 38400 vtl02 /boot/grub/menu.1st Zde předáme jádru mimojiné i parametr pro použití sériové konzole: console=ttyS0,3 84 0 0 /etc/securetty Povolíme přístup na sériovou konzoli superuživateli root.

C.4

Nastavení rozšiřujících balíčků

/etc/thttpd/thttpd.conf Pár voleb pro minimalistický web server. /etc/kismet/kismet_drone.conf Konfigurace agenta pro monitoring éteru.

64

Dodatek D

Konfigurace linuxového jádra #

# Konfigurace linuxového jádra řady 2.4, určená pro linuxové směrovače # a přístupové body založené na architektuře x86. # Optimalizováno pro jednotky WRAP. # # Výběr architektury, podpora modulů, ... CONFIG_X86=y C0NFIG_UID16=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y CONFIG_M586=y CONFIG_X86_WP_WORKS_OK=y CONFIG_X86_INVLPG=y CONFIG_X86_CMPXCHG=y CONFIG_X86_XADD=y CONFIG_X86_BSWAP=y CONFIG_X86_POPAD_OK=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y C0NFIG_X86_L1_CACHE_SHIFT=5 CONFIG_X86_USE_STRING_4 8 6=y CONFIG_X86_ALIGNMENT_16=y CONFIG_X86_PPRO_FENCE=y CONFIG_X86_MCE=y CONFIG_X86_MSR=m CONFIG_X86_CPUID=m CONFIG_NOHIGHMEM=y CONFIG_MTRR=y CONFIG_X86_UP_APIC=y CONFIG_X86_UP_IOAPIC=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # Obecná nastavení - podpora sítě, sběrnic, ...

65

D. KONFIGURACE LINUXOVEHO JÁDRA CONFIG_NET=y CONFIG_PCI=y CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_NAMES=y CONFIG_SYSVIPC=y CONFIG_BSD_PROCESS_ACCT=y CONFIG_SYSCTL=y CONFIG_KCORE_ELF=y CONFIG_BINFMT_ELF=y CONFIG_BINFMT_MISC=m # Podpora Memory Technology Devices CONFIG_MTD=y CONFIG_MTD_DEBUG=y C0NFIG_MTD_DEBUG_VERB0SE=3 CONFIG_MTD_CHAR=y CONFIG_MTD_BLOCK=y CONFIG_MTD_BLOCK_RO=m CONFIG_MTD_BLKMTD=y CONFIG_FTL=m CONFIG_NFTL=m # Bloková zařízení CONFIG_BLK_DEV_LOOP=y CONFIG_BLK_DEV_RAM=m CONFIG_BLK_DEV_RAM_SIZE=4096 # Síťové volby - tcp/ip, směrování, přemostění, paketový filter, CONFIG_PACKET=y CONFIG_NETLINK_DEV=m CONFIG_NETFILTER=y CONFIG_FILTER=y CONFIG_UNIX=y CONFIG_INET=y CONFIG_IP_MULTICAST=y CONFIG_IP_ADVANCED_ROUTER=y CONFIG_IP_MULTIPLE_TABLES=y CONFIG_IP_ROUTE_FWMARK=y CONFIG_IP_ROUTE_NAT=y CONFIG_IP_ROUTE_MULTIPATH=y CONFIG_IP_ROUTE_TOS=y CONFIG_IP_ROUTE_VERBOSE=y CONFIG NET IPIP=m

66

D. KONFIGURACE LINUXOVÉHO JÁDRA CONFIG_NET_IPGRE=m CONFIG_NET_IPGRE_BROADCAST=y CONFIG_IP_MROUTE=y CONFIG_IP_PIMSM_Vl=y C0NFIG_IP_PIMSM_V2=y CONFIG_INET_ECN=y CONFIG_SYN_COOKIES=y C0NFIG_IPV6=m CONFIG_BRIDGE=m #

IP: Netfilter - paketový filter

CONFIG__IP__NF__CONNTRACK=m CONFIG__IP__NF_ FTP=m CONFIG__IP__NF__AMANDA=m CONFIG__IP__NF_ TFTP=m CONFIG__IP__NF__IRC=m CONFIG__IP__NF__QUEUE=m CONFIG__IP__NF__IPTABLES=m CONFIG__IP__NF__MATCH_LIMIT=m CONFIG__IP__NF__MATCH_MAC=m CONFIG__IP__NF__MATCH_PKTTYPE=m CONFIG__IP__NF__MATCH_MARK=m CONFIG__IP__NF__MATCH_MULTIPORT=m CONFIG__IP__NF__MATCH_TOS=m CONFIG__IP__NF__MATCH_RECENT=m CONFIG__IP__NF__MATCH_ECN=m CONFIG__IP__NF__MATCH_DSCP=m CONFIG__IP__NF__MATCH_AH_ESP=m CONFIG__IP__NF__MATCH_LENGTH=m CONFIG__IP__NF__MATCH_TTL=m CONFIG__IP__NF__MATCH_TCPMSS=m CONFIG__IP__NF__MATCH_HELPER=m CONFIG__IP__NF__MATCH_STATE=m CONFIG__IP__NF__MATCH_CONNTRACK=m CONFIG__IP__NF__MATCH_UNCLEAN=m CONFIG__IP__NF__MATCH_OWNER=m CONFIG__IP__NF__FILTER=m CONFIG__IP__NF__TARGET_REJECT=m CONFIG__IP__NF__TARGET_MIRROR=m CONFIG__IP__NF_ NAT=m CONFIG__IP__NF__NAT_NEEDED=y CONFIG__IP__NF__TARGET_MASQUERADE=m CONFIG__IP__NF__TARGET_REDIRECT=m CONFIG__IP__NF__NAT_AMANDA=m CONFIG__IP__NF__NAT_LOCAL=y CONFIG__IP__NF__NAT_SNMP_BASIC=m CONFIG IP NF NAT IRC=m

67

D. KONFIGURACE LINUXOVEHO JÁDRA CONFIG_IP_NF_NAT_FTP=m CONFIG_IP_NF_NAT_TFTP=m CONFIG_IP_NF_MANGLE=m CONFIG_IP_NF_TARGET_TOS=m CONFIG_IP_NF_TARGET_ECN=m CONFIG_IP_NF_TARGET_DSCP=m CONFIG_IP_NF_TARGET_MARK=m CONFIG_IP_NF_TARGET_LOG=m CONFIG_IP_NF_TARGET_ULOG=m CONFIG_IP_NF_TARGET_TCPMSS=m CONFIG_IP_NF_ARPTABLES=m CONFIG_IP_NF_ARPFILTER=m CONFIG_IP_NF_ARP_MANGLE=m # # QoS - kvalita služeb, prioritní fronty # CONFIG_NET_SCHED=y CONFIG_NET_SCH_CBQ=m CONFIG_NET_SCH_HTB=m CONFIG_NET_SCH_CSZ=m CONFIG_NET_SCH_HFSC=m CONFIG_NET_SCH_PRIO=m CONFIG_NET_SCH_WRR=m CONFIG_NET_SCH_RED=m CONFIG_NET_SCH_SFQ=m CONFIG_NET_SCH_ESFQ=m CONFIG_NET_SCH_TEQL=m CONFIG_NET_SCH_TBF=m CONFIG_NET_SCH_GRED=m CONFIG_NET_SCH_NETEM=m CONFIG_NET_SCH_DSMARK=m CONFIG_NET_SCH_INGRESS=m CONFIG_NET_QOS=y CONFIG_NET_ESTIMATOR=y CONFIG_NET_CLS=y CONFIG_NET_CLS_TCINDEX=m C0NFIG_NET_CLS_R0UTE4=m CONFIG_NET_CLS_ROUTE=y CONFIG_NET_CLS_FW=m CONFIG_NET_CLS_U3 2=m CONFIG_NET_CLS_RSVP=m C0NFIG_NET_CLS_RSVP6=m CONFIG_NET_CLS_POLICE=y # IDE rozhraní a řadiče pro CF CONFIG_IDE=y

68

D. KONFIGURACE LINUXOVÉHO JÁDRA CONFIG_BLK_DEV_IDE=y CONFIG_BLK_DEV_IDEDISK=y CONFIG_IDEDISK_MULTI_MODE=y CONFIG_BLK_DEV_IDEPCI=y CONFIG_BLK_DEV_GENERIC=y CONFIG_BLK_DEV_IDEDMA_PCI=y CONFIG_IDEDMA_PCI_AUTO=y CONFIG_BLK_DEV_IDEDMA=y CONFIG_BLK_DEV_CS553 0=y CONFIG_IDEDMA_AUTO=y # Pro použití i u~PC může být třeba dalších ovladačů IDE # Podpora síťových zařízení CONFIG_NETDEVICES=y CONFIG_DUMMY=m CONFIG_BONDING=m CONFIG_EQUALIZER=m CONFIG_IMQ=m CONFIG_TUN=m CONFIG_SHAPER=m # Ethernet CONFIG_NET_ETHERNET=y CONFIG_NET_PCI=y CONFIG_NATSEMI=y # Pro použití i u~PC je třeba dalších ovladačů ethernetu # WLAN - bezdrátové adaptéry CONFIG_NET_WIRELESS=y CONFIG_NET_RADIO=y CONFIG_HERMES=m CONFIG_HOSTAP=m CONFIG_PCI_HERMES=m CONFIG_HOSTAP_PCI=m # Ovladač Madwifi pro karty Atheros kompilujeme zvlášť # Znaková zařízení - konzole jen přes sériový port CONFIG_SERIAL=y CONFIG_SERIAL_CONSOLE=y CONFIG_UNIX98_PTYS=y CONFIG_UNIX98_PTY_COUNT=2 56 # Watchdog karty pro hlídání záseků, hodiny reálného času

69

D. KONFIGURACE LINUXOVEHO JÁDRA CONFIG_WATCHDOG=y CONFIG_WD1100=y CONFIG_RTC=y # Souborové systémy a rozdělení disku C0NFIG_JFFS2_FS=y CONFIG_TMPFS=y CONFIG_RAMFS=y CONFIG_PROC_FS=y CONFIG_DEVPTS_FS=y CONFIG_ROMFS_FS=y C0NFIG_EXT2_FS=y CONFIG_PARTITION_ADVANCED=y CONFIG_MSDOS_PARTITION=y # Cryptografické volby CONFIG__CRYPTO==y CONFIG__CRYPTO__HMAC=y CONFIG__CRYPTO__NULL=m CONFIG__CRYPTO_ MD4=m CONFIG__CRYPTO_ MD5=m CONFIG__CRYPTO__SHAl=m CONFIG__CRYPTO__SHA256=m CONFIG__CRYPTO__SHA512=m CONFIG__CRYPTO__DES=m CONFIG__CRYPTO__BLOWFISH=m CONFIG__CRYPTO__TWOFISH=m CONFIG__CRYPTO__SERPENT=m CONFIG__CRYPTO__AES=m CONFIG__CRYPTO__CAST5=m CONFIG__CRYPTO__CAST6=m CONFIG__CRYPTO_ TEA=m CONFIG__CRYPTO__ARC4=m CONFIG__CRYPTO__DEFLATE=m CONFIG CRYPTO MICHAEL MIC=m # Pomocné rutiny a ostatní CONFIG_CRC32=y CONFIG_ZLIB_INFLATE=m CONFIG_ZLIB_DEFLATE=m CONFIG LOG BUF SHIFT=0

70

Dodatek E

Základní datový model pro management sítě -- net_router DROP TABLE IF EXISTS net_router; CREATE TABLE net_router ( id int(lO) NOT NULL auto_increment, name varchar(32) NOT NULL UNIQUE default 'default_name', tech_id int(lO) NOT NULL default '0', pop_id int(lO) NOT NULL default '0', comment varchar(255) default '', PRIMARY KEY (id), FOREIGN KEY (tech_id) REFERENCES net_tech_router(id), FOREIGN KEY (pop_id) REFERENCES net_pop(cislo) ) ; -- net_interface DROP TABLE IF EXISTS net_interface; CREATE TABLE net_interface ( id int(lO) NOT NULL auto_increment, name varchar(32) NOT NULL UNIQUE default 'default_name', router_id int(5) NOT NULL '0', tech_id int(lO) NOT NULL '0', metric int (5) default '0', area_id int(5) NOT NULL default '65535', mrtg ENUM('yes','no') NOT NULL default 'no', comment varchar(255) default '', PRIMARY KEY (id), FOREIGN KEY (tech_id) REFERENCES net_tech_interface(id), FOREIGN KEY (router_id) REFERENCES net_router(id) FOREIGN KEY (area_id) REFERENCES net_area(id) ) ; -- net_link DROP TABLE IF EXIST net_link; CREATE TABLE net_link ( interfacel_id NOT NULL default '0', interface2_id NOT NULL default '0',

71

E. ZÁKLADNÍ DATOVÝ MODEL PRO M A N A G E M E N T SÍTĚ PRIMARY KEY (interfacel_id, interface2_id), FOREIGN KEY (interfacel_id) REFERENCES net_tech_interface(id), FOREIGN KEY (interface2_id) REFERENCES net_tech_interface(id) ) ; -- net_wireless DROP TABLE IF EXISTS net_wireless; CREATE TABLE net_wireless ( id int(lO) NOT NULL auto_increment, interface_id NOT NULL default '0', essid varchar(64) NOT NULL default '.slovackofree.net', channel int (5) NOT NULL default ' ľ , mode ENUM('master','managed','monitor','ad-hoc') NOT NULL default 'master', polarization ENUM('vertical','horizontal','circular') default 'vertical', antenna_gain int(5) default '0', attenuation int(5) default '0', comment varchar(255) default '', PRIMARY KEY (id), FOREIGN KEY (interface_id) REFERENCES net_interface(id) ) ; -- net_address DROP TABLE IF EXISTS net_address; CREATE TABLE net_address ( id int(10) NOT NULL auto_increment, interface_id NOT NULL default '0', type ENUM('gateway','router', 'client') NOT NULL default 'client', ip int (10) NOT NULL default '0', ip6 varchar(128) default '::', mac varchar(17) default '00:00:00:00:00:00', prefix int (2) NOT NULL default '32', prefix6 int (3) NOT NULL default '128', name varchar(128) default '', comment varchar(255) default '', PRIMARY KEY (id), FOREIGN KEY (interface_id) REFERENCES net_interface(id) ) ; -- net_area DROP TABLE IF EXISTS net_area; CREATE TABLE net_area ( number int (10) NOT NULL default '65535', network int (10) NOT NULL default '0', prefix int (2) NOT NULL default '16', PRIMARY KEY (number,subnet)

72

E. ZÁKLADNÍ DATOVÝ MODEL PRO MANAGEMENT SÍTĚ

) ; -- net_tech_router DROP TABLE IF EXISTS net_tech_router; CREATE TABLE net_tech_router ( id int(10) NOT NULL auto_increment, name varchar(32) NOT NULL UNIQUE default 'default_name', comment varchar(255) default '', PRIMARY KEY (id) ) ; -- net_tech_interface DROP TABLE IF EXISTS net_tech_interface; CREATE TABLE net_tech_interface ( id int(lO) NOT NULL auto_increment, name varchar(32) NOT NULL UNIQUE default 'default_name', metric int(5) NOT NULL default '0', is_wireless ENUM('yes','no') NOT NULL default 'no', comment varchar(255) default '', PRIMARY KEY (id) ) ; - - net_pop DROP TABLE IF EXISTS net_pop; CREATE TABLE net_pop ( id int(lO) NOT NULL auto_increment, name varchar(32) NOT NULL UNIQUE default 'default_name', postal_address varchar(255) default 'unknown', contact varchar(255) default 'unknown', url varchar(255) default '', PRIMARY KEY (id) ) ; -- net_connection DROP TABLE IF EXISTS net_connection; CREATE TABLE net_connection ( id int(lO) NOT NULL auto_increment, name varchar(32) NOT NULL UNIQUE default 'default_name', interface_id NOT NULL default '0', address_id NOT NULL default '0', smokeping ENUM('yes','no') NOT NULL default 'no', data_down int (15) default '0', data_up int (15) default '0', key varchar (255) NOT NULL default '',

73

E. ZÁKLADNÍ DATOVÝ MODEL PRO MANAGEMENT SÍTĚ

PRIMARY KEY (id), FOREIGN KEY (interface_id) REFERENCES net_interface(id), FOREIGN KEY (address_id) REFERENCES net_address(id) ) ;

74

Seznam obrázků 1 Úvod 1.1 Přístup domácností k Internetu v ČR a zemích EU (Zdroj: CSU) 2 Specifikace univerzální služby 2.1 Požadavky aplikací na přenosovou rychlost

3

7

4 Architektura sítě 4.1 Funkční celky při návrhu architektury sítě 18 4.2 Příklad přístupové sítě podoby stromu 19 4.3 Možné implementace veřejných IPv4 adres v síti 23 4.4 Hierarchie IPv6 adres v porovnání s hierarchií IPv4 adres

26

5 Systémová platforma směrovačů a přístupových bodů 5.1 Celkové vytížení procesoru 39 5.2 Počet klientů asociovaných na modulu XI-625 39 5.3 Datový tok na modulu XI-625 40 5.4 Datový tok na modulu CM9 40 6 Management sítě 6.1 Blokové schéma systému správy konfigurací 47 6.2 Entity autentizačního procesu v bezdrátové síti 57

75

Seznam tabulek 4 Architektura sítě 4.1 Struktura lokální IPv4 adresy 21 4.2 Hranice efektivního využití prostoru adresními schématy při HD=0,8 4.3 Tabulka metrik pro OSPF 29

26

5 Systémová platforma směrovačů a přístupových bodů 5.1 Tabulka oblastí a jejich použití na CF kartě 35

76