Główne różnica pomiędzy protokołem BOOTP a DHCP są następujące:

• • • W BOOTP wykorzystywano wstępnie zdefiniowaną bazę możliwych do przypisania adresów IP (przechowywana w statycznym pliku tekstowym). W bazie tej znajdowało się powiązanie MAC klienta i adresu IP. Zgłaszającemu się klientowi , który musiał być wprowadzony do bazy został przypisywany zdefiniowany przez administratora adres IP. Brak wprowadzonego powiązania (brak wpisu o adresie MAC klienta), skutkowało niemożnością przypisania adresu IP. Protokół DHCP natomiast wykorzystuje mechanizm dynamicznej alokacji adresów (opis poniżej).
    • DHCP wykorzystuje mechanizm dzierżawy (wynajęcia) możliwych do przypisania adresów IP w protokole BOOTP brak jest dzierżawy a zarezerwowane adresy IP mogą być przypisane tylko odgórnie zdefiniowanym hostom.
    • BOOTP nie potrafi przekazać wszystkich informacji (przekazuje informację tylko o adresie IP, adresie bramy, masce podsieci i adresie serwera DNS), natomiast protokół DHCP obsługuje ponad 20 różnych parametrów konfiguracyjnych.
    • Protokół DHCP do prowadzenia komunikacji używa protokołu UDP, który do działania wykorzystuje port 67 oraz 68. Sam zaś protokół został zdefiniowany w dokumencie RFC 2131, a opcje konfiguracyjne protokołu zostały zawarte w dokumencie RFC 2132.
    • Protokół DHCP jest protokołem warstwy aplikacji, który oprócz automatycznego przypisywania adresów IP, masek sieciowych, bram czy serwerów DNS oferuje również konfigurację nazw domenowych, strefy czasowe, serwery NTP itp.

W sieci w której zaimplementowano protokół DHCP można wyróżnić trzy odrębne podmioty. Najczęściej w tradycyjnej sieci czy to domowej czy działającej w małej firmie można wyróżnić klientów (te hosty, które adresu potrzebują) i serwer (odpowiedzialny za przydział adresów). Natomiast jeśli te dwa wymienione elementy (klient i serwer) nie działają w tej samej warstwie łącza danych (obręb działania domeny rozgłoszeniowej bądź prościej pakiet DHCP będzie musiał przejść przez router), niezbędny będzie pośrednik (proxy), którego zadaniem będzie przekazanie rozgłoszeń DHCP dalej (pośrednikiem zwykle jest router). Tak więc pośrednik podczas podłączania się klienta, który nie zna swojego adresu IP pełni rolę przekaźnika, przekazującego rozgłoszenie (brodcast) warstwy drugiej, celem odnalezienia serwera, który udzieli mu niezbędnych informacji a także przekazuje z powrotem informację od serwera do klienta.

Myślę, że ostatecznie poniższy rysunek rozwiąże kwestię pełnionych funkcji w sieci w której działa protokół DHCP. W sieci 10.0.0.0/24 pośrednika nie ma ponieważ host WindowsXP_3 ma bezpośredni kontakt z serwerem DHCP (oba komputery znajdują się w tej samej sieci), natomiast w przypadku hosta WindowsXP_1 oraz hosta WindowsXP_2 aby komunikacja z serwerem DHCP była możliwa routery kolejno R1 oraz R2 muszą przekazać pakiety DHCP do serwera, tak więc oba routery są pośrednikami w tym procesie.

Oczywiście najważniejszą funkcją serwera DHCP jest przypisanie adresów IP zgłaszającym się hostom. Serwer DHCP aby sprawnie wykonać swoje zadanie może zastosować jeden z trzech mechanizmów alokacji adresów.

• • • Alokacja ręczna - to administrator przypisuje adresy IP, które mają trafić do określonego klienta, a zadaniem serwera DHCP jest dostarczenie tych adresów,
    • Alokacja automatyczna - serwer DHCP z wstępnie zdefiniowanej puli adresów, klientom automatycznie przypisuje na stałe statyczny adres IP. W mechanizmie tym brak jest dzierżawy adresu.
    • Alokacja dynamiczna - w przeciwieństwie do alokacji automatycznej, serwer zgłaszającym się klientom na pewien ustalony przez administratora czas wydzierżawia adres IP. Adresy są przypisywane z zdefiniowanej puli adresów. Adres IP, któremu czas dzierżawy minął wraca do puli dostępnych (ponownie do wykorzystania) adresów bądź gdy klient zgłasza taką potrzebę okres dzierżawy zostaje wydłużony.

W pakiecie DHCP można wyróżnić następujące pola:

Kod operacji (OP) - rodzaj pakietu: żądanie DHCP (wartość 1) bądź odpowiedź DHCP (wartość 2),

Typ warstwy fizycznej - rodzaj wykorzystanej warstwy sprzętowej (Ethernet, IEEE 802.11, ATM ) np. 1 to Ethernet, 15 to Frame Relay a 20 to linia szeregowa,

Długość adresu sprzętowego - pole zawiera długość adresu sprzętowego (8-bitowa),

Liczba skoków - wartość wykorzystywana przez pośredników w celu odnalezienia serwera DHCP, przed wysłaniem wartość pola jest ustawiana na 0,

Identyfikator transakcji - wygenerowana wartość losowa służąca do powiązania żądania z odpowiedzią (wartość 32-bitowa),

Liczba sekund - liczba sekund jaka upłynęła, od wysunięcia pierwszego żądania bądź od prośby o odnowę dzierżawy,

Flagi - określają rodzaj ruchu sieciowego wykorzystywanego przez klienta DHCP (unicast, broadcast) np. wartość flagi ustawiona na 1 oznacza ruch rozgłoszeniowy,

Adres IP klienta - adres IP klienta, w przypadku wysunięcia żądania o adres IP pole ustawiane jest na 0 natomiast w przypadku odnowy dzierżawy umieszczany jest aktualnie wykorzystywany adres IP,

Twój adres IP - adres IP jaki oferuje nam serwer,

Adres IP serwera - pole zawiera adres IP serwera DHCP,

Adres IP bramy - pole zawiera adres IP bramy domyślnej, informacja ta m.in. jest wykorzystywana gdy w procesie przydzielania adresu IP uczestniczą pośrednicy tak aby możliwa była komunikacja pomiędzy różnymi podsieciami,

