}w!"#$%&'()+,-./012345<ya

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w!"#$%&'()+,-./012345<ya DHCP server s podporou databáze a SNMP BAKALÁŘSKÁ PRÁCE Václav Šlajs Brno, jaro 2006

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

Poděkování Tímto bych chtěl poděkovat svému vedoucímu projektu, Mgr. Michalu Batkovi, za pomoc a vedení při tvorbě tohoto bakalářského projektu. Dále bych rád poděkoval společnosti Google, Inc., která mi pravidelně pomáhala řešit všechny problémy, které se během psaní práce vyskytly. iii

Shrnutí Cílem práce bylo vytvořit implementaci DHCP serveru podle specifikace RFC 2131. Jako rozšíření oproti standartním, běžně používaným DHCP serverům je přidána podpora ukládání dat o přidělených adresách do databáze a podpora na dotazování aktivních prvků v sítí přes protokol SNMP o tom odkud požadavek na adresu přišel. iv

Klíčová slova DHCP, C, Linux, SNMP, PostgreSQL v

Obsah 1 Úvod................................... 3 2 Popis DHCP protokolu........................ 5 2.1 Popis protokolu........................... 5 2.2 Popis paketu............................. 6 2.3 Popis komunikace.......................... 7 3 Analýza................................. 10 3.1 Požadavky.............................. 10 3.2 Návrh řešení............................ 11 4 Použitá IT................................ 13 4.1 Jazyk C............................... 13 4.2 Protokol SNMP........................... 14 4.3 Databáze PostgreSQL........................ 14 4.4 Další knihovny........................... 14 5 Popis implementace.......................... 15 5.1 Použitý DHCP server........................ 15 5.2 Struktura databáze......................... 15 5.3 Popis hlavní části programu.................... 16 5.3.1 Načtení paketu...................... 17 5.3.2 Zjištění typu zprávy................... 19 DISCOVER........................ 19 REQUEST......................... 19 DECLINE......................... 19 5.3.3 SNMP dotaz........................ 19 5.3.4 Výběr adresy z databáze................. 20 5.3.5 Kontrola v databázi.................... 21 ACK............................ 21 NAK............................ 21 5.3.6 Zrušení v databázi.................... 22 5.3.7 Odeslání paketu..................... 22 5.4 Inicializace prostředí........................ 22 5.5 Obsluha signálů........................... 23 6 Závěr................................... 24 1

A Instalace................................. 28 A.1 Příprava knihoven......................... 28 A.2 Příprava databáze.......................... 28 A.3 Vlastní instalace.......................... 28 A.4 Konfigurace............................. 29 A.5 Spuštění............................... 29 B Popis konfigurace............................ 30 C Obsah CDROM přílohy........................ 32 2

Kapitola 1 Úvod V současné době, kdy se rozvíjí informační technologie a využívá se stále více počítačů, je nutné je nějakým efektivním způsobem propojit. Tím nám vznikají rozsáhlé počítačové sítě, při jejichž správě již nestačí pouhý seznam počítačů na papíře s přidělenými adresami. Tím spíše, pokud se do sítě připojují cizí počítače, kterým je nutné sdělit nastavení a přidělit jim nějakou adresu. Za tímto účelem vznikl protokol DHCP (Dynamic Host Configuration Protocol), který vychází ze staršího BOOTP (Bootstrap Protocol). Tento protokol umožňuje dynamicky přidělovat počítačům nastavení sítě a jim přidělenou adresu. Ve svém zaměstnání, kde jsem měl za úkol nasadit v praxi nějaký DHCP server, jsem vyzkoušel více implementací DHCP protokolu. Bohužel ani jeden z nich nesplňoval mé požadavky. Vzhledem ke struktuře sítě jsem potřeboval zjišt ovat z aktivních prvků sítě odkud požadavek na adresu přišel, abych byl schopen odpovědět správným nastavením, které se liší pro různé segmenty sítě. K tomu jsem použil rozšířený protokol SNMP, který se běžně používá na monitorování sítě. Dále bylo potřeba informace o přidělených adresách použít v navazujících systémech. Většina dostupných DHCP serverů si tyto informace ukládala do svého externího souboru. Takto uložená data jsou ale obtížně zpřístupnitelná pro další zpracování, obzvláště, používá-li se v systému více DHCP serverů a je nutné pracovat s daty od všech. Proto jsem zvolil jako vhodné řešení ukládání těchto dat do databáze, která se dá následně synchronizovat do nějaké centrální, kde je pak přístup k datům ze všech serverů. Tento způsob je sice časově náročnější, ale ve výsledku se ukázal jako efektivnější. Z těchto důvodů jsem se rozhodl implementovat vlastní DHCP server s vlastnostmi, které jsem popsal. Původní implementace byla v jazyce Java, z důvodu její snadné přenositelnosti a oproti jazyku C rychlejšímu vývoji. Tento krok se ale později ukázal jako nepříliš správný, jelikož jazyk Java není příliš vhodný pro tento typ aplikací, například kvůli rychlosti. Proto jsem se rozhodl o novou implementaci v jazyce C. Jelikož dnes máme spoustu 3

1. ÚVOD kvalitního volně šiřitelného softwaru, nemusel jsem vše psát od základů, ale využil jsem již hotové implemente DHCP serveru, upravil ji k mým potřebám a přidal potřebné vlastnosti. Dovolte mi, abych Vás v tomto dokumentu blíže seznámil s tímto projektem a s problematikou, která je s ním spojena. 4

