DHCPv4 w Linuxie – konfiguracja serwera krok po kroku

by Patryk

Po skonfigurowaniu adresacji statycznej, routingu i DNS przychodzi moment, w którym warto pójść krok dalej i przestać ustawiać adresy IP ręcznie na każdej maszynie. W praktyce właśnie do tego służy DHCP. Dzięki niemu klient może automatycznie otrzymać nie tylko adres IP, ale też maskę podsieci, bramę domyślną, serwery DNS i inne parametry sieciowe.

W małym labie ręczne ustawianie adresów jeszcze da się ogarnąć, ale im więcej hostów i podsieci, tym szybciej zaczyna to być niewygodne. DHCP upraszcza ten proces i sprawia, że nowe stacje robocze albo maszyny testowe mogą dołączyć do sieci bez ręcznego wpisywania konfiguracji. To właśnie dlatego serwer DHCP jest jedną z podstawowych usług w każdej bardziej rozbudowanej sieci.

W tym artykule wykorzystamy nowe środowisko, przygotowane specjalnie do pokazania nie tylko samego serwera DHCP, ale również agenta przekazywania DHCP. Na Centosie niestety nie dało rady skonfigurować agenta przekazywania ze względu na brak pakietu dhcp-relay w nowych wersjach systemu Centos.

Nie będę tutaj ponownie rozpisywał całej konfiguracji sieci, routingu i tras statycznych, ponieważ te elementy zostały już omówione we wcześniejszych artykułach. Na potrzeby tego wpisu zakładamy, że środowisko jest już gotowe: mamy trzy działające sieci, poprawnie skonfigurowany routing oraz pełną komunikację między wszystkimi urządzeniami.

W naszym środowisku Debian lnx1 będzie pełnił rolę serwera DHCP. Debian lnx2 zaś będzie pełnił rolę agenta przekazywania DHCP, dzięki czemu hosty w innej podsieci będą mogły otrzymać adres z puli utworzonej na serwerze DHCP.

Instalacja i konfiguracja serwera DHCP na Debianie lnx1


Na początek instalujemy usługę DHCP na Debianie lnx1, który w naszym środowisku działa w sieci 172.16.10.0/24 i będzie pełnił rolę głównego serwera DHCP..

apt install isc-dhcp-server

Po zainstalowaniu isc-dhcp-server bardzo często nie startuje od razu, jeśli nie ma jeszcze kompletnej konfiguracji. Najważniejszy jest poniższy plik konfiguracyjny, którym zajmiemy się w pierwszej kolejności:

/etc/dhcp/dhcpd.conf

To właśnie w nim definiuje się pule adresów, bramę domyślną, serwery DNS oraz ewentualne zastrzeżenia dla konkretnych klientów. Bez skonfigurowania tych rzeczy usługa nie uruchomi się poprawnie.

Konfiguracja podstawowej puli DHCP dla sieci 172.16.10.0/24

Na początek skonfigurujmy prostą pulę adresów dla sieci, w której pracuje Windows CL1. Załóżmy, że Debian lnx1 ma statyczny adres 172.16.10.1, więc nie powinien on rozdawać tego adresu klientom. Podobnie dobrze zostawić sobie kilka adresów na potrzeby statycznych hostów i usług.

W pliku /etc/dhcp/dhcpd.conf możemy dodać na przykład taką konfigurację:

authoritative;  
  
default-lease-time 600;  
max-lease-time 7200;  
  
subnet 172.16.10.0 netmask 255.255.255.0 {  
    range 172.16.10.10 172.16.10.150;  
    option routers 172.16.10.1;  
    option subnet-mask 255.255.255.0;  
    option domain-name-servers 172.16.10.1, 172.16.20.11;  
    option domain-name "firma.local";  
    option broadcast-address 172.16.10.255;  
}

Co oznaczają te ustawienia?

  • range określa pulę adresów, które mogą być rozdawane klientom
  • option routers wskazuje bramę domyślną, czyli w tej podsieci Debiana
  • option domain-name-servers wskazuje serwery DNS
  • option domain-name ustawia lokalną domenę
  • default-lease-time i max-lease-time określają czas dzierżawy adresu

W naszym środowisku ma to sens, bo wcześniej Debian pełnił rolę DNS master, a Ubuntu DNS slave, więc klient od razu może dostać poprawne adresy serwerów nazw.

Wskazanie interfejsu nasłuchującego