Sprzętowy adres klienta - adres MAC klienta,

Nazwa serwera - nazwa serwera (opcjonalna), w polu tym podczas wymiany pakietów (DHCPOFFER lub DHCPACK) serwer może umieścić domenową nazwę serwera DNS,

Nazwa pliku startowego - nazwa pliku startowego używanego przez DHCP (wartość opcjonalna, gdy klient zgłasza takie żądanie w komunikacie DHCPDISCOVER),

Opcje – pola dodatkowe powodujące rozszerzenie struktury pakietu DHCP o nowe funkcje.

Ogólnie proces wymiany pakietów DHCP odbywa się według schematu zaprezentowanego poniżej:

Najczęściej proces przypisania adresu IP odbywa się pomiędzy klientem a serwerem. Proces ten również określany jest również jako DORA tj. odkrycie (ang. Discover), oferta (ang. Offer), żądanie (ang. Request) i potwierdzenie (ang. Acknowledgment). Jak widać opiera się on na czterech pakietach.

Aby lepiej zrozumieć przebieg wymiany pakietów pomiędzy klientem a serwerem DHCP omówienie procesu przypisania adresu IP przeprowadzimy na przechwyconych pakietach.

Topologia sieciowa na której będziemy bazować została przedstawiona poniżej. Omówienie procesu DORA rozpoczniemy od komunikacji pomiędzy hostem WindowsXP_3 a serwerem DHCP (bez pośrednika) a następnie przyjrzymy się wymianie pakietów pomiędzy hostem WindowsXP_1 a serwerem DHCP (wersja z pośrednikiem).

Aby móc zacząć omawiać zdarzenia jakie zachodzą przy procesie przypisywania adresu IP najpierw trzeba w sieci posiadać odpowiednio skonfigurowany serwer DHCP. W naszym scenariuszu funkcję tą będzie pełnić system Windows 2012 Server z zainstalowaną rolą serwera DHCP. By serwer mógł zacząć przydzielać adresy należy w pierwszej kolejności stworzyć pulę adresów, które przez ten serwer będą dystrybuowane i taka pula została stworzona. Serwer ma możliwość przypisania adresów IP od 10.0.0.100 do 10.0.0.200 z maską 255.255.255.0 Oprócz adresu IP serwer dostarcza hostom informację o adresie bramy - 10.0.0.2 oraz adresie serwera DNS - 10.0.0.2

Po skonfigurowaniu puli adresów serwer jest gotowy aby pełnić swą rolę, serwer DHCP jeszcze nie przyznał żadnemu z hostów adresu IP.

Po podłączeniu klienta i wzajemnej wymianie pakietów hostowi zostaje przypisany adres 10.0.0.100

Po sprawdzeniu konfiguracji sieciowej hosta, utwierdzamy się w przekonaniu, że cała zdefiniowana na serwerze DHCP konfiguracja została poprawnie dostarczona zgłaszającemu się hostowi.

Jak widać serwer DHCP działa prawidłowo, nastąpiła wymiana pakietów czego konsekwencją jest przypisanie parametrów sieciowych hostowi. Ale żeby proces ten zrozumieć i aby poznać jego przebieg trzeba zajrzeć nieco w głąb a mówiąc dokładniej trzeba przyjrzeć się jakie informacje zawierają poszczególne pakiety. A więc przyjrzyjmy się pakietom.

Wymiana DHCP zaczyna się od klienta. Gdy host w sposób statyczny nie ma przypisanego adresu IP aby uzyskać połączenie z siecią rozpoczyna proces odszukiwania serwera DHCP celem konfiguracji parametrów sieciowych. Host nie posiada żadnych ustawień (bo skąd by je miał znać), nie zna nawet adresu serwera, które by mu te dane przypisał jedyne co można zrobić w tej sytuacji to wysłać pakiet rozgłoszeniowy UDP. Proces wysłania pakietu broadcast ma na celu odszukanie serwera DHCP.

Wykrywanie serwera DHCP - pakiet DHCPDlSCOVER

Kiedy host, który nie ma przypisanych parametrów sieci próbuje się podłączyć do sieci (klient w opcjach musi mieć skonfigurowane, że korzysta z serwera DHCP) w pierwszym kroku musi odnaleźć serwer DHCP, który mu przydzieli prawidłowe adresy IP. W tym celu zostaje wysłany pakiet rozgłoszeniowy DHCPDlSCOVER (pkt 6). Ponieważ w trakcie próby przyłączenia się do sieci host nie posiada żadnej konfiguracji sieciowej, pole warstwy 2 łącza danych zostaje ustawione na broadcast (pkt 1 - ff:ff:ff:ff:ff:ff ), to samo dzieje się z polem warstwy 3 (warstwa sieciowa, pkt 4 - 255.255.255.255). Dodatkowo w polu warstwy 2 zostaje umieszczony adres MAC klienta (pkt 2 – 08:00:27:d2:ab:01) a w polu warstwy 3 adres IP źródłowy zostaje ustawiony na 0.0.0.0 (pkt 3). Jako protokołu transportu DHCP używa UDP (User Datagram Protocol). Zgłaszający się klient wysyła komunikat do serwera na port 67 (pkt 5). Został również wygenerowany identyfikator transakcji, który pozwoli nam na powiązanie kolejnych pakietów (pkt 7 – 0xea045b81, jak się przekonasz czytelniku wartość ta pojawi się we wszystkich następnych pakietach DHCP).

Oferta DHCP – pakiet DHCPOFFER