Kapitola 2 Popis DHCP protokolu 2.1 Popis protokolu DHCP protokol je popsán v RFC 2131 [?]. Vychází a rozšiřuje protokol BOOTP popsaný v RFC 951 [3]. Jeho využití je v poskytování konfigurace sítě klientů, kteří se do ní připojují. DHCP se skládá ze dvou částí protokol na přenášení dat po síti mezi klientem a serverem mechanizmus pro přidělování IP adres Popis protokolu je uveden v následujících kapitolách. Mechanizmus přidělování adres se dělí na tři způsoby: automatické přidělení dynamické přidělení manuální přidělení Automatické přidělení IP adresy znamená, že server při požadavku klienta o adresu vybere některou volnou a tu mu přidělí. Toto přidělení je trvalé a v budoucnosti tento klient dostane pokaždé stejnou adresu. To má nevýhodu pokud se klienti připojují do sítě jen přechodně, nebot pak zůstane obsazená IP adresa, která se už nikomu nepřidělí a může tak dojít k vyčerpání volných adres. Výhodou je, pokud klienti potřebují komunikovat mezi sebou, mají pořád stejnou IP adresu a nemusí se při každé konexi zjišt ovat aktuální adresa. Při dynamickém přidělování server přidělí klientovi IP adresu pouze na omezenou dobu. Pokud v této době klient znova požádá o IP adresu, je mu přidělena stejná. Po uplynutí této doby s ní ale server zachází jako s volnou adresou a může jí přidělit někomu jinému. Tento způsob má opačné klady a zápory oproti automatickému přidělování. Chrání se proti vyčerpání volných IP adres v důsledku jejich trvalého přidělení. Pokud klienti potřebují 5

2. POPIS DHCP PROTOKOLU mezi sebou komunikovat, musí si vždy nejprve zjistit IP adresu druhého klienta.. Manuální připojení znamená, že administrátor sítě přidělí klientům na základě jejich MAC adres pevné IP adresy a DHCP server slouží pouze k distribuci tohoto nastavení. Rozložení IP adres v síti mezi klienty je tedy pevně dané a pokud se do sítě přihlásí nový klient, musí administrátor sítě nastavit na DHCP serveru jeho nastavení. Tento mechanizmus se může vhodně kombinovat s dynamickým přidělováním, kdy administrátor sítě přidělí stálým počítačům pevné IP adresy, ale pokud se do sítě připojí někdo nový, automaticky dostane na nějaký čas přidělenou volnou IP adresu. Cíl DHCP protokolu je v co možná nejjednodušším nastavení sítě, jak pro administrátora, tak pro uživatele. Administrátorovi sítě DHCP umožňuje, aby mohl klientům jednoduše distribuovat nastavení sítě. Může jim přidělovat jednotlivě IP adresy nebo to nechat na DHCP serveru a pouze určit rozsah adres, ze kterých bude vybírat. Z hlediska uživatele je zapojení počítače do sítě triviální záležitost, protože se nemusí starat o žádné nastavení, pouze připojit počítač do sítě a zapnout. Pokud vše funguje jak má, tak se zbytek provede automaticky a během chvíle je schopen komunikovat po lokální síti. 2.2 Popis paketu V následující tabulce je znázorněn DHCP paket a rozmístění a velikost informací v něm uložených. Popis jednotlivých hodnot 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) op typ zprávy - požadavek/odpověd 6

2. POPIS DHCP PROTOKOLU htype typ hardwarové adresy hlen délka hardwarové adresy hops počet paketů, přes které paket prošel xid id probíhající transakce secs počet sekund od začátku transakce (vyplňuje klient) flags příznaky paletu ciaddr IP adresa klienta yiaddr požadovaná IP adresa klienta siaddr IP adresa dalšího serveru giaddr adresa relay serveru chaddr hardwarová adresa klienta sname volitelný název serveru file adresa bootovacího souboru options seznam volitelných parametrů 2.3 Popis komunikace Průběh komunikace mezi klientem a serverem je zobrazen na obrázku 2.1. Začátek komunikace nastává připojením počítače do sítě a jeho zapnutím. Operační systém při startu většinou sám spustí DHCP klienta, který se bude starat o nastavení sítě. Ten nejprve vyšle do sítě zprávu DISCOVER. Tím se snaží najít některý dostupný DHCP server, který by byl ochoten mu přidělit nastavení sítě. DHCP server by měl vždy v síti existovat pouze jeden, jinak by docházelo ke kolizím a nesprávné funkčnosti sítě. Pokud na síti je některý DHCP server a je nastavený tak, aby tomuto klientovi přidělil adresu, vybere pomocí daného mechanizmu IP adresu a tu spolu se základním nastavením sítě pošle zpět klientovi ve zprávě OFFER, čímž mu jí nabídne k používání. Klient po obdržení nabídnuté adresy a nastavení sítě rozhodne, zda bude tuto adresu používat. Může například zjistit, že už jí někdo jiný v síti používá, což by měl ale kontrolovat server a takovou adresu nenabízet, nebo se z nějakého jiného důvodu rozhodne ji nepřijmout. 7

2. POPIS DHCP PROTOKOLU Toto rozhodnutí dá DHCP serveru vědět pomocí zprávy RELEASE. Pokud je všechno v pořádku, klient o adresu požádá zprávou REQUEST. V tomto stavu ji ale ještě nemůže používat, musí nejprve počkat na potvrzení od serveru. Server po přijetí REQUEST zprávy ověří, jestli tuto adresu opravdu nabídl právě tomu klientovi a pokud narazí na problém, odpoví mu zprávou NAK, čímž mu dává najevo, že tuto adresu nesmí používat. Proběhne-li kontrola v pořádku, pošle klientovi zprávu ACK. Touto zprávou úspěšně končí DHCP komunikace mezi klientem a serverem a klient si může nastavit IP adresu a používat jí. V ostatních případech musí klient zkusit znovu požádat pomocí DISCOVER zprávy o novou adresu a celý proces opakovat. Obrázek 2.1: průběh obsluhy spojení Pokud klient ukončí svoji činnost, odešle na server zprávu RELEASE, aby server věděl, že již nebude adresu dále využívat. Na toto chování se však v praxi nedá spolehnout. Klient může být ukončen nestandartním způsobem nebo prostě neposílá nic. 8

