Rozdział 9.
Konfiguracja automatyczna

W tym rozdziale:

• Wprowadzenie do konfiguracji automatycznej

• Protokół BOOTP

• Protokół DHCP

Większość z nas odkryła, iż prawidłowe zainstalowanie i konfiguracja TCP/IP na potrzeby łączności i eksploatacji sieci to zadania wymagające ciągłej pracy. Administrator musi posiadać duże doświadczenie, aby zmusić instalację do pracy. W trakcie lektury Czytelnik zapewne zastanawiał się przynajmniej raz, czy całego tego procesu nie dałoby się zautomatyzować, podobnie jak w przypadku technologii plug-and-play, która pozwala użytkownikom korzystać z oprogramowania natychmiast po zainstalowaniu, bez konieczności ręcznej konfiguracji. W automatycznej konfiguracji TCP/IP w sieci najważniejszą rolę grają protokół BOOTP (BOOTstrap Protocol) oraz jego następca — DHCP (Dynamic Host Configuration Protocol).

W niniejszym rozdziale przedstawione zostaną sposoby automatycznego konfigurowania protokołu TCP/IP oraz rola w tym procesie protokołów BOOTP i DHCP. Omówimy proces ładowania początkowego (bootstrap), format pakietu danych BOOTP, słabe strony tego protokołu oraz rutery stosujące BOOTP. Opiszemy tutaj również proces DHCP, zasady dzierżawy, zakresy i opcje serwera DHCP, format pakietu danych DHCP i trasowanie DHCP.

Wprowadzenie
do konfiguracji automatycznej

Aby zainstalować i skonfigurować oprogramowanie TCP/IP, potrzebne są następujące informacje:

• adresy IP urządzeń TCP/IP,

• adresy sieci,

• maski podsieci,

• nazwa domeny, do której należy urządzenie,

• adres bramy domyślnej (rutera),

• adres serwera nazw.

Automatyczna konfiguracja w przypadku TCP/IP oznacza, że użytkownicy nie muszą ręcznie wpisywać danych, zamiast tego mogą korzystać z komputera zaraz po podłączeniu do sieci.

Automatyczna konfiguracja jest często nazywana autokonfiguracją.

Korzyści z konfiguracji automatycznej

Konfiguracja automatyczna ma wiele zalet w porównaniu z tradycyjnymi metodami ręcznego konfigurowania TCP/IP. Korzyści te staną się bardziej oczywiste, gdy porównamy obie metody — patrz tabela 9.1.

Tabela 9.1. Konfiguracja ręczna i konfiguracja automatyczna — porównanie

Konfiguracja ręczna		Konfiguracja automatyczna
Administrator sieci musi przydzielić unikatowy adres IP do każdego urządzenia. Jeśli urządzeń w sieci jest dużo, zadanie to może być nużące.		Każde urządzenie sieciowe automatycznie otrzymuje unikatowy adres IP. W rezultacie praca administratora jest o wiele łatwiejsza.
Niewłaściwe lub powtarzające się adresy IP mogą powodować mnóstwo kłopotów, ponieważ administrator musi ręcznie wyszukiwać urządzenia o niepoprawnych adresach.		Ponieważ adresy przydzielane są automatycznie, prawdopodobieństwo wystąpienia błędnych lub powtarzających się adresów jest praktycznie zerowe.
Administrator oprócz adresów IP musi wprowadzać maski podsieci i adresy domyślnych ruterów (bram).		Informacje dotyczące adresu domyślnego rutera oraz maski podsieci są konfigurowane automatycznie.
W każdym urządzeniu dodatkowe informacje, takie jak strefa czasowa, adres IP serwera czasu, adres IP serwera inicjującego i nazwa pliku inicjującego muszą być konfigurowane ręcznie.		Dodatkowe informacje są konfigurowane automatycznie.
Administratorzy mogą mieć problemy z przenoszeniem urządzeń z jednej podsieci do drugiej.		Przenoszenie urządzeń między podsieciami nie stanowi zbyt dużego problemu, ponieważ przeniesione urządzenia powinny odpowiednio skonfigurować się automatycznie.
Administrator musi ręcznie zarządzać urządzeniami w sieci.		Automatyczna konfiguracja pozwala na centralne zarządzanie urządzeniami, co oszczędza administratorowi biegania od komputera do komputera.
Konfiguracja ręczna jest wysoce zależna od administratora.		Konfiguracja automatyczna znacząco zmniejsza zakres odpowiedzialności administratorów, zaś użytkownicy nie muszą być całkowicie od nich zależni.
	Adresy serwerów domen i nazw nie mogą być konfigurowane automatycznie. Musimy wpisać je ręcznie.

Konfiguracja w sieciach wielosegmentowych

Obecnie, w środowisku dużych korporacji nacisk przeniósł się z sieci lokalnych na globalne sieci wielosegmentowe. Sieć taka składa się z małych, średnich i dużych sieci lokalnych połączonych ruterami. To przesunięcie środka ciężkości wywołało kilka problemów, związanych z automatyczną konfiguracją TCP/IP:

