DHCP (Dynamic Host Configuration Protocol) Labolatorium Numer 3

Transkrypt

1 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 [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ą

2 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

3 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 i zawierają prośbę o ostatnio uŝywany adres IP (np ). 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 RFC 2131 wprowadza dodatkowo zapytanie typu

4 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

5 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

6 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

7 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.

8 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] [3] Windows Server Księga eksperta Autorzy: Rand Morimoto, Michael Noel, Omar Droubi, Kenton Gardinier, Noel Neal Data wydania: 02/2004 Opracował: Adam Kaltenbek