2. POPIS DHCP PROTOKOLU Typ zprávy DISCOVER OFFER REQUEST ACK RELEASE DECLINE NAK Popis jednotlivých stavů Popis klient vyšle na broadcast požadavek o přidělení adresy server vybere volnou IP adresu a nabídne ji klientovi klient se rozhodne přijmout nabídnutou IP adresu server potvrdí klientovi adresu a přiřadí mu ji klient přestane IP adresu využívat klient odmítne serverem nabízenou adresu server odmítne přiřadit klientovi požadovanou adresu 9

Kapitola 3 Analýza 3.1 Požadavky Akademické instituce v Brně jsou propojeny vysokorychlostní optickou sítí, kterou udržuje ICS (The Institute of Computer Science). Přístup k této síti je samozřejmě nabízen i studentům MU a to nejenom v rámci počítačových učeben na fakultách nebo ve specializovaných laboratořích, ale například i na vysokoškolských kolejích, kde je internetová přípojka skoro v každém pokoji. Takovou sít samozřejmě není jednoduché spravovat a vyžaduje to od administrátorů velké úsilí. Tento DHCP server je určený pro provoz právě na zmiňovaných vysokoškolských kolejích. Topologie sítě na těchto kolejích je znázorněna na obrázku 3.1 Každá kolej má jeden centrální aktivní prvek, ke kterému je připojeno více koncových aktivních prvků. Jejich počet závisí na počtu zásuvek potřebných pro pokrytí všech pokojů. Ke koncovým aktivním prvkům jsou přímo připojeny jednotlivé zásuvky na pokojích studentů. Aby nebylo možné si na kolejích jakkoliv zapojovat počítače a používat je, je na každém kolejním routeru firewall, který odděluje vnitřní sít od akademické sítě. Firewall pro větší bezpečnost kontroluje u každého spojení Obrázek 3.1: Topologie sítě 10

3. ANALÝZA IP adresu a MAC adresu počítače, který jej vytváří. MAC adresa původně sloužila jako unikátní identifikace sítové karty. Dnes je ovšem možné si tuto adresu změnit téměř na cokoliv, což stěžuje administrátorům práci. Na přidělování máme několik bloků veřejných IP adres, které je potřeba rozdělit mezi koleje s přihlédnutím na očekávaný počet připojených počítačů. Při tomto rozdělování je nutné si ponechat velké rezervy, ale zase se nedá počítat s tím, že by každý student měl počítač, což by nebylo ani z technických důvodů možné. Vzhledem k tomu, že na každé koleji je více podsítí připojených k jednomu routeru, bude potřeba aby DHCP server dokázal přidělovat různé adresy na základě toho, v jaké části sítě je klient připojen. Další důležitá věc je návaznost na další systémy. Vzhledem k tomu, že studenti mají možnost si přes internet aktivovat své připojení a firewall je založený na kombinaci MAC adresa a IP adresa, je nutné při aktivaci znát klientovu MAC adresu. Bylo by možné, aby se při každém takovémto požadavku webová aplikace připojila na daný router a zjistila si z DHCP podle IP adresy příslušnou MAC adresu. To by ale bylo dosti neefektivní a náchylné k chybám během spojení, navíc by to vyžadovalo upravit k takovéto funkcionalitě webovou aplikaci. Je tedy mnohem ideálnější řešení mít všechna data na jednom místě. Kvůli návaznosti je také důležité, aby tato data byla aktuální. Připojí-li si student počítač do sítě, dostane od DHCP serveru IP adresu a pokusí se ihned aktivovat své internetové připojení, je nutné, aby webová aplikace již měla data k tomu potřebná a mohla s nimi pracovat. Řešení, že by si studenti mohli aktivovat internet až druhý den po připojení do sítě by se jistě nesetkalo s velkým ohlasem. Hlavní požadavky tedy jsou, aby DHCP server zvládal obsluhovat několik vzdálených lokací. Dále, aby byl dostatečné rychlý, jelikož bude v sítí připojeno velké množství počítačů a je velmi pravděpodobné, že se jejich počet bude zvětšovat. Posledním požadavkem je, aby data o přidělených adresách byla dostupná na jednom místě a to v reálném čase. 3.2 Návrh řešení Jedním řešením je mít centrální DHCP server, který bude obsluhovat všechny koleje najednou. Tohle řešení ale není zrovna ideální, všechny koleje jsou sice spojeny velmi rychlou sítí, takže s tím by problém nebyl, horší ale je, že při výpadku spojení koleje s venkovní sítí přestane fungovat i lokální sít, nebot není možné přidělovat adresy. Z toho důvodu jsem se rozhodl pro decentralizaci a nasazení vlastního DHCP serveru na každou kolej. V tomto 11

3. ANALÝZA případě, pokud dojde k výpadku serveru, bude ochromena pouze jedna kolej a ostatní můžou fungovat dál. Je ale potřeba nějak centrálně sbírat data o přidělených adresách. Tato data je potřeba přenášet v reálném čase, není tedy možné, například, jednou za hodinu poslat seznam přidělených adres na server. Pokaždé, když je adresa přidělena, je nutné, aby se o tom v co nejkratším čase dozvěděl centrální server, kde tím pádem budou informace o všech aktivních adresách ze všech kolejí. Nabízí se tedy možnost ukládat tato data do databáze a ty pak synchronizovat vzdáleně mezi sebou. Tím pádem budeme mít na centrálním serveru vždy aktuální informace o všech částech sítě, což bylo předpokladem. Problém s rozdělením více podsítí na jeden DHCP server, tak aby server správně přiděloval adresy, se dá vyřešit tak, že bude z dostupných adres vybírat náhodně. Měli bychom tedy, například, 3 podsítě pro jednu kolej, ty bychom nastavili DHCP serveru, nastavili správně sít, aby router byl schopen routovat všechny sítě a všechno by fungovalo. Tímto řešením by ale vznikl obrovský zmatek, kdyby, například, 2 počítače na jednom pokoji měly adresy z jiných podsítí a museli spolu komunikovat přes router, čímž by vzrostlo zatížení sítě. Bylo tedy potřeba přidělit koncovým aktivním prvkům, nejlépe podle umístění, jednotlivé podsítě. Například, 1-4 patro jedena podsít, 5-8 druhá atd. Tímto způsobem se nám potom v praxi lépe orientuje v síti, kdy podle adresy dokážeme zjistit přibližné umístění a naopak. Toto je další výhoda oproti předchozímu řešení. Z předpokladu, že všechny koncové aktivní prvky jsou připojeny do jednoho centrálního, který je pak připojený přímo k routeru, se nabízí možnost zjišt ovat z centrálního aktivního prvku, z kterého koncového prvku požadavek přišel a podle toho zjistit, s jakou podsítí pracujeme. Naštěstí použité aktivní prvky podporují tuto funkcionalitu a dokáží říct, na jakém portu je připojena daná MAC adresa. Dokonce dokáží tyto informace poskytovat přes SNMP. Tímto způsobem dokážeme rozdělit podsítě na jednotlivé koncové aktivní prvky podle umístění a přes centrální prvek jednoduše zjišt ovat do jakého segmentu klient patří. 12

