A DHCP rejtett szépségei I.

Átírás

1 A DHCP rejtett szépségei I. Szinte minden TCP/IP hálózat rendelkezik DHCP szolgáltatással. Ez az alkalmazás háttérbe húzódik, a felhasználók sohasem találkoznak vele, és ha jól működik, a rendszergazdák is csak hébe-hóba vetnek rá pillantást. Itt is érvényes az ókori bölcsesség: ami nem látható, az fontosabb, mint ami látható. Az Internet elterjedése technikai értelemben a TCP/IP protokollcsalád széles körű alkalmazását jelenti. Szemben azonban más protokollokkal, amelyek nem igényelnek különösebb konfigurálást, a TCP/IP negyedik verziója csak akkor nyeri el robosztusságát, ha az üzemeltetők precíz beállításokat végeznek rajta. Ha igen sok állomás dolgozik egy hálózatban, a beállítások sokszorosan terhelik a rendszergazdát. Kézzel kellene azokat végezni, méghozzá a helyszínen, hiszen csak a konfiguráció után lehet hálózati kapcsolatot létrehozni, másrészt a szabvány megköveteli, hogy minden állomás egyedi IPcímmel rendelkezzék, - ezt csak precíz és naprakész nyilvántartással lehet biztosítani. Az adatbázist folyton frissíteni kellene, amikor egy új gép érkezik, vagy egy eszközt az egyik hálózatból a másikba kell költöztetni. A problémahalmazra a válasz a DHCP szolgáltatás kialakítása. A Dynamic Host Configuration Protocol, vagyis a dinamikus címkonfigurációs eljárás képes automatikusan az ügyfelek számára egyedi IP-címeket osztani. A DHCP egy szabvány (RFC), bármely operációs rendszer használhatja, ha ismeri. Ma már talán nincs is olyan, amelyiket ne készítettek volna fel a címek automatikus kezelésére. Akár egy Windows for Workgroups 3.11, egy Linux, vagy egy OS/2 is lehet ügyfél. A kliensek viselkedése különböző helyzetekben és konfigurációs igényei eltérőek lehetnek, ahogy ezt később majd látni fogjuk. DHCP alapok A DHCP-szabvány megértéséhez néhány TCP/IP alapfogalmat precízen ismerni kell. Ezek a következők: IP-cím, alhálózati maszk, alapértelmezett átjáró, szórt üzenet (broadcast), útválasztó (router). Lakonikus tömörséggel nézzük, mi mit jelent. IP-cím: négy számjegyből álló, az adott állomást a hálózaton egyértelműen azonosító egyedi cím. A cím két részből áll: a hálózati címből és az állomás címéből. Ránézésre nem állapítható meg, hogy hol ér véget az egyik, és hol kezdődik a másik. Pl.: Alhálózati maszk: az a szám, amely meghatározza, hogy az IP-cím mely része hálózati, és mely része állomáscím. Ennek segítségével lehet megállapítani egy másik IP-címről, hogy az a mi hálózatunkba tartozik-e vagy sem. Pl: Alapértelmezett átjáró: ha egy olyan címre kell csomagokat küldeni, amely nem a mi hálózatunkban van, az állomások az alapértelmezett átjáró felé továbbítják az adatokat. A valóságban az alapértelemzett átjárók többnyire útválasztók (routerek). Szórt üzenet (broadcast): egy speciális csomag, amelyet minden állomás megkap, és fel is dolgoz. A szórt üzenetek nem jutnak át az útválasztón, mivel általában lokális jelentőségük van. Ethernet hálózaton a szórt üzenet MAC célcíme FF-FF-FF- FF-FF-FF. Útválasztó (router): egy olyan speciális állomás, amely kettő vagy ennél több IP-alhálózatot kapcsol össze, és rendelkezik azzal a képességgel, hogy az egyik hálózatból érkezett csomagot a megfelelő útvonalat kiválasztva egy másik hálózatba juttatja. Az alapvető TCP/IP fogalmak mellett meg kell barátkoznunk néhány speciális, a DHCP szabványra vagy kiszolgálóra jellemző definícióval is. Scope: Egy folytonos címtartomány (Pl.: ), amelyből a DHCP kiszolgáló címeket oszt az ügyfeleknek. (Egy vödör IP-cím a szerk.) Egyszerűbb esetekben a scope egy alhálózatot reprezentál. Superscope: Több scope rendszergazdák által meghatározott csoportja, amely képes több logikai alhálózat kezelésére egy fizikai alhálózaton. Exclusion range: Azon címek listája, tartománya, amelyeket a DHCP kiszolgáló nem fog kiajánlani az ügyfeleknek például mert már foglaltak. Address pool: A címtartomány kiosztható része. Lease (bérlet): a DHCP szerver által meghatározott időszak, amely idő alatt egy ügyfél használhatja a szervertől kapott címet. A bérletet meg kell újítani, különben lejár és tovább nem használható. A kiadott bérlet aktív. Ha nem történik megújítás, a bérlet aktív állapotból felhasználható (szabad) állapotba kerül, vagyis egy másik állomás számára kiadhatóvá válik. Reservation (lefoglalás): Állandó cím hozzárendelése egy ügyfélhez. Ezzel biztosítani lehet, hogy egy adott eszköznek mindig ugyanaz marad az IP-címe. Option types: Az ügyfeleknek átadandó konfigurációs paraméter. Általában egy scope-hoz adunk meg opciókat, de léteznek más lehetőségek is. Option classes: Egy másik módszer, hogy az ügyfelek részére konfigurációs beállításokat adjunk ki. Az IP-címet igénylő rendszerek tisztában vannak a saját gyártójukkal és egyéb tulajdonságaikkal, ezek alapján speciális konfigurációs beállításokat is megértenek. Az adott osztályba tartozó ügyfelek érvényesíteni fogják a beállításokat, másokra viszont hatástalan lesz. 1

2 A címkiosztás célja és elvei A DHCP szolgáltatás legfontosabb feladata, hogy egyedi címekkel lássa el azokat az állomásokat, amelyek ezt igénylik. A címeket egy előre kijelölt címtartományból, a scope-ból veszi. A folyamat szépsége abban rejlik, hogy megold egy paradoxont: miként lehet egy állomással TCP/IP szabvány szerint kommunikálni úgy, hogy az nem rendelkezik IP-címmel, ergo képtelen a kommunikációra. A megoldás a szórt üzenetek alkalmazása. Ez az egyetlen csomagtípus, amelyet minden állomás feldolgoz, és csak a csomag tartalma alapján dönti el, az vajon neki szól-e vagy sem. Lássuk pontosan a folyamatot. Az IP-címkiosztás menetrendje Egy állomás indulásakor érzékeli, hogy az üzemeltetők statikus IP konfiguráció helyett dinamikus cím kérésére állították. A 68-as UPD-forrásportról a 67-es UDP-célportra egy ún. DHCP-Discover (DHCP-felfedezés) szórt üzenetet indít a hálón. A csomag célja, hogy az állomás felhívja magára a figyelmet, és arra kérje az ilyen csomagokat figyelő DHCP-kiszolgálókat, hogy ajánljanak fel számára címet. Az ügyfél és a DHCP szerver kezdeti csomagváltásai A szerver vagy szerverek az üzenetet feldolgozzák, és szintén broadcast módszerrel elküldik felajánlásukat (feltéve, ha van kiosztható címük). Ezt a csomagot nevezzük DHCP-Offernek (DHCP ajánlat). A beérkezett ajánlatból vagy ajánlatokból az állomás kiválasztja a neki megfelelőt, és még mindig a szórt üzenettípust használva egy DHCP-Request (DHCP kérés) csomagot küld el a hálózaton. A csomagban elhelyezi annak a szervernek az azonosítóját, amelytől a címet kéri. A szórt üzenet azért hasznos, mert bár az állomás már tudja a kiválasztott szerver címét, a broadcast csomaggal könnyen értesítheti a többi szervert a választásáról, így azok erre a szórt üzenetre úgy reagálnak, hogy korábbi ajánlatukat visszavonják. A visszavonás nem jár hálózati forgalommal, csupán a felajánlott cím kerül újra felajánlható státuszba. Ha a DHCP-szerver elfogadja a kérést, egy DHCP-Acknowledgement (DHCP-jóváhagyás) csomaggal nyugtázza az ügyfél felé, továbbra is szórt üzenettel. Ekkor kapja meg az ügyfél az egyéb DHCP-opciókat is. A kiszolgáló rögzíti kliense legfontosabb adatait az adatbázisban, többek között a host nevét, MAC-címét, és a bérlet lejáratának időpontját. Igen ritka esetben az is előfordulhat, hogy nem fogadja el a szerver a kérést (például mert egy másik számítógép gyorsabb volt és előbb elhappolta a címet), ekkor egy negative acknowledgement (DHCP-Nack) csomagot kap az IP-címet kérő gép, amely azután újrakezdi az eljárást. Látnunk kell, hogy nem igazán vagy nem csupán egy IP-címet kap a számítógépünk, inkább egy engedélyt arra vonatkozóan, hogy egy meghatározott ideig használhat egy adott IP-címet néhány további paraméterrel együtt. Ebből következik, hogy nem a fenti az egyetlen kommunikáció a DHCP-szerver és az ügyfél között. Kommunikáció a DHCP-szerverrel Az IP-cím boldog tulajdonosa legközelebb egy újraindításkor fog kapcsolatba lépni a címkiosztó szolgáltatással. Azt várnánk, hogy a fentiekkel teljesen megegyező párbeszéd zajlik majd le, de tévedünk. Az ügyfelek ugyanis eltárolják a bérletre vonatkozó összes információt, vagyis tisztában vannak azzal, hogy őket megilleti egy cím. Ezért induláskor DHCP-Discover helyett egy DHCP-Request csomagot küldenek, amelyben a korábban már elnyert IP-címet kérik célzott üzenet formájában, megspórolva két csomagot, némi időt és sávszélességet. A kiszolgáló ezt rendesen DHCP-ACK üzenettel nyugtázza, és az élet megy tovább. Ha azonban a ki- és bekapcsolás között fontos változások történtek, például a hordozható gépünket egy másik telephelyen kapcsoltuk be, más eredménye lesz a csomagváltásnak. Az új alhálózatban a másik DHCP-szerver megkapja a DHCP- Request csomagot, mert a szórt üzenetet fel kell dolgoznia. Mivel a kért cím nem az ő hálózatából való, DHCP-Nack csomaggal válaszol a kérésre. Az ügyfél ezután elfelejti a korábbi címét, és egy szabályos IP-cím igénylésbe kezd. No, és mi van, ha a notebook-ot az otthoni hálózatba kapcsoltam be, ahol nincs is DHCP szerver? A szituációban a különböző operációs rendszerek eltérő módon viselkednek. Ha a rendszer Windows 95, vagy Windows NT 4.0, esetleg ezeknél korábbi változat, az ügyfélszoftver azt feltételezi, hogy nem változott a helyzete, csak a DHCP-szerver nem érhető el! A válasz nélkül maradt DHCP-Request csomag arra készteti az ügyfelet, hogy ellenőrizze, érvényes-e még a bérlete. Amennyiben a válasz igen, a rendszer a korábban megkapott IP beállításokkal elindul. Ha a bérlet már nem érvényes, a hálózati protokollt nem tölti be a szoftver. 2

3 Windows 98-tól felfelé, valamint Windows 2000-nél és Windows XP-nél már okosabbak az eszközök. Ha nem jön válasz a DHCP-Request csomagra, az operációs rendszer kísérletet tesz arra, hogy eldöntse, vajon a helyén van-e még és csak a DHCP-kiszolgáló nem érhető el, vagy egy új hálózatban működik, ahol nincs DHCP-szolgáltatás. A trükk egyszerű, egy ICMP (ping) csomagot küld az alapértelmezett átjáró felé. Ha választ kap, a rendszer ott ébredt fel, ahol kikapcsolták, és a DHCP-szolgáltatással van probléma. Ellenkező esetben, tehát ha az átjáró sem válaszol, a feltételezés az, hogy nem a saját helyén indították a rendszert ekkor használja a szoftver az APIPA képességét. Tegyünk egy kis kitérőt, és nézzük meg, miről van szó. Csináld magad DHCP: az APIPA A rövidítés az Automatic Private Internet Protocol Addressing kifejezés rövidítése, magyarul automatikus magán IP-cím kiosztási eljárás. A Microsoft otthoni és kisebb irodai hálózatokhoz vezette be a még csak draft formájában létező APIPA-t, olyan helyekre, ahol bizonyosan nincs kiszolgáló, mert nem érné meg, és nincs szaktudás sem a hálózat konfigurálására. Az APIPA működése egyszerű: ha induláskor az operációs rendszer nem talál DHCP kiszolgálót, a draft által lefoglalt, B- típusú IP-címtartományból ( , subnet mask: ) véletlenszerűen kiválaszt egy címet, meggyőződik arról, hogy azt más nem használja, majd elindul. A meggyőződés annyit tesz, hogy egy ICMP csomagot indít a kiválasztott cím felé. Ha érkezik rá válasz, már létezik a cím a hálózatban, tehát másikat kell keresni. Tízszer próbál így címhez jutni, és tekintve, hogy a lehetséges címek száma, kicsi az esélye, hogy nem találja meg az igazit. Az automatikusan meghatározott címhez azután nem ragaszkodik, és minden ötödik percben kibocsát egy DHCP-Discover csomagot, hátha meggondolták magukat az üzemeltetők és működőképes állapotba hoztak egy címkiosztó szolgáltatást. A DHCP és az APIPA azért fér meg egymás mellett, mert az operációs rendszer el tudja dönteni, hogy milyen szituációban van. Ha korábban már kapott IP-címet, most pedig nem, ugyanakkor az alapértelmezett átjáró működik, vélhetően a DHCPszerver áll. Sebaj, a korábban kapott, és érvényes bérletet lehet használni. Ha az alapértelmezett átjáró sem működik, úgy nincs is DHCP a közelben. Sebaj, ad magának címet az APIPA eljárással. Így vagy úgy, de az ügyfél IP-címhez jut. Persze, ha olyan régóta nincs már DHCP-szolgáltatás, hogy a bérlet lejárt, a rendszergazdák szándéka ellenére az APIPA segítségével éled fel a hálózat, de ez már nem az operációs rendszer felelőssége. További DHCP-üzenetváltások A bérlet egy meghatározott időtartamra vonatkozik, a bérlet lejárati dátummal rendelkezik. Az időtartamba beletartozik a kikapcsolt állapotban eltöltött idő is. Ha eltelik a bérleti idő fele, az ügyfél egy megújítási kérelmet küld annak a DHCPkiszolgálónak, amelytől a címet kapta. Nincs szükség szórt csomagokra, az üzenetváltás közvetlen. Ha nincs válasz, 4, 8, majd 16 másodperccel később újra próbálkozik az ügyfél. A szerver egy DHCP-Ack csomaggal jelzi, hogy elfogadja a bérlet meghosszabbítását. Amennyiben egy szerencsétlen véletlen miatt nem sikerül megújítani a bérletet félidőben, nem történik semmi, az ügyfél továbbra is kommunikációképes. Amikor a bérlet időtartamának 87,5%-a is eltelt, az igénylő újra próbálkozik. Ha ezúttal sem jár szerencsével, már felébred benne a gyanú, hogy valami gond van a kiszolgálóval, ezért a unicast, vagyis direkt csomag helyett ismét előveszi a régi trükköt, szórt üzenetet küld a hálózatra, hátha van ott DHCP-szolgáltatás, csak egy másik szerveren. Más kiszolgálók persze DHCP-Nack csomagot küldenek, de sebaj, ekkor újraindul a címigénylési eljárás, a végeredmény pedig egy új bérlet kiadása. Ha minden jóakaratunk ellenére 87,5%-nál sem sikerül a bérlet megújítása (még az újra bevetett 4, 8, és 16 másodperces újrapróbálkozás ellenére sem) a következő kérelem a bérlet lejáratakor esedékes. A sikertelenségnek már kommunikációs következményei vannak. Ha a rendszer ismeri az APIPA módszert, azzal szerez címet, de ha nem ismeri (Win95, NT4), cím (és hálózat) nélkül marad. Néhány szó elöljáróban a DHCP megbízhatóságáról Miután áttekintettük a lehetséges üzenetváltásokat, vizsgáljuk meg, hogy egyetlen kiszolgálóval, és némi ügyes beállítással milyen rendelkezésre állást tudunk biztosítani. A DHCP egy alapvető szolgáltatás, a legfontosabb kérdés mindenek előtt tehát az, vajon mennyire bízhatunk benne. Láttuk, bármely ügyfél, amely képes eltárolni a saját bérletére vonatkozó információkat, a DHCP-kiszolgáló nélkül is képes használni a bérletét, sőt az sem probléma egy darabig, ha a megújítás nem sikerül. Egy egyszerű újraindítást a felhasználók nem vesznek észre. Az is bizonyos, hogy a kiszolgáló kiesését nem ugyanakkor észlelik majd a kliensek, hanem a bérletük lejáratakor. Az alábbi ábra mutatja, hogy egy átlagos ügyfél vélhetően a bérletidő negyedénél jár (de nem zárható ki, hogy van olyan delikvens, amely már kitöltötte a saját idejét, pl. napokig nem volt bekapcsolva). 3