Sama konfiguracja puli nie wystarczy. Trzeba jeszcze wskazać, na którym interfejsie Debian lnx1 ma nasłuchiwać zapytań DHCP. W naszym labie serwer DHCP ma obsługiwać sieć 172.16.10.0/24, więc powinien nasłuchiwać na interfejsie podłączonym właśnie do tej sieci. Przyszłościowo będzie nasłuchiwać również na interfejsie przychodzącym z sieci 172.16.20.0/24 dlatego dodajmy również enp0s8.

W pliku:

/etc/default/isc-dhcp-server

Ustaw odpowiednie interfejsy enp0s8 i enp0s9.

INTERFACESv4="enp0s8 enp0s9"

Oczywiście nazwy interfejsu mogą być u Ciebie inne, więc wcześniej dobrze sprawdzić je poleceniem ip a.

To ważny krok, bo jeśli wskażesz zły interfejs, serwer DHCP uruchomi się, ale nie będzie odpowiadał klientom z oczekiwanej sieci.

Restart usługi i pierwszy test

Po zapisaniu konfiguracji restartujemy usługę:

systemctl restart isc-dhcp-server  
systemctl status isc-dhcp-server

Jeśli wszystko zostało wpisane poprawnie, usługa powinna wystartować bez błędów.

Teraz przechodzimy na Windows CL1 i ustawiamy kartę sieciową na automatyczne pobieranie adresu. Jeśli wcześniej miał przypisane ustawienia statyczne, warto odświeżyć konfigurację poleceniem:

ipconfig /release  
ipconfig /renew

Po tej operacji klient powinien dostać adres z zakresu: 172.16.10.10 – 172.16.10.150 oraz:

  • bramę 172.16.10.1
  • serwer DNS 172.16.10.1 i 172.16.20.11

Dobrze od razu sprawdzić wynik poleceniem ipconfig /all w wierszu poleceń. To potwierdzi, czy klient faktycznie pobrał parametry z serwera DHCP.

Sprawdzanie wydanych dzierżaw

Wydane dzierżawy adresów IP można podejrzeć bezpośrednio na serwerze DHCP. Służy do tego plik:

cat /var/lib/dhcp/dhcpd.leases

Znajdziesz tam informacje o:

  • wydanych adresach,
  • czasie ich przydzielenia,
  • identyfikatorach klientów,
  • oraz stanie dzierżawy.

To bardzo przydatne przy diagnostyce, bo pozwala szybko sprawdzić, czy klient rzeczywiście pobrał adres z serwera i jaki dokładnie adres został mu przypisany.

Konfiguracja zastrzeżeń DHCP

Czasami chcemy, żeby dany klient nadal korzystał z DHCP, ale zawsze dostawał ten sam adres IP. To bardzo wygodne na przykład dla konkretnych stacji testowych, drukarek albo maszyn, które chcemy rozpoznawać po stałym adresie, ale bez ręcznej konfiguracji na samym hoście.

Takie zachowanie osiąga się przez zastrzeżenie DHCP, czyli przypisanie konkretnego adresu do konkretnego adresu MAC. W Linuxie adres MAC musi być wpisany rozdzielony dwukropkami.

W pliku /etc/dhcp/dhcpd.conf możemy dodać na przykład taki wpis dla CL1:

host cl1 {  
    hardware ethernet 08:00:27:4F:83:13;  
    fixed-address 172.16.10.10;  
}

Oczywiście adres MAC trzeba dopasować do rzeczywistego interfejsu klienta. W Windowsie możesz go sprawdzić poleceniem ipconfig /all.

Po zapisaniu zmian restartujemy usługę:

systemctl restart isc-dhcp-server

a następnie na CL1 ponownie odświeżamy konfigurację:

ipconfig /release  
ipconfig /renew

Jeśli wszystko jest poprawne, klient powinien dostać dokładnie ten adres, który został dla niego zastrzeżony.

DHCP dla drugiej podsieci – konfiguracja DHCP Relay


Do tej pory serwer DHCP działał tylko dla sieci 172.16.10.0/24, bo to właśnie w tej sieci znajduje się Debian. Problem pojawia się wtedy, gdy chcemy rozdawać adresy również klientom z drugiej podsieci, czyli 172.16.20.0/24, gdzie działa Windows CL2.

DHCP korzysta z rozgłoszeń, a te z założenia nie przechodzą przez routery. To oznacza, że klient z 172.16.20.0/24 nie dogada się bezpośrednio z serwerem DHCP w 172.16.10.0/24, chyba że po drodze użyjemy agenta przekazywania DHCP, czyli DHCP Relay.