Kapitola 4 Použitá IT 4.1 Jazyk C Pro vlastní realizaci jsem použil jazyk C. Je to poměrně starý programovací jazyk, jeho počátky sahají do 70. let, kdy pánové Brian Kernighan a Dennis Ritchie vydali první specifikaci tohoto jazyka. Od té doby se jazyk C vyvíjel a vznikly dvě jeho hlavní specifikace: ANSI C ISO/IEC C ANSI C je specifikace vydána American National Standards Institute, podle něhož se též nazývá. ISO/IEC C (dále jen ISO C) je standart vydaný International Organization for Standardization. Při programování jsem se držel specifikace ISO C99, což je její poslední verze. Existuje více překladačů jazyka C, ale ne každý podporuje úplně danou specifikaci a většinou přidává podporu vlastních rozšíření jazyka. Ty jsou občas vhodným doplněním jazyka, jelikož nové specifikace by měli vycházet jednou za 10 let (ISO C). Jejich používáním ale ztratíme možnost přenositelnosti kódu na jiný překladač. Je proto nutné zvážit použití těchto rozšíření s ohledem na budoucí využití programu. Pro vývoj jsem použil překladač GCC (GNU Compiler Collection) [1], který je dostupný pro velké množství platforem. Program byl testován na verzích 3.3, 3.4 a nově na 4.0. Tento jazyk jsem si zvolil z několika důvodů kvalitní návrh jazyka, který již byl léty prověřen rozšířenost, kterou dokazují tisíce aplikací, na jejichž vývoj byl použit díky velkému rozšíření a existenci mnoha překladačů je možné program přeložit a provozovat na moha platformách(např. Linux, BSD) 13

4. POUŽITÁ IT rychlost běhu výsledné aplikace, který sice v dnešních dobách pomalu ztrácí smysl, jelikož se objevuje stále výkonnější hardware, ale na sít ové routery, kde se předpokládá běh DHCP serveru, se většinou používá starší hardware. 4.2 Protokol SNMP SNMP, nebo-li Simple Network Management Protocol, je protokol specifikovaný v RFC 1157 [5] a používá se k monitorování sít ových zařízení. Pro komunikaci pomocí tohoto protokolu jsem použil knihovnu Net- SNMP [6], což je volně šiřitelná knihovna implementující SNMP verze 1, 2 a 3. Pro moje účely je postačující SNMP verze 1. 4.3 Databáze PostgreSQL Pro ukládání dat jsem potřeboval některou multiplatformní volně šiřitelnou databázi. Z předchozích zkušeností jsem použil databázi PostgreSQL[4], se kterou jsem byl doposud spokojen, jak po stránce výkonu, tak funkčnosti. Pro testování jsem použil poslední současnou stable verzi z řady 8.0, což je 8.0.6. Jelikož nepoužívám žádné složitější vlastnosti této databáze, pouze základní SQL dotazy, je možné použít skoro libovolnou verzi. Pro přístup k databázi jsem použil knihovnu pq, která je součástí standardní instalace. Vzhledem k již zmíněné nenáročnosti na databázi je velmi jednoduché portovat aplikaci na kteroukoliv jinou databázi, která je vzhledem k nasazení vhodnější. 4.4 Další knihovny Jako další knihovnu jsem použil Log4c (Logging for C Library) [7], která zajišt uje výstup z programu, at už pro potřeby ladění nebo logování akcí při standartním běhu. Tato knihovna je reimplementací původního projektu Log4J pro jazyk C. Výstup z programu se dá rozdělit do několika kategorií podle důležitosti (chyba, ladící informace atd.) a podle příslušnosti k modulu aplikace. Výstup je následně možné přesměrovat na standardní výstup, do souboru nebo třeba přeposlat na syslogd (démon používaný v linuxu pro shromažd ování informací o běhu aplikací a následně k jejich centrálnímu uložení). 14

Kapitola 5 Popis implementace 5.1 Použitý DHCP server Pro svojí implementaci DHCP serveru jsem použil část jiného open source programu. Šlo o program udhcp [9]. Tento server mne zaujal svojí jednoduchostí. Jedná se o projekt vyvíjený v rámci projektu Busybox, který se snaží nahradit standardní linuxové nástroje jejich minimalistickými verzemi pro provoz v embedded zařízeních. Tento DHCP server obsahuje úplnou podporu DHCP protokolu podle RFC 213 [2] a neobsahuje další, pro můj projekt zbytečné, vlastnosti, které bych nevyužil. Tento projekt je také podle mého názoru jednoduše a přehledně naprogramován, což bylo výhodné pro jeho další úpravy. Z tohoto projektu jsem použil sít ovou vrstvu, která se stará o příjímání a odesílání paketů na sít ová rozhraní. Dále jsem použil funkce pro generování a parsování DHCP paketu. Měl jsem tedy hotový základ serveru, ale bylo zapotřebí dodělat komunikaci s aktivními prvky přes SNMP a ukládání dat do databáze. 5.2 Struktura databáze Požadavky na databázi jsou minimální. Je potřeba jen jedna tabulka, která obsahuje seznam IP adres a informace o jejich přidělení. Její struktura pro PostgreSQL je znázorněna na obrázku 5.1. id klíč ip IP adresa mac MAC adresa lease datum posledního přidělení adresy subnet číslo podsítě, do kterého IP adresa patří status stav IP adresy 15