4 Az ügyfélszámítógépek eloszlása az eltelt bérletidő függvényében Mennyi ideig állhat egy DHCP-szolgáltatás? A hiba nem azonnal jelentkezik, hanem apránként. Előbb egy gép esik ki, majd még egy, majd egyre több. Ha a bérletidő felénél tovább áll a szerver, az ügyfelek többségét érinteni fogja. Ebből viszont az következik, hogy a bérletidő növelése a hiba eszkalálódásának sebességét csökkenti. Ha tehát csupán egyetlen szerverünk van, és vélhetően csak lassan tudjuk megjavítani a DHCP-kiszolgálót, nyugodtan növeljük meg a bérleti idő hosszát (persze még a hiba előtt), így vélhetően nagyon kevés gép esik ki, amíg a problémát elhárítjuk. Szegény ember statisztikai alapon biztosíthat magasabb rendelkezésre állást. No persze gép és gép között jelentős különbség lehet. Ha ne adj Isten épp a főnökünk gépe, vagy az ő főnökének a PC-je nem működik, nincs mérlegelési lehetőségünk, gyorsan kell cselekednünk és javítanunk. A jövőbeli fejmosások elkerülése érdekében pedig előbb-utóbb gondoskodni kell valahogyan a kiszolgáló többszörözéséről. Sokféle lehetőségünk van, kényelmesek és drágák, olcsóbbak és több beavatkozást igénylők. A kiszolgáló funkcióinak ismertetése után visszatérünk még a rendelkezésre állás kérdésére, már csak azért is, mert összetett DHCP beállításoknál nem is mindig könnyű megoldani a problémát. A DHCP rejtett szépségei II. A Windows-rendszerekben működő DHCP-kiszolgáló telepítése több, egymástól független lépésből áll. A hitelesítés buktatóinak ismertetése és az első címtartomány létrehozása után azt vizsgáljuk, milyen integrációt lehet megvalósítani a címkiosztó és a névfeloldó szolgáltatások között. A DHCP-kiszolgáló telepítése magától értetődő: a funkciót a Windows-komponensek hálózati szolgáltatásai között találjuk. A telepítéssel azonban még nem kapunk azonnal üzemkész eszközt. Ha tartományi környezetben, Active Directoryval dolgozunk, el kell végeznünk egy ún. hitelesítési eljárást, és - környezettől függően - be kell állítanunk, hogy milyen adatokat szeretnénk az ügyfelek felé közvetíteni. A DHCP hitelesítése A hitelesítés biztonsági okokból szükséges. Ha bárki telepíthet DHCP-kiszolgálót, és azt konfigurálja, könnyen előfordulhat (és a funkció megléte azt mutatja, elő is fordult), hogy helytelen paramétereket kapnak, majd furcsa, nehezen megfejthető tüneteket produkálnak a munkaállomások. Előfordul, hogy nem képesek a helyi hálózaton túli gépekkel kommunikálni (rossz az alapértelmezett átjáró paraméter), vagy már a címet is rossz tartományból veszik (nem megfelelő a scope). A gondokat megelőzendő a DHCP ellenőrzi, hogy az Active Directory számon tartja-e a neki helyet adó kiszolgálót a hitelesített DHCPszerverek listáján. Ha a megfelelő bejegyzés hiányzik, a szolgáltatás leáll, és az eseménynaplóban elhelyez egy rövid magyarázatot tartalmazó hibaüzenetet. A hitelesítést a DHCP-konzol segítségével végezhetjük el, ha tagjai vagyunk a gyökértartomány Enterprise Administrators csoportjának. Ez egy meglehetősen fontos momentum. A különböző magyarországi Windows 2000 előadásokon azt hallhattuk, hogy a mi üzleti életünkben elegendő egyetlen tartományt létrehozni. A kétségtelen előnyök (egyszerűség, átláthatóság, bizonyos bonyolult szituációk elkerülése) mellett azonban ez a szerkezet hátrányos is lehet. Egyetlen tartományban, amely egyben a gyökértartomány is, a Domain Administrators csoport tagjai bármit megtehetnek. Ha el is vesznek tőlük jogokat, azokat képesek visszaszerezni, még a restricted groups csoportházirend-trükk sem akadályozhatja őket. A problémát úgy lehet megoldani, ha az AD tervezésekor a gyökértartományt egy üres domainnek tervezzük, és alatta építjük ki a valódi adminisztrációs egységünket. A gyökér adminisztrátorainak (számbeli) korlátozásával már könnyedén elérhetjük a célunkat, nevezetesen, hogy ne végezhessen el akármilyen műveletet egy rendszergazda, csak ha erre külön 4

5 engedélyt kapott. (Technikai értelemben a hitelesítés egyetlen feltétele, hogy az AD NetServices konténeréhez teljes hozzáférési joggal rendelkezzen a felhasználó.) A fenti séma a DHCP szerverek esetén nagyon erős kontrollt jelent. Több száz telephely meglétekor is legfeljebb 2-3 hozzáértő kezében összpontosul a címkiosztó szolgáltatás engedélyezése. (Továbbá a RIS szervereké is, ahogy ez majd később látható.) Ezzel együtt a hitelesítés eljárása delegálható az AD delegációs mechanizmusán keresztül. És van élet az AD-n kívül? Igen van: Novell, Linux, sőt NT4-es DHCP-kiszolgálók nem veszik figyelembe a Windows 2000 címtár korlátozását, tehát az igazán rosszakaró tehet kárt a kontárkodástól és figyelmetlen üzemeltetőktől azonban az AD megvéd. Azt az eljárást, amely a hitelesítés meglétét ellenőrzi a Windows 2000 és 2003 szerverek rouge detection műveletnek nevezik. A kiszolgálók, amelyek az ellenőrzést végzik, eltérő módon viselkednek attól függően, hogy tagjai-e egy Active Directory tartománynak, vagy sem. Ha AD-tagok (tagkiszolgálók, vagy tartományvezérlők), egy LDAP-lekérdezést kezdeményeznek, hogy megállapítsák, tagjai-e a hitelesített kiszolgálók listájának. Igenlő válasz esetén tovább működnek, egyébként leállnak. Ha a Windows 2000 kiszolgáló nem tagja AD-tartománynak, hanem úgynevezett stand-alone, vagyis munkacsoport üzemmódban fut, vagy egy NT4 tartomány tagja, a DHCP-szerver indulásakor egy DHCP-INFORM szórt üzenetet helyez el a hálózaton. Ez az üzenettípus számos gyártóspecifikust opciót tartalmaz. A csomaggal a kiszolgáló más DHCP-szervereket keres, amelyek egy AD gyökértartományában helyezkednek el. A kért opciók alapján a megcélzott DHCP-szerverek információkat küldenek vissza a gyökértartományról. A válasz DHCPACK csomagban érkezik. Ezzel a módszerrel egy (de akár több) gyökértartományról is tudomást szerezhet az épp induló DHCP-szolgáltatás. Ha nincs AD a helyi hálózaton, a szolgáltatás elindul, de minden ötödik percben DHCP-INFORM csomagot bocsát ki, tovább kutatva a Windows 2000 címtára után. Ha már az első csomagra is érkezett válasz, minden egyes felfedezett gyökértartomány felé egy lekérdezést indít a DHCPkiszolgáló, hogy ellenőrizze, tagja-e a hitelesített szerverek csoportjának. Amennyiben egyik listán sem találja magát, a szolgáltatás leáll. Ez azt jelenti, hogy nem kell feltétlenül egy Windows 2000 szervernek tartománytagnak lennie, hogy érvényes legyen rá a hitelesített szerverek listája! Szerverkonfiguráció Miután szerencsésen átestünk a hitelesítési eljáráson, igazán nekieshetünk az érdemi konfigurációnak. Az első feladat a megfelelő scope (bérlettartomány) létrehozása. Ezt egy varázsló segíti: meg kell adnunk a kezdő- és a végső címet, amelyet a scope-on belül a szolgáltatás kioszthat, az alhálózati maszkot, a bérletidőt és a kivételeket, vagyis azokat a címeket a tartományon belül, amelyeket mégsem lehet kiosztani. Miután végeztünk, megjelenik egy scope a konzol bal oldalán. A következő ábra az általános tulajdonságokat mutatja. A legproblémásabb kérdés a bérletidő meghatározása. A rendszer hét napot ajánl fel és általában ezt el is fogadhatjuk. Számos megfontolás azonban amellett szól, hogy gondoljuk át alaposan ezt az értéket. Elméletileg a hosszabb bérletidő azt jelenti, hogy a gépek kevesebbet kommunikálnak a kiszolgálóval, vagyis nem terhelik azt. Hétnapos bérletidő esetén három és félnaponta küldenek bérletmegújítási kérelmet, míg például 28 napos bérlet esetén csak tizennégy naponta látszólag ez tiszta haszon. A scope legfontosabb adatai Csakhogy a megtakarítás egyedül a soha ki nem kapcsolt gépekre vonatkozik, mert az induló DHCP ügyfelek mindenképp kérnek címet a szervertől. A nyereség tehát csekély. Ezen még az sem segít, ha végtelenre állítanánk a bérletidőt sőt azzal csak rosszabbul járunk. A bérletidő végtelenre állítása azt jelenti ugyanis, hogy a bérletidőnek nincs fele, tehát nem kell kérni a meghosszabbítását sem. A végtelen időre kiadott cím elvész, nem használható újra. Ezért azt javaslom, hogy sohase adjunk meg végtelen hosszú bérletet! A túl rövid idő sem jó, mivel sok ügyfél esetén ez a reggeli csúcs mellett is valóban nagy forgalomhoz vezet. 5

6 A legcélszerűbb megbecsülni az ügyfelek és a kiosztható címek arányát. Ha sok ügyfélre jut relatíve kevés cím, célszerű rövid bérletet megadni (pl.: 3 nap) Ha sok címünk van és kevés ügyfelünk, a címkiosztás szólhat akár 15, vagy 30 napra is. A címtartomány kijelölésével és létrehozásával azonban még korántsem kapunk működő szolgáltatást. Egy Windowsos környezetben meg kell adnunk néhány nagyon fontos opciót (konfigurációs paramétert) is, amely az ügyfeleket eligazítja. A következő ábra egy ilyen listát mutat be. Az öt kritikus opció Windows környezetben Mindenekelőtt tudatni kell az ügyfelekkel az alapértelmezett átjáró címét az opció száma 003, és magyarul az útválasztó nevet kapta a keresztségben, ami esetleg kissé félrevezetheti a kezdő rendszergazdákat. Windows 2000 környezetben kritikus, egyébként is mind fontosabb a DNS kiszolgálók adatainak pontos beállítása. A 006 opció teszi lehetővé akár több kiszolgáló megadását is. A fontosságot a sorrend jelzi. A tartományi ügyfelek számára meg kell adni, hogy a hostnevükhöz milyen DNS suffix-et, vagyis tartományi kiegészítést biggyesszenek. Ha a gép hostneve mal-001, mostantól az ügyfél tisztában lesz a teljes nevével: mal-001.mal.priv. (Egy különös hibával találkoztam nem is olyan régen. A jelenség az volt, hogy a kliensünk mindenáron a proxy szerverünket akarta használni egy belső weblap eléréséhez is, holott nem ez volt a kívánatos. Kiderült, hogy egy elővigyázatlan kollégánk egy hibás DNS suffixet adott meg kézzel ami felülírta a DHCP beállításokat. A Helyi intranet címek esetén a proxy figyelmen kívül hagyása beállítás ezért nem működött. A paraméter törlése és egy újraindítás segített. Tanulság: semmit se konfiguráljunk az ügyfélgépeken az IP beállítások között!!) A DNS kiszolgálók mellett természetesen meg kell adni a WINS szerverek címét a 044-es opcióban. Végezetül a 046-os paraméterre is szükség van, ezzel definiáljuk, hogy a NetBIOS szabványt használó ügyfelek milyen stratégiát folytassanak a névfeloldáshoz. A legelterjedtebb a hibrid-node üzemmód, ennek a kódja a 0x8. A leírásunk keretein túlmutat a NetBIOS névfeloldási stratégiák ismertetése, de egy korábbi technet cikkben ez fellelhető, esetleg a Q as cikk tisztázza az idetartozó NetBIOS fogalmakat. (Ha ragaszkodunk a technikai részletekhez, el kell mondanunk, hogy tulajdonképpen szinte minden adat DHCP-opcióként jut el az ügyfelekhez, még akkor is, ha a kezelői felületen máshol állítottuk is be. Az alhálózati maszk a 001-es, a bérlethossz a 051-es, a megújítási idő a 058-as, ez alapértelmezetten 50%, és a címkérési idő, 059-es, amely általában 87,5%. A Windows-ügyfelek a fenti opciókon kívül mást nem vesznek figyelembe.) A DNS és a DHCP együttműködése A scope tulajdonságai közé tartozik a DNS-sel való együttműködés definiálása is. Windows 2000 és AD környezetben ez nagyon fontos paramétercsoport. Lássuk részletesen, miről van szó. Engedélyezhetjük, vagy tilthatjuk, hogy a DHCP-kiszolgáló automatikusan frissítse az ügyfelei DNS zónarekordjait. Amennyiben engedélyezzük a frissítést, választhatunk, hogy csak az ügyfél kérésére történjen a regisztráció, vagy mindenképp végezze el a DHCP-szolgáltatás. Hogyan működik mindez? A Windows 2000 és Windows XP a saját DHCPREQUEST csomagjában használ egy 81-es opciós számmal rendelkező, Fully Qualified Domain Name nevű mezőcsoportot, amelyben meghatározza, hogy a DHCP-kiszolgáló miképp regisztrálja a megfelelő rekordokat a DNS adatbázisban. Számunkra a mezőcsoport harmadik tagja érdekes, amely a következő értékeket veheti fel: 0 az ügyfél regisztrálja a saját hostrekordját. 1 az ügyfél azt szeretné, hogy a DHCP-szerver regisztrálja a hostrekordot 3 a DHCP szerver frissíti a hostrekordot az ügyfél beállításától függetlenül. 6