• Urządzenie sieciowe podczas uruchomienia do automatycznego skonfigurowania wymaga informacji, które zasadniczo otrzymuje z zewnętrznego źródła — serwera inicjującego (każdy komputer przechowujący wymagane do rozruchu informacje jest tzw. serwerem inicjującym — boot server). Jeśli serwer ten mieści się w lokalnej podsieci, otrzymanie informacji może być łatwe. Jeśli jednak serwer inicjujący mieści się w innej podsieci, żądanie danych konfiguracyjnych musi zostać przesłane przez ruter. Tego typu informacje zazwyczaj nie są przekazywane przez rutery.

• Jeśli serwer inicjujący jest wyłączony lub z jakiegoś powodu niedostępny, cała sieć może przestać działać, ponieważ hosty nie będą mogły otrzymać od serwera danych uruchomieniowych.

Ręczna konfiguracja informacji w urządzeniach sieciowych jest nudną pracą, zwłaszcza w dużych sieciach. Ponadto rutery nie są zdolne do przesyłania żądań i odpowiedzi związanych z konfiguracją, co doprowadziło do opracowania kolejno dwóch protokołów — BOOTP i DHCP. Protokoły te udostępniają niezbędne mechanizmy przesyłania danych konfiguracyjnych do hostów w sieci TCP/IP, aby wyeliminować konieczność ręcznej konfiguracji poszczególnych urządzeń w sieci. Inaczej mówiąc, protokoły BOOTP i DHCP pozwalają na automatyczne konfigurowanie niezbędnych informacji przez urządzenia sieciowe, na podłączenie do sieci i rozpoczęcie pracy, co odciąża w pewnym stopniu i tak zapracowanych administratorów sieciowych.

Protokół BOOTP

Każde urządzenie potrzebuje w chwili uruchomienia danych systemowych. Te informacje uruchomieniowe — inaczej informacje inicjujące (boot information) — są w komputerze umieszczone w sektorze ładowania początkowego dysku twardego. Jednakże w przypadku komputerów bezdyskowych informacje te nie są dostępne. W środowisku sieciowym takie komputery również potrzebują unikatowych adresów IP, wobec tego muszą je otrzymać z zewnętrznego źródła. Z tego powodu komputery bezdyskowe, tzw. „głuche terminale” (dumb terminal), używają protokołu RARP (Reverse Address Resolution Protocol — protokół odwrotnego rozwiązywania adresów) do pobrania poprawnego adresu IP i informacji inicjujących z serwera inicjującego. RARP ma jednak braki, które sprawiają, że nie nadaje się do pobierania danych konfiguracyjnych podczas rozruchu:

• Pakiet wymieniany pomiędzy serwerem i klientem zawiera tylko czterobajtowy adres IP klienta. Klient do uruchomienia potrzebuje jeszcze dodatkowych informacji, których pakiet RARP nie dostarcza.

• RARP do identyfikacji hosta używa jego adresu MAC, wobec tego nie nadaje się do użytku w sieciach, w których adresy sprzętowe są przydzielane dynamicznie.

Więcej informacji o protokole RARP zawiera rozdział 4.

Protokół BOOTP (BOOTstrap Protocol) został opracowany jako środek zaradczy na niedostatki protokołu RARP. Komunikat (pakiet) BOOTP oprócz adresu IP zawiera informacje startowe, niezbędne, aby z powodzeniem uruchomić komputer bezdyskowy. Ten sam komunikat zawiera też adres serwera BOOTP i domyślnego rutera lub bramy w sieci. Ponadto protokołu BOOTP możemy z powodzeniem używać w sieciach, w których adresy sprzętowe przydzielane są dynamicznie.

Proces ładowania początkowego BOOTP

Proces ładowania początkowego (bootstrap) w protokole BOOTP składa się z dwóch faz. Pierwsza z nich jest fazą ustalenia adresu i wyboru pliku inicjującego. Po otrzymaniu przez klienta adresu IP oraz wyborze wymaganego pliku inicjującego, kontrolę przejmuje faza druga — faza przesłania pliku inicjującego. W jej trakcie klient używa protokołu transferu danych do pobrania pliku inicjującego z serwera inicjującego. Fazy te przebiegają następująco:

• Faza ustalenia adresu i wyboru pliku inicjującego — komputer bezdyskowy podczas uruchomienia wysyła żądanie adresu IP oraz pliku inicjującego do serwera BOOTP przez port 68. Serwer inicjujący oczekuje na żądania BOOTP (oraz DHCP) na porcie 67. Serwer po zidentyfikowaniu stacji roboczej klienta za pomocą adresu MAC, wysłanego razem z żądaniem klienta, wybiera plik inicjujący wstępnie skonfigurowany dla danego klienta.

Serwer inicjujący nie musi działać w tym samym komputerze, który przechowuje pliki inicjujące. Ogólnie mówiąc, taki serwer używa prostej bazy danych, w której pliki inicjujące przypisane są do nazw lub aliasów. W związku z tym pliki inicjujące mogą być składowane w innym komputerze, z którym w razie potrzeby serwer inicjujący się łączy, aby pobrać odpowiedni plik inicjujący.

