Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky

Z´ apadoˇ cesk´ a univerzita v Plzni Fakulta aplikovan´ ych vˇ ed Katedra informatiky

´ PRACE ´ DIPLOMOVA Syst´ em pro ˇ r´ızen´ı a monitorov´ an´ı s´ıt’ov´ eho provozu

Vypracoval: Bc. Radek Vozák Vedouc´ı práce: Ing. Jiˇr´ı Ledvina, CSc.

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem tuto diplomovou práci zpracoval samostatnˇe a ˇze jsem uvedl vˇsechny zdroje a literaturu, ze kter´ ych jsem ˇcerpal.

V Plzni dne 26.6.2014

Podpis: ......................................

Abstrakt Tato práce se zab´ yvá realizac´ı systému pro ˇr´ızen´ı a monitorován´ı s´ıt’ového provozu na prvc´ıch Mikrotik RouterBoard s operaˇcn´ım systémem RouterOS. Pro testy byly vybrány routery RB1100, RB433AH, RB600, RB2011L, RB450 a testovac´ı server Intel s operaˇcn´ım systémem Ubuntu 13.10. Prvn´ım u ´kolem je seznámen´ı s hardwarem RouterBoard a softwarem RouterOS a moˇznostmi pouˇzit´ı v oblasti monitorován´ı a ˇr´ızen´ı s´ıt’ového provozu. Následuj´ıc´ım krokem je vytvoˇren´ı vlastn´ıho systému, kter´ y zahrnuje: monitorován´ı prvk˚ uv s´ıti, ˇr´ızen´ıch a priorizaci datov´ ych tok˚ u a webové rozhran´ı pro snadné ovládán´ı. Posledn´ım krokem je otestován´ı systému na vybran´ ych routerech a ovˇeˇren´ı funkˇcnosti navrˇzeného systému.

Abstract This work deals with realization of a system for controlling and monitoring of network traffic on routers Mikrotik RouterBoard with the operating system RouterOS. The routers RB1100, RB433AH, RB600, RB2011L, RB450 and the testing server Intel with the operating system Ubuntu 13.10 were chosen for the testing of the system. The first task is familirization with the hardware RouterBoard and the software RouterOS and the possibility of usage in the area of monitoring and controlling network traffic. The next step is the actual realization of the system which includes: monitoring of the routers in the network, controlling and priorization of data-flows and a web interface for easy controlling of the system. The last step is system-testing on the chosen routers and verification of functionality of the designed system.

Podˇ ekov´ an´ı Na tomto m´ıstˇe bych rád podˇekoval Ing. Jiˇr´ımu Ledvinovi, CSc., vedouc´ımu práce, za cenné rady, pˇripom´ınky a metodické veden´ı. Dále své rodinˇe za vytvoˇren´ı vhodn´ ych podm´ınek pro psan´ı diplomové práce a sv´ ym pˇra´tel˚ um za psychickou podporu.

Obsah ´ 1 Uvod

1

2 Mikrotik RouterBoard 2.1 Architektury . . . . . . . . . . . . . . 2.1.1 MIPSBE . . . . . . . . . . . . 2.1.2 PPC - PowerPC . . . . . . . . 2.1.3 MIPSLE . . . . . . . . . . . . 2.1.4 TILE . . . . . . . . . . . . . . 2.2 Hardwarová vybavenost a znaˇcen´ı . . 2.3 Komunikaˇcn´ı interface . . . . . . . . 2.3.1 Metalické porty . . . . . . . . 2.3.2 Optické moduly . . . . . . . . 2.3.3 Bezdrátové miniPCI adaptéry 2.3.4 Ostatn´ı . . . . . . . . . . . . 3 Teorie s´ıt’ov´ e komunikace 3.1 Architektura ISO/OSI . . . . . 3.1.1 Fyzická vrstva . . . . . . 3.1.2 Linková vrstva . . . . . 3.1.3 S´ıt’ová vrstva . . . . . . 3.1.4 Transportn´ı vrstva . . . 3.1.5 Relaˇcn´ı vrstva . . . . . . 3.1.6 Prezentaˇcn´ı vrstva . . . 3.1.7 Aplikaˇcn´ı vrstva . . . . . 3.2 Architektura TCP/IP . . . . . . 3.2.1 Vrstva s´ıt’ového rozhran´ı 3.2.2 S´ıt’ová vrstva . . . . . . 3.2.3 Transportn´ı vrstva . . . 3.2.4 Aplikaˇcn´ı vrstva . . . . . 3.3 Zapouzdˇren´ı dat . . . . . . . . . 3.4 Navázán´ı s´ıt’ového spojen´ı . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

2 2 2 3 3 3 3 4 4 6 7 8

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

. . . . . . . . . . . . . . .

9 9 9 10 11 12 12 13 13 14 14 15 16 16 17 17

4 RouterOS 4.1 Základn´ı informace . . . . . . . . . 4.1.1 Funkce operaˇcn´ıho systému 4.1.2 Licence . . . . . . . . . . . . 4.2 Moˇznosti konfigurace . . . . . . . . 4.2.1 Inicializace RouterOS . . . . 4.2.2 Pˇr´ıkazová ˇra´dka . . . . . . . 4.2.3 Winbox . . . . . . . . . . . 4.2.4 Webové rozhran´ı . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

19 19 19 19 20 20 20 21 21

. . . . . . . . . . . . . . .

4.3

S´ıt’ová funkcionalita RouterOS . . . . . . . . . . 4.3.1 Základn´ı nastaven´ı pro komunikaci . . . 4.3.2 Smˇerován´ı mezi routery . . . . . . . . . Monitorován´ı zaˇr´ızen´ı . . . . . . . . . . . . . . . 4.4.1 ICMP a PING . . . . . . . . . . . . . . 4.4.2 SNMP . . . . . . . . . . . . . . . . . . . 4.4.3 Mikrotik API . . . . . . . . . . . . . . . 4.4.4 Grafován´ı dat . . . . . . . . . . . . . . . ˇ ızen´ı datov´ R´ ych tok˚ u . . . . . . . . . . . . . . . 4.5.1 QoS (Kvalita sluˇzeb) . . . . . . . . . . . 4.5.2 Klasifikace paket˚ u pomoc´ı TOS a DSCP 4.5.3 Typy front systému RouterOS . . . . . . 4.5.4 Znaˇckován´ı paket˚ u (mangle) . . . . . . . 4.5.5 Queue Simple a Queue Tree . . . . . . .

. . . . . . . . . . . . . .

22 22 27 30 31 32 34 35 38 38 39 40 42 43

. . . . . . . . . . . .

45 45 46 46 47 49 50 51 51 52 53 53 54

6 Testy syst´ emu v re´ aln´ em provozu ’ 6.1 Monitorován´ı s´ıt ov´ ych prvk˚ u. . . . . . . . . . . . . . . . . . . . . . . . . . ˇ ızen´ı datov´ 6.2 R´ ych tok˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54 54 56

7 Z´ avˇ er

59

Literatura

60

Pˇ r´ılohy ERA model . . . . . . . . . . . . Uˇzivatelsk´ y manuál . . . . . . . . Pˇridán´ı zaˇr´ızen´ı do dohledu Zobrazen´ı graf˚ u . . . . . . . Pˇridán´ı sluˇzby QoS . . . . .

61 61 62 62 63 64

4.4

4.5

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

5 Implementace vlastn´ıho syst´ emu 5.1 Poˇzadavky na systém . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Serverová ˇcást systému . . . . . . . . . . . . . . . . . . . . . . . . . 5.2.1 Databázov´ y model . . . . . . . . . . . . . . . . . . . . . . . 5.2.2 Skript pro monitorován´ı s´ıtˇe . . . . . . . . . . . . . . . . . . 5.2.3 Skript pro ˇr´ızen´ı datového toku . . . . . . . . . . . . . . . . 5.2.4 CRON . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 S´ıt’ová ˇca´st systému . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 Páteˇrn´ı smˇerovaˇce . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 Klientské routery a GW . . . . . . . . . . . . . . . . . . . . 5.4 Uˇzivatelská ˇca´st systému . . . . . . . . . . . . . . . . . . . . . . . . 5.4.1 Pˇridán´ı/odebrán´ı nového routeru pro dohled . . . . . . . . . 5.4.2 Pˇridán´ı/odebrán´ı nové sluˇzby a nastaven´ı prioritn´ıho modelu

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . .

. . . . .

Pˇridán´ı uˇzivatelské sluˇzby . . . . . . . . . . . . . . . . . . . . . . . . . . . Zobrazen´ı konfiguraˇcn´ıch soubor˚ u . . . . . . . . . . . . . . . . . . . . . . . Fotografie z testován´ı . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65 66 67

Pˇ rehled zkratek Zkratka ARP ASBR ATM BGP CCR CPU DHCP DNS FDDI FTP HDLC HT HTTP IANA ICMP IEEE IGMP IMAP IP IPSEC ISP LSA MAC NAT OSPF PCQ PoE POP3 RAM RB RED RFC RIP RPC RSVP SFP SFQ SSID SSL TCP UDP UPS USB

Cel´ e slovo Address Resolution Protocol Autonomous System Boundary Routers Asynchronous Transfer Mode Border Gateway Protocol Cloud Core Router Central Processing Unit Dynamic Host Configuration Protocol Domain Name System Fiber Distributed Data Interface File Transfer Protocol High-Level Data Link Control Hyper-Threading Hypertext Transfer Protocol Internet Assigned Numbers Authority Internet Control Message Protocol Institute of Electrical and Electronics Engineers Internet Group Management Protocol Internet Message Access Protocol Internet Protocol IP security Internet Service Provider Link-state Advertisement Media Access Control Network Address Translation Open Shortest Path First Per Connection Queue Power over Ethernet Post Office Protocol Version 3 Random Access Memory Router Board Random Early Detection Request for Comments Routing Information Protocol Remote Procedure Call Resource Reservation Protocol Small Form-factor Pluggable Transceiver Stochastic Fairness Queuing Service Set Identifier Secure Sockets Layer Transmission Control Protocol User Datagram Protocol Uninterruptible Power Supply Universal Serial Bus

´ 1 UVOD

1

´ Uvod

Internet, WiFi, router, megabit“ a mnoho dalˇs´ıch pojm˚ u z oblasti informaˇcn´ıch technologi´ı ” proniká kaˇzd´ ym dnem ˇc´ım dál t´ım v´ıc do podvˇedom´ı bˇeˇzn´ ych uˇzivatel˚ u, aniˇz by si to sami uvˇedomovali nebo o to mˇeli zájem. Kdo by si dnes umˇel pˇredstavit svˇet bez Facebooku, novinek na Seznamu, poˇc´ıtaˇcov´ ych online her a dalˇs´ıch vymoˇzenost´ı modern´ı doby. Tyto pojmy se stávaj´ı denn´ıch chlebem kaˇzdého z nás a jedin´ y rozd´ıl mezi jednotliv´ ymi uˇzivateli je ten, ˇze pro kaˇzdého jedince jsou tyto sluˇzby jinak d˚ uleˇzité. Od d´ıtˇete, chystaj´ıc´ıho si plynule zahrát online hru se sv´ ymi kamarády, pˇres pracuj´ıc´ı stˇredn´ı generaci touˇz´ıc´ı po stabiln´ım a rychlém pˇr´ıstupu na web aˇz po naˇse prarodiˇce, kteˇr´ı si pouze chtˇej´ı jednoduˇse popov´ıdat se sv´ ymi pˇr´ıbuzn´ ymi po Skypu. A právˇe v této chv´ıli nastupuje na scénu monitorován´ı a ˇr´ızen´ı s´ıt’ového provozu, d´ıky nˇemuˇz je moˇzné kaˇzdému uˇzivateli s´ıtˇe upˇrednostnit právˇe tu sluˇzbu, která ho nejv´ıce zaj´ımá. Téma diplomové práce jsem si vybral proto, abych se pokusil zdokonalit ˇr´ızen´ı a stabilitu datov´ ych tok˚ u v s´ıti obˇcanského sdruˇzen´ı PlzenecNET, o.s., kterou buduji jiˇz od sv´ ych ˇsestnácti let. Prvn´ım bodem této práce bude popis aktuálnˇe pouˇz´ıvan´ ych prvk˚ u firmy Mikrotik RouterBoard, na nichˇz je tato s´ıt’ od zaˇcátku svého vzniku budována. V souˇcasnosti obsahuje nˇekolik stovek zaˇr´ızen´ı tohoto typu. Popsány budou desky, komunikaˇcn´ı rozhran´ı a rozˇsiˇruj´ıc´ı moduly. Druh´ ym bodem bude struˇcn´ y popis teorie s´ıt’ové komunikace, kter´ y je potˇrebn´ y k definici základn´ıch pojm˚ u, se kter´ ymi se bude v dalˇs´ım textu pracovat. Budou zde vysvˇetleny principy komunikace mezi dvˇema s´ıt’ov´ ymi prvky v poˇc´ıtaˇcové s´ıti. Následovat bude pˇredstaven´ı operaˇcn´ıho systému RouterOS instalovaném na tomto typu hardwaru. D˚ uraz bude brán na záleˇzitosti, které jsou podstatné pro základn´ı nastaven´ı systému, zprovoznˇen´ı poˇc´ıtaˇcové s´ıtˇe, ˇr´ızen´ı datov´ ych paket˚ u skrz s´ıt’ a dohled aktivn´ıch prvk˚ u. Za stˇeˇzejn´ı a nejnároˇcnˇejˇs´ı ˇcást celé práce povaˇzuji návrh pravidel pro ˇr´ızen´ı s´ıt’ového provozu a priorizaci datov´ ych paket˚ u v s´ıti. Zápis konfigurace do jednotliv´ ych prvk˚ u bude prob´ıhat skrz jednoduché webové rozhran´ı. Souˇcást´ı systému bude i zobrazen´ı monitorovan´ ych dat. V této ˇca´sti bude kladen d˚ uraz na to, aby bylo moˇzné jednotliv´ ym uˇzivatel˚ um nastavit vlastn´ı prioritn´ı model. Posledn´ım d˚ uleˇzit´ ym bodem k dokonˇcen´ı celé práce bude nasazen´ı celého systému v reáln´ ych podm´ınkách a následné zdokumentován´ı jeho chován´ı. Hardware obˇcanského sdruˇzen´ı PlzenecNET, o.s. mi bude pro tyto u ´ˇcely k dispozici.

1

2 MIKROTIK ROUTERBOARD

2

Mikrotik RouterBoard

Mikrotik RouterBoard je v informaˇcn´ıch technologi´ıch oznaˇcen´ı pro malé základn´ı desky, které jsou uˇzivatesky rozˇsiˇritelné o doplˇ nuj´ıc´ı prvky (bezdrátové miniPCI karty, extern´ı antény, pamˇeti, SFP moduly, ...). V´ ysledn´ y prvek lze následnˇe pouˇz´ıt napˇr´ıklad jako bezdrátov´ y pˇr´ıstupov´ y bod, router, optick´ y ˇci metalick´ y switch, bezdrátov´ y klientsk´ y rou’ ter nebo podobné s´ıt ové prvky. V základn´ı konfiguraci obsahuj´ı RouterBoardy procesor, integrovanou operaˇcn´ı pamˇet’ a dle typu desky nˇekolik s´ıt’ov´ ych karet, SFP slot˚ u, USB port˚ u, miniPCI-E slot˚ u atd. Jako základn´ı operaˇcn´ı systém dodávan´ y pro desky Mikrotik RouterBoard je systém RouterOS, kter´ y je zaloˇzen na Linuxu a budu o nˇem mluvit podrobnˇeji v dalˇs´ıch kapitolách. Je vˇsak moˇzno vyuˇz´ıt i jiné Linuxové distribuce a d´ıky tomu zakomponovat desky to témˇeˇr jakékoliv poˇc´ıtaˇcové s´ıtˇe.

2.1

Architektury

Dˇelen´ı RouterBoard˚ u podle architektury je velmi d˚ uleˇzitou souˇcást´ı pˇri instalaci operaˇcn´ıho systému. Pˇrestoˇze se operaˇcn´ı systém dodává pˇredinstalovan´ y, velmi ˇcasto se jedná o neaktuáln´ı verzi a je hned pˇri prvn´ım spuˇstˇen´ı vhodné stáhnout nejnovˇejˇs´ı fimrware s instrukˇcn´ı sadou pro dan´ y typ procesor˚ u. Pouˇzit´ı daného typu procesor˚ u urˇcuje dané skupinˇe velmi ˇcasto zamˇeˇren´ı, pro které je vhodné tyto typy RouterBoard˚ u pouˇz´ıt. Firma Mikrotik v souˇcasné tobˇe rozliˇsuje tyto architektury: 2.1.1

MIPSBE

• CRS série - jedná se o chytré pˇrep´ınaˇce z ˇrady Smart Switch s moˇznost´ı vyhrazen´ı port˚ u pro routován´ı • RB4xx série - desky s vˇetˇs´ım mnoˇzstv´ım ethernetov´ ych port˚ u ˇci miniPCI slot˚ u. Velmi ˇcasto vyuˇz´ıvané poskytovateli internetového pˇripojen´ı • RB7xx série - desky slouˇz´ıc´ı pro bezdrátové spoje a kanceláˇrské routery • RB9xx série - desky slouˇz´ıc´ı pro bezdrátové spoje a kanceláˇrské routery • RB2011 série - stˇrednˇe v´ ykonné v´ıceportové routery pro nasazen´ı v menˇs´ıch firmách • SXT - bezdrátové klientské zaˇr´ızen´ı s duáln´ı anténou na krátkou vzdálenost • OmniTik - bezdrátov´ y pˇr´ıstupov´ y bod s duáln´ı anténou • Groove - bezdrátov´ y klientsk´ y RouterBoard pˇripojiteln´ y pˇr´ımo na anténu pomoc´ı konektoru N • METAL - bezdrátov´ y klientsk´ y RouterBoard pˇripojiteln´ y pˇr´ımo na anténu pomoc´ı konektoru N v kovovém proveden´ı • SEXTANT - bezdrátové klientské zaˇr´ızen´ı s duáln´ı anténou vˇetˇs´ıho zisku 2

2.2 Hardwarová vybavenost a znaˇcen´ı

2.1.2


PPC - PowerPC

• RB3xx série - desky s vˇetˇs´ım mnoˇzstv´ım ethernetov´ ych port˚ u ˇci miniPCI slot˚ u • RB600 série - desky slouˇz´ıc´ı pro v´ ykonné bezdrátové pˇr´ıstupové body ISP • RB800 série - desky slouˇz´ıc´ı pro v´ ykonné bezdrátové pˇr´ıstupové body ISP • RB1xxx série - velmi v´ ykonné v´ıceportové routery, vhodné jako centráln´ı prvky 2.1.3

MIPSLE

• RB1xx série - starˇs´ı RouterBoardy s vˇetˇs´ım mnoˇzstv´ım ethernetov´ ych port˚ u ˇci miniPCI slot˚ u. • RB5xx série - starˇs´ı typ desky slouˇz´ıc´ı pro malé bezdátové pˇr´ıstupové body ISP 2.1.4

TILE

• CCR série - nejnovˇejˇs´ı ˇrada centráln´ıch v´ıceportov´ ych router˚ u s ˇsestnácti nebo tˇricetiˇsesti jádry.

2.2

Hardwarov´ a vybavenost a znaˇ cen´ı

V´ ybˇer vhodného RouterBoardu pro konkrétn´ı aplikaci nen´ı jednoduchou záleˇzitost´ı. Je potˇreba zváˇzit pˇredevˇs´ım parametry, které souvisej´ı s datovou propustnost´ı jednotliv´ ych prvk˚ u. Pro tuto klasifikaci je rozhoduj´ıc´ım parametrem v´ ykon procesoru. Pokud je tˇreba zaˇr´ızen´ı nasadit v aplikac´ıch, které potˇrebuj´ı ukládat data na vestavˇenou pamˇet’, bude rozhoduj´ıc´ım parametrem velikost pamˇeti RAM. Dalˇs´ım kritériem m˚ uˇze b´ yt poˇcet metalick´ ych, optick´ ych ˇci bezdrátov´ ych interfac˚ u. D´ıky opravdu velice rozsáhlé nab´ıdce RouterBoard˚ u zavedla firma Mikrotik znaˇcen´ı, které specifikuje danou hardwarovou v´ ybavu vybrané desky. Toto rozliˇsen´ı pomoc´ı velk´ ych p´ısmen se ovˇsem t´ yká pouze model˚ u, které maj´ı nˇekolik verz´ı. Mikrotik aktuálnˇe rozliˇsuje tyto verze: • A - v´ıce pamˇeti pro ukládán´ı uˇzivatelsk´ ych dat • H - vyˇsˇs´ı v´ ykon procesoru • G - gigabitové ethernet porty • U - pˇr´ıtomnost USB portu pro pˇripojen´ı k UPS nebo extern´ı pamˇeti • R - oznaˇcen´ı pro desku s integrovanou bezdrátovou kartou • N - podpora protokolu 802.11n u bezdrátov´ ych karat • L - verze lite“ - chudˇs´ı v´ ybava oproti klasick´ ym verz´ım, avˇsak pˇri zachován´ı v´ ykonu ” 3