7 A DHCP és a DNS szolgáltatások együttműködnek, ha ez mi beállítjuk A értékek között nem található olyan, amely a PTR rekordokra vonatkozna. Azt minden esetben a DHCP-kiszolgáló jegyezteti be, kivéve, ha a DHCP-szerver nem ismeri a 81-es opciót. A Windows 2000 és XP kliensek ezt felismerik, és ők végzik rekordfrissítést a DNS-szolgáltatás megfelelő reverse lookup zónájában. A opció értékének beállítását a TCP/IP konfigurációs paneljében lehet elvégezni, még ha ez elsőre nem is tűnik fel. A titokzatos 81-es opció a kezelőfelületen A bekarikázott jelölőnégyzet bekapcsolt állapotban gondoskodik arról, hogy az ügyfél a DHCP-Request csomagban a 81-es opcióban 1-es értéket küldjön a szervernek. Vajon mikor érdemes az ügyfélre és mikor a kiszolgálóra bízni a rekordfrissítést? Nos, általában mindegy, hogy a feladatot ki végzi el. Ha azonban olyan DHCP-ügyfelünk is van, amely több hálózati kártyával is rendelkezik (multihomed), a kliensekre kell hagyni a regisztrációt épp úgy, ahogy a korábbi ábrán láthattuk. A DHCP-szolgáltatás ugyanis egy ügyfélhez csak egyetlen A rekordot jegyez be, illetve felülír minden korábbi bejegyzést, ami a többlábú gépeknél nem előnyös. Szintén nem ajánlott a DHCP-kiszolgálókra bízni a DNS-rekordfrissítést, ha a DNS csak biztonságos rekordfrissítést vár el (secure update). Ebben a szituációban a bejegyzésnek a DHCP-szolgáltatás válna a tulajdonosává, ami gondot jelenthet. Ha például egy NT4-es ügyfél DNS rekordjának bejegyzését a DHCP-szerver végzi el, majd a gépet frissítjük Windows 2000-re, az új rendszer nem lesz képes a saját rekordjának a kezelésére, mert nem ő a tulajdonosa. Hasonló helyzet alakulna ki, ha két (egymásnak tartalék) DHCP kiszolgáló közül az egyik meghibásodik. Ugyanazt a hostcímet a tartalék DHCP-szerver nem frissítheti, mert nem tulajdonosa. Summa summárum: biztonsági frissítéskor ajánlatos megfontoltan használni a DHCP és a DNS ilyen irányú integrációját. És mi történik, ha az ügyfél nem is ismeri a 81-es opciót? Ilyen kliensek a Windows NT4, Win95, Win98. Számukra is képes a regisztráció elvégzésére a DHCP, ha a zóna tulajdonságai között az utolsó jelölőnégyzetet bekapcsoljuk. Végezetül adódik a kérdés: miért van szükség a DHCP-n keresztüli dinamikus frissítésre? Miért kell a dinamikusan változó ügyfelek címét regisztrálni? Egyszerű: korábban a Microsoft ügyfeleket szórt csomagokkal, később a dinamikus regisztrációt lehetővé tévő WINS névfeloldó szerverek segítségével lehetett megtalálni. Ha egy munkaállomáson működik egy megosztott 7

8 nyomtató, arról a szolgáltatásról a WINS-adatbázis tartalmazott egy bejegyzést, a browser szolgáltatás egy erőforráslistában tárolta, s egy WINS-hez címzett névfeloldási kérelem után könnyedén fel lehetett venni a kapcsolatot azzal a bizonyos munkaállomással. A NetBIOS-szabványok eliminálásával azonban a fenti mechanizmusból semmi sem marad: nincs broadcast, sem WINS, sem browser szolgáltatás. Van viszont Active Directory az erőforrás nyilvántartására, LDAPlekérdezés a meglétének ellenőrzésére, dinamikus képességekkel felvértezett DNS a névfeloldáshoz sőt az új kliensek esetén még dinamikusan frissített DNS-bejegyzések is. A régebbi operációs rendszerek viszont mit sem tudnak az új idők új szeleiről, s ők bizony nem képesek a DNS-bejegyzés frissítésére. Ha azonban valami ezt elvégzi helyettük, a korábbi NetBIOS-funkcionalitás minden vonatkozásban megmarad, csak új szabványokkal. Egyszer talán alaposan végig kellene gondolni, hogy a különböző NetBIOS-funkciókat és szolgáltatások mi módon cserélte fel a Microsoft natúr TCP/IP megoldásokkal szigorúan ragaszkodva a meglévő RFC-khez. De ez már egy másik történet. Q NetBIOS over TCP/IP Name Resolution and WINS Q Description of How DHCP Integrates Dynamic DNS Q DHCP Server Does Not Update the A Record on the DNS Server If Option 81 Is Received with the S Bit Set A DHCP rejtett szépségei III. Előző alkalommal telepítettünk és címtartománnyal szereltünk fel egy DHCPkiszolgálót, majd elkalandoztunk a DNS- és DHCP-integráció területére. Most még egy rövid időre visszatérünk a scope-okhoz, és alaposan szemügyre vesszük, milyen részei vannak, és milyen lehetőségekkel rendelkezünk a címtartományok kiterjesztésére. A scope központi fogalom a DHCP-szolgáltatás kialakításakor. Miután a varázsló segítségével létrehoztunk egyet, érdemes alaposan megvizsgálni a kezelőfelületet, hogy lássuk, hogyan finomíthatjuk még a beállításokat. DHCP-kiszolgáló egy scope létrehozása után A címtartomány belülről A scope tulajdonságairól és a legfontosabb opciókról már értekeztünk, de a kizárt és lefoglalt címekkel (reservations), valamint a speciális scope tulajdonságokkal még nem foglalkoztunk. A fenti ábrán látható, hogy a címtartomány definiálása mellett azonnal meg kell adni azokat a címeket vagy címintervallumokat, amelyeket a teljes címtartományon belül szeretnénk kizárni a kiadható IP-címek közül. A kizárás persze nem kötelező, de néha kifejezetten hasznos. Ha például vannak állandó, statikus IP-címet igénylő kiszolgálók vagy egyéb aktív eszközök, switchek, nyomtató-szerverek, és azok címei beékelődnek egy érvényes címtartományba, a kizárás módszerével megakadályozhatjuk, hogy a DHCP-szerver egy másik ügyfél rendelkezésére bocsássa az ominózus azonosítót. Jobb helyeken, ahol ezek az eszközök eleve egy elkülönült címtartományból részesülnek, vagy lefoglalt címeket kapnak a hostok, erre külön nincs szükség. A kizárás funkció ott is használható, amikor két DHCP-szolgáltatással magasabb rendelkezésre állást szeretnénk biztosítani, de erről majd később. A kiadott címek listája Nem elhanyagolható haszonnal jár, ha szeretnénk bepillantani az épp kiadott címek listájába. Ha egy állomás MAC-címét szeretnénk megtudni, vagy csak egyáltalán az IP-címére vagyunk kíváncsiak, a kiadott címek listájának táblázatát kell átböngésznünk. A konzol információkat is szolgáltat a bérletek kiadásáról és lejárati idejéről is. Ha szükséges, törölni is lehet egy rekordot, ám ez csak nagyon körültekintő módon ajánlott. Egy cím törlése hasonló hatással van a hálózatra, mint amikor 8

9 egy bérlet véglegesen lejár, azzal a különbséggel, hogy a bérletet használó ügyfél aktív maradhat, és használhatja a címet, hisz semmiféle értesítést a rekordtörlésről nem kap. A cím ráadásul felszabadul, amit éles környezetben egy másik állomás megkaphat, ezáltal két állomás is ugyanazzal a címmel rendelkezhet. Csak akkor javaslom tehát bérlet törlését, ha az IPcímet szeretnénk felvenni a kizárt vagy a lefoglalt címek közé. Az utóbbi esetben az ügyfél oldalán mindenképp el kell végezni egy ipconfig /renew műveletet is. A lefoglalt címek listája Gyakran összekeverik a kizárt és a lefoglalt címeket, holott ez utóbbiak más célt szolgálnak. Ha szeretnénk minél több ügyfelet a DHCP-szolgáltatás kliensei között tudni, de néhány esetben bizonyosan ugyanazt az IP-címet kellene kiadnunk egy-két állomásnak, a lefoglalt címek közé kell felvennünk az ügyfél adatait, és mindkét kívánságunk teljesült. A lefoglalt címek funkció azért működik, mert a DHCP képes a címigénylő csomagból megállapítani az adott állomás hardver-címét (Ethernet hálózat esetén ez a MAC address), és ha talál ehhez a bejegyzéshez egy lefoglalt címet, azt fogja minden esetben kiajánlani. A reservations működési elvéből következik, hogy ha egy címet kizártunk, akkor az nem lehet egyben lefoglalt cím, és fordítva, a lefoglalt címeket nem szabad kizárni. Bár látszólag triviális dologról van szó, mégis nagyon gyakori konfigurációs hiba, hogy a lefoglalt címeket megpróbálják kizárni, nehogy véletlenül is más kapja meg, vagy mert a lefoglalt cím nem játszik, az másra nem használható, tehát ki kell zárni. Mindez a fogalmak pontatlan ismeretéből fakad. A három címtípus egymáshoz való viszonyát egy ábrán is megjelenítettem, hogy az olvasó már soha többé ne tartozzon az ilyen hibákat elkövetők közé. Címtartomány Lefoglalt címek Kizárt címek A címtartomány, a lefoglalt címek és a kizárt címek viszonya Visszatérve a lefoglalt címekhez: ismernünk kell, miként viselkedik a kiszolgáló, ha olyan címek közül foglalunk le egyet, amely korábban a címtartomány normál címei közé tartozott, és amelyet esetleg egy másik állomás már igénybe vett. Ilyenkor vagy meg kell várnunk a bérlet végét, vagy az adott ügyfelet rá kell szorítanunk, hogy engedje el a címet. NT/2000/XP rendszereknél az ipconfig /release paranccsal érhetjük el ezt, a Win9x világban pedig a winipcfg névre hallgató kis grafikus program siet a segítségünkre. Egyébként a bérlet kiadása szintén nem automatikus, vagyis attól, hogy a lefoglalt címet rögzítettük, még nem kapta meg azt az ügyfél. A kliensgépen kiadott ipconfig /renew parancs azonban általában meghozza gyümölcsét: a friss lefoglalt címet. A lefoglalt cím nagyon hasznos szolgáltatás. Egy hálózatban rengeteg olyan állomás működhet, amely állandó IP-címet igényel. Háromszáz munkaállomáshoz már akár féltucat switch, hálózati nyomtató, több szerver tartozhat, amelyeket mind-mind állandó címmel kell ellátni. Egy IP-cím vagy hálózati maszk-váltás rengeteg munkával jár, ha statikus címekkel dolgozunk. A manuális munka ugyanakkor mindig magában rejti a hibázás lehetőségét is. Könnyen kimaradhat egy DNS-cím vagy az idő-szerverek megadása, s máris megjósolhatatlan hibák tűnnek fel a rendszerben. A lefoglalt címekkel mindez elkerülhető, a változások bizonyosan érvényre jutnak. Hasonló módon lehet leszerelni azokat a megoldásszállítókat, akik egy monitorozó, tarifikáló vagy egyéb berendezést szállítanak, s kötik az ebet a karóhoz a statikus IP-címért. Bőven megteszi egy lefoglalt cím is. Egy tökéletes hálózatban szinte csak a WINS és DHCP-kiszolgálók rendelkeznek statikus címekkel. Műveletek a címtartománnyal Ahhoz, hogy egy scope ellássa feladatát, aktiválni kell. Csak aktív scope bocsát ki IP-bérleteket. A művelet rendkívül egyszerű, csupán a jobboldali egérgombbal kell kattintani a címtartományon, majd az aktiválást választani. A scope deaktiválásával megszűnik a korábbi funkciója. Csak nem aktív címtartományt lehet törölni. A címtartomány körül a legnagyobb felhajtás akkor keletkezik, amikor a rendelkezésre álló címek elfogynak. A bérletidő rövidítésével lehet még orvosolni a címéhséget, a hosszú távú megoldás azonban mindenképpen a scope átalakítása. Elsőre azt gondolhatnánk, hogy kényelmesen átállítjuk a címtartomány tulajdonságlapján a kezdő és a végső címet, sőt akár az alhálózati maszkot, és már készen is vagyunk. Sajnos, ez egy járhatatlan út. A szabvány szerint nem nagyon lehetne nyomon követni, hogy melyik bérletet milyen címtartomány-paraméterekkel adtuk ki. Sok kiadott cím kikerülhetne az érvényes bérletintervallumból, esetleg érvénytelen lenne az alhálózati maszk, egyszóval kavarodás lenne. Három lehetőségünk maradt a probléma megoldására: - a scope kiterjesztése - az alhálózat újrakonstruálása (resubnetting) - Superscope-ok alkalmazása (multinetting) A címtartomány kiterjesztése 9

