DHCP | |
---|---|
Név | Dynamic Host Configuration Protocol |
Szint ( az OSI modell szerint ) | Alkalmazva [1] |
Család | TCP/IP |
Létrehozva: | 1990 |
Port/ID | 67, 68/ UDP |
A protokoll célja | Hálózati konfiguráció lekérése |
Leírás | RFC 2131 |
Főbb megvalósítások (kliensek) | ISC DHCP , Windows Kernel |
Alapvető megvalósítások ( szerverek ) | dhcpd, ISC DHCP szerver, Infoblox |
Médiafájlok a Wikimedia Commons oldalon |
A DHCP ( Dynamic Host Configuration Protocol – dinamikus gazdakonfigurációs protokoll ) egy olyan alkalmazásprotokoll , amely lehetővé teszi a hálózati eszközök számára, hogy automatikusan megkapják az IP-címet és a TCP/IP-hálózaton történő működéshez szükséges egyéb paramétereket . Ez a protokoll kliens-szerver modellen működik . Az automatikus konfiguráláshoz a hálózati eszköz konfigurációs szakaszában lévő ügyfélszámítógép hozzáfér az úgynevezett DHCP szerverhez , és megkapja onnan a szükséges paramétereket. A hálózati rendszergazda beállíthatja a kiszolgáló által a számítógépek számára kiosztott címtartományt. Ezzel elkerülhető a számítógépek manuális konfigurálása a hálózaton, és csökken a hibák száma. A legtöbb TCP/IP hálózaton DHCP-t használnak.
A DHCP a BOOTP protokoll kiterjesztése , amelyet korábban a lemez nélküli munkaállomások IP-címekkel való ellátására használtak rendszerindításkor. A DHCP visszafelé kompatibilis a BOOTP-vel.
A DHCP protokoll szabványt 1993 októberében fogadták el . A protokoll jelenlegi verzióját ( 1997. március ) az RFC 2131 írja le . A DHCP IPv6 környezetben való használatra szánt új verzióját DHCPv6 - nak hívják , és az RFC 3315 ( 2003. július ) határozza meg.
A DHCP protokoll három módot biztosít az IP-címek kiosztására :
A DHCP szolgáltatás egyes megvalósításai képesek automatikusan frissíteni az ügyfélszámítógépeknek megfelelő DNS -rekordokat , amikor új címeket rendelnek hozzájuk. Ez az RFC 2136 -ban leírt DNS-frissítési protokoll használatával történik .
Az IP-címen kívül a DHCP a normál hálózati működéshez szükséges további paraméterekkel is elláthatja a klienst. Ezeket a beállításokat DHCP opcióknak nevezzük . A szabványos opciók listája az RFC 2132 -ben található .
A beállítások mező változó hosszúságú, de a DHCP-kliensnek fel kell készülnie egy 576 bájtos DHCP-üzenet fogadására (ebben az üzenetben a beállítások mező 340 bájt hosszú).
A beállítások mező "varázsszámmal" kezdődik - négy bájt 99, 130, 83, 99 (0x63, 0x82, 0x53, 0x63 hexadecimális értékekkel), lehetővé téve a szerver számára, hogy meghatározza a mező jelenlétét.
Mindegyik opciót a "kód" (egy bájt), "hosszúság" (egy bájt), "érték" sorozat kódolja - egy változó hosszúságú mező, amelynek mérete megegyezik a "hosszúság" mező értékével, beleértve a nullát. .
Két kód kivételt képez:
A kód | Hossz | Leírás |
---|---|---|
0 | (hiányzó) | adatok párosítására és igazítására szolgál |
egy | négy | Alhálózati maszk |
2 | négy | Időzóna, aláírt szám, eltolás UTC -től másodpercben. |
3 | 4*n | Átjárók listája, preferencia sorrendben. |
négy | 4*n | Protocol listája |
5 | 4*n | Az IEN 116 névszerverek listája. |
6 | 4*n | DNS -kiszolgálók listája |
7 | 4*n | Naplószerverek listája (MIT-LCS UDP) |
nyolc | 4*n | Cookie szerverek listája ( RFC 865 ) |
9 | 4*n | LPR szerverek listája ( RFC 1179 ) |
tíz | 4*n | Az Imagen Impress szerverek listája |
tizenegy | 4*n | Erőforrás-felderítő kiszolgálók listája ( RFC 887 ) |
12 | n | Kliens gazdagépneve, karakterlánc. |
13 | 2 | A kliens rendszerindító lemezképének mérete (512 oktett blokkban). |
tizennégy | n | Fájl elérési útja, ahol az ügyfél a kiíratást összeomlás esetén menti |
tizenöt | n | domain név |
16 | négy | Swap szerver |
17 | n | Az ügyfél gyökérkönyvtárának elérési útja. |
tizennyolc | n | BOOTP-bővítmények elérési útja |
19 | egy | Az ügyfélnek engedélyeznie kell-e az IP-továbbítást (1 vagy 0 értéket vesz fel) |
húsz | egy | Az ügyfélnek engedélyeznie kell-e a nem helyi forrásokból származó datagram-továbbítást (1-re vagy 0-ra állítva) |
21 | 8*n | Érvényes hálózati címek és maszkok listája nem helyi forrásokhoz |
22 | egy | Maximális datagramméret (minimális érték 576) |
23 | egy | Alapértelmezett IP TTL érték |
24 | négy | Időtúllépés (másodpercben), hogy az elérési út MTU értékei lejárjanak ( RFC 1191 ) |
25 | 2*n | Az MTU értékek listája a Path MTU Discovery ( RFC 1191 ) végrehajtásakor |
26 | 2 | MTU-érték ehhez az interfészhez (minimális érték 68) |
27 | egy | Jelölje meg, hogy minden alhálózat az aktuális MTU-konfigurációt használja (0 vagy 1 értéket vesz fel) |
28 | négy | Műsorszórási cím |
29 | egy | Az ügyfélnek ICMP-n keresztül kell-e kérnie az alhálózati maszkot (0 vagy 1 értéket vesz fel) |
harminc | egy | Az ügyfélnek válaszolnia kell-e a maszkkérésekre az ICMP-n keresztül (0 vagy 1 értéket vesz fel) |
31 | egy | Az ügyfélnek le kell-e kérdeznie az útválasztókat az RFC 1256 mechanizmus használatával (0 vagy 1 értéket vesz fel) |
32 | négy | Az a cím, amelyre az ügyfélnek útválasztó kéréseket kell küldenie |
33 | 8*n | A statikus útválasztási lista "célcím" - "útválasztó címe" párokból áll. |
34 | egy | A pótkocsik ARP-kérésekhez való használata megengedettségének jele (0 vagy 1 értéket vesz fel) |
35 | négy | Az ARP gyorsítótár időtúllépése, másodpercben. |
36 | egy | Jelölje meg az IEEE 802.3 tokozás ( RFC 1042 ) használatát az Ethernet 2-es verzió ( RFC 894 ) helyett (0-ra vagy 1-re állítva) |
37 | egy | A TCP alapértelmezett TTL értéke |
38 | négy | Időintervallum (másodpercben) a Keepalive elküldése előtt |
39 | egy | Meg kell-e küldeni a Keepalive-t extra szemét oktetttel (0 vagy 1 értéket vesz fel) |
40 | n | NIS domain név (karakterlánc) |
41 | 4*n | A NIS-kiszolgálók listája |
42 | 4*n | Az NTP időszerverek listája |
43 | n | Szállítóspecifikus információk |
44 | 4*n | Névkiszolgálók listázása (NBNS) NetBIOS |
45 | 4*n | A NetBIOS datagram disztribúciós (NBDD) kiszolgálók listája |
46 | egy | NetBIOS csomópont típusa: 0x1 - B-csomópont; 0x2 - P-csomópont; 0x4 - M-csomópont; 0x8 - H-csomópont |
47 | n | NetBIOS terület |
48 | 4*n | Az X Window System betűkészlet-kiszolgálók listája |
49 | 4*n | X Window System megjelenítési címlista |
ötven | négy | Kért IP-cím |
51 | négy | IP-cím kölcsönzési ideje , másodpercben |
52 | egy | Jelölje meg a „file” (1) és „sname” (2) vagy mindkettő (3) mező használatát az opciókhoz |
53 | egy | DHCP üzenet típusa (1 - DHCPDISCOVER; 2 - DHCPOFFER; 3 - DHCPREQUEST; 4 - DHCPDECLINE; 5 - DHCPACK; 6 - DHCPNAK; 7 - DHCPRELEASE; 8 - DHCPINFORM) |
54 | négy | DHCP szerver azonosító |
55 | n | A kért paraméterek listája (minden bájt egy paraméterkód) |
56 | n | Hibaüzenet (karakterlánc) |
57 | 2 | A DHCP üzenet maximális mérete. Minimális érték 576 |
58 | négy | Idő T1, az IP-cím frissítése előtt (másodpercben) |
59 | négy | T2 idő az újrakötés előtt (másodpercben) |
60 | n | Szállítótípus azonosító (karakterlánc) |
61 | n | Ügyfél-azonosító (karakterlánc) |
64 | n | NIS+ domain név |
65 | 4*n | A NIS+ szerverek listája |
66 | n | TFTP-kiszolgáló neve (karakterlánc), ha a „név” mezőt a beállításokhoz használja |
67 | n | A rendszerindító fájl neve (karakterlánc), ha a „file” mezőt az opciókhoz használja |
68 | 4*n | Mobile IP Home Agent címlista |
69 | 4*n | SMTP szerverek listája |
70 | 4*n | A POP3 szerverek listája |
71 | 4*n | Az NNTP -kiszolgálók listája |
72 | 4*n | A WWW szerverek listája |
73 | 4*n | Finger Server List |
74 | 4*n | Az IRC szerverek listája |
75 | 4*n | StreetTalk szerverek listája |
76 | 4*n | StreetTalk Directory Assistance Server List |
255 | (hiányzó) | Az opciólista vége |
A leggyakrabban használt lehetőségek közül néhány:
Egyes szoftvergyártók saját, további DHCP-beállításokat is megadhatnak.
A DHCP protokoll kliens-szerver , azaz működésében egy DHCP kliens és egy DHCP szerver vesz részt . Az adatok továbbítása UDP protokoll használatával történik . Alapértelmezés szerint a klienstől érkező kérések a 67-es porton érkeznek a kiszolgálóhoz, a szerver viszont válaszol a 68-as porton lévő kliensnek egy IP-címmel és egyéb szükséges információkkal, mint például a hálózati maszk, az útválasztó és a DNS-kiszolgálók.
Minden DHCP üzenet mezőkre van osztva, amelyek mindegyike tartalmaz bizonyos információkat. Az utolsó mező kivételével (DHCP opciómezők) rögzített hosszúságúak.
Terület | Leírás | Hossz ( byte -ban ) |
---|---|---|
op | Üzenet típusa. Például a következő értékeket veheti fel: BOOTREQUEST (0x01, kérés a klienstől a szerver felé) és BOOTREPLY (0x02, válasz a szervertől a kliens felé). | egy |
htype | Hardvercímtípus. A mező érvényes értékeit az RFC 1700 "Hozzárendelt számok" határozza meg. Például egy Ethernet MAC-cím esetén ez a mező 0x01. | egy |
hlen | A hardvercím hossza bájtban. Az Ethernet MAC-cím 0x06. | egy |
komló | Azon köztes útválasztók (úgynevezett DHCP-közvetítő ügynökök ) száma, amelyeken keresztül az üzenet áthaladt. Az ügyfél ezt a mezőt 0x00-ra állítja. | egy |
xid | Egyedi, 4 bájtos tranzakcióazonosító, amelyet az ügyfél generál a címszerzési folyamat elején. | négy |
mp | A címszerzési folyamat kezdete óta eltelt idő másodpercben . Nem használható (ebben az esetben 0x0000-ra van állítva). | 2 |
zászlókat | A zászlók mezője a DHCP protokoll speciális paraméterei. | 2 |
ciaddr | kliens IP-címe. Csak akkor van kitöltve, ha az ügyfélnek már van saját IP-címe, és képes válaszolni az ARP -kérésekre (ez akkor lehetséges, ha az ügyfél a bérlet lejárta után címmegújítási eljárást hajt végre). | négy |
yiaddr | A szerver által javasolt új kliens IP-cím. | négy |
siaddr | A szolgáltatási lánc következő szerverének IP-címe. A szerver ebben a mezőben a saját címét adhatja vissza. Az 54-es opció a szerver azonosítására szolgál. | négy |
giaddr | A továbbító ügynök IP-címe, ha részt vett a DHCP-üzenet kiszolgálóhoz való eljuttatásában. | négy |
chaddr | Az ügyfél hardvercíme (általában MAC-cím ). | 16 |
nevet | Opcionális kiszolgálónév null-végződésű karakterláncként . | 64 |
fájlt | Egy opcionális fájlnév a kiszolgálón, amelyet a lemez nélküli munkaállomások távoli rendszerindításkor használnak. A névhez hasonlóan null-végződésű karakterláncként jelenik meg. | 128 |
lehetőségek | DHCP beállítások mező . Itt különféle további konfigurációs lehetőségek vannak megadva. Ennek a mezőnek az elején négy speciális bájt van feltüntetve 99, 130, 83, 99 ("varázsszámok") értékekkel, amelyek lehetővé teszik a szerver számára, hogy meghatározza a mező jelenlétét. A mező változó hosszúságú, azonban a DHCP-kliensnek fel kell készülnie egy 576 bájtos DHCP-üzenet fogadására (ebben az üzenetben az opciók mezője 340 bájt hosszú). | változó |
Nézzünk egy példát arra, hogyan kap egy kliens IP-címet a DHCP-kiszolgálótól. Tegyük fel, hogy az ügyfélnek még nincs saját IP-címe, de ismeri a korábbi címét - 192.168.1.100. A folyamat négy szakaszból áll. Ezeket a szakaszokat gyakran DORA-nak (Discovery, Offer, Request és Acknowledgement) rövidítik.
DHCP DiscoveryA kliens először egy kérést küld a teljes fizikai hálózatra, hogy felderítse az elérhető DHCP-kiszolgálókat. DHCPDISCOVER típusú üzenetet küld (az Üzenettípus opció értéke 1), a forrás IP-címe 0.0.0.0 (ha a számítógép még nem rendelkezik saját IP-címmel), célcímként pedig a 255.255 szórási címet . 255.255.
A kliens több üzenetmezőt kitölt kezdeti értékekkel:
A DHCPDISCOVER üzenet a helyi fizikai hálózaton kívül is továbbítható speciálisan konfigurált DHCP-közvetítő ügynökök használatával, amelyek a DHCP-üzeneteket az ügyfelektől más alhálózatokon lévő szerverekhez továbbítják.
Az IP-cím megszerzésének folyamata nem mindig a DHCPDISCOVER -rel kezdődik . Ha a kliens korábban kapott IP-címet, és a bérleti szerződése még nem járt le, a kliens kihagyhatja a DHCPDISCOVER szakaszt, kezdve egy DHCPREQUEST kéréssel , amelyet a legutóbbi címet kiadó szerver azonosítójával küldtek. Ha nem érkezik válasz a legutóbbi beállításokat kiadó DHCP-kiszolgálótól, az ügyfél DHCPDISCOVER üzenetet küld . Így a kliens elölről kezdi a fogadási folyamatot, megcímezve a hálózati szegmens összes DHCP-kiszolgálóját.
DHCP ajánlatA klienstől kapott üzenet után a szerver meghatározza a kliens szükséges konfigurációját a hálózati rendszergazda által megadott beállításoknak megfelelően. Ebben az esetben a DHCP szerver elfogadja a kliens által kért 192.168.1.100 címet. A szerver DHCPOFFER választ küld neki (az Üzenettípus opció értéke 2), amelyben felajánl egy konfigurációt. Az ügyfélnek felajánlott IP-cím a yiaddr mezőben van megadva . Más paraméterek (például útválasztó és DNS-kiszolgáló címei ) a megfelelő mezőben vannak megadva opcióként.
Ezt az üzenetet a DHCP-kiszolgáló küldi el annak a gazdagépnek, amelyik a DHCPDISCOVER-t küldte a MAC-ján, bizonyos körülmények között az üzenet sugárzásként továbbítható. Egy kliens több különböző DHCP-ajánlatot kaphat különböző szerverektől; közülük ki kell választania a neki megfelelőt.
DHCP kérésA DHCP szerverek által kínált konfigurációk közül a kliens DHCPREQUEST kérést küld (az Üzenettípus opció értéke 3). sugározzák; a kliens által a DHCPDISCOVER üzenetben megadott opciókon kívül egy speciális opció - a szerver azonosító - kerül hozzáadásra, amely jelzi a kliens által kiválasztott DHCP szerver címét (jelen esetben 192.168.1.1).
Ugyanezt a kérést használják fel a címbérlet lejártakor, az idő meghosszabbítására (megújítására) vagy az újrakötési eljárásra. Ezekben az esetekben a "server id" és a "requested IP address" opciók kimaradnak, és a ciaddr mező kitöltésre kerül a korábban hozzárendelt ügyfélcímmel. Ha az idő meghosszabbodik, a kérés nem sugárzott formában kerül elküldésre, hanem a kibocsátó szervernek címezve. Csak ha a szerver nem válaszol a megadott időn belül, akkor az újrakötési eljárást csak akkor indítják el a szórási kérésekkel.
A kérést a kliens újraindítása utáni inicializálásra is használják (init-reboot), amikor már ismeri a korábban hozzárendelt címet. Ebben az esetben a DHCPDISCOVER nem kerül végrehajtásra, hanem azonnal elküldésre kerül egy DHCPREQUEST üzenet a "szerverazonosító" opció megadása nélkül, de a "kért IP-cím" opcióban ismert címmel. A ciaddr mező üresen marad.
DHCP kézfogásVégül a szerver nyugtázza a kérést, és DHCPACK-nyugtát küld (az üzenet típusa 5) a kliensnek. A kliensnek ezután be kell állítania a hálózati interfészét a megadott opciók segítségével.
Üzenetek típusaAz alábbiakban példák láthatók a folyamat során elküldött DHCP-üzenetek egyes mezőinek értékeire. A példában egy 00:1D:60:57:ED:80 MAC -című eszköz IP-címet kér egy DHCP-kiszolgálótól . A kliens az utolsó ismert IP-címét, a 192.168.1.100-at küldi el javaslatként
|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Azon üzeneteken kívül, amelyek szükségesek ahhoz, hogy a kliens először megkapja az IP-címet, a DHCP számos további üzenetet is biztosít egyéb feladatok végrehajtásához.
DHCP hibaHa a szervertől kapott nyugtázás (DHCPACK) után a kliens azt észleli, hogy a szerver által megadott cím már használatban van a hálózaton, akkor DHCPDECLINE elutasító broadcast üzenetet küld (az Üzenettípus opció értéke 4), amely után az IP-cím megszerzésének eljárása megismétlődik. Egy másik kliens IP - címének használata ARP - kérés kibocsátásával észlelhető .
A DHCP törléseOlyan helyzetekben, amikor a szerver nem tudja hozzárendelni a kért címet a klienshez, például ha a kliens a DHCPREQUEST végrehajtásakor érvénytelen értéket ad át a klienstől a "kért IP-cím" opcióhoz, a szerver DHCPNAK Mégse üzenetet küld. Üzenet közvetítése (az "Üzenettípus" opció értéke 6). Egy ilyen üzenet kézhezvételekor a megfelelő ügyfélnek meg kell ismételnie a címszerzési eljárást.
DHCP kiadásaAz ügyfél kifejezetten felmondhatja az IP-cím bérletét. Ehhez egy DHCPRELEASE üzenetet küld (az Üzenettípus opció értéke 7) annak a szervernek, amelyik bérelte a címet. Más DHCP-üzenetekkel ellentétben a DHCPRELEASE nem kerül sugárzásra.
DHCP információA DHCPINFORM információs üzenet (az Üzenettípus opció értéke 8) további TCP/IP paraméterek meghatározására szolgál (például az alapértelmezett útválasztó címe, DNS -kiszolgálók stb.) azon kliensek számára, amelyeknek nincs szükségük dinamikusra. IP-cím (vagyis van egy cím, amelyet manuálisan kell beállítani). A szerverek egy nyugtázó üzenettel (DHCPACK) válaszolnak egy ilyen kérésre IP-cím kiosztása nélkül.
Amikor DHCPOFFER és DHCPACK üzeneteket küld DHCPREQUEST válaszul, a szerver kitölti az 51-es "Bérleti idő" opció értékét, amely egy 32 bites érték, amely azt a relatív időt fejezi ki másodpercekben, ameddig az ügyfél IP-címet kap.
Opcionálisan a szerver két további T1 és T2 időintervallum értékét jelenti a 42. és 43. opcióban. Ha ezek az opciók nincsenek megadva, akkor az ügyfél kiszámítja a T1 -et a bérleti idő 1/2-ével és a T2 -t a bérleti idő 7/8-ával.
T1 után a kliens belép a bérleti idejű megújítási állapotba (megújítás), és megpróbálja megújítani az IP-cím bérleti szerződését úgy, hogy egy unicast DHCPREQUEST kérést küld a szervernek, megadva a címét a ciaddr mezőben , anélkül, hogy átadná a "szerverazonosító" opciókat. " és " kért IP-címet. A szerver erre a kérésre DHCPACK üzenettel válaszol, amely jelzi az új bérleti időközt az aktuális időhöz képest.
Ha a szerver nem válaszol, akkor a T2 -ig hátralévő idő fele után , de legalább 60 másodperccel később próbálkozik újra a kérés elküldésével.
Az ügyfél a T1 intervallum lejárta előtt is kérhet bérleti hosszabbítást.
Ha a T2
idő lejárta után nem érkezik válasz a szervertől, akkor a kliens újrakötési állapotba kerül. Ebben az esetben a kliens megkezdi a hasonló DHCPREQUEST kérések sugárzását, szükség esetén megismétli a küldési kísérleteket a bérleti szerződés lejártáig hátralévő idő fele után, de legfeljebb 60 másodperccel később.
A bérlet lejártáig, még ha a T1 és T2 lejár is, az ügyfél továbbra is a hozzárendelt IP-címet használja, mint korábban. De amikor a bérlet lejár, az ügyfélnek le kell állítania a hálózati tevékenységet, és meg kell próbálnia új címet szerezni, kezdve a DHCPDISCOVER kéréssel.
A Microsoft először a Windows NT 3.5 1994 -ben kiadott szerververziójához mellékelt DHCP-kiszolgálót . A Windows 2000 Server rendszertől kezdve a Microsoft DHCP-kiszolgáló megvalósítása lehetővé teszi a DNS -rekordok dinamikus frissítését , amely az Active Directoryban használatos .
Az Internet Systems Consortium 1997. december 6-án kiadta az ISC DHCP Server első verzióját ( Unix -szerű rendszerekre) . 1999. június 22- én megjelent a 2.0-s verzió, amely jobban megfelelt a szabványnak.
A Cisco 1999 februárjában egy DHCP-kiszolgálót is beépített a Cisco IOS 12.0-ba. A Sun 2001 júliusában hozzáadott egy DHCP-kiszolgálót a Solaris 8- hoz .
Jelenleg a DHCP-kiszolgáló Windows operációs rendszerhez való megvalósítása létezik különálló programok formájában, beleértve a nyíltakat is [5] , amelyek lehetővé teszik, hogy az operációs rendszer nem kiszolgáló verzióit futtató számítógépek DHCP-kiszolgálóként működjenek.
TCP / IP protokollok az OSI modell rétegei szerint | Alapvető|
---|---|
Fizikai | |
csatornázott | |
hálózat | |
Szállítás | |
ülés | |
Reprezentáció | |
Alkalmazott | |
Egyéb alkalmazva | |
A TCP és UDP portok listája |