}w !"#$%&'()+,-./012345
MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
DHCP server s podporou databa´ze a SNMP BAKALA´RˇSKA´ PRA´CE
Va´clav Sˇlajs
Brno, jaro 2006
Prohla´sˇenı´ Prohlasˇuji, zˇe tato bakala´rˇska´ pra´ce je my´m pu˚vodnı´m autorsky´m dı´lem, ktere´ jsem vypracoval samostatneˇ. Vsˇechny zdroje, prameny a literaturu, ktere´ jsem prˇi vypracova´nı´ pouzˇ´ıval nebo z nich cˇerpal, v pra´ci rˇa´dneˇ cituji s uvedenı´m u´plne´ho odkazu na prˇ´ıslusˇny´ zdroj.
Vedoucı´ pra´ce: Mgr. Michal Batko ii
Podeˇkova´nı´ Tı´mto bych chteˇl podeˇkovat sve´mu vedoucı´mu projektu, Mgr. Michalu Batkovi, za pomoc a vedenı´ prˇi tvorbeˇ tohoto bakala´rˇske´ho projektu. Da´le bych ra´d podeˇkoval spolecˇnosti Google, Inc., ktera´ mi pravidelneˇ poma´hala rˇesˇit vsˇechny proble´my, ktere´ se beˇhem psanı´ pra´ce vyskytly.
iii
Shrnutı´ Cı´lem pra´ce bylo vytvorˇit implementaci DHCP serveru podle specifikace RFC 2131. Jako rozsˇ´ırˇenı´ oproti standartnı´m, beˇzˇneˇ pouzˇ´ıvany´m DHCP serveru˚m je prˇida´na podpora ukla´da´nı´ dat o prˇideˇleny´ch adresa´ch do databa´ze a podpora na dotazova´nı´ aktivnı´ch prvku˚ v sı´tı´ prˇes protokol SNMP o tom odkud pozˇadavek na adresu prˇisˇel.
iv
Klı´cˇova´ slova DHCP, C, Linux, SNMP, PostgreSQL
v
Obsah 1 2
3
4
5
6
´ vod . . . . . . . . . . . . . . . . . . U Popis DHCP protokolu . . . . . . . 2.1 Popis protokolu . . . . . . . . . . 2.2 Popis paketu . . . . . . . . . . . . 2.3 Popis komunikace . . . . . . . . . Analy´za . . . . . . . . . . . . . . . . 3.1 Pozˇadavky . . . . . . . . . . . . . 3.2 Na´vrh rˇesˇenı´ . . . . . . . . . . . Pouzˇita´ IT . . . . . . . . . . . . . . . 4.1 Jazyk C . . . . . . . . . . . . . . 4.2 Protokol SNMP . . . . . . . . . . 4.3 Databa´ze PostgreSQL . . . . . . . 4.4 Dalsˇ´ı knihovny . . . . . . . . . . Popis implementace . . . . . . . . . 5.1 Pouzˇity´ DHCP server . . . . . . . 5.2 Struktura databa´ze . . . . . . . . 5.3 Popis hlavnı´ cˇa´sti programu . . . 5.3.1 Nacˇtenı´ paketu . . . . . 5.3.2 Zjisˇteˇnı´ typu zpra´vy . . DISCOVER . . . . . . . REQUEST . . . . . . . . DECLINE . . . . . . . . 5.3.3 SNMP dotaz . . . . . . . 5.3.4 Vy´beˇr adresy z databa´ze 5.3.5 Kontrola v databa´zi . . . ACK . . . . . . . . . . . NAK . . . . . . . . . . . 5.3.6 Zrusˇenı´ v databa´zi . . . 5.3.7 Odesla´nı´ paketu . . . . 5.4 Inicializace prostrˇedı´ . . . . . . . 5.5 Obsluha signa´lu˚ . . . . . . . . . . Za´veˇr . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 5 5 6 7 10 10 11 13 13 14 14 14 15 15 15 16 17 19 19 19 19 19 20 21 21 21 22 22 22 23 24 1
A Instalace . . . . . . . . . A.1 Prˇ´ıprava knihoven . A.2 Prˇ´ıprava databa´ze . . A.3 Vlastnı´ instalace . . A.4 Konfigurace . . . . . A.5 Spusˇteˇnı´ . . . . . . . B Popis konfigurace . . . . C Obsah CDROM prˇı´lohy
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
. . . . . . . .
28 28 28 28 29 29 30 32
2
Kapitola 1
´ vod U V soucˇasne´ dobeˇ, kdy se rozvı´jı´ informacˇnı´ technologie a vyuzˇ´ıva´ se sta´le vı´ce pocˇ´ıtacˇu˚, je nutne´ je neˇjaky´m efektivnı´m zpu˚sobem propojit. Tı´m na´m vznikajı´ rozsa´hle´ pocˇ´ıtacˇove´ sı´teˇ, prˇi jejichzˇ spra´veˇ jizˇ nestacˇ´ı pouhy´ seznam pocˇ´ıtacˇu˚ na papı´rˇe s prˇideˇleny´mi adresami. Tı´m spı´sˇe, pokud se do sı´teˇ prˇipojujı´ cizı´ pocˇ´ıtacˇe, ktery´m je nutne´ sdeˇlit nastavenı´ a prˇideˇlit jim neˇjakou adresu. Za tı´mto u´cˇelem vznikl protokol DHCP (Dynamic Host Configuration Protocol), ktery´ vycha´zı´ ze starsˇ´ıho BOOTP (Bootstrap Protocol). Tento protokol umozˇnˇuje dynamicky prˇideˇlovat pocˇ´ıtacˇu˚m nastavenı´ sı´teˇ a jim prˇideˇlenou adresu. Ve sve´m zameˇstna´nı´, kde jsem meˇl za u´kol nasadit v praxi neˇjaky´ DHCP server, jsem vyzkousˇel vı´ce implementacı´ DHCP protokolu. Bohuzˇel ani jeden z nich nesplnˇoval me´ pozˇadavky. Vzhledem ke strukturˇe sı´teˇ jsem potrˇeboval zjisˇt’ovat z aktivnı´ch prvku˚ sı´teˇ odkud pozˇadavek na adresu prˇisˇel, abych byl schopen odpoveˇdeˇt spra´vny´m nastavenı´m, ktere´ se lisˇ´ı pro ru˚zne´ segmenty sı´teˇ. K tomu jsem pouzˇil rozsˇ´ırˇeny´ protokol SNMP, ktery´ se beˇzˇneˇ pouzˇ´ıva´ na monitorova´nı´ sı´teˇ. Da´le bylo potrˇeba informace o prˇideˇleny´ch adresa´ch pouzˇ´ıt v navazujı´cı´ch syste´mech. Veˇtsˇina dostupny´ch DHCP serveru˚ si tyto informace ukla´dala do sve´ho externı´ho souboru. Takto ulozˇena´ data jsou ale obtı´zˇneˇ zprˇ´ıstupnitelna´ pro dalsˇ´ı zpracova´nı´, obzvla´sˇteˇ, pouzˇ´ıva´-li se v syste´mu vı´ce DHCP serveru˚ a je nutne´ pracovat s daty od vsˇech. Proto jsem zvolil jako vhodne´ rˇesˇenı´ ukla´da´nı´ teˇchto dat do databa´ze, ktera´ se da´ na´sledneˇ synchronizovat do neˇjake´ centra´lnı´, kde je pak prˇ´ıstup k datu˚m ze vsˇech serveru˚. Tento zpu˚sob je sice cˇasoveˇ na´rocˇneˇjsˇ´ı, ale ve vy´sledku se uka´zal jako efektivneˇjsˇ´ı. Z teˇchto du˚vodu˚ jsem se rozhodl implementovat vlastnı´ DHCP server s vlastnostmi, ktere´ jsem popsal. Pu˚vodnı´ implementace byla v jazyce Java, z du˚vodu jejı´ snadne´ prˇenositelnosti a oproti jazyku C rychlejsˇ´ımu vy´voji. Tento krok se ale pozdeˇji uka´zal jako neprˇ´ılisˇ spra´vny´, jelikozˇ jazyk Java nenı´ prˇ´ılisˇ vhodny´ pro tento typ aplikacı´, naprˇ´ıklad kvu˚li rychlosti. Proto jsem se rozhodl o novou implementaci v jazyce C. Jelikozˇ dnes ma´me spoustu 3
´ VOD 1. U kvalitnı´ho volneˇ sˇirˇitelne´ho softwaru, nemusel jsem vsˇe psa´t od za´kladu˚, ale vyuzˇil jsem jizˇ hotove´ implemente DHCP serveru, upravil ji k my´m potrˇeba´m a prˇidal potrˇebne´ vlastnosti. Dovolte mi, abych Va´s v tomto dokumentu blı´zˇe sezna´mil s tı´mto projektem a s problematikou, ktera´ je s nı´m spojena.
4
Kapitola 2
Popis DHCP protokolu 2.1
Popis protokolu
DHCP protokol je popsa´n v RFC 2131 [?]. Vycha´zı´ a rozsˇirˇuje protokol BOOTP popsany´ v RFC 951 [3]. Jeho vyuzˇitı´ je v poskytova´nı´ konfigurace sı´teˇ klientu˚, kterˇ´ı se do nı´ prˇipojujı´. DHCP se skla´da´ ze dvou cˇa´stı´ •
protokol na prˇena´sˇenı´ dat po sı´ti mezi klientem a serverem
•
mechanizmus pro prˇideˇlova´nı´ IP adres
Popis protokolu je uveden v na´sledujı´cı´ch kapitola´ch. Mechanizmus prˇideˇlova´nı´ adres se deˇlı´ na trˇi zpu˚soby: •
automaticke´ prˇideˇlenı´
•
dynamicke´ prˇideˇlenı´
•
manua´lnı´ prˇideˇlenı´
Automaticke´ prˇideˇlenı´ IP adresy znamena´, zˇe server prˇi pozˇadavku klienta o adresu vybere neˇkterou volnou a tu mu prˇideˇlı´. Toto prˇideˇlenı´ je trvale´ a v budoucnosti tento klient dostane pokazˇde´ stejnou adresu. To ma´ nevy´hodu pokud se klienti prˇipojujı´ do sı´teˇ jen prˇechodneˇ, nebot’ pak zu˚stane obsazena´ IP adresa, ktera´ se uzˇ nikomu neprˇideˇlı´ a mu˚zˇe tak dojı´t k vycˇerpa´nı´ volny´ch adres. Vy´hodou je, pokud klienti potrˇebujı´ komunikovat mezi sebou, majı´ porˇa´d stejnou IP adresu a nemusı´ se prˇi kazˇde´ konexi zjisˇt’ovat aktua´lnı´ adresa. Prˇi dynamicke´m prˇideˇlova´nı´ server prˇideˇlı´ klientovi IP adresu pouze na omezenou dobu. Pokud v te´to dobeˇ klient znova pozˇa´da´ o IP adresu, je mu prˇideˇlena stejna´. Po uplynutı´ te´to doby s nı´ ale server zacha´zı´ jako s volnou adresou a mu˚zˇe jı´ prˇideˇlit neˇkomu jine´mu. Tento zpu˚sob ma´ opacˇne´ klady a za´pory oproti automaticke´mu prˇideˇlova´nı´. Chra´nı´ se proti vycˇerpa´nı´ volny´ch IP adres v du˚sledku jejich trvale´ho prˇideˇlenı´. Pokud klienti potrˇebujı´ 5
2. POPIS DHCP PROTOKOLU mezi sebou komunikovat, musı´ si vzˇdy nejprve zjistit IP adresu druhe´ho klienta.. Manua´lnı´ prˇipojenı´ znamena´, zˇe administra´tor sı´teˇ prˇideˇlı´ klientu˚m na za´kladeˇ jejich MAC adres pevne´ IP adresy a DHCP server slouzˇ´ı pouze k distribuci tohoto nastavenı´. Rozlozˇenı´ IP adres v sı´ti mezi klienty je tedy pevneˇ dane´ a pokud se do sı´teˇ prˇihla´sı´ novy´ klient, musı´ administra´tor sı´teˇ nastavit na DHCP serveru jeho nastavenı´. Tento mechanizmus se mu˚zˇe vhodneˇ kombinovat s dynamicky´m prˇideˇlova´nı´m, kdy administra´tor sı´teˇ prˇideˇlı´ sta´ly´m pocˇ´ıtacˇu˚m pevne´ IP adresy, ale pokud se do sı´teˇ prˇipojı´ neˇkdo novy´, automaticky dostane na neˇjaky´ cˇas prˇideˇlenou volnou IP adresu. Cı´l DHCP protokolu je v co mozˇna´ nejjednodusˇsˇ´ım nastavenı´ sı´teˇ, jak pro administra´tora, tak pro uzˇivatele. Administra´torovi sı´teˇ DHCP umozˇnˇuje, aby mohl klientu˚m jednodusˇe distribuovat nastavenı´ sı´teˇ. Mu˚zˇe jim prˇideˇlovat jednotliveˇ IP adresy nebo to nechat na DHCP serveru a pouze urcˇit rozsah adres, ze ktery´ch bude vybı´rat. Z hlediska uzˇivatele je zapojenı´ pocˇ´ıtacˇe do sı´teˇ trivia´lnı´ za´lezˇitost, protozˇe se nemusı´ starat o zˇa´dne´ nastavenı´, pouze prˇipojit pocˇ´ıtacˇ do sı´teˇ a zapnout. Pokud vsˇe funguje jak ma´, tak se zbytek provede automaticky a beˇhem chvı´le je schopen komunikovat po loka´lnı´ sı´ti.
2.2
Popis paketu
V na´sledujı´cı´ tabulce je zna´zorneˇn DHCP paket a rozmı´steˇnı´ a velikost informacı´ v neˇm ulozˇeny´ch. op (1b)
htype (1b) hlen (1b) hops (1b) xid (4b) secs (2b) flags (2b) ciaddr (4b) yiaddr (4b) siaddr (4b) giaddr (4b) sname (64b) chaddr (16b) file (64b) options (variable)
Popis jednotlivy´ch hodnot op – typ zpra´vy - pozˇadavek/odpoveˇd’ 6
2. POPIS DHCP PROTOKOLU htype – typ hardwarove´ adresy hlen – de´lka hardwarove´ adresy hops – pocˇet paketu˚, prˇes ktere´ paket prosˇel xid – id probı´hajı´cı´ transakce secs – pocˇet sekund od zacˇa´tku transakce (vyplnˇuje klient) flags – prˇ´ıznaky paletu ciaddr – IP adresa klienta yiaddr – pozˇadovana´ IP adresa klienta siaddr – IP adresa dalsˇ´ıho serveru giaddr – adresa relay serveru chaddr – hardwarova´ adresa klienta sname – volitelny´ na´zev serveru file – adresa bootovacı´ho souboru options – seznam volitelny´ch parametru˚
2.3
Popis komunikace
Pru˚beˇh komunikace mezi klientem a serverem je zobrazen na obra´zku 2.1. Zacˇa´tek komunikace nasta´va´ prˇipojenı´m pocˇ´ıtacˇe do sı´teˇ a jeho zapnutı´m. Operacˇnı´ syste´m prˇi startu veˇtsˇinou sa´m spustı´ DHCP klienta, ktery´ se bude starat o nastavenı´ sı´teˇ. Ten nejprve vysˇle do sı´teˇ zpra´vu DISCOVER. Tı´m se snazˇ´ı najı´t neˇktery´ dostupny´ DHCP server, ktery´ by byl ochoten mu prˇideˇlit nastavenı´ sı´teˇ. DHCP server by meˇl vzˇdy v sı´ti existovat pouze jeden, jinak by docha´zelo ke kolizı´m a nespra´vne´ funkcˇnosti sı´teˇ. Pokud na sı´ti je neˇktery´ DHCP server a je nastaveny´ tak, aby tomuto klientovi prˇideˇlil adresu, vybere pomocı´ dane´ho mechanizmu IP adresu a tu spolu se za´kladnı´m nastavenı´m sı´teˇ posˇle zpeˇt klientovi ve zpra´veˇ OFFER, cˇ´ımzˇ mu jı´ nabı´dne k pouzˇ´ıva´nı´. Klient po obdrzˇenı´ nabı´dnute´ adresy a nastavenı´ sı´teˇ rozhodne, zda bude tuto adresu pouzˇ´ıvat. Mu˚zˇe naprˇ´ıklad zjistit, zˇe uzˇ jı´ neˇkdo jiny´ v sı´ti pouzˇ´ıva´, cozˇ by meˇl ale kontrolovat server a takovou adresu nenabı´zet, nebo se z neˇjake´ho jine´ho du˚vodu rozhodne ji neprˇijmout. 7
2. POPIS DHCP PROTOKOLU Toto rozhodnutı´ da´ DHCP serveru veˇdeˇt pomocı´ zpra´vy RELEASE. Pokud je vsˇechno v porˇa´dku, klient o adresu pozˇa´da´ zpra´vou REQUEST. V tomto stavu ji ale jesˇteˇ nemu˚zˇe pouzˇ´ıvat, musı´ nejprve pocˇkat na potvrzenı´ od serveru. Server po prˇijetı´ REQUEST zpra´vy oveˇrˇ´ı, jestli tuto adresu opravdu nabı´dl pra´veˇ tomu klientovi a pokud narazı´ na proble´m, odpovı´ mu zpra´vou NAK, cˇ´ımzˇ mu da´va´ najevo, zˇe tuto adresu nesmı´ pouzˇ´ıvat. Probeˇhne-li kontrola v porˇa´dku, posˇle klientovi zpra´vu ACK. Touto zpra´vou u´speˇsˇneˇ koncˇ´ı DHCP komunikace mezi klientem a serverem a klient si mu˚zˇe nastavit IP adresu a pouzˇ´ıvat jı´. V ostatnı´ch prˇ´ıpadech musı´ klient zkusit znovu pozˇa´dat pomocı´ DISCOVER zpra´vy o novou adresu a cely´ proces opakovat.
Obra´zek 2.1: pru˚beˇh obsluhy spojenı´ Pokud klient ukoncˇ´ı svoji cˇinnost, odesˇle na server zpra´vu RELEASE, aby server veˇdeˇl, zˇe jizˇ nebude adresu da´le vyuzˇ´ıvat. Na toto chova´nı´ se vsˇak v praxi neda´ spolehnout. Klient mu˚zˇe by´t ukoncˇen nestandartnı´m zpu˚sobem nebo prosteˇ neposı´la´ nic.
8
2. POPIS DHCP PROTOKOLU
Typ zpra´vy DISCOVER OFFER REQUEST ACK RELEASE DECLINE NAK
Popis jednotlivy´ch stavu˚ Popis klient vysˇle na broadcast pozˇadavek o prˇideˇlenı´ adresy server vybere volnou IP adresu a nabı´dne ji klientovi klient se rozhodne prˇijmout nabı´dnutou IP adresu server potvrdı´ klientovi adresu a prˇirˇadı´ mu ji klient prˇestane IP adresu vyuzˇ´ıvat klient odmı´tne serverem nabı´zenou adresu server odmı´tne prˇirˇadit klientovi pozˇadovanou adresu
9
Kapitola 3
Analy´za 3.1
Pozˇadavky
Akademicke´ instituce v Brneˇ jsou propojeny vysokorychlostnı´ optickou sı´tı´, kterou udrzˇuje ICS (The Institute of Computer Science). Prˇ´ıstup k te´to sı´ti je samozrˇejmeˇ nabı´zen i studentu˚m MU a to nejenom v ra´mci pocˇ´ıtacˇovy´ch ucˇeben na fakulta´ch nebo ve specializovany´ch laboratorˇ´ıch, ale naprˇ´ıklad i na vysokosˇkolsky´ch kolejı´ch, kde je internetova´ prˇ´ıpojka skoro v kazˇde´m pokoji. Takovou sı´t’ samozrˇejmeˇ nenı´ jednoduche´ spravovat a vyzˇaduje to od administra´toru˚ velke´ u´silı´. Tento DHCP server je urcˇeny´ pro provoz pra´veˇ na zminˇovany´ch vysokosˇkolsky´ch kolejı´ch. Topologie sı´teˇ na teˇchto kolejı´ch je zna´zorneˇna na obra´zku 3.1 Kazˇda´ kolej ma´ jeden centra´lnı´ aktivnı´ prvek, ke ktere´mu je prˇipojeno vı´ce koncovy´ch aktivnı´ch prvku˚. Jejich pocˇet za´visı´ na pocˇtu za´suvek potrˇebny´ch pro pokrytı´ vsˇech pokoju˚. Ke koncovy´m aktivnı´m prvku˚m jsou prˇ´ımo prˇipojeny jednotlive´ za´suvky na pokojı´ch studentu˚. Aby nebylo mozˇne´ si na kolejı´ch jakkoliv zapojovat pocˇ´ıtacˇe a pouzˇ´ıvat je, je na kazˇde´m kolejnı´m routeru firewall, ktery´ oddeˇluje vnitrˇnı´ sı´t od akademicke´ sı´teˇ. Firewall pro veˇtsˇ´ı bezpecˇnost kontroluje u kazˇde´ho spojenı´
Obra´zek 3.1: Topologie sı´teˇ 10
3. ANALY´ZA IP adresu a MAC adresu pocˇ´ıtacˇe, ktery´ jej vytva´rˇ´ı. MAC adresa pu˚vodneˇ slouzˇila jako unika´tnı´ identifikace sı´tove´ karty. Dnes je ovsˇem mozˇne´ si tuto adresu zmeˇnit te´meˇrˇ na cokoliv, cozˇ steˇzˇuje administra´toru˚m pra´ci. Na prˇideˇlova´nı´ ma´me neˇkolik bloku˚ verˇejny´ch IP adres, ktere´ je potrˇeba rozdeˇlit mezi koleje s prˇihle´dnutı´m na ocˇeka´vany´ pocˇet prˇipojeny´ch pocˇ´ıtacˇu˚. Prˇi tomto rozdeˇlova´nı´ je nutne´ si ponechat velke´ rezervy, ale zase se neda´ pocˇ´ıtat s tı´m, zˇe by kazˇdy´ student meˇl pocˇ´ıtacˇ, cozˇ by nebylo ani z technicky´ch du˚vodu˚ mozˇne´. Vzhledem k tomu, zˇe na kazˇde´ koleji je vı´ce podsı´tı´ prˇipojeny´ch k jednomu routeru, bude potrˇeba aby DHCP server doka´zal prˇideˇlovat ru˚zne´ adresy na za´kladeˇ toho, v jake´ cˇa´sti sı´teˇ je klient prˇipojen. Dalsˇ´ı du˚lezˇita´ veˇc je na´vaznost na dalsˇ´ı syste´my. Vzhledem k tomu, zˇe studenti majı´ mozˇnost si prˇes internet aktivovat sve´ prˇipojenı´ a firewall je zalozˇeny´ na kombinaci MAC adresa a IP adresa, je nutne´ prˇi aktivaci zna´t klientovu MAC adresu. Bylo by mozˇne´, aby se prˇi kazˇde´m takove´mto pozˇadavku webova´ aplikace prˇipojila na dany´ router a zjistila si z DHCP podle IP adresy prˇ´ıslusˇnou MAC adresu. To by ale bylo dosti neefektivnı´ a na´chylne´ k chyba´m beˇhem spojenı´, navı´c by to vyzˇadovalo upravit k takove´to funkcionaliteˇ webovou aplikaci. Je tedy mnohem idea´lneˇjsˇ´ı rˇesˇenı´ mı´t vsˇechna data na jednom mı´steˇ. Kvu˚li na´vaznosti je take´ du˚lezˇite´, aby tato data byla aktua´lnı´. Prˇipojı´-li si student pocˇ´ıtacˇ do sı´teˇ, dostane od DHCP serveru IP adresu a pokusı´ se ihned aktivovat sve´ internetove´ prˇipojenı´, je nutne´, aby webova´ aplikace jizˇ meˇla data k tomu potrˇebna´ a mohla s nimi ˇ esˇenı´, zˇe by si studenti mohli aktivovat internet azˇ druhy´ den pracovat. R po prˇipojenı´ do sı´teˇ by se jisteˇ nesetkalo s velky´m ohlasem. Hlavnı´ pozˇadavky tedy jsou, aby DHCP server zvla´dal obsluhovat neˇkolik vzda´leny´ch lokacı´. Da´le, aby byl dostatecˇne´ rychly´, jelikozˇ bude v sı´tı´ prˇipojeno velke´ mnozˇstvı´ pocˇ´ıtacˇu˚ a je velmi pravdeˇpodobne´, zˇe se jejich pocˇet bude zveˇtsˇovat. Poslednı´m pozˇadavkem je, aby data o prˇideˇleny´ch adresa´ch byla dostupna´ na jednom mı´steˇ a to v rea´lne´m cˇase.
3.2
Na´vrh rˇesˇenı´
Jednı´m rˇesˇenı´m je mı´t centra´lnı´ DHCP server, ktery´ bude obsluhovat vsˇechny koleje najednou. Tohle rˇesˇenı´ ale nenı´ zrovna idea´lnı´, vsˇechny koleje jsou sice spojeny velmi rychlou sı´tı´, takzˇe s tı´m by proble´m nebyl, horsˇ´ı ale je, zˇe prˇi vy´padku spojenı´ koleje s venkovnı´ sı´tı´ prˇestane fungovat i loka´lnı´ sı´t, nebot’ nenı´ mozˇne´ prˇideˇlovat adresy. Z toho du˚vodu jsem se rozhodl pro decentralizaci a nasazenı´ vlastnı´ho DHCP serveru na kazˇdou kolej. V tomto 11
3. ANALY´ZA prˇ´ıpadeˇ, pokud dojde k vy´padku serveru, bude ochromena pouze jedna kolej a ostatnı´ mu˚zˇou fungovat da´l. Je ale potrˇeba neˇjak centra´lneˇ sbı´rat data o prˇideˇleny´ch adresa´ch. Tato data je potrˇeba prˇena´sˇet v rea´lne´m cˇase, nenı´ tedy mozˇne´, naprˇ´ıklad, jednou za hodinu poslat seznam prˇideˇleny´ch adres na server. Pokazˇde´, kdyzˇ je adresa prˇideˇlena, je nutne´, aby se o tom v co nejkratsˇ´ım cˇase dozveˇdeˇl centra´lnı´ server, kde tı´m pa´dem budou informace o vsˇech aktivnı´ch adresa´ch ze vsˇech kolejı´. Nabı´zı´ se tedy mozˇnost ukla´dat tato data do databa´ze a ty pak synchronizovat vzda´leneˇ mezi sebou. Tı´m pa´dem budeme mı´t na centra´lnı´m serveru vzˇdy aktua´lnı´ informace o vsˇech cˇa´stech sı´teˇ, cozˇ bylo prˇedpokladem. Proble´m s rozdeˇlenı´m vı´ce podsı´tı´ na jeden DHCP server, tak aby server spra´vneˇ prˇideˇloval adresy, se da´ vyrˇesˇit tak, zˇe bude z dostupny´ch adres vybı´rat na´hodneˇ. Meˇli bychom tedy, naprˇ´ıklad, 3 podsı´teˇ pro jednu kolej, ty bychom nastavili DHCP serveru, nastavili spra´vneˇ sı´t, aby router byl schopen routovat vsˇechny sı´teˇ a vsˇechno by fungovalo. Tı´mto rˇesˇenı´m by ale vznikl obrovsky´ zmatek, kdyby, naprˇ´ıklad, 2 pocˇ´ıtacˇe na jednom pokoji meˇly adresy z jiny´ch podsı´tı´ a museli spolu komunikovat prˇes router, cˇ´ımzˇ by vzrostlo zatı´zˇenı´ sı´teˇ. Bylo tedy potrˇeba prˇideˇlit koncovy´m aktivnı´m prvku˚m, nejle´pe podle umı´steˇnı´, jednotlive´ podsı´teˇ. Naprˇ´ıklad, 1-4 patro jedena podsı´t, 5-8 druha´ atd. Tı´mto zpu˚sobem se na´m potom v praxi le´pe orientuje v sı´ti, kdy podle adresy doka´zˇeme zjistit prˇiblizˇne´ umı´steˇnı´ a naopak. Toto je dalsˇ´ı vy´hoda oproti prˇedchozı´mu rˇesˇenı´. Z prˇedpokladu, zˇe vsˇechny koncove´ aktivnı´ prvky jsou prˇipojeny do jednoho centra´lnı´ho, ktery´ je pak prˇipojeny´ prˇ´ımo k routeru, se nabı´zı´ mozˇnost zjisˇt’ovat z centra´lnı´ho aktivnı´ho prvku, z ktere´ho koncove´ho prvku pozˇadavek prˇisˇel a podle toho zjistit, s jakou podsı´tı´ pracujeme. Nasˇteˇstı´ pouzˇite´ aktivnı´ prvky podporujı´ tuto funkcionalitu a doka´zˇ´ı rˇ´ıct, na jake´m portu je prˇipojena dana´ MAC adresa. Dokonce doka´zˇ´ı tyto informace poskytovat prˇes SNMP. Tı´mto zpu˚sobem doka´zˇeme rozdeˇlit podsı´teˇ na jednotlive´ koncove´ aktivnı´ prvky podle umı´steˇnı´ a prˇes centra´lnı´ prvek jednodusˇe zjisˇt’ovat do jake´ho segmentu klient patrˇ´ı.
12
Kapitola 4
Pouzˇita´ IT 4.1
Jazyk C
Pro vlastnı´ realizaci jsem pouzˇil jazyk C. Je to pomeˇrneˇ stary´ programovacı´ jazyk, jeho pocˇa´tky sahajı´ do 70. let, kdy pa´nove´ Brian Kernighan a Dennis Ritchie vydali prvnı´ specifikaci tohoto jazyka. Od te´ doby se jazyk C vyvı´jel a vznikly dveˇ jeho hlavnı´ specifikace: •
ANSI C
•
ISO/IEC C
ANSI C je specifikace vyda´na American National Standards Institute, podle neˇhozˇ se te´zˇ nazy´va´. ISO/IEC C (da´le jen ISO C) je standart vydany´ International Organization for Standardization. Prˇi programova´nı´ jsem se drzˇel specifikace ISO C99, cozˇ je jejı´ poslednı´ verze. Existuje vı´ce prˇekladacˇu˚ jazyka C, ale ne kazˇdy´ podporuje u´plneˇ danou specifikaci a veˇtsˇinou prˇida´va´ podporu vlastnı´ch rozsˇ´ırˇenı´ jazyka. Ty jsou obcˇas vhodny´m doplneˇnı´m jazyka, jelikozˇ nove´ specifikace by meˇli vycha´zet jednou za 10 let (ISO C). Jejich pouzˇ´ıva´nı´m ale ztratı´me mozˇnost prˇenositelnosti ko´du na jiny´ prˇekladacˇ. Je proto nutne´ zva´zˇit pouzˇitı´ teˇchto rozsˇ´ırˇenı´ s ohledem na budoucı´ vyuzˇitı´ programu. Pro vy´voj jsem pouzˇil prˇekladacˇ GCC (GNU Compiler Collection) [1], ktery´ je dostupny´ pro velke´ mnozˇstvı´ platforem. Program byl testova´n na verzı´ch 3.3, 3.4 a noveˇ na 4.0. Tento jazyk jsem si zvolil z neˇkolika du˚vodu˚ •
kvalitnı´ na´vrh jazyka, ktery´ jizˇ byl le´ty proveˇrˇen
•
rozsˇ´ırˇenost, kterou dokazujı´ tisı´ce aplikacı´, na jejichzˇ vy´voj byl pouzˇit
•
dı´ky velke´mu rozsˇ´ırˇenı´ a existenci mnoha prˇekladacˇu˚ je mozˇne´ program prˇelozˇit a provozovat na moha platforma´ch(naprˇ. Linux, BSD) 13
4. POUZˇITA´ IT •
rychlost beˇhu vy´sledne´ aplikace, ktery´ sice v dnesˇnı´ch doba´ch pomalu ztra´cı´ smysl, jelikozˇ se objevuje sta´le vy´konneˇjsˇ´ı hardware, ale na sı´t’ove´ routery, kde se prˇedpokla´da´ beˇh DHCP serveru, se veˇtsˇinou pouzˇ´ıva´ starsˇ´ı hardware.
4.2
Protokol SNMP
SNMP, nebo-li Simple Network Management Protocol, je protokol specifikovany´ v RFC 1157 [5] a pouzˇ´ıva´ se k monitorova´nı´ sı´t’ovy´ch zarˇ´ızenı´. Pro komunikaci pomocı´ tohoto protokolu jsem pouzˇil knihovnu NetSNMP [6], cozˇ je volneˇ sˇirˇitelna´ knihovna implementujı´cı´ SNMP verze 1, 2 a 3. Pro moje u´cˇely je postacˇujı´cı´ SNMP verze 1.
4.3
Databa´ze PostgreSQL
Pro ukla´da´nı´ dat jsem potrˇeboval neˇkterou multiplatformnı´ volneˇ sˇirˇitelnou databa´zi. Z prˇedchozı´ch zkusˇenostı´ jsem pouzˇil databa´zi PostgreSQL[4], se kterou jsem byl doposud spokojen, jak po stra´nce vy´konu, tak funkcˇnosti. Pro testova´nı´ jsem pouzˇil poslednı´ soucˇasnou stable verzi z rˇady 8.0, cozˇ je 8.0.6. Jelikozˇ nepouzˇ´ıva´m zˇa´dne´ slozˇiteˇjsˇ´ı vlastnosti te´to databa´ze, pouze za´kladnı´ SQL dotazy, je mozˇne´ pouzˇ´ıt skoro libovolnou verzi. Pro prˇ´ıstup k databa´zi jsem pouzˇil knihovnu pq, ktera´ je soucˇa´stı´ standardnı´ instalace. Vzhledem k jizˇ zmı´neˇne´ nena´rocˇnosti na databa´zi je velmi jednoduche´ portovat aplikaci na kteroukoliv jinou databa´zi, ktera´ je vzhledem k nasazenı´ vhodneˇjsˇ´ı.
4.4
Dalsˇı´ knihovny
Jako dalsˇ´ı knihovnu jsem pouzˇil Log4c (Logging for C Library) [7], ktera´ zajisˇt’uje vy´stup z programu, at’uzˇ pro potrˇeby ladeˇnı´ nebo logova´nı´ akcı´ prˇi standartnı´m beˇhu. Tato knihovna je reimplementacı´ pu˚vodnı´ho projektu Log4J pro jazyk C. Vy´stup z programu se da´ rozdeˇlit do neˇkolika kategoriı´ podle du˚lezˇitosti (chyba, ladı´cı´ informace atd.) a podle prˇ´ıslusˇnosti k modulu aplikace. Vy´stup je na´sledneˇ mozˇne´ prˇesmeˇrovat na standardnı´ vy´stup, do souboru nebo trˇeba prˇeposlat na syslogd (de´mon pouzˇ´ıvany´ v linuxu pro shromazˇd’ova´nı´ informacı´ o beˇhu aplikacı´ a na´sledneˇ k jejich centra´lnı´mu ulozˇenı´).
14
Kapitola 5
Popis implementace 5.1
Pouzˇity´ DHCP server
Pro svojı´ implementaci DHCP serveru jsem pouzˇil cˇa´st jine´ho open source programu. Sˇlo o program udhcp [9]. Tento server mne zaujal svojı´ jednoduchostı´. Jedna´ se o projekt vyvı´jeny´ v ra´mci projektu Busybox, ktery´ se snazˇ´ı nahradit standardnı´ linuxove´ na´stroje jejich minimalisticky´mi verzemi pro provoz v embedded zarˇ´ızenı´ch. Tento DHCP server obsahuje u´plnou podporu DHCP protokolu podle RFC 213 [2] a neobsahuje dalsˇ´ı, pro mu˚j projekt zbytecˇne´, vlastnosti, ktere´ bych nevyuzˇil. Tento projekt je take´ podle me´ho na´zoru jednodusˇe a prˇehledneˇ naprogramova´n, cozˇ bylo vy´hodne´ pro jeho dalsˇ´ı u´pravy. Z tohoto projektu jsem pouzˇil sı´t’ovou vrstvu, ktera´ se stara´ o prˇ´ıjı´ma´nı´ a odesı´la´nı´ paketu˚ na sı´t’ova´ rozhranı´. Da´le jsem pouzˇil funkce pro generova´nı´ a parsova´nı´ DHCP paketu. Meˇl jsem tedy hotovy´ za´klad serveru, ale bylo zapotrˇebı´ dodeˇlat komunikaci s aktivnı´mi prvky prˇes SNMP a ukla´da´nı´ dat do databa´ze.
5.2
Struktura databa´ze
Pozˇadavky na databa´zi jsou minima´lnı´. Je potrˇeba jen jedna tabulka, ktera´ obsahuje seznam IP adres a informace o jejich prˇideˇlenı´. Jejı´ struktura pro PostgreSQL je zna´zorneˇna na obra´zku 5.1. id – klı´cˇ ip – IP adresa mac – MAC adresa lease – datum poslednı´ho prˇideˇlenı´ adresy subnet – cˇ´ıslo podsı´teˇ, do ktere´ho IP adresa patrˇ´ı status – stav IP adresy 15
5. POPIS IMPLEMENTACE
Obra´zek 5.1: sche´ma SQL tabulky Stav IP adresy ma´ na´sledujı´cı´ mozˇnosti: 1 – Adresa je volna´ a mu˚zˇe by´t prˇirˇazena 2 – Adresa byla nabı´dnuta k prˇirˇazenı´ 3 – Adresa jizˇ byla neˇkomu prˇirˇazena Server prˇi pouzˇitı´ parametru -gendb vygeneruje pocˇa´tecˇnı´ stav databa´ze. V tomto stavu je pro kazˇdou IP adresu z dane´ho rozsahu vygenerova´n jeden za´znam, ktery´ obsahuje pouze IP adresu a status 1. Prˇi nabı´dnutı´ adresy k prˇirˇazenı´ se zmeˇnı´ status na 2 a nastavı´ se lease na aktua´lnı´ cˇas. Pokud klient potvrdı´ prˇirˇazenı´ IP adresy, zmeˇnı´ se status na 3 a lease nastavı´ se na aktua´lnı´ cˇas.
5.3
Popis hlavnı´ cˇa´sti programu
Hlavnı´ program se stara´ o zpracova´nı´ prˇ´ıchozı´ch pozˇadavku˚ a je prova´deˇn ve smycˇce. Jediny´ zpu˚sob jeho ukoncˇenı´ je signa´lem TERM. Jiny´ zpu˚sob neexistuje, jelikozˇ program beˇzˇ´ı na pozadı´ a nenı´ mozˇne´ ho jinak ovla´dat. Zpracova´nı´ jeho pru˚beˇhu je zna´zorneˇno na obra´zku 5.2. Program nejprve cˇeka´ na prˇ´ıchozı´ spojenı´, pokud k neˇmu dojde, prˇijme se DHCP paket, zpracuje se a ulozˇ´ı do pameˇti. Podle jeho typu se potom rozhodne, jaka´ akce se ma´ prove´st. Jednotlive´ fa´ze zpracova´nı´ jsou popsa´ny podrobneˇji v na´sledujı´cı´ch kapitola´ch. 16
5. POPIS IMPLEMENTACE
Obra´zek 5.2: pru˚beˇh obsluhy spojenı´
5.3.1 Nacˇtenı´ paketu Server posloucha´ na prˇ´ıchozı´ pakety na portu 67 prˇes protokol UDP. Standardneˇ se tak deˇje na vsˇech syste´movy´ch interfacech. Pokud je potrˇeba specifikovat, na ktere´m interfacu bude server poslouchat, je to mozˇne´ prove´st pomocı´ konfigurace. Server posloucha´ na broadcast adrese, cozˇ je adresa pro vsˇesmeˇrove´ vysı´la´nı´, jejı´ vy´hodou je, zˇe prˇi posı´la´nı´ dat po sı´ti nenı´ potrˇeba specifikovat prˇ´ıjemce, ale data dojdou ke kazˇde´mu zarˇ´ızenı´ na sı´ti. Kazˇde´ zarˇ´ızenı´ ma´ mozˇnost tato data prˇijmout a zpracovat, nebo ignorovat. Klient totizˇ nenı´ schopny´ veˇdeˇt, na jake´ adrese DHCP server posloucha´ a kam mu ma´ poslat pozˇadavek o prˇideˇlenı´ adresy, a proto posˇle zpra´vu s pozˇadavkem o adresu vsˇem dostupny´m zarˇ´ızenı´m a doufa´, zˇe mu neˇktere´ spra´vneˇ odpovı´. Na prˇ´ıchozı´ spojenı´ cˇeka´ server pomocı´ funkce select, ktera´ je blokujı´cı´. Vykona´va´nı´ programu je tak pozastaveno a cˇeka´ se na probuzenı´ novy´m spojenı´m. Tato funkce take´ reaguje na prˇ´ıjem zpra´vy ze signa´love´ roury po17
5. POPIS IMPLEMENTACE psane´ v kapitole o zpracova´nı´ signa´lu˚. Funkce select dostane jako parametr seznam file deskriptoru˚, ktere´ ma´ sledovat a pokud je mozˇnost z neˇktery´ch cˇ´ıst, vra´tı´ jejich seznam. V nasˇem prˇ´ıpadeˇ tedy dostane file deskriptor otevrˇene´ho UDP spojenı´ a signa´lnı´ roury. Po skoncˇenı´ funkce select se dalsˇ´ı zpracova´nı´ rˇ´ıdı´ podle seznamu file deskriptoru˚, ktery´ vra´tila. Pokud obsahuje ten, ktery´ patrˇ´ı rourˇe pro posı´la´nı´ signa´lu, prˇecˇte se tento signa´l a zpracuje se. Dostaneme-li tedy zpra´vu o tom, zˇe byl prˇijat signa´l TERM, ukoncˇ´ıme hlavnı´ cyklus, uvolnı´ se vsˇechny alokovane´ prostrˇedky (jak pameˇt’, tak file desktiptory) a program se ukoncˇ´ı. Pokud dostaneme zpra´vu, zˇe byl prˇijat signa´l HUP, dojde k nove´mu nacˇtenı´ konfiguracˇnı´ho souboru, cˇ´ımzˇ se prˇepı´sˇou aktua´lnı´ hodnoty a cyklus se spustı´ od zacˇa´tku jizˇ s novy´mi hodnotami. Pokud seznam obsahuje file deskriptor otevrˇene´ho UDP spojenı´, pokracˇuje se v prˇijetı´ DHCP paketu. Dhcp paket jsou bina´rnı´ data, ktera´ majı´ pevneˇ danou strukturu popsanou v kapitole 2.2. Tento fakt je vyuzˇit k jeho dalsˇ´ımu zpracova´nı´. Nenı´ totizˇ nutne´ cˇ´ıst jednotlive´ cˇa´sti paketu a ukla´dat si je do promeˇnny´ch, ale pomocı´ vhodneˇ nadefinovane´ struktury mu˚zˇeme nacˇ´ıst cely´ paket a k informacı´m v neˇm ulozˇeny´ch prˇistupovat prˇes slozˇky struktury. Popisovana´ struktura vypada´ takto: struct dhcpMessage { uint8_t op; uint8_t htype; uint8_t hlen; uint8_t hops; uint32_t xid; uint16_t secs; uint16_t flags; uint32_t ciaddr; uint32_t yiaddr; uint32_t siaddr; uint32_t giaddr; uint8_t chaddr[16]; uint8_t sname[64]; uint8_t file[128]; uint32_t cookie; uint8_t options[308]; }; Jak je videˇt, jednotlive´ slozˇky odpovı´dajı´ svojı´ velikostı´, porˇadı´m a jme´nem datu˚m ve specifikaci DHCP paketu. Prˇi prˇijetı´ paketu jej tedy nacˇteme do promeˇnne´ typu dhcpMessage a da´le k neˇmu prˇistupujeme pouze prˇes 18
5. POPIS IMPLEMENTACE slozˇky struktury. 5.3.2 Zjisˇteˇnı´ typu zpra´vy Typ prˇijate´ zpra´vy je ulozˇen ve slozˇce options. Je to z toho du˚vodu, zˇe DHCP paket je totozˇny´ se starsˇ´ım bootp paketem, ktery´ neobsahoval ru˚zne´ typy zpra´v. Informace v options jizˇ nemajı´ prˇesneˇ danou strukturu, ale kazˇda´ polozˇka, ktera´ zde mu˚zˇe by´t obsazˇena, ma´ definovany´ ko´d, ktery´m zacˇ´ına´, a velikost. Pro zjisˇteˇnı´ typu zpra´vy je tedy nutne´ projı´t vsˇechna data, ktere´ options obsahuje a hledat pozˇadovany´ ko´d. Ten je pro polozˇku oznacˇujı´cı´ typ zpra´vy 0x35. Pokud tuto informaci nenalezneme, nejedna´ se zrˇejmeˇ o korektnı´ DHCP paket, nebo byl cestou po sı´ti posˇkozen, a mu˚zˇeme ho ignorovat a pokracˇovat v cˇeka´nı´ na dalsˇ´ı. Od klienta mu˚zˇeme dostat neˇkolik typu˚ zpra´v. DISCOVER Touto zpra´vou klient zˇa´da´ o prˇideˇlenı´ adresy a nastavenı´ sı´teˇ. Pro jejı´ zpracova´nı´ je potrˇeba nejprve zjistit v jake´m segmentu sı´teˇ je klient prˇipojen a podle toho mu vybrat adresu. REQUEST Touto zpra´vou na´m klient da´va´ najevo, zˇe nabı´dnutou adresu chce pouzˇ´ıvat. Je ale potrˇeba zkontrolovat, byla-li mu adresa skutecˇneˇ na´mi nabı´dnuta. DECLINE Touto zpra´vou klient odmı´ta´ nabı´dnutou adresu. Tato adresa musı´ byt nejprve zkontrolova´na a pak mu˚zˇe by´t oznacˇena jako nepouzˇita´ a nabı´dnuta jine´mu klientu. 5.3.3 SNMP dotaz Pro vy´beˇr spra´vne´ adresy je potrˇeba veˇdeˇt v jake´m segmentu sı´teˇ je klient prˇipojen. Jelikozˇ zna´me prˇesnou topologii sı´teˇ, nenı´ proble´m to zjistit. Tato implementace DHCP serveru pro svu˚j provoz potrˇebuje, aby existoval centra´lnı´ aktivnı´ prvek, ktery´ bude schopen odlisˇit spojenı´ z jednotlivy´ch segmentu˚. Tohoto aktivnı´ho prvku se v te´to fa´zi zepta´me, odkud prˇisˇlo spojeni z MAC adresy, ktera´ je ulozˇena v DHCP paketu. Nemusı´me tedy 19
5. POPIS IMPLEMENTACE kontrolovat, jestli je tato MAC adresa korektnı´ a existuje-li na sı´ti, to prˇenecha´me dane´mu aktivnı´mu prvku. Nejprve si vytvorˇ´ıme OID potrˇebne´ pro dotaz na aktivnı´ prvek. To se bude skla´dat z prefixu, ktery´ je veˇtsˇinou ru˚zny´ podle vy´robce zarˇ´ızenı´ a urcˇuje, kde ve SNMP stromu se informace nacha´zejı´. K neˇmu prˇipojı´me reprezentaci MAC adresy. K jejı´mu prˇevodu do pouzˇitelne´ formy stacˇ´ı jednotlive´ cˇa´sti prˇeve´st z sˇestna´ctkove´ soustavy do desı´tkove´. Jako SNMP komunitu pouzˇijeme standardnı´ public a verzi protokolu 1. Da´l uzˇ stacˇ´ı vy´sledne´ OID poslat jako dotaz na aktivnı´ prvek a prˇecˇ´ıst odpoveˇd’. Pokud nedostaneme zˇa´dnou odpoveˇd’ nebo informaci o tom, zˇe zarˇ´ızenı´ MAC adresu nezna´, jedna´ se nejspı´sˇe o podvrhnuty´ DHCP paket a mu˚zˇeme ignorovat a pokracˇovat v cˇeka´nı´ na dalsˇ´ı spojenı´. V opacˇne´m prˇ´ıpadeˇ zı´ska´me jako odpoveˇd’ cˇ´ıslo portu, prˇes ktery´ pozˇadavek prˇisˇel, cozˇ je v nasˇem prˇ´ıpadeˇ bra´no jako cˇ´ıslo segmentu sı´teˇ. 5.3.4 Vy´beˇr adresy z databa´ze Na za´kladeˇ MAC adresy a segmentu sı´teˇ klienta je potrˇeba zı´skat vhodnou IP adresu z databa´ze. Prˇi tomto procesu mu˚zˇe nastat neˇkolik mozˇnostı´: •
MAC adresa byla nalezena v databa´zi v pozˇadovane´m segmentu
•
MAC adresa byla nalezena v databa´zi, ale v jine´m segmentu
•
MAC adresa nebyla nalezena v databa´zi
Pokud MAC adresa byla nalezena v pozˇadovane´m segmentu, je situace nejjednodusˇsˇ´ı. Stacˇ´ı tedy vybrat za´znam z databa´ze se stejnou MAC adresou a segmentem a z neˇj vzı´t IP adresu. Pokud jsme sice nalezli MAC adresu, ale v jine´m segmentu, znamena´ to, zˇe se na´m klient prˇesteˇhoval do jine´ cˇa´sti sı´teˇ. To muzˇe by´t bud’ trvale´ nebo prˇechodne´, cozˇ na´s ale nezajı´ma´, protozˇe mu stejneˇ musı´me prˇideˇlit jinou adresu, nezˇ tu, kterou meˇl drˇ´ıve. Stary´ za´znam s MAC adresou tedy necha´me beze zmeˇny a da´le pokracˇujeme stejny´m zpu˚sobem, jako kdybychom nic nenasˇli. Pokud MAC adresa nebyla nalezena vu˚bec, je potrˇeba vybrat neˇkterou volnou. Jelikozˇ kazˇdy´ za´znam v databa´zi obsahuje stav, ve ktere´m se nacha´zı´, je tento vy´beˇr pomeˇrneˇ jednoduchy´ a stacˇ´ı najı´t libovolny´ za´znam, ktery´ je ve stavu volny´. Vybereme tedy prvnı´ za´znam, ktery´ ma´ stejny´ segment a jeho stav je volny´. Pokud ovsˇem zˇa´dny´ takovy´ za´znam v dane´m segmentu neexistuje, musı´me se pokusit pouzˇ´ıt znovu neˇkterou drˇ´ıve prˇideˇlenou IP adresu. Prˇi tomto procesu nejprve projdeme adresy, ktere´ 20
5. POPIS IMPLEMENTACE byly klientu˚m nabı´dnuty, ale uzˇ nebyly potvrzeny. Pokud neˇktery´ za´znam v tomto stavu nalezneme, pouzˇijeme jeho IP adresu. V prˇ´ıpadeˇ, zˇe ani tento za´znam neexistuje, je potrˇeba vzı´t neˇkterou jizˇ drˇ´ıve prˇideˇlenou IP adresu. Tuto adresu musı´me pecˇliveˇ vybrat, aby nedosˇlo ke kolizı´m na sı´ti. Je proto nutne´ vybrat nejstarsˇ´ı adresu. Pokud ale i cˇas prˇideˇlenı´ nejstarsˇ´ı IP adresy nenı´ v nasˇem prˇ´ıpadeˇ starsˇ´ı nezˇ jeden den, dostaneme se do proble´mu nedostatku volny´ch adres. Tento stav jizˇ DHCP server sa´m o sobeˇ nedoka´zˇe vyrˇesˇit a jedina´ mozˇnost je za´sah administra´tora, ktery´ mu˚zˇe rozdeˇlit soucˇasny´ plny´ segment na vı´ce maly´ch a kazˇde´mu z nich prˇideˇlit vlastnı´ rozsah adres nebo prˇideˇlit tomuto segmentu dalsˇ´ı rozsah. Toto rˇesˇenı´ uzˇ za´visı´ pouze na administra´torovi sı´teˇ, ktery´ nejle´pe zna´ strukturu sı´teˇ a vı´ jake´ ma´ mozˇnosti v hleda´nı´ novy´ch IP adres. V prˇ´ıpadeˇ, zˇe se na´m adresu nepodarˇilo najı´t, neposˇle se klientovi zˇa´dna´ odpoveˇd’, pouze se zapı´sˇe do logu chybovy´ stav a pokracˇuje se cˇeka´nı´m na dalsˇ´ı spojenı´. Pokud ma´me adresu, ktera´ je vhodna´ k prˇideˇlenı´ klientovi, je potrˇeba nejprve upravit za´znam v databa´zi. Stav za´znamu se zmeˇnı´ na nabı´dnutou adresu a cˇas nabı´dnutı´ na aktua´lnı´. Pote´ jizˇ mu˚zˇeme pokracˇovat ve zpracova´nı´ pozˇadavku a poslat klientovi zpeˇt vybranou IP adresu pomocı´ OFFER zpra´vy. 5.3.5 Kontrola v databa´zi Souhlasil-li klient s nabı´dnutou IP adresou a poslal na´m pozˇadavek k jejı´mu prˇideˇlenı´, je potrˇeba oveˇrˇit platnost tohoto pozˇadavku. Musı´ se v databa´zi najı´t za´znam, ktery´ obsahuje nabı´dnutou IP adresu, klientovu MAC adresu a stejnou podsı´t’, jako tu, ze ktere´ tento pozˇadavek prˇisˇel. ACK Jestlizˇe tento za´znam najdeme, vsˇe je v porˇa´dku a mu˚zˇeme klientovi adresu prˇideˇlit. Nejprve zmeˇnı´me jejı´ stav v databa´zi na prˇideˇlenou a cˇas prˇideˇlenı´ na aktua´lnı´. Pote´ mu˚zˇeme odeslat zpeˇt potvrzujı´cı´ zpra´vu ACK. NAK Pokud tento za´znam nenalezneme, jedna´ se nejspı´sˇe o podvrhnuty´ paket nebo dosˇlo ke spusˇteˇnı´ vı´ce DHCP serveru˚ na sı´ti a adresu mu nabı´dl jiny´ server. Jedna´-li se o druhy´ prˇ´ıpad, je na spra´vci sı´teˇ, aby tento proble´m vyrˇesˇil, protozˇe prakticky nenı´ mozˇne´ provozovat vı´ce DHCP serveru˚ na jedne´ sı´ti. V kazˇde´m prˇ´ıpadeˇ jako odezvu odesˇleme zamı´tavou odpoveˇd’ pomocı´ paketu NAK. 21
5. POPIS IMPLEMENTACE 5.3.6 Zrusˇenı´ v databa´zi Rozhodne-li se klient z jake´hokoliv du˚vodu, zˇe na´mi nabı´dnutou adresu pouzˇ´ıvat nebude, musı´me IP adresu znovu oznacˇit jako volnou. Tı´m prˇedcha´zı´me komplikacı´m prˇi nedostatku IP adres. Aby nedocha´zelo k neopra´vneˇne´mu uvolneˇnı´ cizı´ adresy, je potrˇeba alesponˇ zkontrolovat, sedı´-li IP adresa, MAC adresa a segment sı´teˇ, ze ktere´ho pozˇadavek prˇisˇel. Je-li vsˇe v porˇa´dku, mu˚zˇeme adresu oznacˇit jako volnou.
5.3.7 Odesla´nı´ paketu V te´to fa´zi ma´me jizˇ typ paketu a potrˇebna´ data, ktera´ v neˇm potrˇebujeme poslat klientovi. Jelikozˇ server obsluhuje neˇkolik podsı´tı´, musı´ mı´t pro kazˇdou jinou IP adresu, je proto potrˇeba odeslat paket se spra´vnou zdrojovou adresou. Tu zjistı´me z konfiguracˇnı´ho souboru podle segmentu, z ktere´ho pozˇadavek prˇisˇel. Nynı´ jizˇ stacˇ´ı pouzˇ´ıt ten spra´vny´ file deskriptor a poslat po neˇm strukturu dhcpMessage, ktery´ byl vytvorˇen na za´kladeˇ pu˚vodnı´ho pozˇadavku beˇhem prˇedchozı´ho zpracova´nı´.
5.4
Inicializace prostrˇedı´
Prˇi startu se program pokusı´ nacˇ´ıst konfiguracˇnı´ soubor a zpracovat ho. Standardneˇ se jedna´ o /etc/dhcpd.conf, jeho struktura a vsˇechny mozˇne´ volby jsou popsa´ny v prˇ´ıloze B. Pokud soubor neexistuje, je ukoncˇeno startova´nı´ programu s chybovou zpra´vou o nenalezenı´ konfiguracˇnı´ho souboru. Prˇi nacˇ´ıta´nı´ se take´ kontroluje spra´vnost jednotlivy´ch voleb, aby nedosˇlo k inicializaci promeˇnny´ch nespra´vny´mi hodnotami. Pokud program nenacˇte vsˇechny konfiguracˇnı´ hodnoty potrˇebne´ pro svu˚j beˇh, takte´zˇ se ukoncˇ´ı. Da´le je potrˇeba vytvorˇit spojenı´ na databa´zi, ktera´ bude kvu˚li rychlejsˇ´ımu zpracova´nı´ otevrˇena celou dobu beˇhu programu. Spojenı´ se pokusı´me nava´zat podle hodnot zadany´ch v konfiguracˇnı´m souboru. Pokud tyto volby chybı´ nebo jsou chybne´ a spojenı´ se nepodarˇ´ı, program se ukoncˇ´ı. Tato chyba je velmi kriticka´, protozˇe bez databa´ze program nema´ kde vzı´t data o prˇideˇleny´ch adresa´ch a nema´ si je ani kam ulozˇit po jejich prˇideˇlenı´. Principia´lneˇ by program sice fungovat mohl, ale jeho pouzˇ´ıva´nı´m by se na´m do sı´teˇ zanesl velky´ neporˇa´dek, nemeˇli bychom vu˚bec prˇehled o tom, kdo jake´ IP adresy pouzˇ´ıva´. Ze stejne´ho du˚vodu, pokud beˇhem beˇhu programu dojde k prˇerusˇenı´ konexe na databa´zi a nepodarˇ´ı se jı´ znovu nava´zat, program se take´ ukoncˇ´ı. 22
5. POPIS IMPLEMENTACE
5.5
Obsluha signa´lu˚
Na linuxu je mozˇnost komunikovat s programy pomocı´ signa´lu˚, je tedy vhodne´, aby program doka´zal zpracovat alesponˇ za´kladnı´ signa´ly. DHCP server ma´ handlery pro signa´ly TERM a HUP. Na signa´l TERM program dokoncˇ´ı zpracova´nı´ pra´veˇ prova´deˇne´ho spojenı´ a korektneˇ se ukoncˇ´ı. Na signa´l HUP server take´ nejprve dokoncˇ´ı pra´veˇ zpracova´vane´ spojenı´ a pote´ opeˇt nacˇte konfiguraci. Program obsluhuje signa´ly tı´m zpu˚sobem, zˇe pouzˇije funkci signal, ktere´ prˇeda´ jako parametry jme´no signa´lu a funkci, ktera´ se ma´ prˇi jeho prˇijetı´ zavolat. Da´le se jizˇ program nemusı´ o nic starat. Prˇi prˇijetı´ signa´lu se prˇerusˇ´ı prova´deˇnı´ programu a provede funkce, ktera´ byla dane´mu signa´lu zaregistrova´na. Obsluhu signa´lu˚ azˇ po dokoncˇenı´ zpracova´va´nı´ aktua´lnı´ho spojenı´ je docı´leno tı´m, zˇe funkce, ktere´ je zpracova´vajı´ nezacˇnou prˇ´ımo prova´deˇt potrˇebny´ ko´d, ale posˇlou jme´no signa´lu do roury, kterou zpracova´va´ hlavnı´ program, a skoncˇ´ı. Tı´m se vyhneme neprˇ´ıjemny´m situacı´m, kdy by se naprˇ´ıklad program ukoncˇil beˇhem ukla´da´nı´ dat do databa´ze a tı´m by v nı´ nebyly aktua´lnı´ u´daje, cozˇ by mohlo zpu˚sobit pozdeˇjsˇ´ı proble´my.
23
Kapitola 6
Za´veˇr Implementace DHCP serveru dle popsane´ho na´vrhu byla u´speˇsˇneˇ otestova´na a splnˇuje vsˇechny kladene´ pozˇadavky. Nynı´ je aplikace provozova´na na kolejı´ch Masarykovy univerzity. Sı´t’, pro kterou poskytuje sve´ sluzˇby nenı´ nejmensˇ´ı. Celkoveˇ je v nı´ zapojeno prˇes 1500 pocˇ´ıtacˇu˚ a je rozlozˇena´ v neˇkolika lokalita´ch. Nejzatı´zˇeneˇjsˇ´ı server, ke ktere´mu je prˇipojeno cca 500 pocˇ´ıtacˇu˚, vyrˇizuje kolem 3000 zpra´v denneˇ. Ve sˇpicˇka´ch obsluhuje azˇ 10 zpra´v za sekundu. Vytı´zˇenı´ serveru je prˇitom neznatelne´ a oproti norma´lnı´mu provozu se te´meˇrˇ nelisˇ´ı. Graf, ktery´ zna´zornˇuje pocˇet pozˇadavku˚ za hodinu beˇhem jednoho ty´dne je zna´zorneˇn na obra´zku 6.1. Vezmeme-li v u´vahu, zˇe prˇi jednom pozˇadavku musı´ server nejprve kontaktovat SNMP zarˇ´ızenı´ pro informace, z ktere´ho segmentu sı´teˇ klient pocha´zı´ a da´le jesˇteˇ dotaz do databa´ze kvu˚li zı´ska´nı´ dat, je tento vy´kon solidnı´. A to vsˇe na routeru, ktery´ routuje gigabitovou sı´t’s provozem desı´tek gigabajtu˚ denneˇ. Pro srovna´nı´ jsem provedl za´teˇzˇove´ testy, ktere´ jsem z provoznı´ch du˚vodu nemohl prova´deˇt na kolejnı´ sı´ti, ale na testovacı´m prostrˇedı´. To se skla´dalo ze dvou pocˇ´ıtacˇu˚ a aktivnı´ho prvku. Prvnı´ slouzˇil pro beˇh DHCP serveru a databa´ze a druhy´ posı´lal pozˇadavky na server. V tomto prostrˇedı´, kdy oba pocˇ´ıtacˇe byli obycˇejne´ pracovnı´ stanice, ktere´ jsou vy´konoveˇ mnohem slabsˇ´ı nezˇ stroje, na ktery´ch je v ostre´m provozu pouzˇit, jsem dosahoval zpracova´nı´ neˇkolika desı´tek zpra´v za sekundu bez sebemensˇ´ıch zna´mek zpomalenı´. Je tedy videˇt, zˇe server nejen zˇe situaci v pohodeˇ zvla´da´, ale ma´ jesˇteˇ velke´ rezervy. Na´sledna´ synchronizace dat z jednotlivy´ch serveru˚ na centra´lnı´ funguje takte´zˇ bez sebemensˇ´ıch potı´zˇ´ı a data o prˇideˇleny´ch adresa´ch jsou k dispozici v centra´lnı´ databa´zi te´meˇrˇ okamzˇiteˇ po prˇideˇlenı´. Myslı´m si tedy, zˇe praxe proka´zala spra´vnost na´vrhu a pouzˇite´ technologie. Velkou vy´hodou tohoto rˇesˇenı´ je jeho univerza´lnost. Pokud bude potrˇeba zprovoznit novou cˇa´st sı´teˇ v jine´ lokaliteˇ, nenı´ proble´m zprovoznit dalsˇ´ı DHCP server na tomto mı´steˇ a dı´ky databa´zove´ synchronizaci jeho data prˇeda´vat na centra´lnı´ server pro potrˇeby dalsˇ´ıch aplikacı´. Nenı´ nutny´ zˇa´dny´ za´sah do konfigurace nebo dokonce do implementace serveru a vsˇe bude fungovat spra´vneˇ. 24
6. ZA´VEˇR
Obra´zek 6.1: Graf vytı´zˇenı´ serveru
Dalsˇ´ı vy´hodou je neza´vislost na pouzˇity´ch sı´t’ovy´ch prvcı´ch, s ktery´mi musı´ server komunikovat. Pokud dojde k porusˇe neˇktere´ho centra´lnı´ho aktivnı´ho prvku a bude potrˇeba jej vymeˇnit za jiny´, prˇ´ıpadneˇ i od jine´ho vy´robce, stacˇ´ı v konfiguraci zmeˇnit OID, pod ktery´m novy´ aktivnı´ prvek poskytuje prˇ´ıstup k MAC adresa´m a portu˚m, na ktery´ch se vyskytujı´. Nenı´ tedy nutne´ upravovat server, aby byl schopen komunikovat se zarˇ´ızenı´m od jine´ho vy´robce, ale pouze se zmeˇnı´ jeho konfigurace. V praxi se te´zˇ uka´zala jako velmi vy´hodna´ pra´ce se segmenty sı´teˇ, kdy nenı´ proble´m prˇida´vat dalsˇ´ı nebo existujı´cı´m zveˇtsˇovat cˇi zmensˇovat rozsah IP adres. Naprˇ´ıklad, na jednom segmentu sı´teˇ se najednou objevilo vı´ce pocˇ´ıtacˇu˚, nezˇ se prˇi prˇideˇlova´nı´ adres prˇedpokla´dalo a dosˇly volne´ IP adresy. Po zjisˇteˇnı´ te´to skutecˇnosti na´m byl prˇideˇlen dalsˇ´ı blok IP adres pro pouzˇitı´ v tomto segmentu sı´teˇ. Prˇida´nı´ teˇchto adres, acˇ byli z jine´ podsı´teˇ nezˇ ty pu˚vodnı´, ke sta´vajı´cı´mu segmentu sı´teˇ bylo trivia´lnı´. Stacˇilo nakonfigurovat novy´ rozsah IP adres a prˇideˇlit jej na stejny´ segment jako ten pu˚vodnı´. Tı´m pa´dem DHCP server prˇi prˇijetı´ pozˇadavku z tohoto segmentu nevybı´ra´ IP adresu pouze z pu˚vodnı´ho rozsahu, ale i z nove´ho. Tı´m se vyrˇesˇil nedostatek 25
6. ZA´VEˇR IP adres. Implementace serveru se te´zˇ obesˇla bez potı´zˇ´ı. Beˇhem dvoumeˇsı´cˇnı´ho provozu tohoto DHCP serveru nedosˇlo k zˇa´dne´mu vy´padku zpu˚sobene´mu pa´dem serveru. Nedosˇlo ani k zˇa´dne´mu u´speˇsˇne´mu napadenı´ syste´mu pomocı´ u´myslneˇ sˇpatneˇ sestaveny´ch DHCP paketu˚. Tyto pokusy se vyskytly a nebylo jich ma´lo. Toto je obzvla´sˇteˇ du˚lezˇite´ z hlediska bezpecˇnosti. Mohlo by dojı´t v krajnı´ch prˇ´ıpadech k proniknutı´ do syste´mu neopra´vneˇnou osobou, cozˇ by znamenalo odstavenı´ cele´ho routeru ze sı´teˇ a jeho pecˇlivou kontrolu, ne-li cˇistou reinstalaci syste´mu. Tento vy´padek by tak ve vy´sledku znamenal odstavenı´ cele´ koleje od sı´teˇ. Z informacı´ zde uvedeny´ch, ktere´ jsou podlozˇene´ provozem v praxi na rozsa´hle´ a velmi vytı´zˇene´ sı´ti, navı´c plne´ potenciona´lnı´ch u´tocˇnı´ku˚, usuzuji, zˇe jsem syste´m navrhl a implementoval spra´vneˇ.
26
Literatura [1] GNU Compiler Colection, http://gcc.gnu.org/ [2] RFC 2131, http://www.faqs.org/rfcs/rfc2131.html [3] RFC 951, http://www.faqs.org/rfcs/rfc951.html [4] PostgreSQL, http://www.postgres.com/ [5] RFC 1157, http://www.faqs.org/rfcs/rfc1157.html [6] Net-SNMP, http://net-snmp.sourceforge.net/ [7] Log4c, http://log4c.sourceforge.net/ [8] Make, http://www.gnu.org/software/make/ [9] udhcp, http://udhcp.busybox.net/
27
Prˇı´loha A
Instalace A.1 Prˇı´prava knihoven Prˇed vlastnı´ instalacı´ serveru je nejprve nutne´ nainstalovat tyto knihovny: •
Net-SNMP [6]
•
pq (soucˇa´st PostgreSQL) [4]
•
Log4c [7]
Tyto knihovny se dajı´ sta´hnou na jejich domovsky´ch stra´nka´ch, kde je take´ k nalezenı´ na´vod k jejich instalaci. Dalsˇ´ı potrˇebna´ veˇc je prˇekladacˇ jazyka C. Doporucˇuji pouzˇ´ıt GCC [1], ktery´ jsem pouzˇ´ıval k vy´voji a mohu tedy zajistit jeho podporu. Pro da´vkovy´ prˇeklad je jesˇteˇ potrˇebna´ aplikace make [8].
A.2 Prˇı´prava databa´ze Da´le je nutne´ nainstalovat databa´zovy´ server PostgreSQL [4] a vytvorˇit databa´zi. V te´to databa´zi je nutne´ vytvorˇit tabulky potrˇebne´ pro ukla´da´nı´ dat. To provedeme pomocı´ souboru dhcp.sql, ktery´ obsahuje potrˇebne´ prˇ´ıkazy na jejı´ vytvorˇenı´. Prˇ´ıklad provedenı´ tohoto souboru: psql -U uz ˇivatel -h 127.0.0.1 -d dhcp -f dhcp.sql uz ˇivatel - jme´no uzˇivatele pro prˇ´ıstup do databa´ze 127.0.0.1 - adresa stroje, kde beˇzˇ´ı databa´zovy´ server dhcp - jme´no databa´ze
A.3 Vlastnı´ instalace Po dokoncˇenı´ vsˇech u´konu˚, popsany´ch v prˇedchozı´ch dvou sekcı´ch, je jizˇ instalace jednoducha´. Provede se spusˇteˇnı´m teˇchto prˇ´ıkazu˚ v adresa´rˇi se zdrojovy´m ko´dem: 28
A. INSTALACE ./configure make all make install
A.4 Konfigurace Konfigurace se prova´dı´ v souboru dhcpd.conf, ktery´ je standartneˇ hleda´n v adresa´rˇi /etc. V za´kladnı´ distribuci je vzorovy´ konfiguracˇnı´ soubor, ktery´ obsahuje vsˇechny mozˇne´ volby i s jejich popisem.
A.5 Spusˇteˇnı´ Spusˇteˇnı´ serveru se provede prˇ´ıkazem /usr/local/sbin/dhcpd [-c configfile], kde -c je volitelny´ parametr urcˇujı´cı´ konfiguracˇnı´ soubor standartneˇ /etc/dhcpd.conf). Informace o beˇhu serveru se standartneˇ posı´lajı´ na syslogd, ktery´ je da´le ukla´da´ podle sve´ho nastavenı´.
29
Prˇı´loha B
Popis konfigurace Globa´lnı´ hodnoty if listen – jme´no sı´t’ove´ho rozhranı´, na ktere´m ma´ server poslouchat if count – pocˇet obsluhovany´ch podsı´tı´ Nastavenı´ SNMP zarˇ´ızenı´ snmp ip – adresa SNMP zarˇ´ızenı´, ktere´ poskytuje informace o klientovi snmp community – komunita, ze ktere´ se majı´ cˇ´ıst informace snmp oid – OID mı´sta, kde se nacha´zı´ seznam dvojic MAC:port Nastavenı´ SNMP zarˇ´ızenı´ db ip – adresa databa´ze db name – jme´no databa´ze db user – uzˇivatel pro prˇ´ıstup k databa´zi db password – heslo pro prˇ´ıstup k databa´zi Popis jedne´ podsı´teˇ1 ifn id – id podsı´teˇ ifn name – jme´no podsı´teˇ ifn addr – adresa DHCP serveru v te´to podsı´ti ifn netmask – maska podsı´teˇ ifn dns1 – prvnı´ name server 1. ifn, kde n je cˇ´ıslo interfacu
30
B. POPIS KONFIGURACE ifn dns2 – druhy´ name server ifn gw – gateway pro podsı´t’ ifn from – zacˇa´tek rozsahu pro prˇideˇlova´nı´ adres ifn to – konec rozsahu pro prˇideˇlova´nı´ adres ifn socket – port na aktivnı´m prvku, prˇes ktery´ je tato podsı´t’prˇipojena
31
Prˇı´loha C
Obsah CDROM prˇı´lohy Adresa´rˇ prace src
Popis Text bakala´rˇske´ pra´ce ve forma´tu pdf a ps Zdrojove´ soubory DHCP serveru
32