10 A scope megváltoztatásának egyetlen járható útja a kiterjesztés. Ha az eredeti címtartomány kisebb, mint az alhálózati maszkja alapján az lehetséges lenne, akkor mód van a tartomány végső címének kitolására. Például a címtartományunkat maszkkal, kiterjeszthetjük ig mindenféle káros következmény nélkül. A kiterjesztés lehet többlépcsős is, és az alhálózat elméleti határáig tarthat. Korábban (a Windows NT 4.0 szervernél) csupán 32-esével lehetett a tartományt kiterjeszteni, vagyis 100-ról 132-re kellett volna növelni a tartomány határát. A SP6-tól kezdve ez a kötöttség már nem létezik. Amennyiben eleve belefoglaltuk a scope-ba az alhálózat engedte összes címet, ezt a módszert nem alkalmazhatjuk. Az alhálózat újrakonstruálása (resubnetting) Ha egy subnet maskot úgy alakítunk át, hogy az egyre kisebb számokat tartalmaz, akkor az alhálózatban rendelkezésre álló címek száma megnő. Nagyszerű, épp ezt szeretnénk. Csakhogy ennek komoly ára van. Az alhálózati maszk meghatározza az alhálózatot, vagyis: új maszk, új hálózat. Ezt az új hálózatot meg kell ismertetni valamennyi útválasztónkkal, át kell állítanunk az összes statikus IP-címmel rendelkező állomásunkat, továbbá el kell dobnunk a már létező scope-ot és az összes bérletet, létre kell hozni egy újat. Erre azért van szükség, mert egy scope az alhálózati maszkja alapján csak egyetlen logikai alhálózatnak szolgáltat címet, kettőnek nem. Ha sok géppel dogozunk, és nem kivitelezhető a művelet rövid idő alatt, akkor biztosítani kell a két hálózat közötti kommunikációt az alapértelmezett átjárók átkonfigurálásával. Summa summarum, az alhálózati maszk megváltoztatása hatékony ugyan, de nem sétagalopp. Superscope-ok alkalmazása A superscope a Windows NT4 SP2 verziója óta ismert fogalom, lényegében a címtartományok egybefogását jelenti. Két címtartomány alkotta superscope Ha szeretnénk egyetlen fizikai alhálózaton több logikai (IP) alhálózatot üzemeltetni, azt csupán scope-ok segítségével nem könnyű megvalósítani. A DHCP-kiszolgáló minden ügyfélnek a legelőször aktivált címtartományból hajlandó címet adni. Csupán azt tehetnénk, hogy egy második hálózati kártyát is üzembe helyeznénk, majd ellátnánk az új alhálózatból származó címmel, végül létrehoznánk a második scope-ot is. Minden további (logikai) alhálózat egy további hálózati kártyát igényelne. Ettől a barkácsolástól kímél meg minket a superscope. Tegyük fel, hogy van egy hálózatunk, ahol minden aktív eszköz egyben DHCP-ügyfél is. Szeretnénk elkülöníteni az aktív elemeket cím szerint is a munkaállomásoktól. Mivel a switchekkel csak a hálózati adminisztrátorok kommunikálnak az IPcímeken keresztül, a nem túlságosan nagy forgalom miatt az elkülönítés után nem keletkezik szűk keresztmetszet. A superscope segítségével a feladat megoldása könnyű. Először létre kell hoznunk egy címtartományt a megfelelő alhálózati maszkkal és egyéb opciókkal. Ezután el kell készíteni egy második scope-ot is, amely a /24 hálózatot foglalja magában, ám rögtön valamennyi címet ki kell zárni, az első hármat kivéve. Ez utóbbiakat mint előre lefoglalt címet kell rögzíteni a hálózati kapcsolók MAC címével együtt. Végezetül létre kell hozni egy superscope-ot, majd a két korábbi címtartományt a superscope tagjává kell tenni. 10

11 DG. IP Address1: IP Address2: DHCP-kiszolgáló Scope1: /24 Scope2: / Egy alhálózat két logikai IP-hálózattal Ezzel készen is vagyunk. A két alhálózat közötti kommunikációt az alapértelmezett átjárón felvett útvonalbejegyzés segítségével lehet biztosítani, szükség esetén szűrve az útvonalat használó állomások számát, címét. (Csak zárójelben jegyzem meg, hogy a superscope-ok nem csak a helyi hálózatokon támogatják a több logikai alhálózatot, hanem távoli routereken túli - hálózatokon is. Ezeket a képességeket a DHCP Relay Agent tárgyalásakor még érintjük. A fenti /24 jelölés a továbbiakban többször szerepel majd. Azt jelenti, hogy az alhálózati maszkban 24-db 1-es szerepel, ami decimálisan t jelent.) A superscope-ok fenti képességei hasznosak a címtartományok kiterjesztésekor. Elegendő egy második címtartományt definiálni, majd az első scope-pal egy superscope-ot alkotni, a címtartomány kiterjesztése máris megtörtént. A címtartományok összefogása az alhálózat újrakonstruálásakor is jó szolgálatot tesz. Az új alhálózat bevezetése egy superscope segítségével a legegyszerűbb. Bele kell foglalni az új és a régi címintervallumokat, a régi scope-ot pedig úgy kell módosítani, hogy valamennyi címét ki kell zárni. Az ügyfelek újraindulásakor mindegyik az új intervallumból kap majd címeket. A statikus állomások, valamint az útválasztók konfigurálását nem lehet megúszni. Superscoping, multinetting, supernetting MCP vizsgára készülő szakértő-jelöltek tapasztalhatták, hogy néhány vizsgakérdés előszeretettel próbál zavart kelteni a fenti fogalmakkal kapcsolatban a vizsgázók fejében. Az alhálózatok kialakítása és a superscope fogalmának ismeretében most megragadom az alkalmat, és amennyire lehetséges, tisztázom az egymással részben összefüggő kifejezéseket. A multinetting azt a szituációt jelenti, amikor egy fizikai alhálózaton több logikai (IP) hálózatot hozunk létre. A multinetting elméletileg nem kötődik a DHCP fogalmakhoz, így a superscope-hoz sem, elképzelhető ugyanis multinet DHCP nélkül. Gyakorlatilag azonban ilyen szituáció csak kivételes esetekben fordulhat elő, így a multinetting szinte mindig a superscope fogalmával együtt jelenik meg, hisz a superscope a multinet DHCP-támogatását takarja. A superscoping és a supernetting összehasonlításának az az alapja, hogy lényegében ugyanazt a célt szolgálja mindkét eljárás, habár teljesen eltérő módon közelítik meg a problémát. A superscoping alapvető célja a DHCP-ügyfelek által felhasználható címek számának növelése az alhálózati maszk változtatása nélkül. Ennek érdekében újabb IP-alhálózatokat alkalmaz, és egy közös superscope-ot hoz létre. A megoldás előnye, hogy viszonylag gyors és egyszerű módszer, a meglévő IP-címek nem változnak, és igénytelen megoldás, amennyiben nem szükségszerű, hogy a címtartományok egybefüggőek legyenek. A /24-hez hozzá lehet fűzni a /24-et, de akár a /24-et is. A módszer hátránya, hogy szűk keresztmetszetet hoz létre, hiszen a különböző alhálózatok között az adatforgalom az alapértelmezett átjárón keresztül áramlik, továbbá az állomásoknak nincs közös broadcast címe. A supernetting célja ugyancsak a kiosztható címek növelése, de a fenti megoldástól eltérően az alhálózati maszk változtatásával. Minél kisebb számok szerepelnek a maszkban, annál több host-cím áll rendelkezésre. A maszk 254 lehetséges állomáscímet jelent, míg a már több mint négyszer ennyit. Ha az eredeti címtartomány /24 volt, az új pedig /22, akkor a címintervallum ig bővül. A supernetting egy folytonos címtartományt eredményez, a DHCP támogatása pedig megoldható egyetlen scope-pal. Nem keletkezik szűk keresztmetszet, és van közös broadcast cím is. Hátránya a módszernek, hogy minden cím megváltozik, még akkor is, ha egy host névlegesen ugyanazt a címet kapja vissza. A /24 más jelent, mint a /22. Összegzésül azt mondhatjuk, hogy a superscoping és a supernetting ugyanazt a célt (felhasználható címek növelése) eltérő módszerekkel, előnyökkel és hátrányokkal valósítja meg. A konkrét szituáció és preferenciák határozzák meg, hogy melyik módszer a célravezetőbb. Fontosabb források és ajánlott irodalom: Q Using DHCP "Superscopes" to Serve Multiple Logical Subnets Q DHCP Client May Fail with WinNT 4.0 SP2 Multinetted DHCP Server Q Using DHCP to Assign IP Addresses to Secondary Networks Lepenye Tamás, MCSE 2000 lepenyet@mal.hu 11

12 Q DHCP Server Fails to Lease Addresses for New Scope Q Increasing the Number of IP Addresses on a Subnet A DHCP rejtett szépségei IV. Egy végső lendülettel megbirkózunk a DHCP utolsó nagy fogalomkörével, vagyis az osztályokkal és opciókkal. A cikksorozat második részében már megemlítettük a legfontosabbakat, de túlságosan nem merültünk el a részletekben. Most viszont épp ezt fogjuk tenni, hogy megértsük, milyen eszközeink vannak az ügyfelek finomhangolására, s egyáltalán: mi mindenre képes a DHCP... Az opciókról általában Az opciók lényegüket tekintve paraméterek, amelyeket az ügyfél megkap, feldolgoz vagy éppenséggel elvet. A szabványt úgy alkották meg, hogy a DHCP-csomagokban opciók tömkelege, egészen pontosan legfeljebb 312 byte (oktet) vándorolhat a kiszolgálóról a klienshez. Csoportosításukkal világos képet alkothatunk, hogy mikor kell beállítani egyet-egyet, s mikor nem. Többféle rendezés is elképzelhető. Technikai értelemben léteznek információopciók (information options) és protokollopciók (protocol options). Az információopciókat explicit módon be kell állítani, hogy érvényre jussanak. Az alábbiak mind ennek a csoportnak tagjai: 3 Router 6 DNS kiszolgáló 15 DNS domain név 44 WINS kiszolgálók 46 WINS/NetBIOS node típus 47 NetBIOS Scope ID stb. A protokollopciókat ezzel szemben csak implicit módon lehet megadni a bérlettartomány létrehozásával és konfigurálásával, vagyis egy scope létrehozása részben DHCP-opciók megadása, még ha ezt el is rejti a felhasználói felület. Az alább felsoroltak mind a protokollopciók közé tartoznak: A bérletidő megadásával az 51-es, 58-as és 59-es opciót is beállítjuk. A subnet mask opciószáma Bérletidő 53 DHCP-üzenettípus 55 Igényelt paraméterlista 12

13 58 Megújítási idő (Renewal time) 59 Címkérési idő (Rebind time) Létezik másfajta csoportosítás is, ekkor az alapvető jellemző az a hatókör, amelyben a paraméter felhasználható. Ez alapján megkülönböztethetünk: 1. Szerver avagy default global opciókat 2. Scope opciókat 3. Class opciókat, amelyek lehetnek User class és Vendor class opciók 4. Kliens opciókat, amiket lefoglalt (reserved client) opcióknak is hívnak. Mindez persze nem jelent pontos egymásba ágyazódást. A szerver-scope-client opciók még jól követhetők a konzolon is, ám a user class és a vendor class opciók a szép egymásba ágyazódást keresztülszelik, mert elvileg bárhol előfordulhatnak. A szerver, a scope és a client opciók egymásba ágyazódnak Az erősorrendet ezzel együtt nem nehéz felállítani. A leggyengébb opció-csoport a szerverhez kötődik. Ezek minden bérlettartományban érvényre jutnak, hacsak a scope-ban definiáltak felül nem írják őket. A bérlettartományhoz rendelt opciók a leggyakoribbak. Minden ügyfél megkapja őket, és amennyiben érti, fel is dolgozza azokat. Mit is jelent ez pontosan? Nos, előfordul, hogy egy ügyfél olyan paramétert is kap, amely őt nem érdekli. Például egy Windows for Workgroups 3.11-es ügyfelet egyáltalán nem foglalkoztatja a hálózatban fellelhető NIS szerverek IP-címe (Option 41), ugyanakkor egy Linux rendszer számára meghatározó információról lehet szó. A WfW be egyszerűen nem programozták bele valamennyi opció feldolgozását, így az csak a számára relevánsakat fogja megérteni. S melyek ezek? Ezt már szintén érintettük korábban, de nem árt ismételni. A Microsoft ügyfelek által használt paraméterek a következők: 01 Subnet mask 03 Router 06 DNS Servers 15 Domain Name 44 WINS/NBNS Servers 46 WINS/NBT Node Type 47 NetBIOS Scope ID 51 Lease Time 58 Renewal Time (T1) 59 Rebinding Time (T2) Inverz szedéssel jelöltem a protokollopciókat ezeket a rendszer mindenképp kiadja, ahogy azt már kicsit korábban láttuk. Visszatérve az erősorrendhez: a szerveropciókat felülírhatják a scope-opciók, azokat pedig a kliensopciók. Ezt a sort színesítik némiképp az opcióosztályok. Opcióosztályok (option classes) Az osztályokat azért hozták létre, hogy további finomításokat végezhessünk a címkiosztási rendszerünkön. Nem kötelezően, de általában a scope-on belül definiáljuk azokat a beállításokat, amelyeket egy meghatározott osztályhoz szeretnénk rendelni. Aki figyelmesen megnézi a bérlettartományhoz tartozó paraméterek részletes listáját, láthatja, hogy az oszlopok között szerepel egy vendor (szállító) és egy class (osztály) elnevezésű is. Egy hétköznapi opció, például a 15-ös szállítója standard, osztálya pedig none. Ebből az következik, hogy egy opcióhoz rendelhetünk szállítót és osztályt is, sőt akár mindkettőt egyszerre. Az alábbi ábrán látható, hogy a 002-es a Microsoft Options kategóriába tartozik, a 051-es pedig a Default Routing and Remote Access osztályba. 13

14 Szállítók és osztályok alkalmazás az opciók között Mi is a fenti konfiguráció értelme? A 002-es opció érvényre jut minden Microsoft Options szállítói kategóriába eső ügyfélnél. Melyek ezek? A Windows 98 és annál frissebb, valamint a Windows 2000 és annál frissebb MS rendszerek. Az NT4 miért nem? Mert a szabvány, amely az osztályokat és a szállítói opciókat definiálta 1997-es keltezésű, tehát az NT4 megjelenése után alkották. És honnan tudja egy Windows 2000-es ügyfél, hogy ő ebbe a szállítói kategóriába tartozik? Ezt egyszerűen tudja, mert a szállítója beleprogramozta. Bármely szállító (Pl. Xerox, Cisco, Motorola, Ericsson stb., stb.) definiálhat saját opciókat és saját szállítói osztályokat, amelyeket azután a DHCP szolgáltatás ki tud osztani a megfelelő szállítóazonosítóval rendelkező ügyfelek számára. Nézzük meg mindezt egy fiktív ám mégis lehetséges példán. Tegyük fel, hogy hálózati nyomtatók gyártására szántuk el magukat, a cég márkanevéül pedig a nem túl fantáziadús, ám jól csengő HunPrint nevet adtuk. A nyomtatónkat felkészítettük arra, hogy egy DHCP kiszolgáló segítségével távolról konfigurálni lehessen azt az időt, ami után, ha használaton kívül van a gépünk, automatikusan energiatakarékos üzemmódba (standby) vált. A nyomtató operációs rendszerébe beágyaztuk a megfelelő kódot, és tudattuk vele, hogy a HUNPRNT szállítói osztály tagja. Ezek után ezt az osztály létre kell hoznunk a DHCP kiszolgálón is. A konzolon kattintsunk a jobb egérgombbal a szerveren, majd válasszuk a Define Vendor classes pontot. A három, előre definiált osztályt láthatjuk, ezt a listát kell kiegészíteni a sajátunkkal. Szállítóosztály készítése Ezután a fenti context-menüt újra előcsalogatva definiálhatunk egy új beállítást a Set Predefinied Options funkció segítségével, sőt, még alapértelmezett értéket is adhatunk neki. Definiáltunk egy saját opciót a nyomtatóinkhoz Ha a fenti opciót kiajánljuk egy bérlettartományban, minden eszköz, amely a szállítói osztálynak tagja (vagyis a nyomtatóink), gond nélkül alkalmazni fogja. Persze mi nem fogunk nyomtatógyártásba kezdeni, de lehetséges, hogy a fenti neves gyártók egyike-másika élni fog a lehetőséggel, hogy precízebb beállításokkal lássa el a gyártmányait a DHCP szolgáltatás segítségével. A fenti példával analóg módon lehetséges user class és user class option létrehozása is, ám ekkor alkalmazhatunk egy további trükköt is. A beállításánál az Advanced fülre kattintva kiválaszthatjuk, hogy melyik szállítói osztályból szeretnénk opciót beállítani. 14