5. POPIS IMPLEMENTACE Obrázek 5.1: schéma SQL tabulky Stav IP adresy má následující možnosti: 1 Adresa je volná a může být přiřazena 2 Adresa byla nabídnuta k přiřazení 3 Adresa již byla někomu přiřazena Server při použití parametru -gendb vygeneruje počáteční stav databáze. V tomto stavu je pro každou IP adresu z daného rozsahu vygenerován jeden záznam, který obsahuje pouze IP adresu a status 1. Při nabídnutí adresy k přiřazení se změní status na 2 a nastaví se lease na aktuální čas. Pokud klient potvrdí přiřazení IP adresy, změní se status na 3 a lease nastaví se na aktuální čas. 5.3 Popis hlavní části programu Hlavní program se stará o zpracování příchozích požadavků a je prováděn ve smyčce. Jediný způsob jeho ukončení je signálem TERM. Jiný způsob neexistuje, jelikož program běží na pozadí a není možné ho jinak ovládat. Zpracování jeho průběhu je znázorněno na obrázku 5.2. Program nejprve čeká na příchozí spojení, pokud k němu dojde, přijme se DHCP paket, zpracuje se a uloží do paměti. Podle jeho typu se potom rozhodne, jaká akce se má provést. Jednotlivé fáze zpracování jsou popsány podrobněji v následujících kapitolách. 16

5. POPIS IMPLEMENTACE Obrázek 5.2: průběh obsluhy spojení 5.3.1 Načtení paketu Server poslouchá na příchozí pakety na portu 67 přes protokol UDP. Standardně se tak děje na všech systémových interfacech. Pokud je potřeba specifikovat, na kterém interfacu bude server poslouchat, je to možné provést pomocí konfigurace. Server poslouchá na broadcast adrese, což je adresa pro všesměrové vysílání, její výhodou je, že při posílání dat po síti není potřeba specifikovat příjemce, ale data dojdou ke každému zařízení na síti. Každé zařízení má možnost tato data přijmout a zpracovat, nebo ignorovat. Klient totiž není schopný vědět, na jaké adrese DHCP server poslouchá a kam mu má poslat požadavek o přidělení adresy, a proto pošle zprávu s požadavkem o adresu všem dostupným zařízením a doufá, že mu některé správně odpoví. Na příchozí spojení čeká server pomocí funkce select, která je blokující. Vykonávání programu je tak pozastaveno a čeká se na probuzení novým spojením. Tato funkce také reaguje na příjem zprávy ze signálové roury po- 17

5. POPIS IMPLEMENTACE psané v kapitole o zpracování signálů. Funkce select dostane jako parametr seznam file deskriptorů, které má sledovat a pokud je možnost z některých číst, vrátí jejich seznam. V našem případě tedy dostane file deskriptor otevřeného UDP spojení a signální roury. Po skončení funkce select se další zpracování řídí podle seznamu file deskriptorů, který vrátila. Pokud obsahuje ten, který patří rouře pro posílání signálu, přečte se tento signál a zpracuje se. Dostaneme-li tedy zprávu o tom, že byl přijat signál TERM, ukončíme hlavní cyklus, uvolní se všechny alokované prostředky (jak pamět, tak file desktiptory) a program se ukončí. Pokud dostaneme zprávu, že byl přijat signál HUP, dojde k novému načtení konfiguračního souboru, čímž se přepíšou aktuální hodnoty a cyklus se spustí od začátku již s novými hodnotami. Pokud seznam obsahuje file deskriptor otevřeného UDP spojení, pokračuje se v přijetí DHCP paketu. Dhcp paket jsou binární data, která mají pevně danou strukturu popsanou v kapitole 2.2. Tento fakt je využit k jeho dalšímu zpracování. Není totiž nutné číst jednotlivé části paketu a ukládat si je do proměnných, ale pomocí vhodně nadefinované struktury můžeme načíst celý paket a k informacím v něm uložených přistupovat přes složky struktury. Popisovaná struktura vypadá 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 vidět, jednotlivé složky odpovídají svojí velikostí, pořadím a jménem datům ve specifikaci DHCP paketu. Při přijetí paketu jej tedy načteme do proměnné typu dhcpmessage a dále k němu přistupujeme pouze přes 18