2.3 Komunikaˇcn´ı interface


Pˇr´ıklad oznaˇcen´ı RouterBoardu je: RB433UAHL. Z názvu je moˇzné rovnou odvodit, ˇze se jedná o desku typu RB433 (architektura MIPSBE), která je vybavena portem USB, rozˇs´ıˇrenou vestavˇenou pamˇet´ı RAM, v´ ykonnˇejˇs´ım procesorem, ale zároveˇ n se jedná o verzi ˇ ısla za lite“, která znaˇc´ı absenci portu RS-232 a umˇelé ethernet porty m´ısto kovov´ ych. C´ ” modelovou ˇradou koresponduj´ı s poˇctem ethernetov´ ych port˚ u a miniPCI slot˚ u. Z názvu RB433“ je proto moˇzné vyˇc´ıst, ˇze se jedná o RouterBoard se tˇremi metalick´ ymi porty o ” rychlosti 10/100 Mbps a tˇremi sloty miniPCI pro pˇripojen´ı rádiov´ ych karet. Jak RouterBoard typu RB433UAHL vypadá, je moˇzno vidˇet na Obrázku ˇc´ıslo 1.

Obrázek 1: RB433UAHL

2.3

Komunikaˇ cn´ı interface

Vˇetˇsina dneˇsn´ıch datov´ ych s´ıt´ı nen´ı postavena jen na jednom typu pˇrenosového média. Skoro ve vˇsech pˇr´ıpadech se jedná o kombinaci optické, metalické a bezdrátové s´ıtˇe. Pˇri volbˇe správného RouterBoardu se proto nesm´ı opomenout v´ ybˇer správného typu a mnoˇzstv´ı komunikaˇcn´ıch rozhran´ı (interfac˚ u). Od zaˇr´ızen´ı s jedn´ım metalick´ ym portem a jedn´ım bezdrátov´ ym slotem, které slouˇz´ı ˇcasto jako WiFi klientská jednotka (napˇr: RB911), je moˇzné postupnˇe navyˇsovat poˇcet tˇechto interfac˚ u do poˇzadované konfigurace (RB493AH s 9x ethernetovm´ y portem a 3x miniPCI slotem). Samozˇrejmost´ı je existence ˇcistˇe ethernetov´ ych router˚ u (5 - 13 port˚ u), které jsou v souˇcasnosti poˇra´d ˇcastˇeji doplˇ novány o porty optické (SFP).Velmi rozˇs´ıˇren´ ym RouterBoardem v optick´ ych s´ıt´ıch se stal typ RB2011LS, kter´ y je d´ıky jednomu SFP slotu, deseti metalick´ ym port˚ um a velmi pˇr´ıznivé cenˇe ˇcasto vyuˇz´ıván jako koncové zaˇr´ızen´ı klient˚ u pˇripojen´ ych do této s´ıtˇe. Komunikaˇcn´ı rozhran´ı RouterBoard˚ u se daj´ı rozdˇelit do kategori´ı: 2.3.1

Metalick´ e porty

Jedná o základn´ı komunikaˇcn´ı interface, kter´ y lze naj´ıt na kaˇzdém RouterBoardu. Skrz tento port docház´ı k provotn´ı konfiguraci RouterBoardu administrátorem. Do tˇechto port˚ u je moˇzné pˇripojit vˇsechny kabely vyhovuj´ıc´ı standard˚ um cat.5,6,7 a propojit tak desku 4



s poˇc´ıtaˇcem nebo jin´ ym prvkem poˇc´ıtaˇcové s´ıtˇe. Rozliˇsovat m˚ uˇzeme z hlediska rychlosti, proveden´ı a podporou napájen´ı po ethernetu a to následuj´ıc´ıcm zp˚ usobem: • Rychlost: – 10/100 Mbps porty - podpora Fast Ethernetu definovaného normou IEEE 802.3u – 10/100/1000 Mbps porty - podpora Gigabitového Ethernetu definovaného normou IEEE 802.3ab pro kroucenou dvoulinku • Proveden´ı: – kovové - klasické proveden´ı, moˇznost propojen´ı se st´ınˇen´ ym kabelem – plastové - proveden´ı ve verzi Lite • Napájen´ı: – bez podpory napájen´ı - slouˇz´ı pouze k pˇrenosu dat – s podporou nápájen´ı - tzv. PoE (Power over Ethernet) - slouˇz´ı k napájen´ı prvk˚ u po ethernetovém kabelu. Vyuˇz´ıvá se, pokud je jednotka um´ıstˇena ve venkovn´ım prostˇred´ım daleko od elektrické s´ıtˇe. Odpadá tak nutnost vést druh´ y napájec´ı kabel. PoE je definované normou 802.3af. Jak takovéto porty vypadaj´ı v praxi, je moˇzné vidˇet na Obrázku ˇc´ıslo 2. Na desce typu RB450G je pˇet kovov´ ych metalick´ ych port˚ u s podporou Gigabitového Ethernetu a na portu 1 je viditelné oznaˇcen´ı pro podporu napájen´ı po Ethernetovém kabelu. Pˇri pouˇzit´ı PoE je potˇreba dodrˇzet vstupn´ı napˇet´ı 10-28V. Délka kabelového veden´ı, pˇri kterém bude napájen´ı po Ethernetu fungovat, roste s pouˇzit´ım kvalitnˇejˇs´ı kabeláˇze a s velikost´ı v´ ystupn´ıho napˇet´ı napájec´ıho adaptéru. Pˇri 12V je moˇzné dosáhnout vzdálenosti cca 20m. 24V uˇz dovoluje jednotky napájet na vzdálenost aˇz 50m.

Obrázek 2: B450GPOE

5


2.3.2


Optick´ e moduly

D´ıky klesaj´ıc´ı cenˇe optick´ ych prvk˚ u, vláken a pˇr´ısluˇsenstv´ı jsou RouterBoardy stále ˇcastˇeji vybavovány rozhran´ım pro optickou komunikaci. Pokud chceme kabelovou cestou pˇrekonat vzdálenost vˇetˇs´ı, neˇz jsou ˇra´dovˇe stovky metr˚ u, pˇr´ıpadnˇe se chceme vyhnout interferenc´ım, které jsou patrné na metalickém veden´ı, je pouˇzit´ı optické technologie jedinou cestou. Protoˇze se Mikrotik vydal cestou variabiln´ı desky, nejsou RouterBoardy vybaveny jedn´ım typem optického pˇrevodn´ıku, ale pouze ˇsachtou umoˇznuj´ıc´ı do desky zasunout SFP (small form-factor pluggable) moduly. Uˇzivateli je tak dovoleno vybrat si mezi moduly s r˚ uznou rychlost´ı a technologi´ı pˇrenosu. Moduly, které Mikrotik podporuje, m˚ uˇzeme proto rozdˇelit to následuj´ıc´ıch skupin: • Rychlost: – 10/100 Mbps SFP moduly - v dneˇsn´ı dobˇe uˇz se skoro nepouˇz´ıvaj´ı – 10/100/1000 Mbps SFP moduly - nejrozˇs´ıˇrenˇejˇs´ı – 10Gbit moduly - v souˇcasné dobˇe desky zat´ım nepodporuj´ı, samotn´ y operaˇcn´ı systém RouterOS uˇz ano • Podpora vláken: – Single mode - moduly pracuj´ıc´ı s t´ımto typem vláken umoˇzn ˇuj´ı pˇrenos aˇz na 20km. Nejˇcastˇeji je pouˇzita vlnová délka 1310nm. – Multi mode - moduly pro spojen´ı vzdálenost´ı do cca 550m. Pouˇzit´ı vlnové délky 850nm. • Technologie pˇrenosu: – pˇrenos po dvou vláknech - SFP modul je vybaven dvˇema konektory. Jedno vlákno slouˇz´ı pro pˇr´ıjem a druhé pro vys´ılán´ı. Oba dva smˇery mohou vys´ılat na stejnˇe vlnové délce. – Pˇrenos po jednom vláknu - jedná se o technologii WDM (Wavelength Division Multiplexing - vlnov´ y multiplex). Moduly jsou pˇri tomto typu pˇrenosu na kaˇzdé stranˇe optické trasy rozd´ılné a prodávaj´ı se proto v párech. Pˇri pˇrenosu jsou pouˇzity dvˇe vlnové délky, jedná pro vys´ılán´ı a druhá pro pˇr´ıjem dat. Nejˇcastˇeji se jedná o kombinaci 1310/1550 nm.

6



Vzhledem k velikosti modul˚ u SFP je vˇzdy pouˇzit jeden nebo dva konektory typu LC. Na následuj´ıc´ım Obrázku ˇc´ıslo 3 je vidˇet RouterBoard 2011LS, jeho ˇsachta pro SFP a jeden pár optick´ ych SFP modul˚ u S-3553LC20D.

Obrázek 3: RB2011 s SFP moduly WDM

2.3.3

Bezdr´ atov´ e miniPCI adapt´ ery

ˇ a republika je v souˇcanostni Wi-Fi velmoc´ı Evropy, proto je nejvˇetˇs´ı portfolio MiCesk´ krotiku zamˇeˇreno na bezdrátové prvky. Bez rozˇsiˇritelnosti RouterBoard˚ u o bezdrátové miniPCI adaptéry by urˇcitˇe vˇetˇsina ISP sáhla po ˇreˇsen´ı od konkurenˇcn´ıch v´ yrobc˚ u jako napˇr´ıklad Ubiquti Networks. Svoje uplatnˇen´ı si ale najdou i RouterBoardy s vestavˇenou bezdrátovou ˇca´st´ı. Dˇelen´ı prvk˚ u je v tomto pˇr´ıpadˇe velmi jednoduché: • RouterBoardy s vestavˇenou bezdrátovou kartou bez moˇznosti rozˇs´ıˇren´ı: – Vestavˇená karta s integrovanou anténou - routery pro pouˇzit´ı jako domác´ı/firemn´ı pˇr´ıstupov´ y bod. Pˇr: RB951G-2HnD – Vestavˇená karta s v´ ystupem na extern´ı anténu - desky pouˇzitelné pro páteˇrn´ı spoje. Pˇr: RB911G-5HPnD – Vestavˇená karta s pˇr´ımo pˇripojenou extern´ı anténou - bezdrátové klientské routery. Pˇr: SXT 5HnD • RouterBoardy s moˇznost´ı rozˇs´ıˇren´ı o miniPCI bezdátové karty: – MiniPCI karty pro pásmo 2,4GHz - vys´ılaˇce pro mobiln´ı telefony a notebooky. Pˇr: WNC CM9 – MiniPCI karty pro pásmo 5GHz-a - vys´ılaˇce pro pˇripojen´ı klient˚ u v pásmu 5GHz. Pˇr: Mikrotik R52 – MiniPCI karty pro pásmo 5GHz-n - vys´ılaˇce pro pˇripojen´ı klient˚ u v pásmu 5GHz-n. Pˇr: MikroTik R52Hn – MiniPCI karty pro pásmo 3,5GHz-n - karty pro spoje v licencovaném pásmu ˇ 3,5GHz. Nutné oprávnˇen´ı CTU. Mikrotik tyto karty nevyráb´ı, ale podporuje pˇripojen´ı karet UBNT XR3

7



Jak pˇripojen´ı miniPCI bezdrátové karty vypadá v reálu, je moˇzné si prohlédnout na Obrázku ˇc´ıslo 4. Je zde znázornˇen jiˇz historick´ y typ RouterBoard 112 s osazenou jednou bezdátovou miniPCI kartou typu Mikrotik R52. Karta má pˇripojen´ y pigtail zakonˇcen´ y konektorem R-SMA pro pˇripojen´ı extern´ı antény.

Obrázek 4: RB112 s miniPCI kartou R52

2.3.4

Ostatn´ı

RouterBoardy maj´ı i dalˇs´ı rozhran´ı, pˇres které je moˇzné komunikovat s okol´ım. Dále je zde moˇzné nalézt ˇcidla a v´ ybavu pro akustickou ˇci optickou komunikac´ı s uˇzivatelem. Patˇr´ı mezi nˇe: • USB konektor - slouˇz´ı pro pˇripojen´ı extern´ı pamˇeti, dohledu záloˇzn´ıch zdroj˚ u nebo 3G modem˚ u • RS232 - sériov´ y port slouˇz´ı pro konfiguraci RouterBoard˚ u • Teplotn´ı senzor - sn´ımán´ı teploty • Reproduktor - zvukové zamˇeˇrován´ı spoj˚ u, potvrzen´ı nabˇehnut´ı operaˇcn´ıho systému • Diody - optická kontrola bˇehu zaˇr´ızen´ı. Diody je také moˇzné pouˇz´ıt k zamˇeˇrován´ı spoj˚ u.

8

ˇ ´ KOMUNIKACE 3 TEORIE SÍTOV E

Teorie s´ıt’ov´ e komunikace

3

Neˇz bude moˇzné pˇristoupit k popisu s´ıt’ov´ ych funkc´ı operaˇcn´ıho systému RouterOS, je bezprostˇrednˇe nutné popsat, jak funguj´ı základy s´ıt’ové komunikace mezi zaˇr´ızen´ımi v s´ıti. Aby bylo moˇzné hovoˇrit o s´ıt’ové komunikaci, je potˇreba nejdˇr´ıve nadefinovat pojem s´ıt’ová architektura. S´ıt’ová architektura je struktura, která má na starost ˇr´ızen´ı s´ıt’ové komunikace v systémech a v´ ymˇenu jejich dat. Vznik prvn´ı architektury je u ´zce spjat´ y se vznikem prvn´ıch poˇc´ıtaˇcov´ ych s´ıt´ı. Postupn´ ym v´ yvojem doˇslo k vytvoˇren´ı dvou hlavn´ıch koncepc´ı: Modelu ISO/OSI a TCP/IP. Obˇe tyto architektury se od sebe odliˇsuj´ı následovnˇe: • ISO/OSI - sedmivrstv´ y model. Systém navrˇzen pro spolehlivé a spojované sluˇzby. Zajiˇstˇen´ı spolehlivosti zasahuje aˇz do komunikaˇcn´ı pods´ıtˇe (tj. aˇz do u ´rovnˇe s´ıt’ové vrstvy). Hostitelské poˇc´ıtaˇce maj´ı relativnˇe jednoduchou u ´lohu. Spojované sluˇzby jsou realizovány mechanismem virtuáln´ıch okruh˚ u. • TCP/IP - ˇctyˇrvrstv´ y model. Zajiˇstˇen´ı spolehlivosti je problémem koncov´ ych stanic a je ˇreˇseno aˇz na transportn´ı vrstvˇe. Uˇsetˇrená reˇzie (ˇcas) je pouˇzita pro vlastn´ı pˇrenos. TCP/IP proto nen´ı tak spolehlivá architektura jako ISO/OSI, nicménˇe poskytuje rychlou a jednoduchou komunikaˇcn´ı s´ıt’. Vyuˇz´ıvá nespojovan´ y charakter pˇrenosu tedy jednoduchou datagramovou sluˇzbu. Pro pochopen´ı fungován´ı s´ıt’ové komunikace je potˇreba podrobnˇe popsat funkci jednotliv´ ych vrstev a zavést pojmy komunikaˇcn´ı port, rámec, paket a segment. Následuj´ıc´ı text pˇredpokládá znalost pojm˚ u MAC adresa a IP adresa.

3.1

Architektura ISO/OSI

V roce 1984 byla pˇrijata norma ISO 7498, která definovala pouˇzit´ı referenˇcn´ıho modelu ISO/OSI vypracovaného firmou International Organization for Standardization (ISO). Norma uvád´ı základn´ı principy sedmivrstvé s´ıt’ové architektury. Popisuje jednotlivé vrstvy, kde kaˇzdá ze sedmi vrstev vykonává skupinu jasnˇe definovan´ ych funkc´ı potˇrebn´ ych pro ˇrádnou komunikaci. Pro svoji ˇcinnost vyuˇz´ıvá sluˇzeb sousedn´ı, niˇzˇs´ı vrstvy. Naopak své sluˇzby pak poskytuje vrstvˇe vyˇsˇs´ı. Mezi sedm vrstev patˇr´ı: 3.1.1

Fyzick´ a vrstva

´ Ukolem fyzické vrstvy je zakódován´ı jednotliv´ ych bit˚ u rámce sestrojeného linkovou vrstvou do signálu urˇceného pro pˇrenos pˇres fyzické médium a následnˇe tento signál odeslat/pˇrijmout. Signál m˚ uˇze b´ yt optick´ y, mikrovlnn´ y nebo elektrick´ y. Souˇca´st´ı fyzické vrstvy jsou: • pˇrenosové médium a konektory • zp˚ usob reprezentace dat na daném médiu • zp˚ usob, jak´ ym jsou data zakódována 9


3.1 Architektura ISO/OSI

3.1.2

Linkov´ a vrstva

Zajiˇst’uje spojen´ı mezi dvˇema fyzicky pˇr´ımo propojen´ ymi uzly s´ıtˇe. Uspoˇrádává data z ’ fyzické vrstvy do celk˚ u naz´ yvan´ ych rámce a zajiˇst uje i zpˇetn´ y proces. Jak rámec vypadá je moˇzné vidˇet na Obrázku ˇc´ıslo 5.

Obrázek 5: Rámec • 6 bajt˚ u c´ılová fyzická adresa (DA - Destination Address) • 6 bajt˚ u zdrojová fyzická adresa (SA - Source Address) • 2 bajty typ protokolu (TYPE) • 46-1500 bajt˚ u pˇrenáˇsená data (DATA) • 4 bajty kontroln´ı souˇcet (CRC) Vrstva ˇr´ıd´ı vys´ılán´ı a uspoˇra´dáván´ı pˇrenáˇsen´ ych rámc˚ u, nastavuje parametry pˇrenosu a detekuje neopravitelné chyby. Formátuje fyzické rámce a opatˇruje je fyzickou adresou (MAC adresou). MAC adresa se skládá z 48 bit˚ u a zapisuje se ve formátu ˇsesti dvojcifern´ ych hexadecimáln´ıch ˇc´ısel oddˇelen´ ych dvojteˇckou (pˇr: 00:15:17:FA:CD:B9). Adresa je pˇriˇrazena s´ıt’ové kartˇe pˇri jej´ı v´ yrobˇe a slouˇz´ı jako jednoznaˇcn´ y identifikátor s´ıt’ového zaˇr´ızen´ı. ’ Pro vyˇsˇs´ı vsrtvy zajiˇst uje linková vrstva nezávislost na konkrétn´ım typu pˇrenosového média. Od s´ıt’ové vrstvy pˇrij´ımá linková vrstva paket, kter´ y dopln´ı o hlaviˇcku a patiˇcku, t´ım vznikne rámec. Obsahem hlaviˇcky a patiˇcky jsou tyto informace: • informace o zaˇca´tku a konci rámce • zdrojová a c´ılová fyzická adresa zaˇr´ızen´ı (tzv. MAC adresa) • typ zprávy - definuje, o kter´ y protokol se jedná • CRC - kontroln´ı souˇcet pouˇzit´ y pro detekci chyb Pˇr´ıkladem protokolu linkové vrstvy je Ethernet, kter´ y je pouˇz´ıvan´ y ve vˇetˇsinˇe dneˇsn´ıch s´ıt´ı. Mezi zaˇr´ızen´ı p˚ usob´ıc´ı na této vrstvˇe patˇr´ı: • most (Bridge) - starˇs´ı zaˇr´ızen´ı neˇz switch, v dneˇsn´ı dobˇe se skoro nepouˇz´ıvá • pˇrep´ınaˇc (Switch) - vˇetˇs´ı datová propustnost, v´ıce port˚ u 10



3.1.3

S´ıt’ov´ a vrstva

Tato vrstva se stará o adresován´ı a smˇerován´ı datov´ ych tok˚ u v s´ıt´ıch. Zprostˇredkovává v´ ymˇenu dat ve formˇe paket˚ u mezi koncov´ ymi zaˇr´ızen´ımi, která spolu nejsou pˇr´ımo spojena (jsou propojena skrz s´ıt’). Pˇrij´ımá od vyˇsˇs´ı transportn´ı vrstvy segment, ke kterému pˇridá svoj´ı hlaviˇcku a t´ım vytváˇr´ı paket. Jak paket vypadá a co obsahuje, je moˇzné vidˇet na Obrázku ˇc´ıslo 6. Adresace se provád´ı pomoc´ı IP adres, které m˚ uˇzou b´ yt verze 4 nebo verze 6. • Pˇr´ıklad zápisu IPv4 adresy - 89.203.220.194/30 • Pˇr´ıklad zápisu IPv6 adresy - 2001:1a48:ffff::352/64