15 Előre beállított User class opció alkalmazása Az opciók többsége a DHCP standard Options szállítói osztályba tartozik. Az azonban, hogy mely user classba soroljuk, rajtunk múlik. Így lehetséges, hogy egy opciót másik user classba sorolunk, mint az alapértelmezett. Melyikbe sorolhatjuk? A Windows 2000 DHCP implementációja 3 előre definiált user classt ismer: Default user class Default remote access class Default BOOTP class Az elsőbe tartozik minden ügyfél, aki nem definiált magának user classt. A másodikba tartoznak a Microsoft ügyfelek, ha betárcsáznak, a harmadikba pedig a BOOTP ügyfelek. Ezek kívül természetesen magunk is létrehozhatunk user classt. Ha például szeretnénk, hogy minden gép, amely a humánpolitikai osztályon működik, egy alternatív alapértelmezett átjárót használjon, akkor létre kell hoznunk egy HUMAN user classt, be kell állítanunk egy 03-as opciót hozzá, végül konfigurálnunk kell valamennyi gépet a humánpolitikai osztályon. Ezt a régi ismerős ipconfig paranccsal végezhetjük el P:\>ipconfig /setclassid "Local Area Connection" human Windows IP konfiguráció Az adapter (Local Area Connection) osztályazonosítónak beállítása sikeresen megtörtént. P:\> Sajnos jelenleg egy adott host csak egyetlen user classnak lehet tagja, mivel a szabvány csak egyetlen ASCII stringet használ az ügyfelek azonosítására. Ezért ha van egy human osztályunk és egy mobil osztályunk, a mindkét osztályba tartozó gépekhez egy külön osztályt kell definiálnunk, például human-mobil néven. A szállítói és a user class közötti különbséget jól szemlélteti a fenti két példa. Bár mindkét módszer az ügyfelek szelektív konfigurálására szolgál, az egyik a gyártóspecifikus konfigurációs paraméterek továbbítására tervezték, míg a másik a rendszergazdák által valamilyen kritérium szerint felállított ad-hoc csoportok elkülönített paraméterezését segíti. Az ábrákon egyébként nem véletlenül szerepelt többször is a Default Routing and Remote Access Class. Ennek az osztálynak a segítségével elérhetjük, hogy az RRAS ügyfelek csak rövidebb ideig kapjanak DHCP címeket úgy, hogy a 051- es opció segítségével lerövidítjük a bérletidőt. Miután áttekintettük mindazt, amit az opciókról tudni érdemes, egy elméleti kérdést meg kell válaszolnunk: Vajon miért nem alkalmaz szélesebb körben opciókat a Microsoft az operációs rendszereiben? A user class azonosítókkal például LPR nyomtatókat lehetne megadni egy-egy osztálynak, vagy be lehetne állítani egy idő-kiszolgálót stb. stb. Ehelyett a világelső szoftvercég ismét letér az Internetes járt útról és csoportházirendeket fabrikál (ahol például éppúgy meg lehet már adni az alapértelmezett átjárót, a DNS szervereket, a DNS prefixet és lehetne még sorolni). A válasz kézenfekvő: a DHCP szabvány 312 bájtnyi adatot (paramétert) továbbíthat. Ez bizony egy tisztességes házirendhez kevés. Ráadásul bonyolult adatstruktúrák sem közvetíthetők a DHCP segítségével. A testreszabhatósága, az ügyfelek megkülönböztetése sem túlságosan kifinomult (pl. az Active Directoryhoz képest.) Summa summára: a csoportházirendnek van helye a nap alatt. És akkor hosszútávon DHCP-re nem lesz szükség? Hát, hosszú távon ott van ugye az IPv6, ami sokkal inkább képes konfigurálni magát, mint az IPv4, tehát a DHCP súlya valamennyire csökken majd. Az IPv4 világban azonban várhatóan mindig is megmarad, mert az eredeti funkciójára, vagyis az IP címek kiosztására továbbra is ez a legalkalmasabb módszer. Ami pedig a Microsoft ügyfélrendszereket illeti, egyre több DHCP-opciót fogadnak el, s mire beköszönt az IPv6-korszak, talán mindet ismerni fogják de addigra kihal a DHCP. Szerveroldalon ugyanakkor várható, hogy az újabb verziók követni fogják a DHCP szabványok változását, hiszen nemcsak Microsoft ügyfeleket kell kiszolgálniuk, s más rendszerek esetén ha nincs házirend marad a DHCP. Lepenye Tamás, MCSE 2000 lepenyet@mal.hu 15

16 Felhasznált és ajánlott irodalom Q How to Create a New DHCP User or Vendor Class Q DHCP Server Handles the Global User Class Lease Option Incorrectly Q Microsoft DHCP Vendor and User Classes Windows 2000 Resource Kit TCP/IP Core Networking Guide A DHCP rejtett szépségei V. A címkiosztó szolgáltatás üzembehelyezésekor különösen fontos jól megválasztani a helyszínt. Egyszerű környezetben, ha nincs is több telephely, ez nem probléma, ma azonban már egyre több összetett hálózat működik. Lehet a topológia bármilyen bonyolult, a DHCP szervereknek megfelelően kell működniük. Az egyszerű nagyszerű? Tudjuk már, hogy a DHCP-rendszerek a szórt üzenetekre építenek. Nincs is más lehetőségük, hiszen a minden információáramlás alapját jelentő egyedi IP-cím kiosztása a feladatuk. Egy kommunikációképtelen ügyféllel kommunikálnak, s végül alkalmassá teszik őket az adatcserére. A szórt üzenetek azonban a helyi hálózat foglyai, az útválasztók nem engedik át a broadcast csomagokat ezáltal csökkentve a WAN vonalak és a többi LAN terhelését. A fenti két állításból az következik, hogy minden DHCP-kiszolgáló a saját LAN-jának csapdájában kellene vergődnie, s bár helyben nagyszerű, távoli hatása nincs. A huszáros megoldás, amely a hálózat aktív tagjaivá teszi az állomásokat, csődöt mond, ha ki kellene terjeszteni. Hacsak nincs a tarsolyban egy újabb trükk. Nos, van ilyen. A DHCP továbbító ügynökök (Relay Agent) A Windows NT4, Windows 2000 és Windows 2003 rendszereknek van egy speciális, a DHCP-szervereket támogató szolgáltatása, ezek a továbbító ügynökök. Az NT4-ben még külön szolgáltatásként telepíthető (gyakran összekeverték a DHCP kiszolgálóval és telepítették is), a Windows 2000-ben az RRAS szolgáltatás része. A továbbító ügynök az RRAS szolgáltatás egyik funkciója Egy továbbító ügynök feladata borzasztóan egyszerű: elkapja a helyi hálózatban kószáló DHCP-kiszolgálóknak szánt csomagokat, majd azokat a beállításai szerint egy vagy több más alhálózaton működő DHCP szerver felé továbbítja. Egyből érthető a trükk: a szórt üzenetek az ügynök kezei közt egyszerű unicast csomagokká válnak, így könnyedén, akár több útválasztón is áthaladhatnak. Mindezt azért tudja megtenni a Relay Agent, mert a DHCP szabvány, egészen pontosan az RFC 1542, a DHCP csomagban definiál egy Relay IP Address mezőt (Ezt ismerik úgy is, mint Gateway IP Address, vagy GIADDR). Az ügynök ide írja bele a saját címét, ettől egy csapásra minden DHCP kiszolgáló unicast csomagokkal kezd el kommunikálni vele. A DHCP szerver az ügynök kérését kiértékeli, méghozzá az IP-címe alapján. Azt vizsgálja, hogy az IPcímhez, amelyről a kérés érkezett, tartozik-e egy scope. Ha például az ügynök címe /16, van-e olyan bérlettartomány a szerveren, amelynek akár ez a cím is tagja lehetne. Ha igen, a szolgáltatás kiad egy bérletet. A megérkező válaszokat úgy küldi tovább a Relay Agent az ügyfeleknek, mintha csak egy valódi címkezelő lenne. 16

17 Az egyszerű működéséhez egyszerű konfigurálás tartozik. A beállítás csupán négy paramétert érint. Meg kell adnunk azt az interfészt (hálózati kártyát), amelyre a szolgáltatás működni kezd, és fel kell sorolnunk azokat a DHCP-kiszolgálókat, amelyeket az ügynök értesít, ha helyi címkérelmet fog el. Az ügynökkonfigurálás nem ördöngösség Ezen felül meg lehet változtatnunk az un. Hop-count threshold értéket. A paraméternek igazi jelentősége nincs. Tulajdonképpen az IP csomag TTL értékéhez hasonló mezőről van szó, de attól külön kezelik. Azt jelenti, hogy maximum ennyi Relay Agenten keresztül jöhet a csomag. Azért nincs a gyakorlatban jelentősége, mert bár a szabvány szerint egy ügynök az elkapott címet broadcast, multicast vagy unicast címre továbbíthatja, és így elméletileg elképzelhető, hogy több Agentnél is megfordul a DHCP-Discover csomag, gyakorlatilag kizárólag unicast címeket használnak az ügynökök, közvetlenül a kiszolgálókat megcímezve, tehát szinte sohasem kap ez a mező 1-nél magasabb értéket. A Boot threshold paraméter már hasznosabb. Ennek segítségével két külön hálózatban lévő DHCP kiszolgálót (egyéb konfigurációs trükkök mellett) egymás tartalékává tehetjük méghozzá úgy, hogy a helyi kiszolgáló lesz a preferált. A boot thresholdban meghatározott másodpercig vár ugyanis az ügynök, mielőtt továbbítaná az üzenetet a (távoli) kiszolgálónak. Amennyiben van helyi DHCP szerverünk, és az ügynököt csak arra használjuk, hogy a távoli kiszolgálót, mint tartalékot elérje, a négy másodperc bőven elegendő a helyi címkiosztónak az IP-cím allokálásához, tehát a kívánatos rendszert használták az ügyfelek. Amennyiben a helyi DHCP-kiszolgáló nem működik, az ügynök elvégzi a rábízott munkát és továbbítja a tartalék rendszer felé a kérelmeket. A DHCP rendelkezésre állásának növelését szolgáló technikák ismertetésekor erre a felépítésre még visszatérünk. A hálózat-topológia és a DHCP Most, hogy az ügynökökkel a címkiosztó szolgáltatás olyan, akár a börtönéből szabadult sas, nézzük sorra a kiszolgálók elhelyezésének alapeseteit. Szeretném előrebocsátani, hogy az alábbiaknál sokkal bonyolultabb elrendezések is léteznek, amelyeket később majd tárgyalunk is, most csak a leglényegesebbeket tekintjük át. A teljesen egyértelmű környezet, amikor nincs is útválasztónk, csupán egy LAN-unk, rajta ügyfelek és egyetlen DHCPszerver. Elegendő egyetlen scope, habár korábban láthattuk, hogy nem lehetetlen több cím-intervallum használata sem. A kályha: egy DHCP kiszolgáló, egy alhálózat Az előző esetnél egy icipicit bonyolultabb, amikor több LAN-t egy útválasztó köt össze. Ekkor a távolabbi helyi hálózat ügyfelei csak akkor kaphatnak IP-címet, ha a router maga futtat egy DHCP továbbító ügynöki funkciót. Ma már az útválasztók többsége képes erre csupán annyit kell tennünk, hogy a megfelelő beállításokat elvégezzük. Egy címkiosztó szerver több alhálózattal 17

18 A fenti ábrán látható konfiguráció azonban sok esetben csak illúzió. Először is ritka eset, amikor egy helyi hálózatot egyetlen router választ el egy másiktól. Egyetemi hálózatokon, egy-egy nagyobb város hálózatában elképzelhető, ezzel együtt nem jellemző. Másrészt a topológia azt feltételezi, hogy az útválasztó konfigurálása a kisujjunkban van. Kis magyar valóságunk nem ilyen. Ha vannak routerek, azt többnyire a külső szállító felügyeli (sokszor ő is birtokolja). Ha a címkiosztást ilyen körülmények között a magunk kezében akarjuk tudni, úgy szükségünk lesz egy saját továbbító ügynökre. Ekkor már mindegy, hogy hány eszköz választja el egymástól a helyi hálózatokat, s hogy azok milyen messze vannak egymástól. A következő ábra modellezi azt a szituációt, amelyben a leginkább elkél a továbbító ügynök. Könnyű elképzelni, hogy a bal oldali hálózatához, a központhoz, több olyan LAN kapcsolódik, mint a jobb oldalon látható, vagyis egyetlen DHCP szolgáltatást akár több tucat telephelyet is elláthat. Továbbító ügynökök kérdése az egész. Ha nem mi felügyeljük az útválasztókat A skálázhatóságról csak annyit, hogy a Microsoft ajánlása szerint ne rakjunk egy DHCP-kiszolgálóra 1000-nél (!) több bérlettartományt. Összesen pedig ne legyen több, mint ügyfele egy szervernek. Ha valaki takarékoskodni szeretne a címkiosztó szerverekkel, akár a legnagyobb kiterjedésű magyar LAN is néhány szerverrel elüzemel. Ugye, hogy börtönéből szabadult a DHCP? A továbbító ügynöknek még egy nagyon fontos szerep jut, ugyanis a betárcsázáskor is hárul reá feladat. Ezt a szituációt ábrázolja a következő kép. Betárcsázás és DHCP Ahhoz, hogy megértsük, milyen szerepe van a Relay Agent-nek, meg kell vizsgálnunk az RRAS és a DHCP viszonyát. Látni fogjuk, hogy nemcsak a továbbító ügynök tetszeleg néha a DHCP tulajdonságaival, hanem az RRAS is. A Routing And Remote Access ahogyan a nevében is mutatja, többek között útválasztással és betárcsázással kapcsolatos szolgáltatásokat nyújt. Amikor egy távoli, telefonos kapcsolattal rendelkező ügyfél betárcsáz, tulajdonképpen egy útválasztó kel életre, amelynek egyik lába egy hálózati kártya, a másik pedig egy modem. A DHCP úgy kerül a képbe, hogy az RRASnak valamilyen módon gondoskodnia kell a távoli számítógép modemes lábának IP-címmel való ellátásáról. Többféle lehetőség is létezik. Elvileg beállítható kézzel egy IP-cím a kliensnél, még egy modemes kapcsolathoz is. Na de a dinamikus címek korában? És ha egy másik hálózathoz szeretnék csatlakozni? Vagy egy nagy hálózat másik alhálózatán keresztül lépek be? A statikus cím nem igazán járható. Egy másik megoldás lehet(ne), ha a felhasználó kap egy IP-címet. Ezt megadhatjuk az ADUC felületén keresztül, de az eredmény hasonló lenne az előzőekhez. Kénytelenek leszünk az RRAS-ra bízni a cím átadását. Ekkor kezd egy router DHCP tollakkal ékeskedni. Az RRAS kiszolgáló tulajdonságai párbeszédpanelen egy külön fül foglalkozik az IP-címek kezelésével. Íme, az alábbi képre gondolok. 18