5. POPIS IMPLEMENTACE složky struktury. 5.3.2 Zjištění typu zprávy Typ přijaté zprávy je uložen ve složce options. Je to z toho důvodu, že DHCP paket je totožný se starším bootp paketem, který neobsahoval různé typy zpráv. Informace v options již nemají přesně danou strukturu, ale každá položka, která zde může být obsažena, má definovaný kód, kterým začíná, a velikost. Pro zjištění typu zprávy je tedy nutné projít všechna data, které options obsahuje a hledat požadovaný kód. Ten je pro položku označující typ zprávy 0x35. Pokud tuto informaci nenalezneme, nejedná se zřejmě o korektní DHCP paket, nebo byl cestou po síti poškozen, a můžeme ho ignorovat a pokračovat v čekání na další. Od klienta můžeme dostat několik typů zpráv. DISCOVER Touto zprávou klient žádá o přidělení adresy a nastavení sítě. Pro její zpracování je potřeba nejprve zjistit v jakém segmentu sítě je klient připojen a podle toho mu vybrat adresu. REQUEST Touto zprávou nám klient dává najevo, že nabídnutou adresu chce používat. Je ale potřeba zkontrolovat, byla-li mu adresa skutečně námi nabídnuta. DECLINE Touto zprávou klient odmítá nabídnutou adresu. Tato adresa musí byt nejprve zkontrolována a pak může být označena jako nepoužitá a nabídnuta jinému klientu. 5.3.3 SNMP dotaz Pro výběr správné adresy je potřeba vědět v jakém segmentu sítě je klient připojen. Jelikož známe přesnou topologii sítě, není problém to zjistit. Tato implementace DHCP serveru pro svůj provoz potřebuje, aby existoval centrální aktivní prvek, který bude schopen odlišit spojení z jednotlivých segmentů. Tohoto aktivního prvku se v této fázi zeptáme, odkud přišlo spojeni z MAC adresy, která je ulož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 přenecháme danému aktivnímu prvku. Nejprve si vytvoříme OID potřebné pro dotaz na aktivní prvek. To se bude skládat z prefixu, který je většinou různý podle výrobce zařízení a určuje, kde ve SNMP stromu se informace nacházejí. K němu připojíme reprezentaci MAC adresy. K jejímu převodu do použitelné formy stačí jednotlivé části převést z šestnáctkové soustavy do desítkové. Jako SNMP komunitu použijeme standardní public a verzi protokolu 1. Dál už stačí výsledné OID poslat jako dotaz na aktivní prvek a přečíst odpověd. Pokud nedostaneme žádnou odpověd nebo informaci o tom, že zařízení MAC adresu nezná, jedná se nejspíše o podvrhnutý DHCP paket a můžeme ignorovat a pokračovat v čekání na další spojení. V opačném případě získáme jako odpověd číslo portu, přes který požadavek přišel, což je v našem případě bráno jako číslo segmentu sítě. 5.3.4 Výběr adresy z databáze Na základě MAC adresy a segmentu sítě klienta je potřeba získat vhodnou IP adresu z databáze. Při tomto procesu může nastat několik možností: MAC adresa byla nalezena v databázi v požadovaném segmentu MAC adresa byla nalezena v databázi, ale v jiném segmentu MAC adresa nebyla nalezena v databázi Pokud MAC adresa byla nalezena v požadovaném segmentu, je situace nejjednodušší. Stačí tedy vybrat záznam z databáze se stejnou MAC adresou a segmentem a z něj vzít IP adresu. Pokud jsme sice nalezli MAC adresu, ale v jiném segmentu, znamená to, že se nám klient přestěhoval do jiné části sítě. To muže být bud trvalé nebo přechodné, což nás ale nezajímá, protože mu stejně musíme přidělit jinou adresu, než tu, kterou měl dříve. Starý záznam s MAC adresou tedy necháme beze změny a dále pokračujeme stejným způsobem, jako kdybychom nic nenašli. Pokud MAC adresa nebyla nalezena vůbec, je potřeba vybrat některou volnou. Jelikož každý záznam v databázi obsahuje stav, ve kterém se nachází, je tento výběr poměrně jednoduchý a stačí najít libovolný záznam, který je ve stavu volný. Vybereme tedy první záznam, který má stejný segment a jeho stav je volný. Pokud ovšem žádný takový záznam v daném segmentu neexistuje, musíme se pokusit použít znovu některou dříve přidělenou IP adresu. Při tomto procesu nejprve projdeme adresy, které 20

5. POPIS IMPLEMENTACE byly klientům nabídnuty, ale už nebyly potvrzeny. Pokud některý záznam v tomto stavu nalezneme, použijeme jeho IP adresu. V případě, že ani tento záznam neexistuje, je potřeba vzít některou již dříve přidělenou IP adresu. Tuto adresu musíme pečlivě vybrat, aby nedošlo ke kolizím na síti. Je proto nutné vybrat nejstarší adresu. Pokud ale i čas přidělení nejstarší IP adresy není v našem případě starší než jeden den, dostaneme se do problému nedostatku volných adres. Tento stav již DHCP server sám o sobě nedokáže vyřešit a jediná možnost je zásah administrátora, který může rozdělit současný plný segment na více malých a každému z nich přidělit vlastní rozsah adres nebo přidělit tomuto segmentu další rozsah. Toto řešení už závisí pouze na administrátorovi sítě, který nejlépe zná strukturu sítě a ví jaké má možnosti v hledání nových IP adres. V případě, že se nám adresu nepodařilo najít, nepošle se klientovi žádná odpověd, pouze se zapíše do logu chybový stav a pokračuje se čekáním na další spojení. Pokud máme adresu, která je vhodná k přidělení klientovi, je potřeba nejprve upravit záznam v databázi. Stav záznamu se změní na nabídnutou adresu a čas nabídnutí na aktuální. Poté již můžeme pokračovat ve zpracování požadavku a poslat klientovi zpět vybranou IP adresu pomocí OFFER zprávy. 5.3.5 Kontrola v databázi Souhlasil-li klient s nabídnutou IP adresou a poslal nám požadavek k jejímu přidělení, je potřeba ověřit platnost tohoto požadavku. Musí se v databázi najít záznam, který obsahuje nabídnutou IP adresu, klientovu MAC adresu a stejnou podsít, jako tu, ze které tento požadavek přišel. ACK Jestliže tento záznam najdeme, vše je v pořádku a můžeme klientovi adresu přidělit. Nejprve změníme její stav v databázi na přidělenou a čas přidělení na aktuální. Poté můžeme odeslat zpět potvrzující zprávu ACK. NAK Pokud tento záznam nenalezneme, jedná se nejspíše o podvrhnutý paket nebo došlo ke spuštění více DHCP serverů na síti a adresu mu nabídl jiný server. Jedná-li se o druhý případ, je na správci sítě, aby tento problém vyřešil, protože prakticky není možné provozovat více DHCP serverů na jedné síti. V každém případě jako odezvu odešleme zamítavou odpověd pomocí paketu NAK. 21