Obrázek 6: Paket IPv4 s´ıt’ové vrstvy

• 4 bity specifikuj´ıc´ı, jestli se jedná o IPv4 nebo IPv6 paket (Version) • 4 bity oznaˇcuj´ıc´ı délku hlaviˇcky vynásobenou 4 (IHL) • 8 bit˚ u oznaˇcuj´ıc´ı typ sluˇzby (Type of Service) • 16 bit˚ u oznaˇcuj´ıc´ı délku paketu v bytech (Total Length) • 16 bit˚ u oznaˇcuj´ıc´ı identifikaˇcn´ı tag pomáhaj´ıc´ı k rekonstrukci paketu z v´ıce fragment˚ u (Identification) • 3 bity, které oznaˇcuj´ı, zda je moˇzno paket fragmentovat (Flags) • 13 bit˚ u oznaˇcuj´ıc´ıch offset fragmentu (Fragment Offset) 11



• 8 bit˚ u obsahuj´ıc´ı hodnotu TTL (Time to live); oznaˇcuj´ı, pˇres kolik router˚ u m˚ uˇze paket proj´ıt, neˇz bude zniˇcen • 8 bit˚ u oznaˇcuj´ıc´ı protokol (Protocol (IP)) • 16 bit˚ u obsahuj´ıc´ı kontroln´ı souˇcet CRC (Header Checksum) • 32 bit˚ u obsahuj´ıc´ı zdrojovou IP adresu (Source Adress) • 32 bit˚ u obsahuj´ıc´ı c´ılovou IP adresu (Destination Address) Nejznámˇejˇs´ım protokolem s´ıt’ové vrstvy je protokol IP. Mezi zaˇr´ızen´ı p˚ usob´ıc´ı na této vrstvˇe patˇr´ı Smˇerovaˇce (Routery). 3.1.4

Transportn´ı vrstva

´ Ukolem transportn´ı vrstvy je identifikovat komunikace jednotliv´ ych aplikac´ı a pˇredávat pˇrijatá data pˇr´ısluˇsné aplikaci. Transpotn´ı vrstva pˇrij´ımá z vyˇsˇs´ıch vrstev souvisl´ y datov´ y tok a pˇred odeslán´ım dˇel´ı tento tok do segment˚ u (tzv. segmentace). Pˇri pˇrijet´ı naopak tyto segmenty sestavuje (tzv. reassembling). Adresace se provád´ı pomoc´ı komunikaˇcn´ıch port˚ u v rozsahu 0 - 65535. Pˇridˇelován´ı port˚ u je ˇr´ızeno doporuˇcen´ımi organizace IANA. • 0 - 1023 - Well known porty (systémové porty) • 1024 - 49151 - Registered (uˇzivatelské porty) • 49152 - 65535 - Dynamic (dynamické porty) Nejznámˇejˇs´ımi protokoly transportn´ı vrstvy jsou protokoly UDP a TCP. • TCP (Transmission Control Protocol) - tento protokol zaruˇcuje spolehlivé doruˇcován´ı a správné poˇrad´ı dat • UDP (User Datagram Protocol) - nespolehliv´ y“ protokol - nezaruˇcuje, zda se paket ” neztrat´ı nebo zda paket bude doruˇcen ve zprávném poˇrad´ı Pˇr´ıkladem m˚ uˇze b´ yt napˇr´ıklad Telnet funguj´ıc´ı na protokolu TCP a na portu 23 nebo Winbox pouˇz´ıvan´ y pro konfiguraci RouterOS, kter´ y funguje na protokolu TCP a portu 8291. 3.1.5

Relaˇ cn´ı vrstva

Umoˇzn ˇuje vytvoˇren´ı a ukonˇcen´ı relaˇcn´ıho spojen´ı, synchronizaci a obnoven´ı spojen´ı. Obecnˇe lze ˇr´ıci, ˇze u ´kolem této vrstvy je synchronizovat dialog mezi spolupracuj´ıc´ımi relaˇcn´ımi vrstvami obou systém˚ u, které spolu komunikuj´ı a ˇr´ıdit v´ ymˇenu dat mezi nimi. Obnoven´ı spojen´ı je zajiˇstˇeno pomoc´ı synchronizaˇcn´ıch znaˇcek, které vytváˇr´ı právˇe relaˇcn´ı vrstva. Datové jednotky pˇrenáˇsené relaˇcn´ı vrstvou se naz´ yvaj´ı Session Layer Protocol Data Unit. Pˇr´ıkladem protokol˚ u relaˇcn´ı vrstvy jsou: 12



• RPC (Remote Procedure Call) - vzdálené volán´ı procedur • SSL (Secure Socket Layer) - zabezpeˇcen´ı a ˇsifrován´ı spojen´ı 3.1.6

Prezentaˇ cn´ı vrstva

Hlavn´ı funkc´ı vrstvy je transformovat data do tvaru, kter´ y pouˇz´ıvaj´ı aplikace. Formát dat nemus´ı b´ yt na komunikuj´ıc´ıch systémech stejn´ y, proto prezentaˇcn´ı vrstva zajiˇst’uje pˇrevod mezi syntax´ı pouˇz´ıvanou na daném systému a syntax´ı obecnou. Prezentaˇcn´ı vrstva se zab´ yvá pouze strukturou dat, nikoliv jejich v´ yznamem. Mezi funkce patˇr´ı napˇr. pˇrizp˚ usoben´ı poˇrad´ı bajt˚ u, pˇrevod kód˚ u a abeced. Datové jednotky pˇrenáˇsené presentaˇcn´ı vrstvou se naz´ yvaj´ı PPDU (Presentation Layer Protocol Data Unit). Funkce prezentaˇcn´ı vrstvy jsou ˇ • Sifrov´ an´ı dat • Komprimace dat • Konvertován´ı dat 3.1.7

Aplikaˇ cn´ı vrstva

Jedná se o vrstvu nejbliˇzˇs´ı uˇzivateli, která jiˇz nezajiˇst’uje sluˇzby pro vyˇsˇs´ı vrstvu. Pˇr´ıklady funkc´ı zajiˇst’ovan´ ych touto vrstvou jsou souborové pˇrenosy, sd´ılen´ı zdroj˚ u, pˇr´ıstup k databáz´ım, prohl´ıˇzen´ı webov´ ych stránek, ovládán´ı program˚ u, apod. Datové jednotky pˇrenáˇsené aplikaˇcn´ı vrstvou jsou APDU (Application Layer Protocol Data Unit).

13


3.2 Architektura TCP/IP

3.2

Architektura TCP/IP

TCP/IP je s´ıt’ová architektura, která vznikla v sedmdesát´ ych letech. Byla vytvoˇrena ministerstvem obrany USA p˚ uvodnˇe pro vojenské u ´ˇcely pod názvem ARPANET. Po ovˇeˇren´ı funkˇcnosti paketové (pˇrep´ınané) technologie vláda rozhodla testovac´ı s´ıt’ nezruˇsit a tak se tato architektura dostala do akademického prostˇred´ı. Hned poté se do základn´ıho ARPANETU zaˇcaly pˇridávat nové protokoly a funkce a t´ım postupnˇe vznikl dneˇsn´ı Internet. Architektura TCP/IP vyuˇz´ıvá oproti architektuˇre ISO/OSI pouze ˇctyˇri vrstvy. Rozd´ıl odpov´ıdaj´ıc´ıch vrstev je pˇrehlednˇe znázornˇen na Obrázku ˇc´ıslo 7.

Obrázek 7: Rozd´ıl mezi ISO/OSI a TCP/IP Mezi základn´ı ˇctyˇri vrstvy TCP/IP patˇr´ı vrstva s´ıt’ového rozhran´ı, s´ıt’ová vrstva, transportn´ı vrstva a vrstva aplikaˇcn´ı. Schéma je moˇzné vidˇet na Obrázku ˇc´ıslo 8.: 3.2.1

Vrstva s´ıt’ov´ eho rozhran´ı

- nejniˇzˇs´ı vrstva, které specifikuje samotn´ y pˇr´ıstup k fyzickému pˇrenosovému médiu. TCP/IP na této vrstvˇe nikterak nespecifikuje pˇrenosové technologie. Pˇredpokládá se, ˇze pouˇzije to, co vznikne na základˇe jin´ ych technologi´ı (napˇr´ıklad Ethernet) a nepovaˇzuje za potˇrebné znovu vyv´ıjet ˇreˇsen´ı, které je jiˇz funkˇcn´ı. TCP/IP si klade za u ´kol to, jak jiˇz tyto existuj´ıc´ı technologie co nejlépe vyuˇz´ıt a zpˇr´ıstupnit je tak vyˇsˇs´ım vrstvám. Kaˇzdá pˇrenosová technologie má svá specifika, mezi nˇeˇz patˇr´ı r˚ uzné zp˚ usoby adresován´ı, r˚ uzná velikost pˇrenáˇsen´ ych rámc˚ u, r˚ uzn´ y charakter poskytovan´ ych sluˇzeb. Pˇr´ıklady tˇechto technologi´ı jsou: 14



Obrázek 8: Vrstvy TCP/IP • Ethernet • Token Ring • ATM (Asynchronous Transfer Mode) • FDDI (Fiber Distributed Data Interface) • HDLC (High-Level Data Link Control) 3.2.2

S´ıt’ov´ a vrstva

- vrstva, která jiˇz nen´ı závislá na konkrétn´ı pˇrenosové technologii, se naz´ yvá vrstva s´ıt’ová. ˇ Casto se oznaˇcuje jako Internet Layer (vrstva vzájemného propojen´ı s´ıt´ı) nebo je moˇzné ´ se setkat s oznaˇcen´ım IP vrstva. Ukol této vrstvy je pˇribliˇznˇe stejn´ y jako u s´ıt’ové vrstvy v referenˇcn´ım modelu ISO/OSI - stará se o to, aby se datové pakety dostaly od odes´ılatele skrz s´ıt’ k pˇr´ıjemci pˇres pˇr´ıpadné smˇerovaˇce (brány). D´ıky nespojovanému charakteru pˇrenosu v TCP/IP je na u ´rovni této vrstvy zajiˇstˇena jednoduchá datagramová sluˇzba. Základn´ım protokolem Internetové vrstvy je protokol IP a mezi dalˇs´ı, pouˇz´ıvané a nejznámˇejˇs´ı patˇr´ı napˇr: • ARP (Address Resolution Protocol) • ICMP (Internet Control Message Protocol) • IGMP (Internet Group Management Protokol) • IPSEC (IP security) 15



Smˇerován´ı v s´ıt´ıch TCP/IP je zajiˇstˇeno pomoc´ı smˇerovac´ıch protokol˚ u, které taktéˇz spadaj´ı do Internetové vrstvy. Nejˇcastˇeji je moˇzné se setkat s: • RIP (Routing Information Protocol) ve verz´ıch 1 a 2 • OSPF (Open Shortest Path First) • BGP (Border Gateway Protocol) Podrobnˇejˇs´ı popis a základn´ı principy fungován´ı routovac´ıch protokol˚ u OSPF a BGP jsou uvedeny v kapitole 4.3.2. 3.2.3

Transportn´ı vrstva

- vyuˇz´ıvá nespojovan´ y a nespolehliv´ y pˇrenos na u ´rovni s´ıt’ové vrstvy. Alternativnˇe vˇsak nab´ız´ı i pˇrenos spojovan´ y a spolehliv´ y. Transportn´ı vrstva je implemetnována aˇz v koncov´ ych zaˇr´ızen´ıch a umoˇzn ˇuje tak pˇrizp˚ usobit chován´ı s´ıtˇe moˇznostem a potˇrebám aplikace. Základn´ımu protokoly této vrstvy jsou: • TCP (transmission control protocol) - zajiˇst’uje spolehliv´ y a spojovan´ y pˇrenos • UDP (user datagram protocol) - zajiˇst’uje nespolehliv´ y a nespojovan´ y pˇrenos. Je jen lehkou nadstavbou nad s´ıt’ovou vrstvou a nijak nemˇen´ı povahu pˇrenosov´ ych sluˇzeb s´ıt’ové vrstvy. Oba protokoly slouˇz´ı primárnˇe k odliˇsen´ı jednotliv´ ych spojen´ı na jedné IP adrese. Pokud se k jednomu serveru chce pˇripojit vice klient˚ u, pouˇzij´ı se k rozliˇsen´ı jejich spojen´ı tzv. porty. Pomoc´ı port˚ u je moˇzné teoreticky rozliˇsit aˇz 65535 spojen´ı. 3.2.4

Aplikaˇ cn´ı vrstva

- tvoˇr´ı nejvyˇsˇs´ı vrstvu TCP/IP. Jej´ımi entitami jsou jednotlivé aplikaˇcn´ı programy ˇci procesy, které oproti referenˇcn´ımu modelu ISO/OSI komunikuj´ı pˇr´ımo s transportn´ı vrstvou a vyuˇz´ıvaj´ı jej´ıch sluˇzeb ve formˇe protokol˚ u UDP a TCP. Funkce prezentaˇcn´ı a relaˇcn´ı vrstvy v modelu ISO/OSI si musej´ı v architektuˇre TCP/IP realizovat aplikaˇcn´ı programy samostatnˇe. Kaˇzdé s´ıt’ové spojen´ı aplikace je jednoznaˇcnˇe urˇceno ˇc´ıslem portu, transportn´ım protokolem a IP adresou poˇc´ıtaˇce. Mezi nejznámˇejˇs´ı protokoly aplikaˇcn´ı vrstvy patˇr´ı napˇr´ıklad: • HTTP (Hypertext Transfer Protocol) • FTP (File Transfer Protocol) • POP3 (Post Office Protocol) • IMAP (Internet Message Access Protocol) • DNS (Domain Name System) 16


3.3 Zapouzdˇren´ı dat

3.3

Zapouzdˇ ren´ı dat

Po podrobném popisu jednotliv´ ych vrstev architektury TCP/IP je na Obrázku ˇc´ıslo 9 graficky znázornˇeno, co která vrstva pˇridává do v´ yslednˇe odeslan´ ych dat z daného zaˇr´ızen´ı. Data z aplikaˇcn´ı vrstvy se pˇri pˇredán´ı do vrstvy transportn´ı rozˇsiˇruj´ı o hlaviˇcku, která uvád´ı zdrojov´ y a c´ılov´ y port komunikace. Pˇri pr˚ uchodu vrstvou s´ıt’ovou se jedná o zdrojovou a c´ılovou IP adresu. V posledn´ı ˇradˇe vrstva s´ıt’ového rozhran´ı pˇridává do hlaviˇcky zdrojovou a c´ılovou MAC adresu zaˇr´ızen´ı a do patiˇcky typ technologie, kterou se data budou pˇrenáˇset.

Obrázek 9: Zapouzdˇren´ı dat v s´ıti TCP/IP

3.4

Nav´ az´ an´ı s´ıt’ov´ eho spojen´ı

Jak detailnˇe prob´ıhá navázán´ı s´ıt’ového spojen´ı, je nejlepˇs´ı popsat na konkrétn´ım pˇr´ıpadˇe. Klientsk´ y poˇc´ıtaˇc se chystá kontaktovat webov´ y server um´ıstˇen´ y v internetu. Pomoc´ı sluˇzby DNS klient zjist´ı pˇrevodn´ı vztah mezi názvem a IP adresou c´ılového serveru. Následnˇe zaˇc´ıná spojovac´ı proces. PC vyˇsle do s´ıtˇe broadcast a pomoc´ı protokolu ARP zjist´ı MAC adresu brány. Jakmile ji obdrˇz´ı vytvoˇr´ı TCP paket s c´ılov´ ym portem 80 a náhodnˇe vybran´ ym portem zdrojov´ ym a nastav´ı mu flag SYN. K paketu pˇridá c´ılovou adresu webového serveru a svoji zdrojovou IP adresu. V posledn´ım kroku se dopln´ı zdrojová MAC adresa klienta a c´ılová MAC adresa brány. Takto vytvoˇren´ y paket se odes´ılá do s´ıtˇe. Brána po ’ pˇrijet´ı paketu pˇrep´ıˇse hlaviˇcku vrstvy s´ıt ového rozhran´ı a ovˇeˇr´ı v smˇerovac´ı tabulce, zda má nˇejaké informace o c´ılovém webovém serveru. Následnˇe nastav´ı c´ılovou MAC adresu nové brány a zdrojovou MAC adresu na MAC adresu odchoz´ıho rozhran´ı a pos´ılá paket dále do s´ıtˇe. Paket takto cestuje s´ıt´ı aˇz do segmentu, kde se nacház´ı webov´ y server. V posledn´ım 17


3.4 Navázán´ı s´ıt’ového spojen´ı

kroku brána nastav´ı jako c´ılovou MAC adresu fyzickou adresu webového serveru. Webov´ y server po pˇrijet´ı paketu s flagem SYN odpov´ıdá klientovi stejn´ ym paketem SYN-ACK. Paket cestuje stejn´ ym zp˚ usobem zpátky ke klientovi. Jakmile doraz´ı, klient odpov´ıdá serveru paketem s flagem ACK. Tento proces se naz´ yvá tˇr´ıcestn´ y handshake a grafické znázornˇen´ı je moˇzné vidˇet na Obrázku ˇc´ıslo 10. Po u ´spˇeˇsném proveden´ı tohoto procesu m˚ uˇze zaˇc´ıt skuteˇcná datová komunikace.

Obrázek 10: Tˇr´ıcestn´ y handshake

18

4 ROUTEROS

4

RouterOS

4.1

Z´ akladn´ı informace

MikroTik RouterOS je routerov´ y operaˇcn´ı systém zaloˇzen´ y na Linuxu, vhodn´ y zejména pro bezdrátové spoje. Firma Mikrotik zaˇcala s v´ yvojem prvn´ıho operaˇcn´ıho systému v roce 1995 v Lotyˇssku. Z´ıskán´ı zkuˇsenost´ı s PC bylo základn´ım pil´ıˇrem k vybudován´ı routovac´ıho softwaru MikroTik v2 PC, kter´ y pˇrinesl v´ ybornou ovladatelnost komunikaˇcn´ıch periferi´ı. Verze 2 byla také poˇzadováná za prvn´ı stabiln´ı verzi. 4.1.1

Funkce operaˇ cn´ıho syst´ emu

Promˇena obyˇcejného PC v plnˇe nastaviteln´ y a spolehliv´ y router nebyla jeˇstˇe nikdy jednoduˇsˇs´ı. RouterOS je moˇzné bez problému nainstalovat na architekturu x86. Z obyˇcejného PC lze tak bˇehem 30 minut z´ıskat velmi v´ ykonn´ y router s nepˇrebern´ ym mnoˇzstv´ım funkcionalit. Vˇsechny tyto funkce lze samozˇrejmˇe provozovat i na deskách RouterBoard, na kter´ ych se dodává RouterOS jiˇz pˇredinstalovan´ y. Mezi základn´ı funkce tohoto operaˇcn´ıho systému patˇr´ı: • Router s podporou IPv4, Ipv6 a vˇsech dynamick´ ych protokol˚ u (RIP, OSPF,BGP) • Omezuj´ıc´ı ˇci bezpeˇcnostn´ı Firewall • Proxy server, NTP server, DNS server • Server pro monitorován´ı s´ıt’ového provozu • Hotspot ˇreˇsen´ı pro hotely, restaurace a kavárny • Gateway pro ˇr´ızen´ı pˇristupu uˇzivatel˚ u na internet 4.1.2

Licence

Funkcionalita operaˇcn´ıho systému je omezena v´ ybˇerem vhodné licence. V souˇcasné dobˇe Mikrotik rozliˇsuje ˇsest licenc´ı (podrobn´ y pˇrehled lze nalézt v Pˇr´ıloze 1) : • L0 - Trial licence, která funguje pouze 24 hodin • L1 - Demo licence - je potˇreba registrace • L3 - WISP CPE - licence pro bezdátové klienty, nen´ı moˇzno vytváˇret ˇreˇzim pˇr´ıstupového bodu • L4 - WISP - moˇzno vytváˇret pˇr´ıstupové body, veˇskerá funkcionalita je aktivn´ı, poˇcet tunel˚ u (PPPoE, L2TP) omezen na 200 • L5 - WISP - stejné jako L4, nav´ yˇsen´ y poˇcet aktivn´ıch tunel˚ u • L6 - Controller - vˇsechny funkce dostupné bez omezen´ı 19

4.2 Moˇznosti konfigurace

4.2 4.2.1

4 ROUTEROS

Moˇ znosti konfigurace Inicializace RouterOS