19 Az RRAS-t és a DHCP-t ezen a panelon lőhetjük össze A cím kiosztására két lehetőség is adott. A legegyszerűbb, ha mindent az alapértelmezett értéken hagyunk. Ekkor az RRAS címeket kér (előre) a DHCP kiszolgálótól, méghozzá 10 darabot. Egyet lefoglal magának, a többit pedig szükség szerint kiosztja a betárcsázó ügyfeleknek. Ha mind a tíz cím elfogyna, akkor kér újabb tizet és így tovább. Az alábbi címen egyébként a kikért címek száma módosítható: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\RemoteAccess\Parameters\Ip\InitialAddressPoolSize A címkérés az RRAS indulásakor történik. Amennyiben ekkor nem érhető el DHCP szolgáltatás, az RRAS az APIPA által meghatározott címek közül oszt ki majd az ügyfeleknek. Ha valaki x.x címeket lát, és azt panaszolja, hogy nem tudja elérni a belső hálózatot, az gyanakodjon a DHCP és az RRAS közötti kommunikációs zavarra, és legalább egyszer indítsa újra a betárcsázó szolgáltatást úgy, hogy meggyőződött a DHCP helyes működéséről. A fenti ábrán az is látható, hogy meghatározhatjuk azt az adaptert, ahonnan a RAS a különböző opciókat veszi. Ez kérem itt egy csapda. Az igaz, hogy az RRAS címeket kér a címkiszolgálótól. Egyéb opciókat azonban nem kér! A most emlegetett sor tehát azt mutatja meg, hogy az RRAS melyik hálózati kártyájának beállítását veszik át majd a betárcsázó ügyfelek. Az első és legfontosabb dolog tehát a RRAS LAN kártyájának nagyon korrekt beállítása. Egy rövid táblázat arról, milyen IP konfigurációs értéket honnan vesz az RRAS Opció IP address WINS server DNS server Subnet mask NetBIOS scope ID Node type Forrás DHCP kiszolgálótól az RRAS-on keresztül RRAS LAN adapter beállítása RRAS LAN adapter beállítása Az IP-cím alapján, automatikusan Class A,B vagy C subnetet kap az ügyfél Nem továbbítódik Ha az RRAS-nak nincs WINS szervere, akkor a kliens b-node lesz, egyébként h-node a kapcsolat ideje alatt. No és a korábban emlegetett DHCP RRAS opciókat sem küldi át az RRAS? Nem, azokkal sem foglalkozik. Viszont az ügyfelek a kapcsolat létrejötte után küldhetnek egy DHCPINFORM csomagot, amelyben a megfelelő opciókat kérik. Itt jön a továbbító ügynök újabb feladata. Amennyiben az IP-címeket DHCP kiszolgálótól kapta az RRAS is, az ügynök automatikusan továbbítja az ügyfelek csomagjait ennek a címkiosztónak. Ha viszont statikus címlistával dolgoztunk az RRAS-on, akkor csak abban az esetben működik a továbbítás, ha az ügynököt külön konfiguráltuk, vagyis megmondtuk, hogy mely címkiosztó rendszerrel vegye fel a kapcsolatot. A betárcsázó ügyfelek persze mit sem tudnak arról, hogy a címeket nem közvetlenül egy címkiosztó szervertől kapták. Számukra csak az a lényeges, hogy megkapják a hőn áhított IP-címet, hozzá a megfelelő paramétereket és végre kommunikálhassanak. Nekünk rendszergazdáknak azonban nem árt tisztában lennünk, hogy ez a többnyire problémamentes összekapcsolódás valójában igencsak összetett és kacifántos módon jön létre. 19

20 Lepenye Tamás, MCSE 2000 Felhasznált és ajánlott irodalom Windows 2000 Server Internetworking Guide Chapter 3: IP Unicast Chapter 7: Remote Access Server Windows 2000 TCP/IP Core Networking Guide Windows 2000 Help RRAS Windows 2000 Help DHCP A DHCP rejtett szépségei VI. Azt már korábban is láthattuk, hogy a DHCP szolgáltatás nem áll önmagában, számos más komponenssel együttműködik. A DNS, az Active Directory, az RRAS és a DHCP viszonyát már tisztáztuk. A címkiosztó szerver azonban egyéb funkciókkal is szorosan integrált, sőt néha saját maga tartalmazza ezeket az alkalmazásokat. Ezúttal a BOOTP, a MADCAP, a RIS és a DHCP közti összefüggéseket vizsgáljuk. BOOTP a félig lenyelt előd A DHCP szolgáltatás nem volt előzmények nélküli, isteni fejből kipattant szikra ben Bill Croft a Stanford egyetemről és John Gilmore a Sun Microsystemtől készítettek egy szabványtervet, amely RFC 951-es számmal és Bootstrap Protocol (BOOTP) címmel vonult be a történelembe. Az ő megoldásuk sok tekintetben hasonlóan működött, mint a mai DHCP kiszolgálók, bár nem pontosan ugyanúgy. Az eltérések az alkotók indítékaiból, az előttük álló feladatokból fakadtak. A fenti két úriember a lemez nélküli munkaállomások elindulási folyamatát szerette volna automatizálni. Így a BOOTP szabvány egy kétfázisú indítást definiált. (Az RFC az elsőt írta le részletesen.) Az első fázisban a munkaállomások UDP 67 (szerver) és UDP 68 (kliens) portokon keresztül kommunikálnak. A szerver egy IP címet biztosít a lemez nélküli gépnek, továbbá néhány paramétert, amelyet ők gyártói kiegészítéseknek (vendor extensions) neveztek. Azt az információt, hogy a munkaállomás melyik kiszolgálóról, milyen nevű boot állományt tölthet le az induláshoz szintén a BOOTP kiszolgáló adja meg. A második fázisban a lemez nélküli rendszer TFTP protokollon keresztül felveszi a kapcsolatot a korábban megadott szerverrel, lemásolja a boot állományt, majd azt betöltve elindítja a szükséges operációs rendszert. Tulajdonképpen az RFC szerzői oldották meg a tyúk-tojás problémát, amit mi korábban paradoxonként emlegettünk, vagyis ők javasolták a szórt üzenetek alkalmazását. Láthatjuk, hogy az első fázis igen-igen hasonlít a DHCP működési elveihez. Központi címkezelésről van szó mindkét esetben, ugyanazokat az UDP kapukat használják a BOOTP és DHCP kiszolgálók, kliensek, továbbá az üzenetváltásnál a csomagszerkezet is megegyezik, egy kivételtől eltekintve: a BOOTP csomagok csak 64 oktetnyi helyet biztosítanak a gyártói kiegészítéseknek, míg a DHCP 312 oktetet értelmez, amelyben a különböző opciók utaznak. (A két fogalom opció és gyártói kiegészítés - gyakorlatilag ugyanazt takarja.) Ezek a hasonlóságok arra késztették a DHCP kiszolgálót megalkotó programozókat, hogy lehetővé tegyék a BOOTP ügyfelek támogatását. A Microsoft a Windows NT 4.0 SP2 óta támogatja az idősebb testvér klienseit. A hasonlóságok mellett szólni kell a meglévő különbségekről is. Jó kiindulási alap a szállítói kiegészítések felsorolása. Kód Leírás 1 Subnet Mask 3 Router 4 Time Server 5 Name Server 9 LPR Server 12 Computer Name 15 Domain Name 17 Root Path 20

21 42 NTP Servers 44 WINS Server 45 NetBIOS over TCP/IP Datagram Distribution Server 46 NetBIOS over TCP/IP Node Type 47 NetBIOS over TCP/IP Scope 48 X Window System Font Server 49 X Window System Display Manager 69 SMTP Server 70 POP3 Server A fenti lista lényegesen rövidebb, mint a DHCP opciók teljes táblázata, ráadásul néhány nagyon fontos paraméter is hiányzik. Nincs sehol szó bérletidőről (51-es opció) megújítási időről (renewal time, 58-as opció, rebind time 59-es opció). Ezek szerint egy BOOTP kliens nem újítja meg a bérletét? Nos, nem újítja meg, mivel az IP cím kérését nem bérletviszonynak fogja fel. S íme, ez a legnagyobb különbség egy DHCP és egy BOOTP ügyfél között. Egy BOOTP kliens kér ugyan IP címet a rendszerinduláskor, s minden újabb induláskor is, ám onnantól a címet saját magáénak érzi. Nincs további kapcsolata a BOOTP kiszolgálóval! Hogyan lehet így címeket kezelni? Hiszen az egyszer kiadott címről azután már nem rendelkezhetünk, nem vonhatjuk vissza. A BOOTP világ másképp működik, mint a DHCP. A címek kiadása ugyanis a szabvány szerint egy táblázat alapján történik, amelyben előzőleg rögzítik a leendő ügyfél azonosító adatait, többek között a MAC címét is. Ha analógiát keresünk, a DHCP lefoglalt címeihez hasonlíthatjuk az eljárást a bérletidőtől eltekintve. Vagyis szó sincs ellenőrizetlen folyamatokról, épp ellenkezőleg. A BOOTP világ nem is kaphat címet olyan állomás, amelyről a rendszergazda nem tud. Kizárólag a BOOTP táblázatba felvett hostok nyernek bebocsátást a hálózatba. No persze ez nem is olyan kényelmes megoldás, mint a DHCP, mivel előzetesen be kell gyűjteni legalább a MAC címeket, a boot állományneveket, a TFTP szerver címeket, kézzel frissíteni a táblát stb., stb. Mai szemmel nézve meglehetősen fura, a szabvány megalkotásakor azonban még nem kellett naponta tucatjával telepíteni és kivonni gépeket a hálózatból, vagyis a fenti megoldás is kielégítő volt. Arról nem beszélve, hogy a DHCP-hez képest a BOOTP világ még biztonságosabbnak is tekinthető, hiszen kizárólag a rendszergazdák explicit engedélye után kaphat egy host címet, ami azért erőteljesebb kontroll, mint egy scope aktiválása. A DHCP biztonságáról azonban később még lesz szó, most nézzük, hogyan is fest a konkrét BOOTP implementáció. A Windows NT 4.0-ban a támogatás azt jelentette, hogy a szerver elfogadta a BOOTP csomagokat, majd a lefoglalt címeket (reserved addresses) kezdte el vizsgálni. Amennyiben talált olyan MAC-címet, amely a csomagban szereplő ügyféllel megegyezett, a bérletet kiosztotta. Amikor tehát korábban a lefoglalt címek működéséhez hasonlítottuk a BOOTP megoldásait, egyáltalán nem jártunk távol az igazságtól, mert a DHCP BOOTP emulációja épp ezt a lehetőséget használja ki. A Windows 2000-ben továbbfejlesztették a BOOTP támogatást, és a fenti megoldás megtartása mellett bevezették a dinamikus BOOTP ügyfelek fogalmát. Ez azt jelenti, hogy már nem kell a lefoglalt címek közé felvenni előre a BOOTP ügyfeleket, azok éppen úgy egy aktív bérlettartományból kapnak címet, mint a közönséges ügyfelek. Csupán két dologra kell figyelni. A bérlettartomány tulajdonságai párbeszédpanelen az Advanced lapon engedélyezni kell a BOOTP ügyfelek dinamikus kiszolgálását, továbbá meg kell határozni, hogy mennyi időre kapják meg kiadott IP-címet. A BOOTP ügyfeleknek 30 napra szól az alapértelmezett bérlet A 30 napos bérletidő eléggé veszélyes dolog. Attól, hogy egy DHCP kiszolgáló DHCP ügyfélként szeretné kezelni a BOOTP klienseket, a szabvány még nem változik meg. Márpedig a BOOTP ügyfelek nem fogják megújítani a bérletüket. Ha tehát 30 napon túl sem indítjuk újra őket, a DHCP kiszolgáló másnak is kiadhatja a címüket. Bölcs rendszergazda tehát ezt az értéket legalább 100 napra, vagy még inkább 365 napra módosítja. Manapság ugyanis a BOOTP ügyfelek eléggé sokáig képesek 21

22 üzemelni egyhuzamban. A dinamikus támogatásnak van még egy fontos feltétele: az ügyfelek csak IP címet kérjenek. Ha szükségük van a boot állomány nevére, TFTP szerver címére stb., akkor a dinamikus BOOTP ügyfél mint megoldás nem jöhet szóba. Valamilyen módon ugyanis hozzá kell rendelni a fenti adatokat is a klienshez. Marad a korábban felvillantott reserved address alapú megoldás. Felvesszük a BOOTP ügyfeleket a lefoglalt címek közé megadva a MAC címét, nevét stb. és bejelölve, hogy BOOTP kérés érkezik majd. Ezután be kell állítani két speciális opciót, a 66 és 67 számút. Az első TFTP kiszolgáló nevét, a második a bootfájl nevét tartalmazza. Végül a szerver tulajdonságai lapon bekapcsolhatjuk a BOOTP tábla mappát. Ha ezt megtettük, lehetőségünk van három adattal ellátni a BOOTP ügyfeleket. Az első és a harmadik már ismerős, itt azonban megadhatjuk még a teljes elérési utat is a boot állományhoz. A klienshez felvett értékek alapján a tábla bejegyzéshez egyértelműen hozzárendelhető a BOOTP ügyfél is. Ugye nem bonyolult? A Windows 2000 ennél tovább nem megy. A súgóban azt a fura mondatot olvashatjuk, hogy a TFTP szervernek egy harmadik gyártótól kell származnia, mert a Windows 2000 nem rendelkezik ilyen kiszolgálóval. A BOOTP szabványt követő párbeszédpanel A fenti állítás egy kicsit sántít, hiszen a RIS kiszolgálóhoz dukál egy TFTP is. A pontos megfogalmazás tehát az lehetne, hogy a Windows 2000-et nem szállították olyan TFTP kiszolgálóval, amely a BOOTP ügyfeleket is kiszolgálná. (Kár, hiszen a PXE kliensek nagyon közeli rokonai a BOOTP-t használó állomásoknak.) A BOOTP szolgáltatásról összességében annyit mondhatunk, hogy a szabvány hű követése, ám nem teljes megoldás. Amennyiben azonban az IP-cím kiosztást tekintjük feladatnak, úgy a DHCP kiszolgáló megfelelő támogatást nyújt a BOOTP ügyfeleknek is. MADCAP Ha a BOOTP szabvány a múlt, akkor a Multicast Address Dynamic Client Allocation Protocol (MADCAP) egy kicsit talán a jövő. Nem azért, mintha a multicast szabvány nem lenne legalább olyan idős, mint némely mai középiskolás (1986-ban jelent meg az RFC 988, amelyben először definiálták), hanem inkább azért, mert a rá épülő alkalmazások, mint a videókonferencia, azonnali üzenetküldés, e-learning megoldások, stb. még csak most kezdik meg hódító útjukat. A MADCAP megértéséhez minimális szinten érteni kell a multicast világot is. Az már közismert, hogy a gépeknek egyedi IP címmel kell rendelkezniük, amelyek A, B, C osztályba sorolhatók, esetleg osztály nélküliek. Léteznek azonban D osztályú címek is, ezeket onnan lehet felismerni, hogy a IP cím első négy bitje 1110, vagyis egy multicast cím a és tartományba esik. A multicast címekre a következő szabályok vonatkoznak: 1. Egy állomásnak rendelkeznie kell legalább egy unicast címmel, mielőtt egy multicast címet kap. 2. Egy multicast címet több állomás is megkaphat tulajdonképpen ez az értelme. Egyedi címeknél ez tilos. A szabvány szerint az azonos multicast címmel rendelkező állomások halmazát nevezik multicast csoportnak, amelynek nulla vagy annál több tagja lehet. Egy csoport nem csak egy logikai alhálózatból fogadhat tagokat, és a hálózat tudja, hogy mely állomások tagok, és azok hol helyezkednek el. A csoport dinamikusan változhat. Bármely állomás bármikor csatlakozhat, vagy elhagyhatja a csoportot. (Ennél mélyebbre nem megyünk, habár a téma izgalmas.) 3. Egy állomásnak több multicast címe is lehet egyidejűleg. Tudni kell még, hogy bizonyos címek foglaltak, vagy speciális tulajdonságokkal bírnak. Néhány példa: 1. A címek csak a helyi alhálózaton érvényesek, az útválasztók semmiképp sem továbbítják őket. 2. A címtartomány olyan alkalmazások számára van fenntartva, amelyek elérhetőségét (vagy inkább sugárzási távolságát ) szabályozni lehet. 3. A fenti címtartományon belül a alhálózati maszkkal nagyjából hasonló szerepet játszik a multicast világban, mint a /8 az unicast forgalomnál. Belső használatra ajánlott címtartomány, ideális a MADCAP kiszolgálók számára. Ez a címtartomány címet jelent, ami óriási szám, ha meggondoljuk, hogy egyetlen címet akár több ezer állomás is használhat minden állomás a helyi hálózaton minden útválasztó a helyi hálózaton OSFPv2 útválasztók a hálózatban OSFPv2 útválasztók a hálózatban RIPv2 22

