ˇ e vysok´e uˇcen´ı technick´e v Praze Cesk´ Fakulta elektrotechnick´a Katedra telekomunikaˇcn´ı techniky
Bakal´aˇrsk´a pr´ace Automatizace konfigurace s´ıt’ov´ ych prvk˚ u pomoc´ı Ansible Miroslav Hudec
Studijn´ı program: Studijn´ı obor: Vedouc´ı pr´ ace:
Komunikace, multim´edia a elektronika S´ıt’ov´e a informaˇcn´ı technologie Ing. Miloˇs Koz´ak, Ph.D.
Praha, Kvˇeten 2016
Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem pˇredloˇzenou pr´ aci vypracoval samostatnˇe a ˇze jsem uvedl veˇsker´e pouˇzit´e informaˇcn´ı zdroje v souladu s Metodick´ ym pokynem o dodrˇzov´an´ı etick´ ych princip˚ u pˇri pˇr´ıpravˇe vysokoˇskolsk´ ych z´ avˇereˇcn´ ych prac´ı.
V Praze dne 27.5.2016 Miroslav Hudec i
Podˇ ekov´ an´ı Chtˇel bych podˇekovat sv´emu vedouc´ımu, Ing. Miloˇsi Koz´akovi, Ph.D. za odborn´e veden´ı, trpˇelivost a ochotu, kterou mi v pr˚ ubˇehu zpracov´an´ı bakal´aˇrsk´e pr´ace vˇenoval.
ii
Abstrakt V d˚ usledku st´ al´eho rozvoje dneˇsn´ıch poˇc´ıtaˇcov´ ych s´ıt´ı a zvyˇsovan´ı n´arok˚ u na nˇe kladen´ ych, je ˇcasto potˇreba zav´ adˇet do produkˇcn´ıho provozu vˇetˇs´ı mnoˇzstv´ı nov´ ych a v´ ykonnˇejˇs´ıch zaˇr´ızen´ı. V souˇcasnosti b´ yvaj´ı tato zaˇr´ızen´ı konfigurov´ana jedno po druh´em, coˇz prodluˇzuje dobu nutnou pro nastaven´ı a t´ım samozˇrejmˇe zvyˇsuje n´aklady na implementaci. C´ılem t´eto pr´ace je zefektivnˇen´ı tohoto postupu navrˇzen´ım ˇreˇsen´ı, kter´e umoˇzn´ı automatizovanou konfiguraci mnoha zaˇr´ızen´ı dle zadan´ ych poˇzadavk˚ u. Zaˇr´ızen´ı by tak bylo moˇzn´e nakonfigurovat bˇehem velmi kr´ atk´e doby a s minim´ aln´ım u ´sil´ım. V r´amci t´eto pr´ace jsem se vˇenoval konfiguraci zaˇr´ızen´ı MikroTik. Konfigurace s´ıt’ov´ ych zaˇr´ızen´ı je realizov´ana pomoc´ı konfiguraˇcn´ıho n´astroje Ansible, kter´ y jsem doplnil o moduly umoˇzn ˇuj´ıc´ı nastaven´ı z´akladn´ıch funkc´ı se zamˇeˇren´ım pˇredevˇs´ım na prvotn´ı konfiguraci souvisej´ıc´ı s nasazen´ım vˇetˇs´ıho poˇctu s´ıt’ov´ ych prvk˚ u do s´ıtˇe.
Kl´ıˇ cov´ a slova Automatizace, konfigurace, s´ıt’ov´e prvky, MikroTik, RouterBOARD, RouterOS, Ansible
iii
Abstract As a result of continuous development of today’s computer networks and the increasing demands imposed on them, it is often necessary to introduce a greater number of new and more efficient networking equipment. As common practise, these devices are configured one at a time, which considerably prolongs the time required for setup, and of course increases the cost of such implementation. This work aims to streamline this process by proposing solution that enables automated configuration of multiple devices according to specified requirements. Automating this process would allow to achieve desired state in very short time with minimal effort. In this work, I dealt with the configuration of MikroTik devices. Configuration of these devices was achieved by using configuration tool Ansible, whose functions have been expanded with additional modules. These modules focus primarily on the initial configuration associated with deploying a larger number of network elements.
Key words Network automation, configuration management, networking, MikroTik, RouterBOARD, RouterOS, Ansible
iv
Seznam pouˇ zit´ ych zkratek API Application Programming Interface 4, 17, 19, 21, 22, 37, 38 ARP Address Resolution Protocol 26 BGP Border Gateway Protocol 11 CDP Cisco Discovery Protocol 17, 28, 38 CLI Command Line Interface (Pˇr´ıkazov´ a ˇr´ adka) 1, 4, 12, 13, 17, 22, 25 DHCP Dynamic Host Configuration Protocol 5, 14, 18, 19, 21, 25, 32, 38 DNS Domain Name System 14, 25, 32, 38 DRP Disaster Recovery Plan 2 EIGRP Enhanced Interior Gateway Routing Protocol 11 IDPS Intrusion Detection and Prevention System 5 IP Internet Protocol 8, 11, 18 ISP Internet Service Provider (Poskytovatel Internetu) 1, 10, 16 ITIL Information Technology Infrastructure Library 2 JSON JavaScript Object Notation 24, 28 LAN Local Area Network 18 MNDP MikroTik Neighbor Discovery Protokol 17 NAT Network Address Translation 18, 26 OSPF Open Shortest Path First 11 RIP Router Information Protocol 11, 26, 33, 38 RM ISO/OSI Referenˇcn´ı model ISO/OSI 10, 12, 18 SDN Software Defined Network 5 SNMP Simple Network Management Protocol 3, 4, 13 SOHO Small Office / Home Office 13 SPOF Single Point of Failure 7, 8 SSH Secure Shell 14, 19 TCP Transmission Control Protocol 8, 22 v
Seznam pouˇzit´ ych zkratek TFTP Trivial File Transfer Protocol 14 UDP User Datagram Protocol 8 VLAN Virtual Local Area Network 11 WAN Wide Area Network 18 YAML Yet Another Markup Language 15 YANG Yet Another Next Generation 4
vi
Obsah Abstrakt
iii
Seznam pouˇ zit´ ych zkratek
v
´ 1 Uvod 1.1 Spr´ ava modern´ıch s´ıt´ı . . . . . . . . . 1.1.1 Centralizovan´ a spr´ ava . . . . . 1.1.2 Automatizace poˇc´ıtaˇcov´ ych s´ıt´ı 1.2 Zamˇeˇren´ı a c´ıl pr´ ace . . . . . . . . . .
. . . .
1 1 2 4 5
. . . . . . . . . . . .
7 7 7 10 11 13 13 14 14 16 16 17 19
. . . . . . . . . . . . .
21 21 22 24 24 25 26 28 28 30 32 32 32 33
4 Z´ avˇ er 4.1 Naplnˇen´ı stanoven´ ych c´ıl˚ u . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37 38
Seznam pouˇ zit´ ych zdroj˚ u
ix
. . . .
. . . .
. . . .
. . . .
. . . .
2 Anal´ yza 2.1 Z´ akladn´ı pojmy . . . . . . . . . . . . . . . . . . 2.1.1 Charakteristiky poˇc´ıtaˇcov´e s´ıtˇe . . . . . 2.1.2 Z´ akladn´ı s´ıt’ov´e prvky . . . . . . . . . . 2.2 Moˇznosti konfigurace s´ıt’ov´ ych zaˇr´ızen´ı . . . . . 2.3 Ansible . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Co je Ansible . . . . . . . . . . . . . . . 2.3.2 Historie Ansiblu . . . . . . . . . . . . . 2.3.3 Jak Ansible funguje . . . . . . . . . . . 2.4 MikroTik . . . . . . . . . . . . . . . . . . . . . 2.4.1 Moˇznosti konfigurace zaˇr´ızen´ı MikroTik 2.5 Z´ akladn´ı poˇzadavky na konfiguraci . . . . . . . 2.6 Shrnut´ı a vyhodnocen´ı poznatk˚ u . . . . . . . . 3 Realizace 3.1 MikroTik API . . . . . . . . . . . . . . . 3.2 Z´ akladn´ı funkce . . . . . . . . . . . . . . 3.3 Moduly Ansible . . . . . . . . . . . . . . 3.3.1 Spoleˇcn´e znaky Ansible modul˚ u. 3.3.2 Popis jednotliv´ ych modul˚ u . . . 3.4 Prvotn´ı konfigurace . . . . . . . . . . . . 3.5 Invent´ aˇr . . . . . . . . . . . . . . . . . . 3.5.1 Dynamick´ y invent´ aˇr . . . . . . . 3.6 Ansible Playbook . . . . . . . . . . . . . 3.7 Pˇr´ıklady pouˇzit´ı . . . . . . . . . . . . . 3.7.1 Testovac´ı pracoviˇstˇe . . . . . . . 3.7.2 Pˇr´ıklad 1 . . . . . . . . . . . . . 3.8 Pˇr´ıklad 2 . . . . . . . . . . . . . . . . .
Seznam pˇ r´ıloh
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
. . . .
. . . . . . . . . . . .
. . . . . . . . . . . . .
x vii
Kapitola 1
´ Uvod Rozvoj datov´ ych s´ıt´ı v souˇcasn´e dobˇe prob´ıh´a velmi rychl´ ym tempem. Popt´avka po sluˇzb´ach pˇrenosu dat st´ ale nar˚ ust´ a a datov´e s´ıtˇe nav´ıc pˇreb´ıraj´ı role mnoha dalˇs´ıch s´ıt´ı, jako jsou napˇr´ıklad hlasov´e ˇci televizn´ı s´ıtˇe. Zvyˇsuj´ıc´ı se poˇzadavky na propustnost a spolehlivost datov´ ych s´ıt´ı spolu s rostouc´ım poˇctem internetov´ ych pˇr´ıpojek u ´st´ı v potˇrebu nasazovat velk´e poˇcty s´ıt’ov´ ych zaˇr´ızen´ı pˇredevˇs´ım do pˇr´ıstupov´e ˇc´asti s´ıtˇe. Nasazov´an´ı vˇetˇs´ıho poˇctu s´ıt’ov´ ych zaˇr´ızen´ı s sebou vˇsak pˇrin´ aˇs´ı mnoho v´ yzev. Nov´a zaˇr´ızen´ı je potˇreba spr´avnˇe nastavit tak, aby odpov´ıdala poˇzadavk˚ um dan´e s´ıtˇe a um´ıstˇen´ı konkr´etn´ıho prvku v topologii s´ıtˇe. D´ale je pak potˇreba tato zaˇr´ızen´ı dohledovat, aby bylo moˇzn´e odhalit pˇr´ıpadn´e poruchy ˇci abnormality v s´ıt’ov´em provozu. V neposledn´ı ˇradˇe je tˇreba umoˇznit vzd´alenou spr´avu zaˇr´ızen´ı tak, aby bylo moˇzn´e prov´ adˇet zmˇeny v konfiguraci kaˇzd´eho zaˇr´ızen´ı v n´avaznosti na aktu´aln´ı poˇzadavky bez nutnosti fyzick´eho pˇr´ıstupu k zaˇr´ızen´ı. At’ uˇz se jedn´ a o nasazov´ an´ı aktivn´ıch prvk˚ u v s´ıti Internet Service Provider (Poskytovatel Internetu) (ISP) ˇci v rozs´ ahlejˇs´ı podnikov´e s´ıti, vˇzdy plat´ı, ˇze ˇcas jsou pen´ıze. A ekonomick´e hledisko b´ yv´ a ˇcasto aˇz na prvn´ım m´ıstˇe. Je proto velmi d˚ uleˇzit´e cel´ y proces implementace nov´ ych zaˇr´ızen´ı do provozu co nejv´ıce zefektivnit, a to jak po str´ance potˇrebn´eho ˇcasu, tak n´arok˚ u na lidsk´e zdroje. V ide´ aln´ım pˇr´ıpadˇe by tak mˇel cel´ y proces implementace obstarat jeden technik v co nejkratˇs´ım ˇcase a samozˇrejmˇe bezchybnˇe. K naplnˇen´ı takov´ ych poˇzadavk˚ u je vˇsak potˇreba nal´ezt syst´em pro usnadnˇen´ı a automatizaci cel´eho procesu.
1.1
Spr´ ava modern´ıch s´ıt´ı
Korektnˇe definovan´ a a aplikovan´ a spr´ava poˇc´ıtaˇcov´ ych s´ıt´ı pˇredstavuje fundament´aln´ı pˇredpoklad pro jejich hladk´ y a bezchybn´ y provoz. Navzdory svoj´ı d˚ uleˇzitosti a n´arok˚ um kladen´ ym na dneˇsn´ı s´ıtˇe vˇsak ˇcasto administr´atoˇri tˇechto s´ıt´ı spol´ehaj´ı na pomˇernˇe z´akladn´ı a pˇr´ımoˇcar´e postupy: Zmˇeny v konfigurac´ıch jednotliv´ ych s´ıt’ov´ ych prvk˚ u jsou pˇrev´aˇznˇe prov´adˇeny ruˇcnˇe pomoc´ı zastaral´ ych low-level n´astroj˚ u, jako je Command Line Interface
1
´ KAPITOLA 1. UVOD (Pˇr´ıkazov´ a ˇr´ adka) (CLI). Takov´ yto pˇr´ıstup, kter´ y vyˇzaduje pˇripojen´ı se zvl´aˇst’ ke kaˇzd´emu zaˇr´ızen´ı je vˇsak velmi ˇcasovˇe n´ aroˇcn´ y. Nav´ıc ve svˇetˇe, kde jsou s´ıtˇe st´ale rozlehlejˇs´ı, komplexnˇejˇs´ı a dynamiˇctˇejˇs´ı roste i riziko lidsk´e chyby. Takov´ato chyba v konfiguraci byt’ jedin´eho zaˇr´ızen´ı pˇritom m˚ uˇze m´ıt fat´ aln´ı dopady na provoz cel´e s´ıtˇe. Prvotn´ı pokusy o lepˇs´ı zvl´ adnut´ı obsluhy s´ıt’ov´ ych prvk˚ u vzeˇsly pr´avˇe od s´ıt’ov´ ych administr´ator˚ u, kteˇr´ı sepisovali a spouˇstˇeli nejr˚ uznˇejˇs´ı skripty. Tyto skripty se vˇsak postupem ˇcasu st´avaly st´ ale sofistikovanˇejˇs´ı, pˇriˇcemˇz kaˇzd´ y administr´ator udrˇzoval sv˚ uj vlastn´ı ”arzen´al”. Takov´eto skripty maj´ı vˇsak bohuˇzel velmi specifick´e zamˇeˇren´ı a vyˇzaduj´ı vysokou u ´roveˇ n znalost´ı pro proveden´ı sloˇzitˇejˇs´ıch u ´kon˚ u a zamezen´ı nechtˇen´ ym vedlejˇs´ım u ´ˇcink˚ um. Sestaven´ı takov´eho skriptu nav´ıc vyˇzaduje znaˇcnou odbornost a dlouh´e testov´an´ı metodou pokus-omyl. Dalˇs´ım nezbytn´ ym pˇredpokladem pro provoz poˇc´ıtaˇcov´e s´ıtˇe je spr´ava dokumentace, pˇredevˇs´ım udrˇzov´an´ı z´ aznam˚ u o stavu jednotliv´ ych prvk˚ u a jejich konfigurac´ı. Dojde-li napˇr´ıklad k poruˇse zaˇr´ızen´ı, je tˇreba zajistit, aby po opravˇe poruchy bylo moˇzn´e uv´est zaˇr´ızen´ı do p˚ uvodn´ıho stavu v co nejkratˇs´ım ˇcase. Za t´ımto u ´ˇcelem bylo vyvinuto mnoho softwarov´ ych ˇreˇsen´ı, kter´ a umoˇzn ˇuj´ı automatick´e z´alohov´an´ı konfigurac´ı a jejich n´aslednou obnovu v pˇr´ıpadˇe poruchy. Pro ochranu podnikov´e IT infrastruktury by tak´e mˇel existovat Disaster Recovery Plan (DRP), kter´ y pˇresnˇe definuje procesn´ı postupy pro pˇr´ıpad hav´arie.
1.1.1
Centralizovan´ a spr´ ava
Aby bylo moˇzn´e naplnit veˇsker´e poˇzadavky na provoz s´ıtˇe, je ˇcasto nutn´e celou jej´ı spr´avu centralizovat. Jsou-li veˇsker´e u ´daje o stavu s´ıtˇe dostupn´e z jednoho kontroln´ıho m´ısta, je mnohem snazˇs´ı dohl´ıˇzet na provoz, odhalit pˇr´ıpadn´e poruchy a prov´adˇet zmˇeny v konfiguraci s´ıtˇe s ohledem na vˇsechny d˚ usledky. Je velmi d˚ uleˇzit´e, aby kaˇzd´a zmˇena byla provedena s ohledem na vˇsechny n´ avaznosti a n´ aslednˇe ˇr´ adnˇe zdokumentov´ana. Prov´adˇen´ı zmˇen v s´ıti tak ˇr´ıkaj´ıc ad hoc, napˇr´ıklad na z´ akladˇe poˇzadavk˚ u uˇzivatel˚ u bez jejich ˇr´adn´ ych zaveden´ı do dokumentace s´ıtˇe m˚ uˇze v´est k nestandardn´ımu chov´an´ı cel´e s´ıtˇe. Toto pak zvl´aˇstˇe plat´ı v pˇr´ıpadˇe, ˇze o s´ıt’ se star´ a v´ıce administr´ ator˚ u. Aby se zamezilo takov´ ymto moˇzn´ ym nedopatˇren´ım, mˇela by b´ yt v r´amci spr´ avy s´ıtˇe zavedena a striktnˇe dodrˇzov´ana metodika procesn´ıho ˇr´ızen´ı. Jednou z takov´ ychto standardizovan´ ych metodik je napˇr´ıklad Information Technology Infrastructure Library (ITIL). Jedn´ a se o sadu praktik pro spr´avu IT sluˇzeb, kter´e se zamˇeˇruj´ı na sladˇen´ı IT s potˇrebami podniku [1]. Takov´ ato metodika by pot´e mˇela b´ yt souˇc´ast´ı ˇsirˇs´ı podnikov´e politiky. Monitoring poˇ c´ıtaˇ cov´ e s´ıtˇ e: Monitoringem poˇc´ıtaˇcov´e s´ıtˇe se rozum´ı nepˇretrˇzit´e sledov´an´ı stavu zaˇr´ızen´ı v s´ıti, kter´e umoˇzn´ı odhalit selh´avaj´ıc´ı komponenty s´ıtˇe a upozornit na tuto skuteˇcnost administr´ atora s´ıtˇe. Lze tak jednak pˇredej´ıt moˇzn´ ym v´ ypadk˚ um v provozu ˇci urˇcit kde k poruˇse doˇslo a znaˇcnˇe tak zkr´atit ˇcas potˇrebn´ y na jej´ı odstranˇen´ı. Jedn´ım z 2
´ KAPITOLA 1. UVOD jednoduˇsˇs´ıch pˇr´ıstup˚ u k t´eto problematice je centr´aln´ı shromaˇzd’ov´an´ı log˚ u z jednotliv´ ych zaˇr´ızen´ı. Kaˇzd´e zaˇr´ızen´ı vˇetˇsinou ukl´ad´a informace o sv´em stavu a proveden´ ych u ´konech do souboru oznaˇcovan´eho jako log. Tyto logy lze pak shromaˇzd’ovat na jednom centr´aln´ım m´ıstˇe, kter´ ym b´ yv´ a log server. Logy na tomto serveru jsou pot´e automaticky vyhodnoceny a na z´akladˇe jejich z´ avaˇznosti je provedena pˇreddefinovan´a akce, jako napˇr´ıklad upozornˇen´ı administr´ atora prostˇrednictv´ım e-mailu ˇci SMS. Dalˇs´ı moˇznost´ı pro z´ısk´ av´ an´ı informac´ı o stavu zaˇr´ızen´ı je implementace Simple Network Management Protocol (SNMP). Jedn´ a se o protokol navrˇzen´ y pro shromaˇzd’ov´an´ı a organizaci informac´ı ze spravovan´ ych zaˇr´ızen´ı. Vˇetˇsina dneˇsn´ıch zaˇr´ızen´ı, jako jsou smˇerovaˇce, pˇrep´ınaˇce, servery, koncov´e stanice ˇci tisk´ arny podporuje tento protokol, SNMP je proto hojnˇe vyuˇz´ıv´ an v syst´emech s´ıt’ov´e spr´ avy a jedn´ a se de facto o standard. Informace ze zaˇr´ızen´ı jsou zde prezentov´ ana pomoc´ı promˇenn´ ych, kter´e mohou b´ yt vyhodnocov´any prostˇrednictv´ım softwaru, kter´ y je spuˇstˇen na SNMP serveru. Hodnoty jako napˇr´ıklad aktu´aln´ı vyt´ıˇzen´ı procesoru ˇci ˇs´ıˇrka vyuˇzit´eho p´ asma lze n´ aslednˇe vykreslit do graf˚ u, coˇz poskytuje administr´atorovi dobr´ y pˇrehled o stavu jednotliv´ ych zaˇr´ızen´ı. Stejnˇe jako v pˇredchoz´ım pˇr´ıpadˇe je i zde ˇz´adouc´ı pˇreddefinovat akce pro kl´ıˇcov´e hodnoty, pˇri jejichˇz dosaˇzen´ı dojde k informov´an´ı administr´ atora. Pouˇzit´ı SNMP tak administr´ator˚ um poskytuje mnohem sofistikovanˇejˇs´ı a flexibilnˇejˇs´ı ˇreˇsen´ı neˇz prost´e shromaˇzd’ov´an´ı log˚ u. Dalˇs´ı v´ yhodou tohoto ˇreˇsen´ı je tak´e to, ˇze nˇekter´a zaˇr´ızen´ı umoˇzn ˇuj´ı i zmˇenu svoj´ı konfigurace prostˇrednictv´ım SNMP. Jednou z oblast´ı monitorov´ an´ı s´ıtˇe je tak´e sledov´an´ı samotn´eho s´ıt’ov´eho provozu. Informace o provozu smˇerem do a ze s´ıtˇe administr´ator˚ um vˇetˇsinou zprostˇredkuje smˇerovaˇc ˇci firewall a o stavu zaˇr´ızen´ı v s´ıti jsou informov´ani d´ıky SNMP. Nˇekdy je ovˇsem vhodn´e monitorovat i provoz uvnitˇr lok´ aln´ı s´ıtˇe, coˇz poskytuje administr´ator˚ um mnoho dalˇs´ıch informac´ı za u ´ˇcelem optimalizace s´ıtˇe ˇci odhalen´ı pˇr´ıpadn´ ych chyb. Monitorov´an´ı vnitˇrn´ıho provozu nav´ıc zvyˇsuje bezpeˇcnost, protoˇze d´ıky nˇemu lze odhalit nestandardn´ı s´ıt’ov´ y provoz, kter´ y by mohl pˇredstavovat potenci´ aln´ı rizika. Za t´ımto u ´ˇcelem se vyuˇz´ıvaj´ı takzvan´e s´ıt’ov´e sondy, kter´e shromaˇzd’uj´ı a analyzuj´ı veˇsker´ y s´ıt’ov´ y provoz. Z´ıskan´e statistiky pak poskytuj´ı informace napˇr´ıklad o tom, jak´ y druh provozu ve kter´ ych ˇc´astech s´ıtˇe a v jakou dobu proch´az´ı. Takov´ ych u ´daj˚ u lze vyuˇz´ıt pro potˇrebn´e zmˇeny v konfiguraci jednotliv´ ych aktivn´ıch prvk˚ u pro optimalizaci provozu. S´ıt’ov´e sondy jsou tak´e schopny na z´akladˇe behavior´aln´ı anal´ yzy odhalit odchylky od standardn´ıho provozu a upozornit na nˇe administr´atora s´ıtˇe. Centr´ aln´ı spr´ ava konfigurace: K provozov´an´ı poˇc´ıtaˇcov´e s´ıtˇe neodmyslitelnˇe patˇr´ı spr´ava konfigurac´ı s´ıt’ov´ ych prvk˚ u. Nastaven´ı s´ıt’ov´ ych zaˇr´ızen´ı je ve vˇetˇsinˇe pˇr´ıpad˚ u reprezentov´ano souborem obsahuj´ıc´ım konfiguraˇcn´ı pˇr´ıkazy. Existuje mnoho moˇznost´ı, jak tyto konfigurace z´alohovat a v pˇr´ıpadˇe potˇreby obnovit do dˇr´ıvˇejˇs´ıho stavu. Nejz´akladnˇejˇs´ım, ale nezˇr´ıdka vyuˇz´ıvan´ ym zp˚ usobem je prost´e kop´ırov´an´ı textu z pˇr´ıkazov´e ˇr´adky a n´asledn´e uloˇzen´ı do textov´eho souboru. Ponˇekud lepˇs´ım ˇreˇsen´ım je pˇr´ımo kop´ırov´an´ı konfiguraˇcn´ıho souboru napˇr´ıklad na FTP server. Pro rozlehlejˇs´ı s´ıtˇe s velk´ ym poˇctem aktivn´ıch prvk˚ u je vˇsak velmi 3
´ KAPITOLA 1. UVOD nev´ yhodn´e, aby tyto z´ alohy byly prov´adˇeny ruˇcnˇe. Za t´ımto u ´ˇcelem existuje ˇrada komerˇcn´ıch n´astroj˚ u, jejichˇz u ´ˇcelem je usnadnit a urychlit proces z´alohy a obnovy. Jedn´a se o aplikace, kter´e se periodicky pˇripojuj´ı k s´ıt’ov´ ym zaˇr´ızen´ım a kontroluj´ı stav jejich konfigurace, prov´adˇej´ı jej´ı z´ alohu a v pˇr´ıpadˇe potˇreby jsou schopny na dan´em zaˇr´ızen´ı obnovit nastaven´ı do dˇr´ıvˇejˇs´ıho stavu. Prov´adˇen´ı z´ aloh konfigurac´ı s´ıt’ov´ ych prvk˚ u je d˚ uleˇzit´e z mnoha d˚ uvod˚ u. T´ım prvn´ım je samozˇrejmˇe snaha minimalizovat dobu v´ ypadku s´ıtˇe, dojde-li k poruˇse zaˇr´ızen´ı. V takov´em pˇr´ıpadˇe je nejrychlejˇs´ım ˇreˇsen´ım pˇripojit na m´ısto p˚ uvodn´ıho zaˇr´ızen´ı zaˇr´ızen´ı nov´e a nahr´ at do nˇej konfiguraci ze z´ alohy. Stejnˇe tak v pˇr´ıpadˇe, ˇze s´ıt’ zaˇcne vykazovat nestandardn´ı chov´an´ı, m˚ uˇze b´ yt velmi rychl´ ym a efektivn´ım ˇreˇsen´ım probl´emu vr´acen´ı se do stavu, kdy vˇse fungovalo korektnˇe. T´emˇeˇr vˇzdy totiˇz plat´ı, ˇze pokud nˇeco pˇrestane fungovat, pˇredch´azela tomu nˇejak´ a zmˇena. To je tak´e dalˇs´ım d˚ uvodem, proˇc pravidelnˇe z´alohovat konfigurace aktivn´ıch prvk˚ u. Je-li napl´ anovan´ a jak´ akoliv zmˇena v konfiguraci s´ıtˇe, proveden´ı t´eto zmˇeny by vˇzdy mˇela pˇredch´azet z´ aloha souˇcasn´eho stavu. I pˇri sebevˇetˇs´ı snaze s´ıt’ov´ ych administr´ator˚ u poˇc´ıtat se vˇsemi moˇzn´ ymi n´ asledky pl´ anovan´e zmˇeny se vˇzdy m˚ uˇze objevit nˇeco, s ˇc´ım se nepoˇc´ıtalo. V takov´em pˇr´ıpadˇe je nezbytn´e v prvn´ı ˇradˇe obnovit provozuschopnost s´ıtˇe, a aˇz n´aslednˇe se vˇenovat zjiˇst’ov´ an´ı co zp˚ usobilo dan´ y probl´em a jak jej pro pˇr´ıˇstˇe odstranit.
1.1.2
Automatizace poˇ c´ıtaˇ cov´ ych s´ıt´ı
Hlavn´ım d˚ uvodem pro automatizov´an´ı s´ıt´ı je odlehˇcen´ı z´atˇeˇze administr´ator˚ um, kteˇr´ı jsou jinak ˇcasto nuceni tr´ avit mnoho ˇcasu pˇri plnˇen´ı rutinn´ıch a opakuj´ıc´ıch se u ´kon˚ u. Administr´atoˇri pak mohou vˇenovat v´ıce pozornosti pl´anov´an´ı rozvoje st´avaj´ıc´ı infrastruktury a jej´ıho zefektivnˇen´ı. Ve v´ ysledku je pak d´ıky automatizaci moˇzn´e sn´ıˇzit poˇcet administr´ator˚ u, coˇz vede ke znaˇcn´emu sn´ıˇzen´ı prostˇredk˚ u nezbytn´ ych pro provoz IT infrastruktury. Pojmem automatizace poˇc´ıtaˇcov´e s´ıtˇe se rozum´ı pouˇzit´ı aplikac´ı a n´astroj˚ u, kter´e jsou schopny do jist´e m´ıry samostatnˇe prov´ adˇet komplexn´ı, zdlouhav´e ˇci opakuj´ıc´ı se procesy pˇri spr´avˇe poˇc´ıtaˇcov´e s´ıtˇe at’ s ˇz´ adnou, ˇci minim´ aln´ı interakc´ı ze strany administr´atora s´ıtˇe. Automatizovan´e u ´koly mohou prov´ adˇet jak jednoduch´e a jedno´ uˇcelov´e skripty, tak robustn´ı automatizaˇcn´ı n´astroje. S´ıt’ov´a automatizace vˇsak nen´ı pouze skriptov´an´ı [2]. Zde jsou nˇekter´e typy s´ıt’ov´e automatizace: Skriptovˇ e-orientovan´ a automatizace: Administr´atoˇri p´ıˇs´ı skripty za u ´ˇcelem automatizace zmˇeny konfigurace s´ıt’ov´ ych zaˇr´ızen´ı. Za t´ımto u ´ˇcelem se vyuˇz´ıv´a napˇr´ıklad restful Application Programming Interface (API), YANG, NETCONF, ˇci jednoduch´ ych skript˚ u ovl´adaj´ıc´ıch CLI nebo SNMP. Tyto skripty jsou nejˇcastˇeji v jazyc´ıch Python, Puppet ˇci Chef, ale lze samozˇrejmˇe pouˇz´ıt i jin´e jazyky. Inteligence je pak obsaˇzena v tˇechto skriptech. Mnoho s´ıt’ov´ ych prvk˚ u tak´e podporuje API, kter´e umoˇzn ˇuj´ı l´epe algoritmizovat a uchopit pˇr´ıstup k zaˇr´ızen´ım. Automatick´ a konfigurace a provisioning: Nˇekter´e automatizaˇcn´ı schopnosti jsou pˇr´ımo 4
´ KAPITOLA 1. UVOD vestavˇeny do zaˇr´ızen´ı. Mnoho z nich je dnes povaˇzov´ano za standard, avˇsak zaˇc´ınaly jako jako automatizaˇcn´ı n´ astroje. Typick´ ym pˇr´ıkladem m˚ uˇze b´ yt Dynamic Host Configuration Protocol (DHCP) server, d´ıky kter´emu nen´ı tˇreba nastavovat statick´e adresy na klientsk´ ych zaˇr´ızen´ıch. Jedn´ a se o tak z´ akladn´ı sluˇzbu, ˇze na ni ani nen´ı pohl´ıˇzeno jako na automatizaci, avˇsak stala se tak fundament´ aln´ı, ˇze si dnes bez n´ı deployment koncov´ ych zaˇr´ızen´ı lze jen tˇeˇzko pˇredstavit. Automatick´ y provoz a ˇ r´ızen´ı: Automatizace pom´ah´a zejm´ena s kaˇzdodenn´ımi u ´koly, jako je reagov´an´ı na ud´ alosti a n´ asledn´e rekonfiguraci zaˇr´ızen´ı. Jak´ ykoliv u ´kol z kategorie ”prozkoumat a reagovat”spad´ a sem. Do t´eto kategorie mohou spadat napˇr´ıklad s´ıt’ov´e bezpeˇcnostn´ı syst´emy jako Intrusion Detection and Prevention System (IDPS), kter´e funguj´ı jako automatizovan´e senzory s´ıt’ov´eho provozu schopn´e prov´est adekv´atn´ı akci na z´akladˇe povahy provozu, napˇr´ıklad ukonˇcit spojen´ı. Orchestrace a virtualizace: Dalˇs´ı u ´rovn´ı automatizovan´ ych s´ıt´ı je koncept tzv. softwarovˇe definovan´ ych s´ıt´ı - Software Defined Network (SDN). Jedn´a se o koncept virtualizace kompletn´ı s´ıt’ov´e infrastruktury a jej´ı koordinovan´e spolupr´ace. Existuje mnoho definic SDN, avˇsak v z´ akladu se jedn´ a o konceptu´aln´ı oddˇelen´ı data-plane a control-plane. Toto rozdˇelen´ı poskytuje ˇsirok´e moˇznosti konfigurace jednotliv´ ych prvk˚ u. To v z´avislosti na schopnostech takov´eho syst´emu m˚ uˇze v´est k aplikacemi ˇr´ızen´ ym s´ıt´ım, coˇz znamen´a, ˇze lze nahr´avat aplikace poskytuj´ıc´ı s´ıt’ov´e funkce do ovladaˇce (controlleru) a poskytovat tyto funkce v r´amci cel´e s´ıtˇe. Pˇred pˇr´ıchodem SDN museli ˇclenov´e IT oddˇelen´ı nasadit nov´ y firmware ˇci dokonce nov´ y hardware, aby mohli poskytovat funkce. S pˇr´ıchodem SDN m˚ uˇze b´ yt chov´an´ı s´ıtˇe ˇr´ızeno aplikacemi. Spoleˇcnost Hewlett-Packard kupˇr´ıkladu provozuje SDN App Store, kde poskytuje aplikace ˇr´ıd´ıc´ı s´ıt’ov´ a zaˇr´ızen´ı podporuj´ıc´ı OpenFlow. Existuj´ı tak´e opensourcov´e SDN syst´emy, kter´e jsou modul´ arn´ı a jejich schopnosti lze rozˇsiˇrovat formou aplikac´ı. Softwarovˇe definovan´ a s´ıt’ je pak schopna automaticky pˇrizp˚ usobovat sv´e chov´an´ı aktu´aln´ım poˇzadavk˚ um v re´aln´em ˇcase a poskytovat tak vyˇsˇs´ı kvalitu sluˇzeb koncov´ ym uˇzivatel˚ um. Politikou ˇ r´ızen´ a s´ıt’: Tato forma softwarovˇe definovan´e s´ıtˇe funguje na principu deklarov´an´ı poˇzadovan´e politiky. Spr´ avce s´ıtˇe pop´ıˇse co chce v s´ıt´ı prov´est, a syst´em s´am urˇc´ı jak tyto zmˇeny prov´est. Jedn´ a se o pokroˇcilou formu s´ıt’ov´e automatizace, kter´a umoˇzn ˇuje napˇr´ıklad provozovatel˚ um aplikac´ı definovat, jak´e chov´an´ı od s´ıtˇe oˇcek´avaj´ı. Jako pˇr´ıklad lze uv´est Application Centric Networking od spoleˇcnosti Cisco [3].
1.2
Zamˇ eˇ ren´ı a c´ıl pr´ ace
C´ılem t´eto pr´ ace je navrhnout a realizovat postup pro automatizovanou konfiguraci z´akladn´ıch funkc´ı na s´ıt’ov´ ych zaˇr´ızen´ıch MikroTik s vyuˇzit´ım n´astroje Ansible. Prim´arnˇe je tato pr´ace zamˇeˇrena na takzvanou out-of-box konfiguraci, tedy prvotn´ı nastaven´ı zaˇr´ızen´ı, kter´e umoˇzn´ı 5
´ KAPITOLA 1. UVOD jeho nasazen´ı do s´ıtˇe. V r´ amci t´eto pr´ace se budu vˇenovat moˇzn´ ym postup˚ um k dosaˇzen´ı tohoto c´ıle, n´ aslednˇe popisu mnou zvolen´eho ˇreˇsen´ı a jeho obhajobou. V z´avˇeru pr´ace pak budou uvedeny konkr´etn´ı pˇr´ıpady pouˇzit´ı. C´ılem t´eto pr´ace vˇsak nen´ı vytvoˇren´ı plnˇe automatizovan´eho n´ astroje pro kompletn´ı spr´avu s´ıt’ov´e infrastruktury vystavˇen´e na zaˇr´ızen´ıch spoleˇcnosti MikroTik, n´ ybrˇz pˇredevˇs´ım co nejv´ıce usnadnit nastaven´ı z´akladn´ıch s´ıt’ov´ ych funkc´ı a umoˇznit tak n´ aslednou spr´ avu pomoc´ı dalˇs´ıch n´astroj˚ u. Vzhledem k modul´arn´ı povaze n´astroje Ansible bude vˇsak moˇzn´e v budoucnu pˇridat dalˇs´ı funkce a rozˇs´ıˇrit tak schopnosti tohoto n´ astroje.
6
Kapitola 2
Anal´ yza 2.1 2.1.1
Z´ akladn´ı pojmy Charakteristiky poˇ c´ıtaˇ cov´ e s´ıtˇ e
Mezi z´akladn´ı charakteristiky poˇc´ıtaˇcov´e s´ıtˇe patˇr´ı: Topologie, rychlost na fyzick´e vrstvˇe, cena, bezpeˇcnost, dostupnost, ˇsk´ alovatelnost a spolehlivost [4]. Topologie: Pod pojmem topologie si lze pˇredstavit urˇcit´ y tvar ˇci strukturu s´ıtˇe. Zab´ yv´ a se propojen´ım s´ıt’ov´ ych prvk˚ u v r´ amci s´ıtˇe a zachycen´ım re´aln´e (fyzick´e) a logick´e podoby tohoto propojen´ı. Fyzick´ a topologie popisuje skuteˇcnou konstrukci s´ıtˇe s jednotliv´ ymi uzly a fyzick´ ymi zaˇr´ızen´ımi, vˇcetnˇe popisu kabel´aˇze, kter´a je propojuje. Logick´a topologie se pak vztahuje k tomu, jak jsou v s´ıti pˇren´aˇsena data mezi jednotliv´ ymi uzly. Aˇckoliv logick´a topologie m˚ uˇze kop´ırovat topologii fyzickou (napˇr´ıklad v dom´ac´ıch s´ıt´ıch), ve vˇetˇs´ıch s´ıt´ıch se tyto topologie liˇs´ı. D˚ uvodem je zejm´ena zv´ yˇsen´ı dostupnosti, spolehlivosti a t´ım celkov´e robustnosti s´ıtˇe. Dojde-li napˇr´ıklad k poruˇse zaˇr´ızen´ı ˇci z´avadˇe na kabelu, je moˇzn´e pozmˇenit logickou topologii pˇri zachov´ an´ı t´e fyzick´e. Provoz bude veden jinou cestou a s´ıt’ bude st´ale dostupn´a a provozuschopn´ a. Zmˇenu logick´e topologie v pˇr´ıpadˇe poruchy jsou pak zaˇr´ızen´ı schopna prov´est sama bez vnˇejˇs´ıho z´ asahu, s vyuˇzit´ım zvl´aˇstn´ıch protokol˚ u a ve velmi kr´atk´em ˇcase. S moˇznost´ı poruchy je tˇreba poˇc´ıtat jiˇz pˇri n´avrhu fyzick´e topologie a pokud moˇzno zamezit vzniku Single Point of Failure (SPOF), tedy bodu, jehoˇz selh´an´ı povede k v´ ypadku provozuschopnosti s´ıtˇe. Rychlost na fyzick´ e vrstvˇ e: Rychlost s´ıtˇe ud´av´a, jak´e mnoˇzstv´ı informace je s´ıt’ schopna pˇren´est za urˇcit´ y ˇcas, z´ akladn´ı jednotkou rychlosti je bit za sekundu (b/s, bps). Dneˇsn´ı lok´aln´ı s´ıtˇe vˇetˇsinou vyuˇz´ıvaj´ı v pˇr´ıstupov´e ˇc´asti rychlost´ı 100 Mb/s oznaˇcovanou jako Fast Ethernet, nebo 1000 Mb/s oznaˇcovanou jako Gigabit Ethernet. Vzhledem k neust´ale rostouc´ımu objemu pˇren´ aˇsen´ ych dat, jako sledov´an´ı on-line vide´ı, videokonferenc´ı, pˇrenos soubor˚ u ˇci 7
´ KAPITOLA 2. ANALYZA z´alohov´an´ı na s´ıt’ov´ a u ´loˇziˇstˇe, rostou i poˇzadavky na pˇrenosovou rychlost v poˇc´ıtaˇcov´ ych s´ıt´ıch. Speci´ aln´ım pˇr´ıpadem jsou pak datov´a centra, kter´a vzhledem k enormn´ımu objemu pˇren´aˇsen´ ych dat kladou vysok´e n´ aroky, mimo jin´e, na pˇrenosovou rychlost. To samozˇrejmˇe vyˇzaduje vyuˇzit´ı odliˇsn´e infrastruktury neˇz u uˇzivatelsk´ ych s´ıt´ı, napˇr´ıklad vyuˇzit´ı optick´ ych vl´aken, kter´ a dosahuj´ı vyˇsˇs´ıch pˇrenosov´ ych rychlost´ı neˇz metalick´e kabely. Dostupnost: Dostupnost je parametrem popisuj´ıc´ım jak ˇcasto jsou sluˇzby a prostˇredky poskytovan´e poˇc´ıtaˇcovou s´ıt´ı pˇr´ıstupn´e uˇzivatel˚ um. Vetˇsinou se dostupnost uv´ad´ı jako mnoˇzstv´ı ˇcasu za rok, kdy byly sluˇzby poskytovan´e s´ıt´ı dostupn´e. Tento pomˇer je ud´av´an v procentech, kupˇr´ıkladu dostupnost 99,99% pˇredstavuje povolen´ y v´ ypadek s´ıtˇe na 52,56 minut za rok, tedy asi 8,6 sekundy dennˇe. Kritick´e syst´emy pouˇz´ıvan´e napˇr´ıklad bezpeˇcnostn´ımi sloˇzkami, zdravotnick´ ymi zaˇr´ızen´ımi ˇci datacentry vyˇzaduj´ı vysokou dostupnost (High-availability). U takov´ ychto syst´em˚ u se ˇcasto se uv´ ad´ı dostupnost 99,999% (”pˇet dev´ıtek), coˇz d´av´a prostor pro nedostupnost sluˇzby po dobu 864,3 milisekund dennˇe. K dosaˇzen´ı takto vysok´e dostupnosti je tˇreba v s´ıti ˇci syst´emu eliminovat SPOF, coˇz vyˇzaduje redundanci a monitorov´an´ı poruch v re´ aln´em ˇcase. Vysok´ a dostupnost je velmi d˚ uleˇzit´a tak´e pro podniky. Ve zpr´avˇe z roku 1998 spoleˇcnost IBM uv´ ad´ı, ˇze americk´e podniky pˇriˇsly v d˚ usledku nedostupnosti sv´ ych syst´em˚ u za rok 1996 o 4,54 miliardy dolar˚ u[5]. Spolehlivost: Spolehlivost popisuje schopnost poˇc´ıtaˇcov´e s´ıtˇe prov´est poˇzadovanou akci, jako napˇr´ıklad komunikaci mezi dvˇemi zaˇr´ızen´ımi. Pro uˇcen´ı spolehlivosti s´ıtˇe lze pouˇz´ıt deterministick´e ˇci pravdˇepodobnostn´ı modely [6]. Spolehlivost v poˇc´ıtaˇcov´e s´ıti urˇcuje jednak kvalita infrastruktury a jednak pouˇzit´e komunikaˇcn´ı protokoly. Nˇekter´e s´ıt’ov´e protokoly jsou oznaˇcov´any jako spolehliv´e, nebot’ zahrnuj´ı funkce pro potvrzen´ı o doruˇcen´ı vyslan´e zpr´avy, ˇci jsou schopn´e zajistit jej´ı opˇetovn´e vysl´an´ı v pˇr´ıpadˇe chyby. Typick´ ym spolehliv´ ym protokolem je napˇr´ıklad Transmission Control Protocol (TCP). Naopak nespolehliv´e protokoly nezaruˇcuj´ı doruˇcen´ı vyslan´e zpr´ avy, mohou se vˇsak hodit pro nˇekter´e specifick´e aplikace. Asi nejzn´amˇejˇs´ı protokolem z t´eto kategorie je User Datagram Protocol (UDP). Protokoly TCP i UDP jsou protokoly 4. vrstvy a vyuˇz´ıvaj´ı Internet Protocol (IP), kter´ y spad´a do kategorie nespolehliv´ ych protokol˚ u. Bezpeˇ cnost: Dneˇsn´ı s´ıtˇe a obecnˇe poˇc´ıtaˇcov´e syst´emy pˇren´aˇsej´ı a uchov´avaj´ı mnoho citliv´ ych informac´ı. Nezbytn´ ym poˇzadavkem pˇri provozov´an´ı s´ıtˇe je proto zajiˇstˇen´ı jej´ı bezpeˇcnosti, tedy snaha co nejv´ıce omezit moˇznost pˇr´ıstupu nepovolan´ ym osob´am k tˇemto dat˚ um. Do s´ıt’ov´e bezpeˇcnosti vˇsak nespad´ a pouze obrana proti nejr˚ uznˇejˇs´ım u ´tok˚ um, ale tak´e omezen´ı dopadu dalˇs´ıch potenci´ aln´ıch hrozeb. Mezi tyto hrozby patˇr´ı napˇr´ıklad nedbalost ˇci neznalost uˇzivatel˚ u, pˇr´ırodn´ı faktory jako poˇz´ ar ˇci z´aplavy a dalˇs´ı. Pˇred pl´anov´an´ım zabezpeˇcen´ı s´ıtˇe je pak tˇreba zv´ aˇzit cenu aktiv (hardware, software, data) a jak´e dopady m˚ uˇze m´ıt jejich odcizen´ı, poˇskozen´ı ˇci kompromitov´ an´ı. Bezpeˇcnostn´ı opatˇren´ı by mˇela b´ yt dostateˇcn´a, nikoliv vˇsak pˇremrˇstˇen´ a (pro pˇr´ımˇer - aby nebyla cena trezoru vyˇsˇs´ı neˇz cena jeho obsahu). V n´avaznosti na moˇzn´ y v´ yskyt bezpeˇcnostn´ıch incident˚ u je tˇreba m´ıt pˇripraven pl´an na jejich zvl´ad´an´ı a 8
´ KAPITOLA 2. ANALYZA minimalizov´ an´ı jejich dopadu. S´ıt’ovou bezpeˇcnost lze rozdˇelit do tˇr´ı z´akladn´ıch pil´ıˇr˚ u: fyzick´a bezpeˇcnost, bezpeˇcnost s´ıtˇe a sluˇzeb a bezpeˇcnost lidsk´ ych zdroj˚ u. Do fyzick´e bezpeˇcnosti spad´a napˇr´ıklad zajiˇstˇen´ı vhodn´eho prostˇred´ı pro provoz IT infrastruktury a jeho zabezpeˇcen´ı proti pˇr´ıstupu nepovolan´ ych osob (uzamykateln´e racky a kabinety). Do t´eto kategorie d´ale spad´a fyzick´a topologie a redundance kl´ıˇcov´ ych cest, prov´adˇen´ı z´aloh d˚ uleˇzit´ ych dat ˇci jejich ukl´ad´an´ı na bezpeˇcn´ ych zrcadlen´ ych datov´ ych u ´loˇziˇst´ıch a dalˇs´ı. Bezpeˇcnost s´ıtˇe a sluˇzeb se zab´ yv´ a pˇredevˇs´ım zabezpeˇcen´ım pˇr´ıstupu k tˇemto sluˇzb´am prostˇrednictv´ım autentizace a autorizace, tedy ovˇeˇren´ım uˇzivatel˚ u a nastaven´ım pˇr´ıstupov´ ych pr´av k jednotliv´ ym sluˇzb´am a logov´an´ım jejich ˇcinnosti. Spad´ a sem tak´e prioritizace sluˇzeb, rozdˇelen´ı s´ıtˇe (bezpeˇcnostn´ı z´ony, virtu´aln´ı s´ıtˇe), obvodov´ a bezpeˇcnost (Firewall, obrana proti u ´tok˚ um z Internetu), ochrana koncov´ ych zaˇr´ızen´ı (Antivirov´e programy, IPS, IDS), ochrana s´ıtˇe pˇred uˇzivatelem (povolen´ı pˇr´ıstupu do s´ıtˇe pouze ovˇeˇren´ ym uˇzivatel˚ um a stanic´ım), pouˇz´ıv´an´ı zabezpeˇcen´ ych sluˇzeb a ˇsifrov´an´ı, celkov´a spr´ ava s´ıtˇe (spr´ ava konfigurac´ı zaˇr´ızen´ı, monitoring) a mnoho dalˇs´ıch. Bezpeˇcnost lidsk´ ych zdroj˚ u zahrnuje mimo jin´e informovanost uˇzivatel˚ u formou ˇskolen´ı, minimalizaci pˇr´ıstupov´ ych pr´ av (kaˇzd´ y uˇzivatel m´a pˇr´ıstup pouze tam, kam potˇrebuje), dodrˇzov´an´ı intern´ıch pˇredpis˚ u a politik. Bohuˇzel pr´avˇe tento aspekt s´ıt’ov´e bezpeˇcnosti b´ yv´a ˇcasto opom´ıjen. Mnohdy plat´ı, ˇze nejslabˇs´ım ˇcl´ ankem v zabezpeˇcen´ı s´ıtˇe je pr´avˇe ˇclovˇek. Na tuto skuteˇcnost spol´ehaj´ı u ´toky zaloˇzen´e na soci´ aln´ım inˇzen´ yrstv´ı, kdy u ´toˇcn´ık z´ısk´a kl´ıˇcov´e informace od ´ cn´ık s pˇripravenou z´aminkou kontaktuje nˇekter´eho zamˇestnance ˇcasto pouh´ ym dotazem. Utoˇ zamˇestnance a poˇz´ ad´ a jej o urˇcit´e informace ˇci proveden´ı nˇejak´e akce. Zamˇestnanec pak v dobr´e v´ıˇre udˇel´ a, co u ´toˇcn´ık ˇz´ ad´ a, aniˇz by si byl vˇedom moˇzn´ ych n´asledk˚ u sv´eho jedn´an´ı. Cena: Jedn´ım z hlavn´ıch parametr˚ u pˇri n´avrhu a provozu s´ıt’ov´e infrastruktury je samozˇrejmˇe cena navrˇzen´eho ˇreˇsen´ı. Hlavn´ı pod´ıl na koncov´e cenˇe vˇsak nem´a pouze pouˇzit´ y hardware, ale pˇredevˇs´ım licence pro jednotliv´ a zaˇr´ızen´ı a jejich n´asledn´a podpora ze strany v´ yrobce. S provozem IT infrastruktury jsou tak´e neodmyslitelnˇe spojen´e n´aklady na provoz, tedy pˇredevˇs´ım platy zamˇestnanc˚ u IT oddˇelen´ı. To samozˇrejmˇe plat´ı pˇredevˇs´ım u stˇredn´ıch a ˇ velk´ ych spoleˇcnost´ı, kter´e provozuj´ı rozs´ahl´e infrastruktury. Casto je vˇsak na IT oddˇelen´ı pohl´ıˇzeno jako na jak´ ysi nadstandardn´ı luxus. Pokud vˇse funguje bez probl´em˚ u, pˇripad´ a ˇclen˚ um veden´ı neekonomick´e provozovat IT oddˇelen´ı. Coˇz je ponˇekud ironick´e, protoˇze vˇse funguje bez probl´em˚ u pr´ avˇe tehdy, kdyˇz pracovn´ıci IT oddˇelen´ı odv´adˇej´ı dobˇre svoji pr´aci. V posledn´ıch letech se tak rozm´ ah´ a trend outsourcingu spr´avy IT infrastruktury. Podniky pak maj´ı moˇznost zredukovat IT oddˇelen´ı aˇz na jednoho ˇclovˇeka, kter´ y se vˇetˇsinu ˇcasu zab´ yv´ a napˇr´ıklad poˇzadavky a probl´emy uˇzivatel˚ u. Tohoto trendu si samozˇrejmˇe vˇsimli i velc´ı v´ yrobci na poli IT a upravili tomu i sv´e obchodn´ı politiky. Dnes snad vˇsichni velc´ı hr´aˇci poskytuj´ı tak´e sluˇzby pro spr´ avu a dohled poˇc´ıtaˇcov´ ych s´ıt´ı. Jako pˇr´ıklad m˚ uˇzeme uv´est spoleˇcnost Hewlett-Packard, jej´ıˇz pˇr´ıjmy v roce 2015 tvoˇrili ze 20% pr´avˇe sluˇzby spojen´e s podporou a outsourcingem. Tˇechto 20% pˇritom pˇredstavuje zhruba 20 miliard USD [7]. Podnik˚ um
9
´ KAPITOLA 2. ANALYZA tak outsourcing spr´ avy jejich IT infrastruktury umoˇzn ˇuje sn´ıˇzit n´aklady spojen´e s provozem vlastn´ıch IT oddˇelen´ı a platit extern´ım spoleˇcnostem pouze za to, co v danou chv´ıli potˇrebuj´ı. Pracovn´ıci extern´ıch spoleˇcnost´ı nav´ıc ˇcasto dosahuj´ı vyˇsˇs´ı u ´rovnˇe znalost´ı. ˇ alovatelnost: Pˇri n´ Sk´ avrhu s´ıt’ov´e infrastruktury by se vˇzdy mˇelo poˇc´ıtat s jej´ım r˚ ustem. Je nakonec c´ılem asi kaˇzd´eho podniku zvyˇsovat sv´e zisky, coˇz je ˇcasto spojeno se zv´ yˇsen´ım poˇctu zamˇestnanc˚ u, coˇz zase vede k potˇrebˇe v´ıce server˚ u, v´ıce aktivn´ıch prvk˚ u atd. Pˇr´ıstup ”Aktu´alnˇe m´ ame sedm zamˇestnanc˚ u a jeden server, tud´ıˇz n´am naprosto staˇc´ı osmi-portov´ y pˇrep´ınaˇc”tak sice poskytuje zd´ anlivou u ´sporu pˇri prvotn´ım budov´an´ı s´ıtˇe, avˇsak z dlouhodob´eho hlediska m˚ uˇze b´ yt znaˇcnˇe nehospod´arn´ y. Pˇribude-li ve spoleˇcnosti z v´ yˇse uveden´eho pˇr´ıkladu pozice pro dalˇs´ıho zamˇestnance, bude potˇreba vymˇenit p˚ uvodn´ı pˇrep´ınaˇc za nov´ y, poskytuj´ıc´ı v´ıce pˇr´ıstupov´ ych port˚ u. S´ıt’ by tak vˇzdy mˇela b´ yt navrˇzena s urˇcitou, nikoliv vˇsak pˇremrˇstˇenou, rezervou. Toto samozˇrejmˇe neplat´ı pouze pro podnikov´e s´ıtˇe, ale kupˇr´ıkladu tak´e pro s´ıtˇe ISP, jejich prim´ arn´ım c´ılem je rozˇsiˇrovat svou s´ıt’ a poskytovat sv´e sluˇzby dalˇs´ım z´akazn´ık˚ um.
2.1.2
Z´ akladn´ı s´ıt’ov´ e prvky
Pˇ rep´ınaˇ c (Switch) Pˇrep´ınaˇc je s´ıt’ovˇe zaˇr´ızen´ı pracuj´ıc´ı na L2, tedy spojov´e vrstvˇe Referenˇcn´ı model ISO/OSI (RM ISO/OSI). Jedn´a se vˇetˇsinou o zaˇr´ızen´ı s v´ıce porty, kdy je ke ´ kaˇzd´emu portu pˇripojeno koncov´e zaˇr´ızen´ı. Ukolem pˇrep´ınaˇce je pak pˇred´avat pˇr´ıchoz´ı ethernetov´e r´amce na pˇr´ısluˇsn´ y port podle c´ılov´e MAC adresy. Pˇrep´ınaˇc si vede tabulku, ve kter´e pˇriˇrazuje adresy zaˇr´ızen´ı pˇripojen´ ych ke konkr´etn´ım port˚ um. Pˇrep´ınaˇce nahradily v s´ıt´ıch dnes jiˇz zastaral´e rozboˇcovaˇce neboli Huby. Ty se od pˇrep´ınaˇc˚ u liˇsily pˇredevˇs´ım v tom, ˇze si nevedly tabulku adres pˇripojen´ ych zaˇr´ızen´ı, ale pouze rozes´ılaly pˇr´ıchoz´ı r´ amce na vˇsechny porty s v´ yjimkou pˇr´ıchoz´ıho. To velmi zvyˇsovalo provoz v s´ıti. Pˇredstavme si, ˇze m´ ame 10 osobn´ıch poˇc´ıtaˇc˚ u pˇripojen´ ych prostˇrednictv´ım rozboˇcovaˇce. Bude-li cht´ıt poˇc´ıtaˇc ˇc. 1 komunikovat s poˇc´ıtaˇcem ˇc. 2, veˇsker´a jejich komunikace v obou smˇerech bude z´ aroveˇ n odes´ıl´ ana na poˇc´ıtaˇce ˇc. 3 - ˇc. 10. Ty pak tato data v lepˇs´ım pˇr´ıpadˇe zahod´ı, protoˇze jim nejsou urˇcena, v horˇs´ım pˇr´ıpadˇe to umoˇzn ˇuje potenci´aln´ımu u ´toˇcn´ıkovi odposlouch´ avat tuto komunikaci. Toto zbyteˇcn´e“ kop´ırov´ an´ı dat nav´ıc velmi negativnˇe ovlivˇ nuje propustnost s´ıtˇe. Vˇsechny ” koncov´e stanice propojen´e pomoc´ı hubu tvoˇr´ı tzv. kolizn´ı dom´enu. Pokud chce dan´a stanice vys´ılat na sd´ılen´em m´ediu, mus´ı nejdˇr´ıve naslouchat, je-li m´edium voln´e – tedy zda na nˇem pr´avˇe nevys´ıl´ a jin´ a stanice. V d˚ usledku koneˇcn´e rychlosti ˇs´ıˇren´ı elektromagnetick´e vlny v m´ediu vˇsak m˚ uˇze nastat situace, ˇze stanice zaˇcne vys´ılat kr´atk´ y okamˇzik po tom, co zaˇcala vys´ılat jin´ a stanice a dojde tak ke kolizi. O vzniku t´eto kolize jsou stanice informov´any speci´aln´ım sign´ alem, po kter´em poˇckaj´ı n´ahodnou dobu, neˇz zaˇcnou znovu vys´ılat. Oproti tomu v s´ıt´ıch, kter´e pouˇz´ıvaj´ı pˇrep´ınaˇce, tvoˇr´ı kolizn´ı dom´enu vˇzdy jeden port pˇrep´ınaˇce a 10
´ KAPITOLA 2. ANALYZA zaˇr´ızen´ı k nˇemu pˇripojen´e. Tato metoda se oznaˇcuje jako mikrosegmentace a zabraˇ nuje vzniku koliz´ı. Modern´ı pˇrep´ınaˇce nav´ıc podporuj´ı ˇradu pokroˇcil´ ych funkc´ı, jako je tvorba virtu´aln´ıch lok´aln´ıch s´ıt´ı Virtual Local Area Network (VLAN), prioritizaci dan´eho typu provozu a v neposledn´ı ˇradˇe umoˇzn ˇuj´ı zabr´ anit neopr´avnˇen´ ym uˇzivatel˚ um v pˇripojen´ı do s´ıtˇe. Smˇ erovaˇ c (Router) Smˇerovaˇc je s´ıt’ov´e zaˇr´ızen´ı, jehoˇz u ´kolem je smˇerovat provoz mezi v´ıcero s´ıtˇemi. Oproti pˇrep´ınaˇci pracuje pouze s IP adresami, jedn´a se tedy o L3 zaˇr´ızen´ı. Smˇerovaˇc se vˇetˇsinou nach´ az´ı na okraji lok´aln´ı s´ıtˇe a zpracov´av´a data, kter´a jsou urˇcena k odesl´an´ı mimo lok´ aln´ı s´ıt’, nebo naopak do n´ı. Smˇerovaˇc b´ yv´a na odchoz´ı stranˇe pˇripojen k jednomu nebo v´ıce dalˇs´ım smˇerovaˇc˚ um. Zde je d˚ uleˇzit´e zm´ınit, ˇze kaˇzd´ y port smˇerovaˇce m´ a vlastn´ı IP adresu a porty sousedn´ıch smˇerovaˇc˚ u, kter´ ymi jsou propojeny, se mus´ı nach´azet ve stejn´e pods´ıti neboli subnetu. IP adresu m˚ uˇzeme rozdˇelit na ˇc´ ast s´ıt’ovou a hostovskou. Vˇsechny stanice (angl. hosts) v r´amci jedn´e s´ıtˇe maj´ı spoleˇcnou s´ıt’ovou ˇc´ast IP adresy. Aby bylo moˇzn´e urˇcit, kde je hranice mezi tˇemito dvˇema ˇc´ astmi adresy, pouˇz´ıv´a se s´ıt’ov´a maska (angl. network mask). Ta je stejnˇe jako IP adresa tvoˇrena ˇctyˇrmi oktety, tedy 32 bity. Proveden´ım bitov´e operace AND mezi IP adresou a s´ıt’ovou maskou dostaneme adresu s´ıtˇe: IP adresa 192.168.1.100:
11000000.10101000.00000001.01100100
S´ıt’ov´a maska 255.255.255.0:
11111111.11111111.11111111.00000000
Adresa s´ıtˇe 192.168.1.0:
11000000.10101000.00000001.00000000
Pr´avˇe na z´ akladˇe s´ıt’ov´e adresy smˇerovaˇc rozhodne, kam dan´ y paket vyslat. Spad´a-li c´ılov´a adresa paketu do definovan´eho adresn´ıho rozsahu, je paket odesl´an na odpov´ıdaj´ıc´ı dalˇs´ı zaˇr´ızen´ı. V pˇr´ıpadˇe, ˇze smˇerovaˇc nem´ a konkr´etnˇe definovan´ y rozsah, do kter´eho dan´a adresa spad´ a, vyuˇzije v´ ychoz´ıho z´ aznamu, kter´ y se oznaˇcuje jako v´ ychoz´ı br´ana. Tento proces se naz´ yv´ a smˇerov´an´ı a u ´daje podle kter´ ych se smˇerovaˇc rozhoduje jsou obsaˇzeny ve smˇerovac´ı tabulce. Ta m˚ uˇze b´ yt nastaven´ a staticky administr´atorem s´ıtˇe, nebo dynamicky pomoc´ı smˇerovac´ıch protokol˚ u jako je RIP, OSPF, EIGRP, BGP a dalˇs´ıch.
2.2
Moˇ znosti konfigurace s´ıt’ov´ ych zaˇ r´ızen´ı
Dneˇsn´ı s´ıt’ov´e prvky nab´ızej´ı ˇradu cest, kter´ ymi je moˇzn´e pˇristupovat k jejich nastaven´ı. N´ıˇze se pokus´ım nast´ınit nejbˇeˇznˇejˇs´ı postupy, vˇcetnˇe jejich pˇr´ıpadn´ ych v´ yhod a nev´ yhod: • Konzole • Telnet • SSH 11
´ KAPITOLA 2. ANALYZA • API • Web GUI • N´astroje specifick´e pro v´ yrobce • Automatizaˇcn´ı n´ astroje
Konzole: Syst´emov´ a konzole je sice p˚ uvodnˇe fyzick´e zaˇr´ızen´ı s kl´avesnic´ı a displejem, avˇsak dnes se jiˇz sp´ıˇse vyuˇz´ıvaj´ı virtu´ aln´ı konzole a termin´alov´e emul´atory. Jedn´a se o z´akladn´ı pˇr´ıstup ke konfiguraci zaˇr´ızen´ı prostˇrednictv´ım CLI. Pro konfiguraci prvku skrze konzoli je potˇreba m´ıt fyzick´e spojen´ı s t´ımto prvkem. Bˇeˇzn´ ym standardem pro konzolov´ y pˇr´ıstup je komunikaˇcn´ı rozhran´ı RS-232 (s´eriov´a linka). Jedn´a se o bezkolizn´ı rozhran´ı ˇcistˇe na fyzick´e vrstvˇe RM ISO/OSI. Nˇekter´e aktivn´ı prvky dnes jiˇz poskytuj´ı moˇznost jejich konfigurace pˇres rozhran´ı USB, avˇsak RS-232 je st´ ale mnohem rozˇs´ıˇrenˇejˇs´ı. Rozhran´ı RS-232 u aktivn´ıch prvk˚ u vˇetˇsinou vyuˇz´ıv´ a konektoru RJ-45. Aˇckoliv posledn´ı varianta s´eriov´e linky (RS-232C) poch´az´ı z roku 1969, ˇcasto se dnes pˇri konfiguraci aktivn´ıch prvk˚ u bez tohoto rozhran´ı neobejdeme, nebot’ u zaˇr´ızen´ı v tov´ arn´ım stavu pˇredstavuje mnohdy jedinou moˇznost pro konfiguraci, kter´a n´am umoˇzn´ı alespoˇ n nastavit dalˇs´ı moˇznosti pˇr´ıstupu, kter´e vyuˇz´ıvaj´ı vyˇsˇs´ıch vrstev RM ISO/OSI, napˇr´ıklad Telnet ˇci SSH. Telnet: Zkratka z Telecommunication Network - pˇredstavuje z´akladn´ı zp˚ usob pro vzd´alen´e pˇripojen´ı ke CLI aktivn´ıho prvku. Na rozd´ıl od konzole nevyˇzaduje pˇr´ım´e fyzick´e spojen´ı s konfigurovan´ ym zaˇr´ızen´ım, nebot’ vyuˇz´ıv´a TCP/IP protokolu. Na druhou stranu je vˇsak potˇreba, aby zaˇr´ızen´ı mˇelo nastavenou IP adresu a povolen´ y pˇr´ıstup prostˇrednictv´ım protokolu Telnet. Protokol Telnet typicky vyuˇz´ıv´a portu TCP 23. Znaˇcnou nev´ yhodou tohoto protokolu je vˇsak skuteˇcnost, ˇze veˇsker´a komunikace mezi aktivn´ım prvkem a virtu´aln´ım termin´alem prob´ıh´ a neˇsifrovanˇe. Vznik´a tak riziko moˇzn´eho odposlechu t´eto komunikace a z´ısk´an´ı citliv´ ych informac´ı, kter´e mohou pozdˇeji v´est ke kompromitov´an´ı s´ıt’ov´eho zaˇr´ızen´ı. Z tohoto d˚ uvodu se protokol Telnet pro vzd´alenou spr´avu nedoporuˇcuje. SSH: Secure Shell - zabezpeˇcen´ y komunikaˇcn´ı protokol, n´ahrada za Telnet. Stejnˇe jako Telnet umoˇzn ˇuje vzd´ alen´e pˇripojen´ı ke CLI, avˇsak s t´ım rozd´ılem, ˇze zabezpeˇcuje autentizaci obou zaˇr´ızen´ı a veˇsker´ a komunikace je ˇsifrovan´a. Existuj´ı dvˇe verze SSH, SSH-1 a SSH-2, pˇriˇcemˇz se doporuˇcuje pouˇz´ıvat druhou verzi, kter´a poskytuje vyˇsˇs´ı u ´roveˇ n zabezpeˇcen´ı. Dalˇs´ı v´ yhodou SSH je tak´e moˇznost autentizace pomoc´ı kl´ıˇc˚ u, coˇz jeˇstˇe sniˇzuje moˇznost neopr´avnˇen´eho pˇr´ıstupu k zaˇr´ızen´ı. Protokol SSH je v praxi nejrozˇs´ıˇrenejˇs´ı zp˚ usob pro pˇr´ıstup k vzd´alen´ ym zaˇr´ızen´ım a jeho druh´ a verze byla v roce 2006 navrˇzena jako Internetov´ y standard. Sluˇzba SSH je typicky provozov´ ana na portu TCP 22. API: Application Programming Interface - rozhran´ı pro programov´an´ı aplikac´ı. Jedn´a se o sb´ırku procedur, funkc´ı, tˇr´ıd ˇci protokol˚ u, kter´e m˚ uˇze program´ator vyuˇz´ıvat. API urˇcuje, jak´ ym zp˚ usobem jsou funkce knihovny vol´any ze zdrojov´eho k´odu programu. [8]. Rozhran´ı 12
´ KAPITOLA 2. ANALYZA API tak umoˇzn ˇuje tvorbu vlastn´ıch softwarov´ ych ˇreˇsen´ı pro komunikaci se zaˇr´ızen´ımi za u ´ˇcelem z´ısk´ an´ı informac´ı a u ´pravy jejich konfigurace. Web GUI: Web Graphical User Interface - pˇredstavuje ide´aln´ı moˇznost konfigurace pro m´enˇe zkuˇsen´e uˇzivatele, jedn´ a se o grafick´e prostˇred´ı bˇeˇz´ıc´ı ve webov´em prohl´ıˇzeˇci. Toto prostˇred´ı vˇsak ˇcasto poskytuje pouze zlomek vˇsech poskytovan´ ych funkcionalit. Tohoto zp˚ usobu konfigurace je ˇcasto vyuˇz´ıv´ ano u Small Office / Home Office (SOHO) zaˇr´ızen´ı. V prostˇred´ı vˇetˇs´ıch podnik˚ u vˇsak m˚ uˇze pˇredstavovat bezpeˇcnostn´ı riziko. Bˇeˇzn´ y uˇzivatel dok´aˇze mnohem sn´aze pozmˇenit konfiguraci s´ıt’ov´eho zaˇr´ızen´ı prostˇrednictv´ım grafick´eho prostˇred´ı, neˇz prostˇrednictv´ım CLI. Z tohoto d˚ uvodu se nedoporuˇcuje provozovat Web GUI na prvc´ıch s´ıt’ov´e infrastruktury. N´ astroje specifick´ e pro v´ yrobce: V´ yrobci s´ıt’ov´ ych zaˇr´ızen´ı ve snaze usnadnit spr´avu tˇechto zaˇr´ızen´ı poskytuj´ı nejr˚ uznˇejˇs´ı softwarov´e utility. Jejich u ´ˇcelem je usnadnit nastaven´ı ˇ a vyhnout se ˇcasto zdlouhav´e konfiguraci prostˇrednictv´ım CLI. Casto se tak´e snaˇz´ı usnadnit prvotn´ı nastaven´ı formou pr˚ uvodc˚ u, coˇz umoˇzn´ı i m´enˇe zdatn´ ym uˇzivatel˚ um uv´est zaˇr´ızen´ı do z´akladn´ıho provozuschopn´eho stavu. Nˇekter´e pokroˇcilejˇs´ı n´astroje tak´e umoˇzn ˇuj´ı spr´avu vˇetˇs´ıho poˇctu zaˇr´ızen´ı najednou a poskytuj´ı informace o jejich aktu´aln´ım stavu. Automatizaˇ cn´ı n´ astroje: Existuje pomˇernˇe ˇsirok´a ˇrada jak komerˇcn´ıch tak open-sourcov´ ych aplikac´ı pro spr´ avu s´ıt’ov´e infrastruktury. Tyto aplikace vˇetˇsinou podporuj´ı zaˇr´ızen´ı mnoha v´ yrobc˚ u a pro pˇr´ıstup k tˇemto zaˇr´ızen´ım pouˇz´ıvaj´ı pˇrev´aˇznˇe SNMP ˇci SSH. Tyto programy z´aroveˇ n slouˇz´ı jako log-servery a vˇetˇsinou nab´ızej´ı grafick´e prostˇred´ı poskytuj´ıc´ı administr´atorovi s´ıtˇe pˇrehled o stavu jednotliv´ ych zaˇr´ızen´ı, vˇcetnˇe moˇznosti upozornˇen´ı na nejr˚ uznˇejˇs´ı ud´ alosti. Tyto n´ astroje vˇsak vyˇzaduj´ı jist´e nastaven´ı aktivn´ıch prvk˚ u, proto je nelze vyuˇz´ıt pro prvotn´ı nastaven´ı pˇri deploymentu zaˇr´ızen´ı a nach´azej´ı tak sv´e m´ısto sp´ıˇse v jiˇz provozovan´e s´ıti.
2.3 2.3.1
Ansible Co je Ansible
Ansible je opensource softwarov´ a platforma pro konfiguraci a management (pˇredevˇs´ım) server˚ u, poskytuj´ıc´ı ˇsirok´e moˇznosti pro cloud provisioning, spr´avu konfigurac´ı, deployment aplikac´ı ˇci orchestraci sluˇzeb. Od z´ aklad˚ u je navrˇzen pro hromadnou spr´avu mnoha zaˇr´ızen´ı, s ˇc´ımˇz tak´e souvis´ı jeho state-oriented zamˇeˇren´ı. To znamen´a, ˇze Ansible sp´ıˇse popisuje chov´an´ı IT infrastruktury a souvislosti mezi prvky a sluˇzbami, neˇz aby konfiguroval jeden syst´em po druh´em. V porovn´ an´ı s konkurenˇcn´ımi n´astroji, jako je napˇr´ıklad Chef nebo Puppet, je Ansible pomˇernˇe snadno uchopiteln´ y i pro administr´atory zaˇc´ınaj´ıc´ı se snahou o ˇc´asteˇcnou automatizaci nˇekter´ ych aspekt˚ u dan´e infrastruktury. Jeho jednoduchosti a snadn´emu nasa13
´ KAPITOLA 2. ANALYZA zen´ı napom´ ah´ a tak´e to, ˇze je push-oriented. Na rozd´ıl od ostatn´ıch konfiguraˇcn´ıch n´astroj˚ u nevyˇzaduje ˇz´ adnou instalaci agenta na koncov´ ych zaˇr´ızen´ıch. Pro pˇripojen´ı ke koncov´ ym zaˇr´ızen´ım se tak nejˇcastˇeji pouˇz´ıv´ a Secure Shell (SSH). V terminologii Ansiblu se tato zaˇr´ızen´ı oznaˇcuj´ı jako uzly (angl. node) [9]. Informace o jednotliv´ ych uzlech jsou uvedeny v invent´aˇri (angl. Inventory), kde je moˇzn´e definovat parametry jednotliv´ ych uzl˚ u ˇci skupin tˇechto uzl˚ u. Ansible je do znaˇcn´e m´ıry komunitn´ım projektem a takˇrka kaˇzd´ y se tedy m˚ uˇze pod´ılet na jeho dalˇs´ım v´ yvoji. Veˇsker´e zdrojov´e k´ody nejnovˇejˇs´ı verze Ansiblu jsou dostupn´e na port´alu GitHub [10]. Ansible je tak´e dostupn´ y prostˇrednictv´ım bal´ıˇckovac´ıch sluˇzeb. V souˇcasn´e dobˇe nelze nainstalovat Ansible na operaˇcn´ım syst´emu Windows. Z´akladn´ı pokyny pro instalaci Ansiblu lze nal´ezt v dokumentaci dostupn´e on-line [11].
2.3.2
Historie Ansiblu
Prvotn´ı verze Ansiblu byla vyd´ ana 20. u ´nora 2012. Jeho autorem je Michael DeHaan, autor softwaru Cobbler, kter´ y automatizuje s´ıt’ovˇe-zaloˇzen´e instalace mnoha operaˇcn´ıch syst´em˚ uz centr´aln´ıho bodu s vyuˇzit´ım sluˇzeb jako DHCP, TFTP a DNS. P˚ uvodn´ı spoleˇcnost Ansible, Inc., kter´ a komerˇcnˇe podporovala a sponzorovala Ansible byla 16. ˇr´ıjna 2015 pˇrevzata spoleˇcnost´ı Red Hat Inc. Od verze 1.7 umoˇzn ˇuje Ansible konfigurac´ı uzl˚ u se syst´emem Windows. V dobˇe psan´ı t´eto pr´ ace je nejnovˇejˇs´ı stabiln´ı verz´ı Ansiblu verze 2.0.2.0. Mezi z´akladn´ı c´ıle projektu Ansible patˇr´ı minimalistick´a povaha, konzistence, bezpeˇcnost, vysok´a spolehlivost a n´ızk´ a uˇc´ıc´ı kˇrivka.
2.3.3
Jak Ansible funguje
Ansible je ve sv´e podstatˇe sadou skript˚ u a knihoven napsan´ ych v jazyce Python. Prov´adˇen´ı samotn´ ych konfiguraˇcn´ıch pˇr´ıkaz˚ u maj´ı na starost pr´avˇe tyto skripty, tzv. moduly. Ty maj´ı definovan´ y seznam argument˚ u, na jejichˇz z´akladˇe provedou poˇzadovanou operaci. Argumenty urˇcuj´ı poˇzadovan´ y stav nastavovan´ ych hodnot, zmˇeny se tak provedou pouze v pˇr´ıpadˇe, ˇze aktu´aln´ı hodnota neodpov´ıd´ a t´e poˇzadovan´e. Tento pˇr´ıstup se oznaˇcuje jako desired-state approach. Opakovan´e spuˇstˇen´ı stejn´eho pˇr´ıkazu tak nem´a za n´asledek opˇetovn´e prov´adˇen´ı stejn´ ych zmˇen na koncov´em uzlu. Vˇetˇsina z´akladn´ıch modul˚ u, kter´e jsou souˇc´ast´ı instalace Ansiblu je vˇsak zamˇeˇrena na konfiguraci server˚ u a vyˇzaduje podporu jazyka Python na kaˇzd´em uzlu. Ansible pak na z´ akladˇe zvolen´ ych argument˚ u vytvoˇr´ı skript a spust´ı jej na zvolen´em uzlu. Z tohoto d˚ uvodu zat´ım Ansible neumoˇzn ˇuje konfiguraci vˇetˇsiny s´ıt’ov´ ych prvk˚ u. Pro jejich konfiguraci je tak tˇreba vytvoˇren´ı modul˚ u, kter´e se spouˇstˇej´ı pouze na stranˇe Ansible serveru a uzl˚ um pak pˇred´ avaj´ı uˇz pouze low-level pˇr´ıkazy. V terminologii Ansiblu se typ tohoto pˇripojen´ı oznaˇcuje jako lok´aln´ı (angl. local ). Potom je moˇzn´e zvolit libovoln´ y typ pˇripojen´ı podporovan´ y s´ıt’ov´ ym prvkem (Telnet, SSH, API,...) a pˇrizp˚ usobit mu dan´ y modul. Ansible umoˇzn ˇuje spouˇstˇen´ı modul˚ u ve dvou z´akladn´ıch reˇzimech. V reˇzimu ad-hoc [12] se 14
´ KAPITOLA 2. ANALYZA vˇzdy spust´ı pouze jeden zvolen´ y modul s dan´ ymi parametry 2.1. Ve druh´em reˇzimu se postupnˇe spust´ı libovoln´ y poˇcet modul˚ u (reprezentovan´ ych pˇr´ıkazy) ze seznamu. Tyto seznamy se oznaˇcuj´ı jako sc´en´ aˇre (angl. Playbooks) [13]. Sc´en´aˇre jsou ps´any v jazyce Yet Another Markup Language (YAML), d´ıky ˇcemuˇz jsou velmi pˇrehledn´e a jednoduch´e na pochopen´ı. Kaˇzd´ y sc´en´aˇr obsahuje n´ azev skupiny uzl˚ u, proti kter´ ym budou pˇr´ıkazy pouˇzity. Pˇr´ıklad sc´en´aˇre: 2.2. Sc´en´aˇre tak´e umoˇzn ˇuj´ı pr´ aci s promˇenn´ ymi, coˇz znaˇcnˇe usnadˇ nuje pouˇzit´ı modul˚ u proti velk´emu poˇctu koncov´ ych uzl˚ u. Tyto promˇenn´e lze definovat pˇr´ımo ve sc´en´aˇri, nebo v invent´aˇri pro jednotliv´e uzly ˇci jejich skupiny. Invent´aˇr je soubor obsahuj´ıc´ı seznam vˇsech uzl˚ u. Tyto uzly mohou b´ yt rozdˇeleny do skupin. Ansible vyuˇz´ıv´ a dva druhy invent´ aˇr˚ u: statick´e a dynamick´e. Statick´ y invent´aˇr je prost´ y textov´ y soubor obsahuj´ıc´ı seznam uzl˚ u a informace o nich. Dynamick´ y invent´aˇr je skript napsan´ y v libovoln´em jazyce. Jeho jedinou podm´ınkou je, ˇze pˇri jeho zavol´an´ı s parametrem --list vr´at´ı do standardn´ıho v´ ystupu seznam uzl˚ u s pˇr´ıpadn´ ymi promˇenn´ ymi. Tento pˇr´ıstup je velmi praktick´ y zejm´ena v pˇr´ıpadech, ˇze se jedn´a o velk´e skupiny uzl˚ u. a n s i b l e w e b s e r v e r s −m yum −a ”name=acme s t a t e=l a t e s t ”
K´od 2.1: Pˇr´ıklad pˇr´ım´eho pˇr´ıkazu, kter´ y m´a za u ´kol nainstalovat nejnovˇejˇs´ı verzi bal´ıˇcku acme V´ yˇse uveden´ y pˇr´ıkaz zavol´ a nad skupinou uzl˚ u webservers modul yum, tedy modul ovl´adaj´ıc´ı bal´ıˇckovac´ı sluˇzbu distribuc´ı jako Fedora nebo Red Hat Enterprise Linux. Tomuto modulu pˇred´a parametry name=acme a state=latest. I uˇzivateli se z´akladn´ı znalost´ı linuxov´ ych syst´em˚ u je jasn´e, co tento pˇr´ıkaz udˇel´a: Na vˇsech serverech ze skupiny webservers zkontroluje, ˇze bal´ıˇcek acme je nainstalov´ an v nejnovˇejˇs´ı verzi a pokud nen´ı, nainstaluje nejnovˇejˇs´ı dostupnou verzi. −−− − hosts : w e b s e r v e r s vars : http port : 80 max clients : 200 remote user : r o o t tasks : − name : Ensure apache i s a t t h e l a t e s t v e r s i o n yum : name=httpd s t a t e=l a t e s t − name : Write t h e apache c o n f i g f i l e template : s r c =/s r v / httpd . j 2 d e s t=/ e t c / httpd . c o n f notify : − r e s t a r t apache − name : Ensure apache i s r u n n i n g ( and e n a b l e i t a t boot ) service : name=httpd s t a t e=s t a r t e d e n a b l e d=y e s handlers : − name : r e s t a r t apache service : name=httpd s t a t e=r e s t a r t e d
K´od 2.2: Pˇr´ıklad sc´en´ aˇre, kter´ y ukazuje jak´ ym zp˚ usobem je moˇzn´e instalovat a konfigurovat webov´ y server apache ma serverech ze skupiny webservers. 15
´ KAPITOLA 2. ANALYZA V´ yˇse uveden´ y k´ od pˇredstavuje pˇr´ıklad sc´en´aˇre pro Ansible. Na zaˇc´atku souboru je tˇreba uv´est, proti kter´ ym uzl˚ um budou n´ asledn´e pˇr´ıkazy spuˇstˇeny, v tomto pˇr´ıpadˇe se jedn´a o skupinu webservers. D´ ale jsou zde zad´ any hodnoty nˇekter´ ych vestavˇen´ ych promˇenn´ ych, jako napˇr´ıklad port, na kter´em je provozov´ an HTTP server ˇci jm´eno uˇzivatele, pod kter´ ym se m´a Ansible pˇrihl´asit ke vzd´ alen´emu uzlu. Prvn´ım u ´kolem v tomto sc´en´aˇri je zkontrolovat, ˇze Apache web server je nainstalov´ an v posledn´ı verzi, pˇr´ıpadnˇe tuto verzi nainstalovat. V dalˇs´ım kroku se pˇrep´ıˇse konfiguraˇcn´ı soubor Apache serveru tak, aby odpov´ıdal pˇredem pˇripraven´e ˇsablonˇe uloˇzen´e na Ansible serveru. Pot´e je zavol´an handler, kter´ y restartuje web server. V posledn´ım kroku se ovˇeˇr´ı, ˇze sluˇzba web serveru je spuˇstˇena a ˇze bude automaticky spuˇstˇena pˇri startu syst´emu. Sc´en´ aˇr se spust´ı pˇr´ıkazem ansible-playbook playbook.yml.
2.4
MikroTik
Spoleˇcnost MikroTik byla zaloˇzena v roce 1996 v Litvˇe a zab´ yv´a se v´ yvojem a prodejem s´ıt’ov´ ych prvk˚ u. Aktivn´ı prvky od spoleˇcnosti MikroTik vyuˇz´ıvaj´ı operaˇcn´ıho syst´emu RouterOS zaloˇzen´eho na linuxov´em j´adˇre [14]. Zaˇr´ızen´ı s t´ımto operaˇcn´ım syst´emem nab´ızej´ı ˇsirok´e moˇznosti konfigurace, velk´e mnoˇzstv´ı podporovan´ ych funkc´ı a relativnˇe n´ızkou poˇrizovac´ı cenu v porovn´ an´ı se zaˇr´ızen´ımi konkurenˇcn´ıch znaˇcek. Z tˇechto d˚ uvod˚ u jsou velmi obl´ıben´e u lok´ aln´ıch ISP pro realizaci pˇr´ıstupov´e ˇc´asti s´ıtˇe, pˇredevˇs´ım pak pro bezdr´atov´ a ˇreˇsen´ı. Pˇr´ıjmy spoleˇcnosti MikroTik v roce 2014 ˇcinily 135,4 milion˚ u Euro, z ˇcehoˇz 34,4 milion˚ u ˇcin´ı ˇcist´ y zisk spoleˇcnosti. Hlavn´ım produktem spoleˇcnosti je jiˇz zm´ınˇen´ y RouterOS. Tento operaˇcn´ı syst´em poskytuje ˇsirokou ˇradu funkc´ı, kter´e lze nahr´ avat prostˇrednictv´ım bal´ıˇck˚ u. Existuje 6 u ´rovn´ı licenc´ı pro RouterOS. Tyto licence jsou ˇcasovˇe neomezen´e a jsou souˇc´ast´ı fyzick´eho zaˇr´ızen´ı. Licenci je tedy nutn´e samostatnˇe zakoupit pouze v pˇr´ıpadˇe, ˇze chceme instalovat RouterOS na bˇeˇzn´em poˇc´ıtaˇci ˇci serveru s architekturou x86. V dobˇe psan´ı t´eto pr´ace existuje jiˇz 6. verze tohoto operaˇcn´ıho syst´emu. Spoleˇcnost vˇsak tak´e vyv´ıj´ı vlastn´ı hardware pod oznaˇcen´ım RouterBOARD. S´erie RouterBOARD spolu se syst´emem RouterOS je zamˇeˇrena pˇredevˇs´ım na mal´e a stˇredn´ı poskytovatele bezdr´ atov´eho Internetu.
2.4.1
Moˇ znosti konfigurace zaˇ r´ızen´ı MikroTik
Zaˇr´ızen´ı RouterBOARD nab´ızej´ı tyto moˇznosti konfigurace:
• Konzole • Telnet • SSH • API 16
´ KAPITOLA 2. ANALYZA • Web GUI • WinBox Pˇr´ıstup prostˇrednictv´ım konzole, Telnetu ˇci SSH nab´ız´ı standardn´ı CLI, kter´a poskytuje moˇznost n´ apovˇedy ˇci automatick´e doplˇ nov´an´ı pˇr´ıkaz˚ u. D´ıky intuitivnosti tohoto rozhran´ı si na nˇej lze velmi rychle zvyknout. WinBox: Jednoduch´ a utilita pro syst´emy Windows. Zobrazuje grafick´e prostˇred´ı umoˇzn ˇuj´ıc´ı konfiguraci zaˇr´ızen´ı. Jednotliv´e sekce nastaven´ı jsou co moˇzn´a nejbl´ıˇze stromu konzolov´ ych pˇr´ıkaz˚ u. Jedn´ a se o propriet´ arn´ı ˇreˇsen´ı spoleˇcnosti MikroTik a ve v´ ychoz´ım stavu je pro pˇripojen´ı na stranˇe zaˇr´ızen´ı pouˇzit port TCP 8921 [15]. WinBox nav´ıc umoˇzn ˇuje nal´ezt dostupn´a zaˇr´ızen´ı v s´ıti s vyuˇzit´ım propriet´arn´ıho protokolu MikroTik Neighbor Discovery Protokol (MNDP), coˇz je obdoba zn´amˇejˇs´ıho Cisco Discovery Protocol (CDP), kter´ y je na zaˇr´ızen´ıch tak´e podporov´ an. Za zm´ınku tak´e stoj´ı moˇznost pˇren´aˇsen´ı soubor˚ u mezi PC a zaˇr´ızen´ım MikroTik, d´ıky ˇcemuˇz lze snadno nahr´avat softwarov´e bal´ıˇcky ˇci z´alohovat konfiguraci zaˇr´ızen´ı. API: Zaˇr´ızen´ı s RouterOS nab´ızej´ı tak´e moˇznost konfigurace prostˇrednictv´ım API. Tato moˇznost je dostupn´ a od 3. verze RouterOS. Komunikace se zaˇr´ızen´ım prob´ıh´a vys´ıl´an´ım vˇet, pˇriˇcemˇz v odpovˇedi na jednu vˇetu je pˇrijata jedna nebo v´ıce vˇet. Vˇety se skl´adaj´ı ze slov a jsou ukonˇceny slovem nulov´e d´elky. Prvn´ım slovem vˇety je pˇr´ıkaz (command word ) n´asledovan´ y atributy (attribute word ) v libovoln´em poˇrad´ı [16]. Pˇr´ıkaz v sobˇe zahrnuje cestu ve stromu pˇr´ıkaz˚ u a mˇel by zaˇc´ınat znakem /. Pˇr´ıkazy striktnˇe n´asleduj´ı CLI. Jednoduch´ y pˇr´ıkaz pro proveden´ı restartu zaˇr´ızen´ı bude vypadat takto: /system/reboot. Pˇr´ıkaz s atributem pro pˇrid´an´ı IP adresy na dan´em rozhran´ı bude vypadat takto: /ip/address/add=address=192.168.1.1/24=interface=ether1=disabled=false Po zasl´an´ı kaˇzd´e vˇety vr´ at´ı zaˇr´ızen´ı alespoˇ n jednu strukturovanou odpovˇed’, kter´a bud’ informuje o u ´spˇeˇsn´em proveden´ı pˇr´ıkazu, nebo o vznikl´e chybˇe. Prvn´ı slovo odpovˇedi zaˇc´ın´ a znakem !. Ve v´ ychoz´ım nastaven´ı je pro pˇr´ıstup prostˇrednictv´ım API pouˇzit port TCP 8728. MAC-Telnet: Jedn´ a se o propriet´ arn´ı protokol spoleˇcnosti MikroTik. Jedn´a se v podstatˇe o klasick´ y Telnet, avˇsak s t´ım rozd´ılem, ˇze cel´a komunikace prob´ıh´a pouze na L2. To umoˇzn ˇuje komunikovat i se zaˇr´ızen´ım, kter´e nem´a nastavenou IP adresu a nelze k nˇemu tud´ıˇz pˇristoupit nˇekter´ ym ze standardn´ıch protokol˚ u.
2.5
Z´ akladn´ı poˇ zadavky na konfiguraci
V r´amci t´eto pr´ ace se zamˇeˇr´ım na konfiguraci pouze z´akladn´ıch parametr˚ u, kter´e umoˇzn´ı provozovat zaˇr´ızen´ı RouterBOARD v s´ıti. Zde je v´ yˇcet tˇechto parametr˚ u: 17
´ KAPITOLA 2. ANALYZA • Nastaven´ı IP adresy • Nastaven´ı DHCP serveru • Nastaven´ı Network Address Translation (NAT) • Nastaven´ı statick´ ych a dynamick´ ych cest (Routing) • Firewall
Nastaven´ı IP adresy: Nastaven´ı IP adresy zaˇr´ızen´ı pˇredstavuje z´akladn´ı pˇredpoklad pro provoz s´ıt’ov´eho zaˇr´ızen´ı. Zaˇr´ızen´ı RouterBOARD jsou v´ yluˇcnˇe smˇerovaˇce ˇci L3 pˇrep´ınaˇce (samozˇrejmˇe s v´ yjimkou bezdr´ atov´ ych Access Point˚ u), tud´ıˇz jsou vˇsechny porty konfigurovateln´e na L3 RM ISO/OSI a lze kaˇzd´emu z nich pˇriˇradit IP adresu. V r´amci t´eto pr´ace se budu vˇenovat konfigurov´ an´ı pouze v r´ amci protokolu IP verze 4. Aby byla moˇzn´a prvotn´ı konfigurace zaˇr´ızen´ı jinak neˇz s´eriovou linkou, je ve v´ ychoz´ım nastaven´ı nastavena adresa virtu´aln´ıho s´ıt’ov´eho mostu spojuj´ıc´ıho vˇsechny porty (kromˇe prvn´ıho). Tato adresa je 192.168.88.1/24. Na prvn´ım ethernetov´em portu je u nˇekter´ ych model˚ u spuˇstˇen DHCP klient. DHCP Server: DHCP server usnadˇ nuje konfiguraci klientsk´ ych zaˇr´ızen´ı, na kter´ ych nen´ı po pˇripojen´ı tˇreba nastavovat statickou IP adresu z dan´eho rozsahu. Tuto adresu obdrˇz´ı zaˇr´ızen´ı automaticky pr´ avˇe d´ıky DHCP serveru. Ve v´ ychoz´ım nastaven´ı je u vˇetˇsiny model˚ u spuˇstˇen DHCP server na Local Area Network (LAN) portech. IP adresy nab´ızen´e serverem jsou ze stejn´eho rozsahu jako je v´ ychoz´ı IP adresa, tedy 192.168.88.0/24. Nastaven´ı NAT: NAT je zp˚ usob u ´pravy s´ıt’ov´eho provozu, kter´ y umoˇzn ˇuje pˇreklad nˇekolika IP adres na jedinou adresu (pˇr´ıpadnˇe v´ıce). D´ıky tomuto pˇrekladu, kter´ y je realizov´ an pˇrepisem informac´ı obsaˇzen´ ych v hlaviˇcce IP paketu, nen´ı potˇreba aby kaˇzd´e zaˇr´ızen´ı mˇelo celosvˇetovˇe unik´ atn´ı IP adresu. Celou lok´aln´ı s´ıt’ s de facto libovoln´ ym poˇctem koncov´ ych zaˇr´ızen´ı lze vnˇejˇs´ı s´ıti prezentovat jako jedinou adresu. Tento druh pˇrekladu s´ıt’ov´ ych adres se oznaˇcuje jako Source-NAT, tedy pˇreklad na z´akladˇe zdrojov´e adresy. Smˇerovaˇc zapisuje u ´daje do NAT tabulky, d´ıky kter´e je pak na z´akladˇe ˇc´ısel port˚ u schopen urˇcit, kter´emu zaˇr´ızen´ı v lok´aln´ı s´ıti jsou pˇr´ıchoz´ı pakety urˇceny. Porty jsou v pˇr´ıpadˇe Source-NATu pˇridˇelov´any dynamicky. Lze definovat i konkr´etn´ı porty staticky a urˇcit, na kterou z lok´aln´ıch adres maj´ı b´ yt pakety pˇrich´ azej´ıc´ı na tomto portu pˇrepos´ıl´any. Tento zp˚ usob pˇrekladu se oznaˇcuje jako Destination-NAT a umoˇzn ˇuje napˇr´ıklad provozovat Web server pˇr´ıstupn´ y z Internetu uvnitˇr lok´aln´ı s´ıtˇe, bez nutnosti adresovat ho veˇrejnou (celosvˇetovˇe unik´atn´ı) IP adresou. Ve v´ ychoz´ım nastaven´ı je na zaˇr´ızen´ıch RouterBOARD nastaven Source-NAT typu Masquerade. Jedn´a se o typ Source-NATu, kter´ y umoˇzn ˇuje dynamickou zmˇenu adresy vnˇejˇs´ıho (odchoz´ıho) portu. Veˇsker´ a komunikace z lok´ aln´ı s´ıtˇe smˇeˇruj´ıc´ı mimo tuto s´ıt’ je tak pˇreloˇzena na adresu Wide Area Network (WAN) portu, tedy prvn´ıho ethernetov´eho portu. Nastaven´ı statick´ ych a dynamick´ ych cest (Routing): Bez z´aznam˚ u ve smˇerovac´ı tabulce smˇerovaˇce nen´ı moˇzn´e komunikovat mimo r´amec lok´aln´ı s´ıtˇe (stejn´eho subnetu). 18
´ KAPITOLA 2. ANALYZA Chceme-li, aby koncov´ a zaˇr´ızen´ı mohla komunikovat do dalˇs´ıch s´ıt´ı (napˇr´ıklad Internetu), je tˇreba ve smˇerovac´ı tabulce zav´est v´ ychoz´ı z´aznam, tzv. v´ ychoz´ı br´anu (Default Gateway) . Tento v´ ychoz´ı z´ aznam se skl´ ad´ a ze speci´aln´ı IP adresy 0.0.0.0/0 a adresy next-hopu, tedy adresy dalˇs´ıho zaˇr´ızen´ı ve vnˇejˇs´ı s´ıti (smˇerovaˇce), kter´ y pˇrepoˇsle vyslan´e pakety d´ale. Adresa v´ ychoz´ı br´ any je vˇetˇsinou distribuov´ana pomoc´ı DHCP. Administr´ator m´a samozˇrejmˇe moˇznost definovat dalˇs´ı, specifiˇctˇejˇs´ı z´aznamy ve smˇerovac´ı tabulce, kter´e popisuj´ı jakou cestou m´ a smˇerovaˇc pˇristupovat do definovan´e s´ıtˇe. Tyto z´aznamy se oznaˇcuj´ı jako statick´e. Za u ´ˇcelem zv´ yˇsen´ı dostupnosti poˇc´ıtaˇcov´e s´ıtˇe vˇsak bylo navrˇzeno mnoho dynamick´ ych smˇerovac´ıch protokol˚ u. D´ıky tˇemto protokol˚ um jsou soused´ıc´ı smˇerovaˇce schopn´e poskytovat informace o pˇrilehl´ ych s´ıt´ıch a na z´ akladˇe tˇechto informac´ı si kaˇzd´ y smˇerovaˇc sestav´ı ve svoj´ı smˇerovac´ı tabulce z´ aznam, popisuj´ıc´ı nejlepˇs´ı cestu do dan´e s´ıtˇe. Tyto informace jsou vys´ılany vˇetˇsinou v definovan´ ych ˇcasov´ ych intervalech nebo v pˇr´ıpadˇe zmˇeny. Z´asluhou tˇechto protokol˚ u je pak s´ıt’ odolnˇejˇs´ı napˇr´ıklad proti poruˇse nˇekter´eho prvku, protoˇze ostatn´ı smˇerovaˇce jsou schopny nal´ezt n´ ahradn´ı cestu do poˇzadovan´e s´ıtˇe (samozˇrejmˇe v pˇr´ıpadˇe ˇze takov´a cesta existuje). Dalˇs´ım typem z´ aznam˚ u v routovac´ı tabulce jsou vedle statick´ ych a dynamick´ ych tak´e tzv. Directly Connected, tedy pˇr´ımo pˇripojen´e s´ıtˇe. Smˇerovaˇc je schopen z IP adresy a s´ıt’ov´e masky urˇcit s´ıt’, do kter´e tato adresa spad´a a z´aznam o t´eto s´ıti zavede do smˇerovac´ı tabulky. Tento z´ aznam nen´ı moˇzn´e odstranit. Ve v´ ychoz´ım nastaven´ı je v´ ychoz´ı smˇerovac´ı z´aznam pˇrid´ an pouze je-li z DHCP serveru vnˇejˇs´ı s´ıtˇe, do n´ıˇz je pˇripojen prvn´ı port, z´ısk´ana adresa v´ ychoz´ı br´ any. Firewall: Firewall je filtr s´ıt’ov´e komunikace, kter´ y na z´akladˇe definovan´ ych pravidel prov´ad´ı pˇr´ısluˇsn´e akce. Mezi z´ akladn´ı akce patˇr´ı pˇredevˇs´ım povolen´ı ˇci zak´az´an´ı urˇcit´eho typu komunikace. Firewall implementovan´ y v RouterOS poskytuje velmi ˇsirok´e moˇznosti definov´an´ı pravidel a pˇr´ısluˇsn´ ych akc´ı. Ve v´ ychoz´ım nastaven´ı jsou nastavena takov´a pravidla, kter´ a umoˇzn ˇuj´ı pos´ılat pakety pouze smˇerem ven z lok´aln´ı s´ıtˇe a pˇrij´ımat pouze takov´e pakety, kter´e jsou souˇc´ ast´ı komunikace iniciovan´e lok´aln´ım zaˇr´ızen´ım.
V´ ychoz´ı konfigurace, kter´ a je obsaˇzena ve vˇetˇsinˇe zaˇr´ızen´ı RouterBOARD pˇri prvn´ım pouˇzit´ı, nebo po resetu zaˇr´ızen´ı tak umoˇzn ˇuje z´akladn´ı s´ıt’ov´ y provoz. Laicky ˇreˇceno, do zaˇr´ızen´ı staˇc´ı ve vˇetˇsinˇe pˇr´ıpad˚ u pˇripojit pˇr´ısluˇsn´e kabely a uˇzivatel bude m´ıt pˇr´ıstup do vnˇejˇs´ı s´ıtˇe (napˇr´ıklad Internetu). Tato konfigurace vˇsak pˇredstavuje pouze nezbytn´ y z´aklad a mˇela by b´ yt upravena dle konkr´etn´ıch potˇreb v souvislosti s topologi´ı s´ıtˇe.
2.6
Shrnut´ı a vyhodnocen´ı poznatk˚ u
V r´amci t´eto kapitoly jsem se snaˇzil nast´ınit moˇzn´e pˇr´ıstupy k uchopen´ı problematiky automatizovan´e konfigurace zaˇr´ızen´ı RouterBOARD s vyuˇzit´ım n´astroje Ansible. Pro pˇr´ıstup k zaˇr´ızen´ım by pˇripadalo v u ´vahu vyuˇzit´ı protokolu SSH ˇci API, protoˇze ostatn´ı moˇznosti 19
´ KAPITOLA 2. ANALYZA pˇr´ıstupu ned´ avaj´ı prostor jejich pˇr´ıpadn´emu automatizov´an´ı pro vyuˇzit´ı s v´ıce zaˇr´ızen´ımi. Vzhledem k tomu, ˇze Ansible vyˇzaduje na koncov´ ych zaˇr´ızen´ıch podporu jazyka Python, je bohuˇzel vˇetˇsina existuj´ıc´ıch modul˚ u k ˇreˇsen´ı m´eho probl´emu nepouˇziteln´a. Z tohoto d˚ uvodu je tedy nezbytn´e, vytvoˇrit moduly spouˇstˇen´e pouze lok´alnˇe, kter´e budou samy realizovat pˇr´ıstup k zaˇr´ızen´ı MikroTik. Za t´ımto u ´ˇcelem by samozˇrejmˇe bylo moˇzn´e vyuˇz´ıt existuj´ıc´ı knihovny pro komunikaci v r´ amci protokolu SSH, avˇsak vzhledem ke skuteˇcnosti, ˇze pˇr´ıkazov´a ˇr´adka MikroTiku je navrˇzena prim´ arnˇe pro lidskou interakci, neposkytuje vhodnˇe strukturovan´ y v´ ystup, kter´ y by bylo moˇzn´e v r´ amci modul˚ u dobˇre uchopit. Z tohoto d˚ uvodu jsem se tedy pro realizaci rozhodl vyuˇz´ıt API, kter´e bylo navrˇzeno pr´avˇe za u ´ˇcelem programovatelnˇe uchopiteln´e konfigurace a poskytuje strukturovan´ y v´ ystup. Pˇri volbˇe programovac´ıho jazyka pro moduly byl Python takˇrka jedinou volbou. Ansible sice umoˇzn ˇuje, aby byly moduly ps´ any v libovoln´em jazyce a klade n´aroky pouze na jejich spr´avnˇe strukturovan´ y v´ ystup, avˇsak vzhledem k tomu, ˇze s´am Ansible je ps´an v jazyce Python, poskytuje pro tento jazyk mnoho knihoven a procedur, kter´e usnadˇ nuj´ı tvorbu dalˇs´ıch modul˚ u.
20
Kapitola 3
Realizace V t´eto kapitole se budu vˇenovat detailn´ımu popisu mnou navrˇzen´eho ˇreˇsen´ı vˇcetnˇe konkr´etn´ıch pˇr´ıklad˚ u pouˇzit´ı. Pˇredstav´ım zde z´ akladn´ı funkce a moduly a pˇr´ıklady jejich pouˇzit´ı v r´amci Ansiblu. Na zaˇc´ atek bych vˇsak r´ ad poskytnul ˇsirˇs´ı pohled na celkov´e ˇreˇsen´ı. M´e ˇreˇsen´ı pˇredpokl´ad´ a tvorbu modul˚ u pro Ansible, pˇriˇcemˇz kaˇzd´ y modul je zamˇeˇren na jedno specifick´e odvˇetv´ı konfigurace zaˇr´ızen´ı s RouterOS. Kupˇr´ıkladu jeden modul bude urˇcen pro nastaven´ı IP adresy na konkr´etn´ım portu, jin´ y modul bude umoˇzn ˇovat nastaven´ı statick´eho smˇerov´an´ı, dalˇs´ı modul bude nastavovat DHCP server a tak d´ale. Prim´arn´ım u ´kolem takov´ ychto modul˚ u je pˇredevˇs´ım sestavit ze zadan´ ych parametr˚ u pˇr´ıkazy vhodn´e pro konfiguraci zaˇr´ızen´ı a n´ aslednˇe poskytnout korektnˇe strukturovan´ y v´ ystup pro Ansible. Kromˇe tˇechto specificky zamˇeˇren´ ych modul˚ u je vˇsak tak´e tˇreba vytvoˇren´ı jedn´e nebo v´ıce funkc´ı, kter´e budou obstar´ avat samotnou komunikaci se zaˇr´ızen´ım a prov´adˇet pˇr´ıkazy z´ıskan´e z jednotliv´ ych modul˚ u. Tyto funkce budou tedy p˚ usobit jako jak´asi spojn´a vrstva mezi konfigurovan´ ymi zaˇr´ızen´ımi a jednotliv´ ymi moduly, pˇriˇcemˇz budou do zaˇr´ızen´ı pos´ılat konfiguraˇcn´ı pˇr´ıkazy z´ıskan´e z modul˚ u a naopak pˇred´ avat v´ ystup ze zaˇr´ızen´ı modul˚ um.
3.1
MikroTik API
Jiˇz v minul´e kapitole bylo zm´ınˇeno, ˇze pro pˇr´ıstup ke konfiguraci s´ıt’ov´ ych zaˇr´ızen´ı je tˇreba navrhnout vlastn´ı zp˚ usob pˇripojen´ı, v tomto pˇr´ıpadˇe pˇripojen´ı skrze API. Dokumentace k API na zaˇr´ızen´ıch s RouterOS je pomˇernˇe rozs´ahl´a a dobˇre popisuje veˇsker´e poˇzadavky a vlastnosti tohoto rozhran´ı [16]. Nav´ıc je zde pˇr´ımo dostupn´a knihovna pro komunikaci skrze API v jazyce Python. Na serveru GitHub je dostupn´a vylepˇsen´a verze t´eto knihovny [17], jej´ımˇz autorem je Piotr Skamruk, vystupuj´ıc´ı pod pseudonymem jellonek. Tato knihovna poskytuje funkce pro pˇripojen´ı k zaˇr´ızen´ı MikroTik, sestavov´an´ı a pos´ıl´an´ı ˇr´ıd´ıc´ıch vˇet a pˇrij´ım´an´ı a zpracov´ an´ı odpovˇed´ı. Tuto knihovnu jsem pouˇzil v r´amci sv´e pr´ace jako z´akladn´ı k´amen pro komunikaci s koncov´ ymi zaˇr´ızen´ımi. 21
KAPITOLA 3. REALIZACE
3.2
Z´ akladn´ı funkce
Funkce a tˇr´ıdy popsan´e v t´eto ˇc´ asti pˇredstavuj´ı sd´ılen´e ˇc´asti celkov´eho ˇreˇsen´ı. Jejich u ´kolem je prov´adˇet u ´kony spoleˇcn´e pro vˇsechny (nebo nˇekter´e) moduly. Potˇrebn´e funkce jsou naimportov´any do pˇr´ısluˇsn´ ych modul˚ u. Ansible vyˇzaduje, aby tyto sd´ılen´e moduly byly um´ıstˇeny ve sloˇzce module utils. RosCore: Obsahuje tˇr´ıdu Core, jej´ımˇz autorem je jiˇz dˇr´ıve zm´ınˇen´ y Piotr Skamur. Obsahuje funkce pro komunikaci s RouterOS zaˇr´ızen´ımi a strukturalizaci odpovˇed´ı. RosAPI: V tomto souboru jsou obsaˇzen´e nˇekter´e ze z´akladn´ıch sd´ılen´ ych funkc´ı, z nichˇz nejd˚ uleˇzitˇejˇs´ı je funkce je API, kter´a poskytuje logiku nezbytnou k naplnˇen´ı poˇzadavku na kaˇzd´ y modul Ansiblu, idempotenci. To znamen´a, ˇze zmˇeny jsou provedeny pouze pokud souˇcasn´ y stav neodpov´ıd´ a stavu poˇzadovan´emu. Funkce API pˇrij´ım´a n´asleduj´ıc´ı parametry: • path - Pˇredstavuje cestu ve stromu pˇr´ıkaz˚ u konfigurace RouterOS. Tato cesta vˇzdy zaˇc´ın´ a i konˇc´ı znam´enkem /. Struktura cest kop´ıruje strukturu zn´amou z prostˇred´ı CLI, pouze mezery jsou nahrazeny znakem /. Kupˇr´ıkladu cesta vedouc´ı k nastaven´ı ethernetov´ ych port˚ u bude vypadat takto: /interface/ethernet/ • action - Pˇredstavuje poˇzadovan´ y pˇr´ıkaz. Spolu s parametrem path tvoˇr´ı tzv. commandword. Mezi typick´e pˇr´ıkazy patˇr´ı napˇr´ıklad: print, add, set, remove, enable, disable. Pˇrid´ an´ım pˇr´ıkazu print k cestˇe uveden´e v pˇredchoz´ım bodu tak z´ısk´ame pˇr´ıkaz pro v´ ypis vˇsech existuj´ıc´ıch ethernetov´ ych port˚ u: /interface/ethernet/print • hostname - Pˇredstavuje jm´eno koncov´eho zaˇr´ızen´ı nebo jeho IP adresu. Tento parametr tedy ud´ av´ a, ke kter´emu zaˇr´ızen´ı se hodl´ame pˇripojit. • username - Uˇzivatelsk´e jm´eno nezbytn´e pro pˇrihl´aˇsen´ı do zaˇr´ızen´ı. Nen´ı-li poskytnuto, je pouˇzita v´ ychoz´ı hodnota admin. • password - Uˇzivatelsk´e heslo nezbytn´e pro pˇrihl´aˇsen´ı do zaˇr´ızen´ı. Nen´ı-li poskytnuto, je pouˇzita v´ ychoz´ı hodnota, kterou je pr´azdn´e heslo. • command - T´ımto parametrem je asociativn´ı pole, jehoˇz kl´ıˇce pˇredstavuj´ı poˇzadovan´e atributy nastaven´ı a hodnoty jsou poˇzadovan´e hodnoty tˇechto atribut˚ u. Jako pˇr´ıklad vezmˇeme sadu atribut˚ u potˇrebn´ ych pro nastaven´ı IP adresy na zvolen´em portu zaˇr´ızen´ı. Pro takov´ y pˇr´ıpad m˚ uˇze parametr command vypadat napˇr´ıklad takto: {"address": "192.168.1.1/24", "interface": "ether1", "disabled": "false"}. • port - Tento parametr pˇredstavuje TCP port, na kter´em je provozov´ano API. V´ ychoz´ı hodnota tohoto parametru je 8728. Na tomto portu je na zaˇr´ızen´ıch MikroTik ve v´ ychoz´ım stavu spuˇstˇena sluˇzba API. • DEBUG - Hodnotou tohoto parametru jsou booleovsk´e hodnoty True a False. Tento parametr slouˇz´ı pouze k testovac´ım u ´ˇcel˚ um a odstranˇen´ı pˇr´ıpadn´ ych chyb poskytnut´ım 22
KAPITOLA 3. REALIZACE dodateˇcn´eho v´ ystupu. Parametr nelze pouˇz´ıt pˇri spouˇstˇen´ı modulu pomoc´ı Ansiblu, protoˇze generovan´ y v´ ystup nem´a poˇzadovanou strukturu.
V prvn´ım kroku porovn´ a funkce API souˇcasn´ y stav zaˇr´ızen´ı s poˇzadovan´ ym stavem pomoc´ı pˇr´ıkazu print pro danou cestu a funkce changeCheck. Odpov´ıd´a-li souˇcasn´ y stav konfigurace poˇzadovan´emu, nen´ı potˇreba prov´adˇet ˇz´adn´e zmˇeny a odpov´ıdaj´ıc´ı v´ ystup je vr´acen pˇr´ısluˇsn´emu modulu. Funkce changeCheck m´a z´aroveˇ n za u ´kol urˇcit, zdali existuje objekt, kter´ y m´a nejv´ıce shodn´ ych atribut˚ u s pˇr´ıkazem. Napˇr´ıklad bude-li pˇr´ıkaz poˇzadovat nastaven´ı IP adresy na portu ether1, funkce changeCheck urˇc´ı, zdali jiˇz na dan´em portu nen´ı nastavena IP adresa. V pˇr´ıpadˇe, ˇze na portu ether1 je jiˇz nastavena jin´a adresa, je tˇreba prov´est jej´ı zmˇenu pˇr´ıkazem set s parametrem ID pro dan´ y objekt (port ether1 ). Pokud nen´ı nalezen podobn´ y objekt (v tomto pˇr´ıpadˇe objekt obsahuj´ıc´ı atribut interface=ether1), bude adresa na pˇr´ısluˇsn´ y port nastavena pomoc´ı pˇr´ıkazu add. V´ yvojov´ y diagram funkce API je uveden na obr´azku 3.1.
Parametry funkce API
Poslání sestavené věty
Zavolání funkce API
Přidej požadované atributy
Vytvření připojení k požadovanému zařízení
PRINT pro zadanou cestu
Přihlášení
Nastav parametr ADD
NE
Akce == SET?
NE
Existuje podobný objekt?
Akce == PRINT?
Výstup příkazu PRINT neodpovídá požadovanému stavu
NE
ANO
Ukončení FAILED = False Changed = False
Výstup příkazu PRINT odpovídá požadovanému stavu Ukončení FAILED = False Changed = False
Funkce changeCheck
ANO
PRINT pro zadanou cestu
Nastav parametr SET
ANO
Pro případ takových nastavení, která neobsahují objekty, například DNS
NE
Existují ID v odpovědi?
NE
ANO
Obsahuje příkaz NAME?
Nastav parametr SET + ID
ANO
Příkaz(NAME) == ID(NAME)
Funkce changeCheck
NE
ANO
Výstup příkazu PRINT neodpovídá požadovanému stavu
Ukončení FAILED True
Výstup příkazu PRINT odpovídá požadovanému stavu
Ukončení FAILED False CHANGED True
Obr´ azek 3.1: RosAPI Flowchart RosRaw: Tento sd´ılen´ y modul pˇrij´ım´a stejn´e parametry jako modul RosAPI, avˇsak na rozd´ıl od tohoto modulu neobsahuje logiku pro kontrolu souˇcasn´eho stavu konfigurace zaˇr´ızen´ı. Tento modul slouˇz´ı pouze pro vysl´an´ı pˇresnˇe definovan´ ych pˇr´ıkaz˚ u do zaˇr´ızen´ı a pˇred´av´ a pˇr´ısluˇsn´ y v´ ystup nadˇrazen´emu modulu, kter´ y pak na z´akladˇe vlastn´ı logiky provede dalˇs´ı operace. Parametr command v pˇr´ıpadˇe tohoto modulu nen´ı asociativn´ım polem, ale pouze seznamem konkr´etn´ıch, pˇresnˇe definovan´ ych atribut˚ u.
23
KAPITOLA 3. REALIZACE
3.3 3.3.1
Moduly Ansible Spoleˇ cn´ e znaky Ansible modul˚ u
Ansible klade n´ aroky pˇredevˇs´ım na korektnˇe strukturovan´ y v´ ystup modulu. Tento v´ ystup mus´ı b´ yt ve form´ atu JavaScript Object Notation (JSON). Modul mus´ı poskytnout Ansiblu informace o tom, zda poˇzadovan´ a akce probˇehla v poˇr´adku, a zda doˇslo ke zmˇen´am v konfiguraci zaˇr´ızen´ı ˇci nikoliv. Za t´ımto u ´ˇcelem mus´ı vr´atit alespoˇ n dvˇe promˇenn´e failed a changed, jejichˇz hodnotny jsou True ˇci False. Tvorba modul˚ u v jazyce Python je usnadnˇena t´ım, ˇze Ansible nab´ız´ı procedury pro zpracov´an´ı vstupn´ıch parametr˚ u a pro vr´acen´ı korektnˇe strukturovan´eho v´ ystupu. Kaˇzd´ y modul psan´ y v Pythonu tak potˇrebuje nejdˇr´ıve naimportovat sadu z´akladn´ıch funkc´ı pˇr´ıkazem: from ansible.module utils.basic import * D´ale kaˇzd´ y modul obsahuje seznam podporovan´ ych parametr˚ u. Jedn´a se o asociativn´ı pole, v nˇemˇz jsou uvedeny jednotliv´e parametry a jejich moˇznosti. Ansible napˇr´ıklad umoˇzn ˇuje nastaven´ı v´ ychoz´ı hodnoty parametru, aliasy parametr˚ u a podobnˇe. Je tak´e napˇr´ıklad moˇzn´e definovat, kter´e parametry je nezbytn´e zadat, pˇr´ıpadnˇe jak´e dalˇs´ı parametry je tˇreba zadat v souvislosti s konkr´etn´ım parametrem. Na uk´azce n´ıˇze 3.1 je uvedena ˇc´ast k´odu poch´azej´ıc´ı z modulu pro nastaven´ı IP adresy. Uk´azka neobsahuje samotnou logiku modulu, kter´a vol´ a se zadan´ ymi parametry funkci API a na z´akladˇe odpovˇedi pˇred´a Ansiblu pˇr´ısluˇsn´ y v´ ystup. #! / u s r / b i n / python # Import A n s i b l e module p a r a m e t e r s a n s i b l e = AnsibleModule ( a r g u m e n t s p e c=d i c t ( hostname=d i c t ( r e q u i r e d=F a l s e , type= ’ s t r ’ , a l i a s e s =[ ” h o s t ” ] ) , username=d i c t ( r e q u i r e d=F a l s e , type= ’ s t r ’ , a l i a s e s =[” u s e r ” ] ) , password=d i c t ( r e q u i r e d=F a l s e , type= ’ s t r ’ , a l i a s e s =[ ” p a s s ” ] ) , p o r t=d i c t ( r e q u i r e d=F a l s e , type= ’ i n t ’ , d e f a u l t =8728) , a d d r e s s=d i c t ( r e q u i r e d=F a l s e , type= ’ s t r ’ , a l i a s e s =[ ’ i p ’ , ’ addr ’ ] ) , i n t e r f a c e=d i c t ( r e q u i r e d=True , type= ’ s t r ’ , a l i a s e s =[ ’ i n t ’ ] ) , d i s a b l e d=d i c t ( r e q u i r e d=F a l s e , type= ’ s t r ’ , c h o i c e s =[ ’ t r u e ’ , ’ f a l s e ’ ] ) ), s u p p o r t s c h e c k m o d e=F a l s e , ) d e f main ( ) : from a n s i b l e . m o d u l e u t i l s . RosAPI import API from a n s i b l e . m o d u l e u t i l s . RosAPI import i nt C h e c k # I n i t i a l i z e phase # Required p a r a m e t e r s hostname = a n s i b l e . params [ ’ hostname ’ ] username = a n s i b l e . params [ ’ username ’ ] password = a n s i b l e . params [ ’ password ’ ] p o r t = a n s i b l e . params [ ’ p o r t ’ ]
24
KAPITOLA 3. REALIZACE path = ” / i p / a d d r e s s / ” a c t i o n = ”” command = { ” a d d r e s s ” : a n s i b l e . params [ ’ a d d r e s s ’ ] , \ ” i n t e r f a c e ” : a n s i b l e . params [ ’ i n t e r f a c e ’ ] } # # Module l o g i c ommited # from a n s i b l e . m o d u l e u t i l s . b a s i c import ∗ if
name == ’ main ( )
main
’:
K´ od 3.1: Uk´azka modulu v jazyce Python
3.3.2
Popis jednotliv´ ych modul˚ u
Seznam podporovan´ ych parametr˚ u je vˇzdy uveden na zaˇc´atku zdrojov´eho k´odu modulu. V t´eto sekci proto jen vysvˇetl´ım, k ˇcemu kter´ y modul slouˇz´ı. Parametry modul˚ u se snaˇz´ı co nejpˇresnˇeji kop´ırovat pˇr´ıkazy zn´ am´e z CLI, coˇz by mˇelo zkuˇsenˇejˇs´ımu uˇzivateli usnadnit pr´aci s nimi. Pomlˇcky v n´ azvech konfiguraˇcn´ıch parametr˚ u jsou nahrazov´any podtrˇz´ıtky, jelikoˇz syntaxe jazyka YAML nepovoluje pomlˇcky u kl´ıˇcov´ ych hodnot. avu IP adres pˇriˇrazen´ ych zvolen´ ym s´ıt’ov´ ym rozhran´ım. mt ip: Tento modul slouˇz´ı pro spr´ Modul nejdˇr´ıve provede kontrolu, zdali vybran´e rozhran´ı existuje a nen´ı-li zadan´a IP adresa jiˇz nastavena na jin´em rozhran´ı. Pot´e provede nastaven´ı IP adresy. u pro konfiguraci DHCP serveru. Tento modul mt dhcp net: Jeden z celkem tˇr´ı modul˚ zajiˇst’uje vytvoˇren´ı s´ıtˇe pro DHCP server. ´kolem je vytv´aˇren´ı adresn´ıho mt ip pool: Dalˇs´ı modul pro konfiguraci DHCP serveru, jehoˇz u poolu pro server. mt dhcp srv: Posledn´ı modul pro konfiguraci DHCP serveru, jehoˇz u ´kolem je pˇredevˇs´ım nastavit informace poskytovan´e serverem, tedy napˇr´ıklad adresu v´ ychoz´ı br´any, Domain Name System (DNS) serveru, NTP serveru a podobnˇe. Jedn´ım z parametr˚ u tohoto modulu je port, na kter´em m´ a b´ yt server provozov´ an. mt dns: Jednoduch´ y modul pro nastaven´ı parametr˚ u DNS serveru na zaˇr´ızen´ı. Umoˇzn ˇuje nastavit adresy dalˇs´ıch server˚ u a ukl´ad´an´ı z´aznam˚ u v lok´aln´ı pamˇeti. mt fetch: Tento modul zprostˇredkov´av´a interakci s funkc´ı fetch. Tato funkce umoˇzn ˇuje stahov´an´ı ˇci nahr´ av´ an´ı datov´ ych soubor˚ u pˇr´ımo ze zaˇr´ızen´ı. S vyuˇzit´ım tohoto modulu je moˇzn´e pˇristupovat k FTP ˇci HTTP serveru, napˇr´ıklad za u ´ˇcelem staˇzen´ı aktualizaˇcn´ıch bal´ıˇck˚ u ˇci nahr´an´ı z´ aloh konfigurace. Pomoc´ı tohoto modulu je tak moˇzn´e napˇr´ıklad stahovat sloˇzit´e konfiguraˇcn´ı skripty z FTP serveru. mt static route: Modul pro pˇrid´ av´an´ı statick´ ych smˇerovac´ıch z´aznam˚ u. Logick´ ymi para25
KAPITOLA 3. REALIZACE metry jsou proto adresa c´ılov´e s´ıtˇe a adresa next-hopu. Tento modul tak slouˇz´ı napˇr´ıklad pro nastaven´ı v´ ychoz´ı br´ any. mt nat: Modul pro spr´ avu nastaven´ı pˇrekladu s´ıt’ov´ ych adres. Umoˇzn ˇuje nastaven´ı pˇrekladu na z´akladˇe zdrojov´e adresy (Source-NAT) ˇci c´ılov´e adresy (Destination-NAT). Pomoc´ı tohoto modulu je tak napˇr´ıklad moˇzn´e nastavit zdrojov´ y NAT typu masquerade na portu smˇeˇruj´ıc´ım do veˇrejn´e s´ıtˇe, ˇci nastavit pˇresmˇerov´an´ı pˇr´ıchoz´ı komunikace na zaˇr´ızen´ı v m´ıstn´ı s´ıti. mt firewall: Modul spravuj´ıc´ı nastaven´ı pravidel firewallu. Poskytuje pouze z´akladn´ı moˇznosti nastaven´ı s vyuˇzit´ım odchoz´ıch a pˇr´ıchoz´ıch port˚ u zaˇr´ızen´ı, zdrojov´ ych a c´ılov´ ych adres a TCP/UDP port˚ u, ˇci stavu spojen´ı. ˇuj´ıc´ı nastaven´ı dynamick´eho smˇerovac´ıho protokolu Router Informt rip: Modul umoˇzn mation Protocol (RIP). Pomoc´ı tohoto modulu je moˇzn´e nastavit, kter´e s´ıtˇe se maj´ı propagovat a skrze kter´e porty zaˇr´ızen´ı. Kromˇe konkr´etn´ıch s´ıt´ı je tak´e moˇzn´e nastavit propagaci pˇr´ımo pˇripojen´ ych s´ıt´ı, statick´ ych smˇerovac´ıch z´aznam˚ u ˇci z´aznam˚ u z´ıskan´ ych prostˇrednictv´ım dalˇs´ıch dynamick´ ych smˇerovac´ıch protokol˚ u. ych most˚ u. Vytv´aˇren´ı s´ıt’ov´ ych most˚ u umoˇzn ˇuje spomt brctl: Modul pro konfiguraci s´ıt’ov´ jit v´ıce port˚ u zaˇr´ızen´ı do jednoho logick´eho portu. Tohoto modulu lze vyuˇz´ıt napˇr´ıklad pˇri vytv´aˇren´ı virtu´ aln´ıch lok´ aln´ıch s´ıt´ı. Ty totiˇz na zaˇr´ızen´ıch MikroTik vyˇzaduj´ı vytvoˇren´ı individu´aln´ıch most˚ u, do kter´ ych jsou pot´e pˇrid´any vybran´e porty. mr raw: Tento modul poskytuje moˇznost vysl´an´ı libovoln´eho pˇr´ıkazu do zaˇr´ızen´ı. Vyˇzaduje pˇresnou syntaxi poˇzadovan´eho pˇr´ıkazu a neobsahuje ˇz´adnou logiku pro kontrolu a zpracov´an´ı odpovˇed´ı. Slouˇz´ı pˇredevˇs´ım pro jednoduch´e u ´kony, jako napˇr´ıklad restart zaˇr´ızen´ı, spuˇstˇen´ı skriptu ˇci pˇrid´ an´ı uˇzivatelsk´eho u ´ˇctu.
3.4
Prvotn´ı konfigurace
Jedn´ım z poˇzadavk˚ u pˇri realizaci problematiky t´eto pr´ace je tak´e navrˇzen´ı postupu pro konfiguraci zaˇr´ızen´ı, kter´ a se nach´ azej´ı ve v´ ychoz´ım tov´arn´ım nastaven´ı. Konfigurace v tomto stavu je pops´ ana v kapitole 2.5. V d˚ usledku tohoto nastaven´ı, nen´ı moˇzn´e pˇristoupit ke konfiguraci vˇetˇs´ıho poˇctu zaˇr´ızen´ı MikroTik pˇr´ımo pomoc´ı API, pˇredevˇs´ım proto, ˇze vˇsechna zaˇr´ızen´ı maj´ı nastavenou stejnou IP adresu, 192.168.88.1/24. V d˚ usledku toho nen´ı moˇzn´e jednoznaˇcnˇe urˇcit MAC adresu poj´ıc´ı se k adrese 192.168.88.1/24, coˇz je nezbytn´ y pˇredpoklad pro komunikaci na L2. Komunikace mezi zaˇr´ızen´ımi na L3 se v takov´em pˇr´ıpadˇe st´av´a zcela nepˇredv´ıdatelnou. Situace je demonstrov´ana na obr´azku 3.2. Address Resolution Protocol (ARP) dotaz ze stanice s Ansible serverem vyvol´a odpovˇedi od vˇsech tˇr´ı smˇerovaˇc˚ u.
26
KAPITOLA 3. REALIZACE
192.168.88.1 je na: D4:CA:6D:AA:BB:11
Router1 IP: 192.168.88.1/24 MAC: D4:CA:6D:AA:BB:11 192.168.88.1 je na: D4:CA:6D:CC:DD:22
Ansible Server IP: 192.168.88.200 MAC: 00:11:22:33:44:55
Přepínač
Router2 IP: 192.168.88.1/24 MAC: D4:CA:6D:CC:DD:22 192.168.88.1 je na: D4:CA:6D:EE:FF:33
Router3 IP: 192.168.88.1/24 MAC: D4:CA:6D:EE:FF:33
Obr´ azek 3.2: Konflikt IP adres Zaˇr´ızen´ı MikroTik naˇstˇest´ı umoˇzn ˇuj´ı konfiguraci i bez nastaven´e IP adresy prostˇrednictv´ım propriet´arn´ıho protokolu MAC-Telnet. V naˇsem pˇr´ıpadˇe je tedy moˇzn´e nastavit na zaˇr´ızen´ıch unik´atn´ı IP adresu pomoc´ı MAC-Telnetu, coˇz umoˇzn´ı dalˇs´ı pˇr´ıstup skrze API. Klient pro MAC-Telnet je dostupn´ y na serveru GitHub a jeho autorem je H˚ akon Nessjøen [18]. Bohuˇzel se mi vˇsak nepodaˇrilo vytvoˇrit modul pro Ansible v jazyce Python, kter´ y by dok´azal v r´amci vol´an´ı podproces˚ u vyuˇz´ıt MAC-Telnet pro komunikaci se zaˇr´ızen´ımi. Byl jsem proto nucen ustoupit k jedin´emu funkˇcn´ımu ˇreˇsen´ı, kter´e vyuˇz´ıv´a jednoduch´eho expect skriptu a na z´akladˇe zadan´ ych parametr˚ u provede pouze nejz´akladnˇejˇs´ı pˇr´ıkazy. Jedn´a se o skripty mtbash clean, kter´ y vynut´ı restart zaˇr´ızen´ı bez nahr´an´ı v´ ychoz´ı konfigurace a mtbash default, kter´ y na z´akladˇe vstupn´ıch parametr˚ u nastav´ı IP adresu na zvolen´em portu, nastav´ı jm´eno zaˇr´ızen´ı a vytvoˇr´ı nov´ y uˇzivatelsk´ yu ´ˇcet. Situaci nyn´ı popisuje obr´azek 3.3. 192.168.88.10 je na: D4:CA:6D:AA:BB:11
Router1 IP: 192.168.88.10/24 MAC: D4:CA:6D:AA:BB:11 192.168.88.20 je na: D4:CA:6D:CC:DD:22
Ansible Server IP: 192.168.88.200 MAC: 00:11:22:33:44:55
Přepínač
Router2 IP: 192.168.88.20/24 MAC: D4:CA:6D:CC:DD:22 192.168.88.30 je na: D4:CA:6D:EE:FF:33
Router3 IP: 192.168.88.30/24 MAC: D4:CA:6D:EE:FF:33
Obr´ azek 3.3: Situace po konfiguraci prostˇrednictv´ım MAC-Telnetu
27
KAPITOLA 3. REALIZACE
3.5
Invent´ aˇ r
Invent´aˇr Ansiblu je ve sv´e podstatˇe seznamem vˇsech zn´am´ ych uzl˚ u. Typicky se jedn´a o soubor se jm´enem hosts. Uvnitˇr tohoto souboru mohou b´ yt uzly rozdˇelen´e do skupin, pˇr´ıpadnˇe zde lze uv´est libovoln´e parametry jednotliv´ ych uzl˚ u ˇci skupin. Je vˇsak dobr´ ym zvykem ukl´adat u ´daje o uzlech do samostatn´ ych soubor˚ u, kter´e jsou um´ıstˇeny ve sloˇzce host vars, pˇriˇcemˇz jm´eno kaˇzd´eho souboru je jm´enem dan´eho uzlu. Obdobnˇe lze zapsat parametry t´ ykaj´ıc´ı se skupiny uzl˚ u do souboru, jehoˇz jm´enem je n´azev skupiny a tento soubor um´ıstit do sloˇzky group vars. Pˇr´ıklad souboru hosts pro situaci z obr´azku 3.3 m˚ uˇze vypadat takto: [ routers ] Router1 IP = 1 9 2 . 1 6 8 . 8 8 . 1 0 Router2 IP = 1 9 2 . 1 6 8 . 8 8 . 2 0 Router3 IP = 1 9 2 . 1 6 8 . 8 8 . 3 0 [ routers : vars ] username=admin password=”” a p i p o r t =8728
K´ od 3.2: Pˇr´ıklad statick´eho invent´aˇre s parametry
Invent´aˇr tvoˇr´ı skupina routers se tˇremi uzly, Router1, Router2 a Router3, z nichˇz kaˇzd´ y m´ a jako jeden z parametr˚ u uvedenou svoji IP adresu. D´ale je zde vidˇet sekce se skupinov´ ymi parametry. Vˇsechny uzly pouˇz´ıvaj´ı pro pˇrihl´aˇsen´ı v´ ychoz´ı jm´eno a heslo.
3.5.1
Dynamick´ y invent´ aˇ r
Ansible je velmi robustn´ı n´ astroj navrˇzen´ y pro spr´avu stovek aˇz tis´ıc˚ u koncov´ ych uzl˚ u. Spravovat statick´ y invent´ aˇr ruˇcnˇe pro takov´eto poˇcty uzl˚ u by bylo nemoˇzn´e. Proto Ansible nab´ız´ı vyuˇzit´ı tzv. dynamick´eho invent´aˇre (dynamic inventory), coˇz je skript, kter´ y nˇejak´ ym zp˚ usobem z´ısk´ a informace o uzlech. Opˇet plat´ı, ˇze tento skript m˚ uˇze b´ yt naps´an v libovoln´em jazyce, pouze mus´ı vracet strukturovan´ y JSON form´at do standardn´ıho v´ ystupu. Tento v´ ystup je pak pˇrevzat Ansiblem a pouˇzit jako invent´aˇr. Pro usnadnˇen´ı konfigurace vˇetˇs´ıho poˇctu zaˇr´ızen´ı MikroTik jsem vytvoˇril skript pro generov´an´ı dynamick´eho invent´ aˇre. Skript pouˇz´ıv´a k nalezen´ı zaˇr´ızen´ı v s´ıti informace z CDP protokolu a tyto informace n´ aslednˇe pˇred´a Ansiblu. Jelikoˇz jm´eno kaˇzd´eho uzlu mus´ı b´ yt unik´atn´ı, nelze vˇzdy pouˇz´ıt jako jm´eno uzlu jm´eno nastaven´e v zaˇr´ızen´ı. To plat´ı pˇredevˇs´ım v pˇr´ıpadˇe, ˇze se snaˇz´ıme nakonfigurovat v´ıce zaˇr´ızen´ı, kter´a se nach´azej´ı v tov´arn´ım nastaven´ı. V takov´em pˇr´ıpadˇe pouˇzije skript jako jm´eno uzlu zdrojovou MAC adresu. Pˇr´ıklad v´ ystupu skriptu cdp discovery pro situaci z obr´azku 3.2 bude vypadat takto:
28
KAPITOLA 3. REALIZACE { ” meta ” : { ” hostvars ”:{ ” d4 : ca : 6 d : aa : bb : 1 1 ” : { ”ID ” : ” MikroTik ” , ” IP ” : ” 1 9 2 . 1 6 8 . 8 8 . 1 ” , ” P l a t f o r m ” : ” MikroTik ” , ” Port ” : ” e t h e r 1 ” , ”Source MAC ” : ” d4 : ca : 6 d : aa : bb : 1 1 ” , ” Version ” : ” 6 . 3 2 . 3 ” }, ” d4 : ca : 6 d : c c : dd : 2 2 ” : { ”ID ” : ” MikroTik ” , ” IP ” : ” 1 9 2 . 1 6 8 . 8 8 . 1 ” , ” P l a t f o r m ” : ” MikroTik ” , ” Port ” : ” e t h e r 1 ” , ”Source MAC ” : ” d4 : ca : 6 d : c c : dd : 2 2 ” , ” Version ” : ” 6 . 3 2 . 3 ” }, ” d4 : ca : 6 d : e e : f f : 3 3 ” : { ”ID ” : ” MikroTik ” , ” IP ” : ” 1 9 2 . 1 6 8 . 8 8 . 1 ” , ” P l a t f o r m ” : ” MikroTik ” , ” Port ” : ” e t h e r 1 ” , ”Source MAC ” : ” d4 : ca : 6 d : e e : f f : 3 3 ” , ” Version ” : ” 6 . 3 2 . 3 ” }, } }, ” mikrotiks ”:{ ” hosts ” : [ ” d4 : ca : 6 d : aa : bb : 1 1 ” , ” d4 : ca : 6 d : c c : dd : 2 2 ” , ” d4 : ca : 6 d : e e : f f : 3 3 ” ], ” vars ”:{ ” default password ”:”” , ” d e f a u l t u s e r ” : ” admin” } } }
K´ od 3.3: Pˇr´ıklad v´ ystupu skriptu pro dynamick´ y invent´aˇr
Z v´ ystupu je patrn´e, ˇze vˇsechna nalezen´a zaˇr´ızen´ı se stala souˇc´ast´ı skupiny mikrotiks. Objekt meta slouˇz´ı pro pˇred´ an´ı informac´ı o jednotliv´ ych uzlech. Skript nav´ıc pˇrid´av´a v´ ychoz´ı jm´eno a heslo do skupinov´ ych promˇenn´ ych. Aby nebylo nutn´e spouˇstˇet skript pˇri kaˇzd´e zmˇenˇe konfigurace, lze jej vyuˇz´ıt jako z´ akladn´ı k´amen pro vytvoˇren´ı statick´eho invent´aˇre. Staˇc´ı pouze pˇredat strukturovan´ y v´ ystup z pˇr´ıkladu 3.3 dalˇs´ımu skriptu, kter´ y tento v´ ystup pouˇzije k vytvoˇren´ı statick´eho invent´ aˇre. Autorem tohoto skriptu je David Wittman a skript je volnˇe dostupn´ y na serveru GitHub [19]. Vytvoˇren´ı statick´eho invent´aˇre nav´ıc umoˇzn ˇuje prov´adˇet zmˇeny jednotliv´ ych parametr˚ u a pouˇz´ıt tyto parametry jako argumenty pro nˇekter´e moduly v r´amci playbooku.
29
KAPITOLA 3. REALIZACE
3.6
Ansible Playbook
Sc´en´aˇre Ansiblu poskytuj´ı ˇsirok´e moˇznosti strukturalizace. Aby bylo snadnˇejˇs´ı udrˇzet sc´en´aˇre pˇrehledn´e, je moˇzn´e je rozdˇelit do v´ıce soubor˚ u a tyto sady pot´e pouˇz´ıvat v r´amci nadˇrazen´eho sc´en´aˇre. Za t´ımto u ´ˇcelem je moˇzn´e vytvoˇrit tzv. role, kter´e poskytuj´ı sady pˇr´ıkaz˚ u pro proveden´ı urˇcit´ ych zmˇen. Role jsou reprezentov´any sloˇzkami ve sloˇzce roles. Jako prvn´ı pˇr´ıklad vezmˇeme roli init, kter´ a m´ a za u ´kol smazat tov´arn´ı konfiguraci s´ıt’ov´ ych parametr˚ u v zaˇr´ızen´ı a n´aslednˇe nastavit IP adresu, zmˇenit jm´eno zaˇr´ızen´ı a vytvoˇrit nov´eho uˇzivatele. Role init bude tvoˇrena tˇremi soubory: clear.yml, default.yml a main.yml. Soubor clear.yml bude obsahovat pˇr´ıkazy pro odstranˇen´ı tov´arn´ı konfigurace. V tomto pˇr´ıpadˇe se jedn´a o jedin´ y pˇr´ıkaz, kter´ y lok´ alnˇe spust´ı expect script pro komunikaci skrze MAC-Telnet. V´ yrazy ve dvojit´ ych sloˇzen´ ych z´ avork´ ach pˇredstavuj´ı promˇenn´e : −−− − name : Smaz t o v a r n i k o n f i g u r a c i local action : s c r i p t m t b a s h c l e a n . sh {{ Source MAC }} {{ d e f a u l t u s e r }} {{ d e f a u l t p a s s w o r d }}
K´od 3.4: Soubor clear.yml obsahuj´ıc´ı pˇr´ıkaz pro spuˇstˇen´ı skriptu, kter´ y vymaˇze v´ ychoz´ı tovarn´ı konfiguraci. D´ale soubor default.yml bude obsahovat pˇr´ıkaz pro nastaven´ı IP adresy na dan´em portu, jm´ena zaˇr´ızen´ı a vytvoˇren´ı nov´eho uˇzivatele: −−− − name : Nastav v y c h o z i k o n f i g u r a c i local action : s c r i p t m t b a s h d e f a u l t . sh {{ Source MAC }} {{ d e f a u l t u s e r }} {{ d e f a u l t p a s s w o r d }} {{ID}} {{ n e w u s e r }} {{ new password }} {{ Port }} {{ IP }}
K´od 3.5: Soubor default.yml obsahuj´ıc´ı pˇr´ıkaz pro spuˇstˇen´ı konfiguraˇcn´ıho skriptu, kter´ y nastav´ı IP adresu, ID zaˇr´ızen´ı a vytvoˇr´ı nov´ y uˇzivatelsk´ yu ´ˇcet. Soubor main.yml mus´ı b´ yt obsaˇzen v pˇr´ısluˇsn´e roli, nebot’ slouˇz´ı jako v´ ychoz´ı soubor pouˇzit´ y pˇri vol´an´ı dan´e role. V naˇsem pˇr´ıpadˇe tedy soubor spojuje dva pˇredeˇsl´e pomoc´ı pˇr´ıkazu include. Aby bylo moˇzn´e odstranit tov´arn´ı nastaven´ı, je tˇreba zaˇr´ızen´ı restartovat. Pot´e je potˇreba poˇckat, neˇz bude moˇzn´e pos´ılat dalˇs´ı pˇr´ıkazy. K tomu slouˇz´ı pˇr´ıkaz pause: −−− − include : c l e a r . yml − pause : minutes=1 − include : d e f a u l t . yml
K´od 3.6: Soubor main.yml obsahuj´ıc´ı pˇr´ıkazy pro import soubor˚ u clear.yml a default.yml.
N´asleduje ”opravdov´ y”playbook, kter´ y spust´ı roli init. Na zaˇc´atku sc´en´aˇre je uvedeno jeho jm´eno, typ pˇripojen´ı, definovan´e promˇenn´e a samozˇrejmˇe skupina uzl˚ u, v˚ uˇci kter´e budou pˇr´ıkazy spouˇstˇeny. Sc´en´ aˇr je uloˇzen v souboru site.yml uloˇzen´eho v koˇrenov´e sloˇzce:
30
KAPITOLA 3. REALIZACE
− name : I n i t Playbook # This playbook r e s e t s MikroTik d e v i c e s and a s s i n g n s IP addresses to connected ports hosts : m i k r o t i k s connection : l o c a l gather facts : no vars : default user : admin default password : ” ’ ’ ” new user : a n s i b l e new password : a n s i b l e roles : − init
K´od 3.7: Soubor site.yml obsahuj´ıc´ı sc´en´aˇr Init Playbook, kter´ y spouˇst´ı roli init. root@linux : / a n s i b l e −m i k r o t i k# a n s i b l e −playbook − i h o s t s s i t e . yml −−f o r k =1 PLAY [ I n i t Playbook ] ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ TASK [ i n i t : i n c l u d e ] ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ included: ./roles/init/tasks/clear.yml for Router1, Router2 TASK [ i n i t : Smaz t o v a r n i k o n f i g u r a c i ] ∗∗∗∗∗∗∗∗∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ ∗∗∗∗∗∗∗∗∗∗∗∗ changed: [Router1 ->localhost] changed: [Router2 ->localhost] TASK [ i n i t : pause ] ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ Pausing f o r 60 s e c o n d s ( c t r l+C then ’C’ = c o n t i n u e e a r l y , c t r l+C then ’A’ = a b o r t ) ok: [Router1] TASK [ i n i t : i n c l u d e ] ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ included: ./roles/init/tasks/default.yml for Router1, Router2 TASK [ i n i t : Nastav v y c h o z i k o n f i g u r a c i ] ∗ ∗ ∗ ∗ ∗∗ ∗∗∗∗ ∗∗∗∗ ∗∗∗∗ ∗∗∗∗ ∗∗∗∗ ∗∗∗ ∗∗∗∗ ∗∗∗∗ ∗∗∗ changed: [Router1 ->localhost] changed: [Router2 ->localhost] PLAY RECAP ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ Router1 : ok=5 changed=2 u n r e a c h a b l e=0 f a i l e d =0 Router2 : ok=4 changed=2 u n r e a c h a b l e=0 f a i l e d =0
K´ od 3.8: V´ ystup Ansiblu pro roli init.
Sc´en´aˇre se spouˇstˇej´ı pˇr´ıkazem ansible-playbook, pˇrep´ınaˇc -i urˇcuje soubor invent´aˇre. Parametr --fork=1 je v pˇr´ıpadˇe spouˇstˇen´ı pˇr´ıkaz˚ u vyuˇz´ıvaj´ıc´ıch MAC-Telnet nezbytn´ y. Parametr urˇcuje kolik paraleln´ıch spojen´ı m˚ uˇze Ansible vytvoˇrit, avˇsak spuˇstˇen´ı v´ıce instanc´ı MACTelnetu m˚ uˇze v´est k chyb´ am. Ve v´ ystupu je patrn´ y postup jednotliv´ ych u ´kol˚ u, na z´avˇer je uveden pˇrehledn´ y souhrn cel´e hry.
31
KAPITOLA 3. REALIZACE
3.7 3.7.1
Pˇ r´ıklady pouˇ zit´ı Testovac´ı pracoviˇ stˇ e
Pˇri v´ yvoji a testov´ an´ı modul˚ u jsem vyuˇz´ıval virtu´aln´ıch smˇerovaˇc˚ u MikroTik. Na str´ank´ach v´ yrobce jsou volnˇe dostupn´e obrazy ISO instalaˇcn´ıch CD ˇci pˇr´ımo pˇred-pˇripraven´e instalace pro vyuˇzit´ı ve VMware ˇci Hyper-V [20]. Jako fyzick´e zaˇr´ızen´ı pro testov´an´ı jsem pouˇz´ıval RouterBOARD model RB2011UiAS-2HnD-IN [21] uveden´ y na obr´azku 3.5. V pr˚ ubˇehu t´eto pr´ace jsem na testovan´ ych zaˇr´ızen´ıch provozoval RouterOS ve verz´ıch 6.32.3, 6.34.4 a 6.35.2.
MikroTik 1
Ansible Server IP: 192.168.88.200 MAC: 00:11:22:33:44:55
Přepínač
MikroTik 2
MikroTik 3
Obr´ azek 3.4: Pˇr´ıklad zapojen´ı testovac´ı laboratoˇre
Obr´ azek 3.5: RB2011UiAS-2HnD-IN
3.7.2
Pˇ r´ıklad 1
V tomto pˇr´ıkladu uvedu uk´ azku sc´en´aˇre, jehoˇz u ´kolem je nastavit DNS server, DHCP server, IP adresu na dalˇs´ım portu, statickou cestu do zvolen´e s´ıtˇe, Source-NAT typu masquerade pro prvn´ı port a Destination-NAT pro vzd´alen´ y pˇr´ıstup k m´ıstn´ımu serveru. V´ ystup Ansiblu pro
32
KAPITOLA 3. REALIZACE tento sc´en´ aˇr je uveden v pˇr´ıloze Pˇr´ıloha 2. Jak je zdokumentov´ano v uk´azce, postupnˇe doch´az´ı k nastaven´ı poˇzadovan´ ych parametr˚ u. Kaˇzd´e nastaven´ı pˇredstavuje jeden u ´kol (task), kter´ y je zde reprezentov´ an jm´enem u ´kolu (- name) a jm´enem modulu, kter´ y m´a za u ´kol prov´est pˇr´ısluˇsn´e zmˇeny. Postupnˇe jsou tedy spuˇstˇeny tyto u ´koly: Nastaven´ı DNS serveru, nastaven´ı IP adresy na s´ıt’ov´em rozhran´ı, nastaven´ı adresn´ıho rozsahu pro DHCP server, spuˇstˇen´ı DHCP serveru, nastaven´ı parametr˚ u DHCP serveru, pˇrid´an´ı statick´eho smˇerovac´ıho z´aznamu, nastaven´ı zdrojov´eho pˇrekladu adres a nakonec nastaven´ı pˇrekladu adres pro pˇr´ıchoz´ı komunikaci. − name : M i k r o t i k TEST1 hosts : m i k r o t i k s connection : l o c a l gather facts : no vars : dhcp pool : t e s t p o o l username : a n s i b l e password : a n s i b l e tasks : − name : N a s t a v e n i DNS s e r v e r u mt dns : username={{username }} hostname={{IP }} password={{password }} s e r v e r s = 1 9 2 . 1 6 8 . 1 1 6 . 1 , 8 . 8 . 8 . 8 r e m o t e r e q u e s t s =” t r u e ” − name : N a s t a v e n i IP a d r e s y na r o z h r a n i e t h e r 2 mt ip : username={{username }} hostname={{IP }} password={{password }} a d d r e s s ={{ e t 2 a d d r }} i n t e r f a c e=e t h e r 2 d i s a b l e d =” f a l s e ” − name : N a s t a v e n i IP a d r e s n i h o r o z s a h u pro DHCP s e r v e r mt ip pool : username={{username }} hostname={{IP }} password={{password }} pool name={{ d h c p p o o l }} p o o l r a n g e = 1 9 2 . 1 6 8 . 1 1 6 . 1 0 − 1 9 2 . 1 6 8 . 1 1 6 . 2 0 − name : S p u s t e n i DHCP s e r v e r u na r o z h r a n i e t h e r 2 mt dhcp srv : username={{username }} hostname={{IP }} password={{password }} name =T e s t S e r v e r a d d r e s s p o o l ={{ d h c p p o o l }} d i s a b l e d =” t r u e ” i n t e r f a c e=e t h e r 2 − name : N a s t a v e n i parametru DHCP s e r v e r u mt dhcp net : username={{username }} hostname={{IP }} password={{password }} n e t w o r k a d d r e s s = 1 9 2 . 1 6 8 . 1 1 6 . 0 / 2 4 gateway = 1 9 2 . 1 6 8 . 1 1 6 . 1 d n s s e r v e r =192.168.116.1 − name : N a s t a v e n i s t a t i c k e c e s t y do s i t e 1 9 2 . 1 6 8 . 1 0 . 0 / 2 4 mt static route : username={{username }} hostname={{IP }} password={{password }} d s t a d d r e s s = 1 9 2 . 1 6 8 . 1 0 . 0 / 2 4 gateway = 1 9 2 . 1 6 8 . 1 0 . 1 − name : N a s t a v e n i z d r o j o v e h o p r e k l a d u a d r e s na r o z h r a n i e t h e r 1 mt nat : username={{username }} hostname={{IP }} password={{password }} o u t i n t e r f a c e=e t h e r 1 c h a i n=s r c n a t a c t i o n=masquerade − name : N a s t a v e n i p r e k l a d u a d r e s pro p r i c h o z i p o r t TCP/8022 mt nat : username={{username }} hostname={{IP }} password={{password }} c h a i n= d s t n a t a c t i o n=dst−nat d s t p o r t =8022 t o a d d r e s s e s = 1 9 2 . 1 6 8 . 1 1 6 . 2 0 t o p o r t s =22 p r o t o c o l=t c p
K´od 3.9: Sc´en´ aˇr MikroTik TEST1 obsahuj´ıc´ı pˇr´ıkazy pro konfiguraci DNS serveru, DHCP serveru, IP adresy na zvolen´em s´ıt’ov´em rozhran´ı, statick´eho smˇerovac´ıho z´aznamu, zdrojov´eho pˇrekladu adres a c´ılov´eho pˇrekladu adres pro zvolen´ y port.
3.8
Pˇ r´ıklad 2
V tomto pˇr´ıkladu budeme modelovat topologii s´ıtˇe z obr´azku 3.6. Postupnˇe nastav´ıme IP adresy na vˇsech oznaˇcen´ ych portech a pot´e zprovozn´ıme protokol RIP mezi smˇerovaˇci. D´ale na Routerech 2 a 3 nastav´ıme DHCP server pro s´ıtˇe LAN1 a LAN2. V posledn´ım kroku
33
KAPITOLA 3. REALIZACE nastav´ıme na Routeru 1 statick´ y z´ aznam pro v´ ychoz´ı br´anu a na veˇrejn´em portu spust´ıme zdrojov´ y pˇreklad adres. Informace o v´ ychoz´ı br´anˇe bude propagov´ana pomoc´ı protokolu RIP i mezi Routery 2 a 3.
Internet 77.75.79.1 Ether3/77.75.79.10/24
Ether2/.2 10.0.3.0/30
Ether1/.1 10.0.1.0/30
R1
Ether1/.1
Ether2/.2 Ether2/.2
R3 Ether3/.1
Ether1/.1 10.0.2.0/30
R2 Ether3/.1
LAN 1
LAN 2
192.168.10.0/24
192.168.20.0/24
Obr´ azek 3.6: Topologie mal´e podnikov´e s´ıtˇe Pro prvotn´ı konfiguraci pˇredpokl´ adejme topologii z obr´azku 3.4, pˇriˇcemˇz pro pˇripojen´ı k zaˇr´ızen´ım pouˇz´ıv´ ame port ether4. Vˇsechny tyto porty maj´ı spolu s kontroln´ım PC adresy z rozsahu 192.168.100.0/24. Nejdˇr´ıve je v invent´aˇri potˇreba definovat vˇsechny potˇrebn´e hodnoty: −−− Router1 ID : Router1 IP : 1 9 2 . 1 6 8 . 1 0 0 . 1 0 / 2 4 et1addr : 1 0 . 0 . 1 . 1 / 3 0 et2addr : 1 0 . 0 . 3 . 0 / 3 0 et3addr : 7 7 . 7 5 . 7 9 . 1 0 / 2 4 −−− Router2 ID : Router2 IP : 1 9 2 . 1 6 8 . 1 0 0 . 2 0 / 2 4 et1addr : 1 0 . 0 . 1 . 2 / 3 0 et2addr : 1 0 . 0 . 2 . 1 / 3 0 et3addr : 1 9 2 . 1 6 8 . 2 0 . 1 / 2 4 pool range : ” 1 9 2 . 1 6 8 . 2 0 . 1 0 − 1 9 2 . 1 6 8 . 2 0 . 2 0 0 ” network : 1 9 2 . 1 6 8 . 2 0 . 0 / 2 4 −−− Router3 ID : Router3 IP : 1 9 2 . 1 6 8 . 1 0 0 . 3 0 / 2 4 et1addr : 1 0 . 0 . 3 . 1 / 3 0 et2addr : 1 0 . 0 . 2 . 2 / 3 0 et3addr : 1 9 2 . 1 6 8 . 1 0 . 1 / 2 4 pool range : ” 1 9 2 . 1 6 8 . 1 0 . 1 0 − 1 9 2 . 1 6 8 . 1 0 . 2 0 0 ” network : 1 9 2 . 1 6 8 . 1 0 . 0 / 2 4
K´od 3.10: Invent´ aˇr pro topologii z obr´azku 3.6 obsahuj´ıc´ı uzly Router1, Router2 a Router3.
34
KAPITOLA 3. REALIZACE N´asleduj´ı tˇri sc´en´ aˇre. Prvn´ı sc´en´ aˇr provede zmˇeny na vˇsech tˇrech smˇerovaˇc´ıch. Jednotliv´e u ´koly postupnˇe nastav´ı pˇr´ısluˇsn´e IP adresy na rozhran´ıch ether1, ether2, ether3. V posledn´ı u ´kolu je na vˇsech smˇerovaˇc´ıch spuˇstˇen protokol RIP. −−− − name : A l l r o u t e r s hosts : Router1 , Router2 , Router3 connection : l o c a l gather facts : no vars : username : a n s i b l e password : a n s i b l e tasks : − name : N a s t a v e n i IP a d r e s y na r o z h r a n i e t h e r 1 mt ip : username={{username }} hostname={{IP }} password={{password }} i n t e r f a c e=e t h e r 1 a d d r e s s ={{ e t 1 a d d r }} d i s a b l e d =” f a l s e ” − name : N a s t a v e n i a d r e s y na r o z h r a n i e t h e r 2 mt ip : username={{username }} hostname={{IP }} password={{password }} i n t e r f a c e=e t h e r 2 a d d r e s s ={{ e t 2 a d d r }} d i s a b l e d =” f a l s e ” − name : N a s t a v e n i a d r e s y na r o z h r a n i e t h e r 3 mt ip : username={{username }} hostname={{IP }} password={{password }} i n t e r f a c e=e t h e r 3 a d d r e s s ={{ e t 3 a d d r }} d i s a b l e d =” f a l s e ” − name : N a s t a v e n i p r o t o k o l u RIP mt rip : username={{username }} hostname={{IP }} password={{password }} i n t e r f a c e s=e t h e r 1 , e t h e r 2 r e d i s t r i b u t e c o n n e c t e d =” t r u e ” d i s t r i b u t e d e f a u l t =” i f −i n s t a l l e d send=v2 r e c e i v e=v2 a u t h e n t i c a t i o n=md5 a u t h e n t i c a t i o n −key=P@ssw0rd123
K´od 3.11: Sc´en´ aˇre pro nastaven´ı spoleˇcn´ ych parametr˚ u pro vˇsechny smˇerovaˇce z obr´azku 3.6 V dalˇs´ım sc´en´ aˇri nastav´ıme na hraniˇcn´ım smˇerovaˇci adresu v´ ychoz´ı br´any a zdrojov´ y pˇreklad adres pro umoˇznˇen´ı komunikace do internetu. −−− − name : Border r o u t e r hosts : Router1 connection : l o c a l gather facts : no vars : username : a n s i b l e password : a n s i b l e tasks : − name : S t a t i c k e n a s t a v e n i pro v y c h o z i branu mt static ip : username={{username }} hostname={{IP }} password={{password }} destination address =”0.0.0.0/0” gateway = 7 7 . 7 5 . 7 9 . 1 − name : Z d ro jo v y p r e k l a d a d r e s pro r o z h r a n i e t h e r 3 mt nat : username={{username }} hostname={{IP }} password={{password }} c h a i n=s r c n a t o u t i n t e r f a c e=e t h e r 3 a c t i o n=masquerade
K´od 3.12: Sc´en´ aˇre pro nastaven´ı parametr˚ u hraniˇcn´ıho smˇerovaˇce (Router1 ) z obr´azku 3.6
35
KAPITOLA 3. REALIZACE V posledn´ım sc´en´ aˇri spust´ıme na pˇr´ıstupov´ ych smˇerovaˇc´ıch DHCP servery pro lok´aln´ı s´ıtˇe. V prvn´ım u ´kolu vytvoˇr´ıme adresn´ı rozsah pro dan´ y DHCP server, n´aslednˇe spust´ıme DHCP server na pˇr´ısluˇsn´em rozhran´ı a v posledn´ım u ´kolu nastav´ıme parametry DHCP serveru, jako jsou napˇr´ıklad adresa v´ ychoz´ı br´ any ˇci adresa DNS serveru. −−− − name : A c c e s s r o u t e r s hosts : Router2 , Router3 connection : l o c a l gather facts : no vars : username : a n s i b l e password : a n s i b l e tasks : − name : N a s t a v e n i a d r e s n i h o r o z s a h u pro DHCP s e r v e r mt ip pool : username={{username }} hostname={{IP }} password={{password }} pool name=p o o l p o o l r a n g e ={{ p o o l r a n g e }} − name : S p u s t e n i DHCP s e r v e r u mt dhcp srv : username={{username }} hostname={{IP }} password={{password }} name=dhcp−l o c a l a d d r e s s p o o l=p o o l d i s a b l e d =” f a l s e ” i n t e r f a c e=e t h e r 3 − name : N a s t a v e n i parametru DHCP s e r v e r u mt dhcp net : username={{username }} hostname={{IP }} password={{password }} n e t w o r k a d d r e s s ={{network }} gateway={{ e t 3 a d d r }} dns server =8.8.8.8
K´od 3.13: Sc´en´ aˇre pro nastaven´ı parametr˚ u pro pˇr´ıstupov´e smˇerovaˇce (Router2 a Router3 ) z obr´azku 3.6
36
Kapitola 4
Z´ avˇ er Toto t´ema bakal´ aˇrsk´e pr´ ace jsem si zvolil pˇredevˇs´ım z d˚ uvodu z´ajmu o problematiku automatizovan´e konfigurace s´ıt´ı. Se zaˇr´ızen´ımi RouterBOARD jsem se setkal jiˇz dˇr´ıve, avˇsak jejich konfiguraci jsem realizoval vˇzdy pouze s vyuˇzit´ım pˇr´ıkazov´e ˇr´adky nebo grafick´eho WinBoxu. V tomto ohledu mi zpracov´ an´ı problematiky t´eto pr´ace znaˇcnˇe rozˇs´ıˇrilo obzory. Pˇredevˇs´ım sezn´amen´ı s n´ astrojem Ansible osobnˇe hodnot´ım jako velmi prospˇeˇsn´e. Aˇckoliv se mi zprvu zd´al ne pˇr´ıliˇs vhodn´ y ke konfiguraci s´ıt’ov´ ych zaˇr´ızen´ı bez podpory jazyka Python, ve v´ ysledku se uk´azal b´ yt nedoceniteln´ ym n´ astrojem uˇz jen pro spr´avu invent´aˇr˚ u a ˇsirok´e moˇznosti organizace a strukturalizace pˇr´ıkaz˚ u pomoc´ı sc´en´aˇr˚ u a rol´ı. Jedn´a se opravdu o velmi robustn´ı a mocn´ y n´ astroj, ale pˇresto se jeho z´akladn´ı principy daj´ı pochopit a nauˇcit vcelku rychle. Nav´ıc d´ıky moˇznosti ps´ at vlastn´ı moduly v libovoln´em jazyce m˚ uˇze kdokoliv se z´akladn´ı znalost´ı programov´ an´ı pˇrisp´ıvat a d´ ale rozˇsiˇrovat uˇz tak ˇsirok´e schopnosti tohoto n´astroje. T´ım se pomalu dost´ av´ am k dalˇs´ı zkuˇsenosti, kterou jsem z´ıskal v r´amci tohoto projektu. Touto zkuˇsenost´ı bylo sezn´ amen´ı se s jazykem Python. Programov´an´ı jsem se nikdy pˇr´ıliˇs nevˇenoval a mus´ım pˇriznat, ˇze jsem pomˇernˇe ned´avno ˇzil v domnˇen´ı, ˇze pˇri studiu telekomunikaˇcn´ıch ˇ s´ıt´ı nebude znalost programov´ an´ı nezbytn´a. Zijeme vˇsak v dobˇe, kdy se pomˇernˇe dlouho zabˇehnut´ y syst´em spr´ avy informaˇcn´ıch technologi´ı pˇresouv´a od konzol´ı do virtualizovan´ ych cloud˚ u a ony nekoneˇcn´e u ´drˇzby a obsluhy tˇechto syst´emu pˇreb´ıraj´ı orchestraˇcn´ı aplikace a n´astroje jako Ansible. Stejnˇe jako u Ansiblu i pro Python plat´ı n´ızk´a uˇc´ıc´ı kˇrivka a nav´ıc m´a pomˇernˇe ˇsirok´e moˇznosti nasazen´ı pr´avˇe v oblasti spr´avy s´ıt’ov´e infrastruktury. Alespoˇ n z´akladn´ı znalost programov´ an´ı je nezbytn´ ym pˇredpokladem pro interakci s automatizaˇcn´ımi a orchestraˇcn´ımi n´ astroji a st´ av´ a se tud´ıˇz dalˇs´ım poˇzadavkem kladen´ ym na administr´atory modern´ıch s´ıt´ı.
37
´ ER ˇ KAPITOLA 4. ZAV
4.1
Naplnˇ en´ı stanoven´ ych c´ıl˚ u
C´ılem t´eto pr´ ace bylo rozˇs´ıˇrit schopnosti n´astroje Ansible pro konfiguraci s´ıt’ov´ ych zaˇr´ızen´ı. Prvn´ı pˇrek´ aˇzkou byla skuteˇcnost, ˇze aˇckoliv je Ansible n´astrojem bez agent˚ u, vyˇzaduje pro vˇetˇsinu modul˚ u podporu jazyka Python. Po sezn´amen´ı se s r˚ uzn´ ymi moˇznostmi konfigurace zaˇr´ızen´ı MikroTik jsem se rozhodl pro realizaci vyuˇz´ıt API, kter´e slibovalo nejlepˇs´ı uchopitelnost z pohledu programov´eho pˇr´ıstupu ke konfiguraci. Volba API se uk´azala jako dobr´a volba d´ıky n´ıˇz bylo snazˇs´ı realizovat n´asledn´e moduly pro Ansible. P˚ uvodn´ı myˇslenka pˇri realizaci modul˚ u byla takov´ a, ˇze moduly budou m´ıt minim´aln´ı velikost a budou slouˇzit pˇredevˇs´ım k z´ısk´ an´ı adekv´ atn´ıho vstupu a poskytnut´ı v´ ystupu pro Ansible. Moduly by tak pouze pˇredaly potˇrebn´e parametry nadˇrazen´e funkci, kter´a by na z´akladˇe vlastn´ı logiky umoˇznila prov´ adˇet libovoln´e zmˇeny v konfiguraci bez ohledu na jejich charakter. Bohuˇzel vzhledem k rozs´ ahl´ ym moˇznostem nastaven´ı a jejich vz´ajemn´eho prov´az´an´ı se mi nepodaˇrilo vytvoˇrit jednu vˇsemocnou funkci, kter´a by zajiˇst’ovala proveden´ı zmˇen. Rozhodl jsem se proto pˇrenechat ˇc´ ast logiky cel´eho procesu pˇr´ımo v modulech, ve kter´ ych lze sn´aze oˇsetˇrit konkr´etn´ı pˇr´ıpady spojen´e s konkr´etn´ım nastaven´ım. Podaˇrilo se mi tak vytvoˇrit moduly pro nastaven´ı nˇekter´ ych z´ akladn´ıch funkc´ı zaˇr´ızen´ı MikroTik. Mezi tyto funkce patˇr´ı adresace s´ıt’ov´ ych rozhran´ı, konfigurace DHCP a DNS serveru, konfigurace s´ıt’ov´ ych most˚ u, spr´ava firewallov´ ych pravidel, pˇreklad s´ıt’ov´ ych adres, dynamick´e smˇerov´an´ı pomoc´ı protokolu RIP. Nˇekter´ ych dalˇs´ıch nastaven´ı m˚ uˇze b´ yt dosaˇzeno pomoc´ı pˇr´ım´ ych pˇr´ıkaz˚ u prostˇrednictv´ım ych modul˚ u jsem se tak´e vˇenoval problematice dynamodulu mt raw. Kromˇe tvorby samotn´ mick´ ych invent´ aˇr˚ u pro pouˇzit´ı s velk´ ym poˇctem koncov´ ych zaˇr´ızen´ı a probl´em˚ um spojen´ ym s prvotn´ı konfigurac´ı zaˇr´ızen´ı RouterBOARD. V´ ysledkem m´eho snaˇzen´ı je skript generuj´ıc´ı invent´aˇr pro Ansible na z´ akladˇe informac´ı z´ıskan´ ych z odposlechu CDP r´amc˚ u. Problematika prvotn´ı konfigurace se uk´ azala b´ yt ponˇekud sloˇzitˇejˇs´ı, neˇz jsem oˇcek´aval. Za u ´ˇcelem prvotn´ı konfigurace samozˇrejmˇe existuj´ı r˚ uzn´e moˇznosti, vˇetˇsina z nich vˇsak vyˇzaduje hlubˇs´ı znalost problematiky a nezbytn´e vybaven´ı. Pˇr´ıkladem takov´eho ˇreˇsen´ı m˚ uˇze b´ yt napˇr´ıklad nahr´an´ı vlastn´ıho obrazu operaˇcn´ıho syst´emu do zaˇr´ızen´ım prostˇrednictv´ı bootov´an´ı ze s´ıt’ov´eho TFTP serveru. Moj´ı snahou vˇsak bylo ˇreˇsen´ı, kter´e by kladlo minim´aln´ı poˇzadavky na pˇridan´e prostˇredky a bylo ovladateln´e pˇr´ımo z Ansiblu. Po konzultaci jsem se rozhodl vyuˇz´ıt propriet´arn´ıho protokolu MAC-Telnet, kter´ y zaˇr´ızen´ı MikroTik podporuj´ı. Bohuˇzel jsem narazil na probl´emy s ovl´ ad´ an´ım MAC-Telnetu prostˇrednictv´ım skript˚ u v jazyce Python a byl jsem nucen vydat se pro mne jedinou funkˇcn´ı cestou, kterou bylo ovl´ad´an´ı MAC-Telnetu pomoc´ı expect skriptu. V d˚ usledku toho se moˇznosti konfigurace prostˇrednictv´ım MAC-Telnetu omezili na minimum nezbytn´e k umoˇznˇen´ı pˇr´ıstupu prostˇrednictv´ım API. Samozˇrejmˇe je zde spousta prostoru, kam by se tato pr´ ace dala d´ale rozv´ıjet. Pˇr´ıkladem by mohlo b´ yt napˇr´ıklad vytvoˇren´ı spojovac´ıho modulu pro Ansible, kter´ y by pˇr´ımo realizoval spojen´ı se zaˇr´ızen´ımi MikroTik prostˇrednictv´ım API. Nad takov´ ymto pˇripojen´ım by mohla pracovat ˇrada modul˚ u. D´ıky takov´emu pˇr´ıstupu by pak bylo moˇzn´e vytvoˇrit dalˇs´ı typy spojen´ı pro dalˇs´ı v´ yrobce
38
´ ER ˇ KAPITOLA 4. ZAV s´ıt’ov´ ych zaˇr´ızen´ı a moduly tak udˇelat univerz´alnˇejˇs´ı. Pˇri realizaci jsem ˇcerpal z uveden´ ych zdroj˚ u, pˇredevˇs´ım pak z online dokumentace Ansiblu a MikroTiku. Dalˇs´ımi zdroji pak byly internetov´a f´ora a r˚ uzn´e komunitn´ı skupiny spojen´e s Ansiblem, Pythonem a operaˇcn´ım syst´emem RouterOS.
39
Seznam pouˇ zit´ ych zdroj˚ u [1] Information Technology Infrastructure Library — Wikipedia, The Free Encyclopedia. [Online, dostupn´e z: https://en.wikipedia.org/wiki/ITIL], 2014. [cit. 24.5.2016]. [2] Dan Conde. Network Automation: More Than Scripting. [Online, dostupn´e z: http:// www.networkcomputing.com/data-centers/network-automation-more-scripting/ 819125107], 2015. [cit. 24.5.2016]. [3] Cisco Systems, Inc. z:
Cisco Application Centric Infrastructure.
[Online, dostupn´e
http://www.cisco.com/c/en/us/solutions/data-center-virtualization/
application-centric-infrastructure/index.html]. [cit. 24.5.2016]. [4] Stephen McQuerry. Interconnecting Cisco Network Devices, Part 1 (ICND1): CCNA Exam 640-802 and ICND1 Exam 640-822. Pearson Education, 2007. [5] IBM Global Services. Improving Systems Availability. [Online, dostupn´e z: http://www. dis.uniroma1.it/~irl/docs/availabilitytutorial.pdf], 1998. [cit. 24.5.2016]. [6] Richard Harris. Network Reliability. [Online, dostupn´e z: http://seat.massey.ac.nz/ 143465/Lectures/Network%20Reliability_2_1s.pdf]. [cit. 24.5.2016]. [7] Hewlett Packard: Annual Report 2015. [Online, dostupn´e z: http://h30261.www3. hp.com/~/media/Files/H/HP-IR/documents/reports/2016/2015-form-10k.pdf]. [cit. 24.5.2016]. [8] API — Wikipedia, The Free Encyclopedia. [Online, dostupn´e z: https://cs.wikipedia. org/wiki/API]. [cit. 24.5.2016]. [9] Lorin Hochstein. Ansible: Up and Running. O’Reilly Media, Inc., May 2015. [10] GitHub: Ansible.
[Online, dostupn´e z: https://github.com/ansible/ansible].
[cit. 24.5.2016]. [11] Ansible Documentation: Ansible Documentation. [Online, dostupn´e z: http://docs. ansible.com/ansible/]. [cit. 24.5.2016].
viii
ˇ YCH ´ SEZNAM POUZIT ZDROJ˚ U [12] Ansible Documentation: Introduction To Ad-Hoc Commands. [Online, dostupn´e z: http: //docs.ansible.com/ansible/intro_adhoc.html]. [cit. 24.5.2016]. [13] Ansible Documentation: Intro to Playbooks.
[Online, dostupn´e z: http://docs.
ansible.com/ansible/playbooks_intro.html]. [cit. 24.5.2016]. [14] MikroTik — Wikipedia, The Free Encyclopedia. [Online, dostupn´e z: https://en. wikipedia.org/wiki/MikroTik]. [cit. 24.5.2016]. [15] MikroTik Wiki - Manual: WinBox. [Online, dostupn´e z: http://wiki.mikrotik.com/ wiki/Manual:Winbox]. [cit. 24.5.2016]. [16] MikroTik Wiki - Manual: API. [Online, dostupn´e z: http://wiki.mikrotik.com/wiki/ Manual:API]. [cit. 24.5.2016]. [17] Piotr Skamruk. GitHub: Routerboard python API. [Online, dostupn´e z: https:// github.com/jellonek/rosapi]. [cit. 24.5.2016]. [18] H˚ akon Nessjøen. GitHub: MAC-Telnet Client. [Online, dostupn´e z: https://github. com/haakonnessjoen/MAC-Telnet]. [cit. 24.5.2016]. [19] David Wittman. GitHub: Ansible Dynamic Inventory Converter. [Online, dostupn´e z: https://gist.github.com/DavidWittman/189816c1c2b3a25bd1b18f5f9f681262]. [cit. 24.5.2016]. [20] Mikrotik: Downloads.
[Online, dostupn´e z: http://www.mikrotik.com/download].
[cit. 24.5.2016]. [21] Mikrotik - RouterBOARD: RB2011UiAS-2HnD-IN.
[Online, dostupn´e z: http://
routerboard.com/RB2011UiAS-2HnD-IN]. [cit. 24.5.2016].
ix
Seznam pˇ r´ıloh 1. CD se zdrojov´ ymi k´ ody 2. Pˇ r´ıklad v´ ystupu Ansiblu
Pˇ r´ıloha 1 1. sloˇzka library - sloˇzka obsahuj´ıc´ı moduly a funkce, viz. 3.2 a 3.3 1.1. 1.2. 1.3. 1.4. 1.5. 1.6. 1.7. 1.8. 1.9. 1.10. 1.11. 1.12. 1.13.
RosAPI.py RosRaw.py RosCore.py mt ip.py mt ip pool.py mt dhcp net.py mt dhcp srv.py mt dns.py mt nat.py mt firewall.py mt brctl.py mt static route.py mt raw.py
2. sloˇzka group vars 3. sloˇzka host vars 4. sloˇzka roles 4.1. sloˇzka init 4.1.1. sloˇzka files 4.1.1.1. mtbash clean.sh 4.1.1.2. mtbash default.sh 4.1.2. sloˇzka tasks 4.1.2.1. clear.yml 4.1.2.2. default.yml 4.1.2.3. main.yml 5. cdp discovery.py 6. dyn to sta.py x
Pˇ r´ıloha 2 root@linux : / a n s i b l e −m i k r o t i k# a n s i b l e −playbook − i h o s t s t e s t p l a y b o o k . yml PLAY [ M i k r o t i k TEST1 ] ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ TASK [ N a s t a v e n i DNS s e r v e r u ] ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ changed: [Router2] changed: [Router1] TASK [ N a s t a v e n i IP a d r e s y na r o z h r a n i e t h e r 2 ] ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ changed: [Router2] changed: [Router1] TASK [ N a s t a v e n i IP a d r e s n i h o r o z s a h u pro DHCP s e r v e r ] ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ changed: [Router1] changed: [Router2] TASK [ S p u s t e n i DHCP s e r v e r u na r o z h r a n i e t h e r 2 ] ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ changed: [Router2] changed: [Router1] TASK [ N a s t a v e n i parametru DHCP s e r v e r u ] ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ changed: [Router1] changed: [Router2] TASK [ N a s t a v e n i s t a t i c k e c e s t y do s i t e 1 9 2 . 1 6 8 . 1 0 . 0 / 2 4 ] ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ ∗ changed: [Router1] changed: [Router2] TASK [ N a s t a v e n i z d r o j o v e h o p r e k l a d u a d r e s na r o z h r a n i e t h e r 1 ] ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ changed: [Router1] changed: [Router2] TASK [ N a s t a v e n i p r e k l a d u a d r e s pro p r i c h o z i p o r t 8 0 2 2 ] ∗ ∗ ∗ ∗ ∗ ∗∗ ∗∗∗ ∗∗ ∗∗∗ ∗∗∗ ∗∗ ∗∗∗ ∗∗∗ ∗∗ ∗∗∗ ∗∗∗ ∗∗ ∗∗∗ ∗∗∗ changed: [Router2] changed: [Router1] PLAY RECAP ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗ Router1 : ok=8 changed=7 u n r e a c h a b l e=0 f a i l e d =0 Router2 : ok=8 changed=7 u n r e a c h a b l e=0 f a i l e d =0
V´ ystup Ansiblu pro sc´en´aˇr MikroTik TEST1 viz. 3.9
xi