RouterOS se vˇzdy pˇred prvn´ım pouˇzit´ım nacház´ı v defaultn´ım nastaven´ı. Pˇri kaˇzdém spuˇstˇen´ı systému docház´ı k inicializaci a veˇsker´ y podporovan´ y hardware je po u ´spˇeˇsném nabˇehnut´ı systému pˇripraven k pouˇzit´ı. Pˇri prvotn´ım startu jsou vˇsechna zaˇr´ızen´ı zakázána s v´ yjimkou sériového portu a Ethernetového portu ˇc´ıslo jedna. Pˇres obˇe dvˇe tato rozhran´ı lze provést základn´ı konfiguraci zaˇr´ızen´ı. Do zaˇr´ızen´ı je moˇzné se pˇripojit pˇr´ıkazovou ˇra´dkou, grafick´ ym rozhran´ım nebo v omezené m´ıˇre pˇres rozhran´ı webové. Pro popis jednotliv´ ych moˇznost´ı je potˇreba nejdˇr´ıv vymezit nˇekolik pojm˚ u: • Telnet - neˇsifrovan´ y protokol, kter´ y umoˇzn ˇuje uˇzivateli pˇripojit se ke vzdálenému PC. Pos´ılá zadávaná hesla v nezabezpeˇcené formˇe, coˇz je v mnoha pˇr´ıpadech neˇza´douc´ı. • SSH - zabezpeˇcen´ y komunikaˇcn´ı protokol, náhrada telnetu. • Putty - klientsk´ y program protokol˚ u Telnet a SSH pro systémy Windows. 4.2.2

Pˇ r´ıkazov´ aˇ r´ adka

Ovládán´ı RouterOS pˇres pˇr´ıkazovou ˇrádku je jediné, které umoˇzn ˇuje kompletn´ı administraci tohoto systému. Ovladán´ı je velmi logické, ucelené a intuitivn´ı. Nelze pˇrehlédnout podobu s ovládac´ı konzol´ı produkt˚ u znaˇcky CISCO. Pˇr´ıkazová ˇrádka je vybavena velmi podrobnou nápovˇedou, která se dá kdykoliv vyvolat napsán´ım otazn´ıku ?“. Pˇr´ıklad nápovˇedy ” a toho, jak terminál ve skuteˇcnosti vypadá, lze nalézt na Obrázku ˇc´ıslo 11. Pro ilustraci je zde pouˇzit v´ ystup programu Putty, kter´ y s RouterOS komunikuje pˇres protokol SSH.

Obrázek 11: Pˇr´ıkazov´ y ˇrádek - program Putty

20

4.2 Moˇznosti konfigurace

4.2.3

4 ROUTEROS

Winbox

V nˇekter´ ych pˇr´ıpadech m˚ uˇze nastat, ˇze administrátor nepotˇrebuje pˇr´ıstup ke vˇsem funkcionalitám systému RouterOS a upˇrednostn´ı uˇzivatelsky pˇr´ıjemnˇejˇs´ı grafické rozhran´ı. Pro tuto situaci vyvinul Mikrotik klientsk´ y program Winbox. Nastaven´ı systému pˇres utilitu Winbox je velmi rychlé a pohodlné.

Obrázek 12: Winbox - ukázka grafického rozhran´ı

4.2.4

Webov´ e rozhran´ı

Posledn´ı moˇznost´ı, jak systém nastavit, je pouˇzit´ı webového rozhran´ı, které umoˇzn ˇuje pˇr´ıstup k omezen´ ym funkcionalitám systému a je tak vhodné pouze pro koncové uˇzivatele a jednoduché nastaven´ı router˚ u pro pouˇzit´ı v domác´ı s´ıti. V tomto pˇr´ıpadˇe je moˇzné pouˇz´ıt tzv. Quick setup“, kter´ y v nˇekolika málo kroc´ıch provede uˇzivatele konfigurac´ı a pˇriprav´ı ” RouterBoard spolu se systémem k základn´ımu pouˇzit´ı.

21

4.3 S´ıt’ová funkcionalita RouterOS

4 ROUTEROS

4.3

S´ıt’ov´ a funkcionalita RouterOS

4.3.1

Z´ akladn´ı nastaven´ı pro komunikaci

Aby bylo moˇzné routery s operaˇcn´ım systémem RouterOS provozovat v s´ıti, je zcela nezbytné provést prvotn´ı konfiguraci základn´ıch parametr˚ u. V zaˇr´ızen´ı se po zapojen´ı napájen´ı inicializuje veˇsker´ y hardware a start operaˇcn´ıho systému je následnˇe signalizován hlasit´ ym dvoj´ım p´ıpnut´ım. V této chv´ıli se RouterBoard nacház´ı ve v´ ychoz´ım stavu. Na portu ether1 má nastavenou IP adresu 192.168.88.1/24 a tento port je aktivn´ı. Pro ovˇeˇren´ı pˇr´ıstupu slouˇz´ı v této chv´ıli uˇzivatelské jméno admin a v´ ychoz´ı heslo je prázdn´ y ˇretˇezec. Do zaˇr´ızen´ı je moˇzné se pˇripojit programem Putty a protokolem SSH zm´ınˇeném v kapitole 4.2.2. V´ ychoz´ı stav RouterBoardu nen´ı ˇza´dn´ ym zp˚ usobem pouˇziteln´ y v jiˇz funguj´ıc´ı a nakonfigurované s´ıti. Pro uveden´ı do stavu, kdy router bude moci komunikovat s okol´ım, bude zabezpeˇcen a bude podporovat základn´ı s´ıt’ové sluˇzby, je potˇreba nastavit následuj´ıc´ı parametry: • Heslo a identita Prvn´ım krokem pˇri nastaven´ı, kter´ y je nutn´ y pro zabezpeˇcen´ı, je zmˇena (nastaven´ı) administrátorského hesla. Po pˇrihláˇsen´ı do zaˇr´ızen´ı v´ ychoz´ımi u ´daji toto provedeme jednoduch´ ym napsán´ım password. Po vyplnˇen´ı starého, nového a potvrzen´ım nového hesla, je heslo u ´spˇeˇsnˇe zmˇenˇeno, jak je vidˇet na Obrázku ˇc´ıslo 13.

Obrázek 13: Zmˇena administrátorského hesla Aby bylo moˇzné jednotlivé routery od sebe v s´ıti rozeznat, je nutné kaˇzdému pˇriˇradit jiné jméno (identitu). V´ ychoz´ı nastaven´ı je jméno Mikrotik. Zmˇenu tohoto názvu provedeme pˇr´ıkazem: system identity set name=MujRouter . Zmˇena se projev´ı okamˇzitˇe a je patrná z Obrázku ˇc´ıslo 14.

Obrázek 14: Zmˇena identity routeru

22


4 ROUTEROS

• Nataven´ı IP adresy IP adresa 192.168.88.1/24 je urˇcena pro prvotn´ı konfiguraci routeru. Samozˇrejmost´ı je, ˇze si uˇzivatel m˚ uˇze nastavit jakoukoliv IP adresu na libovolné komunikaˇcn´ı rozhran´ı routeru. Adresa se v operaˇcn´ım systému RouterOS zadává vˇzdy s maskou a to ve zkráceném tvaru (tj napˇr´ıklad 192.168.88.1/24 znamená ve zkuteˇcnosti IP adresa 192.168.88.1 s maskou 255.255.255.0). Nastaven´ı IP adresy na pˇr´ısluˇsné rozhran´ı provedeme pˇr´ıkazem: ip address add address=10.0.0.10/24 interface=ether2. T´ımto pˇr´ıkazem je rozhran´ı ether2 pˇriˇrazena IP adresa 10.0.0.10 s maskou 255.255.255.0. Následnˇe je moˇzné pˇrehled vˇsech aktuálnˇe pˇriˇrazen´ ych IP adres vypsat pˇr´ıkazem ip address print. V´ ystup je pak podobn´ y tomu na Obrázku ˇc´ıslo 15.

Obrázek 15: Pˇriˇrazen´ı IP adresy danému rozhran´ı Pokud chceme IP adresu smazat, je potˇreba pouˇz´ıt pˇr´ıkaz ip address remove X, kde za X dosad´ıme ˇc´ıslo interface uvedeném ve v´ ypisu pˇr´ıkazem print. Pro smazán´ı IP adresy 192.168.88.1/24 je nutné uvést ip address remove 1. T´ımto dojde k pˇreruˇsen´ı komunikace a znovupˇripojen´ı do routeru bude nutné navázat na IP adrese 10.0.0.2 a na rozhran´ı ether2. • Bridge Velmi ˇcasto je potˇreba jednu IP adresu pˇriˇradit na v´ıce komunikaˇcn´ıch rozhran´ı. Pˇr´ıkladem m˚ uˇze b´ yt pouˇzit´ı routeru pro domác´ı u ´ˇcely, kde rozhran´ı ether1 chceme pouˇz´ıt pro pˇripojen´ı do internetu, ale ostatn´ı rozhran´ı chceme pouˇz´ıvat v rámci lokáln´ı s´ıtˇe a chceme, aby byla dostupná na vˇsech portech pod stejnou adresou. Za t´ımto u ´ˇcelem Mikrotik vyvinul funkci Bridge. Bridge je virtuáln´ı rozhran´ı, se kter´ ym se dá ve v´ ysledku pracovat jako s rozhran´ım fyzick´ ym. Pod jeden virtuáln´ı Bridge lze pˇriˇradit nˇekolik fyzick´ ych rozhran´ı a vytvoˇrit tak skupinu rozhran´ı, kter´ ym lze následnˇe pˇriˇradit spoleˇcnou IP adresu. Konfigurace je opˇet velmi jednoduchá. V prvn´ım kroku je potˇreba virtuáln´ı rozhran´ı vytvoˇrit. To lze provést pˇr´ıkazem: interface bridge add name=bridge-local. Následuje uˇz pouze zaˇrazen´ı fyzick´ ych rozhran´ı pod vytvoˇren´ y bridge. Toto lze provést pˇr´ıkazem interface bridge port add interface=ether1 bridge=bridge-local. Kontrolu správného zaˇrazen´ı zajiˇst’uje opˇet pˇr´ıkaz print v dané kategorii: interface bridge port print. V´ ystup takovéto konfigurace je zobrazen na Obrázku ˇc´ıslo 16.

23


4 ROUTEROS

Obrázek 16: Bridge - virtuáln´ı rozhran´ı Bridge m˚ uˇzeme vyuˇz´ıt také ve speciáln´ım pˇr´ıpadˇe pokud RouterBoard chceme nastavit do módu, kdy zaˇr´ızen´ı nebude slouˇzit jako router, ale pouze jako switch. V tomto pˇr´ıpadˇe vˇsechny fyzické rozhran´ı pˇriˇrad´ıme pod jedno virtuáln´ı, kterému pˇriˇrad´ıme IP adresu pro pˇr´ıstup do managementu. • NTP (Network Time Protocol) Protokol pˇresného s´ıt’ového ˇcasu byl vyvinut za u ´ˇcelem synchronizace hodin PC, router˚ u a dalˇs´ıch s´ıt’ov´ ych zaˇr´ızen´ı po poˇc´ıtaˇcové s´ıt´ı. Zajiˇst’uje, aby vˇsechna zaˇr´ızen´ı v s´ıti mˇela stejn´ y a pˇresn´ y ˇcas. To je zejména vhodné pro zaznamenáván´ı logovac´ıch u ´daj˚ u ˇci pro tvorbu záloˇzn´ıch kopi´ı konfigurace. Souˇcasná verze je NTP verze 4, a podrobn´ y popis je uveden v RFC 5905. V operaˇcn´ım systému Mikrotik RouterOS je tato funkce samozˇrejmˇe dostupná. V kaˇzdém zaˇr´ızen´ı lze nastavit primárn´ı a sekundárn´ı NTP server, od kterého má zaˇr´ızen´ı pˇrij´ımat synchronizaˇcn´ı pakety. Pro konfiguraci NTP serveru slouˇz´ı pˇr´ıkazy: system ntp client set primary-ntp=95.47.186.253 system ntp client set secondary-ntp=95.47.187.253 system ntp client set enabled=yes Pro správné nastaven´ı ˇcasového pásma je nutné uvést jeˇstˇe pˇr´ıkaz: system clock set time-zone-name=Europe/Prague V´ ypis správného ˇcasu je následnˇe volán pˇr´ıkazem: system clock print a je zobrazen na Obrázku ˇc´ıslo 17.

Obrázek 17: Nastaven´ı ˇcasu

24


4 ROUTEROS

• NAT (Network Address Translation) Pˇreklad s´ıt’ov´ ych adres je proces, pˇri kterém docház´ı k u ´pravˇe s´ıt’ového provozu procházej´ıc´ıho pˇres router za pomoci pˇrepisu zdrojové nebo c´ılové IP adresy (pˇr´ıpadnˇe ˇ i TCP ˇci UDP port˚ u u pr˚ uchoz´ıch paket˚ u). Casto se lze setkat i s názvy Network Masquerading ˇci IP Masquerading. NAT nám ve v´ ysledku umoˇzn ˇuje u ´sporu IP ad’ res v dané s´ıti. Pˇr´ıkladem opˇet m˚ uˇze b´ yt malá domác´ı s´ıt , ve které se vyskytuj´ı 2 poˇc´ıtaˇce a c´ılem NATu je, aby v rámci s´ıtˇe, do které jsou pˇripojeny, vystupovaly pod jednou IP adresou. Zapojen´ı je znázornˇeno na Obrázku ˇc´ıslo 18.

Obrázek 18: Pˇr´ıklad zapojen´ı domác´ı s´ıtˇe s NATem Mikrotik pro NAT pouˇz´ıvá tˇri základn´ı pravidla: – dst-nat - pˇreklad na základˇe c´ılové IP adresy – src-nat - pˇreklad na základˇe zdrojové IP adresy – masquarede - speciáln´ı pˇr´ıklad src-nat, kter´ y je velmi jednoduch´ y na konfiguraci Omezen´ı NATu je na prvn´ı pohled velmi zˇretelné. NAT sice umoˇzn´ı dvˇema poˇc´ıtaˇc˚ um ˇ pˇr´ıstup do s´ıtˇe, ale znemoˇzn´ı pˇr´ım´ y pˇr´ıstup k nim z venkovn´ı s´ıtˇe. Reˇsen´ım je poté pˇresmˇerován´ı dan´ ych sluˇzeb (port˚ u) pomoc´ı dst-nat. Na obrázku ˇc´ıslo 19 jsou uvedeny pˇr´ıkazy, které by umoˇznily dvˇema poˇc´ıtaˇc˚ um PC1 a PC2 vystupovat do venkovn´ı s´ıtˇe pod adresou 10.110.82.2/24 zadané na rozhran´ı ether1, ale zároveˇ n umoˇznily se z venkovn´ı s´ıtˇe na PC1 pˇripojit pomoc´ı Windows vzdálené plochy (port 3389) a na PC2 pomoc´ı programu LM FREE (port 5650). Komunikace na tyto stroje by pak prob´ıhala na adresách 10.110.82.2:3389 a 10.110.82.2:5650. 25


4 ROUTEROS

Obrázek 19: Pˇr´ıkazy pro nastaven´ı NAT • DHCP (Dynamic Host Configuration Protocol) Protokol, kter´ y se pouˇz´ıvá pro dynamickou konfiguraci klientsk´ ych zaˇr´ızen´ı pˇripojen´ ych do poˇc´ıtaˇcové s´ıtˇe. DHCP pˇridˇeluje jednotliv´ ym stroj˚ um zejména IP adresu, masku s´ıtˇe, implicitn´ı bránu a adresy primárn´ıho a sekundárn´ıho DNS serveru. RouterOS umoˇzn ˇuje jak dynamické tak statické pˇridˇelen´ı tˇechto u ´daj˚ u. Nejprve je zapotˇreb´ı uvést, v jakém rozsahu chceme IP adresy pˇridˇelovat. To je moˇzné zadat pˇr´ıkazem: ip pool add name=dhcppool ranges=10.0.0.100-10.0.0.254, z nˇehoˇz je jasnˇe patrn´ y ’ zadan´ y rozsah IP adres. Následnˇe je potˇreba nastavit s´ıt a gateway, která se bude koncov´ ym stanic´ım propagovat. To zaˇr´ıd´ı pˇr´ıkaz: ip dhcp-server network add address=10.0.0.0/24 gateway=10.0.0.1. Jako posledn´ı je potˇreba spustit DHCP server add name=dhcpserver address-pool=dhcppool interface=bridge1 disabled=no. Pokud je potˇreba pˇriˇradit stanic´ım staticky vˇzdy stejnou IP adresu, je potˇreba do skupiny leases uvést MAC adresu stroje a u ´daje, které mu maj´ı b´ yt pˇriˇrazeny. To lze udˇelat pˇr´ıkazem: ip dhcp-server lease add address=10.0.0.252 client-id=1:70:71:bc:6c:7b:69 comment=Server mac-address=70:71:BC:6C:7B:69 server=dhcpserver V´ ypis vˇsech zaˇr´ızen´ı s pˇriˇrazenou IP lze vypsat pomoc´ı ip dhcp-server lease print

Obrázek 20: V´ ypis tabulky DHCP leases - zaˇr´ızen´ı s pˇridˇelenou IP

26


4.3.2

4 ROUTEROS

Smˇ erov´ an´ı mezi routery

Smˇerován´ı datov´ ych paket˚ u v s´ıti je ˇcasto oznaˇcováno pojmem routován´ı. Pˇri tomto procesu docház´ı k urˇcován´ı cest datagram˚ u jednotliv´ ymi smˇery na základˇe smˇerovac´ı tabulky. Smˇerovac´ı tabulka je vyplnˇena administrátorem staticky a nebo je dynamicky naplnˇena pomoc´ı smˇerovac´ıho protokolu a algoritmu, kter´ y dan´ y protokol pouˇz´ıvá. Obsahem této ’ tabulky je c´ılová s´ıt spoleˇcnˇe s maskou, brána, na kterou se maj´ı dané pakety pro tuto s´ıt’ smˇerovat, a název odchoz´ıho rozhran´ı. Velmi ˇcasto je také uvedena defaultn´ı routa, která odkazuje na implicitn´ı gateway. Veˇskeré pakety, které nesplˇ nuj´ı ˇzádné z routovac´ıch pravidel, jsou poslány na implicitn´ı bránu. • Statické smˇerován´ı Pˇri pouˇzit´ı statického routován´ı je tˇreba, aby administrátor zadal do routeru pro kaˇzdou routovanou s´ıt’ jeden záznam. To je sice vhodné napˇr´ıklad pro koncové stanice ˇci routery, kde je provoz smˇerován pouze jedn´ım smˇerem a lze pouˇz´ıt defaultn´ı routu, ale uˇz to nen´ı vhodné pro vˇetˇs´ı s´ıtˇe, kde sebemenˇs´ı zmˇena v návrhu topologie s´ıtˇe by pro administrátora znamenala zásah do konfigurace nˇekolika s´ıt’ov´ ych prvk˚ u. Pˇridán´ı defaultn´ı routy do prvk˚ u Mikrotik RouterBoard lze provést pˇr´ıkazem: ip route add dst-address=0.0.0.0/0 gateway=10.110.82.1. Smˇerovac´ı tabulku lze vypsat pomoc´ı pˇr´ıkazu ip route print a pˇr´ıklad takové tabulky je uveden na Obrázku ˇc´ıslo 21. Z v´ ypisu je patrné, ˇze defaultn´ı routa byla zadána staticky (je oznaˇcená p´ısmenem S - static).

Obrázek 21: V´ ypis smˇerovac´ı tabulky se staticky zadanou defaultn´ı bránou • Dynamické smˇerován´ı Pˇri pouˇzit´ı dynamického smˇerován´ı jsou tabulky plnˇeny automaticky a v pravideln´ ych intervalech dynamicky reaguj´ı na zmˇeny topologie s´ıtˇe. Pro naplnˇen´ı tabulek je moˇzno pouˇz´ıt nˇekolik dynamick´ ych protokol˚ u, které se dˇel´ı do dvou tˇr´ıd: – interior - RIP v1 a v2, OSPF – exterior - BGP 27


4 ROUTEROS