• Faza przesłania pliku inicjującego — po zidentyfikowaniu przez serwer BOOTP klienta i wyborze odpowiedniego pliku inicjującego, klient przesyła (kopiuje) ten plik do swojej pamięci za pomocą odpowiedniego protokołu, na przykład TFTP (Trivial File Transfer Protocol) lub FTP.

Zawartość pakietu BOOTP

Pakiet BOOTP składa się z 15 pól, których długość jest stała. Dzięki temu implementacja protokołu BOOTP jest prosta i wystarczająco nieduża, by zmieścić się w pamięci klienta. Z tego samego powodu żądania i odpowiedzi BOOTP mają wspólny format. Rysunek 9.1 przedstawia format pakietu BOOTP.

Rysunek 9.1. Format pakietu BOOTP

Pola pakietu BOOTP to:

• OP — pole o długości 1 bajta, określające typ komunikatu. Jeśli komunikat jest żądaniem ze strony klienta, to wartość pola wynosi 1. Gdy jest odpowiedzią serwera inicjującego — wartość pola wynosi 2.

• HTYPE (typ sprzętu) — określa sprzętowy typ interfejsu używanego przez urządzenie nadające. Na przykład, interfejs Ethernet jest reprezentowany przez wartość 1. Pole to ma długość 1 bajta.

• HLEN (długość adresu sprzętowego) — określa długość adresu sprzętowego, zawartego w polu Typ sprzętu. Na przykład, wartość pola równa 6 oznacza adres interfejsu Ethernet. Pole ma długość 1 bajta.

• Hopy — oznacza liczbę serwerów, przez które komunikat był przesyłany. Klient ustawia wartość tego pola na 0. Gdy serwer przesyła komunikat do następnego serwera, liczba hopów (przeskoków) zwiększana jest o 1. Pole o długości 1 bajta.

• XID (ID transakcji) — zawiera generowaną losowo liczbę całkowitą, używaną przez klienta do zestawienia swojego żądania z odpowiedzią na nie. Pole to ma długość 4 bajtów.

• Sekundy — liczba sekund od rozpoczęcia procesu uruchomienia klienta. Pole o długości 2 bajtów.

• Nie używane — pole nie używane, o długości 2 bajtów.

• CIAddr (Adres IP klienta) — jeśli klient zna swój adres IP, to pole zawiera ten adres; w przeciwnym razie — ma wartość równą 0. Pole o długości 4 bajtów.

• YIAddr (Twój adres IP) — jeśli w komunikacie żądającym inicjacji odebranym od klienta pole CIAddr było puste, to pole YIAddr zawiera podany przez serwer adres IP klienta. Inaczej mówiąc, serwer wypełnia to pole, gdy klient nie zna swojego adresu IP; w przeciwnym razie pole jest ignorowane. Pole o długości 4 bajtów.

• SIAddr (Adres IP serwera) — zawiera adres IP serwera, który może być wprowadzony zarówno przez serwer w komunikacie odpowiedzi, jak i przez klienta w komunikacie żądania inicjacji. Jeśli klient zna adres IP serwera, od którego może otrzymać dane uruchomieniowe, to wypełnia to pole; w przeciwnym razie pole otrzymuje wartość 0. Dowolny serwer inicjujący, który potrafi odpowiedzieć na żądanie, w komunikacie odpowiedzi wprowadza własny adres IP. Pole o długości 4 bajtów.

• GIAddr/RIAddr (Adres IP bramy lub rutera) — zawiera adres IP domyślnego rutera lub bramy. Pole to jest opcjonalne i wymagane tylko wtedy, gdy serwer inicjujący mieści się w innej podsieci. Pole o długości 4 bajtów.

• CHAddr (adres sprzętowy klienta) — zawiera adres sprzętowy (MAC) klienta. Pole wypełniane jest przez klienta i ma długość 16 bajtów.

• Nazwa serwera — zawiera nazwę hosta serwera i może być wypełnione zarówno przez serwer w komunikacie odpowiedzi, jak i przez samego klienta w komunikacie żądania inicjacji. Jeśli klient zna nazwę serwera, od którego może otrzymać dane uruchomieniowe, to wypełnia to pole; w przeciwnym razie pole otrzymuje wartość 0. Dowolny serwer inicjujący, który potrafi odpowiedzieć na żądanie, w komunikacie odpowiedzi wprowadza do tego pola własną nazwę. Użycie pola jest nieobowiązkowe; jego długość wynosi 64 bajty.

• Nazwa pliku inicjującego — zawiera ogólną nazwę pliku inicjującego, potrzebnego klientowi do pomyślnego uruchomienia. Pole to może być wypełnione przez klienta, jeśli zna on nazwę pliku, albo przez serwer w komunikacie odpowiedzi. Nazwa zawiera pełną ścieżkę dostępu; długość pola wynosi 128 bajtów.

• Dane producenta — zawiera zamieszczone przez producenta opcjonalne informacje, które muszą zostać przekazane z serwera do klienta. Do tych danych w żądaniu inicjacji może zaliczać się typ sprzętu lub numer seryjny klienta, zaś w odpowiedzi identyfikator zdalnego systemu plików. Mogą się tu również znaleźć: maska podsieci dla lokalnej sieci, adres IP serwera czasu, adres IP serwera domeny lub rozmiar pliku inicjującego. Pole o długości 64 bajtów.