Gdy nasłuchujący serwer odbierze żądanie DHCP, przeszukuje swoją bazę tak by klientowi móc wydzierżawić dostępny adres IP. Po odnalezieniu wolnego adresu IP, następuje wysłanie do klienta oferty – pakiet DHCPOFFER (pkt 6). W pakiecie tym zawarta jest informacja o początkowej konfiguracji klienta, tj. proponowany adres IP (pkt 8 - 10.0.0.100), maska podsieci (pkt 10 - 255.255.255.0), brama domyślna (pkt 12 10.0.0.2), czas trwania dzierżawy (pkt 13 - 8 dni) oraz adres IP serwera składającego ofertę (pkt 14). Oprócz tych wszystkich danych w pakiecie tym również jest miejsce aby np. przekazać informację o czasie odnowy dzierżawy (pkt 11 - 4 dni), czasie ponownego wiązania (pkt 12 - 7 dni), serwerze DNS czy usłudze nazw NetBIOS. W pakiecie jako źródłowy adres MAC zostaje umieszczony adres MAC serwera (pkt 2 - 08:00:27:16:02:b6), natomiast adresem docelowym jest adres rozgłoszeniowy (pkt 1 - ff:ff:ff:ff:ff:ff ). Zostaje również umieszczona informacja o adresie MAC klienta (pkt 9 - 08:00:27:d2:ab:01). W warstwie sieciowej jako adres źródłowy zostaje umieszczony adres serwera (pkt 3 - 10.0.0.2), natomiast adresem docelowym jest adres broadcast (pkt 4 - 255.255.255.255). Serwer wysyła do klienta pakiet UDP na port 68 (pkt 5). Pakiet zawiera ten sam identyfikator transakcji, który znajdował się w pakiecie DHCPDlSCOVER (pkt 7 - 0xea045b81). Dzięki temu mamy pewność, że pakiet ten jest faktycznie odpowiedzią na wcześniejszy pakiet żądania adresu IP)

Żądanie DHCP - pakiet DHCPREQUEST

Kiedy klient odbierze od serwera komunikat DHCPOFFER, odsyła mu komunikat DHCPREQUEST. Nadal w komunikacji pomiędzy serwerem a klientem są używane komunikaty rozgłoszeniowe (warstwa 2 - pkt 1 , warstwa 3 - pkt 2), ponieważ proces przypisania adresu IP jeszcze się nie zakończył a dodatkowo użycie broadcastu gwarantuje nam że inne serwery DHCP (jeśli oczywiście takowe istnieją) dowiedzą się o przyjęciu oferty (pkt 4 - adres 10.0.0.100) przez klienta od danego serwera DHCP. Pakiet ten rozpoczyna dzierżawę adresu lecz również w przypadku przedłużenia dzierżawy wcześniej przypisanego adresu zapoczątkowuje jego odnowę. Użyty identyfikator transakcji (pkt 3 - 0xea045b81) powiązuje pakiet DHCPREQUEST z poprzednimi pakietami.

Potwierdzenie DHCP - pakiet DHCPACK

Po odbiorze pakietu DHCPREQUEST serwer ustanawia dzierżawę wcześniej zaoferowanego adresu IP i jednocześnie tworzy nowy wpis ARP powiązujący adres IP z adresem MAC klienta. Zostaje wysłany (rozgłoszenie w warstwie 2 i 3 - pkt 1 oraz pkt 2), pakiet DHCPACK (pkt 4) który tak naprawdę jest duplikatem komunikatu DHCPOFFER. Po odebraniu przez klienta komunikatu DHCPACK, klient może zacząć używać przydzielonych mu przez serwer parametrów sieci aby skomunikować się z pozostałymi hostami. Użyty identyfikator transakcji (pkt 4 - 0xea045b81) powiązuje pakiet DHCPACK z poprzednimi pakietami, kończąc tym samym proces przypisania parametrów sieci.

Zanim adres zostanie użyty przez hosta, host jeszcze przeprowadza sprawdzenie czy przypadkiem w istniejącej sieci nie nastąpiło zduplikowanie adresu IP. Sprawdzenie te polega na wysłaniu pakietów ARP z zapytanie - „kto używa danego adresu IP?” - w naszym przypadku zapytanie dotyczy adresu 10.0.0.100 Stąd na poniższym rysunku można zaobserwować wysłanie 3 pakietów ARP, które utwierdzają w przekonaniu, że adres jest wolny i można z niego korzystać. Warto tu zauważyć, że proces sprawdzenia poprzez wysłanie pakietów ARP może również wykonać sam serwer DHCP przed wysłaniem pakietu oferty - DHCPOFFER

Poniżej przykład w którym to nastąpiło zdublowanie adresu IP. Na jednym komputerze adres 10.0.0.100 został przypisany statycznie natomiast drugi komputer adres 10.0.0.100 otrzymał od serwera DHCP.

Jak można zaobserwować po poniższym zrzucie przechwyconych pakietów komputer WindowsXP_3 adres 10.0.0.100 (pkt 1) pozyskał od serwera DHCP i następnie celem sprawdzenia dostępności adresu zostały wygenerowane pakiety ARP (pkt 2) mające na celu sprawdzenie czy przypadkiem adres nie jest już wykorzystywany. Pakiety ARP potwierdzają fakt istnienia adresu 10.0.0.100 w sieci (pkt 5). Host decyduje się o ponowienie procesu uzyskania innego adresu IP (pkt 3) i cała komunikacja z serwerem DHCP rozpoczyna się od początku. Komputer uzyskuje kolejny, wolny adres z puli - 10.0.0.101 i następnie dla nowo uzyskanego adresu zostaje wykonane kolejne sprawdzenie ARP (pkt 4). Tym razem test ten, kończy się sukcesem, host zaczyna używać adresu IP 10.0.0.101

Teraz gdy omówiliśmy proces przydzielania adresu IP hostowi, który ma bezpośredni kontakt z serwerem DHCP przejdźmy do bardziej złożonej topologii a mianowicie użyjemy pośrednika, który rozgłoszenia DHCP otrzymane od klienta przekaże pod wskazany adres czyli do serwera DHCP.

Topologia naszej testowej sieci nie zmieniła się i jest pokazana na poniższym rysunku (tak dla przypomnienia). Naszym celem będzie przypisanie adresu IP hostowi WindowsXP_1 oraz hostowi WindowsXP_2. Jak widać poniżej oba hosty znajdują się w odrębnych podsieciach (w innych podsieciach niż serwer DHCP - 10.0.0.0/24), host WindowsXP_1 znajduje się w sieci 192.168.0.0/24, natomiast host WindowsXP_2 w sieci 172.16.0.0/24. Tak więc pośrednikiem dla hosta WindowsXP_1 będzie router R1 natomiast dla hosta WindowsXP_2 router R2. Oba routery zostały skonfigurowane w ten sposób aby zapytania DHCP przekazywać pod adres IP 10.0.0.2 (i oczywiście odpowiedzi).

Oba hosty: WindowsXP_1 oraz WindowsXP_2 jak już zostało zaznaczone leżą w odrębnych, różnych podsieciach tak więc konfiguracji wymaga również sam serwer DHCP. Na serwerze zostały skonfigurowane dwie pule adresów od x.x.x.100 do x.x.x.200 w zależności od obsługiwanej podsieci. Od tej pory serwer może przydzielać adresy IP zgłaszającym się hostom.