Rozd´ıl mezi statick´ ym a dynamick´ ym smˇerován´ım je zˇrejm´ y. Na zaˇr´ızen´ıch, kde se konfigurace mˇen´ı jen zˇr´ıdka, je vhodné pouˇz´ıt statické smˇerován´ı. Prav´ ym opakem jsou pak páteˇrn´ı prvky s´ıtˇe, kde se konfigurace m˚ uˇze dynamicky mˇenit dle funkˇcnosti a nefunkˇcnosti linek. Rozd´ıly mezi jednotliv´ ymi dynamick´ ymi protokoly uˇz na prvn´ı pohled patrné nejsou, proto se následuj´ıc´ı text bude vˇenovat struˇcnému popisu a základn´ımu nastaven´ı tˇr´ı nejpouˇz´ıvanˇejˇs´ıch protokol˚ u, které systém RouterOS podporuje. • RIP (Routing Information Protocol) RIP je vhodn´ y pouze do menˇs´ıch a stˇrednˇe velk´ ych s´ıt´ı. Pouˇz´ıvá k urˇcen´ı cesty Distance Vector Algoritmus, u kterého nen´ı moˇzné ohodnotit linky napˇr´ıklad dle jejich kapacity. Základn´ım parametrem DVA algoritmu je poˇcet skok˚ u mezi jednotliv´ ymi routery. Maximáln´ı poˇcet skok˚ u je 15, coˇz je jedna z nev´ yhod a omezuje tak pouˇzit´ı RIPu ve vˇetˇs´ıch s´ıt´ıch. Druhou velkou nev´ yhodou je pomalá konvergence tohoto algoritmu. Problémy s pomalou konvergenc´ı a zacyklen´ım ˇreˇs´ı RIP ve verzi 2 pomoc´ı split horizon with poisoned reverse“. Veˇskeré dalˇs´ı informace a podrobnosti ” je moˇzné dohledat v RFC 2453. Nastaven´ı RIP na prv´ıch Mikrotik RouterBoard je velmi dobˇre popsáno na http://www.mikrotik.com/testdocs/ros/2.9/routing/rip.php. • OSPF (Open Shortest Path First) Na rozd´ıl od RIP je OSPF smˇerovac´ı protokol, kter´ y je urˇcen pro stˇrednˇe velké a velké poˇc´ıtaˇcové s´ıtˇe. Routery, pouˇz´ıvaj´ıc´ı tento protokol, si v dan´ ych intervalech mezi sebou pos´ılaj´ı Hello“ pakety a kontroluj´ı tak stav sousedn´ıch router˚ u. Pˇri ” zjiˇstˇen´ı jakékoliv zmˇeny, router pos´ılá informaci vˇsem router˚ um v s´ıti a ty si na základˇe toho pˇrepoˇc´ıtaj´ı svoj´ı smˇerovac´ı tabulku. Linky lze ohodnotit r˚ uznou hodnotou Cost“, která je brána v u ´vahu pˇri v´ ypoˇctu nejlepˇs´ı trasy. V´ ymˇena tˇechto ” informac´ı prob´ıhá pomoc´ı LSA (Link State Advertisement) paket˚ u, které si router ukládá do své topologické databáze. V´ ysledkem je vˇzdy shodná topologická databáze na vˇsech smˇerovaˇc´ıch. Z této databáze následnˇe kaˇzd´ y router pomoc´ı Dijsktrova algoritmu vypoˇcte optimáln´ı trasy pro smˇerován´ı. OSPF je nejpouˇz´ıvanˇejˇs´ı protokol pouˇz´ıvan´ y uvnitˇr autonomn´ıch systém˚ u (autonomn´ı systém je skupina smˇerovaˇc˚ u a IP prefix˚ u se spoleˇcnou smˇerovac´ı politikou a jednotnou správou). OSPF dˇel´ı autonomn´ı systém na nˇekolik oblast´ı, které se naz´ yvaj´ı area a jsou obvykle znaˇcené 32 bitov´ ym ˇc´ıslem (vypadaj´ı stejnˇe jako IP adresa). V´ yhodou tˇechto oblast´ı je, ˇze v´ yˇse zm´ınˇené LSA pakety jsou ˇs´ıˇreny pouze v rámci jedné oblasti a nedocház´ı tak ke zbyteˇcnému zahlcen´ı s´ıtˇe. OSPF rozliˇsuje tˇri druhy oblast´ı: – páteˇrn´ı (backbone) - oblast oznaˇcovaná 0.0.0.0. Do této oblasti jsou pˇripojeny vˇsechny ostatn´ı a tato oblast je pˇripojena do internetu – tranzitn´ı (tranzit) - oblast, která je pˇripojena do páteˇrn´ı oblasti v´ıce cestami – stub - oblast, která je pˇripojena do páteˇrn´ı pouze jednou cestou Routery, které jednotlivé oblasti spojuj´ı, maj´ı speciáln´ı oznaˇcen´ı ABR (Area Border Router). Speciáln´ım pˇr´ıpadem je router, kter´ y zastává hraniˇcn´ı funkci celého au28


4 ROUTEROS

tonomn´ıho systému a oznaˇcuje se ASBR (Autonomous System Boundary Router). V´ıce o protokolu OSPF je moˇzné nalézt v RFC 2328. Základn´ı nastaven´ı OSPF v oblasti backbone pro systém Mikrotik RouterOS je podrobnˇe uvedeno na adrese: http://wiki.mikrotik.com/wiki/Manual:OSPF-examples. V´ ystup z dynamicky naplnˇené routovac´ı tabulky je uveden na Obrázku ˇc´ıslo 22. P´ısmeno o“ zde znaˇc´ı routy, které byly do tabulky pˇridány dynamicky pomoc´ı pro” tokolu OSPF.

Obrázek 22: V´ ypis ˇcásti dynamicky naplnˇené smˇerovac´ı tabulky za pomoci OSPF

• BGP(Border Getaway Protocol) BGP je zástupcem exterior“ routovac´ıho protokolu a je urˇcen pro smˇerován´ı mezi au” tonomn´ımi systémy jednotliv´ ych poskytovatel˚ u. Smˇerován´ı mezi autonomn´ımi systémy má svoje charakteristické poˇzadavky. Smˇerovac´ı tabulky obsahuj´ı v pˇr´ıpadˇe tzv. Full BGP“ tabulky stovky tis´ıc záznam˚ u. Nejd˚ uleˇzitˇejˇs´ım kritériem ˇcasto neb´ yvá ” vzdálenost zdroje od c´ıle, ale cena linky, pˇr´ıpadnˇe dalˇs´ı uˇzivatelsky nastavované atributy (napˇr´ıklad seznam tranzitn´ıch autonomn´ıch systém˚ u). Podrobn´ y popis protokolu je moˇzné nalézt v RFC 4271. Velmi pˇekn´ y pˇr´ıklad jednoduchého nastaven´ı BGP pod operaˇcn´ım systémem RouterOS je dostupn´ y na adrese: http://isp-servis.cz/config mikrotik.html. V tomto pˇr´ıpadˇe se pˇres BGP ˇs´ıˇr´ı pouze defaultn´ı routa, coˇz je pro provoz internetu dostateˇcné. Reáln´ y v´ ypis defaultn´ı routy nauˇcené pˇres BGP je ukázán na Obrázku ˇc´ıslo 23.

Obrázek 23: V´ ypis ˇca´sti dynamicky naplnˇené smˇerovac´ı tabulky za pomoci BGP

29

4.4 Monitorován´ı zaˇr´ızen´ı

4.4

4 ROUTEROS

Monitorov´ an´ı zaˇ r´ızen´ı

Informace, zda monitorované zaˇr´ızen´ı v dané dobˇe funguje, jak´ ym zp˚ usobem je zat´ıˇzeno, jaká je aktuáln´ı verze operaˇcn´ıho systému ˇci jak tyto informace vypadaly v historii, jsou informace, které by mˇely b´ yt souˇca´st´ı kaˇzdého monitorovac´ıho systému. Dohled (monitoring) je jedna z nejd˚ uleˇzitˇejˇs´ıch souˇcást´ı ˇra´dnˇe funguj´ıc´ı s´ıtˇe. Administrátor s´ıtˇe, která funguje na prvc´ıch RouterBoard s operaˇcn´ım systémem RouterOS, m˚ uˇze volit z nˇekolika technologi´ı a protokol˚ u, aby dosáhl stavu, kdy bude znát poˇzadované informace. Cel´ y monitorovac´ı systém je moˇzné postavit na vlastn´ıch scriptech ˇci na bezplatn´ ych dohledovac´ıch systémech, kdy administrátor vˇenuje dohledu pouze ˇcas a svoje znalosti. Protipólem je nasazen´ı rozsáhl´ ych systém˚ u z komerˇcn´ı nab´ıdky, které nab´ız´ı nepˇreberné mnoˇzstv´ı funkcionalit. Tyto systémy jsou ovˇsem zpoplatnˇeny. • placené : ISPadmin, Zennos, MikroBill • volnˇe dostupné: Cacti, Nagios, Zabbix Vzhledem k praktické ˇcásti této diplomové práce se následuj´ıc´ı text nebude zab´ yvat popisem hotov´ ych dohledovac´ıch systém˚ u, ale naopak se bude snaˇzit pˇribl´ıˇzit základn´ı prostˇredky (technologie a protokoly), pomoc´ı kter´ ych je moˇzné naprogramovat a sestavit vlastn´ı základn´ı dohledovac´ı systém pro prvky s operaˇcn´ım systémem RouterOS. Pˇred v´ ybˇerem tˇechto technologi´ı je nutné si nejdˇr´ıve ujasnit, co pˇresnˇe je zapotˇreb´ı sledovat a jak´ y v´ ystup je prioritn´ı. Na monitoring je moˇzné se d´ıvat ze dvou pohled˚ u. Prvn´ım z nich je, ˇze na nˇejakém zaˇr´ızen´ı v s´ıti doˇslo k problému a je potˇrebné ho zkontrolovat. Druh´ ym pohledem pak pak m˚ uˇze b´ yt periodické z´ıskáván´ı informac´ı o systému na daném prvku (napˇr´ıklad vyuˇzit´ı CPU, odezva zaˇr´ızen´ı v s´ıti). Tyto informace je pak administrátor schopn´ y vyuˇz´ıt k dalˇs´ımu plánován´ı s´ıtˇe (upgradu prvk˚ u, ˇci pˇrenosov´ ych technologi´ı). Ideáln´ı verz´ı dohledovac´ıho systému by mˇela b´ yt kombinace obou tˇechto pohled˚ u. Mezi poloˇzky, které je moˇzné dohledovat na systému RouterOS patˇr´ı napˇr´ıklad: • dostupnost daného RouterBoardu (latence) • vyt´ıˇzen´ı zdroj˚ u (CPU, disk, pamˇet’) • informace o typu desky a verzi operaˇcn´ıho systému • vyt´ıˇzen´ı pˇrenosov´ ych linek • bezpeˇcnostn´ı incidenty • zmˇeny v konfiguraci (smˇerovac´ı tabulky atd.) Základn´ı monitorovac´ı prostˇredky operaˇcn´ıho systému RouterOS jsou ve vˇetˇsinˇe pˇr´ıpad˚ u shodné z monitorován´ım jak´ ychkoliv jin´ ych zaˇr´ızen´ı. Na následuj´ıc´ıch ˇra´dkách budou popsány ty nejpouˇz´ıvanˇejˇs´ı z nich a bude zde uvedena základn´ı konfigurace systému RouterOS, která je potˇrebná pro jejich bezchybnou funkˇcnost. 30


4.4.1

4 ROUTEROS

ICMP a PING

ICMP (Internet Control Message Protocol) je jeden z nejd˚ uleˇzitˇejˇs´ıch protokol˚ u ze sady protokol˚ u internetu. Operaˇcn´ı systémy je pouˇz´ıvaj´ı pro pos´ılán´ı chybov´ ych zpráv, napˇr´ıklad pro oznámen´ı, ˇze poˇzadovaná sluˇzba nen´ı dostupná. Podrobná dokumentace tohoto protokolu je dostupná v RFC 792. V souvislosti s dohledem s´ıt’ov´ ych prvk˚ u jsou ICMP pakety vyuˇz´ıvány pˇredevˇs´ım nástrojem PING, kter´ y pos´ılá pakety Echo Request“ a oˇcekává pˇr´ıjem zprávy Echo Reply“, aby ” ” urˇcil, zda je c´ılov´ y s´ıt’ov´ y prvek dosaˇziteln´ y a jak dlouho paket˚ um trvá, neˇz se dostanou ze zdroje k c´ıli a zpˇet. PING je dostupn´ y pod systémem RouterOS, Unix i Windows a je povaˇzován za jeden z univerzáln´ıch nástroj˚ u pro ovˇeˇrován´ı dostupnosti prvk˚ u v s´ıti. Spuˇstˇen´ı na vˇsech systémech je provádˇeno pˇr´ıkazem ping A.B.C.D, kde A.B.C.D je IP adresa zaˇr´ızen´ı na které chceme zaslat dotazovac´ı ICMP paket. Ping má i nˇekolik dalˇs´ıch parametr˚ u. Mezi hlavn´ı patˇr´ı parametr count (pro systém RouterOS), kter´ y udává poˇcet odeslan´ ych ICMP paket˚ u a parametr size, kter´ y udává jejich velikost. Pˇr´ıklad ping na zaˇr´ızen´ı s IP adresou 10.110.254.254 o poˇctu 5 ICMP paket˚ u o velikosti 10000 Byt˚ u je zobrazen na Obrázku ˇc´ıslo 24.

Obrázek 24: Ping na zaˇr´ızen´ı 10.110.254.254 V´ ystupem nástroje PING je v kaˇzdém ˇra´dku aktuáln´ı odezva prvku s dotazovanou IP adresou. Je uvedena v milisekundách. Dále je v kaˇzdém ˇra´dku vypsán parametr TTL (Time To Live), coˇz je hodnota ˇzivotnosti“ paket˚ u a znaˇc´ı, pˇres kolik router˚ u paket jeˇstˇe m˚ uˇze ” proj´ıt neˇz bude routerem zahozen (to nastane pˇri hodnotˇe 0). Po odeslán´ı zadaného poˇctu ICMP paket˚ u jsou vypsány statistiky, které udávaj´ı: • sent/received : poˇcet odeslan´ ych/pˇrijat´ ych paket˚ u • packetloss : procentuálnˇe vyjádˇrena ztráta paket˚ u • min-rtt/avg-rtt/max/rtt : minimáln´ı/pr˚ umˇerná/maximáln´ı doba odezvy

31


4.4.2

4 ROUTEROS

SNMP

Simple Network Management Protocol slouˇz´ı k potˇrebám správy s´ıtˇe. Protokol umoˇzn ˇuje sbˇer nejr˚ uznˇejˇs´ıch dat z datové s´ıtˇe a jejich následné vyhodnocován´ı. Na tomto protokolu je d´ıky své univerzálnosti v dneˇsn´ı dobˇe postavena vˇetˇsina prostˇredk˚ u a nástroj˚ u pro dohled a správu s´ıtˇe. Je potˇreba rozliˇsovat mezi stranou monitorovanou (hl´ıdan´ y systém) a monitorovac´ı (sbˇerna dat). Na monitorované stranˇe obvykle bˇeˇz´ı Agent, kter´ y shromaˇzd’uje data o daném systému. Na stranˇe monitorovac´ı bˇeˇz´ı manager, kter´ y se v intervalech dotazuje na poˇzadovaná data Agenta dohledovaného systému. Komunikace mezi agentem a managerem se oznaˇcuje jako SNMP operace. M˚ uˇze existovat i taková konfigurace agenta, která je schopna reagovat na vniklou situaci tak, ˇze sám agent odeˇsle zprávu managerovi automaticky bez jeho poˇzadavku. Taková konfigurace je oznaˇcována jako SNMP TRAP. Jednoznaˇcná identifikace informac´ı vyuˇz´ıvaná systémem správy je uvedena v databázi MIB (Management Information Base) pomoc´ı tzv identifikátoru objektu OID (object identifier). Aby si SNMP agent a manager mohli tyto informace pˇredávat, je nutná znalost této databáze, která je veˇrejnˇe pˇr´ıstupná na: http://www.alvestrand.no/objectid/1.3.6.1.html. OID v systému RouterOS lze u vˇsech poloˇzek vypsat pomoc´ı pˇr´ıkazu print oid v dané kategorii. Pokud napˇr´ıklad chceme vypsat hodnotu uptime (dobˇe bˇehu systému), kter´ y je dostupn´ y v kategroii system resource, pouˇzijeme pˇr´ıkaz system resource print oid. V´ ystup je znázornˇen na Obrázku ˇc´ıslo 25.

Obrázek 25: Vypsán´ı OID hodnoty uptime na systému RouterOS Podrobn´ y popis protokolu SNMP je uveden v RFC 1157, kde lze nalézt pˇresnou definici zpráv, pomoc´ı kter´ ych docház´ı k v´ ymˇenˇe informac´ı. Patˇr´ı mezi nˇe napˇr´ıklad get-request, get-next-request, get-response, get-bulk,trap, inform. Protokol SNMP má aktuálnˇe 3 verze: • v1 - nezabezpeˇcen´ y pˇrenos dat • v2 - umoˇzn ˇuje autentizaci • v3 - umoˇzn ˇuje autentizaci a ˇsifrován´ı Operaˇcn´ı systém RouterOS podporuje vˇsechny tˇri verze. Pokud chceme doc´ılit spolehlivého a bezpeˇcného pˇrenosu dat, je vhodné vyuˇz´ıt verzi 3 protokolu SNMP. V následuj´ıc´ım textu budou popsány konfiguraˇcn´ı pˇr´ıkazy, které umoˇzn´ı nakonfigurovat agenta systému RouterOS tak, aby z nˇej bylo moˇzné vyˇc´ıtat monitorovac´ı data pomoc´ı SNMP ve verzi 3.

32


4 ROUTEROS

V systému router OS je pˇri spuˇstˇen´ı pˇredkonfigurováno SNMP. Je zde nastaveno com” munity name“ na hodnotu public (pˇrihlaˇsovac´ı jméno v protokolu SNMP). Nen´ı poˇzadováno ˇza´dné heslo ani ˇsifrován´ı (SNMP ve verzi 1) a je povoleno pouze ˇcten´ı dat. Zprovoznˇen´ı takového pˇr´ıstupu je moˇzné provést pˇr´ıkazem: snmp set enabled=yes. Jak jiˇz bylo ˇreˇceno, nen´ı tento zp˚ usob zabezpeˇcen´ı vhodn´ y. T´ımto zp˚ usobem si jak´ ykoliv uˇzivatel s´ıtˇe m˚ uˇze bez problému zjistit veˇskeré informace o zaˇr´ızen´ı (dostupné pˇres SNMP) a to nen´ı v ˇza´dném pˇr´ıpadˇe vyhovuj´ıc´ı. Pro plnˇe zabezpeˇcen´ y pˇr´ıstup je nutné pouˇz´ıt SNMP ve verzi 3, které podporuje autentizaci a ˇsifrován´ı. V systému RouterOS je moˇzné volit mezi ˇ autentizaˇcn´ım protokolem MD5 (RFC 1321) a SHA1 (RFC3174). Sifrovac´ ı protokol je pak nastaven na DES (RFC 4772). Nastaven´ı je moˇzné provést pˇr´ıkazem: snmp community add addresses=0.0.0.0/0 authentication-password=D1pl0mkA encryption-password=D1pl0mkA ´ eˇsné zaloˇzen´ı nové zabezpeˇcené community s autenname=secure security=private. Uspˇ tizaˇcn´ımi a ˇsifrovac´ımi u ´daji je viditelné na Obrázku ˇc´ıslo 26.

Obrázek 26: Community secure pro SNMP ve verzi 3 Otestován´ı, zda je SNMP v3 na systému RouterOS funkˇcn´ı, je moˇzné provést pomoc´ı nástroje snmpwalk nainstalovaném pod unixov´ ym systémem. Pro zkouˇsku spojen´ı je nyn´ı moˇzné pouˇz´ıt nastavené u ´daje (jméno: secure, heslo: D1pl0mkA, ˇsifromáván´ı DES s heslem: D1pl0mKA a dobˇre známé OID uptime .1.3.6.1.2.1.1.3.0). V´ ystup snmpwalku je vidˇet na Obrázku ˇc´ıslo 27 a je patrné, ˇze SNMP v3 funguje na systému RouterOS korektnˇe.

Obrázek 27: snmpwalk, SNMP v3, OID: uptime

33


4.4.3

4 ROUTEROS

Mikrotik API