Rutery obsługujące protokół BOOTP

W sieciach TCP/IP rutery służą do łączenia urządzeń i wymiany informacji pomiędzy różnymi fizycznymi segmentami sieci, które noszą nazwę podsieci. Sytuacja, w której klient i serwer inicjujący położone są w różnych podsieciach jest całkiem prawdopodobna, zwłaszcza w środowiskach, gdzie używane są komputery przenośne. Aby umożliwić uruchamianie przez ruter, żądania BOOTP muszą przejść przez jeden lub kilka ruterów.

Dodatkowe informacje o ruterach i podsieciach zawiera rozdział 5.

Gdyby pakiety BOOTP nie były przepuszczane przez rutery, administrator sieci musiałby umieścić w każdej podsieci osobny serwer — zadanie kosztowne i czasochłonne. Można jednak znaleźć na rynku rutery, które rozpoznają pakiety BOOTP i pozwalają na ich przesyłanie do miejsca przeznaczenia. Są to tzw. rutery obsługujące BOOTP lub rutery obsługujące BOOTP i DHCP (BOOTP-enabled router, BOOTP/DHCP-enabled router). Są one dostosowane do funkcjonalności agentów przekazujących BOOTP (BOOTP relay agent). Jak nazwa sugeruje, agent przekazujący BOOTP przekazuje komunikaty pomiędzy klientami i serwerami inicjującymi położnymi w odrębnych sieciach.

Czytelnik na stanowisku administratora sieci może zetknąć się z sytuacją, w której uruchamianie klientów z serwera po drugiej stronie rutera będzie niezbędne, lecz ruter nie będzie przepuszczał komunikatów BOOTP. Jeśli na dodatek ograniczenia budżetu nie pozwolą zainwestować w nowy ruter obsługujący protokół BOOTP, można użyć serwera proxy (lub innego) i skonfigurować go do roli agenta przekazującego. W tym celu wystarczy zainstalować sieciowy system operacyjny — na przykład Windows NT 4.0 lub Windows 2000 — który ma wbudowanego agenta przekazującego BOOTP i DHCP.

Wady protokołu BOOTP

Wraz ze wzrostem popularności komputerów przenośnych środowisko sieciowe zmieniło swój charakter ze statycznego na dynamiczny. W środowisku statycznym każde urządzenie jest na stałe podłączone do sieci i konfiguracja sieci nie ulega zmianie przez tygodnie lub nawet miesiące. Jednakże w środowisku dynamicznym konfiguracja może zmieniać się codziennie, ponieważ palmtopy, notebooki i podobne urządzenia są łatwe do przenoszenia z miejsca na miejsce.

Protokół BOOTP został opracowany dla statycznego środowiska sieciowego, w którym raz utworzony plik konfiguracyjny BOOTP mógł być używany do określenia parametrów wszystkich urządzeń, które informacji potrzebowały. Plik ten zawierał odwzorowania wszystkich hostów w sieci razem z parametrami dla nich. Im więcej hostów w sieci potrzebowało danych inicjacyjnych z zewnętrznego źródła, tym większą objętość miał plik konfiguracyjny BOOTP.

Z uwagi na statyczny charakter sieci, pliku konfiguracyjnego BOOTP nie trzeba było aktualizować zbyt często, jednakże w sieciach dynamicznych zarządzanie plikiem BOOTP staje się zajęciem pełnoetatowym. Po każdym przeniesieniu urządzenia z jednej lokalizacji do innej administrator sieci musi dokonać w bieżących ustawieniach następujących zmian:

• Ponownie wprowadzić parametry BOOTP dla urządzenia — zadanie czasochłonne, jeśli spora liczba urządzeń często zmienia położenie.

• Przydzielić unikatowe adresy IP dla hostów przenoszonych do innej domeny lub podsieci.

Z powyższych powodów BOOTP nie nadążył za szybko rozwijającym się środowiskiem sieci dynamicznych. W rezultacie organizacja IETF (Internet Engineering Task Force) opracowała zaawansowaną wersję BOOTP o nazwie DHCP (Dynamic Host Configuration Protocol — protokół dynamicznej konfiguracji hosta). Protokół DHCP został zaprojektowany, by zaradzić większości niedostatków protokołu BOOTP.

DHCP

Podobnie jak BOOTP, protokół DHCP przydziela pełne dane konfiguracyjne do uruchamianego urządzenia sieciowego. Jest jednak znacznie przydatniejszy od BOOTP, ponieważ dodatkowo pozwala urządzeniom automatycznie pobierać adresy IP. W rezultacie klient DHCP może być przenoszony bez konieczności ręcznej zmiany konfiguracji. Ta zdolność do automatycznej rekonfiguracji ma znaczenie zwłaszcza w przypadku tymczasowych przenosin, gdy host przenoszony jest do innej lokalizacji na bardzo krótki czas (na przykład, na kilka godzin lub dzień). Oprócz dynamicznego przydzielania adresu IP, DHCP posiada wbudowane mechanizmy służące do zarządzania lokalnymi klientami w sieci, rejestracji ruchu sieciowego i podstawowe zabezpieczenia. Równie ważna jest łatwość instalacji, konfiguracji i utrzymywania DHCP. Dzięki tym wszystkim zaletom zadanie zarządzania siecią TCP/IP z pomocą DHCP staje się stosunkowo łatwe.