Zanim przejdziemy do omawiania wymiany pakietów będzie nam jeszcze potrzebna znajomość adresów MAC interfejsów routera. Wymianę pakietów rozpatrzymy pomiędzy hostem WindowsXP_1 a serwerem DHCP (wymiana pomiędzy WindowsXP_2 a serwerem przebiega analogicznie). Tak więc na zrzucie poniżej zostały przedstawione adresy MAC interfejsów routera R1.

Ruch sieciowy został przechwycony w dwóch miejscach: na hoście WindowsXP_1 oraz na interfejsie f0/0 routera R1. Przyjęto założenie - po lewej znajduje się zrzut przechwyconych pakietów pochodzący z hosta WindowsXP_1, natomiast po prawej z interfejsu f0/0 routera R1.

Host WindowsXP_1 celem zdobycia informacji o adresie IP, zaczyna od odszukania serwera DHCP i w tym celu wysyła rozgłoszenie - pakiet DHCPDISCOVER. W polu warstwy drugiej jako adres docelowy zostaje umieszczony rozgłoszeniowy adres ff:ff:ff:ff:ff:ff (pkt 1) natomiast w polu warstwy trzeciej adres 255.255.255.255 (pkt 4). Źródłowym adresem MAC jest interfejs hosta WindowsXP_1 - pkt 2 natomiast pole adresu źródłowego IP zostaje ustawione na 0.0.0.0 (pkt 3).

Rozgłoszenie te trafia do routera R1 (interfejs f1/0), który te rozgłoszenie przekształca i wysyła pod adres serwera DHCP (10.0.0.2 - pkt 5), jako źródłowy adres IP zostaje ustawiony adres interfejsu f1/0 routera R1 (192.168.0.1 - pkt 6). Źródłowy adres MAC zostaje zastąpiony przez adres MAC interfejsu f0/0 (gdyż przez ten interfejs pakiet opuszcza router R1 - pkt 7). Adresem docelowym MAC jest adres serwera DHCP (pkt 8). W pakiecie opuszczającym router R1 pole Hops zmienia wartość z 0 na 1 (by dostać się do serwera DHCP trzeba przejść przez router - pkt 9) a także zostaje uzupełnione pole Relay agent IP address adresem IP: 192.168.0.1 (adres IP pośrednika - pkt 10). Pakiety te, stanowiące spójną komunikację pomiędzy hostem a serwerem można powiązać ze sobą, polem transakcji (Transaction ID - pkt 11).

Po otrzymaniu pakietu DHCPDISCOVER serwer odsyła pakiet oferty DHCPOFFER (pkt 1). Źródłowym adresem MAC jest adres serwera DHCP (pkt 2) natomiast docelowym adresem jest adres MAC interfejsu f0/0 routera R1 (pkt 3). Adresy IP zostają uzupełnione na podstawie informacji zawartych w pakiecie DHCPDISCOVER czyli jako źródłowy adres zostaje ustawiony adres IP serwera DHCP (pkt 4) natomiast jako docelowy adres - interfejs f1/0 routera R1 (pkt 5). Pakiet zawiera ofertę dla hosta WindowsXP_1 tak więc zostają w nim zawarte informacje o: proponowanym adresie IP (pkt 6), masce sieciowej (pkt 7) oraz adresie bramy (pkt 8). Skąd wiadomo z jakiej puli serwer DHCP ma przydzielić parametry sieciowe? Ano wiadomo stąd, że adresem IP wysyłającym rozgłoszenie jest adres 192.168.0.1 Serwer DHCP analizując pakiet sprawdza czy ma zdefiniowaną pulę odnośnie użytego typu adresacji i jeśli tak zostaje wysłana oferta.

Pakiet DHCPOFFER po dotarciu do interfejsu f0/0 zostaje wysłany do klienta poprzez interfejs f1/0. W tym celu docelowy adres MAC zostaje zastąpiony adresem MAC hosta WindowsXP_1 (pkt 9) oraz źródłowym adresem MAC staje się adres MAC interfejsu f1/0 routera R1 (pkt 10). Numer transakcji pozostaje bez zmian (pkt 11).

Po otrzymaniu pakietu DHCPOFFER host odsyła pakiet DHCPREQUEST. Wymiana pakietu przebiega w ten sam sposób jak w przypadku wysłania pakietu DHCPDISCOVER (te same adresy MAC i IP).

Serwer po otrzymaniu pakietu DHCPREQUEST wysyła pakiet potwierdzenia DHCPACK.

Ostatnim etapem jest sprawdzenie czy oferowany przez serwer DHCP adres 192.168.0.100 nie jest przypadkiem używany w tym celu host WindowsXP_1 rozsyła rozgłoszenie ARP.

Gdy odpowiedź na wysłany pakiet ARP nie jest udzielona, host zaczyna korzystać z przydzielonego mu adresu IP.

Fakt przydzielenia adresu IP zostaje również odnotowany na serwerze DHCP.

W urządzeniach SOHO (small office home office), czyli takich z którymi mamy najczęściej do czynienia ustawienia serwera DHCP sprowadzają się do określenia puli adresów przyznawanych przez serwer. Choć oczywiście wszystko zależy od producenta i modelu urządzenia. Teraz, krótko chciałbym przedstawić na jakie parametry konfiguracyjne możemy się natknąć przy konfiguracji tego typu urządzeń.

Na początek router Archer C7 firmy TP-Link. Zestaw standardowych opcji sprowadza się do następujących ustawień:

1 – włączenie/wyłączenie serwera DHCP,

2 – określenie puli adresów do przydzielenia – adres początkowy i końcowy,

3 – określenie czasu dzierżawy adresu,

4 – adres bramy,

5 – nazwa domeny,

6 – pierwszy DNS oraz drugi DNS.

Router umożliwia również sprawdzenie aktualnej dzierżawy adresów.

Ostatnią opcją związaną z DHCP jest możliwość ustawienia rezerwacji adresów IP na podstawie adresu MAC zgłaszającego się klienta.

W przypadku routera WRT54GL firmy Linksys zestaw opcji nie jest tak bogaty jak w przypadku routera firmy TP-Link (no cóż troszkę starsze urządzenie). Konfiguracja serwera DHCP sprowadza się do ustawienia następujących opcji:

1 – włączenie/wyłączenie serwera DHCP,

2 – określenie startowego adresu IP do przydzielenia,

3 – określenie liczby klientów DHCP,

4 – czas dzierżawy adresu IP,

5 – pierwszy DNS, drugi DNS, trzeci DNS,

6 – serwer WINS.

Router również oferuje opcję sprawdzenia aktualnej dzierżawy adresów IP przez klientów.

Bogatsze opcje konfiguracji serwera DHCP oferuje router (również firmy Linksys) X3000. Tu oprócz standardowych opcji mamy możliwość ustawienia przekazania rozgłoszeń DHCP do innego serwera DHCP (opcja DHCP Relay).

Rezerwacje adresów IP możemy dokonać po wybraniu opcji DHCP Reservation.

W routerach firmy ZyXel (na przykładzie modelu NBG334W) określamy czy serwer DHCP ma być włączony czy wyłączony (pkt 1), definiujemy adres początkowy (pkt 2) oraz ilość klientów (pkt 3).

Sekcja Guest WLAN DHCP Setup odnosi się do klientów sieci bezprzewodowej gościa. Router ma możliwość rozgłaszania zarówno sieci głównej, gdzie klienci mają dostęp do hostów podłączonych tradycyjnym sposobem (nasza sieć LAN) a także tzw. sieci Gościa – sieć bezprzewodowa udostępniana dla hostów postronnych (komputery nie mają możliwość łączności z hostami w sieci LAN). Konfiguracja serwera DHCP przebiega analogicznie jak dla klientów sieci LAN.

W sekcji Advanced mamy możliwość ustawienia:

1 – rezerwacji dzierżawy adresów IP przydzielanych klientom (zarówno sieć LAN jak i sieć Gościa),

2 – ustawienia adresów serwerów DNS.

Na zakładce Client List dokonujemy sprawdzenia dzierżawy adresów IP przydzielonych klientom (zarówno sieć LAN jak i sieć Gościa).

Ustawienia oferowane przez routery firmy D-Link a konkretnie model DIR-615:

1 – włączenie/wyłączenie serwera DHCP,

2 – pula adresów IP,

3 – czas dzierżawy,

4 – uwzględnienie informacji o nazwach NetBIOS (m.in. nazwa hosta) oraz konfiguracja opcji NetBIOS,

5 – rezerwacja adresów IP,

6 – lista klientów.

W przypadku routera Netgear WNR3500 konfiguracja serwera DHCP sprowadza się do określenia następujących opcji:

1 – włączenie/wyłączenie serwera DHCP,

2 – określenie adresu IP początkowego,

3 – określenie adresu IP końcowego,

4 – dokonanie rezerwacji adresu IP.

Jak widać po powyższych zrzutach wszyscy producenci oferują dosyć podobny zestaw opcji konfiguracji wbudowanych w router serwerów DHCP. Konsekwencją możliwych do wykonania ustawień jest przeznaczenie routerów. Router te mają pracować w domu bądź małym biurze więc zbyt rozbudowana konfiguracja w przypadku tego typu urządzeń nie jest pożądana. Raz bo i tak bogatszy zestaw ustawień nie byłby wykorzystany a dwa, w urządzeniach SOHO liczy się prostota i możliwość konfiguracji przez osoby mające podstawową wiedzę (bądź żadną) na temat sieci komputerowych.

Teraz przejdźmy do bardziej zaawansowanych routerów a mianowicie routerów firmy Cisco.

Trochę wyżej opisałem jak przebiega przypisywanie adresu IP gdy w procesie uczestniczy pośrednik, lecz nie opisałem jak skonfigurować router aby rozgłoszenia DHCP przekazał dalej do odpowiedniego serwera DHCP. Tak więc już nadrabiam tą zaległość. Dla przypomnienia jeszcze raz schemat naszej sieci na której to będziemy ćwiczyć konfigurację protokołu DHCP.

W pierwszym kroku aby włączyć przekazywanie pakietów UDP odpowiedzialnych za obsługę mechanizmu DHCP należy przejść do konfiguracji interfejsu, który będzie odpowiedzialny za przesłanie rozgłoszenia dalej. Naszym celem jest aby komputer WindowsXP_1 znajdujący się w sieci 192.168.0.0/24 mógł połączyć się z serwerem DHCP o adresie 10.0.0.2 Tak więc przechodzimy do konfiguracji interfejsu f1/0 gdyż ten interfejs jest połączony z siecią próbującą uzyskać dostęp do serwera (pkt 1). W trybie konfiguracji interfejsu musimy zdefiniować tzw. helper address (adres pomocnika), adres ten jest adresem serwera DHCP (pkt 2).Po skonfigurowaniu adresu pomocnika, router rozgłoszenia DHCP odebrane od hostów znajdujących się w sieci 192.168.0.0/24 przekaże do serwera DHCP. Analogicznie konfigurujemy adres pomocnika na routerze R2 tak aby również hosty podłączone do sieci 172.16.0.0/24 mogły się skontaktować z serwerem DHCP.

Stan skonfigurowanego adresu pomocnika możemy sprawdzić po wydaniu polecenia: show ip interface <interfejs>

Oczywiście odpowiedni wpis o konfiguracji helper adress znajdzie się również w pliku konfiguracji bieżącej routera: show running-config

Z adresem pomocnika po jego konfiguracji, może wystąpić jeden problem a mianowicie nastąpi zwiększenie ruchu sieciowego i tym samym zwiększenie obciążenia łącza pomiędzy routerem R1 a serwerem DHCP. Dzieje się tak, ponieważ po skonfigurowaniu polecenia: ip helper-adress router domyślnie przekaże nie tylko ruch DHCP lecz także rozgłoszenia wszystkich innych protokołów, które jako warstwy transportowej używają protokół UDP m.in. TFTP, TACACS, NETBIOS czy DNS.

Protokoły te zostały zebrane w tabeli:

Tak więc by „wyciąć” niepożądane pakiety należy wyłączyć przekazywanie rozgłoszeń tych protokołów. Oczywiście wyłączamy te protokoły, których w naszej sieci nie wykorzystujemy. Wyłączenia dokonujemy za pomocą polecenia: no ip forward-protocol udp <nazwa_protokołu>