Protoˇze protokol SNMP je urˇcen hlavnˇe pro vyˇc´ıtán´ı dat, která jsou dostupná u témˇeˇr vˇsech s´ıt’ov´ ych prvk˚ u, vyvinula firma Mikrotik svoje API, pˇres které je moˇzné ze systému RouterOS vyˇc´ıtat o mnoho v´ıc informac´ı (napˇr´ıklad SSID bezdrátové karty, pˇripojené bezdrátové klienty atd.). Pomoc´ı API lze také do systému RouterOS hodnoty zapisovat a celou konfiguraci mˇenit. API umoˇzn ˇuje uˇzivatel˚ um vytvoˇrit vlastn´ı software, kter´ y bude komunikovat s prvky RouterBoard. Syntaxe pˇr´ıkaz˚ u se velmi podobá pˇr´ıkaz˚ um CLI (pˇr´ıkazové ˇrádky). API je podporováno systémem RouterOS od verze 3.x v´ yˇse a v souˇcasnosti je vyvinuto pro mnoho programovac´ıch jazyk˚ u (C, C++, Java, Perl, PHP, Delphi). Nev´ yhodou API je, ˇze pˇri zápisu vˇetˇs´ıho mnoˇzstv´ı pravidel, vyˇzaduje pomˇernˇe hodnˇe ˇcasu a to z toho d˚ uvodu, ˇze jsou pˇr´ıkazy na router zas´ılány pomoc´ı vˇet, které vˇetˇsinou obsahuj´ı jeden ˇrádkov´ y pˇr´ıkaz. Odpovˇed’ je tvoˇrena opˇet API vˇetou (nebo v´ıce vˇetami). Toto tvoˇr´ı obrovské mnoˇzstv´ı komunikaˇcn´ı reˇzie, proto nemus´ı b´ yt API v nˇekter´ ych systémech pˇr´ıliˇs vhodné. Pokud chceme komunikovat s routerem pomoc´ı API, je nutné API v systému RouterOS nejdˇr´ıve povolit. API komunikuje na portu TCP 8728, pˇr´ıpadnˇe na portu 8729 pokud je potˇreba pouˇz´ıt zabezpeˇcen´ı API-ssl. Povolen´ı prob´ıhá pˇr´ıkazem: ip service enable 5 a ip service enable 7. Syntaxe API pˇr´ıkaz˚ u se liˇs´ı od pˇr´ıkazu pˇr´ıkazové ˇrádky tak, ˇze mezery mezi pˇr´ıkazy jsou vyplnˇeny zpˇetn´ ym lom´ıtkem a mezery v atributech jsou nahrazeny rovn´ıtkem: • CLI pˇr´ıkaz: ip address add address=192.168.88.1/24 interface=ether1 • API pˇr´ıkaz: /ip/address/add =address=192.168.88.1/24 =interface=ether1 Podrobn´ y popis Mikrotik API lze nalézt na: http://wiki.mikrotik.com/wiki/Manual:API. Jsou zde uvedeny i ukázky pˇr´ıkaz˚ u a zdrojové kódy API klienta pro nˇekolik programovac´ıch jazyk˚ u. Na Obrázku ˇc´ıslo 28 je uveden pˇr´ıklad pouˇzit´ı Mikrotik API k dohledován´ı poloˇzek, které by jinak neˇsly vyˇc´ıst pˇres SNMP. Zde konkrétnˇe se jedná o vypsán´ı vˇsech rout ze smˇerovac´ı tabulky, které maj´ı nˇejak´ y komentáˇr.

Obrázek 28: Pouˇzit´ı API

34


4.4.4

4 ROUTEROS

Grafov´ an´ı dat

Pro z´ıskán´ı monitorovac´ıch dat ze zaˇr´ızen´ı byly uvedeny základn´ı zp˚ usoby. Takto z´ıskané hodnoty je ale vhodné archivovat po nˇejakou dobu a ideálnˇe hodnoty zanést do graf˚ u. Za t´ımto u ´ˇcelem lze pouˇz´ıt vestavˇen´ y grafovac´ı nástroj pˇr´ımo v systému RouterOS nazvan´ y Graphing“. I kdyˇz je jeho funkˇcnost znaˇcnˇe omezená, pro základn´ı historii pˇrenos˚ u ” ’ na rozhran´ıch a vyuˇzit´ı prostˇredk˚ u (CPU, pamˇet , disk) m˚ uˇze nˇekter´ ym administrátor˚ um vyhovovat. Jako ideáln´ım ˇreˇsen´ım se jev´ı pro zaznamenáván´ı dat do grafu v zaˇr´ızen´ı koncov´ ych klient˚ u, kter´ ych v s´ıti b´ yvá velk´ y poˇcet a grafy jejich zaˇr´ızen´ı by na serverech zab´ıraly velmi mnoho prostoru. Zapnut´ı graf˚ u na RouterOS lze provést pˇr´ıkazem: tool graphing interface add allowaddress=0.0.0.0/0 interface=all store-on-disk=yes , kde prvn´ı parametr definuje IP adresy, pro které bude dohled dostupn´ y (v tomto pˇr´ıpadˇe vˇsechny), druh´ y, jaká rozhran´ı se maj´ı dohledovat a tˇret´ı parametr udává, ˇze se data maj´ı ukládat na lokáln´ı disk. Podobn´ ym pˇr´ıkazem lze zapnout i grafy zdroj˚ u: tool graphing resource add allow-address=0.0.0.0/0 store-on-disk=yes. Grafy jsou od kaˇzdé poloˇzky tvoˇreny ˇctyˇri (denn´ı, t´ ydenn´ı, mˇes´ıˇcn´ı, roˇcn´ı) a zobrazit je, je moˇzné pomoc´ı vestavˇeného webového serveru na adrese: http://IPADRESA/graphs/iface/ether1/ (pro rozhran´ı ether1). Jak vypadá jeden z graf˚ u, je patrné z Obrázku ˇc´ıslo 29.

Obrázek 29: Graf za pouˇzit´ı nástroje Graphing z RouterOS

35


4 ROUTEROS