Protokół DHCP nie tylko rozwiązuje problem dynamicznego przydzielania adresów IP klientom w sieci TCP/IP, lecz również radzi sobie z problemem szybko kurczącej się puli unikatowych adresów IP. W statycznym środowisku sieciowym administrator nadaje unikatowe adresy IP nowym urządzeniom w sieci. Nawet jeśli urządzenie używane jest rzadko (lub tymczasowo), żadne inne urządzenie nie może korzystać z jego adresu IP, choćby był bardzo potrzebny. Dzięki zastosowaniu protokołu DHCP, który dynamicznie przydziela adresy IP, adresy te są przyznawane tylko w miarę potrzeby i zwalniane, gdy nie są potrzebne, co pozwala oszczędzić cenną przestrzeń adresów IP.

Dzierżawy DHCP

Serwer DHCP utrzymuje pulę poprawnych adresów IP, które może przydzielać klientom. Pula adresów IP nosi nazwę zakresu (scope). Klient w trakcie uruchamiania rozgłasza żądanie adresu IP. Wszystkie serwery DHCP, które otrzymają żądanie, zwracają w odpowiedzi adres IP i związane z nim dane konfiguracyjne, dzięki czemu klient może otrzymać wiele odpowiedzi na żądanie. Następnie klient wybiera do swojego użytku odpowiedni adres IP i dzierżawi go od serwera DHCP. Dzierżawa (lease) określa czas, przez który serwer DHCP pozwala klientowi używać określonego adresu IP. Po potwierdzeniu dzierżawy klient staje się częścią funkcjonującej sieci. Gdy ustalony czas upłynie, dzierżawa jest unieważniana przez serwer DHCP.

W dynamicznym środowisku sieciowym dzierżawy są ważne, ponieważ zapobiegają zagarnianiu przez klienty adresów na długi czas. Po wygaśnięciu dzierżawy adres IP wraca do puli (zakresu) adresów serwera, z której adresy mogą być dzierżawione potrzebującym ich klientom. Jeśli jednak klient nadal używa adresu po upłynięciu terminu, serwer może odnowić dzierżawę i pozwolić klientowi używać tego samego adresu. W niektórych przypadkach nieużywane dzierżawy mogą być automatycznie zwracane do puli adresów.

Czas trwania dzierżawy zależy od sieci i wymogów klientów. Na przykład, w sieci przedsiębiorstwa dzierżawa może trwać dzień lub nawet tydzień, zależnie od wykonywanych zadań. Z drugiej strony, dzierżawy w kafejkach internetowych mogą trwać zaledwie godzinę. Z tego powodu specyfikacja DHCP nie zaleca określonego czasu dzierżawy. Jej długość zależy od administratora sieci. DHCP pozwala również na dzierżawy na czas nieokreślony (np. jeśli podamy w polu Lease Duration wartość 0xffffffff). Przyznawanie trwałych dzierżaw przypomina statyczny przydział adresów IP.

Proces dzierżawy DHCP

Proces dzierżawy DHCP, przedstawiony na rysunku 9.2, obejmuje następujące kroki:

Rysunek 9.2. Proces dzierżawy DHCP

1. Klient zostaje uruchomiony i rozgłasza w lokalnej podsieci tzw. komunikat odkrycia DHCP (DHCPDISCOVER). Ta faza nosi nazwę stanu inicjacji.

Jeśli po drodze pomiędzy klientem i serwerem znajduje się ruter, komunikat rozgłoszenia może być przesyłany do innych podsieci. Do tego celu potrzebne są rutery obsługujące protokół BOOTP.

2. Wszystkie serwery, które otrzymały komunikat odkrycia i mogą wydzierżawić adres IP odpowiadają wysyłając komunikat oferty DHCP (DHCPOFFER). Komunikat ten zawiera adres IP i związane z nim dane konfiguracyjne.

3. Klient może otrzymać wiele ofert dzierżawy, w zależności od liczby serwerów DHCP, które odpowiedziały na komunikat odkrycia. Klient wchodzi teraz w stan wyboru, w którym przegląda komunikaty ofert i wybiera jedną z nich.

4. Klient wchodzi w stan żądania — wysyła do odpowiedniego serwera komunikat żądania (DHCPREQUEST), żądając konfiguracji zaoferowanej przez serwer.

5. Serwer wysyła komunikat pozytywnego potwierdzenia (DHCPACK) komunikatu żądania, wysłanego przez klienta. Oprócz adresu IP i danych konfiguracyjnych komunikat ten zawiera informacje o dzierżawie.