Gdybyśmy z jakiś powodów chcieli skonfigurować dynamiczne przyznawanie interfejsowi routera adresu IP, co prawdę mówiąc w przypadku routerów działających w sieci wewnętrznej nie jest zalecaną praktyką, gdyż prędzej czy później na pewno przysporzy nam to kłopotów, należy skorzystać z polecenia: ip address dhcp Konfiguracja DHCP interfejsu routera jest przydatna w przypadku w którym to router jest podłączony do naszego dostawcy Internetu (ISP), a dostawca ten opcje konfiguracyjne dostarcza właśnie poprzez DHCP.

Tak więc naszym pierwszym krokiem jest przejście do trybu konfiguracji routera (pkt 1) a następnie do trybu konfiguracji interfejsu, który to ma swój adres IP pobrać z serwera DHCP. W przykładzie będzie to interfejs f0/0 routera R2 (pkt 2). Interfejs f0/0 routera R2 miał wcześniej przypisany adres IP statyczny, tak więc należy go usunąć (pkt 3). Po usunięciu adresu IP wydajemy polecenie: ip address dhcp (w przykładzie został jeszcze dodany człon client-id, dodanie tego parametru, spowoduje, że w procesie debugowania łatwiej będzie nam odnaleźć logi dotyczące tego interfejsu, po poleceniu podajemy nazwę interfejsu, gdy chcemy wprowadzić własny ciąg należy dodatkowo do polecenia dołożyć flagę ascii – np. ip address dhcp client-id ascii <własny_tekst>) – pkt 4. Po wprowadzeniu ustawień w komunikacie CLI jesteśmy poinformowani o przypisaniu przez serwer DHCP interfejsowi f0/0 adresu IP 10.0.0.100 (pkt 5).

Weryfikację przypisania adresu IP możemy dokonać również na serwerze DHCP. Jak widać poniżej adres 10.0.0.100 został przypisany hostowi R2.

Powracając do routera, stan przypisania adresu możemy dokonać po wydaniu polecenia: show ip interface brief Jak widać na zrzucie poniżej, po wydaniu polecenia, interfejsowi f0/0 za pomocą mechanizmu DHCP został przypisany adres 10.0.0.100 Interfejs jest w stanie up.

Kolejnym poleceniem służącym do sprawdzenia poprawności działania DHCP jest polecenie: show ip interface <nazwa_interfejsu> Informacje uzyskane dzięki temu poleceniu, powinny pokrywać się z danymi z polecenia: show ip interface brief 

Po uzyskaniu adresu z serwera DHCP, router w swojej tablicy routingu umieszcza trasę statyczną, której odległość administracyjna wynosi 254. Przypisanie takiej wartości dystansowi administracyjnemu powoduje, że trasa ta jest ostatnią możliwą do wykorzystania trasą a pierwszeństwo mają wszystkie inne trasy statyczne czy też trasy pozyskane od protokołów routingu dynamicznego (np. RIP, EIGRP czy OSPF).

Zwolnienie przypisanego adresu IP następuje po wydaniu komendy: release dhcp <nazwa_interfejsu> (pkt 1), stan ten możemy zweryfikować za pomocą polecenia: show ip interface brief (pkt 2). W polu adresu IP widnieje komunikat unassigned – nieprzypisane (pkt 3). Wydanie komendy: show ip interface <nazwa_interfejsu> kończy się komunikatem, że protokół IP na tym interfejsie został wyłączony (pkt 4). Aby ponownie przypisać adres IP do interfejsu (ponowienie dzierżawy) należy użyć polecenia: renew dhcp <nazwa_interfejsu> (pkt 5). Sprawdzenie stanu interfejsu (pkt 6) uwidacznia przypisanie do interfejsu f0/0 adresu 10.0.0.100.

Najwięcej informacji o etapach uzyskania dzierżawy adresu IP uwidoczni nam włączony proces debugowania. Proces ten włączymy za pomocą polecenia: debug dhcp detail Uruchomienie debugowania pomoże nam w rozwiązaniu mogących pojawić się problemów np. z przyznaniem adresu IP (by wymusić informacje interfejs routera został wyłączony i ponownie włączony).

Gdy już wiemy jak skonfigurować interfejs routera aby swój adres IP uzyskał za pośrednictwem zewnętrznego serwera DHCP, przyszła pora aby wytłumaczyć w jaki sposób skonfigurować router by to on stał się serwerem DHCP.

Możliwość włączenia serwera DHCP w urządzeniach Cisco została wprowadzona wraz z pojawieniem się wersji 12.0(1)T systemu IOS. Wykorzystanie routera jako serwera DHCP spowodowało, że zyskaliśmy możliwość wprowadzenia redundancji (nadmiarowości) czyli router Cisco i uruchomiona na nim usługa DHCP może przejąć rolę (w przypadku awarii centralnego serwera DHCP) dostarczania użytkownikom końcowy parametrów sieci.

Jak już jesteśmy przy temacie redundancji to przy wdrażaniu serwerów DHCP trzeba by było zastanowić się nad strategią i wybrać odpowiednią taktykę rozdziału adresów IP. Niestety mechanizm DHCP nie posiada możliwości współpracy z innymi serwerami DHCP tak by od nich się dowiadywać jakie pule adresów zostały zdefiniowane, jakie są wykluczenia oraz jakie adresy IP są aktualnie w użyciu.

Najczęściej spotykanymi rozwiązaniami są metody:

Metoda 50/50

W rozwiązaniu tym są użyte dwa serwery DHCP a każdy z nich może obsłużyć taką samą liczbę klientów. Na każdym z serwerów jest zdefiniowana ta sama pula lecz poprzez wykluczenia każdy z serwerów przyznaje inne adresy IP, tak aby wyeliminować mogące pojawić się konflikty adresowania.

Metoda 80/20

Metoda ta jest podobna do tej opisanej powyżej z tą różnicą, że na serwerach zdefiniowany jest inny procent możliwych do przypisania adresów IP. Jak łatwo się domyślić pierwszy z serwerów dysponuje 80% udziałem adresów IP natomiast drugi z serwerów tylko 20% udziałem adresów IP. Tak więc pytanie - Który z serwerów ma mieć zdefiniowaną większą pulę a który mniejszą? Odpowiedź jest prosta – większą pulę przyznajemy serwerowi DHCP leżącemu najbliżej klientów (rozgłoszenia DHCP do takiego serwera docierają w pierwszej kolejności i to najczęściej on przydziela największą liczbę adresów IP). Resztą puli dysponuje zapasowy serwer, który może znajdować się w odległej podsieci tak aby klienci nie stracili możliwości uzyskania adresu IP.