Pouˇzit´ı lokáln´ı tvorby graf˚ u vˇsak nemus´ı b´ yt vˇzdy vhodné. Pˇr´ıkladem m˚ uˇze b´ yt pˇr´ıpad, kdy je router centráln´ım prvkem s´ıtˇe. Zaˇr´ızen´ı tvoˇr´ı grafy a z nˇejakého d˚ uvodu se porouchá. Administrátor s´ıtˇe jej vymˇen´ı za zaˇr´ızen´ı jiné, ovˇsem o veˇskeré grafy by t´ımto zp˚ usobem ˇ sen´ım této situace je pouˇzit´ı extern´ıho grafovac´ıho nástroje, kter´ pˇriˇsel. Reˇ y pobˇeˇz´ı na serveru a bude z dohledovan´ ych zaˇr´ızen´ı periodicky vyˇc´ıtat data (napˇr´ıklad pomoc´ı SNMP) a bude je ukládat do sv´ ych lokáln´ıch graf˚ u. I po v´ ymˇenˇe dohledovaného prvku s´ıtˇe, je moˇzné pokraˇcovat ve vykreslován´ı grafu a zachovat p˚ uvodn´ı hodnoty. Pˇr´ıkladem nástroje, kter´ y je urˇcen pro tyto u ´ˇcely, je RRDTool. Vytvoˇren´ı graf˚ u pomoc´ı nástroje RRDTool se skládá ze tˇr´ı základn´ıch ˇcást´ı: • Inicializace databáze rrdtool create CPUusage.rrd –step 60 DS:cpu:GAUGE:300:0:100 RRA:MAX:0.5:1:1500 V´ yznam prametr˚ u: – CPUusage.rrd : název datového souboru – –step 60 : data jsou oˇcekávána po 60 vteˇrinách – DS:cpu:GAUGE:300:0:100 : do promˇenné cpu se budou ukládat data. 300 je interval ve vteˇrinách, kter´ y znaˇc´ı ˇcas, po kterém bude zapsána do datového souboru 0, pokud nepˇrijdou dalˇs´ı data. 0 znaˇc´ı minimáln´ı a 100 maximáln´ı hodnotu (rozsah CPU 0-100 – RRA:MAX:0.5:1:1500 : Round Robin Archiv definuje, kolik hodnot je potˇreba uchovávat. D˚ uleˇzitá je hodnota 1, která uvád´ı, z kolika hodnot se má udˇelat pr˚ umˇer, neˇz se uloˇz´ı do archivu. V tomto pˇr´ıpadˇe se ukládá kaˇzdá hodnota. 1500 znaˇc´ı kolik hodnot se má ukládat. 1500 hodnot v intervalu 60 vteˇrin uloˇz´ı data po dobu 25 hodin. • Sbˇer a update dat rrdtool update CPUusage.rrd –template cpu N:cpu V´ yznam parametr˚ u: – CPUusage.rrd : název datového souboru – –template cpu N:cpu : hodnotu N:cpu ukládáme do archivu definovaného pˇri pouˇzit´ı rrdtool create (DS:cpu) • Vytvoˇren´ı grafu rrdtool graph CPUusage.png -a PNG –title=CPUusage DEF:probe1=CPUusage.rrd:cpu:MAX LINE1:probe1#ff0000:CPUusage V´ yznam parametr˚ u: – CPUusage.png - název v´ ystupn´ıho soboru 36


4 ROUTEROS

– CPUusage.png -a PNG –title=CPUusage - formát souboru a nastaven´ı popisu – DEF:probe1=CPUusage.rrd:cpu:MAX : nastav´ı z jakého souboru a jaká promˇenná se bude vykreslovat – LINE1:probe1#ff0000:CPUusage : vytvoˇr´ı legendu, nastav´ı barvu grafovac´ı ˇcáry a popisek legendy Vˇsechny uvedené pˇr´ıkazy jsou dostupné na Unixovém systému po ˇra´dné konfiguraci (aptget install mrtg rrdtool librrds-perl ). Nástroj RRDTool bude pouˇzit v praktické ˇcásti této diplomové práce. Pˇr´ıklad vytvoˇreného grafu pomoc´ı RRDTool je zobrazen na Obrázku ˇc´ıslo 30. Je zde vidˇet zat´ıˇzen´ı CPU routeru RB1200 bˇehem 25 hodin pˇri datovém toku cca 0 100Mbps.

Obrázek 30: Graf za pouˇzit´ı nástroje RRDTool

37

ˇ ızen´ı datov´ 4.5 R´ ych tok˚ u

4.5 4.5.1

4 ROUTEROS

ˇ ızen´ı datov´ R´ ych tok˚ u QoS (Kvalita sluˇ zeb)

QoS (Quality of service) je schopnost s´ıtˇe, pomoc´ı které lze nˇekter´ ym pˇrenos˚ um zajiˇst’ovat lepˇs´ı sluˇzby. Lze také ˇr´ıci, ˇze QoS je vlastnost s´ıtˇe, která umoˇzn´ı rozliˇsovat mezi r˚ uzn´ ymi tˇr´ıdami pˇrenos˚ u a pro kaˇzdou z nich nastavit r˚ uzné parametry pˇrenosu. QoS je rozliˇsována dle následuj´ıc´ıch kategori´ı: • Dostupnost sluˇzby - kvalita pˇripojen´ı do s´ıtˇe • Zpoˇzdˇen´ı sluˇzby - doba pˇrenosu mezi zdrojem a a c´ılem • Propustnost sluˇzby - maximáln´ı datov´ y tok • Ztrátovost paket˚ u - mnoˇzstv´ı zahozen´ ych paket˚ u QoS je zapotˇreb´ı, pokud administrátor potˇrebuje navrhnout s´ıt’, která bude ˇskálovatelná nebo bude podporovat pˇrenos za pomoci v´ıce tˇr´ıd sluˇzeb nebo s podporou kriticky ˇcasov´ ych aplikac´ı. K zajiˇstˇen´ı QoS v s´ıt´ıch jsou dnes realizovány tˇri základn´ı modely: • Sluˇzby typu Best Effort (s maximáln´ım u ´sil´ım) ˇ adn´ - v modelu Best Effort pos´ılaj´ı aplikace data dle vlastn´ıho uváˇzen´ı. Z´ ym zp˚ usobem si nesnaˇz´ı pˇredem vyhradit cestu skrz datovou s´ıt’. S´ıt’ové komponenty se snaˇz´ı data doruˇcit co nejlépe bez ohledu na zpoˇzdˇen´ı ˇci ztrátovost paket˚ u. Pˇr´ıkladem je klasické doruˇcován´ı v IP s´ıt´ıch. • Integrované sluˇzby (Integrated services) - v pˇr´ıpadˇe integrovan´ ych sluˇzeb prob´ıhá pˇrenos dat jin´ ym zp˚ usobem. Aplikace nejdˇr´ıve oznám´ı poˇzadavky na pˇrenos formou poˇzadovan´ ych kvalit (QoS). Poˇc´ıtaˇcová s´ıt’ zjist´ı, zda jsou tyto prostˇredky k dispozici a podle toho se rozhodne, zda pˇrenosu dat vyhov´ı nebo nevyhov´ı. V druhém pˇr´ıpadˇe m˚ uˇze aplikace znovu poˇzádat o prostˇredky s niˇzˇs´ımi nároky na QOS. Jakmile je poˇzadavek s´ıt´ı pˇrijat, docház´ı ze strany s´ıtˇe k informován´ı vˇsech komponent za u ´ˇcelem rezervován´ı dostateˇcného mnoˇzstv´ı prostˇredk˚ u, kter´ y je potˇrebn´ y pro dan´ y pˇrenos. K tomu slouˇz´ı rezervaˇcn´ı protokoly, jako je napˇr´ıklad RSVP (Resource reSerVation Protocol) nebo YESSIR. V´ıce o protokolu RSVP lze dohledat v RFC 2205. • Rozliˇsované sluˇzby (Differentiated Services) - rozd´ıl mezi rozliˇsovan´ ymi a integrovan´ ymi sluˇzbami je pˇredevˇs´ım v tom, ˇze diferencované sluˇzby pˇredem neoznamuj´ı s´ıti poˇzadavky na pˇrenos. Z toho d˚ uvodu nejsou potˇreba ani rezervaˇcn´ı protokoly. Implementace QoS je ˇreˇsena zp˚ usobem, ˇze kaˇzd´ y paket vstupuj´ıc´ı do s´ıtˇe, je na hraniˇcn´ım smˇerovaˇci oznaˇcen znaˇckou, která nadále urˇcuje jeho tˇr´ıdu sluˇzeb v s´ıti. Prvky, pˇres které datov´ y pˇrenos prob´ıhá, tuto znaˇcku pouze ˇctou a dle nastaven´ ych pravidel ˇr´ıd´ı zp˚ usob zpracován´ı paket˚ u. Následuj´ıc´ı text bude zamˇeˇren na diferencované sluˇzby, které budou pˇredmˇetem praktické ˇca´sti diplomové práce. 38


4.5.2

4 ROUTEROS

Klasifikace paket˚ u pomoc´ı TOS a DSCP

Jak jiˇz bylo ˇreˇceno, klasifikace paket˚ u prob´ıhá na hraniˇcn´ıch smˇerovaˇc´ıch a uvnitˇr s´ıtˇe z˚ ustává znaˇcka nezmˇenˇena. V´ ybˇer znaˇcky m˚ uˇze b´ yt proveden napˇr´ıklad na základˇe zdrojové IP adresy, c´ılového IP adresy nebo ˇc´ısla komunikaˇcn´ıho portu protokolu TCP pˇr´ıpadnˇe UDP. Pakety mohou b´ yt oznaˇceny jiˇz pˇr´ımo od aplikace, hraniˇcn´ı smˇerovaˇc pak tyto znaˇcky m˚ uˇze zachovat nebo zmˇenit na znaˇcky, které podporuje pˇrenosová s´ıt’. Zp˚ usob znaˇcen´ı paketu obecnˇe závis´ı na pouˇzité technologii. Znaˇcka m˚ uˇze b´ yt obsaˇzena uvnitˇr hlaviˇcky protokolu nebo pˇridána vnˇe. V pˇr´ıpadˇe pouˇzit´ı diferencovan´ ych sluˇzeb u protokolu IPv4 byla znaˇcka obsaˇzena v poli TOS (Type of Service - RFC 791) a následnˇe byla pˇredefinována na DSCP (Differentiated Services Code Point - RFC 2474). Definice jednotliv´ ych bit˚ u pole TOS a DSCP zobrazuje Obrázek ˇc´ıslo 31.

Obrázek 31: pole TOS vs DSCP V´ yznam bit˚ u TOS: • 0,1,2 (precedence) - znaˇc´ı prioritu paket˚ u • bit 3 - preference n´ızkého zpoˇzdˇen´ı • bit 4 - preference vysoké propustnosti • bit 5 - preference vysoké spolehlivosti • bity 6,7 - rezervované V´ yznam bit˚ u DSCP: • bity 0,1,2,3,4,5,6 (DSCP FIELD) - znaˇc´ı prioritu • bity 6,7 - rezervované Z obrázku i z popisu je patrné, ˇze prvn´ıch 6 bit˚ u vˇzdy urˇcuje priority pˇrenosu a posledn´ı 2 bity z˚ ustávaj´ı rezervované. Toto zaruˇcuje kompatibilitu a pˇrevodn´ı vztah mezi znaˇcen´ım DSCP a TOS precedenc´ı. Tento pˇrevodn´ı vztah je naznaˇcen v tabulce na Obrázku ˇc´ıslo 32.

39


4 ROUTEROS

Obrázek 32: Pˇrevodn´ı vztah mezi TOS a DSCP Praktické nastaven´ı v systému RouterOS lze provést v podkategorii ip firewall mangle. Napˇr´ıklad Manglován´ı“ neboli znaˇckován´ı pravidel pro protokol SSH na základˇe c´ılové IP ” adresy a komunikaˇcn´ıho portu 22 se provád´ı na stranˇe brány následuj´ıc´ım zp˚ usobem: • add action=change-dscp chain=forward disabled=no dst-address=10.110.82.2 dst-port=22 new-dscp=56 passthrough=yes protocol=tcp Na stranˇe klientského hraniˇcn´ıho smˇerovaˇce je pak moˇzné provést znaˇckován´ı bez závislosti na IP adrese (oznaˇc´ı se veˇsker´ y provoz protokolu SSH na portu 22 na vˇsechny servery, které klient pouˇz´ıvá): • add action=change-dscp chain=forward dst-port=22 new-dscp=56 protocol=tcp V tomto pˇr´ıpadˇe hodnota DSCP=56 (111000) odpov´ıdá hodnotˇe TOS=7 (111) a znaˇc´ı nejvyˇsˇs´ı prioritu pˇrenosu. 4.5.3

Typy front syst´ emu RouterOS

Pakety, které procházej´ı skrz router, se pˇri pˇr´ıchodu a zpracován´ı routovac´ım procesem zaˇrazuj´ı do front. Typ této fronty urˇcuje, kter´ y paket bude následnˇe vyhodnocen jako nejv´ıce prioritn´ı a odeslán. RouterOS rozliˇsuje následuj´ıc´ı typy front: • PFIFO a BFIFO - obˇe fronty jsou typu First-In First-Out, coˇz v praxi znamená, ˇze data, která pˇrijdou na router, jsou ve stejném poˇrad´ı i odeslána. Rozd´ıl mezi PFIFO a BFIFO je pouze ten, ˇze jeden pouˇz´ıvá jako mˇernou jednotku paket (PFIFO) a druh´ y byte (BFIFO).

40


4 ROUTEROS

• RED (Random Early Drop) - mechanismus, kter´ y se snaˇz´ı pˇredej´ıt pˇreteˇcen´ı fronty t´ım, ˇze se snaˇz´ı udrˇzet pr˚ umˇernou hodnotu jej´ı velikosti (avqq ). K tomu mu slouˇz´ı dvˇe hodnoty: minimáln´ı(minth ) a maximáln´ı hranice (maxth ). Pokud je pr˚ umˇerná hodnota menˇs´ı neˇz minimáln´ı hranice, router nezahazuje ˇzádné pakety. Pokud je vˇetˇs´ı neˇz maximáln´ı, jsou naopak zahozeny vˇsechny. V pˇr´ıpadˇe, ˇze je velikost fronty v rozsahu (minth ;maxth ) jsou pakety zahazovány s pravdˇepodobnost´ı Pd podle vzorce na Obrázku ˇc´ıslo 33:

Obrázek 33: RED - pravdˇepodobnost zahazován´ı paket˚ u Názornˇe je moˇzné hranice vidˇet na Obrázku ˇc´ıslo 34.

Obrázek 34: RED mechanismus • SFQ (Stochastic Fairness Queuing) - mechanismus, kter´ y funguje na základˇe principu rovnomˇerného pˇridˇelen´ı pˇrenosového pásma otevˇren´ ym sessions. V´ yhoda na velmi pˇret´ıˇzen´ ych linkách je taková, ˇze se vˇzdy dostane na kaˇzdého, kdo chce komunikovat. Naopak nev´ yhodou je, ˇze pásmo nelze pˇridˇelit poˇc´ıtaˇc˚ um na základˇe jejich IP adresy ˇci pouˇzit´ ych port˚ u. • PCQ (Per Connection Queuing) - mechanismus, kter´ y je velmi podobn´ y SFQ a funguje na základˇe hashovac´ıho a Round Robin algoritmu. Pˇridává moˇznost rozliˇsen´ı datového toku dle zdrojové IP adresy, c´ılové IP adresy, zdrojového portu nebo c´ılového portu. Na základˇe zvoleného parametru je datov´ y tok rozdˇelen do nastavitelného poˇctu front, u kter´ ych lze nastavit ˇs´ıˇrku pásma. PCQ se velmi ˇcasto pouˇz´ıvá, pokud chce administrátor vˇsem garantovat stejné pˇrenosové parametry. Jak algoritmus funguje, je podrobnˇe popsáno na: http://wiki.mikrotik.com/wiki/Manual:Queues - PCQ a znázornˇeno na Obrázku ˇc´ıslo 35.

41


4 ROUTEROS

Obrázek 35: PCQ mechanismus 4.5.4

Znaˇ ckov´ an´ı paket˚ u (mangle)

Aby bylo moˇzné paket procházej´ıc´ı routerem zaˇradit do pˇr´ısluˇsného typu fronty, je nutné jej nejprve oznaˇcit. Zaˇrazen´ı do fronty nelze v systému RouterOS nastavit na základˇe znaˇcek TOS (DSCP), ale je nutné paket oznaˇcit unikátn´ı znaˇckou paket-mark pomoc´ı znaˇckovac´ıch pravidel (mangle). Tato znaˇcka slouˇz´ı pouze pro klasifikaci paket˚ u na daném routeru a po opuˇstˇen´ı routeru nen´ı dále v s´ıti viditelná. RouterOS umoˇzn ˇuje oznaˇcen´ı paket˚ u na pˇeti m´ıstech routovac´ıho procesu: • pre-routing - oznaˇc´ı vˇsechny pakety vstupuj´ıc´ı do routeru • forward - oznaˇc´ı pakety, které pouze procházej´ı pˇres router • input - oznaˇc´ı pakety urˇcené pro dan´ y router • output - oznaˇc´ı pakety, které generuje router • post-routing - oznaˇc´ı vˇsechny pakety, které router opouˇstˇej´ı Vizualizace znaˇcen´ı paket˚ u a routovac´ıho procesu ve verzi RouterOS 6.x je vidˇet na Obrázku 36. Oznaˇcen´ı paket˚ u lze provést pˇr´ıkazem: • ip firewall mangle add action=mark-packet chain=forward comment=”pakety znacka dscp 56”dscp=56 new-packet-mark=dscp 56 passthrough=no Tento pˇr´ıkaz zajist´ı oznaˇcen´ı paket˚ u, které procházej´ıc´ı skrz router (chain=forward ) znaˇckou dscp 56 (new-packet-mark=dscp 56 ) a maj´ı hodnotu dscp rovnou 56 (dscp=56 ).

42


4 ROUTEROS

Obrázek 36: Routovac´ı proces - znaˇcen´ı paket˚ u 4.5.5

Queue Simple a Queue Tree

Implementace front v systému RouterOS je zaloˇzena na HTB (Hierarchical Token Bucket). HTB umoˇzn ˇuje vytvoˇren´ı hierarchické struktury front a definici vztah˚ u mezi nimi. Od verze 6.x m˚ uˇze b´ yt tato struktura vytvoˇrena k pouze dvˇema m´ıst˚ um v routovac´ım procesu. Tato m´ısta jsou na obrázku ˇc´ıslo 36 zobrazena pod názvy: GLOBAL HTB a INTERFACE HTB. • GLOBAL HTB - do fronty jsou zaˇrazeny veˇskeré pakety procházej´ı routerem • INTERFACE HTB - do vybrané fronty jsou zaˇrazeny pakety opouˇstˇej´ıc´ı router dan´ ym rozhran´ım Fronty lze v systému RouterOS nakonfigurovat dvˇema zp˚ usoby: • Simple Queue - fronty urˇcené pro základn´ı omezen´ı rychlosti upload/download • Queue Tree - pokroˇcilé fronty pro priorizaci paket˚ u. K pouˇzit´ı je potˇreba znaˇcek mangle. Jednotliv´ ym frontám lze pˇriˇradit prioritu (priority=X ), kde X je v rozmez´ı 1-8 a urˇcuje s jakou prioritou bude daná fronta zpracovávaná, kdyˇz dojde k pˇreplnˇen´ı fronty nadˇrazené (coˇz m˚ uˇze b´ yt GLOBAL fronta, INTERFACE fronta nebo uˇzivatelem vytvoˇrená fronta). Pˇr´ıklad ˇctyˇr front, podˇrazen´ ym INTERFACE frontˇe na rozhran´ı Ether1 je znázornˇen na Obrázku ˇc´ıslo 37. 43


4 ROUTEROS

Obrázek 37: Queue Tree - HTB Konfigurace tˇechto front v systému vypadá následovnˇe: • add limit-at=20M max-limit=20M name=Queue A1 parent=ether1 priority=1 queue=default • add name=Queu PRIO56 packet-mark=dscp 56 parent=Queue A1 priority=1 queue=default • add name=Queue PRIO32 packet-mark=dscp 32 parent=Queue A1 priority=4 queue=default • add name=Queue PRIO08 packet-mark=dscp 08 parent=Queue A1 priority=7 queue=default • add name=Queue ALL packet-mark=all parent=Queue A1 priority=8 queue=default

44

´ 5 IMPLEMENTACE VLASTNÍHO SYSTEMU

5

Implementace vlastn´ıho syst´ emu

5.1

Poˇ zadavky na syst´ em

Pˇred implementac´ı vlastn´ıho systému pro ˇr´ızen´ı a monitorován´ı s´ıt’ového provozu bylo nutné stanovit nˇekolik základn´ıch poˇzadavk˚ u, které bude systém splˇ novat. Tato kritéria byla zvolena na základˇe znalost´ı datové s´ıtˇe obˇcanského sdruˇzen´ı PlzenecNET, o.s. a pˇrizp˚ usobena jej´ım potˇrebám. Mezi tyto poˇzadavky patˇr´ı: • univerzáln´ı monitorovac´ı systém s periodick´ ym sbˇerem dat • platforma Linux a rychl´ y skriptovac´ı jazyk • webové rozhran´ı pro snadné ovládán´ı systému a zobrazen´ı dat • ˇr´ızen´ı datov´ ych tok˚ u pro RouterOS v 6.x a vyˇsˇs´ı • podpora osmivrstvého priorizaˇcn´ıho modelu na páteˇrn´ıch prvc´ıch • moˇznost nastavit pro kaˇzdého uˇzivatele vlastn´ı priorizaˇcn´ı model • grafické zobrazen´ı monitorovan´ ych dat Na základˇe tˇechto poˇzadavk˚ u byly pro tvorbu systému vybrány následuj´ıc´ı prvky a technologie: • monitorovac´ı server: 2x Intel(R) Xeon(TM) CPU 3.00GHz, 8GB RAM, 2x WDC WD20EFRX-68E disk 2TB (RAID 1), základn´ı deska: X6DHR-8G2/X6DHR-TG • operaˇcn´ı systém: Ubuntu 13.10 • skriptovac´ı jazyk: Bash • protokol na vyˇc´ıtán´ı dat: SNMP v1 a v3 • operaˇcn´ı systém pro s´ıt’ové prvky: RouterOS verze 6.x • grafovac´ı nástroj: RRDTool • webov´ y framework: Nette • webov´ y server: Apache/2.4.6 • databázov´ y server: MYSQL 5.5.37 • testovac´ı prvky pro ˇr´ızen´ı datového toku: RB1100, RB433AH, RB433AHL, RB2011L, RB450, 2x MiniPCI R52 5GHz

45


5.2 Serverová ˇca´st systému

5.2

Serverov´ aˇ c´ ast syst´ emu

Základn´ımi prvky serverové ˇca´sti je databáze, skript na vyˇc´ıtán´ı monitorovan´ ych dat, skript na generován´ı pravidel QoS, CRON a webov´ y server, kter´ y slouˇz´ı pro zadáván´ı/zobrazen´ı dat. Na serverové ˇcásti je t´ımto zp˚ usobem implementována dvoj´ı funkcionalita (monitoring s´ıtˇe a generován´ı pravidel pro ˇr´ızen´ı datového toku). Na Obrázku ˇc´ıslo 38 je vidˇet, jak mezi sebou jednotlivé komponenty komunikuj´ı a jak spolupracuj´ı.

Obrázek 38: Schéma

5.2.1

Datab´ azov´ y model

ERA model je uveden v pˇr´ıloze (Pˇr´ılohy - ERA model) a pro funkˇcnost monitorovac´ıho systému jsou d˚ uleˇzité následuj´ıc´ı tabulky: u • vertigo zakaznik - obsahuje seznam zákazn´ık˚ • vertigo sluzba internet - obsahuje seznam sluˇzeb, které jsou pˇriˇrazeny zákazn´ıkovi a nastavuje osmivrstv´ y priorizaˇcn´ı model pro kaˇzdou sluˇzbu • vertigo qos - seznam sluˇzeb, které lze priorizovat • vertigo dohled - seznam router˚ u s jejich IP adresami, které je potˇreba monitorovat

46


5.2.2


Skript pro monitorov´ an´ı s´ıtˇ e

Procesn´ı postup pro u ´spˇeˇsné z´ıskán´ı monitorovan´ ych dat z routeru v s´ıti je následuj´ıc´ı: • zadán´ı routeru pˇres webové rozhran´ı do systému • zápis u ´daj˚ u do databáze (název, IP adresa) do tabulky vertigo dohled • vytvoˇren´ı RRD souboru pro grafován´ı dat • spuˇstˇen´ı skriptu pro monitoring pomoc´ı CRONu • naˇcten´ı vˇsech IP adres router˚ u do skriptu loop.sh • ovˇeˇren´ı dostupnosti router˚ u pomoc´ı ping a uloˇzen´ı hodnoty • pomoc´ı nástroje snmpwalk kontaktován´ı vˇsech monitorovan´ ych router˚ u (SNMP) • uloˇzen´ı z´ıskan´ ych informac´ı do souboru • zpracován´ı souboru pomoc´ı parseru a uloˇzen´ı dat do DB • update grafovac´ıch dat v souboru RRD a vytvoˇren´ı PNG soubor˚ u s grafy • nakop´ırován´ı PNG soubor˚ u do sloˇzky webového serveru • zobrazen´ı z´ıskan´ ych dat pomoc´ı webového serveru O vlastn´ı monitoring se stará skript loop.sh, kter´ y je um´ıstˇen ve sloˇzce ./../parser/bin/. Nastaven´ı globáln´ıch promˇenn´ ych pro tento skript se provád´ı v souboru gobal.conf, kter´ y je na serveru um´ıstˇen v ./../parser/etc/. Zde je moˇzné nastavit následuj´ıc´ı parametry: • mysql: název databáze, uˇzivatelské jméno a heslo pro pˇr´ıstup • dir names: názvy pracovn´ıch adresáˇr˚ u • snmpwalk: verzi SNMP a OID monitorovan´ ych dat • rrdtool: cestu k instalovanému nástroji rrdtool • parallel: poˇcet proces˚ u, které budou kontaktovat routery • ping: poˇcet ICMP paket˚ u pro z´ıskán´ı odezvy a konstantu pro nedostupnost routeru • parser commands: zápis pˇr´ıkazu pro parser (z´ıskán´ı správn´ ych hodnot z v´ ystupu) Po spuˇstˇen´ı skriptu loop.sh. docház´ı k rozdˇelen´ı na nˇekolik podproces˚ u v závislosti na poˇctu monitorovan´ ych zaˇr´ızen´ı. V kaˇzdém podprocesu jsou pak postupnˇe spouˇstˇeny skripty snmpask.sh, parser.sh a graphing.sh. ˇzivotn´ı cyklus je patrn´ y na Obrázku ˇc´ıslo 39.

47



ˇ Obrázek 39: Zivotn´ ı cyklus loop.sh V´ ystupem spuˇstˇen´ı skriptu loop.sh jsou následuj´ıc´ı soubory: • ./../parser/data/new/IP ADRESA - soubor s v´ ystupem snmpwalk • ./../parser/data/graph/IP ADRESA.cpu.rrd - datov´ y soubor zat´ıˇzen´ı CPU • ./../parser/data/graph/IP ADRESA.lat.rrd - datov´ y soubor odezvy routeru • ./../parser/data/png/IP ADRESA.cpu.png - grafick´ y soubor zat´ıˇzen´ı CPU • ./../parser/data/png/IP ADRESA.lat.png - grafick´ y soubor odezvy routeru • ./../www/images/dohled/IP ADRESA.cpu.png - kopie .png na web-serveru • ./../www/images/dohled/IP ADRESA.lat.png - kopie .png na web-serveru

48


5.2.3


Skript pro ˇ r´ızen´ı datov´ eho toku

Procesn´ı postup pro u ´spˇeˇsné nastaven´ı priorizace datov´ ych tok˚ u v s´ıti je následuj´ıc´ı: • Vytvoˇren´ı sluˇzby uˇzivatele pˇres webové rozhran´ı • Zápis u ´daj˚ u do databáze • Zaˇrazen´ı sluˇzeb do prioritn´ıho modelu vybrané sluˇzby (webové rozhran´ı) • Spuˇstˇen´ı skriptu pro vytvoˇren´ı konfiguraˇcn´ıch soubor˚ u pomoc´ı CRONu • Naˇcten´ı IP adres sluˇzeb a vytvoˇren´ı soubor˚ u s pravidly • Upload konfiguraˇcn´ıch soubor˚ u na webov´ y server • Naˇcten´ı souboru do klientsk´ ych zaˇr´ızen´ı a GW O vlastn´ı generován´ı priorizaˇcn´ıch pravidel se stará gos.sh, kter´ y je um´ıstˇen ve sloˇzce ./../qos/bin/. Nastaven´ı globáln´ıch promˇenn´ ych pro tento skript se provád´ı v souboru gobal.conf, kter´ y je na serveru um´ıstˇen v ./../qos/etc/. Zde je moˇzné nastavit následuj´ıc´ı parametry: • mysql: název databáze, uˇzivatelské jméno a heslo pro pˇr´ıstup • dir names: názvy pracovn´ıch adresáˇr˚ u • out file: hlaviˇcky a pˇr´ıpony generovan´ ych soubor˚ u Po spuˇstˇen´ı skriptu qos.sh docház´ı k naˇcten´ı IP adres sluˇzeb, na kter´ ych je potˇreba aplikovat QoS. Dle zadaného prioritn´ıho modelu se vygeneruj´ı pˇr´ısluˇsné pˇr´ıkazy a uloˇz´ı se do souboru pro klientsk´ y router a GW viz Obrázek 40.

Obrázek 40: Pˇr´ıklad vygenerovaného souboru s pravidly pro klientsk´ y router V´ ystupem spuˇstˇen´ı skriptu qos.sh jsou následuj´ıc´ı soubory: • ./../qos/data/IP ADRESA.rsc - soubor s pˇr´ıkazy pro klientsk´ y router • ./../qos/data/gw.rsc - soubor s pˇr´ıkazy pro gateway • ./../Mikrotik/rsc/IP ADRESA.rsc - kopie .rsc na web-serveru • ./../Mikrotik/rsc/gw.rsc - kopie .rsc na web-serveru

49



ˇ Zivotn´ ı cyklus skriptu qos.sh je zobrazen na Obrázku ˇc´ıslo 41.

ˇ Obrázek 41: Zivotn´ ı cyklus qos.sh

5.2.4

CRON

CRON je cyklick´ y plánovaˇc pro systém Linux. Pomoc´ı tohoto nástroje je moˇzné periodicky spouˇstˇet vytvoˇrené skripty ve zvolen´ ych intervalech. Zvolen byl interval jedné minuty pro monitorovac´ı skript a pˇeti minut pro skript na ˇr´ızen´ı datového toku. V obou skriptech jsou implementovány zámky, které zamez´ı dvoj´ımu spuˇstˇen´ı skript˚ u, kdyby z nˇejakého d˚ uvodu nestaˇcily v uvedeném intervalu dobˇehnout do konce. Screen plánovaˇce obsahuje Obrázek ˇc´ıslo 42.

Obrázek 42: Plánován´ı skript˚ u v CRONu

50

5.3 S´ıt’ová ˇca´st systému

5.3


S´ıt’ov´ aˇ c´ ast syst´ emu

Aby bylo moˇzné z router˚ u vyˇc´ıtat poˇzadované informace a bylo moˇzné ˇr´ıdit datov´ y tok v s´ıti, je nutné prvky ˇra´dnˇe nastavit a umoˇznit jim naˇcten´ı potˇrebn´ ych soubor˚ u vygenerovan´ ych na serveru. 5.3.1

P´ ateˇ rn´ı smˇ erovaˇ ce

Z páteˇrn´ıch smˇerovaˇc˚ u je potˇreba z´ıskat monitorovaná data pomoc´ı protokolu SNMP a proto je nutné na routeru aplikovat pˇr´ıkazy, které zajist´ı zabezpeˇcenou komunikaci pomoc´ı SNMP v3: • /snmp community add addresses=0.0.0.0/0 authentication-password=D1pl0mkA encryption-password=D1pl0mkA name=secure security=private • /snmp set enabled=yes trap-community=secure Dalˇs´ım krokem je ˇrádné oznaˇcen´ı paket˚ u dle znaˇcek DSCP, aby je následnˇe bylo moˇzné zaˇradit do fronty. • /ip firewall mangle add action=mark-packet chain=forward comment=”priorita 56” dscp=56 new-packet-mark=dscp 56 passthrough=no • /ip firewall mangle add action=mark-packet chain=forward comment=”priorita 48” dscp=48 new-packet-mark=dscp 48 passthrough=no • /ip firewall mangle add action=mark-packet chain=forward comment=”priorita 40” dscp=40 new-packet-mark=dscp 40 passthrough=no • /ip firewall mangle add action=mark-packet chain=forward comment=”priorita 32” dscp=32 new-packet-mark=dscp 32 passthrough=no • /ip firewall mangle add action=mark-packet chain=forward comment=”priorita 24” dscp=24 new-packet-mark=dscp 24 passthrough=no • /ip firewall mangle add action=mark-packet chain=forward comment=”priorita 16” dscp=16 new-packet-mark=dscp 16 passthrough=no • /ip firewall mangle add action=mark-packet chain=forward comment=”priorita 08” dscp=8 new-packet-mark=dscp 8 passthrough=no • /ip firewall mangle add action=mark-packet chain=forward comment=”priorita other” dscp=0 new-packet-mark=dscp 0 passthrough=no

51

5.3 S´ıt’ová ˇca´st systému


Posledn´ım krokem je vytvoˇren´ı fronty na v´ ystupn´ıch rozhran´ıch dle kapacity, které je rozhran´ı schopné pˇrenést. Na následuj´ıc´ıch ˇra´dc´ıch je uveden pˇr´ıklad konfigurace pro rozhran´ı Ether1 s fyzickou kapacitou 100/100Mbps. Frontu proto nastav´ıme na 95Mbps, aby nedoˇslo k zahlcen´ı linky d´ıky maximáln´ı pˇrenosové kapacitˇe média. • /queue tree add limit-at=95M max-limit=95M name=Queue Ether1 parent=ether1 priority=1 queue=synchronous-default • /queue tree add name=Queue PRIO56 packet-mark=dscp 56 parent=Queue Ether1 priority=1 queue=synchronous-default • /queue tree add name=Queue PRIO48 packet-mark=dscp 48 parent=Queue Ether1 priority=2 queue=synchronous-default • /queue tree add name=Queue PRIO40 packet-mark=dscp 40 parent=Queue Ether1 priority=3 queue=synchronous-default • /queue tree add name=Queue PRIO32 packet-mark=dscp 32 parent=Queue Ether1 priority=4 queue=synchronous-default • /queue tree add name=Queue PRIO24 packet-mark=dscp 24 parent=Queue Ether1 priority=5 queue=synchronous-default • /queue tree add name=Queue PRIO16 packet-mark=dscp 16 parent=Queue Ether1 priority=6 queue=synchronous-default • /queue tree add name=Queue PRIO08 packet-mark=dscp 08 parent=Queue Ether1 priority=7 queue=synchronous-default • /queue tree add name=Queue OTHER packet-mark=dscp 0 parent=Queue Ether1 priority=8 queue=synchronous-default 5.3.2

Klientsk´ e routery a GW

Zaˇr´ızen´ı uˇzivatel˚ u a gateway, která ˇr´ıd´ı provoz do internetu, jsou prvky, v kter´ ych se konfigurace mˇen´ı dynamicky na základˇe zadan´ ych dat v systému. Proto nen´ı moˇzné pravidla nakonfigurovat ruˇcnˇe, ale je potˇreba na zaˇr´ızen´ıch nastavit skript, kter´ y si bude v zadaném intervalu stahovat .rsc soubory ze serveru. T´ımto je zajiˇstˇeno automatické pˇrepisován´ı pravidel na základˇe vstupu uˇzivatele/administrátora.

52

5.4 Uˇzivatelská ˇcást systému


Do konfigurace koncového prvku je potˇreba pˇridat skript (Obrázek 43):

Obrázek 43: Z´ıskán´ı konfigurace pro klientsk´ y router s IP 10.110.82.2 Následnˇe skript zaˇradit do plánovaˇce viz Obrázek 44:

Obrázek 44: Plánovaˇc pro skript na z´ıskán´ı konfigurace pro klientsk´ y router s IP 10.110.82.2 Analogi´ı jsou pak skripty um´ıstˇené do zaˇr´ızen´ı gateway. Pouze m´ısto IP adresy stroje je pouˇzito oznaˇcen´ı gw.rsc.

5.4

Uˇ zivatelsk´ aˇ c´ ast syst´ emu

Uˇzivatelskou ˇca´st systému tvoˇr´ı webov´ y server Apache/2.4.6 a webov´ y framework Nette s podporou PHP5 a moˇznost´ı pˇr´ımého volán´ı SQL dotaz˚ u databáze MYSQL a skript˚ u shellu. Webová aplikace slouˇz´ı pˇredevˇs´ım pro zobrazen´ı monitorovan´ ych dat a zobrazen´ı graf˚ u. D˚ uleˇzitou souˇcást´ı aplikace jsou 2 funkcionality: • Pˇridán´ı/odebrán´ı nového routeru pro dohled • Pˇridán´ı/odebrán´ı nové sluˇzby a nastaven´ı prioritn´ıho modelu 5.4.1

Pˇ rid´ an´ı/odebr´ an´ı nov´ eho routeru pro dohled

Pokud uˇzivatel pˇridá nov´ y router do systému, aplikace uloˇz´ı zadaná data do databáze a následnˇe spust´ı skript new.sh, kter´ y zajist´ı vytvoˇren´ı .rrd soubor˚ u pro dan´ y router ve tvaru IP ADRESA.cpu.rrd a IP ADRESA.lat.rrd a um´ıst´ı je do sloˇzky ./../parser/data/graph. Po pˇridán´ı uˇz jsou informace o monitorovaném routeru obnovovány automaticky na základˇe funkˇcnosti skriptu loop.sh a zvoleného intervalu v plánovaˇci CRON. Pˇri odebrán´ı zaˇr´ızen´ı je volán skript del.sh, kter´ y zajist´ı smazán´ı .rrd soubor˚ u a také graf˚ u ze sloˇzky ./../parser/data/png a ./../www/images/dohled. Jak prob´ıhá pˇridán´ı a odebrán´ı routeru z dohledu pˇres webové rozhran´ı je zobrazeno v pˇr´ıloze ˇc´ıslo 2 (Uˇzivatelsk´ y manuál).

53

´ ´ EM ´ PROVOZU 6 TESTY SYSTEMU V REALN

5.4.2

Pˇ rid´ an´ı/odebr´ an´ı nov´ e sluˇ zby a nastaven´ı prioritn´ıho modelu

Pˇridán´ı nové sluˇzby se poj´ı pouze s pˇr´ım´ ym zápisem zadan´ ych dat do databáze. Následné spouˇstˇen´ı skriptu qos.sh u sluˇzeb, na které chceme QoS aplikovat (na základˇe pˇr´ıznaku QOS=1), zajist´ı vytvoˇren´ı pˇr´ısluˇsn´ ych soubor˚ u .rsc. Pˇri odebrán´ı sluˇzby je volán skript del.sh ze sloˇzky ./../qos/bin/, kter´ y zajist´ı odebrán´ı pˇr´ısluˇsného .rsc souboru z ./../qos/data/ a ./../Mikrotik/rsc/. Pˇridán´ı a odebrán´ı sluˇzby je opˇet zobrazeno v pˇr´ıloze ˇc´ıslo 2 (Uˇzivatelsk´ y manuál).

6 6.1

Testy syst´ emu v re´ aln´ em provozu Monitorov´ an´ı s´ıt’ov´ ych prvk˚ u

Test dohledu páteˇrn´ıch prvk˚ u probˇehl v reálném provozu na páteˇrn´ı s´ıti obˇcanského sdruˇzen´ı PlzenecNET s 80 routery typu Mikrotik RouterBoard (r˚ uzné verze desek i operaˇcn´ıho systému RouterOS). Vˇsechny routery jsou v um´ıstˇeny v OSPF backbone-area. V dobˇe testu pˇres centráln´ı router (kter´ y distribuuje v s´ıti default-route) prob´ıhal provoz cca 200Mbps smˇerem do s´ıtˇe a 50Mbps smˇerem do internetu. Schéma zapojen´ı je patrné z Obrázku ˇc´ıslo 45.

Obrázek 45: Schéma s´ıtˇe pro testován´ı monitoringu

54

6.1 Monitorován´ı s´ıt’ov´ ych prvk˚ u


Pˇri testech monitorovac´ıho procesu bylo provedeno mˇeˇren´ı, které mˇelo za u ´kol zjistit, pˇri jakém poˇctu proces˚ u probˇehne sbˇer ze vˇsech 80 monitorovan´ ych prvk˚ u nejrychleji. Protoˇze byl test provádˇen na serveru, kter´ y disponuje 2 fyzick´ ymi CPU s podporou HT a 2 jádry/CPU, mohl systém pouˇz´ıvat 8 jader. Pˇredpokladem bylo, ˇze pokud by bylo puˇstˇeno 8 proces˚ u, z nichˇz kaˇzd´ y by se snaˇzil z´ıskat data z 10 router˚ u v s´ıti, mˇelo by doj´ıt k nejrychlejˇs´ımu ukonˇcen´ı jednoho ˇzivotn´ıho cyklu skriptu loop.sh.

Obrázek 46: V´ ysledky mˇeˇren´ı pro r˚ uzn´ y poˇcet spuˇstˇen´ ych proces˚ u Mˇeˇren´ı bylo v systému Linux provedeno pomoc´ı nástroje time. Z v´ ysledk˚ u jsou patrné následuj´ıc´ı závˇery: • Nejrychleji probˇehlo naˇcten´ı u ´daj˚ u v pˇr´ıpadˇe, kdy 1 proces obsluhoval 10 router˚ u. Celkovˇe se tedy muselo spustit 8 proces˚ u, coˇz odpov´ıdá oˇcekáván´ı. • V pˇr´ıpadˇe 50 router˚ u na proces je patrné nejkratˇs´ı vyuˇzit´ı CPU (v uˇzivatelském a kernel módu). V´ ysledn´ y ˇcas bˇehu aplikace je vˇsak zdaleka nejhorˇs´ı a to proto, ˇze procesy musely ˇcekat na v´ ystup snmpwalk (I/O operaci). ˇ user a sys je mˇeˇren na • V pˇr´ıpadˇe 1 router/1 proces je patrná vzr˚ ustaj´ıc´ı reˇzie. Cas vˇsech CPU dohromady a proto teoreticky m˚ uˇze b´ yt vˇetˇs´ı neˇz doba bˇehu skriptu real. Po spuˇstˇen´ı skriptu loop.sh doˇslo k naplnˇen´ı databáze (viz Obrázek ˇc´ıslo 47) a zapsán´ı hodnot do .rrd soubor˚ u. Grafick´ y v´ ystup je uveden v pˇr´ıloze ˇc´ıslo 2 (Uˇzivatelsk´ y manuál).

Obrázek 47: Naplnˇen´ı DB pomoc´ı skriptu loop.sh

55


6.2


ˇ ızen´ı datov´ R´ ych tok˚ u

Na ovlivˇ nován´ı datového provozu nebylo moˇzné vyuˇz´ıt infrastrukturu sdruˇzen´ı PlzenecNET. Pro tyto u ´ˇcely byla sestavena testovac´ı s´ıt’, která sv´ ym zapojen´ım korespondovala se zepojen´ım prvk˚ u obˇcanského sdruˇzen´ı (GW, router, OSPF area, bezdrátov´ y spoj). Byly pouˇzity desky RB1100, RB600, RB433AH, RB2011L a RB450. Schéma zapojen´ı je zobrazeno na Obrázku ˇc´ıslo 48.

Obrázek 48: Schéma s´ıtˇe pro testován´ı ˇr´ızen´ı datov´ ych tok˚ u Test byl proveden za následuj´ıc´ı konfigurace: • RB1100 - GW s pravidly pro znaˇckován´ı provozu, NAT • RB600 - OSPF router, kter´ y do s´ıtˇe ˇs´ıˇr´ı default route, bezdrátov´ y bod v AP módu, na rozhran´ı wlan1 nastaven prioritn´ı model s frontou a limitem 20Mbps) • RB433AH - OSPF router, bezdrátov´ y bod v klient módu, OSPF ˇs´ıˇr´ı klientské s´ıtˇe, na rozhran´ı wlan1 nastaven prioritn´ı model s frontou a limitem 20Mbps) • RB450 - klientsk´ y router uˇzivatele Vozák. Sluˇzba BTest zaˇrazena na u ´roveˇ n 48. • RB2011L - klientsk´ y router uˇzivatele Glänzner. Sluˇzba BTest zaˇrazena na u ´roveˇ n 56. • 95.47.186.245 - testovac´ı server (generuje pravidla do .rsc soubor˚ u) • 10.110.82.1 - Bandwidth Test server Kompletn´ı konfiguraˇcn´ı soubory jsou uloˇzeny ve sloˇzce /network na datové disku, kter´ y je pˇr´ılohou diplomové práce. 56