23 Network Time Protocol A szabadon felhasználható multicast-ra épülő alkalmazások számára, legyenek akár az Interneten is. Persze a címeket ugyanúgy meg kell igényelni, de talán itt nincs olyan címéhség, mint az egyedi címek esetében. Fontos tisztázni, hogy a multicast címek függetlenek az egyedi IP azonosítóktól, tehát a MADCAP szerver sem függ a DHCP címtartományok meglététől. Ha egy kiszolgálón csak multicast bérlettartomány található, akkor azt MADCAP szervernek mondjuk. Ám később itt is éppúgy lehet normális scope-okat létrehozni, jól megférnek egymás mellett. Az sem szükséges, hogy az ügyfél unicast címe egy DHCP kiszolgálótól származzon és fordítva: egy DHCP ügyfél nem csak a MADCAP által adott multicast címmel kapcsolódhat olyan csoporthoz, amely többi tagja viszont MADCAP ügyfél. A MADCAP kezelőfelülete Egy multicast címtartomány létrehozása épp olyan könnyű, mint egy közönséges bérlettartományé, sőt, ha lehet, még egyszerűbb. A MADCAP kiszolgálók ugyanis szinte kizárólag címtartományokat definiálnak, opciókat azonban nem ennyivel egyszerűbb az élet. A varázsló, amely a scope-ot létrehozza, csupán a címtartomány nevét, kezdő- és végcímét, a kizárt címeket és a bérletidőt kérdezi meg. Mindezt azonban később is beállíthatjuk a scope tulajdonságai között, ahogy a következő ábra mutatja. A multicast címtartományokkal nem bánik olyan finnyásan a kiszolgáló. A tulajdonságok lapon könnyedén módosíthatjuk a kezdő és végső címet is, ha ez szükséges. Külön említést igényel a TTL érték. Az útválasztók számát jelenti, amelyeken még áthaladhat a multicast forgalom. Ez egyszerűen szabályozza, hogy milyen messziről érhető el az adott multicast alkalmazás (pl. egy e-learning tanfolyam). Egyszerűen konfigurálható multicast címtartomány A multicast világnak van egy különös sajátossága, az illékonyság. Egy videokonferencia záros időn belül véget ér, akárcsak egy tanfolyam, vagy egy élő közvetítés. A címeket hipp-hopp elhagyják a munkaállomások, sőt akár az egész címtartomány is feleslegessé válhat. A Windows 2000 készítői számoltak ezzel a szituációval. A multicast bérlettartomány tulajdonságai között a második lapon beállíthatjuk, hogy a scope meddig éljen, szakszóval: mikor járjon le. Ha eljött az idő, üt a scope órája. Elillan, mintha sohasem lett volna. Amilyen összetett és bonyolult tud lenni egy multicast forgalmat lebonyolító hálózat, olyan egyszerű a MADCAP életre keltése ez most kiderült. Egy valamit azonban érdemes fejben tartani: a MADCAP csupán egy eleme a hálózatnak, amely a fenti alkalmazásokat biztosítja. Szükséges, de nem elégséges feltétele multicast alkalmazások bevezetésének. Nem kerülhető el az útválasztók alapos felülvizsgálata és alkalmassá tétele e speciális forgalom lebonyolítására. A DHCP és a RIS Még 2001 végén indult e lap hasábjain egy öt részből álló sorozat, amelynek keretében az Olvasó részletekbe menően megismerkedhetett a RIS, vagyis a Remote Installation Services rejtelmeivel. Most csak röviden szólunk a RIS és a DHCP kapcsolatáról. A RIS és a DHCP között néha rejtélyes kapcsolat van. Először is minden RIS szervert fel kell venni az Active Directory hitelesített DHCP kiszolgálóinak listájára. Vagyis a Windows 2000 bizonyos szempontból a DHCP kiszolgálókhoz hasonlóan bánik az automatikus szoftverdisztribúciós feladatokat végző RIS szerverekkel. Miért is? A RIS kiszolgálók feladata a PXE ügyfelek kiszolgálása, s csodálatos módon a PXE ügyfelek DHCP csomagok segítségével kommunikálnak a RIS szerverekkel. Ezért szükséges a hitelesítés. Lássuk a tényleges forgalmat. Feltételezzük, hogy mind a DHCP, mind a RIS kiszolgáló az PXE klienssel azonos alhálózatban van. 23

24 1. A PXE ügyfél kibocsát egy DHCP-DISCOVER csomagot, amelyben IP címet és PXE boot szerver címet kér. 2. DHCP-OFFER csomag érkezik a DHCP kiszolgálótól egy IP címmel. 3. DHCP-OFFER csomag érkezik a RIS kiszolgáló BINLSVC komponensétől a PXE szerver címmel. 4. A PXE kliens DHCP-REQUEST csomagot küld a DHCP szervernek, IP címet kér. 5. A DHCP kiszolgáló DHCP-ACK csomaggal nyugtázza a kérelmet. 6. A PXE ügyfél egy újabb DHCP-DISCOVER csomagot bocsát ki. 7. DHCP-OFFER csomag érkezik a DHCP kiszolgálótól az előző IP címmel. 8. DHCP-OFFER csomag érkezik a RIS (BINLSVC) kiszolgálótól a PXE szerver címmel. 9. A PXE kliens DHCP-REQUEST csomagot küld a RIS szervernek, és a PXE boot szerver címét kéri. 10. A RIS (BINLSVC) egy DHCP-ACK csomagot küld, amely a szerver IP címét, nevét, valamint annak az állománynak a nevét tartalmazza, amelyet a TFTP kiszolgálótól kell kérnie az ügyfélnek (Ez a startrom.com). Látható, hogy a harmadik és hetedik csomag felesleges. A harmadik csomagra sohasem fog válaszolni a PXE ügyfél, mert nem tartalmaz IP címet, míg a hetedik azért felesleges, mert IP címmel már rendelkezik a delikvens. Mindez azonban a szabványból következik. DHCP-OFFER csomagra minden DHCP kiszolgáló válaszol. (A BINLSVC konfigurálható ennél finnyásabb módon is. A RIS-nél beállítható, hogy csak az ismert ügyfeleknek válaszoljon. Ha a PXE ügyfél nem tud ismert GUID-ot felmutatni, a BINLSVC egyszerűen hallgat, nem küld válaszokat.) Ha a RIS és a DHCP egy kiszolgálón dolgoznak, lényegesen egyszerűbb párbeszéd zajlik a szerver és az ügyfél között. Csupán az alábbi: 1. DHCP-DISCOVER csomagot bocsát ki az ügyfél (IP címet és PXE boot szerver nevet keres). 2. DHCP-OFFER csomagot küld a kiszolgáló IP-cím ajánlattal és PXE boot szerver névvel. 3. DHCP-REQUEST kérés indul az ügyféltől a kiválasztott IP címmel. 4. DHCP-ACK nyugtázza a cím kiadását. A csomag tartalmazza az IP címet, a RIS szerver címét, és az első letöltendő állomány nevét. A trükk annyi, hogy a DHCP megkérdezi a BINLSVC szolgáltatást, hogy kívánja-e hozzáadni a maga információit a DHCP csomagokhoz. A PXE kliens egyébként az utóbbi forgalmat szereti. Ha két DHCP kiszolgálótól is kap csomagot, akkor azt fogja minden esetben preferálni, amelyik egyben RIS szerver is. A RIS kiszolgálók terheléselosztásánál ezt figyelembe kell venni. A fenti forgalomnál feltételeztük, hogy a három szereplő (PXE ügyfél, DHCP és RIS kiszolgáló) egy alhálózaton működik. Az élet azonban lehet ennél bonyolultabb, megeshet, hogy akár az egyik, akár mindkét szerver egy másik alhálózaton dolgozik. Ekkor természetesen DHCP Relay Agentekre van szükség, amelyeknek több helyre is továbbítani kell az elkapott DHCP- DISCOVER csomagot: a címkiszolgálók mellett a RIS szervereknek is értesülnie kell a PXE ügyfél indulásáról. A Q cikk egy érdekes, de a Microsoft által nem támogatott eljárást ír le. Ennek lényege, hogy három opciót be kell állítani egy adott scope-hoz (ezek közül egyet netsh felületen keresztül), amelynek nyomán a DHCP kiszolgáló rögvest elvégzi a BINLSVC munkáját is, mert megadja a RIS szerver nevét, címét és a boot állomány nevét. A megoldás hátránya, hogy a RIS szervert a scope-hoz köti, ráadásul kicselezi a BINLSVC fent említett biztonsági mechanizmusát is. Viszont a megoldás teljesen hasonlatos egy BOOTP induláshoz. Mi kell egy BOOTP kliensnek? IP cím, TFTP szerver cím, boot fájl név. És mi kell egy PXE kliensnek? Ugyanez. Nohát, nohát. Akkor miért kellett megalkotni egy új szabványt, a PXE-t, ahelyett, hogy az öreg motoros BOOTP-t használták volna? A válasz nem triviális, de valamennyire érthető. A BOOTP egy kihalóban lévő szabvány, mára már alig használják, legfőképpen pedig nem dinamikus. A DHCP ugyan dinamikus, de alapértelmezetten nem tartalmaz olyan adatokat a kliensekről, amilyenek egy PXE hostnak szüksége van. (Láttuk, megoldható, de nem túl szerencsés). Kell tehát egy olyan szabvány, amely IP címet oszt, TFTP szerver nevet és boot image elérhetőséget és dinamikus. Ilyen nem volt, ezért megalkották a PXE-t. Nem lehetett volna ezt a funkciót mégis a DHCP-be gyúrni? Talán lehetett volna, ki tudja. Az mindenesetre árulkodó, hogy a PXE nem egy RFC szabványon alapul, vagyis nem IETF alkotás. Ki tudja? Egyszer talán összeolvasztják a két eljárást olyan sok közös vonásuk van. Egyelőre azonban ez csak találgatás. Volt a BOOTP, van a DHCP és a PXE, nekünk pedig mindegyiket tudni kell alkalmazni a maga helyén. Felhasznált és ajánlott irodalom Lepenye Tamás, MCSE 2000 lepenyet@mal.hu Windows 2000 Server Internetworking Guide Chapter 3: IP Unicast Windows 2000 TCP/IP Core Networking Guide RFC-951 BOOTP Protocol RFC-1930 "Guidelines for creation, selection, and registration of an Autonomous System (AS)." RFC-2365 "Administratively Scoped IP Multicast." Q Description of PXE Interaction Among PXE Client, DHCP, and RIS Server Q Using Dynamic Host Configuration Protocol Options 60, 66, 67 to Direct PXE Clients to RIS Servers May Fail 24

25 A DHCP rejtett szépségei VII. A cikksorozat befejező részében három fontos témakört elemzünk. Megvizsgáljuk, milyen lehetőségeink vannak a DHCP-szolgáltatás rendelkezésre állásának növelésére, áttekintjük a beépített monitorozó eszközöket, végül néhány hasznos fogást ismertetünk, amelyek a DHCP-adatbázis karbantartását segíthetik. A rendelkezésre állás növelése Akik figyelemmel kísérték a tech.net magazin DHCP-cikksorozatát, pontosan tudják, hogy a címkiosztó szolgáltatás kritikus funkció, s bár nem kell minden másodpercben működnie, a hibás szerver lassan, de biztosan megbénítja az egész hálózat életét. Szerencsére számos lehetőség van a kezünkben, hogy a rendelkezésre állást növeljük. Az alábbi pár módszer közül a vékonyabb pénztárcájú és a professzionális szolgáltatók is megtalálhatják a nekik megfelelő megoldást. Rendelkezésre állás növelése józan ésszel Szőr mentén már említettük, most újra elővesszük az egyik legegyszerűbb és legkézenfekvőbb megoldást, amellyel akár napokat is nyerhetünk a DHCP helyreállításához. A címkérés módszeréből, valamint az Windowsos ügyfelek alapértelmezett beállításából következik, hogy a szolgáltatást csak rövid időre igénylik az IP-címmel dolgozó eszközök. Egy ügyfél akkor kerül kapcsolatba a DHCP-szerverrel, amikor először címet kér, újraindul, amikor meg kell újítani a bérletet a bérletidő felénél, sikertelenség esetén a háromnegyedénél, végül a bérlet tényleges lejáratakor. A kontaktusok közül csak az első és az utolsó kritikus, vagyis ha a kliensnek eleve nem volt címe, vagy végleg lejárt a bérlete. Minél hosszabb a két időpont közötti idő vagyis a bérletidő, annál nagyobb a valószínűsége, hogy nem ilyen kritikus helyzet áll fenn. Vagyis a bérletidő növelése önmagában a rendelkezésre állást növelő tényező. Persze csak statisztikai alapon. A bérletidő függvényét vizsgálva azt tapasztalhatnánk, hogy az ügyfelek legtöbbje a bérlet egynegyedénél jár. Miért? Mert ha jól működik a DHCP-szolgáltatás, akkor a gépek túlnyomó többsége félidőben megújítja a bérletét, vagyis a bérletidő 0 és 50%- a között egy normális jellegű eloszlás jellemzi a gépek címbérleteit. A ügyfélszámítógépek eloszlása az eltelt bérletidő függvényében Tökéletes normális eloszlásról azért nem beszélhetünk, mert mindig lesznek olyan gépek, amelyek kikapcsolt állapotban átalusszák a félidőt, és megjósolhatatlan, hogy mikor ébrednek. Ezzel együtt egy kevés gépből (20-60) álló hálózatban, naponta használt állomásokkal a normális eloszlás nagyon jó közelítés. Belátható, hogy egy 90 napos bérletperiódus esetén majdnem 45 nap áll rendelkezésre a DHCP-szolgáltatás megjavításához megint csak statisztikai alapon. Akkor javasolt ehhez a taktikához folyamodni, ha: Egyetlen szerverünk van. Viszonylag kicsi, jól átlátható hálózattal dolgozunk. Stabil a környezetünk, tehát nem konfiguráljuk át gyakran a DHCP-kiszolgálót, nem vásárolunk éppen most gépeket, nem adunk új IP-cím tartományt a hálózatnak. Nincsenek olyan ügyfeleink, amelyek egy másik hálózatban is rendszeresen megfordulnak, és ott címet igényelnek. Nincsenek BOOTP ügyfeleink. (Ők újrainduláskor mindenképp igényelnek IP-címet.) Nem konfiguráltuk úgy az ügyfeleket, hogy leálláskor engedjék el a címüket. Bár kemény korlátok a fentiek, azért szép számmal akad olyan hálózat, amely minden kritériumot teljesít. Fontos megemlíteni, hogy a több telephely nem akadály, hisz az ügyfél számára transzparens, vajon egy valódi címkiszolgáló szervertől kapja a címet, vagy egy Relay Agent közvetíti azt. Nem ajánlott a megoldás extrapolálása a bérletidő végtelenre állításával. Igaz ugyan, hogy ekkor nincs félidő sem, tehát a haranggörbe a fenti ábra bal tengelyére vasalódik, ám a megoldásnak több a hátulütője, mint az előnye. A végtelen bérletperiódussal ellátott ügyfél csak akkor reflektál a DHCP-opciókban bekövetkezett változásokra ha újraindítják, ám ez még csak a kisebbik baj. 25