Metoda 100/100

W rozwiązaniu tym, każdy z serwerów ma możliwość obsłużenia wszystkich klientów (100 procent), adresacja tak została dobrana aby umożliwić obsługę wszystkich klientów. Poprzednie metody takiej gwarancji nam nie dawały, gdyż awaria któregoś z serwerów zmniejszała pulę dostępnych do przypisania adresów IP.

Gdy już zdecydujemy się na odpowiednią strategię (oczywiście nic nie stoi na przeszkodzie by pule adresów IP zdefiniować według własnych upodobań i wymagań) możemy przejść do konfiguracji serwera DHCP na routerze Cisco. Procedura przebiega według poleceń opisanych poniżej (w pierwszej kolejności opis z wykorzystaniem podstawowych opcji konfiguracyjnych a za chwilę troszkę bardziej rozbudowany).

Naszym zadaniem będzie uruchomienie serwera DHCP na routerze R1 tak aby w przypadku niedostępności serwera 10.0.0.2 proces przyznawania adresów IP był nadal możliwy, tak by hosty mogły się ze sobą komunikować.

W pierwszej kolejności należy włączyć usługę serwera DHCP. Usługę włączamy za pomocą polecenia: service dhcp (pkt 1). W kolejnym kroku należy określić nazwę puli - polecenie: ip dhcp pool <nazwa> (pkt 2). W pkt 3 za pomocą polecenia: network <zakres_adresów> określamy pulę adresów IP do przypisania. Polecenie: default-router <adres_IP> posłuży nam do określenia adresu IP routera domyślnego (pkt 4 - adres bramy domyślnej). W końcu ostatnia komenda: dhcp excluded-address <adres_IP_początkowy> <adres_IP_końcowy> pozwala nam na wykluczenie z wcześniej zdefiniowanej puli adresów (adresy od 192.168.0.1 do 192.168.0.254), adresów, które nie będą przydzielane.

Mógłbyś zapytać czytelniku - Czemu zdefiniowałem taką pule adresów IP do wykluczenia? Odpowiedź jest prosta ponieważ zakres od 192.168.0.1 do 192.168.0.99 zarezerwowałem sobie do własnej dyspozycji np. adresacja statyczna natomiast zakres od 192.168.0.100 do 192.168.0.200 jest pulą adresów, które przyznaje serwer DHCP, kontrolowany przez Windows Server 2012 (zakresy nie mogą się pokrywać, inaczej dojdzie do konfliktu). Router R1 będzie przyznawał adresy IP z zakresu od 192.168.0.201 do 192.168.0.254

Tak więc po konfiguracji routera R1 przyszła pora by przetestować jego działanie. Serwer DHCP 10.0.0.2 został odłączony tak więc jego rolę powinien przejąć router R1.Jak widać po poniższym zrzucie tak się właśnie stało. Host WindowsXP_1 uzyskał adres IP 192.168.0.201, który to adres zawiera się w puli adresów routera R1.

Uważny czytelnik zauważy, że adres 192.168.0.201, hostowi WindowsXP_1 został wydzierżawiony na 24 godziny. Jest to domyślne ustawienie serwera DHCP. Ustawienie to oczywiście można zmienić, polecenie, które pozwoli nam ustawić czas dzierżawy na zdefiniowany przez nas okres czasu ma składnię: lease <dni> <godziny> <minuty> (parametry godziny i minuty są opcjonalne). Maksymalny okres dzierżawy wynosi: 365 dni, 23 godziny i 59 minuty natomiast minimalny to 1 minuta. Czas dzierżawy ustalmy po przejściu do trybu konfiguracji puli adresów (w naszym przypadku pula nosi nazwę 192.168.0.0/24). Czas dzierżawy został ustalony na 3 dni i 12 godzin.

Po odnowieniu dzierżawy przez klienta, można zaobserwować efekt wprowadzonych ustawień.

W poleceniu lease możliwe jest również użycie parametru infinite, użycie flagi spowoduje przydzielenie adresu IP z nieskończonym okresem dzierżawy.

Fakt ten można sprawdzić na hoście wydając polecenie: ipconfig /all bądź sprawdzając Szczegóły połączenia sieciowego.

Po przydzieleniu hostowi adresu IP, router przydzielony adres IP wiąże z adresem MAC klienta, któremu dany adres został wydzierżawiony. Aby ukazać to powiązanie wydaj polecenie: show ip dhcp binding Po wydaniu polecenia uzyskamy również informację o czasie wygaśnięcia dzierżawy.

W przypadku wcześniejszego zastosowania polecenia: lease infinite komenda show ip dhcp binding ukaże czas dzierżawy ustawiony na nieskończoność.

Wydanie polecenia: show ip dhcp pool dostarczy nam informacji o zdefiniowanych pulach adresów IP, którymi zarządza serwer DHCP.

Natomiast użycie flagi statistics w poleceniu: show ip dhcp statistics pozwala na zapoznanie się z ogólną statystyką serwera DHCP.

Z informacją o zaistniałych konfliktach w przypisaniu adresu IP (np. złe zdefiniowanie pul adresów IP w których to pule mają część wspólną – przydzielają te same adresy IP) możemy się zapoznać za pomocą polecenia: show ip dhcp conflict

W rozwiązaniu ewentualnych problemów z działaniem serwera DHCP pomogą nam polecenia debugowania i tak wydanie komendy: debug ip dhcp server packet pozwoli nam na monitorowanie stanu wysyłanych i otrzymywanych pakietów DHCP. Np. w poniższym zrzucie w pkt 1 serwer otrzymał informację o zwolnieniu adresu 192.168.0.201 przez klienta natomiast w pkt 2 ten sam klient wysuwa żądanie o przypisanie mu adresu IP.

Wydanie polecenia: debug ip dhcp server events powala nam na monitorowanie zdarzeń jakie zachodzą podczas działania serwera DHCP takich jak: zwolnienie adresu IP (pkt 1), odebraniu pakietu DISCOVER (pkt 2), faktu przypisania adresu IP czy sprawdzeniu terminów dzierżaw a także unieważnieniu wygasłych dzierżaw.