W naszym środowisku tę rolę będzie pełnił Debian lnx2.

Instalacja DHCP Relay na Debian lnx2


Na Debian lnx2 instalujemy odpowiedni pakiet:

apt install isc-dhcp-relay

Podczas instalacji konfigurator zapyta o:

  • adres serwera DHCP – należy wskazać adres Debiana lnx1 osiągalny z lnx2, czyli: 172.16.0.10
  • interfejsy, na których relay ma działać – powinien nasłuchiwać na interfejsie skierowanym do klienta z sieci 172.16.20.0/24, czyli na interfejsie Debiana lnx2 z adresem 172.16.20.1. W moim przypadku enp0s9.

Jeśli chcesz później sprawdzić lub poprawić tę konfigurację ręcznie, zajrzyj do pliku: /etc/default/isc-dhcp-relay

Dodanie drugiej podsieci do konfiguracji DHCP

Sam relay nie wystarczy. Debian lnx1 musi jeszcze wiedzieć, jaką pulę adresów ma rozdawać klientom z drugiej sieci. W tym celu do pliku /etc/dhcp/dhcpd.conf dodajemy kolejną definicję sieci dla 172.16.20.0 oraz 192.16.0.0. DHCP lubi mieć deklaracje dla każdej sieci, warto ją dodać nawet jeśli jest nie używana.

subnet 172.16.20.0 netmask 255.255.255.0 {  
    range 172.16.20.10 172.16.20.150;  
    option routers 172.16.20.1;  
    option subnet-mask 255.255.255.0;  
    option domain-name-servers 172.16.10.1, 172.16.20.11;  
    option domain-name "firma.local";  
    option broadcast-address 172.16.20.255;  
}

subnet 192.16.0.0 netmask 255.255.255.0 {  
}

Tutaj bramą domyślną jest już 172.16.20.1, czyli adres Debiana lnx2 w tej podsieci.

Po zapisaniu zmian restartujemy serwer DHCP:

systemctl restart isc-dhcp-server  
systemctl status isc-dhcp-server

Sprawdzenie konfiguracji DHCP Relay

Na Debianie lnx2 warto upewnić się, że relay rzeczywiście działa. Po instalacji i konfiguracji możesz sprawdzić jego status:

systemctl status isc-dhcp-relay

Jeżeli zajdzie potrzeba restartu:

systemctl restart isc-dhcp-relay

Test DHCP w drugiej podsieci

Na Windowsie CL2 ustawiamy kartę sieciową na automatyczne pobieranie adresu i odświeżamy konfigurację:

ipconfig /release  
ipconfig /renew

Jeśli relay działa poprawnie, klient powinien dostać adres z zakresu: 172.16.20.100 – 172.16.20.150

oraz:

  • bramę 172.16.20.1
  • serwer DNS 172.16.10.1

Warto od razu potwierdzić to poleceniem: ipconfig /all

Co warto zapamiętać o DHCP Relay?

Sam serwer DHCP nie wystarczy, jeśli klient znajduje się w innej podsieci niż serwer. Wynika to z tego, że klient DHCP początkowo wysyła swoje zapytanie jako broadcast, a broadcast nie przejdzie sam przez router.

Właśnie dlatego potrzebny jest relay agent. Jego zadaniem jest:

  • odebranie rozgłoszenia od klienta,
  • przekazanie go dalej do właściwego serwera DHCP,
  • a potem odesłanie odpowiedzi z powrotem do klienta.

W naszym środowisku:

  • Debian lnx1 rozdaje adresy,
  • Debian lnx2 pośredniczy,
  • a CL2 dzięki temu może otrzymać konfigurację mimo tego, że znajduje się w innej sieci.

Podsumowanie


W tym artykule uruchomiliśmy serwer DHCP oraz DHCP Relay w środowisku opartym o dwa Debiany i dwóch klientów Windows. Dzięki temu mogliśmy przejść nie tylko przez podstawowe rozdawanie adresów w jednej podsieci, ale też przez bardziej praktyczny scenariusz, w którym serwer DHCP obsługuje klientów znajdujących się w innej sieci.

W kolejnym artykule pójdziemy krok dalej i zajmiemy się światem IPv6. Zobaczymy, czym różnią się SLAAC, Stateless DHCPv6 i Stateful DHCPv6, jaką rolę odgrywa Router Advertisement i jak uruchomić te mechanizmy krok po kroku w praktyce na tym samym środowisku.

You may also like

Leave a Comment