6. Klient po otrzymaniu potwierdzenia wchodzi w stan powiązania, w którym wydzierżawiony adres IP jest związany z klientem, a klient staje się częścią sieci. W stanie powiązania klient używa trzech liczników czasu, które kontrolują wygaśnięcie, odnowienie i ponowne nawiązanie dzierżawy.

7. W zależności od ustawień licznika czasu wygaśnięcia, po upływie 50% czasu dzierżawy — lub po jej wygaśnięciu — klient usiłuje odnowić dzierżawę, wysyłając komunikat DHCPREQUEST do serwera, który adres wydzierżawił. Klient może też usiłować zakończyć dzierżawę przed czasem, wysyłając komunikat zwolnienia (DHCPRELEASE).

8. Po wysłaniu do serwera komunikatu DHCPREQUEST, klient wchodzi w stan odnowienia i w tym stanie oczekuje na odpowiedź od serwera. Serwer może w odpowiedzi albo przyjąć żądanie (potwierdzając przez DHCPACK), albo je odrzucić (DHCPNACK). W razie odrzucenia żądania klient zwalnia adres i wraca do stanu inicjacji.

9. Jeśli klient nie otrzyma od serwera odpowiedzi w określonym czasie, to serwer zostaje uznany za wyłączony lub niedostępny. W tym przypadku klient po upływie 87,5% czasu dzierżawy wchodzi w stan ponowienia powiązania. W tym stanie klient zaczyna ponownie rozgłaszać komunikat DHCPREQUEST do wszystkich dostępnych serwerów DHCP.

10. Jeśli klient otrzyma choćby jedną pozytywną odpowiedź, to wraca do stanu powiązania, natomiast jeśli wszystkie serwery odpowiedzą negatywnie, klient powróci do stanu inicjacji.

Strategia dzierżawy

Strategia dzierżawy określa, jak długo ma trwać przeciętna dzierżawa oraz czy odnawianie dzierżaw jest dopuszczalne, czy nie. Strategie dzierżawy mogą się jednak różnić dla poszczególnych klientów i grup klientów, w zależności od ich wymagań. Administratorzy sieci ustanawiają strategię dzierżawy dla całej sieci podczas wstępnej konfiguracji serwera DHCP.

Podczas określania strategii czas dzierżawy zdefiniowany przez administratora musi być wystarczająco krótki, aby pojedynczy klient przez zbyt długi okres nie zawłaszczał adresu IP, i by adresy IP wracały do puli. Czas dzierżawy musi być jednocześnie na tyle długi, by klienty nie musiały regularnie rozgłaszać żądań odnowienia dzierżaw adresów IP i zwiększać niepotrzebnie ruch w sieci. Ponadto, klienty mogą wówczas w razie awarii lub braku dostępu do serwera DHCP poprawnie funkcjonować, dopóki serwer nie zostanie przywrócony do użytku.

Czas dzierżawy można ustalić szacunkowo na dwukrotną wartość przeciętnego czasu niedostępności serwerów DHCP w danej podsieci.

Administrator może ustalić czas dzierżawy na określoną liczbę tygodni, dni lub godzin, przez którą klient ma prawo używać przyznanego adresu IP. Termin upływu czasu dzierżawy adresu IP przyznanego z puli klientowi jest obliczany przez dodanie okresu dzierżawy do znacznika czasowego w komunikacie żądania klienta — DHCPREQUEST. Na przykład, jeśli przydzielimy klientowi adres IP na godzinę (tzn. okres dzierżawy wynosi jedną godzinę), a znacznik czasowy w komunikacie DHCPREQUEST to 20.06. 2001, 14:43, wówczas dzierżawa adresu dla klienta wygaśnie 20.06.2001 r. o 15:43.

Informacje o wygaśnięciu dzierżawy dla klienta można w środowisku Windows NT 4.0 sprawdzić za pomocą narzędzia DHCP Manager. Każdy system operacyjny posiada własne narzędzie służące do tego celu.

Strategia dzierżawy definiuje również, czy klient może żądać odnowienia dzierżawy. Do ustawienia tej funkcji służy opcja negocjacji dzierżawy. Jeśli renegocjacja dzierżawy jest dozwolona przez strategię dzierżawy, klienty mogą wysyłać do serwera żądania odnowienia dzierżawy po upływie 50% okresu dzierżawy. Jednakże administrator sieci powinien przy planowaniu strategii dzierżawy wziąć pod uwagę jeden ważny fakt: jeśli liczba urządzeń w sieci przekracza całkowitą liczbę adresów IP w puli serwera, okres dzierżawy powinien być na tyle krótki, by urządzenia nie czekały nazbyt długo na uzyskanie adresu IP. Jeśli w sieci nie ma niedoboru adresów IP, okresy dzierżawy powinny być wystarczająco długie, by klienty nie musiały niepotrzebnie przerywać trwających sesji w celu renegocjacji dzierżawy.

Hosty świadczące usługi sieciowe — na przykład serwery plików, poczty i drukowania — powinny posiadać adresy IP przydzielone ręcznie, a nie dzierżawione na ustalony okres. A jeśli jest to z jakichś względów niemożliwe, hosty te powinny otrzymać dzierżawy trwałe, aby mogły świadczyć innym urządzeniom usługi w sposób nieprzerwany.