26 A nagyobb gond, hogy a DHCP-kiszolgáló nem értesül arról, ha egy gépet végképp kivonnak a hálózatból. A kiadott cím örökre az adott MAC-Address-hez tartozik, tehát elvész. A cím visszanyeréséhez pontos nyilvántartással kell rendelkeznünk a hálózatunk található valamennyi DHCP ügyfél MAC-címéről. Ez túl sok többletmunka a végtelen bérletért cserébe. Igazából épp ezt a nyilvántartást teszi feleslegessé a címkiosztás. A fenti módszer, bár működik, igazából a szolgáltatás tehermentesítésével teremt rendelkezésre állást. Ha a statisztikai elv nem fogadható el, vagy nem alkalmazható, egy komolyabb és megbízhatóbb megoldást kell keresünk as (50-50-es) megoldás Ha nem csak egyetlen kiszolgálóval rendelkezünk, hanem legalább kettővel, egy ügyes trükkel biztosíthatjuk, hogy az ügyfelek mindig hozzájussanak a mindennapi IP-címükhöz. A módszer igen egyszerű. Hozzunk létre két DHCP kiszolgálót, és konfiguráljuk mindegyiken egy-egy azonos címtartományra vonatkozó bérlettartomány. Ezután az egyik kiszolgálón zárjuk ki a címek felső húsz (vagy ötven) százalékát. Végezzük el ugyanezt a műveletet a másik szerveren is, de ott az alsó 80 (vagy 50) százaléknyi címet zárjuk ki. Az eredményt a második ábra mutatja. Scope: Excluded addresses: DHCP Server1 Scope: Excluded addresses: DHCP Server2 DHCP kliens DHCP kliens DHCP kliens DHCP kliens A as (50-50-es) eljárás alkalmazása A végeredmény két, azonos címtartományt kezelő, de pontosan azonos címeket soha ki nem osztó szerverpár lesz. Az eljárás alkalmazásakor a következőre kell figyelni: Véletlenül sem fordulhat elő, hogy azonos dinamikus címet mindkét szerver kiadhasson, tehát a címek között nem lehet átfedés. A két scope opcióinak teljesen azonosnak kell lennie, beleértve a bérletidőt és a speciális opciókat is. A lefoglalt címeket (reserved addresses) mindkét kiszolgálón be kell állítani, beleértve a kiegészítő opciókat is, ha vannak ilyenek. A BOOTP címeket a lefoglalt címekhez hasonlóan kell kezelnünk, vagyis kétszer kell felvennünk minden rekordot. A címtartomány nagyságát úgy érdemes megválasztani, hogy akár egy kiszolgáló is képes legyen valamennyi potenciális ügyfelet kiszolgálni. Ha tehát van 300 gépünk, és 150-et szolgál ki egy DHCP-szolgáltatás, akkor a bérlettartomány tartalmazzon legalább 300 címet. Manapság, a privát címtartományok használatakor ez ritkán probléma. (Ugyanakkor gyakoribb az 50-50%-os megosztása a bérlettartománynak, ezért szerepel ez az ábrán.) Stabil a környezetünk, tehát nem konfiguráljuk át gyakran a DHCP-kiszolgálót, nem vásárolunk éppen most gépeket, nem adunk új IP-cím tartományt a hálózatnak. Nézzük, mit nyerünk a konfigurációval. A módszer valódi rendelkezésre-állás növekedést jelent, mert az egyik kiszolgáló kiesése esetén is elláthatók az ügyfelek IP-címekkel. Akár kézzel is nekiállhatunk egy teljesen új DHCP kiszolgáló felállításának, ha kiesne az egyik, hiszen van egy tükörképünk, amit csak le kell másolnunk. Nem akadályoznak az előző megoldásnál felsorolt kritériumok sem, lehetnek vándorló gépeink, BOOTP klienseink, tetszőlegesen konfigurálhatjuk az ügyfeleket, skálázható megoldáshoz jutunk amely ráadásul mindig működik. Mindezt úgy, hogy nem kellett extrán konfigurált hardvert vásárolnunk, sem új technológiát bevezetnünk, nincs szükség a Windows Server drágább változatára. Olyannyira nincs, hogy a tükörszerver akár másik operációs rendszert is futtathat, például Linuxot. A feltétel csupán annyi, hogy a DHCP-szabvány pontosan kövesse a másik rendszer is, legalábbis mindazt tudja, amit mi használunk a szabványból (esetleg: superscope, különleges opciók (class, vendor stb.)) A magasabb színvonalú szolgáltatásnak azonban ára van. Lényegében kétszer kell elvégeznünk minden konfigurációs műveletet. Ha ritkán változó scope-pal dolgozunk ez kevésbé fájdalmas, ám ha sok lefoglalt címünk van, netán még BOOTP ügyfeleket is kiszolgálunk, akkor nehéz két szerveren precízen azonos adatbázist fenntartani. (Ilyenkor javasolt minden műveletet parancssorból végezni, mert a megkonstruált parancssort könnyű két szerverre lefuttatni.) Katasztrófatűrő megoldás Az es módszert továbbfejleszthető valódi katasztrófatűrő megoldássá. A következő ábra két telephelyből felépülő hálózatot mutat az előbb ismertetett DHCP-konfigurációval. 26

27 Scope1: Excluded addresses: Scope2: Excluded addresses: DHCP Server1 Scope2: Excluded addresses: Scope1: Excluded addresses: DHCP Server2 DHCP kliens DHCP kliens DHCP kliens Katasztrófatűrő megoldás DHCP kliens Az eredeti módszert ki kell egészíteni az útválasztók konfigurálásával (vagy egyéb módon kell biztosítani DHCP Relay Agenteket). A rajzról leolvasható, hogy mindkét telephelyen mindkét DHCP-szerver megkapja az ügyfelek kérését. Ha azonban a továbbító ügynökök némi késéssel indítják el a címigénylő csomagokat a távoli hálózat felé, normál működéskor a helyi kiszolgáló győz. Meghibásodáskor viszont a távoli rendszer mindenképp kiszolgálja az ügyfeleket. A módszer katasztrófatűrő, amennyiben az egyik szerver fizikai megsemmisülése esetén is működőképes marad a címkiosztás. Egyéb vonatkozásaiban a megoldás pontosan ugyanazokat az előnyöket és hátrányokat hordozza, mint az egy telephelyes kialakítás. A fürtözés A Windows 2000 Advanced Server az első olyan Windows kiszolgáló változat, amely lehetővé teszi, hogy megfelelően kialakított hardverrel a DHCP szolgáltatást fürtözhessük. A megoldás ezúttal a virtualizálás. A fürtök állomásokból (node) és virtuális szerverekből állnak. A virtuális szerverek erőforrásokat tartalmaznak. Ilyen erőforrás lehet egy fizikai lemez, egy IP cím, egy hálózati név, vagy éppenséggel egy DHCP-szolgáltatás. A fürt elvi működését mutatja a következő ábra: A DHCP-szolgáltatás a virtuális szerveren található A kliensek sohasem az egyik, vagy másik állomástól kapják a fürtözött szolgáltatást, hanem mindig egy virtuális szervertől. Ez a szerver szükség szerint költözhet egyik állomásról a másikra. (Windows Server 2003 négy, vagy akár 8 node egyikére.) Az átköltözési idő az erőforrások számától és terheltségétől függ. Ha a DHCP-szolgáltatás számára egy saját virtuális szervert definiáltunk, akkor az átköltözés 6-10 másodperc. Ennyi tehát a kiesés tulajdonképpen semennyi. A fürtözött DHCP-kiszolgáló, a virtuális erőforrás létrehozását leszámítva, semmiben sem különbözik egy normális címkiosztó szervertől. A fürt nem ad hozzá és nem vesz el a teljesítményből vagy a funkcionalitásból, csupán a rendelkezésre állást növeli. A megoldás előnye az előzőekhez képest az egyszeres konfiguráció. Előnyös lehet sok (max: 10000!) scope kezelésekor, nagyszámú lefoglalt cím nyilvántartásakor, vagy BOOTP ügyfelek kiszolgálása esetén. Akárcsak az előző két módszer, ez is valódi rendelkezésre állást növelő eljárás. Persze a tökéletes megoldásnak ára van: a fürt kialakítása host-bus adaptereket, közös háttértárat, speciális HCL listán hitelesített konfigurációt feltételez. Az operációs rendszer vagy két Windows 2000 Advanced Server, vagy (legalább két) Windows 2003 Server Enterprise Edition lesz fürtözéskor. Ez jelentős többletköltség, mert a standard változatokhoz képest a 27

28 licencár legalább tízszeres (ha mindkét állomást számolom.) Meggondolandó, hogy a fürtök felépítése, működtetése szakértelmet kíván, a hibajavításkor szakértői költségek merülhetnek fel, hacsak nem profik az üzemeltetők. Láthatjuk, hogy a rendelkezésre állást segítő technológiák igen sokfélék. A különbözőségük lehetőséget teremt arra, hogy ötvözzük őket, ha van rá lehetőségünk és a feltételek adottak. A fürtözés nem zárja ki a hosszú bérletidő használatát, ha pedig két fürtünk is futtat DHCP-kiszolgálót különböző telephelyen, földrajzilag elosztott megoldást alakíthatunk ki az es megoldással. Az egyes módszereket építőelemnek tekinthetjük, és tetszés szerint készíthetünk akár nagyon bonyolult címkiosztó architektúrákat is. Csupán a fantázia (és a pénz) szab határt az elképzeléseinknek. Egy fontos tanácsot azonban érdemes megfogadni: lehet bonyolult, amit elkészítünk, csak legyen jól dokumentált. A rendelkezésre állás egyik halálos ellensége a hiányos dokumentáció. A másik a felügyelet hiánya. A DHCP kiszolgálók monitorozása A kiszolgálók figyelése a rendszergazdák napi feladatai közé tartozik. Ha figyelembe vesszük a DHCP fontosságát, ez még inkább így van. Amikor azonban az ember szembesül a teljesítménynapló számaival, hajlamos kissé visszavenni a lendületből. A helyi tömegközlekedés menetrendje DHCP számlálókba csomagolva A fenti diagram az egyik nagyobb telephelyünk DHCP-kiszolgálójának teljesítményadatait mutatja. A napló eredetileg a teljes 24 órát rögzítette, én azonban csak az 5.30 és 9.00 közötti időszakot ábrázoltam. Mivel kezdetben csupa kisimított vonalakat láttam, elkezdtem nagyítani a diagramot, jól látszik, hogy ezer és tízezerszeres nagyítás hozott eredményt. Végül pusztán az adatok felé fordulva (és tovább szűkítve az időt 5.30 és 8.00 közé) a következőt mondhatjuk a telephelyről. Néhány adat a reggeli indulásról Vannak kimutathatatlanul alacsony értékek, például nem alakult ki sor, hogy a DHCP leellenőrizze keletkezne-e konfliktus egy cím kiadásakor. Ugyancsak nem történt elutasítás (Nack/sec), ami leginkább azt jelenti, hogy nem érkezett olyan notebook a hálózata, amely korábban más alhálózatban kapott címet. A címjóváhagyások (Ack/sec) átlagos értéke 0,018 másodpercenként, tehát 1,08 percenként 64,8 óránként. A két és fél óra alatt tehát nagyjából 162 gépet kapcsoltak be, amelyek azután jóváhagyott címmel elindultak. Persze a többség eleve létező bérlettel indult, a discover csomagot is kibocsátó gépek száma (0,001x60x60x2,5) mindössze 9. Ha elárulom, hogy kb. 10 gép állandóan üzemel, 10-et pedig átlagosan nem kapcsolnak be, máris megkaptuk, hogy kb. 190 gépet lát el a címkiosztó rendszerünk. A DHCP kiszolgáló 28

29 teljes terheltsége 0,020 csomag másodpercenként, vagyis csak 1,2 csomag percenként. Ez a szolgáltatás vélhetően nem fogja megizzasztani a legkisebb szervereket sem. Tudom, hogy vannak ennél jóval nagyobb implementációk is. Egy Internetszolgáltató akár százezer címet is kioszthat egyetlen este nagyvállalati környezetben azonban a DHCP szerver méretezése és terhelése egyszerűen nem lehet probléma. A Diagnostic log A mindennapi hibaelhárítás során a teljesítménynaplónál is fontosabb lehet a Windows 2000-ben bevezetett diagnostic vagy más néven audit log. Az audit log használata nem kötelező, a szerver tulajdonságai párbeszédpanelen lehet bekapcsolni, az advanced fülön pedig a naplóállományok helyét is megadhatjuk. A következő pár sor a fenti szerver naplója ugyanaznap. Microsoft DHCP Service Activity Log Egy hasznos szolgáltatás az audit Event ID Meaning 00 The log was started. 01 The log was stopped. 02 The log was temporarily paused due to low disk space. 10 A new IP address was leased to a client. 11 A lease was renewed by a client. 12 A lease was released by a client. 13 An IP address was found to be in use on the network. 14 A lease request could not be satisfied because the scope's address pool was exhausted. 15 A lease was denied. 16 A lease was deleted. 17 A lease was expired. 20 A BOOTP address was leased to a client. 21 A dynamic BOOTP address was leased to a client. 22 A BOOTP request could not be satisfied because the scope's address pool for BOOTP was exhausted. 23 A BOOTP IP address was deleted after checking to see it was not in use. 50+ Codes above 50 are used for Rogue Server Detection information. ID Date,Time,Description,IP Address,Host Name,MAC Address 51,11/03/03,00:35:43,Authorization succeeded,,mal.priv, 57,11/03/03,00:35:43,Server found in our domain, ,mal.priv, 11,11/03/03,00:47:07,Renew, ,AJK-056.mal.priv,00A0C9417B89 51,11/03/03,01:36:15,Authorization succeeded,,mal.priv, 57,11/03/03,01:36:15,Server found in our domain, ,mal.priv, 11,11/03/03,02:06:04,Renew, ,AJK-099.mal.priv,00A0C9419FB2 51,11/03/03,02:36:47,Authorization succeeded,,mal.priv, A napló szerkezete meglehetősen egyszerű, táblázatba foglalva a következő: Mező ID Dátum Leírás Az eseményt azonosító kód A bejegyzés dátuma 29