Prvn´ım krokem testu bylo spuˇstˇen´ı BTestu uˇzivatele Vozák se zaˇrazen´ım sluˇzby do priority 48. Jak je patrné z Obrázku ˇc´ıslo 49, uˇzivatel byl schopn´ y vyuˇz´ıt celou pˇrenosovou kapacitu 20Mbps.

Obrázek 49: BTest uˇzivatele Vozák, priorita 48 Následnˇe byl spuˇstˇen BTtest uˇzivatele Glänzner se zaˇrazen´ı sluˇzby do priority 56. Na Obrázku ˇc´ıslo 50 je jasnˇe zˇretelné pˇresunut´ı datového toku na stranu tohoto uˇzivatele.

Obrázek 50: BTest uˇzivatele Glänzner a Vozák, priorita 56 vs 48

57



Na Obrázku ˇc´ıslo 51 je vidˇet zat´ıˇzen´ı front na routerboardu RB600. Je patrné, ˇze datov´ y tok s prioritou 56 je upˇrednostˇ nován pˇred tokem s prioritou 48.

Obrázek 51: RB600 - vyuˇzit´ı front Na posledn´ım Obrázku ˇc´ıslo 52 je zobrazeno vyrovnán´ı datov´ ych tok˚ u obou uˇzivatel˚ u, po pˇrenastaven´ı priority sluˇzby BTest u uˇzivatele Vozák na hodnotu 56.

Obrázek 52: Vyrovnané datové toky uˇzivatel˚ u Vozák a Glänzner (stejná priorita 56)

58

´ ER ˇ 7 ZAV

7

Z´ avˇ er

Teoretickou ˇca´st´ı zadán´ı bylo seznámit se se s´ıt’ov´ ymi prvky od firmy Mikrotik RouterBoard, operaˇcn´ım systémem RouterOS a jeho moˇznostmi pouˇzit´ı v oblasti monitorován´ı s´ıt’ového provozu a ˇr´ızen´ı datov´ ych tok˚ u. Tato ˇca´st byla splnˇena bez vˇetˇs´ıch problém˚ u vzhledem k tomu, ˇze prvky RouterBoard nˇekolik let aktivnˇe pouˇz´ıvám i konfiguruji. Prvky od tohoto v´ yrobce pouˇz´ıvá v aktuáln´ı dobˇe mnoho firem, proto nen´ı ˇza´dn´ ym problémem se s nimi potkat v praxi. Realizace vlastn´ıho systému byla ponˇekud sloˇzitˇejˇs´ı. K u ´spˇeˇsnému zprovoznˇen´ı nestaˇcila znalost prvk˚ u RouterBoard a operaˇcn´ıho systému RouterOS, ale bylo nutné pˇridat i znalosti operaˇcn´ıho systému Linux, skriptován´ı v Bashi, práci s databáz´ı MYSQL a také znalost programován´ı ve frameworku Nette a PHP5. Ze vˇsech tˇechto ˇcinnost´ı bych mezi ty problematiˇctˇejˇs´ı zaˇradil práci s Bashem. Skripty tvoˇr´ı hlavn´ı jádro systému a bylo potˇreba je naprogramovat a nastavit tak, aby nedocházelo ke zbyteˇcné procesorové reˇzii nebo ˇcekán´ı na vstup. Toho bylo doc´ıleno pomoc´ı spuˇstˇen´ı odpov´ıdaj´ıc´ıho mnoˇzstv´ı proces˚ u a na rychlosti skript˚ u se to projevilo v pozitivn´ı m´ıˇre. Pˇresto, ˇze jsou funkce systému RouterOS velmi dobˇre zdokumentovány na webov´ ych stránkách, v´ yrobce uˇz neuvád´ı problémy jednotliv´ ych verz´ı operaˇcn´ıho systému. Dobr´ ym a nutn´ ym zdrojem pro tyto u ´ˇcely poslouˇzilo ISP fórum, kde mnoho lid´ı ˇreˇs´ı velmi podobné záleˇzitosti ohlednˇe skriptován´ı, SNMP a priorizace. Nutno vˇsak podotknout, ˇze ve verzi RouterOS 6.15, na které jsem priorizaci testoval, jsem neobjevil ˇza´dn´ y problém. Opakem bylo testován´ı dohledu pomoc´ı protokolu SNMP, kde napˇr´ıklad verze RouterOS 6.13 nebyla schopná odpovˇedˇet na dotazy serveru pomoc´ı snmpwalk. Téma této práce je v souˇcasné dobˇe velice aktuáln´ı. Stále docház´ı k rozˇsiˇrován´ı datov´ ych s´ıt´ı menˇs´ıch bezdrátov´ ych poskytovatel˚ u a vˇsichni se snaˇz´ı zajistit sv´ ym klient˚ um kvalitn´ı sluˇzby, které by mohly konkurovat profesionáln´ım internetov´ ym poskytovatel˚ um. Hlavn´ım c´ılem práce bylo naprogramovat základn´ı monitorovac´ı systém s podporou ˇr´ızen´ı datov´ ych tok˚ u v s´ıti. Toho se podle mého názoru podaˇrilo doc´ılit. Bez sebemenˇs´ıch problém˚ u by bylo moˇzné systém rozˇs´ıˇrit o dalˇs´ı monitorovaná data, která budou administrátora zaj´ımat a pˇrizp˚ usobit prioritn´ı model poˇzadavk˚ um jakékoliv s´ıtˇe. Po doplnˇen´ı systému o administraˇcn´ı záleˇzitosti a systém plateb, bude systém nasazen v testovac´ım reˇzimu v s´ıti obˇcanského sdruˇzen´ı PlzenecNET, o.s.

59

Literatura [1] Web mikrotik http://www.routerboard.com [2] http://www.routerboard.sk [3] http://www.mikrotik.com [4] http://www.root.cz/clanky/mikrotik-jak-funguji-site/ [5] http://home.zcu.cz/ hliboka/ [6] http://www.earchiv.cz/a96/a632k150.php3 [7] http://www.earchiv.cz/a92/a225c110.php3 [8] http://tools.ietf.org/html/ [9] http://wiki.mikrotik.com/wiki/Manual:API [10] http://www.adminblog.org/2013/06/11/snmp-trap-receiver-with-ubuntu/ [11] http://www.kiv.zcu.cz/ ledvina/Prednasky-PSI-2007/qos-text.pdf [12] https://ispforum.cz/

60

Pˇ r´ılohy Pˇ r´ıloha ˇ c.1 ERA model

Obrázek 53: ERA model

61

Pˇ r´ıloha ˇ c.2 Uˇ zivatelsk´ y manu´ al Cel´ y systém je dostupn´ y na adrese: http://kikimara.plzenec.net/Vertigobeta s uˇzivatelsk´ ym jménem a heslem: diplomka/diplomka. Po u ´spˇeˇsném pˇrihláˇsen´ı se zobraz´ı u ´vodn´ı obrazovka systému (viz Obrázek ˇc´ıslo 54).

Obrázek 54: Pˇrihláˇsen´ı do sytému

Pˇ rid´ an´ı zaˇ r´ızen´ı do dohledu Pˇridán´ı nového zaˇr´ızen´ı do dohledu je moˇzné provést pomoc´ı odkazu Dohled v levé ˇca´sti systému. Po jeho stisknut´ı se vyp´ıˇsou aktuálnˇe dohledovaná zaˇr´ızen´ı. V horn´ı ˇca´sti je odkaz na pˇridán´ı nového zaˇr´ızen´ı: Pˇridat zaˇr´ızen´ı k dohledu (viz Obrázek ˇc´ıslo 55).

Obrázek 55: Pˇridán´ı zaˇr´ızen´ı do sytému

62

Pro u ´spˇeˇsné zaˇrazen´ı mezi monitorované routery je potˇreba vyplnit popis, IP adresu, pˇriˇradit zaˇr´ızen´ı k fyzickému m´ıstu Pop (lze pouˇz´ıt UNKNOWN), vyplnit typ SNMP: MikroTik RouterOS, zvolit funkci: Centráln´ı router a zatrhnout pol´ıˇcko Dohledovat.

Obrázek 56: Pˇridán´ı zaˇr´ızen´ı do sytému - detail

Zobrazen´ı graf˚ u Po cca 15 minutách se u pˇridaného zaˇr´ızen´ı zaˇcnou generovat grafy, ve kter´ ych jsou dostupné hodnoty 25 hodin zpˇetnˇe. Pro zobrazen´ı tˇechto graf˚ u staˇc´ı v sekci dohled kliknout na pˇr´ısluˇsn´ y router. Podrobné informace a grafy se zobraz´ı jako na Obrázku ˇc´ıslo 57.

Obrázek 57: Podrobné informace o monitorovaném zaˇr´ızen´ı

63

Pˇ rid´ an´ı sluˇ zby QoS Pˇridat sluˇzbu, kterou bude následnˇe moˇzné zaˇradit do priorizaˇcn´ıho modelu uˇzivatelsk´ ych sluˇzeb, lze provést v sekci Nastaven´ı QoS po kliknut´ı na odkaz Pˇridat pravidlo QoS v horn´ı ˇca´sti (viz Obrázek ˇc´ıslo 58).

Obrázek 58: Pˇridán´ı sluˇzby QoS Pro u ´spˇeˇsné pˇridán´ı sluˇzby je potˇreba vyplnit protokol (podporováno tcp,udp), rozsah port˚ u (pokud jsou porty stejné, jedná se o jeden port), maximáln´ı u ´roveˇ n zaˇrazen´ı sluˇzby (jak vysoko p˚ ujde sluˇzba zaˇradit v prioritn´ım modelu) a popis sluˇzby (viz Obrázek ˇc´ıslo 59)

Obrázek 59: Pˇridán´ı sluˇzby QoS - detail

64

Pˇ rid´ an´ı uˇ zivatelsk´ e sluˇ zby Pˇridán´ı nové sluˇzby je spojeno se zákazn´ıkem. V sekci Zákazn´ıci proto zvol´ıme jméno uˇzivatele, kterému chceme sluˇzbu pˇridat kliknut´ım na jeho jméno (viz Obrázek ˇc´ıslo 60).

Obrázek 60: Vybrán´ı zákazn´ıka Následnˇe se zobraz´ı informace o uˇzivateli a je potˇreba se pˇrepnout na seznam jeho sluˇzeb pomoc´ı tlaˇc´ıtka Sluˇzby v horn´ı ˇca´sti. Stisknut´ı Pˇridat sluˇzbu internet vyvolá formuláˇr, v kterém je moˇzno zaloˇzit novou sluˇzbu. Po oznaˇcen´ı pol´ıˇcka Nastavit QOS je moˇzné nastavit 7u ´rovn´ı sluˇzeb, které je potˇreba danému uˇzivateli priorizovat (viz obrázek ˇc´ıslo 61).

Obrázek 61: Zaloˇzen´ı sluˇzby internet

65

Zobrazen´ı konfiguraˇ cn´ıch soubor˚ u Po u ´spˇeˇsném zaloˇzen´ı sluˇzby a po spuˇstˇen´ı skript˚ u plánovaˇcem CRON se soubory pro klientská zaˇr´ızen´ı se zadan´ ym prioritn´ım modelem zobraz´ı na adrese: http://kikimara.plzenec.net/MikroTik/rsc/ (viz obrázek ˇc´ıslo 62).

Obrázek 62: Soubory .rsc pˇripravené pro klientské routery V prohl´ıˇzeˇci je moˇzné dan´ y .rsc soubor otevˇr´ıt a zkontrolovat vygenerovaná pravidla. Detail souboru pro GW je zobrazen na obrázku ˇc´ıslo 63.

Obrázek 63: Detail .rsc souboru pro GW

66

Pˇ r´ıloha ˇ c.3 Fotografie z testov´ an´ı

Obrázek 64: Testovac´ı s´ıt’

Obrázek 65: Um´ıstˇen´ı serveru v racku PlzenecNET, o.s.

67

Západočeská univerzita v Plzni Fakulta aplikovaných věd Katedra informatiky

Recommend Documents