5. POPIS IMPLEMENTACE 5.3.6 Zrušení v databázi Rozhodne-li se klient z jakéhokoliv důvodu, že námi nabídnutou adresu používat nebude, musíme IP adresu znovu označit jako volnou. Tím předcházíme komplikacím při nedostatku IP adres. Aby nedocházelo k neoprávněnému uvolnění cizí adresy, je potřeba alespoň zkontrolovat, sedí-li IP adresa, MAC adresa a segment sítě, ze kterého požadavek přišel. Je-li vše v pořádku, můžeme adresu označit jako volnou. 5.3.7 Odeslání paketu V této fázi máme již typ paketu a potřebná data, která v něm potřebujeme poslat klientovi. Jelikož server obsluhuje několik podsítí, musí mít pro každou jinou IP adresu, je proto potřeba odeslat paket se správnou zdrojovou adresou. Tu zjistíme z konfiguračního souboru podle segmentu, z kterého požadavek přišel. Nyní již stačí použít ten správný file deskriptor a poslat po něm strukturu dhcpmessage, který byl vytvořen na základě původního požadavku během předchozího zpracování. 5.4 Inicializace prostředí Při startu se program pokusí načíst konfigurační soubor a zpracovat ho. Standardně se jedná o /etc/dhcpd.conf, jeho struktura a všechny možné volby jsou popsány v příloze B. Pokud soubor neexistuje, je ukončeno startování programu s chybovou zprávou o nenalezení konfiguračního souboru. Při načítání se také kontroluje správnost jednotlivých voleb, aby nedošlo k inicializaci proměnných nesprávnými hodnotami. Pokud program nenačte všechny konfigurační hodnoty potřebné pro svůj běh, taktéž se ukončí. Dále je potřeba vytvořit spojení na databázi, která bude kvůli rychlejšímu zpracování otevřena celou dobu běhu programu. Spojení se pokusíme navázat podle hodnot zadaných v konfiguračním souboru. Pokud tyto volby chybí nebo jsou chybné a spojení se nepodaří, program se ukončí. Tato chyba je velmi kritická, protože bez databáze program nemá kde vzít data o přidělených adresách a nemá si je ani kam uložit po jejich přidělení. Principiálně by program sice fungovat mohl, ale jeho používáním by se nám do sítě zanesl velký nepořádek, neměli bychom vůbec přehled o tom, kdo jaké IP adresy používá. Ze stejného důvodu, pokud během běhu programu dojde k přerušení konexe na databázi a nepodaří se jí znovu navázat, program se také ukončí. 22

5. POPIS IMPLEMENTACE 5.5 Obsluha signálů Na linuxu je možnost komunikovat s programy pomocí signálů, je tedy vhodné, aby program dokázal zpracovat alespoň základní signály. DHCP server má handlery pro signály TERM a HUP. Na signál TERM program dokončí zpracování právě prováděného spojení a korektně se ukončí. Na signál HUP server také nejprve dokončí právě zpracovávané spojení a poté opět načte konfiguraci. Program obsluhuje signály tím způsobem, že použije funkci signal, které předá jako parametry jméno signálu a funkci, která se má při jeho přijetí zavolat. Dále se již program nemusí o nic starat. Při přijetí signálu se přeruší provádění programu a provede funkce, která byla danému signálu zaregistrována. Obsluhu signálů až po dokončení zpracovávání aktuálního spojení je docíleno tím, že funkce, které je zpracovávají nezačnou přímo provádět potřebný kód, ale pošlou jméno signálu do roury, kterou zpracovává hlavní program, a skončí. Tím se vyhneme nepříjemným situacím, kdy by se například program ukončil během ukládání dat do databáze a tím by v ní nebyly aktuální údaje, což by mohlo způsobit pozdější problémy. 23

Kapitola 6 Závěr Implementace DHCP serveru dle popsaného návrhu byla úspěšně otestována a splňuje všechny kladené požadavky. Nyní je aplikace provozována na kolejích Masarykovy univerzity. Sít, pro kterou poskytuje své služby není nejmenší. Celkově je v ní zapojeno přes 1500 počítačů a je rozložená v několika lokalitách. Nejzatíženější server, ke kterému je připojeno cca 500 počítačů, vyřizuje kolem 3000 zpráv denně. Ve špičkách obsluhuje až 10 zpráv za sekundu. Vytížení serveru je přitom neznatelné a oproti normálnímu provozu se téměř neliší. Graf, který znázorňuje počet požadavků za hodinu během jednoho týdne je znázorněn na obrázku 6.1. Vezmeme-li v úvahu, že při jednom požadavku musí server nejprve kontaktovat SNMP zařízení pro informace, z kterého segmentu sítě klient pochází a dále ještě dotaz do databáze kvůli získání dat, je tento výkon solidní. A to vše na routeru, který routuje gigabitovou sít s provozem desítek gigabajtů denně. Pro srovnání jsem provedl zátěžové testy, které jsem z provozních důvodu nemohl provádět na kolejní síti, ale na testovacím prostředí. To se skládalo ze dvou počítačů a aktivního prvku. První sloužil pro běh DHCP serveru a databáze a druhý posílal požadavky na server. V tomto prostředí, kdy oba počítače byli obyčejné pracovní stanice, které jsou výkonově mnohem slabší než stroje, na kterých je v ostrém provozu použit, jsem dosahoval zpracování několika desítek zpráv za sekundu bez sebemenších známek zpomalení. Je tedy vidět, že server nejen že situaci v pohodě zvládá, ale má ještě velké rezervy. Následná synchronizace dat z jednotlivých serverů na centrální funguje taktéž bez sebemenších potíží a data o přidělených adresách jsou k dispozici v centrální databázi téměř okamžitě po přidělení. Myslím si tedy, že praxe prokázala správnost návrhu a použité technologie. Velkou výhodou tohoto řešení je jeho univerzálnost. Pokud bude potřeba zprovoznit novou část sítě v jiné lokalitě, není problém zprovoznit další DHCP server na tomto místě a díky databázové synchronizaci jeho data předávat na centrální server pro potřeby dalších aplikací. Není nutný žádný zásah do konfigurace nebo dokonce do implementace serveru a vše bude fungovat správně. 24

