Katedra informatiky
Integrace distribuovan ´e laboratoˇre
po ˇc´ıta ˇcov ´ych s´ıt´ı se simul ´atorem
PacketTracer
Integration of Distributed Virtual
Network Laboratory with
PacketTracer Simulator
Smyslem t´eto pr´ace je umoˇznit komunikaci mezi re´aln ´ymi s´ıt’ov ´ymi prvky a simul´atorem Packet Tracer. Zahrnuje tedy vˇse potˇrebn´e pro splnˇen´ı tohoto c´ıle. Popisuje protokoly pouˇzit´e pˇri komunikaci mezi simul´atory PT a rovnˇeˇz obsahuje jejich implementaci. D´ale jsou zde pops´any zmˇeny, kter´e bylo potˇreba prov´est pro integraci tohoto ˇreˇsen´ı do Virt-labu.
Kl´ıˇcov ´a slova: PTMP, MU, PT API, Packet Tracer, Virtlab, PTServer, PTBridge
Abstract
The purpose of this work is to allow communication between real network equipment and simulator Packet Tracer. Includes everything you need to meet this target. Describes the protocols used for communication between simulators PT and also includes its im-plementation. It also describes changes that had to be made to integration this solution into Virtlab.
IPC – Inter Process Communication
MU – Multi-User connection
PT – Packet Tracer
PTMP – Packet Tracer Messaging Protocol
TCP – Transmission Control Protocol
TCP/IP – Transmission Control Protocol/Internet Protocol
UDP – User Datagram Protocol
VLAN – Virtual Local Area Network
WSDL – Web Services Description Language
Obsah
1 Uvod´ 6
2 Popis souvisej´ıc´ıch projekt ˚u 7
2.1 Virtlab . . . 7
2.2 Packet Tracer . . . 7
3 Packet Tracer API 9 3.1 PtBridge . . . 9
4 Packet Tracer Messaging Protocol 11 4.1 Architektura PTMP protokolu . . . 11
4.2 Reˇzimy pˇrenosu zpr´av . . . 13
4.3 Obecn ´y form´at zpr´av . . . 13
4.4 Stavov ´y diagram . . . 13
4.5 Vyjedn´an´ı spojen´ı . . . 15 4.6 Autentizace . . . 16 4.7 ˇSifrov´an´ı . . . 18 4.8 Komprese . . . 18 4.9 Poˇrad´ı operac´ı PTMP . . . 18 4.10 Udrˇzov´an´ı spojen´ı . . . 19 5 Multi-user connection 20 5.1 Architektura MU protokolu . . . 20 5.2 Vyjedn´an´ı MU spojen´ı . . . 20 5.3 Informace o portech . . . 21 5.4 Informace o lince . . . 21 5.5 Pseudor´amec . . . 23 5.6 Uloˇzen´ı s´ıtˇe . . . 24
5.7 Vstup a v ´ystup konzole . . . 24
5.8 Zmˇena jm´ena MU spojen´ı . . . 25
6 N´avrh ˇreˇsen´ı 26 6.1 PTServer . . . 27 6.2 PTBridge . . . 27 7 Implementace 29 7.1 PTServer . . . 29 7.2 Popis tˇr´ıd PTServeru . . . 30 7.3 PTBridge . . . 33 7.4 Popis tˇr´ıd PTBridge . . . 33 7.5 Upravy Virtlabu . . . .´ 35 8 Z´avˇer 37
9 Reference 38
Pˇr´ılohy 39
Seznam tabulek
1 Tabulka PTMP datov ´ych typ ˚u a zp ˚usob jejich reprezentace . . . 14
2 Hodnoty pole typ pro PTMP zpr´avy . . . 14
3 Hodnoty pole typ pro MU zpr´avy . . . 21
4 Hodnoty pole typ portu pro MU zpr´avy . . . 22
Seznam obr ´azk ˚
u
1 Okno programu Packet Tracer 5.3 . . . 8
2 PTMP – architektura protokolu . . . 12
3 PTMP – zjednoduˇsen ´y stavov ´y diagram . . . 15
4 PTMP – sekvence autentizaˇcn´ıho protokolu . . . 17
5 PT – vzhled odpojen´eho a pˇripojen´eho MU obl´aˇcku . . . 21
6 Celkov ´y koncept ˇreˇsen´ı . . . 27
7 Cesta r´amce z re´aln´eho prvku na poˇc´ataˇc s PT . . . 28
8 Jednoduch ´y sekvenˇcn´ı diagram PTServeru . . . 32
Seznam v ´ypis ˚
u zdrojov ´eho k ´
odu
1 Jednoduch ´y algoritmus pro ˇsifrov´an´ı hesla . . . 18
2 Uk´azka konfiguraˇcn´ıho souboru pro PTServer . . . 31
3 Uk´azka konfiguraˇcn´ıho souboru pro PTBridge . . . 34
4 Funkce pro generov´an´ı n´ahodn´eho hesla . . . 35
1
Uvod
´
C´ılem t´eto pr´ace bylo umoˇznit komunikaci mezi simul´atorem poˇc´ıtaˇcov ´ych s´ıt´ı Packet Tracer a distribuovanou s´ıt’ovou laboratoˇr´ı – Virtlab. V prvn´ı kapitole tedy kr´atce popisuji co tato dvˇe ˇreˇsen´ı umoˇz ˇnuj´ı a nab´ızej´ı. N´asleduj´ıc´ı kapitola popisuje dostupn´e Packet Tracer API a jeho moˇznosti. D´ale jsou pak pops´any protokoly, kter´e umoˇz ˇnuj´ı vz´ajemnou komunikaci mezi v´ıce simul´atory Packet Tracer. Toto propojov´an´ı podporuj´ı pouze novˇejˇs´ı verze programu Packet Tracer (5.0 a novˇejˇs´ı). Nen´ı vˇsak moˇzn´e pro tuto komunikaci pouˇz´ıt ˇz´adn´e jiˇz hotov´e ˇreˇsen´ı, jelikoˇz takov´eto bud’ neexistuje nebo nen´ı nikde zmi ˇnov´ano.
Vˇse z ˇceho fin´aln´ı implementace vych´az´ı jsou rady pˇr´ımo od v ´yvoj´aˇr ˚u simul´atoru a zdrojov´e k ´ody API. To umoˇz ˇnuje rozˇsiˇrovat samotn ´y Packet Tracer. Ke komunikaˇcn´ım protokol ˚um pouˇzit ´ym pˇri propojov´an´ı program ˚u Packet Tracer nen´ı dostupn´a t´emˇeˇr ˇz´adn´a dokumentace.
Pro to aby mezi sebou mohly komunikovat simulovan´e a re´aln´e s´ıt’ov´e prvky, bylo potˇreba vytvoˇrit jak ´ysi s´ıt’ov ´y most (dalo by se snad i ˇr´ıci pˇrekladaˇc). Tento most zajiˇst’uje pˇrevody re´aln´eho provozu na simulovan ´y a naopak.
D´ale je zde popisov´ana anal ´yza ˇreˇsen´ı a tak´e implementovan´a integrace vzd´alen´eho Packet Traceru a Virtlabu. Popisov´any jsou vˇsechny nezbytn´e ´upravy, kter´e jsou pro mnou implementovan´e rozˇs´ıˇren´ı Virtlabu potˇreba.
2
Popis souvisej´ıc´ıch projekt ˚
u
Tato kapitola obsahuje z´akladn´ı popis programu Packet Tracer a tak´e projektu distribuo-van´e laboratoˇre poˇc´ıtaˇcov ´ych s´ıt´ı Virtlab.
Tyto dva projekty si kladou za c´ıl zjednoduˇsit a zlepˇsit v ´yuku zamˇeˇrenou na poˇc´ıtaˇcov´e s´ıtˇe. Takov ´ychto projekt ˚u existuje v´ıce, ovˇsem nen´ı mi zn´am ˇz´adn ´y jin ´y, kter ´y by umoˇz ˇnoval vz´ajemn´e propojov´an´ı v r´amci dan´eho projektu.
2.1 Virtlab
Tento projekt se zab ´yv´a zpˇr´ıstupnˇen´ım s´ıt’ov ´ych prvk ˚u pro praktickou v ´yuku vzd´alenˇe prostˇrednictv´ım s´ıtˇe Internet. Pro uˇzivatele je zde moˇznost pomoc´ı webov´eho prohl´ıˇzeˇce vzd´alenˇe konfigurovat r ˚uzn´e s´ıt’ov´e prvky, kter´e jsou propojov´any automaticky dle ´ulohy. Kaˇzd ´y uˇzivatel si zde m ˚uˇze rezervovat ˇcas pro urˇcit´e zapojen´ı. Je moˇzno vybrat si jiˇz pˇripraven´e topologie, ale tak´e definovat si topologii vlastn´ı.
Souˇcasn´a verze dovoluje propojen´ı v´ıce nez´avisl ´ych lokalit a vz´ajemn´e zap ˚ujˇcov´an´ı prvk ˚u mezi lokalitami.
Tento projekt je aktivnˇe vyv´ıjen na katedˇre informatiky Vysok´e ˇskoly b´a ˇnsk´e. Je urˇcen pˇredevˇs´ım pro studenty t´eto vysok´e ˇskoly a dalˇs´ıch spolupracuj´ıc´ıch ˇskol a instituc´ı. Dalˇs´ı podrobnosti jsou dostupn´e na str´ank´ach projektu [4].
2.2 Packet Tracer
Jedn´a se o softwarov ´y simul´ator, kter ´y dovoluje simulovat rozliˇcn´e s´ıt’ov´e prvky. Co se t ´yˇce nab´ıdky prvk ˚u, jsou jeho moˇznosti omezeny t´ım co vˇse implementuj´ı v ´yvoj´aˇri. Ne-jsou zde vˇsak zat´ım dostupn´e vˇsechny protokoly a ne ´uplnˇe vˇse funguje zcela spr´avnˇe. Tento simul´ator je zamˇeˇren jen na prvky firmy Cisco a Linksys.
Tento projekt je velmi aktivnˇe vyv´ıjen spoleˇcnost´ı Cisco, kter´a jej vyv´ıj´ı pro potˇreby sv´eho v ´yukov´eho a certifikaˇcn´ıho programu. Umoˇz ˇnuje t´ımto zp ˚usobem sv ´ym student ˚um vyzkouˇset si prob´ıran´e technologie na specifick´em hardware. Prozat´ım je pouˇziteln ´y sp´ıˇse pro jednoduˇsˇs´ı ´ulohy, protoˇze simulovan´e prvky neposkytuj´ı vˇsechny funkce dostupn´e na re´aln´em s´ıt’ov´em hardware. Napojuj´ı vˇsak tento program na sv´e kurzy, aby doc´ılili lepˇs´ıho pochopen´ı dan´eho probl´emu studentem.
Od verze 5.0 je moˇzno propojit mezi sebou jednotliv´e instance tohoto programu. Toto propojen´ı funguje nad protokolem TCP/IP.
Souˇcasn´a nejnovˇejˇs´ı verze PT je 5.3 a tato zachov´av´a verzi komunikaˇcn´ıho protokolu obsaˇzenou jiˇz v 5.0. Tato nov´a verze opravuje nˇekolik chyb a rozˇsiˇruje podporovan´e pro-tokoly. Od verze PT 5.0 pˇribyla dalˇs´ı podporovan´a platforma operaˇcn´ıho syst´emu. Na platformˇe Windows byl PT funkˇcn´ı jiˇz v dˇr´ıvˇejˇs´ıch verz´ıch. K t´eto nejrozˇs´ıˇrenˇejˇs´ı plat-formˇe se pˇripojil syst´em Linux, kter ´y je dosti ˇcasto pouˇz´ıv´an pr´avˇe pro r ˚uzn´e s´ıt’ov´e ap-likace. V´ıce o t´eto aplikaci se dozv´ıte napˇr´ıklad na webov ´ych str´ank´ach Cisco Systems [5].
Jak vypad´a okno spuˇstˇen´eho programu Packet Tracer je vidˇet na obr´azku 1. V tomto oknˇe je vidˇet aktivn´ı MU spojen´ı (modr ´y obl´aˇcek) a tak´e nˇekolik s´ıt’ov ´ych prvk ˚u.
3
Packet Tracer API
Pˇri vyd´an´ı PT 5.0 doˇslo tak´e k uvolnˇen´ı jeho API ve tˇrech r ˚uzn ´ych programovac´ıch jazyc´ıch. Jedn´a se o jazyk Flash, Java a C++. Posledn´ı jmenovan ´y m´a dvˇe verze. Ta starˇs´ı je prov´az´ana s frameworkem Qt, novˇejˇs´ı jiˇz neobsahuje ˇz´adnou z´avislost na Qt. Tyto API dovoluj´ı vˇsechny bez v ´yjimky r ˚uznˇe rozˇsiˇrovat lok´alnˇe spuˇstˇen ´y PT. Pro komunikaci s PT jsou zde pouˇzity IPC zpr´avy. Jejich pˇrenos je vˇsak prov´adˇen pomoc´ı TCP/IP soketu. Pro pˇrenos zpr´av a vyjedn´an´ı parametr ˚u tohoto pˇrenosu je pouˇzito protokolu PTMP. Tento komunikaˇcn´ı protokol popisuji v n´asleduj´ıc´ı kapitole.
P ˚uvodn´ı verze C++ API obsahuje zakomentovan ´y k ´od, kter ´y ˇc´asteˇcnˇe implemen-tuje i stranu serveru PTMP. Obˇe verze tohoto API mohou b ´yt pouˇz´ıv´any na operaˇcn´ım syst´emu Microsoft Windows a Linux. V dobˇe dokonˇcov´an´ı tohoto textu se objevila nov´a verze toho API, kter´a je rozˇs´ıˇrena pro vyv´ıjenou verzi PT 5.3. Nedoˇslo k ˇz´adn ´ym ´uprav´am PTMP, ale rozˇsiˇruje moˇznosti IPC komunikace.
Verze napsan´a v jazyce Flash je jedin´a, kter´a obsahuje implementaci protokolu MU, kter ´y rozˇsiˇruje moˇznosti PTMP o vz´ajemnou datovou komunikaci PT. Umoˇz ˇnuje tedy vytv´aˇret virtu´aln´ı kabelov´a spojen´ı mezi programy PT a po nich pˇred´avat simulovan ´y provoz. Je zde vˇsak implementov´ano jen nˇekolik m´alo s´ıt’ov ´ych protokol ˚u (CDP, ARP, ICMP), kter´e PT um´ı. Je vˇsak moˇzn´e, ˇze tyto implementace nejsou zcela funkˇcn´ı. Jedin´a veˇrejn´a aplikace pouˇz´ıvaj´ıc´ı toto API je PtBridge vytvoˇren´a Gregem Neujarhem. Popis t´eto aplikace jsem um´ıstil do samostatn´e kapitoly 3.1. Jedn´a se totiˇz o program, kter ´y prov´ad´ı to co je potˇreba pro ´uspˇeˇsnou integraci PT do prostˇred´ı Virtlabu.
API napsan´e v jazyce Java poskytuje rovnˇeˇz IPC komunikaci s programem PT (v dobˇe dokonˇcov´an´ı tohoto textu je dostupn´e pouze pro verzi 5.2.1). Neobsahuje ˇz´adn´e rozd´ıly proti standardn´ı verzi C++ API, avˇsak dle PT port´alu se jedn´a o nejpouˇz´ıvanˇejˇs´ı API pro rozˇsiˇrov´an´ı PT.
V´ıce se zde o moˇznostech tohoto API rozepisovat nebudu. Pouˇzil jsem jen urˇcit´e kousky ale jako celek nen´ı ˇz´adn´e vhodn´e pro splnˇen´ı m´eho zad´an´ı.
3.1 PtBridge
Tato aplikace se skl´ad´a ze dvou ˇc´ast´ı jedna je napsan´a v jazyce Flash a pˇreloˇzena jako Adobe Air aplikace. Greg Neujarh ji pojmenoval AirBridge. Tato ˇc´ast vyuˇz´ıv´a Flash API pro nav´az´an´ı PTMP a MU spojen´ı s Packet Tracerem. Tak´e zajiˇstujˇe pˇred´av´an´ı simulo-van ´ych r´amc ˚u mezi PT a druhou ˇc´ast´ı – CppBridge, kter´a je jiˇz v jazyce C++.
CppBridge se star´a o pˇrevod CDP, ARP a ICMP protokol ˚u mezi simulovan ´ym provozem PT a re´aln ´ym. Pro tento pˇrevod pouˇz´ıv´a vlastn´ı funkce, ty mi umoˇznily pochopit jak ´ym zp ˚usobem jsou simulovan´e r´amce vytv´aˇreny. Bohuˇzel je ze zdrojov´eho k ´odu CppBridge patrn´e, ˇze tento form´at nen´ı shodn ´y s re´aln ´ymi r´amci. Jde z nich vyˇc´ıst tak´e, ˇze napˇr´ıklad protokol CDP m´a v PT provozu pˇrid´an parametr, kter ´y se u jeho re´aln´e varianty nevysky-tuje. Pˇresnˇejˇs´ı popis tˇechto r´amc ˚u jsem zahrnul do kapitoly o protokolu MU.
Ve v ´ypise 5, kter ´y je mezi pˇr´ılohami, jde vidˇet poˇrad´ı jednotliv ´ych krok ˚u pro nav´az´an´ı spojen´ı a tak´e pˇrijat ´y simulovan ´y CDP r´amec. Tento v ´ypis jsem pˇrevzal z blogu Grega
Neujarha na PT port´alu [10]. V tomto pˇr´ıpadˇe se jedn´a o spojen´ı ve kter´em PT figuruje jako server.
4
Packet Tracer Messaging Protocol
Tato kapitola pojedn´av´a o komunikaˇcn´ım protokolu PTMP. Jde o pˇreloˇzen ´y a doplnˇen ´y text [2]. Tento protokol pˇridan ´y do PT od verze 5.0 umoˇz ˇnuje IPC a MU komunikaci s PT. Protokol MU je popisov´an v n´asleduj´ıc´ı kapitole. Popis IPC protokol ˚u vˇsak tato pr´ace neobsahuje jelikoˇz je pouˇzit pouze pro lok´aln´ı vol´an´ı pˇri pouˇzit´ı API.
D´ıky nˇemu se mohou spojit a vz´ajemnˇe komunikovat dvˇe nez´avisl´e instance PT. Pro datovou komunikaci je pouˇzit protokol MU, kter ´y je pops´an v n´asleduj´ıc´ı kapitole. PTMP protokol je rovnˇeˇz pouˇzit pro inicializaci IPC komunikace. Tento protokol ob-star´av´a nezbytn´e aspekty pro n´avazn´ı spojen´ı (vyjedn´an´ı parametr ˚u, autentizace, ...). 4.1 Architektura PTMP protokolu
Protokol pracuje nad TCP/IP a je navrˇzen jako obecn ´y protokol pro pˇred´av´an´ı zpr´av. Form´at zpr´av pouˇzit ´ych u nav´az´an´ı spojen´ı popisuji v dalˇs´ı ˇc´asti t´eto kapitoly. Aplikace vyuˇz´ıvaj´ıc´ı PTMP si mohou pˇrid´avat nov´e zpr´avy a jejich definice. Tyto zpr´avy mohou b ´yt speci´aln´ımi r´amci pouˇzit ´ymi v MU nebo IPC vol´an´ı v pˇr´ıpadˇe IPC. Z´avis´ı tedy na kaˇzd´e komponentˇe, kter´a vyuˇz´ıv´a tento protokol, jak´e zpr´avy si dopln´ı a jak ´ym zp ˚usobem je bude zpracov´avat. Obecnˇe m ˚uˇzeme PTMP povaˇzovat za dalˇs´ı vrstvu nad TCP, kterou mohou vyuˇz´ıvat aplikace pro komunikaci s PT.
Komunikaˇcn´ı sch´ema pro PTMP aplikace je klient-server, zaloˇzen´e na TCP. Aplikace m ˚uˇze naslouchat na TCP portu a dovolit jin ´ym instanc´ım nav´azat spojen´ı. V naˇsem pˇr´ıpadˇe jsem pr´avˇe toto vyuˇzil a implementovan ´y PTServer naslouch´a na zvolen´em portu a obsluhuje klienty. V ´ychoz´ım portem pro MU je 38000 a pro IPC 39000. Tyto porty nejsou zat´ım pˇriˇrazeny ˇz´adn´e jin´e aplikaci. Komponenty mohou samozˇrejmˇe tento port mˇenit. Jedna PTMP aplikace se m ˚uˇze spojit s jinou, pokud zn´a jej´ı IP adresu a port.
Kdyˇz je spojen´ı nav´az´ano, pˇrich´az´ı na ˇradu vyjedn´an´ı parametr ˚u. Obˇe strany PTMP mus´ı vˇedˇet, jak´e parametry pro spojen´ı pouˇzij´ı. Domlouv´a se zp ˚usob autentizace, reˇzim pˇrenosu zpr´av, komprese a ˇsifrov´an´ı. Pak se autentizuje klientsk´a PTMP aplikace. Je zde tedy moˇzn ´y bezpeˇcnostn´ı probl´em, identita server nen´ı nijak zajiˇstˇena.
Po nav´az´an´ı TCP spojen´ı, vyjedn´an´ı parametr ˚u a autentizaci se jiˇz ned´a hovoˇrit o kon-ceptu klient-server. Obˇe PTMP aplikace maj´ı stejn´e role a funkce. Mohou si tedy navz´ajem vymˇe ˇnovat zpr´avy d´ıky PTMP. Jak prob´ıhaj´ı jednotliv´e kroky je vidˇet na obr´azku 2.
Jak dovoluje samotn´e TCP, je moˇzno na jednom pˇr´ıchoz´ım portu nav´azat v´ıce spo-jen´ı. Pro kaˇzd´e TCP spojen´ı se v Packet Traceru vytvoˇr´ı (nebo si jej vytvoˇr´ıme sami) MU spojen´ı, kter´e je reprezentov´ano graficky vlastn´ım obl´aˇckem.
V dokumentu [2] je naps´ano, ˇze pokud si pˇreje PTMP aplikace ukonˇcit spojen´ı, zaˇsle o tom n´aleˇzitou zpr´avu. Ta je popisov´ana d´ale a je dokonce implementov´ana i v API. Avˇsak pˇri uzavˇren´ı spojen´ı v PT k odesl´an´ı t´eto zpr´avy nedojde a je zasl´ano pouze nˇejak´e nesmysln´e ˇc´ıslo.
4.2 Reˇzimy pˇrenosu zpr ´av
Protoˇze PTMP aplikace mohou b ´yt naps´any v r ˚uzn ´ych programovac´ıch jazyc´ıch, je nutn´e ˇreˇsit i reˇzim pˇrenosu zpr´av. Napˇr´ıklad pro aplikace napsan´e v jazyce Flash je nezbytn ´y textov ´y reˇzim. Nicm´enˇe bin´arn´ı reˇzim umoˇz ˇnuje efektivnˇejˇs´ı pˇrevody a kratˇs´ı zpr´avy, proto je podporov´an tak´e bin´arn´ı reˇzim.
Reˇzim pˇrenosu zpr´av je vyjedn´an na zaˇc´atku kaˇzd´eho spojen´ı.
Dokument specifikuj´ıc´ı PTMP definuje z´akladn´ı datov´e typy pro zpr´avy. Tyto typy jsou pouˇzity pro z´akladn´ı PTMP zpr´avy a jsou implementov´any i v API Packet Traceru. Je moˇzno definovat i vlastn´ı datov´e typy, jejich specifikace je jiˇz na aplikac´ıch vyuˇz´ıvaj´ıc´ıch PTMP. Pˇr´ıkladem by mohly b ´yt r´amce, kter´e jsou pˇren´aˇseny v MU. Tyto jsou podobn´e re´aln ´ym, avˇsak jsou upraveny pro snazˇs´ı zpracov´an´ı v Packet Traceru (d´ale budou naz ´yv´any pseudor´amci).
Form´at tˇechto z´akladn´ı typ ˚u a jejich reprezentace v obou typech k ´odov´an´ı je uk´az´an v tabulce 1.
Vˇsechny uveden´e typy nejsou povinn´e. Jsou vˇsak uˇziteˇcn´e pro udrˇzen´ı kompatibility pˇri pˇrenosu zpr´av. Datov´e typy bez znam´enka nejsou zahrnuty, protoˇze jazyk Java nem´a podporu pro datov´e typy bez znam´enka.
Bin´arn´ı reˇzim urˇcuje d´elku nebo ukonˇcovac´ı znak kaˇzd´eho datov´eho typu. 4.3 Obecn ´y form ´at zpr ´av
Zpr´avy mohou b ´yt pˇren´aˇseny mezi dvˇema PTMP aplikacemi jakmile je nav´az´ano TCP spojen´ı. Tyto zpr´avy nemus´ı b ´yt posl´any v r´amci jednoho TCP segmentu. Mohou m´ıt t´emˇeˇr nekoneˇcnou d´elku (231−1= maxim´aln´ı velikost integeru) a mohou b ´yt v mnoha TCP segmentech. Jsou vˇsak zpracov´any pouze v pˇr´ıpadˇe, ˇze je pˇrijata cel´a zpr´ava. Vˇsechny zpr´avy mus´ı spl ˇnovat n´asleduj´ıc´ı form´at zpr´av, aby bylo moˇzno odliˇsit r ˚uzn´e typy zpr´av a tak´e kde zpr´ava konˇc´ı.
Zpr´ava obsahuje tyto pole:
• D´elka (int) - poˇcet bajt ˚u nebo znak ˚u ve zpr´avˇe, popisuje d´elku typu a obsahu zpr´avy, nen´ı komprimov´ana ani ˇsifrov´ana
• Typ (int) - urˇcuje typ zpr´avy
• Obsah - data promˇenn´e d´elky
V poli typu m ˚uˇze b ´yt ˇc´ıslo, kter´e nab ´yv´a hodnoty podle tabulky 2. Form´aty jed-notliv ´ych zpr´av PTMP jsou pops´any v n´asleduj´ıc´ıch ˇc´astech.
4.4 Stavov ´y diagram
Pˇri navazov´an´ı PTMP spojen´ı proch´az´ı n´asleduj´ıc´ımi stavy:
• Nepˇripojeno: neinicializov´ano TCP spojen´ı
Jm´eno Bin´arnˇe Textovˇe (vˇse ukonˇceno pomoc´ı\0)
byte 8-bitov´a hodnota se
znam´enkem
hodnota v rozsahu−128aˇz127
bool 8-bitov´a hodnota - true/false ”true” nebo ”false”
short 16-bitov´a hodnota se
znam´enkem
hodnota v rozsahu−215aˇz215–1
int 32-bitov´a hodnota se
znam´enkem
hodnota v rozsahu−231aˇz231–1
long 64-bitov´a hodnota se
znam´enkem
hodnota v rozsahu−263aˇz263–1
float 32-bitov´a hodnota s jedn´ım desetinn ´ym m´ıstem
desetinn´e ˇc´ıslo double 64-bitov´a hodnota se dvˇema
desetinn ´ymi m´ısty
desetinn´e ˇc´ıslo string unik ´odov´e znaky r ˚uzn´e
d´elky ukonˇcen´e\0
unik ´odov´e znaky r ˚uzn´e d´elky ukonˇcen´e\0
QString unik ´odov´e znaky r ˚uzn´e d´elky ukonˇcen´e\0
unik ´odov´e znaky r ˚uzn´e d´elky ukonˇcen´e\0
IP adresa 32-bitov´a hodnota IP adresa ve form´atu x.x.x.x
IPv6 adresa 32-bitov´a hodnota IPv6 adresa ve form´atu
x:x:x:x:x:x:x:x
MAC adresa 48-bitov´a hodnota MAC adresa ve form´atu
xxxx.xxxx.xxxx
uuid 128-bitov´a hodnota UUID ve form´atu{
HHHHHHHH-
HHHH-HHHH-HHHH-HHHHHHHHHHHH}
Tabulka 1: Tabulka PTMP datov ´ych typ ˚u a zp ˚usob jejich reprezentace
Hodnota N´azev Obsah zpr´avy
0 NEGOREQ ˇz´adost o vyjedn´an´ı parametr ˚u
1 NEGORESP odpovˇed’ na vyjedn´an´ı parametr ˚u
2 AUTHREQ poˇzadavek na autentizaci
3 AUTHCHAL v ´yzva k autentizaci
4 AUTHRESP odpovˇed’ na autentizaˇcn´ı v ´yzvu
5 AUTHSTATUS status autentizace
6 KEEPALIVE keep-alive
7 DISCONNECT odpojen´ı
>= 100, <200 – IPC zpr´ava
>= 200, <300 – Multi-user zpr´ava Tabulka 2: Hodnoty pole typ pro PTMP zpr´avy
Obr´azek 3: PTMP – zjednoduˇsen ´y stavov ´y diagram
• Vyjedn´av´an´ı: doch´az´ı k vyjedn´an´ı parametr ˚u pouˇzit ´ych pro spojen´ı
• Ovˇeˇrov´an´ı: doch´az´ı k autentizaci
• Vytvoˇreno: autentizov´ano a plnˇe funkˇcn´ı PTMP spojen´ı
Zjednoduˇsen ´y stavov ´y diagram je vidˇet na obr´azku 3. V ´ychoz´ım stavem je Nepˇripojeno. 4.5 Vyjedn ´an´ı spojen´ı
Kdyˇz je nav´az´ano TCP spojen´ı, tak prvn´ı krok, kter ´y dvˇe PTMP aplikace udˇelaj´ı je, ˇze si domluv´ı parametry spojen´ı. Je potˇreba aby si komunikuj´ıc´ı komponenty dohodly parame-try, kter´e pouˇzij´ı pro toto vz´ajemn´e propojen´ı.
PMTP aplikace si vymˇe ˇnuj´ı informace pˇri vyjedn´av´an´ı pomoc´ı zpr´av v tomto form´atu:
• PTMP identifik´ator (string): konstant identifik´ator, ”PTMP”
• Verze PTMP (int): 1
• ID PTMP aplikace (uuid): UUID aplikace odes´ılaj´ıc´ı tuto zpr´avu
• K ´odov´an´ı (int): 1 = text, 2 = bin´arn´ı
• Komprese (int): 1 = ne, 2 = zlib
• Autentizace (int): 1 = ˇcist ´y text, 2 = jednoduch´a, 4 = MD5
• Casov´e raz´ıtko (string): m´ıstn´ı ˇcas, kdy bylo zah´ajeno spojen´ı, ve form´atu YYYYM-ˇ MDDHHMMSS
• Keep-alive (int): keep-alive dobu v sekund´ach
• Vyhrazeno (string): v souˇcasn´e dobˇe nevyuˇzit´e
Klient pos´ıl´a ˇz´adost o vyjedn´an´ı spojen´ı na server (zpr´ava typu 0 - NEGOREQ) se sv ´ymi navrhovan ´ymi ´udaji, ve zpr´avˇe specifikuje sv´e parametry, kter´e navrhuje pro spo-jen´ı. Server v odpovˇedi (zpr´ava typu 1 - NEGORESP) pos´ıl´a sv´e ´udaje, kter´e se pouˇzij´ı pro komunikaci. Takto je vyjedn´an´ı implementov´ano v souˇcasn´e verzi API.
4.6 Autentizace
Pro autentizaci je pouˇzito CRAM (Challenge Response Authentication Mechanism), aut-entizaˇcn´ı mechanizmus zaloˇzen ´y na poˇzadavc´ıch a reakc´ıch na nˇe.
Po nav´az´an´ı TCP spojen´ı a vyjedn´an´ı parametr ˚u spojen´ı zaˇc´ın´a autentizaˇcn´ı pro-ces. Pˇredpokladem je, ˇze klientsk´a i serverov´a aplikace vyuˇz´ıvaj´ıc´ı PTMP pouˇz´ıv´a stejn´e ovˇeˇrovac´ı ´udaje (jm´eno a heslo nebo ID a kl´ıˇc). Je to nezbytn´e pro ´uspˇeˇsn´e proveden´ı autentizace.
Klient nejprve zaˇsle zpr´avu se ˇz´adosti o autentizaci (typ 2 - AUTHREQ). Server reaguje odesl´an´ım v ´yzvy k autentizaci (typ 3 - AUTHCHAL). V ´yzva obsahuje n´ahodnˇe gen-erovan ´y ˇretˇezec obsahuj´ıc´ı 32 znak ˚u.
Pokud byla domluvena autentizace v neˇsifrovan´e podobˇe (ˇcist ´y text), uˇzivatel zaˇsle sv´e heslo server jako neˇsifrovan ´y text. V pˇr´ıpadˇe pouˇzit´ı jednoduch´e autentizace se pouˇzije pro ˇsifrov´an´ı hesla algoritmus popsan ´y v ˇc´asti 4.6.5. Pokud se m´a vyuˇz´ıt MD5 autenti-zace, tak se pomoc´ı haˇsovac´ı funkce MD5 otisk hesla spojen´eho s vygenerovan ´ym textem z v ´yzvy. MD5 metoda je v PT zvolena jako v ´ychoz´ı. Takto upraven´e heslo se zaˇsle serveru v autentizaˇcn´ı odpovˇedi (typ 4 - AUTHRESP). Server pouˇzije dohodnutou metodu au-tentizace pro ovˇeˇren´ı hesla. Pot´e je klientovi zasl´ana zpr´ava o stavu auau-tentizace (typ 5 - AUTHSTATUS). Pokud nen´ı autentizace ´uspˇeˇsn´a, server zaˇsle zpˇet zpr´avu o odpojen´ı (typ 7 - DISCONNECT) a ukonˇc´ı spojen´ı. V PT vˇsak uˇzivatel neobdrˇz´ı ˇz´adn´e upozornˇen´ı o tom, ˇze autentizace selhala. Poˇrad´ı krok ˚u je vidˇet na obr´azku 4.
4.6.1 Form ´at zpr ´avy typu 2 - ˇz ´adost o autentizaci V t´eto zpr´avˇe jsou n´asleduj´ıc´ı pole:
Obr´azek 4: PTMP – sekvence autentizaˇcn´ıho protokolu 4.6.2 Form ´at zpr ´avy typu 3 - autentiza ˇcn´ı v ´yzva
Tato zpr´ava obsahuje pole:
• Text v ´yzvy (string): n´ahodnˇe generovan ´y 32 znak ˚u dlouh ´y text, je pouˇzit pˇri ˇsifrov´an´ı hesla
4.6.3 Form ´at zpr ´avy typu 4 - odpov ˇed’ na autentiza ˇcn´ı v ´yzvu Pole t´eto odpovˇedi jsou tyto:
• Uˇzivatelsk´e jm´eno (string): uˇzivatelsk´e jm´eno nebo ID klienta (napˇr. ”Peer0”)
• Heslo (string): obsah tohoto pole je z´avisl ´y zp ˚usobu autentizace
• Obecn´e (string): rezervov´ano, zat´ım nevyuˇzito 4.6.4 Form ´at zpr ´avy typu 5 - status autentizace Tato zpr´ava obsahuje pole:
• Stav (bool): true = ´uspˇeˇsn´a autentizace, false = ne ´uspˇeˇsn´a autentizace 4.6.5 Jednoduch ´a metoda autentizace
Pro zaˇsifrov´an´ı hesla je pouˇzita n´asleduj´ıc´ı jednoduch´a funkce. Toto je implementace z´ıskan´a ze zdrojov ´ych k ´od ˚u C++ API.
string simple hash(string password)
{
string hash;
for (int i = 0; i <password.length; i++) hash[i ] = 158−password[i];
returnhash;
}
V ´ypis 1: Jednoduch ´y algoritmus pro ˇsifrov´an´ı hesla
4.7 Sifrov ´an´ıˇ
Z bezpeˇcnostn´ıch d ˚uvod ˚u je moˇzno komunikaci mezi PTMP aplikacemi ˇsifrovat. Kaˇzd´a zpr´ava po vyjedn´an´ı parametr ˚u m ˚uˇze b ´yt ˇsifrov´ana, pokud se tak aplikace dohodnou. Pro ˇsifrov´an´ı je pouˇzita jednoduch´a metoda XOR dat se symetrick ´ym kl´ıˇcem (tj. server i klient pouˇz´ıvaj´ı stejn ´y kl´ıˇc pro ˇsifrov´an´ı a deˇsifrov´an´ı).
ˇSifrovac´ı kl´ıˇc je odvozen od UUID a ˇcasov´e znaˇcky serveru a klienta. Vˇsechny tyto ´udaje jsou vymˇenˇeny pˇri vyjedn´av´an´ı spojen´ı. Unik´atn´ı identifik´atory UUID jsou n´ahodnˇe generov´any pˇri spuˇstˇen´ı aplikace. Jejich form´at odpov´ıd´a datov´emu typu uuid defino-van´em v ´yˇse. Pro kl´ıˇc jsou pak pouˇzity vˇsechny tyto ´udaje, kter´e jsou za sebou poskl´ad´any v tomto poˇrad´ı:
1. UUID server 2. UUID kliena 3. ”PTMP”
4. ˇCasov´e raz´ıtko serveru 5. ˇCasov´e raz´ıtko klienta 4.8 Komprese
Pro kompresi je pouˇzita knihovna zlib [3]. Vˇsechny zpr´avy po vyjedn´avac´ım procesu mo-hou b ´yt komprimov´any pokud je komprese zpr´av domluvena pˇri vyjedn´av´an´ı spojen´ı. 4.9 Poˇrad´ı operac´ı PTMP
V popsan´em poˇrad´ı jsou prov´adˇeny jednotliv´e v ´yˇse popsan´e operace pˇri pˇr´ıjmu a odes´ıl´an´ı zpr´av.
Kdyˇz PTMP odes´ıl´a zpr´avu, je pouˇzito toto poˇrad´ı operac´ı: 1. Ve zpr´avˇe je vyplnˇen typ a obsah zpr´avy
(a) Pokud je vyjedn´ano, je zpr´ava zkomprimov´ana (b) Pokud je vyjedn´ano, zpr´ava se zaˇsifruje
3. Spoˇc´ıt´a se a vypln´ı velikost zpr´avy
Kdyˇz PTMP pˇrijme zpr´avu pouˇz´ıv´a toto poˇrad´ı ´ukon ˚u: 1. Z´ısk´a ze zpr´avy jej´ı velkost
2. Pokud je PTMP ve stavu autentizov´an´ı nebo je jiˇz spojeno (a) Pokud je vyjedn´ano, deˇsifruje zpr´avu
(b) Pokud je vyjedn´ano, dekomprimuje zpr´avu 3. Pˇred´a zpr´avu patˇriˇcn´e komponentˇe vyuˇz´ıvaj´ıc´ı PTMP 4.10 Udrˇzov ´an´ı spojen´ı
Keep-aplive mechanizmus je v PTMP pouˇz´ıv´an pro detekci ˇc´asti, kter´a o odpojen´ı neposlal patˇriˇcnou zpr´avou. ˇCasov´e prodlevy mezi keep-alive zpr´avami jsou vyjedn´any na zaˇc´atku spojen´ı. Klient zas´ıl´a ve stanoven´em ˇcase zpr´avy, na kter´e v tomto ˇcase server ˇcek´a. Prodl-eva mezi zpr´avami je v sekund´ach. Pokud je pˇri vyjedn´av´an´ı nastavena na nulu, tak keep-alive zpr´avy nebudou v ˚ubec zas´ıl´any. Tyto PMTP zpr´avy nemaj´ı ˇz´adn ´y obsah a jsou typu 6 - keep-alive. Pokud nejsou obdrˇzeny tˇri za sebou jdouc´ı zpr´avy, tak PTMP prohl´as´ı spojen´ı za ukonˇcen´e a informuje o tom aplikaci.
Ve v ´ychoz´ım stavu Packet Traceru pro MU spojen´ı je volba pro udrˇzov´an´ı spojen´ı nastaven´a na 0 a tud´ıˇz nejsou ˇz´adn´e zpr´avy tohoto typu zas´ıl´any. Toto chov´an´ı je vˇsak pro n´as v ´yhodn´e, jelikoˇz se ˇsetˇr´ı pˇrenosovou kapacitou.
5
Multi-user connection
Tento protokol je nadstavbou nad protokolem PTMP a pr´avˇe on umoˇz ˇnuje v ´ymˇenu pseu-dor´amc ˚u mezi instancemi PT. Tento protokol m´a ponˇekud jednoduˇs´ı stavbu neˇz v ´yˇse popisovan´e PTMP. Vyuˇz´ıv´a j´ım vytvoˇren´e a obsluhovan´e spojen´ı a pˇrid´av´a do PTMP nov´e typy zpr´av, kter´e pak s´am zpracov´av´a.
Pseudor´amce jsou pˇren´aˇseny po virtu´aln´ıch spoj´ıch - link´ach, kter´e jsou odliˇseny je-dineˇcn ´ym ˇc´ıslem linky. V PT jsou MU spojen´ı zobrazov´ana formou bledˇemodr´eho obl´aˇcku se tˇremi pruhy (jeho vzhled je na obr´azku 5). Prvn´ı dva pruhy indikuj´ı ´uspˇeˇsn´e PTMP spojen´ı a posledn´ı pruh pak signalizuje ´uspˇeˇsnost MU spojen´ı. Tento prvek pak zobrazuje i informace o link´ach. Kaˇzd ´y pˇripojen ´y port zaˇr´ızen´ı m´a vlastn´ı linku. Jedn´a se o dvou-bodov´e spojen´ı. Kaˇzd ´y takov ´yto obl´aˇcek m´a sv´e jm´eno, kter´e je jedineˇcn´e v r´amci jedn´e instance PT.
5.1 Architektura MU protokolu
Tento protokol vyuˇz´ıv´a jiˇz vytvoˇren´e PTMP spojen´ı i se vˇsemi parametry. Jakmile je po-moc´ı protokolu PTMP spojen´ı vytvoˇreno a protokol se dostane do stavu spojeno, tak se zapoˇcne s nav´az´an´ım MU spojen´ı. Zaˇslou se zpr´avy, kter ´ymi si server a klient vymˇen´ı uˇzivatelsk´e jm´eno a sv´e UUID. Pot´e si vymˇen´ı informace o jiˇz vytvoˇren ´ych link´ach. Ty jsou ˇc´ıslov´any od nuly, ale pˇri odeb´ır´an´ı doch´az´ı k pˇrepoˇc´ıt´an´ı jejich ˇc´ısel. Vˇzdy se jedn´a o souvislou ˇradu ˇc´ısel, proto se mus´ı informovat obˇe strany o zmˇen´ach a udrˇzovat si synchronizovan´e informace o link´ach.
Pot´e m ˚uˇze b ´yt zasl´ana zpr´ava o zmˇenˇe jm´ena MU spojen´ı (PT ji pos´ıl´a vˇzdy). Jedn´a se o jm´eno, kter´e je pouˇzito pro popis obl´aˇcku v PT. D´ale n´asleduje zpr´ava s informac´ı typu (202 - MUPORTADV). Tato zpr´ava je obvykle pr´azdn´a, jej´ı smysl a obsah je pops´an d´ale v t´eto kapitole.
Po v ´ymˇenˇe vˇsech potˇrebn ´ych zpr´av je MU spojen´ı ´uspˇeˇsnˇe nav´az´ano a pokud je vytvoˇrena i nˇejak´a aktivn´ı linka, tak jiˇz od t´eto chv´ıle m ˚uˇze pˇren´aˇset pseudor´amce.
V tabulce 3 jsou jednotliv´e ˇc´ısla zpr´av pˇridan ´ych do PTMP. 5.2 Vyjedn ´an´ı MU spojen´ı
Aby bylo MU spojen´ı funkˇcn´ı, je nezbytn´e, aby klient zaslal zpr´avu MUNEGOREQ a server mu odpovˇedˇel zpr´avou MUNEGORESP. Tyto zpr´avy maj´ı shodn ´y obsah, liˇs´ı se jen jejich typ. Tato zpr´ava obsahuje tyto pole:
• Uˇzivatelsk´e jm´eno (string): uˇzivatelsk´e jm´eno, obvykle nastaveno na ”Guest” coˇz je v ´ychoz´ı hodnota v PT
• Uuid aplikace (uuid): UUID spuˇstˇen´e aplikace
Tato zpr´avy jsou tedy nezbytn´e pro korektn´ı fungov´an´ı cel´eho MU spojen´ı. Uˇzivatelsk´e jm´eno pouˇzit´e touto zpr´avou je v pˇr´ıpadˇe PT nastaviteln´e v uˇzivatelsk´em profilu. Pro
Obr´azek 5: PT – vzhled odpojen´eho a pˇripojen´eho MU obl´aˇcku
Hodnota N´azev Obsah zpr´avy
200 MUNEGOREQ ˇz´adost o vyjedn´an´ı MU spojen´ı
201 MUNEGORESP odpovˇed’ na vyjedn´an´ı MU spojen´ı
202 MUPORTADV informace o portech
203 MULINKUPDATE informace o lince
204 MULINKUPDATESTATUS status probˇehnut´e operace z informaˇcn´ı zpr´avy
205 MUPDU pseudor´amec
206 MUSAVENETREQ poˇzadavek na uloˇzen´ı s´ıtˇe 207 MUSAVENETRESP odpovˇed’ na uloˇzen´ı s´ıtˇe
208 MUCONIN vstup konzole
209 MUCONOUT v ´ystup na konzoli
210 MUNAMEUPDATE nov´e jm´eno
Tabulka 3: Hodnoty pole typ pro MU zpr´avy 5.3 Informace o portech
Program PT pos´ıl´a zpr´avu MUPORTADV, vˇzdy pˇri nav´az´an´ı MU spojen´ı i kdyˇz je pr´azdn´a. Tato zpr´ava slouˇz´ı k informov´an´ı protistrany o dostupn ´ych portech. Uˇzivatel m ˚uˇze v nab´ıdce PT nastavit, kter´e porty jsou viditeln´e pˇres MU spojen´ı. D´ıky tomuto nastaven´ı pak tyto porty mohou b ´yt pouˇzity pro vytvoˇren´ı linky. Tato zpr´ava pak obsahuje z´akladn´ı pole a na nˇe dynamicky nav´azan´e informace o portech. Vypad´a takto:
• D´elka (int): d´elka n´asleduj´ıc´ı zpr´avy o portech
• Zpr´ava o portech: obsahuje informace o portu v tomto form´atu, tyto informace mo-hou byt obsaˇzeny v´ıcekr´at
– ID (int): identifikaˇcn´ı ˇc´ıslo portu
– Typ (int): typ portu viz. tabulka 4
– Jm´eno (string): jm´eno portu
Tato informaˇcn´ı zpr´ava nen´ı pro spr´avn´e fungov´an´ı MU spojen´ı nezbytn´a. 5.4 Informace o lince
Cel ´y pˇrenos pseudor´amc ˚u mezi PT je zaloˇzen na pˇrenosech po link´ach. Toto by se mohlo porovnat se syst´emem VLAN ˚u 802.1Q. Aby obˇe strany mˇely stejn´e informace o pˇripojen ´ych
Hodnota V ´yznam 1 konzole (v prvc´ıch obvykle RJ45) 2 10BASE-T (RJ45) 3 100BASE-TX (RJ45) 4 1000BASE-T (RJ45) 5 100BASE-FX (SC) 6 1000BASE-LX (SC) 7 serial (DB 60)
8 serial (smart serial)
18 modem (RJ11)
19 serial (RS 232)
21 koax (BNC)
Tabulka 4: Hodnoty pole typ portu pro MU zpr´avy
link´ach, je zde typ zpr´avy, kter´a v ´ymˇenu tˇechto informac´ı umoˇz ˇnuje. Jsou podporov´any operace vytvoˇren´ı nov´e linky, zmˇena parametr ˚u linky, odpojen´ı a smaz´an´ı linky. Kaˇzd´a linka m´a pˇriˇrazeno ˇc´ıslo, kter´e je poˇc´ıt´ano od 0 a je z´avisl´e na poˇrad´ı vytvoˇren´ı linky.
ˇ
C´ısla linek jsou v souvisl´e ˇradˇe a pˇri maz´an´ı tedy mus´ı doj´ıt k jejich pˇrepoˇc´ıt´an´ı. Form´at zpr´av typu 203 - MULINKUPDATE je takov ´yto:
• ID operace (int): ID operace s linkou (nyn´ı vˇzdy 0)
• Typ operace (int): typ operace, kter´a se m´a s linkou prov´est, 0 = vytvoˇren´ı nov´e linky, 1 = zmˇena informac´ı o lince, 2 = odpojen´ı linky, 3 = smaz´an´ı
• ID linky (int): ID linky
• UUID linky (uuid): unik´atn´ı identifik´ator linky
• ID portu (int): ID portu
• Typ kabelu (int): typ kabelu viz. tabulka 5
• Jm´eno portu (string)
• Typ portu (int): typ portu viz. tabulka 4
• Stav portu (bool): 1 = aktivn´ı, 0 = neaktivn´ı
• Pˇr´ım´e zapojen´ı (bool): 0 - kˇr´ıˇzen ´y kabel, 1 - pˇr´ım ´y
• Automatick´e kˇr´ıˇzen´ı (bool)
• Rychlost portu (int)
Hodnota V ´yznam
0 standardn´ı mˇedˇen ´y UTP kabel 1 pˇr´ım ´y UTP kabel
2 kˇr´ıˇzen ´y UTP kabel 3 konzolov ´y kabel 4 optick ´y kabel 5 s´eriov ´y kabel
6 telefonn´ı kabel pro modem 7 koaxi´aln´ı kabel
Tabulka 5: Hodnoty pole typ kabelu pro MULINKUPDATE
• Autonegociace (bool)
• Vyjedn´an´ı rychlosti (bool)
• Vyjedn´an´ı duplexity (bool)
• Clockrate (int)
• DCE Port (bool)
V tabulce 5 jsou uvedeny typy kabel ˚u, jak jsou definov´any v programu PT.
Na tuto zpr´avy by mˇela odpov´ıdat zpr´ava typu 204 - MULINKUPDATESTATUS. Tato m´a obsahovat ID operace a jej´ı status, avˇsak v Informaˇcn´ıch zpr´av´ach o lince (203 -MULINKUPDATE) je ID operace vˇzdy 0 a zpr´ava o statusu nen´ı zat´ım vyuˇzita a odes´ıl´ana. Moˇzn´a je s n´ı poˇc´ıt´ano do budoucna ale souˇcasn ´y stav je takt´eˇz plnˇe funkˇcn´ı. Pro spr´avnou funkci se mi tato zpr´ava nejev´ı ani pˇr´ıliˇs potˇrebn´a.
S tˇemito zpr´avami souvis´ı i to, ˇze si d´ıky nim m ˚uˇze aplikace PT vytvoˇrit tabulku pˇrehledu jednotliv ´ych linek, kter´a obsahuje informace o lok´aln´ım a vzd´alen´em stavu pˇripojen´eho portu (up/down) a tak´e k jak´emu zaˇr´ızen´ı je linka pˇripojena. Vˇsechny tyto informace se zobrazuj´ı v PT.
5.5 Pseudor ´amec
Zpr´ava typu 205 - MUPDU obsahuje samotn´e pseudor´amce, pomoc´ı kter ´ych doch´az´ı k v ´ymˇen´am dat mezi propojen ´ymi simulovan ´ymi zaˇr´ızen´ımi. Jej´ı z´akladn´ı form´at je velmi jednoduch ´y. Obsahuje tato pole:
• ID zpr´avy (int)
• ID linky (int): ID linky kterou pseudor´amec proch´az´ı
ID zpr´avy je na stranˇe PT zˇrejmˇe generov´ano n´ahodnˇe. ˇC´ısla na sebe nenavazuj´ı a nemus´ı j´ıt nutnˇe ani za sebou. Moment´alnˇe nejsp´ıˇse toto pole nen´ı nijak vyuˇzito ke zpra-cov´an´ı. ˇC´ıslo linky vˇsak ke spr´avn´emu doruˇcen´ı zpr´avy nezbytn´e je. Pro to aby pseu-dor´amce byly pos´ıl´any linkou je nezbytn´e, aby byly oba konce linky aktivn´ı. Samotn ´y obsah PDU je r ˚uzn ´y, avˇsak z´akladn´ı informace o typu pˇren´aˇsen´eho r´amce jsou obsaˇzeny textovˇe. Tyto informace jsem z´ıskal pˇri anal ´yze PTMP potaˇzmo MU provozu pomoc´ı s´ıt’ov´eho analyz´atoru Wireshark. Jedn´a se vˇzdy o textov ´ych soupis vˇsech ˇc´ast´ı, kter´e jsou v r´amci pˇren´aˇseny. Napˇr´ıklad pro ARP r´amec vypad´a tato textov´a hlaviˇcka takto ”CEth-ernetIIHeader CArpPacket”.
Obvykle pseudor´amce obsahuj´ı velmi podobn´a pole jako v pˇr´ıpadˇe re´aln ´ych r´amc ˚u. Rozd´ıl kter ´y vˇsak u vˇsech pseudor´amc ˚u je, ˇze t´emˇeˇr vˇsechny d´elkov´e ˇc´asti a kontroln´ı souˇcty jsou nulov´e. Tak´e je zachov´ano obr´acen´e poˇrad´ı jednotlivych s´ıt’ov ´ych protokol ˚u v pseudor´amc´ıch. Po textov´e hlaviˇcce tedy n´asleduje nejhloubˇeji zanoˇren ´y obsah r´amce (napˇr´ıklad samotn ´y obsah protokolu ARP) a na konci se nach´az´ı ˇc´ast spojov´e vrstvy (napˇr. ethernetov´e adresy).
U nˇekter ´ych protokol ˚u jsou vˇsak pˇrid´any do pseudor´amc ˚u parametry, kter´e se v re´aln ´ych r´amc´ıch dan´eho protokolu nevyskytuj´ı. Tak´e form´at nˇekter ´ych parametr ˚u neod-pov´ıd´a zcela re´aln ´ym r´amc ˚um. Z tohoto d ˚uvodu je potˇreba pro kaˇzd ´y podporovan ´y pro-tokol pouˇz´ıt funkci, kter´a se postar´a o korektn´ı pˇrevod dat.
5.6 Uloˇzen´ı s´ıt ˇe
Zpr´avy typu 206 - MUSAVENETREQ a 207 - MUSAVENETRES umoˇz ˇnuj´ı uloˇzen´ı simulo-van´e s´ıtˇe. Jsou zde z d ˚uvodu dvou reˇzim ˚u, kter´e PT obsahuje. T´ım prvn´ım je reˇzim re´aln´eho ˇcasu, kter ´y funguje jako standardn´ı s´ıt’ a dovoluje simulovat chov´an´ı v re´aln´em ˇcase. V tomto reˇzimu PT funguje pˇri spuˇstˇen´ı.
Druh ´y reˇzim je simulaˇcn´ı. V nˇem doch´az´ı k zobrazov´an´ı provozu, kter ´y se s´ıt´ı ˇs´ıˇr´ı. Je moˇzno prohl´ıˇzet si v oknˇe obsah r´amce. Zobrazen´ı tˇechto r´amc ˚u odpov´ıd´a tomu jak jsou r´amce prezentov´any v re´aln´e s´ıti. V tomto simulaˇcn´ım reˇzimu lze filtrovat protokoly, pokud se zaj´ım´ame jen o urˇcit ´y s´ıt’ov ´y protokol.
Tento reˇzim nab´ız´ı automatick´e zachyt´av´an´ı a pˇrehr´av´an´ı. V tomto simulovan´em reˇzimu je vˇsak pˇrenos r´amc ˚u znaˇcnˇe zpomalen z d ˚uvodu n´azornosti.
Pokud si uˇzivatel pˇreje pˇri nav´azan´em MU spojen´ı pˇrepnout svou s´ıt’ do simulo-van´eho reˇzimu, tak dojde ke spuˇstˇen´ı nov´e instance PT. V n´ı m´a uˇzivatel celu svou topologii a z´akladn´ı informace o vzd´alen´em konci. Tyto zpr´avy jsem vˇsak podrobnˇeji nezkoumal, nepovaˇzuji je za potˇrebn´e pro ´uˇcely integrace s Virtlabem. Jejich form´at zde tak´e nebudu rozepisovat jelikoˇz nejsou v implementaci m´e pr´ace vyuˇzity.
5.7 Vstup a v ´ystup konzole
Jelikoˇz je moˇzn´e pˇripojit skrze MU i konzole vzd´alen ´ych prvk ˚u, jsou v MU definov´any i zpr´avy pro pˇrenos tˇechto dat skrze MU spojen´ı. Nejsou v nich vˇsak pˇren´aˇseny pˇr´ıkazy a jejich v ´ystupy. Podrobnˇeji jsem se jimi nezab ´yval, pro funkˇcnost m´e implementace
ne-jsou potˇreba. Pˇripojen´ı na konzolov´a rozhran´ı s´ıt’ov ´ych prvk ˚u je ve Virtlabu umoˇznˇeno pomoc´ı rozhran´ı v internetov´em prohl´ıˇzeˇci.
5.8 Zm ˇena jm ´ena MU spojen´ı
Zpr´ava pro zmˇenu jm´ena je aplikac´ı PT zasl´ana ihned po ´uspˇeˇsn´em nav´az´an´ı MU spo-jen´ı. Nen´ı nezbytn´a pro funkˇcnost a je sp´ıˇse o informaci pro uˇzivatele. D´ıky nim v´ı i o zmˇen´ach jm´ena vzd´alen´eho konce spojen´ı. Jedn´a o n´azev MU obl´aˇcku. Tento si uˇzivatel m ˚uˇze mˇenit jak chce bˇehem chodu programu, a proto je zde zpr´ava o zmˇenˇe jm´ena.
Tyto zpr´avy mohou b ´yt zas´ıl´any jak serverem tak klientem. Tato zpr´ava m´a n´asleduj´ıc´ı form´at:
6
N ´avrh ˇre ˇsen´ı
Po prozkoum´an´ı vˇsech moˇznost´ı PT API a protokol ˚u, kter´e funguj´ı pˇri propojen´ı mezi dvˇema programy Packet Tracer byly uvaˇzov´any dvˇe moˇzn´e varianty ˇreˇsen´ı.
Prvn´ı variantou by bylo vytvoˇren´ı programu, kter ´y by si spustili uˇzivatel´e Virtlabu pˇr´ımo na stejn´em poˇc´ıtaˇci jako Packet Tracer a tento program by mohl uˇz pak pˇr´ımo komunikovat s Virtlabem, kde by se pro tyto ´uˇcely vytvoˇril dalˇs´ı modul v tunelovac´ım serveru. Toto ˇreˇsen´ı by mˇelo tu v ´yhodu, ˇze z´atˇeˇz ohlednˇe pˇrekladu paket ˚u by byla na stranˇe klienta. Tak´e by bylo moˇzno v´ıce vyuˇz´ıt jiˇz hotov´e k ´ody PT API. Nejsp´ıˇse by se vˇsak h ˚uˇre odstra ˇnovaly probl´emy pˇri spojen´ı t´eto aplikace s Virtlabem. Rovnˇeˇz by nejsp´ıˇse nast´avaly probl´emy s aplikac´ı na poˇc´ıtaˇc´ıch klient ˚u (student ˚u). Tak´e by bylo potˇreba m´ıt tento syst´em schopn ´y provozu na obou podporovan ´ych platform´ach. At’ jiˇz by to bylo doc´ıleno pˇrenositeln ´ym k ´odem v jazyce Java, nebo rozd´ıln ´ymi bin´arn´ımi k ´ody pro obˇe podporovan´e platformy. Je tedy pravdˇepodobn´e, ˇze by se takov´eto ˇreˇsen´ı h ˚uˇre udrˇzovalo a rozˇsiˇrovalo.
Druhou cestou je vyuˇz´ıt vyv´ıjenou aplikaci jako server pro pˇripojov´an´ı klient ˚u s pro-gramem Packet Tracer. Toto ˇreˇsen´ı m´a rozhodnˇe v ´yhodu v tom, ˇze je moˇzno cel ´y syst´em l´epe spravovat a udrˇzovat. Tak´e bude jistˇe snazˇs´ı odstranit chyby aplikace a vyrovnat se s pˇr´ıpadn ´ymi z´asahy do protokolu.
Pro implementaci bylo rozhodnuto, ˇze vyuˇzijeme ˇreˇsen´ı, kdy je serverov´a strana (d´ale jen PTServer) um´ıstˇena na serveru Virtlabu. K tomu n´as vedla pˇredevˇs´ım moˇznost lepˇs´ı spr´avy tohoto ˇreˇsen´ı.
Toto ˇreˇsen´ı umoˇzn´ı pˇripojen´ı klient ˚u, kteˇr´ı jsou v dneˇsn´ım Internetu ˇcasto schov´an´ı za nˇejak ´ym typem NATu a tak´e umoˇzn´ı mnohem lepˇs´ı kontrolu a detekci poruch pˇri pˇr´ıpadn ´ych zmˇen´ach protokolu. D´a se vˇsak oˇcek´avat, ˇze PTMP v nejbliˇzˇs´ı dobˇe ˇz´adn ´ych velk ´ych zmˇen nedozn´a, jelikoˇz poˇzadavky na tento protokol kladen´e pln´ı dobˇre. Co se t ´yˇce protokolu MU a v nˇem pˇren´aˇsen ´ych r´amc ˚u, tak bych tak´e neoˇcek´aval z´asadn´ı zmˇeny (tyto r´amce se snaˇz´ı napodobovat zhruba obsah re´aln ´ych r´amc ˚u). Pravdˇepodobnˇe p ˚ujde v ´yvoj PT stejn ´ym smˇerem jako nyn´ı. To znamen´a, ˇze bude vylepˇsov´ana stabilita cel´e ap-likace a pˇrid´ana podpora pro dalˇs´ı protokoly a pˇr´ıkazy, tak aby rozˇs´ıˇrily moˇznosti tohoto simul´atoru.
Cel´e ˇreˇsen´ı integrace je moˇzno rozdˇelit do dvou komponent. Toto rozdˇelen´ı je im-plementov´ano ´uplnˇe. Kaˇzd´a z komponent je schopna samostatn´eho bˇehu. Pro funkˇcnost implementace jsou vˇsak potˇreba obˇe. Jak jsem uvedl v ´yˇse, komponenta pˇrij´ımaj´ıc´ı a ob-sluhuj´ıc´ı spojen´ı s PT je nazv´ana PTServer. Druhou ˇc´ast, kter´a se star´a o pˇreklad pseu-dor´amc ˚u a r´amc ˚u jsem pojmenoval PTBridge.
Toto oddˇelen´ı je zde proto, aby bylo pˇr´ıpadnˇe moˇzno provozovat je oddˇelenˇe, v pˇr´ıpadˇe, ˇze by se jednalo o velmi zat´ıˇzenou komponentu. Celkov ´y koncept n´avrhu je vidˇet na obr´azku 6. Mezi PTServerm a PTBridgem jsou pos´ıl´any pomoc´ı UDP pouze pseudor´amce rozˇs´ıˇren´e o hlaviˇcku (LH), jej´ı obsah a pr´ace s n´ı je pops´ana v n´asleduj´ıc´ı kapitole, kter´a se zab ´yv´a implementac´ı.
Obr´azek 6: Celkov ´y koncept ˇreˇsen´ı 6.1 PTServer
Jak n´azev t´eto komponenty napov´ıd´a jedn´a se o server, kter ´y obsluhuje pˇr´ıchoz´ı spojen´ı s klientsk ´ymi PT. Autentizuje klienty a celkovˇe jeho prim´arn´ı zamˇeˇren´ı je na PTMP. Jeho pr´ace je tak´e komunikovat s ˇr´ıd´ıc´ım serverem Virtlabu, jelikoˇz od nˇej potˇrebuje z´ıskat informace o uˇzivatel´ıch, kteˇr´ı mohou b ´yt pˇripojeni. S´am ˇr´ıd´ıc´ımu serveru pˇred´av´a infor-mace o link´ach vytvoˇren ´ych v MU spojen´ı. Tato komunikace bude prob´ıhat pomoc´ı pro-tokolu SOAP, kter ´y je jiˇz nyn´ı ve Virtlabu nasazen na komunikaci mezi ˇr´ıd´ıc´ımi servery lokalit. Na z´akladˇe informac´ı o pˇripojen ´ych link´ach vytv´aˇr´ı ˇr´ıd´ıc´ı server potˇrebn´e konek-tory.
Implementaci konektor ˚u realizoval Pavel Burda v r´amci sv´e diplomov´e pr´ace [1]. Umoˇz ˇnuj´ı jejich vz´ajemn´e dynamick´e propojov´an´ı. Pˇres takto propojen´e konektory se pak mohou norm´alnˇe pˇren´aˇset data stejnˇe jako by se jednalo o kabelov´e spojen´ı. Propo-jov´an´ı konektor ˚u je moˇzn´e mˇenit za bˇehu aplikace, ale toto jiˇz zajiˇst’uje obsluˇzn´a logika konektor ˚u.
Tak´e na stranˇe PTServeru funguje SOAP server, kter ´y pˇrij´ım´a informace o propojen´ı konektoru. Pokud je propojen konektor vytvoˇren ´y PTServerem s konektorem pˇridan ´ym v konkr´etn´ı ´uloze je jiˇz moˇzn´e pˇren´aˇset pˇres celou soustavu data.
Kaˇzd´a z lokalit Virtlabu bude provozovat vlastn´ı instanci PTServeru pro sv´e uˇzivatele. 6.2 PTBridge
Aby bylo moˇzno oddˇelit pˇreklad re´aln ´ych r´amc ˚u z Virtlabu na pseudor´amce v PT, je zde samostatn´a komponenta PTBridge. Ta bude zajiˇst’ovat jen vz´ajemn ´y pˇreklad r´amc ˚u. Toto oddˇelen´ı je zde pro pˇr´ıpad, ˇze by se jednalo o vyt´ıˇzenou komponentu. D´ıky vyj-mut´ı z hlavn´ıho programu ji bude moˇzno provozovat napˇr´ıklad na samostatn´em serveru.
Obr´azek 7: Cesta r´amce z re´aln´eho prvku na poˇc´ataˇc s PT
Podobnou ´ulohu pln´ı i aplikace nav´azan´a na PT API zmi ˇnovan´a v kapitole 3.1. N´am vˇsak poslouˇz´ı dobˇre jako odrazov ´y m ˚ustek, a tak´e pro z´akladn´ı pochopen´ı syst´emu jak ´ym jsou pˇren´aˇsen ´y r´amce mezi instancemi PT.
Tato komponenta mus´ı b ´yti stejnˇe jako PTServer spuˇstˇena na kaˇzd´e lokalitˇe.
Na obr´azku 7 je jednoduˇse zakresleno jak r´amec z laboratorn´ıho prvku Virtlabu putuje k poˇc´ıtaˇci, kter ´y m´a spuˇstˇen a pˇripojen PT.
7
Implementace
Pro implementaci cel´e pr´ace jsem pouˇzil jazyk C++. Pro dan ´y ´ukol se nab´ız´ı jako nejlepˇs´ı moˇzn ´y. Jelikoˇz jsme se rozhodli pro ˇreˇsen´ı zaloˇzen´e na PTServeru, kter ´y bude um´ıstˇen v architektuˇre Virtlabu. Servery t´eto laboratoˇre jsou postaveny na operaˇcn´ım syst´emu Linux. Z hlediska v ´ykonu a poˇzadovan´eho nasazen´ı se jazyk C++ jev´ı jako nejlepˇs´ı vari-anta. Prvn´ı verze PTServeru nav´ıc pouˇz´ıvala ˇc´asti zdrojov´eho k ´odu z PT API, kter ´y byl naps´an pr´avˇe v C++, ovˇsem obsahovalo i vazby na knihovny Qt. Souˇcasn´a verze jiˇz tyto vazby neobsahuje a pouˇz´ıv´a ˇc´ast k ´od ˚u z novˇejˇs´ı verze C++ PT API.
Cel´e ˇreˇsen´ı je v podstatˇe oddˇeleno od st´avaj´ıc´ıch komponent distribuovan´e labo-ratoˇre. Toto ˇreˇsen´ı bude nejsp´ıˇse vyuˇzito sp´ıˇse v budoucnu v pˇr´ıpadˇe, ˇze bude doch´azet k vˇetˇs´ımu vyuˇz´ıv´an´ı implementovan´eho ˇreˇsen´ı.
Spojen´ı, kter´e se vytv´aˇr´ı mezi PTServerm a klientem, kter ´y m´a spuˇstˇen PT, je vytv´aˇreno pomoc´ı v ´yˇse popsan´eho protokolu PTMP a MU. Oba funguj´ı nad protokolem TCP/IP. Zde bylo nezbytn´e pouˇz´ıt to, co je pouˇzito k vz´ajemn´emu propojen´ı mezi programy Packet Tracer.
Mezi PTServerem a PTBridgem jiˇz nen´ı potˇreba stavov´e spojen´ı. Zat´ım se poˇc´ıt´a s nasazen´ım na jeden stroj a oddˇelen´ı obou ˇc´asti je zde sp´ıˇse pro moˇznou budoucnost. Je zde tedy pouˇzito UDP spojen´ı. Po tomto jsou jiˇz pˇren´aˇsen ´y jen r´amce obsahuj´ıc´ı hlaviˇcku linky a pseudor´amce. Tato hlaviˇcka je pak pouˇzita i v r´amci zaslan´em tunelovac´ımu serveru, kter ´y se star´a o pˇred´an´ı na patˇriˇcn´e rozhran´ı laboratorn´ıho prvku Virtlabu (z´aleˇz´ı jiˇz na subsyst´emu konektor ˚u). Hlaviˇcka linky (LH) obsahuje IP adresu klienta, ˇc´ıslo TCP portu jeho pˇripojen´ı a ˇc´ıslo linky po kter´e je pseudor´amec pˇren´aˇsen. Napˇr´ıklad tato hlaviˇcka m ˚uˇze vypadat takto ”127.0.0.1:5896@0”. Posledn´ı ˇc´ıslo je pr´avˇe ˇc´ıslo linky. Pˇred t´ımto polem je pˇren´aˇsena jen informace o d´elce dan´e hlaviˇcky (cel´e ˇc´ıslo). Toto jsou veˇsker´e potˇrebn´e informace potˇrebn´e pro spr´avn´e doruˇcen´ı pseudor´amce PT.
PTBridge zajist´ı pˇreklad pseudor´amce na form´at, kter ´y je pouˇz´ıv´an u standardn´ıch r´amc ˚u. Samozˇrejmˇe mus´ı doplnit nezbytn´e parametry, kter´a pseudor´amce postr´adaj´ı.
Proto, aby bylo vˇse funkˇcn´ı, bylo potˇreba prov´est i drobn´e zmˇeny ve st´avaj´ıc´ım ob-sluˇzn´em k ´odu Virtlabu. Ty jsou pops´any v samostatn´e podkapitole.
7.1 PTServer
Komponenta PTServer m´a za prim´arn´ı c´ıl umoˇznit pˇripojen´ı PT klienta. Implementov´an je jako serverov´a ˇc´ast PTMP, takˇze obsluhuje a odes´ıl´a potˇrebn´e zpr´avy. Tato ˇc´ast takt´eˇz komunikuje s ˇr´ıd´ıc´ım serverem Virtlabu. Tato komunikace obsahuje moˇznost z´ıskat pˇrihlaˇsovac´ı
´udaje pro ´uˇcely autentizace a autorizace vzd´alen ´ych PT. Pˇrihlaˇsovac´ımi ´udaji se rozum´ı uˇzivatelsk´e jm´eno a heslo. Heslo je doˇcasnˇe generov´ano pro aktivn´ı ´ulohy.
Pro kaˇzd´e pˇr´ıchoz´ı spojen´ı (pˇripojen´ı klienta) je vytvoˇreno obsluˇzn´e vl´akno. Tud´ıˇz server m ˚uˇze nad´ale obsluhovat dalˇs´ı pˇr´ıchoz´ı spojen´ı. Poˇcet vl´aken tedy odpov´ıd´a poˇctu pˇripojen ´ych klient ˚u. Mezi vl´akny k ˇz´adn´e komunikaci nedoch´az´ı.
PTServer zajiˇst’uje jak jiˇz bylo v ´yˇse naps´ano autentizaci PT klienta. V pˇr´ıpadˇe, ˇze au-tentizace selˇze (uˇzivatel zad´a ˇspatn´e jm´eno nebo heslo) tak je ˇr´ıd´ıc´ımu serveru zasl´ana zpr´ava o ne ´uspˇechu. Pro z´ısk´av´an´ı ´udaj ˚u a pos´ıl´an´ı zpr´av ˇr´ıd´ıc´ımu serveru Virtlabu je
pouˇzito protokolu SOAP. Zpr´ava o neuspˇeˇsn´e autentizaci se uˇzivateli v koncov´em PT nezobraz´ı. Pak je spojen´ı rozpojeno a vl´akno konˇc´ı svou ˇcinnost. V pˇr´ıpadˇe ´uspˇeˇsn´e au-tentizace je nav´az´ano spojen´ı a server m ˚uˇze obsluhovat zpr´avy o link´ach. Po pˇripojen´ı klienta nen´ı ˇz´adn´a linka v MU spojen´ı mezi uˇzivatelem a PTServerm vytvoˇrena. Uˇzivatel nejprve mus´ı ve sv´em PT vytvoˇrit novou. Jakmile tak uˇcin´ı, je o tom informov´an po-moc´ı SOAPu ˇr´ıd´ıc´ı server. Takto vytvoˇrenou linku je pak moˇzno propojit s konektorem v aktivn´ı ´uloze. Pokud je vytvoˇren ´y konektor propojen s konektorem v topologii, je in-formov´an PT, ˇze vzd´alen ´y konec linky je zapojen (aktivn´ı). Z tohoto d ˚uvodu se udrˇzuj´ı informace o obou konc´ıch linky.
Moment´alnˇe jsou podporov´any pouze ethernetov´e linky. Virtlab v souˇcasn´e dobˇe podporuje pouze vzd´alen´e propojov´an´ı pr´avˇe ethernetov ´ych port ˚u. Zpr´avy o link´ach, kter´e nejsou ethernetov´eho typu, jsou ignorov´any.
Psedour´amce jsou pˇren´aˇseny pouze pokud jsou oba konce linky aktivn´ı. Tak je tomu d´ıky PT, kter´a ˇcek´a na aktivaci obou konc ˚u linky. Toto ulehˇc´ı z´atˇeˇzi, kter´a by mohla vzniknout pˇri pˇrekladech vˇsech r´amc ˚u. Pokud dojde ke smaz´an´ı nebo odpojen´ı linky, tak je konektor pˇredstavuj´ıc´ı tuto linku rovnˇeˇz odstranˇen. Pˇri rozpojen´ı jsou odstranˇeny vˇsechny PT konektory dan´eho spojen´ı. Propojov´an´ı pseudo-konektor ˚u (linek zakonˇcen ´ych ve Virtlabu) mezi sebou nen´ı zat´ım dovoleno. Pokud bychom st´ali o to vytvoˇrit server pro pˇripojov´an´ı PT mezi sebou (jak ´ysi proxy server), tak by bylo rozhodnˇe vhodnˇejˇs´ı vynechat komponentu staraj´ıc´ı se o pˇreklad r´amc ˚u.
Pro pˇreklad t´eto aplikace je na c´ılov´em syst´emu potˇreba gSOAP Toolkit [6]. Ten je zde pro podporu komunikace protokolem SOAP s ˇr´ıd´ıc´ım serverem Virtlabu. D´ale je potˇreba knihovnapthread, protoˇze jsou pouˇzita pro implementaci vl´akna. ˇZ´adn´e dalˇs´ı speci´aln´ı poˇzadavky na knihovny PTServer neobsahuje.
V ´ypis vˇsech chyb a syst´em logov´an´ı je pouˇzit dle zavaden´eho standardu v syst´emu Virtlab. Pro tyto ´uˇcely jsem pˇrevzal tˇr´ıdu z bakal´aˇrsk´e pr´ace V´aclava Bortl´ıka [7].
7.2 Popis tˇr´ıd PTServeru
Nyn´ı kr´atce pop´ıˇsi vˇsechny d ˚uleˇzit´e tˇr´ıdy, kter´e se nach´azej´ı ve zdrojov ´ych k ´odech PT-Serveru.
PTServer– prim´arn´ı tˇr´ıda, kter´a naslouch´a na nakonfigurovan ´ych portech. Pˇr´ıchoz´ı klientsk´e spojen´ı pˇred´av´a d´ale tˇr´ıdˇePTConnection. Sama obsahuje metody pro komu-nikaci s PTBridgem. V samostatn´em vl´aknˇe spouˇst´ı SOAP server obsaˇzen ´y v tˇr´ıdeSoapServer.
PTConnection– tˇr´ıda zajiˇstuje komunikaci s PT klientem. Obsahuje vˇse potˇrebn´e pro provoz a obsluhu PTMP a MU spojen´ı. Pouˇz´ıv´a tˇr´ıduSoapClientpro SOAP komunikaci s ˇr´ıd´ıc´ım serverem Virtlabu.
PTMPMessage– obsahuje logiku pro zpracov´an´ı PTMP a MU zpr´av. Jednotliv´e zpr´avy pak dˇed´ı tuto z´akladn´ı, tˇr´ıdu ale jsou um´ıstˇeny ve vlastn´ıch souborech.
Messages– souˇc´ast´ı je implementace logov´an´ı dle pravidel Virtlabu. Tuto tˇr´ıdu jsem pˇrevzal z jiˇz beˇz´ıc´ıho syst´emu tunelovac´ıho serveru.
MD5– tˇr´ıda pˇrevzata z C++ API. Obsahuje implementaci MD5 haˇsovac´ıho algoritmu.
MULinks– implementace tabulky linek. Obsahuje metody pro pr´aci s touto tabulkou. Skladuje informace ve vektoru, kter´a obsahuje objektyMULink.
PTBuffer– buffer pouˇzit ´y pro pr´aci se zpr´avami a r´amci. Nezbytn´a pro PTMP. Ob-sahuje i pr´aci se z´akladn´ımi PTMP datov ´ymi typy.
Vˇsechny tˇr´ıdy jsou logicky rozdˇeleny do sloˇzek. Sloˇzka PTMP obsahuje napˇr´ıklad vˇsechny PTMP zpr´avy, jejich zpracov´ani a tak´e obsluˇzn´e tˇr´ıdy. Sloˇzka MU obsahuje zpr´avy protokolu MU. Ve sloˇzce soap se nach´az´ı implementace SOAP funkc´ı a rovnˇeˇz vˇsechny soubory generovan´e gSOAPem. Ve sloˇzce zlib je pak kompresn´ı knihovna zlib. Sloˇzka crypto obsahuje tˇr´ıduMD5.
Pro lepˇs´ı pochopen´ı propojen´ı tˇechto tˇr´ıd jsem vytvoˇril jednoduch ´y sekvenˇcn´ı dia-gram 8. Na nˇem je vˇsak pouze obecn´e propojen´ı, nejedn´a se o nˇejakou z konkr´etn´ıch ˇcinnost´ı.
7.2.1 Konfigurace PTServeru
Pro to, aby bylo moˇzn´e mˇenit d ˚uleˇzit´e parametry je zde konfiguraˇcn´ı soubor. Jeho form´at je pomˇernˇe jednoduch ´y a pˇr´ıklad lze vidˇet na v ´ypise 2. Mezi parametry a hodnotami je mezera. Je moˇzn´e do tohoto souboru vkl´adat koment´aˇre uvozen´e znakem mˇr´ıˇzky – ”#”. ˇR´adky zaˇc´ınaj´ıc´ı t´ımto znakem jsou ignorov´any. Jednotliv´e parametry pak mus´ı b ´yt oddˇeleny ukonˇcen´ım ˇr´adku.
# Tyto parametry jsou pouzity pro poslani pseudoramce PTBridge # Port na kterem PTBridge nasloucha komunikaci od PTServeru PTBridge−port 38100
# IP adresa nebo jmno hostitele pro PTBridge PTBridge−ip localhost
########################################################################## # Tyto parametry jsou pouzity pro prijem pseudoramcu z PTBridge
# IP adresa nebo jmno hostitele pro pjem dat PTServer−ip 127.0.0.1
# Port pro pjem pseudoramcu PTServer−port 38101
########################################################################## # Udaje pro prichozi spojeni od PT
# IP adresa nebo jmno hostitele Listen−ip 127.0.0.1
# Port na kterem je naslouchano (toto je vychozi nastaveni pro MU spojeni) Listen−port 38000
########################################################################## # Parametry pro SOAP komunikaci mezi ridicim serverem a PTServerem
# Port na kterm nasloucha SOAP server na strane PTServeru PTSsoap−port 8080
# Cilove misto SOAPu na Virtlabu
VtSoap−location http://localhost /soapserver.php
V ´ypis 2: Uk´azka konfiguraˇcn´ıho souboru pro PTServer
Um´ıstˇen´ı tohoto konfiguraˇcn´ıho souboru je moˇzno urˇcit v hlaviˇckov´em souboru. Je tedy nezbytn´e, aby bylo zn´amo jiˇz v dobˇe kompilace.
Obr ´azek 8: Jednoduch ´y sekven ˇcn ´ı diagram PTServer u
Nˇekolik parametr ˚u je vˇsak moˇzno nastavit i pˇri spuˇstˇen´ı programu. Pro v ´ypis tˇechto parametr ˚u staˇc´ı spustit program s parametrem -h. Ten zajist´ı v ´ypis vˇsech dostupn ´ych parametr ˚u.
7.3 PTBridge
Tato ˇc´ast je kl´ıˇcov´a pro vz´ajemn ´y pˇreklad r´amc ˚u. Je nezbytn´e pˇrekl´adat pseudor´amce, kter´e jsou pos´ıl´any z PTServeru na re´aln´e r´amce. Ty jsou pak pos´ıl´any rovnˇeˇz pomoc´ı pro-tokolu UDP tunelovac´ımu serveru. Pˇri obou tˇechto pˇrenosech je pouˇzita hlaviˇcka linky (LH), kter´a nen´ı PTBridgem nijak mˇenˇena ani na ni nen´ı pohl´ıˇzeno.
M´a implementace funguje jako jeden proces, kter ´y obsluhuje obˇe tato spojen´ı. Nen´ı zde potˇreba udrˇzovat TCP spojen´ı jelikoˇz je potˇreba maxim´alnˇe urychlit vz´ajemn´e pˇrenosy. Kaˇzd ´y pˇrijat ´y r´amec je zpracov´an k tomu vytvoˇrenou funkc´ı. Souˇcasn´a verze zvl´ad´a pˇrev´adˇet r´amce protokol ˚u CDP, RIP, ARP a ICMP. U protokolu ICMP vˇsak funguj´ı jen echo zpr´avy. Jin´e nejsou v programu PT podporov´any.
Pro lepˇs´ı moˇznost testov´an´ı a v ´yvoje pˇrekladov ´ych funkc´ı je moˇzno spustit PTBridge v m ´odu, ve kter´em odes´ıl´a vˇsechny r´amce na vybran´e s´ıt’ov´e rozhran´ı (podporov´any jsou jen ethernetov´e s´ıt’ov´e karty). Takt´eˇz na nastaven´em rozhran´ı naslouch´a provozu a ten pak pˇred´av´a pro zpracov´an´ı. Po pˇrepracov´an´ı r´amce na pseudor´amec je odesl´an d´ale na PTServer. Pro tuto funkˇcnost je vyuˇzito knihovny pcap [14], kter´a je zn´ama z pro-gram ˚u pro zachyt´av´an´ı a anal ´yzu s´ıt’ov´eho provozu. Zachyt´av´an´ı r´amc ˚u na s´ıt’ov´e kartˇe se v tomto pˇr´ıpadˇe spouˇst´ı v samostatn´em vl´aknˇe. Pro tuto funkˇcnost je nutn´e spouˇstˇet aplikaci s pr´avy superuˇzivatele. Pro spuˇstˇen´ı tohoto reˇzimu je nutno zadat parametr-i=, za kter ´ym n´asleduje ˇc´ıslo s´ıt’ov´eho rozhran´ı. ˇC´ısla rozhran´ı se vyp´ıˇsou v pˇr´ıpadˇe, ˇze je program spuˇstˇen s pr´avy superuˇzivatele.
Pro kaˇzd ´y protokol a smˇer je v t´eto implementaci vlastn´ı pˇrekladov´a funkce. Bohuˇzel se mi zat´ım nepodaˇrilo z´ıskat ˇz´adn´e lepˇs´ı ´udaje o tom jak, jsou pseudor´amce tvoˇreny. Zachoval jsem tedy syst´em, kter ´y je pouˇzit rovnˇeˇz u PtBridge 3.1. Pˇredpokl´ad´am vˇsak, ˇze po tom co se podaˇr´ı z´ıskat od v ´yvoj´aˇr ˚u PT k tvoˇren´ı pseudor´amc ˚u sl´ıbenou pomoc, bude moci b ´yt tento pˇrekladov ´y syst´em pˇredˇel´an.
Pro anal ´yzu pr´ace v ´yˇse popsan ´ych protokol ˚u a tak´e pak n´aslednou kontrolu pr´ace pˇrekl´adac´ı pr´ace PTBridge se velmi osvˇedˇcil n´astroj pro anal ´yzu s´ıtov´eho provozu Wire-shark [15] (dˇr´ıve Ethereal). Umoˇz ˇnuje jak zachyt´av´an´ı tak i anal ´yzu r´amc ˚u a tak´e zo-brazuje obsah r´amce v ˇsestn´actkov´e soustavˇe. Toto je velmi uˇziteˇcn´e pˇri zkoum´an´ı ob-sahu zpr´av protokol ˚u PTMP a MU.
Tak´e PTBridge pouˇz´ıv´a syst´em logov´an´ı a v ´ypis ˚u, kter ´y jsem jiˇz popsal v podkapitole zab ´yvaj´ıc´ı se implementac´ı PTServeru.
7.4 Popis tˇr´ıd PTBridge
Tato ˇc´ast obsahuje stejnou tˇr´ıdu pro logov´an´ı a v ´ypisy jako PTServer. D´ale je zde i tˇr´ıda
PTBufferpopisovan´a v ˇc´asti PTSertveru, je zde ponˇekud zjednoduˇsena.
PTBridge – prim´arn´ı tˇr´ıda, kter´a naslouch´a na nastaven ´ych portech a zajiˇst’uje ko-munikaci jak s PTServerm tak s tunelovac´ım serverem. V samostatn´em vl´aknˇe pˇr´ıpadnˇe
Obr´azek 9: Jednoduch ´y sekvenˇcn´ı diagram PTBridge
spouˇst´ı pˇr´ıpadn´e zachyt´av´an´ı a odes´ıl´an´ı provozu pomoc´ı knihovny pcap. Pˇred´av´a rovnˇeˇz pˇrijat ´y provoz patˇriˇcn ´ym metod´am tˇr´ıd, kter´e zpracov´avaj´ı dan´e r´amce.
Je zde pak jeˇstˇe sloˇzka PDU s tˇr´ıdami, kter´e obsahuj´ı metody pro pˇrevod konkr´etn´ıho r´amce.
Na sekvenˇcn´ım diagramu 9 je postup, kter ´y se pouˇzije pˇri pˇr´ıjmu pseudor´amce ICMP. Ten je po pˇrepracov´an´ı odesl´an opˇet za pomoc´ı metody PTBridge. Z´aleˇz´ı na zp ˚usobu spuˇstˇen´ı, kam bude r´amec doruˇcen. Vˇsechny ostatn´ı pˇreklady prob´ıhaj´ı podobn ´ym zp ˚usobem. 7.4.1 Konfigurace PTBridge
I pro komponentu PTBridge je pouˇzito konfiguraˇcn´ıho souboru, kter ´y obsahuje vˇsechny nezbytn´e parametry. Form´at souboru mus´ı spl ˇnovat stejn´e pˇredpoklady jako v pˇr´ıpadˇe PTServeru. Uk´azkov ´y v ´ypis t´eto konfigurace je vidˇet na v ´ypise 3.
# Port, na kterem se nasloucha pro prenosy z PTServeru PTBridge−port 38100
# IP adresa nebo jmeno hostitele pro naslouchani PTBridge−ip localhost
########################################################################## # IP adresa nebo jmeno hostitele PTServeru (pro komunikaci s PTBridgem)
PTServer−ip 127.0.0.1 # port PTServeru PTServer−port 38101
# IP adresa nebo jmno hostitele s tunelovacim serverem Tunserver−ip 127.0.0.1
# port tunelovacho serveru Tunserver−port 40002
########################################################################## # Port pro naslouchani prenosu z Tunelovaciho serveru
PTBtunnel−port 40101
# IP adresa nebo jmeno hostitele pro naslouchani PTBtunnel−ip localhost
V ´ypis 3: Uk´azka konfiguraˇcn´ıho souboru pro PTBridge
Rovnˇeˇz zde je parametr -h, kter ´y na vyp´ıˇse vˇsechny parametry, se kter ´ymi lze PT-Bridge spustit. Nen´ı zde ˇz´adn ´y povinn ´y parametr.
7.5 Upravy Virtlabu´
Pro potˇreby tohoto ˇreˇsen´ı bylo potˇreba upravit i nˇekolik k ´od ˚u. Tˇechto ´uprav vˇsak nebylo potˇreba mnoho d´ıky solidn´ımu stavu projektu Virtlab. Ten je dobˇre pˇripraven na pˇr´ıpadn´e rozˇsiˇrov´an´ı.
V datab´azi ˇr´ıd´ıc´ıho serveru jsem vytvoˇril tabulku pro uchov´an´ı informac´ı i PT link´ach. V t´eto tabulce jsou uchov´av´any informace o IP adrese a portu klienta. Tato informace slouˇz´ı k unik´atn´ı identifikaci klienta. D´ale jsou v t´eto tabulce uloˇzeny informace o UUID linky, jm´eno konce linky v PT (obvykle jakojmeno prvku jmeno rozhrani), stav vzd´alen´eho portu (aktivn´ı/neaktivn´ı) a typ portu.
Do tabulkyreservationsjsem pˇridal sloupecotp. Tento slouˇz´ı pro uloˇzen´ı generovan´eho hesla, kter´e se pouˇzije pˇri autentizaci PT. Toto pole je vypl ˇnov´ano pˇri aktivaci rezer-vace. Pro tyto ´uˇcely jsem pˇridal do souborumake-reservation.phpfunkci 4, kter´a toto heslo generuje. Funkci vol´am s parametremlengthnastaven ´ym na 8. Pro potˇreby autentizace PT se mi jev´ı takto dlouh´e heslo jako dostateˇcn´e.
function generatePassword($length=9) { srand(makeSeed()); $alfa = ’ 1234567890qwertyuiopasdfghjklzxcvbnmQWERTYUIOPASDFGHJKLZXCVBNM’; $token = ’ ’ ; for( $i = 0; $i <$length; $i ++) {
$token .= $alfa [rand(0,strlen( $alfa ) ) ];
}
return $token;
}
V ´ypis 4: Funkce pro generov´an´ı n´ahodn´eho hesla
Toto heslo je vˇsak nutno uchov´avat v tomto ˇcistˇe textov´em form´atu a stejnˇe jej i pˇred´avat pomoc´ı SOAPu do aplikace PTServer. Zde je teprve s heslem pracov´ano dle vyjednan´e metody autentizace.
Proto komunikaci s ˇr´ıd´ıc´ım serverem je jak jsem jiˇz psal pouˇzito gSOAPu. Aby vˇsak vˇse ˇr´adnˇe fungovalo, vytvoˇril jsem pro tuto komunikaci soubory WSDL. Tyto pomoc´ı jazyka XML popisuj´ı dostupn´e sluˇzby SOAP serveru a tak´e form´at komunikaˇcn´ıch zpr´av. Jelikoˇz se chyst´a nov´a implementace ˇr´ıd´ıc´ıho serveru, tak jsem prozat´ım vytvoˇril vlastn´ı PHP skript obsahuj´ıc´ı jen sluˇzby, kter´e potˇrebuji. Tento skript pouˇz´ıv´a form´at zpr´av defi-novan ´y souborem WSDL. Na stranˇe ˇr´ıd´ıc´ıho serveru je pouˇzito SOAP prostˇredk ˚u, kter´e jsou zabudov´any v prostˇred´ı PHP [17].
Propojen´ı mezi PTBridgem a tunelovac´ım serverem jsem p ˚uvodnˇe chtˇel udˇelat jako v pˇr´ıpadˇe pˇripojen´ı vzd´alen´eho poˇc´ıtaˇce do topologie Virtlabu [18]. Radˇeji vˇsak neˇz zasa-hovat do modulu internetov´eho portu tunelovac´ıho serveru, jsem vytvoˇril vlastn´ı modul pro komunikaci s PTBridgem.
Tento modul je postaven na jiˇz hotov ´ych modulech. Naslouch´a na sv´em vlastn´ım UDP portu a pˇred´av´a r´amce obdrˇzen´ı z tohoto portu d´ale do pˇrep´ınac´ıho j´adra tunelo-vac´ıho serveru. Rovnˇeˇz pos´ıl´a r´amce, kter´e obdrˇz´ı od pˇrep´ınac´ıho j´adra pomoc´ı UDP soketu na dalˇs´ı zpracov´an´ı do PTBridge. Tento modul dˇed´ı tˇr´ıdu Port internal. Naˇc´ıt´a rovnˇeˇz konfiguraci, kter´a obsahuje IP adresu a port, na kter´em m´a naslouchat a tak´e in-formace kde naslouch´a PTBridge.
Aby si uˇzivatel mohl propojit konektor s pseudokonektorem (PT linkou) je potˇreba poupravit funkci ˇr´ıd´ıc´ıho serveru, kter´a uˇzivateli vypisuje pouˇziteln´e konektory. Je potˇreba tak´e pˇridat do k ´odu, kter ´y zajiˇst’uje propojen´ı konektor ˚u aby odeslal SOAP zpr´avu PT-Serveru. Tato zpr´ava obsahuje pr´avˇe hlaviˇcku linky a dle n´ı se zaˇsle patˇriˇcn´emu klientovi informace o aktivaci linky.
8
Z ´av ˇer
Zaˇc´atky v ´yvoje tohoto ˇreˇsen´ı byly pro mˇe dosti obt´ıˇzn´e, jelikoˇz jsem nemˇel mnoho in-formac´ı o protokolech pouˇzit ´ych pˇri spojen´ı dvou PT. Nav´ıc prvn´ı verze, ve kter´e jsem pouˇz´ıval API z´avisl´e na Qt, jsem ˇreˇsil mnoho probl´em ˚u pr´avˇe s Qt framewokem. Nemˇel jsem s n´ım v ˚ubec ˇz´adn´e zkuˇsenosti a tak jsem mˇel prvn´ı funkˇcn´ı v ´ysledky t´eto pr´ace aˇz po velmi dlouh´e dobˇe. Z tohoto d ˚uvodu jsem se rozhodl pokus ˚u s t´ımto ˇreˇsen´ım zanechat a pˇrepracovat vˇse do k ´odu pouˇz´ıvaj´ıc´ı jen C++.
Bohuˇzel jsem doted’ nemˇel zkuˇsenosti s v ´yvojem takto velk´eho projektu ani v jazyce C++. Rozhodnˇe mi tato pr´ace pˇrinesla detailn´ı pochopen´ı pouˇzit ´ych protokol ˚u, at’ tˇech pouˇzit ´ych v PT nebo tˇech, kter´e jsou pˇren´aˇseny v re´aln´e s´ıti. Tak´e pouˇzit´ı gSOAP toolkitu si vyˇz´adalo dosti ˇcasu, ale tyto znalosti jistˇe vyuˇziji i v budoucnosti.
Snaˇzil jsem se vˇsak cel ´y syst´em navrhnout tak aby se dal snadno upravovat a rozˇsiˇrovat. Jen ˇc´ast pro pˇrevod r´amc ˚u v PTBridge je zat´ım provedena pomoc´ı metod, kter´a prov´ad´ı cel ´y tento pˇreklad. Nechtˇel jsem zat´ım prov´adˇet n´avrh jin´eho syst´emu, jelikoˇz jsem st´ale ˇcekal na k ´od od v ´yvoj´aˇr ˚u PT. Ten by mohl pomoci vhodn´emu n´avrhu objektov´e struktury pro pˇrevod r´amc ˚u.
D´ale mˇe pˇri dokonˇcov´an´ı tohoto textu napadlo jak vhodnˇe pouˇz´ıt PTMP zpr´avy Port Info pro lepˇs´ı uˇzivatelskou pˇr´ıvˇetivost cel´eho ˇreˇsen´ı. Bohuˇzel jsem je vˇsak zat´ım nestaˇcil pˇridat do k ´odu aplikace. Toto rozˇs´ıˇren´ı bude souˇc´ast´ı dalˇs´ıho dopracov´an´ı program ˚u, kter´e m´am v pl´anu nad r´amec t´eto diplomov´e pr´ace.
Rovnˇeˇz bych r´ad pˇridal pˇrekladov´e funkce do programu PtBridge 3.1 a rozˇs´ıˇril t´ım jeho moˇznosti.
Pevnˇe douf´am, ˇze se tento projekt bude d´ale rozv´ıjet. Mysl´ım, ˇze se jedn´a o zaj´ımavou problematiku, kter´a m ˚uˇze napomoci pr´avˇe praktick´e v ´yuce poˇc´ıtaˇcov ´ych s´ıt´ı. Zaj´ımav ´ym rozˇs´ıˇren´ım by mohlo b ´yt tˇreba pr´avˇe vyvinut´ı serverov´eho ˇreˇsen´ı, kter´e by umoˇznilo komunikaci mezi mnoha simul´atory Packet Tracer.