Zdefiniowaliśmy zapasowy serwer DHCP dla sieci 192.168.0.0/24 teraz spróbujmy zrobić to samo ale dla sieci 172.16.0.0/24 lecz z trochę większym zestawem opcji.

Tak więc:

1 – uruchamiamy usługę DHCP na routerze R2,

2 – określamy nazwę puli – 172.16.0.0/24,

3 – określamy zakres adresów do przydzielenia – od 172.16.0.1 do 172.16.0.254,

4 – adres routera domyślnego – 172.16.0.1,

5 – nazwa domeny – firma.local,

6 – adresy serwerów DNS – 10.0.0.2 oraz 8.8.8.8,

7 – adres serwera NetBIOS (WINS) – 10.0.0.2,

8 – ustawia sposób rozwiązywania nazw NetBIOS na H-node,

9 – adres serwera TFTP – 10.0.0.2,

10 – informacja o trasie statycznej – host 192.168.2.1 osiągalny poprzez adres 172.16.0.2,

11 – czas dzierżawy – 4 dni,

12 – wykluczenie adresów, które nie będą przydzielane – od 172.16.0.1 do 172.16.0.200.

Jak widać powyżej protokół DHCP celem konfiguracji stacji roboczej potrafi przesłać bardzo dużo informacji tak by host mógł prowadzić skuteczną komunikację z innymi urządzeniami. Tak naprawdę przedstawiona powyżej przykładowa konfiguracja nie wyczerpuje wszystkich możliwości. Możliwych parametrów do przekazania jest znacznie więcej. Jak można zauważyć powyżej są dwa sposoby definiowania parametru, który zostanie wysłany do hosta:

Metoda pierwsza: korzystamy z tzw. „przyjaznych nazw”, których użycie jednoznacznie definiuje jaki parametr jest konfigurowany np. dns-server czy domain-name,

Metoda druga: skorzystanie z polecenia: option <numer_opcji>. I tu rodzi się pytanie – Jaki numer odpowiada jakiemu parametrowi? Myślę, że poniższa tabela odpowie na to pytanie (źródło: http://www.cisco.com/c/en/us/td/docs/net_mgmt/network_registrar/6-1-1/user/guide/users/UserApB.html).

Przy wprowadzaniu parametrów serwera DHCP należy mieć na uwadze, że niektóre opcje akceptują wiele wpisów. Wpisy ustalamy według preferencji (pierwszy wpis najważniejszy, drugi trochę mniej itd.) Takimi parametrami są np. dns-server czy default-router (max 8 wpisów).

Po konfiguracji serwera DHCP wypadałoby sprawdzić, czy wszystkie zdefiniowane przez nas parametry poprawnie są dostarczane do klienta. Jak widać poniżej po podłączeniu hosta WindowsXP_2, host został skonfigurowany według naszych założeń.

W konfiguracji serwera DHCP zawarłem informację o przekazaniu trasy statycznej. Jak można zaobserwować na rysunku poniżej host nie uzyskał jeszcze informacji z serwera DHCP. Skąd to wiadomo? Ano stąd, że adresy zawarte w tablicy routingu mieszczą się w zakresie 169.254.0.1 – 169.254.255.254 a zakres ten przydzielony jest mechanizmowi APIPA (adres IP przydzielany jest przez system gdy serwer DHCP jest nieosiągalny).

Po uzyskaniu łączności z serwerem DHCP i popraniu parametrów konfiguracyjnych można zaobserwować, że zdefiniowany przez nas wpis na serwerze DHCP znajduje swoje odzwierciedlenie w tablicy routingu hosta.

Tak jak w przypadku routerów SOHO i tu istnieje możliwość zdefiniowania adresu IP, który otrzymuje klient za każdym razem gdy o niego poprosi (zawsze ten sam adres IP). Procedura przypisania klientowi stałego adresu IP przebiega następująco:

1 - definiujemy nazwę puli - statyczne,

2 - określamy adres IP, który ma być przydzielony na stałe - 172.16.0.210/24,

3 - za pomocą polecenia: client-identifier <adres_MAC> określamy MAC klienta, któremu wyżej wybrany adres IP będzie przypisany - 0180.0027.f47f.d2,

4 - definiujemy adres routera domyślnego - 172.16.0.1,

5 - definiujemy adres IP serwera DNS - 8.8.8.8

Oczywiście część opcji możemy pominąć (np. pkt 4 czy pkt 5) lecz także tą konfigurację możemy poszerzyć o opcję, które uważamy, że są niezbędne.

Po wprowadzeniu ustawień przyszedł czas by je przetestować w działaniu. Podłączamy klienta o zdefiniowanym przez nas adresie MAC i sprawdzamy jego konfigurację sieciową. Jak można zauważyć poniżej zdefiniowane przez nas parametry zostały dostarczone klientowi.

Dodatkowo sprawdzenia można również wykonać na serwerze DHCP (router R2), przy kliencie, który ma „statycznie” ustawiony adres IP, polecenie: show ip dhcp binding w sekcji Lease expiration ukaże wpis infinite.

Informację o stanie serwera DHCP (informacja o przydzielonych adresach IP) można dodatkowo przesłać na serwer zdalny. Poniżej konfiguracja bazy danych DHCP – router za pomocą protokołu FTP informacje o dzierżawach adresów IP zapisze na serwerze 10.0.0.2 w pliku dzierzawa_r2 Przy konfiguracji zostały użyte poświadczenia użytkownika – login: jankow, hasło:T@jnehaslo1

Oprócz protokołu FTP możliwe jest zapisanie stanu bazy serwera za pomocą protokołu TFTP oraz RCP

Status wykonanej operacji zapisu bazy danych sprawdzimy za pomocą polecenia: show ip dhcp database Jak można zauważyć, baza została zapisana 1 raz i operacja zakończyła się sukcesem.

I na tym chciałbym zakończyć. Mam nadzieję, że po przeczytaniu tego wpisu nie będzie problemu by samodzielnie skonfigurować protokół DHCP w swojej sieci (nieważne czy czytelniku korzystasz z routerów SOHO czy Cisco). Niewątpliwie użycie mechanizmu DHCP pozwala na zaoszczędzenie czasu i przynosi więcej korzyści niż samodzielne dbanie o konfigurację sieciową hostów.