DHCP (Dynamic Host Configuration Protocol) Labolatorium Numer 3

DHCP (Dynamic Host Configuration Protocol)
Labolatorium Numer 3
DHCP jak sama nazwa wskazuje zajmuje się dynamicznym przydzielaniem adresów IP.
DHCP jest protokołem komunikacyjnym umoŜliwiającym komputerom uzyskanie od
serwera danych konfiguracyjnych, np. adresu IP hosta, adresu IP bramy sieciowej, adresu
serwera DNS, maski sieci.. DHCP został opublikowany jako standard w roku 1993. [1]
Dynamiczne przydzielanie adresów IP jest funkcją niezwykle waŜną dzięki niej
moŜemy połączyć się w sieci z innym komputerem czy teŜ wyspecjalizowanym serwerem
właśnie zajmującym się przydzielaniem takich adresów. Wyobraźmy sobie sytuacje Ŝe
chcemy przydzielić adresy IP w firmie która zawiera pięć tysięcy hostów powiedzmy Ŝe jest
to jeszcze moŜliwe ale przy większej ilości typu sto tysięcy zajęło by to nam pół Ŝycia.
Dlatego teŜ wymyślono rozwiązanie automatyzujące ten problem. Rozwiązanie jest dość
oczywiste stosując moŜemy zaimplementować czy to softowe czy teŜ specjalne hardwer-owe
typu serwera DHCP sposoby przydzielania takich adresów. Oprócz tego dany dhcp „pilnuje”
by dane rekordy adresów się nie powtarzały. MoŜliwości przetrzymywania takiej puli
adresów jest wiele począwszy od prostych plików tekstowych skończywszy na duŜych bazach
danych nie zapominając równocześnie o szybkości dotarcia do danego konkretnego adresu ale
o tym za chwilę .[3]
MoŜemy wyróŜnić trzy podstawowe w protokole DHCP techniki przydzielania
adresów IP:
przydzielanie ręczne oparte na tablicy adresów MAC oraz odpowiednich dla nich
adresów IP. Jest ona tworzona przez administratora serwera DHCP. W takiej sytuacji
prawo do pracy w sieci mają tylko komputery zarejestrowane wcześniej przez obsługę
systemu.
przydzielanie automatyczne, gdzie wolne adresy IP z zakresu ustalonego przez
administratora są przydzielane kolejnym zgłaszającym się po nie klientom.
przydzielanie dynamiczne, pozwalające na ponowne uŜycie adresów IP. Administrator
sieci nadaje zakres adresów IP do rozdzielenia. Wszyscy klienci mają tak
skonfigurowane interfejsy sieciowe, Ŝe po starcie systemu automatycznie pobierają
swoje adresy. KaŜdy adres przydzielany jest na pewien czas. Taka konfiguracja
powoduje, Ŝe zwykły uŜytkownik ma ułatwioną pracę z siecią.
Rys. Opis protokołu DHCP [2]
KaŜda z tych trzech technik jest akceptowalna jak i zarówno uŜywana do dziś. Zajmijmy
się rozwiązaniem najciekawszym jakim jest serwer DHCP o którym wcześniej
wspomnieliśmy. Jest to rozwiązanie bardzo skuteczne dzięki takiemu serwerowi i
specjalnej konfiguracji go na danym hoście dostajemy moŜliwości automatyzacji obsługi
adresów i ich przydzielania. Dany uŜytkownik który kieruje zapytanie do serwera dhcp
dostaje w zamian paczkę w której zawierane są informacje na temat jaki IP adres jest nam
przydzielany przez serwer jest to załoŜenie pierwotne. Następnie zawierać się tez mogą
informacje o:
nazwa DNS
adres IP bramy sieciowej (ang. gateway)
adres broadcast
maska podsieci
maksymalny czas oczekiwania na odpowiedź w protokole ARP
wartość MTU (maksymalny rozmiar pakietu)
adresy serwerów NIS
domena NIS
adres IP serwera SMTP
adres serwera TFTP
adres serwera nazw NetBIOS
czasie dzierŜawy (podajemy go w godzinach)
Dany uŜytkownik po otrzymaniu takich informacji potwierdza automatycznie
przyjęcia takich danych z powrotem do serwera DHCP. MoŜemy wyróŜnić parę faz
korzystania z takich rozwiązań np.
Poszukiwanie serwera DHCP Klient chcący się połączyć z serwerem wysyła do sieci
lokalnej pakiety rozgłoszeniowe zaadresowane do wszystkich odbiorców. Procedura ta nosi
nazwę DHCP DISCOVER – odkrywanie DHCP. Czasami routery są konfigurowane, aby
przekazywały pakiety DHCP do właściwego serwera w innej podsieci. Pakiety mają adres
docelowy rozgłoszeniowy 255.255.255.255 i zawierają prośbę o ostatnio uŜywany adres IP
(np. 192.168.1.100). MoŜe ona zostać zignorowana przez serwer.
Oferta DHCP (ang. DHCP Offer) jest składana przez serwer, który określa właściwą
konfigurację klienta na podstawie sprzętowego adresu urządzenia sieciowego określonego w
polu CHADDR (w sieci lokalnej to adres MAC). W polu YIADDR serwer przekazuje
klientowi jego adres IP.
śądanie DHCP (ang. DHCP Request) jest wysyłane przez klienta, który juŜ
rozpoznał serwer DHCP, ale chce uzyskać inne parametry konfiguracji. Dla przykładu moŜe
ponownie zaŜądać adresu IP 192.168.1.100. RFC 2131 wprowadza dodatkowo zapytanie typu
DHCPINFORM. Klient stosuje je, gdy ma juŜ przypisany adres IP (np. ręcznie), lecz nadal
nie zna pozostałych wymaganych parametrów. W odpowiedzi serwer wysyła pakiet
potwierdzenia DHCP z pustym polem YIADDR oraz nie ustawionym czasem dzierŜawy
adresu.
Potwierdzenie DHCP (ang. DHCP Acknowledge) jest wysyłane jako odpowiedź na
Ŝądanie. Zakłada się, Ŝe reakcją klienta na potwierdzenie będzie odpowiednie
skonfigurowanie interfejsu sieciowego.
OdświeŜanie DHCP Elementem przydzielenia klientowi adresu IP przez serwer
DHCP jest przyznanie dodatkowo tzw. czasu dzierŜawy (lease). Określa on czas waŜności
ustawień. W tle pracują dwa zegary - T1 odmierza połowę czasu uŜytkowania, zaś T2 - 87,5
procent pełnego czasu uŜytkowania. Obie wartości moŜna zmienić w opcjonalnych
ustawieniach serwera DHCP - jeśli takie funkcje zostały zaimplementowane. Po upływie
czasu T1 klient wysyła komunikat DHCPREQUEST do serwera i pyta, czy serwer moŜe
przedłuŜyć czas uŜytkowania. Stan ten określa się jako renewing status. Z reguły serwer
odpowiada wiadomością DHCPACK i przydziela nowy czas uŜytkowania. Serwer resetuje
wówczas zegary T1 i T2. JeŜeli po upływie czasu T2 klient nie otrzyma wiadomości
DHCPACK, rozpoczyna się tak zwany rebinding status. Klient musi wysłać komunikat
DHCPREQUEST, Ŝeby uzyskać przedłuŜenie czasu uŜytkowania. Serwer moŜe odpowiedzieć
na to Ŝądanie potwierdzeniem DHCPACK. JeŜeli jednak i to Ŝądanie pozostanie bez
odpowiedzi, klient musi zaŜądać nowego adresu IP. Wkracza wówczas ponownie opisany na
początku mechanizm, który rozsyła zapytania do wszystkich serwerów DHCP w sieci.
Inne usługi typu dynamiczne adresy usługą DHCP jest przydzielanie stałych bądź
tymczasowych adresów IP dla klientów. Podstawowy mechanizm dynamicznego przydziału
adresów sieciowych jest prosty: klient co jakiś czas prosi o przydział adresu. Mechanizm
alokacji gwarantuje, Ŝe adres przypisany do danego klienta nie zostanie przydzielony innemu
przed upływem określonego czasu i jeŜeli klient, który ma juŜ przydzielony adres zgłosi się w
odpowiednim czasie, to ten sam adres sieciowy dalej będzie mu przysługiwał. Termin
określający czas, na jaki zostaje przydzielony adres dla danego klienta to "dzierŜawa" (lease).
Klient moŜe przedłuŜyć dzierŜawę przez odpowiednie zapytanie do serwera. MoŜe wysłać
wiadomość do serwera, Ŝe juŜ nie potrzebuje danego adresu IP. MoŜe teŜ poprosić serwer o
stałe przydzielenie adresu przez zapytanie o nieskończoną dzierŜawę (infinite lease). Podczas
przydziału "stałego" adresu serwer moŜe dać dzierŜawę o długim, lecz nie nieskończonym
czasie, aby wykryć, czy klient rzeczywiście jest cały czas przyłączony do sieci. W niektórych
środowiskach moŜe być konieczne przydzielanie na nowo adresów, kiedy wyczerpią się te
dostępne. W takich przypadkach moŜe być wykorzystany mechanizm, który uŜywa adresów,
którym zakończył się czas dzierŜawy. Serwer powinien uŜyć wszystkich informacji, które są
dostępne w składnicy parametrów, aby wybrać odpowiedni adres do ponownego przydziału.
Na przykład, przed nową alokacją adresu powinien sprawdzić, czy adres ten nie jest uŜywany,
wysyłając np. pakiet z prośbą o ICMP echo.
Zastosowanie protokołu DHCP opis:
Alokowanie adresów sieciowych opis: [2]
JeŜeli klient juŜ zna swój adres sieciowy, niektóre kroki mogą zostać pominięte:
1. Klient wysyła broadcast z wiadomością DHCPDISCOVER do swojej lokalnej,
fizycznej podsieci. Wiadomość DHCPDISCOVER powinna zawierać opcję, która
sugeruje wartości dla adresu sieciowego i czasu dzierŜawy. Agenci przekazujący
powinni podać taką wiadomość do serwera DHCP, który nie znajduje się w danej
podsieci.
2. KaŜdy serwer powinien odpowiedzieć wiadomością DHCPOFFER, która zawiera
dostępny adres sieciowy (i inne parametry konfiguracyjne w opcjach). By działać
efektywniej, serwer nie powinien rezerwować oferowanego adresu. Kiedy alokowany
jest nowy adres, serwer powinien sprawdzić (np. poprzez ICMP Echo Request), czy
oferowany adres nie jest uŜywany przez innego klienta. Implementacja serwera
powinna być taka, Ŝe administrator moŜe wyłączyć opcję sprawdzania, czy oferowany
adres jest juŜ w uŜyciu. Serwer powinien uŜywać agentów przekazujących do
przesyłania wiadomości DHCPOFFER, kiedy to jest potrzebne.
3. Klient otrzymuje jedną lub więcej wiadomości DHCPOFFER z jednego bądź paru
serwerów. MoŜe wybrać oczekiwanie na następne odpowiedzi z innych serwerów.
Klient wybiera jeden z serwerów, z którego otrzymał DHCPOFFER. Wysyła
broadcast z wiadomością DHCPREQUEST, w której musi być zawarty "identyfikator
serwera" (server identifier) określający, który serwer został wybrany.
4. Serwer otrzymuje broadcast z DHCPREQUEST od klienta. Serwery, które otrzymały
wiadomość DHCPREQUEST a nie są ich identyfikatorami, uznają, Ŝe klient
zrezygnował z ich oferty. Serwer wybrany przez klienta wiąŜe go ze sobą i wysyła
wiadomość DHCPACK, która zawiera parametry konfiguracyjne dla klienta.
Kombinacja "identyfikatora klienta" (client identyfier) i przypisanego adresu
sieciowego tworzą unikalny identyfikator dzierŜawy klienta, który będzie uŜywany
przez klienta i serwer w następnych wiadomościach DHCP. JeŜeli serwer nie moŜe
spełnić wymagań stawianych w wiadomości DHCPREQUEST, musi wysyłać
komunikat DHCPNAK.
5. Klient otrzymuje wiadomość DHCPACK z parametrami konfiguracyjnymi. W tym
momencie powinien sprawdzić otrzymane ustawienia i zapisać czas trwania dzierŜawy
wyspecyfikowania w wiadomości DHCPACK. W tym momencie klient jest juŜ
odpowiednio skonfigurowany.
6. JeŜeli klient wykryje, Ŝe dany adres jest juŜ w uŜyciu (np. przez uŜycie komendy
ARP), musi wysłać komunikat DHCPDECLINE do serwera i rozpocząć proces
konfiguracji od nowa. Klient powinien poczekać co najmniej 10 sekund, zanim
rozpocznie od nowa proces konfiguracji (w celu zapobieŜenia obciąŜenia sieci). JeŜeli
klient otrzyma wiadomość DHCPNAK, to rozpoczyna proces konfiguracji od nowa.
JeŜeli klient nie otrzyma Ŝadnej z wiadomości (DHCPACK czy DHCPNAK), to
wysyła znowu wiadomość DHCPREQUEST. Klient powinien wysłać cztery razy
wiadomość DHCPREQUEST (z timeoutami 60 sekund). Jeśli po tym czasie serwer
nie odpowie, powinien rozpocząć proces konfiguracji od początku.
7. Klient moŜe się zrzec dzierŜawy adresu przez wysłanie wiadomości DHCPRELASE
do serwera. Klient identyfikuje swoją dzierŜawę przez "identyfikator klienta" (client
identifier) i adres sieciowy.
Opis pojęć uŜytych w tekście:
DHCP klient komputer w sieci TCP/IP, który uŜywa DHCP do pobrania informacji o
konfiguracji, takich jak adres sieciowy.
DHCP serwer komputer w sieci TCP/IP, który zwraca konfiguracje do klientów DHCP.
Agent przekazujący BOOTP komputer bądź router w sieci TCP/IP, który przekazuje
wiadomości pomiędzy DHCP klientem, a DHCP serwerem.
Powiązania (ang. binding) kolekcja parametrów konfiguracyjnych, które zawierają co
najmniej adres IP DHCP klienta. Powiązania zarządzane są przez serwer DHCP
Ponowne uŜycie adresu
1. Klient wysyła broadcast z wiadomością DHCPREQUEST w lokalnej podsieci.
Wiadomość zawiera adres klienta w opcji "requested IP address".
2. Serwer, który zna konfigurację klienta, odpowiada wiadomością DHCPACK. Serwer
nie powinien sprawdzać, czy adres jest juŜ w uŜyciu. Klient w tym momencie
powinien wysłać ICMP Echo Request. JeŜeli Ŝądanie klienta jest błędne (np. został
przeniesiony do innej podsieci), serwer powinien odpowiedzieć komunikatem
DHCPNAK.
3. Klient otrzymuje wiadomość DHCPACK z parametrami konfiguracyjnymi. JeŜeli
klient otrzyma wiadomość DHCPNAK, oznacza to, Ŝe nie moŜe powtórnie uŜyć
zapamiętanego adresu i musi rozpocząć proces konfiguracji od początku.
4. Klient moŜe się zrzec dzierŜawy adresu przez wysłanie wiadomości DHCPRELASE
do serwera. Klient identyfikuje swoją dzierŜawę przez "identyfikator klienta" (client
identifier) lub pole "chaddr" i adres sieciowy.
5. Interpretacja i prezentacja wartości czasowych.
Klient nabywa adres sieciowy w dzierŜawie, która ma określony czas (moŜe to być czas
nieskończony). W protokole DHCP czas dzierŜawy jest określony liczbą sekund. Wartość jest
zarezerwowana dla reprezentacji "czas nieskończony". MoŜe się zdarzyć, Ŝe klient i serwer
nie mają zsynchronizowanych zegarów, jednak w DHCP czas jest reprezentowany relatywnie.
Reprezentacja czasu jest ilością sekund w 32--bitowym słowie, co daje przedział od 0 do
około 100 lat; powinno to w zupełności wystarczyć do dzierŜawy adresów sieciowych.
Pobieranie parametrów w przypadku zewnętrznie skonfigurowanego adresu
JeŜeli klient otrzymuje adres inną drogą (np. konfiguracja ręczna), powinien uŜyć wiadomości
DHCPINFORM w celu pobrania innych parametrów konfiguracyjnych. Serwer po
otrzymaniu wiadomości DHCPINFORM odpowiada wiadomością DHCPACK, która zawiera
wszystkie informacje potrzebne dla klienta, jednak bez: alokacji adresu sieciowego,
sprawdzania powiązania, zapełnienia pola "yiaddr" lub zawierającego informacje o czasie
dzierŜawy. Serwer musi wysłać wiadomość DHCPACK jako unicast dla adresu podanego w
polu "ciaddr" w wiadomości DHCPINFORM.
Parametry klienta DHCP
Nie wszyscy klienci potrzebują przydzielenia wszystkich parametrów w DHCP. Istnieją dwie
techniki zmniejszenia liczby parametrów przekazywanych przez serwer do klienta. Pierwsza
polega na tym, Ŝe większość parametrów jest domyślnie zdefiniowana w dokumentach RFC
określających, czego potrzebuje komputer do pracy w sieci. Jeśli klient nie dostanie
parametrów od serwera, wtedy uŜywa właśnie parametrów domyślnych. Druga polega na
tym, Ŝe w wiadomościach DHCPDISCOVER lub DHCPREQUEST klient podaje listę tylko
tych parametrów, których potrzebuje.
Dodatkowo klient moŜe zasugerować wartość adresu sieciowego lub czasu dzierŜawy w
wiadomości DHCPDISCOVER. Klient moŜe uŜyć opcji "request IP address" do
zasugerowania, jaki adres chciałby otrzymać, a za pomocą opcji "IP address lease time" moŜe
zasugerować, jaki chciałby otrzymać czas dzierŜawy. JeŜeli serwer otrzyma w wiadomości
DHCPREQUEST zły adres w polu "request IP address", to powinien wysłać wiadomość
DHCPNAK i wygenerować raport do administratora systemu. [2]
[1] pl.wikipedia.org/wiki
[2] www.pckurier.pl
[3] Windows Server 2003. Księga eksperta Autorzy: Rand Morimoto, Michael Noel, Omar
Droubi, Kenton Gardinier, Noel Neal Data wydania: 02/2004
Opracował: Adam Kaltenbek