Opcje zakresu i serwera

Zakres DHCP (DHCP scope) oznacza pełną pulę poprawnych adresów IP, dostępnych dla wszystkich klientów DHCP w fizycznej podsieci. Każdy zakres DHCP posiada następujące właściwości:

• nazwę zakresu,

• pełny zakres adresów IP,

• maskę podsieci,

• okres dzierżawy,

• rezerwacje,

• opcje.

Opcje opisane są w punkcie „Opcje serwera DHCP” w dalszej części tego rozdziału.

Administratorzy sieci używają zakresów, by dzielić fizyczne podsieci na większą liczbę podsieci logicznych. Serwer DHCP świadczy usługi DHCP dla każdej z tych logicznych podsieci oraz identyfikuje i przechowuje dane konfiguracyjne dla wszystkich klientów w danej podsieci. Klient w jednej logicznej podsieci może zażądać danych konfiguracyjnych również od serwerów w innych podsieciach logicznych.

Usługa DHCP w wersji Microsoftu pozwala dodatkowo administratorom sieci grupować kilka zakresów w superzakres (superscope), dzięki czemu można w jednym działaniu przydzielić strategie do wielu zakresów, o ile strategie te dla wszystkich zakresów są identyczne. Superzakresy mogą również służyć do rozwiązywania najczęstszych problemów serwerów DHCP, odciążając administratora sieci.

Od czasu do czasu grupa adresów w obrębie zakresu nie jest oferowana klientom serwera DHCP. Taka grupa nosi nazwę zakresu wykluczenia. Aby wykorzystać adresy IP z za­kresu wykluczenia, administrator musi ręcznie skonfigurować te adresy dla urządzeń sieciowych nie będących w stanie użyć DHCP — na przykład drukarek. Reszta adresów w zakresie (nie wykluczonych) tworzy pulę adresów zakresu. Jedynie adresy z puli adresów zakresu są oferowane klientom. Gdy host w sieci dzierżawi adres na stałe, adres ten jest zarezerwowany dla klienta. Tylko określony host może wydzierżawić adres dla siebie zarezerwowany.

Aby umożliwić klientom korzystanie z usług serwera DHCP, musimy zdefiniować i skonfigurować zakres. Proces tworzenia zakresu DHCP przebiega według następujących kroków:

1. Utwórz zakres za pomocą odpowiedniego programu narzędziowego, zawartego w używanym systemie operacyjnym. Na przykład, w Windows NT 4.0 i nowszych można użyć narzędzia Microsoft DHCP Manager.

Szczegółowa procedura tworzenia zakresów DHCP powinna być opisana w dokumentacji używanego systemu operacyjnego.

11. W razie potrzeby zdefiniuj zakresy wykluczenia, wyłączając z zakresu określone adresy. Adresy z zakresu wykluczenia powinny być używane jedynie dla urządzeń sieciowych niezdolnych do automatycznego uzyskania adresu IP, na przykład dla drukarek i modemów.

12. Utwórz rezerwacje dla urządzeń wymagających trwałej dzierżawy adresu z puli adresów. Do tych urządzeń należą dostępne w sieci serwery różnych typów. Zarezerwowane adresy IP należy również przydzielić do ruterów.

Rezerwacji należy dokonywać jedynie dla urządzeń sieciowych, które mogą dynamicznie uzyskać adres IP dzięki zdolności do korzystania z usługi DHCP.

13. Określ okres dzierżawy. Wartość domyślna wynosi trzy dni i w większości przypadków jest do przyjęcia. Administrator może w miarę potrzeb modyfikować tę wartość.

14. Zdefiniuj niezbędne opcje zgodnie z wymaganiami.

15. Po pomyślnym utworzeniu i skonfigurowaniu, zakres należy aktywować, aby serwery DHCP mogły przetwarzać żądania dzierżaw i przydzielać dynamicznie adresy IP klientom.

Pakiet DHCP

Ponieważ protokoły DHCP i BOOTP są do siebie bardzo podobne, format pakietu DHCP jest również bardzo zbliżony do formatu pakietu BOOTP. Jedno z pól pakietu DHCP jest jednak inaczej traktowane, a kolejne różni się od odpowiednika w BOOTP zawartością. Rysunek 9.3 przedstawia format pakietu DHCP.

Rysunek 9.3. Format pakietu DHCP

Tylko dwa pola w pakiecie DHCP różnią się od pól w pakiecie BOOTP:

• Flagi — jest odpowiednikiem nie używanego pola w pakiecie BOOTP, w którym wszystkie bity pola mają wartość 0. W pakiecie DHCP wszystkie bity flagi mają wartość 0, z wyjątkiem pierwszego z lewej. Wartość tego (najbardziej znaczącego) bitu oznacza komunikat rozgłoszeniowy. Oznacza to, iż klient DHCP może od serwera DHCP zażądać wysłania odpowiedzi za pomocą komunikatu rozgłoszeniowego IP. Pole to ma długość 2 bajtów.