6. ZÁVĚR Obrázek 6.1: Graf vytížení serveru Další výhodou je nezávislost na použitých sít ových prvcích, s kterými musí server komunikovat. Pokud dojde k poruše některého centrálního aktivního prvku a bude potřeba jej vyměnit za jiný, případně i od jiného výrobce, stačí v konfiguraci změnit OID, pod kterým nový aktivní prvek poskytuje přístup k MAC adresám a portům, na kterých se vyskytují. Není tedy nutné upravovat server, aby byl schopen komunikovat se zařízením od jiného výrobce, ale pouze se změní jeho konfigurace. V praxi se též ukázala jako velmi výhodná práce se segmenty sítě, kdy není problém přidávat další nebo existujícím zvětšovat či zmenšovat rozsah IP adres. Například, na jednom segmentu sítě se najednou objevilo více počítačů, než se při přidělování adres předpokládalo a došly volné IP adresy. Po zjištění této skutečnosti nám byl přidělen další blok IP adres pro použití v tomto segmentu sítě. Přidání těchto adres, ač byli z jiné podsítě než ty původní, ke stávajícímu segmentu sítě bylo triviální. Stačilo nakonfigurovat nový rozsah IP adres a přidělit jej na stejný segment jako ten původní. Tím pádem DHCP server při přijetí požadavku z tohoto segmentu nevybírá IP adresu pouze z původního rozsahu, ale i z nového. Tím se vyřešil nedostatek 25

6. ZÁVĚR IP adres. Implementace serveru se též obešla bez potíží. Během dvouměsíčního provozu tohoto DHCP serveru nedošlo k žádnému výpadku způsobenému pádem serveru. Nedošlo ani k žádnému úspěšnému napadení systému pomocí úmyslně špatně sestavených DHCP paketů. Tyto pokusy se vyskytly a nebylo jich málo. Toto je obzvláště důležité z hlediska bezpečnosti. Mohlo by dojít v krajních případech k proniknutí do systému neoprávněnou osobou, což by znamenalo odstavení celého routeru ze sítě a jeho pečlivou kontrolu, ne-li čistou reinstalaci systému. Tento výpadek by tak ve výsledku znamenal odstavení celé koleje od sítě. Z informací zde uvedených, které jsou podložené provozem v praxi na rozsáhlé a velmi vytížené síti, navíc plné potencionálních útočníků, usuzuji, že jsem systém navrhl a implementoval správně. 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

Příloha A Instalace A.1 Příprava knihoven Před vlastní instalací serveru je nejprve nutné nainstalovat tyto knihovny: Net-SNMP [6] pq (součást PostgreSQL) [4] Log4c [7] Tyto knihovny se dají stáhnou na jejich domovských stránkách, kde je také k nalezení návod k jejich instalaci. Další potřebná věc je překladač jazyka C. Doporučuji použít GCC [1], který jsem používal k vývoji a mohu tedy zajistit jeho podporu. Pro dávkový překlad je ještě potřebná aplikace make [8]. A.2 Příprava databáze Dále je nutné nainstalovat databázový server PostgreSQL [4] a vytvořit databázi. V této databázi je nutné vytvořit tabulky potřebné pro ukládání dat. To provedeme pomocí souboru dhcp.sql, který obsahuje potřebné příkazy na její vytvoření. Příklad provedení tohoto souboru: psql -U uživatel -h 127.0.0.1 -d dhcp -f dhcp.sql uživatel - jméno uživatele pro přístup do databáze 127.0.0.1 - adresa stroje, kde běží databázový server dhcp - jméno databáze A.3 Vlastní instalace Po dokončení všech úkonů, popsaných v předchozích dvou sekcích, je již instalace jednoduchá. Provede se spuštěním těchto příkazů v adresáři se zdrojovým kódem: 28

A. INSTALACE./configure make all make install A.4 Konfigurace Konfigurace se provádí v souboru dhcpd.conf, který je standartně hledán v adresáři /etc. V základní distribuci je vzorový konfigurační soubor, který obsahuje všechny možné volby i s jejich popisem. A.5 Spuštění Spuštění serveru se provede příkazem /usr/local/sbin/dhcpd [-c configfile], kde -c je volitelný parametr určující konfigurační soubor standartně /etc/dhcpd.conf). Informace o běhu serveru se standartně posílají na syslogd, který je dále ukládá podle svého nastavení. 29

Příloha B Popis konfigurace Globální hodnoty if listen jméno sít ového rozhraní, na kterém má server poslouchat if count počet obsluhovaných podsítí Nastavení SNMP zařízení snmp ip adresa SNMP zařízení, které poskytuje informace o klientovi snmp community komunita, ze které se mají číst informace snmp oid OID místa, kde se nachází seznam dvojic MAC:port Nastavení SNMP zařízení db ip adresa databáze db name jméno databáze db user uživatel pro přístup k databázi db password heslo pro přístup k databázi Popis jedné podsítě 1 ifn id id podsítě ifn name jméno podsítě ifn addr adresa DHCP serveru v této podsíti ifn netmask maska podsítě ifn dns1 první name server 1. ifn, kde n je číslo interfacu 30

B. POPIS KONFIGURACE ifn dns2 druhý name server ifn gw gateway pro podsít ifn from začátek rozsahu pro přidělování adres ifn to konec rozsahu pro přidělování adres ifn socket port na aktivním prvku, přes který je tato podsít připojena 31

Příloha C Obsah CDROM přílohy Adresář prace src Popis Text bakalářské práce ve formátu pdf a ps Zdrojové soubory DHCP serveru 32