• Opcje — jest odpowiednikiem pola Dane producenta w komunikatach BOOTP. I podobnie jak w pakiecie BOOTP, pole to zawiera dodatkowe dane konfiguracyjne dostarczane przez producenta. Do informacji tych należą: okres dzierżawy, maska podsieci dla lokalnej sieci, adres IP serwera czasu, adres IP serwera domeny oraz rozmiar pliku inicjującego. Pole ma długość 64 bajtów.

Szczegółowy opis pozostałych pól znajduje się w punkcie „Zawartość pakietu BOOTP” we wcześniejszej części rozdziału.

Opcje serwera DHCP

Podczas operacji wydzierżawiania adresów IP klientom DHCP, serwer DHCP może również przydzielać inne parametry konfiguracji wymagane przez klienta, zwane opcjami DHCP lub opcjami serwera DHCP. Należą do nich, na przykład, adres domyślnego rutera lub bramy oraz adres serwera nazw. Podstawowe dostępne opcje konfigurowania klientów DHCP zostały wymienione poniżej:

• Wypełnienie (kod opcji 0) — dopełnia poniższe pola do granic pełnych słów.

• Maska podsieci (kod opcji 1) — przedstawia maskę podsieci dla danej podsieci fizycznej.

• Przesunięcie czasu (kod opcji 2) — oznacza czas UCT (Universal Coordinated Time) w sekundach.

• Ruter (kod opcji 3) — wymienia adresy IP wszystkich ruterów dostępnych w podsieci.

• Serwery czasu (kod opcji 4) — wymienia adresy IP wszystkich serwerów czasu dostępnych dla klienta.

• Serwery nazw (kod opcji 5) — wymienia adresy IP wszystkich serwerów nazw dostępnych dla klienta.

• Serwery DNS (kod opcji 6) — wymienia adresy IP wszystkich serwerów DNS dostępnych dla klienta.

• Serwery dziennika (kod opcji 7) — wymienia adresy IP wszystkich serwerów dziennika dostępnych dla klienta.

• Serwery cookie (kod opcji 8) — wymienia adresy IP wszystkich serwerów cookie dostępnych dla klienta.

• Serwery LPR (kod opcji 9) — wymienia adresy IP wszystkich serwerów drukarek wierszowych (Line PRinter) dostępnych dla klienta.

• Serwery Impress (kod opcji 10) — wymienia adresy IP wszystkich serwerów Imagen Impress dostępnych dla klienta.

• Serwery lokalizacji zasobów (kod opcji 11) — wymienia adresy IP wszystkich serwerów lokalizacji zasobów dostępnych dla klienta.

• Nazwa hosta (kod opcji 12) — przedstawia nazwę klienta, która może mieć długość do 63 bajtów.

• Rozmiar pliku inicjującego (kod opcji 13) — przedstawia rozmiar domyślnego pliku inicjującego klienta.

• Plik zrzutu zawartości (kod opcji 14) — przedstawia ścieżkę do pliku, do którego powinien zostać zrzucony obraz pamięci klienta w przypadku jego załamania. Ten plik jest używany w sytuacjach, gdy domyślny plik inicjujący klienta staje się niedostępny z uwagi na awarię serwera.

• Nazwa domeny (kod opcji 15) — przedstawia nazwę domeny DNS, która powinna być użyta przez klienta do rozwiązania nazwy DNS hosta.

• Serwer wymiany (kod opcji 16) — przedstawia adres IP serwera wymiany dostępnego dla klienta.

• Główna ścieżka dostępu (kod opcji 17) — przedstawia ścieżkę do dysku systemowego klienta.

• Ścieżka do rozszerzeń (kod opcji 18) — oznacza plik zawierający informacje, podobnie jak pole danych producenta w komunikacie odpowiedzi BOOTP. Plik można pobrać za pomocą TFTP.

Trasowanie DHCP

Ruter obsługujący protokół BOOTP potrafi zazwyczaj przesyłać również żądania i odpowiedzi DHCP pomiędzy podsieciami. W tym celu ruter musi obsługiwać usługę przekazywania DHCP i BOOTP. Dowolne urządzenie lub program, które potrafi przesyłać dane konfiguracyjne z jednej podsieci do drugiej, nazywane jest agentem przekazującym (relay agent) — wobec tego ruter obsługujący protokół BOOTP można nazwać agentem przekazującym DHCP/BOOTP. Proces przesyłania żądań wygląda następująco:

1. Klient DHCP wysyła żądanie parametrów konfiguracyjnych przez port 68 TCP.

16. Agent przekazujący przechwytuje żądanie i rozpoznaje podsieć, do której żądanie trzeba przesłać.

17. W docelowej podsieci jeden lub kilka serwerów DHCP może „usłyszeć” rozgłoszenie i odpowiedzieć klientowi, podając dostępny adres IP.

18. Agent przekazujący DHCP/BOOTP przesyła odpowiedzi do klienta, który wybiera jedną z nich, wysyła komunikat żądania do odpowiedniego serwera i otrzymuje dzierżawę, która ponownie zostaje przekazana przez agenta przekazującego.

194 Część II Praca z TCP/IP

Rozdział 9. Konfiguracja automatyczna 181

---